Hi,
Ive received a few complaints that HT, starting from 2.4.22, needs ACPI
enabled. Users who had HT working now have to use ACPI and they didnt
before.
We should have HT working AUTOMATICALLY without ACPI enabled and WITHOUT
any special boot option, as before.
Please lets fix that up
Len?
I think we agreed on that, and Len should be working on this.
Thanks,
Jun
> -----Original Message-----
> From: [email protected] [mailto:linux-kernel-
> [email protected]] On Behalf Of Marcelo Tosatti
> Sent: Monday, September 22, 2003 2:01 AM
> To: [email protected]; Brown, Len; Alan Cox
> Subject: HT not working by default since 2.4.22
>
>
> Hi,
>
> Ive received a few complaints that HT, starting from 2.4.22, needs
ACPI
> enabled. Users who had HT working now have to use ACPI and they didnt
> before.
>
> We should have HT working AUTOMATICALLY without ACPI enabled and
WITHOUT
> any special boot option, as before.
>
> Please lets fix that up
>
> Len?
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Marcelo,
If somebody has a 2.4.22 system where CONFIG_ACPI_HT_ONLY plus zero
cmdline parameters doesn't result in HT running and no ACPI running,
then please forward the details directly to me.
Thanks,
-Len
Ps. CONFIG_ACPI_HT_ONLY "CPU Enumeration Only" is under the CONFIG_ACPI
menu at the request of Red Hat, who wanted to be able to disable
anything to do with ACPI with a single option (CONFIG_ACPI). HT depends
on this part of ACPI b/c the logical HT processors are enumerated using
the ACPI MADT LAPIC entries.
> -----Original Message-----
> From: Marcelo Tosatti [mailto:[email protected]]
> Sent: Monday, September 22, 2003 5:01 AM
> To: [email protected]; Brown, Len; Alan Cox
> Subject: HT not working by default since 2.4.22
>
>
>
> Hi,
>
> Ive received a few complaints that HT, starting from 2.4.22,
> needs ACPI
> enabled. Users who had HT working now have to use ACPI and they didnt
> before.
>
> We should have HT working AUTOMATICALLY without ACPI enabled
> and WITHOUT
> any special boot option, as before.
>
> Please lets fix that up
>
> Len?
>
>
>
>
On Mon, Sep 22, 2003 at 01:28:03PM -0400, Brown, Len wrote:
> If somebody has a 2.4.22 system where CONFIG_ACPI_HT_ONLY plus zero
> cmdline parameters doesn't result in HT running and no ACPI running,
> then please forward the details directly to me.
The old acpitable.[ch] was unconditionally enabled... So _not_
unconditionally enabling HT was a regression.
(just pointing out a fact; I actually prefer a CONFIG_xxx)
Jeff
Okay, so what to do?
We could make 2.4.23 like 2.4.21 where ACPI code for HT is included in
the kernel even when CONFIG_ACPI is not set.
Or we could leave 2.4.23 like 2.4.22 where disabling CONFIG_ACPI really
does remove all ACPI code in the kernel; and when CONFIG_ACPI is set,
CONFIG_ACPI_HT_ONLY is available to limit ACPI to just the tables part
needed for HT.
I'd prefer the later (doing nothing) because CONFIG_ACPI really should
exclude all of ACPI. If we start including bits of ACPI without
CONFIG_ACPI, where do we stop?
I'm not sure how to address "compatibility" and "regression" concepts in
the face of changing config files. Make oldconfig will ask you about
CONFIG_ACPI -- perhaps I should update the help text to emphasize that
it is necessary for HT, and that if selected, CONFIG_ACPI_HT_ONLY is
then available?
Is defconfig used? Does it define "compatibility"? If so, we could
define CONFIG_ACPI && CONFIG_ACPI_HT_ONLY in defconfig to get the 2.4.21
behavior -- then could have our cake and eat it too.
I don't feel strongly about which way to go, but I will want to keep 2.4
and 2.6 as similar as possible in this area.
Thanks,
-Len
> -----Original Message-----
> From: Jeff Garzik [mailto:[email protected]]
> Sent: Monday, September 22, 2003 1:55 PM
> To: Brown, Len
> Cc: Marcelo Tosatti; [email protected]; Alan Cox;
> Nakajima, Jun
> Subject: Re: HT not working by default since 2.4.22
>
>
> On Mon, Sep 22, 2003 at 01:28:03PM -0400, Brown, Len wrote:
> > If somebody has a 2.4.22 system where CONFIG_ACPI_HT_ONLY plus zero
> > cmdline parameters doesn't result in HT running and no ACPI running,
> > then please forward the details directly to me.
>
> The old acpitable.[ch] was unconditionally enabled... So _not_
> unconditionally enabling HT was a regression.
>
> (just pointing out a fact; I actually prefer a CONFIG_xxx)
>
> Jeff
>
>
>
>
> [[email protected]]
>
> I'm not sure how to address "compatibility" and "regression" concepts in
> the face of changing config files. Make oldconfig will ask you about
> CONFIG_ACPI -- perhaps I should update the help text to emphasize that
> it is necessary for HT, and that if selected, CONFIG_ACPI_HT_ONLY is
> then available?
Hmm, I happen to know of a system that fails to detect the sibling CPU(s)
with CONFIG_ACPI_HT_ONLY set, whereas w/o it "all fine running's."
Is this a bug?
--
Tomas Szepe <[email protected]>
On Wed, 24 Sep 2003, Brown, Len wrote:
> Okay, so what to do?
>
> We could make 2.4.23 like 2.4.21 where ACPI code for HT is included in
> the kernel even when CONFIG_ACPI is not set.
>
> Or we could leave 2.4.23 like 2.4.22 where disabling CONFIG_ACPI really
> does remove all ACPI code in the kernel; and when CONFIG_ACPI is set,
> CONFIG_ACPI_HT_ONLY is available to limit ACPI to just the tables part
> needed for HT.
CONFIG_ACPI_HT should be not dependant on CONFIG_ACPI. So
1) Please make it very clear on the configuration that for HT
CONFIG_ACPI_HT_ONLY is needed
2) Move it outside CONFIG_ACPI.
OK?
Thank you.
[email protected] wrote:
> On Wed, 24 Sep 2003, Brown, Len wrote:
>
>
>>Okay, so what to do?
>>
>>We could make 2.4.23 like 2.4.21 where ACPI code for HT is included in
>>the kernel even when CONFIG_ACPI is not set.
>>
>>Or we could leave 2.4.23 like 2.4.22 where disabling CONFIG_ACPI really
>>does remove all ACPI code in the kernel; and when CONFIG_ACPI is set,
>>CONFIG_ACPI_HT_ONLY is available to limit ACPI to just the tables part
>>needed for HT.
>
>
> CONFIG_ACPI_HT should be not dependant on CONFIG_ACPI. So
>
> 1) Please make it very clear on the configuration that for HT
> CONFIG_ACPI_HT_ONLY is needed
> 2) Move it outside CONFIG_ACPI.
>
> OK?
Unfortunately CONFIG_ACPI_HT_ONLY outside and independent of CONFIG_ACPI
proved a bit confusing.
How about the more simple CONFIG_HYPERTHREAD or CONFIG_HT?
If enabled and CONFIG_SMP is set, then we will attempt to discover HT
via ACPI tables, regardless of CONFIG_ACPI value.
Or... (I know multiple people will shoot me for saying this) we could
resurrect acpitable.[ch], and build that when CONFIG_ACPI is disabled.
Jeff
> How about the more simple CONFIG_HYPERTHREAD or CONFIG_HT?
>
> If enabled and CONFIG_SMP is set, then we will attempt to discover HT
> via ACPI tables, regardless of CONFIG_ACPI value.
>
Sounds good to me.
Thanks,
Jun
> -----Original Message-----
> From: Jeff Garzik [mailto:[email protected]]
> Sent: Thursday, September 25, 2003 5:04 PM
> To: [email protected]
> Cc: Brown, Len; Marcelo Tosatti; [email protected]; Alan
Cox;
> Nakajima, Jun
> Subject: Re: HT not working by default since 2.4.22
>
> [email protected] wrote:
> > On Wed, 24 Sep 2003, Brown, Len wrote:
> >
> >
> >>Okay, so what to do?
> >>
> >>We could make 2.4.23 like 2.4.21 where ACPI code for HT is included
in
> >>the kernel even when CONFIG_ACPI is not set.
> >>
> >>Or we could leave 2.4.23 like 2.4.22 where disabling CONFIG_ACPI
really
> >>does remove all ACPI code in the kernel; and when CONFIG_ACPI is
set,
> >>CONFIG_ACPI_HT_ONLY is available to limit ACPI to just the tables
part
> >>needed for HT.
> >
> >
> > CONFIG_ACPI_HT should be not dependant on CONFIG_ACPI. So
> >
> > 1) Please make it very clear on the configuration that for HT
> > CONFIG_ACPI_HT_ONLY is needed
> > 2) Move it outside CONFIG_ACPI.
> >
> > OK?
>
>
> Unfortunately CONFIG_ACPI_HT_ONLY outside and independent of
CONFIG_ACPI
> proved a bit confusing.
>
> How about the more simple CONFIG_HYPERTHREAD or CONFIG_HT?
>
> If enabled and CONFIG_SMP is set, then we will attempt to discover HT
> via ACPI tables, regardless of CONFIG_ACPI value.
>
> Or... (I know multiple people will shoot me for saying this) we could
> resurrect acpitable.[ch], and build that when CONFIG_ACPI is disabled.
>
> Jeff
>
>
> Unfortunately CONFIG_ACPI_HT_ONLY outside and independent of CONFIG_ACPI
> proved a bit confusing.
It was outside, but it wasn't independent -- and _that_ I think was the
source of confusion.
CONFIG_ACPI depended on CONFIG_ACPI_HT. This looked good on paper
because CONFIG_ACPI_HT is a sub-set of CONFIG_ACPI...
But people who wanted ACPI but didn't want HT (eg. everybody with a PIII
laptop...) were perplexed that they had to "enable HT" in order to get
ACPI.
> How about the more simple CONFIG_HYPERTHREAD or CONFIG_HT?
>
> If enabled and CONFIG_SMP is set, then we will attempt to discover HT
> via ACPI tables, regardless of CONFIG_ACPI value.
Yes, except I think we should keep the name CONFIG_ACPI_HT_ONLY since it
says exactly what it does.
Hopefully I can make it looke clear in the menus --
I think on the config menus for CONFIG_ACPI_HT_ONLY and CONFIG_ACPI
should be mutually exclusive.
> Or... (I know multiple people will shoot me for saying this) we could
> resurrect acpitable.[ch], and build that when CONFIG_ACPI is disabled.
The question about configs is independent of the acpitable.[ch] vs
table.c implementation. No, we should not return to maintaining two
copies of the acpi table code.
thanks,
-Len
On Thu, Sep 25, 2003 at 11:37:43PM -0400, Len Brown wrote:
> > How about the more simple CONFIG_HYPERTHREAD or CONFIG_HT?
> >
> > If enabled and CONFIG_SMP is set, then we will attempt to discover HT
> > via ACPI tables, regardless of CONFIG_ACPI value.
>
> Yes, except I think we should keep the name CONFIG_ACPI_HT_ONLY since it
> says exactly what it does.
>
> Hopefully I can make it looke clear in the menus --
> I think on the config menus for CONFIG_ACPI_HT_ONLY and CONFIG_ACPI
> should be mutually exclusive.
Now that I've thought of it (aren't I humble), I rather like CONFIG_HT.
It's simple and it's effects should be obvious to both developer and
user:
CONFIG_HT, CONFIG_ACPI == ACPI
!CONFIG_HT, CONFIG_ACPI == ACPI
CONFIG_HT, !CONFIG_ACPI == HT-only ACPI
!CONFIG_HT, !CONFIG_ACPI == no ACPI
Following the "autoconf model", what we really want to be testing with
CONFIG_xxx is _features_, where possible. "hyperthreading: yes/no" is
IMO more clear than "do I want ht-only ACPI or full ACPI", while at the
same time being more fine-grained and future-proof.
> > Or... (I know multiple people will shoot me for saying this) we could
> > resurrect acpitable.[ch], and build that when CONFIG_ACPI is disabled.
>
> The question about configs is independent of the acpitable.[ch] vs
> table.c implementation. No, we should not return to maintaining two
> copies of the acpi table code.
Point; agreed.
Jeff
> Now that I've thought of it (aren't I humble), I rather like
> CONFIG_HT.
> It's simple and it's effects should be obvious to both developer and
> user:
>
> CONFIG_HT, CONFIG_ACPI == ACPI
> !CONFIG_HT, CONFIG_ACPI == ACPI
> CONFIG_HT, !CONFIG_ACPI == HT-only ACPI
> !CONFIG_HT, !CONFIG_ACPI == no ACPI
>
> Following the "autoconf model", what we really want to be testing with
> CONFIG_xxx is _features_, where possible. "hyperthreading: yes/no" is
> IMO more clear than "do I want ht-only ACPI or full ACPI",
> while at the
> same time being more fine-grained and future-proof.
I like positive logic too.
I went so far as to try to implement this back when I deleted "noht".
The problem is that "!CONFIG_HT" is meaningless. It implies that
you can have CONFIG_ACPI but still "config-out" HT, which you can't.
Ie. The 2nd row above says to give me ACPI w/o HT.
If you delete that row and reverse the polarity you get:
!CONFIG_ACPI_HT_ONLY, CONFIG_ACPI == ACPI
CONFIG_ACPI_HT_ONLY, !CONFIG_ACPI == HT-only ACPI
!CONFIG_ACPI_HT_ONLY, !CONFIG_ACPI == no ACPI
Here we can use config to emphasize that it is not possible to select
CONFIG_ACPI and CONFIG_ACPI_HT_ONLY at the same time.
Cheers,
-Len
Ps. Note that in 2.6 CONFIG_X86_HT exists and covers the sibling code.
It depends on CONFIG_SMP, and CONFIG_ACPI_HT_ONLY depends on it. (in the
ACPI patch)
Len,
I think you're missing Jeffs point.
He's really saying that the user want to select features. The user
doesn't really care how it is implemented. And there is no requirement
(I think) that some source files match one on one with a configuration
option.
As a user I like Jeffs proposal very much. It allows me to indicate what
I want without bothering about the implementation.
I think it would be wise to indicate in the help that HT does include
parts of ACPI.
As a programmer, I can understand your point too. But perhaps you should
do something like this (in the Makefile):
if CONFIG_HT
include part of ACPI needed for HT
endif
if CONFIG_ACPI
include all of acpi
endif
And let make fix things up.
-- Jan Evert
Brown, Len wrote:
>>Now that I've thought of it (aren't I humble), I rather like
>>CONFIG_HT.
>>It's simple and it's effects should be obvious to both developer and
>>user:
>>
>> CONFIG_HT, CONFIG_ACPI == ACPI
>> !CONFIG_HT, CONFIG_ACPI == ACPI
>> CONFIG_HT, !CONFIG_ACPI == HT-only ACPI
>> !CONFIG_HT, !CONFIG_ACPI == no ACPI
>>
>>Following the "autoconf model", what we really want to be testing with
>>CONFIG_xxx is _features_, where possible. "hyperthreading: yes/no" is
>>IMO more clear than "do I want ht-only ACPI or full ACPI",
>>while at the
>>same time being more fine-grained and future-proof.
>
>
> I like positive logic too.
> I went so far as to try to implement this back when I deleted "noht".
>
> The problem is that "!CONFIG_HT" is meaningless. It implies that
> you can have CONFIG_ACPI but still "config-out" HT, which you can't.
>
> Ie. The 2nd row above says to give me ACPI w/o HT.
> If you delete that row and reverse the polarity you get:
>
> !CONFIG_ACPI_HT_ONLY, CONFIG_ACPI == ACPI
> CONFIG_ACPI_HT_ONLY, !CONFIG_ACPI == HT-only ACPI
> !CONFIG_ACPI_HT_ONLY, !CONFIG_ACPI == no ACPI
>
> Here we can use config to emphasize that it is not possible to select
> CONFIG_ACPI and CONFIG_ACPI_HT_ONLY at the same time.
>
> Cheers,
> -Len
>
> Ps. Note that in 2.6 CONFIG_X86_HT exists and covers the sibling code.
> It depends on CONFIG_SMP, and CONFIG_ACPI_HT_ONLY depends on it. (in the
> ACPI patch)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I'm thinking now that 2.4.21 had right:
CONFIG_ACPI == ACPI
!CONFIG_ACPI == !ACPI
No special config option to include/exclude HT.
Internally, the table parsing code will be included if (CONFIG_SMP ||
CONFIG_ACPI) -- since that code doesn't even know about HT, it just
knows about parsing ACPI tables and enumerating processors etc. This
makes sense as this code is needed, for example, by an SMP system that
doesn't implement HT, and also by uni-processor ACPI-enabled systems.
Inventing an "HT-something" config option to describe this code was
probably a mistake.
So at the config option level, we'll be compatible with 2.4.21. Under
the covers we'll be different as 2.4.21 erroneously made acpitables
depend on the IOAPIC -- which didn't support HT on IO-APIC-less boxes
(eg the volume P4 desktops we see today).
thanks,
-Len
ps. Thanks for emphasizsing the "config selects a feature concept". I
really do agree. Indeed, I implemented it this summer, but I got hung
up on the fact that when I was done, in the CONFIG_ACPI case, CONFIG_HT
== !CONFIG_HT so I discarded that scheme.
> Len,
>
> I think you're missing Jeffs point.
> He's really saying that the user want to select features. The user
> doesn't really care how it is implemented. And there is no requirement
> (I think) that some source files match one on one with a configuration
> option.
>
> As a user I like Jeffs proposal very much. It allows me to indicate what
> I want without bothering about the implementation.
> I think it would be wise to indicate in the help that HT does include
> parts of ACPI.
>
> As a programmer, I can understand your point too. But perhaps you should
> do something like this (in the Makefile):
> if CONFIG_HT
> include part of ACPI needed for HT
> endif
> if CONFIG_ACPI
> include all of acpi
> endif
> And let make fix things up.
>
> -- Jan Evert
>
> Brown, Len wrote:
> >>Now that I've thought of it (aren't I humble), I rather like
> >>CONFIG_HT.
> >>It's simple and it's effects should be obvious to both developer and
> >>user:
> >>
> >> CONFIG_HT, CONFIG_ACPI == ACPI
> >> !CONFIG_HT, CONFIG_ACPI == ACPI
> >> CONFIG_HT, !CONFIG_ACPI == HT-only ACPI
> >> !CONFIG_HT, !CONFIG_ACPI == no ACPI
> >>
> >>Following the "autoconf model", what we really want to be testing with
> >>CONFIG_xxx is _features_, where possible. "hyperthreading: yes/no" is
> >>IMO more clear than "do I want ht-only ACPI or full ACPI",
> >>while at the
> >>same time being more fine-grained and future-proof.
> >
> >
> > I like positive logic too.
> > I went so far as to try to implement this back when I deleted "noht".
> >
> > The problem is that "!CONFIG_HT" is meaningless. It implies that
> > you can have CONFIG_ACPI but still "config-out" HT, which you can't.
> >
> > Ie. The 2nd row above says to give me ACPI w/o HT.
> > If you delete that row and reverse the polarity you get:
> >
> > !CONFIG_ACPI_HT_ONLY, CONFIG_ACPI == ACPI
> > CONFIG_ACPI_HT_ONLY, !CONFIG_ACPI == HT-only ACPI
> > !CONFIG_ACPI_HT_ONLY, !CONFIG_ACPI == no ACPI
> >
> > Here we can use config to emphasize that it is not possible to select
> > CONFIG_ACPI and CONFIG_ACPI_HT_ONLY at the same time.
> >
> > Cheers,
> > -Len
> >
> > Ps. Note that in 2.6 CONFIG_X86_HT exists and covers the sibling code.
> > It depends on CONFIG_SMP, and CONFIG_ACPI_HT_ONLY depends on it. (in the
> > ACPI patch)
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
On Thu, Sep 25, 2003 at 11:49:51PM -0400, Jeff Garzik wrote:
> On Thu, Sep 25, 2003 at 11:37:43PM -0400, Len Brown wrote:
> > > How about the more simple CONFIG_HYPERTHREAD or CONFIG_HT?
> > >
> > > If enabled and CONFIG_SMP is set, then we will attempt to discover HT
> > > via ACPI tables, regardless of CONFIG_ACPI value.
> >
> > Yes, except I think we should keep the name CONFIG_ACPI_HT_ONLY since it
> > says exactly what it does.
> >
> > Hopefully I can make it looke clear in the menus --
> > I think on the config menus for CONFIG_ACPI_HT_ONLY and CONFIG_ACPI
> > should be mutually exclusive.
>
> Now that I've thought of it (aren't I humble), I rather like CONFIG_HT.
> It's simple and it's effects should be obvious to both developer and
> user:
>
> CONFIG_HT, CONFIG_ACPI == ACPI
> !CONFIG_HT, CONFIG_ACPI == ACPI
> CONFIG_HT, !CONFIG_ACPI == HT-only ACPI
> !CONFIG_HT, !CONFIG_ACPI == no ACPI
what about making the CONFIG_HT disappear when
CONFIG_ACPI is selected?
by the way I would name it CONFIG_HT_ACPI ..
on the other hand, what do I know about that? ;)
so just take it as another opinion ...
best,
Herbert
> Following the "autoconf model", what we really want to be testing with
> CONFIG_xxx is _features_, where possible. "hyperthreading: yes/no" is
> IMO more clear than "do I want ht-only ACPI or full ACPI", while at the
> same time being more fine-grained and future-proof.
>
>
> > > Or... (I know multiple people will shoot me for saying this) we could
> > > resurrect acpitable.[ch], and build that when CONFIG_ACPI is disabled.
> >
> > The question about configs is independent of the acpitable.[ch] vs
> > table.c implementation. No, we should not return to maintaining two
> > copies of the acpi table code.
>
> Point; agreed.
>
> Jeff
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> > > Hmm, I happen to know of a system that fails to detect the
> > > sibling CPU(s) with CONFIG_ACPI_HT_ONLY set, whereas w/o it
> > > "all fine running's."
> > >
> > > Is this a bug?
> >
> > Yes, could you file it on bugzilla.org Power management/acpi?
>
> It seems 2.4.23-pre5 can't enable the sibling CPU even with
> full ACPI enabled on this system... .config attached,
> relevant parts of dmesg follow:
Forgot to attach the .config, sorry.
--
Tomas Szepe <[email protected]>
> > Hmm, I happen to know of a system that fails to detect the
> > sibling CPU(s) with CONFIG_ACPI_HT_ONLY set, whereas w/o it
> > "all fine running's."
> >
> > Is this a bug?
>
> Yes, could you file it on bugzilla.org Power management/acpi?
It seems 2.4.23-pre5 can't enable the sibling CPU even with
full ACPI enabled on this system... .config attached,
relevant parts of dmesg follow:
(The kernels I was talking about previously were 2.4.22-ac*.)
Compaq ProLiant ML350 G3 detected: force use of acpi=ht
ACPI: RSDP (v000 COMPAQ ) @ 0x000f4f70
ACPI: RSDT (v001 COMPAQ D14 0x00000002 ? 0x0000162e) @ 0x2fffa000
ACPI: FADT (v001 COMPAQ D14 0x00000002 ? 0x0000162e) @ 0x2fffa040
ACPI: MADT (v001 COMPAQ 00000083 0x00000002 ? 0x0000162e) @ 0x2fffa100
ACPI: SPCR (v001 COMPAQ SPCRRBSU 0x00000001 ? 0x0000162e) @ 0x2fffa1c0
ACPI: DSDT (v001 COMPAQ DSDT 0x00000001 MSFT 0x0100000b) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
Processor #6 Pentium 4(tm) XEON(tm) APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
Processor #7 Pentium 4(tm) XEON(tm) APIC version 20
ACPI: LAPIC_NMI (acpi_id[0xff] polarity[0x0] trigger[0x0] lint[0x1])
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: COMPAQ Product ID: PROLIANT APIC at: 0xFEE00000
I/O APIC #2 Version 17 at 0xFEC00000.
I/O APIC #3 Version 17 at 0xFEC01000.
I/O APIC #4 Version 17 at 0xFEC02000.
I/O APIC #5 Version 17 at 0xFEC03000.
Enabling APIC mode: Flat. Using 4 I/O APICs
Processors: 2
Kernel command line: root=/dev/md0 rw vga=normal
Initializing CPU#0
Detected 1993.588 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3971.48 BogoMIPS
Memory: 774560k/786408k available (1819k kernel code, 11460k reserved, 436k data, 288k init, 0k highmem)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: bfebfbff 00000000 00000000 00000000
CPU: Common caps: bfebfbff 00000000 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: bfebfbff 00000000 00000000 00000000
CPU: Common caps: bfebfbff 00000000 00000000 00000000
CPU0: Intel(R) Xeon(TM) CPU 2.00GHz stepping 07
per-CPU timeslice cutoff: 1462.63 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Error: only one processor found.
WARNING: No sibling found for CPU 0.
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
Setting 3 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 3 ... ok.
Setting 4 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 4 ... ok.
Setting 5 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 5 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 3-0, 3-1, 3-2, 3-3, 3-4, 3-5, 3-6, 3-7, 3-8, 3-9, 3-10, 3-11, 3-12, 3-13, 3-14, 3-15, 4-0, 4-1, 4-2, 4-3, 4-4, 4-5, 4-6, 4-7, 4-8, 4-9, 4-10, 4-11, 4-12, 4-13, 4-14, 4-15, 5-0, 5-1, 5-2, 5-3, 5-4, 5-5, 5-6, 5-7, 5-8, 5-9, 5-10, 5-11, 5-12, 5-13, 5-14, 5-15 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 16.
number of IO-APIC #3 registers: 16.
number of IO-APIC #4 registers: 16.
number of IO-APIC #5 registers: 16.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 000F0011
....... : max redirection entries: 000F
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 02000000
....... : arbitration: 02
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 1 1 0 1 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 001 01 1 1 0 1 0 1 1 51
06 001 01 0 0 0 0 0 1 1 59
07 001 01 0 0 0 0 0 1 1 61
08 001 01 0 0 0 0 0 1 1 69
09 001 01 1 1 0 1 0 1 1 71
0a 001 01 1 1 0 1 0 1 1 79
0b 001 01 1 1 0 1 0 1 1 81
0c 001 01 0 0 0 0 0 1 1 89
0d 001 01 0 0 0 0 0 1 1 91
0e 001 01 0 0 0 0 0 1 1 99
0f 001 01 0 0 0 0 0 1 1 A1
IO APIC #3......
.... register #00: 03000000
....... : physical APIC id: 03
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 000F0011
....... : max redirection entries: 000F
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 03000000
....... : arbitration: 03
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 000 00 1 0 0 0 0 0 0 00
07 000 00 1 0 0 0 0 0 0 00
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
IO APIC #4......
.... register #00: 04000000
....... : physical APIC id: 04
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 000F0011
....... : max redirection entries: 000F
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 04000000
....... : arbitration: 04
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 000 00 1 0 0 0 0 0 0 00
07 000 00 1 0 0 0 0 0 0 00
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
IO APIC #5......
.... register #00: 05000000
....... : physical APIC id: 05
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 000F0011
....... : max redirection entries: 000F
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 05000000
....... : arbitration: 05
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 000 00 1 0 0 0 0 0 0 00
07 000 00 1 0 0 0 0 0 0 00
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1993.4372 MHz.
..... host bus clock speed is 99.6718 MHz.
cpu: 0, clocks: 996718, slice: 498359
CPU0<T0:996704,T1:498336,D:9,S:498359,C:996718>
Waiting on wait_init_idle (map = 0x0)
All processors have done init_idle
ACPI: Subsystem revision 20030916
ACPI: Interpreter disabled.
PCI: PCI BIOS revision 2.10 entry at 0xf0094, last bus=5
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ACPI tables contain no PCI IRQ routing entries
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 00:0f.1
PCI: Device 00:00 not found by BIOS
PCI: Device 00:01 not found by BIOS
PCI: Device 00:02 not found by BIOS
PCI: Device 00:78 not found by BIOS
PCI: Device 00:7b not found by BIOS
PCI: Device 00:88 not found by BIOS
PCI: Device 00:8a not found by BIOS
Linux NET4.0 for Linux 2.4
...
--
Tomas Szepe <[email protected]>
> CONFIG_NR_CPUS=4
See if cranking this up to 8 helps.
It looks like your BIOS defines empty processor slots
as processors that are present but disabled.
if this doesn't do it, please drop the output from
from dmidecode and acpidmp in a bugzilla and point me to it.
thanks,
-Len
On Sun, 2003-09-28 at 06:46, Tomas Szepe wrote:
> > > > Hmm, I happen to know of a system that fails to detect the
> > > > sibling CPU(s) with CONFIG_ACPI_HT_ONLY set, whereas w/o it
> > > > "all fine running's."
> > > >
> > > > Is this a bug?
> > >
> > > Yes, could you file it on bugzilla.org Power management/acpi?
> >
> > It seems 2.4.23-pre5 can't enable the sibling CPU even with
> > full ACPI enabled on this system... .config attached,
> > relevant parts of dmesg follow:
>
> Forgot to attach the .config, sorry.
> [[email protected]]
>
> > CONFIG_NR_CPUS=4
>
> See if cranking this up to 8 helps.
> It looks like your BIOS defines empty processor slots
> as processors that are present but disabled.
>
> if this doesn't do it, please drop the output from
> from dmidecode and acpidmp in a bugzilla and point me to it.
Indeed, raising CONFIG_NR_CPUS to 8 solved the problem
even for the CONFIG_ACPI_HT_ONLY case (which wouldn't
work in 2.4.22-ac*).
Do you need any more info on this system or will this do?
--
Tomas Szepe <[email protected]>
> Marcelo wrote:
> CONFIG_ACPI_HT should be not dependant on CONFIG_ACPI
FYI,
This fix has been integrated with others in the ACPI patch,
and is available for test now in these bitkeeper trees:
http://linux-acpi.bkbits.net/linux-acpi-test-2.4.22
http://linux-acpi.bkbits.net/linux-acpi-test-2.4.23
http://linux-acpi.bkbits.net/linux-acpi-test-2.6.0
It is also available as a plain patch "CONFIG_ACPI" here:
ftp.kernel.org:/pub/linux/kernel/people/lenb/acpi/patches/test/*