Announcement

Collapse
No announcement yet.

Linux 6.3 Supports Sensor Monitoring For Many ASUS B650/B660/X670 Motherboards

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

  • Linux 6.3 Supports Sensor Monitoring For Many ASUS B650/B660/X670 Motherboards

    Phoronix: Linux 6.3 Supports Sensor Monitoring For Many ASUS B650/B660/X670 Motherboards

    The hardware monitoring support among consumer desktop motherboards continues to improve with Linux 6.3 adding sensor support for many ASUS B650/B660/X670 AMD Ryzen 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
    Glad to see this feature, I use ASUS ROG STRIX X670E-A GAMING WIFI.
    The only problem I have with it is missing USB hub LPM, so all my USB devices are being reconnected after each wake-up.

    Comment


    • #3
      Sensors? We don't need no stinkin' sensors!

      I want to smell the burning circuitry and see the darn smoke! Then I'll know if something's wrong

      Comment


      • #4

        12345

        Comment


        • #5
          It's been over 14 years since the NCT6775F released, and the hwmon documentation about CPUTIN reporting the wrong temperatures still holds true, and what's not listed is that most of the temperature inputs on Nuvoton chips are wrong. I don't know if it's an implementation problem for years with ASUS or Nuvoton just never fixes the chips, but you can't rely on it, which poses a few problems as the motherboard does rely on it.

          On my X570 Crosshair 8 Dark Hero with an NCT6798D the available temperature inputs are SYSTIN, CPUTIN, AUXTIN{0..3}, PECI Agent 0 Calibration, PCH_CHIP_CPU_MAX_TEMP, PCH_CHIP_TEMP, PCH_CPU_TEMP, TSI{0..1}_TEMP.

          SYSTIN does work, however I have no idea where the diode is. It's definitely not near anything that produces heat like the CPU/GPU/VRM/chipset, it's just reporting case air temperature.

          CPUTIN as reported in the hwmon documentation has barely any bearing on CPU temperature, it only ever moves by 10C at most when under load, and doesn't reach the true temperature at idle, just moves around 35-45C.

          AUXTIN might be the temperature probe and water in/out temperature probes, but I don't have any so I don't know if this is the case or if their functionality is accurate. I have seen posts from people monitoring their temperatures on Windows that their measurements for these seem to glitch out sometimes and freeze.

          PCH temps do nothing and don't report chipset temperature, most likely is for Intel chipsets.

          PECI Agent 0 Calibration is supposed to be the one that is accurate, as crucially it's the default input to control the fans, however it's also wrong! Comparing to Tctl, PECI Agent 0 Calibration floats 5C higher at idle, and frustratingly seems to be over 10C off under load. It would report 60C while Tctl is reporting 72C. This is frustrating because if someone were to set the fan curves in the UEFI to max at 80C (about where the boost frequencies begin to drop as approaching Tjmax) to stop the processor from thermal throttling then it wouldn't work. The processor would be slamming into Tjmax at 90C and thermal throttling and dropping all frequencies while PECI Agent 0 Calibration would be below 80C, with the fans not ramping up. Even more annoying is that it in the first few seconds under load it does spike close to Tctl, but then begins to drop with each second until it hits its steady state, causing the fans to ramp down while the processor is getting hotter.
          I looked into changing the offset in hwmon, however you can't. Reading the specification for the NCT6796D shows it has registers to do so for both PECI Agent 0 and PECI Agent 0 Calibration, however I don't know if that applies to the NCT6798D, or if it works in the first place.

          TSI0_TEMP is accurate as it's a direct readout from AMD's SB-TSI and is actually reading Tctl. Except it can't be used as the source temperature input for a fan, and it's not a hwmon limitation as the specification for the NCT6796D corroborates this.

          TSI1_TEMP is the chipset temperature, it should be accurate.

          I've compared these temperatures to asus-ec-sensors, since it sources some of the temperatures from the NCT6798D, they map as so: Chipset = TSI1_TEMP, CPU = PECI Agent 0 Calibration, and Motherboard = SYSTIN. VRM temperature isn't monitored by the NCT6798D and instead by the embedded controller. I also compared them to zenpower3 and it agrees on TSI0_TEMP, although if you want true core temperatures then you should run ryzen_smu and ryzen_monitor.

          So if someone is using ASUS AMD motherboards are supported by nct6775 or asus-ec-sensors then you should check what it reports for CPU temperature and compare to k10temp/zenpower/zenpower3/ryzen_smu and adjust the fan curves if things aren't right.

          Comment


          • #6
            I just stopped caring altogether for all this. Nothing gets proper support and thew few boards that do either need special hacks/settings (that may kill your hardware) or just report garbage and unreliable data.

            Comment


            • #7
              When it comes to hardware sensors in Linux...I love to hear all the whine with the cheese.

              I wonder if users really understand that hardware sensor chips can be hooked up in ways that do not respect how the LM Sensors package thinks they hook up?

              In other words, LM Sensors is simply placing labels on hardware sensor chip inputs, but the label may or may not actually connect to the actual physical sensor that matches the label.

              Most Linux users are probably now wondering WTF!?! Yup.

              For example, hardware sensor chips might have multiple voltage inputs. LM Sensors might think that "in3" is supposed to connect to "+12V", but LM Sensors reports "1.6V" or something. Perhaps the motherboard designer decided to wire "in3" to VCC, which is typically "+3.3V" on many boards. Or maybe it's connected to a PCH voltage which could be almost anything from "+1.0V" to "+1.8V" or whatever. Or maybe "in3" is left open; it "floats", so it reports all sorts of strange readings.

              Temperature and fan inputs to hardware sensor chips are similar. A temperature input can be connected to ANY compatible temperature reading device...or left disconnected; see the "sensors.conf" manpage for some info on thermal sensor types. Fan inputs can be connected to fan RPM sensor lead or left disconnected. I have had motherboards where LM Sensors reported temperature readings for CPU and mobo that were the reverse of the BIOS readings, so I trusted the BIOS readings and modified the LM Sensors chip config to match. Further experimentation justified my modification.

              Also consider that the voltage input connections to hardware sensor chips have an input voltage limit, typically +2V", so the input is front-ended by a voltage divider resistor array. Now a connection to a "+12V" line can be fed through a voltage divider resistor array and then to a hardware sensor chip input lead that is limited to "+2V" (or whatever) input voltage. The concept of voltage divider arrays is discussed in the LM Sensors 'sensors.conf' manpages. Fan and temperature inputs are not limited in my experience.

              So the actual LM Sensors configuration that works for your motherboard and it's hardware sensor chip is as much guesswork as it is based upon the chip's own documentation. The chip configs that ship with LM sensors are generic, plain & simple; they are not "this a the rule to be followed" configs. That means a typical Linux user who loads the LM Sensors package on their computer and then expects "magic" to happen when they issue the "sensors" command at the command line (or use whatever GUI frontend to display the same data) is generally disappointed and retorts in some Linux mailing list or Linux forum "But IT WORKS RIGHT IN WINDOZES!!! WAAAHH!!!!".

              So what is a typical Linux user to do?

              Learn About Your Hardware

              Take some time to study the BIOS since it does know (in my experience) how to correctly read the motherboard hardware sensors. Take some time to learn about voltage divider math. Learn to use a voltmeter safely. Learn how to modify LM Sensor chip configurations. Expect to do some guesswork and don't expect perfection.

              And if you are the type that expects perfection in Linux, go back to Windoze...or better yet just stick with Apple products.

              Comment


              • #8
                So once ready, sensors outputs will be available in "sensors" command? Right now I only have CPU and GPU temps there (Ryzen and Radeon).

                Comment


                • #9
                  Originally posted by piorunz View Post
                  So once ready, sensors outputs will be available in "sensors" command? Right now I only have CPU and GPU temps there (Ryzen and Radeon).
                  Yes, that's right.

                  Comment


                  • #10
                    Originally posted by piorunz View Post
                    So once ready, sensors outputs will be available in "sensors" command? Right now I only have CPU and GPU temps there (Ryzen and Radeon).
                    Some boards could require addition patch apply for support newer version of chip https://patchwork.kernel.org/[email protected]/

                    In such case dmesg should contain some message about wrong chipid.

                    what board do you have?

                    Comment

                    Working...
                    X