Date: Tue, 19 Mar 2002 11:54:19 -0800 (PST) From: Steve Shorter <steve@nomad.tor.lets.net> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/36108: Diskless NFS Client panic with 4.5-STABLE Message-ID: <200203191954.g2JJsJH94344@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 36108
>Category: kern
>Synopsis: Diskless NFS Client panic with 4.5-STABLE
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 19 12:00:11 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Steve Shorter
>Release: FreeBSD 4.5-STABLE i386
>Organization:
>Environment:
FreeBSD cgi0 4.5-STABLE FreeBSD 4.5-STABLE #0: Sat
Mar 16 07:54:07 EST 2002 root@jak:/usr/src/sys-stable.2002_02_21/compile/JAK i386
>Description:
I have a pool of diskless NFS clients running cgi programs for
a similar pool of NFS clients serving http to the internet.
The hardware and general setup of all client NFS hardware/software
is identical the only difference being that cgi machines run a lot
of perl/php/.... etc .... cgi stuff, probably doing a lot
more file writing.
After upgrading to 4.5, the servers serving http are very
stable, as it was with 4.4
However, the servers running cgi programs are unstable, all
of them will panic after uptimes from 30 mins. to several hours.
However, these same servers are stable running kernel 4.4-RELEASE-p9
in a 4.5-RELEASE userland.
I have verified that the panic occurs with the latest 4.5-STABLE and 4.5-RELEASE.
The NFS servers are 4.5-STABLE from about
Feb 21.
I built a kernel with DDB, and the panics are always the
same. I am inexperienced in debugging FreeBSD kernels but am willing
to help in any way I can and have dedicated use of a machine for
debugging/testing.
Here is a console output and db trace at panic for your enjoyment.
nfs_fsync: not dirty
Debugger("panic")
Stopped at Debugger+0x34: movb $0,in_Debugger.426
db> trace
Debugger(c01fabdb) at Debugger+0x34
panic(c0203894,e258f9a0,e2872e58,e014d520,e2872dac) at panic+0x70
nfs_flush(e25c9480,c38ce300,1,e014d520,0) at nfs_flush+0x5f8
nfs_close(e2872e58,c3b25980,c3b25980,c02188e0,e25c9480) at nfs_close+0x52
vn_close(e25c9480,3,c38ce300,e014d520,e2872ecc) at vn_close+0x40
vn_closefile(c3b25980,e014d520,e014d520,c3b25980,e25c9480) at vn_closefile+0x1f
fdrop(c3b25980,e014d520,4,c385f600,0) at fdrop+0xaf
closef(c3b25980,e014d520,e014d520,1,c021c1f0) at closef+0x9b
close(e014d520,e2872f80,281aa664,1,843f138) at close+0x89
syscall2(834002f,281b002f,bfbf002f,843f138,1) at syscall2+0x16a
Xint0x80_syscall() at Xint0x80_syscall+0x25
db> panic
panic: from debugger
Uptime: 2h43m42s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
If you need more info just ask.
thanx - steve
>How-To-Repeat:
I suspect that high levels of file activity, particularly
writing, over NFS will trigger this panic. But it may be unique
to this particular network use/application.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203191954.g2JJsJH94344>