[lkml]   [2006]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH] 0/3: Fix EH problems in libsas and implement more error handling
    Hi all,

    The following three patches are early drafts of a series of patches to
    fix error handling in libsas so that the scsi_eh_* functions are called
    so that we can attempt to retry failed commands later. There is also a
    patch to aic94xx to make escb errors are detected correctly,
    REQ_TASK_ABORT is handled, and the beginnings of a handler for

    However, there are a number of issues with these patches that I wish to
    bring to the attention of this mailing list for further input:

    First, the aic94xx sequencer can send back an ESCB with an error code of
    "REQ_TASK_ABORT", which means that the kernel has to send an ABORT TASK
    TMF to sequencer to unjam things. Until this happens, the sequencer
    neither services commands nor sends back completions. If we want to
    wait for the error handler to send the ABORT TASK, we end up waiting for
    _all_ pending commands to time out so that the EH can wake up. This
    effectively stalls the system for 30 seconds every time we see

    On the assumption that we'd like to get on with things sooner than
    later, the current iteration of these patches aborts the task as soon as
    possible so that the other pending commands will flush out on their own.
    However, this also necessitates the addition of a new sas_task flag
    (SAS_TASK_INITIATOR_ABORTED) to indicate "Task aborted, but still
    waiting for the EH to call task_done." From what I can tell,
    SAS_TASK_STATE_ABORTED means that the task will be lldd_abort_task'd by
    the EH at some point, but does not indicate if that has been done yet,
    and SAS_TASK_STATE_DONE is set after everything is done.

    The second issue is the manual decrementing of shost->host_failed in the
    error handler. So long as we use the scsi_eh_* commands this value is
    decremented automatically--however, it appears that sas_scsi_clear_* is
    pulling scsi_cmnds off the error queue and ... dropping them so that
    they never go through the error handler. Is this a desirable behavior,
    or am I reading the code incorrectly? Or...?

    The third pertains to REQ_DEVICE_RESET: I've not yet figured out how to
    reset a device port as has been hinted that I must do. I don't know if
    a phy reset is sufficient or if I'm barking up the wrong tree.

    In any case, these patches have been tested on a x206m, x260 and a x366.
    They seemed pretty stable, though YMMV. The patches should apply
    against linux-2.6.19-rc3 + scsi-misc + scsi-rc-fixes + aic94xx git trees
    in the order that they are posted. They may also eat your disks.

    Questions/comments? This is still very much a work in progress and at
    this stage I'm merely seeking constructive feedback to mould this code
    into better shape.

    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: 2006-10-31 00:21    [W:0.022 / U:15.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site