Re: Kernel Panic in latest -CURRENT

Kevin Gerry wrote:
> #0  doadump () at pcpu.h:195
> 195     pcpu.h: No such file or directory.
>        in pcpu.h
> (kgdb) bt
> #0  doadump () at pcpu.h:195
> #1  0xc060cb73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xc060cd6f in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:563
> #3  0xc086954c in trap_fatal (frame=0xe40d3b9c, eva=20) at
> /usr/src/sys/i386/i386/trap.c:870
> #4  0xc0869e8c in trap (frame=0xe40d3b9c) at
> /usr/src/sys/i386/i386/trap.c:276
> #5  0xc0853afb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #6  0xc063b008 in propagate_priority (td=0xc3ab5e00) at
> /usr/src/sys/kern/subr_turnstile.c:272
> #7  0xc063b989 in turnstile_wait (ts=0xc3a9e6e0, owner=0xc3ab5e00,
> queue=Variable "queue" is not available.
> ) at /usr/src/sys/kern/subr_turnstile.c:739
> #8  0xc060140d in _mtx_lock_sleep (m=0xc0993228, tid=3284357632, opts=0,
> file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:395
> #9  0xc04decd7 in em_handle_rxtx (context=0xc3b63000, pending=1) at
> /usr/src/sys/dev/em/if_em.c:1477
> #10 0xc0639e72 in taskqueue_run (queue=0xc3be1880) at
> /usr/src/sys/kern/subr_taskqueue.c:255
> #11 0xc063a04f in taskqueue_thread_loop (arg=0xc3b632ec) at
> /usr/src/sys/kern/subr_taskqueue.c:374
> #12 0xc05ee896 in fork_exit (callout=0xc0639fd0 <taskqueue_thread_loop>,
> arg=0xc3b632ec, frame=0xe40d3d38)
>    at /usr/src/sys/kern/kern_fork.c:797
> #13 0xc0853b70 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:205
> (kgdb) list *0xc063b008
> 0xc063b008 is in propagate_priority
> (/usr/src/sys/kern/subr_turnstile.c:273).
> 268                     ts = td->td_blocked;
> 269                     MPASS(ts != NULL);
> 270                     MPASS(td->td_lock == &ts->ts_lock);
> 271                     /* Resort td on the list if needed. */
> 272                     if (!turnstile_adjust_thread(ts, td)) {
> 273                             mtx_unlock_spin(&ts->ts_lock);
> 274                             return;
> 275                     }
> 276                     /* The thread lock is released as ts lock above. */
> 277             }

Jeff can better comment on it, but for what I can see it seems that 
ts->ts_lock is not acquired again once the new assignment from 
td->td_blocked is done and I think it should be.

Thanks a lot for your report,
Attilio