On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Set cmd_per_lun to reflect value supported by the Host.
In this version of the patch I have addressed comments from
Christoph Hellwig h...@infradead.org
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Hyper-V hosts can support multiple targets and multiple channels and larger
number of
LUNs per target. Update the code to reflect this. With this patch we can
correctly
enumerate all the paths in a multi-path storage environment.
In this version
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Based on the negotiated VMBUS protocol version, we adjust the size of the
storage
protocol messages. The two sizes we currently handle are pre-win8 and post-win8.
In WS2012 R2, we are negotiating higher VMBUS protocol version than the win8
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
On Azure, we have seen instances of unbounded I/O latencies. To deal with
this issue, implement handler that can reset the timeout. Note that the
host gaurantees that it will respond to each command that has been issued.
Signed-off-by: K. Y.
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Going forward it is possible that some of the commands that are not currently
implemented will be implemented on future Windows hosts. Even if they are not
implemented, we are told the host will corrrectly handle unsupported
commands (by returning
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
On some Windows hosts on FC SANs, TEST_UNIT_READY can return SRB_STATUS_ERROR.
Correctly handle this. Note that there is sufficient sense information to
support scsi error handling even in this case.
In this version of the patch I have addressed
On 07/12/2014 06:48 PM, K. Y. Srinivasan wrote:
Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the
Windows host require this. The host validates the command and SRB flags
prior to passing the command down to native driver stack.
Signed-off-by: K. Y. Srinivasan
In _scsih_probe, delay the call to scsi_add_host until the host has been
fully set up.
Otherwise, the default .can_queue value of 1 causes scsi-mq to set the block
layer request queue size to its minimum size, resulting in awful performance.
In _scsih_probe error handling, call
In _scsih_probe, delay the call to scsi_add_host until the host has been
fully set up.
Otherwise, the default .can_queue value of 1 causes scsi-mq to set the block
layer request queue size to its minimum size, resulting in awful performance.
In _scsih_probe error handling, call
port_detect is only called from the module_init routine and thus implicitly
serialized, so remove the driver lock which was held over potentially
sleeping function calls.
Signed-off-by: Christoph Hellwig h...@lst.de
Reported-by: Arthur Marsh arthur.ma...@internode.on.net
Tested-by: Arthur Marsh
On Mon, Jul 14, 2014 at 08:15:17AM +0200, Hannes Reinecke wrote:
Limiting max_lun to 255 will make the driver to _not_ respond to LUNs higher
than that; ie Well-known LUN won't work here.
Also the SCSI stack will be using REPORT LUNS anyway since you're
advertising SPC-2 compliance. So your
On Mon, Jul 14, 2014 at 10:29:04AM +0200, Paul Bolle wrote:
0) Commit 73685a458f2e (tgt: removal) landed in next-20140714. It
states that the CONFIG_SCSI_TGT, CONFIG_SCSI_SRP_TGT_ATTRS and
CONFIG_SCSI_FC_TGT_ATTRS kbuild variable[s] [...] are no longer needed.
It removed the Kconfig entry
0) Commit 73685a458f2e (tgt: removal) landed in next-20140714. It
states that the CONFIG_SCSI_TGT, CONFIG_SCSI_SRP_TGT_ATTRS and
CONFIG_SCSI_FC_TGT_ATTRS kbuild variable[s] [...] are no longer needed.
It removed the Kconfig entry for SCSI_SRP_TGT_ATTRS, but it left the
entries for SCSI_TGT
Back when the mpt3sas driver was first posted I suggested that it should
be merged into mpt2sas, but my proposal didn't get much traction.
Illumos has now produced a shared driver and shown that the difference
are basically limited to a different S/G list format [1], and a quick
experiment on the
On 07/14/2014 10:30 AM, Christoph Hellwig wrote:
On Mon, Jul 14, 2014 at 08:15:17AM +0200, Hannes Reinecke wrote:
Limiting max_lun to 255 will make the driver to _not_ respond to LUNs higher
than that; ie Well-known LUN won't work here.
Also the SCSI stack will be using REPORT LUNS anyway since
On Mon, Jul 14, 2014 at 10:57:53AM +0200, Hannes Reinecke wrote:
Okay, that's fine by me.
Should I take this as a reviewed-by tag?
--
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
On 07/14/2014 11:00 AM, Christoph Hellwig wrote:
On Mon, Jul 14, 2014 at 10:57:53AM +0200, Hannes Reinecke wrote:
Okay, that's fine by me.
Should I take this as a reviewed-by tag?
Yes, please do.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de
On 7/8/2014 5:48 PM, Christoph Hellwig wrote:
SNIP
I've pushed out a new scsi-mq.3 branch, which has been rebased on the
latest core-for-3.17 tree + the RFC: clean up command setup series
from June 29th. Robert Elliot found a problem with not fully zeroed
out UNMAP CDBs, which is fixed by the
On 07/14/2014 10:35 AM, Christoph Hellwig wrote:
Back when the mpt3sas driver was first posted I suggested that it should
be merged into mpt2sas, but my proposal didn't get much traction.
Illumos has now produced a shared driver and shown that the difference
are basically limited to a different
On 14-07-13 06:55 PM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Douglas Gilbert
Sent: Monday, 07 July, 2014 8:31 AM
To: SCSI development list
Subject: [PATCH v2] scsi_debug:
On Mon, 2014-07-14 at 11:22 +0200, Hannes Reinecke wrote:
On 07/14/2014 10:35 AM, Christoph Hellwig wrote:
Back when the mpt3sas driver was first posted I suggested that it should
be merged into mpt2sas, but my proposal didn't get much traction.
Illumos has now produced a shared driver
On 07/14/2014 04:17 PM, James Bottomley wrote:
On Mon, 2014-07-14 at 11:22 +0200, Hannes Reinecke wrote:
On 07/14/2014 10:35 AM, Christoph Hellwig wrote:
Back when the mpt3sas driver was first posted I suggested that it should
be merged into mpt2sas, but my proposal didn't get much traction.
On Mon, 2014-07-14 at 16:39 +0200, Hannes Reinecke wrote:
On 07/14/2014 04:17 PM, James Bottomley wrote:
On Mon, 2014-07-14 at 11:22 +0200, Hannes Reinecke wrote:
On 07/14/2014 10:35 AM, Christoph Hellwig wrote:
Back when the mpt3sas driver was first posted I suggested that it should
be
On Tue, Jul 1, 2014 at 9:11 PM, Andy Grover agro...@redhat.com wrote:
Shaohua Li wrote an initial implementation of this, late last year[1].
Starting from that, I started working on some alternate implementation
choices, and ended up with something rather different.
Please take a look and let
On 07/14/2014 04:57 PM, James Bottomley wrote:
On Mon, 2014-07-14 at 16:39 +0200, Hannes Reinecke wrote:
On 07/14/2014 04:17 PM, James Bottomley wrote:
[ .. ]
This isn't really a democracy; it's about who maintains the drivers and
right now it's LSI (or whatever their new name is).
One of
On 07/14/2014 05:10 PM, Hannes Reinecke wrote:
On 07/14/2014 04:57 PM, James Bottomley wrote:
On Mon, 2014-07-14 at 16:39 +0200, Hannes Reinecke wrote:
On 07/14/2014 04:17 PM, James Bottomley wrote:
[ .. ]
This isn't really a democracy; it's about who maintains the drivers and
right now it's
Hi Robert,
On Sun, Jul 13, 2014 at 05:15:15PM +, Elliott, Robert (Server Storage)
wrote:
I will see if that solves the problem with the scsi-mq-3 tree, or
at least some of the bisect trees leading up to it.
scsi-mq-3 is still going after 45 minutes. I'll leave it running
On Sat, 12 Jul 2014 03:13:07 +
Elliott, Robert (Server Storage) elli...@hp.com wrote:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Joe Lawrence
...
In your crash stack trace, the scsi error handler has
James == James Bottomley james.bottom...@hansenpartnership.com writes:
James I support the concept, since I think everyone told LSI at the
James time that splitting the drivers would become a maintenance
James nightmare.
And it is. I'd like to see these drivers merged as well.
James One of the
29 matches
Mail list logo
