Some Toshiba laptops (and potentially others too) overwrite DSDT tables after boot, which is known to cause ACPI-related issues. Reproducible: Always Steps to Reproduce: 1. Get an affected laptop (e.g., Toshiba Satellite A505-S6005) 2. Build a kernel with ACPI support 3. Boot with ACPI turned on. Actual Results: ACPI DSDT tabbles are overriden and the machine fails to boot or boots but ACPI functionality doesn't work. Expected Results: The machine should function normally.
Created attachment 241349 [details, diff] Fix This patch adds an ACPI option (copy_dsdt) to copy the DSDT tables to a safe place in an early boot step, so that the system doesn't crash. Additionally, as compared with proposed bug at https://bugzilla.kernel.org/attachment.cgi?id=25669, it manages a blacklist with known affected computers so that the issue is addressed transparently. Enabling the option (i.e., booting with acpi=copy_dsdt) doesn't harm working computers, but uses approximately 64KiB of memory.
2.6.34, right?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=aa2110cb1a7510f9b834adfb39b05d4843a35d35
Yes, the patch I submitted is for 2.6.34, although it probably works for 2.6.33 and 2.6.32. The patch I sent does work. The one you are referring to doesn't, because it doesn't implement the copy_dsdt routines. The one in the kernel bugzilla, on the other hand, does work, but the blacklist isn't implemented. My patch is based upon both, and has been tested on my machine successfully.
Has your patch made it too mainline, yet? We only accept patches that are queued in upstream trees.
AFAIK, 2.6.35 incorporates the patch (1), and that other part (the blacklist) is in the patch you posted. Mine mixes the two versions, which makes me think that they reasonably supported in upstream. On the other hand, gentoo-sources and hardened-sources incorporate patches by the Gentoo team, isn't it? (1) https://bugzilla.kernel.org/attachment.cgi?id=25669, http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35, commit 04afb40593f9a3007e5ea817d009529ef10fb685
Hardened team is different than gentoo-sources team. Q. Will you apply [some kernel patch]? If it's a serious and non-intrusive bugfix that has been accepted into the upstream development kernel, then usually yes (please open a bug). Otherwise, generally the answer is no - instead of getting new features added to our kernel, we'd prefer you to contact the authors of that code and get them to finish off their work and submit it to the mainline kernel so that everyone can benefit. Does 2.6.35 work for you?
I haven't tried 2.6.35, because I use the hardened profile and there's no ebuild yet for =hardened-sources-2.6.35. However, it should work. As I previously said, the patch I submitted was made up from two patches made by the kernel developers, both of them sent to Linus to be included in 2.6.35. I know 2.6.35 incorporates the acpi=copy_dsdt boot option, but I'm not sure about the blacklist to automatically apply it on affected computers. I should check that.
From what I see in current 2.6.35 vanilla branch, it seems as though this patch had been applied, including the blacklist. Therefore, this patch should be considered safe to be added to gentoo-sources. References: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=69ec87efa815d69140423014bb5f91e034faac22 http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=aa2110cb1a7510f9b834adfb39b05d4843a35d35
we're going to need more than these two. I see missing functions that the patches apply changes too. Such as: acpi_tb_check_dsdt_header in tbutils.c
My idea wasn't exactly to apply the whole set of patches for the 2.6.35 branch into the 2.6.34 (which is why we do have 2.6.34 AND 2.6.35, isn't it?), but to fix an specific issue which owes to a buggy BIOS on some machines. This is because it would save lots of time for people with this hardware, especially because 2.6.34 is still the "stable" version of the kernel. Certainly, I'd rather build a set of patches with every kernel bugfix in existence so that users of older versions of the kernel don't have a need to upgrade unless they need some new feature, but I don't have time nor resources to do so. I contributed with this patch because it affected me and took me some time to figure out what was going on, find the patches, test them, etc. Having that said, I think the question here is: do we want users of the stable branch to have (some of) the latest bugfixes so that their systems work without difficulties, or do we want to push those users to not-so-stable versions to get the upstream fixes?
We dont apply user's patches, thanks. Identify patches from Linus tree that CLEANLY apply to older kernels and I will apply them
