mirror of
https://github.com/elliotnunn/supermario.git
synced 2024-11-26 16:49:18 +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.
|
|||
|
|
----------------------------------------------------------•----------------------------------------------------------
|