richa@ios.UUCP (Rich Altmaier) (09/27/83)
Regarding panics followed by a stream of 'trap type 2'; the half page of
trap type 2s can happen due to the panic routine doing an spl0(), in
Berkeley 4.1. When this happens there is no core dump.
This spl0() can cause recursive panics if panic is called from the
interrupt stack. The occurance of an interrupt (such as a clock tick)
implies the interrupt routine will eventually execute an rei. Nested
interrupts on the interrupt stack are normally fine. If, for example, a
clock tick interrupt is blocked during execution of
a higher priority interrupt, and the higher priority interrupt code has
trouble and calls panic, the clock tick is unblocked when the spl0()
occurs.
Then the clock tick's rei gets a Vax hardware detected reserved operand
fault due to returning to the interrupt stack with an ipl of 0 (running on
the interrupt stack normally implies some non-0 ipl was in effect to get
there, i.e. interrupts were not masked). The reserved operand fault calls
trap ('type 2'), which calls panic, (where the console message takes a long
time to print, such that another clock tick happens), then spl0() and
everything repeats, until stack overflow.
Unfortunately I'm uncertain why panic() does an spl0(). Presumably so
the disk sync option in boot() (called by panic to do re-boot) will work?
If panic is called from interrupt level, this seems questionable in any case.
In tracing down some kernel bugs, I have removed the spl0 in order to get
core dumps, but cannot advise anyone else to do so.
Rich Altmaier
Integrated Office Systems, 408 257-0171
...!ucbvax!decwrl!ios!richa