Acer Aspire 7750G Slacwkare 64 13.37 Kernel built from vanilla source ath9k wireless driver Last known working kernel : 3.3.0 Since kernel 3.3.1, I cannot authenticate anymore to any access point. dmesg output looks like this: eth0: authenticate with ee:7d:78:eb:fc:64 (try 1) eth0: authenticate with ee:7d:78:eb:fc:64 (try 2) eth0: authenticate with ee:7d:78:eb:fc:64 (try 3) eth0: authentication with ee:7d:78:eb:fc:64 timed out eth0: authenticate with ee:7d:78:eb:fc:64 (try 1) eth0: authenticate with ee:7d:78:eb:fc:64 (try 2) eth0: authenticate with ee:7d:78:eb:fc:64 (try 3) eth0: authentication with ee:7d:78:eb:fc:64 timed out eth0: authenticate with ee:7d:78:eb:fc:66 (try 1) eth0: authenticate with ee:7d:78:eb:fc:66 (try 2) eth0: authenticate with ee:7d:78:eb:fc:66 (try 3) eth0: authentication with ee:7d:78:eb:fc:66 timed out eth0: authenticate with ee:7d:78:eb:fc:66 (try 1) eth0: authenticate with ee:7d:78:eb:fc:66 (try 2) eth0: authenticate with ee:7d:78:eb:fc:66 (try 3) eth0: authentication with ee:7d:78:eb:fc:66 timed out ... and fills up, as wpa_supplicant tries to authenticates. The used hardware is a laptop wireless adapter, dmesg says that at boot: ath: EEPROM regdomain: 0x65 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x65 ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' Registered led device: ath9k-phy0 ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xffffc90011b20000, irq=17 lspci -v shows this: 03:00.0 Network controller: Atheros Communications Inc. AR9287 Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Foxconn International, Inc. Device e034 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at c0100000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-15-17-ff-ff-24-14-12 Capabilities: [170] Power Budgeting <?> Kernel driver in use: ath9k The strange thing is that scanning indeed works, and I can see many AP (I'm in a town). This is a regression since 3.3.0 works fine, as I'm reporting from this version.
(In reply to comment #0) > Acer Aspire 7750G > Slacwkare 64 13.37 > Kernel built from vanilla source > ath9k wireless driver > Last known working kernel : 3.3.0 > > Since kernel 3.3.1, I cannot authenticate anymore to any access point. dmesg > output looks like this: > > eth0: authenticate with ee:7d:78:eb:fc:64 (try 1) > eth0: authenticate with ee:7d:78:eb:fc:64 (try 2) > eth0: authenticate with ee:7d:78:eb:fc:64 (try 3) > eth0: authentication with ee:7d:78:eb:fc:64 timed out > eth0: authenticate with ee:7d:78:eb:fc:64 (try 1) > eth0: authenticate with ee:7d:78:eb:fc:64 (try 2) > eth0: authenticate with ee:7d:78:eb:fc:64 (try 3) > eth0: authentication with ee:7d:78:eb:fc:64 timed out > eth0: authenticate with ee:7d:78:eb:fc:66 (try 1) > eth0: authenticate with ee:7d:78:eb:fc:66 (try 2) > eth0: authenticate with ee:7d:78:eb:fc:66 (try 3) > eth0: authentication with ee:7d:78:eb:fc:66 timed out > eth0: authenticate with ee:7d:78:eb:fc:66 (try 1) > eth0: authenticate with ee:7d:78:eb:fc:66 (try 2) > eth0: authenticate with ee:7d:78:eb:fc:66 (try 3) > eth0: authentication with ee:7d:78:eb:fc:66 timed out > ... > and fills up, as wpa_supplicant tries to authenticates. > > The used hardware is a laptop wireless adapter, dmesg says that at boot: > > ath: EEPROM regdomain: 0x65 > ath: EEPROM indicates we should expect a direct regpair map > ath: Country alpha2 being used: 00 > ath: Regpair used: 0x65 > ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' > Registered led device: ath9k-phy0 > ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xffffc90011b20000, irq=17 > > lspci -v shows this: > > 03:00.0 Network controller: Atheros Communications Inc. AR9287 Wireless > Network > Adapter (PCI-Express) (rev 01) > Subsystem: Foxconn International, Inc. Device e034 > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at c0100000 (64-bit, non-prefetchable) [size=64K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- > Capabilities: [60] Express Legacy Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Virtual Channel > Capabilities: [160] Device Serial Number 00-15-17-ff-ff-24-14-12 > Capabilities: [170] Power Budgeting <?> > Kernel driver in use: ath9k > > The strange thing is that scanning indeed works, and I can see many AP (I'm > in > a town). > > This is a regression since 3.3.0 works fine, as I'm reporting from this > version. a similiar thread with a similiar issue is reported, let me try to recreate it
http://www.spinics.net/lists/linux-wireless/msg87748.html
http://comments.gmane.org/gmane.linux.kernel.wireless.general/88543 the above revert patch from Sujith should fix, got to fix unassociated idle power save case
The same for me. The bug 43077 seems to duplicate this bug. In my dmesg also there is a warning Apr 8 23:25:12 kato kernel: wlan0: deauthenticating from c6:8e:37:e4:ab:4a by local choice (reason=3) Apr 8 23:25:12 kato kernel: ------------[ cut here ]------------ Apr 8 23:25:12 kato kernel: WARNING: at net/wireless/mlme.c:309 cfg80211_send_auth_timeout+0x6d/0xd0 [cfg80211]() Apr 8 23:25:12 kato kernel: Hardware name: VPCCW2S1R Apr 8 23:25:12 kato kernel: Modules linked in: ipt_MASQUERADE iptable_nat nf_nat xt_recent xt_tcpudp nf_conntrack_i pv4 nf_defrag_ipv4 xt_state nf_conntrack ipv6 iptable_filter ip_tables x_tables fuse vboxnetflt(O) vboxnetadp(O) pci _stub vboxpci(O) vboxdrv(O) nfs auth_rpcgss lockd sunrpc nvidia_bl(O) usbhid hid uvcvideo videobuf2_vmalloc videobuf 2_memops videobuf2_core videodev v4l2_compat_ioctl32 nvidia(PO) btusb bluetooth sr_mod snd_hda_codec_hdmi cdrom arc4 snd_hda_codec_realtek ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 ehci_hcd usbcore snd_hda_intel snd_hda_code c snd_hwdep snd_pcm snd_page_alloc snd_timer usb_common sdhci_pci i2c_i801 sdhci snd battery video i2c_core psmouse evdev sony_laptop sky2 mmc_core ac rtc_cmos button backlight rfkill soundcore unix Apr 8 23:25:12 kato kernel: Pid: 522, comm: kworker/u:5 Tainted: P O 3.3.1-gentoo #1 Apr 8 23:25:12 kato kernel: Call Trace: Apr 8 23:25:12 kato kernel: [<ffffffff8102eb5b>] ? warn_slowpath_common+0x7b/0xc0 Apr 8 23:25:12 kato kernel: [<ffffffffa01aab0d>] ? cfg80211_send_auth_timeout+0x6d/0xd0 [cfg80211] Apr 8 23:25:12 kato kernel: [<ffffffff81056a7e>] ? try_to_wake_up+0x1de/0x290 Apr 8 23:25:12 kato kernel: [<ffffffffa0271e21>] ? ath9k_config+0x281/0x530 [ath9k] Apr 8 23:25:12 kato kernel: [<ffffffffa01d5858>] ? ieee80211_probe_auth_done+0xf8/0x110 [mac80211] Apr 8 23:25:12 kato kernel: [<ffffffff8133d83a>] ? __mutex_unlock_slowpath+0x3a/0x50 Apr 8 23:25:12 kato kernel: [<ffffffffa01d8f7e>] ? ieee80211_work_work+0x4ee/0x14f0 [mac80211] Apr 8 23:25:12 kato kernel: [<ffffffff812a46ae>] ? skb_dequeue+0x5e/0x80 Apr 8 23:25:12 kato kernel: [<ffffffffa01d8a90>] ? free_work+0x20/0x20 [mac80211] Apr 8 23:25:12 kato kernel: [<ffffffff81043d6f>] ? process_one_work+0x10f/0x380 Apr 8 23:25:12 kato kernel: [<ffffffff8104667e>] ? worker_thread+0x15e/0x330 Apr 8 23:25:12 kato kernel: [<ffffffff81052280>] ? __wake_up_common+0x50/0x80 Apr 8 23:25:12 kato kernel: [<ffffffff81046520>] ? manage_workers.clone.22+0x230/0x230 Apr 8 23:25:12 kato kernel: [<ffffffff81046520>] ? manage_workers.clone.22+0x230/0x230 Apr 8 23:25:12 kato kernel: [<ffffffff8104aace>] ? kthread+0x9e/0xb0 Apr 8 23:25:12 kato kernel: [<ffffffff811a0000>] ? aead_geniv_alloc+0x2c0/0x350 Apr 8 23:25:12 kato kernel: [<ffffffff81341c14>] ? kernel_thread_helper+0x4/0x10 Apr 8 23:25:12 kato kernel: [<ffffffff8104aa30>] ? kthread_freezable_should_stop+0x60/0x60 Apr 8 23:25:12 kato kernel: [<ffffffff81341c10>] ? gs_change+0xb/0xb Apr 8 23:25:12 kato kernel: ---[ end trace 3a88f303b66412b6 ]---
https://bugzilla.redhat.com/show_bug.cgi?id=814011 I added a bug for Fedora 16, however I feel information should go here too
Created attachment 72994 [details] Dmesg output
uname -r 3.3.1-5.fc16.x86_64
I confirm the problem is not present anymore in 3.3.2 (commit was reverted), and is not present in 3.4-rc4.