From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461) Description of problem: THe i2o_block module is not working properly. THe i2o block device is not accessible. The prestine 2.4.18 kernel works. Loading the i2o_block module should load the i2o_pci and i2o_core module but in the 2.4.18-4 & -5 kernels it only loads the i2o_core module and does not load the i2o_pci module. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Create an entry for the device in the modules.conf file and reboot 2.Try to do an fdisk on the block device in /dev/i2o/hda 3. Actual Results: THe fdisk returns with cannot open /dev/i2o/hda Additional info: The i2o device is a promise sx6000 IDE raid card
I observe the same problem using a Intel Raid Controller SRCU31
This is a bug in the installer/config tools. They should list i2o_pci in modules.conf to be loaded before i2o_core/i2o_block
Well, I have tried to manually load the modules in the right order, i.e. 1. i2o_core 2. i2o_pci 3. i2o_block It does discover my card (Promise SX6000), but no RAID volumes attached. I *REALLY* need to get this going. Is there any chance it will be fixed soon? BTW, I would settle for Promise's drivers, but the dd disk only goes to RH 7.2 and I can't get the GPL'd pti_st driver to load.
7.2 has i2o and IDE code that can't handle the newer SX6000 cards. 7.3 you need to hack up a driver disk because i2o_pci isnt on the disk image. It also won't handle the newer SX6000 card (pti_st will also btw clash with the IDE layer on the newer SX6000 too). With the current kernels the SX6000 should behave solidly, so hopefully with the next release we do too.
Will running 2.4.19 (or maybe above) fix the situation? I really need to get this card working. I have the system up and running on stock RH 7.3, so I could upgrade the kernel to get the SX6000. Am I making a vaild assumption?
It should work reliably on a stock 2.4.19 or on the Red Hat rawhide kernel. If not I'd really like to know about it.
Well I looked at the rawhide kernel RPM... can you say dependency hell? Does the Null beta work with the Promise card w/o a problem? I was, however, able to get the system to see the card and work with it somewhat after I up2dated the kernel and manually load the i2o modules. But you are 100% correct in the fact the IDE layer doesn't play well with the Promise. Oh well... <rant>I will say, however, that having paid for the distro and to not have it work "out of the box" and to be then told "hopefully with the next release we do (behave solidly) too" is more than a little frustrating. I am trying to get a customer of mine off of M$ and to have him see comments like this and the hoops that I had to jump through became dicey...</rant>
The problem is that we have to specifically detect the card in the IDE layer because it appears both as an I2O device and as IDE controllers. The driver we shipped in 7.3 knows how to do that for the older card but Promise changed the chips on the board so they have new PCI identifiers. We got exactly zero warning of that.
Well after much SRPM rebuilding, loaded the Rawhide kernel. Bad news: Problem 1. The kernel detected the IDE controllers on the card. Rebooted and did the ide2=0 ide3=0...1e9=0 trick to disable the detction of all but motherboard IDE. Problem 2. i2o_block did not pull in i2o_pci, just pulled in i2o_core and then i2o_block. Manually removed the i2o modules. and then loaded by hand i2o_core, i2o_pci and i2o_block. I then got: Problem 3. Got the following error messages. Sep 9 18:48:18 wefp kernel: I2O: Spurious reply to handler 3 Sep 9 18:48:18 wefp last message repeated 454 times And the onboard LEDs and warning buzzer started complaining vehemently about a bad RAID set (at least acording to the docs). Rebooted and went into the card setup. RAID set reported as healthy. rebooted and same result. I may not be a kernel hacker, but this is beginning to look like a showstopper.
Problem 2 is not a bug. Problem 3 means something still stomped on the IDE Its ide{n}=off not 0 I believe ?
The ide(n)stuff was a shameless lift from a Promise Fasttrak FAQ. Anyway... Doe I need to add something like: add above i2o_block i2o_pci to /etc/modules.conf? This is unclear. Any suggestions? I fresh out of them.
BTW, ide2=off, etc. doesn't work. Also noticed this message: Sep 10 09:25:12 wefp kernel: i2o/hda:<6>Device claim called, but dev already owned by I2O Block OSM!<6>I2O Block: Could not open device I *REALLY*, *REALLY*, *REALLY* need to get this going.
Stock 2.4.19 exhibits the same behavior for the IDE detection. *****HELP*****!!!!!!!!!!!!! Is there a fix available? How am I supposed to get this fscking thing working?
The already owned message is bizarre. I really need to see a full log and also the lspci -v for that system before I can take more guesses as to what is going on.
FYI: you cannot use the 1.12 promise bios with the i2o drivers. If you do i2o wont ever detect the card.
The core i2o stuff is now in rawhide and appears happy.