Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 1月, 2013 1 次提交
  3. 17 7月, 2012 1 次提交
  5. 22 3月, 2012 1 次提交
  7. 17 1月, 2012 2 次提交
  9. 10 5月, 2011 1 次提交
  11. 25 3月, 2011 1 次提交
  13. 19 1月, 2011 1 次提交
  15. 15 1月, 2011 1 次提交
  17. 07 1月, 2011 1 次提交
    • R
      ACPI / ACPICA: Fix global lock acquisition · 9cd03144
      由 Rafael J. Wysocki 提交于 
      There are two problems with the ACPICA's current implementation of
the global lock acquisition.  First, acpi_ev_global_lock_handler(),
which in fact is an interface to the outside of the kernel, doesn't
validate its input, so it only works correctly if the other side
(i.e. the ACPI firmware) is fully specification-compliant (as far
as the global lock is concerned).  Unfortunately, that's known not
to be the case on some systems (i.e. we get spurious global lock
signaling interrupts without the pending flag set on some systems).
Second, acpi_ev_global_lock_handler() attempts to acquire the global
lock on behalf of a thread waiting for it without checking if there
actually is such a thread.  Both of these shortcomings need to be
addressed to prevent all possible race conditions from happening.

Rework acpi_ev_global_lock_handler() so that it doesn't try to
acquire the global lock and make it signal the availability of the
global lock to the waiting thread instead.  Make sure that the
availability of the global lock can only be signaled when there
is a thread waiting for it and that it can't be signaled more than
once in a row (to keep acpi_gbl_global_lock_semaphore in balance).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>
      9cd03144
  19. 01 10月, 2010 1 次提交
  21. 20 4月, 2010 1 次提交
  23. 23 2月, 2010 1 次提交
    • R
      ACPI / ACPICA: Multiple system notify handlers per device · 3f0be671
      由 Rafael J. Wysocki 提交于 
      Currently it only is possible to install one system notify handler
per namespace node, but this is not enough for PCI run-time power
management, because we need to install power management notifiers for
devices that already have hotplug notifiers installed.  While in
principle this could be handled at the PCI level, that would be
suboptimal due to the way in which the ACPI-based PCI hotplug code is
designed.

For this reason, modify ACPICA so that it is possible to install more
than one system notify handler per namespace node.  Namely, make
acpi_install_notify_handler(), acpi_remove_notify_handler() and
acpi_ev_notify_dispatch() use a list of system notify handler objects
associated with a namespace node.

Make acpi_remove_notify_handler() call acpi_os_wait_events_complete()
upfront to avoid a situation in which concurrent instance of
acpi_remove_notify_handler() removes the handler from under us while
we're waiting for the event queues to flush.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      3f0be671
  25. 23 1月, 2010 1 次提交
  27. 28 3月, 2009 2 次提交
  29. 27 3月, 2009 1 次提交
  31. 09 1月, 2009 2 次提交
  33. 31 12月, 2008 2 次提交
  35. 30 12月, 2008 2 次提交
  37. 17 7月, 2008 1 次提交
  39. 24 4月, 2008 1 次提交
  41. 23 4月, 2008 4 次提交
  43. 10 5月, 2007 3 次提交
  45. 15 3月, 2007 2 次提交
  47. 07 3月, 2007 1 次提交
  49. 16 2月, 2007 1 次提交
    • A
      Execute AML Notify() requests on stack. · 5f7748cf
      由 Alexey Starikovskiy 提交于 
      HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.

The notify handler in the ACPI thermal driver is a C-routine,
which may invoke the ACPI interpreter again to get access
to some ACPI variables such as temperature.  (acpi_evaluate_xxx)
On these HP machines such an evaluation changes state of an ASL 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 explosion in memory consumption.

Also as GPE handling is blocked, machines overheat because ACPI-based
fan control is stalled.  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 this failure,  Linux must not send notify events to the
kacpid workqueue -- either executing them immediately or putting them
on some other thread.

The 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-based kernel shipped with Ubuntu 6.06 LTS.

Second attempt was done by Alexey Starikovskiy, who 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 2.6.18-rc2.

Alexey 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 this broke Linus' machine
also and was reverted from 2.6.19-rc with much fanfair.

The 4th patch 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).  Then a 5th attempt did a
yield() to every GPE execution.

Finally, this 6th generation patch simply executes the notify handler
on the stack.  Previous attempts to do this simple solution failed
because of issues in AML mutex re-entrancy which are now fixed
by the previous patch in this series.

http://bugzilla.kernel.org/show_bug.cgi?id=5534Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      5f7748cf
  51. 03 2月, 2007 4 次提交