initrd DSDT override (Re: Feedback about your talk in Rennes France (20080124) : Evolution of the Linux kernel & virtualization technologies)
Subsystems (4)
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Len Brown
reviewerQuoted 22 lines
Quoted 14 lines
I am annoyed by this missing (or rejected) feature upstream : DSDT
http://gaugusch.at/kernel.shtmlSo to use "custom DSDT loading" I have to patch my laptop buggy BIOS
As usual, I reported this issue to the vendor (which goes nowhere so far) :
http://support.fujitsu-siemens.de/forum/viewtopic.php?p=37001Hopefully many distro already include this patch, but not all of them such as debian :
http://bugs.debian.org/251023
http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelinesQuoted 7 lines
So as a debian contributor, I keep staying on debian and compile my own kernel
and provide it to a "amiloa laptop" community I am managing :
http://tech.groups.yahoo.com/group/amilo/It's ok for me I can live with this, but what average users have to do with their (buggy) hardware ?
Quoted 7 lines
Philosophically speaking: we sholdn't be making decisions for other people like this.
Practically speaking: the fact that distros are shipping it is a huge indication that the decision was wrong.
Len? I think we goofed here.
Here is the existing supported DSDT override method:
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
and at the bottom of that page I point to the alternate initrd method and explain why I've not applied it upstream.
My goal for the Linux/ACPI project is to make Linux work out-of-the-box on any system where Windows works.
Giving "Joe User", who is incapable of compiling
a kernel, an easy method to override his BIOS image makes him more likely to settle for a workaround. And that effort undermines, rather than supports, our goal.
However, Philippe points out that the FSC Amilo box also fails the same way under Windows -- and the vendor is unwilling or unable to fix their BIOS. While Phillippe could build a kernel from source and link in a DSDT via the supported developer method above, or he could run SuSE or Ubuntu which include the initrd patch, he'd prefer to track Debian w/o re-compiling.
I'm fine with making it more convenient for
FSC Amilo ownersr to make their laptops work better under Linux than under Windows -- even if it is impossible for a Linux distro to support the resulting configuration. They're otherwise stuck with junk hardware or extra work.
Also, Thomas continues to assert that this patch makes SuSE easier to debug in the field b/c he can convince users who are unable to re-compile their kernel
go ahead and override their BIOS image for debugging (bless their trusting hearts;-)
So at the risk that we're giving "Joe User" more than enough rope to hang themselves, lets do it -- with some strings attached...
Thomas,
Since you've been a big supporter of this patch, perhaps you can update it and submit it to the list for review?
I think it needs the following changes:
1. tainted bit needs to be set when a DSDT override is used. (this is common both to the new patch and the current override method)
2. upon setting the tainted bit, print a BIG FAT WARNING that this is not a supported configuration.
3. cmdline option needs to be available to disable an override. Otherwise a bad image in the intrd may be a serious pickle for some users.
4. get rid of alarming failure message:
+ printk(KERN_INFO "Looking for DSDT in initrd ...");
...
+ printk(" not found!\n");
Probably it is best to forward the original patch w/ proper credits, and then send updates to address 1-4.
thanks,
-Len
PATCH 1/1 Override DSDT and SSDTs via initramfs
Hi,
you find some comments inlined and the patch which is shipped in OpenSUSE at the end.
Quoted 18 lines · Len Brown
Quoted 18 lines
Quoted 18 lines
I am annoyed by this missing (or rejected) feature upstream : DSDT
http://gaugusch.at/kernel.shtmlSo to use "custom DSDT loading" I have to patch my laptop buggy BIOS
As usual, I reported this issue to the vendor (which goes nowhere so far) :
http://support.fujitsu-siemens.de/forum/viewtopic.php?p=37001Hopefully many distro already include this patch, but not all of them such as debian :
http://bugs.debian.org/251023
http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelinesSo as a debian contributor, I keep staying on debian and compile my own kernel
and provide it to a "amiloa laptop" community I am managing :
http://tech.groups.yahoo.com/group/amilo/
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
It's ok for me I can live with this, but what average users have to do with their (buggy) hardware ?
Philosophically speaking: we sholdn't be making decisions for other people like this.
Practically speaking: the fact that distros are shipping it is a huge indication that the decision was wrong.
IMO, Vista providing a feature to easily override the DSDT via a simple registry pointer to a modified DSDT, is an argument you cannot come around...
The purpose of the feature should definitely not be to provide the possibility to workaround buggy BIOSes, but as done by Vista for debugging and testing.
Quoted 64 lines
Quoted 1 line
Len? I think we goofed here.
Here is the existing supported DSDT override method:
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
and at the bottom of that page I point to the alternate initrd method and explain why I've not applied it upstream.
My goal for the Linux/ACPI project is to make Linux work out-of-the-box on any system where Windows works.
Giving "Joe User", who is incapable of compiling
a kernel, an easy method to override his BIOS image makes him more likely to settle for a workaround. And that effort undermines, rather than supports, our goal.However, Philippe points out that the FSC Amilo box also fails the same way under Windows -- and the vendor is unwilling or unable to fix their BIOS. While Phillippe could build a kernel from source and link in a DSDT via the supported developer method above, or he could run SuSE or Ubuntu which include the initrd patch, he'd prefer to track Debian w/o re-compiling.
I'm fine with making it more convenient for
FSC Amilo ownersr to make their laptops work better under Linux than under Windows -- even if it is impossible for a Linux distro to support the resulting configuration. They're otherwise stuck with junk hardware or extra work.Also, Thomas continues to assert that this patch makes SuSE easier to debug in the field b/c he can convince users who are unable to re-compile their kernel
go ahead and override their BIOS image for debugging (bless their trusting hearts;-)So at the risk that we're giving "Joe User" more than enough rope to hang themselves, lets do it -- with some strings attached...
Thomas,
Since you've been a big supporter of this patch, perhaps you can update it and submit it to the list for review?I think it needs the following changes:
1. tainted bit needs to be set when a DSDT override is used. (this is common both to the new patch and the current override method)
2. upon setting the tainted bit, print a BIG FAT WARNING that this is not a supported configuration.
3. cmdline option needs to be available to disable an override. Otherwise a bad image in the intrd may be a serious pickle for some users.
4. get rid of alarming failure message:
(quoted diff) +2
-0+ printk(KERN_INFO "Looking for DSDT in initrd ..."); + printk(" not found!\n");
Quoted 2 lines
Probably it is best to forward the original patch w/ proper credits, and then send updates to address 1-4.
I do not know who initially came up with this, I just modified/adjusted the patch sometimes. I expect it's Markus, possibly Eric or best both who should be mentioned as author.
The patch should be against a quite recent vanilla kernel, tell me if you have problems with patching/merging and tell me against which kernel/git version/tree you like to have it.
Jeff (Mahony) has adjusted the last bits of it when he updated it to the latest rcX-gitY version:
Changes:
We no longer call populate_rootfs() twice. If we want the custom DSDT, we load the rootfs before ACPI. Otherwise, it is loaded at the
appropriate
initcall time. -jeffm
There is a new version at
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.4-2.6.21.patch,
but there doesn't seem to be any real changes other than elminating the
file
name array.
In fact, I added the array some time ago.
Not sure whether the latest Version of Eric/Markus can also load several DSDT/SSDTs? Maybe you found a more elegant way?
This is a quite useful feature (which is not provided by the current "override via compile into kernel" method). You can add several SSDTs and let them load before any other table is loaded. Duplicated tables will be ignored later. Like this you can also override single and multiple SSDTs easily.
There just need to be files:
/DSDT.aml, /SSDT[1-9]?.aml
in the initrd fs.
If you take this one, please do not forget to mention Eric and Markus as authors.
Thomas
-----------------
Override DSDT and SSDTs via initramfs
Searches and reads in the root of initramfs a DSDT.aml and SSDT[1-9]?.aml files. The found DSDT and SSDTs are loaded into the ACPI namespace prior any BIOS provided table. Later (BIOS provided) tables with the same signature are ignored automatically. Like that the BIOS provided tables can be replaced.
Once a table is loaded via initrd, the kernel gets tainted.
More information can be found here: http://gaugusch.at/kernel.shtml
---
drivers/acpi/Kconfig | 17 ++++++ drivers/acpi/osl.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++-- include/acpi/acpiosxf.h | 4 + init/initramfs.c | 4 + init/main.c | 9 +++ 5 files changed, 156 insertions(+), 5 deletions(-)
drivers/acpi/Kconfig +17 -0
@@ -274,6 +274,23 @@ config ACPI_CUSTOM_DSDT_FILE Enter the full path name to the file which includes the AmlCode declaration. +config ACPI_CUSTOM_DSDT_INITRD + bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default y + help + The DSDT (Differentiated System Description Table) often needs to be + overridden because of broken BIOS implementations. If this feature is + activated you will be able to provide a customized DSDT by adding it + to your initramfs. For now you need to use a special mkinitrd tool. + For more details see <file:Documentation/dsdt-initrd.txt> or + <http://gaugusch.at/kernel.shtml>. If there is no table found, it + will fallback to the custom DSDT in-kernel (if activated) or to the + DSDT from the BIOS. + + Even if you do not need a new one at the moment, you may want to use a + better implemented DSDT later. It is safe to say Y here. + config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0
drivers/acpi/osl.c +123 -4
148 lines not on this page · raw message
include/acpi/acpiosxf.h +4 -0
@@ -95,6 +95,10 @@ acpi_status acpi_os_table_override(struct acpi_table_header *existing_table, struct acpi_table_header **new_table); +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +extern int acpi_must_unregister_table; +#endif +/* * Spinlock primitives */
init/initramfs.c +3 -1
@@ -541,7 +541,7 @@ skip:#endif -static int __init populate_rootfs (void ) +int __init populate_rootfs (void ) {char *err =unpack_to_rootfs (__initramfs_start, __initramfs_end - __initramfs_start,0 );
@@ -582,4 +582,6 @@ static int __init populate_rootfs(void)#endif return 0 ; } +#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD rootfs_initcall (populate_rootfs); +#endif
init/main.c +9 -0
@@ -102,6 +102,12 @@ static inline void mark_rodata_ro(void)extern void tc_init (void );#endif +#ifdef CONFIG_BLK_DEV_INITRD +extern int populate_rootfs (void ); +#else +static inline void populate_rootfs (void ) {} +#endif +enum system_states system_state;EXPORT_SYMBOL (system_state);
@@ -642,6 +648,9 @@ asmlinkage void __init start_kernel(voidcheck_bugs (); +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +populate_rootfs ();/* For DSDT override from initramfs */ +#endif acpi_early_init ();/* before LAPIC and SMP init */ /* Do the rest non-__init'ed, we're now alive */
Re: [PATCH] Override DSDT and SSDTs via initramfs
Hi,
Just a few comments for now as I don't have much time until this weekend. 30/01/08 18:27, Thomas Renninger wrote/a écrit:
:
Quoted 1 line · Len Brown
:
Quoted 2 lines
Quoted 2 lines
Probably it is best to forward the original patch w/ proper credits, and then send updates to address 1-4.
Thomas, the patch you have included is only the "original" patch, right? We need to address the points 1-4 (which seem very reasonable) later on with additional patches. I think most of them are already implemented in
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.2-2.6.17-ssdt.patch
So that should be quite easy :-)
Quoted 3 lines
I do not know who initially came up with this, I just modified/adjusted the patch sometimes. I expect it's Markus, possibly Eric or best both who should be mentioned as author.
Yep, to be precise, Markus Gaugusch is the original author, I'm just the current maintainer, and Thomas has been very helpful for a looong time :-)
:
Quoted 7 lines
Jeff (Mahony) has adjusted the last bits of it when he updated it to the latest rcX-gitY version:
Changes:
We no longer callpopulate_rootfs()twice. If we want the custom DSDT, we load the rootfs before ACPI. Otherwise, it is loaded at the
appropriate
initcall time. -jeffm
I had left it this way because I though Linus had a good reason for delaying populate_rootfs(). But if it works, fine! Maybe some additional comments should be added in before the #ifdef's to clearly show that populate_rootfs() is _always_ called, and they modify only the moment it is called.
Quoted 5 lines
There is a new version at
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.4-2.6.21.patch,
but there doesn't seem to be any real changes other than elminating the
file
name array.
Yes, exactly.
Quoted 3 lines
In fact, I added the array some time ago.
Not sure whether the latest Version of Eric/Markus can also load several DSDT/SSDTs? Maybe you found a more elegant way?
Nope. On the website (http://gaugusch.at/kernel.shtml) you can just find two versions of the patch: one simple and one with your addition for SSDTs support. At least with SSDTs support there is even an advantage over the DSDT-in-kernel version :-)
Just one comment about the patch for now: it misses Documentation/dsdt-initrd.txt . Please include this file too so that the documentation is provided at the same time (it's in the official patch).
I'll test the patch and try to be productive this weekend. See you,
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerRe: [PATCH] Override DSDT and SSDTs via initramfs
Quoted 9 lines
Quoted 4 lines
In fact, I added the array some time ago.
Not sure whether the latest Version of Eric/Markus can also load several DSDT/SSDTs? Maybe you found a more elegant way?Nope. On the website (http://gaugusch.at/kernel.shtml) you can just find two versions of the patch: one simple and one with your addition for SSDTs support. At least with SSDTs support there is even an advantage over the DSDT-in-kernel version :-)
At one point there was a proposal to allow in-kernel SSDT overrides, but we determined that it was problematic because there can be any number of SSDTs (so which one does an override apply to?), some of them auto loaded at RSDT time, and the others loaded at run-time via Load() in the DSDT (and possibly SSDT) AML.
So we decided that to override an SSDT, you need to override a DSDT, incorporate whatever SSDT code you want into your DSDT, and boot with the "acpi_no_auto_ssdt" cmdline parameter to inhibit autoloading of the RSDT enumerated SSDTs. That gives you complete and total control over what AML gets run. (you omit that cmdline param to overide the DSDT but keep the native SSDTs) It also gives you just 1 DSDT to keep track of.
I'm not clear on how to use the proposed initrd SSDT override capability, and why it needs to be different from the simple scheme above, but I wouldn't want a mess there to hold up the rest of the initrd DSDT override patch series -- since only very rarely is an SSDT override needed.
-Len
Re: [PATCH] Override DSDT and SSDTs via initramfs
Quoted 10 lines · Len Brown
Quoted 8 lines
Quoted 3 lines
In fact, I added the array some time ago.
Not sure whether the latest Version of Eric/Markus can also load several DSDT/SSDTs? Maybe you found a more elegant way?Nope. On the website (http://gaugusch.at/kernel.shtml) you can just find two versions of the patch: one simple and one with your addition for SSDTs support. At least with SSDTs support there is even an advantage over the DSDT-in-kernel version :-)
Quoted 5 lines
At one point there was a proposal to allow in-kernel SSDT overrides, but we determined that it was problematic because there can be any number of SSDTs (so which one does an override apply to?), some of them auto loaded at RSDT time, and the others loaded at run-time via
Load()in the DSDT (and possibly SSDT) AML.
Yes and this is easy to solve via initrd.
Quoted 7 lines
So we decided that to override an SSDT, you need to override a DSDT, incorporate whatever SSDT code you want into your DSDT, and boot with the "
acpi_no_auto_ssdt" cmdline parameter to inhibit autoloading of the RSDT enumerated SSDTs. That gives you complete and total control over what AML gets run. (you omit that cmdline param to overide the DSDT but keep the native SSDTs) It also gives you just 1 DSDT to keep track of.
I know and it's a rather complex way.
You need to open the DSDT and copy and paste in an editor all SSDTs into DSDT (inside the last bracket, the global namespace, so simply attaching it at the very end is not working). Is that correct?
Quoted 1 line
That gives you complete and total control over what AML gets run
I doubt that. You said there can be any number of SSDTs. If you know what you are doing..., but how do you explain someone in a bug that he has to collect all SSDTs (some via acpidump --addr xy) open an editor, paste them into the DSDT and so on...
I know what you mean and in what pits you could fall, because I've tried it already, but...
Quoted 2 lines
I'm not clear on how to use the proposed initrd SSDT override capability, and why it needs to be different from the simple scheme above,
... it is far away from a simple scheme, sorry.
Quoted 3 lines
but I wouldn't want a mess there to hold up the rest of the initrd DSDT override patch series -- since only very rarely is an SSDT override needed.
That's true, it's not needed that often and the patch shouldn't be hold off because of that.
Let me explain again what the intend is:
You pass to initrd e.g.:
/
/DSDT.aml /SSDT1.aml /SSDT2.aml
(maybe it should be done in an own dsdt directory. Like that, one could check for each file in this directory, instead of the static array files that get checked, hmmm this possibly should decided now to avoid incompatibilities).
Anyway, say you have a directory:
/dsdt
with two SSDTs sitting there that get loaded before any other table gets loaded.
Those tables have been extracted with acpidump, disassembled with iasl -d, modified (e.g. added some debug code to get printed to syslog) and recompiled.
Those tables have the same OEM id then the original ones, right? Tables with the same OEM id (the original ones) should get ignored later automatically. IIRC I had some problems with dynamically loaded tables, don't know anymore, they are not that often used and theoretically it should just work for them also.
I haven't tried too much here, but SSDTs are used more and more often (I saw a machine with 12 SSDTs, especially on IA64 there might be dozens in the future). We should think about the problem now, before we have bugs and need to write down half a book how the reporter finally could provide some useful information.
Have I overseen something?
Thomas
Re: [PATCH] Override DSDT and SSDTs via initramfs
Quoted 9 lines · Thomas Renninger
On Thu, 2008-01-31 at 14:17 -0500, Len Brown wrote:
[skipped]
Those tables have the same OEM id then the original ones, right? Tables with the same OEM id (the original ones) should get ignored later automatically. IIRC I had some problems with dynamically loaded tables, don't know anymore, they are not that often used and theoretically it should just work for them also.
Comparing SSDT by their OEM ID is proved to not work. Right now, code checks the whole length of the table to be the same, and only then does not load it. It is not the case with any of modified tables, so original tables will be tried to load as well.
Quoted 16 lines
I haven't tried too much here, but SSDTs are used more and more often (I saw a machine with 12 SSDTs, especially on IA64 there might be dozens in the future). We should think about the problem now, before we have bugs and need to write down half a book how the reporter finally could provide some useful information.
Have I overseen something?
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
Quoted 10 lines · Alexey Starikovskiy
Quoted 9 lines · Thomas Renninger
On Thu, 2008-01-31 at 14:17 -0500, Len Brown wrote:
[skipped]
Those tables have the same OEM id then the original ones, right? Tables with the same OEM id (the original ones) should get ignored later automatically. IIRC I had some problems with dynamically loaded tables, don't know anymore, they are not that often used and theoretically it should just work for them also.
Quoted 4 lines
Comparing SSDT by their OEM ID is proved to not work. Right now, code checks the whole length of the table to be the same, and only then does not load it. It is not the case with any of modified tables, so original tables will be tried to load as well.
Ahh, now when you say it, I remember about this darkly... What a pity..., maybe just comparing the whole header (without the checksum) could be an option? Or only do this if dsdt_got_overridden flag is set (ugly, but should be sufficient).
Thomas
Quoted 8 lines
Quoted 8 lines
I haven't tried too much here, but SSDTs are used more and more often (I saw a machine with 12 SSDTs, especially on IA64 there might be dozens in the future). We should think about the problem now, before we have bugs and need to write down half a book how the reporter finally could provide some useful information.
Have I overseen something?
Damn, I have :(
Thomas
Len Brown
reviewerRe: [PATCH] Override DSDT and SSDTs via initramfs
In reply to Thomas RenningerQuoted 5 lines · Thomas Renninger
Quoted 1 line
That gives you complete and total control over what AML gets run
I doubt that. You said there can be any number of SSDTs. If you know what you are doing..., but how do you explain someone in a bug that he has to collect all SSDTs (some via acpidump --addr xy) open an editor, paste them into the DSDT and so on...
Dynamic SSDT's are loaded from OpRegions by address.
If you want to change the AML in those opregions, you have to acquire it with acpidump --addr xy. That is true no mater what override scheme you're using.
However, if you don't want to modify the dynamic SSDT, then it does not have to be dumped -- it will continue to be accessed via Load() of the opregion; and it
is totally unrelated to a DSDT or a DSDT+static-SSDT override.
I am doubtful that SSDT override support past what we have already justifies its own complexity.
-Len
cover Override DSDT via initramfs
Hello,
Here are three patches to implement the override of DSDT via initramfs. I haven't included the feature for overriding the SSDTs as it's seems it's still a bit controversial, and anyway for now there is very little need for it. It should be fairly trivial to add it later if need arises.
The patches are against 2.6.24-git-du-jour, and they have been boot-tested on my laptop.
See you,
Eric
Re: [PATCH 0/3] Override DSDT via initramfs
Quoted 9 lines · Éric Piel
Hello,
Here are three patches to implement the override of DSDT via initramfs. I haven't included the feature for overriding the SSDTs as it's seems it's still a bit controversial, and anyway for now there is very little need for it. It should be fairly trivial to add it later if need arises.
The patches are against 2.6.24-git-du-jour, and they have been boot-tested on my laptop.
I have some problems with the diff format.
Is this a git diff, incompatible with normal patch/diff tools? Hmm, I tried git-apply --check -p1, but it also didn't work for me.
Thanks,
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Override DSDT via initramfs
Quoted 8 lines · Thomas Renninger wrote/
Quoted 7 lines · Éric Piel
Hello,
Here are three patches to implement the override of DSDT via initramfs. I haven't included the feature for overriding the SSDTs as it's seems it's still a bit controversial, and anyway for now there is very little need for it. It should be fairly trivial to add it later if need arises.
Quoted 7 lines
Quoted 2 lines
The patches are against 2.6.24-git-du-jour, and they have been boot-tested on my laptop.
I have some problems with the diff format.
Is this a git diff, incompatible with normal patch/diff tools? Hmm, I tried git-apply --check -p1, but it also didn't work for me.
No, git is not to blame. It's might fault, I forgot to deactivate "format=flowed" in Thunderbird (well, I thought using an external editor was automatically avoiding the problem). So basically, you have to remove one space on each line starting with two spaces... or wait a little bit, I'll resend the patches right now!
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerRe: [PATCH 0/3] Override DSDT via initramfs
In reply to Éric PielQuoted 9 lines · Éric Piel
Hello,
Here are three patches to implement the override of DSDT via initramfs. I haven't included the feature for overriding the SSDTs as it's seems it's still a bit controversial, and anyway for now there is very little need for it. It should be fairly trivial to add it later if need arises.
The patches are against 2.6.24-git-du-jour, and they have been boot-tested on my laptop.
Thanks Eric,
I'll take Thomas, Carlos and my comments and my comments and try to address them w/ a follow-up patch tonight.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Override DSDT via initramfs
Quoted 8 lines · Len Brown wrote/
Quoted 7 lines · Éric Piel
Hello,
Here are three patches to implement the override of DSDT via initramfs. I haven't included the feature for overriding the SSDTs as it's seems it's still a bit controversial, and anyway for now there is very little need for it. It should be fairly trivial to add it later if need arises.
Quoted 8 lines
Quoted 2 lines
The patches are against 2.6.24-git-du-jour, and they have been boot-tested on my laptop.
Thanks Eric,
I'll take Thomas, Carlos and my comments and my comments and try to address them w/ a follow-up patch tonight.-Len
Ah, Great! Just for info, I had started answering the comments from Thomas and Carlos. Here is my proposed version as description for Kconfig:
With this feature you will be able to provide a customized DSDT by adding it to your initramfs. Overriding of the DSDT is mainly thought for developing/testing purposes! If you have problems with ACPI on your machine and you have fixed it up by modifying the DSDT, do not override the DSDT as a long term solution. E.g. if you add new memory to your machine, the modified DSDT will not work (BIOS would generate a slightly adjusted one). Always report bugs in a DSDT to your computer vendor and to bugzilla.kernel.org (assigned to the ACPI component).
In case your mkinitrd tool does not support this feature, a script is provided in the documentation. For more details on this option see <file:Documentation/dsdt-initrd.txt>.
If you feel like tinkering with the DSDT or might have to test a corrected DSDT one day select this option. It is safe to say Y here.
You can use it as inspiration ;-) More over, I was thinking of adding a note in dsdt-initrd.txt like this:
Do note that
the format of the table included in the initramfs is binary (iasl -ta), while if you include the DSDT straight inside the kernel, the format is hexadecimal (iasl -tc).
See you,
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerRe: [PATCH 0/3] Override DSDT via initramfs
Quoted 36 lines · Éric Piel
Quoted 8 lines · Len Brown wrote/
Quoted 7 lines · Éric Piel
Hello,
Here are three patches to implement the override of DSDT via initramfs. I haven't included the feature for overriding the SSDTs as it's seems it's still a bit controversial, and anyway for now there is very little need for it. It should be fairly trivial to add it later if need arises.
Quoted 8 lines
Quoted 2 lines
The patches are against 2.6.24-git-du-jour, and they have been boot-tested on my laptop.
Thanks Eric,
I'll take Thomas, Carlos and my comments and my comments and try to address them w/ a follow-up patch tonight.-Len
Ah, Great! Just for info, I had started answering the comments from Thomas and Carlos. Here is my proposed version as description for
Kconfig:With this feature you will be able to provide a customized DSDT by adding it to your initramfs. Overriding of the DSDT is mainly thought for developing/testing purposes! If you have problems with ACPI on your machine and you have fixed it up by modifying the DSDT, do not override the DSDT as a long term solution. E.g. if you add new memory to your machine, the modified DSDT will not work (BIOS would generate a slightly adjusted one). Always report bugs in a DSDT to your computer vendor and to bugzilla.kernel.org (assigned to the ACPI component).
In case your mkinitrd tool does not support this feature, a script is provided in the documentation. For more details on this option see <file:Documentation/dsdt-initrd.txt>.
If you feel like tinkering with the DSDT or might have to test a corrected DSDT one day select this option. It is safe to say Y here.
Quoted 6 lines
You can use it as inspiration ;-) More over, I was thinking of adding a note in dsdt-initrd.txt like this:
Do note that
the format of the table included in the initramfs is binary (iasl -ta), while if you include the DSDT straight inside the kernel, the format is hexadecimal (iasl -tc).
i think we can add that to the detailed how-to, which I'd rather have on a web page with a pointer to the latest tools etc. (yes, i hold the pen on the web page too:-)
let me send those patches now before dinner break...
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerinitrd DSDT override patch series
In reply to Éric PielOkay, Eric, here's what I've got in the tree now.
Can you give it a whirl?
thanks,
-Len
Len Brown
reviewerPATCH 1/1 ACPI: basic initramfs DSDT override support
In reply to Éric PielFrom: Éric Piel <[email protected]>
The basics of DSDT from initramfs. In case this option is selected, populate_rootfs() is called a bit earlier to have the initramfs content available during ACPI initialization.
This is a very similar path to the one available at
http://gaugusch.at/kernel.shtml but with some update in the documentation, default set to No and the change of populate_rootfs() the "Jeff Mahony way" (which avoids reading the initramfs twice).
--- Documentation/acpi/dsdt-initrd.txt | 100 ++++++++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 17 ++++++ drivers/acpi/osl.c | 73 +++++++++++++++++++++++++-- init/initramfs.c | 8 +++- init/main.c | 7 +++ 5 files changed, 200 insertions(+), 5 deletions(-) create mode 100644 Documentation/acpi/dsdt-initrd.txt
Documentation/acpi/dsdt-initrd.txt new file +100 -0
@@ -0,0 +1,100 @@ +ACPI Custom DSDT read from initramfs + +2003 by Markus Gaugusch < dsdt at gaugusch dot at > +Special thanks go to Thomas Renninger from SuSE, who updated the patch for +2.6.0 and later modified it to read inside initramfs +2004 - 2008 maintained by Eric Piel < eric dot piel at tremplin-utc dot net > + +This option is intended for people who would like to hack their DSDT and don't +want to recompile their kernel after every change. It can also be useful to +distros which offers pre-compiled kernels and want to allow their users to use +a modified DSDT. In the Kernel config, enable the initial RAM filesystem +support (in General Setup) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI +options (General Setup|ACPI Support|Read Custom DSDT from initramfs). + +A custom DSDT (Differentiated System Description Table) is useful when your +computer uses ACPI but problems occur due to broken implementation. Typically, +your computer works but there are some troubles with the hardware detection or +the power management. You can check that troubles come from errors in the DSDT by +activating the ACPI debug option and reading the logs. This table is provided +by the BIOS, therefore it might be a good idea to check for BIOS update on your +vendor website before going any further. Errors are often caused by vendors +testing their hardware only with Windows or because there is code which is +executed only on a specific OS with a specific version and Linux hasn't been +considered during the development. + +Before you run away from customising your DSDT, you should note that already +corrected tables are available for a fair amount of computers on this web-page: +http://acpi.sf.net/dsdt . Be careful though, to work correctly a DSDT has to +match closely the hardware, including the amount of RAM, the frequency of the +processor and the PCI cards present! If you are part of the unluckies who +cannot find their hardware in this database, you can modify your DSDT by +yourself. This process is less painful than it sounds. Download the Intel ASL +compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm . +As root, you then have to dump your DSDT and decompile it. By using the +compiler messages as well as the kernel ACPI debug messages and the reference +book (available at the Intel website and also at http://www.acpi.info), it is +quite easy to obtain a fully working table. + +Once your new DSDT is ready you'll have to add it to an initramfs so that the +kernel can read the table at the very beginning of the boot. As the file has to +be accessed very early during the boot process the initramfs has to be an +initramfs. The file is contained into the initramfs under the name /DSDT.aml . +To obtain such an initramfs, you might have to modify your initramfs script or +you can add it later to the initramfs with the script appended to this +document. The command will look like: +initramfs-add-dsdt initramfs.img my-dsdt.aml + +In case you don't use any initramfs, the possibilities you have are to either +start using one (try mkinitrd or yaird), or use the "Include Custom DSDT" +configure option to directly include your DSDT inside the kernel. + +The message "Looking for DSDT in initramfs..." will tell you if the DSDT was +found or not. If you need to update your DSDT, generate a new initramfs and +perform the steps above. Don't forget that with Lilo, you'll have to re-run it. + + +====================== Here starts initramfs-add-dsdt ========================== +#!/bin/bash +# Adds a DSDT file to the initrd (if it's an initramfs) +# first argument is the name of archive +# second argument is the name of the file to add +# The file will be copied as /DSDT.aml + +# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) +# 20060205: this time it should really work + +# check the arguments +if [ $# -ne 2 ]; then + program_name=$(basename $0) + echo "\ +$program_name: too few arguments +Usage: $program_name initrd-name.img DSDT-to-add.aml +Adds a DSDT file to an initrd (in initramfs format) + + initrd-name.img: filename of the initrd in initramfs format + DSDT-to-add.aml: filename of the DSDT file to add + " 1>&2 + exit 1 +fi + +# we should check it's an initramfs + +tempcpio=$(mktemp -d) +# cleanup on exit, hangup, interrupt, quit, termination +trap 'rm -rf $tempcpio' 0 1 2 3 15 + +# extract the archive +gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 + +# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" +cp -f "$2" "$tempcpio"/DSDT.aml + +# add the file +cd "$tempcpio" +(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 +cd "$OLDPWD" + +# re-compress the archive +gzip -c "$tempcpio"/initramfs.cpio > "$1" +
drivers/acpi/Kconfig +17 -0
@@ -274,6 +274,23 @@ config ACPI_CUSTOM_DSDT_FILE Enter the full path name to the file which includes the AmlCode declaration. +config ACPI_CUSTOM_DSDT_INITRD + bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default n + help + The DSDT (Differentiated System Description Table) often needs to be + overridden because of broken BIOS implementations. If this feature is + activated you will be able to provide a customized DSDT by adding it + to your initramfs. If your mkinitrd tool does not support this feature + a script is provided in the documentation. For more details see + <file:Documentation/dsdt-initrd.txt> or <http://gaugusch.at/kernel.shtml>. + If there is no table found, it will fall-back to the custom DSDT + in-kernel (if activated) or to the DSDT from the BIOS. + + Even if you do not need a new one at the moment, you may want to use a + better DSDT later. It is safe to say Y here. + config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0
drivers/acpi/osl.c +69 -4
88 lines not on this page · raw message
init/initramfs.c +7 -1
@@ -538,7 +538,7 @@ skip: initrd_end =0 ; } -static int __init populate_rootfs (void ) +int __init populate_rootfs (void ) {char *err =unpack_to_rootfs (__initramfs_start, __initramfs_end - __initramfs_start,0 );
@@ -577,4 +577,10 @@ static int __init populate_rootfs(void) }return 0 ; } +#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD +/* +* if this option is enabled, populate_rootfs() is called _earlier_ in the +* boot sequence. This insures that the ACPI initialisation can find the file. +*/ rootfs_initcall (populate_rootfs); +#endif
init/main.c +7 -0
@@ -102,6 +102,12 @@ static inline void mark_rodata_ro(void) { }extern void tc_init (void );#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +extern int populate_rootfs (void ); +#else +static inline void populate_rootfs (void ) {} +#endif +enum system_states system_state;EXPORT_SYMBOL (system_state);
@@ -648,6 +654,7 @@ asmlinkage void __init start_kernel(void)check_bugs (); +populate_rootfs ();/* For DSDT override from initramfs */ acpi_early_init ();/* before LAPIC and SMP init */ /* Do the rest non-__init'ed, we're now alive */
Signature · 6 lines
1.5.4.23.gef5b9 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerPATCH 1/1 ACPI: Taint kernel on ACPI table override (format corrected)
In reply to Éric PielFrom: Éric Piel <[email protected]>
When an ACPI table is overridden (for now this can happen only for DSDT) display a big warning and taint the kernel with flag A.
--- drivers/acpi/osl.c | 7 +++++++ include/linux/kernel.h | 1 + kernel/panic.c | 5 +++-- 3 files changed, 11 insertions(+), 2 deletions(-)
drivers/acpi/osl.c +7 -0
@@ -392,6 +392,13 @@ acpi_os_table_override(struct acpi_table_header * existing_table, *new_table = initrd_table; }#endif +if (*new_table !=NULL ) { + printk(KERN_WARNING PREFIX "Override [%4.4s-%8.8s], " +"this is unsafe: tainting kernel\n" , + existing_table->signature, + existing_table->oem_table_id); +add_taint (TAINT_OVERRIDDEN_ACPI_TABLE ); + }return AE_OK ; }
include/linux/kernel.h +1 -0
@@ -243,6 +243,7 @@ extern enum system_states {#define TAINT_BAD_PAGE (1<<5)#define TAINT_USER (1<<6)#define TAINT_DIE (1<<7) +#define TAINT_OVERRIDDEN_ACPI_TABLE (1<<8)extern void dump_stack (void )__cold ;
kernel/panic.c +3 -2
@@ -161,7 +161,7 @@ const char *print_tainted(void) {static char buf[20 ];if (tainted) { - snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c", + snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c%c", tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G', tainted & TAINT_FORCED_MODULE ? 'F' : ' ', tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
@@ -169,7 +169,8 @@ const char *print_tainted(void) tainted &TAINT_MACHINE_CHECK ?'M' :' ' , tainted &TAINT_BAD_PAGE ?'B' :' ' , tainted &TAINT_USER ?'U' :' ' , - tainted & TAINT_DIE ? 'D' : ' '); + tainted &TAINT_DIE ?'D' :' ' , + tainted & TAINT_OVERRIDDEN_ACPI_TABLE ? 'A' : ' '); }else snprintf (buf,sizeof (buf),"Not tainted" );
Signature · 6 lines
1.5.4.23.gef5b9 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerPATCH 1/1 ACPI: Add "acpi_no_initrd_override" kernel parameter
In reply to Éric PielFrom: Éric Piel <[email protected]>
The acpi_no_initrd_override parameter permits to disable the load of an ACPI table from the initramfs.
--- Documentation/kernel-parameters.txt | 3 +++ drivers/acpi/osl.c | 14 +++++++++++++- 2 files changed, 16 insertions(+), 1 deletions(-)
Documentation/kernel-parameters.txt +3 -0
@@ -175,6 +175,9 @@ and is between 256 and 4096 characters. It is defined in the file acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT + acpi_no_initrd_override [KNL,ACPI] + Disable loading custom ACPI tables from the initramfs + acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows"
drivers/acpi/osl.c +13 -1
@@ -77,6 +77,10 @@ static struct workqueue_struct *kacpi_notify_wq;#define OSI_STRING_LENGTH_MAX 64/* arbitrary */ static char osi_additional_string[OSI_STRING_LENGTH_MAX ]; +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +static int acpi_no_initrd_override; +#endif +/* * "Ode to _OSI(Linux)" *
@@ -386,7 +390,8 @@ acpi_os_table_override(struct acpi_table_header * existing_table, *new_table = (struct acpi_table_header *)AmlCode;#endif #ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD -if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) { +if ((strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) && + !acpi_no_initrd_override) {struct acpi_table_header *initrd_table =acpi_find_dsdt_initrd ();if (initrd_table) *new_table = initrd_table;
@@ -402,6 +407,13 @@ acpi_os_table_override(struct acpi_table_header * existing_table,return AE_OK ; } +int __init acpi_no_initrd_override_setup (char *s) +{ + acpi_no_initrd_override =1 ; +return 1 ; +} +__setup ("acpi_no_initrd_override" , acpi_no_initrd_override_setup); +static irqreturn_t acpi_irq (int irq,void *dev_id) {return (*acpi_irq_handler) (acpi_irq_context) ?IRQ_HANDLED :IRQ_NONE ;
Signature · 6 lines
1.5.4.23.gef5b9 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerPATCH 1/1 ACPI: update DSDT override documentation
In reply to Éric PielFrom: Len Brown <[email protected]>
--- Documentation/acpi/dsdt-initrd.txt | 100 ------------------------------ Documentation/acpi/dsdt-override.txt | 15 +++++ Documentation/acpi/initramfs-add-dsdt.sh | 43 +++++++++++++ drivers/acpi/Kconfig | 22 +++---- 4 files changed, 67 insertions(+), 113 deletions(-) delete mode 100644 Documentation/acpi/dsdt-initrd.txt create mode 100644 Documentation/acpi/dsdt-override.txt create mode 100755 Documentation/acpi/initramfs-add-dsdt.sh
Documentation/acpi/dsdt-initrd.txt deleted +0 -100
@@ -1,100 +0,0 @@ -ACPI Custom DSDT read from initramfs - -2003 by Markus Gaugusch < dsdt at gaugusch dot at > -Special thanks go to Thomas Renninger from SuSE, who updated the patch for -2.6.0 and later modified it to read inside initramfs -2004 - 2008 maintained by Eric Piel < eric dot piel at tremplin-utc dot net > - -This option is intended for people who would like to hack their DSDT and don't -want to recompile their kernel after every change. It can also be useful to -distros which offers pre-compiled kernels and want to allow their users to use -a modified DSDT. In the Kernel config, enable the initial RAM filesystem -support (in General Setup) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI -options (General Setup|ACPI Support|Read Custom DSDT from initramfs). - -A custom DSDT (Differentiated System Description Table) is useful when your -computer uses ACPI but problems occur due to broken implementation. Typically, -your computer works but there are some troubles with the hardware detection or -the power management. You can check that troubles come from errors in the DSDT by -activating the ACPI debug option and reading the logs. This table is provided -by the BIOS, therefore it might be a good idea to check for BIOS update on your -vendor website before going any further. Errors are often caused by vendors -testing their hardware only with Windows or because there is code which is -executed only on a specific OS with a specific version and Linux hasn't been -considered during the development. - -Before you run away from customising your DSDT, you should note that already -corrected tables are available for a fair amount of computers on this web-page: -http://acpi.sf.net/dsdt . Be careful though, to work correctly a DSDT has to -match closely the hardware, including the amount of RAM, the frequency of the -processor and the PCI cards present! If you are part of the unluckies who -cannot find their hardware in this database, you can modify your DSDT by -yourself. This process is less painful than it sounds. Download the Intel ASL -compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm . -As root, you then have to dump your DSDT and decompile it. By using the -compiler messages as well as the kernel ACPI debug messages and the reference -book (available at the Intel website and also at http://www.acpi.info), it is -quite easy to obtain a fully working table. - -Once your new DSDT is ready you'll have to add it to an initramfs so that the -kernel can read the table at the very beginning of the boot. As the file has to -be accessed very early during the boot process the initramfs has to be an -initramfs. The file is contained into the initramfs under the name /DSDT.aml . -To obtain such an initramfs, you might have to modify your initramfs script or -you can add it later to the initramfs with the script appended to this -document. The command will look like: -initramfs-add-dsdt initramfs.img my-dsdt.aml - -In case you don't use any initramfs, the possibilities you have are to either -start using one (try mkinitrd or yaird), or use the "Include Custom DSDT" -configure option to directly include your DSDT inside the kernel. - -The message "Looking for DSDT in initramfs..." will tell you if the DSDT was -found or not. If you need to update your DSDT, generate a new initramfs and -perform the steps above. Don't forget that with Lilo, you'll have to re-run it. - - -====================== Here starts initramfs-add-dsdt ========================== -#!/bin/bash -# Adds a DSDT file to the initrd (if it's an initramfs) -# first argument is the name of archive -# second argument is the name of the file to add -# The file will be copied as /DSDT.aml - -# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) -# 20060205: this time it should really work - -# check the arguments -if [ $# -ne 2 ]; then - program_name=$(basename $0) - echo "\ -$program_name: too few arguments -Usage: $program_name initrd-name.img DSDT-to-add.aml -Adds a DSDT file to an initrd (in initramfs format) - - initrd-name.img: filename of the initrd in initramfs format - DSDT-to-add.aml: filename of the DSDT file to add - " 1>&2 - exit 1 -fi - -# we should check it's an initramfs - -tempcpio=$(mktemp -d) -# cleanup on exit, hangup, interrupt, quit, termination -trap 'rm -rf $tempcpio' 0 1 2 3 15 - -# extract the archive -gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 - -# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" -cp -f "$2" "$tempcpio"/DSDT.aml - -# add the file -cd "$tempcpio" -(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 -cd "$OLDPWD" - -# re-compress the archive -gzip -c "$tempcpio"/initramfs.cpio > "$1" -
Documentation/acpi/dsdt-override.txt new file +15 -0
@@ -0,0 +1,15 @@ +Linux supports two methods of overriding the BIOS DSDT: + +CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel. + +CONFIG_ACPI_CUSTOM_DSDT_INITRD adds the image to the initrd. + +When to use these methods is described in detail on the +Linux/ACPI home page: +http://www.lesswatts.org/projects/acpi/overridingDSDT.php + +Note that if both options are used, the DSDT supplied +by the INITRD method takes precedence. + +Documentation/initramfs-add-dsdt.sh is provided for convenience +for use with the CONFIG_ACPI_CUSTOM_DSDT_INITRD method.
Documentation/acpi/initramfs-add-dsdt.sh new file +43 -0
43 lines not on this page · raw message
drivers/acpi/Kconfig +9 -13
@@ -263,8 +263,10 @@ config ACPI_CUSTOM_DSDT depends on !STANDALONE default n help - This option is to load a custom ACPI DSDT - If you don't know what that is, say N. + This option supports a custom DSDT by linking it into the kernel. + See Documentation/acpi/dsdt-override.txt + + If unsure, say N. config ACPI_CUSTOM_DSDT_FILE string "Custom DSDT Table file to include"
@@ -279,17 +281,11 @@ config ACPI_CUSTOM_DSDT_INITRD depends on BLK_DEV_INITRD default n help - The DSDT (Differentiated System Description Table) often needs to be - overridden because of broken BIOS implementations. If this feature is - activated you will be able to provide a customized DSDT by adding it - to your initramfs. If your mkinitrd tool does not support this feature - a script is provided in the documentation. For more details see - <file:Documentation/dsdt-initrd.txt> or <http://gaugusch.at/kernel.shtml>. - If there is no table found, it will fall-back to the custom DSDT - in-kernel (if activated) or to the DSDT from the BIOS. - - Even if you do not need a new one at the moment, you may want to use a - better DSDT later. It is safe to say Y here. + This option supports a custom DSDT by optionally loading it from initrd. + See Documentation/acpi/dsdt-override.txt + + If you are not using this feature now, but may use it later, + it is safe to say Y here. config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32
Signature · 1 line
1.5.4.23.gef5b9
Len Brown
reviewerPATCH 1/1 ACPI: update intrd DSDT override console messages
In reply to Éric PielFrom: Len Brown <[email protected]>
also, address some checkpatch.pl violations
--- drivers/acpi/osl.c | 33 ++++++++++++++++++--------------- 1 files changed, 18 insertions(+), 15 deletions(-)
drivers/acpi/osl.c +18 -15
@@ -326,49 +326,50 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)struct kstat stat;char *ramfs_dsdt_name ="/DSDT.aml" ; - printk(KERN_INFO PREFIX "Looking for DSDT in initramfs... "); + printk(KERN_INFO PREFIX "Checking initramfs for custom DSDT");/* * Never do this at home, only the user-space is allowed to open a file. -* The clean way would be to use the firmware loader. But this code must be run -* before there is any userspace available. So we need a static/init firmware -* infrastructure, which doesn't exist yet... +* The clean way would be to use the firmware loader. +* But this code must be run before there is any userspace available. +* A static/init firmware infrastructure doesn't exist yet... */ -if (vfs_stat (ramfs_dsdt_name, &stat) <0 ) { -printk ("not found.\n" ); +if (vfs_stat (ramfs_dsdt_name, &stat) <0 )return ret; - } len = stat.size;/* check especially against empty files */ if (len <=4 ) { -printk ("error, file is too small: only %lu bytes.\n" , len); + printk(KERN_ERR PREFIX "Failed: DSDT only %lu bytes.\n", len);return ret; } firmware_file =filp_open (ramfs_dsdt_name,O_RDONLY ,0 );if (IS_ERR (firmware_file)) { -printk ("error, could not open file %s.\n" , ramfs_dsdt_name); + printk(KERN_ERR PREFIX "Failed to open %s.\n", ramfs_dsdt_name);return ret; } - dsdt_buffer =ACPI_ALLOCATE (len); + dsdt_buffer =kmalloc (len,GFP_ATOMIC );if (!dsdt_buffer) { -printk ("error when allocating %lu bytes of memory.\n" , len); + printk(KERN_ERR PREFIX "Failed to allocate %lu bytes.\n", len); goto err; } oldfs =get_fs ();set_fs (KERNEL_DS ); - len2 =vfs_read (firmware_file, (char __user *)dsdt_buffer, len, &firmware_file->f_pos); + len2 =vfs_read (firmware_file, (char __user *)dsdt_buffer, len, + &firmware_file->f_pos);set_fs (oldfs);if (len2 < len) { -printk ("error trying to read %lu bytes from %s.\n" , len, ramfs_dsdt_name); + printk(KERN_ERR PREFIX "Failed to read %lu bytes from %s.\n", + len, ramfs_dsdt_name);ACPI_FREE (dsdt_buffer); goto err; } -printk ("successfully read %lu bytes from %s.\n" , len, ramfs_dsdt_name); + printk(KERN_INFO PREFIX "Found %lu byte DSDT in %s.\n", + len, ramfs_dsdt_name); ret = dsdt_buffer; err:filp_close (firmware_file,NULL );
@@ -392,7 +393,9 @@ acpi_os_table_override(struct acpi_table_header * existing_table,#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD if ((strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) && !acpi_no_initrd_override) { -struct acpi_table_header *initrd_table =acpi_find_dsdt_initrd (); +struct acpi_table_header *initrd_table; + + initrd_table =acpi_find_dsdt_initrd ();if (initrd_table) *new_table = initrd_table; }
Signature · 1 line
1.5.4.23.gef5b9
PATCH 1/3 The basics of DSDT from initramfs
In reply to Len BrownThe basics of DSDT from initramfs. In case this option is selected, populate_rootfs() is called a bit earlier to have the initramfs content available during ACPI initialisation.
This is a very similar path to the one available at
http://gaugusch.at/kernel.shtml but with some update in the documentation, default set to No and the change of populate_rootfs() the "Jeff Mahony way" (which avoids reading the initramfs twice).
--- Documentation/dsdt-initrd.txt | 100 +++++++++++++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 17 +++++++ drivers/acpi/osl.c | 73 ++++++++++++++++++++++++++++-- init/initramfs.c | 8 +++- init/main.c | 7 +++ 5 files changed, 200 insertions(+), 5 deletions(-) create mode 100644 Documentation/dsdt-initrd.txt
Documentation/dsdt-initrd.txt new file +100 -0
@@ -0,0 +1,100 @@ +ACPI Custom DSDT read from initramfs + +2003 by Markuss Gaugusch < dsdt at gaugusch dot org > +Special thanks go to Thomas Renninger from SuSE, who updated the patch for +2.6.0 and later modified it to read inside initramfs +2004 - 2008 maintained by Eric Piel < eric dot piel at tremplin-utc dot net > + +This option is intended for people who would like to hack their DSDT and don't +want to recompile their kernel after every change. It can also be useful to +distros which offers pre-compiled kernels and want to allow their users to use +a modified DSDT. In the Kernel config, enable the initial RAM filesystem +support (in General Setup) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI +options (General Setup|ACPI Support|Read Custom DSDT from initramfs). + +A custom DSDT (Differentiated System Description Table) is useful when your +computer uses ACPI but problems occur due to broken implementation. Typically, +your computer works but there are some troubles with the hardware detection or +the power management. You can check that troubles come from errors in the DSDT by +activating the ACPI debug option and reading the logs. This table is provided +by the BIOS, therefore it might be a good idea to check for BIOS update on your +vendor website before going any further. Errors are often caused by vendors +testing their hardware only with Windows or because there is code which is +executed only on a specific OS with a specific version and Linux hasn't been +considered during the development. + +Before you run away from customising your DSDT, you should note that already +corrected tables are available for a fair amount of computers on this web-page: +http://acpi.sf.net/dsdt . Be careful though, to work correctly a DSDT has to +match closely the hardware, including the amount of RAM, the frequency of the +processor and the PCI cards present! If you are part of the unluckies who +cannot find their hardware in this database, you can modify your DSDT by +yourself. This process is less painful than it sounds. Download the Intel ASL +compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm . +As root, you then have to dump your DSDT and decompile it. By using the +compiler messages as well as the kernel ACPI debug messages and the reference +book (available at the Intel website and also at http://www.acpi.info), it is +quite easy to obtain a fully working table. + +Once your new DSDT is ready you'll have to add it to an initramfs so that the +kernel can read the table at the very beginning of the boot. As the file has to +be accessed very early during the boot process the initramfs has to be an +initramfs. The file is contained into the initramfs under the name /DSDT.aml . +To obtain such an initramfs, you might have to modify your initramfs script or +you can add it later to the initramfs with the script appended to this +document. The command will look like: +initramfs-add-dsdt initramfs.img my-dsdt.aml + +In case you don't use any initramfs, the possibilities you have are to either +start using one (try mkinitrd or yaird), or use the "Include Custom DSDT" +configure option to directly include your DSDT inside the kernel. + +The message "Looking for DSDT in initramfs..." will tell you if the DSDT was +found or not. If you need to update your DSDT, generate a new initramfs and +perform the steps above. Don't forget that with Lilo, you'll have to re-run it. + + +====================== Here starts initramfs-add-dsdt ========================== +#!/bin/bash +# Adds a DSDT file to the initrd (if it's an initramfs) +# first argument is the name of archive +# second argument is the name of the file to add +# The file will be copied as /DSDT.aml + +# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) +# 20060205: this time it should really work + +# check the arguments +if [ $# -ne 2 ]; then + program_name=$(basename $0) + echo "\ +$program_name: too few arguments +Usage: $program_name initrd-name.img DSDT-to-add.aml +Adds a DSDT file to an initrd (in initramfs format) + + initrd-name.img: filename of the initrd in initramfs format + DSDT-to-add.aml: filename of the DSDT file to add + " 1>&2 + exit 1 +fi + +# we should check it's an initramfs + +tempcpio=$(mktemp -d) +# cleanup on exit, hangup, interrupt, quit, termination +trap 'rm -rf $tempcpio' 0 1 2 3 15 + +# extract the archive +gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 + +# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" +cp -f "$2" "$tempcpio"/DSDT.aml + +# add the file +cd "$tempcpio" +(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 +cd "$OLDPWD" + +# re-compress the archive +gzip -c "$tempcpio"/initramfs.cpio > "$1" +
drivers/acpi/Kconfig +17 -0
@@ -274,6 +274,23 @@ config ACPI_CUSTOM_DSDT_FILE Enter the full path name to the file which includes the AmlCode declaration. +config ACPI_CUSTOM_DSDT_INITRD + bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default n + help + The DSDT (Differentiated System Description Table) often needs to be + overridden because of broken BIOS implementations. If this feature is + activated you will be able to provide a customized DSDT by adding it + to your initramfs. If your mkinitrd tool does not support this feature + a script is provided in the documentation. For more details see + <file:Documentation/dsdt-initrd.txt> or <http://gaugusch.at/kernel.shtml>. + If there is no table found, it will fall-back to the custom DSDT + in-kernel (if activated) or to the DSDT from the BIOS. + + Even if you do not need a new one at the moment, you may want to use a + better DSDT later. It is safe to say Y here. + config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0
drivers/acpi/osl.c +69 -4
88 lines not on this page · raw message
init/initramfs.c +7 -1
@@ -541,7 +541,7 @@ skip:#endif -static int __init populate_rootfs (void ) +int __init populate_rootfs (void ) {char *err =unpack_to_rootfs (__initramfs_start, __initramfs_end - __initramfs_start,0 );
@@ -582,4 +582,10 @@ static int __init populate_rootfs(void)#endif return 0 ; } +#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD +/* +* if this option is enabled, populate_rootfs() is called _earlier_ in the +* boot sequence. This insures that the ACPI initialisation can find the file. +*/ rootfs_initcall (populate_rootfs); +#endif
init/main.c +7 -0
@@ -102,6 +102,12 @@ static inline void mark_rodata_ro(void) { }extern void tc_init (void );#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +extern int populate_rootfs (void ); +#else +static inline void populate_rootfs (void ) {} +#endif +enum system_states system_state;EXPORT_SYMBOL (system_state);
@@ -643,6 +649,7 @@ asmlinkage void __init start_kernel(void)check_bugs (); +populate_rootfs ();/* For DSDT override from initramfs */ acpi_early_init ();/* before LAPIC and SMP init */ /* Do the rest non-__init'ed, we're now alive */
Re: [PATCH 1/3] The basics of DSDT from initramfs
Documentation/dsdt-initrd.txt line 3
Quoted 9 lines · Éric Piel
Documentation/dsdt-initrd.txt new file +3
-0@@ -0,0 +1,100 @@ +ACPI Custom DSDT read from initramfs + +2003 by Markuss Gaugusch < dsdt at gaugusch dot org >
Hi,
My email address is dsdt at gaugusch dot at (not "dot org") And the Markus has only one "s".
It's great to see that the little project which I started some years ago is now in the kernel :)
regards,
Markus
Signature · 4 lines
__________________ /"\
Markus Gaugusch \ / ASCII Ribbon Campaign
markus(at)gaugusch.at X Against HTML Mail
/ \Re: [PATCH 1/3] The basics of DSDT from initramfs
Quoted 3 lines · Markus Gaugusch wrote/
Hi,
My email address is dsdt at gaugusch dot at (not "dot org") And the Markus has only one "s".
Duh! It was too simple for me to notice ;-) Sorry, here is a fixed version.
See you,
Eric
--
The basics of DSDT from initramfs. In case this option is selected, populate_rootfs() is called a bit earlier to have the initramfs content available during ACPI initialisation.
This is a very similar path to the one available at
http://gaugusch.at/kernel.shtml but with some update in the documentation, default set to No and the change of populate_rootfs() the "Jeff Mahony way" (which avoids reading the initramfs twice).
--- Documentation/dsdt-initrd.txt | 100 +++++++++++++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 17 +++++++ drivers/acpi/osl.c | 73 ++++++++++++++++++++++++++++-- init/initramfs.c | 8 +++- init/main.c | 7 +++ 5 files changed, 200 insertions(+), 5 deletions(-) create mode 100644 Documentation/dsdt-initrd.txt
Documentation/dsdt-initrd.txt new file +100 -0
@@ -0,0 +1,100 @@ +ACPI Custom DSDT read from initramfs + +2003 by Markus Gaugusch < dsdt at gaugusch dot at > +Special thanks go to Thomas Renninger from SuSE, who updated the patch for +2.6.0 and later modified it to read inside initramfs +2004 - 2008 maintained by Eric Piel < eric dot piel at tremplin-utc dot net > + +This option is intended for people who would like to hack their DSDT and don't +want to recompile their kernel after every change. It can also be useful to +distros which offers pre-compiled kernels and want to allow their users to use +a modified DSDT. In the Kernel config, enable the initial RAM filesystem +support (in General Setup) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI +options (General Setup|ACPI Support|Read Custom DSDT from initramfs). + +A custom DSDT (Differentiated System Description Table) is useful when your +computer uses ACPI but problems occur due to broken implementation. Typically, +your computer works but there are some troubles with the hardware detection or +the power management. You can check that troubles come from errors in the DSDT by +activating the ACPI debug option and reading the logs. This table is provided +by the BIOS, therefore it might be a good idea to check for BIOS update on your +vendor website before going any further. Errors are often caused by vendors +testing their hardware only with Windows or because there is code which is +executed only on a specific OS with a specific version and Linux hasn't been +considered during the development. + +Before you run away from customising your DSDT, you should note that already +corrected tables are available for a fair amount of computers on this web-page: +http://acpi.sf.net/dsdt . Be careful though, to work correctly a DSDT has to +match closely the hardware, including the amount of RAM, the frequency of the +processor and the PCI cards present! If you are part of the unluckies who +cannot find their hardware in this database, you can modify your DSDT by +yourself. This process is less painful than it sounds. Download the Intel ASL +compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm . +As root, you then have to dump your DSDT and decompile it. By using the +compiler messages as well as the kernel ACPI debug messages and the reference +book (available at the Intel website and also at http://www.acpi.info), it is +quite easy to obtain a fully working table. + +Once your new DSDT is ready you'll have to add it to an initramfs so that the +kernel can read the table at the very beginning of the boot. As the file has to +be accessed very early during the boot process the initramfs has to be an +initramfs. The file is contained into the initramfs under the name /DSDT.aml . +To obtain such an initramfs, you might have to modify your initramfs script or +you can add it later to the initramfs with the script appended to this +document. The command will look like: +initramfs-add-dsdt initramfs.img my-dsdt.aml + +In case you don't use any initramfs, the possibilities you have are to either +start using one (try mkinitrd or yaird), or use the "Include Custom DSDT" +configure option to directly include your DSDT inside the kernel. + +The message "Looking for DSDT in initramfs..." will tell you if the DSDT was +found or not. If you need to update your DSDT, generate a new initramfs and +perform the steps above. Don't forget that with Lilo, you'll have to re-run it. + + +====================== Here starts initramfs-add-dsdt ========================== +#!/bin/bash +# Adds a DSDT file to the initrd (if it's an initramfs) +# first argument is the name of archive +# second argument is the name of the file to add +# The file will be copied as /DSDT.aml + +# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) +# 20060205: this time it should really work + +# check the arguments +if [ $# -ne 2 ]; then + program_name=$(basename $0) + echo "\ +$program_name: too few arguments +Usage: $program_name initrd-name.img DSDT-to-add.aml +Adds a DSDT file to an initrd (in initramfs format) + + initrd-name.img: filename of the initrd in initramfs format + DSDT-to-add.aml: filename of the DSDT file to add + " 1>&2 + exit 1 +fi + +# we should check it's an initramfs + +tempcpio=$(mktemp -d) +# cleanup on exit, hangup, interrupt, quit, termination +trap 'rm -rf $tempcpio' 0 1 2 3 15 + +# extract the archive +gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 + +# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" +cp -f "$2" "$tempcpio"/DSDT.aml + +# add the file +cd "$tempcpio" +(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 +cd "$OLDPWD" + +# re-compress the archive +gzip -c "$tempcpio"/initramfs.cpio > "$1" +
drivers/acpi/Kconfig +17 -0
@@ -274,6 +274,23 @@ config ACPI_CUSTOM_DSDT_FILE Enter the full path name to the file which includes the AmlCode declaration. +config ACPI_CUSTOM_DSDT_INITRD + bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default n + help + The DSDT (Differentiated System Description Table) often needs to be + overridden because of broken BIOS implementations. If this feature is + activated you will be able to provide a customized DSDT by adding it + to your initramfs. If your mkinitrd tool does not support this feature + a script is provided in the documentation. For more details see + <file:Documentation/dsdt-initrd.txt> or <http://gaugusch.at/kernel.shtml>. + If there is no table found, it will fall-back to the custom DSDT + in-kernel (if activated) or to the DSDT from the BIOS. + + Even if you do not need a new one at the moment, you may want to use a + better DSDT later. It is safe to say Y here. + config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0
drivers/acpi/osl.c +69 -4
88 lines not on this page · raw message
init/initramfs.c +7 -1
@@ -541,7 +541,7 @@ skip:#endif -static int __init populate_rootfs (void ) +int __init populate_rootfs (void ) {char *err =unpack_to_rootfs (__initramfs_start, __initramfs_end - __initramfs_start,0 );
@@ -582,4 +582,10 @@ static int __init populate_rootfs(void)#endif return 0 ; } +#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD +/* +* if this option is enabled, populate_rootfs() is called _earlier_ in the +* boot sequence. This insures that the ACPI initialisation can find the file. +*/ rootfs_initcall (populate_rootfs); +#endif
init/main.c +7 -0
@@ -102,6 +102,12 @@ static inline void mark_rodata_ro(void) { }extern void tc_init (void );#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +extern int populate_rootfs (void ); +#else +static inline void populate_rootfs (void ) {} +#endif +enum system_states system_state;EXPORT_SYMBOL (system_state);
@@ -643,6 +649,7 @@ asmlinkage void __init start_kernel(void)check_bugs (); +populate_rootfs ();/* For DSDT override from initramfs */ acpi_early_init ();/* before LAPIC and SMP init */ /* Do the rest non-__init'ed, we're now alive */
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] The basics of DSDT from initramfs (format corrected)
The basics of DSDT from initramfs. In case this option is selected, populate_rootfs() is called a bit earlier to have the initramfs content available during ACPI initialization.
This is a very similar path to the one available at
http://gaugusch.at/kernel.shtml but with some update in the documentation, default set to No and the change of populate_rootfs() the "Jeff Mahony way" (which avoids reading the initramfs twice).
--- Documentation/dsdt-initrd.txt | 100 +++++++++++++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 17 +++++++ drivers/acpi/osl.c | 73 ++++++++++++++++++++++++++++-- init/initramfs.c | 8 +++- init/main.c | 7 +++ 5 files changed, 200 insertions(+), 5 deletions(-) create mode 100644 Documentation/dsdt-initrd.txt
Documentation/dsdt-initrd.txt new file +100 -0
@@ -0,0 +1,100 @@ +ACPI Custom DSDT read from initramfs + +2003 by Markus Gaugusch < dsdt at gaugusch dot at > +Special thanks go to Thomas Renninger from SuSE, who updated the patch for +2.6.0 and later modified it to read inside initramfs +2004 - 2008 maintained by Eric Piel < eric dot piel at tremplin-utc dot net > + +This option is intended for people who would like to hack their DSDT and don't +want to recompile their kernel after every change. It can also be useful to +distros which offers pre-compiled kernels and want to allow their users to use +a modified DSDT. In the Kernel config, enable the initial RAM filesystem +support (in General Setup) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI +options (General Setup|ACPI Support|Read Custom DSDT from initramfs). + +A custom DSDT (Differentiated System Description Table) is useful when your +computer uses ACPI but problems occur due to broken implementation. Typically, +your computer works but there are some troubles with the hardware detection or +the power management. You can check that troubles come from errors in the DSDT by +activating the ACPI debug option and reading the logs. This table is provided +by the BIOS, therefore it might be a good idea to check for BIOS update on your +vendor website before going any further. Errors are often caused by vendors +testing their hardware only with Windows or because there is code which is +executed only on a specific OS with a specific version and Linux hasn't been +considered during the development. + +Before you run away from customising your DSDT, you should note that already +corrected tables are available for a fair amount of computers on this web-page: +http://acpi.sf.net/dsdt . Be careful though, to work correctly a DSDT has to +match closely the hardware, including the amount of RAM, the frequency of the +processor and the PCI cards present! If you are part of the unluckies who +cannot find their hardware in this database, you can modify your DSDT by +yourself. This process is less painful than it sounds. Download the Intel ASL +compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm . +As root, you then have to dump your DSDT and decompile it. By using the +compiler messages as well as the kernel ACPI debug messages and the reference +book (available at the Intel website and also at http://www.acpi.info), it is +quite easy to obtain a fully working table. + +Once your new DSDT is ready you'll have to add it to an initramfs so that the +kernel can read the table at the very beginning of the boot. As the file has to +be accessed very early during the boot process the initramfs has to be an +initramfs. The file is contained into the initramfs under the name /DSDT.aml . +To obtain such an initramfs, you might have to modify your initramfs script or +you can add it later to the initramfs with the script appended to this +document. The command will look like: +initramfs-add-dsdt initramfs.img my-dsdt.aml + +In case you don't use any initramfs, the possibilities you have are to either +start using one (try mkinitrd or yaird), or use the "Include Custom DSDT" +configure option to directly include your DSDT inside the kernel. + +The message "Looking for DSDT in initramfs..." will tell you if the DSDT was +found or not. If you need to update your DSDT, generate a new initramfs and +perform the steps above. Don't forget that with Lilo, you'll have to re-run it. + + +====================== Here starts initramfs-add-dsdt ========================== +#!/bin/bash +# Adds a DSDT file to the initrd (if it's an initramfs) +# first argument is the name of archive +# second argument is the name of the file to add +# The file will be copied as /DSDT.aml + +# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) +# 20060205: this time it should really work + +# check the arguments +if [ $# -ne 2 ]; then + program_name=$(basename $0) + echo "\ +$program_name: too few arguments +Usage: $program_name initrd-name.img DSDT-to-add.aml +Adds a DSDT file to an initrd (in initramfs format) + + initrd-name.img: filename of the initrd in initramfs format + DSDT-to-add.aml: filename of the DSDT file to add + " 1>&2 + exit 1 +fi + +# we should check it's an initramfs + +tempcpio=$(mktemp -d) +# cleanup on exit, hangup, interrupt, quit, termination +trap 'rm -rf $tempcpio' 0 1 2 3 15 + +# extract the archive +gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 + +# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" +cp -f "$2" "$tempcpio"/DSDT.aml + +# add the file +cd "$tempcpio" +(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 +cd "$OLDPWD" + +# re-compress the archive +gzip -c "$tempcpio"/initramfs.cpio > "$1" +
drivers/acpi/Kconfig +17 -0
@@ -274,6 +274,23 @@ config ACPI_CUSTOM_DSDT_FILE Enter the full path name to the file which includes the AmlCode declaration. +config ACPI_CUSTOM_DSDT_INITRD + bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default n + help + The DSDT (Differentiated System Description Table) often needs to be + overridden because of broken BIOS implementations. If this feature is + activated you will be able to provide a customized DSDT by adding it + to your initramfs. If your mkinitrd tool does not support this feature + a script is provided in the documentation. For more details see + <file:Documentation/dsdt-initrd.txt> or <http://gaugusch.at/kernel.shtml>. + If there is no table found, it will fall-back to the custom DSDT + in-kernel (if activated) or to the DSDT from the BIOS. + + Even if you do not need a new one at the moment, you may want to use a + better DSDT later. It is safe to say Y here. + config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0
drivers/acpi/osl.c +69 -4
88 lines not on this page · raw message
init/initramfs.c +7 -1
@@ -541,7 +541,7 @@ skip:#endif -static int __init populate_rootfs (void ) +int __init populate_rootfs (void ) {char *err =unpack_to_rootfs (__initramfs_start, __initramfs_end - __initramfs_start,0 );
@@ -582,4 +582,10 @@ static int __init populate_rootfs(void)#endif return 0 ; } +#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD +/* +* if this option is enabled, populate_rootfs() is called _earlier_ in the +* boot sequence. This insures that the ACPI initialisation can find the file. +*/ rootfs_initcall (populate_rootfs); +#endif
init/main.c +7 -0
@@ -102,6 +102,12 @@ static inline void mark_rodata_ro(void) { }extern void tc_init (void );#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +extern int populate_rootfs (void ); +#else +static inline void populate_rootfs (void ) {} +#endif +enum system_states system_state;EXPORT_SYMBOL (system_state);
@@ -643,6 +649,7 @@ asmlinkage void __init start_kernel(void)check_bugs (); +populate_rootfs ();/* For DSDT override from initramfs */ acpi_early_init ();/* before LAPIC and SMP init */ /* Do the rest non-__init'ed, we're now alive */
Len Brown
reviewerRe: [PATCH 1/3] The basics of DSDT from initramfs (format corrected)
Quoted 9 lines · Éric Piel
The basics of DSDT from initramfs. In case this option is selected,
populate_rootfs()is called a bit earlier to have the initramfs content available during ACPI initialization.This is a very similar path to the one available at
http://gaugusch.at/kernel.shtml but with some update in the documentation, default set to No and the change ofpopulate_rootfs()the "Jeff Mahony way" (which avoids reading the initramfs twice).
Quoted 4 lines
Signed-off-by Eric Piel <[email protected]>--- Documentation/dsdt-initrd.txt | 100 +++++++++++++++++++++++++++++++++++++++++
I'd like to move any ACPI-specific documents under a sub-directory, eg. Documentation/acpi/dsdt-initrd.txt
Quoted 13 lines
drivers/acpi/Kconfig | 17 +++++++ drivers/acpi/osl.c | 73 ++++++++++++++++++++++++++++-- init/initramfs.c | 8 +++- init/main.c | 7 +++ 5 files changed, 200 insertions(+), 5 deletions(-) create mode 100644 Documentation/dsdt-initrd.txtDocumentation/dsdt-initrd.txt new file +0
-0
Documentation/dsdt-initrd.txt line 7
Quoted 7 lines
Documentation/dsdt-initrd.txt new file +7
-0@@ -0,0 +1,100 @@ +ACPI Custom DSDT read from initramfs + +2003 by Markus Gaugusch < dsdt at gaugusch dot at > +Special thanks go to Thomas Renninger from SuSE, who updated the patch for +2.6.0 and later modified it to read inside initramfs +2004 - 2008 maintained by Eric Piel < eric dot piel at tremplin-utc dot net > +
I'd like to re-write this to largely point to
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
which I can update.
I don't want to maintain two copies of this documentation.
Quoted 11 lines
Documentation/dsdt-initrd.txt new file +11
-0+This option is intended for people who would like to hack their DSDT and don't +want to recompile their kernel after every change. It can also be useful to +distros which offers pre-compiled kernels and want to allow their users to use +a modified DSDT. In the Kernel config, enable the initial RAM filesystem +support (in General Setup) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI +options (General Setup|ACPI Support|Read Custom DSDT from initramfs). + +A custom DSDT (Differentiated System Description Table) is useful when your +computer uses ACPI but problems occur due to broken implementation. Typically, +your computer works but there are some troubles with the hardware detection or +the power management. You can check that troubles come from errors in the DSDT by
Documentation/dsdt-initrd.txt
Quoted 10 lines
Documentation/dsdt-initrd.txt new file +10
-0+activating the ACPI debug option and reading the logs. This table is provided +by the BIOS, therefore it might be a good idea to check for BIOS update on your +vendor website before going any further. Errors are often caused by vendors +testing their hardware only with Windows or because there is code which is +executed only on a specific OS with a specific version and Linux hasn't been +considered during the development. + +Before you run away from customising your DSDT, you should note that already +corrected tables are available for a fair amount of computers on this web-page: +http://acpi.sf.net/dsdt .
I'd like to discourage use of http://acpi.sf.net/dsdt
except in the extreme cases of permanently broken BIOS that Linux otherwise has no hope of dealing with.
Documentation/dsdt-initrd.txt line 33
Quoted 6 lines
Be careful though, to work correctly a DSDT has to
Documentation/dsdt-initrd.txt new file +5
-0+match closely the hardware, including the amount of RAM, the frequency of the +processor and the PCI cards present! If you are part of the unluckies who +cannot find their hardware in this database, you can modify your DSDT by +yourself. This process is less painful than it sounds. Download the Intel ASL +compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm .
http://acpica.org/downloads/, but that is on the page above and shouldn't need to be referenced in this file.
Quoted 14 lines
Documentation/dsdt-initrd.txt new file +14
-0+As root, you then have to dump your DSDT and decompile it. By using the +compiler messages as well as the kernel ACPI debug messages and the reference +book (available at the Intel website and also at http://www.acpi.info), it is +quite easy to obtain a fully working table. + +Once your new DSDT is ready you'll have to add it to an initramfs so that the +kernel can read the table at the very beginning of the boot. As the file has to +be accessed very early during the boot process the initramfs has to be an +initramfs. The file is contained into the initramfs under the name /DSDT.aml . +To obtain such an initramfs, you might have to modify your initramfs script or +you can add it later to the initramfs with the script appended to this +document. The command will look like: +initramfs-add-dsdt initramfs.img my-dsdt.aml +
Documentation/dsdt-initrd.txt line 57
Quoted 10 lines
Documentation/dsdt-initrd.txt new file +9
-0+In case you don't use any initramfs, the possibilities you have are to either +start using one (try mkinitrd or yaird), or use the "Include Custom DSDT" +configure option to directly include your DSDT inside the kernel. + +The message "Looking for DSDT in initramfs..." will tell you if the DSDT was +found or not. If you need to update your DSDT, generate a new initramfs and +perform the steps above. Don't forget that with Lilo, you'll have to re-run it. + +====================== Here starts initramfs-add-dsdt ==========================
Since we'll have Documentation/acpi/, I think it would be better to have this as a script there rather than a script embedded in a text file.
Quoted 52 lines
Documentation/dsdt-initrd.txt new file +43
-0+#!/bin/bash +# Adds a DSDT file to the initrd (if it's an initramfs) +# first argument is the name of archive +# second argument is the name of the file to add +# The file will be copied as /DSDT.aml + +# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) +# 20060205: this time it should really work + +# check the arguments +if [ $# -ne 2 ]; then + program_name=$(basename $0) + echo "\ +$program_name: too few arguments +Usage: $program_name initrd-name.img DSDT-to-add.aml +Adds a DSDT file to an initrd (in initramfs format) + + initrd-name.img: filename of the initrd in initramfs format + DSDT-to-add.aml: filename of the DSDT file to add + " 1>&2 + exit 1 +fi + +# we should check it's an initramfs + +tempcpio=$(mktemp -d) +# cleanup on exit, hangup, interrupt, quit, termination +trap 'rm -rf $tempcpio' 0 1 2 3 15 + +# extract the archive +gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 + +# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" +cp -f "$2" "$tempcpio"/DSDT.aml + +# add the file +cd "$tempcpio" +(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 +cd "$OLDPWD" + +# re-compress the archive +gzip -c "$tempcpio"/initramfs.cpio > "$1" +drivers/acpi/Kconfig +1
-0@@ -274,6 +274,23 @@ config ACPI_CUSTOM_DSDT_FILE Enter the full path name to the file which includes the AmlCode declaration. +config ACPI_CUSTOM_DSDT_INITRD
drivers/acpi/Kconfig config ACPI_CUSTOM_DSDT_FILE · line 287
Quoted 10 lines
drivers/acpi/Kconfig +10
-0+ bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default n + help + The DSDT (Differentiated System Description Table) often needs to be + overridden because of broken BIOS implementations. If this feature is + activated you will be able to provide a customized DSDT by adding it + to your initramfs. If your mkinitrd tool does not support this feature + a script is provided in the documentation. For more details see + <file:Documentation/dsdt-initrd.txt> or <http://gaugusch.at/kernel.shtml>.
update this for in-tree location only
Quoted 29 lines
drivers/acpi/Kconfig +6
-0+ If there is no table found, it will fall-back to the custom DSDT + in-kernel (if activated) or to the DSDT from the BIOS. + + Even if you do not need a new one at the moment, you may want to use a + better DSDT later. It is safe to say Y here. + config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0drivers/acpi/osl.c +12
-0@@ -312,6 +312,66 @@ acpi_os_predefined_override(const struct acpi_predefined_names *init_val,return AE_OK ; } +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +struct acpi_table_header *acpi_find_dsdt_initrd (void ) +{ +struct file *firmware_file; +mm_segment_t oldfs; +unsigned long len, len2; +struct acpi_table_header *dsdt_buffer, *ret =NULL ; +struct kstat stat; +char *ramfs_dsdt_name ="/DSDT.aml" ; + + printk(KERN_INFO PREFIX "Looking for DSDT in initramfs... "); +
drivers/acpi/osl.c acpi_os_predefined_override(const struct acpi_predefined_names *init_val, · line 336
Quoted 10 lines
drivers/acpi/osl.c +10
-0+/* +* Never do this at home, only the user-space is allowed to open a file. +* The clean way would be to use the firmware loader. But this code must be run +* before there is any userspace available. So we need a static/init firmware +* infrastructure, which doesn't exist yet... +*/ +if (vfs_stat (ramfs_dsdt_name, &stat) <0 ) { +printk ("not found.\n" ); +return ret; + }
lets delete the "not found" -- even without the '!' I think it is not what we want to print on effectively 100% of systems in the field.
How about simply
ACPI: Checking initramfs for custom DSDT.
which doesn't imply anything bad when read in dmesg.
if something bad happens, it will result in one of the messages below
Note that none of the printk's below are checkpatchl.pl clean
Quoted 53 lines
drivers/acpi/osl.c +40
-3+ + len = stat.size; +/* check especially against empty files */ +if (len <=4 ) { +printk ("error, file is too small: only %lu bytes.\n" , len); +return ret; + } + + firmware_file =filp_open (ramfs_dsdt_name,O_RDONLY ,0 ); +if (IS_ERR (firmware_file)) { +printk ("error, could not open file %s.\n" , ramfs_dsdt_name); +return ret; + } + + dsdt_buffer =ACPI_ALLOCATE (len); +if (!dsdt_buffer) { +printk ("error when allocating %lu bytes of memory.\n" , len); + goto err; + } + + oldfs =get_fs (); +set_fs (KERNEL_DS ); + len2 =vfs_read (firmware_file, (char __user *)dsdt_buffer, len, &firmware_file->f_pos); +set_fs (oldfs); +if (len2 < len) { +printk ("error trying to read %lu bytes from %s.\n" , len, ramfs_dsdt_name); +ACPI_FREE (dsdt_buffer); + goto err; + } + +printk ("successfully read %lu bytes from %s.\n" , len, ramfs_dsdt_name); + ret = dsdt_buffer; +err: +filp_close (firmware_file,NULL ); + return ret; +} +#endif +acpi_status acpi_os_table_override (struct acpi_table_header * existing_table,struct acpi_table_header ** new_table)@@ -319,13 +379,18 @@ acpi_os_table_override(struct acpi_table_header * existing_table,if (!existing_table || !new_table)return AE_BAD_PARAMETER ; + *new_table =NULL ; +#ifdef CONFIG_ACPI_CUSTOM_DSDT if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) *new_table = (struct acpi_table_header *)AmlCode; -else - *new_table =NULL ; -#else
drivers/acpi/osl.c acpi_os_table_override(struct acpi_table_header * existing_table, · line 395
Quoted 10 lines
drivers/acpi/osl.c +7
-1- *new_table =NULL ; +#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) { +struct acpi_table_header *initrd_table =acpi_find_dsdt_initrd (); +if (initrd_table) + *new_table = initrd_table; + }#endif return AE_OK ;
I think up here in acpi_os_table_override() is where we should print _which_ override we are using -- to cover the case where there may be one from the kernel and also one from the initrd.
If we are using neither, we should print nothing.
Quoted 43 lines
drivers/acpi/osl.c +0
-0}init/initramfs.c +7
-1@@ -541,7 +541,7 @@ skip:#endif -static int __init populate_rootfs (void ) +int __init populate_rootfs (void ) {char *err =unpack_to_rootfs (__initramfs_start, __initramfs_end - __initramfs_start,0 );@@ -582,4 +582,10 @@ static int __init populate_rootfs(void)#endif return 0 ; } +#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD +/* +* if this option is enabled, populate_rootfs() is called _earlier_ in the +* boot sequence. This insures that the ACPI initialisation can find the file. +*/ rootfs_initcall (populate_rootfs); +#endif init/main.c +6
-0@@ -102,6 +102,12 @@ static inline void mark_rodata_ro(void) { }extern void tc_init (void );#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +extern int populate_rootfs (void ); +#else +static inline void populate_rootfs (void ) {} +#endif +enum system_states system_state;EXPORT_SYMBOL (system_state);
init/main.c asmlinkage void __init start_kernel(void) · line 652
Quoted 4 lines
init/main.c +1
-0@@ -643,6 +649,7 @@ asmlinkage void __init start_kernel(void)check_bugs (); +populate_rootfs ();/* For DSDT override from initramfs */
but this is also done as an initcall, yes?
init/main.c asmlinkage void __init start_kernel(void) · line 655
Quoted 4 lines
init/main.c +0
-0acpi_early_init ();/* before LAPIC and SMP init */ /* Do the rest non-__init'ed, we're now alive */
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] The basics of DSDT from initramfs
In reply to Éric PielHi Eric,
nice. Some minor comments below...
Quoted 49 lines · Éric Piel
The basics of DSDT from initramfs. In case this option is selected,
populate_rootfs()is called a bit earlier to have the initramfs content available during ACPI initialisation.This is a very similar path to the one available at
http://gaugusch.at/kernel.shtml but with some update in the documentation, default set to No and the change ofpopulate_rootfs()the "Jeff Mahony way" (which avoids reading the initramfs twice).Signed-off-by Eric Piel <[email protected]>--- Documentation/dsdt-initrd.txt | 100 +++++++++++++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 17 +++++++ drivers/acpi/osl.c | 73 ++++++++++++++++++++++++++++-- init/initramfs.c | 8 +++- init/main.c | 7 +++ 5 files changed, 200 insertions(+), 5 deletions(-)create mode 100644
Documentation/dsdt-initrd.txtDocumentation/dsdt-initrd.txt new file +23
-0@@ -0,0 +1,100 @@ +ACPI Custom DSDT read from initramfs + +2003 by Markuss Gaugusch < dsdt at gaugusch dot org > +Special thanks go to Thomas Renninger from SuSE, who updated the patch for +2.6.0 and later modified it to read inside initramfs +2004 - 2008 maintained by Eric Piel < eric dot piel at tremplin-utc dot net > + +This option is intended for people who would like to hack their DSDT and don't +want to recompile their kernel after every change. It can also be useful to +distros which offers pre-compiled kernels and want to allow their users to use +a modified DSDT. In the Kernel config, enable the initial RAM filesystem +support (in General Setup) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI +options (General Setup|ACPI Support|Read Custom DSDT from initramfs). + +A custom DSDT (Differentiated System Description Table) is useful when your +computer uses ACPI but problems occur due to broken implementation. Typically, +your computer works but there are some troubles with the hardware detection or +the power management. You can check that troubles come from errors in the DSDT by +activating the ACPI debug option and reading the logs. This table is provided +by the BIOS, therefore it might be a good idea to check for BIOS update on your +vendor website before going any further. Errors are often caused by vendors +testing their hardware only with Windows or because there is code which is +executed only on a specific OS with a specific version and Linux hasn't been
Documentation/dsdt-initrd.txt line 33
Quoted 10 lines
Documentation/dsdt-initrd.txt new file +10
-0+considered during the development. + +Before you run away from customising your DSDT, you should note that already +corrected tables are available for a fair amount of computers on this web-page: +http://acpi.sf.net/dsdt . Be careful though, to work correctly a DSDT has to +match closely the hardware, including the amount of RAM, the frequency of the +processor and the PCI cards present! If you are part of the unluckies who +cannot find their hardware in this database, you can modify your DSDT by +yourself. This process is less painful than it sounds. Download the Intel ASL +compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm .
AFAIK Intel wants to move away from this address. There should have been an opensource project for the ACPICA code started, we should reference this one instead. Len?
Documentation/dsdt-initrd.txt line 37
Quoted 4 lines
Documentation/dsdt-initrd.txt new file +4
-0+As root, you then have to dump your DSDT and decompile it. By using the +compiler messages as well as the kernel ACPI debug messages and the reference +book (available at the Intel website and also at http://www.acpi.info), it is +quite easy to obtain a fully working table.
Hmm, IMO this sentence should not go in, but instead a reference to:
Something like: You can learn how to extract your BIOS ACPI tables, disassemble, modify and recompile them here:
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
(which then still needs to be updated).
Documentation/dsdt-initrd.txt line 42
Quoted 4 lines
Documentation/dsdt-initrd.txt new file +4
-0+Once your new DSDT is ready you'll have to add it to an initramfs so that the +kernel can read the table at the very beginning of the boot. As the file has to +be accessed very early during the boot process the initramfs has to be an +initramfs. The file is contained into the initramfs under the name /DSDT.aml .
So this patch is still using /DSDT.aml...
Documentation/dsdt-initrd.txt
Quoted 10 lines
Documentation/dsdt-initrd.txt new file +10
-0+To obtain such an initramfs, you might have to modify your initramfs script or +you can add it later to the initramfs with the script appended to this +document. The command will look like: +initramfs-add-dsdt initramfs.img my-dsdt.aml + +In case you don't use any initramfs, the possibilities you have are to either +start using one (try mkinitrd or yaird), or use the "Include Custom DSDT" +configure option to directly include your DSDT inside the kernel. + +The message "Looking for DSDT in initramfs..."
Removing this was point 4. of Len's wish list.
IMO it can stay, but I don't really care.
Quoted 30 lines
will tell you if the DSDT was
Documentation/dsdt-initrd.txt new file +29
-0+found or not. If you need to update your DSDT, generate a new initramfs and +perform the steps above. Don't forget that with Lilo, you'll have to re-run it. + + +====================== Here starts initramfs-add-dsdt ========================== +#!/bin/bash +# Adds a DSDT file to the initrd (if it's an initramfs) +# first argument is the name of archive +# second argument is the name of the file to add +# The file will be copied as /DSDT.aml + +# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) +# 20060205: this time it should really work + +# check the arguments +if [ $# -ne 2 ]; then + program_name=$(basename $0) + echo "\ +$program_name: too few arguments +Usage: $program_name initrd-name.img DSDT-to-add.aml +Adds a DSDT file to an initrd (in initramfs format) + + initrd-name.img: filename of the initrd in initramfs format + DSDT-to-add.aml: filename of the DSDT file to add + " 1>&2 + exit 1 +fi + +# we should check it's an initramfs
Documentation/dsdt-initrd.txt line 91
Quoted 10 lines
Documentation/dsdt-initrd.txt new file +10
-0+ +tempcpio=$(mktemp -d) +# cleanup on exit, hangup, interrupt, quit, termination +trap 'rm -rf $tempcpio' 0 1 2 3 15 + +# extract the archive +gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 + +# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" +cp -f "$2" "$tempcpio"/DSDT.aml
DSDT.aml...
Quoted 23 lines
Documentation/dsdt-initrd.txt new file +9
-0+ +# add the file +cd "$tempcpio" +(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 +cd "$OLDPWD" + +# re-compress the archive +gzip -c "$tempcpio"/initramfs.cpio > "$1" +drivers/acpi/Kconfig +6
-0@@ -274,6 +274,23 @@ config ACPI_CUSTOM_DSDT_FILE Enter the full path name to the file which includes the AmlCode declaration. +config ACPI_CUSTOM_DSDT_INITRD + bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default n + help + The DSDT (Differentiated System Description Table) often needs to be
drivers/acpi/Kconfig config ACPI_CUSTOM_DSDT_FILE · line 292
Quoted 10 lines
drivers/acpi/Kconfig +10
-0+ overridden because of broken BIOS implementations. If this feature is + activated you will be able to provide a customized DSDT by adding it + to your initramfs. If your mkinitrd tool does not support this feature + a script is provided in the documentation. For more details see + <file:Documentation/dsdt-initrd.txt> or <http://gaugusch.at/kernel.shtml>. + If there is no table found, it will fall-back to the custom DSDT + in-kernel (if activated) or to the DSDT from the BIOS. + + Even if you do not need a new one at the moment, you may want to use a + better DSDT later. It is safe to say Y here.
This one should be rephrased. Don't invite all users to modify or use foreign DSDTs just for little improvements.
I think the main goal of this patch should be debugging/testing purposes.
Better phrase it like:
If you have problems with ACPI on your machine and you have fixed it up by modifying the DSDT, don't override the DSDT as a long term solution. E.g. if you add new memory to your machine, it will invalidate the modified DSDT (BIOS would generate a slightly adjusted one). Always report bugs in a DSDT to bugzilla.kernel.org and assign it to the ACPI component.
Overriding of the DSDT is mainly thought for developing/testing purposes!
Quoted 11 lines
drivers/acpi/Kconfig +1
-0+ config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0drivers/acpi/osl.c +0
-0@@ -312,6 +312,66 @@ acpi_os_predefined_override(const struct acpi_predefined_names *init_val,return AE_OK ; }
drivers/acpi/osl.c acpi_os_predefined_override(const struct acpi_predefined_names *init_val, · line 323
Quoted 10 lines
drivers/acpi/osl.c +9
-0+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +struct acpi_table_header *acpi_find_dsdt_initrd (void ) +{ +struct file *firmware_file; +mm_segment_t oldfs; +unsigned long len, len2; +struct acpi_table_header *dsdt_buffer, *ret =NULL ; +struct kstat stat; +char *ramfs_dsdt_name ="/DSDT.aml" ;
DSDT.aml
Quoted 119 lines
drivers/acpi/osl.c +60
-4+ + printk(KERN_INFO PREFIX "Looking for DSDT in initramfs... "); + +/* +* Never do this at home, only the user-space is allowed to open a file. +* The clean way would be to use the firmware loader. But this code must be run +* before there is any userspace available. So we need a static/init firmware +* infrastructure, which doesn't exist yet... +*/ +if (vfs_stat (ramfs_dsdt_name, &stat) <0 ) { +printk ("not found.\n" ); +return ret; + } + + len = stat.size; +/* check especially against empty files */ +if (len <=4 ) { +printk ("error, file is too small: only %lu bytes.\n" , len); +return ret; + } + + firmware_file =filp_open (ramfs_dsdt_name,O_RDONLY ,0 ); +if (IS_ERR (firmware_file)) { +printk ("error, could not open file %s.\n" , ramfs_dsdt_name); +return ret; + } + + dsdt_buffer =ACPI_ALLOCATE (len); +if (!dsdt_buffer) { +printk ("error when allocating %lu bytes of memory.\n" , len); + goto err; + } + + oldfs =get_fs (); +set_fs (KERNEL_DS ); + len2 =vfs_read (firmware_file, (char __user *)dsdt_buffer, len, &firmware_file->f_pos); +set_fs (oldfs); +if (len2 < len) { +printk ("error trying to read %lu bytes from %s.\n" , len, ramfs_dsdt_name); +ACPI_FREE (dsdt_buffer); + goto err; + } + +printk ("successfully read %lu bytes from %s.\n" , len, ramfs_dsdt_name); + ret = dsdt_buffer; +err: +filp_close (firmware_file,NULL ); + return ret; +} +#endif +acpi_status acpi_os_table_override (struct acpi_table_header * existing_table,struct acpi_table_header ** new_table)@@ -319,13 +379,18 @@ acpi_os_table_override(struct acpi_table_header * existing_table,if (!existing_table || !new_table)return AE_BAD_PARAMETER ; + *new_table =NULL ; +#ifdef CONFIG_ACPI_CUSTOM_DSDT if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) *new_table = (struct acpi_table_header *)AmlCode; -else - *new_table =NULL ; -#else - *new_table =NULL ; +#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) { +struct acpi_table_header *initrd_table =acpi_find_dsdt_initrd (); +if (initrd_table) + *new_table = initrd_table; + }#endif return AE_OK ; }init/initramfs.c +7
-1@@ -541,7 +541,7 @@ skip:#endif -static int __init populate_rootfs (void ) +int __init populate_rootfs (void ) {char *err =unpack_to_rootfs (__initramfs_start, __initramfs_end - __initramfs_start,0 );@@ -582,4 +582,10 @@ static int __init populate_rootfs(void)#endif return 0 ; } +#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD +/* +* if this option is enabled, populate_rootfs() is called _earlier_ in the +* boot sequence. This insures that the ACPI initialisation can find the file. +*/ rootfs_initcall (populate_rootfs); +#endif init/main.c +6
-0@@ -102,6 +102,12 @@ static inline void mark_rodata_ro(void) { }extern void tc_init (void );#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +extern int populate_rootfs (void ); +#else +static inline void populate_rootfs (void ) {} +#endif +enum system_states system_state;EXPORT_SYMBOL (system_state);
init/main.c asmlinkage void __init start_kernel(void) · line 655
Quoted 7 lines
init/main.c +1
-0@@ -643,6 +649,7 @@ asmlinkage void __init start_kernel(void)check_bugs (); +populate_rootfs ();/* For DSDT override from initramfs */ acpi_early_init ();/* before LAPIC and SMP init */ /* Do the rest non-__init'ed, we're now alive */
IMO it should go in as it is for now.
It could still be extended on the next rcX cycle. All comments are only minor enhancements.
About the /DSDT.aml vs. /dsdt/DSDT.aml location:
As said this is for SSDT overrides.
If someone sees (beside the table signature, I think I can handle/workaround this), why this has no use or not worth to look at it, pls let me know.
Otherwise I will have a look at it (but possibly not that soon...) I expect it need to be checked then whether /dsdt exists at all, is a directory and find all files in it.
The advantage to at least change the name now to dsdt/DSDT.aml, would be to have a consistent naming. If DSDT.aml changes to dsdt/DSDT.aml at some later time we need to adjust userspace tools and will get userspace vs kernel version problems.
I test-compiled the patches on various archs and configs, but didn't do any real DSDT override tests (the patches are in use for quite some time...). All builds succeeded.
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] The basics of DSDT from initramfs
Quoted 2 lines · On Tuesday 05 February 2008 14:43:48 Thomas Renninger wrote:
Quoted 2 lines
Download the Intel ASL
+compiler/decompiler at
http://www.intel.com/technology/IAPC/acpi/downloads.htm .
Quoted 3 lines
AFAIK Intel wants to move away from this address. There should have been an opensource project for the ACPICA code started, we should reference this one instead. Len?
http://www.acpica.org/downloads/
(Although at the moment, it's a bit of a trek through the new site to figure out that Linux needs the tools under 'UNIX source code' - a big fat link on the Linux page to the UNIX tools would be better, and all the compiling instructions from the Linux page can then just be moved to the 'UNIX source code' page, since they're clearly not Linux specific).
-Carlos
Signature · 3 lines
E-Mail: [email protected] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D
PATCH 2/3 Taint kernel on ACPI table override
In reply to Len BrownWhen an ACPI table is overridden (for now this can happen only for DSDT) display a big warning and taint the kernel with flag A.
--- drivers/acpi/osl.c | 7 +++++++ include/linux/kernel.h | 1 + kernel/panic.c | 5 +++-- 3 files changed, 11 insertions(+), 2 deletions(-)
drivers/acpi/osl.c +7 -0
@@ -392,6 +392,13 @@ acpi_os_table_override(struct acpi_table_header * existing_table, *new_table = initrd_table; }#endif +if (*new_table !=NULL ) { + printk(KERN_WARNING PREFIX "Override [%4.4s-%8.8s], " +"this is unsafe: tainting kernel\n" , + existing_table->signature, + existing_table->oem_table_id); +add_taint (TAINT_OVERRIDDEN_ACPI_TABLE ); + }return AE_OK ; }
include/linux/kernel.h +1 -0
@@ -240,6 +240,7 @@ extern enum system_states {#define TAINT_BAD_PAGE (1<<5)#define TAINT_USER (1<<6)#define TAINT_DIE (1<<7) +#define TAINT_OVERRIDDEN_ACPI_TABLE (1<<8)extern void dump_stack (void )__cold ;
kernel/panic.c +3 -2
@@ -160,7 +160,7 @@ const char *print_tainted(void) {static char buf[20 ];if (tainted) { - snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c", + snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c%c", tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G', tainted & TAINT_FORCED_MODULE ? 'F' : ' ', tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
@@ -168,7 +168,8 @@ const char *print_tainted(void) tainted &TAINT_MACHINE_CHECK ?'M' :' ' , tainted &TAINT_BAD_PAGE ?'B' :' ' , tainted &TAINT_USER ?'U' :' ' , - tainted & TAINT_DIE ? 'D' : ' '); + tainted &TAINT_DIE ?'D' :' ' , + tainted & TAINT_OVERRIDDEN_ACPI_TABLE ? 'A' : ' '); }else snprintf (buf,sizeof (buf),"Not tainted" );
Re: [PATCH 2/3] Taint kernel on ACPI table override (format corrected)
When an ACPI table is overridden (for now this can happen only for DSDT) display a big warning and taint the kernel with flag A.
--- drivers/acpi/osl.c | 7 +++++++ include/linux/kernel.h | 1 + kernel/panic.c | 5 +++-- 3 files changed, 11 insertions(+), 2 deletions(-)
drivers/acpi/osl.c +7 -0
@@ -392,6 +392,13 @@ acpi_os_table_override(struct acpi_table_header * existing_table, *new_table = initrd_table; }#endif +if (*new_table !=NULL ) { + printk(KERN_WARNING PREFIX "Override [%4.4s-%8.8s], " +"this is unsafe: tainting kernel\n" , + existing_table->signature, + existing_table->oem_table_id); +add_taint (TAINT_OVERRIDDEN_ACPI_TABLE ); + }return AE_OK ; }
include/linux/kernel.h +1 -0
@@ -240,6 +240,7 @@ extern enum system_states {#define TAINT_BAD_PAGE (1<<5)#define TAINT_USER (1<<6)#define TAINT_DIE (1<<7) +#define TAINT_OVERRIDDEN_ACPI_TABLE (1<<8)extern void dump_stack (void )__cold ;
kernel/panic.c +3 -2
@@ -160,7 +160,7 @@ const char *print_tainted(void) {static char buf[20 ];if (tainted) { - snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c", + snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c%c", tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G', tainted & TAINT_FORCED_MODULE ? 'F' : ' ', tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
@@ -168,7 +168,8 @@ const char *print_tainted(void) tainted &TAINT_MACHINE_CHECK ?'M' :' ' , tainted &TAINT_BAD_PAGE ?'B' :' ' , tainted &TAINT_USER ?'U' :' ' , - tainted & TAINT_DIE ? 'D' : ' '); + tainted &TAINT_DIE ?'D' :' ' , + tainted & TAINT_OVERRIDDEN_ACPI_TABLE ? 'A' : ' '); }else snprintf (buf,sizeof (buf),"Not tainted" );
PATCH 3/3 Add acpi_no_initrd_override kernel parameter
In reply to Len BrownThe acpi_no_initrd_override parameter permits to disable the load of an ACPI table from the initramfs.
--- Documentation/kernel-parameters.txt | 3 +++ drivers/acpi/osl.c | 14 +++++++++++++- 2 files changed, 16 insertions(+), 1 deletions(-)
Documentation/kernel-parameters.txt +3 -0
@@ -170,6 +170,9 @@ and is between 256 and 4096 characters. It is defined in the file acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT + acpi_no_initrd_override [KNL,ACPI] + Disable loading custom ACPI tables from the initramfs + acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows"
drivers/acpi/osl.c +13 -1
@@ -77,6 +77,10 @@ static struct workqueue_struct *kacpi_notify_wq;#define OSI_STRING_LENGTH_MAX 64/* arbitrary */ static char osi_additional_string[OSI_STRING_LENGTH_MAX ]; +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +static int acpi_no_initrd_override; +#endif +/* * "Ode to _OSI(Linux)" *
@@ -386,7 +390,8 @@ acpi_os_table_override(struct acpi_table_header * existing_table, *new_table = (struct acpi_table_header *)AmlCode;#endif #ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD -if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) { +if ((strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) && + !acpi_no_initrd_override) {struct acpi_table_header *initrd_table =acpi_find_dsdt_initrd ();if (initrd_table) *new_table = initrd_table;
@@ -402,6 +407,13 @@ acpi_os_table_override(struct acpi_table_header * existing_table,return AE_OK ; } +int __init acpi_no_initrd_override_setup (char *s) +{ + acpi_no_initrd_override =1 ; +return 1 ; +} +__setup ("acpi_no_initrd_override" , acpi_no_initrd_override_setup); +static irqreturn_t acpi_irq (int irq,void *dev_id) {return (*acpi_irq_handler) (acpi_irq_context) ?IRQ_HANDLED :IRQ_NONE ;
Re: [PATCH 3/3] Add acpi_no_initrd_override kernel parameter (format corrected)
The acpi_no_initrd_override parameter permits to disable the load of an ACPI table from the initramfs.
--- Documentation/kernel-parameters.txt | 3 +++ drivers/acpi/osl.c | 14 +++++++++++++- 2 files changed, 16 insertions(+), 1 deletions(-)
Documentation/kernel-parameters.txt +3 -0
@@ -170,6 +170,9 @@ and is between 256 and 4096 characters. It is defined in the file acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT + acpi_no_initrd_override [KNL,ACPI] + Disable loading custom ACPI tables from the initramfs + acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows"
drivers/acpi/osl.c +13 -1
@@ -77,6 +77,10 @@ static struct workqueue_struct *kacpi_notify_wq;#define OSI_STRING_LENGTH_MAX 64/* arbitrary */ static char osi_additional_string[OSI_STRING_LENGTH_MAX ]; +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +static int acpi_no_initrd_override; +#endif +/* * "Ode to _OSI(Linux)" *
@@ -386,7 +390,8 @@ acpi_os_table_override(struct acpi_table_header * existing_table, *new_table = (struct acpi_table_header *)AmlCode;#endif #ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD -if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) { +if ((strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) && + !acpi_no_initrd_override) {struct acpi_table_header *initrd_table =acpi_find_dsdt_initrd ();if (initrd_table) *new_table = initrd_table;
@@ -402,6 +407,13 @@ acpi_os_table_override(struct acpi_table_header * existing_table,return AE_OK ; } +int __init acpi_no_initrd_override_setup (char *s) +{ + acpi_no_initrd_override =1 ; +return 1 ; +} +__setup ("acpi_no_initrd_override" , acpi_no_initrd_override_setup); +static irqreturn_t acpi_irq (int irq,void *dev_id) {return (*acpi_irq_handler) (acpi_irq_context) ?IRQ_HANDLED :IRQ_NONE ;
Re: [PATCH] Override DSDT and SSDTs via initramfs
In reply to Éric PielQuoted 14 lines · Éric Piel
Hi,
Just a few comments for now as I don't have much time until this weekend. 30/01/08 18:27, Thomas Renninger wrote/a écrit:
:Quoted 1 line · Len Brown
:
Quoted 2 lines
Quoted 2 lines
Probably it is best to forward the original patch w/ proper credits, and then send updates to address 1-4.
Thomas, the patch you have included is only the "original" patch, right? We need to address the points 1-4 (which seem very reasonable) later on with additional patches. I think most of them are already implemented in
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.2-2.6.17-ssdt.patch
So that should be quite easy :-)
Quoted 5 lines
Quoted 3 lines
I do not know who initially came up with this, I just modified/adjusted the patch sometimes. I expect it's Markus, possibly Eric or best both who should be mentioned as author.
Yep, to be precise, Markus Gaugusch is the original author, I'm just the current maintainer, and Thomas has been very helpful for a looong time :-)
Long time is true..., very helpful, don't know, I didn't do that much...
Quoted 7 lines
Quoted 7 lines
Jeff (Mahony) has adjusted the last bits of it when he updated it to the latest rcX-gitY version:
Changes:
We no longer callpopulate_rootfs()twice. If we want the custom DSDT, we load the rootfs before ACPI. Otherwise, it is loaded at the
appropriate
initcall time. -jeffm
Quoted 5 lines
I had left it this way because I though Linus had a good reason for delaying
populate_rootfs(). But if it works, fine! Maybe some additional comments should be added in before the #ifdef's to clearly show thatpopulate_rootfs()is _always_ called, and they modify only the moment it is called.
I don't know about this, I took that change from your patches...
Quoted 16 lines
Quoted 6 lines
There is a new version at
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.4-2.6.21.patch,
but there doesn't seem to be any real changes other than elminating the
file
name array.Yes, exactly.
Quoted 3 lines
In fact, I added the array some time ago.
Not sure whether the latest Version of Eric/Markus can also load several DSDT/SSDTs? Maybe you found a more elegant way?Nope. On the website (http://gaugusch.at/kernel.shtml) you can just find two versions of the patch: one simple and one with your addition for SSDTs support. At least with SSDTs support there is even an advantage over the DSDT-in-kernel version :-)
Quoted 5 lines
Just one comment about the patch for now: it misses
Documentation/dsdt-initrd.txt. Please include this file too so that the documentation is provided at the same time (it's in the official patch).I'll test the patch and try to be productive this weekend.
There is no real need for testing the patch.
It is in OpenSUSE for quite some time. While I don't know how much it got used, it shouldn't break anything if unused.
As Jeff stated (I haven't had a look at your current version) it should be nearly the same.
About Len's points 1-4:
1. tainted bit needs to be set when a DSDT override is used. (this is common both to the new patch and the current override method)
2. upon setting the tainted bit, print a BIG FAT WARNING that this is not a supported configuration.
3. cmdline option needs to be available to disable an override. Otherwise a bad image in the intrd may be a serious pickle for some users.
4. get rid of alarming failure message:
+ printk(KERN_INFO "Looking for DSDT in initrd ...");
...
+ printk(" not found!\n");
Most of this should be included in the one I sent:
1+2 should be covered by this:
+ printk(PREFIX "Override [%4.4s-%8.8s]"
+ " from initramfs -" + " tainting kernel\n", + t->signature, + t->oem_table_id);
+ add_taint(TAINT_NO_SUPPORT);
I remember that I introduced a new TAINT flag, this got probably ripped out because I expect it needed conflict solving with new kernels all the time.
Now when it goes mainline a TAINT_DSDT_OVERRIDE flag might be appropriate, so that if you see a kernel panic or whatever bug, you immediately see why the kernel is tainted.
Problem from 4. should also not exist in this patch anymore.
The boot parameter (3.) is still missing.
Eric, would you mind bringing this all together (if Len agrees with my aspects).
I'd vote for moving the current location of the DSDT file to:
/dsdt/DSDT.aml
This would break current userspace apps (including SuSE's mkinitrd), but would prepare the patch for further SSDT enhancements.
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
Quoted 34 lines · Thomas Renninger
About Len's points 1-4:
1. tainted bit needs to be set when a DSDT override is used. (this is common both to the new patch and the current override method)
2. upon setting the tainted bit, print a BIG FAT WARNING that this is not a supported configuration.
3. cmdline option needs to be available to disable an override. Otherwise a bad image in the intrd may be a serious pickle for some users.
4. get rid of alarming failure message:
(quoted diff) +2
-0+ printk(KERN_INFO "Looking for DSDT in initrd ..."); + printk(" not found!\n");Most of this should be included in the one I sent:
1+2 should be covered by this:drivers/acpi/osl.c +6
-0+printk (PREFIX "Override [%4.4s-%8.8s]" +" from initramfs -" +" tainting kernel\n" , + t->signature, + t->oem_table_id); +add_taint (TAINT_NO_SUPPORT );I remember that I introduced a new TAINT flag, this got probably ripped out because I expect it needed conflict solving with new kernels all the time.
Now when it goes mainline aTAINT_DSDT_OVERRIDEflag might be appropriate, so that if you see a kernel panic or whatever bug, you immediately see why the kernel is tainted.
Quoted 3 lines
Problem from 4. should also not exist in this patch anymore.
The boot parameter (3.) is still missing.
Indeed, points 2 and 4 are already solved in your patch :-)
Quoted 6 lines
Eric, would you mind bringing this all together (if Len agrees with my aspects).
I'd vote for moving the current location of the DSDT file to:
/dsdt/DSDT.aml
This would break current userspace apps (including SuSE's mkinitrd), but would prepare the patch for further SSDT enhancements.
Ok, I'll try to have something ready by the beginning of next week. I'm waiting from Len for his comments on the best names of the files and the SSDTs inclusion...
See you,
Eric
Len Brown
reviewerRe: [PATCH] Override DSDT and SSDTs via initramfs
In reply to Thomas RenningerQuoted 9 lines
Quoted 8 lines
Quoted 8 lines
Jeff (Mahony) has adjusted the last bits of it when he updated it to the latest rcX-gitY version:
Changes:
We no longer callpopulate_rootfs()twice. If we want the custom DSDT, we load the rootfs before ACPI. Otherwise, it is loaded at the
appropriate
initcall time. -jeffm
Quoted 7 lines
Quoted 5 lines
I had left it this way because I though Linus had a good reason for delaying
populate_rootfs(). But if it works, fine! Maybe some additional comments should be added in before the #ifdef's to clearly show thatpopulate_rootfs()is _always_ called, and they modify only the moment it is called.I don't know about this, I took that change from your patches...
So is the populate_rootfs() change in the pach I have correct, or not?
thanks,
-Len
Re: [PATCH] Override DSDT and SSDTs via initramfs
Quoted 14 lines · Len Brown wrote/
Quoted 13 lines
Quoted 13 lines
Quoted 7 lines
Jeff (Mahony) has adjusted the last bits of it when he updated it to the latest rcX-gitY version:
Changes:
We no longer callpopulate_rootfs()twice. If we want the custom DSDT, we load the rootfs before ACPI. Otherwise, it is loaded at the
appropriate
initcall time. -jeffmI had left it this way because I though Linus had a good reason for delaying
populate_rootfs(). But if it works, fine! Maybe some additional comments should be added in before the #ifdef's to clearly show thatpopulate_rootfs()is _always_ called, and they modify only the moment it is called.
Quoted 3 lines
Quoted 1 line
I don't know about this, I took that change from your patches...
So is the
populate_rootfs()change in the pach I have correct, or not?
Yes, it's correct. This is the SuSE version, which is slightly different from the one I had written for the official patch, but which avoids calling twice populate_rootfs(). Both versions work fine anyway :-)
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
In reply to Len BrownHi,
First let me introduce myself, my name does not appear,
but I am the quoted one by Andrew Morton on his 1st post of this thread :
http://thread.gmane.org/gmane.linux.acpi.devel/27726
Quoted 3 lines
Quoted 3 lines
I am annoyed by this missing (or rejected) feature upstream : DSDT
http://gaugusch.at/kernel.shtml
So to use "custom DSDT loading" I have to patch my laptop buggy BIOS
...
Quoted 3 lines
Quoted 3 lines
Hopefully many distro already include this patch, but not all of them such as debian :
http://bugs.debian.org/251023
You may be aware of that yet, but It seems that the patch was rejected for 2.6.25
Quoting linus : "the relevant ACPI code should either run much later,"
So was next then ? how can we help to fix this recurrent issue ?
Anyway I'd like to thank you all for all time spent on this job, and I am happy with the patch as it is...
Regards
Signature · 3 lines
# mailto:rzr[a]users.sf.net -- gpg:0x467094BC # http://rzr.online.fr/contribs.htm -- Libre Software Addict # xmpp:rzr[a]jabber.fr -- sip:rzr[a]ekiga.net
Re: [PATCH] Override DSDT and SSDTs via initramfs
Quoted 1 line · Philippe Coval
Hi,
:
Quoted 7 lines
You may be aware of that yet, but It seems that the patch was rejected for 2.6.25
Quoting linus : "the relevant ACPI code should either run much later,"
Hi,
Yes, I'm aware of it. The problem was that the code was using fake userspace commands to access the filesystem (it's was not really wrong but it always warm the blood of people) _and_ it was reordering the initialisation code in a rather incompatible way with the some of the part of the kernel (which is indeed a good reason to reject a patch!).
Quoted 1 line
So was next then ? how can we help to fix this recurrent issue ?
Now that 2.6.26-rc is open, I can try to summarize all the discussions that have been about this patch during previous cycle. There are basically three solutions:
* Make the ACPI layer able to update the DSDT (or other table) at any
time. This was proposed by Linus, and sounds the most beautiful approach... until you realize that it will lead to lots of limitations on what update can be done on the DSDT and that it requires basically a full rewrite of the ACPI layer (and some other parts of the kernel).
* Leverage the kexec infrastructure: instead of inserting the DSDT in
the initramfs, you first boot calmly, read the DSDT from userspace as you feel like, reboot with kexec to the same kernel while passing this DSDT to the next kernel instance, which will then use it. It seems quite a reasonable approach. So far the only problem I have is that I don't know how to reliably pass the DSDT as argument to the second kernel (mainly due to lack of time to look for).
* Add 20 lines to the initramfs parser so that it can also just read
one file and copy it to memory without populating the rootfs. This permits an approach very similar to the previous one but without fake userspace commands and without reordering the initialisation. Attached is a patch doing this.
Actually, I'd be interested to know how likely this last approach would be acceptable for the kernel. Andrew, would you accept the patch in your tree, for testing?
Quoted 2 lines
Anyway I'd like to thank you all for all time spent on this job, and I am happy with the patch as it is...
One small thing to do to help is to test this patch and report success or failure :-)
See you,
Eric
From de31945e20bc0bd255d0264c5d97a6b24906b30a Mon Sep 17 00:00:00 2001
From: Eric Piel <piel@localhost.(none)>
Date: Wed, 19 Mar 2008 23:00:04 +0100
Subject: [PATCH 1/1] ACPI: initramfs DSDT override support
Permits to load of DSDT (the main ACPI table) from initramfs. In case this option is selected, the initramfs is parsed at ACPI initialization (very early boot time) to look for a file DSDT.aml . This aims at allowing users to override the DSDT without recompiling the kernel
This is derived from the patch from http://gaugusch.at/kernel.shtml but with some clean-up's in the documentation, default set to No, a kernel paramater to disable it at runtime, and most important, a different approach for reading the initramfs which avoids using the filesystem infrastructure.
--- Documentation/acpi/dsdt-override.txt | 12 ++++- Documentation/acpi/initramfs-add-dsdt.sh | 43 +++++++++++++++++ Documentation/kernel-parameters.txt | 3 + drivers/acpi/Kconfig | 11 ++++ drivers/acpi/osl.c | 24 ++++++++++ init/initramfs.c | 74 ++++++++++++++++++++++++++++++ 6 files changed, 165 insertions(+), 2 deletions(-) create mode 100644 Documentation/acpi/initramfs-add-dsdt.sh
Documentation/acpi/dsdt-override.txt +10 -2
@@ -1,7 +1,15 @@ -Linux supports a method of overriding the BIOS DSDT: +Linux supports two methods of overriding the BIOS DSDT: CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel. -When to use this method is described in detail on the +CONFIG_ACPI_CUSTOM_DSDT_INITRD adds the image to the initrd. + +When to use these methods is described in detail on the Linux/ACPI home page: http://www.lesswatts.org/projects/acpi/overridingDSDT.php + +Note that if both options are used, the DSDT supplied +by the INITRD method takes precedence. + +Documentation/initramfs-add-dsdt.sh is provided for convenience +for use with the CONFIG_ACPI_CUSTOM_DSDT_INITRD method.
Documentation/acpi/initramfs-add-dsdt.sh new file +43 -0
43 lines not on this page · raw message
Documentation/kernel-parameters.txt +3 -0
@@ -177,6 +177,9 @@ and is between 256 and 4096 characters. It is defined in the file acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT + acpi_no_initrd_override [KNL,ACPI] + Disable loading custom ACPI tables from the initramfs + acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows"
drivers/acpi/Kconfig +11 -0
@@ -300,6 +300,17 @@ config ACPI_CUSTOM_DSDT bool default ACPI_CUSTOM_DSDT_FILE != "" +config ACPI_CUSTOM_DSDT_INITRD + bool "Read Custom DSDT from initramfs" + depends on BLK_DEV_INITRD + default n + help + This option supports a custom DSDT by optionally loading it from initrd. + See Documentation/acpi/dsdt-override.txt + + If you are not using this feature now, but may use it later, + it is safe to say Y here. + config ACPI_BLACKLIST_YEAR int "Disable ACPI for systems before Jan 1st this year" if X86_32 default 0
drivers/acpi/osl.c +24 -0
@@ -91,6 +91,11 @@ static DEFINE_SPINLOCK(acpi_res_lock);#define OSI_STRING_LENGTH_MAX 64/* arbitrary */ static char osi_additional_string[OSI_STRING_LENGTH_MAX ]; +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +static int acpi_no_initrd_override; +extern struct acpi_table_header *acpi_find_dsdt_initrd (void ); +#endif +/* * "Ode to _OSI(Linux)" *
@@ -333,6 +338,16 @@ acpi_os_table_override(struct acpi_table_header * existing_table,if (strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) *new_table = (struct acpi_table_header *)AmlCode;#endif +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +if ((strncmp (existing_table->signature,"DSDT" ,4 ) ==0 ) && + !acpi_no_initrd_override) { +struct acpi_table_header *initrd_table; + + initrd_table =acpi_find_dsdt_initrd (); +if (initrd_table) + *new_table = initrd_table; + } +#endif if (*new_table !=NULL ) { printk(KERN_WARNING PREFIX "Override [%4.4s-%8.8s], " "this is unsafe: tainting kernel\n",
@@ -343,6 +358,15 @@ acpi_os_table_override(struct acpi_table_header * existing_table,return AE_OK ; } +#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD +static int __init acpi_no_initrd_override_setup (char *s) +{ + acpi_no_initrd_override =1 ; +return 1 ; +} +__setup ("acpi_no_initrd_override" , acpi_no_initrd_override_setup); +#endif +static irqreturn_t acpi_irq (int irq,void *dev_id) {u32 handled;
init/initramfs.c +74 -0
113 lines not on this page · raw message
Signature · 1 line
1.5.4.3
Len Brown
reviewerRe: [PATCH] Override DSDT and SSDTs via initramfs
In reply to Éric PielQuoted 9 lines
Quoted 3 lines
Quoted 3 lines
Probably it is best to forward the original patch w/ proper credits, and then send updates to address 1-4.
Thomas, the patch you have included is only the "original" patch, right? We need to address the points 1-4 (which seem very reasonable) later on with additional patches. I think most of them are already implemented in
http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.2-2.6.17-ssdt.patch
So that should be quite easy :-)
Quoted 5 lines
Quoted 3 lines
I do not know who initially came up with this, I just modified/adjusted the patch sometimes. I expect it's Markus, possibly Eric or best both who should be mentioned as author.
Yep, to be precise, Markus Gaugusch is the original author, I'm just the current maintainer, and Thomas has been very helpful for a looong time :-)
okay, i'll update the original author to be Markus Gaugusch <[email protected]>
(for future reference, if you start the patch comments with a From:
you can specific the original author as somebody else that way)
thanks,
-Len