* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-01-23 18:06 WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1' Konrad Rzeszutek Wilk
@ 2012-01-23 18:13 ` Greg KH
2012-01-27 0:06 ` Greg KH
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2012-01-23 18:13 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Linus Torvalds, linux-kernel, kay.sievers, bp, tglx, mingo, hpa,
x86, lenb, xen-devel
On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
>
> [ 14.484206] SMP alternatives: switching to UP code
> [ 14.514287] ------------[ cut here ]------------
> [ 14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [ 14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [ 14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [ 14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [ 14.514586] Call Trace:
> [ 14.515094] [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [ 14.515094] [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [ 14.515094] [<ffffffff813dea02>] device_release+0x82/0x90
> [ 14.515094] [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [ 14.515094] [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [ 14.515094] [<ffffffff813de6a2>] put_device+0x12/0x20
> [ 14.515094] [<ffffffff813df409>] device_unregister+0x19/0x20
> [ 14.515094] [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [ 14.515094] [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [ 14.515094] [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [ 14.515094] [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [ 14.515094] [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [ 14.515094] [<ffffffff8137b850>] ? split+0xf0/0xf0
> [ 14.515094] [<ffffffff810acd16>] kthread+0x96/0xa0
> [ 14.515094] [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [ 14.515094] [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [ 14.515094] [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [ 14.515094] ---[ end trace 8f70af51a2e2611f ]---
>
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date: Mon Jan 16 14:40:28 2012 -0800
>
> mce: fix warning messages about static struct mce_device
> "
>
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
{sigh}
Yes, that's the correct fix, I'll do the same type of change I did for
the MCE code here as well.
Sorry we missed this one previously.
I'll get this fixed soon.
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-01-23 18:06 WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1' Konrad Rzeszutek Wilk
2012-01-23 18:13 ` Greg KH
@ 2012-01-27 0:06 ` Greg KH
2012-01-27 0:22 ` Kay Sievers
2012-01-29 9:22 ` Maciej Rutecki
2012-02-01 22:22 ` Greg KH
3 siblings, 1 reply; 9+ messages in thread
From: Greg KH @ 2012-01-27 0:06 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, kay.sievers
Cc: Linus Torvalds, linux-kernel, bp, tglx, mingo, hpa, x86, lenb,
xen-devel
On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
>
> [ 14.484206] SMP alternatives: switching to UP code
> [ 14.514287] ------------[ cut here ]------------
> [ 14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [ 14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [ 14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [ 14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [ 14.514586] Call Trace:
> [ 14.515094] [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [ 14.515094] [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [ 14.515094] [<ffffffff813dea02>] device_release+0x82/0x90
> [ 14.515094] [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [ 14.515094] [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [ 14.515094] [<ffffffff813de6a2>] put_device+0x12/0x20
> [ 14.515094] [<ffffffff813df409>] device_unregister+0x19/0x20
> [ 14.515094] [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [ 14.515094] [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [ 14.515094] [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [ 14.515094] [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [ 14.515094] [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [ 14.515094] [<ffffffff8137b850>] ? split+0xf0/0xf0
> [ 14.515094] [<ffffffff810acd16>] kthread+0x96/0xa0
> [ 14.515094] [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [ 14.515094] [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [ 14.515094] [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [ 14.515094] ---[ end trace 8f70af51a2e2611f ]---
>
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date: Mon Jan 16 14:40:28 2012 -0800
>
> mce: fix warning messages about static struct mce_device
> "
>
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
>
> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> the privilige of being the first? Oh, I hadn't done a full bisection
> but v3.2 does not have this.
Kay, this is a mess.
This cpu system device is is interconnected with the different arches
and their cpu-specific structures. Some arches have a static array,
some allocate a huge structure (struct arch_cpu * NUM_CPUS), and others
try to do the right thing with DECLARE_PER_CPU() but don't quite get it
right, making that a static array per cpu.
To unwind all of this, is much beyond 3.3 material, as I'm sure I'll get
it wrong, and have a bunch of non-x86-64 build problems along the way.
Any objection to me just doing the "hack" of the empty release function
at the moment to get rid of this warning, and then clean it all up
properly for 3.4?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-01-27 0:06 ` Greg KH
@ 2012-01-27 0:22 ` Kay Sievers
2012-01-27 0:53 ` Greg KH
0 siblings, 1 reply; 9+ messages in thread
From: Kay Sievers @ 2012-01-27 0:22 UTC (permalink / raw)
To: Greg KH
Cc: Konrad Rzeszutek Wilk, Linus Torvalds, linux-kernel, bp, tglx,
mingo, hpa, x86, lenb, xen-devel
On Fri, Jan 27, 2012 at 01:06, Greg KH <gregkh@suse.de> wrote:
> On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
>> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
>> the privilige of being the first? Oh, I hadn't done a full bisection
>> but v3.2 does not have this.
>
> Kay, this is a mess.
>
> This cpu system device is is interconnected with the different arches
> and their cpu-specific structures. Some arches have a static array,
> some allocate a huge structure (struct arch_cpu * NUM_CPUS), and others
> try to do the right thing with DECLARE_PER_CPU() but don't quite get it
> right, making that a static array per cpu.
>
> To unwind all of this, is much beyond 3.3 material, as I'm sure I'll get
> it wrong, and have a bunch of non-x86-64 build problems along the way.
>
> Any objection to me just doing the "hack" of the empty release function
> at the moment to get rid of this warning, and then clean it all up
> properly for 3.4?
No problem at all.
It would be nice if we get all that to the usual model some day, but I
can totally see that CPU devices try to deal with statically allocated
per-cpu memory. It seems fine, as long as they know what they are
doing.
Just silencing the driver-core warning here sounds fine to me.
Thanks,
Kay
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-01-27 0:22 ` Kay Sievers
@ 2012-01-27 0:53 ` Greg KH
0 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2012-01-27 0:53 UTC (permalink / raw)
To: Kay Sievers
Cc: Konrad Rzeszutek Wilk, Linus Torvalds, linux-kernel, bp, tglx,
mingo, hpa, x86, lenb, xen-devel
On Fri, Jan 27, 2012 at 01:22:46AM +0100, Kay Sievers wrote:
> On Fri, Jan 27, 2012 at 01:06, Greg KH <gregkh@suse.de> wrote:
> > On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
>
> >> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> >> the privilige of being the first? Oh, I hadn't done a full bisection
> >> but v3.2 does not have this.
> >
> > Kay, this is a mess.
> >
> > This cpu system device is is interconnected with the different arches
> > and their cpu-specific structures. Some arches have a static array,
> > some allocate a huge structure (struct arch_cpu * NUM_CPUS), and others
> > try to do the right thing with DECLARE_PER_CPU() but don't quite get it
> > right, making that a static array per cpu.
> >
> > To unwind all of this, is much beyond 3.3 material, as I'm sure I'll get
> > it wrong, and have a bunch of non-x86-64 build problems along the way.
> >
> > Any objection to me just doing the "hack" of the empty release function
> > at the moment to get rid of this warning, and then clean it all up
> > properly for 3.4?
>
> No problem at all.
>
> It would be nice if we get all that to the usual model some day, but I
> can totally see that CPU devices try to deal with statically allocated
> per-cpu memory. It seems fine, as long as they know what they are
> doing.
>
> Just silencing the driver-core warning here sounds fine to me.
Ok, I'll do that tomorrow and send a patch out and then start working on
making all of this dynamic, as it really should be.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-01-23 18:06 WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1' Konrad Rzeszutek Wilk
2012-01-23 18:13 ` Greg KH
2012-01-27 0:06 ` Greg KH
@ 2012-01-29 9:22 ` Maciej Rutecki
2012-02-01 22:22 ` Greg KH
3 siblings, 0 replies; 9+ messages in thread
From: Maciej Rutecki @ 2012-01-29 9:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Linus Torvalds, gregkh, linux-kernel, kay.sievers, bp, tglx,
mingo, hpa, x86, lenb, xen-devel
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=42683
for your bug report, please add your address to the CC list in there, thanks!
On poniedziałek, 23 stycznia 2012 o 19:06:01 Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
>
> [ 14.484206] SMP alternatives: switching to UP code
> [ 14.514287] ------------[ cut here ]------------
> [ 14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194
> device_release+0x82/0x90() [ 14.514354] Device 'cpu1' does not have a
> release() function, it is broken and must be fixed. [ 14.514386] Modules
> linked in: radeon fbcon tileblit font ttm bitblit softcursor
> drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt
> sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd [ 14.514557] Pid:
> 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [ 14.514586] Call Trace:
> [ 14.515094] [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [ 14.515094] [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [ 14.515094] [<ffffffff813dea02>] device_release+0x82/0x90
> [ 14.515094] [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [ 14.515094] [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [ 14.515094] [<ffffffff813de6a2>] put_device+0x12/0x20
> [ 14.515094] [<ffffffff813df409>] device_unregister+0x19/0x20
> [ 14.515094] [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [ 14.515094] [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [ 14.515094] [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [ 14.515094] [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [ 14.515094] [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [ 14.515094] [<ffffffff8137b850>] ? split+0xf0/0xf0
> [ 14.515094] [<ffffffff810acd16>] kthread+0x96/0xa0
> [ 14.515094] [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [ 14.515094] [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [ 14.515094] [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [ 14.515094] ---[ end trace 8f70af51a2e2611f ]---
>
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date: Mon Jan 16 14:40:28 2012 -0800
>
> mce: fix warning messages about static struct mce_device
> "
>
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
>
> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> the privilige of being the first? Oh, I hadn't done a full bisection
> but v3.2 does not have this.
>
> The guest config is quite simple:
> extra="console=hvc0 debug earlyprintk=xen memblock=debug"
> kernel="/mnt/lab/bootstrap-x86_64/vmlinuz"
> ramdisk="/mnt/lab/bootstrap-x86_64/initramfs.cpio.gz"
> memory=1024
> maxmem=2048
> vcpus=2
> name="bootstrap-x86_64"
> on_crash="preserve"
> vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
> --
> 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/
--
Maciej Rutecki
http://www.mrutecki.pl
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-01-23 18:06 WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1' Konrad Rzeszutek Wilk
` (2 preceding siblings ...)
2012-01-29 9:22 ` Maciej Rutecki
@ 2012-02-01 22:22 ` Greg KH
2012-02-02 17:43 ` Konrad Rzeszutek Wilk
3 siblings, 1 reply; 9+ messages in thread
From: Greg KH @ 2012-02-01 22:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Linus Torvalds, gregkh, linux-kernel, kay.sievers, bp, tglx,
mingo, hpa, x86, lenb, xen-devel
On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
>
> [ 14.484206] SMP alternatives: switching to UP code
> [ 14.514287] ------------[ cut here ]------------
> [ 14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [ 14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [ 14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [ 14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [ 14.514586] Call Trace:
> [ 14.515094] [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [ 14.515094] [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [ 14.515094] [<ffffffff813dea02>] device_release+0x82/0x90
> [ 14.515094] [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [ 14.515094] [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [ 14.515094] [<ffffffff813de6a2>] put_device+0x12/0x20
> [ 14.515094] [<ffffffff813df409>] device_unregister+0x19/0x20
> [ 14.515094] [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [ 14.515094] [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [ 14.515094] [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [ 14.515094] [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [ 14.515094] [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [ 14.515094] [<ffffffff8137b850>] ? split+0xf0/0xf0
> [ 14.515094] [<ffffffff810acd16>] kthread+0x96/0xa0
> [ 14.515094] [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [ 14.515094] [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [ 14.515094] [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [ 14.515094] ---[ end trace 8f70af51a2e2611f ]---
>
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date: Mon Jan 16 14:40:28 2012 -0800
>
> mce: fix warning messages about static struct mce_device
> "
>
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
>
> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> the privilige of being the first? Oh, I hadn't done a full bisection
> but v3.2 does not have this.
Does the patch below solve the problem for you?
thanks,
greg k-h
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index db87e78..23f2c4c 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -208,6 +208,25 @@ static ssize_t print_cpus_offline(struct device *dev,
}
static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
+static void cpu_device_release(struct device *dev)
+{
+ /*
+ * This is an empty function to prevent the driver core from spitting a
+ * warning at us. Yes, I know this is directly opposite of what the
+ * documentation for the driver core and kobjects say, and the author
+ * of this code has already been publically ridiculed for doing
+ * something as foolish as this. However, at this point in time, it is
+ * the only way to handle the issue of statically allocated cpu
+ * devices. The different architectures will have their cpu device
+ * code reworked to properly handle this in the near future, so this
+ * function will then be changed to correctly free up the memory held
+ * by the cpu device.
+ *
+ * Never copy this way of doing things, or you too will be made fun of
+ * on the linux-kerenl list, you have been warned.
+ */
+}
+
/*
* register_cpu - Setup a sysfs device for a CPU.
* @cpu - cpu->hotpluggable field set to 1 will generate a control file in
@@ -223,6 +242,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
cpu->node_id = cpu_to_node(num);
cpu->dev.id = num;
cpu->dev.bus = &cpu_subsys;
+ cpu->dev.release = cpu_device_release;
error = device_register(&cpu->dev);
if (!error && cpu->hotpluggable)
register_cpu_control(cpu);
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-02-01 22:22 ` Greg KH
@ 2012-02-02 17:43 ` Konrad Rzeszutek Wilk
2012-02-02 18:38 ` Greg KH
0 siblings, 1 reply; 9+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-02-02 17:43 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, gregkh, linux-kernel, kay.sievers, bp, tglx,
mingo, hpa, x86, lenb, xen-devel
On Wed, Feb 01, 2012 at 02:22:50PM -0800, Greg KH wrote:
> On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> > When I bring a CPU down in a guest (which should be the same as bringing a
> > CPU down using the ACPI framework), I get this:
> >
> > [ 14.484206] SMP alternatives: switching to UP code
> > [ 14.514287] ------------[ cut here ]------------
> > [ 14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> > [ 14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> > [ 14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> > [ 14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> > [ 14.514586] Call Trace:
> > [ 14.515094] [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> > [ 14.515094] [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> > [ 14.515094] [<ffffffff813dea02>] device_release+0x82/0x90
> > [ 14.515094] [<ffffffff812dfb85>] kobject_release+0x45/0x90
> > [ 14.515094] [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> > [ 14.515094] [<ffffffff813de6a2>] put_device+0x12/0x20
> > [ 14.515094] [<ffffffff813df409>] device_unregister+0x19/0x20
> > [ 14.515094] [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> > [ 14.515094] [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> > [ 14.515094] [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> > [ 14.515094] [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> > [ 14.515094] [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> > [ 14.515094] [<ffffffff8137b850>] ? split+0xf0/0xf0
> > [ 14.515094] [<ffffffff810acd16>] kthread+0x96/0xa0
> > [ 14.515094] [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> > [ 14.515094] [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> > [ 14.515094] [<ffffffff816151e0>] ? gs_change+0x13/0x13
> > [ 14.515094] ---[ end trace 8f70af51a2e2611f ]---
> >
> > Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> > Author: Greg Kroah-Hartman <gregkh@suse.de>
> > Date: Mon Jan 16 14:40:28 2012 -0800
> >
> > mce: fix warning messages about static struct mce_device
> > "
> >
> > it looks like the corret fix is to make the 'cpu_devices' in
> > arch/x86/kernel/topology.c to be changed to be more dynamic
> > (or perhaps have an empty release function)?
> >
> > Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> > the privilige of being the first? Oh, I hadn't done a full bisection
> > but v3.2 does not have this.
>
> Does the patch below solve the problem for you?
Hey Greg,
Indeed it does.
For the patch below, please put 'Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>'
Thanks!
>
> thanks,
>
> greg k-h
>
>
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index db87e78..23f2c4c 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -208,6 +208,25 @@ static ssize_t print_cpus_offline(struct device *dev,
> }
> static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
>
> +static void cpu_device_release(struct device *dev)
> +{
> + /*
> + * This is an empty function to prevent the driver core from spitting a
> + * warning at us. Yes, I know this is directly opposite of what the
> + * documentation for the driver core and kobjects say, and the author
> + * of this code has already been publically ridiculed for doing
> + * something as foolish as this. However, at this point in time, it is
> + * the only way to handle the issue of statically allocated cpu
> + * devices. The different architectures will have their cpu device
> + * code reworked to properly handle this in the near future, so this
> + * function will then be changed to correctly free up the memory held
> + * by the cpu device.
> + *
> + * Never copy this way of doing things, or you too will be made fun of
> + * on the linux-kerenl list, you have been warned.
> + */
> +}
> +
> /*
> * register_cpu - Setup a sysfs device for a CPU.
> * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
> @@ -223,6 +242,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
> cpu->node_id = cpu_to_node(num);
> cpu->dev.id = num;
> cpu->dev.bus = &cpu_subsys;
> + cpu->dev.release = cpu_device_release;
> error = device_register(&cpu->dev);
> if (!error && cpu->hotpluggable)
> register_cpu_control(cpu);
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: WARN... Device 'cpu1' does not have a release() function, it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
2012-02-02 17:43 ` Konrad Rzeszutek Wilk
@ 2012-02-02 18:38 ` Greg KH
0 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2012-02-02 18:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Linus Torvalds, gregkh, linux-kernel, kay.sievers, bp, tglx,
mingo, hpa, x86, lenb, xen-devel
On Thu, Feb 02, 2012 at 12:43:30PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 01, 2012 at 02:22:50PM -0800, Greg KH wrote:
> > Does the patch below solve the problem for you?
>
> Hey Greg,
>
> Indeed it does.
>
> For the patch below, please put 'Tested-by: Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>'
Wonderful, thanks for testing, I'll queue this up soon.
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread