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:
Driver in 2.6.27 is not stable, please try to reproduce this in
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.
And shortly after I wrote that, while associating while getting an IP
I'm using Mandriva 2009.0 x86_64 with wpa_supplicant and Mandriva's
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.
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.
with dhclient when associating with a WPA encrypted AP, I got this
backtrace in my logs:
Hardware: Thinkpad T61p with Intel 4965 agn
Software: Debian Lenny x86_64 with vanilla 2.6.27 kernel
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:
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;
if ((_iwl_read32(priv, addr) & mask) == (bits & mask))
i += 10;
} while (i < timeout);
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/