[net.micro.mac] MacSCSI problems

weber@brand.UUCP (Allan G. Weber) (11/20/85)

About two weeks ago I finished collecting together the pieces to build the
MacSCSI hard disk described in Dr. Dobbs Journal.  The first time I got it
all plugged togther, it came up just like the documentation said it would
and seemed to work fine.  Since then, however, the reliability of the disk
has rotted away to the point that it is now almost useless.  Some of the
problems that I've seen are:

1. Disk mounting program gets hung.  Mac has to be rebooted to recover.
2. Mount program executes with no apparent problems but when the finder
   comes back up, the disk icon for the hard disk isn't on the screen.
3. Programs report errors writing to the hard disk.
4. Finder reports that it can't build the desktop for the hard disk since
   it's write-locked (which it isn't).
5. Programs run from the hard disk "bomb" with great regularity and an
   amazing variety of error codes.
6. Disk formatting program hangs before doing anything.
7. Disk formatting program starts to format but doesn't complete due
   to write errors.

The problems are getting worse as time goes by.  What started out as an
occasion error has grown to where the thing is effectively useless.  A lot
of the problems could be due to an increasing number of bad blocks on the
disk but I don't know what would be causing this.

My configuration is the SCSI Interface from Fastime, a Xebec S1410A
controller, and a Shugart 604 5mb disk.  I would be interested in hearing
from any other MacSCSI builders who have had similar troubles (or lack of
them).  If anybody has any advice, I'm in the mood to listen.  Thanks.

Allan Weber
ARPA:  Weber%Brand@USC-ECL
UUCP:  ...sdcrdcf!oberon!brand!weber

rick@ut-ngp.UUCP (Rick Watson) (11/24/85)

It sounds like you are getting disk errors.  Unfortunately, the Fastime
software does not really report errors back to the system correctly, so
it is possible to have really bizarre problems if you get disk errors.

I am posting ReadXebec and TestControl to net.sources.mac. ReadXebec
will read all the sectors on a 5 or 18 megabyte drive connected to
a S1410A controller. It reports the controller internal error counters
before and after reading all the sectors. It also reports any read
errors as they are encountered. It reads the disk in "don't correct
errors mode" so that even correctable errors are reported.
Note that this may not work with S1410 controllers that don't
have the "retry stats" command. Click the mouse to abort early,
and at the end to exit the program.

TestControl reads and writes the sector buffer in the S1410A controller
without reading or writing the disk.  It should run with absolutely
no errors.  If you do get errors, you have a Mac <--> S1410A
problem, which could cause endless untold errors. Again, I don't
think this will work with S1410 controllers. Enter 0 for the
pass count to end the program.

If ReadXebec gets errors, run it again several times. If you 
get errors on the same sector every time, you probably have bad
spots on the disk.  If the errors are more random, you probably
have a bad interface, controller, power supply, cable, etc. 
Try wiggling cables when it runs. Check your power supply voltages
for accuracy.  Clean your connectors, but if you use a pencil
eraser, be sure not to be too industrious as you can erase all
the gold off the contacts.

Hope this helps.

Rick Watson
University of Texas Computation Center
 arpa:   rick@ngp.UTEXAS.EDU   rick@ngp.ARPA
 uucp:   ...seismo!ut-sally!ut-ngp!rick   rick@ut-ngp.UUCP
 bitnet: ccaw001@utadnx
 phone:  512/471-3241

vishniac@wanginst.UUCP (Ephraim Vishniac) (11/25/85)

> About two weeks ago I finished collecting together the pieces to build the
> MacSCSI hard disk described in Dr. Dobbs Journal.  The first time I got it
> all plugged togther, it came up just like the documentation said it would
> and seemed to work fine.  Since then, however, the reliability of the disk
> has rotted away to the point that it is now almost useless.  Some of the
> problems that I've seen are:
> ...
> 4. Finder reports that it can't build the desktop for the hard disk since
>    it's write-locked (which it isn't).
I think I know what this problem is.  The disk driver supplied with MacSCSI
interface is based on the ramdisk driver supplied with Aztec C.  That driver
doesn't respond to status calls correctly - it leaves the status info
unmodified.  The result is that if the most recently mounted volume was
locked, then the ramdisk (or hard disk, in this case) will appear locked 
also.  This is only one of an amazingly large number of "holes" in the driver.
It only works under ideal conditions.

-- 
Ephraim Vishniac
  [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac
  vishniac%Wang-Inst@Csnet-Relay

dave@rocksvax.FUN (Dave Sewhuk,840-5H,76248,2883513) (11/27/85)

/* rocksvax:net.micro.mac / weber@brand.UUCP (Allan G. Weber) /  1:47 pm  Nov 20, 1985 */
I had this problem early on.  My cable in the Mac was a little loose and not
all the command signals made it.

    About the disk ICON not appearing, I found a serious bug in the initialize
disk routine.  I wrote a quick hack which allows me to cycle through all the
steps individually to help me find problems. It is a crummy un-Mac-like
program but it is was quick and dirty.  It allowed me to cycle reads and write so that I could use a scope to watch to SCSI bus.

If you look in the code that initializes block #2 you will see something like
	while (mumble, p=mumble; p<&p_lastbyte ; p++);
		      should read
	while (mumble, p=&mumble; p<=&p_lastbyte ; p++);
				   ^
    I know for a fact that the drive will not mount if a lower case 'd'
sat in the last byte of that parameter block.

    Also note that ScsiIn() always reads in chunks of 8 bytes no matter
what value you request.  It gets rounded up to next set of 8 bytes.

    I had the thing running in about 2 days.  Also I still have not been
able to figure out how to make it start up using an MANX system disk.
I had to take a generic system disk, Set Startup MountSCSI and boot
to the finder and do a OPT-SHIFT Finder to run from the disk.  I
have the same problem using mountRam.   Starting the Shell from
the Finder makes all work well for me.  Once I got that running all
has been running well for me.  I think that the SHELL fragments memory
badly so that it cannot load some important thing in memory when you
switch system files.  I noticed that it tended to grab most of the free
memory when I ran a show free mem desk acc.

    BTW, I am using a SMS FW5000 controller (I also tried an OMT10) with
a Quantum Q2020 drive.

My system has been very stable, but I have only run it less than a week.  I
was amazed how quickly things went together.  Overall, I think the FastTime
interface is a nice piece of work, although it took them a long
time to ship mine.  It sure is fun to have every font, every desk acc,
every game, and stuff on one disk and have 2000K free. It does appear to run
about as fast as a hyperdrive.  My MacWrite startup took about 6 sec instead
of 5.5 that their ad claims.  When I get things tuned a little better
I ought to be able to meet or beat that one!!

Running the hard disk shaves a bit over 2 minutes off the compile of
the MacSCSI code itself.

Dave

arpa: Sewhuk.HENR@Xerox.ARPA
uucp: {ihnp4,rochester,amd,sunybcs}!rocksvax!dave
ns: "Sewhuk:HENR801C:Xerox".ns@Xerox.ARPA