Re: HT CPU handling - 2.6.2

Re: HT CPU handling - 2.6.2

[Len Brown]

Your BIOS is reporting the 2nd CPU as disabled, and telling us that it
has LAPIC id 0x81 = 129.  The ACPI table code prints this out and
registers the processor anyway, but that chokes because the LAPIC ID is
way out of bounds.

I'm thinking that ACPI should not register a processor that the BIOS
marked as disabled...

What should you do?  Apparently you've got an HT-enabled platform, BIOS,
and OS, but do not have an HT-enabled processor.  Your choices are to
disable HT in the BIOS SETUP to clean up this message, or plug in an
HT-enabled processor.

cheers,
-Len

On Mon, 2004-02-09 at 15:44, Hod McWuff wrote:
> I've got a 2.0A GHz P4, advertised as non-hyperthread, that seems to
> be
> reporting the presence of a second CPU. It also seems to be disabled
> by
> setting bit 7 of its ID. I've tried compiling with support for 130
> CPU's
> and nothing changed. What would have to be done to get this disabled
> CPU half back online?
> 
> Feb  9 04:45:03 pug ACPI: Local APIC address 0xfee00000
> Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Feb  9 04:45:03 pug Processor #0 15:2 APIC version 20
> Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81]
> disabled)
> Feb  9 04:45:03 pug Processor #129 invalid (max 16)
> Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> 
> -
> 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/
> 
> 

Re: HT CPU handling - 2.6.2

[Hod McWuff]

OK, the BIOS setting is disabled and cannot be changed, so the message
won't get cleaned up that way. I could of course disable SMP in my
kernel, but that really doesn't address anything.

What I'm wondering is, if the second "CPU" appears to exist but is
merely marked disabled, who cares about the BIOS flag? Why couldn't the
disable flag be cleared or ignored?

Couldn't the ACPI/APIC/SMP code just cope with the odd LAPIC ID somehow?

On Tue, 2004-02-10 at 00:37, Len Brown wrote:
> Your BIOS is reporting the 2nd CPU as disabled, and telling us that it
> has LAPIC id 0x81 = 129.  The ACPI table code prints this out and
> registers the processor anyway, but that chokes because the LAPIC ID is
> way out of bounds.
> 
> I'm thinking that ACPI should not register a processor that the BIOS
> marked as disabled...
> 
> What should you do?  Apparently you've got an HT-enabled platform, BIOS,
> and OS, but do not have an HT-enabled processor.  Your choices are to
> disable HT in the BIOS SETUP to clean up this message, or plug in an
> HT-enabled processor.
> 
> cheers,
> -Len
> 
> On Mon, 2004-02-09 at 15:44, Hod McWuff wrote:
> > I've got a 2.0A GHz P4, advertised as non-hyperthread, that seems to
> > be
> > reporting the presence of a second CPU. It also seems to be disabled
> > by
> > setting bit 7 of its ID. I've tried compiling with support for 130
> > CPU's
> > and nothing changed. What would have to be done to get this disabled
> > CPU half back online?
> > 
> > Feb  9 04:45:03 pug ACPI: Local APIC address 0xfee00000
> > Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> > Feb  9 04:45:03 pug Processor #0 15:2 APIC version 20
> > Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81]
> > disabled)
> > Feb  9 04:45:03 pug Processor #129 invalid (max 16)
> > Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> > Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> > 
> > -
> > 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/
> > 
> > 
> 
> -
> 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/

Re: HT CPU handling - 2.6.2

[Len Brown]

no.  the disabled flag is a reflection of wires inside the processor. 
You could pop the cap and ion-beam edit the die, or buy an HT-enabled
processor.  The later would be somewhat more cost effective;-)

cheers,
-Len

On Tue, 2004-02-10 at 01:47, Hod McWuff wrote:
> OK, the BIOS setting is disabled and cannot be changed, so the message
> won't get cleaned up that way. I could of course disable SMP in my
> kernel, but that really doesn't address anything.
> 
> What I'm wondering is, if the second "CPU" appears to exist but is
> merely marked disabled, who cares about the BIOS flag? Why couldn't the
> disable flag be cleared or ignored?
> 
> Couldn't the ACPI/APIC/SMP code just cope with the odd LAPIC ID somehow?
> 
> On Tue, 2004-02-10 at 00:37, Len Brown wrote:
> > Your BIOS is reporting the 2nd CPU as disabled, and telling us that it
> > has LAPIC id 0x81 = 129.  The ACPI table code prints this out and
> > registers the processor anyway, but that chokes because the LAPIC ID is
> > way out of bounds.
> > 
> > I'm thinking that ACPI should not register a processor that the BIOS
> > marked as disabled...
> > 
> > What should you do?  Apparently you've got an HT-enabled platform, BIOS,
> > and OS, but do not have an HT-enabled processor.  Your choices are to
> > disable HT in the BIOS SETUP to clean up this message, or plug in an
> > HT-enabled processor.
> > 
> > cheers,
> > -Len
> > 
> > On Mon, 2004-02-09 at 15:44, Hod McWuff wrote:
> > > I've got a 2.0A GHz P4, advertised as non-hyperthread, that seems to
> > > be
> > > reporting the presence of a second CPU. It also seems to be disabled
> > > by
> > > setting bit 7 of its ID. I've tried compiling with support for 130
> > > CPU's
> > > and nothing changed. What would have to be done to get this disabled
> > > CPU half back online?
> > > 
> > > Feb  9 04:45:03 pug ACPI: Local APIC address 0xfee00000
> > > Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> > > Feb  9 04:45:03 pug Processor #0 15:2 APIC version 20
> > > Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81]
> > > disabled)
> > > Feb  9 04:45:03 pug Processor #129 invalid (max 16)
> > > Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> > > Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> > > 
> > > -
> > > 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/
> > > 
> > > 
> > 
> > -
> > 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/

Re: HT CPU handling - 2.6.2

[Hod McWuff]

OK then the heck with the flag... am I to understand that there is in
fact a partial CPU on the die? (LAPIC but no other logic?) Or is the
second CPU instance there and real but administratively disabled?

You've been very helpful Mr. Brown but I fear you might be under orders
to tell me the party line. I want to know, regardless of disabled flags
and burnt wires, what if any vestige of a second CPU exists on that
particular piece of silicon in my other room.

On Tue, 2004-02-10 at 02:23, Len Brown wrote:
> no.  the disabled flag is a reflection of wires inside the processor. 
> You could pop the cap and ion-beam edit the die, or buy an HT-enabled
> processor.  The later would be somewhat more cost effective;-)
> 
> cheers,
> -Len
> 
> On Tue, 2004-02-10 at 01:47, Hod McWuff wrote:
> > OK, the BIOS setting is disabled and cannot be changed, so the message
> > won't get cleaned up that way. I could of course disable SMP in my
> > kernel, but that really doesn't address anything.
> > 
> > What I'm wondering is, if the second "CPU" appears to exist but is
> > merely marked disabled, who cares about the BIOS flag? Why couldn't the
> > disable flag be cleared or ignored?
> > 
> > Couldn't the ACPI/APIC/SMP code just cope with the odd LAPIC ID somehow?
> > 
> > On Tue, 2004-02-10 at 00:37, Len Brown wrote:
> > > Your BIOS is reporting the 2nd CPU as disabled, and telling us that it
> > > has LAPIC id 0x81 = 129.  The ACPI table code prints this out and
> > > registers the processor anyway, but that chokes because the LAPIC ID is
> > > way out of bounds.
> > > 
> > > I'm thinking that ACPI should not register a processor that the BIOS
> > > marked as disabled...
> > > 
> > > What should you do?  Apparently you've got an HT-enabled platform, BIOS,
> > > and OS, but do not have an HT-enabled processor.  Your choices are to
> > > disable HT in the BIOS SETUP to clean up this message, or plug in an
> > > HT-enabled processor.
> > > 
> > > cheers,
> > > -Len
> > > 
> > > On Mon, 2004-02-09 at 15:44, Hod McWuff wrote:
> > > > I've got a 2.0A GHz P4, advertised as non-hyperthread, that seems to
> > > > be
> > > > reporting the presence of a second CPU. It also seems to be disabled
> > > > by
> > > > setting bit 7 of its ID. I've tried compiling with support for 130
> > > > CPU's
> > > > and nothing changed. What would have to be done to get this disabled
> > > > CPU half back online?
> > > > 
> > > > Feb  9 04:45:03 pug ACPI: Local APIC address 0xfee00000
> > > > Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> > > > Feb  9 04:45:03 pug Processor #0 15:2 APIC version 20
> > > > Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81]
> > > > disabled)
> > > > Feb  9 04:45:03 pug Processor #129 invalid (max 16)
> > > > Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> > > > Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> > > > 
> > > > -
> > > > 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/
> > > > 
> > > > 
> > > 
> > > -
> > > 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/
> 
> -
> 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/

Re: HT CPU handling - 2.6.2

[Pavel Machek]

Hi!

> OK then the heck with the flag... am I to understand that there is in
> fact a partial CPU on the die? (LAPIC but no other logic?) Or is the
> second CPU instance there and real but administratively disabled?
> 

If I read it correctly, you have two logical CPUs there,
but one of them is administratively disabled. You can't enable
it without some serious tools.

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: HT CPU handling - 2.6.2

[Bill Davidsen]

Hod McWuff wrote:
> I've got a 2.0A GHz P4, advertised as non-hyperthread, that seems to be
> reporting the presence of a second CPU. It also seems to be disabled by
> setting bit 7 of its ID. I've tried compiling with support for 130 CPU's
> and nothing changed. What would have to be done to get this disabled
> CPU half back online?
> 
> Feb  9 04:45:03 pug ACPI: Local APIC address 0xfee00000
> Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Feb  9 04:45:03 pug Processor #0 15:2 APIC version 20
> Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
> Feb  9 04:45:03 pug Processor #129 invalid (max 16)
> Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])

Look in /proc/cpuinfo for number of siblings. If it's one you have no HT 
capability, the stuff for HT is mostly there but there's no sib to 
share. Sort of like a Siamese twin who's an only child or some such. You 
have a funky APIC and not much else.

Don't know if the LAPIC is actually useful.
-- 
Bill Davidsen, TMR

RE: HT CPU handling - 2.6.2

[Brown, Len]

> what if any vestige of a second CPU exists on that
> particular piece of silicon in my other room.
 
The presentations hanging off this page can explain it better than I
can:
http://www.intel.com/technology/hyperthread/index.htm?iid=sr+hyper&

Note that different model processors can implement different degrees of
sharing vs. duplication for different cost/performance.  Linux treats
them all as regular multi-processors with just some fine tuning for
scheduling logical processors vs physical packages.

Cheers,
-Len

Re: HT CPU handling - 2.6.2

[Athol Mullen]

Len Brown <len.brown@intel.com> wrote:
> Your BIOS is reporting the 2nd CPU as disabled, and telling us that it
> has LAPIC id 0x81 = 129.  The ACPI table code prints this out and
> registers the processor anyway, but that chokes because the LAPIC ID is
> way out of bounds.

IIRC, This is what happens with any P4 that sets the HT flag but only
has one logical CPU.  Completely within Intel specs.  I spent several
days struggling with this months ago when I thought that the 2.4GHz P4
I've got was HT capable.  Then I RTFM...

BTW, IIRC, the BIOS of my machine shows "Local APIC Support" instead of
"Hyperthreading Support" if the CPU installed isn't really HT capable.

> I'm thinking that ACPI should not register a processor that the BIOS
> marked as disabled...

The processor counter should find "logical processors present" is one
and ignore the hardware disabled 2nd logical CPU.

> What should you do?  Apparently you've got an HT-enabled platform, BIOS,
> and OS, but do not have an HT-enabled processor.  Your choices are to
> disable HT in the BIOS SETUP to clean up this message, or plug in an
> HT-enabled processor.

Better still, enable Local APIC but not SMP or HT when you build a
kernel.  That way, you get Local APIC support without SMP kernel.

-- 
Athol
<http://cust.idl.com.au/athol>
Linux Registered User # 254000
I'm a Libran Engineer. I don't argue, I discuss.

HT CPU handling - 2.6.2

[Hod McWuff]

I've got a 2.0A GHz P4, advertised as non-hyperthread, that seems to be
reporting the presence of a second CPU. It also seems to be disabled by
setting bit 7 of its ID. I've tried compiling with support for 130 CPU's
and nothing changed. What would have to be done to get this disabled
CPU half back online?

Feb  9 04:45:03 pug ACPI: Local APIC address 0xfee00000
Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Feb  9 04:45:03 pug Processor #0 15:2 APIC version 20
Feb  9 04:45:03 pug ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
Feb  9 04:45:03 pug Processor #129 invalid (max 16)
Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
Feb  9 04:45:03 pug ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])