Hi!
On Tue, 2023-03-07 07:57:17 -0500, emanuel stiebler <emu%e-bbes.com@localhost> wrote:
> On 2023-03-06 15:46, Jan-Benedict Glaw wrote:
> > Current NetBSD doesn't boot in SIMH with 512 MB of RAM configured. I'm
> > quite convinced that this worked in the past. However, I don't have a
> > reference and picked a random commit: about 10 years ago when the SIMH
> > idle detection has been added.
>
> Could you please share your configuration?
> (CPU, MEM, Devices,...)
> Sorry, don't use SIMH ...
I'm sorry, my first reply did go directly to Emanuel.
So... This is plain SIMH (https://github.com/open-simh/simh) with a
minimal pre-setup (for TAP networking) and config running on a Linux
host:
TAP=tap_vax
tunctl -t "${TAP}" || true
ip link set "${TAP}" up || true
brctl addif br0 "${TAP}" || true
./BIN/vax vax-netbsd-localboot.simh
# cat vax-netbsd-localboot.simh
SHOW VERSION
LOAD -r /var/cache/git/simh/VAX/ka655x.bin
#SET CPU 512m
SET CPU 256m
SET CPU idle=netbsd
#SET RQ0 ra92
SET RQ0 rauser=50000
ATTACH RQ0 netbsd.dsk
SET RQ1 cdrom
ATTACH RQ1
/var/cache/laminar-vm/simh-vax-netbsd/images/NetBSD-10.99.2-vax.iso
SET XQ mac=08-00-2b-a0-0e-22
ATTACH XQ tap:tap_vax
SHOW CONFIG
# =======================================================
# 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.
# >>>
# =======================================================
EXPECT ">>>" SEND "boot dua0\r"; CONTINUE
BOOT CPU
EXIT
That's simulating a MicroVAX 3900 with a faked amount of 512 MB
memory. (The real hardware would only allow for 64 MB.)
As far as I have heared in the mean time, both Ultrix and VMS were
successfully tested with 512 MB. With that much RAM, I get a nice
kernel crash (as indicated in an earlier email):
[ 1.9900030] boot device: ra0
[ 1.9900030] root on ra0a dumps on ra0b
[ 1.9900030] root file system type: ffs
[ 1.9900030] kern.module.path=/stand/vax/10.99.2/modules
[ 3.1100030] r0=00000020 r1=9fe44364 r2=00000020 r3=00000000 r4=80d0cf34 r5=00000000 r6=a71fbd88 r7=a71fbd60
[ 3.1100030] r8=a71fbd1c r9=a71fbcac r10=9fe441e4 r11=a71fbcb8
[ 3.1100030] ap=a71fbc48 fp=a71fbc34 sp=7ffff84c pc=80016e5e
[ 3.1100030] panic: SEGV in kernel mode: pc 0x80016e5e addr 0xbedababe
[ 3.1100030] cpu0: Begin traceback...
[ 3.1100030] panic: SEGV in kernel mode: pc 0x80016e5e addr 0xbedababe
[ 3.1100030] Stack traceback :
[ 3.1100030] Process is executing in user space.
[ 3.1100030] cpu0: End traceback...
Stopped in pid 106.106 (stty) at netbsd:vpanic+0x179: pushl $0
db> bt
panic: SEGV in kernel mode: pc 0x80016e5e addr 0xbedababe
Stack traceback :
0xa71fba8c: vpanic+0x179(0x802a2073,0xa71fbb24)
0xa71fbaac: vprintf+0x0(0x802a2073,0x80016e5e,0xbedababe)
0xa71fbad8: trap+0x7a5(0xa71fbbe4)
0xa71fbbe4: trap type=0x8c code=0xbedababe pc=0x80016e5e psl=0xc00004
0xa71fbbb0: _do_cas+0xe(0x9fe44364)
0xa71fbc34: namei_tryemulroot.constprop.0+0xb33(0xa71fbd1c,0,0,0)
0xa71fbcd8: namei+0x30(0xa71fbd60)
0xa71fbd38: vn_open+0xbe(0,0x9ffb2db0,0x10,0x1,0,0xa71fbe80,0xa71fbe7b,0xa71fbe84)
0xa71fbe28: do_open+0x8e(0x9fc3f4c0,0,0x9ffb2db0,0,0,0xa71fbf18)
0xa71fbe90: do_sys_openat+0x5a(0x9fc3f4c0,0xffffff9c,0x7eee9307,0,0,0xa71fbf18)
0xa71fbee0: sys_open+0x1e(0x9fc3f4c0,0xa71fbf54,0xa71fbf4c)
0xa71fbf20: syscall+0x182(0xa71fbfb4)
I have yet to understand the 0xbedababe filler, it was specifically
placed by Matt. (In the GIT mirror, it's
6a98e8539f9813c1f389846b80ea8c769d983ebb of Nov 13, 2010.) I guess
that with 0.5 GB, it's hitting memory boundaries between S0/1 and
P0/1, but I haven't yet dived deep into the NetBSD source code.
MfG, JBG
--
Attachment:
signature.asc
Description: PGP signature