1. 30 11月, 2006 6 次提交
  2. 29 11月, 2006 1 次提交
  3. 28 11月, 2006 3 次提交
  4. 26 11月, 2006 16 次提交
  5. 24 11月, 2006 2 次提交
  6. 23 11月, 2006 2 次提交
    • L
      [AGP] Allocate AGP pages with GFP_DMA32 by default · 66c669ba
      Linus Torvalds 提交于
      Not all graphic page remappers support physical addresses over the 4GB
      mark for remapping, so while some do (the AMD64 GART always did, and I
      just fixed the i965 to do so properly), we're safest off just forcing
      GFP_DMA32 allocations to make sure graphics pages get allocated in the
      low 32-bit address space by default.
      
      AGP sub-drivers that really care, and can do better, could just choose
      to implement their own allocator (or we could add another "64-bit safe"
      default allocator for their use), but quite frankly, you're not likely
      to care in practice.
      
      So for now, this trivial change means that we won't be allocating pages
      that we can't map correctly by mistake on x86-64.
      
      [ On traditional 32-bit x86, this could never happen, because GFP_KERNEL
        would never allocate any highmem memory anyway ]
      Acked-by: NAndi Kleen <ak@suse.de>
      Acked-by: NDave Jones <davej@redhat.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      66c669ba
    • L
      [AGP] Fix intel 965 AGP memory mapping function · 7d915a38
      Linus Torvalds 提交于
      This introduces a i965-specific "mask_memory()" function that knows
      about the extended physical addresses that the i965 supports.  This
      allows us to correctly map in physical memory in the >4GB range into the
      GTT.
      
      Also simplify/clean-up the i965 case for the aperture sizing by just
      returning the fixed 512kB size from "fetch_size()".  We don't really
      care that not all of the aperture may be visible - the only thing that
      cares about the aperture size is the Intel "stolen memory" calculation,
      which depends on the fixed size.
      
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7d915a38
  7. 22 11月, 2006 2 次提交
  8. 21 11月, 2006 7 次提交
  9. 18 11月, 2006 1 次提交
    • L
      Revert "ACPI: created a dedicated workqueue for notify() execution" · b976fe19
      Linus Torvalds 提交于
      This reverts commit 37605a69.
      
      Again.
      
      This same bug has now been introduced twice: it was done earlier by
      commit b8d35192, only to be reverted
      last time in commit 72945b2b.
      
      We must NOT try to queue up notify handlers to another thread than the
      normal ACPI execution thread, because the notifications on some systems
      seem to just keep on accumulating until we run out of memory and/or
      threads.
      
      Keeping events within the one deferred execution thread automatically
      throttles the events properly.
      
      At least the Compaq N620c will lock up completely on the first thermal
      event without this patch reverted.
      
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b976fe19