1. 01 12月, 2013 1 次提交
    • H
      parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address · 0576da2c
      Helge Deller 提交于
      locale-gen on Debian showed a strange problem on parisc:
      mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
      mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
      
      Basically it was just trying to re-mmap() a file at the same address
      which it was given by a previous mmap() call. But this remapping failed
      with EINVAL.
      
      The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
      included the mapping-based offset when we verified the alignment of the given
      fixed address against the offset which we calculated it in the previous call.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # 3.10+
      0576da2c
  2. 13 11月, 2013 1 次提交
  3. 09 11月, 2013 1 次提交
  4. 08 11月, 2013 4 次提交
  5. 27 10月, 2013 1 次提交
    • H
      parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM · 54e181e0
      Helge Deller 提交于
      Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
      not able to bring up other CPUs than the monarch CPU and instead crashed the
      kernel.  The reason was unclear, esp. since it involved various machines (e.g.
      J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
      when less than 4GB were installed, or if a 32bit Linux kernel was booted.
      
      In the end, the fix for those SMP problems is trivial:
      During the early phase of the initialization of the CPUs, including the monarch
      CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
      It's documented that this firmware function may clobber various registers, and
      one one of those possibly clobbered registers is %cr30 which holds the task
      thread info pointer.
      
      Now, if %cr30 would always have been clobbered, then this bug would have been
      detected much earlier. But lots of testing finally showed, that - at least for
      %cr30 - on some machines only the upper 32bits of the 64bit register suddenly
      turned zero after the firmware call.
      
      So, after finding the root cause, the explanation for the various crashes
      became clear:
      - On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
        problem.
      - Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
        thread info pointer was below 4GB.
      - Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
        the upper 32bit were zero anyay.
      - Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
        info pointer was located above the 4GB boundary.
      
      Finally, the patch to fix this problem is trivial by saving the %cr30 register
      before the firmware call and restoring it afterwards.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 2.6.12+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      54e181e0
  6. 20 10月, 2013 1 次提交
  7. 13 10月, 2013 4 次提交
  8. 01 10月, 2013 1 次提交
    • F
      irq: Consolidate do_softirq() arch overriden implementations · 7d65f4a6
      Frederic Weisbecker 提交于
      All arch overriden implementations of do_softirq() share the following
      common code: disable irqs (to avoid races with the pending check),
      check if there are softirqs pending, then execute __do_softirq() on
      a specific stack.
      
      Consolidate the common parts such that archs only worry about the
      stack switch.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@au1.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Mackerras <paulus@au1.ibm.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      7d65f4a6
  9. 27 8月, 2013 1 次提交
  10. 01 8月, 2013 3 次提交
    • T
      parisc: Fix interrupt routing for C8000 serial ports · dd5e6d6a
      Thomas Bogendoerfer 提交于
      We can't use dev->mod_index for selecting the interrupt routing entry,
      because it's not an index into interrupt routing table. It will be even
      wrong on a machine with 2 CPUs (4 cores). But all needed information is
      contained in the PAT entries for the serial ports. mod[0] contains the
      iosapic address and mod_info has some indications for the interrupt
      input (at least it looks like it). This patch implements the searching
      for the right iosapic and uses this interrupt input information.
      Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NHelge Deller <deller@gmx.de>
      dd5e6d6a
    • J
      parisc: Remove arch/parisc/kernel/sys32.h header · 5a0ce2dc
      John David Anglin 提交于
      The KERNEL_SYSCALL define is not used anymore so the header can be
      removed.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      5a0ce2dc
    • J
      parisc: Fix cache routines to ignore vma's with an invalid pfn · 50861f5a
      John David Anglin 提交于
      The parisc architecture does not have a pte special bit. As a result,
      special mappings are handled with the VM_PFNMAP and VM_MIXEDMAP flags.
      VM_MIXEDMAP mappings may or may not have a "struct page" backing. When
      pfn_valid() is false, there is no "struct page" backing. Otherwise, they
      are treated as normal pages.
      
      The FireGL driver uses the VM_MIXEDMAP without a backing "struct page".
      This treatment caused a panic due to a TLB data miss in
      update_mmu_cache. This appeared to be in the code generated for
      page_address(). We were in fact using a very circular bit of code to
      determine the physical address of the PFN in various cache routines.
      This wasn't valid when there was no "struct page" backing.  The needed
      address can in fact be determined simply from the PFN itself without
      using the "struct page".
      
      The attached patch updates update_mmu_cache(), flush_cache_mm(),
      flush_cache_range() and flush_cache_page() to check pfn_valid() and to
      directly compute the PFN physical and virtual addresses.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NHelge Deller <deller@gmx.de>
      50861f5a
  11. 15 7月, 2013 1 次提交
  12. 10 7月, 2013 2 次提交
    • J
      parisc: Ensure volatile space register %sr1 is not clobbered · e8d8fc21
      John David Anglin 提交于
      I still see the occasional random segv on rp3440.  Looking at one of
      these (a code 15), it appeared the problem must be with the cache
      handling of anonymous pages.  Reviewing this, I noticed that the space
      register %sr1 might be being clobbered when we flush an anonymous page.
      
      Register %sr1 is used for TLB purges in a couple of places.  These
      purges are needed on PA8800 and PA8900 processors to ensure cache
      consistency of flushed cache lines.
      
      The solution here is simply to move the %sr1 load into the TLB lock
      region needed to ensure that one purge executes at a time on SMP
      systems.  This was already the case for one use.  After a few days of
      operation, I haven't had a random segv on my rp3440.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NHelge Deller <deller@gmx.de>
      e8d8fc21
    • H
      parisc: more capabilities info in /proc/cpuinfo · 30a9f0b2
      Helge Deller 提交于
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # 3.10
      30a9f0b2
  13. 19 6月, 2013 3 次提交
  14. 01 6月, 2013 2 次提交
  15. 25 5月, 2013 5 次提交
    • H
      parisc: fix irq stack on UP and SMP · d96b51ec
      Helge Deller 提交于
      The logic to detect if the irq stack was already in use with
      raw_spin_trylock() is wrong, because it will generate a "trylock failure
      on UP" error message with CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y.
      
      arch_spin_trylock() can't be used either since in the CONFIG_SMP=n case
      no atomic protection is given and we are reentrant here. A mutex didn't
      worked either and brings more overhead by turning off interrupts.
      
      So, let's use the fastest path for parisc which is the ldcw instruction.
      
      Counting how often the irq stack was used is pretty useless, so just
      drop this piece of code.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      d96b51ec
    • J
      parisc: make interrupt and interruption stack allocation reentrant · b63a2bbc
      John David Anglin 提交于
      The get_stack_use_cr30 and get_stack_use_r30 macros allocate a stack
      frame for external interrupts and interruptions requiring a stack frame.
      They are currently not reentrant in that they save register context
      before the stack is set or adjusted.
      
      I have observed a number of system crashes where there was clear
      evidence of stack corruption during interrupt processing, and as a
      result register corruption. Some interruptions can still occur during
      interruption processing, however external interrupts are disabled and
      data TLB misses don't occur for absolute accesses. So, it's not entirely
      clear what triggers this issue. Also, if an interruption occurs when
      Q=0, it is generally not possible to recover as the shadowed registers
      are not copied.
      
      The attached patch reworks the get_stack_use_cr30 and get_stack_use_r30
      macros to allocate stack before doing register saves. The new code is a
      couple of instructions shorter than the old implementation. Thus, it's
      an improvement even if it doesn't fully resolve the stack corruption
      issue. Based on limited testing, it improves SMP system stability.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      b63a2bbc
    • H
      parisc: show number of FPE and unaligned access handler calls in /proc/interrupts · d0c3be80
      Helge Deller 提交于
      Show number of floating point assistant and unaligned access fixup
      handler in /proc/interrupts file.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      d0c3be80
    • H
      parisc: use PAGE_SHIFT instead of hardcoded value 12 in pacache.S · d845b5fb
      Helge Deller 提交于
      additionally clean up some whitespaces & tabs.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      d845b5fb
    • H
      parisc: add rp5470 entry to machine database · 949451b9
      Helge Deller 提交于
      Signed-off-by: NHelge Deller <deller@gmx.de>
      949451b9
  16. 21 5月, 2013 1 次提交
  17. 12 5月, 2013 2 次提交
    • J
      parisc: fix SMP races when updating PTE and TLB entries in entry.S · f0a18819
      John David Anglin 提交于
      Currently, race conditions exist in the handling of TLB interruptions in
      entry.S.  In particular, dirty bit updates can be lost if an accessed
      interruption occurs just after the dirty bit interruption on a different
      cpu.  Lost dirty bit updates result in user pages not being flushed and
      general system instability.  This change adds lock and unlock macros to
      synchronize all PTE and TLB updates done in entry.S.  As a result,
      userspace stability is significantly improved.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      f0a18819
    • H
      parisc: implement irq stacks - part 2 (v2) · 416821d3
      Helge Deller 提交于
      This patch fixes few build issues which were introduced with the last
      irq stack patch, e.g. the combination of stack overflow check and irq
      stack.
      
      Furthermore we now do proper locking and change the irq bh handler
      to use the irq stack as well.
      
      In /proc/interrupts one now can monitor how huge the irq stack has grown
      and how often it was preferred over the kernel stack.
      
      IRQ stacks are now enabled by default just to make sure that we not
      overflow the kernel stack by accident.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      416821d3
  18. 10 5月, 2013 1 次提交
  19. 08 5月, 2013 5 次提交