Bug 451181 - Wireless not resuming after suspend in eeePC
Summary: Wireless not resuming after suspend in eeePC
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FedoraMini, Mobility
TreeView+ depends on / blocked
Reported: 2008-06-13 08:46 UTC by Carlo Raudino
Modified: 2009-04-24 12:10 UTC (History)
13 users (show)

Fixed In Version: kernel 2.6.28
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-19 17:16:07 UTC
Type: ---

Attachments (Terms of Use)

Description Carlo Raudino 2008-06-13 08:46:04 UTC
Description of problem: With madwifi driver loaded (and wifi active), resume
from suspend results in no available connection...

Version-Release number of selected component (if applicable):
stable in fedora 9 fully updated

How reproducible:
resume from suspend

Steps to Reproduce:
1.resume from suspend
2.wait for wlan connection...nothing
Actual results:
this workaround works:

Expected results:
Wireless resuming, without tweaks or workarounds

Comment 1 Bastien Nocera 2008-06-13 18:27:27 UTC
The problem is probably with the kernel driver, but the fact that this line is
enough to make it work is weird:
ip link set wifi0 up


Comment 2 Dan Williams 2008-06-13 22:10:55 UTC
Yeah, it's probably driver related.  But, could you try to update to the latest
NetworkManager in f9-update?  It's svn3675 and it may help this issue for you. 
Please test.  If it doesn't fix the issue, I get to blame the driver, because
3675 definitely UPs the device when it comes back from sleep.

Comment 3 Carlo Raudino 2008-06-13 22:57:30 UTC
Ok, Installed the updates-testing svn3675 networkmanager, and seems to work (I
removed the workdaround script).

I leave this release in my installation. I let you know if give me any problems.

Thanks for support.

Comment 4 Carlo Raudino 2008-06-13 23:53:33 UTC
Like not said.
When resuming from suspend, networkmanager has the two little balls
rotating...but can't connect to my wlan. Asks wpa key, but isn't able to
connect.... I tried many times...nothing

To resume my connection I have to press Fn+F2 TWO TIMES
(Fn+F2 activates this script...)

PWR=$(cat /sys/devices/platform/eeepc/wlan)

UnloadModules() {
    rmmod ath_pci
    rmmod ath_rate_sample
    rmmod wlan_scan_sta
    rmmod wlan_tkip
    rmmod wlan_wep
    rmmod wlan

LoadModules() {
    modprobe ath_pci

case $1 in
        if [[ "$PWR" = "0" ]]; then
            modprobe pciehp pciehp_force=1

	    echo 1 > /sys/devices/platform/eeepc/wlan

	    rmmod pciehp

        if [[ "$PWR" = "1" ]]; then

            modprobe pciehp pciehp_force=1

            ifconfig ath0 down

            wlanconfig ath0 destroy


            echo 0 > /sys/devices/platform/eeepc/wlan

            rmmod pciehp


Pressing two times, reloads the wifi card....... after, I must right click NM
and deselect WIRELESS.... I reselect Wireless...and wifi comes back
working....my wlan connects........

1- I tried the new NM svn with my OLD and WORKING kernel + madwifi module..SAME
PROBLEM (the old kernel with "stable" NM + workaround, always did resume from

2- Now I updated wpa_supplicant from updates-testing....no change....

:-( So I leave open the bug......

Comment 5 Carlo Raudino 2008-06-14 14:50:31 UTC
I enabled the old workaround script...
WLAN=$(cat /sys/devices/platform/eeepc/wlan)

case "$1" in
if [[ "$WLAN" = "1" ]]; then
{ ip link set wifi0 up ; } 2>/dev/null
exit $?

And NM testing, with this script WORKS and connect well......

I don't understand why...

NM testing without script, no success on connect

NM "stable" widhout script, nothing...just icon with red x........

Comment 6 Carlo Raudino 2008-06-18 09:23:07 UTC
updated to svn3747 from rawhide....still not able to connect after resume...
I just run # ip link set wifi0 up

NM manages to connect to wireless......

Comment 7 Sitsofe Wheeler 2008-09-21 21:06:53 UTC
"About the rfkill switch - be careful.
The current /proc/acpi/asus/wlan implementation is actually killing the power from wireless chip - as a result we had to do a lot of hooplas with pciehp or fakephp to bring the chip up "pci-wise" after the sleep."

Comment 8 Luke Sheldrick 2008-10-03 16:07:37 UTC
Just to note, am using Rawhide 9.91, and would appear to still be showing these symptoms on my eee 701. Using NM 1:0.7.0-0.11.svn4022.4

Comment 9 Carlo Raudino 2008-11-26 08:36:45 UTC
I made a fresh install of Fedora 10..

Wireless is unable to resume after suspend...just using the stock ath5k driver.. I have to reboot my eeepc...

Comment 10 Andras Simon 2008-12-01 15:44:00 UTC
Exactly the same here on an Eee Pc 701, with F10. The ath5k driver works until I suspend/resume. After resuming, the connection is lost and I see the following in /var/log/messages

Dec  1 16:14:09 localhost kernel: ath5k phy0: failed to wakeup the MAC Chip
Dec  1 16:14:09 localhost kernel: ath5k phy0: unable to reset hardware: -5

Are there any more details I should provide?

(I'd be interested in ugly workarounds, too. madwifi also fails on resume, but with different messages.)

Comment 11 Valent Turkovic 2008-12-06 10:06:55 UTC
I have Fedora 10 installed on eee 701 and have the same issue:

ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: unable to reset hardware: -5

If you need some additional feedback please let me know.

Comment 12 Dan Williams 2008-12-09 17:16:45 UTC
(In reply to comment #11)
> I have Fedora 10 installed on eee 701 and have the same issue:
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: unable to reset hardware: -5
> If you need some additional feedback please let me know.

This is a kernel bug, and too have seen it with current kernels and the ar2425 chip.  Can you report the following?

dmesg | grep ath5k

Comment 13 Christof Damian 2008-12-09 20:24:19 UTC
For me it was enough to put:

modprobe eeepc-laptop
modprobe pciehp pciehp_force=1 

into /etc/rc.local of my EeePC 901 and reboot. Though I think the second line might be enough.

Comment 14 Valent Turkovic 2008-12-18 23:35:25 UTC
# dmesg |grep ath5k
ath5k_pci 0000:01:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ath5k_pci 0000:01:00.0: setting latency timer to 64
ath5k_pci 0000:01:00.0: registered as 'phy0'
ath5k phy0: Support for RF2425 is under development.
ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)

Comment 15 Valent Turkovic 2008-12-19 08:39:34 UTC
after adding lines as suggested per comment #13 my asus eee 701 doesn't freezes on suspend and I can only force power off.

So this method doesn't work for 701 because 901 and 701 don't have same hardware.

for which eee is this bug reported for?!? The title is really not clear and sould be made clear. There are lots of asus eee netbooks not and when not mentioning the model it is usually implied that it is the first eee - model 701.

Please make this clear.

Comment 16 Valent Turkovic 2009-01-05 15:06:20 UTC
are there any news regarding this bug? Is there anyway I and other eee 701 users can help fix this issue?

Comment 17 BK 2009-01-05 16:07:56 UTC
I have the exact same issue as #10 on my Eee 900 using a fully updated Fedora 10 using the ath5k driver.

The really interesting thing is that on a fully updated Fedora 9, suspend/resume using ath5k works just fine, and have done so since the kernel update that included the updated ath5k driver. This was before the F10 release, but prior to the F9 kernel update, I used the F10 kernel from rawhide and it had the same issue with resume.

Just yesterday, I even tried making a Fedora 9 LiveUSB stick updated to use the latest kernel, and even when booting from this, the Eee 900 resumes and reconnects correctly.

So clearly, something changed between Fedora 9 and Fedora 10 that causes the ath5k driver to be unable to resume on the latter, and it appears to me that it's specifically a difference in the kernel.

Comment 18 BK 2009-01-05 16:53:53 UTC
In a moment of "Duh! Why didn't  try this before??", I tried installing the F9 kernel (kernel- on my F10-running Eee 900 right after posting my previous comment.

Running this kernel, I could successfully reconnect to the wireless after a suspend/resume cycle.

Running with this kernel has other issues, however, such as requiring a bit of jiggling to get the screen to come back, so it's not a real solution.

It does, however, show that whatever the problem is, it's related to whatever the difference is in configuration/patches between kernel- and kernel-

Comment 19 Sitsofe Wheeler 2009-01-05 18:53:51 UTC
This is working for me with a hand compiled 2.6.28...

Comment 20 Valent Turkovic 2009-01-19 16:48:32 UTC
What do you recommend eee users do? Compile by hand 2.6.28 kernel? Wait for fix in 2.6.27 or something else?

Comment 21 Carlo Raudino 2009-01-19 17:16:07 UTC
I installed the kernel-2.6.28-3.fc10 package from koji and now eeepc 701 wireless resume works perfectly.

Now eeepc 701 is fully supported by fedora without any tweaks.

Thankyou all!

@20 you should try to install manually a 2.6.28 kernel from koji, or just wait the update push....

For me this kernel is working perfectly and eeepc boot is very fast.

Comment 22 Carlo Raudino 2009-01-19 17:17:57 UTC
sorry, I mean kernel-2.6.28-4.fc10   not 3 :-)


Comment 23 Andras Simon 2009-01-21 10:35:45 UTC
(In reply to comment #21)
> I installed the kernel-2.6.28-3.fc10 package from koji and now eeepc 701
> wireless resume works perfectly.

Indeed! Thanks!

Comment 24 Dan Williams 2009-04-23 20:07:28 UTC
As a follow-up for those of you who are running 2.6.27 F-10 kernels since nothing later than 2.6.27 has been pushed to F10 officially yet...

The problem is that since the eeepc wifi cards are PCI-E, and since they are actually *hotplugged* by the BIOS on suspend and rfkill, you need to enable PCI-E hotplug support so the kernel can figure out that the card actually came back.  This has been made substantially better in 2.6.28 and later.

The pciehp module appears to prevent suspend while loaded though, so it needs to be removed at before suspend, and added back on resume.  When you modprobe pciehp, the wifi card will magically be re-detected.

But on 2.6.27 you can work around this with pm-utils scripts.  Put the following into /etc/pm-utils/sleep.d/75Atheros and make it executable and owned by root:



        rmmod pciehp

        modprobe pciehp

case "$1" in
        *) exit $NA

Comment 25 Miroslav Lichvar 2009-04-24 12:10:47 UTC
Thanks for the workaround. On a EeePC 701 I have to rmmod/modprobe also the eeepc_laptop module, otherwise there would be only the "failed to wakeup the MAC Chip" message.

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