[patch 7/7] acpi: remove old blacklist entries

[patch 7/7] acpi: remove old blacklist entries

[akpm]

From: Matthew Garrett <mjg59@srcf.ucam.org>

The kernel has a set of blacklist entries that disable ACPI functionality
on various machines.  These all seem to date from pre-git days and most
have no indication of what they were meant to fix.  Let's work on the
assumption that we've fixed whatever it was that was broken before and so
remove most of the entries.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Dmitry Artamonow <mad_soft@inbox.ru>
Cc: <flinco@libero.it>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Arkadiusz Miskiewicz <arekm@maven.pl>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/x86/kernel/acpi/boot.c |  147 ----------------------------------
 1 file changed, 147 deletions(-)

diff -puN arch/x86/kernel/acpi/boot.c~acpi-remove-old-blacklist-entries arch/x86/kernel/acpi/boot.c
--- a/arch/x86/kernel/acpi/boot.c~acpi-remove-old-blacklist-entries
+++ a/arch/x86/kernel/acpi/boot.c
@@ -1256,35 +1256,6 @@ static int __init disable_acpi_pci(const
 	return 0;
 }
 
-static int __init dmi_disable_acpi(const struct dmi_system_id *d)
-{
-	if (!acpi_force) {
-		printk(KERN_NOTICE "%s detected: acpi off\n", d->ident);
-		disable_acpi();
-	} else {
-		printk(KERN_NOTICE
-		       "Warning: DMI blacklist says broken, but acpi forced\n");
-	}
-	return 0;
-}
-
-/*
- * Limit ACPI to CPU enumeration for HT
- */
-static int __init force_acpi_ht(const struct dmi_system_id *d)
-{
-	if (!acpi_force) {
-		printk(KERN_NOTICE "%s detected: force use of acpi=ht\n",
-		       d->ident);
-		disable_acpi();
-		acpi_ht = 1;
-	} else {
-		printk(KERN_NOTICE
-		       "Warning: acpi=force overrules DMI blacklist: acpi=ht\n");
-	}
-	return 0;
-}
-
 /*
  * Force ignoring BIOS IRQ0 pin2 override
  */
@@ -1308,116 +1279,6 @@ static int __init dmi_ignore_irq0_timer_
  * works for you, please contact linux-acpi@vger.kernel.org
  */
 static struct dmi_system_id __initdata acpi_dmi_table[] = {
-	/*
-	 * Boxes that need ACPI disabled
-	 */
-	{
-	 .callback = dmi_disable_acpi,
-	 .ident = "IBM Thinkpad",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_BOARD_NAME, "2629H1G"),
-		     },
-	 },
-
-	/*
-	 * Boxes that need acpi=ht
-	 */
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "FSC Primergy T850",
-	 .matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "PRIMERGY T850"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "HP VISUALIZE NT Workstation",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "HP VISUALIZE NT Workstation"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "Compaq Workstation W8000",
-	 .matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Compaq"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Workstation W8000"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "ASUS P2B-DS",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
-		     DMI_MATCH(DMI_BOARD_NAME, "P2B-DS"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "ASUS CUR-DLS",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
-		     DMI_MATCH(DMI_BOARD_NAME, "CUR-DLS"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "ABIT i440BX-W83977",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ABIT <http://www.abit.com>"),
-		     DMI_MATCH(DMI_BOARD_NAME, "i440BX-W83977 (BP6)"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM Bladecenter",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_BOARD_NAME, "IBM eServer BladeCenter HS20"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM eServer xSeries 360",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_BOARD_NAME, "eServer xSeries 360"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM eserver xSeries 330",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_BOARD_NAME, "eserver xSeries 330"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM eserver xSeries 440",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "eserver xSeries 440"),
-		     },
-	 },
-
-	/*
-	 * Boxes that need ACPI PCI IRQ routing disabled
-	 */
-	{
-	 .callback = disable_acpi_irq,
-	 .ident = "ASUS A7V",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC"),
-		     DMI_MATCH(DMI_BOARD_NAME, "<A7V>"),
-		     /* newer BIOS, Revision 1011, does work */
-		     DMI_MATCH(DMI_BIOS_VERSION,
-			       "ASUS A7V ACPI BIOS Revision 1007"),
-		     },
-	 },
 	{
 		/*
 		 * Latest BIOS for IBM 600E (1.16) has bad pcinum
@@ -1454,14 +1315,6 @@ static struct dmi_system_id __initdata a
 		     DMI_MATCH(DMI_BIOS_DATE, "03/21/2003")
 		     },
 	 },
-	{
-	 .callback = disable_acpi_pci,
-	 .ident = "Acer TravelMate 36x Laptop",
-	 .matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
-		     },
-	 },
 	{}
 };
 
_

Re: [patch 7/7] acpi: remove old blacklist entries

[Henrique de Moraes Holschuh]

On Tue, 02 Feb 2010, akpm@linux-foundation.org wrote:
> -	/*
> -	 * Boxes that need ACPI disabled
> -	 */
> -	{
> -	 .callback = dmi_disable_acpi,
> -	 .ident = "IBM Thinkpad",
> -	 .matches = {
> -		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
> -		     DMI_MATCH(DMI_BOARD_NAME, "2629H1G"),
> -		     },
> -	 },

The 2629H1G is just one of various models of the ThinkPad A21p, if one
wanted to blacklist the 2629H1G, he should have blacklisted bios_version
KY??HT*, instead, which would get all models with that BIOS (includes the
A22p models as well).

Those thinkpads had Win98 support, and probably worked better in Linux using
APM than ACPI.  That might still be true, but we'd need to find someone with
an A21p or A22p to ask.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [patch 7/7] acpi: remove old blacklist entries

[Len Brown]

applied to acpi-test

thanks,
Len Brown, Intel Open Source Technology Center

Re: [patch 7/7] acpi: remove old blacklist entries

[Len Brown]

> applied to acpi-test

un-applied.

Even if deleting the blacklist entries were correct,
which it more or less may be, the bug at hand is that
"acpi=ht" is now broken -- whether invoked via DMI
or cmdline; and this patch doesn't fix that.

Len Brown, Intel Open Source Technology Center

Re: [patch 7/7] acpi: remove old blacklist entries

[Matthew Garrett]

On Tue, Feb 16, 2010 at 03:19:43AM -0500, Len Brown wrote:
> > applied to acpi-test
> 
> un-applied.
> 
> Even if deleting the blacklist entries were correct,
> which it more or less may be, the bug at hand is that
> "acpi=ht" is now broken -- whether invoked via DMI
> or cmdline; and this patch doesn't fix that.

Indeed it doesn't. But the report also noted that the system worked fine 
with acpi=force, so this is something that we should clean up regardless 
of the original bug.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch 7/7] acpi: remove old blacklist entries

[Len Brown]

> > un-applied.
> > 
> > Even if deleting the blacklist entries were correct,
> > which it more or less may be, the bug at hand is that
> > "acpi=ht" is now broken -- whether invoked via DMI
> > or cmdline; and this patch doesn't fix that.
> 
> Indeed it doesn't. But the report also noted that the system worked fine 
> with acpi=force, so this is something that we should clean up regardless 
> of the original bug.

I fixed the acpi=ht option, and also removed the
system at hand from the blacklist.  This is what
2.6.33 and 2.6.32.stable need.

In the future, I'll consider deleting the "acpi=ht"
option all together, and the blacklist with it,
but such changes are always harder than expected.

On a related topic, we should probably consider bringing
back the "noht" option.  However we would do so by
checking the APIC-id topology rather than assuming
any consistency in how the BIOS enumerates the processors.

thanks,
-Len Brown, Intel Open Source Technology Center

Re: [patch 7/7] acpi: remove old blacklist entries

[Matthew Garrett]

On Tue, Feb 16, 2010 at 09:49:03PM -0500, Len Brown wrote:

> In the future, I'll consider deleting the "acpi=ht"
> option all together, and the blacklist with it,
> but such changes are always harder than expected.

We seem to have no good history of where these blacklist entries came 
from, and we know that at least one of them is actively harmful. Perhaps 
replace them with a debug statement on affected machines telling people 
what they need to pass to restore the blacklist behaviour, and to let us 
know if it's necessary?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch 7/7] acpi: remove old blacklist entries

[Len Brown]

On Wed, 17 Feb 2010, Matthew Garrett wrote:

> On Tue, Feb 16, 2010 at 09:49:03PM -0500, Len Brown wrote:
> 
> > In the future, I'll consider deleting the "acpi=ht"
> > option all together, and the blacklist with it,
> > but such changes are always harder than expected.
> 
> We seem to have no good history of where these blacklist entries came 
> from, and we know that at least one of them is actively harmful. Perhaps 
> replace them with a debug statement on affected machines telling people 
> what they need to pass to restore the blacklist behaviour, and to let us 
> know if it's necessary?

Actually, it wasn't actively harmful until we broke "acpi=ht".
Indeed, it was actively helpful in pointing out that regression:-)

Yes, I think that a warning for a release or so before deleting
some of these entries would make sense -- good idea.

Re: history...
unfortunately old-2.6-bkcvs history is nearly useless,
but bkbits still seems to work.

It shows I pulled this DMI list from Linux-2.4 to Linux-2.6
on 2003-08-09, and that it originally came from Suse:

"pull DMI blacklist from UnitedLinux via 2.4 for disabling ACPI on bad 
BIOS boxes.  This also sets ACPI_BLACKLIST_CUTOFF_YEAR = 2001"

http://linux.bkbits.net:8080/linux-2.6.11-stable/arch/i386/kernel/dmi_scan.c?PAGE=diffs&REV=3f35b565a8XFxBnmR2yf-97PQRqW3Q

I think that move was a short term good idea,
but a long term bad idea.

It looks like we have added no forc_acpi_ht entries since 2003,
but we have deleted a bunch of them.  So it may indeed be time
for the force_acpi_ht, and perhaps the "acpi=ht" option to go.

The other entries in today's acpi_dmi_table[] are less clear
and should probably be modified only with some care...

I'll spin a patch for the acpi=ht part.

thanks,
-Len Brown, Intel Open Source Technology Center

Re: [patch 7/7] acpi: remove old blacklist entries

[Matthew Garrett]

On Wed, Feb 17, 2010 at 01:24:58PM -0500, Len Brown wrote:
> On Wed, 17 Feb 2010, Matthew Garrett wrote:
> > We seem to have no good history of where these blacklist entries came 
> > from, and we know that at least one of them is actively harmful. Perhaps 
> > replace them with a debug statement on affected machines telling people 
> > what they need to pass to restore the blacklist behaviour, and to let us 
> > know if it's necessary?
> 
> Actually, it wasn't actively harmful until we broke "acpi=ht".
> Indeed, it was actively helpful in pointing out that regression:-)

The machines in question are falling back to apm, so probably losing 
some level of powersaving support. I'd say that's harmful :)

> The other entries in today's acpi_dmi_table[] are less clear
> and should probably be modified only with some care...

At least one of them covers a single submodel in a range, despite them 
all running the same BIOS. I'd really lean towards them being bogus at 
this stage of the game.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch 7/7] acpi: remove old blacklist entries

[Henrique de Moraes Holschuh]

On Wed, 17 Feb 2010, Matthew Garrett wrote:
> On Wed, Feb 17, 2010 at 01:24:58PM -0500, Len Brown wrote:
> > On Wed, 17 Feb 2010, Matthew Garrett wrote:
> > > We seem to have no good history of where these blacklist entries came 
> > > from, and we know that at least one of them is actively harmful. Perhaps 
> > > replace them with a debug statement on affected machines telling people 
> > > what they need to pass to restore the blacklist behaviour, and to let us 
> > > know if it's necessary?
> > 
> > Actually, it wasn't actively harmful until we broke "acpi=ht".
> > Indeed, it was actively helpful in pointing out that regression:-)
> 
> The machines in question are falling back to apm, so probably losing 
> some level of powersaving support. I'd say that's harmful :)

Well, on ThinkPads you probably want APM on the older models, for better
power savings and less surprise when trying to suspend to RAM or to disk.

> > The other entries in today's acpi_dmi_table[] are less clear
> > and should probably be modified only with some care...
> 
> At least one of them covers a single submodel in a range, despite them 
> all running the same BIOS. I'd really lean towards them being bogus at 
> this stage of the game.

On that, we do agree.  That ThinkPad entry is completely bogus, I vote that
we remove it if we're not going to fix it to apply to every ThinkPad with
that BIOS.

OTOH, every mention of the A22 I find in the network is coupled with
"acpi=off", which matches what I know about the ThinkPads before the A31p,
X31 and R40e/T40: they tend to work a lot better in APM mode.

There are reports of some bizarre stuff, such as A22m laptops powering up by
themselves some time after shutdown if ACPI is used, etc.  I would suggest
an ACPI cut-off date of 2005 (disable ACPI on anything older than 2005) for
IBM ThinkPads, but this is going to shut down ACPI from people that never
updated their firmware on some models that might be able to do ACPI
properly.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [patch 7/7] acpi: remove old blacklist entries

[Len Brown]

On Wed, 17 Feb 2010, Matthew Garrett wrote:

> On Wed, Feb 17, 2010 at 01:24:58PM -0500, Len Brown wrote:
> > On Wed, 17 Feb 2010, Matthew Garrett wrote:
> > > We seem to have no good history of where these blacklist entries came 
> > > from, and we know that at least one of them is actively harmful. Perhaps 
> > > replace them with a debug statement on affected machines telling people 
> > > what they need to pass to restore the blacklist behaviour, and to let us 
> > > know if it's necessary?
> > 
> > Actually, it wasn't actively harmful until we broke "acpi=ht".
> > Indeed, it was actively helpful in pointing out that regression:-)
> 
> The machines in question are falling back to apm, so probably losing 
> some level of powersaving support. I'd say that's harmful :)

The system at hand is the Asus P2B-DS, a Dual Pentium III.
APM is not SMP safe, and was not deployed on SMP motherboards.
My expectation is that it is perfectly fine running in MPS
mode rather than ACPI mode, as it has been running that way
since 2003.  My expectation is that when running in ACPI mode,
the only thing the user will notice is that the power button
is software controlled.

> > The other entries in today's acpi_dmi_table[] are less clear
> > and should probably be modified only with some care...
> 
> At least one of them covers a single submodel in a range, despite them 
> all running the same BIOS. I'd really lean towards them being bogus at 
> this stage of the game.

While I too vote for consistency and less cruft is better,
I'd like to keep the acpi_ht issue at hand apart from the
inconsistency in old thinkpad BIOS DMI list issue; as they
are logically independent.

thanks,
Len Brown, Intel Open Source Technology Center

Re: [patch 7/7] acpi: remove old blacklist entries

[Matthew Garrett]

On Wed, Feb 17, 2010 at 04:23:12PM -0500, Len Brown wrote:
> On Wed, 17 Feb 2010, Matthew Garrett wrote:
> > The machines in question are falling back to apm, so probably losing 
> > some level of powersaving support. I'd say that's harmful :)
> 
> The system at hand is the Asus P2B-DS, a Dual Pentium III.
> APM is not SMP safe, and was not deployed on SMP motherboards.
> My expectation is that it is perfectly fine running in MPS
> mode rather than ACPI mode, as it has been running that way
> since 2003.  My expectation is that when running in ACPI mode,
> the only thing the user will notice is that the power button
> is software controlled.

So the APM idle loop won't have been used? I was under the impression 
that C1 was preferable to just calling hlt, but I'll admit to having no 
idea if that's true for the PIII. I'd also have expected there to be at 
least S1, so ACPI would be a functional improvement.

> > At least one of them covers a single submodel in a range, despite them 
> > all running the same BIOS. I'd really lean towards them being bogus at 
> > this stage of the game.
> 
> While I too vote for consistency and less cruft is better,
> I'd like to keep the acpi_ht issue at hand apart from the
> inconsistency in old thinkpad BIOS DMI list issue; as they
> are logically independent.

They're similar in that we have absolutely no idea why these entries are 
present, potentially resulting in us reducing the functionality of 
machines that would otherwise work happily.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch 7/7] acpi: remove old blacklist entries

[Len Brown]

> So the APM idle loop won't have been used?

APM -- by definition -- is not present on SMP motherboards,
and thus is a non-factor on motherboards where acpi=ht
would be used.

> I was under the impression 
> that C1 was preferable to just calling hlt, but I'll admit to having no 
> idea if that's true for the PIII.

C1 and HLT are synonymous on P-III, and also many other systems.

MWAIT hints for use in the idle loop were added after Pentium III.

The power savings of MWAIT for C1 is the same as HLT, but
the wakeup mechanism is lower overhead, especially on systems
with lots of processors.

Today, MWAIT extension "hints" are used to get into deep C-states,
but that was not the case for PIII.

> I'd also have expected there to be at 
> least S1, so ACPI would be a functional improvement.

Apparently nobody has complained about lacking that feature
on this motherboard during the last 6 years, so I wouldn't
recommend losing any sleep over it.

> > > At least one of them covers a single submodel in a range, despite them 
> > > all running the same BIOS. I'd really lean towards them being bogus at 
> > > this stage of the game.
> > 
> > While I too vote for consistency and less cruft is better,
> > I'd like to keep the acpi_ht issue at hand apart from the
> > inconsistency in old thinkpad BIOS DMI list issue; as they
> > are logically independent.
> 
> They're similar in that we have absolutely no idea why these entries are 
> present, potentially resulting in us reducing the functionality of 
> machines that would otherwise work happily.

I know for a fact that some of the entries on that list are valid.
I'm delited to clean up the ones that are cruft, and I thank you for
noticing that a cleanup is necessary, but deleting them en-masse
would be folly.

thanks,
-Len Brown, Intel Open Source Technology Center

[PATCH 1/2] ACPI: remove "acpi=ht" DMI blacklist

[Len Brown]

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

SuSE added these entries when deploying ACPI in Linux-2.4.
I pulled them into Linux-2.6 on 2003-08-09.
Over the last 6+ years, several entries have proven to be
unnecessary and deleted, while no new entries have been added.
Matthew suggests that they now have negative value, and I agree.

Based-on-patch-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 arch/x86/kernel/acpi/boot.c |   93 -------------------------------------------
 1 files changed, 0 insertions(+), 93 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index af1c583..cba0311 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1264,23 +1264,6 @@ static int __init dmi_disable_acpi(const struct dmi_system_id *d)
 }
 
 /*
- * Limit ACPI to CPU enumeration for HT
- */
-static int __init force_acpi_ht(const struct dmi_system_id *d)
-{
-	if (!acpi_force) {
-		printk(KERN_NOTICE "%s detected: force use of acpi=ht\n",
-		       d->ident);
-		disable_acpi();
-		acpi_ht = 1;
-	} else {
-		printk(KERN_NOTICE
-		       "Warning: acpi=force overrules DMI blacklist: acpi=ht\n");
-	}
-	return 0;
-}
-
-/*
  * Force ignoring BIOS IRQ0 pin2 override
  */
 static int __init dmi_ignore_irq0_timer_override(const struct dmi_system_id *d)
@@ -1316,82 +1299,6 @@ static struct dmi_system_id __initdata acpi_dmi_table[] = {
 	 },
 
 	/*
-	 * Boxes that need acpi=ht
-	 */
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "FSC Primergy T850",
-	 .matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "PRIMERGY T850"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "HP VISUALIZE NT Workstation",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "HP VISUALIZE NT Workstation"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "Compaq Workstation W8000",
-	 .matches = {
-		     DMI_MATCH(DMI_SYS_VENDOR, "Compaq"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "Workstation W8000"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "ASUS CUR-DLS",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
-		     DMI_MATCH(DMI_BOARD_NAME, "CUR-DLS"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "ABIT i440BX-W83977",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ABIT <http://www.abit.com>"),
-		     DMI_MATCH(DMI_BOARD_NAME, "i440BX-W83977 (BP6)"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM Bladecenter",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_BOARD_NAME, "IBM eServer BladeCenter HS20"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM eServer xSeries 360",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_BOARD_NAME, "eServer xSeries 360"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM eserver xSeries 330",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_BOARD_NAME, "eserver xSeries 330"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
-	 .ident = "IBM eserver xSeries 440",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
-		     DMI_MATCH(DMI_PRODUCT_NAME, "eserver xSeries 440"),
-		     },
-	 },
-
-	/*
 	 * Boxes that need ACPI PCI IRQ routing disabled
 	 */
 	{
-- 
1.7.0.17.g7e5eb

[patch 2/2] ACPI: delete the "acpi=ht" boot option

[Len Brown]

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

acpi=ht was important in 2003 -- before ACPI was
universally deployed and enabled by default in
the major Linux distributions.

At that time, there were a fair number of people who
or chose to, or needed to, run with acpi=off,
yet also wanted access to Hyper-threading.

Today we find that many invocations of "acpi=ht"
are accidental, and thus is it possible that it
is doing more harm than good.

The implementation of acpi=ht is a hack --
lets see if we can delete it.

Signed-off-by: Len Brown <len.brown@intel.com>
---
 Documentation/kernel-parameters.txt |    3 +--
 arch/ia64/include/asm/acpi.h        |    1 -
 arch/x86/include/asm/acpi.h         |    2 --
 arch/x86/kernel/acpi/boot.c         |   17 +++--------------
 arch/x86/lguest/boot.c              |    1 -
 drivers/acpi/tables.c               |    4 ++--
 6 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 826b6e1..a76ca84 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -142,11 +142,10 @@ and is between 256 and 4096 characters. It is defined in the file
 
 	acpi=		[HW,ACPI,X86]
 			Advanced Configuration and Power Interface
-			Format: { force | off | ht | strict | noirq | rsdt }
+			Format: { force | off | strict | noirq | rsdt }
 			force -- enable ACPI if default was off
 			off -- disable ACPI if default was on
 			noirq -- do not use ACPI for IRQ routing
-			ht -- run only enough ACPI to enable Hyper Threading
 			strict -- Be less tolerant of platforms that are not
 				strictly ACPI specification compliant.
 			rsdt -- prefer RSDT over (default) XSDT
diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index e97b255..7ae5889 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -94,7 +94,6 @@ ia64_acpi_release_global_lock (unsigned int *lock)
 #define acpi_noirq 0	/* ACPI always enabled on IA64 */
 #define acpi_pci_disabled 0 /* ACPI PCI always enabled on IA64 */
 #define acpi_strict 1	/* no ACPI spec workarounds on IA64 */
-#define acpi_ht 0	/* no HT-only mode on IA64 */
 #endif
 #define acpi_processor_cstate_check(x) (x) /* no idle limits on IA64 :) */
 static inline void disable_acpi(void) { }
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 56f462c..aa2c39d 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -85,7 +85,6 @@ extern int acpi_ioapic;
 extern int acpi_noirq;
 extern int acpi_strict;
 extern int acpi_disabled;
-extern int acpi_ht;
 extern int acpi_pci_disabled;
 extern int acpi_skip_timer_override;
 extern int acpi_use_timer_override;
@@ -97,7 +96,6 @@ void acpi_pic_sci_set_trigger(unsigned int, u16);
 static inline void disable_acpi(void)
 {
 	acpi_disabled = 1;
-	acpi_ht = 0;
 	acpi_pci_disabled = 1;
 	acpi_noirq = 1;
 }
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index cba0311..97229f3 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -60,7 +60,6 @@ EXPORT_SYMBOL(acpi_disabled);
 int acpi_noirq;				/* skip ACPI IRQ initialization */
 int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
 EXPORT_SYMBOL(acpi_pci_disabled);
-int acpi_ht __initdata = 1;	/* enable HT */
 
 int acpi_lapic;
 int acpi_ioapic;
@@ -1431,9 +1430,8 @@ void __init acpi_boot_table_init(void)
 
 	/*
 	 * If acpi_disabled, bail out
-	 * One exception: acpi=ht continues far enough to enumerate LAPICs
 	 */
-	if (acpi_disabled && !acpi_ht)
+	if (acpi_disabled)
 		return; 
 
 	/*
@@ -1464,9 +1462,8 @@ int __init early_acpi_boot_init(void)
 {
 	/*
 	 * If acpi_disabled, bail out
-	 * One exception: acpi=ht continues far enough to enumerate LAPICs
 	 */
-	if (acpi_disabled && !acpi_ht)
+	if (acpi_disabled)
 		return 1;
 
 	/*
@@ -1484,9 +1481,8 @@ int __init acpi_boot_init(void)
 
 	/*
 	 * If acpi_disabled, bail out
-	 * One exception: acpi=ht continues far enough to enumerate LAPICs
 	 */
-	if (acpi_disabled && !acpi_ht)
+	if (acpi_disabled)
 		return 1;
 
 	acpi_table_parse(ACPI_SIG_BOOT, acpi_parse_sbf);
@@ -1518,19 +1514,12 @@ static int __init parse_acpi(char *arg)
 	/* acpi=force to over-ride black-list */
 	else if (strcmp(arg, "force") == 0) {
 		acpi_force = 1;
-		acpi_ht = 1;
 		acpi_disabled = 0;
 	}
 	/* acpi=strict disables out-of-spec workarounds */
 	else if (strcmp(arg, "strict") == 0) {
 		acpi_strict = 1;
 	}
-	/* Limit ACPI just to boot-time to enable HT */
-	else if (strcmp(arg, "ht") == 0) {
-		if (!acpi_force)
-			disable_acpi();
-		acpi_ht = 1;
-	}
 	/* acpi=rsdt use RSDT instead of XSDT */
 	else if (strcmp(arg, "rsdt") == 0) {
 		acpi_rsdt_forced = 1;
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 7e59dc1..8eb9eed 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1391,7 +1391,6 @@ __init void lguest_init(void)
 #endif
 #ifdef CONFIG_ACPI
 	acpi_disabled = 1;
-	acpi_ht = 0;
 #endif
 
 	/*
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 8a0ed28..f336bca 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -213,7 +213,7 @@ acpi_table_parse_entries(char *id,
 	unsigned long table_end;
 	acpi_size tbl_size;
 
-	if (acpi_disabled && !acpi_ht)
+	if (acpi_disabled)
 		return -ENODEV;
 
 	if (!handler)
@@ -280,7 +280,7 @@ int __init acpi_table_parse(char *id, acpi_table_handler handler)
 	struct acpi_table_header *table = NULL;
 	acpi_size tbl_size;
 
-	if (acpi_disabled && !acpi_ht)
+	if (acpi_disabled)
 		return -ENODEV;
 
 	if (!handler)
-- 
1.7.0.17.g7e5eb

Re: [patch 7/7] acpi: remove old blacklist entries

[Thomas Renninger]

Hi,

On Tuesday 02 February 2010 23:37:59 akpm@linux-foundation.org wrote:
> From: Matthew Garrett <mjg59@srcf.ucam.org>
> 
> The kernel has a set of blacklist entries that disable ACPI functionality
> on various machines.  These all seem to date from pre-git days and most
> have no indication of what they were meant to fix.  Let's work on the
> assumption that we've fixed whatever it was that was broken before and so
> remove most of the entries.

> -	{
> -	 .callback = force_acpi_ht,
> -	 .ident = "IBM eserver xSeries 330",
> -	 .matches = {
> -		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
> -		     DMI_MATCH(DMI_BOARD_NAME, "eserver xSeries 330"),
> -		     },
> -	 },
For this one I can confirm that the blacklist is not needed with latest
kernel and the BIOS I use.
Beside the fact that this machine did not boot correctly due to wrongly
set up SCI irq since 2.6.31 (fixed via stable kernels now), the blacklist does
not match for my machine at all as only "System Information" and not the
"Base Board Information" used in the blacklist is filled in BIOS DMI data:

System Information
        Manufacturer: IBM
        Product Name: eserver xSeries 330 -[867411X]-

Base Board Information
        Manufacturer: IBM
        Product Name: Not Specified
 

I did not test whether the BIOS is up to date, though (and won't update, sorry):
Release Date: 09/20/2002

I'd also vote to remove the blacklist for ACPI test
(does this branch get synced into linux-next)?

    Thomas

Re: [patch 7/7] acpi: remove old blacklist entries

[Len Brown]

On Tue, 23 Feb 2010, Thomas Renninger wrote:

> > -	{
> > -	 .callback = force_acpi_ht,
> > -	 .ident = "IBM eserver xSeries 330",
> > -	 .matches = {
> > -		     DMI_MATCH(DMI_BOARD_VENDOR, "IBM"),
> > -		     DMI_MATCH(DMI_BOARD_NAME, "eserver xSeries 330"),
> > -		     },
> > -	 },

> For this one I can confirm that the blacklist is not needed with latest
> kernel and the BIOS I use.
...
> I'd also vote to remove the blacklist for ACPI test
> (does this branch get synced into linux-next)?

Thanks for the verification, Thomas.
Yes, this one is gone, with all the other force_acpi_ht entries.

Yes, the acpi test branch is included in linux-next.

cheers,
Len Brown, Intel Open Source Technology Center