[PATCH -ac] Panicking in morse code

[PATCH -ac] Panicking in morse code

[Andrew Rodland]

No, it's not 1 April.

I was researching panic_blink() for someone who needed a little help,
when I noticed the comment above the function definition, not being the
kind to step down from a challenge (unless it's just really hard), I
decided to write morse code output code.

The option panicblink= has been hijacked to be a simple bitfield: 
bit 1 : blink LEDs
bit 2 : sound the PC speaker.

the blinking option depends only on pc_keyb.c. the pcspeaker option
depends on kb_mksound() actually doing something. At the moment, both of
these mean i386. The call to panic_blink() in panic() is still guarded
by an i386 #ifdef, anyway, for the moment. The default is to blink only,
because I figured the beeps would be too annoying. Opinions?

It recognizes letters, and digits, and treats everything else as a
space. The timings are tunable by #defines. It repeats the message
indefinitely. And it should only bloat the kernel by a few hundred
bytes, although if someone wants to wrap this in its own config option,
well, that's good too.

Anyway, here's the patch. It's against linux-2.4.19-rc1-ac1+preempt, but
I suspect it applies against all recent -ac. If 2.5 has this, it will
hopefully apply with some fuzz against that, too. I don't have a tree.
(modem. ecch.)


diff -u -r -d linux.old/drivers/char/pc_keyb.c linux/drivers/char/pc_keyb.c
--- linux.old/drivers/char/pc_keyb.c	Fri Jul 19 00:59:04 2002
+++ linux/drivers/char/pc_keyb.c	Fri Jul 19 01:00:34 2002
@@ -1244,37 +1244,126 @@
 #endif /* CONFIG_PSMOUSE */
 
 
-static int blink_frequency = HZ/2;
+static int blink_setting = 1;
 
 /* Tell the user who may be running in X and not see the console that we have 
    panic'ed. 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.  */ 
-void panic_blink(void)
-{ 
-	static unsigned long last_jiffie;
-	static char led;
-	/* Roughly 1/2s frequency. KDB uses about 1s. Make sure it is 
-	   different. */
-	if (!blink_frequency) 
-		return;
-	if (jiffies - last_jiffie > blink_frequency) {
-		led ^= 0x01 | 0x04;
+   exercise for the reader.  
+	And now it's done! LED and speaker morse code by Andrew Rodland, 18-19 Jul 2002
+*/ 
+
+static const char * morse[] = {
+	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
+	"..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
+	"--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
+	"-.--", "--..",	 	 	 	 	 	 /* Y-Z */
+	"-----", ".----", "..---", "...--", "....-",	 	 /* 0-4 */
+	".....", "-....", "--...", "---..", "----."	 	 /* 5-9 */
+};
+
+#define DITLEN (HZ / 4)
+#define DAHLEN 3 * DITLEN
+#define FREQ 1000
+
+static __inline__ void do_blink (int led) {
+
+		if (! blink_setting & 0x01)
+			return;
+		
+		led = led ? (0x01 | 0x04) : 0x00;
+
 		while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); 
 		kbd_write_output(KBD_CMD_SET_LEDS);
 		mdelay(1); 
 		while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); 
 		mdelay(1); 
 		kbd_write_output(led);
-		last_jiffie = jiffies;
+}
+
+void panic_blink(char * buf)
+{ 
+	static unsigned long next_jiffie = 0;
+	static char * bufpos = 0;
+	static char * morsepos = 0;
+	static char state;
+	
+	if (!blink_setting) 
+		return;
+
+	if (!buf)
+		buf="ABC";
+
+
+	if (jiffies > next_jiffie || !bufpos) { //messy. fix.
+		
+		if (state) {
+			do_blink(0);
+			state = 0;
+			next_jiffie = jiffies + DITLEN;
+			return;
+		}
+
+		if (!bufpos) {
+			bufpos = (char *)buf;
+			return;
+		}
+
+	
+		if (!morsepos || !*morsepos) {
+			
+			if (!*bufpos) { /*Repeat the message */ 
+				bufpos = (char *)buf;
+				morsepos = 0;
+				next_jiffie = jiffies + 3 * DAHLEN;
+				return;
+			}
+			next_jiffie = jiffies + DITLEN;
+
+			if (*bufpos >= 'A' && *bufpos <= 'Z') {
+				morsepos = (char *)morse[*bufpos - 'A'];
+			} else if (*bufpos >= 'a' && *bufpos <= 'z') {
+				morsepos = (char *)morse[*bufpos - 'a'];
+			} else if (*bufpos >= '0' && *bufpos <= '9') {
+				morsepos = (char *)morse[*bufpos - '0' + 26];
+			} else {
+				next_jiffie += 2*DITLEN;
+			}
+			bufpos ++;
+			
+			return;
+		}
+
+		if (*morsepos == '.') {
+			if (blink_setting & 0x02)
+				kd_mksound(FREQ, DITLEN);
+			next_jiffie = jiffies + DITLEN;
+			do_blink(1);
+			state = 1;
+			morsepos++;
+			return;
+		} else if (*morsepos == '-') {
+			if (blink_setting & 0x02)
+				kd_mksound(FREQ, DAHLEN);
+			next_jiffie = jiffies + DAHLEN;
+			do_blink(1);
+			state = 1;
+			morsepos++;
+			return;
+		}
+
+		/*impossible*/
+		morsepos = 0;
+
 	}
+	
 }  
 
 static int __init panicblink_setup(char *str)
 {
     int par;
     if (get_option(&str,&par)) 
-	    blink_frequency = par*(1000/HZ);
+	    blink_setting = par;
     return 1;
 }
 
diff -u -r -d linux.old/kernel/panic.c linux/kernel/panic.c
--- linux.old/kernel/panic.c	Fri Jul 19 00:59:04 2002
+++ linux/kernel/panic.c	Thu Jul 18 21:45:45 2002
@@ -97,8 +97,8 @@
 	sti();
 	for(;;) {
 #if defined(__i386__) && defined(CONFIG_VT) 
-		extern void panic_blink(void);
-		panic_blink(); 
+		extern void panic_blink(char * buf);
+		panic_blink(buf); 
 #endif
 		CHECK_EMERGENCY_SYNC
 	}

Re: [PATCH -ac] Panicking in morse code

[William Lee Irwin III]

On Fri, Jul 19, 2002 at 01:13:00AM -0400, Andrew Rodland wrote:
> No, it's not 1 April.
> I was researching panic_blink() for someone who needed a little help,
> when I noticed the comment above the function definition, not being the
> kind to step down from a challenge (unless it's just really hard), I
> decided to write morse code output code.

This is far more amusing than any of the April 1st Linus impersonations.

Good show!


Cheers,
Bill

Re: [PATCH -ac] Panicking in morse code

[Thorsten Kranzkowski]

On Fri, Jul 19, 2002 at 01:13:00AM -0400, Andrew Rodland wrote:
> I was researching panic_blink() for someone who needed a little help,
> when I noticed the comment above the function definition, not being the
> kind to step down from a challenge (unless it's just really hard), I
> decided to write morse code output code.

nice idea :)

> diff -u -r -d linux.old/drivers/char/pc_keyb.c linux/drivers/char/pc_keyb.c
> --- linux.old/drivers/char/pc_keyb.c	Fri Jul 19 00:59:04 2002
> +++ linux/drivers/char/pc_keyb.c	Fri Jul 19 01:00:34 2002
> @@ -1244,37 +1244,126 @@
>  #endif /* CONFIG_PSMOUSE */

[...]

> +static const char * morse[] = {
> +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> +	"..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */

This should read:

	"..", ".---", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */

i.e. there's a dot too much :)

> +	"--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> +	"-.--", "--..",	 	 	 	 	 	 /* Y-Z */
> +	"-----", ".----", "..---", "...--", "....-",	 	 /* 0-4 */
> +	".....", "-....", "--...", "---..", "----."	 	 /* 5-9 */
> +};

73, Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: [PATCH -ac] Panicking in morse code

[Andrew Rodland]

On Fri, 19 Jul 2002 16:36:55 +0000
Thorsten Kranzkowski <dl8bcu@dl8bcu.de> wrote:

> On Fri, Jul 19, 2002 at 01:13:00AM -0400, Andrew Rodland wrote:
> > I was researching panic_blink() for someone who needed a little
> > help, when I noticed the comment above the function definition, not
> > being the kind to step down from a challenge (unless it's just
> > really hard), I decided to write morse code output code.
> 
> nice idea :)
> 
> > diff -u -r -d linux.old/drivers/char/pc_keyb.c
> > linux/drivers/char/pc_keyb.c--- linux.old/drivers/char/pc_keyb.c	Fri Jul 19 00:59:04 2002
> > +++ linux/drivers/char/pc_keyb.c	Fri Jul 19 01:00:34 2002
> > @@ -1244,37 +1244,126 @@
> >  #endif /* CONFIG_PSMOUSE */
> 
> [...]
> 
> > +static const char * morse[] = {
> > +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H
> > */+	"..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P
> > */
> 
> This should read:
> 
> 	"..", ".---", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P
> 	*/
> 
> i.e. there's a dot too much :)
> 

Thank you. Fixed locally.
Since you seem to be something of a morse-wiz (the only letters I know
by heart are 'S', 'O', and 'S'), could you either make corrections on
my timings (ditlen, dahlen, inter-letter space, inter-word space), or
tell me that they're good?

--Andrew

P.S. Yes, in case anyone is wondering, I did create a module that does
nothing but generate a user-supplied panic. :)

Re: [PATCH -ac] Panicking in morse code

[Eli Carter]

Andrew Rodland wrote:
[snip]
> --Andrew
> 
> P.S. Yes, in case anyone is wondering, I did create a module that does
> nothing but generate a user-supplied panic. :)

*ROTFL*  Actually, I can see that being useful for testing...  I fear 
you have tweaked my curiosity to see that particular implementation. :)

Oh, the fun of getting someone to feed that patch to Linus... *grin*

*giggle*

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: [PATCH -ac] Panicking in morse code

[Andrew Rodland]

On Fri, 19 Jul 2002 12:27:51 -0500
Eli Carter <eli.carter@inet.com> wrote:

> Andrew Rodland wrote:
> [snip]
> > --Andrew
> > 
> > P.S. Yes, in case anyone is wondering, I did create a module that
> > does nothing but generate a user-supplied panic. :)
> 
> *ROTFL*  Actually, I can see that being useful for testing...  I fear 
> you have tweaked my curiosity to see that particular implementation.
> :)
> 

Actually, it was pretty simple. It was also my first module ever.
I had a lot of fun writing all of this stuff, but people keep
indicating that maybe some of it could actually be useful. If that's
the case, so much the better.

panictest.c follows.

--cut--

#define __KERNEL__
#define MODULE

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

static char *string = "SOS SOS SOS";

int __init panic_init(void) {
	panic(string);
}
	
module_init(panic_init);
MODULE_LICENSE("GPL");
MODULE_PARM(string, "s");
MODULE_PARM_DESC(string, "The string to panic with.");

Re: [PATCH -ac] Panicking in morse code, v2

[Andrew Rodland]

Thanks a million to the unnamed linux<AT>horizon.com for some great
suggestions/info. v2 of the morse-panic patch features better
punctuation handling, proper morse-like timings, and something like 1/5
the static data requirement, thanks to the varicode algo that I
couldn't come up with myself. :)

Patch follows.

diff -u -r linux.old/drivers/char/pc_keyb.c linux.new/drivers/char/pc_keyb.c
--- linux.old/drivers/char/pc_keyb.c	Fri Jul 19 18:56:36 2002
+++ linux.new/drivers/char/pc_keyb.c	Fri Jul 19 18:54:17 2002
@@ -1244,29 +1244,131 @@
 #endif /* CONFIG_PSMOUSE */
 
 
-static int blink_frequency = HZ/2;
+static int blink_setting = 1;
 
 /* Tell the user who may be running in X and not see the console that we have 
    panic'ed. 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.  */ 
-void panic_blink(void)
-{ 
-	static unsigned long last_jiffie;
-	static char led;
-	/* Roughly 1/2s frequency. KDB uses about 1s. Make sure it is 
-	   different. */
-	if (!blink_frequency) 
-		return;
-	if (jiffies - last_jiffie > blink_frequency) {
-		led ^= 0x01 | 0x04;
+   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.
+*/ 
+
+static const char morsetable[] = {
+	/*	 .-   -... -.-. -..  .    ..-. --.  .... .. */
+		 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 */
+
+	077, 076, 074, 070, 060, 040, 041, 043, 047, 057 	 /* 0-9 */
+};
+
+
+#define DITLEN (HZ / 5)
+#define DAHLEN 3 * DITLEN
+#define SPACELEN 7 * DITLEN
+
+#define FREQ 844
+
+static __inline__ void do_blink (int led) {
+
+		if (! blink_setting & 0x01)
+			return;
+		
+		led = led ? (0x01 | 0x04) : 0x00;
+
 		while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); 
 		kbd_write_output(KBD_CMD_SET_LEDS);
 		mdelay(1); 
 		while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); 
 		mdelay(1); 
 		kbd_write_output(led);
-		last_jiffie = jiffies;
+}
+
+void panic_blink(char * buf)
+{ 
+	static unsigned long next_jiffie = 0;
+	static char * bufpos = 0;
+	static char morse = 0;
+	static char state;
+	
+	if (!blink_setting) 
+		return;
+
+	if (!buf)
+		buf="Panic lost?";
+
+
+	if (jiffies >= next_jiffie || !bufpos) { //messy. fix.
+		
+		if (state) {
+			do_blink(0);
+			state = 0;
+			next_jiffie = jiffies + DITLEN;
+			return;
+		}
+
+		if (!bufpos) {
+			bufpos = (char *)buf;
+			return;
+		}
+
+	
+		if (morse <=1 ) { /* Many thanks for the clever scheme, horizon! */
+			if (!*bufpos) { /*Repeat the message */ 
+				bufpos = (char *)buf;
+				next_jiffie = jiffies + 3 * DAHLEN;
+				return;
+			}
+
+			next_jiffie = jiffies + 3*DITLEN;
+
+			if (*bufpos >= 'A' && *bufpos <= 'Z') {
+				morse = morsetable[*bufpos - 'A'];
+			} else if (*bufpos >= 'a' && *bufpos <= 'z') {
+				morse = morsetable[*bufpos - 'a'];
+			} else if (*bufpos >= '0' && *bufpos <= '9') {
+				morse = morsetable[*bufpos - '0' + 26];
+			} else {
+				switch (*bufpos) {
+					case '/': morse = 0051; break; /* -..-.  */
+					case '=': morse = 0061; break; /* -...-  */
+					case '.': morse = 0152; break; /* .-.-.- */
+					case '?': morse = 0114; break; /* ..--.. */
+					case ',': morse = 0163; break; /* --..-- */
+					case '-': morse = 0141; break; /* -....- */
+					case '\'':morse = 0136; break; /* .----. */
+					case '"': morse = 0122; break; /* .-..-. */
+					case ':': morse = 0107; break; /* ---... */
+					default : /* Space */
+								 next_jiffie += 4*DITLEN; /*For a total of 7*/
+				}
+			}
+			bufpos ++;
+			return;
+		}
+
+		if (morse & 001) {
+			if (blink_setting & 0x02)
+				kd_mksound(FREQ, DAHLEN);
+			next_jiffie = jiffies + DAHLEN;
+			do_blink(1);
+			state = 1;
+			morse >>= 1;
+			return;
+		} else {
+			if (blink_setting & 0x02)
+				kd_mksound(FREQ, DITLEN);
+			next_jiffie = jiffies + DITLEN;
+			do_blink(1);
+			state = 1;
+			morse >>= 1;
+			return;
+		}
+		/*impossible*/
 	}
 }  
 
@@ -1274,7 +1376,7 @@
 {
     int par;
     if (get_option(&str,&par)) 
-	    blink_frequency = par*(1000/HZ);
+	    blink_setting = par;
     return 1;
 }
 
diff -u -r linux.old/kernel/panic.c linux.new/kernel/panic.c
--- linux.old/kernel/panic.c	Fri Jul 19 18:56:36 2002
+++ linux.new/kernel/panic.c	Thu Jul 18 21:45:45 2002
@@ -97,8 +97,8 @@
 	sti();
 	for(;;) {
 #if defined(__i386__) && defined(CONFIG_VT) 
-		extern void panic_blink(void);
-		panic_blink(); 
+		extern void panic_blink(char * buf);
+		panic_blink(buf); 
 #endif
 		CHECK_EMERGENCY_SYNC
 	}

Re: [PATCH -ac] Panicking in morse code

[Alan Cox]

> +static const char * morse[] = {
> +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> +	"..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> +	"--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> +	"-.--", "--..",	 	 	 	 	 	 /* Y-Z */
> +	"-----", ".----", "..---", "...--", "....-",	 	 /* 0-4 */
> +	".....", "-....", "--...", "---..", "----."	 	 /* 5-9 */

How about using bitmasks here. Say top five bits being the length, lower
5 bits being 1 for dash 0 for dit ?


But very nice

Re: [PATCH -ac] Panicking in morse code

[Andrew Rodland]

On Fri, 19 Jul 2002 20:35:15 -0400 (EDT)
Alan Cox <alan@redhat.com> wrote:

> > +static const char * morse[] = {
> > +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H
> > */+	"..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P
> > */+	"--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X
> > */+	"-.--", "--..",	 	 	 	 	 	 /* Y-Z
> > */+	"-----", ".----", "..---", "...--", "....-",	 	 /* 0-4 */
> > +	".....", "-....", "--...", "---..", "----."	 	 /* 5-9 */
> 
> How about using bitmasks here. Say top five bits being the length,
> lower 5 bits being 1 for dash 0 for dit ?
> 
v2 uses an algorithm suggested to me in private that allows you to fit
7 bits of morse into 8 bits. Very clever method.

> 
> But very nice
> 

Thanks. :)

Re: [PATCH -ac] Panicking in morse code

[Thunder from the hill]

Hi,

On Fri, 19 Jul 2002, Alan Cox wrote:
> How about using bitmasks here. Say top five bits being the length, lower
> 5 bits being 1 for dash 0 for dit ?

Just have a look at his latest solution.

							Regards,
							Thunder
-- 
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o?  K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y- 
------END GEEK CODE BLOCK------

Re: [PATCH -ac] Panicking in morse code, v2

[Daniel Phillips]

Nice joke.  Unfortunately, this code is too useful to ignore.  I distinctly 
remember finding myself in the position of having completed the firmware of 
an embedded device without properly recording the correspondence of led blink 
patterns to error codes, the result being that if the firmware had ever failed
(luckily it never did) nobody would have been quite sure why.  How much more 
useful, satisfying and stylish to have encoded the failure messages in morse.

On Saturday 20 July 2002 01:02, Andrew Rodland wrote:
> Thanks a million to the unnamed linux<AT>horizon.com for some great
> suggestions/info. v2 of the morse-panic patch features better
> punctuation handling, proper morse-like timings, and something like 1/5
> the static data requirement, thanks to the varicode algo that I
> couldn't come up with myself. :)

Indeed, that one had me scratching my head, even with the code in front of 
me.  Let me describe the encoding method for the benefit of anybody not 
energetic or foolish enough to puzzle it out for themselves:

  - The sequence is encoded from low bit to high, zero=dit, one=dah

  - The sequence always terminates with a one=dah, which is dropped,
    followed by an infinite string of zeros.

The infinite string of zeros is shifted in from the top of the byte, hence 
the terminating condition morse <= 1, which prudently covers the impossible 
case of morse == 0.

This deserves a comment.

Note that there is a bug waiting to bite: you need to declare morse as 
unsigned char, otherwise you will be unable to make good on your claim that 
up to 7 morse bits can be encoded.

-- 
Daniel

Re: [PATCH -ac] Panicking in morse code, v2

[Thunder from the hill]

Hi,

On Sat, 20 Jul 2002, Daniel Phillips wrote:
> Unfortunately, this code is too useful to ignore.

I think it's also a nice-to-have for 2.5.

							Regards,
							Thunder
-- 
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o?  K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y- 
------END GEEK CODE BLOCK------

Re: [PATCH -ac] Panicking in morse code, v2

[Ville Herva]

On Sat, Jul 20, 2002 at 05:19:13AM -0600, you [Thunder from the hill] wrote:
> Hi,
> 
> On Sat, 20 Jul 2002, Daniel Phillips wrote:
> > Unfortunately, this code is too useful to ignore.
> 
> I think it's also a nice-to-have for 2.5.

Okay, maybe it's just me being too lazy and ignorant to teach myself morse
code, but I'd advocate ksmgdump by Willy Tarreau instead
(http://miaif.lip6.fr/~tarreau/kmsgdump/) - it lets you save the oops to a
floppy or print it. ;)

And it does beep and blink the leds which seems a minimum requirement for a
basic bell-and-a-whistle feature these days...


-- v --

v@iki.fi

Re: [PATCH -ac] Panicking in morse code, v2

[Daniel Phillips]

On Saturday 20 July 2002 15:22, Ville Herva wrote:
> On Sat, Jul 20, 2002 at 05:19:13AM -0600, you [Thunder from the hill] wrote:
> > Hi,
> > 
> > On Sat, 20 Jul 2002, Daniel Phillips wrote:
> > > Unfortunately, this code is too useful to ignore.
> > 
> > I think it's also a nice-to-have for 2.5.
> 
> Okay, maybe it's just me being too lazy and ignorant to teach myself morse
> code...

Then teach it to a script, call it "unmorse" ;-)

	echo dit dit dit dah dah dah dit dit dit | unmorse

-- 
Daniel

Re: [PATCH -ac] Panicking in morse code, v2

[Tomas Szepe]

> > > Hi,
> > > 
> > > On Sat, 20 Jul 2002, Daniel Phillips wrote:
> > > > Unfortunately, this code is too useful to ignore.
> > > 
> > > I think it's also a nice-to-have for 2.5.
> > 
> > Okay, maybe it's just me being too lazy and ignorant to teach myself morse
> > code...
> 
> Then teach it to a script, call it "unmorse" ;-)
> 
> 	echo dit dit dit dah dah dah dit dit dit | unmorse

Try this on for size:


/*  dorssel.c, 1998 IOCCC entry
 *  Frans van Dorsselaer <frans@biabv.com>
 */

#include<stdio.h>
#include<string.h>

main()
{
	char*O,l[999]="'`acgo\177~|xp .-\0R^8)NJ6%K4O+A2M(*0ID57$3G1FBL";
	while(O=fgets(l+45,954,stdin)){
		*l=O[strlen(O)[O-1]=0,strspn(O,l+11)];
		while(*O)switch((*l&&isalnum(*O))-!*l){
		case-1:{char*I=(O+=strspn(O,l+12)+1)-2,O=34;
			while(*I&3&&(O=(O-16<<1)+*I---'-')<80);
			putchar(O&93?*I&8||!(I=memchr(l,O,44))?'?':I-l+47:32);
			break;
		case 1:	;}*l=(*O&31)[l-15+(*O>61)*32];
			while(putchar(45+*l%2),(*l=*l+32>>1)>35);
		case 0:	putchar((++O,32));}
	putchar(10);}
}

Re: [PATCH -ac] Panicking in morse code, v2

[Daniel Phillips]

On Saturday 20 July 2002 16:55, Tomas Szepe wrote:
> Try this on for size:

Gosh, that's hard to read with all those indents...

While I realize how painful it would be to ignore the fact that '.' and '-' 
are adjacent ascii codes, actually '_' makes it look more authentic.

By the way, you are demented ;-)

-- 
Daniel

Re: [PATCH -ac] Panicking in morse code, v2

[Thunder from the hill]

.... ..

On Sat, 20 Jul 2002, Ville Herva wrote:
> Okay, maybe it's just me being too lazy and ignorant to teach myself morse
> code

..  .-- --- ..- .-.. -..  .-.. --- ...- .  .. -
.-.. .- - . .-.. -.--  .. -  .. ...  ... --- -- .  ... .- -. .  - .... .. 
-. --.  - ---  -.. ---  .-- .. - ....  -.-- --- ..- .-.  --- --- .--. ...

					.-. . --. .- .-. -.. ...,
					- .... ..- -. -.. . .-.
-- 
(..- ... .  .... - - .--.://.-- .-- .-- . . -... -... . --- .-. --. 
/ ..- -. --. . . -.- .. ..-.  -.-- --- ..-  -.-. .- -. -. --- -  -.. . 
-.-. --- -.. .)
------ -... . --. .. -.  --. . . -.-  -.-. --- -.. .  -... .-.. --- -.-. 
-.- ------
...- . .-. ... .. --- -. : ...-- . .---- ..---
--././--./.../.- - -.. - ... ++:-- .-? -.-.++$ ..- .-.. .- ...- .... 
..++++$ .--.++$ .-..++++(+++++)$ . .-- -$
-. --- ---?  -.-? .-- -- --- - -- ...-$ .--. ...+ .--. . - -.-- - .--. 
--. .--.+ -+ .....+ -..-+ .-. - !- ...- -...++ -.. ..? !-.. --.
.++++ ....* .-. --- -.-- - 
------ . -. -..  --. . . -.-  -.-. --- -.. .  -... .-.. --- -.-. -.- 
------

Re: [PATCH -ac] Panicking in morse code v3

[Andrew Rodland]

Once more Mr. unnamed sent me some suggestions, and once more I've
merged [my own adaptation of] them in. Also, I took an attempt to make
it somewhat more platform-independent, and re-organize. The original
panic_blink was in pc_keyb.c, and was guarded by an #ifdef __i386__ .
v3 moves the generic code out of pc_keyb (and into panic.c). It should
be able to blink on anything that uses pc_keyb (i386, some ARM, and
some MIPS, apparently), and should be able to beep on anything that
defines kd_mksound to do something (currently only i386). Also the code
has been reorganized so as to be easier to read and follow, and there
are a few more punctuation characters.

Yes, I actually _am_ trying to turn this into something useful.
Now, I don't have a 2.5 tree, and probably wouldn't understand it if I
did, but I get a feeling that this won't be so incredibly easy to port,
thanks to having everything use the input layer. Or am I wrong?

--hobbs

Patch follows

diff -u -r linux.old/drivers/char/pc_keyb.c linux.new/drivers/char/pc_keyb.c
--- linux.old/drivers/char/pc_keyb.c	Fri Jul 19 18:56:36 2002
+++ linux.new/drivers/char/pc_keyb.c	Sat Jul 20 13:18:40 2002
@@ -1244,41 +1244,13 @@
 #endif /* CONFIG_PSMOUSE */
 
 
-static int blink_frequency = HZ/2;
+void pckbd_blink (char led) {
+		led = led ? (0x01 | 0x04) : 0x00;
 
-/* Tell the user who may be running in X and not see the console that we have 
-   panic'ed. 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.  */ 
-void panic_blink(void)
-{ 
-	static unsigned long last_jiffie;
-	static char led;
-	/* Roughly 1/2s frequency. KDB uses about 1s. Make sure it is 
-	   different. */
-	if (!blink_frequency) 
-		return;
-	if (jiffies - last_jiffie > blink_frequency) {
-		led ^= 0x01 | 0x04;
 		while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); 
 		kbd_write_output(KBD_CMD_SET_LEDS);
 		mdelay(1); 
 		while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); 
 		mdelay(1); 
 		kbd_write_output(led);
-		last_jiffie = jiffies;
-	}
-}  
-
-static int __init panicblink_setup(char *str)
-{
-    int par;
-    if (get_option(&str,&par)) 
-	    blink_frequency = par*(1000/HZ);
-    return 1;
 }
-
-/* panicblink=0 disables the blinking as it caused problems with some console
-   switches. otherwise argument is ms of a blink period. */
-__setup("panicblink=", panicblink_setup);
-
diff -u -r linux.old/kernel/panic.c linux.new/kernel/panic.c
--- linux.old/kernel/panic.c	Fri Jul 19 18:56:36 2002
+++ linux.new/kernel/panic.c	Sat Jul 20 17:28:41 2002
@@ -16,6 +16,8 @@
 #include <linux/init.h>
 #include <linux/sysrq.h>
 #include <linux/interrupt.h>
+#include <linux/vt_kern.h>
+#include <linux/pc_keyb.h>
 
 asmlinkage void sys_sync(void);	/* it's really int */
 
@@ -28,9 +30,132 @@
 	panic_timeout = simple_strtoul(str, NULL, 0);
 	return 1;
 }
-
 __setup("panic=", panic_setup);
 
+static int blink_setting = 1;
+
+/* Tell the user who may be running in X and not see the console that we have 
+   panic'ed. 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.
+*/ 
+
+static const unsigned char morsetable[] = {
+	/*  !   "    #  $     %  &    '	 	 */
+	    0, 0122, 0, 0310, 0, 0, 0163,
+	/*  (       )  *  +    ,     -    .      /	 */
+	    055, 0155, 0, 0, 0163, 0141, 0152, 0051,
+	/* 0-9 */
+	    077, 076, 074, 070, 060, 040, 041, 043, 047, 057,
+	/*  :     ;     <   =    >   ?    @  */
+	    0107, 0125, 0, 0061, 0, 0114, 0,
+	/* A-I */
+	   006, 021, 025, 011, 002, 024, 013, 020, 004,
+	/* J-R */
+	   036, 015, 022, 007, 005, 017, 026, 033, 012,
+	/* S-Z */
+	   010, 003, 014, 030, 016, 031, 035, 023,
+	/* [  \  ]  ^  */
+	   0, 0, 0, 0,
+	/* _ */
+	   0154
+
+};
+
+#define DITLEN (HZ / 5)
+#define DAHLEN 3 * DITLEN
+#define SPACELEN 7 * DITLEN
+
+#define FREQ 844
+
+
+#if (defined(__i386__) && defined(CONFIG_VT)) || defined(CONFIG_PC_KEYB)
+#define do_blink(x) pckbd_blink(x)
+#else
+#define do_blink(x) 0
+#endif
+
+void panic_blink(char * buf)
+{ 
+	static unsigned long next_jiffie = 0;
+	static char * bufpos = 0;
+	static unsigned char morse = 0;
+	static char state = 1;
+	
+	if (!blink_setting) 
+		return;
+
+	if (!buf)
+		buf="Panic lost?";
+
+
+	if (bufpos && time_after (next_jiffie, jiffies)) {
+		return; /* Waiting for something. */
+	}
+
+	if (state) { /* Coming off of a blink. */
+		if (blink_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, and figure out how much space. */
+			
+			if(!bufpos)
+				bufpos = (char *)buf; /* First time through */
+
+			if(!*bufpos) {
+				bufpos = (char *)buf; /* Repeating */
+				next_jiffie = jiffies + SPACELEN;
+			} else {
+				next_jiffie = jiffies + DAHLEN; /* Inter-letter space */
+			}
+
+			if (*bufpos >= '!' && *bufpos <= '_') {
+				morse = morsetable[*bufpos - '!'];
+			} else if (*bufpos >= 'a' && *bufpos <= 'z') {
+				morse = morsetable[*bufpos - 'a' + 'A' - '!'];
+			} else {
+				next_jiffie = jiffies + SPACELEN; /*Space -- For a total of 7*/
+				state = 1; /* And bring us back here when we're done */
+			}
+			bufpos ++;
+		}
+	} else { /* Starting a new blink. We have valid code in morse. */
+		int len;
+
+		len = (morse & 001) ? DAHLEN : DITLEN;
+
+		if (blink_setting & 0x02)
+			kd_mksound(FREQ, len);
+		
+		next_jiffie = jiffies + len;
+
+		if (blink_setting & 0x01)
+			do_blink(1);
+		state = 1;
+		morse >>= 1;
+	}
+}  
+
+static int __init panicblink_setup(char *str)
+{
+    int par;
+    if (get_option(&str,&par)) 
+	    blink_setting = par;
+    return 1;
+}
+
+/* panicblink=0 disables the blinking as it caused problems with some console
+   switches. otherwise argument is ms of a blink period. */
+__setup("panicblink=", panicblink_setup);
+
+
 /**
  *	panic - halt the system
  *	@fmt: The text string to print
@@ -96,10 +221,7 @@
 #endif
 	sti();
 	for(;;) {
-#if defined(__i386__) && defined(CONFIG_VT) 
-		extern void panic_blink(void);
-		panic_blink(); 
-#endif
+		panic_blink(buf); 
 		CHECK_EMERGENCY_SYNC
 	}
 }

Re: [PATCH -ac] Panicking in morse code v3

[Brad Hards]

On Sun, 21 Jul 2002 07:32, Andrew Rodland wrote:
> Yes, I actually _am_ trying to turn this into something useful.
> Now, I don't have a 2.5 tree, and probably wouldn't understand it if I
> did, but I get a feeling that this won't be so incredibly easy to port,
> thanks to having everything use the input layer. Or am I wrong?

While it will be non-trivial, it won't be hard either.
The advantage of the input layer is that it no longer matters what
type of keyboard is attached - you can just call input_event() and
turn on and off the LED. The input layer abstracts out the magic
values needed for any particular keyboard.

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: [PATCH -ac] Panicking in morse code v3

[Russell King]

On Sun, Jul 21, 2002 at 06:49:55PM +1000, Brad Hards wrote:
> While it will be non-trivial, it won't be hard either.
> The advantage of the input layer is that it no longer matters what
> type of keyboard is attached - you can just call input_event() and
> turn on and off the LED. The input layer abstracts out the magic
> values needed for any particular keyboard.

Hmm.  I thought the original idea for the "flash LEDs on panic" was
so you knew something had gone wrong early in the boot, at the kind
of places where you don't have a console initialised.  If you don't
have the console initialised, you sure as hell don't have the input
layer or keyboard drivers initialised.

Otherwise it becomes a "toy" feature that doesn't have much value.
What would be more useful would be to disable the console blank
timer on a panic() so it doesn't blank half-way through someone
reading the oops, leaving them with no way to read the rest of it!

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH -ac] Panicking in morse code v3

[Zwane Mwaikambo]

On Sun, 21 Jul 2002, Russell King wrote:

> Otherwise it becomes a "toy" feature that doesn't have much value.
> What would be more useful would be to disable the console blank
> timer on a panic() so it doesn't blank half-way through someone
> reading the oops, leaving them with no way to read the rest of it!

I actually thought of that last night when it happened whilst examining an 
oops.

--- linux-2.5.25/kernel/panic.c.orig	Sun Jul 21 12:45:56 2002
+++ linux-2.5.25/kernel/panic.c	Sun Jul 21 12:09:42 2002
@@ -49,6 +49,9 @@
         unsigned long caller = (unsigned long) __builtin_return_address(0);
 #endif
 
+#ifdef CONFIG_VT
+	disable_console_blank();
+#endif
 	bust_spinlocks(1);
 	va_start(args, fmt);
 	vsprintf(buf, fmt, args);
--- linux-2.5.25/drivers/char/console.c.orig	Sun Jul 21 12:46:18 2002
+++ linux-2.5.25/drivers/char/console.c	Sun Jul 21 12:24:31 2002
@@ -2758,6 +2758,12 @@
 	timer_do_blank_screen(0, 1);
 }
 
+void disable_console_blank(void)
+{
+	del_timer_sync(&console_timer);
+	blankinterval = 0;
+}
+
 void poke_blanked_console(void)
 {
 	del_timer(&console_timer);
--- linux-2.5.25/include/linux/console.h.orig	Sun Jul 21 12:47:01 2002
+++ linux-2.5.25/include/linux/console.h	Sun Jul 21 12:25:42 2002
@@ -112,6 +112,7 @@
 extern void release_console_sem(void);
 extern void console_conditional_schedule(void);
 extern void console_unblank(void);
+extern void disable_console_blank(void);
 
 /* VESA Blanking Levels */
 #define VESA_NO_BLANKING        0

-- 
function.linuxpower.ca

Re: [PATCH -ac] Panicking in morse code v3

[Daniel Phillips]

Here's my contribution to the ongoing beautification:

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				/* [\]^_ */
};

unsigned char tomorse(char c)
{
	return c >= '"' && c <= '_'? morsetable[c - '"']: 0;
}

used as:

+			if (!(morse = tomorse(toupper(*bufpos)))) {
+                               next_jiffie = jiffies + SPACELEN; /*Space -- For a total of 7*/
+                               state = 1; /* And bring us back here when we're done */
+                       }

-- 
Daniel

Re: [PATCH -ac] Panicking in morse code v3

[Andrew Rodland]

On Sun, 21 Jul 2002 17:43:42 +0200
Daniel Phillips <phillips@arcor.de> wrote:

> Here's my contribution to the ongoing beautification:
> 
> [snip patch]

Nice. Thanks. Merged in spirit, if not letter. :)
I suppose I should start putting this up on a webpage instead of
bothering the list every time there's an improvement.

Re: [PATCH -ac] Panicking in morse code

[Bill Davidsen]

On Fri, 19 Jul 2002, Alan Cox wrote:

> > +static const char * morse[] = {
> > +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > +	"..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> > +	"--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> > +	"-.--", "--..",	 	 	 	 	 	 /* Y-Z */
> > +	"-----", ".----", "..---", "...--", "....-",	 	 /* 0-4 */
> > +	".....", "-....", "--...", "---..", "----."	 	 /* 5-9 */
> 
> How about using bitmasks here. Say top five bits being the length, lower
> 5 bits being 1 for dash 0 for dit ?

??? If the length is 1..5 I suspect you could use the top two bits and fit
the whole thing in a byte. But since bytes work well, use the top three
bits for length without the one bit offset. Still a big win over strings,
although a LOT harder to get right by eye.

I want to see this go to the sound card, so that when the admins are in
the ready room drinking coffee and listening to mp3s over the speakers
they will "get the message." Actually one guys says he can read morse in
his sleep, when he's "studying a manual" head down we might see about
that;-)

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

Re: [PATCH -ac] Panicking in morse code

[Daniel Phillips]

On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> On Fri, 19 Jul 2002, Alan Cox wrote:
> 
> > > +static const char * morse[] = {
> > > +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > > +	"..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> > > +	"--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> > > +	"-.--", "--..",	 	 	 	 	 	 /* Y-Z */
> > > +	"-----", ".----", "..---", "...--", "....-",	 	 /* 0-4 */
> > > +	".....", "-....", "--...", "---..", "----."	 	 /* 5-9 */
> > 
> > How about using bitmasks here. Say top five bits being the length, lower
> > 5 bits being 1 for dash 0 for dit ?
> 
> ??? If the length is 1..5 I suspect you could use the top two bits and fit
> the whole thing in a byte. But since bytes work well, use the top three
> bits for length without the one bit offset. Still a big win over strings,
> although a LOT harder to get right by eye.

Please read back through the thread and see how 255 different 7 bit codes
complete with lengths can be packed into 8 bits.

-- 
Daniel

Re: [PATCH -ac] Panicking in morse code

[Daniel Phillips]

On Friday 26 July 2002 05:43, Daniel Phillips wrote:
> Please read back through the thread and see how 255 different 7 bit codes
> complete with lengths can be packed into 8 bits.

Err, make that 'binary code strings up to 7 bits in length'.

-- 
Daniel

Re: [PATCH -ac] Panicking in morse code

[jdow]

From: "Daniel Phillips" <phillips@arcor.de>

> On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > On Fri, 19 Jul 2002, Alan Cox wrote:
> >
> > > > +static const char * morse[] = {
> > > > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > > > + "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> > > > + "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> > > > + "-.--", "--..", /* Y-Z */
> > > > + "-----", ".----", "..---", "...--", "....-", /* 0-4 */
> > > > + ".....", "-....", "--...", "---..", "----." /* 5-9 */
> > >
> > > How about using bitmasks here. Say top five bits being the length,
lower
> > > 5 bits being 1 for dash 0 for dit ?
> >
> > ??? If the length is 1..5 I suspect you could use the top two bits and
fit
> > the whole thing in a byte. But since bytes work well, use the top three
> > bits for length without the one bit offset. Still a big win over
strings,
> > although a LOT harder to get right by eye.
>
> Please read back through the thread and see how 255 different 7 bit codes
> complete with lengths can be packed into 8 bits.

It appears someone is under the misapprehension that Morse characters are
all 5 elements or less. "SK" is an example of a six element meta-character,
one of a set that needs caring for, "...-.-".

(Gawd I wish I could forget that silly communications mode. <sigh>)

{^_^}    W6MKU (Color me a spread-spectrum maven.)

Re: [PATCH -ac] Panicking in morse code

[Daniel Phillips]

On Friday 26 July 2002 06:52, jdow wrote:
> From: "Daniel Phillips" <phillips@arcor.de>
> > On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > > the whole thing in a byte. But since bytes work well, use the top three
> > > bits for length without the one bit offset. Still a big win over strings,
> > > although a LOT harder to get right by eye.
> >
> > Please read back through the thread and see how 255 different 7 bit codes
> > complete with lengths can be packed into 8 bits.
> 
> It appears someone is under the misapprehension that Morse characters are
> all 5 elements or less. "SK" is an example of a six element meta-character,
> one of a set that needs caring for, "...-.-".

Need I point out that we are now perfectly positioned to invent the additional
morse codes needed to represent all the remaining ascii characters?  We could
call the revised code... err... "remorse" ;-)

-- 
Daniel

Re: [PATCH -ac] Panicking in morse code

[Bill Davidsen]

On Fri, 26 Jul 2002, Daniel Phillips wrote:

> On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > On Fri, 19 Jul 2002, Alan Cox wrote:
> > 
> > > > +static const char * morse[] = {
> > > > +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
[...snip...]
> > > 
> > > How about using bitmasks here. Say top five bits being the length, lower
> > > 5 bits being 1 for dash 0 for dit ?
> > 
> > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > the whole thing in a byte. But since bytes work well, use the top three
> > bits for length without the one bit offset. Still a big win over strings,
> > although a LOT harder to get right by eye.
> 
> Please read back through the thread and see how 255 different 7 bit codes
> complete with lengths can be packed into 8 bits.

???
 1 - there are not 255 different 7 bit values, there are 128
 2 - morse code has a longest value of 5 elements not 7
 3 - Alan was talking about len+val representation, not stop-bit patterns,
     which is what I guess you mean

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

Re: [PATCH -ac] Panicking in morse code

[Bill Davidsen]

On Fri, 26 Jul 2002, Daniel Phillips wrote:

> Need I point out that we are now perfectly positioned to invent the additional
> morse codes needed to represent all the remaining ascii characters?  We could
> call the revised code... err... "remorse" ;-)

Were you planning on an RFC for that?

Instead of lights we might include a controller driver for those
"invisible fence"  dog collars, insuring that the administrator didn't
miss the message.

Actually, the only change I would add to the original idea is an interface
to the sound driver, since a lot of folks listen to audio via computer
during
the work day.

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

Re: [PATCH -ac] Panicking in morse code

[Richard B. Johnson]

On Fri, 26 Jul 2002, Bill Davidsen wrote:

> On Fri, 26 Jul 2002, Daniel Phillips wrote:
> 
> > On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > > On Fri, 19 Jul 2002, Alan Cox wrote:
> > > 
> > > > > +static const char * morse[] = {
> > > > > +	".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> [...snip...]
> > > > 
> > > > How about using bitmasks here. Say top five bits being the length, lower
> > > > 5 bits being 1 for dash 0 for dit ?
> > > 
> > > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > > the whole thing in a byte. But since bytes work well, use the top three
> > > bits for length without the one bit offset. Still a big win over strings,
> > > although a LOT harder to get right by eye.
> > 
> > Please read back through the thread and see how 255 different 7 bit codes
> > complete with lengths can be packed into 8 bits.
> 
> ???
>  1 - there are not 255 different 7 bit values, there are 128
>  2 - morse code has a longest value of 5 elements not 7


The '.' (also called full-stop) is 6 elements long. The ',' is also
6 elements long. For a correct implimentation, i.e., one that sounds
correct, you need to encode a 'pause' element into each symbol. This
is because the pause between Morse characters is sometimes ahead
of a character and sometimes behind a character (the pause is ahead
of characters starting with a dot and after characters ending with a
dot, including characters of all dots -- except for numbers, which
have pauses after them). In a previously life, I had to develop
the correct "fist" to pass the Socond Class Radio Telegraph License.

This means that it is probably best to use one 8-byte character
for each Morse-code character.

If anybody's interested I have some DOS assembly circa 1987 that
did this stuff. It ignored the correct "fist", and has spaces after
each character. It doesn't sound too bad.

>  3 - Alan was talking about len+val representation, not stop-bit patterns,
>      which is what I guess you mean

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: [PATCH -ac] Panicking in morse code

[Bill Davidsen]

On Fri, 26 Jul 2002, Richard B. Johnson wrote:

> The '.' (also called full-stop) is 6 elements long. The ',' is also
> 6 elements long. For a correct implimentation, i.e., one that sounds
> correct, you need to encode a 'pause' element into each symbol. This
> is because the pause between Morse characters is sometimes ahead
> of a character and sometimes behind a character (the pause is ahead
> of characters starting with a dot and after characters ending with a
> dot, including characters of all dots -- except for numbers, which
> have pauses after them). In a previously life, I had to develop
> the correct "fist" to pass the Socond Class Radio Telegraph License.

I had forgotten that, haven't used code in decades, and while I doubt
there will be many of those characters in a panic message (might use !
tho) best to have them.

Unless there are exceptions to the nice rules you present, no need to
encode the pause, just apply your rules to it. Hard to fit dot, dash, and
pause in a single bit in any case.

> This means that it is probably best to use one 8-byte character
> for each Morse-code character.

Clearly, if only to avoid complex code. This looks seriously neat!

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

Re: [PATCH -ac] Panicking in morse code

[Jens Schmidt]

Hi to all,
I am not a "morse" guy myself, but appreciate this idea.
Here is what I dug out, (Google and my handbooks)

 International Morse Code

   Letter Morse     Letter Morse    Digit Morse
   A      .-        N      -.       0     -----
   B      -...      O      ---      1     .----
   C      -.-.      P      .--.     2     ..---
   D      -..       Q      --.-     3     ...--
   E      .         R      .-.      4     ....-
   F      ..-.      S      ...      5     .....
   G      --.       T      -        6     -....
   H      ....      U      ..-      7     --...
   I      ..        V      ...-     8     ---..
   J      .---      W      .--      9     ----.
   K      -.-       X      -..-
   L      .-..      Y      -.--
   M      --        Z      --..

   Punctuation Mark       Morse
   Full-stop (period)     .-.-.-
   Comma                  --..--
   Question mark (query)  ..--..
   Hyphen (-)             -....-
   Fraction bar (/)       -..-.
   Double dash (=)        -...-

   (less common)
   Brackets (parentheses) -.--.-
   Quotation marks        .-..-.
   Colon                  ---...
   Apostrophe             .----.

   Procedure codes
   Commence transmission  -.-.-   (CT)
   Wait                   .-...   (AS)
   End of message         .-.-.   (AR)
   End of work            ...-.-  (SK)
   The procedure codes are sent as a single character

  If the duration of a dot is taken to be one unit then
  that of a dash is three units.
  The space between the components of one character is one
  unit, between characters is three units and between
  words seven units.
  To indicate that a mistake has been made and for the
  receiver to delete the last word send ........ (eight dots).

Regards (73) Jens    ZL2TJT



"Richard B. Johnson" wrote:

> On Fri, 26 Jul 2002, Bill Davidsen wrote:
>
> > On Fri, 26 Jul 2002, Daniel Phillips wrote:
> >
> > > On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > > > On Fri, 19 Jul 2002, Alan Cox wrote:
> > > >
> > > > > > +static const char * morse[] = {
> > > > > > +     ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > [...snip...]
> > > > >
> > > > > How about using bitmasks here. Say top five bits being the length, lower
> > > > > 5 bits being 1 for dash 0 for dit ?
> > > >
> > > > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > > > the whole thing in a byte. But since bytes work well, use the top three
> > > > bits for length without the one bit offset. Still a big win over strings,
> > > > although a LOT harder to get right by eye.
> > >
> > > Please read back through the thread and see how 255 different 7 bit codes
> > > complete with lengths can be packed into 8 bits.
> >
> > ???
> >  1 - there are not 255 different 7 bit values, there are 128
> >  2 - morse code has a longest value of 5 elements not 7
>
> The '.' (also called full-stop) is 6 elements long. The ',' is also
> 6 elements long. For a correct implimentation, i.e., one that sounds
> correct, you need to encode a 'pause' element into each symbol. This
> is because the pause between Morse characters is sometimes ahead
> of a character and sometimes behind a character (the pause is ahead
> of characters starting with a dot and after characters ending with a
> dot, including characters of all dots -- except for numbers, which
> have pauses after them). In a previously life, I had to develop
> the correct "fist" to pass the Socond Class Radio Telegraph License.
>
> This means that it is probably best to use one 8-byte character
> for each Morse-code character.
>
> If anybody's interested I have some DOS assembly circa 1987 that
> did this stuff. It ignored the correct "fist", and has spaces after
> each character. It doesn't sound too bad.
>
> >  3 - Alan was talking about len+val representation, not stop-bit patterns,
> >      which is what I guess you mean
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
> The US military has given us many words, FUBAR, SNAFU, now ENRON.
> Yes, top management were graduates of West Point and Annapolis.
>
> -
> 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/

Re: [PATCH -ac] Panicking in morse code

[Albert D. Cahalan]

Jens Schmidt writes:

> I am not a "morse" guy myself, but appreciate this idea.

Yeah, same here. I have to wonder if morse is the
best encoding, since many people don't know it.
The vast majority of us would need a microphone and
translator program anyway, so a computer-friendly
encoding makes more sense. Modems don't do morse.

>    (less common)
>    Brackets (parentheses) -.--.-

Left/right just assumed?

>    Procedure codes
>    Commence transmission  -.-.-   (CT)
>    Wait                   .-...   (AS)
>    End of message         .-.-.   (AR)
>    End of work            ...-.-  (SK)
>    The procedure codes are sent as a single character

If morse fans actually know these, then an interpretation
for correct usage in an oops would need to be determined.

>   If the duration of a dot is taken to be one unit then
>   that of a dash is three units.
>   The space between the components of one character is one
>   unit, between characters is three units and between
>   words seven units.

The ARRL doesn't do this below 18 WPM. They use an
alternate timing (Farnsworth) that sends characters
at 18 WPM and adds extra space to slow down the result.

http://www.arrl.org/files/infoserv/tech/code-std.txt

The latest patch was doing 12 WPM. At that speed,
the ARRL would use Farnsworth timing.

>>>>>>> +static const char * morse[] = {
>>>>>>> +     ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */

Packing into bytes while still being readable:

#define o 0  // dot
#define _ 1  // dash
#define PACK(a,b,c,d,e,f,g,h) (((((((a*2+b)*2+c)*2+d)*2+e)*2+f)*2+g)*2+h)
#define M7(a,b,c,d,e,f,g) PACK(1,a,b,c,d,e,f,g)
#define M6(b,c,d,e,f,g)   PACK(0,1,b,c,d,e,f,g)
#define M5(c,d,e,f,g)     PACK(0,0,1,c,d,e,f,g)
#define M4(d,e,f,g)       PACK(0,0,0,1,d,e,f,g)
#define M3(e,f,g)         PACK(0,0,0,0,1,e,f,g)
#define M2(f,g)           PACK(0,0,0,0,0,1,f,g)
#define M1(g)             PACK(0,0,0,0,0,0,1,g)

static const u8 morse[] = {
  M2(o,_), M4(_,o,o,o), M4(_,o,_,o), M3(_,o,o),   // A B C D
  M1(o), M4(o,o,_,o), M3(_,_,o), M4(o,o,o,o),     // E F G H

I suspect it's false economy to not encode all of ASCII.
If you have all of ASCII, then the ugly switch() goes away
and all you need is a foo&0x7f to ensure things don't go
from bad to worse.

>> The '.' (also called full-stop) is 6 elements long. The ',' is also
>> 6 elements long. For a correct implimentation, i.e., one that sounds
>> correct, you need to encode a 'pause' element into each symbol. This
>> is because the pause between Morse characters is sometimes ahead
>> of a character and sometimes behind a character (the pause is ahead
>> of characters starting with a dot and after characters ending with a
>> dot, including characters of all dots -- except for numbers, which
>> have pauses after them). In a previously life, I had to develop
>> the correct "fist" to pass the Socond Class Radio Telegraph License.

If this is desirable, which I doubt, then it's best generated
by looking at the characters.

Re: [PATCH -ac] Panicking in morse code

[Andrew Rodland]

On Fri, 26 Jul 2002 22:05:03 -0400 (EDT)
"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:

> Jens Schmidt writes:
> 
> > I am not a "morse" guy myself, but appreciate this idea.
> 
> Yeah, same here. I have to wonder if morse is the
> best encoding, since many people don't know it.
> The vast majority of us would need a microphone and
> translator program anyway, so a computer-friendly
> encoding makes more sense. Modems don't do morse.

"asciimorse" would be possible, just going through the byte and doing -
for 1 and . for 0... as a matter of fact, it would probably only take
about two lines of code to get that to be an option, too. Does everyone
else think that that's really the situation? (Personally, I can't do
morse in my head. But neither do I have any oops-decoding hardware. >:)

I'll probably code it anyway. It should allow for a faster transmission
rate, anyway, since you don't have to accomodate humans. (Anyone who
can decode "asciimorse" in their head is a REAL freak. Er. no offense.)

> [some stuff on formats]
> I suspect it's false economy to not encode all of ASCII.
> If you have all of ASCII, then the ugly switch() goes away
> and all you need is a foo&0x7f to ensure things don't go
> from bad to worse.
> 

The ugly switch _is_ gone. However, all of the characters that have a
reasonable encoding are between " and Z (with the exception of
lowercase, which can be mapped onto uppercase with one line).

so current tomorse does:

if (c >= 'a' && c <= 'z') {
	c = c - 'a' + 'A'; //This could be a bit-twiddle, but why?
}
if (c >= '"' && c <= 'Z') {
	return morsetable[c - '"'];
} else {
	return 0;
}

I think this is plenty good. :)

As for Farnsworth spacing... someone provide me with proper timings
(ditlen, inter-component space, inter-letter space) for
12wpm+farnsworth and I'll code it in, if it's really that much better.
I think it's OK the way it is, but I'm one of those types who doesn't
know anything more than 'S', 'O', and 'S'. (Well, and 'E' and 'V' and
the numbers. :)

About changing the encoding: I still don't think that anything could
really be better, from a program-flow standpoint, than what we've got
now. Prove me wrong and I'll be happy.

I don't really think the pretty macros gain anything either, unless the
morse code letters are under heavy development. Last I checked, they're
not. :)

--hobbs's $0.02

Re: [PATCH -ac] Panicking in morse code

[Andrew Rodland]

No offense to anyone intended, but since this most recent discussion is
on the _original_ thread, perhaps some of you have not read the latest
"v3" version of the patch. It does make a bunch of the recent comments
irrelevant (some of the recent discussion, however, is very
interesting.)

If that thread is lost to most normal people by now, and they don't
wantto go gooja-surfing, I'll find a place on the web to put this stuff
up. 

--hobbs

Speaker twiddling [was: Re: Panicking in morse code]

[Andrew Rodland]

On Sat, 27 Jul 2002 01:26:58 -0400 (EDT)
"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:

> >> The vast majority of us would need a microphone and
> >> translator program anyway, so a computer-friendly
> >> encoding makes more sense. Modems don't do morse.
> >
> > "asciimorse" would be possible, just going through the byte and
> > doing - for 1 and . for 0... as a matter of fact, it would probably
> > only take about two lines of code to get that to be an option, too.
> > Does everyone else think that that's really the situation?
> > (Personally, I can't do morse in my head. But neither do I have any
> > oops-decoding hardware. >:)
> >
> > I'll probably code it anyway. It should allow for a faster
> > transmission rate, anyway, since you don't have to accomodate
> > humans. (Anyone who can decode "asciimorse" in their head is a REAL
> > freak. Er. no offense.)
> 
> Hopefully reasonable idea:
> 
> Start each transmission with 900 HZ for 80 ms.
> Start each line with 1300 HZ for 40 ms.
> Each bit is 10 ms at 1600 HZ or 1900 HZ.
> Transmit the 7 low bits, plus a parity bit.
> End each line with a '\0' and a checksum byte.
> End each transmission with silence for 80 ms.
> 

Reasonable -- it would still fit within the code framework I've got
right now, and within the way that panic_blink() works in general.
Do we use odd-parity, so that we can tell the \0 before the checksum
from a \0 in the input stream?

Does a crappy, battery-powered micro tape recorder have a chance of
recording this accurately?

> That ought to survive telephone transmission.
> If I'm lucky, it might survive MP3 encoding.
> It's about 120 WPM, and doesn't slow down on
> non-English text like an oops report.

Anyway, I like it in general. Could you write the decoder software, or
do we have any other volunteers on the list to do it? I'm not sure that
my /dev/dsp programming is up to snuff. (Actually, it'd probably be
easier operating on a .wav/.au unless you want real-time.)

Some final notes/questions:

* 10ms is just one jiffie on most arches in 2.4. That means that we
won't get perfect timing. (I don't think I want to switch to anything
_other_ than jiffies when we're panicked, but I don't know anything
about any of the higher-res stuff. Keep in mind that we get called
inside an infinite loop, and that it's not so easy to change that)

* Might anything from userland want access to this as a device? This
sounds nice at first blush, but using the same code to work well both
as a 'real' driver and for panic situation doesn't seem too easy.

--hobbs

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Daniel Phillips]

On Saturday 27 July 2002 07:57, Andrew Rodland wrote:
> * Might anything from userland want access to this as a device? This
> sounds nice at first blush, but using the same code to work well both
> as a 'real' driver and for panic situation doesn't seem too easy.

The whole morse idea stays cute only if it stays simple.

-- 
Daniel

Re: Speaker twiddling [was: Re: Panicking in morse code]

[David D. Hagood]

I don't understand the direction this discussion is taking.

Either you are trying to output the panic information with minimal 
hardware, and in a form a human might be able to decode, in which case 
the Morse option seems to me to be the best, or you are trying to panic 
in a machine readable format - in which case just dump the data out 
/dev/ttyS0 and be done with it!

To my way of thinking, the idea of the Morse option is that if an oops 
happens when you are not expecting it, and you haven't set up any 
equipment to help you, you still have a shot at getting the data.

Trying to dump the oops data out by some form of FSK in most cases seems 
silly - if you have taken the time to set up a microphone and decoder, 
why not just set up a serial terminal?

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Andrew Rodland]

On Sat, 27 Jul 2002 07:57:42 -0500
"David D. Hagood" <wowbagger@sktc.net> wrote:

> I don't understand the direction this discussion is taking.
> 
> Either you are trying to output the panic information with minimal 
> hardware, and in a form a human might be able to decode, in which case
> the Morse option seems to me to be the best, or you are trying to
> panic in a machine readable format - in which case just dump the data
> out /dev/ttyS0 and be done with it!
> 
> To my way of thinking, the idea of the Morse option is that if an oops
> 
> happens when you are not expecting it, and you haven't set up any 
> equipment to help you, you still have a shot at getting the data.


To my way of thinking, this is still 'minimal' -- it's just a different
minimum.

It's the 'minimum' way to get the panic message out digitally, in such
a way that I might be able to recover it using a tape recorder or a
telephone. Actually, morse is probably that, but morse loses data and
doesn't have any redundancy.

And with a setup pretty similar to what acalahan posted, It can be
written with a minimum of complexity (maybe less than morse) and
hardware (still just pc speaker).

Anyway, I don't expect for other people to use most of what I'm going
to be playing with with this, and my (disconnected) vacation next week
provides the perfect opportunity for me to play with it all I want
without bothering the list. And I've got some mighty interesting ideas
now.

Thanks
--hobbs

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Albert D. Cahalan]

David D. Hagood writes:

> Either you are trying to output the panic information with minimal 
> hardware, and in a form a human might be able to decode, in which case 
> the Morse option seems to me to be the best, or you are trying to panic 
> in a machine readable format - in which case just dump the data out 
> /dev/ttyS0 and be done with it!
>
> To my way of thinking, the idea of the Morse option is that if an oops 
> happens when you are not expecting it, and you haven't set up any 
> equipment to help you, you still have a shot at getting the data.
>
> Trying to dump the oops data out by some form of FSK in most cases seems 
> silly - if you have taken the time to set up a microphone and decoder, 
> why not just set up a serial terminal?

Reality?

I'm one of the 42 remaining people with a terminal. My VT510
mostly sits unplugged due to heat, and it's taking up space.
The RS-232 port is legacy hardware anyway, due for removal.
My VT510 doesn't speak USB.

Morse doesn't do "<" and other common characters. For those
who know it, morse is useful. For well over 99% of the users,
morse is gibberish anyway.

There's no "set up a microphone and decoder" problem.
Most people have a tape recorder. Use that, then play
back into the PC's sound card after you reboot. Post the
sound file on a web site.

Sure, morse is cute and FSK isn't. FSK is useful. Morse is
useful too, for different reasons. One could output in both
formats, alternating between them until reboot.

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Ville Herva]

On Sat, Jul 27, 2002 at 02:56:41PM -0400, you [Albert D. Cahalan] wrote:
> Reality?
> 
> There's no "set up a microphone and decoder" problem.
> Most people have a tape recorder. Use that, then play
> back into the PC's sound card after you reboot. Post the
> sound file on a web site.

Reality?

I don't have a tape recorder, and even if I had that procedure is so tedious
that I'd rather write the oops down with a pen. And I don't use pen
willingly as it is error prone. (I don't even dare to think what Windows
people would say if I actually found a magnetophone and a mic and tried to
sneak into the curiously twittering server room without anyone noticing.)

Let's get real. There's much better solutions already available: 
 - serial console that has been in kernel for ages
   (sneaking into server room with an old laptop and serial cable
   at least _looks_ professional)
 - kmsgdump from Willy Tarreau that writes the oops to a floppy (even makes
   a msdos fs), can use printer and enables pgup/pgdown even after lockup so
   that you can see the whole kernel ring buffer (who would ever notice if
   you sneak out from the server room with a floppy or a sheet of paper)
   http://wtarreau.free.fr/kmsgdump/
 - netconsole from Ingo Molnar that logs the oops over udp (you don't even
   have to sneak into the server room)
   http://people.redhat.com/mingo/netconsole-patches/

Now, I would assume that most people have a floppy, printer or a network
connection. At least more people than have a tape recorder.


-- v --

v@iki.fi

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Ville Herva]

On Sat, Jul 27, 2002 at 11:40:43PM +0100, you [Alan Cox] wrote:
> 
> There is a vt420 sitting next to the rack right here.

We had one VTxxx too, but lost it when moving office.
 
> > Morse doesn't do "<" and other common characters. For those
> > who know it, morse is useful. For well over 99% of the users,
> > morse is gibberish anyway.
> 
> I spent a long time suffering to learn morse. Now for once in my life
> it'll actually be -useful-

I bet you'll quickly get fed up once people start posting oops mp3's as
Albert suggested ;@).


-- v --

v@iki.fi

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Ryan Anderson]

> > Morse doesn't do "<" and other common characters. For those
> > who know it, morse is useful. For well over 99% of the users,
> > morse is gibberish anyway.
> 
> I spent a long time suffering to learn morse. Now for once in my life
> it'll actually be -useful-

I suspect that the speaker twiddling portion of the code is 100 times
more important than the LED blinking part of it.  Everyone I know (as a
Radio Amateur) that knows Morse learned it by hearing it - seeing
blinking lights is a totally different part of the brain that needs to
learn how to interpret the input.

My gut feeling says that this patch falls into the "cool hack" category,
more than anything else - but the best part about cool hacks is that
they are occassionally really really useful to someone.

--
Ryan Anderson
  sometimes Pug Majere

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Alan Cox]

On Sat, 2002-07-27 at 19:56, Albert D. Cahalan wrote:
> I'm one of the 42 remaining people with a terminal. My VT510
> mostly sits unplugged due to heat, and it's taking up space.

There is a vt420 sitting next to the rack right here.

> Morse doesn't do "<" and other common characters. For those
> who know it, morse is useful. For well over 99% of the users,
> morse is gibberish anyway.

I spent a long time suffering to learn morse. Now for once in my life
it'll actually be -useful-

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Lars Magne Ingebrigtsen]

"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

> For well over 99% of the users, morse is gibberish anyway.

But you don't need to know morse to use it.  You just transcribe the
morse code in an Emacs buffer and run it through `M-x unmorse-region'.

../-/.----./... ./.-/.../-.--/.-.-.-

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: [PATCH -ac] Panicking in morse code

[Bill Davidsen]

On Fri, 26 Jul 2002, Albert D. Cahalan wrote:

> Jens Schmidt writes:
> 
> > I am not a "morse" guy myself, but appreciate this idea.
> 
> Yeah, same here. I have to wonder if morse is the
> best encoding, since many people don't know it.
> The vast majority of us would need a microphone and
> translator program anyway, so a computer-friendly
> encoding makes more sense. Modems don't do morse.

What other widely known encoding for blinking lights did you have in mind.
Clearly there are more people who know morse than any other encoding you
could make up, and even those who don't know it would know what it is.

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

Re: [PATCH -ac] Panicking in morse code

[Richard B. Johnson]

On Mon, 29 Jul 2002, Bill Davidsen wrote:

> On Fri, 26 Jul 2002, Albert D. Cahalan wrote:
> 
> > Jens Schmidt writes:
> > 
> > > I am not a "morse" guy myself, but appreciate this idea.
> > 
> > Yeah, same here. I have to wonder if morse is the
> > best encoding, since many people don't know it.
> > The vast majority of us would need a microphone and
> > translator program anyway, so a computer-friendly
> > encoding makes more sense. Modems don't do morse.
> 
> What other widely known encoding for blinking lights did you have in mind.
> Clearly there are more people who know morse than any other encoding you
> could make up, and even those who don't know it would know what it is.
> 
> -- 
> bill davidsen <davidsen@tmr.com>
>   CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.
> 

The Morse Code we are talking about is not the "rip-snorting" 20
words/per/minute that Radio Operators and Hams use. Instead it's
the 3 to 5 words/per/minute code you hear on aircraft navigation
radios, used by all pilots to identify navigation aids. The
'beep' you hear from a ^G is the "dash". A shorter one makes the
"dot".


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Pavel Machek]

Hi!

> > I don't understand the direction this discussion is taking.
> > 
> > Either you are trying to output the panic information with minimal 
> > hardware, and in a form a human might be able to decode, in which case
> > the Morse option seems to me to be the best, or you are trying to
> > panic in a machine readable format - in which case just dump the data
> > out /dev/ttyS0 and be done with it!
> > 
> > To my way of thinking, the idea of the Morse option is that if an oops
> > 
> > happens when you are not expecting it, and you haven't set up any 
> > equipment to help you, you still have a shot at getting the data.
> 
> 
> To my way of thinking, this is still 'minimal' -- it's just a different
> minimum.
> 
> It's the 'minimum' way to get the panic message out digitally, in such
> a way that I might be able to recover it using a tape recorder or a
> telephone. Actually, morse is probably that, but morse loses data and
> doesn't have any redundancy.

You don't need redundancy. You should just repeat message over and over
and over and over and....

If you don't want morse to loose data, invent new codes for different
parenthesis etc.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Pavel Machek]

Hi!

> > I don't understand the direction this discussion is taking.
> > 
> > Either you are trying to output the panic information with minimal 
> > hardware, and in a form a human might be able to decode, in which case
> > the Morse option seems to me to be the best, or you are trying to
> > panic in a machine readable format - in which case just dump the data
> > out /dev/ttyS0 and be done with it!
> > 
> > To my way of thinking, the idea of the Morse option is that if an oops
> > 
> > happens when you are not expecting it, and you haven't set up any 
> > equipment to help you, you still have a shot at getting the data.
> 
> 
> To my way of thinking, this is still 'minimal' -- it's just a different
> minimum.
> 
> It's the 'minimum' way to get the panic message out digitally, in such
> a way that I might be able to recover it using a tape recorder or a
> telephone. Actually, morse is probably that, but morse loses data and
> doesn't have any redundancy.

You might even add FSK checksum at each end of morse line ;-), if you realy
want checksum. Plus it will sound cool. You should also play special melody
at each start of repeat, to be more decoder-friendly [and it will also
sound cool].
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH -ac] Panicking in morse code

[Albert D. Cahalan]

Bill Davidsen writes:
> On Fri, 26 Jul 2002, Albert D. Cahalan wrote:
>> Jens Schmidt writes:

>>> I am not a "morse" guy myself, but appreciate this idea.
>>
>> Yeah, same here. I have to wonder if morse is the
>> best encoding, since many people don't know it.
>> The vast majority of us would need a microphone and
>> translator program anyway, so a computer-friendly
>> encoding makes more sense. Modems don't do morse.
>
> What other widely known encoding for blinking lights did you have in mind.
> Clearly there are more people who know morse than any other encoding you
> could make up, and even those who don't know it would know what it is.

ROTFL

This is NOT morse over blinking lights. Even at 12 WPM,
which is moderately fast, you'd have to stare at the
lights for over an hour without blinking! Keep in mind
that people know morse by sound, not sight, so you'd
have to slow it down. Maybe 24 hours for an oops?

(note: in morse, hex digits are slow)

No, the lights just blink. Encoding just the instruction
pointer, in binary, might be worthwhile. I have doubts.

As for the audio... you can copy morse for over an hour
or you can tape record 4 minutes of noise. Hard choice?

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Albert D. Cahalan]

Lars Magne Ingebri writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

>> For well over 99% of the users, morse is gibberish anyway.
>
> But you don't need to know morse to use it.  You just transcribe the
> morse code in an Emacs buffer and run it through `M-x unmorse-region'.
>
> ../-/.----./... ./.-/.../-.--/.-.-.-

We're talking about 12 WPM for over an hour.

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Albert D. Cahalan]

Pavel Machek writes:

> You might even add FSK checksum at each end of morse line ;-), if you realy
> want checksum. Plus it will sound cool. You should also play special melody
> at each start of repeat, to be more decoder-friendly [and it will also
> sound cool].

I looked into writing a decoder. It's really helpful to have a
fixed ratio of high/low states. It's also good to avoid silence.
The melody is important, so the user will know how long to
record, and to provide a way to sync up the decoder.

AMTOR w/ FEC is looking pretty good, but it needs the
character set fixed. (new shift states, 1 ASCII per 2 Baudot,
or a new code table) I hear there are extensions available
that would at least do lowercase and a bit more puctuation.

Not being a DSP expert, I'm using an FFT to get the power
spectrum for a small region. I slide this window along the
audio sample. I have pretty pictures of the bits now. :-)
It looks like I could pick a frequency with a wide range
of thresholds that give me the proper mark:space ratio,
then recover the clocking... It's not too hard I think, even
after going *.wav --> *.ogg --> *.au or misinterpreting the
data type.

So this is 100 baud. Guessing at good frequencies:
1940 HZ and 1500 HZ
1600 HZ and 1140 HZ
(wide separation needed because I'm not a DSP expert)

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Pavel Machek]

Hi!

> > You might even add FSK checksum at each end of morse line ;-), if you realy
> > want checksum. Plus it will sound cool. You should also play special melody
> > at each start of repeat, to be more decoder-friendly [and it will also
> > sound cool].
> 
> I looked into writing a decoder. It's really helpful to have a
> fixed ratio of high/low states. It's also good to avoid silence.

If you want it to be simple, take a look at multimon. I was actually
able to communicate using beeps on pc beeper and decoded by multimon.

But morse would be way more sexy.
									Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Ray Friess]

will someone turn off the damn server or something...  I've gotten this same
message 40 times already....



Pavel Machek wrote:

> Hi!
>
> > > I don't understand the direction this discussion is taking.
> > >
> > > Either you are trying to output the panic information with minimal
> > > hardware, and in a form a human might be able to decode, in which case
> > > the Morse option seems to me to be the best, or you are trying to
> > > panic in a machine readable format - in which case just dump the data
> > > out /dev/ttyS0 and be done with it!
> > >
> > > To my way of thinking, the idea of the Morse option is that if an oops
> > >
> > > happens when you are not expecting it, and you haven't set up any
> > > equipment to help you, you still have a shot at getting the data.
> >
> >
> > To my way of thinking, this is still 'minimal' -- it's just a different
> > minimum.
> >
> > It's the 'minimum' way to get the panic message out digitally, in such
> > a way that I might be able to recover it using a tape recorder or a
> > telephone. Actually, morse is probably that, but morse loses data and
> > doesn't have any redundancy.
>
> You don't need redundancy. You should just repeat message over and over
> and over and over and....
>
> If you don't want morse to loose data, invent new codes for different
> parenthesis etc.
>                                                                 Pavel
> --
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
>
> -
> 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/

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Thunder from the hill]

Hi,

On Sun, 28 Jul 2002, Ville Herva wrote:
> I bet you'll quickly get fed up once people start posting oops mp3's as
> Albert suggested ;@).

I think we'd better support ogg only.

BTW, I'd rather set up "ksoundoops" which decodes the recorded oops, then 
instructs you to tell nvidia because we're not responsable for this 
panic...

This panic has been presented to you by NVidia.....

			Thunder
-- 
UNC path conversion: s/\\\\/\/\// s/\\/\//g

Re: [PATCH -ac] Panicking in morse code

[Bill Davidsen]

On Mon, 29 Jul 2002, Albert D. Cahalan wrote:

> Bill Davidsen writes:

> > What other widely known encoding for blinking lights did you have in mind.
> > Clearly there are more people who know morse than any other encoding you
> > could make up, and even those who don't know it would know what it is.
> 
> ROTFL
> 
> This is NOT morse over blinking lights. Even at 12 WPM,
> which is moderately fast, you'd have to stare at the
> lights for over an hour without blinking! Keep in mind
> that people know morse by sound, not sight, so you'd
> have to slow it down. Maybe 24 hours for an oops?
> 
> (note: in morse, hex digits are slow)

I certainly didn't think more than the original (prime cause) message was
going to be sent, the whole oops would be useless, some "dereference NULL
pointer" might be, and even "oh shit I die now" would be pretty obvious to
anyone who knows any code at all.

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

Re: Speaker twiddling [was: Re: Panicking in morse code]

[Mark H. Wood]

On Sat, 27 Jul 2002, David D. Hagood wrote:
[snip]
> Trying to dump the oops data out by some form of FSK in most cases seems
> silly - if you have taken the time to set up a microphone and decoder,
> why not just set up a serial terminal?

Because it has hack value -- that is, it's a much more interesting
solution than the straightforward way. :-)

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".

Re: [PATCH -ac] Panicking in morse code

[Thunder from the hill]

Hi,

On Sat, 20 Jul 2002, Neale Banks wrote:
> You mean like an implementation of RFC 1926: "An Experimental
> Encapsulation of IP Datagrams on Top of ATM[1]"? ;-)

   The author assumes that the users take whatever precautions that are
   necessary before attempting to use this protocol in any crowded area.

Same thing to add here...

							Regards,
							Thunder
-- 
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o?  K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y- 
------END GEEK CODE BLOCK------

Re: [PATCH -ac] Panicking in morse code

[Neale Banks]

On Sat, 20 Jul 2002, Ville Herva wrote:
[...]
> I'm just waiting for Andrew to come up with a proper morse code network
> layer, so that the machines in the room can communicate (provided they have
> a mic each)... Now combine that with Ingo's network console and...

You mean like an implementation of RFC 1926: "An Experimental
Encapsulation of IP Datagrams on Top of ATM[1]"? ;-)

Neale.

[1] ATM: in this case it's "Acoustical Transmission Media"

Re: [PATCH -ac] Panicking in morse code

[Ville Herva]

On Fri, Jul 19, 2002 at 12:38:24PM +0200, you [Andi Kleen] wrote:
> Andrew Rodland <arodland@noln.com> writes:
> 
> > I was researching panic_blink() for someone who needed a little help,
> > when I noticed the comment above the function definition, not being the
> > kind to step down from a challenge (unless it's just really hard), I
> > decided to write morse code output code.
> 
> I would consider beeps annoying, but then I usually just cut the beeper
> line on any new PC I install so personally I do not care. Still imagine
> what a machine room that overheated and caused several boxes to panic
> would sound like...

I'm just waiting for Andrew to come up with a proper morse code network
layer, so that the machines in the room can communicate (provided they have
a mic each)... Now combine that with Ingo's network console and...


-- v --

v@iki.fi

Re: [PATCH -ac] Panicking in morse code

[Andi Kleen]

Andrew Rodland <arodland@noln.com> writes:

> I was researching panic_blink() for someone who needed a little help,
> when I noticed the comment above the function definition, not being the
> kind to step down from a challenge (unless it's just really hard), I
> decided to write morse code output code.

Great. Congratulations (having written the original comment).

I would encode the morse strings as bits in a integer instead of strings
though (perhaps with some macros to make it readable), that should shrink 
it quite a bit.

> 
> The option panicblink= has been hijacked to be a simple bitfield: 
> bit 1 : blink LEDs
> bit 2 : sound the PC speaker.
> 
> the blinking option depends only on pc_keyb.c. the pcspeaker option
> depends on kb_mksound() actually doing something. At the moment, both of
> these mean i386. The call to panic_blink() in panic() is still guarded
> by an i386 #ifdef, anyway, for the moment. The default is to blink only,
> because I figured the beeps would be too annoying. Opinions?

I would consider beeps annoying, but then I usually just cut the beeper
line on any new PC I install so personally I do not care. Still imagine
what a machine room that overheated and caused several boxes to panic
would sound like...

-Andi