iwl3945 sometimes fails to resume after suspend

Bug #297385 reported by dhenry
106
This bug affects 17 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

On Intrepid 8.10, Wifi (iwl3945) randomly fails to resume after a Suspend to RAM. I'm using the 2.6.27-7 kernel. With Hardy (and kernel 2.6.24), I never had this problem (however the driver produced random kernel panics when suspending the machine).

Unloading and reloading the iwl3945 kernel module doesn't help (I get the same messages in dmesg after re-modprobing it). The only way to fix is rebooting.

dmesg looks like this, after a modprobe:

[37438.188091] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
[37438.188106] iwl3945: Copyright(c) 2003-2008 Intel Corporation
[37438.189744] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[37438.189771] iwl3945 0000:03:00.0: setting latency timer to 64
[37438.189805] iwl3945: Detected Intel Wireless WiFi Link 3945ABG
[37438.199965] iwl3945: Error: saturation power is -1, less than minimum expected 40
[37438.199976] iwl3945: Invalid power index
[37438.199982] iwl3945: initializing regulatory failed: -5
[37438.204209] iwl3945: probe of 0000:03:00.0 failed with error -5

However, I haven't seen any message from iwl3945 just after a resume whis wifi failure (without manually modprobing the module).

How to reproduce the bug:
1) Suspend
2) Resume
3) Wifi works... or not.

Revision history for this message
Martin Albisetti (beuno) wrote :

I am getting exactly the same in Intrepid as well.
It used to be more random, now it's more like 9/10 times I resume, the wireless doesn't work until I reboot.
I'm on a Dell XPS M1330 with intel gfx and Ubuntu preinstalled

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Guys,

Care to test a few things . . . Can you first try installing "linux-backports-modules-intrepid" to see if it helps. It contains an updated compat-wireless stack. If that doesn't seem to help, care to test and confirm if this issue remains with the most recent pre-release of Jaunty 9.04 (currently Alpha4) - http://cdimage.ubuntu.com/releases/jaunty/ . It contains a newer 2.6.28 based kernel. You should be able to suspend via a LiveCD to try and reproduce. Please let us know your results. Thanks.

Changed in linux:
status: New → Incomplete
Revision history for this message
Greg Michalec (greg-primate) wrote :

I am experiencing a very similar, if not the same, problem. I'm running the latest Jaunty kernel (2.6.28-11-generic). Occasionally, after resuming from suspend-to-ram, my internal iw3945 nic will not respond - the wlan0 device does not exist. The problem persists after removing and re-inserting the iwl3945 module. Here are the relevent messages from dmesg:

[123713.595261] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
[123713.595268] iwl3945: Copyright(c) 2003-2009 Intel Corporation
[123713.595386] iwl3945 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[123713.595414] iwl3945 0000:0c:00.0: setting latency timer to 64
[123713.618204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[123713.618239] iwl3945 0000:0c:00.0: PCI INT A disabled
[123713.618276] iwl3945: probe of 0000:0c:00.0 failed with error -5

slightly different from what's posted above, but the symptoms are the same. The only way I can figure out to re-enable the wireless is to reboot.

Let me know if there is additional info that can be provided.

Thanks!

Revision history for this message
Greg Michalec (greg-primate) wrote :

Changing from Incomplete back to New, as the problem persists in Jaunty kernel

Changed in linux (Ubuntu):
status: Incomplete → New
Revision history for this message
Thorsten S. (thorsten-s) wrote :

I am using vanilla kernel 2.6.28, no problem. But if I use 2.6.29 (and 2.6.29.2), built with old config, the problem occurs as described above.

What confuses me, is that other users with 2.6.28 have the bug, too. I think, that there is some incompatible setting. If you need diffs, send mail to mail at aero2k.de (or write it here, I'll read it).

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Care to test and confirm this remains with the latest Karmic 9.10 release? ISO CD images can be found at http://cdimage.ubuntu.com/releases/karmic/ . You should be able to test using a LiveCD. Thanks.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Greg Michalec (greg-primate) wrote :

Hi -
I'm running current Karmic 9.10 beta (2.6.31-14-generic), and am experiencing this problem. What's odd is that I had thought this issue had gone away in Jaunty, but upon doing a fresh install of karmic beta, it's back. It seems I have a 50/50 chance of having the iwl3945 come back upon resume. I've compared syslogs of a successful wakeup vs. a failed one, and the difference seems to occur here:

Here is the failed entry:
Oct 15 17:26:08 lappy586 NetworkManager: <info> Waking up...
Oct 15 17:26:08 lappy586 NetworkManager: <info> (wlan0): now managed
Oct 15 17:26:08 lappy586 NetworkManager: <info> (wlan0): device state change: 1 -> 2 (reason 2)
Oct 15 17:26:08 lappy586 NetworkManager: <info> (wlan0): bringing up device.
Oct 15 17:26:08 lappy586 kernel: [ 7391.036019] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
Oct 15 17:26:08 lappy586 kernel: [ 7391.036019] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
Oct 15 17:26:08 lappy586 kernel: [ 7391.036019] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
Oct 15 17:26:08 lappy586 kernel: [ 7391.086873] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
Oct 15 17:26:08 lappy586 kernel: [ 7391.198189] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF

and here is a successful wakeup (discarding non-NetworkManager messages):
Oct 15 17:44:38 lappy586 NetworkManager: <info> Waking up...
Oct 15 17:44:38 lappy586 NetworkManager: <info> (wlan0): now managed
Oct 15 17:44:38 lappy586 NetworkManager: <info> (wlan0): device state change: 1 -> 2 (reason 2)
Oct 15 17:44:38 lappy586 NetworkManager: <info> (wlan0): bringing up device.
Oct 15 17:44:38 lappy586 kernel: [ 1048.313312] Registered led device: iwl-phy0::radio
Oct 15 17:44:38 lappy586 kernel: [ 1048.313330] Registered led device: iwl-phy0::assoc
Oct 15 17:44:38 lappy586 kernel: [ 1048.313386] Registered led device: iwl-phy0::RX
Oct 15 17:44:38 lappy586 kernel: [ 1048.313402] Registered led device: iwl-phy0::TX
Oct 15 17:44:38 lappy586 kernel: [ 1048.341468] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 15 17:44:38 lappy586 NetworkManager: <info> (wlan0): preparing device.
Oct 15 17:44:38 lappy586 NetworkManager: <info> (wlan0): deactivating device (reason: 2).
Oct 15 17:44:38 lappy586 NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Oct 15 17:44:38 lappy586 NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Oct 15 17:44:38 lappy586 NetworkManager: <info> (eth0): now managed

--greg

Changed in linux (Ubuntu):
status: Incomplete → New
Revision history for this message
Anakin Starkiller (sunrider) wrote :

Same problem here and it's not working even randomly...
When I tried to reload iwl3945 with modprobe iwl3945, i've got "MAC is in deep sleep" message :
 localhost kernel: [ 1583.642406] ACPI handle has no context!
 localhost kernel: [ 1583.661271] ACPI handle has no context!
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.680204] iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x000003C8
 localhost kernel: [ 1583.916370] iwl3945 0000:0c:00.0: Microcode HW error detected. Restarting.

Revision history for this message
Anakin Starkiller (sunrider) wrote :

To complete my previous comment : I have kernel 2.6.31-14.

Revision history for this message
Jonas G. Drange (jonas-drange) wrote :

I get this error 20% of normal boots, 100% in failsafe gnome. I don't know if this is a hint?

Revision history for this message
Anakin Starkiller (sunrider) wrote :

Jonas G. Drange >> I guess it's related to policykit authorization about kill swith / radio off/on which is not available in polkit-gnome anymore....

Revision history for this message
juanjux (juanjux) wrote :

I have exactly the same problem (on Karmic). In my case the "mac is in deep sleep" problem happens everytime after a suspend to RAM.

Revision history for this message
Ismael Barros (razielmine) wrote :

I have this very problem on my ArchLinux. It probably should be reported upstream.

$ dmesg # after returning from sleep
...
iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
...

$ uname -a
Linux Bebop 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 11:12:58 CEST 2009 i686 Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz GenuineIntel GNU/Linux

$ dmesg |grep iwl # after rebooting
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
iwl3945: Copyright(c) 2003-2009 Intel Corporation
iwl3945 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwl3945 0000:0c:00.0: setting latency timer to 64
iwl3945 0000:0c:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels
iwl3945 0000:0c:00.0: Detected Intel Wireless WiFi Link 3945ABG
iwl3945 0000:0c:00.0: irq 31 for MSI/MSI-X
phy0: Selected rate control algorithm 'iwl-3945-rs'
iwl3945 0000:0c:00.0: firmware: requesting iwlwifi-3945-2.ucode
iwl3945 0000:0c:00.0: loaded firmware version 15.32.2.9
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX

Revision history for this message
juanjux (juanjux) wrote :

After I did an apt-get update && apt-get dist-upgrade, which updated the kernel and some other bits, the problem seems to be gone on my computer, I've only came back from sleep three or four times, but it seems now the wifi always return while previously it would fail 100%.

Revision history for this message
^_Pepe_^ (jose-angel-fernandez-freire) wrote :

Hi Dhenry,

As main bug reporter, please, can you also confirm that this is not an issue yet? [in 9.10?]

Thanks!

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
dhenry (tfc-duke) wrote :

Unfortunately I no longer use suspend to ram, because once I spilled some water on my laptop, and since an hardware problem makes it resume itself randomly :(

So I can't confirm if I still encounter this bug or not.

Revision history for this message
juanjux (juanjux) wrote :

Hi again,

I can say that with the kernel upgrade the problem is not totally fixed here. It went to 100% of times with no wifi after suspend to maybe 20-30%, but the problem is still there.

Revision history for this message
^_Pepe_^ (jose-angel-fernandez-freire) wrote :

Thanks all for your comments

Changed in linux (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Nickolai Toupikov (nickolaitoupikov) wrote :

I am still having this issue with 9.10 (regression from 9.04) on a vaio VGN-FZ18M

nickolai@nexus:~$ lspci -s 06:00.0
06:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

see :
https://bugs.launchpad.net/bugs/470709

Changed in linux (Ubuntu):
status: Fix Released → Incomplete
Revision history for this message
Ian Halpern (ihh) wrote :

Experiencing the same bug with matching iwl3945 messages in the kernel log on a Vaio PCG-7112L running karmic 9.10

Revision history for this message
^_Pepe_^ (jose-angel-fernandez-freire) wrote :

Hi all,

Please can you try with last kernel version, which is located on http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32/?

Thanks in advance.

Revision history for this message
juanjux (juanjux) wrote :

I'll try in a few hours and report.

Revision history for this message
juanjux (juanjux) wrote :

No, with the new kernel tonight the wifi was restored 3 times after sleep, but this morning it didn't return. It seems that this happens when the laptop has been sleeping for some time.

(But this kernel boots pretty fast.)

Revision history for this message
firewall_03 (robertsr) wrote :

I have some the same problem its a hit and miss, it seems like it only happens after it has been suspended overnight or for long periods of time I am also running Karmic i386 and my laptop in a Sony Vaio VGN-NR160E.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
juanjux (juanjux) wrote :

I can confirm that this still happens on 10.04 - in fact now wifi dies after suspend almost 100% of the time, while on 9.10 with the new kernels it was doing it only about 1 in 4 times.

Revision history for this message
chrhei (chrhei) wrote :

I've discovered the same problem with Ubuntu 10.04, kernel 2.6.32-22-generic on a Lenovo Thinkpad R61. Accidentally I've found following solution for me:

echo enabled > /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/power/wakeup

I don't know what it does, but it seems to work. Suspend and resume works now as expected. Maybe this is useful for
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/581441 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/406060.

Revision history for this message
chrhei (chrhei) wrote :

Sorry for the false alarm :-( "My" solution isn't a solution. It just makes resume more often to work. After 8-10 times I get:

freedom1 wpa_supplicant[1379]: Trying to associate with 00:24:fe:xx:xx:xx (SSID='WLAN-XXX' freq=2462 MHz)
May 30 11:06:17 freedom1 NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating
May 30 11:06:17 freedom1 kernel: [ 1918.968034] wlan0: direct probe to AP 00:24:fe:xx:xx:xx (try 1)
May 30 11:06:17 freedom1 kernel: [ 1919.160100] wlan0: direct probe to AP 00:24:fe:xx:xx:xx (try 2)
May 30 11:06:17 freedom1 kernel: [ 1919.360051] wlan0: direct probe to AP 00:24:fe:xx:xx:xx: (try 3)
May 30 11:06:17 freedom1 kernel: [ 1919.560086] wlan0: direct probe to AP 00:24:fe:xx:xx:xx timed out
May 30 11:06:27 freedom1 wpa_supplicant[1379]: Authentication with 00:24:fexx:xx:xx: timed out.

Revision history for this message
David Tomaschik (matir) wrote :

I'm having an interesting pattern here. On the 2nd resume after each reboot, wifi doesn't come up. I get:
iwl3945 0000:0c:00.0: MAC is in deep sleep!. CSR_GP_CNTRL=0xFFFFFFFF
etc.

This is on a Lucid system, tested both i386/x86_64, all current updates.

Revision history for this message
Sergey Klimov (nbdarvin) wrote :

same problem on Maverick and sony ar vgn71 laptop

Revision history for this message
Michael Werle (lemmurg) wrote :

Affects me on a Vaio TX47, using Ubuntu 10.04, kernel 2.6.32-26, 32-bit.

Same issue if booting with the hardware switch in the 'off' position, or toggling the wifi kill switch to 'off' then back to 'on'.

I can reliably re-awaken the card with the following command:
$ echo 1 | sudo tee `find /sys/devices -name state | grep ieee80211`

Seems that the killswitch state doesn't transition back to 'on' properly?

state == 2
Occurs when the killswitch is in the physical off position.
Syslog: "NetworkManager: <info> WiFi now disabled by radio kill switch

state == 1
Occurs when the killswitch is in the physical 'on' position, but only after a boot.

state == 0
Occurs with killswitch in the physical 'on' position after wake-from-sleep, or toggling the killswitch from 'off' to 'on'.
Syslog: "NetworkManager: <info> WiFi now disabled by radio kill switch

Revision history for this message
Giancarlo Panizzo (giancarlo-panizzo) wrote :
Download full text (6.6 KiB)

PresarioC700, Ubuntu Lucid, kernel 2.6.32-28-generic, 32-bit.
Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02).

The wireless doesn't work after suspension all the times. Useless removing and reinstalling iwl3945.

Here the output of dmesg, separated in before/after suspension:

gian@gian-laptop:/$ dmesg | egrep 'iwl|MAC|wl|ire'
[ 0.000000] kernel direct mapping tables up to 377fe000 @ 7000-c000
[ 0.366080] ACPI Warning for \_SB_.PCI0._OSC: Parameter count mismatch - ASL declared 5, ACPI requires 4 (20090903/nspredef-336)
[ 0.369149] ACPI Warning for \_SB_.PCI0._OSC: Parameter count mismatch - ASL declared 5, ACPI requires 4 (20090903/nspredef-336)
[ 1.668369] scsi 2:0:0:0: Direct-Access ATA SAMSUNG HM121HI LZ10 PQ: 0 ANSI: 5
[ 6.980546] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
[ 6.980550] iwl3945: Copyright(c) 2003-2009 Intel Corporation
[ 6.980623] iwl3945 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 6.980639] iwl3945 0000:01:00.0: setting latency timer to 64
[ 7.051572] iwl3945 0000:01:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels
[ 7.051576] iwl3945 0000:01:00.0: Detected Intel Wireless WiFi Link 3945ABG
[ 7.061021] iwl3945 0000:01:00.0: irq 27 for MSI/MSI-X
[ 7.938373] phy0: Selected rate control algorithm 'iwl-3945-rs'
[ 47.861080] iwl3945 0000:01:00.0: firmware: requesting iwlwifi-3945-2.ucode
[ 47.935282] iwl3945 0000:01:00.0: loaded firmware version 15.32.2.9
[ 48.006074] Registered led device: iwl-phy0::radio
[ 48.006098] Registered led device: iwl-phy0::assoc
[ 48.006119] Registered led device: iwl-phy0::RX
[ 48.006138] Registered led device: iwl-phy0::TX
[ 48.017040] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 58.389097] wlan0: deauthenticating from 00:1e:c1:65:20:80 by local choice (reason=3)
[ 58.391919] wlan0: direct probe to AP 00:1e:c1:65:20:81 (try 1)
[ 58.393618] wlan0: direct probe responded
[ 58.393623] wlan0: authenticate with AP 00:1e:c1:65:20:81 (try 1)
[ 58.394121] wlan0: authenticated
[ 58.394144] wlan0: associate with AP 00:1e:c1:65:20:81 (try 1)
[ 58.396286] wlan0: RX AssocResp from 00:1e:c1:65:20:81 (capab=0x11 status=0 aid=1)
[ 58.396290] wlan0: associated
[ 58.397594] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 68.624169] wlan0: no IPv6 routers present
[ 473.985903] wlan0: deauthenticating from 00:1e:c1:65:20:81 by local choice (reason=3)
[ 473.990665] wlan0: deauthenticating from 00:1e:c1:65:20:81 by local choice (reason=3)
[ 473.993717] wlan0: direct probe to AP 00:1e:c1:65:20:80 (try 1)
[ 474.192233] wlan0: direct probe to AP 00:1e:c1:65:20:80 (try 2)
[ 474.392180] wlan0: direct probe to AP 00:1e:c1:65:20:80 (try 3)
[ 474.592197] wlan0: direct probe to AP 00:1e:c1:65:20:80 timed out
[ 486.704050] wlan0: direct probe to AP 00:1e:c1:65:20:80 (try 1)
[ 486.904204] wlan0: direct probe to AP 00:1e:c1:65:20:80 (try 2)
[ 487.104196] wlan0: direct probe to AP 00:1e:c1:65:20:80 (try 3)
[ 487.304202] wlan0: direct probe to AP 00:1e:c1:65:20:80 timed out
[ 492.123463] wlan0: direct probe to AP 00:1e:c1...

Read more...

Revision history for this message
Giancarlo Panizzo (giancarlo-panizzo) wrote :

I've (completely hopefully) solved the problem installing the latest linux-backports-modules-compat-wireless-2.6.36-2.6.32-27-generic.

regards

Revision history for this message
Giancarlo Panizzo (giancarlo-panizzo) wrote :

The problem has come back after a long suspension...

Revision history for this message
Giancarlo Panizzo (giancarlo-panizzo) wrote :

Please forget the last comment: the solution works, the problem has been that the compat-wireless is for linux image 2.6.32-27, and installing the 2.6.32-28 gets automatically loaded another version of the module iwl3945 (i.e 1.2.26ks). The properly working (in my laptop) version of iwl3945 is the one for wich the command

modinfo -F version iwl3945

results in

in-tree:s

and NOT

1.2.26ks

(so the one coming with the backports and not with the kernel image).

Revision history for this message
Paolo Chialastri (paolo-chialastri) wrote :

Hi Giancarlo, I'm running Ubuntu 11.10 on Vaio FZ21E. The module is the same (IWL3945) and also the WiFi Card (Intel PRO/Wireless 3945ABG).

Looking in Synaptic I' cant find 'linux-backports-modules-compat-wireless-2.6.36-2.6.32-27-generic', but only 'linux-backports-modules-headers-oneiric-generic'....

Anyway the command 'modinfo -F version iwl3945' gives me 'in-tree:s'..... so I'm not understanding how to solve, the suspend is very much useful for me !!

Revision history for this message
Paolo Chialastri (paolo-chialastri) wrote :

UPDATE: I workarounded the bug doing as follow:

After suspending, if network comes down, from terminal:

sudo rmmod <your_driver>
sudo modprobe <your_driver>

To view which driver you have give this command: 'sudo lshw -C network'
It should give back something like:

description: Wireless interface
       product: PRO/Wireless 3945ABG [Golan] Network Connection
       vendor: Intel Corporation
       logical name: wlan0
       version: 02
       configuration: broadcast=yes driver=<your_driver> driverversion=2.6.38-8-generic firmware=15.32.2.9 ip=192.168.1.111 latency=0 link=yes multicast=yes wireless=IEEE 802.11abg
       resources: irq:47 memory:edf00000-edf00fff

If doesn't work try this:
Create a file named 'config' in '/etc/pm/config.d/', by giving this: 'sudo gedit /etc/pm/config.d/config'.

Add this line: 'SUSPEND_MODULES="your_driver". Save and reboot.

Revision history for this message
penalvch (penalvch) wrote :

dhenry, thank you for reporting this and helping make Ubuntu better. Intrepid reached EOL on April 30, 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please provide the information following https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume ? As well, can you try 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 the issue remains, run the following command in the development release from a Terminal (Applications->Accessories->Terminal) as it will automatically gather and attach updated debug information to this report.

apport-collect -p linux <BUGNUMBER>

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.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.

Please let us know your results. Thanks in advance.

tags: added: intrepid needs-bisect needs-upstream-testing regression-release resume suspend
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
dhenry (tfc-duke) wrote :

I no longer use ubuntu 8.10. I'm currently running ubuntu 11.04, and haven't seen this issue for a long time. It may even have been fixed in a previous release (ubuntu 9.x or 10.x).

tags: added: kernel-fixed-upstream
Revision history for this message
penalvch (penalvch) wrote :

dhenry, this bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in linux (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Włodek (klata-pirata) wrote :

I see this issue on Ubuntu 12.04 all the way from 10.10 i think.

Revision history for this message
penalvch (penalvch) wrote :

Włodek, please file a new report by executing the following via the Terminal and feel free to subscribe me to it:
ubuntu-bug linux

Thanks!

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.