Le 12/02/2019 à 00:17, Srinivas Pandruvada a écrit :
> [...]
> To know if the intel_pstate in control, you can look at:
> #cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver
>
> So if it is not loaded and Intel intend to support a processor model
> with intel_pstate, then OEM's
On Mon, 2019-02-11 at 22:34 +0100, Erwan Velu wrote:
> I understand your concern but I'd like to defend my use case ;)
>
> I was in a case where I didn't noticed that intel_pstate did engaged
> after a kernel upgrade while it didn't before.
> But there strictly no information message why the
I understand your concern but I'd like to defend my use case ;)
I was in a case where I didn't noticed that intel_pstate did engaged
after a kernel upgrade while it didn't before.
But there strictly no information message why the driver took the
decision not to load (aka considering there is
On Mon, 2019-02-11 at 10:31 +0100, Erwan Velu wrote:
> The init code path have several execeptions where the module can
> decide not to load.
> As CONFIG_X86_INTEL_PSTATE is generally set to Y, the return code is
> not reachable.
> The initialisation code is neither verbose of the reason why it
The init code path have several execeptions where the module can decide not to
load.
As CONFIG_X86_INTEL_PSTATE is generally set to Y, the return code is not
reachable.
The initialisation code is neither verbose of the reason why it did choose to
prematurely exit.
This situation leads to
5 matches
Mail list logo
