https://bugzilla.novell.com/show_bug.cgi?id=207707 teheo@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Comment #28 from teheo@novell.com 2007-02-25 10:15 MST ------- Okay, now I see it. This is interaction between a bit of weirdness in the jmicron controller and how yast selects modules to load. JMB363 controller has two SATA ports and one PATA port. They can be configured in quite a number of different ways but Linux uses only one setting. The two SATA ports are configured as ahci controller residing in PCI function 0 and the PATA port is configured as SFF-compliant (bog standard) IDE controller residing in PCI function 1. So, the controller has two PCI functions BUT they still have the same PCI ID. For example, on my machine. 03:00.0 Class 0104: 197b:2363 (rev 03) 03:00.1 Class 0101: 197b:2363 (rev 03) But, the .0 can only be driven by ahci while .1 by pata_jmicron. Currently, init_one()'s of both ahci and pata_jmicron check the function number and fail with -ENODEV if they're being called on the wrong function number. IOW, both ahci and pata_jmicron claim to support 197b:2363 but ahci fails on function 1 while pata_jmicron fails on function 0. yast is capable of listing all possible drivers for a device and falls back to the next one if the higher priority one fails, but the above peculiarity of JMB controllers seem to confuse it. It correctly lists ahci and pata_jmicron at the top of supported drivers list for both function 0 and function 1, and tries to load ahci as the first choice. ahci successfully attaches to function 0 and module load succeeds. At that point, probably because the module got successfully loaded, yast doesn't fall back to pata_jmicron for function 1. This problem can be fixed in two ways. 1. Fix ahci and pata_jmicron such that they load only for the correct class code - RAID for ahci, IDE for pata_jmicron. I'll make a patch for this and push it upstream. This makes the driver selection more conventional and yast should be happy with it. 2. Fix yast such that it falls back to the next driver if there is any device which doesn't get associated with currently loaded drivers. This can be tested by looking at /sys/devices/blahblah/drivers symlink. IMHO, both #1 and #2 should happen. Who do I poke for #2? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.