Announcement

Collapse
No announcement yet.

AMD Zen Temperature Monitoring Queued For Linux 4.15

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

  • AMD Zen Temperature Monitoring Queued For Linux 4.15

    Phoronix: AMD Zen Temperature Monitoring Queued For Linux 4.15

    We've been expecting it to happen for weeks while indeed the hwmon pull request was indeed sent in today exposing AMD Ryzen / Threadripper / EPYC temperature reporting on Linux...

    http://www.phoronix.com/scan.php?pag...ure-Hwmon-4.15

  • #2
    Add support for handling temperature offset values for various AMD CPUs, similar to the code used in the coretemp driver for Intel CPUs. This is primarily for Ryzen CPUs (which has documented temperature offsets), but the code is kept generic to simplify adding additional CPUs.
    -- https://git.kernel.org/pub/scm/linux...c275d5c18d629d

    So I guess this means Ryzen-based CPU's show an actual temperature that makes sense to humans instead of an arbitrary temp/fan control value? If so, that's nice.

    Comment


    • #3
      Let's hope that this will make it a quick affair to add support for Raven Ridge and the inevitable Zen+ or Zen2.

      Comment


      • #4
        Is there a BKDG for Zen yet?

        Comment


        • #5
          That will be nice to have!
          I was a bit disappointed that this and the XFS update and the DAL/DC code were all queued up for 4.15, 4.14 being the next LTS and all.
          I imagine it would have made life a lot easier for distro developers/maintainers to have an LTS kernel with Zen and Vega support, bells and whistles included.

          I will be curious what temperatures this will report, my motherboard's values seem a bit funky to me, running an overclocked R5 1600X with a Dark Rock TF.

          Comment


          • #6
            Originally posted by OneBitUser View Post
            That will be nice to have!
            I was a bit disappointed that this and the XFS update and the DAL/DC code were all queued up for 4.15, 4.14 being the next LTS and all.
            I imagine it would have made life a lot easier for distro developers/maintainers to have an LTS kernel with Zen and Vega support, bells and whistles included.

            I will be curious what temperatures this will report, my motherboard's values seem a bit funky to me, running an overclocked R5 1600X with a Dark Rock TF.
            it seems no-one wants to use the 4.14 as actual LTS while canonical being the first to say that 4.15 is the next lts for 18.04 if I'm not mistaken :-)

            Comment


            • #7
              It makes me a bit sad that this is news after more than half a year after Ryzen was released.

              Comment


              • #8
                Originally posted by rrohbeck View Post
                Is there a BKDG for Zen yet?
                Only if you sign NDA...
                I really don't know what is so secret in this documentation that it can't be published for all as it was for all other AMD CPUs.

                Comment


                • #9
                  Originally posted by DanL View Post

                  -- https://git.kernel.org/pub/scm/linux...c275d5c18d629d

                  So I guess this means Ryzen-based CPU's show an actual temperature that makes sense to humans instead of an arbitrary temp/fan control value? If so, that's nice.
                  My motherboard BIOS does this offset for me. I wonder if the offset will now be applied twice due to this patch?

                  Comment


                  • #10
                    Originally posted by oleyska View Post

                    it seems no-one wants to use the 4.14 as actual LTS while canonical being the first to say that 4.15 is the next lts for 18.04 if I'm not mistaken :-)
                    Exactly...
                    It would have been nice to have these AMD contributions in the 4.14 kernel already. It could have gone a long way in deduplication of efforts.
                    Distribution maintainers now have two options:
                    1. wait out 4.15 so they can offer better support for modern hardware, if they do this...
                      • they will either have to update the kernel version sometime, which can be a source of instability. Dealing with which will waste resources.
                      • or they will have to backport at least the security patches for their version of the 4.15 kernel. This backporting will inevitably waste resources.
                    2. use 4.14 LTS for the sake of stability. In this case they will have to backport hardware enablement patches from day 0, since the kernel does not support all notable hardware pieces available at it's launch. This backporting will also inevitably waste resources.

                    I know it's not the open source way, but some coordination would have been nice among different stakeholders and projects. Yes, even altering the kernel releases... say make 4.15 the LTS release.

                    Comment

                    Working...
                    X