https://bugzilla.kernel.org/show_bug.cgi?id=204807 Artem S. Tashkinov (aros@xxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #42 from Artem S. Tashkinov (aros@xxxxxxx) --- (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. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
