Date: Thu, 27 May 1999 22:12:41 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: hackers@FreeBSD.ORG Subject: Re: kernel debugging assistance Message-ID: <199905271812.WAA69952@arc.hq.cti.ru> In-Reply-To: Your message of "Thu, 27 May 1999 10:32:00 EDT." <199905271432.KAA21944@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I don't think that this dump is useful for debugging this problem. Perhaps, if > > you compile the kernel with DEBUG_LOCKS, you will get more useful info. > > I checked through the source for DEBUG_LOCKS, it doesn't appear to do anything > other than to printout information.... information that I already have access > to by way of this dump file. I will turn it on regardless swo it makes my > life a bit more simple. Hmm. As I see, DEBUG_LOCKS don't print out anything. The kernel with DEBUG_LOCKS will store the file and line number of every locker in the vnode. > > In looking through this, and at the program that used to cause this problem > reliably (it no longer does, even though nothing changed on the client or > workstation; I am guessing that it is a race condition that happens 5% of > the time and I filled my quota for the next 20 years ;) I have a theory > what is going on... NFS service is entirely in the kernel for FreeBSD, > excepting the NFSDs which mostly sit arround to give the kernel contexts to > pass requests into. NFS uses its own namei mechanism which requests a lock > on what it is looking up. The standard namei mechanism request locks on what it is looking up too. > What if it gets 2 requests at about the same > time for the same file. One nfsd service only one request once. When it try to lock something locked by another nfsd (or, in general, another program), it will wait until the lock is released. After nfsd served a request, it has to release all the locks it got. I think, your panic is caused by nfsd forgot to release a lock. If so, the bug is not where it paniced, but some time before. This is why I suggested DEBUG_LOCKS. Unfortunately, as Don Lewis pointed out, it will not very useful too :-(. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905271812.WAA69952>