Re: [REGRESSION] introduced in 5.10.140 causes drives to drop from LSI SAS controller (Bisected to 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269)

Re: [REGRESSION] introduced in 5.10.140 causes drives to drop from LSI SAS controller (Bisected to 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269)

[Bart Van Assche]

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.

Re: [REGRESSION] introduced in 5.10.140 causes drives to drop from LSI SAS controller (Bisected to 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269)

[Greg KH]

On Wed, Sep 14, 2022 at 10:21:04PM -0400, Jason Wittlin-Cohen wrote:
> #regzbot introduced 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269
> 
> Issue: When running a 5.10.140 kernel compiled from kernel.org source, or a
> bisected kernel with commit 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269, 6 of
> the 48 drives attached to my LSI 9207-8e SAS HBA (P20 firmware, IT mode)
> will drop from the controller shortly after the boot process completes.  At
> this point, the drives are not visible to the LSI controller, verified
> using LSI's lsiutil.x86_64 to list all attached devices, nor are the drives
> enumerated in /dev/disk/by-id. Attempts to access the drives result in I/O
> errors reported in syslog. At some point thereafter, the drives reappear
> and are accessible.
> 
> Running a vanilla 5.10.139 kernel or a bisected kernel with commit
> 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269 removed, all 48 drives appear
> correctly, are listed in LSI's lsiutil tool, and appear in /dev/disk/by-id.
> No I/O errors are reported from any drive and none of the drives drop off
> the controller as experienced in 5.10.140.  SMART testing shows normal
> results for all impacted drives.

Does this also have problems in the latest 5.15 and 5.19 release, or is
it somehow limited to 5.10.y?

Also, html emails are rejected by the mailing lists, so you might want
to resend it all in text-only mode so that everyone can see the full
details.

thanks,

greg k-h

Re: [REGRESSION] introduced in 5.10.140 causes drives to drop from LSI SAS controller (Bisected to 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269)

[Thorsten Leemhuis]

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

Re: [REGRESSION] introduced in 5.10.140 causes drives to drop from LSI SAS controller (Bisected to 6d17a112e9a63ff6a5edffd1676b99e0ffbcd269) #forregzbot

[Thorsten Leemhuis]

[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