Pi3B wifi brcmf_sdio_hdparse #1313
Comments
|
Yes, I've seen those. My theory is that they are caused by out-of-order packet arrival, and that they are related to a low-power mode of the 43430. Try opening a connection (e.g. ssh) with a keepalive of less than 30 seconds and see if the messages still appear. |
|
I'm not convinced it has anything to do with power management. I'm seeing them during heavy traffic. Mar 01 20:47:28 brcmfmac: brcmf_sdio_hdparse: seq 249: sequence number error, expect 248 I think this may need reporting back to Broadcom. I'm not sure what they are responsible for..... Just hardware and firmware..... Or driver as well? |
|
I also think this "out of sequence" issue, may have some bearing on the crappy peak throughput numbers, less then 30Mbps. I've gotten used to 100Mbps peak throughput from the "cheap as chips" mt7601u dongles. Whilst I appreciate that my use case(s), wouldn't be classed as "educational", (streaming high-res audio), and although I don't have hard numbers in front of me for them, IIRC, Wandboard and Cubietruck, which both use earlier revisions of bcm43xx hardware, were capable of peak throughput > 40Mbps. Anyway, I've tested to the point where it's now time to decide that the on-board wi-fi "feature" isn't suitable for my use case(s), blacklist the brcmfmac module and use the dongles I was using with previous Pi hardware. |
|
And not that I believe this has any bearing on this, but it is curious...... Raspbian...... The Ubuntu MATE image is shipping .... I'm not sure where they both got the firmware..... Assume it must have been directly from PiF. (It doesn't appear to be in linux-firmware repo. Which is a problem in itself, for other distributions that wont ship firmware unless it has been accepted into linux-firmware.......) |
|
I'm seeing the same problem. I did tests with the older firmware (Sep 4 2015 16:45:22), problems are worse with it. But I still get those errors with the Dec 15 2015 18:10:45 -version. |
|
Just FYI, I'm also seeing this periodically with a very simple Arch linux setup after setting up WiFi. In my case, I'm not streaming anything at all and have almost nothing running at the time (it was idling over night). I'm not sure what services might actually have tried to do anything at all. Perhaps the time sync?. |
|
I also tested with the patch that disabled power mgmt 1f13305 Didn't help. |
|
Broadcom are aware of the issue. They believe that it is a threading problem within the driver, and they are working on a fix. |
|
The apparent link with power saving was just coincidental - I have also seen those messages since the patch, although they are still rare for me. |
|
Not so rare, used as a music streamer with constant wi-fi traffic, continuously playing back 44k1/16/2 media....
|
|
Glad to see this isn't just me. :) Ubuntu Mate w/a kernel built the day before yesterday... interesting re the different firmware versions. Is there some place where Broadcom posts the latest version? |
|
If it helps, I saw this today accompanied by a load of traces in dmesg: Am using the RP3 as a headless access point (you can see hostapd mentioned in the trace) running FC23 setup as described here: http://hobo.house/2016/03/13/installing-fedora-linux-on-the-raspberry-pi-3/ |
|
I am also using a RP3 as a wifi access point, Kernel 4.1.10-v7+, and am seeing these messages as well in the kernel log. Out of order or not, I haven't noticed anything using the access point on a plus note. |
|
For me, this seems to be associated with a crashof the wifi stuff so that wlan0 gets disconnected and I have to do a Attached is stuff from syslog. |
|
Still happens with 4.4.7 perhaps resort packets in kernel? |
|
I was getting these crashes so the pi 3 would not run for as much as a day. I added heat sinks (and perhaps updated some software, although I don't know exactly what) and they've stayed alive for more than 2 days now. At the same time I added heat sinks, I added a cron thingie that would check every 2 minutes and appropriately kick the net if it found the wifi down. I has not needed to do a kick since the heat sinks. |
|
I wonder if this is related to issue #1471? ("Memory leak in pi3 wifi driver?") |
|
brcmf_sdio_hdparse is called in drivers/net/wireless/brcm80211/brcmfmac/sdio.c line 1952 when the reorder problem occurs. |
|
happens on 4.4.11-v7+ 888 SMP continuously: |
|
Just installed Mate 16.04 last night, seeing this problem. |
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
|
I also see these error messages: |
|
Broadcom have released a patch that changes the error messages to debug message, with the following commit message: I've applied this patch to rpi-4.4.y. |
|
broom... carpet... lift... sweep.... ;) It might not actually be an error, as far as they are concerned, but from what I experienced, the throughput goes down the toilet as soon as those out of sequence messages start appearing..... How do they explain that? I suspect the fact that the logging is "fixed", isn't going to fix the throughput issue. (Not that it affects me. I stopped using the Pi3B on-board wifi some time ago.) |
|
@clivem Pi3B on-board wifi sucks and no one knows, why? |
|
@koppi Well, this latest gen Broadcom 43 series chipset that the Pi3B uses, does seem to have throughput issues compared to the earlier generation BRCM 43 series chips that I have come across on other SBC's. Even though you cant expect class leading performance, (it's 'n', but 20MHz single channel 'n'), from the testing I did back in March when the Pi3B was launched, against on-board BRCM 43xxx wifi with Wandboard and Cubietruck, the Pi3B's average wifi throughput was under half the WB and CT with the best conditions, (ie. only client of the AP), but embarrassingly bad once the "out of sequence" logging started, to the point where I couldn't even stream 96/24 audio without continual stuttering. Easily "fixed" with a $2 MT7601U dongle. ;) |
|
@clivem ok, thank's for your explanation – good to see, that I'm not the only one who ran into this issue. I too bought an MT7601U dongle as a work-around. |
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: #1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
kernel: Add ads1015 overlay See: raspberrypi/linux#1520 kernel: brcmfmac: change rx_seq check log from error print to debug print See: raspberrypi/linux#1313 kernel: brcmfmac: use ndev->needed_headroom to reserve additional header space See: raspberrypi/linux#1357 kernel: brcmfmac: revise SDIO error message in brcmf_sdio_drivestrengthinit kernel: BCM270X_DT: Make i2c-gpio usable by other overlays kernel: BCM270X_DT: Fix rpi-dac overlay See: http://forum.kodi.tv/showthread.php?tid=269814&pid=2349776#pid2349776 kernel: Implement a wakeup-source option for the i2c-rtc DeviceTree overlay See: raspberrypi/linux#1511 kernel: gpio-ir-receiver: fix overlay and add upstream patches See: raspberrypi/linux#1514 firmware: Tuner: Disable unused ACLS tuner, and improve logging firmware: imx219: Remove static variable firmware: ISP Tuners: Make DPF parsing thread safe firmware: audioplus: Allow passthrough dma priority to be overridden in same way as pcm firmware: di_adv: Remove delay uniform firmeare: di_adv: Enable limiter and tweak axi priorities
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
The bus rx sequence is not in order because that control and event frames always cause immediate send, but data frames may be held for glomming in firmware side. It is not actually an error as the packets are still processed even if the RX sequence is not in order. Therefore the error message is rephrased and changed to a debug message. [ Patch from Broadcom ] See: raspberrypi/linux#1313
@pelwell Phil, is this expected????? I've got pages and pages of them? (Not something I've seen before with bcmfmac driver, and I've used it before with several other SBC's.)
brcmfmac: brcmf_sdio_hdparse: seq 106: sequence number error, expect 108
brcmfmac: brcmf_sdio_hdparse: seq 109: sequence number error, expect 108
brcmfmac: brcmf_sdio_hdparse: seq 110: sequence number error, expect 109
The text was updated successfully, but these errors were encountered: