Comment 52 for bug 395239

I have a number of machines that all have different problems which require custom DSDTs. With the latest kernels none of these machines work any more. 1) An Asus A8V-Deluxe Socket 939 motherboard with Opteron 185 CPU. Asus stopped providing updated BIOS images for this machine years ago, and it doesn't have PowerNow support for this CPU. I wrote a custom DSDT for this machine to enable PowerNow and define the various P-states that should be supported. Without the custom DSDT this machine is always running at full power / full speed. (I updated this machine to Karmic last week, previously it was running OpenSuSE. I guess I should have stuck with SuSE.) 2) An Asus M6Ne laptop with dual batteries. A bug in the DSDT causes it to misreport the number of batteries, so battery monitoring doesn't work. There were kernel fixes to ignore the bogus ACPI result codes, but without the patched DSDT the reported battery status is usually wrong / unreliable. And again, this is an old enough machine that Asus ignores all requests to release a patched BIOS.
3) An HP dv5z laptop with multiple Windows-dependent checks in its DSDT. It misreports its thermal parameters for any OS besides Vista. On Linux the result is that the thermal zone module simply fails to load, so CPU temperature monitoring is completely disabled. This is a pretty critical problem on this laptop because the thermal design is so poor and the machine regularly overheats if left unmonitored. This laptop is just over a year old and again, HP doesn't acknowledge that there is any bug and won't release any BIOS updates to address the issue.

The fact is, manufacturers sell shoddy hardware and that's the real world. No amount of cajoling gets them to fix their crap, and it's not worth my time to wait on Hold on their support phone lines to be switched from one non-responsive support person to another over and over again. Compiled in DSDTs are a terrible solution because of the update hassle. Runtime DSDT loading solves the problem and it's obviously something that's already well understood. Maybe in Linus' perfect world manufacturers would listen to end-user complaints, but that's not the real world. Individual users have exactly zero power to cause any improvement in this situation, it will only happen when some large organization with a lot of money and the ability to affect all of the OEMs' incomes makes an issue out of it. In the meantime, this workaround is the most expedient way forward.