On Mon, Jul 15, 2013 at 06:07:09PM +0300, [email protected] wrote: > On 15.07.2013 16:07, Jonathan Gray wrote: > >Can you try run a kernel with the following diff? It disables > >powersaving and framebuffer compression and would help > >narrow things down. > > > >Index: i915_drv.c > >=================================================================== > >RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v > >retrieving revision 1.35 > >diff -u -p -r1.35 i915_drv.c > >--- i915_drv.c 5 Jul 2013 07:20:27 -0000 1.35 > >+++ i915_drv.c 15 Jul 2013 12:59:53 -0000 > >@@ -69,7 +69,7 @@ extern struct mutex mchdev_lock; > > int i915_panel_ignore_lid = 1; > > > > /* Enable powersavings, fbc, downclocking, etc. (default: true) */ > >-unsigned int i915_powersave = 1; > >+unsigned int i915_powersave = 0; > > > > /* Use semaphores for inter-ring sync (default: -1 (use per-chip > >defaults)) */ > > int i915_semaphores = -1; > >@@ -78,7 +78,7 @@ int i915_semaphores = -1; > > * Enable frame buffer compression for power savings > > * (default: -1 (use per-chip default)) > > */ > >-int i915_enable_fbc = -1; > >+int i915_enable_fbc = 0; > > > > /* > > * Enable power-saving render C-state 6. > > Thank you for your diff, but unfortunately it does not solve the > problem. Is there anything else I can try? > > Is there a way on OpenBSD to get i915_error_state mentioned in > Xorg.0.log? > > [ 3845.493] (EE) intel(0): When reporting this, please include > i915_error_state from debugfs and the full dmesg.
Here is a diff that is a bit of a guess. We don't have a way to produce something similiar to the i915_error_state files at the moment. https://bugs.freedesktop.org/show_bug.cgi?id=55984#c143 commit 262b6d363fcff16359c93bd58c297f961f6e6273 Author: Chris Wilson <[email protected]> Date: Tue Jan 15 16:17:54 2013 +0000 drm/i915: Invalidate the relocation presumed_offsets along the slow path In the slow path, we are forced to copy the relocations prior to acquiring the struct mutex in order to handle pagefaults. We forgo copying the new offsets back into the relocation entries in order to prevent a recursive locking bug should we trigger a pagefault whilst holding the mutex for the reservations of the execbuffer. Therefore, we need to reset the presumed_offsets just in case the objects are rebound back into their old locations after relocating for this exexbuffer - if that were to happen we would assume the relocations were valid and leave the actual pointers to the kernels dangling, instant hang. Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4 Author: Chris Wilson <[email protected]> Date: Sun Nov 21 22:07:12 2010 +0000 drm/i915: Handle pagefaults in execbuffer user relocations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Index: i915_drv.c =================================================================== RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v retrieving revision 1.35 diff -u -p -r1.35 i915_drv.c --- i915_drv.c 5 Jul 2013 07:20:27 -0000 1.35 +++ i915_drv.c 15 Jul 2013 15:45:04 -0000 @@ -1726,6 +1726,12 @@ i915_gem_get_relocs_from_user(struct drm return (EINVAL); *relocs = drm_alloc(reloc_count * sizeof(**relocs)); for (i = 0; i < buffer_count; i++) { + struct drm_i915_gem_relocation_entry *user_relocs; + u64 invalid_offset = (u64)-1; + int j; + + user_relocs = (void *)(uintptr_t)exec_list[i].relocs_ptr; + if ((ret = copyin((void *)(uintptr_t)exec_list[i].relocs_ptr, &(*relocs)[reloc_index], exec_list[i].relocation_count * sizeof(**relocs))) != 0) { @@ -1733,6 +1739,26 @@ i915_gem_get_relocs_from_user(struct drm *relocs = NULL; return (ret); } + + /* As we do not update the known relocation offsets after + * relocating (due to the complexities in lock handling), + * we need to mark them as invalid now so that we force the + * relocation processing next time. Just in case the target + * object is evicted and then rebound into its old + * presumed_offset before the next execbuffer - if that + * happened we would make the mistake of assuming that the + * relocations were valid. + */ + for (j = 0; j < exec_list[i].relocation_count; j++) { + if (DRM_COPY_TO_USER(&user_relocs[j].presumed_offset, + &invalid_offset, + sizeof(invalid_offset))) { + drm_free(*relocs); + *relocs = NULL; + return (EFAULT); + } + } + reloc_index += exec_list[i].relocation_count; }
