Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!labrea!aurora!ames!hc!beta!cmcl2!brl-adm!adm!art@acc.arpa
From: art@acc.arpa
Newsgroups: comp.unix.wizards
Subject: uVAX interrupts
Message-ID: <8636@brl-adm.ARPA>
Date: Tue, 4-Aug-87 00:37:46 EDT
Article-I.D.: brl-adm.8636
Posted: Tue Aug  4 00:37:46 1987
Date-Received: Wed, 5-Aug-87 04:24:08 EDT
Sender: news@brl-adm.ARPA
Lines: 21

>For instance, the
>processor priority levels in some of macros are wrong. E.g., splimp()
>needs to be changed from 0x16 to 0x17. The DEQNA interrupts at level
>0x17, which causes obvious problems for the networking code that
>thinks it is running uninterruptable. This is bound to reek havoc on
>machines with two DEQNAs.

This may not really be true.  Are you saying that the DEQNA is actually
REQUESTING an interrupt at level 7 (CPU lvl 0x17)?  The uVAX CPU will
ALWAYS raise the processor priority to level 0x17 regardless of what
level of request was being granted.  This is because the Q22 bus allows
higher priority devices to intercept grants issued for lower priority
requests.  Since the CPU has no way of knowing what level device actually
takes the grant, it must raise priority to the highest possible (0x17).
If the DEQNA is really requesting on level 6 (CPU lvl 0x16) it WILL NOT
receive an interrupt grant if that level is blocked (if the hardware
follows Q22 Bus rules).
						Art Berggreen
						art@acc.arpa

------