Re: iwlagn: associating with AP causes kernel hiccup

From: Andy Lutomirski
Date: Sun Oct 19 2008 - 11:28:06 EST

Richard Scherping wrote:
Tomas Winkler schrieb:
On Fri, Oct 17, 2008 at 5:27 PM, Richard Scherping <richard-YwAN3MSemFZ6lmGzAMPh1A@xxxxxxxxxxxxxxxx> wrote:
When I associate with an AP, Linux 2.6.27 seems to "hang" for a few
seconds. During that time, all sound stops playing and keyboard and
mouse input is impossible.
I'm using Mandriva 2009.0 x86_64 with wpa_supplicant and Mandriva's
wireless network configuration tool (drakroam).

Actually I just found out that running # ifconfig wlan0 down
is enough to trigger the sound and mouse hanging for a few seconds.
And shortly after I wrote that, while associating while getting an IP
with dhclient when associating with a WPA encrypted AP, I got this
backtrace in my logs:
I have a similar problem here. No crash up to now, but the very same "hang" for a few seconds on "ifconfig wlan0 down". Interestingly this does only happen after a normal boot - once I did a suspend and resume (S3), there is no hang anymore.

Hardware: Thinkpad T61p with Intel 4965 agn
Software: Debian Lenny x86_64 with vanilla 2.6.27 kernel

Driver in 2.6.27 is not stable, please try to reproduce this in
current wireless-testing.git.

I do not have the time to compile and test wireless-testing ATM, sorry.

In fact I am annoyed by the fact that iwlagn is "known to be unstable" in a stable kernel release and that this even seems to be a totally normal thing...

Amen. This driver has been available and more-or-less working for ages. What kernel am I supposed to run if I just want a stable system? Haven't found one yet, other than distro kernels...

In any case, I've seen these complete system hiccups with iwl4965 and iwlagn since at least 2.6.25 and through quite a few wireless-testing versions. I bet that this, along with things like it, is the culprit:

In many, many functions:
spin_lock_irqsave(&priv->lock, flags);
ret = iwl_grab_nic_access(priv);

In iwl-io.h (2.6.26.something):
static inline int _iwl_grab_nic_access(struct iwl_priv *priv)
ret = _iwl_poll_bit(priv, CSR_GP_CNTRL,

static inline int _iwl_poll_bit(struct iwl_priv *priv, u32 addr,
u32 bits, u32 mask, int timeout)
int i = 0;

do {
if ((_iwl_read32(priv, addr) & mask) == (bits & mask))
return i;
i += 10;
} while (i < timeout);

return -ETIMEDOUT;

Polling the hardware waiting for firmware to do something *with IRQs disabled*? I'd really rather the drivers on my system didn't do this.

I'd attempt to fix this myself, but I have no clue what the locking rules are supposed to be.

Would I be out of line for wishing the iwlwifi developers would fix longstanding issues (latency and maybe horkage after resume, although the latter seems much improved lately) before adding fancy new things?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at