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