mvumi driver
I have a two Marvel Sata Marvell 88NV9143 controller disks on the board. When I tried to load mvumi module I'm getting an invalid signature error. Further debugging I found any read on memory mapped IO returns 0x (-1). And also the PCI bar address is 64bit where as device is 32-bit [CPU] - [IDT PCI-E Interconnet Switch] - [MVUMI controller, SATA1 SATA2] mvumi :03:00.1: invalid signature [0x]. mvumi: probe of :03:00.1 failed with error -22 Kernel : 2.6.34.12 Longterm Arch : mips/octeon 03:00.1 Mass storage controller: Device 1b4b:9143 (rev 11) Subsystem: Device 1b4b:9143 Flags: bus master, fast devsel, latency 0, IRQ 129 Memory at 11c011200 (32-bit, prefetchable) [size=1M] [virtual] Expansion ROM at 11c011211 [disabled] [size=64K] Capabilities: [50] Power Management version 3 cat /proc/iomem 11c011200-11c01120f : mvumi Thanks in advance -- 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
[SCSI] lpfc: Don't force CONFIG_GENERIC_CSUM on
Hi Randy, I reported: on i386: # CONFIG_CRC_T10DIF is not set drivers/built-in.o: In function `lpfc_bg_crc': (.text+0x3cb3c9): undefined reference to `crc_t10dif' and then James Bottomley provided the patch. I don't know why he added GENERIC_CSUM to it. Thanks for investigating this. How does this patch look? Anton -- [SCSI] lpfc: Don't force CONFIG_GENERIC_CSUM on We want ppc64 to be able to select between optimised assembly checksum routines in big endian and the generic lib/checksum.c routines in little endian. The lpfc driver is forcing CONFIG_GENERIC_CSUM on which means we are unable to make the decision to enable it in the arch Kconfig. If the option exists it is always forced on. This got introduced in 3.10 via commit 6a7252fdb0c3 ([SCSI] lpfc: fix up Kconfig dependencies). I spoke to Randy about it and the original issue was with CRC_T10DIF not being defined. As such, remove the select of CONFIG_GENERIC_CSUM. Signed-off-by: Anton Blanchard an...@samba.org Cc: sta...@vger.kernel.org # 3.10 --- diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 48b2918..92ff027 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -1353,7 +1353,6 @@ config SCSI_LPFC tristate Emulex LightPulse Fibre Channel Support depends on PCI SCSI select SCSI_FC_ATTRS - select GENERIC_CSUM select CRC_T10DIF help This lpfc driver supports the Emulex LightPulse -- 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] IB/iser: Add Discovery support
To run discovery over iSER we need to advertize the CAP_TEXT_NEGO capability
towards user space. Also need to make sure the login RX buffer is posted when
SendTargets TEXT PDUs are sent. For that end, we use a setting of the
ISCSI_PARAM_DISCOVERY_SESS iscsi param as an indication that this is
discovery session.
Signed-off-by: Or Gerlitz ogerl...@mellanox.com
---
Hi James,
I submit this patch through your tree since it depends on the below iscsi
patches (which are acknowledged by Mike) who are targted to 3.12
Or.
[PATCH V2 1/4] scsi_transport_iscsi: Exporting new attrs for iscsi session and
connection in sysfs
http://marc.info/?l=linux-scsim=137267405429329w=2
[PATCH V2 2/4] libiscsi: Exporting new attrs for iscsi session and connection
in sysfs
http://marc.info/?l=linux-scsim=137267405529330w=2
drivers/infiniband/ulp/iser/iscsi_iser.c |3 ++-
drivers/infiniband/ulp/iser/iser_initiator.c | 11 ++-
drivers/scsi/libiscsi.c |5 +
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 2e84ef8..1ec78bd 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -672,6 +672,7 @@ static umode_t iser_attr_is_visible(int param_type, int
param)
case ISCSI_PARAM_TGT_RESET_TMO:
case ISCSI_PARAM_IFACE_NAME:
case ISCSI_PARAM_INITIATOR_NAME:
+ case ISCSI_PARAM_DISCOVERY_SESS:
return S_IRUGO;
default:
return 0;
@@ -701,7 +702,7 @@ static struct scsi_host_template iscsi_iser_sht = {
static struct iscsi_transport iscsi_iser_transport = {
.owner = THIS_MODULE,
.name = iser,
- .caps = CAP_RECOVERY_L0 | CAP_MULTI_R2T,
+ .caps = CAP_RECOVERY_L0 | CAP_MULTI_R2T |
CAP_TEXT_NEGO,
/* session management */
.create_session = iscsi_iser_session_create,
.destroy_session= iscsi_iser_session_destroy,
diff --git a/drivers/infiniband/ulp/iser/iser_initiator.c
b/drivers/infiniband/ulp/iser/iser_initiator.c
index b6d81a8..b31fa1d 100644
--- a/drivers/infiniband/ulp/iser/iser_initiator.c
+++ b/drivers/infiniband/ulp/iser/iser_initiator.c
@@ -234,6 +234,7 @@ void iser_free_rx_descriptors(struct iser_conn *ib_conn)
static int iser_post_rx_bufs(struct iscsi_conn *conn, struct iscsi_hdr *req)
{
struct iscsi_iser_conn *iser_conn = conn-dd_data;
+ struct iscsi_session *session = conn-session;
iser_dbg(req op %x flags %x\n, req-opcode, req-flags);
/* check if this is the last login - going to full feature phase */
@@ -248,7 +249,13 @@ static int iser_post_rx_bufs(struct iscsi_conn *conn,
struct iscsi_hdr *req)
WARN_ON(iser_conn-ib_conn-post_recv_buf_count != 1);
WARN_ON(atomic_read(iser_conn-ib_conn-post_send_buf_count) != 0);
- iser_dbg(Initially post: %d\n, ISER_MIN_POSTED_RX);
+ if (session-discovery_sess) {
+ iser_info(Discovery session, re-using login RX buffer\n);
+ return 0;
+ } else
+ iser_info(Normal session, posting batch of RX %d buffers\n,
+ ISER_MIN_POSTED_RX);
+
/* Initial post receive buffers */
if (iser_post_recvm(iser_conn-ib_conn, ISER_MIN_POSTED_RX))
return -ENOMEM;
@@ -425,6 +432,8 @@ int iser_send_control(struct iscsi_conn *conn,
}
if (task == conn-login_task) {
+ iser_dbg(op %x dsl %lx, posting login rx buffer\n,
+task-hdr-opcode, data_seg_len);
err = iser_post_recvl(iser_conn-ib_conn);
if (err)
goto send_control_error;
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 86153e0..f17a692 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3170,6 +3170,7 @@ int iscsi_set_param(struct iscsi_cls_conn *cls_conn,
{
struct iscsi_conn *conn = cls_conn-dd_data;
struct iscsi_session *session = conn-session;
+ int val;
switch(param) {
case ISCSI_PARAM_FAST_ABORT:
@@ -3264,6 +3265,10 @@ int iscsi_set_param(struct iscsi_cls_conn *cls_conn,
case ISCSI_PARAM_DISCOVERY_PARENT_TYPE:
return iscsi_switch_str_param(session-discovery_parent_type,
buf);
+ case ISCSI_PARAM_DISCOVERY_SESS:
+ sscanf(buf, %d, val);
+ session-discovery_sess = !!val;
+ break;
default:
return -ENOSYS;
}
--
1.7.1
--
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 V2 4/8] [SCSI] megaraid: add missing __iomem annotation
-Original Message-
From: Jingoo Han [mailto:jg1@samsung.com]
Sent: Thursday, August 08, 2013 6:46 AM
To: 'James Bottomley'
Cc: DL-MegaRAID Linux; 'James Bottomley'; linux-scsi@vger.kernel.org;
Jingoo Han
Subject: [PATCH V2 4/8] [SCSI] megaraid: add missing __iomem annotation
Added missing __iomem annotation in order to fix the following sparse
warnings:
drivers/scsi/megaraid.c:4595:26: warning: incorrect type in argument 1
(different address spaces)
drivers/scsi/megaraid.c:4595:26:expected void volatile [noderef]
asn:2*addr
drivers/scsi/megaraid.c:4595:26:got void *noident
drivers/scsi/megaraid.c:4653:26: warning: incorrect type in argument 1
(different address spaces)
drivers/scsi/megaraid.c:4653:26:expected void volatile [noderef]
asn:2*addr
drivers/scsi/megaraid.c:4653:26:got void *noident
Signed-off-by: Jingoo Han jg1@samsung.com
---
No changes since v1:
drivers/scsi/megaraid.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
90c95a3..a395207 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -4592,7 +4592,7 @@ megaraid_probe_one(struct pci_dev *pdev, const
struct pci_device_id *id)
scsi_host_put(host);
out_iounmap:
if (flag BOARD_MEMMAP)
- iounmap((void *)mega_baseport);
+ iounmap((void __iomem *)mega_baseport);
out_release_region:
if (flag BOARD_MEMMAP)
release_mem_region(tbase, 128);
@@ -4650,7 +4650,7 @@ megaraid_remove_one(struct pci_dev *pdev)
/* Free our resources */
if (adapter-flag BOARD_MEMMAP) {
- iounmap((void *)adapter-base);
+ iounmap((void __iomem *)adapter-base);
release_mem_region(adapter-host-base, 128);
} else
release_region(adapter-base, 16);
--
1.7.10.4
Acked-by: Sumit Saxena sumit.sax...@lsi.com
Sumit
--
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 05/16] megaraid: clean up unnecessary MSI/MSI-X capability find
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will consume more time.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: Neela Syam Kolli megaraidli...@lsi.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/megaraid/megaraid_sas_base.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 0177295..ad8fc44 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4072,21 +4072,20 @@ fail_set_dma_mask:
static int megasas_probe_one(struct pci_dev *pdev,
const struct pci_device_id *id)
{
- int rval, pos, i, j;
+ int rval, i, j;
struct Scsi_Host *host;
struct megasas_instance *instance;
u16 control = 0;
/* Reset MSI-X in the kdump kernel */
if (reset_devices) {
- pos = pci_find_capability(pdev, PCI_CAP_ID_MSIX);
- if (pos) {
- pci_read_config_word(pdev, pos + PCI_MSIX_FLAGS,
+ if (pdev-msix_cap) {
+ pci_read_config_word(pdev, pdev-msix_cap +
PCI_MSIX_FLAGS,
control);
if (control PCI_MSIX_FLAGS_ENABLE) {
dev_info(pdev-dev, resetting MSI-X\n);
pci_write_config_word(pdev,
- pos + PCI_MSIX_FLAGS,
+ pdev-msix_cap +
PCI_MSIX_FLAGS,
control
~PCI_MSIX_FLAGS_ENABLE);
}
--
1.7.1
--
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 07/16] mpt3sas: clean up unnecessary MSI/MSI-X capability find
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will consume more time.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@lsi.com
Cc: Sreekanth Reddy sreekanth.re...@lsi.com
Cc: supp...@lsi.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: dl-mptfusionli...@lsi.com
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/mpt3sas/mpt3sas_base.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 5dc280c..e756191 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1520,11 +1520,9 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc,
struct pci_dev *pdev)
static int
_base_check_enable_msix(struct MPT3SAS_ADAPTER *ioc)
{
- int base;
u16 message_control;
- base = pci_find_capability(ioc-pdev, PCI_CAP_ID_MSIX);
- if (!base) {
+ if (!ioc-pdev-msix_cap) {
dfailprintk(ioc, pr_info(MPT3SAS_FMT msix not supported\n,
ioc-name));
return -EINVAL;
@@ -1532,7 +1530,8 @@ _base_check_enable_msix(struct MPT3SAS_ADAPTER *ioc)
/* get msix vector count */
- pci_read_config_word(ioc-pdev, base + 2, message_control);
+ pci_read_config_word(ioc-pdev, ioc-pdev-msix_cap + 2,
+ message_control);
ioc-msix_vector_count = (message_control 0x3FF) + 1;
if (ioc-msix_vector_count 8)
ioc-msix_vector_count = 8;
--
1.7.1
--
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 04/16] hpsa: clean up unnecessary MSI/MSI-X capability find
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will consume more time.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: Stephen M. Cameron scame...@beardog.cce.hp.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: iss_storage...@hp.com
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/hpsa.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..05b31f1 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4090,7 +4090,7 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
if ((h-board_id == 0x40700E11) || (h-board_id == 0x40800E11) ||
(h-board_id == 0x40820E11) || (h-board_id == 0x40830E11))
goto default_int_mode;
- if (pci_find_capability(h-pdev, PCI_CAP_ID_MSIX)) {
+ if (h-pdev-msix_cap) {
dev_info(h-pdev-dev, MSIX\n);
err = pci_enable_msix(h-pdev, hpsa_msix_entries,
MAX_REPLY_QUEUES);
@@ -4110,7 +4110,7 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
goto default_int_mode;
}
}
- if (pci_find_capability(h-pdev, PCI_CAP_ID_MSI)) {
+ if (h-pdev-msi_cap) {
dev_info(h-pdev-dev, MSI\n);
if (!pci_enable_msi(h-pdev))
h-msi_vector = 1;
--
1.7.1
--
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 12/16] pmcraid: clean up unnecessary MSI/MSI-X capability find
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will consume more time.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: Anil Ravindranath anil_ravindran...@pmc-sierra.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/pmcraid.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 1eb7b02..d5b3315 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4678,8 +4678,7 @@ pmcraid_register_interrupt_handler(struct
pmcraid_instance *pinstance)
int rc;
struct pci_dev *pdev = pinstance-pdev;
- if ((pmcraid_enable_msix)
- (pci_find_capability(pdev, PCI_CAP_ID_MSIX))) {
+ if (pmcraid_enable_msix pdev-msix_cap) {
int num_hrrq = PMCRAID_NUM_MSIX_VECTORS;
struct msix_entry entries[PMCRAID_NUM_MSIX_VECTORS];
int i;
--
1.7.1
--
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 11/16] pm8001: clean up unnecessary MSI/MSI-X capability find
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will consume more time.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/pm8001/pm8001_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_init.c
b/drivers/scsi/pm8001/pm8001_init.c
index 3861aa1..1ee61e8 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -734,7 +734,7 @@ static u32 pm8001_request_irq(struct pm8001_hba_info
*pm8001_ha)
pdev = pm8001_ha-pdev;
#ifdef PM8001_USE_MSIX
- if (pci_find_capability(pdev, PCI_CAP_ID_MSIX))
+ if (pdev-msix_cap)
return pm8001_setup_msix(pm8001_ha);
else {
PM8001_INIT_DBG(pm8001_ha,
--
1.7.1
--
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: [SCSI] lpfc: Don't force CONFIG_GENERIC_CSUM on
I'm good with it. You folks understand the config dependencies better than I. -- james Acked-By: James Smart james.sm...@emulex.com On 8/8/2013 3:47 AM, Anton Blanchard wrote: Hi Randy, I reported: on i386: # CONFIG_CRC_T10DIF is not set drivers/built-in.o: In function `lpfc_bg_crc': (.text+0x3cb3c9): undefined reference to `crc_t10dif' and then James Bottomley provided the patch. I don't know why he added GENERIC_CSUM to it. Thanks for investigating this. How does this patch look? Anton -- [SCSI] lpfc: Don't force CONFIG_GENERIC_CSUM on We want ppc64 to be able to select between optimised assembly checksum routines in big endian and the generic lib/checksum.c routines in little endian. The lpfc driver is forcing CONFIG_GENERIC_CSUM on which means we are unable to make the decision to enable it in the arch Kconfig. If the option exists it is always forced on. This got introduced in 3.10 via commit 6a7252fdb0c3 ([SCSI] lpfc: fix up Kconfig dependencies). I spoke to Randy about it and the original issue was with CRC_T10DIF not being defined. As such, remove the select of CONFIG_GENERIC_CSUM. Signed-off-by: Anton Blanchard an...@samba.org Cc: sta...@vger.kernel.org # 3.10 --- diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 48b2918..92ff027 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -1353,7 +1353,6 @@ config SCSI_LPFC tristate Emulex LightPulse Fibre Channel Support depends on PCI SCSI select SCSI_FC_ATTRS - select GENERIC_CSUM select CRC_T10DIF help This lpfc driver supports the Emulex LightPulse -- 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 v4 08/10] scsi: Generate uevents on certain unit attention codes
On Fri, 2013-08-02 at 10:06 -0700, James Bottomley wrote:
On Thu, 2013-08-01 at 16:57 -0400, Ewan D. Milne wrote:
From: Ewan D. Milne emi...@redhat.com
Generate a uevent when the following Unit Attention ASC/ASCQ
codes are received:
2A/01 MODE PARAMETERS CHANGED
2A/09 CAPACITY DATA HAS CHANGED
38/07 THIN PROVISIONING SOFT THRESHOLD REACHED
3F/03 INQUIRY DATA HAS CHANGED
3F/0E REPORTED LUNS DATA HAS CHANGED
Log kernel messages when the following Unit Attention ASC/ASCQ
codes are received that are not as specific as those above:
2A/xx PARAMETERS CHANGED
3F/xx TARGET OPERATING CONDITIONS HAVE CHANGED
Added logic to set expecting_cc_ua for other LUNs on SPC-3 devices
after REPORTED LUNS DATA HAS CHANGED is received, so that duplicate
uevents are not generated, and clear expecting_cc_ua when a
REPORT LUNS command completes, in accordance with the SPC-3
specification regarding reporting of the 3F 0E ASC/ASCQ UA.
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/scsi_error.c | 118
+
drivers/scsi/scsi_lib.c| 42 ++--
drivers/scsi/scsi_sysfs.c | 10
include/scsi/scsi_device.h | 11 -
4 files changed, 156 insertions(+), 25 deletions(-)
In general, this looks good. Just a few points below, and I think it
can go in.
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 96707a6..227041a 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -222,6 +222,86 @@ static inline void scsi_eh_prt_fail_stats(struct
Scsi_Host *shost,
}
#endif
+ /**
+ * scsi_report_lun_change - Set flag on all *other* devices on the same
target
+ * to indicate that a UNIT ATTENTION is expected.
+ * Only do this for SPC-3 devices, however.
+ * @sdev: Device reporting the UNIT ATTENTION
+ */
+static void scsi_report_lun_change(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev-host;
+ struct scsi_device *tmp_sdev;
+
+ if (sdev-scsi_level == SCSI_SPC_3)
Why the SPC3 check? We have SPC2 targets that use report luns and
presumably work as well.
Really the check was for SPC-4 and above, which I believe only generates
a single REPORT LUNS DATA HAS CHANGED unit attention on the first LUN
accessed. This was described in T10 06-411r2. I think it is still
needed but should be changed to = SCSI_SPC_3.
+ shost_for_each_device(tmp_sdev, shost) {
+ if (tmp_sdev-channel == sdev-channel
+ tmp_sdev-id == sdev-id
+ tmp_sdev != sdev)
This should be starget_for_each_device calling a function rather than
hand rolling.
+ tmp_sdev-expecting_cc_ua = 1;
Even with a restricted target loop, this is a bit messy (I think it's my
fault: I did ask you to reuse the existing mechanism, but now I see it,
a separate mechanism that functions the same way on the target looks a
lot cleaner) . It looks like a struct scsi_target
expecting_lun_change:1 flag would work better in this case? You'd set
it in the target at first sight, check it in scsi_report_sense() and
clear it on successful REPORT_LUNS command. There's no need to lock it
because operations on a u32 are atomic and we're going to get slop
around this and the possibility of extra events anyway.
I've tried this out, and it seems to work OK, but I'm a little concerned
about the possibility of losing a subsequent notification. If a flag is
used on the target, then multiple 3F 0E UAs from the same device could
be suppressed, which isn't exactly the correct behavior. Each LUN is
only supposed to report 3F 0E once in SPC-3, per change. If we receive
another one, then there presumably has been *another* change.
Perhaps I'm being too picky about this, and I'm not at all sure that
every storage array has this implemented properly either, so maybe it
doesn't matter enough.
+ }
+}
+
+/**
+ * scsi_report_sense - Examine scsi sense information and log messages for
+ *certain conditions, also issue uevents for some of them.
+ * @sshdr: sshdr to be examined
+ */
+static void scsi_report_sense(struct scsi_device *sdev,
+ struct scsi_sense_hdr *sshdr)
+{
+ enum scsi_device_event evt_type = SDEV_EVT_MAXBITS; /* i.e. none */
+ unsigned long flags;
+
+ if (sshdr-sense_key == UNIT_ATTENTION) {
+ if (sshdr-asc == 0x3f sshdr-ascq == 0x03) {
+ evt_type = SDEV_EVT_INQUIRY_CHANGE_REPORTED;
+ sdev_printk(KERN_WARNING, sdev,
+ Inquiry data has changed);
+ } else if (sshdr-asc == 0x3f sshdr-ascq == 0x0e) {
+ evt_type = SDEV_EVT_LUN_CHANGE_REPORTED;
+
Your Attention Is Needed
I am. Mr. Raymond Khumalo, Head Accounts Management Section, of a well-known Bank here in South Africa. Can i trust you on a transaction deal worth US$10,000,000.if interested contact me for details Email: mrraymondkhumal...@gmail.com -- 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 v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert dgilb...@interlog.com wrote: So what kind of signal was leading to your stomping on the memory? Was it user generated or something like SIGIO, SIGPIPE or a RT signal? It was sometimes SIGHUP (for reopening log files) and sometimes SIGALARM (for various periodic things). To get around the SG_IO ioctl restart problem (for non idempotent SCSI commands) could we replace a -ERESTARTSYS return value with -EINTR ? As I noted in a previous post, for robust user space code using the SG_IO ioctl, masking signals during the IO may help. Yes, absolutely. But process A should be able to keep its memory uncorrupted even if process B is coded wrong :) And what about bsg? Is it any better or worse than sg in the case of interrupted SG_IO ioctls? Apart from the interface (sg_io_hdr v3 versus v4) it should be a drop in replacement for sg. As far as I can tell bsg looks much better w.r.t. signals -- I don't see anywhere that it schedules work onto a workqueue or other kernel thread, and it looks like the SG_IO ioctl there actually has nowhere that checks for signals. All sleeps will be uninterruptible, which I guess may be better or worse depending on your perspective. - 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
[PATCH v5] scsi: Generate uevents on certain unit attention codes
From: Ewan D. Milne emi...@redhat.com
Generate a uevent when the following Unit Attention ASC/ASCQ
codes are received:
2A/01 MODE PARAMETERS CHANGED
2A/09 CAPACITY DATA HAS CHANGED
38/07 THIN PROVISIONING SOFT THRESHOLD REACHED
3F/03 INQUIRY DATA HAS CHANGED
3F/0E REPORTED LUNS DATA HAS CHANGED
Log kernel messages when the following Unit Attention ASC/ASCQ
codes are received that are not as specific as those above:
2A/xx PARAMETERS CHANGED
3F/xx TARGET OPERATING CONDITIONS HAVE CHANGED
Added logic to set expecting_lun_change for other LUNs on the target
after REPORTED LUNS DATA HAS CHANGED is received, so that duplicate
uevents are not generated, and clear expecting_lun_change when a
REPORT LUNS command completes, in accordance with the SPC-3
specification regarding reporting of the 3F 0E ASC/ASCQ UA.
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/scsi_error.c | 106 -
drivers/scsi/scsi_lib.c| 26 ++-
drivers/scsi/scsi_sysfs.c | 10 +
include/scsi/scsi_device.h | 13 +-
4 files changed, 133 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index d0f71e5..598afd9 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -222,6 +222,80 @@ static inline void scsi_eh_prt_fail_stats(struct Scsi_Host
*shost,
}
#endif
+ /**
+ * scsi_report_lun_change - Set flag on all *other* devices on the same target
+ * to indicate that a UNIT ATTENTION is expected.
+ * @sdev: Device reporting the UNIT ATTENTION
+ */
+static void scsi_report_lun_change(struct scsi_device *sdev)
+{
+ /*
+* Prior to SPC-4, every device will report a 3F 0E unit attention once
+* until a REPORT LUNS command is received. SPC-4 targets only report
+* the unit attention once on a single device.
+*/
+ if (sdev-scsi_level = SCSI_SPC_3)
+ sdev-sdev_target-expecting_lun_change = 1;
+}
+
+/**
+ * scsi_report_sense - Examine scsi sense information and log messages for
+ *certain conditions, also issue uevents for some of them.
+ * @sshdr: sshdr to be examined
+ */
+static void scsi_report_sense(struct scsi_device *sdev,
+ struct scsi_sense_hdr *sshdr)
+{
+ enum scsi_device_event evt_type = SDEV_EVT_MAXBITS; /* i.e. none */
+ unsigned long flags;
+
+ if (sshdr-sense_key == UNIT_ATTENTION) {
+ if (sshdr-asc == 0x3f sshdr-ascq == 0x03) {
+ evt_type = SDEV_EVT_INQUIRY_CHANGE_REPORTED;
+ sdev_printk(KERN_WARNING, sdev,
+ Inquiry data has changed);
+ } else if (sshdr-asc == 0x3f sshdr-ascq == 0x0e) {
+ evt_type = SDEV_EVT_LUN_CHANGE_REPORTED;
+ scsi_report_lun_change(sdev);
+ sdev_printk(KERN_WARNING, sdev,
+ Warning! Received an indication that the
+ LUN assignments on this target have
+ changed. The Linux SCSI layer does not
+ automatically remap LUN assignments.\n);
+ } else if (sshdr-asc == 0x3f)
+ sdev_printk(KERN_WARNING, sdev,
+ Warning! Received an indication that the
+ operating parameters on this target have
+ changed. The Linux SCSI layer does not
+ automatically adjust these parameters.\n);
+
+ if (sshdr-asc == 0x38 sshdr-ascq == 0x07) {
+ evt_type = SDEV_EVT_SOFT_THRESHOLD_REACHED_REPORTED;
+ sdev_printk(KERN_WARNING, sdev,
+ Warning! Received an indication that the
+ LUN reached a thin provisioning soft
+ threshold.\n);
+ }
+
+ if (sshdr-asc == 0x2a sshdr-ascq == 0x01) {
+ evt_type = SDEV_EVT_MODE_PARAMETER_CHANGE_REPORTED;
+ sdev_printk(KERN_WARNING, sdev,
+ Mode parameters changed);
+ } else if (sshdr-asc == 0x2a sshdr-ascq == 0x09) {
+ evt_type = SDEV_EVT_CAPACITY_CHANGE_REPORTED;
+ sdev_printk(KERN_WARNING, sdev,
+ Capacity data has changed);
+ } else if (sshdr-asc == 0x2a)
+ sdev_printk(KERN_WARNING, sdev,
+ Parameters changed);
+ }
+
+ if (evt_type != SDEV_EVT_MAXBITS) {
+ set_bit(evt_type, sdev-pending_events);
+ schedule_work(sdev-event_work);
[PATCH v3 1/2] mpt2sas: fix cleanup on controller resource mapping failure
If mpt2sas_base_map_resources takes an early error path then its
counterpart, mpt2sas_base_free_resources needs to be careful about
cleaning up:
1 - _base_mask_interrupts and _base_make_ioc_ready require memory
mapped I/O registers, make sure that this is true.
2 - _base_free_irq iterates over the adapter's reply_queue_list, so
move this list head initialization out of _base_enable_msix to
_scsih_probe so this will always be safe.
3 - check that the controller PCI device and its BARs have been
enabled before disabling them.
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 27 +--
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 1 +
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 3ca757d..27ff0f63 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1409,8 +1409,6 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
int i;
u8 try_msix = 0;
- INIT_LIST_HEAD(ioc-reply_queue_list);
-
if (msix_disable == -1 || msix_disable == 0)
try_msix = 1;
@@ -1489,6 +1487,7 @@ mpt2sas_base_map_resources(struct MPT2SAS_ADAPTER *ioc)
if (pci_enable_device_mem(pdev)) {
printk(MPT2SAS_WARN_FMT pci_enable_device_mem:
failed\n, ioc-name);
+ ioc-bars = 0;
return -ENODEV;
}
@@ -1497,6 +1496,7 @@ mpt2sas_base_map_resources(struct MPT2SAS_ADAPTER *ioc)
MPT2SAS_DRIVER_NAME)) {
printk(MPT2SAS_WARN_FMT pci_request_selected_regions:
failed\n, ioc-name);
+ ioc-bars = 0;
r = -ENODEV;
goto out_fail;
}
@@ -4229,18 +4229,25 @@ mpt2sas_base_free_resources(struct MPT2SAS_ADAPTER *ioc)
dexitprintk(ioc, printk(MPT2SAS_INFO_FMT %s\n, ioc-name,
__func__));
- _base_mask_interrupts(ioc);
- ioc-shost_recovery = 1;
- _base_make_ioc_ready(ioc, CAN_SLEEP, SOFT_RESET);
- ioc-shost_recovery = 0;
+ if (ioc-chip_phys ioc-chip) {
+ _base_mask_interrupts(ioc);
+ ioc-shost_recovery = 1;
+ _base_make_ioc_ready(ioc, CAN_SLEEP, SOFT_RESET);
+ ioc-shost_recovery = 0;
+ }
+
_base_free_irq(ioc);
_base_disable_msix(ioc);
- if (ioc-chip_phys)
+
+ if (ioc-chip_phys ioc-chip)
iounmap(ioc-chip);
ioc-chip_phys = 0;
- pci_release_selected_regions(ioc-pdev, ioc-bars);
- pci_disable_pcie_error_reporting(pdev);
- pci_disable_device(pdev);
+
+ if (pci_is_enabled(pdev)) {
+ pci_release_selected_regions(ioc-pdev, ioc-bars);
+ pci_disable_pcie_error_reporting(pdev);
+ pci_disable_device(pdev);
+ }
return;
}
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 5100476..389d792 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -8175,6 +8175,7 @@ _scsih_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
INIT_LIST_HEAD(ioc-sas_hba.sas_port_list);
INIT_LIST_HEAD(ioc-delayed_tr_list);
INIT_LIST_HEAD(ioc-delayed_tr_volume_list);
+ INIT_LIST_HEAD(ioc-reply_queue_list);
/* init shost parameters */
shost-max_cmd_len = 32;
--
1.8.3.1
--
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 v3 0/2] mpt2sas/mpt3sas resource cleanup fixes
Hi Sreekanth, Here are the patches that address your offlist feedback and testing of earlier patchset versions. I tested with as many early exits as I could think of inside of mpt2sas_base_map_resources to verify, so I believe all error paths should be safe and message-log-friendly. Regards, Joe --- Changes from v2 (offlist): - Clear ioc-bars if pci_enable_device_mem fails. - pci_release_selected_regions verifies non-zero bar pointer, so as long as it's cleared when not actually enabled, we don't need to check it first. Changes from v1: - Verify that the PCI device is enabled before disabling it. - Verify that the PCI BARs have been enabled before releasing them. Joe Lawrence (2): mpt2sas: fix cleanup on controller resource mapping failure mpt3sas: fix cleanup on controller resource mapping failure drivers/scsi/mpt2sas/mpt2sas_base.c | 27 +-- drivers/scsi/mpt2sas/mpt2sas_scsih.c | 1 + drivers/scsi/mpt3sas/mpt3sas_base.c | 27 +-- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1 + 4 files changed, 36 insertions(+), 20 deletions(-) -- 1.8.3.1 -- 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 v3 2/2] mpt3sas: fix cleanup on controller resource mapping failure
If mpt3sas_base_map_resources takes an early error path then its
counterpart, mpt3sas_base_free_resources needs to be careful about
cleaning up:
1 - _base_mask_interrupts and _base_make_ioc_ready require memory
mapped I/O registers, make sure that this is true.
2 - _base_free_irq iterates over the adapter's reply_queue_list, so
move this list head initialization out of _base_enable_msix to
_scsih_probe so this will always be safe.
3 - check that the controller PCI device and its BARs have been
enabled before disabling them.
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 27 +--
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1 +
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index b119610..f998c8d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1709,8 +1709,6 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
int i;
u8 try_msix = 0;
- INIT_LIST_HEAD(ioc-reply_queue_list);
-
if (msix_disable == -1 || msix_disable == 0)
try_msix = 1;
@@ -1790,6 +1788,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
if (pci_enable_device_mem(pdev)) {
pr_warn(MPT3SAS_FMT pci_enable_device_mem: failed\n,
ioc-name);
+ ioc-bars = 0;
return -ENODEV;
}
@@ -1798,6 +1797,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
MPT3SAS_DRIVER_NAME)) {
pr_warn(MPT3SAS_FMT pci_request_selected_regions: failed\n,
ioc-name);
+ ioc-bars = 0;
r = -ENODEV;
goto out_fail;
}
@@ -4393,18 +4393,25 @@ mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER *ioc)
dexitprintk(ioc, pr_info(MPT3SAS_FMT %s\n, ioc-name,
__func__));
- _base_mask_interrupts(ioc);
- ioc-shost_recovery = 1;
- _base_make_ioc_ready(ioc, CAN_SLEEP, SOFT_RESET);
- ioc-shost_recovery = 0;
+ if (ioc-chip_phys ioc-chip) {
+ _base_mask_interrupts(ioc);
+ ioc-shost_recovery = 1;
+ _base_make_ioc_ready(ioc, CAN_SLEEP, SOFT_RESET);
+ ioc-shost_recovery = 0;
+ }
+
_base_free_irq(ioc);
_base_disable_msix(ioc);
- if (ioc-chip_phys)
+
+ if (ioc-chip_phys ioc-chip)
iounmap(ioc-chip);
ioc-chip_phys = 0;
- pci_release_selected_regions(ioc-pdev, ioc-bars);
- pci_disable_pcie_error_reporting(pdev);
- pci_disable_device(pdev);
+
+ if (pci_is_enabled(pdev)) {
+ pci_release_selected_regions(ioc-pdev, ioc-bars);
+ pci_disable_pcie_error_reporting(pdev);
+ pci_disable_device(pdev);
+ }
return;
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 8cbe8fd..a961fe1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -7779,6 +7779,7 @@ _scsih_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
INIT_LIST_HEAD(ioc-sas_hba.sas_port_list);
INIT_LIST_HEAD(ioc-delayed_tr_list);
INIT_LIST_HEAD(ioc-delayed_tr_volume_list);
+ INIT_LIST_HEAD(ioc-reply_queue_list);
/* init shost parameters */
shost-max_cmd_len = 32;
--
1.8.3.1
--
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 v2] Hard disk S3 resume time optimization
This patch essentially removes the disk spinup wait time from the system S3
resume delay. It can be a very significant improvement on systems with large
SATA disks which can take several seconds to spin up. On the systems I've
tested this patch reduces the resume time to around half a second (assuming no
USB devices are consuming that time). Without the patch my systems require
anywhere from 5 to 12 seconds to wakeup from S3 resume depending on the size of
the disks attached.
This is a rewrite of my first attempt to optimize S3 disk resume time:
http://marc.info/?l=linux-idem=136874337908364w=2 . It's vastly simpler in
that it doesn't make any alterations at all to the pm subsystem to allow
non-blocking resume, it simply enables the ata_port and scsi_disk drivers to do
their work in a non-blocking way.
Made some alterations to the first draft of the patch, this is v2.
1) Added scsi cmd error reporting in response to Oliver's comments. The
sd_resume_async_end function now prints out the same error information that was
printed in the sd_start_stop_device call; including the sense buffer contents.
I didn't add any additional error messages for the ata port wakeup since, if
the port wakeup fails, the error data is printed out by the error handler
process itself, so it doesn't require the ata_port_resume call to check up on
it after the failure. The only potential issue is that the
ata_port_resume_async call sets the ata port device to RPM_ACTIVE even if the
ata_eh_handle_port_resume call fails, but there doesn't appear to be any code
which actually calls pm_runtime_set_suspended for ata_ports at the moment, so
the ata_port appears to always be set to RPM_ACTIVE anyway (please correct me
if I'm wrong).
2) I created a new ata_port_resume_async function just for the resume
callback so that it wouldn't affect the thaw, restore, or runtime resume
callback behaviour (just to be on the safe side).
3) I also moved the scsi_disk_put call up into the sd_resume_async_end callback
since the reference counter shouldn't be decremented until the disk is actually
finished starting.
Signed-off-by: Todd Brandt todd.e.bra...@intel.com
drivers/ata/libata-core.c | 19 +-
drivers/scsi/sd.c | 78
-
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index c24354d..842004c 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -118,6 +118,7 @@ struct ata_force_ent {
static struct ata_force_ent *ata_force_tbl;
static int ata_force_tbl_size;
+int ata_resume_status;
static char ata_force_param_buf[PAGE_SIZE] __initdata;
/* param_buf is thrown away after initialization, disallow read */
@@ -5415,6 +5416,22 @@ static int ata_port_resume(struct device *dev)
return rc;
}
+static int ata_port_resume_async(struct device *dev)
+{
+ struct ata_port *ap = to_ata_port(dev);
+
+ ata_resume_status = 0;
+ ata_port_request_pm(ap, PMSG_RESUME, ATA_EH_RESET,
+ ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, ata_resume_status);
+ if (!ata_resume_status) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ }
+
+ return ata_resume_status;
+}
+
/*
* For ODDs, the upper layer will poll for media change every few seconds,
* which will make it enter and leave suspend state every few seconds. And
@@ -5451,7 +5468,7 @@ static int ata_port_runtime_resume(struct device *dev)
static const struct dev_pm_ops ata_port_pm_ops = {
.suspend = ata_port_suspend,
- .resume = ata_port_resume,
+ .resume = ata_port_resume_async,
.freeze = ata_port_do_freeze,
.thaw = ata_port_resume,
.poweroff = ata_port_poweroff,
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 86fcf2c..f5a9800 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -107,6 +107,7 @@ static int sd_remove(struct device *);
static void sd_shutdown(struct device *);
static int sd_suspend(struct device *);
static int sd_resume(struct device *);
+static int sd_resume_async(struct device *);
static void sd_rescan(struct device *);
static int sd_done(struct scsi_cmnd *);
static int sd_eh_action(struct scsi_cmnd *, unsigned char *, int, int);
@@ -484,7 +485,7 @@ static struct class sd_disk_class = {
static const struct dev_pm_ops sd_pm_ops = {
.suspend= sd_suspend,
- .resume = sd_resume,
+ .resume = sd_resume_async,
.poweroff = sd_suspend,
.restore= sd_resume,
.runtime_suspend= sd_suspend,
@@ -3137,6 +3138,81 @@ done:
return ret;
}
+static void sd_resume_async_end(struct request *rq, int error)
+{
+ struct scsi_sense_hdr sshdr;
+ struct scsi_disk *sdkp =
Re: [PATCH v4 08/10] scsi: Generate uevents on certain unit attention codes
On Thu, 2013-08-08 at 12:08 -0400, Ewan Milne wrote:
On Fri, 2013-08-02 at 10:06 -0700, James Bottomley wrote:
On Thu, 2013-08-01 at 16:57 -0400, Ewan D. Milne wrote:
From: Ewan D. Milne emi...@redhat.com
+ * scsi_report_lun_change - Set flag on all *other* devices on the same
target
+ * to indicate that a UNIT ATTENTION is
expected.
+ * Only do this for SPC-3 devices, however.
+ * @sdev:Device reporting the UNIT ATTENTION
+ */
+static void scsi_report_lun_change(struct scsi_device *sdev)
+{
+ struct Scsi_Host *shost = sdev-host;
+ struct scsi_device *tmp_sdev;
+
+ if (sdev-scsi_level == SCSI_SPC_3)
Why the SPC3 check? We have SPC2 targets that use report luns and
presumably work as well.
Really the check was for SPC-4 and above, which I believe only generates
a single REPORT LUNS DATA HAS CHANGED unit attention on the first LUN
accessed. This was described in T10 06-411r2. I think it is still
needed but should be changed to = SCSI_SPC_3.
Perhaps the check needs to go then. Just because SPC-4 says one event
per target doesn't mean devices will obey it. There's no harm if we
guard against repeats even for SPC-4 and above (if they don't do it,
it's just a few extra setting and unsetting of flags) and we'll just
have to remove it again when the first broken device shows up.
+ shost_for_each_device(tmp_sdev, shost) {
+ if (tmp_sdev-channel == sdev-channel
+ tmp_sdev-id == sdev-id
+ tmp_sdev != sdev)
This should be starget_for_each_device calling a function rather than
hand rolling.
+ tmp_sdev-expecting_cc_ua = 1;
Even with a restricted target loop, this is a bit messy (I think it's my
fault: I did ask you to reuse the existing mechanism, but now I see it,
a separate mechanism that functions the same way on the target looks a
lot cleaner) . It looks like a struct scsi_target
expecting_lun_change:1 flag would work better in this case? You'd set
it in the target at first sight, check it in scsi_report_sense() and
clear it on successful REPORT_LUNS command. There's no need to lock it
because operations on a u32 are atomic and we're going to get slop
around this and the possibility of extra events anyway.
I've tried this out, and it seems to work OK, but I'm a little concerned
about the possibility of losing a subsequent notification. If a flag is
used on the target, then multiple 3F 0E UAs from the same device could
be suppressed, which isn't exactly the correct behavior. Each LUN is
only supposed to report 3F 0E once in SPC-3, per change. If we receive
another one, then there presumably has been *another* change.
Perhaps I'm being too picky about this, and I'm not at all sure that
every storage array has this implemented properly either, so maybe it
doesn't matter enough.
Well, you're not thinking about it the right way. Even on the per sdev
flag, we don't clear until a successful GOOD status return, so it will
suppress multiple genuine UAs anyway, assuming the lun data changes are
done fast enough.
From a systems point of view, we receive a UA, trigger and event and
then some user programme tries to work out what changed by issuing a
REPORT LUNS and we suppress all UAs for LUN data changes until the
REPORT LUNS comes down. Even if we get multiple genuine LUN data
changes in that interval, the user programme is going to read the latest
up to date information anyway, so it doesn't matter in the slightest
that we can lose genuine events.
The actual problem with the new scheme is the reverse: that it doesn't
suppress all the spurious events: given a target with three luns, two of
which are in constant use and one of which in sporadic, we'll suppress
the UAs from the LUNs in constant use, but if the sporadic LUN receives
no I/O until after the REPORT LUNS comes down, then it will trigger
another UA for an event we've already processed. I think that's a price
worth paying for simplicity, though.
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -710,6 +710,11 @@ sdev_store_evt_##name(struct device *dev, struct
device_attribute *attr,\
#define REF_EVT(name) dev_attr_evt_##name.attr
DECLARE_EVT(media_change, MEDIA_CHANGE)
+DECLARE_EVT(inquiry_change_reported, INQUIRY_CHANGE_REPORTED)
+DECLARE_EVT(capacity_change_reported, CAPACITY_CHANGE_REPORTED)
+DECLARE_EVT(soft_threshold_reached, SOFT_THRESHOLD_REACHED_REPORTED)
+DECLARE_EVT(mode_parameter_change_reported,
MODE_PARAMETER_CHANGE_REPORTED)
+DECLARE_EVT(lun_change_reported, LUN_CHANGE_REPORTED)
/* Default template for device attributes. May NOT be modified */
static struct attribute *scsi_sdev_attrs[] = {
@@ -729,6 +734,11 @@ static struct attribute *scsi_sdev_attrs[] = {
dev_attr_ioerr_cnt.attr,
[PATCH 1/1] Updated sd_do_mode_sense() description
sd_do_mode_sense() is no longer called with a fixed length buffer. Updated its description to reflect the same. Signed-off-by: ChinmayVS cvs...@gmail.com --- drivers/scsi/sd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index b58e8f8..b183347 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2237,7 +2237,7 @@ got_data: sdkp-device-sector_size = sector_size; } -/* called with buffer of length 512 */ +/* called with buffer of length len */ static inline int sd_do_mode_sense(struct scsi_device *sdp, int dbd, int modepage, unsigned char *buffer, int len, struct scsi_mode_data *data, -- 1.8.1.2 -- 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 11/16] pm8001: clean up unnecessary MSI/MSI-X capability find
On 08/08/2013 9:10 PM, Yijing Wang wrote:
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use pci_dev-
msi_cap/msix_cap to determine whether the device support MSI/MSI-X
instead of using pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will consume more time.
It's fine.
You can add my Acked-by.
Thanks,
Lindar
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/pm8001/pm8001_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_init.c
b/drivers/scsi/pm8001/pm8001_init.c
index 3861aa1..1ee61e8 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -734,7 +734,7 @@ static u32 pm8001_request_irq(struct
pm8001_hba_info *pm8001_ha)
pdev = pm8001_ha-pdev;
#ifdef PM8001_USE_MSIX
- if (pci_find_capability(pdev, PCI_CAP_ID_MSIX))
+ if (pdev-msix_cap)
return pm8001_setup_msix(pm8001_ha);
else {
PM8001_INIT_DBG(pm8001_ha,
--
1.7.1
--
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
