Re: port-arm/59292 (releng testbed: missing atf xml/html results)

["Andreas Gustafsson via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-arm/59292; it has been noted by GNATS.

From: Andreas Gustafsson <gson%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: gson%netbsd.org@localhost,
    port-arm-maintainer%netbsd.org@localhost,
    gnats-admin%netbsd.org@localhost,
    skrll%NetBSD.org@localhost,
    campbell+netbsd%mumble.net@localhost
Subject: Re: port-arm/59292 (releng testbed: missing atf xml/html results)
Date: Sat, 11 Jul 2026 20:59:50 +0300

 More than a year ago, Taylor R Campbell wrote:
 > As noted at the top of https://releng.netbsd.org/b5reports/evbarm-earmv7hf/:
 >
 > > ATF HTML reports and XML files are missing due to the lack of
 > > support for more than one block device in VEXPRESS_A15, but the
 > > console output is available.
 >
 > But we have now nixed the VEXPRESS_A15 kernel config in favour of (I
 > assume) GENERIC.  Surely, even if the VEXPRESS_A15 kernel config
 > didn't support more than one block device, GENERIC should?
 > Or is this a limitation in qemu's `-M vexpress-a15' machine, despite the
 > apparently-unused virtio0-3 devices I see in the dmesg output?
 
 The problem with making anita take advantage of the new block devices
 that appeared with the switch from the VEXPRESS_A15 kernel to GENERIC
 (while still using the vexpress-a15 machine type) is that it would
 break the ability of anita to run tests on versions from before the
 switch.
 
 Perhaps a better solution would be to switch the b5 evbarm-earmv7hf
 testbed to use the "virt" machine type, because anita already supports
 using two block devices with that.  That would make the testbed (but
 not anita) lose the ability to run tests on versions of NetBSD that do
 not yet support the virt machine type, but since recent versions of
 NetBSD are unable to host builds of versions older than
 2020.05.22.22.59.14 anyway, that wouldn't break anything that is not
 already broken.  The memory size of the VM would have to be bumped
 from the current 128 MB because of the following issue mentioned in
 PR 59560:
 
   If you run the ATF tests under qemu using the "virt" machine type
   instead of "vexpress-a15", with the same 128 MB of memory, the tmpfs
   somehow gets created with a size even smaller than the nominal 25%
   = 32 MB, and a large number of tests again fail.
 
 Does that seem like a reasonable plan?
 
 > If it's really a limitation on block devices, could we use vio9p to
 > export the results instead?
 
 That would be even more limiting in terms of what versions can be tested
 (if it even works).
 -- 
 Andreas Gustafsson, gson%NetBSD.org@localhost