Re: RE: ACPI -- Workaround for broken DSDT

Re: RE: ACPI -- Workaround for broken DSDT

[Arjen Verweij]

> Indeed, I'm not confident that fixing DSDTs for vendors is always a good
> idea -- particularly if the vendors don't take the feedback.  I'd rather
> see Linux users able to vote with their dollars to support vendors that
> best support Linux.

What was that about Intel Centrino platforms and Linux :D

OK, that was below the belt maybe, sorry I couldn't resist. AFAIK Intel
has pledged to remedy the situation with a closed source driver and an
open source one over 8(?) months or so.

Arjen



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Scott T. Smith]

On Tue, 2004-02-03 at 23:22, Brown, Len wrote:
> > From Brown, Len on Sunday, 01 February, 2004:
> > >The vendor should supply a correct DSDT with their BIOS.
> > >In the case of Dell, you might inquire here: http://linux.dell.com/
> > >For non-vendor supplied solutions, you might also follow the 
> > DSDT link
> > >here: http://acpi.sourceforge.net/  
> > 
> > Hmm.  Do vendors generally release these?  I know Dell's very shaky on
> >   the Linux support front, at least for desktop/laptop.
> > Also, how do non-vendor supplied ones get made?  Seems like something
> >   you need NDA'ed docs for.
> 
> Non-vendor supplied DSDTs are created by end-users who bought machines
> that don't work.  Per the DSDT link above, one can extract,
> dis-assemble, modify a DSDT -- and tell Linux to use your copy instead
> of the version burned into PROM.

what's the long term strategy for ACPI on Linux?  If there are so many
broken DSDT's, and we want ACPI to be accessible to non-programmers,
then what's the ultimate solution?  Is it to include patches for every
possible platform, and have the ACPI subsystem autodetect and fix at
boot time?

Since thus far the ability to override the DSDT tables has not been
included in the vanilla ACPI distribution, then it seems you guys have
something else in mind.

What does Windows do?  Is it just that their DSDT
parser/executer/whatever operates differently (in which case a Windows
emulation mode could be added to the Linux subsystem), or is it that
Laptop manufacturers ship a corrected DSDT as part of their driver set?

	Scott



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Brown, Len]

The strategy is to improve ACPI on Linux such that all Linux distros are
able to successfully ship ACPI enabled kernels.

When we reach that stage, the OEMs will use these commercial Linux
products when they validate their platforms -- fixing DSDT problems
themselves before the 1st BIOS is released to the public.

Thus the long term strategy is for zero DSDT over-rides.

Re: what does windows do?
Windows doesn't have to do anything.  By being first to ship ACPI, that
implementation provided the defacto ACPI compliance test to which all
BIOS' are tested -- even if that implementation is not ACPI spec
compliant.  No, only under dire circumstances will we emulate Windows
bugs in Linux.

-Len

> -----Original Message-----
> From: Scott T. Smith [mailto:scott-j3vAvQ9dNB9ByuSxxbvQtw@public.gmane.org] 
> Sent: Wednesday, February 04, 2004 9:19 PM
> To: Brown, Len
> Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] RE: ACPI -- Workaround for broken DSDT
> 
> 
> On Tue, 2004-02-03 at 23:22, Brown, Len wrote:
> > > From Brown, Len on Sunday, 01 February, 2004:
> > > >The vendor should supply a correct DSDT with their BIOS.
> > > >In the case of Dell, you might inquire here: 
http://linux.dell.com/
> > >For non-vendor supplied solutions, you might also follow the 
> > DSDT link
> > >here: http://acpi.sourceforge.net/  
> > 
> > Hmm.  Do vendors generally release these?  I know Dell's very shaky
on
> >   the Linux support front, at least for desktop/laptop.
> > Also, how do non-vendor supplied ones get made?  Seems like
something
> >   you need NDA'ed docs for.
> 
> Non-vendor supplied DSDTs are created by end-users who bought machines
> that don't work.  Per the DSDT link above, one can extract,
> dis-assemble, modify a DSDT -- and tell Linux to use your copy instead
> of the version burned into PROM.

what's the long term strategy for ACPI on Linux?  If there are so many
broken DSDT's, and we want ACPI to be accessible to non-programmers,
then what's the ultimate solution?  Is it to include patches for every
possible platform, and have the ACPI subsystem autodetect and fix at
boot time?

Since thus far the ability to override the DSDT tables has not been
included in the vanilla ACPI distribution, then it seems you guys have
something else in mind.

What does Windows do?  Is it just that their DSDT
parser/executer/whatever operates differently (in which case a Windows
emulation mode could be added to the Linux subsystem), or is it that
Laptop manufacturers ship a corrected DSDT as part of their driver set?

	Scott



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Scott T. Smith]

On Wed, 2004-02-04 at 21:15, Brown, Len wrote: 
> The strategy is to improve ACPI on Linux such that all Linux distros are
> able to successfully ship ACPI enabled kernels.
> 
> When we reach that stage, the OEMs will use these commercial Linux
> products when they validate their platforms -- fixing DSDT problems
> themselves before the 1st BIOS is released to the public.

realistically, that's 3-5+ years away.  In the meantime, what are
existing users to do?  (i.e. those of us who don't like reading 430+
pages of the spec)

> Windows doesn't have to do anything.  By being first to ship ACPI, that
> implementation provided the defacto ACPI compliance test to which all
> BIOS' are tested -- even if that implementation is not ACPI spec
> compliant.  No, only under dire circumstances will we emulate Windows
> bugs in Linux.

So basically we shouldn't use ACPI then, and instead use APM?

If Linux ACPI could emulate the bugs that Windows has, then ACPI would
work on Linux on most platforms right away.  That would make Linux more
accessible to people.  Linux already has a bunch of hacks to support
broken hardware which presumably Windows can work around; this seems to
be just another one of those.

While it would be great if BIOS' used correct DSDT's, then what would
happen if those DSDT's didn't work on Windows?  Which version do you
think they'd ship?  Methinks not the one that works on Linux.

OTOH, what happens when Microsoft tries to fix their existing bugs --
they'll either stick with their buggy version forever, or have to
support several versions, depending on how many bugs are fixed and when
they are fixed.  Or you'll end up with some versions of Windows that
won't run on older or newer laptops.

Seems like a messy situation, any way you look at it.

	Scott



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Andi Kleen]

On Thu, 5 Feb 2004 00:15:36 -0500
"Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:


> 
> Re: what does windows do?
> Windows doesn't have to do anything.  By being first to ship ACPI, that
> implementation provided the defacto ACPI compliance test to which all
> BIOS' are tested -- even if that implementation is not ACPI spec

I don't think that's completely true. A lot of the DSDTs I looked 
at had special cases for Win98,Win2000,WinXP. Undoubtedly the next
windows versions will also require special cases in the AML.

Longer term all we can hope for is that the next generation of
BIOS will also have a case for Linux.

> compliant.  No, only under dire circumstances will we emulate Windows
> bugs in Linux.

A little bit more bug-to-bug compatibility surely couldn't hurt,
even when Microsoft isn't even compatible to themsevles.

Like we already have the RELAXED_AML mode and everybody enables it ... 
It just isn't often relaxed enough.

-Andi


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Brown, Len]

> On Wed, 2004-02-04 at 21:15, Brown, Len wrote: 
> > The strategy is to improve ACPI on Linux such that all 
> Linux distros are
> > able to successfully ship ACPI enabled kernels.
> > 
> > When we reach that stage, the OEMs will use these commercial Linux
> > products when they validate their platforms -- fixing DSDT problems
> > themselves before the 1st BIOS is released to the public.
> 
> realistically, that's 3-5+ years away.  In the meantime, what are
> existing users to do?  (i.e. those of us who don't like reading 430+
> pages of the spec)

Linux users should buy machines from OEMs that support Linux,
and not buy machines from OEMs that ignore Linux.  There are
OEMS that validate their platforms with Linux today -- this isn't
3-5 years away.

> So basically we shouldn't use ACPI then, and instead use APM?

If you have an old machine with APM and it satisfies your needs,
then continue using APM on that machine.  However, APM isn't
available on many systems today, and it will be available on
even fewer systems in the future.

> If Linux ACPI could emulate the bugs that Windows has, then ACPI would
> work on Linux on most platforms right away.  That would make 
> Linux more
> accessible to people.  Linux already has a bunch of hacks to support
> broken hardware which presumably Windows can work around; 
> this seems to
> be just another one of those.

Where the spec is vague and vendor's BIOS suggests that Microsoft
interprets the spec a certain way, we make linux work that way.  We also
have several places where we accommodate ACPI spec violations because
OEMs shipped them and Windows doesn't catch them -- but we complain
loudly when we see such errors -- otherwise next year's BIOS' will still
have the same errors...
 
> While it would be great if BIOS' used correct DSDT's, then what would
> happen if those DSDT's didn't work on Windows?  Which version do you
> think they'd ship?  Methinks not the one that works on Linux.

It isn't a choice between a Windows DSDT and a Linux DSDT.  An ACPI spec
compliant DSDT will run on both Windows and Linux.  Note also that ACPI
provides a mechanism where the it can behave differently depending on
the type and version of the OS.

> OTOH, what happens when Microsoft tries to fix their existing bugs --
> they'll either stick with their buggy version forever, or have to
> support several versions, depending on how many bugs are 
> fixed and when
> they are fixed.  Or you'll end up with some versions of Windows that
> won't run on older or newer laptops.

Yes, I expect that Microsoft will have to maintain certain bug
compatibilty or they will not be able to upgrade Windows on existing
platforms that contains those bugs.  Linux may or may not be able to run
ACPI on those platforms.  This isn't a deal killer, however, as Linux
never did run ACPI on those old platforms -- we don't even enable ACPI
for platforms older than Jan 1, 2001.  If they've run Linux w/o ACPI
since then, it is fine that they continue to do so.  The key is that
_new_ platforms should be ACPI spec compliant and validated with
ACPI-enabled Linux -- and as some Linux distros have enabled ACPI --
this is happening today.

Cheers,
-Len


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Luca Capello]

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

Hello,

on 02/05/04 09:10, Brown, Len wrote:
> Linux users should buy machines from OEMs that support Linux,
> and not buy machines from OEMs that ignore Linux.  There are
> OEMS that validate their platforms with Linux today -- this isn't
> 3-5 years away.
how can you tell this OEM supports Linux and that not? Is there
somewhere a list of such OEMs?

I mean, I've always had ASUS laptops and AFAIK ASUS supports Linux (it
seems you can buy a laptop with no XP preinstalled, this is not the case
in Italy). But the latest laptop I bought is an Intel Centrino one and
IIRC Intel supports Linux. Well, the Intel Centrino WiFi drivers/specs
are not available or not released yet or the Intel 82855GM has some
problems in switching LCD/CRT and in resume.

Mabye have I missed something?

Thx, bye,
Gismo / Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFAIgWvVAp7Xm10JmkRAhKRAJ9UBhgdJBo2LqXaVzk71NQrxWHhVwCff6cl
Rl8iTPKqgpXUNRCmXIEMfmw=
=hn1t
-----END PGP SIGNATURE-----


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bruno Ducrot]

On Wed, Feb 04, 2004 at 10:55:49PM -0800, Scott T. Smith wrote:
> On Wed, 2004-02-04 at 21:15, Brown, Len wrote: 
> > The strategy is to improve ACPI on Linux such that all Linux distros are
> > able to successfully ship ACPI enabled kernels.
> > 
> > When we reach that stage, the OEMs will use these commercial Linux
> > products when they validate their platforms -- fixing DSDT problems
> > themselves before the 1st BIOS is released to the public.
> 
> realistically, that's 3-5+ years away.  In the meantime, what are
> existing users to do?  (i.e. those of us who don't like reading 430+
> pages of the spec)

ACPI is multiplatfrom anyway, you really think that people will
install Windows on a Itanium or Opteron servers?  Good luck then
for the technical support of that vendor..

> 
> > Windows doesn't have to do anything.  By being first to ship ACPI, that
> > implementation provided the defacto ACPI compliance test to which all
> > BIOS' are tested -- even if that implementation is not ACPI spec
> > compliant.  No, only under dire circumstances will we emulate Windows
> > bugs in Linux.
> 
> So basically we shouldn't use ACPI then, and instead use APM?
> 
> If Linux ACPI could emulate the bugs that Windows has, then ACPI would
> work on Linux on most platforms right away.  That would make Linux more
> accessible to people.  Linux already has a bunch of hacks to support
> broken hardware which presumably Windows can work around; this seems to
> be just another one of those.
> 
> While it would be great if BIOS' used correct DSDT's, then what would
> happen if those DSDT's didn't work on Windows?  Which version do you
> think they'd ship?  Methinks not the one that works on Linux.
> 
> OTOH, what happens when Microsoft tries to fix their existing bugs --
> they'll either stick with their buggy version forever, or have to
> support several versions, depending on how many bugs are fixed and when
> they are fixed.  Or you'll end up with some versions of Windows that
> won't run on older or newer laptops.
> 

Simple.  When Windows 2000 or WindowsXP (I don't remember correctly
which one) came out, suddenly a lot of BIOS upgrades due
to ACPI incompatibility issues were made by most OEMs...

-- 
Bruno Ducrot

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


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bas Mevissen]

Brown, Len wrote:

> The strategy is to improve ACPI on Linux such that all Linux distros are
> able to successfully ship ACPI enabled kernels.
> 
> When we reach that stage, the OEMs will use these commercial Linux
> products when they validate their platforms -- fixing DSDT problems
> themselves before the 1st BIOS is released to the public.
> 
> Thus the long term strategy is for zero DSDT over-rides.
> 

Linux-ACPI will only become mainstream when it runs out-of-the-box on 
most computers. Until then, it will remain troublesome...

So the choice is to stick to the standard or to be smarter. Yes, it will 
not help fixing the DSDT's. But the only real solution to that is what 
I've written below.

> Re: what does windows do?
> Windows doesn't have to do anything.  By being first to ship ACPI, that
> implementation provided the defacto ACPI compliance test to which all
> BIOS' are tested -- even if that implementation is not ACPI spec
> compliant.  No, only under dire circumstances will we emulate Windows
> bugs in Linux.
> 

ACPI committee did not push a proper validation program. It's like the 
web "standards": standards are therem but everybody tests with IE and 
most web developers are satisfied when it works with it...

ACPI committee should make a proper validation mandatory before a 
computer may be sold as "ACPI X.Y compliant". Then manufacturers can 
test against (open) validation platform and Linux-ACPI can be validated 
against it too.

Bas.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bas Mevissen]

Andi Kleen wrote:


> I don't think that's completely true. A lot of the DSDTs I looked
> at had special cases for Win98,Win2000,WinXP. Undoubtedly the next
> windows versions will also require special cases in the AML.
> 
> Longer term all we can hope for is that the next generation of
> BIOS will also have a case for Linux.
> 

> A little bit more bug-to-bug compatibility surely couldn't hurt,
> even when Microsoft isn't even compatible to themsevles.
> 
> Like we already have the RELAXED_AML mode and everybody enables it ...
> It just isn't often relaxed enough.
> 

Yup, just emulate the latest version of bug-os :-)


Seriously, I think the only real solution is an independant 
qualification program. Vendors can then decide to add extra 
bug-compatibility for Win2k, WinXp and Linux too.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Cagle, John (ISS-Houston)]

Bas Mevissen wrote:
> 
> ACPI committee did not push a proper validation program. It's 
> like the 
> web "standards": standards are therem but everybody tests with IE and 
> most web developers are satisfied when it works with it...
> 
> ACPI committee should make a proper validation mandatory before a 
> computer may be sold as "ACPI X.Y compliant". Then manufacturers can 
> test against (open) validation platform and Linux-ACPI can be 
> validated 
> against it too.

This is a very good point, something for all of us to remember when
participating in any standards-creating process.

Also, if there were a Linux-ACPI standard validation suite, it would
make HP's Linux QA Engineers very happy, and much more likely to
find and fix ACPI AML errors *before* we ship new hardware.  Anyone
interested in working on something like that?

Regards,
John

-----------------------------
John Cagle  john.cagle-VXdhtT5mjnY@public.gmane.org
HP Distinguished Technologist
ProLiant Software Development
  http://www.hp.com/linux/
  Hewlett-Packard Company


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Andi Kleen]

On Thu, 5 Feb 2004 08:33:14 -0600
"Cagle, John (ISS-Houston)" <john.cagle-VXdhtT5mjnY@public.gmane.org> wrote:

> Bas Mevissen wrote:
> > 
> > ACPI committee did not push a proper validation program. It's 
> > like the 
> > web "standards": standards are therem but everybody tests with IE and 
> > most web developers are satisfied when it works with it...
> > 
> > ACPI committee should make a proper validation mandatory before a 
> > computer may be sold as "ACPI X.Y compliant". Then manufacturers can 
> > test against (open) validation platform and Linux-ACPI can be 
> > validated 
> > against it too.
> 
> This is a very good point, something for all of us to remember when
> participating in any standards-creating process.
> 
> Also, if there were a Linux-ACPI standard validation suite, it would
> make HP's Linux QA Engineers very happy, and much more likely to
> find and fix ACPI AML errors *before* we ship new hardware.  Anyone
> interested in working on something like that?

To guarantee parseable AML all you have to do is to compile the AML 
with the Intel AML compiler (available from the Intel ACPI website) 
This could be done from the source code or by just disassembling 
it (iasl -d DSDTdump) and then reassembling it. If it compiles it should be ok 
for the interpreter.

Of course that doesn't guarantee that Linux will work with it
(it could parse the tables incorrectly or not like something the
methods do when executed) but will catch at least some basic AML errors and 
do some static verifying.

-Andi



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Scott T. Smith]

On Thu, 2004-02-05 at 00:10, Brown, Len wrote:
> > On Wed, 2004-02-04 at 21:15, Brown, Len wrote: 
> > > The strategy is to improve ACPI on Linux such that all 
> > Linux distros are
> > > able to successfully ship ACPI enabled kernels.
> > > 
> > > When we reach that stage, the OEMs will use these commercial Linux
> > > products when they validate their platforms -- fixing DSDT problems
> > > themselves before the 1st BIOS is released to the public.
> > 
> > realistically, that's 3-5+ years away.  In the meantime, what are
> > existing users to do?  (i.e. those of us who don't like reading 430+
> > pages of the spec)
> 
> Linux users should buy machines from OEMs that support Linux,
> and not buy machines from OEMs that ignore Linux.  There are
> OEMS that validate their platforms with Linux today -- this isn't
> 3-5 years away.

That argument simply doesn't work for laptops (which seems to me to be
the main driving force behind ACPI, but I recognize ACPI is useful for
desktops too).  There are too many reasons to pick one machine over
another, including weight, size, price/performance, screen quality
(size/resolution), keyboard quality/layout/size, touchpad vs nipple,
etc.  In the end, it's a compromise of course, so it'd be nice if there
was one less constraint on my purchasing decision (i.e. ACPI).

	Scott



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bas Mevissen]

Cagle, John (ISS-Houston) wrote:

> Also, if there were a Linux-ACPI standard validation suite, it would
> make HP's Linux QA Engineers very happy, and much more likely to
> find and fix ACPI AML errors *before* we ship new hardware.  Anyone
> interested in working on something like that?
> 

I agree that it would help a lot of hardware and software manufacturers 
to validate their hardware. The funding part is more a problem then 
people interested to work on it. For example, I would love to work for 
it. :-)

Such suite would be a major undertaking. One needs a huge piece of 
hardware and software to test and validate software and hardware on/with.

To be successful, one also needs an independant, widely accepted (but 
industry-funded!) validation and certification organisation that can 
provide validation and certification for both hardware and software 
products.

BTW. I'm wondering if there are no such initiatives already because this 
problem is not really new.

Regards,

Bas.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bas Mevissen]

Andi Kleen wrote:

> 
> To guarantee parseable AML all you have to do is to compile the AML
> with the Intel AML compiler (available from the Intel ACPI website)
> This could be done from the source code or by just disassembling
> it (iasl -d DSDTdump) and then reassembling it. If it compiles it should be ok
> for the interpreter.
> 

That would at least mean that the interpreter would not have to deal 
with it at runtime. But it looks like a lot of DSDTs don't even pass 
that test...

How is the interpreter currently designed/behaving to cope with such 
situation?

> Of course that doesn't guarantee that Linux will work with it
> (it could parse the tables incorrectly or not like something the
> methods do when executed) but will catch at least some basic AML errors and
> do some static verifying.
> 

Maybe linux-acpi should first do a quick-scan on the DSDT and then 
decide in what "emulation-mode" it should go. Think of

* Simply good according ACPI-2.xxx spec -> follow the spec (ideal case)

* Special Linux-specific behaviour in DSDT -> do what the ACPI 
implementation of does at the moment (likely older BIOS that was tested 
on _some_ version of Linux-acpi)

* DSDT with behaviour customised for one or more Windows version -> 
emulate one of them (the latest version named?)

* Nothing -> just pick a windows emulation depending on BIOS date or 
other prior knowledge

Regards,

Bas.





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bas Mevissen]

Scott T. Smith wrote:
> 
>>Linux users should buy machines from OEMs that support Linux,
>>and not buy machines from OEMs that ignore Linux.  There are
>>OEMS that validate their platforms with Linux today -- this isn't
>>3-5 years away.
> 
> 
> That argument simply doesn't work for laptops (which seems to me to be
> the main driving force behind ACPI, but I recognize ACPI is useful for
> desktops too).  There are too many reasons to pick one machine over
> another, including weight, size, price/performance, screen quality
> (size/resolution), keyboard quality/layout/size, touchpad vs nipple,

I prefer the latter being called "Janet" from now on :-))

> etc.  In the end, it's a compromise of course, so it'd be nice if there
> was one less constraint on my purchasing decision (i.e. ACPI).
> 

The availibility of a fixed DSDT might help. At least you get a working 
notebook to write e-mails to the supplier that they should fix their DSDT.

I'm wondering if it is possible to overload the DSDT for Windows. Think 
of a hack in grub to pre-load another DSDT in RAM.

BIOS are compressed, so they need to be extracted to RAM. So changing it 
(eventualy only changing the pointer to a different location) should be 
possible.

Why would we need it? Simply to check a DSDT on Windows before 
submitting it to the manufacturer. That can ease acceptance of a DSDT-patch.

Regards,

Bas.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Andi Kleen]

On Thu, 05 Feb 2004 17:07:52 +0100
Bas Mevissen <ml-Y9IUUvl1dgU0Iwp8Nzs06g@public.gmane.org> wrote:

> Andi Kleen wrote:
> 
> > 
> > To guarantee parseable AML all you have to do is to compile the AML
> > with the Intel AML compiler (available from the Intel ACPI website)
> > This could be done from the source code or by just disassembling
> > it (iasl -d DSDTdump) and then reassembling it. If it compiles it should be ok
> > for the interpreter.
> > 
> 
> That would at least mean that the interpreter would not have to deal 
> with it at runtime. But it looks like a lot of DSDTs don't even pass 
> that test...
> 
> How is the interpreter currently designed/behaving to cope with such 
> situation?

The Intel interpreter is very strict (even with the relaxed aml option),
microsoft is very lax. That causes problems.

But interpreter problems are usually fairly easy to fix. The 
interpreter could be probably be made even more relaxed, but the 
maintainers (Len.et.al) don't seem to want to go that path so I don't see it 
happening.  They write the code, so it works like they want it.

It would not help that much anyways. 

The interpreter problems would be all easy to catch by QA
(even without actually booting linux). And also easy to fix
afterwards, just a bit time consuming.

The nasty problems are other logic bugs in parsing tables and interpreting 
results of methods. There doing the same thing as Windows is basically
impossible.

> > Of course that doesn't guarantee that Linux will work with it
> > (it could parse the tables incorrectly or not like something the
> > methods do when executed) but will catch at least some basic AML errors and
> > do some static verifying.
> > 
> 
> Maybe linux-acpi should first do a quick-scan on the DSDT and then 
> decide in what "emulation-mode" it should go. Think of
> 
> * Simply good according ACPI-2.xxx spec -> follow the spec (ideal case)
> 
> * Special Linux-specific behaviour in DSDT -> do what the ACPI 
> implementation of does at the moment (likely older BIOS that was tested 
> on _some_ version of Linux-acpi)
> 
> * DSDT with behaviour customised for one or more Windows version -> 
> emulate one of them (the latest version named?)
> 
> * Nothing -> just pick a windows emulation depending on BIOS date or 
> other prior knowledge

You're assuming that all interactions with ACPI are well understood.
But it's an extremly complex system hooking into all kinds of low level
parts of the kernel

(e.g. a lot of ACPI DSDT parsing behaviour doesn't actually come from
the ACPI subsystem code, but from the linux APIC and interrupt code)

Doing "ACPI behaviour emulations" would be impossible to maintain. It's already 
difficult enough to catch and test the various cases. ACPI problems at boot are usually
difficult to debug. Keeping it simple stupid is the only way to keep
it manageable. And the ACPI subsystem is already too complex.

Remember we're not talking about Mozilla here, but about an extremly
low level part of a kernel.

-Andi


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bas Mevissen]

Andi Kleen wrote:

> 
> The Intel interpreter is very strict (even with the relaxed aml option),
> microsoft is very lax. That causes problems.
> 
> But interpreter problems are usually fairly easy to fix. The
> interpreter could be probably be made even more relaxed, but the
> maintainers (Len.et.al) don't seem to want to go that path so I don't see it
> happening.  They write the code, so it works like they want it.
> 
> It would not help that much anyways.
> 
> The interpreter problems would be all easy to catch by QA
> (even without actually booting linux). And also easy to fix
> afterwards, just a bit time consuming.
> 

What about keeping the interpreter strict, but always before passing the 
DSDT to the interpreter, disassemble it and check it for problems. That 
"tester" should then be able to fix the most common problems. Then 
compile it again and pass it to the interpreter. Eventually a sort of 
intermediate language can be used that gives an easy to parse output.

Pro:
* Can fix common problems on the fly
* Can maintain a table of know defects (e.g. don't drive fan of notebook 
XXX)
* Can do all kinds of changes based upon command line options
* Parser code fast, clean and according to standard (verificatable!)
* "New" DSDT is very trustable, so less checking/conditional handling in 
rest of LL kernel code regarding ACPI
* APM -> ACPI "tranlation": write APM in ACPI-terms and get rid of APM 
code in kernel.
* Does not need to be kernel code -> easier to debug and less runtime-risk

Con:
* Boot time
* Maintenance
* Initrd size
* Development time

> The nasty problems are other logic bugs in parsing tables and interpreting
> results of methods. There doing the same thing as Windows is basically
> impossible.
> 

Why? Is that missing knowledge of what Windows does or is the Windows 
implementation too different?

> You're assuming that all interactions with ACPI are well understood.
> But it's an extremly complex system hooking into all kinds of low level
> parts of the kernel
> 
 > (snipped some explanation)

True. So maybe pre-examening is a way to keep the implementation as 
simple as it can be. You are right that having a dynamic behaviour of 
the linux-acpi is not the way to go.

So I think we need to have means to reshape the DSDT at runtime before 
interpreting it. It will definitely not catch all cases, but at least 
some of them.


Bas.





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Karol Kozimor]

Thus wrote Luca Capello:
> I mean, I've always had ASUS laptops and AFAIK ASUS supports Linux (it
> seems you can buy a laptop with no XP preinstalled, this is not the case

To my best knowledge, ASUS doesn't even recognize Linux's existence, at
least as far as laptops go. It probably just happens that they have decent
quality control and their DSDTs are somewhat decent as a result, though
their individual quality still varies. The following code sample, found in
most Centrino DSDTs makes iasl quite unhappy:
#v+
    If (SS1)
    {
        Name (_S1, Package (0x04)
        {
            0x02, 
            0x00, 
            0x00, 
            0x00
        })
    }
#v-

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: ACPI -- Workaround for broken DSDT

[Bruno Ducrot]

On Thu, Feb 05, 2004 at 08:33:14AM -0600, Cagle, John (ISS-Houston) wrote:
> Bas Mevissen wrote:
> > 
> > ACPI committee did not push a proper validation program. It's 
> > like the 
> > web "standards": standards are therem but everybody tests with IE and 
> > most web developers are satisfied when it works with it...
> > 
> > ACPI committee should make a proper validation mandatory before a 
> > computer may be sold as "ACPI X.Y compliant". Then manufacturers can 
> > test against (open) validation platform and Linux-ACPI can be 
> > validated 
> > against it too.
> 
> This is a very good point, something for all of us to remember when
> participating in any standards-creating process.
> 
> Also, if there were a Linux-ACPI standard validation suite, it would
> make HP's Linux QA Engineers very happy, and much more likely to
> find and fix ACPI AML errors *before* we ship new hardware.  Anyone
> interested in working on something like that?
> 

That may be a lot of time consuming for single individual like me that
need to work on complete different topic, or else I can not pay my
car for example.

Cheers,

-- 
Bruno Ducrot

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


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Nate Lawson]

On Wed, 4 Feb 2004, Scott T. Smith wrote:
> On Wed, 2004-02-04 at 21:15, Brown, Len wrote:
> > Windows doesn't have to do anything.  By being first to ship ACPI, that
> > implementation provided the defacto ACPI compliance test to which all
> > BIOS' are tested -- even if that implementation is not ACPI spec
> > compliant.  No, only under dire circumstances will we emulate Windows
> > bugs in Linux.
>
> So basically we shouldn't use ACPI then, and instead use APM?
>
> If Linux ACPI could emulate the bugs that Windows has, then ACPI would
> work on Linux on most platforms right away.  That would make Linux more
> accessible to people.  Linux already has a bunch of hacks to support
> broken hardware which presumably Windows can work around; this seems to
> be just another one of those.

We're doing something slightly different with ACPI on FreeBSD.  We add
hacks^Wworkarounds for buggy DSDT whenever possible but they are under a
kernel option, #ifndef ACPICA_PEDANTIC.  The default is for this option to
give maximum compatibility with the stock DSDT, at the expense of spec
correctness.  However, by adding that option and compiling a kernel, OEMs
could test against ACPI-CA as a reference implementation while ordinary
users get maximum compatibility.

I think the ACPI-CA developers should take a similar tact.  Len, who is on
the Linux side, could suggest distribution maintainers use the option that
gives maximum Windows compatibility when shipping a distro.  Bob, who is
on the ACPI-CA side, could encourage OEMs to test with the option
disabled.  It might even make sense for a Linux distro maintainer to
partner with ACPI-CA to provide a reference ISO that OEMs could boot that
had a /sbin/init that tests the various APIs for correctness.  Both Andy
and I thought this was a good direction to go and perhaps people are
already making progress in that area.

-Nate


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Len Brown]

On Mon, 2004-02-09 at 15:29, Nate Lawson wrote:
> On Wed, 4 Feb 2004, Scott T. Smith wrote:
> > On Wed, 2004-02-04 at 21:15, Brown, Len wrote:
> > > Windows doesn't have to do anything.  By being first to ship ACPI, that
> > > implementation provided the defacto ACPI compliance test to which all
> > > BIOS' are tested -- even if that implementation is not ACPI spec
> > > compliant.  No, only under dire circumstances will we emulate Windows
> > > bugs in Linux.
> >
> > So basically we shouldn't use ACPI then, and instead use APM?
> >
> > If Linux ACPI could emulate the bugs that Windows has, then ACPI would
> > work on Linux on most platforms right away.  That would make Linux more
> > accessible to people.  Linux already has a bunch of hacks to support
> > broken hardware which presumably Windows can work around; this seems to
> > be just another one of those.
> 
> We're doing something slightly different with ACPI on FreeBSD.  We add
> hacks^Wworkarounds for buggy DSDT whenever possible but they are under a
> kernel option, #ifndef ACPICA_PEDANTIC.  The default is for this option to
> give maximum compatibility with the stock DSDT, at the expense of spec
> correctness.  However, by adding that option and compiling a kernel, OEMs
> could test against ACPI-CA as a reference implementation while ordinary
> users get maximum compatibility.
>
> I think the ACPI-CA developers should take a similar tact.  Len, who is on
> the Linux side, could suggest distribution maintainers use the option that
> gives maximum Windows compatibility when shipping a distro.  Bob, who is
> on the ACPI-CA side, could encourage OEMs to test with the option
> disabled.  It might even make sense for a Linux distro maintainer to
> partner with ACPI-CA to provide a reference ISO that OEMs could boot that
> had a /sbin/init that tests the various APIs for correctness.  Both Andy
> and I thought this was a good direction to go and perhaps people are
> already making progress in that area.

I agree 100% with this strategy, Nate.  The users and the OSDs just want
it to work.  The OEMs should have an option to make it into a better
platform test.  Based on the questions I get today, educating the OEMs
to use something other than the stock distro off the shelf, however, is
harder than you might think.  Maybe having the dedicated test ISO is a
good idea.  We'd discussed this in the past, and one benefit is that it
would never be confused with the distro.

Mgr: Did the Linux ACPI Compliance test pass?
Tester: Yes, we booted Red Hat, SuSE, etc
Mgr: No, I said the Linux-based ACPI Compliance Test...

This strategy, however is not incomplete.  The Linux OSDs need to sign
up as ACPI Adopters.  Linux OSDs should have both advanced knowledge and
direct impact on what is being written into the ACPI spec.  Today they
have neither.

-Len




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: ACPI -- Workaround for broken DSDT

[Yu, Luming]

  To AML issue, I think we should sort out interpreter bug , not just
hack DSDT.

--Luming

> We're doing something slightly different with ACPI on FreeBSD.  We add
> hacks^Wworkarounds for buggy DSDT whenever possible but they 
> are under a
> kernel option, #ifndef ACPICA_PEDANTIC.  The default is for 
> this option to
> give maximum compatibility with the stock DSDT, at the expense of spec
> correctness.  However, by adding that option and compiling a 
> kernel, OEMs
> could test against ACPI-CA as a reference implementation 
> while ordinary
> users get maximum compatibility.
> 
> I think the ACPI-CA developers should take a similar tact.  
> Len, who is on
> the Linux side, could suggest distribution maintainers use 
> the option that
> gives maximum Windows compatibility when shipping a distro.  
> Bob, who is
> on the ACPI-CA side, could encourage OEMs to test with the option
> disabled.  It might even make sense for a Linux distro maintainer to
> partner with ACPI-CA to provide a reference ISO that OEMs 
> could boot that
> had a /sbin/init that tests the various APIs for correctness. 
>  Both Andy
> and I thought this was a good direction to go and perhaps people are
> already making progress in that area.
> 


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

ACPI_STRICT_COMPLIANCE (was RE: RE: ACPI -- Workaround for broken DSDT)

[Len Brown]

On Mon, 2004-02-09 at 15:29, Nate Lawson wrote:

> We're doing something slightly different with ACPI on FreeBSD.  We add
> hacks^Wworkarounds for buggy DSDT whenever possible but they are under a
> kernel option, #ifndef ACPICA_PEDANTIC.  The default is for this option to
> give maximum compatibility with the stock DSDT, at the expense of spec
> correctness.  However, by adding that option and compiling a kernel, OEMs
> could test against ACPI-CA as a reference implementation while ordinary
> users get maximum compatibility.
> 
> I think the ACPI-CA developers should take a similar tact.  Len, who is on
> the Linux side, could suggest distribution maintainers use the option that
> gives maximum Windows compatibility when shipping a distro.  Bob, who is
> on the ACPI-CA side, could encourage OEMs to test with the option
> disabled.  It might even make sense for a Linux distro maintainer to
> partner with ACPI-CA to provide a reference ISO that OEMs could boot that
> had a /sbin/init that tests the various APIs for correctness.  Both Andy
> and I thought this was a good direction to go and perhaps people are
> already making progress in that area.

Nate,
I think you're right, practical compatibility must be the default, and a
single config option should allow an OEM to disable the out-of-spec
warnings and workarounds.

CONFIG_ACPI_STRICT_COMPLIANCE seems to be a good choice for the config
option.  Disabled by default, enabled by OEMs for testing their
platforms.

Right now, CONFIG_ACPI_RELAXED AML would be replaced by this.  This will
fix the issue that RELAXED_AML is not currently enabled by default.

We have some warnings and workarounds that gum-up various dmesg that I
think we can put under this umbrella also.

thanks,
-Len




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI_STRICT_COMPLIANCE (was RE: RE: ACPI -- Workaround for broken DSDT)

[Nate Lawson]

On Wed, 11 Feb 2004, Len Brown wrote:
> Nate,
> I think you're right, practical compatibility must be the default, and a
> single config option should allow an OEM to disable the out-of-spec
> warnings and workarounds.
>
> CONFIG_ACPI_STRICT_COMPLIANCE seems to be a good choice for the config
> option.  Disabled by default, enabled by OEMs for testing their
> platforms.
>
> Right now, CONFIG_ACPI_RELAXED AML would be replaced by this.  This will
> fix the issue that RELAXED_AML is not currently enabled by default.
>
> We have some warnings and workarounds that gum-up various dmesg that I
> think we can put under this umbrella also.

Sounds good to me.  Just watch out for hacks that cause valid platforms to
misbehave.  Those should be kept under an off-by-default option.

-Nate


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: RE: ACPI -- Workaround for broken DSDT

[Bruno Ducrot]

On Mon, Feb 09, 2004 at 12:29:45PM -0800, Nate Lawson wrote:
> On Wed, 4 Feb 2004, Scott T. Smith wrote:
> > On Wed, 2004-02-04 at 21:15, Brown, Len wrote:
> > > Windows doesn't have to do anything.  By being first to ship ACPI, that
> > > implementation provided the defacto ACPI compliance test to which all
> > > BIOS' are tested -- even if that implementation is not ACPI spec
> > > compliant.  No, only under dire circumstances will we emulate Windows
> > > bugs in Linux.
> >
> > So basically we shouldn't use ACPI then, and instead use APM?
> >
> > If Linux ACPI could emulate the bugs that Windows has, then ACPI would
> > work on Linux on most platforms right away.  That would make Linux more
> > accessible to people.  Linux already has a bunch of hacks to support
> > broken hardware which presumably Windows can work around; this seems to
> > be just another one of those.
> 
> We're doing something slightly different with ACPI on FreeBSD.  We add
> hacks^Wworkarounds for buggy DSDT whenever possible but they are under a
> kernel option, #ifndef ACPICA_PEDANTIC.  The default is for this option to
> give maximum compatibility with the stock DSDT, at the expense of spec
> correctness.  However, by adding that option and compiling a kernel, OEMs
> could test against ACPI-CA as a reference implementation while ordinary
> users get maximum compatibility.
> 
> I think the ACPI-CA developers should take a similar tact.  Len, who is on
> the Linux side, could suggest distribution maintainers use the option that
> gives maximum Windows compatibility when shipping a distro.  Bob, who is

I strongly discourage that a Linux distribution maintainer will take a kind of
ownership for qualifiyng that say system is compatible with their
distro.  For my 'real' work, we have to work with some distribution that
is somehow 'qualified' for say software, or say hardware driver, even
though that do not make sense.  For example, if you want to install, and
qualify, Oracle under Linux, you have *no choice* for the distribution
to be used.

-- 
Bruno Ducrot

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


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click