LinuxLists.cc - [PATCH] 2.5.59 morse code panics

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

Dave

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

2003-01-30 17:41:41

by Alan

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

2003-01-31 10:34:20

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

Of course we want morseops. :)
v2 follows.

--
Tomas Szepe <[email protected]>

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

diff -urN b/drivers/input/keyboard/atkbd.c a/drivers/input/keyboard/atkbd.c
--- b/drivers/input/keyboard/atkbd.c 2002-12-08 20:06:16.000000000 +0100
+++ a/drivers/input/keyboard/atkbd.c 2003-01-31 10:20:56.000000000 +0100
@@ -445,6 +445,23 @@
atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_SSCANSET);
}

+#ifdef CONFIG_MORSE_PANICS
+static struct atkbd *atkbd_blinkdev = NULL;
+int atkbd_blink(char led) {
+ char param[2] = "\0\0";
+ led = led ? (0x01 | 0x04) : 0x00;
+ *param = led;
+
+ if (atkbd_blinkdev == NULL)
+ return -1;
+
+ if (atkbd_command(atkbd_blinkdev, param, ATKBD_CMD_SETLEDS))
+ return -1;
+
+ return 0;
+}
+#endif
+
/*
* atkbd_disconnect() closes and frees.
*/
@@ -543,11 +560,12 @@
set_bit(atkbd->keycode[i], atkbd->dev.keybit);

input_register_device(&atkbd->dev);
-
+#ifdef CONFIG_MORSE_PANICS
+ atkbd_blinkdev = atkbd;
+#endif
printk(KERN_INFO "input: %s on %s\n", atkbd->name, serio->phys);
}

-
static struct serio_dev atkbd_dev = {
.interrupt = atkbd_interrupt,
.connect = atkbd_connect,
diff -urN b/include/linux/morseops.h a/include/linux/morseops.h
--- b/include/linux/morseops.h 1970-01-01 01:00:00.000000000 +0100
+++ a/include/linux/morseops.h 2003-01-31 11:20:05.000000000 +0100
@@ -0,0 +1,26 @@
+/* Yes, it's morse code ops indeed. */
+
+#ifndef _LINUX_MORSEOPS_H
+#define _LINUX_MORSEOPS_H
+
+#include <linux/config.h>
+
+#if defined(CONFIG_MORSE_PANICS)
+
+extern const unsigned char morsetable[]; /* in kernel/morse.c */
+void panic_morseblink(char *buf); /* in kernel/morse.c */
+
+static inline unsigned char tomorse(char c) {
+ if (c >= 'a' && c <= 'z')
+ c = c - 'a' + 'A';
+ if (c >= '"' && c <= '_') {
+ return morsetable[c - '"'];
+ } else
+ return 0;
+}
+
+#else /* CONFIG_MORSE_PANICS */
+ #define panic_morseblink(buf)
+#endif /* CONFIG_MORSE_PANICS */
+
+#endif /* _LINUX_MORSEOPS_H */
diff -urN b/init/Kconfig a/init/Kconfig
--- b/init/Kconfig 2003-01-17 04:27:43.000000000 +0100
+++ a/init/Kconfig 2003-01-31 11:06:31.000000000 +0100
@@ -98,6 +98,19 @@
13 => 8 KB
12 => 4 KB

+config MORSE_PANICS
+ bool "Morse code panics"
+ depends on KEYBOARD_ATKBD || VT
+ help
+ When enabled, this code will make a panicking kernel cry for
+ help in morse code, signalling on the leds of a possibly attached
+ AT keyboard and/or a bleeper. You can enable/disable your morse
+ output devices of choice using the "panicmorse" kernel boot
+ parameter.
+
+ If unsure, say Y. This feature is very helpful for those who
+ spend most of their time in X.
+
endmenu

@@ -159,4 +172,3 @@
in <file:Documentation/kmod.txt>.

endmenu
-
diff -urN b/kernel/Makefile a/kernel/Makefile
--- b/kernel/Makefile 2003-01-09 10:59:41.000000000 +0100
+++ a/kernel/Makefile 2003-01-31 10:28:04.000000000 +0100
@@ -22,6 +22,7 @@
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_MORSE_PANICS) += morse.o

ifneq ($(CONFIG_IA64),y)
# According to Alan Modra <[email protected]>, the -fno-omit-frame-pointer is
diff -urN b/kernel/morse.c a/kernel/morse.c
--- b/kernel/morse.c 1970-01-01 01:00:00.000000000 +0100
+++ a/kernel/morse.c 2003-01-31 11:19:54.000000000 +0100
@@ -0,0 +1,137 @@
+/*
+ * kernel/morse.c
+ *
+ * Copyright (C) 2002 Andrew Rodland <[email protected]>
+ * Copyright (C) 2003 Tomas Szepe <[email protected]>
+ *
+ * Tell the user who may be running in X and not see the console that
+ * we have panic'd. This is to distingush panics from "real lockups."
+ * Could in theory send the panic message as morse, but that is left
+ * as an exercise for the reader.
+ *
+ * And now it's done! LED and speaker morse code by Andrew Rodland
+ * <[email protected]>, with improvements based on suggestions from
+ * [email protected] and a host of others.
+ *
+ * Initial 2.5 morsepanics port and cleanup by
+ * Tomas Szepe <[email protected]>, January 2003.
+ */
+
+#include <linux/config.h>
+#include <linux/morseops.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/vt_kern.h>
+
+#define DITLEN (HZ / 5)
+#define DAHLEN (3 * DITLEN)
+#define SPACELEN (7 * DITLEN)
+#define FREQ 844
+
+/* Only blink by default if AT keyboard is available,
+ * go for beeping if it isn't.
+ */
+#ifdef CONFIG_KEYBOARD_ATKBD
+extern int atkbd_blink(char led); /* drivers/input/keyboards/atkbd.c */
+#define do_blink(x) atkbd_blink(x)
+static int morse_setting = 1;
+#else
+#define do_blink(x)
+static int morse_setting = 2;
+#endif
+
+const unsigned char morsetable[] = {
+ 0122, 0, 0310, 0, 0, 0163, /* "#$%&' */
+ 055, 0155, 0, 0, 0163, 0141, 0152, 0051, /* ()*+,-./ */
+ 077, 076, 074, 070, 060, 040, 041, 043, 047, 057, /* 0-9 */
+ 0107, 0125, 0, 0061, 0, 0114, 0, /* :;<=>?@ */
+ 006, 021, 025, 011, 002, 024, 013, 020, 004, /* A-I */
+ 036, 015, 022, 007, 005, 017, 026, 033, 012, /* J-R */
+ 010, 003, 014, 030, 016, 031, 035, 023, /* S-Z */
+ 0, 0, 0, 0, 0154 /* [\]^_ */
+};
+
+void panic_morseblink(char *buf)
+{
+ static unsigned long next_jiffie = 0;
+ static char * bufpos = 0;
+ static unsigned char morse = 0;
+ static char state = 1;
+
+ if (!morse_setting)
+ return;
+
+ if (!buf)
+ buf = "Uh oh, we lost the panic msg.";
+
+ /* Waiting for something? */
+ if (bufpos && time_after(next_jiffie, jiffies))
+ return;
+
+ if (state) { /* Coming off of a blink. */
+ if (morse_setting & 0x01)
+ do_blink(0);
+
+ state = 0;
+
+ if (morse > 1) {
+ /* Not done yet, just a one-dit pause. */
+ next_jiffie = jiffies + DITLEN;
+ } else {
+ /* Get a new char, figure out how much space. */
+
+ /* First time through */
+ if (!bufpos)
+ bufpos = (char *) buf;
+
+ if (!*bufpos) {
+ /* Repeating */
+ bufpos = (char *) buf;
+ next_jiffie = jiffies + SPACELEN;
+ } else {
+ /* Inter-letter space */
+ next_jiffie = jiffies + DAHLEN;
+ }
+
+ if (!(morse = tomorse(*bufpos))) {
+ next_jiffie = jiffies + SPACELEN;
+ state = 1; /* And get us back here */
+ }
+ bufpos++;
+ }
+ } else {
+ /* Starting a new blink. We have a valid code in morse. */
+ int len;
+
+ len = (morse & 001) ? DAHLEN : DITLEN;
+
+#ifdef CONFIG_VT
+ if (morse_setting & 0x02)
+ kd_mksound(FREQ, len);
+#endif
+
+ next_jiffie = jiffies + len;
+
+ if (morse_setting & 0x01)
+ do_blink(1);
+
+ state = 1;
+ morse >>= 1;
+ }
+}
+
+static int __init panicmorse_setup(char *str)
+{
+ int par;
+ if (get_option(&str, &par))
+ morse_setting = par;
+ return 1;
+}
+
+/* "panicmorse=0" disables the blinking as it caused problems with
+ * certain console switches.
+ *
+ * "panicmorse | 1" does the show using kbd leds.
+ * "panicmorse | 2" throws in bleeping via kd_mksound().
+ */
+__setup("panicmorse=", panicmorse_setup);
diff -urN b/kernel/panic.c a/kernel/panic.c
--- b/kernel/panic.c 2003-01-09 10:59:41.000000000 +0100
+++ a/kernel/panic.c 2003-01-31 10:36:50.000000000 +0100
@@ -16,6 +16,7 @@
#include <linux/init.h>
#include <linux/sysrq.h>
#include <linux/interrupt.h>
+#include <linux/morseops.h>

asmlinkage void sys_sync(void); /* it's really int */

@@ -95,7 +96,8 @@
disabled_wait(caller);
#endif
local_irq_enable();
- for(;;) {
+ for (;;) {
+ panic_morseblink(buf);
CHECK_EMERGENCY_SYNC
}
}

2003-01-31 11:04:51

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

John.

2003-01-31 13:17:08

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

Dave

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

2003-01-31 14:05:19

by Alan

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

2003-01-31 14:21:39

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

Exactly.

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

John.

2003-01-31 14:31:15

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

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

--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech

Attachments:

(No filename) (226.00 B)

2003-01-31 14:48:45

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

John.

2003-01-31 14:59:33

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

On Fri, Jan 31, 2003 at 09:40:27AM -0500, [email protected] wrote:

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

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

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

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

Dave

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

2003-01-31 15:07:03

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

so use something sensible like a crashdump to floppy.

> While morse code may
> be a little silly the general purpose hook it needs to be done
> cleanly is considerably more useful

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

Dave

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

2003-01-31 15:08:27

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

Dave

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

2003-01-31 15:11:46

by Scott Robert Ladd

[permalink] [raw]

Subject: RE: [PATCH] 2.5.59 morse code panics

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

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

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

A voice synthesizer would be even better than morse code.

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

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

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

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

2003-01-31 15:19:13

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

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

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

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

John.

2003-01-31 15:23:31

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

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

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

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

Attachments:

(No filename) (226.00 B)

2003-01-31 15:25:31

by Andi Kleen

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

Alan Cox <[email protected]> writes:

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

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

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

Morse is not helpful.

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

Thanks,
-Andi

2003-01-31 15:32:24

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

> [[email protected]]
>
> Morse is not helpful.

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

*runs*

2003-01-31 15:41:16

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

irda too maybe ?

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

kgdb-over-firewire ? 8-)

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

A voice of sanity.. I think you made a monster with that comment 8-)

Dave

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

2003-01-31 15:46:38

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

Attachments:

(No filename) (226.00 B)

2003-01-31 15:52:37

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

John.

2003-01-31 16:01:47

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

--
Tomas Szepe <[email protected]>

2003-01-31 16:09:22

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

John.

2003-01-31 17:50:13

by Vojtech Pavlik

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

--
Vojtech Pavlik
SuSE Labs

2003-01-31 17:57:08

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

--
Tomas Szepe <[email protected]>

2003-01-31 19:29:51

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

So here's v3.

--
Tomas Szepe <[email protected]>

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

diff -urN a/drivers/char/keyboard.c b/drivers/char/keyboard.c
--- a/drivers/char/keyboard.c 2002-12-16 07:01:47.000000000 +0100
+++ b/drivers/char/keyboard.c 2003-01-31 20:24:33.000000000 +0100
@@ -262,6 +262,27 @@
}

/*
+ * Turn all possible leds on or off.
+ */
+void kd_turn_all_leds(int on_or_off)
+{
+ struct list_head *node;
+ on_or_off = on_or_off ? 1 : 0;
+
+ list_for_each(node, &kbd_handler.h_list) {
+ struct input_handle *handle = to_handle_h(node);
+ if (test_bit(EV_LED, handle->dev->evbit)) {
+ int led;
+ for (led = 0; led <= LED_MAX; led++) {
+ if (test_bit(led, handle->dev->ledbit))
+ input_event(handle->dev, EV_LED, led,
+ on_or_off);
+ }
+ }
+ }
+}
+
+/*
* Setting the keyboard rate.
*/
static inline unsigned int ms_to_jiffies(unsigned int ms) {
diff -urN a/include/linux/morseops.h b/include/linux/morseops.h
--- a/include/linux/morseops.h 1970-01-01 01:00:00.000000000 +0100
+++ b/include/linux/morseops.h 2003-01-31 20:24:33.000000000 +0100
@@ -0,0 +1,26 @@
+/* Yes, it's morse code ops indeed. */
+
+#ifndef _LINUX_MORSEOPS_H
+#define _LINUX_MORSEOPS_H
+
+#include <linux/config.h>
+
+#if defined(CONFIG_MORSE_PANICS)
+
+extern const unsigned char morsetable[]; /* in kernel/morse.c */
+void panic_morseblink(char *buf); /* in kernel/morse.c */
+
+static inline unsigned char tomorse(char c) {
+ if (c >= 'a' && c <= 'z')
+ c = c - 'a' + 'A';
+ if (c >= '"' && c <= '_') {
+ return morsetable[c - '"'];
+ } else
+ return 0;
+}
+
+#else /* CONFIG_MORSE_PANICS */
+ #define panic_morseblink(buf)
+#endif /* CONFIG_MORSE_PANICS */
+
+#endif /* _LINUX_MORSEOPS_H */
diff -urN a/include/linux/vt_kern.h b/include/linux/vt_kern.h
--- a/include/linux/vt_kern.h 2002-12-16 07:01:55.000000000 +0100
+++ b/include/linux/vt_kern.h 2003-01-31 20:24:33.000000000 +0100
@@ -33,7 +33,10 @@
wait_queue_head_t paste_wait;
} *vt_cons[MAX_NR_CONSOLES];

+/* keyboard.c */
+
extern void kd_mksound(unsigned int hz, unsigned int ticks);
+extern void kd_turn_all_leds(int on_or_off);
extern int kbd_rate(struct kbd_repeat *rep);

/* console.c */
diff -urN a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig 2003-01-17 04:27:10.000000000 +0100
+++ b/init/Kconfig 2003-01-31 20:24:33.000000000 +0100
@@ -98,6 +98,21 @@
13 => 8 KB
12 => 4 KB

+config MORSE_PANICS
+ bool "Morse code panics"
+ depends on VT
+ help
+ When enabled, this code will make a panicking kernel cry for
+ help in morse code, signalling on the leds of a possibly attached
+ keyboard and/or a bleeper. You can enable/disable your morse
+ output devices of choice using the "panicmorse" kernel boot
+ parameter. Currently, "panicmorse=0" will disable the signalling
+ completely, "panicmorse=1" (the default) will only blink the leds,
+ "panicmorse=2" will only beep, and "panicmorse=3" will do both.
+
+ If unsure, say Y. This feature is very helpful for those who
+ spend most of their time in X.
+
endmenu

diff -urN a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile 2003-01-09 14:25:40.000000000 +0100
+++ b/kernel/Makefile 2003-01-31 20:24:33.000000000 +0100
@@ -22,6 +22,7 @@
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_MORSE_PANICS) += morse.o

ifneq ($(CONFIG_IA64),y)
# According to Alan Modra <[email protected]>, the -fno-omit-frame-pointer is
diff -urN a/kernel/morse.c b/kernel/morse.c
--- a/kernel/morse.c 1970-01-01 01:00:00.000000000 +0100
+++ b/kernel/morse.c 2003-01-31 20:24:33.000000000 +0100
@@ -0,0 +1,125 @@
+/*
+ * kernel/morse.c
+ *
+ * Copyright (C) 2002 Andrew Rodland <[email protected]>
+ * Copyright (C) 2003 Tomas Szepe <[email protected]>
+ *
+ * Tell the user who may be running in X and not see the console that
+ * we have panic'd. This is to distingush panics from "real lockups."
+ * Could in theory send the panic message as morse, but that is left
+ * as an exercise for the reader.
+ *
+ * And now it's done! LED and speaker morse code by Andrew Rodland
+ * <[email protected]>, with improvements based on suggestions from
+ * [email protected] and a host of others.
+ *
+ * Initial 2.5 morsepanics port and cleanup by
+ * Tomas Szepe <[email protected]>, January 2003.
+ */
+
+#include <linux/config.h>
+#include <linux/morseops.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/vt_kern.h>
+
+#define DITLEN (HZ / 5)
+#define DAHLEN (3 * DITLEN)
+#define SPACELEN (7 * DITLEN)
+#define FREQ 844
+
+static int morse_setting = 1;
+
+const unsigned char morsetable[] = {
+ 0122, 0, 0310, 0, 0, 0163, /* "#$%&' */
+ 055, 0155, 0, 0, 0163, 0141, 0152, 0051, /* ()*+,-./ */
+ 077, 076, 074, 070, 060, 040, 041, 043, 047, 057, /* 0-9 */
+ 0107, 0125, 0, 0061, 0, 0114, 0, /* :;<=>?@ */
+ 006, 021, 025, 011, 002, 024, 013, 020, 004, /* A-I */
+ 036, 015, 022, 007, 005, 017, 026, 033, 012, /* J-R */
+ 010, 003, 014, 030, 016, 031, 035, 023, /* S-Z */
+ 0, 0, 0, 0, 0154 /* [\]^_ */
+};
+
+void panic_morseblink(char *buf)
+{
+ static unsigned long next_jiffie = 0;
+ static char * bufpos = 0;
+ static unsigned char morse = 0;
+ static char state = 1;
+
+ if (!morse_setting)
+ return;
+
+ if (!buf)
+ buf = "Uh oh, we lost the panic msg.";
+
+ /* Waiting for something? */
+ if (bufpos && time_after(next_jiffie, jiffies))
+ return;
+
+ if (state) { /* Coming off of a blink. */
+ if (morse_setting & 0x01)
+ kd_turn_all_leds(0);
+
+ state = 0;
+
+ if (morse > 1) {
+ /* Not done yet, just a one-dit pause. */
+ next_jiffie = jiffies + DITLEN;
+ } else {
+ /* Get a new char, figure out how much space. */
+
+ /* First time through */
+ if (!bufpos)
+ bufpos = (char *) buf;
+
+ if (!*bufpos) {
+ /* Repeating */
+ bufpos = (char *) buf;
+ next_jiffie = jiffies + SPACELEN;
+ } else {
+ /* Inter-letter space */
+ next_jiffie = jiffies + DAHLEN;
+ }
+
+ if (!(morse = tomorse(*bufpos))) {
+ next_jiffie = jiffies + SPACELEN;
+ state = 1; /* And get us back here */
+ }
+ bufpos++;
+ }
+ } else {
+ /* Starting a new blink. We have a valid code in morse. */
+ int len;
+
+ len = (morse & 001) ? DAHLEN : DITLEN;
+
+ if (morse_setting & 0x02)
+ kd_mksound(FREQ, len);
+
+ next_jiffie = jiffies + len;
+
+ if (morse_setting & 0x01)
+ kd_turn_all_leds(1);
+
+ state = 1;
+ morse >>= 1;
+ }
+}
+
+static int __init panicmorse_setup(char *str)
+{
+ int par;
+ if (get_option(&str, &par))
+ morse_setting = par;
+ return 1;
+}
+
+/* "panicmorse=0" disables the blinking as it caused problems with
+ * certain console switches.
+ *
+ * "panicmorse | 1" does the show using kbd leds.
+ * "panicmorse | 2" throws in bleeping via kd_mksound().
+ */
+__setup("panicmorse=", panicmorse_setup);
diff -urN a/kernel/panic.c b/kernel/panic.c
--- a/kernel/panic.c 2003-01-09 14:25:40.000000000 +0100
+++ b/kernel/panic.c 2003-01-31 20:24:33.000000000 +0100
@@ -16,6 +16,7 @@
#include <linux/init.h>
#include <linux/sysrq.h>
#include <linux/interrupt.h>
+#include <linux/morseops.h>

asmlinkage void sys_sync(void); /* it's really int */

@@ -95,7 +96,8 @@
disabled_wait(caller);
#endif
local_irq_enable();
- for(;;) {
+ for (;;) {
+ panic_morseblink(buf);
CHECK_EMERGENCY_SYNC
}
}

2003-01-31 19:43:31

by Horst von Brand

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

John Bradford <[email protected]> said:

[...]

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

Then put out the stuff in octal...

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

2003-01-31 19:54:38

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

John.

2003-01-31 20:58:37

by Eric Weigle

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

/me ducks

-Eric

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

2003-01-31 21:03:59

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

John.

2003-01-31 21:21:51

by Albert D. Cahalan

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

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

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

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

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

2003-02-02 15:36:24

by Bill Davidsen

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

On Fri, 31 Jan 2003, John Bradford wrote:

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

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

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

2003-02-03 19:05:32

by Jos Hulzink

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

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

Jos

2003-02-03 19:59:29

by Pavel Machek

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

Hi!

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

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

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

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

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

2003-02-03 21:22:53

by Bill Davidsen

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

On Mon, 3 Feb 2003, Jos Hulzink wrote:

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

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

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

2003-02-04 05:50:35

by Peter C. Norton

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

-Peter

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

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

2003-02-04 16:22:29

by Henning P. Schmiedehausen

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

Pavel Machek <[email protected]> writes:

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

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

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

Regards
Henning

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

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

2003-02-05 17:47:14

by Marcelo Roberto Jimenez

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

Dave,

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

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

Regards,

Marcelo.

2003-02-07 15:42:22

by Ryan Anderson

[permalink] [raw]

Subject: Re: [PATCH] 2.5.59 morse code panics

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

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

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

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

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

--

Ryan Anderson
sometimes Pug Majere

2003-02-07 16:29:44