Path: utzoo!utgpu!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Hard Disk Problems
Message-ID: <5181@cbmvax.UUCP>
Date: 4 Nov 88 09:28:00 GMT
References: <649@ecrcvax.UUCP>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 97

In article <649@ecrcvax.UUCP> micha@ecrcvax.UUCP (Micha Meier) writes:
> The guru type varies, sometimes
>it's freeing a memory twice, sometimes illegal instruction or key already
>free/used.
...
>	- is it normal that my hard disk won't validate after a guru?

	It's certainly possible, especially since the Guru appears to be
disk-related, or writing to the disk was going on.  I disk that was being
written to during a crash can have any sort of garbage on it.

>	  Why does this happen? Sometimes it's validated after a reboot,
>	  sometimes not; sometimes it is possible to write to
>	  a non-validated disk and sometimes not. Meanwhile I've changed
>	  my t: setting to ram: and didn-t get any validation
>	  problems since then, but I haven't tried it many times.
>	  Is it possible that the validation problem is only due to t: ?

	Well, if the compiler crashes the system during a write to t:,
or when a file in t: is open, it will force a re-validate.  If there are
problems with the drive, they may show up during validation, or a crash
during write to the disk could destroy some important sectors, like the
root block, or a directory header block.

>	- I got a guru when trying to delete a .o file of zero length
>	  created by the compiler before it crashed. Does it mean that
>	  there is a hard/soft error on the disk? The PD programs I know
>	  of are able to restore files but not to repair the disk
>	  itself - is there a program somewhere that would do this?

	Which guru?  Was it one of the "DOS" guru's, like invalid key?
BTW, key == block number.  For saving data from dead drives, DiskSalv,
by Dave Haynie (on Fish disks, there's an _old_ one on Fish 20, I think
there's a new one on a rectent fish disk), appears to be very good at
recovering disks that have been wiped.  Note: the old version doesn't work
with FFS, the new one does.  Also note it copies the files to another disk,
instead of repairing in place.  This is good because then you can re-format
the drive, and restore.

>	- Since I have no other programs, I've tried diskdoctor
>	  to repair the hard disk. It ended up by saying that two
>	  keys are not readable. What is the key? How is it related
>	  to the cylinder/head? When I've run diskdoctor for the second
>	  time, it wrote the same message. I suppose therefore that
>	  it does not try to correct the disk or that it did not succeed.

	Key is the block number (sector number).  divide by sectors/cylinder
to get the cylinder, take the remainder and divide by sectors/track to get
head number, the remainder is the sector number.

	Sounds like there are two blocks that can't be read (read errors.)

>	- Is there a way to tell Amiga that there are some errors on the
>	  hard disk without running the hard format? When I've tried to
>	  reformat the disk with dpformat (I'm using a PC disk, ST-157R),
>	  nothing really changed.

	All controllers I've seen so far require a hard format to map out
bad sectors (NOT amigados format command).  Check the manufacturers
documentation for your hard drive.

>	- Even with the complete format, I cannot tell the controller
>	  that there are some bad tracks on the disk since it asks
>	  for the BFI number. Can someone tell me what BFI is (I know
>	  what it stands for but this does not help me) and how to
>	  work it out?

	BFI - Bytes From Index.  Note there are two BFI's: RLL and MFM.
Usually RLL drives have errors listed in RLL BFI, MFM (normal, older) drives
use MFM BFI.  For 512 bytes sectors, 1-1 interleave, I THINK the conversion
from sector->BFI is sector*(512+85) + (~256), which puts the error in
the "center" of the sector.  I'm not 100% certain this will work for RLL
BFI, and it certainly won't work for non 1-1 interleave.

>	- If I'm wrong and there is no hard error on the disk (after all,
>	  I've reformatted it several times and run some PC tests on it),
>	  what can be the problem? If it is only in the compiler, is it
>	  possible to prevent it from messing up the disk when it crashes?
>	  I somehow cannot make the ROM-wack work, when I
>	  loadWB with -debug and select the Debug menu, it just does nothing,
>	  is there something I'm missing?

	Format == AMigaDos Format command or manufacturers low-level hard
format program?

	In general, having a compiler Guru while writing to disk is a VERY
bad thing.  Can mess things up bad.  The question is whether the compiler
is dieing, and in the process trashing the HD, or whether the HD has bad spots,
and this is causing problems when the compiler writes to them.  I'd suspect
the first, especially if you don't get read/write errors.

	LoadWB -debug: Do you have a 9600 baud terminal attached to the
serial port?

-- 
You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software.
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup