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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
