mirror of
https://github.com/elliotnunn/supermario.git
synced 2024-11-22 04:31:30 +00:00
191 lines
8.4 KiB
Plaintext
191 lines
8.4 KiB
Plaintext
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.
|
||
----------------------------------------------------------•----------------------------------------------------------
|