Bug 108672

(UEFI is in native-only mode and boots straight into native 1366x768 resolution. With 4.19, the Dell logo shows up for a moment too.)

Set kernel parameters drm.debug=0x1e log_buf_len=4M and reproduce the issue. Attach the full dmesg log from boot. This will help in investigation.

Created attachment 142388 [details]
dmesg

i guess not really supported today, yet?

Sorry about that. I wasn't sure which GPUs it was supposed to already work with (based on https://hansdegoede.livejournal.com/19224.html).

*** This bug has been marked as a duplicate of bug 108225 ***

I would like to reopen this. I've tested again with kernel 5.0.0, which (I believe) is supposed to include the fixes from bug 108225, however I still get exactly the same result. Yes, *backlight* works – but the screen itself is still completely black.

(The system isn't frozen; it boots normally and can suspend/resume. But no image appears after boot; it only starts working after suspend/resume)

I'm not sure that's recent enough, can you test drm-tip?

(In reply to Maarten Lankhorst from comment #8)
> I'm not sure that's recent enough, can you test drm-tip?

My mistake, will do so.

(In reply to Maarten Lankhorst from comment #8)
> I'm not sure that's recent enough, can you test drm-tip?

Just compiled 5.0.0-g6e610bdc61f8 from drm-tip, seems like the same problem still occurs (backlight on but display entirely black on module load).

dmesg backlight?

Created attachment 143634 [details]
dmesg (5.0.0-g6e610bdc61f8)

Not entirely sure if this is what you meant, but:

[    2.188671] [drm:intel_bios_init [i915]] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 13, level 255, controller 0
[    2.190907] [drm:intel_dp_init_panel_power_sequencer [i915]] backlight on delay 1, off delay 200
[    2.198635] [drm:lpt_setup_backlight [i915]] CPU backlight register was enabled, switching to PCH override
[    2.198669] [drm:intel_panel_setup_backlight [i915]] Connector eDP-1 backlight initialized, enabled, brightness 937/937
[    2.223472] [drm:intel_backlight_device_register [i915]] Connector eDP-1 backlight sysfs interface registered

Weird, at this point backlight should work, what happens if you change it?

On that last kernel

(In reply to Maarten Lankhorst from comment #13)
> Weird, at this point backlight should work, what happens if you change it?

Backlight indeed works (and I can even adjust it via /sys/class/backlight)... the problem is that there's no actual image on screen. As soon as i915 gets loaded, the screen flickers once and all pixels go black.

Sorry if I was unclear in the problem description.

What I do see..

[   13.075355] systemd[1]: Started Emergency Shell.
[   13.075467] systemd[1]: Reached target Emergency Mode.
[   13.077260] systemd[350]: emergency.service: Executable /bin/plymouth missing, skipping: No such file or directory

Maybe affected by bug #107100 ?

Oh never mind, from dmesg..

What happens if you run with drm.debug=14 and try to start xorg-server next?

Created attachment 143667 [details]
dmesg (starting Xorg)

Alright, I'll try to set up direct startx later... but currently I have GNOME (gdm) starting up in Wayland mode, then logging into an Xorg-based session, so here's the log for that.

("MARK: starting GUI" is the point where I exit emergency mode; gdm starts its Wayland-based login screen; then I blindly log in; gdm starts xorg-server for my session; I somehow manage to open gnome-terminal and dump dmesg.)

The screen remains blank at all times.

What does the xorg log say?

Created attachment 143720 [details]
Xorg.log after startx (xf86-video-intel)

Nothing different from normal boots that I can see... I tried with both xf86-video-intel and with the modesetting driver. (This time straight startx from console, as requested.)

Created attachment 143721 [details]
Xorg.log after startx (builtin modesetting driver)

Created attachment 143722 [details]
dmesg after startx (builtin modesetting driver)

hsw-ult... I may have a fix for this:
https://patchwork.freedesktop.org/series/59950/

(In reply to Ville Syrjala from comment #23)
> hsw-ult... I may have a fix for this:
> https://patchwork.freedesktop.org/series/59950/

Hmm. Can't see the pfit being on in the logs. So that is probably not going to help.

(In reply to Ville Syrjala from comment #24)
> (In reply to Ville Syrjala from comment #23)
> > hsw-ult... I may have a fix for this:
> > https://patchwork.freedesktop.org/series/59950/
> 
> Hmm. Can't see the pfit being on in the logs. So that is probably not going
> to help.

I could test anyway, but the first patch doesn't seem to apply to 5.1 nor to drm-tip...

(In reply to Mantas Mikulėnas from comment #25)
> (In reply to Ville Syrjala from comment #24)
> > (In reply to Ville Syrjala from comment #23)
> > > hsw-ult... I may have a fix for this:
> > > https://patchwork.freedesktop.org/series/59950/
> > 
> > Hmm. Can't see the pfit being on in the logs. So that is probably not going
> > to help.
> 
> I could test anyway, but the first patch doesn't seem to apply to 5.1 nor to
> drm-tip...

Both patches are now in drm-tip.

[   29.493733] [drm:intel_modeset_setup_hw_state [i915]] SPLL hw state readout: crtc_mask 0x00000001, on 1

I think this migth be the same issue as in bug 108773.

Please try the patch from bug 108773 comment 26.

(In reply to Ville Syrjala from comment #27)
> [   29.493733] [drm:intel_modeset_setup_hw_state [i915]] SPLL hw state
> readout: crtc_mask 0x00000001, on 1
> 
> I think this migth be the same issue as in bug 108773.
> 
> Please try the patch from bug 108773 comment 26.

Tested with yesterday's drm-tip and the patch seems to solve the problem.

Thanks for the feedback closing this issue as Fixed.