🚀 go-pugleaf

This is a followup to a previous posting, in which I requested general
help in determining the cause of a frequent "panic:mget" system crash.
Thanks to all who responded!  Your comments were most helpful.

I have now confirmed the problem is caused by trying to run SLIP on an
ALM-2 serial port.  The ALM2 interrupts the buffer allocation routine, and
ultimately an mbuf allocation panic occurs.

The problem does not occur when I run SLIP on ttyb.


(So why not just run SLIP on ttyb?)

I'd like to keep ttyb available for Sunlink/INR software, which means running
SLIP on the ALM port (ttyh0).

The recommended fix (from several helpful sources -- thanks) is to change
the interrupt priority of the ALM board...something about re-strapping the
serial board for a lower priority.  Sounds like a hardware-kind of thing
to do.  Trouble is, the SUN documentation on the ALM says nothing about
jumpers or DIP-switch settings for changing the interrupt priority level.

Could it be the interrupt priority level is set in software?  A quick peek
at the kernel config file shows:

device          zs0 at obio ? csr 0x20000 flags 3 priority 3

device          mcp0 at vme32d32 ? csr 0x01000000 flags 0x1ffff priority 4
        vector mcpintr 0x8b

"Well", thinks I, "Why not try running the ALM at the SAME priority level as
the ttya/b ports?"  I tried to compile a kernel with the "device mcp0" line
changed from "priority 4" to "priority 3".  Seemed to compile OK, but when I
tried to reboot, I got a continuous stream of

	"iobus level 3 interrupt not serviced"

messages, so with tears in my eyes, I turned around and went back to the
old kernel, which is where I remain to this day.

HAS ANYONE DONE THIS (THIS == successfully reset the interrupt priority
of the ALM-2 board so it works with SLIP)

PLEASE enlighten me as to how - if it is possible at all.  Much thanks.

Michael Maciolek                mikem@juliet.ll.mit.edu         (preferred)
G43 SysAdmin                    mikem@xn.ll.mit.edu
MIT/Lincoln Laboratory