Re: panic: mutex Giant not owned at /usr/src/sys/vm/vm_page.c:544

I too have this problem intermittently.
and at this exact moment.
Dave
On Tuesday, April 22, 2003, at 10:25 AM, David Wolfskill wrote:

> 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 _at_ 
> /usr/src/sys/vm/uma_core.c:838
> exclusive sleep mutex system map r = 0 (0xc082f110) locked _at_ 
> /usr/src/sys/vm/vm_kern.c:325
> exclusive sx GEOM event stalling r = 0 (0xc03f56a0) locked _at_ 
> /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_at_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.
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe_at_freebsd.org"