svn commit: r326383 - head/sys/x86/cpufreq

[Jung-uk Kim]

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-all/attachments/20171130/57208f23/attachment.sig>