Subject: Re: E450 installation problems
To: jml <jml@ha.cx>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: port-sparc64
Date: 06/14/2004 23:43:01
On Sat, Jun 12, 2004 at 01:28:49PM -0500, jml wrote:
> Hi,
> 
> I recently acquired an E450.  I did some reading before trying to install
> NetBSD on the machine and saw Peter Eisch's problem.  He was kind enough
> to share an install ISO with me that had the fix.  Unfortunately, the
> machine never gets to sysinst.  It freezes with:
> 
> Kernelized RAIDframe activated
> md0: internal 5120 KB image area
> scsibus0: waiting 2 seconds for devices to settle...
> scsibus1: waiting 2 seconds for devices to settle...
> probe(esiop0:0:0:0): command timeout, CDB: 0x12 00 00 00 24 00

Looks like an interrupt problem. Interrupts don't get delivered to
the driver.

> 
> Any tips/advice on how to go about debugging this?
> 
> 
> NetBSD IEEE 1275 Bootblock
> ..>> NetBSD/sparc64 OpenFirmware Boot, Revision 1.7
> >> (peter@zipper, Sun Jun  6 09:57:17 CDT 2004)
> devopen: getdisklabel sez no disk label
> devopen: search_label sez no disk label
> loadfile: reading header
> elf64_exec: Booting /pci@1f,4000/scsi@2/disk@6,0:f/netbsd
> 4862936@0x1000000+5401616@0x1800000+2986992@0x1d26c10 
> symbols @ 0xfefe0340 132 start=0x1000000
> chain: calling OF_chain(800000, cbb8, 1000000, fff7fa80, 18)
> prom_get_msgbuf: Cannot recover msgbuf on E250
> prom_get_msgbuf: allocated new buf at 00000000
> prom_get_msgbuf: claiming new buf at 00000000
> Kernel size exceeds 4MB
> console is /pci@1f,4000/ebus@1/se@14,400000:a
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
>     The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>     The Regents of the University of California.  All rights reserved.
> 
> NetBSD 2.0F (INSTALL) #0: Sun Jun  6 11:33:31 CDT 2004
>         peter@zipper:/usr/peter/sparc64/obj/usr/src/sys/arch/sparc64/compile/INSTALL
> total memory = 2048 MB
> avail memory = 1990 MB
> bootpath: /pci@1f,4000/scsi@2,0/disk@6,0:f
> mainbus0 (root): SUNW,Ultra-4: hostid 80b64da3
> cpu0 at mainbus0: SUNW,UltraSPARC-II @ 400 MHz, version 0 FPU
> cpu0: 32K instruction (32 b/l), 16K data (32 b/l), 4096K external (64 b/l)
> cpu at mainbus0 not configured
> psycho0 at mainbus0 addr 0xfffb4000
> SUNW,psycho: impl 0, version 4: ign 7c0 bus range 0 to 0; PCI bus 0
> DVMA map: fe000000 to ffffe000
> IOTSB: 329e000 to 32a6000
> pci0 at psycho0
> pci0: i/o space, memory space enabled
> ebus0 at pci0 dev 1 function 0
> ebus0: Sun Microsystems, Inc. PCIO Ebus2, revision 0x01
> auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 72c000-72c003, 72f000-72f003
> power at ebus0 addr 724000-724003 ipl 2021 ipl 2034 not configured
> SUNW,pll at ebus0 addr 504000-504002 not configured
> sc at ebus0 addr 500000-500007 not configured
> sab0 at ebus0 addr 400000-40007f ipl 43: rev 3.2
> sabtty0 at sab0 port : console i/o
> sabtty1 at sab0 port 1
> com0 at ebus0 addr 3083f8-3083ff ipl 41: ns16550a, working fifo
> kbd0 at com0
> com1 at ebus0 addr 3062f8-3062ff ipl 42: ns16550a, working fifo
> ms0 at com1
> lpt0 at ebus0 addr 3043bc-3043cb, 300398-300399, 700000-70000f ipl 2018
> fdthree at ebus0 addr 3023f0-3023f7, 706000-70600f, 720000-720003 ipl 2023 not configured
> clock0 at ebus0 addr 0-1fff: mk48t59
> flashprom at ebus0 addr 0-fffff, 0-fffff not configured
> SUNW,envctrl at ebus0 addr 600000-600003 ipl 2024 ipl 2021 not configured
> hme0 at pci0 dev 1 function 1: Sun Happy Meal Ethernet, rev. 1
> hme0: interrupting at ivec 37e1
> hme0: Ethernet address 08:00:20:b6:4d:a3
> nsphy0 at hme0 phy 1: DP83840 10/100 media interface, rev. 1
> 0nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> esiop0 at pci0 dev 3 function 0: Symbios Logic 53c875 (ultra-wide scsi)
> esiop0: using on-board RAM
> esiop0: interrupting at ivec 7e0
> scsibus0 at esiop0: 16 targets, 8 luns per target
> esiop1 at pci0 dev 2 function 0: Symbios Logic 53c875 (ultra-wide scsi)
> esiop1: using on-board RAM
> esiop1: interrupting at ivec 7e6

I wonder if the interrupt vector should be 37e0/37e6 here, but it's just a
guess based on the other values. I know noting about how the interrupt routing
is done on this hardware.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--