Subject: Changes to interrupt code
To: None <port-hp300@NetBSD.ORG>
From: Jason Thorpe <thorpej@OG.ORG>
List: port-hp300
Date: 12/08/1996 19:49:22
Hi folks...

So, I was running backups the other day, and got really fed up with
the "dcm0: uart overflow" messages spewing while my tape and disks
were busy.  (My PPP link is on dcm0.)

The reason it was losing so badly is because going to splbio() was blocking
tty interrupts.  The reason for this was that most devices on the hp300
can be configured (via DIP switches or the Configuration EEPROM) to
interrupt at ipl 3, 4, or, 5.

Even with the old code, if your serial port was the highest ipl, splbio()
would still block it's interrupt.  This was a serious bug, IMO.

So, what I did was add code to dynamically compute the ipls of devices
fitting the classes "bio", "net", and "tty".  These dynamically computed
values are now used for the calls to splbio(), splnet(), and spltty().
splimp() is also computed; it must block any interrupt that may call
malloc() or free().  The following heirachy is enforced by the new code:

	bio <= net <= tty <= imp

The rationale for the heirarchy is:

	- Disks will never drop data if their interrupts aren't
	  handled promptly.

	- Network interfaces are less likely to drop data than
	  serial interfaces.

	- Some models of hp300s have really crappy serial ports.

In order to fully take advantage of the new code, you'll probably
have to reconfigure your hardware a bit.  On my hp380, I used
the Configuration EEPROM to set the ipls for the built-in
devices, and deciphered the DIP switches on my DCM card to change
its ipl.  My new hardware interrupt configuration is:

	hpib	3
	scsi	3
	le	4
	dca	5
	dcm	5

This is an ideal configuration.  It's worth noting, however, that
even if you don't reconfigure your hardware, you'll be no worse off
than you were before.  At the end of autoconfiguration, the kernel
will print out the values its using for the spl calls:

interrupt levels: bio = 3, net = 4, tty = 5

As a side-effect of these changes, Rev A DMA controllers may actually
work now; they didn't previously, since the Rev A can only interrupt
at ipl 3.  Previously, the code forced the DMA controller to interrupt
at ipl 5.  Now, the DMA controller will automatically use the ipl of
the highest DMA-using controller.  Thus, if you configure your hpib
controllers to ipl 3, you win, if you have a Rev A DMA controller.
(Don't worry; I don't anticipate that very many people have Rev A
DMA boards :-)

These changes have made my serial ports much more useable during
disk/tape activity.  If you encounter problems, please let me know.

(Oh yah, they'll show up in tomorrow's SUP.)

        -- Jason R. Thorpe <thorpej@og.org>