Konrad Rzeszutek Wilk
2012-Jan-23 18:06 UTC
WARN... Device ''cpu1'' does not have a release() function, it is broken and must be fixed. when doing ''xl vcpu-set <guest_id> 1''
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'']
Greg KH
2012-Jan-23 18:13 UTC
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''
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
Greg KH
2012-Jan-27 00:06 UTC
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''
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
Kay Sievers
2012-Jan-27 00:22 UTC
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''
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
Greg KH
2012-Jan-27 00:53 UTC
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''
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
Maciej Rutecki
2012-Jan-29 09:22 UTC
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''
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
Greg KH
2012-Feb-01 22:22 UTC
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''
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);
Konrad Rzeszutek Wilk
2012-Feb-02 17:43 UTC
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''
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);
Greg KH
2012-Feb-02 18:38 UTC
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''
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