Commit:     2074a106f52b6371885afbd714e929d60d0e3f64
Parent:     6c6a2a8d201b4f8fd54167802da5ddbe08abd744
Author:     Alan Cox <[EMAIL PROTECTED]>
AuthorDate: Thu May 24 02:42:38 2007 +0200
Committer:  Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
CommitDate: Thu May 24 02:42:38 2007 +0200

    ide/pci/serverworks.c: Fix corruption/timeouts with MegaIDE
    It turns out from customer reports to Red Hat and some PCI dumps that the
    MegaIDE in RAID mode doesn't provide the drive tuning data that the
    serverworks driver expects but sometimes does provide something that
    fools the code.
    For the RAID class case skip the oem setup and don't trust the BIOS data.
    We then tune from scratch and this sorts it out. (This has been confirmed
    on an afflicted IBM blade)
    [libata serverworks.c never trusts the BIOS in the first place so is
    accidentally immune]
    Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
    Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
 drivers/ide/pci/serverworks.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
index 6234f80..1f80c6d 100644
--- a/drivers/ide/pci/serverworks.c
+++ b/drivers/ide/pci/serverworks.c
@@ -158,6 +158,12 @@ static int svwks_tune_chipset (ide_drive_t *drive, u8 
        pci_read_config_word(dev, 0x4A, &csb5_pio);
        pci_read_config_byte(dev, 0x54, &ultra_enable);
+       /* If we are in RAID mode (eg AMI MegaIDE) then we can't it
+          turns out trust the firmware configuration */
+       if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
+               goto oem_setup_failed;
        /* Per Specified Design by OEM, and ASIC Architect */
        if ((dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE) ||
            (dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2)) {
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to