1. 17 12月, 2009 2 次提交
  2. 16 12月, 2009 1 次提交
    • H
      x86, msr/cpuid: Register enough minors for the MSR and CPUID drivers · 0b962d47
      H. Peter Anvin 提交于
      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: NRuss 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: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <tip-*@git.kernel.org>
      0b962d47
  3. 15 12月, 2009 3 次提交
    • F
      x86: Split swiotlb initialization into two stages · 186a2502
      FUJITA Tomonori 提交于
      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: NYinghai Lu <yinghai@kernel.org>
      Reported-by: NRoland Dreier <rdreier@cisco.com>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      LKML-Reference: <20091215204729A.fujita.tomonori@lab.ntt.co.jp>
      Tested-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      186a2502
    • H
      x86: Regex support and known-movable symbols for relocs, fix _end · 873b5271
      H. Peter Anvin 提交于
      This adds a new category of symbols to the relocs program: symbols
      which are known to be relative, even though the linker emits them as
      absolute; this is the case for symbols that live in the linker script,
      which currently applies to _end.
      
      Unfortunately the previous workaround of putting _end in its own empty
      section was defeated by newer binutils, which remove empty sections
      completely.
      
      This patch also changes the symbol matching to use regular expressions
      instead of hardcoded C for specific patterns.
      
      This is a decidedly non-minimal patch: a modified version of the
      relocs program is used as part of the Syslinux build, and this 	is
      basically a backport to Linux of some of those changes; they have
      thus been well tested.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <4AF86211.3070103@zytor.com>
      Acked-by: NMichal Marek <mmarek@suse.cz>
      Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
      873b5271
    • H
      x86, msr: Remove incorrect, duplicated code in the MSR driver · 494c2ebf
      H. Peter Anvin 提交于
      The MSR driver would compute the values for cpu and c at declaration,
      and then again in the body of the function.  This isn't merely
      redundant, but unsafe, since cpu might not refer to a valid CPU at
      that point.
      
      Remove the unnecessary and dangerous references in the declarations.
      This code now matches the equivalent code in the CPUID driver.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      494c2ebf
  4. 14 12月, 2009 4 次提交
  5. 12 12月, 2009 2 次提交
    • M
      x86: Limit the number of processor bootup messages · 2eaad1fd
      Mike Travis 提交于
      When there are a large number of processors in a system, there
      is an excessive amount of messages sent to the system console.
      It's estimated that with 4096 processors in a system, and the
      console baudrate set to 56K, the startup messages will take
      about 84 minutes to clear the serial port.
      
      This set of patches limits the number of repetitious messages
      which contain no additional information.  Much of this information
      is obtainable from the /proc and /sysfs.   Some of the messages
      are also sent to the kernel log buffer as KERN_DEBUG messages so
      dmesg can be used to examine more closely any details specific to
      a problem.
      
      The new cpu bootup sequence for system_state == SYSTEM_BOOTING:
      
      Booting Node   0, Processors  #1 #2 #3 #4 #5 #6 #7 Ok.
      Booting Node   1, Processors  #8 #9 #10 #11 #12 #13 #14 #15 Ok.
      ...
      Booting Node   3, Processors  #56 #57 #58 #59 #60 #61 #62 #63 Ok.
      Brought up 64 CPUs
      
      After the system is running, a single line boot message is displayed
      when CPU's are hotplugged on:
      
          Booting Node %d Processor %d APIC 0x%x
      
      Status of the following lines:
      
          CPU: Physical Processor ID:		printed once (for boot cpu)
          CPU: Processor Core ID:		printed once (for boot cpu)
          CPU: Hyper-Threading is disabled	printed once (for boot cpu)
          CPU: Thermal monitoring enabled	printed once (for boot cpu)
          CPU %d/0x%x -> Node %d:		removed
          CPU %d is now offline:		only if system_state == RUNNING
          Initializing CPU#%d:		KERN_DEBUG
      Signed-off-by: NMike Travis <travis@sgi.com>
      LKML-Reference: <4B219E28.8080601@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      2eaad1fd
    • M
      x86: Remove enabling x2apic message for every CPU · 450b1e8d
      Mike Travis 提交于
      Print only once that the system is supporting x2apic mode.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <4B226E92.5080904@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      450b1e8d
  6. 11 12月, 2009 7 次提交
  7. 10 12月, 2009 12 次提交
  8. 09 12月, 2009 4 次提交
  9. 08 12月, 2009 1 次提交
  10. 07 12月, 2009 1 次提交
    • T
      x86: Fix bogus warning in apic_noop.apic_write() · a946d8f1
      Thomas Gleixner 提交于
      apic_noop is used to provide dummy apic functions. It's installed
      when the CPU has no APIC or when the APIC is disabled on the kernel
      command line.
      
      The apic_noop implementation of apic_write() warns when the CPU has
      an APIC or when the APIC is not disabled.
      
      That's bogus. The warning should only happen when the CPU has an
      APIC _AND_ the APIC is not disabled. apic_noop.apic_read() has the
      correct check.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: <stable@kernel.org> # in <= .32 this typo resides in native_apic_write_dummy()
      LKML-Reference: <alpine.LFD.2.00.0912071255420.3089@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a946d8f1
  11. 05 12月, 2009 1 次提交
    • L
      x86: ASUS P4S800 reboot=bios quirk · 4832ddda
      Leann Ogasawara 提交于
      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: NLeann Ogasawara <leann.ogasawara@canonical.com>
      LKML-Reference: <1259972107.4629.275.camel@emiko>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      4832ddda
  12. 04 12月, 2009 1 次提交
  13. 03 12月, 2009 1 次提交
    • M
      x86, apic: Enable lapic nmi watchdog on AMD Family 11h · 7d1849af
      Mikael Pettersson 提交于
      The x86 lapic nmi watchdog does not recognize AMD Family 11h,
      resulting in:
      
        NMI watchdog: CPU not supported
      
      As far as I can see from available documentation (the BKDM),
      family 11h looks identical to family 10h as far as the PMU
      is concerned.
      
      Extending the check to accept family 11h results in:
      
        Testing NMI watchdog ... OK.
      
      I've been running with this change on a Turion X2 Ultra ZM-82
      laptop for a couple of weeks now without problems.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <19223.53436.931768.278021@pilspetsen.it.uu.se>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7d1849af