Re: hpsa driver bug crack kernel down!
Hi Davidlohr, Thanks for the information! According to lspci output, device :02:00.2 is HP ILO controller, device :03:00.0 is RAID controller. Both ILO and RAID controllers need to access reserved memory range [0x7f61e000 - 0x7f61] in physical mode. According to dmesg output, BIOS has reserved memory and IOMMU has setup 1:1 mapping for ILO and RAID controller to access this range. Related log messages as below: BIOS-e820: [mem 0x7f61d000-0x8fff] reserved IOMMU: Setting RMRR: IOMMU: Setting identity map for device :03:00.0 [0x7f61e000 - 0x7f61] IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] From the screenshot, device :02:00.2 fails to access memory address 0x7f61e000. That indicates IOMMU driver fails to setup 1:1 mapping for Reserved Memory Range for ILO controller. So could you please help to check whether you could observe boot messages like IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] with the failure kernel image? It would be great if boot messages could be saved when failing to boot, so we could get more information from log. BTW, I have double checked related code, and still can't find a reliable explanation for the regression:( Thanks! Gerry On 2014/4/11 0:19, Davidlohr Bueso wrote: On Thu, 2014-04-10 at 08:46 +, Woodhouse, David wrote: On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote: [+ David, VT-d maintainer ] Jiang, David, can you please have a look into this issue? DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 That Present bit in context entry is clear fault means that we have not set up *any* mappings for this PCI device… on this IOMMU. Yes, specifically (finally done bisecting): commit 2e45528930388658603ea24d49cf52867b928d3e Author: Jiang Liu jiang@linux.intel.com Date: Wed Feb 19 14:07:36 2014 +0800 iommu/vt-d: Unify the way to process DMAR device scope array This commit is about how we decide which IOMMU a given PCI device is attached to. Thus, my first guess would be that we are quite happily setting up the requested DMA maps on the *wrong* IOMMU, and then taking faults when the device actually tries to do DMA. However, I'm not 100% convinced of that. The fault address looks suspiciously like a true physical address, not a virtual bus address of the type that we'd normally allocate for a dma_map_* operation. Those would start at 0xf000 and work downwards, typically. Do you have 'iommu=pt' on the kernel command line? No. Can I see the full dmesg as this system boots, and also a copy of the DMAR table? Attaching a dmesg from one of the kernels that boots. It doesn't appear to have much of the related information... is there any debug config option I can enable that might give you more data? -- 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 RESEND 09/23] hpsa: Fallback to MSI rather than to INTx if MSI-X failed
Currently the driver falls back to INTx mode when MSI-X
initialization failed. This is a suboptimal behaviour
for chips that also support MSI. This update changes that
behaviour and falls back to MSI mode in case MSI-X mode
initialization failed.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Stephen M. Cameron scame...@beardog.cce.hp.com
Cc: iss_storage...@hp.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/hpsa.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..3284edb 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -6162,7 +6162,6 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
dev_warn(h-pdev-dev, MSI-X init failed %d\n,
err);
h-msix_vector = 0;
- goto default_int_mode;
}
}
if (pci_find_capability(h-pdev, PCI_CAP_ID_MSI)) {
--
1.7.7.6
--
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 RESEND 10/23] hpsa: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Stephen M. Cameron scame...@beardog.cce.hp.com
Cc: iss_storage...@hp.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/hpsa.c | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 3284edb..36bb1e4 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -6144,26 +6144,23 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
goto default_int_mode;
if (pci_find_capability(h-pdev, PCI_CAP_ID_MSIX)) {
dev_info(h-pdev-dev, MSIX\n);
- h-msix_vector = MAX_REPLY_QUEUES;
- err = pci_enable_msix(h-pdev, hpsa_msix_entries,
- h-msix_vector);
- if (err 0) {
+ err = pci_enable_msix_range(h-pdev, hpsa_msix_entries,
+ 1, MAX_REPLY_QUEUES);
+ if (err 0) {
+ dev_warn(h-pdev-dev, MSI-X init failed %d\n, err);
+ h-msix_vector = 0;
+ goto single_msi_mode;
+ } else if (err MAX_REPLY_QUEUES) {
dev_warn(h-pdev-dev, only %d MSI-X vectors
available\n, err);
- h-msix_vector = err;
- err = pci_enable_msix(h-pdev, hpsa_msix_entries,
- h-msix_vector);
- }
- if (!err) {
- for (i = 0; i h-msix_vector; i++)
- h-intr[i] = hpsa_msix_entries[i].vector;
- return;
- } else {
- dev_warn(h-pdev-dev, MSI-X init failed %d\n,
- err);
- h-msix_vector = 0;
}
+
+ h-msix_vector = err;
+ for (i = 0; i h-msix_vector; i++)
+ h-intr[i] = hpsa_msix_entries[i].vector;
+ return;
}
+single_msi_mode:
if (pci_find_capability(h-pdev, PCI_CAP_ID_MSI)) {
dev_info(h-pdev-dev, MSI\n);
if (!pci_enable_msi(h-pdev))
--
1.7.7.6
--
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 RESEND 17/23] pm8001: Fix invalid return when request_irq() failed
When a call to request_irq() failed pm8001_setup_msix()
still returns the success. This udate fixes the described
misbehaviour.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Jack Wang xjtu...@gmail.com
---
drivers/scsi/pm8001/pm8001_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_init.c
b/drivers/scsi/pm8001/pm8001_init.c
index c4f31b21..df421f5 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -740,9 +740,10 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
*pm8001_ha)
pm8001_ha-irq_vector[i].irq_id = i;
pm8001_ha-irq_vector[i].drv_inst = pm8001_ha;
- if (request_irq(pm8001_ha-msix_entries[i].vector,
+ rc = request_irq(pm8001_ha-msix_entries[i].vector,
pm8001_interrupt_handler_msix, flag,
- intr_drvname[i], (pm8001_ha-irq_vector[i]))) {
+ intr_drvname[i], (pm8001_ha-irq_vector[i]));
+ if (rc) {
for (j = 0; j i; j++)
free_irq(
pm8001_ha-msix_entries[j].vector,
--
1.7.7.6
--
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 RESEND 23/23] vmw_pvscsi: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Arvind Kumar arvindku...@vmware.com
Cc: pv-driv...@vmware.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Arvind Kumar arvindku...@vmware.com
---
drivers/scsi/vmw_pvscsi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index c88e146..598f65e 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -1194,7 +1194,7 @@ static int pvscsi_setup_msix(const struct pvscsi_adapter
*adapter,
struct msix_entry entry = { 0, PVSCSI_VECTOR_COMPLETION };
int ret;
- ret = pci_enable_msix(adapter-dev, entry, 1);
+ ret = pci_enable_msix_exact(adapter-dev, entry, 1);
if (ret)
return ret;
--
1.7.7.6
--
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 RESEND 18/23] pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/pm8001/pm8001_init.c | 39 +++--
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_init.c
b/drivers/scsi/pm8001/pm8001_init.c
index df421f5..1d3c02d 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -725,34 +725,35 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
*pm8001_ha)
sizeof(pm8001_ha-msix_entries[0]);
for (i = 0; i max_entry ; i++)
pm8001_ha-msix_entries[i].entry = i;
- rc = pci_enable_msix(pm8001_ha-pdev, pm8001_ha-msix_entries,
+ rc = pci_enable_msix_exact(pm8001_ha-pdev, pm8001_ha-msix_entries,
number_of_intr);
pm8001_ha-number_of_intr = number_of_intr;
- if (!rc) {
- PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
- pci_enable_msix request ret:%d no of intr %d\n,
- rc, pm8001_ha-number_of_intr));
+ if (rc)
+ return rc;
+ PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
+ pci_enable_msix_exact request ret:%d no of intr %d\n,
+ rc, pm8001_ha-number_of_intr));
- for (i = 0; i number_of_intr; i++) {
- snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
- DRV_NAME%d, i);
- pm8001_ha-irq_vector[i].irq_id = i;
- pm8001_ha-irq_vector[i].drv_inst = pm8001_ha;
+ for (i = 0; i number_of_intr; i++) {
+ snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
+ DRV_NAME%d, i);
+ pm8001_ha-irq_vector[i].irq_id = i;
+ pm8001_ha-irq_vector[i].drv_inst = pm8001_ha;
- rc = request_irq(pm8001_ha-msix_entries[i].vector,
- pm8001_interrupt_handler_msix, flag,
- intr_drvname[i], (pm8001_ha-irq_vector[i]));
- if (rc) {
- for (j = 0; j i; j++)
- free_irq(
- pm8001_ha-msix_entries[j].vector,
+ rc = request_irq(pm8001_ha-msix_entries[i].vector,
+ pm8001_interrupt_handler_msix, flag,
+ intr_drvname[i], (pm8001_ha-irq_vector[i]));
+ if (rc) {
+ for (j = 0; j i; j++) {
+ free_irq(pm8001_ha-msix_entries[j].vector,
(pm8001_ha-irq_vector[i]));
- pci_disable_msix(pm8001_ha-pdev);
- break;
}
+ pci_disable_msix(pm8001_ha-pdev);
+ break;
}
}
+
return rc;
}
#endif
--
1.7.7.6
--
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 RESEND 21/23] qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Log message code 0x00c6 preserved, although it is reported
after successful call to pci_enable_msix_range(), not before
possibly unsuccessful call to pci_enable_msix(). Consumers
of the error code should not notice the difference.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/qla2xxx/qla_isr.c | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 95314ef..41eb0dc 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2918,27 +2918,22 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
rsp_que *rsp)
for (i = 0; i ha-msix_count; i++)
entries[i].entry = i;
- ret = pci_enable_msix(ha-pdev, entries, ha-msix_count);
- if (ret) {
- if (ret MIN_MSIX_COUNT)
- goto msix_failed;
-
+ ret = pci_enable_msix_range(ha-pdev,
+ entries, MIN_MSIX_COUNT, ha-msix_count);
+ if (ret 0) {
+ ql_log(ql_log_fatal, vha, 0x00c7,
+ MSI-X: Failed to enable support,
+ giving up -- %d/%d.\n,
+ ha-msix_count, ret);
+ goto msix_out;
+ } else if (ret ha-msix_count) {
ql_log(ql_log_warn, vha, 0x00c6,
MSI-X: Failed to enable support
-- %d/%d\n Retry with %d vectors.\n,
ha-msix_count, ret, ret);
- ha-msix_count = ret;
- ret = pci_enable_msix(ha-pdev, entries, ha-msix_count);
- if (ret) {
-msix_failed:
- ql_log(ql_log_fatal, vha, 0x00c7,
- MSI-X: Failed to enable support,
- giving up -- %d/%d.\n,
- ha-msix_count, ret);
- goto msix_out;
- }
- ha-max_rsp_queues = ha-msix_count - 1;
}
+ ha-msix_count = ret;
+ ha-max_rsp_queues = ha-msix_count - 1;
ha-msix_entries = kzalloc(sizeof(struct qla_msix_entry) *
ha-msix_count, GFP_KERNEL);
if (!ha-msix_entries) {
--
1.7.7.6
--
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 RESEND 19/23] pmcraid: Get rid of a redundant assignment
Signed-off-by: Alexander Gordeev agord...@redhat.com Cc: Anil Ravindranath anil_ravindran...@pmc-sierra.com Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/scsi/pmcraid.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c index be8ce54..c06af7f 100644 --- a/drivers/scsi/pmcraid.c +++ b/drivers/scsi/pmcraid.c @@ -4746,7 +4746,6 @@ pmcraid_isr_legacy: pinstance-hrrq_vector[0].drv_inst = pinstance; pinstance-hrrq_vector[0].vector = pdev-irq; pinstance-num_hrrq = 1; - rc = 0; rc = request_irq(pdev-irq, pmcraid_isr, IRQF_SHARED, PMCRAID_DRIVER_NAME, pinstance-hrrq_vector[0]); -- 1.7.7.6 -- 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 RESEND 20/23] pmcraid: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Anil Ravindranath anil_ravindran...@pmc-sierra.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/pmcraid.c | 13 ++---
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index c06af7f..6d0f208 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4698,19 +4698,10 @@ pmcraid_register_interrupt_handler(struct
pmcraid_instance *pinstance)
for (i = 0; i PMCRAID_NUM_MSIX_VECTORS; i++)
entries[i].entry = i;
- rc = pci_enable_msix(pdev, entries, num_hrrq);
- if (rc 0)
+ num_hrrq = pci_enable_msix_range(pdev, entries, 1, num_hrrq);
+ if (num_hrrq 0)
goto pmcraid_isr_legacy;
- /* Check how many MSIX vectors are allocated and register
-* msi-x handlers for each of them giving appropriate buffer
-*/
- if (rc 0) {
- num_hrrq = rc;
- if (pci_enable_msix(pdev, entries, num_hrrq))
- goto pmcraid_isr_legacy;
- }
-
for (i = 0; i num_hrrq; i++) {
pinstance-hrrq_vector[i].hrrq_id = i;
pinstance-hrrq_vector[i].drv_inst = pinstance;
--
1.7.7.6
--
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 RESEND 15/23] mpt2sas: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@lsi.com
Cc: Sreekanth Reddy sreekanth.re...@lsi.com
Cc: supp...@lsi.com
Cc: dl-mptfusionli...@lsi.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/mpt2sas/mpt2sas_base.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index bde63f7..984b605 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1432,10 +1432,10 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
for (i = 0, a = entries; i ioc-reply_queue_count; i++, a++)
a-entry = i;
- r = pci_enable_msix(ioc-pdev, entries, ioc-reply_queue_count);
+ r = pci_enable_msix_exact(ioc-pdev, entries, ioc-reply_queue_count);
if (r) {
- dfailprintk(ioc, printk(MPT2SAS_INFO_FMT pci_enable_msix
- failed (r=%d) !!!\n, ioc-name, r));
+ dfailprintk(ioc, printk(MPT2SAS_INFO_FMT
+ pci_enable_msix_exact failed (r=%d) !!!\n, ioc-name, r));
kfree(entries);
goto try_ioapic;
}
--
1.7.7.6
--
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 RESEND 12/23] lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: James Smart james.sm...@emulex.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/lpfc/lpfc_init.c | 38 +-
1 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 7163f37..b109adc 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8100,9 +8100,9 @@ lpfc_sli4_pci_mem_unset(struct lpfc_hba *phba)
* @phba: pointer to lpfc hba data structure.
*
* This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-3 interface specs. The kernel function pci_enable_msix() is
- * called to enable the MSI-X vectors. Note that pci_enable_msix(), once
- * invoked, enables either all or nothing, depending on the current
+ * with SLI-3 interface specs. The kernel function pci_enable_msix_exact()
+ * is called to enable the MSI-X vectors. Note that pci_enable_msix_exact(),
+ * once invoked, enables either all or nothing, depending on the current
* availability of PCI vector resources. The device driver is responsible
* for calling the individual request_irq() to register each MSI-X vector
* with a interrupt handler, which is done in this function. Note that
@@ -8126,8 +8126,8 @@ lpfc_sli_enable_msix(struct lpfc_hba *phba)
phba-msix_entries[i].entry = i;
/* Configure MSI-X capability structure */
- rc = pci_enable_msix(phba-pcidev, phba-msix_entries,
- ARRAY_SIZE(phba-msix_entries));
+ rc = pci_enable_msix_exact(phba-pcidev, phba-msix_entries,
+ ARRAY_SIZE(phba-msix_entries));
if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
0420 PCI enable MSI-X failed (%d)\n, rc);
@@ -8664,15 +8664,13 @@ out:
* @phba: pointer to lpfc hba data structure.
*
* This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-4 interface spec. The kernel function pci_enable_msix() is called
- * to enable the MSI-X vectors. Note that pci_enable_msix(), once invoked,
- * enables either all or nothing, depending on the current availability of
- * PCI vector resources. The device driver is responsible for calling the
- * individual request_irq() to register each MSI-X vector with a interrupt
- * handler, which is done in this function. Note that later when device is
- * unloading, the driver should always call free_irq() on all MSI-X vectors
- * it has done request_irq() on before calling pci_disable_msix(). Failure
- * to do so results in a BUG_ON() and a device will be left with MSI-X
+ * with SLI-4 interface spec. The kernel function pci_enable_msix_range()
+ * is called to enable the MSI-X vectors. The device driver is responsible
+ * for calling the individual request_irq() to register each MSI-X vector
+ * with a interrupt handler, which is done in this function. Note that later
+ * when device is unloading, the driver should always call free_irq() on all
+ * MSI-X vectors it has done request_irq() on before calling pci_disable_msix()
+ * Failure to do so results in a BUG_ON() and a device will be left with MSI-X
* enabled and leaks its vectors.
*
* Return codes
@@ -8694,18 +8692,16 @@ lpfc_sli4_enable_msix(struct lpfc_hba *phba)
phba-sli4_hba.msix_entries[index].entry = index;
vectors++;
}
-enable_msix_vectors:
- rc = pci_enable_msix(phba-pcidev, phba-sli4_hba.msix_entries,
-vectors);
- if (rc 1) {
- vectors = rc;
- goto enable_msix_vectors;
- } else if (rc) {
+
+ rc = pci_enable_msix_range(phba-pcidev, phba-sli4_hba.msix_entries,
+ 2, vectors);
+ if (rc 0) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
0484 PCI enable MSI-X failed (%d)\n, rc);
goto vec_fail_out;
}
+ vectors = rc;
/* Log MSI-X vector assignment */
for (index = 0; index vectors; index++)
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
--
1.7.7.6
--
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 RESEND 11/23] lpfc: Remove superfluous call to pci_disable_msix()
There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: James Smart james.sm...@emulex.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: James Smart james.sm...@emulex.com
---
drivers/scsi/lpfc/lpfc_init.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 635eeb3..7163f37 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8131,7 +8131,7 @@ lpfc_sli_enable_msix(struct lpfc_hba *phba)
if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
0420 PCI enable MSI-X failed (%d)\n, rc);
- goto msi_fail_out;
+ goto vec_fail_out;
}
for (i = 0; i LPFC_MSIX_VECTORS; i++)
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
@@ -8209,6 +8209,8 @@ irq_fail_out:
msi_fail_out:
/* Unconfigure MSI-X capability structure */
pci_disable_msix(phba-pcidev);
+
+vec_fail_out:
return rc;
}
@@ -8701,7 +8703,7 @@ enable_msix_vectors:
} else if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
0484 PCI enable MSI-X failed (%d)\n, rc);
- goto msi_fail_out;
+ goto vec_fail_out;
}
/* Log MSI-X vector assignment */
@@ -8764,9 +8766,10 @@ cfg_fail_out:
phba-sli4_hba.fcp_eq_hdl[index]);
}
-msi_fail_out:
/* Unconfigure MSI-X capability structure */
pci_disable_msix(phba-pcidev);
+
+vec_fail_out:
return rc;
}
--
1.7.7.6
--
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 RESEND 08/23] isci: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Signed-off-by: Alexander Gordeev agord...@redhat.com Cc: Lukasz Dorau lukasz.do...@intel.com Cc: Maciej Patelczyk maciej.patelc...@intel.com Cc: Dave Jiang dave.ji...@intel.com Cc: intel-linux-...@intel.com Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/scsi/isci/init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c index 695b34e..4198e45 100644 --- a/drivers/scsi/isci/init.c +++ b/drivers/scsi/isci/init.c @@ -356,7 +356,7 @@ static int isci_setup_interrupts(struct pci_dev *pdev) for (i = 0; i num_msix; i++) pci_info-msix_entries[i].entry = i; - err = pci_enable_msix(pdev, pci_info-msix_entries, num_msix); + err = pci_enable_msix_exact(pdev, pci_info-msix_entries, num_msix); if (err) goto intx; -- 1.7.7.6 -- 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 RESEND 06/23] csiostor: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Naresh Kumar Inna nar...@chelsio.com
Cc: Arvind Bhushan arvi...@chelsio.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/csiostor/csio_hw.h |2 +-
drivers/scsi/csiostor/csio_isr.c | 22 +-
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 49b1daa..5db2d85 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -94,7 +94,7 @@ enum {
};
struct csio_msix_entries {
- unsigned short vector; /* Vector assigned by pci_enable_msix */
+ unsigned short vector; /* Assigned MSI-X vector */
void*dev_id;/* Priv object associated w/ this msix*/
chardesc[24]; /* Description of this vector */
};
diff --git a/drivers/scsi/csiostor/csio_isr.c b/drivers/scsi/csiostor/csio_isr.c
index 91ba91d..a8c748a 100644
--- a/drivers/scsi/csiostor/csio_isr.c
+++ b/drivers/scsi/csiostor/csio_isr.c
@@ -499,7 +499,7 @@ csio_reduce_sqsets(struct csio_hw *hw, int cnt)
static int
csio_enable_msix(struct csio_hw *hw)
{
- int rv, i, j, k, n, min, cnt;
+ int i, j, k, n, min, cnt;
struct csio_msix_entries *entryp;
struct msix_entry *entries;
int extra = CSIO_EXTRA_VECS;
@@ -521,19 +521,15 @@ csio_enable_msix(struct csio_hw *hw)
csio_dbg(hw, FW supp #niq:%d, trying %d msix's\n, hw-cfg_niq, cnt);
- while ((rv = pci_enable_msix(hw-pdev, entries, cnt)) = min)
- cnt = rv;
- if (!rv) {
- if (cnt (hw-num_sqsets + extra)) {
- csio_dbg(hw, Reducing sqsets to %d\n, cnt - extra);
- csio_reduce_sqsets(hw, cnt - extra);
- }
- } else {
- if (rv 0)
- csio_info(hw, Not using MSI-X, remainder:%d\n, rv);
-
+ cnt = pci_enable_msix_range(hw-pdev, entries, min, cnt);
+ if (cnt 0) {
kfree(entries);
- return -ENOMEM;
+ return cnt;
+ }
+
+ if (cnt (hw-num_sqsets + extra)) {
+ csio_dbg(hw, Reducing sqsets to %d\n, cnt - extra);
+ csio_reduce_sqsets(hw, cnt - extra);
}
/* Save off vectors */
--
1.7.7.6
--
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 RESEND 02/23] bfa: Do not call pci_enable_msix() after it failed once
Function pci_enable_msix() should not be called in case
it threw a negative errno from a previous call.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Anil Gurumurthy aguru...@brocade.com
Cc: Vijaya Mohan Guvva vmo...@brocade.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Anil Gurumurthy anil.gurumur...@qlogic.com
---
drivers/scsi/bfa/bfad.c | 48 ++
1 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index cc0fbcd..972ff8d 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1235,33 +1235,31 @@ bfad_setup_intr(struct bfad_s *bfad)
(bfa_asic_id_cb(pdev-device) !msix_disable_cb)) {
error = pci_enable_msix(bfad-pcidev, msix_entries, bfad-nvec);
- if (error) {
- /* In CT1 CT2, try to allocate just one vector */
- if (bfa_asic_id_ctc(pdev-device)) {
- printk(KERN_WARNING bfa %s: trying one msix
- vector failed to allocate %d[%d]\n,
- bfad-pci_name, bfad-nvec, error);
- bfad-nvec = 1;
- error = pci_enable_msix(bfad-pcidev,
+ /* In CT1 CT2, try to allocate just one vector */
+ if (error 0 bfa_asic_id_ctc(pdev-device)) {
+ printk(KERN_WARNING bfa %s: trying one msix
+ vector failed to allocate %d[%d]\n,
+ bfad-pci_name, bfad-nvec, error);
+ bfad-nvec = 1;
+ error = pci_enable_msix(bfad-pcidev,
msix_entries, bfad-nvec);
- }
+ }
- /*
-* Only error number of vector is available.
-* We don't have a mechanism to map multiple
-* interrupts into one vector, so even if we
-* can try to request less vectors, we don't
-* know how to associate interrupt events to
-* vectors. Linux doesn't duplicate vectors
-* in the MSIX table for this case.
-*/
- if (error) {
- printk(KERN_WARNING bfad%d:
- pci_enable_msix failed (%d),
- use line based.\n,
- bfad-inst_no, error);
- goto line_based;
- }
+ /*
+* Only error number of vector is available.
+* We don't have a mechanism to map multiple
+* interrupts into one vector, so even if we
+* can try to request less vectors, we don't
+* know how to associate interrupt events to
+* vectors. Linux doesn't duplicate vectors
+* in the MSIX table for this case.
+*/
+ if (error) {
+ printk(KERN_WARNING bfad%d:
+ pci_enable_msix failed (%d),
+ use line based.\n,
+ bfad-inst_no, error);
+ goto line_based;
}
/* Disable INTX in MSI-X mode */
--
1.7.7.6
--
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 RESEND 05/23] csiostor: Remove superfluous call to pci_disable_msix()
There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Naresh Kumar Inna nar...@chelsio.com
Cc: Arvind Bhushan arvi...@chelsio.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/csiostor/csio_isr.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_isr.c b/drivers/scsi/csiostor/csio_isr.c
index 7ee9777..91ba91d 100644
--- a/drivers/scsi/csiostor/csio_isr.c
+++ b/drivers/scsi/csiostor/csio_isr.c
@@ -529,10 +529,8 @@ csio_enable_msix(struct csio_hw *hw)
csio_reduce_sqsets(hw, cnt - extra);
}
} else {
- if (rv 0) {
- pci_disable_msix(hw-pdev);
+ if (rv 0)
csio_info(hw, Not using MSI-X, remainder:%d\n, rv);
- }
kfree(entries);
return -ENOMEM;
--
1.7.7.6
--
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 RESEND 04/23] bfa: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Anil Gurumurthy aguru...@brocade.com
Cc: Vijaya Mohan Guvva vmo...@brocade.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/bfa/bfad.c | 20 ++--
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index e7e4774..839c81c 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1234,29 +1234,21 @@ bfad_setup_intr(struct bfad_s *bfad)
if ((bfa_asic_id_ctc(pdev-device) !msix_disable_ct) ||
(bfa_asic_id_cb(pdev-device) !msix_disable_cb)) {
- error = pci_enable_msix(bfad-pcidev, msix_entries, bfad-nvec);
+ error = pci_enable_msix_exact(bfad-pcidev,
+ msix_entries, bfad-nvec);
/* In CT1 CT2, try to allocate just one vector */
- if (error 0 bfa_asic_id_ctc(pdev-device)) {
+ if (error == -ENOSPC bfa_asic_id_ctc(pdev-device)) {
printk(KERN_WARNING bfa %s: trying one msix
vector failed to allocate %d[%d]\n,
bfad-pci_name, bfad-nvec, error);
bfad-nvec = 1;
- error = pci_enable_msix(bfad-pcidev,
- msix_entries, bfad-nvec);
+ error = pci_enable_msix_exact(bfad-pcidev,
+ msix_entries, 1);
}
- /*
-* Only error number of vector is available.
-* We don't have a mechanism to map multiple
-* interrupts into one vector, so even if we
-* can try to request less vectors, we don't
-* know how to associate interrupt events to
-* vectors. Linux doesn't duplicate vectors
-* in the MSIX table for this case.
-*/
if (error) {
printk(KERN_WARNING bfad%d:
- pci_enable_msix failed (%d),
+ pci_enable_msix_exact failed (%d),
use line based.\n,
bfad-inst_no, error);
goto line_based;
--
1.7.7.6
--
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 6/7] blk-mq: split out tag initialization, support shared tags
Add a new blk_mq_tag_set structure that gets set up before we initialize
the queue. A single blk_mq_tag_set structure can be shared by multiple
queues.
Signed-off-by: Christoph Hellwig h...@lst.de
---
block/blk-mq-cpumap.c |6 +-
block/blk-mq-tag.c | 14 ---
block/blk-mq-tag.h | 19 +++-
block/blk-mq.c | 242
block/blk-mq.h |5 +-
drivers/block/null_blk.c | 92 ++---
drivers/block/virtio_blk.c | 48 +
include/linux/blk-mq.h | 34 +++
8 files changed, 260 insertions(+), 200 deletions(-)
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 0979213..5d0f93c 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -80,17 +80,17 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned int
nr_queues)
return 0;
}
-unsigned int *blk_mq_make_queue_map(struct blk_mq_reg *reg)
+unsigned int *blk_mq_make_queue_map(struct blk_mq_tag_set *set)
{
unsigned int *map;
/* If cpus are offline, map them to first hctx */
map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
- reg-numa_node);
+ set-numa_node);
if (!map)
return NULL;
- if (!blk_mq_update_queue_map(map, reg-nr_hw_queues))
+ if (!blk_mq_update_queue_map(map, set-nr_hw_queues))
return map;
kfree(map);
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 83ae96c..7a799c4 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -1,25 +1,11 @@
#include linux/kernel.h
#include linux/module.h
-#include linux/percpu_ida.h
#include linux/blk-mq.h
#include blk.h
#include blk-mq.h
#include blk-mq-tag.h
-/*
- * Per tagged queue (tag address space) map
- */
-struct blk_mq_tags {
- unsigned int nr_tags;
- unsigned int nr_reserved_tags;
- unsigned int nr_batch_move;
- unsigned int nr_max_cache;
-
- struct percpu_ida free_tags;
- struct percpu_ida reserved_tags;
-};
-
void blk_mq_wait_for_tags(struct blk_mq_tags *tags)
{
int tag = blk_mq_get_tag(tags, __GFP_WAIT, false);
diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
index 947ba2c..b602e3f 100644
--- a/block/blk-mq-tag.h
+++ b/block/blk-mq-tag.h
@@ -1,7 +1,24 @@
#ifndef INT_BLK_MQ_TAG_H
#define INT_BLK_MQ_TAG_H
-struct blk_mq_tags;
+#include linux/percpu_ida.h
+
+/*
+ * Tag address space map.
+ */
+struct blk_mq_tags {
+ unsigned int nr_tags;
+ unsigned int nr_reserved_tags;
+ unsigned int nr_batch_move;
+ unsigned int nr_max_cache;
+
+ struct percpu_ida free_tags;
+ struct percpu_ida reserved_tags;
+
+ struct request **rqs;
+ struct list_head page_list;
+};
+
extern struct blk_mq_tags *blk_mq_init_tags(unsigned int nr_tags, unsigned int
reserved_tags, int node);
extern void blk_mq_free_tags(struct blk_mq_tags *tags);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 1cb7618..c3b1810 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -81,7 +81,7 @@ static struct request *__blk_mq_alloc_request(struct
blk_mq_hw_ctx *hctx,
tag = blk_mq_get_tag(hctx-tags, gfp, reserved);
if (tag != BLK_MQ_TAG_FAIL) {
- rq = hctx-rqs[tag];
+ rq = hctx-tags-rqs[tag];
blk_rq_init(hctx-queue, rq);
rq-tag = tag;
@@ -401,6 +401,12 @@ static void blk_mq_requeue_request(struct request *rq)
rq-nr_phys_segments--;
}
+struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags, unsigned int tag)
+{
+ return tags-rqs[tag];
+}
+EXPORT_SYMBOL(blk_mq_tag_to_rq);
+
struct blk_mq_timeout_data {
struct blk_mq_hw_ctx *hctx;
unsigned long *next;
@@ -422,12 +428,13 @@ static void blk_mq_timeout_check(void *__data, unsigned
long *free_tags)
do {
struct request *rq;
- tag = find_next_zero_bit(free_tags, hctx-queue_depth, tag);
- if (tag = hctx-queue_depth)
+ tag = find_next_zero_bit(free_tags, hctx-tags-nr_tags, tag);
+ if (tag = hctx-tags-nr_tags)
break;
- rq = hctx-rqs[tag++];
-
+ rq = blk_mq_tag_to_rq(hctx-tags, tag++);
+ if (rq-q != hctx-queue)
+ continue;
if (!test_bit(REQ_ATOM_STARTED, rq-atomic_flags))
continue;
@@ -947,11 +954,11 @@ struct blk_mq_hw_ctx *blk_mq_map_queue(struct
request_queue *q, const int cpu)
}
EXPORT_SYMBOL(blk_mq_map_queue);
-struct blk_mq_hw_ctx *blk_mq_alloc_single_hw_queue(struct blk_mq_reg *reg,
+struct blk_mq_hw_ctx *blk_mq_alloc_single_hw_queue(struct blk_mq_tag_set *set,
unsigned int hctx_index)
{
return kmalloc_node(sizeof(struct blk_mq_hw_ctx),
-
[PATCH 5/7] blk-mq: initialize request on allocation
If we want to share tag and request allocation between queues we cannot
initialize the request at init/free time, but need to initialize it
at allocation time as it might get used for different queues over its
lifetime.
Signed-off-by: Christoph Hellwig h...@lst.de
---
block/blk-mq.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index ef7acc0..1cb7618 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -82,6 +82,7 @@ static struct request *__blk_mq_alloc_request(struct
blk_mq_hw_ctx *hctx,
tag = blk_mq_get_tag(hctx-tags, gfp, reserved);
if (tag != BLK_MQ_TAG_FAIL) {
rq = hctx-rqs[tag];
+ blk_rq_init(hctx-queue, rq);
rq-tag = tag;
return rq;
@@ -254,9 +255,7 @@ static void __blk_mq_free_request(struct blk_mq_hw_ctx
*hctx,
const int tag = rq-tag;
struct request_queue *q = rq-q;
- blk_rq_init(hctx-queue, rq);
blk_mq_put_tag(hctx-tags, tag);
-
blk_mq_queue_exit(q);
}
@@ -1100,7 +1099,6 @@ static int blk_mq_init_rq_map(struct blk_mq_hw_ctx *hctx,
left -= to_do * rq_size;
for (j = 0; j to_do; j++) {
hctx-rqs[i] = p;
- blk_rq_init(hctx-queue, hctx-rqs[i]);
if (reg-ops-init_request) {
error = reg-ops-init_request(driver_data,
hctx, hctx-rqs[i], i);
--
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
[no subject]
This is the majority of the blk-mq work still required for switching over SCSI. There are a few more bits for I/O completion and requeueing pending, but they will need further work. -- 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] blk-mq: initialize resid_len
Signed-off-by: Christoph Hellwig h...@lst.de --- block/blk-mq.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index 1d2a9bd..c1f4736 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -350,6 +350,8 @@ static void blk_mq_start_request(struct request *rq, bool last) trace_block_rq_issue(q, rq); + rq-resid_len = blk_rq_bytes(rq); + /* * Just mark start time and set the started bit. Due to memory * ordering, we know we'll see the correct deadline as long as -- 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
[PATCH v2 RESEND 03/23] bfa: Cleanup bfad_setup_intr() function
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Anil Gurumurthy aguru...@brocade.com
Cc: Vijaya Mohan Guvva vmo...@brocade.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Anil Gurumurthy anil.gurumur...@qlogic.com
---
drivers/scsi/bfa/bfad.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index 972ff8d..e7e4774 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1219,7 +1219,7 @@ bfad_install_msix_handler(struct bfad_s *bfad)
int
bfad_setup_intr(struct bfad_s *bfad)
{
- int error = 0;
+ int error;
u32 mask = 0, i, num_bit = 0, max_bit = 0;
struct msix_entry msix_entries[MAX_MSIX_ENTRY];
struct pci_dev *pdev = bfad-pcidev;
@@ -1279,20 +1279,18 @@ bfad_setup_intr(struct bfad_s *bfad)
bfad-bfad_flags |= BFAD_MSIX_ON;
- return error;
+ return 0;
}
line_based:
- error = 0;
- if (request_irq
- (bfad-pcidev-irq, (irq_handler_t) bfad_intx, BFAD_IRQ_FLAGS,
-BFAD_DRIVER_NAME, bfad) != 0) {
- /* Enable interrupt handler failed */
- return 1;
- }
+ error = request_irq(bfad-pcidev-irq, (irq_handler_t)bfad_intx,
+ BFAD_IRQ_FLAGS, BFAD_DRIVER_NAME, bfad);
+ if (error)
+ return error;
+
bfad-bfad_flags |= BFAD_INTX_ON;
- return error;
+ return 0;
}
void
--
1.7.7.6
--
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 RESEND 01/23] be2iscsi: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Signed-off-by: Alexander Gordeev agord...@redhat.com Cc: Jayamohan Kallickal jayamohan.kallic...@emulex.com Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org Acked-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com --- drivers/scsi/be2iscsi/be_main.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index 0d82229..279b2f9 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -5282,12 +5282,10 @@ static void beiscsi_msix_enable(struct beiscsi_hba *phba) for (i = 0; i = phba-num_cpus; i++) phba-msix_entries[i].entry = i; - status = pci_enable_msix(phba-pcidev, phba-msix_entries, -(phba-num_cpus + 1)); + status = pci_enable_msix_exact(phba-pcidev, phba-msix_entries, + phba-num_cpus + 1); if (!status) phba-msix_enabled = true; - - return; } /* -- 1.7.7.6 -- 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] blk-mq: make -flush_rq fully transparent to drivers
Drivers shouldn't have to care about the block layer setting aside a
request to implement the flush state machine. We already override the
mq context and tag to make it more transparent, but so far haven't deal
with the driver private data in the request. Make sure to override this
as well, and while we're at it add a proper helper sitting in blk-mq.c
that implements the full impersonation.
Signed-off-by: Christoph Hellwig h...@lst.de
---
block/blk-flush.c | 12 ++--
block/blk-mq.c| 20
block/blk-mq.h|2 ++
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-flush.c
index 9a0c427..b218f61 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -307,16 +307,8 @@ static bool blk_kick_flush(struct request_queue *q)
q-flush_pending_idx ^= 1;
blk_rq_init(q, q-flush_rq);
- if (q-mq_ops) {
- /*
-* Reuse the tag value from the fist waiting request,
-* with blk-mq the tag is generated during request
-* allocation and drivers can rely on it being inside
-* the range they asked for.
-*/
- q-flush_rq-mq_ctx = first_rq-mq_ctx;
- q-flush_rq-tag = first_rq-tag;
- }
+ if (q-mq_ops)
+ blk_mq_clone_flush_request(q-flush_rq, first_rq);
q-flush_rq-cmd_type = REQ_TYPE_FS;
q-flush_rq-cmd_flags = WRITE_FLUSH | REQ_FLUSH_SEQ;
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 747feb9..67859e9 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -272,6 +272,26 @@ void blk_mq_free_request(struct request *rq)
__blk_mq_free_request(hctx, ctx, rq);
}
+/*
+ * Clone all relevant state from a request that has been put on hold in
+ * the flush state machine into the preallocated flush request that hangs
+ * off the request queue.
+ *
+ * For a driver the flush request should be invisible, that's why we are
+ * impersonating the original request here.
+ */
+void blk_mq_clone_flush_request(struct request *flush_rq,
+ struct request *orig_rq)
+{
+ struct blk_mq_hw_ctx *hctx =
+ orig_rq-q-mq_ops-map_queue(orig_rq-q, orig_rq-mq_ctx-cpu);
+
+ flush_rq-mq_ctx = orig_rq-mq_ctx;
+ flush_rq-tag = orig_rq-tag;
+ memcpy(blk_mq_rq_to_pdu(flush_rq), blk_mq_rq_to_pdu(orig_rq),
+ hctx-cmd_size);
+}
+
bool blk_mq_end_io_partial(struct request *rq, int error, unsigned int
nr_bytes)
{
if (blk_update_request(rq, error, blk_rq_bytes(rq)))
diff --git a/block/blk-mq.h b/block/blk-mq.h
index 238379a..7964dad 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -27,6 +27,8 @@ void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool
async);
void blk_mq_init_flush(struct request_queue *q);
void blk_mq_drain_queue(struct request_queue *q);
void blk_mq_free_queue(struct request_queue *q);
+void blk_mq_clone_flush_request(struct request *flush_rq,
+ struct request *orig_rq);
/*
* CPU hotplug helpers
--
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
[PATCH v2 RESEND 00/23] scsi: Use pci_enable_msix_range() instead of pci_enable_msix()
Hello, This series is against 3.15-rc1. As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. There are no major changes in this series since I posted it last time. Thanks! Cc: iss_storage...@hp.com Cc: intel-linux-...@intel.com Cc: supp...@lsi.com Cc: dl-mptfusionli...@lsi.com Cc: qla2xxx-upstr...@qlogic.com Cc: iscsi-dri...@qlogic.com Cc: pv-driv...@vmware.com Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org Alexander Gordeev (23): be2iscsi: Use pci_enable_msix_exact() instead of pci_enable_msix() bfa: Do not call pci_enable_msix() after it failed once bfa: Cleanup bfad_setup_intr() function bfa: Use pci_enable_msix_exact() instead of pci_enable_msix() csiostor: Remove superfluous call to pci_disable_msix() csiostor: Use pci_enable_msix_range() instead of pci_enable_msix() fnic: Use pci_enable_msix_exact() instead of pci_enable_msix() isci: Use pci_enable_msix_exact() instead of pci_enable_msix() hpsa: Fallback to MSI rather than to INTx if MSI-X failed hpsa: Use pci_enable_msix_range() instead of pci_enable_msix() lpfc: Remove superfluous call to pci_disable_msix() lpfc: Use pci_enable_msix_range() instead of pci_enable_msix() megaraid: Fail resume if MSI-X re-initialization failed megaraid: Use pci_enable_msix_range() instead of pci_enable_msix() mpt2sas: Use pci_enable_msix_exact() instead of pci_enable_msix() mpt3sas: Use pci_enable_msix_exact() instead of pci_enable_msix() pm8001: Fix invalid return when request_irq() failed pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix() pmcraid: Get rid of a redundant assignment pmcraid: Use pci_enable_msix_range() instead of pci_enable_msix() qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix() qla4xxx: Use pci_enable_msix_exact() instead of pci_enable_msix() vmw_pvscsi: Use pci_enable_msix_exact() instead of pci_enable_msix() drivers/scsi/be2iscsi/be_main.c |6 +-- drivers/scsi/bfa/bfad.c | 62 - drivers/scsi/csiostor/csio_hw.h |2 +- drivers/scsi/csiostor/csio_isr.c | 24 --- drivers/scsi/fnic/fnic_isr.c |4 +- drivers/scsi/hpsa.c | 30 ++ drivers/scsi/isci/init.c |2 +- drivers/scsi/lpfc/lpfc_init.c | 47 +++--- drivers/scsi/megaraid/megaraid_sas_base.c | 24 +-- drivers/scsi/mpt2sas/mpt2sas_base.c |6 +- drivers/scsi/mpt3sas/mpt3sas_base.c |4 +- drivers/scsi/pm8001/pm8001_init.c | 44 +++-- drivers/scsi/pmcraid.c| 14 +-- drivers/scsi/qla2xxx/qla_isr.c| 27 +--- drivers/scsi/qla4xxx/ql4_nx.c |2 +- drivers/scsi/vmw_pvscsi.c |2 +- 16 files changed, 129 insertions(+), 171 deletions(-) -- 1.7.7.6 -- 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: Vertraulich //
Guten Abend, Ich bin Herr Juan Morato, der Auditor General von Unicaja Bank- Madrid. Im Zuge meiner Abschlussprüfung, entdeckte ich eine schwimmende Fonds auf einem Konto, das 1990 bei der Cam Bank eröffnet wurde, bevor der Besitz von Unicaja Gruppe gekauft wurde, ich bin der Abschlussprüfer der einem toten Ausländer Herr Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede Anstrengung, ein Mitglied seiner Familie oder einen nächsten Angehörigen zu Ermitteln sind gescheitert. Bei meinen Ermittlungen habe ich festgestellt, dass Sie zu den nächsten Angehörigen gehören, da Sie den gleichen Nachnamen tragen. Er verstarb ohne Nachkommen oder einen Testament. Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf ein sicheres Konto zu überweisen. Ich schlage daher vor, dass ich Sie als stillen Teilhaber eintrage und Sie mir ein Konto zur Verfügung stellen, oder ein neues Konto eröffnen um dieses Geld dorthin zu überweisen. Für Ihre Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der verstorbenen Person, entdeckte ich, dass: (1) Niemand dieses Konto seit 2004 betrieben hat (2) Er starb ohne Erben, daher das Geld weiter floss. (3) Keine andere Person über dieses Konto bescheid weiß und auch kein Empfänger eingetragen ist Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld verfallen und anschließend in Gesellschaftsmitteln fließen, von denen nur die Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen ,die auf Ihren Namen zugelassen sind ausfüllen,wobei ich Ihnen selbstverständlich behilflich sein werde. Bitte geben Sie mir eine Antwort auf meine private E -Mail- juan.mora...@1email.eu oder Fax + 34 917 692 656, so dass ich Ihnen detaillierte Informationen über die Modalitäten meines Vorschlages zu senden kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu erreichen sind. Ich freue mich auf Ihre baldige Antwort. Mit freundlichen Grüßen Herr Juan Morato Tel.: + 34 631 178 660 -- 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
[Bug 74011] New: strange observation, the queue depth is (64) meanwhile fw queue depth (65)
https://bugzilla.kernel.org/show_bug.cgi?id=74011 Bug ID: 74011 Summary: strange observation, the queue depth is (64) meanwhile fw queue depth (65) Product: IO/Storage Version: 2.5 Kernel Version: 3.2 to 3.14.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: SCSI Assignee: linux-scsi@vger.kernel.org Reporter: rbli...@gmail.com Regression: No Created attachment 132121 -- https://bugzilla.kernel.org/attachment.cgi?id=132121action=edit System information I get this error on the disk containing the root partition This happens on recent kernels, but not on the 2.6.32.61 kernel. The code generating these messages is however identical in 2.6.32.61 and newer kernels. This doesn't especially happen when the system is under high load. This happens on both our production and stand-by server. Production server was switched back to 2.6.32.61. Attached file contains system information of the stand-by server running kernel 3.14.0 (cpuinfo.txt lspci.txt meminfo.txt proc_scsi_scsi.txt ver_linux.txt). I can provide more info and perform tests if needed. -- You are receiving this mail because: You are the assignee for the bug. -- 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: esp_scsi QTAG in FAS216
Hi Tuomas,
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per
ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
- esp-config2 = 0;
+ esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
- esp-config2 = 0;
- esp_write8(esp-config2, ESP_CFG2);
}
}
}
I'll test these out soon.
Michael, where can I pull the latest version of zorro_esp?
Not sure my patch had ever made it into Geert's m68k-queue - except for
the patch in my previous mail, my zorro_esp.c is still the same as I
got from you in October last year. The project has been on the back
burner for too long ...
I'll look into setting up pull access to my repository. zorro_esp.c as
of today attached for now.
Cheers,
Michael
/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
*
* Copyright (C) 1996 Jesper Skov (js...@cygnus.co.uk)
*
* Copyright (C) 2011 Michael Schmitz (schm...@debian.org) for
* migration to ESP SCSI core
*/
/*
* ZORRO bus code from:
*/
/*
* Detection routine for the NCR53c710 based Amiga SCSI Controllers for Linux.
* Amiga MacroSystemUS WarpEngine SCSI controller.
* Amiga Technologies/DKB A4091 SCSI controller.
*
* Written 1997 by Alan Hourihane al...@fairlite.demon.co.uk
* plus modifications of the 53c7xx.c driver to support the Amiga.
*
* Rewritten to use 53c700.c by Kars de Jong jo...@linux-m68k.org
*/
#include linux/module.h
#include linux/init.h
#include linux/interrupt.h
#include linux/ratelimit.h
#include linux/dma-mapping.h
#include linux/scatterlist.h
#include linux/delay.h
#include linux/zorro.h
#include linux/slab.h
#include asm/page.h
#include asm/pgtable.h
#include asm/cacheflush.h
#include asm/amigahw.h
#include asm/amigaints.h
#include scsi/scsi_host.h
#include scsi/scsi_transport_spi.h
#include scsi/scsi_device.h
#include scsi/scsi_tcq.h
#include esp_scsi.h
MODULE_AUTHOR(Michael Schmitz schm...@debian.org);
MODULE_DESCRIPTION(Amiga Zorro NCR5C9x (ESP) driver);
MODULE_LICENSE(GPL);
#define DMA_WRITE 0x8000
static struct zorro_driver_data {
const char *name;
unsigned long offset;
unsigned long dma_offset;
int absolute;
int zorro3; /* offset is absolute address */
} zorro_esp_driver_data[] = {
{ .name = CyberStormI, .offset = 0xf400, .dma_offset = 0xf800,
.absolute = 0, .zorro3 = 0 },
{ .name = CyberStormII, .offset = 0x1ff03, .dma_offset = 0x1ff43,
.absolute = 0, .zorro3 = 0 },
{ .name = Blizzard 2060, .offset = 0x1ff00, .dma_offset = 0x1ffe0,
.absolute = 0, .zorro3 = 0 },
{ .name = Blizzard 1230, .offset = 0x8000, .dma_offset = 0x1,
.absolute = 0, .zorro3 = 0 },
{ .name = Blizzard 1230II, .offset = 0x1, .dma_offset = 0x10021,
.absolute = 0, .zorro3 = 0 },
{ .name = Fastlane, .offset = 0x101, .dma_offset = 0x141,
.absolute = 0, .zorro3 = 1 },
{ 0 }
};
static struct zorro_device_id zorro_esp_zorro_tbl[] = {
{
.id =
Re: hpsa driver bug crack kernel down!
Hi all,
I guess I found the root cause. It's a bug in matching
device scope, variable 'level' should be decreased when walking up PCI
topology.
Could you please help to test following patch?
Thanks!
Gerry
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index f445c10..1f8308c 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -152,7 +152,7 @@ dmar_alloc_pci_notify_info(struct pci_dev *dev,
unsigned long event)
info-seg = pci_domain_nr(dev-bus);
info-level = level;
if (event == BUS_NOTIFY_ADD_DEVICE) {
- for (tmp = dev, level--; tmp; tmp = tmp-bus-self) {
+ for (tmp = dev, level--; tmp; level--, tmp =
tmp-bus-self) {
info-path[level].device = PCI_SLOT(tmp-devfn);
info-path[level].function = PCI_FUNC(tmp-devfn);
if (pci_is_root_bus(tmp-bus))
On 2014/4/11 0:19, Davidlohr Bueso wrote:
On Thu, 2014-04-10 at 08:46 +, Woodhouse, David wrote:
On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
[+ David, VT-d maintainer ]
Jiang, David, can you please have a look into this issue?
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 602
dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000
That Present bit in context entry is clear fault means that we have
not set up *any* mappings for this PCI device… on this IOMMU.
Yes, specifically (finally done bisecting):
commit 2e45528930388658603ea24d49cf52867b928d3e
Author: Jiang Liu jiang@linux.intel.com
Date: Wed Feb 19 14:07:36 2014 +0800
iommu/vt-d: Unify the way to process DMAR device scope array
This commit is about how we decide which IOMMU a given PCI device is
attached to.
Thus, my first guess would be that we are quite happily setting up the
requested DMA maps on the *wrong* IOMMU, and then taking faults when the
device actually tries to do DMA.
However, I'm not 100% convinced of that. The fault address looks
suspiciously like a true physical address, not a virtual bus address of
the type that we'd normally allocate for a dma_map_* operation. Those
would start at 0xf000 and work downwards, typically.
Do you have 'iommu=pt' on the kernel command line?
No.
Can I see the full
dmesg as this system boots, and also a copy of the DMAR table?
Attaching a dmesg from one of the kernels that boots. It doesn't appear
to have much of the related information... is there any debug config
option I can enable that might give you more data?
--
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: esp_scsi QTAG in FAS216
Hi Dave,
When this bit is set, the 53CF94/96 can receive 3-byte messages
during
bus-initiated Select With ATN. This feature is also enabled by
setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have
unintended side effects. It's just easier to test whether this fixes
our problem.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per
ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
That's what I understood from the bits Kars quoted, yes. And in the
Amiga driver cases, it will always be the 3 byte message feature
controlled by that bit, as far as I can see.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro
driver, thanks,
Michael
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
- esp-config2 = 0;
+ esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
- esp-config2 = 0;
- esp_write8(esp-config2, ESP_CFG2);
}
}
}
--
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: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[ffffffff814c6bc1] [ffffffff814c6bc1] kobject_put+0x11/0x70
On Sat, Apr 12, 2014 at 01:34:31PM +0200, Sander Eikelenboom wrote:
Hi,
I just ran into the oops belowafter some uptime.
Classic use after free introduced by my recent changes, sorry.
This should fix it:
---
From: Christoph Hellwig h...@lst.de
Subject: scsi: don't reference freed command in scsi_init_sgtable
When scsi_init_io fails we have to release our device reference, but
we do this trying to reference the just freed command. Add a local
scsi_device pointer to fix this.
Reported-by: Sander Eikelenboom li...@eikelenboom.it
Signed-off-by: Christoph Hellwig h...@lst.de
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 65a123d..54eff6a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1044,6 +1044,7 @@ static int scsi_init_sgtable(struct request *req, struct
scsi_data_buffer *sdb,
*/
int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
+ struct scsi_device *sdev = cmd-device;
struct request *rq = cmd-request;
int error = scsi_init_sgtable(rq, cmd-sdb, gfp_mask);
@@ -1091,7 +1092,7 @@ err_exit:
scsi_release_buffers(cmd);
cmd-request-special = NULL;
scsi_put_command(cmd);
- put_device(cmd-device-sdev_gendev);
+ put_device(sdev-sdev_gendev);
return error;
}
EXPORT_SYMBOL(scsi_init_io);
--
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
HPSA related kernel panic on boot in 3.15 rc1 on Proliant with P420i
Hi, on P420i (2GB FBWC) with latest(5.22?) FW, and 2 SSD smart path enabled RAID0 arrays (1 and 3 SSD), i get panic on initialization. What is sad, i can't capture complete stack trace and it is deep in kernel worker, but top items are: SA5_performant_intr_mask+0x30/0x30 spin_unlock_irqrestore hpsa_unit_one local_pci_probe ... kthread worker stuff RIP is calc_bucket_map+0x30/0x3a. Anyone got idea what is going on? 3.14 was working fine with exact config, so i suspect it could be HPSA smart path code related. Best regards, Darius. -- 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: HPSA related kernel panic on boot in 3.15 rc1 on Proliant with P420i
After minor googling found vga= option for kernel and managed to capture full stack trace, like i suspected it is HPSA performant mode related. uploaded pic: http://tinypic.com/r/2j68rwx/8 BR, Darius. On Mon, Apr 14, 2014 at 2:33 PM, Darius D. darius@gmail.com wrote: Hi, on P420i (2GB FBWC) with latest(5.22?) FW, and 2 SSD smart path enabled RAID0 arrays (1 and 3 SSD), i get panic on initialization. What is sad, i can't capture complete stack trace and it is deep in kernel worker, but top items are: SA5_performant_intr_mask+0x30/0x30 spin_unlock_irqrestore hpsa_unit_one local_pci_probe ... kthread worker stuff RIP is calc_bucket_map+0x30/0x3a. Anyone got idea what is going on? 3.14 was working fine with exact config, so i suspect it could be HPSA smart path code related. Best regards, Darius. -- 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: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[ffffffff814c6bc1] [ffffffff814c6bc1] kobject_put+0x11/0x70
Monday, April 14, 2014, 1:30:15 PM, you wrote:
On Sat, Apr 12, 2014 at 01:34:31PM +0200, Sander Eikelenboom wrote:
Hi,
I just ran into the oops belowafter some uptime.
Classic use after free introduced by my recent changes, sorry.
This should fix it:
Thx !
---
From: Christoph Hellwig h...@lst.de
Subject: scsi: don't reference freed command in scsi_init_sgtable
When scsi_init_io fails we have to release our device reference, but
we do this trying to reference the just freed command. Add a local
scsi_device pointer to fix this.
Reported-by: Sander Eikelenboom li...@eikelenboom.it
Signed-off-by: Christoph Hellwig h...@lst.de
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 65a123d..54eff6a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1044,6 +1044,7 @@ static int scsi_init_sgtable(struct request *req,
struct scsi_data_buffer *sdb,
*/
int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
+ struct scsi_device *sdev = cmd-device;
struct request *rq = cmd-request;
int error = scsi_init_sgtable(rq, cmd-sdb, gfp_mask);
@@ -1091,7 +1092,7 @@ err_exit:
scsi_release_buffers(cmd);
cmd-request-special = NULL;
scsi_put_command(cmd);
- put_device(cmd-device-sdev_gendev);
+ put_device(sdev-sdev_gendev);
return error;
}
EXPORT_SYMBOL(scsi_init_io);
--
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: HPSA related kernel panic on boot in 3.15 rc1 on Proliant with P420i
Hi,
i've found that patch, but somehow relevant thread was showing only on
http://www.spinics.net/lists/linux-scsi/msg73770.html but not on
marc.info
Anyway, after applying patch, my system passes HPSA initialization,
...but goes boom with unknown FS on block 0,0 error, but it is
probably not related, as somehow i see initrd generated, even if
config was copied from 3.14 where there was non.
http://tinypic.com/r/311qvc3/8
Looking into this problem, but probably not HPSA related, sorry for
repeat bug report.
Thanks for help,
Darius.
On Mon, Apr 14, 2014 at 4:03 PM, scame...@beardog.cce.hp.com wrote:
On Mon, Apr 14, 2014 at 2:33 PM, Darius D. darius@gmail.com wrote:
Hi,
on P420i (2GB FBWC) with latest(5.22?) FW, and 2 SSD smart path
enabled RAID0 arrays (1 and 3 SSD), i get panic on initialization.
What is sad, i can't capture complete stack trace and it is deep in
kernel worker, but top items are:
SA5_performant_intr_mask+0x30/0x30
spin_unlock_irqrestore
hpsa_unit_one
local_pci_probe
... kthread worker stuff
RIP is calc_bucket_map+0x30/0x3a.
Anyone got idea what is going on? 3.14 was working fine with exact
config, so i suspect it could be HPSA smart path code related.
Try the patch below, and see also: http://marc.info/?t=13970113551r=1w=2
-- steve
From f6b44f25c451d32cca5cf2e9825e0636132e69cf Mon Sep 17 00:00:00 2001
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Date: Thu, 10 Apr 2014 16:44:59 -0500
Subject: [PATCH] hpsa: fix uninitialized variable in
hpsa_put_ctlr_into_performant_mode()
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..ef4dfdd 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl((h-cfgtable-TransportSupport));
+ if (!(trans_support PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
--
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] hpsa: fix uninitialized trans_support in hpsa_put_ctlr_into_performant_mode()
Your subject line is very tame. It should be the one line summary of
why we apply the patch, so it should read something like
hpsa: fix NULL deref in performant mode
On Thu, 2014-04-10 at 17:17 -0500, scame...@beardog.cce.hp.com wrote:
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
The description should be more comprehensible.
I'm clear that the use before initialisation is a bug ... I'm less clear
on why it causes an oops.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..ef4dfdd 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl((h-cfgtable-TransportSupport));
+ if (!(trans_support PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
Shouldn't you be moving this check from its previous location, rather
than adding a new one that makes the original obsolete?
James
---
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..9a6e4a2 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl((h-cfgtable-TransportSupport));
+ if (!(trans_support PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
@@ -7479,10 +7483,6 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
}
/* TODO, check that this next line h-nreply_queues is correct */
- trans_support = readl((h-cfgtable-TransportSupport));
- if (!(trans_support PERFORMANT_MODE))
- return;
-
h-nreply_queues = h-msix_vector 0 ? h-msix_vector : 1;
hpsa_get_max_perf_mode_cmds(h);
/* Performant mode ring buffer and supporting data structures */
--
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: hpsa driver bug crack kernel down!
Sorry for the delay, I've been having to take turns for this box. On Fri, 2014-04-11 at 09:18 +, Woodhouse, David wrote: On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote: Attaching a dmesg from one of the kernels that boots. It doesn't appear to have much of the related information... is there any debug config option I can enable that might give you more data? I'd like the contents of /sys/firmware/acpi/tables/DMAR please. Attached is the disassembly of the raw output. And please could you also apply this patch to both the last-working and first-failing kernels and show me the output in both cases? So I still cannot get around getting the info for the first failing kernel, but below is for the last working. Thanks. Device 0:03:00.0 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.1 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.3 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.4 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.4 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.7 [0x7f7ee000 - 0x7f7e] Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff] Device 0:00:1f.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O Device 0:00:00.0 on IOMMU at a800 Device 0:00:01.0 on IOMMU at a800 Device 0:00:02.0 on IOMMU at a800 Device 0:00:03.0 on IOMMU at a800 Device 0:00:04.0 on IOMMU at a800 Device 0:00:05.0 on IOMMU at a800 Device 0:00:06.0 on IOMMU at a800 Device 0:00:07.0 on IOMMU at a800 Device 0:00:08.0 on IOMMU at a800 Device 0:00:09.0 on IOMMU at a800 Device 0:00:0a.0 on IOMMU at a800 Device 0:00:14.0 on IOMMU at a800 Device 0:00:1c.0 on IOMMU at a800 Device 0:00:1c.4 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1e.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 Device 0:04:00.0 on IOMMU at a800 Device 0:04:00.1 on IOMMU at a800 Device 0:04:00.2 on IOMMU at a800 Device 0:04:00.3 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 Device 0:01:03.0 on IOMMU at a800 Device 0:50:00.0 on IOMMU at ac00 Device 0:50:01.0 on IOMMU at ac00 Device 0:50:02.0 on IOMMU at ac00 Device 0:50:03.0 on IOMMU at ac00 Device 0:50:04.0 on IOMMU at ac00 Device 0:50:05.0 on IOMMU at ac00 Device 0:50:06.0 on IOMMU at ac00 Device 0:50:07.0 on IOMMU at ac00 Device 0:50:08.0 on IOMMU at ac00 Device 0:50:09.0 on IOMMU at ac00 Device 0:50:0a.0 on IOMMU at ac00 Device 0:50:14.0 on IOMMU at a800 Device 0:a0:00.0 on IOMMU at b000 Device 0:a0:01.0 on IOMMU at b000 Device 0:a0:02.0 on IOMMU at b000 Device 0:a0:03.0 on IOMMU at b000 Device 0:a0:04.0 on IOMMU at b000 Device 0:a0:05.0 on IOMMU at b000 Device 0:a0:06.0 on IOMMU at b000 Device 0:a0:07.0 on IOMMU at b000 Device 0:a0:08.0 on IOMMU at b000 Device 0:a0:09.0 on IOMMU at b000 Device 0:a0:0a.0 on IOMMU at b000 Device 0:a0:14.0 on IOMMU at a800 Device 0:7c:00.0 on IOMMU at a800 Device 0:7c:08.0 on IOMMU at a800 Device 0:82:00.0 on IOMMU at a800 Device 0:82:08.0 on IOMMU at a800 /* * Intel ACPI Component Architecture * AML Disassembler version 20140325-64 [Apr 11 2014] * Copyright (c) 2000 - 2014 Intel Corporation * * Disassembly of DMAR.raw, Fri Apr 11 09:10:10 2014 * * ACPI Data Table [DMAR] * * Format:
Re: [PATCH] sd: medium access timeout counter fails to reset
On Thu, 2014-04-10 at 11:08 -0400, David Jeffery wrote:
There is an error with the medium access timeout feature of the sd driver. The
sdkp-medium_access_timed_out value is reset to zero in sd_done() in the wrong
place. Currently it is reset to zero only when a command returns sense data.
This can result in cases where the medium access check falsely triggers from
timed out commands which are hours or days apart.
For example, an I/O command times out and is aborted. It then retries and
succeeds. But with no sense data generated and returned, the
medium_access_timed_out value is not reset. If no sd command returns sense
data, then the next command to time out (however far in time from the first
failure) will trigger the medium access timeout and put the device offline.
The resetting of sdkp-medium_access_timed_out should occur before the check
for sense data.
Signed-off-by: David Jeffery djeff...@redhat.com
---
To reproduce using scsi_debug, use SCSI_DEBUG_OPT_TIMEOUT or
SCSI_DEBUG_OPT_MAC_TIMEOUT to force an I/O command to timeout. Then, remove
the opt value so the I/O will succeed on retry. Perform more I/O as desired.
Finally, repeat the process to make a new I/O command time out. Without the
patch, the device will be marked offline even though many I/O commands have
succeeded between the 2 instances of timed out commands.
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 470954a..a41e68e 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1689,12 +1689,12 @@ static int sd_done(struct scsi_cmnd *SCpnt)
sshdr.ascq));
}
#endif
+ sdkp-medium_access_timed_out = 0;
+
if (driver_byte(result) != DRIVER_SENSE
(!sense_valid || sense_deferred))
goto out;
- sdkp-medium_access_timed_out = 0;
-
switch (sshdr.sense_key) {
case HARDWARE_ERROR:
case MEDIUM_ERROR:
--
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
Hey James-
Is there some reason why this patch was never accepted? David posted it
a couple of times last year and Martin ack'ed it, but I don't see it in
your tree, and I don't see any other comments on it.
It seems like something that ought to be fixed.
Reviewed-by: Ewan D. Milne emi...@redhat.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: hpsa driver bug crack kernel down!
Hi Davidlohr, Thanks for providing the DMAR table. According to the DMAR table, one bug in the iommu driver fails to handle this entry: [1D2h 0466 1] Device Scope Entry Type : 01 [1D3h 0467 1] Entry Length : 0A [1D4h 0468 2] Reserved : [1D6h 0470 1] Enumeration ID : 00 [1D7h 0471 1] PCI Bus Number : 00 [1D8h 0472 2] PCI Path : 1C,04 [1DAh 0474 2] PCI Path : 00,02 And the patch sent out by me should fix this bug. Could you please help to have a try? Thanks! Gerry On 2014/4/14 23:45, Davidlohr Bueso wrote: Sorry for the delay, I've been having to take turns for this box. On Fri, 2014-04-11 at 09:18 +, Woodhouse, David wrote: On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote: Attaching a dmesg from one of the kernels that boots. It doesn't appear to have much of the related information... is there any debug config option I can enable that might give you more data? I'd like the contents of /sys/firmware/acpi/tables/DMAR please. Attached is the disassembly of the raw output. And please could you also apply this patch to both the last-working and first-failing kernels and show me the output in both cases? So I still cannot get around getting the info for the first failing kernel, but below is for the last working. Thanks. Device 0:03:00.0 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.1 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.3 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.4 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.4 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.7 [0x7f7ee000 - 0x7f7e] Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff] Device 0:00:1f.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O Device 0:00:00.0 on IOMMU at a800 Device 0:00:01.0 on IOMMU at a800 Device 0:00:02.0 on IOMMU at a800 Device 0:00:03.0 on IOMMU at a800 Device 0:00:04.0 on IOMMU at a800 Device 0:00:05.0 on IOMMU at a800 Device 0:00:06.0 on IOMMU at a800 Device 0:00:07.0 on IOMMU at a800 Device 0:00:08.0 on IOMMU at a800 Device 0:00:09.0 on IOMMU at a800 Device 0:00:0a.0 on IOMMU at a800 Device 0:00:14.0 on IOMMU at a800 Device 0:00:1c.0 on IOMMU at a800 Device 0:00:1c.4 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1e.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 Device 0:04:00.0 on IOMMU at a800 Device 0:04:00.1 on IOMMU at a800 Device 0:04:00.2 on IOMMU at a800 Device 0:04:00.3 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 Device 0:01:03.0 on IOMMU at a800 Device 0:50:00.0 on IOMMU at ac00 Device 0:50:01.0 on IOMMU at ac00 Device 0:50:02.0 on IOMMU at ac00 Device 0:50:03.0 on IOMMU at ac00 Device 0:50:04.0 on IOMMU at ac00 Device 0:50:05.0 on IOMMU at ac00 Device 0:50:06.0 on IOMMU at ac00 Device 0:50:07.0 on IOMMU at ac00 Device 0:50:08.0 on IOMMU at ac00 Device 0:50:09.0 on IOMMU at ac00 Device 0:50:0a.0 on IOMMU at ac00 Device 0:50:14.0 on IOMMU at a800 Device 0:a0:00.0 on IOMMU at b000 Device 0:a0:01.0 on IOMMU at b000 Device 0:a0:02.0 on IOMMU at b000
Re: hpsa driver bug crack kernel down!
On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: Hi Davidlohr, Thanks for providing the DMAR table. According to the DMAR table, one bug in the iommu driver fails to handle this entry: [1D2h 0466 1] Device Scope Entry Type : 01 [1D3h 0467 1] Entry Length : 0A [1D4h 0468 2] Reserved : [1D6h 0470 1] Enumeration ID : 00 [1D7h 0471 1] PCI Bus Number : 00 [1D8h 0472 2] PCI Path : 1C,04 [1DAh 0474 2] PCI Path : 00,02 And the patch sent out by me should fix this bug. Could you please help to have a try? Sorry, I am unable to find any patches from you regarding this issue... I must be missing something. Could you please point me to the lkml link? Thanks. -- 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: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 09:44 -0700, Davidlohr Bueso wrote: On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: Hi Davidlohr, Thanks for providing the DMAR table. According to the DMAR table, one bug in the iommu driver fails to handle this entry: [1D2h 0466 1] Device Scope Entry Type : 01 [1D3h 0467 1] Entry Length : 0A [1D4h 0468 2] Reserved : [1D6h 0470 1] Enumeration ID : 00 [1D7h 0471 1] PCI Bus Number : 00 [1D8h 0472 2] PCI Path : 1C,04 [1DAh 0474 2] PCI Path : 00,02 And the patch sent out by me should fix this bug. Could you please help to have a try? Sorry, I am unable to find any patches from you regarding this issue... I must be missing something. Could you please point me to the lkml link? Never mind, I got it internally. I'll let you know as soon as I can test it later today. -- 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: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 09:47 -0700, Davidlohr Bueso wrote: On Mon, 2014-04-14 at 09:44 -0700, Davidlohr Bueso wrote: On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: Hi Davidlohr, Thanks for providing the DMAR table. According to the DMAR table, one bug in the iommu driver fails to handle this entry: [1D2h 0466 1] Device Scope Entry Type : 01 [1D3h 0467 1] Entry Length : 0A [1D4h 0468 2] Reserved : [1D6h 0470 1] Enumeration ID : 00 [1D7h 0471 1] PCI Bus Number : 00 [1D8h 0472 2] PCI Path : 1C,04 [1DAh 0474 2] PCI Path : 00,02 And the patch sent out by me should fix this bug. Could you please help to have a try? Sorry, I am unable to find any patches from you regarding this issue... I must be missing something. Could you please point me to the lkml link? Never mind, I got it internally. I'll let you know as soon as I can test it later today. Thanks. Jiang, if you can then let me have a copy with a signed-off-by I'll shepherd it upstream along with your other patch which is already in my iommu-2.6.git tree. -- Sent with Evolution's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Re: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 16:57 +0800, Jiang Liu wrote: Hi all, I guess I found the root cause. It's a bug in matching device scope, variable 'level' should be decreased when walking up PCI topology. Could you please help to test following patch? Thanks! Gerry Worked like a charm -- I no longer see all those DMAR messages and the hpsa hard lockup is gone, thanks. Feel free to add my: Reported-and-tested-by: Davidlohr Bueso davidl...@hp.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: [Pv-drivers] [PATCH] VMW_PVSCSI: Fix the issue of DMA-API related warnings.
Hi James,
Could you please help getting this in?
Thanks!
Arvind
- Original Message -
From: Arvind Kumar arvindku...@vmware.com
To: jbottom...@parallels.com, linux-scsi@vger.kernel.org
Cc: pv-driv...@vmware.com, Josh Boyer jwbo...@fedoraproject.org
Sent: Friday, March 21, 2014 11:08:32 AM
Subject: [Pv-drivers] [PATCH] VMW_PVSCSI: Fix the issue of DMA-API related
warnings.
The driver is missing calls to pci_dma_mapping_error() after
performing the DMA mapping, which caused DMA-API warning to
show up in dmesg's output. Though that happens only when
DMA_API_DEBUG option is enabled. This change fixes the issue
and makes pvscsi_map_buffers() function more robust.
Signed-off-by: Arvind Kumar arvindku...@vmware.com
Cc: Josh Boyer jwbo...@fedoraproject.org
---
drivers/scsi/vmw_pvscsi.c | 45 +++--
drivers/scsi/vmw_pvscsi.h |2 +-
2 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index c88e146..9478a00 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -349,9 +349,9 @@ static void pvscsi_create_sg(struct pvscsi_ctx *ctx,
* Map all data buffers for a command into PCI space and
* setup the scatter/gather list if needed.
*/
-static void pvscsi_map_buffers(struct pvscsi_adapter *adapter,
- struct pvscsi_ctx *ctx, struct scsi_cmnd *cmd,
- struct PVSCSIRingReqDesc *e)
+static int pvscsi_map_buffers(struct pvscsi_adapter *adapter,
+ struct pvscsi_ctx *ctx, struct scsi_cmnd *cmd,
+ struct PVSCSIRingReqDesc *e)
{
unsigned count;
unsigned bufflen = scsi_bufflen(cmd);
@@ -360,18 +360,30 @@ static void pvscsi_map_buffers(struct pvscsi_adapter
*adapter,
e-dataLen = bufflen;
e-dataAddr = 0;
if (bufflen == 0)
- return;
+ return 0;
sg = scsi_sglist(cmd);
count = scsi_sg_count(cmd);
if (count != 0) {
int segs = scsi_dma_map(cmd);
- if (segs 1) {
+
+ if (segs == -ENOMEM) {
+ scmd_printk(KERN_ERR, cmd,
+ vmw_pvscsi: Failed to map cmd sglist for
DMA.\n);
+ return -1;
+ } else if (segs 1) {
pvscsi_create_sg(ctx, sg, segs);
e-flags |= PVSCSI_FLAG_CMD_WITH_SG_LIST;
ctx-sglPA = pci_map_single(adapter-dev, ctx-sgl,
SGL_SIZE, PCI_DMA_TODEVICE);
+ if (pci_dma_mapping_error(adapter-dev, ctx-sglPA)) {
+ scmd_printk(KERN_ERR, cmd,
+ vmw_pvscsi: Failed to map ctx
sglist for DMA.\n);
+ scsi_dma_unmap(cmd);
+ ctx-sglPA = 0;
+ return -1;
+ }
e-dataAddr = ctx-sglPA;
} else
e-dataAddr = sg_dma_address(sg);
@@ -382,8 +394,15 @@ static void pvscsi_map_buffers(struct pvscsi_adapter
*adapter,
*/
ctx-dataPA = pci_map_single(adapter-dev, sg, bufflen,
cmd-sc_data_direction);
+ if (pci_dma_mapping_error(adapter-dev, ctx-dataPA)) {
+ scmd_printk(KERN_ERR, cmd,
+ vmw_pvscsi: Failed to map direct data
buffer for DMA.\n);
+ return -1;
+ }
e-dataAddr = ctx-dataPA;
}
+
+ return 0;
}
static void pvscsi_unmap_buffers(const struct pvscsi_adapter *adapter,
@@ -712,6 +731,12 @@ static int pvscsi_queue_ring(struct pvscsi_adapter
*adapter,
ctx-sensePA = pci_map_single(adapter-dev, cmd-sense_buffer,
SCSI_SENSE_BUFFERSIZE,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(adapter-dev, ctx-sensePA)) {
+ scmd_printk(KERN_ERR, cmd,
+ vmw_pvscsi: Failed to map sense buffer for
DMA.\n);
+ ctx-sensePA = 0;
+ return -1;
+ }
e-senseAddr = ctx-sensePA;
e-senseLen = SCSI_SENSE_BUFFERSIZE;
} else {
@@ -737,7 +762,15 @@ static int pvscsi_queue_ring(struct pvscsi_adapter
*adapter,
else
e-flags = 0;
- pvscsi_map_buffers(adapter, ctx, cmd, e);
+ if (pvscsi_map_buffers(adapter, ctx, cmd, e) != 0) {
+ if (cmd-sense_buffer) {
+ pci_unmap_single(adapter-dev, ctx-sensePA,
+SCSI_SENSE_BUFFERSIZE,
+
Re: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[ffffffff814c6bc1] [ffffffff814c6bc1] kobject_put+0x11/0x70
On Mon, Apr 14, 2014 at 02:57:00PM -0400, Joe Lawrence wrote: I hit a similar crash last week on a franken-kernel here (3.14 + scsi misc + qlogic patches + out of tree drivers + terriblethingsIknow). I think there is one other similar use-after-free that's been in place for a while now: Yes, that looks the same. I'll fix it and prepare a patch that consolidates this duplicate code while at it. -- 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] hpsa: fix NULL dereference in hpsa_put_ctlr_into_performant_mode()
Initialize local variable trans_support before it is used rather
than after. It is supposed to contain the value of a register on the
controller containing bits that describe which transport modes the
controller supports (e.g. performant, ioaccel1, ioaccel2). A
NULL pointer dereference will almost certainly occur if trans_support
is not initialized at the right point. If for example the uninitialized
trans_support value does not have the bit set for ioaccel2 support when it
should be, then ioaccel2_alloc_cmds_and_bft() will not get called as it
should be and the h-ioaccel2_blockFetchTable array will remain NULL
instead of being allocated. Too late, trans_support finally gets
initialized with the correct value with ioaccel2 mode bit set,
which later causes calc_bucket_map() to be called to fill in
h-ioaccel2_blockFetchTable[]. However h-ioaccel2_blockFetchTable
is NULL because it didn't get allocated because earlier trans_support
wasn't initialized at the right point.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..9a6e4a2 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl((h-cfgtable-TransportSupport));
+ if (!(trans_support PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
@@ -7479,10 +7483,6 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
}
/* TODO, check that this next line h-nreply_queues is correct */
- trans_support = readl((h-cfgtable-TransportSupport));
- if (!(trans_support PERFORMANT_MODE))
- return;
-
h-nreply_queues = h-msix_vector 0 ? h-msix_vector : 1;
hpsa_get_max_perf_mode_cmds(h);
/* Performant mode ring buffer and supporting data structures */
--
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: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[ffffffff814c6bc1] [ffffffff814c6bc1] kobject_put+0x11/0x70
On Mon, 14 Apr 2014 04:30:15 -0700
Christoph Hellwig h...@infradead.org wrote:
On Sat, Apr 12, 2014 at 01:34:31PM +0200, Sander Eikelenboom wrote:
Hi,
I just ran into the oops belowafter some uptime.
Classic use after free introduced by my recent changes, sorry.
This should fix it:
---
From: Christoph Hellwig h...@lst.de
Subject: scsi: don't reference freed command in scsi_init_sgtable
When scsi_init_io fails we have to release our device reference, but
we do this trying to reference the just freed command. Add a local
scsi_device pointer to fix this.
Reported-by: Sander Eikelenboom li...@eikelenboom.it
Signed-off-by: Christoph Hellwig h...@lst.de
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 65a123d..54eff6a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1044,6 +1044,7 @@ static int scsi_init_sgtable(struct request *req,
struct scsi_data_buffer *sdb,
*/
int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
+ struct scsi_device *sdev = cmd-device;
struct request *rq = cmd-request;
int error = scsi_init_sgtable(rq, cmd-sdb, gfp_mask);
@@ -1091,7 +1092,7 @@ err_exit:
scsi_release_buffers(cmd);
cmd-request-special = NULL;
scsi_put_command(cmd);
- put_device(cmd-device-sdev_gendev);
+ put_device(sdev-sdev_gendev);
return error;
}
EXPORT_SYMBOL(scsi_init_io);
Hi Christoph,
I hit a similar crash last week on a franken-kernel here (3.14 + scsi
misc + qlogic patches + out of tree drivers + terriblethingsIknow). I
think there is one other similar use-after-free that's been in place
for a while now:
int scsi_prep_return(struct request_queue *q, struct request *req, int ret)
{
struct scsi_device *sdev = q-queuedata;
switch (ret) {
case BLKPREP_KILL:
req-errors = DID_NO_CONNECT 16;
/* release the command and kill it */
if (req-special) {
struct scsi_cmnd *cmd = req-special;
scsi_release_buffers(cmd);
scsi_put_command(cmd);
put_device(cmd-device-sdev_gendev);
req-special = NULL;
}
break;
...
and the backtrace looked like:
general protection fault: [#1] SMP
Modules linked in: ccmod(POF) ftmod(OF) ipmi_devintf ipmi_msghandler bonding sg
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel ixgbe(OF) aesni_intel igb(OF) ptp lrw pps_core gf128mul
glue_helper i2c_algo_bit mdio ablk_helper cryptd pcspkr dca ntb i2c_core
matroxfb(OF) videosw(OF) nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c
dm_service_time sd_mod(OF) crc_t10dif crct10dif_common qla2xxx(OF)
scsi_transport_fc mpt2sas(OF) raid_class scsi_tgt scsi_transport_sas dm_mirror
dm_region_hash dm_log dm_multipath dm_mod
CPU: 8 PID: 23976 Comm: systemd-udevd Tainted: PF W O 3.14.0+ #2
Hardware name: Stratus ftServer 6400/G7LAY, BIOS BIOS Version 6.3:57 12/25/2013
task: 880420b3d7c0 ti: 880729138000 task.ti: 880729138000
RIP: 0010:[812e2a2d] [812e2a2d] kobject_put+0xd/0x60
RSP: 0018:880729139a80 EFLAGS: 00010002
RAX: RBX: 6b6b6b6b6b6b6ce3 RCX: 0001002e0003
RDX: 002e RSI: ea0021370400 RDI: 6b6b6b6b6b6b6ce3
RBP: 880729139a88 R08: 88084dc16300 R09: 0001002e0002
R10: 88104f603a80 R11: ea0021370400 R12: 88084dc16300
R13: 0001 R14: 881026935388 R15: 880ff56b3a18
FS: 7f2eed940880() GS:88085fd0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f2eed0e2c20 CR3: 00084d6c8000 CR4: 000407e0
Stack:
88076248d0a8 880729139a98 813e57d7 880729139ac0
8141bf3e 00018141be66 88076248d0a8 88104def6840
880729139b20 a00a46e0 88104def6840 88076248d0a8
Call Trace:
[813e57d7] put_device+0x17/0x20
[8141bf3e] scsi_prep_return+0x9e/0xc0
[a00a46e0] sd_prep_fn+0x70/0xcd0 [sd_mod]
[812bb49f] blk_peek_request+0x12f/0x250
[8141cdf8] scsi_request_fn+0x48/0x570
[812b66f3] __blk_run_queue+0x33/0x40
[812b67aa] queue_unplugged+0x2a/0xa0
[812bb928] blk_flush_plug_list+0x1d8/0x230
[812bbd14] blk_finish_plug+0x14/0x40
[8116b239] __do_page_cache_readahead+0x209/0x290
[8116b52d] force_page_cache_readahead+0x6d/0xa0
[8116b843] page_cache_sync_readahead+0x43/0x50
[81161b35] generic_file_aio_read+0x4f5/0x720
[8120dc2b] blkdev_aio_read+0x4b/0x70
[811d27e7] do_sync_read+0x67/0xa0
[811d2efb] vfs_read+0x9b/0x160
[811d3a05] SyS_read+0x55/0xd0
[81637aa9] system_call_fastpath+0x16/0x1b
Regards,
-- Joe
--
To unsubscribe from this list: send
Re: [PATCH RESEND 2] mvsas: Recognise device/subsystem 9485/9485 as 88SE9485
On Wed, 2014-02-19 at 01:06 +, Ben Hutchings wrote:
Matt Taggart reported that mvsas didn't bind to the Marvell
SAS controller on a Supermicro AOC-SAS2LP-MV8 board.
lspci reports it as:
01:00.0 RAID bus controller [0104]: Marvell Technology Group Ltd. Device
[1b4b:9485] (rev 03)
Subsystem: Marvell Technology Group Ltd. Device [1b4b:9485]
[...]
Add it to the device table as chip_9485.
Adding Marvell maintainer to cc. Can we get an ack on this ... or is
mvsas dead and I can just apply it anyway?
Thanks,
James
Reported-by: Matt Taggart tagg...@debian.org
Tested-by: Matt Taggart tagg...@debian.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/scsi/mvsas/mv_init.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 7b7381d..83fa5f8 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -729,6 +729,15 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9485,
},
+ {
+ .vendor = PCI_VENDOR_ID_MARVELL_EXT,
+ .device = 0x9485,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = 0x9485,
+ .class = 0,
+ .class_mask = 0,
+ .driver_data= chip_9485,
+ },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4
(exact model unknown) */
--
Ben Hutchings
One of the nice things about standards is that there are so many of them.
--
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
