From owner-freebsd-ppc@FreeBSD.ORG Wed Dec 20 19:32:00 2006 Return-Path: X-Original-To: freebsd-ppc@freebsd.org Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F74816A47C for ; Wed, 20 Dec 2006 19:32:00 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6504F43CA0 for ; Wed, 20 Dec 2006 19:31:57 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [192.168.0.13] (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id CKN17244 (AUTH peterg@ptree32.com.au); Thu, 21 Dec 2006 05:31:51 +1000 (EST) Message-ID: <45898F1F.402@freebsd.org> Date: Wed, 20 Dec 2006 11:29:35 -0800 From: Peter Grehan User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Andrew Turner References: <20061218104841.72ba51ea@hermies.int.fubar.geek.nz> <4585CCC1.7050005@freebsd.org> <20061218222327.308dca53@hermies.int.fubar.geek.nz> <4586CA29.10803@freebsd.org> <20061219113230.34182787@hermies.int.fubar.geek.nz> <4587316C.1070500@freebsd.org> <20061220192614.04c53dbf@hermies.int.fubar.geek.nz> In-Reply-To: <20061220192614.04c53dbf@hermies.int.fubar.geek.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: FreeBSD on an Efika X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 19:32:00 -0000 Hi Andrew, >> As you can see in , the existing vector definition >> don't match these, or are incorrect for the G2 core. > There is EXC_IMISS, EXC_DLMISS and EXC_DSMISS. Better get my brain in gear, I saw EXC_DTMISS and punted. > The attached patch adds the NetBSD handlers. There is a bug in the > patch where I can read data once but on the next read or write the > kernel crashes. I'll have a look at this today. Debugging could be difficult. When you get the crash, is there a panic backtrace ? The SRR* registers should be printed if that is the case. later, Peter.