Subject: Re: Keyboard/SCSI-Interference
To: Michael L. Hitch <email@example.com>
From: Eduardo E. Horvath firstname.lastname@example.org <email@example.com>
Date: 11/20/1995 08:28:17
On Sun, 19 Nov 1995, Michael L. Hitch wrote:
> On Nov 19, 3:54am, Frank Dana wrote:
> > ...Or to the keyboard. It's the SCSI bus freezing the entire system,
> > basically, and I experience it under 1.1_ALPHA (951021 sources, soon to
> > be 951117) as well. My system is an A2000 4/2 with GVP 4008 controlling
> > a Quantum Lightning 730.
> I would guess that are sections of the 33C93 SCSI driver (A3000/A2091,
> and GVP) that polls the SCSI chip when initiating a SCSI operation.
> Since the driver is going to run at splbio() (which is IPL 3) or at the
> adapter interrupt level (IPL 2) , that's going to block the keyboard
> interrupt and the software interrupt used for keyboard repeats. I
> haven't looked at that driver for a while, and I don't remember exactly
> how the driver currently works.
Yes, the driver runs at splbio until it has successully selected the bus
and initiated the command. However, unlike the old driver, it does not
wait until DMA begins to re-enable the interrupts.
> The serial receive interrupt is at IPL 5, which shouldn't have any
> trouble with the SCSI driver normally - but there may be parts of the
> kernel or I/O system that may run at splhigh() [IPL 7] which would
> severely impact the processing of serial receive interrupts. The
> LEV6_DEFER option forces the highest spl level used by the kernel to be
> 4, which should allow the serial receive processing to never be blocked.
> It also defers any level 6 interrupt processing to level 4 (the clock on
> NetBSD uses a level 6 interrupt, and several boards use level 6
> interrupt), which minimizes the amount of time running at IPL6.
What boards are at IPL6? I thought the A3000 and A2091 controllers were