1. 10 Jul, 2009 6 commits
  2. 21 Jun, 2009 2 commits
  3. 18 Jun, 2009 3 commits
  4. 17 Jun, 2009 11 commits
    • Ingo Molnar's avatar
      Merge branch 'x86/urgent' into x86/mce3 · 81340006
      Ingo Molnar authored
      Conflicts:
      	arch/x86/kernel/cpu/mcheck/mce_intel.c
      
      Merge reason: merge with an urgent-branch MCE fix.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      81340006
    • Prarit Bhargava's avatar
      x86: nmi: Add Intel processor 0x6f4 to NMI perfctr1 workaround · fe955e5c
      Prarit Bhargava authored
      Expand Intel NMI perfctr1 workaround to include a Core2 processor stepping
      (cpuid family-6, model-f, stepping-4).  Resolves a situation where the NMI
      would not enable on these processors.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: prarit@redhat.com
      Cc: suresh.b.siddha@intel.com
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fe955e5c
    • H. Peter Anvin's avatar
      x86, mce: mce_intel.c needs <asm/apic.h> · 1bf7b31e
      H. Peter Anvin authored
      mce_intel.c uses apic_write() and lapic_get_maxlvt(), and so it needs
      <asm/apic.h>.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      1bf7b31e
    • Jaswinder Singh Rajput's avatar
    • Figo.zhang's avatar
      x86, io_apic.c: Work around compiler warning · 50a8d4d2
      Figo.zhang authored
      This compiler warning:
      
        arch/x86/kernel/apic/io_apic.c: In function ‘ioapic_write_entry’:
        arch/x86/kernel/apic/io_apic.c:466: warning: ‘eu’ is used uninitialized in this function
        arch/x86/kernel/apic/io_apic.c:465: note: ‘eu’ was declared here
      
      Is bogus as 'eu' is always initialized. But annotate it away by
      initializing the variable, to make it easier for people to notice
      real warnings. A compiler that sees through this logic will
      optimize away the initialization.
      Signed-off-by: default avatarFigo.zhang <figo1802@gmail.com>
      LKML-Reference: <1245248720.3312.27.camel@myhost>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      50a8d4d2
    • Cyrill Gorcunov's avatar
      x86: mce: Don't touch THERMAL_APIC_VECTOR if no active APIC present · 5ce4243d
      Cyrill Gorcunov authored
      If APIC was disabled (for some reason) and as result
      it's not even mapped we should not try to enable thermal
      interrupts at all.
      Reported-by: default avatarSimon Holm Thøgersen <odie@cs.aau.dk>
      Tested-by: default avatarSimon Holm Thøgersen <odie@cs.aau.dk>
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <20090615182633.GA7606@lenovo>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5ce4243d
    • Andi Kleen's avatar
      x86: mce: Handle banks == 0 case in K7 quirk · 203abd67
      Andi Kleen authored
      Vegard Nossum reported:
      
      > I get an MCE-related crash like this in latest linus tree:
      >
      > [    0.115341] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
      > [    0.116396] CPU: L2 Cache: 512K (64 bytes/line)
      > [    0.120570] mce: CPU supports 0 MCE banks
      > [    0.124870] BUG: unable to handle kernel NULL pointer dereference at 00000000 00000010
      > [    0.128001] IP: [<ffffffff813b98ad>] mcheck_init+0x278/0x320
      > [    0.128001] PGD 0
      > [    0.128001] Thread overran stack, or stack corrupted
      > [    0.128001] Oops: 0002 [#1] PREEMPT SMP
      > [    0.128001] last sysfs file:
      > [    0.128001] CPU 0
      > [    0.128001] Modules linked in:
      > [    0.128001] Pid: 0, comm: swapper Not tainted 2.6.30 #426
      > [    0.128001] RIP: 0010:[<ffffffff813b98ad>]  [<ffffffff813b98ad>] mcheck_init+0x278/0x320
      > [    0.128001] RSP: 0018:ffffffff81595e38  EFLAGS: 00000246
      > [    0.128001] RAX: 0000000000000010 RBX: ffffffff8158f900 RCX: 0000000000000000
      > [    0.128001] RDX: 0000000000000000 RSI: 00000000000000ff RDI: 0000000000000010
      > [    0.128001] RBP: ffffffff81595e68 R08: 0000000000000001 R09: 0000000000000000
      > [    0.128001] R10: 0000000000000010 R11: 0000000000000000 R12: 0000000000000000
      > [    0.128001] R13: 00000000ffffffff R14: 0000000000000000 R15: 0000000000000000
      > [    0.128001] FS:  0000000000000000(0000) GS:ffff880002288000(0000) knlGS:00000
      > 00000000000
      > [    0.128001] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      > [    0.128001] CR2: 0000000000000010 CR3: 0000000001001000 CR4: 00000000000006b0
      > [    0.128001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [    0.128001] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
      > [    0.128001] Process swapper (pid: 0, threadinfo ffffffff81594000, task ffffff
      > ff8152a4a0)
      > [    0.128001] Stack:
      > [    0.128001]  0000000081595e68 5aa50ed3b4ddbe6e ffffffff8158f900 ffffffff8158f
      > 914
      > [    0.128001]  ffffffff8158f948 0000000000000000 ffffffff81595eb8 ffffffff813b8
      > 69c
      > [    0.128001]  5aa50ed3b4ddbe6e 00000001078bfbfd 0000062300000800 5aa50ed3b4ddb
      > e6e
      > [    0.128001] Call Trace:
      > [    0.128001]  [<ffffffff813b869c>] identify_cpu+0x331/0x392
      > [    0.128001]  [<ffffffff815a1445>] identify_boot_cpu+0x23/0x6e
      > [    0.128001]  [<ffffffff815a14ac>] check_bugs+0x1c/0x60
      > [    0.128001]  [<ffffffff8159c075>] start_kernel+0x403/0x46e
      > [    0.128001]  [<ffffffff8159b2ac>] x86_64_start_reservations+0xac/0xd5
      > [    0.128001]  [<ffffffff8159b3ea>] x86_64_start_kernel+0x115/0x14b
      > [    0.128001]  [<ffffffff8159b140>] ? early_idt_handler+0x0/0x71
      
      This happens on QEMU which reports MCA capability, but no banks.
      Without this patch there is a buffer overrun and boot ops because
      the code would try to initialize the 0 element of a zero length
      kmalloc() buffer.
      Reported-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Tested-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      LKML-Reference: <20090615125200.GD31969@one.firstfloor.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      203abd67
    • Ingo Molnar's avatar
      Merge branch 'linus' into x86/urgent · cc4949e1
      Ingo Molnar authored
      Merge reason: pull in latest to fix a bug in it.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cc4949e1
    • H. Peter Anvin's avatar
      x86, boot: use .code16gcc instead of .code16 · 28b48688
      H. Peter Anvin authored
      Use .code16gcc to compile arch/x86/boot/bioscall.S rather than
      .code16, since some older versions of binutils can't generate 32-bit
      addressing expressions (67 prefixes) in .code16 mode, only in
      .code16gcc mode.
      Reported-by: default avatarTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      28b48688
    • Cliff Wickman's avatar
      x86: correct the conversion of EFI memory types · e2a71476
      Cliff Wickman authored
      This patch causes all the EFI_RESERVED_TYPE memory reservations to be recorded
      in the e820 table as type E820_RESERVED.
      
      (This patch replaces one called 'x86: vendor reserved memory type'.
       This version has been discussed a bit with Peter and Yinghai but not given
       a final opinion.)
      
      Without this patch EFI_RESERVED_TYPE memory reservations may be
      marked usable in the e820 table. There may be a collision between
      kernel use and some reserver's use of this memory.
      
      (An example use of this functionality is the UV system, which
       will access extremely large areas of memory with a memory engine
       that allows a user to address beyond the processor's range.  Such
       areas are reserved in the EFI table by the BIOS.
       Some loaders have a restricted number of entries possible in the e820 table,
       hence the need to record the reservations in the unrestricted EFI table.)
      
      The call to do_add_efi_memmap() is only made if "add_efi_memmap" is specified
      on the kernel command line.
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      e2a71476
    • H. Peter Anvin's avatar
      x86: cap iomem_resource to addressable physical memory · 95ee14e4
      H. Peter Anvin authored
      iomem_resource is by default initialized to -1, which means 64 bits of
      physical address space if 64-bit resources are enabled.  However, x86
      CPUs cannot address 64 bits of physical address space.  Thus, we want
      to cap the physical address space to what the union of all CPU can
      actually address.
      
      Without this patch, we may end up assigning inaccessible values to
      uninitialized 64-bit PCI memory resources.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Martin Mares <mj@ucw.cz>
      Cc: stable@kernel.org
      95ee14e4
  5. 16 Jun, 2009 18 commits