Dell XPS 13 9380 flickering (Whiskey Lake)

Bug #1826125 reported by Paulo Matos on 2019-04-24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

A brand new Dell XPS 13 9380 preinstalled with Ubuntu 18.04 flickers to the point of being totally unusable.

I have upgraded since to 18.10 and 19.04 with no changes. I have tried several combinations of the i915 parameters fastboot, enable_rc6 and enable_fbc to no avail.

Examples of flickering are here:
ProblemType: Bug
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
 /dev/snd/controlC0: gdm 1430 F.... pulseaudio
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see
DistroRelease: Ubuntu 19.04
InstallationDate: Installed on 2019-04-13 (10 days ago)
InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38
MachineType: Dell Inc. XPS 13 9380
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1035-oem root=UUID=252898e9-6e96-4705-a709-2db930b7c4c7 ro quiet splash i915.fastboot=1 i915.enable_rc6=0 vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-1035.40-oem 4.15.18
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
 linux-restricted-modules-4.15.0-1035-oem N/A
 linux-backports-modules-4.15.0-1035-oem N/A
 linux-firmware 1.178
Tags: disco
Uname: Linux 4.15.0-1035-oem x86_64
UpgradeStatus: Upgraded to disco on 2019-04-24 (0 days ago)

_MarkForUpload: True 02/14/2019
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.2.1 0KTW76
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.2.1:bd02/14/2019:svnDellInc.:pnXPS139380:pvr:rvnDellInc.:rn0KTW76:rvrA00:cvnDellInc.:ct10:cvr: XPS XPS 13 9380
dmi.sys.vendor: Dell Inc.

Paulo Matos (pmatos) wrote :

Having problems posting apport data due to:
$ ubuntu-bug -c cartsheel.apport -u 1826125
Usage: ubuntu-bug [options] [symptom|pid|package|program path|.apport/.crash file]

ubuntu-bug: error: -u/--update-bug option cannot be used together with options for a new report

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Paulo Matos (pmatos) on 2019-04-24
affects: ubuntu → linux (Ubuntu)

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1826125

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete

apport information

tags: added: apport-collected disco
description: updated
Paulo Matos (pmatos) wrote : CRDA.txt

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Paulo Matos (pmatos) wrote :

I will give it a try. Is this just a matter of adding the ppa and `apt-get install drm-intel-nightly`?

Kai-Heng Feng (kaihengfeng) wrote :

Download linux-image-unsigned-5.1.0-994-generic_5.1.0-994.201904222200_amd64.deb and linux-modules-5.1.0-994-generic_5.1.0-994.201904222200_amd64.deb then install them.

Paulo Matos (pmatos) wrote :

Thanks Kai. Unfortunately it's still not ok. Interestingly now there is no flickering per-se. What I see is display corruption and flickering when refresh occurs - for example by moving the mouse or typing something.

Is there anything else I can try at this point? Or any further information I can provide?

pmatos@cartwheel:~$ dmesg
[ 0.000000] Linux version 5.1.0-994-generic (kernel@gloin) (gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)) #201904222200 SMP Tue Apr 23 02:04:43 UTC 2019
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.1.0-994-generic root=UUID=252898e9-6e96-4705-a709-2db930b7c4c7 ro quiet splash i915.fastboot=1 i915.enable_rc6=0 vt.handoff=1
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Hygon HygonGenuine
[ 0.000000] Centaur CentaurHauls
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
[ 0.000000] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
[ 0.000000] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.

Paulo Matos (pmatos) wrote :

Removed the i915 boot params : i915.fastboot=1 i915.enable_rc6=0
No changes.

Kai-Heng Feng (kaihengfeng) wrote :

Can you boot with kernel parameter "drm.debug=0xe" and attach full dmesg after boot?

Paulo Matos (pmatos) wrote :

Sure. Results are attached next.

Paulo Matos (pmatos) wrote :
Kai-Heng Feng (kaihengfeng) wrote :

Does "i915.enable_psr=0" help?

Paulo Matos (pmatos) wrote :

Unfortunately not. It actually makes the flickering more like in the pre-5 kernel where it flickers constantly as opposed to only when the move is moved. Posting new dmesg with i915.enable_psr=0 in case its useful.

Paulo Matos (pmatos) wrote :

I have upgraded the BIOS to 1.2.1 but not changed its settings. Could it be that there's something there that I could try?

Paulo Matos (pmatos) wrote :
Timo Aaltonen (tjaalton) wrote :

Sounds like you should contact the upstream developers and file a bug at

It seems that the panel has been changed to another device since XPS13 was enabled by Canonical, wouldn't be the first time. Are you able to test windows on it? (to rule out the machine itself being faulty)

Paulo Matos (pmatos) wrote :

Hummm, I have almost zero experience with windows. Is there a windows version that I can install for free - windows 10 maybe?

Also, if the machine is faulty wouldn't it flicker during BIOS setup as well?

Timo Aaltonen (tjaalton) wrote :

maybe it would, yes..

anyway, best to file a bug upstream and link it here

summary: - Dell XPS 13 9380 flickering (Intel Kaby Lake)
+ Dell XPS 13 9380 flickering (Whiskey Lake)

Created attachment 144092
dmesg from boot

This was previously reported here:

Brand new XPS 13 9380 arrived a couple of days ago from Dell with Ubuntu 18.04 preinstalled.

Flickering started immediatelly post boot and it was constant.
I updated BIOS from 1.1.1 to 1.2.1, tried i915.fastboot and i915.enable_rc6 combinations to no avail.

Updated to Ubuntu 19.04 and kernel-5 to no avail. However flickering changed from constant to only if there's a screen refresh.

Videos pre kernel 5:

Videos post kernel 5:

I attach dmesg from boot.

Paulo Matos (pmatos) wrote :

Timo, opened upstream as suggested:

Paulo Matos (pmatos) wrote :

Timo, it seems I can install windows 10 on a usb flash for installation. Will try that.

Paulo Matos (pmatos) wrote :

I am however betting this is not a hw bug due to the way the flickering changed with the kernel upgrade. Compare the first video posted in this report and now:

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed

and happens with current nightly too

Stan, any help here? I see hotplug events in dmesg.

Tiffany (hsiaoting) wrote :

Hi Paulo Matos,

Could you please help go through Dell Diagnostics tool by pressing F12 when booting.

We need hardware information & test result to triage and troubleshoot.

Thank you.

Paulo Matos (pmatos) wrote :

Tiffany, apologies for the delay on this. I have been on holidays. Running the tests now.

Paulo Matos (pmatos) wrote :

All basic tests passed. I attach Configuration shown by the checker. Let me know if you need anything else.

Kai-Heng Feng (kaihengfeng) wrote :

Can you try "nomodeset" kernel parameter?

Paulo Matos (pmatos) wrote :
Paulo Matos (pmatos) wrote :
Paulo Matos (pmatos) wrote :

I should point out that I discussed with some other owners of this same laptop and they are not seeing the same issue with a normal FullHD display. It seems to be related to the new 4K display shipped with this laptop.

Paulo Matos (pmatos) wrote :

Kai, `nomodeset` works!!! huh, what happened? It boots and all looks good.
If I use it on a daily basis, which side-effects will it have?

Tiffany (hsiaoting) wrote :

@Paulo Matos,

We contacted the manufacturer and got some feedback this might be hardware dispatches.

Please consider reaching your local Dell support.

Thank you.

Kai-Heng Feng (kaihengfeng) wrote :

"nomodeset" is just a way to check if the panel is intact. It disables Intel graphics driver, so you'll lose all graphics acceleration by doing that.

It'll also drastically increase the power consumption of your laptop.

Let's wait for Intel graphics maintainer's reply.

Paulo Matos (pmatos) wrote :

What do you mean by hardware dispatches?
I contacted dell support. They were utterly useless as soon as I told them I am using the pre-installed ubuntu system. They have close to zero-knowledge when something comes up Linux related. They basically keep forwarding me to the dell drivers page to update the drivers which says 'We do not provide drivers for ubuntu systems', although they know a priori I am using ubuntu.

Ping? With 5.0 and up PSR seems to be messing with the results, but disabling it doesn't fix the original issue.

If I can help at all sorting this one out let me know. logs, ssh access to the machine, you name it.

Timo Aaltonen (tjaalton) wrote :

Would you mind testing an older oem kernel from bionic? Install 'linux-image-4.15.0-1034-oem' and remember to select it from the boot menu.

agiani (agiani) wrote :

I have the same flickering problem, but I don't have it with PCLinuxOS running kernel 5.0.2:

Linux localhost.localdomain 5.0.2-pclos1 #1 SMP Wed Mar 13 20:05:56 CDT 2019 x86_64 x86_64 x86_64 GNU/Linux

Hope it helps.


Paulo Matos (pmatos) wrote :

Interesting. @agiani, do you have the Dell with the 4K display?
From your post I assume you tested ubuntu, saw the flickering and then reinstalled PCLinuxOS, which with 5.0.2 does not show flickering. Is this correct?

agiani (agiani) wrote :

Sorry form my English :-D

Yes, I have the Dell with the 4k display.
I have try all linux distribution (Fedora, Suse, Mint, Sabayon, ecc.) and all flickering!
PclinuxOS does not flickering.

Paulo Matos (pmatos) wrote :

Interesting because it flickers with ubuntu and kernel 5.1.0 which is more recent than 5.0.2. I am not an expert here, Timo, Kai, Tiffany, any ideas of what PCLinuxOS might have to fix this?

Timo Aaltonen (tjaalton) wrote :

hard to tell, but I know that changes in 5.0.6 (which the ubuntu kernel in 19.04 basically has) likely did not regress this way

but you are free to test a mainline build of 5.0.2

Created attachment 144287
[PATCH] drm/i915: Dump the full ESI register block on short pulse

This patch might help us figure out what the sink is trying to tell us.

thanks Ville, here's a kernel deb based on drm-intel-next-fixes-2019-05-15 plus this patch

Paulo, please install, boot with drm.debug=14 and attach dmesg

Changed in linux:
importance: Medium → Critical
status: Confirmed → Incomplete
Paulo Matos (pmatos) wrote :

I just attempted to boot this kernel but it literally bricks my system. As soon as it tries to boot, the system restarts. Problem is that grub UEFI doesn't give me a choice of kernel to boot, therefore I have no idea how to proceed as the system keeps trying to boot a kernel that restarts the system. Any suggestions?

agiani (agiani) wrote :

is it possible to try the new kernel with the fix via ubuntu live usb persistent?

Kai-Heng Feng (kaihengfeng) wrote :

Please change "GRUB_TIMEOUT=0" in /etc/default/grub to a positive number, like "GRUB_TIMEOUT=2".

Then run `sudo update-grub`.

Paulo Matos (pmatos) wrote :

Thanks Kai. I might have to do this through a ubuntu live installation in a flash since my system is bricked. I am travelling at the moment until Sunday so I might not be able to get to it until then. My apologies for the slow response on this.

Timo Aaltonen (tjaalton) wrote :

it's not bricked, you should be able to get the grub menu by hitting esc

and which kernel are we talking about?

Paulo Matos (pmatos) wrote :

Timo, forget about the kernel issue. I managed to get it to work. ESC helped.

Let me reply in the proper thread...

Created attachment 144318
Timo rc5+ kernel dmesg

Timo, I have attached the dmesg with rc5+ kernel you asked me to test.

[ 4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00 00 00 00 00 81 01

According to that the sink thinks everything is fine, so no idea why generates short hpds.

Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the kernel cmdline.

(In reply to Ville Syrjala from comment #9)
> [ 4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00
> 00 00 00 00 81 01
> According to that the sink thinks everything is fine, so no idea why
> generates short hpds.
> Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the
> kernel cmdline.

enable_psr=0 does not help. Posting dmesg with enable_psr=0.

Created attachment 144319
rc5+ kernel with enable_psr=0

In it is mentioned that the same laptop with PCLinuxOS with 5.0.2 doesn't flicker. Is it worth it getting some data from there perhaps?

Paulo Matos (pmatos) wrote :

@agiani, are you using in PCLinuxOS any kernel options?

(In reply to Paulo J. Matos from comment #11)
> Created attachment 144319 [details]
> rc5+ kernel with enable_psr=0

The log was cut off so couldn't see that PSR was in fact disabled. You can fix that by passing eg. log_buf_len=2M to the kernel cmdline.

Anyways, after a second glance at the logs I see the sink does sometimes indicate that the receiver port was not synchronized. Not sure why the failure manifests at that level with the link otherwise being reported as stable. Looks like we could try to reduce the link rate a bit and still have enough bandwidth for the 4k@60 mode. I'll attach something to that effect.

Created attachment 144325
[PATCH] hack: Disable 5.4ghz link rate for skl

This should drop the link rate to 4.32ghz, which is the lowest we can go with this panel. Please test.

Hmm, yes 4.32 is what the BIOS uses, so this might even help:
[ 1.391106] [drm:intel_dump_pipe_config [i915]] port clock: 432000, pipe src size: 3840x2160, pixel rate 533299

Hmm. That probably means this is a victim of commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"), which I think would have picked the lower link rate for us.

Yes, eDP revision seems to be 1.4a:
[ 1.385017] [drm:intel_dp_init_connector [i915]] eDP DPCD: 04 92 a5
so I believe that is indeed what would have happened.

agiani (agiani) wrote :

I use PcLinuxOS without kernel options, you can try starting PcLinuxOS live USB to see that it works without any parameters.
I attach dmesg PCLinuxOS output.

Timo Aaltonen (tjaalton) wrote :

Do you have a kernel update for pclinuxos with 5.0.8 or newer? I bet that's broken, as speculated on the fdo bug.

agiani (agiani) wrote :

I can try to install the 5.1.4 version present in the PclinuxOS repositories and see what happens!
Why do you think that with versions later than 5.0.2 it doesn't work?
Why does it work properly with version 5.0.2?

agiani (agiani) wrote :

you're right, with 5.1.4 it doesn't work.
Can't understand what's different in 5.0.2 that makes it work?

agiani (agiani) wrote :

I attach dmesg output after updating the kernel to 5.1.4

Paulo Matos (pmatos) wrote :

@agiani ville explained it in #72, #73 and #74.
I haven't managed to try the patch Ville provided as I need to do a full kernel build and haven't had the time to look into it yet.

agiani (agiani) wrote :

Ok @Paulo,
unfortunately I do not speak English
and I do not understand it well
I am also not a linux expert.

I can confirm that with Timo's kernel, with Ville's patch it all works smoothly.
Great job guys! Thanks so much for the support. I will keep using this kernel until upstream is fixed. Can you please update this bug once a proper fix hits upstream?

Changed in linux:
status: Incomplete → In Progress

Can we get a test with just 'git revert f11cb1c19ad0' ?

kernel -10 with the revert availabe behind the same url

but reverting it would reopen 109959

Changed in linux:
status: In Progress → Incomplete

Paulo, please test kernel build -10

Apologies, I dropped the ball on this one. I will do that today.

I can confirm that the kernel with the reverted commit works. Apologies for the delay.

Changed in linux:
status: Incomplete → Confirmed

Hi all,

I have been following this bug report for a while - I just wanted to check in on status. Will the fix be rolled out now that Paulo has confirmed the working kernel version?

Created attachment 144765
[PATCH] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

Here's an attempt at fixing this without horribly breaking a bunch of other eDP panels. Would appreciate if people can test this.

Also available here in git form:
git:// dp_retry_max_vs_optim

Changed in linux:
status: Confirmed → Incomplete
Thomas SIMON (dev.uhuru) wrote :

Hello, I would like to note that I think that I also have something related to this bug - although with the normal 1920x1024 panel (on XPS 13 9380) with a fresh Ubuntu 19.04 install (so kernel 5+) - I did not test the OEM Ubuntu 18.04 LTS.

The screen "flickers" from time to time (perhaps linked to refresh?) barely noticeable during the day but a lot more often at night with redshift / gnome night light enabled.

Daniel C (djcater) wrote :

Hi Thomas, that sounds very similar to what we are seeing over in bug 1827790.

Thomas SIMON (dev.uhuru) wrote :

Many thanks, you are right, I'll post there!

Brad Figg (brad-figg) on 2019-07-24
tags: added: ubuntu-certified
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.