Re: [patch 2/2] [PATCH 2/2] ACPI: generic initramfs table override support #3

[Jeff Mahoney <jeffm@suse.com>]

On 10/10/2009 10:43 AM, Matthew Garrett wrote:
> On Sat, Oct 10, 2009 at 10:32:10AM -0400, Jeff Mahoney wrote:
> 
>> I agree. In an ideal world this would be unnecessary. It's true that
>> ACPI bugs have become must less common than they used to be but I think
>> users would prefer their machines be usable while the ACPI developers
>> are diagnosing why they need a workaround in the first place.
> 
> If that were the tradeoff then I'd be happy, but what tends to happen is 
> that the section of users who are able to help us debug just work around 
> it instead and the ones who have no idea how to report a bug end up with 
> broken machines.

Well then maybe the answer is to make it complain loudly that it's a bug
that is being worked around. More than just the taint message. Perhaps
even an autogenerated report on the DSDT if it's overridden to be sent
at the user's discretion. There has to be a middle ground here. Most
distros don't backport minor ACPI fixes for their maintenance kernels.
So it's great that it would get fixed in the next release, but it still
leaves the user out in the cold in the meantime. Sometimes it's the
temperature or battery usage getting misreported. Other times it means
the user can't suspend or a docking station won't work.

>> In some cases it's just that the MS AML compiler is just so much more
>> lax than the Intel one. I had a notebook where I had to extract, fix,
>> and rebuild my DSDT and then it worked fine. Without the ability to
>> override it, I would've been stuck.
> 
> For a user who can do these fixups themselves, it's easy enough to 
> rebuild a kernel with the DSDT override. However, pretty much every 
> recent ACPI bug I've seen has had nothing to do with the MS compiler's 
> less strict error checking - we run the in-kernel interpreter in a lax 
> mode that's intended to be bug for bug compatible with the Microsoft 
> one.

Sure, it was a few years ago and things have changed. It was just an
example of how it fixed my system. I've seen several openSUSE bug
reports that get fixed by replacing the DSDT. And yes, I do assign those
bugs to our ACPI developers for actual fixing.

The thing is that there are sites out there that provide fixed DSDTs so
users don't actually have to go through the effort of extracting,
fixing, and rebuilding themselves. Even if they did have to do that,
building your own kernel to fix your DSDT kicks you right out of the
maintenance stream of your distro. So then they're stuck between
rebuilding the kernel at every update or losing security fixes. Neither
sound particularly fun.

-Jeff

-- 
Jeff Mahoney
SUSE Labs