RE: DSDT in initrd

RE: DSDT in initrd

[Grover, Andrew]

> From: Randy.Dunlap [mailto:rddunlap-3NddpPZAyC0@public.gmane.org] 
> Lots of newer systems don't have an option of "... safely reverts to
> non-ACPI ...", and surely you know that.  It's make ACPI work in some
> fashion or have no power management.

Yeah but DSDT in initrd doesn't help solve the problem for anyone but
hackers.

> It seems that your goal is idealistic and not user-friendly, at least
> not in the short-term.  It's a worthy long-term goal.

Anything that does not use the DSDT from the BIOS is not user-friendly.
It should "just work" for as many people as possible, without hackery.
It's never going to be 100%. The only way I can think of to get close is
if we take the time to implement a cutoff based on BIOS date, with both
a Good and Bad BIOS list, for exceptions to that cutoff.

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.

> The ACPI interpreter will always have bugs in it.  The BIOS DSDTs
> will always have bugs.  After all, they are software (or firmware).

All I can say w.r.t. bugs is that it used to be the case that when
diagnosing an issue, I started with the assumption the BIOS was right
and the interpreter had a bug -- now I start with the assumption that
the BIOS is buggy. :) If we can come up with a solution to mitigate the
impact of bad DSDTs, then in my mind the only things left are 1)
squashing the few bugs left in the PCI IRQ routing code and 2) sleep
support. We've come a long way baby!

Regards -- Andy


-------------------------------------------------------
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

Re: DSDT in initrd

[Mark Santcroos]

General question from a FreeBSD'er...

Do the vendors also use the iASL compiler or do they have their one tools?

Mark

-- 
Mark Santcroos                    RIPE Network Coordination Centre
http://www.ripe.net/home/mark/    New Projects Group/TTM


-------------------------------------------------------
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

RE: DSDT in initrd

[Adachi, Kenichi]

Hi,

> General question from a FreeBSD'er...
> 
> Do the vendors also use the iASL compiler or do they have 
> their one tools?

Take a look at Creater ID of original tables.
Likely MSFT is still most common.

Thanks,
- Adachi, Kenichi



-------------------------------------------------------
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

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

[Pavel Machek]

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.

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

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

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
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

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

[Ducrot Bruno]

On Sun, May 18, 2003 at 11:34:05PM +0200, Pavel Machek wrote:
> 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.
> 
> I believe policy should be "if it can't possibly break anyone".
> 
> AML functions not returning value can be safely replaced with
> returning 0; uninitialized variables can also be initialized with
> 0. Both should be safe, and we should printk() loudly in both cases.
> 

o relax operational region checking (not so trivial as it sound like,
  and may be done at acpi init stage imho),
o Store(Local0, Local0) is a Noop,
o allow return statements to be propageted to the calling method if the
  caller is known to return 'something' (either because it is a reserved
  method known to return something, or because it return
  something in other code path),
o mutex mis-use.

others?

All of them could be a separate kernel options, and cry when
possible (not handled by acpi debug option).

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
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

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

[Alan Cox]

On Llu, 2003-05-19 at 16:17, Ducrot Bruno wrote:
> o relax operational region checking (not so trivial as it sound like,
>   and may be done at acpi init stage imho),

Done in current -ac

> others?

A please upgrade signature table so that vendors who have fixed bioses
have a way to let customers find this out without bitching at support



-------------------------------------------------------
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

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

[Ducrot Bruno]

On Mon, May 19, 2003 at 04:14:47PM +0100, Alan Cox wrote:
> On Llu, 2003-05-19 at 16:17, Ducrot Bruno wrote:
> > o relax operational region checking (not so trivial as it sound like,
> >   and may be done at acpi init stage imho),
> 
> Done in current -ac

I know.  But it is not done like I described (at init stage, not
interpreter run stage, and perform not only size check but access
corrections in some trivial case).

> > others?
> 
> A please upgrade signature table so that vendors who have fixed bioses
> have a way to let customers find this out without bitching at support

Yeah.


-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
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

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

[Kevin Fenzi]

-----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-----


-------------------------------------------------------
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

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

[Cagle, John (ISS-Houston)]

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

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

[Alan Cox]

On Llu, 2003-05-19 at 18:38, Cagle, John (ISS-Houston) wrote:
> 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.

There I would agree. The -ac 2.4 tree has a config option for "relaxed"
ACPI, so you can have it to the spec - which might suit the more
paranoid types such as telco's, or to the reality which is a bit looser.
This is a prime candidate



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
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

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

[Sérgio Monteiro Basto]

On Mon, 2003-05-19 at 18:38, Cagle, John (ISS-Houston) wrote:
> 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.
Can you give me one tip, idea (paint one draw) about whose Compaq have
this asterisk, 
or where do you think Compaq begins correct this undocumented  thing, 
this question is more for laptops area.
My compaq presario 706EA doesn't have  
-- 
Sérgio Basto
Technology Project Manager
onevision design studios
TECMAIA - Parque de Ciência e Tecnologia da Maia
Rua Frederico Ulrich, 2650
4470-605 MOREIRA DA MAIA
tel. + 351 22 091 5410
fax. + 351 22 091 5419
email: sbasto-n97bsLhj/YhQPh2TJV30h1aTQe2KTcn/@public.gmane.org
web: http://www.onevision-design.com



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
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

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

[Moore, Robert]

Why is it that only Compaq machines seem to use the asterisk?
Bob


> -----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


-------------------------------------------------------
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

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

[Grover, Andrew]

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
> 


-------------------------------------------------------
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

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

[Cagle, John (ISS-Houston)]

Compaq was probably the first OEM to support ACPI with Windows 98.
The MS OS issue must have been fixed by the time other hardware
vendors implemented ACPI, so they didn't have to use the "*"
workaround.  (But that's just a guess, I don't know for sure.)

> -----Original Message-----
> From: Moore, Robert [mailto:robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
> Sent: Monday, May 19, 2003 12:46 PM
> To: Cagle, John (ISS-Houston); Kevin Fenzi; 
> acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: RE: Working around bugs in ACPI BIOS [was Re: [ACPI] 
> DSDT in initrd]
> 
> 
> 
> Why is it that only Compaq machines seem to use the asterisk? Bob
> 
> 
> > -----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
> 
> 
> -------------------------------------------------------
> 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/a> cpi-devel
> 


-------------------------------------------------------
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

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

[Grover, Andrew]

[-- Attachment #1: Type: text/plain, Size: 5563 bytes --]

Against 2.4-acpi-latest.

Completely untested. Does this work?

-- Andy

> -----Original Message-----
> From: Grover, Andrew 
> Sent: Monday, May 19, 2003 10:51 AM
> To: Cagle, John (ISS-Houston); Kevin Fenzi; 
> acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: RE: Working around bugs in ACPI BIOS [was Re: [ACPI] 
> DSDT in initrd]
> 
> 
> 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
> > 
> 
> 
> -------------------------------------------------------
> 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
> 

[-- Attachment #2: compaq.diff --]
[-- Type: application/octet-stream, Size: 525 bytes --]

===== drivers/acpi/bus.c 1.14 vs edited =====
--- 1.14/drivers/acpi/bus.c	Fri May 16 13:35:09 2003
+++ edited/drivers/acpi/bus.c	Mon May 19 11:46:08 2003
@@ -1508,6 +1508,12 @@
 		sprintf(device->pnp.device_class, "%s", ACPI_BUS_CLASS);
 	}
 
+	/* Compaq erroneously puts * in front of their HIDs on old BIOSes */
+	if (hid && *hid == '*') {
+		printk(KERN_DEBUG PREFIX "Ignoring * in _HID. Is this a Compaq?\n");
+		hid++;
+	}
+
 	if (hid) {
 		sprintf(device->pnp.hardware_id, "%s", hid);
 		device->flags.hardware_id = 1;

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

[Kevin Fenzi]

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

>>>>> "Andrew" == Andrew Grover <Grover> writes:

Andrew> Against 2.4-acpi-latest.  Completely untested. Does this work?

It appears to work fine here on my compaq presario 2800t. 

ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?
ACPI: Ignoring * in _HID. Is this a Compaq?

With the stock acpi-20030512-2.4.21-rc2.diff.gz patch + your patch
below eveything looks to work fine. Battery status, lid, pretty much
any function. 

Thanks, 

Andrew> -- Andy

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

iD8DBQE+yarw3imCezTjY0ERAljZAJ4scPAbCMgkIqQH6qRArgninl1c7gCfYvXd
ZtsNJGRCJPdEX4XhlDiX2/g=
=Kh0B
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
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

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

[Pavel Machek]

Hi!

> Against 2.4-acpi-latest.
> 
> Completely untested. Does this work?

Looks good except that I'd make it KERN_ERR. It is BIOS error after
all, it is *not* debugging message.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
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