kern/147420: [nfs] kldload nfs modules causes nfs-aware kernel panic after a while

[Peter Cornelius]

>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 at 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: