From owner-freebsd-hackers Tue May 4 16:56:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 6CCE515268 for ; Tue, 4 May 1999 16:55:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA20828; Tue, 4 May 1999 16:55:52 -0700 (PDT) (envelope-from dillon) Date: Tue, 4 May 1999 16:55:52 -0700 (PDT) From: Matthew Dillon Message-Id: <199905042355.QAA20828@apollo.backplane.com> To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu, crossd@cs.rpi.edu Subject: Re: 'nother NFS panic on 3.1-STABLE-Sun Mar 21 References: <199905030253.WAA27609@cs.rpi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :crash, this time I have the crashdump. (BTW: I issued 'savecore' on the machine :and it said "no coredump", yet I issued a dd bs=512 if=/dev/wd0s1b skip= :OFFSET of=crashfile, and I have a valid core.) Below is what I find to be :interesting in the PS output: : :USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND :root 34338 39.2 0.0 296 0 ?? R - 0:00.00 (nfsd) 0 34338 34337 276 -6 0 296 0 - R ?? 0:00.00 (nfsd) :root 167 0.0 0.0 262984 0 ?? Ss - 0:00.00 (rpc.statd) 0 167 1 0 2 0 262984 0 select Ss ?? 0:00.00 (rpc.statd) : :Does this sugggest anything to anyone? (We will be upgrading this machine :shortly, I just hope to gather some insight as to what tripped this. Our :new kernels will be config -g; strip --no-debug kernels :) : :-- :David Cross | email: crossd@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd :Rensselaer Polytechnic Institute, | Ph: 518.276.2860 :Department of Computer Science | Fax: 518.276.4033 :I speak only for myself. | WinNT:Linux::Linux:FreeBSD I looked at the code and your original bug report but could not find anything obvious. A stack backtrace will probably not yield enough information, but a crash dump would be primo if you can manage to get one. In order for a crash dump to work, total swap space must be at least as large as main memory, /var/crash must have sufficient space (i.e. be a tad larger then main memory), and crash dumps must be enabled via the 'dumpdev' /etc/rc.conf variable. For example, if your swap partition is /dev/sd0b, you would put 'dumpdev="/dev/sd0b"' in your rc.conf. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message