On Tuesday 28 April 2009 08:09:16 Olivier Berger wrote: > Thomas Renninger <trenn@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
