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 [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
