Date: Wed, 10 Dec 2008 13:04:08 +0100 From: =?ISO-8859-1?Q?Beat_G=E4tzi?= <beat@chruetertee.ch> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-sparc64@freebsd.org Subject: Re: Booting of 200811 snapshot on Sun Fire V880 Message-ID: <493FB038.3080103@chruetertee.ch> In-Reply-To: <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> <20081209211900.GC15733@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl wrote: > 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... Yes and the story continues... > 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. With this image the server boots without problems but during the installer the server panics: panic: cheetah_ipi_selected: couldn't send IPI cpuid = 3 KDB: enter: panic I was not able to enter to the debugger and it wasn't possible to send a break signal and return to OBP. I tried it several times and the panic occurred at various points during the installer. Thanks, Beat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?493FB038.3080103>