ipw3945: Error sending LEDS_CMD. Random driver crash.

[Martin Andersson]

Binary package hint: linux-source-2.6.20

Problem:
ipw3945 driver crash with following output to dmesg. Only way to repair problem is to reboot. i.e. unloading ,reloading module and restarting helper does not work:
...
[37954.280000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[37954.880000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[37955.380000] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
[37955.880000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[37956.524000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
[37957.024000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
[37957.524000] ipw3945: Error sending ADD_STA: time out after 500ms.
[37958.024000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
[37967.032000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[37967.136000] ADDRCONF(NETDEV_UP): eth1: link is not ready
[38017.024000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[38017.524000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[38017.796000] ------------[ cut here ]------------
[38017.796000] kernel BUG at kernel/workqueue.c:323!
[38017.796000] invalid opcode: 0000 [#1]
....
(Full dmesg attached to bug.)

Steps to reproduce:
This driver crash randomly happens after a fair amount of uptime (often 10-24 h). Most frequently while running bittorrent.

Hardware:
Fujitsu-Siemens Amilo Si1520. Relevant lspci (-nvv) parts:
01:00.0 0280: 8086:4222 (rev 02)
        Subsystem: 8086:1001
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at da000000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000 Data: 0000
        Capabilities: [e0] Express Legacy Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s <512ns, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
                Link: Latency L0s <128ns, L1 <64us
                Link: ASPM L0s L1 Enabled RCB 64 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x1
(Full lspci attached to bug.)

Software:
Kernel: 2.6.20-15.27 (linux.image-2.6.20-15-generic)

Note:
#1: This bug might be related to bug #108090
#2: I have never had this problem with earlier feisty kernel versions (during alpha and beta stage)

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug does not meet the criteria for a stable release update and is being marked as Won't Fix for this particular version of the kernel. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates .
However, the issue that you reported is one that should be possible to test with the live environment of the Desktop CD of the development release - Gutsy Gibbon. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed kernel. You can find out more about the development release at http://www.ubuntu.com/testing/ .
If you do decide to test with the development release of Ubuntu please comment on this bug report and include at least the minimal information requested at http://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help.

[Ryan Novosielski (novosirj)]

My system's relevant information (this set of files does not contain the wireless error, but it is identical to the other poster's).

I personally use 2.6.22-13-rt, but I suspect the -rt has nothing to do with it. I had no problems with 2.6.17. 2.6.20 was bad for a myriad of reasons, so I never used it long enough to find out.

[Ryan Novosielski (novosirj)]

...next...

[Ryan Novosielski (novosirj)]

...and the last file.

[Brian Murray (brian-murray)]

Ryan - It would be helpful if we could have your exact crash report too. Additionally, are you using 802.11b or 802.11g to connect to your access point? Thanks again.

[Ryan Novosielski (novosirj)]

I have two different crashes. One of these was recoverable, and one of these was not (reboot required). I will note which is which where I can.

Note that I'm not 100% sure of this data and will try to capture it at the time it happens next time, but I'm working from memory on what happened in the unrecoverable case (and what action I took afterwards that may be reflected in the messages).

Note this first case is NOT the common case and the one that I am referring to. The second case is the reason I joined on to this bug (unrecoverable).

[Ryan Novosielski (novosirj)]

Forgot to address the first question -- my access point at home is a Linux 2.4 PC with a Orinoco/WaveLAN 128-bit WEP card (802.11b).

Here is the common crash case that I was referring to earlier. The crash starts, apparently, with the failure with command #07. This often displays also on shutdown (and seems in some cases to halt shutdown).

[Ryan Novosielski (novosirj)]

Does anyone reading this know if any of my boot messages (unstable TSC, etc.) or suggestions for boot parameters might affect this? The one crash asked me to add irqpoll to my boot options. I've tried adding stuff before that really had no effect, but I'd be happy to look also in this case if it's necessary.

[Brian Murray (brian-murray)]

I think it would be worth trying as all the error messages deal with interrupts or IRQ in the first crash. Thanks again.

[Ryan Novosielski (novosirj)]

I haven't had this problem since, but what is the downside? I see a lot of stuff related to IRQ's in 'top' (pretty sure that wasn't there before).

Also, I see a new assignment and a confirmation. Curious what the current status is.

[SunnyBUG (sunnybug)]

Same for me (4-6 hours of running BitTorrent)
But in 1-2 minutes after this messages laptop completely locks up.

[Søren Boll Overgaard (boll-fork)]

I can confirm this error on a Lenovo Thinkpad X61s. The error occurs at random intervals between 30 minutes and 12 hours after boot. It is necessary to reboot the system to fix the lockup.

~$ lspci | grep -i wireless
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
~$

The log shows this:
[ 3115.204000] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
[ 3117.120000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
[ 3117.620000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
[ 3118.120000] ipw3945: Error sending ADD_STA: time out after 500ms.
[ 3118.620000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
[ 3177.620000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[ 3178.120000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[ 4640.996000] ADDRCONF(NETDEV_UP): eth0: link is not ready

~$ uname -a
Linux diablo 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

I am running Gutsy, and never saw this problem with feisty. If you need additional information, please let me know.

[Ryan Novosielski (novosirj)]

Try adding irqpoll to your kernel boot options. This seems to have alleviated the problem for me. There should be a proper fix for this though.

[SunnyBUG (sunnybug)]

Tried that before already, nothing changed, still hardware lockups in 8-12h
of active use.

On 10/24/07, Ryan Novosielski <email address hidden> wrote:
>
> Try adding irqpoll to your kernel boot options. This seems to have
> alleviated the problem for me. There should be a proper fix for this
> though.
>
> --
> ipw3945: Error sending LEDS_CMD. Random driver crash.
> https://bugs.launchpad.net/bugs/109887
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Søren Boll Overgaard (boll-fork)]

I tried adding irqpoll as well. All it did was slow the machine to a crawl and the error keeps occurring.

[YorTheGreat (jord-swart)]

Can confirm the bug on a Dell D830. It is almost driving me back to feisty.

[Luke12 (luca-venturini)]

Running Gutsy with this driver on a Dell Inspiron 6400, never had this bug occurring in a month or so, with heavy usage, and costant use of suspend-to-ram, ecc. (I do have other issues with the driver, relating to suspend-to-ram, but this is a whole another story). I do not know what in my hw/sw configuration may protect me.

[razboinik (razboinik)]

Upgraded to Gutsy over the weekend and being driven nuts with this bug
I'm on a Dell Inspiron 9400

lspci | grep -i wireless
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
uname -r
2.6.22-14-generic

Fortunately I can restart the driver without restarting
/etc/init.d/networking stop ; modprobe -r ipw3945 ieee80211 ; sleep 2 ; modprobe ipw3945 ieee80211

My router is a 802.11g
And it crashes more often when using bittorrent

this is annoying, any fix yet?

[paulten (paul-tenfjord)]

Also discussed here :
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/71510

This is driving me crazy. I need a reboot to reload the module.
This seems to be a ubuntu only kernel error... I wish I was a kernel dev.

Any suggestions?

[Mats Taraldsvik (meastp)]

I also have this problem on a Dell D830

$ uname -r
2.6.22-14-generic
$ lspci | grep -i wireless
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
$

[tk23 (masq-fischlustig)]

Same to me.

* It's a Dell Latitude D630 and it happens usually on large data transfers. Reboot helps.
* Reloading modules helps, but sometimes the laptop crashes shortly after reloading.
* Crashing drived can be reproduced if "iwpriv eth1 set_power 5" and laptop is not on AC.

$ uname -a
Linux host 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

$ dmesg
[ 553.812000] SysRq : Changing Loglevel
[ 553.812000] Loglevel set to 6
[ 5891.924000] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
[ 5893.524000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
[ 5894.024000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
[ 5894.524000] ipw3945: Error sending ADD_STA: time out after 500ms.
[ 5895.024000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
[ 5898.556000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[ 5929.412000] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 5954.028000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[ 5954.528000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
[ 5957.524000] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
[ 5957.636000] psmouse.c: resync failed, issuing reconnect request
[ 5957.908000] ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
[ 5958.672000] input: PS/2 Mouse as /class/input/input8
[ 5958.692000] input: AlpsPS/2 ALPS GlidePoint as /class/input/input9
[ 5960.848000] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 5971.696000] eth1: no IPv6 routers present
[ 5981.356000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
[ 5981.368000] ipw3945: ERROR: No TX rate available.
[ 5981.368000] ipw3945: tx cmd rate scale failed.

$ lspci |grep Wireless
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

$ lspci -nvvv -d 8086:4222
0c:00.0 0280: 8086:4222 (rev 02)
        Subsystem: 8086:1021
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
        Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
        <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at fe8ff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

$ iwpriv
eth1 Available private ioctls :
          set_power (8BE0) : set 1 int & get 0
          get_power (8BE1) : set 0 & get 80 char
          set_mode (8BE2) : set 1 int & get 0
          get_mode (8BE3) : set 0 & get 80 char
          set_preamble (8BE4) : set 1 int & get 0
          get_preamble (8BE5) : set 0 & get 16 char
          reset (8BE7) : set 0 int & get 0
          monitor (8BE6) : set 2 int & get 0

[Christopher DeMarco (demarco)]

razboinik writes that the following works:

    /etc/init.d/networking stop ; modprobe -r ipw3945 ieee80211 ; sleep 2 ; modprobe ipw3945 ieee80211

I can confirm that this works -- but first I have to switch off the wireless card using the hardware switch.

I repeat -- if you can't get the module to unload, TRY YOUR LAPTOP'S HARDWARE "WIRELESS ON/OFF" SWITCH :-)

Still, it'd be nice to have the root cause fixed in the driver :-/

[Christopher DeMarco (demarco)]

One more thing: These hangs seem to only happen at the office, where our wireless infrastructure is built on Apple AirPorts. I can't recall ever seeing this hang at home (non-Apple wireless).

How does this correlate with others' experiences?

[Mats Taraldsvik (meastp)]

I connect to a D-link DIR 655.

[SunnyBUG (sunnybug)]

For me this happens on all 3 APs I use

Apple AirPort Express
ZyXEL ADSL modem with builtin AP
D-Link

All 3 use WPA-PSK, so I belive it does not depend on manufacter,
but (MAYBE) on encryption used,

[Mats Taraldsvik (meastp)]

The router I connect to has no encryption at all, only MAC-address filtering. (I tried to give the owner a lesson in wireless security, but he wouldn't listen.)

[paulten (paul-tenfjord)]

This happens with every AP I tried so far.
I will try to use the hardware switch and unloading the NIC next time, hopefully it won't be for a couple of hours, since it just happend :-(
Looking forward to the next kernel update...

Paul

[paulten (paul-tenfjord)]

This is by far the most annoying bug I have experienced in my 6 years as a linux user, it's a bug the at random makes us need a reboot. I suggest a higher priority.

Paul

[Mats Taraldsvik (meastp)]

Agreed. I have disabled wireless in BIOS and use wired network.

[SunnyBUG (sunnybug)]

Same here... using wired network only now.
Makes my Ubuntu useless...

Developers say that this bug won't be fixed in Gutsy.
Because it is not release-critical.
I think it is....

[paulten (paul-tenfjord)]

I can confirm that when using the hardware off switch for the card, then stopping the network and unloading the module works.
The crash interval seems to be accelerated when using vpn, perhaps because the nic is under heavier load? Crashed 3 times since my last post.

SunnyBug,
It is marked Assigned to ubuntu kernel team, if it was considered a non release-critical bug they would have marked it "Wont Fix".
When marked wont fix, it won't be fixed before the next release cycle.

I am right?

I think all of us with this problem agree that this IS a release critical bug. Google shows no other distributions with this problem, hence it seems to be a critical ubuntu only bug.

There are also some duplicate bugs on lanchpad describing similar issues.

Paul

[Kristian Hellquist (kristian-hellquist)]

Same problem here. Im gonna try razboinik's suggestion next time the driver
crash (T - 3 h)

[amine Say (aminesay)]

HAving the same problem on Sony vaio vgn-FE21h
Dmesg output:

ipw3945: Radio Frequency Kill Switch is On:
[117933.680000] Kill switch must be turned off for wireless networking to work.
[117933.736000] usb 3-1: USB disconnect, address 90
[117934.408000] ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
[117934.732000] usb 3-1: new full speed USB device using uhci_hcd and address 91
[117934.764000] ipw3945: Radio Frequency Kill Switch is On:
[117934.764000] Kill switch must be turned off for wireless networking to work.
[117935.264000] ipw3945: Error sending ADD_STA: time out after 500ms.
[117935.764000] ipw3945: Error sending RATE_SCALE: time out after 500ms.
[117936.000000] usb 3-1: new full speed USB device using uhci_hcd and address 92
[117936.204000] usb 3-1: configuration #1 chosen from 1 choice

Turning the hard switch dosn't change anything. I have to reboot to make it work again. This never happened in feisty, and i'm getting it now almost every 2 days!!

[Niels Klomp (nk-careworks)]

I can confirm this bug on a Dell Vostro 1700 running Feisty.

It is definitely related with high network traffic, since it occurs guaranteed within 40 minutes of remote X usage, whilst at other moments it occurs only sporadicly.

This is the worst bug I have ever encountered in the 9 years I am using Linux.

$ uname -a
Linux host 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

$ lspci |grep Wireless
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

Nov 27 23:57:02 cw-mobile2 kernel: [15954.176000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
Nov 27 23:57:02 cw-mobile2 kernel: [15954.676000] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
Nov 27 23:57:04 cw-mobile2 kernel: [15956.172000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
Nov 27 23:57:04 cw-mobile2 kernel: [15956.672000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
Nov 27 23:57:05 cw-mobile2 kernel: [15957.172000] ipw3945: Error sending ADD_STA: time out after 500ms.
Nov 27 23:57:05 cw-mobile2 kernel: [15957.672000] ipw3945: Error sending SCAN_ABORT_CMD: time out after 500ms.
Nov 27 23:57:09 cw-mobile2 kernel: [15961.176000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
Nov 27 23:57:25 cw-mobile2 NetworkManager: <info> eth1: link timed out.
Nov 27 23:57:25 cw-mobile2 NetworkManager: <info> SWITCH: found better connection 'eth1/CareWorksH' than current connection 'eth1/CareWorksH'. same_ssid=1, have_link=0
Nov 27 23:57:25 cw-mobile2 NetworkManager: <info> Will activate connection 'eth1/CareWorksH'.
Nov 27 23:57:25 cw-mobile2 NetworkManager: <info> Device eth1 activation scheduled...
Nov 27 23:57:25 cw-mobile2 NetworkManager: <info> Deactivating device eth1.
Nov 27 23:57:25 cw-mobile2 dhclient: There is already a pid file /var/run/dhclient.eth1.pid with pid 6341
Nov 27 23:57:25 cw-mobile2 dhclient: killed old client process, removed PID file
Nov 27 23:57:25 cw-mobile2 dhclient: DHCPRELEASE on eth1 to 10.14.14.1 port 67
Nov 27 23:57:25 cw-mobile2 avahi-daemon[5784]: Withdrawing address record for 10.14.14.101 on eth1.
Nov 27 23:57:25 cw-mobile2 avahi-daemon[5784]: Leaving mDNS multicast group on interface eth1.IPv4 with address 10.14.14.101.
Nov 27 23:57:25 cw-mobile2 avahi-daemon[5784]: Interface eth1.IPv4 no longer relevant for mDNS.
Nov 27 23:57:26 cw-mobile2 avahi-daemon[5784]: Withdrawing address record for fe80::21b:77ff:fec3:4893 on eth1.
Nov 27 23:57:26 cw-mobile2 NetworkManager: <info> Activation (eth1) started...
Nov 27 23:57:26 cw-mobile2 NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
Nov 27 23:57:26 cw-mobile2 NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) started...
Nov 27 23:57:26 cw-mobile2 NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) scheduled...
Nov 27 23:57:26 cw-mobile2 NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) complete.
Nov 27 23:57:26 cw-mobile2 NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) starting...
Nov 27 23:57:26 cw-mobile2 NetworkManager: <info> Activation (eth1/wirele...

[Siegie (siegie)]

i replaced ipw3945 with iwl3945 and al is working 100% stable now.
blacklist ipw3945
/etc/modules iwl3945
use te following fix http://wiki.debian.org/iwl4965
more info on my blog http://siegie.sin.khk.be/wordpress/2007/12/03/eindelijk-stabiel-draadloos-internet/

[fgiust (fgiust)]

bug confirmed on another dell D830.
Connected to a 802.11g ap with WPA protection, crashes occours every few (1-2) hours and the only solution is to restart.

[Bas Kok (bakotaco)]

and confirmed on another dell d830 with any ap. seems to happen more often when heavy udp traffic is involved (streaming video for instance)

[Marcj (marcdejonge)]

Bug confirmed on a Dell M6300

I had this bug on a networks with static WEP, WPA-PSK and EAP-TTLS. It seems to happen most often with heavy traffic, using a terminal server. Also sometimes it crashes within 5 minutes and sometimes it keeps on working for hours without any problem.

[hhao1985 (diverhao)]

Bug confirmed on a HP dv6500

gutsy, Intel wireless card

The syslog is exactly the same with the bug description above.

[Max86 (dsmart-theptrgroup)]

I also have a Dell M6300. This is a show-stopper! It needs a higher priority. (It's time to switch back to redhat!)

[Patrick Engelman (patrick-directitcorp)]

I had this same problem on a 3945 on a Dell Inspiron 1420 notebook.

The fix suggested above worked, I added a line saying:
blacklist ipw3945
to the /etc/modprobe.d/blacklist file

and I added another line saying:

iwl3945

to /etc/modules

I would consistantly reproduce the crash within 10 minutes by attempting to copy several gigs of data over the network. With the new module the data transfer works fine.

[paulten (paul-tenfjord)]

I get the same error with iwl3945.

[Leann Ogasawara (leannogasawara)]

Hardy Heron Alpha2 was recently released. It contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ . You should be able to then test the new kernel via the LiveCD. 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/hardy/alpha2 . Thanks!

[Leann Ogasawara (leannogasawara)]

I also just wanted to add a note that the ipw3945 project has been deprecated according to the following site:

http://ipw3945.sourceforge.net/

Development efforts have switched to the iwlwifi project:

http://intellinuxwireless.org/

[Andres Mujica (andres.mujica)]

Just reporting the same bug in other trackers as well as the intel one.

http://bughost.org/bugzilla/show_bug.cgi?id=1260
http://bugs.archlinux.org/task/7709

[Arthur Bogard (arthur-bogard-gmail)]

Well, it looks like this is an issue that others are having. I'll post whatever relevant information I think you all might need.

First off, the description of what happened (this is the second time this happened). I use a Gateway c-140xl with Gutsy. I had uptime for something around 18-20hrs. The computer was running well for the entire time until the crash. I was using Firefox and Bittorrent (although last time this happened, I wasn't using bittorrnet, nor had I used it prior in the boot). Anyway, suddenly the CPU throttles to 50% (well, 100% on one core and almost none on the other) and the wireless network is disconnected. I open the system monitor and notice that the ipw3945/0 thread is uninteruptable at 50% CPU usage. I have a terminal open already, so I decide to modprobe the driver and then when that doesn't work, I try to set eth1 to monitor mode. At this time, the CPU usage goes back down, but the process is still uninteruptable. I right-click on the process to kill it, and the system-monitor application crashes. Then I tried killing the process from the terminal, and the terminal freezes. So, I decide to Ctl-alt-bksp and reboot X. This fails, and it just gets stuck in the terminal. I push the power button, and it starts shutting down. That's no big deal, until it refuses to finish shutting down. Instead, it says: "mount: / is busy" and "will halt now" and just sticks there. I have to force shut things down from there. Looking at the log, the relevant information is as follows:

from kern.log:
Jan 21 19:03:49 Camelot kernel: [37012.712000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
Jan 21 19:03:50 Camelot kernel: [37013.212000] ipw3945: Error sending ADD_STA: time out after 500ms.
Jan 21 19:03:50 Camelot kernel: [37013.712000] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
Jan 21 19:03:54 Camelot kernel: [37017.240000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
Jan 21 19:04:13 Camelot kernel: [37036.220000] ADDRCONF(NETDEV_UP): eth1: link is not ready
Jan 21 19:04:27 Camelot kernel: [37050.284000] ADDRCONF(NETDEV_UP): eth1: link is not ready
Jan 21 19:04:50 Camelot kernel: [37073.856000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
Jan 21 19:04:51 Camelot kernel: [37074.356000] ipw3945: Error sending LEDS_CMD: time out after 500ms.

From syslog
Jan 21 19:03:49 Camelot kernel: [37012.712000] ipw3945: Error sending cmd #08 to daemon: time out after 500ms.
Jan 21 19:03:50 Camelot kernel: [37013.212000] ipw3945: Error sending ADD_STA: time out after 500ms.
Jan 21 19:03:50 Camelot kernel: [37013.712000] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
Jan 21 19:03:54 Camelot kernel: [37017.240000] ipw3945: Error sending LEDS_CMD: time out after 500ms.
Jan 21 19:04:10 Camelot NetworkManager: <info> eth1: link timed out.
Jan 21 19:04:10 Camelot NetworkManager: <info> SWITCH: found better connection 'eth1/camelot' than current connection 'eth1/camelot'. same_ssid=1, have_link=0
Jan 21 19:04:10 Camelot NetworkManager: <info> Will activate connection 'eth1/camelot'.
Jan 21 19:04:10 Camelot NetworkManager: <info> Device eth1 activation sc...

[Leann Ogasawara (leannogasawara)]

Care to test with a Hardy Alpha LiveCD? http://cdimage.ubuntu.com/releases/hardy . Also, please use the iwlwifi (iwl3945) driver rather than ipw3945. iwlwifi is included in Ubuntu Hardy kernel. Thanks.

[pearcec (christian-pearcec)]

Tried blacklisting ipw3945 and adding iwl3954 but now the network doesn't work at all. Downloading Hardy for a Live test.

[Jens Einar Vaskinn (vaskinn)]

Using Gutsy on a D830, updated from all repositories (proposed, universe, multi-universe, backports)

$ uname -a
Linux host 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux

$ lspci | grep -i wireless
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

Tried both the ipw3945, iwl3945 and using Hardy alpha-3. No luck on either of them. While using iwl3945 i have the same symptoms but a bit different entries in the log (I forgot to save the dmesg from the live cd, but if I'm not totally wrong it was very similar to using iwl3945 with gutsy):

[Leann Ogasawara (leannogasawara)]

HI Jens,

Your dmesg cache seems to have filled up and written over the initial boot logs. Care to recapture it for Hardy? Also note that Hardy Alpha4 will be released in a few days so you may want to wait to test with the newer release which will have an updated kernel. If the issue still exists, per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again.

[Andrea Caminiti (nrayever)]

hi everyone:

i got some problems with my ipw3945. the wifi is working ok, but the problem that i have is that the connection led (or the indicator that the wifi is enable) it's not working! so i don't really know whats happening. i don't know when the wifi is enable. i just depend on the nm-applet to know it. is there any way to solve this or is part of this bug??

nrayever

[Patrick Engelman (patrick-directitcorp)]

Another update -- earlier I said that the problem went away when switching to iwl3945 from ipw3945 on my Dell Inspiron 1420. Actually, with the iwl3945 version included in the latest kernel for Ubuntu 7.10, I still experienced periodic network lockups (on the order of once a week or so), just not nearly as bad. I found instructions here

http://jkyamog.blogspot.com/2007/12/linux-install-on-hp-6910p-using-ubuntu.html

on how to rebuild the linux-ubuntu-modules-2.6.22-14-generic package from source after updating the source for the mac80211 and iwlwifi packages to the latest versions. This has resolved the lockup issues but wireless still does not work after suspend or hibernate.

[Leann Ogasawara (leannogasawara)]

Again, if you can please test with the latest 8.04 Hardy Alpha release that would be great. The Hardy Heron Alpha 5 series was recently released which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Also please note that we will keep this report open against the latest development kernel but this will be closed against 2.6.20 and 2.6.22. Thanks.

[Arthur Bogard (arthur-bogard-gmail)]

Hardy Alpha works great. Wireless usually resumes just fine from suspend
(although once in a blue moon I have to modprobe it to get it to work).
I've not had a network lockup since Alpha 3.

On Wed, Feb 27, 2008 at 9:44 AM, Leann Ogasawara <email address hidden> wrote:

> Again, if you can please test with the latest 8.04 Hardy Alpha release
> that would be great. The Hardy Heron Alpha 5 series was recently
> released which contains an updated version of the kernel. You can
> download and try the new Hardy Heron Alpha release from
> http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then
> test the new kernel via the LiveCD. General information regarding the
> release can also be found here: http://www.ubuntu.com/testing/ .
>
> Also please note that we will keep this report open against the latest
> development kernel but this will be closed against 2.6.20 and 2.6.22.
> Thanks.
>
> ** Changed in: linux-source-2.6.22 (Ubuntu)
> Status: Confirmed => Won't Fix
>
> --
> ipw3945: Error sending LEDS_CMD. Random driver crash.
> https://bugs.launchpad.net/bugs/109887
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Mikael Nilsson (mini)]

ons 2008-02-27 klockan 14:44 +0000 skrev Leann Ogasawara:
> Again, if you can please test with the latest 8.04 Hardy Alpha release
> that would be great. The Hardy Heron Alpha 5 series was recently
> released which contains an updated version of the kernel.

As I'm running Hardy from the repos, can you please be specific about
which version that you believe could contain a fix?

/Mikael

--
<email address hidden>

Plus ça change, plus c'est la même chose

[Leann Ogasawara (leannogasawara)]

Arthur, thanks for testing and the update. Glad to hear things are working for you. Martin, since you are the original bug reporter, care to comment if this is resolved for you with the latest Hardy Alpha release?

Mikael, I assume you've been pulling in the latest updates periodically. In which case you'll most likely be running the 2.6.24-10 kernel (at the time of this posting). 2.6.24-10 should be sufficient enough for you to test with. Thanks.

[Leann Ogasawara (leannogasawara)]

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.

[Mikael Nilsson (mini)]

No longer valid as Ubuntu now ships with iwl3945 and not ipw3945.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.