Announcement

Collapse
No announcement yet.

36+ More ASUS Motherboards Will Enjoy Sensor Monitoring Support With Linux 6.4

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

  • 36+ More ASUS Motherboards Will Enjoy Sensor Monitoring Support With Linux 6.4

    Phoronix: 36+ More ASUS Motherboards Will Enjoy Sensor Monitoring Support With Linux 6.4

    In addition to the ASUS Z590 motherboards seeing sensor monitoring support with patches queued for Linux 6.4 that were talked about earlier this month on Phoronix, the latest nct6775 driver activity now queued in the hardware monitoring subsystem's hwmon-next branch is allowing support for another three dozen ASUS motherboards...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Still no A320I-K :'(

    Comment


    • #3
      Well the only ones missing for the Z790 family are:

      ROG MAXIMUS Z790 APEX
      ROG STRIX Z790-I GAMING WIFI
      ROG STRIX Z790-E GAMING WIFI
      ROG MAXIMUS Z790 HERO (The one I have)
      ROG STRIX Z790-F GAMING WIFI
      ROG STRIX Z790-A GAMING WIFI D4​

      After that, ASUS would be up to date with everything.
      Linux Gaming - https://youtube.com/@xtremelinux

      Comment


      • #4
        Originally posted by Luis Alvarado View Post
        Well the only ones missing for the Z790 family are:

        ROG MAXIMUS Z790 APEX
        ROG STRIX Z790-I GAMING WIFI
        ROG STRIX Z790-E GAMING WIFI
        ROG MAXIMUS Z790 HERO (The one I have)
        ROG STRIX Z790-F GAMING WIFI
        ROG STRIX Z790-A GAMING WIFI D4​

        After that, ASUS would be up to date with everything.
        I own the ROG STRIX Z690-E GAMING WIFI, isnt that missing too?

        Comment


        • #5
          So Asus MBs are getting their Sensor monitoring support because their Super I/O and ACPI combination were broken in the first place? And users with normal motherboards are getting nothing even thought they have the same super i/o controller?

          add:
          Oh, I get it, I need to manually
          Code:
          modprobe nct6775
          but why doesn't it probe automatically by kernel?
          Last edited by RejectModernity; 21 March 2023, 01:28 AM.

          Comment


          • #6
            Originally posted by EphemeralEft View Post
            Still no A320I-K :'(
            We are probably stuck forever, relying on the out-of-tree driver. https://wiki.archlinux.org/title/lm_...R_motherboards

            Comment


            • #7
              Originally posted by RejectModernity View Post
              So Asus MBs are getting their Sensor monitoring support because their Super I/O and ACPI combination were broken in the first place? And users with normal motherboards are getting nothing even thought they have the same super i/o controller?

              add:
              Oh, I get it, I need to manually
              Code:
              modprobe nct6775
              but why doesn't it probe automatically by kernel?
              If you want automatic probing...go back to using Windows where the OS will probe you whether you like it or not and send the results directly to Microsoft for inspection.

              Seriously, Linux is very slowly getting to the level of Windows where everything is done for the user. Linux started as a hobbyist OS and users were not only expected but encouraged to experiment with it; revise it; extend it; and generally make it more & more useful.

              As for the early days of LM Sensors development, the maintainers were solely focused on "Does it have a public datasheet?" before they would ever consider writing any code surrounding any monitoring chip. And even if a public datasheet was available it sometimes considered "insufficient" for the LM Sensors developers, all 1 or 2 of them IIRC. There was no sense of experimentation or exploration among those developers, mainly because there were no resources, no time, and no desire to do so. A number of chips did get added over the years, perhaps only because 1 of the developers encountered them in their paying "day job" work, and so they might have had access to some data not otherwise available.

              I think it took a radical approach like this one to get this type of support for ASUS boards because users were completely frustrated with lack of development in the LM Sensors world. The fact that the LM Sensors team even considered it or import it to their tree is earth-shattering. Perhaps the LM Sensors team has a "plausible deniability by distance" case - they did not write the code so if it blows up don't blame them...and that preserves their status quo "no public datasheet, no support, wake me up when the coffee is ready" position.

              As for vendors supporting or not supporting Linux...I think the reasons are multiple...and that's a whole 'nother lengthy post...but here's a short list (a vendor's view):
              1. Cost to support with no revenue return, so why bother?
              2. Multiple Linux distributions to support, but which ones? Windows is just...Windows and a known API & development kit. Mac is like Windows...a known API & probably a development kit also. Linux has such a long list of OS to consider, each sometimes using different Linux kernel versions.
              3. The multitude of Linux packaging methods can be confusing and annoying. Which one do we use?
              4. Linux ABI & API seem like moving targets from release to release despite what Linus claims. If that's a false statement, then why are package maintainers needed & revising packages a necessary evil as dependencies change (and that can change API entrypoints into those dependencies)?
              5. Linux kernel code contribution model is confusing, from licensing (to annoy our attorneys) to code contribution (to annoy our developers) to just getting the code accepted (to annoy everybody).
              6. The issue of ongoing code maintenance in the Linux kernel is confusing. It seems like no on-going contributions to a piece of code can leave a big RED 'X' which alerts the Linux kernel code maintainers to consider DROPPING YOUR CODE LIKE A STONE IN A POND. As a vendor I might not see any reason to update anything, unless it's a bugfix, but I risk getting code dropped because it's 'crusty' or hasn't kept up with the latest ABI, API, and Linux kernel code dependency changes (see 2 & 4).
              7. Time & resources. Big Corps like AMD & Intel & NVIDIA (sort of) have that time & resources (money), but most companies are smaller than them.
              8. Market penetration of Linux. Windows has lots of Enterprise support and Windows Enterprise customers have certain expectations that have to be met. Mac has a loyal and vocal customer base and likely expectations that have to be met. Linux has what compared to those two?
              I think (2), (4), and (6) are major issues for vendors. Items (1) and (7) help the bean-counters justify not supporting a Linux team at that vendor. Windows & Mac have made the effort to 'court' developers, make life easier for them working with their OS: developer relations teams, development kits, stable ABI & API, driver certification programs, and so on. Linux has made what efforts in those areas? Against, think about it from a vendor's viewpoint.

              Sure, Linux gives you lots of choice, but that plethora of choice confuses vendors who like one clear way of doing stuff for an OS and with an OS vendor. So Michael's comment at the end of his article was, I think, a touch self-serving but it also raises a VERY serious question that the entire Linux world has to consider if it is ever going to progress beyond it's current standing with vendors.

              Comment


              • #8
                Coreboot Support for them would be nice. Where are the OpenSource UEFI Implementations with Overclocking and Undervolting features for all boards?

                Comment


                • #9
                  Originally posted by EphemeralEft View Post
                  Still no A320I-K :'(
                  Do you see sensors output when you boot upstream kernel without any custom modules and add 'acpi_enforce_resources=lax' to boot parameters?

                  If there are output of sensors with lax, board could be supported by porting wmi proxy code from nct6775 to it87 module.

                  At least we can try ;-)

                  In any case if some board doesn't work, add dmidecode + acpi dump to https://bugzilla.kernel.org/show_bug.cgi?id=204807 or https://github.com/asus-wmi-boards-s...sus-board-dsdt will provide some hope to support of board, no guarantees, but may be.


                  ​​You are always welcome to create issues about your board;-)

                  Next patch series will contain several additional boards detected by dumps from https://github.com/linuxhw/ACPI/tree...Tek%20Computer, so if someone has already sent dump for board to linuxhw database, it could be in next series.

                  ​​​​​
                  Last edited by denisdevelops; 21 March 2023, 04:15 PM.

                  Comment

                  Working...
                  X