Arch Linux

Most likely this will not be patched by arch devs. The policy is to only patch kernel for bug fixes and security issues. If this is a deliberate change in the kernel, we aren't going to patch for the old behavior. I would report this upstream if it actually is a bug and not a change.

If it's not a bug your best path is probably to make a PKGBUILD for the modified kernel.

Nothing has changed. The patch was not in vanilla 2.6.24 and is not in 2.6.25. The git message you referenced reverts a commit that has been made after the 2.6.25 development cycle has been started.

The situation is the same as with 2.6.24: We have to add a patch to the kernel which adds custom dsdt support. This hasn't changed and support for the custom dsdt is built into the -ARCH kernel.

We used to have a patch for this in 2.6.24, which was probably removed during the rc versions of 2.6.25 because there's in-kernel DSDT support during the release candidate series which made this patch fail to apply.

Kernel 2.6.25-1-ARCH has version 0.9 of the DSDT patch applied, the author has released a new version 0.9a ... there is no Changelog, but it's possible this fixes the problem again.

I have the same problem with a custom DSDT on kernel 2.6.25.
The patch used by arch is the one mentioned here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a9e0d685553af76cb6ae2af93cca4913e7fcd47
More details: http://fixunix.com/kernel/359747-2-6-25-rc5-mm1-8.html
I don't think the new (acpi-dsdt-initrd-v0.9a-2.6.25) patch will fix the problem but i will probably test it tonight.

diff -Naur acpi-dsdt-initrd-v0.9-2.6.25.patch acpi-dsdt-initrd-v0.9a-2.6.25.patch

The only thing worth mentioning:

++#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+#include <acpi/acpi.h>
++#endif

Rebuilt the kernel with the updated 0.9a patch but it's still not working.

[lexiw@stroggos ~]$ dmesg|grep DSDT
ACPI: DSDT 7F6D5400, 438C (r1 INT430 SYSFexxx 1001 INTL 20050624)
ACPI: Checking initramfs for custom DSDT
ACPI: EC: Look up EC in DSDT

I noticed this since 2.6.25-rc6 or so, the newer acpi-dsdt-initrd-v0.9a-2.6.25.patch makes no difference and its no wonder since mkinitcpio DSDT hook is not actually adding the /DSDT.aml to the kernel26.img file. For whatever reason it is ignoring /lib/initcpio/custom.dsdt.
Extract the kernel26.img there is no trace of the DSDT.aml.

However using the linux-2.6.25/Documentation/acpi/initramfs-add-dsdt.sh script will add the DSDT to the kernel26.img.

We didn't change mkinitcpio in that respect. Can you run mkinitcpio -v -p kernel26 and post the output?

Heres the output of mkinitcpio -v -p kernel26

verbose.patch fix the verbose output
mkinitcpio.log is the output of mkinitcpio -v
Looking in /boot/kernel26.img there is a /DSDT.aml file

I should add that i patched the DSDT months ago to fix the lid behavior because the monitor wasn't turning on after closing/opening it.
The custom DSDT worked till kernel 2.6.24, now the monitor won't turn off in terminal after i close the lid, it works in gnome but maybe there is a workaround (vbetool?). However it acts weird when i open the lid.

The verbose.patch should be in mkinitcpio.git, not sure if I applied it already.

You could save a filelist with mkinitcpio -s somefile and post it. Then show me the filelist of the resulting image using zcat kernel26.img | cpio -t and post that as well to speed things up for me.

mkinitcpio -s somefile.log
mkinitcpio -g somefile.img
zcat somefile.img | cpio -t > zcat.log

From these files, everything looks alright and DSDT.aml is where it should be.

It looks like a regression in the kernel acpi.
BTW, where should i send that patch (and maybe any future patch) for mkinitcpio?

I'd like to find out why adding the dsdt using the script from the patch works, but mkinitcpio doesn't. Can any of you try if it helps to put the dsdt last in the HOOKS list, or if it helps to put it first in the HOOKS list?

This bug can be closed for me, the regression is in the kernel, my DSDT get loaded correctly. The bug has been reported and there are some patches waiting for upstream.

There is no regression in the upstream kernel, because the ACPI DSDT initrd patch is not in the kernel.

I have reports on the forums that the dsdt patch works, but not if you add the dsdt using mkinitcpio.

I was just stating that using mkinitcpio to add the dsdt is working for me. The dsdt get added but something doesn't work and it's related to the recent changes to drivers/acpi.
This patch (http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg271899.html) against http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/acpi/ec.c;h=7222a18a03198d0bc70121d1246dc27af1d0629e;hb=4b119e21d0c66c22e8ca03df05d9de623d0eb50f worked for me.
My original report was not related to this bug at all (but i discovered it later!) that's why i'm telling you that, for me, it's closed and i don't belong to the discussion anymore.
Using the standard mkinitcpio.conf (generated during the setup) always worked for me.

@ brain0

I tried to move the dsdt hook to the beginning and end of the HOOKS list (and remade the image every time, of course). This didn't help and the DSDT gets still ignored.

It's not yet very clear if the bug is in the acpi-dsdt-initrd patch which doesn't see the DSDT.aml file or if it's in mkinitcpio which fails to add the file for some people.

Robert, Daniel could you list the initramfs to see if the DSDT.aml file is inside?
zcat /boot/initrd-2.6.25.3-XXX.img | cpio -t > zcat.log

If indeed, it is present, I'll have a closer look at the acpi-dsdt-initrd patch. It could be possible that in the new version there is a bug in the cpio parser.

BTW, Thomas, you can also try it at home :-) Just use you normal DSDT: you can find it there: /sys/firmware/acpi/tables/DSDT . Copy this file in the initramfs, and you should find in dmesg a line saying your DSDT has been overridden.

OK, here is my listing. DSDT seems to be included (line 96).

Oh, I start to understand. The initramfs has all the files starting with "/" while in other distros it directly start with the name. I guess I'll have to fix the patch to remove the "/" before the filename... (because modifying mkinitcpio would work here, but theoretically having a / is not forbidden by the kernel).

In the mean time, just for archlinux you confirm this comes from there by changing the "DSDT.aml" string in the patch to "/DSDT.aml" .

I didn't know that, it should be easy to fix in mkinitcpio though.

Eric, can you please change line 132 of /lib/initcpio/functions from
echo "file ${dest} ${fil} $(stat -c '%a' ${fil}) 0 0" >> "${FILELIST}"
to
echo "file ${dest#/} ${fil} $(stat -c '%a' ${fil}) 0 0" >> "${FILELIST}"
and then regenerate your initramfs. This is only a partial fix, but the DSDT.aml should now be found if what you say is true.

Hehe... I don't have archlinux, so it will take me some time to test this fix to mkinitcpio.
Could some reporter try it? Robert, Daniel?

Ah, I didn't realize who you were until now, thanks for commenting here directly. Can any of the affected try this fix?

Thomas, i tried the patch, here's the output:

bash-3.2# mkinitcpio -g /boot/kernel26.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [dsdt]
:: Parsing hook [v86d]
:: Parsing hook [autodetect]
:: Parsing hook [pata]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [keymap]
:: Parsing hook [filesystems]
:: Generating module dependencies
WARNING: Couldn't open directory /tmp/mkinitcpio.bCS1HH/lib/modules/2.6.25-ARCH: No such file or directory
FATAL: Could not open /tmp/mkinitcpio.bCS1HH/lib/modules/2.6.25-ARCH/modules.dep.temp for writing: No such file or directory
ERROR: file '/tmp/mkinitcpio.bCS1HH/lib/modules/2.6.25-ARCH/modules.dep' does not exist
ERROR: file '/tmp/mkinitcpio.bCS1HH/lib/modules/2.6.25-ARCH/modules.alias' does not exist
ERROR: file '/tmp/mkinitcpio.bCS1HH/lib/modules/2.6.25-ARCH/modules.symbols' does not exist
:: Generating image '/boot/kernel26.img'...SUCCESS

Changing line 9 of /lib/initcpio/install/dsdt from:
add_file "/lib/initcpio/custom.dsdt" "/DSDT.aml"
to:
add_file "/lib/initcpio/custom.dsdt" "DSDT.aml"
worked for me.

Before the workaround:
[lexiw@stroggos ~]$ dmesg|grep DSDT
ACPI: DSDT 7F6D5400, 438C (r1 INT430 SYSFexxx 1001 INTL 20050624)
ACPI: Checking initramfs for custom DSDT
ACPI: EC: Look up EC in DSDT

After the workaround:
[lexiw@stroggos ~]$ dmesg|grep DSDT
ACPI: DSDT 7F6D5400, 438C (r1 INT430 SYSFexxx 1001 INTL 20050624)
ACPI: Checking initramfs for custom DSDT
ACPI: Found DSDT in DSDT.aml.
ACPI: Override [DSDT-SYSFexxx], this is unsafe: tainting kernel
ACPI: Table DSDT replaced by host OS
ACPI: DSDT 00000000, 3E4C (r1 INT430 SYSFexxx 1001 INTL 20061109)
ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt"CPU0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping 06
ACPI: EC: Look up EC in DSDT

My lid is working again now with the Arch 'vanilla' kernel.

Okay, I'll include the shorter (easier) workaround provided by lexiw's last post in mkinitcpio. This means that we can move the kernel to core.

Great, with the new mkinitcpio I was able to upgrade to Kernel 2.6.25 without any hassle. Just out of the box.

From my side we can close this bug.

Thanks for your effort! / Danke für die Mühe!
Many thanks also to Eric for his direct participation.

Same problem here. Mkinitcpio from core (0.5.18.1-1) does not include my custom DSDT into the image.

The workaround by lexiw works for me.