Panicking in morse code

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
@@ -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
@@ -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
 	}

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

Good show!

Cheers,
Bill

nice idea :)

[...]

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

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

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. :)

Andrew Rodland wrote:
[snip]

*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 `-------------------------------------------------

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.");

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
@@ -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 
+	<[email protected]>, with improvements based on suggestions from
+	[email protected].
+*/ 
+
+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
@@ -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
 	}

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.

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

Hi,

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------

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 --

[email protected]

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

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

Daniel

Try this on for size:

/* dorssel.c, 1998 IOCCC entry
* Frans van Dorsselaer <[email protected]>
*/

#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);}
}

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

.... ..

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

					.-. . --. .- .-. -.. ...,
					- .... ..- -. -.. . .-.

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

v2 uses an algorithm suggested to me in private that allows you to fit 7 bits of morse into 8 bits. Very clever method.

Thanks. :)

Hi,

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------

??? 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 <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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

Daniel

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

Daniel

From: "Daniel Phillips" <[email protected]>

lower

fit

strings,

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.)

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

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 <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

[...snip...]

???
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 <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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.

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.

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.

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

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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

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.

Left/right just assumed?

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

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.

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.

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

"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.)

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

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?

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

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

Daniel

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?

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

Hi!

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.

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

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].
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.

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)

Hi!

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.

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.

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 --

[email protected]

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

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

We had one VTxxx too, but lost it when moving office.

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

-- v --

[email protected]

Hi,

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

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

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.)
   [email protected] * Lars Magne Ingebrigtsen

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

On Sat, 27 Jul 2002, David D. Hagood wrote:
[snip]

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

Mark H. Wood, Lead System Programmer   [email protected]
MS Windows *is* user-friendly, but only for certain values of "user".

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

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 <[email protected]>
  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.

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?

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 <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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
@@ -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);
-

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.

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 ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

@@ -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);

@@ -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);

@@ -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

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

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.