From: Greg KH <gregkh@suse.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, kay.sievers@vrfy.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, bp@amd64.org, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, x86@kernel.org, lenb@kernel.org,
xen-devel@lists.xensource.com
Subject: 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'
Date: Thu, 26 Jan 2012 16:06:12 -0800 [thread overview]
Message-ID: <20120127000612.GA14678@suse.de> (raw)
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
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
next prev parent reply other threads:[~2012-01-27 0:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2012-01-27 0:22 ` Kay Sievers
2012-01-27 0:53 ` Greg KH
2012-01-29 9:22 ` Maciej Rutecki
2012-02-01 22:22 ` Greg KH
2012-02-02 17:43 ` Konrad Rzeszutek Wilk
2012-02-02 18:38 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120127000612.GA14678@suse.de \
--to=gregkh@suse.de \
--cc=bp@amd64.org \
--cc=hpa@zytor.com \
--cc=kay.sievers@vrfy.org \
--cc=konrad.wilk@oracle.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).