From owner-freebsd-sparc64@FreeBSD.ORG Tue Dec 9 21:19:05 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 AAD401065670 for ; Tue, 9 Dec 2008 21:19:05 +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 476C98FC08 for ; Tue, 9 Dec 2008 21:19:05 +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 mB9LJ01b021378; Tue, 9 Dec 2008 22:19:00 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id mB9LJ0c0021377; Tue, 9 Dec 2008 22:19:00 +0100 (CET) (envelope-from marius) Date: Tue, 9 Dec 2008 22:19:00 +0100 From: Marius Strobl To: Beat =?unknown-8bit?Q?G=E4tzi?= Message-ID: <20081209211900.GC15733@alchemy.franken.de> References: <4935839E.4010000@chruetertee.ch> <20081204180726.GA19048@alchemy.franken.de> <26f6c7210812050014l5dac2871k7ca1db1677d0b7d0@mail.gmail.com> <20081205172112.GA52382@alchemy.franken.de> <26f6c7210812080259j1cc1cb3bo2fe827a8442f068a@mail.gmail.com> <20081209081300.GK52382@alchemy.franken.de> <493E433F.5040703@chruetertee.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <493E433F.5040703@chruetertee.ch> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Booting of 200811 snapshot on Sun Fire V880 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, 09 Dec 2008 21:19:05 -0000 On Tue, Dec 09, 2008 at 11:06:55AM +0100, Beat Gtzi wrote: > > The new image fixes the data access error but it seems that I run into > another bug: > > isp1: port 0x1000-0x10ff mem > 0x2000000-0x2000fff at device 4.0 on pci3 > pcib2: WARNING: using devices behind PCI-PCI bridges may cause data > corruptionisp1: [ITHREAD] > isp1: Board Type 10160, Chip Revision 0x6, loaded F/W Revision 10.4.41 > isp1: invalid NVRAM header > isp2: port 0x1100-0x11ff mem > 0x2002000-0x2002fff at device 5.0 on pci3 > pcib2: WARNING: using devices behind PCI-PCI bridges may cause data > corruptionisp2: [ITHREAD] > isp2: Board Type 10160, Chip Revision 0x6, loaded F/W Revision 10.4.41 > isp2: invalid NVRAM header > pcib4: mem > 0x40004e00000-0x40004e17fff,0x40004c10000-0x40004c1004f,0x7ffe8000000-0x7ffe80000ff > irq > 626,624,625,628,630 on nexus0 > pcib4: Schizo, version 4, IGN 0x9, bus A, 33MHz > Timecounter "pcib4" frequency 150000000 Hz quality 100 > pcib4: DVMA map: 0xc0000000 to 0xffffffff > pcib4: [FILTER] > pcib4: [FILTER] > pcib4: [FILTER] > pcib4: [FILTER] > pci4: on pcib4 > pci4: at device 2.0 (no driver attached) > hme0: mem 0x100000-0x107fff at device 2.1 on pci4 > miibus2: on hme0 > ukphy1: PHY 1 on miibus2 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > hme0: Ethernet address: 00:03:ba:xx:xx:xx > pcib4: invalid interrupt vector 0x245 > hme0: couldn't establish interrupt > panic: trap: fast data access mmu miss > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x80: ta %xcc, 1 > db> bt > Tracing pid 0 tid 100000 td 0xc0848780 > panic() at panic+0x20c > trap() at trap+0x570 > -- fast data access mmu miss tar=0 %o7=0xc0328a48 -- > _rw_rlock() at _rw_rlock+0x170 > in_pcbpurgeif0() at in_pcbpurgeif0+0x24 > in_ifdetach() at in_ifdetach+0x1c > if_detach() at if_detach+0x180 > ether_ifdetach() at ether_ifdetach+0x58 > hme_detach() at hme_detach+0x64 > hme_pci_attach() at hme_pci_attach+0x388 > device_attach() at device_attach+0x4a4 > device_probe_and_attach() at device_probe_and_attach+0x64 > bus_generic_attach() at bus_generic_attach+0x10 > ofw_pcibus_attach() at ofw_pcibus_attach+0x72c > device_attach() at device_attach+0x4a4 > device_probe_and_attach() at device_probe_and_attach+0x64 > bus_generic_attach() at bus_generic_attach+0x10 > schizo_attach() at schizo_attach+0x13b8 > device_attach() at device_attach+0x4a4 > device_probe_and_attach() at device_probe_and_attach+0x64 > bus_generic_attach() at bus_generic_attach+0x10 > nexus_attach() at nexus_attach+0x4fc > device_attach() at device_attach+0x4a4 > device_probe_and_attach() at device_probe_and_attach+0x64 > root_bus_configure() at root_bus_configure+0x28 > configure() at configure+0x4 > mi_startup() at mi_startup+0x18c > btext() at btext+0x30 > db> > You have some real luck with this machine... The problem causing the panic seems to be a bug in the network stack which I don't have a clue about, which is triggered by hme(4) immediatley detaching again as it can't setup the interrupt due to what appears to be a firmware bug. Could you please try: http://people.freebsd.org/~marius/8.0-20081209-SNAP-sparc64-disc1.iso.gz which tries to work around the latter bug. Given that this involves some guesswork and I can't tell for sure it's a firmware bug without an OFW device tree dump (if there's still a working Solaris installation on that machine could you please provide the output of `prtconf -Ppv`?) I'm unsure whtether this will actually solve it. Marius