Fwd: bbbf096ea227607cbb348155eeda7af71af1a35b results in "dirty" shutdown

Fwd: bbbf096ea227607cbb348155eeda7af71af1a35b results in "dirty" shutdown

[Bagas Sanjaya]

Hi,

I notice a regression report on Bugzilla that seems to have been
handled already there [1]. Quoting from it:

> I have noticed that after each shutdown SMART would log +1 on each raw_value of drives that count power related issues.
> 
> Here are some of the smart values where i noticed increase among different drives
> 
> POR_Recovery_Count 
> Unexpect_Power_Loss_Ct  
> Power-Off_Retract_Count 
> 
> That doesn't happen on previous Kernels.. and it stops as soon as i switch back to LTS.
> I seeked through the Bug Reports but couldn't really find the issue. So i don't know if this has been reported or patched already.

Another reporter had found the culprit:

> 
> 
> This has been reported as being introduced in stable 6.5.8 [1].  Reverting commit 	bbbf096ea227607cbb348155eeda7af71af1a35b is reported to solve the issue [2]. bbbf096ea227607cbb348155eeda7af71af1a35b [3] is mainline commit aa3998dbeb3abce63653b7f6d4542e7dcd022590 [4] which was introduced in 6.6-rc4 which matches the original report.
> 
> [1]: https://bugs.archlinux.org/task/80064
> [2]: https://bugs.archlinux.org/task/80064#comment223100
> [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bbbf096ea227607cbb348155eeda7af71af1a35b
> [4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa3998dbeb3abce63653b7f6d4542e7dcd022590

See Bugzilla for the full thread.

Anyway, I'm adding this regression to regzbot:

#regzbot introduced: aa3998dbeb3abc https://bugzilla.kernel.org/show_bug.cgi?id=218038
#regzbot title: dirty shutdown due to disabling manage_system_start_stop on SCSI devices
#regzbot link: https://bugs.archlinux.org/task/80064

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218038

-- 
An old man doll... just what I always wanted! - Clara

Re: Fwd: bbbf096ea227607cbb348155eeda7af71af1a35b results in "dirty" shutdown

[Damien Le Moal]

On 10/25/23 09:40, Bagas Sanjaya wrote:
> Hi,
> 
> I notice a regression report on Bugzilla that seems to have been
> handled already there [1]. Quoting from it:
> 
>> I have noticed that after each shutdown SMART would log +1 on each raw_value of drives that count power related issues.
>>
>> Here are some of the smart values where i noticed increase among different drives
>>
>> POR_Recovery_Count 
>> Unexpect_Power_Loss_Ct  
>> Power-Off_Retract_Count 
>>
>> That doesn't happen on previous Kernels.. and it stops as soon as i switch back to LTS.
>> I seeked through the Bug Reports but couldn't really find the issue. So i don't know if this has been reported or patched already.
> 
> Another reporter had found the culprit:
> 
>>
>>
>> This has been reported as being introduced in stable 6.5.8 [1].  Reverting commit 	bbbf096ea227607cbb348155eeda7af71af1a35b is reported to solve the issue [2]. bbbf096ea227607cbb348155eeda7af71af1a35b [3] is mainline commit aa3998dbeb3abce63653b7f6d4542e7dcd022590 [4] which was introduced in 6.6-rc4 which matches the original report.
>>
>> [1]: https://bugs.archlinux.org/task/80064
>> [2]: https://bugs.archlinux.org/task/80064#comment223100
>> [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bbbf096ea227607cbb348155eeda7af71af1a35b
>> [4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa3998dbeb3abce63653b7f6d4542e7dcd022590
> 
> See Bugzilla for the full thread.

I am aware of this and looking into it. The patch mentioned above seems to have
introduced the issue that drives are not being stopped on shutdown with real
PCs. But they are with qemu VM. So this seems to relate to ACPI shutdown as
well. Not sure, looking into it.

The main issue I have is that I cannot reproduce the old behavior mentioned in
this case, which is, the counters not incrementing on shutdown. They do increase
for me, always, even prior to the patch mentioned above.

Digging.

> Anyway, I'm adding this regression to regzbot:
> 
> #regzbot introduced: aa3998dbeb3abc https://bugzilla.kernel.org/show_bug.cgi?id=218038
> #regzbot title: dirty shutdown due to disabling manage_system_start_stop on SCSI devices
> #regzbot link: https://bugs.archlinux.org/task/80064
> 
> Thanks.
> 
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218038
> 

-- 
Damien Le Moal
Western Digital Research

Re: Fwd: bbbf096ea227607cbb348155eeda7af71af1a35b results in "dirty" shutdown

[Damien Le Moal]

On 10/25/23 09:40, Bagas Sanjaya wrote:
> Hi,
> 
> I notice a regression report on Bugzilla that seems to have been
> handled already there [1]. Quoting from it:
> 
>> I have noticed that after each shutdown SMART would log +1 on each raw_value of drives that count power related issues.
>>
>> Here are some of the smart values where i noticed increase among different drives
>>
>> POR_Recovery_Count 
>> Unexpect_Power_Loss_Ct  
>> Power-Off_Retract_Count 
>>
>> That doesn't happen on previous Kernels.. and it stops as soon as i switch back to LTS.
>> I seeked through the Bug Reports but couldn't really find the issue. So i don't know if this has been reported or patched already.
> 
> Another reporter had found the culprit:
> 
>>
>>
>> This has been reported as being introduced in stable 6.5.8 [1].  Reverting commit 	bbbf096ea227607cbb348155eeda7af71af1a35b is reported to solve the issue [2]. bbbf096ea227607cbb348155eeda7af71af1a35b [3] is mainline commit aa3998dbeb3abce63653b7f6d4542e7dcd022590 [4] which was introduced in 6.6-rc4 which matches the original report.
>>
>> [1]: https://bugs.archlinux.org/task/80064
>> [2]: https://bugs.archlinux.org/task/80064#comment223100
>> [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bbbf096ea227607cbb348155eeda7af71af1a35b
>> [4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa3998dbeb3abce63653b7f6d4542e7dcd022590
> 
> See Bugzilla for the full thread.
> 
> Anyway, I'm adding this regression to regzbot:
> 
> #regzbot introduced: aa3998dbeb3abc https://bugzilla.kernel.org/show_bug.cgi?id=218038
> #regzbot title: dirty shutdown due to disabling manage_system_start_stop on SCSI devices
> #regzbot link: https://bugs.archlinux.org/task/80064

#regzbot fixed-by: 24eca2dce0f8d19db808c972b0281298d0bafe99


> 
> Thanks.
> 
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218038
> 

-- 
Damien Le Moal
Western Digital Research

Re: Fwd: bbbf096ea227607cbb348155eeda7af71af1a35b results in "dirty" shutdown

[Linux regression tracking (Thorsten Leemhuis)]

On 27.10.23 09:41, Damien Le Moal wrote:
> On 10/25/23 09:40, Bagas Sanjaya wrote:
>>
>> I notice a regression report on Bugzilla that seems to have been
>> handled already there [1]. Quoting from it:
> [...]
>>> [1]: https://bugs.archlinux.org/task/80064
>>> [2]: https://bugs.archlinux.org/task/80064#comment223100
>>> [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bbbf096ea227607cbb348155eeda7af71af1a35b
>>> [4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa3998dbeb3abce63653b7f6d4542e7dcd022590
>>
>> See Bugzilla for the full thread.
>>
>> Anyway, I'm adding this regression to regzbot:
>>
>> #regzbot introduced: aa3998dbeb3abc https://bugzilla.kernel.org/show_bug.cgi?id=218038
>> #regzbot title: dirty shutdown due to disabling manage_system_start_stop on SCSI devices
>> #regzbot link: https://bugs.archlinux.org/task/80064

Damien, many thx for handling this regression so quickly.

FWIW, a quick remark, as it might save you (and others seeing this) some
work in the future:

> #regzbot fixed-by: 24eca2dce0f8d19db808c972b0281298d0bafe99

Telling regzbot about this is nice, but not really needed[1], as your
fix afaics contains links to the reports that are tracked by regzbot.
Hence regzbot would have noticed the fix automatically once it lands in
next or mainline[2], just like it noticed and tracked the patches you
posted for review earlier.

Ciao, Thorsten

[1] it just makes it a little more obvious that a fix is now incoming

[2] there is a bug there somewhere that make it fail sometimes, but I'll
sooner or later catch it