Date: Tue, 06 Jul 1999 03:56:07 -0700 From: David Greenman <dg@root.com> To: Stephen McKay <syssgm@detir.qld.gov.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" Message-ID: <199907061056.DAA11064@implode.root.com> In-Reply-To: Your message of "Tue, 06 Jul 1999 20:44:19 %2B1000." <199907061044.UAA14043@nymph.detir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
You'll want to look primarily in the swap_pager code since it messes with that (at least it used to - I don't recall what Matt's new code does with it). There should be various calls to vm_object_pip_* that manipulate the paging_in_progress number. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com >On Tuesday, 6th July 1999, Stephen McKay wrote: > >>the make world hangs with cc1 in "objtrm"... > >I'm having a fun old conversation with myself here! ;-) > >Here's some concrete info: > >(kgdb) p/x *(struct vm_object*) 0xc32ea21c >$13 = {object_list = {tqe_next = 0xc3389e58, tqe_prev = 0xc323fdec}, > shadow_head = {tqh_first = 0x0, tqh_last = 0xc32ea224}, shadow_list = { > tqe_next = 0xc327b8dc, tqe_prev = 0xc32cb734}, memq = { > tqh_first = 0xc0308e80, tqh_last = 0xc03046ec}, generation = 0x3004, > type = 0x1, size = 0x2a7, ref_count = 0x0, shadow_count = 0x0, > pg_color = 0x5, hash_rand = 0xfd9a69d7, flags = 0x21c8, > paging_in_progress = 0x1, behavior = 0x0, resident_page_count = 0x9, > backing_object = 0x0, backing_object_offset = 0x0, last_read = 0x14, > pager_object_list = {tqe_next = 0xc323c438, tqe_prev = 0xc323a424}, > handle = 0x0, un_pager = {vnp = {vnp_size = 0x16}, devp = {devp_pglist = { > tqh_first = 0x16, tqh_last = 0x0}}, swp = {swp_bcount = 0x16}}} > >The high points: > ref_count=0 > shadow_count=0 > type=1 (OBJT_SWAP) > paging_in_progress=1 > resident_page_count=9 > flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead) > >A typical memory page from this object: > >(kgdb) p/x *(struct vm_page*) 0xc02ffd90 >$14 = {pageq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f1960}, hnext = 0x0, > listq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f196c}, object = 0xc32ea21c, > pindex = 0x2f, phys_addr = 0x4f4000, queue = 0x41, flags = 0x0, pc = 0x34, > wire_count = 0x0, hold_count = 0x0, act_count = 0x8, busy = 0x0, > valid = 0xff, dirty = 0xff} > >The high points: > queue=inactive > flags=0 > wire_count=0 > hold_count=0 > busy=0 > valid=ff > dirty=ff > >All 9 of them are like that. So, no busy or PG_BUSY or anything. No paging >really in progress after all. So the object's paging_in_progress count is >out. > >Who was watching what code changed recently? Remember I had this problem >on a kernel from 1999/06/16 too. So it's an "old" problem. > >Off to research the next installment... > >Stephen. > >PS I haven't worked out yet how to find the stack of the errant process. >Any hints? The stack trace should be helpful. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message 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?199907061056.DAA11064>