[big skip]
Tried kernel 3.14 with this device. Still no go, the brcmsmac driver still
does not work correctly, it stalls as before.
Today I tried 3.16 kernel today too, just for fun (since this whole brcmsmac
thing looks not more like a non-working toy). Now with another laptop and
the same broadcom wifi adaptor (BRCM4313 802.11bgn Wireless Network Adapter
rev 01) (because due to cracked usb port on my original notebook it does not
work anymore).
This combination (kernel& wifi) does not work at all. Or, it is more jokish
than before -- the NIC works for ARP packets but nothing else, not even ping
or DNS or NTP. I see the access point sending replies (to pings or dns), but
these replies are not shown by tcpdump on the laptop. Even not all ARP packets
sent by the AP reaches the laptop.
So, I'm curious -- why this driver is found in regular section of kernel?
It looks like it should be in staging at least, or better yet, in a new section
titled "toy drivers" or something like this. Does it work for any device at
all?
Hi Michael,
Thanks for your encouraging suggestions. I revisited the threads you
referred to. In the boardflags it shows you have a bt+wifi card. It
could be that is an issue. The brcmsmac supports other devices, ie.
bcm43224/5 and the bcm4313 comes in a number of varieties. From what you
tell here it seems you have trouble in rx path so I will look into that
area if there is any specifically done for your variant of the bcm4313.
Regards,
Arend
Thanks,
/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Michael Tokarev <hidden> Date: 2014-08-26 16:15:34
26.08.2014 18:56, Arend van Spriel wrote:
On 08/26/14 07:13, Michael Tokarev wrote:
[]
quoted
So, I'm curious -- why this driver is found in regular section of kernel?
It looks like it should be in staging at least, or better yet, in a new section
titled "toy drivers" or something like this. Does it work for any device at
all?
Hi Michael,
Thanks for your encouraging suggestions.
You might be a good politician :) These are blames, quite strong...
Seriously. As you revisited this thread, I had quite some issues and
money loss after all this, -- after initially especially choosing a
model with a supported wifi card which turned out to be non-working,
which I tried to fix by buying a new wifi NIC (which didn't work
thanks to Lenovo), and which I finally broke due to usb wifi dongle
I used.
But that's all "poetry", the main source of my blames is you reaction -
your first reply was really ecoraging, I hoped we can have some solution
together (I have strong programming background, just not as good with
kernel and drivers as you). But after your single reply, you never
spoke again until now. That's 8 months. _That_ is where my frustration
comes from.
And the actual facts are true - by now I have had 2 entirely different
devices (my original laptop which is now thrown away and another, given
by me by a friend because I needed something) - I dunno if that's
exactly the same wifi card or not (lspci output looks similar, and
this one is also bt/wifi combo), but they both doesn't work in a
quite similar way. So, the driver doesn't work with 2 out of 2 devices
which I've seen. Not a good statistics generally, but that's 100%
"hit" ratio for me. So I really am curious if this driver works at
all.
I revisited the threads you referred to. In the boardflags it shows you
have a bt+wifi card. It could be that is an issue. The brcmsmac supports other
devices, ie. bcm43224/5 and the bcm4313 comes in a number of varieties.
From what you tell here it seems you have trouble in rx path so I will look
into that area if there is any specifically done for your variant of the bcm4313.
I tested this "new" laptop with 3.16 kernel just briefly. I may try more
complete analysis. I can participate with the debugging/dumping (I already
mentioned my strong programming background - but I'm really not into drivers
and hardware internals). So, basically, I'm all yours ;) Not that I really
need this driver anymore (since I will avoid these cards like a plague, for
obvious reasons :), but I want to have some good outcome out of all this
story :)
Thanks,
/mjt
From: Arend van Spriel <hidden> Date: 2014-08-26 21:37:33
On 08/26/14 18:15, Michael Tokarev wrote:
26.08.2014 18:56, Arend van Spriel wrote:
quoted
On 08/26/14 07:13, Michael Tokarev wrote:
[]
quoted
quoted
So, I'm curious -- why this driver is found in regular section of kernel?
It looks like it should be in staging at least, or better yet, in a new section
titled "toy drivers" or something like this. Does it work for any device at
all?
Hi Michael,
Thanks for your encouraging suggestions.
You might be a good politician :) These are blames, quite strong...
Seriously. As you revisited this thread, I had quite some issues and
money loss after all this, -- after initially especially choosing a
model with a supported wifi card which turned out to be non-working,
which I tried to fix by buying a new wifi NIC (which didn't work
thanks to Lenovo), and which I finally broke due to usb wifi dongle
I used.
But that's all "poetry", the main source of my blames is you reaction -
your first reply was really ecoraging, I hoped we can have some solution
together (I have strong programming background, just not as good with
kernel and drivers as you). But after your single reply, you never
spoke again until now. That's 8 months. _That_ is where my frustration
comes from.
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.
Admittedly the brcmsmac got very little attention as all our resources
were put on brcmfmac.
And the actual facts are true - by now I have had 2 entirely different
devices (my original laptop which is now thrown away and another, given
by me by a friend because I needed something) - I dunno if that's
exactly the same wifi card or not (lspci output looks similar, and
this one is also bt/wifi combo), but they both doesn't work in a
quite similar way. So, the driver doesn't work with 2 out of 2 devices
which I've seen. Not a good statistics generally, but that's 100%
"hit" ratio for me. So I really am curious if this driver works at
all.
quoted
I revisited the threads you referred to. In the boardflags it shows you
have a bt+wifi card. It could be that is an issue. The brcmsmac supports other
devices, ie. bcm43224/5 and the bcm4313 comes in a number of varieties.
From what you tell here it seems you have trouble in rx path so I will look
into that area if there is any specifically done for your variant of the bcm4313.
I tested this "new" laptop with 3.16 kernel just briefly. I may try more
complete analysis. I can participate with the debugging/dumping (I already
mentioned my strong programming background - but I'm really not into drivers
and hardware internals). So, basically, I'm all yours ;) Not that I really
need this driver anymore (since I will avoid these cards like a plague, for
obvious reasons :), but I want to have some good outcome out of all this
story :)
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.
Regards,
Arend
From: Michael Tokarev <hidden> Date: 2014-08-27 10:03:00
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.
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?
Thank you!
/mjt
From: Arend van Spriel <hidden> Date: 2014-08-27 15:27:42
On 08/27/14 12:02, Michael Tokarev wrote:
27.08.2014 01:37, Arend van Spriel wrote:
quoted
On 08/26/14 18:15, Michael Tokarev wrote:
[]
quoted
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.
quoted
Admittedly the brcmsmac got very little attention as all our resources were put on brcmfmac.
That happens. :)
[]
quoted
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.
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
From: Arend van Spriel <hidden> Date: 2014-09-15 08:03:31
On 27-08-14 17:27, Arend van Spriel wrote:
On 08/27/14 12:02, Michael Tokarev wrote:
quoted
27.08.2014 01:37, Arend van Spriel wrote:
quoted
On 08/26/14 18:15, Michael Tokarev wrote:
[]
quoted
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.
quoted
Admittedly the brcmsmac got very little attention as all our
resources were put on brcmfmac.
That happens. :)
[]
quoted
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
quoted
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
From: Michael Tokarev <hidden> Date: 2014-09-21 15:30:34
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] 0000000000000000 0000000000000009
[ 202.607780] Restarting tasks ... ffffffff814208bf 0000000000000000
[ 202.607783] ffffffff8104c926 ffff8800d5843d08 ffff8800d052f300 ffff8801189ea940
[ 202.607786] ffff8800d5843d00 0000000000000000 ffffffff8131c0d9 0000000000000000
[ 202.607790] Call Trace:
[ 202.607797] [<ffffffff814208bf>] ? dump_stack+0x41/0x51
[ 202.607802] [<ffffffff8104c926>] ? warn_slowpath_common+0x86/0xb0
[ 202.607807] [<ffffffff8131c0d9>] ? _request_firmware+0x439/0xa20
[ 202.607812] [<ffffffff8131c7a5>] ? request_firmware+0x35/0x60
[ 202.607816] [<ffffffffa0121780>] ? btusb_setup_bcm_patchram+0x70/0x3f0 [btusb]
[ 202.607823] [<ffffffffa0a0618d>] ? hci_dev_do_open+0x24d/0x8c0 [bluetooth]
[ 202.607829] [<ffffffff81082ade>] ? enqueue_task_fair+0x32e/0xce0
[ 202.607834] [<ffffffff8100bbb5>] ? sched_clock+0x5/0x10
[ 202.607839] [<ffffffff8107832b>] ? update_rq_clock+0x3b/0xd0
[ 202.607846] [<ffffffffa0a06818>] ? hci_power_on+0x18/0x120 [bluetooth]
[ 202.607877] [<ffffffff8106cad0>] ? kthread_freezable_should_stop+0x60/0x60
[ 202.607881] [<ffffffff81425dbc>] ? ret_from_fork+0x7c/0xb0
[ 202.607885] [<ffffffff8106cad0>] ? 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://<ip-over-wifi>/some-random-file
<Ctrl+C>
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
From: Michael Tokarev <hidden> Date: 2014-09-23 10:04:35
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.
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
From: Arend van Spriel <hidden> Date: 2014-09-23 12:47:48
On 09/23/14 12:04, Michael Tokarev wrote:
21.09.2014 19:30, Michael Tokarev wrote:
quoted
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.
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