Date: Thu, 2 Jul 2009 11:41:49 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Greg Rivers <gcr+freebsd-current@tharned.org> Cc: freebsd-current@freebsd.org Subject: Re: Panic during shutdown Message-ID: <20090702084149.GE2884@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.BSF.2.00.0907011812490.1649@blue.tharned.org> References: <alpine.BSF.2.00.0907011139490.75481@roadkill.tharned.org> <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <alpine.BSF.2.00.0907011812490.1649@blue.tharned.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090702084149.GE2884>