https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733
--- Comment #2 from Conrad Meyer <c...@freebsd.org> --- 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 'sysctl dev.cpu.0.freq=foo' is invoked, for example. Second, if possible can you share the output of 'acpidump -dt'? It will be fairly large and you might have to compress it to attach it to bugzilla. It should not contain especially sensitive information — it's BIOS data and code provided to the operating system to understand system devices. I'll add: the method hwpstate(4) uses to set the current p-state is documented on Zen PPR as: *********************** "Writes to this field cause the core to change to the indicated __non-boosted__ P-state number…" (emphasis added) *********************** So, e.g., writing P0 (unlimited) still disables boost, I guess. Interestingly, the documentation on the boost enable/disable bit (HWCR::CpbDis) also mentions boosted / non-boosted P-states: "If core performance boost is disabled while a core is in a boosted P-state, the core automatically transitions to the highest performance non-boosted P-state." So... perhaps hwpstate(4) should explicitly check and enable CPB (boost) when "P0" is selected. Or we could synthesize an extra P-state, e.g., "3701" which when selected sets P0 and also boost. IMO, that's more effort than it's worth because manual P-state setting is silly on these CPUs. Here's a test you could do to confirm. Set dev.cpu.0.freq=3700, or whatever the maximum is. Then run (needs root): 'cpucontrol -m 0xc0010015 /dev/cpuctl0'. This reads the HWCR MSR from CPU0. The output will look something like: MSR 0xc0010015: 0x00000000 0x09000011 If the bit: 0x02000000 is set, it indicates that CPB is *disabled*. If that bit is set, you could try: "cpucontrol -m '0xc0010015&=~0x02000000' /dev/cpuctl0" and see if it restores boost-level performance. (I don't know if you would have to clear it on all CPUs, or if it is globally cleared by the cpu0 command.) -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
