>>>>> "Sreekanth" == Reddy, Sreekanth <sreekanth.re...@avagotech.com> writes:
Sreekanth> This is because, when driver receives DELAY_NOT_RESPONDING Sreekanth> for a disk when it is undergoing addition in the SCSI Mid Sreekanth> layer, the driver would block the I/O to that disk resulting Sreekanth> in a deadlock. i.e the disk addition work couldn't be Sreekanth> completed as it can't send any I/O to the disk as I/Os are Sreekanth> blocked. Any device removal (TARGET_NOT_RESPONDING) or link Sreekanth> update(RC_PHY_CHANGED) couldn't be processed as they are in Sreekanth> the queue to get processed after disk addition. Sreekanth> An module parameter 'unblock_io' is introduced which needs to Sreekanth> be set to have this functionality enabled. By default this Sreekanth> functionality is disabled. This really sounds like a scenario you should be able to handle in general (without special "don't-be-broken" module parameters). Also, shouldn't your internal task management be able to deal with this? Why does the sdev's state during probe affect your ability to make forward progress? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
