ipw2200 needs to be reloaded after suspend

Hi,

this is not a network-manager bug. Lets find a new home :) ...

 - Alexander

The problem may be because the ipw3945 module needs to be reloaded in order for network-manager to reestablish the WiFi connection after a resume. I had a similar problem and adding ipw3945 in the SUSPEND_MODULES list in /usr/lib/pm-utils/defaults fixed it.

BTW, if /usr/lib/pm-utils/defaults is intended to be changed by users, shouldn't it be called /etc/default/pm-utils instead ?

Xavier

xhienne: because /usr/lib/pm-utils/defaults is not intended to be changed by end users, it is inteded to be changed by distribution maintainers.

End users should drop config files in /etc/pm/config.d -- any changes made in these files will override ones made in /usr/lib/pm-utils/defaults

This bug was fixed in the package pm-utils - 0.99.2-3ubuntu6

---------------
pm-utils (0.99.2-3ubuntu6) hardy; urgency=low

  * Add debian/patches/97_fix_ppc_suspend_test.patch: Fix suspend test on
    PowerPC, thanks to Matthew Garrett (see patch header for details).
  * debian/patches/70-remove-pm-pmu.patch: Change the patch to not entirely
    drop pm-pmu, but use hal-system-power-pmu instead. This brings back
    suspend to PowerPC. (LP: #189851)
  * Add debian/patches/98-unload_network_modules.patch: Unload/reload network
    modules during suspend. Thanks to Matthew Garrett! (LP: #162654)

 -- Martin Pitt <email address hidden> Thu, 27 Mar 2008 16:26:43 +0100

Reloading the network modules on my desktop system causes the network to being down after resuming.
This is what /var/run/pm-suspend looks like:
export ibm_bluetooth_STATE=missing
export RESUME_MODULES="forcedeth $RESUME_MODULES"
export RESUME_MODULES="sky2 $RESUME_MODULES"
export cpu0_governor_STATE=ondemand

This triggered a bug with udev: bug 208103.
After fixing 70-persistent-net.rules however, I still have to "sudo invoke-rc.d restart networking" to make it work again.

/etc/network/interfaces:
--------------
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.178.20
    netmask 255.255.255.0
        network 192.168.178.0
        broadcast 192.168.178.255
        gateway 192.168.178.1
--------------

I'm not using NetworkManager.

pm-utils - 0.99.2-3ubuntu6 does not fix the bug. While it unloads/reloads the module correctly, it does not reenable the interface (wlan0_rename). For one reason or the other bringing up wlan0_rename does however not solve the problem. NM still does not connect.I have to restart hal.

Florian, the "wlan0_rename" is probably caused by bug 208103. A workaround is mentioned there.

However, I'm re-opening this bug, because it seems like this change also needs to restart the "networking" service, at least with my system.

I can confirm this to. Works again after "/etc/init.d/networking restart". But i have the problem on the wired card, so it's not only a wireless problem...

not restarting networking breaks manual network setups as Daniel Hahler says. Either we should do that, or revert the patch and people with broken modules will need to use SUSPEND_MODULES. I'm not sure if either is great, restarting networking could have bad effects for some people and obviously the correct solution is to have kernel modules suspend hardware properly so this isn't necessary, but that's not realistic for hardy.

Currently however I can state that I am not experiencing this bug anymore. Switching to hardy and the new iwlwifi drivers in 2.6.24 did it for me. In any case, if I am not mistaken, ipw3945 drivers should have been ditched, am I wrong?

I am still seeing this issue. I have pm-utils version 0.99.2-3ubuntu8, so version 0.99.2-3ubuntu6 does not fix this as stated above. I have a wired card, not wireless. I've attached my output from dmesg (log was cleared just before I suspended). Had to do a sudo ifdown eth0 and sudo ifup eth0 to get things going. I will also try doing a "/etc/init.d/networking restart" to see if that does the same thing.

Looks like ""/etc/init.d/networking restart" basically does what I was doing (ifdown/ifup) in one step rather than two. So that works as well. Note that the ifdown command returns the following after the resume:
RTNETLINK answers: No such process
SIOCDELRT: No such process

Let me know what other info I can provide. I'd be happy to help fix this if I can.

This debdiff fixes debian/patches/98-unload_network_modules.patch to restart networking on thaw or resume.

Regression from previous releases, and earlier releases restarted the network as well. Milestoning.

Oh, unfortunately the fix does not actually cure the keyboard/mouse problem, but at least it avoids the beeping and the error messages. I'll upload a fix soon (it will hang in the release-management queue a bit until it gets accepted).

This bug was fixed in the package pm-utils - 0.99.2-3ubuntu9

---------------
pm-utils (0.99.2-3ubuntu9) hardy; urgency=low

  * debian/patches/70-remove-pm-pmu.patch: Check for /dev/pmu before calling
    /usr/lib/hal/hal-system-power-pmu. Not doing so causes error messages and
    g-p-m error beeps on non-powerpc systems. (LP: #210832)
  * debian/patches/98-unload_network_modules.patch: Restart network after
    resuming, since this unloads/reloads network modules during suspend. This
    unbreaks static network configuration after suspend, and mimics
    acpi-support's behaviour of previous releases. (LP: #162654)

 -- Martin Pitt <email address hidden> Fri, 11 Apr 2008 08:21:13 -0500

Still a problem for me after the fix.

Using Hardy with pm-utils 0.99.2-3ubuntu10.

Can't get ethernet nor wireless after resume from suspend--network config still totally static.

Thanks for looking into this.

This bug seems to have re-appeared in intrepid.

I am using a static network config and networking does not work after resume from suspend until I either restart networking or run dhclient

Tim, the unloading of network modules was removed from the pm-utils script in intrepid, since that was actually a kernel bug. Thus the restarting of /etc/init.d/networking was dropped, too, since this is evil and just a workaround.

What kind of network device do you have in your config, ethernet or wifi? Can you please attach /var/log/kern.log after resuming?

I have an Intel PRO/Wireless 2915ABG (which uses ipw2200 driver)

I am using a manual configuration through /etc/network/interfaces and using wpa-supplicant.

Have attached a copy of kern.log after resuming, (without using pm-utils to unload the wifi driver during suspend)

This problem is now specific to ipw2200, reopening the bug for this. It's really a kernel bug, but we can work around it in pm-utils.

This affects forcedeth in the same way: see bug 288281

Please note that the "hack" to make this work (debian/patches/98-unload_network_modules.patch) has been removed in pm-utils (1.1.0-1ubuntu1) during Intrepid development.
More info at my original bug report about this (bug 283462, duplicated to the one mentioned in my comment above).

ipw2200 normally works fine after suspend for me, but occasionally in the WPA Enterprise environment at uni it will need reloading upon resume.

I have tried both the workarounds from the above mentioned bugs (288281 and 283462)

with the SUSPEND_MODULES workaround, wifi always gets associated with the AP but never gets an IP from DHCP server.

with the RESUME_MODULES workaround, things seem to work however sometimes, can take several minutes before wifi associates with the AP. although once it finally associates it does have an IP. Sometimes, maybe 1 in 4 resumes it will connect straight away.

I have also now discovered that without either of these workarounds, wifi does eventually connect to the AP after 3 or so minutes, but never gets IP address.

Tim wrote:
> I have an Intel PRO/Wireless 2915ABG (which uses ipw2200 driver)
>
> I am using a manual configuration through /etc/network/interfaces and
> using wpa-supplicant.
>
> Have attached a copy of kern.log after resuming, (without using pm-utils
> to unload the wifi driver during suspend)
>
>
Can you fix this by running sudo killall wpa_supplicant after resume?

William Grant wrote:
> ipw2200 normally works fine after suspend for me, but occasionally in
> the WPA Enterprise environment at uni it will need reloading upon
> resume.
>
>
maybe doing a sudo killall wpa_supplicant is enough to cure you in that
case?

Alexander Sack wrote:
> William Grant wrote:
>> ipw2200 normally works fine after suspend for me, but occasionally in
>> the WPA Enterprise environment at uni it will need reloading upon
>> resume.
>>
> maybe doing a sudo killall wpa_supplicant is enough to cure you in that
> case?

Restarting NM doesn't help, and IIRC that restarts wpa_supplicant.

William Grant wrote:
> Alexander Sack wrote:
>
>> William Grant wrote:
>>
>>> ipw2200 normally works fine after suspend for me, but occasionally in
>>> the WPA Enterprise environment at uni it will need reloading upon
>>> resume.
>>>
>>>
>> maybe doing a sudo killall wpa_supplicant is enough to cure you in that
>> case?
>>
>
> Restarting NM doesn't help, and IIRC that restarts wpa_supplicant.
>
>
it doesnt restart wpa supplicant. so my question is still valid.

no that doesnt seem to help.

wpa_supplicant does not even restart after I kill it.

On 12/29/2008 12:54 AM, Alexander Sack wrote:
> Tim wrote:
>
>> I have an Intel PRO/Wireless 2915ABG (which uses ipw2200 driver)
>>
>> I am using a manual configuration through /etc/network/interfaces and
>> using wpa-supplicant.
>>
>> Have attached a copy of kern.log after resuming, (without using pm-utils
>> to unload the wifi driver during suspend)
>>
>>
>>
> Can you fix this by running sudo killall wpa_supplicant after resume?
>
>

With the latest comments I am now confused: what *actually* needs to happen to make ipw2200 survive a suspend? Remove/load the module? restart wpa_supplicant? Both? None? Something else?

as best as I can tell 3 steps are needed

1. remove/reload the module (or use RESUME_MODULES workaround)
2. restart wpa_supplicant (needs to be done manually since it doesn't restart after running killall)

The above leaves wifi successfully connected to the AP, but the routing table is missing the default route,

3. Add default route

Tim [2009-01-27 20:42 -0000]:
> 1. remove/reload the module (or use RESUME_MODULES workaround)

That would be SUSPEND_MODULES then.

> 2. restart wpa_supplicant (needs to be done manually since it doesn't restart after running killall)

That doesn't need any arguments?

> 3. Add default route

That means we need to capture the default route as it was before.
However, at that point it really becomes hackish. Maybe there is a
D-Bus signal that we can send to NetworkManager that asks it to
restart the connection?

I still don't know what to do here; needs questions from previous comment resolved at least.

> That would be SUSPEND_MODULES then.

RESUME_MODULES does work fine to reload modules, not sure about SUSPEND MODULES

> That doesn't need any arguments?

yeh, starting wpa-supplicant manually requires atleast -c, -i and prob -D arguments to be specified

On Mon, 2009-03-02 at 20:34 +0000, Tim wrote:
> RESUME_MODULES does work fine to reload modules, not sure about
> SUSPEND_MODULES
On the contrary. SUSPEND_MODULES is honoured by pm-utils, but
RESUME_MODULES is not. Do a grep for it in /usr/lib/pm-utils and you'll
see what I mean.
--
Chow Loong Jin

I have the same problem with iwl3945, but worse as it hangs altogether on resume.

I did not notice it earlier because I do not often user wireless, and have the kill switch on (in which case there is no problem).

Unloading on suspend appears to fix this, but I have not yet tested it while actually connected to a network so I do not know if that would still cause a problem.

Graeme, this bug is about ipw2200. iwl3945 suspends/resumes just fine in general without any magic (I do that all the time). Please report a separate bug report against the kernel with "ubuntu-bug linux" (in Ubuntu 9.04) after reproducing the hang.

I think I've only seen Hardy mentioned in the above discussion. Does this same issue exist in the most recent Jaunty Jackalope 9.04 release - http://www.ubuntu.com/news/ubuntu-9.04-desktop .

Please let us know your results. Thanks.

I have a thinkpad T42 with the 2915ABG card (IPW2200 driver).every since upgrading to 8.10 then directly to 9.04, I am getting constant disconnects/reconnects. I have tried with and without the network manager, tried wicd, tried everything. This card worked flawlessly in 8.04....

Even now, iwconfig reports 18 mbit/sec. I've seen as low as 5.5 with this release.

I am pleased - NOT!

Kurt, your problem is not related to a suspend problem. Can you please report it separately? (ubuntu-bug linux).

There is too little information about doing a workaround in pm-utils, and it should be fixed properly in the kernel. Unloading modules is evil and often not even possible.

Hi luca-venturini,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/ . However, note you can only test Suspend, not Hibernate, when using a LiveCD. If you could run the following command from a Terminal (Applications->Accessories->Terminal) it will automatically gather and attach updated debug information to this report.

apport-collect -p linux-image-`uname -r` 162654

Also, please be sure to take a look at https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume . If you can provide any additional information outlined there it would be much appreciated.

Additionally, if you could try to reproduce this with the upstream mainline kernel that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

I can confirm that I no longer have this problem after upgrading to Ubuntu 9.04.

Marking Fix Released per last comment #45.

Wow I don't whether can see this and help me. Every time when I relog in from the hibernation or hang ,the network just collapse. I now use the 11.04 and before upgrading , the 10.10 has the same problems .Is is a bug? Some one can help me handle this ?Thank you in advance.