a distinction. (And, I'm looking forward to
the day when all of the reference counting stuff can be removed...I
think it's not far off.)
Webb
On 3/26/15 8:47 AM, Tomas Henzl wrote:
On 03/25/2015 07:33 PM, Webb Scales wrote:
Tomas,
You are correct that the previous approach
At this point, I've turned this work over to Don; I presume he'll want
to address the bitmask search. I'll leave it up to him to decide what to
do about the refcount.
Webb
On 3/26/15 11:10 AM, Tomas Henzl wrote:
On 03/26/2015 03:38 PM, Webb Scales wrote:
Ah! Tomas, you
for command allocation
On 03/17/2015 09:06 PM, Don Brace wrote:
From: Webb Scales web...@hp.com
Rework slave allocation:
- separate the tagging support setup from the hostdata setup
- make the hostdata setup act consistently when the lookup fails
- make the hostdata setup act
On 10/24/14 2:45 AM, Bart Van Assche wrote:
On 10/23/14 19:43, Webb Scales wrote:
On 10/23/14 3:16 AM, Bart Van Assche wrote:
All my tests with use_blk_mq=n were run with a WARN_ON_ONCE(req-tag
0) statement present in srp_queuecommand(). I haven't seen any kernel
warning being triggered
On 10/23/14 3:16 AM, Bart Van Assche wrote:
All my tests with use_blk_mq=n were run with a WARN_ON_ONCE(req-tag
0) statement present in srp_queuecommand(). I haven't seen any kernel
warning being triggered during the tests I ran.
Bart, what's the data type of req-tag, here? (E.g., if it
Hannes,
In megasas_change_queue_type(), is it possible for sdev-queue_depth to
be greater than 256?
Unless I'm misunderstanding the SCSI code, we can request a
queue-depth/tag-map-size which is greater than 256, but, since the
scsi_cmnd::tag field is an unsigned char, depths greater than
[Hannes, James, Christoph: sorry for the extra copies -- my mail client
didn't automatically convert to plain-text for the list, so it bounced.]
Could someone enlighten me on when and where a driver might want to or
be required to set the tagged_supported flag?
A quick grep yields a number
);
spin_unlock_irqrestore(q-queue_lock, flags);
-if (bidi_bytes)
-scsi_release_bidi_buffers(cmd);
scsi_release_buffers(cmd);
scsi_next_command(cmd);
}
Looks reasonable to me.
Reviewed-by: Webb Scales web...@hp.com
--
To unsubscribe from this list
))
blk_queue_init_tags(sdev-request_queue, depth,
sdev-host-bqt);
Reviewed-by: Webb Scales web...@hp.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
to
'!atomic_read(sdev-device_busy)' fixes the problem.
Cc: Christoph Hellwig h...@lst.de
Cc: Hannes Reinecke h...@suse.de
Cc: Webb Scales web...@hp.com
Cc: Jens Axboe ax...@kernel.dk
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/scsi/scsi_lib.c | 2 +-
1 file changed, 1 insertion(+), 1
: add support sending aborts to physical devices via the ioaccel2
path
hpsa: fix problem with abort support checking happening too early
hpsa: remove incorrect bug on in hpsa_scsi_ioaccel_raid_map
Webb Scales (3):
Initialize reference counts to zero on initial command entry
hpsa: remove incorrect bug on in hpsa_scsi_ioaccel_raid_map
Webb Scales (3):
Initialize reference counts to zero on initial command entry
allocation
hpsa: make hpsa_send_reset_as_abort_ioaccel2() use the specified
reply queue.
hpsa: use block layer tag for command allocation
:
return scsi_prep_return(q, req, ret);
}
Reviewed-by: Webb Scales web...@hp.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
13 matches
Mail list logo
