LinuxLists.cc - BCM4313 & brcmsmac & 3.12: only semi-working?

2013-12-27 21:08:17

Subject: BCM4313 & brcmsmac & 3.12: only semi-working?

Hello.

Got a Lenovo Thinkpad notebook with the following wifi card:

03:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01)
Subsystem: Broadcom Corporation Device [14e4:0608]
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at f1600000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-24-ff-ff-fe-48-d2
Capabilities: [16c] Power Budgeting <?>
Kernel driver in use: bcma-pci-bridge

With 3.12 kernel, the device is recognized and it is possible to
connect to the access point and exchange some data. In 3.10,
even connection (assotiation with the AP) was quite a bit
problematic, and packet exchange never worked).

However, after receiving a few packets (about 100 packets), the
interface almost stops receiving data, except a few packets once
in a while. For example, when d/loading some file over wifi, first
part (very beginning) gets d/loaded fine, and next d/load stalls,
with Rx counter of the card not changing. Terminating the process
makes the counter to increase by one or two.

Stopping and re-starting the interface in NetworkManager makes
it go again, also for just about 100 packets, till it stalls
again.

Sometimes it works longer, say, 500 or even 1000 packets, but
at the end it stalls anyway.

Here's a typical iwconfig output:

wlan0 IEEE 802.11bgn ESSID:"mjt"
Mode:Managed Frequency:2.412 GHz Access Point: 64:70:02:29:D9:30
Bit Rate=1 Mb/s Tx-Power=19 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=56/70 Signal level=-54 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:84 Invalid misc:13 Missed beacon:0

(Note the bitrate of 1Mbps: the AP is pretty much capable of
running at 54Mbps, and actually my smartphone, when used in
exactly the same place, goes at full 54Mbps just fine. The
signal conditions are very well in here, AP is about 15 meters
away, stright visible. When I force-reconnect it, it displays
some more sane value here for a few moments but drops to 1mbps
anyway).

Here's some dmesg output when I start/stop wifi network and
try to d/load something:

...
[28031.696294] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement)
[28031.696307] brcmsmac bcma0:0: brcms_ops_config: change power-save mode: false (implement)
[28033.640097] wlan0: authenticate with 64:70:02:29:d9:30
[28033.642395] wlan0: send auth to 64:70:02:29:d9:30 (try 1/3)
[28033.644624] wlan0: authenticated
[28033.645452] wlan0: associate with 64:70:02:29:d9:30 (try 1/3)
[28033.650163] wlan0: RX AssocResp from 64:70:02:29:d9:30 (capab=0x411 status=0 aid=1)
[28033.651697] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated
[28033.651702] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement)
[28033.651710] wlan0: associated
[28033.921528] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
[28149.522205] wlan0: deauthenticating from 64:70:02:29:d9:30 by local choice (reason=3)
[28149.535454] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated
[28149.535469] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
[28149.535476] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement)
[28149.538431] cfg80211: Calling CRDA to update world regulatory domain
[28152.718056] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement)
[28152.718074] brcmsmac bcma0:0: brcms_ops_config: change power-save mode: false (implement)
[28154.564599] wlan0: authenticate with 64:70:02:29:d9:30
[28154.567108] wlan0: send auth to 64:70:02:29:d9:30 (try 1/3)
[28154.569527] wlan0: authenticated
[28154.570232] wlan0: associate with 64:70:02:29:d9:30 (try 1/3)
[28154.574687] wlan0: RX AssocResp from 64:70:02:29:d9:30 (capab=0x411 status=0 aid=1)
[28154.575257] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated
[28154.575261] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement)
[28154.575268] wlan0: associated
...

The same notebook with the same wifi card works just fine under
windows (both windows 7 and 8), demonstrating stable reliable
about-54Mbps connection.

Is there any hope to get this device working under linux?

I can re-build kernels and stuff, enable debugging etc, -- that's
no problem, but I've really limited time.

I purchased this notebook especially to be used when travelling,
to be able to access to my office/work network over hotel wifi,
I plan to have a trip starting Jan-2. After figuring out that
it doesn't quite work as I'd expect it to do, I purchased another
wifi card, just to face another issue: it my notebook refuses to
_boot_ while that card is inserted! (it was a completely new
and unexpected "feature", now I know what it is, and will avoid
lenovo and HP notebooks in the future), -- so I returned the card
back. But now I'm again without wifi, and I can't return the
notebook...

P.S. I tried to find archives of brcm80211 list, or a way to
subscribe to it before posting, but found neither. Are there
archives?

Thanks,

/mjt

2013-12-28 12:24:24

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

2014-09-29 19:48:05

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 Live image to try the wl driver, just to verify that
it performs better and the hardware is still fine. First on the Ubuntu Live
image the speed with the brcmsmac driver were the same as in my test above. I
the installed the wl driver, unloaded the brcmsmac module and loaded the wl
module. That however did not work as something in the kernel crashed and
wireless didn't work at all. I rebootet the system to test again in case this
was a random failure. What was interesting after this reboot was that the
wireless connection was fast with the brcmsmac driver. I got about 35 Mbit/s
up and down speed. I then tried the wl driver again but it still crashed.

After this I rebooted into my normal Debian system and the brcmsmac driver was
still fast. So what was different now than before. I realized that I always did
a reboot, so the Laptop was never really off between the boots. I then shut
down the laptop and waited a few seconds before turning it on again. And after
that the driver was back to the slow speed.

I did not verify this a second time, but for now it very much looks like the
wl driver is settings something in the card that is necessary for getting
faster speeds. This seems to be preserved on reboot but not on poweroff.

I hope this my help you finding the problem in the brcmsmac driver. Feel free
to ask if you need any addition debug information from me.

And for the record, my atheros usb card is still much faster, it reaches
130 Mbit/s.

Greetings,
Maxi

Attachments:

signature.asc (819.00 B)
This is a digitally signed message part.

2014-11-19 13:46:24

by Arend van Spriel

[permalink] [raw]

Subject: 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<[email protected]> 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

2014-11-19 13:49:32

by Arend van Spriel

[permalink] [raw]

Subject: 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<[email protected]> 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

2014-11-30 12:04:35

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
>

Attachments:

0001-bcma-dump-raw-sprom-content-for-debugging.patch (981.00 B)

2014-11-19 17:54:25

by Arend van Spriel

[permalink] [raw]

Subject: 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

Attachments:

0001-brcmutil-add-helper-function-to-format-board-revisio.patch (2.00 kB)
0002-brcmsmac-extend-hardware-info-shown-in-debugfs.patch (2.43 kB)
Download all attachments

2014-11-17 22:44:32

2014-12-21 14:08:48

[permalink] [raw]

Subject: 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

2020-08-24 04:37:35

by Sébastien Le Preste De Vauban

[permalink] [raw]

Subject: Re: BCM4313 & brcmsmac & 3.12: only semi-working?

I'am in kernel 5.8.3.

Today I updated from .2 to .3.
I had not used wireless from a long time (+1 year) in this notebook.
So when I successfully connected to the router, and started browsing,
I had a complete freeze of my system. Not even ssh access.
Later I had the same complete freeze when I closed the lid; when I
went back to the device it was completely frozen.
journalctl -b -1 --system does not throw anything significant, no
indication of a kernel panic.

Now I am back to wired connection and no problems so far. So I suspect
it's the wireless card.

l$ sudo lspci -vnn -d 14e4:
02:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries
BCM4313 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01)
Subsystem: Askey Computer Corp. Device [144f:7179]
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at e1500000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-9f-ff-ff-be-b4-74
Capabilities: [16c] Power Budgeting <?>
Kernel modules: bcma

For now I have blacklisted this modules just in case.
b43
brcmsmac
bcma
mac80211

Has anyone been experiencing this issue in the aforementioned kernel version?