From owner-freebsd-current  Tue Jul  6  3:46:20 1999
Delivered-To: freebsd-current@freebsd.org
Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66])
	by hub.freebsd.org (Postfix) with ESMTP id A923514BCC
	for <freebsd-current@freebsd.org>; Tue,  6 Jul 1999 03:46:14 -0700 (PDT)
	(envelope-from syssgm@detir.qld.gov.au)
Received: by ren.detir.qld.gov.au; id UAA14415; Tue, 6 Jul 1999 20:45:21 +1000 (EST)
Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2)
	id xma014401; Tue, 6 Jul 99 20:44:56 +1000
Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9])
	by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA21767
	for <freebsd-current@freebsd.org>; Tue, 6 Jul 1999 20:44:24 +1000 (EST)
Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10])
	by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA23345
	for <freebsd-current@freebsd.org>; Tue, 6 Jul 1999 20:44:20 +1000 (EST)
Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1])
	by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA14043;
	Tue, 6 Jul 1999 20:44:20 +1000 (EST)
	(envelope-from syssgm@nymph.detir.qld.gov.au)
Message-Id: <199907061044.UAA14043@nymph.detir.qld.gov.au>
To: freebsd-current@freebsd.org
Cc: syssgm@detir.qld.gov.au
Subject: Re: Stuck in "objtrm" 
References: <199907021200.WAA06282@nymph.detir.qld.gov.au> <199907060745.RAA12161@nymph.detir.qld.gov.au>
In-Reply-To: <199907060745.RAA12161@nymph.detir.qld.gov.au>
    from Stephen McKay at "Tue, 06 Jul 1999 17:45:11 +1000"
Date: Tue, 06 Jul 1999 20:44:19 +1000
From: Stephen McKay <syssgm@detir.qld.gov.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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