Well I have a war story to relate here.  When I was a poor student, I
came across a wonderful deal on Micropolis 4.5GB SCSI hard drives.  I
bought at least 4.  Of course, the deal was too good to be true,
because as I discovered over the course of a year or so that these
drives were flaky.  Seriously flaky.  They would occasionally
malfunction and hang the entire SCSI bus.  Needless to say, Unix
didn't appreciate this very much.  Any process accessing disk would
hang and become unkillable.  A soft reboot would hang trying to kill
processes waiting on disks which weren't responding, leading to a
creeping sort of deadlock which gradually froze the entire system.
Often, a hard reboot was the only remedy.

Somehow, in the process, disk blocks would get written to the wrong
places.  I suffered repeated corruption, and a very insidious kind --
a file would suddenly have a block replaced with other data.  When
this was a directory entry, I'd get many of the children appearing as
inode numbers in the lost+found directory at the next fsck.  One thing
I learned from this is that you really, really want your storage
subsystem to be reliable.  I ended up writing software to reattach
directory subtrees based on the filenames in them, based on the
directory trees I recovered from backups.  So the structural damage
wasn't unrecoverable, but having random blocks of data appear in my
files was something that occured so gradually that I'm sure many made
their way onto backups (there is no obvious failure mode to detect
that this has happened if you don't protect everything with tripwire
or something).

One time I was leaving to attend a security conference, and I had a
program I wrote which could do encryption of files in-place, so I'd
run it on the raw disk devices to protect the data while I wasn't
around.  In this circumstance I was very short on time, so I booted
off a custom floppy, started several crypts in parallel (one on each
disk), and left.

When I returned, the SCSI bus was hung.  I now had something like
seven hard drives, all partially encrypted.  Since the encryption was
committed a sector at a time, starting at the beginning, I found that
I could use dd and ent (an entropy calculation program) and do a
binary search for the point where it went from ciphertext to plaintext
(a sector is enough to distinguish the two).  Using this method, and
some hacks to the in-place encryption program, I was able to recover
all of the drives.

Next, using dd, I was able to determine that these drives would hang
when a read operation crossed the 2^31-1 byte boundary, indicating an
unhandled signed integer overflow in the drive firmware.  My guess is
that the wrap-around was responsible for placing the sectors of data
in apparently-random locations on the disk.  Since they were just over
4GB in capacity, perhaps Micropolis tried to use the same firmware
from a previous line, and this was the first model which was large
enough to trigger this problem.  In any case, I obtained software that
allowed me to upload firmware to the drives over the SCSI bus.
Collaborating with other individuals over the Internet, I was able to
fix the signed integer overflow (the drive controller was an Intel
80186) and get working firmware, which I put on all the drives.  The
drives never hung again, and one of those drives is still in use in
one of my machines today.

By some amazing coincidence, Micropolis went out of business around this time.

Note that uploading firmware to the drive didn't require setting any
jumpers, although the program was an MS-DOS program which presumably
operated in real mode.  I am thankful that malware writers haven't
included something like this in their payloads, because I can't think
of anything more annoying than someone turning my hard drives into
warm bricks.