1. 09 11月, 2012 15 次提交
  2. 04 11月, 2012 1 次提交
  3. 03 11月, 2012 2 次提交
  4. 02 11月, 2012 4 次提交
    • D
      FRV: Fix the new-style kernel_thread() stuff · e7aa51b2
      David Howells 提交于
      The kernel_thread() changes for FRV don't work, and FRV fails to boot,
      starting with:
      
      	commit 02ce496f
      	Author: Al Viro <viro@zeniv.linux.org.uk>
      	Date:   Tue Sep 18 22:18:51 2012 -0400
      	Subject: frv: split ret_from_fork, simplify kernel_thread() a lot
      
      The problem is that the userspace registers are completely cleared when a
      kernel thread is created and all subsequent user threads are then copied from
      that.  Unfortunately, however, the TBR and PSR registers are restored from the
      pt_regs and the values they should be set to are clobbered by the memset.
      
      Instead, copy across the old user registers as normal, and then merely alter
      GR8 and GR9 in it if we're going to execute a kernel thread.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      e7aa51b2
    • D
      FRV: Fix the preemption handling · 1ee6f566
      David Howells 提交于
      Fix the preemption handling in FRV code where the PREEMPT_ACTIVE value is
      incorrectly loaded into the threadinfo flags rather than the threadinfo
      preemption count.
      
      Unfortunately, the code cannot be simply converted to use
      preempt_schedule_irq() as is because FRV uses virtual interrupt disablement to
      cut down on the cost of actually disabling interrupts and thus
      local_irq_enable() doesn't actually enable interrupts.
      Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Al Viro <viro@ZenIV.linux.org.uk>
      1ee6f566
    • D
      FRV: Don't objcopy the GNU build_id note · 5f0231d9
      David Howells 提交于
      Don't let objcopy transfer the GNU build_id note into the loadable image as it
      is located at address 0 and the image ends up >3G in size.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      5f0231d9
    • D
      FRV: Add missing linux/export.h #inclusions · a5788caa
      David Howells 提交于
      Add missing linux/export.h #inclusions to the FRV arch.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      a5788caa
  5. 01 11月, 2012 2 次提交
    • X
      KVM: x86: fix vcpu->mmio_fragments overflow · 87da7e66
      Xiao Guangrong 提交于
      After commit b3356bf0 (KVM: emulator: optimize "rep ins" handling),
      the pieces of io data can be collected and write them to the guest memory
      or MMIO together
      
      Unfortunately, kvm splits the mmio access into 8 bytes and store them to
      vcpu->mmio_fragments. If the guest uses "rep ins" to move large data, it
      will cause vcpu->mmio_fragments overflow
      
      The bug can be exposed by isapc (-M isapc):
      
      [23154.818733] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
      [ ......]
      [23154.858083] Call Trace:
      [23154.859874]  [<ffffffffa04f0e17>] kvm_get_cr8+0x1d/0x28 [kvm]
      [23154.861677]  [<ffffffffa04fa6d4>] kvm_arch_vcpu_ioctl_run+0xcda/0xe45 [kvm]
      [23154.863604]  [<ffffffffa04f5a1a>] ? kvm_arch_vcpu_load+0x17b/0x180 [kvm]
      
      Actually, we can use one mmio_fragment to store a large mmio access then
      split it when we pass the mmio-exit-info to userspace. After that, we only
      need two entries to store mmio info for the cross-mmio pages access
      Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      87da7e66
    • K
      xen/mmu: Use Xen specific TLB flush instead of the generic one. · 95a7d768
      Konrad Rzeszutek Wilk 提交于
      As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the
      hypervisor to do a TLB flush on all active vCPUs. If instead
      we were using the generic one (which ends up being xen_flush_tlb)
      we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But
      before we make that hypercall the kernel will IPI all of the
      vCPUs (even those that were asleep from the hypervisor
      perspective). The end result is that we needlessly wake them
      up and do a TLB flush when we can just let the hypervisor
      do it correctly.
      
      This patch gives around 50% speed improvement when migrating
      idle guest's from one host to another.
      
      Oracle-bug: 14630170
      
      CC: stable@vger.kernel.org
      Tested-by: NJingjie Jiang <jingjie.jiang@oracle.com>
      Suggested-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      95a7d768
  6. 30 10月, 2012 2 次提交
  7. 29 10月, 2012 3 次提交
    • W
      ARM: 7567/1: io: avoid GCC's offsettable addressing modes for halfword accesses · 7629a9f6
      Will Deacon 提交于
      Using the 'o' memory constraint in inline assembly can result in GCC
      generating invalid immediate offsets for memory access instructions with
      reduced addressing capabilities (i.e. smaller than 12-bit immediate
      offsets):
      
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983
      
      As there is no constraint to specify the exact addressing mode we need,
      fallback to using 'Q' exclusively for halfword I/O accesses. This may
      emit an additional add instruction (using an extra register) in order
      to construct the address but it will always be accepted by GAS.
      Reported-by: NBastian Hecht <hechtb@googlemail.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7629a9f6
    • P
      ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set · 39141ddf
      Paul Walmsley 提交于
      After commit 846a1368 ("ARM: vfp: fix
      saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
      started crashing during boot with omap2plus_defconfig:
      
      [    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
      [    3.915954]  mmcblk0: p1
      [    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
      [    4.093719] Modules linked in:
      [    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b8 #570)
      [    4.103149] PC is at vfp_reload_hw+0x1c/0x44
      [    4.107666] LR is at __und_usr_fault_32+0x0/0x8
      
      It turns out that the context save/restore fix unmasked a latent bug
      in commit 5aaf2544 ("ARM: 6203/1: Make
      VFPv3 usable on ARMv6").  When CONFIG_VFPv3 is set, but the kernel is
      booted on a pre-VFPv3 core, the code attempts to save and restore the
      d16-d31 VFP registers.  These are only present on non-D16 VFPv3+, so
      this results in an undefined instruction exception.  The code didn't
      crash before commit 846a1368 because the save and restore code was
      only touching d0-d15, present on all VFP.
      
      Fix by implementing a request from Russell King to add a new HWCAP
      flag that affirmatively indicates the presence of the d16-d31
      registers:
      
         http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2
      
      and some feedback from Måns to clarify the name of the HWCAP flag.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Martin <dave.martin@linaro.org>
      Cc: Måns Rullgård <mans.rullgard@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      39141ddf
    • F
      ARM: 7565/1: sched: stop sched_clock() during suspend · 6a4dae5e
      Felipe Balbi 2 提交于
      The scheduler imposes a requirement to sched_clock()
      which is to stop the clock during suspend, if we don't
      do that any RT thread will be rescheduled in the future
      which might cause any sort of problems.
      
      This became an issue on OMAP when we converted omap-i2c.c
      to use threaded IRQs, it turned out that depending on how
      much time we spent on suspend, the I2C IRQ thread would
      end up being rescheduled so far in the future that I2C
      transfers would timeout and, because omap_hsmmc depends
      on an I2C-connected device to detect if an MMC card is
      inserted in the slot, our rootfs would just vanish.
      
      arch/arm/kernel/sched_clock.c already had an optional
      implementation (sched_clock_needs_suspend()) which would
      handle scheduler's requirement properly, what this patch
      does is simply to make that implementation non-optional.
      
      Note that this has the side-effect that printk timings
      won't reflect the actual time spent on suspend so other
      methods to measure that will have to be used.
      
      This has been tested with beagleboard XM (OMAP3630) and
      pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
      after this patch.
      
      Thanks to Kevin Hilman for helping out with debugging.
      Acked-by: NKevin Hilman <khilman@ti.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6a4dae5e
  8. 27 10月, 2012 4 次提交
  9. 26 10月, 2012 7 次提交