Bug 21432
Summary: | Ath5k - sometimes wireless network does not work | ||
---|---|---|---|
Product: | Drivers | Reporter: | Fede (fedevx) |
Component: | network-wireless | Assignee: | drivers_network-wireless (drivers_network-wireless) |
Status: | CLOSED OBSOLETE | ||
Severity: | normal | CC: | linville, me, mickflemm, nunojsg |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.novell.com/show_bug.cgi?id=637717 | ||
Kernel Version: | 2.6.34.7-0.4-desktop #1 SMP PREEMPT | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Fede
2010-10-29 06:51:32 UTC
Some laptops have both a dedicated switch for rfkill and a key combination. Perhaps you sometimes accidentally hit the key combination, causing the soft block? As for the other part, it sounds like the key (i.e. the hard block) is working as expected, but perhaps the LED isn't being handled as desired? John, I don't think I've touched anything by accident, I noticed the problem after I upgraded to OpenSUSE 11.3. As I started up the laptop and I ran iwlist wlan0 scan it reported no scan results while the led indicator would still blink. While it could be a problem with the LED not working as desired, why would then iwlist report no scan results when it should be indicating that the device is down? If you can advice on how to further troubleshoot the issue I'll be delighted to do that. Thank you Been a while...is this still an issue with kernel 2.6.37 or later? John, I don't recall seeing it again but I haven't tried much to be honest. Why don't you close this one as resolved and if I find it again I'll open a new one against the new kernel? I believe I can reproduce something similar with kernel 4.1.15. The ath5k wireless connection is managed through wpa_supplicant, and when I stop the wireless service, the card gets "soft blocked" (as shown by rfkill) and additional action is required before starting wireless again. Looking at the code for ath5k rkfill (drivers/net/wireless/ath/ath5k/rfkill.c), I can see, in ath5k_rfkill_hw_stop(): /* enable RFKILL when stopping HW so Wifi LED is turned off */ ath5k_rfkill_enable(ah); According to the git log, it seems that this code has been around since the first incarnation of the file, dating from 2009, and perhaps that would also explain the original bug reported here. |