blockable sleep lock panic (with gdb backtrace)

From: Andre Guibert de Bruet (andy_at_siliconlandmark.com)
Date: 02/13/04

  • Next message: Andre Guibert de Bruet: "Re: /usr/src/sys/dev/aic7xxx errors when compiling"
    Date: Fri, 13 Feb 2004 04:34:07 -0500 (EST)
    To: current@freebsd.org
    
    

    Hi,

    I encountered this while fiddling with my USB CF reader and camcontrol
    rescan.

    (kgdb) where
    #0 doadump () at ../../../kern/kern_shutdown.c:240
    #1 0x604504e5 in db_fncall (dummy1=1016, dummy2=0, dummy3=1016,
    dummy4=0xb086881c "") at ../../../ddb/db_command.c:548
    #2 0x6045026a in db_command (last_cmdp=0x6078fcc0, cmd_table=0x0,
    aux_cmd_tablep=0x6073f3cc, aux_cmd_tablep_end=0x6073f3d0)
        at ../../../ddb/db_command.c:346
    #3 0x60450388 in db_command_loop () at ../../../ddb/db_command.c:472
    #4 0x60453179 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
    #5 0x606c34c3 in kdb_trap (type=3, code=0, regs=0xb086895c) at
    ../../../i386/i386/db_interface.c:171
    #6 0x606d8079 in trap (frame=
          {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1618097444, tf_esi =
    1, tf_ebp = -1333360216, tf_isp = -1333360248, tf_ebx = 0,
    tf_edx = 0, tf_ecx = 1627471872, tf_eax = 18, tf_trapno = 3, tf_err = 0,
    tf_eip = 1617704894, tf_cs = 8, tf_eflags = 134, tf_esp = 1
    618180660, tf_ss = 1618083699}) at ../../../i386/i386/trap.c:579
    #7 0x606c37be in Debugger (msg=0x0) at machine/cpufunc.h:65
    #8 0x6055dac4 in __panic (file=0x60723342 "../../../kern/subr_witness.c",
    line=654,
        fmt=0x60723524 "blockable sleep lock (%s) %s @ %s:%d") at
    ../../../kern/kern_shutdown.c:536
    #9 0x60584eee in witness_checkorder (lock=0x6b0fe104, flags=9,
    file=0x60734ac4 "vm/vm_page.c", line=1077)
        at ../../../kern/subr_witness.c:653
    #10 0x605538da in _mtx_lock_flags (m=0x68e5c000, opts=0, file=---Can't
    read userspace from dump, or kernel process---

    ) at ../../../kern/kern_mutex.c:249
    #11 0x606983e7 in vm_page_free_toq (m=0x68e5c000) at
    ../../../vm/vm_page.c:1077
    #12 0x60697624 in vm_page_free (m=0x610977d8) at ../../../vm/vm_page.c:395
    #13 0x60699eff in contigmalloc1 (size=8192, type=0x6076e4e0, flags=1,
    low=0, high=4294967295, alignment=1, boundary=0,
        map=0x6103b000) at ../../../vm/vm_contig.c:224
    #14 0x6069a23b in contigmalloc (size=0, type=0x0, flags=0, low=0, high=0,
    alignment=0, boundary=0) at ../../../vm/vm_contig.c:297
    #15 0x606c173d in bus_dmamem_alloc (dmat=0x6962cc80, vaddr=0x6e00db48,
    flags=0, mapp=0x0)
        at ../../../i386/i386/busdma_machdep.c:430
    #16 0x6050c07a in usb_block_allocmem (tag=0x0, size=8192, align=1,
    dmap=0x68fee33c) at ../../../dev/usb/usb_mem.c:186
    #17 0x6050c19f in usb_allocmem (bus=0x0, size=8192, align=0, p=0x68fee33c)
    at ../../../dev/usb/usb_mem.c:247
    #18 0x604fe1a7 in ohci_allocm (bus=0x0, dma=0x0, size=0) at
    ../../../dev/usb/ohci.c:954
    #19 0x6050e1c4 in usbd_transfer (xfer=0x68fee300) at
    ../../../dev/usb/usbdi.c:309
    #20 0x60507b91 in umass_setup_transfer (sc=0x0, pipe=0x0, buffer=0x0,
    buflen=0, flags=4, xfer=0x68fee300)
        at ../../../dev/usb/umass.c:1151
    #21 0x60508222 in umass_bbb_state (xfer=0x0, priv=0x6ba59500,
    err=1761534720) at ../../../dev/usb/umass.c:1517
    #22 0x6050ea91 in usb_transfer_complete (xfer=0x68fee300) at
    ../../../dev/usb/usbdi.c:834
    #23 0x604fe9a8 in ohci_softintr (v=0x68fce000) at
    ../../../dev/usb/ohci.c:1405
    #24 0x6050bba2 in usb_schedsoftintr (bus=0x0) at
    ../../../dev/usb/usb.c:840
    #25 0x604fe658 in ohci_intr1 (sc=0x68fce000) at
    ../../../dev/usb/ohci.c:1216
    #26 0x604fe4cf in ohci_intr (p=0x68fce000) at ../../../dev/usb/ohci.c:1145
    #27 0x60549a4f in ithread_loop (arg=0x68e4b280) at
    ../../../kern/kern_intr.c:547
    #28 0x605489f5 in fork_exit (callout=0x605498d0 <ithread_loop>, arg=0x0,
    frame=0x0) at ../../../kern/kern_fork.c:802
    (kgdb) up 11
    #11 0x606983e7 in vm_page_free_toq (m=0x68e5c000) at
    ../../../vm/vm_page.c:1077
    1077 VI_LOCK(vp);
    (kgdb) list
    1072 ((object->flags & OBJ_DEAD) == 0)
    1073 ) {
    1074 struct vnode *vp = (struct vnode *)object->handle;
    1075
    1076 if (vp) {
    1077 VI_LOCK(vp);
    1078 if (VSHOULDFREE(vp))
    1079 vfree(vp);
    1080 VI_UNLOCK(vp);
    1081 }
    (kgdb) up
    #12 0x60697624 in vm_page_free (m=0x610977d8) at ../../../vm/vm_page.c:395
    395 vm_page_free_toq(m);
    (kgdb) list
    390 */
    391 void
    392 vm_page_free(vm_page_t m)
    393 {
    394 vm_page_flag_clear(m, PG_ZERO);
    395 vm_page_free_toq(m);
    396 vm_page_zero_idle_wakeup();
    397 }
    398
    399 /*
    (kgdb) up
    #13 0x60699eff in contigmalloc1 (size=8192, type=0x6076e4e0, flags=1,
    low=0, high=4294967295, alignment=1, boundary=0,
        map=0x6103b000) at ../../../vm/vm_contig.c:224
    224 vm_page_free(m);
    (kgdb) list
    219 if (!VM_OBJECT_TRYLOCK(object)) {
    220 start++;
    221 goto again;
    222 }
    223 vm_page_busy(m);
    224 vm_page_free(m);
    225 VM_OBJECT_UNLOCK(object);
    226 }
    227 }
    228 for (i = start; i < (start + size / PAGE_SIZE);
    i++) {
    (kgdb) up
    #14 0x6069a23b in contigmalloc (size=0, type=0x0, flags=0, low=0, high=0,
    alignment=0, boundary=0) at ../../../vm/vm_contig.c:297
    297 ret = contigmalloc1(size, type, flags, low, high,
    alignment, boundary,
    (kgdb) list
    292 unsigned long boundary)
    293 {
    294 void * ret;
    295
    296 mtx_lock(&Giant);
    297 ret = contigmalloc1(size, type, flags, low, high,
    alignment, boundary,
    298 kernel_map);
    299 mtx_unlock(&Giant);
    300 return (ret);
    301 }
    (kgdb) up
    #15 0x606c173d in bus_dmamem_alloc (dmat=0x6962cc80, vaddr=0x6e00db48,
    flags=0, mapp=0x0)
        at ../../../i386/i386/busdma_machdep.c:430
    430 *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF,
    mflags,
    (kgdb) list
    425 /*
    426 * XXX Use Contigmalloc until it is merged into
    this facility
    427 * and handles multi-seg allocations. Nobody
    is doing
    428 * multi-seg allocations yet though.
    429 */
    430 *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF,
    mflags,
    431 0ul, dmat->lowaddr, dmat->alignment?
    dmat->alignment : 1ul,
    432 dmat->boundary);
    433 }
    434 if (*vaddr == NULL)
    (kgdb) up
    #16 0x6050c07a in usb_block_allocmem (tag=0x0, size=8192, align=1,
    dmap=0x68fee33c) at ../../../dev/usb/usb_mem.c:186
    186 if (bus_dmamem_alloc(p->tag, &p->kaddr,
    (kgdb) list
    181 goto free;
    182 }
    183
    184 p->size = size;
    185 p->align = align;
    186 if (bus_dmamem_alloc(p->tag, &p->kaddr,
    187 BUS_DMA_NOWAIT|BUS_DMA_COHERENT, &p->map))
    188 goto tagfree;
    189
    190 if (bus_dmamap_load(p->tag, p->map, p->kaddr, p->size,

    I'm a little troubled by all of the 0's that are passed to contigmalloc()
    as it passes all it's arguments to contigmalloc1(), which explicitly
    checks for a zero size. It would have expected to have gotten a
    "contigmalloc1: size must not be 0" panic in that case. Could this be
    another case of gdb screwing up on a frame?

    This issue is way above my level of USB and VM debugging skill, but I'm
    willing to learn and try different patches.

    System is:
    FreeBSD bling.home 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Tue Feb 10 15:14:29
    EST 2004 root@bling.home:/usr/src/sys/i386/compile/BLING i386

    I still have the debug kernel and crashdump around if there's any need for
    additional information. If this issue has already been fixed, please
    forgive me for wasting everyone's time.

    Regards,
    Andy

    > Andre Guibert de Bruet | Enterprise Software Consultant >
    > Silicon Landmark, LLC. | http://siliconlandmark.com/ >
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  • Next message: Andre Guibert de Bruet: "Re: /usr/src/sys/dev/aic7xxx errors when compiling"

    Relevant Pages

    • ddb(4) spoils kernel stack in CURRENT?
      ... My kernel config is: ... kgdb against the resulting kernel dump fails to print complete backtrace: ... Previous frame inner to this frame (corrupt stack?) ...
      (freebsd-current)
    • Helping interpreting crash
      ... My FreeBSD server crashed out the other night. ... So could anyone possibly have a look at below (or tell me of somewhere I can go to get the right info..bearing in mind I don't know all that much about the kernel) and let me know what's up? ... kgdb kernel.debug /var/crash/vmcore.1 ... #12 0xc05df0cf in syscall (frame= ...
      (freebsd-questions)
    • Kernel Panic
      ... During the last weeks I am getting sporadic kernel panics. ... I attached the kgdb output and can give additional information when it's ... Previous frame inner to this frame ...
      (freebsd-current)
    • 6.2-STABLE panic in network multicast-address related cleanup code
      ... The following kernel panic occurred twice yesterday evening under ... # kgdb /boot/kernel/kernel.debug vmcore.40 ... #19 0xc06e6577 in syscall (frame= ... Seems like some multi-cast related cleanups are broken. ...
      (freebsd-stable)
    • Re: 5.3-BETA5 panics when inserting dc0 carbus card (only with ACPI enabled) enabled)
      ... I can supply kernel config, vmcore, kernel.debug,and pciconf -lv ... GDB is free software, covered by the GNU General Public License, and you are ... Previous frame inner to this frame ...
      (freebsd-current)