RE: Working around bugs in ACPI BIOS [was Re: 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

quoted

quoted

quoted

quoted

quoted

"Pavel" == Pavel Machek [off-list ref] writes:

Pavel> Hi!

quoted

quoted

I must admit I'm really torn. If there were 2-3 little AML 

problems 

quoted

quoted

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 

quoted

quoted

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