Re: BCM4313 & brcmsmac & 3.12: only semi-working?
Hi Arend, On Sun, Dec 21, 2014 at 06:34:24PM +0100, Maximilian Engelhardt wrote: > On Sunday 21 December 2014 16:03:17 Arend van Spriel wrote: > > On 12/21/14 15:24, Maximilian Engelhardt wrote: > > > On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote: > > >> Thanks. It shows you have have the same bt-coex version as Michael. I am > > >> not familiar with bluetooth side of things. Are you both using bluetooth > > >> on 4313? > > >> > > >> Regards, > > >> Arend > > > > > > I don't know. I think I have Bluetooth somehow enabled but I'm not really > > > using it. I definitely don't have any Bluetooth devices connected. I could > > > try to unload/disable Bluetooth it to see if it makes any difference. > > > > That would be useful to know. > > > > I did a test with all Bluetooth modules unloaded that I could find but > throughput was still very low (about 4 Mbit/s with brcmsmac, my atheros USB > stick archived about 110 Mbit/s). any update on this issue? One of my relatives would like to get rid of that Ralink wifi stick she has been carrying around for 1.5 years now since the internal wifi in her Thinkpad E130 suffers from this problem. Best regards, Daniel -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 03/09/15 21:54, Daniel Glöckner wrote: Hi Arend, On Sun, Dec 21, 2014 at 06:34:24PM +0100, Maximilian Engelhardt wrote: On Sunday 21 December 2014 16:03:17 Arend van Spriel wrote: On 12/21/14 15:24, Maximilian Engelhardt wrote: On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote: Thanks. It shows you have have the same bt-coex version as Michael. I am not familiar with bluetooth side of things. Are you both using bluetooth on 4313? Regards, Arend I don't know. I think I have Bluetooth somehow enabled but I'm not really using it. I definitely don't have any Bluetooth devices connected. I could try to unload/disable Bluetooth it to see if it makes any difference. That would be useful to know. I did a test with all Bluetooth modules unloaded that I could find but throughput was still very low (about 4 Mbit/s with brcmsmac, my atheros USB stick archived about 110 Mbit/s). any update on this issue? One of my relatives would like to get rid of that Ralink wifi stick she has been carrying around for 1.5 years now since the internal wifi in her Thinkpad E130 suffers from this problem. I did get my hands on same device as Michael has/had and it now sits in my developement laptop. Just need to find some time to give it a spin. Regards, Arend Best regards, Daniel -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
Happy new year! On Tue, Mar 10, 2015 at 10:27:18PM +0100, Arend van Spriel wrote: > On 03/09/15 21:54, Daniel Glöckner wrote: > >On Sun, Dec 21, 2014 at 06:34:24PM +0100, Maximilian Engelhardt wrote: > >>On Sunday 21 December 2014 16:03:17 Arend van Spriel wrote: > >>>On 12/21/14 15:24, Maximilian Engelhardt wrote: > On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote: > >Thanks. It shows you have have the same bt-coex version as Michael. I am > >not familiar with bluetooth side of things. Are you both using bluetooth > >on 4313? > > > >Regards, > >Arend > > I don't know. I think I have Bluetooth somehow enabled but I'm not really > using it. I definitely don't have any Bluetooth devices connected. I could > try to unload/disable Bluetooth it to see if it makes any difference. > >>> > >>>That would be useful to know. > >>> > >> > >>I did a test with all Bluetooth modules unloaded that I could find but > >>throughput was still very low (about 4 Mbit/s with brcmsmac, my atheros USB > >>stick archived about 110 Mbit/s). > > > >any update on this issue? > >One of my relatives would like to get rid of that Ralink wifi stick she > >has been carrying around for 1.5 years now since the internal wifi in her > >Thinkpad E130 suffers from this problem. > > I did get my hands on same device as Michael has/had and it now sits > in my developement laptop. Just need to find some time to give it a > spin. Is there any hope for this device? The Thinkpad is still in use. Best regards, Daniel -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 27-08-14 17:27, Arend van Spriel wrote: > On 08/27/14 12:02, Michael Tokarev wrote: >> 27.08.2014 01:37, Arend van Spriel wrote: >>> On 08/26/14 18:15, Michael Tokarev wrote: >> [] >>> Well, sorry about that. I did see the other messages fly by and >>> noticed you were using the wl driver so assumed you were fine with that. >> >> That's past already. I had several issues with wl driver, >> and current issue is that even the latest (Aug-2014) version >> of wl driver doesn't work with current kernel. So I can't >> really even compare wl and brcmsmac, -- in kernels< 3.16 >> brcmsmac does not work, but wl can't be compiled for 3.16, >> and using different kernels for comparison is a bit wrong >> because there may be differences in other areas. >> >>> Admittedly the brcmsmac got very little attention as all our >>> resources were put on brcmfmac. >> >> That happens. :) >> >> [] >>> Ok. Let's put frustration aside and make an effort. So could you make >>> a trace using trace-cmd utility. The log can get quite big. The >>> brcmsmac driver needs to be built with CONFIG_BRCM_TRACING enabled. >>> Please execute the following commands (assuming you use ubuntu with >>> network-manager): >>> >>> $ sudo stop network-manager >>> $ sudo insmod brcmfmac.ko >>> $ sudo trace-cmd record -e brcmsmac:* >>> >>> In another terminal: >>> >>> $ sudo start network-manager >>> >>> The trace-cmd must be stopped using ctrl-c. >> >> Okay. This turned out to be not so simple. >> >> My initial attempt indicated that brcmsmac in 3.16 does >> not work at all. This isn't actually true - subsequent >> attempts shows that it works. I was ready to conclude >> the problem is fixed (after transferring several gigs >> of data over wifi, with tracing enabled or disabled, >> after fresh boot or after reboot from wl-enabled kernel, >> etc - it all worked. >> >> Until I hit the same stall as I described initially, the >> same which happened numerous times with kernel 3.12 ($subj). >> >> After several mins of transferring it stalled. But this >> time (unlike with 3.12), it continued after about 30 secs. > > A kernel log (so no trace) of stalling interface might be useful so if > you can provide that and put a marker in there where you believe it > stalled that would be great. Hi Michael, Did you have any opportunity to create a log file. Got a question from someone else who got bad bcm4313 behaviour after a certain upgrade. Did you have the same experience? Regards, Arend >> So, while my initial test of 3.16 indicated the prob is still >> here, at the same (or even worse) state, I can't really >> reproduce it, at least in a reliable way. There's something >> wrong still, but at least current version is significantly >> more useful than before (in a hope it wont stall at the >> very wrong moment exactly ;). >> >> There's one more difference between brcmsmac and wl -- with >> wl, I see significantly better speed, -- it is about 5MB/sec, >> while with brcmsmac it jumps between 2.0..4.5MB/sec (with >> 58..65Mbps connection rate in both cases). Here's a typical >> iwconfig output for brcmsmac version: >> >> wlan0 IEEE 802.11bgn ESSID:"mjt" >>Mode:Managed Frequency:2.412 GHz Access Point: >> 64:70:02:29:D9:30 >>Bit Rate=65 Mb/s Tx-Power=19 dBm >>Retry short limit:7 RTS thr:off Fragment thr:off >>Power Management:off >>Link Quality=58/70 Signal level=-61 dBm >>Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 >>Tx excessive retries:56355 Invalid misc:472 Missed beacon:0 >> >> I'll keep trying/testing various cases, in attempt to >> understand what's going on. For now, I can't provide the >> requested traces (it wont be very useful, I guess). >> >> BTW, are there other things not implemented in brcmsmac? >> I see the module reminds about power management, what >> does it mean? Anything else missing? > > Well, the wireless twiki has that info [1]. Regarding features the > important ones that I know are still not there are 40MHz support, and > power-save. The bcm4313 does not support 40MHz. Community contributions > added ibss, and ap mode. For P2P and TDLS probably some changes would be > needed although most of the legwork is done in mac80211. > > Regards, > Arend > > [1] > http://wireless.kernel.org/en/users/Drivers/brcm80211#To_be_done_for_softmac_driver > > >> Thank you! >> >> /mjt > -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
15.09.2014 12:03, Arend van Spriel wrote: > Hi Michael, Hello again! I'm sorry for the long delay, I'll describe what happens in a moment. > Did you have any opportunity to create a log file. Got a question from > someone else who got bad bcm4313 behaviour after a certain upgrade. Did > you have the same experience? No, I didn't have that opportunity. As I mentioned before, the second laptop where I faced the same problem with brcm4313 wasn't mine, and I had to return it back to its owner, so I had nothing to test things on for quite some time. However, a few days ago, after I was searching for a good notebook of my own (obviously without broadcom parts ;), another friend of mine sent me a gift - a new laptop. But this one has even worse wifi card (from linux support PoV anyway) -- it is mediatek (formely ralink) MT7630e card. After trying to build drivers for it for a while, I gave up, and an idea come to me to swap this mediatek card with that broadcom 4313 card. And surprizingly it worked - both laptops accepted the "new" cards and I verified both works. So now the mediatek from my laptop works in my friend's hp envy, and his brcm4313 works on my new asus. So from now on I again have some playground for this stuff. As I mentioned before, the card appears to work fine, at least at first, I wasn't able to trigger any lockups/stalls before. Now I can't trigger any stalls either, again, at least easily. However, I found a 100%-reliable - so far - reproducer for the initial behavour I described in the very first message in this thread, which soon be one year old... Namely, after resume, the card does not work. ARP works, ping and DNS sometimes/somewhat work, inital TCP connection establisment works, but eg http download does not work, it stalls almost immediately. Also during resume, I see the following kernel messages: [ 202.607767] CPU: 2 PID: 2706 Comm: kworker/u9:0 Not tainted 3.16-amd64 #3.16.3 [ 202.607769] Hardware name: ASUSTeK COMPUTER INC. X200LA/X200LA, BIOS X200LA.204 06/16/2014 [ 202.607776] Workqueue: hci0 hci_power_on [bluetooth] [ 202.607778] 0009 [ 202.607780] Restarting tasks ... 814208bf [ 202.607783] 8104c926 8800d5843d08 8800d052f300 8801189ea940 [ 202.607786] 8800d5843d00 8131c0d9 [ 202.607790] Call Trace: [ 202.607797] [] ? dump_stack+0x41/0x51 [ 202.607802] [] ? warn_slowpath_common+0x86/0xb0 [ 202.607807] [] ? _request_firmware+0x439/0xa20 [ 202.607812] [] ? request_firmware+0x35/0x60 [ 202.607816] [] ? btusb_setup_bcm_patchram+0x70/0x3f0 [btusb] [ 202.607823] [] ? hci_dev_do_open+0x24d/0x8c0 [bluetooth] [ 202.607829] [] ? enqueue_task_fair+0x32e/0xce0 [ 202.607834] [] ? sched_clock+0x5/0x10 [ 202.607839] [] ? update_rq_clock+0x3b/0xd0 [ 202.607846] [] ? hci_power_on+0x18/0x120 [bluetooth] [ 202.607877] [] ? kthread_freezable_should_stop+0x60/0x60 [ 202.607881] [] ? ret_from_fork+0x7c/0xb0 [ 202.607885] [] ? kthread_freezable_should_stop+0x60/0x60 [ 202.607887] ---[ end trace da2a7947839f7b1e ]--- [ 202.607891] bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e3.hcd will not be loaded [ 202.607894] Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e3.hcd not found I dunno how related these are -- bluetooth is another function of this card. http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this is a trace collected after resuming from suspend-to-disk, after the above kernel message, and doing this: stop network-manager rmmod brcmsmac brcmutil modpobe brcmsmac trace-cmd record brcmsmac:* & start network-manager wget http:///some-random-file wget did received some series of packets, with pauses in-between, but overal the progress looks like it is stalled completely, there's almost no progress. This is 3.16.3 kernel. Note that reloading module after resume is not sufficient (I'll try reloading whole brcm stack). Thank you for your interest! /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
21.09.2014 19:30, Michael Tokarev wrote: > Namely, after resume, the card does not work. ARP works, ping and > DNS sometimes/somewhat work, inital TCP connection establisment > works, but eg http download does not work, it stalls almost > immediately. It does not work at all anymore again. Not only after resume but also after could power up, it stalls right at start of wget for example. > http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this > is a trace collected after resuming from suspend-to-disk And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz is another trace, after insmod brcmutils & brcmsmac, starting trace-cmd record (with network-manager running in the background), and running a wget on http://ip-add-ress-of-the-access-point/somefile (which immediately stalls, showing minimal progress once in a while only). Hopefully this will help to find the problem. And for the record, I'm _again_ without the wifi network. But unlike of the previous situation, I can at least buy some other, better supported wifi adapter now, because this laptop does not have a bios lock (is 6235ANHMW any good?) Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/23/14 12:04, Michael Tokarev wrote: 21.09.2014 19:30, Michael Tokarev wrote: Namely, after resume, the card does not work. ARP works, ping and DNS sometimes/somewhat work, inital TCP connection establisment works, but eg http download does not work, it stalls almost immediately. It does not work at all anymore again. Not only after resume but also after could power up, it stalls right at start of wget for example. http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this is a trace collected after resuming from suspend-to-disk And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz is another trace, after insmod brcmutils& brcmsmac, starting trace-cmd record (with network-manager running in the background), and running a wget on http://ip-add-ress-of-the-access-point/somefile (which immediately stalls, showing minimal progress once in a while only). Well. This log and the one from a few days ago only show me interrupt status changes, which does not tell me a lot. I do see that the hardware signals transmit completions, but it is far less informative then I hoped it would be. Maybe I am missing some debug configuration here? Seth, would you know? Regards, Arend Hopefully this will help to find the problem. And for the record, I'm _again_ without the wifi network. But unlike of the previous situation, I can at least buy some other, better supported wifi adapter now, because this laptop does not have a bios lock (is 6235ANHMW any good?) Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Tue, Sep 23, 2014 at 02:47:45PM +0200, Arend van Spriel wrote: > On 09/23/14 12:04, Michael Tokarev wrote: > >21.09.2014 19:30, Michael Tokarev wrote: > >>Namely, after resume, the card does not work. ARP works, ping and > >>DNS sometimes/somewhat work, inital TCP connection establisment > >>works, but eg http download does not work, it stalls almost > >>immediately. > > > >It does not work at all anymore again. Not only after resume but also > >after could power up, it stalls right at start of wget for example. > > > >>http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this > >>is a trace collected after resuming from suspend-to-disk > > > >And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz > >is another trace, after insmod brcmutils& brcmsmac, starting trace-cmd > >record > >(with network-manager running in the background), and running a wget on > >http://ip-add-ress-of-the-access-point/somefile (which immediately stalls, > >showing minimal progress once in a while only). > > Well. This log and the one from a few days ago only show me > interrupt status changes, which does not tell me a lot. I do see > that the hardware signals transmit completions, but it is far less > informative then I hoped it would be. Maybe I am missing some debug > configuration here? > > Seth, would you know? Well, there are a few different trace events defined for brcmsmac. This would enable the full set: $ trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg It's been quite some time since I used them, but I think brcmsmac_tx is quite noisy so you may only want to enable that if you already suspect a tx problem. I always find it useful to enable the mac80211 and mac80211_msg events too when debugging wireless, and I often enable cfg80211 events as well (none of these are especially verbose). Of course all of this depends on having the right config options selected. Looks like the relevant options are CONFIG_BRCM_TRACING and CONFIG_MAC80211_MESSAGE_TRACING. Seth -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/23/14 15:44, Seth Forshee wrote: On Tue, Sep 23, 2014 at 02:47:45PM +0200, Arend van Spriel wrote: On 09/23/14 12:04, Michael Tokarev wrote: 21.09.2014 19:30, Michael Tokarev wrote: Namely, after resume, the card does not work. ARP works, ping and DNS sometimes/somewhat work, inital TCP connection establisment works, but eg http download does not work, it stalls almost immediately. It does not work at all anymore again. Not only after resume but also after could power up, it stalls right at start of wget for example. http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this is a trace collected after resuming from suspend-to-disk And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz is another trace, after insmod brcmutils& brcmsmac, starting trace-cmd record (with network-manager running in the background), and running a wget on http://ip-add-ress-of-the-access-point/somefile (which immediately stalls, showing minimal progress once in a while only). Well. This log and the one from a few days ago only show me interrupt status changes, which does not tell me a lot. I do see that the hardware signals transmit completions, but it is far less informative then I hoped it would be. Maybe I am missing some debug configuration here? Seth, would you know? Well, there are a few different trace events defined for brcmsmac. This would enable the full set: $ trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg It's been quite some time since I used them, but I think brcmsmac_tx is quite noisy so you may only want to enable that if you already suspect a tx problem. I always find it useful to enable the mac80211 and mac80211_msg events too when debugging wireless, and I often enable cfg80211 events as well (none of these are especially verbose). Ah, I read back the email from Sep 21 and it says: trace-cmd record brcmsmac:* & I am surprised the capture contains something as -e is missing. Good to know there are different tracers for the driver. Regards, Arend Of course all of this depends on having the right config options selected. Looks like the relevant options are CONFIG_BRCM_TRACING and CONFIG_MAC80211_MESSAGE_TRACING. Seth -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
23.09.2014 17:50, Arend van Spriel wrote: > On 09/23/14 15:44, Seth Forshee wrote: [] >> Well, there are a few different trace events defined for brcmsmac. This >> would enable the full set: >> >> $ trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg >> >> It's been quite some time since I used them, but I think brcmsmac_tx is >> quite noisy so you may only want to enable that if you already suspect a >> tx problem. I always find it useful to enable the mac80211 and >> mac80211_msg events too when debugging wireless, and I often enable >> cfg80211 events as well (none of these are especially verbose). > > Ah, I read back the email from Sep 21 and it says: > > trace-cmd record brcmsmac:* & > > I am surprised the capture contains something as -e is missing. Good to know > there are different tracers for the driver. > >> Of course all of this depends on having the right config options >> selected. Looks like the relevant options are CONFIG_BRCM_TRACING and >> CONFIG_MAC80211_MESSAGE_TRACING. So, what should I enable? I guess there's a suspection of tx path problem (since according to tcpdump, the other side sends packets our way, but our side does not receive them), so -e brcmsmac_tx shold be okay to enable (and should be easy to filter out if needed, too, I guess). And using -e, now too, like this: trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg -e mac80211 -e mac80211 -e cfg80211 http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409232.dat.gz is the result from the following: modprobe brcmsmac (networkmanager is running) trace-cmd as above & wget http://ip-add-ress/random-file -O /dev/null I waited for wget to stall (it d'loaded 240Kb) and hit Ctrl+C. The trace file isn't really that huge. Thank you! /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
23.09.2014 18:25, Michael Tokarev wrote: > 23.09.2014 17:50, Arend van Spriel wrote: >> On 09/23/14 15:44, Seth Forshee wrote: [] >>> It's been quite some time since I used them, but I think brcmsmac_tx is >>> quite noisy so you may only want to enable that if you already suspect a >>> tx problem. I always find it useful to enable the mac80211 and >>> mac80211_msg events too when debugging wireless, and I often enable >>> cfg80211 events as well (none of these are especially verbose). mac80211_msg does not exist, it looks like. fwiw. /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote: > 23.09.2014 18:25, Michael Tokarev wrote: > > 23.09.2014 17:50, Arend van Spriel wrote: > >> On 09/23/14 15:44, Seth Forshee wrote: > [] > >>> It's been quite some time since I used them, but I think brcmsmac_tx is > >>> quite noisy so you may only want to enable that if you already suspect a > >>> tx problem. I always find it useful to enable the mac80211 and > >>> mac80211_msg events too when debugging wireless, and I often enable > >>> cfg80211 events as well (none of these are especially verbose). > > mac80211_msg does not exist, it looks like. fwiw. Did you check your kernel's config? You need to have CONFIG_MAC80211_MESSAGE_TRACING enabled. Seth -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
23.09.2014 18:31, Seth Forshee пишет: > On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote: >> 23.09.2014 18:25, Michael Tokarev wrote: >>> 23.09.2014 17:50, Arend van Spriel wrote: On 09/23/14 15:44, Seth Forshee wrote: >> [] > It's been quite some time since I used them, but I think brcmsmac_tx is > quite noisy so you may only want to enable that if you already suspect a > tx problem. I always find it useful to enable the mac80211 and > mac80211_msg events too when debugging wireless, and I often enable > cfg80211 events as well (none of these are especially verbose). >> >> mac80211_msg does not exist, it looks like. fwiw. > > Did you check your kernel's config? You need to have > CONFIG_MAC80211_MESSAGE_TRACING enabled. Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless, but not net/. Rebuilt, another trace is here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/23/14 18:02, Michael Tokarev wrote: 23.09.2014 18:31, Seth Forshee пишет: On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote: 23.09.2014 18:25, Michael Tokarev wrote: 23.09.2014 17:50, Arend van Spriel wrote: On 09/23/14 15:44, Seth Forshee wrote: [] It's been quite some time since I used them, but I think brcmsmac_tx is quite noisy so you may only want to enable that if you already suspect a tx problem. I always find it useful to enable the mac80211 and mac80211_msg events too when debugging wireless, and I often enable cfg80211 events as well (none of these are especially verbose). mac80211_msg does not exist, it looks like. fwiw. Did you check your kernel's config? You need to have CONFIG_MAC80211_MESSAGE_TRACING enabled. Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless, but not net/. Rebuilt, another trace is here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz Thanks, Just to confirm. With this trace you also get a stall during wget? Regards, Arend /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
23.09.2014 21:35, Arend van Spriel wrote: > On 09/23/14 18:02, Michael Tokarev wrote: >> Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless, >> but not net/. Rebuilt, another trace is here -- >> >> http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz >> >> Thanks, > > Just to confirm. With this trace you also get a stall during wget? Yes. Initially it started d/loading but some time later the d/load speed reduced to 0. It is possible to wait further, and after some more time it will receive some more bytes/kilobytes/packets and stall again. Overall progress is nearing zero. Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/23/14 20:10, Michael Tokarev wrote: 23.09.2014 21:35, Arend van Spriel wrote: On 09/23/14 18:02, Michael Tokarev wrote: Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless, but not net/. Rebuilt, another trace is here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz Thanks, Just to confirm. With this trace you also get a stall during wget? Yes. Initially it started d/loading but some time later the d/load speed reduced to 0. It is possible to wait further, and after some more time it will receive some more bytes/kilobytes/packets and stall again. Overall progress is nearing zero. I looked at the log. I see download commence because the packets received of 1562 bytes length. So within one second I see little over 200 packets so approx. 3Mbps which is not impressive but I don't know what can be expected. Indeed after that it stalls and we only seem to receive small packets of 179 bytes that seem to end up in cfg80211_mgmt_rx. It could be that the hardware is somehow bogged and can not receive at higher modulations as management frames are transmitted at lower rates. The hardware will drop packets that are having FCS (aka. checksum) errors. The brcmsmac is missing some code to read fcs error count from hardware, but I will get back to you with a patch that we can use to confirm this. Regards, Arend Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
>I looked at the log. I see download commence because the packets >received of 1562 bytes length. So within one second I see little over >200 packets so approx. 3Mbps which is not impressive but I don't know >what can be expected. When it works it goes 50+ Mbps. I always tested at the same place and the signal there is good. D/load speed is 11Mb/sec steady. When it works. Today after powercycle it worked fine at 11 megabytes per second, I transferred several gigs of data. > Indeed after that it stalls and we only seem to >receive small packets of 179 bytes that seem to end up in >cfg80211_mgmt_rx. It could be that the hardware is somehow bogged and >can not receive at higher modulations as management frames are >transmitted at lower rates. The hardware will drop packets that are >having FCS (aka. checksum) errors. The brcmsmac is missing some code to > >read fcs error count from hardware, but I will get back to you with a >patch that we can use to confirm this. I see. Today I ordered an intel wifi card (which also works at 5MHz) and will swap bcm4313 with it. Since the notebook has to be disassembled for this (it doesn't have separate window for wifi card), and the procedure is rather complex I don't want to do it more times than necessary... ;) Thanks! /mjt from android phone -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
Okay, so finally, today, without any updates from your side, I opened up the laptop again and inserted a newly bought Intel 6235ANHMW card instead of this creaky brcm4313. This card works right out of the box - plug it in and set up, both wifi and bluetooth (I had numerous probs with bluetooth too with brcm card), and it works on both 2.4GHz and 5GHz bands. Connection is very good and stable, I wasn't able to trigger a single glitch no matter how hard I tried. My only sorry is a lot of wasted time, efforts and money - all that have much better value than trying to deal with non-working drivers. And my only wish is so vendors stop using non-working parts in their hardware.. But oh well. Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/26/14 16:26, Michael Tokarev wrote: Okay, so finally, today, without any updates from your side, I opened up the laptop again and inserted a newly bought Intel 6235ANHMW card instead of this creaky brcm4313. This card works right out of the box - plug it in and set up, both wifi and bluetooth (I had numerous probs with bluetooth too with brcm card), and it works on both 2.4GHz and 5GHz bands. Connection is very good and stable, I wasn't able to trigger a single glitch no matter how hard I tried. Good for you. My only sorry is a lot of wasted time, efforts and money - all that have much better value than trying to deal with non-working drivers. And my only wish is so vendors stop using non-working parts in their hardware.. But oh well. Being bold here, but would you be willing to send that non-working part of hardware to me. I seem to have 4313 cards over here that just work and it would help greatly investigating the issue. I guess you do not care that much anymore, but might be others do (myself included). 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
26.09.2014 18:42, Arend van Spriel wrote: > Being bold here, but would you be willing to send that non-working part of > hardware to me. I seem to have 4313 cards over here that just work and it > would help greatly investigating the issue. I guess you do not care that much > anymore, but might be others do (myself included). Please note that this is 2nd card of the same model which I come across in different laptops (one lenovo which I bought last December, and later in a HP Envy which I borrowed from my friend because my lenovo didn't work anymore). Both shows exactly the same sympthoms, on several different WiFi networks. The sympthoms are rehashed here several times -- sporaric stalls of different frequence of occurences, which can be cured by re-loading the driver. I can send it your way, -- guess it will be quite a bit costly, but I don't have any use for it anyway (short of throwing it away), and since I already spent significantly more money due to all this (whole thinkpad plus ssds and several wifi adaptors), this additional cost is just a small noize. But since that's 2nd card in a row, maybe there's something else in there, the prob is not in the card? I mentioned several times that here, both of these cards worked for long periods of time and for many gigabytes transfers (I used wget in a loop overnight), -- and worked very well. Just that these "working periods" changes into "non-working periods" without any clear cause, sporadically. And these working periods can be rather long, too. Maybe this is some uninitialized field somewhere, I dunno - at least that'd explain the "mystery" and inability to reproduce any of the two kinds of "periods". Ofcourse it's rather difficult to debug, but it might not be card-specific. I also noticed that quite often it does not work after rebooing the laptop from windows. But not always. I thought maybe win switches it into some mode which linux driver fails to notice, but no, the fact that it sometimes works after windows tells me that I'm not right. And note please that the closed-source wl driver always worked with both of these cards, at least when I was able to compile it (the prob is always the same - no support for more recent kernels; and I don't really like to use recent kernels (I myself currently stay with 3.10.x stable line), but both laptops actually requires recent kernels to work properly (either because of great energy saving support in latest intel cpus, or because of support of gpu in latest intel celerons) -- that's why I really prefer in-kernel driver). That to say - the fact that wl always works may tell that the hw is fine and the prob is elsewhere. Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/26/14 17:20, Michael Tokarev wrote: I can send it your way, -- guess it will be quite a bit costly, but I don't have any use for it anyway (short of throwing it away), and since I already spent significantly more money due to all this (whole thinkpad plus ssds and several wifi adaptors), this additional cost is just a small noize. But since that's 2nd card in a row, maybe there's something else in there, the prob is not in the card? Could be. Maybe some BIOS issue. Can you make some hi-res pictures of the card and email them to me? If it is identical to what I already have over here there is not much sense in sending it. 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Monday 29 September 2014 15:44:03 Arend van Spriel wrote: > On 09/26/14 17:20, Michael Tokarev wrote: > > I can send it your way, -- guess it will be quite a bit costly, > > but I don't have any use for it anyway (short of throwing it > > away), and since I already spent significantly more money due > > to all this (whole thinkpad plus ssds and several wifi adaptors), > > this additional cost is just a small noize. But since that's > > 2nd card in a row, maybe there's something else in there, the > > prob is not in the card? > > Could be. Maybe some BIOS issue. Can you make some hi-res pictures of > the card and email them to me? If it is identical to what I already have > over here there is not much sense in sending it. > > Regards, > Arend Hi Arend, I just saw this thread on linux-wireless and wanted to answer as it might be of interest to you. I also own a BCM4313 wireless network card. About a year ago I reported some problems with reception strength which were then fixed after some time, debugging and testing passed. At that time I also did some throughput testing, but only had a 802.11g access-point to test. The results were not ideal, but also not too bad. So at that time I thought the issues were all more or less fixed and mostly fine. I also don't use wireless very much, so as long as things do work somehow acceptable I probably don't notice any problems immediately. So it comes that only about some month ago I noticed that the throughput I measured with my 11g access-point (about half the rate than with an atheros card on the same ap) is about the same on a 11n access-point where it should be much faster. I didn't experience any stalls, but that may also be that I didn't use the card enough to really notice them. I always wanted to report a bug because of the low throughout, but never got to it because of lack of time. I didn't want to provide a report saying just it doesn't work or it's slow without any data about it and a description how to reproduce it, as I think without this information a bug report is mostly useless. I also had a look at the kernel changelog of the brcmsm driver and notices there was little to no activity lately. Because of this I also wasn't sure if there is still someone interesting in fixing bugs for this device. As I was annoyed by the bad support for this card I decided it would be more easy and much less time consuming to simply buy another card than trying to get this fixed. So I bought a BCM43228 card, because it also supports 5 GHz. Only after it arrived I noticed that it was only supported by the 3.17+ kernel (not so much of a problem) and that it only seems to work in 802.11g mode (only slow speeds and no 5 GHz). At least I could use it in full 11g speeds, so it was a improvement. So I still don't have a card that does simply work. As I hope the missing support for my BCM43228 will hopefully be added some time in the future it probably would still be worth fixing the BCM4313 card as other users will also benefit from it. A friend of mine also has the same laptop than me and the same (or at least very similar) wireless card. He has told me he has also problem with stalls like Michael reported (if I remember the history of the thread correctly). So I'm not really sure where I should go from here. I can try to provide some debugging information as time permits, but I don't know how much time I will have for this in the future. Of course ideally I want to use the BCM43228 card with full support, as it can work on 5 GHz. Currently the BCM43228 card is plugged into my laptop, but I want to avoid swapping the cards more that very few times because the antenna connectors are only designed for very few (un)plug cycles. If it's of any information, my card is labeled BCM-BCM94313HMGB on the sticker, the laptop where it was originally is a ThinkPad Edge E135. Greetings, Maxi signature.asc Description: This is a digitally signed message part.
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 09/29/14 21:40, Maximilian Engelhardt wrote: On Monday 29 September 2014 15:44:03 Arend van Spriel wrote: On 09/26/14 17:20, Michael Tokarev wrote: I can send it your way, -- guess it will be quite a bit costly, but I don't have any use for it anyway (short of throwing it away), and since I already spent significantly more money due to all this (whole thinkpad plus ssds and several wifi adaptors), this additional cost is just a small noize. But since that's 2nd card in a row, maybe there's something else in there, the prob is not in the card? Could be. Maybe some BIOS issue. Can you make some hi-res pictures of the card and email them to me? If it is identical to what I already have over here there is not much sense in sending it. Regards, Arend Hi Arend, I just saw this thread on linux-wireless and wanted to answer as it might be of interest to you. I also own a BCM4313 wireless network card. About a year ago I reported some problems with reception strength which were then fixed after some time, debugging and testing passed. At that time I also did some throughput testing, but only had a 802.11g access-point to test. The results were not ideal, but also not too bad. So at that time I thought the issues were all more or less fixed and mostly fine. I also don't use wireless very much, so as long as things do work somehow acceptable I probably don't notice any problems immediately. So it comes that only about some month ago I noticed that the throughput I measured with my 11g access-point (about half the rate than with an atheros card on the same ap) is about the same on a 11n access-point where it should be much faster. I didn't experience any stalls, but that may also be that I didn't use the card enough to really notice them. I always wanted to report a bug because of the low throughout, but never got to it because of lack of time. I didn't want to provide a report saying just it doesn't work or it's slow without any data about it and a description how to reproduce it, as I think without this information a bug report is mostly useless. I also had a look at the kernel changelog of the brcmsm driver and notices there was little to no activity lately. Because of this I also wasn't sure if there is still someone interesting in fixing bugs for this device. As I was annoyed by the bad support for this card I decided it would be more easy and much less time consuming to simply buy another card than trying to get this fixed. So I bought a BCM43228 card, because it also supports 5 GHz. Only after it arrived I noticed that it was only supported by the 3.17+ kernel (not so much of a problem) and that it only seems to work in 802.11g mode (only slow speeds and no 5 GHz). At least I could use it in full 11g speeds, so it was a improvement. So I still don't have a card that does simply work. As I hope the missing support for my BCM43228 will hopefully be added some time in the future it probably would still be worth fixing the BCM4313 card as other users will also benefit from it. A friend of mine also has the same laptop than me and the same (or at least very similar) wireless card. He has told me he has also problem with stalls like Michael reported (if I remember the history of the thread correctly). So I'm not really sure where I should go from here. I can try to provide some debugging information as time permits, but I don't know how much time I will have for this in the future. Of course ideally I want to use the BCM43228 card with full support, as it can work on 5 GHz. Currently the BCM43228 card is plugged into my laptop, but I want to avoid swapping the cards more that very few times because the antenna connectors are only designed for very few (un)plug cycles. If it's of any information, my card is labeled BCM-BCM94313HMGB on the sticker, the laptop where it was originally is a ThinkPad Edge E135. Thanks for taking time to chime in. This chipset is a pain in the The label info does help. You have a 4313 with internal PA for which support was added later. The card that Michael has seems to have an external PA. The initial iPA support patch broke things for everyone with external PA so it was reverted. In the second round it was better, but it seems Michael still had issues. As he mentioned BT issues and his card shares the external PA between WLAN and BT I believe that there is a BT-coex issue. What is causing your 4313 to seemingly do 11g rates is hard to tell without any debug info. I have that card over here, but in my cabled setup it is doing 72Mbps, ie. 11n rate. I can run a rate-vs-range test to see if there is an issue. Thanks again and 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Tuesday 30 September 2014 12:06:10 Arend van Spriel wrote: > On 09/29/14 21:40, Maximilian Engelhardt wrote: > > On Monday 29 September 2014 15:44:03 Arend van Spriel wrote: > >> On 09/26/14 17:20, Michael Tokarev wrote: > >>> I can send it your way, -- guess it will be quite a bit costly, > >>> but I don't have any use for it anyway (short of throwing it > >>> away), and since I already spent significantly more money due > >>> to all this (whole thinkpad plus ssds and several wifi adaptors), > >>> this additional cost is just a small noize. But since that's > >>> 2nd card in a row, maybe there's something else in there, the > >>> prob is not in the card? > >> > >> Could be. Maybe some BIOS issue. Can you make some hi-res pictures of > >> the card and email them to me? If it is identical to what I already have > >> over here there is not much sense in sending it. > >> > >> Regards, > >> Arend > > > > Hi Arend, > > > > I just saw this thread on linux-wireless and wanted to answer as it might > > be of interest to you. > > > > I also own a BCM4313 wireless network card. About a year ago I reported > > some problems with reception strength which were then fixed after some > > time, debugging and testing passed. At that time I also did some > > throughput testing, but only had a 802.11g access-point to test. The > > results were not ideal, but also not too bad. So at that time I thought > > the issues were all more or less fixed and mostly fine. I also don't use > > wireless very much, so as long as things do work somehow acceptable I > > probably don't notice any problems immediately. So it comes that only > > about some month ago I noticed that the throughput I measured with my 11g > > access-point (about half the rate than with an atheros card on the same > > ap) is about the same on a 11n access-point where it should be much > > faster. I didn't experience any stalls, but that may also be that I > > didn't use the card enough to really notice them. > > > > I always wanted to report a bug because of the low throughout, but never > > got to it because of lack of time. I didn't want to provide a report > > saying just it doesn't work or it's slow without any data about it and a > > description how to reproduce it, as I think without this information a > > bug report is mostly useless. > > > > I also had a look at the kernel changelog of the brcmsm driver and notices > > there was little to no activity lately. Because of this I also wasn't sure > > if there is still someone interesting in fixing bugs for this device. > > > > As I was annoyed by the bad support for this card I decided it would be > > more easy and much less time consuming to simply buy another card than > > trying to get this fixed. So I bought a BCM43228 card, because it also > > supports 5 GHz. Only after it arrived I noticed that it was only > > supported by the 3.17+ kernel (not so much of a problem) and that it only > > seems to work in 802.11g mode (only slow speeds and no 5 GHz). At least I > > could use it in full 11g speeds, so it was a improvement. > > > > So I still don't have a card that does simply work. As I hope the missing > > support for my BCM43228 will hopefully be added some time in the future it > > probably would still be worth fixing the BCM4313 card as other users will > > also benefit from it. > > > > A friend of mine also has the same laptop than me and the same (or at > > least > > very similar) wireless card. He has told me he has also problem with > > stalls > > like Michael reported (if I remember the history of the thread correctly). > > > > So I'm not really sure where I should go from here. I can try to provide > > some debugging information as time permits, but I don't know how much > > time I will have for this in the future. Of course ideally I want to use > > the BCM43228 card with full support, as it can work on 5 GHz. > > > > Currently the BCM43228 card is plugged into my laptop, but I want to avoid > > swapping the cards more that very few times because the antenna connectors > > are only designed for very few (un)plug cycles. > > > > If it's of any information, my card is labeled BCM-BCM94313HMGB on the > > sticker, the laptop where it was originally is a ThinkPad Edge E135. > > Thanks for taking time to chime in. This chipset is a pain in the > The label info does help. You have a 4313 with internal PA for which > support was added later. The card that Michael has seems to have an > external PA. The initial iPA support patch broke things for everyone > with external PA so it was reverted. In the second round it was better, > but it seems Michael still had issues. As he mentioned BT issues and his > card shares the external PA between WLAN and BT I believe that there is > a BT-coex issue. > > What is causing your 4313 to seemingly do 11g rates is hard to tell > without any debug info. I have that card over here, but in my cabled > setup it is doing 72Mbps, ie. 11n rate. I can run a
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 10/09/14 00:19, Maximilian Engelhardt wrote: On Tuesday 30 September 2014 12:06:10 Arend van Spriel wrote: On 09/29/14 21:40, Maximilian Engelhardt wrote: On Monday 29 September 2014 15:44:03 Arend van Spriel wrote: On 09/26/14 17:20, Michael Tokarev wrote: I can send it your way, -- guess it will be quite a bit costly, but I don't have any use for it anyway (short of throwing it away), and since I already spent significantly more money due to all this (whole thinkpad plus ssds and several wifi adaptors), this additional cost is just a small noize. But since that's 2nd card in a row, maybe there's something else in there, the prob is not in the card? Could be. Maybe some BIOS issue. Can you make some hi-res pictures of the card and email them to me? If it is identical to what I already have over here there is not much sense in sending it. Regards, Arend Hi Arend, I just saw this thread on linux-wireless and wanted to answer as it might be of interest to you. I also own a BCM4313 wireless network card. About a year ago I reported some problems with reception strength which were then fixed after some time, debugging and testing passed. At that time I also did some throughput testing, but only had a 802.11g access-point to test. The results were not ideal, but also not too bad. So at that time I thought the issues were all more or less fixed and mostly fine. I also don't use wireless very much, so as long as things do work somehow acceptable I probably don't notice any problems immediately. So it comes that only about some month ago I noticed that the throughput I measured with my 11g access-point (about half the rate than with an atheros card on the same ap) is about the same on a 11n access-point where it should be much faster. I didn't experience any stalls, but that may also be that I didn't use the card enough to really notice them. I always wanted to report a bug because of the low throughout, but never got to it because of lack of time. I didn't want to provide a report saying just it doesn't work or it's slow without any data about it and a description how to reproduce it, as I think without this information a bug report is mostly useless. I also had a look at the kernel changelog of the brcmsm driver and notices there was little to no activity lately. Because of this I also wasn't sure if there is still someone interesting in fixing bugs for this device. As I was annoyed by the bad support for this card I decided it would be more easy and much less time consuming to simply buy another card than trying to get this fixed. So I bought a BCM43228 card, because it also supports 5 GHz. Only after it arrived I noticed that it was only supported by the 3.17+ kernel (not so much of a problem) and that it only seems to work in 802.11g mode (only slow speeds and no 5 GHz). At least I could use it in full 11g speeds, so it was a improvement. So I still don't have a card that does simply work. As I hope the missing support for my BCM43228 will hopefully be added some time in the future it probably would still be worth fixing the BCM4313 card as other users will also benefit from it. A friend of mine also has the same laptop than me and the same (or at least very similar) wireless card. He has told me he has also problem with stalls like Michael reported (if I remember the history of the thread correctly). So I'm not really sure where I should go from here. I can try to provide some debugging information as time permits, but I don't know how much time I will have for this in the future. Of course ideally I want to use the BCM43228 card with full support, as it can work on 5 GHz. Currently the BCM43228 card is plugged into my laptop, but I want to avoid swapping the cards more that very few times because the antenna connectors are only designed for very few (un)plug cycles. If it's of any information, my card is labeled BCM-BCM94313HMGB on the sticker, the laptop where it was originally is a ThinkPad Edge E135. Thanks for taking time to chime in. This chipset is a pain in the The label info does help. You have a 4313 with internal PA for which support was added later. The card that Michael has seems to have an external PA. The initial iPA support patch broke things for everyone with external PA so it was reverted. In the second round it was better, but it seems Michael still had issues. As he mentioned BT issues and his card shares the external PA between WLAN and BT I believe that there is a BT-coex issue. What is causing your 4313 to seemingly do 11g rates is hard to tell without any debug info. I have that card over here, but in my cabled setup it is doing 72Mbps, ie. 11n rate. I can run a rate-vs-range test to see if there is an issue. Thanks again and Regards, Arend Hi Arend, Today I changed back to the BC4313 card to verify the speed is still slow. At first it was slow as I remembered it (down about 3 Mbits/s, up about 1 Mbit/s, measured with iperf). I then booted an Ubuntu
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 9 October 2014 09:52, Arend van Spriel wrote:
> I have been staring at differences brcmsmac and our internal driver (which
> wl is derived from as well). Would you be able to make an mmiotrace loading
> wl and brcmsmac.
Arend,
As you noticed earlier, this is a WiFi card with BT. I've checked
siutils.c from SDK 7.14.43.7 (got it from Netgear R8000) and it has
three BCM4313 workarounds:
1) si_doattach
SI_MSG(("Applying 4313 WARs\n"));
si_pmu_chipcontrol(sih, 0, CCTRL_4313_12MA_LED_DRIVE,
CCTRL_4313_12MA_LED_DRIVE);
It's already implemented in bcma, see driver_chipcommon_pmu.c
2) si_epa_4313war
/* EPA Fix */
W_REG(sii->osh, &cc->gpiocontrol,
R_REG(sii->osh, &cc->gpiocontrol) | GPIO_CTRL_EPA_EN_MASK);
This is what you already implement in ai_epa_4313war
3) si_pmu_synth_pwrsw_4313_war
I don't think it's implemented.
4) si_btcombo_p250_4313_war
I also don't think it's implemented
The last one (si_btcombo_p250_4313_war) looks promising, the comment
above the function says:
/** WL/BT control for 4313 btcombo boards >= P250 */
I guess you need to re-implement this function and call it somewhere
in brcmsmac.
--
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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Thursday 09 October 2014 10:21:12 Rafał Miłecki wrote:
> On 9 October 2014 09:52, Arend van Spriel wrote:
> > I have been staring at differences brcmsmac and our internal driver (which
> > wl is derived from as well). Would you be able to make an mmiotrace
> > loading
> > wl and brcmsmac.
>
> Arend,
>
> As you noticed earlier, this is a WiFi card with BT. I've checked
> siutils.c from SDK 7.14.43.7 (got it from Netgear R8000) and it has
> three BCM4313 workarounds:
>
>
> 1) si_doattach
> SI_MSG(("Applying 4313 WARs\n"));
> si_pmu_chipcontrol(sih, 0, CCTRL_4313_12MA_LED_DRIVE,
> CCTRL_4313_12MA_LED_DRIVE);
>
> It's already implemented in bcma, see driver_chipcommon_pmu.c
>
>
> 2) si_epa_4313war
> /* EPA Fix */
> W_REG(sii->osh, &cc->gpiocontrol,
> R_REG(sii->osh, &cc->gpiocontrol) | GPIO_CTRL_EPA_EN_MASK);
>
> This is what you already implement in ai_epa_4313war
>
>
> 3) si_pmu_synth_pwrsw_4313_war
> I don't think it's implemented.
>
>
> 4) si_btcombo_p250_4313_war
> I also don't think it's implemented
>
>
> The last one (si_btcombo_p250_4313_war) looks promising, the comment
> above the function says:
> /** WL/BT control for 4313 btcombo boards >= P250 */
> I guess you need to re-implement this function and call it somewhere
> in brcmsmac.
Hi,
I just wanted to ask if there is any progress on this issue since I haven't
heard anything for a month. Please let me know if you need any additional
information.
Greetings,
Maxi
signature.asc
Description: This is a digitally signed message part.
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
18.11.2014 01:36, Maximilian Engelhardt wrote: [] > I just wanted to ask if there is any progress on this issue since I haven't > heard anything for a month. Please let me know if you need any additional > information. I've no idea if there's any progress. Meanwhile I've an easy way of testing of my brcm4313 card in a mini-itx board with mini-PCIe slot. It works rather nicely and the stalls are easy to trigger. Running 3.16 kernel right now, tried to d/load a file from the AP, -- boom, it stalled after 77Kb. Since the previous discussion apparently ended prematurely and no patches to try emerged, I don't have anything to try on it... Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 11/17/14 23:36, Maximilian Engelhardt wrote:
On Thursday 09 October 2014 10:21:12 Rafał Miłecki wrote:
On 9 October 2014 09:52, Arend van Spriel wrote:
I have been staring at differences brcmsmac and our internal driver (which
wl is derived from as well). Would you be able to make an mmiotrace
loading
wl and brcmsmac.
Arend,
As you noticed earlier, this is a WiFi card with BT. I've checked
siutils.c from SDK 7.14.43.7 (got it from Netgear R8000) and it has
three BCM4313 workarounds:
1) si_doattach
SI_MSG(("Applying 4313 WARs\n"));
si_pmu_chipcontrol(sih, 0, CCTRL_4313_12MA_LED_DRIVE,
CCTRL_4313_12MA_LED_DRIVE);
It's already implemented in bcma, see driver_chipcommon_pmu.c
2) si_epa_4313war
/* EPA Fix */
W_REG(sii->osh,&cc->gpiocontrol,
R_REG(sii->osh,&cc->gpiocontrol) | GPIO_CTRL_EPA_EN_MASK);
This is what you already implement in ai_epa_4313war
3) si_pmu_synth_pwrsw_4313_war
I don't think it's implemented.
4) si_btcombo_p250_4313_war
I also don't think it's implemented
The last one (si_btcombo_p250_4313_war) looks promising, the comment
above the function says:
/** WL/BT control for 4313 btcombo boards>= P250 */
I guess you need to re-implement this function and call it somewhere
in brcmsmac.
Hi,
I just wanted to ask if there is any progress on this issue since I haven't
heard anything for a month. Please let me know if you need any additional
information.
I had a bit of problem with the mmiotrace files. Well, my (virtual)
linux machine had as it ended up swapping on my disk and went down the
drain.
I still wanted to look at items 3) and 4) that Rafal mentioned although
item 4) does not seems to apply to Michael's 4313 it may help yours. I
submitted a patch to get counter statistics from the 802.11 core on the
chip [1] as I am curious whether that will show a possible lead.
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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 11/19/14 14:46, Arend van Spriel wrote:
On 11/17/14 23:36, Maximilian Engelhardt wrote:
On Thursday 09 October 2014 10:21:12 Rafał Miłecki wrote:
On 9 October 2014 09:52, Arend van Spriel wrote:
I have been staring at differences brcmsmac and our internal driver
(which
wl is derived from as well). Would you be able to make an mmiotrace
loading
wl and brcmsmac.
Arend,
As you noticed earlier, this is a WiFi card with BT. I've checked
siutils.c from SDK 7.14.43.7 (got it from Netgear R8000) and it has
three BCM4313 workarounds:
1) si_doattach
SI_MSG(("Applying 4313 WARs\n"));
si_pmu_chipcontrol(sih, 0, CCTRL_4313_12MA_LED_DRIVE,
CCTRL_4313_12MA_LED_DRIVE);
It's already implemented in bcma, see driver_chipcommon_pmu.c
2) si_epa_4313war
/* EPA Fix */
W_REG(sii->osh,&cc->gpiocontrol,
R_REG(sii->osh,&cc->gpiocontrol) | GPIO_CTRL_EPA_EN_MASK);
This is what you already implement in ai_epa_4313war
3) si_pmu_synth_pwrsw_4313_war
I don't think it's implemented.
4) si_btcombo_p250_4313_war
I also don't think it's implemented
The last one (si_btcombo_p250_4313_war) looks promising, the comment
above the function says:
/** WL/BT control for 4313 btcombo boards>= P250 */
I guess you need to re-implement this function and call it somewhere
in brcmsmac.
Hi,
I just wanted to ask if there is any progress on this issue since I
haven't
heard anything for a month. Please let me know if you need any additional
information.
I had a bit of problem with the mmiotrace files. Well, my (virtual)
linux machine had as it ended up swapping on my disk and went down the
drain.
I still wanted to look at items 3) and 4) that Rafal mentioned although
item 4) does not seems to apply to Michael's 4313 it may help yours. I
submitted a patch to get counter statistics from the 802.11 core on the
chip [1] as I am curious whether that will show a possible lead.
Regards,
Arend
+ links
patch [1] depends on patch [2]
[1]
https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-next.git/commit/drivers/net/wireless/brcm80211?id=3fe33c4ce
[2]
https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-next.git/commit/drivers/net/wireless/brcm80211?id=9146782b1b
--
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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 11/19/14 10:04, Michael Tokarev wrote:
18.11.2014 01:36, Maximilian Engelhardt wrote:
[]
I just wanted to ask if there is any progress on this issue since I haven't
heard anything for a month. Please let me know if you need any additional
information.
I've no idea if there's any progress. Meanwhile I've an easy way of
testing of my brcm4313 card in a mini-itx board with mini-PCIe slot.
It works rather nicely and the stalls are easy to trigger.
Running 3.16 kernel right now, tried to d/load a file from the
AP, -- boom, it stalled after 77Kb.
Since the previous discussion apparently ended prematurely and no patches
to try emerged, I don't have anything to try on it...
In our last email exchange I got the impression you switch to Intel
board and did not want to keep replacing cards for testing. Nice to hear
you have an alternative setup for this and I assume are willing to do
some testing.
I submitted two patches upstream and additionally I have attached two
other that are still under review. Could you try these patches and sent
me the content of the two debugfs files 'macstat' and 'hardware' after a
stall has occurred.
Regards,
Arend
From dbc69f9769b92f3ce115fabf880f767d6bd4c436 Mon Sep 17 00:00:00 2001
From: Arend van Spriel
Date: Thu, 13 Nov 2014 14:16:34 +0100
Subject: [PATCH 1/2] brcmutil: add helper function to format board revision
The board revision that is available in hardware can be translated
so it matches the labelling on the board. This is accomplished by
this helper function.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/brcm80211/brcmutil/utils.c | 16
drivers/net/wireless/brcm80211/include/brcmu_utils.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/net/wireless/brcm80211/brcmutil/utils.c
b/drivers/net/wireless/brcm80211/brcmutil/utils.c
index 0f7e1c7..1575a1d 100644
--- a/drivers/net/wireless/brcm80211/brcmutil/utils.c
+++ b/drivers/net/wireless/brcm80211/brcmutil/utils.c
@@ -292,4 +292,20 @@ void brcmu_dbg_hex_dump(const void *data, size_t size,
const char *fmt, ...)
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, data, size);
}
EXPORT_SYMBOL(brcmu_dbg_hex_dump);
+
+/* Produce a human-readable string for boardrev */
+char *brcmu_boardrev_str(u32 brev, char *buf)
+{
+ char c;
+
+ if (brev < 0x100) {
+ snprintf(buf, 8, "%d.%d", (brev & 0xf0) >> 4, brev & 0xf);
+ } else {
+ c = (brev & 0xf000) == 0x1000 ? 'P' : 'A';
+ snprintf(buf, 8, "%c%03x", c, brev & 0xfff);
+ }
+ return (buf);
+}
+EXPORT_SYMBOL(brcmu_boardrev_str);
+
#endif /* defined(DEBUG) */
diff --git a/drivers/net/wireless/brcm80211/include/brcmu_utils.h
b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
index 8ba445b..a043e29 100644
--- a/drivers/net/wireless/brcm80211/include/brcmu_utils.h
+++ b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
@@ -218,4 +218,6 @@ void brcmu_dbg_hex_dump(const void *data, size_t size,
const char *fmt, ...)
}
#endif
+char *brcmu_boardrev_str(u32 brev, char *buf);
+
#endif /* _BRCMU_UTILS_H_ */
--
1.9.1
From a197cf44ef058942928b48223fce9d3f112be9d0 Mon Sep 17 00:00:00 2001
From: Arend van Spriel
Date: Thu, 13 Nov 2014 14:19:49 +0100
Subject: [PATCH 2/2] brcmsmac: extend hardware info shown in debugfs
The hardware info now also include radio and phy information, which
can be helpful in debugging issues.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/brcm80211/brcmsmac/debug.c | 40 +
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/debug.c
b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
index 19740c1..c9a8b93 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/debug.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
@@ -30,6 +30,7 @@
#include "main.h"
#include "debug.h"
#include "brcms_trace_events.h"
+#include "phy/phy_int.h"
static struct dentry *root_folder;
@@ -74,20 +75,33 @@ static
int brcms_debugfs_hardware_read(struct seq_file *s, void *data)
{
struct brcms_pub *drvr = s->private;
+ struct brcms_hardware *hw = drvr->wlc->hw;
+ struct bcma_device *core = hw->d11core;
+ struct bcma_bus *bus = core->bus;
+ char boardrev[10];
- seq_printf(s, "board vendor: %x\n"
- "board type: %x\n"
- "board revision: %x\n"
- "board flags: %x\n"
- "board flags2: %x\n"
- "firmware revision: %x\n",
- drvr->wlc->hw->d11core->bus->boardinfo.vendor,
- drvr->wlc->hw->d11core->bus->boardinfo.type,
- drvr->wlc->hw->boardrev,
- drvr->wlc->hw->boardflags,
- dr
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
19.11.2014 20:54, Arend van Spriel wrote: [] > In our last email exchange I got the impression you switch to Intel board and > did not want to keep replacing cards for testing. I especially wrote that I have several days to try things out and if you'll be quick it will be possible for me to test things. You never replied before now (which is some more months later). > Nice to hear you have an alternative setup for this and I assume are > willing to do some testing. > > I submitted two patches upstream and additionally I have attached two other > that are still under review. Could you try these patches and sent me the > content of the two debugfs files 'macstat' and 'hardware' after a stall has > occurred. You didn't tell which kernel it is based on. So I tried it on 3.16, ofcourse the patches didn't apply so I hand-edited the debug printf in drivers/net/wireless/brcm80211/brcmsmac/debug.c (in 3.16 it didn't use seq_printf yet). So now I have a `hardware' file (in brcmsmac/bcma0:0/ subdir in debugfs), but not macstat. Here's the contents `hardware' one: chipnum 0x4313 chiprev 0x1 chippackage 0x8 corerev 0x18 boardid 0x1795 boardvendor 0x103c boardrev P107 boardflags 0x402201 boardflags2 0x884 ucoderev 0x262032c radiorev 0x1 phytype 0x8 phyrev 0x1 anarev 0xa nvramrev 8 Since there's no macstats, I guess it is not very useful, so before digging for too deep, I ask which kernel do you want me to try here. Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
19.11.2014 22:58, Michael Tokarev wrote: > 19.11.2014 20:54, Arend van Spriel wrote: [] >> I submitted two patches upstream and additionally I have attached two other >> that are still under review. Could you try these patches and sent me the >> content of the two debugfs files 'macstat' and 'hardware' after a stall has >> occurred. > > You didn't tell which kernel it is based on. So I tried it on 3.16, Ok, I misunderstood you apparently, -- I only tried 2 patches, while I should try all 4. So here it goes. The hardware info again: > chipnum 0x4313 > chiprev 0x1 > chippackage 0x8 > corerev 0x18 > boardid 0x1795 > boardvendor 0x103c > boardrev P107 > boardflags 0x402201 > boardflags2 0x884 > ucoderev 0x262032c > radiorev 0x1 > phytype 0x8 > phyrev 0x1 > anarev 0xa > nvramrev 8 Macstat: txallfrm: 287 txrtsfrm: 118 txctsfrm: 25 txackfrm: 60 txdnlfrm: 0 txbcnfrm: 0 txfunfl[8]: 0 0 0 0 0 0 0 0 txtplunfl: 0 txphyerr: 0 pktengrxducast: 0 pktengrxdmcast: 0 rxfrmtoolong: 330 rxfrmtooshrt: 16 rxinvmachdr: 722 rxbadfcs: 4306 rxbadplcp: 7257 rxcrsglitch: 61757 rxstrt: 6667 rxdfrmucastmbss: 41 rxmfrmucastmbss: 25 rxcfrmucast: 116 rxrtsucast: 0 rxctsucast: 59 rxackucast: 19 rxdfrmocast: 70 rxmfrmocast: 84 rxcfrmocast: 211 rxrtsocast: 3 rxctsocast: 20 rxdfrmmcast: 9 rxmfrmmcast: 1486 rxcfrmmcast: 0 rxbeaconmbss: 377 rxdfrmucastobss: 0 rxbeaconobss: 1086 rxrsptmout: 94 bcntxcancl: 0 rxf0ovfl: 0 rxf1ovfl: 0 rxf2ovfl: 0 txsfovfl: 0 pmqovfl: 0 rxcgprqfrm: 0 rxcgprsqovfl: 0 txcgprsfail: 0 txcgprssuc: 0 prs_timeout: 0 rxnack: 0 frmscons: 0 txnack: 0 txglitch_nack: 38 txburst: 4 bphy_rxcrsglitch: 2 phywatchdog: 0 bphy_badplcp: 0 As far as I can see, the stats are never updated during stall, no numbers are changing, at least while the download is waiting for the next packet. Sometimes wpa_supplicant does something little, so some stats gets updated, eg, this is how it looks like after about 2..3 minutes: txallfrm: 420 txrtsfrm: 201 txctsfrm: 25 txackfrm: 69 txdnlfrm: 0 txbcnfrm: 0 txfunfl[8]: 0 0 0 0 0 0 0 0 txtplunfl: 0 txphyerr: 0 pktengrxducast: 0 pktengrxdmcast: 0 rxfrmtoolong: 1908 rxfrmtooshrt: 73 rxinvmachdr: 4115 rxbadfcs: 15064 rxbadplcp: 42368 rxcrsglitch: 36620 rxstrt: 26393 rxdfrmucastmbss: 48 rxmfrmucastmbss: 27 rxcfrmucast: 158 rxrtsucast: 0 rxctsucast: 92 rxackucast: 25 rxdfrmocast: 113 rxmfrmocast: 390 rxcfrmocast: 962 rxrtsocast: 38 rxctsocast: 59 rxdfrmmcast: 48 rxmfrmmcast: 7681 rxcfrmmcast: 0 rxbeaconmbss: 1505 rxdfrmucastobss: 0 rxbeaconobss: 6059 rxrsptmout: 171 bcntxcancl: 0 rxf0ovfl: 0 rxf1ovfl: 0 rxf2ovfl: 0 txsfovfl: 0 pmqovfl: 0 rxcgprqfrm: 0 rxcgprsqovfl: 0 txcgprsfail: 0 txcgprssuc: 0 prs_timeout: 0 rxnack: 0 frmscons: 0 txnack: 0 txglitch_nack: 41 txburst: 4 bphy_rxcrsglitch: 5 phywatchdog: 0 bphy_badplcp: 0 This is with 3.18-tobe kernel (current Linus git). Dunno if this is helpful or not... Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 19-11-14 22:00, Michael Tokarev wrote:
> 19.11.2014 22:58, Michael Tokarev wrote:
>> 19.11.2014 20:54, Arend van Spriel wrote:
> []
>>> I submitted two patches upstream and additionally I have attached two other
>>> that are still under review. Could you try these patches and sent me the
>>> content of the two debugfs files 'macstat' and 'hardware' after a stall has
>>> occurred.
>>
>> You didn't tell which kernel it is based on. So I tried it on 3.16,
>
> Ok, I misunderstood you apparently, -- I only tried 2 patches,
> while I should try all 4. So here it goes.
>
> The hardware info again:
>
>> chipnum 0x4313
>> chiprev 0x1
>> chippackage 0x8
>> corerev 0x18
>> boardid 0x1795
>> boardvendor 0x103c
>> boardrev P107
>> boardflags 0x402201
>> boardflags2 0x884
>> ucoderev 0x262032c
>> radiorev 0x1
>> phytype 0x8
>> phyrev 0x1
>> anarev 0xa
>> nvramrev 8
>
> Macstat:
>
> txallfrm: 287
> txrtsfrm: 118
> txctsfrm: 25
> txackfrm: 60
> txdnlfrm: 0
> txbcnfrm: 0
> txfunfl[8]: 0 0 0 0 0 0 0 0
> txtplunfl: 0
> txphyerr: 0
> pktengrxducast: 0
> pktengrxdmcast: 0
> rxfrmtoolong: 330
> rxfrmtooshrt: 16
> rxinvmachdr: 722
> rxbadfcs: 4306
> rxbadplcp: 7257
> rxcrsglitch: 61757
> rxstrt: 6667
> rxdfrmucastmbss: 41
> rxmfrmucastmbss: 25
> rxcfrmucast: 116
> rxrtsucast: 0
> rxctsucast: 59
> rxackucast: 19
> rxdfrmocast: 70
> rxmfrmocast: 84
> rxcfrmocast: 211
> rxrtsocast: 3
> rxctsocast: 20
> rxdfrmmcast: 9
> rxmfrmmcast: 1486
> rxcfrmmcast: 0
> rxbeaconmbss: 377
> rxdfrmucastobss: 0
> rxbeaconobss: 1086
> rxrsptmout: 94
> bcntxcancl: 0
> rxf0ovfl: 0
> rxf1ovfl: 0
> rxf2ovfl: 0
> txsfovfl: 0
> pmqovfl: 0
> rxcgprqfrm: 0
> rxcgprsqovfl: 0
> txcgprsfail: 0
> txcgprssuc: 0
> prs_timeout: 0
> rxnack: 0
> frmscons: 0
> txnack: 0
> txglitch_nack: 38
> txburst: 4
> bphy_rxcrsglitch: 2
> phywatchdog: 0
> bphy_badplcp: 0
>
>
> As far as I can see, the stats are never updated during stall,
> no numbers are changing, at least while the download is waiting
> for the next packet. Sometimes wpa_supplicant does something
> little, so some stats gets updated, eg, this is how it looks like
> after about 2..3 minutes:
>
> txallfrm: 420
> txrtsfrm: 201
> txctsfrm: 25
> txackfrm: 69
> txdnlfrm: 0
> txbcnfrm: 0
> txfunfl[8]: 0 0 0 0 0 0 0 0
> txtplunfl: 0
> txphyerr: 0
> pktengrxducast: 0
> pktengrxdmcast: 0
> rxfrmtoolong: 1908
> rxfrmtooshrt: 73
> rxinvmachdr: 4115
> rxbadfcs: 15064
> rxbadplcp: 42368
> rxcrsglitch: 36620
> rxstrt: 26393
> rxdfrmucastmbss: 48
> rxmfrmucastmbss: 27
> rxcfrmucast: 158
> rxrtsucast: 0
> rxctsucast: 92
> rxackucast: 25
> rxdfrmocast: 113
> rxmfrmocast: 390
> rxcfrmocast: 962
> rxrtsocast: 38
> rxctsocast: 59
> rxdfrmmcast: 48
> rxmfrmmcast: 7681
> rxcfrmmcast: 0
> rxbeaconmbss: 1505
> rxdfrmucastobss: 0
> rxbeaconobss: 6059
> rxrsptmout: 171
> bcntxcancl: 0
> rxf0ovfl: 0
> rxf1ovfl: 0
> rxf2ovfl: 0
> txsfovfl: 0
> pmqovfl: 0
> rxcgprqfrm: 0
> rxcgprsqovfl: 0
> txcgprsfail: 0
> txcgprssuc: 0
> prs_timeout: 0
> rxnack: 0
> frmscons: 0
> txnack: 0
> txglitch_nack: 41
> txburst: 4
> bphy_rxcrsglitch: 5
> phywatchdog: 0
> bphy_badplcp: 0
>
>
> This is with 3.18-tobe kernel (current Linus git).
>
> Dunno if this is helpful or not...
Well, it shows tx looks ok, but with download there is not much of that
going on. At least no large packets. However, I did find some missing
pieces related to bt-coex. Given that you device is a wifi-bt combo card
that is likely an issue for you. One of the missing pieces looks in
sprom for parameters and that is provided by bcma. However, it does not
seem to extract bt-coex related stuff. So I have attached a patch based
on 3.18-rc5 for bcma that dumps the sprom contents. Could you sent that
content to me.
Regards,
Arend
> Thanks,
>
> /mjt
>
>From 29cfa8ec164e2d742f98ddb2c5368b70540f5fab Mon Sep 17 00:00:00 2001
From: Arend van Spriel
Date: Sun, 23 Nov 2014 10:26:17 +0100
Subject: [PATCH] bcma: dump raw sprom content for debugging
Signed-off-by: Arend van Spriel
---
drivers/bcma/sprom.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bcma/sprom.c b/drivers/bcma/sprom.c
index efb037f..0c246a4 100644
--- a/drivers/bcma/sprom.c
+++ b/drivers/bcma/sprom.c
@@ -129,10 +129,16 @@ static u8 bcma_sprom_crc(const u16 *sprom, size_t words)
int word;
u8 crc = 0xFF;
+ pr_debug(KBUILD_MODNAME "sprom:");
for (word = 0; word < words - 1; word++) {
+ if ((word % 10) == 0)
+ pr_debug("\n\t");
+ pr_debug("%04X ", sprom[word]);
crc = bcma_crc8(crc, sprom[word] & 0x00FF);
crc = bcma_crc8(crc, (sprom[word] & 0xFF00) >> 8);
}
+ if ((word % 10) == 0)
+ pr_debug("\n");
crc = bcma_crc8(crc, sprom[words - 1] & 0x00FF);
crc ^= 0xFF;
--
1.9.1
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
I'm sorry this took so long - I was AFK during weekend and had to deal with a huge backlog after that. Now it is all sorted. 23.11.2014 12:43, Arend van Spriel wrote: > On 19-11-14 22:00, Michael Tokarev wrote: [] > Well, it shows tx looks ok, but with download there is not much of that > going on. At least no large packets. However, I did find some missing > pieces related to bt-coex. Given that you device is a wifi-bt combo card > that is likely an issue for you. One of the missing pieces looks in > sprom for parameters and that is provided by bcma. However, it does not > seem to extract bt-coex related stuff. So I have attached a patch based > on 3.18-rc5 for bcma that dumps the sprom contents. Could you sent that > content to me. Here we go. I had to replace pr_debug with pr_err - haven't looked yet, but the thing is that pr_debug isn't even being compiled into the kernel here, all the messages are not present in the compiled modules. [ 525.693474] bcma: bcmasprom: [ 525.693528] bcma: [ 525.693592] bcma: 2801 [ 525.693613] bcma: [ 525.693659] bcma: 1795 [ 525.693679] bcma: 103C [ 525.693725] bcma: 0070 [ 525.693746] bcma: EDBE [ 525.693791] bcma: [ 525.693811] bcma: 2BC4 [ 525.693856] bcma: 2A64 [ 525.693877] bcma: 2964 [ 525.693922] bcma: [ 525.693938] bcma: 2C64 [ 525.693984] bcma: 3CE7 [ 525.694004] bcma: 46FF [ 525.694049] bcma: 47FF [ 525.694070] bcma: 0C00 [ 525.694115] bcma: 0820 [ 525.694136] bcma: 0030 [ 525.694181] bcma: 1002 [ 525.694202] bcma: 9F28 [ 525.694247] bcma: 5D44 [ 525.694267] bcma: [ 525.694329] bcma: 8080 [ 525.694349] bcma: 1D8F [ 525.694395] bcma: 0032 [ 525.694415] bcma: 0100 [ 525.694461] bcma: DF00 [ 525.694481] bcma: 71F5 [ 525.694526] bcma: 8400 [ 525.694547] bcma: 0083 [ 525.694592] bcma: 8500 [ 525.694613] bcma: 2010 [ 525.694658] bcma: [ 525.694674] bcma: 0001 [ 525.694719] bcma: [ 525.694740] bcma: [ 525.694785] bcma: [ 525.694805] bcma: [ 525.694850] bcma: [ 525.694871] bcma: [ 525.694916] bcma: [ 525.694937] bcma: [ 525.694982] bcma: [ 525.695002] bcma: [ 525.695063] bcma: [ 525.695084] bcma: [ 525.695129] bcma: 1008 [ 525.695150] bcma: 0305 [ 525.695195] bcma: [ 525.695215] bcma: [ 525.695261] bcma: [ 525.695281] bcma: [ 525.695326] bcma: 4727 [ 525.695347] bcma: 8000 [ 525.695392] bcma: [ 525.695409] bcma: 0002 [ 525.695454] bcma: [ 525.695474] bcma: 1800 [ 525.695520] bcma: 1800 [ 525.695561] bcma: [ 525.695610] bcma: [ 525.695631] bcma: [ 525.695677] bcma: [ 525.695698] bcma: [ 525.695746] bcma: [ 525.695766] bcma: [ 525.695827] bcma: [ 525.695848] bcma: [ 525.695893] bcma: [ 525.695914] bcma: [ 525.695961] bcma: 5372 [ 525.695982] bcma: 1107 [ 525.696027] bcma: 2201 [ 525.696048] bcma: 0040 [ 525.696093] bcma: 0884 [ 525.696116] bcma: [ 525.696161] bcma: [ 525.696178] bcma: E006 [ 525.696223] bcma: E659 [ 525.696244] bcma: 5F5A [ 525.696290] bcma: 5856 [ 525.696310] bcma: 0001 [ 525.696356] bcma: [ 525.696376] bcma: 83FF [ 525.696422] bcma: [ 525.696443] bcma: 0003 [ 525.696488] bcma: 0202 [ 525.696508] bcma: [ 525.696570] bcma: [ 525.696590] bcma: 0011 [ 525.698381] bcma: 017A [ 525.698402] bcma: [ 525.700181] bcma: [ 525.700202] bcma: [ 525.701936] bcma: [ 525.701957] bcma: 0201 [ 525.703650] bcma: [ 525.703672] bcma: 7800 [ 525.705278] bcma: [ 525.706808] bcma: 6410 [ 525.708296] bcma: E398 [ 525.708318] bcma: 0008 [ 525.709774] bcma: [ 525.709796] bcma: [ 525.711186] bcma: [ 525.711207] bcma: 0044 [ 525.712532] bcma: 2400 [ 525.712556] bcma: FCF7 [ 525.713867] bcma: 0089 [ 525.713888] bcma: [ 525.716500] bcma: [ 525.716524] bcma: [ 525.717834] bcma: [ 525.717855] bcma: [ 525.719195] bcma: [ 525.719217] bcma: [ 525.720530] bcma: [ 525.720551] bcma: [ 525.721862] bcma: [ 525.721882] bcma: [ 525.723176] bcma: [ 525.724400] bcma: [ 525.725678] bcma: [ 525.725699] bcma: 0048 [ 525.726996] bcma: FED2 [ 525.727017] bcma: 15D9 [ 525.728308] bcma: FAC6 [ 525.728329] bcma: [ 525.729642] bcma: [ 525.729664] bcma: [ 525.730958] bcma: [ 525.730978] bcma: [ 525.733526] bcma: [ 525.733549] bcma: [ 525.734827] bcma: [ 525.734848] bcma: [ 525.736155] bcma: [ 525.736179] bcma: [ 525.737466] bcma: [ 525.737487] bcma: [ 525.738764] bcma: [ 525.738785] bcma: [ 525.740049] bcma: [ 525.741240] bcma: [ 525.742501] bcma: [ 525.742522] bcma: [ 525.743806] bcma: [ 525.743827] bcma: [ 525.745111] bcma: [ 525.745132] bcma: [ 525.746433] bcma: [
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 26-11-14 10:52, Michael Tokarev wrote: > I'm sorry this took so long - I was AFK during weekend and had > to deal with a huge backlog after that. Now it is all sorted. > > 23.11.2014 12:43, Arend van Spriel wrote: >> On 19-11-14 22:00, Michael Tokarev wrote: > [] >> Well, it shows tx looks ok, but with download there is not much of that >> going on. At least no large packets. However, I did find some missing >> pieces related to bt-coex. Given that you device is a wifi-bt combo card >> that is likely an issue for you. One of the missing pieces looks in >> sprom for parameters and that is provided by bcma. However, it does not >> seem to extract bt-coex related stuff. So I have attached a patch based >> on 3.18-rc5 for bcma that dumps the sprom contents. Could you sent that >> content to me. > > Here we go. I had to replace pr_debug with pr_err - haven't looked yet, > but the thing is that pr_debug isn't even being compiled into the kernel > here, all the messages are not present in the compiled modules. Thanks. Did not find what I was looking for, but I started working on integrating btcoex related functionality. The attached patch will print some info so I can focus on the required functionality for your device. It is based on 3.18-rc5. Regards, Arend > [ 525.693474] bcma: bcmasprom: > [ 525.693528] bcma: > > [ 525.693592] bcma: 2801 > [ 525.693613] bcma: > [ 525.693659] bcma: 1795 > [ 525.693679] bcma: 103C > [ 525.693725] bcma: 0070 > [ 525.693746] bcma: EDBE > [ 525.693791] bcma: > [ 525.693811] bcma: 2BC4 > [ 525.693856] bcma: 2A64 > [ 525.693877] bcma: 2964 > [ 525.693922] bcma: > > [ 525.693938] bcma: 2C64 > [ 525.693984] bcma: 3CE7 > [ 525.694004] bcma: 46FF > [ 525.694049] bcma: 47FF > [ 525.694070] bcma: 0C00 > [ 525.694115] bcma: 0820 > [ 525.694136] bcma: 0030 > [ 525.694181] bcma: 1002 > [ 525.694202] bcma: 9F28 > [ 525.694247] bcma: 5D44 > [ 525.694267] bcma: > > [ 525.694329] bcma: 8080 > [ 525.694349] bcma: 1D8F > [ 525.694395] bcma: 0032 > [ 525.694415] bcma: 0100 > [ 525.694461] bcma: DF00 > [ 525.694481] bcma: 71F5 > [ 525.694526] bcma: 8400 > [ 525.694547] bcma: 0083 > [ 525.694592] bcma: 8500 > [ 525.694613] bcma: 2010 > [ 525.694658] bcma: > > [ 525.694674] bcma: 0001 > [ 525.694719] bcma: > [ 525.694740] bcma: > [ 525.694785] bcma: > [ 525.694805] bcma: > [ 525.694850] bcma: > [ 525.694871] bcma: > [ 525.694916] bcma: > [ 525.694937] bcma: > [ 525.694982] bcma: > [ 525.695002] bcma: > > [ 525.695063] bcma: > [ 525.695084] bcma: > [ 525.695129] bcma: 1008 > [ 525.695150] bcma: 0305 > [ 525.695195] bcma: > [ 525.695215] bcma: > [ 525.695261] bcma: > [ 525.695281] bcma: > [ 525.695326] bcma: 4727 > [ 525.695347] bcma: 8000 > [ 525.695392] bcma: > > [ 525.695409] bcma: 0002 > [ 525.695454] bcma: > [ 525.695474] bcma: 1800 > [ 525.695520] bcma: 1800 > [ 525.695561] bcma: > [ 525.695610] bcma: > [ 525.695631] bcma: > [ 525.695677] bcma: > [ 525.695698] bcma: > [ 525.695746] bcma: > [ 525.695766] bcma: > > [ 525.695827] bcma: > [ 525.695848] bcma: > [ 525.695893] bcma: > [ 525.695914] bcma: > [ 525.695961] bcma: 5372 > [ 525.695982] bcma: 1107 > [ 525.696027] bcma: 2201 > [ 525.696048] bcma: 0040 > [ 525.696093] bcma: 0884 > [ 525.696116] bcma: > [ 525.696161] bcma: > > [ 525.696178] bcma: E006 > [ 525.696223] bcma: E659 > [ 525.696244] bcma: 5F5A > [ 525.696290] bcma: 5856 > [ 525.696310] bcma: 0001 > [ 525.696356] bcma: > [ 525.696376] bcma: 83FF > [ 525.696422] bcma: > [ 525.696443] bcma: 0003 > [ 525.696488] bcma: 0202 > [ 525.696508] bcma: > > [ 525.696570] bcma: > [ 525.696590] bcma: 0011 > [ 525.698381] bcma: 017A > [ 525.698402] bcma: > [ 525.700181] bcma: > [ 525.700202] bcma: > [ 525.701936] bcma: > [ 525.701957] bcma: 0201 > [ 525.703650] bcma: > [ 525.703672] bcma: 7800 > [ 525.705278] bcma: > > [ 525.706808] bcma: 6410 > [ 525.708296] bcma: E398 > [ 525.708318] bcma: 0008 > [ 525.709774] bcma: > [ 525.709796] bcma: > [ 525.711186] bcma: > [ 525.711207] bcma: 0044 > [ 525.712532] bcma: 2400 > [ 525.712556] bcma: FCF7 > [ 525.713867] bcma: 0089 > [ 525.713888] bcma: > > [ 525.716500] bcma: > [ 525.716524] bcma: > [ 525.717834] bcma: > [ 525.717855] bcma: > [ 525.719195] bcma: > [ 525.719217] bcma: > [ 525.720530] bcma: > [ 525.720551] bcma: > [ 525.721862] bcma: > [ 525.721882] bcma: > [ 525.723176] bcma: > > [ 525.724400] bcma: > [ 525.725678] bcma: > [ 525.725699] bcma: 0048 > [ 525.726996] bcma: FED2 > [ 525.727017] bcma: 15D9 > [ 525.728308] bcma: FAC6 > [ 525.728329] bcma: > [ 525.729642] bcma:
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
Hi Arend, sorry for my late reply, it took me a bit to get the modules compiled with your patches. Here is the information from my card. During this test I had very bad performance with my wifi connection with big latency and lots of packet loss. [ 1642.407735] bcma: bus0: Found chip with id 0x4313, rev 0x01 and package 0x08 [ 1642.407766] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x24, class 0x0) [ 1642.407794] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x18, class 0x0) [ 1642.407829] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x11, class 0x0) [ 1642.407913] bcma: bus0: Found rev 8 PMU (capabilities 0x084C3008) [ 1642.407978] bcma: bus0: SPROM offset 0x830 [ 1642.410625] bcma: bcmasprom: [ 1642.410630] bcma: [ 1642.410635] bcma: 2801 [ 1642.410637] bcma: [ 1642.410640] bcma: 0608 [ 1642.410642] bcma: 14E4 [ 1642.410645] bcma: 0070 [ 1642.410647] bcma: EDBE [ 1642.410649] bcma: [ 1642.410651] bcma: 2BC4 [ 1642.410654] bcma: 2A64 [ 1642.410655] bcma: 2964 [ 1642.410658] bcma: [ 1642.410659] bcma: 2C64 [ 1642.410662] bcma: 3CE7 [ 1642.410663] bcma: 46FF [ 1642.410666] bcma: 47FF [ 1642.410667] bcma: 0C00 [ 1642.410670] bcma: 0820 [ 1642.410671] bcma: 0030 [ 1642.410674] bcma: 1002 [ 1642.410676] bcma: 9F28 [ 1642.410678] bcma: 5D44 [ 1642.410679] bcma: [ 1642.410683] bcma: 8080 [ 1642.410684] bcma: 1D8F [ 1642.410687] bcma: 0032 [ 1642.410689] bcma: 0100 [ 1642.410691] bcma: DF00 [ 1642.410693] bcma: 71F5 [ 1642.410695] bcma: 8400 [ 1642.410697] bcma: 0083 [ 1642.410699] bcma: 8500 [ 1642.410701] bcma: 2010 [ 1642.410703] bcma: [ 1642.410705] bcma: 0001 [ 1642.410707] bcma: [ 1642.410709] bcma: [ 1642.410711] bcma: [ 1642.410713] bcma: [ 1642.410715] bcma: [ 1642.410717] bcma: [ 1642.410719] bcma: [ 1642.410721] bcma: [ 1642.410723] bcma: [ 1642.410724] bcma: [ 1642.410728] bcma: [ 1642.410730] bcma: [ 1642.410732] bcma: 1008 [ 1642.410734] bcma: 0305 [ 1642.410736] bcma: [ 1642.410738] bcma: [ 1642.410740] bcma: [ 1642.410742] bcma: [ 1642.410744] bcma: 4727 [ 1642.410746] bcma: 8000 [ 1642.410748] bcma: [ 1642.410749] bcma: 0002 [ 1642.410752] bcma: [ 1642.410753] bcma: 1F30 [ 1642.410756] bcma: 1800 [ 1642.410757] bcma: [ 1642.410760] bcma: [ 1642.410761] bcma: [ 1642.410764] bcma: [ 1642.410765] bcma: [ 1642.410768] bcma: [ 1642.410769] bcma: [ 1642.410773] bcma: [ 1642.410774] bcma: [ 1642.410777] bcma: [ 1642.410778] bcma: [ 1642.410781] bcma: 5372 [ 1642.410782] bcma: 1109 [ 1642.410785] bcma: 2201 [ 1642.410786] bcma: 0040 [ 1642.410789] bcma: 0884 [ 1642.410790] bcma: [ 1642.410793] bcma: [ 1642.410794] bcma: C014 [ 1642.410797] bcma: 3DC1 [ 1642.410798] bcma: 809D [ 1642.410801] bcma: 5856 [ 1642.410802] bcma: 0001 [ 1642.410805] bcma: [ 1642.410807] bcma: 83FF [ 1642.410809] bcma: [ 1642.410811] bcma: 0003 [ 1642.410813] bcma: 0202 [ 1642.410814] bcma: [ 1642.410818] bcma: [ 1642.410819] bcma: 0011 [ 1642.410822] bcma: 017A [ 1642.410824] bcma: [ 1642.410826] bcma: [ 1642.410828] bcma: [ 1642.410830] bcma: [ 1642.410832] bcma: 0201 [ 1642.410834] bcma: [ 1642.410836] bcma: 7800 [ 1642.410838] bcma: [ 1642.410839] bcma: 01FF [ 1642.410842] bcma: E398 [ 1642.410844] bcma: 0008 [ 1642.410846] bcma: [ 1642.410848] bcma: [ 1642.410850] bcma: [ 1642.410852] bcma: 0044 [ 1642.410854] bcma: 2400 [ 1642.410856] bcma: FCF7 [ 1642.410858] bcma: 0089 [ 1642.410860] bcma: [ 1642.410863] bcma: [ 1642.410865] bcma: [ 1642.410867] bcma: [ 1642.410869] bcma: [ 1642.410871] bcma: [ 1642.410873] bcma: [ 1642.410875] bcma: [ 1642.410877] bcma: [ 1642.410879] bcma: [ 1642.410881] bcma: [ 1642.410883] bcma: [ 1642.410884] bcma: [ 1642.410887] bcma: [ 1642.410888] bcma: 0048 [ 1642.410891] bcma: FED2 [ 1642.410892] bcma: 15D9 [ 1642.410895] bcma: FAC6 [ 1642.410897] bcma: [ 1642.410899] bcma: [ 1642.410901] bcma: [ 1642.410903] bcma: [ 1642.410904] bcma: [ 1642.410908] bcma: [ 1642.410909] bcma: [ 1642.410912] bcma: [ 1642.410913] bcma: [ 1642.410916] bcma: [ 1642.410917] bcma: [ 1642.410920] bcma: [ 1642.410921] bcma: [ 1642.410924] bcma: [ 1642.410925] bcma: [ 1642.410927] bcma: [ 1642.410929] bcma: [ 1642.410931] bcma: [ 1642.410933] bcma: [ 1642.410935] bcma: [ 1642.410937] bcma: [ 1642.410939] bcma: [ 1642.410941] bcma: [ 1642.410943] bcma: [ 1642.410945] bcma: [ 1642.410947] bcma: [ 1642.410949] bc
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
30.11.2014 15:04, Arend van Spriel wrote: > Thanks. Did not find what I was looking for, but I started working on > integrating btcoex related functionality. The attached patch will print > some info so I can focus on the required functionality for your device. > It is based on 3.18-rc5. With this patch applied against 3.18-rc5, the machine instantly reboots once brcmsmac module is loaded. I'm still debugging this. Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 12/02/14 22:40, Michael Tokarev wrote: 30.11.2014 15:04, Arend van Spriel wrote: Thanks. Did not find what I was looking for, but I started working on integrating btcoex related functionality. The attached patch will print some info so I can focus on the required functionality for your device. It is based on 3.18-rc5. With this patch applied against 3.18-rc5, the machine instantly reboots once brcmsmac module is loaded. I'm still debugging this. Argh. Probably the register access I added end up in limbo land or some other stupid mistake. I will double check my patch. Regards, Arend Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 12/03/14 13:43, Arend van Spriel wrote: On 12/02/14 22:40, Michael Tokarev wrote: 30.11.2014 15:04, Arend van Spriel wrote: Thanks. Did not find what I was looking for, but I started working on integrating btcoex related functionality. The attached patch will print some info so I can focus on the required functionality for your device. It is based on 3.18-rc5. With this patch applied against 3.18-rc5, the machine instantly reboots once brcmsmac module is loaded. I'm still debugging this. Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove that call as it causes endless recursion and eventually reboot. Regards, Arend Argh. Probably the register access I added end up in limbo land or some other stupid mistake. I will double check my patch. Regards, Arend Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
16.12.2014 19:51, Arend van Spriel wrote: > Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove > that call as it causes endless recursion and eventually reboot. Ok, that was easy. Now it loads, but wifi link still does not work, stalling as before. What we're looking at now? (To have a common base, I applied this bt-coex patch to 3.18.0 kernel. I can also apply the previously mentioned debugging/stats patch too). Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 12/21/14 10:58, Michael Tokarev wrote: 16.12.2014 19:51, Arend van Spriel wrote: Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove that call as it causes endless recursion and eventually reboot. Ok, that was easy. Now it loads, but wifi link still does not work, stalling as before. What we're looking at now? The patch is just to provide me with extra bt-coex related information in the kernel log. So if you can provide that to me I have to info needed to look in the proprietary code base to determine what is missing. Regards, Arend (To have a common base, I applied this bt-coex patch to 3.18.0 kernel. I can also apply the previously mentioned debugging/stats patch too). Thanks, /mjt -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 12/21/14 11:00, Michael Tokarev wrote: Attaching a picture of the board, too. One of the two similar boards I have (another has lenovo sticker on it). Also available as http://www.corpit.ru/mjt/BRCM94313HMGB.JPG (I wonder if broadcom does not have any of these cards anymore... ;) Probably in US, but we are in an office in the Netherlands and do not have every flavor of board available. I will dive into some boxes again with this info. Thanks, 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
[Trimming Cc list a bit] 21.12.2014 13:12, Arend van Spriel wrote: > On 12/21/14 10:58, Michael Tokarev wrote: >> 16.12.2014 19:51, Arend van Spriel wrote: >> >>> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove >>> that call as it causes endless recursion and eventually reboot. >> >> Ok, that was easy. Now it loads, but wifi link still >> does not work, stalling as before. What we're looking >> at now? > > The patch is just to provide me with extra bt-coex related information in the > kernel log. So if you can provide that to me I have to info needed to look in > the proprietary code base to determine what is missing. I don't really see any additional info, but it might be just me. Here's the dmesg contents of loading brcmsmac module with debug=1, adding an IP address to the wlan0 interface and running a simple download (which stalls after about 4..6Kb transferred): [73321.062190] cfg80211: Calling CRDA to update world regulatory domain [73326.973828] bcma: bus0: Found chip with id 0x4313, rev 0x01 and package 0x08 [73326.979264] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x24, class 0x0) [73326.984760] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x18, class 0x0) [73326.990242] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x11, class 0x0) [73326.995741] bcma: bus0: Found rev 8 PMU (capabilities 0x084C3008) [73326.995754] bcma: bus0: SPROM offset 0x830 [73326.997645] bcma: bus0: Found SPROM revision 8 [73327.008110] bcma: bus0: GPIO driver not activated [73327.008117] bcma: bus0: Bus registered [73327.016533] Support for cores revisions 0x17 and 0x18 disabled by module param allhwsupport=0. Try b43.allhwsupport=1 [73327.021981] b43: probe of bcma0:1 failed with error -524 [73327.027507] Broadcom 43xx driver loaded [ Features: PNL ] [73327.028594] brcmsmac bcma0:1: mfg 4bf core 812 rev 24 class 0 irq 19 [73327.028620] ieee80211 phy4: brcms_c_protection_upd: idx 2, val -1 [73327.028623] ieee80211 phy4: brcms_c_protection_upd: idx 1, val 0 [73327.028626] ieee80211 phy4: brcms_c_protection_upd: idx 12, val -1 [73327.028629] ieee80211 phy4: brcms_c_protection_upd: idx 11, val 0 [73327.028632] ieee80211 phy4: brcms_c_protection_upd: idx 14, val -1 [73327.028635] ieee80211 phy4: brcms_c_protection_upd: idx 13, val 0 [73327.028638] ieee80211 phy4: brcms_c_protection_upd: idx 15, val -1 [73327.028641] ieee80211 phy4: brcms_c_protection_upd: idx 4, val 2 [73327.028647] brcmsmac bcma0:1: brcms_b_attach wl0: vendor 0x14e4 device 0x4727 [73327.028660] brcmsmac bcma0:1: brcms_b_corereset wl0: core reset [73327.028667] bcma: bus0: Switched to core: 0x812 [73327.029223] brcmsmac bcma0:1: brcms_b_phy_reset wl0: reset phy [73327.029227] brcmsmac bcma0:1: brcms_b_core_phypll_ctl wl0 [73327.029259] brcmsmac bcma0:1: brcms_b_corereset wl0: core reset [73327.029364] brcmsmac bcma0:1: brcms_b_phy_reset wl0: reset phy [73327.029367] brcmsmac bcma0:1: brcms_b_core_phypll_ctl wl0 [73327.029410] brcmsmac bcma0:1: brcms_b_attach wl0: phy 8/1 radio 2064/1 [73327.029460] brcmsmac bcma0:1: hardware: SECI [73327.029464] brcmsmac bcma0:1: brcms_c_coredisable wl0: disable core [73327.029490] brcmsmac bcma0:1: brcms_b_core_phypll_ctl wl0 [73327.029529] ieee80211 phy4: brcms_c_protection_upd: idx 15, val 0 [73327.029534] ieee80211 phy4: brcms_c_protection_upd: idx 3, val 1 [73327.029537] ieee80211 phy4: brcms_c_protection_upd: idx 10, val 1 [73327.029549] ieee80211 phy4: brcms_c_protection_upd: idx 3, val 1 [73327.029820] ieee80211 phy4: Selected rate control algorithm 'minstrel_ht' [73327.121616] brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: false (implement) [73327.121626] brcmsmac bcma0:1: brcms_ops_config: change power-save mode: false (implement) [73327.122195] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [73328.179594] wlan0: authenticate with 64:70:02:29:d9:30 [73328.183927] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded [73328.187684] wlan0: send auth to 64:70:02:29:d9:30 (try 1/3) [73328.193289] wlan0: authenticated [73328.198793] wlan0: associate with 64:70:02:29:d9:30 (try 1/3) [73328.207394] wlan0: RX AssocResp from 64:70:02:29:d9:30 (capab=0x411 status=0 aid=2) [73328.211734] brcmsmac bcma0:1: brcmsmac: brcms_ops_bss_info_changed: associated [73328.215616] brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: true (implement) [73328.219433] wlan0: associated [73328.223264] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [73328.282197] ieee80211 phy4: brcms_c_protection_upd: idx 11, val 0 [73328.285855] ieee80211 phy4: brcms_c_protection_upd: idx 13, val 4 [73328.289431] ieee80211 phy4: brcms_c_protection_upd: idx 16, val 0 [73332.121259] net_ratelimit: 36 callbacks suppressed [73332.125201] brcmsmac bcma0:1: brcms_c_watchdog wl0 [7.125295] brcmsmac bcma0:1: brcms_c_watchdog wl0 [73334.129073] brcmsmac bcma0:1: brcms_c_watchdog wl0 [73335.133022] brcmsma
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 12/21/14 11:27, Michael Tokarev wrote: [73327.029460] brcmsmac bcma0:1: hardware: SECI Well, The piece of info is small, but it is there ;-) Thanks, 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote: > On 12/21/14 10:58, Michael Tokarev wrote: > > 16.12.2014 19:51, Arend van Spriel wrote: > >> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please > >> remove that call as it causes endless recursion and eventually reboot.> > > Ok, that was easy. Now it loads, but wifi link still > > does not work, stalling as before. What we're looking > > at now? > > The patch is just to provide me with extra bt-coex related information > in the kernel log. So if you can provide that to me I have to info > needed to look in the proprietary code base to determine what is missing. > > Regards, > Arend Hi Arend, here is the output from my card: [ 5167.720041] cfg80211: Calling CRDA to update world regulatory domain [ 5167.737243] bcma: bus0: Found chip with id 0x4313, rev 0x01 and package 0x08 [ 5167.737271] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x24, class 0x0) [ 5167.737290] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x18, class 0x0) [ 5167.737324] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x11, class 0x0) [ 5167.737407] bcma: bus0: Found rev 8 PMU (capabilities 0x084C3008) [ 5167.737417] bcma: bus0: SPROM offset 0x830 [ 5167.739392] bcma: bcmasprom: [ 5167.739396] bcma: [ 5167.739400] bcma: 2801 [ 5167.739402] bcma: [ 5167.739404] bcma: 0608 [ 5167.739405] bcma: 14E4 [ 5167.739408] bcma: 0070 [ 5167.739409] bcma: EDBE [ 5167.739411] bcma: [ 5167.739412] bcma: 2BC4 [ 5167.739414] bcma: 2A64 [ 5167.739416] bcma: 2964 [ 5167.739417] bcma: [ 5167.739419] bcma: 2C64 [ 5167.739421] bcma: 3CE7 [ 5167.739422] bcma: 46FF [ 5167.739424] bcma: 47FF [ 5167.739425] bcma: 0C00 [ 5167.739427] bcma: 0820 [ 5167.739429] bcma: 0030 [ 5167.739430] bcma: 1002 [ 5167.739432] bcma: 9F28 [ 5167.739434] bcma: 5D44 [ 5167.739435] bcma: [ 5167.739438] bcma: 8080 [ 5167.739439] bcma: 1D8F [ 5167.739441] bcma: 0032 [ 5167.739442] bcma: 0100 [ 5167.739444] bcma: DF00 [ 5167.739445] bcma: 71F5 [ 5167.739447] bcma: 8400 [ 5167.739448] bcma: 0083 [ 5167.739450] bcma: 8500 [ 5167.739452] bcma: 2010 [ 5167.739453] bcma: [ 5167.739455] bcma: 0001 [ 5167.739457] bcma: [ 5167.739458] bcma: [ 5167.739460] bcma: [ 5167.739461] bcma: [ 5167.739463] bcma: [ 5167.739464] bcma: [ 5167.739466] bcma: [ 5167.739467] bcma: [ 5167.739469] bcma: [ 5167.739470] bcma: [ 5167.739473] bcma: [ 5167.739474] bcma: [ 5167.739476] bcma: 1008 [ 5167.739477] bcma: 0305 [ 5167.739479] bcma: [ 5167.739480] bcma: [ 5167.739482] bcma: [ 5167.739484] bcma: [ 5167.739485] bcma: 4727 [ 5167.739487] bcma: 8000 [ 5167.739488] bcma: [ 5167.739490] bcma: 0002 [ 5167.739492] bcma: [ 5167.739493] bcma: 1F30 [ 5167.739495] bcma: 1800 [ 5167.739496] bcma: [ 5167.739498] bcma: [ 5167.739499] bcma: [ 5167.739501] bcma: [ 5167.739502] bcma: [ 5167.739504] bcma: [ 5167.739505] bcma: [ 5167.739508] bcma: [ 5167.739509] bcma: [ 5167.739511] bcma: [ 5167.739512] bcma: [ 5167.739514] bcma: 5372 [ 5167.739515] bcma: 1109 [ 5167.739517] bcma: 2201 [ 5167.739519] bcma: 0040 [ 5167.739520] bcma: 0884 [ 5167.739522] bcma: [ 5167.739523] bcma: [ 5167.739525] bcma: C014 [ 5167.739526] bcma: 3DC1 [ 5167.739528] bcma: 809D [ 5167.739530] bcma: 5856 [ 5167.739531] bcma: 0001 [ 5167.739533] bcma: [ 5167.739534] bcma: 83FF [ 5167.739536] bcma: [ 5167.739537] bcma: 0003 [ 5167.739539] bcma: 0202 [ 5167.739540] bcma: [ 5167.739543] bcma: [ 5167.739544] bcma: 0011 [ 5167.739546] bcma: 017A [ 5167.739547] bcma: [ 5167.739549] bcma: [ 5167.739550] bcma: [ 5167.739552] bcma: [ 5167.739553] bcma: 0201 [ 5167.739555] bcma: [ 5167.739556] bcma: 7800 [ 5167.739558] bcma: [ 5167.739559] bcma: 01FF [ 5167.739561] bcma: E398 [ 5167.739563] bcma: 0008 [ 5167.739564] bcma: [ 5167.739566] bcma: [ 5167.739568] bcma: [ 5167.739569] bcma: 0044 [ 5167.739571] bcma: 2400 [ 5167.739572] bcma: FCF7 [ 5167.739574] bcma: 0089 [ 5167.739575] bcma: [ 5167.739578] bcma: [ 5167.739579] bcma: [ 5167.739581] bcma: [ 5167.739582] bcma: [ 5167.739584] bcma: [ 5167.739585] bcma: [ 5167.739587] bcma: [ 5167.739588] bcma: [ 5167.739590] bcma: [ 5167.739591] bcma: [ 5167.739593] bcma: [ 5167.739594] bcma: [ 5167.739596] bcma: [ 5167.739597] bcma: 0048 [ 5167.739599] bcma: FED2 [ 5167.739600] bcma: 15D9 [ 5167.739602] bcma: FAC6 [ 5167.739604] bcma: [ 5167.739605] bcma: [ 5167.739607] bcma: [ 5167.739608] bcma: [ 5167.739610] bcma: [ 5167.739612] bcma: [ 5167.739614] bcma:
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 12/21/14 15:08, Maximilian Engelhardt wrote: On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote: On 12/21/14 10:58, Michael Tokarev wrote: 16.12.2014 19:51, Arend van Spriel wrote: Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove that call as it causes endless recursion and eventually reboot.> Ok, that was easy. Now it loads, but wifi link still does not work, stalling as before. What we're looking at now? The patch is just to provide me with extra bt-coex related information in the kernel log. So if you can provide that to me I have to info needed to look in the proprietary code base to determine what is missing. Regards, Arend Hi Arend, here is the output from my card: Thanks. It shows you have have the same bt-coex version as Michael. I am not familiar with bluetooth side of things. Are you both using bluetooth on 4313? Regards, Arend [ 5167.720041] cfg80211: Calling CRDA to update world regulatory domain [ 5167.737243] bcma: bus0: Found chip with id 0x4313, rev 0x01 and package 0x08 [ 5167.737271] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x24, class 0x0) [ 5167.737290] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x18, class 0x0) [ 5167.737324] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x11, class 0x0) [ 5167.737407] bcma: bus0: Found rev 8 PMU (capabilities 0x084C3008) [ 5167.737417] bcma: bus0: SPROM offset 0x830 [ 5167.739392] bcma: bcmasprom: [ 5167.739396] bcma: [ 5167.739400] bcma: 2801 [ 5167.739402] bcma: [ 5167.739404] bcma: 0608 [ 5167.739405] bcma: 14E4 [ 5167.739408] bcma: 0070 [ 5167.739409] bcma: EDBE [ 5167.739411] bcma: [ 5167.739412] bcma: 2BC4 [ 5167.739414] bcma: 2A64 [ 5167.739416] bcma: 2964 [ 5167.739417] bcma: [ 5167.739419] bcma: 2C64 [ 5167.739421] bcma: 3CE7 [ 5167.739422] bcma: 46FF [ 5167.739424] bcma: 47FF [ 5167.739425] bcma: 0C00 [ 5167.739427] bcma: 0820 [ 5167.739429] bcma: 0030 [ 5167.739430] bcma: 1002 [ 5167.739432] bcma: 9F28 [ 5167.739434] bcma: 5D44 [ 5167.739435] bcma: [ 5167.739438] bcma: 8080 [ 5167.739439] bcma: 1D8F [ 5167.739441] bcma: 0032 [ 5167.739442] bcma: 0100 [ 5167.739444] bcma: DF00 [ 5167.739445] bcma: 71F5 [ 5167.739447] bcma: 8400 [ 5167.739448] bcma: 0083 [ 5167.739450] bcma: 8500 [ 5167.739452] bcma: 2010 [ 5167.739453] bcma: [ 5167.739455] bcma: 0001 [ 5167.739457] bcma: [ 5167.739458] bcma: [ 5167.739460] bcma: [ 5167.739461] bcma: [ 5167.739463] bcma: [ 5167.739464] bcma: [ 5167.739466] bcma: [ 5167.739467] bcma: [ 5167.739469] bcma: [ 5167.739470] bcma: [ 5167.739473] bcma: [ 5167.739474] bcma: [ 5167.739476] bcma: 1008 [ 5167.739477] bcma: 0305 [ 5167.739479] bcma: [ 5167.739480] bcma: [ 5167.739482] bcma: [ 5167.739484] bcma: [ 5167.739485] bcma: 4727 [ 5167.739487] bcma: 8000 [ 5167.739488] bcma: [ 5167.739490] bcma: 0002 [ 5167.739492] bcma: [ 5167.739493] bcma: 1F30 [ 5167.739495] bcma: 1800 [ 5167.739496] bcma: [ 5167.739498] bcma: [ 5167.739499] bcma: [ 5167.739501] bcma: [ 5167.739502] bcma: [ 5167.739504] bcma: [ 5167.739505] bcma: [ 5167.739508] bcma: [ 5167.739509] bcma: [ 5167.739511] bcma: [ 5167.739512] bcma: [ 5167.739514] bcma: 5372 [ 5167.739515] bcma: 1109 [ 5167.739517] bcma: 2201 [ 5167.739519] bcma: 0040 [ 5167.739520] bcma: 0884 [ 5167.739522] bcma: [ 5167.739523] bcma: [ 5167.739525] bcma: C014 [ 5167.739526] bcma: 3DC1 [ 5167.739528] bcma: 809D [ 5167.739530] bcma: 5856 [ 5167.739531] bcma: 0001 [ 5167.739533] bcma: [ 5167.739534] bcma: 83FF [ 5167.739536] bcma: [ 5167.739537] bcma: 0003 [ 5167.739539] bcma: 0202 [ 5167.739540] bcma: [ 5167.739543] bcma: [ 5167.739544] bcma: 0011 [ 5167.739546] bcma: 017A [ 5167.739547] bcma: [ 5167.739549] bcma: [ 5167.739550] bcma: [ 5167.739552] bcma: [ 5167.739553] bcma: 0201 [ 5167.739555] bcma: [ 5167.739556] bcma: 7800 [ 5167.739558] bcma: [ 5167.739559] bcma: 01FF [ 5167.739561] bcma: E398 [ 5167.739563] bcma: 0008 [ 5167.739564] bcma: [ 5167.739566] bcma: [ 5167.739568] bcma: [ 5167.739569] bcma: 0044 [ 5167.739571] bcma: 2400 [ 5167.739572] bcma: FCF7 [ 5167.739574] bcma: 0089 [ 5167.739575] bcma: [ 5167.739578] bcma: [ 5167.739579] bcma: [ 5167.739581] bcma: [ 5167.739582] bcma: [ 5167.739584] bcma: [ 5167.739585] bcma: [ 5167.739587] bcma: [ 5167.739588] bcma: [ 5167.739590] bcma: [ 5167.739591] bcma: [ 5167.739593] bcma: [ 5167.739594] bcma: [ 5167.739596] bcma: [ 5167.739597] bcma: 0048 [ 5167.739599] bcma: FED2 [ 5167.739600] bcma: 15D9 [ 5167.739602] bcma: FAC6 [ 5167.739604] bcma: [ 5167.739605] bcma: [ 5167.739607] bcma: [ 5167.739608] bcma: [ 5167.739610] bcma:
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote: > On 12/21/14 15:08, Maximilian Engelhardt wrote: > > On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote: > >> On 12/21/14 10:58, Michael Tokarev wrote: > >>> 16.12.2014 19:51, Arend van Spriel wrote: > Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please > remove that call as it causes endless recursion and eventually reboot.> > >>> > >>> Ok, that was easy. Now it loads, but wifi link still > >>> does not work, stalling as before. What we're looking > >>> at now? > >> > >> The patch is just to provide me with extra bt-coex related information > >> in the kernel log. So if you can provide that to me I have to info > >> needed to look in the proprietary code base to determine what is missing. > >> > >> Regards, > >> Arend > > > > Hi Arend, > > > here is the output from my card: > Thanks. It shows you have have the same bt-coex version as Michael. I am > not familiar with bluetooth side of things. Are you both using bluetooth > on 4313? > > Regards, > Arend I don't know. I think I have Bluetooth somehow enabled but I'm not really using it. I definitely don't have any Bluetooth devices connected. I could try to unload/disable Bluetooth it to see if it makes any difference. Greetings, Maxi signature.asc Description: This is a digitally signed message part.
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On 12/21/14 15:24, Maximilian Engelhardt wrote: On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote: On 12/21/14 15:08, Maximilian Engelhardt wrote: On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote: On 12/21/14 10:58, Michael Tokarev wrote: 16.12.2014 19:51, Arend van Spriel wrote: Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please remove that call as it causes endless recursion and eventually reboot.> Ok, that was easy. Now it loads, but wifi link still does not work, stalling as before. What we're looking at now? The patch is just to provide me with extra bt-coex related information in the kernel log. So if you can provide that to me I have to info needed to look in the proprietary code base to determine what is missing. Regards, Arend Hi Arend, here is the output from my card: Thanks. It shows you have have the same bt-coex version as Michael. I am not familiar with bluetooth side of things. Are you both using bluetooth on 4313? Regards, Arend I don't know. I think I have Bluetooth somehow enabled but I'm not really using it. I definitely don't have any Bluetooth devices connected. I could try to unload/disable Bluetooth it to see if it makes any difference. That would be useful to know. Thanks, Arend Greetings, Maxi -- 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
Re: BCM4313 & brcmsmac & 3.12: only semi-working?
On Sunday 21 December 2014 16:03:17 Arend van Spriel wrote: > On 12/21/14 15:24, Maximilian Engelhardt wrote: > > On Sunday 21 December 2014 15:13:50 Arend van Spriel wrote: > >> On 12/21/14 15:08, Maximilian Engelhardt wrote: > >>> On Sunday 21 December 2014 11:12:40 Arend van Spriel wrote: > On 12/21/14 10:58, Michael Tokarev wrote: > > 16.12.2014 19:51, Arend van Spriel wrote: > >> Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please > >> remove that call as it causes endless recursion and eventually > >> reboot.> > > > > Ok, that was easy. Now it loads, but wifi link still > > does not work, stalling as before. What we're looking > > at now? > > The patch is just to provide me with extra bt-coex related information > in the kernel log. So if you can provide that to me I have to info > needed to look in the proprietary code base to determine what is > missing. > > Regards, > Arend > >>> > >>> Hi Arend, > >> > >>> here is the output from my card: > >> Thanks. It shows you have have the same bt-coex version as Michael. I am > >> not familiar with bluetooth side of things. Are you both using bluetooth > >> on 4313? > >> > >> Regards, > >> Arend > > > > I don't know. I think I have Bluetooth somehow enabled but I'm not really > > using it. I definitely don't have any Bluetooth devices connected. I could > > try to unload/disable Bluetooth it to see if it makes any difference. > > That would be useful to know. > I did a test with all Bluetooth modules unloaded that I could find but throughput was still very low (about 4 Mbit/s with brcmsmac, my atheros USB stick archived about 110 Mbit/s). Greetings, Maxi signature.asc Description: This is a digitally signed message part.
