Date: Sat, 23 Jan 1999 19:45:48 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@netplex.com.au> Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG Subject: Re: panic: found dirty cache page 0xf046f1c0 Message-ID: <Pine.BSF.4.01.9901231943140.59627-100000@herring.nlsystems.com> In-Reply-To: <199901231928.DAA00732@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 24 Jan 1999, Peter Wemm wrote:
> Doug Rabson wrote:
> > On Sat, 23 Jan 1999, Matthew Dillon wrote:
> >
> > >
> > > :I made it happen again by doing the same installworld but this time I
> > > :caught it in the debugger. I'll leave the machine up for a while in case
> > > :someone has some idea of how to debug it. The stacktrace looks like this:
> > > :
> > > :#0 Debugger () at ../../alpha/alpha/db_interface.c:260
> > > :#1 0xfffffc000036c2c0 in panic () at ../../kern/kern_shutdown.c:444
> > > :#2 0xfffffc00004942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
> > > :#3 0xfffffc00003a1b54 in allocbuf () at ../../kern/vfs_bio.c:1791
> > >
> > > The panic message should be printing the address of the vm_page_t that
> > > it caught.
> > >
> > > From the debugger, dump that vm_page_t with 'print'.
> > >
> > > print *0xADDRESS
> > >
> > > Do about 8 print's bumping the address by 4 ( in hex ) for each.
> > >
> > > It would be even better if we could figure out the contents and type
> > > of the underlying object.
> >
> > I have full symbols:
> >
> > (gdb) fr 2
> > #2 0xfffffc00004942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
> > 1041 panic("found dirty cache page %p", m);
> > (gdb) l
> > 1036 */
> > 1037
> > 1038 if (qtype == PQ_CACHE) {
> > 1039 #if !defined(MAX_PERF)
> > 1040 if (m->dirty)
> > 1041 panic("found dirty cache page %p", m);
> > 1042
> > 1043 #endif
> > 1044 vm_page_busy(m);
> > 1045 vm_page_protect(m, VM_PROT_NONE);
> > (gdb) p m
> > $4 = (struct vm_page *) 0xfffffe0000108f40
> > (gdb) p *m
> > $5 = {pageq = {tqe_next = 0x0, tqe_prev = 0xfffffc000052ecc8}, hnext = 0x0,
> > listq = {tqe_next = 0xfffffe0000090fe0, tqe_prev = 0xfffffe00000bb6b8},
> > object = 0xfffffe00050e2a10, pindex = 12, phys_addr = 88940544, queue = 172
> ,
> > flags = 128, pc = 41, wire_count = 0, hold_count = 0, act_count = 5 '\005',
>
> > busy = 0 '\000', valid = 65535, dirty = 65535}
>
> > --
>
> Doug, Matt wanted some things from m->object too.. If it's still there
> can you grab it?
>
> printf(
> "found dirty cache page %p (%p,%d,%x) obtype %d obflags %x",
> m,
> m->object,
> (int)m->pindex,
> (int)m->flags,
> (int)m->object->type,
> (int)m->object->flags
> );
He sent me private mail asking for m->object which I replied to. Here is
*m->object:
$6 = {object_list = {tqe_next = 0xfffffe0005369870,
tqe_prev = 0xfffffe000527e0b8}, shadow_head = {tqh_first = 0x0,
tqh_last = 0xfffffe00050e2a20}, shadow_list = {tqe_next = 0x0,
tqe_prev = 0xfffffe00052d2020}, memq = {tqh_first = 0xfffffe00000c8f80,
tqh_last = 0xfffffe0000115a78}, generation = 897, type = OBJT_DEFAULT,
size = 23, ref_count = 1, shadow_count = 0, pg_color = 4,
hash_rand = -15145890, flags = 8192, paging_in_progress = 0, behavior = 0,
resident_page_count = 15, cache_count = 15, wire_count = 0,
backing_object = 0x0, backing_object_offset = 0, last_read = 0,
pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, handle = 0x0,
un_pager = {vnp = {vnp_size = 754}, devp = {devp_pglist = {
tqh_first = 0x2f2, tqh_last = 0x0}}, swp = {swp_bcount = 754}}}
>
> BTW; in vm_map.c:
> /*
> * vm_map_clean
> *
> * Push any dirty cached pages in the address range to their pager.
> * If syncio is TRUE, dirty pages are written synchronously.
> * If invalidate is TRUE, any cached pages are freed as well.
> *
> * Returns an error if any part of the specified range is not mapped.
> */
> This kinda suggests that dirty cached pages might not be all that
> unusual.. but the code in question seems to be working at a different
> level.
I'm not too familiar with this code. It is only called from msync(2) as
far as I can see.
--
Doug Rabson Mail: dfr@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
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?Pine.BSF.4.01.9901231943140.59627-100000>