Yes! I can build and run a current system only if I don't access any
other disk but the boot disk. Just "disklabel sd1" often panics
immediately, or soon thereafter. It seems to have a better chance of
succeeding, if the system's been up long enough for the kernel pools
to have already pre-allocated more memory than they have at startup,
as viewed with "vmstat -m".

With a system on sd1, "disklabel sd0" does the same thing. I actually
managed to finesse the swap partition on sd2 today, after building
against the November 6 sup. That seemed to be working fine. The two
swaps exercised successfully over a bunch of X programs; it only
paniced after I started repeatedly trying "disklabel" on all three
disks.

The symptom is fairly consistent, if "disklabel" is run immediately
after booting into single-user mode. E.g:

# disklabel sd0

	/* normal disklabel */

# disklabel sd1
panic: fstat

Stopped in disklabel at _Debugger...
db>t
_Debugger
_panic
_sys___fstat13
_syscall
_trap0

With other sequences, the exact panic message is unpredictable. Some
resemble yours. All this showed up early in September, before the
signal changes. Nothing much seems to have changed since then. I only
recently realized the system can be made stable by moving everything
to one disk.

This is on a Quadra 630/36M, three external drives.

On Sun, 8 Nov 1998, Ken Nakata wrote:

> Are you or anybody experiencing any seemingly-random kernel panics?
> I've done make build of current as of Oct. 30, and kernel dies with
> various panics.
> 
> For instance:
> 
> panic: intr_dispatch: bad vec 0x365
> Stopped in fsck_ffs at Debugger+0x6: unlk a6
> db> t
> _Debugger(...)+6
> _panic(...)+50
> _intr_dispatch(bd94)+1c
> _intrhand(?)
> _vn_lock(9387ec,20002,d0c,1,2000)+a
> _spec_open(93be14)+150
> _vn_open(93bee4,1,4e8)+31a
> _sys_open(922604,93bf88,93bf80)+7e
> _syscall(5)+146
> _trap0()+e
> db>
> 
> Or,
> 
> panic: pool_get: rusgepl: page empty
> ...
> db> t
> pool_get(...)+...
> exit1(...)+...
> sys_exit(...)+...
> syscall(...)+...
> db>