Date: Thu, 22 Oct 1998 19:57:48 -0700 From: David Greenman <dg@root.com> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: zach@gaffaneys.com (Zach Heilig), FreeBSD-current@FreeBSD.ORG Subject: Re: cdda2wav == panic (/sys/vm/vm_page.c:516) Message-ID: <199810230257.TAA11585@implode.root.com> In-Reply-To: Your message of "Thu, 22 Oct 1998 10:53:15 MDT." <199810221653.KAA16575@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> #7 0xf01f6d93 in trap_fatal (frame=0xf48dac70) at ../../i386/i386/trap.c:874
>> #8 0xf01f6a84 in trap_pfault (frame=0xf48dac70, usermode=0)
>> at ../../i386/i386/trap.c:772
>> #9 0xf01f66d7 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -236365800,
>> tf_esi = 8550, tf_ebp = -192041804, tf_isp = -192041832, tf_ebx = 51390,
>> tf_edx = 65470, tf_ecx = -192026224, tf_eax = -264085512,
>> tf_trapno = 12, tf_err = 0, tf_eip = -266451744, tf_cs = 8,
>> tf_eflags = 66054, tf_esp = 0, tf_ss = 0}) at ../../i386/i386/trap.c:396
>> #10 0xf01e44e0 in vm_page_lookup (object=0xf48de990, pindex=8550)
>> at ../../vm/vm_page.c:516
>> #11 0xf01630c7 in allocbuf (bp=0xf1e95818, size=8192)
>> at ../../kern/vfs_bio.c:1782
The above indicates that the VM object hash list has been messed up for
some reason. A VM object might have gotten trashed or perhaps the list
pointers were messed up due to missing splvm protection somewhere.
>Here's the stack trace from my panic last month (Sept. 8th):
>
>==================================================================
>login: vm_page_free: pindex(63), busy(0), PG_BUSY(1), hold(9)
>panic: vm_page_free: freeing busy page
>mp_lock = 01000001; cpuid = 1; lapic.id = 00000000
>Debugger("panic")
>Stopped at _Debugger+0x35: movb $0,_in_Debugger.98
>db> trace
>_Debugger(f0134343) at _Debugger+0x35
>_panic(f01f17ff,f054241c,80000000,f83f3ea8,f01f19b0) at _panic+0x8d
>_vm_page_freechk_and_unqueue(f054241c) at _vm_page_freechk_and_unqueue+0x6e
>_vm_page_free(f054241c,f8976220,0,f83f3ed4,f01eeffd) at _vm_page_free+0x1c
>_vm_object_terminate(f8976220,f4dd85f0,f091e220,f189e440,f83f3ee8) at _vm_object_terminate+0xb7
>_vm_object_deallocate(f8976220,f4dd85f0,0,f83f3f00,f01423fe) at _vm_object_deallocate+0x1c9
>_shm_deallocate_segment(f4dd85f0,f189e440,0,f8344cc0,f83f3f1c) at _shm_deallocate_segment+0x12
>_shm_delete_mapping(f8344cc0,f189e440) at _shm_delete_mapping+0x6e
>_shmexit(f8344cc0) at _shmexit+0x29
>_exit1(f8344cc0,0,f83f3fb4,f020dbdf,f8344cc0) at _exit1+0x1bc
This is a different, apparantly unrelated panic that seems to be caused by
a bug with the original page allocation - it isn't properly clearing the
PG_BUSY flag (via vm_page_wakeup()). This might be a bug in vm_fault().
>If I knew what the problem was, I would have probably fixed it by now. :)
>I think it will take someone knowledgeable about the VM system to fix this,
>so I'm CCing this to David. :)
...
>The CAM passthrough driver uses vmapbuf() and vunmapbuf() (via
>cam_periph_mapmem()) to map data segments into and out of kernel virtual
>memory. My guess is that this, in combination with cdda2wav's shared
>memory usage, exposes some VM bug.
Hmmm.
-DG
David Greenman
Co-founder/Principal Architect, The FreeBSD Project
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810230257.TAA11585>