[lkml]   [2002]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectLBA48 still disabled on Promise 20265?


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;

That line of code prevents probe_lba_addressing() from setting
addressing to 1 for the primary channel which kills LBA48 addressing

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 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:22    [W:0.042 / U:35.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site