FixP5Scsi
_____________________________________________________________________________

Some P5 SCSI devices drivers accesses chip memory for a controlled busy-wait 
loop. I don't know precisely what this busy-wait is used for, but the device 
does this by accessing the chip memory location 0xffff0 like this,

	nop
	tst.w $ffff0
	nop

however, WITHOUT EVEN ALLOCATING THIS LOCATION BEFORE. Obviously, this makes
MuGuardianAngle SCREAM, and for good reason: What you see here is very bad
programming style and very questionable for a commercial product. First of
all, the chip memory timing depends on the DMA traffic of the native hardware
and hence on the screen solution. Second, even IF this busy wait has to made,
it is required to ALLOCATE the memory location used for the dummy read.

Unlike FixCybAccess, FixP5Scsi patches this problem by patching the code
of the device drivers just in place, and avoids this hit. I haven't seen
any problem by just removing this dummy wait here.

Currently, the following device drivers are patched:

2060scsi.device
2040scsi.device
cybscsi.device
z3scsi.device
1240scsi.device
1260scsi.device

In case you own a P5 SCSI board that shows similar symptons as mentioned
above (namely, dummy reads from 0xffff0) and that is not on the list, please
let me know.


This fix *DOES NOT* fix the general DMA related problems of the cybscsi.device, as 
for example not calling the Os functions CachePreDMA() and CachePostDMA() and hence
passing a (possibly invalid) logical address to the DMA logic instead of
the true physical address.

You only need to run this program if you want to use the MuGuardianAngel. To
install it, type

FixP5Scsi

on the shell. It will patch the problem right away in the device driver
and need not to be run to be permanently active.