On Mon 2015-08-17 12:11:15, Ingo Molnar wrote:
>
> * Chen Yu <yu.c.c...@intel.com> wrote:
>
> > A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208)
Access denied :-(
> > that, after resuming from S3, CPU is working at a low speed.
> > After investigation, it is found that, BIOS has modified the value
> > of THERM_CONTROL register during S3, changes it from 0 to 0x10,
> > while the latter means CPU can only get 25% of the Duty Cycle,
> > and this caused the problem.
What HW is this on?
> > --- a/arch/x86/power/cpu.c
> > +++ b/arch/x86/power/cpu.c
> > @@ -97,6 +97,7 @@ static void __save_processor_state(struct saved_context
> > *ctxt)
> > mtrr_save_fixed_ranges(NULL);
> >
> > rdmsrl(MSR_EFER, ctxt->efer);
> > + rdmsrl(MSR_IA32_THERM_CONTROL, ctxt->clock_modulation);
>
> So what your changelog fails to mention:
>
> - You only add this code to the 64-bit kernel. Are 32-bit kernels not
> affected?
>
> - the MSR read is done unconditionally. Is MSR_IA32_THERM_CONTROL available
> architecturally and readable (and has sensible values) on all 64-bit
> capable
> x86 CPUs that run this code path?
- So BIOS expects to control MSR_IA32_THERM_CONTROL . Now you suspend
in hot enironment but resume in cool one. BIOS sets up
MSR_IA32_THERM_CONTROL the right way, but you override it.
As BIOS expects to control MSR_IA32_THERM_CONTROL and machine is
kept cool, BIOS will not write new value to it, and machine will
keep running slowly.
Doing this unconditionally is asking for trouble. Blacklist entry with
affected BIOS info might be acceptable, but...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
