NetBSD Problem Report #57219

From www@netbsd.org  Sun Feb  5 15:35:45 2023
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))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 6AFF21A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  5 Feb 2023 15:35:45 +0000 (UTC)
Message-Id: <20230205153543.95FA71A923A@mollari.NetBSD.org>
Date: Sun,  5 Feb 2023 15:35:43 +0000 (UTC)
From: als@thangorodrim.ch
Reply-To: als@thangorodrim.ch
To: gnats-bugs@NetBSD.org
Subject: ./configure for gcl-2.6.14 crashes kernel (reboot) on NetBSD 9.3 sparc64
X-Send-Pr-Version: www-1.0

>Number:         57219
>Category:       port-sparc64
>Synopsis:       ./configure for gcl-2.6.14 crashes kernel (reboot) on NetBSD 9.3 sparc64
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 05 15:40:00 +0000 2023
>Closed-Date:    Thu Feb 09 06:46:01 +0000 2023
>Last-Modified:  Thu Feb 09 06:46:01 +0000 2023
>Originator:     Alexander Schreiber
>Release:        NetBSD 9.3 release
>Organization:
>Environment:
NetBSD telperion.angband.thangorodrim.de 9.3 NetBSD 9.3 (TELPERION) #0: Sun Nov 27 15:17:20 CET 2022  root@telperion.angband.thangorodrim.de:/usr/obj/sys/arch/sparc64/compile/TELPERION sparc64

>Description:
Running ./configure for gcl-2.6.14 results in a kernel crash on
NetBSD 9.3 sparc64.

Machine info from dmesg:
machine type: SUNW,UltraAX-i2 (SUN V100), cpu type: SUNW,UltraSPARC-IIe
RAM: 2GB

Message printed on (serial) system console:

login: [ 2506097.5121967] panic: kernel diagnostic assertion "start < end" failed: file "/usr/src/sys/uvm/uvm_map.c", line 4754 
[ 2506097.6428290] cpu0: Begin traceback...
[ 2506097.6896165] cpu0: End traceback...
[ 2506097.7343230] Frame pointer is at 0x1788c2d71
[ 2506097.7343230] Call traceback:
[ 2506097.7343230]  netbsd:cpu_reboot+0x244(1678e28, 0, ffff, 16829d9, 1384720, 1834000) fp = 1788c2e51
[ 2506097.7343230]  netbsd:vpanic+0x174(104, 0, 163a9d0, 186d800, 0, 102707580) fp = 1788c2f01
[ 2506097.7343230]  netbsd:kern_assert+0x34(163a9d0, 1788c38f8, 1875400, 1876800, 104, 1876a38) fp = 1788c2fb1
[ 2506097.7343230]  netbsd:uvm_unmap1+0x74(163a9d0, 163a9c0, 168e170, 168e728, 1292, 101e8d780) fp = 1788c3071
[ 2506097.7343230]  netbsd:execve_runproc+0x248(108dcc8f0, 0, 0, 0, 0, 101e8d780) fp = 1788c3131
[ 2506097.7343230]  netbsd:execve1+0x48(102707580, 1788c3ad8, 0, 0, 1, 1035ee408) fp = 1788c3221
[ 2506097.7343230]  netbsd:syscall+0x384(102707580, 402a8c88, 402a8ca0, 402a8cb0, 1324a00, 182b760) fp = 1788c34f1
[ 2506097.7343230]  netbsd:1011724+0(1788c3ed0, c3b, 40951828, 3b, 1788c3f40, 102707580) fp = 1788c3621
[ 2506097.7343230]  netbsd:1105b8+0(402a8c88, 402a8ca0, 402a8cb0, 23b250, 160, 23bc04) fp = ffffffffffffbe91

[ 2506097.7343230] dumping to dev 12,1 offset 4194460
  2022 M [ 2506097.7343230] wddump: DMA error
[ 2506097.7343230] - device not ready
[ 2506098.0212054] cpu0: rebooting


Last few lines of ./configure output before the ssh session disconnects due to kernel crash:

#
#
#
# Subconfigure of GMP done
# ------------------------
#
checking for leading underscore in object symbols... "no"
checking "for GNU ld option -Map"... "yes"
checking for size of gmp limbs... 8
checking _SHORT_LIMB... no
checking _LONG_LONG_LIMB... no
checking for X... libraries /usr/X11R7/lib, headers /usr/X11R7/include
checking for main in -lX11... no
missing x libraries -- cannot compile xgcl
checking for xdr_double... yes
checking __builtin_clzl... yes
checking __builtin_ctzl... yes
checking __builtin___clear_cache... yes
checking size of long... 8
checking for time.h... yes
checking for sys/time.h... yes
checking size of time_t... 8
checking for byte order... big
checking for word order... big
checking for pagewidth... 13
checking for required object alignment... 8
checking for C extension variable alignment... __attribute__ ((aligned (8)))
checking for C extension noreturn function attribute... __attribute__ ((noreturn))
checking sizeof struct contblock... 16
checking for sbrk... yes
checking for ADDR_NO_RANDOMIZE constant... no assuming 0x40000
checking for ADDR_COMPAT_LAYOUT constant... no
checking for ADDR_LIMIT_3GB constant... no
checking for personality(ADDR_NO_RANDOMIZE) support... no
checking that sbrk is (now) non-random... yes
checking CSTACK_DIRECTION... -1
checking finding CSTACK_ALIGNMENT... 32
checking CSTACK_ADDRESS... 0xffffffffffffffff
checking cstack bits... 0
checking NEG_CSTACK_ADDRESS... yes
checking finding default linker script... got it
checking output_arch... bfd_arch_sparc
configure: trying to adjust text start
client_loop: send disconnect: Broken pipe


>How-To-Repeat:
(tested both as root and uid!=0 user)
download https://www.gnu.org/software/gcl//gcl-2.6.14.tar.gz
unpack the archive and cd into gcl-2.6.14
run: ./configure --prefix=/tmp/test

As observed, machine crashes at the same point in the configure run.

I have two mostly identical machines (one uses spinning rust,
the other SSD for storage), I'm willing to test patches.
>Fix:

>Release-Note:

>Audit-Trail:
From: Alexander Schreiber <als@thangorodrim.ch>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-sparc64/57219: ./configure for gcl-2.6.14 crashes kernel
 (reboot) on NetBSD 9.3 sparc64
Date: Sun, 5 Feb 2023 21:57:04 +0100

 Some further testing was done on NetBSD 9.3 amd64, where the configure
 actual goes past the point where it crashes on sparc64. Relevant output
 snippet:

 checking output_arch... bfd_arch_i386
 configure: trying to adjust text start    <----- crashes on sparc64 after this
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 configure: min log text start 20
 configure: max log text start 29
 configure: lowering log text to 300000 to maximize data area
 checking our linker script... done

 On NetBSD 9.3 amd64 the configure script later gives up because it has
 problems identifying the platform, but that is not relevant here.

 Also, I copied the URL to the gcl archive from their release email,
 where that link is sadly 404 compliant. 

 However, following the download link at https://www.gnu.org/software/gcl/
 which directs to their mirrors yields:

 http://mirror.metanet.ch/gnu/gcl/gcl-2.6.14.tar.gz

 which actually works.

 Further machine information (since this was requested on IRC): the
 sparc64 machines it crashes on have 2GB of ECC RAM.


From: Harold Gutch <logix@foobar.franken.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc64/57219: ./configure for gcl-2.6.14 crashes kernel (reboot) on NetBSD 9.3 sparc64
Date: Sun, 5 Feb 2023 22:54:05 +0100

 Hi,

 Unfortunately I cannot reproduce this in Qemu, I am seeing the same
 behavior there as on amd64:

   checking output_arch... bfd_arch_sparc
   configure: trying to adjust text start
   [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
   [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
   [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
   [...]

 The "trying to adjust text start" loop in the configure script starts
 prety much like this:

   echo "int main() {return 0;}" >foo.c

   gcc -no-pie -Wl,--verbose foo.c -o foo 2>&1 | \
      awk '/==================================================/{i=1-i;next}
      {if (i) print}' >gcl.script.def

   cat gcl.script.def | awk '/SIZEOF_HEADERS/ {gsub("0x[0-9]*","0x" j,$0);}
      {print}' j=0 >gcl.script

   gcc -no-pie -Wl,-T gcl.script foo.c -o foo

   ./foo

 What happens if you run this one by one in a shell?  Do you get the
 same panic when running "./foo"?


 thanks,
   Harold

From: Harold Gutch <logix@foobar.franken.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc64/57219: ./configure for gcl-2.6.14 crashes kernel (reboot) on NetBSD 9.3 sparc64
Date: Mon, 6 Feb 2023 00:33:25 +0100

 Built a kernel with DIAGNOSTIC after brief off-list discussion, and
 now I also see this panic in Qemu.

From: Harold Gutch <logix@foobar.franken.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc64/57219: ./configure for gcl-2.6.14 crashes kernel (reboot) on NetBSD 9.3 sparc64
Date: Mon, 6 Feb 2023 07:47:36 +0100

 I also tested netbsd-10 (from yesterday), and that panics at the same
 place (if DIAGNOSTIC is on).

 amd64 doesn't seem to be affected.  I haven't tested any other
 architectures.


   Harold

From: Alexander Schreiber <als@thangorodrim.ch>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-sparc64/57219: ./configure for gcl-2.6.14 crashes kernel
 (reboot) on NetBSD 9.3 sparc64
Date: Tue, 7 Feb 2023 02:26:45 +0100

 Rebuilt a GENERIC with full DEBUG enabled:

 options        DIAGNOSTIC      # extra kernel sanity checking
 makeoptions     DEBUG="-g"
 options         DEBUG
 options         LOCKDEBUG
 options         DB_MAX_WIDTH=160
 options         DDB_ONPANIC=2   # print stack trace


 ran ./configure again and got this
 on the serial console:

 login: [ 1533.9117629] vmcmds 0/8, error 12
 [ 1533.9512858] vmcmd[0] = vmcmd_map_pagedvn 0/0x2000 fd@0 prot=05 flags=4
 [ 1534.0302952]      ^--- failed
 [ 1534.0656327] vmcmd[1] = vmcmd_map_readvn 0x100000/0x1388 fd@0 prot=07 flags=4
 [ 1534.1508814] vmcmd[2] = vmcmd_map_pagedvn 0x40200000/0x14000 fd@0 prot=05 flags=2
 [ 1534.2402860] vmcmd[3] = vmcmd_map_zero 0x14000/0x100000 fd@0 prot=00 flags=1
 [ 1534.3244898] vmcmd[4] = vmcmd_map_readvn 0x114000/0xe88 fd@0x14000 prot=03 flags=1
 [ 1534.4149331] vmcmd[5] = vmcmd_map_zero 0xfffffffff7efe000/0x100000 fd@0 prot=00 flags=0
 [ 1534.5105806] vmcmd[6] = vmcmd_map_zero 0xfffffffff7ffe000/0x7e00000 fd@0 prot=00 flags=8
 [ 1534.6072559] vmcmd[7] = vmcmd_map_zero 0xffffffffffdfe000/0x200000 fd@0 prot=03 flags=8
 [ 1534.7028980] execve_dovmcmds: vmcmd 0 failed: 12
 [ 1534.7579983] panic: kernel diagnostic assertion "start < end" failed: file "/usr/src/sys/uvm/uvm_map.c", line 4754 
 [ 1534.8827368] cpu0: Begin traceback...
 [ 1534.9263989] cpu0: End traceback...
 [ 1534.9679831] Frame pointer is at 0x178852d51
 [ 1534.9679831] Call traceback:
 [ 1534.9679831]  netbsd:cpu_reboot+0x244(19d1b70, 0, ffff, 19a12e9, 1606580, 1c70000) fp = 178852e31
 [ 1534.9679831]  netbsd:vpanic+0x174(104, 0, 195e658, 1cc2000, 0, 1034b1a00) fp = 178852ee1
 [ 1534.9679831]  netbsd:kern_assert+0x34(195e658, 1788538d8, 1cd9000, 1cda400, 104, 1cda508) fp = 178852f91
 [ 1534.9679831]  netbsd:uvm_unmap1+0xa8(195e658, 195e648, 19f0350, 19f0980, 1292, 2014000) fp = 178853051
 [ 1534.9679831]  netbsd:execve_runproc+0x42c(103a68610, 0, 0, 0, 0, 101e81780) fp = 178853111
 [ 1534.9679831]  netbsd:execve1+0x48(c, 178853ad8, 30, 0, 0, 103a80e08) fp = 178853221
 [ 1534.9679831]  netbsd:syscall+0x3dc(1034b1a00, 402a8c88, 402a8ca0, 402a8cb0, 15a2740, 1c62660) fp = 1788534f1
 [ 1534.9679831]  netbsd:1011abc+0(178853ed0, c3b, 40951828, 3b, 178853f40, 1034b1a00) fp = 178853621
 [ 1534.9679831]  netbsd:1105b8+0(402a8c88, 402a8ca0, 402a8cb0, 23b250, 160, 23bc04) fp = ffffffffffffbec1

 [ 1534.9679831] dumping to dev 12,1 offset 4194460
     16 M [ 1534.9679831] wddump: DMA error
 [ 1534.9679831] - i/o error
 [ 1535.0219663] tlp0: receive ring overrun
 [ 1535.0676942] cpu0: rebooting

 Upon reboot, savecore actually wrote a 100 MB compressed core to /var/crash/ ..

From: "Harold Gutch" <hgutch@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57219 CVS commit: src/sys/arch/sparc64/include
Date: Tue, 7 Feb 2023 14:11:16 +0000

 Module Name:	src
 Committed By:	hgutch
 Date:		Tue Feb  7 14:11:16 UTC 2023

 Modified Files:
 	src/sys/arch/sparc64/include: vmparam.h

 Log Message:
 Avoid using (1<<64)-1 for VM_MAX{,USER}_ADDRESS as rounding that up to
 the next page boundary gives 0 and instead make the VA space end one
 page earlier.

 Fixes PR sparc64/57219.


 To generate a diff of this commit:
 cvs rdiff -u -r1.42 -r1.43 src/sys/arch/sparc64/include/vmparam.h

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

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57219 CVS commit: [netbsd-10] src/sys/arch/sparc64/include
Date: Wed, 8 Feb 2023 16:40:46 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Feb  8 16:40:46 UTC 2023

 Modified Files:
 	src/sys/arch/sparc64/include [netbsd-10]: vmparam.h

 Log Message:
 Pull up following revision(s) (requested by hgutch in ticket #71):

 	sys/arch/sparc64/include/vmparam.h: revision 1.43

 Avoid using (1<<64)-1 for VM_MAX{,USER}_ADDRESS as rounding that up to
 the next page boundary gives 0 and instead make the VA space end one
 page earlier.

 Fixes PR sparc64/57219.


 To generate a diff of this commit:
 cvs rdiff -u -r1.42 -r1.42.18.1 src/sys/arch/sparc64/include/vmparam.h

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

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57219 CVS commit: [netbsd-9] src/sys/arch/sparc64/include
Date: Wed, 8 Feb 2023 16:42:12 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Feb  8 16:42:12 UTC 2023

 Modified Files:
 	src/sys/arch/sparc64/include [netbsd-9]: vmparam.h

 Log Message:
 Pull up following revision(s) (requested by hgutch in ticket #1588):

 	sys/arch/sparc64/include/vmparam.h: revision 1.43

 Avoid using (1<<64)-1 for VM_MAX{,USER}_ADDRESS as rounding that up to
 the next page boundary gives 0 and instead make the VA space end one
 page earlier.

 Fixes PR sparc64/57219.


 To generate a diff of this commit:
 cvs rdiff -u -r1.39 -r1.39.4.1 src/sys/arch/sparc64/include/vmparam.h

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

From: Alexander Schreiber <als@thangorodrim.ch>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-sparc64/57219: ./configure for gcl-2.6.14 crashes kernel
 (reboot) on NetBSD 9.3 sparc64
Date: Thu, 9 Feb 2023 00:42:48 +0100

 Applied the aforementioned patch to the 9.3 release tree, kernel
 was rebuilt with the patch + DIAGNOSTIC + DEBUG and rebooted into
 it.

 Ran gcl ./configure again and it no longer crashes, but behaves
 as on amd64 (minus the segfault that doesn't happen there):

 configure: trying to adjust text start
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Abort trap              (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 [1]   Segmentation fault (core dumped) (${CC} ${LDFLAGS} -Wl,-T gcl.script foo.c -o f...
 configure: min log text start 19

 The console, however is pretty noisy, but that is expected when:
  - running with DEBUG
  - having user space code doing creative fuckery with VM mappings
    (as Lisps are prone to do)
 so there is lots of this:

 login: [ 1309.3109110] vmcmds 0/8, error 12
 [ 1309.3561572] vmcmd[0] = vmcmd_map_pagedvn 0/0x2000 fd@0 prot=05 flags=4
 [ 1309.4351499]      ^--- failed
 [ 1309.4705003] vmcmd[1] = vmcmd_map_readvn 0x100000/0x1388 fd@0 prot=07 flags=4
 [ 1309.5557414] vmcmd[2] = vmcmd_map_pagedvn 0x40200000/0x14000 fd@0 prot=05 flags=2
 [ 1309.6451453] vmcmd[3] = vmcmd_map_zero 0x14000/0x100000 fd@0 prot=00 flags=1
 [ 1309.7293514] vmcmd[4] = vmcmd_map_readvn 0x114000/0xe88 fd@0x14000 prot=03 flags=1
 [ 1309.8198050] vmcmd[5] = vmcmd_map_zero 0xfffffffff7efe000/0x100000 fd@0 prot=00 flags=0
 [ 1309.9154381] vmcmd[6] = vmcmd_map_zero 0xfffffffff7ffe000/0x7e00000 fd@0 prot=00 flags=8
 [ 1310.0121185] vmcmd[7] = vmcmd_map_zero 0xffffffffffdfe000/0x200000 fd@0 prot=03 flags=8
 [ 1310.1077601] execve_dovmcmds: vmcmd 0 failed: 12
 [ 1311.4319565] vmcmds 0/8, error 12
 [ 1311.4733745] vmcmd[0] = vmcmd_map_pagedvn 0/0x2000 fd@0 prot=05 flags=4
 [ 1311.5523666]      ^--- failed
 [ 1311.5877125] vmcmd[1] = vmcmd_map_readvn 0x100000/0x1388 fd@0 prot=07 flags=4
 [ 1311.6729583] vmcmd[2] = vmcmd_map_pagedvn 0x40200000/0x14000 fd@0 prot=05 flags=2
 [ 1311.7623631] vmcmd[3] = vmcmd_map_zero 0x14000/0x100000 fd@0 prot=00 flags=1
 [ 1311.8465705] vmcmd[4] = vmcmd_map_readvn 0x114000/0xe88 fd@0x14000 prot=03 flags=1
 [ 1311.9370176] vmcmd[5] = vmcmd_map_zero 0xfffffffff7efe000/0x100000 fd@0 prot=00 flags=0
 [ 1312.0326541] vmcmd[6] = vmcmd_map_zero 0xfffffffff7ffe000/0x7e00000 fd@0 prot=00 flags=8
 [ 1312.1293354] vmcmd[7] = vmcmd_map_zero 0xffffffffffdfe000/0x200000 fd@0 prot=03 flags=8
 [ 1312.2249828] execve_dovmcmds: vmcmd 0 failed: 12


 In summary: calling this fixed on actual sparc64 hardware as well.

State-Changed-From-To: open->closed
State-Changed-By: hgutch@NetBSD.org
State-Changed-When: Thu, 09 Feb 2023 06:46:01 +0000
State-Changed-Why:
Fixed in -current in Qemu and HW (confirmed by OP) and pulled up
to netbsd-9/netbsd-10.


>Unformatted:

Home	PR Database Search