Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!uokmax!servalan!epmooch!ben From: ben@epmooch.UUCP (Rev. Ben A. Mesander) Newsgroups: comp.sys.amiga.hardware Subject: Re: A2091 rev 6.6 ROM announcement Message-ID: Date: 3 May 91 14:10:18 GMT References: <8860@ucdavis.ucdavis.edu> <07643.AA07643@babylon.rmt.sub.org> Lines: 35 >In article <07643.AA07643@babylon.rmt.sub.org> rbabel@babylon.rmt.sub.org (Ralph Babel) writes: >In article , rkushner@sycom.UUCP >(Ronald Kushner) writes: > >> September I bought a GVP Series II, and it didn't work >> properly with 2 drives either, it would send the heads out >> of range on my ST-296NPR! CRUNCH! OUCH! R/W ERROR! > >This is utter nonsense! > >The driver will only access blocks that have been requested >by the filesystem. There is NO WAY a SCSI host adapter's >driver could step a drive's heads outside the valid range - >SCSI isn't ST-506 or trackdisk.device! Something like this >could only be done by the SCSI drive controller's firmware. >And even _if_ an invalid block would be requested, then the >drive is supposed to reject this request with an error. You are correct. When I initially partitioned my ST-296n, the Microbotics mountlist initially had one too many cylinders. The drive does not "send the heads out of range." The drive returns an "Illegal Request" SCSI sense code when access to those blocks was detected. Note: I used to develop SCSI firmware for CDC/Imprimis/Seagate. I *know* this to be the case. SCSI does *not* access the drive on a cylinder, head, sector basis, and can *not* cause the drive to slam its heads. Now you may have a defective drive, that's another matter. >Ralph -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |