[karmic] 2.6.31 kernel does not load custom DSDT

[MyName]

Binary package hint: linux-image

Current kernel doas not load custom (fixed) DSDT.aml

Kernel: 2.6.31-1-generic

$ /etc/initramfs-tools/DSDT.aml
$ sudo update-initramfs -u

reboot

$ dmesg | grep DSDT
[ 0.000000] ACPI: DSDT 4ff76dcd 05105 (v01 INTEL ODEM 06040000 MSFT 0100000E)
[ 0.078585] ACPI: EC: Look up EC in DSDT

(stop modify my description!)

[Dominic Evans (oldmanuk)]

Same problem. Regression from earlier kernels which did correctly load the DSDT.aml

$ sudo md5sum /proc/acpi/dsdt /etc/initramfs-tools/DSDT.aml
a0ead294bc1ddf95e80aea9cb4c36a6f /proc/acpi/dsdt
dea0dba40bee9ce0c007061d4dfba574 /etc/initramfs-tools/DSDT.aml

[Dominic Evans (oldmanuk)]

e.g., was previously enabled in bug 246222 for intrepid

[tannalv (gandkri)]

Well, according to http://<email address hidden>/8811841.html Linus Torvalds took out the part of the code that made us able to add custom DSDT-tables to our initramfs.

"ACPI: Remove ACPI_CUSTOM_DSDT_INITRD option

...ACPI code should either run much later, or this shouldn't be done at all.
For 2.6.25, we'll just pick the latter option. We can revisit this concept later if necessary."

So it's some ubuntu-guys sitting behind this all creating special patches for the kernels so they do what Linus doesn't want them to do?
Anyways, I'm hoping for a working DSDT-in-initramfs-patchable kernel soon.
The fan on my laptop always stays on otherwise. It's annoying.
Please do this soon. It shouldn't be more than a minor patch after all..?

[67GTA (67gta)]

The kernel devs don't add the DSDT patch until the final release. Ben Collins usually adds this patch himself despite Linus's thoughts. My question is will this patch continue to be added to 2.6.31 and future kernels? The Arch devs have axed it as of 2.6.30 citing bugs with the patch. You can no longer load a custom DSDT with Arch unless you compile your own kernel.

[67GTA (67gta)]

The custom dsdt patch will be removed for 2.6.31 and future kernel versions. You are urged to file bug reports for your specific problems that causes the need for a custom dsdt. The only alternative for 2.6.31 and on is to compile a custom kernel with the patch yourself.

[67GTA (67gta)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090730 SUSE/3.5.2-2.4 Firefox/3.5.2

Opensuse 11.2 milestone 6, kernel 2.6.31. I just installed today, and tried loading my custom DSDT required to have CPU temps seen due to a buggy DSDT. The kernel is no longer loading, or even looking for a DSDT file according to dmesg output.

Reproducible: Always

Steps to Reproduce:
1.Add path to custom DSDT in Yast /etc/sysconfig Editor
2.Reboot
3.Dmesg output shows kernel is not looking for DSDT file.
Actual Results:
Same as above.

Expected Results:
Loaded custom DSDT and bypass original.

[Johannes Frank (jmfrank)]

Well,

I've got a ASUS A6km notebook, and the only way to get it boot from usb-stick is loading a custom DSDT table. Now that the patch is removed I cannot boot with any usb-devices attached. I'm currently digging into creating a custom kernel, but that leaves me out to security patches. The situation is unpleasant. Is there a way out of this?

[67GTA (67gta)]

Unfortunately, no. You will have to recompile your custom kernel with the security patches as they come out. The easiest alternative I've seen is kernelcheck. It will show newer kernel versions and patches. It basically does everything for you. I will probably use this with 9.10, or until my DSDT bugs get fixed. There is a .deb file on the downloads page.

http://kcheck.sourceforge.net/

[Jeffm-novell (jeffm-novell)]

Yes, that patch needs to be forward ported to 2.6.31 still. Thanks for the reminder.

[Jeffm-novell (jeffm-novell)]

I've identified why the patch crashes. It's because we allocate memory for the table as part of the early kernel initialization - and it's before the SLAB caches have been initialized.

[Jeffm-novell (jeffm-novell)]

Created an attachment (id=318740)
Updated patch version

This patch delays the DSDT overriding from acpi_boot_table_init() until acpi_early_init(), where it used to be overridden. This is still before any initcalls are made, so it should be safe. Unfortunately, I needed to open code some chunks and it's sort of hacky.

[Jeffm-novell (jeffm-novell)]

Created an attachment (id=318741)
The diff against the original patch to isolate the changes.

[Jeffm-novell (jeffm-novell)]

Thomas, can you take a look at this when you get a chance? I think it should be safe, but I'll defer to your expertise.

[Trenn-novell (trenn-novell)]

I try to find time at the beginning of next week.
Eric, the maintainer of the patch (cmp. with http://gaugusch.at/kernel.shtml) might also want to have a look at this one.

[67GTA (67gta)]

Let me know if you need any testing done. I have a milestone 7 test partition on the affected machine. I really appreciate you taking the time to look at this:-)

[Trenn-novell (trenn-novell)]

I think I got it...
If this works, great. I doubt it can break anything as the relevant parts (delete previously fetched DSDT) only gets active if there is a table found which means the system is tainted anyway :)

Will you commit that one? Is there still time for 11.2?

[Jeffm-novell (jeffm-novell)]

Committed.

[Jkosina (jkosina)]

The patch has been disabled again, as it causes oops, please see bug #542767.

[Trenn-novell (trenn-novell)]

Maintaining the "Overriding DSDT via initrd" patch is cumbersome and it may possibly miss in 11.2.
Alternative is to compile the DSDT into a selfcompiled kernel.
Even better:
What exactly do you need the DSDT override for?
Has this already been discussed as "unfixable" or is it worth looking at the problem and find a fix or workaround?

[67GTA (67gta)]

The kernel can't read the CPU temps because of a buggy DSDT. This causes the laptop to run hotter than normal. I don't get shutdowns with Opensuse, but do with Ubuntu. I filed a bug here for Ubuntu: https://bugs.launchpad.net/opensuse/+source/linux/+bug/412167 If you think this can be fixed at the kernel level, I will recreate the bug here.

[Trenn-novell (trenn-novell)]

Your problem can be workarounded much easier in several ways.
Hmm, on the other hand I do not see what it should fix. Only behavior which may change is that you get an OS triggered proper shutdown instead of a hard power off switch triggered by the CPU.

Let me first describe your problem, so that I do not mix up anything:
The problem you are referring to is described in detail here:
https://wiki.edubuntu.org/LaptopTestingTeam/HPdv5z

What is done here is that a hot and a critical trip point is always exposed to the Operating System. In Linux the hot trip point isn't used, when the critical trip point is exceeded, the machine will shut down.
The critical trip point (similar to hot, but for other OSes) is only exposed on *older* Windowses, in your case it's always exposed but not for "Windows 2006" (e.g. for Windows 2001 SP1/SP2 and others).
I expect the fix on your DSDT looks like (adding the comments):
Name (TPC, 0x5F)
                Method (_CRT, 0, Serialized)
                {
// If (LLess (OSYS, 0x07D6))
// {
                        Return (Add (0x0AAC, Multiply (TPC, 0x0A)))
// }
                }
If you do exactly the same as described here: https://wiki.edubuntu.org/LaptopTestingTeam/HPdv5z
The critical temp which gets calculated and exposed to OS is 95 C.
If you force (this is what gets done?) to expose the critical thermal trip point to the OS/kernel, this will cause the kernel to shut down your machine if a temperature read (correct or incorrect!) at 95 C or above.

Therefore I do not fully understand what this should fix. Only that you may get a proper done, clear shut down initiated by the OS, instead of a hard power switch of by HW on higher temperatures (there always is a HW driven emergency thermal power off limit).

Also be aware that the OS string changed several times the last years.
For example latest kernel does not expose itself anymore as "Linux", but for some time the "Windows 2006" string got added. Therefore I expect with our current kernel you should not see the a critical trip point anymore.
Possibly this is what you want (and what you have done?) which may avoid (OS triggered) shut downs.
But the DSDT patching to get this behavior would also include to comment out:
                        Return (Add (0x0AAC, Multiply (TPC, 0x0A)))

But Ubuntu (depending on the kernel version) may only expose "Windows 2001 SP1/SP2" strings, therefore you get a critical trip point there.

[Jeroen-studiowolff (jeroen-studiowolff)]

Hi, i'm Jeroen Wolff form the Netherlands.
I've got the same problems. I want to use my own DSDT binary during startup.
This is becuase my fan on Compaq 8510p is blowing a lot!!
With the DSDT fix i've managed to lower de temperature setting for the fan to start blowing.
On openSUSE 11.1 i could make it work with tools like iasl (see http://forums.opensuse.org/new-user-how-faq-read-only/unreviewed-how-faq/386054-how-fix-your-buggy-dsdt.html)
Now on 11.2 i have to do it via the mkinitrd....but no luck so far.
What can i do?

[Jeroen-studiowolff (jeroen-studiowolff)]

I've build a new kernel with my patched DSDT file.

CONFIG_ACPI_CUSTOM_DSDT_FILE="/etc/acpi/DSDT.hex"
CONFIG_ACPI_CUSTOM_DSDT=y

Now i've got myself a quiter laptop. But it would be nice that it can be done without a kernel build.

[Len Brown (len-brown)]

Note that if you are going to build a kernel from scratch,
that the CONFIG_ACPI_CUSTOM_DSDT method continues
to be available, and does not require patching kernel source:

http://lesswatts.org/projects/acpi/overridingDSDT.php

[Jeffm-novell (jeffm-novell)]

I have an alternate patch that I hope to include in 11.2 now. But, given the regression the last patch introduced, I'd appreciate some testing. I'll post a link to a test kernel later today.

[Jeffm-novell (jeffm-novell)]

I've posted test packages at http://ftp.suse.com/pub/people/jeffm/suse/testpkgs/533555

It may take several minutes to them to sync out. When you get a chance, can you boot the one for your system?

[67GTA (67gta)]

I installed the packages for i586, but still not looking for DSDT per dmesg output. I was going to attempt to add dsdt anyway, but initramfs-add-dsdt.sh is missing from /usr/src/linux/Documentation/acpi.

[Jeffm-novell (jeffm-novell)]

That's the documentation for a generic kernel patch. For openSUSE, you'll want to change $ACPI_DSDT in /etc/sysconfig/kernel (to point to a valid DSDT) and then re-run mkinitrd.

[67GTA (67gta)]

I added the path to the custom DSDT.aml in etcsysconfig and ran mkinitrd.
Still no sign of looking for or loading DSDT per dmesg. I extracted the DSDT from /proc and still shows MSFT for the compiler ID. It just isn't inserting the custom DSDT.

Kernel image: /boot/vmlinuz-2.6.31.3-2-desktop
Initrd image: /boot/initrd-2.6.31.3-2-desktop
cp: cannot stat `/etc/scsi_id.config': No such file or directory
Root device: /dev/disk/by-id/ata-SAMSUNG_HD501LJ_S10NJ1MP700177-part4 (/dev/sda4) (mounted on / as ext4)
Resume device: /dev/disk/by-id/ata-SAMSUNG_HD501LJ_S10NJ1MP700177-part2 (/dev/sda2)
ACPI DSDT: /home/shawnr/DSDT.aml
Kernel Modules: thermal_sys thermal sata_nv pata_amd ata_generic ide-core amd74xx ide-pci-generic processor fan crc16 jbd2 ext4
Features: block usb resume.userspace resume.kernel
Bootsplash: openSUSE (1280x1024)
30018 blocks

Original Table Header:
 * Signature "DSDT"
 * Length 0x00005B41 (23361)
 * Revision 0x01 **** ACPI 1.0, no 64-bit math support
 * Checksum 0xCD
 * OEM ID "HPQOEM"
 * OEM Table ID "SLIC-CPC"
 * OEM Revision 0x00001000 (4096)
 * Compiler ID "MSFT"
 * Compiler Version 0x0100000E (16777230)

[Jeffm-novell (jeffm-novell)]

Can you provide your dmesg output and the results of grep INITRAMFS /proc/config.gz?

[67GTA (67gta)]

Created an attachment (id=322295)
Config/dmesg output

DSDT in config is empty??

[Jeffm-novell (jeffm-novell)]

Ugh. Of course it's not working. I split the patch into two and forgot one of them. Sorry.

[Jeffm-novell (jeffm-novell)]

I've posted a new test build at http://ftp.suse.com/pub/people/jeffm/suse/testpkgs/533555-2

[67GTA (67gta)]

Success!!! Dmesg output shows DSDT is loaded. DSDT from proc is my custom one. I can't thank you enough. There are a lot of pissed off people testing Ubuntu 9.10 right now that can't use their custom DSDT's I built for them. Would it be possible to incorporate this patch into a third party Ubuntu kernel? I have several offers to host/package a kernel if someone managed to fix the patch.

linux-opzd:/home/shawnr # dmesg | grep DSDT
[ 0.000000] ACPI: DSDT bbee3180 05B41 (v01 HPQOEM SLIC-CPC 00001000 MSFT 0100000E)
[ 0.142400] ACPI: Override [DSDT-SLIC-CPC], this is unsafe: tainting kernel
[ 0.142404] ACPI: DSDT f5060000 05230 (v01 HPQOEM SLIC-CPC 00001000 INTL 20081204)
[ 0.232636] ACPI: EC: Look up EC in DSDT

Original Table Header:
 * Signature "DSDT"
 * Length 0x00005230 (21040)
 * Revision 0x01 **** ACPI 1.0, no 64-bit math support
 * Checksum 0xFA
 * OEM ID "HPQOEM"
 * OEM Table ID "SLIC-CPC"
 * OEM Revision 0x00001000 (4096)
 * Compiler ID "INTL"
 * Compiler Version 0x20081204 (537399812)

[67GTA (67gta)]

I filed a bug for Opensuse as well. They have patched the kernel for 11.2. I am using my custom DSDT on 11.2 RC1 right now. Looks like Opensuse will be the only distro to have custom DSDT support without recompiling your kernel every time a security update comes out.

https://bugzilla.novell.com/show_bug.cgi?id=533555

[raphael (raaa)]

HI,

I could apply the 2.6.30 acpi-dsdt-initrd Patch from http://gaugusch.at/kernel.shtml to latest Karmic Kernel.

It works:

[ 0.026350] ACPI: Checking initramfs for custom DSDT
[ 0.307090] ACPI: Found DSDT in DSDT.aml.
[ 0.307099] ACPI: Override [DSDT-ODEM ], this is unsafe: tainting kernel
[ 0.307108] ACPI: Table DSDT replaced by host OS

[krantix (krantix)]

running 2.6.31-14-generic

on a toshiba laptop which needs custom DSDT to avoid overheating of NVIDIA card...

since my custom DSDT won't load I won't be able to use karmic if not with acpi=off.

This is really disappointing.

[krantix (krantix)]

raphael how did you apply the patch? thanks!

[Krastanov (krastanov-stefan)]

I was told that the new policy about DSDT bugs it to fix them in the kernel as custom DSDT are dangerous for new users. Have you found/opened a bug report about that overheating of yours? I was plagued by similar bug (for few years) but after making some noise (especially with that new policy) some devs started working on it.
And the functionality for loading DSDTs is still in the code - it's just deselected when compiling. Here you can find how to build a kernel - you can use the ubuntu kernel, the vanilla one or zen... https://wiki.ubuntu.com/ZenKernel When configuring just select custom dsdt loading.
I will mark the bug as invalid because of the new policy.

[krantix (krantix)]

I think the value of having a custom dsdt in this transition phase is higher.

Some people may not even notice and burn their GPU cards for this reason. Not really a great strategy to foster adoption. If I had knew this before I would have NEVER upgraded to 9.10.

[Krastanov (krastanov-stefan)]

Well, I rather agree with you. The other side of the coin is that the crappy DSDT supplied by the manufacture is the reason to have those problems.
At least you can remedy your problems booting with acpi=off and compiling a kernel.
I urge you to file a bug report with all the screaming tags you can think of. If someone from the devs knew about the problem, a fast fix should be already present.

[krantix (krantix)]

thanks Krastanov. Next time I won't buy Toshiba for sure, I've been writing on the toshiba support forum since the very beginning of this (2 years ago), but they couldn't care less.

[krantix (krantix)]

after recent upgrades, GPU temperature seems to work fine, but audio does not work anymore. The custom dsdt fixed both audio and temperature problems.

[SnZ (spthcl-deactivatedaccount)]

same problem here. I have ASUS A6km and ubuntu was only working with this fixed DSDT: http://acpi.sourceforge.net/dsdt/view.php?id=890

But i can't add this to kernel. Maybe anybody will help?

[Krastanov (krastanov-stefan)]

For bugs due to bad DSDT shipped by the manufacturer you must:
1) First and most important - ask them to fix it - it's their mistake, and you have the right to sue them if they sell you bad quality hardware.
2) Report a specific bug about that DSDT - the current policy is to fix the bugs in the kernel and NOT loading custom DSDT. That won't change any time soon.

Marking as invalid.

[Krastanov (krastanov-stefan)]

In the meantime you can install older kernel or compile your own.

[Tony Butler (spudz76)]

In my case with an ancient Dell Inspiron 3500 laptop, the DSDT is so broken that it doesn't even have a datecode, so the kernel ignores it. Using acpi=force makes it hang hard. With no ACPI or APM pretty much everything is broken. I'd like to try a simple dumped dissasembled and recompiled DSDT with no mods (known to fix many issues on ancient hardware, or bugs caused by the Microsoft ACPI compiler) but now I get to rebuild a custom package to even try it. At this point it might be easier to hack the BIOS image to inject a proper DSDT which is even more dangerous than having the kernel option to do it.

Old hardware is never going to be repaired by the manufacturer, it has been out of support lifecycle for years. I am not even sure how to report a bug about this DSDT or how anyone would patch it - detecting the model string in the DSDT and automatically overriding the safety check for the ACPI date, and then tweaking everything else to override or ignore the bits and pieces that are completely broken? Seems like supplying a good custom DSDT would be a more elegant fix than mucking with all that code just for some ancient laptop that most people wouldn't even try to use anymore.

Also a new user isn't going to accidentally drop a random DSDT file in the initramfs, and it should be clear enough from the outset to any user that meddling with initramfs can and probably will lead to severe issues if you don't know exactly what you're doing.

Recompiling a custom kernel package every update cycle is ridiculous, just to get this needed feature back. Stuff like this leads to people using various third party repositories which usually causes even more problems than the one this new posture intends to avoid. I know if there was a repo I could add that had a non-neutered yet current kernel package I would do it immediately. Maybe Ubuntu should run an official "I'm not an idiot" repo that power users could add in order to get non-neutered "unsafe" packages that go against the mainstream "protect you from yourself" grain, yet still actually work properly alongside the normal repo packages. Maybe put up a web page so you have to sign up for access to the repo and take an online quiz to prove you actually aren't an idiot, even, to keep out the dumb average user riff-raff. Or at least a bunch of disclaimer checkboxes that force the user to confirm their computer might light on fire or become an expensive paperweight if they so much as dare to use the repo.

[Jeffm-novell (jeffm-novell)]

Ok, this patch was too late to make it onto the install media, but it will be incorporated into the next update.

[Simone Campanoni (simo-xan)]

I agree with Tony Butler.
I have the same problem on a Toshiba Satellite P100 laptop which could be easily solved by loading a custom DSDT.
Unfortunately Toshiba does not do anything about it and therefore I have to find another solution! (and therefore in the future I will never buy a Toshiba anymore)

Unfortunately the decision taken by Kubuntu community to not allow to load custom DSDT leads to force users (like me) to find other solutions (maybe change the distribution).
Consider also that many users choose kubuntu (or ubuntu) to not waste their time on rebuilding and reconfiguring softwares and therefore building our kernel should not be a solution.

[Pietro Battiston (toobaz)]

@Krastanov: I don't know how exactly to interpret the following sentence:

"2) Report a specific bug about that DSDT - the current policy is to fix the bugs in the kernel and NOT loading custom DSDT. That won't change any time soon.".

Do you mean that
- in _specific_ cases the kernel _could_ be instructed to override the DSDT, or that
- it may try to workaround the DSDT flaws but without changing it directly, or that
- the bug should be reported just for the sake of information, but not much can be done about it because DSDT problems are not "bugs in the kernel"?

It is one crucial point that I'd like to understand, and presumably Tony and Simone too. Thanks.

[Harry Metske (harry-metske)]

Here's another complaint about not being able anymore to load custom DSDT's:

I have a one year old HP 6830s laptop. It has a very noisy fan (when running Linux).
I managed to fix that by tweaking the DSDT resulting is a nice quiet laptop.
I upgraded to 9.10 and tried to do the same trick, but no, finally ended up here in this bug report.

Any chance this bug can be fixed, I would really appreciate .
(now I'm forced to backout to 9.04 again, and maybe switch to SuSE)

thanks,
Harry

[Howard Chu (hyc)]

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.

[Howard Chu (hyc)]

Ok, so after the patch was removed from 2.6.25 in February 2008, it was fixed and reposted in July 2008 http://lkml.org/lkml/2008/7/21/338 but there were no further followups. What happened?

[arcasys (mail-arcasys)]

What's the point in whining about OEMs delivering crappy DSDTs as long as they appear to work with Windows? It won't increase adoption of Linux to fingerpoint OEMs instead of solving the problem. Ubuntu is a very nice distro and working
out of the box for a lot of things. But not being able to suspend to RAM (after it had worked in 8.04) is a real nuisance.
Trying to fix the DSDT seemed to be my last resort but having to recompile the kernel isn't a practical solution.

[Andreas B. (andreas-b123)]

I think anybody should be able to use Linux, especially Ubuntu, I thought it should be Linux for everyone, not only for users with standard compliant BIOS.

There is no BIOS update available for my notebook, there is only a text, "Windows 7 is not supported", in this case I think Linux should support this notebook! Without recompiling the kernel!

[Naoyuki Tai (ntai)]

I hit this issue with ABIT's IL-90MV motherboard. SSDT table is totally busted, and with this obsolete hardware, there is very little chance that the BIOS is updated.
_PST in SSDT has the wrong CPU frequencies and voltage IDs. My 2GHz CPU is showing that the max CPU speed is 1.2GHz.
I did send a "tech support" request to the ABIT.com.tw that Linux does not work too well with such BIOS.
I am hoping that it's fixed in the future, but it's very unlikely because ABIT is not going to make any money fixing the problem.

Meanwhile, there is not much I can do but to get out from Karmic.
Very sad.

[Howard Chu (hyc)]

One more request - if you're not going to integrate the custom DSDT patch, please provide a .deb package for your kernel build tree with all .o files intact. Then we can insert our own DSDT.hex and rebuild without having to spend hours recompiling the entire kernel. This is getting to be a real pain, enough to make me switch distros.

[Johannes (hummlbach)]

Me too needs to add custom dsdt to initrd! Please reintroduce the ACPI_CUSTOM_DSDT_INITRD option or suggest another _usable_ solution.

Thanks.

[peter pan (clarcraft)]

I think there are a lot of people who found a working dsdt on the web and happily used it for a long time.
I think it is absolutely the wrong way to disable a usefull and working feature.
Rebuilding the kernel is really the worst workaround i cn imagine...
So please enable ACPI_CUSTOM_DSDT again...
thanks,

peter

[Nikolaus Filus (nfilus)]

One more unhappy guy, having a Samsung P35 (similar to Asus), which was badly manufactured and even worse supported with updates. Without the patched DSDT my Fan runs ALWAYS at FULL speed - forget about silent or powersaving mode :(

[Yann (lostec)]

Forget about it guys: Ubuntu kernel team just don't care anymore about users problems.

See the original duplicate of this bug here, set "won't fix" after last demand for inclusion in 10.04.1 (to avoid regression for previous 8.04 LTS users):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246222

So go openSuse... they don't set such kind of major problem "won't fix" after years of users demand: It's set in "major" severity and solved just after 11.2 release in january. That's having users concern!

11.3 is coming this summer... If it's still in opensuse and ubuntu kernel team have not changed their mind until 10.04.1 that'll be there at the same time, that'll be the end of 5 years Ubutnu hitrory for me!