[net.micro.pc] AT hard disk failure

john@hp-pcd.UUCP (john) (03/14/85)

<<<

  "Without exiting turbo, I power-cycled the machine..."

Does this mean that you turn off your AT without running the SHUTDOWN
program that parks the heads?


John Eaton
!hplabs!hp-pcd!john

doug@cornell.UUCP (Douglas Campbell) (03/18/85)

*** REPLACE THIS LINE WITH YOUR AT HARD DISK ***

Well, after 5 months of using 3 ATs and feeling that the much-publicized
hard disk problems were blown way out of proportion, it got me last Saturday.
Sure enough, all of a sudden one of the ATs got ever-incresing disk failures.

It's a very bizzare problem.  I watched the disintegration of the disk with
fascination, having never experienced anything like this before.  I include
here my experience, with the hope that someone else can use this info to
help track down the problem.

I was running Turbo Pascal from DOS, and had just run a program a few times.
Without exiting turbo, I power-cycled the machine to reset a hardware board.
Everything came up normally, and I was placed in the root directory of drive
C.  I tried to move down to my sub-directory with the cd command, and the first
error occured.  These errors are detectable by the sound of the drive changing
speeds to read the track even before the error message occurs.  From that
point on, I would get somewhat random errors like "sector not found" or
"I/O error" or something else I can't remember right now.  There seemed to
be a pattern, however, in that almost always every other file access would
fail.  Also, files that would fail to read the first time would often read
correctly on the second attempt.

I then powered down and brought up Xenix to see if it was affected.  It was.
It reported random disk errors also, but not nearly so many.  This is likely
due to the fact that Xenix resides on the inner cyllinders while DOS resides
on the outer.  I then tried to reformat the whole disk.  First I ran the
Xenix badblock program.  This program found about 50 bad blocks, most of them
located toward the outer edge of the disk (cyllinders 550 on).  Interestingly,
though, the bad tracks were always 0 and 2 - never 1 or 3!  I ran the program
again to see if the bad blocks would be the same, and this time got about 150
bad blocks, mostly on tracks 0 and 2, but some on 1 and 3.  I didn't see any
blocks that were bad the first time that had been found good the second time.

Weird problem.  Anybody got any clues?
						Doug Campbell
						doug@cornell.{UUCP|ARPA}

jbn@wdl1.UUCP (03/27/85)

      You only have to park the heads if you intend to move the machine.