1. 27 7月, 2010 12 次提交
  2. 20 7月, 2010 2 次提交
  3. 19 7月, 2010 2 次提交
    • D
      mm: add context argument to shrinker callback · 7f8275d0
      Dave Chinner 提交于
      The current shrinker implementation requires the registered callback
      to have global state to work from. This makes it difficult to shrink
      caches that are not global (e.g. per-filesystem caches). Pass the shrinker
      structure to the callback so that users can embed the shrinker structure
      in the context the shrinker needs to operate on and get back to it in the
      callback via container_of().
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      7f8275d0
    • L
      drm/i915: add 'reclaimable' to i915 self-reclaimable page allocations · cd9f040d
      Linus Torvalds 提交于
      The hibernate issues that got fixed in commit 985b823b ("drm/i915:
      fix hibernation since i915 self-reclaim fixes") turn out to have been
      incomplete.  Vefa Bicakci tested lots of hibernate cycles, and without
      the __GFP_RECLAIMABLE flag the system eventually fails to resume.
      
      With the flag added, Vefa can apparently hibernate forever (or until he
      gets bored running his automated scripts, whichever comes first).
      
      The reclaimable flag was there originally, and was one of the flags that
      were dropped (unintentionally) by commit 4bdadb97 ("drm/i915:
      Selectively enable self-reclaim") that introduced all these problems,
      but I didn't want to just blindly add back all the flags in commit
      985b823b, and it looked like __GFP_RECLAIM wasn't necessary.  It
      clearly was.
      
      I still suspect that there is some subtle reason we're missing that
      causes the problems, but __GFP_RECLAIMABLE is certainly not wrong to use
      in this context, and is what the code historically used.  And we have no
      idea what the causes the corruption without it.
      Reported-and-tested-by: NM. Vefa Bicakci <bicave@superonline.com>
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd9f040d
  4. 06 7月, 2010 2 次提交
    • C
      drm/i915: Explosion following OOM in do_execbuffer. · 6f772d7e
      Chris Wilson 提交于
      Oops, when merging the extra details following an OOM, I missed that
      driver_private is now NULL and the correct way to convert from the
      drm_gem_object into the drm_i915_gem_object is to use to_intel_bo().
      
      BUG: unable to handle kernel NULL pointer dereference at 00000069
      IP: [<c11a4a02>] i915_gem_do_execbuffer+0x71f/0xbb6
      *pde = 00000000
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/virtual/vc/vcsa3/uevent
      
      Pid: 10993, comm: X Not tainted 2.6.35-rc2+ #67 /
      EIP: 0060:[<c11a4a02>] EFLAGS: 00213202 CPU: 0
      EIP is at i915_gem_do_execbuffer+0x71f/0xbb6
      EAX: f647e8a8 EBX: 00000000 ECX: 00000003 EDX: 00000000
      ESI: 00424000 EDI: 00000000 EBP: f6508e48 ESP: f6508dd4
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process X (pid: 10993, ti=f6508000 task=f6432880 task.ti=f6508000)
      Stack:
       f6508de0 f7130000 00000001 00000000 00000000 f647e8a8 00000000 f64f8480
      <0> f7974414 00000000 00000006 00000000 00000000 f6578000 00000008 00000006
      <0> f6797880 00400000 00000000 ffffffe4 f7974400 000000d0 000000d0 000001c0
      Call Trace:
       [<c11a4f3a>] ? i915_gem_execbuffer2+0xa1/0xe7
       [<c118ab96>] ? drm_ioctl+0x22c/0x2fa
       [<c11a4e99>] ? i915_gem_execbuffer2+0x0/0xe7
       [<c107e88c>] ? do_sync_read+0x8f/0xca
       [<c1088cbd>] ? vfs_ioctl+0x2c/0x96
       [<c118a96a>] ? drm_ioctl+0x0/0x2fa
       [<c10891f4>] ? do_vfs_ioctl+0x429/0x45a
       [<c107e5c9>] ? fsnotify_access+0x54/0x5f
       [<c107ee1c>] ? vfs_read+0x9a/0xae
       [<c1089258>] ? sys_ioctl+0x33/0x4d
       [<c1002610>] ? sysenter_do_call+0x12/0x26
      Code: d0 89 4d c4 31 c9 89 45 d8 eb 44 8b 45 cc 8b 14 88 8b 42 50 89 45
      bc 8b 45 a0 8b 52 38 89 55 d0 31 d2 f6 40 20 01 74 0d 8b 55 bc <f6> 42
      69 30 0f 95 c2 0f b6 d2 8b 45 d0 c7 45 d4 00 00 00 00 89
      EIP: [<c11a4a02>] i915_gem_do_execbuffer+0x71f/0xbb6 SS:ESP 0068:f6508dd4
      CR2: 0000000000000069
      ---[ end trace 3f1d514b34d39381 ]---
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      6f772d7e
    • T
      gpu/drm/i915: Add a blacklist to omit modeset on LID open · 1073af33
      Thomas Bächler 提交于
      On some machines (currently only the Toshiba Tecra A11 is known), the GPU
      locks up when modeset is forced on LID open. This patch adds a new DMI
      blacklist and omits modesetting for all matches.
      
      Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15550Signed-off-by: NThomas Bächler <thomas@archlinux.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      1073af33
  5. 02 7月, 2010 9 次提交
  6. 19 6月, 2010 2 次提交
  7. 15 6月, 2010 2 次提交
  8. 09 6月, 2010 1 次提交
  9. 08 6月, 2010 2 次提交
  10. 06 6月, 2010 1 次提交
  11. 05 6月, 2010 2 次提交
    • A
      drm/i915/gen4: Fix interrupt setup ordering · c496fa1f
      Adam Jackson 提交于
      Unmask, then enable interrupts, then enable interrupt sources; matches
      PCH ordering.  The old way (sources, enable, unmask) gives a window
      during which interrupt conditions would appear in ISR but would never
      reach IIR and thus never raise an IRQ.  Since interrupts only trigger
      on rising edges in ISR, this would lead to conditions where (for
      example) output hotplugging would never fire an interrupt because it
      was already stuck on in ISR.
      
      Also, since we know IIR and PIPExSTAT have been cleared during
      irq_preinstall, don't clear them again during irq_postinstall, nothing
      good can come of that.
      Signed-off-by: NAdam Jackson <ajax@redhat.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      c496fa1f
    • D
      drm/i915: Use RSEN instead of HTPLG for tfp410 monitor detection. · f458823b
      Dave Müller 提交于
      Presence detection of a digital monitor seems not to be reliable using
      the HTPLG bit.
      
      Dave Müller <dave.mueller@gmx.ch>
      f458823b
  12. 03 6月, 2010 2 次提交
  13. 02 6月, 2010 1 次提交