That is exactly caused by the bug we tell about…
But im using the older LTS Kernel (Kernel: 6.1.55-1-MANJARO) from stable branch… and you told us, you only see this behaviour with the newer Kernels…
So for my exsample the info is not true, and i have this issue over a longer period… who knows how long? I never regulary checked my smartvalues and with my silent case, i can’t tell the noise difference from HDD if my Disk is flawless powered down or not.
192 Power Off Retract Count
Count of power-off or emergency retract cycles Old-Age Online 97 97 0 0x000000001287 N/A 4.743
And even from sleep mode its raising to 4745 now.
So as Manjaro user, i just had to use this command as workaround and thats it?
wget https://dn.odroid.com/5422/script/odroid.shutdown
sudo install -o root -g root -m 0755 ./odroid.shutdown /lib/systemd/system-shutdown/odroid.shutdown
It is worth to be tested - it works for me.
Please report!
Been following the thread and applied the same workaround yesterday. Working for me as well 
1 Like
Arch is suffering too - please read…
https://bbs.archlinux.org/viewtopic.php?id=289789
Unfortunately we’re not really allowed to report kernel issues as we’re using Manjaro patched and built kernels. What would be the proper procedure to have valid report besides installing another OS with official kernel packages?
//EDIT: issue has been reported, author of “bad commit” contacted
1 Like
Sad… its not working at all… i see it when i shutdown my PC, that unmounts going on and i see it wants to disable my Sata Ports, but my Power Off Retract Count is raising to 4746 
Edit: Sleep Mode raised it now to 4747 
You may have a different issue.
Depends on drive:
One: Seagate BarraCuda 3.5 (SMR) / ST4000DM004-2CV104
SMART ID192: 20 (RAW Value)
Next: Western Digital Red / WDC WD10EFRX-68FYTN0
SMART ID192: 66 (RAW-Value)
On an ASUS-B550-machine…
EDIT:
latest news = [SOLVED] Arch shutdown powers off HDD abruptly / Kernel & Hardware / Arch Linux Forums
Good finding! Can we install this Kernel as well? Or do we need to wait for somebody from the Manjaro staff to implement it into the Manjaro kernel?
As linux6.5.8-3 does not fix this (t)issue
No, we didn’t reverted ata: libata-scsi: Disable scsi device manage_system_start_stop · torvalds/linux@bbbf096 · GitHub so far. Most likely this got added to 6.6 development cycle and was backported to many stable kernels. Also the upcoming stable kernels won’t have a fix unless one was queued up for Wednesdays releases. So let me check the kernel mailing list and which kernels introduced that regression.
Also it means that there is no real solution for that issue yet found:
Damien Le Moal 2023-10-24 11:34:41 UTC
(In reply to Artem S. Tashkinov from comment #3) > CC’ing Damien Le Moal, the author of the bad commit. Bad commit ? Please measure your words… This commit fixes a very real and serious issue with system/suspend resume. But sure, it looks like it did introduce a regression that went unnoticed, which seems to be that ATA drives are not being suspended before a system shutdown. I will have a look tomorrow (too late for me today). In the mean time, please test with the latest 6.6-rc7 to confirm if this issue is still present.
Comment 5 loqs 2023-10-24 12:22:22 UTC
I can reproduce the issue with 6.6-rc7. Do you need any outputs?
2 Likes
“which kernels introduce that regression”
afaik 6.1 / 6.5 /6.6
But thank you so much 
You have to find the exact point-releases and not just major kernel series numbers. As it can also been added to 5.x and 4.x kernels …
I see…
you could download that git repo and check for the offending patch in each release folder to find the exact numbers … example
Apparently it is the very latest point releases: 6.5.8 and 6.1.59.
1 Like
well @GaVenga already mentinoed the exact versions he found the regression, but forgot: When shutting down PC, all mechanical hard-disks run down hard - #21 by GaVenga. Anyhow, there is now a fix candidate available, which I applied to 6.1, 6.5 and 6.6 kernel series. Should be available in about 3 hours. Would be great to test it and give feedback to the mailing-list: 218038 – bbbf096ea227607cbb348155eeda7af71af1a35b results in "dirty" shutdown
The issue ucurred when updating:
==> kernel 6.1.58-1 (o.K.) TO kernel 6.1.59.1
==> kernel 6.5.7-1 (o.K.) TO kernel 6.5.8-1
==> kernel 6.6.0rc4-1 - has issue (had no version tested before)
==> kernel 6.6.0rc6-1 - has issue…
@philm Sorry if the answer to this question is obvious, but how are we supposed to grab the fix candidate? Thanks for all your efforts btw
And thanks to Hartmut for raising the issue in the first place. I wouldn’t even have noticed (Running 10+ HDDs on my machine hehe also vielen Dank!)
1 Like