Per a few private requests, I found enough interest to post a thesis for all to see about the SCSI ID 5 issue.

Starting with SCSI Manager 4.3, or System 7.5, or different SCSI hardware architectures – you get the time frame – a sudden issue began happening with SCSI ID 5 on many Macs. This has some technical problems, and I will probably paraphrase certain sections or use analogies without stating them properly – be forgiving, techies, and realize the point that I’m trying to get across.

Timing – There is a timing issue with SCSI devices on Macintosh that has to do with SCSI Manager 4.3 and the new SCSI controllers – the SCSI bus is divided into two sections instead of one, so that asynchronous access can be performed at a faster rate. Additionally, more Plug and Play features were available with SCSI Manager 4.3, and the issue rears it’s ugly head again. The binary bit for SCSI ID 5 is “101”. This is the first ID available on the second “channel” of the SCSI controller. The timing issue is that this ID can often be skipped if other devices on the chain are in use when the scan commences. This really has nothing to do with the device – the software and hardware involved on the motherboard makes the skip. This can lead to slow data transfers or a device not being recognized on bootup. The problem seems intermittent, and Apple released several updates that were designed to help this, but never completely solved it. In the end, their TIL recommended that the ID be avoided if possible, and patches applied if not possible to avoid.

Removable SCSI Devices – The timing issue is compounded by removable drives – a device may recognize that a cart is inserted and send the proper SCSI command on the chain to the computer, but if the device isn’t recognized at that particular moment due to the timing issue, then the mounted device command is lost, and the cart may need to be ejected and reinserted again for the computer to notice the drive. Zip drives and CD-ROM drives were noted as the biggest culprit, and CD-R devices would fail in writing because of the problem – suddenly the device at ID 5 would disappear under heavy SCSI load from the hard drive, and Toast (or other CD-R programs) would report an error and ruin the CD-R media. This occurred frequently because the first bits – 0, 1, 2, 3, 4, are the higher priority bits – any device in 5 and 6 are lowest priority on the chain.

Scanners (and Other High Load SCSI Devices) – During a scan, if the ID was skipped, a scan might stop or become corrupted because of the timing issue of SCSI ID 5. Additionally, scanners would ghost – they may or may not show up at any given moment. Ethernet adapters on ID 5 would drop network connections more frequently, since AppleShare polls network devices every 2.3 seconds.

Why Not SCSI ID 6? – Yes, SCSI ID 6 should have the same problems, being on the other channel. The advantage of SCSI ID 6 is that, according to true SCSI specs, this is the normal first bootup device, so it is always polled on bootup. It has the highest priority level in SCSI controllers (hardware). This means that any device on SCSI ID 6 really has higher priority than any other device, but it is immediately de-channeled to the second channel by SCSI Manager 4.3. In the end, it’s slower, but it will always show up.

CD-R Addendum – Macintoshes with CD-R problems are often exacerbated by a common issue – if a second hard drive is placed at SCSI ID 1, and the CD-R is at SCSI ID 5, there is a perfect timing issue – ID 1 is the mirror on the chain that can take up the timing loop that would include the SCSI ID 5 scan. More times than I care to remember, moving the CD-R to ID 2 solved the problem without issue.

Corrupted Hard Drives/Removable Carts – These both had data reliability problems with long copies on SCSI ID 5 – the reason should be obvious. Additionally, drive space would be corrupted by improper writes. Device speed and transfer would be much slower on this ID than on others because of the failures. But certain removable cart drives were stable on this ID, simply because of their redundant nature and persistent caching of cart data. SyQuest removables are the only safe devices I’ve found – Mag Ops, etc. Not Jaz or Zip. I’m talking about 44/88 MB, and 230 MB, 560 MB, and 2.2 GB carts – the big bad hard drive platens or Mag Op carts used before Jaz and Zip came into the arena. These older devices implored more heavy duty SCSI controllers, which would confirm SCSI commands and be more stable. Newer devices are cheaper and much less reliable in this ID.

Any further questions or comments are appreciated, as well as corrections. If there’s something I’ve explained improperly, please feel free to chew me out. I’m always looking for a better way of saying what I’m thinking.

Scott L. Barber <serker@earthling.net>

Pres/CEO, SERKER Worldwide, Inc.

Providing Hardware/Networking/Telecomm for 13 years

The Take Away

SCSI ID 5 can be problematic, especially for writing data. When possible, avoid using SCSI ID 5. If you have enough devices that you need to use it, use it for a read-only device such as a CD-ROM drive or scanner – this way you avoid writing anything to any type of writable media (hard drive, removable media drive, CD-R, etc.)

Scott L. Barber originally posted this to Quadlist, the listserv for users of 68040-based Macs. It is reprinted with his permission.

Keywords: #scsiid5

Short link: https://goo.gl/0mVLaL

searchword: scsiid5