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