Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
els = 0;
> +
> + ibmvfc_init_sub_crqs(vhost);
> +
> + spin_unlock(vhost->crq.q_lock);
> + spin_unlock_irqrestore(vhost->host->host_lock, flags);
ibmvfc_init_sub_crqs can sleep, for multiple reasons, so you can't hold
a lock when you call it. There is a GFP_KERNEL allocation in it, and the
patch before this one adds an msleep in an error path.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
e);
> } while (rc == H_BUSY || H_IS_LONG_BUSY(rc));
Other places in the driver where we get a busy return code back we have an
msleep(100).
Should we be doing that here as well?
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
On 1/13/21 7:27 PM, Ming Lei wrote:
> On Wed, Jan 13, 2021 at 11:13:07AM -0600, Brian King wrote:
>> On 1/12/21 6:33 PM, Tyrel Datwyler wrote:
>>> On 1/12/21 2:54 PM, Brian King wrote:
>>>> On 1/11/21 5:12 PM, Tyrel Datwyler wrote:
>>>>> Introduce s
With the exception of the few comments I've shared, the rest of this looks
good to me and you can add my:
Reviewed-by: Brian King
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
t;mq_enabled = IBMVFC_MQ;
> - vhost->client_scsi_channels = IBMVFC_SCSI_CHANNELS;
> + vhost->mq_enabled = mq_enabled;
> + vhost->client_scsi_channels = min(nr_scsi_hw_queues, nr_scsi_channels);
> vhost->using_channels = 0;
> vhost->do_enquiry = 1;
>
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
On 1/12/21 6:33 PM, Tyrel Datwyler wrote:
> On 1/12/21 2:54 PM, Brian King wrote:
>> On 1/11/21 5:12 PM, Tyrel Datwyler wrote:
>>> Introduce several new vhost fields for managing MQ state of the adapter
>>> as well as initial defaults for MQ enablement.
>>&g
ement
our own host wide busy reference counting, which doesn't sound very good, or
we need to add some API to block / scsi that allows us to dynamically change
can_queue.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
default break needs to be a return -EIO.
> + }
> + }
> + }
> +
> + sdev_printk(KERN_INFO, sdev, "Successfully cancelled outstanding
> commands\n");
> + return 0;
> +}
> +
> +static int ibmvfc_cancel_all_sq(struct scsi_device *sdev, int type)
> {
> struct ibmvfc_host *vhost = shost_priv(sdev->host);
> struct ibmvfc_event *evt, *found_evt;
> @@ -2498,6 +2559,27 @@ static int ibmvfc_cancel_all(struct scsi_device *sdev,
> int type)
> return 0;
> }
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
tore. You'll need
to rethink the locking here. You could just do a spin_unlock_irq / spin_lock_irq
here and that would probably be OK, but probably isn't the best.
> }
>
> /**
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
the caller will wait for the command being
> cancelled to get returned */
> + goto free_events;
Similar comment here... What about the rest of the outstanding cancel commands?
Do you need
to wait for those to complete before freeing them?
>
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
wmb();
> + }
> +
> + ibmvfc_toggle_scrq_irq(scrq, 1);
> + if ((crq = ibmvfc_next_scrq(scrq)) != NULL) {
> + ibmvfc_toggle_scrq_irq(scrq, 0);
> + ibmvfc_handle_scrq(crq, scrq->vhost);
> + crq->valid = 0;
> + wmb();
> + } else
> + done = 1;
> + }
> + spin_unlock_irqrestore(scrq->vhost->host->host_lock, flags);
> +}
> +
> /**
> * ibmvfc_init_tgt - Set the next init job step for the target
> * @tgt: ibmvfc target struct
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
eed with discovery. You will proceed with enquiry and channel setup.
Then, I think you could end up in queuecommand doing this:
evt->hwq = hwq % vhost->scsi_scrqs.active_queues;
And that is a divide by zero...
I wonder if it would be better in this scenario where registering the sub crqs
fails,
if you just did:
vhost->do_enquiry = 0;
vhost->mq_enabled = 0;
vhost->using_channels = 0;
It looks like you only try to allocate the subcrqs in probe, so if that fails,
we'd
never end up using mq, so just disabling in this case seems reasonable.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
On 12/2/20 11:27 AM, Tyrel Datwyler wrote:
> On 12/2/20 7:14 AM, Brian King wrote:
>> On 12/1/20 6:53 PM, Tyrel Datwyler wrote:
>>> Introduce several new vhost fields for managing MQ state of the adapter
>>> as well as initial defaults for MQ enablement.
>>&g
nels = min(channels, nr_scsi_hw_queues);
Don't we need to do a LIP here for this new setting to go into effect?
> + spin_unlock_irqrestore(shost->host_lock, flags);
> + return strlen(buf);
> +}
> +
> static DEVICE_ATTR(partition_name, S_IRUGO, ibmvfc_show_host_partition_name,
> NULL);
> static DEVICE_ATTR(device_name, S_IRUGO, ibmvfc_show_host_device_name, NULL);
> static DEVICE_ATTR(port_loc_code, S_IRUGO, ibmvfc_show_host_loc_code, NULL);
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
to after the check
for !found_evt?
> +
> + found_evt = NULL;
> + list_for_each_entry(evt, >sent, queue) {
> + if (evt->cmnd && evt->cmnd->device == sdev && evt->hwq
> == i) {
> + found_evt = evt;
> + break;
> + }
> }
> - }
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
list, and call the done function
again,
which could result in a double completion to the scsi layer.
I think you need to grab the host lock before you check the free bit to avoid
this race.
> + spin_unlock_irqrestore(vhost->host->host_lock, flags);
> + evt->done(evt);
> +}
> +
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
also be in ibmvfc_reset_crq in another thread?
If so, you'd have a subtle race condition here where the cur pointer could
be read, then ibmvfc_reset_crq writes it to zero, then this thread
writes it to a non zero value, which would then cause you to be out of
sync with the VIOS as to where the cur pointer is.
> + scrq->cur = 0;
> + rmb();
> + } else
> + crq = NULL;
> +
> + return crq;
> +}
> +
--
Brian King
Power Linux I/O
IBM Linux Technology Center
oto reg_failed;
> + }
> +
> + scrq->hwq_id = index;
> + scrq->vhost = vhost;
> +
> + LEAVE;
> + return 0;
> +
> +reg_failed:
> + dma_unmap_single(dev, scrq->msg_token, PAGE_SIZE, DMA_BIDIRECTIONAL);
> +dma_map_failed:
> + free_page((unsigned long)scrq->msgs);
> + LEAVE;
> + return rc;
> +}
> +
--
Brian King
Power Linux I/O
IBM Linux Technology Center
= IBMVFC_MAX_CDB_LEN;
> shost->unique_id = shost->host_no;
> + shost->nr_hw_queues = IBMVFC_SCSI_HW_QUEUES;
>
> vhost = shost_priv(shost);
> INIT_LIST_HEAD(>sent);
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
ibmvfc_free_event(evt);
Looks like you are freeing this event twice due to the fallthrough...
> + fallthrough;
> + case IBMVFC_MAD_DRIVER_FAILED:
> + ibmvfc_free_event(evt);
> + return;
> + default:
> + dev_err(vhost->dev, "Invalid Channel Enquiry response: 0x%x\n",
> + mad_status);
> + ibmvfc_link_down(vhost, IBMVFC_LINK_DEAD);
> + ibmvfc_free_event(evt);
> + return;
> + }
> +
> + ibmvfc_channel_setup(vhost);
> +}
> +
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
; + dev_err(vhost->dev, "Received duplicate correlation_token
> 0x%08llx!\n",
> + crq->ioba);
> + return;
> + }
> +
> + del_timer(>timer);
> + list_del(>queue);
> + ibmvfc_trc_end(evt);
> + evt->done(evt);
> +}
> +
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
; + LEAVE;
> + return -1;
> + }
> + }
> +
> + LEAVE;
> + return 0;
> +}
> +
> +static void ibmvfc_release_sub_crqs(struct ibmvfc_host *vhost)
> +{
> + int i;
> +
> + ENTER;
> + if (!vhos
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
int scan_complete;
> int logged_in;
> + int mq_enabled;
> + int using_channels;
> + int do_enquiry;
> + int client_scsi_channels;
> int aborting_passthru;
> int events_to_log;
> #define IBMVFC_AE_LINKUP 0x0001
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
&
> IBMVFC_HANDLE_VF_WWPN)
Same here
> + return _cmd->v2.rsp;
> + else
> + return _cmd->v1.rsp;
> +}
> +
> #ifdef CONFIG_SCSI_IBMVFC_TRACE
> /**
> * ibmvfc_trc_start - Log a start trace entry
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Everything else in this series looks OK to me.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
On 11/17/20 4:14 PM, Brian King wrote:
> On 11/11/20 7:04 PM, Tyrel Datwyler wrote:
>> The FC iu and response payloads are located at different offsets
>> depending on the ibmvfc_cmd version. This is a result of the version 2
>> vfcFrame definition adding an extra 64by
fc_passthru_iu {
> __be64 correlation;
> __be64 scsi_id;
> __be64 tag;
> + __be64 targetWWPN;
For consistency, can you make this target_wwpn?
> __be64 reserved2[2];
> } __packed __aligned(8);
>
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
>
>> Since we are replacing a table for a device which is still in the
>> system, we should not try messing with its DMA if it already has
>> mappings so the warning should become an error preventing DDW. It is
>> rather hard to trigger in practice but I could hack a d
; return;
> }
>
> + pci_disable_pcie_error_reporting(pdev);
> +
> qla2x00_wait_for_sess_deletion(base_vha);
>
> set_bit(UNLOADING, _vha->dpc_flags);
> @@ -5866,7 +5870,6 @@ void qla2x00_relogin(struct scsi_qla_host *vha)
> qla2x00_unmap_iobases(ha);
>
> pci_release_selected_regions(ha->pdev, ha->bars);
> - pci_disable_pcie_error_reporting(pdev);
> pci_disable_device(pdev);
>
> /*
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
id =
> - (entries_each_hrrq - 1);
> + ioa_cfg->hrrq[i].max_cmd_id =
> + (entries_each_hrrq - 1);
> } else {
> entries_each_hrrq =
- 1);
> + ioa_cfg->hrrq[i].max_cmd_id =
> + (entries_each_hrrq - 1);
> } else {
> entries_each_hrrq =
> IPR_NUM_BASE_CMD_BLKS/
>
Acked-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
ers when issuing i/o to already configured
devices. Therefore, we cannot simply move the initialization of
jiffies_at_alloc to
scsi_init_rq. I've been working on moving the retry counter and jiffies_at_alloc
into struct scsi_request, as that doesn't get reinitialized.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
ers when issuing i/o to already configured
devices. Therefore, we cannot simply move the initialization of
jiffies_at_alloc to
scsi_init_rq. I've been working on moving the retry counter and jiffies_at_alloc
into struct scsi_request, as that doesn't get reinitialized.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
break the overall retry timer logic
in scsi_softirq_done.
Suggested-by: Bart Van Assche <bart.vanass...@wdc.com>
Signed-off-by: Brian King <brk...@linux.vnet.ibm.com>
---
Index: linux-2.6.git/drivers/scsi/scsi_lib.c
===
---
break the overall retry timer logic
in scsi_softirq_done.
Suggested-by: Bart Van Assche
Signed-off-by: Brian King
---
Index: linux-2.6.git/drivers/scsi/scsi_lib.c
===
--- linux-2.6.git.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6.git/d
Scratch this one... Version 2 on the way with the corresponding changes
in scsi_init_request...
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Scratch this one... Version 2 on the way with the corresponding changes
in scsi_init_request...
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
Save / restore the retry counter in scsi_cmd in scsi_init_command.
This allows us to go back through scsi_init_command for retries
and not forget we are doing a retry.
Signed-off-by: Brian King <brk...@linux.vnet.ibm.com>
---
Index: linux-2.6.git/drivers/scsi/scsi
Save / restore the retry counter in scsi_cmd in scsi_init_command.
This allows us to go back through scsi_init_command for retries
and not forget we are doing a retry.
Signed-off-by: Brian King
---
Index: linux-2.6.git/drivers/scsi/scsi_lib.c
art Van Assche <bart.vanass...@wdc.com>
Signed-off-by: Brian King <brk...@linux.vnet.ibm.com>
---
Index: linux-2.6.git/drivers/scsi/scsi_lib.c
===
--- linux-2.6.git.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6.git/drivers/
art Van Assche
Signed-off-by: Brian King
---
Index: linux-2.6.git/drivers/scsi/scsi_lib.c
===
--- linux-2.6.git.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6.git/drivers/scsi/scsi_lib.c
@@ -1154,6 +1154,7 @@ void scsi_init_command(str
the retry counter in scsi_init_command which lets us
go through scsi_init_command for retries and not forget why we were
there.
These patches have only been boot tested on my Power machine with ipr
to ensure they fix the issue I was seeing.
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology
the retry counter in scsi_init_command which lets us
go through scsi_init_command for retries and not forget why we were
there.
These patches have only been boot tested on my Power machine with ipr
to ensure they fix the issue I was seeing.
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology
On 08/18/2017 04:41 PM, Bart Van Assche wrote:
> On Fri, 2017-08-18 at 16:04 -0500, Brian King wrote:
>> I think I have an understanding what is going on and why Bart's patch is
>> causing problems for ipr.
>> I can work around the boot hang in ipr, but ultimately I think
On 08/18/2017 04:41 PM, Bart Van Assche wrote:
> On Fri, 2017-08-18 at 16:04 -0500, Brian King wrote:
>> I think I have an understanding what is going on and why Bart's patch is
>> causing problems for ipr.
>> I can work around the boot hang in ipr, but ultimately I think
Since ipr RAID arrays do not support the MAINTENANCE_IN /
MI_REPORT_SUPPORTED_OPERATION_CODES, set no_report_opcodes
to prevent it from being sent.
Signed-off-by: Brian King <brk...@linux.vnet.ibm.com>
---
Index: linux-2.6.git/drivers/scsi
Since ipr RAID arrays do not support the MAINTENANCE_IN /
MI_REPORT_SUPPORTED_OPERATION_CODES, set no_report_opcodes
to prevent it from being sent.
Signed-off-by: Brian King
---
Index: linux-2.6.git/drivers/scsi/ipr.c
===
--- linux
On 08/17/2017 10:52 AM, Bart Van Assche wrote:
> On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote:
>> On 08/16/2017 12:21 PM, Bart Van Assche wrote:
>>> On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
>>>> As of next-20170809, linux-next on powerpc boot hung
On 08/17/2017 10:52 AM, Bart Van Assche wrote:
> On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote:
>> On 08/16/2017 12:21 PM, Bart Van Assche wrote:
>>> On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
>>>> As of next-20170809, linux-next on powerpc boot hung
On 08/17/2017 10:32 AM, Bart Van Assche wrote:
> On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote:
>> On 08/16/2017 01:15 PM, Bart Van Assche wrote:
>>> On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
>>>> Linux-next booted with
On 08/17/2017 10:32 AM, Bart Van Assche wrote:
> On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote:
>> On 08/16/2017 01:15 PM, Bart Van Assche wrote:
>>> On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
>>>> Linux-next booted with
t supported by ipr, it should return with an
illegal request.
When I'm hung at this point, there is nothing outstanding to the adapter /
driver. I'll continue
debugging...
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
with an
illegal request.
When I'm hung at this point, there is nothing outstanding to the adapter /
driver. I'll continue
debugging...
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
37f90] [c003ea20] call_do_irq+0x14/0x24
>> [c007f84e3a70] [c001dae0] do_IRQ+0xd0/0x190
>> [c0000007f84e3ac0] [c0008c58] hardware_interrupt_common
>> +0x158/0x160
>
> Hello Brian,
>
> In the MAINTAINERS file I found the following:
>
> I
37f90] [c003ea20] call_do_irq+0x14/0x24
>> [c007f84e3a70] [c001dae0] do_IRQ+0xd0/0x190
>> [c0000007f84e3ac0] [c0008c58] hardware_interrupt_common
>> +0x158/0x160
>
> Hello Brian,
>
> In the MAINTAINERS file I found the following:
>
>
/0x4a0
[c01fffe97f90] [c002da50] call_do_irq+0x14/0x24
[c007fad93aa0] [c0017e8c] do_IRQ+0x9c/0x140
[c007fad93af0] [c0008b98] hardware_interrupt_common+0x138/0x140
Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Brian King <brk...@linux.vne
/0x4a0
[c01fffe97f90] [c002da50] call_do_irq+0x14/0x24
[c007fad93aa0] [c0017e8c] do_IRQ+0x9c/0x140
[c007fad93af0] [c0008b98] hardware_interrupt_common+0x138/0x140
Reported-by: Michael Ellerman
Signed-off-by: Brian King
---
Index: linux-2.6.git/drivers/scsi/ipr.c
On 07/28/2017 10:17 AM, Brian J King wrote:
> Jens Axboe wrote on 07/28/2017 09:25:48 AM:
>
>> Can you try the below fix? Should be more palatable than the previous
>> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
Michael,
Does this address the issue
On 07/28/2017 10:17 AM, Brian J King wrote:
> Jens Axboe wrote on 07/28/2017 09:25:48 AM:
>
>> Can you try the below fix? Should be more palatable than the previous
>> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
Michael,
Does this address the issue you are seeing?
writel() function on arm/arm64
>>> arhictectures have an embedded wmb() call inside.
>
> [Sreekanth] Whether same thing applicable for SPARC & POWER
> architectures. If yes then we are fine with this patch changes.
This is also true for Power.
Reviewed-by: Brian King <brk...@linux.vnet.ibm.com>
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
edded wmb() call inside.
>
> [Sreekanth] Whether same thing applicable for SPARC & POWER
> architectures. If yes then we are fine with this patch changes.
This is also true for Power.
Reviewed-by: Brian King
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
le we set that flag properly when deciding initially whether
to use LSIs or MSIs, we fail to set it if we first chose MSIs,
the test fails, then fallback to LSIs.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Signed-off-by: Brian King <brk...@linux.vnet.ibm.com>
---
when deciding initially whether
to use LSIs or MSIs, we fail to set it if we first chose MSIs,
the test fails, then fallback to LSIs.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Brian King
---
drivers/scsi/ipr.c |1 +
1 file changed, 1 insertion(+)
diff -puN drive
>
> You force gso_size to device mtu, regardless of real MSS used by the TCP
> sender.
>
> Don't you have the MSS provided in RX descriptor, instead of guessing
> the value ?
Eric,
We are currently pursuing making changes to the Power Virtual I/O Server to
provide
the MSS to the ibmveth driver. However, this will take time to go through test
and ultimately get released. Although imperfect, this patch does help a real
customer
hitting this issue right now. Would you object to this patch getting merged as
is,
with the understanding that when we get the change in the Virtual I/O Server
released,
we will revert this interim change and apply the new method?
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
s of real MSS used by the TCP
> sender.
>
> Don't you have the MSS provided in RX descriptor, instead of guessing
> the value ?
Eric,
We are currently pursuing making changes to the Power Virtual I/O Server to
provide
the MSS to the ibmveth driver. However, this will take time to go through test
and ultimately get released. Although imperfect, this patch does help a real
customer
hitting this issue right now. Would you object to this patch getting merged as
is,
with the understanding that when we get the change in the Virtual I/O Server
released,
we will revert this interim change and apply the new method?
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
On 11/06/2016 03:22 PM, Jonathan Maxwell wrote:
> On Thu, Nov 3, 2016 at 8:40 AM, Brian King <brk...@linux.vnet.ibm.com> wrote:
>> On 10/27/2016 10:26 AM, Eric Dumazet wrote:
>>> On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
>>>> We recently encounter
On 11/06/2016 03:22 PM, Jonathan Maxwell wrote:
> On Thu, Nov 3, 2016 at 8:40 AM, Brian King wrote:
>> On 10/27/2016 10:26 AM, Eric Dumazet wrote:
>>> On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
>>>> We recently encountered a bug where a few customers using
the VIOS (AIX based) is
actually
being done by software in the VIOS. What they may be able to do is when
performing
this aggregation, they could look at the packet lengths of all the packets being
aggregated and take the largest packet size within the aggregation unit, minus
the
header length a
ally
being done by software in the VIOS. What they may be able to do is when
performing
this aggregation, they could look at the packet lengths of all the packets being
aggregated and take the largest packet size within the aggregation unit, minus
the
header length and return that to the virtual e
send out?
Acked-by: Brian King <brk...@linux.vnet.ibm.com>
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
send out?
Acked-by: Brian King
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
>
>> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc
>>
>> The short changelog is:
>>
>> Brian King (1):
>> ipr: Wait to do async scan until scsi host is initialized
>
> This commit seems to be causing a ~10 minute pause during b
m/linux/kernel/git/jejb/scsi.git scsi-misc
>>
>> The short changelog is:
>>
>> Brian King (1):
>> ipr: Wait to do async scan until scsi host is initialized
>
> This commit seems to be causing a ~10 minute pause during boot on my
> powerpc boxes which have an
On 11/05/2015 02:26 AM, Laurent Vivier wrote:
>
>
> On 05/11/2015 00:06, Brian King wrote:
>> On 11/04/2015 07:02 AM, Hannes Reinecke wrote:
>>> On 11/04/2015 12:46 PM, Laurent Vivier wrote:
>>>>
>>>>
>>>> On 04/11/2015 12:16, Hannes
On 11/05/2015 02:51 AM, Hannes Reinecke wrote:
> On 11/05/2015 12:06 AM, Brian King wrote:
>> On 11/04/2015 07:02 AM, Hannes Reinecke wrote:
>>> On 11/04/2015 12:46 PM, Laurent Vivier wrote:
>>>>
>>>>
>>>> On 04/11/2015 12:16, Hannes Reinec
On 11/05/2015 02:26 AM, Laurent Vivier wrote:
>
>
> On 05/11/2015 00:06, Brian King wrote:
>> On 11/04/2015 07:02 AM, Hannes Reinecke wrote:
>>> On 11/04/2015 12:46 PM, Laurent Vivier wrote:
>>>>
>>>>
>>>> On 04/11/2015 12:16, Hannes
1 - 100 of 229 matches
Mail list logo