[lkml]   [2002]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] 2.4.20-pre5-ac2: Promise Controller LBA48 DMA fixed

The trivial patch at the end of this text fixes DMA w/ LBA48 problems
on the Promise 202265 controller and probably also the 20267. This
patch is against 2.4.20-pre5-ac2 but I suspect it should apply cleanly
against anything after 2.4.19-ac4.

Problem: LBA48 DMA stopped working on Promise 20265 some time after
kernel version 2.4.19-ac4. This manifested itself on systems with
large (>137GB) hard drives; addressing above 137GB stopped working
correctly, leading to file system errors, and after a foolish
"e2fsck -y" operation, massive corruption.

Cause: The DMA was broken due to a bad if-statement in the function
init_hwif_pdc202xx() in pdc202xx.c. Because "!" binds more
tightly than "==", the check against PCI_DEVICE_ID_PROMISE_20246
was incorrect, which prevented the Promise controller LBA48 fix
logic from basically ever being turned on. Obfuscating this
further was logic in that same function which disabled LBA48
addressing mode for devices on the primary channel of the 20265 or

Solution: Apply parantheses to get evaluation ordering correct. Then
remove duct tape which disabled LBA48 addressing.

Verification: Before this fix, inspecting
/proc/ide/<host>/<device>/settings would show "0" for the
"address" attribute, owing to LBA48 being off. Just removing the
duct tape causing this however results in a broken system (driver
DMA completely fails). After also fixing the if-statement, the
system comes up successfully, the "address" attribute reads back
as "1" (confirms LBA48 addressing on), and most importantly,
fsck'ing the big drive comes back clean!

This problem did not exist in 2.4.19-ac4 because the code had since
then been rearranged / rewritten. The new code harbored the bug and
the LBA48 regression. Note: I have not tested this fix against the
Promise 20267, but I suspect (since 2.4.19-ac4 didn't hack up the
20267 either) that the same fix applies there so I deleted the duct
tape rather than just moving it.


diff -u -r linux-2.4.20-pre5-ac2/drivers/ide/pci/pdc202xx.c linux-2.4.20-pre5-ac2.fixed/drivers/ide/pci/pdc202xx.c
--- linux-2.4.20-pre5-ac2/drivers/ide/pci/pdc202xx.c 2002-09-05 00:09:43.000000000 -0500
+++ linux-2.4.20-pre5-ac2.fixed/drivers/ide/pci/pdc202xx.c 2002-09-05 00:16:43.000000000 -0500
@@ -952,7 +952,6 @@
- hwif->addressing = (hwif->channel) ? 0 : 1;
hwif->busproc = &pdc202xx_tristate;
@@ -979,7 +978,7 @@
if (!(hwif->udma_four))
hwif->udma_four = (!(hwif->INB(hwif->dma_vendor3) & 0x04));
} else {
- if (!hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20246) {
+ if (!(hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20246)) {
u16 mask = (hwif->channel) ? (1<<11) : (1<<10);
u16 CIS = 0;
hwif->ide_dma_begin = &pdc202xx_old_ide_dma_begin;

| Mike Isely | PGP fingerprint
POSITIVELY NO | | 03 54 43 4D 75 E5 CC 92
UNSOLICITED JUNK MAIL! | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| (spam-foiling address) |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.081 / U:2.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site