Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 6 Jul 2022 10:29:20 -0700
From:   Arun Easi <aeasi@marvell.com>
To:     Thorsten Leemhuis <regressions@leemhuis.info>
CC:     Tony Battersby <tonyb@cybernetics.com>,
        Saurav Kashyap <skashyap@marvell.com>,
        Nilesh Javali <njavali@marvell.com>,
        <GR-QLogic-Storage-Upstream@marvell.com>,
        <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <regressions@lists.linux.dev>
Subject: Re: [EXT] Re: [REGRESSION] qla2xxx: tape drive not removed after
 unplug FC cable
In-Reply-To: <30feb08e-83d0-34e2-06bb-40f4960c8be4@leemhuis.info>
Message-ID: <3b2c7bd3-06e9-a11e-a44c-905540a2fa69@marvell.com>
References: <baef87c3-5dad-3b47-44c1-6914bfc90108@cybernetics.com>
 <alpine.LRH.2.21.9999.2205271524460.4730@mvluser05.qlc.com>
 <5bcb5963-9da0-fd59-45c5-d27af02e7748@leemhuis.info>
 <178e4e7a-64fc-a442-cdda-45100eaebda0@cybernetics.com>
 <alpine.LRH.2.21.9999.2206211156470.4730@mvluser05.qlc.com>
 <d41671b4-8d29-b940-da37-b8dbe81f4d72@cybernetics.com>
 <alpine.LRH.2.21.9999.2206221557150.4730@mvluser05.qlc.com>
 <30feb08e-83d0-34e2-06bb-40f4960c8be4@leemhuis.info>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="1879738122-1102453863-1657064255=:3483"
Content-ID: <a5286f37-27ed-8a76-61ee-9530d32f91c0@marvell.com>
Precedence: bulk

--1879738122-1102453863-1657064255=:3483
Content-Type: text/plain; charset="ISO-8859-7"
Content-Transfer-Encoding: 8BIT
Content-ID: <11e5aaee-c6cc-5cba-d062-ddb3962c129e@marvell.com>

Hi Thorsten,

On Mon, 4 Jul 2022, 5:06am, Thorsten Leemhuis wrote:

> On 23.06.22 01:03, Arun Easi wrote:
> > On Wed, 22 Jun 2022, 7:56am, Tony Battersby wrote:
> > 
> >> On 6/21/22 18:05, Arun Easi wrote:
> >>> Thanks for the info. Just to reiterate, you've reported two issues (though 
> >>> this log was showing only 1 of them).
> >>>
> >>> Issue 1 - Tape device never disappears when removed
> >>> Issue 2 - When a direct connected tape 1 was replaced with tape 2, tape 2 
> >>>           was not discovered.
> >>>
> >>> For Issue-2, please try the attached patch. This may not be the final fix, 
> >>> but wanted to check if that would fix the issue for you.
> >>>
> >>> For Issue-1, the behavior was intentional, though that behavior needs 
> >>> refinement. These tape drives support something called FC sequence level 
> >>> error recovery (added in FCP-2), which can make tape I/Os survive even 
> >>> across a short cable pull. This is not a simple retry of the I/O, rather a 
> >>> retry done at the FC sequence level that gives the IO a better chance of
> >>> revival. In other words, the said patch that caused regression, while 
> >>> introduces an incorrect reporting of the state of the device, makes backup 
> >>> more resilient.
> >>>
> >>> Now, onto the behavior when device state is reported immediately. What we 
> >>> have observed, at least with one tape drive from a major vendor, is that, 
> >>> across a device loss and device back case with both the events reported to 
> >>> upper layers, the backup operation was getting failed. This is due to a 
> >>> REPORT LUNS command being issued during device reappearance reporting 
> >>> (fc_remote_port_add -> SCSI scan), which the tape drive was not expecting 
> >>> and caused the backup to fail.
> >>>
> >>> I know that some tape drives do not support multiple commands to it at the 
> >>> same time, but not sure if that is still the norm these days.
> >>>
> >>> So, perhaps one way to make the behavior better, is to either report the 
> >>> disappearing device a bit delayed or have intelligence added in SCSI scan 
> >>> to detect ongoing tape IO operations and delay/avoid the REPORT LUNs. 
> >>> Former is a more contained (in the LLD) fix.
> >>>
> >>> Regards,
> >>> -Arun
> >>
> >> Your patch does fix Issue-2 for me.? For Issue-1, it would be fine with
> >> me if qla2xxx reported device removal to the upper level a bit delayed,
> >> as you said.
> >>
> > 
> > Thanks for testing and verifying the patch.
> 
> BTW, that patch should have 'Link:' tags pointing to all reports about
> this issue, e.g. the start of this thread.

Thanks, will add, I was not aware of this.

> 
> These tags are important, as they allow others to look into the
> backstory now and years from now. That is why they should be placed in
> cases like this, as Documentation/process/submitting-patches.rst and
> Documentation/process/5.Posting.rst explain in more detail.
> Additionally, my regression tracking bot ?regzbot? relies on these tags
> to automatically connect reports with patches that are posted or
> committed to fix the reported issue. BTW, let me tell regzbot to monitor
> this thread:
> 
> > We will post the patch upstream after due testing.
> That was more than two weeks ago now and I didn't see any progress. Or
> did I miss it?

No, the fix is being prepared to be posted.

Regards,
-Arun
--1879738122-1102453863-1657064255=:3483--