Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Apr 2003 08:25:36 -0700 (PDT)
From:      David Wolfskill <david@catwhisker.org>
To:        current@freebsd.org
Subject:   panic: mutex Giant not owned at /usr/src/sys/vm/vm_page.c:544
Message-ID:  <200304221525.h3MFPaSN005306@bunrab.catwhisker.org>

next in thread | raw e-mail | index | archive | help
Today's -CURRENT (CVSup from 0347 - 0356 hrs. PDT (US/Pacific).  Built
without incident.  Cut'n'paste from serial console of my SMP (2x886MHz
PIIIs) build machine:

acd0: <Compaq CRD-8322B/1.06> CDROM drive at ata1 as master
acd0: read 5500KB/s (21KB/s), 128KB buffer, PIO4
acd0: Reads: CD-R, CD-RW, CD-DA stream, packet
acd0: Writes:
acd0: Audio: play, 255 volume levels
acd0: Mechanism: ejectable tray, unlocked, lock protected
acd0: Medium: no/blank disc
SMP: AP CPU #1 Launched!
SMP: CPU1 ap_init():
     lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000000 SVR: 0x000001ff
panic: mutex Giant not owned at /usr/src/sys/vm/vm_page.c:544
cpuid = 1; lapic.id = 01000000
Debugger("panic")
Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db> tr
Debugger(c0394cfb,1000000,c0394433,d68e192c,1) at Debugger+0x55
panic(c0394433,c039456c,c03ab27e,220,315) at panic+0x11f
_mtx_assert(c03fa2e0,1,c03ab27e,220,c08639f8) at _mtx_assert+0xec
vm_page_insert(c08639f8,c042a180,2,0,1) at vm_page_insert+0x62
vm_page_alloc(c042a180,2,0,1,0) at vm_page_alloc+0x34b
obj_alloc(c083a8c0,1000,d68e19ef,101,c03c866c) at obj_alloc+0x79
slab_zalloc(c083a8c0,1,c083a8c0,c082efa4,c082ef3c) at slab_zalloc+0x150
uma_zone_slab(c083a8c0,1,c03abd03,61c,c083a9dc) at uma_zone_slab+0xd8
uma_zalloc_bucket(c083a8c0,1,c03abd03,586,1) at uma_zalloc_bucket+0x17d
uma_zalloc_arg(c083a8c0,0,1,d68e1ad0,c0315595) at uma_zalloc_arg+0x307
vm_map_entry_create(c082f0b0,0,c03aa4af,33b,1) at vm_map_entry_create+0x4d
vm_map_insert(c082f0b0,c042a400,4268000,0,c4167000) at vm_map_insert+0x285
kmem_malloc(c082f0b0,1000,1,d68e1b5c,c0324a00) at kmem_malloc+0x185
page_alloc(c14e4700,1000,d68e1b4f,1,c03c866c) at page_alloc+0x27
slab_zalloc(c14e4700,101,c14e4700,c4164fd8,c4164e00) at slab_zalloc+0x150
uma_zone_slab(c14e4700,101,c03abd03,61c,c14e481c) at uma_zone_slab+0xd8
uma_zalloc_bucket(c14e4700,101,c03abd03,586,1) at uma_zalloc_bucket+0x17d
uma_zalloc_arg(c14e4700,0,101,d68e1c54,90) at uma_zalloc_arg+0x307
malloc(90,c03c3400,101,4,d68e1c3c) at malloc+0xd4
g_new_bio(2,c0390b80,c0387725,4,c03e0ac0) at g_new_bio+0x4f
g_io_getattr(c0387725,c402a600,d68e1c54,d68e1c84,4) at g_io_getattr+0x32
g_getattr__(c0387725,c402a600,d68e1c84,4,d68e1c8c) at g_getattr__+0x2f
g_mbr_taste(c03e0ac0,c415e800,0,bf,163) at g_mbr_taste+0x101
g_do_event(c415e780,0,c03909d9,f6,66666667) at g_do_event+0x1f0
one_event(d68e1d08,c01b2a15,c03f5844,0,4c) at one_event+0x1e2
g_run_events(c03f5844,0,4c,c0390d56,a) at g_run_events+0x15
g_event_procbody(0,d68e1d48,c0392a00,313,0) at g_event_procbody+0x45
fork_exit(c01b29d0,0,d68e1d48) at fork_exit+0xc1
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd68e1d7c, ebp = 0 ---
db> show locks  
exclusive sleep mutex vm object r = 0 (0xc042a180) locked @ /usr/src/sys/vm/uma_core.c:838
exclusive sleep mutex system map r = 0 (0xc082f110) locked @ /usr/src/sys/vm/vm_kern.c:325
exclusive sx GEOM event stalling r = 0 (0xc03f56a0) locked @ /usr/src/sys/geom/geom_event.c:225
db> show pcpu 0
cpuid        = 0
curthread    = 0xc150b980: pid 33 "pagezero"
curpcb       = 0xd6931da0
fpcurthread  = none
idlethread   = 0xc1504980: pid 12 "idle: cpu0"
currentldt   = 0x28
spin locks held:
db> show pcpu 1
cpuid        = 1
curthread    = 0xc1504e40: pid 2 "g_event"
curpcb       = 0xd68e1da0
fpcurthread  = none
idlethread   = 0xc1504850: pid 11 "idle: cpu1"
currentldt   = 0x28
spin locks held:
db> 

As noted at other times, getting this machine up & running again is not
especially time-critical for the next several hours; I can poke at it
and rebuild things, including trying out patches or whatever.

Peace,
david
-- 
David H. Wolfskill				david@catwhisker.org
Based on what I have seen to date, the use of Microsoft products is not
consistent with reliability.  I recommend FreeBSD for reliable systems.



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