Suspend/resume : Fault errors on pipe A

[abishai]

I have Dell XPS13 Skylake laptop. FreeBSD booted with UEFI. I cloned 11-STABLE drm46 branch and Xorg works like a charm.

To my surprise, suspend/resume have signs of work as well. However, after resume, screen filled with vertical lines of different colors. After sshing, I saw logs filled with Aug 14 16:13:12 testbsd kernel: : 0x00000880[drm:0xffffffff82a46086s] *ERROR* Fault errors on pipe A Aug 14 16:13:12 testbsd kernel: : 0x00000880[drm:0xffffffff82a46086s] *ERROR* Fault errors on pipe A Aug 14 16:13:12 testbsd kernel: : 0x00000080[drm:0xffffffff82a46086s] *ERROR* Fault errors on pipe A Aug 14 16:13:12 testbsd last message repeated 41 times errors. I found similar thread in Arch forums and it was resolved with drm patching. https://bbs.archlinux.org/viewtopic.php?id=206394

If you need additional info, please tell, I'l provide it.

[mattmacy]

Weird, I don't understand how that fix wouldn't be in 4.6 which came out in may. Nonetheless, I'll merge it in if I can find it in Torvalds' tree.

Thanks.

[mattmacy]

Can you try and apply the following? I found the commit referenced by the issue referenced by the issue:

commit 39d9b85a4d4fa1642663ca0d208b5c246a3d6f50 Author: Gary Wang gary.c.wang@intel.com Date: Fri Aug 28 16:40:34 2015 +0800

drm/i915: set CDCLK if DPLL0 enabled during resuming from S3

Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.

References: https://bugs.freedesktop.org/show_bug.cgi?id=91697
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com>
Tested-by: Gary Wang <gary.c.wang@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Xiong Y Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Gary Wang <gary.c.wang@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 53f5476..8ea9821 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5712,16 +5712,13 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
        /* enable PG1 and Misc I/O */
        intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);

-       /* DPLL0 already enabed !? */
-       if (I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE) {
-               DRM_DEBUG_DRIVER("DPLL0 already running\n");
-               return;
+       /* DPLL0 not enabled (happens on early BIOS versions) */
+       if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
+               /* enable DPLL0 */
+               required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
+               skl_dpll0_enable(dev_priv, required_vco);
        }

-       /* enable DPLL0 */
-       required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
-       skl_dpll0_enable(dev_priv, required_vco);
-
        /* set CDCLK to the frequency the BIOS chose */
        skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);

[mattmacy]

I see the problem. We're always calling pci_default_resume and skylake needs special handling.

[abishai]

Looks like it was merged. https://github.com/FreeBSDDesktop/freebsd-base-graphics/blob/drm-next-4.6-11-STABLE/sys/dev/drm2/i915/intel_display.c#L5813

[mattmacy]

Yes. The driver needs to call a driver specific resume.

[mattmacy]

Actually, it does - unclear what's going wrong on skylake. When I get time I'll try instrumenting that path. Or you could do so...

[abishai]

https://gist.github.com/abishai/3c14811c74734e1c830d324a49d5c795 here is log with boot, suspend and resume. Actually, I see strange errors from nvme driver as well, however SSD is working after resume.

[abishai]

And not all firmwares are loaded : Aug 16 20:48:07 testbsd kernel: i915/skl_dmc_ver1.bin: could not load firmware image, error 2

[mattmacy]

@abishai usually the firmware loads anyway. That's an artifact of the firmware(9) API being somewhat rubbish plus the names not lining up so I try loading different names. On the off chance it doesn't load it only reduces the driver's ability to do power management on SKL.

[jongmin-lee]

Hello I've also confronted this issue. I've checked the Linux's issue solved by the patch and merged to our branch already. Linux's issue has same symptom of ours but the reason is somewhat different. Linux's issue has an error code of 0x00000000, while ours has an error code of 0x00000080 that is GEN9_PIPE_PLANE1_FAULT. (0x00000000 is a ridiculous value and seems to be masked. )

I feel strange about the address of error message that should be a function name that print the error message like [drm:gen8_irq_handler [i915]] . How can't the logger get the symbol of function? I suspect abnormal function call or failed symbol loading but i can't be sure. I'm debugging this issue for 2 weeks. Someone who solved the issue help me plz

[jongmin-lee]

My suspect is wrong. DRM_ERROR macro just prints the address of function in the FreeBSDDesktop kernel. Anyway I see the resume sequence breaks before the driver calls any resume functions and cannot reach the function of skl_init_cdclk which is the reason of the symptom in Linux. This problem is not related with the drm-patch at all.

[yanko-yankulov]

Hi guys,

Just confirmed - the patch I posted in #111 solves this exact issue for me.

[mattmacy]

Fixed