[SOLVED] hddtemp issue with Samsung SSD 850 PRO 256G

[sdauth]

Hi,
I'm unable to fetch the temp for this SSD, it is missing from provided hddtemp.db so I created a custom one in /etc/hddtemp.db with field(190) to get the correct value but it doesn't work.

hddtemp /dev/sdk

Code: Select all

/dev/sdk: Samsung SSD 850 PRO 256G B              �@ : no sensor

What's wrong ?

hddtemp /dev/sdk --debug

Code: Select all

================= hddtemp 0.3-beta15 ==================
Model: Samsung SSD 850 PRO 256G B              �@

field(5)	 = 0
field(9)	 = 41
field(12)	 = 30
field(177)	 = 35
field(179)	 = 0
field(181)	 = 0
field(182)	 = 0
field(183)	 = 0
field(187)	 = 0
field(190)	 = 32
field(195)	 = 0
field(199)	 = 0
field(235)	 = 47
field(241)	 = 21

If one of the field value seems to match the temperature, be sure to read
the hddtemp man page before sending a report (section REPORT). Thanks.

/etc/hddtemp.db

Code: Select all

"Samsung SSD 850 PRO 256G B"           190 C "Samsung SSD 850 PRO 256G B"

Thanks

[mike155]

hddtemp doesn't seem to work for my Samsung 840 PRO either:

Code: Select all

# hddtemp /dev/sdb

/dev/sda: Samsung SSD 840 PRO Serise              �:  no sensor

smartctl, on the other hand, works perfectly fine:

Code: Select all

# smartctl -a /dev/sdb

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 840 PRO Series
...
190 Airflow_Temperature_Cel 0x0032  076  060  000  Old_age  Always  -  24

[sdauth]

mike155,

Alright, good to know. yes indeed, smartctl works.
I see there is a new driver in kernel to get hdd temp without installing hddtemp.

Only applies to kernel >5.6 though, I'll try that later. (I use 5.4.x)

https://www.phoronix.com/scan.php?page= ... SATA-Temps

Here is another long overdue kernel change... For more than a decade there have been patches trying to get SATA/SCSI drive temperature monitoring working nicely within the Linux kernel but none of that work ever made it through for mainlining. That has left various user-space tools to provide the functionality, but in doing so that has required root access and not to mention the need to first install said utilities. Well, with Linux 5.6 in 2020, there is finally a proper drive temperature driver for disks and solid-state drives with temperature sensors.

It took until the current Linux 5.5 cycle to see a kernel driver for NVMe drive temperatures to avoid having to run third-party utilities as root in user-space while now for Linux 5.6 will be the support for even older SATA/SCSI drives with the new "drivetemp" driver.

[mike155]

Yes, you're right, 'sensors' now reports the temperatures of my SSDs.

Below is what 'sensors' prints for my Samsung SSD 840 PRO Series (SATA):

Code: Select all

drivetemp-scsi-1-0
Adapter: SCSI adapter
temp1:        +24.0°C  (low  =  +0.0°C, high = +70.0°C)
                       (crit low =  +0.0°C, crit = +70.0°C)
                       (lowest = +21.0°C, highest = +40.0°C)

And here is what 'sensors' prints for my Samsung SSD 970 EVO Plus 2TB (NVMe):

Code: Select all

nvme-pci-0200
Adapter: PCI adapter
Composite:    +39.9°C  (low  = -273.1°C, high = +84.8°C)
                       (crit = +84.8°C)
Sensor 1:     +39.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +40.9°C  (low  = -273.1°C, high = +65261.8°C)

[sdauth]

I installed 5.10.23 and it works fine indeed now, it shows all temps, very nice I will probably remove hddtemp now
The only "issue" is that sensors command reports the drives as :

drivetemp-scsi-1-0
etc..
I wonder if it could show the block like /dev/sda etc.. instead or the model so I know which drive I'm looking at.

Meanwhile, this works (with model name and temp) :

Code: Select all

grep -l "drivetemp" /sys/class/hwmon/hwmon*/name | while read f; do printf "%s(%-.2s°C)\n" "`<${f%/*}/device/model`" "`<${f%/*}/temp1_input`"; done

EDIT : Some good info here : https://github.com/lm-sensors/lm-sensors/issues/230
I'll read that later, I have to go now.

[fedeliallalinea]

Moved from Other Things Gentoo to Kernel & Hardware.

[Anon-E-moose]

hddtemp only needs a line added for any device it doesn't know, telling it where to look (typically 190) for it's value
The database (despite the name) is a text file

add this after modifying for whatever you need and it should work.

Code: Select all

"Samsung SSD 860 EVO 1TB"					190 C "Samsung SSD 860 EVO 1TB"

The samsung description on the left comes from smartctl -i <drive>
Device Model:

Edit to add: the name sensors applies to the device (such as nvme-pci-0100) comes from somewhere in the /sys area.

[sdauth]

Anon-E-moose,

Yes, that's what I did but it doesn't work nonetheless.
I suspect the garbage characters are causing some trouble.
This is what I get when running --debug (or not)

Code: Select all

Samsung SSD 850 PRO 256G B              �@ # <-WTF?

I tried adding this to hddtemp.db, I also rebooted just in case :

Code: Select all

"Samsung SSD 850 PRO 256G B"           190 C "Samsung SSD 850 PRO 256G B"

and also (with the garbage)

Code: Select all

"Samsung SSD 850 PRO 256G B              �@"           190 C "Samsung SSD 850 PRO 256G B"

Nothing. This is the only drive failing. I have an Apple SSD, a 840 Evo, a bunch of WD hdd, all detected and without garbage characters.

On the other hand, drivetemp driver works flawlessly. (smartctl as well of course)

EDIT : It seems there is a patch for the garbage characters -> https://bugs.debian.org/cgi-bin/bugrepo ... bug=891501
I will try that.

[Anon-E-moose]

Since hddtemp uses the first part as a lookup, the odd characters would be a problem.

Does it print out the oddness with smartctl -i

If so, the do smartctl ><some file>
edit the file down to just the piece you need and put that into the db.

Note: haven't tried it, don't have a drive that reports something like that. And it may not work depending on how hddtemp "parses" the file and whether they take into account things like the odd characters.

Edit to add: reading your edit

The fix is just to chop it after the "B" character in the db ? Or is he talking about changing hddtemp itself?

[sdauth]

The fix is just to chop it after the "B" character in the db ? Or is he talking about changing hddtemp itself?

It changes some code indeed.
So I applied the patch and now there is no more garbage characters at the end (good) but hddtemp still fails to read the sensor.. I give up.

smartctl -i output is perfect, hdparm as well. Maybe it's an issue with this specific model and hddtemp.

[sdauth]

Ok...

Now I feel really stupid. Forget about the patch, no need for that. (Unless you want a clean output without garbage, see -> hddtemp_model_name.patch )
The resolution was quite simple actually, I forgot to pass the -f argument to read the custom database.. I assumed hddtemp would have picked up /etc/hddtemp.db but no.. by default it reads :

Code: Select all

/usr/share/hddtemp/hddgentoo.db
/usr/share/hddtemp/hddtemp.db

So, if you query manually the temp, pass -f argument.
hddtemp -f /etc/hddtemp.db /dev/sdk

By the way, this entry works :

Code: Select all

"Samsung SSD 850 PRO 256"       190 C "Samsung SSD 850 PRO"

And finally if you use the openrc service, make sure to pass --file option if custom entry is not in /usr/share/hddtemp..

/etc/conf.d/hddtemp

Code: Select all

[...]
HDDTEMP_OPTS="--listen=127.0.0.1 --file=/etc/hddtemp.db"
[...]

[Anon-E-moose]

Glad you got it working.

I used to monitor my temps all the time, but once I was sure they were staying stable, I usually just do check with smartctl when I want to know. Plus constantly monitoring the temps, at least on my nvme, caused it to run a degree hotter.