Distribution: Fedora Core 3 Hardware Environment: x86 Software Environment: Problem Description: The Adaptec I2O RAID driver (dpt_i2o.c) has a few character devices with major number 151 that it uses to communicate with userspace utilities. These devices are not registered with sysfs, so udev can't pick them up. Steps to reproduce: 1) Boot Linux on a machine with an Adaptec I2O RAID controller. 2) Note that there's no "dev" file in class/scsi_host/hostX in sysfs.
Where did we end up on this? Problem still present in 2.6.13-rc4? Did you try using the other I2O drivers? Device Drivers->I2O Support?
I saw nothing that would indicate that this has been fixed in the current version of the kernel. I have not explored using the I2O drivers; I will do so when I have a chance. bugme-daemon@kernel-bugs.osdl.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=4880 > > akpm@osdl.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |akpm@osdl.org > > > > ------- Additional Comments From akpm@osdl.org 2005-07-29 00:07 ------- > Where did we end up on this? Problem still present in 2.6.13-rc4? > > Did you try using the other I2O drivers? > Device Drivers->I2O Support? > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter.
bugme-daemon@kernel-bugs.osdl.org wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=4880 > > Summary: dpt_i2o.c does not register itself with sysfs Mark, could you please take a look at this one, maybe create yourself a bugzilla account and add it to your todo list? Thanks.
Is all this fixed up now?
The applications 'assume' the dpt_i2o driver is utilizing major number 151 and make their own nodes when communicating with the Adapter, so I wonder why there is a need to register with sysfs? The driver does make calls to register_chrdev() which should make all the arrangements none-the-less.
Any updates on this problem? Thanks.
I left the position where I had access to the systems with the Adaptec SCSI cards about two months ago, but I don't believe that the problem had been fixed at that point.
Mark, do you think this is still valid, or should we shut the bug down? Thanks.
Closing: dpt_i2o works as is, there seems little point in breaking it, and its not the preferred i2o driver anyway