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 2.6.32.10-90.fc12.i686.PAE #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.
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?
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.
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... https://bugzilla.kernel.org/show_bug.cgi?id=10325 https://bugzilla.kernel.org/show_bug.cgi?id=12068 https://bugzilla.kernel.org/show_bug.cgi?id=13900 https://bugzilla.kernel.org/show_bug.cgi?id=14561 https://bugzilla.kernel.org/show_bug.cgi?id=15382
That leaves the question how it comes that it works fine with Linpus Linux?
Seems like 2.6.32.11-99.fc12.i686.PAE 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.
Tried it out, just leaving the WLAN area and coming back causes "failed to wakeup the MAC chip" messages.
Similarly problem was spotted on F13 with 2.6.33.6-147 kernel.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
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?
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
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.
How does it looks for compat-wireless (see comment 11) ?
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.
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. So, kmod-compat-wireless-2.6.37-4.fc14.i686 kernel-2.6.35.10-74.fc14.i686 working for me currently. How soon will these be mainstream?
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?
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?
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.
(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.
Please test one of these packages: http://people.redhat.com/sgruszka/compat-wireless-next/