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. ----------------------------------------------------------•----------------------------------------------------------