Bug 839365 - ath5k gain calibration timeout
ath5k gain calibration timeout
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
wireless first=2.6.34 tested=3.3.8
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-11 14:08 EDT by Greg
Modified: 2012-08-18 01:21 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 638943
Environment:
Last Closed: 2012-08-18 01:21:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Greg 2012-07-11 14:08:14 EDT
+++ This bug was initially created as a clone of Bug #638943 +++

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)

--- Additional comment from triage@lists.fedoraproject.org on 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

--- Additional comment from julian.fedora@googlemail.com on 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?

--- Additional comment from julian.fedora@googlemail.com on 2011-06-06 09:11:25 EDT ---

Created attachment 503216 [details]
dmesg since suspend

--- Additional comment from clancy.kieran+redhat@gmail.com on 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

--- Additional comment from bugzilla.redhat.com@peterjanes.ca on 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

--- Additional comment from collura@ieee.org on 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.

--- Additional comment from collura@ieee.org on 2012-04-19 06:22:12 EDT ---

Created attachment 578568 [details]
part of var log messages

--- Additional comment from collura@ieee.org on 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. :')

--- Additional comment from pv.bugzilla@gmail.com on 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.

--- Additional comment from collura@ieee.org on 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

--- Additional comment from maksim.burnin@gmail.com on 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.

--- Additional comment from andy.shevchenko@gmail.com on 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

--- Additional comment from greg.beeley@lightsys.org on 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.

--- Additional comment from clancy.kieran+redhat@gmail.com on 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!)

--- Additional comment from greg.beeley@lightsys.org on 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.

--- Additional comment from collura@ieee.org on 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?

--- Additional comment from collura@ieee.org on 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

--- Additional comment from jklimes@redhat.com on 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.

--- Additional comment from gabriele.svelto@gmail.com on 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

--- Additional comment from jwboyer@redhat.com on 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.
Comment 1 Greg 2012-07-11 14:09:54 EDT
I could not re-open the bug, so I cloned it.  There are plenty of reports in the comments section of this bug indicating that it *is* happening with F16 and F17.  I can personally confirm that this continues to happen on F16.
Comment 2 Josh Boyer 2012-07-11 14:13:53 EDT
(In reply to comment #1)
> I could not re-open the bug, so I cloned it.  There are plenty of reports in
> the comments section of this bug indicating that it *is* happening with F16
> and F17.  I can personally confirm that this continues to happen on F16.

With what kernel version?  As noted in the original bug, there is supposedly a fix in the 3.4 kernel, which all Fedora versions are on now.
Comment 3 Greg 2012-07-11 14:28:26 EDT
You're right Josh - I'm still on 3.3.8 at the moment.  If that does fix this bug, that would be *wonderful*.  I should be able to update this afternoon, and will report back in about a week whether or not I've had this issue come back up again.
Comment 4 Justin M. Forbes 2012-08-17 13:06:08 EDT
Any update on this? It has been a while.  Is it fixed in the current release?
Comment 5 Kieran Clancy 2012-08-17 13:14:55 EDT
I haven't had nearly as many wifi problems since recent updates.

I still occasionally need to toggle the rfkill to get it to connect, but I think that might be a different problem because it's not giving the same messages as before.

Thanks to anyone who has contributed to the stability of the wifi in recent updates.

Maybe wait a couple of days for other people to say if they still have the problem, then close it. If my other wifi problems become regular enough I'll file a new report.
Comment 6 Greg 2012-08-17 15:40:32 EDT
I have not had this issue recur since the 3.4.x kernel update.  This fix is very much appreciated!

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