Created attachment 705792 [details] dmesg output Description of problem: Network stopped working, ie, no data transfer took place. Following lines were in dmesg when I checked: [23600.787689] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23738.714806] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23835.778563] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23914.756808] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23927.582210] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: Pkt tx suppressed, illegal channel possibly 2 [23932.698670] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23952.324598] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23954.164160] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23962.905110] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23972.526450] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23972.526870] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23972.527314] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23972.536100] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [23984.557540] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24002.733101] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24238.775512] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24498.624774] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24612.508718] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24643.101483] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24728.807946] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24731.048981] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24738.295214] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24738.533530] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [24773.308174] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: enabled true, count 0 (implement) Version-Release number of selected component (if applicable): Linux dhcppc1 3.8.1-201.fc18.x86_64 #1 SMP Thu Feb 28 19:23:08 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Observed once till now. Will keep an eye out for future occurrences. Steps to Reproduce: 1.NA. Happened on it's own. 2.Restarting wifi got network back to working 3. complete dmesg attached.
Ankur, Is this still an issue with 3.8.8 or so? I see a the following under heavy load here, but device remains functional. Will let you know if I make headway on it. [23927.582210] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: Pkt tx suppressed, illegal channel possibly 2 They phyerr I haven't seen. Let me know if it's still an issue with 3.8.8.
Hi John, I'm on 3.9.0 on F19 and the device seems to work OK. dmesg is still full of these, but the device continues to work, no hangups recently: [122826.976644] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [122829.145385] brcmsmac bcma0:0: phyerr 0x10, rate 0x6e [122829.145395] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122829.145726] brcmsmac bcma0:0: phyerr 0x10, rate 0x6e [122829.145734] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122829.146207] brcmsmac bcma0:0: phyerr 0x10, rate 0x6e [122829.146215] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122831.320068] brcmsmac bcma0:0: phyerr 0x10, rate 0x14 [122831.320078] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122831.320778] brcmsmac bcma0:0: phyerr 0x10, rate 0x14 [122831.320784] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122831.321509] brcmsmac bcma0:0: phyerr 0x10, rate 0x14 [122831.321525] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122840.889758] brcmsmac bcma0:0: phyerr 0x1, rate 0x6e [122840.889770] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [122840.889934] brcmsmac bcma0:0: phyerr 0x1, rate 0x6e [122840.889939] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [122840.890120] brcmsmac bcma0:0: phyerr 0x1, rate 0x6e [122840.890127] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [122848.184925] brcmsmac bcma0:0: phyerr 0x10, rate 0x14 [122848.184973] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122848.185802] brcmsmac bcma0:0: phyerr 0x10, rate 0x14 [122848.185817] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [122848.186640] brcmsmac bcma0:0: phyerr 0x10, rate 0x14 [122848.186656] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [ankur@ankur-pc ~]$ Thanks, Warm regards, Ankur
Created attachment 743662 [details] another dmesg output
Nothing upstream I see as a fix yet..Have seen similar messages here on my set up with BCM943224HMS when sending high throughput on using iperf.. Device stays connected but litters the logs with these. add Arend to cc list. Arend: any idea about these phy errs? They seem innocent enough: any fix for this or guidelines about which phy errors are serious enough to warrant such LOUD log messages. I can tone do the noise, but no idea what PHY errors are one to pay attention to..just disable this since it's apparently recoverable?
I just updated to Linux ankur-pc 3.9.3-301.fc19.x86_64 #1 SMP Mon May 20 12:50:56 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I still get these: [ 8249.675034] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [ 8249.675210] brcmsmac bcma0:0: phyerr 0x1, rate 0x14 [ 8249.675215] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [ankur@ankur-pc ~]$ Quite a lot of them. The wifi output does seem to be affected. Evolution/Emapthy etc begin to have connectivity issues. I'm not sure if this is caused by a congested network or a driver issue though. Too many variables :/ Thanks, Ankur
Created attachment 750839 [details] dmesg output 3.9.3-301 kernel
(In reply to Ankur Sinha (FranciscoD) from comment #5) > I just updated to > Linux ankur-pc 3.9.3-301.fc19.x86_64 #1 SMP Mon May 20 12:50:56 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux > > > I still get these: > > [ 8249.675034] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx > phy error (0x1) > [ 8249.675210] brcmsmac bcma0:0: phyerr 0x1, rate 0x14 > [ 8249.675215] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx > phy error (0x1) > [ankur@ankur-pc ~]$ > > > Quite a lot of them. The wifi output does seem to be affected. > Evolution/Emapthy etc begin to have connectivity issues. I'm not sure if > this is caused by a congested network or a driver issue though. Too many > variables :/ > > Thanks, > Ankur I can tone down the messages easily, but can you quantify "The wifi output does seem to be affected"?
Hi John, I only checked dmesg because both evolution and empathy began to give time out errors. Firefox seemed to work OK, but it does use caches. It's difficult to pin point if wifi had stopped working or if some component in gnome that's common to both evolution and empathy had begun to hang up. Thanks, Ankur
Ankur, PHY problems are usually radio issue. What is the signal quality like at the point this fails? If signal strength is low, or signal quality is bad, I'd expect this kind of thing. Take a look at this location: its an excellent guide to help you find this data and we'll sort out if this is a radio problem or driver/software issue. http://www.cyberciti.biz/tips/linux-find-out-wireless-network-speed-signal-strength.html Once you reproduce the problem, I'd like to see a bit of output from the iwconfig Interface-Name-Here iwconfig wlan0 Sample outputs: wlan0 IEEE 802.11abgn ESSID:"nixcraft5g" Mode:Managed Frequency:5.18 GHz Access Point: 74:44:44:44:57:FC Bit Rate=6 Mb/s Tx-Power=15 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=41/70 Signal level=-69 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:28 Missed beacon:0mmands: A number of samples over time are good also..
Hi John, I'll look into this and provide data by next week. Thanks for the link. Warm regards, Ankur
Created attachment 760182 [details] Wavemon screenshot Attached is a screenshot from wavemon when I noticed dmesg going: ac bcma0:0: phyerr 0x10, rate 0xa [181630.247213] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [181630.248470] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [181630.248478] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [181630.249761] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [181630.249769] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [181692.983760] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [181692.983770] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [181692.985893] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [181692.985919] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [181692.991126] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [181692.991137] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [181739.261864] brcmsmac bcma0:0: phyerr 0x8, rate 0xa [181739.261883] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x8) [181762.140340] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [181762.140353] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [181808.465581] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181808.465592] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181808.467531] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181808.467550] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181808.471180] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181808.471220] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181817.436883] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181817.436893] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181817.437207] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181817.437214] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181904.876789] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181904.876868] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181904.883168] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181904.883176] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181904.888155] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181904.888161] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181914.523912] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181914.523950] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181914.527594] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181914.527667] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181914.527876] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [181914.527890] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [181939.929900] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [181939.929941] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [182045.219459] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [182045.219505] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [182045.221668] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [182045.221709] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [182045.226753] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [182045.226779] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [182084.878699] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182084.878710] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [182124.045935] brcmsmac bcma0:0: wl0: brcms_c_d11hdrs_mac80211: txop exceeded phylen 130/256 dur 1546/1504 [182157.004268] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182157.004277] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [182188.207760] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182188.207768] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [182198.439857] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182198.439868] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [182198.459695] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182198.459729] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [182334.907401] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182334.907438] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [182334.910903] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182334.910942] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [182557.195894] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [182557.195905] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [182577.804709] brcmsmac bcma0:0: phyerr 0x10, rate 0xa [182577.804793] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) [182809.526865] brcmsmac bcma0:0: phyerr 0x8, rate 0xa [182809.526874] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x8) [182809.528956] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [182809.528966] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [183129.623385] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [183129.623412] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [183129.623640] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [183129.623673] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [183129.623844] brcmsmac bcma0:0: phyerr 0x1, rate 0xa [183129.623871] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) .... I think it's a signal issue. The quality doesn't go about 53/70 and the signal level remains around a -60dBm. Thanks, Ankur
Actually it's not bad..Most cards are good to -75 to -80. This would be "3 bar" of 5 so it's reasonable. At least the phyerrs don't *appear* to be coming from low signal or noise based on those numbers. You have 2 issues here. When the apps timeout, you get log spam. When you get the timeouts, try this and let me know if it clears up. If so, I suspect a driver / firmware issue maybe: modprobe -r brcmsmac modprobe brcmsmac See if that helps it recover and stay for a while. These kind of things are normal part of radio world, but it should recover better, IMHO. As to the log spam: The messages can be cut back with a small of the print statement to reduce the log spam. Fixed one the other day, in this exact area..
Ok. I'll do that and report. Thanks :) Warm regards, Ankur
(In reply to Ankur Sinha (FranciscoD) from comment #11) > Created attachment 760182 [details] > Wavemon screenshot > ... > [182045.226753] brcmsmac bcma0:0: phyerr 0x10, rate 0xa > [182045.226779] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu > tx phy error (0x10) > [182084.878699] brcmsmac bcma0:0: phyerr 0x1, rate 0xa > [182084.878710] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu > tx phy error (0x1) > [182124.045935] brcmsmac bcma0:0: wl0: brcms_c_d11hdrs_mac80211: txop > exceeded phylen 130/256 dur 1546/1504 ... > > I think it's a signal issue. The quality doesn't go about 53/70 and the > signal level remains around a -60dBm. > > Thanks, > Ankur Hmm..Just now noticed this above..txop exceeded phylen msg..maybe a significant clue to the reason. Will check into this also.
Hi John, The modprobe steps don't seem to be working. I haven't been able to connect to the university network at all today. Weirdly enough, it was working just fine on Friday. The university wifi stopped working yesterday so they may have changed stuff in it. My other devices are connecting fine to it though, so I don't think they broke anything. I thought it could be because of excess traffic so I tried connecting to a wifi hotspot on my phone. It didn't connect to it either. dmesg is again littered with: [ 133.598885] wlp18s0: authenticate with d8:c7:c8:8a:c8:61 [ 133.601691] wlp18s0: send auth to d8:c7:c8:8a:c8:61 (try 1/3) [ 133.603476] wlp18s0: authenticated [ 133.604082] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 1/3) [ 133.604253] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 133.604268] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 2/3) [ 133.604453] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 133.604465] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 3/3) [ 133.604654] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 133.604665] wlp18s0: association with d8:c7:c8:8a:c8:61 timed out [ 133.887942] wlp18s0: authenticate with d8:c7:c8:8a:c7:61 [ 133.890731] wlp18s0: send auth to d8:c7:c8:8a:c7:61 (try 1/3) [ 133.892565] wlp18s0: authenticated [ 133.893063] wlp18s0: associate with d8:c7:c8:8a:c7:61 (try 1/3) [ 133.893207] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 133.893233] wlp18s0: associate with d8:c7:c8:8a:c7:61 (try 2/3) [ 133.893407] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 133.893435] wlp18s0: associate with d8:c7:c8:8a:c7:61 (try 3/3) [ 133.893608] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 133.893634] wlp18s0: association with d8:c7:c8:8a:c7:61 timed out [ 134.178902] wlp18s0: authenticate with d8:c7:c8:8a:93:81 [ 134.180726] wlp18s0: send auth to d8:c7:c8:8a:93:81 (try 1/3) [ 134.182566] wlp18s0: authenticated [ 134.183086] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 1/3) [ 134.186133] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.186189] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 2/3) [ 134.186461] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.186482] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 3/3) [ 134.186911] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.186929] wlp18s0: association with d8:c7:c8:8a:93:81 timed out [ 134.412130] wlp18s0: authenticate with d8:c7:c8:8a:bc:a1 [ 134.414666] wlp18s0: send auth to d8:c7:c8:8a:bc:a1 (try 1/3) [ 134.416309] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.416335] wlp18s0: send auth to d8:c7:c8:8a:bc:a1 (try 2/3) [ 134.417112] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.417170] wlp18s0: send auth to d8:c7:c8:8a:bc:a1 (try 3/3) [ 134.419829] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.419900] wlp18s0: authentication with d8:c7:c8:8a:bc:a1 timed out [ 134.644294] wlp18s0: authenticate with d8:c7:c8:8a:c7:81 [ 134.646096] wlp18s0: direct probe to d8:c7:c8:8a:c7:81 (try 1/3) [ 134.847195] wlp18s0: send auth to d8:c7:c8:8a:c7:81 (try 2/3) [ 134.849090] wlp18s0: authenticated [ 134.850191] wlp18s0: associate with d8:c7:c8:8a:c7:81 (try 1/3) [ 134.850421] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.850496] wlp18s0: associate with d8:c7:c8:8a:c7:81 (try 2/3) [ 134.850661] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.850723] wlp18s0: associate with d8:c7:c8:8a:c7:81 (try 3/3) [ 134.850874] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 134.850897] wlp18s0: association with d8:c7:c8:8a:c7:81 timed out [ 135.012986] wlp18s0: authenticate with d8:c7:c8:8a:c8:81 [ 135.017440] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 1/3) [ 135.215004] TCP: lp registered [ 135.218183] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 2/3) [ 135.419212] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 3/3) [ 135.620258] wlp18s0: authentication with d8:c7:c8:8a:c8:81 timed out [ 135.750805] wlp18s0: authenticate with d8:c7:c8:8a:c7:01 [ 135.750865] wlp18s0: direct probe to d8:c7:c8:8a:c7:01 (try 1/3) [ 135.951316] wlp18s0: direct probe to d8:c7:c8:8a:c7:01 (try 2/3) [ 136.152280] wlp18s0: direct probe to d8:c7:c8:8a:c7:01 (try 3/3) [ 136.353302] wlp18s0: authentication with d8:c7:c8:8a:c7:01 timed out [ 137.350230] wlp18s0: authenticate with d8:c7:c8:8a:c8:61 [ 137.351595] wlp18s0: send auth to d8:c7:c8:8a:c8:61 (try 1/3) [ 137.353481] wlp18s0: authenticated [ 137.354557] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 1/3) [ 137.363667] wlp18s0: RX AssocResp from d8:c7:c8:8a:c8:61 (capab=0x431 status=0 aid=8) [ 137.364301] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated [ 137.364308] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) [ 137.364321] wlp18s0: associated [ 137.364334] IPv6: ADDRCONF(NETDEV_CHANGE): wlp18s0: link becomes ready [ 137.372751] brcmsmac bcma0:0: phyerr 0x80, rate 0xb00 [ 158.157470] wlp18s0: deauthenticating from d8:c7:c8:8a:c8:61 by local choice (reason=3) [ 158.158424] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 158.158431] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) [ 158.159079] cfg80211: Calling CRDA to update world regulatory domain [ 158.167826] cfg80211: World regulatory domain updated: [ 158.167832] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 158.167834] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 158.167836] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 158.167837] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 158.167838] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 158.167840] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 158.167861] cfg80211: Calling CRDA for country: AU [ 158.178290] cfg80211: Regulatory domain changed to country: AU [ 158.178295] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 158.178297] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 158.178298] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2300 mBm) [ 158.178300] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2300 mBm) [ 158.178302] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) [ 161.711507] wlp18s0: authenticate with d8:c7:c8:8a:c7:61 [ 161.713396] wlp18s0: send auth to d8:c7:c8:8a:c7:61 (try 1/3) [ 161.717952] wlp18s0: authenticated [ 161.718961] wlp18s0: associate with d8:c7:c8:8a:c7:61 (try 1/3) [ 161.719842] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 161.719868] wlp18s0: associate with d8:c7:c8:8a:c7:61 (try 2/3) [ 161.720766] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 161.720788] wlp18s0: associate with d8:c7:c8:8a:c7:61 (try 3/3) [ 161.720949] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 161.720994] wlp18s0: association with d8:c7:c8:8a:c7:61 timed out [ 162.846159] wlp18s0: authenticate with d8:c7:c8:8a:93:81 [ 162.848770] wlp18s0: send auth to d8:c7:c8:8a:93:81 (try 1/3) [ 162.852416] wlp18s0: authenticated [ 162.853104] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 1/3) [ 162.853276] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 162.853290] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 2/3) [ 162.853512] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 162.853523] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 3/3) [ 162.853796] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 162.853813] wlp18s0: association with d8:c7:c8:8a:93:81 timed out [ 163.917158] wlp18s0: authenticate with d8:c7:c8:8a:bc:a1 [ 163.919798] wlp18s0: direct probe to d8:c7:c8:8a:bc:a1 (try 1/3) [ 164.120232] wlp18s0: direct probe to d8:c7:c8:8a:bc:a1 (try 2/3) [ 164.321212] wlp18s0: direct probe to d8:c7:c8:8a:bc:a1 (try 3/3) [ 164.522305] wlp18s0: authentication with d8:c7:c8:8a:bc:a1 timed out [ 165.554111] wlp18s0: authenticate with d8:c7:c8:8a:c7:01 [ 165.554197] wlp18s0: direct probe to d8:c7:c8:8a:c7:01 (try 1/3) [ 165.754380] wlp18s0: direct probe to d8:c7:c8:8a:c7:01 (try 2/3) [ 165.955432] wlp18s0: direct probe to d8:c7:c8:8a:c7:01 (try 3/3) [ 166.156450] wlp18s0: authentication with d8:c7:c8:8a:c7:01 timed out [ 167.187372] wlp18s0: authenticate with d8:c7:c8:8a:c8:81 [ 167.187443] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 1/3) [ 167.387588] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 2/3) [ 167.588603] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 3/3) [ 167.789631] wlp18s0: authentication with d8:c7:c8:8a:c8:81 timed out [ 169.691344] wlp18s0: authenticate with d8:c7:c8:8a:c8:61 [ 169.691764] wlp18s0: send auth to d8:c7:c8:8a:c8:61 (try 1/3) [ 169.693636] wlp18s0: authenticated [ 169.694796] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 1/3) [ 169.694946] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 169.694974] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 2/3) [ 169.695136] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 169.695274] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 3/3) [ 169.695417] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 169.695430] wlp18s0: association with d8:c7:c8:8a:c8:61 timed out [ 179.881801] wlp18s0: authenticate with d8:c7:c8:8a:c7:61 [ 179.884481] wlp18s0: send auth to d8:c7:c8:8a:c7:61 (try 1/3) [ 179.888700] wlp18s0: authenticated [ 179.889843] wlp18s0: associate with d8:c7:c8:8a:c7:61 (try 1/3) [ 179.894391] wlp18s0: RX AssocResp from d8:c7:c8:8a:c7:61 (capab=0x431 status=0 aid=6) [ 179.895071] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated [ 179.895074] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) [ 179.895080] wlp18s0: associated [ 187.159461] wlp18s0: deauthenticating from d8:c7:c8:8a:c7:61 by local choice (reason=3) [ 187.160416] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 187.160422] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) [ 187.162136] cfg80211: Calling CRDA to update world regulatory domain [ 187.165869] cfg80211: World regulatory domain updated: [ 187.165873] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 187.165875] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 187.165876] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 187.165878] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 187.165879] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 187.165880] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 187.165899] cfg80211: Calling CRDA for country: AU [ 187.168021] cfg80211: Regulatory domain changed to country: AU [ 187.168025] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 187.168027] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 187.168028] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2300 mBm) [ 187.168029] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2300 mBm) [ 187.168030] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) [ 191.332067] wlp18s0: authenticate with d8:c7:c8:8a:93:81 [ 191.334628] wlp18s0: send auth to d8:c7:c8:8a:93:81 (try 1/3) [ 191.337026] wlp18s0: authenticated [ 191.338030] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 1/3) [ 191.338356] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 191.338371] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 2/3) [ 191.338582] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 191.338602] wlp18s0: associate with d8:c7:c8:8a:93:81 (try 3/3) [ 191.338832] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 191.338850] wlp18s0: association with d8:c7:c8:8a:93:81 timed out [ 201.405854] wlp18s0: authenticate with d8:c7:c8:8a:bc:a1 [ 201.408748] wlp18s0: send auth to d8:c7:c8:8a:bc:a1 (try 1/3) [ 201.410088] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 201.410142] wlp18s0: send auth to d8:c7:c8:8a:bc:a1 (try 2/3) [ 201.410658] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 201.410698] wlp18s0: send auth to d8:c7:c8:8a:bc:a1 (try 3/3) [ 201.410893] brcmsmac bcma0:0: phyerr 0x4, rate 0xa [ 201.410919] wlp18s0: authentication with d8:c7:c8:8a:bc:a1 timed out [ 211.447094] wlp18s0: authenticate with d8:c7:c8:8a:c8:81 [ 211.447238] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 1/3) [ 211.648191] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 2/3) [ 211.849210] wlp18s0: direct probe to d8:c7:c8:8a:c8:81 (try 3/3) [ 212.050231] wlp18s0: authentication with d8:c7:c8:8a:c8:81 timed out [ 227.667481] cfg80211: Calling CRDA to update world regulatory domain [ 227.670673] cfg80211: World regulatory domain updated: [ 227.670678] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 227.670680] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 227.670682] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 227.670684] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 227.670686] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 227.670688] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 227.685799] bcma: bus0: Found chip with id 0x4313, rev 0x01 and package 0x08 [ 227.685844] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x24, class 0x0) [ 227.685869] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x18, class 0x0) [ 227.685918] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x11, class 0x0) [ 227.698206] bcma: bus0: Bus registered [ 227.707785] brcmsmac bcma0:0: mfg 4bf core 812 rev 24 class 0 irq 17 [ 227.708998] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 227.724004] cfg80211: Calling CRDA for country: AU [ 227.725341] systemd-udevd[3420]: renamed network interface wlan0 to wlp18s0 [ 227.727485] cfg80211: Regulatory domain changed to country: AU [ 227.727489] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 227.727491] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 227.727493] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2300 mBm) [ 227.727494] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2300 mBm) [ 227.727496] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) [ 227.891604] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) [ 227.891615] brcmsmac bcma0:0: brcms_ops_config: change power-save mode: false (implement) [ 227.891769] IPv6: ADDRCONF(NETDEV_UP): wlp18s0: link is not ready [ 227.946247] r8169 0000:13:00.0 p1p1: link down [ 227.946279] IPv6: ADDRCONF(NETDEV_UP): p1p1: link is not ready [ 300.206520] wlp18s0: authenticate with d8:c7:c8:8a:c8:61 [ 300.208394] wlp18s0: send auth to d8:c7:c8:8a:c8:61 (try 1/3) [ 300.210200] wlp18s0: authenticated [ 305.213987] wlp18s0: deauthenticating from d8:c7:c8:8a:c8:61 by local choice (reason=3) [ 369.822909] r8169 0000:13:00.0 p1p1: link up [ 369.822924] IPv6: ADDRCONF(NETDEV_CHANGE): p1p1: link becomes ready [ 370.084740] r8169 0000:13:00.0 p1p1: link down [ 371.700074] r8169 0000:13:00.0 p1p1: link up [ 431.899026] r8169 0000:13:00.0 p1p1: link down [ 433.749842] r8169 0000:13:00.0 p1p1: link up [ 434.176064] r8169 0000:13:00.0 p1p1: link down [ 460.303311] usb 2-1.5: new high-speed USB device number 4 using ehci-pci [ 460.389816] usb 2-1.5: New USB device found, idVendor=04e8, idProduct=6860 [ 460.389823] usb 2-1.5: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 460.389827] usb 2-1.5: Product: SAMSUNG_Android [ 460.389831] usb 2-1.5: Manufacturer: SAMSUNG [ 460.389834] usb 2-1.5: SerialNumber: 42f7ed041b348fcf [ 460.521151] cdc_acm 2-1.5:1.1: This device cannot do calls on its own. It is not a modem. [ 460.521220] cdc_acm 2-1.5:1.1: ttyACM0: USB ACM device [ 460.521921] usbcore: registered new interface driver cdc_acm [ 460.521923] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters [ 529.705936] wlp18s0: authenticate with 38:aa:3c:7f:1e:05 [ 529.708115] wlp18s0: send auth to 38:aa:3c:7f:1e:05 (try 1/3) [ 529.709642] wlp18s0: authenticated [ 534.713920] wlp18s0: deauthenticating from 38:aa:3c:7f:1e:05 by local choice (reason=3) [ 544.827711] wlp18s0: authenticate with 38:aa:3c:7f:1e:05 [ 544.827778] wlp18s0: send auth to 38:aa:3c:7f:1e:05 (try 1/3) [ 544.829437] wlp18s0: authenticated [ 545.195523] wlp18s0: deauthenticating from 38:aa:3c:7f:1e:05 by local choice (reason=3) [ 558.229236] wlp18s0: authenticate with 38:aa:3c:7f:1e:05 [ 558.229468] wlp18s0: send auth to 38:aa:3c:7f:1e:05 (try 1/3) [ 558.233111] wlp18s0: authenticated [ 563.234867] wlp18s0: deauthenticating from 38:aa:3c:7f:1e:05 by local choice (reason=3) The samsung stuff in the end is when I USB tethered my phone. (The phone is connected to the university wifi). I tried the modprobe part multiple times, as you'll see. In fact, I used an alias: alias wifi_restart='sudo systemctl stop NetworkManager.service ;sudo modprobe -r brcmsmac; sleep 1;sudo modprobe brcmsmac; sudo systemctl start NetworkManager.service ' and it hasn't worked today. I've tried both the latest kernels in F19: kernel-3.9.6-301.fc19.x86_64 kernel-3.9.8-300.fc19.x86_64 and none of them have connected to wifi today. I'll keep trying in regular intervals and post updates, if any. Thanks again. I'm sorry I haven't good news today. Warm regards, Ankur
John, Just wondering. Is it possible that the entire issue is caused by faulty hardware? I don't think so, but I could check up if you think that might be a cause. Thanks, Ankur
Reboot, and it connected in one go: [ 93.528127] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) [ 93.528140] brcmsmac bcma0:0: brcms_ops_config: change power-save mode: false (implement) [ 93.528346] IPv6: ADDRCONF(NETDEV_UP): wlp18s0: link is not ready [ 102.574228] wlp18s0: authenticate with d8:c7:c8:8a:c8:61 [ 102.576889] wlp18s0: send auth to d8:c7:c8:8a:c8:61 (try 1/3) [ 102.578696] wlp18s0: authenticated [ 102.579821] wlp18s0: associate with d8:c7:c8:8a:c8:61 (try 1/3) [ 102.583339] wlp18s0: RX AssocResp from d8:c7:c8:8a:c8:61 (capab=0x431 status=0 aid=5) [ 102.584004] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated [ 102.584009] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) [ 102.584019] wlp18s0: associated [ 102.584029] IPv6: ADDRCONF(NETDEV_CHANGE): wlp18s0: link becomes ready [ 103.403185] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement) [ 105.599944] TCP: lp registered [ 130.146516] brcmsmac bcma0:0: phyerr 0x1, rate 0x14 [ 130.146538] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [ 130.148295] brcmsmac bcma0:0: phyerr 0x1, rate 0x14 [ 130.148303] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1) [ 130.394383] brcmsmac bcma0:0: phyerr 0x1, rate 0x37 [... .... ... Ankur
(In reply to Ankur Sinha (FranciscoD) from comment #16) > John, > > Just wondering. Is it possible that the entire issue is caused by faulty > hardware? I don't think so, but I could check up if you think that might be > a cause. > > Thanks, > Ankur It's possible, but I see the stuff on another card too, BCM has mentioned this PHY stuff seems to have come into the fore after 3.8 kernel. In looking at another related issue I wondered if this might help your issue: disable bluetooth using: Can you disable bluetooth (rfkill block bluetooth)?
(In reply to John Greene from comment #18) > (In reply to Ankur Sinha (FranciscoD) from comment #16) > > John, > > > > Just wondering. Is it possible that the entire issue is caused by faulty > > hardware? I don't think so, but I could check up if you think that might be > > a cause. > > > > Thanks, > > Ankur > > It's possible, but I see the stuff on another card too, BCM has mentioned > this PHY stuff seems to have come into the fore after 3.8 kernel. > > In looking at another related issue I wondered if this might help your issue: > > disable bluetooth using: > Can you disable bluetooth (rfkill block bluetooth)? Hi John I don't think I have a bluetooth module on this laptop at all. It was removed at one of the service sessions and not replaced. BIOS doesn't show it either. Thanks, Ankur
Patch submitted upstream to make the message only visible in debug mode. Just a workaround, not a root cause.
John Greene, et al: I have a similar/the same issue with a Broadcom BCM4313, but on Debian. I know Debian is not Red Hat, and for that I apologize, however I can answer a few questions that are open in this thread. nmschulte@dv1540-ai-nms:~$ uname -a Linux dv1540-ai-nms 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux nmschulte@dv1540-ai-nms:~$ lspci -nn | grep Broadcom 12:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01) Disabling bluetooth via `rfkill block bluetooth` doesn't appear to resolve the issue; I still receive the phyerr/ampdu tx phy error log spam. Bouncing the kernel drive does work for me; as a temporary solution I use crontab to bounce the driver every hour. As well, I have seen once or twice a 'txop exceeded phylen' message in my kernel log, but I think that is a red herring; a symptom rather than a cause. I have created a bug report for Debian, but it doesn't appear to have any traction yet. You can see my kernel log and configuration there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712720 Again, apologies if doing what I just did is frowned upon; I just want this issue resolved!
nmshulte and friends, Appreciate you being willing to help. Couple updates: 1. the txop exceeded phylen is a non-starter. It's a notification that the window for the STA to transmit it's data was longer than the data it had to send. So just a warning that the air was idle. Not the problem. 2. I've posted a workaround patch upstream as a workaround to the messages which has been filling the logs. I'll post it here as well, has been ack'ed by BCM but it's only putting the messages into debug enabled logs. It doesn't address the base problem. Broadcom is still looking at the reason for this issue to have surfaced. That said, I expect that the same problem will exist on other distributions using substantially the same driver code, but have no direct view into them. I've offered assist with their investigations. More as I hear it..Till then, all I can say is phy module is having issues getting data out on transmit and getting an ack returned. And that's causing the errors. Needs more investigation.
Created attachment 775322 [details] Patch to move 2 PHY error message to debug, lessening log spam Has been submitted to net-next..
Thanks for the updates John Greene; glad to know there is movement behind the curtains. If I find the time, I'm considering bisecting the kernel to track down the issue, though I imagine BCM/others can do (and are doing) a better job.
(In reply to nmschulte from comment #24) > Thanks for the updates John Greene; glad to know there is movement behind > the curtains. > > If I find the time, I'm considering bisecting the kernel to track down the > issue, though I imagine BCM/others can do (and are doing) a better job. We might if we would know how to consistently replicate the issue. Once we have that we can go and bisect. I noticed the message in an automated test this morning and trying to derive the conditions. However, if you can consistently reproduce the problem it would be extremely helpful if you can do a bisect, but you need to know the good and the bad to catch the ugly. --- http://www.imdb.com/title/tt0060196/
(In reply to Arend van Spriel from comment #25) > We might if we would know how to consistently replicate the issue. Once we > have that we can go and bisect. I noticed the message in an automated test > this morning and trying to derive the conditions. > > However, if you can consistently reproduce the problem it would be extremely > helpful if you can do a bisect, but you need to know the good and the bad to > catch the ugly. Alright, noted. I was going to start from somewhere in 3.2, as that's the next latest 'good' build I believe I have. It sounds like I should be safe to jump somewhere into 3.7 or 3.8 though; if I could get a confirmation on a closer starting point I'd be more likely to jump in.
Similar issues "illegal channel" (not same errors though) were created here using iperf tx at high tx rates, basically flooding the tx on the part seem to create these issues. I have a upstream patch for this already..just bury the messages. I do feel the two are linked.. A lot of details about reproducing that may help: https://bugzilla.redhat.com/show_bug.cgi?id=960977
I've posted a couple workarounds upstream for the spam issues at least. They are small and will at least ease the irritation. No, it doesn't fix the problem but fixing the noise except for debug builds: 99e94940697adec4f84758adb2db71f4a82c7ba5 is in v3.10-rc1-214-g99e9494 a76e9ff18b7c4a3f8fc812fb71f55cb2eec74ba8 is v3.11-rc1-39-ga76e9ff commit a76e9ff18b7c4a3f8fc812fb71f55cb2eec74ba8 Author: John Greene <jogreene> Date: Mon Jul 15 14:33:34 2013 -0400 brcmsmac: Further reduce log spam from tx phy messages Relegate 2 phy messages to debug status as they create excessive log spam, noted in multiple bugzillas for brcmsmac v3.8 and up. This is a follow on to net-next 99e94940697adec4f84758adb2db71f4a82c7ba5: brcmsmac: Reduce log spam in heavy tx, make err print in debug brcmsmac bcma0:0: phyerr 0x10, rate 0x14 brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10) ..and.. commit 99e94940697adec4f84758adb2db71f4a82c7ba5 Author: John Greene <jogreene> Date: Mon Jun 3 09:47:39 2013 -0400 brcmsmac: Reduce log spam in heavy tx, make err print in debug Move message to debug mode to reduce log spam under heavy tx (iperf) load. This message prints in ht debug mode only: brcms_c_ampdu_dotxstatus_complete: Pkt tx suppressed, illegal channel possibly 153
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Hi, I am running arch linux and having the same issues here. Not sure if this has been solved with the latest fedora kernel release so it would be nice if you could provide some information. On my side I run this kernel uname -a Linux wom 3.11.1-1-ARCH #1 SMP PREEMPT Sat Sep 14 19:30:21 CEST 2013 x86_64 GNU/Linux And I get this output: sudo journalctl -b -2|grep brcm Sep 23 07:12:43 wom kernel: brcmsmac bcma0:0: mfg 4bf core 812 rev 24 class 0 irq 17 Sep 23 07:12:43 wom kernel: ieee80211 phy0: registered radio enabled led device: brcmsmac-phy0:radio gpio: 243 Sep 23 07:12:44 wom kernel: brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) Sep 23 07:12:44 wom kernel: brcmsmac bcma0:0: brcms_ops_config: change power-save mode: false (implement) Sep 23 07:12:44 wom NetworkManager[233]: <info> rfkill3: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.1/0000:06:00.0/bcma0:0/ieee80211/phy0/rfkill3) (driver brcmsmac) Sep 23 07:12:44 wom NetworkManager[233]: <info> (wlp6s0): new 802.11 WiFi device (driver: 'brcmsmac' ifindex: 3) Sep 23 07:12:46 wom kernel: brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated Sep 23 07:12:46 wom kernel: brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) Sep 23 07:12:46 wom kernel: brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement) Sep 23 07:12:46 wom kernel: brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement) Sep 23 07:14:03 wom kernel: brcmsmac bcma0:0: phyerr 0x4, rate 0xa Sep 23 07:15:29 wom kernel: brcmsmac bcma0:0: phyerr 0x4, rate 0xa Sep 23 07:16:03 wom kernel: brcmsmac bcma0:0: phyerr 0x4, rate 0xa Sep 23 07:21:59 wom kernel: brcmsmac bcma0:0: phyerr 0x20, rate 0xa Talking about perf (I have no idea what it is about) I see from time to time these guys showing up. Often in case of a complete system freeze: Sep 23 07:47:24 wom kernel: perf samples too long (2504 > 2500), lowering kernel.perf_event_max_sample_rate to 50100 Sep 23 08:56:07 wom kernel: perf samples too long (5036 > 4990), lowering kernel.perf_event_max_sample_rate to 25200 I hope this correlates some how and the information is usable to get this thing up and running again. I was also affected by this bug, not sure if they are related: https://bbs.archlinux.org/viewtopic.php?id=168177 Thanks for your reply, Kind Regards, Wompy
Wompy, perf, as I (understand it (not much!) is a kernel benchmark tool and test the kernel performance. Perhaps you can change your kernel build to exclude it if it is causing issues? As to brcmsmac phyerr/rate messages: I don't know what is causing them but have submitted a patch to lower the noise they create to the logs. Vendor is aware of the issues (which started apparently since 3.9). Not sure what the state is currently: I see some upstream that should be in v3.11.1. Sounds like that aren't helping this issues at least for you? Are these errors frequent for you and tied to any specific location (i.e. wireless router)? I know these issues seem to pop up when a bunch of traffic is going across the network when I saw them. If perf is running some net traffic bench mark (not obvious from the message above), that might be causing it. Can you disable/remove perf and let me know if that helps. Oh, if you can reproduce, I'd like for you (if you will?) post a couple things: 1. get connected to AP 2. note in log you see the phy errs 3. then post the output of: iwconfig wlan? and iwlist scanning I'd like to see what the wifi route is setup for when errors occur. Thanks.
Closing this due to age and no response. Hope your problem is solved? If not, please feel free to reopen this or a new bug and we will try to help. Happy Holidays to you.