Re: ENABLE_SERIAL_BREAK_KEY...or something?
boggle Are you guys serious about dropping the box by powering off the console ? /boggle Yup... Pretty dumb, isn't it? mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
key to drop to the debugger? Say have it so that if a keystroke of ~b (as Would be most excellent if this could be done. A couple of boxen I have here have serial consoles attached to other machines which do a very good simulation of a break when the controlling process leaves them. Dropping to DDB every time you reboot the other machine is, uh, less than desirable behaviour. :-) Agreed, but this may be quite a project... doing a cd ~bob would be fun. :) You would pretty much have to implement some timing requirements, but I imagine that it could bulk up that section of the kernel pretty easily. One thing that might help (assuming you CAN generate a break) is to watch DCD (or some other control line(s)). Generally, when a break is sent intentionally, the DCD line is active -- when the kernel detects a break, wait until after it's finished, then check DCD. If it's high, drop to debugger. If it's low, somebody either turned the terminal off or dropped outta kermit. (I have the displeasure of maintaining an AIX box that does something similar to this. Before the upgrade that fixed this problem, turning off the serial console brought the whole machine down.) --Mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
Mike Nowlin wrote: Agreed, but this may be quite a project... doing a cd ~bob would be fun. :) You would pretty much have to implement some timing requirements, but I imagine that it could bulk up that section of the kernel pretty easily. Yep. I started to hack something like this into sio.c in the days of 2.1, then the need disappeared for a while and I never completed it. One thing that might help (assuming you CAN generate a break) is to watch DCD (or some other control line(s)). Yes. (DSR also jumps to mind.) Generally, when a break is sent intentionally, the DCD line is active -- when the kernel detects a break, wait until after it's finished, then check DCD. If it's high, drop to debugger. If it's low, somebody either turned the terminal off or dropped outta kermit. Excellent idea. (I have the displeasure of maintaining an AIX box that does something similar to this. Before the upgrade that fixed this problem, turning off the serial console brought the whole machine down.) Suns tend to do it too. Great fun when patch-monkeys disturb the cable to the console... :-) -- Phil Homewood DNRC email: ph...@mincom.com Postmaster and BOFH Mincom Pty Ltd phone: +61-7-3303-3524 Brisbane, QLD Australia fax:+61-7-3303-3269 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
On Thu, 10 Jun 1999, Mike Nowlin wrote:
key to drop to the debugger? Say have it so that if a keystroke of ~b (as
Would be most excellent if this could be done. A couple of boxen I
have here have serial consoles attached to other machines which
do a very good simulation of a break when the controlling process
leaves them. Dropping to DDB every time you reboot the other machine
is, uh, less than desirable behaviour. :-)
Agreed, but this may be quite a project... doing a cd ~bob would be
the general idea is that this wouldn't only register as a 'break' when
issud over the serial console, nowhere else...I know, some ppl use the
serial console as a regular login, but my experience is that its painfully
slow and good for maintenance only
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
Would be most excellent if this could be done. A couple of boxen I
have here have serial consoles attached to other machines which
do a very good simulation of a break when the controlling process
leaves them. Dropping to DDB every time you reboot the other machine
is, uh, less than desirable behaviour. :-)
I had the same problem. Changing the sio code to require three breaks
inside a 10 seconds interval before dropping into the debugger reduced
the problem for me.
- Tor Egge
Index: sys/i386/conf/options.i386
===
RCS file: /home/ncvs/src/sys/i386/conf/options.i386,v
retrieving revision 1.116
diff -u -r1.116 options.i386
--- options.i3861999/06/06 22:45:04 1.116
+++ options.i3861999/06/08 00:27:17
@@ -24,6 +24,7 @@
AUTO_EOI_1 opt_auto_eoi.h
AUTO_EOI_2 opt_auto_eoi.h
BREAK_TO_DEBUGGER opt_comconsole.h
+TRIPLE_BREAK_TO_DEBUGGER opt_comconsole.h
CONSPEED opt_comconsole.h
I586_PMC_GUPROFopt_i586_guprof.h
WLCACHEopt_wavelan.h
Index: sys/isa/sio.c
===
RCS file: /home/ncvs/src/sys/isa/sio.c,v
retrieving revision 1.246
diff -u -r1.246 sio.c
--- sio.c 1999/05/31 06:57:31 1.246
+++ sio.c 1999/06/08 00:27:38
@@ -427,6 +427,16 @@
{ -1, -1 }
};
+#define DDB_BREAK_MASK (IER_ERXRDY | IER_ETXRDY | IER_ERLS | IER_EMSC)
+
+#ifdef TRIPLE_BREAK_TO_DEBUGGER
+#ifndef TRIPLE_BREAK_TIMEOUT
+#define TRIPLE_BREAK_TIMEOUT 10
+#endif
+int triple_break_count;/* number of breaks detected */
+int triple_break_time; /* time_second sampled at first break */
+#endif
+
#ifdef COM_ESP
/* XXX configure this properly. */
static Port_t likely_com_ports[] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8, };
@@ -998,6 +1008,9 @@
com-lt_out.c_ispeed = com-lt_out.c_ospeed =
com-lt_in.c_ispeed = com-lt_in.c_ospeed =
com-it_in.c_ispeed = com-it_in.c_ospeed = comdefaultrate;
+#if defined(DDB) defined(BREAK_TO_DEBUGGER) defined(DDB_BREAK_MASK)
+ outb(iobase + com_ier, DDB_BREAK_MASK);
+#endif
} else
com-it_in.c_ispeed = com-it_in.c_ospeed = TTYDEF_SPEED;
if (siosetwater(com, com-it_in.c_ispeed) != 0) {
@@ -1404,7 +1417,12 @@
com-pps.ppsparam.mode = 0;
outb(iobase + com_cfcr, com-cfcr_image = ~CFCR_SBREAK);
{
- outb(iobase + com_ier, 0);
+#if defined(DDB) defined(BREAK_TO_DEBUGGER) defined(DDB_BREAK_MASK)
+ if (com-unit == comconsole)
+ outb(iobase + com_ier, DDB_BREAK_MASK);
+ else
+#endif
+ outb(iobase + com_ier, 0);
tp = com-tp;
if (tp-t_cflag HUPCL
/*
@@ -1704,7 +1722,23 @@
if (line_status LSR_BI) {
#if defined(DDB) defined(BREAK_TO_DEBUGGER)
if (com-unit == comconsole) {
+#ifdef TRIPLE_BREAK_TO_DEBUGGER
+ if (time_second
+ triple_break_time +
+ TRIPLE_BREAK_TIMEOUT)
+ triple_break_count = 0;
+ triple_break_count++;
+ if (triple_break_count == 1)
+ triple_break_time =
+ time_second;
+ else if (triple_break_count
+== 3) {
+ triple_break_count = 0;
+ breakpoint();
+ }
+#else
breakpoint();
+#endif
goto cont;
}
#endif
Re: ENABLE_SERIAL_BREAK_KEY...or something?
On 10-Jun-99 The Hermit Hacker wrote: On Thu, 10 Jun 1999, Mike Nowlin wrote: key to drop to the debugger? Say have it so that if a keystroke of ~b (as Would be most excellent if this could be done. A couple of boxen I have here have serial consoles attached to other machines which do a very good simulation of a break when the controlling process leaves them. Dropping to DDB every time you reboot the other machine is, uh, less than desirable behaviour. :-) Agreed, but this may be quite a project... doing a cd ~bob would be the general idea is that this wouldn't only register as a 'break' when issud over the serial console, nowhere else...I know, some ppl use the serial console as a regular login, but my experience is that its painfully slow and good for maintenance only Agree also, my DG/UX (a SysV) sees a series of about twenty open-bracket, close-bracket [] on the console as a signal to jump into ROM. I've only had to use it once; the box was so far in the weeds that I couldn't get a login. boggle Are you guys serious about dropping the box by powering off the console ? /boggle Regards, --- Don Read dr...@calcasieu.com EDP Manager dr...@texas.net Calcasieu Lumber Co. Austin TX -- Meddle not in the affairs of dragons, for you are crunchy and taste good with ketchup. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
On Thu, 10 Jun 1999, Don Read wrote: boggle Are you guys serious about dropping the box by powering off the console ? /boggle Suns do this. They sense the terminal power off as a break. One previous ork place had a bunch of rack mounted suns, sharing a serial console via a switch box. There was a problem that sometimes switching from one machine to another would cause a break. Someone wired it slightly different, and included a push button on the switch box to send a break. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ENABLE_SERIAL_BREAK_KEY...or something?
How hard would it be to add a kernel option that would enable an alternate
key to drop to the debugger? Say have it so that if a keystroke of ~b (as
suggested by one user) came through on the console line, it would drop to
the debugger?
I guess the next question is would this even work once the hang happened,
of course...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: ENABLE_SERIAL_BREAK_KEY...or something?
The Hermit Hacker wrote: How hard would it be to add a kernel option that would enable an alternate key to drop to the debugger? Say have it so that if a keystroke of ~b (as suggested by one user) came through on the console line, it would drop to the debugger? Would be most excellent if this could be done. A couple of boxen I have here have serial consoles attached to other machines which do a very good simulation of a break when the controlling process leaves them. Dropping to DDB every time you reboot the other machine is, uh, less than desirable behaviour. :-) (Perhaps this thread should go to -hackers?) -- Phil Homewood DNRC email: ph...@mincom.com Postmaster and BOFH Mincom Pty Ltd phone: +61-7-3303-3524 Brisbane, QLD Australia fax:+61-7-3303-3269 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
