[PATCH] 2.5.59 morse code panics

[PATCH] 2.5.59 morse code panics

[Tomas Szepe]

Here's the initial port of Andrew Rodland's morse code panics to
2.5.  It's probably got a few issues that need to be sorted out:
at least the acquisition of the atkbd handle is a shameful hack.
The original regular blinking code from ac has been removed,
because it's no use when we've got morse about. :)

Any comments appreciated, patch against 2.5.59.

-- 
Tomas Szepe <szepe@pinerecords.com>


diff -urN a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
--- a/drivers/input/keyboard/atkbd.c	2002-12-08 20:06:16.000000000 +0100
+++ b/drivers/input/keyboard/atkbd.c	2003-01-30 15:19:50.000000000 +0100
@@ -445,6 +445,23 @@
 	atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_SSCANSET);
 }
 
+#ifdef CONFIG_MORSE_PANICS
+static struct atkbd *atkbd_blinkdev = NULL;
+int atkbd_blink(char led) {
+	char param[2] = "\0\0";
+	led = led ? (0x01 | 0x04) : 0x00;
+	*param = led;
+
+	if (atkbd_blinkdev == NULL)
+		return -1;
+
+	if (atkbd_command(atkbd_blinkdev, param, ATKBD_CMD_SETLEDS))
+		return -1;
+
+	return 0;
+}
+#endif
+
 /*
  * atkbd_disconnect() closes and frees.
  */
@@ -543,11 +560,12 @@
 			set_bit(atkbd->keycode[i], atkbd->dev.keybit);
 
 	input_register_device(&atkbd->dev);
-
+#ifdef CONFIG_MORSE_PANICS
+	atkbd_blinkdev = atkbd;
+#endif
 	printk(KERN_INFO "input: %s on %s\n", atkbd->name, serio->phys);
 }
 
-
 static struct serio_dev atkbd_dev = {
 	.interrupt =	atkbd_interrupt,
 	.connect =	atkbd_connect,
diff -urN a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig	2003-01-17 04:27:10.000000000 +0100
+++ b/init/Kconfig	2003-01-30 15:15:56.000000000 +0100
@@ -98,6 +98,17 @@
 		     13 =>  8 KB
 		     12 =>  4 KB
 
+config MORSE_PANICS
+	bool "Morse code panics"
+	depends on KEYBOARD_ATKBD || VT
+	help
+	  When enabled, this code will make a panicking kernel scream for
+	  help in morse code, signalling on the leds of a possibly attached
+	  AT keyboard and/or a bleeper.  You can enable/disable your morse
+	  output devices of choice using the "panicmorse" kernel boot
+	  parameter.
+	  If unsure, say Y.
+
 endmenu
 
 
@@ -159,4 +170,3 @@
 	  in <file:Documentation/kmod.txt>.
 
 endmenu
-
diff -urN a/kernel/panic.c b/kernel/panic.c
--- a/kernel/panic.c	2003-01-09 14:25:40.000000000 +0100
+++ b/kernel/panic.c	2003-01-30 15:46:11.000000000 +0100
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 #include <linux/sysrq.h>
 #include <linux/interrupt.h>
+#include <linux/vt_kern.h>
 
 asmlinkage void sys_sync(void);	/* it's really int */
 
@@ -31,6 +32,142 @@
 
 __setup("panic=", panic_setup);
 
+#ifdef CONFIG_MORSE_PANICS
+
+#ifdef CONFIG_KEYBOARD_ATKBD
+ extern int atkbd_blink(char led);	/* drivers/input/keyboards/atkbd.c */
+ #define do_blink(x) atkbd_blink(x)
+#else
+ #define do_blink(x) 0
+#endif
+
+static int morse_setting = 1;
+
+static const unsigned char morsetable[] = {
+	0122, 0, 0310, 0, 0, 0163,				/* "#$%&' */
+	055, 0155, 0, 0, 0163, 0141, 0152, 0051, 		/* ()*+,-./ */
+	077, 076, 074, 070, 060, 040, 041, 043, 047, 057,	/* 0-9 */
+	0107, 0125, 0, 0061, 0, 0114, 0, 			/* :;<=>?@ */
+	006, 021, 025, 011, 002, 024, 013, 020, 004,		/* A-I */
+	036, 015, 022, 007, 005, 017, 026, 033, 012,		/* J-R */
+	010, 003, 014, 030, 016, 031, 035, 023,			/* S-Z */
+	0, 0, 0, 0, 0154					/* [\]^_ */
+};
+
+static inline unsigned char tomorse(char c) {
+	if (c >= 'a' && c <= 'z')
+		c = c - 'a' + 'A';
+	if (c >= '"' && c <= '_') {
+		return morsetable[c - '"'];
+	} else
+		return 0;
+}
+
+#define DITLEN		(HZ / 5)
+#define DAHLEN		(3 * DITLEN)
+#define SPACELEN	(7 * DITLEN)
+
+#define FREQ 844
+
+/*  Tell the user who may be running in X and not see the console that
+ *  we have panic'd.  This is to distingush panics from "real lockups."
+ *  Could in theory send the panic message as morse, but that is left
+ *  as an exercise for the reader.
+ *
+ *  And now it's done! LED and speaker morse code by Andrew Rodland
+ *  <arodland@noln.com>, with improvements based on suggestions from
+ *  linux@horizon.com and a host of others.
+ *
+ *  Initial 2.5 morsepanics port by Tomas Szepe <szepe@pinerecords.com>,
+ *  January 2003.
+ */
+void panic_morseblink(char *buf)
+{ 
+	static unsigned long next_jiffie = 0;
+	static char * bufpos = 0;
+	static unsigned char morse = 0;
+	static char state = 1;
+	
+	if (!morse_setting) 
+		return;
+
+	if (!buf)
+		buf = "Uh oh, we lost the panic msg.";
+
+	/* Waiting for something? */
+	if (bufpos && time_after(next_jiffie, jiffies))
+		return;
+
+	if (state) {	/* Coming off of a blink. */
+		if (morse_setting & 0x01)
+			do_blink(0);
+
+		state = 0;
+
+		if (morse > 1) {
+			/* Not done yet, just a one-dit pause. */
+			next_jiffie = jiffies + DITLEN;
+		} else {
+			/* Get a new char, figure out how much space. */
+
+			/* First time through */
+			if (!bufpos)
+				bufpos = (char *) buf;
+
+			if (!*bufpos) {
+				/* Repeating */
+				bufpos = (char *) buf;
+				next_jiffie = jiffies + SPACELEN;
+			} else {
+				/* Inter-letter space */
+				next_jiffie = jiffies + DAHLEN; 
+			}
+
+			if (!(morse = tomorse(*bufpos))) {
+				next_jiffie = jiffies + SPACELEN;
+				state = 1;	/* And get us back here */
+			}
+			bufpos++;
+		}
+	} else {
+		/* Starting a new blink.  We have a valid code in morse. */
+		int len;
+
+		len = (morse & 001) ? DAHLEN : DITLEN;
+
+#ifdef CONFIG_VT
+		if (morse_setting & 0x02)
+			kd_mksound(FREQ, len);
+#endif
+
+		next_jiffie = jiffies + len;
+
+		if (morse_setting & 0x01)
+			do_blink(1);
+
+		state = 1;
+		morse >>= 1;
+	}
+}
+
+static int __init panicmorse_setup(char *str)
+{
+	int par;
+	if (get_option(&str, &par)) 
+		morse_setting = par;
+	return 1;
+}
+
+/*  "panicmorse=0" disables the blinking as it caused problems with
+ *  certain console switches.
+ *
+ *  "panicmorse | 1" does the show using kbd leds.
+ *  "panicmorse | 2" throws in bleeping via kd_mksound().
+ */
+__setup("panicmorse=", panicmorse_setup);
+
+#endif /* CONFIG_MORSE_PANICS */
+
 /**
  *	panic - halt the system
  *	@fmt: The text string to print
@@ -95,7 +232,10 @@
         disabled_wait(caller);
 #endif
 	local_irq_enable();
-	for(;;) {
+	for (;;) {
+#if defined(CONFIG_MORSE_PANICS)
+		panic_morseblink(buf);
+#endif
 		CHECK_EMERGENCY_SYNC
 	}
 }

Re: [PATCH] 2.5.59 morse code panics

[Dave Jones]

On Thu, Jan 30, 2003 at 04:07:09PM +0100, Tomas Szepe wrote:
 > Here's the initial port of Andrew Rodland's morse code panics to
 > 2.5.  It's probably got a few issues that need to be sorted out:
 > at least the acquisition of the atkbd handle is a shameful hack.
 > The original regular blinking code from ac has been removed,
 > because it's no use when we've got morse about. :)
 > 
 > Any comments appreciated, patch against 2.5.59.

I forwarded Linus a copy of Andi Kleens original
'blink leds on panic' patch circa 2.5.3 or so.
He rejected it due to not wanting PC-isms in kernel/

As this patch further builds upon the previous one,
It'd take a complete change of mind on his part to take
this as it is.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.59 morse code panics

[Alan Cox]

On Thu, 2003-01-30 at 17:36, Dave Jones wrote:
> As this patch further builds upon the previous one,
> It'd take a complete change of mind on his part to take
> this as it is.

If its attached to atkbd then its not a PCism and its now
nicely modularised in the atkbd driver. Providing we have
a clear split between the core "morse sender" and the
platform specific morse output device (do we want 
morse_ops 8)) it should be clean and you can write morse
drivers for pc speaker, for non pc keyboard and even for
soundblaster 8)

Re: [PATCH] 2.5.59 morse code panics

[Tomas Szepe]

> [alan@lxorguk.ukuu.org.uk]
> 
> On Thu, 2003-01-30 at 17:36, Dave Jones wrote:
> 
> > As this patch further builds upon the previous one,
> > It'd take a complete change of mind on his part to take
> > this as it is.
> 
> If its attached to atkbd then its not a PCism and its now
> nicely modularised in the atkbd driver. Providing we have
> a clear split between the core "morse sender" and the
> platform specific morse output device (do we want 
> morse_ops 8)) it should be clean and you can write morse
> drivers for pc speaker, for non pc keyboard and even for
> soundblaster 8)

Of course we want morseops. :)
v2 follows.

-- 
Tomas Szepe <szepe@pinerecords.com>


 drivers/input/keyboard/atkbd.c |   22 +++++-
 include/linux/morseops.h       |   26 +++++++
 init/Kconfig                   |   14 +++-
 kernel/Makefile                |    1 
 kernel/morse.c                 |  137 +++++++++++++++++++++++++++++++++++++++++
 kernel/panic.c                 |    4 -
 6 files changed, 200 insertions(+), 4 deletions(-)

diff -urN b/drivers/input/keyboard/atkbd.c a/drivers/input/keyboard/atkbd.c
--- b/drivers/input/keyboard/atkbd.c	2002-12-08 20:06:16.000000000 +0100
+++ a/drivers/input/keyboard/atkbd.c	2003-01-31 10:20:56.000000000 +0100
@@ -445,6 +445,23 @@
 	atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_SSCANSET);
 }
 
+#ifdef CONFIG_MORSE_PANICS
+static struct atkbd *atkbd_blinkdev = NULL;
+int atkbd_blink(char led) {
+	char param[2] = "\0\0";
+	led = led ? (0x01 | 0x04) : 0x00;
+	*param = led;
+
+	if (atkbd_blinkdev == NULL)
+		return -1;
+
+	if (atkbd_command(atkbd_blinkdev, param, ATKBD_CMD_SETLEDS))
+		return -1;
+
+	return 0;
+}
+#endif
+
 /*
  * atkbd_disconnect() closes and frees.
  */
@@ -543,11 +560,12 @@
 			set_bit(atkbd->keycode[i], atkbd->dev.keybit);
 
 	input_register_device(&atkbd->dev);
-
+#ifdef CONFIG_MORSE_PANICS
+	atkbd_blinkdev = atkbd;
+#endif
 	printk(KERN_INFO "input: %s on %s\n", atkbd->name, serio->phys);
 }
 
-
 static struct serio_dev atkbd_dev = {
 	.interrupt =	atkbd_interrupt,
 	.connect =	atkbd_connect,
diff -urN b/include/linux/morseops.h a/include/linux/morseops.h
--- b/include/linux/morseops.h	1970-01-01 01:00:00.000000000 +0100
+++ a/include/linux/morseops.h	2003-01-31 11:20:05.000000000 +0100
@@ -0,0 +1,26 @@
+/* Yes, it's morse code ops indeed. */
+
+#ifndef _LINUX_MORSEOPS_H
+#define _LINUX_MORSEOPS_H
+
+#include <linux/config.h>
+
+#if defined(CONFIG_MORSE_PANICS)
+
+extern const unsigned char morsetable[];	/* in kernel/morse.c */
+void panic_morseblink(char *buf);		/* in kernel/morse.c */
+
+static inline unsigned char tomorse(char c) {
+	if (c >= 'a' && c <= 'z')
+		c = c - 'a' + 'A';
+	if (c >= '"' && c <= '_') {
+		return morsetable[c - '"'];
+	} else
+		return 0;
+}
+
+#else	/* CONFIG_MORSE_PANICS */
+ #define panic_morseblink(buf)
+#endif	/* CONFIG_MORSE_PANICS */
+
+#endif	/* _LINUX_MORSEOPS_H */
diff -urN b/init/Kconfig a/init/Kconfig
--- b/init/Kconfig	2003-01-17 04:27:43.000000000 +0100
+++ a/init/Kconfig	2003-01-31 11:06:31.000000000 +0100
@@ -98,6 +98,19 @@
 		     13 =>  8 KB
 		     12 =>  4 KB
 
+config MORSE_PANICS
+	bool "Morse code panics"
+	depends on KEYBOARD_ATKBD || VT
+	help
+	  When enabled, this code will make a panicking kernel cry for
+	  help in morse code, signalling on the leds of a possibly attached
+	  AT keyboard and/or a bleeper.  You can enable/disable your morse
+	  output devices of choice using the "panicmorse" kernel boot
+	  parameter.
+
+	  If unsure, say Y.  This feature is very helpful for those who
+	  spend most of their time in X.
+
 endmenu
 
 
@@ -159,4 +172,3 @@
 	  in <file:Documentation/kmod.txt>.
 
 endmenu
-
diff -urN b/kernel/Makefile a/kernel/Makefile
--- b/kernel/Makefile	2003-01-09 10:59:41.000000000 +0100
+++ a/kernel/Makefile	2003-01-31 10:28:04.000000000 +0100
@@ -22,6 +22,7 @@
 obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
 obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
 obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_MORSE_PANICS) += morse.o
 
 ifneq ($(CONFIG_IA64),y)
 # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
diff -urN b/kernel/morse.c a/kernel/morse.c
--- b/kernel/morse.c	1970-01-01 01:00:00.000000000 +0100
+++ a/kernel/morse.c	2003-01-31 11:19:54.000000000 +0100
@@ -0,0 +1,137 @@
+/*
+ *  kernel/morse.c
+ *
+ *  Copyright (C) 2002 Andrew Rodland <arodland@noln.com>
+ *  Copyright (C) 2003 Tomas Szepe <szepe@pinerecords.com>
+ *
+ *  Tell the user who may be running in X and not see the console that
+ *  we have panic'd.  This is to distingush panics from "real lockups."
+ *  Could in theory send the panic message as morse, but that is left
+ *  as an exercise for the reader.
+ *
+ *  And now it's done! LED and speaker morse code by Andrew Rodland
+ *  <arodland@noln.com>, with improvements based on suggestions from
+ *  linux@horizon.com and a host of others.
+ *
+ *  Initial 2.5 morsepanics port and cleanup by
+ *  Tomas Szepe <szepe@pinerecords.com>, January 2003.
+ */
+
+#include <linux/config.h>
+#include <linux/morseops.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/vt_kern.h>
+
+#define DITLEN		(HZ / 5)
+#define DAHLEN		(3 * DITLEN)
+#define SPACELEN	(7 * DITLEN)
+#define FREQ		844
+
+/*  Only blink by default if AT keyboard is available,
+ *  go for beeping if it isn't.
+ */
+#ifdef CONFIG_KEYBOARD_ATKBD
+extern int atkbd_blink(char led);	/* drivers/input/keyboards/atkbd.c */
+#define do_blink(x) atkbd_blink(x)
+static int morse_setting = 1;
+#else
+#define do_blink(x)
+static int morse_setting = 2;
+#endif
+
+const unsigned char morsetable[] = {
+	0122, 0, 0310, 0, 0, 0163,				/* "#$%&' */
+	055, 0155, 0, 0, 0163, 0141, 0152, 0051, 		/* ()*+,-./ */
+	077, 076, 074, 070, 060, 040, 041, 043, 047, 057,	/* 0-9 */
+	0107, 0125, 0, 0061, 0, 0114, 0, 			/* :;<=>?@ */
+	006, 021, 025, 011, 002, 024, 013, 020, 004,		/* A-I */
+	036, 015, 022, 007, 005, 017, 026, 033, 012,		/* J-R */
+	010, 003, 014, 030, 016, 031, 035, 023,			/* S-Z */
+	0, 0, 0, 0, 0154					/* [\]^_ */
+};
+
+void panic_morseblink(char *buf)
+{ 
+	static unsigned long next_jiffie = 0;
+	static char * bufpos = 0;
+	static unsigned char morse = 0;
+	static char state = 1;
+	
+	if (!morse_setting) 
+		return;
+
+	if (!buf)
+		buf = "Uh oh, we lost the panic msg.";
+
+	/* Waiting for something? */
+	if (bufpos && time_after(next_jiffie, jiffies))
+		return;
+
+	if (state) {	/* Coming off of a blink. */
+		if (morse_setting & 0x01)
+			do_blink(0);
+
+		state = 0;
+
+		if (morse > 1) {
+			/* Not done yet, just a one-dit pause. */
+			next_jiffie = jiffies + DITLEN;
+		} else {
+			/* Get a new char, figure out how much space. */
+
+			/* First time through */
+			if (!bufpos)
+				bufpos = (char *) buf;
+
+			if (!*bufpos) {
+				/* Repeating */
+				bufpos = (char *) buf;
+				next_jiffie = jiffies + SPACELEN;
+			} else {
+				/* Inter-letter space */
+				next_jiffie = jiffies + DAHLEN; 
+			}
+
+			if (!(morse = tomorse(*bufpos))) {
+				next_jiffie = jiffies + SPACELEN;
+				state = 1;	/* And get us back here */
+			}
+			bufpos++;
+		}
+	} else {
+		/* Starting a new blink.  We have a valid code in morse. */
+		int len;
+
+		len = (morse & 001) ? DAHLEN : DITLEN;
+
+#ifdef CONFIG_VT
+		if (morse_setting & 0x02)
+			kd_mksound(FREQ, len);
+#endif
+
+		next_jiffie = jiffies + len;
+
+		if (morse_setting & 0x01)
+			do_blink(1);
+
+		state = 1;
+		morse >>= 1;
+	}
+}
+
+static int __init panicmorse_setup(char *str)
+{
+	int par;
+	if (get_option(&str, &par)) 
+		morse_setting = par;
+	return 1;
+}
+
+/*  "panicmorse=0" disables the blinking as it caused problems with
+ *  certain console switches.
+ *
+ *  "panicmorse | 1" does the show using kbd leds.
+ *  "panicmorse | 2" throws in bleeping via kd_mksound().
+ */
+__setup("panicmorse=", panicmorse_setup);
diff -urN b/kernel/panic.c a/kernel/panic.c
--- b/kernel/panic.c	2003-01-09 10:59:41.000000000 +0100
+++ a/kernel/panic.c	2003-01-31 10:36:50.000000000 +0100
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 #include <linux/sysrq.h>
 #include <linux/interrupt.h>
+#include <linux/morseops.h>
 
 asmlinkage void sys_sync(void);	/* it's really int */
 
@@ -95,7 +96,8 @@
         disabled_wait(caller);
 #endif
 	local_irq_enable();
-	for(;;) {
+	for (;;) {
+		panic_morseblink(buf);
 		CHECK_EMERGENCY_SYNC
 	}
 }

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> > > As this patch further builds upon the previous one,
> > > It'd take a complete change of mind on his part to take
> > > this as it is.
> > 
> > If its attached to atkbd then its not a PCism and its now
> > nicely modularised in the atkbd driver. Providing we have
> > a clear split between the core "morse sender" and the
> > platform specific morse output device (do we want 
> > morse_ops 8)) it should be clean and you can write morse
> > drivers for pc speaker, for non pc keyboard and even for
> > soundblaster 8)

Actually the Soundblaster idea might not be so funny as it originally
sounds, (pun intended :-) ), because if you've got another machine
nearby, with a microphone, you could actually turn up the volume, and
de-code the morse on the other box.  The PC speaker may well be too
quiet to do that.  It should be fairly straightforward to get a simple
bleep out of any card that implements the Adlib registers.

John.

Re: [PATCH] 2.5.59 morse code panics

[Dave Jones]

On Fri, Jan 31, 2003 at 11:12:57AM +0000, John Bradford wrote:

 > Actually the Soundblaster idea might not be so funny as it originally
 > sounds, (pun intended :-) ), because if you've got another machine
 > nearby, with a microphone, you could actually turn up the volume, and
 > de-code the morse on the other box.

Or you could put down the crackpipe and run a serial console between
the two boxes. Or even netconsole would make more sense
(and be a lot more reliable).
 
		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.59 morse code panics

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

On Fri, 31 Jan 2003 13:22:21 GMT, Dave Jones said:

> Or you could put down the crackpipe and run a serial console between
> the two boxes. Or even netconsole would make more sense
> (and be a lot more reliable).

There's a classic Monty Python skit where John Cleese is organizing an
expedition to build a bridge between the two peaks of Mt Kilamanjaro.

I have to do most of my kernel hacking at home, on my own time.  So I'm
sitting there with a laptop and no second machine.  Now, if the intent is
to say "Don't bother doing anything that might require debugging unless you
can afford 2 machines", that's OK - but let's be open about that requirement.
And has been pointed out, some laptops don't even *HAVE* a serial port.

There's a *REASON* that IBM RS/6K boxes have at least a little 3-digit LED
display - during boot or a panic, even if you can't trust the console drivers
anymore, you can still output *something*.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> There's a *REASON* that IBM RS/6K boxes have at least a little 3-digit LED
> display - during boot or a panic, even if you can't trust the console drivers
> anymore, you can still output *something*.

By the way, you can buy cards with LED displays on which monitor port
80h, and tell you how far through the boot process a box is getting.
Not much use on a laptop, though :-).

John.

Re: [PATCH] 2.5.59 morse code panics

[Dave Jones]

On Fri, Jan 31, 2003 at 09:40:27AM -0500, Valdis.Kletnieks@vt.edu wrote:

 > I have to do most of my kernel hacking at home, on my own time.  So I'm
 > sitting there with a laptop and no second machine.  Now, if the intent is
 > to say "Don't bother doing anything that might require debugging unless you
 > can afford 2 machines", that's OK - but let's be open about that requirement.
 > And has been pointed out, some laptops don't even *HAVE* a serial port.

So go see Ingo's netconsole. (Which admittedly only supports certain
net drivers). Or one of the crashdump facilities. All of which is far more
reliable and useful than sitting there with a microphone.
 
 > There's a *REASON* that IBM RS/6K boxes have at least a little 3-digit LED
 > display - during boot or a panic, even if you can't trust the console drivers
 > anymore, you can still output *something*.

There's no reason to trust morse panic output more than console output.
If something has scribbled over kernel space memory, you're screwed
anyway. It's hit or miss whether your panic-method-de-jour has been
stomped on.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: [PATCH] 2.5.59 morse code panics

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Fri, 31 Jan 2003 15:05:41 GMT, Dave Jones said:

> So go see Ingo's netconsole. (Which admittedly only supports certain
> net drivers). Or one of the crashdump facilities. All of which is far more
> reliable and useful than sitting there with a microphone.

If I don't have a second box to run a serial cable to, I probably don't have
a second box to run cat5 to, so netconsole probably doesn't do me any good.

crashdump might be usable, I'll have to look...

> There's no reason to trust morse panic output more than console output.
> If something has scribbled over kernel space memory, you're screwed
> anyway. It's hit or miss whether your panic-method-de-jour has been
> stomped on.

The real solution is probably to get Ingo's netconsole, the morse-panic patch,
the current serial-console support, and abstract it all into some
infrastructure with output hooks - netconsole, serial, morse, whatever.

But we're alledgedly in a feature freeze, so that's a 2.7-ish I guess...
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] 2.5.59 morse code panics

[Alan Cox]

On Fri, 2003-01-31 at 13:22, Dave Jones wrote:
> Or you could put down the crackpipe and run a serial console between
> the two boxes. Or even netconsole would make more sense
> (and be a lot more reliable).

A lot of newer laptops do not have serial ports. While morse code may
be a little silly the general purpose hook  it needs to be done 
cleanly is considerably more useful

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> A lot of newer laptops do not have serial ports. While morse code may
> be a little silly the general purpose hook  it needs to be done 
> cleanly is considerably more useful

Exactly.

The exact method that a crashed machine, in a rack, in a datacentre,
miles away from me, contacts me to let me know something is wrong
doesn't matter, but if a member of the datacentre staff can get a
detailed message to me, so much the better than just having the box
rebooted.  On the other hand, I don't actually want to have to listen
to ten minutes of morse code over the phone when another box could do
it for me.

John.

Re: [PATCH] 2.5.59 morse code panics

[Dave Jones]

On Fri, Jan 31, 2003 at 02:29:59PM +0000, John Bradford wrote:

 > The exact method that a crashed machine, in a rack, in a datacentre,
 > miles away from me, contacts me to let me know something is wrong
 > doesn't matter, but if a member of the datacentre staff can get a
 > detailed message to me, so much the better than just having the box
 > rebooted.  On the other hand, I don't actually want to have to listen
 > to ten minutes of morse code over the phone when another box could do
 > it for me.

That must be a pretty quiet datacentre. And what happens when more than
one box starts beeping ?

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: [PATCH] 2.5.59 morse code panics

[Dave Jones]

On Fri, Jan 31, 2003 at 03:09:46PM +0000, Alan Cox wrote:

 > A lot of newer laptops do not have serial ports.

so use something sensible like a crashdump to floppy.
 
 > While morse code may
 > be a little silly the general purpose hook  it needs to be done 
 > cleanly is considerably more useful

sure. things like lkcd,netconsole etc could all use that
infrastructure.   The beyond-silly bit was the 'other machine
to decode morse' argument.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

>  > A lot of newer laptops do not have serial ports.
> 
> so use something sensible like a crashdump to floppy.

A lot of newer laptops do not have floppy drives :-)

Seriously, though, I agree that morse isn't the most ideal way to get
data out of a crashed system.

>  > While morse code may
>  > be a little silly the general purpose hook  it needs to be done 
>  > cleanly is considerably more useful
> 
> sure. things like lkcd,netconsole etc could all use that
> infrastructure.   The beyond-silly bit was the 'other machine
> to decode morse' argument.

Depends on how good your morse is, I suppose, I wouldn't really want
to decode a oops from morse by ear.

>  > The exact method that a crashed machine, in a rack, in a datacentre,
>  > miles away from me, contacts me to let me know something is wrong
>  > doesn't matter, but if a member of the datacentre staff can get a
>  > detailed message to me, so much the better than just having the box
>  > rebooted.  On the other hand, I don't actually want to have to listen
>  > to ten minutes of morse code over the phone when another box could do
>  > it for me.
> 
> That must be a pretty quiet datacentre. And what happens when more than
> one box starts beeping ?

OK, point taken, that *was* a beyond-silly suggestion :-)

John.

RE: [PATCH] 2.5.59 morse code panics

[Scott Robert Ladd]

John Bradford wrote:
>> Actually the Soundblaster idea might not be so funny as it originally
>> sounds, (pun intended :-) ), because if you've got another machine
>> nearby, with a microphone, you could actually turn up the volume, and
>> de-code the morse on the other box.

And Dave Jones replied:
> Or you could put down the crackpipe and run a serial console between
> the two boxes. Or even netconsole would make more sense
> (and be a lot more reliable).

Oh, come now, Dave; be nice! This is fun stuff.

A voice synthesizer would be even better than morse code.

"I'm sorry Dave. I can't boot."

Think Hal 9000, from 2001/2010! The kernel could detect a sound card at
boot, and then tell us what broke. Very 22nd century, if you ask me.

If sound is broken or nonexistent, we could fall back to Morse! Or electric
shocks via a serial connection! The possibilities are endless.

...Scott (Who thinks people here are much too serious sometimes)

Re: [PATCH] 2.5.59 morse code panics

[Vojtech Pavlik]

On Thu, Jan 30, 2003 at 06:45:34PM +0000, Alan Cox wrote:

> On Thu, 2003-01-30 at 17:36, Dave Jones wrote:
> > As this patch further builds upon the previous one,
> > It'd take a complete change of mind on his part to take
> > this as it is.
> 
> If its attached to atkbd then its not a PCism and its now
> nicely modularised in the atkbd driver. Providing we have
> a clear split between the core "morse sender" and the
> platform specific morse output device (do we want 
> morse_ops 8)) it should be clean and you can write morse
> drivers for pc speaker, for non pc keyboard and even for
> soundblaster 8)

It should be in the keyboard.c file, using input_event() to blink the
LEDs. This way it'll work on all archs in 2.5.

I will not accept it as a patch for atkbd.c, unless there is a strong
reason to do it there.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.59 morse code panics

[Tomas Szepe]

> [vojtech@suse.cz]
> 
> It should be in the keyboard.c file, using input_event() to blink the
> LEDs. This way it'll work on all archs in 2.5.

Oh, thanks for pointing this out, Vojtech, I'll certainly fix it.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: [PATCH] 2.5.59 morse code panics

[Tomas Szepe]

> [vojtech@suse.cz]
> 
> It should be in the keyboard.c file, using input_event() to blink the
> LEDs. This way it'll work on all archs in 2.5.

This change
 a) allows for other cleanups, too.
 b) probably makes the gazillion leds on sparc keyboards blink.  EVIL!!

So here's v3.

-- 
Tomas Szepe <szepe@pinerecords.com>


 drivers/char/keyboard.c  |   21 +++++++
 include/linux/morseops.h |   26 +++++++++
 include/linux/vt_kern.h  |    3 +
 init/Kconfig             |   15 +++++
 kernel/Makefile          |    1 
 kernel/morse.c           |  125 +++++++++++++++++++++++++++++++++++++++++++++++
 kernel/panic.c           |    4 +
 7 files changed, 194 insertions(+), 1 deletion(-)

diff -urN a/drivers/char/keyboard.c b/drivers/char/keyboard.c
--- a/drivers/char/keyboard.c	2002-12-16 07:01:47.000000000 +0100
+++ b/drivers/char/keyboard.c	2003-01-31 20:24:33.000000000 +0100
@@ -262,6 +262,27 @@
 }
 
 /*
+ * Turn all possible leds on or off.
+ */
+void kd_turn_all_leds(int on_or_off)
+{
+	struct list_head *node;
+	on_or_off = on_or_off ? 1 : 0;
+
+	list_for_each(node, &kbd_handler.h_list) {
+		struct input_handle *handle = to_handle_h(node);
+		if (test_bit(EV_LED, handle->dev->evbit)) {
+			int led;
+			for (led = 0; led <= LED_MAX; led++) {
+				if (test_bit(led, handle->dev->ledbit))
+					input_event(handle->dev, EV_LED, led,
+						on_or_off);
+			}
+		}
+	}
+}
+
+/*
  * Setting the keyboard rate.
  */
 static inline unsigned int ms_to_jiffies(unsigned int ms) {
diff -urN a/include/linux/morseops.h b/include/linux/morseops.h
--- a/include/linux/morseops.h	1970-01-01 01:00:00.000000000 +0100
+++ b/include/linux/morseops.h	2003-01-31 20:24:33.000000000 +0100
@@ -0,0 +1,26 @@
+/* Yes, it's morse code ops indeed. */
+
+#ifndef _LINUX_MORSEOPS_H
+#define _LINUX_MORSEOPS_H
+
+#include <linux/config.h>
+
+#if defined(CONFIG_MORSE_PANICS)
+
+extern const unsigned char morsetable[];	/* in kernel/morse.c */
+void panic_morseblink(char *buf);		/* in kernel/morse.c */
+
+static inline unsigned char tomorse(char c) {
+	if (c >= 'a' && c <= 'z')
+		c = c - 'a' + 'A';
+	if (c >= '"' && c <= '_') {
+		return morsetable[c - '"'];
+	} else
+		return 0;
+}
+
+#else	/* CONFIG_MORSE_PANICS */
+ #define panic_morseblink(buf)
+#endif	/* CONFIG_MORSE_PANICS */
+
+#endif	/* _LINUX_MORSEOPS_H */
diff -urN a/include/linux/vt_kern.h b/include/linux/vt_kern.h
--- a/include/linux/vt_kern.h	2002-12-16 07:01:55.000000000 +0100
+++ b/include/linux/vt_kern.h	2003-01-31 20:24:33.000000000 +0100
@@ -33,7 +33,10 @@
 	wait_queue_head_t paste_wait;
 } *vt_cons[MAX_NR_CONSOLES];
 
+/* keyboard.c */
+
 extern void kd_mksound(unsigned int hz, unsigned int ticks);
+extern void kd_turn_all_leds(int on_or_off);
 extern int kbd_rate(struct kbd_repeat *rep);
 
 /* console.c */
diff -urN a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig	2003-01-17 04:27:10.000000000 +0100
+++ b/init/Kconfig	2003-01-31 20:24:33.000000000 +0100
@@ -98,6 +98,21 @@
 		     13 =>  8 KB
 		     12 =>  4 KB
 
+config MORSE_PANICS
+	bool "Morse code panics"
+	depends on VT
+	help
+	  When enabled, this code will make a panicking kernel cry for
+	  help in morse code, signalling on the leds of a possibly attached
+	  keyboard and/or a bleeper.  You can enable/disable your morse
+	  output devices of choice using the "panicmorse" kernel boot
+	  parameter.  Currently, "panicmorse=0" will disable the signalling
+	  completely, "panicmorse=1" (the default) will only blink the leds,
+	  "panicmorse=2" will only beep, and "panicmorse=3" will do both.
+
+	  If unsure, say Y.  This feature is very helpful for those who
+	  spend most of their time in X.
+
 endmenu
 
 
diff -urN a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile	2003-01-09 14:25:40.000000000 +0100
+++ b/kernel/Makefile	2003-01-31 20:24:33.000000000 +0100
@@ -22,6 +22,7 @@
 obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
 obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
 obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_MORSE_PANICS) += morse.o
 
 ifneq ($(CONFIG_IA64),y)
 # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
diff -urN a/kernel/morse.c b/kernel/morse.c
--- a/kernel/morse.c	1970-01-01 01:00:00.000000000 +0100
+++ b/kernel/morse.c	2003-01-31 20:24:33.000000000 +0100
@@ -0,0 +1,125 @@
+/*
+ *  kernel/morse.c
+ *
+ *  Copyright (C) 2002 Andrew Rodland <arodland@noln.com>
+ *  Copyright (C) 2003 Tomas Szepe <szepe@pinerecords.com>
+ *
+ *  Tell the user who may be running in X and not see the console that
+ *  we have panic'd.  This is to distingush panics from "real lockups."
+ *  Could in theory send the panic message as morse, but that is left
+ *  as an exercise for the reader.
+ *
+ *  And now it's done! LED and speaker morse code by Andrew Rodland
+ *  <arodland@noln.com>, with improvements based on suggestions from
+ *  linux@horizon.com and a host of others.
+ *
+ *  Initial 2.5 morsepanics port and cleanup by
+ *  Tomas Szepe <szepe@pinerecords.com>, January 2003.
+ */
+
+#include <linux/config.h>
+#include <linux/morseops.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/vt_kern.h>
+
+#define DITLEN		(HZ / 5)
+#define DAHLEN		(3 * DITLEN)
+#define SPACELEN	(7 * DITLEN)
+#define FREQ		844
+
+static int morse_setting = 1;
+
+const unsigned char morsetable[] = {
+	0122, 0, 0310, 0, 0, 0163,				/* "#$%&' */
+	055, 0155, 0, 0, 0163, 0141, 0152, 0051, 		/* ()*+,-./ */
+	077, 076, 074, 070, 060, 040, 041, 043, 047, 057,	/* 0-9 */
+	0107, 0125, 0, 0061, 0, 0114, 0, 			/* :;<=>?@ */
+	006, 021, 025, 011, 002, 024, 013, 020, 004,		/* A-I */
+	036, 015, 022, 007, 005, 017, 026, 033, 012,		/* J-R */
+	010, 003, 014, 030, 016, 031, 035, 023,			/* S-Z */
+	0, 0, 0, 0, 0154					/* [\]^_ */
+};
+
+void panic_morseblink(char *buf)
+{ 
+	static unsigned long next_jiffie = 0;
+	static char * bufpos = 0;
+	static unsigned char morse = 0;
+	static char state = 1;
+	
+	if (!morse_setting) 
+		return;
+
+	if (!buf)
+		buf = "Uh oh, we lost the panic msg.";
+
+	/* Waiting for something? */
+	if (bufpos && time_after(next_jiffie, jiffies))
+		return;
+
+	if (state) {	/* Coming off of a blink. */
+		if (morse_setting & 0x01)
+			kd_turn_all_leds(0);
+
+		state = 0;
+
+		if (morse > 1) {
+			/* Not done yet, just a one-dit pause. */
+			next_jiffie = jiffies + DITLEN;
+		} else {
+			/* Get a new char, figure out how much space. */
+
+			/* First time through */
+			if (!bufpos)
+				bufpos = (char *) buf;
+
+			if (!*bufpos) {
+				/* Repeating */
+				bufpos = (char *) buf;
+				next_jiffie = jiffies + SPACELEN;
+			} else {
+				/* Inter-letter space */
+				next_jiffie = jiffies + DAHLEN; 
+			}
+
+			if (!(morse = tomorse(*bufpos))) {
+				next_jiffie = jiffies + SPACELEN;
+				state = 1;	/* And get us back here */
+			}
+			bufpos++;
+		}
+	} else {
+		/* Starting a new blink.  We have a valid code in morse. */
+		int len;
+
+		len = (morse & 001) ? DAHLEN : DITLEN;
+
+		if (morse_setting & 0x02)
+			kd_mksound(FREQ, len);
+
+		next_jiffie = jiffies + len;
+
+		if (morse_setting & 0x01)
+			kd_turn_all_leds(1);
+
+		state = 1;
+		morse >>= 1;
+	}
+}
+
+static int __init panicmorse_setup(char *str)
+{
+	int par;
+	if (get_option(&str, &par)) 
+		morse_setting = par;
+	return 1;
+}
+
+/*  "panicmorse=0" disables the blinking as it caused problems with
+ *  certain console switches.
+ *
+ *  "panicmorse | 1" does the show using kbd leds.
+ *  "panicmorse | 2" throws in bleeping via kd_mksound().
+ */
+__setup("panicmorse=", panicmorse_setup);
diff -urN a/kernel/panic.c b/kernel/panic.c
--- a/kernel/panic.c	2003-01-09 14:25:40.000000000 +0100
+++ b/kernel/panic.c	2003-01-31 20:24:33.000000000 +0100
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 #include <linux/sysrq.h>
 #include <linux/interrupt.h>
+#include <linux/morseops.h>
 
 asmlinkage void sys_sync(void);	/* it's really int */
 
@@ -95,7 +96,8 @@
         disabled_wait(caller);
 #endif
 	local_irq_enable();
-	for(;;) {
+	for (;;) {
+		panic_morseblink(buf);
 		CHECK_EMERGENCY_SYNC
 	}
 }

Re: [PATCH] 2.5.59 morse code panics

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Fri, 2003-01-31 at 13:22, Dave Jones wrote:
> > Or you could put down the crackpipe and run a serial console between
> > the two boxes. Or even netconsole would make more sense
> > (and be a lot more reliable).
> 
> A lot of newer laptops do not have serial ports. While morse code may
> be a little silly the general purpose hook  it needs to be done 
> cleanly is considerably more useful

And how many users and how many kernel hackers are able to decode
morse on the fly? Are you going to explain to users
"to debug this you'll need to learn morse" ?

If you want to make debugging easy for laptops write a USB or firewire
console. Firewire is actually quite interesting because it can even
do DMA, so you could peek into the memory.

Morse is not helpful.

I admit I was the on who got this ball running by suggesting it "as an 
exercise for the reader" in the original panic blink code, but
guys this was intended as a JOKE, not serious. Please get over it
and don't merge that silly code.

Thanks,
-Andi

Re: [PATCH] 2.5.59 morse code panics

[Tomas Szepe]

> [ak@suse.de]
> 
> Morse is not helpful.

Of course it is, you're just angry that I've left out your original
plain_blinking code.

*runs*

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> > Morse is not helpful.
> 
> Of course it is

Especially since a number of Linux developers have ham radio
experience.

> you're just angry that I've left out your original
> plain_blinking code.

Well, there are typically *three* keyboard LEDs...  Why not use one
the middle one for morse, and outside two for plain blinking?

John.

Re: [PATCH] 2.5.59 morse code panics

[Tomas Szepe]

> [john@grabjohn.com]
> 
> Well, there are typically *three* keyboard LEDs...  Why not use one
> the middle one for morse, and outside two for plain blinking?

Because that's going to make reading the morse much harder.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> > Well, there are typically *three* keyboard LEDs...  Why not use one
> > the middle one for morse, and outside two for plain blinking?
> 
> Because that's going to make reading the morse much harder.

Err, I was joking, that was not a serious suggestion :-)

John.

Re: [PATCH] 2.5.59 morse code panics

[Horst von Brand]

John Bradford <john@grabjohn.com> said:

[...]

> > you're just angry that I've left out your original
> > plain_blinking code.
> 
> Well, there are typically *three* keyboard LEDs...  Why not use one
> the middle one for morse, and outside two for plain blinking?

Then put out the stuff in octal...

/me dives for a hiding place
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> > > you're just angry that I've left out your original
> > > plain_blinking code.
> > 
> > Well, there are typically *three* keyboard LEDs...  Why not use one
> > the middle one for morse, and outside two for plain blinking?
> 
> Then put out the stuff in octal...

Or maybe even have a nice scrolling binary display...

John.

Re: [PATCH] 2.5.59 morse code panics

[Eric Weigle]

> > > > you're just angry that I've left out your original
> > > > plain_blinking code.
> > > 
> > > Well, there are typically *three* keyboard LEDs...  Why not use one
> > > the middle one for morse, and outside two for plain blinking?
> > 
> > Then put out the stuff in octal...
> Or maybe even have a nice scrolling binary display...
Or even better, time it so that when you twirl the keyboard around by its
cord in a dark room, the LEDs print the message into the air a-la the skyliner
(http://www.theskyliner.com/)

/me ducks

-Eric

-- 
------------------------------------------------------------
        Eric H. Weigle -- http://public.lanl.gov/ehw/
"They that can give up essential liberty to obtain a little
temporary safety deserve neither" -- Benjamin Franklin
------------------------------------------------------------

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> > > > > you're just angry that I've left out your original
> > > > > plain_blinking code.
> > > > 
> > > > Well, there are typically *three* keyboard LEDs...  Why not use one
> > > > the middle one for morse, and outside two for plain blinking?
> > > 
> > > Then put out the stuff in octal...
> > Or maybe even have a nice scrolling binary display...
> Or even better, time it so that when you twirl the keyboard around
> by its cord in a dark room, the LEDs print the message into the air
> a-la the skyliner

> (http://www.theskyliner.com/)

Might be a problem for cordless keyboards, though - not sure how we'd
support those.

John.

Re: [PATCH] 2.5.59 morse code panics

[Bill Davidsen]

On Fri, 31 Jan 2003, John Bradford wrote:

> Well, there are typically *three* keyboard LEDs...  Why not use one
> the middle one for morse, and outside two for plain blinking?

Sure, alternating on/off between the outside LEDs at a rate of about
1/sec, like the warning lights on a railroad crossing (in the USA).

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] 2.5.59 morse code panics

[Jos Hulzink]

On Sunday 02 February 2003 16:42, Bill Davidsen wrote:
> On Fri, 31 Jan 2003, John Bradford wrote:
> > Well, there are typically *three* keyboard LEDs...  Why not use one
> > the middle one for morse, and outside two for plain blinking?
>
> Sure, alternating on/off between the outside LEDs at a rate of about
> 1/sec, like the warning lights on a railroad crossing (in the USA).

<nonsense>
As long as this doesn't mean a 50.000 kilo locomotive will ride over my 
keyboard, it is fine with me.

Oh, and I don't want to destroy the American dream, but blinking lights on 
railroad crossings even exist in the poorest countries in Africa... Or do the 
Americans even have a patent on the blinking speed ? :-P

Sidenote: you can't speak of "the middle", the LED ordering is free :) At 
least here in Europe...
</nonsense>

Besides, I'd like to see some beeps (not too annoying please) besides the 
blinking. Sometimes while debugging KGI I don't even notice the kernel 
entered kdb (also blinking LEDs, and kdb shows up on a remote terminal). 
Also: servers will usually have keyboard switches, making the blinks unnoted. 
But I assume that has been said before.

Jos

Re: [PATCH] 2.5.59 morse code panics

[Bill Davidsen]

On Mon, 3 Feb 2003, Jos Hulzink wrote:

> On Sunday 02 February 2003 16:42, Bill Davidsen wrote:
> > On Fri, 31 Jan 2003, John Bradford wrote:
> > > Well, there are typically *three* keyboard LEDs...  Why not use one
> > > the middle one for morse, and outside two for plain blinking?
> >
> > Sure, alternating on/off between the outside LEDs at a rate of about
> > 1/sec, like the warning lights on a railroad crossing (in the USA).
> 
> <nonsense>
> As long as this doesn't mean a 50.000 kilo locomotive will ride over my 
> keyboard, it is fine with me.
> 
> Oh, and I don't want to destroy the American dream, but blinking lights on 
> railroad crossings even exist in the poorest countries in Africa... Or do the 
> Americans even have a patent on the blinking speed ? :-P

In the USA thry are two, horizontal, in England I saw some up near Thursk
which were vertical. Avoiding US-centerism I clarified where I saw them,
rather than assuming that they would be the same everywhere...

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] 2.5.59 morse code panics

[Peter C. Norton]

On Fri, Jan 31, 2003 at 04:01:05PM +0000, John Bradford wrote:
> Especially since a number of Linux developers have ham radio
> experience.

Well most linux users don't.  I'm sure its really easy to find a morse
code chart in many hundreds of places online.  But 2 scripts - one
that turns keyboard input or mic input into dots and dashes (so you
can enter it yourself or put the phone up to the system's microphone)
would help.  Then all you'd need is a morse->ascii converter.

So who's got a good morse->ascii program?  And who has the
dot-dash->.-.-.- translator?  And the audio->.-.-.- translator?

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

Plan 2: If you're going to apologize, don't do it.  If you're going to 
do it, don't apologize

Re: [PATCH] 2.5.59 morse code panics

[Ryan Anderson]

On Mon, Feb 03, 2003 at 10:00:07PM -0800, Peter C. Norton wrote:
> On Fri, Jan 31, 2003 at 04:01:05PM +0000, John Bradford wrote:
> > Especially since a number of Linux developers have ham radio
> > experience.
> 
> Well most linux users don't.  I'm sure its really easy to find a morse
> code chart in many hundreds of places online.  But 2 scripts - one
> that turns keyboard input or mic input into dots and dashes (so you
> can enter it yourself or put the phone up to the system's microphone)
> would help.  Then all you'd need is a morse->ascii converter.
> 
> So who's got a good morse->ascii program?  And who has the
> dot-dash->.-.-.- translator?  And the audio->.-.-.- translator?

emacs (I'm not a user, though) has something like M-x-morse that will
convert back and forth.

Otherwise, the basic tables are fairly easy to find - I've seen multiple
filters for various IRC clients that would convert in at least one
direction.

In any case, there are two things to remember here:
	1) This may occassionaly be helpful in debugging problems.
	2) It has a nice hack value to it.

> 
> -Peter
> 
> -- 
> The 5 year plan:
> In five years we'll make up another plan.
> Or just re-use this one.
> 
> Plan 2: If you're going to apologize, don't do it.  If you're going to 
> do it, don't apologize
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Ryan Anderson
  sometimes Pug Majere

Re: [PATCH] 2.5.59 morse code panics

[John Bradford]

> > > Especially since a number of Linux developers have ham radio
> > > experience.
> > 
> > Well most linux users don't.  I'm sure its really easy to find a morse
> > code chart in many hundreds of places online.  But 2 scripts - one
> > that turns keyboard input or mic input into dots and dashes (so you
> > can enter it yourself or put the phone up to the system's microphone)
> > would help.  Then all you'd need is a morse->ascii converter.
> > 
> > So who's got a good morse->ascii program?  And who has the
> > dot-dash->.-.-.- translator?  And the audio->.-.-.- translator?

We already discussed the idea of a userspace program to decode the
morse:

http://marc.theaimsgroup.com/?l=linux-kernel&m=104401177724846&w=2

> emacs (I'm not a user, though) has something like M-x-morse that will
> convert back and forth.

Yes, M-x morse-region.

John.

Re: [PATCH] 2.5.59 morse code panics

[Dave Jones]

On Fri, Jan 31, 2003 at 04:34:55PM +0100, Andi Kleen wrote:

 > If you want to make debugging easy for laptops write a USB or firewire
 > console.

irda too maybe ?
 
 > Firewire is actually quite interesting because it can even
 > do DMA, so you could peek into the memory.

kgdb-over-firewire ? 8-)

 > Morse is not helpful.
 > 
 > I admit I was the on who got this ball running by suggesting it "as an 
 > exercise for the reader" in the original panic blink code, but
 > guys this was intended as a JOKE, not serious. Please get over it
 > and don't merge that silly code.
 
A voice of sanity.. I think you made a monster with that comment 8-)

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.59 morse code panics

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

On Fri, 31 Jan 2003 15:46:49 GMT, Dave Jones said:
> On Fri, Jan 31, 2003 at 04:34:55PM +0100, Andi Kleen wrote:
> 
>  > If you want to make debugging easy for laptops write a USB or firewire
>  > console.
> 
> irda too maybe ?

As I said - infrastructure and output hook.. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] 2.5.59 morse code panics

[Pavel Machek]

Hi!

> > On Fri, 2003-01-31 at 13:22, Dave Jones wrote:
> > > Or you could put down the crackpipe and run a serial console between
> > > the two boxes. Or even netconsole would make more sense
> > > (and be a lot more reliable).
> > 
> > A lot of newer laptops do not have serial ports. While morse code may
> > be a little silly the general purpose hook  it needs to be done 
> > cleanly is considerably more useful
> 
> And how many users and how many kernel hackers are able to decode
> morse on the fly? Are you going to explain to users
> "to debug this you'll need to learn morse" ?

If it is message "could not mount ext2 on /dev/hda2" I guess I could
catch enough of it to be usefull.

> I admit I was the on who got this ball running by suggesting it "as an 
> exercise for the reader" in the original panic blink code, but
> guys this was intended as a JOKE, not serious. Please get over it
> and don't merge that silly code.

Its not *that* silly. Simple extension of "blink leds on panic".

								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [PATCH] 2.5.59 morse code panics

[Henning P. Schmiedehausen]

Pavel Machek <pavel@suse.cz> writes:

>> And how many users and how many kernel hackers are able to decode
>> morse on the fly? Are you going to explain to users
>> "to debug this you'll need to learn morse" ?

You don't need to. All you need is a simple tool where you can toggle
the morse code via mouse button or keyboard in and the screen displays
the clear text. I'd say you can write this for a Palm (poking the
screen with the pen). This is, after all, the 21st century. ;-)

>If it is message "could not mount ext2 on /dev/hda2" I guess I could
>catch enough of it to be usefull.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen                  INTERMETA GmbH
hps@intermeta.de           +49 9131 50 654 0        http://www.intermeta.de/

  Java, perl, Solaris, Linux, xSP Consulting, Web Services -- hero for hire
        freelance consultant -- Jakarta Turbine Development  -- RHSCLG

Re: [PATCH] 2.5.59 morse code panics

[Albert D. Cahalan]

Dave Jones writes:
> On Fri, Jan 31, 2003 at 02:29:59PM +0000, John Bradford wrote:

>> On the other hand, I don't actually want to have to listen
>> to ten minutes of morse code over the phone when another
>> box could do it for me.
>
> That must be a pretty quiet datacentre. And what happens
> when more than one box starts beeping ?

a. Supposedly a good ham can pick one signal from many,
   at least if the pitches are different.

b. If you're not a good ham, you can process the audio.
   There are existing decoders that might do the job.
   This works for 1 computer if you have a tape recorder.

Using fast Morse over the speaker, an oops may take
30 minutes.

Blinking keyboard LEDs would have to be much slower.
The data would have to be just an instruction pointer.

Using a non-Morse code over the speaker could get the
transmission time down to a couple minutes, with full
ASCII and error correction.

Say, anybody have a *.wav file of machine-room noise?
(16-bit, 44.1 and 48 kHz)

Re: [PATCH] 2.5.59 morse code panics

[Marcelo Roberto Jimenez]

Dave,

> That must be a pretty quiet datacentre. And what happens when more
> than one box starts beeping ?
>
> Dave

That is a very very low probability event if there are only linux boxes.
:-)

Regards,

Marcelo.