Linux 2.6.26 not loading custom DSDT from initrd

This isn't just a config option, we were missing the patch that added this functionality. Committed to git repo.

This may fix the problems I've had in Bug 251338, when will this hit the repository?

Ben, can you glance at my BIOS dumps, if you have a few minutes to kill?

I'm sure there are lots of people with this particular type of BIOS bustage that would love to see a fix.

This bug was fixed in the package linux - 2.6.26-4.12

---------------
linux (2.6.26-4.12) intrepid; urgency=low

  [ Ben Collins ]

  * e1000e: Upgraded module to 0.4.1.7 upstream. Placed in ubuntu/,
    in-kernel driver disabled
  * config: Disable e1000e in-kernel, and enable newer driver in ubuntu/
  * rfkill: Update to 1.3 drivers, and move to common location
  * ubuntu: Actually link kconfig/kbuild into rfkill subdir
  * config: Enable loading dsdt from initramfs
    - LP: #246222
  * ubuntu: [compcache] Update to fix crashes in improper BUG()
  * build: Create a retag scripts to recover tags from rebases
  * build: Updates for dbg pkg
  * build: Make sure no empty lines show up in debian/files
  * ubuntu: atl1e: Add new driver from 2.6.27-pre-rc1
    - LP: #243894
  * sys_getcwd: Fix some brokeness introduced by AppArmor __d_path
    changes
    - LP: #251223
  * ubuntu: unionfs: Added v1.4 module from hardy
  * build: Add sub-flavour infrastructure, and virtual subflav

  [ Eric Piel ]

  * ACPI: Allow custom DSDT tables to be loaded from initramfs

  [ Kees Cook ]

  * AppArmor: Smack VFS patches

  [ Mario Limonciello ]

  * Work around ACPI corruption upon suspend on some Dell machines.
    - LP: #183033

  [ Tim Gardner ]

  * Export usbhid_modify_dquirk for LBM module bcm5974
    - LP: #250838
  * VIA - Add VIA DRM Chrome9 3D engine
    - LP: #251862
  * Define TRUE/FALSE for VIA DRM driver.

 -- Ben Collins <email address hidden> Tue, 15 Jul 2008 12:51:39 -0400

I just updated my laptop to use 2.6.26-5.13 and the fix doesn't seem to work.
Booting my laptop /proc/acpi/dsdt doesn't match /etc/initramfs-tools/DSDT.aml and the kernel log doesn't contain the usual "Looking for DSDT in initramfs... "

stgraber@castiana:~$ dmesg | grep -i DSDT
[ 0.000000] ACPI: DSDT BFFC8538, 12A44 (r1 HP 8510x 10000 MSFT 3000001)
[ 0.604032] ACPI: EC: Look up EC in DSDT

Nevertheless the config file contains the required DSDT_INITRD=y option and the patch seems to have been applied correctly (looking at git). Any idea what's going wrong ?

stgraber@castiana:~$ cat /boot/config-2.6.26-5-generic | grep -i DSDT
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_CUSTOM_DSDT_FILE=""
CONFIG_ACPI_CUSTOM_DSDT_INITRD=y

I'm moving the bug status back to triaged as it doesn't seem to have been fixed.

Fixed in 2.6.26-5.14.

stgraber@castiana:~$ sudo md5sum /proc/acpi/dsdt
3d7fb563d186ea2cdafd5f4e3215fe35 /proc/acpi/dsdt
stgraber@castiana:~$ sudo md5sum /etc/initramfs-tools/DSDT.aml
3d7fb563d186ea2cdafd5f4e3215fe35 /etc/initramfs-tools/DSDT.aml

$cat /boot/config-2.6.31-20-generic | grep -i DSDT
CONFIG_ACPI_CUSTOM_DSDT_FILE=""
# CONFIG_ACPI_CUSTOM_DSDT is not set
$ uname -a
Linux richiter 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010 x86_64 GNU/Linux

Can we get this back? It's very useful and compiling customer kernel is a pain.

I discover loading custom DSDT is impossible on Lucid Lynx... as it was in Hardy: This is necessary to load a custom DSDT on my laptop (Toshiba Satellite P100) because without a DSDT hack, GPU fan does not work => overheating.

Root cause is that temp regulation loop is handled in windows by some WMI bios extensions not working for Linux.

A lot of laptop hardware need custom DSDT to run under linux, so this regression must be solved!

For every kernel already tested on my machine:

$ grep -i dsdt /boot/config-2.6.32*
/boot/config-2.6.32-17-generic:CONFIG_ACPI_CUSTOM_DSDT_FILE=""
/boot/config-2.6.32-17-generic:# CONFIG_ACPI_CUSTOM_DSDT is not set
/boot/config-2.6.32-17-generic-pae:CONFIG_ACPI_CUSTOM_DSDT_FILE=""
/boot/config-2.6.32-17-generic-pae:# CONFIG_ACPI_CUSTOM_DSDT is not set
/boot/config-2.6.32-18-generic:CONFIG_ACPI_CUSTOM_DSDT_FILE=""
/boot/config-2.6.32-18-generic:# CONFIG_ACPI_CUSTOM_DSDT is not set
/boot/config-2.6.32-18-generic-pae:CONFIG_ACPI_CUSTOM_DSDT_FILE=""
/boot/config-2.6.32-18-generic-pae:# CONFIG_ACPI_CUSTOM_DSDT is not set

you can see CONFIG_ACPI_CUSTOM_DSDT is not in the configuration => For users in need to pass custom DSDT to kernel, the only solution will be to recompile a kernel with either:
-CONFIG_ACPI_CUSTOM_DSDT set and making an initramfs with their custom DSDT.
-CONFIG_ACPI_CUSTOM_DSDT_FILE with their DSDT file in the compiled kernel.

Both case means recompiling kernel with altered cfg each time it change! This is a huge regression compared to my current ubuntu install (Hardy Heron) and previous ones (I use this trick since Dapper Drake).

Well, after some research I found this is an invalid bug: see bug #395239

I disagree: This was a convenient way to cope with buggy BIOSes sinces ages... and should not have been removed without any alternative.

This is clearly a regression for Lucid compared to Hardy:

With a reworked DSDT.aml:
-In hardy (and before): Just copy DSDT.aml in /etc/initramfs-tools/ and at 1st time, one dpkg-reconfigure linux-image-$(uname -r) for 1st time only (as reconfigure is after done automatically at each kernel update).
-Now: Get kernel sources at each update, edit config to give a DSDT.aml path, recompile kernel... and pray for your GPU not frying during recompile/reboot time if you cannot do the job on another machine.

Well, if for you this is not a regession, we have a word definition problem...

Well, this functionality is missing from Intrepid kernels, so I think it will never be reintroduced.

So, is there any good solution to automate kernel config patching+recompilation to cope with this with no hassle?

No in Ubuntu 10.04 is this impossible. Try OpenSuse

So the question is: Why Ubuntu didn't keep this useful patch when Suse proves it's possible to do so with current kernels?
This is a major upgrade stopper for previous LTS users...

I don't want to go to a rpm based distro indeed.

So I'll keep 8.04 for a while and if this problem is still unsolved in 10.04.1 iteration, I think the solution will be much easier: Getting rid of Linux, going back to XP and my "linux distro" will become cygwin.

Maybe that's the safer (my DSDT hack was solving a GPU fan not working issue) and hassle free option on laptops.

As 10.04.1 is the recommended update point for current 8.04 users, it should make sense to integrate this DSDT override patch for this sub release point. This is just keeping the current level of linux hardware quirk!

Looks like you're righ Sentello about openSuse: They still maintain custom DSDT initrd loading patch.
https://bugzilla.novell.com/show_bug.cgi?id=533555

If someone knows anybody in Ubuntu kernel team able to take this patch in for 10.04.1, please let him know about this!

Yann,
    I can tell you from conversations with the team that this was removed due to the ability to seriously damage your machine with a custom DSDT. I will, however, ask one of them to provide a bit more detail as I only have a peripheral understanding of the issues here.

Thanks!

~JFo

The upstream position on the DSDT override was that it quite simply allows you to pull in random DSDTs for the wrong machine with the possibility of real permenant damage to your hardware from a "software" change. If there are bugs in the DSDT and the BIOS vendor is unable to fix them, then upstream says we should be quirking the implementation of the execution side so that it behaves sensibly on these machines. To do that we need to get the bugs identified and upstreamed so that we can get these quirks created and integrated.

per Andy's response above, I have declined nominations and marked this bug as Wont Fix.

Thanks!

~JFo

1) People modifying DSDTs are usually carefull and knows the risks. They are just willing a little bit more than many others to run linux on any hardware they have. I don't think reconfiguring/recompiling a kernel (+modules, nvidia/ati stuff...) is less risky (on top of that, that's hours of compile time for each kernel update).
2) Did you already tried to get a BIOS corrected by a manufacturer? I asked Toshiba... they said they do not support Linux. End of the game so please stop kidding!

If openSuse become more user centric than Ubuntu... I think that should really trigger good questions in your mind!

But maybe maintaining such useful kernel patches is not as easy as reversing buttons... to make everyone learn about gconf to correct this?

OK, this one will still "won't fix" it seems...
So the only solution will be, as everyone concerned by this issue advice on the web, to go to openSuse...

I'll stick to 8.04 until july: If 10.04.1 include the patch, I'll upgrade... If not I migrate to openSuse 11.3 that'll be there at this time.

That's quite funny, 3 years after Shuttleworth saying openSuse devs to go Ubuntu... to send 5 years users in the opposite direction!

Indeed, this is just another expression of this fact: Ubuntu is loosing what made it's success, being user centric, which seems every version less true.

Saying "this was removed due to the ability to seriously damage your machine with a custom DSDT" when it's exactly the opposite in my case (no GPU fan => It'll burn in half an hour of low usage!), allowing linux usage on the affected machine since Dapper... that's really worth reading this!!!

"won't fix"? This is a joke?

@ Yann: Now i trying this: http://ubuntuforums.org/showpost.php?p=8411199&postcount=1
but i still have same problem :(

@ Sentello:

Seems openSuse no more better at the moment: I tried 11.2 in a Virtualbox... and the kernel config is not there anymore: Maybe forgotten in some update? And it seems this is not in 11.3 at the moment too.

But it seems, at least, they care about bugs because reopening this one in opensuse trigger some action quickly:
https://bugzilla.novell.com/show_bug.cgi?id=533555

Wait and see... I'm stick with 8.04 meantime...

this sucks! Have you tried to put it DSDT into the kernel?
We must install Windows :)

Folks,
    Please read Andy's comment #17. The upstream maintainers of the kernel (meaning Linus et Al) have made the decision to remove the ability of custom DSDT. This was NOT a decision by the Ubuntu Kernel Team.

Please file your grievance with the appropriate party.

Thanks!

~JFo

And what we should do? There must be any solution?
Without DSDT, my laptop does not working.

File bugs against the kernel here: https://bugzilla.kernel.org/ This way the bugs can be fixed and trickle down to everyone. The custom dsdt only fixes your problem, and the bug is never exposed. This is why it was disabled.

and what I do for a functional Ubuntu 10.04?

Have you started a help thread on the forums? Maybe there is a workaround for your problem until you can file a bug, and hopefully get it fixed.

re: Filing bugs against the kernel - that's only reasonable when there is in fact a kernel bug. There are plenty of ACPI bugs that cannot be labeled as kernel bugs, or fixed by other kernel patches. E.g. the new AMD-based Lenovo Thinkpads are *missing* the PSS tables, because Lenovo simply released these machines too early, with an incomplete BIOS. So CPU frequency scaling is unavailable without patching these tables into the DSDT. No amount of kernel fixing can make up for totally missing ACPI info, the only solution is to fix the DSDT.

You can still add the dsdt patch to a custom kernel. It is not the best solution, but in extreme cases like that, it is your only choice. Most situations aren't that extreme, and only suffer from ACPI bugs that can be fixed. Does the cpu scaling work in Windows? If so, maybe the kernel can be told to ignore the missing PSS table for your model and just query the cpu for info. The dsdt only tells the OS about the hardware and it's config options. If you change the hardware, the dsdt still points to the old hardware, and the OS still configures the new hardware fine in most cases. The dsdt tables are not mandatory to have a working PC.

Yes, I'm using a compiled-in DSDT now but it's a PITA to have to recompile it with every kernel update. (Echoing a previous request - if this is going to be the standard "solution" then you guys need to provide a kernel package that contains a kernel build tree with .o files ready to be linked, so that we don't have to sit through recompiling the whole thing just to make one change.)

re: Windows - good question, unfortunately I can't provide an answer to that. I reformatted the drive and put Ubuntu on it as soon as I got the machine, also destroying the Lenovo recovery partition at the same time. (In retrospect perhaps I should have left that intact...)

You are compiled DSDT into kernel? How?
Can you send a link to the guide by which you did this?

> The upstream position on the DSDT override was that it quite simply allows you to pull in
> random DSDTs for the wrong machine with the possibility of real permanent damage to
> your hardware from a "software" change.

which in turn forces users to recompile kernel for the patched DSDT. One way or the other, the stated kernel team's goal would not be fulfilled.
Users who need to override DSDT are forced to now recompile kernel for every kernel update.
Also users who knows how to patch DSDT should be assumed that they know what they are doing in the first place. (I certainly do.)

Unless you have a gobs of money to buy your hardware any time you want or influence the manufacturer, you'd be stuck with bad DSDT implementation of your computers.
I guess Linux kernel team got too rich and forgot that there are normal people who is using older computers.

Tell us how to compile the kernel? Is any tutorial?