Hey there.  So I found someone who's trying to help me find tech docs at Mips.
I haven't heard back from them yet, but if I don't soon, I'll ring them again
next week.  Fingers crossed.

Also, I made an interesting observation...  We seem to be making a large 
assumption with the Magnum that it considers on-board peripherals handled
by the I/O ASIC to be VLB devices, as they are on the Acer Pica.  ASIC
interrupts are presumably signaled in the "PVIS" register (Pica VLB Interrupt
Source) at 0xe0040000.  Linux's jazz.h uses 0xe0010000 for the same purpose.
I tried changing PVIS to this address, to no avail.  I even did a comparison
reading of 0xe0010000 vs. 0xe0040000.  At 0xe0010000, I read all ones.  So
that seemed out.  At 0xe0040000, I read 0xfc00, which seemed correct.  Bits
0 thru 9 indicating no internal ASIC interrupts are currently raised.  I'm
curious under what conditions this register would be found at 0xe0010000 as
linux assumes?  I haven't tried booting a linux kernel, so I don't know if
it works or not.

Then, I did another test.  In pica_clkintr(), I inserted a for-loop to do an
"inw" on every address from 0xe0000000 to 0xe0000300, stepping by eights.
I also did an inw on the four registers 0xe0010000/2, and 0xe0040000/2 right
after.  This did not fix the problem!  This test disproves the theory that
IT_STAT is at a different location.  That seemed doubtful anyhow from my
disassembling of the ARC firmware.  It also disproved that an internal ASIC
interrupt was still pending.  None were, as the reading of 0xfc00 from
0xe0040000 showed.  Internal ASIC interrupts shouldn't really be coming into
play anyway, since they should be raising INT0.  We care about INT4.  Or at
least we *think* we do.  We're making a large assumption that a Rev 2 ASIC
(as we know the Magnum 4000SC uses) signals the interval timer interrupt on
INT4.  We're also assuming ARC is setting things up beforehand in a particular
way.  Which makes me curious about the CONFIG (0xe0000000) register.  And
what it can control.  Which basically leads us to the fact that documentation
would definitely seem needed.  I'm hoping Mips comes through, as it would
be infinitely helpful against this problem.  Does anyone on the list have the
specs for the R4030 or R4230?  If so, could you photocopy the register mappings
and be willing to mail them to me?  This may help in the interim.

Cheers,
-Mark