Bug 173727
Summary: | 2.6.14-1.1637_FC4 loads orinoco_pci and hostap_pci simultaneously | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | jar <jar> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | jesse.brandeburg, kmilos, moneta.mace, notting, pfrields, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-10-16 20:43:27 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jar
2005-11-19 19:33:07 UTC
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. |