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