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.

> ...And if you think the keyboard problems are bad, you should try using a
> modem. I basically get a comm error every time the disk is hit--which
> makes FTP transfers a lot of fun--not to mention SUP. 8)  I'm hoping that
> M. Illenser's (sp?) suggestions for SERIBUF and LEV_6 will alleviate some
> of the problem--but I don't completely understand why it's happening at all.

  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.
Increasing SERIBUF allows more buffering of received characters at the
serial receive interrupt level, but if the kernel gets too busy to keep
up with the received data, it will eventually overflow.  I think the
idea is that received data normally would be received in blocks (SLIP or
PPP packets) and if the buffer is larger than the amount of
"unacknowledged" data, you shouldn't loose any input.  A transfer like
ZModem could fail if the sending system tries to send the entire
transfer without any handshaking, although I would expect the local
program would request a retransmission when it receives bad data.

  The receive interrupt handler should be forcing RTS off if the buffer
is close to filling up.  If the response time of the remote system is
slow enough though, it could send enough characters to overflow the
receive interrupt buffer.

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA