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

[birdie]

I'll be happy to review and if appropriate accept respective patches. Note that the original patch included support for reporting energy values, which should be dropped. See Jean Delvare's feedback from the time for reasons.

I'm quite sure this patch is so stale it won't apply to mainline and thus needs to be fixed/rewritten and I'm not a C programmer to do that. And I've no idea how to make the person who wrote it in the first place to get back to it. Looks like a lost case to me

I'm pretty sure thousands of users will be happy to test it just like we're now testing your k10temp patched driver.

[groeck]

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?

I'll be happy to review and if appropriate accept respective patches. Note that the original patch included support for reporting energy values, which should be dropped. See Jean Delvare's feedback from the time for reasons.

[groeck]

... 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.

Thanks everyone for the test feedback. An updated version of the series is now available at https://patchwork.kernel.org/project...?series=230307. Note that I may hold the series for the 5.7 kernel; while I got a lot of test feedback, no one actually reviewed the code. I won't drop it entirely without review (it doesn't seem that risky), but that warrants a lengthy soak time in linux-next.

[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?

[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.

[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..

[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

[tildearrow]

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

What are you talking about?

[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.

[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.