Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 5月, 2012 2 次提交
  3. 29 3月, 2012 1 次提交
  5. 21 2月, 2012 1 次提交
  7. 13 1月, 2012 2 次提交
  9. 08 12月, 2011 3 次提交
  11. 11 11月, 2011 1 次提交
    • M
      MIPS: ASID conflict after CPU hotplug · 5c200197
      由 Maksim Rayskiy 提交于 
      I am running SMP Linux 2.6.37-rc1 on BMIPS5000 (single core dual thread)
and observe some abnormalities when doing system suspend/resume which I
narrowed down to cpu hotplugging. The suspend brings the second thread
processor down and then restarts it, after which I see memory corruption
in userspace. I started digging and found out that problem occurs because
while doing execve() the child process is getting the same ASID as the
parent, which obviously corrupts parent's address space.

Further digging showed that activate_mm() calls get_new_mmu_context() to
get a new ASID, but at this time ASID field in entryHi is 1, and
asid_cache(cpu) is 0x100 (it was just reset to ASID_FIRST_VERSION when
the secondary TP was booting).

So, get_new_mmu_context() increments the asid_cache(cpu) value to
0x101, and thus puts 0x01 into entryHi. The result - ASID field does
not get changed as it was supposed to.

My solution is very simple - do not reset asid_cache(cpu) on TP warm
restart.

Patchwork: https://patchwork.linux-mips.org/patch/1797/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5c200197
  13. 01 11月, 2011 1 次提交
  15. 02 10月, 2011 1 次提交
  17. 21 9月, 2011 1 次提交
  19. 01 7月, 2011 1 次提交
    • P
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      由 Peter Zijlstra 提交于 
      The nmi parameter indicated if we could do wakeups from the current
context, if not, we would set some state and self-IPI and let the
resulting interrupt do the wakeup.

For the various event classes:

  - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
  - tracepoint: nmi=0; since tracepoint could be from NMI context.
  - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

As one can see, there is very little nmi=1 usage, and the down-side of
not using it is that on some platforms some software events can have a
jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

The up-side however is that we can remove the nmi parameter and save a
bunch of conditionals in fast paths.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Michael Cree <mcree@orcon.net.nz>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Eric B Munson <emunson@mgebm.net>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Don Zickus <dzickus@redhat.com>
Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      a8b0ca17
  21. 18 5月, 2011 1 次提交
  23. 19 1月, 2011 1 次提交
  25. 17 12月, 2010 1 次提交
  27. 30 10月, 2010 2 次提交
  29. 07 10月, 2010 1 次提交
  31. 05 8月, 2010 4 次提交
  33. 06 7月, 2010 1 次提交
  35. 22 5月, 2010 1 次提交
  37. 21 5月, 2010 1 次提交
    • J
      mips,kgdb: kdb low level trap catch and stack trace · 5dd11d5d
      由 Jason Wessel 提交于 
      The only way the debugger can handle a trap in inside rcu_lock,
notify_die, or atomic_notifier_call_chain without a recursive fault is
to have a low level "first opportunity handler" do_trap_or_bp() handler.

Generally this will be something the vast majority of folks will not
need, but for those who need it, it is added as a kernel .config
option called KGDB_LOW_LEVEL_TRAP.

Also added was a die notification for oops such that kdb can catch an
oops for analysis.

There appeared to be no obvious way to pass the struct pt_regs from
the original exception back to the stack back tracer, so a special
case was added to show_stack() for when kdb is active because you
generally desire to generally look at the back trace of the original
exception.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Acked-by: NRalf Baechle <ralf@linux-mips.org>
      5dd11d5d
  39. 01 5月, 2010 2 次提交
  41. 13 4月, 2010 1 次提交
  43. 27 2月, 2010 2 次提交
  45. 11 2月, 2010 1 次提交
  47. 28 1月, 2010 1 次提交
    • D
      MIPS: PowerTV: Fix support for timer interrupts with > 64 external IRQs · 010c108d
      由 David VomLehn 提交于 
      The MIPS processor is limited to 64 external interrupt sources. Using a
greater number without IRQ sharing requires reading platform-specific
registers. On such platforms, reading the IntCtl register to determine
which interrupt corresponds to a timer interrupt will not work.

On MIPSR2 systems there is a solution - the TI bit in the Cause register,
specifically indicates that a timer interrupt has occured. This patch uses
that bit to detect interrupts for MIPSR2 processors, which may be expected
to work regardless of how the timer interrupt may be routed in the hardware.

Signed-off-by: David VomLehn (dvomlehn@cisco.com)
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/804/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      010c108d
  49. 17 12月, 2009 2 次提交
  51. 18 9月, 2009 1 次提交
  53. 17 6月, 2009 2 次提交
  55. 30 3月, 2009 1 次提交