Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA27344; Sun, 3 Dec 95 01:37:01 EST
Received: from BILL-THE-CAT.MIT.EDU by MIT.EDU with SMTP
	id AA28742; Sun, 3 Dec 95 01:35:50 EST
From: ghudson@MIT.EDU
Received: by bill-the-cat.MIT.EDU (5.0/4.7) id AA08063; Sun, 3 Dec 1995 01:36:57 -0500
Date: Sun, 3 Dec 1995 01:36:57 -0500
Message-Id: <9512030636.AA08063@bill-the-cat.MIT.EDU>
To: ghudson@MIT.EDU
Cc: pc-dialup@MIT.EDU
In-Reply-To: "[245] in pc-dialup"
Subject: Re: Crash report
Content-Length: 1822


I wrote:
> inode 13 is /etc/mtree, a directory.  Process 15788 is apparently
> "mesg".

This was an error; see below.

>	free vnode: type VDIR, usecount 1, writecount 0, refcount 0,
>	        tag 13, fid: 1.20014dea.1.1, locked 0 times by 15788
>	panic: free vnode isn't
>	syncing disks... 23 23 20 12 6 done

Okay, that was a message from afs_nbsd_print(), indicating cell 1,
volume 20014dea (a hex number), vnode 1, unique ID 1.  Tag 13 is
VT_AFS.

We got another panic message today:

	free vnode: type VDIR, usecount 1, writecount 0, refcount 1,
	        tag VT_UFS, ino 15360, on dev 4, 10 (LOCKED)
	        owner pid 12727
	panic: free vnode isn't
	syncing disks... le0: framing error
	le0: crc mismatch

(This time, the machine never seemed to reboot, but just hung; the
panic message was transcribed by Karl.)  At least we're back to the
inode of /etc.

Our process accounting lists 12727 as being the pid of "zwgc",
"attach", and "cmp" (in that order).  The process accounting goes from
process 15476 (cmp) to process 103 (accton); it's interesting to note
that there's a whole bunch of "w" and "cmp" processes from uid 12188
(simonlee) before the crash, including the most recent pid 12727.
simonlee's activity extends back at least several thousand pids, and
is dominated by "w" and "cmp" processes, with some "mv", "test", and
"zwrite" processes in there as well.

pid 15788 preceding the November 26 11:47pm crash (with the AFS vnode)
was also a "cmp", and there is also a lot of activity of the same
nature from user simonlee around that process; however, that time the
crash didn't occur until the pids wrapped around and came up to the
12700s, and simonlee's activity stopped in the 7800s.

I'm going to send him mail asking him what he's up to, since he may
have a way of reproducing the kernel problem.