Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #201 (new defect)

Opened 14 years ago

Last modified 10 years ago

madwifi-ng fails to work after suspend/resume

Reported by: radsaq@gmail.com Assigned to:
Priority: major Milestone: version 1.0.0 - first stable release
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

Using svn revision 1347 under Linux 2.6.15-rc4-ck1, the driver fails to work after a suspend/resume cycle. After trying to bring up the ath0 interface (in station mode), I get:

wifi0: unable to reset hardware: '' (HAL status 2671361) (freq 2412 flags 0xa0)
wifi0: ath_chan_set: unable to reset channel 6 (2437Mhz) flags 0xa0 '' (HAL status 2953921758)
wifi0: ath_chan_set: unable to reset channel 11 (2462Mhz) flags 0xa0 '' (HAL status 2953921758)
wifi0: ath_chan_set: unable to reset channel 7 (2442Mhz) flags 0xa0 '' (HAL status 2953921758)
[..lots more like this until I destroy the ath0 device..]

Trying to subsequently unload/reload ath_pci results in:

ACPI: PCI interrupt for device 0000:01:0d.0 disabled
ath_pci: driver unloaded
ath_pci: 0.9.4.5 (Atheros/multi-bss)
ACPI: PCI Interrupt 0000:01:0d.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
wifi%d: unable to attach hardware: 'Hardware didn't respond as expected' (HAL status 3)
ACPI: PCI interrupt for device 0000:01:0d.0 disabled

Attachments

madwifi-suspend.patch (2.2 kB) - added by svens@gmx.de on 12/06/05 20:54:13.
madwifi-suspend-signed.patch (2.3 kB) - added by svens@gmx.de on 12/15/05 08:55:23.
signed patch
madwifi-suspend-signed2.patch (2.2 kB) - added by svens on 12/19/05 23:18:04.
madwifi-suspend-initkeytable.diff (1.8 kB) - added by dns@somacoma.net on 11/19/06 12:05:42.
madwifi-suspend-initkeytable.2.diff (2.5 kB) - added by dns@somacoma.net on 11/19/06 15:30:45.
signed off

Change History

12/02/05 00:40:22 changed by radsaq@gmail.com

Oh, this is with a 5212:

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

12/02/05 08:47:16 changed by mrenzmann

  • priority changed from major to minor.
  • milestone changed from version 0.9.0 - move to new codebase to version 1.0.0 - first stable release.

12/06/05 20:54:13 changed by svens@gmx.de

  • attachment madwifi-suspend.patch added.

12/06/05 20:56:00 changed by anonymous

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

12/07/05 07:49:35 changed by mrenzmann

#195 is probably related.

12/08/05 15:13:06 changed by radsaq@gmail.com

Thanks, that patch seems to have fixed it :)

12/08/05 17:59:39 changed by mrenzmann

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.

12/08/05 18:03:26 changed by svens@gmx.de

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

12/08/05 18:16:31 changed by mrenzmann

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?

12/15/05 08:25:48 changed by mrenzmann

  • status changed from new to assigned.
  • owner set to mrenzmann.

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

12/15/05 08:55:23 changed by svens@gmx.de

  • attachment madwifi-suspend-signed.patch added.

signed patch

12/19/05 23:18:04 changed by svens

  • attachment madwifi-suspend-signed2.patch added.

12/19/05 23:26:25 changed by svens

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

12/21/05 00:07:14 changed by radsaq@gmail.com

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

12/28/05 16:08:24 changed by radsaq@gmail.com

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.

01/22/06 10:34:55 changed by madwifi@jako.ping.de

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.

01/22/06 16:00:22 changed by runge@web.de

  • priority changed from minor to major.

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

01/22/06 16:10:49 changed by radsaq@gmail.com

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

02/01/06 07:47:12 changed by kelmo

  • patch_attached set to 1.

02/02/06 14:22:06 changed by cthiel@suse.de

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?

05/12/06 08:28:00 changed by Charles Bovy

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?

05/20/06 15:28:20 changed by mkeswani@hotmail.com

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.

07/09/06 16:12:15 changed by ezk@cs.sunysb.edu

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.

07/14/06 21:23:11 changed by supermihi@web.de

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.

07/18/06 19:47:02 changed by anonymous

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

rmmod ath_pci modprobe ath_pci

in order to make it work

07/21/06 19:24:24 changed by pwaldenlinux@pacbell.net

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

07/27/06 21:55:06 changed by Eckart

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

07/28/06 06:32:05 changed by mrenzmann

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.

08/25/06 09:49:24 changed by charles @ bovy.nl

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

08/26/06 00:12:18 changed by kelmo

Probably the patch from #671 improved it.

08/26/06 13:41:57 changed by madwifi@jako.ping.de

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.

08/27/06 14:25:50 changed by kelmo

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

08/27/06 16:05:22 changed by radsaq@gmail.com

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

08/28/06 19:43:17 changed by anonymous

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.

10/07/06 02:36:58 changed by Giuseppe.Castagna@ens.fr

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

10/18/06 03:42:34 changed by Damjan

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.

(follow-up: ↓ 36 ) 10/22/06 15:30:47 changed by 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

11/15/06 05:07:24 changed by dns@somacoma.net

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

11/19/06 12:05:42 changed by dns@somacoma.net

  • attachment madwifi-suspend-initkeytable.diff added.

11/19/06 15:30:45 changed by dns@somacoma.net

  • attachment madwifi-suspend-initkeytable.2.diff added.

signed off

(in reply to: ↑ 34 ) 03/17/07 00:43:03 changed by anonymous

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 !

03/20/07 03:31:59 changed by mentor

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

05/16/07 04:12:56 changed by jlquinn@optonline.net

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.

(follow-up: ↓ 40 ) 05/16/07 06:49:53 changed by mrenzmann

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

(in reply to: ↑ 39 ) 05/25/07 19:19:45 changed by anonymous

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.

05/26/07 08:28:47 changed by mrenzmann

  • status changed from assigned to new.
  • owner deleted.

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.

03/04/08 10:42:06 changed by nbrouard

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)

03/20/08 18:20:15 changed by Erik Meitner <erik@wanderings.us>

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.

01/15/09 04:26:17 changed by holt.r94+mad@gmail.com

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.

08/11/09 06:01:10 changed by Biggen

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