🚀 go-pugleaf

In article: <817232741snz@wookie.demon.co.uk>  John Beardmore 
> Do what is this "diskchange flaw" then ?  How do you know you have it ?
> Is this floppy or HD ?

Here's a list of the confirmed flaws that I know about on the cmd640 & the 
rz1000 (it has some references to IBM drivers used under OS/2, as it's taken 
from the PCI IDE FAQ on c.o.o.misc) :

1) CMD 640 (CMD Technology Inc.)

   There are four problems with this particular chip.  Here's the
   first one:

   Channels (two IDE drives may be attached to each IDE channel) cannot
   be operated concurrently because there is a single I/O queue for both
   channels.  Simultaneous reads to both channels will cause data
   corruption.  This is not mentioned in the chipset errata.

   Here's the second one:

   Their stand-alone PCI board does not have a BIOS and appears to
   come-up disabled per the PCI definition. Its really difficult to
   tell whether a PCI-IDE controller is operating in 'legacy' mode
   since (at least) the CMD chipset does not update the PCI config
   space with the legacy base port addresses. Also convincing PCI to
   route IRQ 14/15 to a PCI Int is problematic unless the motherboard
   BIOS explicitly supports this function.

   Here's the third one:

   The CMD chipset also has a documented restriction that it will not
   support DWORD config write cycles.  Of course the Award BIOS on the
   (Vobis) motherboard on which testing was being performed did not
   issue byte/word config cycles explicitly and instead implemented all
   config read/write services as read/modify/write of DWORD data. The
   net result was that the system PCI BIOS could not be used to program
   the motherboard chipset!

   Here's the fourth one:

   Some systems have the floppy drive changeline connected to the same
   line as the 640 chipset.  With this setup, data corruption can occur.
   The reason is this:

   The chip fifo is used not only to contain data, but to contain chip
   status as well.  As a consequence of this, the following could occur:

   Floppy I/O starts.
   HD I/O starts.
   HD I/O is just about finished when floppy I/O finishes and a request
   to start different floppy I/O is made.
   At this point, the floppy changeline status is read from the floppy
   changeline status register, at location 3f7.  If there is data in the
   CMD chip waiting to go to the disk at this point, two bytes of it are
   _removed_ and replaced with the floppy changeline status.  This, of
   course, causes data corruption.


PC Tech RZ1000  (PC Technology Inc.)

   Produces accelerated IRQ.  IBM1S506.ADD actually tolerates this.
   However, when the driver reads (HEX address) 1x7 during interrupt
   processing to clear the interrupt, the chipset puts the status in its
   read-ahead FIFO resulting in data corruption. Intel used this chip on
   their motherboards which they sold to Gateway, AT&T, IBM and others.

   This feature is not mentioned in its chipset errata.

   The second bug was discovered only recently by PowerQuest.  It has
   been the source of much discussion on UseNet.  Here's how the
   now-famous bug occurs:

   HD I/O starts.
   HD I/O is just about finished when some other device interrupts the
   CPU to do DMA (a floppy drive or sound card, for example).  Data is
   still in the IDE fifo.
   The other device finishes its I/O and its status is read from its own
   register.
   The IDE status register is read to check the status of the HD transfer
   (for errors, etc.).  At this point the PC Tech chip _removes_ two
   bytes of the data currently in the FIFO awaiting transfer to/from RAM
   and replaces it with its status.  This, of course, causes data
   corruption.



As far as telling if you have the bug I only know of one sure way, & that's if 
you use OS/2. There's a test program on hobbes called EIDETEST (or something 
close) which will tell you whether errors have occurred. Just leave it running 
in the background while you do whatever you normally do on the machine. Leave it 
going for several hours just to be sure. There are OS/2 patches available to 
"fix" the problem, although like MS's they just disable prefetch buffers AFAIK. 
This results in 7-20% degradation in h/d performance on the machines I've seen, 
although I've heard ridiculous claims of >40%.

If you have a Triton, Endeavour, or Premier m/b that's more than 5-6 months old 
then you probably have a dodgy rz1000. Later revisions of the boards have h/w 
fixes in place. You have *no* legal comeback on this - it's already been tried 
in both the UK & US - and Intel or your supplier will not do anything for you 
(unless you've got a damn good supplier). Most of the Escom machines that I've 
seen (P60-P90) have the flaw - & surprise, surprise : the staff in two of the 
outlets that I've been in don't know a thing about it.

If you have *any* sort of cmd640 chipset (AFAIK) then you have the flaw. When 
you take into account the other main deficiency of the cmd640 - no concurrent 
access to the secondary channel, then it's time to bin it IMHO.
I found a 10% increase in speed when using OS/2 when I changed cards - 
concurrent access to the swap file does wonders :)

If you're running Win3.x, then don't worry about it as I've never seen a Win3.x 
machine do concurrent floppy & h/d transfers :) (in the case of the cmd640)

Win95 & WinNT are *supposed* to have patches in place to disable prefetch 
buffering, but as I don't use either I can't confirm this. You could try turning 
off prefetch buffering in the BIOS if you have that option, but there's no 
guarantee that the EIDE driver won't turn it back on - the OS/2 one did.

I appear to be running the only chipset in the FAQ that doesn't have reported 
problems (W83769F chipset) - maybe thats because I'm the only one in the known 
universe who has a m/b with this chipset and runs OS/2 :)

Sorry about the length of the reply, but this problem is *insidious*. It 
corrupted my EA_DATA file on the FAT partition over the course of 4-5 months.

If this doesn't clear it all up then try the .storage FAQ.


-- 
John Naismith