Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752658AbaACRac (ORCPT ); Fri, 3 Jan 2014 12:30:32 -0500 Received: from mail-pd0-f172.google.com ([209.85.192.172]:48410 "EHLO mail-pd0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750935AbaACRa2 (ORCPT ); Fri, 3 Jan 2014 12:30:28 -0500 Message-ID: <52C6F3B4.3050904@gmail.com> Date: Fri, 03 Jan 2014 09:30:28 -0800 From: Dirk Brandewie User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Rafael J. Wysocki" , Kashyap Chamarthy CC: Gleb Natapov , Josh Boyer , One Thousand Gnomes , Viresh Kumar , "cpufreq@vger.kernel.org" , Linux PM list , "Linux-Kernel@Vger. Kernel. Org" , "Richard W.M. Jones" Subject: Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad References: <4794554.Hmd2RUNYDT@vostro.rjw.lan> <52C18A23.10703@redhat.com> <3710588.K8glfx1cYs@vostro.rjw.lan> In-Reply-To: <3710588.K8glfx1cYs@vostro.rjw.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5971 Lines: 151 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? Can some one tell me how the nested environment differs in regards to reading MSRs? TIA --Dirk On 12/30/2013 06:07 PM, Rafael J. Wysocki wrote: >>> --- >>> 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. > > Awesome, thanks! > > Below is an official version with a changelog. I'll queue it up as a fix > for 3.13. > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki > Subject: intel_pstate: Fail initialization if P-state information is missing > > If pstate.current_pstate is 0 after the initial > intel_pstate_get_cpu_pstates(), this means that we were unable to > obtain any useful P-state information and there is no reason to > continue, so free memory and return an error in that case. > > This fixes the following divide error occuring in a nested KVM > guest: > > Intel P-state driver initializing. > Intel pstate controlling: cpu 0 > cpufreq: __cpufreq_add_dev: ->get() failed > divide error: 0000 [#1] SMP > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1 > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > task: ffff88001ea20000 ti: ffff88001e9bc000 task.ti: ffff88001e9bc000 > RIP: 0010:[] [] intel_pstate_timer_func+0x11d/0x2b0 > RSP: 0000:ffff88001ee03e18 EFLAGS: 00010246 > RAX: 0000000000000000 RBX: ffff88001a454348 RCX: 0000000000006100 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: ffff88001ee03e38 R08: 0000000000000000 R09: 0000000000000000 > R10: ffff88001ea20000 R11: 0000000000000000 R12: 00000c0a1ea20000 > R13: 1ea200001ea20000 R14: ffffffff815c5400 R15: ffff88001a454348 > FS: 0000000000000000(0000) GS:ffff88001ee00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000006f0 > Stack: > fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100 > ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40 > ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000 > Call Trace: > > [] call_timer_fn+0x8a/0x310 > [] ? call_timer_fn+0x5/0x310 > [] ? pid_param_set+0x130/0x130 > [] run_timer_softirq+0x234/0x380 > [] __do_softirq+0x104/0x430 > [] irq_exit+0xcd/0xe0 > [] smp_apic_timer_interrupt+0x45/0x60 > [] apic_timer_interrupt+0x72/0x80 > > [] ? vprintk_emit+0x1dd/0x5e0 > [] printk+0x67/0x69 > [] __cpufreq_add_dev.isra.13+0x883/0x8d0 > [] cpufreq_add_dev+0x10/0x20 > [] subsys_interface_register+0xb1/0xf0 > [] cpufreq_register_driver+0x9f/0x210 > [] intel_pstate_init+0x27d/0x3be > [] ? mutex_unlock+0xe/0x10 > [] ? cpufreq_gov_dbs_init+0x12/0x12 > [] do_one_initcall+0xfa/0x1b0 > [] ? parse_args+0x225/0x3f0 > [] kernel_init_freeable+0x1fc/0x287 > [] ? do_early_param+0x88/0x88 > [] ? rest_init+0x150/0x150 > [] kernel_init+0xe/0x130 > [] ret_from_fork+0x7c/0xb0 > [] ? rest_init+0x150/0x150 > Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89 > RIP [] intel_pstate_timer_func+0x11d/0x2b0 > RSP > ---[ end trace f166110ed22cc37a ]--- > Kernel panic - not syncing: Fatal exception in interrupt > > Reported-and-tested-by: Kashyap Chamarthy > Cc: Josh Boyer > Signed-off-by: Rafael J. Wysocki > --- > 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; > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/