Ryzen/Threadripper 溫度感測器:哪些感測器與哪些核心模組相關以及如何啟用它們
我可以在 Linux 下的華擎 x399 Taichi 主機板上的 AMD Threadripper 1950x 上監控哪些感測器。去年宣布溫度監控適用於 Ryzen 處理器,據推測包含在 4.15 核心中,據此:https ://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-Temps -Hwmon-下一個。但是,似乎溫度是偏移的,這是在核心 4.18.6 中根據以下內容修復的:https ://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18.6-k10temp-Correct
據我所知,在 Linux 下絕對沒有關於 Windows 下的每核溫度監控的說法。
但是,其他消息來源表明我可能需要專門基於我的主機板建構模組。這些說明似乎表明我可以根據感測器檢測的輸出建構適當的核心驅動程序:https ://linuxconfig.org/monitor-amd-ryzen-temperatures-in-linux-with-latest-kernel-modules
根據感測器檢測我有 nct6775,但我找不到任何跡象表明我有適當的核心模組(沒有用 lsmod 顯示,還有其他地方我應該看嗎?)。不幸的是,我無法從儲存庫建構,因為它不再在 github 上。
所以這些是我的問題:
- 哪些驅動程序和核心模組提供哪些資訊?具體來說,哪些給出了 Windows 下可用的每個核心讀數?
- linux下銳龍溫度驅動的現狀如何:完整、不完整、被破解、永遠不可靠?
- 如果我能得到 nct6775,除了我已經擁有的 K10 之外,它還能給我什麼?我還能從哪裡獲得建構它們的原始碼?
- 為什麼這方面的記錄如此糟糕?在課程發布標準桿後一年半沒有關於此的明確資訊,按照行業標準,AMD 是否異常無益?
$$ deleted answer by OP: $$我仍然想知道:究竟是什麼讓 nct6775 現在可用?
在以下連結中回答一般問題有很多嘗試。不幸的是,它們都不是全面的,所以我會嘗試改進它們。 Linux:如何找到用於設備的設備驅動程序?
在您的情況下,感測器設備可以作為中所示的連結之一找到
ls -l /sys/class/hwmon/*
。您可以嘗試擴展該命令,並立即找到您的核心模組:ls -l /sys/class/hwmon/*/device/driver/module
然而,這個命令做了一些假設。它不會在所有情況下都有效。如果命令不起作用,請通過檢查鏈中的每個單獨連結來縮小範圍。有三種可能的情況。
- 你有
driver
連結,但沒有module
連結。這意味著驅動程序內置在核心中!這會回答你的問題:-)。
它同樣可以
ls -l
在driver
連結上。即查看驅動程序的名稱,更改上述命令以刪除該/module
部分。通常驅動程序名稱與可載入模組的名稱相同,但有時它們不同。 2.driver
連結不在下面,但是device
…如果上述命令不起作用,您可能需要替換
device
為device/device
,等等。該
device
連結會將您帶到父設備。但有時驅動程序在祖父母設備上,甚至更遠:-)。 3. 沒有一個父級device
有driver
連結,或者根本沒有父級device
連結。該
device
連結會將您帶到父設備。例如,您可能有一個網路設備/sys/class/wlan0
,並且/sys/class/wlan0/device
可能指向一個提供wlan0
.
pci
在您的情況下,我可以想像它在標準匯流排上沒有類似設備的東西。在這種情況下,驅動程序應該定義自己的自定義設備,在/sys/devices/platform/
. 這正是coretemp
我的英特爾 CPU 驅動程序所做的。但是如果你的驅動程序弄錯了,它會創建一個沒有父設備的設備,因此沒有
device
連結。感測器(hwmon
設備)是比較晦澀的子設備之一;我以前見過這種情況發生好幾次。往裡看ls /sys/devices/virtual/*
,我似乎有三個設備出錯了,而且都是hwmon
設備。如果沒有“物理”/父母
device
- 那麼就沒有driver
. 這是真正虛擬設備的預期行為,例如環回 (lo
) 或bridge
網路設備。它反映了 Linux 核心的設備模型。在物理設備上,您可以刪除綁定到它的驅動程序,並可能綁定不同的驅動程序。在沒有物理設備的情況下支持這一點是沒有意義的。不幸的是,沒有像這樣的等效方法來找到實現虛擬設備的模組。內容:
查看 /sys 的範例結果
我找到了模組名稱,現在…
在 /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
但是其他結果看起來沒有那麼有用:-)。是什麼
virtual/thermal/thermal_zone0/hwmon0
?
hwmon
設備(和一些其他類型)也有一個name
. 例如iwlwifi
感測器,它實際上是由我的英特爾 Wi-Fi 卡提供的。但是驅動程序有問題並將其聲明為虛擬設備。$ head */name ==> hwmon0/name <== acpitz ==> hwmon1/name <== dell_smm ==> hwmon2/name <== iwlwifi ==> hwmon3/name <== coretemp
這是一個不同的設備,其中驅動程序位於“祖父母”上:
$ 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
這個驅動也沒有模組,因為這個是核心內置的。如果您可以在核心建構配置中找到相應的選項,您可以確認這一點。但是,這不一定與模組命名相同。
$ 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.我找到了模組名稱,現在…
你說你不是100%確定你做了什麼。如果您找到了模組名稱,但您擔心因為您不記得是否從未知網站安裝了它,那麼您可以查看以下內容。
您可以重新載入模組並檢查重新載入模組的路徑:
$ modprobe --remove coretemp $ modprobe -v coretemp insmod /lib/modules/4.19.4-200.fc28.x86_64/kernel/drivers/hwmon/coretemp.ko.xz
然後您可以查詢您的包管理器以確認模組文件來自分發核心包。例如對於 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
您的包管理器還應該讓您驗證已安裝的封包件沒有被修改。
確認包裹的來源並不是那麼簡單:-)。通常你會查看包名並猜測:-)。您可以獲得可用軟體包的列表以及它們的來源,例如使用
dnf info kernel
,但我認為 dnf 不能顯示已安裝的 RPM 文件或可用 RPM 的校驗和。