On 11/30/2017 15:31, Conrad Meyer wrote: > On Thu, Nov 30, 2017 at 12:08 PM, Jung-uk Kim <j...@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
signature.asc
Description: OpenPGP digital signature
