When you boot the 2005.1 (and previous as well) the kernel panics while detecting the ASR-2005S. Recent kernel patches >=2.6.13-rc7 IIRC fix the issue partially with pci_request_region erroring out giving you a better understanding of the issue. If I boot the cd with the nodetect option and then manually load the i2o_core & i2o_block modules I can continue the install perfectly fine (minus the 4 hours it took to get GRUB to install to the raid-5 array). My guess is that either the dpt_i2o module or possibly even the aic7xxx or i2o_* modules get loaded and start doing their business with the controller and one of them gets control last and looses. Reproducible: Always Steps to Reproduce: 1. boot livecd (tested on 2005.1) on system with i2o controller 2. wait for it 3. kernel panic (not, profit!!! unfortunately) Actual Results: kernel panic about an interrupt something (sorry for being so vague, im doing this from work without access to my machine). Expected Results: Not load the i2o_* drivers, or only load the i2o_* drivers (my personal preference) and not panic. Since this might be a problem with the coldplug or hotplug or whatever plug is loading two mutually exclusive drivers one after the other, you should be able to load and unload modules before hand. I'm not very sure where the error is coming from because I'm pretty new to debugging things and dont know of any way of tracing it to the root of the issue. If someone would like to give me some pointers on how to get to the root of the issue I'll be more than happy to RTFM. As an aside - since I now have my computer up and running through a very round-about way, I would like to note one thing. I have my whole system on a hardware raid-5 array with grub and i2o_* compiled into the kernel. The system boots from an initramfs image (if thats the correct terminology) and everything appears alright. However, my kernel does NOT have SCSI support, aic7xxx and especially not dpt_i2o compiled in OR as modules - NOT at all. and it still boots and all fine. So am I to understand that the i2o subsystem lets the raid card do all its talking to the scsi system and the kernel doesnt do it all? As in - the kernel only talks to PCI and lets the card handle all the SCSI interaction? If thats the case, it should probably be noted somewhere in the manual for people installing on hardware raid. Thanks, - frank
The dpt_i2o driver, or any i2o driver, for that matter, technically are not SCSI cards when used in this manner. They are i2o devices to the kernel, that speak SCSI to their attached devices. In other words, the kernel doesn't speak SCSI to them, it speaks i2o, and the card then speaks SCSI to the devices, which speak SCSI back, and then the card speaks i2o to the kernel. This is only the case in i2o drivers. For example, any MegaRAID controllers show up as a standard SCSI device. One of the main issues with RAID controllers is they *all* do something different, so documenting the caveats of each one is beyond the scope of our documentation. This won't be resolved until 2006.0, as we'll need a new release to properly resolve this bug. At any rate, this is why we provide things like "nohotplug" and "nodetect" to work around any defficiencies in the kernel or in configuration.
Changing Hardware to All since this would affect any PCI-capable architecture. Also lowering severity since there is a known and documented workaround (nodetect/nohotplug).
Can you verify that this is still a problem with a newer release? I do not have the hardware to verify this myself.
It's been a while and we've had a couple releases since this was reported and I cannot verify this bug due to lack of availability of the hardware. Marking as NEEDINFO.
