[Simh] NetBSD 5.1 on MicoVAX 3900 boot error

[Mark Pizzolato]

On Wednesday, April 19, 2017 at 5:45 AM, Peter Conrad Cumminsky wrote:
> On Tue, 18 Apr 2017, Mark Pizzolato wrote:
> > On Tuesday, April 18, 2017 at 8:57 AM, Peter Conrad Cumminsky wrote:
> >> On Mon, 17 Apr 2017, Mark Pizzolato wrote:
> >>
> >>> On Monday, April 17, 2017 at 10:28 AM, petercpm at sdf.org wrote:
> >>>> I'm getting a Segv error on boot of NetBSD 5.1 on the VAX emulator of
> >> SIMH v
> >>>> 4.0 Beta. Install went fine w/o any problems. I'm attaching the session
> file
> >> and
> >>>> here's the netbsd-boot file:
> >>>>
> >>>> ............................................................
> >>>> load -r ..\..\..\..\bin\ka655x.bin
> >>>> set cpu 64m
> >>>> ; SET CPU IDLE=NETBSD
> >>>> set tto 7b
> >>>> ; AT DZ 8888
> >>>> set rq0 ra92
> >>>> at rq0 netbsd.dsk
> >>>> at xq0 eth0
> >>>> boot cpu
> >>>>
> >>>> ; At the VMB prompt, type boot dua0:
> >>>> ............................................................
> >>>
> >>> I vaguely recall that there was at least one NetBSD version that was just
> >> broken and hadn't been tested on any VAX (real or simulated) before it was
> >> 'released'.
> >>>
> >>> I suggest you:
> >>> 1) try the same with simh 3.9
> >>> 2) try a later NetBSD release.
> >>>
> >>> If you're seeing a problem which persists across several NetBSD releases,
> >> and/or exists in the 4.0 code but not the 3.9 code, please open an issue at
> >> https://github.com/simh/simh/issues
> >>>
> >>> Have Fun.
> >>>
> >>> - Mark Pizzolato
> >>>
> >>
> >> Thanks for the tips and info.
> >>
> >> I've tried all versions of NetBSD 5.x (5.0.2, 5.1, 5.1.5, 5.2 and
> >> 5.2.3) that I can find on SIMH 4.0 beta and they all Segv. I have an old
> >> NetBSD 3 that boots and I tried NetBSD 6.0.4 and that also boots.
> >>
> >> I am not able to run earlier versions of SIMH as I'm on Windows 10 64-bit
> >> and WinPCAP does not run on W10. I use NPcap on W10 and that doesn't
> >> work on earlier versions of SIMH which require WinPcap.
> >
> > You shouldn't need WinPCAP merely to test if the CD image is bootable.
> > The point of the boot test exercise is to help determine if the problem is
> > in NetBSD or due to recent changes to simh.  If changes to simh are at
> > fault, I'll track it down and fix the problem.
> >
> >> I specifically want to run a 5.x version of NetBSD. I'm pretty sure it did
> >> run on SIMH 3.8-1 on Windows 7 before the upgrade. I need to downgrade
> a
> >> laptop I have to Win7 in the future and may try that. Until then I'll play
> >> with OpenBSD which doesn't seem to have any problems with SIMH 4.0
> beta.
> >
> > The boot test I'm suggesting will be far less work than setting up another
> > system.
> >
> > Let me know.
> >
> > - Mark
> >
> >
> 
> As I mentioned in my OP the NetBSD 5.x iso's installation works fine - no
> problems with cd-rom boot. The first boot of the installed NetBSD 5.x Segv's
> as per the original file attachment in my OP.
> 
> I installed the SIMH 3.9 vax.exe and ka655x.bin in a seperate directory
> and ran the installed NetBSD 5.1. It booted w/o the Segv (and did not give
> me the WinPCAP error since I used the sans-network version of SIMH 3.9).
> 
> While it doesn't help me to run it without a network I hope this helps you
> find the problem. Again, installation from CD works fine - first boot
> Segv's.

OK.  So, the difference in boot output on the simh v3.x version is:

        rx0 at mscpbus1 drive 3: RX50 
        qe0 at uba0 csr 174440 vec 764 ipl 17: deqna, hardware address 08:00:2b:23:52:2f

while on the failing simh v4.x version it is:

        rx0 at mscpbus1 drive 3: RX50
        qt0 at uba0 csr 174440 vec 764 ipl 17panic: Segv in kernel mode: pc 801feeb5 addr 1c
        Stopped in pid 0.1 (system) at  netbsd:upcallret:       function "upcallret()", e...

As it turns out, on both versions of simh, the XQ device defaults to emulating a DELQA-PLUS 
(aka DELQA-T).  Some changes were made in the XQ device simulation over time which now 
allows the NetBSD driver to detect the device as an DELQA-T instead of merely a DEQNA and
it now is using the qt driver instead of the qe driver.  The NetBSD qt driver seems to have 
some sort of bug and/or incompatibility with the DELQA-T device simulation which is 
demonstrated as the crash you see.

If your configuration file has "SET XQ TYPE=DELQA" the boot output will be:

        rx0 at mscpbus1 drive 3: RX50
        qt !Turbo
        qe0 at uba0 csr 174440 vec 764 ipl 17: delqa, hardware address 08:00:2b:23:52:2f

and the system will boot successfully.

It would be interesting to see what the boot output looks like on the subsequence NetBSD 6.x versions...

- Mark