Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!pacbell.com!ucsd!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.admin
Subject: Re: restore crashes remote machine
Message-ID: <13091@dog.ee.lbl.gov>
Date: 11 May 91 14:07:56 GMT
References: <1991May10.141543@sweetpea.jsc.nasa.gov>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 37
X-Local-Date: Sat, 11 May 91 07:07:56 PDT

In article <1991May10.141543@sweetpea.jsc.nasa.gov>
zook@sweetpea.jsc.nasa.gov (Craig A. Zook  283-4206) writes:
>I have several Suns ... running SunOS 4.1.1 ... [and get]
>system crashes.

>May 10 13:41:21 tm vmunix: panic: psig action

This is an internally-detected error in `psig'.

Signals are sent to a process by setting a bit in the other process's
`pending signals' mask.  The process is awaked, if appropriate, and
when it eventually runs, it notices the pending signal and calls
`issig' and then `psig'.  psig() determines what to do based on the
current `signal action'.  This action is one of:

	SIG_DFL: take the default action (often, core dump/kill process).
	SIG_IGN: ignore.
	SIG_CATCH, SIG_HOLD: (internal to psignal/issig)

Now, issig() and psignal() are supposed to discard signals with no
effect, and say `no pending signal' for signals that are blocked.
Thus, psig() will panic if either:

	u.u_signal[p->p_cursig] == SIG_IGN

or

	(p->p_sigmask & (1 << p->p_cursig)) != 0

because both of these mean `the signal is not supposed to do anything'
---for SIG_IGN, `not ever' and for p_sigmask, `not yet'.

There must therefore be a bug in either psignal or issig, or both.
Presumably you are paying Sun for support.  Well, here they go....
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov