1. 23 2月, 2010 1 次提交
  2. 16 2月, 2010 1 次提交
  3. 11 2月, 2010 11 次提交
  4. 05 2月, 2010 3 次提交
  5. 30 1月, 2010 4 次提交
  6. 28 1月, 2010 1 次提交
    • C
      drm/i915: Selectively enable self-reclaim · 4bdadb97
      Chris Wilson 提交于
      Having missed the ENOMEM return via i915_gem_fault(), there are probably
      other paths that I also missed. By not enabling NORETRY by default these
      paths can run the shrinker and take memory from the system (but not from
      our own inactive lists because our shrinker can not run whilst we hold
      the struct mutex) and this may allow the system to survive a little longer
      whilst our drivers consume all available memory.
      
      References:
        OOM killer unexpectedly called with kernel 2.6.32
        http://bugzilla.kernel.org/show_bug.cgi?id=14933
      
      v2: Pass gfp into page mapping.
      v3: Use new read_cache_page_gfp() instead of open-coding.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4bdadb97
  7. 26 1月, 2010 5 次提交
    • J
      drm/i915: handle non-flip pending case when unpinning the scanout buffer · de3f440f
      Jesse Barnes 提交于
      The first page flip queued will replace the current front buffer, which
      should have a 0 pending flip count.  So at finish time we need to handle
      that case (i.e. if the flip count is 0 *or* dec_and_test is 0 we need to
      wake the waiters).
      
      Also fix up an error path in the queue function and add some debug
      output (only enabled with driver debugging).
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      de3f440f
    • L
      drm/i915: Fix the device info of Pineview · 8a6c77d6
      Li Peng 提交于
      Pineview doesn't has CXSR and need GTT-based hardware status page.
      It fixes a X boot hung issue on Pinview since commit cfdf1f
      Signed-off-by: NLi Peng <peng.li@intel.com>
      Acked-by: NZhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      8a6c77d6
    • L
      drm/i915: enable vblank interrupt on ironlake · c062df61
      Li Peng 提交于
      so far vblank interrupt on ironlake is disabled, this would cause
      bad gfx performance if userspace calls drm_wait_vblank. This patch
      enables vblank interrupt on ironlake and follows vblank get/put
      model.
      Signed-off-by: NLi Peng <peng.li@intel.com>
      Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      c062df61
    • C
      drm/i915: Prevent use of uninitialized pointers along error path. · 0ce907f8
      Chris Wilson 提交于
      X.org hang with [drm:i915_gem_do_execbuffer] *ERROR* in dmesg
        http://bugzilla.kernel.org/show_bug.cgi?id=15114
      
      Matej found he was hitting an error path within i915_gem_do_execbuffer()
      that led to the attempt to dereference an uninitialised pointer during
      cleanup. This path used to be safe as we used to calloc the object
      lists, but this was changed in c8e0f93a. Daniel Vetter had also spotted
      this error and proposed a similar patch.
      
      [ 6379.732892] [drm:i915_gem_do_execbuffer] *ERROR* Object ffff880098cd6540 appears more than once in object list
      [ 6379.740976] [drm:i915_gem_do_execbuffer] *ERROR* Object ffff880098cd6540 appears more than once in object list
      [ 6379.740995] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
      [ 6379.740998] IP: [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260
      [ 6379.741006] PGD babab067 PUD bb435067 PMD 0
      [ 6379.741010] Oops: 0002 [#1] PREEMPT SMP
      [ 6379.741014] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.2/0000:06:00.0/ieee80211/phy0/rfkill0/state
      [ 6379.741017] CPU 1
      [ 6379.741021] Pid: 2186, comm: X Not tainted 2.6.33-rc4-00399-g24bc7347 #142 M11D/ESPRIMO Mobile M9400
      [ 6379.741023] RIP: 0010:[<ffffffff8122ddb5>] [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260
      [ 6379.741027] RSP: 0018:ffff8800b9047b78  EFLAGS: 00213206
      [ 6379.741029] RAX: 0000000000000000 RBX: 000000000000004f RCX: ffff880098cac800
      [ 6379.741032] RDX: ffff880098caca78 RSI: ffff8800b9047c98 RDI: ffff880098cd6540
      [ 6379.741034] RBP: ffff8800b9047c78 R08: ffffffff814b96b5 R09: 0000000000000006
      [ 6379.741036] R10: 0000000000000000 R11: 0000000000000003 R12: 000000000000004e
      [ 6379.741038] R13: 00000000fffffff7 R14: 0000000000000000 R15: 0000000000000001
      [ 6379.741041] FS:  0000000000000000(0000) GS:ffff880001900000(0063) knlGS:00000000f72636c0
      [ 6379.741043] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      [ 6379.741041] FS:  0000000000000000(0000) GS:ffff880001900000(0063) knlGS:00000000f72636c0
      [ 6379.741043] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      [ 6379.741045] CR2: 00000000000000a0 CR3: 00000000b9000000 CR4: 00000000000006e0
      [ 6379.741048] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 6379.741050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [ 6379.741052] Process X (pid: 2186, threadinfo ffff8800b9046000, task ffff8800bb5d8000)
      [ 6379.741054] Stack:
      [ 6379.741055]  ffffc90023f57000 ffffc90023f56fff ffffc90023f56fff ffffc90023f55000
      [ 6379.741059] <0> ffff8800b9047c98 ffff8800bb43c840 ffff8800bf1de800 ffff8800bf1de820
      [ 6379.741063] <0> ffff8800b9047bd8 ffff880098cac800 0000000000000000 0000000000000002
      [ 6379.741068] Call Trace:
      [ 6379.741072]  [<ffffffff8122e6cb>] ?  i915_gem_execbuffer+0x6b/0x370
      [ 6379.741077]  [<ffffffff810a5f52>] ? __vmalloc_node+0xa2/0xb0
      [ 6379.741080]  [<ffffffff8122e6cb>] ?  i915_gem_execbuffer+0x6b/0x370
      [ 6379.741083]  [<ffffffff8122e816>] i915_gem_execbuffer+0x1b6/0x370
      [ 6379.741086]  [<ffffffff8120cd55>] drm_ioctl+0x1d5/0x460
      [ 6379.741089]  [<ffffffff8122e660>] ?  i915_gem_execbuffer+0x0/0x370
      [ 6379.741093]  [<ffffffff81248c35>] i915_compat_ioctl+0x45/0x50
      [ 6379.741097]  [<ffffffff810f1659>] compat_sys_ioctl+0xa9/0x1570
      [ 6379.741102]  [<ffffffff810b1d5c>] ? vfs_read+0x13c/0x1a0
      [ 6379.741106]  [<ffffffff81028424>] sysenter_dispatch+0x7/0x2b
      [ 6379.741108] Code: 08 85 c0 74 52 31 db 0f 1f 80 00 00 00 00 48 63 c3 48 8b
      8d 68 ff ff ff 48 8d 14 c1 48 8b 02 48 85 c0 74 25 48 8b 80 80 00 00 00 <c7> 80
      a0 00 00 00 00 00 00 00 48 8b 3a 48 85 ff 74 0c 48 c7 c6
      [ 6379.741142] RIP  [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260
      [ 6379.741145]  RSP <ffff8800b9047b78>
      [ 6379.741147] CR2: 00000000000000a0
      [ 6379.741159] ---[ end trace 0598809afa4c31db ]---
      Reported-by: NMatej Laitl <strohel@gmail.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      0ce907f8
    • Z
      drm/i915: disable hotplug detect before Ironlake CRT detect · eceb784c
      Zhenyu Wang 提交于
      This tries to fix CRT detect loop hang seen on some Ironlake form
      factor, to clear up hotplug detect state before taking CRT detect
      to make sure next hotplug detect cycle is consistent.
      
      Cc: Stable Team <stable@kernel.org>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      eceb784c
  8. 16 1月, 2010 8 次提交
  9. 13 1月, 2010 5 次提交
  10. 09 1月, 2010 1 次提交