https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
eborisch+free...@gmail.com changed:
What|Removed |Added
CC||eborisch+free...@gmail.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
Conrad Meyer changed:
What|Removed |Added
Version|12.0-STABLE |CURRENT
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #24 from commit-h...@freebsd.org ---
A commit references this bug:
Author: cem
Date: Fri Jan 31 17:40:42 UTC 2020
New revision: 357336
URL: https://svnweb.freebsd.org/changeset/base/357336
Log:
hwpstate(4): Ignore CurPstateLi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #22 from sig...@gmail.com ---
(In reply to Conrad Meyer from comment #21)
Hard to imagine a description that makes sense to random users, this is just so
damn technical. But if there's a pointer to it in some manpage people are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #21 from Conrad Meyer ---
(In reply to sigsys from comment #20)
c0010061 doesn't follow c00l0062 on my Zen1 + ASRock X370 system, for example.
:-) Maybe it's a Zen+ thing, maybe it's a BIOS thing, who knows.
In any case I agre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #20 from sig...@gmail.com ---
Maybe it could do some double checking only once to "learn" about those
registers' behavior (and maybe have a sysctl to reset that to make it check
again)? But if Linux ignores it entirely then you'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #19 from Conrad Meyer ---
(In reply to Conrad Meyer from comment #18)
> I am curious if Linux does any better. Maybe they just ignore c0010061.
Yeah they just ignore c0010061 entirely. Probably we can too.
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #18 from Conrad Meyer ---
(In reply to sigsys from comment #15)
> It would already be pretty good if the kernel could detect the situation by
> double checking on one of those registers and log a warning. Assuming it
> wouldn't
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #17 from commit-h...@freebsd.org ---
A commit references this bug:
Author: cem
Date: Mon Jan 27 06:04:33 UTC 2020
New revision: 357165
URL: https://svnweb.freebsd.org/changeset/base/357165
Log:
hwpstate(4): Log a debug line w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #16 from sig...@gmail.com ---
Created attachment 211097
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=211097&action=edit
P3.50 acpidump -dt
Upgraded to 3.50 and I'm seeing the *exact* same behavior doing the same tes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #15 from sig...@gmail.com ---
It would already be pretty good if the kernel could detect the situation by
double checking on one of those registers and log a warning. Assuming it
wouldn't risk causing even more problems on some
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #14 from Conrad Meyer ---
Sorry, not 3.90, only go to 3.50 maybe?
> ASRock do NOT recommend updating this BIOS if Pinnacle, Raven, Summit or
> Bristol Ridge CPU is being used on your system.
I don't have a clue why they'd rel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #13 from Conrad Meyer ---
Note that there are several newer BIOSes available for that board:
https://www.asrock.com/mb/AMD/B450%20Pro4/#BIOS
The only remark that really jumps out is for 3.31, "Change AMD PBO rule with
Pinnacle
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #12 from Conrad Meyer ---
(It's also surprising that writing c0010062 *works* and overwrites c0010061 —
the docs for c0010062 say: "P-state limits are applied to any P-state requests
made through this register. Reads from this f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #11 from Conrad Meyer ---
Very interesting, thanks! It's the low bits of 0xc0010061 following 0xc0010062
up that is surprising / causing hwpstate(4) to ignore the user's supplied
configuration (side note: we should really produ
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #10 from sig...@gmail.com ---
(In reply to Conrad Meyer from comment #9)
It's showing some interesting behavior I think. The last 3 bits of 0xc0010061
and 0xc0010062 go up but don't go down. And they go up together.
At boot:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #9 from Conrad Meyer ---
Another test to try (maybe after entering a non-P0 p-state, not sure if that
matters) if you'd like:
$ cpucontrol -m '0xc0010061' /dev/cpuctl0
This is the PStateCurLim register, and the low 3 bits are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #8 from sig...@gmail.com ---
No luck. I retried with debug.acpi.disabled="thermal" in my loader.conf and
redid the tests and didn't notice the behavior changing. Still gets stuck on
the lowest frequency until a reboot.
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
scha...@gmail.com changed:
What|Removed |Added
CC||scha...@gmail.com
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #6 from Conrad Meyer ---
Over on bug 234455 comment #9, schaiba@gmail reports tuning
debug.acpi.disabled="thermal" to fix Ryzen getting stuck in low P-states. I
think that suggests buggy BIOS, since the ACPI thermal implementat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #5 from Conrad Meyer ---
(In reply to sigsys from comment #4)
Thanks for the testing, that’s really helpful!
I totally agree this is a bug that needs fixing; disabling powerd / avoiding
manually reducing the clock is just a wor
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #4 from sig...@gmail.com ---
Created attachment 210970
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210970&action=edit
acpidump -dt
(In reply to Conrad Meyer from comment #3)
Alright I tested a bunch of things based
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #3 from Conrad Meyer ---
I tried the following test:
$ cpuset -l 0 time sha1 <~200MBfile>
(burn one result for caching, then repeat 3 trials)
I got average 0.24 real, 0.22 user. You might pick a slightly larger file for
bigger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #2 from Conrad Meyer ---
Can both of you try:
Adding 'debug.hwpstate_verbose="1"' in /boot/loader.conf and checking dmesg for
boot-time messages about hwpstate? This can also be sysctl'd at runtime to see
what gets logged when
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #1 from sig...@gmail.com ---
Same thing happens for me on 12-STABLE on a Ryzen 2700. The CPU frequency
isn't going up once it has been lowered (even though it looks like it does
according to that sysctl, the CPU actually remains
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
Bug ID: 234733
Summary: Setting CPU frequency with sysctl dev.cpu.0.fr slows a
Ryzen 2700X down
Product: Base System
Version: 12.0-STABLE
Hardware: amd64
26 matches
Mail list logo
