From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: When using FC4 2.6.12, I have to put the following lines to the end of the /etc/hotplug/blacklist to get rid of loading orinoco_pci. # a) Do NOT load orinoco_pci when we are using hostap driver # b) Do NOT load hostap_pci or it's alias wlan0 defined in # /etc/modprobe.conf, let network service run it instead. orinoco_pci hostap_pci wlan0 Now when I updated to FC4 2.6.14 this doesn't work any more. I have to delete orinoco_pci. Otherwise both hostap_pci and orinoco_pci are loaded at boot. orinoco 0.15rc2 (David Gibson <hermes.id.au>, Pavel Roskin <proski>, et al) orinoco_pci 0.15rc2 (Pavel Roskin <proski>, David Gibson <hermes.id.au> & Jean Tour eth2: WEP supported, 104-bit key eth2: MAC address 00:0E:6A:6A:6A:6A eth2: Station name "Prism I" eth2: ready ACPI: PCI interrupt for device 0000:02:0a.0 disabled e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 ip_tables: (C) 2000-2002 Netfilter core team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.3 (4095 buckets, 32760 max) - 236 bytes per conntrack u32 classifier Perfomance counters on OLD policer on input device check on Ingress scheduler: Classifier actions prefered over netfilter ieee80211_crypt: registered algorithm 'NULL' hostap_pci: 0.4.4-kernel (Jouni Malinen <jkmaline.fi>) ACPI: PCI Interrupt 0000:02:0a.0[A] -> Link [LNKG] -> GSI 11 (level, low) -> IRQ 11 hostap_pci: Registered netdevice wifi0 wifi0: Original COR value: 0x50 prism2_hw_init: initialized in 192 ms wifi0: NIC: id=0x8013 v1.0.0 wifi0: PRI: id=0x15 v1.1.1 wifi0: STA: id=0x1f v1.7.4 wifi0: Intersil Prism2.5 PCI: mem=0xdfbff000, irq=11 wifi0: registered netdevice wlan0 Version-Release number of selected component (if applicable): 2.6.14-1.1637_FC4, hotplug-2004_09_23-7, module-init-tools-3.1-4 How reproducible: Always Steps to Reproduce: 1. Install Prism2.5 pci card to the machine 2. Put orinoco_pci and wlan0 module alias to hotplug blacklist 3. Reboot Actual Results: Both orinoco_pci and hostap_pci are loaded. Expected Results: After putting orinoco_pci & wlan0 to hotplug blacklist, hotplug system should not load them and then hostap_pci is the only driver which is loaded for that HW. Additional info:
I'm seeing the same on FC5test2, kudzu consistently assigns orinoco_pci to this hardware, but both drivers get loaded anyway. Since hotplug is being deprecated, I guess the modules should now go to /etc/modprobe.d/blacklist? Still, it would be nice if kudzu/neat made this work without intervention.
kudzu is actually not involved anymore. It's all done via udev and the kernel's event layer. Ideally only one of them would actually claim the device.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Yes same problem continues with 2.6.15-1.1830_FC4. Not only the orinico_pci and hostap_pci fight but also e100 and eepro100. It seems that in FC4 there is no place to blacklist a module. And because same device IDs exists in those modules, they all are loaded. According to Kay Sievers the blacklistning should be possible with module-init-tools-3.2-0.pre9.1 or never, but currently FC4 includes only module-init-tools-3.1-4.
There is /etc/hotplug/blacklist in FC4.
>There is /etc/hotplug/blacklist in FC4. Yes there is, but it doesn't affect anything. If I put lines like: ... ... orinoco_pci orinoco eepro100 to the end of the /etc/hotplug/blacklist, it affects anything, double modules e100, eepro100 and rinico_pci, hostap_pci are still loaded. It (/etc/hotplug/blacklist) works with 2.6.12.xx kernels but not with 2.6.14.xx or 2.6.15.xx kernels. Or do I have some problem elsewhere?
...also both 8139cp and 8139too has been loaded. So there may be many extra modules loaded for the same hw nowadays. How to tell to the system that: Load hostap_pci but not orinoco_pci Load e100 but not eepro100 Load 8139too but not 8139cp If I remember correctly in 2.6.12.xx the system doesn't work correctly if double modules are loaded (that's why I originally start to blacklist them to get working system), but now everything (lan/wlan) seems to work. Maybe the drivers loaded first (e100, 8139too, hostap_pci) registers itself and the drivers loaded afterwards (eepro100, 8139cp, orinoco_pci) can't register and it just stay indle to the memory. But is the loading order always the same between reboots so that the wrong drivers doesn't got loaded?
Just updated the module-init-tools to module-init-tools-3.2-0.pre9.0.FC4.1. I also did own /etc/modprobe.d/blacklist-custom file and put the following lines to it: blacklist hermes blacklist orinoco blacklist orinoco_pci blacklist eepro100 blacklist 8139cp This prevents eepro100 and 8139cp from loading, but not orinoco*/hermes modules. Orinoco modules get loaded just after hostap_pci. Why this driver doesn't want to honor the blacklisting?
Is this getting loaded at system startup or later? Is it being loaded by udev, kudzu, or something else?
> Is this getting loaded at system startup or later? Is it being loaded by udev, > kudzu, or something else? I don't know sure, the orinoco driver has been loaded at start-up by system itself udev/hotplug or kudzu. If I delete the /etc/sysconfig/hwconf, someone generates it again after system start-up. There is also section for "Intersil Corporation Prism 2.5 Wavelan chipset" which doesn't hold true. class: NETWORK bus: PCI detached: 0 device: eth2 driver: orinoco_pci desc: "Intersil Corporation Prism 2.5 Wavelan chipset" vendorId: 1260 deviceId: 3873 subVendorId: 10b7 subDeviceId: 0001 pciType: 1 pcidom: 0 pcibus: 2 pcidev: a pcifn: 0 The following lines should be: device: eth2 --> wlan0 driver: orinoco_pci --> hostap_pci Yes it seems like the kudzu is guiltily for this?
(In reply to comment #10) > Yes it seems like the kudzu is guiltily for this? No it is not. After disabling kudzu by 'chkconfig kudzu off' and rebooting the orinoco* modules are still loaded.
OK, so what happens in FC4 is that kmodule uses the kudzu probing code to decide what modules to load. It will then come up with one of orinoco_pci or hostap_pci, depending on the order of the modules in modules.pcimap. If it probes orinoco_pci and it is in the blacklist files, though, then that should mean kmodule won't load it. However, that means it won't load the other one either (hostap_pci). This code may not be working right, though - it appears it isn't.
(In reply to comment #12) > OK, so what happens in FC4 is that kmodule uses the kudzu probing code to decide > what modules to load. It will then come up with one of orinoco_pci or > hostap_pci, depending on the order of the modules in modules.pcimap. > > If it probes orinoco_pci and it is in the blacklist files, though, then that > should mean kmodule won't load it. However, that means it won't load the other > one either (hostap_pci). This code may not be working right, though - it appears > it isn't. Ok but how is the situation different between: a) hostap_pci is loaded first, then orinoco_pci --> blacklistning doesn't work b) e100 is loaded first, then eepro100 --> blacklistning works !
Is this a add-in cardbus card, or mini-pci on the mainboard?
(In reply to comment #14) > Is this a add-in cardbus card, or mini-pci on the mainboard? It is native PCI card: 02:0a.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01) Subsystem: 3Com Corporation: Unknown device 0001 Flags: medium devsel, IRQ 11 Memory at dfbff000 (32-bit, prefetchable) [size=4K] Capabilities: [dc] Power Management version 2
I have this same problem (dual drivers load, network doesn't work) on an IBM T30 laptop model 2366-BU4. I'm going to file an additional bug on hostap because it doesn't work on this chipset while orinoco does.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
I will retest this with Fedora Core 6 when it comes out. I will open a new bug report if the problem is still there with FC6.
ok, thanks.