Announcement

Collapse
No announcement yet.

Linux 5.12 To Allow Voltage/Temperature Reporting On Some ASRock Motherboards

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

  • #21
    Originally posted by stormcrow View Post

    Blame Intel. It's their spec. They intentionally made it vague and large parts of it up to hardware vendors with predictable (and predicted by many people including myself at the time of original publication) results. This is why nearly every OS implements Intel's ACPI tables except OpenBSD. OpenBSD's tables aren't always compatible with various devices, especially laptops, because of it. I have an HP laptop that won't run OpenBSD because booting it will cause a thermal shutdown. Linux is fine. Microsoft probably doesn't really have a lot to do with it. They use Intel's ACPI tables and the OEMs install their own tweaks.

    Not everything wrong in PC land is Microsoft's fault.
    You're missing the point, which is that there is *no* standard for this. I only mentioned ACPI because it seems like a decent place to put this. Ideally such a standard would have been proposed by the motherboard manufacturers since they are the ones to benefit/suffer from it. Sadly they don't care are more than happy to shovel their "value add" custom Windows programs to their users. Since the mobo vendors don't care the second option would be for Microsoft to mandate it for Windows certification. They have done it for various other things, which is mostly a good thing IMO since it has kept the PC ecosystem from turning into the wild west mess of ARM/etc.

    Also the ACPI failures you're citing are in fact Microsoft's fault. Most operating systems base their ACPI implementation on Intel's reference implementation, which generally tries to follow the standard. The one notable excetion is Windows which uses Microsoft's own ACPI implementation. Sadly Windows ACPI has in many cases been totally happy with various spec violating behaviour. And thanks to Microsoft's dominant position many machines have only been tested against the Windows ACPI implementation. So if you want to make your OS's ACPI implementation work with real world systems generally you just have to ask "What does Windows do?" and adjust your behaviour to match regardless of what the spec says.

    Comment


    • #22
      Originally posted by xeekei View Post
      No confirmation for X570 Taichi? Been looking at that one for a while.
      That works fine, Had one from release until I ditched it for a x570 master last month.(Other reasons )


      Originally posted by mazumoto View Post
      I have a Gigabyte X570 Aorus Master with an ITE IT8688E SuperIO and I'm really annoyed that it doesn't work and probably never will. Would've bought another board if I realized this before buying. I even wrote ITE a support ticket, but they said it's a specific design for a customer and they can't give out the datasheet - and Gigabyte told me they don't give the datasheet out to end users. Grmpf!

      Edit:
      there is even this discouraging bug report: https://github.com/lm-sensors/lm-sensors/issues/154

      I must be lucky have that board now

      Code:
      [[email protected] ~]$ sensors
      iwlwifi_1-virtual-0
      Adapter: Virtual device
      temp1:        +42.0°C 
      
      it8688-isa-0a40
      Adapter: ISA adapter
      in0:         948.00 mV (min =  +0.00 V, max =  +3.06 V)
      in1:           2.02 V  (min =  +0.00 V, max =  +3.06 V)
      in2:           2.04 V  (min =  +0.00 V, max =  +3.06 V)
      in3:           2.02 V  (min =  +0.00 V, max =  +3.06 V)
      in4:           1.20 V  (min =  +0.00 V, max =  +3.06 V)
      in5:         912.00 mV (min =  +0.00 V, max =  +3.06 V)
      in6:           1.37 V  (min =  +0.00 V, max =  +3.06 V)
      3VSB:          3.26 V  (min =  +0.00 V, max =  +6.12 V)
      Vbat:          3.05 V 
      fan1:         724 RPM  (min =    0 RPM)
      fan2:         425 RPM  (min =    0 RPM)
      fan3:         428 RPM  (min =    0 RPM)
      fan4:           0 RPM  (min =    0 RPM)
      fan5:        1110 RPM  (min =    0 RPM)
      temp1:        +37.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
      temp2:        -55.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
      temp3:        +42.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = AMD AMDSI
      temp4:        +48.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
      temp5:        +47.0°C  (low  =  +0.0°C, high = -125.0°C)  sensor = thermistor
      temp6:        +58.0°C  (low  = -16.0°C, high = +90.0°C)  sensor = thermistor
      intrusion0:  OK
      
      nvme-pci-0400
      Adapter: PCI adapter
      Composite:    +28.9°C  (low  = -273.1°C, high = +84.8°C)
                             (crit = +84.8°C)
      Sensor 1:     +28.9°C  (low  = -273.1°C, high = +65261.8°C)
      Sensor 2:     +37.9°C  (low  = -273.1°C, high = +65261.8°C)
      
      acpitz-acpi-0
      Adapter: ACPI interface
      temp1:        +16.8°C  (crit = +20.8°C)
      
      amdgpu-pci-0c00
      Adapter: PCI adapter
      vddgfx:        1.09 V 
      fan1:           0 RPM  (min =    0 RPM, max = 3850 RPM)
      edge:         +45.0°C  (crit = +100.0°C, hyst = -273.1°C)
                             (emerg = +105.0°C)
      junction:     +65.0°C  (crit = +110.0°C, hyst = -273.1°C)
                             (emerg = +115.0°C)
      mem:          +44.0°C  (crit = +94.0°C, hyst = -273.1°C)
                             (emerg = +99.0°C)
      power1:      146.00 W  (cap = 250.00 W)
      
      it8792-isa-0a60
      Adapter: ISA adapter
      in0:           1.80 V  (min =  +0.00 V, max =  +2.78 V)
      in1:         676.00 mV (min =  +0.00 V, max =  +2.78 V)
      in2:         992.00 mV (min =  +0.00 V, max =  +2.78 V)
      +3.3V:         3.38 V  (min =  +0.00 V, max =  +5.56 V)
      in4:           1.80 V  (min =  +0.00 V, max =  +2.78 V)
      in5:           1.19 V  (min =  +0.00 V, max =  +2.78 V)
      in6:           2.78 V  (min =  +0.00 V, max =  +2.78 V)  ALARM
      3VSB:          3.36 V  (min =  +0.00 V, max =  +5.56 V)
      Vbat:          3.21 V 
      fan1:           0 RPM  (min =    0 RPM)
      fan2:           0 RPM  (min =    0 RPM)
      fan3:           0 RPM  (min =    0 RPM)
      temp1:        +41.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
      temp2:        -55.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
      temp3:        +41.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
      intrusion0:  ALARM
      
      zenpower-pci-00c3
      Adapter: PCI adapter
      SVI2_Core:   944.00 mV
      SVI2_SoC:      1.18 V 
      Tdie:         +42.2°C  (high = +95.0°C)
      Tctl:         +42.2°C 
      Tccd1:        +39.2°C 
      Tccd2:        +38.0°C 
      SVI2_P_Core:  12.98 W 
      SVI2_P_SoC:   14.52 W 
      SVI2_C_Core:  13.84 A 
      SVI2_C_SoC:   12.36 A 
      
      nvme-pci-0100
      Adapter: PCI adapter
      Composite:    +45.9°C  (low  = -273.1°C, high = +72.8°C)
                             (crit = +75.8°C)
      Sensor 1:     +45.9°C  (low  = -273.1°C, high = +65261.8°C)
      Sensor 2:     +49.9°C  (low  = -273.1°C, high = +65261.8°C)
      
      [[email protected] ~]$
      I have rev 1.2 if that is what makes the difference.

      Kernel 5.9.16


      I just wish the motherboard manufactures would supply a sensors.conf file for their boards!

      Comment


      • #23
        Originally posted by timofonic View Post

        Then why nobody replaces him by a more competent maintaner? This is very ridicule and shameful!

        Linus, please blame him. Please stop being a corporate whore and move your fat ass.
        The problem is that nowadays, reverse engineer is just not enough. At least with these kinds of chips, the same model of chip can have revisions that differ wildly between versions, and can lead to system stability, or a broken system (or even better, a brick). You can't risk that nowadays, so the mantainer ask for patches derived from official specs provided by manufacturers themselves. Heck i've seen led chips controllers that can brick motherboards (Hello MSI!!!) by just reading a particular RAM address.

        Blame hardware designers and capitalism. Even 1 cent matters in thousands quantities.
        Last edited by stargeizer; 24 January 2021, 02:32 PM.

        Comment


        • #24
          Originally posted by mazumoto View Post
          I have a Gigabyte X570 Aorus Master with an ITE IT8688E SuperIO and I'm really annoyed that it doesn't work and probably never will. Would've bought another board if I realized this before buying. I even wrote ITE a support ticket, but they said it's a specific design for a customer and they can't give out the datasheet - and Gigabyte told me they don't give the datasheet out to end users. Grmpf!

          Edit:
          there is even this discouraging bug report: https://github.com/lm-sensors/lm-sensors/issues/154
          This is why I did a lot of research and nail biting before buying my current motherboard. ITE bad was known. And only some Nuvoton chips are supported. I was looking at MSI B550, but they only had 6687 and it wasn't supported then. And then 2 months later, someone added support for it.......

          Comment


          • #25
            Originally posted by skeevy420 View Post
            So, long story short, my PC died. Woke up and it acted like it wouldn't resume from a blanked monitor but I also wasn't able to Ctl+Alt+F# into another terminal either and had to hard reboot. According to the POST lights and testing with 3 processors, multiple SATA cables, a Linux and Windows boot drive, and 2 GPUs I thought it was either the motherboard or PSU so I ordered both. Hooked up a minimal setup and got the same POST lights on the new MB and PSU, only adding a 4th CPU to the testing since the motherboard came with a CPU in the slot. I guess I have bad ram? I just can't imagine that all six of my ram sticks died...
            Since my stimulus check came in I have to ask if an X570 is worth it over a B550 just for PCIE gen 4. I've got the gist of a Ryzen 5 4650 Pro build dialed in and I'm wondering if the extra $50 would be worth it because ECC is damn expensive and $500 out of my ~$700 budget is the CPU and ram, but a Pro APU with ECC memory in a custom build, yes please. I'm typing this from a keyboard plugged into my Android TV where the arrow keys work as a mouse cursor and enter acts as primary click. I don't know how to line break enter yet.
            This seemed like a decent place to ask since it's a motherboard article. Any idea WTF is up with my PC? The only thing I don't have extra to test is sticks of ram. Just curious at this point. I really wanted an extra year before upgrading...dammit...forced upgrades fscking suck. And, yes, I did the one stick of ram at a time thing. Spent the greater part of yesterday doing as many HW combinations as possible. And I don't have any actual Gen 4 hardware aside from the APU I plan on getting.
            Line Break Paragraphs, LOL
            Disconnect everything non-essential. dGPU, disks, other peripherals - you just need CPU + motherboard + RAM to boot to atleast UEFI screen. Of course, display and keyboard too.

            Comment


            • #26
              Originally posted by syrjala View Post

              You're missing the point, which is that there is *no* standard for this. I only mentioned ACPI because it seems like a decent place to put this. Ideally such a standard would have been proposed by the motherboard manufacturers since they are the ones to benefit/suffer from it. Sadly they don't care are more than happy to shovel their "value add" custom Windows programs to their users. Since the mobo vendors don't care the second option would be for Microsoft to mandate it for Windows certification. They have done it for various other things, which is mostly a good thing IMO since it has kept the PC ecosystem from turning into the wild west mess of ARM/etc.

              Also the ACPI failures you're citing are in fact Microsoft's fault. Most operating systems base their ACPI implementation on Intel's reference implementation, which generally tries to follow the standard. The one notable excetion is Windows which uses Microsoft's own ACPI implementation. Sadly Windows ACPI has in many cases been totally happy with various spec violating behaviour. And thanks to Microsoft's dominant position many machines have only been tested against the Windows ACPI implementation. So if you want to make your OS's ACPI implementation work with real world systems generally you just have to ask "What does Windows do?" and adjust your behaviour to match regardless of what the spec says.
              Well, ACPI has a lot of features for reporting things, it's just that Microsoft created WMI and pushed manufacturers to adopt that.

              For example, this one computer that I have doesn't report the fan as a cooling device through ACPI. Instead, you have to make WMI calls that ultimately call the custom RFAN ACPI function that will return the fan speed. There's a large chain of calls between the WMI function and the RFAN function, and I have to figure out exactly which magical parameters to pass in to the WMI function so that the RFAN function ultimately gets called. (the same WMI function does different things based on what parameters you pass to it).

              Same for ThinkPads, fan doesn't get reported as an ACPI cooling device. Someone (probably Redhat) did the hard work of figuring out how it worked, and created a ThinkPad ACPI driver that exposes the fan device and speed.

              So fuck WMI and fuck Microsoft. It's definitely their fault.
              ​​​​​

              Comment


              • #27
                Originally posted by sandy8925 View Post


                Disconnect everything non-essential. dGPU, disks, other peripherals - you just need CPU + motherboard + RAM to boot to atleast UEFI screen. Of course, display and keyboard too.
                First thing I did and I've done that with various combinations of 4 processors and 3 GPUs on 2 motherboards with 2 PSUs with and without boot disks. Older bios system with no iGPU so a GPU is necessary and I normally physically swap boot disks when dual booting. Tried all 6 sticks of ram one at a time on both motherboards. Only thing I don't have to try is ram that wasn't already in my PC. Aside from six sticks of ram dying at once, I'm stumped.

                Comment


                • #28
                  Originally posted by skeevy420 View Post

                  First thing I did and I've done that with various combinations of 4 processors and 3 GPUs on 2 motherboards with 2 PSUs with and without boot disks. Older bios system with no iGPU so a GPU is necessary and I normally physically swap boot disks when dual booting. Tried all 6 sticks of ram one at a time on both motherboards. Only thing I don't have to try is ram that wasn't already in my PC. Aside from six sticks of ram dying at once, I'm stumped.
                  Only thing I can think of is that your house's power supply is screwy, or your case (maybe power/reset button wires) are screwy.

                  Comment


                  • #29
                    skeevy,

                    I agree, having all six sticks of RAM kick the bucket simultaneously seems unlikely... although if that's the only constant between all your testing, it can't be ruled out. I've had similar fun in the past with thinking the issue was one thing while it was actually something else. Just getting the cheapest stick of DDRx you need would at least allow testing.

                    Right now, provided the B550 boards offer all the connectivity options you require, I'd say go B550.

                    You seem to have covered most of the bases for testing, so nothing really jumps out at me as a cause. Except the nagging possibility that it might be RAM...

                    Comment


                    • #30
                      Originally posted by stargeizer View Post
                      The problem is that nowadays, reverse engineer is just not enough. At least with these kinds of chips, the same model of chip can have revisions that differ wildly between versions, and can lead to system stability, or a broken system (or even better, a brick). You can't risk that nowadays, so the mantainer ask for patches derived from official specs provided by manufacturers themselves. Heck i've seen led chips controllers that can brick motherboards (Hello MSI!!!) by just reading a particular RAM address.
                      I was going to day something similar myself. It's not like a filesystem where it's entirely under the control of the OS. Even a different firmware version might cause issues - and if there is no spec to point to, and it bricks on Linux, who do you think will get the blame? (Heck, probably they catch it even if it is in spec, but it's something.)

                      If this was the Year of the Linux Desktop, it probably wouldn't be as big of a problem, because manufacturers would have more incentive to submit details or outright drivers, like AMD and Intel did. But this is one of the many reasons that achievement has proven so elusive.

                      Comment

                      Working...
                      X