>> Well, for now I'm just going to shut them all off and see if that solves some
>> of my problems.
>
>That's probably good for testing, but it would be nice to see if just
>screening out level-2 interrupts would be sufficient.  That leaves only
>serial and NMI (debugger switch) interrupts.  Leaving serial interrupts
>active would be nice since most machines seem to already be having
>problems keeping up with the serial...

I fully agree. Right now, I believe the only conflict seems to be between
intvid and SCSI so the serial interrupts should be clear to run while I'm
messing with the video registers. 

>> What interrupts, if any, does the kernel shut off when you go into a system
>> call?
>
>Nothing, basically.  Assuming that you mean a system call like "fork()"
>from a user program.  In general, when an interrupt service routine is
>running, all interrupts at that level or lower are blocked.  So in the
>middle of a scsi interrupt handler, scsi, nubus, clock, adb interrupts,
>etc. are all blocked.

I think what's happening is that I'm doing a screen change system call and
just at that moment a SCSI interrupt occurs and WHAMO - the hardware chokes
and dies.

I think that the video and SCSI might be sharing certain circuitry in the
RBV/V8/VASP chips that requires one blocking out the other during activity.
In fact, if I don't clear a particluar bit when I start video operations I
get SCSI phase problems getting thrown out on every disk access thereafter.

I'm going to compile in some changes over the next couple of hours.

Cross your fingers folks :)

_______________________________________________________________________
 Michael Zucca - mrz5149@rit.cs.rit.edu - http://www.rit.edu/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________