Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 12:40:26AM -0800, Steve Langasek wrote:
> On Fri, Mar 10, 2006 at 08:10:12AM +0100, Sven Luther wrote:
> > > I've done a little poking of my own at sysfs based on the comments in
> > > the yaird code. I can confirm that it is possible for a PCI IDE driver
> > > to be listed as associated with a PCI device without actually being the
> > > driver used to access the device. This happens on my alpha, where
> > > ide-generic must be used due to bugs in the cmd64x driver, yet running
> > > modprobe cmd64x does show this driver associated with the PCI device:
>
> > > $ ls -l /sys/devices/pci0000\:00/0000\:00\:0b.0/driver
> > > lrwxrwxrwx 1 root root 0 2006-03-09 19:46 /sys/devices/pci0000:00/0000:00:0b.0/driver -> ../../../bus/pci/drivers/CMD64x_IDE
>
> > Mmm. When this was happening, could you use and mount partition on this device ?
> > And when doing so, do you know which of ide-generic or cmd64x would be used to
> > read the drive ?
>
> Are you suggesting that loading cmd64x has changed which driver is
> associated with /dev/hda, even though the machine has partitions mounted
> from it at the time?
No, i am wondering what /sys/devices/pci0000:00/0000:00:0b.0/driver was
pointing too previous to cm64x being loaded. It seems strange to me that it
will not point to what is actually used.
Maybe you could just give a ls -l output of the device and block pointers to
the module, in all possible cases ( only cmd64x or ide-generic loaded, both
loaded in both order) ?
> > And again, is the right thing to do here, not to fix those cmd64x bugs ?
>
> Um, that's completely missing the point. The point of this exercise was to
> try to rule out a possible explanation for the yaird workaround. Which I
> did.
He, ...
BTW, did you see Jurij's post, which tracked back all those trouble to the
recently dropped Herbert-Xu-modular-ide patch ?
> > > However, /sys/block/hda/device still points to the right place, and it's my
> > > understanding that /sys/block is what yaird walks, so this still is no
> > > explanation for how someone could have mis-identified a bug in this area.
>
> > How does it find the device and then the driver starting from block ?
>
> $ readlink /sys/block/hda/device
> ../../devices/ide0/0.0
This is the ide-generic node, right ?
> So we should expect yaird to only load ide-generic on this system, since
> cmd64x, while loaded, is not associated with the root device (according to
> sysfs or otherwise).
Seems logical, i still wonder aboutthe device driver link above, since it
somehow says that cm64x is responsible for this device.
Friendly,
Sven Luther
Reply to: