art@acc.arpa (08/04/87)
>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 ------
narten@purdue.edu (08/04/87)
Art, Thanks for the clarification. I was basing my info on the probe() message (which reports CPU level 0x17 for all devices on the Q22), and a USENET posting a while back. I installed a suggested fix and our uVAX II began working. Previously, with 2 network devices, it had crashed soon after booting. It turns out that our ProNET card was interrupting at device level 7. This is what caused the conflict with splimp(). Changing the interrupt priority, and recompiling the kernel with splimp() at level 0x16 has things working fine now. According to the DEQNA manual, it interrupts at device level 4. Thomas