Bug#664767: Brcmsmac driver woes, possible regression?
On 03/23/2013 04:28 PM, Camaleón wrote: 2013/3/19 Camaleón noela...@gmail.com: Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Update: applied the patch to revert the other patch but I still cannot get the driver to work (see attached syslog). N-M still asks for password until desists :-( More verbose logs, just in case someone finds something of interest. Greetings, What I see in this log is that your AP keeps sending EAPOL message 1 and you keep sending EAPOL message 2 until one gives up the attempts. This behaviour would suggest the psk is wrong as indicated in the log, but you said you could connect using another card, right? So using the same configured N-M connection? Regards, Arend -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote: 2013/3/19 Camaleón noela...@gmail.com: 2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Update: applied the patch to revert the other patch but I still cannot get the driver to work (see attached syslog). N-M still asks for password until desists :-( Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote: 2013/3/19 Camaleón noela...@gmail.com: 2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Update: applied the patch to revert the other patch but I still cannot get the driver to work (see attached syslog). N-M still asks for password until desists :-( Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote: El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote: 2013/3/19 Camaleón noela...@gmail.com: 2013/3/18 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug Perfect, thanks. root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware board vendor: 103c board type: 145c board revision: 2209 board flags: 8002a00 board flags2: 800 firmware revision: 262032b Now let's see how reverting the patch makes any difference as soon as I can compile the module. I will keep you updated Update: applied the patch to revert the other patch but I still cannot get the driver to work (see attached syslog). N-M still asks for password until desists :-( Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2013-03-19 a las 12:59 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote: El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Oops! Okay, so what user inputs is not bullet-proof. Anyway, this does not seem to be a problem of bad password. I was finally able to get connected to the AP as soon as I carry the nebook and put it next to the AP which is the problem I've always have had with this driver (brcmsmac). As soon as I back to another room, N-M asks me again for the pass-key and disconnects. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 19:11 +0100, Camaleón wrote: El 2013-03-19 a las 12:59 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote: El 2013-03-19 a las 11:53 -0500, Dan Williams escribió: Note that NM 0.9.8 won't ask for a password when just anything fails, but will ask for a password if the 4-way handshake fails, because if that fails, it's probably your password. We're contemplating getting rid of that too, and just notifying the user that their password may be wrong and that they should go update it in the network configuration panel so we don't interrupt. But if you're 100% sure your PSK is correct, then it is, most likely, a driver bug. Password is correct. I have a second wireless card (external, using rt2800usb driver) that connects without a glitch to the same AP. Moreover, unless I type the right password, N-M dialog does not allow me to click on the Connect button. NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Oops! Okay, so what user inputs is not bullet-proof. Anyway, this does not seem to be a problem of bad password. I was finally able to get connected to the AP as soon as I carry the nebook and put it next to the AP which is the problem I've always have had with this driver (brcmsmac). Yeah, that's a symptom of bad power control or bad gain or who knows what in the driver. But also, make sure your antennas are connected correctly :) As soon as I back to another room, N-M asks me again for the pass-key and disconnects. NM 0.9.8 shouldn't do that; I bet you're not even getting to the point where the 4-way handshake and password verification are done. NM 0.9.8 will retry a few times, notify you and fail, then wait a couple minutes and try again. It shouldn't ask for a password anymore in situations like this. Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2013-03-19 a las 13:16 -0500, Dan Williams escribió: On Tue, 2013-03-19 at 19:11 +0100, Camaleón wrote: (...) NM minimally verifies the PSK, which by 802.11 standards is between 8 and 63 ASCII characters inclusive. So you should be able to type anything you want within those constraints, but clearly only one is your real PSK. Oops! Okay, so what user inputs is not bullet-proof. Anyway, this does not seem to be a problem of bad password. I was finally able to get connected to the AP as soon as I carry the nebook and put it next to the AP which is the problem I've always have had with this driver (brcmsmac). Yeah, that's a symptom of bad power control or bad gain or who knows what in the driver. But also, make sure your antennas are connected correctly :) I'm starting to think the embedded wireless adapter could have been damaged somehow. The fact is that the card worked fine until kernel 2.6.38 (IIRC), but afterwards... well, I had to connect an additional USB card. As soon as I back to another room, N-M asks me again for the pass-key and disconnects. NM 0.9.8 shouldn't do that; I bet you're not even getting to the point where the 4-way handshake and password verification are done. NM 0.9.8 will retry a few times, notify you and fail, then wait a couple minutes and try again. It shouldn't ask for a password anymore in situations like this. Debian Wheezy still has 0.9.4 but well, that's a minor issue ;-( Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On 03/19/2013 05:21 PM, Camaleón wrote: Mar 19 17:05:28 stt300 kernel: [26034.188562] wlan0: authenticated Mar 19 17:05:28 stt300 kernel: [26034.192108] wlan0: associate with 00:1a:2b:97:7a:97 (try 1/3) Mar 19 17:05:28 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: authenticating - associating Mar 19 17:05:30 stt300 kernel: [26036.586947] wlan0: RX AssocResp from 00:1a:2b:97:7a:97 (capab=0x411 status=0 aid=1) Mar 19 17:05:30 stt300 kernel: [26036.587560] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated Mar 19 17:05:30 stt300 kernel: [26036.587576] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) Mar 19 17:05:30 stt300 kernel: [26036.587603] wlan0: associated Mar 19 17:05:30 stt300 kernel: [26036.587698] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Mar 19 17:05:30 stt300 wpa_supplicant[2855]: wlan0: Associated with 00:1a:2b:97:7a:97 Seems to be heading in the right direction, but Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associating - associated Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associated - 4-way handshake Mar 19 17:05:32 stt300 avahi-daemon[2630]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::ae81:12ff:fe34:6963. Mar 19 17:05:32 stt300 avahi-daemon[2630]: New relevant interface wlan0.IPv6 for mDNS. Mar 19 17:05:32 stt300 avahi-daemon[2630]: Registering new address record for fe80::ae81:12ff:fe34:6963 on wlan0.*. Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): association took too long. Here it seem to go bad again... Mar 19 17:05:32 stt300 NetworkManager[30971]: info (wlan0): device state change: config - need-auth (reason 'none') [50 60 0] Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): asking for new secrets Mar 19 17:05:32 stt300 kernel: [26039.005158] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3) And we get a deauth request with WLAN_REASON_DEAUTH_LEAVING. Mar 19 17:05:33 stt300 kernel: [26040.004150] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated Mar 19 17:05:33 stt300 kernel: [26040.004172] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) Mar 19 17:05:34 stt300 kernel: [26040.504402] cfg80211: Calling CRDA to update world regulatory domain Mar 19 17:05:34 stt300 ntpd[2611]: Listen normally on 16 wlan0 fe80::ae81:12ff:fe34:6963 UDP 123 Mar 19 17:05:34 stt300 ntpd[2611]: peers refreshed Mar 19 17:05:34 stt300 wpa_supplicant[2855]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 Mar 19 17:05:34 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: 4-way handshake - disconnected Mar 19 17:05:34 stt300 NetworkManager[30971]: warn Couldn't disconnect supplicant interface: This interface is not connected. I am trying to make sense of it, but it is getting late over here. Have a fresh look tomorrow. Regards, Arend -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Tue, 2013-03-19 at 22:55 +0100, Arend van Spriel wrote: On 03/19/2013 05:21 PM, Camaleón wrote: Mar 19 17:05:28 stt300 kernel: [26034.188562] wlan0: authenticated Mar 19 17:05:28 stt300 kernel: [26034.192108] wlan0: associate with 00:1a:2b:97:7a:97 (try 1/3) Mar 19 17:05:28 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: authenticating - associating Mar 19 17:05:30 stt300 kernel: [26036.586947] wlan0: RX AssocResp from 00:1a:2b:97:7a:97 (capab=0x411 status=0 aid=1) Mar 19 17:05:30 stt300 kernel: [26036.587560] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated Mar 19 17:05:30 stt300 kernel: [26036.587576] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) Mar 19 17:05:30 stt300 kernel: [26036.587603] wlan0: associated Mar 19 17:05:30 stt300 kernel: [26036.587698] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Mar 19 17:05:30 stt300 wpa_supplicant[2855]: wlan0: Associated with 00:1a:2b:97:7a:97 Seems to be heading in the right direction, but Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associating - associated Mar 19 17:05:30 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: associated - 4-way handshake Mar 19 17:05:32 stt300 avahi-daemon[2630]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::ae81:12ff:fe34:6963. Mar 19 17:05:32 stt300 avahi-daemon[2630]: New relevant interface wlan0.IPv6 for mDNS. Mar 19 17:05:32 stt300 avahi-daemon[2630]: Registering new address record for fe80::ae81:12ff:fe34:6963 on wlan0.*. Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): association took too long. Here it seem to go bad again... Mar 19 17:05:32 stt300 NetworkManager[30971]: info (wlan0): device state change: config - need-auth (reason 'none') [50 60 0] Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): asking for new secrets Mar 19 17:05:32 stt300 kernel: [26039.005158] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3) And we get a deauth request with WLAN_REASON_DEAUTH_LEAVING. That local choice (reason=3) is NetworkManager terminating the association attempt because it already took 25 seconds, which is way too long for a simple association. The cause is long before that. NM tells the supplicant to start associating here: Mar 19 17:05:07 stt300 NetworkManager[30971]: info Config: set interface ap_scan to 1 and finally kills the attempt here: Mar 19 17:05:32 stt300 NetworkManager[30971]: warn Activation (wlan0/wireless): association took too long. So the supplicant gets a total of 25 seconds to associate to the AP, which, if you're not associated within that time, you're definitely not going to get associated if you're given more time. But between 17:05:07 and 17:05:32, NM is just waiting for the association to succeed. It really does look like the supplicant or driver tries to associate but then fails, eg: Mar 19 17:05:08 stt300 kernel: [26014.833011] wlan0: send auth to 00:1a:2b:97:7a:97 (try 1/3) Mar 19 17:05:13 stt300 kernel: [26019.834259] wlan0: deauthenticating from 00:1a:2b:97:7a:97 by local choice (reason=3) There's a whole lot of authentication/association failures in that log, which do appear to indicate that the STA can see the AP, but the AP can't hear the STA. Then we also have stuff like: Mar 19 17:05:24 stt300 wpa_supplicant[2855]: wlan0: SME: Authentication request to the driver failed where it would be nice to know why the request failed. Dan Mar 19 17:05:33 stt300 kernel: [26040.004150] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated Mar 19 17:05:33 stt300 kernel: [26040.004172] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) Mar 19 17:05:34 stt300 kernel: [26040.504402] cfg80211: Calling CRDA to update world regulatory domain Mar 19 17:05:34 stt300 ntpd[2611]: Listen normally on 16 wlan0 fe80::ae81:12ff:fe34:6963 UDP 123 Mar 19 17:05:34 stt300 ntpd[2611]: peers refreshed Mar 19 17:05:34 stt300 wpa_supplicant[2855]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 Mar 19 17:05:34 stt300 NetworkManager[30971]: info (wlan0): supplicant interface state: 4-way handshake - disconnected Mar 19 17:05:34 stt300 NetworkManager[30971]: warn Couldn't disconnect supplicant interface: This interface is not connected. I am trying to make sense of it, but it is getting late over here. Have a fresh look tomorrow. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble?
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote[1]: vermagic: 3.9.0-rc2 SMP mod_unload modversions 686 As soon as I load the brcmsmac module, N-M pop-ups and asks for the secrets... constantly until it quits, that is, I cannot even connect to the wifi AP with the Broadcom card, it's a bit frustrating :-( (attaching full dmesg and syslog files) Thanks. I also downloaded Debian experimental kernel sources (3.8.2), do you want me to compile and test this? I see no reason to do that. Hm. Jonathan [1] http://bugs.debian.org/664767 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On 03/18/2013 09:37 AM, Jonathan Nieder wrote: Camaleón wrote[1]: vermagic: 3.9.0-rc2 SMP mod_unload modversions 686 As soon as I load the brcmsmac module, N-M pop-ups and asks for the secrets... constantly until it quits, that is, I cannot even connect to the wifi AP with the Broadcom card, it's a bit frustrating :-( Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware The regression was caused by following commit: brcmsmac: support 4313iPA b6fc28a158076ca2764edc9a6d1e1402f56e1c0c If possible you can revert that and see how that goes. Regards, Arend Thanks. I also downloaded Debian experimental kernel sources (3.8.2), do you want me to compile and test this? I see no reason to do that. Hm. Jonathan [1] http://bugs.debian.org/664767 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: On 03/18/2013 09:37 AM, Jonathan Nieder wrote: Camaleón wrote[1]: vermagic: 3.9.0-rc2 SMP mod_unload modversions 686 As soon as I load the brcmsmac module, N-M pop-ups and asks for the secrets... constantly until it quits, that is, I cannot even connect to the wifi AP with the Broadcom card, it's a bit frustrating :-( Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty so now that I'm going to recompile the whole kernel again to revert the patch, is there any flag I need to turn on at the .config file to enable the debug for brcmsmac or any additional flag it could be interesting for this? The regression was caused by following commit: brcmsmac: support 4313iPA b6fc28a158076ca2764edc9a6d1e1402f56e1c0c If possible you can revert that and see how that goes. It will cost me a bunch of dislikes ;-) but sure, I'll try and report back. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió: Sorry to hear. Reading back the bug report I noticed you are having a bcm4313 and we recently had a regression on it. Could you provide debugfs information from debugfs_mount/brcmsmac/bcma0:0/hardware I see. My /sys/kernel/debug/* directory is empty mount -t debugfs debugfs /sys/kernel/debug -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-07-28 a las 13:49 -0500, Jonathan Nieder escribió: Camaleón wrote: 2012/7/25 Jonathan Nieder jrnie...@gmail.com: Hmm. What happens if you try all 23 together again? Compiled today with all the patches and it happens that I get the usual reconnects... I'm completely baffled. Thanks for the quick feedback. If you don't authenticate with network-manager quickly enough, does gnome-shell still crash? Curious, Jonathan Yes, indeed, gnome-shell crashes when I delay too much (~10 minutes or so) the password input (in this last log the crash is not present but it segfaulted afterwards). That's something I always have found curious: when wireless reconnects, I first get one pop-up window (light grey colored, old GNOME style) for the password. If I leave it as is (do not press Accept nor Cancel for a while), I get a second pop-up over the current one (black window with rounded corners) and if the delay was noticeable, or even if I click on the Cancel button, gnome-shell waves (crashes) and the session is automatically restored. But maybe this is something for a different bug report against N-M :-? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: 2012/7/25 Jonathan Nieder jrnie...@gmail.com: Hmm. What happens if you try all 23 together again? Compiled today with all the patches and it happens that I get the usual reconnects... I'm completely baffled. Thanks for the quick feedback. If you don't authenticate with network-manager quickly enough, does gnome-shell still crash? Curious, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: 2012/7/23 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: I compiled the kernel today with the 22 patches and today got this: Neat. Ok, we're almost done. Could you try the attached patch (patch 23) without the others against 3.2.y? If it works, I'll submit patches 22 and 23 to stable@ for inclusion in the 3.2.y tree. Patch 23 seems to be of no help at all, wireless is compelety unstable... I get reconnects every 5 minutes or less :-( (attaching syslog with kernel 3.2.21 with just patch 23 applied) Hmm. What happens if you try all 23 together again? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote:
I compiled the kernel today with the 22 patches and today got this:
Neat. Ok, we're almost done. Could you try the attached patch (patch
23) without the others against 3.2.y?
If it works, I'll submit patches 22 and 23 to stable@ for inclusion
in the 3.2.y tree.
Thanks,
Jonathan
From: Arend van Spriel ar...@broadcom.com
Date: Wed, 11 Apr 2012 11:52:50 +0200
Subject: brcm80211: smac: only provide valid regulatory hint
commit 94a2ca311cf4154c566cf5c49b88c13cd4cdce73 upstream.
The driver provides a regulatory hint to cfg80211 as obtained from the
SPROM. Mostly, this will be a two-letter ISO country code. However, it
may obtain special country code similar to the world regulatory domain
as used in cfg80211. This patch avoids setting these special codes as
the hint is lost to cfg80211.
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Reviewed-by: Brett Rudley brud...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 36 -
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/channel.c
b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
index 89ad1b7dab8f..7fc2db32dc41 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/channel.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
@@ -628,6 +628,40 @@ brcms_c_country_aggregate_map(struct brcms_cm_info
*wlc_cm, const char *ccode,
return false;
}
+/*
+ * Indicates whether the country provided is valid to pass
+ * to cfg80211 or not.
+ *
+ * returns true if valid; false if not.
+ */
+static bool brcms_c_country_valid(const char *ccode)
+{
+ /*
+* only allow ascii alpha uppercase for the first 2
+* chars.
+*/
+ if (!((0x80 ccode[0]) == 0 ccode[0] = 0x41 ccode[0] = 0x5A
+ (0x80 ccode[1]) == 0 ccode[1] = 0x41 ccode[1] = 0x5A
+ ccode[2] == '\0'))
+ return false;
+
+ /*
+* do not match ISO 3166-1 user assigned country codes
+* that may be in the driver table
+*/
+ if (!strcmp(AA, ccode) ||/* AA */
+ !strcmp(ZZ, ccode) ||/* ZZ */
+ ccode[0] == 'X' || /* XA - XZ */
+ (ccode[0] == 'Q' /* QM - QZ */
+(ccode[1] = 'M' ccode[1] = 'Z')))
+ return false;
+
+ if (!strcmp(NA, ccode))
+ return false;
+
+ return true;
+}
+
/* Lookup a country info structure from a null terminated country
* abbreviation and regrev directly with no translation.
*/
@@ -1089,7 +1123,7 @@ struct brcms_cm_info *brcms_c_channel_mgr_attach(struct
brcms_c_info *wlc)
/* store the country code for passing up as a regulatory hint */
ccode = getvar(wlc-hw-sih, BRCMS_SROM_CCODE);
- if (ccode)
+ if (ccode brcms_c_country_valid(ccode))
strncpy(wlc-pub-srom_ccode, ccode, BRCM_CNTRY_BUF_SZ - 1);
/*
--
1.7.10.4
Bug#664767: Brcmsmac driver woes, possible regression?
2012/7/8 Jonathan Nieder jrnie...@gmail.com: Could you try with patches 1-19? (Patches 18, 19, 22, and 23 seem potentially interesting.) Sorry for the delay... I've tried kernel 3.2.21 with patches 1 to 19 but I get random reconnects in just one day: hpc03@stt300:~$ dmesg | grep -i associated [ 90.937628] wlan0: associated [ 90.939453] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated [ 215.076524] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 224.752735] wlan0: associated [ 224.755533] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated [ 295.081454] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 298.699733] wlan0: associated [ 298.701335] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated [ 448.597002] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 452.218052] wlan0: associated [ 452.219079] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated [ 2251.604460] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 2253.556536] wlan0: associated [ 2253.557907] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated [ 2434.845459] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 2438.515550] wlan0: associated [ 2438.517259] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated [ 2494.548459] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: disassociated [ 2594.547477] wlan0: associated [ 2594.549072] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated Moreover, if I delay the data input when N-M asks me for the AP password, gnome-shell starts segfaulting :-( Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: Sorry for the delay... I've tried kernel 3.2.21 with patches 1 to 19 but I get random reconnects in just one day: [...] Moreover, if I delay the data input when N-M asks me for the AP password, gnome-shell starts segfaulting :-( Thank you. Next combination to try when you have time is 1-22. Many thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/7/7 Camaleón noela...@gmail.com: A quick follow-up... now running kernel 3.2.21 with the first 17 patches applied. Let's see how it goes (will comment on the next days) and thanks Jonathan for (still!) hanging in there. I got lots of disconnects today (in only one day using kernel 3.2.21+17 patches), so maybe this is relevant (kernel with all the patches was running quite stable for at least 7 days...). The next logs are from today (when N-M asked me for secrets all over again) but the AP password is saved in NM, I can see it from the applet: ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. ** Message: No keyring secrets found for WLAN_B5/802-11-wireless-security; asking user. x-session-manager[2180]: WARNING: Application 'gnome-shell.desktop' killed by signal 11 And also from today, gnome-shell is crashing again when I am disconnected: hpc03@stt300:~$ dmesg | grep -i segfault [24567.870238] gnome-shell[2642]: segfault at 20 ip b76b7dab sp bfb1d5e0 error 4 in libgnome-shell.so[b7679000+9d000] [24658.649384] mail-notificati[2655]: segfault at 4c ip 08060203 sp bf8b7c00 error 4 in mail-notification[8048000+5c000] It seems the key patches are from 18 to 23 (remember I'm using ES for the regulatory domain) :-? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: It seems the key patches are from 18 to 23 (remember I'm using ES for the regulatory domain) :-? Yep. Could you try with patches 1-19? (Patches 18, 19, 22, and 23 seem potentially interesting.) Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/7/6 Jonathan Nieder jrnie...@gmail.com: I'll let Arend et al know, and maybe they will have ideas for future useful tests. In the meantime, let's brute-force this. :) How does 3.2.y + patches 1-17 do? A quick follow-up... now running kernel 3.2.21 with the first 17 patches applied. Let's see how it goes (will comment on the next days) and thanks Jonathan for (still!) hanging in there. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-06-25 a las 15:13 -0500, Jonathan Nieder escribió: Camaleón wrote: I'm afraid I'm getting the old well-known random disconects again (with gnome-shell segfaulting when this happens) ;-( Applied the ten first patches, compiled 3.2.21-1 from Debian sources and... well, I'm attaching log. Thanks. Could you try 3.2.21 + all 23 patches again? Sorry for the delay. 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, but when that happened gnome-shell was not segfaulting at least...). 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. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: El 2012-06-25 a las 15:13 -0500, Jonathan Nieder escribió: Thanks. Could you try 3.2.21 + all 23 patches again? Sorry for the delay. 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, but when that happened gnome-shell was not segfaulting at least...). Thanks for the details --- very useful. I'll let Arend et al know, and maybe they will have ideas for future useful tests. In the meantime, let's brute-force this. :) How does 3.2.y + patches 1-17 do? Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: I'm afraid I'm getting the old well-known random disconects again (with gnome-shell segfaulting when this happens) ;-( Applied the ten first patches, compiled 3.2.21-1 from Debian sources and... well, I'm attaching log. Thanks. Could you try 3.2.21 + all 23 patches again? I can try Arend's suggestion of setting US for the CRDA instead ES :-? This would be interesting, too (as an independent test). Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: 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. This is with the 3.2.2-1 kernel. Does switching to a newer kernel avoid this kind of trouble? If so, does switching back bring the trouble back again? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-06-23 a las 12:05 -0500, Jonathan Nieder escribió: Camaleón wrote: 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. This is with the 3.2.2-1 kernel. Does switching to a newer kernel avoid this kind of trouble? If so, does switching back bring the trouble back again? I noticed there was a new kernel update but as I was centered in this bug report I had configured GRUB to directly boot the older kernel. I'm going to leave the system for a while with the new kernel loaded to see what problem hits (if any)... Gee, I'm about to lose all my hair with this -:-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: El 2012-06-23 a las 12:05 -0500, Jonathan Nieder escribió: Camaleón wrote: 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. This is with the 3.2.2-1 kernel. Does switching to a newer kernel avoid this kind of trouble? If so, does switching back bring the trouble back again? I noticed there was a new kernel update but as I was centered in this bug report I had configured GRUB to directly boot the older kernel. I'm going to leave the system for a while with the new kernel loaded to see what problem hits (if any)... Ah, so the reconects do not happen often enough to tell immediately whether switching kernels caused relief? We need a program to automatically create histograms with number of occurences per day, per hour, and per minute for intermittent bugs like this one. :) The new data from this last observation is that 3.2.2-1 is capable of producing random reconnects and instability, just like the newer kernels. So the mystery of the 3.2.2 - 3.2.9 regression has been dispelled. I don't expect 3.2.21-1 to be any different from, say, 3.2.18-1, so I don't think it's worth spending much time with it loaded unless there's no better test to run. I can suggest a kernel if you'd like, or if you want to use whichever has worked best in the past (3.4.y?) until we haved spent a little more time mulling over the data you've already provided, that's fine with me, too. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-06-23 a las 12:23 -0500, Jonathan Nieder escribió: Camaleón wrote: I noticed there was a new kernel update but as I was centered in this bug report I had configured GRUB to directly boot the older kernel. I'm going to leave the system for a while with the new kernel loaded to see what problem hits (if any)... Ah, so the reconects do not happen often enough to tell immediately whether switching kernels caused relief? We need a program to automatically create histograms with number of occurences per day, per hour, and per minute for intermittent bugs like this one. :) I wish there's such a tool :-P Well, the latest kernel 3.2.20-1 runs more stable (only one reconnect since it was loaded a few hours ago), I mean, now more crazy crashes like the above. The new data from this last observation is that 3.2.2-1 is capable of producing random reconnects and instability, just like the newer kernels. So the mystery of the 3.2.2 - 3.2.9 regression has been dispelled. The kernel 3.2.2-1 craziness started a day ago, it was running nicely, but well, you're right, whatever happened in the meantime reproduced -very agressively- the issue again which translates into the problem was still there :-( I don't expect 3.2.21-1 to be any different from, say, 3.2.18-1, so I don't think it's worth spending much time with it loaded unless there's no better test to run. I can suggest a kernel if you'd like, or if you want to use whichever has worked best in the past (3.4.y?) until we haved spent a little more time mulling over the data you've already provided, that's fine with me, too. I'll keep testing brcmsmac with the upstream branch (mainline and unstable) so yes, if you have a kernel in your radar you think I could try just tell and I'll go with it. Anyway, it's a good signal that there are no more users added to this bug report, mine has to be a very corner (though annoying) case. Gretings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote:
I'll keep testing brcmsmac with the upstream branch (mainline and
unstable) so yes, if you have a kernel in your radar you think I
could try just tell and I'll go with it.
Ok, cool. Here's my favorite kernel for the moment:
v3.2.21 + patches 1-10 from http://bugs.debian.org/664767#99
This would help us check Arend's hunch that patches mentioning 'mute'
could have taken care of it.
Instructions for building:
# get kernel history if you don't already have it:
git clone git://...
# fetch latest point releases:
git remote add stable \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable
# check out 3.2.21:
git checkout stable/linux-3.2.y
git reset --hard
git am -3sc $(ls -1 /path/to/patches/00{0[1-9],10}-*)
# configure:
make silentoldconfig
scripts/config --disable DEBUG_INFO
make localmodconfig; # optional: minimize configuration
# build, test:
make deb-pkg; # optionally with -jnum for parallel build
dpkg -i ../name of package; # as root
reboot
Hope that helps,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/6/11 Camaleón noela...@gmail.com: Mmmm, this is something I can still try (an earlier working kernel). As per my comment #167 [1], candidates could be lower versions starting from 3.2.4-1, which according to the snapshot [2] could be: 3.2.2-1 (source: linux-2.6 3.2.2-1) 3.2.1-2 (source: linux-2.6 3.2.1-2) 3.2.1-1 (source: linux-2.6 3.2.1-1) Will do on these these -time permitting- and report here. 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. Not sure if this can be of any help because of the brief testing time-frame but I used to get a reconnect once a day with the other kernels I've been trying... Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
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.
How about this patch, for 3.2.y kernels? I suggest the following
steps for testing:
0. prerequisites:
apt-get install git build-essential
1. get the kernel history, if you do not already have it:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
2. add point releases:
cd linux
git remote add stable \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable
3. configure, build, test:
git checkout stable/linux-3.2.y
cp /boot/config-$(uname -r) .config; # current configuration
scripts/config --disable DEBUG_INFO
make localmodconfig; # optional: minimize configuration
make deb-pkg; # optionally with -jnum for parallel build
dpkg -i ../name of package; # as root
reboot
... test test test ...
Hopefully it reproduces the disconnection. So
4. try the patch:
cd linux
git revert f96b08a7e6f6
make deb-pkg; # maybe with -j4
dpkg -i ../name of package; # as root
reboot
... test test test ...
From: Jonathan Nieder jrnie...@gmail.com
Date: Tue, 19 Jun 2012 12:57:27 -0500
Subject: Revert brcmsmac: fix tx queue flush infinite loop
This reverts commit f96b08a7e6f69c0f0a576554df3df5b1b519c479.
Just testing something, nothing deeper to see here.
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c
b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 833cbefcbfd2..364200cfb21c 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -8225,21 +8225,13 @@ int brcms_c_get_curband(struct brcms_c_info *wlc)
void brcms_c_wait_for_tx_completion(struct brcms_c_info *wlc, bool drop)
{
- int timeout = 20;
-
/* flush packet queue when requested */
if (drop)
brcmu_pktq_flush(wlc-pkt_queue-q, false, NULL, NULL);
/* wait for queue and DMA fifos to run dry */
- while (!pktq_empty(wlc-pkt_queue-q) || brcms_txpktpendtot(wlc) 0) {
+ while (!pktq_empty(wlc-pkt_queue-q) || brcms_txpktpendtot(wlc) 0)
brcms_msleep(wlc-wl, 1);
-
- if (--timeout == 0)
- break;
- }
-
- WARN_ON_ONCE(timeout == 0);
}
void brcms_c_set_beacon_listen_interval(struct brcms_c_info *wlc, u8 interval)
--
1.7.11.rc3
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-06-10 a las 17:49 -0500, Jonathan Nieder escribió: This kernel was running fine the whole Saturday but today I had another reconnect (network-manager asked for the password which I had to reconfirm). I'm attaching the full syslog for this pacthed kernel. The reconnect happened at night (22:00 or so). Thanks. You first reported this against 3.2.9-1. Were you using some earlier 3.2.y kernel without trouble before? Mmmm, this is something I can still try (an earlier working kernel). As per my comment #167 [1], candidates could be lower versions starting from 3.2.4-1, which according to the snapshot [2] could be: 3.2.2-1 (source: linux-2.6 3.2.2-1) 3.2.1-2 (source: linux-2.6 3.2.1-2) 3.2.1-1 (source: linux-2.6 3.2.1-1) Will do on these these -time permitting- and report here. Thanks for reminding me this second line of investigation :-) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664767#167 [2] http://snapshot.debian.org/binary/linux-image-3.2.0-1-686-pae/ Gretings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
found 664767 linux-2.6/3.2.19-1 quit Camaleón wrote: Yes. What I get is the Network Manager window requesting for the password confirm, randomly. If I delay the password confirmation, the wireless connection drops. [...] I downloaded sid kernel sources for 3.2.19, applied the first of the patches (0001-brcm80211-smac-drop-40MHz-intolerant-flag-from-HT-ca.patch and build a new deb kernel package. [...] This kernel was running fine the whole Saturday but today I had another reconnect (network-manager asked for the password which I had to reconfirm). I'm attaching the full syslog for this pacthed kernel. The reconnect happened at night (22:00 or so). Thanks. You first reported this against 3.2.9-1. Were you using some earlier 3.2.y kernel without trouble before? Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
forwarded 664767 http://thread.gmane.org/gmane.linux.kernel.wireless.general/92452 quit Camaleón wrote: I downloaded sid kernel sources for 3.2.19, applied the first of the patches (0001-brcm80211-smac-drop-40MHz-intolerant-flag-from-HT-ca.patch and build a new deb kernel package. [...] This kernel was running fine the whole Saturday but today I had another reconnect (network-manager asked for the password which I had to reconfirm). I'm attaching the full syslog for this pacthed kernel. The reconnect happened at night (22:00 or so). Nicely done. Let's take this upstream again. Thanks for your patience, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Sun, Jun 03, 2012 at 02:21:28PM +0200, Camaleón wrote: 2012/6/1 Camaleón noela...@gmail.com: OTOH, I will try to reproduce the instability state with 3.2.16-1 over the weekend and will comment the results here. Okay, I'm afraid the problem is still present in kernel 3.2.17-1 :-( Wireless was stable when I tested because I had loaded wl driver instead (I completely forgot about that), once I changed to brcmsmac I got a disconnect after 3-4 hours... Sorry for the noise. Anyway, if applying all the patches is not possible I can run individual tests to cherry-pick some of them but as Jonathan pointed I'll need some guidance to make the tryouts. It would be good if you tried Debian kernel 3.2.18-1 (or newer). It has endless retry of A-MPDU transmissions patch in brcmsmac. Maybe it makes some difference. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-06-04 a las 11:42 +0300, Touko Korpela escribió: It would be good if you tried Debian kernel 3.2.18-1 (or newer). It has endless retry of A-MPDU transmissions patch in brcmsmac. Maybe it makes some difference. I already have that kernel (3.2.18-1) installed and fails. I can try with sid's kernel (3.2.19-1) but I don't think there's going to be a significant change. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
found 664767 linux-2.6/3.2.18-1
quit
Camaleón wrote:
I already have that kernel (3.2.18-1) installed and fails.
Marking so. I assume this means it produces the unwanted connection
resets.
Could you try with just the first patch ('drop 40MHz intolerant
flag') from the series sent before? (Trying one patch at a time would
normally be a pretty wasteful strategy, but in this case the first one
is one of the most interesting.)
Thanks again for your help and patience.
yours,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/6/1 Camaleón noela...@gmail.com: OTOH, I will try to reproduce the instability state with 3.2.16-1 over the weekend and will comment the results here. Okay, I'm afraid the problem is still present in kernel 3.2.17-1 :-( Wireless was stable when I tested because I had loaded wl driver instead (I completely forgot about that), once I changed to brcmsmac I got a disconnect after 3-4 hours... Sorry for the noise. Anyway, if applying all the patches is not possible I can run individual tests to cherry-pick some of them but as Jonathan pointed I'll need some guidance to make the tryouts. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/5/30 Jonathan Nieder jrnie...@gmail.com: Anyway, after having loaded kernel 3.2.19 (with the set of patches applied) for all the weekend and until today, I've experienced NO reconnects nor random connection downs which means the wireless link runs stable and at least it's usable here :-) Nice. Let's call that a success. Kernel team: here is a list of the patches[*] Camaleón applied: (...) I'd like to add a comment because I think it can be relevant... since the latest stock kernel update (3.2.18-1) a couple of days ago coming from the usual wheezy set of upgrades (I mean, with no additional patches applied) brcmsmac driver seems to run also stable with no disconnects... I don't know how to interpret it but looks like a good news because it means that no additional patches are needed. I will keep an eye on this new kernel update and as always, I'm open to run any further tests that you may require. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: I'd like to add a comment because I think it can be relevant... since the latest stock kernel update (3.2.18-1) a couple of days ago coming from the usual wheezy set of upgrades (I mean, with no additional patches applied) brcmsmac driver seems to run also stable with no disconnects... That's nice to hear. What kernel were you using before then? (3.3? 3.2.12-1?) Does 3.2.16-1 from snapshot.debian.org reproduce the problem easily? I guess what would be most useful is a list of kernel version you tried, the result with each, and how long you tried it. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-06-01 a las 12:42 -0500, Jonathan Nieder escribió: Camaleón wrote: I'd like to add a comment because I think it can be relevant... since the latest stock kernel update (3.2.18-1) a couple of days ago coming from the usual wheezy set of upgrades (I mean, with no additional patches applied) brcmsmac driver seems to run also stable with no disconnects... That's nice to hear. What kernel were you using before then? (3.3? 3.2.12-1?) Does 3.2.16-1 from snapshot.debian.org reproduce the problem easily? I guess what would be most useful is a list of kernel version you tried, the result with each, and how long you tried it. According to dpkg log it was (most recent come first): 3.2.17-1 3.2.16-1 3.2.15-1 3.2.14-1 3.2.12-1 3.2.9-1 -- this bug report (...possible regression?) starts here 3.2.6-1 3.2.4-1 All of those failed to run brcmamsc in a stable state. The last time I checked and still was failing it was with kernel 3.2.17-1 (by that time I had to start using wl driver instead). OTOH, I will try to reproduce the instability state with 3.2.16-1 over the weekend and will comment the results here. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/5/27 Jonathan Nieder jrnie...@gmail.com: Thanks. I assume you mean the brcms_c_wait_... warning when you refer to an oops. Separating the symptoms: brcms_c_wait_for_tx_completion warning: bug#672891 connection resets, segfaults, general instability: bug#664767 (this bug) AMPDU status: BA Timeout: bug#674430 (...) Yup, that can be. Anyway, after having loaded kernel 3.2.19 (with the set of patches applied) for all the weekend and until today, I've experienced NO reconnects nor random connection downs which means the wireless link runs stable and at least it's usable here :-) Is there any chance for these patches hit wheezy when is relased or get into testing? I've just read Ben's announcement about the availabilty of 3.2.19-1 kernel in a few days and having these patches would improve things a lot for users experincining these issues or similar problems with brcmsmac. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
found 664767 linux-2.6/3.2.12-1 tags 664767 - moreinfo quit Camaleón wrote: Anyway, after having loaded kernel 3.2.19 (with the set of patches applied) for all the weekend and until today, I've experienced NO reconnects nor random connection downs which means the wireless link runs stable and at least it's usable here :-) Nice. Let's call that a success. Kernel team: here is a list of the patches[*] Camaleón applied: 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 It's not clear to me which of these addresses the memory corruption and random reconnects Camaleón was experiencing. I think we should take them all. (It's basically a backport of brcmsmac changes to date, minus the switch to BCMA.) Commit 2b0a53d51b5f (only print block-ack timeout message at trace level) addresses the distracting log noise from bug#674430. Commits c261bdf8acad (reset mac80211 too when resetting) and 2646c46d5679 (disable rx on ops_stop) sound useful but their descriptions don't mention the symptoms. 8906c43cb160 (fix channel 216 frequency) and 1570e53c14ff (don't treat 2057 radio rev 5 like rev 7) also look like obviously good fixes. Likewise for 137dabed34a1 (avoid NULL pointer dereference, especially when memory is short) though it wouldn't have caused Camaleón's trouble. Commits 6b1a89afbf97 (drop 40MHz intolerant flag from HT capability info), 6b8da423315b (do not use US as fallback regulatory hint), and 94a2ca311cf4 (only pass valid regulatory hints to cfg80211) affect the channel used and might explain why the connection is more stable. Thanks, Jonathan [*] http://bugs.debian.org/664767#99 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Wed, 2012-05-30 at 12:27 -0500, Jonathan Nieder wrote: found 664767 linux-2.6/3.2.12-1 tags 664767 - moreinfo quit Camaleón wrote: Anyway, after having loaded kernel 3.2.19 (with the set of patches applied) for all the weekend and until today, I've experienced NO reconnects nor random connection downs which means the wireless link runs stable and at least it's usable here :-) Nice. Let's call that a success. Kernel team: here is a list of the patches[*] Camaleón applied: 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 It's not clear to me which of these addresses the memory corruption and random reconnects Camaleón was experiencing. I think we should take them all. (It's basically a backport of brcmsmac changes to date, minus the switch to BCMA.) [...] I'm sorry but I don't agree. This would seem to leave us with a version of brcmsmac that's quite different from what anyone else uses. Please try to identify which of these are the really important changes and propose them for stable. (It may however be sensible to use the 'compat-wireless' tree as a means to keep wireless drivers updated in wheezy. I keep meaning to look into the details of this and then discuss it with the kernel and release teams.) Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#664767: Brcmsmac driver woes, possible regression?
Ben Hutchings wrote: On Wed, 2012-05-30 at 12:27 -0500, Jonathan Nieder wrote: 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 [...] and random reconnects Camaleón was experiencing. I think we should take them all. (It's basically a backport of brcmsmac changes to date, minus the switch to BCMA.) [...] I'm sorry but I don't agree. This would seem to leave us with a version of brcmsmac that's quite different from what anyone else uses. Please try to identify which of these are the really important changes and propose them for stable. Fair enough. I think we'll need help from upstream to figure that out. [...] (It may however be sensible to use the 'compat-wireless' tree as a means to keep wireless drivers updated in wheezy. I keep meaning to look into the details of this and then discuss it with the kernel and release teams.) I don't think that's a good idea unless it's a separate package, since wireless drivers get their fair share of regressions just like the rest of the kernel and there is no equivalent of stable for driver backports. But as a separate package that could be frequently updated through backports.debian.org it might be nice. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-05-22 a las 16:18 -0500, Jonathan Nieder escribió: Thanks again for your patience. Could you try the attached patch series against a 3.2.18-based kernel (like the one from kernel.org or from sid)? (...) Downloaded the sid kernel sources, applied the 23 patches, compiled the whole kernel, generated a deb file and installed but brcmsmac module seems to be missing and whatever I add at the .config file does not resurrect the module. And I don't remember what I did the last time nor if something has changed (again) in this regard O:-) Any hint? What's the magic line to get brcmsmac back in this kernel version? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Sat, 2012-05-26 at 16:25 +0200, Camaleón wrote: El 2012-05-22 a las 16:18 -0500, Jonathan Nieder escribió: Thanks again for your patience. Could you try the attached patch series against a 3.2.18-based kernel (like the one from kernel.org or from sid)? (...) Downloaded the sid kernel sources, applied the 23 patches, compiled the whole kernel, generated a deb file and installed but brcmsmac module seems to be missing and whatever I add at the .config file does not resurrect the module. And I don't remember what I did the last time nor if something has changed (again) in this regard O:-) Any hint? What's the magic line to get brcmsmac back in this kernel version? I wonder whether you really built from the Debian-patched sources (by running debian/bin/test-patches or debian/rules build or similar) or the upstream source. In Linux 3.2 you can enable either CONFIG_BCMA (bcma bus driver, supporting the b43 driver) or CONFIG_BRCMSMAC (brcmsmac driver) but not both. Debian has a patch that resolves this conflict, and they are both enabled. However, if you don't apply that patch then you need to make sure CONFIG_BCMA is disabled before you can enable CONFIG_BRCMSMAC. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-05-26 a las 16:07 +0100, Ben Hutchings escribió: Any hint? What's the magic line to get brcmsmac back in this kernel version? I wonder whether you really built from the Debian-patched sources (by running debian/bin/test-patches or debian/rules build or similar) or the upstream source. A mix of that. I got the sources (manually) from Debian repos and proceeded as usual (make menuconfig...). In Linux 3.2 you can enable either CONFIG_BCMA (bcma bus driver, supporting the b43 driver) or CONFIG_BRCMSMAC (brcmsmac driver) but not both. Debian has a patch that resolves this conflict, and they are both enabled. However, if you don't apply that patch then you need to make sure CONFIG_BCMA is disabled before you can enable CONFIG_BRCMSMAC. That was it! Disabling bcma showed brcmsmac and now the module is built. Thanks a bunch, I was going nuts with this. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/5/26 Camaleón noela...@gmail.com: El 2012-05-26 a las 16:07 +0100, Ben Hutchings escribió: In Linux 3.2 you can enable either CONFIG_BCMA (bcma bus driver, supporting the b43 driver) or CONFIG_BRCMSMAC (brcmsmac driver) but not both. Debian has a patch that resolves this conflict, and they are both enabled. However, if you don't apply that patch then you need to make sure CONFIG_BCMA is disabled before you can enable CONFIG_BRCMSMAC. That was it! Disabling bcma showed brcmsmac and now the module is built. Thanks a bunch, I was going nuts with this. Thanks to Ben's tip now the testing is in place. The patches have been applied and brcmsmac module is loaded. Mmm... I'm attaching a kernel oops I got after having the module loaded, curious is that despite the oops, the wireless link is up and running, no reconnects (which reminds me the first reports...). Will report back for any other update or change in the wireless activity. Greetings, -- Camaleón [18798.704992] brcmsmac :02:00.0: bus 2 slot 0 func 0 irq 10 [18798.705022] brcmsmac :02:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [18798.705037] brcmsmac :02:00.0: setting latency timer to 64 [18798.772188] Found chip type AI (0x13814313) [18798.780894] Applying 4313 WARs [18798.782015] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule: [18798.782026] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782036] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule: [18798.782045] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782054] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule: [18798.782063] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782072] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule: [18798.782082] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782090] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule: [18798.782101] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782110] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule: [18798.782120] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782128] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule: [18798.782138] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782146] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule: [18798.782157] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782165] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule: [18798.782175] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782183] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule: [18798.782193] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782202] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule: [18798.782212] cfg80211: 2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [18798.782221] cfg80211: Updating information on frequency 2467 MHz for a 20 MHz width channel with regulatory rule: [18798.782231] cfg80211: 2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [18798.782240] cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width channel with regulatory rule: [18798.782250] cfg80211: 2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [18798.782259] cfg80211: Updating information on frequency 2484 MHz for a 20 MHz width channel with regulatory rule: [18798.782268] cfg80211: 2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [18798.837102] cfg80211: Calling CRDA for country: ES [18798.852520] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule: [18798.852530] cfg80211: 2402000 KHz - 2482000 KHz @ 4 KHz), (N/A mBi, 2000 mBm) [18798.852536] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule: [18798.852543] cfg80211: 2402000 KHz - 2482000 KHz @ 4 KHz), (N/A mBi, 2000 mBm) [18798.852549] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule: [18798.852556] cfg80211: 2402000 KHz - 2482000 KHz @ 4 KHz), (N/A mBi, 2000 mBm) [18798.852562] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule: [18798.852569] cfg80211: 2402000 KHz - 2482000 KHz @ 4 KHz), (N/A mBi, 2000
Bug#664767: Brcmsmac driver woes, possible regression?
Hi Camaleón, Camaleón wrote: Mmm... I'm attaching a kernel oops I got after having the module loaded, curious is that despite the oops, the wireless link is up and running, no reconnects (which reminds me the first reports...). Will report back for any other update or change in the wireless activity. Thanks. I assume you mean the brcms_c_wait_... warning when you refer to an oops. Separating the symptoms: brcms_c_wait_for_tx_completion warning: bug#672891 connection resets, segfaults, general instability: bug#664767 (this bug) AMPDU status: BA Timeout: bug#674430 Seth wrote[1]: | The trace is related to handling a disconnection, which will also | trigger a reprocessing of the regulatory rules. The warning and the | regulatory message share a common cause, but I don't think there's a | direct relationship between them. I don't think his regulatory series[2] is likely to affect your symptoms, but maybe it will be easier to get help once that has been reviewed and applied upstream. In the meantime, thanks for your updates --- this helps a lot. Regards, Jonathan [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/87873/focus=87922 [2] http://thread.gmane.org/gmane.linux.kernel.wireless.general/89097 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
severity 664767 important quit Hi again, Camaleón wrote: Although kernel 3.3 still logs the trace (despite having applied all of the suggested the patches), there's an overall stability improvement in the wireless driver when compared to kernel 3.2.12 where: - Wireless link is more prone to connection resets which require for user interaction to reconnect again - Reconnects make some running programs to segfault [...] Apr 6 19:56:22 stt300 kernel: [32987.534515] gnome-shell[2062]: segfault at 24 ip b76bbb31 sp bfbf7920 error 4 in libgnome-shell.so[b7681000+a] Apr 6 19:58:02 stt300 kernel: [33086.718790] mail-notificati[2077]: segfault at 4c ip 08060063 sp bfe8d4a0 error 4 in mail-notification[8048000+5c000] That's no good. It would be nice to get this fixed in 3.2.y upstream if possible. [...] Is there something we can do to improve the driver status in Wheezy? I think we ought to update brcmsmac to the latest version available for wheezy. It is a young driver, and the version in 3.2 has serious problems as described by Seth Forsee[1]: | The background is that brcmsmac contains a bunch of code for regulatory | support that is either duplicated (and in conflict) with the | protocol-level support or else it would better be handled there. This is | causing problems on pretty much any channel that isn't part of the | default world regulatory domain. | | I've sent RFC patches that strip out the vast majority of this code in | favor of better integration with the protocol-level regulatory support. Unfortunately that could a little tricky because there might be changes elsewhere that brcmsmac relies on (bcma, wireless core). Jonathan [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/87873/focus=90727 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
On Mon, May 21, 2012 at 09:07:51AM -0500, Jonathan Nieder wrote: Camaleón wrote: Although kernel 3.3 still logs the trace (despite having applied all of the suggested the patches), there's an overall stability improvement in the wireless driver when compared to kernel 3.2.12 where: - Wireless link is more prone to connection resets which require for user interaction to reconnect again - Reconnects make some running programs to segfault [...] Apr 6 19:56:22 stt300 kernel: [32987.534515] gnome-shell[2062]: segfault at 24 ip b76bbb31 sp bfbf7920 error 4 in libgnome-shell.so[b7681000+a] Apr 6 19:58:02 stt300 kernel: [33086.718790] mail-notificati[2077]: segfault at 4c ip 08060063 sp bfe8d4a0 error 4 in mail-notification[8048000+5c000] That's no good. It would be nice to get this fixed in 3.2.y upstream if possible. Maybe try also new 3.2.18-1 kernel (available today in unstable) to see how stable it works. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-05-21 a las 09:07 -0500, Jonathan Nieder escribió: Camaleón wrote: Apr 6 19:56:22 stt300 kernel: [32987.534515] gnome-shell[2062]: segfault at 24 ip b76bbb31 sp bfbf7920 error 4 in libgnome-shell.so[b7681000+a] Apr 6 19:58:02 stt300 kernel: [33086.718790] mail-notificati[2077]: segfault at 4c ip 08060063 sp bfe8d4a0 error 4 in mail-notification[8048000+5c000] That's no good. It would be nice to get this fixed in 3.2.y upstream if possible. Just for the record, I've had to stop using brcmsmac for now (it usually went down when doing regular updates in wheezy :-/) and I'm currently running wl, which runs quite well (no reconnects, no dropdowns and stable as a rock). I'll keep doing tests from time to time when a new kernel arrives (3.4 should be out, so I can compile and test brcmsmac from the mainline, time permitting). [...] Is there something we can do to improve the driver status in Wheezy? I think we ought to update brcmsmac to the latest version available for wheezy. It is a young driver, and the version in 3.2 has serious problems as described by Seth Forsee[1]: | The background is that brcmsmac contains a bunch of code for regulatory | support that is either duplicated (and in conflict) with the | protocol-level support or else it would better be handled there. This is | causing problems on pretty much any channel that isn't part of the | default world regulatory domain. | | I've sent RFC patches that strip out the vast majority of this code in | favor of better integration with the protocol-level regulatory support. Unfortunately that could a little tricky because there might be changes elsewhere that brcmsmac relies on (bcma, wireless core). Jonathan [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/87873/focus=90727 Thanks for you ongoing support on this, Jonathan. Just ping this bug whenever you need I run any specific test, I'll be more than happy to help :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/3/24 Jonathan Nieder jrnie...@gmail.com: Camaleón wrote: 2012/3/24 Jonathan Nieder jrnie...@gmail.com: Could you send a summary of the symptoms to linux-wirel...@vger.kernel.org, cc-ing Stanislaw Gruszka sgrus...@redhat.com, Arend van Spriel ar...@broadcom.com, and either me or this bug log so we can track it? [...] Already done. Perfect. Thanks much. Jonathan, Although kernel 3.3 still logs the trace (despite having applied all of the suggested the patches), there's an overall stability improvement in the wireless driver when compared to kernel 3.2.12 where: - Wireless link is more prone to connection resets which require for user interaction to reconnect again - Reconnects make some running programs to segfault This snippet comes for kernel 3.2.12 (which I have loaded today with brcmsmac.ko patched) after having experiences one of these intermittent reconnects: Apr 6 19:56:22 stt300 kernel: [32987.534515] gnome-shell[2062]: segfault at 24 ip b76bbb31 sp bfbf7920 error 4 in libgnome-shell.so[b7681000+a] Apr 6 19:58:02 stt300 kernel: [33086.718790] mail-notificati[2077]: segfault at 4c ip 08060063 sp bfe8d4a0 error 4 in mail-notification[8048000+5c000] Is there something we can do to improve the driver status in Wheezy? I can test any pacthes that can make brcmsmac to be more stable, at least to get a stability closer to the one provided by kernel 3.3. I wouldn't like to see Wheezy users complaining or dropping on the open source driver and going to wl because of this so if there's anything more I can test, please just tell. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.3.tar.bz2 And got another trace Mar 23 17:50:08 stt300 kernel: [ 112.280060] [ cut here ] Mar 23 17:50:08 stt300 kernel: [ 112.280123] WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:7998 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() [...] Should I install a different kernel? Thanks. Nah. Could you send a summary of the symptoms to linux-wirel...@vger.kernel.org, cc-ing Stanislaw Gruszka sgrus...@redhat.com, Arend van Spriel ar...@broadcom.com, and either me or this bug log so we can track it? Be sure to mention: - steps to reproduce the problem, expected result, actual result, and how the difference indicates a bug (should be simple here :)) - how reproducible it is (40%? 100%?) - which kernel versions you have tested and what happened with each - full dmesg output from booting and reproducing the bug, as an attachment - any workarounds or other weird observations - a pointer to http://bugs.debian.org/664767 for the backstory Hopefully they might have commands to run or a patch to try to track down what is going wrong. Thanks, and sorry for the trouble. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/3/24 Jonathan Nieder jrnie...@gmail.com: Thanks. Nah. Could you send a summary of the symptoms to linux-wirel...@vger.kernel.org, cc-ing Stanislaw Gruszka sgrus...@redhat.com, Arend van Spriel ar...@broadcom.com, and either me or this bug log so we can track it? Be sure to mention: - steps to reproduce the problem, expected result, actual result, and how the difference indicates a bug (should be simple here :)) - how reproducible it is (40%? 100%?) - which kernel versions you have tested and what happened with each - full dmesg output from booting and reproducing the bug, as an attachment - any workarounds or other weird observations - a pointer to http://bugs.debian.org/664767 for the backstory Hopefully they might have commands to run or a patch to try to track down what is going wrong. Thanks, and sorry for the trouble. Jonathan Already done. Thanks for your ongoing work and continuous support, Jonathan :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
forwarded 664767 http://thread.gmane.org/gmane.linux.kernel.wireless.general/87873 quit Camaleón wrote: 2012/3/24 Jonathan Nieder jrnie...@gmail.com: Could you send a summary of the symptoms to linux-wirel...@vger.kernel.org, cc-ing Stanislaw Gruszka sgrus...@redhat.com, Arend van Spriel ar...@broadcom.com, and either me or this bug log so we can track it? [...] Already done. Perfect. Thanks much. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/3/22 Camaleón noela...@gmail.com: I'll compile the latest kernel available from kernel.org this weekend and report back as soon as I get useful results. I just have installed: http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.3.tar.bz2 And got another trace Mar 23 17:50:08 stt300 kernel: [ 112.280060] [ cut here ] Mar 23 17:50:08 stt300 kernel: [ 112.280123] WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:7998 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() Mar 23 17:50:08 stt300 kernel: [ 112.280134] Hardware name: Compaq Mini CQ10-500 Mar 23 17:50:08 stt300 kernel: [ 112.280142] Modules linked in: acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative parport_pc ppdev lp parport binfmt_misc uinput fuse loop arc4 snd_hda_codec_idt joydev uvcvideo videobuf2_core videodev media videobuf2_vmalloc videobuf2_memops brcmsmac mac80211 brcmutil cfg80211 crc8 cordic snd_hda_intel snd_hda_codec snd_hwdep snd_pcm iTCO_wdt bcma snd_seq snd_timer snd_seq_device hp_wmi sparse_keymap rfkill psmouse evdev serio_raw pcspkr uhci_hcd snd r8169 i915 soundcore ehci_hcd rts_pstor(C) iTCO_vendor_support mii usbcore snd_page_alloc i2c_i801 drm_kms_helper usb_common drm i2c_algo_bit i2c_core ac battery wmi power_supply video processor button reiserfs sd_mod crc_t10dif ahci libahci thermal thermal_sys libata scsi_mod Mar 23 17:50:08 stt300 kernel: [ 112.280337] Pid: 135, comm: kworker/u:3 Tainted: G C 3.3.0 #1 Mar 23 17:50:08 stt300 kernel: [ 112.280345] Call Trace: Mar 23 17:50:08 stt300 kernel: [ 112.280367] [c102bbee] ? warn_slowpath_common+0x68/0x79 Mar 23 17:50:08 stt300 kernel: [ 112.280406] [f8bdec49] ? brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac] Mar 23 17:50:08 stt300 kernel: [ 112.280421] [c102bc0c] ? warn_slowpath_null+0xd/0x10 Mar 23 17:50:08 stt300 kernel: [ 112.280459] [f8bdec49] ? brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac] Mar 23 17:50:08 stt300 kernel: [ 112.280491] [f8bd6131] ? brcms_ops_flush+0x1f/0x29 [brcmsmac] Mar 23 17:50:08 stt300 kernel: [ 112.280539] [f8870a84] ? __ieee80211_recalc_idle+0x19a/0x1c5 [mac80211] Mar 23 17:50:08 stt300 kernel: [ 112.280556] [c1046339] ? should_resched+0x5/0x1e Mar 23 17:50:08 stt300 kernel: [ 112.280601] [f88715f0] ? ieee80211_recalc_idle+0x19/0x36 [mac80211] Mar 23 17:50:08 stt300 kernel: [ 112.280644] [f886b477] ? ieee80211_sta_connection_lost+0x62/0x77 [mac80211] Mar 23 17:50:08 stt300 kernel: [ 112.280689] [f886d9d4] ? ieee80211_sta_work+0xc5/0x11f [mac80211] Mar 23 17:50:08 stt300 kernel: [ 112.280704] [c103d823] ? process_one_work+0x112/0x1fa Mar 23 17:50:08 stt300 kernel: [ 112.280749] [f886fd76] ? ieee80211_teardown_sdata+0xab/0xab [mac80211] Mar 23 17:50:08 stt300 kernel: [ 112.280763] [c103e08c] ? worker_thread+0xa9/0x122 Mar 23 17:50:08 stt300 kernel: [ 112.280776] [c103dfe3] ? manage_workers.isra.23+0x13d/0x13d Mar 23 17:50:08 stt300 kernel: [ 112.280789] [c1040ab8] ? kthread+0x68/0x6d Mar 23 17:50:08 stt300 kernel: [ 112.280802] [c1040a50] ? kthread_freezable_should_stop+0x37/0x37 Mar 23 17:50:08 stt300 kernel: [ 112.280816] [c12c0b3e] ? kernel_thread_helper+0x6/0x10 Mar 23 17:50:08 stt300 kernel: [ 112.280825] ---[ end trace 5431285cf30076f2 ]--- Should I install a different kernel? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-03-21 a las 17:00 -0500, Jonathan Nieder escribió: Camaleón wrote: 2012/3/21 Camaleón noela...@gmail.com: I'm going to keep the system all the day with wifi connected and see if I get any trace. Will report back as soon as I can provide the data. Thanks. I've got another trace: [...] WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:8234 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() Looks like that patch doesn't fix it. Thanks for the quick feedback. By reviewing the kernel bug¹, I've noted something. The patch I applied² modified this file: drivers/net/wireless/brcm80211/brcmsmac/ampdu.c While the patch referenced³ in the bug report seems to make changes in: drivers/net/wireless/brcm80211/brcmsmac/main.c Now I'm not sure to have applied the correct one :-? How does v3.3 do? (It should pass from the NEW queue into experimental in the next day or so, or if you have time to build a kernel.org kernel then that would be just as good a test.) I'll compile the latest kernel available from kernel.org this weekend and report back as soon as I get useful results. ¹https://bugzilla.kernel.org/show_bug.cgi?id=42576 ²http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=brcm80211-smac-fix-endless-retry-of-A-MPDU-transmiss.patch;att=1;bug=664767 ³https://bugzilla.kernel.org/attachment.cgi?id=72082 Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
El 2012-03-20 a las 13:36 -0500, Jonathan Nieder escribió: Hi Camaleón, That was fast :-) Camaleón wrote: Since the last days, I'm experiencing some unstability with the brcmsmac driver and get kernel traces like this in the logs: [ 210.896074] [ cut here ] [ 210.896138] WARNING: at [...]/drivers/net/wireless/brcm80211/brcmsmac/main.c:8234 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() Context: https://bugzilla.kernel.org/show_bug.cgi?id=42576 Does the attached patch change anything? (...) When trying to load the patched module (insmod brcmsmac.ko), I get: insmod: error inserting 'brcmsmac.ko': -1 Invalid module format And dmesg: brcmsmac: disagrees about version of symbol module_layout What I did? - Got the current kernel source¹ from Debian - Unpacked the files on the desktop - Applied the patch to the file - Run make menuconfig and followed this² instructions - Run make SUBDIRS=drivers/net/wireless/brcm80211/brcmsmac modules I must be making something wrong. I know I could try with kernel 3.3-rc2 where the patch is already applied but my guess is that you prefer to check if the patch works with current kernel 3.2-9 because that's what wheezy will use, right? Any help on how to bypass this will be appreciated. ¹http://ftp.de.debian.org/debian/pool/main/l/linux-2.6/linux-2.6_3.2.9.orig.tar.gz ²http://linuxwireless.org/en/users/Drivers/brcm80211 Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: I know I could try with kernel 3.3-rc2 where the patch is already applied Yep, results from the kernel in experimental would already be interesting. but my guess is that you prefer to check if the patch works with current kernel 3.2-9 because that's what wheezy will use, right? Exactly. Assuming 3.3 works well, I would like to see if that patch works so it can be applied to the upstream 3.2.y tree, fixing this bug in wheezy and other 3.2-based distros. Possible instructions for building a module to test, based on [1]: # prerequisites apt-get build-dep linux-2.6; # as root # get and unpack the source apt-get source linux-2.6/sid cd linux-2.6-version fakeroot debian/rules source fakeroot debian/rules setup_i386_none_686-pae # apply patch cd debian/build/build_i386_none_686-pae patch -p1 the patch # build driver make drivers/net/wireless/brcm80211/brcmsmac/ Alternatively, here is a simpler but more resource-intensive method that more directly answers the question is this patch suitable for the 3.2.y-stable tree?: # prerequisites apt-get install git build-essential # fetch the kernel history if you don't already have it git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git # fetch point releases cd linux git remote add -f stable \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git # test 3.2.y git checkout stable/linux-3.2.y cp /boot/config-$(uname -r) .config; # current configuration make localmodconfig; # optional: minimize configuration make nconfig; # making sure CONFIG_BRCMSMAC is enabled as a module make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot ... test test test ... # hopefully it reproduces the bug. So try the patch: cd linux git am -3sc the patch make deb-pkg; # maybe with -j4 dpkg -i ../name of package; # as root reboot ... test test test ... Sorry for the lack of detail before. Ciao, Jonathan [1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official or the corresponding page in the debian-kernel-handbook package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/3/21 Jonathan Nieder jrnie...@gmail.com: Possible instructions for building a module to test, based on [1]: # prerequisites apt-get build-dep linux-2.6; # as root # get and unpack the source apt-get source linux-2.6/sid cd linux-2.6-version fakeroot debian/rules source fakeroot debian/rules setup_i386_none_686-pae # apply patch cd debian/build/build_i386_none_686-pae patch -p1 the patch # build driver make drivers/net/wireless/brcm80211/brcmsmac/ Thanks for the detailed steps. The first one looks easier, but this step fails: root@stt300:/usr/src/linux-2.6-3.2.9# fakeroot debian/rules setup_i386_none_686-pae make: *** No rule to make target `setup_i386_none_686-pae'. Stop. I'm not very skilled when it comes to compile things or building packages, sorry :-P -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/3/21 Camaleón noela...@gmail.com: Thanks for the detailed steps. The first one looks easier, but this step fails: root@stt300:/usr/src/linux-2.6-3.2.9# fakeroot debian/rules setup_i386_none_686-pae make: *** No rule to make target `setup_i386_none_686-pae'. Stop. Okay, some advances. I had to run: fakeroot make -f debian/rules.gen setup_i386_none_686-pae As instructed in the kernel guide you sent but now the module does not compile, once I run: make drivers/net/wireless/brcm80211/brcmsmac/ Which exists with no errors, there is no brcmsmac.ko generated :-? -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/3/21 Camaleón noela...@gmail.com: As instructed in the kernel guide you sent but now the module does not compile, once I run: make drivers/net/wireless/brcm80211/brcmsmac/ Which exists with no errors, there is no brcmsmac.ko generated :-? Okay, I think I finally did it: root@stt300:/usr/src/linux-2.6-3.2.9/debian/build/build_i386_none_686-pae# modinfo drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko filename: drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko license:Dual BSD/GPL description:Broadcom 802.11n wireless LAN driver. author: Broadcom Corporation alias: pci:v14E4d0576sv*sd*bc*sc*i* alias: pci:v14E4d4727sv*sd*bc*sc*i* alias: pci:v14E4d4353sv*sd*bc*sc*i* alias: pci:v14E4d4357sv*sd*bc*sc*i* depends:mac80211,brcmutil,cfg80211,cordic,crc8 vermagic: 3.2.0-2-686-pae SMP mod_unload modversions 686 And now the module is loaded (I had to load first mac80211,brcmutil,cfg80211,cordic,crc8 modules and lastly, the patched brcmsmac). I'm going to keep the system all the day with wifi connected and see if I get any trace. Will report back as soon as I can provide the data. Thanks. -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Camaleón wrote: 2012/3/21 Camaleón noela...@gmail.com: I'm going to keep the system all the day with wifi connected and see if I get any trace. Will report back as soon as I can provide the data. Thanks. I've got another trace: [...] WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:8234 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() Looks like that patch doesn't fix it. Thanks for the quick feedback. How does v3.3 do? (It should pass from the NEW queue into experimental in the next day or so, or if you have time to build a kernel.org kernel then that would be just as good a test.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
2012/3/21 Camaleón noela...@gmail.com: I'm going to keep the system all the day with wifi connected and see if I get any trace. Will report back as soon as I can provide the data. Thanks. I've got another trace: Mar 21 22:44:07 stt300 kernel: [114985.404111] [ cut here ] Mar 21 22:44:07 stt300 kernel: [114985.404156] WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:8234 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() Mar 21 22:44:07 stt300 kernel: [114985.404172] Hardware name: Compaq Mini CQ10-500 Mar 21 22:44:07 stt300 kernel: [114985.404178] Modules linked in: brcmsmac(O) crc8 cordic brcmutil mac80211 cfg80211 acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative parport_pc ppdev lp parport binfmt_misc uinput fuse loop uvcvideo videodev media joydev i915 arc4 snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm uhci_hcd snd_seq hp_wmi ehci_hcd snd_timer sparse_keymap pcspkr evdev psmouse drm_kms_helper usbcore drm iTCO_wdt r8169 iTCO_vendor_support usb_common i2c_i801 snd_seq_device battery serio_raw snd i2c_algo_bit ac i2c_core rts_pstor(C) rfkill power_supply mii wmi soundcore snd_page_alloc video button processor reiserfs sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys [last unloaded: cordic] Mar 21 22:44:07 stt300 kernel: [114985.404345] Pid: 1569, comm: kworker/u:0 Tainted: GWC O 3.2.0-2-686-pae #1 Mar 21 22:44:07 stt300 kernel: [114985.404352] Call Trace: Mar 21 22:44:07 stt300 kernel: [114985.404368] [c1038398] ? warn_slowpath_common+0x68/0x79 Mar 21 22:44:07 stt300 kernel: [114985.404399] [f878ee22] ? brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac] Mar 21 22:44:07 stt300 kernel: [114985.404411] [c10383b6] ? warn_slowpath_null+0xd/0x10 Mar 21 22:44:07 stt300 kernel: [114985.404441] [f878ee22] ? brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac] Mar 21 22:44:07 stt300 kernel: [114985.404467] [f878610f] ? brcms_ops_flush+0x1f/0x29 [brcmsmac] Mar 21 22:44:07 stt300 kernel: [114985.404496] [f884adca] ? ieee80211_scan_work+0x36a/0x3fb [mac80211] Mar 21 22:44:07 stt300 kernel: [114985.404510] [c1049a53] ? process_one_work+0x112/0x1fa Mar 21 22:44:07 stt300 kernel: [114985.404536] [f884aa60] ? ieee80211_scan_rx+0x139/0x139 [mac80211] Mar 21 22:44:07 stt300 kernel: [114985.404547] [c104a75e] ? worker_thread+0xa9/0x122 Mar 21 22:44:07 stt300 kernel: [114985.404558] [c104a6b5] ? manage_workers.isra.23+0x13d/0x13d Mar 21 22:44:07 stt300 kernel: [114985.404568] [c104d09f] ? kthread+0x63/0x68 Mar 21 22:44:07 stt300 kernel: [114985.404578] [c104d03c] ? kthread_worker_fn+0x101/0x101 Mar 21 22:44:07 stt300 kernel: [114985.404590] [c12beffe] ? kernel_thread_helper+0x6/0x10 Mar 21 22:44:07 stt300 kernel: [114985.404597] ---[ end trace 69d340d40ce8dd46 ]--- This time the wireless card was not disconnected at all, I just saw the trace at dmesg, no other visible effects were present. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664767: Brcmsmac driver woes, possible regression?
Package: linux-2.6 Version: 3.2.9-1 Severity: normal Since the last days, I'm experiencing some unstability with the brcmsmac driver and get kernel traces like this in the logs: [ 210.896074] [ cut here ] [ 210.896138] WARNING: at /build/buildd- linux-2.6_3.2.9-1-i386-YUHlYw/linux-2.6-3.2.9/debian/build/source_i386_none/drivers/net/wireless/brcm80211/brcmsmac/main.c:8234 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() [ 210.896153] Hardware name: Compaq Mini CQ10-500 [ 210.896160] 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 videodev media joydev i915 arc4 snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm uhci_hcd brcmsmac snd_seq hp_wmi ehci_hcd mac80211 snd_timer sparse_keymap pcspkr evdev psmouse drm_kms_helper brcmutil usbcore drm iTCO_wdt r8169 iTCO_vendor_support usb_common i2c_i801 snd_seq_device battery serio_raw snd i2c_algo_bit ac i2c_core rts_pstor(C) cfg80211 crc8 cordic rfkill power_supply mii wmi soundcore snd_page_alloc video button processor reiserfs sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys [ 210.896347] Pid: 135, comm: kworker/u:3 Tainted: G C 3.2.0-2-686-pae #1 [ 210.896355] Call Trace: [ 210.896376] [c1038398] ? warn_slowpath_common+0x68/0x79 [ 210.896416] [f878ee1e] ? brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac] [ 210.896430] [c10383b6] ? warn_slowpath_null+0xd/0x10 [ 210.896468] [f878ee1e] ? brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac] [ 210.896500] [f878610f] ? brcms_ops_flush+0x1f/0x29 [brcmsmac] [ 210.896538] [f865fdca] ? ieee80211_scan_work+0x36a/0x3fb [mac80211] [ 210.896554] [c1049a53] ? process_one_work+0x112/0x1fa [ 210.896588] [f865fa60] ? ieee80211_scan_rx+0x139/0x139 [mac80211] [ 210.896602] [c104a75e] ? worker_thread+0xa9/0x122 [ 210.896615] [c104a6b5] ? manage_workers.isra.23+0x13d/0x13d [ 210.896627] [c104d09f] ? kthread+0x63/0x68 [ 210.896639] [c104d03c] ? kthread_worker_fn+0x101/0x101 [ 210.896654] [c12beffe] ? kernel_thread_helper+0x6/0x10 [ 210.896663] ---[ end trace 69d340d40ce8dd3f ]--- There are more entries like this in the last days: root@stt300:~# grep -i cut here /var/log/messages* /var/log/messages:Mar 20 14:51:12 stt300 kernel: [ 210.896074] [ cut here ] /var/log/messages.1:Mar 11 19:51:46 stt300 kernel: [ 9632.344061] [ cut here ] /var/log/messages.1:Mar 12 18:45:37 stt300 kernel: [13952.604072] [ cut here ] /var/log/messages.1:Mar 14 17:02:08 stt300 kernel: [ 650.192074] [ cut here ] /var/log/messages.1:Mar 14 19:45:36 stt300 kernel: [ 110.964072] [ cut here ] /var/log/messages.1:Mar 15 18:38:14 stt300 kernel: [ 1231.616077] [ cut here ] /var/log/messages.1:Mar 16 15:43:47 stt300 kernel: [ 290.948065] [ cut here ] /var/log/messages.1:Mar 17 09:02:36 stt300 kernel: [ 513.360069] [ cut here ] /var/log/messages.1:Mar 17 15:32:42 stt300 kernel: [ 110.188068] [ cut here ] /var/log/messages.1:Mar 19 08:40:59 stt300 kernel: [ 201.160070] [ cut here ] Dsepite the trace, wireless adapter is still working and there is no other visible effects, although sometimes the wireless card loses its connection with the AP and has to reconnect again. -- Package-specific info: ** Version: Linux version 3.2.0-2-686-pae (Debian 3.2.9-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Mon Mar 5 01:59:18 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-2-686-pae root=UUID=ef88aa1c-5071-41ac-8884-6c991eca9b22 ro quiet ** Tainted: WC (1536) * Taint on warning. * Module from drivers/staging has been loaded. ** Kernel log: [ 73.331997] ieee80211 phy0: changing basic rates failed: -22 [ 73.332054] ieee80211 phy0: brcms_ops_bss_info_changed: arp filtering: enabled true, count 0 (implement) [ 73.333523] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 86.096056] wlan0: no IPv6 routers present [ 95.004534] ieee80211 phy0: brcms_ops_bss_info_changed: arp filtering: enabled true, count 1 (implement) [ 210.896074] [ cut here ] [ 210.896138] WARNING: at /build/buildd-linux-2.6_3.2.9-1-i386-YUHlYw/linux-2.6-3.2.9/debian/build/source_i386_none/drivers/net/wireless/brcm80211/brcmsmac/main.c:8234 brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]() [ 210.896153] Hardware name: Compaq Mini CQ10-500 [ 210.896160] 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 videodev media joydev i915 arc4 snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm uhci_hcd
Bug#664767: Brcmsmac driver woes, possible regression?
Hi Camaleón,
Camaleón wrote:
Since the last days, I'm experiencing some unstability with the brcmsmac
driver
and get kernel traces like this in the logs:
[ 210.896074] [ cut here ]
[ 210.896138] WARNING: at
[...]/drivers/net/wireless/brcm80211/brcmsmac/main.c:8234
brcms_c_wait_for_tx_completion+0x73/0x7d [brcmsmac]()
Context: https://bugzilla.kernel.org/show_bug.cgi?id=42576
Does the attached patch change anything?
From: Arend van Spriel ar...@broadcom.com
Date: Thu, 23 Feb 2012 18:38:22 +0100
Subject: brcm80211: smac: fix endless retry of A-MPDU transmissions
commit 85091fc0a75653e239dc8379658515e577544927 upstream.
The A-MPDU code checked against a retry limit, but it was using
the wrong variable to do so. This patch fixes this to assure
proper retry mechanism.
This problem had a side-effect causing the mac80211 flush callback
to remain waiting forever as well. That side effect has been fixed
by commit by Stanislaw Gruszka:
commit f96b08a7e6f69c0f0a576554df3df5b1b519c479
Date: Tue Jan 17 12:38:50 2012 +0100
brcmsmac: fix tx queue flush infinite loop
Reference:
https://bugzilla.kernel.org/show_bug.cgi?id=42576
Cc: Stanislaw Gruszka sgrus...@redhat.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Reviewed-by: Alwin Beukers al...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
drivers/net/wireless/brcm80211/brcmsmac/ampdu.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
b/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
index 7f27dbdb6b60..051586275f14 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
@@ -1053,17 +1053,13 @@ brcms_c_ampdu_dotxstatus_complete(struct ampdu_info
*ampdu, struct scb *scb,
}
/* either retransmit or send bar if ack not recd */
if (!ack_recd) {
- struct ieee80211_tx_rate *txrate =
- tx_info-status.rates;
- if (retry (txrate[0].count (int)retry_limit)) {
+ if (retry (ini-txretry[index] (int)retry_limit)) {
ini-txretry[index]++;
ini-tx_in_transit--;
/*
* Use high prededence for retransmit to
* give some punch
*/
- /* brcms_c_txq_enq(wlc, scb, p,
-* BRCMS_PRIO_TO_PREC(tid)); */
brcms_c_txq_enq(wlc, scb, p,
BRCMS_PRIO_TO_HI_PREC(tid));
} else {
--
1.7.10.rc1
