On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote:
> 
> Can you do 'show locks' at the ddb prompt to get a list of what locks are held?

db> show locks
exclusive (sleep mutex) Giant (0xc0343ae0) locked @ 
/nfs/5.x/src/sys/kern/kern_timeout.c:186
exclusive (spin mutex) sched lock (0xc0343940) locked @ 
/nfs/5.x/src/sys/kern/kern_mutex.c:340

> probably a NULL pointer dereference of some sort in _mtx_lock_sleep(). 

>From trace:
        :
--- trap 0xc, eip = 0xc01b67c6, esp = 0xcbf9ec74, ebp = 0xcbf9ec80 ---
_mtx_lock_sleep(cc4c310c,0,c029b360,27b) at _mtx_lock_sleep+0x14e
        :

In gdb (now with debug information):
(kgdb) bt
        :
#21 0xc01cf514 in printf (
    fmt=0xc02b3480 "kernel trap %d with interrupts disabled\n")
    at /nfs/5.x/src/sys/kern/subr_prf.c:262
#22 0xc026bca9 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, 
      tf_edi = -877096400, tf_esi = -867421940, tf_ebp = -872813440, 
      tf_isp = -872813472, tf_ebx = -877096188, tf_edx = -1049155008, 
      tf_ecx = 2, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
      tf_eip = -1071945786, tf_cs = 8, tf_eflags = 65666, tf_esp = 635, 
      tf_ss = 0}) at /nfs/5.x/src/sys/i386/i386/trap.c:206
#23 0xc01b67c6 in _mtx_lock_sleep (m=0xcc4c310c, opts=0, 
    file=0xc029b360 "/nfs/5.x/src/sys/kern/kern_time.c", line=635)
    at /nfs/5.x/src/sys/kern/kern_mutex.c:409
#24 0xc01b6421 in _mtx_lock_flags (m=0xcc4c310c, opts=0, 
    file=0xc029b360 "/nfs/5.x/src/sys/kern/kern_time.c", line=635)
    at /nfs/5.x/src/sys/kern/kern_mutex.c:235
#25 0xc01c4b60 in realitexpire (arg=0xcc4c2f04)
    at /nfs/5.x/src/sys/kern/kern_time.c:635
#26 0xc01c4fc6 in softclock (dummy=0x0)
    at /nfs/5.x/src/sys/kern/kern_timeout.c:187
#27 0xc01b03ce in ithread_loop (arg=0xc0e45c80)
    at /nfs/5.x/src/sys/kern/kern_intr.c:532
#28 0xc01af8ac in fork_exit (callout=0xc01b02a4 <ithread_loop>, 
    arg=0xc0e45c80, frame=0xcbf9ed48) at /nfs/5.x/src/sys/kern/kern_fork.c:

(kgdb) up
        :
#22 0xc026bca9 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, 
      tf_edi = -877096400, tf_esi = -867421940, tf_ebp = -872813440, 
      tf_isp = -872813472, tf_ebx = -877096188, tf_edx = -1049155008, 
      tf_ecx = 2, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
      tf_eip = -1071945786, tf_cs = 8, tf_eflags = 65666, tf_esp = 635, 
      tf_ss = 0}) at /nfs/5.x/src/sys/i386/i386/trap.c:206
206                             printf("kernel trap %d with interrupts disabled\n",
(kgdb) 
#23 0xc01b67c6 in _mtx_lock_sleep (m=0xcc4c310c, opts=0, 
    file=0xc029b360 "/nfs/5.x/src/sys/kern/kern_time.c", line=635)
    at /nfs/5.x/src/sys/kern/kern_mutex.c:409
409                                     if (td1->td_ksegrp->kg_pri.pri_level > 
kg->kg_pri.pri_level)

(kgdb) p td1
$1 = (struct thread *) 0x0

The strange part is that line 409 is the body of a for-loop (TAILQ_FOREACH)
that breaks whrn td1 is NULL.

(kgdb) p m->mtx_blocked
$3 = {tqh_first = 0xc1772a40, tqh_last = 0xcc4c3100}

(kgdb) p $3.tqh_first
$6 = (struct thread *) 0xc1772a40

(kgdb) p $6->td_blkq
$7 = {tqe_next = 0x1, tqe_prev = 0xdeadc0de}

(kgdb) p *$6
$8 = {td_proc = 0x18729006, td_ksegrp = 0x0, td_last_kse = 0x0, td_kse = 0x0, 
  td_plist = {tqe_next = 0x86001, tqe_prev = 0x0}, td_kglist = {
    tqe_next = 0x0, tqe_prev = 0x0}, td_slpq = {tqe_next = 0x0, 
    tqe_prev = 0xcd20e000}, td_blkq = {tqe_next = 0x1, tqe_prev = 0xdeadc0de}, 
  td_runq = {tqe_next = 0xdeadc0de, tqe_prev = 0xdeadc0de}, 
  td_flags = -559038242, td_dupfd = -559038242, td_wchan = 0x0, 
  td_wmesg = 0xc16a0cac "\200*w", td_lastcpu = 0 '\000', td_locks = 0, 
  td_blocked = 0xcd207b48, td_ithd = 0x0, 
  td_mtxname = 0xcd207a0c "\200*w\220*w\200z W", td_contested = {
    lh_first = 0xcd207a80}, td_sleeplocks = 0xcd207940, 
  td_intr_nesting_level = 1869349888, td_md = {<No data fields>}, td_retval = {
    -559060125, -559038242}, td_pcb = 0xdeadc0de, td_slpcallout = {c_links = {
      sle = {sle_next = 0xdeadc0de}, tqe = {tqe_next = 0xdeadc0de, 
        tqe_prev = 0xdeadc0de}}, c_time = -559038242, c_arg = 0xdeadc0de, 
    c_func = 0, c_flags = -1049941016}, td_frame = 0xc1772b40, 
  td_kstack_obj = 0xc1772248, td_kstack = 0}

I don't know to what extend the structures have ben globbered by the
double panic, but this is what I see post mortem.

BTW: It seems easily reproducable so if you want some additional
info, let me know. The kernel is bleeding edge with a local fix for
the linprocfs breakage.

FYI,

-- 
 Marcel Moolenaar         USPA: A-39004          [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to