I was following the information on https://hansdegoede.livejournal.com/19224.html to enable flicker-free bot on Fedora 29. However, enabling i915.fastboot=1 results in the screen staying black during and after boot. No login manager is shown, and I cannot switch VTs via CTRL+ALT+F keys (as usual). This happens on a Thinkpad S1 Yoga (Haswell platform), which incidentally I know is one of the Haswell machines available for Intel employees. Tested kernel versions: Fedora kernels 4.18.18/19, 4.19.2-200 and 4.20.0-0.rc2.git2.1. I havent tested any mainline or git build yet. I reported https://bugzilla.redhat.com/show_bug.cgi?id=1639437, and was referred to here. I'll try to create a dmesg with debug information, and attach it here.
I confirm the same behaviour on a Thinkpad T440s using an i7-4600U Haswell processor and kernel 4.19.2 on Arch. This is with an eDP panel. The system is booting in EFI mode and the bootloader text is still visible, but as Linux starts booting there's only a black screen. I can still interact with the system as normal (start applications,...), I just don't see anything on the screen. The screen backlight is still on at this stage. While investigating using SSH the screen went into powersave, that is, the backlight turned off. When I exited the screen powersave by moving my mouse pointer, the screen turned back on and is working normally. I'd be happy to provide debug information/test other kernels if you tell me what would be useful.
Correction: After the bootloader is shown, the vendor logo briefly flashes on the screen and then the screen turns black.
(In reply to Julius B. from comment #0) > I was following the information on > https://hansdegoede.livejournal.com/19224.html to enable flicker-free bot on > Fedora 29. > > However, enabling i915.fastboot=1 results in the screen staying black during > and after boot. No login manager is shown, and I cannot switch VTs via > CTRL+ALT+F keys (as usual). > > This happens on a Thinkpad S1 Yoga (Haswell platform), which incidentally I > know is one of the Haswell machines available for Intel employees. > > Tested kernel versions: > Fedora kernels 4.18.18/19, 4.19.2-200 and 4.20.0-0.rc2.git2.1. > > I havent tested any mainline or git build yet. I reported > https://bugzilla.redhat.com/show_bug.cgi?id=1639437, and was referred to > here. > > I'll try to create a dmesg with debug information, and attach it here. Dmesg log from boot with kernel parameters drm.debug=0x1e log_buf_len=4M are needed from latest drm-tip. This issue could be duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=104838
Created attachment 142523 [details] Dmesg output from drm-tip with fastboot on T440s I cloned drm-tip, built the kernel with default options+EFISTUB, booted with fastboot (black screen), turned the screen off with `xset dpms force off` and got normal graphical output after moving the mouse pointer to wake the screen up again.
Maarten, Any help here?
https://patchwork.freedesktop.org/series/52754/ ?
Created attachment 142648 [details] Dmesg from drm-tip 20181128 with fastboot on T440s I built drm-tip at 5912c54d9804fb15d6a9fa2798bfef1e837c8938 (Nov 27 18:38:00 2018 -0800) with default config + EFISTUB, booted and there was no output on the screen. When I forced the monitor into sleep mode (xset dpms force off) and woke the screen up by moving the mouse I had normal output again. It seems the LUT update patch does not solve the issue for me.
Hmm dumped pipe config stays the same regardless, so link parameters don't seem t o be a problem. Could still be backlight. https://bugs.freedesktop.org/attachment.cgi?id=142522 ?
Created attachment 142659 [details] Dmesg of drm-tip + backlight patch on T440s Same drm-tip version as the the last comment + the backlight patch. The backlight was working before the patch. That is, there was a clear difference between the black screen after boot and the black screen after xset dpms force off. With the patch, the backlight was off after boot as well and there was no difference before and after xset dpms force off. I could see boot messages on the screen for a split-second after exiting the boot loader. It appeared that the screen was half-filled (top-to-bottom) with messages before it turned off. Maybe this information helps in determining the timing of the problematic action.
According to bug#104838, this should be fixed in linux-next. However, I haven't been able to verify the fix, my system still shows a black screen when booting with i915.fastboot=1. I'll try to create a dmesg log and attach it here. Johannes Krampf, could you check if it works on your system?
Created attachment 144306 [details] dmesg linux-next 20190517 without fastboot on T440s
Created attachment 144307 [details] dmesg linux-next 20190517 with fastboot on T440s I tried linux-next. When I cloned the tree, the latest version was b1d6682ef9bb6893690e39e2186371a1dc45072b with the tag next-20190517. The kernel worked fine without fastboot. With fastboot I would very briefly (<second) see boot messages, then the screen would go black, but with the backlight on. Finally, around the time I expect Wayland to have started, the screen went completely black with the backlight being off. The machine was running and I was able to open a terminal and redirect dmesg to a file. I was also able to switch to a virtual terminal, redirect dmesg once more to a file and to trigger a reboot. All of this was with the backlight being off. I did not try the equivalent of `xset dpms force off` because I couldn't remember how this worked on Wayland/sway. I can try this if it would be helpful. Please ask me in this case.
Created attachment 144308 [details] dmesg linux-next 20190517 with fastboot on Yoga
Created attachment 144309 [details] dmesg linux-next 20190517 with fastboot on Yoga
Created attachment 144310 [details] dmesg linux-next 20190517 without fastboot on Yoga I can confirm the same behaviour as Johannes on the S1 Yoga with X11: With fastboot I would very briefly (<second) see boot messages, then the screen would go black, but with the backlight on. Finally, around the time I expect X11 to have started, the screen went completely black with the backlight being off. However, I wasn't able to switch VTs, but I captured dmesg via ssh.
Please test latest drm-tip and make sure to pass drm.debug=0xe to the kernel cmdline.
Created attachment 144328 [details] Dmesg of drm-tip without fastboot on T440s
Created attachment 144329 [details] Dmesg of drm-tip with fastboot on T440s This is drm-tip version 307cedb7b907ee533bf9e746d0e06bea04f2722b from Thu May 23 12:49:55 2019 +1000. I used drm.debug=0xe on the kernel flags as requested. Previously I had 0x1e. The behaviour changed slightly with drm-tip: On startup, I still get the sub-second flash with boot messages and then the screen _including the backlight_ turns off. I can interact with the system (wayland+VT), but get no screen output. Please tell me if there's any other information I can provide (video of boot process?) and I'll try to provide it.
(In reply to Johannes Krampf from comment #18) > Created attachment 144329 [details] > Dmesg of drm-tip with fastboot on T440s > > This is drm-tip version 307cedb7b907ee533bf9e746d0e06bea04f2722b from Thu > May 23 12:49:55 2019 +1000. I used drm.debug=0xe on the kernel flags as > requested. Previously I had 0x1e. > > The behaviour changed slightly with drm-tip: > > On startup, I still get the sub-second flash with boot messages and then the > screen _including the backlight_ turns off. I can interact with the system > (wayland+VT), but get no screen output. OK. I guess we're dealing with a backlight problem at this point. We do see the telltale signs here: [ 0.910355] [drm:lpt_setup_backlight] CPU backlight register was enabled, switching to PCH override The code was supposed to be fixed so that it can do the CPU->PCH switch but it looks like it's still not working correctly.
I think we need to check how the BIOS has programmed the backlight. Please boot without loading i915, and then do the following: intel_reg read 0x48250 0x48254 0x48350 0x48354 0x48360 0x48260 0x48264 0x48268 0x48400 0xc8250 0xc8254 You can get intel_reg from igt-gpu-tools/intel-gpu-tools.
I booted into the Arch Linux provided 5.1.3 kernel with module_blacklist=i915 on the kernel parameters and verified that there was no i915 in lsmod output. Output of `intel_reg read 0x48250 0x48254 0x48350 0x48354 0x48360 0x48260 0x48264 0x48268 0x48400 0xc8250 0xc8254` without i915: ``` Error: /usr/share/igt-gpu-tools/registers/common_display.txt:1: ('CPU_VGACNTRL', '0x00041000', '') Error: /usr/share/igt-gpu-tools/registers/haswell:1: common_display.txt Warning: reading '/usr/share/igt-gpu-tools/registers/haswell' failed. Using builtin register spec. BLC_PWM_CPU_CTL2 (0x00048250): 0xe0000000 (enable 1, pipe EDP, blinking 0, granularity 128) BLC_PWM_CPU_CTL (0x00048254): 0x03540354 (cycle 852, freq 852) BLC_PWM2_CPU_CTL2 (0x00048350): 0x60000000 (enable 0, pipe EDP, blinking 0, granularity 128) BLC_PWM2_CPU_CTL (0x00048354): 0x00000000 (cycle 0, freq 0) BLC_MISC_CTL (0x00048360): 0x00000000 (PWM1-PCH PWM2-CPU) (0x00048260): 0x00000002 (0x00048264): 0x00000000 (0x00048268): 0x00000000 UTIL_PIN_CTL (0x00048400): 0x00000000 (enable 0, transcoder A, mode data, data 0 inverted polarity 0) BLC_PWM_PCH_CTL1 (0x000c8250): 0x80000000 (enable 1, override 0, inverted polarity 0) BLC_PWM_PCH_CTL2 (0x000c8254): 0x03540354 (freq 852, cycle 852) ``` Values when running with the module i915 loaded: ``` Error: /usr/share/igt-gpu-tools/registers/common_display.txt:1: ('CPU_VGACNTRL', '0x00041000', '') Error: /usr/share/igt-gpu-tools/registers/haswell:1: common_display.txt Warning: reading '/usr/share/igt-gpu-tools/registers/haswell' failed. Using builtin register spec. BLC_PWM_CPU_CTL2 (0x00048250): 0x60000000 (enable 0, pipe EDP, blinking 0, granularity 128) BLC_PWM_CPU_CTL (0x00048254): 0x03540354 (cycle 852, freq 852) BLC_PWM2_CPU_CTL2 (0x00048350): 0x60000000 (enable 0, pipe EDP, blinking 0, granularity 128) BLC_PWM2_CPU_CTL (0x00048354): 0x00000000 (cycle 0, freq 0) BLC_MISC_CTL (0x00048360): 0x00000000 (PWM1-PCH PWM2-CPU) (0x00048260): 0x00000001 (0x00048264): 0x00000000 (0x00048268): 0x00000000 UTIL_PIN_CTL (0x00048400): 0x00000000 (enable 0, transcoder A, mode data, data 0 inverted polarity 0) BLC_PWM_PCH_CTL1 (0x000c8250): 0xc0000000 (enable 1, override 1, inverted polarity 0) BLC_PWM_PCH_CTL2 (0x000c8254): 0x03540130 (freq 852, cycle 304) ```
Nothing remarkable in the backlight setup. Hmm. Looks like the BIOS is using SPLL for eDP. We do seem to leave that correctly enabled, but maybe we're turning off its reference by mistake. It is using the SSC reference by the looks of it, but the question which one. What does 'intel_reg read 0x42004' say? Assuming it's using the PCH SSC reference this might help: --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15342,7 +15342,7 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv) intel_encoder_clones(encoder); } - intel_init_pch_refclk(dev_priv); + //intel_init_pch_refclk(dev_priv); drm_helper_move_panel_connectors_to_head(&dev_priv->drm); }
(In reply to Ville Syrjala from comment #22) > Nothing remarkable in the backlight setup. > > Hmm. Looks like the BIOS is using SPLL for eDP. We do seem to leave that > correctly enabled, but maybe we're turning off its reference by mistake. > It is using the SSC reference by the looks of it, but the question which one. > > What does 'intel_reg read 0x42004' say? Doh. Make that 'intel_reg read 0x42014'
After commenting out `intel_init_pch_refclk(dev_priv);` I was able to boot successfully on drm-tip 307cedb7b907ee533bf9e746d0e06bea04f2722b from 23 May (freedesktop git seems to be down, I couldn't update). It seems your suspicion is correct. :-) Running `intel_reg read 0x42014` gives me the same value when booting Arch Linux kernel 5.1.6 (with and without loading i915) and with drm-tip and fastboot: ``` # intel_reg read 0x42014 Error: /usr/share/igt-gpu-tools/registers/common_display.txt:1: ('CPU_VGACNTRL', '0x00041000', '') Error: /usr/share/igt-gpu-tools/registers/haswell:1: common_display.txt Warning: reading '/usr/share/igt-gpu-tools/registers/haswell' failed. Using builtin register spec. (0x00042014): 0x21000002 ```
To clarify: I get the same register value with the patched drm-tip and fastboot, I didn't try unpatched drm-tip.
Created attachment 144444 [details] [review] [PATCH] drm/i915: Do not touch the PCH SSC reference if a PLL is using it This should avoid clobbering the PCH SSC reference during driver load. Please test and post the resulting dmesg with drm.debug=0xe so that I can confirm the logic works as intended.
Created attachment 144452 [details] Dmesg of drm-tip fastboot with patch "Do not touch the PCH SSC..." I synced to the most recent drm-tip, applied the patch and was able to boot with fastboot and graphical output working. I've attached the dmesg output with drm.debug=0xe.
(In reply to Johannes Krampf from comment #27) > Created attachment 144452 [details] > Dmesg of drm-tip fastboot with patch "Do not touch the PCH SSC..." > > I synced to the most recent drm-tip, applied the patch and was able to boot > with fastboot and graphical output working. > > I've attached the dmesg output with drm.debug=0xe. Nice. Thanks for testing. Fix is in: commit b16c7ed95caf270075c52faad0af8f4cb57ae979 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Jun 4 23:09:29 2019 +0300 drm/i915: Do not touch the PCH SSC reference if a PLL is using it
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.