1. 13 5月, 2008 3 次提交
    • Y
      x86: checking aperture size order · 8c9fd91a
      Yinghai Lu 提交于
      some systems are using 32M for gart and agp when memory is less than 4G.
      Kernel will reject and try to allcate another 64M that is not needed,
      and we will waste 64M of perfectly good RAM.
      
      this patch adds a workaround by checking aper_base/order between NB and
      agp bridge. If they are the same, and memory size is less than 4G, it
      will allow it.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      8c9fd91a
    • Y
      x86: agp_gart size checking for buggy device · 1edc1ab3
      Yinghai Lu 提交于
      while looking at Rafael J. Wysocki's system boot log,
      
      I found a funny printout:
      
      	Node 0: aperture @ de000000 size 32 MB
      	Aperture too small (32 MB)
      	AGP bridge at 00:04:00
      	Aperture from AGP @ de000000 size 4096 MB (APSIZE 0)
      	Aperture too small (0 MB)
      	Your BIOS doesn't leave a aperture memory hole
      	Please enable the IOMMU option in the BIOS setup
      	This costs you 64 MB of RAM
      	Mapping aperture over 65536 KB of RAM @ 4000000
      
      	...
      
      	agpgart: Detected AGP bridge 20
      	agpgart: Aperture pointing to RAM
      	agpgart: Aperture from AGP @ de000000 size 4096 MB
      	agpgart: Aperture too small (0 MB)
      	agpgart: No usable aperture found.
      	agpgart: Consider rebooting with iommu=memaper=2 to get a good aperture.
      
      it means BIOS allocated the correct gart on the NB and AGP bridge, but
      because a bug in the silicon (the agp bridge reports the wrong order,
      it wants 4G instead) the kernel will reject that allocation.
      
      Also, because the size is only 32MB, and we try to get another 64M for gart,
      late fix_northbridge can not revert that change because it still reads
      the wrong size from agp bridge.
      
      So try to double check the order value from the agp bridge, before calling
      aperture_valid().
      
      [ mingo@elte.hu: 32-bit fix. ]
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1edc1ab3
    • P
      x86: iommu: use symbolic constants, not hardcoded numbers · aa134f1b
      Pavel Machek 提交于
      Move symbolic constants into gart.h, and use them instead of hardcoded
      constant.
      Signed-off-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      aa134f1b
  2. 30 4月, 2008 1 次提交
  3. 26 4月, 2008 2 次提交
  4. 20 2月, 2008 2 次提交
  5. 19 2月, 2008 3 次提交
  6. 06 2月, 2008 1 次提交
  7. 05 2月, 2008 11 次提交
  8. 30 1月, 2008 3 次提交
  9. 24 1月, 2008 1 次提交
  10. 30 10月, 2007 1 次提交
  11. 18 10月, 2007 1 次提交
  12. 17 10月, 2007 2 次提交
  13. 15 10月, 2007 2 次提交
    • J
      fix use after free in amd create gatt pages · bdc3e603
      Jesper Juhl 提交于
      Coverity spotted a "use after free" bug in
      drivers/char/agp/amd-k7-agp.c::amd_create_gatt_pages().
      
      The problem is this:
      	If "entry = kzalloc(sizeof(struct amd_page_map), GFP_KERNEL);"
      fails, then there's a loop in the function to free all entries
      allocated so far and break out of the allocation loop. That in itself
      is pretty sane, but then the (now freed) 'tables' is assigned to
      amd_irongate_private.gatt_pages and 'retval' is set to -ENOMEM which
      causes amd_free_gatt_pages(); to be called at the end of the function.
      The problem with this is that amd_free_gatt_pages() will then loop
      'amd_irongate_private.num_tables' times and try to free each entry in
      tables[] - this is bad since tables has already been freed and
      furthermore it will call kfree(tables) at the end - a double free.
      
      This patch removes the freeing loop in amd_create_gatt_pages() and
      instead relies entirely on the call to amd_free_gatt_pages() to free
      everything we allocated in case of an error. It also sets
      amd_irongate_private.num_tables to the actual number of entries
      allocated instead of just using the value passed in from the caller -
      this ensures that amd_free_gatt_pages() will only attempt to free
      stuff that was actually allocated.
      Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      bdc3e603
    • D
      AGP fix race condition between unmapping and freeing pages · a2721e99
      Dave Airlie 提交于
      With Andi's clflush fixup, we were getting hangs on server exit, flushing the
      mappings after freeing each page helped.
      
      This showed up a race condition where the pages after being freed could be
      reused before the agp mappings had been flushed.  Flushing after each single
      page is a bad thing for future drm work, so make the page destroy a two pass
      unmapping all the pages, flushing the mappings, and then destroying the pages.
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      a2721e99
  14. 07 10月, 2007 1 次提交
  15. 20 9月, 2007 1 次提交
  16. 12 9月, 2007 2 次提交
  17. 25 8月, 2007 2 次提交
  18. 06 8月, 2007 1 次提交