Bug 109959 - REGRESSION: black screen with linux 5.0 when starting X
Summary: REGRESSION: black screen with linux 5.0 when starting X
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: highest normal
Assignee: Manasi
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
: 110193 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-03-11 12:16 UTC by Albert Astals Cid
Modified: 2019-04-16 20:27 UTC (History)
19 users (show)

See Also:
i915 platform: CFL
i915 features: display/DP


Attachments
said file with drm.debug=14 (125.19 KB, text/plain)
2019-03-11 12:16 UTC, Albert Astals Cid
no flags Details
fuller dmesg log (213.70 KB, text/plain)
2019-03-11 15:43 UTC, Albert Astals Cid
no flags Details
parameter-patch (3.05 KB, patch)
2019-03-18 18:35 UTC, Mark Weiman
no flags Details | Splinter Review
display edid.log (4.64 KB, text/x-log)
2019-03-25 18:58 UTC, Joe Lawson
no flags Details
Adds EDID DRM quirk (2.21 KB, patch)
2019-03-26 22:14 UTC, Manasi
no flags Details | Splinter Review
i915 use the EDID quirk (1.88 KB, patch)
2019-03-26 22:14 UTC, Manasi
no flags Details | Splinter Review
dmesg of drm-tip kernel. (92.86 KB, text/plain)
2019-03-27 18:38 UTC, Pascal Bürklin
no flags Details
EDID with the patch applied (298 bytes, application/octet-stream)
2019-03-27 18:39 UTC, Pascal Bürklin
no flags Details
dmesg with drm.debug=0xe (125.75 KB, text/plain)
2019-03-27 18:48 UTC, Pascal Bürklin
no flags Details
dmesg log with the patch and debug 14 (227.03 KB, patch)
2019-03-27 18:48 UTC, Albert Astals Cid
no flags Details | Splinter Review
dmesg log with patch applied and debug 0xe (and log_buffer_size increased) (351.48 KB, text/plain)
2019-03-27 19:02 UTC, Pascal Bürklin
no flags Details
Debug patch for the quirk (2.08 KB, patch)
2019-03-27 22:58 UTC, Manasi
no flags Details | Splinter Review
dmesg log with the extra debug patch and debug 14 (214.58 KB, text/plain)
2019-03-27 23:36 UTC, Albert Astals Cid
no flags Details
Debug Patch v2 (2.33 KB, patch)
2019-03-28 18:29 UTC, Manasi
no flags Details | Splinter Review
patch that works for me (3.26 KB, patch)
2019-03-30 11:20 UTC, Albert Astals Cid
no flags Details | Splinter Review
corrected-patch-5.0.6 (4.69 KB, patch)
2019-04-04 15:43 UTC, Mark Weiman
no flags Details | Splinter Review
*really* corrected rediffed 5.0.6 patch (4.48 KB, patch)
2019-04-04 23:46 UTC, Adam Williamson
no flags Details | Splinter Review
[v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on eDP (4.91 KB, patch)
2019-04-05 07:55 UTC, Jani Nikula
no flags Details | Splinter Review
journalctl log with drm.debug=14 (426.57 KB, text/plain)
2019-04-14 16:56 UTC, Juan
no flags Details
mgarstecki_i915_vbt (6.00 KB, application/octet-stream)
2019-04-16 07:33 UTC, Mathieu Garstecki
no flags Details
/sys/kernel/debug/dri/0/i915_vbt with Kernel 5.0.7-4.g012b5f1-default (6.00 KB, application/octet-stream)
2019-04-16 08:10 UTC, Dan Čermák
no flags Details
arch linux dell xps 15 9570 (6.00 KB, application/octet-stream)
2019-04-16 11:59 UTC, pbazan
no flags Details
i915_vbt Dell Precision 7530 (6.00 KB, application/octet-stream)
2019-04-16 16:38 UTC, Juan
no flags Details
i915 vbt dump (6.00 KB, application/octet-stream)
2019-04-16 19:11 UTC, Matteo Iervasi
no flags Details
i915_vbt dump (6.00 KB, application/octet-stream)
2019-04-16 20:27 UTC, Emanuele Panigati
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Astals Cid 2019-03-11 12:16:14 UTC
Created attachment 143621 [details]
said file with drm.debug=14

As mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=105267 the patch introduced to fix that makes my screen black when trying to start X (i can see the boot messages)

This https://invent.kde.org/snippets/44 workarounds the issue for me.

dmesg with drm.debug=14 attached

laptop is a Dell XPS 15 9570
Comment 1 Lakshmi 2019-03-11 12:30:29 UTC
Reporter, Can you attach the dmesg from boot.
Have you tried to verify the issue with drmtip? (https://cgit.freedesktop.org/drm-tip)
Black screen is shown only when starting X? What did you do immediately to see the normal screen? Asking this to know the impact of this bug. 
Is this issue reproducible every time? Would be good to see the results from drmtip.
Comment 2 Albert Astals Cid 2019-03-11 12:53:57 UTC
As far as i know, that  is dmesg output from boot, i.e. i boot, ssh from another computer and dmesg > file, what else do you think is missing?

> Black screen is shown only when starting X?

Yes (well to be honest i don't know if it's X but it looks like it, i'll attach a video of it)

> What did you do immediately to see the normal screen? 

I don't know what you mean by "normal screen", but you can never see anything again, you have to reboot.

Yes, it is reproducible every time.

No, I have not tried compiling drm-tip, honestly at this point i don't feel like spending my time trying to figure out how to use that unless you tell me that there has been changes regarding the issue i'm reporting.
Comment 3 Albert Astals Cid 2019-03-11 13:03:00 UTC
You can see the boot sequence https://youtu.be/JL0Y3oQ_e9w it will be a black screen forever

if i use the patch i provided, it all looks good and i get the X login display asking for my user/password instead of that black screen
Comment 4 Pascal Bürklin 2019-03-11 13:25:10 UTC
Since I have the same Laptop I can confirm, that I am having this issue too. I spent the last week troubleshooting it and therefor I want to share my current state. First of all it's not only with the X server. This bug appears on the same hardware when you try to load the i915 module with the option 'modeset' set to 1 (enabled). Also it is able to boot into the kernel as long as you keep the option set to 0. (Sadly you're not able to start an X server then) Further investigation (Thanks to the reporter) led me to analyze the workaround: (IMPORTANT FROM NOW ON ITS YET THEORETICAL ONLY, I am investigating further). Since the workaround in drivers/gpu/drm/i915/intel_dp.c forces the first block to never be executed, also nothing else changed, beside the addition of the if statement in line 2033 (I checked everything else). Therefor the bug is caused by the function (line 1882) 'intel_dp_dsc_compute_config', which returns true instead of false.
Comment 5 Lakshmi 2019-03-11 13:53:57 UTC
(In reply to Albert Astals Cid from comment #2)
> As far as i know, that  is dmesg output from boot, i.e. i boot, ssh from
> another computer and dmesg > file, what else do you think is missing?
Logs from first 3 seconds are missing from the attachment. Which platform is this?
 
> I don't know what you mean by "normal screen", but you can never see
> anything again, you have to reboot.

I got the information what I was looking for. Thanks.
Comment 6 Albert Astals Cid 2019-03-11 15:43:19 UTC
Created attachment 143624 [details]
fuller dmesg log

Had to increase the dmesg log size since the ringbuffer was filling up
Comment 7 Albert Astals Cid 2019-03-11 15:44:00 UTC
(In reply to Lakshmi from comment #5)
> (In reply to Albert Astals Cid from comment #2)
> > As far as i know, that  is dmesg output from boot, i.e. i boot, ssh from
> > another computer and dmesg > file, what else do you think is missing?
> Logs from first 3 seconds are missing from the attachment. Which platform is
> this?

Added the fuller dmesg in previous comment. Platform is archlinux (is that what you're asking?)
Comment 8 Jani Saarinen 2019-03-11 16:11:06 UTC
This enough:
[    0.351237] smpboot: CPU0: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (family: 0x6, model: 0x9e, stepping: 0xa)

So looks CFL-H, Lakshmi.
Comment 9 Pascal Bürklin 2019-03-11 16:16:57 UTC
(In reply to Jani Saarinen from comment #8)
> This enough:
> [    0.351237] smpboot: CPU0: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
> (family: 0x6, model: 0x9e, stepping: 0xa)
> 
> So looks CFL-H, Lakshmi.

This bug also occurs on the Intel(R) Core(TM) i7-8750H

Since it's having the same graphics-chip it should be redundant.
Comment 10 Victor 2019-03-12 19:12:19 UTC
I'm facing the problem since Linux 4.20.13.

Please have a look at his commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.20.13&id=218b6d525b036463f3af0e9a1da9d0285ee2bc5b
Comment 11 Maarten Lankhorst 2019-03-13 11:50:01 UTC
If it's that bug, can you paste Xorg.0.log?
Comment 12 Albert Astals Cid 2019-03-13 15:08:59 UTC
@Victor please do not hijack my bug report, 4.20.13 works fine here.
Comment 13 Ville Syrjala 2019-03-13 16:11:04 UTC
[    4.724103] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1] Link Training failed at link rate = 432000, lane count = 1
[    4.724139] [drm:intel_dp_modeset_retry_work_fn [i915]] [CONNECTOR:85:eDP-1]
...
[    5.863904] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1] Link Training failed at link rate = 324000, lane count = 1
[    5.863939] [drm:intel_dp_get_link_train_fallback_values [i915]] Retrying Link training for eDP with same parameters
...

So link training no longer works for whatever reason.
Comment 14 Ville Syrjala 2019-03-13 16:16:25 UTC
(In reply to Ville Syrjala from comment #13)
> [    4.724103] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1]
> Link Training failed at link rate = 432000, lane count = 1
> [    4.724139] [drm:intel_dp_modeset_retry_work_fn [i915]]
> [CONNECTOR:85:eDP-1]
> ...
> [    5.863904] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1]
> Link Training failed at link rate = 324000, lane count = 1
> [    5.863939] [drm:intel_dp_get_link_train_fallback_values [i915]] Retrying
> Link training for eDP with same parameters
> ...
> 
> So link training no longer works for whatever reason.

Ah yes it's the fast and narrow vs. wide and slow thing.

[    3.263107] [drm:intel_dp_init_connector [i915]] eDP DPCD: 04 93 a6

So this is a eDP 1.4a sink, which means we'll go for the fast and narrow instead of the old wide and slow apporach.
Comment 15 Joe Lawson 2019-03-16 00:08:06 UTC
I helped confirm the kernel patch working for my Dell on arch 5.0.2 but I boot to click not X so I think this isn't an X issue. My DP1-2 worked fine. Just eDP1 was hosed at startup.
Comment 16 Joe Lawson 2019-03-16 00:11:12 UTC
(In reply to Joe Lawson from comment #15)
> ... but I boot to click

Was supposed to say boot to cli not X. I use startx after logging in.
Comment 17 Sergi Granell 2019-03-16 15:33:14 UTC
Same problem here with the Dell XPS 15 9570.

Black screen when it should get into GNOME Shell Wayland since Linux 5.0.
Comment 18 Mark Weiman 2019-03-18 18:35:20 UTC
Created attachment 143729 [details] [review]
parameter-patch

I wrote up this patch to make it easy to switch between forcing the slow and wide to fast modes. If it helps anyone.
Comment 19 Jason Antman 2019-03-23 12:31:57 UTC
I'm also experiencing this issue, on Arch Linux kernel 5.0.3 running on a Dell Precision 5530

BIOS 1.3.0 (07/12/2018)
Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz (family: 0x6, model: 0x9e, stepping: 0xa)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Mobile)
01:00.0 3D controller: NVIDIA Corporation GP107GLM [Quadro P1000 Mobile] (rev a1)

I've tried building a kernel package for Arch with Mark's patch applied ( https://github.com/jantman/arch-pkgbuilds/tree/master/linux-precision5530 for PKGBUILD and source, binaries linked from http://archrepo.jasonantman.com/current/index.html ), but when running with that patched kernel and the ``force_edp_wide=1`` parameter set, I see no real difference in behavior from my previous ~35 hours struggling with video on this machine: external displays work fine, eDP is just backlight and black screen.

Would it be possible for someone who's verified this patch to post the details of their kernel parameters and driver versions/config?
Comment 20 Emanuele Panigati 2019-03-23 13:04:46 UTC
(In reply to Jason Antman from comment #19)
> I'm also experiencing this issue, on Arch Linux kernel 5.0.3 running on a
> Dell Precision 5530
> 
> BIOS 1.3.0 (07/12/2018)
> Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz (family: 0x6, model: 0x9e,
> stepping: 0xa)
> 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630
> (Mobile)
> 01:00.0 3D controller: NVIDIA Corporation GP107GLM [Quadro P1000 Mobile]
> (rev a1)
> 
> I've tried building a kernel package for Arch with Mark's patch applied (
> https://github.com/jantman/arch-pkgbuilds/tree/master/linux-precision5530
> for PKGBUILD and source, binaries linked from
> http://archrepo.jasonantman.com/current/index.html ), but when running with
> that patched kernel and the ``force_edp_wide=1`` parameter set, I see no
> real difference in behavior from my previous ~35 hours struggling with video
> on this machine: external displays work fine, eDP is just backlight and
> black screen.
> 
> Would it be possible for someone who's verified this patch to post the
> details of their kernel parameters and driver versions/config?

Same for me (Dell XPS 9570): kernel 5.0.3 with Mark's patch has the same issue found in non-patched kernel, while using https://invent.kde.org/snippets/44 patch the system boots fine (I am writing from arch with 5.0.3 kernel patched).

If it can help, my current kernel params are:

add_efi_memmap rw acpi_rev_override=1 nvidia-drm.modeset=1 pcie_port_pm=on acpi_osi="Windows 2009"
Comment 21 Mark Weiman 2019-03-23 14:00:45 UTC
Jason, I mistyped in that patch, you need to pass "i915.force_edp_wide=1" to work since that's within the i915 module.
Comment 22 Joe Lawson 2019-03-25 18:58:05 UTC
Created attachment 143776 [details]
display edid.log

I did a dump of the edid info of my displays. The edp doesn't work while the DP does.

The patch does work fine. Perhaps this information can help make a better detection routine.
Comment 23 Manasi 2019-03-25 21:44:57 UTC
Hi All,
I am working on getting this issue fixed for you all.
So based on the experimental patches and the logs, looks like for this specific eDP panel, it does need max lane count and max link rate for it to pass link training and our optimized fast and narrow approach wont work.
@jani @Ville, do you think the best solution for fixing this would be adding a quirk for this edP panel, looks like its the same panel in all 3 cases.

Manasi
Comment 24 Jason Antman 2019-03-25 23:23:00 UTC
(In reply to Mark Weiman from comment #21)
> Jason, I mistyped in that patch, you need to pass "i915.force_edp_wide=1" to
> work since that's within the i915 module.

Ah, thanks! I haven't recompiled to revert back to your patch and add the proper parameter yet, but I can confirm that Albert's original patch works perfectly for me, so I assume yours would as well (if I'd provided the proper parameters).

I can provide dmesg/edid from my system as well if needed, but it sounds like this is pretty well narrowed-down at this point. Many thanks to all!
Comment 25 Manasi 2019-03-26 22:14:02 UTC
Created attachment 143782 [details] [review]
Adds EDID DRM quirk
Comment 26 Manasi 2019-03-26 22:14:40 UTC
Created attachment 143783 [details] [review]
i915 use the EDID quirk
Comment 27 Manasi 2019-03-26 22:17:36 UTC
Albert, Pascal, Jason, Victor: I have attached the two patches :
1. Add DRM EDID quirk
2. i915 use the EDID quirk

These add the quirk for this specific eDP panel based on the EDID attached and sets the quirk to use wide and slow or the max link rate and max lane count approach which should fix the link training issue.

Could you please apply these on drm-tip in the above order and test them and let me know if this fixes the issue so I can submit those to the M-L?

Regards
Manasi
Comment 28 Albert Astals Cid 2019-03-26 23:20:44 UTC
I have applied the patches on top of linux 5.0.4 ( needed some tweaking, my untrained eye says the patch looks good https://ghostbin.com/paste/2bmk3 ) and it doesn't fix the issue for me.

I've no idea how to use/compile drm-tip 

Is there any howto to explain how to use that on top of a "stable" kernel?
Comment 29 Manasi 2019-03-27 17:10:17 UTC
Albert, the patch that you have looks good and if you have the same EDID as the one attached by Joe, this should work.
Do you mind sending me your EDID log and the dmesg with debug level set to 0xe with these patches?

Manasi
Comment 30 Pascal Bürklin 2019-03-27 18:38:46 UTC
Created attachment 143791 [details]
dmesg of drm-tip kernel.

I applied both patches in order ontop of drm-tip an compiled the whole kernel. Sadly I can not confirm that the issue got fixed. I attached the dmesg output. I will attach my EDID.log too

Pascal
Comment 31 Pascal Bürklin 2019-03-27 18:39:38 UTC
Created attachment 143792 [details]
EDID with the patch applied
Comment 32 Albert Astals Cid 2019-03-27 18:42:42 UTC
My Xorg.0.log says

[     6.038] (II) modeset(0): Manufacturer: SHP  Model: 149a  Serial#: 0


So yes it seems it's the same EDID as joe
Comment 33 Pascal Bürklin 2019-03-27 18:48:44 UTC
Created attachment 143793 [details]
dmesg with drm.debug=0xe
Comment 34 Albert Astals Cid 2019-03-27 18:48:54 UTC
Created attachment 143794 [details] [review]
dmesg log with the patch and debug 14
Comment 35 Pascal Bürklin 2019-03-27 19:02:29 UTC
Created attachment 143795 [details]
dmesg log with patch applied and debug 0xe (and log_buffer_size increased)

Sorry for the spam. I forgot to increase the log_buffer_size.


Pascal
Comment 36 Manasi 2019-03-27 20:39:27 UTC
Looks like, it didnt use the quirk, let me add some debug prints and give you a debug patch to apply on top of the two so we can see why its not getting the quirk.

Manasi
Comment 37 Manasi 2019-03-27 22:58:47 UTC
Created attachment 143796 [details] [review]
Debug patch for the quirk

Could you please try this debug patch on top of the other 2 patches and send me the dmesg log with debug level = 0xe

Manasi
Comment 38 Albert Astals Cid 2019-03-27 23:36:59 UTC
Created attachment 143797 [details]
dmesg log with the extra debug patch and debug 14

Seems only "eDP Debug: eDP 1.4 SHP panle quirk present" is triggered, but not the other two
Comment 39 Manasi 2019-03-28 18:29:02 UTC
Created attachment 143801 [details] [review]
Debug Patch v2

Could you please try this v2 of the debug patch on top of the first two quirk patches, this will tell us why its not getting invoked correctly in i915 even though the drm level quirk is getting triggered.
Comment 40 Albert Astals Cid 2019-03-30 11:20:29 UTC
ok, i found the problem, you need to move

if (connector->display_info.force_max_lane_count)
   intel_dp->edp_force_max_lane_count = true;

before
   drm_connector_update_edid_property(connector, edid);

since drm_connector_update_edid_property calls drm_add_display_info that calls drm_reset_display_info and that will reset force_max_lane_count

If you do that it works for me.
Comment 41 Albert Astals Cid 2019-03-30 11:20:59 UTC
Created attachment 143817 [details] [review]
patch that works for me
Comment 42 Emanuele Panigati 2019-03-30 13:58:30 UTC
(In reply to Albert Astals Cid from comment #41)
> Created attachment 143817 [details] [review] [review]
> patch that works for me

Just built kernel 5.0.5 on Archlinux for my Dell XPS 9570 using the patch provided by Albert.
I can confirm no issue at startup, the system boots fine.
Comment 43 Ralgor 2019-03-30 18:36:40 UTC
I also built 5.0.5 on Archlinux using Albert's patch, but it didn't work. Further investigation revealed the product id for my display is 0x148e. I'm running a Dell XPS 15 2-in-1 9575, with the 1080p display.
Comment 44 Ralgor 2019-03-30 18:37:46 UTC
I forgot to add that I modified the patch on my end with my product id, and then it worked fine.
Comment 45 Dan Čermák 2019-04-01 12:20:24 UTC
(In reply to Albert Astals Cid from comment #41)
> Created attachment 143817 [details] [review] [review]
> patch that works for me

I've applied this patch on top of the Linux Kernel v5.0 tag and it fixes the problems on my Dell Precision 5530.

Unfortunately it does not apply cleanly on v5.1rc3, so I couldn't test the latest pre-release.
Comment 46 Manasi 2019-04-02 00:43:22 UTC
Great, so I will swap the position of setting the force_max_lane_count and post the patches to the mailing list with quirks for both panels/both vendor IDs
Comment 47 Manasi 2019-04-02 21:26:13 UTC
(In reply to Ralgor from comment #44)
> I forgot to add that I modified the patch on my end with my product id, and
> then it worked fine.

So you just changed the product ID, SHP is still the same right?

Manasi
Comment 48 Ralgor 2019-04-02 23:17:20 UTC
(In reply to Manasi from comment #47)
> (In reply to Ralgor from comment #44)
> > I forgot to add that I modified the patch on my end with my product id, and
> > then it worked fine.
> 
> So you just changed the product ID, SHP is still the same right?
> 
> Manasi

Yup:

	/* SHP eDP 1.4 panel only works with max lane count */
	{ "SHP", 0x149a, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
        { "SHP", 0x148e, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
Comment 49 Manasi 2019-04-03 18:02:24 UTC
Yup, I have added those quirks and patches are on the M-L with you all copied on it:
https://patchwork.freedesktop.org/series/58893/
Comment 50 Manasi 2019-04-04 00:38:26 UTC
Hi All,

Another approach for fixing this issue was suggested, can anyone of you please test the patch by itself without any previous quirk patches  to see if it fixes the problem?

https://patchwork.freedesktop.org/series/58975/

Manasi
Comment 51 Mark Weiman 2019-04-04 13:47:41 UTC
This new patch does not apply on 5.0.6
Comment 52 Manasi 2019-04-04 15:27:05 UTC
Sorry, please try the v2 of the patch:

https://patchwork.freedesktop.org/patch/296273/?series=58975&rev=2

Let me know if that fixes the issue.

Manasi
Comment 53 Mark Weiman 2019-04-04 15:33:53 UTC
I can already tell that this won't apply either on 5.0.6 because the last hunk (intel_drv.h) is what caused the issue.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/i915/intel_drv.h?h=v5.0.6#n1221
Comment 54 Mark Weiman 2019-04-04 15:43:39 UTC
Created attachment 143862 [details] [review]
corrected-patch-5.0.6

Something for use with 5.0.6 (I'm building/testing it currently).
Comment 55 Manasi 2019-04-04 18:07:53 UTC
Cool, let me know if it fixes the issue and you can add tested by tag to the patch.

Manasi
Comment 56 Adam Williamson 2019-04-04 21:59:49 UTC
I tried a build of 5.0.6 with Mark's 'corrected' patch, but it fails to build on i686 at least:

BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_uses_max_link_params':
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:467:43: error: parameter name omitted
BUILDSTDERR:   467 | static bool intel_dp_uses_max_link_params(struct intel_dp*,
BUILDSTDERR:       |                                           ^~~~~~~~~~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:471:22: error: 'intel_dp' undeclared (first use in this function)
BUILDSTDERR:   471 |  return link_rate == intel_dp->max_link_rate &&
BUILDSTDERR:       |                      ^~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:471:22: note: each undeclared identifier is reported only once for each function it appears in
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c: At top level:
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:475:13: error: redefinition of 'intel_dp_uses_max_link_params'
BUILDSTDERR:   475 | static bool intel_dp_uses_max_link_params(struct intel_dp *intel_dp,
BUILDSTDERR:       |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:467:13: note: previous definition of 'intel_dp_uses_max_link_params' was here
BUILDSTDERR:   467 | static bool intel_dp_uses_max_link_params(struct intel_dp*,
BUILDSTDERR:       |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:467:13: warning: 'intel_dp_uses_max_link_params' defined but not used [-Wunused-function]
BUILDSTDERR: make[4]: *** [scripts/Makefile.build:277: drivers/gpu/drm/i915/intel_dp.o] Error 1
BUILDSTDERR: make[3]: *** [scripts/Makefile.build:492: drivers/gpu/drm/i915] Error 2
BUILDSTDERR: make[3]: *** Waiting for unfinished jobs....
Comment 57 Adam Williamson 2019-04-04 22:02:30 UTC
Oh, looking at it carefully, it seems the "corrected" patch mistakenly tries to add intel_dp_uses_max_link_params() twice...
Comment 58 Adam Williamson 2019-04-04 23:46:16 UTC
Created attachment 143865 [details] [review]
*really* corrected rediffed 5.0.6 patch

here's a corrected corrected patch =)
Comment 59 Jani Nikula 2019-04-05 07:26:59 UTC
Please test

http://patchwork.freedesktop.org/patch/msgid/20190405072439.8922-1-jani.nikula@intel.com

and report back. This is on top of current drm-tip.
Comment 60 Jani Nikula 2019-04-05 07:54:30 UTC
(In reply to Jani Nikula from comment #59)
> Please test
> 
> http://patchwork.freedesktop.org/patch/msgid/20190405072439.8922-1-jani.
> nikula@intel.com
> 
> and report back. This is on top of current drm-tip.

Scratch that.

http://patchwork.freedesktop.org/patch/msgid/20190405075220.9815-1-jani.nikula@intel.com
Comment 61 Jani Nikula 2019-04-05 07:55:31 UTC
Created attachment 143874 [details] [review]
[v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on eDP

Attached is a backport of the patch to v5.0.
Comment 62 Adam Williamson 2019-04-08 14:48:14 UTC
FWIW, a Fedora tester with an affected system reports that this works fine. He tested a scratch build of 5.0.6 with Jani's backport of his own patch, from comment #61.
Comment 63 Albert Astals Cid 2019-04-08 15:48:13 UTC
I've had a few very busy days lately, haven't been able to test, i'll try to find today but may be it takes me until friday
Comment 64 Albert Astals Cid 2019-04-08 21:12:40 UTC
(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

I can confirm this backport works fine for me on 5.0.x
Comment 65 Emanuele Panigati 2019-04-09 14:49:21 UTC
(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

Works for me too (kernel 5.0.7 x86_64 - Arch Linux)
Comment 66 Matteo Iervasi 2019-04-10 12:28:32 UTC
(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

Working correctly here, using Ubuntu 18.04 with Xanmod kernel + this patch
Comment 67 Dan Čermák 2019-04-10 22:10:01 UTC
(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

The patch works for me too (Dell Precision 5530).
Comment 68 Robert Strube 2019-04-14 05:56:48 UTC
Patch worked for me on 5.0.7 mainline + Ubuntu patches.  Running Ubuntu 19.04 with no problems now.  qq, will this fix make it's way into 5.0.8 mainline?
Comment 69 Dave N 2019-04-14 09:57:10 UTC
This works for me with on a Dell XPS 15 9575 with 1080p display (same as Ralgor) running Arch Linux 5.0.7, but only when patched with this: https://patchwork.freedesktop.org/series/58893/
Comment 70 Juan 2019-04-14 16:56:51 UTC
Created attachment 143967 [details]
journalctl log with drm.debug=14

For some reason the provided patch #143874 didn't work for me, on Fedora kernel 5.0.7 running on a Dell Precision 7530. Full journalctl log provided. This kernel is manually patched, but AFAIK the official kernel was patched already, but it didn't work for me.

It may be another bug, but I doubt it, since it's a very similar case as the rest of the people (Dell laptop, Intel GPU, problem appeared in kernel 5.*)

For now I'm stuck with kernel 4.20.16, which works perfectly.
Comment 71 pbazan 2019-04-15 08:54:10 UTC
Doesn't work for me on Dell XPS 15 9570, still black flickering screen. 
Arch linux, kernel 5.0.7.arch1-1.
Comment 72 Albert Astals Cid 2019-04-15 09:22:34 UTC
(In reply to pbazan from comment #71)
> Doesn't work for me on Dell XPS 15 9570, still black flickering screen. 
> Arch linux, kernel 5.0.7.arch1-1.

But are you using the patch provided in attachment 143874 [details] [review] ? 5.0.7 doesn't have this fix in it.
Comment 73 Albert Astals Cid 2019-04-15 09:24:28 UTC
@Jani i'm setting this back to assigned since there's quite a few people that have verified the patch in comment #61 this fixes the problem for us
Comment 74 pbazan 2019-04-15 10:45:47 UTC
(In reply to Albert Astals Cid from comment #72)
> (In reply to pbazan from comment #71)
> > Doesn't work for me on Dell XPS 15 9570, still black flickering screen. 
> > Arch linux, kernel 5.0.7.arch1-1.
> 
> But are you using the patch provided in attachment 143874 [details] [review] [review]
> ? 5.0.7 doesn't have this fix in it.

Nope, my understanding was the patch was in 5.0.7 already. I will recheck with the patch applied.
Comment 75 Federico Dolce 2019-04-15 15:37:49 UTC
I can confirm that the patch provided in attachment 143874 [details] [review] applied on kernel 5.0.7.arch1-1 works on my Dell XPS 15 9570, while the unpatched kernel does not work.
Comment 76 Juan 2019-04-15 16:06:12 UTC
(In reply to Juan from comment #70)
> Created attachment 143967 [details]
> journalctl log with drm.debug=14
> 
> For some reason the provided patch #143874 didn't work for me, on Fedora
> kernel 5.0.7 running on a Dell Precision 7530. Full journalctl log provided.
> This kernel is manually patched, but AFAIK the official kernel was patched
> already, but it didn't work for me.
> 
> It may be another bug, but I doubt it, since it's a very similar case as the
> rest of the people (Dell laptop, Intel GPU, problem appeared in kernel 5.*)
> 
> For now I'm stuck with kernel 4.20.16, which works perfectly.

I installed now a newer official fedora testing kernel, which I'm sure it has the patch, and it works ok. I probably messed up the kernel build. Sorry for the noise.
Comment 77 Manasi 2019-04-15 17:52:36 UTC
So can we close this bug mow? The reverted patch will get backported to stable 5.0.0

Manasi
Comment 78 Lakshmi 2019-04-15 19:20:47 UTC
@Jani, Can we close this issue?
Comment 79 Albert Astals Cid 2019-04-15 20:12:52 UTC
I'm going to close it myself since from what i understand from emails it'll land on both 5.0.x and to be 5.1

Someone shout very strong if i misunderstood :D

Thanks all involved in developing and testing the fix :)
Comment 80 pbazan 2019-04-15 20:55:20 UTC
(In reply to Federico Dolce from comment #75)
> I can confirm that the patch provided in attachment 143874 [details] [review]
> [review] applied on kernel 5.0.7.arch1-1 works on my Dell XPS 15 9570, while
> the unpatched kernel does not work.

Works for me too, thank you.
Comment 81 Chad Quickstad 2019-04-15 21:01:10 UTC
Fixed in Fedora kernel 5.0.7-200.fc29.x86_64.  After upgrading to it, it booted on my Dell 9570 and I'm running it right now!
Comment 82 Dan Čermák 2019-04-15 21:25:33 UTC
*** Bug 110193 has been marked as a duplicate of this bug. ***
Comment 83 Jani Nikula 2019-04-16 07:14:46 UTC
Fixed upstream by

commit 21635d7311734d2d1b177f8a95e2f9386174b76d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Apr 5 10:52:20 2019 +0300

    drm/i915/dp: revert back to max link rate and lane count on eDP

and the backport is queued for stable v5.0.8.

Thanks everyone for reporting and testing!

Finally one thing that might help us going forward is if all of you affected could attach /sys/kernel/debug/dri/0/i915_vbt please. Does not matter which kernel you're running. Thanks.
Comment 84 Mathieu Garstecki 2019-04-16 07:33:03 UTC
Created attachment 143987 [details]
mgarstecki_i915_vbt

Affected here, attached is my /sys/.../i915_vbt

Dell XPS 15 9570, kernel 4.20.13-arch1-1-ARCH.
Comment 85 Dan Čermák 2019-04-16 08:10:21 UTC
Created attachment 143988 [details]
/sys/kernel/debug/dri/0/i915_vbt with Kernel 5.0.7-4.g012b5f1-default

Attached /sys/kernel/debug/dri/0/i915_vbt running on Kernel 5.0.7-4.g012b5f1-default from openSUSE Tumbleweed on a Dell Precision 5530 that was affected with Kernel 5.0, now fixed.
Comment 86 pbazan 2019-04-16 11:59:16 UTC
Created attachment 143990 [details]
arch linux dell xps 15 9570

Attached
Comment 87 Juan 2019-04-16 16:38:47 UTC
Created attachment 143993 [details]
i915_vbt Dell Precision 7530

/sys/kernel/debug/dri/0/i915_vbt, Fedora, kernel 5.0.7-300.fc30.x86_64, Dell Precision 7530
Comment 88 Matteo Iervasi 2019-04-16 19:10:46 UTC
Here is my dump, done with kernel 5.0.6 (XanMod version), manually compiled with the patch. System is Ubuntu 18.04.2.
Comment 89 Matteo Iervasi 2019-04-16 19:11:32 UTC
Created attachment 144000 [details]
i915 vbt dump
Comment 90 Emanuele Panigati 2019-04-16 20:27:40 UTC
Created attachment 144002 [details]
i915_vbt dump

That's my dump on Dell XPS 9570 running Arch Linux with kernel 5.0.7 compiled with the patch.

5.0.7-arch1-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux


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.