2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2008-06-11 00:20:56 +08:00
|
|
|
* zfcp device driver
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2008-06-11 00:20:56 +08:00
|
|
|
* Registration and callback for the s390 common I/O layer.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2012-07-20 17:15:04 +08:00
|
|
|
* Copyright IBM Corp. 2002, 2010
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
2008-12-25 20:39:53 +08:00
|
|
|
#define KMSG_COMPONENT "zfcp"
|
|
|
|
#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
|
|
|
|
|
2011-07-30 15:25:15 +08:00
|
|
|
#include <linux/module.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "zfcp_ext.h"
|
2010-02-17 18:18:50 +08:00
|
|
|
#include "zfcp_reqlist.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-05-15 19:18:21 +08:00
|
|
|
#define ZFCP_MODEL_PRIV 0x4
|
|
|
|
|
2009-11-24 23:54:00 +08:00
|
|
|
static DEFINE_SPINLOCK(zfcp_ccw_adapter_ref_lock);
|
|
|
|
|
|
|
|
struct zfcp_adapter *zfcp_ccw_adapter_by_cdev(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
struct zfcp_adapter *adapter;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
adapter = dev_get_drvdata(&cdev->dev);
|
|
|
|
if (adapter)
|
|
|
|
kref_get(&adapter->ref);
|
|
|
|
spin_unlock_irqrestore(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
return adapter;
|
|
|
|
}
|
|
|
|
|
|
|
|
void zfcp_ccw_adapter_put(struct zfcp_adapter *adapter)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
kref_put(&adapter->ref, zfcp_adapter_release);
|
|
|
|
spin_unlock_irqrestore(&zfcp_ccw_adapter_ref_lock, flags);
|
|
|
|
}
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
/**
|
|
|
|
* zfcp_ccw_activate - activate adapter and wait for it to finish
|
|
|
|
* @cdev: pointer to belonging ccw device
|
|
|
|
* @clear: Status flags to clear.
|
|
|
|
* @tag: s390dbf trace record tag
|
|
|
|
*/
|
|
|
|
static int zfcp_ccw_activate(struct ccw_device *cdev, int clear, char *tag)
|
2009-06-16 16:30:34 +08:00
|
|
|
{
|
2009-11-24 23:54:00 +08:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2009-06-16 16:30:34 +08:00
|
|
|
|
2009-08-18 21:43:27 +08:00
|
|
|
if (!adapter)
|
|
|
|
return 0;
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
zfcp_erp_clear_adapter_status(adapter, clear);
|
2010-09-08 20:40:01 +08:00
|
|
|
zfcp_erp_set_adapter_status(adapter, ZFCP_STATUS_COMMON_RUNNING);
|
2009-06-16 16:30:34 +08:00
|
|
|
zfcp_erp_adapter_reopen(adapter, ZFCP_STATUS_COMMON_ERP_FAILED,
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
tag);
|
2009-06-16 16:30:34 +08:00
|
|
|
zfcp_erp_wait(adapter);
|
2012-09-04 21:23:35 +08:00
|
|
|
flush_work(&adapter->scan_work); /* ok to call even if nothing queued */
|
2009-06-16 16:30:34 +08:00
|
|
|
|
2009-11-24 23:54:00 +08:00
|
|
|
zfcp_ccw_adapter_put(adapter);
|
|
|
|
|
2009-06-16 16:30:34 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-05-15 19:18:21 +08:00
|
|
|
static struct ccw_device_id zfcp_ccw_device_id[] = {
|
|
|
|
{ CCW_DEVICE_DEVTYPE(0x1731, 0x3, 0x1732, 0x3) },
|
|
|
|
{ CCW_DEVICE_DEVTYPE(0x1731, 0x3, 0x1732, ZFCP_MODEL_PRIV) },
|
|
|
|
{},
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(ccw, zfcp_ccw_device_id);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* zfcp_ccw_priv_sch - check if subchannel is privileged
|
|
|
|
* @adapter: Adapter/Subchannel to check
|
|
|
|
*/
|
|
|
|
int zfcp_ccw_priv_sch(struct zfcp_adapter *adapter)
|
|
|
|
{
|
|
|
|
return adapter->ccw_device->id.dev_model == ZFCP_MODEL_PRIV;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
|
|
|
* zfcp_ccw_probe - probe function of zfcp driver
|
2009-11-24 23:54:00 +08:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2009-08-18 21:43:27 +08:00
|
|
|
* This function gets called by the common i/o layer for each FCP
|
|
|
|
* device found on the current system. This is only a stub to make cio
|
|
|
|
* work: To only allocate adapter resources for devices actually used,
|
|
|
|
* the allocation is deferred to the first call to ccw_set_online.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2009-11-24 23:54:00 +08:00
|
|
|
static int zfcp_ccw_probe(struct ccw_device *cdev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-08-18 21:43:27 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* zfcp_ccw_remove - remove function of zfcp driver
|
2009-11-24 23:54:00 +08:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer and removes an adapter
|
|
|
|
* from the system. Task of this function is to get rid of all units and
|
|
|
|
* ports that belong to this adapter. And in addition all resources of this
|
|
|
|
* adapter will be freed too.
|
|
|
|
*/
|
2009-11-24 23:54:00 +08:00
|
|
|
static void zfcp_ccw_remove(struct ccw_device *cdev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct zfcp_adapter *adapter;
|
|
|
|
struct zfcp_port *port, *p;
|
|
|
|
struct zfcp_unit *unit, *u;
|
2008-10-01 18:42:20 +08:00
|
|
|
LIST_HEAD(unit_remove_lh);
|
|
|
|
LIST_HEAD(port_remove_lh);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-11-24 23:54:00 +08:00
|
|
|
ccw_device_set_offline(cdev);
|
2009-09-24 16:23:24 +08:00
|
|
|
|
2009-11-24 23:54:00 +08:00
|
|
|
adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2009-11-24 23:53:58 +08:00
|
|
|
if (!adapter)
|
|
|
|
return;
|
|
|
|
|
|
|
|
write_lock_irq(&adapter->port_list_lock);
|
|
|
|
list_for_each_entry_safe(port, p, &adapter->port_list, list) {
|
|
|
|
write_lock(&port->unit_list_lock);
|
2009-11-24 23:54:05 +08:00
|
|
|
list_for_each_entry_safe(unit, u, &port->unit_list, list)
|
2009-11-24 23:53:58 +08:00
|
|
|
list_move(&unit->list, &unit_remove_lh);
|
|
|
|
write_unlock(&port->unit_list_lock);
|
|
|
|
list_move(&port->list, &port_remove_lh);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2009-11-24 23:53:58 +08:00
|
|
|
write_unlock_irq(&adapter->port_list_lock);
|
2009-11-24 23:54:00 +08:00
|
|
|
zfcp_ccw_adapter_put(adapter); /* put from zfcp_ccw_adapter_by_cdev */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-11-24 23:53:59 +08:00
|
|
|
list_for_each_entry_safe(unit, u, &unit_remove_lh, list)
|
2010-02-17 18:18:56 +08:00
|
|
|
zfcp_device_unregister(&unit->dev, &zfcp_sysfs_unit_attrs);
|
2009-11-24 23:53:59 +08:00
|
|
|
|
|
|
|
list_for_each_entry_safe(port, p, &port_remove_lh, list)
|
2013-04-26 22:13:48 +08:00
|
|
|
device_unregister(&port->dev);
|
2009-11-24 23:53:59 +08:00
|
|
|
|
2009-11-24 23:54:00 +08:00
|
|
|
zfcp_adapter_unregister(adapter);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* zfcp_ccw_set_online - set_online function of zfcp driver
|
2009-11-24 23:54:00 +08:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2009-08-18 21:43:27 +08:00
|
|
|
* This function gets called by the common i/o layer and sets an
|
|
|
|
* adapter into state online. The first call will allocate all
|
|
|
|
* adapter resources that will be retained until the device is removed
|
|
|
|
* via zfcp_ccw_remove.
|
|
|
|
*
|
|
|
|
* Setting an fcp device online means that it will be registered with
|
|
|
|
* the SCSI stack, that the QDIO queues will be set up and that the
|
|
|
|
* adapter will be opened.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2009-11-24 23:54:00 +08:00
|
|
|
static int zfcp_ccw_set_online(struct ccw_device *cdev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-11-24 23:54:00 +08:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-08-18 21:43:27 +08:00
|
|
|
if (!adapter) {
|
2009-11-24 23:54:00 +08:00
|
|
|
adapter = zfcp_adapter_enqueue(cdev);
|
|
|
|
|
|
|
|
if (IS_ERR(adapter)) {
|
|
|
|
dev_err(&cdev->dev,
|
2009-08-18 21:43:27 +08:00
|
|
|
"Setting up data structures for the "
|
|
|
|
"FCP adapter failed\n");
|
2009-11-24 23:54:00 +08:00
|
|
|
return PTR_ERR(adapter);
|
2009-08-18 21:43:27 +08:00
|
|
|
}
|
2009-11-24 23:54:00 +08:00
|
|
|
kref_get(&adapter->ref);
|
2009-08-18 21:43:27 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-08-02 17:05:16 +08:00
|
|
|
/* initialize request counter */
|
2010-02-17 18:18:50 +08:00
|
|
|
BUG_ON(!zfcp_reqlist_isempty(adapter->req_list));
|
2006-08-02 17:05:16 +08:00
|
|
|
adapter->req_no = 0;
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
zfcp_ccw_activate(cdev, 0, "ccsonl1");
|
2012-09-04 21:23:35 +08:00
|
|
|
/* scan for remote ports
|
|
|
|
either at the end of any successful adapter recovery
|
|
|
|
or only after the adapter recovery for setting a device online */
|
|
|
|
zfcp_fc_inverse_conditional_port_scan(adapter);
|
|
|
|
flush_work(&adapter->scan_work); /* ok to call even if nothing queued */
|
2009-11-24 23:54:00 +08:00
|
|
|
zfcp_ccw_adapter_put(adapter);
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
* zfcp_ccw_offline_sync - shut down adapter and wait for it to finish
|
2009-11-24 23:54:00 +08:00
|
|
|
* @cdev: pointer to belonging ccw device
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
* @set: Status flags to set.
|
|
|
|
* @tag: s390dbf trace record tag
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer and sets an adapter
|
2007-05-09 17:01:24 +08:00
|
|
|
* into state offline.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
static int zfcp_ccw_offline_sync(struct ccw_device *cdev, int set, char *tag)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-11-24 23:54:00 +08:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
|
|
|
|
|
|
|
if (!adapter)
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
zfcp_erp_set_adapter_status(adapter, set);
|
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, tag);
|
2005-04-17 06:20:36 +08:00
|
|
|
zfcp_erp_wait(adapter);
|
2009-11-24 23:54:00 +08:00
|
|
|
|
|
|
|
zfcp_ccw_adapter_put(adapter);
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
/**
|
|
|
|
* zfcp_ccw_set_offline - set_offline function of zfcp driver
|
|
|
|
* @cdev: pointer to belonging ccw device
|
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer and sets an adapter
|
|
|
|
* into state offline.
|
|
|
|
*/
|
|
|
|
static int zfcp_ccw_set_offline(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
return zfcp_ccw_offline_sync(cdev, 0, "ccsoff1");
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
2008-06-11 00:20:56 +08:00
|
|
|
* zfcp_ccw_notify - ccw notify function
|
2009-11-24 23:54:00 +08:00
|
|
|
* @cdev: pointer to belonging ccw device
|
2005-04-17 06:20:36 +08:00
|
|
|
* @event: indicates if adapter was detached or attached
|
|
|
|
*
|
|
|
|
* This function gets called by the common i/o layer if an adapter has gone
|
|
|
|
* or reappeared.
|
|
|
|
*/
|
2009-11-24 23:54:00 +08:00
|
|
|
static int zfcp_ccw_notify(struct ccw_device *cdev, int event)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-11-24 23:54:00 +08:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
|
|
|
|
|
|
|
if (!adapter)
|
|
|
|
return 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
switch (event) {
|
|
|
|
case CIO_GONE:
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
if (atomic_read(&adapter->status) &
|
|
|
|
ZFCP_STATUS_ADAPTER_SUSPENDED) { /* notification ignore */
|
|
|
|
zfcp_dbf_hba_basic("ccnigo1", adapter);
|
|
|
|
break;
|
|
|
|
}
|
2009-11-24 23:54:00 +08:00
|
|
|
dev_warn(&cdev->dev, "The FCP device has been detached\n");
|
2010-12-02 22:16:16 +08:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccnoti1");
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
case CIO_NO_PATH:
|
2009-11-24 23:54:00 +08:00
|
|
|
dev_warn(&cdev->dev,
|
2008-10-01 18:42:15 +08:00
|
|
|
"The CHPID for the FCP device is offline\n");
|
2010-12-02 22:16:16 +08:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccnoti2");
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
case CIO_OPER:
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
if (atomic_read(&adapter->status) &
|
|
|
|
ZFCP_STATUS_ADAPTER_SUSPENDED) { /* notification ignore */
|
|
|
|
zfcp_dbf_hba_basic("ccniop1", adapter);
|
|
|
|
break;
|
|
|
|
}
|
2009-11-24 23:54:00 +08:00
|
|
|
dev_info(&cdev->dev, "The FCP device is operational again\n");
|
2010-09-08 20:40:01 +08:00
|
|
|
zfcp_erp_set_adapter_status(adapter,
|
|
|
|
ZFCP_STATUS_COMMON_RUNNING);
|
2008-04-18 18:51:55 +08:00
|
|
|
zfcp_erp_adapter_reopen(adapter, ZFCP_STATUS_COMMON_ERP_FAILED,
|
2010-12-02 22:16:16 +08:00
|
|
|
"ccnoti4");
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2009-04-01 01:16:05 +08:00
|
|
|
case CIO_BOXED:
|
2009-11-24 23:54:00 +08:00
|
|
|
dev_warn(&cdev->dev, "The FCP device did not respond within "
|
|
|
|
"the specified time\n");
|
2010-12-02 22:16:16 +08:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccnoti5");
|
2009-04-01 01:16:05 +08:00
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2009-11-24 23:54:00 +08:00
|
|
|
|
|
|
|
zfcp_ccw_adapter_put(adapter);
|
2005-04-17 06:20:36 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-06-11 00:20:56 +08:00
|
|
|
* zfcp_ccw_shutdown - handle shutdown from cio
|
|
|
|
* @cdev: device for adapter to shutdown.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2008-06-11 00:20:56 +08:00
|
|
|
static void zfcp_ccw_shutdown(struct ccw_device *cdev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-11-24 23:54:00 +08:00
|
|
|
struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-09-24 16:23:23 +08:00
|
|
|
if (!adapter)
|
2009-11-24 23:54:00 +08:00
|
|
|
return;
|
2009-09-24 16:23:23 +08:00
|
|
|
|
2010-12-02 22:16:16 +08:00
|
|
|
zfcp_erp_adapter_shutdown(adapter, 0, "ccshut1");
|
2005-04-17 06:20:36 +08:00
|
|
|
zfcp_erp_wait(adapter);
|
2009-08-18 21:43:27 +08:00
|
|
|
zfcp_erp_thread_kill(adapter);
|
2009-11-24 23:54:00 +08:00
|
|
|
|
|
|
|
zfcp_ccw_adapter_put(adapter);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
static int zfcp_ccw_suspend(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
zfcp_ccw_offline_sync(cdev, ZFCP_STATUS_ADAPTER_SUSPENDED, "ccsusp1");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int zfcp_ccw_thaw(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
/* trace records for thaw and final shutdown during suspend
|
|
|
|
can only be found in system dump until the end of suspend
|
|
|
|
but not after resume because it's based on the memory image
|
|
|
|
right after the very first suspend (freeze) callback */
|
|
|
|
zfcp_ccw_activate(cdev, 0, "ccthaw1");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int zfcp_ccw_resume(struct ccw_device *cdev)
|
|
|
|
{
|
|
|
|
zfcp_ccw_activate(cdev, ZFCP_STATUS_ADAPTER_SUSPENDED, "ccresu1");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-24 16:23:22 +08:00
|
|
|
struct ccw_driver zfcp_ccw_driver = {
|
2011-03-23 17:16:02 +08:00
|
|
|
.driver = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.name = "zfcp",
|
|
|
|
},
|
2008-06-11 00:20:56 +08:00
|
|
|
.ids = zfcp_ccw_device_id,
|
|
|
|
.probe = zfcp_ccw_probe,
|
|
|
|
.remove = zfcp_ccw_remove,
|
|
|
|
.set_online = zfcp_ccw_set_online,
|
|
|
|
.set_offline = zfcp_ccw_set_offline,
|
|
|
|
.notify = zfcp_ccw_notify,
|
|
|
|
.shutdown = zfcp_ccw_shutdown,
|
[SCSI] zfcp: Do not wakeup while suspended
If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.
The following kernel messages could be seen on resume:
kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping
As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.
kernel: zfcp.3dff9c: <FCP device bus ID>:\
Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
ERP cannot recover an error on the FCP device
In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.
Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.32+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-04 21:23:32 +08:00
|
|
|
.freeze = zfcp_ccw_suspend,
|
|
|
|
.thaw = zfcp_ccw_thaw,
|
|
|
|
.restore = zfcp_ccw_resume,
|
2008-06-11 00:20:56 +08:00
|
|
|
};
|