Subject: Re: --db_more-- in recent sparc64 kernel
To: None <eeh@netbsd.org, heas@shrubbery.net>
From: None <eeh@netbsd.org>
List: port-sparc64
Date: 07/12/2001 17:45:55
> What happens if you type `q'?
back to the prom
chain: calling OF_chain(800000, edd0, 1000000, fffb1a80, 18)
Fast Data Access MMU Miss
{0} ok
O.K. When you get this you should type `.trap-registers' and record
the TT and TPC values. The TPC values then need to be correlated with
your kernel image to find out what source line caused the fault.
`ctrace' may also be useful.
> What's probably happening is that there is a call to db_printf()
> with a corrupt string. db_printf() will attempt to print it and
> generates a `--db_more--' when it thinks you're at the end of the
> page. It would be useful to know how you got there.
>
> Is your kernel DEBUG or not? If not, try compiling with DEBUG to
> get some more boot diagnostics.
i removed the kernel build directory and built another from scratch.
when i booted this kernel, it did not prompt and just went into the
continuous spaces loop.
Boot device: disk File and args:
NetBSD IEEE 1275 Bootblock
..>> NetBSD/sparc64 OpenFirmware Boot, Revision 1.3
>> (root@foad, Mon Jul 9 20:11:51 UTC 2001)
loadfile: reading header
elf64_exec: Booting /sbus@1f,0/SUNW,fas@e,8800000/sd@0,0:a/netbsd
1453419@0x1000000+88000@0x1400000+309512@0x14157c0
symbols @ 0xfff3c300 74+147840+71699 start=0x1000000
chain: calling OF_chain(800000, edd0, 1000000, fffb1a80, 18)
sending a break here dumps back to the prom. suggestions?
oddly, i built a kernel on my other ultra2 with the same config file
and cvs update from yesterday and it boots fine. this box is exactly
the same h/w and s/w wise, apart from 1G vs 256M ram and the compiler,
which is the one from ~january while the other is the dwarf toolchain.
I have been noticing this sort of flakyness recently. Building
a kernel with one set of options works, and another set of options
fails. I have to attribute that to some sort of toolchain flakyness.
> being worked on? tia.
>
> No, the debugger should work. But it appears you're not getting
> far enough for the debugger to initialize.
kgdb too? last i checked, i read that kgdb did not work.
kgdb has never worked and there is no effort being made to make it work.
Eduardo