Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 5月, 2007 5 次提交
    • A
      ACPI: created a dedicated workqueue for notify() execution · 88db5e14
      由 Alexey Starikovskiy 提交于 
      HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.

Notify handler in ACPI driver is a C-routine, which may call ACPI
interpreter again to get access to some ACPI variables
(acpi_evaluate_xxx).
On these HP machines such an evaluation changes state of some variable
and lets the loop above break.

In the current ACPI implementation Notify requests are being deferred
to the same kacpid workqueue on which the above GPE handler with
infinite loop is executing. Thus we have a deadlock -- loop will
continue to spin, sending notify events, and at the same time
preventing these notify events from being run on a workqueue. All
notify events are deferred, thus we see increase in memory consumption
noticed by author of the thread. Also as GPE handling is bloked,
machines overheat. Eventually by external poll of the same
acpi_evaluate, kacpid is released and all the queued notify events are
free to run, thus 100% cpu utilization by kacpid for several seconds
or more.

To prevent all these horrors it's needed to not put notify events to
kacpid workqueue by either executing them immediately or putting them
on some other thread. It's dangerous to execute notify events in
place, as it will put several ACPI interpreter stacks on top of each
other (at least 4 in case of nx6125), thus causing kernel  stack
overflow.

First attempt to create a new thread was done by Peter Wainwright
He created a bunch of threads, which were stealing work from a kacpid
workqueue.
This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.

Second attempt was done by me, I created a new thread for each Notify
event. This worked OK on HP nx machines, but broke Linus' Compaq
n620c, by producing threads with a speed what they stopped the machine
completely. Thus this patch was reverted from 18-rc2 as I remember.
I re-made the patch to create second workqueue just for notify events,
thus hopping it will not break Linus' machine. Patch was tested on the
same HP nx machines in #5534 and #7122, but I did not received reply
from Linus on a test patch sent to him.
Patch went to 19-rc and was rejected with much fanfare again.
There was 4th patch, which inserted schedule_timeout(1) into deferred
execution of kacpid, if we had any notify requests pending, but Linus
decided that it was too complex (involved either changes to workqueue
to see if it's empty or atomic inc/dec).
Now you see last variant which adds yield() to every GPE execution.

http://bugzilla.kernel.org/show_bug.cgi?id=5534
http://bugzilla.kernel.org/show_bug.cgi?id=8385Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      88db5e14
    • L
      Revert "ACPICA: fix AML mutex re-entrancy" · 262a7a28
      由 Len Brown 提交于 
      This reverts commit c0d127b5.

These changes to AML locking were made to allow
Notify handlers to be called on the stack
and not deadlock.  However, that scheme turns
out to be flawed and was reverted by the previous commit,
so this commit restores the locking to it previous design.
Signed-off-by: NLen Brown <len.brown@intel.com>
      262a7a28
    • L
      Revert "Execute AML Notify() requests on stack." · 40d07080
      由 Len Brown 提交于 
      This reverts commit 5f7748cf.

While that change fixed the HP
http://bugzilla.kernel.org/show_bug.cgi?id=5534

it broke the ACER:
http://bugzilla.kernel.org/show_bug.cgi?id=8385
which as AML that caused Linux go recursive
and stack fault.

So this commit by itself will restore the ACER
and again break the HP, which we'll fix another way.
Signed-off-by: NLen Brown <len.brown@intel.com>
      40d07080
    • L
      Revert "ACPICA: revert "acpi_serialize" changes" · 4d2acd9e
      由 Len Brown 提交于 
      This reverts commit a8f4af6d.
Thus restoring ACPICA's new acpi_serialize code.

This commit by itself may cause a regression, but
it is reverted in this order so that subsequent
reverts reverts under this one can be made
without conflict.
Signed-off-by: NLen Brown <len.brown@intel.com>
      4d2acd9e
    • R
      PM: Separate hibernation code from suspend code · a3d25c27
      由 Rafael J. Wysocki 提交于 
      [ With Johannes Berg <johannes@sipsolutions.net> ]

Separate the hibernation (aka suspend to disk code) from the other suspend
code.  In particular:

 * Remove the definitions related to hibernation from include/linux/pm.h
 * Introduce struct hibernation_ops and a new hibernate() function to hibernate
   the system, defined in include/linux/suspend.h
 * Separate suspend code in kernel/power/main.c from hibernation-related code
   in kernel/power/disk.c and kernel/power/user.c (with the help of
   hibernation_ops)
 * Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_ops
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a3d25c27
  3. 09 5月, 2007 6 次提交
  5. 08 5月, 2007 1 次提交
  7. 03 5月, 2007 1 次提交
    • J
      [PATCH] x86: Log reason why TSC was marked unstable · 5a90cf20
      由 john stultz 提交于 
      Change mark_tsc_unstable() so it takes a string argument, which holds the
reason the TSC was marked unstable.

This is then displayed the first time mark_tsc_unstable is called.

This should help us better debug why the TSC was marked unstable on certain
systems and allow us to make sure we're not being overly paranoid when
throwing out this troublesome clocksource.

Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
      5a90cf20
  9. 01 5月, 2007 1 次提交
  11. 29 4月, 2007 1 次提交
  13. 27 4月, 2007 1 次提交
  15. 26 4月, 2007 5 次提交
  17. 24 4月, 2007 1 次提交
  19. 31 3月, 2007 1 次提交
  21. 29 3月, 2007 1 次提交
  23. 26 3月, 2007 6 次提交
  25. 24 3月, 2007 1 次提交
  27. 23 3月, 2007 1 次提交
  29. 22 3月, 2007 6 次提交
  31. 17 3月, 2007 1 次提交
    • T
      ACPI: Only use IPI on known broken machines (AMD, Dothan/BaniasPentium M) · 25496cae
      由 Thomas Renninger 提交于 
      Use IPI for blacklisted CPUs, add parameter IPI vs LAPIC

Currently, Linux disables lapic timer for all machines with C2 and higher
C-state support.

According to Intel only specific Intel models (Banias/Dothan) are broken
in respect of not waking up from C2 with lapic.

However, I am not sure about the naming of the parameter and how it
could/should get integrated into the dyntick part
(CONFIG_GENERIC_CLOCKEVENTS). There, a more fine grained check (TSC
still running?, ..) is needed? Does this make sense (always use
CLOCK_EVT_NOTIFY_BROADCAST_ON, but use OFF if forced by use_ipi=0:
clockevents_notify(use_ipi ? CLOCK_EVT_NOTIFY_BROADCAST_ON :
CLOCK_EVT_NOTIFY_BROADCAST_OFF, &pr->id);
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>
      25496cae
  33. 16 3月, 2007 1 次提交