[3.2.y] Re: Brcmsmac driver woes, possible regression?

[3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Hi Arend et al,

Quick puzzle for you.  You like puzzles, right? ;-)

As discussed at [1], Camaleón has been experiencing unwanted random
wireless reconnects with various 3.2.y kernels up to and including
3.2.19:

Camaleón wrote[3]:

>      What I get is the Network Manager window requesting for the
> password confirm, randomly. If I delay the password confirmation, the
> wireless connection drops.

Newer kernels seemed to work better than old, so I asked her to apply
the following patches agains the 3.2.y tree (the exact patches used
are at [2]):

  6b1a89afbf97 brcm80211: smac: drop "40MHz intolerant" flag from HT
               capability info
  c261bdf8acad brcm80211: smac: indicate severe problems to Mac80211
  0bf1f883fd0a brcm80211: smac: removed MPC related code
  4412953061de brcm80211: smac: removed MPC related variables
  28237002e726 brcm80211: smac: removed down-on-watchdog MPC functionality
  43ac09722f8e brcm80211: smac: removed down-on-rf-kill functionality
  a8bc4917ed6b brcm80211: smac: bugfix for tx mute in brcms_b_init()
  c6c44893c864 brcm80211: smac: fixed inconsistency in transmit mute
  2646c46d5679 brcm80211: smac: modified Mac80211 callback interface
  dc460127898c brcm80211: smac: mute transmit on ops_start
  1525662ac280 brcm80211: smac: changed check to confirm STA only support
  b7eec4233c34 brcm80211: smac: replace own access category definitions with
               mac80211 enum
  e9ca530a7b18 brcm80211: smac: don't modify sta parameters when adding sta
  8906c43cb160 brcm80211: smac: fix channel frequency
  02a588a2e3b9 brcm80211: smac: combine promiscuous mode functionality
  be667669ec01 brcm80211: smac: added support for mac80211 filter flags
 [d3f311349add brcm80211: fix usage of set tx power] --- unrelated, my mistake
  aa1f2f0a3218 brcm80211: smac: precendence bug in wlc_phy_attach()
  1570e53c14ff brcm80211: smac: fix unintended fallthru in
               wlc_phy_radio_init_2057()
  137dabed34a1 brcm80211: smac: remove smatch warnings from brcmsmac code
  2b0a53d51b5f brcm80211: smac: only print block-ack timeout message at
               trace level
  6b8da423315b brcm80211: smac: do not use US as fallback regulatory hint
  94a2ca311cf4 brcm80211: smac: only provide valid regulatory hint

The result was very nice --- the random reconnects went away.

Here comes the puzzle --- which of those patches are responsible for
the improvement?

If it is not too invasive, we would like to test the responsible patch
separately and submit it for inclusion in stable trees, hence the
question.  Incidentally, if any unrelated patches also seem like good
stable candidates, that would be interesting to hear, too.  (In other
words, a brief description of the symptoms addressed by _any_ of the
listed patches would be welcome.)

Example log of a reconnect at [3].

Thanks,
Jonathan

[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/87873
[2] http://bugs.debian.org/664767#99
[3] http://bugs.debian.org/664767#196

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Hi again,

Jonathan Nieder wrote:

> As discussed at [1], Camaleón has been experiencing unwanted random
> wireless reconnects with various 3.2.y kernels up to and including
> 3.2.19:

This was first reproduced on a kernel closely based on 3.2.9.  It
would typically happen pretty reliably once a day or so.  Four days of
testing a kernel close to 3.2.2 haven't triggered it again[1].

The only brcm80211 change in that range is

  f96b08a7e6f6 brcmsmac: fix tx queue flush infinite loop

So maybe the timeout is too short and this safety is tripping when it
shouldn't.  I've asked Camaleón to try a recent 3.2.y kernel with and
without that commit reverted to test this guess.

That leaves another mystery: which of the 22 changes listed at [2] was
providing relief in earlier tests?  E.g., does

>   c261bdf8acad brcm80211: smac: indicate severe problems to Mac80211

make it easier to recover from this kind of error?  Are there commands
we should run or diagnostics to try to get a better sense of what is
going on?

Grasping at straws,
Jonathan

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=220;bug=664767
[2] http://thread.gmane.org/gmane.linux.kernel.wireless.general/92452

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Arend van Spriel]

On 06/19/2012 08:15 PM, Jonathan Nieder wrote:
> Hi again,
> 
> Jonathan Nieder wrote:
> 
>> As discussed at [1], Camaleón has been experiencing unwanted random
>> wireless reconnects with various 3.2.y kernels up to and including
>> 3.2.19:
> 
> This was first reproduced on a kernel closely based on 3.2.9.  It
> would typically happen pretty reliably once a day or so.  Four days of
> testing a kernel close to 3.2.2 haven't triggered it again[1].
> 
> The only brcm80211 change in that range is
> 
>   f96b08a7e6f6 brcmsmac: fix tx queue flush infinite loop
> 

The WARN_ONCE added by the commit above still triggers sometimes. Two
recent commits I did regarding this are in 3.4-stable. Not sure if they
have been ported to 3.2 as well.

85091fc brcm80211: smac: fix endless retry of A-MPDU transmissions
badc4f0 brcm80211: smac: resume transmit fifo upon receiving frames

However, I still observe the warning so I am looking what other event
trigger this issue.

> So maybe the timeout is too short and this safety is tripping when it
> shouldn't.  I've asked Camaleón to try a recent 3.2.y kernel with and
> without that commit reverted to test this guess.
> 
> That leaves another mystery: which of the 22 changes listed at [2] was
> providing relief in earlier tests?  E.g., does
> 
>>   c261bdf8acad brcm80211: smac: indicate severe problems to Mac80211
> 
> make it easier to recover from this kind of error?  Are there commands
> we should run or diagnostics to try to get a better sense of what is
> going on?

Not commends yet. We want to add debugfs support. The commit above only
notifies mac80211 that we have a problem. However, the recovery scenario
that mac80211 initiates upon this notification turns out to be killing
for brcmsmac.

Gr. AvS

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Arend van Spriel wrote:
> On 06/19/2012 08:15 PM, Jonathan Nieder wrote:

>> This was first reproduced on a kernel closely based on 3.2.9.  It
>> would typically happen pretty reliably once a day or so.  Four days of
>> testing a kernel close to 3.2.2 haven't triggered it again[1].
>>
>> The only brcm80211 change in that range is
>>
>>   f96b08a7e6f6 brcmsmac: fix tx queue flush infinite loop
>
> The WARN_ONCE added by the commit above still triggers sometimes. Two
> recent commits I did regarding this are in 3.4-stable. Not sure if they
> have been ported to 3.2 as well.
>
> 85091fc brcm80211: smac: fix endless retry of A-MPDU transmissions
> badc4f0 brcm80211: smac: resume transmit fifo upon receiving frames

Yep, both are in 3.2-stable (added in 3.2.18 and 3.2.17, respectively).

[...]
> However, I still observe the warning so I am looking what other event
> trigger this issue.

Feel free to contact Touko Korpela <touko.korpela@iki.fi> and Camaleón
if you need recent logs or other information about that[1].

I had been hoping that was mostly orthogonal until Camaleón mentioned
that 3.2.2 doesn't seem to trigger the random reconnects.

Thanks,
Jonathan

[1] tracked here: http://bugs.debian.org/672891

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Arend van Spriel]

On 06/19/2012 09:28 PM, Jonathan Nieder wrote:
> Arend van Spriel wrote:
>> However, I still observe the warning so I am looking what other event
>> trigger this issue.
> 
> Feel free to contact Touko Korpela <touko.korpela@iki.fi> and Camaleón
> if you need recent logs or other information about that[1].
> 
> I had been hoping that was mostly orthogonal until Camaleón mentioned
> that 3.2.2 doesn't seem to trigger the random reconnects.

I missed this piece of info. So the following statements are true?

1. v3.2.2 and earlier did not show the issue.
2. v3.2.9 until 3.2.17 have random reconnects.
3. v3.2.18 does not have random reconnects (or less).

Unfortunately, between v3.2.2 and v3.2.9 the only commit was the
infinite loop fix from Stanislaw so that does not solve the puzzle.
It only bails out with a warning, but there probably still is a problem
in v3.2.2.

Gr. AvS

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Arend van Spriel wrote:
> On 06/19/2012 09:28 PM, Jonathan Nieder wrote:

>> I had been hoping that was mostly orthogonal until Camaleón mentioned
>> that 3.2.2 doesn't seem to trigger the random reconnects.
>
> I missed this piece of info. So the following statements are true?
>
> 1. v3.2.2 and earlier did not show the issue.
> 2. v3.2.9 until 3.2.17 have random reconnects.
> 3. v3.2.18 does not have random reconnects (or less).

(1) and (2) are true.  I don't think (3) is.

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Arend van Spriel]

On 06/20/2012 12:02 PM, Jonathan Nieder wrote:
> Arend van Spriel wrote:
>> On 06/19/2012 09:28 PM, Jonathan Nieder wrote:
> 
>>> I had been hoping that was mostly orthogonal until Camaleón mentioned
>>> that 3.2.2 doesn't seem to trigger the random reconnects.
>>
>> I missed this piece of info. So the following statements are true?
>>
>> 1. v3.2.2 and earlier did not show the issue.
>> 2. v3.2.9 until 3.2.17 have random reconnects.
>> 3. v3.2.18 does not have random reconnects (or less).
> 
> (1) and (2) are true.  I don't think (3) is.
> 

I have my doubts on (3) as well, but I think the likelihood of the
random reconnects has reduced by earlier mentioned patches. I will work
with Camaleón and/or Touko Korpela investigating this (and keep you posted).

Gr. AvS

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Arend van Spriel]

On 06/11/2012 05:15 AM, Jonathan Nieder wrote:

Decided to lookup this message and reply. Noticed it, but forgot to
follow up.

> Hi Arend et al,
> 
> Quick puzzle for you.  You like puzzles, right? ;-)

>From time to time, I do. When I get enough sleep ;-)

> As discussed at [1], Camaleón has been experiencing unwanted random
> wireless reconnects with various 3.2.y kernels up to and including
> 3.2.19:
> 
> Camaleón wrote[3]:
> 
>>      What I get is the Network Manager window requesting for the
>> password confirm, randomly. If I delay the password confirmation, the
>> wireless connection drops.
> 
> Newer kernels seemed to work better than old, so I asked her to apply
> the following patches agains the 3.2.y tree (the exact patches used
> are at [2]):
> 
>   6b1a89afbf97 brcm80211: smac: drop "40MHz intolerant" flag from HT
>                capability info
>   c261bdf8acad brcm80211: smac: indicate severe problems to Mac80211
>   0bf1f883fd0a brcm80211: smac: removed MPC related code
>   4412953061de brcm80211: smac: removed MPC related variables
>   28237002e726 brcm80211: smac: removed down-on-watchdog MPC functionality
>   43ac09722f8e brcm80211: smac: removed down-on-rf-kill functionality
>   a8bc4917ed6b brcm80211: smac: bugfix for tx mute in brcms_b_init()
>   c6c44893c864 brcm80211: smac: fixed inconsistency in transmit mute
>   2646c46d5679 brcm80211: smac: modified Mac80211 callback interface
>   dc460127898c brcm80211: smac: mute transmit on ops_start
>   1525662ac280 brcm80211: smac: changed check to confirm STA only support
>   b7eec4233c34 brcm80211: smac: replace own access category definitions with
>                mac80211 enum
>   e9ca530a7b18 brcm80211: smac: don't modify sta parameters when adding sta
>   8906c43cb160 brcm80211: smac: fix channel frequency
>   02a588a2e3b9 brcm80211: smac: combine promiscuous mode functionality
>   be667669ec01 brcm80211: smac: added support for mac80211 filter flags
>  [d3f311349add brcm80211: fix usage of set tx power] --- unrelated, my mistake
>   aa1f2f0a3218 brcm80211: smac: precendence bug in wlc_phy_attach()
>   1570e53c14ff brcm80211: smac: fix unintended fallthru in
>                wlc_phy_radio_init_2057()
>   137dabed34a1 brcm80211: smac: remove smatch warnings from brcmsmac code
>   2b0a53d51b5f brcm80211: smac: only print block-ack timeout message at
>                trace level
>   6b8da423315b brcm80211: smac: do not use US as fallback regulatory hint
>   94a2ca311cf4 brcm80211: smac: only provide valid regulatory hint
> 
> The result was very nice --- the random reconnects went away.

If I remember correctly the random reconnects were caused by mac80211
flush callback.

> Here comes the puzzle --- which of those patches are responsible for
> the improvement?

My hunch based on what I found so far is that the patches mentioning the
word 'mute' could be key here.

> If it is not too invasive, we would like to test the responsible patch
> separately and submit it for inclusion in stable trees, hence the
> question.  Incidentally, if any unrelated patches also seem like good
> stable candidates, that would be interesting to hear, too.  (In other
> words, a brief description of the symptoms addressed by _any_ of the
> listed patches would be welcome.)

I really need to dive into the patches individually so it may take some
time.

Gr. AvS

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Hi,

Arend van Spriel wrote:
> On 06/11/2012 05:15 AM, Jonathan Nieder wrote:

>> Newer kernels seemed to work better than old, so I asked her to apply
>> the following patches agains the 3.2.y tree (the exact patches used
>> are at [2]):

I asked Camaleón to test the collection again to rule out a fluke.
Still looks ok[1]:

|                      I've been running this test (kernel 3.2.21 with 
| all the patches applied) since last Saturday which has been running 
| quite stable (only a couple reconnects in 7 days

Phew.

[...]
> My hunch based on what I found so far is that the patches mentioning the
> word 'mute' could be key here.

Unfortunately a collection including all of those (patches 1-10)
produces lots of reconnects and gnome-shell segfaults:

| Applied the ten first patches, compiled 3.2.21-1 from Debian sources
| and... well, I'm attaching log.

[...]
> I really need to dive into the patches individually so it may take some
> time.

Thanks.

Camaleón also tried changing the regulatory domain:

| >> I can try Arend's suggestion of setting "US" for the CRDA instead ES :-?
| >
| > This would be interesting, too (as an independent test).
|
| I tried but got no successful results so I restored the ES setting.

If you have questions for Camaleón or tests that it would be useful to
run, I'm all ears.  Unless we hear from you, the next test will
probably be to try patches 1-17, to cut the list of patches that might
have fixed it in half.

Ciao,
Jonathan

[1] http://bugs.debian.org/664767

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Hi again,

Quick update.

Arend van Spriel wrote:
> On 06/11/2012 05:15 AM, Jonathan Nieder wrote:

>> Newer kernels seemed to work better than old, so I asked her to apply
>> the following patches agains the 3.2.y tree (the exact patches used
>> are at [2]):
>> 
>>   6b1a89afbf97 brcm80211: smac: drop "40MHz intolerant" flag from HT
>>                capability info
>>   c261bdf8acad brcm80211: smac: indicate severe problems to Mac80211
>>   0bf1f883fd0a brcm80211: smac: removed MPC related code
>>   4412953061de brcm80211: smac: removed MPC related variables
>>   28237002e726 brcm80211: smac: removed down-on-watchdog MPC functionality
>>   43ac09722f8e brcm80211: smac: removed down-on-rf-kill functionality
>>   a8bc4917ed6b brcm80211: smac: bugfix for tx mute in brcms_b_init()
>>   c6c44893c864 brcm80211: smac: fixed inconsistency in transmit mute
>>   2646c46d5679 brcm80211: smac: modified Mac80211 callback interface
>>   dc460127898c brcm80211: smac: mute transmit on ops_start
>>   1525662ac280 brcm80211: smac: changed check to confirm STA only support
>>   b7eec4233c34 brcm80211: smac: replace own access category definitions with
>>                mac80211 enum
>>   e9ca530a7b18 brcm80211: smac: don't modify sta parameters when adding sta
>>   8906c43cb160 brcm80211: smac: fix channel frequency
>>   02a588a2e3b9 brcm80211: smac: combine promiscuous mode functionality
>>   be667669ec01 brcm80211: smac: added support for mac80211 filter flags
>>  [d3f311349add brcm80211: fix usage of set tx power] --- unrelated, my mistake
>>   aa1f2f0a3218 brcm80211: smac: precendence bug in wlc_phy_attach()
>>   1570e53c14ff brcm80211: smac: fix unintended fallthru in
>>                wlc_phy_radio_init_2057()

With all the above patches applied on top of 3.2.21, Camaleón quickly
gets the reconnects and gnome-shell segfaults if she does not supply
the password to network-manager in time[1].  That means the patch that
prevents trouble is presumably one of the four listed below.

>>   137dabed34a1 brcm80211: smac: remove smatch warnings from brcmsmac code
>>   2b0a53d51b5f brcm80211: smac: only print block-ack timeout message at
>>                trace level
>>   6b8da423315b brcm80211: smac: do not use US as fallback regulatory hint
>>   94a2ca311cf4 brcm80211: smac: only provide valid regulatory hint

Thanks,
Jonathan

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=295;bug=664767

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Arend van Spriel]

On 07/16/2012 11:31 PM, Jonathan Nieder wrote:
> 
> With all the above patches applied on top of 3.2.21, Camaleón quickly
> gets the reconnects and gnome-shell segfaults if she does not supply
> the password to network-manager in time[1].  That means the patch that
> prevents trouble is presumably one of the four listed below.
> 
>>>   137dabed34a1 brcm80211: smac: remove smatch warnings from brcmsmac code
>>>   2b0a53d51b5f brcm80211: smac: only print block-ack timeout message at
>>>                trace level
>>>   6b8da423315b brcm80211: smac: do not use US as fallback regulatory hint
>>>   94a2ca311cf4 brcm80211: smac: only provide valid regulatory hint
> 
> Thanks,
> Jonathan
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=295;bug=664767
> 

Thanks, Jonathan

I guess the behaviour improved due to the last two patches listed above,
but I also suspect that it is only an improvement and the root cause
still exists.

Gr. AvS

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Arend van Spriel wrote:
> On 07/16/2012 11:31 PM, Jonathan Nieder wrote:

>> With all the above patches applied on top of 3.2.21, Camaleón quickly
>> gets the reconnects and gnome-shell segfaults if she does not supply
>> the password to network-manager in time[1].  That means the patch that
>> prevents trouble is presumably one of the four listed below.
>>
>>>>   137dabed34a1 brcm80211: smac: remove smatch warnings from brcmsmac code
>>>>   2b0a53d51b5f brcm80211: smac: only print block-ack timeout message at
>>>>                trace level
>>>>   6b8da423315b brcm80211: smac: do not use US as fallback regulatory hint
>>>>   94a2ca311cf4 brcm80211: smac: only provide valid regulatory hint
>>
>> Thanks,
>> Jonathan
>>
>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=295;bug=664767
>
> Thanks, Jonathan
>
> I guess the behaviour improved due to the last two patches listed above,
> but I also suspect that it is only an improvement and the root cause
> still exists.

I think you're right.  Camaleón tried with all patches except the last
one and still got the unwanted reconnects.

Would 6b8da423315b and 94a2ca311cf4 be good candidates for stable@ in
the meantime (for symptom relief and saner regulatory code) until the
root cause is found?

Thanks,
Jonathan

Re: [3.2.y] Re: Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Jonathan Nieder wrote:
> Arend van Spriel wrote:

>> I guess the behaviour improved due to the last two patches listed above,
>> but I also suspect that it is only an improvement and the root cause
>> still exists.
>
> I think you're right.  Camaleón tried with all patches except the last
> one and still got the unwanted reconnects.
>
> Would 6b8da423315b and 94a2ca311cf4 be good candidates for stable@ in
> the meantime (for symptom relief and saner regulatory code) until the
> root cause is found?

To answer my own question: I guess not, at least not on the basis of
Camaleón's experience.

Results so far:

 * mainline >= 3.4.y: seemed to be ok for a few days, never showed the
   problem.
 * 3.2.19 + the 23 patches discussed in this thread: worked fine for about
   a week, never showed the problem.
 * 3.2.18: failed quickly.
 * 3.2.19 + first patch: failed quickly.
 * 3.2.2: worked ok for a while, then acted up again.  Affected.
 * 3.2.21 + 10 patches: failed quickly.
 * 3.2.21 + all 23 patches: worked ok-ish (?) for a week ("only a
   couple reconnects in 7 days, but when that happened gnome-shell was
   not segfaulting at least...").  I should have paid more attention:
   that meant it was affected!
 * 3.2.21 + 17 patches: failed quickly.
 * 3.2.21 + 19 patches: failed quickly.
 * 3.2.22 + 22 patches: failed quickly.
 * 3.2.21 + patch #23 alone: failed quickly.
 * 3.2.21 + all 23 patches: failed quickly.

Arend, you're very good at this guessing game. ;-)

I imagine the problem is still present in mainline.  Camaleón, the
next useful test would probably be mainline or wireless-testing, and
we should probably stop being so lazy and try to figure out _what_ is
happening when it reconnects and whether it is even a kernel bug.  It
might be something normal (like rekeying) not being handled well by
userspace.

Whatever it is, it seems that the kernel can help, since the
proprietary Broadcom wl driver works better if I have understood
Camaleón correctly.

Thanks,
Jonathan

Re: [3.2.y] Brcmsmac driver woes, possible regression?

[Jonathan Nieder]

Hi again,

Camaleón wrote[1]:
> 2012/6/19 Jonathan Nieder <jrnieder@gmail.com>:
>> Camaleón wrote:

>>> Update: I've been running kernel 3.2.2-1 over 4 days (since last
>>> Saturday until today) and still haven't experienced any disconnection.
>>
>> Interesting.  I wonder if the workaround in f96b08a7e6f6 (brcmsmac:
>> fix tx queue flush infinite loop, 2012-01-17) has too short a timeout
>> and is backfiring.
>
> Mmm...
>
>> How about this patch, for 3.2.y kernels?  I suggest the following
>> steps for testing:
>
> (...)
>
> Thanks for the detailed steps.
>
> I've planned to start debugging over the weekend because I have more
> spare time for this but the last (yesterday?) set of updates for
> wheezy have left the system in a very bad shape. Is not only that N-M
> is reconnecting very often (!) but gnome-shell and mail-notification
> are segfaulting as crazy horses.
>
> I'm attaching the syslog.
>
> There is also a "new" segfault coming from "net/wireless/mlme.c" (I
> say "new" because I don't recall this file was involved in the past
> :-?) so given the current state of the system I'm a bit reluctant of
> running more test at least for now. Let's see if an upcoming update
> restores the sanity to the system. I'll keep you informed.

Just realized upstream was not in the cc.  Moving to there.

If I understand correctly, these symptoms are similar to those you
experienced with 3.2.9-1.  So there is no reason to believe
f96b08a7e6f6 is the source of the trouble after all.  The problem must
originate somewhere else.  Right?

Syslog at [1].

Thanks,
Jonathan

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=230;bug=664767

[...]
> Jun 23 12:43:28 stt300 kernel: [    0.000000] Linux version 3.2.0-1-686-pae (Debian 3.2.2-1) (ben@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 SMP Wed Feb 1 09:39:41 UTC 2012
[...]
> Jun 23 12:44:37 stt300 NetworkManager[1478]: <info> Activation (wlan0/wireless): connection 'WLAN_B5' has security, and secrets exist.  No new secrets needed.
[...]
> Jun 23 12:44:38 stt300 kernel: [   88.476883] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[...]
> Jun 23 12:44:40 stt300 dhclient: bound to 192.168.0.150 -- renewal in 123164 seconds.
[...]
> Jun 23 12:59:05 stt300 wpa_supplicant[1514]: wlan0: WPA: Group rekeying completed with 00:23:f8:9d:ad:11 [GTK=TKIP]
[...]
> Jun 23 13:14:41 stt300 wpa_supplicant[1514]: wlan0: WPA: Key negotiation completed with 00:23:f8:9d:ad:11 [PTK=TKIP GTK=TKIP]
[...]
> Jun 23 13:29:05 stt300 wpa_supplicant[1514]: wlan0: WPA: Group rekeying completed with 00:23:f8:9d:ad:11 [GTK=TKIP]
[...]
> Jun 23 13:41:44 stt300 kernel: [ 3513.868441] ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled: false (implement)
> Jun 23 13:41:44 stt300 kernel: [ 3513.868462] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated
> Jun 23 13:41:44 stt300 kernel: [ 3513.868478] ieee80211 phy0: brcms_ops_bss_info_changed: arp filtering: enabled false, count 1 (implement)
> Jun 23 13:41:45 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
> Jun 23 13:41:45 stt300 kernel: [ 3514.806036] cfg80211: Calling CRDA to update world regulatory domain
[...]
> Jun 23 13:41:45 stt300 kernel: [ 3514.825799] cfg80211: Calling CRDA for country: ES
> Jun 23 13:41:45 stt300 kernel: [ 3514.840865] cfg80211: Regulatory domain changed to country: ES
[...]
> Jun 23 13:41:46 stt300 NetworkManager[1478]: <info> (wlan0): supplicant interface state: disconnected -> scanning
> Jun 23 13:41:47 stt300 wpa_supplicant[1514]: wlan0: SME: Trying to authenticate with 00:23:f8:9d:ad:11 (SSID='WLAN_B5' freq=2437 MHz)
[...]
> Jun 23 13:41:49 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 13:47:28 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 13:47:30 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 13:49:35 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 13:49:38 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 13:50:24 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 13:50:31 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 13:51:33 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 13:51:35 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 13:54:54 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 13:54:56 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 13:58:59 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 13:59:01 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 13:59:49 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 13:59:52 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 14:01:29 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 14:01:42 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 14:06:57 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 14:07:27 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 14:07:27 stt300 kernel: [ 5057.456105] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 14:07:27 stt300 kernel: [ 5057.458183] ------------[ cut here ]------------
> Jun 23 14:07:27 stt300 kernel: [ 5057.458245] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:309 cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]()
> Jun 23 14:07:27 stt300 kernel: [ 5057.458266] Hardware name: Compaq Mini CQ10-500            
> Jun 23 14:07:27 stt300 kernel: [ 5057.458276] Modules linked in: acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative parport_pc ppdev lp parport binfmt_misc uinput fuse loop uvcvideo arc4 videodev media brcmsmac joydev cordic crc8 brcmutil mac80211 hp_wmi cfg80211 snd_hda_codec_idt i915 snd_hda_intel sparse_keymap rfkill snd_hda_codec snd_hwdep snd_pcm rts_pstor(C) drm_kms_helper snd_page_alloc iTCO_wdt r8169 evdev snd_seq snd_seq_device snd_timer drm i2c_algo_bit snd uhci_hcd pcspkr psmouse serio_raw iTCO_vendor_support mii ehci_hcd usbcore i2c_i801 usb_common soundcore i2c_core ac battery wmi power_supply video processor button reiserfs sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys
> Jun 23 14:07:27 stt300 kernel: [ 5057.458528] Pid: 4002, comm: kworker/u:0 Tainted: G         C   3.2.0-1-686-pae #1
> Jun 23 14:07:27 stt300 kernel: [ 5057.458541] Call Trace:
> Jun 23 14:07:27 stt300 kernel: [ 5057.458569]  [<c1038328>] ? warn_slowpath_common+0x68/0x79
> Jun 23 14:07:27 stt300 kernel: [ 5057.458617]  [<f862ab97>] ? cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]
> Jun 23 14:07:27 stt300 kernel: [ 5057.458638]  [<c1038346>] ? warn_slowpath_null+0xd/0x10
> Jun 23 14:07:27 stt300 kernel: [ 5057.458684]  [<f862ab97>] ? cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]
> Jun 23 14:07:27 stt300 kernel: [ 5057.458737]  [<f87cbee7>] ? ieee80211_probe_auth_done+0x21/0x98 [mac80211]
> Jun 23 14:07:27 stt300 kernel: [ 5057.458791]  [<f87cee5a>] ? ieee80211_work_work+0xda7/0xde4 [mac80211]
> Jun 23 14:07:27 stt300 kernel: [ 5057.458814]  [<c12b8410>] ? __schedule+0x54b/0x55b
> Jun 23 14:07:27 stt300 kernel: [ 5057.458886]  [<f8753f2a>] ? intel_idle_update+0x33/0x18f [i915]
> Jun 23 14:07:27 stt300 kernel: [ 5057.458908]  [<c10499e3>] ? process_one_work+0x112/0x1fa
> Jun 23 14:07:27 stt300 kernel: [ 5057.458959]  [<f87ce0b3>] ? free_work+0xd/0xd [mac80211]
> Jun 23 14:07:27 stt300 kernel: [ 5057.458980]  [<c104a6ee>] ? worker_thread+0xa9/0x122
> Jun 23 14:07:27 stt300 kernel: [ 5057.458999]  [<c104a645>] ? manage_workers.isra.23+0x13d/0x13d
> Jun 23 14:07:27 stt300 kernel: [ 5057.459018]  [<c104d02f>] ? kthread+0x63/0x68
> Jun 23 14:07:27 stt300 kernel: [ 5057.459036]  [<c104cfcc>] ? kthread_worker_fn+0x101/0x101
> Jun 23 14:07:27 stt300 kernel: [ 5057.459056]  [<c12be1be>] ? kernel_thread_helper+0x6/0x10
> Jun 23 14:07:27 stt300 kernel: [ 5057.459069] ---[ end trace da1b8e557d7583b2 ]---
> Jun 23 14:07:27 stt300 NetworkManager[1478]: <info> (wlan0): deactivating device (reason 'supplicant-timeout') [11]
[...]
> Jun 23 14:11:11 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 14:11:32 stt300 NetworkManager[1478]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
> Jun 23 14:12:49 stt300 kernel: [ 5379.399774] mail-notificati[2603]: segfault at 4c ip 08060113 sp bfa06b20 error 4 in mail-notification[8048000+5d000]
[...]
> Jun 23 14:22:10 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 14:22:13 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 15:08:28 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 15:08:31 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 15:24:27 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 15:24:30 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 15:27:40 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 15:27:42 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 15:29:51 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 15:30:25 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 15:30:25 stt300 NetworkManager[1478]: <info> (wlan0): device state change: activated -> disconnected (reason 'supplicant-timeout') [100 30 11]
> Jun 23 15:30:25 stt300 kernel: [10034.732100] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 15:30:25 stt300 kernel: [10034.733834] ------------[ cut here ]------------
> Jun 23 15:30:25 stt300 kernel: [10034.733895] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:309 cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]()
> Jun 23 15:30:25 stt300 kernel: [10034.733916] Hardware name: Compaq Mini CQ10-500            
> Jun 23 15:30:25 stt300 kernel: [10034.733925] Modules linked in: acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative parport_pc ppdev lp parport binfmt_misc uinput fuse loop uvcvideo arc4 videodev media brcmsmac joydev cordic crc8 brcmutil mac80211 hp_wmi cfg80211 snd_hda_codec_idt i915 snd_hda_intel sparse_keymap rfkill snd_hda_codec snd_hwdep snd_pcm rts_pstor(C) drm_kms_helper snd_page_alloc iTCO_wdt r8169 evdev snd_seq snd_seq_device snd_timer drm i2c_algo_bit snd uhci_hcd pcspkr psmouse serio_raw iTCO_vendor_support mii ehci_hcd usbcore i2c_i801 usb_common soundcore i2c_core ac battery wmi power_supply video processor button reiserfs sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys
> Jun 23 15:30:25 stt300 kernel: [10034.734250] Pid: 4638, comm: kworker/u:0 Tainted: G        WC   3.2.0-1-686-pae #1
> Jun 23 15:30:25 stt300 kernel: [10034.734263] Call Trace:
> Jun 23 15:30:25 stt300 kernel: [10034.734294]  [<c1038328>] ? warn_slowpath_common+0x68/0x79
> Jun 23 15:30:25 stt300 kernel: [10034.734341]  [<f862ab97>] ? cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]
> Jun 23 15:30:25 stt300 kernel: [10034.734361]  [<c1038346>] ? warn_slowpath_null+0xd/0x10
> Jun 23 15:30:25 stt300 kernel: [10034.734404]  [<f862ab97>] ? cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]
> Jun 23 15:30:25 stt300 kernel: [10034.734457]  [<f87cbee7>] ? ieee80211_probe_auth_done+0x21/0x98 [mac80211]
> Jun 23 15:30:25 stt300 kernel: [10034.734512]  [<f87cee5a>] ? ieee80211_work_work+0xda7/0xde4 [mac80211]
> Jun 23 15:30:25 stt300 kernel: [10034.734534]  [<c12b8410>] ? __schedule+0x54b/0x55b
> Jun 23 15:30:25 stt300 kernel: [10034.734596]  [<f8747569>] ? i915_gem_retire_requests_ring+0xef/0x122 [i915]
> Jun 23 15:30:25 stt300 kernel: [10034.734660]  [<f8749a87>] ? i915_gem_retire_work_handler+0x41/0xf7 [i915]
> Jun 23 15:30:25 stt300 kernel: [10034.734683]  [<c10499e3>] ? process_one_work+0x112/0x1fa
> Jun 23 15:30:25 stt300 kernel: [10034.734735]  [<f87ce0b3>] ? free_work+0xd/0xd [mac80211]
> Jun 23 15:30:25 stt300 kernel: [10034.734756]  [<c104a6ee>] ? worker_thread+0xa9/0x122
> Jun 23 15:30:25 stt300 kernel: [10034.734775]  [<c104a645>] ? manage_workers.isra.23+0x13d/0x13d
> Jun 23 15:30:25 stt300 kernel: [10034.734793]  [<c104d02f>] ? kthread+0x63/0x68
> Jun 23 15:30:25 stt300 kernel: [10034.734812]  [<c104cfcc>] ? kthread_worker_fn+0x101/0x101
> Jun 23 15:30:25 stt300 kernel: [10034.734832]  [<c12be1be>] ? kernel_thread_helper+0x6/0x10
> Jun 23 15:30:25 stt300 kernel: [10034.734846] ---[ end trace da1b8e557d7583b3 ]---
[...]
> Jun 23 15:32:04 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 15:32:04 stt300 kernel: [10134.528104] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 15:32:04 stt300 kernel: [10134.528213] ------------[ cut here ]------------
> Jun 23 15:32:04 stt300 kernel: [10134.528272] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:309 cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]()
[...]
> Jun 23 15:32:21 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 15:32:21 stt300 kernel: [10150.816183] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 15:32:21 stt300 NetworkManager[1478]: <info> (wlan0): supplicant interface state: authenticating -> disconnected
> Jun 23 15:32:21 stt300 kernel: [10150.824142] ------------[ cut here ]------------
> Jun 23 15:32:21 stt300 kernel: [10150.824205] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:309 cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]()
[...]
> Jun 23 15:32:33 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (auth) [id=0 id_str=]
[...]
> Jun 23 16:03:57 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:03:59 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 16:06:45 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:09:55 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 16:09:55 stt300 kernel: [12405.648116] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 16:09:55 stt300 NetworkManager[1478]: <info> (wlan0): supplicant interface state: associating -> disconnected
> Jun 23 16:09:55 stt300 kernel: [12405.664163] ------------[ cut here ]------------
> Jun 23 16:09:55 stt300 kernel: [12405.664225] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:366 cfg80211_send_assoc_timeout+0xbc/0xbe [cfg80211]()
[...]
> Jun 23 16:09:58 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 16:15:23 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:16:02 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 16:16:02 stt300 kernel: [12771.844163] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 16:16:02 stt300 kernel: [12771.856283] ------------[ cut here ]------------
> Jun 23 16:16:02 stt300 kernel: [12771.856347] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:366 cfg80211_send_assoc_timeout+0xbc/0xbe [cfg80211]()
[...]
> Jun 23 16:18:14 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 16:18:14 stt300 kernel: [12904.608165] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 16:18:14 stt300 kernel: [12904.608270] ------------[ cut here ]------------
> Jun 23 16:18:14 stt300 kernel: [12904.608329] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:309 cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]()
[...]
> Jun 23 16:18:17 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 16:23:18 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:23:20 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 16:25:43 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:25:54 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> Jun 23 16:25:54 stt300 kernel: [13364.012098] wlan0: deauthenticating from 00:23:f8:9d:ad:11 by local choice (reason=3)
> Jun 23 16:25:54 stt300 kernel: [13364.013700] ------------[ cut here ]------------
> Jun 23 16:25:54 stt300 kernel: [13364.013762] WARNING: at /build/buildd-linux-2.6_3.2.2-1-i386-9uGbTI/linux-2.6-3.2.2/debian/build/source_i386_none/net/wireless/mlme.c:309 cfg80211_send_auth_timeout+0x5d/0x6a [cfg80211]()
[...]
> Jun 23 16:25:56 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 16:26:35 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:26:38 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]
> Jun 23 16:27:39 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:27:43 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
> Jun 23 16:27:43 stt300 NetworkManager[1478]: <info> (wlan0): supplicant interface state: 4-way handshake -> completed
> Jun 23 16:28:37 stt300 kernel: [13527.683194] gnome-shell[2591]: segfault at 2c ip b76b5c1f sp bf86b3a0 error 4 in libgnome-shell.so[b7677000+9d000]
> Jun 23 16:28:38 stt300 x-session-manager[1886]: WARNING: Application 'gnome-shell.desktop' killed by signal 11
[...]
> Jun 23 16:33:08 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4
[...]
> Jun 23 16:33:10 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:23:f8:9d:ad:11 completed (reauth) [id=0 id_str=]
[...]

Re: [3.2.y] Brcmsmac driver woes, possible regression?

[Arend van Spriel]

On 06/23/2012 07:50 PM, Jonathan Nieder wrote:
> Hi again,
> 
> Camaleón wrote[1]:
>> 2012/6/19 Jonathan Nieder <jrnieder@gmail.com>:
>>> Camaleón wrote:
> 
>>>> Update: I've been running kernel 3.2.2-1 over 4 days (since last
>>>> Saturday until today) and still haven't experienced any disconnection.
>>>
>>> Interesting.  I wonder if the workaround in f96b08a7e6f6 (brcmsmac:
>>> fix tx queue flush infinite loop, 2012-01-17) has too short a timeout
>>> and is backfiring.
>>
>> Mmm...
>>
>>> How about this patch, for 3.2.y kernels?  I suggest the following
>>> steps for testing:
>>
>> (...)
>>
>> Thanks for the detailed steps.
>>
>> I've planned to start debugging over the weekend because I have more
>> spare time for this but the last (yesterday?) set of updates for
>> wheezy have left the system in a very bad shape. Is not only that N-M
>> is reconnecting very often (!) but gnome-shell and mail-notification
>> are segfaulting as crazy horses.
>>
>> I'm attaching the syslog.
>>
>> There is also a "new" segfault coming from "net/wireless/mlme.c" (I
>> say "new" because I don't recall this file was involved in the past
>> :-?) so given the current state of the system I'm a bit reluctant of
>> running more test at least for now. Let's see if an upcoming update
>> restores the sanity to the system. I'll keep you informed.
> 
> Just realized upstream was not in the cc.  Moving to there.
> 
> If I understand correctly, these symptoms are similar to those you
> experienced with 3.2.9-1.  So there is no reason to believe
> f96b08a7e6f6 is the source of the trouble after all.  The problem must
> originate somewhere else.  Right?
> 
> Syslog at [1].
> 
> Thanks,
> Jonathan
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=230;bug=664767
> 
> [...]
>> Jun 23 12:43:28 stt300 kernel: [    0.000000] Linux version 3.2.0-1-686-pae (Debian 3.2.2-1) (ben@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 SMP Wed Feb 1 09:39:41 UTC 2012
> [...]
>> Jun 23 12:44:37 stt300 NetworkManager[1478]: <info> Activation (wlan0/wireless): connection 'WLAN_B5' has security, and secrets exist.  No new secrets needed.
> [...]
>> Jun 23 12:44:38 stt300 kernel: [   88.476883] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [...]
>> Jun 23 12:44:40 stt300 dhclient: bound to 192.168.0.150 -- renewal in 123164 seconds.
> [...]
>> Jun 23 12:59:05 stt300 wpa_supplicant[1514]: wlan0: WPA: Group rekeying completed with 00:23:f8:9d:ad:11 [GTK=TKIP]
> [...]
>> Jun 23 13:14:41 stt300 wpa_supplicant[1514]: wlan0: WPA: Key negotiation completed with 00:23:f8:9d:ad:11 [PTK=TKIP GTK=TKIP]
> [...]
>> Jun 23 13:29:05 stt300 wpa_supplicant[1514]: wlan0: WPA: Group rekeying completed with 00:23:f8:9d:ad:11 [GTK=TKIP]
> [...]
>> Jun 23 13:41:44 stt300 kernel: [ 3513.868441] ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled: false (implement)
>> Jun 23 13:41:44 stt300 kernel: [ 3513.868462] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated
>> Jun 23 13:41:44 stt300 kernel: [ 3513.868478] ieee80211 phy0: brcms_ops_bss_info_changed: arp filtering: enabled false, count 1 (implement)
>> Jun 23 13:41:45 stt300 wpa_supplicant[1514]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:23:f8:9d:ad:11 reason=4

This means AP is not receiving anything from this machine.

>> Jun 23 13:41:45 stt300 kernel: [ 3514.806036] cfg80211: Calling CRDA to update world regulatory domain
> [...]
>> Jun 23 13:41:45 stt300 kernel: [ 3514.825799] cfg80211: Calling CRDA for country: ES
>> Jun 23 13:41:45 stt300 kernel: [ 3514.840865] cfg80211: Regulatory domain changed to country: ES
> [...]

I am curious how the system would behave if you select US instead ES
country.

Gr. AvS