NetBSD Problem Report #59292

From www@netbsd.org  Sun Apr 13 18:51:20 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CCA511A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 13 Apr 2025 18:51:19 +0000 (UTC)
Message-Id: <20250413185118.595321A923D@mollari.NetBSD.org>
Date: Sun, 13 Apr 2025 18:51:18 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: releng testbed: missing atf xml/html results
X-Send-Pr-Version: www-1.0

>Number:         59292
>Category:       port-arm
>Synopsis:       releng testbed: missing atf xml/html results
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gson
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 13 18:55:00 +0000 2025
>Last-Modified:  Sat Jul 11 18:00:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
Test ArmBSD Results Extraction
>Environment:
>Description:
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?  If it's really a limitation on block devices, could we use vio9p to export the results instead?
>How-To-Repeat:
anita test arm32, probably
>Fix:
Yes, please!

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: port-arm-maintainer->gson
Responsible-Changed-By: skrll@NetBSD.org
Responsible-Changed-When: Sat, 21 Mar 2026 17:02:28 +0000
Responsible-Changed-Why:
Is this something you can fix Andreas? Either anita, or releng, or both


From: Andreas Gustafsson <gson@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: gson@netbsd.org,
    port-arm-maintainer@netbsd.org,
    gnats-admin@netbsd.org,
    skrll@NetBSD.org,
    campbell+netbsd@mumble.net
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

>Unformatted:

Home	PR Database Search