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