Sensores de temperatura Ryzen/Threadripper: quais sensores estão relacionados a quais módulos do kernel e como habilitá-los

[resposta excluída pelo OP:] Eu ainda gostaria de saber: o que exatamente está disponibilizando o nct6775 agora?

Há muitas tentativas de responder à pergunta geral no link a seguir. Infelizmente, nenhum deles é abrangente, então tentarei melhorá-los. Linux: Como encontrar o driver de dispositivo usado para um dispositivo?

No seu caso, o dispositivo sensor pode ser encontrado em um dos links mostrados em ls -l /sys/class/hwmon/*. Você pode tentar estender esse comando e encontrar seu módulo do kernel imediatamente:

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

No entanto, este comando faz algumas suposições. Não funcionará em todos os casos. Se o comando não funcionar, reduza-o verificando cada elo individual na cadeia. Há três casos possíveis.

1. Você tem um driverlink, mas nenhum modulelink.

   Isso significa que o driver está embutido no kernel! O que meio que responderia à sua pergunta :-).

   É igualmente possível ls -lno driverlink. Ou seja, para ver o nome do driver, altere o comando acima para remover a /modulepeça. Muitas vezes, o nome do driver é o mesmo que o nome do módulo carregável, mas às vezes eles são diferentes.

2. O driverlink não está imediatamente abaixo devicede , mas ...

   Se o comando acima não funcionar, talvez seja necessário substituir devicepor device/device, ou assim por diante.

   O devicelink leva você ao dispositivo pai. Mas às vezes o driver está no dispositivo do avô, ou ainda mais :-).

3. Nenhum dos pais devicetem um driverlink ou não há nenhum devicelink pai.

   O devicelink leva você ao dispositivo pai. Por exemplo, você pode ter um dispositivo de rede /sys/class/wlan0e /sys/class/wlan0/devicepode apontar para uma placa PCI que fornece wlan0.

   No seu caso, posso imaginar não ter nada parecido com um dispositivo no pcibarramento padrão. Nesse caso, o driver deve definir seu próprio dispositivo personalizado, em /sys/devices/platform/. Isso é exatamente o que o coretempdriver da minha CPU Intel faz.

   Mas se o seu driver errar, ele criará um dispositivo sem pai e, portanto, sem devicelink. Sensores ( hwmondispositivos) são um dos dispositivos filhos mais obscuros; Já vi isso acontecer várias vezes antes. Olhando em ls /sys/devices/virtual/*, parece que tenho três dispositivos que erram, e todos eles são hwmondispositivos.

   Se não houver "físico" / pai device- então não pode haver driver. Esse é o comportamento esperado para dispositivos genuinamente virtuais, como loopback ( lo) ou bridgedispositivos de rede. Ele reflete o modelo de dispositivo do kernel Linux. Em um dispositivo físico, você pode remover o driver que está vinculado a ele e potencialmente vincular um driver diferente. Não faria sentido oferecer suporte a isso sem ter um dispositivo físico. É lamentável porque não existe um método equivalente como este, para encontrar o módulo que implementa um dispositivo virtual.

Conteúdo:

1. Resultados de exemplo procurando em /sys
2. Encontrei o nome do módulo, agora...

1. Exemplo de resultados procurando em /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

Mas os outros resultados não parecem tão úteis :-). O que é virtual/thermal/thermal_zone0/hwmon0?

hwmondispositivos (e alguns outros tipos) também têm um arquivo name. Por exemplo, o iwlwifisensor, que é realmente fornecido pela minha placa Intel Wi-Fi. Mas o driver está com bugs e o declarou como um dispositivo virtual.

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

==> hwmon1/name <==
dell_smm

==> hwmon2/name <==
iwlwifi

==> hwmon3/name <==
coretemp

Aqui está um dispositivo diferente, onde o driver está no "avô":

$ 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

Também não há módulo para este driver, porque este está embutido no kernel. Você pode confirmar isso se encontrar a opção correspondente na configuração de compilação do kernel. Isso não é necessariamente nomeado da mesma forma que o módulo.

$ 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. Encontrei o nome do módulo, agora...

Você disse que não tem 100% de certeza do que fez. Se você encontrou o nome do módulo, mas ficou preocupado porque não se lembra se o instalou de um site desconhecido, aqui estão algumas coisas que você pode ver.

Você pode recarregar um módulo e verificar o caminho de onde seu módulo foi recarregado:

$ modprobe --remove coretemp

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

Então você pode consultar seu gerenciador de pacotes para confirmar se o arquivo do módulo veio do pacote do kernel de distribuição. Por exemplo, para 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

Seu gerenciador de pacotes também deve permitir que você verifique se os arquivos do pacote instalado não foram modificados.

Não é tão simples confirmar de onde veio o pacote :-). Normalmente você olha para o nome do pacote e adivinha :-). Você pode obter uma lista de pacotes disponíveis e de onde eles vêm, por exemplo, com dnf info kernel, mas não acho que o dnf possa mostrar a soma de verificação do arquivo RPM que foi instalado ou dos RPMs disponíveis.