My Intel GMA HD 4000 on Lenovo IdeaPad S400 with the latest VT, drm2 and i915kms from 10-STABLE can't resume properly because AIGLX fails to wake up. Of course, the graphics after it non-usable or horribly corrupted, like here: http://i327.photobucket.com/albums/k477/ivan_rokotov_bsd/2_zpsd7564e4b.png I found this patch, which solved the problem completely: http://lists.freebsd.org/pipermail/freebsd-x11/2013-October/013727.html Now, I can resome, and have this in X log after it: [ 4561.749] (WW) intel(0): retrying batchbuffer submit [ 4561.803] (WW) intel(0): retrying batchbuffer submit [ 4561.857] (WW) intel(0): retrying batchbuffer submit [ 4561.908] (WW) intel(0): retrying batchbuffer submit [ 4561.959] (WW) intel(0): retrying batchbuffer submit [ 4562.012] (WW) intel(0): retrying batchbuffer submit [ 4562.063] (WW) intel(0): retrying batchbuffer submit [ 4562.117] (WW) intel(0): retrying batchbuffer submit [ 4562.171] (WW) intel(0): retrying batchbuffer submit [ 4562.225] (WW) intel(0): retrying batchbuffer submit [ 4562.279] (WW) intel(0): retrying batchbuffer submit [ 4562.333] (WW) intel(0): retrying batchbuffer submit [ 4562.386] (WW) intel(0): retrying batchbuffer submit [ 4562.439] (WW) intel(0): retrying batchbuffer submit [ 4562.493] (WW) intel(0): retrying batchbuffer submit [ 4562.547] (WW) intel(0): retrying batchbuffer submit [ 4564.779] (II) AIGLX: Suspending AIGLX clients for VT switch [ 4564.779] (WW) intel(0): drmDropMaster failed: Unknown error: -22 [ 4565.994] (II) AIGLX: Resuming AIGLX clients after VT switch [ 4566.096] (II) intel(0): EDID vendor "CMN", prod id 5239 [ 4566.096] (II) intel(0): Printing DDC gathered Modelines: [ 4566.096] (II) intel(0): Modeline "1366x768"x0.0 71.59 1366 1410 1439 1512 768 771 775 789 -hsync -vsync (47.3 kHz eP) but everything is alive: compiz restarts correctly, GL applications work as they did before resume. This is very stable, I suspended/resumed my notebook more than ten times for 4-5 days (without shutting down) - and it works. The ret value obtained with this code xf86DrvMsg(scrn->scrnIndex, X_WARNING, "retrying batchbuffer submit, ret=%d\n", ret); is: [ 8572.583] (WW) intel(0): retrying batchbuffer submit, ret=-16 Fix: The retry hack proposed by Jan Kokemüller <jan.kokemueller@gmail.com> here http://lists.freebsd.org/pipermail/freebsd-x11/2013-October/013727.html solves the problem. How-To-Repeat: Install FreeBSD with the latest VT code on Lenovo IdeaPad S400 and try to do suspend/resume from X.
I forgot to add here how the system fails to restart without the aforementioned patch. With AIGLX activated, I get this horrible corruption: http://i327.photobucket.com/albums/k477/ivan_rokotov_bsd/2_zpsd7564e4b.png and no moving or switching to console help. No GL application starts. I also found this in the X log after resume: [ 1173.617] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption: Device busy. (II) AIGLX: Suspending AIGLX clients for VT switch [ 1173.663] (WW) intel(0): drmDropMaster failed: Unknown error: -22 [ 1177.289] (II) AIGLX: Resuming AIGLX clients after VT switch [ 1177.340] (II) intel(0): EDID vendor "CMN", prod id 5239 [ 1177.340] (II) intel(0): Printing DDC gathered Modelines: [ 1177.340] (II) intel(0): Modeline "1366x768"x0.0 71.59 1366 1410 1439 1512 768 771 775 789 -hsync -vsync (47.3 kHz eP)
(This is on Lenovo IdeaPad S400 as in the case of original poster.)
Created attachment 155303 [details] xf86-video-intel batch buffer retry patch It would be great if the simple patch by Jan Kokemüller that Ivan points to could be added to x11-drivers/xf86-video-intel/files! I'm attaching that patch for easy access. I have been using this patch on a TP X201 for quite some time.
https://lists.freebsd.org/pipermail/freebsd-x11/2015-December/017055.html suggests special attention to this bug. I can't comment on Intel GMA HD, https://forums.freebsd.org/threads/suspend-resume-problem.13311/#post-307411 describes a workaround that's applicable with PC-BSD 11.0-CURRENT with an Intel HD Graphics 5500, but the symptom there is blackness (not corruption) on resume.
Hi! Is this still an issue with an updated xorg stack, possibly also using drm-next-kmod?
(In reply to Niclas Zeising from comment #5) Not an issue for me since quite some time with a newer xorg stack (possibly also due to upgrading to 10.x from 9.x).
Closing this, submitter says the issue is fixed.