SCSIMgr Release Notes
First created on: 3/17/92 6:11:02 PM

----------------------------------------------------------•----------------------------------------------------------

3/17/92 6:11:09 PM

File: SCSIMgrHW96.a,3
Owner: pete helme     
Project: MainProj∫OS∫SCSIMgr∫

Radar bug: #1021847

> Release notes for this change:

Fix the removable device bug (CD ROMs etc.) on Quadras which caused the “This disk is unreadable.  Do you want to format?” dialog to randomly appear.  Apparently there is a bug in the 53C96 chip which causes the FIFO count to get stuck on occasion.  We now flush the FIFO buffer to make sure the count is correct.

> What was tested:

This fix was originally run on a Quadra for several hours and the dialog never came up.

----------------------------------------------------------•----------------------------------------------------------
5/22/92 4:13:33 PM

File: SCSIEqu96.a,2
Owner: Dean Yu     
Project: MainProj∫Internal∫Asm∫

File: SCSIPriv.a,17
Owner: Dean Yu     
Project: MainProj∫Internal∫Asm∫

File: SCSIMgr96.a,4
Owner: Dean Yu     
Project: MainProj∫OS∫SCSIMgr∫

File: SCSIMgrHW96.a,5
Owner: Dean Yu     
Project: MainProj∫OS∫SCSIMgr∫

File: SCSIMgrInit96.a,4
Owner: Dean Yu     
Project: MainProj∫OS∫SCSIMgr∫

Radar bug: #1029009

> Release notes for this change:

From James Blair’s release notes:

“The bug involves the incorrect recovery of writeback data.  The order of the writebacks
has been modified to be correct (using the Motorola ‘040 specification).

“Modification to the DREQ bit testing has been implemented.  Instead of using an
immediate btst value (very BAD for compatibility and maintainability! - especially for
the braindead Quadra SCSI address space) a SCSI Mgr global was setup for the bit
location.


> What was tested:

“These mods were tested for hours on the hardware that the bug was reported and other C96
based Macs.”
----------------------------------------------------------•----------------------------------------------------------
7/31/92 12:52:40 AM

File: SCSILinkPatch.a,14     
Owner: Chris Derossi     
Project: MainProj∫OS∫SCSIMgr∫

Radar bug: #1035754

> Release notes for this change:

This is the fix for the now-famous System Error #41 problem caused by the Quantum
firmware bug. The short description of the problem is this:

Quantum 40MB and 80MB drives have a bug in their firmware which can cause their cache to
become corrupt. A subsequent read of data in the cache returns bad data without
registering an error. During boot, this can happen with the data for the Finder’s
resource map causing the Finder to fail to load.

For the Quantum bug to manifest, several conditions all have to be just right: the amount
of data being read must be within a certain range; another read of a small amount must
follow quickly; the data must be stored in a particular configuration on the disk. To
prevent this bug from happening, we make sure that the second read doesn’t happen quickly
enough. This is done by adding a delay between the two reads.

We want to delay for about 25ms, which we’ve rounded up to 30ms for safety. But we only
want to delay if we have to. We decide that we have to when: a read of 10 to 15 blocks
has happened last AND another read is about to occur before 30ms have passed. When these
conditions do occur, we delay for 30ms MINUS the time that has already passed. For
example, if 8ms passes between the first read and the second, we add only 22ms of delay.
This is to minimize the performance penalty for this workaround.

This delay logic has to be inside of the SCSI driver, which is read from the hard disk at
boot time. Since we want to fix the problem with Cube-E, whether or not the user has
update the driver on the disk, we patch all SCSI drivers in RAM. This patch uses the same
mechanism used by the 7.0 tune up. We check the code in RAM to make sure it is what we
expect it to be. If it is, we change a few instructions into a JSR into our patch. (We do
flush the cache for ’040 fans.) If the code is not what we expect, which will happen if
we’ve already patched that driver once or if it’s a non-Apple driver, or if it’s a
version of the driver we don’t know about, then we don’t change anything.

> What was tested:

I ran the system with this patch on my Quadra 950 (which has version $27 of the SCSI
driver) and verified with Macsbug that the driver was indeed patched in RAM. The driver
kept working fine and I saw that the delay was in fact happening periodically.

We have a Vail that has a 100% reproducable case of the System Error #41 crash. I put in
the System with the fix and the crash could not be reproduced. Just to make sure that the
new system wasn’t affecting anything else, I made an INIT version of the fix and added it
to the configuration that would always crash. Once again, the crash would no longer
happen.
----------------------------------------------------------•----------------------------------------------------------
8/1/92 4:30:07 PM

File: SCSILinkPatch.a,15     
Owner: Chris Derossi     
Project: MainProj∫OS∫SCSIMgr∫

Radar bug: #1035754

> Release notes for this change:

This is a better fix for the now-famous System Error #41 problem caused by the Quantum
firmware bug. The short description of the problem is this:

Quantum 40MB and 80MB drives have a bug in their firmware which can cause their cache to
become corrupt. A subsequent read of data in the cache returns bad data without
registering an error. During boot, this can happen with the data for the Finder’s
resource map causing the Finder to fail to load.

For the Quantum bug to manifest, several conditions all have to be just right: the amount
of data being read must be within a certain range; another read of a small amount must
follow quickly; the data must be stored in a particular configuration on the disk. To
prevent this bug from happening, we make sure that the size of the read is never in the
dangerous range of 10-15 blocks. We do this by changing any such read into two smaller
reads. This is better than the delay fix because it adds far less overhead.

This block size logic has to be inside of the SCSI driver, which is read from the hard
disk at
boot time. Since we want to fix the problem with Cube-E, whether or not the user has
update the driver on the disk, we patch all SCSI drivers in RAM. This patch uses the same
mechanism used by the 7.0 tune up. We check the code in RAM to make sure it is what we
expect it to be. If it is, we change a few instructions into a JSR into our patch. (We do
flush the cache for ’040 fans.) If the code is not what we expect, which will happen if
we’ve already patched that driver once or if it’s a non-Apple driver, or if it’s a
version of the driver we don’t know about, then we don’t change anything.


> What was tested:

I ran the system with this patch on my Quadra 950 (which has version $27 of the SCSI
driver) and verified with Macsbug that the driver was indeed patched in RAM. The driver
kept working fine and I saw that dangerous reads were in fact being broken into two
smaller reads.

We have a Vail that has a 100% reproducable case of the System Error #41 crash. I put in
the System with the fix and the crash could not be reproduced. Just to make sure that the
new system wasn’t affecting anything else, I made an INIT version of the fix and added it
to the configuration that would always crash. Once again, the crash would no longer
happen.

----------------------------------------------------------•----------------------------------------------------------
8/10/92 10:17:05 PM

File: SCSILinkPatch.a,16     
Owner: Chris Derossi     
Project: MainProj∫OS∫SCSIMgr∫

Radar bug: #1035754

> Release notes for this change:

At Paul Wolf’s suggestion, I flush the data cache as well as the instruction cache in
order to guarantee that we don’t get obsolete data out of the cache after we patch the
SCSI driver in RAM.

Also, since we’re modifying code in the SCSI driver, there is the possibility that a VM
page fault will fire and try to use the SCSI driver while we’re patching it. So, I turn
off interrupts while we’re patching the driver and reenable them after the caches have
been flushed.

> What was tested:

I created an INIT version of the patch and ran it. I watched it execute with Macsbug, and
everything looked fine. I also made sure that the driver was patched correctly in RAM.
----------------------------------------------------------•----------------------------------------------------------
