[CUWiN-Dev] another debug trace

[David Young]

On Thu, Jun 30, 2005 at 06:16:53PM -0500, Bill Comisky wrote:
> 
> Same (recent) build of CUWiN.  This was right after reboot.  I exited one 
> terminal serial console session and opened another, and found myself at 
> the db> prompt. That setrootfstime() at the end looks familiar, I've seen 
> the debugger stop here before.
> 
> db> trace /u
> cpu_Debugger(4,0,c052d000,c050a000,800) at netbsd:cpu_Debugger+0x4
> comintr(c0563e00,0,c0360010,30,10) at netbsd:comintr+0xcd
> Xintr_legacy4() at netbsd:Xintr_legacy4+0xa9
> --- interrupt ---
> cpu_switch(c03145e0,0,1,0,0) at netbsd:cpu_switch+0x9f
> ltsleep(c0314420,4,c02bcca2,0,0) at netbsd:ltsleep+0x234
> uvm_scheduler(c0314400,1,c035d008,35d000,364000) at 
> netbsd:uvm_scheduler+0x76
> setrootfstime(0,0,0,0,0) at netbsd:setrootfstime
> db>

This looks ok, FSVO of "ok."  The system will keep running when you type
'continue', right?

I think I know how it gets into ddb.  The kernel drops into ddb when
you send a BREAK signal---you raise the RS-232 TD line for a few bit
(character?) times.  Sometimes, as a side-effect of attaching a serial
cable or starting a terminal program, the kernel (the hardware?) thinks
it got a BREAK, and it drops into ddb.  I am not sure if this is a
Soekris flaw, a kernel flaw, a flaw in the OS or in the terminal program.
Maybe this is what happened here.

I do not know how to find out how long the kernel has been in ddb.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933