[lkml]   [2003]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Undo aic7xxx changes (now rc7+aic20030603)
On Tue, 24 Jun 2003 23:26:09 +0200, Stephan von Krawczynski said:

> sorry, you probably misunderstood my flaky explanation. What I meant was not
> cached block from the _tape_ (obviously indeed a char-type device) but from t
> 3ware disk (i.e. the other side of the verification). Consider the tape
> completely working, but the disk data corrupt (possibly not from real reading
> but from corrupted cache).

Don't rule out odder explanations either. True story follows.. ;)

I once had the misfortune of being the admin for a Gould PN/9080. UTX/32 1.2
came out, and since it changed the inode format on disk, it's dump/mkfs/restore
time. So I take the last 3 full backups, and do 2 more complete dumps besides.
I checked, and *NO* I/O errors had been reported (and then I checked THAT by
giving it a known bad tape and seeing errors WERE reported).

Do the upgrade... and *every single* tape was 'not in dump/restore format'.

Finally traced it down (this was the days when oscilloscopes were still useful)
to a bad 7400 series chip on the tape controller. The backplane was a 32-bit
bus, the tape was an 8-bit device - so there was a 4-to-1 mux that had a bad
chip. Bit 3 would be correct for 4 bits, inverted for 4 bits, correct for
4, etc.. Tape drive *NEVER* complained, because what came over the *cable*
was correct, parity and all..

Oh, and I got the data back something like this:

cat > mangle.c
main() {
int muck[2];
while (read(0,muck,8) == 8) {
muck[1] ^= 0x20202020;
cc -o mangle mangle.c
dd if=/dev/rmt0 bs=32k | ./mangle | restore -f -

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:36    [W:0.140 / U:1.760 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site