Some devices are not capable of addressing 64 bits
via DMA, which includes MSI-X vectors. This allows
us to ensure these devices use MSI-X vectors in
32 bit space.
Signed-off-by: Brian King
---
arch/powerpc/platforms/pseries/msi.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions
Acked-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
On 2/9/23 11:11 AM, Nathan Lynch wrote:
> Brian King writes:
>> On 2/7/23 9:14 AM, Nathan Lynch wrote:
>>> Brian King writes:
>>>> While testing fixes to the hvcs hotplug code, kmemleak was reporting
>>>> potential memory leaks. This was tracked
On 2/7/23 9:14 AM, Nathan Lynch wrote:
>
> (cc'ing a few possibly interested people)
>
> Brian King writes:
>> While testing fixes to the hvcs hotplug code, kmemleak was reporting
>> potential memory leaks. This was tracked down to the struct device_node
>> o
Synchronizes hotplug remove with the freeing of the port.
This ensures we have freed all the memory associated with
this port and are not leaking memory.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff
When hotplug removing an hvcs device, we need to ensure the
hangup processing is done prior to exiting the remove function,
so use tty_vhangup to do the hangup processing directly
rather than using tty_hangup which simply schedules the hangup
work for later execution.
Signed-off-by: Brian King
Grab a reference to the tty when removing the hvcs to ensure
it does not get freed unexpectedly.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index 522910716025
Rather than manually creating attributes for the hvcs driver,
let the driver core do this for us. This also fixes some hotplug
remove issues and ensures that cleanup of these attributes
is done in the right order.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 17 -
1
Use the dev_groups functionality to manage the attribute groups
for hvcs devices. This simplifies the code and also eliminates
errors coming from kernfs when attempting to remove a console
device that is in use.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 19 +--
1
attribute groups to use ATTRIBUTE_GROUPS macros
Changes since initial version:
- Change to use driver default groups to manage attribute lifecycle
Brian King (5):
hvcs: Use dev_groups to manage hvcs device attributes
hvcs: Use driver groups to manage driver attributes
hvcs: Get reference
Synchronizes hotplug remove with the freeing of the port.
This ensures we have freed all the memory associated with
this port and are not leaking memory.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff
When hotplug removing an hvcs device, we need to ensure the
hangup processing is done prior to exiting the remove function,
so use tty_vhangup to do the hangup processing directly
rather than using tty_hangup which simply schedules the hangup
work for later execution.
Signed-off-by: Brian King
Grab a reference to the tty when removing the hvcs to ensure
it does not get freed unexpectedly.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index 5de7ad40
Rather than manually creating attributes for the hvcs driver,
let the driver core do this for us. This also fixes some hotplug
remove issues and ensures that cleanup of these attributes
is done in the right order.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 24
Use the dev_groups functionality to manage the attribute groups
for hvcs devices. This simplifies the code and also eliminates
errors coming from kernfs when attempting to remove a console
device that is in use.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 24
The hvcs driver only ever gets two references to the port. One
at initialization time, and one at install time. Remove the code
that was trying to do multiple port puts for each open, which
would result in more puts than gets.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 18
:
- Change to use driver default groups to manage attribute lifecycle
Brian King (6):
hvcs: Fix hvcs port reference counting
hvcs: Use dev_groups to manage hvcs device attributes
hvcs: Use driver groups to manage driver attributes
hvcs: Get reference to tty in remove
hvcs: Use vhangup
of 1 still, and the release function was never
getting called as a result of this. This adds an of_node_put in
pSeries_reconfig_remove_node in order to balance the refcounting
so that we actually free the device_node in the case of it being
allocated in pSeries_reconfig_add_node.
Signed-off-by: Brian
Synchronizes hotplug remove with the freeing of the port.
This ensures we have freed all the memory associated with
this port and are not leaking memory.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff
When hotplug removing an hvcs device, we need to ensure the
hangup processing is done prior to exiting the remove function,
so use tty_vhangup to do the hangup processing directly
rather than using tty_hangup which simply schedules the hangup
work for later execution.
Signed-off-by: Brian King
Cleanup the sysfs group earlier in remove. This eliminates
errors coming from kernfs when attempting to remove a console
device that is in use.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvcs.c b
The hvcs driver only ever gets two references to the port. One
at initialization time, and one at install time. Remove the code
that was trying to do multiple port puts for each open, which
would result in more puts than gets.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 18
Grab a reference to the tty when removing the hvcs to ensure
it does not get freed unexpectedly.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index 9c5887d0c882
This moves the removal of the rescan sysfs attribute to occur
before the call to unregister the vio to ensure the removal
does not fail due to the vio driver already being freed.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
This patch series fixes a number of issues with hotplugging
hvcs devices including memory leaks as well as, the inability
to reconnect to a console device after it has been hot added
back, since it was not getting cleaned up properly on the
hotplug remove path.
Brian King (6):
hvcs: Fix hvcs
On 2/1/23 4:32 AM, Christophe Leroy wrote:
>
>
> Le 30/01/2023 à 23:43, Brian King a écrit :
>> This patch series fixes a number of issues with hotplugging
>> hvcs devices including memory leaks as well as, the inability
>> to reconnect to a console device after it
When hotplug removing an hvcs device, we need to ensure the
hangup processing is done prior to exiting the remove function,
so use tty_vhangup to do the hangup processing directly
rather than using tty_hangup which simply schedules the hangup
work for later execution.
Signed-off-by: Brian King
Synchronizes hotplug remove with the freeing of the port.
This ensures we have freed all the memory associated with
this port and are not leaking memory.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff
of 1 still, and the release function was never
getting called as a result of this. This adds an of_node_put in
pSeries_reconfig_remove_node in order to balance the refcounting
so that we actually free the device_node in the case of it being
allocated in pSeries_reconfig_add_node.
Signed-off-by: Brian
Grab a reference to the tty when removing the hvcs to ensure
it does not get freed unexpectedly.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index 9c5887d0c882
This moves the removal of the rescan sysfs attribute to occur
before the call to unregister the vio to ensure the removal
does not fail due to the vio driver already being freed.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Cleanup the sysfs group earlier in remove. This eliminates
errors coming from kernfs when attempting to remove a console
device that is in use.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvcs.c b
This patch series fixes a number of issues with hotplugging
hvcs devices including memory leaks as well as, the inability
to reconnect to a console device after it has been hot added
back, since it was not getting cleaned up properly on the
hotplug remove path.
Brian King (7):
hvcs: Fix hvcs
The hvcs driver only ever gets two references to the port. One
at initialization time, and one at install time. Remove the code
that was trying to do multiple port puts for each open, which
would result in more puts than gets.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 18
paths.
Signed-off-by: Brian King
---
drivers/scsi/ibmvscsi/ibmvfc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 00684e11976b..1a0c0b7289d2 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
On 10/26/21 12:39 AM, Alexey Kardashevskiy wrote:
>
>
> On 10/26/21 01:40, Brian King wrote:
>> On 10/23/21 7:18 AM, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 23/10/2021 07:18, Brian King wrote:
>>>> On 10/22/21 7:24 AM, Alexey Kardashevsk
On 10/23/21 7:18 AM, Alexey Kardashevskiy wrote:
>
>
> On 23/10/2021 07:18, Brian King wrote:
>> On 10/22/21 7:24 AM, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 22/10/2021 04:44, Brian King wrote:
>>>> If ibm,pmemory is installed in the sy
On 10/22/21 7:24 AM, Alexey Kardashevskiy wrote:
>
>
> On 22/10/2021 04:44, Brian King wrote:
>> If ibm,pmemory is installed in the system, it can appear anywhere
>> in the address space. This patch enhances how we handle DMA for devices when
>> ibm,pmemory is present
the default window to dynamically map ibm,pmemory.
In the case where we only have a single DMA window, this won't work,
so if the window is not big enough to map the entire address range,
we cannot direct map.
Signed-off-by: Brian King
---
arch/powerpc/platforms/pseries/iommu.c | 19
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
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
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
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
Reviewed-by: Brian King
--
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?
>
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
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
; + 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
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
one in a single threaded loop
from the discovery thread, but let's fix it up anyway to be safe.
Signed-off-by: Brian King
---
drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 322b
a bunch of checkpatch
> warnings.
Sorry about the checkpatch issues. Thanks for pulling this in.
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
.
This has been tested by IBM's storage interoperability team
on a FS9100, forcing the failover to occur. With debug tracing enabled
in the ibmvfc driver, we confirmed the move login was sent
in this scenario and confirmed the link bounce no longer occurred.
Signed-off-by: Brian King
---
drivers
>
>> 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
t; + vio_enable_interrupts(to_vio_dev(hostdata->dev));
Is it necessary to disable / enable interrupts around the call to
ibmvscsi_reset_host?
I don't know why we'd need to do that before calling the reset as we have other
cases, like ibmvscsi_timeout where we don't bother doing this. Also, at the end
of the reset we look to be already enabling interrupts.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
_reset_crq_queue can call msleep.
This had been implemented as separate reset_crq and reenable_crq fields
so that it could run lockless. I'm not opposed to changing this to a single
field in general, we just need to be careful where we are adding locking.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
->dev,
> pool->size * sizeof(*pool->iu_storage),
> ->iu_token, 0);
> +>iu_token, GFP_KERNEL);
> if (!pool->iu_storage) {
> kfree(pool->events);
> return -ENOMEM;
>
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
; if (!evt_struct->ext_list) {
> if (!firmware_has_feature(FW_FEATURE_CMO))
> sdev_printk(KERN_ERR, cmd->device,
>
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
1 - 100 of 306 matches
Mail list logo
