Issues with LSI-3008 adapters, mpt3sas driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I am seeing an issue while using an LSI-3008-based adapter (mpt3sas driver) on a PowerPC system (although I am not yet convinced it is architecture dependent). When I create a RAID1 volume, the physical disk devices get "hidden" as expected however the various kernel objects are out of sync. The corresponding bits in the "sd_index_ida" bitmap gets cleared, and the symlink in /sys/dev/block for this major:minor pair gets removed, but none of the other major:minor entries in sysfs get removed. The next time a new device is added (for example, during another RAID volume create or delete), the recently-freed major:minor number is picked up from the "sd_index_ida" bitmap but the attempt to create sysfs entries fails EEXIST due to an entry by the same name already (still) existing. This failure goes unhandled and later the kernel panics in sd_probe_async while dereferencing an (apparently) invalid backing_dev_info structure (presumably left invalid due to the EEXIST error).

A reboot clears this (bitmaps and sysfs) up and the second RAID volume (if a create was done) shows up normally. However, even if the panic were avoided by better error handling in sd_probe_async there would still be the problem of being able to create more than one RAID volume without rebooting.

I am wondering if this issue has been seen elsewhere, and also just what might be going wrong. For mpt3sas, it appears that the firmware largely drives the hiding/exposing of devices but I don't see an issue with the ordering of those events. I am wondering if the driver is failing to setup the device attributes correctly in order to get the proper sysfs handling.

I am seeing this on Ubuntu 16.04, but also see it on the upstream kernel. Oddly, it does not happen on RHEL 7.2 (an older kernel).

A possibly-related issue we see is that when a RAID volume is deleted, none of the RAID device nodes (/dev as well as /sys/) get removed - although they are unusable. Deleting before creating does not produce the panic, so I believe the "sd_index_ida" bitmap is not getting updated by the delete.


Any help would be appreciated.

Thanks,

Doug

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux