On Tue, 2023-03-07 09:55:58 +0100, Martin Husemann <martin%duskware.de@localhost> wrote: > On Mon, Mar 06, 2023 at 09:46:02PM +0100, Jan-Benedict Glaw wrote: > > If anybody has a verified "it worked at this version" for me, I'd be > > quite grateful. It's not too much fun cross-building a 10 y old code > > base with a modern toolchain... > > There are always the old release ISOs from archive.netbsd.org that you > can try ;-) > > The oldest image I had lying around in my simh folder was 6.99.44 from > June 2014 and it did not work. I did --- all broken :) Actually, I'm a baby step further: [ 1.9300030] kern.module.path=/stand/vax/10.99.2/modules [ 5.2800030] r0=00000000 r1=80364200 r2=00000000 r3=9fe98c80 r4=80d0cf34 r5=00000000 r6=9fd22024 r7=00000000 [ 5.2800030] r8=9fe771c0 r9=801e2314 r10=9fe74000 r11=00004000 [ 5.2800030] ap=a71e59cc fp=a71e59b8 sp=7ffff298 pc=80016e5e [ 5.2800030] panic: SEGV in kernel mode: pc 0x80016e5e addr 0xbedababe [ 5.2800030] cpu0: Begin traceback... [ 5.2800030] panic: SEGV in kernel mode: pc 0x80016e5e addr 0xbedababe [ 5.2800030] Stack traceback : [ 5.2800030] Process is executing in user space. [ 5.2800030] cpu0: End traceback... Stopped in pid 100.100 (sh) at netbsd:vpanic+0x179: pushl $0 db> bt panic: SEGV in kernel mode: pc 0x80016e5e addr 0xbedababe Stack traceback : 0xa71e5810: vpanic+0x179(0x802a2073,0xa71e58a8) 0xa71e5830: vprintf+0x0(0x802a2073,0x80016e5e,0xbedababe) 0xa71e585c: trap+0x7a5(0xa71e5968) 0xa71e5968: trap type=0x8c code=0xbedababe pc=0x80016e5e psl=0xc00004 0xa71e5934: _do_cas+0xe(0x80364200) 0xa71e59b8: brelse+0x12(0x9fe78d90,0) 0xa71e59d8: ffs_init_vnode+0x1fd(0x9fe771c0,0x9fdf1c68,0x60b4a,0) 0xa71e5a0c: ffs_loadvnode+0x2d(0x9fe75000,0x9fdf1c68,0xa71e5b80,0x8,0xa71e5aa8) 0xa71e5a58: vcache_get+0x153(0x9fe75000,0xa71e5b80,0x8,0xa71e5b78) 0xa71e5abc: ufs_lookup+0x898(0xa71e5bc0) 0xa71e5b8c: VOP_LOOKUP+0x45(0x9fe443a4,0xa71e5c04,0xa71e5d88) 0xa71e5bd4: lookup_once+0x1f1(0xa71e5d1c,0x9fe443a4,0xa71e5c9c,0xa71e5ca0,0xa71e5c9b) 0xa71e5c0c: namei_tryemulroot.constprop.0+0x5ec(0xa71e5d1c,0,0,0) 0xa71e5cd8: namei+0x30(0xa71e5d60) 0xa71e5d38: vn_open+0xbe(0,0x9ffb2d40,0x10,0x1,0x900,0xa71e5e80,0xa71e5e7b,0xa71e5e84) 0xa71e5e28: do_open+0x8e(0x9fe98c80,0,0x9ffb2d40,0,0x900,0xa71e5f18) 0xa71e5e90: do_sys_openat+0x5a(0x9fe98c80,0xffffff9c,0x7ffff374,0,0x900,0xa71e5f18) 0xa71e5ee0: sys_open+0x1e(0x9fe98c80,0xa71e5f54,0xa71e5f4c) 0xa71e5f20: syscall+0x182(0xa71e5fb4) The address 0xbedababe is actually a marker, should be placed at the end of the S0 address space. So I guess we're just accidentally hitting a boarder of NetBSD's address space layout here. Haven't understood the code yet, though. (But I also dropped Matt an email.) Thanks, Jan-Benedict --
Attachment:
signature.asc
Description: PGP signature