From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 21 18:58:16 2009 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 942D71065675 for ; Tue, 21 Apr 2009 18:58:16 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2713D8FC22 for ; Tue, 21 Apr 2009 18:58:15 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n3LIwE2N036757; Tue, 21 Apr 2009 20:58:14 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n3LIwEFe036756; Tue, 21 Apr 2009 20:58:14 +0200 (CEST) (envelope-from marius) Date: Tue, 21 Apr 2009 20:58:14 +0200 From: Marius Strobl To: Florian Smeets Message-ID: <20090421185814.GA33994@alchemy.franken.de> References: <20090325114426.GA74306@alchemy.franken.de> <49CA1BF1.6090507@kasimir.com> <20090420183620.GA25251@alchemy.franken.de> <49ED0917.10402@kasimir.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49ED0917.10402@kasimir.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: US-III crashes on current 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: Tue, 21 Apr 2009 18:58:17 -0000 On Tue, Apr 21, 2009 at 01:45:27AM +0200, Florian Smeets wrote: > On 20.04.09 20:36, Marius Strobl wrote: > >On Wed, Mar 25, 2009 at 12:56:33PM +0100, Florian Smeets wrote: > >>On 25.03.2009 12:44 Uhr, Marius Strobl wrote: > >>>On Sun, Mar 22, 2009 at 07:30:28PM -0500, zenxyzzy wrote: > >>> > >>>>2) halt consistently panic's the machine. quite benign, if you think > >>>>about it: > >>>> > >>>>panic: trap: fast data access mmu miss > >>>>cpuid = 0 > >>>>KDB: enter: panic > >>>>[thread pid 1402 tid 100148 ] > >>>>Stopped at kdb_enter+0x80: ta %xcc, 1 > >>>>db> where > >>>>Tracing pid 1402 tid 100148 td 0xfffff8000448a700 > >>>>panic() at panic+0x20c > >>>>trap() at trap+0x4d0 > >>>>-- fast data access mmu miss tar=0x14543da000 %o7=0xc034c96c -- > >>>>callout_lock() at callout_lock+0x40 > >>>>untimeout() at untimeout+0xc > >>>>isp_done() at isp_done+0x140 > >>>>isp_intr() at isp_intr+0x3eb8 > >>>>isp_poll() at isp_poll+0x38 > >>>>xpt_polled_action() at xpt_polled_action+0xc8 > >>>>dashutdown() at dashutdown+0x16c > >>>>boot() at boot+0x858 > >>>>reboot() at reboot+0x64 > >>>>syscall() at syscall+0x2e8 > >>>>-- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 -- > >>>>userland() at 0x4056af08 > >>>>user trace: trap %o7=0x1013e4 > >>>>pc 0x4056af08, sp 0x7fdffffe261 > >>>>pc 0x100df0, sp 0x7fdffffe321 > >>>>pc 0x402066f4, sp 0x7fdffffe3e1 > >>> > >>>IIRC, this was recently already (correctly) reported to scsi@. > >>>At least I for one didn't have time to investigate this so far > >>>though. > >>> > >> > >>I can offer console access to a machine which has this problem to any > >>developer interested. > >> > > > >Are you still seeing this on current CURRENT? Unfortunately > >I'm not able to reproduce it here. Recently there was some > >rototilling in sub-system startup and I think also shutdown > >which caused some fallout but which might have been fixed > >again. > > > > Yes, i can still reproduce this on every shutdown. Tried with r191337. > Trace is still the same. > Could you please run gdb(1) on the corresponding kernel.debug and report the output of the following commands? l *(0xc034c96c) l *(callout_lock+0x40) Change as needed if the addresses differ from the above backtrace. Hrm, the one you reported to scsi@ actually is a bit different: > -- fast data access mmu miss tar=0x1454156000 %o7=0xc040e7a4 -- > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x5c > callout_lock() at callout_lock+0x50 In that case please additionally get the output of l *(_mtx_lock_spin_flags+0x5c) Marius