Re: [PULL 00/21] Test updates (tuxrun tests, new QTest maintainer, ...)

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 21 Oct 2024 at 15:11, Thomas Huth <thuth@redhat.com> wrote:
> Looking at the log files of the job, I can see in
> https://gitlab.com/qemu-project/qemu/-/jobs/8141649069/artifacts/browse/build/tests/functional/aarch64/test_aarch64_tuxrun.TuxRunAarch64Test.test_arm64be/
> console.log:
>
> 2024-10-21 13:20:32,844: Run /sbin/init as init process
> 2024-10-21 13:20:34,043: EXT4-fs (vda): re-mounted. Opts: (null). Quota
> mode: none.
> 2024-10-21 13:20:34,350: Starting syslogd: OK
> 2024-10-21 13:20:34,423: Starting klogd: OK
> 2024-10-21 13:20:34,667: Running sysctl: OK
> 2024-10-21 13:20:34,739: Saving 2048 bits of non-creditable seed for next boot
> 2024-10-21 13:20:34,966: Starting network: blk_update_request: I/O error,
> dev vda, sector 5824 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
> 2024-10-21 13:20:35,028: blk_update_request: I/O error, dev vda, sector 8848
> op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
> 2024-10-21 13:20:35,051: OK
> 2024-10-21 13:20:35,088: blk_update_request: I/O error, dev vda, sector
> 12936 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
> 2024-10-21 13:20:35,149: blk_update_request: I/O error, dev vda, sector
> 17032 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
> 2024-10-21 13:20:35,181: Welcome to TuxTest
> 2024-10-21 13:20:35,882: tuxtest login: blk_update_request: I/O error, dev
> vda, sector 21128 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
> 2024-10-21 13:20:35,882: blk_update_request: I/O error, dev vda, sector
> 25224 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
> 2024-10-21 13:20:35,882: blk_update_request: I/O error, dev vda, sector
> 29320 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
> 2024-10-21 13:20:35,887: root
>
> So this is indeed more than just a timeout setting that is too small...
> I don't get the virtio errors when running the test locally, though.
> I guess this needs some more investigation first ... maybe best if I respin
> the PR without this patch for now 'til this is understood and fixed.

I guess big-endian is one of the setups most likely to be
broken :-)

-- PMM