Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 07 1月, 2012 2 次提交
  3. 23 12月, 2011 1 次提交
    • D
      sparc64: Fix MSIQ HV call ordering in pci_sun4v_msiq_build_irq(). · 7cc85833
      由 David S. Miller 提交于 
      This silently was working for many years and stopped working on
Niagara-T3 machines.

We need to set the MSIQ to VALID before we can set it's state to IDLE.

On Niagara-T3, setting the state to IDLE first was causing HV_EINVAL
errors.  The hypervisor documentation says, rather ambiguously, that
the MSIQ must be "initialized" before one can set the state.

I previously understood this to mean merely that a successful setconf()
operation has been performed on the MSIQ, which we have done at this
point.  But it seems to also mean that it has been set VALID too.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cc85833
  5. 05 12月, 2011 1 次提交
  7. 18 11月, 2011 1 次提交
  9. 16 11月, 2011 1 次提交
    • D
      sparc: Stash orig_i0 into %g6 instead of %g2 · e88d2468
      由 David S. Miller 提交于 
      As per the comments added by this commit, %g2 turns out to not be a
usable place to save away orig_i0 for syscall restart handling.

In fact all of %g2, %g3, %g4, and %g5 are assumed to be saved across
a system call by various bits of code in glibc.

%g1 can't be used because that holds the syscall number, which would
need to be saved and restored for syscall restart handling too, and
that would only compound our problems :-)

This leaves us with %g6 and %g7 which are for "system use".  %g7 is
used as the "thread register" by glibc, but %g6 is used as a compiler
and assembler temporary scratch register.  And in no instance is %g6
used to hold a value across a system call.

Therefore %g6 is safe for storing away orig_i0, at least for now.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e88d2468
  11. 15 11月, 2011 1 次提交
    • D
      sparc: Fix handling of orig_i0 wrt. debugging when restarting syscalls. · 1d299bc7
      由 David S. Miller 提交于 
      Although we provide a proper way for a debugger to control whether
syscall restart occurs, we run into problems because orig_i0 is not
saved and restored properly.

Luckily we can solve this problem without having to make debuggers
aware of the issue.  Across system calls, several registers are
considered volatile and can be safely clobbered.

Therefore we use the pt_regs save area of one of those registers, %g2,
as a place to save and restore orig_i0.

Debuggers transparently will do the right thing because they save and
restore this register already.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d299bc7
  13. 14 11月, 2011 1 次提交
  15. 01 11月, 2011 7 次提交
  17. 31 10月, 2011 1 次提交
  19. 26 10月, 2011 1 次提交
  21. 20 10月, 2011 1 次提交
  23. 13 10月, 2011 2 次提交
  25. 22 9月, 2011 1 次提交
    • D
      sparc: Make '-p' boot option meaningful again. · 11032c17
      由 David S. Miller 提交于 
      If "-p" is given on the command line, clear the CON_BOOT
flag for the initial early boot PROM console.

This is necessary to try and see crash messages that occur
between the registry of the VT console and the probing of
the first framebuffer or serial console.  During this time
no console messages are emitted because the VT console
registry (even if no backend is registered to it) removes
the early console if CON_BOOT is set.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11032c17
  27. 21 9月, 2011 1 次提交
  29. 17 9月, 2011 1 次提交
  31. 30 8月, 2011 3 次提交
  33. 27 8月, 2011 1 次提交
  35. 21 8月, 2011 1 次提交
    • D
      sparc: Allow handling signals when stack is corrupted. · 5598473a
      由 David S. Miller 提交于 
      If we can't push the pending register windows onto the user's stack,
we disallow signal delivery even if the signal would be delivered on a
valid seperate signal stack.

Add a register window save area in the signal frame, and store any
unsavable windows there.

On sigreturn, if any windows are still queued up in the signal frame,
try to push them back onto the stack and if that fails we kill the
process immediately.

This allows the debug/tst-longjmp_chk2 glibc test case to pass.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5598473a
  37. 19 8月, 2011 1 次提交
    • I
      sparc: fix array bounds error setting up PCIC NMI trap · 4a0342ca
      由 Ian Campbell 提交于 
        CC      arch/sparc/kernel/pcic.o
arch/sparc/kernel/pcic.c: In function 'pcic_probe':
arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds]
cc1: all warnings being treated as errors

I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via
the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear
to be 4 instructions long and I presume from the usage that instructions are
int sized.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a0342ca
  39. 12 8月, 2011 1 次提交
  41. 05 8月, 2011 2 次提交
  43. 03 8月, 2011 6 次提交
  45. 31 7月, 2011 2 次提交