login
Search
Last July, Andrew Rodland added logic to make a server's LED's blink in morse code following a kernel panic, in response to comments he read in the function 'panic_blink' [story]. Tomas Szepe has dusted of this code and ported it to the 2.5 development kernel, receiving a mixed reaction.
Dave Jones [interview] suggested the patch had little merit as there were far easier ways to debug a kernel panic, to which Alan Cox [interview] replied, "While morse code may be a little silly the general purpose hook it needs to be done cleanly is considerably more useful". Andi Kleen, the author of the comment that suggested morse code, had this to say:
"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."
From: Tomas Szepe To: lkml Subject: [PATCH] 2.5.59 morse code panics Date: Thu, 30 Jan 2003 16:07:09 +0100 Here's the initial port of Andrew Rodland's morse code panics to 2.5. It's probably got a few issues that need to be sorted out: at least the acquisition of the atkbd handle is a shameful hack. The original regular blinking code from ac has been removed, because it's no use when we've got morse about. :) Any comments appreciated, patch against 2.5.59. -- Tomas Szepe [patch]
From: Dave Jones Subject: Re: [PATCH] 2.5.59 morse code panics Date: Thu, 30 Jan 2003 17:36:42 +0000 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
From: Alan Cox Subject: Re: [PATCH] 2.5.59 morse code panics Date: 30 Jan 2003 18:45:34 +0000 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)
From: Tomas Szepe Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 11:43:26 +0100 > [alan@lxorguk.ukuu.org.uk] > > On Thu, 2003-01-30 at 17:36, Dave Jones wrote: > > > As this patch further builds upon the previous one, > > It'd take a complete change of mind on his part to take > > this as it is. > > If its attached to atkbd then its not a PCism and its now > nicely modularised in the atkbd driver. Providing we have > a clear split between the core "morse sender" and the > platform specific morse output device (do we want > morse_ops 8)) it should be clean and you can write morse > drivers for pc speaker, for non pc keyboard and even for > soundblaster 8) Of course we want morseops. :) v2 follows. -- Tomas Szepe [patch]
From: John Bradford Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 11:12:57 +0000 (GMT) > > > 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.
From: Dave Jones Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 13:22:21 +0000 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
From: Alan Cox Subject: Re: [PATCH] 2.5.59 morse code panics Date: 31 Jan 2003 15:09:46 +0000 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
From: John Bradford Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 14:29:59 +0000 (GMT) > 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.
From: Dave Jones Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 15:13:48 +0000 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 -
From: Andi Kleen Subject: Re: [PATCH] 2.5.59 morse code panics Date: 31 Jan 2003 16:34:55 +0100 Alan Cox 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
From: Tomas Szepe Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 16:41:41 +0100 > Andi Kleen > > Morse is not helpful. Of course it is, you're just angry that I've left out your original plain_blinking code. *runs*
From: John Bradford Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 16:01:05 +0000 (GMT) > > 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.
From: Bill Davidsen Subject: Re: [PATCH] 2.5.59 morse code panics Date: Sun, 2 Feb 2003 10:42:50 -0500 (EST) 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 CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
From: Vojtech Pavlik Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 18:59:27 +0100 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
From: Tomas Szepe Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 19:06:20 +0100 > Vojtech Pavlik: > > 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
From: Tomas Szepe Subject: Re: [PATCH] 2.5.59 morse code panics Date: Fri, 31 Jan 2003 20:38:59 +0100 > Vojtech Pavlik: > > 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 [patch]
interesting
You can't make an omellette without breaking a few eggs. However, lately, I've noticed more and more people trying to help the linux kernel being criticized and having virtual sand kicked in their faces by the "nerd bully" kernel developers. That sort of "we're better than you" attitude is usually only associated with *BSD.
Eventually, people will get tired of trying to help out the linux kernel, and it will end up dieing (just like *BSD).
Please, don't let that happen!
It's nothing new.
As someone who has watched the semi-periodic flamewars over the past 8 or 9 years on lkml, I'd have to say this is nothing new. You need a thick skin to work with these guys, and you need to not take anything too personally. That's why lkml has such a high ratio of lurkers to contributors.
Nowadays things are actually better than in the beginning, with the introduction of "newbie friendly" areas, such as #kernelnewbies and the kernel janitoring lists. Newcomers to the kernel can do the equivalent of "starting in the mailroom" and working their way up.
The big difference I see (as an outsider) between *BSD and Linux is that your position in the Linux kernel community shifts based soley on how people react to you over a long window of time (and you to them). In the *BSD community, there seems to be a clear "inside" and "outside", with discrete, formalized transitions between the two states. Maybe I'm misinterpreting things, but I'm not too worried about Linux's style changing into BSD's style overnight.
They didn't get the picture though
I didn't follow the morse code patch very closely, but it has been around for quite a long time (a year?) with people seriously trying to push it and make elaborate arguments for it, all the while they had been ignoring the ever blunter hints being sent their way. I hope they (I didn't even read the thread here) will finally get the message and shut the hell up for the love of dear sweet Jesus.
Perhaps
Using new POST Reporters for these function may useful. The post reporters uses some voice data stored into PC BIOS.
when my new board booting, speakers sayin someting. Also I found 10 other voice messages for errors. (like overheat, cpu malfunction etc).
one code to rule them all
In practice it doesn't matter what standard is used as long as its standard. However if you say "morse code" people all over the world will at least be able to find out what you mean. Code patterns can be minimal enough that you dont have to learn morse just the common error codes.
Up to 20 you could just have a simple numbering system eg long followed by number of shorts. Or "s o s" followed by longs for 10s and shorts for 1s. If the number of messages is more than 20 or so maybe the morse alphabet would be more logical. I dont think its a silly idea
bo
one problem
In the time taken to record and decode the oops, you could have got a job, and earned enough money to get another computer and set up a serial link between it and the crashing one.
Not a feature in Windows?
I assumed the greatest value would be to motivate MS to steal the idea and add a morse.dll and Control Panel to Windows XP (w/morse). Would probably add another 5M of bloat to Windows, I'm sure. And then Linus will just have to accept the patch! :-)
BSOD
How does one morse the output of a random BSOD...
beep BEEEP beep beep beep BEEP... damn I missed a beep let's start all over.. and all the beeping will drive the Windows users mad... I'm already getting fond of this idea.
Obligatory Ellen
I was working on a paper for school on my dad's PC, it it was like dit dit dah dit dit dit, and my paper was gone.....
Accessibility
Hmmm... linux kernel aside,
Maybe morse code output on application (or toolkit) level
could be an alternative mean of communication with blind users
(an audio equivalent of the braille system)...
(the reason I suggest it is that it would be much cheaper
and easier to implement than Text-To-Speech in many kinds
of systems).
Perhaps this is already in use somewhere, though...
Quite similar to....
a PC mobo beeping when it fails to boot. I haven't come across this in awhile, but I do remember digging out the manuals for some 486 to decode the beep patterns. Only to learn that it couln't handle the ram I put in it...
Perhaps not for long drawn out morse messages, but short definite patterns this may have some neat uses.
hmm
While 'real' morse code might be a little overkill, some 'flash codes' (ala bios beep codes) representing common reasons of kernel panics might actualy not be a bad idea. At least it should point you in the right direction.