RE: RE: ACPI -- Workaround for broken DSDT

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

[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

[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

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