panic in mpt3sas driver in kernel-4.19

2018-11-14 Thread Yang Yingliang

Hi, all

When I run some stable tests on D05 board with kernel-4.19.0, I 
got this kernel panic twice:


first time:
[26994.792533] Kernel panic - not syncing: 4mpt3sas_cm0: 
_config_request: Firmware BUG: mpi_reply mismatch: Requested 
ExtPageType(0x12) Reply ExtPageType(0x10)

[26994.792533]
[26994.808583] CPU: 51 PID: 50166 Comm: kworker/u128:2 Tainted: 
G   OE 4.19.0-1.1.18.aarch64 #1
[26994.818283] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.55 
08/05/2018

[26994.825697] Workqueue: fw_event_mpt3sas0 _firmware_event_work
[26994.831567] Call trace:
[26994.834078]  dump_backtrace+0x0/0x1d0
[26994.837838]  show_stack+0x24/0x30
[26994.841234]  dump_stack+0x98/0xbc
[26994.844630]  panic+0x150/0x2c4
[26994.847756]  _config_request.constprop.5+0xa20/0xbc8
[26994.852846]  mpt3sas_config_get_sas_device_pg0+0xa4/0x100
[26994.858371]  _transport_set_identify+0x60/0x218
[26994.862975]  mpt3sas_transport_update_links+0xe4/0x248
[26994.868204]  _scsih_sas_host_refresh+0xec/0x1b0
[26994.872849]  _firmware_event_work+0x1ad0/0x2700
[26994.877494]  process_one_work+0x154/0x3c0
[26994.881588]  worker_thread+0x5c/0x478
[26994.885309]  kthread+0x108/0x138
[26994.888610]  ret_from_fork+0x10/0x18
[26994.892255] SMP: stopping secondary CPUs
---


second time:
170343.763389] Kernel panic - not syncing: 4mpt3sas_cm0: 
_config_request: Firmware BUG: config page mismatch: Requested 
PageType(0x0f) Reply PageType(0x00)

[170343.763389]
[170343.803812] CPU: 56 PID: 14403 Comm: kworker/u128:2 Tainted: 
G   OE 4.19.0-1.1.18.aarch64 #1
[170343.830092] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.55 
08/05/2018

[170343.845687] Workqueue: fw_event_mpt3sas0 _firmware_event_work
[170343.859726] Call trace:
[170343.870204]  dump_backtrace+0x0/0x1d0
[170343.881736]  show_stack+0x24/0x30
[170343.892852]  dump_stack+0x98/0xbc
[170343.903687]  panic+0x150/0x2c4
[170343.914110]  _config_request.constprop.5+0x88c/0xbc8
[170343.926431]  mpt3sas_config_get_sas_device_pg0+0xd0/0x100
[170343.939173]  _transport_set_identify+0x60/0x218
[170343.950820]  mpt3sas_transport_update_links+0xe4/0x248
[170343.963125]  _scsih_sas_host_refresh+0xec/0x1b0
[170343.974537]  _firmware_event_work+0x1ad0/0x2700
[170343.985733]  process_one_work+0x154/0x3c0
[170343.996513]  worker_thread+0x5c/0x478
[170344.006591]  kthread+0x108/0x138
[170344.015871]  ret_from_fork+0x10/0x18
[170344.025448] SMP: stopping secondary CPUs
---





[PATCH] iser: set sector for ambiguous mr status errors

2018-11-14 Thread Sagi Grimberg
If for some reason we failed to query the mr status, we need to make sure
to provide sufficient information for an ambiguous error (guard error on
sector 0).

Fixes: 0a7a08ad6f5f ("IB/iser: Implement check_protection")
Cc: 
Reported-by: Dan Carpenter 
Signed-off-by: Sagi Grimberg 
---
 drivers/infiniband/ulp/iser/iser_verbs.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/ulp/iser/iser_verbs.c 
b/drivers/infiniband/ulp/iser/iser_verbs.c
index 946b623ba5eb..ab137bafa8a8 100644
--- a/drivers/infiniband/ulp/iser/iser_verbs.c
+++ b/drivers/infiniband/ulp/iser/iser_verbs.c
@@ -1124,7 +1124,9 @@ u8 iser_check_task_pi_status(struct iscsi_iser_task 
*iser_task,
 IB_MR_CHECK_SIG_STATUS, _status);
if (ret) {
pr_err("ib_check_mr_status failed, ret %d\n", ret);
-   goto err;
+   /* Not alot we can do, return ambiguous guard error */
+   *sector = 0;
+   return 0x1;
}
 
if (mr_status.fail_status & IB_MR_CHECK_SIG_STATUS) {
@@ -1152,9 +1154,6 @@ u8 iser_check_task_pi_status(struct iscsi_iser_task 
*iser_task,
}
 
return 0;
-err:
-   /* Not alot we can do here, return ambiguous guard error */
-   return 0x1;
 }
 
 void iser_err_comp(struct ib_wc *wc, const char *type)
-- 
2.17.1



Re: [PATCH] qla2xxx: Add SysFS hook for FC-NVMe autoconnect

2018-11-14 Thread Ewan D. Milne
On Tue, 2018-11-13 at 09:49 -0800, Bart Van Assche wrote:
> On Tue, 2018-11-13 at 17:38 +, Madhani, Himanshu wrote:
> > On Nov 13, 2018, at 6:23 AM, Bart Van Assche  wrote:
> > > On Tue, 2018-11-13 at 01:02 +, Madhani, Himanshu wrote:
> > > > I see other drivers also use similar information populated for NVMe
> > > > Connection at boot time.
> > > 
> > > Hi Himanshu,
> > > 
> > > Which other drivers are you referring to?
> > > 
> > > Thanks,
> > > 
> > > Bart.
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri
> > vers/scsi/lpfc/lpfc_attr.c
> 
> Hello James,
> 
> Please either move the information exported by lpfc_nvme_info_show() into
> debugfs or split the information exported by that function into multiple
> sysfs attributes. Otherwise you will get flamed by Greg KH as soon as he
> encounters that code because of not following the rules explained in
> Documentation/filesystems/sysfs.txt.
> 
> Bart.

Better yet, is there some way we could get at least the connection
information needed for discovery moved into the NVMe/FC transport
layer so that we don't need to have separate implementations that
have to be parsed?

-Ewan