Skip to contentSkip to conversation

Incorrect ACPI blacklisting of ASUS P4B266 ?

DISCUSSION Olivier Berger 3 participants 13 messages Mar 28, 2009 – May 22, 2009 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hi.

There are quite a lot of reports of people having problems managing poweroff of their ASUS P4B266 based systems.

It seems that providing acpi=force as a boot param is quite succesful.

Maybe that should be fixed WRT to the blacklisting... hence reporting as advised in the kernel source (arch/x86/kernel/acpi/boot.c).

I unfortunately couldn't identify the reason why such a blacklisting was setup, as it seems to come from long time ago.

Hope this helps,

Best regards.

Signature · 3 lines
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

Following advice from Thomas Renninger, I hereby propose a patch for the ACPI blacklisting kernel code, that I've successfully applied to kernel 2.6.26-15, that allows ACPI detection on Asus P4B266 mainboards.

Maybe there could be a smarter version that would allow blacklisting for same mainboards with older BIOS versions than the one I'm using, but I don't know if/how that'd be possible. So the patch I propose is pretty obvious.

FYI, here are some reports that mention acpi=force working succesfully for P4B266 mainboards (in english and german) :

http://forums.fedoraforum.org/showpost.php?p=669615&postcount=5 / http://fedoraforum.org/forum/showpost.php?p=669615&postcount=5
https://lists.ubuntu.com/archives/kernel-bugs/2006-November/023486.html / https://bugs.launchpad.net/linux/+bug/43961/comments/145
http://forum.ubuntuusers.de/topic/automatische-abschaltung/#post-249151
http://www.pc-forum24.de/suse-system-installieren/3031-suse-10-2-laesst-sich-nicht-ausschalten.html#post13729

I hope this won't break things for different BIOS versions than mine, and that this will on the other hand allow lots of users to benefit from working ACPI.

Best regards,

arch/x86/kernel/acpi/boot.c renamed from arch/x86/kernel/acpi/boot.c.orig +0 -8
@@ -1106,14 +1106,6 @@
 	 },
 	{
 	 .callback = force_acpi_ht,
-	 .ident = "ASUS P4B266",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
-		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
 	 .ident = "ASUS P2B-DS",
 	 .matches = {
 		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
Quoted 16 lines · Thomas Renninger
Quoted 5 lines · On Saturday 28 March 2009 16:32:49 you wrote:

Hi.

There are quite a lot of reports of people having problems managing poweroff of their ASUS P4B266 based systems.

Quoted 7 lines

It seems that providing acpi=force as a boot param is quite succesful.

Maybe that should be fixed WRT to the blacklisting... hence reporting as advised in the kernel source (arch/x86/kernel/acpi/boot.c).

I unfortunately couldn't identify the reason why such a blacklisting was setup, as it seems to come from long time ago.

Maybe acpi was broken at that times and the bug was not in the ASUS BIOS, but in the ACPI implementation. Or the BIOS got fixed up.

Quoted 7 lines

Why don't you send a patch removing the ASUS from the dmi list and post it on [email protected]
Best also add a pointer to e.g. a discussion where people state that it works better with acpi=force.

Thomas

- --
Olivier BERGER
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFJ82X6LBigKrTF838RAguPAJ9sPUhnbG7V0XeXn1HLBg+8GGCfFwCgp6Hh +hRrDc8OZ/K7N6bzYwz7b+8=
=Jv7i
-----END PGP SIGNATURE-----

#3 lore raw
Quoted 8 lines · On Saturday 25 April 2009 21:35:42 Olivier Berger wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

Following advice from Thomas Renninger, I hereby propose a patch for the ACPI blacklisting kernel code, that I've successfully applied to kernel 2.6.26-15, that allows ACPI detection on Asus P4B266 mainboards.

Hmm, there seem to be different models of this motherboard series:
P4B266
P4B266-C
P4B266-E
P4B266-M
P4B266-SE

P4B266 and P4B266-SE seem to have a similar BIOS history and the latest for both is: Beta Version 1011.003

The rest has a similar version string, but different latest BIOS versions (e.g. 1007)

The dmi blacklisting currently done in the kernel is probably matching all of above and is rather unfortunate.
We could have:
- A BIOS update which makes all of above models work with acpi(=force) well. Then your patch is perfect.

- One or more of above (latest) BIOSes does not work well with acpi=force still.
Then we'd get regressions and some people will moan about that and the patch will get reverted. In this case we should find out which kind of BIOS/mainboard it is and enhance the blacklisting to only match this(these) -> dmidecode is needed to be able to blacklist more fine grained.

Quoted 8 lines

Maybe there could be a smarter version that would allow blacklisting for same mainboards with older BIOS versions than the one I'm using, but I don't know if/how that'd be possible. So the patch I propose is pretty obvious.

FYI, here are some reports that mention acpi=force working succesfully for P4B266 mainboards (in english and german) :

Quoted 6 lines

http://forums.fedoraforum.org/showpost.php?p=669615&postcount=5 / http://fedoraforum.org/forum/showpost.php?p=669615&postcount=5
https://lists.ubuntu.com/archives/kernel-bugs/2006-November/023486.html / https://bugs.launchpad.net/linux/+bug/43961/comments/145
http://forum.ubuntuusers.de/topic/automatische-abschaltung/#post-249151
http://www.pc-forum24.de/suse-system-installieren/3031-suse-10-2-laesst-sich-nicht-ausschalten.html#post13729

I hope this won't break things for different BIOS versions than mine,

That's the risk and we should try to find out more first.

I wonder whether it's worth that at all, one of the latest BIOSes is from:
2003/06/10

Quoted 2 lines

and that this will on the other hand allow lots of users to benefit from working ACPI.

It should be best if you state in above references that these guys must use acpi=force.
Others should find it then via google.
That's the easiest and safest way.
I tried to find out who and why this got added, but this exists even before git history...

Thomas

#4 lore raw
Quoted 14 lines · Thomas Renninger
Quoted 6 lines · On Saturday 25 April 2009 21:35:42 Olivier Berger wrote:

Hi.

Following advice from Thomas Renninger, I hereby propose a patch for the ACPI blacklisting kernel code, that I've successfully applied to kernel 2.6.26-15, that allows ACPI detection on Asus P4B266 mainboards.

Hmm, there seem to be different models of this motherboard series:
P4B266
P4B266-C
P4B266-E
P4B266-M
P4B266-SE

Quoted 3 lines

P4B266 and P4B266-SE seem to have a similar BIOS history and the latest for both is: Beta Version 1011.003

Where is this information available (other than on Asus support site) , btw ?

Quoted 9 lines

The rest has a similar version string, but different latest BIOS versions (e.g. 1007)

The dmi blacklisting currently done in the kernel is probably matching all of above and is rather unfortunate.
We could have:
- A BIOS update which makes all of above models work with acpi(=force) well. Then your patch is perfect.

Quoted 8 lines

- One or more of above (latest) BIOSes does not work well with acpi=force still.
Then we'd get regressions and some people will moan about that and the patch will get reverted. In this case we should find out which kind of BIOS/mainboard it is and enhance the blacklisting to only match this(these) -> dmidecode is needed to be able to blacklist more fine grained.

Isn't there any possibility to compare BIOS versions in the blacklisting code ?

Quoted 13 lines
Quoted 13 lines

Maybe there could be a smarter version that would allow blacklisting for same mainboards with older BIOS versions than the one I'm using, but I don't know if/how that'd be possible. So the patch I propose is pretty obvious.

FYI, here are some reports that mention acpi=force working succesfully for P4B266 mainboards (in english and german) :

http://forums.fedoraforum.org/showpost.php?p=669615&postcount=5 / http://fedoraforum.org/forum/showpost.php?p=669615&postcount=5
https://lists.ubuntu.com/archives/kernel-bugs/2006-November/023486.html / https://bugs.launchpad.net/linux/+bug/43961/comments/145
http://forum.ubuntuusers.de/topic/automatische-abschaltung/#post-249151
http://www.pc-forum24.de/suse-system-installieren/3031-suse-10-2-laesst-sich-nicht-ausschalten.html#post13729

Quoted 5 lines
Quoted 1 line

I hope this won't break things for different BIOS versions than mine,

That's the risk and we should try to find out more first.

I wonder whether it's worth that at all, one of the latest BIOSes is from:
2003/06/10

Of course it's an old mainboard... but I suppose there are still quite a bunch in operation.

Quoted 7 lines
Quoted 3 lines

and that this will on the other hand allow lots of users to benefit from working ACPI.

It should be best if you state in above references that these guys must use acpi=force.
Others should find it then via google.
That's the easiest and safest way.

Well... adding burden on users instead of clean patch ;)

Quoted 3 lines

I tried to find out who and why this got added, but this exists even before git history...

Same for my searches :(

So... there ain't a way to provide an improved patch that wouldn't change anything but for tested BIOS versions (btw, mine is :
BIOS Information
Vendor: Award Software, Inc.
Version: ASUS P4B266 ACPI BIOS Revision 1010 Release Date: 08/06/2002
) ?

That would be sad if the current blacklisting wasn't able to do such checks on versions :(

Anyway, I suppose I will follow your advice and try and report people of the acpi=force as I already started to do in
http://www.olivierberger.com/weblog/index.php?post/2009/03/28/Proper-power-management-on-Asus-P4B266-mainboard

Thanks for your helps.

Best regards,

Signature · 3 lines
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/
#5 lore raw
Quoted 57 lines · On Tuesday 28 April 2009 08:09:16 Olivier Berger wrote:
Quoted 14 lines · Thomas Renninger
Quoted 6 lines · On Saturday 25 April 2009 21:35:42 Olivier Berger wrote:

Hi.

Following advice from Thomas Renninger, I hereby propose a patch for the ACPI blacklisting kernel code, that I've successfully applied to kernel 2.6.26-15, that allows ACPI detection on Asus P4B266 mainboards.

Hmm, there seem to be different models of this motherboard series:
P4B266
P4B266-C
P4B266-E
P4B266-M
P4B266-SE

Quoted 3 lines

P4B266 and P4B266-SE seem to have a similar BIOS history and the latest for both is: Beta Version 1011.003

Where is this information available (other than on Asus support site) , btw ? From the Asus support site.

Quoted 9 lines

The rest has a similar version string, but different latest BIOS versions (e.g. 1007)

The dmi blacklisting currently done in the kernel is probably matching all of above and is rather unfortunate.
We could have:
- A BIOS update which makes all of above models work with acpi(=force) well. Then your patch is perfect.

Quoted 8 lines

- One or more of above (latest) BIOSes does not work well with acpi=force still.
Then we'd get regressions and some people will moan about that and the patch will get reverted. In this case we should find out which kind of BIOS/mainboard it is and enhance the blacklisting to only match this(these) -> dmidecode is needed to be able to blacklist more fine grained.

Isn't there any possibility to compare BIOS versions in the blacklisting code ?

Quoted 13 lines
Quoted 13 lines

Maybe there could be a smarter version that would allow blacklisting for same mainboards with older BIOS versions than the one I'm using, but I don't know if/how that'd be possible. So the patch I propose is pretty obvious.

FYI, here are some reports that mention acpi=force working succesfully for P4B266 mainboards (in english and german) :

http://forums.fedoraforum.org/showpost.php?p=669615&postcount=5 / http://fedoraforum.org/forum/showpost.php?p=669615&postcount=5
https://lists.ubuntu.com/archives/kernel-bugs/2006-November/023486.html / https://bugs.launchpad.net/linux/+bug/43961/comments/145
http://forum.ubuntuusers.de/topic/automatische-abschaltung/#post-249151
http://www.pc-forum24.de/suse-system-installieren/3031-suse-10-2-laesst-sich-nicht-ausschalten.html#post13729

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

I hope this won't break things for different BIOS versions than mine,

That's the risk and we should try to find out more first.

I wonder whether it's worth that at all, one of the latest BIOSes is from:
2003/06/10

Of course it's an old mainboard... but I suppose there are still quite a bunch in operation.

Yep and it would be worse if some are not anymore after this change, than if some (a lot probably are already using this) need acpi=force.

Quoted 24 lines
Quoted 7 lines
Quoted 3 lines

and that this will on the other hand allow lots of users to benefit from working ACPI.

It should be best if you state in above references that these guys must use acpi=force.
Others should find it then via google.
That's the easiest and safest way.

Well... adding burden on users instead of clean patch ;)

Quoted 3 lines

I tried to find out who and why this got added, but this exists even before git history...

Same for my searches :(

So... there ain't a way to provide an improved patch that wouldn't change anything but for tested BIOS versions (btw, mine is :
BIOS Information
Vendor: Award Software, Inc.
Version: ASUS P4B266 ACPI BIOS Revision 1010 Release Date: 08/06/2002
) ?

Quoted 2 lines

That would be sad if the current blacklisting wasn't able to do such checks on versions :(

You could either:
1) add a whitelist into the blacklist
2) better limit the blacklist
The first won't break machines, but is ugly.
For the second you must know which BIOS(es) fix the acpi parts to not cause regressions and then list all broken BIOS revisions, e.g.:

	{
	 .callback = force_acpi_ht,
	 .ident = "ASUS P4B266",
	 .matches = {
		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
		     DMI_MATCH(DMI_BOARD_VERSION, "ASUS P4B266 ACPI BIOS Revision 1007"),
		     },
	 },
	{
	 .callback = force_acpi_ht,
	 .ident = "ASUS P4B266",
	 .matches = {
		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
		     DMI_MATCH(DMI_BOARD_VERSION, "ASUS P4B266 ACPI BIOS Revision 1008"),
		     },
	 },

BTW, the same seem to have happened for the ASUS A7V:

	/*
	 * 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"),
		     },
	 },

One could argue that people have to upgrade to the latest BIOS and your patch is ok. This is IMO a valid argument, but it could be that people with a P4B266-SE board cannot upgrade to version 1010. I'd say, better leave the fingers off...

Quoted 3 lines

Anyway, I suppose I will follow your advice and try and report people of the acpi=force as I already started to do in
http://www.olivierberger.com/weblog/index.php?post/2009/03/28/Proper-power-management-on-Asus-P4B266-mainboard

Everyone with such problems should easily be able to google the acpi=force param for this board then.

Thanks,

Thomas

#6 lore raw
Quoted 7 lines · Thomas Renninger
Quoted 3 lines

That would be sad if the current blacklisting wasn't able to do such checks on versions :(

You could either:
1) add a whitelist into the blacklist
2) better limit the blacklist
The first won't break machines, but is ugly.

I suppose some new algorithm would need to be written for that, and no easy "struct definition" (like what is currently there) will be enough ?

Quoted 22 lines

For the second you must know which BIOS(es) fix the acpi parts to not cause regressions and then list all broken BIOS revisions, e.g.:

	{
	 .callback = force_acpi_ht,
	 .ident = "ASUS P4B266",
	 .matches = {
		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
		     DMI_MATCH(DMI_BOARD_VERSION, "ASUS P4B266 ACPI BIOS Revision 1007"),
		     },
	 },
	{
	 .callback = force_acpi_ht,
	 .ident = "ASUS P4B266",
	 .matches = {
		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
		     DMI_MATCH(DMI_BOARD_VERSION, "ASUS P4B266 ACPI BIOS Revision 1008"),
		     },
	 },

BTW, the same seem to have happened for the ASUS A7V:

Quoted 15 lines
	/*
	 * 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"),
		     },
	 },

Well, that lacks some version comparison operator to look clean to me... which looks far from trivial considering the version formats probably quite creative ;)

Quoted 4 lines

One could argue that people have to upgrade to the latest BIOS and your patch is ok. This is IMO a valid argument, but it could be that people with a P4B266-SE board cannot upgrade to version 1010. I'd say, better leave the fingers off...

Yup.

Quoted 7 lines
Quoted 4 lines

Anyway, I suppose I will follow your advice and try and report people of the acpi=force as I already started to do in
http://www.olivierberger.com/weblog/index.php?post/2009/03/28/Proper-power-management-on-Asus-P4B266-mainboard

Everyone with such problems should easily be able to google the acpi=force param for this board then.

I'm thinking about some kind of warning message that might be provided by the kernel.

Currently, the blacklisting issues something like :
xxx detected : force use of acpi=ht

Maybe in some greylisted cases (like such ASUS P4B266), an additional message may be issued, something like :
xxx detected : may work with acpi=force (test at own risk)
or something like that ?

Btw, while we're at it, the first message is not so clear to me "force use of acpi=ht" : I think it could be interpreted as "you may force ACPI to work by passing acpi=ht" or something like that, as it tends to indicate that it refers to an 'acpi=' parameter.

Maybe something like "forced 'ht' mode for acpi" or a similar variant would be less ambiguous (pardon me, I'm not so sure what 'ht' means here, btw).

Hope this helps,

Signature · 3 lines
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/
#7 lore raw
Quoted 6 lines · On Tuesday 28 April 2009 19:15:47 Olivier Berger wrote:

Thomas Renninger <[email protected]> writes:

I'm thinking about some kind of warning message that might be provided by the kernel.

Quoted 7 lines

Currently, the blacklisting issues something like :
xxx detected : force use of acpi=ht

Maybe in some greylisted cases (like such ASUS P4B266), an additional message may be issued, something like :
xxx detected : may work with acpi=force (test at own risk)
or something like that ?

Sounds like a good idea.
Something like that (not tested at all).
I could imagine Len adds this one if you give it a try and see the message popping up in dmesg.

ACPI: Some latest P4B266 BIOSes prefer acpi, but get blacklisted, notify user

---
 arch/x86/kernel/acpi/boot.c |    3 +++
 1 file changed, 3 insertions(+)
arch/x86/kernel/acpi/boot.c +3 -0
Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
@@ -1496,6 +1496,9 @@ static int __init force_acpi_ht(const st
 	if (!acpi_force) {
 		printk(KERN_NOTICE "%s detected: force use of acpi=ht\n",
 		       d->ident);
+		if (!strcmp(d->ident, "ASUS P4B266"))
+			printk(KERN_NOTICE "Latest BIOSes might work better"
+			       " with acpi=force\n");
 		disable_acpi();
 		acpi_ht = 1;
 	} else {

#8 lore raw
Quoted 10 lines · Thomas Renninger
Quoted 9 lines · On Tuesday 28 April 2009 19:15:47 Olivier Berger wrote:

Thomas Renninger <[email protected]> writes:

I'm thinking about some kind of warning message that might be provided by the kernel.

Currently, the blacklisting issues something like :
xxx detected : force use of acpi=ht

Quoted 8 lines
Quoted 4 lines

Maybe in some greylisted cases (like such ASUS P4B266), an additional message may be issued, something like :
xxx detected : may work with acpi=force (test at own risk)
or something like that ?

Sounds like a good idea.
Something like that (not tested at all).
I could imagine Len adds this one if you give it a try and see the message popping up in dmesg.

I can confirm this works.

Here's the dmesg :

Apr 29 23:17:42 asustour kernel: [    0.000000] ASUS P4B266 detected: force use of acpi=ht
Apr 29 23:17:42 asustour kernel: [    0.000000] Latest BIOSes might work better with acpi=force

Hope this is would be at least better than previous state.

Thanks for your help.

Best regards,

Signature · 3 lines
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/
#9 lore raw

Hi.

Quoted 16 lines · Olivier Berger
Quoted 14 lines · Thomas Renninger
Quoted 13 lines · On Tuesday 28 April 2009 19:15:47 Olivier Berger wrote:

Thomas Renninger <[email protected]> writes:

I'm thinking about some kind of warning message that might be provided by the kernel.

Currently, the blacklisting issues something like :
xxx detected : force use of acpi=ht

Maybe in some greylisted cases (like such ASUS P4B266), an additional message may be issued, something like :
xxx detected : may work with acpi=force (test at own risk)
or something like that ?

Quoted 7 lines
Quoted 4 lines

Sounds like a good idea.
Something like that (not tested at all).
I could imagine Len adds this one if you give it a try and see the message popping up in dmesg.

I can confirm this works.

May I ask you to review the patch provided here :
http://marc.info/?l=linux-acpi&m=124094144423277&w=2 ?

I'm asking directly as I saw no response on the list. Sorry to bother you.

Thanks in advance.

Best regards,

Signature · 3 lines
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/
reviewer
#10 lore raw
In reply to Thomas Renninger

The P4B266 DMI entry went into ./arch/i386/kernel/dmi_scan.c back in Aug-2003.

That was when I was just starting to maintain ACPI, and I took a bunch of blacklist entries from SuSE because they were already shipping with ACPI enabled.

In the short term, it may have been the right thing to do, but in the long term it was a mistake and I regret doing it.

Blacklist entries paper-over real bugs, and unless we are lucky enough that somebody like you, Oliver, steps forward, blacklist entries are nearly impossible to ever remove.

So I'm inclined to apply your original patch to delete the blacklist entry entirely. If somebody with one of those boxes has a regression, we'll go fix their box -- which we may have acutally fixed years ago and not known it...

thanks,
-Len

#11 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

Quoted 2 lines · Len Brown

The P4B266 DMI entry went into ./arch/i386/kernel/dmi_scan.c back in Aug-2003.

Wow, I understand why it was hard to track it back to the time it was included ;-)

Quoted 8 lines

That was when I was just starting to maintain ACPI, and I took a bunch of blacklist entries from SuSE because they were already shipping with ACPI enabled.

In the short term, it may have been the right thing to do, but in the long term it was a mistake and I regret doing it.

Quoted 9 lines

Blacklist entries paper-over real bugs, and unless we are lucky enough that somebody like you, Oliver, steps forward, blacklist entries are nearly impossible to ever remove.

So I'm inclined to apply your original patch to delete the blacklist entry entirely. If somebody with one of those boxes has a regression, we'll go fix their box -- which we may have acutally fixed years ago and not known it...

OK, as a maintainer you'll be the one to blame ;) And as a user, I'll be glad to see my system fully using ACPI, I guess :-)

Quoted 5 lines · Len Brown

Olivier,
If you can send me a properly formatted patch
to remove the dmi entry,
(Documentation/SubmittingPatches)
including your signed-off, i'll apply it.

Here's it in attachment. I'm not really experienced with git so I hope it suits your needs.

Quoted 5 lines

thanks,
Len Brown, Intel Open Source Technology Center

Best regards,

Quoted 1 line

From 6f304fa7c0e0c5bac86fb47c53354889017fceb8 Mon Sep 17 00:00:00 2001

From: olivier <[email protected]>
Date: Sat, 16 May 2009 15:47:18 +0200
Subject: [PATCH] Removing ACPI blacklisting for P4B266 mainboards.
See http://marc.info/?l=linux-acpi&m=124068823904429&w=2 for discussion

---
 arch/x86/kernel/acpi/boot.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)
arch/x86/kernel/acpi/boot.c +0 -8
index 723989d..065b3fa 100644
@@ -1569,14 +1569,6 @@ static struct dmi_system_id __initdata acpi_dmi_table[] = {
 	 },
 	{
 	 .callback = force_acpi_ht,
-	 .ident = "ASUS P4B266",
-	 .matches = {
-		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
-		     DMI_MATCH(DMI_BOARD_NAME, "P4B266"),
-		     },
-	 },
-	{
-	 .callback = force_acpi_ht,
 	 .ident = "ASUS P2B-DS",
 	 .matches = {
 		     DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
Signature · 1 line
1.6.2.4

- --
Olivier BERGER
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFKD77rLBigKrTF838RAthrAKDerhUKv8JZTvtJ5SrlooeFZofU0wCgyJ8L 8z1I6OP9wSsS7JQn7vm1UIc=
=AQyP
-----END PGP SIGNATURE-----

#12 lore raw
Quoted 10 lines · Olivier Berger
Quoted 5 lines · Len Brown

Olivier,
If you can send me a properly formatted patch
to remove the dmi entry,
(Documentation/SubmittingPatches)
including your signed-off, i'll apply it.

Here's it in attachment. I'm not really experienced with git so I hope it suits your needs.

FYI, I've resent it in an individual mail
(http://marc.info/?l=linux-acpi&m=124291514825272&w=2) and

Quoted 2 lines · Len Brown

applied for 2.6.31

Thanks.

Best regards,

Signature · 3 lines
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/
reviewer
#13 lore raw
In reply to Olivier Berger

Olivier,
If you can send me a properly formatted patch
to remove the dmi entry,
(Documentation/SubmittingPatches)
including your signed-off, i'll apply it.

thanks,
Len Brown, Intel Open Source Technology Center