Re: Working around bugs in ACPI BIOS [was Re: DSDT in initrd]

Kevin Fenzi
2003-05-19T17:07:34Z

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

>>>>> "Pavel" == Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> writes:

Pavel> Hi!
>> I must admit I'm really torn. If there were 2-3 little AML problems
>> that if we worked around them, a horde of machines would start
>> working, then I think we would do that, but my sense is that there
>> are many more ways a DSDT can be broken, and that implementing
>> workarounds for all of them would cause other systems to
>> fail. Maybe some of the people who have fixed their DSDTs can
>> comment on the scope of bugs out there.

Pavel> I believe policy should be "if it can't possibly break anyone".

Pavel> AML functions not returning value can be safely replaced with
Pavel> returning 0; uninitialized variables can also be initialized
Pavel> with 0. Both should be safe, and we should printk() loudly in
Pavel> both cases.

The one I would like to see is when acpi is parsing and comes accross
a variable with a * in it, it just removes the * and parses the
variable after that. This would make tons of compaq laptops happy with
acpi out of the box. I think pretty much all of them have this bug.

The main reason I have to modify my dsdt is to remove all the *'s from
it. ie,

Name(_HID, "*PNP0C0B")
...
Name(_HID, "*PNP0C01")
...
Name(_HID, "*PNP0A03")

Is there any way this could be added?

Granted this might cause compaq to not update their bios, but on many
of the older laptops I don't think thats going to happen anyhow.

kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE+yQ9a3imCezTjY0ERAr3/AKCbuqoMQpYkRuMaBskTx1FPTiEDigCeMgN8
rWg4Pf0x6RuabOMEtfjTVj8=
=sStk
-----END PGP SIGNATURE-----