Subject: Re: --db_more-- in recent sparc64 kernel
To: None <eeh@netbsd.org>
From: john heasley <heas@shrubbery.net>
List: port-sparc64
Date: 07/11/2001 23:26:00
Wed, Jul 11, 2001 at 09:26:21PM -0000, eeh@netbsd.org:
>
> after cvs update ~7/9 (and again an hour ago), booting my ultra 2
> stops at a --db_more-- prompt
>
> Rebooting with command: boot -s
> Boot device: /sbus/SUNW,fas@e,8800000/sd@0,0 File and args: -s
> 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
> 1453372@0x1000000+88000@0x1400000+309512@0x14157c0
> symbols @ 0xfff3c300 74+147840+71699 start=0x1000000
> chain: calling OF_chain(800000, edd0, 1000000, fffb1a80, 18)
> --db_more--
>
> if i hit space here, it loops printing tabs (or is it spaces) forever.
> is there a way around this, while (i'm guessing) debugger support is
>
> That's a new one. Hm. I presume you have DDB enabled.
correct.
> 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
> 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.
> 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.
> Eduardo