On 03/15/2014 20:26, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Sat, Mar 15, 2014 at 18:17 -0700: >> How far along does it get? > It rarely gets to multiuser, and even if it does, it panics very > shortly afterward: > panic: vm_page_alloc: page 0xc0805db0 is wired > > I did finally get around to dumping the vm_page struct for it (the > CTF crazyness) and I did send it to alc and kib, but neither one has > replied... > > here is a dump in case someone else has some vm_page clue: > {'act_count': '\x00', > 'aflags': '\x00', > 'busy_lock': 1, > 'dirty': '\xff', > 'flags': 0, > 'hold_count': 0, > 'listq': {'tqe_next': 0xc0805e00, 'tqe_prev': 0xc06d18a0}, > 'md': {'pv_kva': 3235856384, > 'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc0805de0}, > 'pv_memattr': '\x00', > 'pvh_attrs': 0}, > 'object': 0xc06d1878, > 'oflags': '\x04', > 'order': '\t', > 'phys_addr': 17776640, > 'pindex': 3572, > 'plinks': {'memguard': {'p': 0, 'v': 3228376932}, > 'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06d1f64}, > 's': {'pv': 0xc06d1f64, 'ss': {'sle_next': 0x0}}}, > 'pool': '\x00', > 'queue': '\xff', > 'segind': '\x01', > 'valid': '\xff', > 'wire_count': 1} > > and as you can see, wire_count is not 0... but looks resonable...
There are several things wrong with this page. Two lines later, this assertion would also fail: KASSERT(m->dirty == 0, ("vm_page_alloc: page %p is dirty", m)); because a page in the cache/free lists should never be dirty. The page's flags field doesn't include PG_CACHED. So, the object field should be NULL and the valid field should be 0, but they are not. All of these fields are (explicitly) cleared when a page is freed (cf. vm_page_free_toq()). Can you determine if the value of the object field matches the address of either kernel_object or kmem_object? The oflags field containing VPO_UNMANAGED makes that likely. In a nutshell, this looks like the same page is simultaneously in use by one part of the kernel and free in another part. I doubt that it's a simple case of use after free. In that case, the dirty, object, and valid fields would be zero, and the crash would be in a different part of the kernel. > So, I'm blocked until someone w/ clue tells me what more I need to do > to debug this... > _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"