Slashdot Mirror
Gnarly Error Messages
Veeru writes "In my career, I have run across some whopper error messages, but a call from the mainframe sysop one night beat them all: 'We are experiencing MVS processor spin loops, the programs are running while holding a disabled CPU. This is causing XCF communication delays to the point where we are losing VTAM RTP routing, are suffering OSPF adjacency failures on TCP/IP dynamic routing and MIM VCF failures. Whatever this code is, it should NOT be propagated to production or we run the risk of losing the development plex if XCF signaling is adversely impacted by processor disabled spin loops'. My friend once got an error message 'Error 2 while trying to report error 2'. I would be curious to hear from the Slashdot community on encounters with other bizarre error messages."
Actually, that is very poor error reporting. It gives no indication of what the error is. It gives no indication of *where* the error is.
At the very least, the line number should be written to a log file, with as much data as you can pull together. A better thing to do is to write a stack trace to a log file, with a snapshot of the environment when it occurred (what you tried to do, locals, globals, etc).
This page in particular has the forbearer error to Ellen Feiss:t ml
http://www.mixed-up.com/markb/humor/mpc.h
"Huh ?"
Does it make you happy you're so strange?
I hate to ruin a perfectly good story, but what you saw was probably "DOUBLE PANIC."
If an SGI box kernel panics, it does exactly what you described, printing the message "KERNEL PANIC" at the top of the textport and spewing out lots of stack traces after it.
Now, kernel panics are, of course, handled by a handler. (Those panic messages don't happen by magic, you know.) If, on the off chance, your machine should panic, and then panic again inside the panic handler-- apart from meaning something is really, really wrong-- the system prints the message "DOUBLE PANIC" on the screen.
That's probably what you saw. I've seen this many times-- always due to faulty hardware.
Of course, I wouldn't put it past SGI to put a joke in their panic messages. This is, of course, the company that warned users in its workstation owner's guide not to "dangle the mouse by its cable or throw mouse at co-workers."
And there's always the ever-popular audiopanel -spinaltap gag. Running audiopanel with the -spinaltap flag makes the VU meters go to 11. Naturally.
I write in my journal
Comment removed based on user account deletion
I seem to remember that Enlightenment does a lot of those things in its "configure" script.
Checking refrigerator for beer... Refrigerator does not have enough beer.
Or something like that. There's a switch to turn them off, but I never did.
Windows NT has done soemthing similar when it couldn't find the mouse. A message box pops up, but you can't reply without a mouse. The 'O' on the 'OK' button is not hot-keyed.
Tab to the button and press enter/space. Should work fine.
Also of interestError message hall of shame
Usually, there is an option to fix this in the bios. Normally it's on the first bios setup screen, labelled "Halt on: (list of options)" or somesuch. Tell it to keep keep silent on boot errors, and you can probably yank that keyboard.
Need a Linux consultant in New Orleans?
Reportedly, that error message is traditional, and used to be accurate. You'd get that if the printer had jammed in such a way that there was paper pressed on one side against a spinning part, generating heat and paper dust. By the time you got to the printer, it would probably have burst into flames. Of course, the printer could have broken in a less catastrophic way, but people don't tend to complain when their computer tells them their huge printer is on fire and it turns out it's merely broken. These days, of course, printers rarely burst into flames, but if there's something mysteriously wrong with the printer that's not one of the standard problems, who knows? (The message tends to come up if the kernel doesn't understand the printer status quite right)
See this linux kernel post.
Dang, I just tried to replicate this error for a funny screenshot, and apparently XP "does not work after year 2099" either, since it rolls back to 1980 instead of 2100. Maybe if I set it in the BIOS...
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
I was going to mention this one, but you beat me to it. I always thought that error message was a riot. I got it when trying to rename a file to the same name as a directory (in the same directory).
And it was "Disk Man", or at least that's the name on the icon of my 2500. (Powered up for the first time on about 2 years!)
Milalwi
Which is why you install the free and excellent MacsBug, which provides a much more informative and useful debugging environment than the BSOD.
May we never see th
Enlightenment configure script:
Checking for mass_quantities_of_bass_ale in -lfridge...not found!
Checking for mass_quantities_of_any_ale in -lfridge...not found!
-- Veni, vidi, dormivi
In a zero downtime environment, you may need to replace a faulty processor while the system is still hot. Most of these systems are multiprocessor though, which is why it exists.
Tired of legitimate data sources? Try UNCYCLOPEDIA
Totally OT but here's the deal on that:
- most newer PS/2 keyboards can be hot plugged with no problem
- most older (AT-style) keyboards with a PS/2 adaptor will cause damage
- the damage is actually caused by a filter capacitor in the keyboard drawing too much juice initially for the poor little fuse on the PS/2 port to handle. If you look at any mbd with PS/2 ports (and you know what a surface mount fuse looks like) you'll see one each for the mouse and keyboard
- newer keyboards (anything made in the last 4 or 5 years) are better designed and have smaller filter capacitors, hence less risk (if any) of blowing the fuse
- if you do blow the fuse you can just bridge it with a carefully bent paperclip or a bit of careful soldering; I've never seen any other part of the circuit take any damage after bridging, even with repeated hot-plugs of the keyboard (or mouse) which toasted the fuse originally
But yeah, hot-plugging anything that isn't actually designed for it is kind of asking for trouble.
Plus, an 8 megabyte (you used little b, I assume you mean bits?) BIOS wouldn't surprise me. I don't know what the BIOS sizes on newer motherboards are now, though.
mrg
No - what should happen is something like ...
An unexpected error has occurred. The details of the error have been recorded in the log file:
Log file name
Please email the above file to devteam@company.invalid.
Your currently-opened files have been saved as the files:
Filename 1
Filename 2
[Application name] will now quit.
and then quit as gracefully as possible.
This does a couple of things:
1. It saves the state in a logfile.
2. It tells the user what is going on, without confusing them.
3. It allows the user the option of opening the logfile and seeing what info they will be sending the developer.
4. It allows the user to recover their work (hopefully - not always possible).
This was a bug on some AMD K6 CPU's. The hlt instruction is used in an idle loop to tell the CPU that nothing's happening. The CPU can then reduce its power consumption and generally cool itself off if it gets a bunch of these instructions in a row.
This instruction is used as a power management technique, and also helps cool the cpu down.
Anyway the hlt instruction should work, but for some reason was broken on some AMD K6 cpu's. The solution was to pass a special kernel parameter (I think) to get linux to not use that instruction. Either that or compile without APM support.. I forget now...
'We are experiencing MVS processor spin loops, the programs are running while holding a disabled CPU. This is causing XCF communication delays to the point where we are losing VTAM RTP routing, are suffering OSPF adjacency failures on TCP/IP dynamic routing and MIM VCF failures. Whatever this code is, it should NOT be propagated to production or we run the risk of losing the development plex if XCF signaling is adversely impacted by processor disabled spin loops'.
You're confusing an error message with an operator's description of a problem. MVS can't display error messages while in disabled spin loops, the I/O interrupts are blocked by the "disabled" part!
You want a good example of bad error messages? How about anything except MVS messages? I'm serious - the MVS "Messages and Codes" manuals are huge, and list every message issued by the software complete with advice on what to do when you receive the message! How, one asks, can you find the right advice? Easy: every message begins with a "message identifier" - a short alphanumeric sequence that uniquely identifies it and points directly to the place where the doc lives.
Try that with your average Open Source project. Hell, try to just get a list of the errors reported, let alone advice on what to do when they are reported.