Bug 16192 - wireless LED behaves strangely
wireless LED behaves strangely
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 low
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
Depends on:
  Show dependency treegraph
Reported: 2010-06-13 10:34 UTC by florian.a.jung
Modified: 2011-01-21 18:11 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.34
Tree: Mainline
Regression: No

lspci's output (1.58 KB, text/plain)
2010-06-13 10:34 UTC, florian.a.jung
my /root/flo-setup-wlan-led (701 bytes, text/plain)
2010-08-06 10:26 UTC, florian.a.jung

Description florian.a.jung 2010-06-13 10:34:45 UTC
Created attachment 26751 [details]
lspci's output

On my IBM Thinkpad X31 with atheros wlan card, the WLAN LED behaves strangely.

actual results: when wlan is switched off via rfkill, the LED is on. when it's switched on, it has no effect (stays on). when wlan is active (transferring, searching, associating etc), the LED sometimes blinks, sometimes is on (solid), sometimes is completely off

expected results: for example: on (solid) when wlan is active, blinking if associating OR: flashing when active (transferring, associating, whatever), off when idle/rfkill-ed

only when i unload the ath5k module, the LED is switched off.
Comment 1 florian.a.jung 2010-08-06 10:25:08 UTC
On kernel 2.6.35 (i assume but didn't verify that this also works on older kernels), this could be fixed (or actually, work-around-ed) as follows:

set one LED's trigger to the rfkill of the wlan card. this alone switches the LED on or off when triggering rfkill, unfortunately also off when the card gets active (transferring or receiving data)
set the other LED's trigger to phy0radio. this alone switches the LED on when it gets active (that is, exactly then when the above would fail)

the result is a almost unnoticeable flicker when it starts transferring (it gets switched off (bug!) and switched on immediately after it), but for me, this is enough.

This is how i automated that task:

echo 'install ath5k modprobe --ignore-install ath5k; sleep 1; bash /root/flo-setup-wlan-led' > /etc/modprobe.d/flo-ath5k

the /root/flo-setup-wlan-led file is attached
it finds out the correct rfkill (i have two (bluetooth vs wlan) which have a race-condition), finds the paths to the wlan leds and sets the triggers as described above

the above may suggest that i have two LEDs. i have NOT. However, Linux sees two (rx and tx), i dunno why. The real LED can controlled by both "linux-leds". 
if i switch rx on, the real turns on. if i then switch tx (not rx!) off, it turns off again. Maybe this is related to the bug.
Comment 2 florian.a.jung 2010-08-06 10:26:56 UTC
Created attachment 27362 [details]
my /root/flo-setup-wlan-led
Comment 3 Kieran Clancy 2010-08-06 17:01:00 UTC
See a similar report here: https://bugzilla.redhat.com/show_bug.cgi?id=618232

This means there at least two instances of ath5k hardware which have a LED intended to indicate rfkill and not wireless network activity.

The kernel needs to do a better job of distinguishing between hardware with an rkfill LED and hardware with a wireless activity LED. In my opinion, it would be better to err on the side of having no working transfer light than having an rfkill light blinking madly. (For example, on my laptop the rfkill light is like 20 lumens and is extremely distracting while blinking.)
Comment 4 florian.a.jung 2010-08-07 10:51:11 UTC
NetBSD seems to handle the LED correctly, or at least, with a certain system
when i set it up or down, it turns on or off, when i start a wlan search, it blinks. (i find that pretty bright led blinking annoying, but at least netbsd is able to manage it correctly). maybe it may help to look at netbsds code.

maybe simply allowing the user to disable automatic control of the led helps. then i could tell him: "ath5k, don't touch the led!" and set the trigger correctly (or set brightness manually, which does not matter, as i need a custom script to make my wlan button working at all)

on older kernels (2.6.26), the led worked as transfer indicator, and was not very bright, as it was flashing extremely quickly. the led was not exposed.
is such a PWM possible to implement without problems in software, or would that cause high power consumption (due to interrupt wakeups etc)? because then it would be possible, for example, to turn it "half-on" for "rfkill on" and "full-on" for transmitting or so...
Comment 5 John W. Linville 2011-01-21 18:10:54 UTC
Unless/until laptop vendors want to submit their own patches, I think enabling scripts like the one in comment 2 are the best we can do...

Note You need to log in before you can comment on or make changes to this bug.