From owner-freebsd-arm@FreeBSD.ORG Thu Jun 12 06:05:43 2014 Return-Path: Delivered-To: freebsd-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 61D39EEA; Thu, 12 Jun 2014 06:05:43 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2577F23E9; Thu, 12 Jun 2014 06:05:42 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 992721FE026; Thu, 12 Jun 2014 08:05:41 +0200 (CEST) Message-ID: <5399434D.2070008@selasky.org> Date: Thu, 12 Jun 2014 08:06:05 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: RPI-B VM panic References: <539170AA.2000109@selasky.org> <5398B50A.1070301@selasky.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm 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: Thu, 12 Jun 2014 06:05:43 -0000 On 06/11/14 22:51, Michael Tuexen wrote: > On 11 Jun 2014, at 21:59, Hans Petter Selasky wrote: > >> On 06/06/14 09:41, Hans Petter Selasky wrote: >>> Hi, >>> >>> I'm seeing this with RPI-B: >>> >>> panic: vm_page_insert_after: msucc doesn't succeed pindex >>> KDB: enter: panic >>> [ thread pid 18 tid 100052 ] >>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>> db> >>> >>> >>> Any ideas? > Which revision are you using? What is triggering the panic? I could > try to reproduce the problem. > > I've used r267055 with reverted r266083 for a couple of days and > it was running stable. It compiled a lot of ports including wireshark. > Hi, I'm running -current with a patch reverted for the CPU counter. It happens around growfs. The error is not constant. If I change the boot timing by plugging more USB devices, then I sometimes can pass the point of error. I think the problem is related to the following commit: > commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 > Author: alc > Date: Sun May 12 16:50:18 2013 +0000 > > Refactor vm_page_alloc()'s interactions with vm_reserv_alloc_page() and > vm_page_insert() so that (1) vm_radix_lookup_le() is never called while the > free page queues lock is held and (2) vm_radix_lookup_le() is called at most > once. This change reduces the average time that the free page queues lock > is held by vm_page_alloc() as well as vm_page_alloc()'s average overall > running time. > > Sponsored by: EMC / Isilon Storage Division > Looks like we are trying to grow the stack and then the pages are not in the expected order. --HPS