panic on sparc64
Maksim Yevmenkin
maksim.yevmenkin at gmail.com
Wed Oct 10 13:58:49 PDT 2007
hello,
recent -current often panics with the following stack trace on sparc64.
is this something new? or has it been fixed already?
thanks,
max
panic: mutex vm page queue mutex not owned at
/usr/src/sys/sparc64/sparc64/pmap.c:1768
cpuid = 0
KDB: enter: panic
panic: from debugger
cpuid = 0
Uptime: 9h36m23s
Dumping 256 MB (2 chunks)
chunk at 0: 134217728 bytes |
#0 0x00000000c0280318 in doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 savectx(&dumppcb);
(kgdb) where
#0 0x00000000c0280318 in doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0x00000000c0280d40 in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:409
#2 0x00000000c0281124 in panic (fmt=0xc06454f0 "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:563
#3 0x00000000c009ed28 in db_panic (addr=3224044552, have_addr=0, count=-1,
modif=0xceff6868 "") at /usr/src/sys/ddb/db_command.c:433
#4 0x00000000c009fc74 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:401
#5 0x00000000c00a2d34 in db_trap (type=Variable "type" is not available.
) at /usr/src/sys/ddb/db_main.c:222
#6 0x00000000c02b00d4 in kdb_trap (type=107, code=0, tf=0xceff6cd0)
at /usr/src/sys/kern/subr_kdb.c:502
#7 0x00000000c0559990 in trap (tf=0xceff6cd0)
at /usr/src/sys/sparc64/sparc64/trap.c:318
#8 0x00000000c0071000 in tl1_trap ()
#9 0x00000000c02b0408 in kdb_enter (msg=0x12 <Address 0x12 out of bounds>)
at /usr/src/sys/kern/subr_kdb.c:307
#10 0x00000000c02b0408 in kdb_enter (msg=0xc066c008 "panic")
at /usr/src/sys/kern/subr_kdb.c:307
#11 0x00000000c02810ec in panic (fmt=0xc066a978 "mutex %s not owned at %s:%d")
at /usr/src/sys/kern/kern_shutdown.c:547
#12 0x00000000c0272894 in _mtx_assert (m=0xc07e1598, what=1,
file=0xc069aaf0 "/usr/src/sys/sparc64/sparc64/pmap.c", line=1768)
at /usr/src/sys/kern/kern_mutex.c:623
#13 0x00000000c0551660 in pmap_page_is_mapped (m=0xfffff80007be2768)
at /usr/src/sys/sparc64/sparc64/pmap.c:1768
#14 0x00000000c04e6f14 in vm_page_free_toq (m=0xfffff80007be2768)
at /usr/src/sys/vm/vm_page.c:1258
#15 0x00000000c04e72d8 in vm_page_free (m=0xfffff80007be2768)
at /usr/src/sys/vm/vm_page.c:498
#16 0x00000000c055bb84 in uma_small_free (mem=0xfffff80001252000, size=8192,
flags=8 '\b') at /usr/src/sys/sparc64/sparc64/vm_machdep.c:505
#17 0x00000000c04d3d78 in zone_drain (zone=0xfffff80007fec900)
at /usr/src/sys/vm/uma_core.c:767
#18 0x00000000c04cf194 in zone_foreach (zfunc=0xc04d3aa0 <zone_drain>)
at /usr/src/sys/vm/uma_core.c:1495
#19 0x00000000c04d41c8 in uma_reclaim () at /usr/src/sys/vm/uma_core.c:2670
#20 0x00000000c04eaf20 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:696
#21 0x00000000c025bf24 in fork_exit (callout=0xc04ea560 <vm_pageout>, arg=0x0,
frame=0xceff7880) at /usr/src/sys/kern/kern_fork.c:796
#22 0x00000000c00711f0 in fork_trampoline ()
#23 0x00000000c00711f0 in fork_trampoline ()
Previous frame identical to this frame (corrupt stack?)
More information about the freebsd-current
mailing list