Re: brcmsmac problems in wireless-testing

[Seth Forshee <seth.forshee@canonical.com>]

Bah, I managed to screw up the format of the headers somehow. Fixed the
subject.

On Wed, May 30, 2012 at 03:25:47PM -0500, Seth Forshee wrote:
> Hi Arend,
> 
> I'm seeing some problems with BCM43224 in a Macbook Air 4,1 in
> wireless-testing. The symptom is that transferring data on the
> connection isn't working, even though it appears to still be associated.
> Eventually network manager realizes the connection is dead and gets
> stuck in an endless loop of trying to reassociate until I take down the
> connection and bring it back up. I find the following in dmesg.
> 
> [  583.943618] WARNING: at /home/sforshee/wireless-testing/wireless-testing/drivers/net/wireless/brcm80211/brcmsmac/main.c:7968 brcms_c_wait_for_tx_completion+0x99/0xb0 [brcmsmac]()
> [  583.943626] Hardware name: MacBookAir4,1
> [  583.943629] Modules linked in: hidp dm_crypt snd_hda_codec_hdmi snd_hda_codec_cirrus arc4 brcmsmac mac80211 brcmutil cfg80211 cordic joydev snd_hda_intel snd_hda_codec snd_hwdep snd_pcm applesmc input_polldev coretemp snd_seq_midi microcode snd_rawmidi rfcomm uvcvideo bnep snd_seq_midi_event parport_pc videobuf2_core videodev snd_seq ppdev btusb videobuf2_vmalloc snd_timer bluetooth videobuf2_memops bcm5974 snd_seq_device snd soundcore bcma snd_page_alloc apple_bl mei(C) mac_hid lp parport hid_apple usbhid hid ghash_clmulni_intel aesni_intel cryptd aes_x86_64 i915 drm_kms_helper drm i2c_algo_bit video [last unloaded: ipmi_msghandler]
> [  583.943733] Pid: 63, comm: kworker/u:6 Tainted: G         C   3.4.0-030400+brcmreg201205292159-generic #030400+brcmreg201205292159
> [  583.943740] Call Trace:
> [  583.943756]  [<ffffffff8105022f>] warn_slowpath_common+0x7f/0xc0
> [  583.943765]  [<ffffffff8105028a>] warn_slowpath_null+0x1a/0x20
> [  583.943785]  [<ffffffffa03c2bd9>] brcms_c_wait_for_tx_completion+0x99/0xb0 [brcmsmac]
> [  583.943798]  [<ffffffffa03b35fb>] brcms_ops_flush+0x3b/0x60 [brcmsmac]
> [  583.943840]  [<ffffffffa03483ed>] ieee80211_mgd_probe_ap_send+0x12d/0x1f0 [mac80211]
> [  583.943852]  [<ffffffff8101258b>] ? __switch_to+0x12b/0x420
> [  583.943864]  [<ffffffff8167707e>] ? _raw_spin_lock+0xe/0x20
> [  583.943892]  [<ffffffffa0348aaf>] ieee80211_mgd_probe_ap.part.22+0x10f/0x130 [mac80211]
> [  583.943917]  [<ffffffffa0348c4e>] ieee80211_sta_monitor_work+0x2e/0x30 [mac80211]
> [  583.943928]  [<ffffffff8106d52a>] process_one_work+0x12a/0x420
> [  583.943952]  [<ffffffffa0348c20>] ? ieee80211_beacon_connection_loss_work+0x150/0x150 [mac80211]
> [  583.943962]  [<ffffffff8106e0ce>] worker_thread+0x12e/0x2f0
> [  583.943972]  [<ffffffff8106dfa0>] ? manage_workers.isra.25+0x200/0x200
> [  583.943980]  [<ffffffff81072d63>] kthread+0x93/0xa0
> [  583.943989]  [<ffffffff816805a4>] kernel_thread_helper+0x4/0x10
> [  583.943997]  [<ffffffff81072cd0>] ? flush_kthread_worker+0x80/0x80
> [  583.944004]  [<ffffffff816805a0>] ? gs_change+0x13/0x13
> [  583.944009] ---[ end trace 32b6c1209a07d73c ]---
> [ 1018.400892] ieee80211 phy0: brcms_c_prec_enq_head: No where to go, prec == 4
> 
> This last message repeats indefinitely until disassociating with the AP.
> I also found an instance of this in my logs where I start getting the
> messages from brcms_c_prec_enq_head without the warning.
> 
> I'm not doing anything specific to trigger the issue. I've found it in
> this state a couple times after the machine has been left sitting idle
> for a while. I'm currently trying to reproduce it again so I can poke at
> it some more.
> 
> Let me know if you have any ideas. Bisecting will be problematic due to
> the variability in reproducing, but I don't think I've ever seen this in
> 3.4.
> 
> Thanks,
> Seth
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html