From owner-freebsd-arm@FreeBSD.ORG Sat Dec 6 17:54:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0487EDD for ; Sat, 6 Dec 2014 17:54:23 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 CD82FD45 for ; Sat, 6 Dec 2014 17:54:22 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XxJYj-000GlI-6k; Sat, 06 Dec 2014 17:54:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sB6HsKSx016098; Sat, 6 Dec 2014 10:54:20 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19hhEkRM7A6IUjj+gO3C2xH X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: re: new support for Raspberry Pi B+ From: Ian Lepore To: draymond@FoxValley.net In-Reply-To: <20141202162852.w97gp1gmpkw004kw@webmail.FoxValley.net> References: <20141202162852.w97gp1gmpkw004kw@webmail.FoxValley.net> Content-Type: text/plain; charset="us-ascii" Date: Sat, 06 Dec 2014 10:54:19 -0700 Message-ID: <1417888459.1064.109.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 17:54:23 -0000 On Tue, 2014-12-02 at 16:28 -0600, draymond@FoxValley.net wrote: > > It seems that "portsnap fetch update" is a consistent way to > > generate a panic. I have now seen panics with all four of my SD > > cards on two different Raspberry Pis, and with three different > > power cables. All occurred while running at low speed for SD > > (25MHz) on r274416. > > > > ... > > > > Ian, you mentioned that you thought this looked like a memory > > corruption similar to the issues reported on Wandboard. I have been > > reading those threads but I don't fully understand what is the > > issue. Can you clarify? I also saw some discussion about some new > > changes currently under testing and planned for release. Are these > > expected to resolve the memory corruption? What is the root cause > > and is the problem present in all builds or just recent builds? > > Ian, can you comment? The current pmap code (low-level virtual memory implementation) for armv6 is less than perfect. We fixed a bunch of bugs earlier this year, but given the problems people are seeing when pushing heavy workloads on multicore systems, it appears we didn't fix all of them. I have no real evidence, just a gut feeling, that some of the problems we see on single-core systems are also related to the pmap implementation. Svata and Michal have a completely separate pmap implementation they wrote for their $work a couple years ago (before we even had armv6 support in freebsd -- they were way ahead of us). We're testing it now with the goal of replacing the current code with the new code sometime soon. While Svata and Michal have been using and testing this code for a long time, they've done it on a couple specific systems and with an older freebsd code base. Now we need wider testing. There may be a bug or two to work out in the new code, and even more likely, the new code may help expose existing bugs in other parts of arm-freebsd that we'll need to fix along the way. -- Ian