From owner-freebsd-hackers Tue May 4 19:47:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id DC38215AF1 for ; Tue, 4 May 1999 19:47:21 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.1/8.9.1) with ESMTP id WAA21537; Tue, 4 May 1999 22:47:11 -0400 (EDT) Message-Id: <199905050247.WAA21537@cs.rpi.edu> To: Matthew Dillon Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu, crossd@cs.rpi.edu Subject: Re: 'nother NFS panic on 3.1-STABLE-Sun Mar 21 In-Reply-To: Message from Matthew Dillon of "Tue, 04 May 1999 16:55:52 PDT." <199905042355.QAA20828@apollo.backplane.com> Date: Tue, 04 May 1999 22:47:09 -0400 From: "David E. Cross" 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 > I do have the complete crashdump (unfortunately the kernel was compiled sans debuging information). Would this still be of use? -- 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message