While working on a bug report for zimh pmetzger/zimh#20 I came across a bug in open-simh that seems to occur only if you are running open-simh on a single-cpu machine. I discovered it in a VM that I set up at $WORK.
Booting a NetBSD install dvd (.iso file) runs into a Machine Check in NetBSD's boot loader when loading the kernel.
It seems to be related to something with timing, locks, threads, or similar. When I went to reproduce it just now so I could paste the output, the Machine Check failed to happen (and the boot proceeded perfectly normally). The second time it did:
$ simh-microvax3900 netbsd.ini
MicroVAX 3900 simulator Open SIMH V4.1-0 Current simh git commit id: 7994e0a7 Build: Unsupported=include+lib
/home/netbsd/netbsd.ini-4> attach nvr nvram.bin
%SIM-INFO: NVR: buffering file in memory
/home/netbsd/netbsd.ini-10> attach rq1 NetBSD-11.0_RC7-vax.iso
%SIM-INFO: RQ1: Unit is read only
%SIM-INFO: RQ1: 'NetBSD-11.0_RC7-vax.iso' Contains an ISO 9660 filesystem
%SIM-INFO: RQ1: Volume Identifier: NETBSD_110_RC7 Containing 234336 2048 Byte Sectors
/home/netbsd/netbsd.ini-32> boot cpu
%SIM-INFO: Loading boot code from internal ka655x.bin
KA655X-B V5.3, VMB 2.7
Performing normal system tests.
40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..
24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..
08..07..06..05..04..03..
Tests completed.
>>>boot dua1
(BOOT/R5:0 DUA1
2..
-DUA1
1..0..
>> NetBSD/vax boot [1.12 (Thu Jul 23 05:11:42 UTC 2026)] <<
>> Press any key to abort autoboot 0
getdisklabel: no disk label
nfs_open: must mount first.
open netbsd.vax: No such file or directory
> boot netbsd
getdisklabel: no disk label
nfs_open: must mount first.
Machine check, pc=7dcd3c, psl=4140008
>
The netbsd.ini file is
; Command file for simh-vax (a 3900)
; Usage: simh-vax $0
; Attach non-volatile RAM to a file
attach nvr nvram.bin
set cpu 256m
set rq0 ra92
; attach rq0 netbsd.dsk
set rq1 cdrom
; https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-11/20260723051142Z/images/NetBSD-11.0_RC7-vax.iso
attach rq1 NetBSD-11.0_RC7-vax.iso
set rq2 ra92
; attach rq2 NetBSD-9.99.92-vax-live.img
set xq type=DELQA ; set XQ TYPE={DEQNA|DELQA|DELQA-T}
; ipv6 for nat is only supported in zimh, not in open-simh.
; attach xq0 nat:dhcp
; attach xq0 nat:dhcp,ipv6
; attach xq0 tap:tap0
; set debug /dev/stderr
; set XQ DEBUG=TRACE;CSR;VAR;WARN;RBDL;XBDL;SETUP;SANITY;REG;PACKET;DATA;ETH
set idle=netbsd
set cpu noautoboot
; set console brk=5 ; HLT, to the >>> prompt
; set console wru=5 ; to the simh> prompt
;
; Choose one of the following lines. SET CPU CONHALT returns control to the
; VAX console monitor on a halt event (where behavior will be further
; determined by whether auto-boot is set--see above. SET CPU SIMHALT will
; cause the simulator to get control instead.
set cpu conhalt
;set cpu simhalt
boot cpu
The boot image is from https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-11/20260723051142Z/images/NetBSD-11.0_RC7-vax.iso but it probably doesn't have to be exactly that one.
When running the VM with 4 cpus, the machine check doesn't happen.
Zimh has the same problem, so there is probably a common cause. I can give access to the VM if wanted; I would probably duplicate the user so that it won't interfere with potential debugging from the zimh side. (I should mention that the simh-microvax3900 binary was not compiled on that vm so I would need to set it up for local compilation)
While working on a bug report for zimh pmetzger/zimh#20 I came across a bug in open-simh that seems to occur only if you are running open-simh on a single-cpu machine. I discovered it in a VM that I set up at $WORK.
Booting a NetBSD install dvd (.iso file) runs into a Machine Check in NetBSD's boot loader when loading the kernel.
It seems to be related to something with timing, locks, threads, or similar. When I went to reproduce it just now so I could paste the output, the Machine Check failed to happen (and the boot proceeded perfectly normally). The second time it did:
The
netbsd.inifile isThe boot image is from https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-11/20260723051142Z/images/NetBSD-11.0_RC7-vax.iso but it probably doesn't have to be exactly that one.
When running the VM with 4 cpus, the machine check doesn't happen.
Zimh has the same problem, so there is probably a common cause. I can give access to the VM if wanted; I would probably duplicate the user so that it won't interfere with potential debugging from the zimh side. (I should mention that the simh-microvax3900 binary was not compiled on that vm so I would need to set it up for local compilation)