On Fri, May 07, 2004 at 11:56:26AM -0700, Andrey Petrov wrote:
> On Fri, May 07, 2004 at 10:23:11AM -0500, Peter Eisch wrote:

> > .Loading f13a  bytes of file...
> > >> NetBSD/sparc64 OpenFirmware Boot, Revision 1.6
> > >> (autobuild@tgm.netbsd.org, Tue May  4 23:53:02 UTC 2004)
> > devopen: getdisklabel sez no disk label
> > devopen: search_label sez no disk label
> > main: Calling loadfile(fd, /pci@1f,4000/scsi@3/disk@0,0:b/netbsd -d)
> > loadfile: reading header
> > elf64_exec: Booting /pci@1f,4000/scsi@3/disk@0,0:b/netbsd
> > 4969896@0x1000000+164432@0x1800000+4029872@0x1828250
> > symbols @ 0xfef58400 149+380664+226458 start=0x1000000
> > chain: calling OF_chain(800000, cbb0, 1000000, fff7fa80, 18)
> > OF_chain: prom returned!
> > Calling entry(0, 0xfff7fa80, 18, f0075a4c, f0075a4c)
> > Fast Data Access MMU Miss
> > {0} ok .trap-registers
> > %TL:1 %TT:68 %TPC:f000b168 %TnPC:f000b16c
> > %TSTATE:4400000602  %CWP:2
> >    %PSTATE:6 AG:0 IE:1 PRIV:1 AM:0 PEF:0 RED:0 MM:0 TLE:0 CLE:0 MG:0 IG:0
> >    %ASI:0  %CCR:44  XCC:nZvc   ICC:nZvc
> > 
> > %TL:2 %TT:68 %TPC:f0003048 %TnPC:f000304c
> > %TSTATE:4458041402  %CWP:2
> >    %PSTATE:414 AG:0 IE:0 PRIV:1 AM:0 PEF:1 RED:0 MM:0 TLE:0 CLE:0 MG:1 IG:0
> >    %ASI:58  %CCR:44  XCC:nZvc   ICC:nZvc

This puppy died inside the firmware.  Since it hasn't printed anything it's
difficult to tell what it was doing when it died.  Can you make sure the
kernel's compiled with DEBUG enabled?  Otherwise the -V flag will have no
effect.

Another thing you can do is the ctrace command or the <n> .window command.
One of the lower stackframes should have a pointer to the firmware's command
block in %i0 or %o0.  The first cell it points to is a pointer to the name
of the client function being called.

If I were forced to speculate, I would guess that your machine died trying
move itself around.  In order to use 4MB TLB entries to map in the kernel
text and data segments, those segments need to be on 4MB PA boundaries, and
the data also needs to be expandable enough to hold the BSS segment.  Thus,
if the kernel finds itself in the wrong location, it will try to relocate
itself.  The firmware on some machines cannot handle these operations and
die with the above problem.  That's why I made ofwboot smart enough to 
place the kernel somewhere it won't need to be relocated.

One last thing you can try is to load the kernel directly from the bootblock.

1) Enable the fcode-debug? configuration variable so the FCodes have names.

2) boot with the -DV flags.  The bootblock will load but not execute.
You will get a message saying that the program you just loaded was not
executable.  Ignore it.

3) invoke the bootblock with:

ok " /netbsd" do-boot

Or whatever your kernel's called.

Now, if you're lucky, the firmware will have loaded the kernel's symbol
table, so when you do a ctrace you'll get actual function names from the
stacktrace.

Eduardo