[Bug 198839] Backport of the Linux MegaRAID driver for SAS based RAID controllers
https://bugzilla.kernel.org/show_bug.cgi?id=198839 --- Comment #2 from doru iorgulescu (doru.iorgules...@gmail.com) --- Hi, The problem is in kernel 4.9.82 #define MEGASAS_VERSION "06.811.02.00-rc1" For kernel 4.14.20 is OK #define MEGASAS_VERSION "07.702.06.00-rc1" 5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3508 (rev 01) Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508 (Integrated RAID Module RMSP3CD080F) Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0 Memory at 38f0 (64-bit, prefetchable) [size=1M] Memory at 38e0 (64-bit, prefetchable) [size=1M] Memory at b880 (32-bit, non-prefetchable) [size=1M] I/O ports at 8000 [size=256] Expansion ROM at [disabled] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [b0] MSI-X: Enable+ Count=128 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [148] Power Budgeting Regards, Capabilities: [158] Alternative Routing-ID Interpretation (ARI) Capabilities: [168] #19 Capabilities: [254] #16 Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1 Len=100 Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1 Len=038 Capabilities: [3bc] #15 Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas Regards, Doru Iorgulescu On Tue, Feb 20, 2018 at 9:07 AM,wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=198839 > > Sumit Saxena (sumit.sax...@broadcom.com) changed: > >What|Removed |Added > > > CC||sumit.sax...@broadcom.com > > --- Comment #1 from Sumit Saxena (sumit.sax...@broadcom.com) --- > (In reply to doru iorgulescu from comment #0) > > Created attachment 274257 [details] > > Backport of the Linux MegaRAID driver for SAS based RAID controllers > > > > Backport of the Linux MegaRAID driver for SAS based RAID controllers > > > > backport of the megaraid_sas driver from kernel 4.14.20 to kernel 4.9.82 > > > > Hi, > > > > Hardware: > > DMI: Intel Corporation S2600WFT/S2600WFT, BIOS > > SE5C620.86B.00.01.0009.101920170742 10/19/2017 > > > > I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid to > > /usr/src/linux-4.9.82/drivers/scsi/megaraid . I compile the kernel > 4.9.82 > > and is OK ! > > I send dmesg atached. > > > > > > The problem for original linux kernel 4.9.82 is : > > > > 5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode > > SAS3508 (rev 01) > > Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508 > (Integrated > > RAID Module RMSP3CD080F) > > Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0 > > Memory at 38f0 (64-bit, prefetchable) [size=1M] > > Memory at 38e0 (64-bit, prefetchable) [size=1M] > > Memory at b880 (32-bit, non-prefetchable) [size=1M] > > I/O ports at 8000 [size=256] > > Expansion ROM at [disabled] > > Capabilities: [40] Power Management version 3 > > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ > > Capabilities: [70] Express Endpoint, MSI 00 > > Capabilities: [b0] MSI-X: Enable+ Count=128 Masked- > > Capabilities: [d0] Vital Product Data > > Capabilities: [100] Advanced Error Reporting > > Capabilities: [148] Power Budgeting Regards, > > Capabilities: [158] Alternative Routing-ID Interpretation (ARI) > > Capabilities: [168] #19 > > Capabilities: [254] #16 > > Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1 > > Len=100 > > Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1 > > Len=038 > > Capabilities: [3bc] #15 > > Kernel driver in use: megaraid_sas > > Kernel modules: megaraid_sas > > > > Regards, > > Doru Iorgulescu > > Hi Doru, > > I have gone through the attached logs and observed some prints about > hibernation failure. > -- > [3.788370] PM: Starting manual resume from disk > [3.788375] PM: Hibernation image partition 8:9 present > [3.788377] PM: Looking for hibernation image. > [3.788638] PM: Image not found (code -22) > [3.788640] PM: Hibernation image not present or could not be loaded. > -- > > Is it the problem you are trying to point ? Please clarify. > Is it regression from 4.14.20 to 4.9.82 due to megaraid_sas driver > backporting > ? > > > Thanks, > Sumit > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail
[Bug 198839] Backport of the Linux MegaRAID driver for SAS based RAID controllers
https://bugzilla.kernel.org/show_bug.cgi?id=198839 Sumit Saxena (sumit.sax...@broadcom.com) changed: What|Removed |Added CC||sumit.sax...@broadcom.com --- Comment #1 from Sumit Saxena (sumit.sax...@broadcom.com) --- (In reply to doru iorgulescu from comment #0) > Created attachment 274257 [details] > Backport of the Linux MegaRAID driver for SAS based RAID controllers > > Backport of the Linux MegaRAID driver for SAS based RAID controllers > > backport of the megaraid_sas driver from kernel 4.14.20 to kernel 4.9.82 > > Hi, > > Hardware: > DMI: Intel Corporation S2600WFT/S2600WFT, BIOS > SE5C620.86B.00.01.0009.101920170742 10/19/2017 > > I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid to > /usr/src/linux-4.9.82/drivers/scsi/megaraid . I compile the kernel 4.9.82 > and is OK ! > I send dmesg atached. > > > The problem for original linux kernel 4.9.82 is : > > 5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode > SAS3508 (rev 01) > Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508 (Integrated > RAID Module RMSP3CD080F) > Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0 > Memory at 38f0 (64-bit, prefetchable) [size=1M] > Memory at 38e0 (64-bit, prefetchable) [size=1M] > Memory at b880 (32-bit, non-prefetchable) [size=1M] > I/O ports at 8000 [size=256] > Expansion ROM at [disabled] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ > Capabilities: [70] Express Endpoint, MSI 00 > Capabilities: [b0] MSI-X: Enable+ Count=128 Masked- > Capabilities: [d0] Vital Product Data > Capabilities: [100] Advanced Error Reporting > Capabilities: [148] Power Budgeting Regards, > Capabilities: [158] Alternative Routing-ID Interpretation (ARI) > Capabilities: [168] #19 > Capabilities: [254] #16 > Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1 > Len=100 > Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1 > Len=038 > Capabilities: [3bc] #15 > Kernel driver in use: megaraid_sas > Kernel modules: megaraid_sas > > Regards, > Doru Iorgulescu Hi Doru, I have gone through the attached logs and observed some prints about hibernation failure. -- [3.788370] PM: Starting manual resume from disk [3.788375] PM: Hibernation image partition 8:9 present [3.788377] PM: Looking for hibernation image. [3.788638] PM: Image not found (code -22) [3.788640] PM: Hibernation image not present or could not be loaded. -- Is it the problem you are trying to point ? Please clarify. Is it regression from 4.14.20 to 4.9.82 due to megaraid_sas driver backporting ? Thanks, Sumit -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 198839] New: Backport of the Linux MegaRAID driver for SAS based RAID controllers
https://bugzilla.kernel.org/show_bug.cgi?id=198839 Bug ID: 198839 Summary: Backport of the Linux MegaRAID driver for SAS based RAID controllers Product: SCSI Drivers Version: 2.5 Kernel Version: 4.9.82 4.14.20 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Other Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org Reporter: doru.iorgules...@gmail.com Regression: No Created attachment 274257 --> https://bugzilla.kernel.org/attachment.cgi?id=274257=edit Backport of the Linux MegaRAID driver for SAS based RAID controllers Backport of the Linux MegaRAID driver for SAS based RAID controllers backport of the megaraid_sas driver from kernel 4.14.20 to kernel 4.9.82 Hi, Hardware: DMI: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0009.101920170742 10/19/2017 I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid to /usr/src/linux-4.9.82/drivers/scsi/megaraid . I compile the kernel 4.9.82 and is OK ! I send dmesg atached. The problem for original linux kernel 4.9.82 is : 5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3508 (rev 01) Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508 (Integrated RAID Module RMSP3CD080F) Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0 Memory at 38f0 (64-bit, prefetchable) [size=1M] Memory at 38e0 (64-bit, prefetchable) [size=1M] Memory at b880 (32-bit, non-prefetchable) [size=1M] I/O ports at 8000 [size=256] Expansion ROM at [disabled] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [b0] MSI-X: Enable+ Count=128 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [148] Power Budgeting Regards, Capabilities: [158] Alternative Routing-ID Interpretation (ARI) Capabilities: [168] #19 Capabilities: [254] #16 Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1 Len=100 Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1 Len=038 Capabilities: [3bc] #15 Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas Regards, Doru Iorgulescu -- You are receiving this mail because: You are watching the assignee of the bug.
Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")
> As already explained in the previous mail, there is a fixup for this in > commit 81b6c9998979 ('scsi: core: check for device state in > __scsi_remove_target()'). > Please check if this is applied, too. I tested commit 81b6c9998979 cherry-picked on top of 4.14.20 and it indeed solves the problem. Can it be backported to 4.14 LTS, please?
[PATCH] mvsas: fix wrong endianess of sgpio api
From: Wilfried Weissmann--- drivers/scsi/mvsas/mv_94xx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mvsas/mv_94xx.c b/drivers/scsi/mvsas/mv_94xx.c index 7de5d8d75..926086f39 100644 --- a/drivers/scsi/mvsas/mv_94xx.c +++ b/drivers/scsi/mvsas/mv_94xx.c @@ -1088,7 +1088,7 @@ static int mvs_94xx_gpio_write(struct mvs_prv_info *mvs_prv, * if bit is set then create a mask with the first * bit of the drive set in the mask ... */ - u32 bit = (write_data[i/8] & (1 << (i&(8-1 ? + u32 bit = (write_data[3-(i/8)] & (1 << (i&(8-1 ? 1<<(24-drive*8) : 0; /* @@ -1132,7 +1132,7 @@ static int mvs_94xx_gpio_write(struct mvs_prv_info *mvs_prv, void __iomem *regs = mvi->regs_ex - 0x10200; mw32(MVS_SGPIO_DCTRL + MVS_SGPIO_HOST_OFFSET * mvi->id, - be32_to_cpu(((u32 *) write_data)[i])); + le32_to_cpu(((u32 *) write_data)[i])); } return reg_count; }
[PATCH] mvsas: fix wrong endianess of sgpio api
The SGPIO api is little endian. This patch fixes the byte order and brings it back to sync with ledmon v0.80 and above.
[PATCH 4/8] scsi: hisi_sas: fix the issue of setting linkrate register
From: Xiaofei TanIt is not right to set the register PROG_PHY_LINK_RATE while PHY is still enabled. So if we want to change PHY linkrate, we need to disable PHY before setting the register PROG_PHY_LINK_RATE, and then start-up PHY. This patch is to fix this issue. Signed-off-by: Xiaofei Tan Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 5 +++-- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 5 +++-- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 5 +++-- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c index 38bbda9..2eb8980 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c @@ -881,10 +881,11 @@ static void phy_set_linkrate_v1_hw(struct hisi_hba *hisi_hba, int phy_no, prog_phy_link_rate &= ~0xff; prog_phy_link_rate |= rate_mask; + disable_phy_v1_hw(hisi_hba, phy_no); + msleep(100); hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE, prog_phy_link_rate); - - phy_hard_reset_v1_hw(hisi_hba, phy_no); + start_phy_v1_hw(hisi_hba, phy_no); } static int get_wideport_bitmap_v1_hw(struct hisi_hba *hisi_hba, int port_id) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c index 662d259..357138f 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c @@ -1611,10 +1611,11 @@ static void phy_set_linkrate_v2_hw(struct hisi_hba *hisi_hba, int phy_no, prog_phy_link_rate &= ~0xff; prog_phy_link_rate |= rate_mask; + disable_phy_v2_hw(hisi_hba, phy_no); + msleep(100); hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE, prog_phy_link_rate); - - phy_hard_reset_v2_hw(hisi_hba, phy_no); + start_phy_v2_hw(hisi_hba, phy_no); } static int get_wideport_bitmap_v2_hw(struct hisi_hba *hisi_hba, int port_id) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index 1ee95ab..8da9de7 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -1862,10 +1862,11 @@ static void phy_set_linkrate_v3_hw(struct hisi_hba *hisi_hba, int phy_no, prog_phy_link_rate &= ~0xff; prog_phy_link_rate |= rate_mask; + disable_phy_v3_hw(hisi_hba, phy_no); + msleep(100); hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE, prog_phy_link_rate); - - phy_hard_reset_v3_hw(hisi_hba, phy_no); + start_phy_v3_hw(hisi_hba, phy_no); } static void interrupt_disable_v3_hw(struct hisi_hba *hisi_hba) -- 1.9.1
[PATCH 6/8] scsi: hisi_sas: remove unused variable hisi_sas_devices.running_req
From: Xiang ChenThe structure element hisi_sas_devices.running_req to count how many commands are active is in effect only ever written in the code, so remove it. Signed-off-by: Xiang Chen Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas.h | 1 - drivers/scsi/hisi_sas/hisi_sas_main.c | 9 - drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 3 --- 3 files changed, 13 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h index e7fd287..d1153e8 100644 --- a/drivers/scsi/hisi_sas/hisi_sas.h +++ b/drivers/scsi/hisi_sas/hisi_sas.h @@ -175,7 +175,6 @@ struct hisi_sas_device { struct hisi_sas_dq *dq; struct list_headlist; u64 attached_phy; - atomic64_t running_req; enum sas_device_typedev_type; int device_id; int sata_idx; diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index 9ff8790..88ad8d4 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -200,8 +200,6 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba, struct sas_task *task, if (task) { struct device *dev = hisi_hba->dev; - struct domain_device *device = task->dev; - struct hisi_sas_device *sas_dev = device->lldd_dev; if (!task->lldd_task) return; @@ -213,9 +211,6 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba, struct sas_task *task, dma_unmap_sg(dev, task->scatter, task->num_scatter, task->data_dir); - - if (sas_dev) - atomic64_dec(_dev->running_req); } if (slot->buf) @@ -431,8 +426,6 @@ static int hisi_sas_task_prep(struct sas_task *task, struct hisi_sas_dq spin_unlock_irqrestore(>task_state_lock, flags); dq->slot_prep = slot; - - atomic64_inc(_dev->running_req); ++(*pass); return 0; @@ -1517,8 +1510,6 @@ static int hisi_sas_query_task(struct sas_task *task) dq->slot_prep = slot; - atomic64_inc(_dev->running_req); - /* send abort command to the chip */ hisi_hba->hw->start_delivery(dq); spin_unlock_irqrestore(>lock, flags_dq); diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c index 2eb8980..8dd0e6a6 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c @@ -1407,9 +1407,6 @@ static int slot_complete_v1_hw(struct hisi_hba *hisi_hba, } out: - if (sas_dev) - atomic64_dec(_dev->running_req); - hisi_sas_slot_task_free(hisi_hba, task, slot); sts = ts->stat; -- 1.9.1
[PATCH 8/8] scsi: hisi_sas: Code cleanup and minor bug fixes
From: Xiang ChenThe patch does some code cleanup and fixes some small bugs: - Correct return status of phy_up_v3_hw() - Add static for function phy_get_max_linkrate_v3_hw() - Change exception return status when no reset method - Change magic value to ts->stat in slot_complete_vx_hw() - Remove unnecessary check for dev_is_sata() - Fix some issues of alignment and indents (Authored by Xiaofei Tan in another patch, but added here to be practical) Signed-off-by: Xiaofei Tan Signed-off-by: Xiang Chen Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas_main.c | 14 +++--- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 4 +++- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 10 ++ drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 16 +--- 4 files changed, 25 insertions(+), 19 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index dff9723..49c1fa6 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -33,7 +33,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int direction) case ATA_CMD_FPDMA_RECV: case ATA_CMD_FPDMA_SEND: case ATA_CMD_NCQ_NON_DATA: - return HISI_SAS_SATA_PROTOCOL_FPDMA; + return HISI_SAS_SATA_PROTOCOL_FPDMA; case ATA_CMD_DOWNLOAD_MICRO: case ATA_CMD_ID_ATA: @@ -45,7 +45,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int direction) case ATA_CMD_WRITE_LOG_EXT: case ATA_CMD_PIO_WRITE: case ATA_CMD_PIO_WRITE_EXT: - return HISI_SAS_SATA_PROTOCOL_PIO; + return HISI_SAS_SATA_PROTOCOL_PIO; case ATA_CMD_DSM: case ATA_CMD_DOWNLOAD_MICRO_DMA: @@ -64,7 +64,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int direction) case ATA_CMD_WRITE_LOG_DMA_EXT: case ATA_CMD_WRITE_STREAM_DMA_EXT: case ATA_CMD_ZAC_MGMT_IN: - return HISI_SAS_SATA_PROTOCOL_DMA; + return HISI_SAS_SATA_PROTOCOL_DMA; case ATA_CMD_CHK_POWER: case ATA_CMD_DEV_RESET: @@ -77,21 +77,21 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int direction) case ATA_CMD_STANDBY: case ATA_CMD_STANDBYNOW1: case ATA_CMD_ZAC_MGMT_OUT: - return HISI_SAS_SATA_PROTOCOL_NONDATA; + return HISI_SAS_SATA_PROTOCOL_NONDATA; default: { if (fis->command == ATA_CMD_SET_MAX) { switch (fis->features) { case ATA_SET_MAX_PASSWD: case ATA_SET_MAX_LOCK: - return HISI_SAS_SATA_PROTOCOL_PIO; + return HISI_SAS_SATA_PROTOCOL_PIO; case ATA_SET_MAX_PASSWD_DMA: case ATA_SET_MAX_UNLOCK_DMA: - return HISI_SAS_SATA_PROTOCOL_DMA; + return HISI_SAS_SATA_PROTOCOL_DMA; default: - return HISI_SAS_SATA_PROTOCOL_NONDATA; + return HISI_SAS_SATA_PROTOCOL_NONDATA; } } if (direction == DMA_NONE) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c index 8dd0e6a6..520ba69 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c @@ -651,8 +651,10 @@ static int reset_hw_v1_hw(struct hisi_hba *hisi_hba) dev_err(dev, "De-reset failed\n"); return -EIO; } - } else + } else { dev_warn(dev, "no reset method\n"); + return -EIO; + } 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 357138f..f2cddff 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c @@ -1095,8 +1095,10 @@ static int reset_hw_v2_hw(struct hisi_hba *hisi_hba) dev_err(dev, "SAS de-reset fail.\n"); return -EIO; } - } else - dev_warn(dev, "no reset method\n"); + } else { + dev_err(dev, "no reset method\n"); + return -EIO; + } return 0; } @@ -2408,7 +2410,7 @@ static void slot_err_v2_hw(struct hisi_hba *hisi_hba, spin_lock_irqsave(_hba->lock, flags); hisi_sas_slot_task_free(hisi_hba, task, slot); spin_unlock_irqrestore(_hba->lock, flags); - return -1; + return ts->stat; } if (unlikely(!sas_dev)) { @@ -2667,7 +2669,7 @@ static int prep_abort_v2_hw(struct hisi_hba *hisi_hba, /* dw0 */ hdr->dw0 = cpu_to_le32((5
[PATCH 5/8] scsi: hisi_sas: increase timer expire of internal abort task
From: Xiaofei TanThe current 110ms expiry time is not long enough for the internal abort task. The reason is that the internal abort task could be blocked in HW if the HW is retrying to set up link. The internal abort task will be executed only when the retry process finished. The maximum time is 5s for the retry of setting up link. So, the timer expire should be more than 5s. This patch increases it from 110ms to 6s. Signed-off-by: Xiaofei Tan Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index 9d16372..9ff8790 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -871,6 +871,7 @@ static void hisi_sas_tmf_timedout(struct timer_list *t) #define TASK_TIMEOUT 20 #define TASK_RETRY 3 +#define INTERNAL_ABORT_TIMEOUT 6 static int hisi_sas_exec_internal_tmf_task(struct domain_device *device, void *parameter, u32 para_len, struct hisi_sas_tmf_task *tmf) @@ -1574,7 +1575,7 @@ static int hisi_sas_query_task(struct sas_task *task) task->task_proto = device->tproto; task->task_done = hisi_sas_task_done; task->slow_task->timer.function = hisi_sas_tmf_timedout; - task->slow_task->timer.expires = jiffies + msecs_to_jiffies(110); + task->slow_task->timer.expires = jiffies + INTERNAL_ABORT_TIMEOUT*HZ; add_timer(>slow_task->timer); res = hisi_sas_internal_abort_task_exec(hisi_hba, sas_dev->device_id, -- 1.9.1
[PATCH 3/8] scsi: hisi_sas: fix the issue of link rate inconsistency
From: Xiaofei TanIn sysfs, there are two files about minimum linkrate, and also two files for maximum linkrate. Take maximum linkrate example, maximum_linkrate_hw is read-only and indicated by the register HARD_PHY_LINKRATE, and maximum_linkrate is read-write and corresponding to the register PROG_PHY_LINK_RATE. But in the function phy_up_v*_hw(), we get *_linkrate value from HARD_PHY_LINKRATE. It is not right. This patch is to fix this issue. Unreferenced PHY-interrupt enum is also removed for v3 hw. Signed-off-by: Xiaofei Tan Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas_main.c | 2 ++ drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 1 - drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 8 +--- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 13 + 4 files changed, 4 insertions(+), 20 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index 2d4dbed..9d16372 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -683,6 +683,8 @@ static void hisi_sas_phy_init(struct hisi_hba *hisi_hba, int phy_no) phy->hisi_hba = hisi_hba; phy->port = NULL; + phy->minimum_linkrate = SAS_LINK_RATE_1_5_GBPS; + phy->maximum_linkrate = hisi_hba->hw->phy_get_max_linkrate(); sas_phy->enabled = (phy_no < hisi_hba->n_phy) ? 1 : 0; sas_phy->class = SAS; sas_phy->iproto = SAS_PROTOCOL_ALL; diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c index 679e76f..38bbda9 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c @@ -873,7 +873,6 @@ static void phy_set_linkrate_v1_hw(struct hisi_hba *hisi_hba, int phy_no, sas_phy->phy->maximum_linkrate = max; sas_phy->phy->minimum_linkrate = min; - min -= SAS_LINK_RATE_1_5_GBPS; max -= SAS_LINK_RATE_1_5_GBPS; for (i = 0; i <= max; i++) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c index ab6db50..662d259 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c @@ -1603,7 +1603,6 @@ static void phy_set_linkrate_v2_hw(struct hisi_hba *hisi_hba, int phy_no, sas_phy->phy->maximum_linkrate = max; sas_phy->phy->minimum_linkrate = min; - min -= SAS_LINK_RATE_1_5_GBPS; max -= SAS_LINK_RATE_1_5_GBPS; for (i = 0; i <= max; i++) @@ -2684,7 +2683,7 @@ static int prep_abort_v2_hw(struct hisi_hba *hisi_hba, static int phy_up_v2_hw(int phy_no, struct hisi_hba *hisi_hba) { int i, res = IRQ_HANDLED; - u32 port_id, link_rate, hard_phy_linkrate; + u32 port_id, link_rate; struct hisi_sas_phy *phy = _hba->phy[phy_no]; struct asd_sas_phy *sas_phy = >sas_phy; struct device *dev = hisi_hba->dev; @@ -2723,11 +2722,6 @@ static int phy_up_v2_hw(int phy_no, struct hisi_hba *hisi_hba) } sas_phy->linkrate = link_rate; - hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no, - HARD_PHY_LINKRATE); - phy->maximum_linkrate = hard_phy_linkrate & 0xf; - phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf; - sas_phy->oob_mode = SAS_OOB_MODE; memcpy(sas_phy->attached_sas_addr, >sas_addr, SAS_ADDR_SIZE); dev_info(dev, "phyup: phy%d link_rate=%d\n", phy_no, link_rate); diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index a1f1868..1ee95ab 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -340,12 +340,6 @@ struct hisi_sas_err_record_v3 { #define HISI_SAS_COMMAND_ENTRIES_V3_HW 4096 #define HISI_SAS_MSI_COUNT_V3_HW 32 -enum { - HISI_SAS_PHY_PHY_UPDOWN, - HISI_SAS_PHY_CHNL_INT, - HISI_SAS_PHY_INT_NR -}; - #define DIR_NO_DATA 0 #define DIR_TO_INI 1 #define DIR_TO_DEVICE 2 @@ -1121,7 +1115,7 @@ static int prep_abort_v3_hw(struct hisi_hba *hisi_hba, static int phy_up_v3_hw(int phy_no, struct hisi_hba *hisi_hba) { int i, res = 0; - u32 context, port_id, link_rate, hard_phy_linkrate; + u32 context, port_id, link_rate; struct hisi_sas_phy *phy = _hba->phy[phy_no]; struct asd_sas_phy *sas_phy = >sas_phy; struct device *dev = hisi_hba->dev; @@ -1139,10 +1133,6 @@ static int phy_up_v3_hw(int phy_no, struct hisi_hba *hisi_hba) goto end; } sas_phy->linkrate = link_rate; - hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no, - HARD_PHY_LINKRATE); - phy->maximum_linkrate = hard_phy_linkrate & 0xf; - phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf; phy->phy_type &= ~(PORT_TYPE_SAS | PORT_TYPE_SATA); /* Check for SATA
[PATCH 0/8] hisi_sas: support x6000 board and some misc changes
This patchset primarily adds support for the Huawei x6000 board, which includes hip07 chipset. Unfortunately, due to some board layout differences with our development board, we need to set a PHY-related register differently for optimal signal quality. As such, a signal attenuation property is added to describe the differences in the boards and allow the PHY register to be set appropriately. In addition to this above feature, some misc changes are added for: - PHY linkrate sysfs interface - linkrate set function - internal abort timer timeout increase Xiang Chen (2): scsi: hisi_sas: remove unused variable hisi_sas_devices.running_req scsi: hisi_sas: Code cleanup and minor bug fixes Xiaofei Tan (6): dt-bindings: scsi: hisi_sas: add an property of signal attenuation scsi: hisi_sas: support the property of signal attenuation for v2 hw scsi: hisi_sas: fix the issue of link rate inconsistency scsi: hisi_sas: fix the issue of setting linkrate register scsi: hisi_sas: increase timer expire of internal abort task scsi: hisi_sas: fix return value of hisi_sas_task_prep() .../devicetree/bindings/scsi/hisilicon-sas.txt | 7 +++ drivers/scsi/hisi_sas/hisi_sas.h | 1 - drivers/scsi/hisi_sas/hisi_sas_main.c | 34 +--- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 13 +++-- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 62 +- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 34 +--- 6 files changed, 88 insertions(+), 63 deletions(-) -- 1.9.1
[PATCH 7/8] scsi: hisi_sas: fix return value of hisi_sas_task_prep()
From: Xiaofei TanIt is an implicit regulation that error code that function returned should be negative. But hisi_sas_task_prep() doesn't follow this. This may cause problems in the upper layer code. For example, in sas_expander.c of libsas, smp_execute_task_sg() may return the number of bytes of underrun. It will be conflicted with the scenaio lldd_execute_task() return an positive error code. This patch change the return value from SAS_PHY_DOWN to -ECOMM in hisi_sas_task_prep(). Signed-off-by: Xiaofei Tan Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index 88ad8d4..dff9723 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -316,7 +316,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct hisi_sas_dq */ if (device->dev_type != SAS_SATA_DEV) task->task_done(task); - return SAS_PHY_DOWN; + return -ECOMM; } if (DEV_IS_GONE(sas_dev)) { @@ -327,7 +327,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct hisi_sas_dq dev_info(dev, "task prep: device %016llx not ready\n", SAS_ADDR(device->sas_addr)); - return SAS_PHY_DOWN; + return -ECOMM; } port = to_hisi_sas_port(sas_port); @@ -337,7 +337,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct hisi_sas_dq "SATA/STP" : "SAS", device->port->id); - return SAS_PHY_DOWN; + return -ECOMM; } if (!sas_protocol_ata(task->task_proto)) { -- 1.9.1
[PATCH 2/8] scsi: hisi_sas: support the property of signal attenuation for v2 hw
From: Xiaofei TanThe register SAS_PHY_CTRL is configured according to signal quality. The signal quality is calculated by signal attenuation of hardware physical link. It may be different for different PCB layout. So, in order to give better support to new board, this patch add support to reading the devicetree property, signal-attenuation. Of course, we still keep an default value in driver to adapt old board. Signed-off-by: Xiaofei Tan Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 39 +- 1 file changed, 38 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 4ccb61e..ab6db50 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c @@ -406,6 +406,17 @@ struct hisi_sas_err_record_v2 { __le32 dma_rx_err_type; }; +struct signal_attenuation_s { + u32 de_emphasis; + u32 preshoot; + u32 boost; +}; + +struct sig_atten_lu_s { + const struct signal_attenuation_s *att; + u32 sas_phy_ctrl; +}; + static const struct hisi_sas_hw_error one_bit_ecc_errors[] = { { .irq_msk = BIT(SAS_ECC_INTR_DQE_ECC_1B_OFF), @@ -1130,9 +1141,16 @@ static void phys_try_accept_stp_links_v2_hw(struct hisi_hba *hisi_hba) } } +static const struct signal_attenuation_s x6000 = {9200, 0, 10476}; +static const struct sig_atten_lu_s sig_atten_lu[] = { + { , 0x3016a68 }, +}; + static void init_reg_v2_hw(struct hisi_hba *hisi_hba) { struct device *dev = hisi_hba->dev; + u32 sas_phy_ctrl = 0x30b9908; + u32 signal[3]; int i; /* Global registers init */ @@ -1176,9 +1194,28 @@ static void init_reg_v2_hw(struct hisi_hba *hisi_hba) hisi_sas_write32(hisi_hba, AXI_AHB_CLK_CFG, 1); hisi_sas_write32(hisi_hba, HYPER_STREAM_ID_EN_CFG, 1); + /* Get sas_phy_ctrl value to deal with TX FFE issue. */ + if (!device_property_read_u32_array(dev, "signal-attenuation", + signal, ARRAY_SIZE(signal))) { + for (i = 0; i < ARRAY_SIZE(sig_atten_lu); i++) { + const struct sig_atten_lu_s *lookup = _atten_lu[i]; + const struct signal_attenuation_s *att = lookup->att; + + if ((signal[0] == att->de_emphasis) && + (signal[1] == att->preshoot) && + (signal[2] == att->boost)) { + sas_phy_ctrl = lookup->sas_phy_ctrl; + break; + } + } + + if (i == ARRAY_SIZE(sig_atten_lu)) + dev_warn(dev, "unknown signal attenuation values, using default PHY ctrl config\n"); + } + for (i = 0; i < hisi_hba->n_phy; i++) { hisi_sas_phy_write32(hisi_hba, i, PROG_PHY_LINK_RATE, 0x855); - hisi_sas_phy_write32(hisi_hba, i, SAS_PHY_CTRL, 0x30b9908); + hisi_sas_phy_write32(hisi_hba, i, SAS_PHY_CTRL, sas_phy_ctrl); hisi_sas_phy_write32(hisi_hba, i, SL_TOUT_CFG, 0x7d7d7d7d); hisi_sas_phy_write32(hisi_hba, i, SL_CONTROL, 0x0); hisi_sas_phy_write32(hisi_hba, i, TXID_AUTO, 0x2); -- 1.9.1
[PATCH 1/8] dt-bindings: scsi: hisi_sas: add an property of signal attenuation
From: Xiaofei TanFor some new boards with hip07 chipset we are required to set PHY config registers differently. The hw property which determines how to set these registers is in the PHY signal attenuation readings. This patch add an devicetree property, signal-attenuation, which is used to describe the signal attenuation of an board. Cc: Rob Herring Cc: Mark Rutland Signed-off-by: Xiaofei Tan Signed-off-by: John Garry --- Documentation/devicetree/bindings/scsi/hisilicon-sas.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt index df3bef7..bd32ecd 100644 --- a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt +++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt @@ -53,6 +53,13 @@ Main node required properties: Optional main node properties: - hip06-sas-v2-quirk-amt : when set, indicates that the v2 controller has the "am-max-transmissions" limitation. + - signal-attenuation : array of 3 32-bit values, containing de-emphasis, + preshoot, and boost attenuation readings for the board. They + are used to describe the signal attenuation of the board. These + values' range is 7600 to 12400, and used to represent -24dB to + 24dB. + The formula is "y = (x-1)/1". For example, 10478 + means 4.78dB. Example: sas0: sas@c100 { -- 1.9.1
Re: [PATCH] libiscsi: ensure session spin lock usage consistent
On 02/07/2018 09:17 PM, Chris Leech wrote: > I overlooked it by mentally swapping out the session->lock in the patch > for session->frwd_lock from the warning when looking at this, but what > kernel was this patch built against? It doesn't have the > frwd_lock/back_lock split stuff. > > - Chris > Please disregard this patch set. It was based on the wrong branch of linux-scsi. I will resubmit V2 soon. Thank you for your reviews. -- Lee Duncan
Re: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
On Tue, Feb 13, 2018 at 11:14 AM, Li Weiwrote: > add ufs node document for Hisilicon. > > Signed-off-by: Li Wei > --- > Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 37 > ++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt I'm pretty sure we've discussed it before, but can you make this so that the generic properties are part of the ufshcd binding, and you refer to it from here, only describing in what ways the hisi ufs binding differs from the standard? > diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > new file mode 100644 > index ..0d21b57496cf > --- /dev/null > +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > @@ -0,0 +1,37 @@ > +* Hisilicon Universal Flash Storage (UFS) Host Controller > + > +UFS nodes are defined to describe on-chip UFS hardware macro. > +Each UFS Host Controller should have its own node. > + > +Required properties: > +- compatible: compatible list, contains one of the following - > + "hisilicon,hi3660-ufs", > "jedec,ufs-1.1" for hisi ufs > + host controller present on Hi36xx > chipset. > +- reg : should contain UFS register address space & UFS SYS > CTRL register address, > +- interrupt-parent : interrupt device > +- interrupts: interrupt number > +- clocks : List of phandle and clock specifier pairs > +- clock-names : List of clock input name strings sorted in the same > + order as the clocks property. > "ref_clk", "phy_clk" is optional The clock names sound generic enough, should we have both in the generic binding? > +- resets: reset node register, one reset the clk and the other > reset the controller > +- reset-names : describe reset node register This looks incomplete. What is the name of the reset line supposed to be? I'd also suggest you document it in the ufshcd binding instead. Arnd
RE: [PATCH v2 1/2] scsi: mpt3sas: fix oops in error handlers after shutdown/unload
-Original Message- From: Mauricio Faria de Oliveira [mailto:mauri...@linux.vnet.ibm.com] Sent: Saturday, February 17, 2018 4:10 AM To: linux-scsi@vger.kernel.org; bart.vanass...@wdc.com; sreekanth.re...@broadcom.com Cc: sathya.prak...@broadcom.com; chaitra.basa...@broadcom.com; suganath-prabu.subram...@broadcom.com; j...@linux.vnet.ibm.com; martin.peter...@oracle.com; dougm...@linux.vnet.ibm.com Subject: [PATCH v2 1/2] scsi: mpt3sas: fix oops in error handlers after shutdown/unload This patch adds checks for 'ioc->remove_host' in the SCSI error handlers, so not to access pointers/resources potentially freed in the PCI shutdown/module unload path. The error handlers may be invoked after shutdown/unload, depending on other components. This problem was observed with kexec on a system with a mpt3sas based adapter and an infiniband adapter which takes long enough to shutdown: The mpt3sas driver finished shutting down / disabled interrupt handling, thus some commands have not finished and timed out. Since the system was still running (waiting for the infiniband adapter to shutdown), the scsi error handler for task abort of mpt3sas was invoked, and hit an oops -- either in scsih_abort() because 'ioc->scsi_lookup' was NULL (without commit dbec4c90 "scsi: mpt3sas: lockless command submission"), or later up in scsih_host_reset() (with or without that commit), because it eventually called mpt3sas_base_get_iocstate(). After commit dbec4c90, the oops in scsih_abort() does not occur anymore (_scsih_scsi_lookup_find_by_scmd() is no longer called), but that commit is too big and out of the scope of linux-stable, where this patch might help, so still go for the changes. Also, this might help to prevent similar errors in the future, in case code changes and possibly tries to access freed stuff. Note the fix in scsih_host_reset() is still important anyway. Signed-off-by: Mauricio Faria de Oliveira--- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index 74fca18..5ab3caf 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -2835,7 +2835,8 @@ int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, _scsih_tm_display_info(ioc, scmd); sas_device_priv_data = scmd->device->hostdata; - if (!sas_device_priv_data || !sas_device_priv_data->sas_target) { + if (!sas_device_priv_data || !sas_device_priv_data->sas_target || + ioc->remove_host) { sdev_printk(KERN_INFO, scmd->device, "device been deleted! scmd(%p)\n", scmd); scmd->result = DID_NO_CONNECT << 16; @@ -2898,7 +2899,8 @@ int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, _scsih_tm_display_info(ioc, scmd); sas_device_priv_data = scmd->device->hostdata; - if (!sas_device_priv_data || !sas_device_priv_data->sas_target) { + if (!sas_device_priv_data || !sas_device_priv_data->sas_target || + ioc->remove_host) { sdev_printk(KERN_INFO, scmd->device, "device been deleted! scmd(%p)\n", scmd); scmd->result = DID_NO_CONNECT << 16; @@ -2961,7 +2963,8 @@ int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, _scsih_tm_display_info(ioc, scmd); sas_device_priv_data = scmd->device->hostdata; - if (!sas_device_priv_data || !sas_device_priv_data->sas_target) { + if (!sas_device_priv_data || !sas_device_priv_data->sas_target || + ioc->remove_host) { starget_printk(KERN_INFO, starget, "target been deleted! scmd(%p)\n", scmd); scmd->result = DID_NO_CONNECT << 16; @@ -3019,7 +3022,7 @@ int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, ioc->name, scmd); scsi_print_command(scmd); - if (ioc->is_driver_loading) { + if (ioc->is_driver_loading || ioc->remove_host) { pr_info(MPT3SAS_FMT "Blocking the host reset\n", ioc->name); r = FAILED; -- 1.8.3.1 Acked-by: Sreekanth Reddy Thanks, Sreekanth
Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")
Neither it was backported: $ git log --grep 'commit 81b6c99' v4.14..v4.14.20 I'll try to apply it and see if it fixes my problem. If it does, what would be the proccess of backporting this patch to 4.14? On 19 February 2018 at 08:08, Max Ivanovwrote: > It seems that commit 81b6c9998979 ('scsi: core: check for device state > in __scsi_remove_target()') didn't make it to 4.14 branch > > $ git tag --contains 81b6c9998979 > v4.15 > v4.15-rc6 > v4.15-rc7 > v4.15-rc8 > v4.15-rc9 > v4.15.1 > v4.15.2 > v4.15.3 > v4.15.4 > v4.16-rc1 > v4.16-rc2 > > On 19 February 2018 at 06:56, Hannes Reinecke wrote: >> On 02/18/2018 07:33 PM, Max Ivanov wrote: >>> Hi, >>> >>> on my system I can't logout from iSCSI session when on 4.4.18, but >>> 4.3.19 works just fine. git bisect points to fbce4d97fd ("scsi: fixup >>> kernel warning during rmmod()") >>> >>> Bug manifests itself like following: >>> - iSCSI session logout hangs and never completes >>> - 1 kworker per iSCSI session start consuming 100% CPU >>> - very shortly one of 2 errors show up in dmesg (full listings are below): >>> * kernel: list_del corruption, 88c1cd6bb810->next is LIST_POISON1 >>> * kernel BUG at mm/slub.c:295! >>> >>> Ways to trigger bug: >>> 1. initiate iSCSI sessions to multiple portals >>> 2. let multipathd to create multipath devices >>> 3. run 'iscsiadm -m node --logoutall=all' >>> >>> Bugs is NOT triggered and iSCSI logout succeeds when either: >>> - multipathd is masked and never started >>> - I manually delete all scsi devices via /sys/block/$d/device/delete >>> before attempting >>> to do iSCSI logout >>> >>> list_del_corrpution: >>> >>> Feb 16 10:37:11 localhost.localdomain kernel: alua: device handler >>> registered >>> Feb 16 10:37:11 localhost.localdomain kernel: emc: device handler registered >>> Feb 16 10:37:11 localhost.localdomain kernel: rdac: device handler >>> registered >>> Feb 16 10:37:11 localhost.localdomain kernel: device-mapper: multipath >>> service-time: version 0.3.0 loaded >>> Feb 16 10:38:38 localhost.localdomain kernel: list_del corruption, >>> 88c1cd6bb810->next is LIST_POISON1 (dead0100) >>> Feb 16 10:38:38 localhost.localdomain kernel: [ cut here >>> ] >>> Feb 16 10:38:38 localhost.localdomain kernel: kernel BUG at >>> lib/list_debug.c:47! >>> Feb 16 10:38:38 localhost.localdomain kernel: invalid opcode: [#1] SMP >>> PTI >>> Feb 16 10:38:38 localhost.localdomain kernel: Modules linked in: >>> dm_service_time dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua >>> binfmt_misc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi >>> ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink >>> ebtable_nat ebtable_broute bridge stp llc ip6tabl >>> Feb 16 10:38:38 localhost.localdomain kernel: pata_acpi >>> Feb 16 10:38:38 localhost.localdomain kernel: CPU: 2 PID: 5 Comm: >>> kworker/u24:0 Not tainted 4.14.18-300.fc27.x86_64 #1 >>> Feb 16 10:38:38 localhost.localdomain kernel: Hardware name: VMware, >>> Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS >>> 6.00 09/21/2015 >>> Feb 16 10:38:38 localhost.localdomain kernel: Workqueue: scsi_wq_5 >>> __iscsi_unbind_session [scsi_transport_iscsi] >>> Feb 16 10:38:38 localhost.localdomain kernel: task: 88bdede83e80 >>> task.stack: b15043158000 >>> Feb 16 10:38:38 localhost.localdomain kernel: RIP: >>> 0010:__list_del_entry_valid+0x4e/0x90 >>> Feb 16 10:38:38 localhost.localdomain kernel: RSP: >>> 0018:b1504315bd88 EFLAGS: 00010082 >>> Feb 16 10:38:38 localhost.localdomain kernel: RAX: 004e >>> RBX: 88c1cd6bbf38 RCX: >>> Feb 16 10:38:38 localhost.localdomain kernel: RDX: >>> RSI: 88bdefc96a38 RDI: 88bdefc96a38 >>> Feb 16 10:38:38 localhost.localdomain kernel: RBP: 0246 >>> R08: 07be R09: 00aa >>> Feb 16 10:38:38 localhost.localdomain kernel: R10: b1504315bd58 >>> R11: R12: 88c1ebb659c0 >>> Feb 16 10:38:38 localhost.localdomain kernel: R13: 88bdec827010 >>> R14: 88c1cd6bb800 R15: 88c1cd6bb800 >>> Feb 16 10:38:38 localhost.localdomain kernel: FS: >>> () GS:88bdefc8() >>> knlGS: >>> Feb 16 10:38:38 localhost.localdomain kernel: CS: 0010 DS: ES: >>> CR0: 80050033 >>> Feb 16 10:38:38 localhost.localdomain kernel: CR2: 563d0c1ed280 >>> CR3: 00057120a001 CR4: 001606e0 >>> Feb 16 10:38:38 localhost.localdomain kernel: Call Trace: >>> Feb 16 10:38:38 localhost.localdomain kernel: >>> scsi_device_dev_release_usercontext+0x52/0x250 >>> Feb 16 10:38:38 localhost.localdomain kernel: ? __schedule+0x10f/0x880 >>> Feb 16 10:38:38 localhost.localdomain kernel: >>> execute_in_process_context+0x21/0x60 >>> Feb 16 10:38:38 localhost.localdomain kernel: device_release+0x30/0x80 >>> Feb 16 10:38:38 localhost.localdomain kernel:
Re: [PATCH v3 04/13] lpfc: Add push-to-adapter support to sli4
On Fri, Feb 16, 2018 at 08:53:44AM -0800, James Smart wrote: > > Any reason you can't use writeq() on 32 Bit as well? There's a compat > > version > > in linux/io-64-nonatomic-hi-lo.h. > > We actually ran into issues on the existence of writeq() on a 32bit > platform. Thus this code block. Oh can you elaborate more on the issue? I bet if we merge it that way, someone comes around with a patch chaning it to writeq() on 32Bit as well. Wouldn't it be better to improve the 32Bit writeq() code? Generally speaking (same for the WC issue), ifdefs (especially architecture specific ones) in driver code should be avoided. 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
Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")
It seems that commit 81b6c9998979 ('scsi: core: check for device state in __scsi_remove_target()') didn't make it to 4.14 branch $ git tag --contains 81b6c9998979 v4.15 v4.15-rc6 v4.15-rc7 v4.15-rc8 v4.15-rc9 v4.15.1 v4.15.2 v4.15.3 v4.15.4 v4.16-rc1 v4.16-rc2 On 19 February 2018 at 06:56, Hannes Reineckewrote: > On 02/18/2018 07:33 PM, Max Ivanov wrote: >> Hi, >> >> on my system I can't logout from iSCSI session when on 4.4.18, but >> 4.3.19 works just fine. git bisect points to fbce4d97fd ("scsi: fixup >> kernel warning during rmmod()") >> >> Bug manifests itself like following: >> - iSCSI session logout hangs and never completes >> - 1 kworker per iSCSI session start consuming 100% CPU >> - very shortly one of 2 errors show up in dmesg (full listings are below): >> * kernel: list_del corruption, 88c1cd6bb810->next is LIST_POISON1 >> * kernel BUG at mm/slub.c:295! >> >> Ways to trigger bug: >> 1. initiate iSCSI sessions to multiple portals >> 2. let multipathd to create multipath devices >> 3. run 'iscsiadm -m node --logoutall=all' >> >> Bugs is NOT triggered and iSCSI logout succeeds when either: >> - multipathd is masked and never started >> - I manually delete all scsi devices via /sys/block/$d/device/delete >> before attempting >> to do iSCSI logout >> >> list_del_corrpution: >> >> Feb 16 10:37:11 localhost.localdomain kernel: alua: device handler registered >> Feb 16 10:37:11 localhost.localdomain kernel: emc: device handler registered >> Feb 16 10:37:11 localhost.localdomain kernel: rdac: device handler registered >> Feb 16 10:37:11 localhost.localdomain kernel: device-mapper: multipath >> service-time: version 0.3.0 loaded >> Feb 16 10:38:38 localhost.localdomain kernel: list_del corruption, >> 88c1cd6bb810->next is LIST_POISON1 (dead0100) >> Feb 16 10:38:38 localhost.localdomain kernel: [ cut here >> ] >> Feb 16 10:38:38 localhost.localdomain kernel: kernel BUG at >> lib/list_debug.c:47! >> Feb 16 10:38:38 localhost.localdomain kernel: invalid opcode: [#1] SMP >> PTI >> Feb 16 10:38:38 localhost.localdomain kernel: Modules linked in: >> dm_service_time dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua >> binfmt_misc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi >> ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink >> ebtable_nat ebtable_broute bridge stp llc ip6tabl >> Feb 16 10:38:38 localhost.localdomain kernel: pata_acpi >> Feb 16 10:38:38 localhost.localdomain kernel: CPU: 2 PID: 5 Comm: >> kworker/u24:0 Not tainted 4.14.18-300.fc27.x86_64 #1 >> Feb 16 10:38:38 localhost.localdomain kernel: Hardware name: VMware, >> Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS >> 6.00 09/21/2015 >> Feb 16 10:38:38 localhost.localdomain kernel: Workqueue: scsi_wq_5 >> __iscsi_unbind_session [scsi_transport_iscsi] >> Feb 16 10:38:38 localhost.localdomain kernel: task: 88bdede83e80 >> task.stack: b15043158000 >> Feb 16 10:38:38 localhost.localdomain kernel: RIP: >> 0010:__list_del_entry_valid+0x4e/0x90 >> Feb 16 10:38:38 localhost.localdomain kernel: RSP: >> 0018:b1504315bd88 EFLAGS: 00010082 >> Feb 16 10:38:38 localhost.localdomain kernel: RAX: 004e >> RBX: 88c1cd6bbf38 RCX: >> Feb 16 10:38:38 localhost.localdomain kernel: RDX: >> RSI: 88bdefc96a38 RDI: 88bdefc96a38 >> Feb 16 10:38:38 localhost.localdomain kernel: RBP: 0246 >> R08: 07be R09: 00aa >> Feb 16 10:38:38 localhost.localdomain kernel: R10: b1504315bd58 >> R11: R12: 88c1ebb659c0 >> Feb 16 10:38:38 localhost.localdomain kernel: R13: 88bdec827010 >> R14: 88c1cd6bb800 R15: 88c1cd6bb800 >> Feb 16 10:38:38 localhost.localdomain kernel: FS: >> () GS:88bdefc8() >> knlGS: >> Feb 16 10:38:38 localhost.localdomain kernel: CS: 0010 DS: ES: >> CR0: 80050033 >> Feb 16 10:38:38 localhost.localdomain kernel: CR2: 563d0c1ed280 >> CR3: 00057120a001 CR4: 001606e0 >> Feb 16 10:38:38 localhost.localdomain kernel: Call Trace: >> Feb 16 10:38:38 localhost.localdomain kernel: >> scsi_device_dev_release_usercontext+0x52/0x250 >> Feb 16 10:38:38 localhost.localdomain kernel: ? __schedule+0x10f/0x880 >> Feb 16 10:38:38 localhost.localdomain kernel: >> execute_in_process_context+0x21/0x60 >> Feb 16 10:38:38 localhost.localdomain kernel: device_release+0x30/0x80 >> Feb 16 10:38:38 localhost.localdomain kernel: kobject_put+0x80/0x1a0 >> Feb 16 10:38:38 localhost.localdomain kernel: scsi_remove_target+0x16d/0x1b0 >> Feb 16 10:38:38 localhost.localdomain kernel: >> __iscsi_unbind_session+0xad/0x150 [scsi_transport_iscsi] >> Feb 16 10:38:38 localhost.localdomain kernel: process_one_work+0x184/0x3a0 >> Feb 16 10:38:38 localhost.localdomain kernel: worker_thread+0x2e/0x380 >> Feb 16 10:38:38