Bug 1054593 - Two new drive strings for the hddtemp database for Samsung SSD drives
Summary: Two new drive strings for the hddtemp database for Samsung SSD drives
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: hddtemp
Version: 19
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-17 05:44 UTC by Edward Kuns
Modified: 2014-01-28 04:39 UTC (History)
2 users (show)

Fixed In Version: hddtemp-0.3-0.30.beta15.fc19
Clone Of:
Environment:
Last Closed: 2014-01-28 04:39:22 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Edward Kuns 2014-01-17 05:44:11 UTC
Description of problem:

Two Samsung SSD drives aren't detected.

Version-Release number of selected component (if applicable):

hddtemp-0.3-0.26.beta15.fc19.x86_64

Details:

Here are two new lines for the hddtemp database:

"Samsung SSD 840 PRO Serise"                190  C  "SAMSUNG SSD 840 PRO"
"SAMSUNG SSD 830 Series"                190  C    "SAMSUNG SSD 830"

I added these at line 277.  This allows the utility to read the sensors of the two named SSD drives, which I have.  Yes the 840 Pro has a misspelling in the data it returns.  It also returns a bogus character in its name, as you can see from the output below:

# hddtemp --debug /dev/sda

================= hddtemp 0.3-beta15 ==================
Model: Samsung SSD 840 PRO Serise              �

field(5)     = 0
field(9)     = 188
field(12)     = 2
field(177)     = 16
field(179)     = 0
field(181)     = 0
field(182)     = 0
field(183)     = 0
field(187)     = 0
field(190)     = 31
field(195)     = 0
field(199)     = 0
field(235)     = 1
field(241)     = 205


# hddtemp --debug /dev/sdb

================= hddtemp 0.3-beta15 ==================
Model: SAMSUNG SSD 830 Series

field(5)     = 0
field(9)     = 191
field(12)     = 13
field(177)     = 19
field(179)     = 0
field(181)     = 0
field(182)     = 0
field(183)     = 0
field(187)     = 0
field(190)     = 29
field(195)     = 0
field(199)     = 0
field(235)     = 12
field(241)     = 128

I sent the above information to the email address in the man page for hddtemp and got an immediate bounce, so I am not certain where the ultimate source control is located, today, for hddtemp.  With the above information, at least Fedora can properly detect these SSD drives.  I also have two physical drives, and the temperature data returned by the SSD drives correlates well with the temperature data returned by they physical drives.

Comment 1 Ville Skyttä 2014-01-18 13:23:30 UTC
Some searching around the web tells me that these aren't the only drives that lack attribute 194 but do have useful data in 190, so here's a try for something more generic: try 190 if 194 doesn't exist by default (smartd does that too):

http://koji.fedoraproject.org/koji/buildinfo?buildID=492107

Could you try it out and let me know if it works for you? It's built for Rawhide but can be installed as is on F-19.

Comment 2 Edward Kuns 2014-01-18 19:17:11 UTC
I tried it and it works perfectly.  Thank you.  Great idea to keep the database to only exceptions.  It's probably a good idea, however, to keep a header describing the data.  Something like this:

# Minimal database for drives not covered by defaults (attributes 194 and 190).
# hddtemp will first try S.M.A.R.T. attribute 194.  If it does not exist, it will
# try attribute 190.
#
# The four columns are:
# 1) Regular expression matching the drive identification, which you see as the
#    Model in the output of:  hddtemp --debug /dev/drive
# 2) S.M.A.R.T. attribute number to get drive temperature. A value of zero
#    means that we know that the drive doesn't have a temperature sensor.
# 3) Temperature units reported (C or F).
# 4) Human readable string representing the drive model

I assume when (if?) this gets pushed to F19, I'll have to uninstall this version to be able to install the Fedora 19 update?

Comment 3 Ville Skyttä 2014-01-18 20:21:04 UTC
Thanks for the db description comments, adopted a slightly modified version in 0.3-0.30.beta15. The upcoming F-19 update will be 0.30.beta15.fc19 so it'll upgrade your 0.29.beta15.fc21, no need for uninstall or downgrade first.

Comment 4 Fedora Update System 2014-01-18 20:32:26 UTC
hddtemp-0.3-0.30.beta15.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/hddtemp-0.3-0.30.beta15.fc19

Comment 5 Fedora Update System 2014-01-18 20:34:19 UTC
hddtemp-0.3-0.30.beta15.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/hddtemp-0.3-0.30.beta15.fc20

Comment 6 Fedora Update System 2014-01-20 03:02:33 UTC
Package hddtemp-0.3-0.30.beta15.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hddtemp-0.3-0.30.beta15.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-1152/hddtemp-0.3-0.30.beta15.fc19
then log in and leave karma (feedback).

Comment 7 Edward Kuns 2014-01-20 14:25:30 UTC
Tested hddtemp-0.3-0.30.beta15.fc19 from updates-testing repo and it works perfectly.

Comment 8 Fedora Update System 2014-01-28 04:38:00 UTC
hddtemp-0.3-0.30.beta15.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2014-01-28 04:39:22 UTC
hddtemp-0.3-0.30.beta15.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.