Wireless Card Fails After X Amount of Time or Y Amount of Data Transfered

These next 3 dmesg logs were taken after installing linux-backports-modules-intrepid on my system.

This dmesg log was taken after booting with the irqpoll option enabled within grub. Please note that it still tells me I should boot with irqpoll enabled, even though I already did:

[ 3189.593604] irq 16: nobody cared (try booting with the "irqpoll" option)

If there are any more tests I can do, or anything else that can be done on my end to be of any help, please just let me know. I'm really getting annoyed by this bug...

The new network-manager update released today *appears* to have resolved the issue. I no longer have the IRQ error even with the "irqpoll" option turned off in boot settings, and my wireless doesn't seem to have any issues remaining connected.

I will continue to monitor my computer over the next few days (and stress it out with large amounts of transfers) to see if the issue really does appear resolved. I'll update the next time I see an issue or at the end of the week confirming a fix.

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.

Hi Alsandair,

Can I assume since we didn't hear back from you that this is indeed fixed? Please let us know. Thanks.

No, sorry, this has not been fixed. I was very optimistic when I wrote my last post and did not experience any issues for an entire day. However, I shut down the computer, and started it back up again a few days ago (after some vacation time), and it did the same as it had before.

Attached is a dmesg output from a day or two ago to prove the problem still persists. It is also still reproduceable, and the "irqpoll" boot option still has no bearing on the situation (except that it makes the rest of my computer slow down in addition to the problem still occurring).

Is there anything else I can do to help out? Perhaps install a new kernel version, or compile something new? This is extremely frustrating, and I would like to get it fixed... If I can help out at all, beyond the logs I've provided, please be sure to let me know.

Hi Alsandair,

You might want to try installing the 2.6.27-11 kernel available in the intrepid-proposed repository. To learn how to enable intrepid-proposed refer to https://wiki.ubuntu.com/Testing/EnableProposed . Let us know how it goes. Thanks.

All of my previous testing was done on the 2.6.27-7 kernel...and so, following your lead, I updated to the 2.6.27-9 kernel and the 2.6.27-11 kernel after that. After all updates (including installing the linux-backports-modules for each kernel version), the problem is still unresolved.

More alarmingly, my wireless fails to work *at all* in kernel version 2.6.27-11. A dmesg does seem to throw some errors, though, that may be helpful. Hopefully we are nearing a solution...because this is getting increasingly frustrating on my end, as I absolutely need wireless of some kind at my university - especially in my computer science classes.

I have attached dmesg and lspci -vvnn logs for each kernel version tested today after the bug was triggered or the device failed to load. These logs are denoted by a -9 or a -11 after the name in the file.

Thank you so much for the help so far, Leann! Can you possibly think of any other tests or anything that I can do to help out? I'm willing to do just about anything!

Again, the specific kernel versions I have tested so far are, according to /proc/version_signature outputs:

Ubuntu 2.6.27-7.15-generic
Ubuntu 2.6.27-7.16-generic
Ubuntu 2.6.27-9.19-generic
Ubuntu 2.6.27-11.22-generic

This bug has persisted through all of them on my system and is reproduceable.

Is there anything else needed to change that "Incomplete" back to a "Triaged" or to something else? Just let me know and I'll see what I can do.

Thanks!!!

I've received a few kernel updates to 2.6.27-11 in the past few days and nothing has changed - it still won't let me even use my wireless card in this kernel version. Should I be filing a separate bug for the inoperability of the card within this kernel version, or should I just tack that onto this bug?

Also, thank you for changing the status back to "Triaged" - hopefully we'll reach a conclusion soon!

Is there any other information I can provide for the devs or any other tests I can run on my own to help out? Thanks!!!

Hi Alsandair,

If you can just keep updating this bug report that will be great. One additional thing you may want to test is the latest pre-release of Jaunty - http://cdimage.ubuntu.com/releases/jaunty/alpha-2/ . Again, if you can just post a comment here with your results it would be appreciated. Thanks.

Well, after a short stint with Debian Lenny and a large amount of time where my laptop was away for repairs (motherboard died), I'm back and with Kubuntu Jaunty 9.04. Problem is, this bug STILL exists! In fact, if anything, I'd say it's gotten worse.

I've done some extra research into the issue, and I've found that this bug report may possibly be a duplicate of this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/264104

So, following the instructions some people gave concerning that bug, I tried killing my wireless card:

sudo modprobe -r ipw2200

...and then getting it back up again with the hwcrypto setting turned off:

sudo modprobe ipw2200 hwcrypto=0

The effect of this is to allow the card much more up-time than without the option, although the card STILL randomly fails. It now also throws additional errors in dmesg like so:

[snip]
[82404.381577] ipw2200: Failed to send SSID: Command timed out. # my wireless drops, but the card still stays active
[82411.277154] ipw2200: Failed to send SCAN_REQUEST_EXT: Command timed out.
[82512.977996] ipw2200: Failed to send SCAN_REQUEST_EXT: Command timed out. # I realize this, and reconnect the wireless using the network management applet
[82631.977113] ipw2200: No space for Tx
[82631.977126] ipw2200: Failed to send SCAN_REQUEST_EXT: Reason -16
[82751.980508] ipw2200: No space for Tx
[82751.980522] ipw2200: Failed to send SCAN_REQUEST_EXT: Reason -16
[82871.978260] ipw2200: No space for Tx
[82871.978274] ipw2200: Failed to send SCAN_REQUEST_EXT: Reason -16
[82991.978370] ipw2200: No space for Tx
[82991.978385] ipw2200: Failed to send SCAN_REQUEST_EXT: Reason -16
[83111.979798] ipw2200: No space for Tx
[83111.979812] ipw2200: Failed to send SCAN_REQUEST_EXT: Reason -16
[83231.977437] ipw2200: No space for Tx
[83231.977453] ipw2200: Failed to send SCAN_REQUEST_EXT: Reason -16
[83266.152499] ipw2200: No space for Tx
[83266.152511] ipw2200: Failed to send CARD_DISABLE: Reason -16
[83266.196169] ipw2200 0000:05:09.0: PCI INT A disabled # card commits suicide, processor begins running at 100%
[snip] # here, the card is modprobe -r'ed, then modprobe hwcrypto=0'ed
[83676.146350] ipw2200: Firmware error detected. Restarting. # wireless drops out until the firmware has been restarted...note that I *just* re-enabled the card not too long ago!!! >.<
[snip]
# taken from the attached dmesg log, comments added by me

These errors are taken from the session I'm currently running. An interesting thing to note is that, through this, I've found a workaround for keeping the system up while getting the wireless to work. If the card throws the "ipw2200: Firmware error detected. Restarting." error and kills itself, I can modprobe -r the driver and then modprobe it again and it will begin worki...

I'm beginning to think this has nothing to do with the kernel, and has more to do with network-manager. I'm having issues connecting to WPA networks in Jaunty, so I tried installing wicd and removing network-manager. I was still unable to connect to the WPA network where I was, but.....

...my network card worked properly!!!! No errors at all!!!! See the attached dmesg log for what it *should* look like, when working properly. =D

So, I guess now the question is...is this really a bug? Or is it some configuration issue? In bug #179698 (linked above), I've had responses that the problems are fixed in Jaunty. Now, I'm using Kubuntu...and that/those user(s) may not, but the point remains that perhaps the issue *is* fixed, but only for certain users. I'll try to do some additional testing, but for the moment I'm stuck because I've had to send my laptop away again (same exact motherboard issue as last time...company failed to fix it =\).

Anything else I can do to get more info for this bug (if it is, indeed, a bug after all)? I'm kinda running out of ideas, myself...

Unfortunately it seems this bug is still an issue. Can you confirm this issue exists with the Karmic Alpha 9.10 release. Images for testing are available at http://cdimage.ubuntu.com/daily-live/current/ . Please let us know your results.

If the issue remains while still running Karmic, please run the following command which will automatically gather and attach updated debug information:

apport-collect -p linux <bug #>

Thanks in advance.

I'm seeing this currently with Karmic. My wireless simply stops working after a few hours (today, roughly 6 hours or more after startup). Nothing much was happening on the computer that was idling on IRC; when I came back, the wifi was dead, with stuff like this in kern.log:

Oct 20 15:43:02 kusanagi kernel: [21573.559107] ipw2200: Failed to send SSID: Reason -16
Oct 20 15:43:37 kusanagi kernel: [21608.594208] ipw2200: No space for Tx
Oct 20 15:43:37 kusanagi kernel: [21608.594213] ipw2200: Failed to send SCAN_REQUEST_EXT: Reason -16

Now, the only thing I tried that seemed to work was to
sudo rmmod ipw2200
sudo modprobe ipw2200

After which, it worked.

Same here on a Lenovo W500, upgraded from Jaunty x64 to Karmic x64 when 9.10 was released.

I have to restart network manager each time it disconnects:

sudo /etc/init.d/network-manager restart

Using HTTP, SSH, SMTP, BitTorrent etc. the disconnects are very rare, it's more often with BitTorrent but I didn't have it running more than a few hours at a time.

However, VoIP (Pidgin with Google Talk) and Skype disconnect often.

Google Talk can last for a whole 10 minutes call, but it seems cumulative: sometimes it disconnects during the call, but not if I restart the network manager shortly before it.

With Skype it lasts maybe one minute. It failed each time I tried. I had to use my old PowerBook G4 running MacOS X 10.5 Leopard, which worked flawlessly, so I'm inclined to think that the problem is in my Ubuntu laptop, not the ASUS WIFI router. The network is encrypted with WPA2, which might be a factor according to a post I saw in Ubuntuforums saying that the problem didn't occur if the network was not encrypted.

I don't remember having these problems before updating to Karmic from Jaunty, but I've had the laptop just since last June and was most of August without Internet access.

This might be related to bug #483322 and bug #459933.

I have the same problem as listed in the description, and it's generally pretty quick (1 < n < 5 minutes).

I thought it may be due to bad noise rejection by the wireless card, but running 'cat /proc/net/wireless' in a looping script that logs to /var/log/wireless shows the connection drops with an over-all quality value of 64/70, -46 signal strength, -72 noise, average values of 55 / -55 / -73.

I scanned for other wireless networks ( iwlist wlan0 scan ) and made sure I was using a channel others weren't (1, 4, 11 were used, so I chose 7), average values of 57. -53. -72. and still lost the connection.

The solution (which was not necessary with Windows 2000 on the same hardware) was to set the Wireless Access Point 'Control Tx Rates' to 18Mbps. This changes the way the AP sends information and "boosts the distance," although my test distance was 4 feet from the AP, no walls, direct line-of-sight, so distance wasn't an issue. Higher Tx rates use different encoding (such as 36, 48, and 54Mbps as compared to 18Mbps), and do not work as well.

I can now hold a connection at 20' through plaster walls without a problem, although a longer observation time is needed (currently on 2 days).

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.