Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.sys.amiga
Subject: Re: Pal Jr.
Message-ID: <284@l5comp.UUCP>
Date: Thu, 4-Jun-87 02:09:24 EDT
Article-I.D.: l5comp.284
Posted: Thu Jun  4 02:09:24 1987
Date-Received: Tue, 9-Jun-87 01:57:18 EDT
References: <1135@crash.CTS.COM> <545@unisec.usi.com> <863@nscpdc.NSC.COM>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Organization: L5 Computing, Edmonds, WA
Lines: 38
Summary: Notes on hard disks and amigadog.

In article <863@nscpdc.NSC.COM> joemu@nscpdc.NSC.COM (Joe Mueller) writes:
>other is that while doing something that accesses the disk a lot, I get a
>requestor that says I have a read/write error. If I ask AmigaDOS to retry
>it always works so it looks like some type of timing problem. Both of these
In fooling with scottdisk.device I hacked in support for reporting errors.
(The original MicroForge driver I got didn't bother itself over this) I did
this because some weird things were happening with my system. I had just put
in a ST4051 and as it turned out it was a DUD. I keep getting R/W errors from
the dog when using a driver that didn't check error status. But when I had it
start returning the error, so I could figure out what the #$@! was going on,
the read/write errors vanished. What I got instead was other reactions.

My conclusion is that read/write errors come from amigadog when it checks the
checksum on the block that it has just read.

This sets off a couple questions in my mind that you may wish to ask Byte by
Byte.

Does their driver issue a sense status command to the SCSI controller when a
check status is reported? Or does it just assume the transfer went through?

If they do, how did those blocks get through??? :)

My driver nailed EVERY bad block off that ST4051 after I put in error checking,
I never saw another read/write error message. I started seeing "Transfer failed"
instead for example.

Another answer is that your ram is flakey. The block could be read into ram and
bit(s) get flipped before it's checksum got checked. And when you retried the
block was read in again and the bit(s) DIDN'T get flipped that time.

[ Above posted where CATS could see and comment ]

Scott Turner
-- 
L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM.
GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020
If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs
[ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)