Re: [PATCH 1/4] mpt3sas: Added print to notify cable running at a degraded speed.
On Thu, Jan 19, 2017 at 09:19:07PM +0530, Chaitra P B wrote: > Driver processes the event MPI26_EVENT_ACTIVE_CABLE_DEGRADED > when a cable is present and is running at a degraded speed > (below the SAS3 12 Gb/s rate). Prints added > to inform the user that the cable is not running at > optimal speed. > > Signed-off-by: Chaitra P B > Suganath Prabu Missing Signed-off-by for Suganath. > --- > drivers/scsi/mpt3sas/mpi/mpi2_ioc.h |2 ++ > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 18 +- > 2 files changed, 15 insertions(+), 5 deletions(-) Otherwise, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] mpt3sas driver Enhancements and
On Thu, Jan 19, 2017 at 09:19:06PM +0530, Chaitra P B wrote: > Here is the change list: > Posting 4 patches for mpt3sas driver enhancement and defect fixes. > * Handle cable event for notifying degraded speed. > * Performance improvement for Crusader. > * Fix Firmware fault state 0x2100 during heavy 4K RR > FIO stress test. > * Updated driver version to 15.100.00.00 > > Chaitra P B (4): > mpt3sas: Added print to notify cable running at a degraded > speed. > mpt3sas: Fix for Crusader to achieve product targets with SAS > devices. > mpt3sas: Fix Firmware fault state 0x2100 during heavy 4K RR FIO > stress test. > mpt3sas: Bump driver version to 15.100.00.00 > > drivers/scsi/mpt3sas/mpi/mpi2_ioc.h |2 + > drivers/scsi/mpt3sas/mpt3sas_base.c | 20 ++ > drivers/scsi/mpt3sas/mpt3sas_base.h |7 +++-- > drivers/scsi/mpt3sas/mpt3sas_ctl.c |4 ++- > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 47 + > 5 files changed, 70 insertions(+), 10 deletions(-) Please be sure you have appropriate Signed-off-by lines on all of your patches, thanks. -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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 2/2] scsi: storvsc: Add support for FC lightweight host.
On Thu, Jan 19, 2017 at 12:55:27PM -0500, Cathy Avery wrote:
>
>
> On 01/18/2017 06:15 PM, Dan Carpenter wrote:
> >On Wed, Jan 18, 2017 at 03:28:58PM -0500, Cathy Avery wrote:
> >>Enable FC lightweight host option so that the luns exposed by
> >>the driver may be manually scanned.
> >>
> >>Signed-off-by: Cathy Avery
> >>---
> >> drivers/scsi/storvsc_drv.c | 6 +-
> >> 1 file changed, 1 insertion(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> >>index 888e16e..fc1d6ba 100644
> >>--- a/drivers/scsi/storvsc_drv.c
> >>+++ b/drivers/scsi/storvsc_drv.c
> >>@@ -1882,6 +1882,7 @@ static struct hv_driver storvsc_drv = {
> >> static struct fc_function_template fc_transport_functions = {
> >>.show_host_node_name = 1,
> >>.show_host_port_name = 1,
> >>+ .lightweight_transport = 1,
> >> };
> >> #endif
> >>@@ -1906,11 +1907,6 @@ static int __init storvsc_drv_init(void)
> >>fc_transport_template = fc_attach_transport(&fc_transport_functions);
> >>if (!fc_transport_template)
> >>return -ENODEV;
> >>-
> >>- /*
> >>-* Install Hyper-V specific timeout handler.
> >>-*/
> >>- fc_transport_template->eh_timed_out = storvsc_eh_timed_out;
> >I don't undestand how removing this is related.
>
> Its not related but it is also not necessary so I took it out. The
> default scsi timeout handler will be used.
>
> I can certainly put it back.
I'm not sure that we understand each other properly.
Has this patch already been committed? If so, then there is no need to
put it back.
But it if hasn't been committed, can you resend the patches with that
bit broken out into a separate patch with its own changelog? Patches
should only do one thing but you're saying that it's doing two
unrelated things.
regards,
dan carpenter
--
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 7/7] scsi: hisi_sas: decrease running_req in hisi_sas_slot_task_free()
From: Xiang Chen
There is an issue that hisi_sas_dev.running_req is not
decremented properly for internal abort and TMF.
To resolve, only decrease running_req in hisi_sas_slot_task_free()
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 8
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 2 --
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 8601cec..53637a9 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -71,6 +71,8 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba,
struct sas_task *task,
struct hisi_sas_slot *slot)
{
struct device *dev = &hisi_hba->pdev->dev;
+ struct domain_device *device = task->dev;
+ struct hisi_sas_device *sas_dev = device->lldd_dev;
if (!slot->task)
return;
@@ -97,6 +99,8 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba,
struct sas_task *task,
slot->task = NULL;
slot->port = NULL;
hisi_sas_slot_index_free(hisi_hba, slot->idx);
+ if (sas_dev)
+ atomic64_dec(&sas_dev->running_req);
/* slot memory is fully zeroed when it is reused */
}
EXPORT_SYMBOL_GPL(hisi_sas_slot_task_free);
@@ -141,8 +145,6 @@ static void hisi_sas_slot_abort(struct work_struct *work)
struct hisi_hba *hisi_hba = dev_to_hisi_hba(task->dev);
struct scsi_cmnd *cmnd = task->uldd_task;
struct hisi_sas_tmf_task tmf_task;
- struct domain_device *device = task->dev;
- struct hisi_sas_device *sas_dev = device->lldd_dev;
struct scsi_lun lun;
struct device *dev = &hisi_hba->pdev->dev;
int tag = abort_slot->idx;
@@ -165,8 +167,6 @@ static void hisi_sas_slot_abort(struct work_struct *work)
spin_unlock_irqrestore(&hisi_hba->lock, flags);
if (task->task_done)
task->task_done(task);
- if (sas_dev)
- atomic64_dec(&sas_dev->running_req);
}
static int hisi_sas_task_prep(struct sas_task *task, struct hisi_hba *hisi_hba,
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 9e16f42..1b21445 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1830,8 +1830,6 @@ static void slot_err_v2_hw(struct hisi_hba *hisi_hba,
}
out:
- if (sas_dev)
- atomic64_dec(&sas_dev->running_req);
hisi_sas_slot_task_free(hisi_hba, task, slot);
sts = ts->stat;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] scsi: hisi_sas: fix probe ordering problem
From: Xiang Chen
There is a potential probe issue in how we trigger the hw initialisation.
Although we use 1s timer to delay hw initialisation, there is still a
potential that sas_register_ha() is not be finished before we start
the PHY init from hw->hw_init().
To avoid this issue, initialise the hw after sas_register_ha() in the
same probe context.
Note: it is not necessary to use 1s timer now (modified v2 hw only).
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 8
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 8 ++--
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index b2782ce..8601cec 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -1552,10 +1552,6 @@ int hisi_sas_probe(struct platform_device *pdev,
hisi_sas_init_add(hisi_hba);
- rc = hisi_hba->hw->hw_init(hisi_hba);
- if (rc)
- goto err_out_ha;
-
rc = scsi_add_host(shost, &pdev->dev);
if (rc)
goto err_out_ha;
@@ -1564,6 +1560,10 @@ int hisi_sas_probe(struct platform_device *pdev,
if (rc)
goto err_out_register_ha;
+ rc = hisi_hba->hw->hw_init(hisi_hba);
+ if (rc)
+ goto err_out_register_ha;
+
scsi_scan_host(shost);
return 0;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 2e776b7..9e16f42 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1093,9 +1093,8 @@ static void phy_hard_reset_v2_hw(struct hisi_hba
*hisi_hba, int phy_no)
start_phy_v2_hw(hisi_hba, phy_no);
}
-static void start_phys_v2_hw(unsigned long data)
+static void start_phys_v2_hw(struct hisi_hba *hisi_hba)
{
- struct hisi_hba *hisi_hba = (struct hisi_hba *)data;
int i;
for (i = 0; i < hisi_hba->n_phy; i++)
@@ -1104,10 +1103,7 @@ static void start_phys_v2_hw(unsigned long data)
static void phys_init_v2_hw(struct hisi_hba *hisi_hba)
{
- struct timer_list *timer = &hisi_hba->timer;
-
- setup_timer(timer, start_phys_v2_hw, (unsigned long)hisi_hba);
- mod_timer(timer, jiffies + HZ);
+ start_phys_v2_hw(hisi_hba);
}
static void sl_notify_v2_hw(struct hisi_hba *hisi_hba, int phy_no)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] scsi: hisi_sas: modify hard reset for directed-attached disk
From: Xiang Chen
Correctly set registers in v2 for root PHY hardreset for directly
attached disk.
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 93fceda..2e776b7 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -207,6 +207,8 @@
#define TXID_AUTO (PORT_BASE + 0xb8)
#define TXID_AUTO_CT3_OFF 1
#define TXID_AUTO_CT3_MSK (0x1 << TXID_AUTO_CT3_OFF)
+#define TX_HARDRST_OFF 2
+#define TX_HARDRST_MSK (0x1 << TX_HARDRST_OFF)
#define RX_IDAF_DWORD0 (PORT_BASE + 0xc4)
#define RX_IDAF_DWORD1 (PORT_BASE + 0xc8)
#define RX_IDAF_DWORD2 (PORT_BASE + 0xcc)
@@ -1078,7 +1080,15 @@ static void stop_phy_v2_hw(struct hisi_hba *hisi_hba,
int phy_no)
static void phy_hard_reset_v2_hw(struct hisi_hba *hisi_hba, int phy_no)
{
+ struct hisi_sas_phy *phy = &hisi_hba->phy[phy_no];
+ u32 txid_auto;
+
stop_phy_v2_hw(hisi_hba, phy_no);
+ if (phy->identify.device_type == SAS_END_DEVICE) {
+ txid_auto = hisi_sas_phy_read32(hisi_hba, phy_no, TXID_AUTO);
+ hisi_sas_phy_write32(hisi_hba, phy_no, TXID_AUTO,
+ txid_auto | TX_HARDRST_MSK);
+ }
msleep(100);
start_phy_v2_hw(hisi_hba, phy_no);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] scsi: hisi_sas: workaround v2 hw SATA IO timeout issue
From: Xiang Chen
The v2 SAS controller needs more time to detect channel idle
and send setup link request than SATA disk does, so it is
difficult for the SAS controller to setup an STP link. Therefore
it may cause some IO timeouts.
We need to periodically configure the SAS controller so it
doesn't receive STP setup requests from SATA disks for a while,
so IO can be sent during this period.
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 75 +-
1 file changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 69b0f06..6c787eb 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -215,6 +215,7 @@
#define RX_IDAF_DWORD5 (PORT_BASE + 0xd8)
#define RX_IDAF_DWORD6 (PORT_BASE + 0xdc)
#define RXOP_CHECK_CFG_H (PORT_BASE + 0xfc)
+#define CON_CONTROL(PORT_BASE + 0x118)
#define DONE_RECEIVED_TIME (PORT_BASE + 0x11c)
#define CHL_INT0 (PORT_BASE + 0x1b4)
#define CHL_INT0_HOTPLUG_TOUT_OFF 0
@@ -526,6 +527,8 @@ enum {
#define SATA_PROTOCOL_FPDMA0x8
#define SATA_PROTOCOL_ATAPI0x10
+static void hisi_sas_link_timeout_disable_link(unsigned long data);
+
static u32 hisi_sas_read32(struct hisi_hba *hisi_hba, u32 off)
{
void __iomem *regs = hisi_hba->regs + off;
@@ -978,6 +981,50 @@ static void init_reg_v2_hw(struct hisi_hba *hisi_hba)
upper_32_bits(hisi_hba->initial_fis_dma));
}
+static void hisi_sas_link_timeout_enable_link(unsigned long data)
+{
+ struct hisi_hba *hisi_hba = (struct hisi_hba *)data;
+ int i, reg_val;
+
+ for (i = 0; i < hisi_hba->n_phy; i++) {
+ reg_val = hisi_sas_phy_read32(hisi_hba, i, CON_CONTROL);
+ if (!(reg_val & BIT(0))) {
+ hisi_sas_phy_write32(hisi_hba, i,
+ CON_CONTROL, 0x7);
+ break;
+ }
+ }
+
+ hisi_hba->timer.function = hisi_sas_link_timeout_disable_link;
+ mod_timer(&hisi_hba->timer, jiffies + msecs_to_jiffies(900));
+}
+
+static void hisi_sas_link_timeout_disable_link(unsigned long data)
+{
+ struct hisi_hba *hisi_hba = (struct hisi_hba *)data;
+ int i, reg_val;
+
+ reg_val = hisi_sas_read32(hisi_hba, PHY_STATE);
+ for (i = 0; i < hisi_hba->n_phy && reg_val; i++) {
+ if (reg_val & BIT(i)) {
+ hisi_sas_phy_write32(hisi_hba, i,
+ CON_CONTROL, 0x6);
+ break;
+ }
+ }
+
+ hisi_hba->timer.function = hisi_sas_link_timeout_enable_link;
+ mod_timer(&hisi_hba->timer, jiffies + msecs_to_jiffies(100));
+}
+
+static void set_link_timer_quirk(struct hisi_hba *hisi_hba)
+{
+ hisi_hba->timer.data = (unsigned long)hisi_hba;
+ hisi_hba->timer.function = hisi_sas_link_timeout_disable_link;
+ hisi_hba->timer.expires = jiffies + msecs_to_jiffies(1000);
+ add_timer(&hisi_hba->timer);
+}
+
static int hw_init_v2_hw(struct hisi_hba *hisi_hba)
{
struct device *dev = &hisi_hba->pdev->dev;
@@ -2020,9 +2067,12 @@ static int phy_up_v2_hw(int phy_no, struct hisi_hba
*hisi_hba)
if (phy->identify.device_type == SAS_END_DEVICE)
phy->identify.target_port_protocols =
SAS_PROTOCOL_SSP;
- else if (phy->identify.device_type != SAS_PHY_UNUSED)
+ else if (phy->identify.device_type != SAS_PHY_UNUSED) {
phy->identify.target_port_protocols =
SAS_PROTOCOL_SMP;
+ if (!timer_pending(&hisi_hba->timer))
+ set_link_timer_quirk(hisi_hba);
+ }
queue_work(hisi_hba->wq, &phy->phyup_ws);
end:
@@ -2033,10 +2083,23 @@ static int phy_up_v2_hw(int phy_no, struct hisi_hba
*hisi_hba)
return res;
}
+static bool check_any_wideports_v2_hw(struct hisi_hba *hisi_hba)
+{
+ u32 port_state;
+
+ port_state = hisi_sas_read32(hisi_hba, PORT_STATE);
+ if (port_state & 0x1ff)
+ return true;
+
+ return false;
+}
+
static int phy_down_v2_hw(int phy_no, struct hisi_hba *hisi_hba)
{
int res = 0;
u32 phy_state, sl_ctrl, txid_auto;
+ struct hisi_sas_phy *phy = &hisi_hba->phy[phy_no];
+ struct hisi_sas_port *port = phy->port;
hisi_sas_phy_write32(hisi_hba, phy_no, PHYCTRL_NOT_RDY_MSK, 1);
@@ -2046,6 +2109,10 @@ static int phy_down_v2_hw(int phy_no, struct hisi_hba
*hisi_hba)
sl_ctrl = hisi_sas_phy_read32(hisi_hba, phy_no, SL_CONTROL);
hisi_sas_phy_write32(hisi_hba, phy_no, SL_CONTROL,
sl_ctrl & ~SL_CONTROL_CTA_MSK);
+ if (
[PATCH v2 0/7] hisi_sas: SATA IO workaround and other misc patches
This patchset introduces some misc fixes and improvements. Most signifigantly this patchset includes a workaround for a SATA IO issue on v2 hw (hip06/7). Differences v1->v2: - Add macro for SMP TIMEOUT in ITCT struct John Garry (2): scsi: hisi_sas: downgrade refclk message scsi: hisi_sas: downgrade internal abort exit print Xiang Chen (5): scsi: hisi_sas: workaround v2 hw SATA IO timeout issue scsi: hisi_sas: modify some values of ITCT table scsi: hisi_sas: modify hard reset for directed-attached disk scsi: hisi_sas: fix probe ordering problem scsi: hisi_sas: decrease running_req in hisi_sas_slot_task_free() drivers/scsi/hisi_sas/hisi_sas_main.c | 20 +++--- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 109 + 2 files changed, 106 insertions(+), 23 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] scsi: hisi_sas: downgrade refclk message
The message to inform that the controller has no refclk is currently at warning level, which is unnecessary, so downgrade to debug. Signed-off-by: John Garry Reviewed-by: Xiang Chen Reviewed-by: Johannes Thumshirn --- drivers/scsi/hisi_sas/hisi_sas_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index 22dba01..eee7ae2 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -1453,7 +1453,7 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct platform_device *pdev, refclk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(refclk)) - dev_info(dev, "no ref clk property\n"); + dev_dbg(dev, "no ref clk property\n"); else hisi_hba->refclk_frequency_mhz = clk_get_rate(refclk) / 100; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] scsi: hisi_sas: modify some values of ITCT table
From: Xiang Chen
Set SMP connection timeout and continue AWT timer;
Clear ITCT table when dev gone.
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 6c787eb..93fceda 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -334,6 +334,11 @@
#define ITCT_HDR_MCR_MSK (0xf << ITCT_HDR_MCR_OFF)
#define ITCT_HDR_VLN_OFF 9
#define ITCT_HDR_VLN_MSK (0xf << ITCT_HDR_VLN_OFF)
+#define ITCT_HDR_SMP_TIMEOUT_OFF 16
+#define ITCT_HDR_SMP_TIMEOUT_8US 1
+#define ITCT_HDR_SMP_TIMEOUT (ITCT_HDR_SMP_TIMEOUT_8US * \
+250) /* 2ms */
+#define ITCT_HDR_AWT_CONTINUE_OFF 25
#define ITCT_HDR_PORT_ID_OFF 28
#define ITCT_HDR_PORT_ID_MSK (0xf << ITCT_HDR_PORT_ID_OFF)
/* qw2 */
@@ -696,6 +701,8 @@ static void setup_itct_v2_hw(struct hisi_hba *hisi_hba,
qw0 |= ((1 << ITCT_HDR_VALID_OFF) |
(device->linkrate << ITCT_HDR_MCR_OFF) |
(1 << ITCT_HDR_VLN_OFF) |
+ (ITCT_HDR_SMP_TIMEOUT << ITCT_HDR_SMP_TIMEOUT_OFF) |
+ (1 << ITCT_HDR_AWT_CONTINUE_OFF) |
(port->id << ITCT_HDR_PORT_ID_OFF));
itct->qw0 = cpu_to_le64(qw0);
@@ -705,7 +712,7 @@ static void setup_itct_v2_hw(struct hisi_hba *hisi_hba,
/* qw2 */
if (!dev_is_sata(device))
- itct->qw2 = cpu_to_le64((500ULL << ITCT_HDR_INLT_OFF) |
+ itct->qw2 = cpu_to_le64((5000ULL << ITCT_HDR_INLT_OFF) |
(0x1ULL << ITCT_HDR_BITLT_OFF) |
(0x32ULL << ITCT_HDR_MCTLT_OFF) |
(0x1ULL << ITCT_HDR_RTOLT_OFF));
@@ -714,7 +721,7 @@ static void setup_itct_v2_hw(struct hisi_hba *hisi_hba,
static void free_device_v2_hw(struct hisi_hba *hisi_hba,
struct hisi_sas_device *sas_dev)
{
- u64 qw0, dev_id = sas_dev->device_id;
+ u64 dev_id = sas_dev->device_id;
struct device *dev = &hisi_hba->pdev->dev;
struct hisi_sas_itct *itct = &hisi_hba->itct[dev_id];
u32 reg_val = hisi_sas_read32(hisi_hba, ENT_INT_SRC3);
@@ -738,8 +745,7 @@ static void free_device_v2_hw(struct hisi_hba *hisi_hba,
dev_dbg(dev, "got clear ITCT done interrupt\n");
/* invalid the itct state*/
- qw0 = cpu_to_le64(itct->qw0);
- qw0 &= ~(1 << ITCT_HDR_VALID_OFF);
+ memset(itct, 0, sizeof(struct hisi_sas_itct));
hisi_sas_write32(hisi_hba, ENT_INT_SRC3,
ENT_INT_SRC3_ITC_INT_MSK);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] scsi: hisi_sas: downgrade internal abort exit print
Downgrade the exit print in hisi_sas_internal_task_abort() to dbg level, as info is not required. Signed-off-by: John Garry Reviewed-by: Xiang Chen Reviewed-by: Johannes Thumshirn --- drivers/scsi/hisi_sas/hisi_sas_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index eee7ae2..b2782ce 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -1121,7 +1121,7 @@ static int hisi_sas_query_task(struct sas_task *task) } exit: - dev_info(dev, "internal task abort: task to dev %016llx task=%p " + dev_dbg(dev, "internal task abort: task to dev %016llx task=%p " "resp: 0x%x sts 0x%x\n", SAS_ADDR(device->sas_addr), task, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
This patch enables NCQ support for APM X-Gene SATA controller hardware v1.1
that was broken with hardware v1.0. Second thing, here we should not assume
XGENE_AHCI_V2 always in case of having valid _CID in ACPI table. I need to
remove this assumption because V1_1 also has a valid _CID for backward
compatibly with v1.
v2 changes:
1. Changed patch description
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_xgene.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 73b19b2..8b88be9 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -87,6 +87,7 @@
enum xgene_ahci_version {
XGENE_AHCI_V1 = 1,
+ XGENE_AHCI_V1_1,
XGENE_AHCI_V2,
};
@@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgene_ahci_acpi_match[] = {
{ "APMC0D0D", XGENE_AHCI_V1},
+ { "APMC0D67", XGENE_AHCI_V1_1},
{ "APMC0D32", XGENE_AHCI_V2},
{},
};
@@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
static const struct of_device_id xgene_ahci_of_match[] = {
{.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
+ {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
{.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
{},
};
@@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
struct resource *res;
const struct of_device_id *of_devid;
enum xgene_ahci_version version = XGENE_AHCI_V1;
- const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
- &xgene_ahci_v2_port_info };
+ const struct ata_port_info *ppi;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "%s: Error reading device
info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
- } else if (info->valid & ACPI_VALID_CID) {
- version = XGENE_AHCI_V2;
}
}
}
@@ -858,18 +858,20 @@ skip_clk_phy:
switch (version) {
case XGENE_AHCI_V1:
+ ppi = &xgene_ahci_v1_port_info;
hpriv->flags = AHCI_HFLAG_NO_NCQ;
break;
case XGENE_AHCI_V2:
+ ppi = &xgene_ahci_v2_port_info;
hpriv->flags |= AHCI_HFLAG_YES_FBS;
hpriv->irq_handler = xgene_ahci_irq_intr;
break;
default:
+ ppi = &xgene_ahci_v1_port_info;
break;
}
- rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
-&ahci_platform_sht);
+ rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
if (rc)
goto disable_resources;
--
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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On Tue, Jan 17, 2017 at 05:45:53PM +0200, Sagi Grimberg wrote: > > >-- > >[1] > >queue = b'nvme0q1' > > usecs : count distribution > > 0 -> 1 : 7310 || > > 2 -> 3 : 11 | | > > 4 -> 7 : 10 | | > > 8 -> 15 : 20 | | > >16 -> 31 : 0| | > >32 -> 63 : 0| | > >64 -> 127: 1| | > > > >[2] > >queue = b'nvme0q1' > > usecs : count distribution > > 0 -> 1 : 7309 || > > 2 -> 3 : 14 | | > > 4 -> 7 : 7| | > > 8 -> 15 : 17 | | > > > > Rrr, email made the histograms look funky (tabs vs. spaces...) > The count is what's important anyways... > > Just adding that I used an Intel P3500 nvme device. > > >We can see that most of the time our latency is pretty good (<1ns) but with > >huge tail latencies (some 8-15 ns and even one in 32-63 ns). > > Obviously is micro-seconds and not nano-seconds (I wish...) So to share yesterday's (and today's) findings: On AHCI I see only one completion polled as well. This probably is because in contrast to networking (with NAPI) in the block layer we do have a link between submission and completion whereas in networking RX and TX are decoupled. So if we're sending out one request we get the completion for it. What we'd need is a link to know "we've sent 10 requests out, now poll for the 10 completions after the 1st IRQ". So basically what NVMe already did with calling __nvme_process_cq() after submission. Maybe we should even disable IRQs when submitting and re-enable after submitting so the submission patch doesn't get preempted by a completion. Does this make sense? Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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 1/4] mpt3sas: Added print to notify cable running at a degraded speed.
Driver processes the event MPI26_EVENT_ACTIVE_CABLE_DEGRADED
when a cable is present and is running at a degraded speed
(below the SAS3 12 Gb/s rate). Prints added
to inform the user that the cable is not running at
optimal speed.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpi/mpi2_ioc.h |2 ++
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 20 ++--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
b/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
index 8bae305..af4be40 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_ioc.h
@@ -624,6 +624,8 @@ typedef struct _MPI26_EVENT_DATA_ACTIVE_CABLE_EXCEPT {
/* defines for ReasonCode field */
#define MPI26_EVENT_ACTIVE_CABLE_INSUFFICIENT_POWER (0x00)
+#define MPI26_EVENT_ACTIVE_CABLE_PRESENT(0x01)
+#define MPI26_EVENT_ACTIVE_CABLE_DEGRADED (0x02)
/*Hard Reset Received Event data */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 75f3fce..0f71f4a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -8028,15 +8028,23 @@ mpt3sas_scsih_event_callback(struct MPT3SAS_ADAPTER
*ioc, u8 msix_index,
case MPI2_EVENT_ACTIVE_CABLE_EXCEPTION:
ActiveCableEventData =
(Mpi26EventDataActiveCableExcept_t *) mpi_reply->EventData;
- if (ActiveCableEventData->ReasonCode ==
- MPI26_EVENT_ACTIVE_CABLE_INSUFFICIENT_POWER) {
- pr_info(MPT3SAS_FMT "Currently an active cable with
ReceptacleID %d",
+ switch (ActiveCableEventData->ReasonCode) {
+ case MPI26_EVENT_ACTIVE_CABLE_INSUFFICIENT_POWER:
+ pr_info(MPT3SAS_FMT "Currently an active cable with
ReceptacleID %d\n",
ioc->name, ActiveCableEventData->ReceptacleID);
- pr_info("cannot be powered and devices connected to
this active cable");
- pr_info("will not be seen. This active cable");
- pr_info("requires %d mW of power",
+ pr_info(" cannot be powered and devices connected
to\n");
+ pr_info(" this active cable will not be seen. This\n");
+ pr_info(" cable requires %d mW of power\n",
ActiveCableEventData->ActiveCablePowerRequirement);
+ break;
+
+ case MPI26_EVENT_ACTIVE_CABLE_DEGRADED:
+ pr_info(MPT3SAS_FMT "Currently a cable with
ReceptacleID %d",
+ ioc->name, ActiveCableEventData->ReceptacleID);
+ pr_info(" is not running at optimal speed(12 Gb/s)\n");
+ break;
}
+
break;
default: /* ignore the rest */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] mpt3sas: Fix Firmware fault state 0x2100 during heavy 4K RR FIO stress test.
Due existence of loop in the IO path our HBA will receive heavy IOs and
also as driver is not updating the Reply Post Host Index frequently, So
there will be a high chance that our Firmware unable to find any free entry
in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
observe 0x2100 firmware fault.
So to fix this, we have defined a thresh hold value. After continuously
processing this thresh hold number of reply descriptors driver will update
the Reply Descriptor Host Index so that this thresh hold number of reply
descriptors entries will be freed and these entries will be available for
firmware and we won't observe this Firmware fault. We have defined this
threshold value as 1/3rd of the hba queue depth.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 722fab9..a3fe1fb 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1040,6 +1040,25 @@ _base_interrupt(int irq, void *bus_id)
reply_q->reply_post_free[reply_q->reply_post_host_index].
Default.ReplyFlags & MPI2_RPY_DESCRIPT_FLAGS_TYPE_MASK;
completed_cmds++;
+ /* Update the reply post host index after continuously
+* processing the threshold number of Reply Descriptors.
+* So that FW can find enough entries to post the Reply
+* Descriptors in the reply descriptor post queue.
+*/
+ if (completed_cmds > ioc->hba_queue_depth/3) {
+ if (ioc->combined_reply_queue) {
+ writel(reply_q->reply_post_host_index |
+ ((msix_index & 7) <<
+MPI2_RPHI_MSIX_INDEX_SHIFT),
+ ioc->replyPostRegisterIndex[msix_index/8]);
+ } else {
+ writel(reply_q->reply_post_host_index |
+ (msix_index <<
+MPI2_RPHI_MSIX_INDEX_SHIFT),
+ &ioc->chip->ReplyPostHostIndex);
+ }
+ completed_cmds = 1;
+ }
if (request_desript_type == MPI2_RPY_DESCRIPT_FLAGS_UNUSED)
goto out;
if (!reply_q->reply_post_host_index)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] mpt3sas: Fix for Crusader to achieve product targets with SAS devices.
Small glitch/degraded performance in Crusader is improved with SAS
drives by removing unnecessary spinlocks while clearing scsi command
in drivers internal lookup table.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.c |1 +
drivers/scsi/mpt3sas/mpt3sas_base.h |1 +
drivers/scsi/mpt3sas/mpt3sas_ctl.c |4 +++-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 31 ---
4 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index f00ef88..722fab9 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -5522,6 +5522,7 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
goto out_free_resources;
ioc->non_operational_loop = 0;
+ ioc->got_task_abort_from_ioctl = 0;
return 0;
out_free_resources:
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index dcb33f4..83cfa16 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -1000,6 +1000,7 @@ struct MPT3SAS_ADAPTER {
u8 broadcast_aen_busy;
u16 broadcast_aen_pending;
u8 shost_recovery;
+ u8 got_task_abort_from_ioctl;
struct mutexreset_in_progress_mutex;
spinlock_t ioc_reset_in_progress_lock;
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 95f0f24..02fe1c4 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -826,16 +826,18 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct
mpt3_ioctl_command karg,
"TASK_MGMT: handle(0x%04x), task_type(0x%02x)\n",
ioc->name,
le16_to_cpu(tm_request->DevHandle), tm_request->TaskType));
-
+ ioc->got_task_abort_from_ioctl = 1;
if (tm_request->TaskType ==
MPI2_SCSITASKMGMT_TASKTYPE_ABORT_TASK ||
tm_request->TaskType ==
MPI2_SCSITASKMGMT_TASKTYPE_QUERY_TASK) {
if (_ctl_set_task_mid(ioc, &karg, tm_request)) {
mpt3sas_base_free_smid(ioc, smid);
+ ioc->got_task_abort_from_ioctl = 0;
goto out;
}
}
+ ioc->got_task_abort_from_ioctl = 0;
if (test_bit(device_handle, ioc->device_remove_in_progress)) {
dtmprintk(ioc, pr_info(MPT3SAS_FMT
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 0f71f4a..217e0fe 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -1074,6 +1074,26 @@ _scsih_scsi_lookup_get(struct MPT3SAS_ADAPTER *ioc, u16
smid)
}
/**
+ * _scsih_scsi_lookup_get_clear_without_lock - returns scmd entry without
+ * holding any lock.
+ * @ioc: per adapter object
+ * @smid: system request message index
+ *
+ * Returns the smid stored scmd pointer.
+ * Then will dereference the stored scmd pointer.
+ */
+static inline struct scsi_cmnd *
+_scsih_scsi_lookup_get_clear_without_lock(struct MPT3SAS_ADAPTER *ioc,
+ u16 smid)
+{
+ struct scsi_cmnd *scmd = NULL;
+
+ swap(scmd, ioc->scsi_lookup[smid - 1].scmd);
+
+ return scmd;
+}
+
+/**
* _scsih_scsi_lookup_get_clear - returns scmd entry
* @ioc: per adapter object
* @smid: system request message index
@@ -1088,8 +1108,7 @@ _scsih_scsi_lookup_get_clear(struct MPT3SAS_ADAPTER *ioc,
u16 smid)
struct scsi_cmnd *scmd;
spin_lock_irqsave(&ioc->scsi_lookup_lock, flags);
- scmd = ioc->scsi_lookup[smid - 1].scmd;
- ioc->scsi_lookup[smid - 1].scmd = NULL;
+ scmd = _scsih_scsi_lookup_get_clear_without_lock(ioc, smid);
spin_unlock_irqrestore(&ioc->scsi_lookup_lock, flags);
return scmd;
@@ -4659,7 +4678,13 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8
msix_index, u32 reply)
unsigned long flags;
mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply);
- scmd = _scsih_scsi_lookup_get_clear(ioc, smid);
+
+ if (ioc->broadcast_aen_busy || ioc->pci_error_recovery ||
+ ioc->got_task_abort_from_ioctl)
+ scmd = _scsih_scsi_lookup_get_clear(ioc, smid);
+ else
+ scmd = _scsih_scsi_lookup_get_clear_without_lock(ioc, smid);
+
if (scmd == NULL)
return 1;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] mpt3sas: Updating driver version to v15.100.00.00
Signed-off-by: Chaitra P B Signed-off-by: Suganath Prabu S --- drivers/scsi/mpt3sas/mpt3sas_base.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index 83cfa16..4ab634f 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -73,9 +73,9 @@ #define MPT3SAS_DRIVER_NAME"mpt3sas" #define MPT3SAS_AUTHOR "Avago Technologies " #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver" -#define MPT3SAS_DRIVER_VERSION "14.101.00.00" -#define MPT3SAS_MAJOR_VERSION 14 -#define MPT3SAS_MINOR_VERSION 101 +#define MPT3SAS_DRIVER_VERSION "15.100.00.00" +#define MPT3SAS_MAJOR_VERSION 15 +#define MPT3SAS_MINOR_VERSION 100 #define MPT3SAS_BUILD_VERSION 0 #define MPT3SAS_RELEASE_VERSION00 -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] mpt3sas driver Enhancements and
Here is the change list: Posting 4 patches for mpt3sas driver enhancement and defect fixes. * Handle cable event for notifying degraded speed. * Performance improvement for Crusader. * Fix Firmware fault state 0x2100 during heavy 4K RR FIO stress test. * Updated driver version to 15.100.00.00 Chaitra P B (4): mpt3sas: Added print to notify cable running at a degraded speed. mpt3sas: Fix for Crusader to achieve product targets with SAS devices. mpt3sas: Fix Firmware fault state 0x2100 during heavy 4K RR FIO stress test. mpt3sas: Updating driver version to v15.100.00.00 drivers/scsi/mpt3sas/mpi/mpi2_ioc.h |2 + drivers/scsi/mpt3sas/mpt3sas_base.c | 20 + drivers/scsi/mpt3sas/mpt3sas_base.h |7 ++-- drivers/scsi/mpt3sas/mpt3sas_ctl.c |4 ++- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 51 -- 5 files changed, 71 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mpt3sas: Fix for Crusader to achieve product targets with SAS devices.
On Fri, Jan 20, 2017 at 08:12:11PM +0530, Chaitra P B wrote:
> Small glitch/degraded performance in Crusader is improved with SAS
> drives by removing unnecessary spinlocks while clearing scsi command
> in drivers internal lookup table.
>
> Signed-off-by: Chaitra P B
> Signed-off-by: Suganath Prabu S
> ---
Whats wrong with creating a __scsih_scsi_lookup_get_clear() and calling
it with the scsi_lookup_lock held from _scsih_scsi_lookup_get_clear()
instead of duplicating the code?
It's quite common in the linux kernel to have two functions func and __func,
where func is
func()
{
spin_lock();
__func();
spin_unlock();
}
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mpt3sas: Added print to notify cable running at a degraded speed.
On Fri, Jan 20, 2017 at 08:12:10PM +0530, Chaitra P B wrote: > Driver processes the event MPI26_EVENT_ACTIVE_CABLE_DEGRADED > when a cable is present and is running at a degraded speed > (below the SAS3 12 Gb/s rate). Prints added > to inform the user that the cable is not running at > optimal speed. > > Signed-off-by: Chaitra P B > Signed-off-by: Suganath Prabu S > --- Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] mpt3sas: Updating driver version to v15.100.00.00
On Fri, Jan 20, 2017 at 08:12:13PM +0530, Chaitra P B wrote: > > Signed-off-by: Chaitra P B > Signed-off-by: Suganath Prabu S > --- Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mpt3sas: Fix Firmware fault state 0x2100 during heavy 4K RR FIO stress test.
On Fri, Jan 20, 2017 at 08:12:12PM +0530, Chaitra P B wrote:
> Due existence of loop in the IO path our HBA will receive heavy IOs and
> also as driver is not updating the Reply Post Host Index frequently, So
> there will be a high chance that our Firmware unable to find any free entry
> in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
> observe 0x2100 firmware fault.
> So to fix this, we have defined a thresh hold value. After continuously
> processing this thresh hold number of reply descriptors driver will update
> the Reply Descriptor Host Index so that this thresh hold number of reply
> descriptors entries will be freed and these entries will be available for
> firmware and we won't observe this Firmware fault. We have defined this
> threshold value as 1/3rd of the hba queue depth.
>
> Signed-off-by: Chaitra P B
> Signed-off-by: Suganath Prabu S
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 19 +++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 722fab9..a3fe1fb 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -1040,6 +1040,25 @@ _base_interrupt(int irq, void *bus_id)
> reply_q->reply_post_free[reply_q->reply_post_host_index].
> Default.ReplyFlags & MPI2_RPY_DESCRIPT_FLAGS_TYPE_MASK;
> completed_cmds++;
> + /* Update the reply post host index after continuously
> + * processing the threshold number of Reply Descriptors.
> + * So that FW can find enough entries to post the Reply
> + * Descriptors in the reply descriptor post queue.
> + */
> + if (completed_cmds > ioc->hba_queue_depth/3) {
> + if (ioc->combined_reply_queue) {
> + writel(reply_q->reply_post_host_index |
> + ((msix_index & 7) <<
> + MPI2_RPHI_MSIX_INDEX_SHIFT),
> + ioc->replyPostRegisterIndex[msix_index/8]);
> + } else {
> + writel(reply_q->reply_post_host_index |
> + (msix_index <<
> + MPI2_RPHI_MSIX_INDEX_SHIFT),
> + &ioc->chip->ReplyPostHostIndex);
> + }
> + completed_cmds = 1;
> + }
> if (request_desript_type == MPI2_RPY_DESCRIPT_FLAGS_UNUSED)
> goto out;
> if (!reply_q->reply_post_host_index)
Do I understand it correctly that you fill the HBA's internal queue up to a
3rd and then kick it to start processing?
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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: [lkp-robot] [rcu] b332151a29: kernel_BUG_at_mm/slab.c
On 2017-01-19 09:02:16 [+0800], kernel test robot wrote: > test-description: Trinity is a linux system call fuzz tester. you don't even get to fire up trinity. With and without the patch you crash very early. > +-+++ > | | d5f6ab9c11 | > b332151a29 | > +-+++ > | boot_successes | 0 | 0 > | > | boot_failures | 6 | 8 > | > | WARNING:at_include/linux/kref.h:#kobject_get| 6 | 8 > | > | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 2 | 2 > | > | kernel_BUG_at_mm/slab.c | 0 | 4 > | > | invalid_opcode:#[##]PREEMPT_SMP | 0 | 4 > | > | Kernel_panic-not_syncing:Fatal_exception| 0 | 6 > | > | BUG:unable_to_handle_kernel | 0 | 2 > | > | Oops| 0 | 2 > | > +-+++ There is no successful boot. The pattern changes with patch in question applied. > [8.044624] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [8.055721] slab: double free detected in cache 'kmalloc-32', objp 8af558c0 > [8.057138] [ cut here ] > [8.058085] kernel BUG at mm/slab.c:2624! > [8.059255] invalid opcode: [#1] PREEMPT SMP yes. With and without the patch there is a lot of wrong stuff like complains about a kobject initialized again. This leads to a double free at some point. What happens is the following: CONFIG_SCSI_DEBUG is enabled which adds a dummy host controller with a dummy disk. This gets probed during boot. Since you also enabled CONFIG_DEBUG_TEST_DRIVER_REMOVE it gets removed and re-added. The request_queue in genhd disk is re-used while the disk is added for the second time: [1.314404] scsi host0: scsi_debug: version 1.86 [20160430] [1.314404] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0 [1.315994] scsi 0:0:0:0: Direct-Access Linuxscsi_debug 0186 PQ: 0 ANSI: 7 [1.351052] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB) [1.355916] sd 0:0:0:0: [sda] Write Protect is off [1.356838] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08 [1.364455] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [1.437642] sd 0:0:0:0: [sda] Attached SCSI disk [1.438413] sd 0:0:0:0: [sda] Synchronizing SCSI cache [1.445868] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB) [1.450819] sd 0:0:0:0: [sda] Write Protect is off [1.451853] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08 [1.459636] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [1.471446] kobject (beb87d44): tried to init an initialized object, something is seriously wrong. Since you also need CONFIG_SCSI_MQ_DEFAULT enabled I assume the MQ block code is buggy here. But commit b332151a29 in Paul's tree innocent. Sebastian -- 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: [lkp-robot] [rcu] b332151a29: kernel_BUG_at_mm/slab.c
On 01/20/2017 08:01 AM, Sebastian Andrzej Siewior wrote: > On 2017-01-19 09:02:16 [+0800], kernel test robot wrote: >> test-description: Trinity is a linux system call fuzz tester. > > you don't even get to fire up trinity. With and without the patch you > crash very early. > >> +-+++ >> | | d5f6ab9c11 | >> b332151a29 | >> +-+++ >> | boot_successes | 0 | 0 >>| >> | boot_failures | 6 | 8 >>| >> | WARNING:at_include/linux/kref.h:#kobject_get| 6 | 8 >>| >> | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 2 | 2 >>| >> | kernel_BUG_at_mm/slab.c | 0 | 4 >>| >> | invalid_opcode:#[##]PREEMPT_SMP | 0 | 4 >>| >> | Kernel_panic-not_syncing:Fatal_exception| 0 | 6 >>| >> | BUG:unable_to_handle_kernel | 0 | 2 >>| >> | Oops| 0 | 2 >>| >> +-+++ > > There is no successful boot. The pattern changes with patch in question > applied. > >> [8.044624] sd 0:0:0:0: [sda] Synchronizing SCSI cache >> [8.055721] slab: double free detected in cache 'kmalloc-32', objp >> 8af558c0 >> [8.057138] [ cut here ] >> [8.058085] kernel BUG at mm/slab.c:2624! >> [8.059255] invalid opcode: [#1] PREEMPT SMP Is there a full trace of this? > yes. With and without the patch there is a lot of wrong stuff like > complains about a kobject initialized again. This leads to a double free > at some point. And what patch are we talking about? I don't mind being CC'ed into a thread, but some context and background would be immensely helpful here... -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] mpt3sas: Fix Firmware fault state 0x2100 during heavy 4K RR FIO stress test.
On Fri, Jan 20, 2017 at 8:40 PM, Johannes Thumshirn wrote:
> On Fri, Jan 20, 2017 at 08:12:12PM +0530, Chaitra P B wrote:
>> Due existence of loop in the IO path our HBA will receive heavy IOs and
>> also as driver is not updating the Reply Post Host Index frequently, So
>> there will be a high chance that our Firmware unable to find any free entry
>> in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
>> observe 0x2100 firmware fault.
>> So to fix this, we have defined a thresh hold value. After continuously
>> processing this thresh hold number of reply descriptors driver will update
>> the Reply Descriptor Host Index so that this thresh hold number of reply
>> descriptors entries will be freed and these entries will be available for
>> firmware and we won't observe this Firmware fault. We have defined this
>> threshold value as 1/3rd of the hba queue depth.
>>
>> Signed-off-by: Chaitra P B
>> Signed-off-by: Suganath Prabu S
>> ---
>> drivers/scsi/mpt3sas/mpt3sas_base.c | 19 +++
>> 1 files changed, 19 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> index 722fab9..a3fe1fb 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> @@ -1040,6 +1040,25 @@ _base_interrupt(int irq, void *bus_id)
>> reply_q->reply_post_free[reply_q->reply_post_host_index].
>> Default.ReplyFlags & MPI2_RPY_DESCRIPT_FLAGS_TYPE_MASK;
>> completed_cmds++;
>> + /* Update the reply post host index after continuously
>> + * processing the threshold number of Reply Descriptors.
>> + * So that FW can find enough entries to post the Reply
>> + * Descriptors in the reply descriptor post queue.
>> + */
>> + if (completed_cmds > ioc->hba_queue_depth/3) {
>> + if (ioc->combined_reply_queue) {
>> + writel(reply_q->reply_post_host_index |
>> + ((msix_index & 7) <<
>> + MPI2_RPHI_MSIX_INDEX_SHIFT),
>> + ioc->replyPostRegisterIndex[msix_index/8]);
>> + } else {
>> + writel(reply_q->reply_post_host_index |
>> + (msix_index <<
>> + MPI2_RPHI_MSIX_INDEX_SHIFT),
>> +
>> &ioc->chip->ReplyPostHostIndex);
>> + }
>> + completed_cmds = 1;
>> + }
>> if (request_desript_type == MPI2_RPY_DESCRIPT_FLAGS_UNUSED)
>> goto out;
>> if (!reply_q->reply_post_host_index)
>
> Do I understand it correctly that you fill the HBA's internal queue up to a
> 3rd and then kick it to start processing?
No, driver will continuously process the reply descriptors from Reply
Descriptor Post Queue (RDPQ) but will update it's Host Index (tail
index) with the firmware after continuously processing 1/3rd of the
HBA queue depth number of descriptors instead of updating it's host
index only at after it see unused descriptor entry. So that firmware
can always get enough free descriptors entries to post reply
descriptors and won't see any 0x2100 fault which will occur if
firmware doesn't find any free descriptor entry in the RDPQ queue.
Thanks,
Sreekanth
>
> Thanks,
> Johannes
> --
> Johannes Thumshirn Storage
> jthumsh...@suse.de+49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mpt3sas: Fix for Crusader to achieve product targets with SAS devices.
On Fri, Jan 20, 2017 at 8:30 PM, Johannes Thumshirn wrote:
> On Fri, Jan 20, 2017 at 08:12:11PM +0530, Chaitra P B wrote:
>> Small glitch/degraded performance in Crusader is improved with SAS
>> drives by removing unnecessary spinlocks while clearing scsi command
>> in drivers internal lookup table.
>>
>> Signed-off-by: Chaitra P B
>> Signed-off-by: Suganath Prabu S
>> ---
>
> Whats wrong with creating a __scsih_scsi_lookup_get_clear() and calling
> it with the scsi_lookup_lock held from _scsih_scsi_lookup_get_clear()
> instead of duplicating the code?
>
> It's quite common in the linux kernel to have two functions func and __func,
> where func is
>
> func()
> {
> spin_lock();
> __func();
> spin_unlock();
> }
>
Sure, We will resend this path with this change.
Thanks,
Sreekanth
> --
> Johannes Thumshirn Storage
> jthumsh...@suse.de+49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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: [lkp-robot] [rcu] b332151a29: kernel_BUG_at_mm/slab.c
On 01/20/2017 08:23 AM, Sebastian Andrzej Siewior wrote: >>> yes. With and without the patch there is a lot of wrong stuff like >>> complains about a kobject initialized again. This leads to a double free >>> at some point. >> >> And what patch are we talking about? I don't mind being CC'ed into a thread, >> but some context and background would be immensely helpful here... > > The patch is irrelevant. lkp-robot found a bug which was there before > the patch in question but the pattern changed so it blamed the Author. > It triggers even v4.9 with > CONFIG_SCSI_DEBUG > CONFIG_DEBUG_TEST_DRIVER_REMOVE > CONFIG_SCSI_MQ_DEFAULT > enabled and CONFIG_SCSI_DEBUG is simply a SCSI host controller which is > always there. I can send you a complete config against current HEAD > which boots in kvm if you want. That's alright, sounds like it's not a -next regression, but rather something that is already broken. I can reproduce a lot of breakage if I enable CONFIG_DEBUG_TEST_DRIVER_REMOVE, in fact my system doesn't boot at all. This is the first bug: [ 18.247895] [ cut here ] [ 18.247907] WARNING: CPU: 21 PID: 2223 at drivers/ata/libata-core.c:6522 ata_host_detach+0x11b] [ 18.247908] Modules linked in: igb(+) ahci(+) libahci i2c_algo_bit dca libata nvme(+) nvme_core [ 18.247917] CPU: 21 PID: 2223 Comm: systemd-udevd Tainted: GW 4.10.0-rc4+ #30 [ 18.247919] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016 [ 18.247919] Call Trace: [ 18.247928] dump_stack+0x68/0x93 [ 18.247934] __warn+0xc6/0xe0 [ 18.247937] warn_slowpath_null+0x18/0x20 [ 18.247943] ata_host_detach+0x11b/0x120 [libata] [ 18.247950] ata_pci_remove_one+0x10/0x20 [libata] [ 18.247955] ahci_remove_one+0x10/0x20 [ahci] [ 18.247958] pci_device_remove+0x34/0xb0 [ 18.247966] driver_probe_device+0xd0/0x370 [ 18.247969] __driver_attach+0x9a/0xa0 [ 18.247971] ? driver_probe_device+0x370/0x370 [ 18.247973] bus_for_each_dev+0x5d/0x90 [ 18.247975] driver_attach+0x19/0x20 [ 18.247977] bus_add_driver+0x11f/0x220 [ 18.247980] driver_register+0x5b/0xd0 [ 18.247982] __pci_register_driver+0x58/0x60 [ 18.247984] ? 0xa00d9000 [ 18.247988] ahci_pci_driver_init+0x1e/0x20 [ahci] [ 18.247992] do_one_initcall+0x3e/0x170 [ 18.247997] ? rcu_read_lock_sched_held+0x45/0x80 [ 18.248001] ? kmem_cache_alloc_trace+0x22e/0x290 [ 18.248004] do_init_module+0x5a/0x1cb [ 18.248007] load_module+0x1e60/0x2570 [ 18.248008] ? __symbol_put+0x70/0x70 [ 18.248010] ? show_coresize+0x30/0x30 [ 18.248013] ? kernel_read_file+0x19e/0x1c0 [ 18.248015] ? kernel_read_file_from_fd+0x44/0x70 [ 18.248016] SYSC_finit_module+0xba/0xc0 [ 18.248018] SyS_finit_module+0x9/0x10 [ 18.248021] entry_SYSCALL_64_fastpath+0x18/0xad [ 18.248022] RIP: 0033:0x7f49c5a645b9 [ 18.248023] RSP: 002b:7ffccf512658 EFLAGS: 0246 ORIG_RAX: 0139 [ 18.248025] RAX: ffda RBX: 7f49c61659dd RCX: 7f49c5a645b9 [ 18.248026] RDX: RSI: 7f49c53152c7 RDI: 0009 [ 18.248026] RBP: 0002 R08: R09: [ 18.248027] R10: 0009 R11: 0246 R12: 555737e82b30 [ 18.248028] R13: 555737e71200 R14: 555737e82b30 R15: [ 18.248030] ---[ end trace b0ae5eae3430d5d6 ]--- and it's even more downhill from there. That option is marked unstable, are we expecting it to work right now? -- Jens Axboe -- 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: [lkp-robot] [rcu] b332151a29: kernel_BUG_at_mm/slab.c
On 2017-01-20 08:09:36 [-0800], Jens Axboe wrote: > Is there a full trace of this? [3.654003] scsi host0: scsi_debug: version 1.86 [20160430] [3.654003] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0 [3.660755] scsi 0:0:0:0: Direct-Access Linuxscsi_debug 0186 PQ: 0 ANSI: 7 [3.711231] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB) [3.716202] sd 0:0:0:0: [sda] Write Protect is off [3.717244] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08 [3.725059] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.795093] sd 0:0:0:0: [sda] Attached SCSI disk [3.796686] sd 0:0:0:0: [sda] Synchronizing SCSI cache [3.804770] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB) [3.809748] sd 0:0:0:0: [sda] Write Protect is off [3.810806] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08 [3.818599] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.830894] kobject (be01a5fc): tried to init an initialized object, something is seriously wrong. [3.832820] CPU: 6 PID: 6 Comm: kworker/u14:0 Not tainted 4.9.0 #86 [3.834172] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.1-1 04/01/2014 [3.835886] Workqueue: events_unbound async_run_entry_fn [3.837028] 80079da8 83a5f6cc be01a5fc be01a5fc 80079dc4 83a61e33 842a883c be01a5fc [3.838802] 84397488 be01a108 80079dec 83a46afa be01a5d8 840670a0 be01a5d8 [3.840570] be01a108 bd983468 be01a108 bd983470 be01a5d8 80079e14 83a3c857 be01a5d8 [3.842350] Call Trace: [3.842884] [<83a5f6cc>] dump_stack+0x58/0x7c [3.843834] [<83a61e33>] kobject_init+0x73/0x80 [3.844828] [<83a46afa>] blk_mq_register_dev+0x2a/0x110 [3.845971] [<83a3c857>] blk_register_queue+0x87/0x140 [3.847085] [<83a49c7e>] device_add_disk+0x1ce/0x470 [3.848170] [<83c3d328>] sd_probe_async+0xe8/0x1b0 [3.849207] [<83672347>] async_run_entry_fn+0x37/0xe0 [3.850313] [<836694f7>] process_one_work+0x1b7/0x3e0 [3.851414] [<8366947c>] ? process_one_work+0x13c/0x3e0 [3.852552] [<83669759>] worker_thread+0x39/0x460 [3.853569] [<83669720>] ? process_one_work+0x3e0/0x3e0 [3.854717] [<8366f394>] kthread+0xb4/0xd0 [3.855611] [<83f8cb4d>] ? _raw_spin_unlock_irq+0x2d/0x50 [3.856775] [<8366f2e0>] ? __kthread_create_on_node+0x160/0x160 [3.858066] [<8366f2e0>] ? __kthread_create_on_node+0x160/0x160 [3.859340] [<83f8d363>] ret_from_fork+0x1b/0x28 [3.863951] kobject (ff0ca36c): tried to init an initialized object, something is seriously wrong. [3.865875] CPU: 6 PID: 6 Comm: kworker/u14:0 Not tainted 4.9.0 #86 [3.867202] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.1-1 04/01/2014 [3.868924] Workqueue: events_unbound async_run_entry_fn [3.870079] 80079da8 83a5f6cc ff0ca36c be01a5fc 80079dc4 83a61e33 842a883c ff0ca36c [3.871846] 80079dc4 84397474 be01a108 80079dec 83a46b1c be01a5d8 840670a0 be01a5d8 [3.873605] be01a108 bd983468 be01a108 bd983470 be01a5d8 80079e14 83a3c857 be01a5d8 [3.875395] Call Trace: [3.875928] [<83a5f6cc>] dump_stack+0x58/0x7c [3.876878] [<83a61e33>] kobject_init+0x73/0x80 [3.877884] [<83a46b1c>] blk_mq_register_dev+0x4c/0x110 [3.879018] [<83a3c857>] blk_register_queue+0x87/0x140 [3.880136] [<83a49c7e>] device_add_disk+0x1ce/0x470 [3.881227] [<83c3d328>] sd_probe_async+0xe8/0x1b0 [3.882283] [<83672347>] async_run_entry_fn+0x37/0xe0 [3.883381] [<836694f7>] process_one_work+0x1b7/0x3e0 [3.884481] [<8366947c>] ? process_one_work+0x13c/0x3e0 [3.885613] [<83669759>] worker_thread+0x39/0x460 [3.886658] [<83669720>] ? process_one_work+0x3e0/0x3e0 [3.887791] [<8366f394>] kthread+0xb4/0xd0 [3.888680] [<83f8cb4d>] ? _raw_spin_unlock_irq+0x2d/0x50 [3.889881] [<8366f2e0>] ? __kthread_create_on_node+0x160/0x160 [3.891189] [<8366f2e0>] ? __kthread_create_on_node+0x160/0x160 [3.892506] [<83f8d363>] ret_from_fork+0x1b/0x28 [3.893563] kobject (ff21b36c): tried to init an initialized object, something is seriously wrong. [3.895559] CPU: 6 PID: 6 Comm: kworker/u14:0 Not tainted 4.9.0 #86 [3.896938] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.1-1 04/01/2014 [3.898741] Workqueue: events_unbound async_run_entry_fn [3.899911] 80079da8 83a5f6cc ff21b36c be01a5fc 80079dc4 83a61e33 842a883c ff21b36c [3.901739] 80079dc4 84397474 be01a108 80079dec 83a46b1c be01a5d8 840670a0 be01a5d8 [3.903558] be01a108 bd983468 be01a108 bd983470 be01a5d8 80079e14 83a3c857 be01a5d8 [3.905381] Call Trace: [3.905936] [<83a5f6cc>] dump_stack+0x58/0x7c [3.906913] [<83a61e33>] kobject_init+0x73/0x80 [3.907931] [<83a46b1c>] blk_mq_register_dev+0x4c/0x110 [3.909108] [<83a3c857>] blk_register_queue+0x87/0x140 [3.910267] [<83a49c7e>] device_add_disk+0x1ce/0x470 [3.9
Re: [lkp-robot] [rcu] b332151a29: kernel_BUG_at_mm/slab.c
On 2017-01-20 08:32:37 [-0800], Jens Axboe wrote:
> That's alright, sounds like it's not a -next regression, but rather something
> that is already broken. I can reproduce a lot of breakage if I enable
> CONFIG_DEBUG_TEST_DRIVER_REMOVE, in fact my system doesn't boot at all. This
> is the first bug:
>
> [ 18.247895] [ cut here ]
> [ 18.247907] WARNING: CPU: 21 PID: 2223 at drivers/ata/libata-core.c:6522
> ata_host_detach+0x11b]
> [ 18.247908] Modules linked in: igb(+) ahci(+) libahci i2c_algo_bit dca
> libata nvme(+) nvme_core
> [ 18.247917] CPU: 21 PID: 2223 Comm: systemd-udevd Tainted: GW
> 4.10.0-rc4+ #30
> [ 18.247919] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4
> 11/09/2016
> [ 18.247919] Call Trace:
> [ 18.247928] dump_stack+0x68/0x93
> [ 18.247934] __warn+0xc6/0xe0
> [ 18.247937] warn_slowpath_null+0x18/0x20
> [ 18.247943] ata_host_detach+0x11b/0x120 [libata]
…
> and it's even more downhill from there. That option is marked unstable, are we
> expecting it to work right now?
Well, as per 248ff0216543 ("driver core: Make Kconfig text for
DEBUG_TEST_DRIVER_REMOVE stronger"):
| The current state of driver removal is not great.
| CONFIG_DEBUG_TEST_DRIVER_REMOVE finds lots of errors. The help text
| currently undersells exactly how many errors this option will find. Add
| a bit more description to indicate this option shouldn't be turned on
| unless you actually want to debug driver removal. The text can be
| changed later when more drivers are fixed up.
so it looks like the option is working but it uncovers bugs. I've put
you in TO because the breakage in kvm test went away after I disabled
the MQ support in SCSI. So I *assumed* that MQ was not doing something
right in the removal path. I don't know if this libata-core backtrace is
a false positive or not.
Sebastian
--
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: [lkp-robot] [rcu] b332151a29: kernel_BUG_at_mm/slab.c
On 01/20/2017 09:09 AM, Sebastian Andrzej Siewior wrote:
> On 2017-01-20 08:32:37 [-0800], Jens Axboe wrote:
>> That's alright, sounds like it's not a -next regression, but rather something
>> that is already broken. I can reproduce a lot of breakage if I enable
>> CONFIG_DEBUG_TEST_DRIVER_REMOVE, in fact my system doesn't boot at all. This
>> is the first bug:
>>
>> [ 18.247895] [ cut here ]
>> [ 18.247907] WARNING: CPU: 21 PID: 2223 at drivers/ata/libata-core.c:6522
>> ata_host_detach+0x11b]
>> [ 18.247908] Modules linked in: igb(+) ahci(+) libahci i2c_algo_bit dca
>> libata nvme(+) nvme_core
>> [ 18.247917] CPU: 21 PID: 2223 Comm: systemd-udevd Tainted: GW
>> 4.10.0-rc4+ #30
>> [ 18.247919] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4
>> 11/09/2016
>> [ 18.247919] Call Trace:
>> [ 18.247928] dump_stack+0x68/0x93
>> [ 18.247934] __warn+0xc6/0xe0
>> [ 18.247937] warn_slowpath_null+0x18/0x20
>> [ 18.247943] ata_host_detach+0x11b/0x120 [libata]
> …
>
>> and it's even more downhill from there. That option is marked unstable, are
>> we
>> expecting it to work right now?
>
> Well, as per 248ff0216543 ("driver core: Make Kconfig text for
> DEBUG_TEST_DRIVER_REMOVE stronger"):
>
> | The current state of driver removal is not great.
> | CONFIG_DEBUG_TEST_DRIVER_REMOVE finds lots of errors. The help text
> | currently undersells exactly how many errors this option will find. Add
> | a bit more description to indicate this option shouldn't be turned on
> | unless you actually want to debug driver removal. The text can be
> | changed later when more drivers are fixed up.
>
> so it looks like the option is working but it uncovers bugs. I've put
> you in TO because the breakage in kvm test went away after I disabled
> the MQ support in SCSI. So I *assumed* that MQ was not doing something
> right in the removal path. I don't know if this libata-core backtrace is
> a false positive or not.
Sure, I get that, my question is just if it's always finding valid bugs,
or if the test itself is buggy. The fact that I can't boot anything after
enabling it makes me suspicious.
Or maybe the state of load/remove/load is just pretty sad.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mpt3sas: Added print to notify cable running at a degraded speed.
On Fri, 2017-01-20 at 20:12 +0530, Chaitra P B wrote:
> Driver processes the event MPI26_EVENT_ACTIVE_CABLE_DEGRADED
> when a cable is present and is running at a degraded speed
> (below the SAS3 12 Gb/s rate). Prints added
> to inform the user that the cable is not running at
> optimal speed.
[]
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
[]
> @@ -8028,15 +8028,23 @@ mpt3sas_scsih_event_callback(struct MPT3SAS_ADAPTER
> *ioc, u8 msix_index,
> case MPI2_EVENT_ACTIVE_CABLE_EXCEPTION:
> ActiveCableEventData =
> (Mpi26EventDataActiveCableExcept_t *) mpi_reply->EventData;
> - if (ActiveCableEventData->ReasonCode ==
> - MPI26_EVENT_ACTIVE_CABLE_INSUFFICIENT_POWER) {
> - pr_info(MPT3SAS_FMT "Currently an active cable with
> ReceptacleID %d",
> + switch (ActiveCableEventData->ReasonCode) {
> + case MPI26_EVENT_ACTIVE_CABLE_INSUFFICIENT_POWER:
> + pr_info(MPT3SAS_FMT "Currently an active cable with
> ReceptacleID %d\n",
> ioc->name, ActiveCableEventData->ReceptacleID);
> - pr_info("cannot be powered and devices connected to
> this active cable");
> - pr_info("will not be seen. This active cable");
> - pr_info("requires %d mW of power",
> + pr_info(" cannot be powered and devices connected
> to\n");
> + pr_info(" this active cable will not be seen. This\n");
> + pr_info(" cable requires %d mW of power\n",
Can you please use more intelligible logging
where sentences are not broken across multiple
lines of output? Something like:
pr_notice(MPT3SAS_FMT "Receptacle ID %d: This active
cable requires %d mW of power\n",
ioc->name, ActiveCableEventData->ReceptacleID,
ActiveCableEventData->ActiveCablePowerRequirement);
pr_notice(MPT3SAS_FMT "Receptacle ID %d: Devices
connected to this active cable will not be seen\n",
ioc->name,
ActiveCableEventData->ReceptacleID);
I believe MPT3SAS_FMT is unnecessary obfuscation and
it should just be replaced by "%s: " everywhere.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mpt3sas: Added print to notify cable running at a degraded speed.
On Fri, 2017-01-20 at 09:55 -0800, Joe Perches wrote:
> I believe MPT3SAS_FMT is unnecessary obfuscation and
> it should just be replaced by "%s: " everywhere.
Here's a trivial command that could be used one day:
$ git grep --name-only MPT3SAS_FMT -- "*.c" | \
xargs perl -p -i -e 'local $/; while (<>) { s/\bMPT3SAS_FMT\s*"/"%s: /g;
print; }'
--
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] scsi: lpfc: Replace BUG() with BUG_ON()
> "Shyam" == Shyam Saini writes: Shyam> Replace BUG() with BUG_ON() using coccinelle Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set elsiocb contexts to NULL after freeing it
> "Johannes" == Johannes Thumshirn writes: Johannes> Set the elsiocb contexts to NULL after freeing as others Johannes> depend on it. Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set elsiocb contexts to NULL after freeing it
> "Martin" == Martin K Petersen writes: > "Johannes" == Johannes Thumshirn writes: Johannes> Set the elsiocb contexts to NULL after freeing as others Johannes> depend on it. Martin> Applied to 4.11/scsi-queue. Replied to the wrong mail, sorry. This fix is already upstream. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] scsi: be2iscsi: Use GFP_ATOMIC under spin lock
> "Wei" == Wei Yongjun writes: Wei> From: Wei Yongjun A spin lock is taken Wei> here so we should use GFP_ATOMIC. Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sd: Cleaned up comment references to @sdp argument explanation.
> "John" == John Pittman writes: John> In sd.c there are two comment references to 'struct scsi_device John> *sdp' as an argument. One of the references has a typo and the John> other should be a reference to 'struct device *dev' instead. Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/12] qla2xxx: Feature updates for target.
On Thu, 2017-01-19 at 22:27 -0800, Himanshu Madhani wrote: > Please consider this updated series for inclusion in target-pending. Hello Himanshu, These patches have been applied on my scsi-target-for-v4.11 branch. Thank you for all the work you have done on addressing review comments. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 193041] New: iSCSI initiator: mkfs.ext4 + mount triggers kernel oops
https://bugzilla.kernel.org/show_bug.cgi?id=193041
Bug ID: 193041
Summary: iSCSI initiator: mkfs.ext4 + mount triggers kernel
oops
Product: IO/Storage
Version: 2.5
Kernel Version: v4.10-rc4
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: SCSI
Assignee: linux-scsi@vger.kernel.org
Reporter: bvanass...@acm.org
Regression: No
Created attachment 252661
--> https://bugzilla.kernel.org/attachment.cgi?id=252661&action=edit
netconsole output
The following command sequence worked with previous kernels but triggers a
kernel oops with kernel v4.10-rc4:
./restart-lio-iscsi
iscsiadm -m discovery -t st -p localhost
iscsiadm -m node -p localhost -l
mkfs.ext4 /dev/sda
mount /dev/sda /mnt
gdb translates the crash address into the following:
$ gdb ./drivers/scsi/iscsi_tcp.ko
(gdb) list *(iscsi_sw_tcp_xmit_segment+0x84)
0xf54 is in iscsi_sw_tcp_xmit_segment (drivers/scsi/iscsi_tcp.c:272).
267 struct iscsi_sw_tcp_conn *tcp_sw_conn = tcp_conn->dd_data;
268 struct socket *sk = tcp_sw_conn->sock;
269 unsigned int copied = 0;
270 int r = 0;
271
272 while (!iscsi_tcp_segment_done(tcp_conn, segment, 0, r)) {
273 struct scatterlist *sg;
274 unsigned int offset, copy;
275 int flags = 0;
276
--
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: [PATCH v2 0/7] hisi_sas: SATA IO workaround and other misc patches
> "John" == John Garry writes: John> This patchset introduces some misc fixes and improvements. Most John> signifigantly this patchset includes a workaround for a SATA IO John> issue on v2 hw (hip06/7). John> Differences v1->v2: - Add macro for SMP TIMEOUT in ITCT struct Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] virtio_scsi: Reject commands when virtqueue is broken
> "Eric" == Eric Farman writes: Eric> In the case of a graceful set of detaches, where the Eric> virtio-scsi-ccw disk is removed from the guest prior to the Eric> controller, the guest behaves quite normally. Specifically, the Eric> detach gets us into sd_sync_cache to issue a Synchronize Cache(10) Eric> command, which immediately fails (and is retried a couple of Eric> times) because the device has been removed. Later, the removal of Eric> the controller sees two CRWs presented, but there's no further Eric> indication of the removal from the guest viewpoint. Applied to 4.10/scsi-fixes. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_debug: Add OPTIMAL TRANSFER LENGTH GRANULARITY option.
> "Lukas" == Lukas Herbolt writes: Lukas, Lukas> I have been playing with scsi_debug and found that there is no Lukas> way how to change the minimum_io_size (OPTIMAL TRANSFER LENGTH Lukas> GRANULARITY reported by VPD 0xb0). Lukas> The current module has minimum_io_size always set to Lukas> physical_block_size. So here comes a small patch which add a new Lukas> option to this module to be able to set it independently to the Lukas> physical_block_size. Default behavior is to keep the Lukas> minimum_io_size equal to the physical_block_size. No objection to the functionality but I don't really like the naming scheme. There are many granularities in SBC so "gran" isn't particularly descriptive. How about opt_xferlen_exp or something like that? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] be2iscsi: switch to pci_alloc_irq_vectors
> "Christoph" == Christoph Hellwig writes: Christoph> And get automatic MSI-X affinity for free. Jitendra? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] csiostor: switch to pci_alloc_irq_vectors
> "Christoph" == Christoph Hellwig writes: Christoph> And get automatic MSI-X affinity for free. Chelsio folks: Please review and test! -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
