Quantcast

Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Tim Gardner-2
https://bugs.launchpad.net/bugs/1663687

[PATCH 1/6] scsi: storvsc: Enable tracking of queue depth
[PATCH 2/6] scsi: storvsc: Remove the restriction on max segment size
[PATCH 3/6] scsi: storvsc: Enable multi-queue support
[PATCH 4/6] scsi: storvsc: use tagged SRB requests if supported by
[PATCH 5/6] scsi: storvsc: properly handle SRB_ERROR when sense
[PATCH 6/6] scsi: storvsc: properly set residual data length on

rtg


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 1/6] scsi: storvsc: Enable tracking of queue depth

Tim Gardner-2
From: "K. Y. Srinivasan" <[hidden email]>

BugLink: http://bugs.launchpad.net/bugs/1663687

Enable tracking of queue depth.

Signed-off-by: K. Y. Srinivasan <[hidden email]>
Reviewed-by: Long Li <[hidden email]>
Signed-off-by: Martin K. Petersen <[hidden email]>
(cherry picked from linux-next commit f64dad2628bdf62eac7ac145a6e31430376b65e4)
Signed-off-by: Tim Gardner <[hidden email]>
---
 drivers/scsi/storvsc_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 141d9fe..c517321 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1550,6 +1550,7 @@ static struct scsi_host_template scsi_driver = {
  /* Make sure we dont get a sg segment crosses a page boundary */
  .dma_boundary = PAGE_SIZE-1,
  .no_write_same = 1,
+ .track_queue_depth = 1,
 };
 
 enum {
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 2/6] scsi: storvsc: Remove the restriction on max segment size

Tim Gardner-2
In reply to this post by Tim Gardner-2
From: "K. Y. Srinivasan" <[hidden email]>

BugLink: http://bugs.launchpad.net/bugs/1663687

Remove the artificially imposed restriction on max segment size.

Signed-off-by: K. Y. Srinivasan <[hidden email]>
Reviewed-by: Long Li <[hidden email]>
Signed-off-by: Martin K. Petersen <[hidden email]>
(cherry picked from linux-next commit 977965283526dd2e887331365da19b05c909a966)
Signed-off-by: Tim Gardner <[hidden email]>
---
 drivers/scsi/storvsc_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index c517321..1f3c5d9 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1267,8 +1267,6 @@ static int storvsc_do_io(struct hv_device *device,
 static int storvsc_device_configure(struct scsi_device *sdevice)
 {
 
- blk_queue_max_segment_size(sdevice->request_queue, PAGE_SIZE);
-
  blk_queue_bounce_limit(sdevice->request_queue, BLK_BOUNCE_ANY);
 
  blk_queue_rq_timeout(sdevice->request_queue, (storvsc_timeout * HZ));
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 3/6] scsi: storvsc: Enable multi-queue support

Tim Gardner-2
In reply to this post by Tim Gardner-2
From: "K. Y. Srinivasan" <[hidden email]>

BugLink: http://bugs.launchpad.net/bugs/1663687

Enable multi-q support. We will allocate the outgoing channel using
the following policy:

        1. We will make every effort to pick a channel that is in the
           same NUMA node that is initiating the I/O
        2. The mapping between the guest CPU and the outgoing channel
           is persistent.

Signed-off-by: K. Y. Srinivasan <[hidden email]>
Reviewed-by: Long Li <[hidden email]>
Signed-off-by: Martin K. Petersen <[hidden email]>
(back ported from linux-next commit d86adf482b843b3a58a9ec3b7c1ccdbf7c705db1)
Signed-off-by: Tim Gardner <[hidden email]>

Conflicts:
        drivers/scsi/storvsc_drv.c
---
 drivers/scsi/storvsc_drv.c | 113 +++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 110 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 1f3c5d9..c54b726 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -458,6 +458,15 @@ struct storvsc_device {
  * Max I/O, the device can support.
  */
  u32   max_transfer_bytes;
+ /*
+ * Number of sub-channels we will open.
+ */
+ u16 num_sc;
+ struct vmbus_channel **stor_chns;
+ /*
+ * Mask of CPUs bound to subchannels.
+ */
+ struct cpumask alloced_cpus;
  /* Used for vsc/vsp channel reset process */
  struct storvsc_cmd_request init_request;
  struct storvsc_cmd_request reset_request;
@@ -635,6 +644,11 @@ static void handle_sc_creation(struct vmbus_channel *new_sc)
    (void *)&props,
    sizeof(struct vmstorage_channel_properties),
    storvsc_on_channel_callback, new_sc);
+
+ if (new_sc->state == CHANNEL_OPENED_STATE) {
+ stor_device->stor_chns[new_sc->target_cpu] = new_sc;
+ cpumask_set_cpu(new_sc->target_cpu, &stor_device->alloced_cpus);
+ }
 }
 
 static void  handle_multichannel_storage(struct hv_device *device, int max_chns)
@@ -651,6 +665,7 @@ static void  handle_multichannel_storage(struct hv_device *device, int max_chns)
  if (!stor_device)
  return;
 
+ stor_device->num_sc = num_sc;
  request = &stor_device->init_request;
  vstor_packet = &request->vstor_packet;
 
@@ -838,6 +853,25 @@ static int storvsc_channel_init(struct hv_device *device, bool is_fc)
  * support multi-channel.
  */
  max_chns = vstor_packet->storage_channel_properties.max_channel_cnt;
+
+ /*
+ * Allocate state to manage the sub-channels.
+ * We allocate an array based on the numbers of possible CPUs
+ * (Hyper-V does not support cpu online/offline).
+ * This Array will be sparseley populated with unique
+ * channels - primary + sub-channels.
+ * We will however populate all the slots to evenly distribute
+ * the load.
+ */
+ stor_device->stor_chns = kzalloc(sizeof(void *) * num_possible_cpus(),
+ GFP_KERNEL);
+ if (stor_device->stor_chns == NULL)
+ return -ENOMEM;
+
+ stor_device->stor_chns[device->channel->target_cpu] = device->channel;
+ cpumask_set_cpu(device->channel->target_cpu,
+ &stor_device->alloced_cpus);
+
  if (vmstor_proto_version >= VMSTOR_PROTO_VERSION_WIN8) {
  if (vstor_packet->storage_channel_properties.flags &
     STORAGE_CHANNEL_SUPPORTS_MULTI_CHANNEL)
@@ -1198,17 +1232,64 @@ static int storvsc_dev_remove(struct hv_device *device)
  /* Close the channel */
  vmbus_close(device->channel);
 
+ kfree(stor_device->stor_chns);
  kfree(stor_device);
  return 0;
 }
 
+static struct vmbus_channel *get_og_chn(struct storvsc_device *stor_device,
+ u16 q_num)
+{
+ u16 slot = 0;
+ u16 hash_qnum;
+ struct cpumask alloced_mask;
+ int num_channels, tgt_cpu;
+
+ if (stor_device->num_sc == 0)
+ return stor_device->device->channel;
+
+ /*
+ * Our channel array is sparsley populated and we
+ * initiated I/O on a processor/hw-q that does not
+ * currently have a designated channel. Fix this.
+ * The strategy is simple:
+ * I. Ensure NUMA locality
+ * II. Distribute evenly (best effort)
+ * III. Mapping is persistent.
+ */
+
+ cpumask_and(&alloced_mask, &stor_device->alloced_cpus,
+    cpumask_of_node(cpu_to_node(q_num)));
+
+ num_channels = cpumask_weight(&alloced_mask);
+ if (num_channels == 0)
+ return stor_device->device->channel;
+
+ hash_qnum = q_num;
+ while (hash_qnum >= num_channels)
+ hash_qnum -= num_channels;
+
+ for_each_cpu(tgt_cpu, &alloced_mask) {
+ if (slot == hash_qnum)
+ break;
+ slot++;
+ }
+
+ stor_device->stor_chns[q_num] = stor_device->stor_chns[tgt_cpu];
+
+ return stor_device->stor_chns[q_num];
+}
+
+
 static int storvsc_do_io(struct hv_device *device,
- struct storvsc_cmd_request *request)
+ struct storvsc_cmd_request *request, u16 q_num)
 {
  struct storvsc_device *stor_device;
  struct vstor_packet *vstor_packet;
  struct vmbus_channel *outgoing_channel;
  int ret = 0;
+ struct cpumask alloced_mask;
+ int tgt_cpu;
 
  vstor_packet = &request->vstor_packet;
  stor_device = get_out_stor_device(device);
@@ -1222,7 +1303,26 @@ static int storvsc_do_io(struct hv_device *device,
  * Select an an appropriate channel to send the request out.
  */
 
- outgoing_channel = vmbus_get_outgoing_channel(device->channel);
+ if (stor_device->stor_chns[q_num] != NULL) {
+ outgoing_channel = stor_device->stor_chns[q_num];
+ if (outgoing_channel->target_cpu == smp_processor_id()) {
+ /*
+ * Ideally, we want to pick a different channel if
+ * available on the same NUMA node.
+ */
+ cpumask_and(&alloced_mask, &stor_device->alloced_cpus,
+    cpumask_of_node(cpu_to_node(q_num)));
+ for_each_cpu(tgt_cpu, &alloced_mask) {
+ if (tgt_cpu != outgoing_channel->target_cpu) {
+ outgoing_channel =
+ stor_device->stor_chns[tgt_cpu];
+ break;
+ }
+ }
+ }
+ } else {
+ outgoing_channel = get_og_chn(stor_device, q_num);
+ }
 
 
  vstor_packet->flags |= REQUEST_COMPLETION_FLAG;
@@ -1522,7 +1622,8 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
  cmd_request->payload_sz = payload_sz;
 
  /* Invokes the vsc to start an IO */
- ret = storvsc_do_io(dev, cmd_request);
+ ret = storvsc_do_io(dev, cmd_request, get_cpu());
+ put_cpu();
 
  if (ret == -EAGAIN) {
  /* no more space */
@@ -1684,6 +1785,11 @@ static int storvsc_probe(struct hv_device *device,
  host->sg_tablesize, MAX_MULTIPAGE_BUFFER_COUNT);
  host->sg_tablesize = MAX_MULTIPAGE_BUFFER_COUNT;
 #endif
+ /*
+ * Set the number of HW queues we are supporting.
+ */
+ if (stor_device->num_sc != 0)
+ host->nr_hw_queues = stor_device->num_sc + 1;
 
  /* Register the HBA and start the scsi bus scan */
  ret = scsi_add_host(host, &device->device);
@@ -1720,6 +1826,7 @@ err_out2:
  goto err_out0;
 
 err_out1:
+ kfree(stor_device->stor_chns);
  kfree(stor_device);
 
 err_out0:
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 4/6] scsi: storvsc: use tagged SRB requests if supported by the device

Tim Gardner-2
In reply to this post by Tim Gardner-2
From: Long Li <[hidden email]>

BugLink: http://bugs.launchpad.net/bugs/1663687

Properly set SRB flags when hosting device supports tagged queuing.
This patch improves the performance on Fiber Channel disks.

Signed-off-by: Long Li <[hidden email]>
Reviewed-by: K. Y. Srinivasan <[hidden email]>
Signed-off-by: K. Y. Srinivasan <[hidden email]>
Cc: <[hidden email]>
Signed-off-by: Martin K. Petersen <[hidden email]>
(cherry picked from linux-next commit 3cd6d3d9b1abab8dcdf0800224ce26daac24eea2)
Signed-off-by: Tim Gardner <[hidden email]>
---
 drivers/scsi/storvsc_drv.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index c54b726..094573d 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -136,6 +136,8 @@ struct hv_fc_wwn_packet {
 #define SRB_FLAGS_PORT_DRIVER_RESERVED 0x0F000000
 #define SRB_FLAGS_CLASS_DRIVER_RESERVED 0xF0000000
 
+#define SP_UNTAGGED ((unsigned char) ~0)
+#define SRB_SIMPLE_TAG_REQUEST 0x20
 
 /*
  * Platform neutral description of a scsi request -
@@ -1549,6 +1551,13 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
  vm_srb->win8_extension.srb_flags |=
  SRB_FLAGS_DISABLE_SYNCH_TRANSFER;
 
+ if (scmnd->device->tagged_supported) {
+ vm_srb->win8_extension.srb_flags |=
+ (SRB_FLAGS_QUEUE_ACTION_ENABLE | SRB_FLAGS_NO_QUEUE_FREEZE);
+ vm_srb->win8_extension.queue_tag = SP_UNTAGGED;
+ vm_srb->win8_extension.queue_action = SRB_SIMPLE_TAG_REQUEST;
+ }
+
  /* Build the SRB */
  switch (scmnd->sc_data_direction) {
  case DMA_TO_DEVICE:
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 5/6] scsi: storvsc: properly handle SRB_ERROR when sense message is present

Tim Gardner-2
In reply to this post by Tim Gardner-2
From: Long Li <[hidden email]>

BugLink: http://bugs.launchpad.net/bugs/1663687

When sense message is present on error, we should pass along to the upper
layer to decide how to deal with the error.
This patch fixes connectivity issues with Fiber Channel devices.

Signed-off-by: Long Li <[hidden email]>
Reviewed-by: K. Y. Srinivasan <[hidden email]>
Signed-off-by: K. Y. Srinivasan <[hidden email]>
Cc: <[hidden email]>
Signed-off-by: Martin K. Petersen <[hidden email]>
(cherry picked from linux-next commit bba5dc332ec2d3a685cb4dae668c793f6a3713a3)
Signed-off-by: Tim Gardner <[hidden email]>
---
 drivers/scsi/storvsc_drv.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 094573d..f71705f 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -925,6 +925,13 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb,
  switch (SRB_STATUS(vm_srb->srb_status)) {
  case SRB_STATUS_ERROR:
  /*
+ * Let upper layer deal with error when
+ * sense message is present.
+ */
+
+ if (vm_srb->srb_status & SRB_STATUS_AUTOSENSE_VALID)
+ break;
+ /*
  * If there is an error; offline the device since all
  * error recovery strategies would have already been
  * deployed on the host side. However, if the command
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 6/6] scsi: storvsc: properly set residual data length on errors

Tim Gardner-2
In reply to this post by Tim Gardner-2
From: Long Li <[hidden email]>

BugLink: http://bugs.launchpad.net/bugs/1663687

On I/O errors, the Windows driver doesn't set data_transfer_length
on error conditions other than SRB_STATUS_DATA_OVERRUN.
In these cases we need to set data_transfer_length to 0,
indicating there is no data transferred. On SRB_STATUS_DATA_OVERRUN,
data_transfer_length is set by the Windows driver to the actual data transferred.

Reported-by: Shiva Krishna <[hidden email]>
Signed-off-by: Long Li <[hidden email]>
Reviewed-by: K. Y. Srinivasan <[hidden email]>
Signed-off-by: K. Y. Srinivasan <[hidden email]>
Cc: <[hidden email]>
Signed-off-by: Martin K. Petersen <[hidden email]>
(cherry picked from linux-next commit 40630f462824ee24bc00d692865c86c3828094e0)
Signed-off-by: Tim Gardner <[hidden email]>
---
 drivers/scsi/storvsc_drv.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index f71705f..7c71fb0 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -377,6 +377,7 @@ enum storvsc_request_type {
 #define SRB_STATUS_SUCCESS 0x01
 #define SRB_STATUS_ABORTED 0x02
 #define SRB_STATUS_ERROR 0x04
+#define SRB_STATUS_DATA_OVERRUN 0x12
 
 #define SRB_STATUS(status) \
  (status & ~(SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_QUEUE_FROZEN))
@@ -996,6 +997,7 @@ static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request,
  struct scsi_cmnd *scmnd = cmd_request->cmd;
  struct scsi_sense_hdr sense_hdr;
  struct vmscsi_request *vm_srb;
+ u32 data_transfer_length;
  struct Scsi_Host *host;
  u32 payload_sz = cmd_request->payload_sz;
  void *payload = cmd_request->payload;
@@ -1003,6 +1005,7 @@ static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request,
  host = stor_dev->host;
 
  vm_srb = &cmd_request->vstor_packet.vm_srb;
+ data_transfer_length = vm_srb->data_transfer_length;
 
  scmnd->result = vm_srb->scsi_status;
 
@@ -1016,13 +1019,20 @@ static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request,
      &sense_hdr);
  }
 
- if (vm_srb->srb_status != SRB_STATUS_SUCCESS)
+ if (vm_srb->srb_status != SRB_STATUS_SUCCESS) {
  storvsc_handle_error(vm_srb, scmnd, host, sense_hdr.asc,
  sense_hdr.ascq);
+ /*
+ * The Windows driver set data_transfer_length on
+ * SRB_STATUS_DATA_OVERRUN. On other errors, this value
+ * is untouched.  In these cases we set it to 0.
+ */
+ if (vm_srb->srb_status != SRB_STATUS_DATA_OVERRUN)
+ data_transfer_length = 0;
+ }
 
  scsi_set_resid(scmnd,
- cmd_request->payload->range.len -
- vm_srb->data_transfer_length);
+ cmd_request->payload->range.len - data_transfer_length);
 
  scmnd->scsi_done(scmnd);
 
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ACK/cmnt: Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Stefan Bader-2
In reply to this post by Tim Gardner-2
On 13.02.2017 14:05, Tim Gardner wrote:
> https://bugs.launchpad.net/bugs/1663687
>
> [PATCH 1/6] scsi: storvsc: Enable tracking of queue depth
> [PATCH 2/6] scsi: storvsc: Remove the restriction on max segment size
> [PATCH 3/6] scsi: storvsc: Enable multi-queue support
> [PATCH 4/6] scsi: storvsc: use tagged SRB requests if supported by
> [PATCH 5/6] scsi: storvsc: properly handle SRB_ERROR when sense
> [PATCH 6/6] scsi: storvsc: properly set residual data length on
>
Mainly on the premise of this being a very specific driver which should be
getting proper verification by the requesters.

-Stefan



--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ACK/cmnt: Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Joshua R. Poulson
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ACK/cmnt: Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Stefan Bader-2
On 14.02.2017 23:13, Joshua R. Poulson wrote: number and not bug fixing only in a strict sense. But since isolated to one
driver / environment can be verified and won't cause regressions generally.

-Stefan


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ACK/cmnt: Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Joshua R. Poulson
We will definitely be verifying the storvsc driver with functional and
performance tests.

On Wed, Feb 15, 2017 at 12:43 AM, Stefan Bader
<[hidden email]> wrote:

> On 14.02.2017 23:13, Joshua R. Poulson wrote:
>> I actually messed up my request, it's six commits, not just the one I
>> posted earlier:
>>
>> scsi: storvsc: properly set residual data length on errors
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/scsi/storvsc_drv.c?id=40630f462824ee24bc00d692865c86c3828094e0
>>
>> scsi: storvsc: properly handle SRB_ERROR when sense message is present
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/scsi/storvsc_drv.c?id=bba5dc332ec2d3a685cb4dae668c793f6a3713a3
>>
>> scsi: storvsc: use tagged SRB requests if supported by the device
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/scsi/storvsc_drv.c?id=3cd6d3d9b1abab8dcdf0800224ce26daac24eea2
>>
>> scsi: storvsc: Enable multi-queue support
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/scsi/storvsc_drv.c?id=d86adf482b843b3a58a9ec3b7c1ccdbf7c705db1
>>
>> scsi: storvsc: Remove the restriction on max segment size
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/scsi/storvsc_drv.c?id=977965283526dd2e887331365da19b05c909a966
>>
>> scsi: storvsc: Enable tracking of queue depth
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/scsi/storvsc_drv.c?id=f64dad2628bdf62eac7ac145a6e31430376b65e4
>>
> Which is what Tim submitted. My reservations so to speak were just about the
> number and not bug fixing only in a strict sense. But since isolated to one
> driver / environment can be verified and won't cause regressions generally.
>
> -Stefan
>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ACK: Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Brad Figg-2
In reply to this post by Tim Gardner-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

APPLIED: Xenial/Yakkety SRU - Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions)

Thadeu Lima de Souza Cascardo-3
In reply to this post by Tim Gardner-2
Applied to xenial and yakkety master-next branches.

Thanks.
Cascardo.

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Loading...