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(a)redhat.com