FC2T3 - Adaptec RAID ques

[Warren Togami]

Alan Cox wrote:
> On Thu, Apr 29, 2004 at 04:28:02PM -0500, -=Brian Truter=- wrote:
> 
>>The Adaptec 2100S RAID card was supported inherantly in FC1. 
>>FC2T3 does not seem to detect it. It does probe and load the I2O_block and
>>I2O_core modules, but the installer fails saying it cannot find a hard
>>drive.

You have more than one logical block device right?  Unfortunately it was 
discovered after Test3's kernel froze that using more than one block 
device, the i2o_block driver would corrupt kernel memory, oops or panic 
depending on the situation.  These problems have since been seemingly 
completely fixed by Markus Lidel's efforts, and I really hope we can 
incorporate these changes in the FC2 final kernel.  (Read the bottom of 
this message for the latest status of this driver development.)

The 2.4 kernel series had the dpt_i2o driver maintained by Adaptec. 
Unfortunately they chose to not prepare the driver for the 2.6 kernel, 
and as a result these owners were locked out of 2.6 for a while.  There 
is some ongoing development toward fixing the dpt_i2o driver, however it 
is unclear to me whether it is fully stable.  The old 2.4 dpt_i2o driver 
  never did work on 64bit archs.

The generic I2O layer originally written by Alan Cox was unusable and 
broken in various ways in 2.6 until Markus Lidel began hacking at it. 
He began with his personal x86 32bit box, then my x86-64 dual Opteron 
server.  Due to his efforts, for the first time I am able to use the 2.6 
kernel and 64bit kernel with my Adaptec 2110S RAID card.

The one thing you have to watch out for however is that the /dev nodes 
are different when using the generic I2O layer.  Rather than having 
/dev/sdX devices, they are used as /dev/i2o/hdX.

> 
> 
> See the release notes. There are still several problems with dpt/adaptec
> stuff and i2o right now across 2.6 as a whole.
> 
> 

I wrote the below status report about I2O driver development a few hours 
ago.

Markus has just posted five I2O patches to LKML.  We have extensively 
tested that combination of I2O changes to be stable for both x86 and 
x86-64 (Dual Opteron on Tyan 2880S).  For this reason it should be safe 
to include and should not pose added risk to other kernel subsystems.

Additionally the raidutils is able to work for the first time on both 
32bit and 64bit kernels when the passthru patch is added.  This patch 
was the only portion criticized on linux-scsi mailing list, but after 
further research Markus believes that it is impossible to use the 
generic SCSI passthru to achieve the same result.  This is because 
i2o_config uses a char device, while the generic SCSI uses block devices.

List of Improvements over Upstream:
* No longer corrupts kernel memory/oops/panic when there is more than 
one logical block device.
* i2o_scsi now uses the i2o_context_list_*() functions for transaction 
context, and therefore now work on 64-bit systems too
* Stable operation tested up to four block devices with heavy I/O 
simultaneously. (bonnie++)
* Loads and unloads kernel modules cleanly.
* i2o-makefile-cleanup.patch
The Kconfig and Makefile in drivers/message/i2o have a CONFIG_I2O_PCI 
entry, which has been replaced by CONFIG_I2O_CONFIG for the i2o_config 
module.

TODO:
* Optimize for 64bit DMA addressing when available.
* Change i2o_config to use generic SCSI passthru after it is implemented 
upstream.

http://i2o.shadowconnect.com/
More information and all patches are available here.

Warren Togami
wtogami at redhat.com