From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932850AbbLNVMx (ORCPT ); Mon, 14 Dec 2015 16:12:53 -0500 Received: from vserver.eikelenboom.it ([84.200.39.61]:41734 "EHLO smtp.eikelenboom.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932075AbbLNVMu (ORCPT ); Mon, 14 Dec 2015 16:12:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 Dec 2015 22:07:30 +0100 From: Sander Eikelenboom To: Eric Shelton Cc: David Vrabel , Boris Ostrovsky , linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, knockknock@gmail.com Subject: Re: [Xen-devel] linux 4.4 Regression: 100% cpu usage on idle pv guest under Xen with single vcpu In-Reply-To: References: Message-ID: <6d217be011dd04c86ba9c3e2178b5efb@eikelenboom.it> User-Agent: Roundcube Webmail/0.9.5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015-12-14 20:48, Eric Shelton wrote: > Please note that the same issue appears to have been introduced in the > recent 4.2.7 kernel. It perhaps has to do > with b4ff8389ed14b849354b59ce9b360bdefcdbf99c having a matching > commit e8d097151d309eb71f750bbf34e6a7ef6256da7e in linux-stable.git. > The > below patch to arch/x86/kernel/rtc.c was also effective for 4.2.7. > > Eric Hi Eric, Yeah it's unfortunate the patch patching the other patches destined for stable didn't make it in time for stable :(. Any how the chosen solution wasn't ideal so there now is a V2 patch by Boris. It hasn't been picked up yet, but hopefully will be anytime soon (for the patch see http://lkml.iu.edu/hypermail/linux/kernel/1512.1/03504.html) -- Sander > On 2015-12-02 18:30, Sander Eikelenboom wrote: >> On 2015-12-02 15:55, David Vrabel wrote: >> > On 28/11/15 15:47, Sander Eikelenboom wrote: >> >> genirq: Flags mismatch irq 8. 00000000 (hvc_console) vs. 00000000 >> >> (rtc0) >> > >> > We shouldn't register an rtc_cmos device because its legacy irq >> > conflicts with the irq needed for hvc0. For a multi VCPU guest irq 8 >> > is >> > in use for the pv spinlocks and this gets requested first, preventing >> > the rtc device from probing. >> > >> > Does this patch fix it for you? >> > >> > David >> >> It does, thanks. >> >> Reported-and-tested-by: Sander Eikelenboom >> >> -- >> Sander >> >> > 8<-------------------- >> > x86: rtc_cmos platform device requires legacy irqs >> > >> > Adding the rtc platform device when there are no legacy irqs (no >> > legacy PIC) causes a conflict with other devices that end up using the >> > same irq number. >> > >> > In a single VCPU PV guest we should have: >> > >> > /proc/interrupts: >> > CPU0 >> > 0: 4934 xen-percpu-virq timer0 >> > 1: 0 xen-percpu-ipi spinlock0 >> > 2: 0 xen-percpu-ipi resched0 >> > 3: 0 xen-percpu-ipi callfunc0 >> > 4: 0 xen-percpu-virq debug0 >> > 5: 0 xen-percpu-ipi callfuncsingle0 >> > 6: 0 xen-percpu-ipi irqwork0 >> > 7: 321 xen-dyn-event xenbus >> > 8: 90 xen-dyn-event hvc_console >> > ... >> > >> > But hvc_console cannot get its interrupt because it is already in use >> > by rtc0 and the console does not work. >> > >> > genirq: Flags mismatch irq 8. 00000000 (hvc_console) vs. 00000000 >> > (rtc0) >> > >> > The rtc_cmos device requires a particular legacy irq so don't add it >> > if there are no legacy irqs. >> > >> > Signed-off-by: David Vrabel >> > --- >> > arch/x86/kernel/rtc.c | 5 +++++ >> > 1 file changed, 5 insertions(+) >> > >> > diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c >> > index cd96852..07c70f1 100644 >> > --- a/arch/x86/kernel/rtc.c >> > +++ b/arch/x86/kernel/rtc.c >> > @@ -14,6 +14,7 @@ >> > #include >> > #include >> > #include >> > +#include >> > >> > #ifdef CONFIG_X86_32 >> > /* >> > @@ -200,6 +201,10 @@ static __init int add_rtc_cmos(void) >> > } >> > #endif >> > >> > + /* RTC uses legacy IRQs. */ >> > + if (!nr_legacy_irqs()) >> > + return -ENODEV; >> > + >> > platform_device_register(&rtc_device); >> > dev_info(&rtc_device.dev, >> > "registered platform RTC device (no PNP device > found)\n");