Created attachment 94601 [details] dmesg Since upgrade to 3.8, I can connect to wireless networks only after 10-20 attempts. Maybe this happens on 3.7 too, I skipped it because vga_switcheroo didn't work for me. On 3.6 everything works on first attempt. My wi-fi card: 0d:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) Subsystem: Hewlett-Packard Company Device 1483 dmesg: many [ 26.235402] wlan0: authenticate with e0:46:9a:59:a9:52 [ 26.237384] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded [ 26.237424] wlan0: direct probe to e0:46:9a:59:a9:52 (try 1/3) [ 26.437825] wlan0: direct probe to e0:46:9a:59:a9:52 (try 2/3) [ 26.638761] wlan0: direct probe to e0:46:9a:59:a9:52 (try 3/3) [ 26.839692] wlan0: authentication with e0:46:9a:59:a9:52 timed out and then finally [ 530.562118] wlan0: authenticate with e0:46:9a:59:a9:52 [ 530.564338] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded [ 530.564374] wlan0: send auth to e0:46:9a:59:a9:52 (try 1/3) [ 530.565870] wlan0: authenticated [ 530.567050] wlan0: associate with e0:46:9a:59:a9:52 (try 1/3) [ 530.571017] wlan0: RX AssocResp from e0:46:9a:59:a9:52 (capab=0x431 status=0 aid=1) [ 530.571586] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated [ 530.571594] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: enabled true, count 0 (implement) [ 530.571598] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) [ 530.571623] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 530.571772] wlan0: associated
Done some additional testing: The problem is present in 3.8-rc1, but is not in 3.7.10 Connections to the same AP after first succesful connection are done on first attempt. If I turn off and on my wi-fi adapter, I have problems again.
I reverted this commit: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=b6fc28a158076ca2764edc9a6d1e1402f56e1c0c and now I have successful connection on first attempt.
I'm confirming the existence of this regression. 24:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) Subsystem: Hewlett-Packard Company Device 145c Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at d4400000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information: Len=78 <?> Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number 00-00-12-ff-ff-6f-ac-81 Capabilities: [16c] Power Budgeting <?> Kernel driver in use: bcma-pci-bridge Linux nina 3.8.6-1-ARCH #1 SMP PREEMPT Sat Apr 6 07:27:01 CEST 2013 x86_64 GNU/Linux
I can't reproduce this bug with the current kernel from Arch testing channel at the moment. Linux nina 3.8.10-1-ARCH #1 SMP PREEMPT Sat Apr 27 12:36:59 CEST 2013 x86_64 GNU/Linux Can anyone confirm that this bug has been fixed?
Problematic commit was reverted: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=95ffc2b9c20c201cead468e1fe185b8c11f9a55b