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

Dan?

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.

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.

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...)
______________________________________________________
#!/bin/bash

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
    poweron)
        if [[ "$PWR" = "0" ]]; then
            modprobe pciehp pciehp_force=1

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

	    rmmod pciehp

        fi
        ;;
           
    poweroff)
        if [[ "$PWR" = "1" ]]; then

            modprobe pciehp pciehp_force=1

            ifconfig ath0 down

            wlanconfig ath0 destroy

            UnloadModules

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

            rmmod pciehp

        fi
        ;;
esac
______________________________________________________________

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
suspend)

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


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

I enabled the old workaround script...
______________________________________________
#!/bin/sh
WLAN=$(cat /sys/devices/platform/eeepc/wlan)

case "$1" in
thaw|resume)
if [[ "$WLAN" = "1" ]]; then
{ ip link set wifi0 up ; } 2>/dev/null
fi
;;
*)
;;
esac
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........

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......

"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."

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

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...

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.)

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.

(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

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.

# 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)

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.

are there any news regarding this bug? Is there anyway I and other eee 701 users can help fix this issue?

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.

In a moment of "Duh! Why didn't  try this before??", I tried installing the F9 kernel (kernel-2.6.27.9-73.fc9.i686.rpm) 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-2.6.27.9-159.fc10.i686 and kernel-2.6.27.9-73.fc9.i686.

This is working for me with a hand compiled 2.6.28...

What do you recommend eee users do? Compile by hand 2.6.28 kernel? Wait for fix in 2.6.27 or something else?

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.

sorry, I mean kernel-2.6.28-4.fc10   not 3 :-)

http://koji.fedoraproject.org/koji/buildinfo?buildID=78384

(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!

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:

#!/bin/sh

. "${PM_FUNCTIONS}"

suspend_ath()
{
        rmmod pciehp
}

resume_ath()
{
        modprobe pciehp
}

case "$1" in
        hibernate|suspend)
                suspend_ath
                ;;
        thaw|resume)
                resume_ath
                ;;
        *) exit $NA
                ;;
esac

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.