Support for AMD Family 17h Processors #16
Comments
|
Any Updates? |
|
Is this tool actively maintained? |
|
Not paid, not 24/7. This was always supposed to be a shadow repository. Unfortunately the main repository is gone. |
|
@groeck How much work is it to add sensor compatibility with new processors and motherboards? Ryzen is a pretty big deal, maybe you can crowdfund something if that would help? What can we do to help short of learning C? |
|
Money isn't an issue. Time is. |
|
thanks for explaining. |
|
Datasheet for Family 17h CPUs is not published by AMD. Adding temperature sensor support to the kernel driver will require additional technical information which is not currently available. Specifically, it is not known in which PCI device the temperature sensor resides, and if the registers are identical to earlier chips. |
|
https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf Does that datasheet contain anything useful? Thanks |
|
@sarnex: Unfortunately not. The required information is traditionally in the "BIOS and Kernel |
|
Please ignore my comment, I had a cached version opened which didn't have the latest comments, my bad! |
|
@sarnex @BeerSerc : Some additional information: I was told that the document needed is in fact the PPR. Problem is that there are two versions of this document, one that is public and one that is available only under NDA. The version available under NDA supposedly includes the required information. |
|
Great news, how do we sign the NDA and get the document? |
|
On Sun, May 7, 2017 at 7:51 PM, Sebastian Jug ***@***.***> wrote:
Great news, how do we sign the NDA and get the document?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGvNDF4kNBHvSEUIj5gykgOWAYD35p8eks5r3ljvgaJpZM4MY9zR>
.
I assume if someone does get ahold of it by signing the NDA, they won't be
able to release code based on information in it.
|
|
@sarnex: Yes, that is exactly the problem. |
|
Related:
At the time of writing, the latest Processor Programming Reference (PPR) for AMD Family 17h Models 00h-0Fh Processors (publication #54945) is revision 1.14, released 5/3/2017. And it seems the information buyers of this CPU require to reliably make use of the product is still missing. |
|
Anybody here contacted AMD to ask for such info? |
|
Is lack of information still an issue ? If so I can ask around internally, either to get it released publicly or under NDA with an exemption allowing use of the knowledge in open source driver development (we had to do that at least once for sensitive areas of the GPU). I am on the GPU side of AMD so will probably have to ask a few dumb questions re: exactly what we are looking for... what I'm a bit fuzzy on is "on die" temperature logic vs "on motherboard" logic which I believe are what are being discussed in the following thread: https://linuxconfig.org/monitor-amd-ryzen-temperatures-in-linux-with-latest-kernel-modules The reason for my confusion is that from what I remember all of the temperature measurement for our CPUs on Linux has been via motherboard logic (which I thought was hooked up to one or more sensors on the CPU) rather than on-die logic, but that is only what I have picked up from casual browsing while setting up my own systems at home. If the "motherboard sensors" are not reporting temperature information from the CPU chip then what temperatures are they reporting ? Last dumb question - what is the relationship between the the modules (eg it87) in Guenter's repo and the corresponding copies in upstream kernel drivers/hwmon ? Upstream seems to be a couple of months older at first glance - guessing Guenter's repo is the development tree and changes there eventually go upstream ? Thanks, |
|
@johnbridgman: Sure, if you can get an exception, that would help. Which information is needed: The PCI ID and location of the REPORTED_TEMP_CTRL_OFFSET register (or whatever it is called on family 17h; the name is from family 15h model 0x60 and 0x70) as well as the location of the index register to read it. The index register on family 15h is 0xb8, the offset is 0xd8200ca4. Also, it would help to know if there is a means to read the temperature offset from the CPU (20 degrees C for 1700X and 1800X), or if it is necessary to calculate the offset from the CPU type. Re drivers here - yes, those are development versions, and sometimes experimental. Normally I keep drivers in sync with upstream, but the it87 driver has deviated so much that I'll need several weeks to bring the drivers in sync. Unfortunately I don't have that time right now. |
|
echo $((0x |
|
@rozhuk-im: That helped, thanks. Patch for the k10temp driver submitted upstream. Too late for the v4.14 kernel, but it will be available in v4.15. |
|
@groeck Re: https://lkml.org/lkml/2017/9/4/503 , FYI At least some (1950X and I think 1920X) Threadripper CPU models have a 27°C offset too, if you want to try to correct a few more models automatically. |
|
On 09/04/2017 06:53 PM, Conrad Meyer wrote:
@groeck <https://github.com/groeck> Re: https://lkml.org/lkml/2017/9/4/503 , FYI At least some (1950X and I think 1920X) Threadripper CPU models have a 27°C offset too, if you want to try to correct a few more models automatically.
Fun part with the Threadripper CPU is that they have the same CPU model number.
The same microcode runs on both Ryzen and Threadripper. This means I will also
need a means to detect the affected CPU models, probably based on the model string.
Any idea what the CPU model string (as reported by /proc/cpuinfo) is ?
For 1700X, as example, it is "AMD Ryzen 7 1700X Eight-Core Processor".
I suspect it might be "AMD Ryzen Threadripper 1950X ...", but that is just
a guess and not good enough here.
Thanks,
Guenter
|
|
My system isn't running Linux, but FreeBSD reports "AMD Ryzen Threadripper 1950X 16-Core Processor" in the early boot messages. |
|
For info the Ryzen 5 1600 |
|
Ryzen 5 should not have temperature offsets. |
|
On Tue, Sep 05, 2017 at 01:53:02AM +0000, Conrad Meyer wrote:
@groeck Re: https://lkml.org/lkml/2017/9/4/503 , FYI At least some (1950X and I think 1920X) Threadripper CPU models have a 27°C offset too, if you want to try to correct a few more models automatically.
Yes, and I am told from AMD that older models have various offsets
as well. This is going to be fun in a negative sense :-(.
Guenter
|
|
Yeah, it's awful. I don't know what AMD is thinking. In FreeBSD we just punt on the issue and have the user configure an offset if they want to. |
|
@h3po: Since the offset is negative, you are effectively arguing that, on your system, the offset should not be applied, or that the offset should not be a 27° offset but something else. You'll need to provide actual evidence that this is the case. |
|
My Debian Sid (4.15) system has 1950X @ 3.9 + Asrock X399 Fatality Pro + Enermax 360 AIO. Running sensors (lm_sensors) at near idle gives me: However, I am uncertain which of these degrees are there relevant to me and what to watch out for. "k10temp-pci-00cb" and "k10temp-pci-00c3" appear normal given the thread, but "SMBUSMASTER 0" has risen to over 98°C when running some intensive programs, despite the Enermax watercooling. @groeck, any help or link to how to interpret these and other degrees reported is appreciated! |
|
@measly This ticket is not really the right forum for support requests. That said, given the offset between nct6779-isa-0290:SMBUSMASTER and k10temp-pci-00cb:temp1, the former could easily be the unadjusted raw value (and thus, subtracting 27° yields real temperature). Or it could be a bogus sensor — those are very common. (My system reports "AUXTIN: -26.5°C" which is of course wrong.) (If it is just the unadjusted raw sensor, 98° - 27° = 71°C, which is still quite high. It's possible your CPU cooling solution is insufficient or improperly installed.) |
|
62-27=35, which sounds about right. Sure, 98-27=71, which appears a bit high, but then I don't really know what to expect with AMD CPUs. Big question is if the temperature on SMBUSMASTER 0 changes quickly in conjunction with the CPU temperature or more slowly. If it is always in sync with k10temp, you have your answer. |
|
Just for comparison on the 71° figure: I also have a 1950X. Under sustained load on all cores, the highest I see is about 52-55°C. That's with a 3x120mm "AIO" cooler and no overclocking. |
|
@groeck and @cemeyer, the SMSBUSMASTER 0 does respond rather more quickly to load (stress-ng -c 32 -t 16) than either k10-pci-00cb and k10-pci-00c3, yet in conjunction. That is clearly visible using the KDE System Monitor; I attach a link to a screenshot uploaded at imgur, https://imgur.com/ERljFiK. Still, the offset shown in the numbers of that graph doesn't exactly add upp to 27°C, but rather 28.5°C. Maybe it is the KDE System Monitor which uses some smoothing function, I don't know. |
|
Looks like we are down to arguing about a 1.5°C temperature difference, a different granularity, and possibly a small reporting time delay between the two values. Not sure I understand what the problem is at this point. |
|
By the way I verified with an infrared thermometer that the correct temperature of the socket is most likely the lower one. I initially started wondering about which temperature is correct because the system starts crashing at a reported temperature of 65-70° when I pushed the overvoltage too far. Improved cooling solved the issue. |
|
Am I understanding correctly that kernel 4.15 should work? I have IT8733E (Aorus Xtreme X399 and 2950X) and I see negative temperature for temp2. I've tried kernel 4.19 as well without luck. When I run sensors-detect, I get an error: Found unknown chip with ID 0x8733 Thanks for any help! |
|
This exchange was about the CPU temperature sensor, not about support for ITE sensor chips. Also,
|
|
Can you recommend a driver? From multiple threads on the topic, I see that there used to be a github repo (I think yours) for it87, but it seems to have been removed. I'm really at a loss as to get CPU temperature for my system. |
|
There are various clones of the it87 driver available on github. I no longer follow the subject, I don't know if any are actively maintained, and I can not make a recommendation. You should be able use the k10temp driver from the latest upstream kernel, though. |
|
I can confirm k10temp worked for me on kernel 4.19 with Threadripper 1900. |
|
I've tried kernel 4.19 with the latest of this project as well as groeck/k10temp. sensors-detect recognizes the sensors with the k10temp driver, but sensors doesn't display any CPU temperatures. |
|
This is what I am getting Looking more closely now, it looks like nct6795 is being used, which also got added to the mainline kernel I believe. |
|
k10temp should instantiate for 2950X, and others have reported that it does. What sensors-detect does is all but irrelevant for the kernel driver. Is k10temp loaded ? |
|
I can confirm I'm getting the above issues on a Ryzen 7 2700X, Fedora 29, 4.19. |
|
Sorry, what issues ? The two most recent do show CPU temperatures, and I don't see anything wrong with it. If you see issues, please be specific what those issues are exactly. |
|
Oh my bad, I expected to see all 8 Cores, my bad, all is good then 👍 |
|
Can somebody comment on the core voltages being reported by lm-sensors? This is run on my Ryzen 1600 on an ASRock B450 Pro4. Vcore is being reported as +0.46 V; it rises to somewhere around +0.58 V under load. This can't be right for a processor that is listed at 1.2 V out of the box, though. |
|
The lower voltage is reasonable; I have seen even lower voltages on 1700X/2700X. It should spike to above 1.2V quickly if the CPU is under load. No idea why it would not do that. It may be, though, that the first voltage is not Vcore; after all, that is just a configuration parameter set in /etc/sensors3.conf. One possibility might be to watch other voltages under load and check if there is one with a better match. |
|
On 2018-12-27 04:44, Brian Schrameck wrote:
Can somebody comment on the core voltages being reported by lm-sensors? This is run on my Ryzen 1600 on an ASRock B450 Pro4. Vcore is being reported as +0.46 V; it rises to somewhere around +0.58 V under load. This can't be right for a processor that is listed at 1.2 V out of the box, though.
k10temp-pci-00c3
Adapter: PCI adapter
Tdie: +26.5°C (high = +70.0°C)
Tctl: +26.5°C
nct6779-isa-0290
Adapter: ISA adapter
Vcore: +0.46 V (min = +0.00 V, max = +1.74 V)
in1: +1.29 V (min = +0.00 V, max = +0.00 V) ALARM
AVCC: +3.44 V (min = +0.00 V, max = +0.00 V) ALARM
+3.3V: +3.44 V (min = +0.00 V, max = +0.00 V) ALARM
in4: +1.90 V (min = +0.00 V, max = +0.00 V) ALARM
in5: +0.90 V (min = +0.00 V, max = +0.00 V) ALARM
in6: +1.22 V (min = +0.00 V, max = +0.00 V) ALARM
3VSB: +3.46 V (min = +0.00 V, max = +0.00 V) ALARM
Vbat: +3.25 V (min = +0.00 V, max = +0.00 V) ALARM
in9: +0.00 V (min = +0.00 V, max = +0.00 V)
in10: +0.94 V (min = +0.00 V, max = +0.00 V) ALARM
in11: +1.07 V (min = +0.00 V, max = +0.00 V) ALARM
in12: +1.73 V (min = +0.00 V, max = +0.00 V) ALARM
in13: +0.25 V (min = +0.00 V, max = +0.00 V) ALARM
in14: +1.84 V (min = +0.00 V, max = +0.00 V) ALARM
fan1: 0 RPM (min = 0 RPM)
fan2: 862 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 729 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
SYSTIN: +23.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor
CPUTIN: -62.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +15.0°C sensor = thermistor
AUXTIN1: +29.0°C sensor = thermistor
AUXTIN2: +22.0°C sensor = thermistor
AUXTIN3: -27.0°C sensor = thermistor
PCH_CHIP_CPU_MAX_TEMP: +0.0°C
PCH_CHIP_TEMP: +0.0°C
PCH_CPU_TEMP: +0.0°C
PCH_MCH_TEMP: +0.0°C
intrusion0: ALARM
intrusion1: ALARM
beep_enable: disabled
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub [1], or mute the thread [2].
Hi Brian,
I have a Ryzen 1600 running on an ASRock AB350 Pro4 and I created the
following configuration:
https://github.com/lm-sensors/lm-sensors/blob/master/configs/ASRock/AB350_Pro4.conf
You might consider using it as a base for your own configuration. The
configuration for Vcore is as follows:
label in0 "Vcore"
compute in0 @*2, @/2
set in0_min 0.30
set in0_max 1.45
It looks like that configuration may be correct for you. I see +0.88V
at idle, +1.23V when all cores are under load and +1.38V when a single
core is under load.
Here is an example of the output I see (single core load):
nct6779-isa-0290
Adapter: ISA adapter
Vcore: +1.39 V (min = +0.30 V, max = +1.46 V)
+5.0V: +5.09 V (min = +4.51 V, max = +5.50 V)
AVCC: +3.42 V (min = +2.98 V, max = +3.63 V)
+3.3V: +3.42 V (min = +2.98 V, max = +3.63 V)
+12.0V: +12.36 V (min = +11.40 V, max = +12.62 V)
VDDCR_SOC: +0.90 V (min = +0.80 V, max = +1.20 V)
DRAMV: +1.22 V (min = +1.10 V, max = +1.50 V)
3VSB: +3.46 V (min = +2.98 V, max = +3.63 V)
VBAT: +3.26 V (min = +2.70 V, max = +3.63 V)
VDDP: +0.94 V (min = +0.90 V, max = +1.20 V)
+1.05V: +1.07 V (min = +0.94 V, max = +1.15 V)
+1.8V: +1.84 V (min = +1.62 V, max = +1.98 V)
Chassis Fan 3: 813 RPM (min = 0 RPM)
CPU Fan 1: 1341 RPM (min = 400 RPM)
Chassis Fan 1: 0 RPM (min = 0 RPM)
Chassis Fan 2: 926 RPM (min = 0 RPM)
Motherboard Temp: +25.0°C (high = +55.0°C, hyst = +50.0°C) sensor =
thermistor
CPU Temp: +36.0°C (high = +80.0°C, hyst = +75.0°C) sensor =
thermistor
beep_enable: disabled
k10temp-pci-00c3
Adapter: PCI adapter
CPU Core Temp: +45.5°C (high = +70.0°C)
Tctl: +45.5°C
Regards,
Leigh.
Links:
------
[1]
#16 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/AFOVmYCLU1aFlCgIM39OJIbCCWVRq7NSks5u9FAlgaJpZM4MY9zR
|
|
I'm running a 2990wx with ASRock Fatal1ty X399 Professional mobo. I get the following output when running sensors |
|
I always love it when people don't even bother to provide the kernel version. My wild guess is that commits 1b59788979ac and possibly 484a84f25ca7 are missing in that kernel, but who knows. |
|
Anyone here have luck with 3rd gen Ryzen CPUs? I have a Asrock b450 PRO4 and kernel 5.3.0 and am seeing weird values (like CPUTIN is -62.5 without load and then on a stress test, jumps to +58) See https://www.reddit.com/r/ASRock/comments/ddnkr4/temps_and_voltages_from_sensors_on_b450pro4_with/ |
|
On Thu, Oct 10, 2019 at 05:29:49AM -0700, Raghu wrote:
Anyone here have luck with 3rd gen Ryzen CPUs? I have a Asrock b450 PRO4 and kernel 5.3.0 and am seeing weird values (like CPUTIN is -62.5 without load and then on a stress test, jumps to +58)
See https://www.reddit.com/r/ASRock/comments/ddnkr4/temps_and_voltages_from_sensors_on_b450pro4_with/
```
nct6779-isa-0290
Adapter: ISA adapter
Vcore: +0.42 V (min = +0.00 V, max = +1.74 V)
in1: +1.27 V (min = +0.00 V, max = +0.00 V) ALARM
AVCC: +3.39 V (min = +2.98 V, max = +3.63 V)
+3.3V: +3.39 V (min = +2.98 V, max = +3.63 V)
in4: +1.83 V (min = +0.00 V, max = +0.00 V) ALARM
in5: +1.08 V (min = +0.00 V, max = +0.00 V) ALARM
in6: +1.21 V (min = +0.00 V, max = +0.00 V) ALARM
3VSB: +3.38 V (min = +2.98 V, max = +3.63 V)
Vbat: +3.20 V (min = +2.70 V, max = +3.63 V)
in9: +0.00 V (min = +0.00 V, max = +0.00 V)
in10: +0.94 V (min = +0.00 V, max = +0.00 V) ALARM
in11: +1.07 V (min = +0.00 V, max = +0.00 V) ALARM
in12: +1.69 V (min = +0.00 V, max = +0.00 V) ALARM
in13: +0.33 V (min = +0.00 V, max = +0.00 V) ALARM
in14: +1.81 V (min = +0.00 V, max = +0.00 V) ALARM
fan1: 0 RPM (min = 0 RPM)
fan2: 1620 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 1221 RPM (min = 0 RPM)
SYSTIN: +36.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor
CPUTIN: -62.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +15.0°C sensor = thermistor
AUXTIN1: +29.0°C sensor = thermistor
AUXTIN2: +22.0°C sensor = thermistor
AUXTIN3: -24.0°C sensor = thermistor
SMBUSMASTER 0: +49.0°C
This is the CPU temperature on this board. You would have to ask Asrock
why they connect the CPU to this input.
Other than that, I would suggest to use k10temp.
Guenter
|
|
I can confirm the doubling of in0 noted by @leighbb is needed also on the ASRock 570M Pro board to get correct (?) readings. I have not used any independent method to verify they are 100% accurate, but it sure seems to get them in right ballpark. Does anyone know how this multiplier was derived? Is it from an official data sheet? |
and others
Hi,
The new AMD Ryzen chips are Family 17h, and are unsupported by lm-sensors.
Please add support for them, and let me know if you need any information, as I have one.
Thanks,
Sarnex
The text was updated successfully, but these errors were encountered: