Bug 204807
|
Description
Artem S. Tashkinov
2019-09-10 18:51:27 UTC
Even with acpi_enforce_resources=lax I'm getting these messages on boot: nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20190509/utaddress-204) ACPI: This conflict may cause random problems and system instability ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Same for in 5.4.6 on a Asus Z170-WS (BIOS 3602 05/24/2019). dmesg says, nct6775: Found NCT6793D or compatible chip at 0x2e:0x290 ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20190816/utaddress-204) Any updates on this one, Rui Zhang? It's great you've specified HW but it surely looks like no one really cares. Please attach the acpidump output. Well, TBH, it is probably that there is no way to fix this. The root cause is that ACPI claims some resources that will possibly be used by the ACPI AML code, but the native nct6775 driver also requests the same piece of resource. Created attachment 289943 [details] acpidump -b (In reply to Zhang Rui from comment #4) > Please attach the acpidump output. > > Well, TBH, it is probably that there is no way to fix this. > The root cause is that ACPI claims some resources that will possibly be used > by the ACPI AML code, but the native nct6775 driver also requests the same > piece of resource. This doesn't seem right because Windows just works and doesn't require any hacks to be 100% functional on this PC. 99% of users will never know how to enable this option and will have a malfunctioning sensor. Created attachment 292207 [details]
acpidump -b
Same issue with linux-next-git (5.9-rc2ish at the moment) on ASUS TUF B550M motherboard.
Same issue on latest ubuntu 20.04.1 LTS with an ASUS Prime X570-P, flashed at BIOS v2606. (In reply to Zhang Rui from comment #4) > Please attach the acpidump output. > > Well, TBH, it is probably that there is no way to fix this. > The root cause is that ACPI claims some resources that will possibly be used > by the ACPI AML code, but the native nct6775 driver also requests the same > piece of resource. From what I can see pretty much all recent AMD chipset motherboards users are affected. This sounds like something which must be fixed because we are talking about a very broad use case. Created attachment 292371 [details]
acpidump -b
dump from my system ASUS Prime X570-P Bios v2606
Same issue on 5.8.13 on Gigabyte B550M DS3H. out 07 07:09:44 d3.localdomain kernel: it87: Found IT8628E chip at 0xa40, revision 1 out 07 07:09:44 d3.localdomain kernel: it87: Beeping is supported out 07 07:09:44 d3.localdomain kernel: ACPI Warning: SystemIO range 0x0000000000000A45-0x0000000000000A46 conflicts with OpRegion 0x0000000000000A45-0x0000000000000A46 (\GSA1.SIO1) (20200528/utaddress-204) out 07 07:09:44 d3.localdomain kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver out 07 07:09:44 d3.localdomain kernel: fuse: init (API version 7.31) out 07 07:09:44 d3.localdomain systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE out 07 07:09:44 d3.localdomain systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. out 07 07:09:44 d3.localdomain systemd[1]: Failed to start Load Kernel Modules. out 07 07:09:44 d3.localdomain kernel: audit: type=1130 audit(1602065384.576:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-modules-load comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Created attachment 292911 [details]
acpidump -b
Same issue on ASUS TUF Z390M-PRO GAMING BIOS v2808
nct6775: Enabling hardware monitor logical device mappings.
nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20200528/utaddress-204)
Created attachment 293593 [details]
acpidump -b for 5.9.6 and Asus X570-Plus TUF Gaming
I have the same problem with 5.9.6 kernel and Asus X570-Plus TUF Gaming motherboard.
for all the people in this thread that reports the same problem, please attach the full dmesg output after boot. Created attachment 293727 [details]
Dmesg after booting kernel 5.9.8 on Asus B550M TUF
Created attachment 293751 [details]
dmesg after boot 5.9.8 Asus TUF Gaming X570-PLUS
Created attachment 293755 [details]
dmesg after boot ASUS PRIME X570-P
dmesg after boot ASUS PRIME X570-P
Created attachment 293757 [details]
sensors not working acpi conflict
Sensors not working with chip Nuvoton NCT6798D on Asus Primer X570-PRO
because of ACPI conflict: ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion
Also affected on ASUS Prime B460-Plus motherboard w v1403 BIOS. Created attachment 293819 [details]
ASUS Prime B460 Plus dmesg
dmesg of ASUSM Prime B460 Plus booting
Same with Nuvoton NCT6798D on Asus TUF Gaming X570 PRO and Kernel 5.10.2-2-MANJARO Created attachment 294703 [details]
dmesg ASUS X570 TUF Gaming Pro
Created attachment 294705 [details]
acpicump -p ASUS X570 TUF Gaming Pro
Same issue on : DMI: ASUS System Product Name/ROG CROSSHAIR VIII IMPACT, BIOS 3204 01/25/2021 ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20200925/utaddress-204) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Created attachment 295261 [details]
dmesg for ASUS ROG CROSSHAIR VIII IMPACT with BIOS : 3204
Created attachment 295263 [details]
acpidump for ASUS ROG CROSSHAIR VIII IMPACT with BIOS : 3204
Created attachment 295403 [details]
Dmesg for Asus B550M-plus WIFI
I have "acpi_enforce_resources=lax" in kernel line but still have the conflict problem.
Probably not related but rest of the parameters: add_efi_memmap initrd=\amd-ucode.img mitigations=off video=current iommu=pt
Created attachment 295417 [details]
dmesg for Asus ROG STRIX Z490-I
dmesg for Asus ROG STRIX Z490-I. BIOS 11/30/2020 v1003
[ 3.194752] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[ 3.194756] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20200528/utaddress-204)
[ 3.194759] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Same also on Asus Prime H310I-Plus Ubuntu 20.04.2 LTS Kernel: 5.4.0-66-generic acpi_enforce_resources=lax enabled dmesg: [ 4.083054] nct6775: Found NCT6796D or compatible chip at 0x2e:0x290 [ 4.083058] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20190816/utaddress-204) [ 4.083063] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Created attachment 295835 [details]
dmesg after boot ASUS PRIME X570-P bios 3602
ASUS PRIME X570-P after flashing newest bios 3602.
Created attachment 295837 [details]
acpidump ASUS PRIME X570-P bios 3602
ACPI Dump ASUS PRIME X570-P BIOS 3602
I checked the dmesg and acpidump from Jaap,
[ 3.497957] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[ 3.497963] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20200528/utaddress-204)
[ 3.497969] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Device (AMW0)
{
Name (_HID, EisaId ("PNP0C14") /* Windows Management Instrumentation Device */) // _HID: Hardware ID
Name (_UID, "ASUSWMI") // _UID: Unique ID
...
So the resource conflict happens between native nct6775 driver and the ACPI asus_wmi driver.
My understanding is that asus_wmi/asus_nb_wmi do the same thing as nct6775 and expose them to hwmon class as well. If this is true, we can simply ignore these warning messages because "Yes, there is an ACPI driver is available for this device. And yes, we can use asus hwmon I/F instead of the native driver"
But this is just my guess. Need Hans to confirm on this.
For the other reporters in this thread, please
1. make sure your kernel is built with CONFIG_ASUS_WMI and CONFIG_ASUS_NB_WMI
2. attach the output of "sensors" command
because we should be able to see "asus" sensor in the output, provides similar functionality as nct6775 driver does.
Reassign to platform driver category. This isn't a bug - the ACPI tables claim the resource in question, and there's no way we can verify there are no conflicts between ACPI methods that touch that range and the native driver. If you're confident that this is safe on your system then you can boot with acpi_enforce_resources=lax, but we can't make that the default. This will still produce the warning, but the driver will be permitted to load. (In reply to Matthew Garrett from comment #33) > This isn't a bug - the ACPI tables claim the resource in question, and > there's no way we can verify there are no conflicts between ACPI methods > that touch that range and the native driver. If you're confident that this > is safe on your system then you can boot with acpi_enforce_resources=lax, > but we can't make that the default. This will still produce the warning, but > the driver will be permitted to load. This bug needs to be fixed because 1) It doesn't affect Windows 2) Average people will never know how to deal with issue 3) I cannot ask my motherboard vendor (ASUS) to fix this issue in BIOS because they don't provide support for Linux - they barely provide any support at all. OoB experience of Linux users should not be "I don't get any sensors output, how to fix that?" Most users don't even know what and how to Google. They don't know about dmesg either. That's an effing horrible attitude. I'm CC'ing Linus because I absolutely hate what's going on. This might not be a classic "bug" but **no one on Earth cares**. What people care about is having their systems work and be supported by Linux out of the box with **no cryptic voodoo applied**. You don't ask Windows users to run bcdedit.exe to fix their hardware, do you? So, why do Linux users have to edit system configuration files to get at least comparable experience? Don't get me started that HWiNFO64 shows up to ten times more hardware sensors and their parameters than lm-sensors. Lastly, this problem affects literally hundreds of thousands of systems. It's not some single broken motherboard or broken EFI, we're talking about multiple classes of hardware. Here's the situation. Your ACPI tables declare that your system firmware may access the addresses associated with your IO sensors. We have no idea what your firmware may do here - it may do nothing (in which case accessing the addresses is completely safe), or it may use them for its own internal monitoring. Sensor hardware frequently uses indexed addressing, which means that accessing a sensor requires something like the following: 1) Write the desired sensor to the index register 2) Read the sensor value from the data register These can't occur simultaneously, so if both the OS and the firmware are accessing it you risk ending up with something like: 1) Write sensor A to the index register (from the OS) 2) Write sensor B to the index register (from the firmware) 3) Read the sensor value from the data register (returns the value of sensor B to the firmware) 4) Read the sensor value from the data register (returns the value of sensor B to the OS) The OS asked for the value of sensor A, but received the value of sensor B. From the OS side this is probably not a big deal (you get a weird value in your graphing), but if it happens the other way around the firmware may decide that the system is running out of spec and shut it down to avoid damage. This is not a good user experience. Why does Windows not have the same problem? Well, in the general case there's nothing stopping it from doing so. Vendor tooling usually takes one of two approaches: 1) They don't use the hardware sensors directly, they use firmware interfaces to them. This is alluded to in comment #31 - on Asus systems, the sensors are available via a WMI interface. Using a firmware interface ensures that the firmware knows what the state of the hardware is, and avoids any race conditions. Your board may well support an alternative firmware interface and Linux simply lacks driver support for it. If so, I'm afraid that the correct solution is to add that driver support. Given that this bug has ended up covering boards from multiple vendors, it's no longer the correct place to handle that, though. 2) The vendor knows that the firmware makes no policy decisions based on the sensor values, so it's safe to access the resources even though the firmware declares that it uses them. The problem with this approach is that *we* have no way of knowing that it's safe, and the consequences of it being unsafe include data loss. Given the choice between users being able to look at system temperatures and users not losing data, we choose to prioritise users not losing data. Looking at your ACPI tables, we see the following: Name (IOHW, 0x0290) OperationRegion (SHWM, SystemIO, IOHW, 0x0A) Field (SHWM, ByteAcc, NoLock, Preserve) { Offset (0x05), HIDX, 8, HDAT, 8 } This means that there's a region of IO ports starting at address 0x290 and 0x0a addresses long. This is the same region of port IO that your sensor chip uses. Within that address range, we declare that 0x295 is called HIDX, and 0x296 is called HDAT. This is consistent with an index and data register as described above, which means that having the OS access this space directly is likely to race with the firmware (ie, it's dangerous). Near here are two methods called RHWM and WHWM. At a guess, that's "Read Hardware Monitoring" and "Write Hardware Monitoring". These not only access the sensors via the registers described above, they do some additional hardware access around it. This is further evidence to support there being some handshaking involved to avoid race conditions - the firmware takes a mutex and appears to hit some other register that may also be used to guard against racing against system management mode. We really, *really* want to be using the firmware methods here rather than touching the sensor chip directly. At this point, direct access isn't so much walking past a sign saying "Danger, keep out", it's a sign saying "Proceed no further or you will die slowly and it will hurt the entire time". RHWM is referenced from the WMBD method if the first argument to it is RHWM, and WHWM is referenced if the argument is WHWM. WMBD is the WMI dispatcher for the WMI function with identifier "BD" - looking at your _WDG object, which describes the available WMI interfaces, we have the following: Name (_WDG, Buffer (0x50) { /* 0000 */ 0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11, // .^..mN.. /* 0008 */ 0x8A, 0x39, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66, // .9.. ..f /* 0010 */ 0x42, 0x43, 0x01, 0x02, 0xA0, 0x47, 0x67, 0x46, // BC...GgF /* 0018 */ 0xEC, 0x70, 0xDE, 0x11, 0x8A, 0x39, 0x08, 0x00, // .p...9.. /* 0020 */ 0x20, 0x0C, 0x9A, 0x66, 0x42, 0x44, 0x01, 0x02, // ..fBD.. /* 0028 */ 0x72, 0x0F, 0xBC, 0xAB, 0xA1, 0x8E, 0xD1, 0x11, // r....... /* 0030 */ 0x00, 0xA0, 0xC9, 0x06, 0x29, 0x10, 0x00, 0x00, // ....)... /* 0038 */ 0xD2, 0x00, 0x01, 0x08, 0x21, 0x12, 0x90, 0x05, // ....!... /* 0040 */ 0x66, 0xD5, 0xD1, 0x11, 0xB2, 0xF0, 0x00, 0xA0, // f....... /* 0048 */ 0xC9, 0x06, 0x29, 0x10, 0x4D, 0x4F, 0x01, 0x00 // ..).MO.. }) The format of _WDG is 16 bytes of GUID, 2 bytes of ID or notification data, 1 byte of instance count and 1 byte of flags. The GUID used by asus-wmi corresponds to the first GUID in this file, 97845ED0-4E6D-11DE-8A39-0800200C9A66. That has an ID of 0x4243, or BC - ie, it's not the GUID we're looking for. The next GUID, however, (466747a0-70ec-11de-8a39-0800200c9a66) has an identifier of 0x4344, or BD. So this is the GUID we're looking for. Unfortunately asus-wmi doesn't handle this GUID, so new code will need to be written. I'm going to close this bug again because it's turned into a generic bug covering different motherboard vendors, and there's no one size fits all solution. For your case the correct way to handle it is for someone to write a driver that uses the 466747a0-70ec-11de-8a39-0800200c9a66 interface to expose the sensor data. I'm afraid I don't have relevant hardware so can't do this myself, but please do open another bug for that. tl;dr - the kernel message you're seeing is correct. Avoiding it requires a new driver to be written. If you *personally* feel safe in ignoring the risks, you can pass the acpi_enforce_resources=lax option, but that can't be the default because it's unsafe in the general case, and so it isn't the solution to the wider problem. CONFIG_ASUS_WMI=m andI confirmed the module is loaded. I think I saw some improvements lastly in the support of temperature sensors, I am not so sure because I have no traces of the old state and it's a long time ago I used the UI. I flashed my BIOS recently and hoped things would be solved with that action. Thanks a lot Matthew for this good explanation and for the first time I understood (at abstract level) what is going on and why it is so. This explanation is something really valuable to be kept and put in a prominent place like kernel Documentation and a known issues text file (then a less asus specific explanation) IMO. I was nearly as desperate to try to use the `acpi_enforce_resources=lax` setting but without understanding it is for me as an engineer something "hot" and now I really get why it is so, I will for my part keep my fingers away from the setting and hope that someone will find out how to get the FAN values in the normal driver. Many thanks for the clarification. As noted in https://twitter.com/james_hilliard/status/1373178256615211012, there's actually a driver here: https://github.com/electrified/asus-wmi-sensors/ . I did a quick search earlier, but managed to miss this somehow. Are you sure about that driver? The github page says: "Note: X570/B550/TRX40 boards do not have the WMI interface and are not supported." And those seems to be the chipsets of all or almost all boards reported in this bug. 20 mar. 2021 8:51:07 bugzilla-daemon@bugzilla.kernel.org: > https://bugzilla.kernel.org/show_bug.cgi?id=204807 > > --- Comment #39 from Matthew Garrett (mjg59-kernel@srcf.ucam.org) --- > As noted in https://twitter.com/james_hilliard/status/1373178256615211012, > there's actually a driver here: > https://github.com/electrified/asus-wmi-sensors/ . I did a quick search > earlier, but managed to miss this somehow. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug. Interesting, it looks like it uses the same GUID but has a different set of methods. So yes, this driver probably won't work for a bunch of the boards here - it would need to be adapted to add support for the methods that these ones provide. (In reply to Matthew Garrett from comment #37) > 97845ED0-4E6D-11DE-8A39-0800200C9A66. That has an ID of 0x4243, or BC - ie, > it's not the GUID we're looking for. The next GUID, however, > (466747a0-70ec-11de-8a39-0800200c9a66) has an identifier of 0x4344, or BD. > So this is the GUID we're looking for. Unfortunately asus-wmi doesn't handle > this GUID, so new code will need to be written. > > I'm going to close this bug again because it's turned into a generic bug > covering different motherboard vendors, and there's no one size fits all > solution. For your case the correct way to handle it is for someone to write > a driver that uses the 466747a0-70ec-11de-8a39-0800200c9a66 interface to > expose the sensor data. I'm afraid I don't have relevant hardware so can't > do this myself, but please do open another bug for that. > > tl;dr - the kernel message you're seeing is correct. Avoiding it requires a > new driver to be written. If you *personally* feel safe in ignoring the > risks, you can pass the acpi_enforce_resources=lax option, but that can't be > the default because it's unsafe in the general case, and so it isn't the > solution to the wider problem. That's the problem: we have _multiple_ motherboards with _multiple_ different chipsets from _different_ vendors 1) all having the same glitch 2) all requiring the same workaround 3) working just fine under Windows with no hacks > My understanding is that asus_wmi/asus_nb_wmi do the same thing as nct6775 > and expose them to hwmon class as well. And at the same time you're talking about asus_wmi which covers only _certain_ ASUS motherboards, and no one in this discussion has shown it to work or provide the same set of sensors. And this driver has nothing to do with sensors, linux/drivers/platform/x86/asus-wmi.c: * Asus PC WMI hotkey driver This is not a driver which even tangentially deals with HW sensors found in motherboards affected by this bug. I don't know why you're trying to sweep this bug under the rug but I really dislike it. The Linux kernel development has always followed common sense principles and it contains a _huge_ number of workarounds just to enable HW which doesn't work according to specs. At the very least you could printk() this: "Your motherboard might not exposing ACPI resources correctly, so you might not get access to your HW sensors. You could add "acpi_enforce_resources=lax" to kernel boot parameters to enable monitoring at your own risk. Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information". And this still paints Linux in a very bad light as users hardly care about if ACPI is implemented according to the specifications or not: however what they really care is whether their hardware works or being supported under Linux regardless out of the box. Most Linux users don't even know `dmesg` exists, so they have no way of knowing how to fix the issue. Lastly, this bug is not fixed. A small correction of my previous comment: linux/drivers/platform/x86/asus-nb-wmi.c /* * Asus Notebooks WMI hotkey driver * * Copyright(C) 2010 Corentin Chary <corentin.chary@gmail.com> */ This is not related to lm-sensors in any shape or form. I'm really sad how this situation is getting handled: the bug has been known for over 1.5 years, affects literally hundreds of thousands devices and you're saying that this kernel option might have unintended consequences yet _everyone_ in this thread has enabled it with _zero_ side affects and Windows seemingly has it enabled by default, as no such messages are getting logged in Windows Event Log either when using HWiNFO64 or vendor specific monitoring software. (In reply to Artem S. Tashkinov from comment #42) > "Your motherboard might not be exposing ACPI resources correctly, so you > might > not get access to your HW sensors. You could add > "acpi_enforce_resources=lax" to kernel boot parameters to enable monitoring > at your own risk. Please refer to > https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information". This message will at least allow various Linux distros to enable the option by default because many are not aware of the bug. Artem, Nobody is denying there's an issue here. However, the issue is that an additional driver needs to be written for this hardware. Please file a new bug for that and do not keep reopening this one. (In reply to Artem S. Tashkinov from comment #43) > A small correction of my previous comment: > > linux/drivers/platform/x86/asus-nb-wmi.c > > /* > * Asus Notebooks WMI hotkey driver > * > * Copyright(C) 2010 Corentin Chary <corentin.chary@gmail.com> > */ > > This is not related to lm-sensors in any shape or form. asus_nb_wmi_init -> asus_wmi_register_driver -> asus_wmi_probe -> asus_wmi_add -> asus_wmi_hwmon_init Although the warning messages are printed by ACPI code, but this is a conflict between the native nct6775 driver and the Asus wmi driver, because Asus wmi driver accesses the same piece of resources and provide similar functionalities. And I'm familiar with neither of them. > I'm really sad how > this situation is getting handled: the bug has been known for over 1.5 > years, affects literally hundreds of thousands devices and you're saying > that this kernel option might have unintended consequences yet _everyone_ in > this thread has enabled it with _zero_ side affects and Windows seemingly > has it enabled by default, as no such messages are getting logged in Windows > Event Log either when using HWiNFO64 or vendor specific monitoring software. In Linux, at least for now, I don't see a way to enable native nct6775 driver by default, and, this is true for all the native drivers that have resource conflict with the firmware. IMO, the rootcause is that Linux does not support override driver A (native driver in this case) when driver B (driver that talks to firmware) is loaded, so we have to disable driver A even if there is only 0.01% possibility that driver B will be loaded when we know there might be a conflict. what we can do is to write driver B to make this statement true "ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver" and ignore this message. (In reply to Artem S. Tashkinov from comment #44) > (In reply to Artem S. Tashkinov from comment #42) > > "Your motherboard might not be exposing ACPI resources correctly, so you > > might > > not get access to your HW sensors. You could add > > "acpi_enforce_resources=lax" to kernel boot parameters to enable monitoring > > at your own risk. Please refer to > > https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information". > > This message will at least allow various Linux distros to enable the option > by default because many are not aware of the bug. Hmmm, what about following conditions 1. "acpi_enforce_resources=" is a global switch, there might be platforms with more than one conflict, or with another conflict rather than nct6775. we can not validate all of them. 2. we may have new drivers that talk with firmware later, and we can not use "acpi_enforce_resources=lax" then. But thanks for raising this up, I think this also rings a bell that the current message is kind of misleading. It is true that ACPI covers a series of devices as described in the ACPI spec. But at the same time, ACPI is an interface. Many drivers, including vendor specific drivers, talks with firmware through the ACPI Interface. They depends on ACPI, but they're actually not covered by the ACPI specification, nor by kernel drivers/acpi code. "ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver" makes people feel like it is an ACPI problem, but in many cases, it is not, I can only triage them. So if someone is willing to spend time on making this work, then here is how I believe this could be made to work (for the case which Matthew Garrett analysed): 1. Modify the nct6775 driver, adding a set of nct6775_register_ops to the nct6775_sio_data struct and have any function which sits "below" the probe() function only use these ops to do register accesses. Combined with having sensors_nct6775_init() set these register-ops to the currently used superio register access functions (so that nothing changes for existing users of the driver). 2. Move the nct6775_sio_data struct declaration to a shared header somewhere under include/linux 3. Have a new WMI driver which defines register-ops compatible with the ones expected by the nct6775_sio_data struct, using the RHWM and WHWM methods which Matthew found (note these should be called through their WMI wrappers) and have this driver instantiate a platform device, with its platdata set to this new nct6775_sio_data struct, allowing the nct6775 driver to access the registers this way, using the mutual-exclusion mechanism build into the RHWM and WHWM methods. As the drivers/platform/x86 maintainer I would be more then happy to merge a clean driver for step 3. To me this seems quite doable (to someone with some kernel-dev experience + enough time). Note I believe that this will not be a whole lot of work (but its not trivial either). Artem, Matthew gave a really good explanation on techical background what's going on. What you really need is to amend existing driver(s) or provide a new one to fulfill the functionality you want to have. (In reply to Andy Shevchenko from comment #48) > Matthew gave a really good explanation on techical background what's going > on. What you really need is to amend existing driver(s) or provide a new one > to fulfill the functionality you want to have. I'm not a programmer let alone a person who understand the innards of the Linux kernel to even attempt to fix the issue, not to mention that: > Note I believe that this will not be a whole lot of work (but its not trivial > either). Maybe we have ... kernel developers who can do that instead, for instance lm-sensors maintainers. I don't know. I'm confused. I did my best to report the issue. Meanwhile I'll continue to use the hack since I want to monitor my HW right now - not a few years later when someone finally ventures to scratch the itch. Thank you very much ;-) > Maybe we have ... kernel developers who can do that instead
You now kernel developers are humans too, so they need to eat and sleep and stuff too. IOW they don't have unlimited time to spend on helping every Linux user out there without any compensation.
Maybe you have a friend with some kernel-development experience who can help. Or maybe you can find someone who you can pay to fix this for you?
(In reply to Artem S. Tashkinov from comment #49) > (In reply to Andy Shevchenko from comment #48) > > Matthew gave a really good explanation on techical background what's going > > on. What you really need is to amend existing driver(s) or provide a new > one > > to fulfill the functionality you want to have. > > I'm not a programmer let alone a person who understand the innards of the > Linux kernel to even attempt to fix the issue, not to mention that: > > > Note I believe that this will not be a whole lot of work (but its not > trivial > > either). > > Maybe we have ... kernel developers who can do that instead, for instance > lm-sensors maintainers. I don't know. I'm confused. I did my best to report > the issue. Meanwhile I'll continue to use the hack since I want to monitor > my HW right now - not a few years later when someone finally ventures to > scratch the itch. Thank you very much ;-) Artem, I feel your pain. Believe me, I have got into the similar situation(s) myself being actually a kernel developer! I'm often being frustrated, but that's how it works in Linux and in OSS in general. The root cause here is the production model used by world of Windows and world of Linux (and besides the downsides like above I prefer the latter). For Windows the drivers are made for *THE product* while in *nix world the drivers try to cover as many products as they can with regard to the similarities and compatibility of the corresponding IPs. That's why people often see "oh, hey, it works in Windows!" Yes, it works, but if and only if you are using the very same *THE product*. Step right or left will be a suicidal in that model. The Windows model is very fragile because of this and requires 10x times more resources to develop the code. OSS community simply does not have such resources to fulfill a job and due to economical reasons even Micro$oft also found advantages in the OSS model (but not with the drivers, unfortunately). The best help for you and for the rest is to be on the constructive side. You see, you even may yourself to develop a solution and become (a well paid) kernel developer. Or just for fun (look at the example of Intel IPU3 CIO2 camera glue layer (to support Windows only platforms) which is done solely by one guy who declared that he even didn't know C programming language before! So, please, do not blame people here, it's rather the problem of the model. "That's an effing horrible attitude", Artem (#c34). *leaving this rant* I'm also removing myself from the Cc of this bug because the discussion here does not seem to be productive. If anyone wants to implement the solution which I outlined in command 47, drop me an email at hdegoede@redhat.com . Hello, I was doing some preparatory work to implement the solution in comment 47 - like analysis of source code. Unfortunately, it seems like this solution would only work for ASUS boards. All the acpidump outputs in this ticket are from ASUS boards. The "RHWM" and "WHWM" methods are from an interface with UID="ASUSWMI", so they look to be asus-specific. For ASUS boards there exists a better driver: https://github.com/electrified/asus-wmi-sensors so there is probably no reason to implement direct access to nct6775. Are there any benefits from implementing access to nct6775 as outlined above? Greetings, (In reply to Mateusz Jończyk from comment #54) > For ASUS boards there exists a better driver: > > https://github.com/electrified/asus-wmi-sensors Interesting I wonder why that has not been submitted upstream. I'll open an issue at its github page for that. > so there is probably no reason to implement direct access to nct6775. > > Are there any benefits from implementing access to nct6775 as outlined above? No, that was just meant as a possible solution for the reported problem. I agree that using the WMI interface, which presumably is what Asus' Windows tools use, is better. Hmm, asus-wmi-sensors also is not such a great solution, it seems the WMI interface is buggy on some boards and causes fans to stop or get stuck at max speed, which is quite bad, see: https://github.com/electrified/asus-wmi-sensors#known-issues So it seems that the situation with sensors on these boards simply sucks and Asus is to blame here. If even the "official" method of accessing the sensors is buggy then Asus needs to get their firmware fixed and until that is done users are better of without sensors support. (In reply to Hans de Goede from comment #56) > Hmm, > > asus-wmi-sensors also is not such a great solution, it seems the WMI > interface is buggy on some boards and causes fans to stop or get stuck at > max speed, which is quite bad, see: > > https://github.com/electrified/asus-wmi-sensors#known-issues IMHO, this could be caused by access races, not necessarily by a buggy BIOS. The driver may simply not implement correct synchronization methods. It may be necessary to call some ACPI / WMI methods before and after accessing the sensors to avoid resource conflicts. As is written in the documentation: > The more frequently the WMI interface is polled the greater the potential for > this to happen. I am also not sure if the driver implements correct locking behavior kernel-wise. (In reply to Mateusz Jończyk from comment #57) > (In reply to Hans de Goede from comment #56) > > Hmm, > > > > asus-wmi-sensors also is not such a great solution, it seems the WMI > > interface is buggy on some boards and causes fans to stop or get stuck at > > max speed, which is quite bad, see: > > > > https://github.com/electrified/asus-wmi-sensors#known-issues > > IMHO, this could be caused by access races, not necessarily by a buggy BIOS. > The driver may simply not implement correct synchronization methods. It may > be necessary to call some ACPI / WMI methods before and after accessing the > sensors to avoid resource conflicts. Perhaps, but usually WMI methods take the locks which they need on entry and release them on exit. I'm not even sure if an ACPI method (which this ultimately is) can hold locks after it exits, I would not be surprised if all acquired locks are automatically dropped on exit from the interpreter. Also note that the README also states that on some motherboards the problems are fixed in later BIOS versions, which also points to a race inside the AML code and not a bug in the driver. > As is written in the documentation: > > The more frequently the WMI interface is polled the greater the potential > for > > this to happen. > > I am also not sure if the driver implements correct locking behavior > kernel-wise. I did not check, but this should not matter, that may mess up the driver's state, but the WMI code is expected to do its own locking at the AML level, to e.g. protect against similar accesses to the super IO through the ACPI thermal region interface. Note I'm not claiming that this is definitely not an issue with the driver, it could be. But I've seen a lot of very buggy AML code and I've yet to find a single vendor which does not write very low quality AML code. It seems there is absolutely no code-review done on the AML code and very little QA. The Asus X570-Plus TUF Gaming was described in this ticket as not working. It is listed as not supported by this driver on GitHub. So there are some devices without a working WMI interface that would benefit from the handling in comment 47. > I agree that using the WMI interface, which presumably is what Asus' Windows > tools use, is better. It also does not require guessing voltage divider parameters, which makes raw access to nct6775 not that much useful. asus-wmi-sensors was already mentioned in comment #39. I tried it with ASUS PRIME B360-PLUS but no device was matched by the driver. It could have been some user error though. (In reply to Matthew Garrett from comment #39) > As noted in https://twitter.com/james_hilliard/status/1373178256615211012, > there's actually a driver here: > https://github.com/electrified/asus-wmi-sensors/ . I did a quick search > earlier, but managed to miss this somehow. From its description: Note: X570/B550/TRX40 boards do not have the WMI interface and are not supported. Yes, my board was neither listed as supported, nor as unsupported/unknown in the mentioned README file. Hello all, perhaps this is the wrong place to ask such a question, but after reading many sites on the interwebs about the issue, i am left with the impression that most people (me included) do not actually understand the implications introduced by turning on/off knobs like "acpi_enforce_resources=lax". Also, i read a lot, mostly unclear, comments about "hardware damage" and therefore would like to ask, what is actually the recommended way to go about this with the situation as it is now? Is this issue perhaps only relevant for manual fan control, because with or without "acpi_enforce_resources=lax" and the nct6775 kernel module loaded, the system appears to adjust the fan speed for the appropriate load either way and there aren't any noticable differences between CPU temps either. So i guess my question basically boils down to this: Is there actually something to worry about, apart from not beeing able to see/control fan speeds? I just have become a little worried now with all the contradictive information out there, also read (on phoronix) about this [1] and this [2] a few weeks ago. This is a Asus X570 Gaming-E Board with a Ryzen 5950X CPU. As a regular user, am i going to fry my little computer by running Linux on it? I understand that nobody will guarantee anything, of course, i just felt this might be a good place for a qualified answer, because, obviously, i don't understand any of this low-level stuff. Thanks a bunch. [1] Linux 5.11 Drops AMD Zen Voltage/Current Reporting Over Lack Of Documentation https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.11-Drops-k10temp-V-C [2] AMD Ryzen 5000 Temperature Monitoring Support Sent In For Linux 5.12 https://www.phoronix.com/scan.php?page=news_item&px=Zen-3-Desktop-CPU-k10temp Sydney, I understand that all the discussion can be somewhat confusing. It should be perfectly safe to run Linux on your computer (but as you said no there is no warranty), by default Windows also does not come with any software to monitor the nct6775 sensors. So when installing Linux without making any changes your computer will run the same way as with a pristine (no extra sw installed) windows install. Under Linux you will even be able to monitor the CPU temperature using the CPU's builtin temp-sensors. What does not work is monitoring other temperatures, voltages and fan-speeds. Nor controlling fan-speeds. But typically a modern motherboard will automatically control the CPU fan speed based on temperature, without needing the OS to do anything; Also most users typically use their computer for other things then to monitor the computers temps and voltages. Matthew rightly advises against using "acpi_enforce_resources=lax" because that opens races between the firmware and Linux which could result in writing to another superIO register then intended. This can definitely lead to e.g. stopping the fans even though the CPU is running hot, which is not good but all modern CPUs have builtin overtemp protection, so at the worst the system will simply shutdown (1). Theoretically this could also lead to worse outcomes, such us changes your CPU or RAM voltage which could damage your hardware. I am aware of at least one semi-related case where RAM got seriously overvolted damaging both the RAM and the CPU, this was not with a Super-IO solution though, but with I2C attached sensor probing. 1) Repeatedly overheating your CPU to where it automatically shuts down is not good for your CPU's health though and will likely shorten its lifetime. TL;DR: Don't use "acpi_enforce_resources=lax", otherwise running Linux should be safe and everything should work fine. Hello Hans, thank you for taking the time to answer my question. Your analogy to a (if there is such a thing) "pristine" ~20GB Windows installation makes indeed sense and i imagined something like this already without understanding it properly, but it is indeed reassuring, hearing this from someone who has a much, much better understanding of the subsystem at hand. Personally, i don't have any need for monitoring voltages or manually adjusting fan curves, etc. Also, over the past ~15 years, i have not once been let down by following kernel developers advice, because even if i did not fully understand the issue or even just at hindsight, there has always been deductive, and like Artem has ascertained, sometimes frustrating, yes, but always deductive reasoning behing the decisions and defaults, like it appears to be the case (lack of documentation and/or vendor support) here. A kind of established trust, really. And even if incorrect, _always_ with best knowledge and conscience. IMO, this is all a user can ask for, and unfortunately, albeit mostly in the commercial SW ecosystem, not a given anymore. I would trade these virtues for warranty any day. TL;DR: Much thanks for answering the question this detailed. Flatter/sweet-talk. Will link your post for people with similar concerns. Big thanks again and have a nice week, Hans et al. Sydney, thank you for your kind words, you have put a smile on my face, so thank you. (In reply to Hans de Goede from comment #64) > > Matthew rightly advises against using "acpi_enforce_resources=lax" because > that opens races between the firmware and Linux which could result in > writing to another superIO register then intended. This can definitely lead > to e.g. stopping the fans even though the CPU is running hot, which is not > good but all modern CPUs have builtin overtemp protection, so at the worst > the system will simply shutdown (1). > Multiple users use acpi_enforce_resources=lax and I haven't seen a single report that it's ever broken anything. AFAIK no one has used this hack to control fans using PWM, so that might indeed lead to unintended consequences. I use it for that, and had no problem... yet. 15 abr. 2021 11:27:55 bugzilla-daemon@bugzilla.kernel.org: > https://bugzilla.kernel.org/show_bug.cgi?id=204807 > > --- Comment #67 from Artem S. Tashkinov (aros@gmx.com) --- > (In reply to Hans de Goede from comment #64) >> >> Matthew rightly advises against using "acpi_enforce_resources=lax" because >> that opens races between the firmware and Linux which could result in >> writing to another superIO register then intended. This can definitely lead >> to e.g. stopping the fans even though the CPU is running hot, which is not >> good but all modern CPUs have builtin overtemp protection, so at the worst >> the system will simply shutdown (1). >> > > Multiple users use acpi_enforce_resources=lax and I haven't seen a single > report that it's ever broken anything. > > AFAIK no one has used this hack to control fans using PWM, so that might > indeed > lead to unintended consequences. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug. (In reply to Artem S. Tashkinov from comment #67) > Multiple users use acpi_enforce_resources=lax and I haven't seen a single > report that it's ever broken anything. <sigh> Yet I have been on the receiving end of a bug-report where I had to explain to a user that the lm_sensors sensors-detect script had overvolted his RAM ruining both his expensive high-end RAM as well as his expensive top of the line CPU. The user was surprisingly relaxed about all this, which I really appreciated. And that was while the script was not doing anything which we (the developers) considered dangerous. But the motherboard had a funky setup causing a SMbus *read* transaction to change the voltage. Mucking with this stuff can be dangerous and as Matthew has explained in his thorough analysis of the DSDT the DSDT is actually accessing the superio and if that races with a Linux kernel access a wrong register may be read from, or worse written to. Using acpi_enforce_resources=lax simply is dangerous and we are not going to change the default, period, full-stop. I welcome further discussions here about how we can *safely* solve hwmon access on various motherboards. Please stop discussing acpi_enforce_resources=lax, that is not a safe option to use and more discussion about it is not productive. Created attachment 296451 [details]
acpidump for Pro B550-C
can confirm the issue with ASUS System Product Name/Pro B550M-C, BIOS 0214 10/22/2020
The bug still exists if asus_wmi & eeepc_wmi is blacklisted. Does the acpi_wmi still claim the address space even if no consumer/driver is available?
Created attachment 296529 [details]
Add support for access via Asus WMI to nct6775
(In reply to Bernhard Seibold from comment #71) > Created attachment 296529 [details] > Add support for access via Asus WMI to nct6775 Nice, have you submitted this to kernel's hwmon subsystem maintainer for inclusion into the mainline kernel ? (In reply to Hans de Goede from comment #72) > (In reply to Bernhard Seibold from comment #71) > > Created attachment 296529 [details] > > Add support for access via Asus WMI to nct6775 > > Nice, have you submitted this to kernel's hwmon subsystem maintainer for > inclusion into the mainline kernel ? No, I just finished writing this. I cannot test if it still works correctly for non-WMI cases, and I think using device address zero for WMI is probably a bit hackish. Please also note that this patch only adds access via WMI for i/o port 0x295, while superio access is still using the "traditional" method. There are however also WMI methods for superio access, at least on my board, and it would probably be safer to use those as well. However I would propose to first split the superio functionality into a separate driver. Comments in nct6775 seem to imply that this was/is intended to be done at some point. > Please also note that this patch only adds access via WMI for i/o port 0x295,
> while superio access is still using the "traditional" method.
Ah I missed that, yes that needs to be resolved before this is suitable for upstream. Thank you for your work on this.
Created attachment 296645 [details]
Add support for access via Asus WMI to nct6775 (Rev 2)
Here's an updated patch that also accesses the Super-I/O ports via WMI. Please note that it also adds an ACPI resource check for that IO region. So it might actually make the driver work on less hardware, although that check should probably have been there in the first place.
(In reply to Bernhard Seibold from comment #75) > Created attachment 296645 [details] > Add support for access via Asus WMI to nct6775 (Rev 2) > > Here's an updated patch that also accesses the Super-I/O ports via WMI. > Please note that it also adds an ACPI resource check for that IO region. So > it might actually make the driver work on less hardware, although that check > should probably have been there in the first place. Seems to work here, thank you very much! nct6775: Found NCT6798D or compatible chip at 0x0:0x290 nct6775: Using Asus WMI to access chip $ sensors nct6798-isa-0000 Adapter: ISA adapter I'm only curious why it continues to say ISA adapter which doesn't seem technically correct. Anyways, please submit for Linux 5.13 - it mustn't be too late as we are now in a merge window. Tested-by: Artem S. Tashkinov <aros@gmx.com> (In reply to Bernhard Seibold from comment #75) > Created attachment 296645 [details] > Add support for access via Asus WMI to nct6775 (Rev 2) > > Here's an updated patch that also accesses the Super-I/O ports via WMI. > Please note that it also adds an ACPI resource check for that IO region. So > it might actually make the driver work on less hardware, although that check > should probably have been there in the first place. Hi, I can confirm that this patch works for me too. dmesg |grep nct6775 [ 43.723698] nct6775: Found NCT6798D or compatible chip at 0x0:0x290 [ 43.723890] nct6775: Using Asus WMI to access chip sensors nct6798-* | head -2 nct6798-isa-0000 Adapter: ISA adapter mobo: ASUS ROG STRIX B550-F GAMING (WI-FI) - bios version 2403 kernel: 5.13.0 (patched) Thanks Bernhard! Have a nice sunday everyone. Is there any chance this patch reach upstream ? Thanks a lot Guys ! (In reply to Gregory Duhamel from comment #78) > Is there any chance this patch reach upstream ? Thanks a lot Guys ! I submitted the patch, but it was rejected and I don't intend to continue working on it, sorry. https://www.spinics.net/lists/linux-hwmon/msg11260.html (In reply to Bernhard Seibold from comment #79) > (In reply to Gregory Duhamel from comment #78) > > Is there any chance this patch reach upstream ? Thanks a lot Guys ! > > I submitted the patch, but it was rejected and I don't intend to continue > working on it, sorry. > > https://www.spinics.net/lists/linux-hwmon/msg11260.html To be honest I have no evidence it was rejected, rather additional work is needed. This is standard practice in OSS projects, especially big ones like kernel to reshape patch(es) a few times when it will satisfy all parties. Hi All, I've got the same issue with a ASUS ROG STRIX X570-E Gaming. We need this patch merged! Can anyone with influence or clout help push this along so we can get this resolved? There must be hundreds of thousands affected by this! (In reply to danglingpointerexception@gmail.com from comment #81) > Hi All, I've got the same issue with a ASUS ROG STRIX X570-E Gaming. > > We need this patch merged! Can anyone with influence or clout help push > this along so we can get this resolved? > > There must be hundreds of thousands affected by this! The best what you can do is to go to the mailing list and discuss it there with a respective maintainer. (In reply to Andy Shevchenko from comment #82) > > The best what you can do is to go to the mailing list and discuss it there > with a respective maintainer. Meanwhile this bug is not resolved and there's no (accepted) patch. The bug status is wrong and misleading but I'm not going to argue :-) (In reply to Artem S. Tashkinov from comment #83) > (In reply to Andy Shevchenko from comment #82) > > > > The best what you can do is to go to the mailing list and discuss it there > > with a respective maintainer. > > Meanwhile this bug is not resolved and there's no (accepted) patch. The bug > status is wrong and misleading but I'm not going to argue :-) First of all, read comment #80, second, do not misinterpret the bug status. It shows exactly the current state of affairs. If nobody wants to work further on the offered change, it's not a problem of the community. Linux kernel does not work on "take it or leave it" terms. So, instead of whining here, roll up your sleeves and finish the job, that would be much better! Created attachment 298539 [details]
POC: Add support for access via Asus WMI to nct6775 by board name detect
I have added only small list of board names(/sys/class/dmi/id/board_name), could you add yours and check?
P.S.: I have not checked with real devices.
Please add my board name "TUF GAMING B550-PLUS". I'm happy to roll the patch into my kernel and make whatever checks are needed, but I'm new to this so could use some guidance. Email me if you want me to test on my box? (In reply to Denis Pauk from comment #85) > Created attachment 298539 [details] > POC: Add support for access via Asus WMI to nct6775 by board name detect > > I have added only small list of board names(/sys/class/dmi/id/board_name), > could you add yours and check? > > P.S.: I have not checked with real devices. Thank you all for your great work. I added my board "ROG STRIX B550-F GAMING (WI-FI)" and added patch against 5.14.1-arch1-1 BIOS 2423 08/10/2021. $ dmesg | grep nct6775 [ 6.878846] nct6775: Found NCT6798D or compatible chip at 0x0:0x290 [ 6.879018] nct6775: Using Asus WMI to access chip $ sensors nct6798-isa-0000 Adapter: ISA adapter in0: 472.00 mV (min = +0.00 V, max = +1.74 V) in1: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in2: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.33 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in5: 960.00 mV (min = +0.00 V, max = +0.00 V) ALARM in6: 280.00 mV (min = +0.00 V, max = +0.00 V) ALARM in7: 3.36 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.33 V (min = +0.00 V, max = +0.00 V) ALARM in9: 904.00 mV (min = +0.00 V, max = +0.00 V) ALARM in10: 304.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in12: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in13: 408.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 304.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 714 RPM (min = 0 RPM) fan2: 776 RPM (min = 0 RPM) fan3: 708 RPM (min = 0 RPM) fan4: 870 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) fan6: 0 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +28.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +35.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +82.5°C sensor = thermistor AUXTIN1: +49.0°C sensor = thermistor AUXTIN2: -60.0°C sensor = thermistor AUXTIN3: +78.0°C sensor = thermistor PECI Agent 0 Calibration: +35.5°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled Would be very, very nice if someone has the knowledge to make this acceptable for upstream. Created attachment 298669 [details] POC: Add support for access via Asus WMI to nct6775 by board/vendor name detect Updated version with check vendor name and fix for possible issues with non ASUS motherboards, added names of motherboards have mentioned in bug. I will also check possible way for use functions pointers instead conditional checks equal to access_wmi. After that I will try to send patch to review. (In reply to comment #87) > I added my board "ROG STRIX B550-F GAMING (WI-FI)" and added patch against > 5.14.1-arch1-1 BIOS 2423 08/10/2021. Thank you, I have added your board also. (In reply to comment #86) > Please add my board name "TUF GAMING B550-PLUS". Thank you, I have added it to list. What the distro do you use? For debian it can be: * git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git * cd linux-stable * git check v5.14 * cp /boot/config-5.10.0-8-amd64 .config * make CC="ccache gcc" -j 32 * make CC="ccache gcc" -j 32 bindeb-pkg * sudo dpkg -i ../linux-image-5.14.0+_5.14.0+-1_amd64.deb Look to https://wiki.debian.org/BuildADebianKernelPackage As a side note: using dkms is much faster than recompiling the whole kernel. Can you please also add my board: "TUF GAMING X570-PLUS". Thank you for working on the patch! (In reply to pehlm from comment #90) > Can you please also add my board: "TUF GAMING X570-PLUS". > > Thank you for working on the patch! I'm pretty sure all X570 based ASUS motherboards with this chip have to work via WMI and adding them one by one will needlessly inflate the patch. Blacklisting could be used instead (though I'm quite sure there will be no SKUs to blacklist). (In reply to Artem S. Tashkinov from comment #91) > (In reply to pehlm from comment #90) > > Can you please also add my board: "TUF GAMING X570-PLUS". > > > > Thank you for working on the patch! > > I'm pretty sure all X570 based ASUS motherboards with this chip have to work > via WMI and adding them one by one will needlessly inflate the patch. > Blacklisting could be used instead (though I'm quite sure there will be no > SKUs to blacklist). I even might agree with you, but here is a dilemma: do you want to have the patch accepted in mainline (*), or do you want a better code right now? *) this is what maintainer wants. @Denis Pauk, you may consider to have an array of strings and use match_string() call instead of plenty of strcmp():s. Created attachment 298703 [details]
POC: Add support for access via Asus WMI to nct6775 use match_string
* Use match_string for filter boards
* use function pointers for superio
Thanks Denis! Can confirm the module loads successfully on an Asus PRIME B460-PLUS with the following: [608513.608260] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [608513.608293] acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [608513.608355] acpi PNP0C14:04: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [608513.608404] acpi PNP0C14:05: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [608513.609331] nct6775: Using Asus WMI to access chip [608513.609437] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 I'm not sure about the duplicate warnings, maybe because I am still running a kernel with acpi_enforce_resources=lax (did not reboot before inserting the patched module). (In reply to dflogeras2 from comment #94) > Thanks Denis! Can confirm the module loads successfully on an Asus PRIME > B460-PLUS with the following: > > [608513.608260] acpi PNP0C14:02: duplicate WMI GUID > 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) > [608513.608293] acpi PNP0C14:03: duplicate WMI GUID > 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) > [608513.608355] acpi PNP0C14:04: duplicate WMI GUID > 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) > [608513.608404] acpi PNP0C14:05: duplicate WMI GUID > 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) > [608513.609331] nct6775: Using Asus WMI to access chip > [608513.609437] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > > I'm not sure about the duplicate warnings, maybe because I am still running > a kernel with acpi_enforce_resources=lax (did not reboot before inserting > the patched module). That's bug 201885 which is not related to this one. (In reply to Denis Pauk from comment #88) > Created attachment 298669 [details] > POC: Add support for access via Asus WMI to nct6775 by board/vendor name > detect > > Updated version with check vendor name and fix for possible issues with non > ASUS motherboards, added names of motherboards have mentioned in bug. I will > also check possible way for use functions pointers instead conditional > checks equal to access_wmi. After that I will try to send patch to review. > > (In reply to comment #87) > > I added my board "ROG STRIX B550-F GAMING (WI-FI)" and added patch against > > 5.14.1-arch1-1 BIOS 2423 08/10/2021. > > Thank you, I have added your board also. > > (In reply to comment #86) > > Please add my board name "TUF GAMING B550-PLUS". > > Thank you, I have added it to list. What the distro do you use? > > For debian it can be: > * git clone > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > * cd linux-stable > * git check v5.14 > * cp /boot/config-5.10.0-8-amd64 .config > * make CC="ccache gcc" -j 32 > * make CC="ccache gcc" -j 32 bindeb-pkg > * sudo dpkg -i ../linux-image-5.14.0+_5.14.0+-1_amd64.deb > > Look to https://wiki.debian.org/BuildADebianKernelPackage Denis, I'm on Gentoo, and already have the kernel sources unpacked and ready to go (5.13.13-gentoo). I did the following: # rmmod nct6775 # cd /usrc/src/linux # patch -i ~/nct6775_wmi_v3.patch -p1 # make modules -j12 # mv /lib/modules/5.13.13-gentoo-splig-3-sensors/kernel/drivers/hwmon/nct6775.ko /lib/modules/5.13.13-gentoo-splig-3-sensors/kernel/drivers/hwmon/nct6775.ko.orig # cp drivers/hwmon/nct6775.ko /lib/modules/5.13.13-gentoo-splig-3-sensors/kernel/drivers/hwmon/nct6775.ko # modprobe nct6775 "sensors" output remains the same: nct6798-isa-0290 Adapter: ISA adapter in0: 376.00 mV (min = +0.00 V, max = +1.74 V) in1: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in2: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.30 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM in5: 880.00 mV (min = +0.00 V, max = +0.00 V) ALARM in6: 256.00 mV (min = +0.00 V, max = +0.00 V) ALARM in7: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.28 V (min = +0.00 V, max = +0.00 V) ALARM in9: 904.00 mV (min = +0.00 V, max = +0.00 V) ALARM in10: 264.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in12: 1.04 V (min = +0.00 V, max = +0.00 V) ALARM in13: 368.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 272.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 716 RPM (min = 0 RPM) fan3: 496 RPM (min = 0 RPM) fan4: 327 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) fan6: 0 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +33.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +35.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +85.0°C sensor = thermistor AUXTIN1: +55.0°C sensor = thermistor AUXTIN2: -61.0°C sensor = thermistor AUXTIN3: +79.0°C sensor = thermistor PECI Agent 0 Calibration: +34.5°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled dmesg with tree module: [ 3596.867638] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [ 3596.867642] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210331/utaddress-204) [ 3596.867645] ACPI: OSL: Resource conflict; ACPI support missing from driver? [ 3596.867646] ACPI: OSL: Resource conflict: System may be unstable or behave erratically dmesg with patched module: [ 3681.885428] nct6775: Using Asus WMI to access chip [ 3681.885468] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.13.13-gentoo-splig-3-sensors root=/dev/nvme0n1p3 ro module_blacklist=nouveau acpi_enforce_resources=lax I hope that's of some use. The differing dmesg output suggests that the patch is helping, but shouldn't there be a change (improvement) to the sensors output? (In reply to Tom Lloyd from comment #96) > > I hope that's of some use. The differing dmesg output suggests that the > patch is helping, but shouldn't there be a change (improvement) to the > sensors output? You already worked around your problem by adding the line: acpi_enforce_resources=lax, so with or without the patch, your 'sensors' output will work. With the patch, sensors uses WMI. Without the patch, sensors is only working because you've switched to 'lax'. (In reply to Tom Lloyd from comment #96) > > I hope that's of some use. The differing dmesg output suggests that the > patch is helping, but shouldn't there be a change (improvement) to the > sensors output? The patch which is being worked on here is simply changing the method of accessing hardware, it does _not_ change the underlying driver which deciphers the sensor inputs. To improve the output you've got to create e.g. /etc/sensors.d/nct6798.conf and describe your desired configuration there but that's outside the scope of this bugzilla. Please read lm-sensors documentations for that. I've already done that for the ASUS TUF GAMING X570-PLUS (WI-FI) motherboard: https://github.com/lm-sensors/lm-sensors/pull/216 but my configuration is very incomplete since the documentation for this chip is likely proprietary and not available publicly. Even HWiNFO64 fails to decipher multiple inputs and shows them as is and that's the best application for that under Windows. Then certain inputs may simply not be connected to anything and basically report white noise. If you have close contacts at ASUS they may give you the data but that's far from certain. For some reasons hardware monitoring for motherboards, GPUs and CPUs is veiled in secrecy and protected by patents and NDA. That all makes sense, thanks both for the clarification. I can confirm then that the patch works on my hardware "TUF GAMING B550-PLUS". Good luck getting it into the tree :) I have sent https://bugzilla.kernel.org/attachment.cgi?id=298703 version to review: https://lkml.org/lkml/2021/9/8/840 ``` $ sudo dmidecode | grep -i B550 Product Name: ROG STRIX B550-F GAMING $ ``` The patch worked for me after adding my board name, could you please also add "ROG STRIX B550-F GAMING"? Thank you for working on this patch. Created attachment 298771 [details]
System Info after applying latest patch
Hi, (oh. Could've put my comment in the attachment comment... duh) I applied Denis Pauk patch today, (how I did it described in https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ). While I'm not sure if I did everything correctly, I can see nct6775 pulling in the wmi module now, so I'm fairly certain I'm running the patch. And yet I'm somehow still getting the acpi access warning, and no further sensor output. Did I do something wrong? System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X Hi guys, I have tried the patch for my "ROG STRIX B550-I GAMING", LGFM: ``` nct6798-isa-0290 Adapter: ISA adapter Vcore: 472.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM AVSB: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM 3VCC: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM +12V: 12.19 V (min = +0.00 V, max = +0.00 V) ALARM in5: 856.00 mV (min = +0.00 V, max = +0.00 V) ALARM +5V: 1.48 V (min = +0.00 V, max = +0.00 V) ALARM 3.3V: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM Vbat: 3.47 V (min = +0.00 V, max = +0.00 V) ALARM in9: 896.00 mV (min = +0.00 V, max = +0.00 V) ALARM in13: 280.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 280.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 750 RPM (min = 0 RPM) CPU Fan: 585 RPM (min = 0 RPM) CHA_FAN1: 0 RPM (min = 0 RPM) SYSTIN: +34.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +33.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +80.5°C sensor = thermistor AUXTIN1: +34.0°C sensor = thermistor AUXTIN2: +34.0°C sensor = thermistor AUXTIN3: +86.0°C sensor = thermistor PECI Agent 0 Calibration: +33.0°C beep_enable: disabled ``` The TUF-GAMING-X570-PLUS.conf config file was used from the comment 98. Just wonder, so high temperature on AUXTIN0 and on AUXTIN3 is something real? And what it could be? Or it could be because the TUF-GAMING-X570-PLUS.conf is badly applicable/adjusted for another MB model? (In reply to Jonathan from comment #103) > Hi, > (oh. Could've put my comment in the attachment comment... duh) > I applied Denis Pauk patch today, (how I did it described in > https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ). > While I'm not sure if I did everything correctly, I can see nct6775 pulling > in the wmi module now, so I'm fairly certain I'm running the patch. > And yet I'm somehow still getting the acpi access warning, and no further > sensor output. > Did I do something wrong? > > System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X Could you please check with original patch from Bernhard Seibold? And check what is value in "/sys/class/dmi/id/board_name" ? (In reply to Denis Pauk from comment #105) > (In reply to Jonathan from comment #103) > > Hi, > > (oh. Could've put my comment in the attachment comment... duh) > > I applied Denis Pauk patch today, (how I did it described in > > https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ). > > While I'm not sure if I did everything correctly, I can see nct6775 pulling > > in the wmi module now, so I'm fairly certain I'm running the patch. > > And yet I'm somehow still getting the acpi access warning, and no further > > sensor output. > > Did I do something wrong? > > > > System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X > > Could you please check with original patch from Bernhard Seibold? > And check what is value in "/sys/class/dmi/id/board_name" ? Sure. I'll try the "original" patch tomorrow. ``` cat /sys/class/dmi/id/board_name TUF GAMING X570-PLUS (WI-FI) ``` (In reply to Denis Pauk from comment #100) > I have sent https://bugzilla.kernel.org/attachment.cgi?id=298703 version to > review: https://lkml.org/lkml/2021/9/8/840 Could you please add C8H motherboards to the patch at the next iteration? "ROG CROSSHAIR VIII HERO" "ROG CROSSHAIR VIII DARK HERO" i can confirm for "ROG CROSSHAIR VIII DARK HERO" (Rev X.0x): [ 3.360424] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [ 3.360433] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210604/utaddress-204) Created attachment 298799 [details] dmesg for boot with Denis's patch applied (In reply to Jonathan from comment #106) > (In reply to Denis Pauk from comment #105) > > (In reply to Jonathan from comment #103) > > > Hi, > > > (oh. Could've put my comment in the attachment comment... duh) > > > I applied Denis Pauk patch today, (how I did it described in > > > https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ). > > > While I'm not sure if I did everything correctly, I can see nct6775 > pulling > > > in the wmi module now, so I'm fairly certain I'm running the patch. > > > And yet I'm somehow still getting the acpi access warning, and no further > > > sensor output. > > > Did I do something wrong? > > > > > > System: Asus TUF Gaming X570-Plus (Wi-Fi) with 5600X > > > > Could you please check with original patch from Bernhard Seibold? > > And check what is value in "/sys/class/dmi/id/board_name" ? > > Sure. I'll try the "original" patch tomorrow. > > ``` > cat /sys/class/dmi/id/board_name > > TUF GAMING X570-PLUS (WI-FI) > ``` I've tested both patches now. I had trouble getting Bernhard's to run via dkms, so I built a custom kernel. Worked flawlessly afterwards. Out of fairness (since I'm really not that sure if my dkms attempts yesterday actually worked), I also built a kernel with Denis's patch. Didn't change much. I've attached dmesg for Denis's patch. Created attachment 298805 [details] POC: Add support for access via Asus WMI to nct6775 with debug Add more debug information about what is wrong with match vendor/board names. (In reply to Jonathan from comment #109) > Created attachment 298799 [details] > dmesg for boot with Denis's patch applied Could you add your board to list and recheck? Most of these boards, as you probably know already, seem to not provide readings for all the available sensors via the Nuvoton chip. For example, water temperature sensors are unavailable. Readings from those sensors are available via the embedded controller registers. Thus I created a little HWMON driver [1] to read them using WMI method 'BREC' (probably stands for Block Read Embedded Controller). The driver currently supports only three boards (ROG Crosshair VIII Hero, ROG Crosshair VIII Dark Hero, ROG STRIX X570-E GAMING). ROG Crosshair VIII Formula should not differ, but need someone with the hardware to test. While working on these sensors for the Libre Hardware Monitor project, we found that the Nuvoton 6798D chip provides sensors readings for configured in the BIOS QFan sources in its registers [2]. Maybe those are worth displaying with the nct6775 driver? They can include sensors that are otherwise are available from the embedded controller only. If you want to add support for your boards, feel free to submit patches to either project (and notify me to update the driver for HWMON from LHM if needed, please). [1] https://github.com/zeule/asus-wmi-ec-sensors [2] https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/issues/533
please add:
cat /sys/class/dmi/id/board_name
ROG STRIX X570-F GAMING
can confirm latest debug.diff is working, many thanks:
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `nct6775':
* ISA bus, address 0x290
Chip `Nuvoton NCT6798D Super IO Sensors' (confidence: 9)
Driver `k10temp' (autoloaded):
* Chip `AMD Family 17h thermal sensors' (confidence: 9)
Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no):
Unloading i2c-dev... OK
-
Sep 15 01:55:35 desk kernel: nct6775: Using Asus WMI to access 0xc1 chip.
Sep 15 01:55:35 desk kernel: nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
Sep 15 02:02:41 desk systemd[1]: Starting Hardware Monitoring Sensors...
Sep 15 02:02:41 desk kernel: nct6775: Using Asus WMI to access 0xc1 chip.
Sep 15 02:02:41 desk kernel: nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
Sep 15 02:02:41 desk systemd[1]: Finished Hardware Monitoring Sensors.
-
[root@desk testM]# sensors
amdgpu-pci-0700
Adapter: PCI adapter
vddgfx: 950.00 mV
fan1: 835 RPM (min = 0 RPM, max = 3200 RPM)
edge: +39.0°C (crit = +91.0°C, hyst = -273.1°C)
power1: 44.15 W (cap = 277.00 W)
nct6798-isa-0290
Adapter: ISA adapter
in0: 888.00 mV (min = +0.00 V, max = +1.74 V)
in1: 992.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in2: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM
in3: 3.30 V (min = +0.00 V, max = +0.00 V) ALARM
in4: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
in5: 960.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in6: 256.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in7: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM
in8: 3.33 V (min = +0.00 V, max = +0.00 V) ALARM
in9: 904.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in10: 480.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in11: 496.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in12: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM
in13: 344.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in14: 256.00 mV (min = +0.00 V, max = +0.00 V) ALARM
fan1: 678 RPM (min = 0 RPM)
fan2: 575 RPM (min = 0 RPM)
fan3: 1050 RPM (min = 0 RPM)
fan4: 738 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
SYSTIN: +28.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
CPUTIN: +33.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +86.0°C sensor = thermistor
AUXTIN1: +28.0°C sensor = thermistor
AUXTIN2: +26.0°C sensor = thermistor
AUXTIN3: +91.0°C sensor = thermistor
PECI Agent 0 Calibration: +33.5°C
PCH_CHIP_CPU_MAX_TEMP: +0.0°C
PCH_CHIP_TEMP: +0.0°C
PCH_CPU_TEMP: +0.0°C
intrusion0: ALARM
intrusion1: ALARM
beep_enable: disabled
k10temp-pci-00c3
Adapter: PCI adapter
Tctl: +32.6°C
Tdie: +32.6°C
Tccd1: +39.5°C
(In reply to Denis Pauk from comment #110) > Created attachment 298805 [details] > POC: Add support for access via Asus WMI to nct6775 with debug > > Add more debug information about what is wrong with match vendor/board names. > > (In reply to Jonathan from comment #109) > > Created attachment 298799 [details] > > dmesg for boot with Denis's patch applied > > Could you add your board to list and recheck? This patch works, after adding "TUF GAMING X570-PLUS (WI-FI)". (At first it didn't, but then I noticed I did forget the closing bracket on "(WI-FI") Patch series are applied by Guenter Roeck. https://lkml.org/lkml/2021/9/17/1079 Thank you everyone! To be more precise it's here: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?id=cd0b8e410937 Thank you, Denis! Thank you very much for your work, Denis! (In reply to Denis Pauk from comment #114) > Patch series are applied by Guenter Roeck. > https://lkml.org/lkml/2021/9/17/1079 > > Thank you everyone! guess i was a bit late to the party and "ROG STRIX X570-F GAMING" did not get added (as per comment 112).. but hey thanks for this patch :) Thanks! I confirm the patch works for me with ASUS PRIME B360-PLUS and linux-5.14.5 after adding the board on the white-list:
--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -4986,6 +4986,7 @@ static int __init nct6775_find(int sioaddr, struct nct6775_sio_data *sio_data)
static struct platform_device *pdev[2];
static const char * const asus_wmi_boards[] = {
+ "PRIME B360-PLUS",
"PRIME B460-PLUS",
"ROG CROSSHAIR VIII DARK HERO",
"ROG CROSSHAIR VIII HERO",
# sensors nct6796-isa-0290
nct6796-isa-0290
Adapter: ISA adapter
Vcore: 376.00 mV (min = +0.00 V, max = +1.74 V)
in1: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
AVCC: 3.46 V (min = +0.00 V, max = +0.00 V) ALARM
+3.3V: 3.42 V (min = +0.00 V, max = +0.00 V) ALARM
in4: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM
in5: 144.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in6: 120.00 mV (min = +0.00 V, max = +0.00 V) ALARM
3VSB: 3.46 V (min = +0.00 V, max = +0.00 V) ALARM
Vbat: 3.22 V (min = +0.00 V, max = +0.00 V) ALARM
in9: 1.05 V (min = +0.00 V, max = +0.00 V) ALARM
in10: 152.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in11: 128.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in12: 136.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in13: 120.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in14: 136.00 mV (min = +0.00 V, max = +0.00 V) ALARM
fan1: 1073 RPM (min = 0 RPM)
fan2: 1214 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
fan7: 0 RPM (min = 0 RPM)
SYSTIN: +28.0°C (high = +98.0°C, hyst = +95.0°C) sensor = thermistor
CPUTIN: +33.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +111.0°C sensor = thermistor
AUXTIN1: +118.0°C sensor = thermistor
AUXTIN2: +117.0°C sensor = thermistor
AUXTIN3: +118.0°C sensor = thermistor
PECI Agent 0: +37.0°C (high = +98.0°C, hyst = +95.0°C)
(crit = +100.0°C)
PECI Agent 0 Calibration: +32.0°C
PCH_CHIP_CPU_MAX_TEMP: +0.0°C
PCH_CHIP_TEMP: +0.0°C
intrusion0: ALARM
intrusion1: ALARM
beep_enable: disabled
does this patch change how kernel reads the sensor values (e.g. to that buggy asus wmi interface) or it merely sets specifically for nct67 module what "acpi_enforce_resources=lax" does? (In reply to nutodafozo from comment #119) > does this patch change how kernel reads the sensor values (e.g. to that > buggy asus wmi interface) or The underlying module/driver which reads sensors data is the same and this patch doesn't touch it. > it merely sets specifically for nct67 module what > "acpi_enforce_resources=lax" does? Exactly. FYI, tested also with "ROG CROSSHAIR VIII FORMULA", works well. [72758.077595] nct6775: Using Asus WMI to access chip [72758.077637] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 nct6798-isa-0290 Adapter: ISA adapter in0: 936.00 mV (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.74 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.08 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.31 V (min = +0.00 V, max = +0.00 V) ALARM in9: 912.00 mV (min = +0.00 V, max = +0.00 V) ALARM in10: 80.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.34 V (min = +0.00 V, max = +0.00 V) ALARM in14: 904.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 422 RPM (min = 0 RPM) fan2: 991 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 626 RPM (min = 0 RPM) fan6: 0 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +35.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +38.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +22.0°C sensor = thermistor AUXTIN1: +104.0°C sensor = thermistor AUXTIN2: +98.0°C sensor = thermistor AUXTIN3: +31.0°C sensor = thermistor PECI Agent 0 Calibration: +39.0°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled I confrm patch works on my "TUF GAMING Z490-PLUS (WI-FI)".
[1295150.017048] nct6775: Found NCT6798D or compatible chip at 0x0:0x290
nct6798-isa-0000
Adapter: ISA adapter
in0: 835.00 mV (min = +0.00 V, max = +1.94 V)
in1: 5.00 V (min = +0.00 V, max = +0.00 V) ALARM
in2: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM
in3: 3.33 V (min = +0.00 V, max = +0.00 V) ALARM
in4: 12.00 V (min = +0.00 V, max = +0.00 V) ALARM
in5: 784.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in6: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in7: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM
in8: 3.12 V (min = +0.00 V, max = +0.00 V) ALARM
in9: 1.06 V (min = +0.00 V, max = +0.00 V) ALARM
in10: 1.36 V (min = +0.00 V, max = +0.00 V) ALARM
in11: 960.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in12: 1.04 V (min = +0.00 V, max = +0.00 V) ALARM
in13: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in14: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
fan1: 369 RPM (min = 0 RPM)
fan2: 389 RPM (min = 0 RPM)
fan3: 398 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
fan7: 0 RPM (min = 0 RPM)
SYSTIN: +30.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
CPUTIN: +33.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +26.0°C sensor = thermistor
AUXTIN1: +7.0°C sensor = thermistor
AUXTIN2: +28.0°C sensor = thermistor
AUXTIN3: +25.0°C sensor = thermistor
PECI Agent 0 Calibration: +32.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
I also noticed that some voltage values reported by nct6775 differs from the ones reported by Asus software on Windows.
I changed voltage scaling factors to those listed below and now voltages are reported like on Asus software on Windows.
/*
* Some of the voltage inputs have internal scaling, the tables below
* contain 8 (the ADC LSB in mV) * scaling factor * 100
*/
static const u16 scale_in[15] = {
888, 4000, 1600, 1600, 9600, 800, 800, 1600, 1600, 1600, 1600, 1600, 800,
800, 800
};
(In reply to Kamil Pietrzak from comment #122) > I confrm patch works on my "TUF GAMING Z490-PLUS (WI-FI)". > > [1295150.017048] nct6775: Found NCT6798D or compatible chip at 0x0:0x290 .... > > I also noticed that some voltage values reported by nct6775 differs from the > ones reported by Asus software on Windows. > > I changed voltage scaling factors to those listed below and now voltages are > reported like on Asus software on Windows. > > /* > * Some of the voltage inputs have internal scaling, the tables below > * contain 8 (the ADC LSB in mV) * scaling factor * 100 > */ > static const u16 scale_in[15] = { > 888, 4000, 1600, 1600, 9600, 800, 800, 1600, 1600, 1600, 1600, 1600, > 800, > 800, 800 > }; It looks like need to update code with custom scale values in relation to board name. And it can be in future patches. Also need to look what functionality is nondestructive and can be merged in: * https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/OpenRGB.patch * https://github.com/zeule/asus-wmi-ec-sensors/blob/master/asus-wmi-ec-sensors.c * https://github.com/electrified/asus-wmi-sensors/ and cover maximum boards. OpenRGB looks as good candidate for merge, as I see it uses i2c bus instead asuswmi, and we already have ground for custom logic, it should be possible if we have list of boards where such access is implemented by ASUS?. (In reply to Eugene Shalygin from comment #111) > Most of these boards, as you probably know already, seem to not provide > readings for all the available sensors via the Nuvoton chip. For example, > [...] we found that the Nuvoton 6798D chip provides sensors readings for > configured in the BIOS QFan sources in its registers [2]. Maybe those are > worth displaying with the nct6775 driver? They can include sensors that > are otherwise are available from the embedded controller only. I can't really vouch for high end desktop motherboards, but at least as far as laptops are concerned this has been the case since forever about everywhere (ranging from "somewhat nitpicky" lacks to "kinda important" ones) https://github.com/daringer/asus-fan/issues/13 https://github.com/daringer/asus-fan/issues/44#issuecomment-487380638 I don't know how dangerous accessing EC could be (be it directly, or through possible ACPI methods.. in some cases datasheets may even be available), but something else that isn't just vanilla WMI is needed. https://sourceforge.net/p/acpi4asus/mailman/message/7375427/ Btw following the breadcrumb trail of the asus linux drivers history.. it seems like different/older machines may have used 'ECRW' in its place (or if not any I found that to still be present on my 2016 X756UX). Created attachment 298887 [details]
Add support for access via Asus WMI to nct6775 (2021.09.20)
Updated patch with support:
---
+ "PRIME B360-PLUS",
+ "PRIME B460-PLUS",
+ "ROG CROSSHAIR VIII DARK HERO",
+ "ROG CROSSHAIR VIII FORMULA",
+ "ROG CROSSHAIR VIII HERO",
+ "ROG CROSSHAIR VIII IMPACT",
+ "ROG STRIX B550-E GAMING",
+ "ROG STRIX B550-F GAMING",
+ "ROG STRIX B550-F GAMING (WI-FI)",
+ "ROG STRIX X570-F GAMING",
+ "ROG STRIX Z390-E GAMING",
+ "ROG STRIX Z490-I GAMING",
+ "TUF GAMING B550M-PLUS",
+ "TUF GAMING B550M-PLUS (WI-FI)",
+ "TUF GAMING B550-PLUS",
+ "TUF GAMING X570-PLUS",
+ "TUF GAMING X570-PLUS (WI-FI)",
+ "TUF GAMING X570-PRO (WI-FI)",
+ "TUF GAMING Z490-PLUS (WI-FI)",
---
(In reply to Denis Pauk from comment #125) > Created attachment 298887 [details] > Add support for access via Asus WMI to nct6775 (2021.09.20) > > Updated patch with support: Could you please add my motherboard as well? cat /sys/class/dmi/id/board_name ROG STRIX B550-I GAMING I mention it in the comment 104 above. Created attachment 298905 [details]
Add support for access via Asus WMI to nct6775 (2021.09.21)
Added support by ASUSWMI:
--
+ "PRIME B360-PLUS",
+ "PRIME B460-PLUS",
+ "PRIME X570-PRO",
+ "ROG CROSSHAIR VIII DARK HERO",
+ "ROG CROSSHAIR VIII FORMULA",
+ "ROG CROSSHAIR VIII HERO",
+ "ROG CROSSHAIR VIII IMPACT",
+ "ROG STRIX B550-E GAMING",
+ "ROG STRIX B550-F GAMING",
+ "ROG STRIX B550-I GAMING",
+ "ROG STRIX B550-F GAMING (WI-FI)",
+ "ROG STRIX X570-F GAMING",
+ "ROG STRIX Z390-E GAMING",
+ "ROG STRIX Z490-I GAMING",
+ "TUF GAMING B550M-PLUS",
+ "TUF GAMING B550M-PLUS (WI-FI)",
+ "TUF GAMING B550-PLUS",
+ "TUF GAMING X570-PLUS",
+ "TUF GAMING X570-PLUS (WI-FI)",
+ "TUF GAMING X570-PRO (WI-FI)",
+ "TUF GAMING Z490-PLUS (WI-FI)",
--
I have added i2c adapter code from OpenRGB code:
--
+ "PRIME B450M-GAMING",
+ "PRIME X370-PRO",
+ "PRIME X399-A",
+ "PRIME X470-PRO",
+ "PRIME Z270-A",
+ "PRIME Z370-A",
+ "ROG CROSSHAIR VI HERO",
+ "ROG STRIX B350-F GAMING",
+ "ROG STRIX B450-F GAMING",
+ "ROG STRIX X399-E GAMING",
+ "ROG STRIX Z270-E",
+ "ROG STRIX Z370-E",
+ "ROG STRIX Z490-E GAMING",
+ "TUF B450 PLUS GAMING",
--
Could anyone with such boards check that it still works with OpenRGB? It uses incompatible with ASUSWMI method. If it works, i will try to port to use AsusWMI code.
Created attachment 298971 [details] Add support for access via Asus WMI (2021.09.25) Support by nct6775:ASUSWMI: --- + "PRIME B360-PLUS", + "PRIME B460-PLUS", + "PRIME X570-PRO", + "ROG CROSSHAIR VIII DARK HERO", + "ROG CROSSHAIR VIII FORMULA", + "ROG CROSSHAIR VIII HERO", + "ROG CROSSHAIR VIII IMPACT", + "ROG STRIX B550-E GAMING", + "ROG STRIX B550-F GAMING", + "ROG STRIX B550-F GAMING (WI-FI)", + "ROG STRIX B550-I GAMING", + "ROG STRIX X570-F GAMING", + "ROG STRIX Z390-E GAMING", + "ROG STRIX Z490-I GAMING", + "TUF GAMING B550M-PLUS", + "TUF GAMING B550M-PLUS (WI-FI)", + "TUF GAMING B550-PLUS", + "TUF GAMING B550-PRO", + "TUF GAMING X570-PLUS", + "TUF GAMING X570-PLUS (WI-FI)", + "TUF GAMING X570-PRO (WI-FI)", + "TUF GAMING Z490-PLUS (WI-FI)", --- Support nct6775:i2c (OpenRGB code): -- + "PRIME B450M-GAMING", + "PRIME X370-PRO", + "PRIME X399-A", + "PRIME X470-PRO", + "PRIME Z270-A", + "PRIME Z370-A", + "ROG CROSSHAIR VI HERO", + "ROG STRIX B350-F GAMING", + "ROG STRIX B450-F GAMING", + "ROG STRIX X399-E GAMING", + "ROG STRIX Z270-E", + "ROG STRIX Z370-E", + "ROG STRIX Z490-E GAMING", + "TUF B450 PLUS GAMING", -- Support ASUS WSI asus_wmi_sensors:native (https://github.com/electrified/asus-wmi-sensors): --- + "ROG CROSSHAIR VII HERO (WI-FI)", + "ROG CROSSHAIR VII HERO", + "ROG CROSSHAIR VI HERO (WI-FI AC)", + "CROSSHAIR VI HERO", + "ROG CROSSHAIR VI EXTREME", + "ROG ZENITH EXTREME", + "ROG ZENITH EXTREME ALPHA", + "PRIME X399-A", + "PRIME X470-PRO", + "ROG STRIX X399-E GAMING", + "ROG STRIX B450-E GAMING", + "ROG STRIX B450-F GAMING", + "ROG STRIX B450-I GAMING", + "ROG STRIX X470-I GAMING", + "ROG STRIX X470-F GAMING", ---- Support ASUS WSI asus_wmi_sensors:ec (https://github.com/zeule/asus-wmi-ec-sensors/blob/master): --- + [BOARD_R_C8H] = "ROG CROSSHAIR VIII HERO", + [BOARD_R_C8DH] = "ROG CROSSHAIR VIII DARK HERO", + [BOARD_R_C8F] = "ROG CROSSHAIR VIII FORMULA", + [BOARD_RS_X570_E_G] = "ROG STRIX X570-E GAMING", + [BOARD_RS_B550_E_G] = "ROG STRIX B550-E GAMING", --- (In reply to Kamil Pietrzak from comment #122) > static const u16 scale_in[15] = { > 888, 4000, 1600, 1600, 9600, 800, 800, 1600, 1600, 1600, 1600, 1600, > 800, > 800, 800 > }; @Kamil Pietrzak Could you please check that scale applied to your board correctly? (In reply to Eugene Shalygin from comment #111) > Thus I created a little HWMON driver [1] to read them using WMI method > 'BREC'. @Eugene Shalygin Could you please check that combined version is still worked? (In reply to Denis Pauk from comment #128) > @Eugene Shalygin Could you please check that combined version is still > worked? Thank you for your efforts to mainline these drivers! I have a couple of changes and questions to the EC part. Is a review going on somewhere where I can participate? Otherwise here are the main points: 1. I'm pretty sure the B550-E GAMING board has no EC sensors. Other B550 boards I've seen DSDT from provide a dummy BREC() function. 2. The "Water" fan sensor should have been named "Water_pump" or alike. 3. There is probably an AIO fan sensor at (2, 0x00, 0xB8) EC, but I did not yet find time to check. Maybe someone has this header connected and can do a test for us? I'll try to test with hardware later today. Thank you for your work, Denis! (In reply to Denis Pauk from comment #128) > @Kamil Pietrzak Could you please check that scale applied to your board > correctly? I confirm voltages defined in "static const u16 scale_in_z490[15]" are applied correctly to my motherboard "TUF GAMING Z490-PLUS (WI-FI)". Motherboard "TUF GAMING Z490-PLUS (WI-FI)" is using Nuvoton NCT6798D Super I/O, so probably all motherboards that use same Nuvoton chip may benefit from those new voltage scaling factors. Maybe variable "static const u16 scale_in_z490" could have some more generic name related to NCT6798D. Here I have to admit that I figured out those voltage scaling factors by try and error (to match voltages to those shown in Asus software on Windows), cause I could not find Nuvoton NCT6798D documentation on Nuvoton website. Also I think it is probaby safe to add motherboard "TUF GAMING Z490-PLUS" to supported boards, case as far as I know the only difference between "TUF GAMING Z490-PLUS" and "TUF GAMING Z490-PLUS (WI-FI)" is Intel Wi-Fi 6 AX201 chip on the latter. (In reply to Eugene Shalygin from comment #129) > Thank you for your efforts to mainline these drivers! I have a couple of > changes and questions to the EC part. Is a review going on somewhere where I > can participate? Otherwise here are the main points: > I have not sent it to review yet. I prefer to have checked at least one motherboard from each group before send for review. Especially i2c adapter. (In reply to Eugene Shalygin from comment #129) > 1. I'm pretty sure the B550-E GAMING board has no EC sensors. Other B550 > boards I've seen DSDT from provide a dummy BREC() function. As for me it has returned reasonable values for "ROG STRIX B550-E GAMING": ---- asuswmiecsensors-isa-0000 Adapter: ISA adapter Chipset: +32.0°C CPU: +22.0°C Motherboard: +22.0°C T_Sensor: +216.0°C VRM: +28.0°C k10temp-pci-00c3 Adapter: PCI adapter Tctl: +25.1°C Tdie: +25.1°C Tccd1: +22.5°C Tccd2: +24.5°C ---- Maybe it has other valuable sensors, I have used some lucky values for now that looks as reasonable. Motherboard for sure has T_Sensor and AIO_PUMP by https://rog.asus.com/motherboards/rog-strix/rog-strix-b550-e-gaming-model/spec. (In reply to Kamil Pietrzak from comment #130) > Motherboard "TUF GAMING Z490-PLUS (WI-FI)" is using Nuvoton NCT6798D Super > I/O, so probably all motherboards that use same Nuvoton chip may benefit > from those new voltage scaling factors. What do you think about use kernel mode parameter for use custom value until we will have some approve that other motherboards with NCT6798D has same scale factors? Created attachment 299111 [details] Add support for access via Asus WMI (2021.10.05) Patch with same list of supported boards, additionally applied changes from review https://lkml.org/lkml/2021/10/2/189. (In reply to Kamil Pietrzak from comment #130) > I confirm voltages defined in "static const u16 scale_in_z490[15]" are > applied correctly to my motherboard "TUF GAMING Z490-PLUS (WI-FI)". I afraid next patch will be without scaling :-( https://lkml.org/lkml/2021/10/5/707 (In reply to Denis Pauk from comment #133) > I afraid next patch will be without scaling :-( > https://lkml.org/lkml/2021/10/5/707 I am not kernel developer but I also think per motherboard voltage scalling is bad idea in terms of maintenance. For the same reason hardcoding any of board models in module code is rather bad idea and personally I would prefer to use for example use_wmi=y module parameter or similar when resource conflict occurs on module loading. With regard to current voltage scaling factors for nct6798d chip, they are most likely not correct and probably will require future changes. For example I can't see +12V and +5V is sensors output when using current voltage scalling factors. (In reply to Kamil Pietrzak from comment #137) > With regard to current voltage scaling factors for nct6798d chip, they are > most likely not correct and probably will require future changes. For > example I can't see +12V and +5V is sensors output when using current > voltage scalling factors. Partially responding to my own comment here. Due to the lack of publicly available documentation for NCT6798D chip I checked docs for similar chips (NCT6791D, NCT6791D). Looks like voltages like +12V and +5V can be connected to any one of general purpose voltage inputs on the SuperIO chip. So on one motherboard +12V can be connected to pin VIN0, but on another one with same SuperIO chip it can possibly be connected to other general purpose voltage pin like VIN1, VIN2, VIN3 etc. In that case it will not be possible to properly scale these voltages without hardcoding motherboard models in module code, so scaling should take place in userspace apps like lm_sensors. The only voltages that can be safely scaled in module code are Vcore, AVSB, 3VCC, 3VSB, VBAT. Pins to which they are connected should not change between different motherboards. So it looks like current voltage scaling factors are as accurate as it can be without hardcoding motherboards models. However, I am still curious about Vcore voltage readings on my TUF Z490 board in BIOS and Asus software. According to docs Vcore should be calculated with formula Detected Voltage = Reading * 0.008 V but Asus in BIOS and in their software on Windows calculate it probably with some additional scaling factor, most likely something like Detected Voltage = Reading * 0.008 V * 1.11 The only reason that comes to my mind for calculating Vcore in that way is that they (Asus) wanted BIOS/software Vcore readings to be more accurate in relation to voltage readings using for example multimeter near the CPU socket. Created attachment 299159 [details] Add support for access via Asus WMI (2021.10.10) Rebased over https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-next Sent to LKML(without unchecked i2c logic): https://lkml.org/lkml/2021/10/10/65 Can someone add my board please? It is an Asus PRIME X570-P, I guess the sensor should be, if not exactly the same, as the one from an Asus PRIME X570-Pro. I cannot use Linux with my board since the CPU fan is spinning at maximum speed making an extreme amount of noise, due to that module's sensor readings which are wrong. I would like to ask for an assistance to understand why reading EC sensors takes so much time (1 second). Could, please, users of boards with sensors published in EC registers (we currently aware of the following models: Pro WS X570-ACE, ROG Crosshair VIII Hero, ROG Crosshair VIII Dark Hero, ROG Crosshair VIII Formula, G STRIX B550-E GAMING, ROG STRIX X570-E GAMING) measure how long does it take to read all 256 EC registers in their system and report back the time and the board name? # modprobe ec_sys # time cat /sys/kernel/debug/ec/ec0/io > /dev/null Thank you! (In reply to Feliks from comment #140) > Can someone add my board please? It is an Asus PRIME X570-P, I guess the > sensor should be, if not exactly the same, as the one from an Asus PRIME > X570-Pro. > I cannot use Linux with my board since the CPU fan is spinning at maximum > speed making an extreme amount of noise, due to that module's sensor > readings which are wrong. You have to test yourself before anybody else will add it. (In reply to Eugene Shalygin from comment #141) > I would like to ask for an assistance to understand why reading EC sensors > takes so much time (1 second). Could, please, users of boards with sensors > published in EC registers (we currently aware of the following models: Pro > WS X570-ACE, ROG Crosshair VIII Hero, ROG Crosshair VIII Dark Hero, ROG > Crosshair VIII Formula, G STRIX B550-E GAMING, ROG STRIX X570-E GAMING) > measure how long does it take to read all 256 EC registers in their system > and report back the time and the board name? > > # modprobe ec_sys > # time cat /sys/kernel/debug/ec/ec0/io > /dev/null It won't mean anything. The each register read separately may take a long time since EC is a separate uController that may be interrupted at any time by any higher priority task (to be sure you have to have a look into the firmware source code). So, I'll be not surprised if 1s in some cases is not enough. Not I'm against the shrtening the timeouts, but somebody should really know what they are about and why. Please add the board : ProArt X570-CREATOR WIFI to the list of affected and the asus-wmi patch. I believe ROG STRIX Z590-E GAMING WIFI to be impacted as well Please add also Asus z390 rog strix f-gaming. [ 3.685656] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [ 3.685747] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20190816/utaddress-204) [ 3.685750] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver (In reply to Jarkko Korpi from comment #146) > Please add also Asus z390 rog strix f-gaming. > > [ 3.685656] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > [ 3.685747] ACPI Warning: SystemIO range > 0x0000000000000295-0x0000000000000296 conflicts with OpRegion > 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20190816/utaddress-204) > [ 3.685750] ACPI: If an ACPI driver is available for this device, you > should use it instead of the native driver Have you tried to run https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-next with added your board to list? Could you also share exact name of board from /sys/class/dmi/id/board_name? cat /sys/class/dmi/id/board_name ROG STRIX Z390-F GAMING no I haven'y tried the patch. My ancient MAXIMUS VII HERO (NCT6791D) suffers from this bug as well. I added the board name to asus_wmi_boards, but this is what I get: [ 3.131718] nct6775: Using Asus WMI to access 0x0 chip. [ 3.131742] nct6775: Enabling hardware monitor logical device mappings. [ 3.131750] nct6775: Found NCT6791D or compatible chip at 0x2e:0x290 nct6791-isa-0290 Adapter: ISA adapter Vcore: 0.00 V (min = +0.00 V, max = +0.00 V) in1: 0.00 V (min = +0.00 V, max = +0.00 V) AVCC: 0.00 V (min = +0.00 V, max = +0.00 V) +3.3V: 0.00 V (min = +0.00 V, max = +0.00 V) in4: 0.00 V (min = +0.00 V, max = +0.00 V) in5: 0.00 V (min = +0.00 V, max = +0.00 V) in6: 0.00 V (min = +0.00 V, max = +0.00 V) 3VSB: 0.00 V (min = +0.00 V, max = +0.00 V) Vbat: 0.00 V (min = +0.00 V, max = +0.00 V) in9: 0.00 V (min = +0.00 V, max = +0.00 V) in10: 0.00 V (min = +0.00 V, max = +0.00 V) in11: 0.00 V (min = +0.00 V, max = +0.00 V) in12: 0.00 V (min = +0.00 V, max = +0.00 V) in13: 0.00 V (min = +0.00 V, max = +0.00 V) in14: 0.00 V (min = +0.00 V, max = +0.00 V) fan1: 0 RPM (min = 0 RPM) fan2: 0 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +0.0°C (high = +0.0°C, hyst = +0.0°C) sensor = thermistor CPUTIN: +0.0°C (high = +0.0°C, hyst = +0.0°C) sensor = thermistor AUXTIN0: +0.0°C sensor = thermistor AUXTIN1: +0.0°C sensor = thermistor AUXTIN2: +0.0°C sensor = thermistor AUXTIN3: +0.0°C sensor = thermistor PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C PCH_MCH_TEMP: +0.0°C intrusion0: OK intrusion1: OK beep_enable: disabled Any idea? (In reply to Olli Asikainen from comment #149) > My ancient MAXIMUS VII HERO (NCT6791D) suffers from this bug as well. > > I added the board name to asus_wmi_boards, but this is what I get: ... > Any idea? Please share your DSDT ACPI table (/sys/firmware/acpi/tables/DSDT or acpidump -b -n DSDT). Created attachment 299459 [details]
acpidump -b -n DSDT
(In reply to Olli Asikainen from comment #151) > Created attachment 299459 [details] > acpidump -b -n DSDT This motherboard has totally different firmware, neither like the ones supported by Denis patch, nor those supported by the asus-wmi-sensors driver. Yeah, it's old and suffers from the same bug, but I reckon supporting this would be a completely different story. Thanks for your answer Eugene and sorry for the noise. (In reply to Olli Asikainen from comment #153) > Yeah, it's old and suffers from the same bug, but I reckon supporting this > would be a completely different story. Thanks for your answer Eugene and > sorry for the noise. This firmware seem to be using ACPI mutex named \_SB_.PCI0.LPCB.SIO1.MUT0 to guard access to the nct chip registers. I wonder, can we rely on these mutexes, whose names seem to be quite stable, as well, instead of the WMI functions? Then accessing nct registers would become simpler: lock ACPI mutex if needed, access registers always in the regular way, unlock the mutex. Couldn't you have a nct6775.force_wmi parameter or something, a bit like i915 has force_probe? So people can at least see if (and use in the meantime) their motherboard is supported on their independent own. Created attachment 299483 [details] Check MAXIMUS_VII_HERO by lock mutex directly (In reply to Olli Asikainen from comment #151) > Created attachment 299459 [details] > acpidump -b -n DSDT Could you check with updated patch? It has only nct6798d part and only for check idea. As I see by your logs and dsdt - all call returned just zero and DSDT does not have RSIO/WRIO methods. Could you please check with patch? (In reply to Eugene Shalygin from comment #154) > (In reply to Olli Asikainen from comment #153) > > Yeah, it's old and suffers from the same bug, but I reckon supporting this > > would be a completely different story. Thanks for your answer Eugene and > > sorry for the noise. > > This firmware seem to be using ACPI mutex named \_SB_.PCI0.LPCB.SIO1.MUT0 to > guard access to the nct chip registers. > > I wonder, can we rely on these mutexes, whose names seem to be quite stable, > as well, instead of the WMI functions? Then accessing nct registers would > become simpler: lock ACPI mutex if needed, access registers always in the > regular way, unlock the mutex. It looks as different for different boards, B550-E uses "\\_SB.PCI0.SBRG.SIO1.MUT0" as mutex name. if someone provides a patch for ROG STRIX Z390-F GAMING I am willing to give it a try against up to date Linu's git tree. where exactly I find this new patch from sudo make menuconfig? (In reply to Denis Pauk from comment #159) > Created attachment 299483 [details] > Check MAXIMUS_VII_HERO by lock mutex directly > > (In reply to Olli Asikainen from comment #151) > > Created attachment 299459 [details] > > acpidump -b -n DSDT > > Could you check with updated patch? It has only nct6798d part and only for > check idea. It works! (as far as I can tell) [ 5.109607] nct6775: Using Asus WMI mutex. [ 5.109633] nct6775: Enabling hardware monitor logical device mappings. [ 5.109641] nct6775: Found NCT6791D or compatible chip at 0x2e:0x290 nct6791-isa-0290 Adapter: ISA adapter Vcore: 928.00 mV (min = +0.00 V, max = +1.74 V) in1: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM AVCC: 3.31 V (min = +2.98 V, max = +3.63 V) +3.3V: 3.31 V (min = +2.98 V, max = +3.63 V) in4: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in5: 1.94 V (min = +0.00 V, max = +0.00 V) ALARM in6: 0.00 V (min = +0.00 V, max = +0.00 V) 3VSB: 3.42 V (min = +2.98 V, max = +3.63 V) Vbat: 3.30 V (min = +2.70 V, max = +3.63 V) in9: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM in10: 0.00 V (min = +0.00 V, max = +0.00 V) in11: 936.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 0.00 V (min = +0.00 V, max = +0.00 V) in13: 8.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 8.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 0 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) fan6: 0 RPM (min = 0 RPM) SYSTIN: +28.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor CPUTIN: +30.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: -128.0°C sensor = thermistor AUXTIN1: -128.0°C sensor = thermistor AUXTIN2: +29.0°C sensor = thermistor AUXTIN3: +127.0°C sensor = thermistor PECI Agent 0: +30.0°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled Created attachment 299517 [details] Rebased patch with all asus_* drivers and i2c 11.11.2021 Patch rebased over https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tag/?h=hwmon-for-v5.16 tag. Could someone also check i2c adapter? It should work for all boards with direct access to NCT67xx or with known acpi mutex name and available for: "PRIME B450M-GAMING", "PRIME X370-PRO", "PRIME X399-A", "PRIME X470-PRO", "PRIME Z270-A", "PRIME Z370-A", "ROG CROSSHAIR VI HERO", "ROG STRIX B350-F GAMING", "ROG STRIX B450-F GAMING", "ROG STRIX X399-E GAMING", "ROG STRIX Z270-E", "ROG STRIX Z370-E", "ROG STRIX Z490-E GAMING", "TUF B450 PLUS GAMING", As: --- cat /sys/bus/i2c/devices/i2c-8/name SMBus NCT67xx adapter at 0295 --- i2c bus can be checked by: --- modprobe i2c-dev i2cdetect 8 --- I2c adapter code is based on patch from OpenRGB repository. Created attachment 299519 [details] attachment-16225-0.html Another board to add: Product Name: PRIME B550M-A (WI-FI) [ 105.876155] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 On Thu, 11 Nov 2021 at 11:36, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=204807 > > Denis Pauk (pauk.denis@gmail.com) changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Attachment #299483 [details]|0 |1 > is obsolete| | > > --- Comment #163 from Denis Pauk (pauk.denis@gmail.com) --- > Created attachment 299517 [details] > --> https://bugzilla.kernel.org/attachment.cgi?id=299517&action=edit > Rebased patch with all asus_* drivers and i2c 11.11.2021 > > Patch rebased over > > > https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tag/?h=hwmon-for-v5.16 > tag. > > Could someone also check i2c adapter? It should work for all boards with > direct > access to NCT67xx or with known acpi mutex name and available for: > "PRIME B450M-GAMING", > "PRIME X370-PRO", > "PRIME X399-A", > "PRIME X470-PRO", > "PRIME Z270-A", > "PRIME Z370-A", > "ROG CROSSHAIR VI HERO", > "ROG STRIX B350-F GAMING", > "ROG STRIX B450-F GAMING", > "ROG STRIX X399-E GAMING", > "ROG STRIX Z270-E", > "ROG STRIX Z370-E", > "ROG STRIX Z490-E GAMING", > "TUF B450 PLUS GAMING", > > As: > --- > cat /sys/bus/i2c/devices/i2c-8/name > SMBus NCT67xx adapter at 0295 > --- > > i2c bus can be checked by: > --- > modprobe i2c-dev > i2cdetect 8 > --- > > I2c adapter code is based on patch from OpenRGB repository. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug. > > (In reply to Joel Wirāmu from comment #164) > Another board to add: > Product Name: PRIME B550M-A (WI-FI) > [ 105.876155] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > I will add as part of next patch. (In reply to Denis Pauk from comment #163) > Created attachment 299517 [details] > Rebased patch with all asus_* drivers and i2c 11.11.2021 Thank you Denis! A small correction for MAXIMUS VII HERO, the board name is actually "MAXIMUS VII HERO" not "ROG MAXIMUS VII HERO". Created attachment 299537 [details] Rebased patch with fixed board names 11.11.2021 (In reply to Olli Asikainen from comment #167) > (In reply to Denis Pauk from comment #163) > > Created attachment 299517 [details] > > Rebased patch with all asus_* drivers and i2c 11.11.2021 > > Thank you Denis! > > A small correction for MAXIMUS VII HERO, the board name is actually "MAXIMUS > VII HERO" not "ROG MAXIMUS VII HERO". Could you check? (In reply to Joel Wirāmu from comment #164) > Created attachment 299519 [details] > attachment-16225-0.html > > Another board to add: > Product Name: PRIME B550M-A (WI-FI) > [ 105.876155] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > Could you check? (In reply to Eugene Shalygin from comment #168) > (In reply to Denis Pauk from comment #165) > > > Maybe we can have asus_wmi_info_table from patch in #163 as shared file > with > > description of preferred method for access, acpi mutext name, devices on > i2c > > bus, ec register address to sensor type. What do you think? > > My idea was that the mutex for the state lock can be either the regular > mutex or the ACPI mutex, there is no need to lock both of them > simultaneously. So that the module can return a structure with the mutex > (ACPI one if known for the given hardware or the regular one) and functions > to lock and unlock it. I just thought that would make logic in the actual > sensor modules (nct or ec) simpler. Could you look to nct6775_data:{un}lock? Do you mean something like it? (In reply to Andy Shevchenko from comment #157) > (In reply to Eugene Shalygin from comment #156) > > (In reply to Andy Shevchenko from comment #155) > > > > I use acpi_acquire_mutex()/acpi_release_mutex() for the ASUS EC sensors > > driver > > (https://github.com/zeule/asus-ec-sensors/blob/master/asus-ec-sensors. > > c#L417), but there seem to be no other users of these function inside the > > kernel sources (checked 5.15.0) > > Looks legit. Object is passed by handle:path. Could we enable create i2c adapter for all direct access cases? Connected devices(RGB leds?) should be in safe conditions by default without read/write by this adapter and code reuses same lock as monitoring code. What do you think? Hello Guys, uname -a Linux 5.16.0-0.rc1.20211115git8ab774587903.14.vanilla.1.fc35.x86_64 #1 SMP PREEMPT Tue Nov 16 12:36:08 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux sensors nct6798-isa-0290 Adapter: ISA adapter in0: 1.20 V (min = +0.00 V, max = +1.74 V) fan1: 883 RPM (min = 0 RPM) fan2: 596 RPM (min = 0 RPM) fan3: 820 RPM (min = 0 RPM) fan6: 1081 RPM (min = 0 RPM) SYSTIN: +31.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +37.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +26.0°C sensor = thermistor AUXTIN1: +127.0°C sensor = thermistor AUXTIN2: +109.0°C sensor = thermistor AUXTIN3: +23.0°C sensor = thermistor PECI Agent 0 Calibration: +37.5°C [...] Thanks a lot everyone ! Special though to Denis and everyone contributing. Regards, Gregory. Created attachment 299757 [details] Rebased patch with i2c v5.15 28.11.2021 Code have sent as part of https://lkml.org/lkml/2021/11/28/225 + i2c. (In reply to Denis Pauk from comment #173) > Created attachment 299757 [details] > Rebased patch with i2c v5.15 28.11.2021 > > Code have sent as part of https://lkml.org/lkml/2021/11/28/225 + i2c. I see that my M/B "ROG STRIX X570-I GAMING" not listed in patch. And yes I checked patch and can confirm that CPU FAN sensor monitoring still absent for my M/B with this patch. (In reply to Mikhail from comment #174) > (In reply to Denis Pauk from comment #173) > > Created attachment 299757 [details] > > Rebased patch with i2c v5.15 28.11.2021 > > > > Code have sent as part of https://lkml.org/lkml/2021/11/28/225 + i2c. > > I see that my M/B "ROG STRIX X570-I GAMING" not listed in patch. And yes I > checked patch and can confirm that CPU FAN sensor monitoring still absent > for my M/B with this patch. What do you mean by missing "CPU FAN"? It has returned zero or does not exist in listing? It case it has returned zero, could you attach result of "acpidump -b -n DSDT" ? > What do you mean by missing "CPU FAN"? It has returned zero or does not exist > in listing? It has returned always zero even before your patch. $ sensors hidpp_battery_0-hid-3-10 Adapter: HID adapter in0: 3.80 V amdgpu-pci-0b00 Adapter: PCI adapter vddgfx: 775.00 mV fan1: 0 RPM (min = 0 RPM, max = 3300 RPM) edge: +52.0°C (crit = +100.0°C, hyst = -273.1°C) (emerg = +105.0°C) junction: +55.0°C (crit = +110.0°C, hyst = -273.1°C) (emerg = +115.0°C) mem: +54.0°C (crit = +100.0°C, hyst = -273.1°C) (emerg = +105.0°C) power1: 22.00 W (cap = 255.00 W) nvme-pci-0100 Adapter: PCI adapter Composite: +50.9°C iwlwifi_1-virtual-0 Adapter: Virtual device temp1: +54.0°C k10temp-pci-00c3 Adapter: PCI adapter Tctl: +76.6°C Tccd1: +71.0°C Tccd2: +74.5°C ucsi_source_psy_0_00081-i2c-0-08 Adapter: Synopsys DesignWare I2C adapter in0: 0.00 V (min = +0.00 V, max = +0.00 V) curr1: 0.00 A (max = +0.00 A) > It case it has returned zero, could you attach result of "acpidump -b -n > DSDT" ? [mikhail@primary-ws ~]$ sudo acpidump -b -n DSDT [mikhail@primary-ws ~]$ Oh sorry it does not exist I looked at the GPU sensors by mistake. (In reply to Mikhail from comment #176) > > What do you mean by missing "CPU FAN"? It has returned zero or does not > exist > > in listing? > > It has returned always zero even before your patch. > > > $ sensors > hidpp_battery_0-hid-3-10 > Adapter: HID adapter > in0: 3.80 V > > amdgpu-pci-0b00 > Adapter: PCI adapter > vddgfx: 775.00 mV > fan1: 0 RPM (min = 0 RPM, max = 3300 RPM) > edge: +52.0°C (crit = +100.0°C, hyst = -273.1°C) > (emerg = +105.0°C) > junction: +55.0°C (crit = +110.0°C, hyst = -273.1°C) > (emerg = +115.0°C) > mem: +54.0°C (crit = +100.0°C, hyst = -273.1°C) > (emerg = +105.0°C) > power1: 22.00 W (cap = 255.00 W) > > nvme-pci-0100 > Adapter: PCI adapter > Composite: +50.9°C > > iwlwifi_1-virtual-0 > Adapter: Virtual device > temp1: +54.0°C > > k10temp-pci-00c3 > Adapter: PCI adapter > Tctl: +76.6°C > Tccd1: +71.0°C > Tccd2: +74.5°C > > ucsi_source_psy_0_00081-i2c-0-08 > Adapter: Synopsys DesignWare I2C adapter > in0: 0.00 V (min = +0.00 V, max = +0.00 V) > curr1: 0.00 A (max = +0.00 A) > > What do you have in dmesg when you load driver? > > It case it has returned zero, could you attach result of "acpidump -b -n > > DSDT" ? > > [mikhail@primary-ws ~]$ sudo acpidump -b -n DSDT > [mikhail@primary-ws ~]$ acpidump should create binary dump of DSDT section(dsdt.dat) of your board, could you attach it here? Created attachment 299883 [details] dsdt.dat (ROG STRIX X570-I GAMING) > acpidump should create binary dump of DSDT section(dsdt.dat) of your board, > could you attach it here? > What do you have in dmesg when you load driver?
[11492.230845] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[11492.230925] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210930/utaddress-204)
[11492.230937] ACPI: OSL: Resource conflict; ACPI support missing from driver?
Created attachment 299887 [details] Add X570-I mutex Could you check with updated patch? (In reply to Mikhail from comment #179) > Created attachment 299883 [details] > dsdt.dat (ROG STRIX X570-I GAMING) > > > acpidump should create binary dump of DSDT section(dsdt.dat) of your board, > > could you attach it here? Created attachment 299891 [details]
dsdt dump p8z68-v lx
Created attachment 299893 [details]
dmesg p8z68-v lx
No changes with the latest patch on old ASUS P8Z68-V LX. (sorry for post spamming, newbie here) Kernel 5.15.2 Manjaro. Attached DSDT dump and dmesg. [ 11.103782] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290 [ 11.103790] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWRE) (20210730/utaddress-204) (In reply to Denis Pauk from comment #181) > Created attachment 299887 [details] > Add X570-I mutex > > Could you check with updated patch? This patch is suitable for 5.16 rc3 right? Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] 1 out of 1 hunk ignored -- saving rejects to file drivers/hwmon/Kconfig.rej 73 out of 83 hunks FAILED -- saving rejects to file drivers/hwmon/nct6775.c.rej error: Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep) Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep) (In reply to Mikhail from comment #185) > (In reply to Denis Pauk from comment #181) > > Created attachment 299887 [details] > > Add X570-I mutex > > > > Could you check with updated patch? > > This patch is suitable for 5.16 rc3 right? > > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored -- saving rejects to file drivers/hwmon/Kconfig.rej > 73 out of 83 hunks FAILED -- saving rejects to file > drivers/hwmon/nct6775.c.rej > error: Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep) > Bad exit status from /var/tmp/rpm-tmp.HxCCT9 (%prep) Patch is based on stable v5.15 kernel version. Could you check with v5.15 kernel version from kernel.org. (In reply to Vladdrako from comment #184) > No changes with the latest patch on old ASUS P8Z68-V LX. (sorry for post > spamming, newbie here) Kernel 5.15.2 Manjaro. > Attached DSDT dump and dmesg. > > [ 11.103782] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290 > [ 11.103790] ACPI Warning: SystemIO range > 0x0000000000000295-0x0000000000000296 conflicts with OpRegion > 0x0000000000000290-0x0000000000000299 (\_GPE.HWRE) (20210730/utaddress-204) P8Z68-V is not in the list of supported boards, could you try add it to the list (asus_wmi_info_table)? If it does not help, could you attach dump of your bios? (acpidump -b -n DSDT). I assume that bios does not support WMI methods from that patch and need to search fully different workaround. (In reply to Denis Pauk from comment #186) > Patch is based on stable v5.15 kernel version. Could you check with v5.15 > kernel version from kernel.org. > Hmmm... Depmod failure depmod: WARNING: /builddir/build/BUILDROOT/kernel-5.15.6-200.fc35.x86_64/./lib/modules/5.15.6-200.fc35.x86_64+debug/kernel/drivers/hwmon/nct6775.ko needs unknown symbol wmi_evaluate_method > P8Z68-V is not in the list of supported boards, could you try add it to the > list (asus_wmi_info_table)? Added DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX", NULL), Nothing changed. > If it does not help, could you attach dump of your bios? (acpidump -b -n > DSDT). I assume that bios does not support WMI methods from that patch and > need to search fully different workaround. Here dump from CH341A https://www.upload.ee/files/13692045/P8Z68-V_LX.Bin.html Probably not the best place to put this, but I can confirm that this patch appears to work on my new ASUS motherboard after updating the asus_wmi_boards table with its board name ("ROG STRIX B550-A GAMING" - it's just a B550-F with a different color scheme).
Created attachment 299921 [details] Photo of FANs indication in BIOS (ROG STRIX X570-I GAMING) ( (In reply to Denis Pauk from comment #186) > Patch is based on stable v5.15 kernel version. Could you check with v5.15 > kernel version from kernel.org. Thanks, I beginning see CPU FAN RPM. $ sensors iwlwifi_1-virtual-0 Adapter: Virtual device temp1: +55.0°C amdgpu-pci-0b00 Adapter: PCI adapter vddgfx: 775.00 mV fan1: 0 RPM (min = 0 RPM, max = 3300 RPM) edge: +52.0°C (crit = +100.0°C, hyst = -273.1°C) (emerg = +105.0°C) junction: +54.0°C (crit = +110.0°C, hyst = -273.1°C) (emerg = +115.0°C) mem: +56.0°C (crit = +100.0°C, hyst = -273.1°C) (emerg = +105.0°C) power1: 15.00 W (cap = 255.00 W) nvme-pci-0100 Adapter: PCI adapter Composite: +52.9°C hidpp_battery_0-hid-3-9 Adapter: HID adapter in0: 4.06 V nct6798-isa-0290 Adapter: ISA adapter in0: 976.00 mV (min = +0.00 V, max = +1.74 V) in1: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in2: 3.41 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.36 V (min = +0.00 V, max = +0.00 V) ALARM in4: 992.00 mV (min = +0.00 V, max = +0.00 V) ALARM in5: 656.00 mV (min = +0.00 V, max = +0.00 V) ALARM in6: 424.00 mV (min = +0.00 V, max = +0.00 V) ALARM in7: 3.41 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.36 V (min = +0.00 V, max = +0.00 V) ALARM in9: 912.00 mV (min = +0.00 V, max = +0.00 V) ALARM in10: 328.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 544.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 1.04 V (min = +0.00 V, max = +0.00 V) ALARM in13: 464.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 368.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 847 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +46.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +48.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +66.5°C sensor = thermistor AUXTIN1: +46.0°C sensor = thermistor AUXTIN2: +21.0°C sensor = thermistor AUXTIN3: +67.0°C sensor = thermistor PECI Agent 0 Calibration: +53.0°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled k10temp-pci-00c3 Adapter: PCI adapter Tctl: +63.4°C Tccd1: +53.8°C Tccd2: +48.0°C ucsi_source_psy_0_00081-i2c-0-08 Adapter: Synopsys DesignWare I2C adapter in0: 0.00 V (min = +0.00 V, max = +0.00 V) curr1: 0.00 A (max = +0.00 A) For unknown reason RPM of PCH FAN and RPM of HS FAN which displayed in BIOS didn't reading by driver. It's normal? (In reply to Mikhail from comment #190) > For unknown reason RPM of PCH FAN and RPM of HS FAN which displayed in BIOS > didn't reading by driver. It's normal? That's because those sensors are read from another chip, the ACPI EC. You need to add your board to either asus_emi_ec_sensors driver in kernel 5.16 or to not yet mainlined new iteration of that driver which is still at Github [1]. That should be pretty straightforward now for your board. [1] https://github.com/zeule/asus-ec-sensors (In reply to Vladdrako from comment #184) > No changes with the latest patch on old ASUS P8Z68-V LX. (sorry for post > spamming, newbie here) Kernel 5.15.2 Manjaro. > Attached DSDT dump and dmesg. (In reply to Vladdrako from comment #188) > > P8Z68-V is not in the list of supported boards, could you try add it to the > > list (asus_wmi_info_table)? > > Added DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX", NULL), > Nothing changed. > I am afraid "P8Z68-V LX" will be unsupported. I don't see any Acquire locks in your dsdl related to 0x0290 region and all calls made direct operations with superio chip. You can try with DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX", &acpi_board_LPCB_MUTEX), But I am not sure that it will lock correct mutex or be safe. @Eugene Shalygin Could you correct me if I have missed something? (In reply to Denis Pauk from comment #192) > You can try with DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V > LX", &acpi_board_LPCB_MUTEX), But I am not sure that it will lock correct > mutex or be safe. drivers/hwmon/nct6775.c:5443:56: error: «acpi_board_LPCB_MUTEX» undeclared here (not in a function) 5443 | DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX", &acpi_board_LPCB_MUTEX), | ^~~~~~~~~~~~~~~~~~~~~ drivers/hwmon/nct6775.c:5411:24: note: in expansion of macro «DMI_EXACT_MATCH_ASUS_BOARD_NAME» 5411 | .driver_data = info, \ | ^~~~ Created attachment 299975 [details] Add support for access via Asus WMI to nct6775 (2021.12.09) (In reply to Vladdrako from comment #193) > (In reply to Denis Pauk from comment #192) > > You can try with DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V > > LX", &acpi_board_LPCB_MUTEX), But I am not sure that it will lock correct > > mutex or be safe. > > drivers/hwmon/nct6775.c:5443:56: error: «acpi_board_LPCB_MUTEX» undeclared > here (not in a function) > 5443 | DMI_EXACT_MATCH_ASUS_BOARD_NAME("P8Z68-V LX", > &acpi_board_LPCB_MUTEX), > | > ^~~~~~~~~~~~~~~~~~~~~ > drivers/hwmon/nct6775.c:5411:24: note: in expansion of macro > «DMI_EXACT_MATCH_ASUS_BOARD_NAME» > 5411 | .driver_data = info, > \ > | ^~~~ Could you check with updated patch? (In reply to Denis Pauk from comment #194) > Could you check with updated patch? Unfortunately, it didn't help :( I've been using the oct 10th version of this patch on 5.15 manjaro for a few weeks without issues. Amazing work by Denis and everyone else involved! I was just wondering if the patch is included in the 5.16 kernel or does it still need to be patched manually? (In reply to Denis Pauk from comment #192) > @Eugene Shalygin Could you correct me if I have missed something? Isn't the \_SB_.PCI0.LPCB.SIO1.MUT0 mutex, referenced by \_SB_.PCI0.LPCB.SIO1.ENFG() / \_SB_.PCI0.LPCB.SIO1.EXFG(), the one we are looking for? @Denis Pauk
Fixed by replacing DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."), \ -> "ASUSTeK Computer INC."
sudo dmidecode -t 2
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.6 present.
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: P8Z68-V LX
Version: Rev X.0x
Serial Number: MB-1234567890
Asset Tag: To be filled by O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
sudo dmesg | grep ACPI
[sudo] пароль для vladdrako:
[ 0.000000] ACPI: OSL: Static SSDT installation disabled
[ 0.000000] BIOS-e820: [mem 0x00000000ce941000-0x00000000ceb94fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000ceb95000-0x00000000ceba1fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000ceba2000-0x00000000cebc0fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000cebc1000-0x00000000cebc5fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000cebc6000-0x00000000cec08fff] ACPI NVS
[ 0.000000] efi: ACPI=0xceb95000 ACPI 2.0=0xceb95000 SMBIOS=0xce425f98
[ 0.012426] ACPI: SSDT ACPI table found in initrd [kernel/firmware/acpi/ssdt1.aml][0x414]
[ 0.012430] ACPI: SSDT ACPI table found in initrd [kernel/firmware/acpi/ssdt2.aml][0xb05]
[ 0.012432] ACPI: SSDT ACPI table found in initrd [kernel/firmware/acpi/ssdt3.aml][0x2f4]
[ 0.012434] ACPI: SSDT ACPI table found in initrd [kernel/firmware/acpi/ssdt4.aml][0x87b]
[ 0.012436] ACPI: SSDT ACPI table found in initrd [kernel/firmware/acpi/ssdt5.aml][0x3aa]
[ 0.012438] ACPI: SSDT ACPI table found in initrd [kernel/firmware/acpi/ssdt6.aml][0x18a]
[ 0.012439] ACPI: SSDT ACPI table found in initrd [kernel/firmware/acpi/ssdt7.aml][0x18a]
[ 0.012460] modified: [mem 0x00000000ce14e000-0x00000000ce150145] ACPI data
[ 0.012470] modified: [mem 0x00000000ce941000-0x00000000ceb94fff] ACPI NVS
[ 0.012472] modified: [mem 0x00000000ceb95000-0x00000000ceba1fff] ACPI data
[ 0.012473] modified: [mem 0x00000000ceba2000-0x00000000cebc0fff] ACPI NVS
[ 0.012475] modified: [mem 0x00000000cebc1000-0x00000000cebc5fff] ACPI data
[ 0.012476] modified: [mem 0x00000000cebc6000-0x00000000cec08fff] ACPI NVS
[ 0.012497] ACPI: Early table checksum verification disabled
[ 0.012500] ACPI: RSDP 0x00000000CEB95000 000024 (v02 ALASKA)
[ 0.012503] ACPI: XSDT 0x00000000CEB95078 00006C (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.012512] ACPI: FACP 0x00000000CEB9F930 0000F4 (v04 ALASKA A M I 01072009 AMI 00010013)
[ 0.012520] ACPI: DSDT 0x00000000CEB95180 00A7B0 (v02 ALASKA A M I 00000015 INTL 20051117)
[ 0.012525] ACPI: FACS 0x00000000CEBBFF80 000040
[ 0.012530] ACPI: APIC 0x00000000CEB9FA28 000072 (v03 ALASKA A M I 01072009 AMI 00010013)
[ 0.012536] ACPI: MCFG 0x00000000CEB9FAA0 00003C (v01 ALASKA A M I 01072009 MSFT 00000097)
[ 0.012541] ACPI: HPET 0x00000000CEB9FAE0 000038 (v01 ALASKA A M I 01072009 AMI. 00000005)
[ 0.012544] ACPI: Ignoring installation of SSDT at 00000000CEB9FB18
[ 0.012546] ACPI: Ignoring installation of SSDT at 00000000CEB9FE88
[ 0.012548] ACPI: Ignoring installation of SSDT at 00000000CEBA0838
[ 0.012553] ACPI: DMAR 0x00000000CEBA12D0 0000A8 (v01 INTEL SNB 00000001 INTL 00000001)
[ 0.012558] ACPI: BGRT 0x00000000CEBA13D0 000038 (v00 ALASKA A M I 01072009 AMI 00010013)
[ 0.012561] ACPI: Reserving FACP table memory at [mem 0xceb9f930-0xceb9fa23]
[ 0.012562] ACPI: Reserving DSDT table memory at [mem 0xceb95180-0xceb9f92f]
[ 0.012563] ACPI: Reserving FACS table memory at [mem 0xcebbff80-0xcebbffbf]
[ 0.012564] ACPI: Reserving APIC table memory at [mem 0xceb9fa28-0xceb9fa99]
[ 0.012565] ACPI: Reserving MCFG table memory at [mem 0xceb9faa0-0xceb9fadb]
[ 0.012566] ACPI: Reserving HPET table memory at [mem 0xceb9fae0-0xceb9fb17]
[ 0.012567] ACPI: Reserving DMAR table memory at [mem 0xceba12d0-0xceba1377]
[ 0.012568] ACPI: Reserving BGRT table memory at [mem 0xceba13d0-0xceba1407]
[ 0.012572] ACPI: Table Upgrade: install [SSDT- PmRef- Cpu0Ist]
[ 0.012574] ACPI: Ignoring installation of SSDT at 00000000CE14E000
[ 0.012576] ACPI: Table Upgrade: install [SSDT- PmRef- CpuPm]
[ 0.012577] ACPI: Ignoring installation of SSDT at 00000000CE14E414
[ 0.012579] ACPI: Table Upgrade: install [SSDT-SataRe-SataTabl]
[ 0.012581] ACPI: Ignoring installation of SSDT at 00000000CE14EF19
[ 0.012582] ACPI: Table Upgrade: install [SSDT- PmRef- Cpu0Cst]
[ 0.012584] ACPI: Ignoring installation of SSDT at 00000000CE14F20D
[ 0.012585] ACPI: Table Upgrade: install [SSDT- PmRef- ApIst]
[ 0.012587] ACPI: Ignoring installation of SSDT at 00000000CE14FA88
[ 0.012589] ACPI: Table Upgrade: install [SSDT- PmRef- ApCst]
[ 0.012590] ACPI: Ignoring installation of SSDT at 00000000CE14FE32
[ 0.012592] ACPI: Table Upgrade: install [SSDT- PmRef- ApCst]
[ 0.012593] ACPI: Ignoring installation of SSDT at 00000000CE14FFBC
[ 0.042572] ACPI: PM-Timer IO Port: 0x408
[ 0.042580] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[ 0.042594] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.042595] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.042599] ACPI: Using ACPI (MADT) for SMP configuration information
[ 0.042600] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.122119] ACPI: Core revision 20210730
[ 0.166568] ACPI: PM: Registering ACPI NVS region [mem 0xce941000-0xceb94fff] (2441216 bytes)
[ 0.166568] ACPI: PM: Registering ACPI NVS region [mem 0xceba2000-0xcebc0fff] (126976 bytes)
[ 0.166568] ACPI: PM: Registering ACPI NVS region [mem 0xcebc6000-0xcec08fff] (274432 bytes)
[ 0.166581] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.166581] ACPI: bus type PCI registered
[ 0.166581] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.169728] ACPI: Added _OSI(Module Device)
[ 0.169728] ACPI: Added _OSI(Processor Device)
[ 0.169728] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.169728] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.169728] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.169728] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.169728] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.177081] ACPI: 1 ACPI AML tables successfully acquired and loaded
[ 0.178274] ACPI: EC: EC started
[ 0.178275] ACPI: EC: interrupt blocked
[ 0.178279] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
[ 0.178281] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC used to handle transactions
[ 0.178283] ACPI: Interpreter enabled
[ 0.178298] ACPI: PM: (supports S0 S5)
[ 0.178299] ACPI: Using IOAPIC for interrupt routing
[ 0.178330] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.178545] ACPI: Enabled 10 GPEs in block 00 to 3F
[ 0.185721] ACPI: PM: Power Resource [FN00]
[ 0.185797] ACPI: PM: Power Resource [FN01]
[ 0.185874] ACPI: PM: Power Resource [FN02]
[ 0.185948] ACPI: PM: Power Resource [FN03]
[ 0.186023] ACPI: PM: Power Resource [FN04]
[ 0.186715] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
[ 0.193940] ACPI: PCI: Interrupt link LNKA configured for IRQ 11
[ 0.194009] ACPI: PCI: Interrupt link LNKB configured for IRQ 3
[ 0.194076] ACPI: PCI: Interrupt link LNKC configured for IRQ 4
[ 0.194143] ACPI: PCI: Interrupt link LNKD configured for IRQ 5
[ 0.194209] ACPI: PCI: Interrupt link LNKE configured for IRQ 0
[ 0.194210] ACPI: PCI: Interrupt link LNKE disabled
[ 0.194276] ACPI: PCI: Interrupt link LNKF configured for IRQ 10
[ 0.194342] ACPI: PCI: Interrupt link LNKG configured for IRQ 0
[ 0.194343] ACPI: PCI: Interrupt link LNKG disabled
[ 0.194409] ACPI: PCI: Interrupt link LNKH configured for IRQ 11
[ 0.194710] ACPI: EC: interrupt unblocked
[ 0.194711] ACPI: EC: event unblocked
[ 0.194716] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
[ 0.194717] ACPI: EC: GPE=0x18
[ 0.194719] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC initialization complete
[ 0.194720] ACPI: \_SB_.PCI0.LPCB.EC0_: EC: Used to handle transactions and events
[ 0.194782] ACPI: bus type USB registered
[ 0.194782] PCI: Using ACPI for IRQ routing
[ 0.207295] pnp: PnP ACPI init
[ 0.208360] pnp: PnP ACPI: found 8 devices
[ 0.378928] ACPI: button: Power Button [PWRB]
[ 0.379132] ACPI: button: Power Button [PWRF]
[ 0.379837] ACPI: thermal: Thermal Zone [TZ00] (28 C)
[ 0.380112] ACPI: thermal: Thermal Zone [TZ01] (30 C)
[ 5.069363] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20210730/utaddress-204)
[ 5.069371] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 5.069374] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[ 5.069377] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 5.069378] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[ 5.069381] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 5.069382] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000050F (\_GPE.GPIO) (20210730/utaddress-204)
[ 5.069384] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[ 5.069386] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 11.270149] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no)
sudo dmesg | grep nct6775
[ 6.082896] nct6775: Can't read chip ID by Asus WMI.
[ 6.083246] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0
[ 6.083277] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[ 6.083315] nct6775: i2c have not found
sensors ✔
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +38.0°C (high = +80.0°C, crit = +99.0°C)
Core 0: +38.0°C (high = +80.0°C, crit = +99.0°C)
Core 1: +37.0°C (high = +80.0°C, crit = +99.0°C)
Core 2: +37.0°C (high = +80.0°C, crit = +99.0°C)
Core 3: +31.0°C (high = +80.0°C, crit = +99.0°C)
nct6776-isa-0290
Adapter: ISA adapter
Vcore: 944.00 mV (min = +0.00 V, max = +1.74 V)
in1: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
AVCC: 3.41 V (min = +2.98 V, max = +3.63 V)
+3.3V: 3.41 V (min = +2.98 V, max = +3.63 V)
in4: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM
in5: 2.04 V (min = +0.00 V, max = +0.00 V) ALARM
in6: 824.00 mV (min = +0.00 V, max = +0.00 V) ALARM
3VSB: 3.41 V (min = +2.98 V, max = +3.63 V)
Vbat: 3.38 V (min = +2.70 V, max = +3.63 V)
fan1: 0 RPM (min = 0 RPM)
fan2: 853 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
SYSTIN: +26.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor
CPUTIN: +91.0°C (high = +81.0°C, hyst = +76.0°C) sensor = thermistor
AUXTIN: +63.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
PECI Agent 0: +36.0°C (high = +80.0°C, hyst = +75.0°C)
(crit = +99.0°C)
PCH_CHIP_TEMP: +0.0°C
PCH_CPU_TEMP: +0.0°C
PCH_MCH_TEMP: +0.0°C
intrusion0: ALARM
intrusion1: ALARM
beep_enable: disabled
acpitz-acpi-0
Adapter: ACPI interface
temp1: +27.8°C (crit = +105.0°C)
temp2: +29.8°C (crit = +105.0°C)
nvme-pci-0200
Adapter: PCI adapter
Composite: +25.9°C (low = -0.1°C, high = +69.8°C)
(crit = +84.8°C)
ERROR: Can't get value of subfeature temp2_min: I/O error
ERROR: Can't get value of subfeature temp2_max: I/O error
Sensor 1: +35.9°C (low = +0.0°C, high = +0.0°C)
Now works as expected. Thanks for your work! Sadly, nobody wants to fix conflicts with lpc_ich/gpio_ich drivers, so I will blacklist them :)
Created attachment 300029 [details] Asus WMI for nct6775 v5.15 base (2021.12.14) (In reply to Vladdrako from comment #198) > @Denis Pauk > Fixed by replacing DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER > INC."), \ -> "ASUSTeK Computer INC." Could check with updated patch? (In reply to Jason Oickle from comment #196) > I've been using the oct 10th version of this patch on 5.15 manjaro for a few > weeks without issues. Amazing work by Denis and everyone else involved! > > I was just wondering if the patch is included in the 5.16 kernel or does it > still need to be patched manually? Thank you. v5.16(nct6775) will have support of: * "ProArt X570-CREATOR WIFI", * "Pro WS X570-ACE", * "PRIME B360-PLUS", * "PRIME B460-PLUS", * "PRIME X570-PRO", * "ROG CROSSHAIR VIII DARK HERO", * "ROG CROSSHAIR VIII FORMULA", * "ROG CROSSHAIR VIII HERO", * "ROG CROSSHAIR VIII IMPACT", * "ROG STRIX B550-E GAMING", * "ROG STRIX B550-F GAMING", * "ROG STRIX B550-F GAMING (WI-FI)", * "ROG STRIX B550-I GAMING", * "ROG STRIX X570-F GAMING", * "ROG STRIX Z390-E GAMING", * "ROG STRIX Z490-I GAMING", * "TUF GAMING B550M-PLUS", * "TUF GAMING B550M-PLUS (WI-FI)", * "TUF GAMING B550-PLUS", * "TUF GAMING B550-PRO", * "TUF GAMING X570-PLUS", * "TUF GAMING X570-PLUS (WI-FI)", * "TUF GAMING X570-PRO (WI-FI)", * "TUF GAMING Z490-PLUS", * "TUF GAMING Z490-PLUS (WI-FI)", v5.17(nct6775) will have support of: * "ProArt X570-CREATOR WIFI", * "Pro WS X570-ACE", * "PRIME B360-PLUS", * "PRIME B460-PLUS", * "PRIME X570-PRO", * "ROG CROSSHAIR VIII DARK HERO", * "ROG CROSSHAIR VIII FORMULA", * "ROG CROSSHAIR VIII HERO", * "ROG CROSSHAIR VIII IMPACT", * "ROG STRIX B550-E GAMING", * "ROG STRIX B550-F GAMING", * "ROG STRIX B550-F GAMING (WI-FI)", * "ROG STRIX B550-I GAMING", * "ROG STRIX X570-F GAMING", * "ROG STRIX Z390-E GAMING", * "ROG STRIX Z490-I GAMING", * "TUF GAMING B550M-PLUS", * "TUF GAMING B550M-PLUS (WI-FI)", * "TUF GAMING B550-PLUS", * "TUF GAMING B550-PRO", * "TUF GAMING X570-PLUS", * "TUF GAMING X570-PLUS (WI-FI)", * "TUF GAMING X570-PRO (WI-FI)", * "TUF GAMING Z490-PLUS", * "TUF GAMING Z490-PLUS (WI-FI)", v5.17(asus_wmi_ec_sensors) will have support of: * "PRIME X570-PRO", * "Pro WS X570-ACE", * "ROG CROSSHAIR VIII DARK HERO", * "ROG CROSSHAIR VIII FORMULA", * "ROG CROSSHAIR VIII HERO", * "ROG STRIX B550-E GAMING", * "ROG STRIX B550-I GAMING", * "ROG STRIX X570-E GAMING", v5.17(asus_wmi_sensors) will have support (board version from 2) of: * "PRIME X399-A", * "PRIME X470-PRO", * "ROG CROSSHAIR VI EXTREME", * "ROG CROSSHAIR VI HERO", * "ROG CROSSHAIR VI HERO (WI-FI AC)", * "ROG CROSSHAIR VII HERO", * "ROG CROSSHAIR VII HERO (WI-FI)", * "ROG STRIX B450-E GAMING", * "ROG STRIX B450-F GAMING", * "ROG STRIX B450-I GAMING", * "ROG STRIX X399-E GAMING", * "ROG STRIX X470-F GAMING", * "ROG STRIX X470-I GAMING", * "ROG ZENITH EXTREME", * "ROG ZENITH EXTREME ALPHA", Support of others boards is not merged/reviewed yet. (In reply to Denis Pauk from comment #199) > Could check with updated patch? Works fine. sudo dmesg | grep wmi [ 7.943237] asus_wmi: ASUS WMI generic driver loaded [ 8.052769] asus_wmi: Initialization: 0x0 [ 8.052805] asus_wmi: BIOS WMI version: 0.9 [ 8.052863] asus_wmi: SFUN value: 0x0 [ 8.052866] eeepc-wmi eeepc-wmi: Detected ASUSWMI, use DCTS [ 8.053621] input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input13 sudo dmesg | grep nct6775 [ 8.074613] nct6775: Can't read chip ID by Asus WMI. [ 8.074982] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0 [ 8.075014] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290 [ 8.075056] nct6775: i2c have not found sensors coretemp-isa-0000 Adapter: ISA adapter Package id 0: +37.0°C (high = +80.0°C, crit = +99.0°C) Core 0: +37.0°C (high = +80.0°C, crit = +99.0°C) Core 1: +36.0°C (high = +80.0°C, crit = +99.0°C) Core 2: +37.0°C (high = +80.0°C, crit = +99.0°C) Core 3: +31.0°C (high = +80.0°C, crit = +99.0°C) acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8°C (crit = +105.0°C) temp2: +29.8°C (crit = +105.0°C) nct6776-isa-0290 Adapter: ISA adapter Vcore: 944.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM AVCC: 3.41 V (min = +2.98 V, max = +3.63 V) +3.3V: 3.41 V (min = +2.98 V, max = +3.63 V) in4: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in5: 2.04 V (min = +0.00 V, max = +0.00 V) ALARM in6: 832.00 mV (min = +0.00 V, max = +0.00 V) ALARM 3VSB: 3.42 V (min = +2.98 V, max = +3.63 V) Vbat: 3.38 V (min = +2.70 V, max = +3.63 V) fan1: 0 RPM (min = 0 RPM) fan2: 856 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +27.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor CPUTIN: +91.5°C (high = +81.0°C, hyst = +76.0°C) ALARM sensor = thermistor AUXTIN: +64.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor PECI Agent 0: +36.0°C (high = +80.0°C, hyst = +75.0°C) (crit = +99.0°C) PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C PCH_MCH_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled nvme-pci-0200 Adapter: PCI adapter Composite: +25.9°C (low = -0.1°C, high = +69.8°C) (crit = +84.8°C) ERROR: Can't get value of subfeature temp2_min: I/O error ERROR: Can't get value of subfeature temp2_max: I/O error Sensor 1: +37.9°C (low = +0.0°C, high = +0.0°C) Created attachment 300039 [details] 0001-hwmon-nct6775-Add-support-for-ROG-MAXIMUS-X-HERO.patch I can confirm that the sensors of Asus ROG MAXIMUS X HERO also work with the proposed patchset. The name of the board is "ROG MAXIMUS X HERO", and needs to use acpi_board_LPCB_MUTEX. Attached a patch based on the Linux 5.15 branch with applied latest patchset for nct6775 from 2021.12.14 (comment #199 from Denis Pauk). Created attachment 300125 [details] ASUS Pro B550M-C/CSM acpidump -b dsdt.dat The "Pro B550M-C" as mentioned in #c70 also appears to need to be in a list. $ cat /sys/class/dmi/id/board_name Pro B550M-C https://www.asus.com/us/Motherboards-Components/Motherboards/CSM/Pro-B550M-C-CSM/ As of Kernel 5.15, and now 5.16 too. My board no longer reads my chip either - nct6798. Works fine up to Kernel 5.14.21 though. How can I help re-adding this support back in? Thanks (In reply to Jonathan Farrugia from comment #203) > As of Kernel 5.15, and now 5.16 too. My board no longer reads my chip either > - nct6798. > > Works fine up to Kernel 5.14.21 though. > > How can I help re-adding this support back in? > > Thanks Forgot to add my board details: cat /sys/class/dmi/id/board_name PRIME B550M-A Created attachment 300253 [details] Asus WMI for nct6775 v5.16 base (2022.01.11) (In reply to Jonathan Farrugia from comment #204) > cat /sys/class/dmi/id/board_name > PRIME B550M-A (In reply to Gregory P. Smith from comment #202) > The "Pro B550M-C" as mentioned in #c70 also appears to need to be in a list. > > $ cat /sys/class/dmi/id/board_name > Pro B550M-C > > https://www.asus.com/us/Motherboards-Components/Motherboards/CSM/Pro-B550M-C- > CSM/ Could you check with updated patch? Hi! I've tested my ROG STRIX B450-F GAMING II with asus_wmi_sensors. Seems to mostly work? asus_wmi_sensors-virtual-0 Adapter: Virtual device CPU Core Voltage: 905.00 mV VPP MEM Voltage: 2.54 V +12V Voltage: 10.25 V +5V Voltage: 5.15 V 3VSB Voltage: 3.40 V VBAT Voltage: 3.29 V AVCC3 Voltage: 3.40 V SB 1.05V Voltage: 1.04 V CPU Core Voltage: 0.00 V CPU SOC Voltage: 0.00 V CPU Fan: 795 RPM Chassis Fan 1: 813 RPM Chassis Fan 2: 0 RPM Chassis Fan 3: 555 RPM AIO Pump: 0 RPM Water Pump: 0 RPM CPU OPT: 0 RPM CPU Temperature: +36.0°C CPU Socket Temperature: +30.0°C Motherboard Temperature: +32.0°C Chipset Temperature: +36.0°C Tsensor 1 Temperature: +216.0°C CPU VRM Temperature: +0.0°C CPU VRM Output Current: 0.00 A Not sure what's up with Tsensor1. (In reply to Aleksa Savic from comment #206) > Not sure what's up with Tsensor1. That's the blank value. That's what I suspected, thanks for confirming. Do I need to check anything else, is it good for addition? (In reply to Denis Pauk from comment #205) > Created attachment 300253 [details] > Asus WMI for nct6775 v5.16 base (2022.01.11) > > (In reply to Jonathan Farrugia from comment #204) > > cat /sys/class/dmi/id/board_name > > PRIME B550M-A > (In reply to Gregory P. Smith from comment #202) > > The "Pro B550M-C" as mentioned in #c70 also appears to need to be in a > list. > > > > $ cat /sys/class/dmi/id/board_name > > Pro B550M-C > > > > > https://www.asus.com/us/Motherboards-Components/Motherboards/CSM/Pro-B550M-C- > > CSM/ > > Could you check with updated patch? Just tried the patch. The chip is being detected correctly and readings are the same as with Kernel 5.14.21. nct6798-isa-0290 Adapter: ISA adapter in0: +0.39 V (min = +0.00 V, max = +1.74 V) in1: +1.01 V (min = +0.00 V, max = +0.00 V) ALARM in2: +3.44 V (min = +0.00 V, max = +0.00 V) ALARM in3: +3.33 V (min = +0.00 V, max = +0.00 V) ALARM in4: +1.02 V (min = +0.00 V, max = +0.00 V) ALARM in5: +1.05 V (min = +0.00 V, max = +0.00 V) ALARM in6: +1.01 V (min = +0.00 V, max = +0.00 V) ALARM in7: +3.44 V (min = +0.00 V, max = +0.00 V) ALARM in8: +3.38 V (min = +0.00 V, max = +0.00 V) ALARM in9: +0.92 V (min = +0.00 V, max = +0.00 V) ALARM in10: +0.52 V (min = +0.00 V, max = +0.00 V) ALARM in11: +0.52 V (min = +0.00 V, max = +0.00 V) ALARM in12: +1.03 V (min = +0.00 V, max = +0.00 V) ALARM in13: +1.00 V (min = +0.00 V, max = +0.00 V) ALARM in14: +1.01 V (min = +0.00 V, max = +0.00 V) ALARM fan1: 1347 RPM (min = 0 RPM) fan2: 1279 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +23.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +28.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +25.5°C sensor = thermistor AUXTIN1: +23.0°C sensor = thermistor AUXTIN2: +23.0°C sensor = thermistor AUXTIN3: +26.0°C sensor = thermistor PECI Agent 0 Calibration: +28.5°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled If I may ask, will this work be integrated into 5.16.x patches? Thanks :) One more board.
--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -5001,6 +5001,7 @@ static const char * const asus_wmi_boards[] = {
"ROG STRIX X570-F GAMING",
"ROG STRIX X570-I GAMING",
"ROG STRIX Z390-E GAMING",
+ "ROG STRIX Z390-F GAMING",
"ROG STRIX Z490-I GAMING",
"TUF GAMING B550M-PLUS",
"TUF GAMING B550M-PLUS (WI-FI)",
And it works.
[ 8.534975] nct6775: Using Asus WMI to access 0xc1 chip.
[ 8.535102] nct6775: Enabling hardware monitor logical device mappings.
[ 8.535141] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
nct6798-isa-0290
Adapter: ISA adapter
in0: 648.00 mV (min = +0.00 V, max = +1.74 V)
in1: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in2: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM
in3: 3.36 V (min = +0.00 V, max = +0.00 V) ALARM
in4: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM
in5: 176.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in6: 0.00 V (min = +0.00 V, max = +0.00 V)
in7: 3.38 V (min = +0.00 V, max = +0.00 V) ALARM
in8: 3.12 V (min = +0.00 V, max = +0.00 V) ALARM
in9: 528.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in10: 584.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in11: 512.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in12: 1.06 V (min = +0.00 V, max = +0.00 V) ALARM
in13: 296.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in14: 560.00 mV (min = +0.00 V, max = +0.00 V) ALARM
fan1: 481 RPM (min = 0 RPM)
fan2: 520 RPM (min = 0 RPM)
fan3: 435 RPM (min = 0 RPM)
fan4: 484 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 517 RPM (min = 0 RPM)
fan7: 4231 RPM (min = 0 RPM)
SYSTIN: +28.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
CPUTIN: +32.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: -128.0°C sensor = thermistor
AUXTIN1: +17.0°C sensor = thermistor
AUXTIN2: +25.0°C sensor = thermistor
AUXTIN3: +53.0°C sensor = thermistor
PECI Agent 0 Calibration: +32.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
acpitz-acpi-0
Adapter: ACPI interface
temp1: +27.8°C (crit = +119.0°C)
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +45.0°C (high = +86.0°C, crit = +100.0°C)
Core 0: +32.0°C (high = +86.0°C, crit = +100.0°C)
Core 1: +33.0°C (high = +86.0°C, crit = +100.0°C)
Core 2: +33.0°C (high = +86.0°C, crit = +100.0°C)
Core 3: +45.0°C (high = +86.0°C, crit = +100.0°C)
Core 4: +32.0°C (high = +86.0°C, crit = +100.0°C)
Core 5: +33.0°C (high = +86.0°C, crit = +100.0°C)
Core 6: +33.0°C (high = +86.0°C, crit = +100.0°C)
Core 7: +32.0°C (high = +86.0°C, crit = +100.0°C)
Any idea if or when this fix will make it into a Kernel release? As of 5.16.3 it's still not merged. Created attachment 300351 [details] Asus WMI for nct6775 v5.16 base (2022.01.30) Updated patch with X570-E and Z390-F/H/I. Boards with possible support of i2c connection/mutex are moved to separate section. Also includes patches from https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-next and https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-for-v5.17-rc2 (In reply to Jonathan Farrugia from comment #211) > Any idea if or when this fix will make it into a Kernel release? As of > 5.16.3 it's still not merged. Patch with "Pro B550M-C" will be included to 5.18 release. Created attachment 300389 [details]
Asus WMI for nct6775 v5.16 base (2022.02.03)
Added SENSORS_ASUS_EC driver.
Same as SENSORS_ASUS_WMI_EC but much faster.
> Added SENSORS_ASUS_EC driver.
> Same as SENSORS_ASUS_WMI_EC but much faster.
BTW, the WMI code works awfully slow in most of the kernel configurations I tried, but with my custom kernel (Gentoo) it works OK. When I use a Fedora kernel config in the same environment, EC operations via WMI become slow. I tried to unload various modules but to date do not know what slows down the kernel. It would be great to find that out.
My Board happens to report "PRIME X570-P" instead of "PRIME X570-PRO" (what I saw in the source code)... > sudo dmidecode -t 2 > # dmidecode 3.2 > Getting SMBIOS data from sysfs. > SMBIOS 3.3.0 present. > # SMBIOS implementations newer than version 3.2.0 are not > # fully supported by this version of dmidecode. > > Handle 0x0002, DMI type 2, 15 bytes > Base Board Information > Manufacturer: ASUSTeK COMPUTER INC. > Product Name: PRIME X570-P > Version: Rev X.0x > Serial Number: 200569769502586 > Asset Tag: Default string > Features: > Board is a hosting board > Board is replaceable > Location In Chassis: Default string > Chassis Handle: 0x0003 > Type: Motherboard > Contained Object Handles: 0 I have the latest available bios installed for my board. > BIOS Information > Vendor: American Megatrends Inc. > Version: 4021 > Release Date: 08/09/2021 > Address: 0xF0000 > Runtime Size: 64 kB > ROM Size: 16 MB > Characteristics: > PCI is supported > APM is supported > BIOS is upgradeable > BIOS shadowing is allowed > Boot from CD is supported > Selectable boot is supported > BIOS ROM is socketed > EDD is supported > 5.25"/1.2 MB floppy services are supported (int 13h) > 3.5"/720 kB floppy services are supported (int 13h) > 3.5"/2.88 MB floppy services are supported (int 13h) > Print screen service is supported (int 5h) > 8042 keyboard services are supported (int 9h) > Serial services are supported (int 14h) > Printer services are supported (int 17h) > ACPI is supported > USB legacy is supported > BIOS boot specification is supported > Targeted content distribution is supported > UEFI is supported > BIOS Revision: 5.17 (In reply to Jaap de Haan from comment #215) > My Board happens to report "PRIME X570-P" instead of "PRIME X570-PRO" (what > I saw in the source code)... They look like two distinct models: https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570-PRO/ https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570-P/ Oh dear, you're absolutely right. These are indeed two different boards. Not confusing at all for consumers <irony>... Created attachment 300417 [details] Asus WMI for nct6775 v5.16 base (2022.02.08) (In reply to Eugene Shalygin from comment #216) > (In reply to Jaap de Haan from comment #215) > > My Board happens to report "PRIME X570-P" instead of "PRIME X570-PRO" (what > > I saw in the source code)... > > They look like two distinct models: > > https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570- > PRO/ > > https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-X570-P/ Updated version of patch with asus-ec-sensors CPU core voltage patch from Eugene Shalygin and additional support in nct6775 module for * PRIME X570-P, * ROG STRIX B550-F GAMING WIFI II, * ROG STRIX B550-XE GAMING (WI-FI), * ROG STRIX X570-E GAMING, * ROG STRIX Z390-F GAMING, * ROG STRIX Z390-H GAMING, * ROG STRIX Z390-I GAMING, * ROG STRIX Z490-A GAMING, * ROG STRIX Z490-E GAMING, * ROG STRIX Z490-F GAMING, * ROG STRIX Z490-G GAMING, * ROG STRIX Z490-G GAMING (WI-FI), * ROG STRIX Z490-H GAMING Created attachment 300478 [details]
ASUS PRIME H510-K DSDT table
So, I have an ASUS PRIME H510-K motherboard and was faced with the same issue.
Just adding the motherboard in the list wasn't sufficient however. Because although the ACPI method exist for read/write of the registers under the WMBD method, the WMI table listing the GUID doesn't actually list that 0xBD object so the WMI calls failed ...
I "worked around" it by runtime patching the DSDT table, but it's not exactly user friendly ... maybe a module quirk based on model to ignore the _WDG table and just calling WMBD directly would be better.
Anyway, just wanted to report on my experience.
I also contacted Asus and described the issue in detail, but let's face it, there isn't a chance in hell that this is going to be fixed on their side ...
Created attachment 300506 [details]
Asus WMI for nct6775 v5.16 base (2022.02.22)
Update code with up streamed Eugene Shalygin patches for asus_ec_sensors.
asus_wmi_ec_sensors is also updated to be in sync with asus_ec_sensors. Could some one check with "ROG STRIX X570-F GAMING"/"ROG STRIX X570-I GAMING".
Could someone with a such boards check?
I use kernel 5.17 rc5 commit 5c1ee569660d. And my M/B is "ROG STRIX X570-I GAMING". The driver nct6775 not automatically loaded for unknown reason. Demonstration: https://youtu.be/NyTqxwshE-s Denis it's a normal that nct6775 driver not automatically loaded? Same issue with Rog Strix Z370-H Gaming, which has Nuvoton NCT6793D Kernel version: 5.16.11-zen1-1-zen [ 2.018193] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20210930/utaddress-204) [ 2.018199] ACPI: OSL: Resource conflict; ACPI support missing from driver? First I would like to thank all of you who contributed to this patch. Special thanks to Denis who took it upstream. I have another candidate and was hoping we can have it added to the patch. $ cat /sys/class/dmi/id/board_name ROG STRIX X570-E GAMING WIFI II $ dmesg [ 4.244908] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [ 4.244914] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210930/utaddress-204) [ 4.244919] ACPI: OSL: Resource conflict; ACPI support missing from driver? $ uname -a Linux pop-os 5.16.11-76051611-generic #202202230823~1646248261~21.10~2b22243 SMP PREEMPT Wed Mar 2 20: x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/os-release NAME="Pop!_OS" VERSION="21.10" ID=pop ID_LIKE="ubuntu debian" PRETTY_NAME="Pop!_OS 21.10" VERSION_ID="21.10" HOME_URL="https://pop.system76.com" SUPPORT_URL="https://support.system76.com" BUG_REPORT_URL="https://github.com/pop-os/pop/issues" PRIVACY_POLICY_URL="https://system76.com/privacy" VERSION_CODENAME=impish UBUNTU_CODENAME=impish LOGO=distributor-logo-pop-os Thank you! Created attachment 300540 [details]
DSDT dump - ROG STRIX X570-E GAMING WIFI II
Thanks all for the effort en support. please also add: cat /sys/class/dmi/id/board_name PRO H410T [ 5.478347] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [ 5.478351] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210331/utaddress-204) [ 5.478356] ACPI: OSL: Resource conflict; ACPI support missing from driver? uname -a Linux rd-nas01 5.13.0-35-generic #40-Ubuntu SMP Mon Mar 7 08:03:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux cat /etc/os-release PRETTY_NAME="Ubuntu 21.10" NAME="Ubuntu" VERSION_ID="21.10" VERSION="21.10 (Impish Indri)" VERSION_CODENAME=impish ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=impish Would it be possible to get these new motherboard in during Linux 5.18 merge window? I hope someone works on the big picture problem: Maintaining hard coded lists of random vendor specific strings in the kernel source code does not scale. The only solution for anyone overlooked or unidentified is to modify a list in the kernel source code and maintain their own fork of the distro's kernel for years? That is unfriendly and leaves most actual users stuck. A way to choose which settings to use at boot and/or module load time (or amend these lists) via configuration external to the kernel (ex: parameters) would avoid this endless "me too" string submission dance. Created attachment 300687 [details] Asus WMI for nct6775 v5.17 base (2022.04.03) (In reply to renedis from comment #228) > Thanks all for the effort en support. please also add: > > cat /sys/class/dmi/id/board_name > PRO H410T (In reply to Hubert Banas from comment #225) > First I would like to thank all of you who contributed to this patch. > Special thanks to Denis who took it upstream. > > I have another candidate and was hoping we can have it added to the patch. > > $ cat /sys/class/dmi/id/board_name > ROG STRIX X570-E GAMING WIFI II Could you please recheck with new patch? (In reply to renedis from comment #228) > Thanks all for the effort en support. please also add: > > cat /sys/class/dmi/id/board_name > PRO H410T Could you please share dsdt dump? (acpidump -b -n DSDT) (In reply to Hubert Banas from comment #229) > Would it be possible to get these new motherboard in during Linux 5.18 merge > window? It can be part of 5.19+ if patch will be accepted before start of the new merge window. (I have not sent patch yet.) (In reply to Denis Pauk from comment #232) > (In reply to Hubert Banas from comment #229) > > Would it be possible to get these new motherboard in during Linux 5.18 > merge > > window? > > It can be part of 5.19+ if patch will be accepted before start of the new > merge window. (I have not sent patch yet.) Sounds good. Thank you. Thanks all for the effort. Please also add: $ cat /sys/class/dmi/id/board_name PRIME H410M-R $ dmesg [ 1685.886012] nct6775: Enabling hardware monitor logical device mappings. [ 1685.886040] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [ 1685.886044] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20210730/utaddress-213) [ 1685.886048] ACPI: OSL: Resource conflict; ACPI support missing from driver? $ uname -a Linux localhost.localdomain 5.14.21-150400.19-default #1 SMP PREEMPT_DYNAMIC Wed Apr 20 08:32:52 UTC 2022 (d6fb753) x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/os-release NAME="openSUSE Leap" VERSION="15.4 Beta" ID="opensuse-leap" ID_LIKE="suse opensuse" VERSION_ID="15.4" PRETTY_NAME="openSUSE Leap 15.4 Beta" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:15.4" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap" LOGO="distributor-logo-Leap" Created attachment 300872 [details] Asus WMI for nct6775 v5.17 base (2022.05.03) Added support by WMI for: * PRO H410T * PRIME H410M-R * ROG STRIX X570-E GAMING WIFI II By ACPI lock (will not be upstreamed): * ROG STRIX Z370-H GAMING Code is fully untested. (In reply to Dmitrii Levchenko from comment #234) > Thanks all for the effort. > Please also add: > > $ cat /sys/class/dmi/id/board_name > PRIME H410M-R (In reply to Hubert Banas from comment #233) > > > > It can be part of 5.19+ if patch will be accepted before start of the new > > merge window. (I have not sent patch yet.) > > Sounds good. Thank you. Upstream contains rework of nct6775, I have applied all commits but can't check code with real hardware for now. If everything works for you, i will send patch to updated with new boards. (In reply to Emmanuel Mayor from comment #223) > Same issue with Rog Strix Z370-H Gaming, which has Nuvoton NCT6793D > DSDT does not have required WMI interface, board support can be implemented only by direct lock of ACPI mutex. Created attachment 300905 [details] acpidump -b -n DSDT for H410T (In reply to Denis Pauk from comment #232) > (In reply to renedis from comment #228) > > Thanks all for the effort en support. please also add: > > > > cat /sys/class/dmi/id/board_name > > PRO H410T > > Could you please share dsdt dump? (acpidump -b -n DSDT) Sorry for the late reply. There you go, see attached file. (In reply to renedis from comment #236) > Created attachment 300905 [details] > acpidump -b -n DSDT for H410T > > (In reply to Denis Pauk from comment #232) > > (In reply to renedis from comment #228) > > > Thanks all for the effort en support. please also add: > > > > > > cat /sys/class/dmi/id/board_name > > > PRO H410T > > > > Could you please share dsdt dump? (acpidump -b -n DSDT) > > Sorry for the late reply. > There you go, see attached file. Thank you, could you please check patch attached in #235? Created attachment 300932 [details]
Z170M-PLUS dsdt dump
Hi,
Can the Asus Z170M-PLUS be supported by this effort too?
cat /sys/class/dmi/id/board_name
Z170M-PLUS
[May11 11:46] nct6775: Enabling hardware monitor logical device mappings.
[ +0.000028] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290
[ +0.000004] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20211217/utaddress-204)
[ +0.000004] ACPI: OSL: Resource conflict; ACPI support missing from driver?
dsdt dump is attached.
Created attachment 300958 [details]
Asus Z170-DELUXE dump
Thank you for continued work, herewith details for another Asus Z170 board:
$ cat /sys/class/dmi/id/board_name
Z170-DELUXE
$ cat /proc/version
Linux version 5.17.7-051707-generic (kernel@gloin) (gcc (Ubuntu 11.3.0-1ubuntu1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #202205121146 SMP PREEMPT Thu May 12 13:20:51 UTC 2022
still needs `acpi_enforce_resources=lax` for sensors to work
dmesg:
[ 3.565498] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290
[ 3.566379] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20211217/utaddress-204)
[ 3.568047] ACPI: OSL: Resource conflict; ACPI support missing from driver?
Created attachment 300963 [details] Asus WMI for nct6775 v5.17 base (2022.05.15) (In reply to Rob Miller from comment #239) > Created attachment 300958 [details] > Asus Z170-DELUXE dump (In reply to Sven Arvidsson from comment #238) > Created attachment 300932 [details] > Z170M-PLUS dsdt dump Unfortunately, your motherboard does not have any endpoints supported by upstreamed drivers. Could you please try with attached patch? It provides custom lock method that is unsupported by upstream driver. Denis, please answer the question. The driver `nct6775` I should manually loaded after each boot? Or it should be loaded automatically? (In reply to Mikhail from comment #241) > Denis, please answer the question. > The driver `nct6775` I should manually loaded after each boot? Or it should > be loaded automatically? Driver should be automatically loaded on next reboot after modules_install. What do you have in dmesg after 'modprobe nct6775' or 'insmod <path>/nct6775.ko' ? (In reply to Denis Pauk from comment #242) > Driver should be automatically loaded on next reboot after modules_install. I expecting that default kernel package in my distro (Fedora Rawhide) already have latest nct6775 driver. So didn't run make modules_install because it unacceptable for a package based distribution (no one want that package based distro turns into Slackware). > What do you have in dmesg after 'modprobe nct6775' or 'insmod > <path>/nct6775.ko' ? Modprobe looks good: # modprobe nct6775 [ 95.017206] nct6775: Using Asus WMI to access 0xc1 chip. [ 95.017239] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 Driver is loading manually without any errors and sensors become show chipset information. But insmod unapplicable because in Fedora all modules is compressed: # insmod /usr/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz insmod: ERROR: could not insert module /usr/lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz: Unknown symbol in module # depmod /lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz depmod: ERROR: Bad version passed /lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz # modinfo /lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz filename: /lib/modules/5.18.0-0.rc7.54.fc37.x86_64+debug/kernel/drivers/hwmon/nct6775.ko.xz license: GPL description: Driver for NCT6775F and compatible chips author: Guenter Roeck <linux@roeck-us.net> rhelversion: 9.99 depends: hwmon-vid,wmi retpoline: Y intree: Y name: nct6775 vermagic: 5.18.0-0.rc7.54.fc37.x86_64+debug SMP preempt mod_unload sig_id: PKCS#7 signer: Fedora kernel signing key sig_key: 05:21:2C:F4:BE:27:02:E2:CE:C9:4F:8F:A6:94:3B:72:76:05:73:E1 sig_hashalgo: sha256 signature: A4:5D:3C:C7:5F:0F:4E:DE:D9:B5:D9:CC:8C:4A:FD:D5:9A:5A:53:F8: 60:F8:AD:4D:93:26:31:6C:88:EF:FB:5C:96:34:FE:D1:FA:8A:15:5F: DE:8A:CA:02:1B:14:BB:FF:92:AE:F0:7E:98:61:8B:FD:BC:39:FA:5C: 83:DD:1A:36:ED:E0:E7:C1:84:73:C7:1C:15:8E:50:8B:7A:10:CA:09: A2:CC:11:8E:D2:CF:63:94:56:A7:E4:C3:EC:19:0A:25:F6:19:B7:3C: 1F:95:74:E6:C5:E0:B8:17:B3:C0:D0:3E:D7:93:F6:94:10:DB:17:BC: 1D:DD:AF:EA:51:D6:A4:9B:83:F5:00:AF:96:EA:C0:E5:B2:E3:DA:97: 5D:58:B9:6A:E5:8A:32:1A:EE:CD:17:04:6D:97:72:60:90:F2:B5:C4: DB:71:3A:45:FC:86:0E:1D:94:8F:98:5F:5C:C8:0E:48:99:7B:3E:BC: FA:07:01:2E:F8:45:E8:04:B0:A2:57:11:9B:B5:3A:C9:22:86:11:92: E2:5C:0D:91:7A:91:36:64:24:12:26:68:36:4F:AD:6F:C2:64:A7:DB: 69:0E:D6:B5:A6:A2:21:BC:6F:4A:B1:6E:40:F4:33:15:8C:E4:CB:B0: 09:B2:E7:8C:64:5A:67:30:50:05:A2:53:1D:7B:50:11:A1:25:67:5A: 05:94:06:D7:74:D3:59:26:B0:B4:0E:72:9E:50:A7:68:E3:EC:0C:E4: 75:26:20:33:77:0D:0A:C1:B7:29:98:D4:36:2E:E5:87:2F:9A:54:E5: 51:13:A4:D0:A9:04:BC:48:DA:33:B7:33:08:F0:12:D9:55:03:E3:05: A4:0F:6A:6A:23:9D:92:A5:7E:72:BF:C3:73:FE:EF:4D:FD:2A:D2:4D: 04:AE:77:EF:11:26:E4:AF:7F:16:8A:7B:0C:45:51:78:4B:2D:7B:3A: 10:3D:E9:7E:19:45:8C:CA:74:A1:66:4B:EB:DC:F3:BC:DF:78:E8:EF: 87:52:94:A6:C3:37:76:FB:3B:CE:1E:04:29:5C:AE:93:91:80:CC:57: 8D:B5:63:E7:F8:6E:EC:5A:DE:62:56:E9:4B:18:50:20:58:A2:52:E0: F3:F5:DA:B2:28:9F:9C:8D:D7:FC:A8:90:67:BC:12:2D:E3:3C:57:02: 3A:8D:B2:08:21:86:F6:D9:D2:BB:6C:39:A4:D8:B3:29:59:FC:24:00: 64:C2:92:AA:1F:AA:33:43:9F:5F:1E:2E:95:0B:72:13:38:A2:DB:77: 1F:00:86:78:D9:D2:AD:87:AA:9E:E4:6B:8D:80:8E:44:DC:EC:A8:92: 02:86:3B:0F:0D:EA:4C:AD:A8:E4:50:0F parm: force_id:Override the detected device ID (ushort) parm: fan_debounce:Enable debouncing for fan RPM signal (ushort) # uname -r 5.18.0-0.rc7.54.fc37.x86_64+debug (In reply to Denis Pauk from comment #240) > > Could you please try with attached patch? It provides custom lock method > that is unsupported by upstream driver. Thanks for the patch and your continued work on this! Unfortunately, there's no difference on my system after applying the patch. I get the same warnings about a resource conflict and missing ACPI support. Created attachment 301030 [details] Asus WMI for nct6775 v5.18 base (2022.05.24) (In reply to Sven Arvidsson from comment #244) > (In reply to Denis Pauk from comment #240) > > > > Could you please try with attached patch? It provides custom lock method > > that is unsupported by upstream driver. > Thanks for the patch and your continued work on this! > > Unfortunately, there's no difference on my system after applying the patch. > I get the same warnings about a resource conflict and missing ACPI support. I have made mistake in board name(Z170-PLUS instead Z170M-PLUS), could you please recheck with rebased patch? (In reply to Denis Pauk from comment #240) > Created attachment 300963 [details] > Asus WMI for nct6775 v5.17 base (2022.05.15) > > (In reply to Rob Miller from comment #239) > > Created attachment 300958 [details] > > Asus Z170-DELUXE dump > Unfortunately, your motherboard does not have any endpoints supported by > upstreamed drivers. > > Could you please try with attached patch? It provides custom lock method > that is unsupported by upstream driver. Thank you for your continued efforts on this. I installed the 5.18 base patch and was able to boot without the warning messages. The nct6775 module loaded without issue, but 'sensors' command did not show all the info for my device as it does booting the Ubuntu 5.15.0-33-generic kernel with the 'acpi_enforce_resources=lax' option. nct675 reports: Found NCT6793D or compatible chip at 0x2e:0x290 Created attachment 301046 [details] Z170M-PLUS crash (In reply to Denis Pauk from comment #245) > I have made mistake in board name(Z170-PLUS instead Z170M-PLUS), could you > please recheck with rebased patch? Thanks for the new patch! The chip is detected now, but unfortunately crashes after loading. Crash log is attached. Created attachment 301047 [details] Asus WMI for nct6775 v5.18 base (2022.05.25) (In reply to Sven Arvidsson from comment #247) > Created attachment 301046 [details] > Z170M-PLUS crash > > (In reply to Denis Pauk from comment #245) > > I have made mistake in board name(Z170-PLUS instead Z170M-PLUS), could you > > please recheck with rebased patch? > Thanks for the new patch! The chip is detected now, but unfortunately > crashes after loading. > > Crash log is attached. Welcome! I have added small fix for init, could you please try? (In reply to Rob Miller from comment #246) > (In reply to Denis Pauk from comment #240) > > Created attachment 300963 [details] > > Asus WMI for nct6775 v5.17 base (2022.05.15) > > > > (In reply to Rob Miller from comment #239) > > > Created attachment 300958 [details] > > > Asus Z170-DELUXE dump > > > Unfortunately, your motherboard does not have any endpoints supported by > > upstreamed drivers. > > > > Could you please try with attached patch? It provides custom lock method > > that is unsupported by upstream driver. > > Thank you for your continued efforts on this. > > I installed the 5.18 base patch and was able to boot without the warning > messages. > > The nct6775 module loaded without issue, but 'sensors' command did not show > all the info for my device as it does booting the Ubuntu 5.15.0-33-generic > kernel with the 'acpi_enforce_resources=lax' option. > > nct675 reports: Found NCT6793D or compatible chip at 0x2e:0x290 Welcome! I have added little more debug information and additional check for different name of mutex. could you please try? Other possible issue can be different naming of vendor: "ASUSTeK COMPUTER INC." vs "ASUSTeK Computer INC.". (In reply to Denis Pauk from comment #248) > Welcome! I have added small fix for init, could you please try? The third time's the charm! Everything is working fine now. All the sensor data previously visible with the acpi_enforce_resources=lax option is there and PWM seems to be working fine. Thanks for all the hard work you've done! (In reply to Denis Pauk from comment #248) > (In reply to Rob Miller from comment #246) > > > > Asus Z170-DELUXE dump > Welcome! I have added little more debug information and additional check for > different name of mutex. could you please try? > > Other possible issue can be different naming of vendor: "ASUSTeK COMPUTER > INC." vs "ASUSTeK Computer INC.". 1) Using second patch, again sensors doesn't work without the 'lax' boot parameter, and there is a new error: [ 3.469698] nct6775: No such ASUS mutex: \_SB.PCI0.SBRG.SIO1.MUT0 [ 3.470614] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290 [ 3.471418] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20211217/utaddress-204) [ 3.473062] ACPI: OSL: Resource conflict; ACPI support missing from driver? 2) Aplogies, I did find an error booting with the first patch: [ 3.501711] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0 [ 3.501864] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290 [ 3.502050] BUG: kernel NULL pointer dereference, address: 0000000000000270 [ 3.502060] #PF: supervisor write access in kernel mode [ 3.502068] #PF: error_code(0x0002) - not-present page [ 3.502076] PGD 0 P4D 0 [ 3.502087] Oops: 0002 [#1] PREEMPT SMP PTI [ 3.502102] CPU: 3 PID: 344 Comm: systemd-modules Not tainted 5.18.0 #2 [ 3.502116] Hardware name: System manufacturer System Product Name/Z170-DELUXE, BIOS 3801 03/14/2018 [ 3.502121] RIP: 0010:nct6775_platform_probe+0x71/0x1b0 [nct6775] [ 3.502139] Code: 48 c7 c6 00 19 c8 8f 49 89 c7 e8 ca 26 0d ce 48 85 c0 0f 84 3b 01 00 00 49 8b 44 24 10 ba c0 0d 00 00 be 18 05 00 00 4c 89 f7 <48> 89 04 25 70 02 00 00 e8 72 9f 88 ce 48 89 c3 48 85 c0 0f 84 18 [ 3.502144] RSP: 0018:ffffb5ab0093b828 EFLAGS: 00010286 [ 3.502151] RAX: ffff8a17c1278720 RBX: ffffffffc03f6528 RCX: 0000000000000000 [ 3.502156] RDX: 0000000000000dc0 RSI: 0000000000000518 RDI: ffff8a17c4451810 [ 3.502159] RBP: ffffb5ab0093b850 R08: ffff8a17c378bab8 R09: 0000000000000000 [ 3.502162] R10: ffff8a17c378bf00 R11: 0000000000000000 R12: ffff8a17c378b200 [ 3.502166] R13: ffff8a17c4451800 R14: ffff8a17c4451810 R15: ffff8a17c378ba80 [ 3.502171] FS: 00007fe3c6f44900(0000) GS:ffff8a270ecc0000(0000) knlGS:0000000000000000 [ 3.502171] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.502175] CR2: 0000000000000270 CR3: 00000001109b2005 CR4: 00000000003706e0 [ 3.502176] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.502177] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.502177] Call Trace: [ 3.502178] <TASK> [ 3.508488] loop4: detected capacity change from 0 to 113736 [ 3.510084] platform_probe+0x49/0xc0 [ 3.525183] really_probe+0x1b5/0x390 [ 3.525185] __driver_probe_device+0x115/0x190 [ 3.525186] driver_probe_device+0x23/0xc0 [ 3.525187] __device_attach_driver+0xae/0x110 [ 3.525188] ? driver_allows_async_probing+0x60/0x60 [ 3.525189] bus_for_each_drv+0x85/0xd0 [ 3.525192] __device_attach+0xde/0x1f0 [ 3.525193] device_initial_probe+0x13/0x20 [ 3.525194] bus_probe_device+0x8f/0xa0 [ 3.525195] device_add+0x407/0x920 [ 3.525196] ? dev_set_name+0x53/0x70 [ 3.525198] ? preempt_count_add+0x7a/0xc0 [ 3.525200] platform_device_add+0x111/0x250 [ 3.525201] sensors_nct6775_platform_init+0x4c3/0x1000 [nct6775] [ 3.525204] ? superio_wmi_exit+0x10/0x10 [nct6775] [ 3.525206] ? superio_outb+0x20/0x20 [nct6775] [ 3.525207] ? superio_inb+0x20/0x20 [nct6775] [ 3.525208] ? superio_exit+0x40/0x40 [nct6775] [ 3.525210] ? superio_wmi_outb+0x30/0x30 [nct6775] [ 3.525211] ? 0xffffffffc037f000 [ 3.525212] do_one_initcall+0x49/0x210 [ 3.525214] ? kmem_cache_alloc_trace+0x1a6/0x300 [ 3.538973] do_init_module+0x52/0x250 [ 3.538975] load_module+0x27e5/0x2bd0 [ 3.538978] __do_sys_finit_module+0xc5/0x130 [ 3.538980] ? __do_sys_finit_module+0xc5/0x130 [ 3.538982] __x64_sys_finit_module+0x18/0x20 [ 3.538983] do_syscall_64+0x5c/0x80 [ 3.538985] ? exit_to_user_mode_prepare+0x49/0x190 [ 3.538987] ? syscall_exit_to_user_mode+0x26/0x40 [ 3.538988] ? __x64_sys_lseek+0x18/0x20 [ 3.538990] ? do_syscall_64+0x69/0x80 [ 3.538992] ? exit_to_user_mode_prepare+0x166/0x190 [ 3.538993] ? syscall_exit_to_user_mode+0x26/0x40 [ 3.538994] ? do_syscall_64+0x69/0x80 [ 3.538995] ? syscall_exit_to_user_mode+0x26/0x40 [ 3.538996] ? __x64_sys_finit_module+0x18/0x20 [ 3.538998] ? do_syscall_64+0x69/0x80 [ 3.538999] ? do_syscall_64+0x69/0x80 [ 3.539001] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3.539002] RIP: 0033:0x7fe3c731ea3d [ 3.539004] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 89 01 48 [ 3.549209] RSP: 002b:00007ffd20e10708 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 3.549210] RAX: ffffffffffffffda RBX: 0000562f4cf2ee70 RCX: 00007fe3c731ea3d [ 3.549211] RDX: 0000000000000000 RSI: 00007fe3c75f9441 RDI: 0000000000000007 [ 3.549212] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000002 [ 3.549212] R10: 0000000000000007 R11: 0000000000000246 R12: 00007fe3c75f9441 [ 3.549213] R13: 0000562f4cf27160 R14: 00007fe3c781ccd0 R15: 0000562f4cf32360 [ 3.549214] </TASK> [ 3.549215] Modules linked in: nct6775(+) nct6775_core hwmon_vid lm92 jc42 coretemp ipmi_devintf ipmi_msghandler msr parport_pc ppdev lp parport drm ip_tables x_tables autofs4 crc32_pclmul igb psmouse e1000e nvme i2c_i801 i2c_algo_bit i2 c_smbus nvme_core dca ahci libahci xhci_pci xhci_pci_renesas wmi video [ 3.549226] CR2: 0000000000000270 [ 3.549227] ---[ end trace 0000000000000000 ]--- [ 3.549227] RIP: 0010:nct6775_platform_probe+0x71/0x1b0 [nct6775] [ 3.549229] Code: 48 c7 c6 00 19 c8 8f 49 89 c7 e8 ca 26 0d ce 48 85 c0 0f 84 3b 01 00 00 49 8b 44 24 10 ba c0 0d 00 00 be 18 05 00 00 4c 89 f7 <48> 89 04 25 70 02 00 00 e8 72 9f 88 ce 48 89 c3 48 85 c0 0f 84 18 [ 3.549230] RSP: 0018:ffffb5ab0093b828 EFLAGS: 00010286 [ 3.549231] RAX: ffff8a17c1278720 RBX: ffffffffc03f6528 RCX: 0000000000000000 [ 3.549232] RDX: 0000000000000dc0 RSI: 0000000000000518 RDI: ffff8a17c4451810 [ 3.549232] RBP: ffffb5ab0093b850 R08: ffff8a17c378bab8 R09: 0000000000000000 [ 3.549233] R10: ffff8a17c378bf00 R11: 0000000000000000 R12: ffff8a17c378b200 [ 3.549233] R13: ffff8a17c4451800 R14: ffff8a17c4451810 R15: ffff8a17c378ba80 [ 3.549234] FS: 00007fe3c6f44900(0000) GS:ffff8a270ecc0000(0000) knlGS:0000000000000000 [ 3.549235] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.549235] CR2: 0000000000000270 CR3: 00000001109b2005 CR4: 00000000003706e0 [ 3.549236] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.549237] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.568106] systemd[1]: Mounting Mount unit for core20, revision 1434... Created attachment 301099 [details] Asus WMI for nct6775 v5.18 base (2022.06.03) (In reply to Rob Miller from comment #250) > (In reply to Denis Pauk from comment #248) > > > (In reply to Rob Miller from comment #246) > > > > > Asus Z170-DELUXE dump > > > Welcome! I have added little more debug information and additional check > for > > different name of mutex. could you please try? > > > > Other possible issue can be different naming of vendor: "ASUSTeK COMPUTER > > INC." vs "ASUSTeK Computer INC.". > > 1) Using second patch, again sensors doesn't work without the 'lax' boot > parameter, and there is a new error: > > [ 3.469698] nct6775: No such ASUS mutex: \_SB.PCI0.SBRG.SIO1.MUT0 > > 2) Aplogies, I did find an error booting with the first patch: > > [ 3.501711] nct6775: Using Asus WMI mutex: \_SB_.PCI0.LPCB.SIO1.MUT0 > [ 3.501864] nct6775: Found NCT6793D or compatible chip at 0x2e:0x290 Could you please check? (In reply to Denis Pauk from comment #251) > Created attachment 301099 [details] > Asus WMI for nct6775 v5.18 base (2022.06.03) > > (In reply to Rob Miller from comment #250) > Could you please check? Score! sensors command fully working, no issues in dmesg, no 'lax' boot parameter. Thank you! and well done! Created attachment 301145 [details]
Add Maximus XI Hero
I have an older Maximus XI Hero (WiFi) that works fine once I add it to the appropriate lists. I'm attaching the patch I've been using on top of the existing nct6775.patch. Hopefully, it can get integrated into the next iteration.
Thanks!
(In reply to Michael Carns from comment #253) > Created attachment 301145 [details] > Add Maximus XI Hero > > I have an older Maximus XI Hero (WiFi) that works fine once I add it to the > appropriate lists. I'm attaching the patch I've been using on top of the > existing nct6775.patch. Hopefully, it can get integrated into the next > iteration. > > Thanks! Thank you for the EC patch! To mainline it we need to check the HW mutex name, and there is a mistake in the attached patch: MAX_IDENTICAL_BOARD_VARIATIONS needs to be increased for it to work. Or, if it works as is, there is a mistake in the asus-ec-sensors driver code. Thus, could you, please, register a pull request or an issue at https://github.com/zeule/asus-ec-sensors to resolve that and mainline the change? Thanks all! With kernel 5.17 it didn't worked without manually patching. I've skipped kernel 5.18 but can confirm that kernel 5.19 works OOTB: nct6798-isa-0290 Adapter: ISA adapter in0: 664.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM in2: 3.28 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.36 V (min = +0.00 V, max = +0.00 V) ALARM in4: 992.00 mV (min = +0.00 V, max = +0.00 V) ALARM in5: 832.00 mV (min = +0.00 V, max = +0.00 V) ALARM in6: 240.00 mV (min = +0.00 V, max = +0.00 V) ALARM in7: 3.28 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.22 V (min = +0.00 V, max = +0.00 V) ALARM in9: 496.00 mV (min = +0.00 V, max = +0.00 V) ALARM in10: 608.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 592.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in13: 232.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 376.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 2235 RPM (min = 0 RPM) fan2: 2224 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) fan6: 0 RPM (min = 0 RPM) SYSTIN: +35.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +33.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +91.0°C sensor = thermistor AUXTIN1: +15.0°C sensor = thermistor AUXTIN2: +16.0°C sensor = thermistor AUXTIN3: +75.0°C sensor = thermistor PECI Agent 0 Calibration: +32.0°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 Kernel: 5.19.0-051900-generic Many thanks again! @Eugene Shalygin Can you create patch for the 5.19 kernel, please? Created attachment 302999 [details]
Asus WMI for nct6775 v5.19 base (2022.10.14)
Hwmon changes v5.19..v5.20 + nct6775 locks
@Denis Pauk Something wrong with the patch, it has only commit headers :) Created attachment 303000 [details] Asus WMI for nct6775 v5.19 base (2022.10.14) (In reply to Vladdrako from comment #258) > @Denis Pauk > Something wrong with the patch, it has only commit headers :) Could you please check now? (In reply to Denis Pauk from comment #259) > Created attachment 303000 [details] > Asus WMI for nct6775 v5.19 base (2022.10.14) > > (In reply to Vladdrako from comment #258) > > @Denis Pauk > > Something wrong with the patch, it has only commit headers :) > > Could you please check now? It works ok, thanks. Created attachment 303020 [details]
Asus P8H67 DSDT
Is Asus P8H67 also a MB that could have support added?
DSDT attached.
dmidecode:
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: P8H67
Version: Rev X.0x
Serial Number: MF70B3G04701427
Asset Tag: To be filled by O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
dmesg:
[207642.852150] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[207642.852158] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWRE) (20220331/utaddress-204)
[207642.852163] ACPI: OSL: Resource conflict; ACPI support missing from driver?
Created attachment 303031 [details] Asus WMI for nct6775 v5.20 base (2022.10.18) (In reply to Jure Repinc from comment #261) > Created attachment 303020 [details] > Asus P8H67 DSDT > > Is Asus P8H67 also a MB that could have support added? P8H67 does not have support of WMI interfaces that currently used for ASUS boards in kernel. Also it looks like access to nct6775 is not guarded by any mutex locks in code section with sensors registers region. (It can be really dangerous to use registers directly) I have added use lock from different section that also used in other bioses as lock. Could you please check? Created attachment 303045 [details] Asus WMI for nct6775 v5.20 base (2022.10.20) Updated patch with X670 board support, based on patch from Ahmad Khalifa, https://patchwork.kernel.org/project/linux-hwmon/patch/20221018173428.71080-1-ahmad@khalifa.ws/ Created attachment 303116 [details]
DSDT - X99-E-WS-USB3 - Decompiled
Same or similar issue with X99-E WS/USB 3.1:
nct6775: Found NCT6791D or compatible chip at 0x2e:0x290
ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20200925/utaddress-204)
I've been trying to make sense of the DSDT by reading the ACPI spec, but I'm not having a lot success. Built kernels 5.10, 5.19, 6.0.2, 6.03, and several different versions of nct6775 driver for each including "Asus WMI for nct6775 v5.20 base (2022.10.20)", both in tree and as a custom DKMS module to no effect.
I'm rather reluctant to actually try using acpi_enforce_resourses=lax, so I don't know for sure if that would make it work or not. I've attached my DSDT as pulled from the latest BIOS update for my board from ASUS. Could someone take a look and confirm for me that I likely have this same problem?
(In reply to zykr.caswell from comment #264) > Created attachment 303116 [details] > DSDT - X99-E-WS-USB3 - Decompiled > > Same or similar issue with X99-E WS/USB 3.1: > > nct6775: Found NCT6791D or compatible chip at 0x2e:0x290 > ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts > with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) > (20200925/utaddress-204) > > I've been trying to make sense of the DSDT by reading the ACPI spec, but I'm > not having a lot success. Built kernels 5.10, 5.19, 6.0.2, 6.03, and several > different versions of nct6775 driver for each including "Asus WMI for > nct6775 v5.20 base (2022.10.20)", both in tree and as a custom DKMS module > to no effect. > > I'm rather reluctant to actually try using acpi_enforce_resourses=lax, so I > don't know for sure if that would make it work or not. I've attached my DSDT > as pulled from the latest BIOS update for my board from ASUS. Could someone > take a look and confirm for me that I likely have this same problem? Could you please apply patch and add line with you board and recheck? Change should be like "DMI_MATCH_ASUS_WMI_BOARD("<You board name>", &acpi_board_LPCB_MUTEX)," near "MAXIMUS VII HERO" definition. Name board should be from /sys/class/dmi/id/board_name. TLDR: B-->0 and it works!
Adding the board to that list, which I'm feeling a little embarrassed I hadn't already tried, gives this:
nct6775_dkms_platform: No such ASUS mutex: \_SB_.PCI0.LPCB.SIO1.MUT0
nct6775_dkms_platform: Found NCT6791D or compatible chip at 0x2e:0x290
ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20220331/utaddress-204)
ACPI: OSL: Resource conflict; ACPI support missing from driver?
Looking at the DKMS, I don't have such a Mutex, but I do have one under LPC0 instead of LPCB.
Scope (_SB) --> Device (PCI0) --> Device (LPC0) --> Device (SIO1) --> Mutex (MUT0, 0x00)
Adding that in results in... IT WORKS! I had almost given up by this point and was main continuing out of stubbornness rather than any actual expectation of getting it working.
So, thank you, thank you very much. I'm not sure all of the values are right as the temperatures seem rather high, but I will try to confirm that now.
ADDED:
+ DMI_ASUS_BOARD_INFO(acpi_board_LPC0_MUTEX, "\\_SB_.PCI0.LPC0.SIO1.MUT0");
...
DMI_MATCH_ASUS_NONWMI_BOARD("P8Z68-V LX", &acpi_board_LPCB_MUTEX),
+ /* SB_.PCI0.LPC0.SIO1.MUT0*/
+ DMI_MATCH_ASUS_WMI_BOARD("X99-E WS/USB 3.1", &acpi_board_LPC0_MUTEX),
+ /* SB_.PCI0.LPCB.SIO1.MUT0*/
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS VII HERO", &acpi_board_LPCB_MUTEX),
Created attachment 303126 [details] Asus WMI for nct6775 v5.20 base (2022.11.03) (In reply to zykr.caswell from comment #266) > TLDR: B-->0 and it works! Thank you, I have updated patch with your board. can add support TUF GAMING B550M-PLUS WIFI II?
I tried add parameter acpi_enforce_resources=lax, it works.
# dmidecode 3.4
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: TUF GAMING B550M-PLUS WIFI II
Version: Rev X.0x
Serial Number: 220909970904631
Asset Tag: Default string
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Default string
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
cat /sys/class/dmi/id/board_name
TUF GAMING B550M-PLUS WIFI II
Created attachment 303161 [details] Asus WMI for nct6775 v6.0 base (2022.11.12) (In reply to yutesdb from comment #268) > can add support TUF GAMING B550M-PLUS WIFI II? > > I tried add parameter acpi_enforce_resources=lax, it works. Could you please now? (In reply to Denis Pauk from comment #269) > Created attachment 303161 [details] > Asus WMI for nct6775 v6.0 base (2022.11.12) > > (In reply to yutesdb from comment #268) > > can add support TUF GAMING B550M-PLUS WIFI II? > > > > I tried add parameter acpi_enforce_resources=lax, it works. > > Could you please now? thanks, it works, only compile hwmon modules, without acpi_enforce_resources=lax parameter. Created attachment 303265 [details]
Add support for ROG STRIX B660-I GAMING WIFI
This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for nct6775 v6.0 base (2022.11.12)" patch.
(In reply to Slawomir Stepien from comment #271) > Created attachment 303265 [details] > Add support for ROG STRIX B660-I GAMING WIFI > > This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for > nct6775 v6.0 base (2022.11.12)" patch. Thank you! I will add your code to the next patch version. Just for recheck, could you please share error place on init when you added your board to asus_acpi_boards(x670 generation methods) or asus_wmi_boards(b550/x570 generation methods)? Are both of methods of access failed? I have hoped B660 boards have same access method as x670 boards at least :-( (In reply to Denis Pauk from comment #272) > (In reply to Slawomir Stepien from comment #271) > > Created attachment 303265 [details] > > Add support for ROG STRIX B660-I GAMING WIFI > > > > This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for > > nct6775 v6.0 base (2022.11.12)" patch. > > Thank you! I will add your code to the next patch version. > > Just for recheck, could you please share error place on init when you added > your board to asus_acpi_boards(x670 generation methods) or > asus_wmi_boards(b550/x570 generation methods)? Are both of methods of access > failed? > > I have hoped B660 boards have same access method as x670 boards at least :-( [93233.798384] nct6775: Can't read ChipID by Asus WMI. [93233.798386] nct6775: No dmi definition `ROG STRIX B660-I GAMING WIFI`:`ASUSTeK COMPUTER INC.` [93233.798446] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [93233.798449] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204) [93233.798452] ACPI: OSL: Resource conflict; ACPI support missing from driver? (In reply to Slawomir Stepien from comment #273) > (In reply to Denis Pauk from comment #272) > > (In reply to Slawomir Stepien from comment #271) > > > Created attachment 303265 [details] > > > Add support for ROG STRIX B660-I GAMING WIFI > > > > > > This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI for > > > nct6775 v6.0 base (2022.11.12)" patch. > > > > Thank you! I will add your code to the next patch version. > > > > Just for recheck, could you please share error place on init when you added > > your board to asus_acpi_boards(x670 generation methods) or > > asus_wmi_boards(b550/x570 generation methods)? Are both of methods of > access > > failed? > > > > I have hoped B660 boards have same access method as x670 boards at least > :-( > > [93233.798384] nct6775: Can't read ChipID by Asus WMI. > [93233.798386] nct6775: No dmi definition `ROG STRIX B660-I GAMING > WIFI`:`ASUSTeK COMPUTER INC.` > [93233.798446] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > [93233.798449] ACPI Warning: SystemIO range > 0x0000000000000295-0x0000000000000296 conflicts with OpRegion > 0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204) > [93233.798452] ACPI: OSL: Resource conflict; ACPI support missing from > driver? But if I add the board to the asus_acpi_boards, it works but with: [93515.558164] nct6775: Using Asus ACPI to access 0xc1 chip. [93515.558166] nct6775: No dmi definition `ROG STRIX B660-I GAMING WIFI`:`ASUSTeK COMPUTER INC.` [93515.558229] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 So I guess this is a better approach for my case? (In reply to Slawomir Stepien from comment #274) > (In reply to Slawomir Stepien from comment #273) > > (In reply to Denis Pauk from comment #272) > > > (In reply to Slawomir Stepien from comment #271) > > > > Created attachment 303265 [details] > > > > Add support for ROG STRIX B660-I GAMING WIFI > > > > > > > > This adds support for ROG STRIX B660-I GAMING WIFI into the "Asus WMI > for > > > > nct6775 v6.0 base (2022.11.12)" patch. > > > > > > Thank you! I will add your code to the next patch version. > > > > > > Just for recheck, could you please share error place on init when you > added > > > your board to asus_acpi_boards(x670 generation methods) or > > > asus_wmi_boards(b550/x570 generation methods)? Are both of methods of > > access > > > failed? > > > > > > I have hoped B660 boards have same access method as x670 boards at least > > :-( > > > > [93233.798384] nct6775: Can't read ChipID by Asus WMI. > > [93233.798386] nct6775: No dmi definition `ROG STRIX B660-I GAMING > > WIFI`:`ASUSTeK COMPUTER INC.` > > [93233.798446] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > > [93233.798449] ACPI Warning: SystemIO range > > 0x0000000000000295-0x0000000000000296 conflicts with OpRegion > > 0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204) > > [93233.798452] ACPI: OSL: Resource conflict; ACPI support missing from > > driver? > > But if I add the board to the asus_acpi_boards, it works but with: > > [93515.558164] nct6775: Using Asus ACPI to access 0xc1 chip. > [93515.558166] nct6775: No dmi definition `ROG STRIX B660-I GAMING > WIFI`:`ASUSTeK COMPUTER INC.` > [93515.558229] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > > So I guess this is a better approach for my case? It should be, its near to correct way as its designed by ASUS. Its not clear for now how to make such calls by WMI, i suppose that they have changed WMI method ID to some different or hide it behind other methods. Look to the X670 patch discussion: https://patchwork.kernel.org/project/linux-hwmon/patch/20221018173428.71080-1-ahmad@khalifa.ws/ Created attachment 303333 [details]
Asus WMI for nct6775 v6.0 base (2022.12.01)
Added:
* PRIME B450-PLUS
* ROG STRIX B660-I GAMING WIFI
The MB "ROG CROSSHAIR VIII HERO" is already in the supported list. There is a wi-fi edition as well. Can it be added to the allow list? $ cat /sys/class/dmi/id/board_name ROG CROSSHAIR VIII HERO (WI-FI) I built the nct6775* code with this name included as a module using dkms and tested it for a few weeks with kernels 6.0.1[0-2] on Fedora 37 successfully. [30073.435475] nct6775: Using Asus WMI to access 0xc1 chip. [30073.435509] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 Created attachment 303466 [details]
Asus WMI for nct6775 v6.1 base (2022.12.24)
Simplified version of patch with removed custom i2c adapter and reworked access to sensors on previous generation of boards (<=AMD B550/X570) and additional new generation boards(AMD B650/X670).
B550/X570 style:
"CROSSHAIR VI HERO", // use custom port definition
"PRIME B360-PLUS",
"PRIME B450-PLUS", // use custom port definition
"PRIME B450M-GAMING II", // use custom port definition
"PRIME B450M-GAMING/BR", // use custom port definition
"PRIME B460-PLUS",
"PRIME B550-PLUS",
"PRIME B550M-A",
"PRIME B550M-A (WI-FI)",
"PRIME B550M-A AC",
"PRIME B550M-A WIFI II",
"PRIME B550M-K",
"PRIME H410M-R",
"PRIME X370-PRO", // use custom port definition
"PRIME X470-PRO", // use custom port definition
"PRIME X570-P",
"PRIME X570-PRO",
"PRO H410T",
"Pro B550M-C",
"Pro WS X570-ACE",
"ProArt B550-CREATOR",
"ProArt X570-CREATOR WIFI",
"ProArt Z490-CREATOR 10G",
"ROG CROSSHAIR VI EXTREME", // use custom port definition
"ROG CROSSHAIR VI HERO (WI-FI AC)", // use custom port definition
"ROG CROSSHAIR VII HERO", // use custom port definition
"ROG CROSSHAIR VII HERO (WI-FI)", // use custom port definition
"ROG CROSSHAIR VIII DARK HERO",
"ROG CROSSHAIR VIII EXTREME",
"ROG CROSSHAIR VIII FORMULA",
"ROG CROSSHAIR VIII HERO",
"ROG CROSSHAIR VIII HERO (WI-FI)",
"ROG CROSSHAIR VIII IMPACT",
"ROG MAXIMUS XI HERO",
"ROG MAXIMUS XI HERO (WI-FI)",
"ROG STRIX B350-F GAMING", // use custom port definition
"ROG STRIX B350-I GAMING", // use custom port definition
"ROG STRIX B450-E GAMING", // use custom port definition
"ROG STRIX B450-F GAMING", // use custom port definition
"ROG STRIX B450-F GAMING II", // use custom port definition
"ROG STRIX B450-I GAMING", // use custom port definition
"ROG STRIX B550-A GAMING",
"ROG STRIX B550-E GAMING",
"ROG STRIX B550-F GAMING",
"ROG STRIX B550-F GAMING (WI-FI)",
"ROG STRIX B550-F GAMING WIFI II",
"ROG STRIX B550-I GAMING",
"ROG STRIX B550-XE GAMING (WI-FI)",
"ROG STRIX X370-F GAMING", // use custom port definition
"ROG STRIX X370-I GAMING", // use custom port definition
"ROG STRIX X470-F GAMING", // use custom port definition
"ROG STRIX X470-I GAMING", // use custom port definition
"ROG STRIX X570-E GAMING",
"ROG STRIX X570-E GAMING WIFI II",
"ROG STRIX X570-F GAMING",
"ROG STRIX X570-I GAMING",
"ROG STRIX Z390-E GAMING",
"ROG STRIX Z390-F GAMING",
"ROG STRIX Z390-H GAMING",
"ROG STRIX Z390-I GAMING",
"ROG STRIX Z490-A GAMING",
"ROG STRIX Z490-E GAMING",
"ROG STRIX Z490-F GAMING",
"ROG STRIX Z490-G GAMING",
"ROG STRIX Z490-G GAMING (WI-FI)",
"ROG STRIX Z490-H GAMING",
"ROG STRIX Z490-I GAMING",
"TUF B450 PLUS GAMING", // use custom port definition
"TUF GAMING B450-PLUS II", // use custom port definition
"TUF GAMING B550-PLUS",
"TUF GAMING B550-PLUS WIFI II",
"TUF GAMING B550-PRO",
"TUF GAMING B550M-E",
"TUF GAMING B550M-E (WI-FI)",
"TUF GAMING B550M-PLUS",
"TUF GAMING B550M-PLUS (WI-FI)",
"TUF GAMING B550M-PLUS WIFI II",
"TUF GAMING X570-PLUS",
"TUF GAMING X570-PLUS (WI-FI)",
"TUF GAMING X570-PRO (WI-FI)",
"TUF GAMING Z490-PLUS",
"TUF GAMING Z490-PLUS (WI-FI)",
"Z490-GUNDAM (WI-FI)",
B650/X670:
"PRIME B650-PLUS",
"PRIME B650M-A",
"PRIME B650M-A (WI-FI)",
"ProArt B660-CREATOR D4",
"ProArt X670E-CREATOR WIFI",
"ProArt Z790-CREATOR WIFI", // use custom port definition
"ROG CROSSHAIR X670E EXTREME",
"ROG CROSSHAIR X670E GENE",
"ROG CROSSHAIR X670E HERO",
"ROG MAXIMUS XIII EXTREME GLACIAL",
"ROG MAXIMUS Z690 EXTREME",
"ROG MAXIMUS Z690 EXTREME GLACIAL",
"ROG MAXIMUS Z790 EXTREME", // use custom port definition
"ROG STRIX B650E-E GAMING (WI-FI)",
"ROG STRIX B650E-F GAMING (WI-FI)",
"ROG STRIX B660-I GAMING WIFI",
"ROG STRIX X670E-A GAMING WIFI",
"ROG STRIX X670E-E GAMING WIFI",
"ROG STRIX X670E-F GAMING WIFI",
"ROG STRIX X670E-I GAMING WIFI",
"ROG STRIX Z590-A GAMING WIFI II",
"ROG STRIX Z690-A GAMING WIFI D4",
"TUF GAMING Z590-PLUS WIFI",
By mutex lock:
DMI_MATCH_ASUS_NONWMI_BOARD("P8Z68-V LX", &acpi_board_LPCB_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("CROSSHAIR VI HERO", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX APEX", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX CODE", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX EXTREME", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX FORMULA", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS IX HERO", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("MAXIMUS VII HERO", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("P8H67", &acpi_board_LPCB_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("PRIME B450M-GAMING/BR", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("PRIME B450M-GAMING II", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("PRIME B450-PLUS", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("PRIME X370-PRO", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("PRIME X470-PRO", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("PRIME Z270-A", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ProArt Z790-CREATOR WIFI", &acpi_board_0LPC_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VI EXTREME", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VI HERO (WI-FI AC)", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VII HERO", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG CROSSHAIR VII HERO (WI-FI)", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG MAXIMUS X HERO", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG MAXIMUS Z790 EXTREME", &acpi_board_0LPC_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B350-F GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B350-I GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-E GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-F GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-F GAMING II", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX B450-I GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X370-F GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X370-I GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X470-F GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX X470-I GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("ROG STRIX Z370-H GAMING", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270E-GAMING", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270F-GAMING", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270G-GAMING", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("STRIX-Z270H-GAMING", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("TUF B450 PLUS GAMING", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("TUF GAMING B450-PLUS II", &acpi_board_SBRG_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("TUF Z270 MARK 1", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("Z170-DELUXE", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("Z170M-PLUS", &acpi_board_GPEM_MUTEX),
DMI_MATCH_ASUS_WMI_BOARD("Z270-WS", &acpi_board_GPEM_MUTEX),
If boards are in several lists, access could be possible by several methods.
If new patch will work for you, I will start to prepare patches for upstream review(except mutex changes).
Boards with "use custom port definition" mark could be in such patches only after test with real board as such boards use little different method definitions than in fully tested boards.
Created attachment 303467 [details]
signature.asc
Sehr geehrte Damen und Herren, vielen Dank für Ihre Nachricht. Ich bin am 9.1. wieder im Büro. Mit freundlichen Grüßen Thomas Langkamp, Dozent für Statistik und Wissenschaftliche Arbeit MSH Medical School Hamburg
(In reply to Denis Pauk from comment #278) I was succesfull in enabling the monitoring for my Asus X670-P motherboard on kernel 6.1.2 running on Almalinux. First of all I added my board to DMI section of you r patch and second I added it to asus_wmi_sensors. The patch didn't apply fully though on ML linux but manually editing nct6775-platform was trivial for me (I just needed to add Asus X670-P to the list and didn't bother to sort out the differences in the list from the patch and linux 6.1.2). I still need to modprobe nct6775 and lmsensors doesn't detect my sensors OOTB. But the module loads cleanly and I see sensors readings :) nct6799-isa-0290 Adapter: ISA adapter in0: 1.21 V (min = +0.00 V, max = +1.74 V) in1: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in2: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.34 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in5: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM in6: 784.00 mV (min = +0.00 V, max = +0.00 V) ALARM in7: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.30 V (min = +0.00 V, max = +0.00 V) ALARM in9: 1.67 V (min = +0.00 V, max = +0.00 V) ALARM in10: 560.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 552.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM in13: 496.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 424.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 681 RPM (min = 0 RPM) fan2: 512 RPM (min = 0 RPM) fan3: 639 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +30.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +34.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +38.0°C sensor = thermistor AUXTIN1: +19.0°C sensor = thermistor AUXTIN2: +20.0°C sensor = thermistor AUXTIN3: +73.0°C sensor = thermistor PECI Agent 0 Calibration: +35.5°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C TSI0_TEMP: +46.4°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled Not all is correct (for example one of the 2 case fans is missing from the list) but at least I'm getting somewhere, thanx! :) Created attachment 303548 [details] Asus WMI for nct6775 v6.1 base (2023.01.07) (In reply to Jeroen Beerstra from comment #280) (In reply to Slawomir Stepien from comment #274) Could you check with new patch? It contains updated Fan and Temperature sensors support. https://patchwork.kernel.org/project/linux-hwmon/patch/20221228135744.281752-1-linux@roeck-us.net/ https://patchwork.kernel.org/project/linux-hwmon/patch/20230102212857.5670-1-zev@bewilderbeest.net/ Looks good to me: $ sensors k10temp-pci-00c3 Adapter: PCI adapter Tctl: +64.0°C Tccd1: +35.4°C Tccd2: +35.1°C nct6799-isa-0290 Adapter: ISA adapter in0: 1.37 V (min = +0.00 V, max = +1.74 V) in1: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in2: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.34 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in5: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM in6: 752.00 mV (min = +0.00 V, max = +0.00 V) ALARM in7: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.30 V (min = +0.00 V, max = +0.00 V) ALARM in9: 1.67 V (min = +0.00 V, max = +0.00 V) ALARM in10: 560.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 560.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 1.03 V (min = +0.00 V, max = +0.00 V) ALARM in13: 496.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 424.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 755 RPM (min = 0 RPM) fan2: 819 RPM (min = 0 RPM) fan3: 712 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 674 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +31.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +36.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +39.5°C sensor = thermistor AUXTIN1: +19.0°C sensor = thermistor AUXTIN2: +20.0°C sensor = thermistor AUXTIN3: +73.0°C sensor = thermistor PECI Agent 0 Calibration: +54.0°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C TSI0_TEMP: +64.5°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled amdgpu-pci-0e00 Adapter: PCI adapter vddgfx: 1.34 V vddnb: 1.01 V edge: +41.0°C PPT: 55.25 W Linux beerstra 6.1.4-1.el9_1.beerstra.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 7 19:36:39 CET 2023 x86_64 x86_64 x86_64 GNU/Linux The patch didn't apply cleanly to 6.1.4 though, but that is because some boards were already included. Voltages seem off though. Created attachment 303610 [details]
Asus WMI for nct6775 v6.1 base (2023.01.15)
Rebased patch to new commits from hwmon-next
I have the same or related issue with Asus Pro WS W680-ACE IPMI motherboard. The following dmesg output is produced when I'm trying to "modprobe nct6775" and lm_sensors do not show any PWM fan/temp values from this chip: [ 1001.509854] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 [ 1001.509868] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\RMTW.SHWM) (20220331/utaddress-204) [ 1001.509880] ACPI: OSL: Resource conflict; ACPI support missing from driver? $ cat /sys/class/dmi/id/board_name Pro WS W680-ACE IPMI $ zcat /proc/config.gz | grep -i asus CONFIG_USB_PEGASUS=m CONFIG_TABLET_USB_PEGASUS=m CONFIG_SENSORS_ASUS_WMI=m CONFIG_SENSORS_ASUS_EC=m CONFIG_HID_ASUS=m CONFIG_ASUS_LAPTOP=m CONFIG_ASUS_WIRELESS=m CONFIG_ASUS_WMI=m CONFIG_ASUS_NB_WMI=m CONFIG_ASUS_TF103C_DOCK=m $ lsmod | grep -i -E \(wmi\|asus\) wmi 32768 1 video $ uname -a Linux calculate 6.1.7-gentoo-dist #1 SMP PREEMPT_DYNAMIC Wed Jan 18 12:31:42 -00 2023 x86_64 13th Gen Intel(R) Core(TM) i9-13900 GenuineIntel GNU/Linux Is there any way how I can assist in resolving it, testing patches etc? Created attachment 303655 [details] Asus WMI for nct6775 v6.1 base (2023.01.26) (In reply to Nikita Koval from comment #284) > I have the same or related issue with Asus Pro WS W680-ACE IPMI motherboard. > The following dmesg output is produced when I'm trying to "modprobe nct6775" > and lm_sensors do not show any PWM fan/temp values from this chip: Could you try with such path? Difference with previous patch is your board added to asus_msi_boards. ASUS EC controller endpoint looks not implemented for you board and only nct6775 is required for show sensors data. (In reply to Denis Pauk from comment #285) > Created attachment 303655 [details] > Asus WMI for nct6775 v6.1 base (2023.01.26) > Thanks for the patch! It didn't work right away with my current 6.1.7-gentoo kernel though, but I was able to apply it against vanilla v6.0. The sensors from 6798D chip seem working now (at least the ones that I care about, like fan values): nct6798-isa-0290 Adapter: ISA adapter in0: 144.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM in2: 3.41 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.33 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM in5: 0.00 V (min = +0.00 V, max = +0.00 V) ALARM in6: 0.00 V (min = +0.00 V, max = +0.00 V) in7: 3.41 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.23 V (min = +0.00 V, max = +0.00 V) ALARM in9: 528.00 mV (min = +0.00 V, max = +0.00 V) ALARM in10: 504.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 0.00 V (min = +0.00 V, max = +0.00 V) ALARM in12: 1.06 V (min = +0.00 V, max = +0.00 V) ALARM in13: 392.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 896.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 1124 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +28.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +38.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: -128.0°C sensor = thermistor AUXTIN1: +25.0°C sensor = thermistor AUXTIN2: +127.0°C sensor = thermistor AUXTIN3: +32.0°C sensor = thermistor PECI Agent 0 Calibration: +38.5°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +55.0°C PCH_CPU_TEMP: +0.0°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled I will be using this kernel for a while and will report if I notice any related issues. Created attachment 303659 [details]
dsdt.dat Z170 PRO GAMING/AURA
Hello, would it be possible to add support for Asus Z170 PRO GAMING/AURA?
cat /sys/class/dmi/id/board_name:
Z170 PRO GAMING/AURA
dmesg:
2023-01-27T13:10:42+0100 kernel: nct6775: Enabling hardware monitor logical device mappings.
2023-01-27T13:10:42+0100 kernel: nct6775: Found NCT6793D or compatible chip at 0x2e:0x290
2023-01-27T13:10:42+0100 kernel: ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20220331/utaddress-204)
2023-01-27T13:10:42+0100 kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver?
Setting acpi_enforce_resources=lax kernel parameter results in 'sensors' returning much more data like fan speed, voltage etc.
Thank you for your work!
Created attachment 303660 [details] Asus WMI for nct6775 v6.1 base (2023.01.28) (In reply to Robert Kling from comment #287) > Created attachment 303659 [details] > dsdt.dat Z170 PRO GAMING/AURA > > Hello, would it be possible to add support for Asus Z170 PRO GAMING/AURA? > > cat /sys/class/dmi/id/board_name: > Z170 PRO GAMING/AURA Could you please check now? There will be used mutex lock for access to sensors. Note, i have also checked such boards and it will be without support in any currently known way as no mutex used inside access methods: * Z170I PRO GAMING * B150I PRO GAMING/WIFI/AURA * B150I PRO GAMING/AURA * Z97-PRO GAMER (no definition like nct6775 sensor) (In reply to Denis Pauk from comment #288) > Created attachment 303660 [details] > Asus WMI for nct6775 v6.1 base (2023.01.28) > > (In reply to Robert Kling from comment #287) > > Created attachment 303659 [details] > > dsdt.dat Z170 PRO GAMING/AURA > > > > Hello, would it be possible to add support for Asus Z170 PRO GAMING/AURA? > > > > cat /sys/class/dmi/id/board_name: > > Z170 PRO GAMING/AURA > > Could you please check now? There will be used mutex lock for access to > sensors. > > Note, i have also checked such boards and it will be without support in any > currently known way as no mutex used inside access methods: > * Z170I PRO GAMING > * B150I PRO GAMING/WIFI/AURA > * B150I PRO GAMING/AURA > * Z97-PRO GAMER (no definition like nct6775 sensor) The patch didn't apply to 6.1.8 cleanly, some mainboards were already mentioned in nct6775-platform.c. I tried to adapt and it applied/compiled. But sensors show no fan speed & voltages. dmesg showing: 2023-01-28T22:44:58+0100 kernel: nct6775: No such ASUS mutex: \_GPE.MUT0 2023-01-28T22:44:58+0100 kernel: nct6775: Enabling hardware monitor logical device mappings. 2023-01-28T22:44:58+0100 kernel: nct6775: Found NCT6793D or compatible chip at 0x2e:0x290 2023-01-28T22:44:58+0100 kernel: ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20220331/utaddress-204) 2023-01-28T22:44:58+0100 kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? Not sure if I made an error, I'll try 6.1.0 when I have some more time. Created attachment 303662 [details] Asus WMI for nct6775 v6.1.8 base (2023.01.29) (In reply to Robert Kling from comment #289) > dmesg showing: > > 2023-01-28T22:44:58+0100 kernel: nct6775: No such ASUS mutex: \_GPE.MUT0 > 2023-01-28T22:44:58+0100 kernel: nct6775: Enabling hardware monitor logical > device mappings. > 2023-01-28T22:44:58+0100 kernel: nct6775: Found NCT6793D or compatible chip > at 0x2e:0x290 > 2023-01-28T22:44:58+0100 kernel: ACPI Warning: SystemIO range > 0x0000000000000295-0x0000000000000296 conflicts with OpRegion > 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20220331/utaddress-204) > 2023-01-28T22:44:58+0100 kernel: ACPI: OSL: Resource conflict; ACPI support > missing from driver? > > Not sure if I made an error, I'll try 6.1.0 when I have some more time. Could you try with such one? Change with previous one is usage "\\_SB.PCI0.LPCB.SIO1.MUT0" mutex. Note - it will be unsafe, looks like your board doesn't use/export mutex before access to sensors and change settings of fans. So code just uses IO lock available in dsdt. (In reply to Denis Pauk from comment #290) > Created attachment 303662 [details] > Asus WMI for nct6775 v6.1.8 base (2023.01.29) > > Could you try with such one? > > Change with previous one is usage "\\_SB.PCI0.LPCB.SIO1.MUT0" mutex. Note - > it will be unsafe, looks like your board doesn't use/export mutex before > access to sensors and change settings of fans. So code just uses IO lock > available in dsdt. That seems to have done the trick! kernel: nct6775: Using Asus WMI mutex: \_SB.PCI0.LPCB.SIO1.MUT0 kernel: nct6775: Enabling hardware monitor logical device mappings. kernel: nct6775: Found NCT6793D or compatible chip at 0x2e:0x290 Not sure if more info from dmesg would be useful for you. sensors is outputting fan/voltage data from nct6793-isa-0290 now! I don't want to take up too much of your time for something that's not really crucial, but how unsafe is it? I let the mainboard/bios handle cpu/aux fan speed, I'm not running any fan control programs at the moment. Would that be fine? Thank you very much for your help & time! (In reply to Robert Kling from comment #291) > I let the mainboard/bios handle > cpu/aux fan speed, I'm not running any fan control programs at the moment. > Would that be fine? It depends on luck, bioses, hw schematic and so on. Main issue is bios does not provide known methods for sensor access and does not use global mutex before access to the region related to sensors, and mutual access could be not possible with such bios implementation. It works without known issues for other boards with mutex lock (P8H67, X99-E WS/USB 3.1). Other boards could have issues, like example it can be such: https://github.com/electrified/asus-wmi-sensors#known-issues. Its different driver but issues could be the same. > The WMI implementation in some of Asus' BIOSes is buggy. This can result in > fans stopping, fans getting stuck at max speed, or temperature readouts > getting stuck. This is not an issue with the driver, but the BIOS. The Prime > X470 Pro seems particularly bad for this. The more frequently the WMI > interface is polled the greater the potential for this to happen. Until you > have subjected your computer to an extended soak test while polling the > sensors frequently, don't leave you computer unattended. I can personally say > I've seen the issue on the Crosshair VII with BIOS 2606 and a Ryzen 2700X, > upgrading to 3004 rectified the issue. Or https://bugzilla.kernel.org/show_bug.cgi?id=204807#c37 > Sensor hardware frequently uses indexed addressing, which means that > accessing a sensor requires something like the following: > > 1) Write the desired sensor to the index register > 2) Read the sensor value from the data register > > These can't occur simultaneously, so if both the OS and the firmware are > accessing it you risk ending up with something like: > 1) Write sensor A to the index register (from the OS) > 2) Write sensor B to the index register (from the firmware) > 3) Read the sensor value from the data register (returns the value of sensor > B to the firmware) > 4) Read the sensor value from the data register (returns the value of sensor > B to the OS) Or https://bugzilla.kernel.org/show_bug.cgi?id=204807#c69 > the lm_sensors sensors-detect script had overvolted his RAM ruining both his > expensive high-end RAM as well as his expensive top of the line CPU. The user > was surprisingly relaxed about all this, which I really appreciated. > > And that was while the script was not doing anything which we (the > developers) considered dangerous. But the motherboard had a funky setup > causing a SMbus *read* transaction to change the voltage. Thank you! Is this stable on a 5.19 kernel? Having a TUF GAMING X570-PLUS board and hasn't tried the patch before. Now I was getting the Ubuntu HWE kernel 5.19 for Jammy. Can I run lm-sensors and having the sensors running without trouble? For me, on 6.1 ML via elrepo. I needed to apply patch and modprobe nct6775. Lmsensors did not detect my sensors. Other than that it just works :) (In reply to Jeroen Beerstra from comment #294) > For me, on 6.1 ML via elrepo. I needed to apply patch and modprobe nct6775. > Lmsensors did not detect my sensors. Other than that it just works :) Isn't this patch included in kernels after 5.17? (In reply to Jonathan from comment #103) > Hi, > (oh. Could've put my comment in the attachment comment... duh) > I applied Denis Pauk patch today, (how I did it described in > https://gist.github.com/greenbigfrog/26f948c9d86f1cb2fd23bfeaa23ca068 ). hi I have updated the gist to compile on newer kernels >= 5.17 https://gist.github.com/mennucc/2a322744612a7e21debfa001e987c15a this gist does not patch; but anybody can add their MB to the whitelist easily thanks a. ON 6.1.12 I still needed to apply it. Guess it’s included in 6.2 (RC atm)? But I would love to stand corrected, compiling kernels goes like a tornado on a highend Ryzen but still is a task I would like to skip nowadays...
> Op 16 feb. 2023, om 12:01 heeft bugzilla-daemon@kernel.org het volgende
> geschreven:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=204807
>
> --- Comment #295 from Pär Ekholm (forum1@m.pekholm.org) ---
> (In reply to Jeroen Beerstra from comment #294)
>> For me, on 6.1 ML via elrepo. I needed to apply patch and modprobe nct6775.
>> Lmsensors did not detect my sensors. Other than that it just works :)
>
> Isn't this patch included in kernels after 5.17?
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are on the CC list for the bug.
(In reply to Pär Ekholm from comment #293) > Is this stable on a 5.19 kernel? Having a TUF GAMING X570-PLUS board and > hasn't tried the patch before. Now I was getting the Ubuntu HWE kernel 5.19 > for Jammy. Can I run lm-sensors and having the sensors running without > trouble? You board is supported by 5.19 kernel, and does not have any know issues. Apply additional patch is not required for your board. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hwmon/nct6775-platform.c?h=v5.19#n1090 After initial merge code does not have any significant changes related to asus bioses support, just add new board to list of supported boards. New kernel 6.3+ could have additional support of x670 boards. Merge window will be in one or two weeks after that will be more information about exact list of supported boards by upstream kernel. Look to https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tree/drivers/hwmon/nct6775-platform.c?h=hwmon-next#n1115 Thank you. hi all. I have added my mobo a week ago to the list. It works fine. Someone may add it to the whitelist. # cat /sys/class/dmi/id/board_name PRIME A520M-A II Thanks. a. Created attachment 303789 [details] Asus WMI for nct6775 v6.2 base (2023.02.26) * Rebased over v6.2 * Added more AMD A520 boards. * Several boards use different mutex name, could be regression - code is unchecked for now. (In reply to A. M. from comment #299) > hi all. > I have added my mobo a week ago to the list. It works fine. Someone may add > it to the whitelist. > > # cat /sys/class/dmi/id/board_name > > PRIME A520M-A II > > Thanks. a. Could you please recheck with new patch? Created attachment 303816 [details]
Asus WMI for nct6775 v6.2 base (2023.02.28)
Add A320/B350/B760/Z590 boards.
Created attachment 303833 [details] proart-x670e-dmi.patch hi denis, i've tested patch for 6.1.8 (https://bugzilla.kernel.org/show_bug.cgi?id=204807#c290) against gentoo 6.1.12 kernel on ProArt X670E-CREATOR WIFI. seems to work ok. i attached a patch to put this board in asus_wmi_info_table, as this also appears to make the module load automatically with a modalias. for the mutex, i checked my DSDT and acpi_board_SBRG_MUTEX seems to exist there, but i am very much a novice in kernel programming so i am unsure if this is correct. if it helps i can attach my DSDT for this board. i would very much like for this to be included in a future kernel, so if i can help further let me know. here is my sensor reading. mischief@beast:~ $ dmesg|grep nct6775 [ 6.678325] nct6775: Found NCT6799D or compatible chip at 0x2e:0x290 mischief@beast:~ $ sensors nct6799-* nct6799-isa-0290 Adapter: ISA adapter in0: 1.34 V (min = +0.00 V, max = +1.74 V) in1: 1000.00 mV (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.01 V (min = +0.00 V, max = +0.00 V) ALARM in5: 1.01 V (min = +0.00 V, max = +0.00 V) ALARM in6: 1.15 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.30 V (min = +0.00 V, max = +0.00 V) ALARM in9: 1.66 V (min = +0.00 V, max = +0.00 V) ALARM in10: 528.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 528.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.28 V (min = +0.00 V, max = +0.00 V) ALARM in14: 1.23 V (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 849 RPM (min = 0 RPM) fan3: 841 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) fan6: 0 RPM (min = 0 RPM) fan7: 0 RPM (min = 0 RPM) SYSTIN: +37.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor CPUTIN: +41.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +18.0°C sensor = thermistor AUXTIN1: +23.0°C sensor = thermistor AUXTIN2: +23.0°C sensor = thermistor AUXTIN3: +14.0°C sensor = thermistor PECI Agent 0 Calibration: +41.5°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C PCH_CPU_TEMP: +0.0°C TSI0_TEMP: +50.5°C intrusion0: OK intrusion1: ALARM beep_enable: disabled I'm Using ASUS H97-ProGamer motherboard and i still can't sensors on kernel 6.2.2 without using "acpi_enforce_resources=lax", i haven't seen anyone else mention the asus-h97-progamer motherboard but this mb is having the same issue as all others that were mentioned (In reply to barfin from comment #303) > I'm Using ASUS H97-ProGamer motherboard and i still can't sensors on kernel > 6.2.2 without using "acpi_enforce_resources=lax", i haven't seen anyone else > mention the asus-h97-progamer motherboard but this mb is having the same > issue as all others that were mentioned Uefi dump of H97 board does not have any known APIs, Could you please check what sensor is detected on board after "acpi_enforce_resources=lax"? it can be showed in dmesg/sensors output or in dmidecode output. (In reply to Nick Owens from comment #302) (In reply to A. M. from comment #299) Thank you, I have found issues in my script for detect available port definitions/methods in UEFI dump. I will send patch to upstream with new boards after fix issues and rescan board dumps. (In reply to Denis Pauk from comment #304) > (In reply to barfin from comment #303) > > I'm Using ASUS H97-ProGamer motherboard and i still can't sensors on kernel > > 6.2.2 without using "acpi_enforce_resources=lax", i haven't seen anyone > else > > mention the asus-h97-progamer motherboard but this mb is having the same > > issue as all others that were mentioned > > Uefi dump of H97 board does not have any known APIs, Could you please check > what sensor is detected on board after "acpi_enforce_resources=lax"? it can > be showed in dmesg/sensors output or in dmidecode output. > > (In reply to Nick Owens from comment #302) > (In reply to A. M. from comment #299) > Thank you, I have found issues in my script for detect available port > definitions/methods in UEFI dump. I will send patch to upstream with new > boards after fix issues and rescan board dumps. here's all the outputs, the file that have "_lax" at the end were captured when acpi_enforce_resources=lax was used https://drive.proton.me/urls/8S727K80A4#MdPfNfkyxSbq Created attachment 303946 [details]
ASUS H97-Progamer sensors output with acpi_enforce_resources=lax
Created attachment 303947 [details]
ASUS H97-Progamer dmesg
Created attachment 303968 [details] Asus WMI for nct6775 v6.2 base (2023.03.16) Clean up previous patch, add more boards. (In reply to barfin from comment #305) > > here's all the outputs, the file that have "_lax" at the end were captured > when acpi_enforce_resources=lax was used > https://drive.proton.me/urls/8S727K80A4#MdPfNfkyxSbq Could you please check messages in dmesg without lax about resource conflicts? (In reply to Denis Pauk from comment #308) > Created attachment 303968 [details] > Asus WMI for nct6775 v6.2 base (2023.03.16) > > Clean up previous patch, add more boards. > How do I apply this patch to 6.2.6? It reports: Reversed (or previously applied) patch detected! Assume -R? And not all changes apply :/ Created attachment 303973 [details] Asus WMI for nct6775 v6.2.7 base (2023.03.17) (In reply to Jeroen Beerstra from comment #309) > (In reply to Denis Pauk from comment #308) > > Created attachment 303968 [details] > > Asus WMI for nct6775 v6.2 base (2023.03.16) > > > > Clean up previous patch, add more boards. > > > > How do I apply this patch to 6.2.6? It reports: > Reversed (or previously applied) patch detected! Assume -R? > > And not all changes apply :/ Could you please check new one ? I have rebased patch to 6.2.7 (In reply to Denis Pauk from comment #310) > Could you please check new one ? I have rebased patch to 6.2.7 Applies, compiles, and works just fine. Thank you very much for your hard work, hope all of this lands in 6.3. Please also add: cat /sys/class/dmi/id/board_name Pro H610T D4 It's the same board (and uses the same chip) as the H410T but with a newer 1700 socket. Thanks again! Created attachment 303985 [details] Asus WMI for nct6775 v6.2.7 base (2023.03.20) Added additional boards based on data from https://github.com/linuxhw/ACPI/tree/master/Desktop/ASUSTek%20Computer (In reply to renedis from comment #312) > Please also add: > > cat /sys/class/dmi/id/board_name > Pro H610T D4 > > > It's the same board (and uses the same chip) as the H410T but with a newer > 1700 socket. > > Thanks again! Thank you! (In reply to Denis Pauk from comment #308) > Created attachment 303968 [details] > Asus WMI for nct6775 v6.2 base (2023.03.16) > > Clean up previous patch, add more boards. > > (In reply to barfin from comment #305) > > > > here's all the outputs, the file that have "_lax" at the end were captured > > when acpi_enforce_resources=lax was used > > https://drive.proton.me/urls/8S727K80A4#MdPfNfkyxSbq > > Could you please check messages in dmesg without lax about resource > conflicts? sure https://gist.github.com/barfin/943c219a5a6bd8aa15778d8c80b2786c Created attachment 304004 [details]
acpidump -b for ROG STRIX Z690-E GAMING WIFI
acpidump -b for the ROG STRIX Z690-E GAMING WIFI
Created attachment 304005 [details]
dmidecode for ROG STRIX Z690-E GAMING WIFI
Created attachment 304010 [details]
ASUS PRIME Z690-P ACPI table dump (acpidump -b)
I'm attaching the ACPI table dump of an ASUS PRIME Z690-P board. As far as I can see it uses the classic WMI method, so it should work by adding it to the asus_wmi_boards list at nct6775-platform.c.
Created attachment 304011 [details] Asus WMI for nct6775 v6.2.7 base (2023.03.23) Updated version of the patch with more boards. Full list of boards: https://github.com/asus-wmi-boards-sensors/asus-board-dsdt/blob/master/README.md (In reply to barfin from comment #314) > > sure > https://gist.github.com/barfin/943c219a5a6bd8aa15778d8c80b2786c Thank you, I dont see any suspicious conflicts, could you please try load sensor module and check errors on load with lax. (In reply to bruno from comment #316) > Created attachment 304005 [details] > dmidecode for ROG STRIX Z690-E GAMING WIFI (In reply to Alejandro González from comment #317) > Created attachment 304010 [details] > ASUS PRIME Z690-P ACPI table dump (acpidump -b) Thank you, I will add boards to next upstream patch. (In reply to Jeroen Beerstra from comment #311) > (In reply to Denis Pauk from comment #310) > > Could you please check new one ? I have rebased patch to 6.2.7 > > Applies, compiles, and works just fine. Thank you very much for your hard > work, hope all of this lands in 6.3. Same for 6.2.8. I did notice these warnings though: drivers/hwmon/nct6775-platform.c:1325:21: warning: 'acpi_board_0LPC_MUTEX' defined but not used [-Wunused-variable] 1325 | DMI_ASUS_BOARD_INFO(acpi_board_0LPC_MUTEX, "\\_SB.PC00.LPCB.SIO1.MUT0"); | ^~~~~~~~~~~~~~~~~~~~~ drivers/hwmon/nct6775-platform.c:1319:31: note: in definition of macro 'DMI_ASUS_BOARD_INFO' 1319 | static struct acpi_board_info name = { \ | ^~~~ drivers/hwmon/nct6775-platform.c:1324:21: warning: 'acpi_board_LPCB_MUTEX' defined but not used [-Wunused-variable] 1324 | DMI_ASUS_BOARD_INFO(acpi_board_LPCB_MUTEX, "\\_SB_.PCI0.LPCB.SIO1.MUT0"); | ^~~~~~~~~~~~~~~~~~~~~ drivers/hwmon/nct6775-platform.c:1319:31: note: in definition of macro 'DMI_ASUS_BOARD_INFO' 1319 | static struct acpi_board_info name = { \ | ^~~~ drivers/hwmon/nct6775-platform.c:1323:21: warning: 'acpi_board_GPEM_MUTEX' defined but not used [-Wunused-variable] 1323 | DMI_ASUS_BOARD_INFO(acpi_board_GPEM_MUTEX, "\\_GPE.MUT0"); | ^~~~~~~~~~~~~~~~~~~~~ drivers/hwmon/nct6775-platform.c:1319:31: note: in definition of macro 'DMI_ASUS_BOARD_INFO' 1319 | static struct acpi_board_info name = { \ | ^~~~ Since they seem pretty harmless to me, I didn't report them earlier. Hi, I wonder why the board B550M-K has disappeared from the final patch integrated in the kernel sources. It's somewhat the same board as B550M-A, which is included. Moreover, it's in the list in comment #278: https://bugzilla.kernel.org/show_bug.cgi?id=204807#c278 An unfortunate omission? :) Thanks! Created attachment 304071 [details] Asus WMI for nct6775 v6.2.9 base (2023.04.01) Updated patch version. (In reply to Mickaël Blanchard from comment #320) > Hi, > > I wonder why the board B550M-K has disappeared from the final patch > integrated in the kernel sources. It's somewhat the same board as B550M-A, > which is included. > Moreover, it's in the list in comment #278: > https://bugzilla.kernel.org/show_bug.cgi?id=204807#c278 > > An unfortunate omission? :) > > Thanks! Do you mean "PRIME B550M-K"? Both hwmon-next branch and patch have it in https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/tree/drivers/hwmon/nct6775-platform.c?h=hwmon-next&id=8a863eb1b1162653d133856702e13560f3596b85#n1076 Do you have some load issue with new patch? (In reply to Jeroen Beerstra from comment #319) > (In reply to Jeroen Beerstra from comment #311) > > (In reply to Denis Pauk from comment #310) > > > Could you please check new one ? I have rebased patch to 6.2.7 > > > > Applies, compiles, and works just fine. Thank you very much for your hard > > work, hope all of this lands in 6.3. > > Same for 6.2.8. I did notice these warnings though: Thank you, should be fixed in new patch. > (In reply to Mickaël Blanchard from comment #320)
> > Hi,
> >
> > I wonder why the board B550M-K has disappeared from the final patch
> > integrated in the kernel sources. It's somewhat the same board as B550M-A,
> > which is included.
> > Moreover, it's in the list in comment #278:
> > https://bugzilla.kernel.org/show_bug.cgi?id=204807#c278
> >
> > An unfortunate omission? :)
> >
> > Thanks!
>
> Do you mean "PRIME B550M-K"? Both hwmon-next branch and patch have it in
> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/
> tree/drivers/hwmon/nct6775-platform.c?h=hwmon-
> next&id=8a863eb1b1162653d133856702e13560f3596b85#n1076
>
> Do you have some load issue with new patch?
Yes this is the board I'm talking about.
I'm currently running 6.1.21 and the board is not included here. So I still have the load issue.
I haven't watched in the staging, I should have as indeed it's here. :)
So I guess I just have to wait the merge & backport in 6.1 branch.
Op 01-04-2023 om 15:09 schreef bugzilla-daemon@kernel.org: > https://bugzilla.kernel.org/show_bug.cgi?id=204807 > > Denis Pauk (pauk.denis@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Attachment #304011 [details]|0 |1 > is obsolete| | > > --- Comment #321 from Denis Pauk (pauk.denis@gmail.com) --- > Created attachment 304071 [details] > --> https://bugzilla.kernel.org/attachment.cgi?id=304071&action=edit > Asus WMI for nct6775 v6.2.9 base (2023.04.01) > > Updated patch version. > > > (In reply to Jeroen Beerstra from comment #319) >> (In reply to Jeroen Beerstra from comment #311) >>> (In reply to Denis Pauk from comment #310) >>>> Could you please check new one ? I have rebased patch to 6.2.7 >>> Applies, compiles, and works just fine. Thank you very much for your hard >>> work, hope all of this lands in 6.3. >> Same for 6.2.8. I did notice these warnings though: > Thank you, should be fixed in new patch. Yes it is, thank you. Created attachment 304077 [details] Asus WMI for nct6775 v6.2.9 base (2023.04.02) Added A620 several boards which have uefi bios download link on official site. (In reply to barfin from comment #314) > (In reply to Denis Pauk from comment #308) I have added ugly hack for skip resource conflicts on "H97-PRO GAMER". Could you please check that it works for your case? Created attachment 304087 [details]
Asus WMI for nct6775 v6.2.9 base (2023.04.05)
Add more H310/H370/H410 boards
Any news on 6.3 which has been released? Cannot move as of yet because zfs is not ready for 6.3 also :) Just curious, before I moved my main storage array to zfs I did boot with 6.3 and noticed my fans and temp sensors were gone again ;) I do appreaciate your efforts though, we depend on people like you to get our precious new hardware supported on Linux .... if only companies like Asus would look beyond M$ Windows. Then again, we would have the same bloatware on our beloved Linux too :D Created attachment 304223 [details]
Asus WMI for nct6775 v6.3 base (2023.05.06)
Rebased over v6.3, List of supported boards are same as previous.
Created attachment 304249 [details]
ASUS TUF B650M-PLUS WIFI
Hi, is this the correct place to also report issues with the new ASUS NCT6799D support in kernel 6.3?
I'm on an ASUS TUF GAMING B650M-PLUS WIFI , kernel 6.3.1
Trying to modprobe nct6775 fails with ENODEV, doing so with force_id=0xd428 works:
[ 1600.922632] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
[ 1600.931439] nct6775: Refusing to enable a Super-I/O device with a base I/O port 0
However, all sensor values are unlabeled.
Or did I misunderstand, and NCT6799D is not meant to be fully supported yet?
Attached are dmidecode, acpidump, and the readings from sensors.
(In reply to Jannik Glückert from comment #328) > Created attachment 304249 [details] > ASUS TUF B650M-PLUS WIFI > > Hi, is this the correct place to also report issues with the new ASUS > NCT6799D support in kernel 6.3? > > I'm on an ASUS TUF GAMING B650M-PLUS WIFI , kernel 6.3.1 > > Trying to modprobe nct6775 fails with ENODEV, doing so with force_id=0xd428 > works: > [ 1600.922632] nct6775: Found NCT6798D or compatible chip at 0x2e:0x290 > [ 1600.931439] nct6775: Refusing to enable a Super-I/O device with a base > I/O port 0 > > However, all sensor values are unlabeled. > > Or did I misunderstand, and NCT6799D is not meant to be fully supported yet? > > Attached are dmidecode, acpidump, and the readings from sensors. Upstream code has support for asus boards with such sensor. In same time upstream code does not have support for sensor itself. And need to apply additional patch from https://patchwork.kernel.org/project/linux-hwmon/patch/20221228135744.281752-1-linux@roeck-us.net/. Patch from comment #327 also contains this patch. Hello,
i've this board :
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG STRIX X670E-I GAMING WIFI
But no sensors are detect on Kernel : 6.3.3-200 (Fedora)
Can someone please help me understand where is the issue (if any) ?
Thanks a lot !
Hey, I use 6.3.9 custom kernel on Gentoo GNU/Linux and it seems that my motherboard is not (yet) supported. It is TUF GAMING B460-PLUS. I looked at 6.4.0 sources and.. voila it is there. Will wait for the next stable release, then Hello,
i've this board :
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: X99-A II
# dmesg|tail -n 3
[431341.603491] nct6775: Found NCT6791D or compatible chip at 0x2e:0x290
[431341.603501] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20210730/utaddress-204)
[431341.603510] ACPI: OSL: Resource conflict; ACPI support missing from driver?
Sensors not found, add support for access to nct6775
Thanks a lot !
Created attachment 305675 [details]
no T_SENSOR for ASUS WS X299 SAGE/10 DSDT.dsl
Product Name: WS X299 SAGE/10G
Version: Rev 1.xx
Good morning,
I have a single thermistor attached to the T_SENSOR on the motherboard which shows up in the BIOS no problem. Is there a way to get this to show up in lm-sensors or possibly provide information to help development to add this sensor ?
I have also added "GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax" with no changes.
Created attachment 305676 [details]
no T_SENSOR for ASUS WS X299 SAGE/10 DSDT.aml DSDT.dsl
Product Name: WS X299 SAGE/10G
Version: Rev 1.xx
Good morning,
I have a single thermistor attached to the T_SENSOR on the motherboard which shows up in the BIOS no problem. Is there a way to get this to show up in lm-sensors or possibly provide information to help development to add this sensor ?
I have also added "GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax" with no changes.
Not sure if this is the right place for this, if it isn't could someone please direct me to the right place.
(In reply to Denis Pauk from comment #265) > (In reply to zykr.caswell from comment #264) > > Created attachment 303116 [details] > > DSDT - X99-E-WS-USB3 - Decompiled > > > > Same or similar issue with X99-E WS/USB 3.1: > > > > nct6775: Found NCT6791D or compatible chip at 0x2e:0x290 > > ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 > conflicts > > with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) > > (20200925/utaddress-204) > > > > I've been trying to make sense of the DSDT by reading the ACPI spec, but > I'm > > not having a lot success. Built kernels 5.10, 5.19, 6.0.2, 6.03, and > several > > different versions of nct6775 driver for each including "Asus WMI for > > nct6775 v5.20 base (2022.10.20)", both in tree and as a custom DKMS module > > to no effect. > > > > I'm rather reluctant to actually try using acpi_enforce_resourses=lax, so I > > don't know for sure if that would make it work or not. I've attached my > DSDT > > as pulled from the latest BIOS update for my board from ASUS. Could someone > > take a look and confirm for me that I likely have this same problem? > > Could you please apply patch and add line with you board and recheck? Change > should be like "DMI_MATCH_ASUS_WMI_BOARD("<You board name>", > &acpi_board_LPCB_MUTEX)," near "MAXIMUS VII HERO" definition. > > Name board should be from /sys/class/dmi/id/board_name. I would like to ask if the support for the board "MAXIMUS VII HERO" will be merged to the kernel in the future? If any assistance for testing is needed I am happy to help to get this added. |