Control Mode page (0xA) QERR bit setting

Control Mode page (0xA) QERR bit setting

[Jeremy Higdon]

It looks as though the midlayer assumes that QERR is 0.  Is that correct?

If QERR is 0, then a check condition for one command will not affect other
commands, whereas if QERR is 1, then when one command gets a check condition,
all others for that ITL are silently aborted.

Since I wasn't able to find any code (other than in the ipr driver) that
completed all outstanding commands to a Lun when a check condition is
received, I figure that we depend on QERR=0.

thanks

jeremy

Re: Control Mode page (0xA) QERR bit setting

[James Bottomley]

On Mon, 2004-08-30 at 22:45, Jeremy Higdon wrote:
> It looks as though the midlayer assumes that QERR is 0.  Is that correct?

Actually, no, the mid-layer is agnostic to the setting of QERR.  On
error, it simply quiesces the host and waits for all the commands to
timeout or complete.

> If QERR is 0, then a check condition for one command will not affect other
> commands, whereas if QERR is 1, then when one command gets a check condition,
> all others for that ITL are silently aborted.

Yes, so we see them time out in the error handler.

> Since I wasn't able to find any code (other than in the ipr driver) that
> completed all outstanding commands to a Lun when a check condition is
> received, I figure that we depend on QERR=0.

No, we work for either.  QERR != 0 is very rare in mode pages, primarily
because it's almost impossible to predict what tags actually got dropped
on the floor because you don't know the status of the head scheduler
(only tasks accepted and scheduled behind the failing tag actually get
dropped; executing tasks ahead of it are allowed to complete as long as
the failing condition doesn't impact them).

James

Re: Control Mode page (0xA) QERR bit setting

[Jeremy Higdon]

On Mon, Aug 30, 2004 at 11:33:46PM -0400, James Bottomley wrote:
> On Mon, 2004-08-30 at 22:45, Jeremy Higdon wrote:
> > It looks as though the midlayer assumes that QERR is 0.  Is that correct?
> 
> Actually, no, the mid-layer is agnostic to the setting of QERR.  On
> error, it simply quiesces the host and waits for all the commands to
> timeout or complete.
>
> > If QERR is 0, then a check condition for one command will not affect other
> > commands, whereas if QERR is 1, then when one command gets a check condition,
> > all others for that ITL are silently aborted.
> 
> Yes, so we see them time out in the error handler.

Well okay.  They are handled, just not too quickly :-)
Not optimal behavior if lots of devices have QERR set to 1.  Fortunately,
they are rare, as you mention below.  Though some OSes actually set
that bit when they can.

> > Since I wasn't able to find any code (other than in the ipr driver) that
> > completed all outstanding commands to a Lun when a check condition is
> > received, I figure that we depend on QERR=0.
> 
> No, we work for either.  QERR != 0 is very rare in mode pages, primarily
> because it's almost impossible to predict what tags actually got dropped
> on the floor because you don't know the status of the head scheduler
> (only tasks accepted and scheduled behind the failing tag actually get
> dropped; executing tasks ahead of it are allowed to complete as long as
> the failing condition doesn't impact them).

Right.  It kind of has to be handled by the host driver or perhaps the
adapter itself, since in many cases only the adapter knows what the
device has actually accepted.  Even then, some complex devices may
theoretically have race conditions in their SCSI engine (though one would
hope not).

> James

thanks,

jeremy

Re: Control Mode page (0xA) QERR bit setting

[Brian King]

The ipr driver actually depends on QERR=1 and adapter firmware to do the 
right thing. TCQing doesn't get setup by the ipr driver until userspace 
enables it, and the userspace tool to enable it takes care of setting up 
QERR=1 before enabling it. When I get a check condition I send down a 
cancel all requests to the device, which is similar to an abort task 
set. The end result is that all commands that were silently aborted get 
returned to me with aborted status. Meanwhile, the device is in a state 
where it will always return a "not ready - synchronization required" 
response (pseudo ACA state), which I translate to DID_IMM_RETRY. I do 
the request sense and then clear this sync required state on the next 
command issued.

-Brian

Jeremy Higdon wrote:
> It looks as though the midlayer assumes that QERR is 0.  Is that correct?
> 
> If QERR is 0, then a check condition for one command will not affect other
> commands, whereas if QERR is 1, then when one command gets a check condition,
> all others for that ITL are silently aborted.
> 
> Since I wasn't able to find any code (other than in the ipr driver) that
> completed all outstanding commands to a Lun when a check condition is
> received, I figure that we depend on QERR=0.
> 
> thanks
> 
> jeremy
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center