Skip to content

L
linux
Switch branch/tag
  1. 01 Apr, 2008 2 commits
    • Rafael J. Wysocki's avatar
      ACPI PM: Restore the 2.6.24 suspend ordering · 7731ce63
      Rafael J. Wysocki authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Tested-by: default avatarFelix Möller <felix@derklecks.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7731ce63
    • Mikulas Patocka's avatar
      plip: replace spin_lock_irq with spin_lock_irqsave in irq context · cabce28e
      Mikulas Patocka authored 
      Plip uses spin_lock_irq/spin_unlock_irq in its IRQ handler (called from
parport IRQ handler), the latter enables interrupts without parport
subsystem IRQ handler expecting it.

The bug can be seen if you compile kernel with lock dependency checking
and use plip --- it produces a warning.

This patch changes it to spin_lock_irqsave/spin_lock_irqrestore, so that
it doesn't enable interrupts when already disabled.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cabce28e
  3. 30 Mar, 2008 30 commits
  5. 29 Mar, 2008 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7