iwlagn: cannot allocate SKB buffers

Bug #308053 reported by Andrej Prša
6
Affects Status Importance Assigned to Milestone
linux-backports-modules-2.6.27 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

After prolonged network activity (typically during heavy traffic) the network stops responding. Wireless card remains associated with the access point (local router with WPA), but no traffic comes in or out. As this happens, /var/log/syslog obtains several tens of:

Dec 14 18:18:54 gemma kernel: [11538.519710] iwlagn: Can not allocate SKB buffers

separated by ~45 seconds. Other machines connected to the AP are unaffected, the problem is local to this computer. This is observed on a Compaq 6820s running Intrepid 64-bit. There are no other network-related messages in either syslog or messages. After disassociating and associating, everything returns back to normal.

Device:
10:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
 Subsystem: Intel Corporation Device 1100
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 2297
 Region 0: Memory at dc000000 (64-bit, non-prefetchable) [size=8K]
 Capabilities: <access denied>
 Kernel driver in use: iwlagn
 Kernel modules: iwlagn
00: 86 80 29 42 06 00 10 00 61 00 80 02 10 00 00 00
10: 04 00 00 dc 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 11
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0a 01 00 00

Module:
filename: /lib/modules/2.6.27-10-generic/updates/iwlagn.ko
alias: iwl4965
license: GPL
author: Copyright(c) 2003-2008 Intel Corporation
version: 1.3.27ks
description: Intel(R) Wireless WiFi Link AGN driver for Linux
firmware: iwlwifi-4965-2-lbm.ucode
firmware: iwlwifi-5000-1-lbm.ucode
srcversion: D21819AB73FDCB49B6A45A3
alias: pci:v00008086d0000423Bsv*sd00001011bc*sc*i*
alias: pci:v00008086d0000423Asv*sd00001021bc*sc*i*
alias: pci:v00008086d0000423Asv*sd00001001bc*sc*i*
alias: pci:v00008086d00004237sv*sd*bc*sc*i*
alias: pci:v00008086d00004236sv*sd*bc*sc*i*
alias: pci:v00008086d00004235sv*sd*bc*sc*i*
alias: pci:v00008086d00004232sv*sd*bc*sc*i*
alias: pci:v00008086d00004237sv*sd00001216bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001326bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001306bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001206bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001305bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001205bc*sc*i*
alias: pci:v00008086d00004230sv*sd*bc*sc*i*
alias: pci:v00008086d00004229sv*sd*bc*sc*i*
depends: iwlcore,lbm_cw-mac80211,lbm_cw-cfg80211
vermagic: 2.6.27-10-generic SMP mod_unload modversions
parm: disable50:manually disable the 50XX radio (default 0 [radio on]) (int)
parm: swcrypto50:using software crypto engine (default 0 [hardware])
 (bool)
parm: debug50:50XX debug output mask (int)
parm: queues_num50:number of hw queues in 50xx series (int)
parm: qos_enable50:enable all 50XX QoS functionality (int)
parm: 11n_disable50:disable 50XX 11n functionality (int)
parm: amsdu_size_8K50:enable 8K amsdu size in 50XX series (int)
parm: fw_restart50:restart firmware in case of error (int)
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: disable:manually disable the radio (default 0 [radio on]) (int)
parm: swcrypto:using crypto in software (default 0 [hardware]) (int)
parm: debug:debug output mask (int)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: queues_num:number of hw queues. (int)
parm: qos_enable:enable all QoS functionality (int)
parm: 11n_disable:disable 11n functionality (int)
parm: amsdu_size_8K:enable 8K amsdu size (int)
parm: fw_restart4965:restart firmware in case of error (int)

Revision history for this message
Andrej Prša (andrej-prsa) wrote :

Managed to get more syslog output on the bug:

[ 2876.725114] iwlagn: Microcode SW error detected. Restarting 0x2000000.
[ 2876.941557] Registered led device: iwl-phy0:radio
[ 2876.941877] Registered led device: iwl-phy0:assoc
[ 2876.942152] Registered led device: iwl-phy0:RX
[ 2876.942422] Registered led device: iwl-phy0:TX

It seems to me that the reset should be done on the active connection as well -- maybe NM should catch the microcode exception.

Revision history for this message
agenthex (hexsmith) wrote :

I've been having problems with the iwlagn module. I'm actually using Hardy 8.04.1, and I presume an update that was committed to Intrepid has been sent to Hardy as well. The LiveCD had no problems, and my disk install of Hardy had worked flawlessly for a long time. It is only recently that this has occurred, and it seems related to this thread:

http://ubuntuforums.org/showthread.php?t=962070

There is a workaround that was suggested for Intrepid that the users in that thread were unable to use successfully due to the fact that the iwl4965 module was removed from Intrepid in favor of iwlagn. Being on Hardy, I still have the iwl4965 module, so issuing the command to unload iwlagn and iwl4965 then re-load iwl4965 has so far resolved my issues:

sudo modprobe -r iwlagn iwl4965 ; sudo modprobe iwl4965

Without the proper module, this command does not function properly. If Intrepid (and presumably Jaunty) were to include iwl4965, then this workaround could be applied.

Revision history for this message
agenthex (hexsmith) wrote :

The relevant dmesg output I get when this occurs is as follows:

[ 3603.194199] wlan0: No ProbeResp from current AP 00:0f:34:8f:98:d5 - assume out of range
[ 3603.939973] wlan0: No STA entry for own AP 00:0f:34:8f:98:d5
[ 3606.456102] wlan0: No STA entry for own AP 00:0f:34:8f:98:d5
[ 3609.478726] wlan0: No STA entry for own AP 00:0f:34:8f:98:d5
[ 3616.213511] wlan0: Initial auth_alg=0
[ 3616.213531] wlan0: authenticate with AP 00:0f:34:8f:98:d5
[ 3616.290410] wlan0: authenticate with AP 00:0f:34:8f:98:d5
[ 3616.446937] wlan0: authenticate with AP 00:0f:34:8f:98:d5
[ 3616.607757] wlan0: authentication with AP 00:0f:34:8f:98:d5 timed out

I'm not entirely certain if this is due to SKB buffers, but this occurs on a fairly regular basis. Running the workaround above allows the adapter to reconnect, but I cannot stay connected long enough to transfer a full CD image.

Revision history for this message
agenthex (hexsmith) wrote :

Please disregard my posts. My problems extended to Windows XP and Vista. The chip has been replaced with an identical version, and my problem has been resolved.

Jan Schneider (yunosh)
Changed in linux-backports-modules-2.6.27:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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