Re: panic: mutex Giant not owned

From: Jun Kuriyama <kuriyama_at_imgsrc.co.jp>
Date: Thu, 09 Sep 2004 23:52:52 +0900
At Thu, 09 Sep 2004 23:42:04 +0900,
kuriyama wrote:
> This is current as of 2004.09.08.20.00.00+00.

After this message, I tried to take a dump.

-----
db> panic         
panic: from debugger
cpuid = 1
boot() called on cpu#1
Uptime: 6h15m31s
Dumping 2047 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 1536 1552 1568 1584 1600 1616 1632 1648 1664 1680 1696 1712 1728 1744 1760 1776 1792 1808 1824 1840 1856 1872 1888 1904 1920 1936 1952 1968 1984 2000 2016 2032
Dump complete
Shutting down ACPI
    ACPI-0265: *** Error: Hardware never changed modes
panic: pmap_invalidate_page: interrupts disabled
cpuid = 1
KDB: enter: panic
[thread 100305]
Stopped at      kdb_enter+0x2b: nop
db> trace
kdb_enter(c068845a) at kdb_enter+0x2b
panic(c06a2f43,c066bcdb,0,c0744e40,ed1397bc) at panic+0x127
pmap_invalidate_page(c0744e40,c4624000) at pmap_invalidate_page+0x2a
pmap_enter(c0744e40,c4624000,c1109778,7,1,c072bba0,4725,0) at pmap_enter+0x21c
kmem_malloc(c103a0c0,1000,101,ed139844,c0614aa5) at kmem_malloc+0x367
page_alloc(c1044840,1000,ed139837,101,40) at page_alloc+0x1a
slab_zalloc(c1044840,101,c1044840,c06da764,c1045460) at slab_zalloc+0xa1
uma_zone_slab(c1044840,1,c1045468,0,c069deed,856) at uma_zone_slab+0xd0
uma_zalloc_internal(c1044840,0,1,0,c1033468) at uma_zalloc_internal+0x29
bucket_alloc(80,1,1,1,c1045960) at bucket_alloc+0x4c
uma_zfree_arg(c1033420,c34a9540,c34a9e20) at uma_zfree_arg+0x22c
free(c34a9540,c0838660,ed139918,c081312a,c34a9540) at free+0xd1
AcpiOsFree(c34a9540,0,c34a9580,3,ed139930) at AcpiOsFree+0x10
AcpiNsDeleteChildren(c34a9580,c3537a80,c344d000,c344d00c,ed13993c) at AcpiNsDeleteChildren+0x6e
AcpiNsDeleteNamespaceSubtree(c0838e14,ed139944,c081ca65,ed13994c,c081d970) at AcpiNsDeleteNamespaceSubtree+0x53
AcpiNsTerminate(ed13994c,c081d970,ed139958,c081f6af,c08337ca) at AcpiNsTerminate+0xe
AcpiUtSubsystemShutdown(ed139958,c081f6af,c08337ca,ed139998,c04fe29b) at AcpiUtSubsystemShutdown+0x1d
AcpiTerminate(c08337ca,ed139998,c04fe29b,c34d3400,104) at AcpiTerminate+0x8
acpi_shutdown_final(c34d3400,104,c344d00c,0,c068847e) at acpi_shutdown_final+0x8f
boot(104,104,c43d27d0,0,c06a8964) at boot+0x61f
panic(c067141e,ed139a78,c0444898,c051411f,0) at panic+0x175
db_panic(c051411f,0,ffffffff,ed1399ec,0) at db_panic+0xd
db_command(c06e7424,c06ae180,c06a8964,c06a8968,c067142c) at db_command+0x264
db_command_loop(0,0,ed139aa4,ed139a90,ed139ad8) at db_command_loop+0x5c
db_trap(3,0,3,c43d27d0,ed139b24) at db_trap+0xdd
kdb_trap(3,0,ed139b2c) at kdb_trap+0x8b
trap(ed130018,c0510010,c0680010,c0687917,1) at trap+0x480
calltrap() at calltrap+0x5
--- trap 0x3, eip = 0xc051411f, esp = 0xed139b6c, ebp = 0xed139b6c ---
kdb_enter(c068845a) at kdb_enter+0x2b
panic(c0687917,c0698812,c06857cf,536,c4262bf4) at panic+0x127
_mtx_assert(c06f2280,1,c06857cf,536,c4262bf4) at _mtx_assert+0x5c
kqueue_close(c4262bf4,c43d27d0) at kqueue_close+0x28
fdrop_locked(c4262bf4,c43d27d0,c344bd24,0,c06853b7) at fdrop_locked+0x84
fdrop(c4262bf4,c43d27d0) at fdrop+0x24
kevent(c43d27d0,ed139d14,6,7,282) at kevent+0x1d6
syscall(2f,2f,2f,bfaedb80,1) at syscall+0x213
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (363, FreeBSD ELF32, kevent), eip = 0x281e5c4b, esp = 0xbfaedb54, ebp = 0xbfaedfc0 ---
-----


-- 
Jun Kuriyama <kuriyama_at_imgsrc.co.jp> // IMG SRC, Inc.
             <kuriyama_at_FreeBSD.org> // FreeBSD Project
Received on Thu Sep 09 2004 - 12:52:55 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:11 UTC