Bug#664767: Brcmsmac driver woes, possible regression?

[Jonathan Nieder <jrnieder@gmail.com>]

severity 664767 important
quit

Hi again,

Camaleón wrote:

> Although kernel 3.3 still logs the trace (despite having applied all
> of the suggested the patches), there's an overall stability
> improvement in the wireless driver when compared to kernel 3.2.12
> where:
>
> - Wireless link is more prone to connection resets which require for
> user interaction to reconnect again
> - Reconnects make some running programs to segfault
[...]
> Apr  6 19:56:22 stt300 kernel: [32987.534515] gnome-shell[2062]: segfault at 24 ip b76bbb31 sp bfbf7920 error 4 in libgnome-shell.so[b7681000+a0000]
> Apr  6 19:58:02 stt300 kernel: [33086.718790] mail-notificati[2077]: segfault at 4c ip 08060063 sp bfe8d4a0 error 4 in mail-notification[8048000+5c000]

That's no good.  It would be nice to get this fixed in 3.2.y upstream
if possible.

[...]
> Is there something we can do to improve the driver status in Wheezy?

I think we ought to update brcmsmac to the latest version available
for wheezy.  It is a young driver, and the version in 3.2 has serious
problems as described by Seth Forsee[1]:

| The background is that brcmsmac contains a bunch of code for regulatory
| support that is either duplicated (and in conflict) with the
| protocol-level support or else it would better be handled there. This is
| causing problems on pretty much any channel that isn't part of the
| default world regulatory domain.
|
| I've sent RFC patches that strip out the vast majority of this code in
| favor of better integration with the protocol-level regulatory support.

Unfortunately that could a little tricky because there might be
changes elsewhere that brcmsmac relies on (bcma, wireless core).

Jonathan

[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/87873/focus=90727