Hi,

on Mon, 8 May 1995 19:01:37 +0200 der Mouse wrote 
concerning "-current sparc problems" something like this:

[...]
> I actually specified -ds as boot options, recalling that someone had said
> that -d made it stop very early in DDB.  I did get a message to the
> effect that kernel was not compiled with KGDB, which was true but not
> relevant - or does -d work only if you build with KGDB as well as DDB?

-d only works with KGDB (which in turn does not work ;)), but it would be
simple to make it work with DDB, too.

> In any case, the panic proved to be "panic: boot device not known".
> This is somewhat confusing, because the disk I'm booting from does show
> up on the messages.

This is a "bug" I fixed a long time ago for me privately with a kind of a
hack. The problem is, that the kernel compares the target specified with the
boot string with the device unit number (usually counted from 0) instead of
the real scsi target id. So, one possible solution (aside from hacking
the code), would be to configure the kernel, so that your disk(s) is/are
numbered after their scsi ids

sd1	at scsibus0 target 1 drive ?

Alternatively you can boot with option -a and enter the correct disk when
promped for it.

> Problem two: when it stopped in ddb, I typed "trace" at the db> prompt.
> It printed "?(1be4, b00, 0, 0, 0, 92) at" and hung.  L1-A has no
> effect.

No idea why it hangs, but you might want to use the netbsd bootblocks,
because they load the symbol table. (Which may be what's missing and 
causing the crash. not that it's ok ... ;))

> Am I doing something stupid, or did I just pick up a broken set of
> kernel sources?  

None of those. You're almost up and running.

Bye, Rolf