Re: Signficant bugfix to my emulator

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> And of course the official builds are here: [...]
> I'll report back once the fetch has finished and I've test-booted
> (and, prseumably, investigated a little).

My test boots (2G of disk at 0.0, DUA0, the ISO at 1.0, DUB0) hang at

[   1.0000000] uda1 at uba0 csr 160334 vec 770 ipl 17
[   1.0000000] mscpbus1 at uda1: version 0 model 0
[   1.0000000] mscpbus1: DMA burst size set to 4

I've put a full transcript on ftp.rodents-montreal.org in
/mouse/misc/vax/2024-01-01.15:26:33.nb-iso-boot, with a base64ed
version in the same thing with .base64 appended - the original is not a
normal text file; it contains ESCs, and CRs in places other than CRLF
pairs, and possibly other such.  Once I get back in touch with lili
I'll try jbglaw@'s ISO and see what happens for me with it.

So I set an output breakpoint at "mscpbus1:" and, when it tripped,
turned the clock rate down by a factor of 100 and enabled full tracing;
I then let it run until the tracing file hit about a gigabyte.
(Turning the clock rate down is to keep it from spending all its time
servicing timer interrupts, since with full tracing it runs much
slower.)

It seems to be stuck in a livelock servicing DEQNA interrupts.  After
cutting the log back by deleting memory access and machine state change
traces (egrep -v '^([iprw]|chg): '), the loop appears to be repeating
this.  (This quote includes three lines of overlap, identical between
the beginning and the end of the quote except for instruction serial
numbers.)  If anyone wants full details, I've put the full log portion
from the first line quoted here to the last line quoted here up on
ftp.rodents-montreal.org in
/mouse/misc/vax/2024-01-01.15:26:33.nb-iso-loop (no base64 this time;
this one is a normal text file).

(462435199 00000004) 800234d4: 3c 8f 10 27 7e            movzwl  $2710,-(sp)
intr vec=3f4 ipl=17 (qbus XQA0)
(462435199 04170000) 804c07c4: bb 3f                     pushr   $3f
(462435200 04170000) 804c07c6: 16 9f a8 06 00 80         jsb     *$800006a8
(462435201 04170000) 800006a8: d0 8e 50                  movl    (sp)+,r0
(462435202 04170008) 800006ab: da 17 12                  mtpr    $17,$12
(462435203 04170000) 800006ae: d0 a0 08 51               movl    08(r0),r1
(462435204 04170004) 800006b2: 13 07                     beql    800006bb
(462435205 04170004) 800006bb: db 02 52                  mfpr    $2,r2
(462435206 04170008) 800006be: d0 a2 00 52               movl    00(r2),r2
(462435207 04170008) 800006c2: d6 c2 88 01               incl    0188(r2)
(462435208 04170000) 800006c6: d8 00 c2 8c 01            adwc    $0,018c(r2)
(462435209 04170004) 800006cb: dd a0 04                  pushl   04(r0)
(462435210 04170000) 800006ce: fb 01 b0 00               calls   $1,*00(r0)
(462435211 04170000) 80016f2c: c2 04 5e                  subl2   $4,sp
(462435212 04170008) 80016f2f: d0 01 ef d2 0b 36 00      movl    $1,80377b08
(462435213 04170000) 80016f36: cb 03 ac 04 50            bicl3   $3,04(ap),r0
(462435214 04170000) 80016f3b: d0 50 ef ce 0b 36 00      movl    r0,80377b10
(462435215 04170000) 80016f42: db 12 50                  mfpr    $12,r0
(462435216 04170000) 80016f45: d0 50 ef c0 0b 36 00      movl    r0,80377b0c
(462435217 04170000) 80016f4c: d5 ef da a9 33 00         tstl    8035192c
(462435218 04170000) 80016f52: 13 38                     beql    80016f8c
(462435219 04170000) 80016f54: d0 ef d2 0b 36 00 50      movl    80377b2c,r0
(462435220 04170008) 80016f5b: cb 8f fe ff ff ff a0 30 50   bicl3   $fffffffe,30(r0),r0
(462435221 04170004) 80016f64: 13 19                     beql    80016f7f
(462435222 04170004) 80016f7f: d0 ef 87 0b 36 00 50      movl    80377b0c,r0
(462435223 04170000) 80016f86: d6 50                     incl    r0
(462435224 04170000) 80016f88: da 50 12                  mtpr    r0,$12
(462435225 04180000) 80016f8b: 04                        ret     
(462435226 04180000) 800006d2: ba 3f                     popr    $3f
(462435227 04180000) 800006d4: 02                        rei     
(462435228 00000004) 800234d4: 3c 8f 10 27 7e            movzwl  $2710,-(sp)
intr vec=3f4 ipl=17 (qbus XQA0)
(462435228 04170000) 804c07c4: bb 3f                     pushr   $3f

It appears my DEQNA emulation doesn't get along with something, almost
certainly the qe driver, in that kernel.  At the moment I don't know
which is at fault; my DEQNA emulation works fine with 1.4T's qe driver,
though that's weak evidence at best.  Booting from dua0 instead of
dub0, I see

...
uba0 at ibus0: Q22
uda0 at uba0 csr 172150 vec 774 ipl 17
mscpbus0 at uda0: version 0 model 0
mscpbus0: DMA burst size set to 4
ra0 at mscpbus0 drive 0: A 0
ra0: nspt 32 group 64 ngpc 1 rct 0 nrpt 0 nrct 1
uda1 at uba0 csr 160334 vec 770 ipl 17
mscpbus1 at uda1: version 0 model 0
mscpbus1: DMA burst size set to 4
ra1 at mscpbus1 drive 0: B 0
ra1: nspt 32 group 64 ngpc 1 rct 0 nrpt 0 nrct 1
qe0 at uba0 csr 174440 vec 764 ipl 17
qe0: deqna, hardware address 9e:ac:67:c3:0e:f0
booted from type 17 unit 0 controller 0 adapter 0
boot device: ra0
root on ra0a dumps on ra0b
...

I do, however, note that the 10.99.10 kernel doesn't touch the DEQNA
during that loop (any Qbus access would be a line beginning "Qbus:"),
so it's no surprise the interrupt reoccurs.  The last Qbus accesses
before it falls into the loop are to XQA0 (this is why I say "almost
certainly the qe driver) - perhaps the 10.99.10 DEQNA driver isn't
prepared to handle infinitely fast hardware?  I had that trouble with
1.4T's MSCP code.

It does not look like another case of "interrupt is sort-of
level-triggered and sort-of edge-triggered"; for one thing, on the Qbus
that's less possible, and for another, the code executed after the very
first interrupt of the stream is eyeball-identical (I didn't
mechanically compare) to one iteration of the loop, indicating that it
wasn't expecting even the first interrupt.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B