Alan:
Though you did use the part of the patch that fixes the bad
PCI_DEVICE_ID_PROMISE_20246 comparison, you didn't pull in the part that
gets rid of the LBA48-disabling hack. In 2.4.20-pre5-ac3 in
init_hwif_pdc202xx() the switch statement there still does:
hwif->addressing = (hwif->channel) ? 0 : 1;
for cases PCI_DEVICE_ID_PROMISE_20265 and PCI_DEVICE_ID_PROMISE_20267.
That line of code prevents probe_lba_addressing() from setting
addressing to 1 for the primary channel which kills LBA48 addressing
there.
In 2.4.20-pre5-ac4 in init_hwif_pdc202xx(), the switch has been changed
to some if-statements but the effect is the same:
if (hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20265)
hwif->addressing = (hwif->channel) ? 0 : 1;
(and similarly for PCI_DEVICE_ID_PROMISE_20267).
Is there a good reason why LBA48 is still disabled here? The only
reason I can think of should have been fixed in -pre5-ac3.
With LBA48 disabled anyone running 160GB drives on the primary channel
are going to experience more nasty disk corruption.
-Mike
| 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:30 EST