| Summary: | qemuppc ping test failure | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [QA/Testing] Runtime Testing | Reporter: | Richard Purdie <richard.purdie> | ||||||
| Component: | oeqa/runtime | Assignee: | Unassigned <unassigned> | ||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | Medium | CC: | alexandre.belloni, bruce.ashfield, paulg, randy.macleod, sakib.sajal, steve | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 4.0 | ||||||||
| Hardware: | x86 | ||||||||
| OS: | Multiple | ||||||||
| Whiteboard: | AB-INT | ||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||||
| Attachments: |
|
||||||||
|
Description
Richard Purdie
2021-07-07 07:12:02 UTC
Looking at other successful qemuppc logs, th RTNETLINK message appears normal but the "chmod: /var/log/wtmp: No such file or directory Failed to set mode -0664- for -/var/log/wtmp-" is not. I reran the test manually in the same build directory with the same image. The most interesting thing was on this run: QMP connected to QEMU at 07/07/21 07:26:56 and took 3.456681966781616 seconds QMP released QEMU at 07/07/21 07:26:57 and took 1.1139729022979736 seconds from connect runqemu - INFO - Copy done in 0.14536833763122559 seconds whilst on the failed run: QMP connected to QEMU at 07/07/21 01:26:34 and took 24.899512767791748 seconds QMP released QEMU at 07/07/21 01:27:18 and took 43.95131969451904 seconds from connect runqemu - INFO - Copy done in 0.26656150817871094 seconds In some tests the wtmp error is present, in some it is not, it doesn't affect the ping success/failure. The RTNETLINK message is always there. In one test run it took a long time, core-image-minimal () - Ran 66 tests in 17.148s vs core-image-minimal () - Ran 66 tests in 2642.934s and in the latter, the time seemed to be spent getting single characters over serial very slowly with periodic timeouts. dmesg for the failing case shows boot in 13.4s, the success case was 9.2s. dmesg is pretty much identical except the usb stack init is later compared to the rest of the system in the success case. top and ps output show the same processes running with no significant looking differences. Created attachment 4810 [details]
Failure dmesg
Created attachment 4811 [details]
Success dmesg
Netconsole might be an option. I think that Paul has found a worlflow that might help with qemuppc hangs... Not seen in months. Occurred again in the dunfell 3.1.32 release build: https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/8596/steps/14/logs/stdio Not reopening though since it happens less than once a year. |