1. 30 9月, 2008 1 次提交
  2. 28 9月, 2008 1 次提交
  3. 23 7月, 2008 1 次提交
    • V
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum 提交于
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      
      The format:
      
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
         underscores.
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      77ef50a5
  4. 11 7月, 2008 1 次提交
  5. 10 7月, 2008 1 次提交
  6. 27 6月, 2008 1 次提交
    • I
      x86, AMD IOMMU, build fix #2 · 92af4e29
      Ingo Molnar 提交于
      fix:
      
       arch/x86/kernel/amd_iommu.c: In function ‘amd_iommu_init_dma_ops':
       arch/x86/kernel/amd_iommu.c:940: error: lvalue required as left operand of assignment
       arch/x86/kernel/amd_iommu.c:941: error: lvalue required as left operand of assignment
      
      due to !CONFIG_GART_IOMMU.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      92af4e29
  7. 12 6月, 2008 1 次提交
  8. 22 5月, 2008 1 次提交
  9. 13 5月, 2008 2 次提交
  10. 30 1月, 2008 1 次提交
    • Y
      x86: disable the GART early, 64-bit · aaf23042
      Yinghai Lu 提交于
      For K8 system: 4G RAM with memory hole remapping enabled, or more than
      4G RAM installed.
      
      when try to use kexec second kernel, and the first doesn't include
      gart_shutdown. the second kernel could have different aper position than
      the first kernel. and second kernel could use that hole as RAM that is
      still used by GART set by the first kernel. esp. when try to kexec
      2.6.24 with sparse mem enable from previous kernel (from RHEL 5 or SLES
      10). the new kernel will use aper by GART (set by first kernel) for
      vmemmap. and after new kernel setting one new GART. the position will be
      real RAM. the _mapcount set is lost.
      
      Bad page state in process 'swapper'
      page:ffffe2000e600020 flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0
      Trying to fix it up, but a reboot is needed
      Backtrace:
      Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13
      
      Call Trace:
       [<ffffffff8026401f>] bad_page+0x63/0x8d
       [<ffffffff80264169>] __free_pages_ok+0x7c/0x2a5
       [<ffffffff80ba75d1>] free_all_bootmem_core+0xd0/0x198
       [<ffffffff80ba3a42>] numa_free_all_bootmem+0x3b/0x76
       [<ffffffff80ba3461>] mem_init+0x3b/0x152
       [<ffffffff80b959d3>] start_kernel+0x236/0x2c2
       [<ffffffff80b9511a>] _sinittext+0x11a/0x121
      
      and
       [ffffe2000e600000-ffffe2000e7fffff] PMD ->ffff81001c200000 on node 0
      phys addr is : 0x1c200000
      
      RHEL 5.1 kernel -53 said:
      PCI-DMA: aperture base @ 1c000000 size 65536 KB
      
      new kernel said:
      Mapping aperture over 65536 KB of RAM @ 3c000000
      
      So could try to disable that GART if possible.
      
      According to Ingo
      
      > hm, i'm wondering, instead of modifying the GART, why dont we simply
      > _detect_ whatever GART settings we have inherited, and propagate that
      > into our e820 maps? I.e. if there's inconsistency, then punch that out
      > from the memory maps and just dont use that memory.
      >
      > that way it would not matter whether the GART settings came from a [old
      > or crashing] Linux kernel that has not called gart_iommu_shutdown(), or
      > whether it's a BIOS that has set up an aperture hole inconsistent with
      > the memory map it passed. (or the memory map we _think_ i tried to pass
      > us)
      >
      > it would also be more robust to only read and do a memory map quirk
      > based on that, than actively trying to change the GART so early in the
      > bootup. Later on we have to re-enable the GART _anyway_ and have to
      > punch a hole for it.
      >
      > and as a bonus, we would have shored up our defenses against crappy
      > BIOSes as well.
      
      add e820 modification for gart inconsistent setting.
      
      gart_fix_e820=off could be used to disable e820 fix.
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      aaf23042
  11. 30 10月, 2007 3 次提交
  12. 11 10月, 2007 1 次提交
  13. 22 7月, 2007 1 次提交