Bug 36108
| Summary: | Diskless NFS Client panic with 4.5-STABLE | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Steve Shorter <steve> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.5-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->closed I just committed what we believe to be the solution to -current and -stable (rev 1.242.2.16 of kern/vfs_bio.c for -stable). It should show up on the mirrors soon. |
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.