Hi Helmar,

> ' 
> ' 
> ' > I SEE THE FIRST CONSOLE OUTPUT OF NETBSD-KERNEL ON FALCON  	YEP :-))
> ' > and even with a personal note to me (line with '**' below) ;-))
> ' > unless the kernel hung after one page of output 
> ' > (the position is shown below with '<<=====')
> ' Finally, we're getting somewhere!
> Hmm, my English is not so perfect, so I don't understand the sense of this
> idiom (or was it a serious sentence?) :-)
Mmmm, maybe my english isn't that good either, every dutchman would understand
this I guess. I just meant that finally we are getting some decent results :-)
> ' 
> ' I have put 2 kernels into your incoming directory:
> '  netbsd.h5:
> '      This kernels tries to automagically find out if it is running on a
> '      Falcon or TT. Try this one first. If it gives you console output,
> YEP. It is running.
That's very good, it means that I can merge some Falcon sources with the 'real'
source tree.

> '      you can skip trying netbsd.h6. I hope it runs nicely through the
> '      serial port init as I am curious to know what the SCSI code will
> '      do on a Falcon. I have been busy all week to modify it.
> YEP. Very nicely through. ;-)
Thanks, I didn't expect it to get completely through the device probing :-)
It's rather difficult writing drivers for devices you do no have.

> ' > 
> ' > So here is the whole output I got (transcribed with hand):
> ' > 
> ' lot's of transcription deleted...
> ' > fdc0 at mainbus0
> ' > fd0 at fdc0
> ' > zs0 at mainbus0<<===== h e r e the cursor stands and the kernel hung !
> Here is the next output, continued
> (also for you to see my SCSI configuration; {..} is my comment)
> 
> zs0 at mainbus0 serial 2 on channel a and modem 2 on channel b
> ncrscsi0 at mainbus0
> scsibus0 at ncrscsi0
> ncrscsi0 targ 0 lun 0: <EMULEX, MD21/52    ESDI, A00> SCSI0 0/direct fixed
> sd0 at scsibus0: 137 MB, 830 cyl, 10 head, 33 sec, 512 bytes/sec 
> ncrscsi0 targ 1 lun 0: <CDC, 94181-15, 5466> SCSI1 0/direct fixed
> sd1 at scsibus0: 582 MB, 1546 cyl, 15 head, 51 sec, 512 bytes/sec 
> ncrscsi0 targ 4 lun 0: < , , > SCSI1 1/sequential removable
> { after 1 minute of delay, so I thought kernel hung here :-) }
> st0 at scsibus0: rogue, drive empty	{ if no tape loaded }
> {OR}	"	 "      density code 0x5, 512 byte blocks, write-enabled
> {OR}	"	 "						-protected
> 					{ if tape loaded, resp. rw or ro }
> { then, after 1..2 minutes of delay, sd0-disk clicks and ..}
> panic, kernel jump to zero
Well, some more work to do this evening!

> db>
> 
> The for me only useful command I found in kernel-debugger was `trace'
> Its output follows (spare me to transcribe all of the datas and adresses ! ;)
> I give only the procedure-stack, isn't there any possibility to redirect
> any output of the kernel-debugger in a file ? For your debugging it will be
> very urgent, I think.
> 
> db> trace
> _Debugger(...)
> _panic(...)
> _rem_sicallback(...)
> _softint(...)
> _trap(...)
> _tsleep(...)
> _biowait(...)
> _bounds_check_with_label(...)
> _readdisklabel(...)
> _sdgetdisklabel(...)
> _sdopen(...)
> _setconf(...)
> _setconf(... other values ...)
> _configure(...)
> _cpu_startup(...)
> _main(...)
> Hope , this is useful for you and accellerates your trouble-shooting.
I think so, I will study it this evening. I'll spare you the work of
transcribing all the parameters :-) You cannot direct output from the
debugger to a file, this is rather difficult at this point and crash
dumps are not yet implemented :-(

Did you use the '-b' option with loadbsd? I do not understand why it
tries to access you disk if you didn't. If you didn't do it, could
you please try 'loadbsd -b netbsd', then we also know if the floppy
driver, ramdisk and the boot-filesystem will work...
As the results are now, it will probably crash when searching for a
suitable place to create your filesystems.

Bye, Leo.