A few days ago, a few of you may recall, I sent a note here about
getting panics when running ps, with a call stack looking like

	_mem_access_fault+0x27c:	call	_panic
	_trapbase+0x23fc:		call	_mem_access_fault
	_trapbase+0x270c:		call	_syscall
	_swread+0x1c:			call	_physio
	_spec_read+0xd4:		jmpl	%o3, %o7
	_ufsspec_read+0x34:		jmpl	%o1, %o7
	_vn_read+0xb8:			jmpl	%o1, %o7
	_read+0xc0:			jmpl	%o3, %o7
	_syscall+0x1ec:			jmpl	%o3, %o7
	_trapbase+0x270c:		call	_syscall

A little UTSLing makes it clear what's going on here.  swread(), the
read routine for the swap-space driver (in vm/vm_swap.c), reads

int
swread(dev, uio)
	dev_t dev;
	struct uio *uio;
{

	return (physio(swstrategy, NULL, B_READ, minphys, uio));
}

But when I look at physio() (sys/kern_physio.c), it starts

int
physio(strategy, bp, dev, flags, minphys, uio)
	int (*strategy)(); 
	struct buf *bp;
	dev_t dev;
	int flags;
	u_int (*minphys)();
	struct uio *uio;
{

Can you say "argument mismatch"?  Sure you can! :-)

This probably has something to do with the recent changes to physio and
friends, but I don't feel I know enough about them to be sure of doing
the right thing.  This source is from a sup a few days old; I'm doing a
new sup now, but it's producing "SUP: Can't connect to server for
supfilesrv: Connection timed out".  If and when I manage to get a fresh
sup, I'll see if this has been fixed; if not, or if sup doesn't manage
to connect soon, I'll probably dive in, machete in hand, and see if I
can at least make it stop panicking.

In the meantime: reading from /dev/drum is liable to panic the system,
so use the c option to ps if there's any chance one of your processes
has been swapped. :-(  (Or else symlink /dev/drum to /dev/null, which I
found helped, though I'm sure I lost some functionality.)

Unless of course your kernel is old (or new, if this has been fixed)
enough that this mismatch is not present....

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu