Re: somewhat important inteldrm fix
Running the updated xf86-video-intel driver uncovered a bug in the
kernel drm code. The page fault handler wasn't handling some of the
possible errors correctly. This made the X server die with a SIGSEGV.
The diff below brings things closer to what Linux does, and seems to
fix the crashes I was seeing. A bit more testing would be welcome
though. Note that this needs the commit to drmP.h I just made, which
might not have made it to all the anoncvs servers yet.
Index: i915_gem.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem.c,v
retrieving revision 1.68
diff -u -p -r1.68 i915_gem.c
--- i915_gem.c2 Feb 2014 10:54:10 - 1.68
+++ i915_gem.c4 Feb 2014 22:47:53 -
@@ -1522,6 +1522,7 @@ i915_gem_fault(struct drm_gem_object *ge
NULL, NULL);
DRM_UNLOCK();
dev_priv-entries--;
+ pmap_update(ufi-orig_map-pmap);
uvm_wait(intelflt);
return (VM_PAGER_REFAULT);
}
@@ -1533,18 +1534,42 @@ unlock:
DRM_UNLOCK();
dev_priv-entries--;
pmap_update(ufi-orig_map-pmap);
- if (ret == -EIO) {
+
+ switch (ret) {
+ case -EIO:
+ /* If this -EIO is due to a gpu hang, give the reset code a
+ * chance to clean up the mess. Otherwise return the proper
+ * SIGBUS. */
+ if (!atomic_read(dev_priv-mm.wedged))
+ return VM_PAGER_ERROR;
+ case -EAGAIN:
+ /* Give the error handler a chance to run and move the
+ * objects off the GPU active list. Next time we service the
+ * fault, we should be able to transition the page into the
+ * GTT without touching the GPU (and so avoid further
+ * EIO/EGAIN). If the GPU is wedged, then there is no issue
+ * with coherency, just lost writes.
+ */
+#if 0
+ set_need_resched();
+#endif
+ case 0:
+ case -ERESTART:
+ case -EINTR:
+ case -EBUSY:
/*
- * EIO means we're wedged, so upon resetting the gpu we'll
- * be alright and can refault. XXX only on resettable chips.
+ * EBUSY is ok: this just means that another thread
+ * already did the job.
*/
- ret = VM_PAGER_REFAULT;
- } else if (ret) {
- ret = VM_PAGER_ERROR;
- } else {
- ret = VM_PAGER_OK;
+ return VM_PAGER_OK;
+ case -ENOMEM:
+ return VM_PAGER_ERROR;
+ case -ENOSPC:
+ return VM_PAGER_ERROR;
+ default:
+ WARN_ONCE(ret, unhandled error in i915_gem_fault: %i\n, ret);
+ return VM_PAGER_ERROR;
}
- return ret;
}
/**
Thanks, this works good for me too -- no X segfaults anymore.
Re: inteldrm diff
Thanks to Stefan Wollny, I now have a GM45-based system. It seems to work quite well. I'm still trying to figure out the (minor) screen corruption that happens in gnome, but after the latest set of changes I've not been able to make it hang in anyway. So that means the only generation of Intel graphics that jsg@ and I are still missing is the Intel 5/3400 Series chipset that goes together with the 1st generation Core i3/i5 processors. This shows up in dmesg as: pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02 together with lots of Intel 3400 devices. If anybody has a laptop from that generation (x201, t410 for us thinkpad addicts) they are willing to donate, please let us know. Thanks to all involved developers and hardware donators especially Mark Kettenis, Stefan Sperling and Stefan Wollny. The problem is now really fixed by this commit: http://marc.info/?l=openbsd-cvsm=138637060322724w=2
Re: inteldrm diff
I tried this diff and at least one thing changed -- neverball now works (previously it immediately hung the GPU on start). There is still corruption and GPU hanging in chromium. There is corruption in mplayer -vo gl too (and it is still much slower than it is on 5.4). With a lot of help from Stefan Sperling I tried to do experiments. Since I am too unskilled I was not able to do it properly and build xenocara from the same point in time (date-based CVS checkouts do not compile for me) but I built kernel on 5.3 from 2013-07-06 with just this patch applied: http://freshbsd.org/commit/openbsd/304417ea27d0874895cc4e65c30324b7bd14ac22 (as I am 80% sure it's when problems started) and the screen became totally corrupted in X but computer did not hang. It looked very similar to what is seen now. If that helps that is all I could find out.
Re: inteldrm(4) diff
I just tried this. It gives a blank screen while booting (after initalizing inteldrm). Nothing shows up on screen, but system does not hang.
Re: inteldrm(4) diff
The second one works better -- it now shows the picture, but GPU hangs anyway.
