Computer Voodoo?

jbeaupre asks: "A corollary to 'Any sufficiently advanced technology is indistinguishable from magic' is that sometimes users have to resort to what I call 'computer voodoo.' You don't know why it works, you barely care how it works, but you find yourself doing the strangest things because it just seems to work. I'm talking about things like: smacking a PC every 5 seconds for an hour to keep it from stalling on a hard drive reformat (with nary a problem after the reformat); or figuring out the only way to get a PC partially fried by lightning to recognize an ethernet card, after booting into Windows, is to start the computer by yanking the card out and shoving it back in (thereby starting the boot processes). What wacky stuff have you done that makes no obvious sense, but just works?"

Comments

hitting it

[crazedotaku]

Usually whenever it would start going on the fritz a good punch or kick to the tower would get it going again. And also stop that damn whirring noise. It always makes me laugh when I'd see people hitting the monitor. Because THAT is where everything is XD

Re:hitting it

[dadragon]

Well, I've hit a monitor because that's where the problem was! It had that God-aweful flyback transformer noise. Hitting it ever 15 minutes or so would make it go away for a while. Then it got fuzzy, so I bought an LCD instead of fixing it.

Re:Current computer

[MyDixieWrecked]

I'm not sure I'm reading your post right (no pun intended), but...

some BIOS require certain devices to be present to pass the POST. I discovered this the hard way when setting up a headless server. I spent 20 hours installing gentoo, got the services all nicely configured and put the machine in the corner, and it never went online... so I pulled it out and brought it back to my desk and it booted fine.

I didn't find out that it was keyboard/monitor missing errors that was preventing the system from booting until I carried the monitor to the other side of the room and plugged it in and saw the keyboard error... then I poked around in the bios and saw the options for requiring keyboard and monitor.

Re:Always remember...

[KiloByte]

...you gotta type 'sync' three times before it works.

Don't laugh so loud. While running it thrice is indeed voodoo, there are Unices where you actually need to sync twice.

The POSIX semantic is: sync() doesn't have to actually write everything, it can just schedule the commit. However, a second sync() won't return until the writes from the previous sync() finish.

On Linux, a single sync is enough, though.

Re:Not sure how it works...

[Roadmaster]

Here's how it works.

IDE drives keep a list of spare sectors to be used if one of the "primary" ones gets damaged. However, if a sector gets damaged and it already contained data, the drive won't reallocate it, because it would have no way of recovering the information. So it keeps "hoping" that some day the data will be readable again, and when that happens, it'll reallocate the sector. However, it never happens.

When you overwrite a defective sector, the drive says "aha! since the user overwrote the information, it means it's not important anymore; so I'll go ahead, mark the sector as bad and replace it with a spare". That's why overwriting gives the drive a chance to remap all bad sectors to clean ones.

This is a trick I learned by reading the documentation on smartd; if SMART reports defective or unreadable sectors, there's a way to figure out which files reside in those sectors and overwrite them with zeroes; the file will of course be lost, but by overwriting you let the drive reassign the sector and everything is peachy again.

By the way, if you reformat the drive with the destructive verification option (-c -c) it's likely that when the test overwrites to verify readability, the same reassigning process will take place; the standard "-c" test is a read-only test that's why you're unable to format a drive without the overwriting procedure.

So you see, not voodoo. :)

Re:Not sure how it works...

[spinja]

This trick even works non-destructively: dd if=/dev/hda of=/dev/hda bs=512 A friend of mine showed me this method a few years ago and it has helped recover failing drives over a dozen times since.

Mod parent up!!!

[Fallen Kell]

If I had mod points left I would have done it myself. I never actually thought to try and do that. It makes perfect sense now that you said it. I always assumed that when used dd setting the input file and output file to the same thing would cause it to get stuck in an infinite loop. But now that you posted that and I thought it out some more, it makes perfect sense. DD will just grab the amount of data you specified as the block size from the input file and dump it to the first part of the output file (which in this case would be the same section of the disk). It will then increment by the block size on the input file and place copy it to the output file by the same incrementation of the block size, rinse, repeat ad infinum until it hits EOF...

Again, great little one liner command to remember in the tool bag...

Re:Mod parent up!!!

[statusbar]

The hard drives do a dynamic re-mapping of bad sectors to a different area. If you write an entire sector, and the sector was already marked a 'unreadable', the drive has an opportunity of using the 'secret' sector area instead. From then on, reads for this sector will come from the secret area. There are a limited number of secret tracks.

This is one of the 'gotchas' with multimedia content. A hard drive may have fast access times and a fast bus, but if there are persistent CRC errors (and there is quite often CRC errors on a non-failing drive!), then the drive may have to take 15 or so separate reads of the track to reconstruct - It may also temporarily move the surrounding tracks to the secret area, then zero out the surrounding tracks in order to reduce track-to-track crosstalk.

All of this takes time, and quite often any real time media bandwidth budgets get blown when this happens.

The neat thing is, when this does happen, it is never an error. The program does finally get the data, but it just takes longer than expected. Typically one way to find out if the drive has remapped tracks on you is to have a program which measures track to track access time sequentially, and find the track boundaries that take a lot longer than a move from adjacent tracks should.

Jeff

Re:Walk into the room

[grcumb]

Computers mysteriously start working again when you enter the room? Feh. This hardly qualifies as Voodoo. I mean, it's got a perfectly rational explanation:

quantum bogodynamics: /kwontm boh`gohdi:namiks/, n.

A theory that characterizes the universe in terms of bogon sources (such as politicians, used-car salesmen, TV evangelists, and suits in general), bogon sinks (such as taxpayers and computers), and bogosity potential fields. Bogon absorption, of course, causes human beings to behave mindlessly and machines to fail (and may also cause both to emit secondary bogons); however, the precise mechanics of the bogon-computron interaction are not yet understood and remain to be elucidated. Quantum bogodynamics is most often invoked to explain the sharp increase in hardware and software failures in the presence of suits; the latter emit bogons, which the former absorb. See bogon, computron, suit, psyton.

Here is a representative QBD theory: The bogon is a boson (integral spin, +1 or -1), and has zero rest mass. In this respect it is very much like a photon. However, it has a much greater momentum, thus explaining its destructive effect on computer electronics and human nervous systems. The corollary to this is that bogons also have tremendous inertia, and therefore a bogon beam is deflected only with great difficulty. When the bogon encounters its antiparticle, the cluon, they mutually annihilate each other, releasing magic smoke. Furthermore 1 Lenat = 1 mole (6.022E23) of bogons (see microLenat).

Re:Hard Drive Massage

[RealityMogul]

Sometimes taking the drive cover off and watching what it is doing helps. My uncle had a drive that died and would just click at startup. Upon watching it "click", I realized the head was just snapping back from the position it was trying to read. Solution: physically hold the read head in place when it tried to reset. Worked well enough to get the drive booted as a slave and copy all the important stuff off of it.