Linux In 2020 Can Finally Provide Sane Monitoring Of SATA Drive Temperatures

[starshipeleven]

And that's the reason, gentlemen, Linux has sucked, sucks and will always suck. For other OSes people usually just get work done ,e.g. HWiNFO reports everything on earth, no questions asked.

HWiNFO and any other application like that runs as Administrator, dumbass

[starshipeleven]

HWiNFO does not need any "special drivers for sensors".

Yeah, because it is an application running as Administrator that supports the protocols and the bs on its own https://www.hwinfo.com/version-history/

How can you even claim it is different from Smartmontools or whatever other linux userspace application that runs as root and does stuff is beyond me

[SilverBird775]

HDD temperature polling does affect its performance. Can't say the same about SSDs because I haven't tested that.

Oh, thats unfortunate. Perhaps it is causing by some SMART data renewing and cache flushing to fixate its inner state before reporting. There should be more direct and non invasive method (ATA SCT) to collect temperature data. I had no chance to observe the performance hit on my SSD (SATA-AHCI) because the sensor lib pick up the useless lifespan SMART attribute instead of temperature. Gnome disk's SMART report treating lifespan attribute as secondary temperature sensor as well.


.

[caligula]

Oh, thats unfortunate. Perhaps it is causing by some SMART data renewing and cache flushing to fixate its inner state before reporting. There should be more direct and non invasive method (ATA SCT) to collect temperature data. I had no chance to observe the performance hit on my SSD (SATA-AHCI) because the sensor lib pick up the useless lifespan SMART attribute instead of temperature. Gnome disk's SMART report treating lifespan attribute as secondary temperature sensor as well.

Might be the case that fetching only temp data won't slow down as much. smarctl --all fetches all sorts of things.

[caligula]

Too bad when SATA drives just went to the same pile as floppy drives.

Don't be silly. The price per storage unit is significantly lower. At least for smaller corporations, spending $10k or $100k on drives is a relevant question.

[tildearrow]

Too bad when SATA drives just went to the same pile as floppy drives.

What are you talking about?

[tildearrow]

HWiNFO does not need any "special drivers for sensors". It works right out of the box after you install Windows without installing any drivers whatsoever.

It needs AMD/NVIDIA drivers to monitor GPUs though but it's because NVIDIA and AMD closely guard their HW interfaces and only expose them via their own proprietary APIs.

God, why are there so many stupid open source fanatics here?

I. completely. agree.

It's been a while and I still cannot read my AMD card's memory temperature or voltage.

Manufacturers just don't care enough to work with Linux :l

[tuxd3v]

I. completely. agree.
It's been a while and I still cannot read my AMD card's memory temperature or voltage.
Manufacturers just don't care enough to work with Linux :l

That type of Hardware is diferent..
Disks are a very sensitive thing, among others..

Seagate has the OpenSeaChest Tools, and they work great, for other vendors I don't know..

[groeck]

Thanks a lot for all the feedback. Regarding test coverage for drivetemp, I can only recommend for everyone - especially everyone who raised concerns here - to test it and provide feedback. The driver is only loaded on request, so anyone with concerns about performance impact can simply not load it or, to be sure, blacklist it. This is not an opt-out driver, it is an opt-in driver.
Regarding temperature and other telemetry reporting on Ryzen CPUs, please note that AMD did not publish the necessary information which would enable any such improvements. Quite obviously at least some of that information has leaked, and the zenpower driver referenced here makes use of it. At this point I would like to point out that patches to improve the upstream k10temp driver to report the additional telemetry have before now not been posted. As a kind reminder, anyone interested in such improvements to this and other drivers is invited to submit patches for inclusion into the upstream kernel. Either case, a preliminary patch series adding more telemetry reporting to the k10temp driver is now available for testing at https://patchwork.kernel.org/project...?series=229271.

[birdie]

Thanks a lot for all the feedback. Regarding test coverage for drivetemp, I can only recommend for everyone - especially everyone who raised concerns here - to test it and provide feedback. The driver is only loaded on request, so anyone with concerns about performance impact can simply not load it or, to be sure, blacklist it. This is not an opt-out driver, it is an opt-in driver.
Regarding temperature and other telemetry reporting on Ryzen CPUs, please note that AMD did not publish the necessary information which would enable any such improvements. Quite obviously at least some of that information has leaked, and the zenpower driver referenced here makes use of it. At this point I would like to point out that patches to improve the upstream k10temp driver to report the additional telemetry have before now not been posted. As a kind reminder, anyone interested in such improvements to this and other drivers is invited to submit patches for inclusion into the upstream kernel. Either case, a preliminary patch series adding more telemetry reporting to the k10temp driver is now available for testing at https://patchwork.kernel.org/project...?series=229271.

Great many thanks, Guenter! It's great to see you here - quite unexpected!

Now what about reviving additional data points in the coretemp driver, a feature I asked you about many years ago, and you actually implemented it, only to abandon it swiftly under some weird pretense?