On Sat, 27 Jul 2002 01:26:58 -0400 (EDT)
"Albert D. Cahalan" <[email protected]> wrote:
> >> 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.
> >
> > "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.)
>
> Hopefully reasonable idea:
>
> Start each transmission with 900 HZ for 80 ms.
> Start each line with 1300 HZ for 40 ms.
> Each bit is 10 ms at 1600 HZ or 1900 HZ.
> Transmit the 7 low bits, plus a parity bit.
> End each line with a '\0' and a checksum byte.
> End each transmission with silence for 80 ms.
>
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?
> That ought to survive telephone transmission.
> If I'm lucky, it might survive MP3 encoding.
> It's about 120 WPM, and doesn't slow down on
> non-English text like an oops report.
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
On Saturday 27 July 2002 07:57, Andrew Rodland wrote:
> * 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.
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?
On Sat, 27 Jul 2002 07:57:42 -0500
"David D. Hagood" <[email protected]> wrote:
> 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.
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
On Sat, Jul 27, 2002 at 02:56:41PM -0400, you [Albert D. Cahalan] wrote:
> Reality?
>
> 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.
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]
David D. Hagood writes:
> 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?
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.
On Sat, 2002-07-27 at 19:56, Albert D. Cahalan wrote:
> 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.
There is a vt420 sitting next to the rack right here.
> 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.
I spent a long time suffering to learn morse. Now for once in my life
it'll actually be -useful-
On Sat, Jul 27, 2002 at 11:40:43PM +0100, you [Alan Cox] wrote:
>
> There is a vt420 sitting next to the rack right here.
We had one VTxxx too, but lost it when moving office.
> > 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.
>
> I spent a long time suffering to learn morse. Now for once in my life
> it'll actually be -useful-
I bet you'll quickly get fed up once people start posting oops mp3's as
Albert suggested ;@).
-- v --
[email protected]
> > 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.
>
> I spent a long time suffering to learn morse. Now for once in my life
> it'll actually be -useful-
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
jdow writes:
> From: "Alan Cox" <[email protected]>
>> On Sat, 2002-07-27 at 19:56, Albert D. Cahalan wrote:
>>> 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.
>>
>> There is a vt420 sitting next to the rack right here.
Alan is #2 out of the 42 people with terminals.
> Alan, the really perverse can actually read 45.45bps Baudot RTTY streams
> by ear. (Ironically the person I have watched do it is also named Alan.)
> Should it also send out Baudot as an option?
Yow. That's 60 to 65 WPM for a continuous transmission.
For the PC speaker, Baudot RTTY is easy. Data pulses are 22 ms
and stop pulses are 22, 31, or 33 ms. If the kernel is compiled
with HZ==100 then you must do the European "50 bauds" instead,
at 66.67 WPM with 20 ms data and 30 ms stop.
Ask that other Alan what frequency shift he likes; mark/space
may be 2125/2975, 2125/2295, 1275/2125, or 1275/1445.
> Now, are you sure
> that you are going to be ready to type in the Morse you copy in your head
> as the machine surprises you with a crash and bleats of Morse code?
It needs to repeat.
"Albert D. Cahalan" <[email protected]> writes:
> For well over 99% of the users, morse is gibberish anyway.
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
Hi!
> > 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.
>
>
> 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.
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.
Hi!
> > 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.
>
>
> 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.
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.
Lars Magne Ingebri writes:
> "Albert D. Cahalan" <[email protected]> writes:
>> For well over 99% of the users, morse is gibberish anyway.
>
> 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'.
>
> ../-/.----./... ./.-/.../-.--/.-.-.-
We're talking about 12 WPM for over an hour.
Pavel Machek writes:
> 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].
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!
> > 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].
>
> 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.
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.
will someone turn off the damn server or something... I've gotten this same
message 40 times already....
Pavel Machek wrote:
> Hi!
>
> > > 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.
> >
> >
> > 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.
>
> 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.
>
> -
> 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/
Hi,
On Sun, 28 Jul 2002, Ville Herva wrote:
> I bet you'll quickly get fed up once people start posting oops mp3's as
> Albert suggested ;@).
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
On Sat, 27 Jul 2002, David D. Hagood wrote:
[snip]
> 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?
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".