Mailinglist Archive: opensuse-bugs (8120 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=207707


teheo@xxxxxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #28 from teheo@xxxxxxxxxx  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.