Fatal trap 12 under RELENG_5_1, anyone who can help?

From: Eivind Olsen (eivind_at_aminor.no)
Date: 08/01/03

  • Next message: Tinderbox: "[current tinderbox] failure on i386/pc98"
    Date: Fri, 01 Aug 2003 10:08:43 +0200
    To: current@freebsd.org
    
    

    Hello.
    My FreeBSD RELENG_5_1 server (cvsupped 4 days ago) seems to have problems -
    it crashes from time to time (approx. once a day).

    I've rebuilt the kernel with debug-symbols and enabled the debugger and
    caught a crash tonight:

    Here's what I had on screen (I also ran "show reg" and "trace"):

    Fatal trap 12: page fault while in kernel mode
    fault virtual address = 0x14
    fault code = supervisor write, page not present
    instruction pointer = 0x8:0xc02e8139
    stack pointer = 0x10:0xcfbf684c
    frame pointer = 0x10:0xcfbf6880
    code segment = base 0x0, limit 0xfffff, type 0x1b
                            = DPL 0, pres 1, def32 1, gran 1
    processor eflags = interrupt enabled, resume, IOPL = 0
    current process = 46373 (ctl_cyrusdb)
    kernel: type 12 trap, code=0
    Stopped at g_dev_strategy+0x29: movl %eax,0x14(%ebx)
    db> show reg
    cs 0x8
    ds 0x10
    es 0x10
    fs 0x18
    ss 0x10
    eax 0xf7255200
    ecx 0
    edx 0
    ebx 0
    esp 0xcfbf684c
    ebp 0xcfbf6880
    esi 0xc201e824
    edi 0xc2044900
    eip 0xc02e8139 g_dev_strategy+0x29
    efl 0x10286
    dr0 0
    dr1 0
    dr2 0
    dr3 0
    dr4 0xffff0ff0
    dr5 0x400
    dr6 0xffff0ff0
    dr7 0x400
    g_dev_strategy+0x29: movl %eax,0x14(%ebx)
    db> trace
    g_dev_strategy(c201e824,c2152800,0,cfbf68d0,c2098eca) at g_dev_strategy+0x29
    launch_requests(c2e16e80,0,10000,ffffffff,43) at launch_requests+0x448
    vinumstart(c5ad9da8,0,c243aab0,cfbf694c,c02e5bc6) at vinumstart+0x2b2
    vinumstrategy(c5ad9da8,0,c0b79490,40,0) at vinumstrategy+0xa6
    spec_xstrategy(c215b7fc,c5ad9da8,cfbf6968,c02e4f18,cfbf6994) at
    spec_xstrategy+0x306
    spec_specstrategy(cfbf6994,cfbf69b0,c044f7ad,cfbf6994,0) at
    spec_specstrategy+0x1b
    spec_vnoperate(cfbf6994,0,c0b79490,f,c5ad9da8) at spec_vnoperate+0x18
    ufs_strategy(cfbf69d8,cfbf6a0c,c0359a87,cfbf69d8,1) at ufs_strategy+0xdd
    ufs_vnoperate(cfbf69d8,1,c0504f45,35e,cfbf69f8) at ufs_vnoperate+0x18
    bwrite(c5ad9da8,cfbf6a5c,c0361aca,c5ad9da8,c5ad9ed8) at bwrite+0x3a7
    bawrite(c5ad9da8,c5ad9ed8,10,3c6,20020080) at bawrite+0x1c
    cluster_wbuild(c302c000,4000,4c,0,4) at cluster_wbuild+0x6ba
    cluster_write(c5afaf08,84cf9c,0,51,c2f82300) at cluster_write+0x571
    ffs_write(cfbf6be0,c1fb97f8,c243aab0,227,c2158600) at ffs_wrie+0x5ff
    vn_write(c1fb97f8,cfbf6c7c,c2f82300,0,c243aab0) at vn_write+0x192
    write(c243aab0,cfbf6d10,c0518514,3fb,3) at write+0x69
    syscall(2f,2f,2f,0,807e000) at syscall+0x24e
    Xint0x80_syscall() at Xint0x80_syscall+0x1d
    --- syscall (4, FreeBSD ELF32, write), eip = 0x282e08b3, esp = 0xbfbfec1c,
    ebp = 0xbfbfec38 ---
    db>

    I _think_ I've managed to type it all in correctly.

    No crash dump was made (I have dumpdev="/dev/ad0s1b" in /etc/rc.conf) - are
    there anything else I need to do to get it to crashdump to that device?
    Should I have given any other commands to the internal debugger to find
    more information?

    The kernel I'm running is really GENERIC with a few small changes:

    vimes# diff VIMES /usr/src/sys/i386/conf/GENERIC
    25c25
    < ident trisha

    ---
    > ident         GENERIC
    30c30
    < makeoptions   DEBUG=-g                #Build kernel with gdb(1) debug 
    symbols
    ---
    > #makeoptions  DEBUG=-g                #Build kernel with gdb(1) debug 
    symbols
    62c62
    < options       DDB                     #Enable the kernel debugger
    ---
    > #options      DDB                     #Enable the kernel debugger
    266,269d265
    < # This option is a subset of the IPFILTER option.
    < options       IPFILTER                #ipfilter support
    < options       IPFILTER_LOG            #ipfilter logging
    < options       IPFILTER_DEFAULT_BLOCK  #block all packets by default
    vimes#
    So, can anyone help me out here? Are there anything else I should have done 
    to find more information? Any other commands to give to the kernel 
    debugger? Any way of making the crashdump happen next time I see a kernel 
    trap like this?
    -- 
    Eivind Olsen
    eivind@aminor.no
    _______________________________________________
    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: Tinderbox: "[current tinderbox] failure on i386/pc98"

    Relevant Pages

    • STOP MESSAGE - Possibly Causes
      ... Here is the diagnose of the dump file from the debugger: ... Copyright Microsoft Corporation. ... Loading Kernel Symbols ... This means a trap occurred in kernel mode, and it's a trap of a kind ...
      (microsoft.public.windowsxp.help_and_support)
    • Re: How to enable KITL for CEPC..
      ... KeyIndex 0 = -1 ... Cannot access selected Device from service host. ... Debugger could not initialize connection. ... The Kernel Debugger has been disconnected successfully. ...
      (microsoft.public.windowsce.platbuilder)
    • Re: Windbg: Disable user mode debugging
      ... >> This group is not applicable because of the win32 in the title. ... So you don't have 64-bit Windows. ... debugger is an extension to ntoskrnl and maybe the hal too. ... I do know that the kernel does not have ...
      (microsoft.public.win32.programmer.kernel)
    • Random reboots
      ... Microsoft Windows Debugger Version 6.9.0003.113 X86 ... Copyright Microsoft Corporation. ... Loading Kernel Symbols ... Loaded symbol image file: ntkrnlpa.exe ...
      (microsoft.public.windowsxp.help_and_support)
    • more panics from current (partII)
      ... traces look quite the same. ... kernel trap 19 with interrupts disabled ... panic: from debugger ...
      (freebsd-current)