On Fri, Mar 10, 2006 at 09:49:18AM +0100, Sven Luther wrote: > > > 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. Nothing: there is no driver associated with the PCI device. > > > 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 ? Yes. That seems to give most of the answers I was looking for. > > > > 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 ? Yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
