Bug 173647

Created attachment 82504 [details]
hwinfo output

Hwinfo was created after manual change of driver in YaST to hostap_pci.

where does /etc/modprobe.d/prism2 come from?

From wireless-tools package.

Reassigning to the new maintainer of yast2-network.

Stana, what is output from "hwinfo --netcard"?

Here it is.

See also comment #1.

14: PCI 06.0: 0200 Ethernet controller                          
  [Created at pci.286]
  UDI: /org/freedesktop/Hal/devices/pci_10ec_8139
  Unique ID: JNkJ.IQxIdIhhuH7
  SysFS ID: /devices/pci0000:00/0000:00:06.0
  SysFS BusID: 0000:00:06.0
  Hardware Class: network
  Model: "Realtek RT8139"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8139 "RTL-8139/8139C/8139C+"
  SubVendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  SubDevice: pci 0x8139 "RT8139"
  Revision: 0x10
  Driver: "8139too"
  Driver Modules: "8139too"
  Device File: eth1
  I/O Ports: 0xd000-0xd0ff (rw)
  Memory Range: 0xdfffef00-0xdfffefff (rw,non-prefetchable)
  Memory Range: 0xdffd0000-0xdffdffff (ro,prefetchable,disabled)
  IRQ: 11 (105134 events)
  HW Address: 00:50:fc:33:ce:ba
  Link detected: yes
  Module Alias: "pci:v000010ECd00008139sv000010ECsd00008139bc02sc00i00"
  Driver Info #0:
    Driver Status: 8139too is active
    Driver Activation Cmd: "modprobe 8139too"
  Driver Info #1:
    Driver Status: 8139cp is active
    Driver Activation Cmd: "modprobe 8139cp"
  Config Status: cfg=no, avail=yes, need=no, active=unknown

18: PCI 08.0: 0282 WLAN controller
  [Created at pci.286]
  UDI: /org/freedesktop/Hal/devices/pci_1260_3873
  Unique ID: Kbch.1o+tnlD7E2E
  SysFS ID: /devices/pci0000:00/0000:00:08.0
  SysFS BusID: 0000:00:08.0
  Hardware Class: network
  Model: "Intersil Prism 2.5 Wavelan chipset"
  Vendor: pci 0x1260 "Intersil Corporation"
  Device: pci 0x3873 "Prism 2.5 Wavelan chipset"
  SubVendor: pci 0x1260 "Intersil Corporation"
  SubDevice: pci 0x3873 
  Revision: 0x01
  Driver: "hostap_pci"
  Driver Modules: "hostap_pci"
  Device File: wifi0
  Device Files: wifi0, wlan0
  Features: WLAN
  Memory Range: 0xdfdff000-0xdfdfffff (rw,prefetchable)
  IRQ: 12 (21001 events)
  HW Address: 00:60:b3:6b:d3:c5
  WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13
  WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472
  WLAN bitrates: 1 2 5.5 11
  WLAN encryption modes: WEP40 WEP104
  WLAN authentication modes: open sharedkey
  Module Alias: "pci:v00001260d00003873sv00001260sd00003873bc02sc80i00"
  Driver Info #0:
    Driver Status: hostap_pci is active
    Driver Activation Cmd: "modprobe hostap_pci"
  Driver Info #1:
    Driver Status: orinoco_pci is not active
    Driver Activation Cmd: "modprobe orinoco_pci"
  Driver Info #2:
    Driver Status: prism2_pci is not active
    Driver Activation Cmd: "modprobe prism2_pci"
  Config Status: cfg=no, avail=yes, need=no, active=unknown

44: USB 00.0: 0291 USB Host-to-Host link
  [Created at usb.122]
  UDI: /org/freedesktop/Hal/devices/usb_device_5e3_502_noserial_if0
  Unique ID: wn1q.O_1aoNxqb1B
  Parent ID: 2XnU.NsNrnmnifN0
  SysFS ID: /devices/pci0000:00/0000:00:11.3/usb5/5-2/5-2:1.0
  SysFS BusID: 5-2:1.0
  Hardware Class: network
  Model: "Genesys Logic GL620USB GeneLink USB-USB Bridge"
  Hotplug: USB
  Vendor: usb 0x05e3 "Genesys Logic, Inc."
  Device: usb 0x0502 "GL620USB GeneLink USB-USB Bridge"
  Revision: "1.80"
  Driver: "gl620a"
  Driver Modules: "gl620a"
  Device File: usb0
  Speed: 12 Mbps
  HW Address: 16:9a:ad:f6:02:ce
  Link detected: yes
  Module Alias: "usb:v05E3p0502d0180dc00dsc00dp00icFFisc00ip00"
  Driver Info #0:
    Driver Status: usbnet is active
    Driver Activation Cmd: "modprobe usbnet"
  Driver Info #1:
    Driver Status: gl620a is active
    Driver Activation Cmd: "modprobe gl620a"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #41 (Hub)

But now you're running correct driver.
Can you reproduce it when installation start? Because YaST uses (or better - should) use modules from Linuxrc, so we should fix it there.
There is no rule about /etc/modprobe.d/* (but if hwinfo will allow this, it can select correct module for YaST)

Just start installation and check which driver is running ...

Created attachment 142767 [details]
hwinfo-netcard.log

hwinfo --netcard output when booted Installation menu from the OpenSUSE 10.2 DVD.

And this is from live system on the installed system:

utx:~ # grep -r prism2_pci /etc/modprobe.* /lib/modules/2.6.* | grep 1260 | grep 3873
/lib/modules/2.6.18.2-34-default/modules.alias:alias pci:v00001260d00003873sv*sd*bc*sc*i* prism2_pci
/lib/modules/2.6.18.2-34-default/modules.pcimap:prism2_pci           0x00001260 0x00003873 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
/lib/modules/2.6.18.8-0.3-default/modules.alias:alias pci:v00001260d00003873sv*sd*bc*sc*i* prism2_pci
/lib/modules/2.6.18.8-0.3-default/modules.pcimap:prism2_pci           0x00001260 0x00003873 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
utx:~ # rpm -qf /lib/modules/2.6.18.8-0.3-default/modules.pcimap
kernel-default-2.6.18.8-0.3

Jirko, 
that card is Prism2.5 and driver prism2_pci doesn't support it.
Remove it from modules.alias (or from source what is parsed when modules.alias is generated)

Sorry, that's against upstream kernel policy, I can't do that. Exactly for this reason, unbind and bind attributes (files) in sysfs were introduced. YaST should use them if it doesn't do that already.

Okay, I was too quick with my response. prism54 doesn't work with this card and it shouldn't be listed. I cannot see 1260:3873 PCI ID in prism54 driver in the latest HEAD kernel. Could you reproduce the problem on 10.3?

Hm, I was confused by those numbers, sorry. It's not prism54 but prism2_pci. It's from wlan-kmp package (or wlan-ng-kmp in the latest stable), not from the kernel.

I recently dropped prism2_pci, but there is still the problem left that there are two drivers matching one device. We should prefer hostap over orinoco, as it does support WPA. But for some devices, orinoco may work better. Hence, it would be good if there was a way to select the wanted driver. Kay, does udev support driver selection somehow?

No, unfortunately not in a sane way today. The magic is all in the kernel, and userspace has no control over it, besides not to load a driver.

It could be possible to specify a depmod driver order (man depmod.conf), so that one module gets loaded before the other one, but that may be unreliable in some situations, especially after device re-plug when the modules are already loaded. But it's probably still worth to give it a try.

The only safe way is that the user blacklists one or the other driver. 

There is infrastructure in the kernel and udev now, to allow per-device driver binding configuration with udev rules, but this is not enabled by default. It will need a lot of testing, as it completely changes how Linux handles driver binding. We may get ready for that in the next months.

Do you know (In reply to comment #16 from Kay Sievers)
> There is infrastructure in the kernel and udev now, to allow per-device driver
> binding configuration with udev rules, but this is not enabled by default. It
> will need a lot of testing, as it completely changes how Linux handles driver
> binding. We may get ready for that in the next months.

It is possible (and the functionality is there for a really long time) to use bind/unbind sysfs attributes to change the driver on the fly - even when you have both modules loaded. Why you does not use this? It's thoroughly tested and works without problems.

*** Bug 297671 has been marked as a duplicate of this bug. ***

(In reply to comment #17 from Jiri Benc)
> Do you know (In reply to comment #16 from Kay Sievers)
> > There is infrastructure in the kernel and udev now, to allow per-device driver
> > binding configuration with udev rules, but this is not enabled by default. It
> > will need a lot of testing, as it completely changes how Linux handles driver
> > binding. We may get ready for that in the next months.
> 
> It is possible (and the functionality is there for a really long time) to use
> bind/unbind sysfs attributes to change the driver on the fly - even when you
> have both modules loaded. Why you does not use this? It's thoroughly tested and
> works without problems.

Thanks for letting me know what we can do in the driver core. :)

It just doesn't make sense to let a random kernel driver attach to the device, and then read the configuration and find out to unbind and bind the device to another driver.
It creates all sorts of races, where the device is already in used by other subsystems. Like you can just unbind a device with an already automounted filesystem and such things.

To finally address this, how should we proceed in the case that are two drivers for the same device? We cannot simply blacklist one of the drivers, as the set of supported cards may differ. This is definitely the case for orinoco and hostap, as orinoco supports Hermes chipsets besides Prism2. It may be the case for PrismGT cards as well, as p54 might not support FullMAC devices (not sure about this). I the past, I did blacklist all drivers and added lots of alias-lines to modprobe config, but this is quite a PITA. So far, udev simply loads all matching drivers, which is probably not what the user wants. Is there some mechanism in udev that could help us? There a reasons to not use re-binding, as Kay stated.

Isn't it somehow possible to prefer one module over another? Kay, you afaik told me so, some time ago. But i also have something in mind that this means did not help.

Nevertheless, i guess we will always have this problem. driver will probably never have mutually exclusive device lists. So we need a generic way to solve this. Kay, you often discuss related topics with kernel and modprobe maintainers. Would you please try to find a generic solution?

We have modules.order now, to solve common problems in that area. It defines the loading order of multiple modules for the same device. It also reflects the in-kernel link order, for kernels without modules. We prefer libata drivers over IDE driver that way now.

We don't have a device specific configuration to bind drivers. Entire userspace driver binding would be needed, it might be possible with the current infrastructure, but I doubt it will happen anytime soon. It seems too fragile, and nobody is working on it.

I consider this as fixed, and everything else a feature request which should not be handled in bugzilla.