Hmmm...the original deauth seems to be due to a MIC failure.  After that, I'm not sure I know what is happening -- the book I have says status code 12 is "Association denied due to reason outside the scope of this standard".

Does this happen with any other access points?

I went and bought a Linksys WRT54G (v7.0, fwiw) and was unable to reproduce the problem with that, so maybe it's an issue between the Atheros card and the Micronet AP.

I have used a number of different wifi clients (including a Nokia E51 smartphone, an Apple Ipod Touch, and several different brands of PC/notebook wifi adapters) with the Micronet AP, but this Atheros card is the first that causes it to drop its clients. Unfortunately, it doesn't have syslog.

I'm willing to test more if there is any hope of fixing the Atheros driver to work with the Micronet AP.

Just stumbled across this bug report -- maybe a MIC failure causes the AP to enter countermeasures mode (deciding to drop all clients is a bit extreme, though).  Perhaps you can try using CCMP instead of TKIP?

I don't think so; this is a pretty old AP that just supports TKIP.

However, in the meantime, I've heard of similar problems with different NICs and APs, so the issue seems to be more general (reports of this issue became more frequent with the release of Ubuntu karmic, fwiw). I'll try to get some of the affected people to post more information here.

I have an Acer Aspire One with an Atheros WLAN adapter (lspci says: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)) and I get quite frequent connection losses under high load. The kernel log looks similar to the one shown above. My AP is an Linksys WRT54GL. Please tell if and how I can provide more information.

I also have an Acer Aspire One, model AOA150, also with an Atheros WLAN adapter (lspci says: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)) And I am experiencing the very same thing as the above posters. I'm using version 2.6.32.6 of the kernel, and my router is actually almost the same type as the above poster's: a Linksys WRT54G.

I will do what I can to provide info as well.

The problem persists even ater upgrading to DD-WRT on the router. However, it doesn't seem to disconnect the other computers on the network; only the Aspire One. Also, I don't know what info will be requried of me to help with this issue or how to get it, aside from dmesg, which says this upon disconnect now that the router runs DD-WRT:

wlan0: AP denied association (code=12)
wlan0: deauthenticating from 00:1a:70:50:7b:14 by local choice (reason=3)

Let me know what else you need and how to get it.

(In reply to comment #2)
> I went and bought a Linksys WRT54G (v7.0, fwiw) and was unable to reproduce
> the
> problem with that, so maybe it's an issue between the Atheros card and the
> Micronet AP.

Correction: the Atheros card still gets disconnected from the AP, but other clients aren't.

Also, sometimes a call trace like the following appears in the kernel log:

kernel: [20045.916832] wlan0: deauthenticating by local choice (reason=3)
kernel: [20045.916896] ------------[ cut here ]------------
kernel: [20045.916938] WARNING: at /build/buildd/linux-2.6.31/drivers/net/wireless/ath/ath5k/base.c:3145 ath5k_bss_info_changed+0x1a9/0x1b0 [ath5k]()
kernel: [20045.916949] Hardware name: AOA150
kernel: [20045.916954] Modules linked in: isofs nfs lockd nfs_acl auth_rpcgss sunrpc binfmt_misc autofs4 lp parport snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 ecb snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event joydev ath5k snd_seq snd_timer mac80211 snd_seq_device uvcvideo ath videodev acerhdf i915 snd soundcore v4l1_compat drm psmouse i2c_algo_bit snd_page_alloc pcspkr serio_raw led_class cfg80211 video output xfs exportfs sha256_generic aes_i586 aes_generic cbc dm_crypt r8169 mii intel_agp agpgart fbcon tileblit font bitblit softcursor
kernel: [20045.917112] Pid: 2201, comm: wpa_supplicant Not tainted 2.6.31-18-generic #55-Ubuntu
kernel: [20045.917120] Call Trace:
kernel: [20045.917146]  [<c014513d>] warn_slowpath_common+0x6d/0xa0
kernel: [20045.917176]  [<f833bcb9>] ? ath5k_bss_info_changed+0x1a9/0x1b0 [ath5k]
kernel: [20045.917201]  [<f833bcb9>] ? ath5k_bss_info_changed+0x1a9/0x1b0 [ath5k]
kernel: [20045.917233]  [<c0145185>] warn_slowpath_null+0x15/0x20
kernel: [20045.917265]  [<f833bcb9>] ath5k_bss_info_changed+0x1a9/0x1b0 [ath5k]
kernel: [20045.917312]  [<f83656a8>] ieee80211_bss_info_change_notify+0xa8/0x1a0 [mac80211]
kernel: [20045.917348]  [<f833bb10>] ? ath5k_bss_info_changed+0x0/0x1b0 [ath5k]
kernel: [20045.917395]  [<f836d46a>] ieee80211_set_disassoc+0x1ba/0x240 [mac80211]
kernel: [20045.917440]  [<f836d58c>] ieee80211_sta_deauthenticate+0x3c/0x50 [mac80211]
kernel: [20045.917488]  [<f83743ec>] ieee80211_deauth+0x2c/0x40 [mac80211]
kernel: [20045.917537]  [<f8ed1687>] cfg80211_wext_siwmlme+0x97/0xe0 [cfg80211]
kernel: [20045.917558]  [<c05589db>] ioctl_standard_iw_point+0x18b/0x2e0
kernel: [20045.917604]  [<f8ed15f0>] ? cfg80211_wext_siwmlme+0x0/0xe0 [cfg80211]
kernel: [20045.917622]  [<c0558be5>] ioctl_standard_call+0xb5/0xf0
kernel: [20045.917660]  [<f8ed15f0>] ? cfg80211_wext_siwmlme+0x0/0xe0 [cfg80211]
kernel: [20045.917675]  [<c04a01b5>] ? __dev_get_by_name+0x85/0xb0
kernel: [20045.917689]  [<c0558cda>] T.789+0xba/0x140
kernel: [20045.917734]  [<f8ed15f0>] ? cfg80211_wext_siwmlme+0x0/0xe0 [cfg80211]
kernel: [20045.917750]  [<c0558da9>] T.790+0x49/0x80
kernel: [20045.917764]  [<c0558e0a>] wext_handle_ioctl+0x2a/0x70
kernel: [20045.917778]  [<c04a10a9>] dev_ioctl+0x249/0x250
kernel: [20045.917793]  [<c0490b0b>] sock_ioctl+0x1cb/0x260
kernel: [20045.917807]  [<c0490940>] ? sock_ioctl+0x0/0x260
kernel: [20045.917822]  [<c01f532c>] vfs_ioctl+0x1c/0x90
kernel: [20045.917835]  [<c01f5651>] do_vfs_ioctl+0x71/0x310
kernel: [20045.917849]  [<c057622b>] ? do_page_fault+0x19b/0x380
kernel: [20045.917862]  [<c01f594f>] sys_ioctl+0x5f/0x80
kernel: [20045.917877]  [<c01033ac>] syscall_call+0x7/0xb
kernel: [20045.917888] ---[ end trace 48668c25e42ef853 ]---
kernel: [20046.225038] ath5k 0000:03:00.0: PCI INT A disabled
kernel: [20046.537093] cfg80211: Calling CRDA for country: HU
kernel: [20046.609053] cfg80211: Regulatory domain changed to country: HU
kernel: [20046.609064]  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [20046.609074]  (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [20046.609083]  (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [20046.609091]  (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [20046.609099]  (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
kernel: [20046.614743] ath5k 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
kernel: [20046.614790] ath5k 0000:03:00.0: setting latency timer to 64
kernel: [20046.615005] ath5k 0000:03:00.0: registered as 'phy0'
kernel: [20047.116888] ath: EEPROM regdomain: 0x65
kernel: [20047.116895] ath: EEPROM indicates we should expect a direct regpair map
kernel: [20047.116903] ath: Country alpha2 being used: 00
kernel: [20047.116907] ath: Regpair used: 0x65
kernel: [20047.118459] phy0: Selected rate control algorithm 'minstrel'
kernel: [20047.120839] Registered led device: ath5k-phy0::rx
kernel: [20047.120900] Registered led device: ath5k-phy0::tx
kernel: [20047.120911] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
kernel: [20049.440863] ADDRCONF(NETDEV_UP): wlan0: link is not ready
kernel: [20050.438365] cfg80211: Found new beacon on frequency: 2472 MHz (Ch 13) on phy0
kernel: [20056.283258] r8169: eth0: link down
kernel: [20056.283877] ADDRCONF(NETDEV_UP): eth0: link is not ready
kernel: [20056.544786] ADDRCONF(NETDEV_UP): wlan0: link is not ready
kernel: [20058.072232] wlan0: authenticate with AP 00:18:f8:65:28:1f
kernel: [20058.073795] wlan0: authenticated
kernel: [20058.073807] wlan0: associate with AP 00:18:f8:65:28:1f
kernel: [20058.078202] wlan0: RX AssocResp from 00:18:f8:65:28:1f (capab=0x431 status=0 aid=1)
kernel: [20058.078223] wlan0: associated
kernel: [20058.085286] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
kernel: [20058.118429] cfg80211: Calling CRDA for country: DE
kernel: [20058.123235] cfg80211: Received country IE:
kernel: [20058.123244] cfg80211: Regulatory domain: DE
kernel: [20058.123248]  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [20058.123256]  (2402000 KHz - 2494000 KHz @ 40000 KHz), (10000 mBi, 10000 mBm)
kernel: [20058.123260] cfg80211: CRDA thinks this should applied:
kernel: [20058.123264] cfg80211: Regulatory domain: DE
kernel: [20058.123268]  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [20058.123275]  (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [20058.123281]  (5150000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [20058.123287]  (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
kernel: [20058.123291] cfg80211: We intersect both of these and get:
kernel: [20058.123295] cfg80211: Regulatory domain: 98
kernel: [20058.123299]  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [20058.123305]  (2402000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [20058.123316] cfg80211: Disabling channel 2484 MHz on phy0 due to Country IE
kernel: [20058.123326] cfg80211: Current regulatory domain updated by AP to: DE
kernel: [20058.123331]  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [20058.123337]  (2402000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [20068.908062] wlan0: no IPv6 routers present
kernel: [26927.318296] ath5k phy0: unsupported jumbo
kernel: [39660.293444] ath5k phy0: unsupported jumbo
kernel: [41403.487014] ath5k phy0: unsupported jumbo
kernel: [43727.860567] ath5k phy0: unsupported jumbo

Some of this may have been the result of a script I have running that automatically removes all wifi related modules when the connection goes away and then re-inserts them and attempts to re-associate. This reduces the annoyance somewhat.

I also experience this problem with the 2.6.32-19-generic kernel with Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01) (ath5k)
Some good luck today in that it will now associate, but disconnects after a minute or so.

Relevant from kern.log (I hope):

Apr  8 11:22:44 teej-laptop kernel: [  997.569500] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr  8 11:22:56 teej-laptop kernel: [ 1009.471442] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:22:56 teej-laptop kernel: [ 1009.471538] wlan0: deauthenticating from 00:1f:9f:eb:32:d9 by local choice (reason=3)
Apr  8 11:22:56 teej-laptop kernel: [ 1009.471649] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:22:56 teej-laptop kernel: [ 1009.473352] wlan0: direct probe responded
Apr  8 11:22:56 teej-laptop kernel: [ 1009.473364] wlan0: authenticate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:22:56 teej-laptop kernel: [ 1009.481391] wlan0: authenticated
Apr  8 11:22:56 teej-laptop kernel: [ 1009.481419] wlan0: associate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:22:56 teej-laptop kernel: [ 1009.483722] wlan0: RX AssocResp from 00:1f:9f:eb:32:d9 (capab=0x411 status=0 aid=2)
Apr  8 11:22:56 teej-laptop kernel: [ 1009.483728] wlan0: associated
Apr  8 11:22:56 teej-laptop kernel: [ 1009.485066] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Apr  8 11:23:02 teej-laptop kernel: [ 1015.224787] eth0: link down.
Apr  8 11:23:07 teej-laptop kernel: [ 1020.220179] wlan0: no IPv6 routers present
Apr  8 11:23:25 teej-laptop kernel: [ 1038.540099] No probe response from AP 00:1f:9f:eb:32:d9 after 500ms, disconnecting.
Apr  8 11:24:52 teej-laptop kernel: [ 1125.687685] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr  8 11:25:00 teej-laptop kernel: [ 1133.413205] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:00 teej-laptop kernel: [ 1133.413278] wlan0: deauthenticating from 00:1f:9f:eb:32:d9 by local choice (reason=3)
Apr  8 11:25:00 teej-laptop kernel: [ 1133.413360] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:00 teej-laptop kernel: [ 1133.415348] wlan0: direct probe responded
Apr  8 11:25:00 teej-laptop kernel: [ 1133.415354] wlan0: authenticate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:00 teej-laptop kernel: [ 1133.421797] wlan0: authenticated
Apr  8 11:25:00 teej-laptop kernel: [ 1133.421825] wlan0: associate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:00 teej-laptop kernel: [ 1133.424203] wlan0: RX AssocResp from 00:1f:9f:eb:32:d9 (capab=0x411 status=0 aid=1)
Apr  8 11:25:00 teej-laptop kernel: [ 1133.424209] wlan0: associated
Apr  8 11:25:00 teej-laptop kernel: [ 1133.425056] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Apr  8 11:25:08 teej-laptop kernel: [ 1141.540599] No probe response from AP 00:1f:9f:eb:32:d9 after 500ms, disconnecting.
Apr  8 11:25:09 teej-laptop kernel: [ 1143.084619] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:09 teej-laptop kernel: [ 1143.087185] wlan0: direct probe responded
Apr  8 11:25:09 teej-laptop kernel: [ 1143.087205] wlan0: authenticate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:09 teej-laptop kernel: [ 1143.088965] wlan0: authenticated
Apr  8 11:25:09 teej-laptop kernel: [ 1143.089045] wlan0: associate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:09 teej-laptop kernel: [ 1143.091343] wlan0: RX AssocResp from 00:1f:9f:eb:32:d9 (capab=0x411 status=0 aid=1)
Apr  8 11:25:09 teej-laptop kernel: [ 1143.091356] wlan0: associated
Apr  8 11:25:10 teej-laptop kernel: [ 1143.512522] wlan0: no IPv6 routers present
Apr  8 11:25:24 teej-laptop kernel: [ 1157.542579] No probe response from AP 00:1f:9f:eb:32:d9 after 500ms, disconnecting.
Apr  8 11:25:25 teej-laptop kernel: [ 1159.094404] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:25 teej-laptop kernel: [ 1159.096144] wlan0: direct probe responded
Apr  8 11:25:25 teej-laptop kernel: [ 1159.096147] wlan0: authenticate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:25 teej-laptop kernel: [ 1159.098112] wlan0: authenticated
Apr  8 11:25:25 teej-laptop kernel: [ 1159.098133] wlan0: associate with AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:25 teej-laptop kernel: [ 1159.100511] wlan0: RX AssocResp from 00:1f:9f:eb:32:d9 (capab=0x411 status=0 aid=1)
Apr  8 11:25:25 teej-laptop kernel: [ 1159.100521] wlan0: associated
Apr  8 11:25:31 teej-laptop kernel: [ 1164.540566] No probe response from AP 00:1f:9f:eb:32:d9 after 500ms, disconnecting.
Apr  8 11:25:32 teej-laptop kernel: [ 1166.067049] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 1)
Apr  8 11:25:33 teej-laptop kernel: [ 1166.261924] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 2)
Apr  8 11:25:33 teej-laptop kernel: [ 1166.460464] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 (try 3)
Apr  8 11:25:33 teej-laptop kernel: [ 1166.663139] wlan0: direct probe to AP 00:1f:9f:eb:32:d9 timed out
Apr  8 11:25:59 teej-laptop kernel: [ 1193.003690] eth0: link up.

If anything else is needed, just let me know. Thanks guys.

*** Bug 15079 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> Apr  8 11:25:32 teej-laptop kernel: [ 1166.067049] wlan0: direct probe to AP
> 00:1f:9f:eb:32:d9 (try 1)
> Apr  8 11:25:33 teej-laptop kernel: [ 1166.261924] wlan0: direct probe to AP
> 00:1f:9f:eb:32:d9 (try 2)
> Apr  8 11:25:33 teej-laptop kernel: [ 1166.460464] wlan0: direct probe to AP
> 00:1f:9f:eb:32:d9 (try 3)
> Apr  8 11:25:33 teej-laptop kernel: [ 1166.663139] wlan0: direct probe to AP
> 00:1f:9f:eb:32:d9 timed out
> Apr  8 11:25:59 teej-laptop kernel: [ 1193.003690] eth0: link up.
> 
> If anything else is needed, just let me know. Thanks guys.

In this case it looks like you aren't receiving any beacons or probe responses from the AP.  It works in madwifi I assume?  Teej - is this a 5211?

(In reply to comment #8)
> (In reply to comment #2)
> > I went and bought a Linksys WRT54G (v7.0, fwiw) and was unable to reproduce
> the
> > problem with that, so maybe it's an issue between the Atheros card and the
> > Micronet AP.
> 
> Correction: the Atheros card still gets disconnected from the AP, but other
> clients aren't.

Ok, this makes more sense.

The Aspire One seems to have lots of difficulties, but unfortunately I don't have the hardware so it's tough to tell what's going on.  This seems related:

https://bugzilla.kernel.org/show_bug.cgi?id=15538

> Also, sometimes a call trace like the following appears in the kernel log:

As far as I can tell what happened here is:

- at some point, we removed the sta interface from the driver (essentially ifconfig wlan0 down)
- after that, userspace notified the kernel that it was no longer associated with the AP

The stack trace is harmless, but, this ordering shouldn't happen.  I wonder, does it happen on a more recent kernel?

Hi Bob,
I haven't actually tried the madwifi drivers recently, will try the latest build and see what that produces. Oh it's a AR5001.

(In reply to comment #12)
> (In reply to comment #8)
> > (In reply to comment #2)
> > > I went and bought a Linksys WRT54G (v7.0, fwiw) and was unable to
> reproduce the
> > > problem with that, so maybe it's an issue between the Atheros card and
> the
> > > Micronet AP.
> > 
> > Correction: the Atheros card still gets disconnected from the AP, but other
> > clients aren't.
> 
> Ok, this makes more sense.

This is with the Linksys AP. With the Micronet AP, all clients _do_ get disconnected when the Aspire ONE's ath5k acts up.

> The Aspire One seems to have lots of difficulties, but unfortunately I don't
> have the hardware so it's tough to tell what's going on.  This seems related:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=15538

Maybe I'm missing something, but to me it doesn't look related at all; I don't see any txbuf related messages and I'm not using ad-hoc mode.

> > Also, sometimes a call trace like the following appears in the kernel log:
> 
> As far as I can tell what happened here is:
> 
> - at some point, we removed the sta interface from the driver (essentially
> ifconfig wlan0 down)
> - after that, userspace notified the kernel that it was no longer associated
> with the AP
> 
> The stack trace is harmless, but, this ordering shouldn't happen.

My watchdog script certainly did an ifconfig wlan0 down, but only after the connection was gone (as in, pings to a known working address on the LAN behind the AP failed several times in a row).

> I wonder, does it happen on a more recent kernel?

I'll upgrade tomorrow and get back to you with the results.

> > https://bugzilla.kernel.org/show_bug.cgi?id=15538
> 
> Maybe I'm missing something, but to me it doesn't look related at all; I
> don't
> see any txbuf related messages and I'm not using ad-hoc mode.

You wouldn't see these symptoms except in adhoc mode, but the root issue is interrupts stop firing for unknown reasons, which would certainly cause beacon loss and missed probe responses.

Created attachment 25930 [details]
Kernel log from 2.6.33-grml (grml.02)

(In reply to comment #15)
> > > https://bugzilla.kernel.org/show_bug.cgi?id=15538
> > 
> > Maybe I'm missing something, but to me it doesn't look related at all; I
> don't
> > see any txbuf related messages and I'm not using ad-hoc mode.
> 
> You wouldn't see these symptoms except in adhoc mode, but the root issue is
> interrupts stop firing for unknown reasons, which would certainly cause
> beacon
> loss and missed probe responses.

Well, what do you know; I retried with 2.6.33 (precompiled grml kernel), and did receive some "no further txbuf available, dropping packet" messages.

I attached a large segment of the kernel log. Interestingly, it includes warnings about low memory corruption, something I haven't seen before. Maybe related to different kernel configuration? The relevant part of the diff between the configs looks like this:

--- config-2.6.31-18-generic    2010-01-08 19:54:26.000000000 +0100
+++ config-2.6.33-grml  2010-04-02 11:59:00.000000000 +0200
#[...]
@@ -345,11 +382,12 @@
 CONFIG_ZONE_DMA_FLAG=1
 CONFIG_BOUNCE=y
 CONFIG_VIRT_TO_BUS=y
-CONFIG_HAVE_MLOCK=y
-CONFIG_HAVE_MLOCKED_PAGE_BIT=y
 CONFIG_MMU_NOTIFIER=y
-CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
-CONFIG_HIGHPTE=y
+CONFIG_KSM=y
+CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
+CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
+# CONFIG_MEMORY_FAILURE is not set
+# CONFIG_HIGHPTE is not set
 CONFIG_X86_CHECK_BIOS_CORRUPTION=y
 CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
 CONFIG_X86_RESERVE_LOW_64K=y
@@ -359,20 +397,20 @@
 CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
 CONFIG_X86_PAT=y
+CONFIG_ARCH_USES_PG_UNCACHED=y
 CONFIG_EFI=y
 CONFIG_SECCOMP=y
-CONFIG_CC_STACKPROTECTOR_ALL=y
 CONFIG_CC_STACKPROTECTOR=y

I first tried to trigger the wifi failure by rsyncing a large file to the Aspire one over ssh, but this always failed early complaining about "Corrupted MAC on input", which doesn't sound promising at all but may be a separate issue.

I then switched to using NFS. After a few tens of seconds of rsyncing, the wifi connection was gone; then my watchdog script kicked in, removed the ath5k module and reinserted it. Subsequently I stopped this script so it wouldn't interfere with the experiment; I marked this event in the attached log.

Is there anything more I can do?

Created attachment 26566 [details]
Disable ASPM L0s/L1 on ath5k

I have had these problems myself too. I have been using pcie_aspm=force with AOA150 and now finally noticed that I had to disable ASPM for ath5k to make it work right. This patch fixes my problems, you might want to give it a try too.

I have an AAO A150, and I get a connection drop under heavy load. This also kills other wireless connections on the same AP at the same time. This happens for standard modules for Ubuntu 10.04, and for linux-backports-modules-wireless-2.6.32.22.

I applied the patch from #18 above to compat-wireless-2010-05-29, and compiled against 2.6.32-22-generic (Ubuntu 10.04). Had to change calls to pci_pcie_cap() in the patch to calls to pci_find_capability():

From:
  pos = pci_pcie_cap(pdev);
to:
  pos = pci_find_capability(pdev, PCI_CAP_ID_EXP);

I think the newer API is not in 2.6.32-22, but I am likely to have got this wrong (no experience here!).

The connection drop due to large transfers is gone - I moved ~1GB of files up & down without failure. Before, I was seeing all the various symptoms described in this bug report.

I did notice that the new driver seems slow to connect from cold boot. Might be something I did... not sure.

Using Arch Linux and kernel26-zen 2.6.33, I compiled the exact same compat-wireless as Graham. I was able to download a torrent at 1.1Mbps without killing my connection or others' to the router, though neither I nor anyone else could browse the internet or access the router page a half hour or so into the download. Might be a kink in the router or DD-WRT.

I am also experiencing something similar to what Graham also reported. The driver is sparsely able to make a connection to the router in the first place. Using wicd, I get lots of "Unable to get IP address" errors. I was able to test out the connection quality once I did get connected, though.

The same problem was exhibited in compat-wireless 2010-06-02, causing me to try out the one Graham used.

I switched ath5k hardware for b43 (I took last stab at figuring mine ath5k problems after I ordered the new part :P) and I'm not able to work on this patch anymore. However I did more checking on AAO150, it appears that BIOS enables ASPM L0s on mini-pcie slot(s) (booted kernel with pcie_aspm=off).

With pcie_aspm=force (L0s and L1 on) problems appear much earlier. Disabling just L1 didn't help, I had to disable L0s with the patch. These instability problems also exists when tested ndiswrapper/windows driver.

If it helps any I can post 'lspci -vvv', dmesg, config, etc, but they will be with b43.

Tested using 2.6.34

Maybe this is L0s problem only, windows driver inf seems to have setup for enabling L1 on some devices but never L0s.

I can confirm this behaviour on a O2 wireless broadband router and a Billion BiPAC 7800N. I actually bought the latter because I thought my issues were a fault with the former (I mean, how likely is it that the NIC in my Aspire One would bring down the whole network under load...)

@Jussi Kivilinna.

I just tested this patch on (used to be called AR2425) AR5001, and it works just fine.

Moreover, I edited the patch to disable only L0S and card still works.
Why doesn't that surprise me?
Another workaround in windows driver for hardware bug....

I compiled compat-wireless dated today for ath5k, with the patch from #18 applied. I had to make an adustment to the #ifdef mentioned in hunk 2, but it applied. One of the hunks had a fuzz of 2, I think hunk 5. I guess that means the line count was off a little bit?

Anyways. Applied that patch to compat-wireless for 2010-06-23 and compiled it. Everything's working great now. Before, I was using ndiswrapper without authentication on the router. Now, I'm able to turn on WPA2 and download a torrent at 800kb/s without everyone getting disassociated. Everyone still loses www access in the process (unknown host errors), but everyone stays connected and all other internet access still works, such as torrents and MMOs. I think that's a DD-WRT thing. Nothing shows up in the netbook's dmesg about it.

And with this new version of ath5k, I am able to connect consistently to my network. I restarted three times to make sure, and then also shut it down and started it back up cold. So that issue mentioned in my previous post here is gone.

Small update (forgot to update): Now running linux kernel 2.6.35-8 on Ubuntu 10.10 (dev version) 32 bit. Have tried both the ath5k and madwifi drivers, to no avail. Am not knowledgeable enough to try to recompile the compat-wireless stack. If any more info is needed from me, I'll be happy to provide it if possible. Thank you.

commit 6ccf15a1a76d2ff915cdef6ae4d12d0170087118
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date:   Fri Aug 13 11:27:28 2010 -0400

    ath5k: disable ASPM L0s for all cards
    
    Atheros PCIe wireless cards handled by ath5k do require L0s disabled.
    For distributions shipping with CONFIG_PCIEASPM (this will be enabled
    by default in the future in 2.6.36) this will also mean both L1 and L0s
    will be disabled when a pre 1.1 PCIe device is detected. We do know L1
    works correctly even for all ath5k pre 1.1 PCIe devices though but cannot
    currently undue the effect of a blacklist, for details you can read
    pcie_aspm_sanity_check() and see how it adjusts the device link
    capability.
    
    It may be possible in the future to implement some PCI API to allow
    drivers to override blacklists for pre 1.1 PCIe but for now it is
    best to accept that both L0s and L1 will be disabled completely for
    distributions shipping with CONFIG_PCIEASPM rather than having this
    issue present. Motivation for adding this new API will be to help
    with power consumption for some of these devices.
    
    Example of issues you'd see:
    
      - On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001
        Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well
        with ASPM enabled, the card will eventually stall on heavy traffic
        with often 'unsupported jumbo' warnings appearing. Disabling
        ASPM L0s in ath5k fixes these problems.
    
      - On the same card you would see a storm of RXORN interrupts
        even though medium is idle.
    
    Credit for root causing and fixing the bug goes to Jussi Kivilinna.
    
    Cc: David Quan <David.Quan@atheros.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Tim Gardner <tim.gardner@canonical.com>
    Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
    Cc: stable@kernel.org
    Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
    Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>