+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
+Subject: [PATCH] small fixes to 3.3 (and 3.2) CPU hotplug code. (v1)
+Date: Wed, 1 Feb 2012 16:16:38 -0500
+
+While I was playing with 'xm vcpu-set X N' I realized that the VCPU hotplug
+code in 3.2 spews tons of messages. Found out that we were missing an preempt_*
+call. While at it, I fixed also an annoying message ("XENBUS: Unable to ..")
+that shows up during bootup.
+
+Anyhow, these are going for 3.3 and CC-ing stable on the:
+ [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG:
+
+--
+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/
+
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
+Subject: [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
+Date: Wed, 1 Feb 2012 16:16:39 -0500
+
+When a user offlines a VCPU and then onlines it, we get:
+
+NMI watchdog disabled (cpu2): hardware events not enabled
+BUG: scheduling while atomic: swapper/2/0/0x00000002
+Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod libcrc32c crc32c radeon fbco
+ ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs [last unloaded:
+
+Pid: 0, comm: swapper/2 Tainted: G O 3.2.0phase15.1-00003-gd6f7f5b-dirty #4
+Call Trace:
+ [<ffffffff81070571>] __schedule_bug+0x61/0x70
+ [<ffffffff8158eb78>] __schedule+0x798/0x850
+ [<ffffffff8158ed6a>] schedule+0x3a/0x50
+ [<ffffffff810349be>] cpu_idle+0xbe/0xe0
+ [<ffffffff81583599>] cpu_bringup_and_idle+0xe/0x10
+
+The reason for this should be obvious from this call-chain:
+cpu_bringup_and_idle:
+ \- cpu_bringup
+ | \-[preempt_disable]
+ |
+ |- cpu_idle
+ \- play_dead [assuming the user offlined the VCPU]
+ | \
+ | +- (xen_play_dead)
+ | \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
+ | | onlines it starts from here]
+ | \- cpu_bringup [preempt_disable]
+ |
+ +- preempt_enable_no_reschedule()
+ +- schedule()
+ \- preempt_enable()
+
+So we have two preempt_disble() and one preempt_enable(). Calling
+preempt_enable() after the cpu_bringup() in the xen_play_dead
+fixes the imbalance.
+
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+---
+ arch/x86/xen/smp.c | 7 +++++++
+ 1 files changed, 7 insertions(+), 0 deletions(-)
+
+diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
+index 041d4fe..501d4e0 100644
+--- a/arch/x86/xen/smp.c
++++ b/arch/x86/xen/smp.c
+@@ -409,6 +409,13 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
+ play_dead_common();
+ HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
+ cpu_bringup();
++ /*
++ * Balance out the preempt calls - as we are running in cpu_idle
++ * loop which has been called at bootup from cpu_bringup_and_idle.
++ * The cpucpu_bringup_and_idle called cpu_bringup which made a
++ * preempt_disable() So this preempt_enable will balance it out.
++ */
++ preempt_enable();
+ }
+
+ #else /* !CONFIG_HOTPLUG_CPU */
+--
+1.7.7.5
+
+--
+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/
+
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
+Subject: [PATCH 2/2] xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
+Date: Wed, 1 Feb 2012 16:16:40 -0500
+
+When the initial domain starts, it prints (depending on the
+amount of CPUs) a slew of
+XENBUS: Unable to read cpu state
+XENBUS: Unable to read cpu state
+XENBUS: Unable to read cpu state
+XENBUS: Unable to read cpu state
+
+which provide no useful information - as the error is a valid
+issue - but not on the initial domain. The reason is that the
+XenStore is not accessible at that time (it is after all the
+first guest) so the CPU hotplug watch cannot parse "availability/cpu"
+attribute.
+
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+---
+ drivers/xen/cpu_hotplug.c | 3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
+index 14e2d99..4dcfced 100644
+--- a/drivers/xen/cpu_hotplug.c
++++ b/drivers/xen/cpu_hotplug.c
+@@ -30,7 +30,8 @@ static int vcpu_online(unsigned int cpu)
+ sprintf(dir, "cpu/%u", cpu);
+ err = xenbus_scanf(XBT_NIL, dir, "availability", "%s", state);
+ if (err != 1) {
+- printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
++ if (!xen_initial_domain())
++ printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
+ return err;
+ }
+
+--
+1.7.7.5
+
+--
+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/
+
projects / packages / kernel.git / commitdiff