Messages in this thread | | | Date | Sun, 15 Feb 1998 15:04:01 -0600 | From | Doug Ledford <> | Subject | Re: 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 <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
| |