Date: Thu, 3 Jun 2010 07:50:14 GMT From: Peter Cornelius <pcc@gmx.net> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/147420: [nfs] kldload nfs modules causes nfs-aware kernel panic after a while Message-ID: <201006030750.o537oEHk001553@www.freebsd.org> Resent-Message-ID: <201006030800.o53802Aw037023@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 147420 >Category: kern >Synopsis: [nfs] kldload nfs modules causes nfs-aware kernel panic after a while >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 03 08:00:02 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Peter Cornelius >Release: 8.1-PRERELEASE >Organization: pcc >Environment: FreeBSD netserv.ka.cornelius 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Wed May 26 11:23:27 UTC 2010 root@netserv.ka.cornelius:/usr/Obj-RELENG_8/usr/Src-RELENG_8/sys/NETSERV i386 >Description: I don't know whether this is a usual operational situation nor do I see any such report in gnats (at least, to my limited understanding of this all) but I managed to run into the following kernel panic some two or three hours after attempting to load the nfs modules on an 'almost-'GENERIC kernel. I copied this manually and hope that all's fine: interface nfslock.1 already present in the KLD 'kernel'! interface nfslock.1 already present in the KLD 'kernel'! panic: nfs_dirbad: /usr: bad dir ino 46895494 at offset 114368: mangled entry cpuid=0 KDB: enter: panic [thread pid 6410 tid 100340] Stopped at kdb_enter+0x3a movl $0,kdb_why If I can believe the clock, the failure occurred about 2 and a half hours after I fiddled with the modules and attempting make tinderbox nfs-mount whatever it wants to mount in a jail (that is, a real jail, not a tinderbox 'jail'). I also tried nullfs mounts in the same jail before that. The box did react on my keyboard input but oddly the clock seems to have stopped running. The KERNCONF is almost GENERIC, see differences below and foots on # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.519.2.10 2010/04/29 22:44:04 thompsa Exp $. 'Almost' GENERIC as there are some differences, most notably the VIMAGE option which I currently don't (actively) use. # ( cd /usr/src/sys/i386/conf/ && diff GENERIC NETSERV ) 21,22c21,22 < cpu I486_CPU < cpu I586_CPU --- > #cpu I486_CPU > #cpu I586_CPU 24c24,25 < ident GENERIC --- > ident VNETSERV > #ident NETSERV 38a40 > options ROUTETABLES=16 # max 16. 1 is back compatible 40a43 > # SCTP is not yet compatible with VIMAGE. 78c81,90 < options INCLUDE_CONFIG_FILE # Include this file in kernel --- > > # Debugging for use in -current > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > #options INVARIANTS # Enable calls of extra sanity checking > #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > #options INCLUDE_CONFIG_FILE # Include this file in kernel 297c309 < options USB_DEBUG # enable debug msgs --- > #options USB_DEBUG # enable debug msgs 335c347 < #device sbp # SCSI over FireWire (Requires scbus and da) --- > device sbp # SCSI over FireWire (Requires scbus and da) 339a352,360 > > options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) > options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) > options SC_KERNEL_CONS_ATTR=(FG_RED|BG_BLACK) > options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) > > # Network stack virtualisation. > options VIMAGE > options VNET_DEBUG >How-To-Repeat: I didn't try. The fsck's still running. >Fix: Not known. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201006030750.o537oEHk001553>