Ok, here's the situation.

We're having new heating fitted, and our brand new(!!!) boiler quit 
working after all of 2 hours of being fitted. So, we've got an 
electrician over today. I knew this was happening, so I plugged in the 
other end of the serial cable in advance, "just in case". For those who 
don't know, this machine refuses to boot unless the other end of the 
serial console is plugged in and I haven't managed to find out why yet :(

It was quite hard thinking of what could possibly go wrong, because, 
well, the machine is on an UPS... so really nothing *should* have gone 
terribly wrong. Of course, computers being computers things went wrong.

The electrician didn't warn anyone when he was going to cut the power, 
so all the computers just went off when he did, including the one that 
the serial cable was plugged in to. Not to worry, I thought, the UPS is 
working and the server is still on, I just have to wait for the power to 
come back. Much to my surprise, when the power came back I found that 
none of the Windows machines could log on to the server. I checked the 
switch to find that the servers activity light was constantly blinking, 
even after unplugging everything else, so there couldn't possibly be any 
activity for it to be blinking at. I check what's happened over the 
serial console, only to find it's sitting at a db> prompt! That, I 
wasn't expecting.

db> bt
cpu_Debugger(246,c05cfe6c,c05cfe40,206,c0daffc0) at 
netbsd:cpu_Debugger+0x4 

comintr(c0de8e00,0,59b30010,30,3bbd0010) at netbsd:comintr+0x692 

Xintr_legacy4() at netbsd:Xintr_legacy4+0xa9 

--- interrupt ---
cpu_switch(c0545340,0,0,282,c0dc0d80) at netbsd:cpu_switch+0x9f 

ltsleep(c0545180,4,c04978ca,0,0) at netbsd:ltsleep+0x33f 

uvm_scheduler(c0545160,0,c05496fc,c0482705,0) at 
netbsd:uvm_scheduler+0x74 

main(0,0,0,0,0) at netbsd:main+0x682

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 appears that unless you set DDB_ONPANIC=0 in the kernel config, the 
default is 1. I thought it was 0, so... ddb.onpanic was 1 and 
ddb.fromconsole was 1 aswell. So it could have been either really I guess.

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!
-- 
Mark Cullen <mark.r.cullen@gmail.com>
BSc (Hons), Computer Science