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: http://fedoraproject.org/wiki/EeePc#Wireless_resume_from_suspend_fix Expected results: Wireless resuming, without tweaks or workarounds
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.