1. 29 8月, 2009 1 次提交
    • J
      x86: Fix earlyprintk=dbgp for machines without NX · 47d25003
      Jan Beulich 提交于
      Since parse_early_param() may (e.g. for earlyprintk=dbgp)
      involve calls to page table manipulation functions (here
      set_fixmap_nocache()), NX hardware support must be determined
      before calling that function (so that __supported_pte_mask gets
      properly set up).
      
      But the call after parse_early_param() can also not go away, as
      that will honor eventual command line specified disabling of
      the NX functionality.
      
      ( This will then just result in whatever mappings got
        established during parse_early_param() having the NX bit set
        despite it being disabled on the command line, but I think
        that's tolerable).
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      LKML-Reference: <4A97F3BD02000078000121B9@vpn.id2.novell.com>
      [ merged to x86/pat to resolve a conflict. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47d25003
  2. 27 8月, 2009 11 次提交
  3. 22 8月, 2009 3 次提交
    • H
      x86, mtrr: make mtrr_aps_delayed_init static bool · 5400743d
      H. Peter Anvin 提交于
      mtr_aps_delayed_init was declared u32 and made global, but it only
      ever takes boolean values and is only ever used in
      arch/x86/kernel/cpu/mtrr/main.c.  Declare it "static bool" and remove
      external references.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      5400743d
    • S
      x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init · d0af9eed
      Suresh Siddha 提交于
      SDM Vol 3a section titled "MTRR considerations in MP systems" specifies
      the need for synchronizing the logical cpu's while initializing/updating
      MTRR.
      
      Currently Linux kernel does the synchronization of all cpu's only when
      a single MTRR register is programmed/updated. During an AP online
      (during boot/cpu-online/resume)  where we initialize all the MTRR/PAT registers,
      we don't follow this synchronization algorithm.
      
      This can lead to scenarios where during a dynamic cpu online, that logical cpu
      is initializing MTRR/PAT with cache disabled (cr0.cd=1) etc while other logical
      HT sibling continue to run (also with cache disabled because of cr0.cd=1
      on its sibling).
      
      Starting from Westmere, VMX transitions with cr0.cd=1 don't work properly
      (because of some VMX performance optimizations) and the above scenario
      (with one logical cpu doing VMX activity and another logical cpu coming online)
      can result in system crash.
      
      Fix the MTRR initialization by doing rendezvous of all the cpus. During
      boot and resume, we delay the MTRR/PAT init for APs till all the
      logical cpu's come online and the rendezvous process at the end of AP's bringup,
      will initialize the MTRR/PAT for all AP's.
      
      For dynamic single cpu online, we synchronize all the logical cpus and
      do the MTRR/PAT init on the AP that is coming online.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      d0af9eed
    • S
      generic-ipi: Allow cpus not yet online to call smp_call_function with irqs disabled · 269c861b
      Suresh Siddha 提交于
      Because of deadlock possiblities smp_call_function() is not allowed to
      be called with interrupts disabled. Add an exception for the cpu not
      yet online, as no one else can send smp call function interrupt to this
      cpu that is not yet online and as such deadlock condition is not possible.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      269c861b
  4. 21 8月, 2009 3 次提交
  5. 20 8月, 2009 3 次提交
  6. 18 8月, 2009 2 次提交
    • J
      i386: Fix section mismatches for init code with !HOTPLUG_CPU · 78b89ecd
      Jan Beulich 提交于
      Commit 0e83815b changed the
      section the initial_code variable gets allocated in, in an
      attempt to address a section conflict warning. This, however
      created a new section conflict when building without
      HOTPLUG_CPU. The apparently only (reasonable) way to address
      this is to always use __REFDATA.
      
      Once at it, also fix a second section mismatch when not using
      HOTPLUG_CPU.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Robert Richter <robert.richter@amd.com>
      LKML-Reference: <4A8AE7CD020000780001054B@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      78b89ecd
    • S
      x86, pat: Allow ISA memory range uncacheable mapping requests · 1adcaafe
      Suresh Siddha 提交于
      Max Vozeler reported:
      >  Bug 13877 -  bogl-term broken with CONFIG_X86_PAT=y, works with =n
      >
      >  strace of bogl-term:
      >  814   mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0)
      >				 = -1 EAGAIN (Resource temporarily unavailable)
      >  814   write(2, "bogl: mmaping /dev/fb0: Resource temporarily unavailable\n",
      >	       57) = 57
      
      PAT code maps the ISA memory range as WB in the PAT attribute, so that
      fixed range MTRR registers define the actual memory type (UC/WC/WT etc).
      
      But the upper level is_new_memtype_allowed() API checks are failing,
      as the request here is for UC and the return tracked type is WB (Tracked type is
      WB as MTRR type for this legacy range potentially will be different for each
      4k page).
      
      Fix is_new_memtype_allowed() by always succeeding the ISA address range
      checks, as the null PAT (WB) and def MTRR fixed range register settings
      satisfy the memory type needs of the applications that map the ISA address
      range.
      Reported-and-Tested-by: NMax Vozeler <xam@debian.org>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      1adcaafe
  7. 17 8月, 2009 3 次提交
    • I
      x86, mce: Don't initialize MCEs on unknown CPUs · e412cd25
      Ingo Molnar 提交于
      An older test-box started hanging at the following point during
      bootup:
      
       [    0.022996] Mount-cache hash table entries: 512
       [    0.024996] Initializing cgroup subsys debug
       [    0.025996] Initializing cgroup subsys cpuacct
       [    0.026995] Initializing cgroup subsys devices
       [    0.027995] Initializing cgroup subsys freezer
       [    0.028995] mce: CPU supports 5 MCE banks
      
      I've bisected it down to commit 4efc0670 ("x86, mce: use 64bit
      machine check code on 32bit"), which utilizes the MCE code on
      32-bit systems too.
      
      The problem is caused by this detail in my config:
      
        # CONFIG_CPU_SUP_INTEL is not set
      
      This disables the quirks in mce_cpu_quirks() but still enables
      MCE support - which then hangs due to the missing quirk
      workaround needed on this CPU:
      
      	if (c->x86 == 6 && c->x86_model < 0x1A && banks > 0)
      		mce_banks[0].init = 0;
      
      The safe solution is to not initialize MCEs if we dont know on
      what CPU we are running (or if that CPU's support code got
      disabled in the config).
      
      Also be a bit more defensive on 32-bit systems: dont do a
      boot-time dump of pending MCEs not just on the specific system
      that we found a problem with (Pentium-M), but earlier ones as
      well.
      
      Now this problem is probably not common and disabling CPU
      support is rare - but still being more defensive in something
      we turned on for a wide range of CPUs is prudent.
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      LKML-Reference: Message-ID: <4A88E3E4.40506@jp.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e412cd25
    • B
      x86, mce: don't log boot MCEs on Pentium M (model == 13) CPUs · c7f6fa44
      Bartlomiej Zolnierkiewicz 提交于
      On my legacy Pentium M laptop (Acer Extensa 2900) I get bogus MCE on a cold
      boot with CONFIG_X86_NEW_MCE enabled, i.e. (after decoding it with mcelog):
      
      MCE 0
      HARDWARE ERROR. This is *NOT* a software problem!
      Please contact your hardware vendor
      CPU 0 BANK 1 MCG status:
      MCi status:
      Error overflow
      Uncorrected error
      Error enabled
      Processor context corrupt
      MCA: Data CACHE Level-1 UNKNOWN Error
      STATUS f200000000000195 MCGSTATUS 0
      
      [ The other STATUS values observed: f2000000000001b5 (... UNKNOWN error)
        and f200000000000115 (... READ Error).
      
        To verify that this is not a CONFIG_X86_NEW_MCE bug I also modified
        the CONFIG_X86_OLD_MCE code (which doesn't log any MCEs) to dump
        content of STATUS MSR before it is cleared during initialization. ]
      
      Since the bogus MCE results in a kernel taint (which in turn disables
      lockdep support) don't log boot MCEs on Pentium M (model == 13) CPUs
      by default ("mce=bootlog" boot parameter can be be used to get the old
      behavior).
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Reviewed-by: NAndi Kleen <andi@firstfloor.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7f6fa44
    • L
      x86: Annotate section mismatch warnings in kernel/apic/x2apic_uv_x.c · 52459ab9
      Leonardo Potenza 提交于
      The function uv_acpi_madt_oem_check() has been marked __init,
      the struct apic_x2apic_uv_x has been marked __refdata.
      
      The aim is to address the following section mismatch messages:
      
      WARNING: arch/x86/kernel/apic/built-in.o(.data+0x1368): Section mismatch in reference from the variable apic_x2apic_uv_x to the function .cpuinit.text:uv_wakeup_secondary()
      The variable apic_x2apic_uv_x references
      the function __cpuinit uv_wakeup_secondary()
      If the reference is valid then annotate the
      variable with __init* or __refdata (see linux/init.h) or name the variable:
      *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
      
      WARNING: arch/x86/kernel/built-in.o(.data+0x68e8): Section mismatch in reference from the variable apic_x2apic_uv_x to the function .cpuinit.text:uv_wakeup_secondary()
      The variable apic_x2apic_uv_x references
      the function __cpuinit uv_wakeup_secondary()
      If the reference is valid then annotate the
      variable with __init* or __refdata (see linux/init.h) or name the variable:
      *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
      
      WARNING: arch/x86/built-in.o(.text+0x7b36f): Section mismatch in reference from the function uv_acpi_madt_oem_check() to the function .init.text:early_ioremap()
      The function uv_acpi_madt_oem_check() references
      the function __init early_ioremap().
      This is often because uv_acpi_madt_oem_check lacks a __init
      annotation or the annotation of early_ioremap is wrong.
      
      WARNING: arch/x86/built-in.o(.text+0x7b38d): Section mismatch in reference from the function uv_acpi_madt_oem_check() to the function .init.text:early_iounmap()
      The function uv_acpi_madt_oem_check() references
      the function __init early_iounmap().
      This is often because uv_acpi_madt_oem_check lacks a __init
      annotation or the annotation of early_iounmap is wrong.
      
      WARNING: arch/x86/built-in.o(.data+0x8668): Section mismatch in reference from the variable apic_x2apic_uv_x to the function .cpuinit.text:uv_wakeup_secondary()
      The variable apic_x2apic_uv_x references
      the function __cpuinit uv_wakeup_secondary()
      If the reference is valid then annotate the
      variable with __init* or __refdata (see linux/init.h) or name the variable:
      *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
      Signed-off-by: NLeonardo Potenza <lpotenza@inwind.it>
      LKML-Reference: <200908161855.48302.lpotenza@inwind.it>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      52459ab9
  8. 16 8月, 2009 1 次提交
  9. 15 8月, 2009 1 次提交
  10. 14 8月, 2009 9 次提交
  11. 13 8月, 2009 3 次提交
    • P
      perf_counter: Report the cloning task as parent on perf_counter_fork() · 94d5d1b2
      Peter Zijlstra 提交于
      A bug in (9f498cc5: perf_counter: Full task tracing) makes
      profiling multi-threaded apps it go belly up.
      
      [ output as: (PID:TID):(PPID:PTID) ]
      
       # ./perf report -D | grep FORK
      0x4b0 [0x18]: PERF_EVENT_FORK: (3237:3237):(3236:3236)
      0xa10 [0x18]: PERF_EVENT_FORK: (3237:3238):(3236:3236)
      0xa70 [0x18]: PERF_EVENT_FORK: (3237:3239):(3236:3236)
      0xad0 [0x18]: PERF_EVENT_FORK: (3237:3240):(3236:3236)
      0xb18 [0x18]: PERF_EVENT_FORK: (3237:3241):(3236:3236)
      
      Shows us that the test (27d028de perf report: Update for the new
      FORK/EXIT events) in builtin-report.c:
      
              /*
               * A thread clone will have the same PID for both
               * parent and child.
               */
              if (thread == parent)
                      return 0;
      
      Will clearly fail.
      
      The problem is that perf_counter_fork() reports the actual
      parent, instead of the cloning thread.
      
      Fixing that (with the below patch), yields:
      
       # ./perf report -D | grep FORK
      0x4c8 [0x18]: PERF_EVENT_FORK: (1590:1590):(1589:1589)
      0xbd8 [0x18]: PERF_EVENT_FORK: (1590:1591):(1590:1590)
      0xc80 [0x18]: PERF_EVENT_FORK: (1590:1592):(1590:1590)
      0x3338 [0x18]: PERF_EVENT_FORK: (1590:1593):(1590:1590)
      0x66b0 [0x18]: PERF_EVENT_FORK: (1590:1594):(1590:1590)
      
      Which both makes more sense and doesn't confuse perf report
      anymore.
      Reported-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: paulus@samba.org
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <1250172882.5241.62.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      94d5d1b2
    • P
      perf_counter: Fix an ipi-deadlock · 970892a9
      Peter Zijlstra 提交于
      perf_pending_counter() is called from IRQ context and will call
      perf_counter_disable(), however perf_counter_disable() uses
      smp_call_function_single() which doesn't fancy being used with
      IRQs disabled due to IPI deadlocks.
      
      Fix this by making it use the local __perf_counter_disable()
      call and teaching the counter_sched_out() code about pending
      disables as well.
      
      This should cover the case where a counter migrates before the
      pending queue gets processed.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey J Ashford <cjashfor@us.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: stephane eranian <eranian@googlemail.com>
      LKML-Reference: <20090813103655.244097721@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      970892a9
    • P
      perf: Rework/fix the whole read vs group stuff · 3dab77fb
      Peter Zijlstra 提交于
      Replace PERF_SAMPLE_GROUP with PERF_SAMPLE_READ and introduce
      PERF_FORMAT_GROUP to deal with group reads in a more generic
      way.
      
      This allows you to get group reads out of read() as well.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Corey J Ashford <cjashfor@us.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: stephane eranian <eranian@googlemail.com>
      LKML-Reference: <20090813103655.117411814@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3dab77fb