Slashdot Mirror
Panicking In Morse Code
An anonymous reader writes "When an i386 running Linux panics, a function in the kernel called 'panic_blink' causes the system's LEDs to blink. Andrew Rodland recently posted a creative patch to turn that steady blink into a useful message in morse code!"
You're paraphrasing Richard Feyman:
Physics is like sex: sure, it may give some practical results, but that's
not why we do it. --Richard Feynman.
Linux: Panicking In Morse Code Submitted by Jeremy on Saturday, July 20, 2002 - 08:12
/* Tell the user who may be running in X and not see the console that we have
Digging through the source code of a recent kernel, in the file 'linux/drivers/char/pc_keyb.c', above the definition for the function 'panic_blink', one reads the following comment:
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. */
Andrew Rodland stumbled across this comment, and as he explains, "not being the kind to step down from a challenge (unless it's just really hard), I decided to write morse code output code." His patch against Linux kernel version 2.4.19-rc1-ac1 (plus preempt) actually modifies the kernel to report a panic in morse code! Andrew also submitted a small sample module for generating test panics.
From: Andrew Rodland
To: linux-kernel AT vger.kernel.org
Subject: [PATCH -ac] Panicking in morse code
Date: Fri, 19 Jul 2002 01:13:00 -0400
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.
I managed to grab a copy!
--
Todd
This is a good page for the morse code and common abbreviations used by HAM (amateur radio) operators. You could always have your computer die with QSB? (are my signals fading?)...
Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
num lock, cap lock, scroll lock
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Most BIOS's still do that when they can't start-- you can find BIOS error codes online for most computers, though the beep codes differ between models.
Nowadays, though, hardware is cheap enough that most people just start swapping out hardware when their computer does something other than the standard short beep on startup.
Now if we could patch the BIOS's to give errors in Morse code...
LedgerSMB: Open source Accounting/ERP
One of the (many) cool things that differentiate Macs from PC's is the way the report POST failures.
Depending on if the video driver was sane or not yet, you'd get an infamous "San Mac" display, followed by a few codes in hex describing what was wrong. If not, you'd get POST-coded beeps.
What was really cool were the "chimes of death". Each Mac model family had a specific sound that played when the POST test failed. These ranged from the opening to the Twilight Zone theme, to a drum crash, to the sound of glass breaking, to a full-on car crash. (You get get some of them here, but I KNOW there's a more comprehensive list with samples out there somewhere.)
Ahh, memories...
Hire a Linux system administrator, systems engineer,
That's exactly what it does. It simply transmits the message that was passed to panic(), after snprintf-expansion.
:)
As for the parent message, it has two modes of operation, currently, keyboard-LEDs and/or pc-speaker, but the latest version (v3) is potentially compatible with any sort of LED or beeper, if someone writes the code. The beeper, in fact, uses the same beep function as the VC's, which was already set up to be multi-arch-compatible in just that way.
In other words, yes, I _am_ trying to make this reasonably useful.
Someone gave me a RaQ4 because his house power was too flaky and the box kept rebooting.
Well after bringing it home and reloading it from the "network gold disk" I started using it. After a short while, the box became very slow to respond. The load had gone up to 33 (yes, the O'Reilly Performance Tuning book says the load shouldn't go over 2.0 x the CPU count -- this went up to 33 on idle). It was the damn LCD control app. Once I chmodded it to -x, the load hasn't gone over 0.02 in over a year. Of course the LCD is useless now, but its better than having the whole server useless.
I brought it up to my friend (who was managing about 800 of the bastards at an ISP) and he replied, "oh, no wonder the damn things are so freaking slow".
So, lately I've been reading up on the System Installation Suite so that I can setup my own tftp server-based install of Debian. If you also anticipate Sun dropping support for these bad boys, you may want to look into it too. It would be nice to have the box feel like a normal one and who knows, maybe the lcdproc isn't such a resource hog now. Maybe the market will be flooded with them once they're abandoned, and SISuite will breathe new life into them.
Intelligent Life on Earth