Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, January 03, 2014 08:04:36 PM Gleb Natapov wrote:
> On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
> > Hi All,
> > 
> > Sorry for being late to the party but I just got back from vacation.
> > 
> > There is something deeply wrong here.  We should have never gotten to
> > intel_pstate_init_cpu().  The VM had to have returned value from the read
> > of the max pstate at driver init time and 0 when the CPU was being brought up.
> > 
> > intel_pstate_msrs_not_valid() was added to solve this issue early on
> > if I remember correctly it was Josh that reported it then.  Is there
> > a definative way to detect whether we are running in a VM?
> > 
> Checking for VM is a wrong thing to do here. KVM should behave like it
> does not support p-state.
> 
> > Can some one tell me how the nested environment differs in regards to
> > reading MSRs?
> > 
> It shouldn't differ, but there may be bug somewhere in nested emulation.
> We shouldn't try and hind the bug by doing more checks in Linux but
> rather fixing KVM bug that causes Linux to behave incorrectly.

Well, fixing the KVM bug is surely welcome.

That said, adding checks to ensure that your assumptions are valid is rarely
wrong, especially if they are done once per kernel boot.  And the kernel only
should panic if it cannot continue to run, which isn't the case here.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux