summaryrefslogtreecommitdiff
path: root/Documentation/kernel-parameters.txt
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2008-03-30 02:19:07 +0100
committerLinus Torvalds <torvalds@linux-foundation.org>2008-04-01 11:21:08 -0700
commit7731ce63d9a863c987dd87b0425451fff0e6cdc8 (patch)
tree7bf9798c40cf43283deeff67747bd15e226e495b /Documentation/kernel-parameters.txt
parentcabce28ec0a0ae3d0ddfa4461f0e8be94ade9e46 (diff)
downloadlinux-3.10-7731ce63d9a863c987dd87b0425451fff0e6cdc8.tar.gz
linux-3.10-7731ce63d9a863c987dd87b0425451fff0e6cdc8.tar.bz2
linux-3.10-7731ce63d9a863c987dd87b0425451fff0e6cdc8.zip
ACPI PM: Restore the 2.6.24 suspend ordering
Some time ago it turned out that our suspend code ordering broke some NVidia-based systems that hung if _PTS was executed with one of the PCI devices, specifically a USB controller, in a low power state. Then, it was noticed that the suspend code ordering was not compliant with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and it was argued that the code had to be changed for that reason (ref. http://bugzilla.kernel.org/show_bug.cgi?id=9528). So we did, but evidently we did wrong, because it's now turning out that some systems have been broken by this change. Refs: http://bugzilla.kernel.org/show_bug.cgi?id=10340 https://bugzilla.novell.com/show_bug.cgi?id=374217#c16 [ I said at that time that something like this might happend, but the majority of people involved thought that it was improbable due to the necessity to preserve the compliance of hardware with ACPI 1.0. ] This actually is a quite serious regression from 2.6.24. Moreover, the ACPI 1.0 ordering of suspend code introduced another issue that I have only noticed recently. Namely, if the suspend of one of devices fails, the already suspended devices will be resumed without executing _WAK before, which leads to problems on some systems (for example, in such situations thermal management is broken on my HP nx6325). Consequently, it also breaks suspend debugging on the affected systems. Note also, that the requirement to execute _PTS before suspending devices does not really make sense, because the device in question may be put into a low power state at run time for a reason unrelated to a system-wide suspend. For the reasons outlined above, the change of the suspend ordering should be reverted, which is done by the patch below. [ Felix Möller: "I am the reporter from the original Novell Bug: https://bugzilla.novell.com/show_bug.cgi?id=374217 I just tried current git head (two hours ago) with the patch (the one from the beginning of this thread) from Rafael and without it. With the patch my MacBook does suspend without it does not." ] Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Felix Möller <felix@derklecks.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/kernel-parameters.txt')
-rw-r--r--Documentation/kernel-parameters.txt5
1 files changed, 0 insertions, 5 deletions
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 508e2a2c986..4cd1a5da80a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -170,11 +170,6 @@ and is between 256 and 4096 characters. It is defined in the file
acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA
Format: <irq>,<irq>...
- acpi_new_pts_ordering [HW,ACPI]
- Enforce the ACPI 2.0 ordering of the _PTS control
- method wrt putting devices into low power states
- default: pre ACPI 2.0 ordering of _PTS
-
acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT
acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS