madwifi-ng fails to work after suspend/resume

Oh, this is with a 5212:

wifi0: Atheros 5212: mem=0xd0200000, irq=11

i've changed the suspend/resume code a bit (quick & dirty). At least on my machine the driver works much better after suspend...

#195 is probably related.

Thanks, that patch seems to have fixed it :)

A question regarding the patch: why did you comment out the ath_init(dev) call in ath_resume() and the ath_stop(dev) call in ath_shutdown()? Did you check for unwanted side effects?

In addition, I'd like to keep the if (...); around line 242 in ath/if_ath_pci.c, just to document what the /* XXX: what? */ is actually referring to.

No, i just commented this out because with this wireless isn't working after suspend/resume. i guess the proper way is to investigate *why* this doesn't work, but i hadn't time for this. we could also add the if(...)); , but i have no idea whats the advantage of using this construct...

The advantage is that it's more obvious that the "what?" is short for "what should be done in case this command fails?".

Could you please update your patch accordingly (and maybe add a comment explaining why the ath_stop(dev)/ath_init(dev) has been commented out and refering to this ticket) and sign it off?

Does anyone notice any obvious negative side-effects after this patch has been applied?

No objections, so I'll commit the patch as soon as it has been signed off.

signed patch

Please test madwifi-suspend-signed2.patch, if it works i'll commit it. That should be a proper solution.

I don't have time for a more comprehensive test at the moment, but after coming home from work and unsuspending my laptop, I couldn't connect to my access point until I rebooted..

Sorry for the delay.. I tested again and it definitely seems that I am unable to connect to my AP after suspend with this patch unless I remove and reload the driver.

Same problem here with a 5211 in a thinkpad. Madwifi-ng only works after reloading the driver. The old code (cvs-import) does not have this problem.

Remove and reload the driver is a temporary fix for me, although a little ugly.

ifdown ath0
/usr/local/bin/wlanconfig ath0 destroy
madwifi=`lsmod | grep wlan | awk '{print $4}'|grep -v "^$" | tr "," " "`
for i in $madwifi; do modprobe -r $i; done

I went back to using a modified version of the original patch, since the latest one doesn't work. I presume the problem is with the ath_stop/ath_init calls (which, as discussed above, are commented out in the initial patch) but I don't have the time/know-how to figure out what specifically is breaking there..

I'v tested the latests patch (with some modifications to make it apply) on top of yesterdays snapshot and it didn't fix the problem for me :( Is there an updated patch somewhere to fix this problem?

I did some basic troubleshooting with Madwifi-ng revision 1538 in STA mode, using both plain and WPA2 mode. After suspending and resuming, the connectivity is lost.

Doing:

iwlist ath0 scan

ath0 Interface doesn't support scanning.

After doing:

ifconfig ath0 down
ifconfig ath0 up

The scanning continues and association resumes. So, suspending and resuming with recent revision is a bit improved because you don't have to delete the VAP. Does this help fixing this ticket?

I have a DWL-G650 card (Atheros 5212) and have encountered the same problem. I have not been able to find any solution to this problem and hence am submitting it here.

My setup is as follows:

Compaq 1530D Laptop with Pentium MMX 133MHz having two PCMCIA slots controlled by TI PCI1131. Running current release DamnSmallLinux? 2.3 with a 2.4.26 Linux Kernel.

The Madwifi drivers supplied with DSL would not work so I downloaded the Madwifi-ng drivers for DSL. After installation, everything worked fine until I found that on issuing the command "ifconfig ath0 up" and then trying to scan for APs, nothing would come up. The link light on the card would not flash and the message in dmesg output would be:

wifi0: Atheros 5212: mem=0x10c00000, irq=11 wifi0:unable to reset hardware: (HAL status 4294967295) (freq 2412 flags 0xa0)

Everytime I would bring ath0 down and then up again, I would get the same message.

I first thought this might be a problem with the Cardbus manager as I was not getting a beep on card insertion and the ACT light on the card would flash twice and freeze. I did a step-by-step load of cardmgr and after loading yenta_socket and checking dmesg, I though I might be getting an interrupt conflict on startup:

IRQ routing conflict for 00:11.1, have irq 11 want irq 15,

but yenta_socket appeared to resolve this for the two controllers:

Yenta ISA IRQ mask 0x6f8, PCI irq15 Socket status: 30000006 Yenta ISA IRQ mask 0x6f8, PCI irq11 Socket status: 30000006

I found that a cardctl reset command would get the ACT light flashing again. ifconfig and iwcnofig output also showed ath0 correctly. I have been unable to progress further.

I have the same problem. I've got an older Sony Vaio PCG-Z505JSK, w/ FC5, and all the latest kernels. I'm currently using kmod-madwifi-0.9.0-1.2.6.17_1.2145_FC5 w/ the matching kernel, but this problem has been going on for a while now. I have a netgear WG511T pc card. After resuming from suspend or hibernate, the module doesn't work (one light stays on permanently on the card, instead of the usual two blinking lights). Restarting the network doesn't help; ifdown/ifup doesn't help. Only thing that helps is unloading the module and reloading it. I'll be happy to provide you w/ more info about my system, just let me know what. Thanks.

Same here with "Atheros Communications, Inc. Ar5212 802.11abg NIC" (mini express in Lenovo Laptop).

After resuming from suspend wifi doesn't work anymore. I also have problems without suspending but I don't know if they're related.

Me too. I have to do (as root):

rmmod ath_pci modprobe ath_pci

in order to make it work

Still a problem with kmod-madwifi-0.9.0-1.2.6.17_1.2157_FC5 on my DWL-G630 and HP Omnibook 6000

Had the same problem. "Atheros Communications, Inc. Ar5212 802.11abg NIC" (mini express in Lenovo Laptop) suspends nicely, resumes nicely, but in 50% (10%) of the cases, after resuming from ram (or disk) it does not connect to the router, even after "rmmod ath_pci modprobe ath_pci". I tried to unload the driver by hand, before suspending.... but nothing worked.

This was when I loaded the wlan card automatically at startup or hotplug. Changing t0 "manual" (Opensuse 10.1, KDE, Kinternet) solved the problem for me.

Still this is a bug, but less disturbing (for me).

We are aware that suspending still does not work as intended, which is also stated in the release notes of 0.9.2, for example. However, it's no top priority problem at this time, but it will get addressed at some point.

Suspend to RAM works correctly with the latest release right now. I don't know what patch did the fix. Could you confirm this?

Probably the patch from #671 improved it.

I can't confirm this. Without unloading the modules first, madwifi does not scan and the LED on my T40p does not blink after a suspend to RAM. At least for me nothing has changed compared to previous versions.

I also cannot confirm this, /me thinks resumption is not quite right yet.

It seems to work on my hardware, although the connection is reset in the process (but I guess this is a problem for userspace).

Here are my results of a suspend to RAM (S3):

[root@host Desktop]# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.19 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.22 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.24 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.24 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.24 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.18 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.19 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.19 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=1.29 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=1.12 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=1.13 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=1.13 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=1.13 ms

--- 192.168.1.1 ping statistics ---
30 packets transmitted, 18 received, 40% packet loss, time 43548ms
rtt min/avg/max/mdev = 1.129/1.198/1.294/0.052 ms

wpa_supplicant reassociates to the AP at icmp_seq=26. I'm not roaming, I suspend and resume on the same location.

I'm using 2.6.17.9 kernel.

Still not working for me. I use svn latest version 1747 kernel 2.6.18-1.2189.fc5 and a Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) on my Thinkpad X40. Suspend work but after resume I need to run modprobe -r ath_pci && modprobe ath_pci

I have a 06:00.0 Ethernet controller: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 02) PcCardBus? card, and I use suspend2 with all my kernels. I've used several in the past year, and always I had to remove the ath_pci module before suspend and add it after resume.

Workaround (on FC5 and on my T41 Thinkpad):
Create /etc/acpi/events/thinkpad-resume.conf as

event=processor CPU 00000081
action=/etc/acpi/actions/resume.sh

and /etc/acpi/actions/resume.sh as

rmmod ath_pci && modprobe ath_pci
/etc/init.d/NetworkManager restart

The latter one needs execute permissions as well. (chmod u+x etc/acpi/actions/resume.sh)
Then restart acpid as /etc/init.d/acpid restart

hi.

running 1799 on a thinkpad T41p. i think we'll finally get that fixed.

i've gone through the driver source. enabled debugging, tried the patch above, etc. found it hard to identify any problems, apart from the fact that it doesn't work any longer after resume.

[btw: if you're planning to complain about lost vap state, check your distro first. many ifupdown interfaces or even blacklist drivers. so, if 'iwconfig' doesn't show interface settings as they used before suspend, it's probably some script gone wild on your network setup in the first line, not necessarily the driver source.]

after resume:

outgoing packets go through hard_start_xmit() without any errors. though, a promiscuous remote target interface doesn't show any packets .. but errors: Rx invalid crypt incrementing.

the key shown in iwconfig is derived from driver memory, not device state. a single refresh operation of the orginal key resolves the encryption errors, and gets the link to work.

1. so could someone familiar with the driver please rewrite ath_initkeytable() as it used to be? i've found a version from late 2004, but the codebase obviously changed a litte. the outcommented reference can still be found in if_ath.c:ath_init(). yes, still needed.

2. as far as as i can tell on my t41p, ath_reset() as suggested by the first patch seems otherwise perfectly sufficient.

very kind regards, daniel

signed off

Replying to nagyga1@gmail.com:

Workaround (on FC5 and on my T41 Thinkpad):
Create /etc/acpi/events/thinkpad-resume.conf as {{{ event=processor CPU 00000081 action=/etc/acpi/actions/resume.sh }}} and /etc/acpi/actions/resume.sh as {{{ rmmod ath_pci && modprobe ath_pci /etc/init.d/NetworkManager restart }}} The latter one needs execute permissions as well. (chmod u+x etc/acpi/actions/resume.sh)
Then restart acpid as /etc/init.d/acpid restart

Thanks! This one works great on my IBM T42 / SUSE 10.1 !

Hum, this only restores the WEP keys. Should we not also handle the keys of other kinds (WPA/RSN)?

What's the status of this bug? I still have a fair bit of trouble with madwifi when resuming. This is 0.9.3 on a Lenovo T60p. I'm running Debian and the kernel version doesn't matter - the problem shows up on every kernel I've ever tried.

Basically, I often need to remove and reinsert ath_pci after resume to get it to associate. Sometimes multiple remove/reinsert cycles are required. I think the problem might be worse when I try to connect using LEAP at work and then connect to my open router at home.

Suspend/resume is still an issue in v0.9.3, which is also listed as "known issue" for the release, see here.

Replying to mrenzmann:

Suspend/resume is still an issue in v0.9.3, which is also listed as "known issue" for the release, see here.

Sorry, I was aware that it was still outstanding. I was trying to ask how work was going on this issue and whether I could provide assistance in squashing it. I hadn't seen traffic related to this ticket on the mailing lists.

To the best of my knowledge there is currently no work spent on this issue, but I might be wrong. I fear I won't find the time for that during the next weeks, so if someone else would like to look at it, please feel free.

Just a reminder. It is still a known issue even in 0.9.5 .

modprobe -r ath_pci && modprobe ath_pci is still the solution for my R61

03:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

This has been a problem for me for quite some time. I am currently using r3101. I keep an eye on the madwifi-cvs list and have not seen anything to address this so I assume I will not have luck with the latest code.

Thinkpad t60 8744-5bu

03:00.0 0280: 168c:0024 (rev 01) 03:00.0 Network controller: Atheros Communications, Inc. AR5418 802.11a/b/g/n Wireless PCI Express Adapter (rev 01)

Kernel 2.6.22(Ubuntu Gutsy)

I am willing to be a tester if someone else has the know-how to work on this.

When I use r3878 on Ubuntu Intrepid, it fails to work after resume. HOWEVER, after reloading the driver, it works perfectly fine. I created a script that runs after resuming and wireless works just like normal. The script is only:

modprobe -r ath_pci modprobe ath_pci

I'm using a D-Link 1330, and ubuntu has all updates as of Jan 14 2009.

Any new info on if this is being worked on? Would have thought it would have been corrected in 4 years...