lkml.org 
[lkml]   [2002]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: aic7xxx sets CDR offline, how to reset?
    Date
    From
    patmans@us.ibm.com said:
    > If we only send an abort or reset after a quiesce I don't see why one
    > is better than the other.

    Quiesce means from the top (no more commands go from the block layer to the
    device) not from the bottom (commands can still be completed for the device).

    > Not specific to reset or abort - if a single command gets an error, we
    > wait for oustanding commands to complete before starting up the error
    > handler thread. If all the commands (error one and outstanding) have
    > barriers, those that do not error out will complete out of order from
    > the errored command.

    We don't wait. The commands may possibly be completing in parallel with
    recovery. To address your point, though, that's why the device needs to be
    reset as fast as possible: to preserve what's left of the command order. I
    accept that for a misbehaving device, this may be a race.

    > And what happens if one command gets some sort of check condition
    > (like medium error, or aborted command) that causes a retry? Will IO's
    > still be correctly ordered?

    Retries get eliminated. It should be up to the upper layers (sd or beyond) to
    say whether a retry is done. Since, as you point out, retries automatically
    violate any barrier, it is probably up to the block layer to judge what should
    be done about the problem.

    > I would like to see error handling occur without quiescing the entire
    > adapter before taking any action. Stopping all adapter IO for a
    > timeout can be a bit expensive - imagine a tape drive and multiple
    > disks on an adapter, any IO disk timeout or failure will wait for the
    > tape IO to complete before allowing any other IO, if the tape
    > operation is long or is going to timeout this could be minutes or
    > hours.

    Actually, I do think that quiescing has an important role to play. A lot of
    drive errors can be self inflicted indigestion by accepting more tags into the
    queue than it can process. Quiescing the queue lets us see if the drive can
    digest what it currently has or whether we need to apply a strong emetic.

    I'd actually like to add tag starvation recovery to the error handler's list
    of things to do. In that case, all you do on entry to the error handler is
    quiesce the upper queue and wait a while to see if the commands continue
    returning. You only begin more drastic measures if nothing comes back in the
    designated time period.

    James


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

    \
     
     \ /
      Last update: 2005-03-22 13:28    [W:5.024 / U:0.392 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site