Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
On 11/26/2012 03:32 PM, James Bottomley wrote: On Mon, 2012-11-26 at 13:09 +0800, Aaron Lu wrote: On 11/26/2012 01:03 PM, James Bottomley wrote: On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote: On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote: I really think we need a way for (auto)pm and event polling to talk to each other so that autopm can tell event poll to sod off while pm is in effect. Trying to solve this from inside libata doesn't seem right. The problem, again, seems to be figuring out which hardware device maps to which block device. Hmmm... Any good ideas? I've asked the PM people several times about this, because it's a real problem for almost everything: PM needs some type of top to bottom stack view, which the layering isolation we have within storage really doesn't cope with well. No real suggestion has been forthcoming. Actually, I think that the particular case in question is really special and the fact that there's the pollig loop that user space is involved in doesn't make things more stratightforward. And PM really doesn't need to see things top to bottom, but the polling needs to know what happens in the PM land. We need to be able to tell it from now on tell user space that there are no events here. The question is where to put that information so that it's accessible to all parts of the stack involved. Right, open to suggestions ... The reason I think it should be emulated (in the acpi layer, not libata, but as long as it's not in SCSI, I'm not so fussed where it ends up) is because ZPODD is the software equivalent of ZPREADY, which will be done in hardware and will be effectively invisible to autopm in the same way that SCSI (and ATA) power management is mostly invisible. If we currently do ZPREADY emulation in the low layer (i.e. ZPODD has exact ZPREADY emulation), we won't care (except for flipping the sofware bit) whether the device support ZPODD or ZPREADY and it will all just work(tm). The industry expectation is that ZPODD is just a transition state between current power management and ZPREADY. Well, if you poll a ZPREADY-capable drive, it will go off and on in cycles transparently, but still it won't save as much energy as it can. We'll need to do something about the polling in that case too, it seems. No: with ZPREADY, the device effectively lies to the poll. The Spec says that when it powers off the mechanical pieces, it must reply from firmware to a certain preset emulations of SCSI commands and not wake from power off. These commands include TEST UNIT READY and a few others, so the device will happily reply to polls while being off (it replies with the original state before power was lost). When you issue actual medium access commands, or manually insert or remove media it will wake up. That's why I think ZPODD should emulate this behaviour. I suppose you are refering to section 15.3.5? That's the recommendation for emulating ZPREADY in ZPODD devices, yes. I don't think the SPEC says what the host software _must_ do, it's informative. And I agree that when possible, we should emulate the command without powering up the ODD, but if we can eliminate the noise, wouldn't that be better? The way I look at it is we currently have no real power management for actual SCSI devices, we rely on the internal timers of the device to effect power management for us. ZPREADY fits right into this scheme (as I think it was designed to) so it seems odd to me that we would introduce a software PM based scheme for ZPODD, which is an interim spec until everything supports ZPREADY, and then go back to doing nothing for ZPREADY. I'm amenable to a proposal that we *shouldn't* be doing nothing for SCSI PM and perhaps it should be plumbed into software PM, but it looks odd to me to have sofware PM for ZPODD but not for at least ZPREADY and probably for SCSI PM as well. Well, ZPREADY is not a power state that we can program the ODD to enter(figure 234 and table 323 of the SPEC), it servers more like an information provided by ODD to host so that host does not need to do TUR and then examine the sense code to decide if zero power ready status is satisfied but simply query ODD if its current power state is ZPREADY. So it's not that we program the device to go into ZPREADY power state and the ODD's power will be omitted. The benefit of a ZPREADY capable ODD is that, when we need to decide if the ODD is in a zero power ready status, we can simply query the ODD by issuing a GET_EVENT_STATUS_NOTIFICATION and check the returned power class events, if it is in ZPREADY power state, then we can omit the power. To support ZPREADY, we just need some change to the zpready funtion, which currently uses sense code to check ZP ready status. So this is my understanding of ZPREADY, and I don't see it as a total different thing with ZPODD, it just changes the way how host senses the zero power
Re: [PATCH 03/11] IB/srp: don't send anything on a bad QP
On 11/26/12 05:44, David Dillow wrote: Once we know we have an issue with the QP, there is no point trying to send anything else down the pipe. This also allows us to consolidate code in the SCSI EH path. [ ... ] @@ -1683,7 +1681,7 @@ static int srp_send_tsk_mgmt(struct srp_target_port *target, struct srp_iu *iu; struct srp_tsk_mgmt *tsk_mgmt; - if (srp_is_removed(target)) + if (target-state) return -1; Hi Dave, After I posted the patch on which the above patch has been based I realized that testing the connection state at the start of srp_send_tsk_mgmt() is not sufficient to avoid QPN use-after-free. If a DREQ is received by the initiator after the above test has been performed and before the task management function has been sent it is still possible to send a task management function over a closed QP. I'd like to address this in a different way - see also the thread called SCSI LLDs, the SCSI error handler and host resource lifetime on the linux-scsi mailing list (November 20, http://marc.info/?t=13534215553r=1). Sorry for the confusion I caused. Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] IB/srp: keep processing commands during host removal
On 11/26/12 05:44, David Dillow wrote:
From: Bart Van Assche bvanass...@acm.org
Some SCSI upper layer drivers, e.g. sd, issue SCSI commands from
inside scsi_remove_host() (see also the sd_shutdown() call in
sd_remove()). Make sure that these commands have a chance to reach
the SCSI device.
Signed-off-by: Bart Van Assche bvanass...@acm.org
[ adapted to new state tracking ]
Signed-off-by: David Dillow dillo...@ornl.gov
---
drivers/infiniband/ulp/srp/ib_srp.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 2951e1c..f7d7e6a 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1328,12 +1328,13 @@ static int srp_queuecommand(struct Scsi_Host *shost,
struct scsi_cmnd *scmnd)
int len;
if (unlikely(target-state)) {
- if (!srp_is_removed(target))
+ /*
+ * Only requeue commands if we cannot send them to the target.
+ * We'll let commands through during shutdown so that caches
+ * get flushed, etc.
+ */
+ if (srp_is_disconnected(target) || srp_in_error(target))
goto err;
-
- scmnd-result = DID_BAD_TARGET 16;
- scmnd-scsi_done(scmnd);
- return 0;
}
spin_lock_irqsave(target-lock, flags);
Hi Dave,
After I posted the patch on which the above patch has been based I
realized that it can be simplified. Since the patch called Eliminate
state SRP_TARGET_CONNECTING blocks the SCSI host as long as the RDMA
RC connection is being reconnected srp_queuecommand() won't be invoked
during the disconnected or error state. How about adding the patch
below just after the patch that eliminates the state
SRP_TARGET_CONNECTING ?
Bart.
[PATCH] ib_srp: Keep processing commands during host removal
Some SCSI upper layer drivers, e.g. sd, issue SCSI commands from
inside scsi_remove_host(). See also the sd_shutdown() call in
sd_remove(). Make sure that these commands have a chance to reach
the SCSI device.
Signed-off-by: Bart Van Assche bvanass...@acm.org
---
drivers/infiniband/ulp/srp/ib_srp.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 39723e7..03b9fa0 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1324,13 +1324,6 @@ static int srp_queuecommand(struct Scsi_Host *shost,
struct scsi_cmnd *scmnd)
unsigned long flags;
int len;
- if (target-state == SRP_TARGET_DEAD ||
- target-state == SRP_TARGET_REMOVED) {
- scmnd-result = DID_BAD_TARGET 16;
- scmnd-scsi_done(scmnd);
- return 0;
- }
-
spin_lock_irqsave(target-lock, flags);
iu = __srp_get_tx_iu(target, SRP_IU_CMD);
if (!iu)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] IB/srp: simplify state tracking
On 11/26/12 05:44, David Dillow wrote: The state of the target has several conditions that overlap, making it easier to model as a bit-field of exceptional conditions rather than an enum of all possible states. Bart Van Assche did the hard work of identifying the states that can be removed, and did a first patch that consolidated the state space. [ ... ] Hi Dave, Could you please explain why you would prefer to use test_bit () / test_and_set_bit() and clear_bit() for managing the SRP target state ? As far as I can see the target state is not changed in any code path where it matters how fast the state is changed. Maybe I'm missing something ? Thanks, Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
On Mon, 2012-11-26 at 16:27 +0800, Aaron Lu wrote: Well, ZPREADY is not a power state that we can program the ODD to enter(figure 234 and table 323 of the SPEC), it servers more like an information provided by ODD to host so that host does not need to do TUR and then examine the sense code to decide if zero power ready status is satisfied but simply query ODD if its current power state is ZPREADY. So it's not that we program the device to go into ZPREADY power state and the ODD's power will be omitted. The benefit of a ZPREADY capable ODD is that, when we need to decide if the ODD is in a zero power ready status, we can simply query the ODD by issuing a GET_EVENT_STATUS_NOTIFICATION and check the returned power class events, if it is in ZPREADY power state, then we can omit the power. To support ZPREADY, we just need some change to the zpready funtion, which currently uses sense code to check ZP ready status. So this is my understanding of ZPREADY, and I don't see it as a total different thing with ZPODD, it just changes the way how host senses the zero power ready status. But if I was wrong, please kindly let me know, thanks. My understanding is that a ZPREADY device may be capable of internal power down, meaning it doesn't necessarily need the host to omit the power. It depends what the difference is between Sleep and Off is (they're deliberately left as implementation defined in the standard, Ch 16, but the conditions of sleep are pretty onerous, so it sounds like most of the mechanics are powered down). However, if you want to work it similarly to ZPODD, then the timeouts automatically transitions to ZPREADY, the device issues an event, we trap the event at the low level and omit power. I'm also curious about driving sleep from autopm, since mode page timers don't control the sleep transition. James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] ipr: Resource path error logging cleanup
The resource path as displayed by the ipr driver is the
location string identifying a location on the SAS fabric.
This patch adds the SCSI host number such that error logs
can be more easily correlated in multiple adapter configurations.
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 78 -
drivers/scsi/ipr.h |5 ++-
2 files changed, 56 insertions(+), 27 deletions(-)
Index: b/drivers/scsi/ipr.h
===
--- a/drivers/scsi/ipr.h2012-11-14 23:07:25.986404583 -0600
+++ b/drivers/scsi/ipr.h2012-11-14 23:11:26.756404525 -0600
@@ -409,7 +409,7 @@ struct ipr_config_table_entry64 {
__be64 dev_id;
__be64 lun;
__be64 lun_wwn[2];
-#define IPR_MAX_RES_PATH_LENGTH24
+#define IPR_MAX_RES_PATH_LENGTH48
__be64 res_path;
struct ipr_std_inq_data std_inq_data;
u8 reserved2[4];
@@ -1722,7 +1722,8 @@ struct ipr_ucode_image_header {
if (ipr_is_device(hostrcb)) { \
if ((hostrcb)-ioa_cfg-sis64) {\
printk(KERN_ERR IPR_NAME : %s: fmt, \
-
ipr_format_res_path(hostrcb-hcam.u.error64.fd_res_path, \
+ ipr_format_res_path(hostrcb-ioa_cfg, \
+ hostrcb-hcam.u.error64.fd_res_path, \
hostrcb-rp_buffer, \
sizeof(hostrcb-rp_buffer)),\
__VA_ARGS__); \
Index: b/drivers/scsi/ipr.c
===
--- a/drivers/scsi/ipr.c2012-11-14 23:09:49.484214019 -0600
+++ b/drivers/scsi/ipr.c2012-11-14 23:28:24.724214331 -0600
@@ -1166,14 +1166,15 @@ static int ipr_is_same_device(struct ipr
}
/**
- * ipr_format_res_path - Format the resource path for printing.
+ * __ipr_format_res_path - Format the resource path for printing.
* @res_path: resource path
* @buf: buffer
+ * @len: length of buffer provided
*
* Return value:
* pointer to buffer
**/
-static char *ipr_format_res_path(u8 *res_path, char *buffer, int len)
+static char *__ipr_format_res_path(u8 *res_path, char *buffer, int len)
{
int i;
char *p = buffer;
@@ -1187,6 +1188,27 @@ static char *ipr_format_res_path(u8 *res
}
/**
+ * ipr_format_res_path - Format the resource path for printing.
+ * @ioa_cfg: ioa config struct
+ * @res_path: resource path
+ * @buf: buffer
+ * @len: length of buffer provided
+ *
+ * Return value:
+ * pointer to buffer
+ **/
+static char *ipr_format_res_path(struct ipr_ioa_cfg *ioa_cfg,
+u8 *res_path, char *buffer, int len)
+{
+ char *p = buffer;
+
+ *p = '\0';
+ p += snprintf(p, buffer + len - p, %d/, ioa_cfg-host-host_no);
+ __ipr_format_res_path(res_path, p, len - (buffer - p));
+ return buffer;
+}
+
+/**
* ipr_update_res_entry - Update the resource entry.
* @res: resource entry struct
* @cfgtew:config table entry wrapper struct
@@ -1226,8 +1248,8 @@ static void ipr_update_res_entry(struct
if (res-sdev new_path)
sdev_printk(KERN_INFO, res-sdev, Resource path: %s\n,
- ipr_format_res_path(res-res_path, buffer,
- sizeof(buffer)));
+ ipr_format_res_path(res-ioa_cfg,
+ res-res_path, buffer, sizeof(buffer)));
} else {
res-flags = cfgtew-u.cfgte-flags;
if (res-flags IPR_IS_IOA_RESOURCE)
@@ -1613,8 +1635,8 @@ static void ipr_log_sis64_config_error(s
ipr_err_separator;
ipr_err(Device %d : %s, i + 1,
-ipr_format_res_path(dev_entry-res_path, buffer,
-sizeof(buffer)));
+ __ipr_format_res_path(dev_entry-res_path,
+ buffer, sizeof(buffer)));
ipr_log_ext_vpd(dev_entry-vpd);
ipr_err(-New Device Information-\n);
@@ -1960,14 +1982,16 @@ static void ipr_log64_fabric_path(struct
ipr_hcam_err(hostrcb, %s %s: Resource Path=%s\n,
path_active_desc[i].desc,
path_state_desc[j].desc,
-ipr_format_res_path(fabric-res_path,
buffer,
-sizeof(buffer)));
+ipr_format_res_path(hostrcb-ioa_cfg,
+
[PATCH 0/7] Add support for new IBM SAS controllers
The new generation IBM SAS controllers will support MSI-X interrupt and Distributed Completion Processing features. The patches in this series add the code to support these new hardware features and also add some patches for performance improvement such as block iopoll and reducing lock contention in ipr driver. Thanks for your help! Wendy -- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ipr: Add sereral new CCIN definitions for new adapters support
Add the appropriate definitions and table entries for new adapter support.
Signed-off-by: Wen Xiong wenxi...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 10 ++
drivers/scsi/ipr.h |5 +
2 files changed, 15 insertions(+)
Index: b/drivers/scsi/ipr.c
===
--- a/drivers/scsi/ipr.c2012-11-14 20:15:46.666405044 -0600
+++ b/drivers/scsi/ipr.c2012-11-14 20:23:26.295466065 -0600
@@ -9279,6 +9279,8 @@ static struct pci_device_id ipr_pci_tabl
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROC_FPGA_E2,
PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57B2, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROC_FPGA_E2,
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57C0, 0, 0, 0 },
+ { PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROC_FPGA_E2,
PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57C3, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROC_FPGA_E2,
PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57C4, 0, 0, 0 },
@@ -9292,6 +9294,14 @@ static struct pci_device_id ipr_pci_tabl
PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57C8, 0, 0, 0 },
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROCODILE,
PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57CE, 0, 0, 0 },
+ { PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROCODILE,
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57D5, 0, 0, 0 },
+ { PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROCODILE,
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57D6, 0, 0, 0 },
+ { PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROCODILE,
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57D7, 0, 0, 0 },
+ { PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CROCODILE,
+ PCI_VENDOR_ID_IBM, IPR_SUBS_DEV_ID_57D8, 0, 0, 0 },
{ }
};
MODULE_DEVICE_TABLE(pci, ipr_pci_table);
Index: b/drivers/scsi/ipr.h
===
--- a/drivers/scsi/ipr.h2012-11-14 20:15:46.666405044 -0600
+++ b/drivers/scsi/ipr.h2012-11-14 20:23:23.404216172 -0600
@@ -82,6 +82,7 @@
#define IPR_SUBS_DEV_ID_57B40x033B
#define IPR_SUBS_DEV_ID_57B20x035F
+#define IPR_SUBS_DEV_ID_57C00x0352
#define IPR_SUBS_DEV_ID_57C30x0353
#define IPR_SUBS_DEV_ID_57C40x0354
#define IPR_SUBS_DEV_ID_57C60x0357
@@ -94,6 +95,10 @@
#define IPR_SUBS_DEV_ID_574D0x0356
#define IPR_SUBS_DEV_ID_57C80x035D
+#define IPR_SUBS_DEV_ID_57D50x03FB
+#define IPR_SUBS_DEV_ID_57D60x03FC
+#define IPR_SUBS_DEV_ID_57D70x03FF
+#define IPR_SUBS_DEV_ID_57D80x03FE
#define IPR_NAME ipr
/*
--
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ipr: Handler ID memory allocation failure
Add code to handle memory allocation failures at module load time.
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c |7 +++
1 file changed, 7 insertions(+)
Index: b/drivers/scsi/ipr.c
===
--- a/drivers/scsi/ipr.c2012-11-14 23:07:30.067656109 -0600
+++ b/drivers/scsi/ipr.c2012-11-14 23:09:49.484214019 -0600
@@ -8516,6 +8516,10 @@ static int __devinit ipr_alloc_mem(struc
BITS_TO_LONGS(ioa_cfg-max_devs_supported), GFP_KERNEL);
ioa_cfg-vset_ids = kzalloc(sizeof(unsigned long) *
BITS_TO_LONGS(ioa_cfg-max_devs_supported), GFP_KERNEL);
+
+ if (!ioa_cfg-target_ids || !ioa_cfg-array_ids
+ || !ioa_cfg-vset_ids)
+ goto out_free_res_entries;
}
for (i = 0; i ioa_cfg-max_devs_supported; i++) {
@@ -8591,6 +8595,9 @@ out_free_vpd_cbs:
ioa_cfg-vpd_cbs, ioa_cfg-vpd_cbs_dma);
out_free_res_entries:
kfree(ioa_cfg-res_entries);
+ kfree(ioa_cfg-target_ids);
+ kfree(ioa_cfg-array_ids);
+ kfree(ioa_cfg-vset_ids);
goto out;
}
--
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] ipr: Add support for MSI-X and distributed completion
The new generation IBM SAS Controllers will support MSI-X interrupts and
Distributed Completion Processing features. This patch add these support
in ipr device driver.
Signed-off-by: Wen Xiong wenxi...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 716 -
drivers/scsi/ipr.h | 70 +++--
2 files changed, 593 insertions(+), 193 deletions(-)
Index: b/drivers/scsi/ipr.c
===
--- a/drivers/scsi/ipr.c2012-11-14 23:28:24.724214331 -0600
+++ b/drivers/scsi/ipr.c2012-11-15 20:48:21.684212986 -0600
@@ -98,6 +98,7 @@ static unsigned int ipr_transop_timeout
static unsigned int ipr_debug = 0;
static unsigned int ipr_max_devs = IPR_DEFAULT_SIS64_DEVS;
static unsigned int ipr_dual_ioa_raid = 1;
+static unsigned int ipr_number_of_msix = 2;
static DEFINE_SPINLOCK(ipr_driver_lock);
/* This table describes the differences between DMA controller chips */
@@ -215,6 +216,8 @@ MODULE_PARM_DESC(dual_ioa_raid, Enable
module_param_named(max_devs, ipr_max_devs, int, 0);
MODULE_PARM_DESC(max_devs, Specify the maximum number of physical devices.
[Default= __stringify(IPR_DEFAULT_SIS64_DEVS) ]);
+module_param_named(number_of_msix, ipr_number_of_msix, int, 0);
+MODULE_PARM_DESC(number_of_msix, Specify the number of MSIX interrupts to use
on capable adapters (1 - 5). (default:1));
MODULE_LICENSE(GPL);
MODULE_VERSION(IPR_DRIVER_VERSION);
@@ -595,8 +598,11 @@ static void ipr_reinit_ipr_cmnd(struct i
struct ipr_ioasa *ioasa = ipr_cmd-s.ioasa;
struct ipr_ioasa64 *ioasa64 = ipr_cmd-s.ioasa64;
dma_addr_t dma_addr = ipr_cmd-dma_addr;
+ int hrrq_id;
+ hrrq_id = ioarcb-cmd_pkt.hrrq_id;
memset(ioarcb-cmd_pkt, 0, sizeof(struct ipr_cmd_pkt));
+ ioarcb-cmd_pkt.hrrq_id = hrrq_id;
ioarcb-data_transfer_length = 0;
ioarcb-read_data_transfer_length = 0;
ioarcb-ioadl_len = 0;
@@ -646,12 +652,16 @@ static void ipr_init_ipr_cmnd(struct ipr
* pointer to ipr command struct
**/
static
-struct ipr_cmnd *__ipr_get_free_ipr_cmnd(struct ipr_ioa_cfg *ioa_cfg)
+struct ipr_cmnd *__ipr_get_free_ipr_cmnd(struct ipr_hrr_queue *hrrq)
{
- struct ipr_cmnd *ipr_cmd;
+ struct ipr_cmnd *ipr_cmd = NULL;
+
+ if (likely(!list_empty(hrrq-hrrq_free_q))) {
+ ipr_cmd = list_entry(hrrq-hrrq_free_q.next,
+ struct ipr_cmnd, queue);
+ list_del(ipr_cmd-queue);
+ }
- ipr_cmd = list_entry(ioa_cfg-free_q.next, struct ipr_cmnd, queue);
- list_del(ipr_cmd-queue);
return ipr_cmd;
}
@@ -666,7 +676,8 @@ struct ipr_cmnd *__ipr_get_free_ipr_cmnd
static
struct ipr_cmnd *ipr_get_free_ipr_cmnd(struct ipr_ioa_cfg *ioa_cfg)
{
- struct ipr_cmnd *ipr_cmd = __ipr_get_free_ipr_cmnd(ioa_cfg);
+ struct ipr_cmnd *ipr_cmd =
+ __ipr_get_free_ipr_cmnd(ioa_cfg-hrrq[IPR_INIT_HRRQ]);
ipr_init_ipr_cmnd(ipr_cmd, ipr_lock_and_done);
return ipr_cmd;
}
@@ -761,13 +772,12 @@ static int ipr_set_pcix_cmd_reg(struct i
**/
static void ipr_sata_eh_done(struct ipr_cmnd *ipr_cmd)
{
- struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
struct ata_queued_cmd *qc = ipr_cmd-qc;
struct ipr_sata_port *sata_port = qc-ap-private_data;
qc-err_mask |= AC_ERR_OTHER;
sata_port-ioasa.status |= ATA_BUSY;
- list_add_tail(ipr_cmd-queue, ioa_cfg-free_q);
+ list_add_tail(ipr_cmd-queue, ipr_cmd-hrrq-hrrq_free_q);
ata_qc_complete(qc);
}
@@ -783,14 +793,13 @@ static void ipr_sata_eh_done(struct ipr_
**/
static void ipr_scsi_eh_done(struct ipr_cmnd *ipr_cmd)
{
- struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
struct scsi_cmnd *scsi_cmd = ipr_cmd-scsi_cmd;
scsi_cmd-result |= (DID_ERROR 16);
scsi_dma_unmap(ipr_cmd-scsi_cmd);
scsi_cmd-scsi_done(scsi_cmd);
- list_add_tail(ipr_cmd-queue, ioa_cfg-free_q);
+ list_add_tail(ipr_cmd-queue, ipr_cmd-hrrq-hrrq_free_q);
}
/**
@@ -805,24 +814,30 @@ static void ipr_scsi_eh_done(struct ipr_
static void ipr_fail_all_ops(struct ipr_ioa_cfg *ioa_cfg)
{
struct ipr_cmnd *ipr_cmd, *temp;
+ struct ipr_hrr_queue *hrrq;
ENTER;
- list_for_each_entry_safe(ipr_cmd, temp, ioa_cfg-pending_q, queue) {
- list_del(ipr_cmd-queue);
+ for_each_hrrq(hrrq, ioa_cfg) {
+ list_for_each_entry_safe(ipr_cmd,
+ temp, hrrq-hrrq_pending_q, queue) {
+ list_del(ipr_cmd-queue);
+
+ ipr_cmd-s.ioasa.hdr.ioasc =
+ cpu_to_be32(IPR_IOASC_IOA_WAS_RESET);
+ ipr_cmd-s.ioasa.hdr.ilid =
+ cpu_to_be32(IPR_DRIVER_ILID);
- ipr_cmd-s.ioasa.hdr.ioasc =
cpu_to_be32(IPR_IOASC_IOA_WAS_RESET);
-
[PATCH 6/7] ipr: Implement block iopoll
This patch implements blk iopoll in ipr driver for performance improvement.
Signed-off-by: Wen Xiong wenxi...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 218 +
drivers/scsi/ipr.h |6 +
2 files changed, 175 insertions(+), 49 deletions(-)
Index: b/drivers/scsi/ipr.c
===
--- a/drivers/scsi/ipr.c2012-11-18 22:35:29.254215152 -0600
+++ b/drivers/scsi/ipr.c2012-11-19 12:35:23.744213921 -0600
@@ -108,6 +108,7 @@ static const struct ipr_chip_cfg_t ipr_c
.max_cmds = 100,
.cache_line_size = 0x20,
.clear_isr = 1,
+ .iopoll_weight = 0,
{
.set_interrupt_mask_reg = 0x0022C,
.clr_interrupt_mask_reg = 0x00230,
@@ -132,6 +133,7 @@ static const struct ipr_chip_cfg_t ipr_c
.max_cmds = 100,
.cache_line_size = 0x20,
.clear_isr = 1,
+ .iopoll_weight = 0,
{
.set_interrupt_mask_reg = 0x00288,
.clr_interrupt_mask_reg = 0x0028C,
@@ -156,6 +158,7 @@ static const struct ipr_chip_cfg_t ipr_c
.max_cmds = 1000,
.cache_line_size = 0x20,
.clear_isr = 0,
+ .iopoll_weight = 64,
{
.set_interrupt_mask_reg = 0x00010,
.clr_interrupt_mask_reg = 0x00018,
@@ -3560,6 +3563,92 @@ static struct device_attribute ipr_ioa_r
.store = ipr_store_reset_adapter
};
+static int ipr_iopoll(struct blk_iopoll *iop, int budget);
+ /**
+ * ipr_show_iopoll_weight - Show ipr polling mode
+ * @dev: class device struct
+ * @buf: buffer
+ *
+ * Return value:
+ * number of bytes printed to buffer
+ **/
+static ssize_t ipr_show_iopoll_weight(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct Scsi_Host *shost = class_to_shost(dev);
+ struct ipr_ioa_cfg *ioa_cfg = (struct ipr_ioa_cfg *)shost-hostdata;
+ unsigned long lock_flags = 0;
+ int len;
+
+ spin_lock_irqsave(shost-host_lock, lock_flags);
+ len = snprintf(buf, PAGE_SIZE, %d\n, ioa_cfg-iopoll_weight);
+ spin_unlock_irqrestore(shost-host_lock, lock_flags);
+
+ return len;
+}
+
+/**
+ * ipr_store_iopoll_weight - Change the adapter's polling mode
+ * @dev: class device struct
+ * @buf: buffer
+ *
+ * Return value:
+ * number of bytes printed to buffer
+ **/
+static ssize_t ipr_store_iopoll_weight(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct Scsi_Host *shost = class_to_shost(dev);
+ struct ipr_ioa_cfg *ioa_cfg = (struct ipr_ioa_cfg *)shost-hostdata;
+ u32 user_iopoll_weight;
+ unsigned long lock_flags = 0;
+ int i;
+
+ if (!ioa_cfg-sis64) {
+ dev_info(ioa_cfg-pdev-dev, blk-iopoll not supported on this
adapter\n);
+ return -EINVAL;
+ }
+ user_iopoll_weight = simple_strtoul(buf, NULL, 10);
+ if (user_iopoll_weight 256) {
+ dev_info(ioa_cfg-pdev-dev, Invalid blk-iopoll weight. It
must be less than 256\n);
+ return -EINVAL;
+ }
+ if (user_iopoll_weight == ioa_cfg-iopoll_weight) {
+ dev_info(ioa_cfg-pdev-dev, Current blk-iopoll weight has
the same weight\n);
+ return strlen(buf);
+ }
+
+ if (blk_iopoll_enabled ioa_cfg-iopoll_weight
+ ioa_cfg-sis64 ioa_cfg-nvectors 1) {
+ for (i = 1; i ioa_cfg-hrrq_num; i++)
+ blk_iopoll_disable(ioa_cfg-hrrq[i].iopoll);
+ }
+
+ spin_lock_irqsave(shost-host_lock, lock_flags);
+ ioa_cfg-iopoll_weight = user_iopoll_weight;
+ if (blk_iopoll_enabled ioa_cfg-iopoll_weight
+ ioa_cfg-sis64 ioa_cfg-nvectors 1) {
+ for (i = 1; i ioa_cfg-hrrq_num; i++) {
+ blk_iopoll_init(ioa_cfg-hrrq[i].iopoll,
+ ioa_cfg-iopoll_weight, ipr_iopoll);
+ blk_iopoll_enable(ioa_cfg-hrrq[i].iopoll);
+ }
+ }
+ spin_unlock_irqrestore(shost-host_lock, lock_flags);
+
+ return strlen(buf);
+}
+
+static struct device_attribute ipr_iopoll_weight_attr = {
+ .attr = {
+ .name = iopoll_weight,
+ .mode = S_IRUGO | S_IWUSR,
+ },
+ .show = ipr_show_iopoll_weight,
+ .store = ipr_store_iopoll_weight
+};
+
/**
* ipr_alloc_ucode_buffer - Allocates a microcode download buffer
* @buf_len: buffer length
@@ -3928,6 +4017,7 @@ static struct device_attribute *ipr_ioa_
[PATCH 7/7] ipr: Driver version 2.6.0
Bump driver version. Signed-off-by: Wen Xiong wenxi...@linux.vnet.ibm.com --- drivers/scsi/ipr.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: b/drivers/scsi/ipr.h === --- a/drivers/scsi/ipr.h2012-11-19 12:18:58.263935158 -0600 +++ b/drivers/scsi/ipr.h2012-11-19 12:35:31.355166443 -0600 @@ -39,8 +39,8 @@ /* * Literals */ -#define IPR_DRIVER_VERSION 2.5.4 -#define IPR_DRIVER_DATE (July 11, 2012) +#define IPR_DRIVER_VERSION 2.6.0 +#define IPR_DRIVER_DATE (November 16, 2012) /* * IPR_MAX_CMD_PER_LUN: This defines the maximum number of outstanding -- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] ipr: Reduce lock contention
This patch reduces lock contention while implementing distributed
completion processing.
Signed-off-by: Wen Xiong wenxi...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 322 +
drivers/scsi/ipr.h | 21 +--
2 files changed, 239 insertions(+), 104 deletions(-)
Index: b/drivers/scsi/ipr.c
===
--- a/drivers/scsi/ipr.c2012-11-15 20:48:21.0 -0600
+++ b/drivers/scsi/ipr.c2012-11-18 22:35:29.254215152 -0600
@@ -552,7 +552,8 @@ static void ipr_trc_hook(struct ipr_cmnd
struct ipr_trace_entry *trace_entry;
struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
- trace_entry = ioa_cfg-trace[ioa_cfg-trace_index++];
+ trace_entry = ioa_cfg-trace[atomic_add_return
+ (1, ioa_cfg-trace_index)%IPR_NUM_TRACE_ENTRIES];
trace_entry-time = jiffies;
trace_entry-op_code = ipr_cmd-ioarcb.cmd_pkt.cdb[0];
trace_entry-type = type;
@@ -563,6 +564,7 @@ static void ipr_trc_hook(struct ipr_cmnd
trace_entry-cmd_index = ipr_cmd-cmd_index 0xff;
trace_entry-res_handle = ipr_cmd-ioarcb.res_handle;
trace_entry-u.add_data = add_data;
+ wmb();
}
#else
#define ipr_trc_hook(ipr_cmd, type, add_data) do { } while (0)
@@ -697,9 +699,15 @@ static void ipr_mask_and_clear_interrupt
u32 clr_ints)
{
volatile u32 int_reg;
+ int i;
/* Stop new interrupts */
- ioa_cfg-allow_interrupts = 0;
+ for (i = 0; i ioa_cfg-hrrq_num; i++) {
+ spin_lock(ioa_cfg-hrrq[i]._lock);
+ ioa_cfg-hrrq[i].allow_interrupts = 0;
+ spin_unlock(ioa_cfg-hrrq[i]._lock);
+ }
+ wmb();
/* Set interrupt mask to stop all new interrupts */
if (ioa_cfg-sis64)
@@ -818,6 +826,7 @@ static void ipr_fail_all_ops(struct ipr_
ENTER;
for_each_hrrq(hrrq, ioa_cfg) {
+ spin_lock(hrrq-_lock);
list_for_each_entry_safe(ipr_cmd,
temp, hrrq-hrrq_pending_q, queue) {
list_del(ipr_cmd-queue);
@@ -837,6 +846,7 @@ static void ipr_fail_all_ops(struct ipr_
del_timer(ipr_cmd-timer);
ipr_cmd-done(ipr_cmd);
}
+ spin_unlock(hrrq-_lock);
}
LEAVE;
}
@@ -991,12 +1001,9 @@ static void ipr_send_blocking_cmd(struct
static int ipr_get_hrrq_index(struct ipr_ioa_cfg *ioa_cfg)
{
if (ioa_cfg-hrrq_num == 1)
- ioa_cfg-hrrq_index = 0;
- else {
- if (++ioa_cfg-hrrq_index = ioa_cfg-hrrq_num)
- ioa_cfg-hrrq_index = 1;
- }
- return ioa_cfg-hrrq_index;
+ return 0;
+ else
+ return (atomic_add_return(1, ioa_cfg-hrrq_index) %
(ioa_cfg-hrrq_num - 1)) + 1;
}
/**
@@ -1018,7 +1025,7 @@ static void ipr_send_hcam(struct ipr_ioa
struct ipr_cmnd *ipr_cmd;
struct ipr_ioarcb *ioarcb;
- if (ioa_cfg-allow_cmds) {
+ if (ioa_cfg-hrrq[IPR_INIT_HRRQ].allow_cmds) {
ipr_cmd = ipr_get_free_ipr_cmnd(ioa_cfg);
list_add_tail(ipr_cmd-queue, ipr_cmd-hrrq-hrrq_pending_q);
list_add_tail(hostrcb-queue, ioa_cfg-hostrcb_pending_q);
@@ -2564,7 +2571,7 @@ static int ipr_reset_reload(struct ipr_i
/* If we got hit with a host reset while we were already resetting
the adapter for some reason, and the reset failed. */
- if (ioa_cfg-ioa_is_dead) {
+ if (ioa_cfg-hrrq[IPR_INIT_HRRQ].ioa_is_dead) {
ipr_trace;
return FAILED;
}
@@ -3205,7 +3212,8 @@ static void ipr_worker_thread(struct wor
restart:
do {
did_work = 0;
- if (!ioa_cfg-allow_cmds || !ioa_cfg-allow_ml_add_del) {
+ if (!ioa_cfg-hrrq[IPR_INIT_HRRQ].allow_cmds ||
+ !ioa_cfg-allow_ml_add_del) {
spin_unlock_irqrestore(ioa_cfg-host-host_lock,
lock_flags);
return;
}
@@ -3453,7 +3461,7 @@ static ssize_t ipr_show_adapter_state(st
int len;
spin_lock_irqsave(ioa_cfg-host-host_lock, lock_flags);
- if (ioa_cfg-ioa_is_dead)
+ if (ioa_cfg-hrrq[IPR_INIT_HRRQ].ioa_is_dead)
len = snprintf(buf, PAGE_SIZE, offline\n);
else
len = snprintf(buf, PAGE_SIZE, online\n);
@@ -3479,14 +3487,20 @@ static ssize_t ipr_store_adapter_state(s
struct Scsi_Host *shost = class_to_shost(dev);
struct ipr_ioa_cfg *ioa_cfg = (struct ipr_ioa_cfg *)shost-hostdata;
unsigned long lock_flags;
- int result = count;
+ int result = count, i;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
spin_lock_irqsave(ioa_cfg-host-host_lock, lock_flags);
Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
On Mon, 26 Nov 2012, James Bottomley wrote: I'm also curious about driving sleep from autopm, since mode page timers don't control the sleep transition. Is it feasible to do this the other way around? That is, to drive runtime suspend by noticing when the device decides to put itself into a low-power state? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Change type-2 dif to use rq embedded 32 byte cdb
cc Lukasz and Maciej from Intel and changing Dan William's email On 11/21/2012 03:07 PM, Rob Evers wrote: These patches replace the original t10 type 2 dif mempool implementation by increasing the block and scsi cdb maximum sizes from 16 to 32 bytes. The cdb embedded in the request structure can then be used for type 2 dif commands, or other 32 byte cdbs as required. Motivation for this is that type-2 dif commands should be treated as any other read/writes generally, without any performance penalty. This patch set conflicts with a patch previously posted which addresses a race in UA induced retries with type 2 dif commands. These patches also address that problem: http://marc.info/?l=linux-scsim=135186352200668w=2 Testing: Readily reproduced the race condition panic by simultaneously inducing UAs while load testing 8 scsi_debug devices. With patch applied, same testing ran for 15 hours without a panic. Sanity tested performance using scsi_debug, with and without type 2 dif enabled. Order 80% performance increase noticed with patches when scsi_debug was running in dif type 2 mode. Running scsi_debug without type 2 dif, performance was approximately equal. Used 3.7.0-rc5 for testing and patch generation. root (2): Change the cdb size limits in block and scsi to 32 bytes Change dif type 2 commands to use embedded 32 byte cdb drivers/scsi/sd.c| 45 + drivers/scsi/sd.h| 5 - include/linux/blkdev.h | 2 +- include/scsi/scsi_cmnd.h | 13 ++--- 4 files changed, 4 insertions(+), 61 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7 v5] More device removal fixes
On 11/23/12 11:37, Bart Van Assche wrote:
On 10/26/12 14:00, Bart Van Assche wrote:
Fix a few race conditions that can be triggered by removing a device:
[ ... ]
I'd like to add the patch below to this series. [ ... ]
Below is another patch (hopefully the last) that I'd like to add to
this series. Note: the reason that I only ran into this issue now is
because I only started testing very recently with an ib_srp version
with the host state check removed from srp_queuecommand().
[PATCH] Make scsi_remove_host() wait for device removal
SCSI LLDs may start cleaning up host resources needed by their
queuecommand() callback as soon as scsi_remove_host() finished.
Hence scsi_remove_host() must wait until blk_cleanup_queue() for
all devices associated with the host has finished.
This patch fixes the following kernel oops:
BUG: spinlock bad magic on CPU#0, multipathd/20128
lock: 0x8801b32e8bc8, .magic: 8801, .owner: none/-1, .owner_cpu:
-1556759232
Pid: 20128, comm: multipathd Not tainted 3.7.0-rc7-debug+ #1
Call Trace:
[8141206f] spin_dump+0x8c/0x91
[81412095] spin_bug+0x21/0x26
[81218a6f] do_raw_spin_lock+0x13f/0x150
[81417b38] _raw_spin_lock_irqsave+0x78/0xa0
[a0293c6c] srp_queuecommand+0x3c/0xc80 [ib_srp]
[a0002f18] scsi_dispatch_cmd+0x148/0x310 [scsi_mod]
[a000a080] scsi_request_fn+0x320/0x520 [scsi_mod]
[811ec397] __blk_run_queue+0x37/0x50
[811ec3ee] queue_unplugged+0x3e/0xd0
[811eef33] blk_flush_plug_list+0x1c3/0x240
[811eefc8] blk_finish_plug+0x18/0x50
[8119661e] do_io_submit+0x29e/0xa00
[81196d90] sys_io_submit+0x10/0x20
[81420d82] system_call_fastpath+0x16/0x1b
---
drivers/scsi/hosts.c | 16
drivers/scsi/scsi_priv.h |2 +-
drivers/scsi/scsi_scan.c |5 -
drivers/scsi/scsi_sysfs.c | 15 ---
include/scsi/scsi_host.h |1 +
5 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 593085a..7b6b0b2 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -150,6 +150,19 @@ int scsi_host_set_state(struct Scsi_Host *shost, enum
scsi_host_state state)
}
EXPORT_SYMBOL(scsi_host_set_state);
+static bool scsi_device_list_empty(struct Scsi_Host *shost)
+{
+ bool res;
+
+ WARN_ON_ONCE(irqs_disabled());
+
+ spin_lock_irq(shost-host_lock);
+ res = list_empty(shost-__devices);
+ spin_unlock_irq(shost-host_lock);
+
+ return res;
+}
+
/**
* scsi_remove_host - remove a scsi host
* @shost: a pointer to a scsi host to remove
@@ -178,6 +191,8 @@ void scsi_remove_host(struct Scsi_Host *shost)
BUG_ON(scsi_host_set_state(shost, SHOST_DEL_RECOVERY));
spin_unlock_irqrestore(shost-host_lock, flags);
+ wait_event(shost-device_list_empty, scsi_device_list_empty(shost));
+
transport_unregister_device(shost-shost_gendev);
device_unregister(shost-shost_dev);
device_del(shost-shost_gendev);
@@ -351,6 +366,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template
*sht, int privsize)
shost-shost_state = SHOST_CREATED;
INIT_LIST_HEAD(shost-__devices);
INIT_LIST_HEAD(shost-__targets);
+ init_waitqueue_head(shost-device_list_empty);
INIT_LIST_HEAD(shost-eh_cmd_q);
INIT_LIST_HEAD(shost-starved_list);
init_waitqueue_head(shost-host_wait);
diff --git a/drivers/scsi/scsi_priv.h b/drivers/scsi/scsi_priv.h
index 8f9a0ca..86250fb 100644
--- a/drivers/scsi/scsi_priv.h
+++ b/drivers/scsi/scsi_priv.h
@@ -130,7 +130,7 @@ extern int scsi_sysfs_add_sdev(struct scsi_device *);
extern int scsi_sysfs_add_host(struct Scsi_Host *);
extern int scsi_sysfs_register(void);
extern void scsi_sysfs_unregister(void);
-extern void scsi_sysfs_device_initialize(struct scsi_device *);
+extern int scsi_sysfs_device_initialize(struct scsi_device *);
extern int scsi_sysfs_target_initialize(struct scsi_device *);
extern struct scsi_transport_template blank_transport_template;
extern void __scsi_remove_device(struct scsi_device *);
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 3e58b22..ddea318 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -289,7 +289,10 @@ static struct scsi_device *scsi_alloc_sdev(struct
scsi_target *starget,
sdev-request_queue-queuedata = sdev;
scsi_adjust_queue_depth(sdev, 0, sdev-host-cmd_per_lun);
- scsi_sysfs_device_initialize(sdev);
+ if (scsi_sysfs_device_initialize(sdev)) {
+ display_failure_msg = 0;
+ goto out_device_destroy;
+ }
if (shost-hostt-slave_alloc) {
ret = shost-hostt-slave_alloc(sdev);
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 2661a957..760fc85 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -348,6 +348,8 @@
Re: SCSI LLDs, the SCSI error handler and host resource lifetime
On 11/21/12 08:19, Hannes Reinecke wrote:
Hmm.
This would still mean that the eh thread will run until finished.
Which can take _A LOT_ of time (we're speaking hours here).
I would rather have an additional return code in the various
scsi_try_XXX functions to terminate the loop quickly.
Hello Hannes,
Since I'm not sure that I understood you properly: is something like
the patch below what you had in mind ?
Thanks,
Bart.
[PATCH] Skip invoking error handler once device removal started
---
drivers/scsi/scsi_error.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c1b05a8..697f7f2 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -582,7 +582,8 @@ static int scsi_try_bus_reset(struct scsi_cmnd *scmd)
if (!hostt-eh_bus_reset_handler)
return FAILED;
- rtn = hostt-eh_bus_reset_handler(scmd);
+ rtn = scsi_host_scan_allowed(host) ?
+ hostt-eh_bus_reset_handler(scmd) : FAST_IO_FAIL;
if (rtn == SUCCESS) {
if (!hostt-skip_settle_delay)
@@ -621,7 +622,8 @@ static int scsi_try_target_reset(struct scsi_cmnd *scmd)
if (!hostt-eh_target_reset_handler)
return FAILED;
- rtn = hostt-eh_target_reset_handler(scmd);
+ rtn = scsi_host_scan_allowed(host) ?
+ hostt-eh_target_reset_handler(scmd) : FAST_IO_FAIL;
if (rtn == SUCCESS) {
spin_lock_irqsave(host-host_lock, flags);
__starget_for_each_device(scsi_target(scmd-device), NULL,
@@ -645,12 +647,14 @@ static int scsi_try_target_reset(struct scsi_cmnd *scmd)
static int scsi_try_bus_device_reset(struct scsi_cmnd *scmd)
{
int rtn;
- struct scsi_host_template *hostt = scmd-device-host-hostt;
+ struct Scsi_Host *host = scmd-device-host;
+ struct scsi_host_template *hostt = host-hostt;
if (!hostt-eh_device_reset_handler)
return FAILED;
- rtn = hostt-eh_device_reset_handler(scmd);
+ rtn = scsi_host_scan_allowed(host) ?
+ hostt-eh_device_reset_handler(scmd) : FAST_IO_FAIL;
if (rtn == SUCCESS)
__scsi_report_device_reset(scmd-device, NULL);
return rtn;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pv-drivers] [PATCH 097/493] scsi: remove use of __devexit_p
On Mon, Nov 19, 2012 at 01:20:46PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. ... drivers/scsi/vmw_pvscsi.c | 2 +- For vmw_pvscsi: Acked-by: Dmitry Torokhov d...@vmware.com Thanks, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] First pass at merging Bart's HA work
This series compiles, but is otherwise UNTESTED. I'll be working on that over the next few days, with an eye on getting as much of Bart's work into 3.8 as possible. Hi Dave, Great to have you back. Certainly I'd like to get this stuff into 3.8 too. A couple of comments: - I think the srp_transport stuff should go through linux-scsi / James B. instead of my tree, esp. since it's shared with the IBM vscsi stuff (I think) - I see Bart had a few comments about a few of your patches, I'll wait for you guys to hash that out. Otherwise definitely happy to merge this for 3.8! Thanks, Roland -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] UAPI: (Scripted) Disintegrate include/rdma
Thanks, applied. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] IB/srp: destroy and recreate QP and CQs on each connection
On 11/26/12 05:44, David Dillow wrote: From: Ishai Rabinovitz is...@mellanox.co.il HW QP FATAL errors persist over a reset operation, but we can recover from that by recreating the QP and associated CQs for each connection. Creating a new QP/CQ also completely forecloses any possibility of getting stale completions or packets on the new connection. [ ... ] This looks like a more elegant way than what I had came up with (Make srp_disconnect_target() wait for IB completions) so I'm fine with this patch, and with the next one too. Bart. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] First pass at merging Bart's HA work
On Mon, 2012-11-26 at 10:50 -0800, Roland Dreier wrote: - I think the srp_transport stuff should go through linux-scsi / James B. instead of my tree, esp. since it's shared with the IBM vscsi stuff (I think) - I see Bart had a few comments about a few of your patches, I'll wait for you guys to hash that out. I'm amenable to that, but we do need an agreed patch set, as Roland says. I also hate to apply the pressure, but I suspect -rc7 was the last -rc, so I'm expecting the merge window to open on 2/12. James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
On Mon, 2012-11-26 at 11:21 -0500, Alan Stern wrote: On Mon, 26 Nov 2012, James Bottomley wrote: I'm also curious about driving sleep from autopm, since mode page timers don't control the sleep transition. Is it feasible to do this the other way around? That is, to drive runtime suspend by noticing when the device decides to put itself into a low-power state? Well, yes and no. The spec is annoyingly (and deliberately) vague about what the states actually mean. The two states that the devices go into because of timers is idle and standby. The supposedly deeper low power state of sleep can only be reached by sending a command to the device. The design is that software (or HBA drivers) don't really need to notice idle and standby; the device automatically manages transitions between them depending on command activity. For sleep, we do have to care (if it actually makes some meaningful difference). James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] First pass at merging Bart's HA work
I'm amenable to that, but we do need an agreed patch set, as Roland says. I also hate to apply the pressure, but I suspect -rc7 was the last -rc, so I'm expecting the merge window to open on 2/12. I think the srp_transport bits are all simple and non-controversial. So at least from my perspective, OK to merge right now, except that Dave mentioned he screwed up the attribution on one email, but that should be easy to fix with a quick resend. - R. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error handling on FC devices
On 11/19/2012 7:41 AM, Hannes Reinecke wrote: Hi all, just when we thought we'd finally nailed the error handling on FC ... A customer of ours recently hit this really nasty issue: He had a 'drain' on the SAN, in the sense that the link was still intact, but no commands were coming back from the link. This caused the FC HBA / driver to not detect a link down, and so the failing command was pushed onto the error handler. Which of course resorted back to HBA reset, but by that time the cluster already had kicked out the machine. And as all machines in the cluster were connected to the same switch this happened to all machines, resulting on a nice cluster shutdown. And a really unhappy customer. Looking closer multipathing actually managed to detect and switch paths as desired, but as the initial failing command was pushed onto the error handler all applications had to wait for this command to finish before proceeding. So the following questions: - Why did the FC HBA not detect a 'link-down' scenario? (Incidentally, this happens with QLogic _and_ Emulex :-) I know this is not a typical link-down, but from my naive assumption the HBA should detect that commands are not making progress, and at least after RA TOV was expired it should try to reset the link. Link up/down is almost always the state of the physical link - TX signal is active, and on RX side, we have negotiated speed and acquired sync, and are seeing valid characters. It has nothing to do with the packet transmission on the link which is a different story. There is, within the FC std, tracking of credits vs the link, which could reset it (although, it's reset, and yours may be a different definition). So as long as the other end kept it's link up, and we saw valid characters - the link is fine. From the SCSI perspective - there are no requirements about how long a command takes (consider format commands - which could take hours between the cmd and the response). There is no definition about making progress that can be enforced. We have the i/o timers - which usually have defaults of 30s/60s/90s by default. R_A_TOV (10s) is too short vs these - especially when considering some transparent failover arrays (2 pieces of hardware, both on the link, but only 1 responding - and after one fails, the other takes over the others personality, taking about 90s to do so, and resuming the i/os from the new hardware; during this entire time there may be no traffic, for much of this window and it's still good). Additionally, there is no requirement that all targets be in use at all times - you could come up with a situation where 1 target is influencing the link activity decision, thus invoking the link bounce, and disrupting i/o load on other targets that are fine. Low probability, but possible. In general, lack of activity is a good indicator, but that's it, only an indicator. Not great for a hard policy choice. Also, you're asking low-level designs to now do something new (time inter-i/o gaps, and aggregate gaps), which they may not be prepared to do so. - Can we speed up error handling for these cases? Currently we're waiting for eh to complete before returning the affected commands with a final state. However, after we've done a LUN reset there shouldn't be any command state left and we should be able to terminate outstanding commands directly, without having to wait for eh to finally complete. James? Theoretically, I agree - the affected command only has to stall long enough to ensure its own cancellation, which could be just the io abort. True, if the abort is not successful, then you still don't know the status, so you have to escalate the type of recovery to try to cancel, etc. I expect, given the limbo state of the i/o on lower eh failures, you do have to wait to ensure it's cancelled, at least from a generic scsi point of view. You could try to optimize the local system view - where as long as the LLDD ensures it's cancelled, and will protocol-wise ensure no bad side effects, then you could release it earlier in the eh escalation. I don't believe we have a way for the LLDD to give such a notice to the midlayer. Given all the grey areas you touch on, especially across different types of scsi protocols and hardware, it doesn't surprise me we are waiting until we have confirmation of cancellation before continuing. Given path switching is somewhat separate from the i/o, would it better to send a notification of a path-fail condition as part of the eh, rather than hinging it on the individual i/o. Yes, the i/o is still in limbo and can't be switched to the new path, but other i/o could without incurring the delay. -- james s Thanks. Cheers, Hannes -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES
Stefan == Stefan Richter stef...@s5r6.in-berlin.de writes: Stefan, Stefan I did not try sg_write_same on any of the devices; but since Stefan the two SPC-3 devices are correctly identified as fully Stefan provisioned, won't issue WRITE SAME to them either. What if you have an SSD behind one of them? Stefan Hence let's remove the no_report_opcodes and no_write_same Stefan blacklist flags so that these commands can be used on Stefan respectively capable targets. I just erred on the side of caution. If you are happy without belt and suspenders that's perfectly ok with me :) -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Change type-2 dif to use rq embedded 32 byte cdb
Rob == Rob Evers rev...@redhat.com writes: Rob These patches replace the original t10 type 2 dif mempool Rob implementation by increasing the block and scsi cdb maximum sizes Rob from 16 to 32 bytes. The cdb embedded in the request structure can Rob then be used for type 2 dif commands, or other 32 byte cdbs as Rob required. Rob Motivation for this is that type-2 dif commands should be treated Rob as any other read/writes generally, without any performance Rob penalty. We did the mempool because we did not want to penalize everybody else by always allocating 32-byte CDBs. Type 2 is a really rare corner case. So while I agree we should handle the UA scenario correctly, I'm not sure I agree with the fix. Why are you messing with Type 2 devices in the first place? These should really only be used inside disk arrays. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
On 11/26/2012 09:17 PM, James Bottomley wrote: On Mon, 2012-11-26 at 16:27 +0800, Aaron Lu wrote: Well, ZPREADY is not a power state that we can program the ODD to enter(figure 234 and table 323 of the SPEC), it servers more like an information provided by ODD to host so that host does not need to do TUR and then examine the sense code to decide if zero power ready status is satisfied but simply query ODD if its current power state is ZPREADY. So it's not that we program the device to go into ZPREADY power state and the ODD's power will be omitted. The benefit of a ZPREADY capable ODD is that, when we need to decide if the ODD is in a zero power ready status, we can simply query the ODD by issuing a GET_EVENT_STATUS_NOTIFICATION and check the returned power class events, if it is in ZPREADY power state, then we can omit the power. To support ZPREADY, we just need some change to the zpready funtion, which currently uses sense code to check ZP ready status. So this is my understanding of ZPREADY, and I don't see it as a total different thing with ZPODD, it just changes the way how host senses the zero power ready status. But if I was wrong, please kindly let me know, thanks. My understanding is that a ZPREADY device may be capable of internal power down, meaning it doesn't necessarily need the host to omit the power. It depends what the difference is between Sleep and Off is (they're deliberately left as implementation defined in the standard, Ch 16, but the conditions of sleep are pretty onerous, so it sounds like most of the mechanics are powered down). I Agree that when the ODD is put to Sleep state, it may power down most of the mechanics, good for power saving. The problem is, we have the 2 seconds poll, and since Sleep state can not process any command, we will need to bring the ODD out of Sleep state every 2 seconds, is this feasible? Please note that leaving Sleep state needs full initialization of the ODD. ZPODD system(ODD+platform) solves this problem with ACPI, when the ODD is powered off and any event that may induce a media change event will generate an ACPI interrupt, so we can stop the poll(though in whatever way is still in discussion). So I suppose we need to find a proper way to implement Sleep. However, if you want to work it similarly to ZPODD, then the timeouts automatically transitions to ZPREADY, the device issues an event, we trap the event at the low level and omit power. Yeah, I can do this. Except that I don't quite understand how the device issues the event to host, by interrupt? My understanding is that, it will issue this event to itself...and host still needs to use command GET_EVENT_STATUS_NOTIFICATION to fetch the event, much the same way like the media related events it emits. I'm also curious about driving sleep from autopm, since mode page timers don't control the sleep transition. I see. But we will need to work out a sensible way to put the ODD into that power state, if at all possible. Thanks, Aaron -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] IB/srp: keep processing commands during host removal
On Mon, 2012-11-26 at 10:43 +0100, Bart Van Assche wrote: On 11/26/12 05:44, David Dillow wrote: From: Bart Van Assche bvanass...@acm.org Some SCSI upper layer drivers, e.g. sd, issue SCSI commands from inside scsi_remove_host() (see also the sd_shutdown() call in sd_remove()). Make sure that these commands have a chance to reach the SCSI device. Hi Dave, After I posted the patch on which the above patch has been based I realized that it can be simplified. Since the patch called Eliminate state SRP_TARGET_CONNECTING blocks the SCSI host as long as the RDMA RC connection is being reconnected srp_queuecommand() won't be invoked during the disconnected or error state. How about adding the patch below just after the patch that eliminates the state SRP_TARGET_CONNECTING ? Right, I left off out the part of that patch that blocks the target as I wanted to think about its implications a bit more. I think it is probably the right thing to do, and will likely add that functionality back. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] IB/srp: don't send anything on a bad QP
On Mon, 2012-11-26 at 10:17 +0100, Bart Van Assche wrote: On 11/26/12 05:44, David Dillow wrote: Once we know we have an issue with the QP, there is no point trying to send anything else down the pipe. This also allows us to consolidate code in the SCSI EH path. After I posted the patch on which the above patch has been based I realized that testing the connection state at the start of srp_send_tsk_mgmt() is not sufficient to avoid QPN use-after-free. If a DREQ is received by the initiator after the above test has been performed and before the task management function has been sent it is still possible to send a task management function over a closed QP. AFIACT, DREQ does not actually close the QP -- it only tells us that the other side would like to. We don't actually close the connection until we try to send on it again, I think -- not sure if we see recv failures for the queued work items. Regardless, the issue of resource lifetime is an issue that needs solving. I'd like to address this in a different way - see also the thread called SCSI LLDs, the SCSI error handler and host resource lifetime on the linux-scsi mailing list (November 20, http://marc.info/?t=13534215553r=1). I like the direction you propose there. It seems that scsi_remove_host() at one point waited for the EH thread to exit -- or perhaps it was part of scsi_host_put() chain -- as there's the longstanding deferral to the work queue for the SRP target removal. Of course, that's been there for ~5 years now, and things have changed in the SCSI stack. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] IB/srp: simplify state tracking
On Mon, 2012-11-26 at 10:46 +0100, Bart Van Assche wrote: On 11/26/12 05:44, David Dillow wrote: The state of the target has several conditions that overlap, making it easier to model as a bit-field of exceptional conditions rather than an enum of all possible states. Bart Van Assche did the hard work of identifying the states that can be removed, and did a first patch that consolidated the state space. [ ... ] Hi Dave, Could you please explain why you would prefer to use test_bit () / test_and_set_bit() and clear_bit() for managing the SRP target state ? As far as I can see the target state is not changed in any code path where it matters how fast the state is changed. Maybe I'm missing something ? I don't think you are missing anything; if anything, I probably am. I still believe that there is a possibility of overlapping states, and some of the changes you had introduced had us checking multiple state variables to see if we could perform an action. Moving to bit flags cleaned that up, at least in my head. Your more recent series does not need to check multiple variables given the target block, and while resource lifetimes confuse the various states, I may be inclined to go back to your set. It's had more testing, for sure. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] First pass at merging Bart's HA work
On Mon, 2012-11-26 at 23:15 +0400, James Bottomley wrote: On Mon, 2012-11-26 at 10:50 -0800, Roland Dreier wrote: - I think the srp_transport stuff should go through linux-scsi / James B. instead of my tree, esp. since it's shared with the IBM vscsi stuff (I think) - I see Bart had a few comments about a few of your patches, I'll wait for you guys to hash that out. I'm amenable to that, but we do need an agreed patch set, as Roland says. I also hate to apply the pressure, but I suspect -rc7 was the last -rc, so I'm expecting the merge window to open on 2/12. We can push it through James's tree if need be, but Bart's code is pretty self-contained, and going through the SCSI tree will introduce merge dependencies. It'd be much easier to push it all through the RDMA tree, especially if we want to get this landed for 3.8. I'd want Fujita Tomonori, Robert Jennings, and James to ack the changes the SRP transport code, though they've been pending for a long time w/o comment so perhaps silence is consent? -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] First pass at merging Bart's HA work
On 27/11/2012 06:04, David Dillow wrote: We can push it through James's tree if need be, but Bart's code is pretty self-contained, and going through the SCSI tree will introduce merge dependencies. It'd be much easier to push it all through the RDMA tree Yep, this makes sense to me even without taking into account the time left for the merge window to open, the patches have been around for long time and relate directly to the SRP code in the IB subsystem, there's no point in introducing merge dependencies where it can be avoided. Or. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] csiostor: Fix sparse warnings.
Hi James,
Could you please let me know when this patch would be pushed?
Thanks,
Naresh.
On 11/20/2012 6:15 PM, Naresh Kumar Inna wrote:
This patch fixes sparse warnings related to endian-ness, which were
reported by the 0-day kernel build and testing tool.
Signed-off-by: Naresh Kumar Inna nar...@chelsio.com
---
drivers/scsi/csiostor/csio_attr.c | 34 ++--
drivers/scsi/csiostor/csio_hw.c | 14 +++---
drivers/scsi/csiostor/csio_hw.h |6 +--
drivers/scsi/csiostor/csio_lnode.c| 91
+
drivers/scsi/csiostor/csio_mb.c | 62 ---
drivers/scsi/csiostor/csio_rnode.c| 11 ++--
drivers/scsi/csiostor/csio_scsi.c |8 ++--
drivers/scsi/csiostor/t4fw_api_stor.h | 12 ++--
8 files changed, 110 insertions(+), 128 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_attr.c
b/drivers/scsi/csiostor/csio_attr.c
index c8cf857..065a87a 100644
--- a/drivers/scsi/csiostor/csio_attr.c
+++ b/drivers/scsi/csiostor/csio_attr.c
@@ -89,7 +89,7 @@ csio_reg_rnode(struct csio_rnode *rn)
spin_unlock_irq(shost-host_lock);
sp = rn-rn_sparm;
- rport-maxframe_size= sp-csp.sp_bb_data;
+ rport-maxframe_size = ntohs(sp-csp.sp_bb_data);
if (ntohs(sp-clsp[2].cp_class) FC_CPC_VALID)
rport-supported_classes = FC_COS_CLASS3;
else
@@ -192,7 +192,7 @@ csio_fchost_attr_init(struct csio_lnode *ln)
fc_host_supported_speeds(shost) = FC_PORTSPEED_10GBIT |
FC_PORTSPEED_1GBIT;
- fc_host_maxframe_size(shost) = ln-ln_sparm.csp.sp_bb_data;
+ fc_host_maxframe_size(shost) = ntohs(ln-ln_sparm.csp.sp_bb_data);
memset(fc_host_supported_fc4s(shost), 0,
sizeof(fc_host_supported_fc4s(shost)));
fc_host_supported_fc4s(shost)[7] = 1;
@@ -325,23 +325,23 @@ csio_get_stats(struct Scsi_Host *shost)
memset(fcoe_port_stats, 0, sizeof(struct fw_fcoe_port_stats));
csio_get_phy_port_stats(hw, ln-portid, fcoe_port_stats);
- fhs-tx_frames += (fcoe_port_stats.tx_bcast_frames +
- fcoe_port_stats.tx_mcast_frames +
- fcoe_port_stats.tx_ucast_frames +
- fcoe_port_stats.tx_offload_frames);
- fhs-tx_words += (fcoe_port_stats.tx_bcast_bytes +
-fcoe_port_stats.tx_mcast_bytes +
-fcoe_port_stats.tx_ucast_bytes +
-fcoe_port_stats.tx_offload_bytes) /
+ fhs-tx_frames += (be64_to_cpu(fcoe_port_stats.tx_bcast_frames) +
+ be64_to_cpu(fcoe_port_stats.tx_mcast_frames) +
+ be64_to_cpu(fcoe_port_stats.tx_ucast_frames) +
+ be64_to_cpu(fcoe_port_stats.tx_offload_frames));
+ fhs-tx_words += (be64_to_cpu(fcoe_port_stats.tx_bcast_bytes) +
+be64_to_cpu(fcoe_port_stats.tx_mcast_bytes) +
+be64_to_cpu(fcoe_port_stats.tx_ucast_bytes) +
+be64_to_cpu(fcoe_port_stats.tx_offload_bytes)) /
CSIO_WORD_TO_BYTE;
- fhs-rx_frames += (fcoe_port_stats.rx_bcast_frames +
- fcoe_port_stats.rx_mcast_frames +
- fcoe_port_stats.rx_ucast_frames);
- fhs-rx_words += (fcoe_port_stats.rx_bcast_bytes +
- fcoe_port_stats.rx_mcast_bytes +
- fcoe_port_stats.rx_ucast_bytes) /
+ fhs-rx_frames += (be64_to_cpu(fcoe_port_stats.rx_bcast_frames) +
+be64_to_cpu(fcoe_port_stats.rx_mcast_frames) +
+be64_to_cpu(fcoe_port_stats.rx_ucast_frames));
+ fhs-rx_words += (be64_to_cpu(fcoe_port_stats.rx_bcast_bytes) +
+ be64_to_cpu(fcoe_port_stats.rx_mcast_bytes) +
+ be64_to_cpu(fcoe_port_stats.rx_ucast_bytes)) /
CSIO_WORD_TO_BYTE;
- fhs-error_frames += fcoe_port_stats.rx_err_frames;
+ fhs-error_frames += be64_to_cpu(fcoe_port_stats.rx_err_frames);
fhs-fcp_input_requests += ln-stats.n_input_requests;
fhs-fcp_output_requests += ln-stats.n_output_requests;
fhs-fcp_control_requests += ln-stats.n_control_requests;
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index 963c6c1..8ecdb94 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -169,7 +169,7 @@ csio_set_reg_field(struct csio_hw *hw, uint32_t reg,
uint32_t mask,
* is assigned the 64-bit ECC word for the read data.
*/
int
-csio_hw_mc_read(struct csio_hw *hw, uint32_t addr, uint32_t *data,
+csio_hw_mc_read(struct csio_hw *hw, uint32_t addr, __be32 *data,
uint64_t *ecc)
{
int i;
@@ -209,7 +209,7 @@
