Re: [REGRESSION][BISECTED][STABLE] hdparm errors since 28ab9769117c

[Christian Heusel]

On 24/08/09 08:42PM, Christian Heusel wrote:
> On 24/08/09 08:34AM, Damien Le Moal wrote:
> > On 2024/08/07 15:10, Niklas Cassel wrote:
> > > On Wed, Aug 07, 2024 at 11:26:46AM -0700, Damien Le Moal wrote:
> > >> On 2024/08/07 10:23, Christian Heusel wrote:
> > >>> Hello Igor, hello Niklas,
> > >>>
> > >>> on my NAS I am encountering the following issue since v6.6.44 (LTS),
> > >>> when executing the hdparm command for my WD-WCC7K4NLX884 drives to get
> > >>> the active or standby state:
> > >>>
> > >>>     $ hdparm -C /dev/sda
> > >>>     /dev/sda:
> > >>>     SG_IO: bad/missing sense data, sb[]:  f0 00 01 00 50 40 ff 0a 00 00 78 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >>>      drive state is:  unknown
> > >>>
> > >>>
> > >>> While the expected output is the following:
> > >>>
> > >>>     $ hdparm -C /dev/sda
> > >>>     /dev/sda:
> > >>>      drive state is:  active/idle
> > >>>
> > 
> > Yes, indeed. I do not want to revert any of these recent patches, because as you
> > rightly summarize here, these fix something that has been broken for a long
> > time. We were just lucky that we did not see more application failures until
> > now, or rather unlucky that we did not as that would have revealed these
> > problems earlier.
> > 
> > So I think we will have some patching to do to hdparm at least to fix the
> > problems there.
> 
> It seems like this does not only break hdparm but also hddtemp, which
> does not use hdparm as dep as far as I can tell:
> 
>     # on bad kernel for the above issue
>     $ hddtemp /dev/sda
>     /dev/sda: WDC WD40EFRX-68N32N0                    : drive is sleeping
> 
>     # on good kernel for the above issue
>     $ hddtemp /dev/sda
>     /dev/sda: WDC WD40EFRX-68N32N0: 31°C
> 
> I didn't take the time to actually verify that this is the same issue,
> but it seems very likely from what we have gathered in this thread
> already.
> 
> So while I agree that it might have previously just worked by chance it
> seems like there is quite some stuff depending on the previous behavior.
> 
> This was first discovered in [this thread in the Arch Linux Forums][0]
> by user @GerBra.
> 
>  ~Chris
> 
> [0]: https://bbs.archlinux.org/viewtopic.php?id=298407

As someone on the same thread has pointed out, this also seems to affect
udiskd:

https://github.com/storaged-project/udisks/issues/732

Attachment: signature.asc
Description: PGP signature