-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QEMU serial output is not reliable, may affect SLIP and thus network testing #8187
Comments
Still an issue with new qemu? |
Can retest to be 100% sure, bit I don't see any that part of qemu change any longer. Indirectly, it's the same - MicroPythin testsuite running over QEMU serial emu has ~50% chance to fail: https://ci.linaro.org/view/lite-iot-ci/job/lite-aeolus-micropython/ |
Well, I'm actually pleasantly surprised, because the situation is visibly improved, running with qemu from SDK 0.9.5. First run of dumb_http_server/qemu_cortex_m3 with I then proceeded with
But note that the type of failure is different from the original description above: there it was hang with eventual timeout, here quick ECONNRESET. Another ECONNRESETs are repeatable, the longest run I got from 3 was:
|
But! Now qemu_x86 and qemu_cortex_m3 switched their positions, i.e. SLIP comm with qemu_x86 seems to be significantly broken:
Got these timeouts 2 times in row (again much less than on 1000th req). All that happened with Summing up: yes, QEMU SLIP is still not reliable, yes. |
@rlubos, Given that this comes from your report, can you please put qemu_x86/qemu_cortex_m3 under some ordeal too? |
Have you tried with native_posix board? Just wondering if this is something related to SLIP or serial connection, or if the issue is in other part of the networking stack. |
Fairly speaking no, as I find network setup of native_posix kinda cumbersome.
As the title of this ticket suggest, the best hypothesis is that the problem on the side of QEMU emulation. The behavior I experienced is that SLIP driver gets e.g. 783 bytes packet, and spools it into the UART. However, Wireshark sees just truncated 275 bytes packet, which of course gets discarded. |
Qemu has now native ethernet support so we could start to migrate away from SLIP. Closing this one. |
Well, closing is s bit of haste, given the "we can start". And this ticket is about serial output non-reliability, not just networking as affected by it. So, I'll likely reopen it when hitting issue again. |
This ticket provides a (partial) answer of why the issue described in #7831 (comment) happens, specifically:
ab -n1000 http://192.0.2.1:8080/
,ab
eventually times outSo, it's more or less know issue, but it's not always kept in mind: UART emulation in QEMU is sub-ideal, and there can be problems with serial communication, which is used by SLIP and loop-slip-tap.sh. This is what happens here.
For example, SLIP driver logging:
What we can see here is that pkt 0x20001e78 was transmitted twice. But here's what Wireshark sees:
As can be seen, instead of first 783 bytes packet it receives broken 275 bytes packet, which gets ignored by host. That's what causes retransmission, and next time the packet gets thru.
The text was updated successfully, but these errors were encountered: