Wireless (ipw2200) does not work after waking up from sleep(without manually switching on).

I can confirm this.

Using Network Manager for wpa connection, and after resuming from suspend/hibernate I have to disable and re-enable networking from the Network Manager menu to kick off the connection process.

I am having a similar problem, when I resume from a suspend network manager just sits a spins as it tries to reconnect. I have to reload the ipw2200 module then it works fine.

problem is still present in Edgy (however, overal suspend and hibernation performance hae tremendeously increased, it is not really fast, thanks guys)

I meant is is noW really fast;-)

I have this problem too with a built-in wireless card. I'm not using network-manager. My laptop is a Dell 6400 with an Intel wireless card:

0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

Often the wireless network doesn't come back up when waking from suspend to RAM. This usually fixes the problem:
$ /etc/init.d/networking restart

I'll attach the tail end of dmesg.

After waking the computer, sometimes running
$ /etc/init.d/networking restart
still fails to bring up the interface. Attached is the output of the above command when it fails.

I suspect that this is a separate issue.

My laptop uses ipw2200 but I can't confirm this bug and have no lines with ipw2200 in my /var/log/syslog.

Is this still a problem in feisty?

is it somehow possible to test this with a LiveCD of Feisty? I do not really have a partition to spare for a developement version (or can I somehow test it in some chroot or virtual environment? just tell me what to use and I will test it) - otherwise I will stick to Edgy.

I think so. Hibernation won't work, since there needs to be a swap partition to get it working, and I'm not sure if the livecd is set up to use a pre-existing partition. The sleep should work fine though, I think. Let us know how that test with sleep works out on feisty if you get the chance.

I tried with herd 4 and it does not even get back from sleep, but sleep is supposedly broken, so I will try with herd 5. Stay tuned.

Can you please let us know how herd 5 turned out and maybe try the latest Beta too? Thanks.

sorry for the delay, my CD Drive ceased to work so I could not test.
I tried the latest beta and it does not work.
Should I try herd 5 as well?
Or can I provie you with some other info?

(this bug is especially unfortunate with combination with other bug https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/53953 since it is impossible to turn the wireless on in default install without some tweaking - but maybe I am the only one using Ubuntu on this piece of hardware, it is pretty noname and old)

Please attach the output of lspci -vvn, lspci -vv, and dmesg. Thanks

I am attaching all three as attachements
1 dmesg

2 lspci -vv

3 lspci -vvn

That dmesg output was from an edgy installation. I think it may need to be from a feisty environment instead. Could you please attach that too?

my bad, I did not realized that, I suppose outputs of lspci does not change with distribution, right
dmesg from latest feisty beta attached

Major updates in 2.6.20-14 for lib-ata and ACPI. Please try the daily ISO on Monday 4/2 http://cdimage.ubuntu.com/daily-live/current.

I am sorry but I am unsure now - the oldest there is Wednesday (28 3), at least for my platform (i386), newer are only for amd64 - which one should I try, the one from 28 opr should I wait for a newer one to appear?

tried the daly from 2.4. and it still does not work

Still present in Feisty release:-(.

My computer with Xubuntu feisty had a problem with getting an ip-adress after waking from hibernation. I´ve solved this problem by changing /etc/default/acpi-support

Editing this file, look for the line below, where to add [networking] after that no problems anymore:

# Add services to this list to stop them before suspend and restart them in
# the resume process.
STOP_SERVICES="networking"

Hope this will work for you to,
Thomas.

thanks for your input, Thomas, but that does not work, I think it has something to do with not standard drivers (called acerhk) that turn on/off wifi.

hi,
i had the same problem: the wireless connection didn't resume after hibernation. what i did to fix the problem: call "gconf-editor" in a terminal. edit setting for "apps--> gnome-power-manager and switch "networkmanager_sleep" OFF (uncomment). hibernation is still quite slow though; if anyone has a hind how to get it faster, i'd appreciate to know about it. cheers

I had the same problem with ipw2200 on a toshiba laptop, but adding ipw2200 to mondules in /etc/default/acpi-support fixed the issue...
I hope you'll fix this for furture releases since it's a big bug... Anyway, I just wanted to confirm it... :)

I do confirm this issue on Acer TravelMate 3210 partially solved stopping networking service.

Why partially solved. Because network manager loop requesting to unlock keyring but pressing Esc solve this problem. Restoring from Hibernate enter in the loop too.

Good news is that is the 1st time I'm enable to suspend and hibernate !!!! (Y)

Linux xxx 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
Ubuntu 7.10

still an issue as of up to date gutsy (for the same hardware Prestigio 157 - I still use it and intent to use it for another two years, if it lasts, so if someone wants to have a look at this, I will happily test)

Changing to contemporary kernel since it is still an issue.

The Hardy Heron Alpha series was recently released. Alpha2 and subsequent releases contain an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . Please note that Alpha3 will be released within the next day or two so you many want to wait. You should be able to then test this bug with the new kernel on the LiveCD (Suspend is possible, but not Hibernation). If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . Thanks!

Tried with aplha 3, same results as alwasy, marking back as confirmed. I really think this has something to do with this bug https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/53953 - I have got a BIOS switch to turn the wireless on, so upon boot, it works, but when I suspend, it seems that linux knows how to shut wireless down, but does not know hot to turn it on back because it does not know how to handle the switch - something acerhk could be a part of solution to, maybe.

Just learned the development kernel is called linux now, targeting at it.

Hi Tomas,

Care to test with the latest Hardy Alpha 6 that was released: http://www.ubuntu.com/testing. You should be able to test Suspend via the LiveCD, not Hibernate though. Assuming the issue still exists, care to then attach your dmesg output after a suspend/resume process? Thanks.

dmesg attached, it is still an issue. I think the problem is with acerhk drivers (as i already said, see https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/53953 ) anyway, what I need to get it (wireless) working:
modify /etc/modprobe.d/options and add a line
options acerhk autowlan=1

then remove and insert the driver (sudo modprobe -r acerhk, sudo modprobe acerhk)
and press the button to turn on wireless (the button would not work without that option)

This happens for me, too, on Hardy with a T60 laptop using the iwl3945 module.

tim@diva:/tmp$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04
tim@diva:/tmp$ uname -a
Linux diva 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

dmesg & lspci output attached.

the bug is still in affect as of Hardy release

I want to join this bug watch. I just started having this problem after upgrading to Hardy. It's affecting my z61t notebook.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

As usual, it is exactly the same.

Have similar bug under new release.
Laptop BenQ S32B
$ lsb_release -rd
Description: Ubuntu intrepid (development branch)
Release: 8.10
$ uname -a
Linux BenQ 2.6.27-2-generic #1 SMP Thu Aug 28 17:20:02 UTC 2008 i686 GNU/Linux

Trying to find workaround.

Found solution.
Problems can be solved
1) by hands: check if this helps then go to 2)
After "sudo pm-suspend"
  sudo rmmod ath_pci
  sudo modprobe ath_pci
  sudo /etc/init.d/NetworkManager restart
Network appears. If so, automate this
2)
  sudo vim /etc/pm/config.d/modules:
> SUSPEND_MODULES="ath_pci"
  sudo vim /usr/lib/pm-utils/sleep.d/10NetworkManager
> case "$1" in
> hibernate|suspend)
> /etc/init.d/NetworkManager stop
> ;;
> thaw|resume)
> /etc/init.d/NetworkManager start
> ;;
>*) exit $NA
> ;;
> esac

Gotcha.
Maybe Ubuntu ACPI Team could make this behaviour default? It looks like most of wireless modules should be unloaded before suspend.

nestoklon: does not work for me, thank you though (I think my issue has something to do with the hardware wifi switch)

Thanks Thomas,

We'll keep this open against the actively developed kernel but against 2.6.22 this will be closed as it does not qualify for a Stable Release Update - http://wiki.ubuntu.com/StableReleaseUpdates . Thanks.

Works for me, nestoklon. Thank you so so very much! :)

I have an acer Extensa 4220 which uses the atheros chipset too. I do believe the ubuntu ACPI team should make this the default behaviour, as I'd imagine pretty much anybody who uses atheros chipsets should have this issue. Hopefully, this turns out quicker on google next time I have to do this ;) (i'm sure to have forgotten, and have spent over a year and a half without suspend).

Now my Ubuntu is complete and whole! :D

Since upgrading to Intrepid Ibex, this issue is fixed for me. At least, it is with suspend: I haven't tried with hibernate because my swap partition is too small.

I upgraded over the weekend, so I was using packages from Oct 25.
Current versions:
linux-generic: 2.6.27.7.11
network-manager: 0.7~~svn20081018t105859-0ubuntu1

i seem to be experiencing this bug with the final version of intrepid with ipw2200.

to get wireless working after waking from sleep I must reload the ipw2200 module and then run dhclient.

I, too, have been plagued by this problem i.e. losing wireless connection when I activate suspend or hibernate. I WAS using Intrepid 8.10 on my Acer laptop ....and by chance decided to try out Mint5 Linux - where I don't have this problem! Howcome the Mint team have solved a problem that is still bedevilling Ubuntu users??? Am mystified ...

I solved my issue by removing and reloading ath_pci. (Half of the steps suggested by nestoklon)

yc

This bug is related to the Intel ipw2200 kernel module which manages the 2200BG adapter.

Tomas Hynk's PC has:

 Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)

Alex Fraser's PC has the 3945 which uses the iwl3945 module:

 Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222]

nestoklon, Siddhu Warrier and yclian have Atheros wireless adapters. E.g.

 Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)

Tomas' original report shows the kill-switch is detected as being on:

Jul 17 23:59:49 localhost kernel: [17180125.980000] ipw2200: Radio Frequency Kill Switch is On:
Jul 17 23:59:49 localhost kernel: [17180125.980000] Kill switch must be turned off for wireless

If you are using the Intel 2200BG or Intel 3945ABG and are affected by this issue in Hardy, Intrepid, or Jaunty please provide the following information with kernel debug enabled.

To enable kernel debug enter the GRUB menu at start-up by pressing ESCape. Highlight the kernel to boot, press "E" to edit it. Highlight the "kernel" line and press "E" to edit it. At the end of the line remove "quiet splash" and replace with " debug". Press Enter, then press "B" to boot with the changed parameters.

Do a clean start-up, suspend, resume cycle and then attach an archive containing these reports:

uname -a >/tmp/version.log
lsb_release -a >>/tmp/version.log
sudo dmidecode -t system >/tmp/dmidecode.log
lshal | sed -n '/^udi = .*rfkill/,/^udi =/ p' >/tmp/hal-rfkill.log
sudo lspci -vvnn >/tmp/lspci.log
tar -czf /tmp/lp53310.logs.tar.gz /tmp/version.log /tmp/dmidecode.log /var/log/kern.log /tmp/hal-rfkill.log /tmp/lspci.log

Attach /tmp/lp53310.logs.tar.gz to a comment.

Thanks for someone of the kernel team looking into this. All the information attached as requested.

Tomas. Sorry I haven't responded. Somehow I missed the bug update notification email but just noticed this when scanning my ACPI team notifications.

I'll look into your report and get back to you.

It might be of interest that I have two Vaio notebooks here with 2915ABG [8086:4223] ipw2200-managed mini-PCI adaptors and neither has a problem with Jaunty.

Tomas. I've looked at the provided logs and the kernel source-code involved.

The logs show that the PC (I assume this is still the Prestigio 157?) doesn't provide a radio frequency kill switch using the usual HAL (hardware abstraction layer) identity. Here's an example of what I'd expect to see (from a 3945ABG):

lshal | sed -n '/^udi = .*rfkill/,/^udi =/ p'
udi = '/org/freedesktop/Hal/devices/pci_8086_4222_rfkill_3945ABG_wlan'

With the 2915ABG devices here that doesn't show up either so not a major problem. There is however a node in the /sys/devices/ tree that actively reflects the kill-switch state provided by the ipw2200 module. Here's a bit of code to see if your PC has the same:

KILL="$(find /sys/devices -name rf_kill)"
if [ ! -z "$KILL" ] && cat $KILL

The values reported have these meanings (from the ipw2200 source):

 /* 0 - RF kill not enabled
    1 - SW based RF kill active (sysfs)
    2 - HW based RF kill active
    3 - Both HW and SW baed RF kill active */

Depending on the result you can try manually changing it. I'd be interested to know if it is possible to actually make the radio turn on/off using it:

echo 1 > sudo tee $KILL

When I do that on the Vaio notebooks with 2915ABG the NetworkManager applet reports no network device almost immediately. I can re-enable it by doing:

echo 0 > sudo tee $KILL

If I use the hardware switch to kill the radio I see:

cat $KILL
2

If the ipw2200 module has no control over the state of the radio kill switch - if it can only read the status - then I'm going to close this bug as Invalid (since it isn't a problem with ipw2200) and move to your other specific bug #53953 "change 'acerhk' to use 'autowlan=1' by default".

PJ: yes, it is still P157 (it is great I can run modern Ubuntu on almost 5 year old notebook more or less without a glitch).

The code you posted assigns /sys/devices/pci0000:00/0000:00:1e.0/0000:02:06.0/rf_kill to $KILL,
when I do echo 1 > $KILL (under root permissions) I lose the signal in less than a second. I can get it back with echo 0 > $KILL - that is the same as on your side. So the ipw2200 has some control over the kill switch.

Wow! I never expected that! Things are looking promising :)

There now looks to be a work-around we could implement in user-space when the system suspends and resumes. A simple shell script reads this value on suspend and writes the same value back on resume.

That would be good since wireless drivers are supposed to be passive and not try to change the state of rfkill, only respond to it's current setting. That's why I suggested in the related acerhk bug report it implement the RFKILL API where driver-handling of this issue should be done.

One thing more: Does this ipw2200 sysfs control mechanism work even when the acerhk autowlan=1 parameter is *not* used?

Your joy looks promising:-).
Yes, it works even when acerhk is not loaded at all.

Try installing this power-management script and let me know how it goes. I'm not completely happy with it since it doesn't try to ensure the device it is probing and poking is the ipw2200/acerhk combination, but lets see how it goes.

1. Download the script attachment
2. Copy to /etc/pm/sleep.d/

sudo cp action_rfkill /etc/pm/sleep.d/

3. make executable

sudo chmod a+x /etc/pm/sleep.d/action_rfkill

4. Test!

By the way, echo 1 > $KILL causes this to appear in the syslog:
Mar 20 19:38:36 bill NetworkManager: <info> Wireless now disabled by radio killswitch
and echo 0 > $KILL shows this:
Mar 20 19:38:42 bill NetworkManager: <info> Wireless now enabled by radio killswitch
that corresponds to
Mar 20 19:51:16 bill kernel: [17180125.980000] Kill switch must be turned off for wireless networking to work.
that I normally get upon resume.

However, when I try to suspend and resume,
echo 1 > $KILL
no longer worgs,
cat $KILL
gives 2 and unless I manually press the hardware button, it cannot be changed through echoing - once I press the button, I can change $KILL by echoing egain.

The script does not work. I commented out the rm "$SAVE_TO" part and
0 gets saved to /var/run/\^sys\^devices\^pci0000\:00\^0000\:00\:1e.0\^0000\:02\:06.0\^rf_kill, so the script works, but as I said in the post above, it somehow cannot change the value back to 0 (it somehow makes sense, since 2 means wh switch is enabled).

I actually find out this:
1) when $KILL is 2, I cannot change it by echoing.
2) when $KILL is 1 or 0, I can. When it is 0, I can echo it to 1. Echoing 2 and 3 do nothing. When it is 1, echoing all 0,2 and 3 sets it to 0.

So, I guess, somewhere during suspend/resume, sw switch is disabled and only hw switch is enabled, but I do not pretend I understand it.

Your report appears to confirm that the Radio button on the PC is purely a momentary press-to-make type... the state associated with it is held by a system I/O device register and therefore lost when power is removed from all but RAM on S3 suspend.

What a shame... that means we're back to the solution being to add support for the RFKILL API to the acerhk driver.

But how it comes that when I boot up the computer wifi works? Is it set by bios, which is not used while resuming? So we need a driver that will emulate this bios behaviour?

On Fri, 2009-03-20 at 20:23 +0000, TomasHnyk wrote:
> But how it comes that when I boot up the computer wifi works? Is it set
> by bios, which is not used while resuming? So we need a driver that will
> emulate this bios behaviour?
>
That's it precisely. For a cold-boot or return from hibernation the PC
goes through the BIOS power-on self test and configures the devices.

When doing suspend/resume all device state has to be saved by drivers
and restored on resume.

If acerhk implemented the RFKILL API the power-management system would
ensure that the state of the 'switch' was restored during resume.

PJ: I did some digging and found following. My laptop should be supported with wistron_btns driver. That is a kernel driver that handles more or less the same class of laptops as acerhk. As my laptop does not output any useful dmidecode info, it cannot be recognized automatically. However, there is a parameter to tell the driver the type of my laptop. So, when I do
sudo modprobe wistron_btns force=1 keymap=1557/MS2141
the driver gets loaded and all the buttons are asigned correctly. Only the button for wifi behaves just as any normal programmable button, which it (the button) is however not supposed to do. So this is a bug in winstron_btns - if we were able to fix that, the suspend problem would be solved (I think wistron_btns implements RFKILL: http://lwn.net/Articles/194637/ and there is also something resume/suspend related in the source code of the driver).
I tried looking into the source code of the driver (it is in /drivers/input/misc/wistron_btns.c in the kernel tree) but I do not understand it very much. My laptop with the parameters above uses the ms2141 keymap - I checked with acerhk (it has a debugging mode) and found out that the keys are assigned correctly. But beyond that, I do not understand why it does not work - there seems to be code for enabling and disabling the wifi in the driver.

Do you think you could help me and (I will gladly provide testing any information) either fix the bug or forward it to the kernel people?

I've opened a new bug report to address your suggestion: bug #346586 "wistron_btns: Implement RF-Kill support for some Acer and no-name systems"

Marking this as 'Won't Fix" since the issue isn't caused by the ipw2200 driver.

I've followed these postings with interest, astounded by the trials and tribulations some users have to wade through to get their connection up and running again - no wonder so many newbies flee Linux in confusion! You don't have to plow through this stuff when you're using Windows ... Anyway, I had similar problems which now appear to be resolved, without recourse to any of the suggestions on these postings. I run Ubuntu 8.10 on and Acer 3680 laptop, and while I had trouble for a while, losing my wireless connection when I hibernated or suspended, but since I've done a clean re-install of Ubuntu 8.10 and downloaded ALL updates, I no longer experience this maddening problem. So perhaps there's an easier way for those who still have this problem??? I also had a problem getting Ubuntu to work with my Brother MFC-215, but this was also resolved after the reinstall & download...

On Sun, 2009-03-22 at 02:47 +0000, wordsmyth wrote:
> I've followed these postings with interest, astounded by the trials and
> tribulations some users have to wade through to get their connection up
> and running again - no wonder so many newbies flee Linux in confusion!

If they do it is probably for the best. If the manufacturers do not
provide active support for drivers for Linux as well as Windows, and do
not provide the technical documentation for their proprietary devices,
then their users lose the ability to choose their preferred OS.

> You don't have to plow through this stuff when you're using Windows ...

Actually on Windows it can be worse. These third-party drivers are
sometimes hard to find especially for older devices where the original
media has been lost or damaged.

If you look at a typical Windows PC you'll find that there will be a
whole bunch of third-party driver packages (usually pre-installed by the
manufacturer) that need manual installation if the machine is rebuilt -
On the range of Sony Vaios I have each has at least eight driver
packages that require manual installation/update management.

Many of them don't get updated and if bugs appear the user is powerless
to do anything about it.

None of those provide any central update management and notification
such as Ubuntu and other distributions do.

For Linux, installing third-party drivers is relatively rare since
almost all hardware has (some) support from the mainline kernel. The
obvious exceptions are things like ATI and Nvidia video drivers but that
is the same for Windows too - constant third-party updates.

The Linux approach means that once the driver is in the mainline kernel
it is available to all without needing to locate and install it
(provided the distro enables the module).

> Anyway, I had similar problems which now appear to be resolved, without
> recourse to any of the suggestions on these postings. I run Ubuntu 8.10
> on and Acer 3680 laptop, and while I had trouble for a while, losing my
> wireless connection when I hibernated or suspended, but since I've done
> a clean re-install of Ubuntu 8.10 and downloaded ALL updates, I no
> longer experience this maddening problem.

I think that will be related to the atheros drivers, which rely on
continuous reverse engineering or restricted options.