[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCSI drive woes
- Subject: Re: SCSI drive woes
- From: dempson@actrix.gen.nz (David Empson)
- Date: 1998/02/28
- Newsgroups: comp.sys.apple2
- Organization: Empsoft
- References: <6d2196$4p9$1@server05.icaen.uiowa.edu>
ISCA AppleII Librarian <apple2pd@icaen.uiowa.edu> wrote:
> I recently was given some old SCSI harddrives which came from older Macs.
> I also finally order an external SCSI case and power-supply from Alltech
> so I can test these drives. I have put the drives into three piles:
>
> The good, the bad, and the UGLY.
>
> The UGLY is a Quantum 40S (40meg scsi) with the Apple sticker indicating
> it (was) is a Mac compatible scsi drive. I call it 'the drive from HELL' ;-)
[snippage]
> I ran a couple p8 disk verify programs (Apple Utilites verify disk and
> AW5.1 Disk verify and read/write verify programs on the disk without problems.
> From the GS/OS finder I copied files (>1000) from my boot drive to the UGLY
> without problems. The drive seems stable, quiet, and reliable. I could now
> even partition with ADU.
Partial explanation: if there was a block that ADU could not read near
the start of the disk, it may have reported an error before writing the
partition map. If a block with a soft error was written to during the
test, then it would now read OK, and this is probably sufficient to
allow ADU to partition it (though I wouldn't trust the drive).
[more snippage]
Summary: it appears that the drive is handled fine under GS/OS, but has
strange behaviour under ProDOS-8.
The obvious difference is the GS/OS SCSI Manager vs the firwmare driver
on the SCSI card. These are not identical, and may have different
responses to unusual conditions. For example, if the drive is flakey
and is reporting a minor error, it is possible that the SCSI card
firmware will throw its hands up in horror and report a read error,
while the SCSI Manager knows about the error and ignores it.
What is really puzzling me is that you say you can use data files on the
disk from ProDOS-8 applications, but you cannot launch ProDOS-8
applications on this drive.
There is no technical difference between, say, verifying a P8 SYS file
in a P8 program, and loading it for execution. I can't see how one
would work and the other not.
> There are at least THREE things I can NOT do:
>
> 1) Boot from the drive. (I quit from the Finder, power down, power off
> the boot drive, and power up the IIGS. All I get is the sliding apple,
> not a SCSI boot error, or other bizarre behaviour.)
Possible explanation: nothing is supplying termination power (except
your normal drive, which is now switched off). Try leaving both drives
on but swap their SCSI IDs (you will need to turn them off, change the
IDs, then turn them on again).
Otherwise, it could be a problem with the drive not responding quickly
enough to a SCSI INIT operation - if it takes a few seconds to "appear"
then booting from it will fail, but when booting from the other drive,
GS/OS will see it fine by the time the SCSI Manager and hard disk driver
are loaded.
If you try to boot from it, then the drive doesn't appear in time, and
the SCSI card thinks there are no devices connected.
P8 might be OK if booted directly from your other drive, because it will
take a couple more seconds before trying to find this drive. However, I
doubt this will be enough of an extra delay.
> 2) Launch a p8 SYS file on the drive, from the Finder, or a p8 application
> like Davex. From the finder, prodos 2.0.3 launches, the sys applic
> name show at top of screen and then I get a please insert disk message
> followed by a can't launch next application error = $0045, and then I
> return to finder.
This is a "volume not found" error. Also rather bizarre - it usually
occurs if P8 2.x doesn't have enough unused unit numbers to be able to
access a high numbered SCSI drive partition, but that shouldn't be the
case here. Otherwise it means that the system was able to read the
volume but the directory was damaged and the name doesn't match (also
not likely). Pass.
> From p8 (davex or basic.system), the chosen p8 sys file on UGLY tries
> to start, can't and I get the equivalent of a device not connected
> message. S16 applics are no problem. They launch, run, and exit just
> fine on UGLY drive from HELL's partitions. p8 SYS applics will NOT
> launch.
Have you tried doing a BLOAD on a SYS file from BASIC.SYSTEM (don't
forget the ",TSYS" parameter)? If that works, the puzzle gets deeper...
I have a theory:
There is some kind of weird problem with the drive that is reporting
errors when two reads occur in quick succession, possibly requiring a
head movement. This might behave differently for certain files,
depending on where they are located on the drive.
Nah, sounds rather iffy.
> One exception (so far) is CSU. Yes I can run CSU (chinook scsi utils)
> from the UGLY drive. Only SCSI ID 6 drive is shown. And I can quit
> CSU back to the Finder. But ... after CSU is exited, UGLY is forever
> lost to P8 (device not connected), but not to GS/OS and the Finder,
> until I reboot.
Partial explanation for this: CSU does a SmartPort INIT call, which
rescans the SCSI bus for devices. If the drive did not respond to this
call, then it would be lost to ProDOS-8.
An interesting point here: I think if you boot GS/OS and then launch P8,
then no SCSI INIT call is ever performed explicitly (just the firwmare's
own boot-time initialization).
This might be a problem with the drive taking too long to respond after
a SCSI INIT sequence (GS/OS has a longer timeout than the SCSI
firmware). If so, it is impossible to access it using CSU (unless the
program is patched to bypass the INIT operation, but unfortunately this
is essential after operations like partitioning).
Oh well, at least I could answer one question (why the drive doesn't
appear under certain circumstances).
--
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand