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:
Created attachment 143449 [details] Intel reg dump on a boot with the issue
> 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)?
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.
Created attachment 143456 [details] dmesg with i915.fastboot=1 suspend Here is the dmesg segment when running systemd suspend
Reporter, do you still have the issue? @Maarten, any suggestions here?
@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!
Created attachment 144445 [details] Boot with new kernel into a working graphical environment
Created attachment 144446 [details] Turning the screen off and on to reproduce the issue with the new kernel
Created attachment 144447 [details] intel_reg dump while the screen no longer displays an image
(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.
(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.
Jani, any thoughts on what might be going wrong here?
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.
Reporter, can you please give your feedback based on comment 13?
Please excuse me for the late reply, I must have missed the initial notification. Thank you for the recommendations, Jani. I just upgraded to Kernel 5.2.1.arch1-1 for its improved hardware support, but the issue remains the same. I've attached the i915_vbt and the reg dump after a fresh boot, as well as a reg dump after restarting the display (note: it was DSI1, not DSI-1). Both reg dumps were made with "intel_reg dump --all", which also spilled some errors on stderr that I've attached separately.
Created attachment 144816 [details] reg dump on a fresh boot with kernel 5.2
Created attachment 144817 [details] reg dump on a fresh boot with kernel 5.2 stderr
Created attachment 144818 [details] reg dump on restarted display with kernel 5.2
Created attachment 144819 [details] reg dump on restarted display with kernel 5.2 stderr
Created attachment 144820 [details] contents of /sys/kernel/debug/dri/0/i915_vbt
Looks like you've hit a bug in the intel_reg tool that's been around for about five years... /o\ Alas this means you'll have to redo the dumps with the fixed tool, because the fallback "builtin register spec" you see mentioned in the stderr is mostly useless here. The intel_reg fix is [1], which I hope to get merged to igt upstream soon too. I'm really sorry for the inconvenience. [1] http://patchwork.freedesktop.org/patch/msgid/20190821130928.29640-1-jani.nikula@intel.com
The intel_reg fix is now in igt upstream.
Hello Jani. Thank you for submitting a fix. After compiling current igt-gpu-tools at 50390dd7 locally on the machine, I also symlinked /usr/share/igt-gpu-tools (as was installed on my Arch) to /usr/local/share/igt-gpu-tools (where the new compiled intel_reg binary expected to find register files) so that the builtin register spec error got resolved. Now stderr is clean :) I also updated to kernel 5.2.9-arch1-1-ARCH if that matters. I'll now attach the reg dumps before and after the issue as previously mentioned.
Created attachment 145141 [details] reg dump with fixed intel_reg and kernel 5.2.9
Created attachment 145142 [details] reg dump after screen restart with fixed intel_reg and kernel 5.2.9
@Jani, What are next steps?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/236.
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.