NetBSD Problem Report #59165

From www@netbsd.org  Sun Mar  9 22:46:05 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)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D80CC1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  9 Mar 2025 22:46:04 +0000 (UTC)
Message-Id: <20250309224603.CDFF71A923C@mollari.NetBSD.org>
Date: Sun,  9 Mar 2025 22:46:03 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: vio9p(4): expose tag through sysctl or device properties
X-Send-Pr-Version: www-1.0

>Number:         59165
>Category:       kern
>Synopsis:       vio9p(4): expose tag through sysctl or device properties
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    ozaki-r
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 09 22:50:00 +0000 2025
>Closed-Date:    Mon Feb 02 03:53:05 +0000 2026
>Last-Modified:  Mon Feb 02 03:53:05 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The Net9P Mountation
>Environment:
>Description:
In virtio-9p, the host passes a tag identifying each possible 9p mount point to the guest.  The mount tag is an arbitrary(?) string configured in the host (e.g., qemu -device virtio-9p-pci,mount_tag=FOO,...).

Currently, NetBSD only prints it to dmesg:

[     1.049667] vio9p0: tagged as FOO

It would be nice if this were exposed to userland via sysctl, device properties, or something, so that, e.g., a devpubd(8) hook could automatically create a symlink for it.
>How-To-Repeat:
try to juggle a collection of /dev/vio9pN mount points in the guest and host VM configuration
>Fix:
Yes, please!

>Release-Note:

>Audit-Trail:
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Tue, 11 Mar 2025 12:30:58 +0900

 On Mon, Mar 10, 2025 at 7:50=E2=80=AFAM <campbell+netbsd@mumble.net> wrote:
 >
 > >Number:         59165
 > >Category:       kern
 > >Synopsis:       vio9p(4): expose tag through sysctl or device properties
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          change-request
 > >Submitter-Id:   net
 > >Arrival-Date:   Sun Mar 09 22:50:00 +0000 2025
 > >Originator:     Taylor R Campbell
 > >Release:        current, 10, 9, ...
 > >Organization:
 > The Net9P Mountation
 > >Environment:
 > >Description:
 > In virtio-9p, the host passes a tag identifying each possible 9p mount po=
 int to the guest.  The mount tag is an arbitrary(?) string configured in th=
 e host (e.g., qemu -device virtio-9p-pci,mount_tag=3DFOO,...).
 >
 > Currently, NetBSD only prints it to dmesg:
 >
 > [     1.049667] vio9p0: tagged as FOO
 >
 > It would be nice if this were exposed to userland via sysctl, device prop=
 erties, or something, so that, e.g., a devpubd(8) hook could automatically =
 create a symlink for it.
 > >How-To-Repeat:
 > try to juggle a collection of /dev/vio9pN mount points in the guest and h=
 ost VM configuration
 > >Fix:
 > Yes, please!
 >

 I have a patch for systctl:
 https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.patch
 Does it satisfy the demand?

   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: gnats-bugs@netbsd.org
Cc: Ryota Ozaki <ozaki-r@netbsd.org>
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Tue, 11 Mar 2025 12:52:57 +0100

 On Tue, Mar 11, 2025 at 12:30:58PM +0900, Ryota Ozaki wrote:
 > I have a patch for systctl:
 > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.patch
 > Does it satisfy the demand?

 Thanks for working on this.  This could be very useful.

 If you attach multiple virtio-9p file systems to the VM, does your patch
 create hw.vio9p0.tag, hw.vio9p1.tag etc.?

 --chris

From: Ryota Ozaki <ozaki-r@netbsd.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Mon, 17 Mar 2025 17:33:44 +0900

 On Tue, Mar 11, 2025 at 8:53=E2=80=AFPM Christoph Badura <bad@bsd.de> wrote=
 :
 >
 > On Tue, Mar 11, 2025 at 12:30:58PM +0900, Ryota Ozaki wrote:
 > > I have a patch for systctl:
 > > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.patch
 > > Does it satisfy the demand?
 >
 > Thanks for working on this.  This could be very useful.
 >
 > If you attach multiple virtio-9p file systems to the VM, does your patch
 > create hw.vio9p0.tag, hw.vio9p1.tag etc.?

 Thank you for pointing this out. It assumed there was just one vio9p.
 I've put a fixed version:
 https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v2.patch

 Thanks,
   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: gnats-bugs@netbsd.org
Cc: Ryota Ozaki <ozaki-r@netbsd.org>
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Tue, 18 Mar 2025 00:27:00 +0100

 On Mon, Mar 17, 2025 at 05:33:44PM +0900, Ryota Ozaki wrote:
 > On Tue, Mar 11, 2025 at 8:53 PM Christoph Badura <bad@bsd.de> wrote:
 > > If you attach multiple virtio-9p file systems to the VM, does your patch
 > > create hw.vio9p0.tag, hw.vio9p1.tag etc.?
 > Thank you for pointing this out. It assumed there was just one vio9p.

 I've been using at least two since last summer. :-)

 > I've put a fixed version:
 > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v2.patch

 I guess the change from the previsous version is the use of
 device_xname(self) in:
 +	    device_xname(self), SYSCTL_DESCR("VirtIO 9p status"),

 That all looks fine to me.

 There is one more thing to think about: discoverability.
 How do we find out which hw.vio9pN sysctl nodes exist?

 Of course, we can do "sysctl hw | grep \^hw.vio9p" and process that.
 But that seems not right to me.
 We should have something like hw.disknames for vio9p.
 Maybe hw.vio9p.instances with a list of the instance names as strings?

 That shouldn't prevent you from committing your change

 Actually, I wish used a better MIB design in sysctl.
 Like:
   hw.vio9p.instances = vio9p0 vio9p1
   hw.vio9p.vio9p0.tag = tag1
   hw.vio9p.vio9p1.tag = tag2

 And likewise:
   hw.vm.wm0.*
   hw.vm.wm1.*
 etc.

 And a way for sysctl to just enumerate the immediate children of a node
 Like:
   $ sysctl --enumerate-children hw.wm
   hw.wm.wm0
   hw.wm.wm1
   $

 But we don't have that.  We could make a start with the hw.vio9p sub-MIB,
 though.

 But perhaps this should be discussed on tech-kern.

 --chris

From: Ryota Ozaki <ozaki-r@netbsd.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Tue, 25 Mar 2025 16:46:28 +0900

 I'm sorry for late reply...

 On Tue, Mar 18, 2025 at 8:27=E2=80=AFAM Christoph Badura <bad@bsd.de> wrote=
 :
 >
 > On Mon, Mar 17, 2025 at 05:33:44PM +0900, Ryota Ozaki wrote:
 > > On Tue, Mar 11, 2025 at 8:53=E2=80=AFPM Christoph Badura <bad@bsd.de> w=
 rote:
 > > > If you attach multiple virtio-9p file systems to the VM, does your pa=
 tch
 > > > create hw.vio9p0.tag, hw.vio9p1.tag etc.?
 > > Thank you for pointing this out. It assumed there was just one vio9p.
 >
 > I've been using at least two since last summer. :-)
 >
 > > I've put a fixed version:
 > > https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v2.patch
 >
 > I guess the change from the previsous version is the use of
 > device_xname(self) in:
 > +           device_xname(self), SYSCTL_DESCR("VirtIO 9p status"),
 >
 > That all looks fine to me.

 Thanks.

 >
 > There is one more thing to think about: discoverability.
 > How do we find out which hw.vio9pN sysctl nodes exist?
 >
 > Of course, we can do "sysctl hw | grep \^hw.vio9p" and process that.
 > But that seems not right to me.
 > We should have something like hw.disknames for vio9p.
 > Maybe hw.vio9p.instances with a list of the instance names as strings?
 >
 > That shouldn't prevent you from committing your change
 >
 > Actually, I wish used a better MIB design in sysctl.
 > Like:
 >   hw.vio9p.instances =3D vio9p0 vio9p1
 >   hw.vio9p.vio9p0.tag =3D tag1
 >   hw.vio9p.vio9p1.tag =3D tag2
 >
 > And likewise:
 >   hw.vm.wm0.*
 >   hw.vm.wm1.*
 > etc.
 >
 > And a way for sysctl to just enumerate the immediate children of a node
 > Like:
 >   $ sysctl --enumerate-children hw.wm
 >   hw.wm.wm0
 >   hw.wm.wm1
 >   $

 That reminds me of a RESTful API that requires listing up available endpoin=
 ts.
 I agree with the demand for discoverability, but in this case (sysctl
 MIBs) I don't
 desire it so much because, as you said, we can know the existing of sysctl =
 MIBs
 by using grep, etc. The proposed MIB design may help to make scripts simple=
 ,
 but I'm not sure if it's essential for everyone.

 >
 > But we don't have that.  We could make a start with the hw.vio9p sub-MIB,
 > though.
 >
 > But perhaps this should be discussed on tech-kern.

 I agree.

   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: Ryota Ozaki <ozaki-r@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Wed, 9 Apr 2025 19:38:42 +0200

 Darn, I wanted to reply earlier.

 On Tue, Mar 25, 2025 at 04:46:28PM +0900, Ryota Ozaki wrote:
 > That reminds me of a RESTful API that requires listing up available endpoints.

 I was reminded of SNMP.

 > I agree with the demand for discoverability, but in this case (sysctl
 > MIBs) I don't
 > desire it so much because, as you said, we can know the existing of sysctl MIBs
 > by using grep, etc. The proposed MIB design may help to make scripts simple,
 > but I'm not sure if it's essential for everyone.

 That's fine for scripts that run infrequently.  But it doesn't really work
 for stuff like systat or node_exporter which would query the MIB
 frequently.

 But we can address that later if the need arrives.

 --chris

From: Ryota Ozaki <ozaki-r@netbsd.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Thu, 17 Apr 2025 12:40:58 +0900

 On Thu, Apr 10, 2025 at 2:38=E2=80=AFAM Christoph Badura <bad@bsd.de> wrote=
 :
 >
 > Darn, I wanted to reply earlier.
 >
 > On Tue, Mar 25, 2025 at 04:46:28PM +0900, Ryota Ozaki wrote:
 > > That reminds me of a RESTful API that requires listing up available end=
 points.
 >
 > I was reminded of SNMP.
 >
 > > I agree with the demand for discoverability, but in this case (sysctl
 > > MIBs) I don't
 > > desire it so much because, as you said, we can know the existing of sys=
 ctl MIBs
 > > by using grep, etc. The proposed MIB design may help to make scripts si=
 mple,
 > > but I'm not sure if it's essential for everyone.
 >
 > That's fine for scripts that run infrequently.  But it doesn't really wor=
 k
 > for stuff like systat or node_exporter which would query the MIB
 > frequently.
 >
 > But we can address that later if the need arrives.

 Okay, I've prepared another patch that adds intermediate node, hw.vio9p,
 so I think it allows us to do further work on it:
   https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v3.patch

 BTW, with the new patch, sysctl hw.vio9p iterates available nodes of
 vio9p devices:
   kvm# sysctl hw.vio9p
   hw.vio9p.vio9p0.tag =3D test
   hw.vio9p.vio9p1.tag =3D test2

 Does this behavior just satisfy your demand?

   ozaki-r

From: Christoph Badura <bad@bsd.de>
To: Ryota Ozaki <ozaki-r@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device
 properties
Date: Thu, 17 Apr 2025 15:55:57 +0200

 On Thu, Apr 17, 2025 at 12:40:58PM +0900, Ryota Ozaki wrote:
 > Okay, I've prepared another patch that adds intermediate node, hw.vio9p,
 > so I think it allows us to do further work on it:
 >   https://www.netbsd.org/~ozaki-r/vio9p-tag-sysctl.v3.patch
 > 
 > BTW, with the new patch, sysctl hw.vio9p iterates available nodes of
 > vio9p devices:
 >   kvm# sysctl hw.vio9p
 >   hw.vio9p.vio9p0.tag = test
 >   hw.vio9p.vio9p1.tag = test2

 Wow! Thank you!  I really didn't expect that you would do this.  Thanks
 again!

 > Does this behavior just satisfy your demand?

 I wouldn't call it a demand.  More a suggestion and what I would prefer.

 --chris

From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59165 CVS commit: src/sys/dev/pci
Date: Tue, 22 Apr 2025 05:56:25 +0000

 Module Name:	src
 Committed By:	ozaki-r
 Date:		Tue Apr 22 05:56:25 UTC 2025

 Modified Files:
 	src/sys/dev/pci: vio9p.c

 Log Message:
 vio9p: export tag via sysctl

 With this change, we can see tags of virtio-9p devices via sysctl:
   # sysctl hw.vio9p
   hw.vio9p.vio9p0.tag = test
   hw.vio9p.vio9p1.tag = test2

 PR kern/59165


 To generate a diff of this commit:
 cvs rdiff -u -r1.11 -r1.12 src/sys/dev/pci/vio9p.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 24 Apr 2025 12:24:43 +0000
State-Changed-Why:
Thanks!  I will try this out when I have a chance.  Might be worth
pullup-10 too.


State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: ozaki-r@NetBSD.org
State-Changed-When: Mon, 12 May 2025 01:56:10 +0000
State-Changed-Why:
pullup-10 and pullup-9 done


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59165 CVS commit: [netbsd-10] src/sys/dev/pci
Date: Thu, 15 May 2025 17:53:24 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Thu May 15 17:53:24 UTC 2025

 Modified Files:
 	src/sys/dev/pci [netbsd-10]: vio9p.c

 Log Message:
 Pull up following revision(s) (requested by ozaki-r in ticket #1115):

 	sys/dev/pci/vio9p.c: revision 1.12

 vio9p: export tag via sysctl

 With this change, we can see tags of virtio-9p devices via sysctl:
   # sysctl hw.vio9p
   hw.vio9p.vio9p0.tag = test
   hw.vio9p.vio9p1.tag = test2

 PR kern/59165


 To generate a diff of this commit:
 cvs rdiff -u -r1.9.4.1 -r1.9.4.2 src/sys/dev/pci/vio9p.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Greg A. Woods" <woods@planix.ca>
To: NetBSD-current Users Discussion List <current-users@netbsd.org>
Cc: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>,
    NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Tue, 25 Nov 2025 17:39:19 -0800

 --pgp-sign-Multipart_Tue_Nov_25_17:39:11_2025-1
 Content-Type: text/plain; charset=US-ASCII

 I was looking into when and why vio9p(4) started working (on amd64 I
 have it working in 10.99.12, as of early April) and I ran into mention
 of a sysctl to see the tag names, and then I found PR#59165.

 There's no mention of this sysctl node in the viop(4) manual page
 though, nor in sysctl(7) (though I wouldn't expect it in the latter).

 I see the code is there in sys/dev/pci/vio9p.c, but it doesn't seem to
 work for me:


 $ uname -a
 NetBSD nbt2.local 10.99.12 NetBSD 10.99.12 (GENERIC) #1: Tue Apr  8 14:29:37 PDT 2025  woods@very.local:/Users/woods/build/woods/very.local/trunk-x86_64-amd64-obj/Volumes/work/woods/g-NetBSD-src/sys/arch/amd64/compile/GENERIC amd64
 $ /sbin/modstat | fgrep vio9p
 vio9p                      driver   builtin  -        0       - virtio
 $ fgrep vio9p /var/run/dmesg.boot
 vio9p0 at virtio3: features: 0x10000001<INDIRECT_DESC,MOUNT_TAG>
 virtio3: allocated 24576 byte for virtqueue 0 for vio9p, size 128
 vio9p0: tagged as share
 $ /sbin/sysctl hw.vio9p
 sysctl: second level name 'vio9p' in 'hw.vio9p' is invalid
 $ /sbin/sysctl -a | fgrep vio9p
 kern.drivers = [[...]], [356 -1 vio9p], [[...]]

 I think the code looks right, and given I see the output of the device
 printf that's executed right above that code, well....

 For the record I'm running this under QEMU, with UTM, on macOS(i386),
 and accessing the shared directory via 9p is working very well.

 Is anyone else who might be using vio9p(4) seeing this sysctl node?

 --
 					Greg A. Woods <gwoods@acm.org>

 Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

 --pgp-sign-Multipart_Tue_Nov_25_17:39:11_2025-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 Content-Description: OpenPGP Digital Signature

 -----BEGIN PGP SIGNATURE-----

 iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCaSZaQQAKCRBmfXG3eL/0
 fwiBAKCA9CpvBt2i9YggIkscw2/G03UuOgCePiWy8kG71pZrOqGMljfSfsy4h+A=
 =oA6C
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Tue_Nov_25_17:39:11_2025-1--

From: "Greg A. Woods" <woods@planix.ca>
To: NetBSD-current Users Discussion List <current-users@netbsd.org>,
	NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>,
	NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
Date: Thu, 27 Nov 2025 12:30:43 -0800

 --pgp-sign-Multipart_Thu_Nov_27_12:30:35_2025-1
 Content-Type: text/plain; charset=US-ASCII

 At Tue, 25 Nov 2025 17:39:19 -0800, "Greg A. Woods" <woods@planix.ca> wrote:
 Subject: Re: kern/59165: vio9p(4): expose tag through sysctl or device properties
 >
 > I see the code is there in sys/dev/pci/vio9p.c, but it doesn't seem to
 > work for me:

 Ooops!  It does work.  The wrong kernel was booted.  The right one was
 installed, but not booted.  I should have seen that in the uname output,
 but somehow it didn't click.

 > $ uname -a
 > NetBSD nbt2.local 10.99.12 NetBSD 10.99.12 (GENERIC) #1: Tue Apr  8 14:29:37 PDT 2025  woods@very.local:/Users/woods/build/woods/very.local/trunk-x86_64-amd64-obj/Volumes/work/woods/g-NetBSD-src/sys/arch/amd64/compile/GENERIC amd64

 An even newer kernel is now confirmed as booted:

 $ uname -a
 NetBSD nbt2.local 11.99.4 NetBSD 11.99.4 (GENERIC) #1: Thu Nov 27 10:58:12 PST 2025  woods@very.local:/Users/woods/build/woods/very.local/trunk-x86_64-amd64-obj/Volumes/work/woods/g-NetBSD-src/sys/arch/amd64/compile/GENERIC amd64

 $ /sbin/sysctl  hw.vio9p
 hw.vio9p.vio9p0.tag = share


 Sorry for the false report!


 In other news though the vio9p device(s) doesn't show up as a disk, and
 so its I/O stats don't get reported by systat:

  $ /sbin/sysctl  hw.disknames
 hw.disknames = ld0 dk0 dk1 dk2 dk3 dk4 dk5

 Is that (partly) because they are character devices?

 During a sysinst upgrade with sets on the vio9p device I noted that the
 read speed seemed to be around 12MB/s, which couldn't even keep the root
 filesystem and disk an more than about 30% busy.

 --
 					Greg A. Woods <gwoods@acm.org>

 Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

 --pgp-sign-Multipart_Thu_Nov_27_12:30:35_2025-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 Content-Description: OpenPGP Digital Signature

 -----BEGIN PGP SIGNATURE-----

 iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCaSi07QAKCRBmfXG3eL/0
 f2VuAJ9fHRRH7PdmjbDJ3NcQgSS8sphz1wCgm2bFfA3RHbf+w6QjrKsGQX7TOiE=
 =dKsN
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Thu_Nov_27_12:30:35_2025-1--

Responsible-Changed-From-To: kern-bug-people->ozaki-r
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Mon, 02 Feb 2026 03:53:05 +0000
Responsible-Changed-Why:


State-Changed-From-To: pending-pullups->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Mon, 02 Feb 2026 03:53:05 +0000
State-Changed-Why:
fixed and pulled up to netbsd-10, not worth it for netbsd-9


>Unformatted:

Home	PR Database Search