I would like to make another point about why I am making this change
in case it is not clear. The queue full events are form
TRANS_TX_CREDIT_TIMEOUT_ERR and TRANS_TX_CLOSE_NORMAL_ERR errors in
the slot: I want the slot retried when this occurs, so I set status
as SAS_QUEUE_FULL just so we will
I would like to make another point about why I am making this change
in case it is not clear. The queue full events are form
TRANS_TX_CREDIT_TIMEOUT_ERR and TRANS_TX_CLOSE_NORMAL_ERR errors in
the slot: I want the slot retried when this occurs, so I set status
as SAS_QUEUE_FULL just so we will
On 02/19/2016 11:46 AM, John Garry wrote:
> On 18/02/2016 10:57, John Garry wrote:
>> On 18/02/2016 10:30, Hannes Reinecke wrote:
>>> On 02/18/2016 11:12 AM, John Garry wrote:
On 18/02/2016 07:40, Hannes Reinecke wrote:
>>> [ .. ]
> Well, the classical thing would be to associate each
On 02/19/2016 11:46 AM, John Garry wrote:
> On 18/02/2016 10:57, John Garry wrote:
>> On 18/02/2016 10:30, Hannes Reinecke wrote:
>>> On 02/18/2016 11:12 AM, John Garry wrote:
On 18/02/2016 07:40, Hannes Reinecke wrote:
>>> [ .. ]
> Well, the classical thing would be to associate each
On 18/02/2016 10:57, John Garry wrote:
On 18/02/2016 10:30, Hannes Reinecke wrote:
On 02/18/2016 11:12 AM, John Garry wrote:
On 18/02/2016 07:40, Hannes Reinecke wrote:
[ .. ]
Well, the classical thing would be to associate each request tag
with a SAS task; or, in your case, associate each
On 18/02/2016 10:57, John Garry wrote:
On 18/02/2016 10:30, Hannes Reinecke wrote:
On 02/18/2016 11:12 AM, John Garry wrote:
On 18/02/2016 07:40, Hannes Reinecke wrote:
[ .. ]
Well, the classical thing would be to associate each request tag
with a SAS task; or, in your case, associate each
On 18/02/2016 10:30, Hannes Reinecke wrote:
On 02/18/2016 11:12 AM, John Garry wrote:
On 18/02/2016 07:40, Hannes Reinecke wrote:
[ .. ]
Well, the classical thing would be to associate each request tag
with a SAS task; or, in your case, associate each slot index with a
request tag.
You
On 18/02/2016 10:30, Hannes Reinecke wrote:
On 02/18/2016 11:12 AM, John Garry wrote:
On 18/02/2016 07:40, Hannes Reinecke wrote:
[ .. ]
Well, the classical thing would be to associate each request tag
with a SAS task; or, in your case, associate each slot index with a
request tag.
You
On 02/18/2016 11:12 AM, John Garry wrote:
> On 18/02/2016 07:40, Hannes Reinecke wrote:
[ .. ]
>> Well, the classical thing would be to associate each request tag
>> with a SAS task; or, in your case, associate each slot index with a
>> request tag.
>> You probably would need to reserve some slots
On 02/18/2016 11:12 AM, John Garry wrote:
> On 18/02/2016 07:40, Hannes Reinecke wrote:
[ .. ]
>> Well, the classical thing would be to associate each request tag
>> with a SAS task; or, in your case, associate each slot index with a
>> request tag.
>> You probably would need to reserve some slots
On 18/02/2016 07:40, Hannes Reinecke wrote:
On 02/16/2016 05:56 PM, John Garry wrote:
On 16/02/2016 15:33, Hannes Reinecke wrote:
On 02/16/2016 01:22 PM, John Garry wrote:
In high-datarate aging tests, it is found that
the SCSI framework can periodically
issue lu resets to the device. This is
On 18/02/2016 07:40, Hannes Reinecke wrote:
On 02/16/2016 05:56 PM, John Garry wrote:
On 16/02/2016 15:33, Hannes Reinecke wrote:
On 02/16/2016 01:22 PM, John Garry wrote:
In high-datarate aging tests, it is found that
the SCSI framework can periodically
issue lu resets to the device. This is
On 02/16/2016 05:56 PM, John Garry wrote:
> On 16/02/2016 15:33, Hannes Reinecke wrote:
>> On 02/16/2016 01:22 PM, John Garry wrote:
>>> In high-datarate aging tests, it is found that
>>> the SCSI framework can periodically
>>> issue lu resets to the device. This is because scsi
>>> commands begin
On 02/16/2016 05:56 PM, John Garry wrote:
> On 16/02/2016 15:33, Hannes Reinecke wrote:
>> On 02/16/2016 01:22 PM, John Garry wrote:
>>> In high-datarate aging tests, it is found that
>>> the SCSI framework can periodically
>>> issue lu resets to the device. This is because scsi
>>> commands begin
On 16/02/2016 15:33, Hannes Reinecke wrote:
On 02/16/2016 01:22 PM, John Garry wrote:
In high-datarate aging tests, it is found that
the SCSI framework can periodically
issue lu resets to the device. This is because scsi
commands begin to timeout. It is found that TASK SET
FULL may be returned
On 16/02/2016 15:33, Hannes Reinecke wrote:
On 02/16/2016 01:22 PM, John Garry wrote:
In high-datarate aging tests, it is found that
the SCSI framework can periodically
issue lu resets to the device. This is because scsi
commands begin to timeout. It is found that TASK SET
FULL may be returned
On 02/16/2016 01:22 PM, John Garry wrote:
> In high-datarate aging tests, it is found that
> the SCSI framework can periodically
> issue lu resets to the device. This is because scsi
> commands begin to timeout. It is found that TASK SET
> FULL may be returned many times for the same command,
>
On 02/16/2016 01:22 PM, John Garry wrote:
> In high-datarate aging tests, it is found that
> the SCSI framework can periodically
> issue lu resets to the device. This is because scsi
> commands begin to timeout. It is found that TASK SET
> FULL may be returned many times for the same command,
>
In high-datarate aging tests, it is found that
the SCSI framework can periodically
issue lu resets to the device. This is because scsi
commands begin to timeout. It is found that TASK SET
FULL may be returned many times for the same command,
causing the timeouts.
To overcome this, the queue depth
In high-datarate aging tests, it is found that
the SCSI framework can periodically
issue lu resets to the device. This is because scsi
commands begin to timeout. It is found that TASK SET
FULL may be returned many times for the same command,
causing the timeouts.
To overcome this, the queue depth
20 matches
Mail list logo
