> > BTW, if anyone uses softdep *you have to tell me*, and then try
> > to repeat problems you encounter without softdep. That is a
> > totally different problem set.
> Yes, I am using softdep.
I am not concerned with the softdep case. softdep needs a maintainer,
and it isn't me. I'll provide hints for how to debug this though:
First apply the following diff to the tree. This will keep the screen
alive during the suspend cycle. On some inteldrm chipsets it will
fail to resume afterwards, however. On x230 this works, newer models
cannot handle this hack. Anyways the goal is is to observe why it
isn't suceeding at completing the suspend sync.
Having the screen alive makes it possible to add printf's to the ffs
softdep code, in particular softdep_sync_metadata() and such
functions. Figure out what the code is doing keeping so busy. Why
does it keep doing IO? Is it writing data blocks for files? Is it
repeatedly updating the same metadata?
For this suspend case, the sync functions are being called with various
_WAIT flags instead of _NOWAIT or _LAZY. It is being asked to achieve
stability. What stops it from achieving stability? When you read the
code in the area you'll be shocked at the comments. Try to figure
out which cases are occurring.
Anyone with rudimentary C skills and patience can do this. (But I
won't be doing it, I have other things to do)
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.108
diff -u -p -u -r1.108 i915_drv.c
--- i915_drv.c 30 Sep 2017 07:36:56 -0000 1.108
+++ i915_drv.c 21 Dec 2017 05:52:54 -0000
@@ -673,6 +673,8 @@ static int i915_drm_suspend(struct drm_d
+ return 0;
/* ignore lid events during suspend */
dev_priv->modeset_restore = MODESET_SUSPENDED;
@@ -745,6 +747,8 @@ static int i915_drm_suspend_late(struct
struct drm_i915_private *dev_priv = drm_dev->dev_private;
+ return 0;
ret = intel_suspend_complete(dev_priv);