RE: [PATCH] Add CONFIG_ACPI_RELAXED_AML option

RE: [PATCH] Add CONFIG_ACPI_RELAXED_AML option

[Grover, Andrew]

> From: Craig Whitmore [mailto:lennon-q3Ck4f9/EBK9koe0gwxAeg@public.gmane.org] 
> > > distributed in windows drivers.
> >
> > Continuing with this thread, would it make sense to be ACPI 
> compliant
> > but allow 'custom' dsdts to be passed to the acpi subsystem to allow
> > users to work around less than perfect implementations from
> > manufacturers.
> >
> 
> Just 1 question. What do the manufacturer's say when you tell 
> them they have
> a "broken" dsdt? Do they normally fix it? or give some excuse 
> in a reason
> why they won't fix it?

It varies. BIOS bugs exposed by Linux may be prioritized lower due to
Linux's market position in laptops. They also may not get attention if they
are on end-of-lifed machines, or rolled into a BIOS update only when enough
other bugs are fixed to justify a new BIOS's validation and release. (We may
*say* to them it is a trivial fix, but the only way to know if it breaks
Windows is for them to test it!)

There also isn't always a clear way to report BIOS bugs from end users.

On the upside, the things we're seeing are almost always obviously wrong and
easy to fix - it's just getting them to make the trivial change.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Custom Override for DSDT?

[Matthew Tippett]

Getting back to the original question, would it make sense to support a 
way of overriding a dsdt to allow a broken BIOS that the manufacturer 
won't fix be usable?

This still keeps standards based ACPI compliance but with the nice twist 
  that we don't have to rely entirely on the manufacturer for the BIOS 
to work.

Regards,

Matthew

Grover, Andrew wrote:
>>From: Craig Whitmore [mailto:lennon-q3Ck4f9/EBK9koe0gwxAeg@public.gmane.org] 
>>
>>>>distributed in windows drivers.
>>>
>>>Continuing with this thread, would it make sense to be ACPI 
>>
>>compliant
>>
>>>but allow 'custom' dsdts to be passed to the acpi subsystem to allow
>>>users to work around less than perfect implementations from
>>>manufacturers.
>>>
>>
>>Just 1 question. What do the manufacturer's say when you tell 
>>them they have
>>a "broken" dsdt? Do they normally fix it? or give some excuse 
>>in a reason
>>why they won't fix it?
> 
> 
> It varies. BIOS bugs exposed by Linux may be prioritized lower due to
> Linux's market position in laptops. They also may not get attention if they
> are on end-of-lifed machines, or rolled into a BIOS update only when enough
> other bugs are fixed to justify a new BIOS's validation and release. (We may
> *say* to them it is a trivial fix, but the only way to know if it breaks
> Windows is for them to test it!)
> 
> There also isn't always a clear way to report BIOS bugs from end users.
> 
> On the upside, the things we're seeing are almost always obviously wrong and
> easy to fix - it's just getting them to make the trivial change.
> 
> Regards -- Andy
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> 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:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

RE: Custom Override for DSDT?

[Grover, Andrew]

> From: Matthew Tippett [mailto:matthew-+XluyfkzffvQT0dZR+AlfA@public.gmane.org] 
> Getting back to the original question, would it make sense to 
> support a 
> way of overriding a dsdt to allow a broken BIOS that the manufacturer 
> won't fix be usable?
> 
> This still keeps standards based ACPI compliance but with the 
> nice twist 
>   that we don't have to rely entirely on the manufacturer for 
> the BIOS 
> to work.

We have this. Old documentation of the procedure is at
http://developer.intel.com/technology/iapc/acpi/bios_override.htm .

There is a new, easier way to do it, that various people have documented.
(Ducrot, perhaps?) We will be updating that URL with the new method at some
point, too.

It's good for debugging, or you highly motivated people, but obviously not
for a general solution.

Regards -- Andy





-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/