Date: Wed, 8 Oct 2003 02:16:52 -0500 From: Alan Cox <alc@cs.rice.edu> To: Kris Kennaway <kris@obsecurity.org> Cc: current@FreeBSD.org Subject: Re: panic: mutex vm object not owned at ../../../vm/vm_page.c:762 Message-ID: <20031008071652.GC27527@cs.rice.edu> In-Reply-To: <20031006093030.GA653@rot13.obsecurity.org> References: <20031006093030.GA653@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 06, 2003 at 02:30:30AM -0700, Kris Kennaway wrote:
> I got this upon attempting to burn a CD with cdrecord on my
> freshly-updated current machine:
>
> panic: mutex vm object not owned at ../../../vm/vm_page.c:762
>
This should now be fixed.
Alan
> syncing disks, buffers remaining... 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842 3842
> giving up on 218 buffers
> Uptime: 16m51s
> Dumping 511 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
> ---
> Reading symbols from /boot/kernel/nvidia.ko...done.
> Loaded symbols for /boot/kernel/nvidia.ko
> #0 doadump () at ../../../kern/kern_shutdown.c:240
> 240 dumping++;
> (kgdb) bt
> #0 doadump () at ../../../kern/kern_shutdown.c:240
> #1 0xc054a32d in boot (howto=256) at ../../../kern/kern_shutdown.c:372
> #2 0xc054a6b7 in panic () at ../../../kern/kern_shutdown.c:550
> #3 0xc05410cc in _mtx_assert (m=0xc4ea4c24, what=0, file=0xc06f8518 "../../../vm/vm_page.c", line=762)
> at ../../../kern/kern_mutex.c:855
> #4 0xc065c03c in vm_page_alloc (object=0xc4ea4c24, pindex=0, req=0) at ../../../vm/vm_page.c:762
> #5 0xc064e68b in vm_fault_copy_entry (dst_map=0xc4f527e0, src_map=0xc4d653f0, dst_entry=0xc537fd5c,
> src_entry=0x0) at ../../../vm/vm_fault.c:1167
> #6 0xc0654e81 in vm_map_copy_entry (src_map=0xc4d653f0, dst_map=0xc4f527e0, src_entry=0xc537f834,
> dst_entry=0xc537fd5c) at ../../../vm/vm_map.c:2379
> #7 0xc06551c6 in vmspace_fork (vm1=0xc4d653f0) at ../../../vm/vm_map.c:2494
> #8 0xc064fcce in vm_forkproc (td=0xc4ebe130, p2=0xc53855ac, td2=0xc4ebeab0, flags=20)
> at ../../../vm/vm_glue.c:624
> #9 0xc05353f5 in fork1 (td=0xc4ebe130, flags=20, pages=0, procp=0xd9d38cd8) at ../../../kern/kern_fork.c:654
> #10 0xc053441b in fork (td=0xc4ebe130, uap=0xd9d38d10) at ../../../kern/kern_fork.c:102
> #11 0xc06a4d93 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4096, tf_esi = 65536, tf_ebp = -1077948008, tf_isp = -640447116, tf_ebx = 64, tf_edx = 1307, tf_ecx = 672806144, tf_eax = 2, tf_trapno = 0, tf_err = 2, tf_eip = 672202079, tf_cs = 31, tf_eflags = 582, tf_esp = -1077948052, tf_ss = 47}) at ../../../i386/i386/trap.c:1006
> #12 0xc069505d in Xint0x80_syscall () at {standard input}:144
> ---Can't read userspace from dump, or kernel process---
> (kgdb)
>
> The annoying thing was that something apparently overwrote the
> partition table on the disk holding the swap partition - I had to
> recreate it by hand before I could bring the system back up, although
> it then came back up without further problems.
>
> Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031008071652.GC27527>