On Sat, Jul 20, 2019 at 10:32:46PM +1000, open...@rlr.id.au wrote: > >Synopsis: X11 graphics not working in snapshots on Braswell system > >Category: amd64 > >Environment: > System : OpenBSD 6.5 > Details : OpenBSD 6.5-current (GENERIC.MP) #131: Fri Jul 19 > 13:18:29 MDT 2019 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > Under 6.5 (release plus syspatches), X11 works with the default > configuration. Over the last several weeks, I've been trying > snapshots, and none has worked correctly: > - With the default configuration, the box usually switches to screen 4 > but displays nothing, and becomes unresponsive to keyboard, mouse, > and pings, therefore requiring hard reset. Without xenodm enabled > in /etc/rc.conf.local, using > rcctl -f start xenodm; sleep 120; rcctl -f stop xenodm > the system survived the most recent test without full lockup. > See below for relevant logs. > - Forcing the Intel driver using a configuration file, things do work > somewhat, but glxinfo/glxgears give errors. > See below for relevant logs. > >How-To-Repeat: > Start X11 without a configuration file. > >Fix: > Unknown.
Does this backport from linux help? Taken From commit 8cd999181f8c744c87fb64e7b3600876ec3428b2 Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Mon Jan 14 21:17:27 2019 +0000 drm/i915: Prevent concurrent GGTT update and use on Braswell (again) On Braswell, under heavy stress, if we update the GGTT while simultaneously accessing another region inside the GTT, we are returned the wrong values. To prevent this we stop the machine to update the GGTT entries so that no memory traffic can occur at the same time. This was first spotted in commit 5bab6f60cb4d1417ad7c599166bcfec87529c1a2 Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Fri Oct 23 18:43:32 2015 +0100 drm/i915: Serialise updates to GGTT with access through GGTT on Braswell but removed again in forlorn hope with commit 4509276ee824bb967885c095c610767e42345c36 Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Mon Feb 20 12:47:18 2017 +0000 drm/i915: Remove Braswell GGTT update w/a However, gem_concurrent_blit is once again only stable with the patch applied and CI is detecting the odd failure in forked gem_mmap_gtt tests (which smell like the same issue). Fwiw, a wide variety of CPU memory barriers (around GGTT flushing, fence updates, PTE updates) and GPU flushes/invalidates (between requests, after PTE updates) were tried as part of the investigation to find an alternate cause, nothing comes close to serialised GGTT updates. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105591 Testcase: igt/gem_concurrent_blit Testcase: igt/gem_mmap_gtt/*forked* References: 5bab6f60cb4d ("drm/i915: Serialise updates to GGTT with access through GGTT on Braswell") References: 4509276ee824 ("drm/i915: Remove Braswell GGTT update w/a") Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114211729.30352-1-ch...@chris-wilson.co.uk Index: sys/dev/pci/drm/i915/i915_gem_gtt.c =================================================================== RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem_gtt.c,v retrieving revision 1.17 diff -u -p -r1.17 i915_gem_gtt.c --- sys/dev/pci/drm/i915/i915_gem_gtt.c 14 Apr 2019 10:14:51 -0000 1.17 +++ sys/dev/pci/drm/i915/i915_gem_gtt.c 21 Jul 2019 09:21:02 -0000 @@ -3543,7 +3543,8 @@ static int gen8_gmch_probe(struct i915_g ggtt->vm.insert_entries = gen8_ggtt_insert_entries; /* Serialize GTT updates with aperture access on BXT if VT-d is on. */ - if (intel_ggtt_update_needs_vtd_wa(dev_priv)) { + if (intel_ggtt_update_needs_vtd_wa(dev_priv) || + IS_CHERRYVIEW(dev_priv) /* fails with concurrent use/update */) { ggtt->vm.insert_entries = bxt_vtd_ggtt_insert_entries__BKL; ggtt->vm.insert_page = bxt_vtd_ggtt_insert_page__BKL; if (ggtt->vm.clear_range != nop_clear_range)