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

Cagle, John (ISS-Houston)
2003-05-19T17:38:03Z

I recently discovered the origin of the infamous Compaq asterisk
problem:

When doing the original ACPI BIOS code (for Win98, many years ago),
either Windows 98 or the Microsoft ASL compiler had a problem with
HIDs generated from EISA ID's. To work around the problem, Microsoft
instructed us to use an asterisk as the first character of the _HID
value. All MS OS's since have understood this as a valid character
for use in HIDs, yet it was never added to the ACPI spec. This wasn't
a problem until Linux came along using Intel's ACPI stack, which was
written to the original spec, which doesn't allow asterisks in the
HIDs...

That said, it would be nice to relax that constraint in the Linux
ACPI implementation. The BIOS developers are aware of the issue and
they are rolling that change into new implementations going forward,
but there's no way all existing laptops will get new versions of the
BIOS.

Regards,
John

> -----Original Message-----
> From: Kevin Fenzi [mailto:kevin-acpi-+bl/7iUgRMUAvxtiuMwx3w@public.gmane.org]
> Sent: Monday, May 19, 2003 12:08 PM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: Working around bugs in ACPI BIOS [was Re: [ACPI]
> DSDT in initrd]
>
>
> -----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 with
> Pavel> 0. Both should be safe, and we should printk() loudly in both
> Pavel> 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-----