PATCH: [2.4.21-pre3] Fix for Promise PIO Lockup

Newer kernels will lock up when a drive command (SMART, hdparm -I, etc.) is issued to a drive connected to a Promise 20265 or 20267 controller while the controller is in DMA mode. The problem appears to be that tune_chipset incorrectly clears the high PIO bit thinking that it is a "PIO force on" bit. The documentation I have access to does not seem to mention a PIO force bit. Not changing that bit seems to fix the problem with drive commands on a promise controller.

The documentation I have also says the values for the TB and TC variables should be the same for all UDMA modes and they are not. However the driver seems to work anyway, so I left them the way they are.

To reproduce this problem make sure your drive is set to a DMA mode, eg hdparm -X 67 and then issue a drive command, e.g. hdparm -I.

This problem may also be present in the drivers for other Promise chips.

This change has only been minimally tested.

------ snip here -------

diff -durbB linux-2.4.20-p2/drivers/ide/pci/pdc202xx_old.c linux-2.4.20-p3/drivers/ide/pci/pdc202xx_old.c
@@ -268,7 +268,9 @@
        if ((BP & 0xF0) && (CP & 0x0F)) {
            /* clear DMA modes of upper 842 bits of B Register */
            /* clear PIO forced mode upper 1 bit of B Register */
-            pci_write_config_byte(dev, (drive_pci)|0x01, BP &~0xF0);
+                        /* The documentation I have access to says there
+                           is no PIO forced mode bit. -- RAB 01/10/03 */
+            pci_write_config_byte(dev, (drive_pci)|0x01, BP &~0xE0);
            pci_read_config_byte(dev, (drive_pci)|0x01, &BP);
 
            /* clear DMA modes of lower 8421 bits of C Register */

I have tried to reproduce this problem according to your description above, but neither my 20269 (with "new" driver) nor my 20267 (with "old" driver) hangs. I checked with kernels 2.5.58 and 2.4.21-pre3.

Maybe something else is needed for the hang to occur?

/Mikael