[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <yq1oavdr1rs.fsf@sermon.lab.mkp.net>
Date: Thu, 21 Aug 2014 17:06:15 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: "Reddy\, Sreekanth" <Sreekanth.Reddy@...gotech.com>
Cc: <jejb@...nel.org>, <JBottomley@...allels.com>,
<linux-scsi@...r.kernel.org>, <Sathya.Prakash@...gotech.com>,
<Nagalakshmi.Nandigama@...gotech.com>,
<linux-kernel@...r.kernel.org>, <hch@...radead.org>,
<martin.petersen@...cle.com>
Subject: Re: [RESEND][PATCH 09/10][SCSI]mpt2sas: Added module parameter 'unblock_io' to unblock IO's during disk addition
>>>>> "Sreekanth" == Reddy, Sreekanth <Sreekanth.Reddy@...gotech.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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists