Closed Drachenkaetzchen closed 3 years ago
Drachenkaetzchen
commented
3 years ago I just noticed that the WiFi interface seems to be attached to mmc1 which is initialized as high speed SDHC:
[ 3.099665] mmc1: new high speed SDIO card at address 0001According to Wikipedia, the high speed mode supports 25 MB/s, which would explain why the issue occurs only with 3 clients and 10 MB/s transfer rate each.
pelwell
commented
3 years ago I don't think you can rule out power supply - the built-in detector only picks up gross undervoltage events on the main supply line, and doesn't necessarily notice when isolated areas of the device don't quite get the voltage they need to function correctly. The official power supply is only really intended to power the Pi itself, a mouse and a keyboard. I've successfully powered an SSD in a USB carrier at the same time, but the WiFi and Bluetooth subsystems were idle at the time.
I don't think you will get much more than about 110Mb/s through the WiFi, once you've factored in the multiple protocol overheads, i.e. about 1.5 of your 10MB/s streams.
Drachenkaetzchen
commented
3 years ago I don't think you can rule out power supply - the built-in detector only picks up gross undervoltage events on the main supply line, and doesn't necessarily notice when isolated areas of the device don't quite get the voltage they need to function correctly. The official power supply is only really intended to power the Pi itself, a mouse and a keyboard. I've successfully powered an SSD in a USB carrier at the same time, but the WiFi and Bluetooth subsystems were idle at the time.
The issue also occurred when I didn't have an SSD via USB attached (= booted from an SD card with no other USB devices attached).
I don't think you will get much more than about 110Mb/s through the WiFi, once you've factored in the multiple protocol overheads, i.e. about 1.5 of your 10MB/s streams.
The issue is not that I'm getting too little bandwidth - the issue is that the attempt to transfer more data than the link supports triggers the problem which results in a non-responsive system.
pelwell
commented
3 years ago If what you are saying is correct then an iperf/iperf3 to a PC with a high-speed 5G WiFi interface should be enough to crash the WiFi stack, but I've never seen that happen. Also, firmware crashes are trapped and reported to the brcmfmac driver, so the symptoms don't quite match.
I suggest you try slightly increasing the voltage supplied to the board (the exact power requirements vary from unit to unit) - put over_voltage=2 in config.txt and either remove the USB peripherals or put them on a powered hub.
Drachenkaetzchen
commented
3 years ago I suggest you try slightly increasing the voltage supplied to the board (the exact power requirements vary from unit to unit) - put
over_voltage=2in config.txt and either remove the USB peripherals or put them on a powered hub.
Citing myself:
The issue also occurred when I didn't have an SSD via USB attached (= booted from an SD card with no other USB devices attached).
What makes you think it's an undervoltage problem?
pelwell
commented
3 years ago Years of experience.
Drachenkaetzchen
commented
3 years ago Years of experience.
Years of experience comes with ignorance of facts, I guess.
Drachenkaetzchen
commented
3 years ago Closing the issue as there doesn't seem to be any interest in fixing kernel bugs.
Short Description
When running ustreamer to stream the RPI camera over the network with 10 megabytes/s per client, and 3 clients connected, the system becomes non-responsive with the following messages appearing in
dmesg(excerpt)Verbose Description
I run ustreamer to stream video over the network. On my Raspberry Pi 4, this seems to trigger an issue where either the WiFi hardware or the driver crashes if I connect to the video stream from multiple machines. For a single client, this is about 10 megabytes per second. The WiFi interface is on a 5 GHz 325Mbit/s connection.
When about 3 clients are connected and the system tries to transfer about 30 megabytes per second over the wifi, the system often becomes non-responsive after a random amount of time. It is noteworthy that as soon as the non-responsive state is reached, the attached serial console via USB shows the kernel log extremely slowly, suggesting that the system is under heavy load by that issue.
However, writing the output of
dmesgto a text file still seems to work. As such, I can rule out power supply issues as the system is using the original USB-C power supply for the Raspberry Pi 4, since an undervoltage condition would appear in the log. The captured log when the problem occurs can be found below.It is noteworthy that the issue does not seem to occur if using an USB WiFi stick.
To reproduce Since the issue only appears after a random amount of time, it's hard to reproduce. Any clues on how to make this reproducible are appreciated.
Expected behaviour The system stays responsive even if the WiFi interface is under heavy load.
Actual behaviour The systembecomes unresponsive under heavy WiFi load.
System
Raspberry Pi 4 Model B Rev 1.1 PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)"
Full raspinfo output pastebin
Logs