[lkml]   [1998]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 3940UW Driver Locks the Machine
    Gerard Roudier wrote:
    > > Well, in practice, this should never be a problem. It would be illegal for
    > > a device to reject a TAG message when it has outstanding tags already. It
    > > can do so after a reset or during power on, but in both of those cases, it
    > > wouldn't have any outstanding commands. At power up, you haven't sent any
    > A driver that performs one command at a time with each device, or that
    > controls the SCSI protocol from the C code will probably deal easily
    > with a TAG having being refused (using a MESSAGE REJECT).
    > If we want to reduce command latency and allow the controller to process
    > outstandings commands as quickly as possible we must prepare several
    > commands per device and queue them to the controller 'firmware'
    > ('sequencer' for the Adaptec, 'SCRIPTS' for the ncr and 'firmware' for
    > assumed Intelligent Controllers). In such a situation when a TAG is
    > rejected, we have to reverse all that stuff or at least partially or to
    > manage this from the C code using interrupts. Remember that, once selected,
    > only the target can disconnect the BUS and change SCSI phase.

    Correct. However, in the current aic7xxx code we maintain the queue of
    commands to be sent in kernel space, and the controller DMAs those commands
    down. So, when this happens, we can easily just pause the sequencer, remove
    the commands waiting but not sent yet, update the queue tail position to
    reflect the number of commands we removed, then unpause the sequencer after
    changing a few flags so the command will get sent untagged instead of
    tagged. This assumes that the device rejecting the tagged command will
    reject all tagged commands, and hence there won't be any outstanding
    commands at the time of the rejection. We make this assumption because,
    like you, if a drive randomly rejects tag commands it's horribly broken as
    far as I'm concerned and someone else can write a firmware update :)

    > I've considered all that and even more. If someone want to take into
    > account all compliant and non compliant SCSI device behaviours regarding
    > Tagged Command Queueing, I am interested in knowing the real gain compared
    > to the needed effort.

    I don't take into account all possible behaviours. I make one assumption,
    that no device randomly rejects tags, they either accept them or reject
    them, and from that point I simply stop tagged queueing on the first reject
    I get for a tagged command (although, I do admit, if the reject comes on one
    of our ordered Q tags, then I don't blow off tagging completely, just the
    ordered tags).

    > Only high end SCSI devices really gain advantage of tagged commands and
    > they generally behave well enough with this feature. I doubt that
    > crappy Jaz devices are really faster with tagged commands and so,
    > I am not about to spare time for useless improvements.

    The one exception to this, which prompted me to put the code in, was that
    certain OEM drive resellers were shipping decent hard drives out with the
    DQue bit set. Since the drives were actually capable of tagged queueing,
    and high enough performance to benefit from it, this was reasonable.
    Especially when you consider that without the code, the driver went into an
    abort/reset loop continually resetting the drive because it was failing on
    tagged commands. The drives in question were IBM DFS series drives shipped
    by Sun and Apple.


    Doug Ledford <>
    Opinions expressed are my own, but
    they should be everybody's.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:41    [W:0.023 / U:113.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site