Date: Sat, 2 Oct 2004 03:05:50 -0400 (EDT) From: "David E. Cross" <crossd@cs.rpi.edu> To: "Jason C. Wells" <jcw@highperformance.net> Cc: port-freebsd@openafs.org Subject: Re: FreeBSD 5.2.1 Client Success! Message-ID: <20041002030159.A84436@monica.cs.rpi.edu> In-Reply-To: <F99BE7989AEABA2B6ABCEF48@[192.168.1.16]> References: <66F8A41B3F4164470D9446F2@[192.168.1.16]> <F99BE7989AEABA2B6ABCEF48@[192.168.1.16]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Oct 2004, Jason C. Wells wrote: > --On Friday, October 01, 2004 8:21 PM -0700 "Jason C. Wells" > <jcw@highperformance.net> wrote: > > > I have been bugging folks for FreeBSD status reports for a while now. It > > is my turn to make one. I have a working FreeBSD OpenAFS 1.3.71 client. > > I plan to do some stress testing to see if it pukes. > > Yeah, it puked. :| > > Writing from and to AFS even simultaneously worked fine. Deleting was > problematic. When running OpenAFS 1.3.71 on FreeBSD 5.2.1 an attempt to > delete an AFS file results in: > > panic: lockmgr: locking against myself > > If anyone is working on the port anymore, I will be glad to work this issue > in greater detail. I don't have the skill to hack a fix. Ugh, its been awhile since I've played with this, or the sections of the VFS that AFS likes to (ab)use. As I recall many of the lockmgr errors are the fallout of AFS having its own vnodes. If you can get a stack trace from that, or a debugging output of what it was trying to lock, it could be helpful. It _used_ to be that AFS kept an artificially incremente VNODE count to prevent "its" vnodes from re-entering the system pool, there were more than a couple of places that this cause various OS assumptions to be false. Though I believe this was replaced with a VNODE flag that basically indicated that the VNODE in question was "foreign" and told the kernel to keep its hands off; its possible this abstraction broke down at some point either in the FreeBSD or OpenAFS side of the equation... aforementioned stack trace/dump would be instrumental in pinning that down. -- David E. Cross
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041002030159.A84436>