Incorrect ACPI blacklisting of ASUS P4B266 ?

Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

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.
-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

-----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,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: p4b266noblacklist.patch --]
[-- Type: text/x-diff, Size: 544 bytes --]

--- linux-2.6-2.6.26/arch/x86/kernel/acpi/boot.c.orig	2009-04-25 18:02:10.000000000 +0200
+++ linux-2.6-2.6.26/arch/x86/kernel/acpi/boot.c	2009-04-25 18:03:01.000000000 +0200
@@ -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."),

[-- Attachment #3: Type: text/plain, Size: 1293 bytes --]



Thomas Renninger <trenn@suse.de> writes:

> 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.
>> 
>> 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.
>
> Why don't you send a patch removing the ASUS from the dmi list and post
> it on linux-acpi@vger.kernel.org
> 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-----

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Thomas Renninger]

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.

> 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,
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

> 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

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

Thomas Renninger <trenn@suse.de> writes:

> 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
>
> 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 ?

> 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.
>

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

>> 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,
> 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.

>
>> 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 ;)

> 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,

-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Thomas Renninger]

On Tuesday 28 April 2009 08:09:16 Olivier Berger wrote:
> Thomas Renninger <trenn@suse.de> writes:
> 
> > 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
> >
> > 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.
> 
> > 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.
> >
> 
> Isn't there any possibility to compare BIOS versions in the blacklisting
> code ?
> 
> >> 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,
> > 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.
> >
> >> 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 ;)
> 
> > 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 :(
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...

> 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

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

Thomas Renninger <trenn@suse.de> writes:

>> 
>> 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 ?

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

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

> 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.

>
>> 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,
-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Thomas Renninger]

On Tuesday 28 April 2009 19:15:47 Olivier Berger wrote:
> Thomas Renninger <trenn@suse.de> 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 ?
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


Signed-off-by: Thomas Renninger <trenn@suse.de>

---
 arch/x86/kernel/acpi/boot.c |    3 +++
 1 file changed, 3 insertions(+)

Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ 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 {
\0

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

Thomas Renninger <trenn@suse.de> writes:

> On Tuesday 28 April 2009 19:15:47 Olivier Berger wrote:
>> Thomas Renninger <trenn@suse.de> 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 ?
> 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,
-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

Hi.

Olivier Berger <oberger@ouvaton.org> writes:

> Thomas Renninger <trenn@suse.de> writes:
>
>> On Tuesday 28 April 2009 19:15:47 Olivier Berger wrote:
>>> Thomas Renninger <trenn@suse.de> 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 ?
>> 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,
-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Len Brown]

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

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

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

Hi.

Len Brown <lenb@kernel.org> writes:

> 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 ;-)

>
> 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...
>

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 :-)


Len Brown <lenb@kernel.org> writes:

> 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.

>
> thanks,
> Len Brown, Intel Open Source Technology Center
>
>

Best regards,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Removing-ACPI-blacklisting-for-P4B266-mainboards.patch --]
[-- Type: text/x-diff, Size: 1056 bytes --]

>From 6f304fa7c0e0c5bac86fb47c53354889017fceb8 Mon Sep 17 00:00:00 2001
From: olivier <olivier@olivierberger.com>
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

Signed-off-by: Olivier Berger <oberger@ouvaton.org>
---
 arch/x86/kernel/acpi/boot.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 723989d..065b3fa 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -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."),
-- 
1.6.2.4


[-- Attachment #3: Type: text/plain, Size: 350 bytes --]


- -- 
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-----

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[Olivier Berger]

Olivier Berger <oberger@ouvaton.org> writes:

> Len Brown <lenb@kernel.org> writes:
>
>> 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 

Len Brown <lenb@kernel.org> writes:

> applied for 2.6.31
>

Thanks.

Best regards,

-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

Re: Incorrect ACPI blacklisting of ASUS P4B266 ?

[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.

thanks,
Len Brown, Intel Open Source Technology Center