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

[Kashyap Chamarthy]

On 12/29/2013 04:04 PM, Rafael J. Wysocki wrote:
> On Sunday, December 29, 2013 01:12:18 PM Kashyap Chamarthy wrote:
>> [. . .]
>>
>>>> Here's host dmesg: https://bugzilla.kernel.org/attachment.cgi?id=119751
>>>>
>>>>>> Can you ftrace the failure?
>>>>
>>>> Can try, need some time (rest of the day I'll be away travelling,
>>>> will try to do it over the weekend, and update the Kernel
>>>> bugzilla with observations).
>>>>
>>>>>>
>>>>> Ugh, it looks like guest dmesg but there are KVM messages there too ("[
>>>>> 281.443662] kvm [2452]: vcpu0 unhandled rdmsr: 0xe8" is unhandled access
>>>>> to MSR_IA32_APERF I was talking about above), so I guess this is nested
>>>>> guest invocation? 
>>>>
>>>> Yeah -- sorry, I forgot to note it's in a nested environment :(
>>>>
>>>>> Does it happen in non nested guest?
>>>>
>>>> I need to that.
>>>>
>>>> Note to self: Also try with a newer Kernel on the host.
>>>
>>> Please try the patch I posted earlier today when you're at it:
>>>
>>> https://patchwork.kernel.org/patch/3411991/
>>
>> I applied the patch & tried to build the Kernel, it failed with:
>>
>> =======
>> .
>> .
>> .
>> Generating a 4096 bit RSA private key
>> ............................................................................................................drivers/cpufreq/intel_pstate.c:
>> In function 'intel_pstate_init_cpu':
>> drivers/cpufreq/intel_pstate.c:617:18: error: 'struct pstate_data' has no member named
>> 'current_state'
>>   if (!cpu->pstate.current_state) {
> 
> My bad, that should have been current_pstate.  Updated patch is appended.
> 
> Thanks,
> Rafael
> 
> 
> ---
>  drivers/cpufreq/intel_pstate.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===================================================================
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -614,6 +614,11 @@ static int intel_pstate_init_cpu(unsigne
>  	cpu = all_cpu_data[cpunum];
>  
>  	intel_pstate_get_cpu_pstates(cpu);
> +	if (!cpu->pstate.current_pstate) {
> +		all_cpu_data[cpunum] = NULL;
> +		kfree(cpu);
> +		return -ENODATA;
> +	}
>  
>  	cpu->cpu = cpunum;
>  
> 


Thanks Rafel, I can confirm this patch helps.

I re-built the Kernel on L0 (physical host) and L1 (guest hypervisor) with
the above patch, and re-ran the libguestfs test (which invokes an L2 appliance),
it now successfully completes:

   http://kashyapc.fedorapeople.org/temp/libguestfs-test-tool-stdout.txt


Here's a Fedora Kernel scratch build (not retained for more than 2 weeks)
with the above patch I used -- http://koji.fedoraproject.org/koji/taskinfo?taskID=6342414



-- 
/kashyap
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/