Date: Thu, 2 Jul 2009 22:44:44 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Greg Rivers <gcr+freebsd-current@tharned.org> Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Panic during shutdown (cause identified) Message-ID: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.BSF.2.00.0907020759300.1333@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> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> <alpine.BSF.2.00.0907020759300.1333@blue.tharned.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--MKQswQ7UUMqTthTa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jul 02, 2009 at 11:37:01AM -0500, Greg Rivers wrote:
> On Thu, 2 Jul 2009, Kostik Belousov wrote:
>=20
> >>>Also, please describe the load on the machine,
> >>>
> >>
> >>It happens regardless of the load. For example, just booting=20
> >>multi-user and immediately running shutdown (either by logging in or=20
> >>pressing the ACPI power button) triggers the panic.
> >No, it does not happen regardless of the load. The patch was tested on=
=20
> >the semi-standard set of programs run on the system, and all seen=20
> >accounting mistakes were fixed.
> >
>=20
> I don't know what patch you're referring to. Are you saying this issue=
=20
> was seen before and thought to have been fixed?
The issue is an indicator of the bug somewhere else, in the code that
does precise swap accounting. I committed that approximately one week
ago. The patch I am referring to is the r194766.
>=20
>=20
> >You have some process that does exhibit the behaviour causing error in=
=20
> >swap accounting. I think for start you could just show me ps auxww=20
> >output, in private, if you prefer.
> >
>=20
> I can save you the trouble of reading ps output. Based on your insight=
=20
> that the problem is with a particular process, I eliminated variables fro=
m=20
> /etc/rc.conf by trial, and have determined that it's the amd(8)=20
> automounter that's causing the panic. When I remove 'amd_enable=3D"YES"'=
,=20
> no more panic.
>=20
>=20
> >> The panic message on the console does not show the process. Can that=
=20
> >> be determined from kgdb? If so, how?
> >It does show the process, like
> >KDB: enter: panic
> >[thread pid 32021 tid 100598 ]
> >
>=20
> Yes, ordinarily such message is shown, but it is not shown for this panic=
.=20
> Also with this panic, about half the time the machine locks up hard just=
=20
> before, during, or after the core dump.
>=20
>=20
> >BTW, did you saw the kernel messages like negative vmsize for uid =3D XX=
X ?
> >
>=20
> No, there have been none of those.
>=20
>=20
> Please let me know if I can help with further testing/debugging. BTW, I=
=20
> did not customize the amd configuration; I was using the stock=20
> configuration from the base system.
The information you provided about amd(8) causing the problem was crusial.
The issue is that amd locks its pages with mlockall(2), and the code
neglected to account the wired mappings, but did not forgot to decrease
their swap share on unmapping.
Patch below fixed the issue for me.
diff --git a/sys/vm/vm_extern.h b/sys/vm/vm_extern.h
index 7bacde4..ec21a3a 100644
--- a/sys/vm/vm_extern.h
+++ b/sys/vm/vm_extern.h
@@ -55,7 +55,8 @@ vm_map_t kmem_suballoc(vm_map_t, vm_offset_t *, vm_offset=
_t *, vm_size_t,
void swapout_procs(int);
int useracc(void *, int, int);
int vm_fault(vm_map_t, vm_offset_t, vm_prot_t, int);
-void vm_fault_copy_entry(vm_map_t, vm_map_t, vm_map_entry_t, vm_map_entry_=
t);
+void vm_fault_copy_entry(vm_map_t, vm_map_t, vm_map_entry_t, vm_map_entry_=
t,
+ vm_ooffset_t *);
void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t);
int vm_fault_wire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t, boolean_t=
);
int vm_forkproc(struct thread *, struct proc *, struct thread *, struct vm=
space *, int);
diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c
index 43743f4..579cf49 100644
--- a/sys/vm/vm_fault.c
+++ b/sys/vm/vm_fault.c
@@ -1126,11 +1126,9 @@ vm_fault_unwire(vm_map_t map, vm_offset_t start, vm_=
offset_t end,
* entry corresponding to a main map entry that is wired down).
*/
void
-vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry)
- vm_map_t dst_map;
- vm_map_t src_map;
- vm_map_entry_t dst_entry;
- vm_map_entry_t src_entry;
+vm_fault_copy_entry(vm_map_t dst_map, vm_map_t src_map,
+ vm_map_entry_t dst_entry, vm_map_entry_t src_entry,
+ vm_ooffset_t *fork_charge)
{
vm_object_t backing_object, dst_object, object;
vm_object_t src_object;
@@ -1163,10 +1161,12 @@ vm_fault_copy_entry(dst_map, src_map, dst_entry, sr=
c_entry)
VM_OBJECT_LOCK(dst_object);
dst_entry->object.vm_object =3D dst_object;
dst_entry->offset =3D 0;
- if (dst_entry->uip !=3D NULL) {
- dst_object->uip =3D dst_entry->uip;
+ if (fork_charge !=3D NULL) {
+ dst_object->uip =3D curthread->td_ucred->cr_ruidinfo;
+ uihold(dst_object->uip);
dst_object->charge =3D dst_entry->end - dst_entry->start;
dst_entry->uip =3D NULL;
+ *fork_charge +=3D dst_entry->end - dst_entry->start;
}
prot =3D dst_entry->max_protection;
=20
diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
index 82d37e6..ea6f713 100644
--- a/sys/vm/vm_map.c
+++ b/sys/vm/vm_map.c
@@ -2909,7 +2909,8 @@ vm_map_copy_entry(
* Cause wired pages to be copied into the new map by
* simulating faults (the new pages are pageable)
*/
- vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry);
+ vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry,
+ fork_charge);
}
}
=20
--MKQswQ7UUMqTthTa
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkpNDiwACgkQC3+MBN1Mb4gsYACgm0KZ2+Qt9cl/wiSMLAEAgVCv
oQwAnAxa2Rtg6Hra04ujYLl5xm/sl0Td
=aJMH
-----END PGP SIGNATURE-----
--MKQswQ7UUMqTthTa--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090702194444.GK2884>