Hyper-threaded pickle

Hyper-threaded pickle

[Jeff Garzik]

So,

Just now getting my dual athlon going under 2.6.x.  It _really_ doesn't 
like ACPI.

ACPI specifications dictate some hardware characteristics, as well as 
specifying table structures and such.  One of those characteristics is 
the 4-second poweroff:  if you hold down the power button for 4-5 
seconds, your motherboard is required to poweroff the machine.  This is 
supposed to be a hard poweroff, and on most machines this works even 
when various pieces of hardware are frozen/locked-up.

Turning on ACPI kills my 4-second poweroff, which is pretty darn 
impressive.  So I proceed to disable ACPI...  but CONFIG_ACPI_BOOT 
doesn't want to disable.  I am trying to restore my working, non-ACPI 
configuration under 2.6, but this seems to be preventing me from doing so:

drivers/acpi/Kconfig:
config ACPI_BOOT
         bool
         depends on ACPI || X86_HT
         default y

arch/i386/Kconfig:
config X86_HT
         bool
         depends on SMP && !(X86_VISWS || X86_VOYAGER)
         default y

My dual athlon _definitely_ doesn't have hyperthreading, and I am 
willing to bet that force-enabling the ACPI boot and HT code for all SMP 
machines breaks other older-SMP boxes as well.

	Jeff

Re: Hyper-threaded pickle

[Len Brown]

Re: old systems -- we use dmi_scan to disable ACPI on systems by default
on systems older than 1/1/2001.

Re: opteron & !HT.  Andi showed me a patch today that disables X86_HT if
you build specifically for an AMD CPU that doesn't support HT.  This
looks like a good idea, and possibly should be expanded.

Re: your power button
I can't explain the 4-second over-ride not working, is this prototype
hardware?  In any case, I'll be happy to work with you to figure out why
ACPI isn't working properly on this box -- a bug report with the details
would be the way to go.  Note that if poweroff works in uni-processor
mode but not in SMP mode, you'll want the latest patch here:
http://bugzilla.kernel.org/show_bug.cgi?id=1141

thanks,
-Len

On Thu, 2004-03-04 at 23:52, Jeff Garzik wrote:
> So,
> 
> Just now getting my dual athlon going under 2.6.x.  It _really_ doesn't 
> like ACPI.
> 
> ACPI specifications dictate some hardware characteristics, as well as 
> specifying table structures and such.  One of those characteristics is 
> the 4-second poweroff:  if you hold down the power button for 4-5 
> seconds, your motherboard is required to poweroff the machine.  This is 
> supposed to be a hard poweroff, and on most machines this works even 
> when various pieces of hardware are frozen/locked-up.
> 
> Turning on ACPI kills my 4-second poweroff, which is pretty darn 
> impressive.  So I proceed to disable ACPI...  but CONFIG_ACPI_BOOT 
> doesn't want to disable.  I am trying to restore my working, non-ACPI 
> configuration under 2.6, but this seems to be preventing me from doing so:
> 
> drivers/acpi/Kconfig:
> config ACPI_BOOT
>          bool
>          depends on ACPI || X86_HT
>          default y
> 
> arch/i386/Kconfig:
> config X86_HT
>          bool
>          depends on SMP && !(X86_VISWS || X86_VOYAGER)
>          default y
> 
> My dual athlon _definitely_ doesn't have hyperthreading, and I am 
> willing to bet that force-enabling the ACPI boot and HT code for all SMP 
> machines breaks other older-SMP boxes as well.
> 
> 	Jeff
> 
> 
> 
> 

Re: Hyper-threaded pickle

[Jeff Garzik]

Len Brown wrote:
> Re: old systems -- we use dmi_scan to disable ACPI on systems by default
> on systems older than 1/1/2001.

What happens for the no-DMI case?


> Re: opteron & !HT.  Andi showed me a patch today that disables X86_HT if
> you build specifically for an AMD CPU that doesn't support HT.  This
> looks like a good idea, and possibly should be expanded.

Cool.

My main worry/concern is breaking older systems, due to this change in 
behavior.

An easy first step is to make CONFIG_X86_HT selectable again.

	Jeff

Re: Hyper-threaded pickle

[Len Brown]

> > Re: old systems -- we use dmi_scan to disable ACPI on systems by default
> > on systems older than 1/1/2001.
> 
> What happens for the no-DMI case?

When DMI is not present, dmi_scan is a no-op -- so ACPI will run in
whatever default the system is set to -- eg. "off" for FC1, and "on" for
FC2-test1.

We've found in practice that dmi_scan has been pretty effective at
identifying the set of systems new enough to have an ACPI enabled BIOS
but old enough that the ACPI implementation is hopeless.  Though we've
had many reports of 1/1/2001 being a bit *too* conservative -- disabling
ACPI on systems where ACPI works fine.  Indeed, there is a bugzilla
requesting a "white-list" to enable exceptions to this date.  I'm not
enthusiastic about that plan, however.  I figure there are more 3-year
old boxes that have been running Linux w/o ACPI than there are those
which have; and I'd rather spend my ergs on the current and upcoming
boxes where vendors are more willing to update a broken BIOS...

> > Re: opteron & !HT.  Andi showed me a patch today that disables X86_HT if
> > you build specifically for an AMD CPU that doesn't support HT.  This
> > looks like a good idea, and possibly should be expanded.
> 
> Cool.
> 
> My main worry/concern is breaking older systems, due to this change in 
> behavior.

2.4 and SuSE have deployed this way for some time.  The HT part of ACPI
was in RHL 8.0 and 9.0 by default as well -- and this is consistent with
that.

> An easy first step is to make CONFIG_X86_HT selectable again.

That wouldn't help the most importaht case though -- the distro who
wants the same kernel binary to run on a broad variety of platforms.

-Len

Re: Hyper-threaded pickle

[Bill Davidsen]

Len Brown wrote:
>>>Re: old systems -- we use dmi_scan to disable ACPI on systems by default
>>>on systems older than 1/1/2001.
>>
>>What happens for the no-DMI case?
> 
> 
> When DMI is not present, dmi_scan is a no-op -- so ACPI will run in
> whatever default the system is set to -- eg. "off" for FC1, and "on" for
> FC2-test1.
> 
> We've found in practice that dmi_scan has been pretty effective at
> identifying the set of systems new enough to have an ACPI enabled BIOS
> but old enough that the ACPI implementation is hopeless.  Though we've
> had many reports of 1/1/2001 being a bit *too* conservative -- disabling
> ACPI on systems where ACPI works fine.  Indeed, there is a bugzilla
> requesting a "white-list" to enable exceptions to this date.  I'm not
> enthusiastic about that plan, however.  I figure there are more 3-year
> old boxes that have been running Linux w/o ACPI than there are those
> which have; and I'd rather spend my ergs on the current and upcoming
> boxes where vendors are more willing to update a broken BIOS...

Even though I have some boxes which are hurt by this, I have to agree, 
although I wouldn't be unhappy if there were a few more options to 
enable just parts of ACPI. There are more important things, however, and 
since I can live with ACPI=force or no acpi at all it's an annoyance 
rather than an issue.

I have a few machines which are never going to 2.6 because their ACPI is 
totally broken and 2.6 APC no longer functions to turn the machine off. 
Since I expect 2.4 to be viable longer than the machines, I have no 
issues with that, either. If I don't have time to look at it why should 
I ask anyone else?

Re: Hyper-threaded pickle

[Andi Kleen]

Len Brown <len.brown@intel.com> writes:

>> > Re: old systems -- we use dmi_scan to disable ACPI on systems by default
>> > on systems older than 1/1/2001.
>> 
>> What happens for the no-DMI case?
>
> When DMI is not present, dmi_scan is a no-op -- so ACPI will run in

A box without DMI likely also doesn't have ACPI tables. I believe DMI
is older than ACPI.

-Andi