Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 May 2005 10:29:10 -0700 (PDT)
From:      Doug White <dwhite@gumbysoft.com>
To:        Daniel Eriksson <daniel_k_eriksson@telia.com>
Cc:        'John Baldwin' <jhb@FreeBSD.org>
Subject:   RE: task queue: supervisor write, page not present
Message-ID:  <20050505102605.H47211@carver.gumbysoft.com>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAg/SpT//m70Cq10eNTNNaogEAAAAA@telia.com>
References:  <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAg/SpT//m70Cq10eNTNNaogEAAAAA@telia.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 May 2005, Daniel Eriksson wrote:

> John Baldwin wrote:
>
> > Did Sam's recent fixes to taskqueues fix this panic for you?
>
> Less than 24 hours after going back to the usage pattern the server had when
> it crashed several times last month, it crashed again. This time it looks a
> little bit different. Not sure it is related at all. This is on an dual CPU
> (AMD AthlonMP) machine.
>
> System/kernel compiled from sources dated: 2005.04.29.23.00.00
>
> I have both a debug kernel and a dump that I can make available if someone
> wants to look closer at this.

>From the traceback it looks like the object at the end of
swap_pager_putpages() has been ripped out from under us since the mutex is
NULL.  Can you print the address and contents of "object" in that frame?
Considering we'd just locked and unlocked the object in the preceeding
loop, I don't think we're corrupting it...

Also odd the traceback is different between ddb and gdb.

>
> /Daniel Eriksson
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 00
> fault virtual address   = 0x1c
> fault code              = supervisor write, page not present
> instruction pointer     = 0x20:0xc069ee7f
> stack pointer           = 0x28:0xe09d8c20
> frame pointer           = 0x28:0xe09d8c44
> 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         = 3 (g_up)
> [thread pid 3 tid 100041 ]
> Stopped at      swp_pager_async_iodone+0x8f:    lock cmpxchgl
> %edx,0x1c(%ecx)
> db> wh
> Tracing pid 3 tid 100041 td 0xc1ecd600
> swp_pager_async_iodone(d1721040,c1ecd600,0,0,0) at
> swp_pager_async_iodone+0x8f
> bufdone(d1721040,c3f6d738,e09d8cc0,c05ac6af,c3f6d738) at bufdone+0x16f
> swapgeom_done(c3f6d738,0,c1ecd600,0,c1ecd600) at swapgeom_done+0x37
> biodone(c3f6d738,c0793168,24c,c0736c91,c8) at biodone+0xaf
> g_io_schedule_up(c1ecd600,4c,c1ecd600,c050f970,e09d8d04) at
> g_io_schedule_up+0x66
> g_up_procbody(0,e09d8d38,0,0,0) at g_up_procbody+0xaf
> fork_exit(c050f970,0,e09d8d38) at fork_exit+0x80
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xe09d8d6c, ebp = 0 ---
>
> (kgdb) where
> #0  doadump () at pcpu.h:165
> #1  0xc0452b15 in db_fncall (dummy1=15, dummy2=0, dummy3=1021,
> dummy4=0xe09d8a28 "") at /usr/src/sys/ddb/db_command.c:531
> #2  0xc0452892 in db_command (last_cmdp=0xc078d8a4, cmd_table=0x0,
> aux_cmd_tablep=0xc07553fc, aux_cmd_tablep_end=0xc0755400)
>     at /usr/src/sys/ddb/db_command.c:349
> #3  0xc045299a in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
> #4  0xc04549f5 in db_trap (type=12, code=0) at
> /usr/src/sys/ddb/db_main.c:221
> #5  0xc0571d4e in kdb_trap (type=0, code=0, tf=0xe09d8be0) at
> /usr/src/sys/kern/subr_kdb.c:421
> #6  0xc06faf46 in trap_fatal (frame=0xe09d8be0, eva=0) at
> /usr/src/sys/i386/i386/trap.c:801
> #7  0xc06fac32 in trap_pfault (frame=0xe09d8be0, usermode=0, eva=28) at
> /usr/src/sys/i386/i386/trap.c:724
> #8  0xc06fa7b2 in trap (frame=
>       {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = -781053888,
> tf_ebp = -526545852, tf_isp = -526545908, tf_ebx = -1066799632, tf_edx =
> -1041443328, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip =
> -1066799489, tf_cs = 32, tf_eflags = 66050, tf_esp = -660721664, tf_ss = 1})
> at /usr/src/sys/i386/i386/trap.c:414
> #9  0xc06e559a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #10 0x00000008 in ?? ()
> #11 0x00000028 in ?? ()
> #12 0x00000028 in ?? ()
> #13 0x00000000 in ?? ()
> #14 0xd1721040 in ?? ()
> #15 0xe09d8c44 in ?? ()
> #16 0xe09d8c0c in ?? ()
> #17 0xc069edf0 in swap_pager_putpages () at
> /usr/src/sys/vm/swap_pager.c:1375
> #18 0xc05acb5f in bufdone (bp=0xd1721040) at
> /usr/src/sys/kern/vfs_bio.c:3096
> #19 0xc06a0b17 in swapgeom_done (bp2=0xc3f6d738) at
> /usr/src/sys/vm/swap_pager.c:2355
> #20 0xc05ac6af in biodone (bp=0xc3f6d738) at
> /usr/src/sys/kern/vfs_bio.c:2927
> #21 0xc050f736 in g_io_schedule_up (tp=0xc1ecd600) at
> /usr/src/sys/geom/geom_io.c:489
> #22 0xc050fa1f in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95
> #23 0xc0539b30 in fork_exit (callout=0xc050f970 <g_up_procbody>, arg=0x0,
> frame=0x0) at /usr/src/sys/kern/kern_fork.c:789
> #24 0xc06e55fc in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:208
>
>

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite@gumbysoft.com          |  www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050505102605.H47211>