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