Booting my Dell Inspiron with 'i915.fastboot=1' still results in flicker during load, and more importantly, completely blank screen afterwards. Perhaps similar to bug 104838 but in my case the kernel *does not* lock up; I can still blindly run commands. So here's dmesg output after booting into emergency mode and running `modprobe i915`: [ 67.947553] Linux agpgart interface v0.103 [ 68.092857] VFIO - User Level meta-driver version: 0.3 [ 68.237788] checking generic (c0000000 408000) vs hw (c0000000 10000000) [ 68.237789] fb: switching to inteldrmfb from EFI VGA [ 68.237806] Console: switching to colour dummy device 80x25 [ 68.237873] [drm] Replacing VGA console driver [ 68.238868] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 68.238869] [drm] Driver supports precise vblank timestamp query. [ 68.239226] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 68.249512] [drm] Initialized i915 1.6.0 20180719 for 0000:00:02.0 on minor 0 [ 68.250556] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 68.250772] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input10 [ 68.253438] fbcon: inteldrmfb (fb0) is primary device [ 68.267489] Console: switching to colour frame buffer device 170x48 [ 68.276041] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device Software: linux 4.19.1-arch1-1, linux-firmware 20181026.1cb4e51-1 (Arch Linux) Hardware: Dell Inspiron 5547 (UEFI; fw ver. A10), internal eDP connection according to xrandr. 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) 03:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1002:6900]
(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.
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.