Bug 191326
Summary: | Linksys WPC11 v.3 does not work in FC 5 (worked great FC1-4) | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | zingale <zingale> | ||||||||||
Component: | kernel | Assignee: | Neil Horman <nhorman> | ||||||||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 5 | CC: | davej, linville, moneta.mace, netllama, slysam, triton, williamnorfleet2000, wtogami | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2006-11-13 19:04:29 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: | |||||||||||||
Attachments: |
|
Description
zingale
2006-05-10 20:22:55 UTC
Same problem for me. What I've discovered through alot of painful trial & error, is that if I leave the card ejected until FC5 has fully booted, and then insert it, networking works fine. But if its inserted all the time while booting, then it never works. I've also found that the hostap_cs driver seems to want to take ownership of the card, and orinoco_cs (which owned it all along) fight it out. That doesn't really explain why it will work with being inserted post-install though. It looks like this can be addressed by adding: # Wireless LAN card blacklist hostap_cs to the file /etc/modprobe.d/blacklist and alias wlan0 orinoco_cs to the file /etc/modprobe.conf It's working reliably here. That does not make any difference here. The problem that I was seeing is that both drivers (orinoco, hostap) were getting loaded. With the changes above, I show only the orinoco driver: # lsmod | grep "orinoco\|hostap" orinoco_cs 16900 1 orinoco 36756 1 orinoco_cs hermes 7680 2 orinoco_cs,orinoco Right, it does address that problem, however I still can't get my WPC11v3 to work from bootup. Only when I boot with it ejected, and then insert later does it work. This works for me too now. Thanks. Haven't tried getting it working from boot-up -- that's not something I normally try to do (I rarely boot -- usually I suspend). I'm a bit confused...can this issue be closed now? If not, please try the FC5.netdev kernels: http://people.redhat.com/linville/kernels/fedora-netdev/ Do those kernels work for you? Please don't close this, its not fixed for me with the latest FC5 kernel. I'll try to test a netdev kernel this weekend. thanks *** Bug 189566 has been marked as a duplicate of this bug. *** Just tested the latest "2122" netdev kernel. Unfortunately, there is no change in behavior whatsoever. Lonni, please attach the output of running "sysreport"...thanks! Created attachment 130245 [details]
requested sysreport
requested sysreport
sysreport attached, thanks John! Created attachment 130323 [details]
Command responces
I am having this same problem in FC5 with my AiroNet 350 (airo_cs). here is the output from ifconfig -a iwconfig tail /var/log/messages I hope this helps in finding the problem. Well it has been a while...can everyone try the current kernels at the location from comment 7, and post the results here...thanks! still broken here. 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. No, this still isn't fixed. Its sad that this bug has existed for the entire life of FC5 and no one made any effort to work on it. I have had exactly the same problem with an SMC2532W-B card in a Dell Inspiron 7500 under a fresh, fully updated install of FC5 (this combo worked fine under FC3 and FC4 and the orinoco_cs driver). Kernel is 2.6.18-1.2200.fc5. I applied the fixes describe in Post 2 above (thanks, Mace!). Initially, the card would not link with its access point when installed in the machine during booting. However, disabling services NetworkManager and NetworkManagerDispatcher fixed that. The card now works normally. Thanks to all! So I've been reading through this ticket, and the whole thing seems to be a little lost to me. It sounds like there are two problems being discussed in this ticket: 1) The confusion of the hostap_cs and orinoco_cs drivers over who should be running the wireless NIC. 2) The inability to pass traffic with cards driven by the orinoco driver coupled with the appearance of a clearly borked MAC address. Item (1) appears fixed by the comments in #2 and I think can be completely put to bed at this point. For those still having problems with (2) please configure your syslog.conf file to record kern.debug messages and higher, then reboot the box and try to send some traffic over your wireless link. Then send in the /var/log/messages file to this ticket. Thanks! How does one "configure your syslog.conf file to record kern.debug messages and higher" ? man syslog.conf the details are all there. basically you just make sure there is a line in /etc/syslog.conf that matches this regex: .*kern.debug.*/var/log/messages Created attachment 140413 [details]
/var/log/messages
well, it appears from your message logs that you haven't properly blacklisted the hostap driver in your system, as per comment #2 (I can see that both modules are loaded from your message log). Please correct that and try again. See commment #3 where I stated that didn't help. That doesn't mean you don't need to do it. Orinoco and hostap are having some sort of conflict on systems with this hardware. Whatever else may be going on in your system, this is certainly a problem, that we're not going to see past without blacklisting hostap. So please go back, blacklist the hostap driver, and try this again. Amazingly, after blacklisting hostap_cs the NIC works after rebooting! This was definitely not the case a few months ago I apologize for not trying it when you suggested earlier. Actually, nevermind, its not working again after another reboot. /var/log/messages attached. Created attachment 140968 [details]
/var/log/messages with hostap_cs blacklisted
/var/log/messages with hostap_cs blacklisted
Looking at your last message log, I don't see any messages from hostap _or_ orinoco, are you sure that you didn't somehow accidentally blacklist both drivers or something? If you modprobe ornico by hand, does everything start working again? I'm 100% certain that I didn't blacklist orinoco, as its loaded, along with orinoco_cs & hermes (in lsmod output). As before, if I boot without the card inserted, and then insert it once FC5 has finished booting fully, networking comes up automatically, and there are no problems. I'm sorry, I must have been looking at another message log, I see orinoco getting loaded now in your last boot. Although I do notice that you are not on the latest fc5 netdev kernel. I would highly recommend updating before we go any further with this. I did test with a recent netdev kernel recently (and it also exhibited this bug), unfortunately, all 2.6.18.x based kernels are pretty much unusable on this system due to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214096 well, I don't know what to tell you. You are at this point reporting a problem that every other reporter has fixed by following the procedure outlined in comment #2. At this point the only options that I see are for you to try again with the latest driver available from linksys, and see then if the hardware responds better (from what I read, there are several firmware updates in the latest driver). I'm not sure that I understand what you mean by "try again with the latest driver available from linksys". Do you mean the latest netdev kernel, or something from Linksys's website? the latter The 'latest' driver on Linksys's website is 3.5 years old, and doesn't even build on a recent kernel. Dang, didn't check the date, Well, I'm sorry, I don't know what to tell you. You are describing a problem that matches identically what at least 4 other people in this ticket alone have described, and for each of them, the problem is solved by blacklisting the alternate hostap driver. I'm not sure what is different about your particular setup, but at this point, unless you can provide me with some other data indicating that there is another bug here, I can only assume that there is something awry in your configuration that I can't see with the provided data, that is causing your system to not obtain a dhcp address with the nic plugged in from boot. *sigh* No offense, but I don't understand why this was closed out simply because you can't figure out what is wrong. I thought that bugs get closed when there is an explanation or solution to the bug, or a lack of communication from the bug reporter. Neither seems to be the case here. There appear to be at least 4 people who have commented and/or are CC'd on this bug who have not stated that the fix in comment #2 worked for them. "unless you can provide me with some other data indicating that there is another bug here" I don't know what kind of information you need, however I get the strong impression that you went down your checklist, and when you hit the bottom without figuring this out, you gave up and closed the bug. If you don't know what the problem is here, that's fine, I can live with that, if you'd admit as much and just let the bug sit for another 6 months. However, closing a bug when its clear that its not resolved just seems like the wrong approach. |