From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 19:44:51 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 5CBCF1065677; Thu, 2 Jul 2009 19:44:51 +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 9D85E8FC27; Thu, 2 Jul 2009 19:44:50 +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 n62JijV5061275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 22:44:46 +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 n62JijvK028671; Thu, 2 Jul 2009 22:44:45 +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 n62JijKr028670; Thu, 2 Jul 2009 22:44:45 +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 22:44:44 +0300 From: Kostik Belousov To: Greg Rivers Message-ID: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MKQswQ7UUMqTthTa" 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: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Panic during shutdown (cause identified) 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 19:44:51 -0000 --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--