mikem@juliet.ll.mit.edu (Mike Maciolek) (05/06/89)
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