Real time control in device drivers

[Per Westerlund]

trainoff at voodoo.ucsb.edu writes:
>This lead me to something I don't understand.  I decided to raise the
>hardware interupt priority of my device above the disk and the ethernet.
>I decided on vmebus interupt level 4.  I figure that if the disk interupt
>isn't serviced on time I just lose a disk rotation.  If the ethernet isn't
>serviced, I lose a packet and need a retransmit.  If the fifo on my
>printer controller empties, I lose the page and what's worse I don't know
>that I have lost it.  I changed the interupt levels on the board and in
>the GENERIC file.  I remade the kernel and rebooted.  The system hung
>during the fsck of / and /usr.  Then just for fun I tried to reboot the
>old kernel (with the priority 2 in the GENERIC file) with the board still
>at level 4.  It came up fine and the problem was much reduced but not
>eliminated.  I am confused by this.  I thought that the hardware and the
>GENERIC file had to agree!?  What is going on here?

SPARC has 16 interrupt levels, VME 7.  The intended mapping is: SPARC =
VME*2.  The hardware mapping is done by the VME interface on the
CPU-board.

We then must compensate for this in software, which is done by the macro
pritospl().  It multiplies given values with two, by shifting left 9 bits
when all that is required is 8.

Unfortunately, this mapping is already done by config!  In your config
file you entered 'priority 4'.  When xxattach() gets called the priority
level is set to 8 (try it).  (On one of the boards I have tried, this
resulted in trying to set the board's interrupt level to 8, which became 0
when only thre bits were used -> "interrupts off"!)

It also means that the routine trying to protect a critical region with
splx(pritospl(XXX)) fails, because 8*2 = 16 -> 0 by masking!  This can
explain your problems during fsck.

			Per Westerlund