lkml.org 
[lkml]   [1998]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 3940UW Driver Locks the Machine
Gerard Roudier wrote:
>
> I donnot have a Jaz device. Based on reports and especially on Richard
> Waltham testings with such a device, it seems to me that the Jaz may in
> certain circumstances reject a TAG (after having been selected).
> The SCSI specs allow that to targets when they are in some initialisation
> process and, AFAIR, the initiator is invited (required?) to perform the
> command as if the command was not TAGGED.
> Implementing such a behaviour is pain in the ass, since several TAGGED
> commands may have been queued to drivers and/or controllers when a TAG
> is so rejected.

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
yet, and after a reset you just blew them all away anyway :) In my
experience (so far, this is a new feature in my current driver) there aren't
hardly any devices that reject tag messages after they've indicated during
an IDENTIFY that they support tags. I also don't have problems after a Bus
Device Reset or Bus Reset because of the built in delay time I use (to get
around that initialisation process time period). So, the only devices that
should reject tags are ones that indicate in the Identify info that they can
do tagged queueing, but because of a firmware bug or the status of the DQue
bit, can't. To date, I don't really know how well that code works because
this is so rare :) But, when it does happen, my code simply blows away any
commands it may have already queued up as having been reset and then resends
the current command as untagged. It assumes the device will *never* accept
a tagged command and then reject a tagged command while it still has
commands in its queue (at least not in the sense of immediate rejection
after the TAG message, it might reject based on other reasons, but we keep
track of the last message so we know what got rejected). If a device ever
rejects the TAG message when it has outstanding tagged commands, it damn
sure better do a bus free next or else be prepared for me to blow it off
with a Bus Device Reset or a full bus reset. If it goes back into the
mesg_out phase I'll have no choice but to kill the current transfer and
since an initiator technically isn't suppossed to do a bus free itself, that
leaves no alternative but the reset alternatives.

> IMO, this would require additionnal complexity in scsi drivers
> in a way that may affect performances and reliability.
>
> Note that the device may claim to be in some initialisation process
> only after a reset and while it is spinning up.
>
> Gerard.

--

Doug Ledford <dledford@dialnet.net>
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 majordomo@vger.rutgers.edu

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