View Issue Details

IDProjectCategoryView StatusLast Update
0010516CentOS-7kernelpublic2016-11-21 18:04
Reporternov1ce 
PrioritynormalSeverityblockReproducibilityalways
Status resolvedResolutionfixed 
PlatformLenovo System x3650 M5OSCentOS 7OS Version7.2.1511
Product Version7.2.1511 
Target VersionFixed in Version 
Summary0010516: mpt3sas driver
DescriptionHello,

We seem to have an issue with mpt3sas driver included in CentOS 7 (7.2.1511) running on Lenovo System x3650 M5.

# uname -a
Linux bigddn01 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[ 3.608523] mpt3sas version 04.100.00.00 loaded
[ 3.608840] mpt3sas0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (131640904 kB)
[ 3.664247] mpt3sas0: MSI-X vectors supported: 8, no of cores: 32, max_msix_vectors: 8
[ 3.855056] mpt3sas0: LSISAS3008: FWVersion(03.00.07.00), ChipRevision(0x02), BiosVersion(06.00.01.00)

The installation of CentOS works fine. Here is a snippet from dmesg:

[ 3.608523] mpt3sas version 04.100.00.00 loaded
[ 3.608746] mpt3sas 0000:15:00.0: enabling device (0140 -> 0142)
[ 3.608840] mpt3sas0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (131640904 kB)
[ 3.664247] mpt3sas0: MSI-X vectors supported: 8, no of cores: 32, max_msix_vectors: 8
[ 3.664362] mpt3sas 0000:15:00.0: irq 46 for MSI/MSI-X
[ 3.664403] mpt3sas 0000:15:00.0: irq 47 for MSI/MSI-X
[ 3.664416] mpt3sas 0000:15:00.0: irq 48 for MSI/MSI-X
[ 3.664450] mpt3sas 0000:15:00.0: irq 49 for MSI/MSI-X
[ 3.664483] mpt3sas 0000:15:00.0: irq 50 for MSI/MSI-X
[ 3.664522] mpt3sas 0000:15:00.0: irq 51 for MSI/MSI-X
[ 3.664564] mpt3sas 0000:15:00.0: irq 52 for MSI/MSI-X
[ 3.664597] mpt3sas 0000:15:00.0: irq 53 for MSI/MSI-X
[ 3.664893] mpt3sas0-msix0: PCI-MSI-X enabled: IRQ 46
[ 3.664894] mpt3sas0-msix1: PCI-MSI-X enabled: IRQ 47
[ 3.664894] mpt3sas0-msix2: PCI-MSI-X enabled: IRQ 48
[ 3.664895] mpt3sas0-msix3: PCI-MSI-X enabled: IRQ 49
[ 3.664895] mpt3sas0-msix4: PCI-MSI-X enabled: IRQ 50
[ 3.664896] mpt3sas0-msix5: PCI-MSI-X enabled: IRQ 51
[ 3.664896] mpt3sas0-msix6: PCI-MSI-X enabled: IRQ 52
[ 3.664897] mpt3sas0-msix7: PCI-MSI-X enabled: IRQ 53
[ 3.664898] mpt3sas0: iomem(0x0000000090cf0000), mapped(0xffffc9001c320000), size(65536)
[ 3.664899] mpt3sas0: ioport(0x0000000000002e00), size(256)
[ 3.809272] mpt3sas0: Allocated physical memory: size(17342 kB)
[ 3.809275] mpt3sas0: Current Controller Queue Depth(10123),Max Controller Queue Depth(10240)
[ 3.809277] mpt3sas0: Scatter Gather Elements per IO(128)
[ 3.855056] mpt3sas0: LSISAS3008: FWVersion(03.00.07.00), ChipRevision(0x02), BiosVersion(06.00.01.00)
[ 3.855059] mpt3sas0: Protocol=(
[ 3.855646] mpt3sas0: sending port enable !!
[ 5.649806] mpt3sas0: host_add: handle(0x0001), sas_addr(0x500605b00ab56830), phys(8)
[ 5.651910] mpt3sas0: expander_add: handle(0x0009), parent(0x0001), sas_addr(0x500507606345287f), phys(25)
[ 12.420259] mpt3sas0: port enable: SUCCESS

If I reboot the server, scsi 0:0:0:0 gets blocked, all remaining scsi IDs get reshuffled and I see "device is not present handle" errors:

[ 6.107015] scsi 0:0:0:0: device_blocked, handle(0x000a)

[ 3.591144] mpt3sas version 04.100.00.00 loaded
[ 3.591350] mpt3sas 0000:15:00.0: enabling device (0140 -> 0142)
[ 3.591440] mpt3sas0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (131640904 kB)
[ 3.646675] mpt3sas0: MSI-X vectors supported: 8, no of cores: 32, max_msix_vectors: 8
[ 3.646721] mpt3sas 0000:15:00.0: irq 46 for MSI/MSI-X
[ 3.646729] mpt3sas 0000:15:00.0: irq 47 for MSI/MSI-X
[ 3.646737] mpt3sas 0000:15:00.0: irq 48 for MSI/MSI-X
[ 3.646745] mpt3sas 0000:15:00.0: irq 49 for MSI/MSI-X
[ 3.646753] mpt3sas 0000:15:00.0: irq 50 for MSI/MSI-X
[ 3.646769] mpt3sas 0000:15:00.0: irq 51 for MSI/MSI-X
[ 3.646776] mpt3sas 0000:15:00.0: irq 52 for MSI/MSI-X
[ 3.646784] mpt3sas 0000:15:00.0: irq 53 for MSI/MSI-X
[ 3.646903] mpt3sas0-msix0: PCI-MSI-X enabled: IRQ 46
[ 3.646905] mpt3sas0-msix1: PCI-MSI-X enabled: IRQ 47
[ 3.646906] mpt3sas0-msix2: PCI-MSI-X enabled: IRQ 48
[ 3.646907] mpt3sas0-msix3: PCI-MSI-X enabled: IRQ 49
[ 3.646910] mpt3sas0-msix4: PCI-MSI-X enabled: IRQ 50
[ 3.646911] mpt3sas0-msix5: PCI-MSI-X enabled: IRQ 51
[ 3.646913] mpt3sas0-msix6: PCI-MSI-X enabled: IRQ 52
[ 3.646914] mpt3sas0-msix7: PCI-MSI-X enabled: IRQ 53
[ 3.646916] mpt3sas0: iomem(0x0000000090cf0000), mapped(0xffffc9001c8c0000), size(65536)
[ 3.646917] mpt3sas0: ioport(0x0000000000002e00), size(256)
[ 3.774651] mpt3sas0: Allocated physical memory: size(17342 kB)
[ 3.774654] mpt3sas0: Current Controller Queue Depth(10123),Max Controller Queue Depth(10240)
[ 3.774655] mpt3sas0: Scatter Gather Elements per IO(128)
[ 3.820429] mpt3sas0: LSISAS3008: FWVersion(03.00.07.00), ChipRevision(0x02), BiosVersion(06.00.01.00)
[ 3.820431] mpt3sas0: Protocol=(
[ 3.821017] mpt3sas0: sending port enable !!
[ 5.590029] mpt3sas0: host_add: handle(0x0001), sas_addr(0x500605b00ab56830), phys(8)
[ 5.592233] mpt3sas0: expander_add: handle(0x0009), parent(0x0001), sas_addr(0x500507606345287f), phys(25)
[ 5.906518] mpt3sas0: device is not present handle(0x04b)!!!
[ 5.910632] mpt3sas0: device is not present handle(0x04c)!!!
[ 5.913716] mpt3sas0: device is not present handle(0x04d)!!!
[ 5.913836] mpt3sas0: device is not present handle(0x04e)!!!
[ 5.913948] mpt3sas0: device is not present handle(0x04f)!!!
[ 5.914059] mpt3sas0: device is not present handle(0x0410)!!!
[ 5.914170] mpt3sas0: device is not present handle(0x0411)!!!
[ 5.914281] mpt3sas0: device is not present handle(0x0412)!!!
[ 5.914392] mpt3sas0: device is not present handle(0x0413)!!!
[ 5.914504] mpt3sas0: device is not present handle(0x0414)!!!
[ 5.914631] mpt3sas0: device is not present handle(0x0415)!!!
[ 11.846267] mpt3sas0: port enable: SUCCESS

If I reboot the server one more time everything is back to normal until the next reboot.

I've just tried the latest kernel from ELRepo (4.4.4-1) which includes version 09.102.00.00 of mpt3sas driver and it works without any issues and reboot of the server doesn't change scsi IDs.

Is there any chance that the version of mpt3sas driver could be updated in 3.10.0 kernel?

I'd happy to provide with any additional information needed.

Thank you.
TagsNo tags attached.
abrt_hash
URL

Activities

toracat

toracat

2016-03-07 15:56

manager   ~0025942

You might want to try asking ELRepo to build a kmod package.
nov1ce

nov1ce

2016-03-09 19:15

reporter   ~0025968

Update:

Phil Perry from ELRepo was kind enough to build a kmod package for me which includes two patches below applied to the latest RHEL 7.2 mpt3sas driver from kernel-3.10.0-327.10.1.el7.

1. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/scsi/mpt3sas?h=v4.4.4&id=e4bc7f5c21a18cab9acd30940df0ee791fcd7b9e

2. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/scsi/mpt3sas?h=v4.4.4&id=df838f92f3f5240dca54e1629e8547818e8ea646

This seemed to fix my issue. After several reboots scsi labeling is still consistent, I don't see "device is not present" errors anymore and all SATA drives are present.

I have a bug filed with Red Hat although I'm not sure if/when it will be fixed (there is no activity on the submitted bug).

Perhaps you might be interested to verify and apply both patches in CentOSPlus kernel.

Thanks.
toracat

toracat

2016-03-09 19:48

manager   ~0025969

I am planning to add the referenced patches in the next kernel-plus update.
toracat

toracat

2016-03-10 01:36

manager  

centos-linux-3.10-mpt3sas-SML-bug10516.patch (4,505 bytes)
centosplus kernel patch (bug #10516)

commit e4bc7f5c21a18cab9acd30940df0ee791fcd7b9e
Author: Sreekanth Reddy <sreekanth.reddy@avagotech.com>
Date:   Tue Jun 30 12:24:49 2015 +0530

    mpt3sas: Don't block the drive when drive addition under the control of SML
    
    During hot-plugging of a disk(having a flaky link), the disk addition
    stops and any further disk addition or removal doesn't happen on that
    controller.
    
    This is because, when driver receives DELAY_NOT_RESPONDING event for a disk
    while it is undergoing addition at the SCSI Transport layer, the driver
    would block the I/O to that disk resulting in a deadlock. i.e the disk
    addition work couldn't be completed at the SCSI Transport Layer as it
    can't send any I/Os (such as Inquiry, Report LUNs etc) to the disk as
    I/Os are blocked to this drive. Also any subsequent device removal
    (TARGET_NOT_RESPONDING) or link update(RC_PHY_CHANGED) event couldn't be
    processed as they are in the queue to get processed after disk addition
    event.
    
    Description of Change:
    Don't block the drive when drive addition is under the control of SML.
    So that SML won't be blocked of issuing the device dicovery commands
    (such as Inquiry, Report LUNs etc).
    
    Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Applied-by: Akemi Yagi <toracat@centos.org>

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h
index a7386ee..01d92db 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -294,7 +294,8 @@ struct _internal_cmd {
  * @responding: used in _scsih_sas_device_mark_responding
  * @fast_path: fast path feature enable bit
  * @pfa_led_on: flag for PFA LED status
- *
+ * @pend_sas_rphy_add: flag to check if device is in sas_rphy_add()
+ *	addition routine.
  */
 struct _sas_device {
 	struct list_head list;
@@ -315,6 +315,7 @@ struct _sas_device {
 	u8	responding;
 	u8	fast_path;
 	u8	pfa_led_on;
+	u8	pend_sas_rphy_add;
 };
 
 /**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 5a97e32..d457dba 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2690,6 +2690,11 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16 handle)
 {
 	struct MPT3SAS_DEVICE *sas_device_priv_data;
 	struct scsi_device *sdev;
+	struct _sas_device *sas_device;
+
+	sas_device = _scsih_sas_device_find_by_handle(ioc, handle);
+	if (!sas_device)
+		return;
 
 	shost_for_each_device(sdev, ioc->shost) {
 		sas_device_priv_data = sdev->hostdata;
@@ -2699,6 +2704,8 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16 handle)
 			continue;
 		if (sas_device_priv_data->block)
 			continue;
+		if (sas_device->pend_sas_rphy_add)
+			continue;
 		sas_device_priv_data->block = 1;
 		scsi_internal_device_block(sdev);
 		sdev_printk(KERN_INFO, sdev,
diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c
index efb98af..7a7aa68 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_transport.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c
@@ -649,6 +649,7 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc, u16 handle,
 	unsigned long flags;
 	struct _sas_node *sas_node;
 	struct sas_rphy *rphy;
+	struct _sas_device *sas_device = NULL;
 	int i;
 	struct sas_port *port;
 
@@ -731,10 +732,27 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc, u16 handle,
 		    mpt3sas_port->remote_identify.device_type);
 
 	rphy->identify = mpt3sas_port->remote_identify;
+
+	if (mpt3sas_port->remote_identify.device_type == SAS_END_DEVICE) {
+		sas_device = mpt3sas_scsih_sas_device_find_by_sas_address(ioc,
+				    mpt3sas_port->remote_identify.sas_address);
+		if (!sas_device) {
+			dfailprintk(ioc, printk(MPT3SAS_FMT
+				"failure at %s:%d/%s()!\n",
+				ioc->name, __FILE__, __LINE__, __func__));
+			goto out_fail;
+		}
+		sas_device->pend_sas_rphy_add = 1;
+	}
+
 	if ((sas_rphy_add(rphy))) {
 		pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
 		    ioc->name, __FILE__, __LINE__, __func__);
 	}
+
+	if (mpt3sas_port->remote_identify.device_type == SAS_END_DEVICE)
+		sas_device->pend_sas_rphy_add = 0;
+
 	if ((ioc->logging_level & MPT_DEBUG_TRANSPORT))
 		dev_printk(KERN_INFO, &rphy->dev,
 			"add: handle(0x%04x), sas_addr(0x%016llx)\n",
toracat

toracat

2016-03-10 01:37

manager  

centos-linux-3.10-mpt3sas-fix-block-bug10516.patch (5,785 bytes)
centosplus kernel patch (bug #10516)

commit e4bc7f5c21a18cab9acd30940df0ee791fcd7b9e
Author: Sreekanth Reddy <sreekanth.reddy@avagotech.com>
Date:   Tue Jun 30 12:24:49 2015 +0530

    mpt3sas: Don't block the drive when drive addition under the control of SML

    During hot-plugging of a disk(having a flaky link), the disk addition
    stops and any further disk addition or removal doesn't happen on that
    controller.

    This is because, when driver receives DELAY_NOT_RESPONDING event for a disk
    while it is undergoing addition at the SCSI Transport layer, the driver
    would block the I/O to that disk resulting in a deadlock. i.e the disk
    addition work couldn't be completed at the SCSI Transport Layer as it
    can't send any I/Os (such as Inquiry, Report LUNs etc) to the disk as
    I/Os are blocked to this drive. Also any subsequent device removal
    (TARGET_NOT_RESPONDING) or link update(RC_PHY_CHANGED) event couldn't be
    processed as they are in the queue to get processed after disk addition
    event.

    Description of Change:
    Don't block the drive when drive addition is under the control of SML.
    So that SML won't be blocked of issuing the device dicovery commands
    (such as Inquiry, Report LUNs etc).

    Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Applied-by: Akemi Yagi <toracat@centos.org>

--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c	2016-03-09 10:27:25.339763252 -0800
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c	2016-03-09 12:53:27.780776328 -0800
@@ -2598,6 +2598,75 @@ _scsih_fw_event_cleanup_queue(struct MPT
 }
 
 /**
+ * _scsih_internal_device_block - block the sdev device
+ * @sdev: per device object
+ * @sas_device_priv_data : per device driver private data
+ *
+ * make sure device is blocked without error, if not
+ * print an error
+ */
+static void
+_scsih_internal_device_block(struct scsi_device *sdev,
+			struct MPT3SAS_DEVICE *sas_device_priv_data)
+{
+	int r = 0;
+
+	sdev_printk(KERN_INFO, sdev, "device_block, handle(0x%04x)\n",
+	    sas_device_priv_data->sas_target->handle);
+	sas_device_priv_data->block = 1;
+
+	r = scsi_internal_device_block(sdev);
+	if (r == -EINVAL)
+		sdev_printk(KERN_WARNING, sdev,
+		    "device_block failed with return(%d) for handle(0x%04x)\n",
+		    sas_device_priv_data->sas_target->handle, r);
+}
+
+/**
+ * _scsih_internal_device_unblock - unblock the sdev device
+ * @sdev: per device object
+ * @sas_device_priv_data : per device driver private data
+ * make sure device is unblocked without error, if not retry
+ * by blocking and then unblocking
+ */
+
+static void
+_scsih_internal_device_unblock(struct scsi_device *sdev,
+			struct MPT3SAS_DEVICE *sas_device_priv_data)
+{
+	int r = 0;
+
+	sdev_printk(KERN_WARNING, sdev, "device_unblock and setting to running, "
+	    "handle(0x%04x)\n", sas_device_priv_data->sas_target->handle);
+	sas_device_priv_data->block = 0;
+	r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+	if (r == -EINVAL) {
+		/* The device has been set to SDEV_RUNNING by SD layer during
+		 * device addition but the request queue is still stopped by
+		 * our earlier block call. We need to perform a block again
+		 * to get the device to SDEV_BLOCK and then to SDEV_RUNNING */
+
+		sdev_printk(KERN_WARNING, sdev,
+		    "device_unblock failed with return(%d) for handle(0x%04x) "
+		    "performing a block followed by an unblock\n",
+		    sas_device_priv_data->sas_target->handle, r);
+		sas_device_priv_data->block = 1;
+		r = scsi_internal_device_block(sdev);
+		if (r)
+			sdev_printk(KERN_WARNING, sdev, "retried device_block "
+			    "failed with return(%d) for handle(0x%04x)\n",
+			    sas_device_priv_data->sas_target->handle, r);
+
+		sas_device_priv_data->block = 0;
+		r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+		if (r)
+			sdev_printk(KERN_WARNING, sdev, "retried device_unblock"
+			    " failed with return(%d) for handle(0x%04x)\n",
+			    sas_device_priv_data->sas_target->handle, r);
+	}
+}
+
+/** 
  * _scsih_ublock_io_all_device - unblock every device
  * @ioc: per adapter object
  *
@@ -2616,11 +2685,10 @@ _scsih_ublock_io_all_device(struct MPT3S
 		if (!sas_device_priv_data->block)
 			continue;
 
-		sas_device_priv_data->block = 0;
 		dewtprintk(ioc, sdev_printk(KERN_INFO, sdev,
 			"device_running, handle(0x%04x)\n",
 		    sas_device_priv_data->sas_target->handle));
-		scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+		_scsih_internal_device_unblock(sdev, sas_device_priv_data);
 	}
 }
 
@@ -2645,10 +2713,9 @@ _scsih_ublock_io_device(struct MPT3SAS_A
 		if (sas_device_priv_data->sas_target->sas_address
 		    != sas_address)
 			continue;
-		if (sas_device_priv_data->block) {
-			sas_device_priv_data->block = 0;
-			scsi_internal_device_unblock(sdev, SDEV_RUNNING);
-		}
+		if (sas_device_priv_data->block)
+			_scsih_internal_device_unblock(sdev,
+				sas_device_priv_data);
 	}
 }
 
@@ -2671,10 +2738,7 @@ _scsih_block_io_all_device(struct MPT3SA
 			continue;
 		if (sas_device_priv_data->block)
 			continue;
-		sas_device_priv_data->block = 1;
-		scsi_internal_device_block(sdev);
-		sdev_printk(KERN_INFO, sdev, "device_blocked, handle(0x%04x)\n",
-		    sas_device_priv_data->sas_target->handle);
+		_scsih_internal_device_block(sdev, sas_device_priv_data);
 	}
 }
 
@@ -2706,10 +2770,7 @@ _scsih_block_io_device(struct MPT3SAS_AD
 			continue;
 		if (sas_device->pend_sas_rphy_add)
 			continue;
-		sas_device_priv_data->block = 1;
-		scsi_internal_device_block(sdev);
-		sdev_printk(KERN_INFO, sdev,
-			"device_blocked, handle(0x%04x)\n", handle);
+		_scsih_internal_device_block(sdev, sas_device_priv_data);
 	}
 }
 
toracat

toracat

2016-03-10 01:38

manager   ~0025973

Centosplus patches uploaded.
toracat

toracat

2016-03-10 03:09

manager   ~0025974

I have uploaded a centosplus kernel set that has the patches applied (kernel-plus-3.10.0-327.10.1.el7.ay.centos.plus) for you to test:

http://people.centos.org/toracat/kernel/7/plus/bugs10447_10516/

Please note that the packages are not signed and are provided for testing purposes only.
nov1ce

nov1ce

2016-03-10 15:36

reporter   ~0025988

Thank you. Tested and it works like a charm.
toracat

toracat

2016-03-10 16:13

manager   ~0025989

Thanks for the success report. :) The patches will be in the next update of the official kernel-plus package.
toracat

toracat

2016-03-10 17:51

manager   ~0025998

Could you add me (toracat@elrepo.org) to the CC list of the RH bugzilla report you filed? Also please add this CentOS bug number to the external bug link.
nov1ce

nov1ce

2016-03-10 18:14

reporter   ~0025999

Done. :)
toracat

toracat

2016-03-10 18:28

manager   ~0026000

Thanks!
toracat

toracat

2016-04-12 15:56

manager   ~0026267

kernel-plus-3.10.0-327.13.1 is out. The patches are now in this kernel.
nov1ce

nov1ce

2016-06-02 14:04

reporter   ~0026754

Hello toracat,

Me again. :) Just wondering, the patches that you applied to kernel-plus-3.10.0-327.13.1, are they automatically being transferred to newer versions of kernel-plus?

I've just updated to the latest 3.10.0-327.18.2.el7.centos.plus and it seems that SCSI IDs (this time I guess it's a bus ID actually) change after each reboot:

[ 11.856389] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.856515] sd 0:0:1:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.857041] sd 0:0:2:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.857199] sd 0:0:3:0: [sdd] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.857299] sd 0:0:4:0: [sde] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.857498] sd 0:0:5:0: [sdf] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.858064] sd 0:0:6:0: [sdg] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.859275] sd 0:0:11:0: [sdl] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.859483] sd 0:0:7:0: [sdh] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.859638] sd 0:0:8:0: [sdi] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.859804] sd 0:0:9:0: [sdj] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.859963] sd 0:0:10:0: [sdk] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)

After reboot:

[ 11.975850] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.975997] sd 1:0:3:0: [sdd] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976139] sd 1:0:2:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976279] sd 1:0:1:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976459] sd 1:0:5:0: [sdf] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976490] sd 1:0:11:0: [sdl] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976505] sd 1:0:4:0: [sde] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976632] sd 1:0:7:0: [sdh] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976764] sd 1:0:8:0: [sdi] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.976920] sd 1:0:9:0: [sdj] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.977232] sd 1:0:10:0: [sdk] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 11.977389] sd 1:0:6:0: [sdg] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)

Another reboot, and it's back to 0:0:X:0.

It doesn't have any impact on my servers though, since SCSI IDs are still consistent and I don't lose any drives, but this is similar to what I've seen in 4.4.X kernel (although my RH bug hasn't been updated).

Thanks.
toracat

toracat

2016-06-02 16:31

manager   ~0026757

Yes, the patches are passed on to newer plus kernels upon every update until the distro kernel gets the fix.
toracat

toracat

2016-11-21 18:03

manager   ~0027954

The patches are now in the 7.3 distro kernel. Therefore they have been removed from the plus kernel.
toracat

toracat

2016-11-21 18:04

manager   ~0027955

Closing as 'resolved'. If you find any issue, please submit a new ticket.

Issue History

Date Modified Username Field Change
2016-03-07 15:00 nov1ce New Issue
2016-03-07 15:56 toracat Note Added: 0025942
2016-03-09 17:55 toracat Status new => assigned
2016-03-09 19:15 nov1ce Note Added: 0025968
2016-03-09 19:48 toracat Note Added: 0025969
2016-03-10 01:36 toracat File Added: centos-linux-3.10-mpt3sas-SML-bug10516.patch
2016-03-10 01:37 toracat File Added: centos-linux-3.10-mpt3sas-fix-block-bug10516.patch
2016-03-10 01:38 toracat Note Added: 0025973
2016-03-10 03:09 toracat Note Added: 0025974
2016-03-10 15:36 nov1ce Note Added: 0025988
2016-03-10 16:13 toracat Note Added: 0025989
2016-03-10 17:51 toracat Note Added: 0025998
2016-03-10 18:14 nov1ce Note Added: 0025999
2016-03-10 18:28 toracat Note Added: 0026000
2016-04-12 15:56 toracat Note Added: 0026267
2016-06-02 14:04 nov1ce Note Added: 0026754
2016-06-02 16:31 toracat Note Added: 0026757
2016-11-21 18:03 toracat Note Added: 0027954
2016-11-21 18:04 toracat Status assigned => resolved
2016-11-21 18:04 toracat Resolution open => fixed
2016-11-21 18:04 toracat Note Added: 0027955