Lm_Sensor depending Proggies not showing temperature of SATA-drives

Using Freon on Manjaro-Gnome (unstable), the update today is hiding all SATA-drives (but not the NVMe).
.
If kernel-module drivetemp is loaded ( sudo modprobe drivetemp )
then ALL the SATA-drives are called “temp1” -
instead of for example " SAMSUNG HD…".
found with: Kernel 6.1.103-1 and 6.10.3-1
.
Kernel 6.1.100-1 is o.K. (Everything works as it should…)

If kernel module “drivetemp” is loaded:
To configure lm_sensors, you can create a file /etc/sensors.d/drivetemp
contents:

chip "drivetemp-*"
label temp1 "Test-Platte"

All SATA-drives are called “Test-Platte”.
An error occurs - if you write: chip “drivetemp-scsi-1-0”

Udisk2 seems to be affected, the udisk2.service complains:

"Error probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sda':
unexpected sense data returned  ....."

“Psensors” is affected too, doesnot show any SATA-drive

Reason might be changing kernel version;
linux6.1.100-1 = o.K. / 6.1.103 = does not work
linux6.10.0-3 = o.K. / 6.10.3-3 and 6.140.3-4 = does not work (? 6.10.3-1 too?)

What’s that? Maybe the Freon GNOME Shell Extension?

That’s a bit vague. What update? You’re using the unstable branch, right?

Yes, indeed.

Right, unstable. The other PC using testing, is affected too,
also PSensor - seems all programs that use lm_sensors…

Are you loading it on boot? This is what I do:

❯ cat /etc/modules-load.d/modules.conf
# List of modules to load at boot
drivetemp
i2c-dev

cat /etc/modules-load.d/modules.conf
==> the list is empty:
.
/etc/modules-load.d/drivetemp.conf
contains this entry:

# List of modules to load at boot
drivetemp

Now changed to (and deleted /etc/modules-load.conf/drivetemp.conf):
/etc/modules-load.d/modules.conf

# List of modules to load at boot
drivetemp

Then result of:
cat /etc/modules-load.d/modules.conf
is

# List of modules to load at boot
drivetemp

(prior it was empty)
Result: nothing changed at all…

You already had it set then. It doesn’t matter what the name of the file is. :wink:

1 Like

Hi.
I think your problem is the similar to mine.
WHen i am tryin to issue command via hdparm i see next thing:

$ 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

There was a commit in v6.6.44 and it was backported to the
v6.10.3 and v6.1.103 according to Christian Heusel and it breaks something with hdparm and i think it is a culprit of your problem too.


#regzbot introduced: 28ab9769117c
#regzbot title: ata: libata-scsi: Sense data errors breaking hdparm with WD drives


Please check.

Full post from kernel org is here

Full message from **Christian Heusel**

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

I did a bisection within the stable series and found the following
commit to be the first bad one:

28ab9769117c ("ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error")

According to kernel.dance the same commit was also backported to the
v6.10.3 and v6.1.103 stable kernels and I could not find any commit or
pending patch with a “Fixes:” tag for the offending commit.

So far I have not been able to test with the mainline kernel as this is
a remote device which I couldn’t rescue in case of a boot failure. Also
just for transparency it does have the out of tree ZFS module loaded,
but AFAIU this shouldn’t be an issue here, as the commit seems clearly
related to the error. If needed I can test with an untainted mainline
kernel on Friday when I’m near the device.

I have attached the output of hdparm -I below and would be happy to
provide further debug information or test patches.

Cheers,
Christian


#regzbot introduced: 28ab9769117c
#regzbot title: ata: libata-scsi: Sense data errors breaking hdparm with WD drives


Correct. Looks like a change in kernel code, lm_sensors and PSensors or similar can’t handle it.
Seagate and Samsung drives are affected too (but not any NVMe-drive).

1 Like

Problem solved. Updated (and tested) kernels linux 6.6.47-1 and linux 6.10.6-1 o.K.
@philm solved it!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.