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

Grover, Andrew
2003-05-19T17:50:39Z

OK, sounds reasonable. Anyone have a patch verified to work for this,
sitting around? If not, I'll take a look at this for next release.

Regards -- Andy

> -----Original Message-----
> From: Cagle, John (ISS-Houston) [mailto:john.cagle-VXdhtT5mjnY@public.gmane.org]
> Sent: Monday, May 19, 2003 10:38 AM
> To: Kevin Fenzi; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: RE: Working around bugs in ACPI BIOS [was Re: [ACPI]
> DSDT in initrd]
>
>
> 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-----
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: If flattening out C++ or Java
> code to make your application fit in a relational database is
> painful,
> don't do it! Check out ObjectStore. Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel