Gavan Fantom wrote:
> Mark Cullen wrote:
>> It doesn't really look much like a panic to me though? Did it panic? Or
>> was it some kinda freak occurance that when the power to the serial
>> console machine suddenly went, it somehow managed to send a break and
>> made the server drop to ddb? Is there any way to tell the difference
>> between the two? Is it possible to get out of a 'dropped to ddb' state?
> 
> It does rather look like a break was received on the console. "comintr"
> in the backtrace is telling here.
> 
>> I forgot the command to get a dump from ddb (reboot / sync doesn't work
>> on this machine, it just hangs at 'Syncing disks...' forever + 1), so I
>> haven't got a kernel dump, sorry!
> 
> If you drop into ddb by accident (rather than a panic, etc), you should
> be able to just continue (type "c") rather than rebooting.
> 

That's kinda what I thought. I saw no mention of panic(), it looked 
quite strange. Thanks.

I would think that if I set ddb.fromconsole=0 and ddb.onpanic=0 that 
sending a break wouldn't drop to ddb anymore, and it will reboot 
automatically when it panics, right? I've done that now.

I'm a little concerned about the 'onpanic' one, as manually typing 
'reboot' or 'sync' at ddb just hangs (I mentioned this in another mail 
regarding RAIDFrame actually). In order for it to work I need... 'reboot 
0x104' (as in the RAIDFrame 'testing kernel dumps'. I don't know what 
the 0x104 means, but is this what a panic() will do if it's not set to 
drop to ddb?

Thanks
-- 
Mark Cullen <mark.r.cullen@gmail.com>
BSc (Hons), Computer Science