On 9/14/22 19:21, Jason Wittlin-Cohen wrote:
8d5c106fe216bf16080d7070c37adf56a9227e60 is the first bad commit commit 8d5c106fe216bf16080d7070c37adf56a9227e60 Author: Kiwoong Kim <kwmad.kim@samsung.com mailto:kwmad.kim@samsung.com> Date: Tue Aug 2 10:42:31 2022 +0900
scsi: ufs: core: Enable link lost interrupt
commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 upstream.
Link lost is treated as fatal error with commit c99b9b230149 ("scsi: ufs: Treat link loss as fatal error"), but the event isn't registered as interrupt source. Enable it.
Hi Jason,
Something must have gone wrong during the bisection process. Commit 8d5c106fe216 ("scsi: ufs: core: Enable link lost interrupt") only affects the UFS driver and hence cannot change the behavior of a SAS controller. How about repeating the bisection process?
Thanks,
Bart.
Hi, this is your Linux kernel regression tracker.
On 15.09.22 04:48, Bart Van Assche wrote:
On 9/14/22 19:21, Jason Wittlin-Cohen wrote:
8d5c106fe216bf16080d7070c37adf56a9227e60 is the first bad commit commit 8d5c106fe216bf16080d7070c37adf56a9227e60 Author: Kiwoong Kim <kwmad.kim@samsung.com mailto:kwmad.kim@samsung.com> Date: Tue Aug 2 10:42:31 2022 +0900
scsi: ufs: core: Enable link lost interrupt
commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 upstream.
Link lost is treated as fatal error with commit c99b9b230149 ("scsi: ufs: Treat link loss as fatal error"), but the event isn't registered as interrupt source. Enable it.
Something must have gone wrong during the bisection process. Commit 8d5c106fe216 ("scsi: ufs: core: Enable link lost interrupt") only affects the UFS driver and hence cannot change the behavior of a SAS controller. How about repeating the bisection process?
Hmm, nothing happened here for a week. :-/ That's not how this should be when it comes to regressions...
Jason, any news on this? A answer to Greg's question ("Does this also have problems in the latest 5.15 and 5.19 release)") would be helpful. Also: when your wrote "Running [...] a bisected kernel with commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 removed, [...]" I assume you tested this with 5.10.y?
Side note: Sure, a bisection can easily got wrong, as Bart outlined. But you also wrote "Running [...] a bisected kernel with commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 removed, [...]" sounds a lot like the bisection didn't go sideways. Are you sure you nothing went wrong when you tested this revert?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
#regzbot introduced 8d5c106fe216bf1608 #regzbot poke
[Note: this mail is primarily send for documentation purposes and/or for regzbot, my Linux kernel regression tracking bot. That's why I removed most or all folks from the list of recipients, but left any that looked like a mailing lists. These mails usually contain '#forregzbot' in the subject, to make them easy to spot and filter out.]
On 22.09.22 13:38, Thorsten Leemhuis wrote:
Hmm, nothing happened here for a week. :-/ That's not how this should be when it comes to regressions...
Jason, any news on this?
#regzbot invalid: reporter MIA
linux-stable-mirror@lists.linaro.org