From owner-freebsd-hackers Mon Jun 14 9:47:27 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 B3C6D14DFE for ; Mon, 14 Jun 1999 09:47:25 -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.3/8.9.3) with ESMTP id MAA13655 for ; Mon, 14 Jun 1999 12:47:24 -0400 (EDT) Message-Id: <199906141647.MAA13655@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: 3.2-STABLE panic #17 (NFS -- additional informatio) Date: Mon, 14 Jun 1999 12:47:24 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, now that I have hopefully gotten the criticial people's attention, I will proceed with the details: 1: My test program can only reproduce this with NFSv3/UDP from a recently patched Solaris system to a FreeBSD server. I have not tested older Solaris patches, I suspect that they will not cause the panic. 2: Recent packet traces of the NFS traffic reveals that it is likely *NOT* unlink that is causing the problem. I now have 6 packet traces and all fail within a couple of packets of the NFS server responding to a create request with "ERROR: File exists" (that is TCPDUMP terminoligy). Looking through the create call, I think I can see it, but it is tough. 2a: only ever *one* "ERROR: File exists" has ever been seen per a single crash. 3: Based on #1 and #2 I can surmise that other OSs will eventually trip this, but the access pattern is sufficiently different that my test program will not do it. 4: It is not a concurancy issue as far as I can tell. I wrapped all of nfssrv_create() (or whatever it is called) in a spl_softclock(), splx() pairing and I could still cause the panic. 5: I tried compiling with "MAX_PERF" which in effect comments out the panic, this caused all access to the directory to result in (D)iskwait, with WCHAN of "inode". Effectively bringing the NFS server down, but without the advantage of having the machine come back by itself. I am still digging arround, but this is significantly above my head. It is great fun, and I wouldn't mind continuing except this is becoming a difficult issue. We have backed everything down to NFSv2, but existing mounts are difficult to get rid of. -- 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