On 5/22/19 11:05 PM, Cleber Rosa wrote: > ----- Original Message ----- >> From: "Eduardo Habkost" <ehabk...@redhat.com> >> On Wed, Mar 13, 2019 at 12:45:41AM +0100, Philippe Mathieu-Daudé wrote: >>> From: Philippe Mathieu-Daudé <f4...@amsat.org> >>> >>> Similar to the x86_64/pc test, it boots a Linux kernel on a raspi2 >>> board and verify the serial is working. >>> >>> If ARM is a target being built, "make check-acceptance" will >>> automatically include this test by the use of the "arch:arm" tags. >>> >>> Alternatively, this test can be run using: >>> >>> $ avocado run -t arch:arm tests/acceptance >>> $ avocado run -t machine:raspi2 tests/acceptance >>> >>> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >> >> We're getting timeouts on travis-ci: >> https://travis-ci.org/ehabkost/qemu/jobs/535468057#L3289 >> >> I don't know yet if the guest is hanging, or if we just need to >> increase the timeout. I could reproduce the timeout locally, >> too.
That's odd, I can't reproduce (this test is quicker than the following test_arm_emcraft_sf2 which start u-boot then timeouts and start the kernel). My guess is network issues, since this test use a different mirror: archive.raspberrypi.org Gerd already raised this problem (timeout reached while fetching artifacts) to Cleber. Cleber, can we add test_setup() methods that use different timeouts? Regards, Phil. > It may be related to: > > https://bugs.launchpad.net/qemu/+bug/1829779 > > And this is a proof that we urgently need to have a better > way of presenting/storing test artifacts. The brief output > is nice when everything goes well, but makes the test results > close to useless once a failure happens. > > Philippe showed us how GitLab allows CI jobs to preserve > artifacts, so maybe the solution is to move the loads there. > > - Cleber. >
