b43 reconnect issue

English Network/Internet
#1

OS 13.1 KDE _64

Card-1: Broadcom BCM4312 802.11b/g LP-PHY driver: wl

04:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev 01)        Subsystem: Broadcom Corporation Device [14e4:04b5]
        Kernel driver in use: wl
        Kernel modules: ssb, wl

I know - I’m using ‘wl’

I switched to it to check functionality compared to b43

The issue is reconnect after suspend. Is very slow.

I’m pretty sure it kernel related. Here are my findings:

OS 12.3 kernel 3.7 with b43 > reconnect is within a second or two
OS 12.3 kernel 3.11 or 3.12 with b43 > reconnect is 30-60 sec

(Other distros also with kernel 3.8> also experience this issue using b43)

OS 13.1 kernel 3.11 or 3.12 with b43 reconnect is 30-60 sec
OS 13.1 kernel 3.11 with ‘wl’ reconnect is within a second or two

Didn’t test ‘wl’ in 13.3

#2

So I installed 13.1 on my netbook
It doesn’t use broadcom but

02:00.0 Network controller [0280]: Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe [1814:3090]        Subsystem: AzureWave Device [1a3b:1087]
        Kernel driver in use: rt2800pci
        Kernel modules: rt2800pci

This device works OK, as expected, normally.

Before we bash broadcom over the head. Consider:
My hardware works and has worked flawlessly with b43 since kernel 3 supported it
It still does with all kernels up thru 3.0 > 3.7
3.8> all exhibit the slow reconnect and are actually slower at initial connect at reboot stage too

#3

On 11/17/2013 01:16 AM, caf4926 wrote:
>
> So I installed 13.1 on my netbook
> It doesn’t use broadcom but
>
> Code:
> --------------------
> 02:00.0 Network controller [0280]: Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe [1814:3090] Subsystem: AzureWave Device [1a3b:1087]
> Kernel driver in use: rt2800pci
> Kernel modules: rt2800pci
>
>
>
> --------------------
>
>
> This device works OK, as expected, normally.
>
> Before we bash broadcom over the head. Consider:
> My hardware works and has worked flawlessly with b43 since kernel 3
> supported it
> It still does with all kernels up thru 3.0 > 3.7
> 3.8> all exhibit the slow reconnect and are actually slower at initial
> connect at reboot stage too

Pull yourself the git version of the mainline tree, and bisect to find the
actual commit that causes the problem. Bisecting between 3.8 (bad) and 3.7
(good) should only involve 15 builds.