Closed Dazog closed 2 years ago
Thank you for the inputs!
Let me know if you require any more information.
We will have to determine which sensors are present in this board. Can be done either via experimenting with this driver or you can look up outputs from Windows monitoring software (ASUS AiSuite or HWINFO).
I have EC entries for: VRM CPU core Current CPU Core power
in HWinfo64
Thank you! I will add those plus T_Sensor and CPU_OPT fan, which are also on the internal connectors list at the ASUS tech specs page.
@Dazog, I forgot to ask for the DMI board vendor and name strings. Please, # cat /sys/class/dmi/id/board_{vendor,name}
.
Windows stats this:
I can do the command later in linux for you aswell.
Thank you, that will do. Could you test #18 (branch feature/ProArt-X570-CREATOR-WIFI), please?
Appears secure boot blocks the loading of modules.
I use it for windows and do not want to disable it.
I have no way to load the module to test this :(
But the kernel makefile should sign out-of-tree modules as well.
Hi @zeule , I can confirm that the test branch works properly:
# dmidecode -s baseboard-product-name
ProArt X570-CREATOR WIFI
# sensors asusec-isa-0000
asusec-isa-0000
Adapter: ISA adapter
CPU Core: 1.30 V
CPU_Opt: 1577 RPM
Chipset: +58.0°C
CPU: +57.0°C
Motherboard: +35.0°C
T_Sensor: -40.0°C
VRM: +48.0°C
CPU: 81.00 A
Do you think this change will eventually make it into the mainline kernel? That would be awesome :)
I also have a few questions, I apologise if this isn't the right place to ask but I'm having trouble finding out what the various sensors correspond to:
CPU
temperature from the EC is? It's different from Tctl
, Tccd1
and Tccd2
:
# sensors asusec-isa-0000 | grep CPU.*°C; sensors k10temp-pci-00c3
CPU: +62.0°C
k10temp-pci-00c3
Adapter: PCI adapter
Tctl: +73.0°C
Tccd1: +71.0°C
Tccd2: +67.8°C
nct6798-isa-0290
Adapter: ISA adapter
in0: 1.29 V (min = +0.00 V, max = +1.74 V)
in1: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM
in2: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM
in3: 3.31 V (min = +0.00 V, max = +0.00 V) ALARM
in4: 1.70 V (min = +0.00 V, max = +0.00 V) ALARM
in5: 592.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in6: 1.07 V (min = +0.00 V, max = +0.00 V) ALARM
in7: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM
in8: 3.33 V (min = +0.00 V, max = +0.00 V) ALARM
in9: 888.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in10: 40.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in11: 96.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in12: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
in13: 1.31 V (min = +0.00 V, max = +0.00 V) ALARM
in14: 888.00 mV (min = +0.00 V, max = +0.00 V) ALARM
fan1: 1269 RPM (min = 0 RPM)
fan2: 856 RPM (min = 0 RPM)
fan3: 1544 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 1252 RPM (min = 0 RPM)
fan6: 1781 RPM (min = 0 RPM)
fan7: 937 RPM (min = 0 RPM)
SYSTIN: +35.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
CPUTIN: +51.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +22.0°C sensor = thermistor
AUXTIN1: +127.0°C sensor = thermistor
AUXTIN2: +100.0°C sensor = thermistor
AUXTIN3: +32.0°C sensor = thermistor
PECI Agent 0 Calibration: +57.5°C
PCH_CHIP_CPU_MAX_TEMP: +0.0°C
PCH_CHIP_TEMP: +0.0°C
PCH_CPU_TEMP: +0.0°C
intrusion0: OK
intrusion1: ALARM
beep_enable: disabled
Also I'm a bit confused by this statement from the README (also mentioned in https://github.com/torvalds/linux/commit/b87611d43757c131e5f272b42f0561faed52029e):
The EC registers do not provide critical values for the sensors and as such they are not published to the HWMON.
And yet:
# cat /sys/class/hwmon/hwmon4/name
asusec
Doesn't it mean that the data is published to the HWMON? Or is there a subtlety which I don't understand?
… I can confirm that the test branch works properly:
Thank you!
Do you think this change will eventually make it into the mainline kernel? That would be awesome :)
Yes, I will submit it, thanks to your test.
- do you know what the
CPU
temperature from the EC is? It's different fromTctl
,Tccd1
andTccd2
:
ASUS AiSuite calls it "CPU Package", as far as I remember.
- is there a way to find what the values returned by the Super-I/O chip correspond to? e.g.
Theoretically you can decompile your BIOS and find labels there... The only other way is to compare with another software which already knows that. Most of them are Windows application though.
Also I'm a bit confused by this statement from the README…
The EC chip, unlike the Super-I/O one, does not provide critical values (min, max, hyst, etc.).
Mainlined.
Hi @zeule, I believe you forgot to add the mutex path for this board: https://github.com/torvalds/linux/commit/de8fbac5e59e239b00cdac611784b1bc1ff53d14#diff-637d49de94a4f7fc8228b8fa6dddaac36c7bf4869e219296df524d2fe7000fcaR189-L182 It prevents the module from loading:
asus-ec-sensors asus-ec-sensors: Hardware access guard mutex name is empty
asus-ec-sensors asus-ec-sensors: Failed to setup state/EC locking: -22
asus-ec-sensors: probe of asus-ec-sensors failed with error -22
The following fixes it, as it uses the same mutex path as other boards:
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index a901e4e33d81..b4d65916b3c0 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -299,6 +299,7 @@ static const struct ec_board_info board_info_pro_art_x570_creator_wifi = {
.sensors = SENSOR_SET_TEMP_CHIPSET_CPU_MB | SENSOR_TEMP_VRM |
SENSOR_TEMP_T_SENSOR | SENSOR_FAN_CPU_OPT |
SENSOR_CURR_CPU | SENSOR_IN_CPU_CORE,
+ .mutex_path = ASUS_HW_ACCESS_MUTEX_ASMX,
.family = family_amd_500_series,
};
Thank you, the fix was applied and submitted upstream.
Model: ProArt-X570-CREATOR-WIFI Creator.zip
Attached is the .dat and .dsl
Let me know if you require any more information.