[Simh] Fwd: 4.3BSD Quasijarus0c on the VAX-11/730

[Mark Pizzolato - Info Comm]

On Jul 7, 2014 10:44 AM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
>
> On Wed, Jul 2, 2014 at 8:38 AM, Christian Gauger-Cosgrove
> <captainkirk359 at gmail.com> wrote:
> > In other news, I have had some assistance getting Quasijarus up and
> > running on the 11/730...
> > root device? rb0*         <--- Enter "rb0*" here.
> > idc0: lost interrupt       <--- This error repeats infinitely.
>
> So I was able to completely reproduce these results and I've done some
> digging into 4.3BSD's idc.c as well as simh's vax730_rb.c... by
> disassembling idc.o from the distro files and comparing it to the live
> in-memory contents of the running simulation, I've run across
> something interesting...
>
> First of all, I was able to confirm the in-memory location of the
> variable 'idcdebug' at 0x80063a5c, which lets me turn idc.c's
> debugging on and off.  When I did this, I got a surprise - mixed in
> with a lot of debugging output was the rest of the startup and a "#"
> prompt.  I am able to run commands, look around the disk, etc., only
> as long as idcdebug is non-zero.  As soon as I turn it back to 0, the
> "lost interrupt" loop returns (but then turning debugging back on does
> not seem to unstick it - once stuck, it stays stuck).
>
> Specifically what I did was follow the recipe right up to the "root
> device?" prompt, then ^E to gain access to the "sim>" prompt, then
> "deposit 80063a5c 1" and "go".  There follows a flurry of debugging
> statements ending in "#".
>
> Curiously, "idcdebug" only appears in the printd macro (as
> "if(idcdebug)printf"), so there must be some side-effect since the
> only direct linkage would be additional reads of the rb730 registers
> for some of the printf statements, and the indirect effects are to add
> additional cycles between operations (defeating a race condition?)
>
> I can capture the driver debugging output, but most of the output from
> a working machine is not useful for debugging - we already have a good
> idea of what should be happening when things are going well.
>
> That's all I've got for now, if someone wants to take it and run with it.

A useful debugging technique/tool is to turn on simh instruction history and to use simh breakpoints.  The great thing about this is that without regard to the amount of simh debugging output that is produced or the contemplation time spent while stepping through the driver code the apparent timing the driver is counting on should not change and thus the problem should still appear.

Give this a shot and see what you learn.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140707/81271ecd/attachment-0002.html>