From: Thomas Renninger <trenn@suse.de>
To: ykzhao <yakui.zhao@intel.com>
Cc: Len Brown <lenb@kernel.org>, "travis@sgi.com" <travis@sgi.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] ACPI: Do not try to set up acpi processor stuff on cores exceeding maxcpus=
Date: Sun, 6 Jun 2010 23:04:36 +0200 [thread overview]
Message-ID: <201006062304.36663.trenn@suse.de> (raw)
In-Reply-To: <1275441766.3718.15.camel@localhost.localdomain>
On Wednesday 02 June 2010 03:22:46 am ykzhao wrote:
> On Sat, 2010-05-29 at 03:25 +0800, Thomas Renninger wrote:
...
> > This is not about "not creating proc files", but about setting up
> > throttling/c-states for not booted CPUs.
> > The message:
> > ACPI: HARDWARE addr space,NOT supported yet
> > comes from throttling init code. It goes an undefined path because
> >
> > struct cpuinfo_x86 *c = &cpu_data(cpu);
> > is uninitialized (all is zero...):
> > if ((c->x86_vendor != X86_VENDOR_INTEL) ||
> > !cpu_has(c, X86_FEATURE_ACPI)) {
> > printk(KERN_ERR PREFIX
> > "HARDWARE addr space,NOT supported yet\n");
>
> Agree with your analysis.
>
> Can we add "online check" in the above throtting patch
Not really. You get corner cases you need to check for:
CPUs get offlined manually -> processor driver gets loaded ->
CPU gets onlined again -> Throttling/C-states wil be uninitialized.
> or simply use the
> cpuinfo of the first boot CPU to fix the corresponding warning message?
This is an ugly hack (I also thought about it to be honest). Then the whole or
quite some variables of the per_cpu cpuinfo_x86 structure could be made
global and need not to be per_cpu based. This also indicates that something
in the processor driver is wrong by design.
> Maybe we will change the T-state for the hot-onlined cpu.
Not sure I understand this sentence:
If the CPU is beyond maxcpus=X you must not be able to change T-states
for this CPU.
Hm, the hotplug cleanup patch I sent recently would take care of above and
make this tiny sanity check unnecessary (I sent that just for Len to get a
picture what's missing in procoessor driver code for real CPU hotplug):
http://permalink.gmane.org/gmane.linux.power-management.general/19491
There still were issues with this patch (not sure when I try on this again, it
has low prio for me currently), thus I'd appreciate if this safe sanity check
could just go to Linus.
Thanks,
Thomas
next prev parent reply other threads:[~2010-06-06 21:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 15:03 [PATCH] ACPI: Do not try to set up acpi processor stuff on cores exceeding maxcpus= Thomas Renninger
2010-05-28 18:46 ` Len Brown
2010-05-28 19:25 ` Thomas Renninger
2010-06-02 1:22 ` ykzhao
2010-06-06 21:04 ` Thomas Renninger [this message]
2010-06-09 22:04 ` Len Brown
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=201006062304.36663.trenn@suse.de \
--to=trenn@suse.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=travis@sgi.com \
--cc=yakui.zhao@intel.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).