1. 16 7月, 2008 23 次提交
  2. 15 7月, 2008 5 次提交
    • T
      x86: sanitize Kconfig · aba3728c
      Thomas Gleixner 提交于
      Set default n for MEMTEST and MTRR_SANITIZER and fix the help texts.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      aba3728c
    • L
      x86: MMIOTRACE should not default to on · 116a9fb3
      Linus Torvalds 提交于
      Even the help-text makes it clear that normal people shouldn't enable
      it.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      116a9fb3
    • L
      Start using the new '%pS' infrastructure to print symbols · 7daf705f
      Linus Torvalds 提交于
      This simplifies the code significantly, and was the whole point of the
      exercise.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7daf705f
    • H
      x86, suspend, acpi: correct and add comments about Big Real Mode · 065cb3df
      H. Peter Anvin 提交于
      Explain that we set up the descriptors for Big Real Mode, and why we
      do so.  In particular, one system that is known to fail without it is
      the Lenovo X61.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      065cb3df
    • H
      x86, suspend, acpi: enter Big Real Mode · 3bf2e774
      H. Peter Anvin 提交于
      The explanation for recent video BIOS suspend quirk failures is that
      the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff)
      instead of ordinary Real Mode (*.limit = 0xffff).
      
      This patch changes the segment descriptors to Big Real Mode instead.
      
      The segment descriptor registers (what Intel calls "segment cache") is
      always active.  The only thing that changes based on CR0.PE is how it is
      *loaded* and the interpretation of the CS flags.
      
      The segment descriptor registers contain of the following sub-registers:
      selector (the "visible" part), base, limit and flags.  In protected mode
      or long mode, they are loaded from descriptors (or fs.base or gs.base can
      be manipulated directly in long mode.)  In real mode, the only thing
      changed by a segment register load is the selector and the base, where the
      base <- selector << 4.  In particular, *the limit and the flags are not
      changed*.
      
      As far as the handling of the CS flags: a code segment cannot be writable
      in protected mode, whereas it is "just another segment" in real mode, so
      there is some kind of quirk that kicks in for this when CR0.PE <- 0.  I'm
      not sure if this is accomplished by actually changing the cs.flags register
      or just changing the interpretation; it might be something that is
      CPU-specific.  In particular, the Transmeta CPUs had an explicit "CS is
      writable if you're in real mode" override, so even if you had loaded CS
      with an execute-only segment it'd be writable (but not readable!) on return
      to real mode.  I'm not at all sure if that is how other CPUs behave.
      Signed-off-by: N"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3bf2e774
  3. 14 7月, 2008 6 次提交
  4. 13 7月, 2008 6 次提交
    • M
      x86: I/O APIC: remove an IRQ2-mask hack · ce8b06b9
      Maciej W. Rozycki 提交于
      Now that IRQ2 is never made available to the I/O APIC, there is no need
      to special-case it and mask as a workaround for broken systems.  Actually,
      because of the former, mask_IO_APIC_irq(2) is a no-op already.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce8b06b9
    • Y
      x86: fix numaq_tsc_disable calling · 3d88cca7
      Yinghai Lu 提交于
      got this on a test-system:
      
       calling  numaq_tsc_disable+0x0/0x39
       NUMAQ: disabling TSC
       initcall numaq_tsc_disable+0x0/0x39 returned 0 after 0 msecs
      
      that's because we should not be using arch_initcall to call numaq_tsc_disable.
      
      need to call it in setup_arch before time_init()/tsc_init()
      and call it in init_intel() to make the cpu feature bits right.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3d88cca7
    • Y
      x86, e820: remove end_user_pfn · 7b479bec
      Yinghai Lu 提交于
      end_user_pfn used to modify the meaning of the e820 maps.
      
      Now that all e820 operations are cleaned up, unified, tightened up,
      the e820 map always get updated to reality, we don't need to keep
      this secondary mechanism anymore.
      
      If you hit this commit in bisection it means something slipped through.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7b479bec
    • Y
      x86: max_low_pfn_mapped fix, #3 · 9958e810
      Yinghai Lu 提交于
      optimization: try to merge the range with same page size in
      init_memory_mapping, to get the best possible linear mappings set up.
      
      thus when GBpages is not there, we could do 2M pages.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9958e810
    • Y
      x86: max_low_pfn_mapped fix, #2 · 965194c1
      Yinghai Lu 提交于
      tighten the boundary checks around max_low_pfn_mapped - dont overmap
      nor undermap into holes.
      
      also print out tseg for AMD cpus, for diagnostic purposes.
      (this is an SMM area, and we split up any big mappings around that area)
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      965194c1
    • Y
      x86: max_low_pfn_mapped fix, #1 · 7ab073b6
      Yinghai Lu 提交于
      fix crash on Ingo's big box:
      
      calling  pci_iommu_init+0x0/0x17
      PCI-DMA: Disabling AGP.
      PCI-DMA: aperture base @ d0000000 size 65536 KB
      PCI-DMA: using GART IOMMU.
      PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
      BUG: unable to handle kernel paging request at ffff88000003be88
      IP: [<ffffffff8026d377>] __alloc_pages_internal+0xc3/0x3f2
      PGD 202063 PUD 206063 PMD 22fc00163 PTE 3b162
      Oops: 0000 [1] SMP
      
      and e820 is:
      
       BIOS-e820: 0000000000000000 - 000000000009ac00 (usable)
       BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved)
       BIOS-e820: 00000000000ca000 - 0000000000100000 (reserved)
       BIOS-e820: 0000000000100000 - 000000007ff70000 (usable)
       BIOS-e820: 000000007ff70000 - 000000007ff86000 (ACPI data)
       BIOS-e820: 000000007ff86000 - 0000000080000000 (ACPI NVS)
       BIOS-e820: 0000000080000000 - 00000000cfe00000 (usable)
       BIOS-e820: 00000000cfe00000 - 00000000d0000000 (reserved)
       BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
       BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
       BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
       BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
       BIOS-e820: 0000000100000000 - 0000000830000000 (usable)
      
      system has 32 GB RAM installed.
      
      max_low_pfn_mapped is 0xcfe00, and GART aperture is not mapped.
      
      So try to use init_memory_mapping to map that area, because the iommu
      thinks that area is ram ...
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7ab073b6