svn commit: r326383 - head/sys/x86/cpufreq
Jung-uk Kim
jkim at FreeBSD.org
Thu Nov 30 20:47:30 UTC 2017
On 11/30/2017 15:31, Conrad Meyer wrote:
> On Thu, Nov 30, 2017 at 12:08 PM, Jung-uk Kim <jkim at freebsd.org> wrote:
>> On 11/30/2017 14:32, Conrad Meyer wrote:
>>> Hi,
>>>
>>> I don't think this answers the second question about the conditional.
>>> It seems like PCPU_GET() for the initial CPU should be pulled out of
>>> the loop, which binds the thread to a different CPU every iteration.
>>
>> Ah, good catch. I'll fix it soon. Sorry.
>
> Thanks! :-)
>
>>> Also, as a side effect of disabling verification, you have fixed PR
>>> 221621, 219213, and probably 218262.
>>
>> Probably. However, I am just trying to fix my FX-8350 and A10-6800 and
>> I don't have Zen processors to verify the MSRs are actually working on
>> those CPUs.
>
> I have one, I can verify if needed (although the change looks good to
> me). On some Zen systems (including mine) it seems that the hardware
> can successfully set a P-state, but will fail to read it back. For me
> it is P1 but other users have reported P0. That's the root issue of
> all of those PRs. If reading back isn't required, maybe that's a
> solution to the issue.
Reading back was not really necessary (aka "fire-and-forget"). However,
we wanted to make sure all cores are in the same P-state before
returning to the caller. Back in the days, it wasn't a big deal because
we only had few cores to deal with and never expected to see complex
topologies such as the Threadripper, I guess. :-/
Jung-uk Kim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20171130/57208f23/attachment.sig>
More information about the svn-src-head
mailing list