Date: Thu, 12 Jun 2014 20:44:03 +0200 From: Michael Tuexen <tuexen@freebsd.org> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPI-B VM panic Message-ID: <AA73660C-72CA-4AB0-BACF-DF77728F3162@freebsd.org> In-Reply-To: <5399434D.2070008@selasky.org> References: <539170AA.2000109@selasky.org> <5398B50A.1070301@selasky.org> <AA183785-AC40-4A48-BFB2-5A6B1368ECB5@freebsd.org> <5399434D.2070008@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jun 2014, at 08:06, Hans Petter Selasky <hps@selasky.org> wrote: > On 06/11/14 22:51, Michael Tuexen wrote: >> On 11 Jun 2014, at 21:59, Hans Petter Selasky <hps@selasky.org> = wrote: >>=20 >>> On 06/06/14 09:41, Hans Petter Selasky wrote: >>>> Hi, >>>>=20 >>>> I'm seeing this with RPI-B: >>>>=20 >>>> 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> >>>>=20 >>>>=20 >>>> Any ideas? >> Which revision are you using? What is triggering the panic? I could >> try to reproduce the problem. >>=20 >> 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. >>=20 >=20 > Hi, >=20 > 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 I haven't it experienced. I normally grow the filesystem from 1 GB to 16 = GB after installation and I have not connected any USP device. I'm normally = booting it using a serial cable, no monitor, no keyboard, no mouse attached. Best regards Michael > the point of error. I think the problem is related to the following = commit: >=20 >> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21 >> Author: alc <alc@FreeBSD.org> >> Date: Sun May 12 16:50:18 2013 +0000 >>=20 >> 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. >>=20 >> Sponsored by: EMC / Isilon Storage Division >>=20 >=20 > Looks like we are trying to grow the stack and then the pages are not = in the expected order. >=20 > --HPS >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA73660C-72CA-4AB0-BACF-DF77728F3162>