This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 638943

Summary: ath5k gain calibration timeout
Product: [Fedora] Fedora Reporter: Lenka Pátková <nicci.l>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 15CC: bugzilla.redhat.com, clancy.kieran+redhat, collura, davej, dougsland, gabriele.svelto, gansalmon, greg.b.redhat, itamar, jklimes, jonathan, julian.fedora, kernel-maint, madhu.chinakonda, maksim.burnin, mozilla_bugs, pv.bugzilla, sgruszka
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 839365 (view as bug list) Environment:
Last Closed: 2012-07-11 13:53:34 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
dmesg since suspend
none
part of var log messages none

Description Lenka Pátková 2010-09-30 08:55:45 EDT
Description of problem:

Several times a day wifi disconnects from the AP, unable to reconnect again. Restart won't help, needs to be power cycled. Dmesg shows following errors: 

Sep 30 14:29:44 broucek kernel: net_ratelimit: 5 callbacks suppressed
Sep 30 14:29:44 broucek kernel: ath5k phy0: gain calibration timeout (2412MHz)
Sep 30 14:29:44 broucek kernel: ath5k phy0: gain calibration timeout (2417MHz)
...

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

kernel-2.6.34.7-56.fc13.x86_64

How reproducible:

Not sure, but it happens several times a day, when I'm at home.

Additional info:

lspci -vv:
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
	Subsystem: Device 1a3b:1026
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at fdff0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ath5k
	Kernel modules: ath5k

dmesg:
Sep 30 09:07:23 broucek kernel: ath5k 0000:02:00.0: PCI INT A -> GSI 17 (level, 
low) -> IRQ 17
Sep 30 09:07:23 broucek kernel: ath5k 0000:02:00.0: registered as 'phy0'
Sep 30 09:07:23 broucek kernel: ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2
, PHY: 0x70)
Comment 1 Bug Zapper 2011-05-31 08:14:50 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Julian Aloofi 2011-06-06 09:10:46 EDT
This still happens in Fedora 15, I'm seeing exactly the same problems, on x86 though.
lspci -vv
14:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
	Subsystem: AMBIT Microsystem Corp. AR5007EG 802.11bg NIC
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 19
	Region 0: Memory at cfcf0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ath5k
	Kernel modules: ath5k

I can reproduce this on my laptop when using it on battery power for a couple of minutes, or resuming from suspend (to RAM).
Attaching my dmesg since the point where I suspended the machine.
I already had this problem with previous kernels on other distributions, it seems to be happening since 2.6.27.

Could someone please clarify what info is needed to clear the NEEDINFO?
Comment 3 Julian Aloofi 2011-06-06 09:11:25 EDT
Created attachment 503216 [details]
dmesg since suspend
Comment 4 Kieran Clancy 2012-02-04 09:08:44 EST
Attempting to clear NEEDINFO.

I'm seeing this too. Fedora 16.

kernel-3.2.2-1.fc16.x86_64

02:00.0 Ethernet controller: Atheros Communications Inc. AR242x / AR542x Wireless Network Adapter (PCI-Express) (rev 01)
	Subsystem: Hewlett-Packard Company Device 137b
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at d3500000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [90] MSI-X: Enable- Count=1 Masked-
		Vector table: BAR=0 offset=00000000
		PBA: BAR=0 offset=00000000
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
	Kernel driver in use: ath5k
	Kernel modules: ath5k
Comment 5 Peter Janes 2012-04-15 17:23:05 EDT
My Acer Aspire One D150-1055 has a similar issue.  It's not limited to or solved by battery or suspend/resume activity; only a power cycle will recover.

kernel-3.3.1-5.fc16.i686

lspci -vv
01:00.0 Ethernet controller: Atheros Communications Inc. AR242x / AR542x Wireles
s Network Adapter (PCI-Express) (rev 01)
        Subsystem: Foxconn International, Inc. Device e008
        Physical Slot: 1
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 55100000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3h
ot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
                Address: 00000000  Data: 0000
        Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L
1 <64us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupporte
d-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPe
nd-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L
0 <512ns, L1 <64us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 128 bytes Disabled- Retrain- CommCl
k+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive
- BWMgmt- ABWMgmt-
        Capabilities: [90] MSI-X: Enable- Count=1 Masked-
                Vector table: BAR=0 offset=00000000
                PBA: BAR=0 offset=00000000
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
 MalfTLP- ECRC- UnsupReq+ ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
 MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
 MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout+ NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
        Capabilities: [140 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
                        Status: NegoPending- InProgress-
        Kernel driver in use: ath5k
        Kernel modules: ath5k
Comment 6 collura 2012-04-19 05:30:26 EDT
have had this happen few times where was actively using system and net reconnect dialogwould pop up but then wouldnt complete the reconnect.  power cycle wouldnt do it, seem to have to pull the battery as well lol.
Comment 7 collura 2012-04-19 06:22:12 EDT
Created attachment 578568 [details]
part of var log messages
Comment 8 collura 2012-04-19 06:37:57 EDT
hmm no sooner was i digging out 
  kernel-debug-3.3.1-5.fc16.x86_64 
to install than i ran across 
  kernel-3.3.2-1.fc16.x86_64 
and its associated bug:
  https://bugzilla.redhat.com/show_bug.cgi?id=810796

which description sounds eerily familair:

"Description of problem: after boot and login in the wireless network adapter
connects without any problem to the wireless network. When this connection is
interrupted (by hand or after the laptop went into hybernation), reconnecting
isn't possible. The system keeps asking for the wifi password. The only way to
connect to the network is to reboot the system.
"

so someone who has the gain issue more than my few times a month should be happy to give feedback i am guessing. :')
Comment 9 Phil V 2012-04-26 19:14:31 EDT
In my case, with updated F16, removing and reinserting the battery restores network connectivity, as reported in similar bugs from 2009, 2010, 2011:
https://bugzilla.redhat.com/show_bug.cgi?id=478395
https://bugzilla.redhat.com/show_bug.cgi?id=638943
https://bugzilla.redhat.com/show_bug.cgi?id=672778

I would consider this an unfortunate workaround, but not a fix.
Comment 10 collura 2012-05-13 00:45:20 EDT
just had this happen with an 
fc17-fullyupdated-prerelease-with-updates-testing-enabled

  kernel-3.3.4-4.fc17,x86_64
  NetworkManager-1:0.9.4.0-8.git20120502.fc17.x86_64

wpa_supplicant_log dateless snippet:
  wlan0: CTRL-EVENT-DISCONNECTED bssid=<removed> reason=4
  wlan0: Failed to initiate AP scan
  wlan0: Failed to initiate AP scan

messages snippet:

May 13 00:06:07 <removed> NetworkManager[599]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
May 13 00:06:07 <removed> NetworkManager[599]: <warn> Couldn't disconnect supplicant interface: This interface is not connected.
May 13 00:06:07 <removed> NetworkManager[599]: <info> Config: set interface ap_scan to 1
May 13 00:06:07 <removed> kernel: [  132.501220] ath5k phy0: gain calibration timeout (2452MHz)
May 13 00:06:08 <removed> kernel: [  133.012957] ath5k phy0: gain calibration timeout (2457MHz)
May 13 00:06:09 <removed> kernel: [  134.036600] net_ratelimit: 1 callbacks suppressed
Comment 11 Maksim Burnin 2012-05-13 12:25:24 EDT
This bug has disappeared after kernel update.

lspci:
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x / AR542x Wireless Network Adapter (PCI-Express) (rev 01)

Kernel: 3.3.2-6.fc16.i686

Uptime: 16 days. Running smooth since last restart.

Thanks to everyone who worked on the fix.
Comment 12 Andy Shevchenko 2012-05-14 13:39:20 EDT
Just updated mine F14 to F16. Have got this issue just within 12 hours of usage F16.

Linux localhost.localdomain 3.3.5-2.fc16.i686 #1 SMP Tue May 8 12:04:02 UTC 2012 i686 i686 i386 GNU/Linux

Laptop: Thinkpad x60s
Comment 13 Greg 2012-05-17 01:35:33 EDT
I recently upgraded to F16, and I have this problem on F16 x86_64 as well.  Has happened on all update kernels I have tried so far.

Wifi stops working, and endless "ath5k phyX: gain calibration timeout (XXXXMHz)" kernel messages start appearing.  Laptop is a Thinkpad R61.  The ath5k driver has been so bad over the years that I sure wish I had opted for the Intel wifi option for this laptop instead of the Atheros option.

Current workaround I am using is to:

   1 - rmmod ath5k ath
   2 - suspend laptop
   3 - resume laptop
   4 - modprobe ath5k
   5 - reconnect to wifi access point

This happens sometimes several times a day.  Due to some wifi problems I had with the previous distro on this laptop ("noise floor calibration timeout" messages), I suspect the problem happens in a noisy wifi environment and the driver is not handling the situation properly.

Just turning the wifi on and off, or even rmmod and modprobe of ath5k, does not help.  The wifi device has to be power cycled by suspending and resuming the laptop.

lspci -v shows:

03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)
        Subsystem: IBM ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (AR5BXB6)
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at df3f0000 (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

I'll wait a day or so to see if anyone replies here.  If not, I'll file a new bug for this issue on F16 since this bug is listed as F15 and "fedora extras", neither of which fit my situation.
Comment 14 Kieran Clancy 2012-05-17 02:28:25 EDT
I've been seeing this for a couple of months now on F16. It's very very frustrating.

I find that it reacts quite differently depending on whether I am at home or at work.

At home it usually connects by itself, although sometimes I need to switch the wireless on/off (just with the hardware rfkill.) Every so often if I leave my laptop on for a few hours and when I come back it has stopped working though.

At work it almost never connects by itself. When I resume my laptop from Suspend at work, it tries to connect but seems to get stuck somewhere. The gnome wireless indicator says "authentication required" but no login dialogue is displayed (also, I have it set to remember my password so it shouldn't need to ask me, ever.)

Not much in dmesg apart from:
ADDRCONF(NETDEV_UP): wlan0: link is not ready

/var/log/messages has a bit more from NetworkManager:
wake requested (sleeping: yes  enabled: yes)
waking up and re-enabling...
(wlan0): now managed
(wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
(wlan0): bringing up device.
[kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready]
(wlan0): preparing device.
(wlan0): deactivating device (reason 'managed') [2]
(wlan0): supplicant interface state: starting -> ready
(wlan0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] 
(wlan0): supplicant interface state: ready -> inactive
Trying to remove a non-existant call id.
Activation (wlan0) starting connection 'Auto eduroam'
(wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
(wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Activation (wlan0/wireless): access point 'Auto eduroam' has security, but secrets are required.
(wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
Activation (wlan0) Stage 2 of 5 (Device Configure) complete.

So you can see it says "secrets required" and just gives up. Is it that it failed to get the secrets over DBus or something? (Like if that process is not yet "awake" from the suspend?)

And, of course, every so often (usually at work), I will get a flood of dmesg:
[84543.918634] ath5k phy0: gain calibration timeout (2472MHz)
[84544.383483] ath5k phy0: gain calibration timeout (2462MHz)
[84658.347282] ath5k phy0: gain calibration timeout (2412MHz)
[84658.811690] ath5k phy0: gain calibration timeout (2417MHz)
[84659.275602] ath5k phy0: gain calibration timeout (2422MHz)
(usually a message every second or two).

During which time, the Wifi doesn't work at all. Very occasionally it seems to work again by toggling rfkill off and on, but usually I have to suspend (and then toggle rfkill again).

Are these two separate issues? Is someone looking at this for F16? Pinging Dave Jones (sorry if you're on holiday or something!)
Comment 15 Greg 2012-05-23 22:43:19 EDT
More evidence that this happens mainly in high-noise environments.

Neighbor (we believe who has a 2.4GHz cordless phone) has been gone lately.  No gain calibration timeout errors during this time.  Otherwise, it would happen pretty much at least once a day when I'm at home.

With the "noise floor calibration timeouts" on a previous distro, the timeouts did not lock up the wifi card every time, but degraded performance.  Those timeouts definitely only happened when the neighbor had the 2.4GHz phone off of its base station.
Comment 16 collura 2012-05-27 05:37:07 EDT
hmm so i guess the question is:

  'what is the name of the package/command 
   that allows use of the wifi card as a spectrum analyzer?'

so we can watch for spread spectrum bursts near 2.4GHz
during these gain calibration timeout occurrences?
Comment 17 collura 2012-05-30 18:51:50 EDT
possibly related:

  https://bugzilla.redhat.com/show_bug.cgi?id=814914

as has 'gain calibration timeout' in bug#814914 second attached log
Comment 18 Jirka Klimes 2012-06-04 09:11:27 EDT
It looks like there's a fix in kernel 3.4.

https://bbs.archlinux.org/viewtopic.php?pid=1084733#p1084733
http://comments.gmane.org/gmane.linux.kernel.wireless.general/86055

Try installing kernel-3.4.0-1.fc17 from testing repository.
Comment 19 Gabriele Svelto 2012-06-06 17:16:40 EDT
I'm experiencing the same problem, it started in Fedora 16 and persists on Fedora 17 with kernel 3.3.7-1. The output of lspci -vvv -nn on a machine shows this:

04:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x / AR542x Wireless Network Adapter (PCI-Express) [168c:001c] (rev 04)
	Subsystem: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01) [168c:3067]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at f0200000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ath5k
Comment 20 Josh Boyer 2012-07-11 13:53:34 EDT
Fedora 15 has reached it's end of life as of June 26, 2012.  As a result, we will not be fixing any remaining bugs found in Fedora 15.

In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with.  Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered.

Thank you for taking the time to file a report.  We hope newer versions of Fedora suit your needs.