From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 08:41:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D6D106564A for ; Thu, 2 Jul 2009 08:41:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1698FC13 for ; Thu, 2 Jul 2009 08:41:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n628fnfG012973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 11:41:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n628fnsB080659; Thu, 2 Jul 2009 11:41:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n628fn41080658; Thu, 2 Jul 2009 11:41:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Jul 2009 11:41:49 +0300 From: Kostik Belousov To: Greg Rivers Message-ID: <20090702084149.GE2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="307FGJNKNK2k8fNP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Panic during shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:41:55 -0000 --307FGJNKNK2k8fNP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 01, 2009 at 06:54:22PM -0500, Greg Rivers wrote: > On Wed, 1 Jul 2009, Kostik Belousov wrote: >=20 > >> at /usr/src/sys/vm/vm_object.c:715 > >>#6 0xc064d24c in vm_object_deallocate (object=3D0xc4300000) > >> at /usr/src/sys/vm/vm_object.c:592 > >I am interested in the output of > >p *object > >from the frame 6, and the output of > >p swap_total > >p swap_reserved > >all from kgdb. > > >=20 > ... > (kgdb) frame 6 > #6 0xc064d24c in vm_object_deallocate (object=3D0xc4300000) > at /usr/src/sys/vm/vm_object.c:592 > 592 vm_object_terminate(object); > (kgdb) list > 587 * Don't double-terminate, we could be in a=20 > termination > 588 * recursion due to the terminate having to sync= =20 > data > 589 * to disk. > 590 */ > 591 if ((object->flags & OBJ_DEAD) =3D=3D 0) > 592 vm_object_terminate(object); > 593 else > 594 VM_OBJECT_UNLOCK(object); > 595 object =3D temp; > 596 } > (kgdb) p *object > $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xc06ce176 "vm object", > lo_flags =3D 21168128, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock= =3D 4}, > object_list =3D {tqe_next =3D 0xc43217f8, tqe_prev =3D 0xc41b1454}, sha= dow_head=20 > =3D { > lh_first =3D 0x0}, shadow_list =3D {le_next =3D 0x0, le_prev =3D 0xc4= 15c5f4}, > memq =3D {tqh_first =3D 0x0, tqh_last =3D 0xc4300028}, root =3D 0x0, si= ze =3D 245, > generation =3D 271, ref_count =3D 0, shadow_count =3D 0, type =3D 0 '\0= ', > flags =3D 12552, pg_color =3D 250, paging_in_progress =3D 0, > resident_page_count =3D 0, backing_object =3D 0x0, backing_object_offse= t =3D 0, > pager_object_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, rvq =3D { > lh_first =3D 0x0}, cache =3D 0x0, handle =3D 0x0, un_pager =3D {vnp = =3D { > vnp_size =3D 0}, devp =3D {devp_pglist =3D {tqh_first =3D 0x0, tqh_= last =3D=20 > 0x0}}, > swp =3D {swp_bcount =3D 0}}, uip =3D 0xc3d10340, charge =3D 1003520} > (kgdb) p swap_total > $2 =3D 2147483648 > (kgdb) p swap_reserved > $3 =3D 634880 >=20 >=20 > >Also, please describe the load on the machine, > > >=20 > It happens regardless of the load. For example, just booting multi-user= =20 > and immediately running shutdown (either by logging in or pressing the=20 > ACPI power button) triggers the panic. No, it does not happen regardless of the load. The patch was tested on the semi-standard set of programs run on the system, and all seen accounting mistakes were fixed. You have some process that does exhibit the behaviour causing error in swap accounting. I think for start you could just show me ps auxww output, in private, if you prefer. >=20 >=20 > >... and look up what process exited when the panic happens. > > >=20 > The panic message on the console does not show the process. Can that be= =20 > determined from kgdb? If so, how? It does show the process, like KDB: enter: panic [thread pid 32021 tid 100598 ] there, you can look up pid/tid and then do ps in ddb to look at the process= es. Also, you may do "show allpcpu" in ddb. In kgdb, info threads should do the trick, AFAIR. BTW, did you saw the kernel messages like negative vmsize for uid =3D XXX ? --307FGJNKNK2k8fNP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpMcs0ACgkQC3+MBN1Mb4g7JQCgvjHd1tzpGSA5OL+ygyrYw4sA JwoAniNYUB1K6jVVLtMyrTpJ5idCQtyM =RsfX -----END PGP SIGNATURE----- --307FGJNKNK2k8fNP--