From owner-freebsd-arm@FreeBSD.ORG Mon Jun 16 16:08:26 2014 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB6D6DAA; Mon, 16 Jun 2014 16:08:26 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C0052142; Mon, 16 Jun 2014 16:08:25 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s5GG8G8W020831; Mon, 16 Jun 2014 11:08:24 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1mgbwark0a-1; Mon, 16 Jun 2014 11:08:24 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id D3BBE50003F; Mon, 16 Jun 2014 11:08:23 -0500 (CDT) Message-ID: <539F1676.2020406@rice.edu> Date: Mon, 16 Jun 2014 11:08:22 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Hans Petter Selasky , Ian Lepore Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> <539B2BE8.2090005@rice.edu> <539E9DD4.4080001@selasky.org> In-Reply-To: <539E9DD4.4080001@selasky.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406160175 Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:08:26 -0000 On 06/16/2014 02:33, Hans Petter Selasky wrote: >> >> This output shows that according to the object's list of pages there is >> already a page allocated at pindex 4 (or "off=0x4" above). If this list >> is correct, and not itself corrupted, then we shouldn't be making a call >> to vm_page_alloc() to allocate another page at the same pindex. >> >> Whether it is this list of pages that is corrupted or not, this means >> that the object's list of pages (shown above) and its radix tree of >> pages are out of sync. >> >> I'm curious to know what mpred is when the assertion fails. That will >> tell us something about the state of the radix tree. >> >> I've also modified ddb's "show object" to provide an additional bit of >> information. However, it would be really nice if "show object" >> displayed the state of the radix tree. >> >> > > This patch makes no change. Can you please clarify? Did I not attach the new patch? The new patch changed the output of the KASSERT and ddb's "show object" so that we could get a better idea where the vm object corruption lies.