Bug 578607 - ATH5K driver fails to wake up hardware
Summary: ATH5K driver fails to wake up hardware
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Stanislaw Gruszka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-03-31 19:12 UTC by andreas
Modified: 2011-12-26 11:10 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-12-26 11:10:51 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Launchpad 432353 0 None None None Never
Linux Kernel 15382 0 None None None Never

Description andreas 2010-03-31 19:12:54 UTC
Description of problem:
Usually after waking up from sleep, the laptop fails to wake up the WLAN hardware on an Acer One A110 (8GB flash Linux version)

Version-Release number of selected component (if applicable):
Linux acerone.kostyrka.org #1 SMP Tue Mar 23 10:04:28 UTC 2010 i686 i686 i386 GNU/Linux

How reproducible:
Wait till the netbook suspends, reactivate. Wait till NetManager prompts you for the WLAN key because it cannot connect to the WLAN anymore.

Additional info:

Kernel log during initial detection:
Mar 31 14:10:28 acerone kernel: ath5k 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Mar 31 14:10:28 acerone kernel: ath5k 0000:03:00.0: registered as 'phy0'
Mar 31 14:10:28 acerone kernel: Registered led device: ath5k-phy0::rx
Mar 31 14:10:28 acerone kernel: Registered led device: ath5k-phy0::tx
Mar 31 14:10:28 acerone kernel: ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)

Kernel log after encountering the problem:

Mar 31 14:24:12 acerone kernel: ath5k phy0: failed to wakeup the MAC Chip
Mar 31 14:24:12 acerone kernel: ath5k phy0: can't reset hardware (-5)
Mar 31 14:24:51 acerone kernel: ath5k phy0: failed to wakeup the MAC Chip
Mar 31 14:24:51 acerone kernel: ath5k phy0: can't reset hardware (-5)
(and so on)

Partial Work around:
For infrastructure WLANs the broadcom-wl driver works mostly reliably; it does not work really reliable for adhoc wlans.

Comment 1 John W. Linville 2010-03-31 19:44:48 UTC
I have to admit, I'm awfully curious how the broadcom-wl driver has anything to do with an ath5k problem... :-)

Nick, any thoughts on how to debug this phy reset issue?

Comment 2 andreas 2010-03-31 21:21:52 UTC
My fault, I've installed the recommended kmod-wl on the Acer One wiki page, without checking that it got used.

The symptoms also seemed to get better, but at a second thought that might because I've not suspended even once :)

Sorry, for confusion.

Comment 3 Nick Kossifidis 2010-04-01 13:48:56 UTC
It's the classic problem with AR2425 chips when their host interface unit (HIU) hangs, we have too many bug reports about this issue but it's not easy to debug since it seems it's also related to the pci subsystem eg. in my laptop using a mini-pcie to expresscard adapter i couldn't reproduce this behaviour (i'm using an AR2425 that came with an eeepc) + other netbooks with AR2425 are known to work fine (eeepc included, check out https://bugzilla.redhat.com/show_bug.cgi?id=451181).

Here are some of the bug reports...

Comment 4 andreas 2010-04-02 09:12:35 UTC
That leaves the question how it comes that it works fine with Linpus Linux?

Comment 5 andreas 2010-04-15 15:52:47 UTC
Seems like is way more reliable on Acer Ones during normal operation. (Seems like, because it has has worked reliable on two days for a couple hours)

Using an Adhoc connection still dies rather quickly.

After suspension it still does not work.

Comment 6 andreas 2010-04-15 18:50:03 UTC
Tried it out, just leaving the WLAN area and coming back causes "failed to wakeup the MAC chip" messages.

Comment 7 Tommy He 2010-08-07 10:20:10 UTC
Similarly problem was spotted on F13 with kernel.

Comment 8 Bug Zapper 2010-11-03 18:10:26 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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: 

Comment 9 Bug Zapper 2010-12-03 16:31:13 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 10 Tommy He 2010-12-23 08:39:24 UTC
The problem still persist on Fedora 14 with latest kernel from repo.

Even changing the charging status will cause WiFi connection lost(i.e plug in the AC adapter).

Someone please re-open this bug please?

Comment 11 Stanislaw Gruszka 2011-01-24 14:02:24 UTC
Is something better on current upstream? You can test current upstream drivers on Fedora using compat-wireless http://people.redhat.com/sgruszka/compact_wireless.html

Comment 12 cam 2011-02-03 19:58:54 UTC
I have a long suffering Acer Aspire one user with this problem, currently on F13. I will upgrade to F14 and reproduce the problem.

It is an odd problem in that the hardware once locked up, will not recover unless there is a hard reset / power cycle. I know it's oldish hardware but even a manual workaround to reset the hardware somehow would be welcome.

Comment 13 Stanislaw Gruszka 2011-02-04 06:59:21 UTC
How does it looks for compat-wireless (see comment 11) ?

Comment 14 cam 2011-02-04 12:31:35 UTC
Stanislaw, thanks for the comment. I have updated the machine in question to F14 and after a few hours the bug is reproduced. It seems the behaviour is unchanged.

Tonight I will try to get the upstream drivers you mention tested, I will report back.

Comment 15 cam 2011-02-05 12:06:51 UTC
Hello, I'm please to report, I have been trying the compat-wireless drivers for a while, and have had over 10 hours of trouble free operation.

I checked the logs and with the old drivers I saw lockups every few hours at least, so I think this is either a cure or it has made the lockups a lot less frequent. I will report if we have any more problems but I haven't seen any yet.



working for me currently.

How soon will these be mainstream?

Comment 16 Stanislaw Gruszka 2011-02-08 14:39:37 UTC
Fedora 15 will have these fixes. I will not backport them to F-14, since I don't know what commits fix the problem. You can use compat-wireless for now. Hopefully, I will update that packages regularly, soon they should be available by yum.

Tommy He, any info from you?

Comment 17 cam 2011-02-08 15:10:08 UTC
A quick update, I have seen the problem reproduce twice with fairly extensive testing. I have logs that look like they used to for the failure before compat-wireless. This is quite a bit better than the problem used to be (failing once every several hours instead of every hour)

So compat-wireless is not a complete fix for this issue.

I will have further chances to debug this, is there any extra logging I can enable, or diagnostic procedures to follow when the failure happens?

Comment 18 Stanislaw Gruszka 2011-02-09 17:00:53 UTC
There is debug ath5k module parameter, which enable verbose logging and generate lots of messages.

Before debugging however, let's first check current upstream code (from wireless-next), there are some patches that could possibly help with problem. I will soon have compat-wireless package prepared, but if you want to test code faster, you can compile beading edge compat-wireless from source.

Comment 19 Tommy He 2011-02-10 15:29:57 UTC
(In reply to comment #16)
> Fedora 15 will have these fixes. I will not backport them to F-14, since I
> don't know what commits fix the problem. You can use compat-wireless for now.
> Hopefully, I will update that packages regularly, soon they should be available
> by yum.
> Tommy He, any info from you?

I will test the compact-wireless this weekend. The one with ath5k is not accessible during weekdays for me.

Comment 20 Stanislaw Gruszka 2011-02-11 13:56:33 UTC
Please test one of these packages:

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