Date: Tue, 9 Dec 2008 22:19:00 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Beat =?unknown-8bit?Q?G=E4tzi?= <beat@chruetertee.ch> Cc: freebsd-sparc64@freebsd.org Subject: Re: Booting of 200811 snapshot on Sun Fire V880 Message-ID: <20081209211900.GC15733@alchemy.franken.de> In-Reply-To: <493E433F.5040703@chruetertee.ch> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <Qlogic ISP 10160 PCI SCSI Adapter> 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: <Qlogic ISP 10160 PCI SCSI Adapter> 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: <Sun Host-PCI bridge> 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: <OFW PCI bus> on pcib4 > pci4: <bridge> at device 2.0 (no driver attached) > hme0: <Sun HME 10/100 Ethernet> mem 0x100000-0x107fff at device 2.1 on pci4 > miibus2: <MII bus> on hme0 > ukphy1: <Generic IEEE 802.3u media interface> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081209211900.GC15733>