1

What sensors I can monitor on my AMD Threadripper 1950x on an ASRock x399 Taichi mobo under Linux. It was announced last year that temperature monitoring was working for Ryzen processors and that was supposedly included in the 4.15 kernel, according to this:https://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-Temps-Hwmon-Next. However, it seems the temperatures are offset, which was fixed in kernel 4.18.6 according to this: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18.6-k10temp-Correct

As far as I can tell there is absolutely no talk of per-core temperature monitoring under Linux as is available with Windows.

However, other sources suggest that I might need to build modules specifically based on my motherboard. These instructions seem to suggest that I can build the appropriate kernel drivers based on the output of sensors-detect: https://linuxconfig.org/monitor-amd-ryzen-temperatures-in-linux-with-latest-kernel-modules

Accoding to sensors-detect I have nct6775, but I can't find any sign that that I have the appropriate kernel module (not shown with lsmod, is there someplace else I should look?). Unfortunately, I cannot build from the repository because it is no longer on github.

So these are my questions:

  1. What drivers and kernel modules give what information? Specifically, which ones give the per-core readings that are available under Windows?

  2. What is the status of temperature drivers for Ryzen under linux: complete, incomplete, hacked together and never-to-be-reliable?

  3. If I can get nct6775 built, what will that give me in addition to the K10 that I already have? Where else might I go to get the source to build them from?

  4. Why is this so poorly documented? Is not having clear info about this a year and a half after release par for the course, are is AMD being unusually unhelpful by industry standards?

1

[deleted answer by OP:] I would still like to know: what exactly is making nct6775 available now?

There are a lot of attempts at answering the general question in the following link. Unfortunately none of them are comprehensive, so I will try to improve on them. Linux: How to find the device driver used for a device?

In your case, the sensor device can be found as one of the links shown in ls -l /sys/class/hwmon/*. You could try to extend that command, and find your kernel module immediately:

ls -l /sys/class/hwmon/*/device/driver/module

However, this command makes some assumptions. It will not work in every case. If the command does not work, narrow it down by checking each individual link in the chain. There are three possible cases.

  1. You have a driver link, but no module link.

    This means the driver is built in to the kernel! Which would kind of answer your question :-).

    It is equally possible to ls -l on the driver link. I.e. to see the name of the driver, change the above command to remove the /module part. Often the driver name is the same as the name of the loadable module, but sometimes they are different.

  2. The driver link is not immediately under device, but...

    If the above command does not work, you might need to replace device with device/device, or so on.

    The device link takes you to the parent device. But sometimes the driver is on the grandparent device instead, or even further :-).

  3. None of the parent device(s) have a driver link, or there is no parent device link at all.

    The device link takes you to the parent device. For example, you might have a network device /sys/class/wlan0, and /sys/class/wlan0/device might point to a PCI card which provides wlan0.

    In your case, I can imagine it not having anything like a device on the standard pci bus. In this case the driver is supposed to define its own custom device, in /sys/devices/platform/. This is exactly what the coretemp driver for my Intel CPU does.

    But if your driver got this wrong, it would create a device with no parent, and hence no device link. Sensors (hwmon devices) are one of the more obscure child devices; I've seen this happen several times before. Looking in ls /sys/devices/virtual/*, I seem to have three devices that get this wrong, and all of them are hwmon devices.

    If there is no "physical" / parent device - then there can be no driver. This is expected behaviour for genuinely virtual devices, like loopback (lo) or bridge networking devices. It reflects the device model of the Linux kernel. On a physical device, you can remove the driver that is bound to a it, and potentially bind a different driver. It wouldn't make sense to support this without having a physical device. It's just unfortunate because there is no equivalent method like this, to find the module that implements a virtual device.


Contents:

  1. Example results looking in /sys
  2. I found the module name, now...

1. Example results looking in /sys

$ cd /sys/class/hwmon/
$ ls -l *
total 0
lrwxrwxrwx. 1 root root 0 Dec  2 17:50 hwmon0 -> ../../devices/virtual/thermal/thermal_zone0/hwmon0
lrwxrwxrwx. 1 root root 0 Dec  2 17:50 hwmon1 -> ../../devices/virtual/hwmon/hwmon1
lrwxrwxrwx. 1 root root 0 Dec  2 17:50 hwmon2 -> ../../devices/virtual/thermal/thermal_zone8/hwmon2
lrwxrwxrwx. 1 root root 0 Dec  2 17:50 hwmon3 -> ../../devices/platform/coretemp.0/hwmon/hwmon3

$ ls -l hwmon3/device/driver/module
lrwxrwxrwx. 1 root root 0 Dec  2 18:32 /sys/class/hwmon/hwmon3/device/driver/module -> ../../../../module/coretemp

But the other results did not look so helpful :-). What is virtual/thermal/thermal_zone0/hwmon0?

hwmon devices (and some other types) also have a name. E.g. the iwlwifi sensor, which is really provided by my Intel Wi-Fi card. But the driver is buggy and declared it as a virtual device.

$ head */name
==> hwmon0/name <==
acpitz

==> hwmon1/name <==
dell_smm

==> hwmon2/name <==
iwlwifi

==> hwmon3/name <==
coretemp

Here's a different device, where the driver is on the "grandparent":

$ ls -l */device/device/driver
lrwxrwxrwx. 1 root root 0 Dec  2 18:33 /sys/class/hwmon/hwmon0/device/device/driver -> ../../../../bus/acpi/drivers/thermal

Also there is no module for this driver, because this one is built-in to the kernel. You can confirm this if you can find the corresponding option in the kernel build configuration. This is not necessarily named the same as the module though.

$ ls -l */device/device/driver/module
ls: cannot access '*/device/device/driver/module': No such file or directory

$ grep CORETEMP= /boot/config-$(uname -r)
CONFIG_SENSORS_CORETEMP=m
$ grep ACPI_THERMAL= /boot/config-$(uname -r)
CONFIG_ACPI_THERMAL=y

2. I found the module name, now...

You said you're not 100% sure what you've done. If you've found the module name, but you were worried because you can't remember if you installed it from an unknown website, here are some things you could look at.

You can reload a module and check the path your module was reloaded from:

$ modprobe --remove coretemp

$ modprobe -v coretemp
insmod /lib/modules/4.19.4-200.fc28.x86_64/kernel/drivers/hwmon/coretemp.ko.xz

Then you can query your package manager to confirm the module file came from the distribution kernel package. E.g. for RPM:

$ rpm -q --whatprovides /lib/modules/4.19.4-200.fc28.x86_64/kernel/drivers/hwmon/coretemp.ko.xz
kernel-core-4.19.4-200.fc28.x86_64

$ rpm -q --whatprovides /boot/vmlinuz-$(uname -r)
kernel-core-4.19.4-200.fc28.x86_64

Your package manager should also let you verify the installed package files have not been modified.

It's not so simple to confirm where the package came from :-). Usually you look at the package name and guess :-). You can get a list of available packages and where they come from e.g. with dnf info kernel, but I don't think dnf can show the checksum of the RPM file that was installed or of the available RPMs.

  • Thanks... this has also led me to ask another question: unix.stackexchange.com/questions/485548/… – Stonecraft Dec 2 '18 at 20:11
  • It seems I have my work cut out for me :/ – Stonecraft Dec 2 '18 at 21:26
  • @Thoughtcraft did you find a module to tell you what provides the nct6775 sensor device on your system? Please, we're in suspense now :-). Ah, the hwmon devices are just numbered, you might be wondering which hwmon device is the one you wanted, I kind of skipped that step. I edited my answer , I hope this is clearer, and maybe it helps you. – sourcejedi Dec 2 '18 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.