From: Greg KH <gregkh@linuxfoundation.org>
To: Salvatore Bonaccorso <carnil@debian.org>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>,
Sagar Biradar <sagar.biradar@microchip.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Adaptec OEM Raid Solutions <aacraid@microsemi.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Sasha Levin <sashal@kernel.org>,
Linux kernel regressions list <regressions@lists.linux.dev>,
Hannes Reinecke <hare@suse.de>, scsi <linux-scsi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Gilbert Wu <gilbert.wu@microchip.com>,
John Garry <john.g.garry@oracle.com>
Subject: Re: scsi regression that after months is still not addressed and now bothering 6.1.y users, too
Date: Sat, 30 Dec 2023 10:58:23 +0000 [thread overview]
Message-ID: <2023123013-dose-skirmish-27c2@gregkh> (raw)
In-Reply-To: <ZY8oXge0QKYUkO1b@eldamar.lan>
On Fri, Dec 29, 2023 at 09:13:18PM +0100, Salvatore Bonaccorso wrote:
> Hi all,
>
> On Sat, Nov 25, 2023 at 08:10:35AM +0100, Thorsten Leemhuis wrote:
> > On 24.11.23 17:25, Greg KH wrote:
> > > On Tue, Nov 21, 2023 at 10:50:57AM +0100, Thorsten Leemhuis wrote:
> > >> * @SCSI maintainers: could you please look into below please?
> > >>
> > >> * @Stable team: you might want to take a look as well and consider a
> > >> revert in 6.1.y (yes, I know, those are normally avoided, but here it
> > >> might make sense).
> > >>
> > >> Hi everyone!
> > >>
> > >> TLDR: I noticed a regression (Adaptec 71605z with aacraid sometimes
> > >> hangs for a while) that was reported months ago already but is still not
> > >> fixed. Not only that, it apparently more and more users run into this
> > >> recently, as the culprit was recently integrated into 6.1.y; I wonder if
> > >> it would be best to revert it there, unless a fix for mainline comes
> > >> into reach soon.
> > >>
> > >> Details:
> > >>
> > >> Quite a few machines with Adaptec controllers seems to hang for a few
> > >> tens of seconds to a few minutes before things start to work normally
> > >> again for a while:
> > >> https://bugzilla.kernel.org/show_bug.cgi?id=217599
> > >>
> > >> That problem is apparently caused by 9dc704dcc09eae ("scsi: aacraid:
> > >> Reply queue mapping to CPUs based on IRQ affinity") [v6.4-rc7]. That
> > >> commit despite a warning of mine to Sasha recently made it into 6.1.53
> > >> -- and that way apparently recently reached more users recently, as
> > >> quite a few joined that ticket.
> > >[...]
> > > I am loath to revert a stable patch that has been there for so long as
> > > any upgrade will just cause the same bug to show back up. Why can't we
> > > just revert it in Linus's tree now and I'll take that revert in the
> > > stable trees as well?
> >
> > FWIW, I know and in general agree with that strategy, that's why I
> > normally wouldn't have brought a stable-only revert up for
> > consideration. But this issue to me looked somewhat special and urgent
> > for two and a half reasons: (1) that backport apparently made a lot more
> > people suddenly hit the issue (2) there was also this data corruption
> > aspect one of the reporters mentioned (not sure if that is real and/or
> > if this might be just a 6.1.y thing). Furthermore for 6.1.y it was
> > recently confirmed that reverting the change fixes things, while we iirc
> > had no such confirmation for recent mainline kernels at that point. So
> > it looked like it would take a while to get this sorted out in mainline.
> > But it seems we finally might get closer to that now, so yeah, maybe
> > it's not worth a stable revert.
>
> If I'm not completely wrong, finally indeed the commit has been
> reverted in mainline, with c5becf57dd56 ("Revert "scsi: aacraid: Reply
> queue mapping to CPUs based on IRQ affinity"") .
>
> This is what was mentioned here:
> https://bugzilla.kernel.org/show_bug.cgi?id=217599#c52
>
> So should/can it be reverted it now as well on the 6.1.y stable series
> (and the others up as needed?)
Now queued up, thanks.
greg k-h
prev parent reply other threads:[~2023-12-30 10:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 9:50 scsi regression that after months is still not addressed and now bothering 6.1.y users, too Thorsten Leemhuis
2023-11-21 9:57 ` Thorsten Leemhuis
2023-11-21 11:30 ` John Garry
2023-11-21 12:24 ` Linux regression tracking (Thorsten Leemhuis)
2023-11-21 13:05 ` James Bottomley
2023-11-21 13:24 ` Linux regression tracking (Thorsten Leemhuis)
2023-11-21 13:31 ` James Bottomley
2023-11-24 16:25 ` Greg KH
2023-11-24 22:44 ` Martin K. Petersen
2023-11-25 7:10 ` Thorsten Leemhuis
2023-12-29 20:13 ` Salvatore Bonaccorso
2023-12-30 10:58 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023123013-dose-skirmish-27c2@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=aacraid@microsemi.com \
--cc=carnil@debian.org \
--cc=gilbert.wu@microchip.com \
--cc=hare@suse.de \
--cc=john.g.garry@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=sagar.biradar@microchip.com \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.