It looks like bug #101343 is back with a vengeance on the XPS 9350 on Kernel 5.2. After a few seconds of inactivity, the screen freezes but does not thaw even after moving the mouse or "creating movement" of any sort on the screen. The only way is to lock/unlock the screen and then I can get a few seconds of use. enable_psr=0 fixes the issue.
Please check if the bug still happens with drm-tip if so attach logs for us.
If the problem persists with drmtip (https://cgit.freedesktop.org/drm-tip) attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Created attachment 144732 [details] dmesg with drm-intel I was able to reproduce the issue with drm-tip, although not immediately, I had to reboot a couple of times and then it happened.
command line was: cryptdevice=UUID=68647d07-0bc2-4bab-be88-36888b168e82:lvm:allow-discards resume=UUID=fe0174cf-695f-4056-9bdf-372598105b7c root=UUID=c0f2d8c0-eb57-4740-92d9-0087085f1e23 rw i915.fastboot=1 i915.enable_guc=1 intel_iommu=igfx_off nvme_core.default_ps_max_latency_us=200000 i915.enable_psr=1 drm.debug=0x1e log_buf_len=4M kvm-intel.vmentry_l1d_flush=never mitigations=off fbcon=font:TER16x32 elevator=bfq quiet splash environment is Gnome/Wayland on Arch.
Thanks François Nothing useful on the drm-tip dmesg =/ but as you said it is hard to reproduce on drm-tip so lets first check what needs to be cherry-picked from drm-tip to kernel 5.2, can you also attach dmesg logs of it? i915.fastboot=1 and i915.enable_psr=1 are the default options, you don't need to set those anymore.
Created attachment 144747 [details] dmesg with 5.2
Bug Report from Arch Linux: https://bugs.archlinux.org/task/63159
Also see this conversation on LKML: https://lkml.org/lkml/2019/7/10/834
Created attachment 144767 [details] [review] hack patch Hi could you try with the attached patch? And if the issue happens again could you share the output of this files? /sys/kernel/debug/dri/0/i915_edp_psr_status /sys/kernel/debug/dri/0/i915_display_info /sys/kernel/debug/dri/0/i915_dmc_info /sys/kernel/debug/dri/0/eDP-1/i915_psr_sink_status Thanks
attachment 144767 [details] [review] seems to fix/work around the issue on drm-tip
In case that's still helpful: # cat /sys/kernel/debug/dri/0/i915_display_info CRTC info --------- CRTC 48: pipe: A, active=yes, (size=3200x1800), dither=no, bpp=24 fb: 87, pos: 0x0, size: 3200x1800 encoder 85: type: DDI A, connectors: connector 86: type: eDP-1, status: connected, mode: "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa cursor visible? yes, position (450, 1196), size 256x256, addr 0x077c0000 num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0 --Plane id 31: type=PRI, crtc_pos= 0x 0, crtc_size=3200x1800, src_pos=0.0000x0.0000, src_size=3200.0000x1800.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001) --Plane id 38: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001) --Plane id 45: type=CUR, crtc_pos= 450x1196, crtc_size= 256x 256, src_pos=0.0000x0.0000, src_size=256.0000x256.0000, format=AR24 little-endian (0x34325241), rotation=0 (0x00000001) underrun reporting: cpu=yes pch=yes CRTC 66: pipe: B, active=no, (size=1920x1080), dither=no, bpp=24 underrun reporting: cpu=yes pch=yes CRTC 84: pipe: C, active=no, (size=0x0), dither=no, bpp=0 underrun reporting: cpu=yes pch=yes Connector info -------------- connector 86: type eDP-1, status: connected physical dimensions: 290x170mm subpixel order: Unknown CEA rev: 0 DPCD rev: 12 audio support: no fixed mode: "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa DP branch device present: no modes: "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa connector 92: type DP-1, status: disconnected connector 99: type HDMI-A-1, status: disconnected connector 105: type DP-2, status: disconnected connector 110: type HDMI-A-2, status: disconnected # cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink support: yes [0x01] PSR mode: PSR1 enabled Source PSR ctl: enabled [0x81f00626] Source PSR status: IDLE [0x04050006] Busy frontbuffer bits: 0x00000000 # cat /sys/kernel/debug/dri/0/i915_dmc_info fw loaded: yes path: i915/skl_dmc_ver1_27.bin version: 1.27 DC3 -> DC5 count: 6 DC5 -> DC6 count: 0 program base: 0x09004040 ssp base: 0x00002fc0 htp: 0x00b40068 # cat /sys/kernel/debug/dri/0/eDP-1/i915_psr_sink_status Sink PSR status: 0x2 [active, display from RFB]
Would it be possible to provide the contents of the same debugfs files on a working kernel(5.1) ? Changes to "Source PSR ctl" and DMC version will be particularly interesting.
(In reply to Jose Roberto de Souza from comment #5) > Thanks François > > Nothing useful on the drm-tip dmesg =/ but as you said it is hard to > reproduce on drm-tip so lets first check what needs to be cherry-picked from > drm-tip to kernel 5.2, can you also attach dmesg logs of it? > > i915.fastboot=1 and i915.enable_psr=1 are the default options, you don't > need to set those anymore. I'd say it is important to not set i915.enable_psr=1 as it overrides VBT defaults. i915.enable_psr=1 makes the driver enable PSR even if the VBT asks it not to.
I’m also affected by lock-up since upgrading to 5.2. Disabling PSR seems to fix the issue. Of course I would prefer PSR to work. :) (In reply to Dhinakaran Pandiyan from comment #12) > Would it be possible to provide the contents of the same debugfs files on a > working kernel(5.1) ? > > Changes to "Source PSR ctl" and DMC version will be particularly interesting. PSR was disabled on 5.1 (it was enabled by https://patchwork.freedesktop.org/patch/290920/), so not sure if that would really be interesting. But I can downgrade and report if you still think this can be useful.
Or should I try 5.1 while manually enabling PSR?
Just to make sure that this is not missed: My KBL system is also affected, so it's not just SKL that has this issue.
(In reply to Dhinakaran Pandiyan from comment #12) > Would it be possible to provide the contents of the same debugfs files on a > working kernel(5.1) ? > > Changes to "Source PSR ctl" and DMC version will be particularly interesting. Hello, First, even on drm-tip, Source PSR status fluctuates between IDLE [0x04020006] and SRDENT [0x40040006]. For kernel < 5.2, I'll need another machine to ssh from while the screen is frozen... bear with me.
(In reply to Bruno Pagani from comment #14) > I’m also affected by lock-up since upgrading to 5.2. Disabling PSR seems to > fix the issue. Of course I would prefer PSR to work. :) > > (In reply to Dhinakaran Pandiyan from comment #12) > > Would it be possible to provide the contents of the same debugfs files on a > > working kernel(5.1) ? > > > > Changes to "Source PSR ctl" and DMC version will be particularly interesting. > > PSR was disabled on 5.1 (it was enabled by > https://patchwork.freedesktop.org/patch/290920/), so not sure if that would > really be interesting. But I can downgrade and report if you still think > this can be useful. No, PSR1 was enabled by default since 5.0, PSR2 was enabled by default on 5.2.
(In reply to taijian from comment #16) > Just to make sure that this is not missed: My KBL system is also affected, > so it's not just SKL that has this issue. Thanks, updating the bug
(In reply to François Guerraz from comment #17) > (In reply to Dhinakaran Pandiyan from comment #12) > > Would it be possible to provide the contents of the same debugfs files on a > > working kernel(5.1) ? > > > > Changes to "Source PSR ctl" and DMC version will be particularly interesting. > > Hello, > > First, even on drm-tip, Source PSR status fluctuates between IDLE > [0x04020006] and SRDENT [0x40040006]. > > For kernel < 5.2, I'll need another machine to ssh from while the screen is > frozen... bear with me. That is okay this floating, if you can please share the whole output of /sys/kernel/debug/dri/0/i915_edp_psr_status with kernel 5.1.
Created attachment 144803 [details] [review] solution patch Could you revert the hack patch if you applied and apply this patch and let me know if it worked before we merge this fix? Thanks
Experiment 2: Apply this patch on drm-tip https://patchwork.freedesktop.org/patch/318389/?series=63774&rev=1
Both the revised patches for 5.2 and drm-tip seem to work on my machine.
(In reply to François Guerraz from comment #23) > Both the revised patches for 5.2 and drm-tip seem to work on my machine. Good to know. Do you mind replying to the mailing list with a tested-by tag?
(In reply to Dhinakaran Pandiyan from comment #24) > (In reply to François Guerraz from comment #23) > > Both the revised patches for 5.2 and drm-tip seem to work on my machine. > > Good to know. Do you mind replying to the mailing list with a tested-by tag? François, can you please respond on this?
As you can see, the latest revision of the patch has my tested-by tag. https://patchwork.freedesktop.org/patch/319173/?series=63774&rev=4
Fix merged on Linux 5.2.8
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.