From: ykzhao <yakui.zhao@intel.com>
To: Thomas Renninger <trenn@suse.de>
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: Wed, 02 Jun 2010 09:22:46 +0800 [thread overview]
Message-ID: <1275441766.3718.15.camel@localhost.localdomain> (raw)
In-Reply-To: <201005282125.15681.trenn@suse.de>
On Sat, 2010-05-29 at 03:25 +0800, Thomas Renninger wrote:
> On Friday 28 May 2010 08:46:27 pm Len Brown wrote:
> > On Wed, 26 May 2010, Thomas Renninger wrote:
> > > Patch is against latest Linus master branch and is expected to be
> > > safe bug fix.
> > >
> > > You get:
> > > ACPI: HARDWARE addr space,NOT supported yet
> > > for each ACPI defined CPU which status is active, but exceeds
> > > maxcpus= count.
> > >
> > > As these "not booted" CPUs do not run an idle routine
> > > and echo X >/proc/acpi/processor/*/throttling did not work
> > > I couldn't find a way to really access not onlined/booted
> > > machines. Still this should get fixed and
> > > /proc/acpi/processor/X dirs of cores exceeding maxcpus
> > > should not show up.
> >
> > Can we delete the /proc/acpi/processor/ dirs instead of maintaining them?
>
> 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 or simply use the
cpuinfo of the first boot CPU to fix the corresponding warning message?
Maybe we will change the T-state for the hot-onlined cpu.
thanks.
>
> Similar to what happens (happened?) on acpi processor (real) hotplug.
>
> The proc files should vanish in a separate patch, but I am not sure what
> could break.
> I saw powertop still reading battery info from /proc, I thought hal is also
> still accessing it, but I cannot say for sure.
>
> Thomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-06-02 1:25 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 [this message]
2010-06-06 21:04 ` Thomas Renninger
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=1275441766.3718.15.camel@localhost.localdomain \
--to=yakui.zhao@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=travis@sgi.com \
--cc=trenn@suse.de \
/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).