From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 31 13:18:27 2008 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8D341065673 for ; Fri, 31 Oct 2008 13:18:27 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id C9BAD8FC39 for ; Fri, 31 Oct 2008 13:18:27 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 590BD8C074; Fri, 31 Oct 2008 08:18:27 -0500 (CDT) Date: Fri, 31 Oct 2008 08:18:27 -0500 To: mdh Message-ID: <20081031131827.GA9613@soaustin.net> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <183638.12752.qm@web56802.mail.re3.yahoo.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: Mark Linimon , freebsd-sparc64@freebsd.org Subject: Re: Free Ultra2 in Silicon Valley, USA X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 13:18:28 -0000 On Fri, Oct 31, 2008 at 06:02:28AM -0700, mdh wrote: > A dual CPU Ultra2 is going to be a lot more powerful than an Ultra5. Hmm, ok, didn't know that. If no-one else claims it first, perhaps I can claim it for the build cluster and pull one of the Ultra 5s. I intend to be out in .ca.us for meetBSD. > E4500's can be relatively beefy. We could have gotten our hands on some more of them in .ca.us but the problem is who wants to pay for the power :-( Really, their time has come and gone. > OK, this is probably way over my head, but I'll bite - what exactly > happens if you don't breakpoint through it? http://people.freebsd.org/~linimon/studies/dmesgs/dmesg.netra_1_t200.txt . This appears to be some kind of race condition; my guess from fooling around with it is that some interrupt is enabled, and then fires, before the setup to handle it is finished. (Note that the same kernel runs fine on the 100s). By stepping through it, you can see it fail at different locations; without stepping through it, it is always at the same. Unfortunately my notes are at home and that machine is unreachable ATM. mcl