From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 6 18:24:54 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76FC316A422; Mon, 6 Feb 2006 18:24:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7736943D46; Mon, 6 Feb 2006 18:24:53 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7865178 for multiple; Mon, 06 Feb 2006 13:25:36 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k16IOoFt041494; Mon, 6 Feb 2006 13:24:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-sparc64@freebsd.org Date: Mon, 6 Feb 2006 13:25:10 -0500 User-Agent: KMail/1.9.1 References: <200601200105.k0K15pBe051816@www.freebsd.org> <20060204230244.Y45494@carver.gumbysoft.com> <20060205114452.N46628@mail.yashy.com> In-Reply-To: <20060205114452.N46628@mail.yashy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602061325.12260.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1278/Mon Feb 6 06:05:04 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-gnats-submit@freebsd.org, Yasholomew Yashinski Subject: Re: sparc64/92033: dc(4) issues on Ultra10 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: Mon, 06 Feb 2006 18:24:54 -0000 On Sunday 05 February 2006 11:50, Yasholomew Yashinski wrote: > On Sat, 4 Feb 2006, Doug White wrote: > >> dc0: port 0x400-0x4ff mem > >> 0x1800000-0x18000ff at device 2.0 on pci2 miibus1: on dc0 > >> dcphy0: on miibus1 > >> dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >> dc0: [GIANT-LOCKED] > >> > >> Unread portion of the kernel message buffer: > >> panic: trap: data access error > >> Uptime: 4m15s > >> Dumping 512 MB (2 chunks) > >> chunk at 0: 268435456 bytes | > > > > Can you consistently reproduce this problem? If so, it is likely a device > > driver bug. The data_access_error trap doesn't usually indicate a > > hardware issue. > > Yes. As noted below, as soon as dc0 is called upon, the kernel > cores. This happens every time dc0 is called upon. Can you figure out which instance of CSR_READ_4() or DC_CLRBIT() is triggering this panic? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org