> Have you checked to make sure the console port isn't in "secure" mode?
> If it *is* secured, it may be ignoring your break.  My next guess would
> be wild - something along the lines of the terminal server doesn't
> send a Break unless modem control is enabled....

Okay, so I can't figure out how to check that! :)

At the moment terminal server or straight cable to the back a break signal
does absolutely nothing but print high ascii chars on the screen.  I can't
get to a debugger (booting with boot_osflags d) nor back to the P00>>> 
monitor.  Once the system is running.

Do you have any ideas? :)
 
> Re: Break vs ^P for VAXen - it all depends on the model.  Most if not
> all of the MicroVAXen I've had required Break, and would ignore ^P.
> But most of the "big iron" VAXen required ^P and could care less about
> a Break.

Oh my god..  ^P works  (via a serial line) ..  but ONLY while booting,
that is during the primary and secondary boot strap.  After that, I don't
seem to be able to get back to the monitor or the debugger.

CPU 0 booting

(boot dkb0.0.0.3.0 -file netbsd -flags d)
block 0 of dkb0.0.0.3.0 is a valid boot block
reading 15 blocks from dkb0.0.0.3.0
bootstrap code read in
Building FRU table
base = 200000, image_start = 0, image_bytes = 1e00
initializing HWRPB at 2000
initializing page table at 1f2000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code

NetBSD/alpha 1.5.2 FFS Primary Bootstrap
Jumping to entry point...

NetBSD/alpha 1.5.2 Secondary Bootstrap, Revision 1.10
(he@albatross.urc.uninett.no, Jun 13 03:11:13 MEST 2001)

VMS PAL rev: 0x4000100010115
OSF PAL rev: 0x4000100020117
Switch to OSF PAL code succeeded.

Boot file: netbsd
Boot flags: d
5733776-
halted CPU 0

halt code = 1
operator initiated halt
PC = 10065d38
P00>>>