Bug 618232

Summary: ath5k: rfkill light changes from on to off and back on spasmodically
Product: [Fedora] Fedora Reporter: Kieran Clancy <clancy.kieran+redhat>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: anton, dougsland, gansalmon, itamar, jonathan, kernel-maint, linville, madhu.chinakonda, me
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-05 17:28:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
0001-ath5k-add-led_disable-module-option.patch none

Description Kieran Clancy 2010-07-26 13:30:53 UTC
Description of problem:
I just upgraded from F11 to F13, and I am now having a problem where the rfkill prominent light on my laptop (blue for wireless enabled, red for wireless disabled) flickers between states all the time when the wireless is on. The wireless does not actually turn off in this time, and udev doesn't register any change while it's flickering.

In F11 the rfkill functionality didn't work for my laptop at all (the system didn't recognise the button being pressed and the light was always red for "off", but the wireless worked without problems).

Now in F13, I am beginning to find this very distracting after just a few hours. The blue light is very bright and it keeps flashing on and off in no particular pattern. It's still red most of the time too, so it's not properly reporting the wireless state. If I press the rfkill button, the system now detects that the wireless is disabled, and the light will remain in whatever state it was in when I pressed it (no flickering).

So, my suspicion is that somehow the system has confused the rfkill indicator with a wireless network indicator (which might flash during data transfer on some laptops). Is there any way to debug this?

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. Turn on wireless and connect to a network
Actual results:
Watch the prominent light change colour annoyingly.

Expected results:
The light should be blue when the wireless is on, and red when the wireless is off. No flickering.

Additional info:
Laptop: HP Compaq Presario CQ61
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
	Subsystem: Hewlett-Packard Company Device 137b
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at d3500000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 2
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
	Capabilities: [60] Express Legacy Endpoint, MSI 00
	Capabilities: [90] MSI-X: Enable- Count=1 Masked-
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Kernel driver in use: ath5k
	Kernel modules: ath5k

Comment 1 John W. Linville 2010-07-26 14:36:39 UTC
Looks like your laptop is hitting the information from the patch below:

commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d
Author: Marcos Chaparro <nitrousnrg@gmail.com>
Date:   Mon Aug 24 23:00:31 2009 -0400

    ath5k: add led pin configuration for compaq c700 laptop
    With this patch, a compaq c700 can turn on the wifi led.
    The array of compatible devices now includes the hardware
    present in this computer, as well as the led pin and
    Signed-off-by: Marcos Chaparro <nitrousnrg@gmail.com>
    Signed-off-by: Bob Copeland <me@bobcopeland.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index 876725f..b767c3b 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -69,6 +69,8 @@ static const struct pci_device_id ath5k_led_devices[] = {
        { ATH_SDEVICE(PCI_VENDOR_ID_AZWAVE, 0x1026), ATH_LED(3, 0) },
        /* IBM ThinkPad AR5BXB6 (legovini@spiro.fisica.unipd.it) */
        { ATH_SDEVICE(PCI_VENDOR_ID_IBM, 0x058a), ATH_LED(1, 0) },
+       /* HP Compaq C700 (nitrousnrg@gmail.com) */
+       { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
        /* IBM-specific AR5212 (all others) */
        { }

Bob, I don't suppose there is anyway to easily experiment with these LED settings (i.e. without compiling kernels)?

Kieran, have you used this device with another OS?  Does it flash a different light for activity there?  Or none at all?  Is this light the only one flashing?

Comment 2 John W. Linville 2010-07-26 14:37:48 UTC
Ooops!  Forgot to Cc Bob...

Comment 3 Kieran Clancy 2010-07-26 14:43:05 UTC
In Windows Vista it is red when wireless is disabled/disconnected and blue when wireless is connected. It never flickers between red and blue while connected. There is no LED on the laptop to indicate wireless transfer activity.

Comment 4 John W. Linville 2010-07-28 16:32:43 UTC
Created attachment 435068 [details]

Comment 5 John W. Linville 2010-07-28 17:31:55 UTC
F-13 test kernel w/ above patch is available here:


To use it, create a file named /etc/modprobe.d/ath5k.conf with the following single line:

options ath5k led_disable=1

Then reboot into the new kernel installed from the link above (once the build finishes).  Does this stop the annoying blink?

Comment 6 Bob Copeland 2010-07-29 12:05:28 UTC
As mentioned on the ML we can do without a modparam here, instead you can do:

$ echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"

and same for the rx trigger.  That will disable the LED completely, and you can also set the current value of the led through the brightness file (I think)... the LEDs are binary so use either 0 or max_brightness.

Both triggers are connected to the same gpio in ath5k, so you'll have to modify both triggers or turn one off.  There is a second gpio for the rfkill; I don't believe we control how the LED is displayed there, just whether it is on or off.

Also of note, you can use other mac80211 triggers like 'phy0assoc' or 'phy0radio' if you want to have the led lit only when associated or when rfkill is enabled, etc.  Of course I have not tried, since I don't have any hardware with LEDs.

Oh one other thing: some cards have hardware LEDs which aren't hooked up to the trigger files because the hardware drives them.  It is possible to put these LEDs under software control (madwifi does) but IMO it's silly to make the host strobe the gpio if the card can do it.  This is mostly on older pcmcia kit though.

Comment 7 Bob Copeland 2010-07-29 12:09:59 UTC
RE the OP, to me it sounds like rfkill and led gpios are separate but this particular laptop uses it to indicate rfkill state.  So I think you can just set one of the trigger files to phy0radio and turn off the other one.

Comment 8 Kieran Clancy 2010-07-29 16:21:53 UTC
John, thank you for taking the time to build a custom kernel with that patch. Since Bob's suggestion (thanks Bob) works, I didn't test it at this point.

Bob, I don't fully understand your comment; what is gpio/mac80211/phy0assoc/phy0radio/etc?

Echoing 'none' to both triggers makes the light stop flickering.

I think you may have explained it (but I didn't understand), but why doesn't the rfkill light change colour anymore?

Lastly, it's all fine for me to put a couple of lines in an init script to set these to 'none', but there's obviously a bug in that the kernel is detecting all HP ath5k devices with the same id as having a wireless network indicator when in fact it is an rfkill indicator. Is it possible to differentiate in the kernel between ath5k devices with an rfkill LED and ones with transfer LEDs?

Comment 9 Bob Copeland 2010-07-30 02:05:37 UTC
(In reply to comment #8)
> John, thank you for taking the time to build a custom kernel with that patch.
> Since Bob's suggestion (thanks Bob) works, I didn't test it at this point.
> Bob, I don't fully understand your comment; what is
> gpio/mac80211/phy0assoc/phy0radio/etc?

Okay I'll try to clarify:

- gpio = general purpose I/O pins, i.e. the wire coming from the wifi mac chip to somewhere on the pcie connector which is then hooked up to the LED on the case in the laptop.  There may be multiple gpios with different functions; e.g. ath5k supports a write-able gpio for setting the rfkill state, and another one for setting the LED state.  Though theoretically there might be multiple LEDs, or a separate rfkill LED, we really only support one single LED.

- mac80211 = the Linux kernel wireless stack, which sits above ath5k.  It provides the basic LED interface that wireless drivers can use.

Each exposed LED has an LED trigger, which is represented by the file in sysfs and represents the event that turns the LED on or off.  For ath5k, since we just support a single LED, both rx and tx triggers are set up to toggle the LED when packets are received and transmitted.

> I think you may have explained it (but I didn't understand), but why doesn't
> the rfkill light change colour anymore?

Think of the rfkill switch and the rfkill LED as separate functions.  We're
obviously strobing the rfkill LED for rx and tx, which doesn't match what Vista does.  I believe you can get a similar-to-Vista behavior by doing:

$ echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"
$ echo phy0radio > "/sys/class/leds/ath5k-phy0::rx/trigger"

In other words, turn one of the triggers off and make the other one operate for radio on/off events.  You can get a list of available triggers by catting the trigger file.

> Is it possible to differentiate in the
> kernel between ath5k devices with an rfkill LED and ones with transfer LEDs?    

This, I don't know.  It would be nice if this info were already available via acpi or something.  We could add another flag for LED function but the pin/polarity table already doesn't scale, so there needs to be a better way than just keeping the table of pci ids...

Comment 10 John W. Linville 2010-08-05 17:28:36 UTC
It sounds like you at least have a solution to tame the LEDs.  Determining if/how to differentiate between laptops on some basis other than PCI IDs seems like an upstream issue to me.

Comment 11 John W. Linville 2010-08-06 13:35:26 UTC
This might be useful for reference: