1. 20 8月, 2009 33 次提交
  2. 18 8月, 2009 1 次提交
  3. 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
  4. 16 8月, 2009 1 次提交
  5. 15 8月, 2009 2 次提交
    • L
      ARM: 5673/1: U300 fix initsection compile warning · a2bb9f4d
      Linus Walleij 提交于
      The u300_init_check_chip() function was not properly tagged with
      the __init macro and provided a initsection mismatch on
      compilation.
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a2bb9f4d
    • R
      ARM: Fix broken highmem support · dde5828f
      Russell King 提交于
      Currently, highmem is selectable, and you can request an increased
      vmalloc area.  However, none of this has any effect on the memory
      layout since a patch in the highmem series was accidentally dropped.
      Moreover, even if you did want highmem, all memory would still be
      registered as lowmem, possibly resulting in overflow of the available
      virtual mapping space.
      
      The highmem boundary is determined by the highest allowed beginning
      of the vmalloc area, which depends on its configurable minimum size
      (see commit 60296c71 for details on
      this).
      
      We should create mappings and initialize bootmem only for low memory,
      while the zone allocator must still be told about highmem.
      
      Currently, memory nodes which are completely located in high memory
      are not supported.  This is not a huge limitation since systems
      relying on highmem support are unlikely to have discontiguous memory
      with large holes.
      
      [ A similar patch was meant to be merged before commit 5f0fbf9e
        and be available  in Linux v2.6.30, however some git rebase screw-up
        of mine dropped the first commit of the series, and that goofage
        escaped testing somehow as well. -- Nico ]
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: NNicolas Pitre <nico@marvell.com>
      dde5828f