ath_pci must be reloaded after resume

Bug #275692 reported by computx on 2008-09-29
310
This bug affects 27 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Undecided
Unassigned
linux-backports-modules-2.6.27 (Ubuntu)
Undecided
Unassigned
linux-restricted-modules (Ubuntu)
Medium
Unassigned

Bug Description

On a fresh install of intrepid after resume from standby I have no network connection on my atheros ar5212 wifi card.
If I remove and reload the ath_pci module then restart networking it works fine.
Output of dmesg is attached,
This is a thinkpad t42 laptop
Kernel is 2.6.27-4-generic #1 SMP Wed Sep 24 01:30:51 UTC 2008 i686 GNU/Linux
Happy to supply any further info needed.

== Workaround (if you want to continue using the proprietary ath_pci dirver) ==
create a file /etc/pm/config.d/madwifi containing the single line:

   SUSPEND_MODULES=ath_pci

== Fix (if you want to use the free ath5k/ath9k driver) ==
install linux-backports-modules-intrepid

computx (afleak) wrote :
computx (afleak) wrote :

I just realized this appears to be the same bug as #194607 in hardy. Would love to see this fixed in intrepid.

andyboeh (andy-boehler) wrote :

Same problem for me on Acer Aspire One. On hardy I didn't have this problem (but I was using a custom-built 2.6.27-rc kernel).

andyboeh (andy-boehler) wrote :

I added a line 'SUSPEND_MODULES="ath_pci"' to /etc/pm/config.d/01-modules and now resuming works.

computx (afleak) wrote :

Yes that works for me also. Devs, could we make this default behaviour for intrepid? The workaround is great but it would be even better if newbies didn't have to search for this.

fwiw: /etc/pm/config.d/01-modules did not previously exist on my system

andyboeh (andy-boehler) wrote :

/etc/pm/config.d/01-modules was created by me, so no, this file shouldn't exist on a default install ;)

nclm (nclm) wrote :

I experience the same behaviour

Loïc Minier (lool) wrote :

I confirm; perhaps we can ship a pm-utils file to unload the module on suspend/resume in lrm.

Changed in linux-restricted-modules:
status: New → Confirmed
Loïc Minier (lool) wrote :

I suggest not overwriting SUSPEND_MODULES completely, perhaps use:
SUSPEND_MODULES="$SUSPEND_MODULES ath_pci"

The ath5k in linux-backports-module in intrepid works better then the current one in linux-image in intrepid; it survives suspend/resume and covers more hardware.

Loïc Minier (lool) wrote :

Sorry, "overwriting" is fine, it's handled by pm-utils.

Loïc Minier (lool) wrote :

So I confirm that adding a /etc/config.d/10madwifi with SUSPEND_MODULES="ath_pci" fixes wifi after suspend/resume for me when using plain intrepid.

Oliver Grawert (ogra) wrote :

linux-restricted-modules needs to ship:
/etc/pm/config.d/madwifi

with the following line:
SUSPEND_MODULES="ath_pci"

this will make sure the module gets properly unloaded in suspend/resume cycles which doesnt happen by default and thus results in a broke wlan connection after a resume.

Steve Langasek (vorlon) wrote :

Shipping this in linux-restricted modules-2.6.x-y would mean either file conflicts, or a versioned conffile name for each kernel revision. Shipping it in linux-restricted-modules-common will make it tricky to roll this back, if and when the module no longer has to be reloaded on suspend/resume. Under the circumstances, would it not be simpler to ship this setting in pm-utils itself?

Steve Langasek (vorlon) wrote :
Changed in ubuntu-release-notes:
status: New → Fix Released
Loïc Minier (lool) wrote :

I think madwifi wont be kept for much longer as ath5k / ath9k are supposed to replace it entirely pretty soon (perhaps already in 2.6.28); hence linux-restricted-common seems like the good place to ship the file. I think it's easier to think of changing the value in lrm if we update to a madwifi which doesn't need this hack, but this is very unlikely anyway.

I didn't want to add the file to pm-utils because it makes us pile hardware specific files to parse on suspend/resume which are already slowish on some devices when using pm-utils. (I see it a bit like init script proliferation slowing down boot.)

Andreas Jonsson (sonofjon) wrote :

Bug #272300 sounds related. Adding

  ifconfig wifi0 up

to

  /usr/lib/pm-utils/sleep.d/10NetworkManager

seems to solve madwifi resume issues on some systems.

Brian Harkness (maestro-bwh) wrote :

Oliver, does anything else need to be put in the file /etc/pm/config.d/madwifi

other than

SUSPEND_MODULES="ath_pci"

Loïc Minier (lool) wrote :

No, nothing else.

However please prefix the filename with some number; there's already /etc/pm/config.d/00sleep_module.

Seeed (nielsfranke) wrote :

I can confirm this bug on my Sony Vaio VGN-N31m with my Atheros AR5006EG wifi card.

The fix from Loïc Minier solved the problem.

Simon Vass (technical-team) wrote :

I can confirm this on a Toshiba A205-S5806 with
03:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)

The SUSPEND_MODULES="ath_pci" fix above worked fine.

Jukka Laurila (jlaurila) wrote :

Confirmed the bug with Intrepid on an IBM Thinkpad T40p with:

02:02.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)

The SUSPEND_MODULES="ath_pci" fix works at least with my unencrypted WLAN.

Michael Rooney (mrooney) wrote :

Leann or another knowledgeable person, is this a duplicate of bug 267339?

Changed in linux-restricted-modules:
importance: Undecided → Medium
status: Confirmed → Triaged
Gustavo Puy (info-gustavopuy) wrote :

With Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01) on Intrepid Ibex

SUSPEND_MODULES=ath_pci

doesn't works for me, on resume we have to do

:~# modprobe ath_pci
:~# ifconfig wifi0 up
:~# ifconfig ath0 up

So, I added 'ifconfig wifi0 up' in the NetworkManager suspend/resume script at /usr/lib/pm-utils/sleep.d/10NetworkManager here:

thaw|resume)
  ifconfig wifi0 up <---
  resume_nm

Brian Harkness (maestro-bwh) wrote :

Unfortunately I got really frustrated with the performance of my atheros card in my laptop with Intrepid. I could never get a stable connection. However, I agree that the ifconfig wifi0 up would bring up my interface, where SUSPEND_MODULES=ath_pci would not.

as a personal preference, when I modify scripts in my root directory, I have them call a script in my home directory, rather than add a bunch of lines in a root directory file. I had /usr/lib/pm-utils/sleep.d/ modified such that it called /home/user/bin/wifiwake.sh It is just easier to modify stuff there, with permissions and all.

Darius (darius-dons) wrote :

I don't need the MODULES line, however I do need 'ifconfig wifi0 up' (I modified resume_nm in /usr/lib/pm-utils/sleep.d/10NetworkManager)

This appears to be a regression BTW - in Ubuntu 8.04 it wasn't necessary.

This bug still exists in Jaunty alpha 3 live CD and Jaunty install with updates as of 20080130

I experience this same issue of a non-functional ath_pci module with my Fujitsu P1610 running the latest Intrepid stable (installed yesterday). I can fix it manually as outlined below, but I'd much rather understand where the module needs to be listed in order to properly reload itself after suspend-resume.

In dmesg, my wifi card reports itself like this...
[ 23.323484] wifi0: Atheros 5424/2424: mem=0x54100000, irq=18

After a suspend, it cannot automatically reconnect, and choosing an ESSID manually also fails to connect, until you've reloaded the module.

if I just run...

sudo ifconfig ath0 up

...it doesn't seem to load up a functioning wireless adapter. I can select from the list of - possibly cached - local wifi networks, but it gives up trying to connect.

To fix I have to run...

sudo /etc/init.d/networking restart
sudo modprobe -r ath_pci
sudo modprobe ath_pci

...although I was very surprised to find that adding these lines to /etc/default/acpi-support

MODULES="ath_pci"
SERVICES="networking"

...is somehow not equivalent with running these two commands manually, possibly the order matters. There's certainly some kind of timing issue, as sometimes it needs to restart the networking service as well as the module reload, and sometimes it just works with only the module reload.

If the module reload isn't enough to bring the network back up, an alternative sequence which works is to run the module reload, then reselect the wireless network ESSID manually from the drop down, which then connects successfully.

description: updated

Based on feedback both here and in some of the bugs marked as duplicates, it appears this issue is resolved if you install linux-backports-modules-intrepid which will provide the ath5k/ath9k drivers. There is also a workaround if you want to continue using the proprietary ath_pci driver. I've updated the description of this bug report to reflect both.

After a quick discussion with the kernel team, it's not likely there will be any updates coming in for madwifi so I'm marking this "Fix Released" against linux-backports-modules-2.6.27 and "Won't Fix" against linux-restricted-modules. If you still experience this issue even after testing the workaround or installing linux-backports-modules-intrepid, please open a new bug. Thanks.

Changed in linux-backports-modules-2.6.27:
status: New → Fix Released
Changed in linux-restricted-modules:
status: Triaged → Won't Fix
Thomas Hood (jdthood) wrote :

I have read through the reports marked as duplicates of this one and see three possibly distinct issues.

1. Have to do "ifconfig wifi0 up" after suspend
2. ath_pci needs to be reloaded after suspend; fixed by using ath5k instead
3. ath5k needs to be realoaded after suspend

The first two issues appear to be moot in Jaunty, leaving the third issue which is exacerbated by the fact that reloading ath5k doesn't make the Atheros card work again.

(Regarding issue #1: There is no wifi0 interface; it is now called wlan0. After suspend it is not necessary to do a "ifconfig up" on this interface.)
(Regarding issue #2: There is no ath_pci module loaded.)

Additional information:

I have a ThinkPad X61 running Jaunty. After suspend and resume the Atheros card does not always work: sometimes it works, sometimes it doesn't. In the latter case, removing and reinserting ath5k does *not* help.

$ lspci |grep -i ath
03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)
$ lsmod|grep ath
ath5k 107008 0
mac80211 217080 1 ath5k
led_class 12036 2 ath5k,thinkpad_acpi
cfg80211 38032 2 ath5k,mac80211
root@triffid:~# dmidecode -s system-manufacturer
LENOVO
root@triffid:~# dmidecode -s system-product-name
7673CTO
root@triffid:~# dmidecode -s system-version
ThinkPad X61

Christian Reis (kiko) wrote :

Thomas, that's really useful information, but you should be filing a new bug, not updating this one -- it is rarely useful, in a vague bug like this, to try and reopen it. The bug you are reporting seems to be something like

  After suspend, atheros cards sometimes fails, and reloading ath5k does not fix it.

Thomas Hood (jdthood) wrote :

OK, filed new bug report #341627.

Jamin W. Collins (jcollins) wrote :

This is listed as "Fix Released" however, I'm still seeing it with the current Jaunty alpha.

Jaunty by default used the ath5k module for wireless. However, with the ath5k driver connectivity was sluggish and intermittent.

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

After moving to the proprietary driver, connectivity improved dramatically along with overall throughput. However, after suspend, the ath_pci driver much be removed and reloaded manual. listing it in /etc/default/acpi-support has no effect.

Well, I am running a Sony VGN-N330FH and the problem is still there. I just did the modification

sudo nano /etc/pm/config.d/madwifi
SUSPEND_MODULES=ath_pci

and will restart right now. Will get back to report

sudo lshw -C network
  *-network
       description: Ethernet interface
       product: 88E8036 PCI-E Fast Ethernet Controller
       vendor: Marvell Technology Group Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: eth0
       version: 16
       serial: 00:13:a9:c8:de:9e
       capacity: 100MB/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm vpd msi pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=sky2 driverversion=1.23 firmware=N/A latency=0 link=no multicast=yes port=twisted pair
       resources: irq:27 memory:d6000000-d6003fff ioport:2000(size=256)
  *-network
       description: Wireless interface
       product: AR5001 Wireless Network Adapter
       vendor: Atheros Communications Inc.
       physical id: 0
       bus info: pci@0000:06:00.0
       logical name: wmaster0
       version: 01
       serial: 00:19:7e:4b:d9:75
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list logical ethernet physical wireless
       configuration: broadcast=yes driver=ath5k ip=192.168.1.101 latency=0 multicast=yes wireless=IEEE 802.11bg
       resources: irq:18 memory:da000000-da00ffff

Nope, didn't work
Ubuntu Karmic
Linux vaio 2.6.31-22-generic #60-Ubuntu SMP Thu May 27 00:22:23 UTC 2010 i686 GNU/Linux

I was running wicd instead of network-manager. I uninstalled wicd and reinstalled network-manager, recreated the

sudo nano /etc/pm/config.d/madwifi
SUSPEND_MODULES=ath_pci

suspended and logged in again. It seems that my problem is solved.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers