Re: panic: Bad link elm, nfsd related?

On Wed, 29 Apr 2009, Matthew West wrote:

>
> Unread portion of the kernel message buffer:
> panic: Bad link elm 0xffffff00074ef400 next->prev != elm
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> panic() at panic+0x182
> xprt_inactive_locked() at xprt_inactive_locked+0x78
> svc_vc_rendezvous_recv() at svc_vc_rendezvous_recv+0x335
> svc_run_internal() at svc_run_internal+0x347
> svc_run() at svc_run+0x94
> nlm_syscall() at nlm_syscall+0x826
> syscall() at syscall+0x1e7
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x8008b7c6c, rsp = 0x7fffffffecf8, rbp = 0x7fffffffee20 ---
>
> Any suggestions?  Should I go back to the newer RPC implementation?
>
The crash was in the new rpc, which is always used by the nlm. You could
try the following patch to sys/rpc/svc.c, if you wanted to live on the
"bleeding edge".

Good luck with it, if you try it, rick
--- untested patch for sys/rpc/svc.c ---
*** svc.c.sav	Wed Apr 29 17:04:38 2009
--- svc.c	Wed Apr 29 17:13:36 2009
***************
*** 362,367 ****
--- 362,375 ----

   	mtx_lock(&pool->sp_lock);

+ 	if (!xprt->xp_registered) {
+ 		/*
+ 		 * Race with xprt_unregister - we lose.
+ 		 */
+ 		mtx_unlock(&pool->sp_lock);
+ 		return;
+ 	}
+
   	if (!xprt->xp_active) {
   		TAILQ_INSERT_TAIL(&pool->sp_active, xprt, xp_alink);
   		xprt->xp_active = TRUE;