1. 29 10月, 2016 1 次提交
  2. 30 5月, 2016 1 次提交
  3. 06 7月, 2015 1 次提交
  4. 24 6月, 2015 1 次提交
  5. 22 6月, 2015 1 次提交
    • V
      ARCv2: Support for ARCv2 ISA and HS38x cores · 1f6ccfff
      Vineet Gupta 提交于
      The notable features are:
          - SMP configurations of upto 4 cores with coherency
          - Optional L2 Cache and IO-Coherency
          - Revised Interrupt Architecture (multiple priorites, reg banks,
              auto stack switch, auto regfile save/restore)
          - MMUv4 (PIPT dcache, Huge Pages)
          - Instructions for
      	* 64bit load/store: LDD, STD
      	* Hardware assisted divide/remainder: DIV, REM
      	* Function prologue/epilogue: ENTER_S, LEAVE_S
      	* IRQ enable/disable: CLRI, SETI
      	* pop count: FFS, FLS
      	* SETcc, BMSKN, XBFU...
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      1f6ccfff
  6. 17 4月, 2015 1 次提交
  7. 05 6月, 2014 1 次提交
  8. 29 6月, 2013 1 次提交
  9. 26 6月, 2013 2 次提交
    • V
      ARC: Remove explicit passing around of ECR · 38a9ff6d
      Vineet Gupta 提交于
      With ECR now part of pt_regs
      
      * No need to propagate from lowest asm handlers as arg
      * No need to save it in tsk->thread.cause_code
      * Avoid bit chopping to access the bit-fields
      
      More code consolidation, cleanup
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      38a9ff6d
    • V
      ARC: pt_regs update #5: Use real ECR for pt_regs->event vs. synth values · 502a0c77
      Vineet Gupta 提交于
      pt_regs->event was set with artificial values to identify the low level
      system event (syscall trap / breakpoint trap / exceptions / interrupts)
      
      With r8 saving out of the way, the full word can be used to save real
      ECR (Exception Cause Register) which helps idenify the event naturally,
      including additional info such as cause code, param.
      Only for Interrupts, where ECR is not applicable, do we resort to
      synthetic non ECR values.
      
      SAVE_ALL_TRAP/EXCEPTIONS can now be merged as they both use ECR with
      different runtime values.
      
      The ptrace helpers now use the sub-fields of ECR to distinguish the
      events (e.g. vector 0x25 is trap, param 0 is syscall...)
      
      The following benefits will follow:
      
      (1) This centralizes the location of where ECR is saved and will allow
          the cleanup of task->thread.cause_code ECR placeholder which is set
          in non-uniform way. Then ARC VM code can safely rely on it being
          there for purpose of finer grained VM_EXEC dcache flush (based on
          exec fault: I-TLB Miss)
      
      (2) Further, ECR being passed around from low level handlers as arg can
          be eliminated as it is part of standard reg-file in pt_regs
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      502a0c77
  10. 22 6月, 2013 1 次提交
  11. 07 5月, 2013 1 次提交
    • V
      ARC: Debug/crash-printing Improvements · bd3c8b11
      Vineet Gupta 提交于
      * Remove the line-break between scratch/callee-regs (sneaked in when we
        converted from printk to pr_*
      
      * Use %pS to print the symbol names of faulting PC (ret pseudo register)
        and BLINK (call return register)
      
      * Don't print user-vma for a kernel crash (only do it for
        print-fatal-signals based regfile dump)
      
      * Verbose print the Interrupt/Exception Enable/Active state
      
      * for main executable link address is 0x10000 based (vs. 0) thus offset
        of faulting PC needs to be adjusted
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      bd3c8b11
  12. 01 5月, 2013 2 次提交
    • V
      arc, print-fatal-signals: reduce duplicated information · 681a90ff
      Vineet Gupta 提交于
      After the recent generic debug info on dump_stack() and friends, arc
      is printing duplicate information on debug dumps.
      
       [ARCLinux]$ ./crash
       crash/50: potentially unexpected fatal signal 11.	<-- [1]
       /sbin/crash, TGID 50					<-- [2]
       Pid: 50, comm: crash Not tainted 3.9.0-rc4+ #132 	<-- [3]
       ...
      
      Remove them.
      
      [tj@kernel.org: updated patch desc]
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      681a90ff
    • T
      dump_stack: unify debug information printed by show_regs() · a43cb95d
      Tejun Heo 提交于
      show_regs() is inherently arch-dependent but it does make sense to print
      generic debug information and some archs already do albeit in slightly
      different forms.  This patch introduces a generic function to print debug
      information from show_regs() so that different archs print out the same
      information and it's much easier to modify what's printed.
      
      show_regs_print_info() prints out the same debug info as dump_stack()
      does plus task and thread_info pointers.
      
      * Archs which didn't print debug info now do.
      
        alpha, arc, blackfin, c6x, cris, frv, h8300, hexagon, ia64, m32r,
        metag, microblaze, mn10300, openrisc, parisc, score, sh64, sparc,
        um, xtensa
      
      * Already prints debug info.  Replaced with show_regs_print_info().
        The printed information is superset of what used to be there.
      
        arm, arm64, avr32, mips, powerpc, sh32, tile, unicore32, x86
      
      * s390 is special in that it used to print arch-specific information
        along with generic debug info.  Heiko and Martin think that the
        arch-specific extra isn't worth keeping s390 specfic implementation.
        Converted to use the generic version.
      
      Note that now all archs print the debug info before actual register
      dumps.
      
      An example BUG() dump follows.
      
       kernel BUG at /work/os/work/kernel/workqueue.c:4841!
       invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #7
       Hardware name: empty empty/S3992, BIOS 080011  10/26/2007
       task: ffff88007c85e040 ti: ffff88007c860000 task.ti: ffff88007c860000
       RIP: 0010:[<ffffffff8234a07e>]  [<ffffffff8234a07e>] init_workqueues+0x4/0x6
       RSP: 0000:ffff88007c861ec8  EFLAGS: 00010246
       RAX: ffff88007c861fd8 RBX: ffffffff824466a8 RCX: 0000000000000001
       RDX: 0000000000000046 RSI: 0000000000000001 RDI: ffffffff8234a07a
       RBP: ffff88007c861ec8 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff8234a07a
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
       FS:  0000000000000000(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: ffff88015f7ff000 CR3: 00000000021f1000 CR4: 00000000000007f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Stack:
        ffff88007c861ef8 ffffffff81000312 ffffffff824466a8 ffff88007c85e650
        0000000000000003 0000000000000000 ffff88007c861f38 ffffffff82335e5d
        ffff88007c862080 ffffffff8223d8c0 ffff88007c862080 ffffffff81c47760
       Call Trace:
        [<ffffffff81000312>] do_one_initcall+0x122/0x170
        [<ffffffff82335e5d>] kernel_init_freeable+0x9b/0x1c8
        [<ffffffff81c47760>] ? rest_init+0x140/0x140
        [<ffffffff81c4776e>] kernel_init+0xe/0xf0
        [<ffffffff81c6be9c>] ret_from_fork+0x7c/0xb0
        [<ffffffff81c47760>] ? rest_init+0x140/0x140
        ...
      
      v2: Typo fix in x86-32.
      
      v3: CPU number dropped from show_regs_print_info() as
          dump_stack_print_info() has been updated to print it.  s390
          specific implementation dropped as requested by s390 maintainers.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Chris Metcalf <cmetcalf@tilera.com>		[tile bits]
      Acked-by: Richard Kuo <rkuo@codeaurora.org>		[hexagon bits]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a43cb95d
  13. 16 2月, 2013 3 次提交
  14. 11 2月, 2013 1 次提交
  15. 28 1月, 2013 1 次提交
  16. 10 10月, 2012 1 次提交
  17. 18 12月, 2010 1 次提交
  18. 22 11月, 2010 1 次提交
  19. 02 10月, 2010 1 次提交
    • N
      ARM: do not define VMALLOC_END relative to PAGE_OFFSET · 7c63984b
      Nicolas Pitre 提交于
      VMALLOC_END is supposed to be an absolute value, while PAGE_OFFSET may
      vary depending on the selected user:kernel memory split mode through
      CONFIG_VMSPLIT_*.  In fact, the goal of moving PAGE_OFFSET down is to
      accommodate more directly addressed RAM by the kernel below the vmalloc
      area, and having VMALLOC_END move along PAGE_OFFSET is rather against
      the very reason why PAGE_OFFSET can be moved in the first place.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      7c63984b
  20. 07 8月, 2008 1 次提交
  21. 03 5月, 2005 1 次提交
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4