> Ah!... ok, it is an NFS bug. I've been trying to track this down
> for a while ever since you reported the 3.4 lockup bug. This is probably
> related to a similar problem.
>
> There is a bug somewhere related to NFS locking up while doing a
> pagein from the executable image. It can occur when the binary
> is ripped out from under the client but it also can apparently occur
> if the program takes a signal during a pagein on a valid binary
> that hasn't been ripped out.
>
> If you still have this machine up, can you idle it and do a tcpdump
> looking for NFS packets for a few minutes? I'd like to know if it is
> doing an infinite retry of the page it got stuck on. Knowing what
> it is trying to do and why it isn't aborting on error with a segfault
> is the key.
>
> After that, is there any chance you can panic this machine and get
> a kernel dump?
I can come close to idle... It should be realtively easy to identify the
NFS packets in question, they will be stale FH replies from the server
(as I pulled the backing store out from under it hoping that the retry would
trigger a SEGV). Panic-ing it will be a bit trickier... the kernel is
compiled with DDB *BUT* the only console is a serial console and I forgot to
enable the ENABLE_DB_ON_SERIAL_BREAK thing-y. I am sure with gdb -k
/kernel.debug /dev/mem and your expertise we could trip a panic somehow.
For now, let me get you that NFS packetlog...
--
David Cross | email: [EMAIL PROTECTED]
Acting Lab Director | NYSLP: FREEBSD
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
