Red Hat Bugzilla – Bug 982264
brcmsmac oopses and freezes all the time
Last modified: 2013-08-22 12:48:14 EDT
Created attachment 770503 [details]
Description of problem:
After upgrade to F19 I'm getting oopses and freezes all the time, if connected to one particular wifi network.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. connect to wifi at my mother in law's :-)
kernel oops/freeze thirty times a day (sometimes in a few minutes, sometimes it works a few hours)
[ 475.296402] brcmsmac bcma0:0: phyerr 0x1, rate 0x6e
[ 475.296407] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1)
[ 479.656696] brcmsmac bcma0:0: phyerr 0x10, rate 0x37
[ 479.656709] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10)
[ 479.657077] brcmsmac bcma0:0: phyerr 0x10, rate 0x37
[ 479.657080] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10)
[ 479.657494] brcmsmac bcma0:0: phyerr 0x10, rate 0x37
[ 479.657496] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x10)
[ 480.583350] brcmsmac bcma0:0: phyerr 0x1, rate 0x6e
[ 480.583364] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1)
[ 481.969076] brcmsmac bcma0:0: phyerr 0x1, rate 0x14
[ 481.969083] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete: ampdu tx phy error (0x1)
You have 2 distinct issues. Severity first:
The oops is you have a picture of is helpful to start, are you able to upload the crash log? Info that would be very helpful immediately PRECEEDS this dump.. This is usually saved in the crash log if you have the kernel debugging setup up. Does /var/crash exist? If not, some details about doing this are here, will hopefully make the camera unnecesary since it appears easy to reproduce (can you confirm that?). You might need to disable wifi and use ethernet to set this up.
Second, and less of an issue are the tx phy errors, I'm working on a patch today to mute the volume of them..
I recognize the screen snapshot. I first encounter it on 6/17/13 with f19-beta-x86_64. Some casual research with public networks I encounter leads me to cautiously say some networks are more prone to it than others. So much so as to once again, cautiously say specific router models and brands, (setting also, maybe) are more prone toward it than others.
I don't have the crash report. I'll put enabling it on my queue.
If someone can reproduce this a couple pieces of data will help in ongoing investigations: can someone help?
reproduce the issue, then upload the output of the following 2 commands:
This will help isolate the AP configuration and see if anything helps isolate this and other related issues.
Thanks in advance!
Hi Karel, John,
I've a short circuit method of reproducing this, as follows:
> cd /etc/sysconfig/network-scripts
> ifup ifcfg-dhcp
At one location kernel panic is for sure. I've not collected any data yet.
Thanks for the update Joseph.
Do you know the make/model of the AP at the in-laws? If it's like mine, something quite old from my history.. ;)
Might help a bit to know that.
Created attachment 779107 [details]
Created attachment 779109 [details]
Good Morning All;
I'm having a power breakfast with my friend Ronald. (Mr. McDonald) What's an AP? The first attachment is the iwconfig output.
Love breakfast there.
AP is for access point, another name for wireless router.
Ok, you are connected to a
Cell 01 - Address: 00:0F:8F:7E:EE:C2
Frequency:2.462 GHz (Channel 11)
Quality=70/70 Signal level=-36 dBm
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
11 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Extra: Last beacon: 11ms ago
IE: Unknown: 000761747477696669
IE: Unknown: 010882840B0C12961824
IE: Unknown: 03010B
IE: Unknown: 2A0104
IE: Unknown: 32043048606C
IE: Unknown: DD06004096010102
IE: Unknown: DD050040960303
IE: Unknown: DD1600409604000207A4000023A400004243000062320000
IE: Unknown: DD180050F2020101020003A4000027A4000042435E0062322F00
Looks like a Cisco/Linksys, since it's attwifi, probably what ever ATT provides them. Interesting that encryption is off. 802.11 b/g no 802.11n
I'd have to dig a bit further to be sure. It appears this AP isn't configured to be using 802.11n or if it's even capable of it. If you can connect to the AP and check it's configuration and enable 802.11n, you problem maybe fixed, that is, if the wireless router supports 802.11n. Can you check this first? Maybe the easiest to get the wireless router model number and google it for info and see if it lists 802.11n support.. Can you check that?
I picked up my mail yesterday, and have been thinking on this sporadically today. The access point from the iwconfig listing, incorrectly labeled in the attachments is provides the access point and ESSID.
wlp2s0 IEEE 802.11bgn ESSID:"attwifi"
Mode:Managed Frequency:2.462 GHz Access Point: 00:0F:8F:7E:EE:C2
Bit Rate=1 Mb/s Tx-Power=19 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
If I'm reading correctly your instructions offer a possible solution if I could configure the wireless router at McDonald's. Wireless tools give me access to my wifi card, but not to router's configuration. Now if it were my own Cisco wrt160 that'd be a easy.
Let me think on this some more if I'm not going off on tangent way off yonder, else correct me if I'm that for off.
Is the AP above at Mickey D's or your folks? Yes, Ronald probably won't let you config his router.. He's funny that way.
The one above just doesn't look like it's offering 802.11n and therefore no ampdu, which is causing your messages.
Created attachment 782356 [details]
hostname: sunbird, file: results of running `iwlist scan'
Good Morning Folks;
John, sorry stuff to do this morning, or I'd have brought my clown friend Ronald's coffee for the both of us. I believe it is Mr. Volny with the problem hardware; my relatives are all good hardworking people with outstanding wireless equipment. I don't have any kernel panics connecting wirelessly at McD's either by the way.
Where I am at now, a branch of the New York Public Library where I hide-a-way to get work done causes me all sorts of connection problems. This is the only branch of the NYPL where I have problems connecting.
I've just now installed f19, the release 32 bit version with Gnome desktop. Selected NYPL form the drop down list on the upper right hand corner of the desktop and lockedup my box. If I boot to the command line only, and do:
> cd /etc/sysconfig/network-scripts
> ifup ifcfg_Auto-NYPL
I'll get the kernel panic dump exactly the same as the screen snapshot Mr. Volney provided earlier.
I'm working on these instructions: http://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
and I'll keep you informed. Have a good weekend
Created attachment 782357 [details]
hostname: sunbird, file results of running `iwconfig'
(In reply to Joseph Pesco from comment #12)
> I believe it is Mr. Volny with the problem hardware;
Mr. Volný doesn't own that AP, please be patient until I'll get to its vicinity again, then I'll do more testing
Guys this appears to be close a duplicate of BZ 989269. The chip vendor is working to gather info for a fix: some patches there might help you gather info for them to fix. Check this out:
Created attachment 786754 [details]
hostname: sunbird, config file
fyi, custom kernel built from the config attached and is unaltered from the srpm still panics. My destination is to obtain a crash log, though now not till after looking into 989269 in more deatail.
After installing and booting with kernel-PAE-3.10.9-200.fc19.i686.rpm oops is no longer an issue. (Thanks!)
*** This bug has been marked as a duplicate of bug 989269 ***