Announcement

Collapse
No announcement yet.

Gigabyte Motherboard WMI Temperature Driver Queued Ahead Of Linux 5.13

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by birdie View Post
    Meanwhile ASUS users are screwed.
    Lol, I just love how you're linking this "discussion" you had with the kernel devs, instead of trying to hide it in a deep dark cave and erase its existence from the world (as I would do if I had been publicly ridiculed like that). Could it be that you're actually proud of yourself acting like a 12yo?

    Some choice quotes from that bug report:

    Originally posted by The Troll
    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.
    No dude, you have it all wrong: we Linux users DO care if ACPI (or whatever other standard) is properly implemented according to spec or not. We take pride in a platform that is technically sound. We do NOT want a platform that's full of hacks and workarounds, just to cater to vendors like ASUS and their half-broken crap.

    Also, hardware DOES work properly under Linux because it's not Linux that makes it work, it's the firmware. That's what controls my fans and monitors the system's temps and voltages. What does NOT work in some cases under Linux is MONITORING those sensors, which is something that MOST USERS won't ever want or need to do.

    Originally posted by Sane & polite kernel dev #1
    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.
    Originally posted by The Troll
    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.
    Originally posted by Sane & polite kernel dev #1
    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.
    Originally posted by The Troll
    This message [talking about a new message he's proposed to be printed out, even though he's just been told the current message is correct] will at least allow various Linux distros to enable the option by default [talking about "acpi_enforce_resources=lax" even though he's just been told it's freaking NOT SAFE to be enabled by default] because many are not aware of the bug.
    Originally posted by Sane & polite kernel dev #2
    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.
    Originally posted by Sane & polite kernel dev #3
    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-...s#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.
    Originally posted by Sane & polite kernel dev #3
    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).
    Originally posted by The Troll
    Multiple users use acpi_enforce_resources=lax and I haven't seen a single report that it's ever broken anything.
    Originally posted by Sane & polite kernel dev #3
    <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.
    Originally posted by The Troll
    I'm not a programmer let alone a person who understand the innards of the Linux kernel to even attempt to fix the issue
    TL;DR #1: Then please STFU and go back to your Windows.

    TL;DR #2: In other words, what we have here is a self-declared non-programmer who's b*tching to the effing KERNEL programmers (i.e. not your average script kid) about something that he's arbitrarily decided to perceive as a kernel issue on the basis that "it works on Windows lol", and who demands that it be fixed by THEM because he "can't go asking the vendors to support Linux"; all the while the kernel devs kindly trying to explain to him that it's not a problem of Linux but a problem of the vendors, and that unfortunately it's one of those things that without official vendor support the kernel devs can't provide a proper solution, like e.g. Nouveau.

    But what am I saying - this is the same guy that's been bitching for years and years against Linux and the open source model, and praising Nvidia for their utterly horrible handling of GPU driver support or Microsoft for their great product that is Windows (not).

    Seriously dude, you're a very sad person.

    Comment


    • #12
      Originally posted by skeevy420 View Post

      Type "sensors" in the terminal. I posted my terminal output in the last thread. This added the gigabyte_wmi-virtual-0 entries.
      I use another kind of motherboard getting few useless data.

      Comment


      • #13
        Originally posted by birdie View Post
        Meanwhile ASUS users are screwed.
        eh?

        The ASUS users just need to take the current asus-wmi-sensors driver and update it for their board, nbd.

        Linux users expect to have to write drivers when they buy unsupported hardware, I've written several myself.

        Comment


        • #14
          Originally posted by calc View Post

          eh?

          The ASUS users just need to take the current asus-wmi-sensors driver and update it for their board, nbd.

          Linux users expect to have to write drivers when they buy unsupported hardware, I've written several myself.
          Who said that?

          Comment


          • #15
            Originally posted by birdie View Post

            Who said that?
            That has been an unspoken assumption for years (and a bit of a joke too at times). Maybe not as far as making their own drivers, but know where to look for third party drivers or are comfortable with compiling code. Very few hardware vendors support anything besides Windows and MacOS, and when they do it's usually unofficially (with third party developers). One is expected to buy hardware that is reported as working with Linux (or at least their favorite distro) if they want a pleasant experience. If you don't, then I hope they purposely made that choice and know how to get support.

            Comment


            • #16
              Originally posted by birdie View Post

              Who said that?
              You've clearly have used Linux for long enough to know that's true as you have had a Phoronix account since 2008.

              I've been using Linux for 26 years, I just don't like creating accounts everywhere. While you don't have to write drivers as often as when I started using Linux, when there weren't drivers for nearly anything, it is still a common occurrence when you intentionally choose unsupported hardware.

              Comment


              • #17
                Originally posted by calc View Post

                You've clearly have used Linux for long enough to know that's true as you have had a Phoronix account since 2008.

                I've been using Linux for 26 years, I just don't like creating accounts everywhere. While you don't have to write drivers as often as when I started using Linux, when there weren't drivers for nearly anything, it is still a common occurrence when you intentionally choose unsupported hardware.
                I've used Linux long enough to have learned that it often doesn't support what it claims to support and this "support" often means there are kernel modules, or CUPS filters, or sane libraries for something - it means nothing in terms how well it works and if it works at outside of what a particular developer has coded.

                I mean take for instance the CPU - a computer component without which nothing works. Are Intel and AMD CPUs properly supported under Linux? Well, you can use them for sure but what about monitoring? lm-sensors monitor like 5% of what HWiNFO64 provides.

                So, sorry, Linux support on average just means a particular device basic features will work. That's it. That's a sad story really.

                Comment


                • #18
                  Originally posted by birdie View Post
                  I mean take for instance the CPU - a computer component without which nothing works. Are Intel and AMD CPUs properly supported under Linux? Well, you can use them for sure but what about monitoring? lm-sensors monitor like 5% of what HWiNFO64 provides.
                  You say 'CPU', the sensors of which are supported in the kernel directly, and then immediately conflate it with whatever pos motherboard you chose to put it in, whose additional sensors are often not supported.

                  HWiNFO64 is able to monitor so many different motherboards likely due the vendors directly providing the developer information on how to do it. I seriously doubt Martin, the guy that writes HWiNFO64, buys every board in existence to add support for it. And those same vendors refuse to provide any information to Linux developers.

                  Perhaps you really don't know what you are talking about in general.

                  Comment


                  • #19
                    More like hardware vendors provide the info for the Windows drivers, which HWiNFO64 leverages. But yeah, point is that information is scarce in Linux for this type of stuff and often has to be reverse engineered.
                    We don't even have robust software based fan control in Linux even. The is fancontrol, but that's old, I doubt it gets much of any updates, and has several bugs. Last I checked there were a couple of solutions being worked on, but honestly I haven't bothered to look since these days most uefi provide adequate fan control. At least AMD has provided enough documentation on their video cards to be able to control their fans.

                    Comment


                    • #20
                      Originally posted by calc View Post

                      You say 'CPU', the sensors of which are supported in the kernel directly, and then immediately conflate it with whatever pos motherboard you chose to put it in, whose additional sensors are often not supported.

                      HWiNFO64 is able to monitor so many different motherboards likely due the vendors directly providing the developer information on how to do it. I seriously doubt Martin, the guy that writes HWiNFO64, buys every board in existence to add support for it. And those same vendors refuse to provide any information to Linux developers.

                      Perhaps you really don't know what you are talking about in general.
                      You're so full of crap, it's cringeworthy. Here, take this:



                      And under Linux:

                      $ sensors
                      k10temp-pci-00c3
                      Adapter: PCI adapter
                      Tctl: +34.0°C
                      Tdie: +34.0°C
                      Tccd1: +33.8°C


                      Unfortunately with that I have to blacklist you because I understand what I'm talking about and you, with your fanatical attitude, is frothing at your mouth and know so little I have no desire to argue.

                      Comment

                      Working...
                      X