Bug 109760 - [i915 KMS] No screen image after modeset on Intel Atom x5-Z8300
Summary: [i915 KMS] No screen image after modeset on Intel Atom x5-Z8300
Status: NEEDINFO
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-24 10:37 UTC by zvezdin
Modified: 2019-07-15 11:05 UTC (History)
3 users (show)

See Also:
i915 platform: BSW/CHT
i915 features: display/DSI


Attachments
Dmesg on a boot demonstrating the issue (110.74 KB, text/plain)
2019-02-24 10:37 UTC, zvezdin
no flags Details
Intel reg dump on a boot with the issue (96.48 KB, text/plain)
2019-02-24 10:38 UTC, zvezdin
no flags Details
dmesg with i915.fastboot=1 boot (131.00 KB, text/plain)
2019-02-25 09:28 UTC, zvezdin
no flags Details
dmesg with i915.fastboot=1 suspend (38.19 KB, text/plain)
2019-02-25 09:30 UTC, zvezdin
no flags Details
Boot with new kernel into a working graphical environment (1011.98 KB, text/plain)
2019-06-04 17:45 UTC, zvezdin
no flags Details
Turning the screen off and on to reproduce the issue with the new kernel (26.87 KB, text/plain)
2019-06-04 17:46 UTC, zvezdin
no flags Details
intel_reg dump while the screen no longer displays an image (19.69 KB, text/plain)
2019-06-04 17:46 UTC, zvezdin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description zvezdin 2019-02-24 10:37:23 UTC
Created attachment 143448 [details]
Dmesg on a boot demonstrating the issue

Bug description:


I've got an Acer Switch 10e SW3-016 tablet (Intel Atom x5-Z8300) and have been fighting in getting a working Linux environment on it for the last couple of months.

Most notably, booting any distro displays the kernel log until KMS loads Intel drivers, after which the screen briefly flashes white and stops displaying an image. I can ssh, successfully start and interact with X, change brightness levels (and since it's an LCD display I can see brightness changes), just that all I see is black pixels.

Kernel parameter i915.fastboot=1 temporarily fixes this issue - the display works, until the screen is shut off (to either sleep or manually "xset dpms force off"). After the screen wakes up, there is again no screen image (brightness and everything else works as normal).

I tried manually compiling and installing the recommended drm-tip, but the issue stays the same.

I've attached the full dmesg (with drm.debug=0x1e log_buf_len=1M kernel params), and an intel_reg dump.
I couldn't dump the VBIOS:
cat: /sys/devices/pci0000:00/0000:00:02.0/rom: Input/output error

System environment:
-- chipset:
-- system architecture: 64-bit
-- xf86-video-intel: N/A
-- xserver: N/A
-- mesa: N/A
-- libdrm: 2.4.97
-- kernel: 4.20.11-arch2-1-ARCH
-- Linux distribution: Arch
-- Machine or mobo model: Acer Switch SW3-016
-- Display connector: DSI

Reproducing steps:

Additional info:
Comment 1 zvezdin 2019-02-24 10:38:59 UTC
Created attachment 143449 [details]
Intel reg dump on a boot with the issue
Comment 2 Lakshmi 2019-02-25 08:02:37 UTC
> Kernel parameter i915.fastboot=1 temporarily fixes this issue - the display
> works, until the screen is shut off (to either sleep or manually "xset dpms
> force off"). After the screen wakes up, there is again no screen image
> (brightness and everything else works as normal).
> 

Can you add dmesg log in this case (i915.fastboot=1)?
Comment 3 zvezdin 2019-02-25 09:28:54 UTC
Created attachment 143455 [details]
dmesg with i915.fastboot=1 boot

Having i915.fastboot=1 successfully boots with a working display. Then, running systemd suspend shuts off the screen for half a second and then the system automatically wakes up again (with the screen displaying black). I've attached the dmesg during this process.
Comment 4 zvezdin 2019-02-25 09:30:17 UTC
Created attachment 143456 [details]
dmesg with i915.fastboot=1 suspend

Here is the dmesg segment when running systemd suspend
Comment 5 Lakshmi 2019-06-04 10:28:00 UTC
Reporter, do you still have the issue?
@Maarten, any suggestions here?
Comment 6 zvezdin 2019-06-04 17:44:12 UTC
@Lakshmi

Upgrading my Arch system to latest current state, including Kernel 5.1.6-arch1-1-ARCH and libdrm 2.4.98-1 yields interesting results.

Now, without needing any extra kernel flags, I am able to boot into a graphical interface, control the brightness, and gpu acceleration is working. However, if the screen is shut off (for example, via xset dpms force off), when the screen wakes up again, it no longer displays a picture (everything else with the system works, including brightness levels, just no picture). This is a problem regardless if X is running or not.

I am attaching a dmesg on a successful boot with a working graphical environment. And then a dmesg on what happens after I run "xset dpms force off" and wake the screen up (so that it stops displaying a picture). Both of these dmesg logs are from the same boot. I'm also attaching an intel reg dump after the screen stops displaying a picture. Hope that helps!
Comment 7 zvezdin 2019-06-04 17:45:13 UTC
Created attachment 144445 [details]
Boot with new kernel into a working graphical environment
Comment 8 zvezdin 2019-06-04 17:46:07 UTC
Created attachment 144446 [details]
Turning the screen off and on to reproduce the issue with the new kernel
Comment 9 zvezdin 2019-06-04 17:46:56 UTC
Created attachment 144447 [details]
intel_reg dump while the screen no longer displays an image
Comment 10 Lakshmi 2019-06-05 05:54:39 UTC
(In reply to zvezdin from comment #8)
> Created attachment 144446 [details]
> Turning the screen off and on to reproduce the issue with the new kernel

In this case, can you attach the dmesg from boot.
Comment 11 zvezdin 2019-06-05 11:21:30 UTC
(In reply to Lakshmi from comment #10)
> (In reply to zvezdin from comment #8)
> > Created attachment 144446 [details]
> > Turning the screen off and on to reproduce the issue with the new kernel
> 
> In this case, can you attach the dmesg from boot.

Booting into a graphical environment (the first file I uploaded yesterday) and turning the screen off and on (the second file I uploaded yesterday) are the same dmesg, split on two parts - booting and issue recreation.
Comment 12 James Ausmus 2019-06-18 14:26:01 UTC
Jani, any thoughts on what might be going wrong here?
Comment 13 Jani Nikula 2019-06-20 12:39:00 UTC
We simply fail to enable the DSI display. DSI being DSI, we don't get errors, so hard to say why without the hardware.

Obviously the UEFI GOP is able to enable the display, and with i915.fastboot=1 we just don't touch the hardware until the next modeset, which we then fail.

i915.fastboot=1 became the default for VLV and CHV in v5.1 so that explains the change in behaviour.

Please attach /sys/kernel/debug/dri/0/i915_vbt.

Please redo the register dumps. Boot v5.1 (assuming the default i915.fastboot=1) and take register dump #1. Then run 'xrandr --output DSI-1 --off --auto' (i.e. display off/on cycle, I hope I got the command line right from memory) and take register dump #2. Attach both.
Comment 14 Lakshmi 2019-07-15 11:05:01 UTC
Reporter, can you please give your feedback based on comment 13?


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.