1. 05 12月, 2008 2 次提交
  2. 04 12月, 2008 1 次提交
    • J
      x86: change thread_info's flag field back to 32 bits · affa219b
      Joe Korty 提交于
      Impact: pack struct thread_info more tightly
      
      Change x86_64's thread_info 'flags' field back to __u32.
      
      This was changed to 'unsigned long' when the thread_info*.h
      for i386 and x86_64 were merged.  Change it back.  We can
      do this as only 27 bits of 'flags' are actually used.
      
      This change actually packs down thread_info by 64 bits:
      32 bits are saved by the smaller flags, and 32 bits are
      saved by the following 'mm_segment_t field' becoming
      naturally 64-bit aligned.
      Signed-off-by: NJoe Korty <joe.korty@ccur.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      affa219b
  3. 01 12月, 2008 5 次提交
  4. 30 11月, 2008 1 次提交
  5. 27 11月, 2008 1 次提交
    • J
      x86: always define DECLARE_PCI_UNMAP* macros · b627c8b1
      Joerg Roedel 提交于
      Impact: fix boot crash on AMD IOMMU if CONFIG_GART_IOMMU is off
      
      Currently these macros evaluate to a no-op except the kernel is compiled
      with GART or Calgary support. But we also need these macros when we have
      SWIOTLB, VT-d or AMD IOMMU in the kernel. Since we always compile at
      least with SWIOTLB we can define these macros always.
      
      This patch is also for stable backport for the same reason the SWIOTLB
      default selection patch is.
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b627c8b1
  6. 26 11月, 2008 6 次提交
    • A
      x86: fixup config space size of CPU functions for AMD family 11h · ffd565a8
      Andreas Herrmann 提交于
      Impact: extend allowed configuration space access on 11h CPUs from 256 to 4K
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ffd565a8
    • A
      [CPUFREQ] powernow-k8: ignore out-of-range PstateStatus value · a266d9f1
      Andreas Herrmann 提交于
      A workaround for AMD CPU family 11h erratum 311 might cause that the
      P-state Status Register shows a "current P-state" which is larger than
      the "current P-state limit" in P-state Current Limit Register. For the
      wrong P-state value there is no ACPI _PSS object defined and
      powernow-k8/cpufreq can't determine the proper CPU frequency for that
      state.
      
      As a consequence this can cause a panic during boot (potentially with
      all recent kernel versions -- at least I have reproduced it with
      various 2.6.27 kernels and with the current .28 series), as an
      example:
      
      powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82 processors (2 \
      )
      powernow-k8:    0 : pstate 0 (2200 MHz)
      powernow-k8:    1 : pstate 1 (1100 MHz)
      powernow-k8:    2 : pstate 2 (600 MHz)
      BUG: unable to handle kernel paging request at ffff88086e7528b8
      IP: [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f
      PGD 202063 PUD 0
      Oops: 0002 [#1] SMP
      last sysfs file:
      CPU 1
      Modules linked in:
      Pid: 1, comm: swapper Not tainted 2.6.28-rc3-dirty #16
      RIP: 0010:[<ffffffff80486361>]  [<ffffffff80486361>] cpufreq_stats_update+0x4a/0\
      f
      Synaptics claims to have extended capabilities, but I'm not able to read them.<6\
      6
      RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88006e7528c0
      RDX: 00000000ffffffff RSI: ffff88006e54af00 RDI: ffffffff808f056c
      RBP: 00000000fffee697 R08: 0000000000000003 R09: ffff88006e73f080
      R10: 0000000000000001 R11: 00000000002191c0 R12: ffff88006fb83c10
      R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88006fb50740(0000) knlGS:0000000000000000
      Unable to initialize Synaptics hardware.
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: ffff88086e7528b8 CR3: 0000000000201000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 1, threadinfo ffff88006fb82000, task ffff88006fb816d0)
      Stack:
       ffff88006e74da50 0000000000000000 ffff88006e54af00 ffffffff804863c7
       ffff88006e74da50 0000000000000000 00000000ffffffff 0000000000000000
       ffff88006fb83c10 ffffffff8024b46c ffffffff808f0560 ffff88006fb83c10
      Call Trace:
       [<ffffffff804863c7>] ? cpufreq_stat_notifier_trans+0x51/0x83
       [<ffffffff8024b46c>] ? notifier_call_chain+0x29/0x4c
       [<ffffffff8024b561>] ? __srcu_notifier_call_chain+0x46/0x61
       [<ffffffff8048496d>] ? cpufreq_notify_transition+0x93/0xa9
       [<ffffffff8021ab8d>] ? powernowk8_target+0x1e8/0x5f3
       [<ffffffff80486687>] ? cpufreq_governor_performance+0x1b/0x20
       [<ffffffff80484886>] ? __cpufreq_governor+0x71/0xa8
       [<ffffffff80484b21>] ? __cpufreq_set_policy+0x101/0x13e
       [<ffffffff80485bcd>] ? cpufreq_add_dev+0x3f0/0x4cd
       [<ffffffff8048577a>] ? handle_update+0x0/0x8
       [<ffffffff803c2062>] ? sysdev_driver_register+0xb6/0x10d
       [<ffffffff8056592c>] ? powernowk8_init+0x0/0x7e
       [<ffffffff8048604c>] ? cpufreq_register_driver+0x8f/0x140
       [<ffffffff80209056>] ? _stext+0x56/0x14f
       [<ffffffff802c2234>] ? proc_register+0x122/0x17d
       [<ffffffff802c23a0>] ? create_proc_entry+0x73/0x8a
       [<ffffffff8025c259>] ? register_irq_proc+0x92/0xaa
       [<ffffffff8025c2c8>] ? init_irq_proc+0x57/0x69
       [<ffffffff807fc85f>] ? kernel_init+0x116/0x169
       [<ffffffff8020cc79>] ? child_rip+0xa/0x11
       [<ffffffff807fc749>] ? kernel_init+0x0/0x169
       [<ffffffff8020cc6f>] ? child_rip+0x0/0x11
      Code: 05 c5 83 36 00 48 c7 c2 48 5d 86 80 48 8b 04 d8 48 8b 40 08 48 8b 34 02 48\
      
      RIP  [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f
       RSP <ffff88006fb83b20>
      CR2: ffff88086e7528b8
      ---[ end trace 0678bac75e67a2f7 ]---
      Kernel panic - not syncing: Attempted to kill init!
      
      In short, aftereffect of the wrong P-state is that
      cpufreq_stats_update() uses "-1" as index for some array in
      
      cpufreq_stats_update (unsigned int cpu)
      {
      ...
           if (stat->time_in_state)
                      stat->time_in_state[stat->last_index] =
                              cputime64_add(stat->time_in_state[stat->last_index],
                                            cputime_sub(cur_time, stat->last_time));
      ...
      }
      
      Fortunately, the wrong P-state value is returned only if the core is
      in P-state 0. This fix solves the problem by detecting the
      out-of-range P-state, ignoring it, and using "0" instead.
      
      Cc: Mark Langsdorf <mark.langsdorf@amd.com>
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      a266d9f1
    • M
      x86, bts: fix wrmsr and spinlock over kmalloc · de90add3
      Markus Metzger 提交于
      Impact: fix sleeping-with-spinlock-held bugs/crashes
      
      - Turn a wrmsr to write the DS_AREA MSR into a wrmsrl.
      - Use irqsave variants of spinlocks.
      - Do not allocate memory while holding spinlocks.
      Reported-by: NStephane Eranian <eranian@googlemail.com>
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      de90add3
    • M
      x86, pebs: fix PEBS record size configuration · c4858ffc
      Markus Metzger 提交于
      Impact: fix DS hw enablement on 64-bit x86
      
      Fix the PEBS record size in the DS configuration.
      Reported-by: NStephane Eranian <eranian@googlemail.com>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c4858ffc
    • M
      x86, bts: turn macro into static inline function · e5e8ca63
      Markus Metzger 提交于
      Impact: cleanup
      
      Replace a macro with a static inline function.
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e5e8ca63
    • M
      x86, bts: exclude ds.c from build when disabled · 292c669c
      Markus Metzger 提交于
      Impact: cleanup
      
      Move the CONFIG guard from the .c file into the makefile.
      Reported-by: NAndi Kleen <andi-suse@firstfloor.org>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      292c669c
  7. 25 11月, 2008 2 次提交
  8. 23 11月, 2008 2 次提交
    • I
      xen: pin correct PGD on suspend · 86bbc2c2
      Ian Campbell 提交于
      Impact: fix Xen guest boot failure
      
      commit eefb47f6 ("xen: use
      spin_lock_nest_lock when pinning a pagetable") changed xen_pgd_walk to
      walk over mm->pgd rather than taking pgd as an argument.
      
      This breaks xen_mm_(un)pin_all() because it makes init_mm.pgd readonly
      instead of the pgd we are interested in and therefore the pin subsequently
      fails.
      
      (XEN) mm.c:2280:d15 Bad type (saw 00000000e8000001 != exp 0000000060000000) for mfn bc464 (pfn 21ca7)
      (XEN) mm.c:2665:d15 Error while pinning mfn bc464
      
      [   14.586913] 1 multicall(s) failed: cpu 0
      [   14.586926] Pid: 14, comm: kstop/0 Not tainted 2.6.28-rc5-x86_32p-xenU-00172-gee2f6cc7 #200
      [   14.586940] Call Trace:
      [   14.586955]  [<c030c17a>] ? printk+0x18/0x1e
      [   14.586972]  [<c0103df3>] xen_mc_flush+0x163/0x1d0
      [   14.586986]  [<c0104bc1>] __xen_pgd_pin+0xa1/0x110
      [   14.587000]  [<c015a330>] ? stop_cpu+0x0/0xf0
      [   14.587015]  [<c0104d7b>] xen_mm_pin_all+0x4b/0x70
      [   14.587029]  [<c022bcb9>] xen_suspend+0x39/0xe0
      [   14.587042]  [<c015a330>] ? stop_cpu+0x0/0xf0
      [   14.587054]  [<c015a3cd>] stop_cpu+0x9d/0xf0
      [   14.587067]  [<c01417cd>] run_workqueue+0x8d/0x150
      [   14.587080]  [<c030e4b3>] ? _spin_unlock_irqrestore+0x23/0x40
      [   14.587094]  [<c014558a>] ? prepare_to_wait+0x3a/0x70
      [   14.587107]  [<c0141918>] worker_thread+0x88/0xf0
      [   14.587120]  [<c01453c0>] ? autoremove_wake_function+0x0/0x50
      [   14.587133]  [<c0141890>] ? worker_thread+0x0/0xf0
      [   14.587146]  [<c014509c>] kthread+0x3c/0x70
      [   14.587157]  [<c0145060>] ? kthread+0x0/0x70
      [   14.587170]  [<c0109d1b>] kernel_thread_helper+0x7/0x10
      [   14.587181]   call  1/3: op=14 arg=[c0415000] result=0
      [   14.587192]   call  2/3: op=14 arg=[e1ca2000] result=0
      [   14.587204]   call  3/3: op=26 arg=[c1808860] result=-22
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      86bbc2c2
    • T
      x86: revert irq number limitation · a1967d64
      Thomas Gleixner 提交于
      Impact: fix MSIx not enough irq numbers available regression
      
      The manual revert of the sparse_irq patches missed to bring the number
      of possible irqs back to the .27 status. This resulted in a regression
      when two multichannel network cards were placed in a system with only
      one IO_APIC - causing the networking driver to not have the right
      IRQ and the device not coming up.
      
      Remove the dynamic allocation logic leftovers and simply return
      NR_IRQS in probe_nr_irqs() for now.
      
         Fixes: http://lkml.org/lkml/2008/11/19/354Reported-by: NJesper Dangaard Brouer <hawk@diku.dk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJesper Dangaard Brouer <hawk@diku.dk>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a1967d64
  9. 21 11月, 2008 1 次提交
    • M
      x86: Fix interrupt leak due to migration · 0ca4b6b0
      Matthew Wilcox 提交于
      When we migrate an interrupt from one CPU to another, we set the
      move_in_progress flag and clean up the vectors later once they're not
      being used.  If you're unlucky and call destroy_irq() before the vectors
      become un-used, the move_in_progress flag is never cleared, which causes
      the interrupt to become unusable.
      
      This was discovered by Jesse Brandeburg for whom it manifested as an
      MSI-X device refusing to use MSI-X mode when the driver was unloaded
      and reloaded repeatedly.
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ca4b6b0
  10. 20 11月, 2008 3 次提交
    • R
      x86: fixing __cpuinit/__init tangle, xsave_cntxt_init() · bfe085f6
      Rakib Mullick 提交于
      Annotate xsave_cntxt_init() as "can be called outside of __init".
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bfe085f6
    • R
      x86: fix __cpuinit/__init tangle in init_thread_xstate() · 9bc646f1
      Rakib Mullick 提交于
      Impact:	fix incorrect __init annotation
      
      This patch removes the following section mismatch warning. A patch set
      was send previously (http://lkml.org/lkml/2008/11/10/407). But
      introduce some other problem, reported by Rufus
      (http://lkml.org/lkml/2008/11/11/46). Then Ingo Molnar suggest that,
      it's best to remove __init from xsave_cntxt_init(void). Which is the
      second patch in this series. Now, this one removes the following
      warning.
      
      WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x2237): Section
      mismatch in reference from the function cpu_init() to the function
      .init.text:init_thread_xstate()
      The function __cpuinit cpu_init() references
      a function __init init_thread_xstate().
      If init_thread_xstate is only used by cpu_init then
      annotate init_thread_xstate with a matching annotation.
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9bc646f1
    • U
      reintroduce accept4 · de11defe
      Ulrich Drepper 提交于
      Introduce a new accept4() system call.  The addition of this system call
      matches analogous changes in 2.6.27 (dup3(), evenfd2(), signalfd4(),
      inotify_init1(), epoll_create1(), pipe2()) which added new system calls
      that differed from analogous traditional system calls in adding a flags
      argument that can be used to access additional functionality.
      
      The accept4() system call is exactly the same as accept(), except that
      it adds a flags bit-mask argument.  Two flags are initially implemented.
      (Most of the new system calls in 2.6.27 also had both of these flags.)
      
      SOCK_CLOEXEC causes the close-on-exec (FD_CLOEXEC) flag to be enabled
      for the new file descriptor returned by accept4().  This is a useful
      security feature to avoid leaking information in a multithreaded
      program where one thread is doing an accept() at the same time as
      another thread is doing a fork() plus exec().  More details here:
      http://udrepper.livejournal.com/20407.html "Secure File Descriptor Handling",
      Ulrich Drepper).
      
      The other flag is SOCK_NONBLOCK, which causes the O_NONBLOCK flag
      to be enabled on the new open file description created by accept4().
      (This flag is merely a convenience, saving the use of additional calls
      fcntl(F_GETFL) and fcntl (F_SETFL) to achieve the same result.
      
      Here's a test program.  Works on x86-32.  Should work on x86-64, but
      I (mtk) don't have a system to hand to test with.
      
      It tests accept4() with each of the four possible combinations of
      SOCK_CLOEXEC and SOCK_NONBLOCK set/clear in 'flags', and verifies
      that the appropriate flags are set on the file descriptor/open file
      description returned by accept4().
      
      I tested Ulrich's patch in this thread by applying against 2.6.28-rc2,
      and it passes according to my test program.
      
      /* test_accept4.c
      
        Copyright (C) 2008, Linux Foundation, written by Michael Kerrisk
             <mtk.manpages@gmail.com>
      
        Licensed under the GNU GPLv2 or later.
      */
      #define _GNU_SOURCE
      #include <unistd.h>
      #include <sys/syscall.h>
      #include <sys/socket.h>
      #include <netinet/in.h>
      #include <stdlib.h>
      #include <fcntl.h>
      #include <stdio.h>
      #include <string.h>
      
      #define PORT_NUM 33333
      
      #define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
      
      /**********************************************************************/
      
      /* The following is what we need until glibc gets a wrapper for
        accept4() */
      
      /* Flags for socket(), socketpair(), accept4() */
      #ifndef SOCK_CLOEXEC
      #define SOCK_CLOEXEC    O_CLOEXEC
      #endif
      #ifndef SOCK_NONBLOCK
      #define SOCK_NONBLOCK   O_NONBLOCK
      #endif
      
      #ifdef __x86_64__
      #define SYS_accept4 288
      #elif __i386__
      #define USE_SOCKETCALL 1
      #define SYS_ACCEPT4 18
      #else
      #error "Sorry -- don't know the syscall # on this architecture"
      #endif
      
      static int
      accept4(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, int flags)
      {
         printf("Calling accept4(): flags = %x", flags);
         if (flags != 0) {
             printf(" (");
             if (flags & SOCK_CLOEXEC)
                 printf("SOCK_CLOEXEC");
             if ((flags & SOCK_CLOEXEC) && (flags & SOCK_NONBLOCK))
                 printf(" ");
             if (flags & SOCK_NONBLOCK)
                 printf("SOCK_NONBLOCK");
             printf(")");
         }
         printf("\n");
      
      #if USE_SOCKETCALL
         long args[6];
      
         args[0] = fd;
         args[1] = (long) sockaddr;
         args[2] = (long) addrlen;
         args[3] = flags;
      
         return syscall(SYS_socketcall, SYS_ACCEPT4, args);
      #else
         return syscall(SYS_accept4, fd, sockaddr, addrlen, flags);
      #endif
      }
      
      /**********************************************************************/
      
      static int
      do_test(int lfd, struct sockaddr_in *conn_addr,
             int closeonexec_flag, int nonblock_flag)
      {
         int connfd, acceptfd;
         int fdf, flf, fdf_pass, flf_pass;
         struct sockaddr_in claddr;
         socklen_t addrlen;
      
         printf("=======================================\n");
      
         connfd = socket(AF_INET, SOCK_STREAM, 0);
         if (connfd == -1)
             die("socket");
         if (connect(connfd, (struct sockaddr *) conn_addr,
                     sizeof(struct sockaddr_in)) == -1)
             die("connect");
      
         addrlen = sizeof(struct sockaddr_in);
         acceptfd = accept4(lfd, (struct sockaddr *) &claddr, &addrlen,
                            closeonexec_flag | nonblock_flag);
         if (acceptfd == -1) {
             perror("accept4()");
             close(connfd);
             return 0;
         }
      
         fdf = fcntl(acceptfd, F_GETFD);
         if (fdf == -1)
             die("fcntl:F_GETFD");
         fdf_pass = ((fdf & FD_CLOEXEC) != 0) ==
                    ((closeonexec_flag & SOCK_CLOEXEC) != 0);
         printf("Close-on-exec flag is %sset (%s); ",
                 (fdf & FD_CLOEXEC) ? "" : "not ",
                 fdf_pass ? "OK" : "failed");
      
         flf = fcntl(acceptfd, F_GETFL);
         if (flf == -1)
             die("fcntl:F_GETFD");
         flf_pass = ((flf & O_NONBLOCK) != 0) ==
                    ((nonblock_flag & SOCK_NONBLOCK) !=0);
         printf("nonblock flag is %sset (%s)\n",
                 (flf & O_NONBLOCK) ? "" : "not ",
                 flf_pass ? "OK" : "failed");
      
         close(acceptfd);
         close(connfd);
      
         printf("Test result: %s\n", (fdf_pass && flf_pass) ? "PASS" : "FAIL");
         return fdf_pass && flf_pass;
      }
      
      static int
      create_listening_socket(int port_num)
      {
         struct sockaddr_in svaddr;
         int lfd;
         int optval;
      
         memset(&svaddr, 0, sizeof(struct sockaddr_in));
         svaddr.sin_family = AF_INET;
         svaddr.sin_addr.s_addr = htonl(INADDR_ANY);
         svaddr.sin_port = htons(port_num);
      
         lfd = socket(AF_INET, SOCK_STREAM, 0);
         if (lfd == -1)
             die("socket");
      
         optval = 1;
         if (setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &optval,
                        sizeof(optval)) == -1)
             die("setsockopt");
      
         if (bind(lfd, (struct sockaddr *) &svaddr,
                  sizeof(struct sockaddr_in)) == -1)
             die("bind");
      
         if (listen(lfd, 5) == -1)
             die("listen");
      
         return lfd;
      }
      
      int
      main(int argc, char *argv[])
      {
         struct sockaddr_in conn_addr;
         int lfd;
         int port_num;
         int passed;
      
         passed = 1;
      
         port_num = (argc > 1) ? atoi(argv[1]) : PORT_NUM;
      
         memset(&conn_addr, 0, sizeof(struct sockaddr_in));
         conn_addr.sin_family = AF_INET;
         conn_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
         conn_addr.sin_port = htons(port_num);
      
         lfd = create_listening_socket(port_num);
      
         if (!do_test(lfd, &conn_addr, 0, 0))
             passed = 0;
         if (!do_test(lfd, &conn_addr, SOCK_CLOEXEC, 0))
             passed = 0;
         if (!do_test(lfd, &conn_addr, 0, SOCK_NONBLOCK))
             passed = 0;
         if (!do_test(lfd, &conn_addr, SOCK_CLOEXEC, SOCK_NONBLOCK))
             passed = 0;
      
         close(lfd);
      
         exit(passed ? EXIT_SUCCESS : EXIT_FAILURE);
      }
      
      [mtk.manpages@gmail.com: rewrote changelog, updated test program]
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Tested-by: NMichael Kerrisk <mtk.manpages@gmail.com>
      Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
      Cc: <linux-api@vger.kernel.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      de11defe
  11. 19 11月, 2008 2 次提交
  12. 18 11月, 2008 8 次提交
  13. 17 11月, 2008 1 次提交
  14. 16 11月, 2008 3 次提交
    • Y
      x86: fix es7000 compiling · d3c6aa1e
      Yinghai Lu 提交于
      Impact: fix es7000 build
      
        CC      arch/x86/kernel/es7000_32.o
      arch/x86/kernel/es7000_32.c: In function find_unisys_acpi_oem_table:
      arch/x86/kernel/es7000_32.c:255: error: implicit declaration of function acpi_get_table_with_size
      arch/x86/kernel/es7000_32.c:261: error: implicit declaration of function early_acpi_os_unmap_memory
      arch/x86/kernel/es7000_32.c: In function unmap_unisys_acpi_oem_table:
      arch/x86/kernel/es7000_32.c:277: error: implicit declaration of function __acpi_unmap_table
      make[1]: *** [arch/x86/kernel/es7000_32.o] Error 1
      
      we applied one patch out of order...
      
      | commit a73aaedd
      | Author: Yinghai Lu <yhlu.kernel@gmail.com>
      | Date:   Sun Sep 14 02:33:14 2008 -0700
      |
      |    x86: check dsdt before find oem table for es7000, v2
      |
      |    v2: use __acpi_unmap_table()
      
      that patch need:
      
      	x86: use early_ioremap in __acpi_map_table
      	x86: always explicitly map acpi memory
      	acpi: remove final __acpi_map_table mapping before setting acpi_gbl_permanent_mmap
      	acpi/x86: introduce __apci_map_table, v4
      
      submitted to the ACPI tree but not upstream yet.
      
      fix it until those patches applied, need to revert this one
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3c6aa1e
    • M
      x86, bts: fix unlock problem in ds.c · d1f1e9c0
      Markus Metzger 提交于
      Fix a problem where ds_request() returned an error without releasing the
      ds lock.
      Reported-by: NStephane Eranian <eranian@gmail.com>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d1f1e9c0
    • D
      Revert "x86: blacklist DMAR on Intel G31/G33 chipsets" · 52168e60
      David Woodhouse 提交于
      This reverts commit e51af663, which was
      wrongly hoovered up and submitted about a month after a better fix had
      already been merged.
      
      The better fix is commit cbda1ba8
      ("PCI/iommu: blacklist DMAR on Intel G31/G33 chipsets"), where we do
      this blacklisting based on the DMI identification for the offending
      motherboard, since sometimes this chipset (or at least a chipset with
      the same PCI ID) apparently _does_ actually have an IOMMU.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52168e60
  15. 13 11月, 2008 2 次提交
    • R
      x86: make NUMA on 32-bit depend on EXPERIMENTAL again · 604d2055
      Rafael J. Wysocki 提交于
      My previous patch to make CONFIG_NUMA on x86_32 depend on BROKEN
      turned out to be unnecessary, after all, since the source of the
      hibernation vs CONFIG_NUMA problem turned out to be the fact that
      we didn't take the NUMA KVA remapping into account in the
      hibernation code.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      604d2055
    • R
      x86, hibernate: fix breakage on x86_32 with CONFIG_NUMA set · 97a70e54
      Rafael J. Wysocki 提交于
      Impact: fix crash during hibernation on 32-bit NUMA
      
      The NUMA code on x86_32 creates special memory mapping that allows
      each node's pgdat to be located in this node's memory.  For this
      purpose it allocates a memory area at the end of each node's memory
      and maps this area so that it is accessible with virtual addresses
      belonging to low memory.  As a result, if there is high memory,
      these NUMA-allocated areas are physically located in high memory,
      although they are mapped to low memory addresses.
      
      Our hibernation code does not take that into account and for this
      reason hibernation fails on all x86_32 systems with CONFIG_NUMA=y and
      with high memory present.  Fix this by adding a special mapping for
      the NUMA-allocated memory areas to the temporary page tables created
      during the last phase of resume.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      97a70e54