1. 06 Jan, 2010 1 commit
  2. 31 Dec, 2009 1 commit
    • Frederic Weisbecker's avatar
      perf: Pass appropriate frame pointer to dump_trace() · 48b5ba9c
      Frederic Weisbecker authored
      
      Pass the frame pointer from the regs of the interrupted path
      to dump_trace() while processing the stack trace.
      
      Currently, dump_trace() takes the current bp and starts the
      callchain from dump_trace() itself. This is wasteful because
      we need to walk through the entire NMI/DEBUG stack before
      retrieving the interrupted point.
      
      We can fix that by just using the frame pointer from the
      captured regs. It points exactly where we want to start.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1262235183-5320-1-git-send-regression-fweisbec@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      48b5ba9c
  3. 30 Dec, 2009 2 commits
  4. 29 Dec, 2009 1 commit
    • Mike Travis's avatar
      x86: SGI UV: Fix writes to led registers on remote uv hubs · 39d30770
      Mike Travis authored
      
      The wrong address was being used to write the SCIR led regs on
      remote hubs.  Also, there was an inconsistency between how BIOS
      and the kernel indexed these regs.  Standardize on using the
      lower 6 bits of the APIC ID as the index.
      
      This patch fixes the problem of writing to an errant address to
      a cpu # >= 64.
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Reviewed-by: default avatarJack Steiner <steiner@sgi.com>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: stable@kernel.org
      LKML-Reference: <4B3922F9.3060905@sgi.com>
      [ v2: fix a number of annoying checkpatch artifacts and whitespace noise ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      39d30770
  5. 28 Dec, 2009 1 commit
    • Pekka Enberg's avatar
      x86: Use KERN_DEFAULT log-level in __show_regs() · d015a092
      Pekka Enberg authored
      
      Andrew Morton reported a strange looking kmemcheck warning:
      
        WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88004fba6c20)
        0000000000000000310000000000000000000000000000002413000000c9ffff
         u u u u u u u u u u u u u u u u i i i i i i i i u u u u u u u u
      
         [<ffffffff810af3aa>] kmemleak_scan+0x25a/0x540
         [<ffffffff810afbcb>] kmemleak_scan_thread+0x5b/0xe0
         [<ffffffff8104d0fe>] kthread+0x9e/0xb0
         [<ffffffff81003074>] kernel_thread_helper+0x4/0x10
         [<ffffffffffffffff>] 0xffffffffffffffff
      
      The above printout is missing register dump completely. The
      problem here is that the output comes from syslog which doesn't
      show KERN_INFO log-level messages. We didn't see this before
      because both of us were testing on 32-bit kernels which use the
      _default_ log-level.
      
      Fix that up by explicitly using KERN_DEFAULT log-level for
      __show_regs() printks.
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <1261988819.4641.2.camel@penberg-laptop>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d015a092
  6. 23 Dec, 2009 1 commit
    • Linus Torvalds's avatar
      Revert "x86, ucode-amd: Ensure ucode update on suspend/resume after CPU off/online cycle" · 2f99f5c8
      Linus Torvalds authored
      This reverts commit 9f15226e.  It's just
      wrong, and broke resume for Rafael even on a non-AMD CPU.
      
      As Rafael says:
       "... it causes microcode_init_cpu() to be called during resume even for
        CPUs for which there's no microcode to apply.  That, in turn, results
        in executing request_firmware() (on Intel CPUs at least) which doesn't
        work at this stage of resume (we have device interrupts disabled, I/O
        devices are still suspended and so on).
      
        If I'm not mistaken, the "if (uci->valid)" logic means "if that CPU is
        known to us" , so before commit 9f15226e
      
       microcode_resume_cpu() was
        called for all CPUs already in the system during suspend, which was
        the right thing to do.  The commit changed it so that the CPUs without
        microcode to apply are now treated as "unknown", which is not quite
        right.
      
        The problem this commit attempted to solve has to be handled
        differently."
      
      Bisected-and -requested-by: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f99f5c8
  7. 22 Dec, 2009 6 commits
    • Andrew Morton's avatar
      arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by... · 4a28395d
      Andrew Morton authored
      arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by using smp_call_function_any()
      
      Presently acpi-cpufreq will perform the MSR read on the first CPU in the
      mask.  That's inefficient if that CPU differs from the current CPU.
      Because we have to perform a cross-CPU call, but we could have run the
      rdmsr on the current CPU.
      
      So switch to using the new smp_call_function_any(), which will perform the
      call on the current CPU if that CPU is present in the mask (it is).
      
      Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Zhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      4a28395d
    • Alex Chiang's avatar
      ACPI: processor: unify arch_acpi_processor_cleanup_pdc · 47817254
      Alex Chiang authored
      
      The x86 and ia64 implementations of the function in $subject are
      exactly the same.
      
      Also, since the arch-specific implementations of setting _PDC have
      been completely hollowed out, remove the empty shells.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      47817254
    • Alex Chiang's avatar
      ACPI: processor: finish unifying arch_acpi_processor_init_pdc() · 6c5807d7
      Alex Chiang authored
      
      The only thing arch-specific about calling _PDC is what bits get
      set in the input obj_list buffer.
      
      There's no need for several levels of indirection to twiddle those
      bits. Additionally, since we're just messing around with a buffer,
      we can simplify the interface; no need to pass around the entire
      struct acpi_processor * just to get at the buffer.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      6c5807d7
    • Alex Chiang's avatar
      ACPI: processor: factor out common _PDC settings · 08ea48a3
      Alex Chiang authored
      
      Both x86 and ia64 initialize _PDC with mostly common bit settings.
      
      Factor out the common settings and leave the arch-specific ones alone.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      08ea48a3
    • Alex Chiang's avatar
      ACPI: processor: unify arch_acpi_processor_init_pdc · 407cd87c
      Alex Chiang authored
      
      The x86 and ia64 implementations of arch_acpi_processor_init_pdc()
      are almost exactly the same. The only difference is in what bits
      they set in obj_list buffer.
      
      Combine the boilerplate memory management code, and leave the
      arch-specific bit twiddling in separate implementations.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      407cd87c
    • Alex Chiang's avatar
      ACPI: processor: introduce arch_has_acpi_pdc · 1d9cb470
      Alex Chiang authored
      
      arch dependent helper function that tells us if we should attempt to
      evaluate _PDC on this machine or not.
      
      The x86 implementation assumes that the CPUs in the machine must be
      homogeneous, and that you cannot mix CPUs of different vendors.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      1d9cb470
  8. 21 Dec, 2009 1 commit
    • Joerg Roedel's avatar
      x86/amd-iommu: Fix initialization failure panic · 0f764806
      Joerg Roedel authored
      
      The assumption that acpi_table_parse passes the return value
      of the hanlder function to the caller proved wrong
      recently. The return value of the handler function is
      totally ignored. This makes the initialization code for AMD
      IOMMU buggy in a way that could cause a kernel panic on
      initialization. This patch fixes the issue in the AMD IOMMU
      driver.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarJoerg Roedel <joerg.roedel@amd.com>
      0f764806
  9. 18 Dec, 2009 1 commit
    • Suresh Siddha's avatar
      x86, irq: Allow 0xff for /proc/irq/[n]/smp_affinity on an 8-cpu system · 18374d89
      Suresh Siddha authored
      
      John Blackwood reported:
      > on an older Dell PowerEdge 6650 system with 8 cpus (4 are hyper-threaded),
      > and  32 bit (x86) kernel, once you change the irq smp_affinity of an irq
      > to be less than all cpus in the system, you can never change really the
      > irq smp_affinity back to be all cpus in the system (0xff) again,
      > even though no error status is returned on the "/bin/echo ff >
      > /proc/irq/[n]/smp_affinity" operation.
      >
      > This is due to that fact that BAD_APICID has the same value as
      > all cpus (0xff) on 32bit kernels, and thus the value returned from
      > set_desc_affinity() via the cpu_mask_to_apicid_and() function is treated
      > as a failure in set_ioapic_affinity_irq_desc(), and no affinity changes
      > are made.
      
      set_desc_affinity() is already checking if the incoming cpu mask
      intersects with the cpu online mask or not. So there is no need
      for the apic op cpu_mask_to_apicid_and() to check again
      and return BAD_APICID.
      
      Remove the BAD_APICID return value from cpu_mask_to_apicid_and()
      and also fix set_desc_affinity() to return -1 instead of using BAD_APICID
      to represent error conditions (as cpu_mask_to_apicid_and() can return
      logical or physical apicid values and BAD_APICID is really to represent
      bad physical apic id).
      Reported-by: default avatarJohn Blackwood <john.blackwood@ccur.com>
      Root-caused-by: default avatarJohn Blackwood <john.blackwood@ccur.com>
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1261103386.2535.409.camel@sbs-t61>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      18374d89
  10. 17 Dec, 2009 4 commits
    • Pallipadi, Venkatesh's avatar
      x86: Reenable TSC sync check at boot, even with NONSTOP_TSC · 6c56ccec
      Pallipadi, Venkatesh authored
      Commit 83ce4009 did the following change
      If the TSC is constant and non-stop, also set it reliable.
      
      But, there seems to be few systems that will end up with TSC warp across
      sockets, depending on how the cpus come out of reset. Skipping TSC sync
      test on such systems may result in time inconsistency later.
      
      So, reenable TSC sync test even on constant and non-stop TSC systems.
      Set, sched_clock_stable to 1 by default and reset it in
      mark_tsc_unstable, if TSC sync fails.
      
      This change still gives perf benefit mentioned in 83ce4009
      
       for systems
      where TSC is reliable.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <20091217202702.GA18015@linux-os.sc.intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6c56ccec
    • Linus Torvalds's avatar
      x86/ptrace: make genregs[32]_get/set more robust · 04a1e62c
      Linus Torvalds authored
      
      The loop condition is fragile: we compare an unsigned value to zero, and
      then decrement it by something larger than one in the loop.  All the
      callers should be passing in appropriately aligned buffer lengths, but
      it's better to just not rely on it, and have some appropriate defensive
      loop limits.
      Acked-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      04a1e62c
    • Frederic Weisbecker's avatar
      perf events, x86/stacktrace: Fix performance/softlockup by providing a special... · 06d65bda
      Frederic Weisbecker authored
      perf events, x86/stacktrace: Fix performance/softlockup by providing a special frame pointer-only stack walker
      
      It's just wasteful for stacktrace users like perf to walk
      through every entries on the stack whereas these only accept
      reliable ones, ie: that the frame pointer validates.
      
      Since perf requires pure reliable stacktraces, it needs a stack
      walker based on frame pointers-only to optimize the stacktrace
      processing.
      
      This might solve some near-lockup scenarios that can be triggered
      by call-graph tracing timer events.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1261024834-5336-2-git-send-regression-fweisbec@gmail.com>
      [ v2: fix for modular builds and small detail tidyup ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      06d65bda
    • Frederic Weisbecker's avatar
      perf events, x86/stacktrace: Make stack walking optional · 61c1917f
      Frederic Weisbecker authored
      
      The current print_context_stack helper that does the stack
      walking job is good for usual stacktraces as it walks through
      all the stack and reports even addresses that look unreliable,
      which is nice when we don't have frame pointers for example.
      
      But we have users like perf that only require reliable
      stacktraces, and those may want a more adapted stack walker, so
      lets make this function a callback in stacktrace_ops that users
      can tune for their needs.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1261024834-5336-1-git-send-regression-fweisbec@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      61c1917f
  11. 16 Dec, 2009 7 commits
  12. 15 Dec, 2009 7 commits
    • H. Peter Anvin's avatar
      x86, msr/cpuid: Register enough minors for the MSR and CPUID drivers · 0b962d47
      H. Peter Anvin authored
      
      register_chrdev() hardcodes registering 256 minors, presumably to
      avoid breaking old drivers.  However, we need to register enough
      minors so that we have all possible CPUs.
      
      checkpatch warns on this patch, but the patch is correct: NR_CPUS here
      is a static *upper bound* on the *maximum CPU index* (not *number of
      CPUs!*) and that is what we want.
      Reported-and-tested-by: default avatarRuss Anderson <rja@sgi.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <tip-*@git.kernel.org>
      0b962d47
    • André Goddard Rosa's avatar
      tree-wide: convert open calls to remove spaces to skip_spaces() lib function · e7d2860b
      André Goddard Rosa authored
      Makes use of skip_spaces() defined in lib/string.c for removing leading
      spaces from strings all over the tree.
      
      It decreases lib.a code size by 47 bytes and reuses the function tree-wide:
         text    data     bss     dec     hex filename
        64688     584     592   65864   10148 (TOTALS-BEFORE)
        64641     584     592   65817   10119 (TOTALS-AFTER)
      
      Also, while at it, if we see (*str && isspace(*str)), we can be sure to
      remove the first condition (*str) as the second one (isspace(*str)) also
      evaluates to 0 whenever *str == 0, making it redundant. In other words,
      "a char equals zero is never a space".
      
      Julia Lawall tried the semantic patch (http://coccinelle.lip6.fr
      
      ) below,
      and found occurrences of this pattern on 3 more files:
          drivers/leds/led-class.c
          drivers/leds/ledtrig-timer.c
          drivers/video/output.c
      
      @@
      expression str;
      @@
      
      ( // ignore skip_spaces cases
      while (*str &&  isspace(*str)) { \(str++;\|++str;\) }
      |
      - *str &&
      isspace(*str)
      )
      Signed-off-by: default avatarAndré Goddard Rosa <andre.goddard@gmail.com>
      Cc: Julia Lawall <julia@diku.dk>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: David Howells <dhowells@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Samuel Ortiz <samuel@sortiz.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e7d2860b
    • Andres Salomon's avatar
      cs5535: drop the Geode-specific MFGPT/GPIO code · c95d1e53
      Andres Salomon authored
      
      With generic modular drivers handling all of this stuff, the
      geode-specific code can go away.  The cs5535-gpio, cs5535-mfgpt, and
      cs5535-clockevt drivers now handle this.
      Signed-off-by: default avatarAndres Salomon <dilinger@collabora.co.uk>
      Cc: Jordan Crouse <jordan@cosmicpenguin.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Chris Ball <cjb@laptop.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c95d1e53
    • Andres Salomon's avatar
      cs5535: move VSA2 checks into linux/cs5535.h · f060f270
      Andres Salomon authored
      Signed-off-by: default avatarAndres Salomon <dilinger@collabora.co.uk>
      Cc: Jordan Crouse <jordan@cosmicpenguin.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Chris Ball <cjb@laptop.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f060f270
    • Andres Salomon's avatar
      cs5535: move the DIVIL MSR definition into linux/cs5535.h · 2e8c1243
      Andres Salomon authored
      
      The only thing that uses this is the reboot_fixups code.
      Signed-off-by: default avatarAndres Salomon <dilinger@collabora.co.uk>
      Cc: Jordan Crouse <jordan@cosmicpenguin.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Chris Ball <cjb@laptop.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2e8c1243
    • FUJITA Tomonori's avatar
      x86: Split swiotlb initialization into two stages · 186a2502
      FUJITA Tomonori authored
      The commit f4780ca0 moves
      swiotlb initialization before dma32_free_bootmem(). It's
      supposed to fix a bug that the commit
      75f1cdf1
      
       introduced, we
      initialize SWIOTLB right after dma32_free_bootmem so we wrongly
      steal memory area allocated for GART with broken BIOS earlier.
      
      However, the above commit introduced another problem, which
      likely breaks machines with huge amount of memory. Such a box
      use the majority of DMA32_ZONE so there is no memory for
      swiotlb.
      
      With this patch, the x86 IOMMU initialization sequence are:
      
      1. We set swiotlb to 1 in the case of (max_pfn > MAX_DMA32_PFN
         && !no_iommu). If swiotlb usage is forced by the boot option,
         we go to the step 3 and finish (we don't try to detect IOMMUs).
      
      2. We call the detection functions of all the IOMMUs. The
         detection function sets x86_init.iommu.iommu_init to the IOMMU
         initialization function (so we can avoid calling the
         initialization functions of all the IOMMUs needlessly).
      
      3. We initialize swiotlb (and set dma_ops to swiotlb_dma_ops) if
         swiotlb is set to 1.
      
      4. If the IOMMU initialization function doesn't need swiotlb
         (e.g. the initialization is sucessful) then sets swiotlb to zero.
      
      5. If we find that swiotlb is set to zero, we free swiotlb
         resource.
      Reported-by: default avatarYinghai Lu <yinghai@kernel.org>
      Reported-by: default avatarRoland Dreier <rdreier@cisco.com>
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      LKML-Reference: <20091215204729A.fujita.tomonori@lab.ntt.co.jp>
      Tested-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      186a2502
    • Rusty Russell's avatar
      x86: don't export inline function · e6428047
      Rusty Russell authored
      
      For CONFIG_PARAVIRT, load_gs_index is an inline function (it's #defined
      to native_load_gs_index otherwise).
      
      Exporting an inline function breaks the new assembler-based alphabetical
      sorted symbol list:
      
      Today's linux-next build (x86_64 allmodconfig) failed like this:
      
      	.tmp_exports-asm.o: In function `__ksymtab_load_gs_index':
      	(__ksymtab_sorted+0x5b40): undefined reference to `load_gs_index'
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      To: x86@kernel.org
      Cc: alan-jenkins@tuffmail.co.uk
      e6428047
  13. 14 Dec, 2009 7 commits