1. 05 Dec, 2009 1 commit
    • Leann Ogasawara's avatar
      x86: ASUS P4S800 reboot=bios quirk · 4832ddda
      Leann Ogasawara authored
      Bug reporter noted their system with an ASUS P4S800 motherboard would
      hang when rebooting unless reboot=b was specified.  Their dmidecode
      didn't contain descriptive System Information for Manufacturer or
      Product Name, so I used their Base Board Information to create a
      reboot quirk patch.  The bug reporter confirmed this patch resolves
      the reboot hang.
      
      Handle 0x0001, DMI type 1, 25 bytes
      System Information
             Manufacturer: System Manufacturer
             Product Name: System Name
             Version: System Version
             Serial Number: SYS-1234567890
             UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F
             Wake-up Type: Power Switch
      
      Handle 0x0002, DMI type 2, 8 bytes
      Base Board Information
           Manufacturer: ASUSTeK Computer INC.
           Product Name: P4S800
           Version: REV 1.xx
           Serial Number: xxxxxxxxxxx
      
      BugLink: http://bugs.launchpad.net/bugs/366682
      
      ASUS P4S800 will hang when rebooting unless reboot=b is specified.
      Add a quirk to reboot through the bios.
      Signed-off-by: default avatarLeann Ogasawara <leann.ogasawara@canonical.com>
      LKML-Reference: <1259972107.4629.275.camel@emiko>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      4832ddda
  2. 03 Dec, 2009 1 commit
  3. 28 Nov, 2009 1 commit
  4. 20 Nov, 2009 1 commit
    • Thomas Gleixner's avatar
      x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage · 746357d6
      Thomas Gleixner authored
      When the kernel is compiled with -pg for tracing GCC 4.4.x inserts
      stack alignment of a function _before_ the mcount prologue if the
      -march=pentium-mmx is set and -mtune=generic is not set. This breaks
      the assumption of the function graph tracer which expects that the
      mcount prologue
      
             push %ebp
             mov  %esp, %ebp
      
      is the first stack operation in a function because it needs to modify
      the function return address on the stack to trap into the tracer
      before returning to the real caller.
      
      The generated code is:
      
              push   %edi
              lea    0x8(%esp),%edi
              and    $0xfffffff0,%esp
              pushl  -0x4(%edi)
              push   %ebp
              mov    %esp,%ebp
      
      so the tracer modifies the copy of the return address which is stored
      after the stack alignment and therefor does not trap the return which
      in turn breaks the call chain logic of the tracer and leads to a
      kernel panic.
      
      Aside of the fact that the generated code is horrible for no good
      reason other -march -mtune options generate the expected:
      
              push   %ebp
              mov    %esp,%ebp
              and    $0xfffffff0,%esp
      
      which does the same and keeps everything intact.
      
      After some experimenting we found out that this problem is restricted
      to gcc4.4.x and to the following -march settings:
      
      i586, pentium, pentium-mmx, k6, k6-2, k6-3, winchip-c6, winchip2, c3,
      geode
      
      By adding -mtune=generic the code generator produces always the
      expected code.
      
      So forcing -mtune=generic when CONFIG_FUNCTION_GRAPH_TRACER=y is not
      pretty, but at the moment the only way to prevent that the kernel
      trips over gcc-shrooms induced code madness.
      
      Most distro kernels have CONFIG_X86_GENERIC=y anyway which forces
      -mtune=generic as well so it will not impact those.
      
      References: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
      	    http://lkml.org/lkml/2009/11/19/17Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <alpine.LFD.2.00.0911200206570.24119@localhost.localdomain>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>,
      Cc: Jeff Law <law@redhat.com>
      Cc: gcc@gcc.gnu.org
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Andrew Haley <aph@redhat.com>
      Cc: Richard Guenther <richard.guenther@gmail.com>
      Cc: stable@kernel.org
      746357d6
  5. 16 Nov, 2009 1 commit
    • Prarit Bhargava's avatar
      x86: AMD Northbridge: Verify NB's node is online · 303fc087
      Prarit Bhargava authored
      Fix panic seen on some IBM and HP systems on 2.6.32-rc6:
      
       BUG: unable to handle kernel NULL pointer dereference at (null)
       IP: [<ffffffff8120bf3f>] find_next_bit+0x77/0x9c
        [...]
        [<ffffffff8120bbde>] cpumask_next_and+0x2e/0x3b
        [<ffffffff81225c62>] pci_device_probe+0x8e/0xf5
        [<ffffffff812b9be6>] ? driver_sysfs_add+0x47/0x6c
        [<ffffffff812b9da5>] driver_probe_device+0xd9/0x1f9
        [<ffffffff812b9f1d>] __driver_attach+0x58/0x7c
        [<ffffffff812b9ec5>] ? __driver_attach+0x0/0x7c
        [<ffffffff812b9298>] bus_for_each_dev+0x54/0x89
        [<ffffffff812b9b4f>] driver_attach+0x19/0x1b
        [<ffffffff812b97ae>] bus_add_driver+0xd3/0x23d
        [<ffffffff812ba1e7>] driver_register+0x98/0x109
        [<ffffffff81225ed0>] __pci_register_driver+0x63/0xd3
        [<ffffffff81072776>] ? up_read+0x26/0x2a
        [<ffffffffa0081000>] ? k8temp_init+0x0/0x20 [k8temp]
        [<ffffffffa008101e>] k8temp_init+0x1e/0x20 [k8temp]
        [<ffffffff8100a073>] do_one_initcall+0x6d/0x185
        [<ffffffff8108d765>] sys_init_module+0xd3/0x236
        [<ffffffff81011ac2>] system_call_fastpath+0x16/0x1b
      
      I put in a printk and commented out the set_dev_node()
      call when and got this output:
      
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x0
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x1
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x2
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x3
      
      I.e. the issue appears to be that the HW has set val to a valid
      value, however, the system is only configured for a single
      node -- 0, the others are offline.
      
      Check to see if the node is actually online before setting
      the numa node for an AMD northbridge in quirk_amd_nb_node().
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: bhavna.sarathy@amd.com
      Cc: jbarnes@virtuousgeek.org
      Cc: andreas.herrmann3@amd.com
      LKML-Reference: <20091112180933.12532.98685.sendpatchset@prarit.bos.redhat.com>
      [ v2: clean up the code and add comments ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      303fc087
  6. 11 Nov, 2009 1 commit
  7. 10 Nov, 2009 3 commits
  8. 08 Nov, 2009 1 commit
  9. 06 Nov, 2009 1 commit
  10. 04 Nov, 2009 1 commit
    • Stefani Seibold's avatar
      x86, fs: Fix x86 procfs stack information for threads on 64-bit · 89240ba0
      Stefani Seibold authored
      This patch fixes two issues in the procfs stack information on
      x86-64 linux.
      
      The 32 bit loader compat_do_execve did not store stack
      start. (this was figured out by Alexey Dobriyan).
      
      The stack information on a x64_64 kernel always shows 0 kbyte
      stack usage, because of a missing implementation of the KSTK_ESP
      macro which always returned -1.
      
      The new implementation now returns the right value.
      Signed-off-by: default avatarStefani Seibold <stefani@seibold.net>
      Cc: Americo Wang <xiyou.wangcong@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <1257240160.4889.24.camel@wall-e>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      89240ba0
  11. 03 Nov, 2009 2 commits
  12. 02 Nov, 2009 2 commits
  13. 29 Oct, 2009 1 commit
  14. 28 Oct, 2009 1 commit
  15. 27 Oct, 2009 1 commit
  16. 26 Oct, 2009 3 commits
    • Jan Beulich's avatar
      x86-64: Fix register leak in 32-bit syscall audting · 81766741
      Jan Beulich authored
      Restoring %ebp after the call to audit_syscall_exit() is not
      only unnecessary (because the register didn't get clobbered),
      but in the sysenter case wasn't even doing the right thing: It
      loaded %ebp from a location below the top of stack (RBP <
      ARGOFFSET), i.e. arbitrary kernel data got passed back to user
      mode in the register.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Acked-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <4AE5CC4D020000780001BD13@vpn.id2.novell.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      81766741
    • Jiri Slaby's avatar
      x86: crash_dump: Fix non-pae kdump kernel memory accesses · 72ed7de7
      Jiri Slaby authored
      Non-PAE 32-bit dump kernels may wrap an address around 4G and
      poke unwanted space. ptes there are 32-bit long, and since
      pfn << PAGE_SIZE may exceed this limit, high pfn bits are
      cropped and wrong address mapped by kmap_atomic_pfn in
      copy_oldmem_page.
      
      Don't allow this behavior in non-PAE kdump kernels by checking
      pfns passed into copy_oldmem_page. In the case of failure,
      userspace process gets EFAULT.
      
      [v2]
      - fix comments
      - move ifdefs inside the function
      Signed-off-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Paul Mundt <lethal@linux-sh.org>
      LKML-Reference: <1256551903-30567-1-git-send-email-jirislaby@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      72ed7de7
    • Rusty Russell's avatar
      x86: Side-step lguest problem by only building cmpxchg8b_emu for pre-Pentium · ae1b22f6
      Rusty Russell authored
      Commit 79e1dd05 "x86: Provide an alternative() based
      cmpxchg64()" broke lguest, even on systems which have cmpxchg8b
      support.  The emulation code gets used until alternatives get
      run, but it contains native instructions, not their paravirt
      alternatives.
      
      The simplest fix is to turn this code off except for 386 and 486
      builds.
      Reported-by: default avatarJohannes Stezenbach <js@sig21.net>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: lguest@ozlabs.org
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <200910261426.05769.rusty@rustcorp.com.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ae1b22f6
  17. 23 Oct, 2009 1 commit
  18. 21 Oct, 2009 1 commit
  19. 16 Oct, 2009 5 commits
    • Robin Holt's avatar
      x86, UV: Fix and clean up bau code to use uv_gpa_to_pnode() · 1d21e6e3
      Robin Holt authored
      Create an inline function to extract the pnode from a global
      physical address and then convert the broadcast assist unit to
      use the newly created uv_gpa_to_pnode function.
      
      The open-coded code was wrong as well - it might explain a
      few of our unexplained bau hangs.
      Signed-off-by: default avatarRobin Holt <holt@sgi.com>
      Acked-by: default avatarCliff Whickman <cpw@sgi.com>
      Cc: linux-mm@kvack.org
      Cc: Jack Steiner <steiner@sgi.com>
      LKML-Reference: <20091016112920.GZ8903@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1d21e6e3
    • Roland Dreier's avatar
      x86: Don't print number of MCE banks for every CPU · 93ae5012
      Roland Dreier authored
      The MCE initialization code explicitly says it doesn't handle
      asymmetric configurations where different CPUs support different
      numbers of MCE banks, and it prints a big warning in that case.
      
      Therefore, printing the "mce: CPU supports <x> MCE banks"
      message into the kernel log for every CPU is pure redundancy
      that clutters the log significantly for systems with lots of
      CPUs.
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      LKML-Reference: <adaeip473qt.fsf@cisco.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      93ae5012
    • Robin Holt's avatar
      x86, UV: Fix information in __uv_hub_info structure · 036ed8ba
      Robin Holt authored
      A few parts of the uv_hub_info structure are initialized
      incorrectly.
      
       - n_val is being loaded with m_val.
       - gpa_mask is initialized with a bytes instead of an unsigned long.
       - Handle the case where none of the alias registers are used.
      
      Lastly I converted the bau over to using the uv_hub_info->m_val
      which is the correct value.
      
      Without this patch, booting a large configuration hits a
      problem where the upper bits of the gnode affect the pnode
      and the bau will not operate.
      Signed-off-by: default avatarRobin Holt <holt@sgi.com>
      Acked-by: default avatarJack Steiner <steiner@sgi.com>
      Cc: Cliff Whickman <cpw@sgi.com>
      Cc: stable@kernel.org
      LKML-Reference: <20091015224946.396355000@alcatraz.americas.sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      036ed8ba
    • Ingo Molnar's avatar
      x86: Document linker script ASSERT() quirk · a5912f6b
      Ingo Molnar authored
      Older binutils breaks if ASSERT() is used without a sink
      for the output.
      
      For example 2.14.90.0.6 is known to be broken, the link
      fails with:
      
        LD      .tmp_vmlinux1
        ld:arch/x86/kernel/vmlinux.lds:678: parse error
      
      Document this quirk in all three files that use it.
      
        See:    http://marc.info/?l=linux-kbuild&m=124930110427870&w=2
        See[2]: d2ba8b21 ("x86: Fix assert syntax in vmlinux.lds.S")
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      LKML-Reference: <4AD6523D.5030909@zytor.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a5912f6b
    • Linus Torvalds's avatar
      Linux 2.6.32-rc5 · 012abeea
      Linus Torvalds authored
      012abeea
  20. 15 Oct, 2009 11 commits