1. 11 9月, 2007 4 次提交
  2. 06 9月, 2007 2 次提交
    • H
      m32r: Rename STI/CLI macros · 7071b291
      Hirokazu Takata 提交于
      The names of STI and CLI macros were derived from i386 arch historically,
      but their name are incomprehensible.
      So, for easy to understand, rename these macros to ENABLE_INTERRUPTS
      and DISABLE_INTERRUPTS, respectively.
      Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
      7071b291
    • H
      m32r: build fix of entry.S · 33205613
      Hirokazu Takata 提交于
      This patch fixes the following compile error:
      <--  snip  -->
       ...
        AS      arch/m32r/kernel/entry.o
      /home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S: Assembler messages:
      /home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S:358: Error: bad instruction `addi r0,#(((((0)+(64))+(32))+(32)))'
      make[2]: *** [arch/m32r/kernel/entry.o] Error 1
      <--  snip  -->
      Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
      Cc: Adrian Bunk <bunk@kernel.org>
      33205613
  3. 05 9月, 2007 1 次提交
    • C
      [x86 setup] Work around bug in Xen HVM · ce29a1f8
      Christian Ehrhardt 提交于
      Apparently XEN does not keep the contents of the 48-bit gdt_48 data
      structure that is passed to lgdt in the XEN machine state. Instead it
      appears to save the _address_ of the 48-bit descriptor
      somewhere. Unfortunately this data happens to reside on the stack and
      is probably no longer availiable at the time of the actual protected
      mode jump.
      
      This is Xen bug but given that there is a one-line patch to work
      around this problem, the linux kernel should probably do this.  My fix
      is to make the gdt_48 description in setup_gdt static (in setup_idt
      this is already the case). This allows the kernel to boot under
      Xen HVM again.
      Signed-off-by: NChristian Ehrhardt <lk@c--e.de>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ce29a1f8
  4. 03 9月, 2007 10 次提交
  5. 01 9月, 2007 7 次提交
  6. 31 8月, 2007 8 次提交
  7. 30 8月, 2007 7 次提交
  8. 29 8月, 2007 1 次提交
    • K
      [POWERPC] Flush registers to proper task context · 0ee6c15e
      Kumar Gala 提交于
      When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
      we need to respect the task_struct that the caller has passed to us.
      
      Most cases we are called with current, however sometimes (ptrace) we may
      be passed a different task_struct.
      
      This showed up when using gdbserver debugging a simple program that used
      floating point. When gdb tried to show the FP regs they all showed up as
      0, because the child's FP registers were never properly flushed to memory.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      0ee6c15e