1. 28 6月, 2009 1 次提交
    • H
      Revert "x86: cap iomem_resource to addressable physical memory" · ff8a4bae
      H. Peter Anvin 提交于
      This reverts commit 95ee14e4.
      Mikael Petterson <mikepe@it.uu.se> reported that at least one of his
      systems will not boot as a result.  We have ruled out the detection
      algorithm malfunctioning, so it is not a matter of producing the
      incorrect bitmasks; rather, something in the application of them
      fails.
      
      Revert the commit until we can root cause and correct this problem.
      
      -stable team: this means the underlying commit should be rejected.
      Reported-and-isolated-by: NMikael Petterson <mikpe@it.uu.se>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <200906261559.n5QFxJH8027336@pilspetsen.it.uu.se>
      Cc: stable@kernel.org
      Cc: Grant Grundler <grundler@parisc-linux.org>
      ff8a4bae
  2. 26 6月, 2009 5 次提交
    • P
      x86, delay: tsc based udelay should have rdtsc_barrier · e888d7fa
      Pallipadi, Venkatesh 提交于
      delay_tsc needs rdtsc_barrier to provide proper delay.
      
      Output from a test driver using hpet to cross check delay
      provided by udelay().
      
      Before:
      [   86.794363] Expected delay 5us actual 4679ns
      [   87.154362] Expected delay 5us actual 698ns
      [   87.514162] Expected delay 5us actual 4539ns
      [   88.653716] Expected delay 5us actual 4539ns
      [   94.664106] Expected delay 10us actual 9638ns
      [   95.049351] Expected delay 10us actual 10126ns
      [   95.416110] Expected delay 10us actual 9568ns
      [   95.799216] Expected delay 10us actual 9638ns
      [  103.624104] Expected delay 10us actual 9707ns
      [  104.020619] Expected delay 10us actual 768ns
      [  104.419951] Expected delay 10us actual 9707ns
      
      After:
      [   50.983320] Expected delay 5us actual 5587ns
      [   51.261807] Expected delay 5us actual 5587ns
      [   51.565715] Expected delay 5us actual 5657ns
      [   51.861171] Expected delay 5us actual 5587ns
      [   52.164704] Expected delay 5us actual 5726ns
      [   52.487457] Expected delay 5us actual 5657ns
      [   52.789338] Expected delay 5us actual 5726ns
      [   57.119680] Expected delay 10us actual 10755ns
      [   57.893997] Expected delay 10us actual 10615ns
      [   58.261287] Expected delay 10us actual 10755ns
      [   58.620505] Expected delay 10us actual 10825ns
      [   58.941035] Expected delay 10us actual 10755ns
      [   59.320903] Expected delay 10us actual 10615ns
      [   61.306311] Expected delay 10us actual 10755ns
      [   61.520542] Expected delay 10us actual 10615ns
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      e888d7fa
    • H
      x86, setup: correct include file in <asm/boot.h> · 658dbfeb
      H. Peter Anvin 提交于
      <asm/boot.h> needs <asm/pgtable_types.h>, not <asm/page_types.h> in
      order to resolve PMD_SHIFT.  Also, correct a +1 which really should be
      + THREAD_ORDER.
      
      This is a build error which was masked by a typoed #ifdef.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      658dbfeb
    • R
      x86, setup: Fix typo "CONFIG_x86_64" in <asm/boot.h> · 22f4319d
      Robert P. J. Day 提交于
      CONFIG_X86_64 was misspelled (wrong case), which caused the x86-64
      kernel to advertise itself as more relocatable than it really is.
      This could in theory cause boot failures once bootloaders start
      support the new relocation fields.
      Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      22f4319d
    • H
      x86, mce: percpu mcheck_timer should be pinned · 5be6066a
      Hidetoshi Seto 提交于
      If CONFIG_NO_HZ + CONFIG_SMP, timer added via add_timer() might
      be migrated on other cpu.  Use add_timer_on() instead.
      
      Avoids the following failure:
      
      Maciej Rutecki wrote:
      > > After normal boot I try:
      > >
      > > echo 1 > /sys/devices/system/machinecheck/machinecheck0/check_interval
      > >
      > > I found this in dmesg:
      > >
      > > [  141.704025] ------------[ cut here ]------------
      > > [  141.704039] WARNING: at arch/x86/kernel/cpu/mcheck/mce.c:1102
      > > mcheck_timer+0xf5/0x100()
      Reported-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Tested-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
      Acked-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      5be6066a
    • K
      x86: Add sysctl to allow panic on IOCK NMI error · 5211a242
      Kurt Garloff 提交于
      This patch introduces a new sysctl:
      
          /proc/sys/kernel/panic_on_io_nmi
      
      which defaults to 0 (off).
      
      When enabled, the kernel panics when the kernel receives an NMI
      caused by an IO error.
      
      The IO error triggered NMI indicates a serious system
      condition, which could result in IO data corruption. Rather
      than contiuing, panicing and dumping might be a better choice,
      so one can figure out what's causing the IO error.
      
      This could be especially important to companies running IO
      intensive applications where corruption must be avoided, e.g. a
      bank's databases.
      
      [ SuSE has been shipping it for a while, it was done at the
        request of a large database vendor, for their users. ]
      Signed-off-by: NKurt Garloff <garloff@suse.de>
      Signed-off-by: NRoberto Angelino <robertangelino@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      LKML-Reference: <20090624213211.GA11291@kroah.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5211a242
  3. 24 6月, 2009 2 次提交
  4. 23 6月, 2009 1 次提交
    • P
      x86: Move init_gbpages() to setup_arch() · 854c879f
      Pekka J Enberg 提交于
      The init_gbpages() function is conditionally called from
      init_memory_mapping() function. There are two call-sites where
      this 'after_bootmem' condition can be true: setup_arch() and
      mem_init() via pci_iommu_alloc().
      
      Therefore, it's safe to move the call to init_gbpages() to
      setup_arch() as it's always called before mem_init().
      
      This removes an after_bootmem use - paving the way to remove
      all uses of that state variable.
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <Pine.LNX.4.64.0906221731210.19474@melkki.cs.Helsinki.FI>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      854c879f
  5. 22 6月, 2009 25 次提交
  6. 21 6月, 2009 6 次提交