1. 27 9月, 2008 1 次提交
  2. 25 9月, 2008 1 次提交
  3. 24 9月, 2008 22 次提交
  4. 10 9月, 2008 2 次提交
    • P
      x86: fix memmap=exactmap boot argument · d6be118a
      Prarit Bhargava 提交于
      When using kdump modifying the e820 map is yielding strange results.
      
      For example starting with
      
       BIOS-provided physical RAM map:
       BIOS-e820: 0000000000000100 - 0000000000093400 (usable)
       BIOS-e820: 0000000000093400 - 00000000000a0000 (reserved)
       BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
       BIOS-e820: 000000003fee0000 - 000000003fef3000 (ACPI data)
       BIOS-e820: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
       BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
       BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
       BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
       BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
       BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
      
      and booting with args
      
      memmap=exactmap memmap=640K@0K memmap=5228K@16384K memmap=125188K@22252K memmap=76K#1047424K memmap=564K#1047500K
      
      resulted in:
      
       user-defined physical RAM map:
       user: 0000000000000000 - 0000000000093400 (usable)
       user: 0000000000093400 - 00000000000a0000 (reserved)
       user: 0000000000100000 - 000000003fee0000 (usable)
       user: 000000003fee0000 - 000000003fef3000 (ACPI data)
       user: 000000003fef3000 - 000000003ff80000 (ACPI NVS)
       user: 000000003ff80000 - 0000000040000000 (reserved)
       user: 00000000e0000000 - 00000000f0000000 (reserved)
       user: 00000000fec00000 - 00000000fec10000 (reserved)
       user: 00000000fee00000 - 00000000fee01000 (reserved)
       user: 00000000ff000000 - 0000000100000000 (reserved)
      
      But should have resulted in:
      
       user-defined physical RAM map:
       user: 0000000000000000 - 00000000000a0000 (usable)
       user: 0000000001000000 - 000000000151b000 (usable)
       user: 00000000015bb000 - 0000000008ffc000 (usable)
       user: 000000003fee0000 - 000000003ff80000 (ACPI data)
      
      This is happening because of an improper usage of strcmp() in the
      e820 parsing code.  The strcmp() always returns !0 and never resets the
      value for e820.nr_map and returns an incorrect user-defined map.
      
      This patch fixes the problem.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d6be118a
    • J
      lib: Correct printk %pF to work on all architectures · deac93df
      James Bottomley 提交于
      It was introduced by "vsprintf: add support for '%pS' and '%pF' pointer
      formats" in commit 0fe1ef24.  However,
      the current way its coded doesn't work on parisc64.  For two reasons: 1)
      parisc isn't in the #ifdef and 2) parisc has a different format for
      function descriptors
      
      Make dereference_function_descriptor() more accommodating by allowing
      architecture overrides.  I put the three overrides (for parisc64, ppc64
      and ia64) in arch/kernel/module.c because that's where the kernel
      internal linker which knows how to deal with function descriptors sits.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      deac93df
  5. 09 9月, 2008 4 次提交
  6. 08 9月, 2008 2 次提交
    • H
      powerpc: Fix rare boot build breakage · 4ff23fa9
      Hugh Dickins 提交于
      A make -j20 powerpc kernel build broke a couple of months ago saying:
      In file included from arch/powerpc/boot/gunzip_util.h:13,
                       from arch/powerpc/boot/prpmc2800.c:21:
      arch/powerpc/boot/zlib.h:85: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘*’ token
      arch/powerpc/boot/zlib.h:630: warning: type defaults to ‘int’ in declaration of ‘Byte’
      arch/powerpc/boot/zlib.h:630: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token
      
      It happened again yesterday: too rare for me to confirm the fix, but
      it looks like the list of dependants on gunzip_util.h was incomplete.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4ff23fa9
    • A
      powerpc/spufs: Fix possible scheduling of a context to multiple SPEs · b2e601d1
      Andre Detsch 提交于
      We currently have a race when scheduling a context to a SPE -
      after we have found a runnable context in spusched_tick, the same
      context may have been scheduled by spu_activate().
      
      This may result in a panic if we try to unschedule a context that has
      been freed in the meantime.
      
      This change exits spu_schedule() if the context has already been
      scheduled, so we don't end up scheduling it twice.
      Signed-off-by: NAndre Detsch <adetsch@br.ibm.com>
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      b2e601d1
  7. 07 9月, 2008 3 次提交
  8. 06 9月, 2008 5 次提交
    • Y
      x86: move mtrr cpu cap setting early in early_init_xxxx · dd786dd1
      Yinghai Lu 提交于
      Krzysztof Helt found MTRR is not detected on k6-2
      
      root cause:
      	we moved mtrr_bp_init() early for mtrr trimming,
      and in early_detect we only read the CPU capability from cpuid,
      so some cpu doesn't have that bit in cpuid.
      
      So we need to add early_init_xxxx to preset those bit before mtrr_bp_init
      for those earlier cpus.
      
      this patch is for v2.6.27
      Reported-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dd786dd1
    • K
      x86: delay early cpu initialization until cpuid is done · 12cf105c
      Krzysztof Helt 提交于
      Move early cpu initialization after cpu early get cap so the
      early cpu initialization can fix up cpu caps.
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      12cf105c
    • L
      [ARM] 5241/1: provide ioremap_wc() · 1ad77a87
      Lennert Buytenhek 提交于
      This patch provides an ARM implementation of ioremap_wc().
      
      We use different page table attributes depending on which CPU we
      are running on:
      
      - Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
        possible mapping types (CB=00/01/10/11).  We can't use any of the
        cached memory types (CB=10/11), since that breaks coherency with
        peripheral devices.  Both CB=00 and CB=01 are suitable for _wc, and
        CB=01 (Uncached/Buffered) allows the hardware more freedom than
        CB=00, so we'll use that.
      
        (The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
        but isn't allowed to merge them, but there is no other mapping type
        we can use that allows the hardware to delay and merge stores, so
        we'll go with CB=01.)
      
      - XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
        difference that on these platforms, CB=01 actually _does_ allow
        merging stores.  (If you want noncoalescing bufferable behavior
        on Xscale v1/v2, you need to use XCB=101.)
      
      - Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
        mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
        in ARMv6 parlance).
      
        The ARMv6 ARM explicitly says that any accesses to Normal memory can
        be merged, which makes Normal memory more suitable for _wc mappings
        than Device or Strongly Ordered memory, as the latter two mapping
        types are guaranteed to maintain transaction number, size and order.
        We use the Uncached variety of Normal mappings for the same reason
        that we can't use C=1 mappings on ARMv5.
      
        The xsc3 Architecture Specification documents TEXCB=00100 as being
        Uncacheable and allowing coalescing of writes, which is also just
        what we need.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1ad77a87
    • T
      x86: HPET: read back compare register before reading counter · 72d43d9b
      Thomas Gleixner 提交于
      After fixing the u32 thinko I sill had occasional hickups on ATI chipsets
      with small deltas. There seems to be a delay between writing the compare
      register and the transffer to the internal register which triggers the
      interrupt. Reading back the value makes sure, that it hit the internal
      match register befor we compare against the counter value.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      72d43d9b
    • T
      x86: HPET fix moronic 32/64bit thinko · f7676254
      Thomas Gleixner 提交于
      We use the HPET only in 32bit mode because:
      1) some HPETs are 32bit only
      2) on i386 there is no way to read/write the HPET atomic 64bit wide
      
      The HPET code unification done by the "moron of the year" did
      not take into account that unsigned long is different on 32 and
      64 bit.
      
      This thinko results in a possible endless loop in the clockevents
      code, when the return comparison fails due to the 64bit/332bit
      unawareness. 
      
      unsigned long cnt = (u32) hpet_read() + delta can wrap over 32bit.
      but the final compare will fail and return -ETIME causing endless
      loops.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f7676254