Bug 112143

Summary: Built-in display corrupted after wake-up from S3 on Dell XPS 7390 2-in-1 (Ice Lake)
Product: DRI Reporter: Andreas Kloeckner <inform>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: RESOLVED INVALID QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: alex.zuo, imre.deak, intel-gfx-bugs, yang.a.shi
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard: Triaged
i915 platform: ICL i915 features:

Description Andreas Kloeckner 2019-10-27 19:13:58 UTC
I have a Dell XPS 7390 2-in-1, which use a "Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz". While the machine defaults to s2idle, energy consumption in that state is high, which led me to investigate S3 sleep, enabled by

echo deep|sudo tee /sys/power/mem_sleep

This works well, except for one annoying showstopper wrinkle: The machine's built-in display remains on a corrupted version of the Dell logo after wake-up. All other aspects of the machine (including externally attached displays) resume entirely fine, but the internal display remains garbled until a reset or power cycle.

I've recorded a video to better convey what's happening:

https://ssl.tiker.net/nextcloud/s/jZQjjgjT2EwedBe

Notably, the pixel pattern in the corrupted logo *does* change in response to interactions with the system, meaning that likely *some* part of the framebuffer is being shown, but display state is not sufficiently reset to enable proper display function.

Linux lightning 5.4.0-rc5 #1 SMP Sun Oct 27 12:56:36 CDT 2019 x86_64 GNU/Linux

-- Linux distribution:

  Debian testing/unstable

-- Machine or mother board model:

  From dmidecode:

  Handle 0x0100, DMI type 1, 27 bytes
  System Information
          Manufacturer: Dell Inc.
          Product Name: XPS 13 7390 2-in-1
          Version: Not Specified
          Serial Number: (redacted)
          UUID: (redacted)
          Wake-up Type: Power Switch
          SKU Number: 08B0
          Family: XPS
  
  Handle 0x0200, DMI type 2, 17 bytes
  Base Board Information
          Manufacturer: Dell Inc.
          Product Name: 06CDVY
          Version: A00
          Serial Number: (redacted)
          Asset Tag: Not Specified
          Features:
                  Board is a hosting board
                  Board is replaceable
          Location In Chassis: Not Specified
          Chassis Handle: 0x0000
          Type: Motherboard
          Contained Object Handles: 0
  
-- Display connector: (such as HDMI, DP, eDP, ...)

  Output of xrandr --verbose:
  https://gist.github.com/inducer/169409e85ee9a8999a7834f401558146

-- Register dumps before/after S3:

  https://gist.github.com/inducer/346c05cc9331c68213cda51e9bdbf7cc

-- Other version info

  https://gist.github.com/inducer/e51bb5bbfca3f307066b375b062e939d
Comment 1 Andreas Kloeckner 2019-10-27 19:33:01 UTC
Here's a dmesg log with drm.debug=0x1e in case that's helpful:

https://gist.github.com/inducer/c0b8630adbdf4b9c0dae6c9f01819854
Comment 2 Zuo Alex 2019-10-29 06:17:10 UTC
now we did not have the Dell XPS 7390 2-in-1 . we are trying on another Dell desktop(ice lake)with the same kernel release . Will keep you post . thanks .
Comment 3 Lakshmi 2019-10-29 15:44:12 UTC
(In reply to Andreas Kloeckner from comment #0)
> I have a Dell XPS 7390 2-in-1, which use a "Intel(R) Core(TM) i7-1065G7 CPU
> @ 1.30GHz". While the machine defaults to s2idle, energy consumption in that
> state is high, which led me to investigate S3 sleep, enabled by
> 
> echo deep|sudo tee /sys/power/mem_sleep
> 
> This works well, except for one annoying showstopper wrinkle: The machine's
> built-in display remains on a corrupted version of the Dell logo after
> wake-up. All other aspects of the machine (including externally attached
> displays) resume entirely fine, but the internal display remains garbled
> until a reset or power cycle.
> 
> I've recorded a video to better convey what's happening:
> 
> https://ssl.tiker.net/nextcloud/s/jZQjjgjT2EwedBe
> 
> Notably, the pixel pattern in the corrupted logo *does* change in response
> to interactions with the system, meaning that likely *some* part of the
> framebuffer is being shown, but display state is not sufficiently reset to
> enable proper display function.
> 
> Linux lightning 5.4.0-rc5 #1 SMP Sun Oct 27 12:56:36 CDT 2019 x86_64
> GNU/Linux
> 
> -- Linux distribution:
> 
>   Debian testing/unstable
> 
> -- Machine or mother board model:
> 
>   From dmidecode:
> 
>   Handle 0x0100, DMI type 1, 27 bytes
>   System Information
>           Manufacturer: Dell Inc.
>           Product Name: XPS 13 7390 2-in-1
>           Version: Not Specified
>           Serial Number: (redacted)
>           UUID: (redacted)
>           Wake-up Type: Power Switch
>           SKU Number: 08B0
>           Family: XPS
>   
>   Handle 0x0200, DMI type 2, 17 bytes
>   Base Board Information
>           Manufacturer: Dell Inc.
>           Product Name: 06CDVY
>           Version: A00
>           Serial Number: (redacted)
>           Asset Tag: Not Specified
>           Features:
>                   Board is a hosting board
>                   Board is replaceable
>           Location In Chassis: Not Specified
>           Chassis Handle: 0x0000
>           Type: Motherboard
>           Contained Object Handles: 0
>   
> -- Display connector: (such as HDMI, DP, eDP, ...)
> 
>   Output of xrandr --verbose:
>   https://gist.github.com/inducer/169409e85ee9a8999a7834f401558146
> 
> -- Register dumps before/after S3:
> 
>   https://gist.github.com/inducer/346c05cc9331c68213cda51e9bdbf7cc
> 
> -- Other version info
> 
>   https://gist.github.com/inducer/e51bb5bbfca3f307066b375b062e939d

@Imre, any comments here?
Comment 4 Imre Deak 2019-10-29 16:14:12 UTC
If S3 is not the default state on your machine then I'm not sure we're supporting it.

Could you also send a drm.debug=0x1e log that also contains the suspend/resume sequence messages?

Could you try if you also see the corruption when using the FB console (switching to it when you see the corruption and doing a suspend/resume from the console)?
Comment 5 Yang 2019-10-30 06:10:43 UTC
@Kloeckner 
We tried this issue on Dell Inspiron Ten generation i7-1065G7 with Ubuntu 19.10.
Can't reproduce this display issue.

We also upgrade the kernel to 5.4.0-rc5, still don't reproduce this issue.

Would you like to add i915.enable_psr=0 in cmdline in grub file?
And try to see whether you can reproduce this issue or not?
Thanks.
Comment 6 Andreas Kloeckner 2019-10-31 05:19:35 UTC
Thanks for your help, all!

> If S3 is not the default state on your machine then I'm not sure we're supporting it.

It is not the default. However, S3 support appears perfect aside from this issue--the machine is completely usable after resume on an externally attached screen. Just the internal display does not come back.

> Could you also send a drm.debug=0x1e log that also contains the suspend/resume sequence messages?

The dmesg debug log I sent earlier contained a suspend/resume cycle:

https://gist.github.com/inducer/c0b8630adbdf4b9c0dae6c9f01819854

> Would you like to add i915.enable_psr=0 in cmdline in grub file?

With PSR disabled, the Dell logo does not get corrupted. It just stays in place. However, the content of my desktop still does not reappear on the built-in panel.

> Could you try if you also see the corruption when using the FB console (switching to it when you see the corruption and doing a suspend/resume from the console)?

FB console shows the same symptoms: external display comes back fine, internal display stays on Dell logo (or its corrupted version, depending on PSR state).
Comment 7 Yang 2019-11-01 06:16:17 UTC
@Kloeckner 

Would you like to record a video again after you disable PSR in command line?
i915.enable_psr=0

Thanks.
Comment 8 Yang 2019-11-06 06:11:13 UTC
@Kloeckner 

We use debian bullseye/sid with kernel 5.2.0.
After echo mem > /sys/power/state. And then awaken the system by keyboard.
The built-in display can recovery successfully, but the system hang.

It is not the same issue that you meet.
We still can't reproduce your issue.

Thanks.
Comment 9 Andreas Kloeckner 2019-11-09 21:21:06 UTC
I recorded another video with PSR disabled, see here:

https://ssl.tiker.net/nextcloud/s/8ZBQCMAHB6Hkg3q

Unlike before, the logo does not get corrupted, it just stays there. The machine appears unresponsive, but it is entirely usable from an externally attached display.

Note that I'm now running drm-tip, commit 41eb27f39e60d822edc75e6aaeb416b72bc1dcf2, and I have the required firmware blobs installed. The behavior hasn't changed though.
Comment 10 Andreas Kloeckner 2019-11-10 03:35:54 UTC
Likely a BIOS issue, as it also occurs in Windows, as pointed out by @arek.burdach in https://gitlab.com/emrose/xps13-7390_debian/merge_requests/4#note_242414579.

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.