1. 31 12月, 2008 12 次提交
  2. 29 12月, 2008 1 次提交
  3. 25 12月, 2008 1 次提交
    • M
      [S390] arch_setup_additional_pages arguments · fc5243d9
      Martin Schwidefsky 提交于
      arch_setup_additional_pages currently gets two arguments, the binary
      format descripton and an indication if the process uses an executable
      stack or not. The second argument is not used by anybody, it could
      be removed without replacement.
      
      What actually does make sense is to pass an indication if the process
      uses the elf interpreter or not. The glibc code will not use anything
      from the vdso if the process does not use the dynamic linker, so for
      statically linked binaries the architecture backend can choose not
      to map the vdso.
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      fc5243d9
  4. 23 12月, 2008 4 次提交
  5. 21 12月, 2008 11 次提交
  6. 16 12月, 2008 10 次提交
  7. 03 12月, 2008 1 次提交
    • T
      powerpc: Better setup of boot page TLB entry · b3898895
      Trent Piepho 提交于
      The initial TLB mapping for the kernel boot didn't set the memory coherent
      attribute, MAS2[M], in SMP mode.
      
      If this code supported booting a secondary processor, which it doesn't yet,
      but if it did, then when a secondary processor boots, it would probably signal
      the primary processor by setting a variable called something like
      __secondary_hold_acknowledge.  However, due to the lack of the M bit, the
      primary processor would not snoop the transaction (even if a transaction were
      broadcast).  If primary CPU's L1 D-cache had a copy, it would not be flushed
      and the CPU would never see the ack.  Which would have resulted in the primary
      CPU spinning for a long time, perhaps a full second before it gives up, while
      it would have waited for the ack from the secondary CPU that it wouldn't have
      been able to see because of the stale cache.
      
      The value of MAS2 for the boot page TLB1 entry is a compile time constant,
      so there is no need to calculate it in powerpc assembly language.
      
      Also, from the MPC8572 manual section 6.12.5.3, "Bits that represent
      offsets within a page are ignored and should be cleared." Existing code
      didn't clear them, this code does.
      
      The same when the page of KERNELBASE is found; we don't need to use asm to
      mask the lower 12 bits off.
      
      In the code that computes the address to rfi from, don't hard code the
      offset to 24 bytes, but have the assembler figure that out for us.
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      b3898895