Bug 205211
| Summary: | Kernel dump while copying large files via network on odroidc1 (meson8b) | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Piero Ottuzzi (ottuzzi) |
| Component: | Platform | Assignee: | drivers_platform (drivers_platform) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | dirkneukirchen |
| Priority: | P1 | ||
| Hardware: | ARM | ||
| OS: | Linux | ||
| Kernel Version: | 5.3.3 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Piero Ottuzzi
2019-10-16 09:00:46 UTC
possible duplicate or similar bug: https://bugzilla.kernel.org/show_bug.cgi?id=205787 observed on Armbian Nightly with 5.3.11 and 5.3.8 on Odroid-C1 (revision without heatsink) Problem is probably expressed in irregular iperf results (running on USB ethernet 100mbit interface) running iperf -s on the odroid I get these results accessing it from another machine iperf -c <odroidc1> -i 2 -t 60 ------------------------------------------------------------ Client connecting to 192.168.3.198, TCP port 5001 TCP window size: 144 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.3.192 port 55142 connected with 192.168.3.198 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 2.0 sec 2.68 MBytes 11.3 Mbits/sec [ 3] 2.0- 4.0 sec 15.2 MBytes 64.0 Mbits/sec [ 3] 4.0- 6.0 sec 22.4 MBytes 93.8 Mbits/sec [ 3] 6.0- 8.0 sec 2.46 MBytes 10.3 Mbits/sec [ 3] 8.0-10.0 sec 13.4 MBytes 56.1 Mbits/sec [ 3] 10.0-12.0 sec 22.5 MBytes 94.4 Mbits/sec [ 3] 12.0-14.0 sec 13.8 MBytes 58.0 Mbits/sec [ 3] 14.0-16.0 sec 127 KBytes 521 Kbits/sec [ 3] 16.0-18.0 sec 18.2 MBytes 76.5 Mbits/sec [ 3] 18.0-20.0 sec 22.2 MBytes 93.3 Mbits/sec [ 3] 20.0-22.0 sec 8.47 MBytes 35.5 Mbits/sec [ 3] 22.0-24.0 sec 127 KBytes 521 Kbits/sec [ 3] 24.0-26.0 sec 192 KBytes 785 Kbits/sec [ 3] 26.0-28.0 sec 4.60 MBytes 19.3 Mbits/sec [ 3] 28.0-30.0 sec 255 KBytes 1.04 Mbits/sec [ 3] 30.0-32.0 sec 63.6 KBytes 261 Kbits/sec [ 3] 32.0-34.0 sec 18.4 MBytes 77.1 Mbits/sec [ 3] 34.0-36.0 sec 5.80 MBytes 24.3 Mbits/sec [ 3] 36.0-38.0 sec 7.00 MBytes 29.4 Mbits/sec [ 3] 38.0-40.0 sec 1.14 MBytes 4.78 Mbits/sec [ 3] 40.0-42.0 sec 2.18 MBytes 9.15 Mbits/sec [ 3] 42.0-44.0 sec 11.2 MBytes 46.9 Mbits/sec [ 3] 44.0-46.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 46.0-48.0 sec 127 KBytes 521 Kbits/sec [ 3] 48.0-50.0 sec 63.6 KBytes 261 Kbits/sec [ 3] 50.0-52.0 sec 63.6 KBytes 261 Kbits/sec [ 3] 52.0-54.0 sec 127 KBytes 521 Kbits/sec [ 3] 54.0-56.0 sec 63.6 KBytes 261 Kbits/sec [ 3] 56.0-58.0 sec 127 KBytes 521 Kbits/sec [ 3] 58.0-60.0 sec 63.6 KBytes 261 Kbits/sec [ 3] 0.0-60.2 sec 193 MBytes 26.9 Mbits/sec Hi, in previous kernel versions (maybe 5.1... not really sure) I found that using performance governor (so excluding any kind of frequency scaling) the problem was less present (maybe totally disappeared but I was not stressing so much to be sure) and performance was stable (25MBytes/sec) copying files from my Win10 laptop to odroidc1 via SMB. Thank you for your input I tested using cpufreq-set -g performance to change the governor after reboot and the problem seems to dissappear /not reproducible with a short iperf test - no dumps and no performance degradation on iperf running iperf -c 192.168.3.198 -i 2 -t 60 with default ondemand governor: 2/3 times dumps after 1 run, the third execution did dump after 2 runs (so 120 seconds) ; (soft) rebooted after a dump occured -> soft reboot and governor change iperf -c 192.168.3.198 -i 2 -t 60 with performance governor: no dump (600s runs fine too), no dump on git clone linux-amlogic repo [ 4] local 192.168.3.198 port 5001 connected with 192.168.3.192 port 39140 [ 4] 0.0-600.1 sec 6.58 GBytes 94.1 Mbits/sec So either the bug is with the ondemand governor or its just more difficult to reproduce with performance governor Hi, I think the bug is in the frequency scaling code and not in a specific governor: as ondemand is continuosly changing CPU frequency it is the fastest method to expose a bug :) |