lkml.org 
[lkml]   [2010]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: mvsas errors in 2.6.36
    Date
    On December 4, 2010, jack_wang wrote:
    >
    > Here is what I get with that returning 0 rather than -1 as you requested:
    > [19107.040031] sas: command 0xffff88011c77f9c0, task 0xffff88022ae51600, timed out: BLK_EH_NOT_HANDLED
    > [19107.040062] sas: Enter sas_scsi_recover_host
    > [19107.040072] sas: trying to find task 0xffff88022ae51600
    > [19107.040079] sas: sas_scsi_find_task: aborting task 0xffff88022ae51600
    > [19107.040089] drivers/scsi/mvsas/mv_sas.c 1703:<7>mv_abort_task() mvi=ffff880224040000 task=ffff88022ae51600 slot=ffff880224066680 slot_idx=x4
    > [19107.040101] sas: sas_scsi_find_task: task 0xffff88022ae51600 is aborted
    > [19107.040107] sas: sas_eh_handle_sas_errors: task 0xffff88022ae51600 is aborted
    > [19107.040113] sas: sas_ata_task_done: SAS error 8d
    > [19107.040124] ata21: translated ATA stat/err 0x01/04 to SCSI SK/ASC/ASCQ 0xb/00/00
    > [19107.040860] ata21: status=0x01 { Error }
    > [19107.040866] ata21: error=0x04 { DriveStatusError }
    > [19107.040886] sas: --- Exit sas_scsi_recover_host
    > [19318.000085] sas: command 0xffff8801250291c0, task 0xffff88018a8e5b80, timed out: BLK_EH_NOT_HANDLED
    > [19318.000125] sas: Enter sas_scsi_recover_host
    > [19318.000135] sas: trying to find task 0xffff88018a8e5b80
    > [19318.000141] sas: sas_scsi_find_task: aborting task 0xffff88018a8e5b80
    > [19318.000152] drivers/scsi/mvsas/mv_sas.c 1703:<7>mv_abort_task() mvi=ffff880224040000 task=ffff88018a8e5b80 slot=ffff8802240666d8 slot_idx=x5
    > [19318.000163] sas: sas_scsi_find_task: task 0xffff88018a8e5b80 is aborted
    > [19318.000169] sas: sas_eh_handle_sas_errors: task 0xffff88018a8e5b80 is aborted
    > [19318.000175] sas: sas_ata_task_done: SAS error 8d
    > [19318.000185] ata24: translated ATA stat/err 0x01/04 to SCSI SK/ASC/ASCQ 0xb/00/00
    > [19318.000896] ata24: status=0x01 { Error }
    > [19318.000902] ata24: error=0x04 { DriveStatusError }
    > [19318.000922] sas: --- Exit sas_scsi_recover_host
    >
    >
    >
    > [Jack] Do all the drives discoverd? There are still commands timeout, maybe the disks need more time to response, or something
    > wrong with the driver, I'm not sure.

    All drives come up. That last set of logs is something that happens once
    or twice an hour while running. I just rebooted again to see what
    difference the change makes with a fresh startup. So far it seems that
    the controller is running properly in SATA II/3Gbps mode after the reboot.

    Just to contrast what the kernel reports in the two scenarios:
    rmmod+modprobe:
    sas: DOING DISCOVERY on port 0, pid:7283
    drivers/scsi/mvsas/mv_sas.c 1388:found dev[0:5] is gone.
    sas: sas_ata_phy_reset: Found ATA device.
    ata15.00: ATA-8: ST31000528AS, CC34, max UDMA/133
    ata15.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
    ata15.00: qc timeout (cmd 0xef)
    [snip mvsas reset]
    sas: sas_ata_phy_reset: Found ATA device.
    sas: sas_to_ata_err: Saw error 2. What to do?
    sas: sas_ata_task_done: SAS error 2
    ata15.00: failed to IDENTIFY (I/O error, err_mask=0x100)
    sas: STUB sas_ata_scr_read
    ata15: limiting SATA link speed to 1.5 Gbps
    ata15.00: limiting speed to UDMA/133:PIO3

    fresh boot:
    sas: DOING DISCOVERY on port 0, pid:312
    drivers/scsi/mvsas/mv_sas.c 1388:found dev[0:5] is gone.
    sas: sas_ata_phy_reset: Found ATA device.
    ata9.00: ATA-8: ST31000528AS, CC34, max UDMA/133
    ata9.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
    ata9.00: configured for UDMA/133

    This seems to happen on all ports. As does my original issue, though it
    (the original issue) doesn't happen to all ports at the same time, rather
    events seem to randomly happen, to one or more ports at random times.

    As you can see, the drive are 1TB Seagate SATAII drives. They are setup
    in a md-raid 5 array. Luckily these events don't bubble any errors up
    the stack causing a rebuild.

    > --
    > 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/
    >


    --
    Thomas Fjellstrom
    thomas@fjellstrom.ca


    \
     
     \ /
      Last update: 2010-12-04 13:57    [W:0.024 / U:91.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site