ubuntu 18.04 flickering screen with Radeon X1600

Bug #1791312 reported by Werner Lueckel on 2018-09-07
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
linux (Ubuntu)
Medium
Unassigned

Bug Description

my laptop: HP Compaq nx9420
my grafic card:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530/M56-P [Mobility Radeon X1600] (prog-if 00 [VGA controller])

attachment:
the bug-apport-file

Description:
I start ubuntu 18.04 LTS (Kernel 4.15.0.33) in textmode;
-> as soon as the kernel-module radeon.ko is loaded the screen starts flickering
when starting the grafic-mode the flickering continues; so the screen is unusable.

when setting the option "radeon.modeset=0" (thus: not use radeon drivers) the screen does not flicker
but the resolution is limited to 1400x1050 (instead of natural 1680x1050)
so I can not use this as work-around

when using the old ubuntu 14.04.05 LTS (Kernel 3.13.0-157)
the screen is o.k. NO flickering in textmode, nice grafic, NO flickering
xrandr tells: 1680x1050 60.1

so I must stay on old ubuntu 14.04.05 ???

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 1791312

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
tags: added: bionic
Werner Lueckel (werner-lueckel) wrote :
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Werner Lueckel (werner-lueckel) wrote :

I attached a short video-clip (MOV03422.MPG) showing the flickering screen; that flickering continues in grafic-mode too ...

Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19-rc3

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Werner Lueckel (werner-lueckel) wrote :

I tested the flickering-issue with the upstream-kernel
 "linux-image-unsigned-4.19.0-041900rc3-generic_4.19.0-041900rc3.201809120832_amd64.deb"
and it seemed to be fixed!
No more flickering.
So I added the tag "kernel-fixed-upstream" to this report.

tags: added: kernel-fixed-upstream
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: kernel-bug-exists-upstream
removed: kernel-fixed-upstream
Werner Lueckel (werner-lueckel) wrote :

Sorry, but it turned out that the flickering-issue is NOT really fixed with the upstream-kernel.
Sometimes a boot again ends in a flickering screen as before.
Now I have the following scenario:
- boot 14.04.5 LTS with kernel 3.13.0-157
  -> screen is ALWAYS o.k.; NO flickering
- boot 18.04.1 LTS with upstream-kernel 4.19.0-041900rc3
  -> USUALLY the screen is o.k; BUT SOMETIMES the screen flickers as before
  I found no special reason that may cause/avoid the flickering; just reboot and watch ...
  and if the screen flickers, reboot again and the screen may be o.k. ...

So I replaced the tag "kernel-fixed-upstream" by "kernel-bug-exists-upstream".

my laptop: HP Compaq nx9420
my grafic card:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530/M56-P [Mobility Radeon X1600] (prog-if 00 [VGA controller])
screen resolution: 1680x1050@60.1

when booting UBUNTU "14.04.5 LTS, Trusty Tahr" kernel 3.13.0-160-generic
-> the screen is fine in text-mode and in grafic-mode; NO flickering.
boot-messages say:
[drm] Initialized radeon 2.36.0 ...

BUT,
when booting UBUNTU "18.04.1 LTS (Bionic Beaver)" kernel 4.15.0-36-generic
-> the screen starts heavy flickering as soon as the kernel-module "radeon.ko"
is loaded. The flickering continues in grafic-mode.
here the boot-messages say:
[drm] Initialized radeon 2.50.0 ...
so: this seems to be a new version of radeon.ko.

My question:
- is there a method or a 'hidden flag' to switch radeon.ko-2.50 back to the
  good behaviour of radeon.ko-2.16?

Any chance you can narrow down when the regression occurred and bisect it using git? Please attach your dmesg output and xorg log (if using X).

Created attachment 142154
dmesg Ubuntu14.04, Kernel3.13.0-160, radeon 2.36.0, screen O.K.

Created attachment 142155
dmesg Ubuntu18.04, Kernel4.15.0-36, radeon 2.50.0, screen flickering

- I attached 2 dmesg-listings;
  booting Ubuntu14.04, Kernel3.13 -> screen is o.k.; no flickering
  booting Ubuntu18.04, Kernel4.15 -> screen flickers.
- no Xorg log since the flickering happens already in text-mode
- I did the following test (on Ubuntu18.04):
  . boot with radeon.modeset=0 (thus: disable radeon driver)
    -> screen o.k.; NO flickering
  . then sudo modprobe -v radeon modeset=1
    -> and the flickering starts ...

Created attachment 142156
dmesg Ubuntu14.04, Kernel4.4.0-133, radeon 2.43.0, screen flickering

... and I found out that the screen-flickering already starts with
VERSION="14.04.5 LTS, Trusty Tahr"
kernel: 4.4.0-133-generic
radeon 2.43.0

see the attached dmesg14.04_4.4.0-133.txt

Additional Information:

- I have the same flickering screen with

  Debian Life CD: UBCD-life
    Linux version 3.16.0-4-586
    [drm] Initialized radeon 2.39.0 20080528

some more tests with different systems give the following table:

sorted by radeon-version
system kernel radeon result
------------------------- ----------- -------- --------
UBUNTU 14.04.5 LTS, Trusty Tahr 3.13.0-161 2.36.0 O.K.
puppy_tahr 6.0.5 3.14.56 2.37.0 O.K.
puppy_slacko 6.3.2 3.14.55 2.37.0 O.K
UBCD 3.16.0 2.39.0 FLICKER
puppy_xenialpup 7.5 4.4.95 2.43.0 FLICKER
UBUNTU 14.04.5 LTS, Trusty Tahr 4.4.0-133 2.43.0 FLICKER
UBUNTU 18.04.1 LTS (Bionic Beaver) 4.15.0-36 2.50.0 FLICKER

so the problem seems to start with a radeon.ko driver > 2.37.0;
I wonder how the radeon-version 2.38.0 would work, but, so far, I havn't
found a system including it.

more tests with flickering screen:

- check modelines "xvidtune -show -display :0"
  14.04 trusty (NO flickering)
  "1680x1050" 122.00 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync
  18.04.1 LTS (Flickering screen)
  "1680x1050" 122.00 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync
  -> exactly the same

- on 18.04.1 LTS
  (1) with flickering grafic screen:
  repeatedly switch the screen-mode (xrandr):
    to 1440x900 and back to 1680x1050
  -> typically after 2...5 repetitions the screen is o.k. and stops flickering

  (2) BUT: when the screen awakes from "sleep" -> the flickering starts again!
      switch to text-console (F1) -> flickers too!
      switch back to grafic (F7) -> flickering continues

   the I may continue with (1)
   OR (frustrated):
   BOOT 14.04 trusty; which still works fine; excellent grafic; never flickers;
   ... and start working!

- BUT: what can I do when support for "14.04 trusty" ends?

(In reply to Alex Deucher from comment #1)
> Any chance you can narrow down when the regression occurred and bisect it
> using git? Please attach your dmesg output and xorg log (if using X).

I tried to narrow down the flickering issue making several tests; see my comments below.

(In reply to Alex Deucher from comment #1)
> Any chance you can narrow down when the regression occurred and bisect it
> using git? Please attach your dmesg output and xorg log (if using X).

... sorry, by comments are not below, but "above" ...

(In reply to Werner Lueckel from comment #8)
>
> - BUT: what can I do when support for "14.04 trusty" ends?

Try radeon.new_pll=0

thank you for your tip, but radeon.new_pll=0 gives me
... radeon: unknown parameter 'new_pll' ignored
And: I cannot find 'new_pll' in 'modinfo -p radeon';
So new_pll seems to be (no longer?) a radeon parameter.

Paul Dufresne (paulduf) wrote :

The bug have been reported upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=108514

https://forums.linuxmint.com/viewtopic.php?t=229387
suggest the bug could be "fixed" by creating /usr/share/X11/xorg.conf.d/20-radeon.conf with:

Section "Device"
 Identifier "Radeon"
 Driver "radeon"
 Option "AccelMethod" "glamor"
        Option "TearFree" "on"
EndSection

Someone could try?

Paul Dufresne (paulduf) wrote :

I guess I would rather add the two option lines (with same indentation) to:
file:///usr/share/X11/xorg.conf.d/10-radeon.conf

Paul Dufresne (paulduf) wrote :

Someone said:
"I tried this with a Ubuntu 17.10 and could not boot. I had to use a rescue boot and remove the lines again to get it up and running."
from:https://askubuntu.com/questions/794865/16-04-ati-mobility-radeon-x1600-full-resolution-flickering
So, try with care!

I tried the glamor / tearfree - advice, but: with NO success; still flickering.
And, btw.: I don't think the flickering is an Xorg-issue;
it starts in "textmode" (!!) as soon as the radeon-kernel-driver loads. I think the kernel-driver
does NOT read Xorg-configurations.

Just for fun, I've tested different systems:
System kernel radeon.ko result
UBUNTU-14.04.5 3.13.0-164 2.36.0 O.K
puppy_slacko-6.3.2 3.14.55 2.37.0 O.K.
UBCD 3.16.0 2.39.0 FLICKER
UBUNTU 14.04.5 4.4.0-133 2.43.0 FLICKER
UBUNTU 18.04.1 4.15.0-42 2.50.0 FLICKER

So, I think the problem starts with a modification made in radeon.ko version 2.37.0 --> 2.39.0

Additionally I found a "kind of work-around": switch the mode several times!
thus:
- ignore flickering; start grafic mode
- xrandr --output LVDS --mode 1440x900; sleep 2; xrandr --output LVDS --mode 1680x1050;
- try that 2 ... 5 times until flickering stops!

Paul Dufresne (paulduf) wrote :

Thanks for trying the tearfree option! (ok, it don't work)

By reading: https://wiki.ubuntu.com/Kernel/MainlineBuilds

I discovered: http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
which would allow to download prebuild .deb for old mwainline kernels.

I am a bit sceptical if new versions of ubuntu would boot with so old versions.
But it could help someone pinpoint the problem.

Paul Dufresne (paulduf) wrote :

Well, I tested on my laptop with:
paul@paul-NC210-NC110:~$ cat /proc/version
Linux version 3.14.79-031479-generic (kernel@gloin) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #20160910530 SMP Sun Sep 11 09:41:06 UTC 2016

When I used gdebi to install the kernel .deb, in the details, there were some errors.
I believe this was because I did not installed headers .deb before...
I would suggest you install the headers .deb before... but it work even without
the headers .deb.
Also gdebi said version was already installed: I am pretty sure it was not.

I lost my wifi however after rebooting with that version (I plugged Ethernet wire for writing
this).

And I am on Linux Mint 19.1.
When I rebooted, it continue to boot with old kernel, and was not showing me the menu...
even if I pressed Esc and Shift.

So I edited /etc/default/grub from:
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0

to:
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10

but I think this could be needed only on Mint.

after that, advanced options were showing, and I was able to select old kernel version.

Paul Dufresne (paulduf) wrote :

I just retried by installing headers, then reinstall kernel-generic.
This time wifi works.
Note that these packages won't show in Synaptic.
Will show in dpkg -l|grep kernel. Use dpkg -r to remove them.

.. as recommended I tried 3.14.79-031479-generic;
giving me radeon.ko version 2.37.0 and the screen is o.k. No flickering.
btw. I had the same result e.g. with "puppy_tahr 6.0.5 boot CD" which has the same radeon-version (2.37.0).
My guess: the flickering-problem starts with radeon 2.39.0 upward. See my table above (a little messed-up due to lacking blanks).

Paul Dufresne (paulduf) wrote :

Ok, I have access at "work" on a Compaq nx9420, for a few days.

linux 3.15.0-rc2 is first one to flickers, but goes to busybox

linux 3.15.0-rc1 does not flickers, but goes to busybox
  I found: mounting /dev/sda1 on /root: invalid argument
  and then initrd not mounting.

previous version, 3.14.79: no flickers, boot to graphics mode

will try to study changes for 3.15.0-rc2

Paul Dufresne (paulduf) wrote :

From: https://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc2-trusty/CHANGES
I see the folowing changes for radeon:

Alex Deucher (13):
      drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
      drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
      drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
      drm/radeon/dp: switch to the common i2c over aux code
      drm/radeon: fix audio pin counts for DCE6+ (v2)
      drm/radeon: disable mclk dpm on R7 260X
      drm/radeon: fix runpm handling on APUs (v4)
      drm/radeon: update CI DPM powertune settings
      drm/radeon: add support for newer mc ucode on SI (v2)
      drm/radeon: add support for newer mc ucode on CI (v2)
      drm/radeon: re-enable mclk dpm on R7 260X asics
      drm/radeon/si: make sure mc ucode is loaded before checking the size
      drm/radeon/ci: make sure mc ucode is loaded before checking the size

Christian König (2):
      drm/radeon: apply more strict limits for PLL params v2
      drm/radeon: improve PLL params if we don't match exactly v2

Christoph Jaeger (2):
      ...
      drm/radeon: fix VCE fence command

Quentin Casasnovas (1):
      drm/radeon: memory leak on bo reservation failure. v2

The:
Christian König (2):
      drm/radeon: apply more strict limits for PLL params v2
      drm/radeon: improve PLL params if we don't match exactly v2
rings a bell for me, because I believe someone somewhere was saying that a kernel parameter
speaking of PLL was fixing the problem... but people did not find PLL parameters for radeon,
so people did not follow about that comment.

From:
https://www.x.org/releases/current/doc/man/man4/radeon.4.xhtml
I see:
Option "LVDSProbePLL" "boolean"
When BIOS panel information isn’t available (like on PowerBooks), it may still be necessary to
use the firmware-provided PLL values for the panel or flickering will happen. This option will
force probing of the current value programmed in the chip when X is launched in that case.
This is only useful for LVDS panels (laptop internal panels). The default is on.
Also:
Option "DefaultTMDSPLL" "boolean"
Use the default driver provided TMDS PLL values rather than the ones provided by the BIOS.
This option has no effect on Mac cards.
Enable this option if you are having problems with a DVI monitor using the internal TMDS controller.
The default is off.

Also:
      drm/radeon: update CI DPM powertune settings
ring an other bell, because I think I remember someone saying something about DPM in some message.
Sorry for not being more specific.

A similar, older fixed closed bug:
https://bugzilla.kernel.org/show_bug.cgi?id=26552

Paul Dufresne (paulduf) wrote :

Indeed, the two radeon parameters for PLL mention in previous message
does not seems to appear anymore in modinfo radeon.

paul@paul-NC210-NC110:~/linux-stable$ git log --oneline v3.15-rc1..v3.15-rc2 | grep radeon
bcddee29b0b8 drm/radeon/ci: make sure mc ucode is loaded before checking the size
8c79bae6a30f drm/radeon/si: make sure mc ucode is loaded before checking the size
f8a2645ecede drm/radeon: improve PLL params if we don't match exactly v2
74073c9dd299 drm/radeon: memory leak on bo reservation failure. v2
681941c1790b drm/radeon: fix VCE fence command
7e1858f9aff7 drm/radeon: re-enable mclk dpm on R7 260X asics
277babc374f6 drm/radeon: add support for newer mc ucode on CI (v2)
1ebe92802eaf drm/radeon: add support for newer mc ucode on SI (v2)
5fb9cc4d8b16 drm/radeon: apply more strict limits for PLL params v2
6abc6d5c73b2 drm/radeon: update CI DPM powertune settings
90c4cde9d5a2 drm/radeon: fix runpm handling on APUs (v4)
57700ad1f2f2 drm/radeon: disable mclk dpm on R7 260X
8902e6f2b832 drm/radeon: Improve vramlimit module param documentation
be0949f5eb9c drm/radeon: fix audio pin counts for DCE6+ (v2)
379dfc25e257 drm/radeon/dp: switch to the common i2c over aux code
25377b921b40 drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
paul@paul-NC210-NC110:~/linux-stable$

paul@paul-NC210-NC110:~/linux-stable$ git show 5fb9cc4d8b16
commit 5fb9cc4d8b1639b9a7487c1ee7b2b0c52877327d
Author: Christian König <email address hidden>
Date: Fri Apr 4 13:45:42 2014 +0200

    drm/radeon: apply more strict limits for PLL params v2

    Letting post and refernce divider get to big is bad for signal stability.

    v2: increase the limit to 210

    Signed-off-by: Christian König <email address hidden>

diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 386cfa4c194d..2f42912031ac 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -937,6 +937,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
        }
        post_div = post_div_best;

+ /* limit reference * post divider to a maximum */
+ ref_div_max = min(210 / post_div, ref_div_max);
+
        /* get matching reference and feedback divider */
        ref_div = max(den / post_div, 1u);
        fb_div = nom;
paul@paul-NC210-NC110:~/linux-stable$
I might try to recompile kernel with that line commented out.
But it has been many years I did not compile a kernel.

Paul Dufresne (paulduf) wrote :

Well, It seems to take more than 12 hours ( I did stopped it ) to compile a
kernel (many features deactivated) on my atom based laptop. Will retry.

But the line I wanted to comment out does not seems to exist anymore.

But I found that the function to select PLL values show them before returning
in a DRM_DEBUG_KMS macro. I also found that if booted with kernel parameter
drm.debug=4 then KernelModeSettings related messages are added to dmesg output.

So I expect to be able to compare tomorrow PLL values for the old version where
the bug does not manifest to a new one where the bug manifest itself.

I am comparing PLL values for a not flickering kernel:
Linux version 3.14.79-031479-generic
and version 4.15 (recent one):

Linux 4.15:
Flickering values
[ 5.554557] [drm:radeon_compute_pll_avivo [radeon]] 122000 - 121980, pll dividers - fb: 253.0 ref: 8, post 7
[ 465.773119] [drm:radeon_compute_pll_avivo [radeon]] 122000 - 121980, pll dividers - fb: 253.0 ref: 8, post 7
[ 503.796178] [drm:radeon_compute_pll_avivo [radeon]] 122000 - 121980, pll dividers - fb: 253.0 ref: 8, post 7

Linux version 3.14.79-031479-generic: no flickering
[4.250932] [drm:radeon_compute_pll_avivo], 12201, pll dividers - fb: 189.8 ref: 6, post 7
[ 230.376566] [drm:radeon_compute_pll_avivo], 12201, pll dividers - fb: 189.8 ref: 6, post 7

122000 is about 10x 12201
I don't know what are these values, but it seems very different!

I had determined that 3.15-rc2 was the first version where flickering appears.
I guess it could be related to:
https://lists.freedesktop.org/archives/dri-devel/2014-April/057800.html

Created attachment 143324
Paul's dmesg with drm.debug=4 on kernel 3.14_79 (No flickering)

Created attachment 143325
Paul Dufresne's Xorg.0.log for k3.14.79 no_flickering

Created attachment 143326
dufresnep's dmesg for kernel 4.15.0-45-generic (Linux Mint) with drm.debug=4 with a lot of flickering

Created attachment 143327
dufresnep's Xorg.0.log for kernel 4.15.0-45 (Mint 19) with drm.debug=4 lots of flickering

Created attachment 143328
dufresnep's dmesg for kernel 4.15.0-45-generic with drm.debug=0 with strangely no flickering

Created attachment 143329
dufresnep's xorg log for kernel 4.15.0 with drm.debug=0 strangely without flickering

Created attachment 143330
dmesg for kernel 5.0rc5 with flickering and debug=4

Created attachment 143331
Xorg.0.log for kernel 50rc5 with flickering

flickering had began only when in graphics mode ... usually begins while text display at boot

Created attachment 143332
dufrp's Xorg.0.log for kernel 5.0rc5 (xstart as root) with no flickering

Created attachment 143333
dufrp's dmesg for kernel 5.0rc5 (xstarted as root) with no flickering

Created attachment 143334
output of sudo dmidecode > dmidecode.txr

Created attachment 143335
sudo lspci -nnvvk > lspci_while_flickering.txt

fv (fratiman-vladut) wrote :

Same laptop, same problem.
Thanks for workaround using commands: xrandr ..; sleep 2; xrandr ...;

I have done a git bisect:
client@client-LIFEBOOK-AH531 ~/mylinux $ git bisect good
f8a2645ecede4eaf90b3d785f2805c8ecb76d43e is the first bad commit
commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e
Author: Christian König <email address hidden>
Date: Wed Apr 16 11:54:21 2014 +0200

    drm/radeon: improve PLL params if we don't match exactly v2

    Otherwise we might be quite off on older chipsets.

    v2: keep ref_div minimum

    Signed-off-by: Christian König <email address hidden>

:040000 040000 a2150329e19966a1eb911d1d1ac74e865f002b1b 7220bfcf2fad7f94f071376fdd5aedd3d358545c M drivers
client@client-LIFEBOOK-AH531 ~/mylinux $

client@client-LIFEBOOK-AH531 ~/mylinux $ git bisect log
# bad: [a798c10faf62a505d24e5f6213fbaf904a39623f] Linux 3.15-rc2
# good: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1
git bisect start 'v3.15-rc2' 'v3.15-rc1' '--' 'drivers/gpu/drm/radeon'
# good: [681941c1790b92207334d08ee017007685f35438] drm/radeon: fix VCE fence command
git bisect good 681941c1790b92207334d08ee017007685f35438
# skip: [8902e6f2b832e00e10c6f9e9532f6f63feb4972f] drm/radeon: Improve vramlimit module param documentation
git bisect skip 8902e6f2b832e00e10c6f9e9532f6f63feb4972f
# bad: [bcddee29b0b87af3aeda953840f97b356b24dc5e] drm/radeon/ci: make sure mc ucode is loaded before checking the size
git bisect bad bcddee29b0b87af3aeda953840f97b356b24dc5e
# bad: [f8a2645ecede4eaf90b3d785f2805c8ecb76d43e] drm/radeon: improve PLL params if we don't match exactly v2
git bisect bad f8a2645ecede4eaf90b3d785f2805c8ecb76d43e
# good: [74073c9dd29905645feb6dee03c144657a9844cd] drm/radeon: memory leak on bo reservation failure. v2
git bisect good 74073c9dd29905645feb6dee03c144657a9844cd
# first bad commit: [f8a2645ecede4eaf90b3d785f2805c8ecb76d43e] drm/radeon: improve PLL params if we don't match exactly v2
client@client-LIFEBOOK-AH531 ~/mylinux $

Created attachment 143368
git show of firt bad commit

Antonio Ferraro (anfe67) wrote :

Same problem here: Laptop is a HP 255 G6 based on AMD E2-9000e, Ubuntu is 18.04 64 bits, kernel 4.15.0-45-generic, wide monitor is LG LG 25UM58-P, 2560x1080.

It does not always flicker, but it does when playing video or when using applications in full screen mode (or in general when using most of the surface of the wide screen). Monitor is connected through HDMI, other monitors with lower resolutions do not flicker.

The following patch seems to work for me:
client@client-LIFEBOOK-AH531 ~/Téléchargements $ diff -u old/linux-4.19.21/drivers/gpu/drm/radeon/radeon_display.c linux-4.19.21/drivers/gpu/drm/radeon/radeon_display.c
--- old/linux-4.19.21/drivers/gpu/drm/radeon/radeon_display.c 2019-02-12 13:47:27.000000000 -0500
+++ linux-4.19.21/drivers/gpu/drm/radeon/radeon_display.c 2019-02-14 15:29:37.743229474 -0500
@@ -921,12 +921,14 @@
  ref_div_max = max(min(100 / post_div, ref_div_max), 1u);

  /* get matching reference and feedback divider */
- *ref_div = min(max(DIV_ROUND_CLOSEST(den, post_div), 1u), ref_div_max);
+ // was: *ref_div = min(max(DIV_ROUND_CLOSEST(den, post_div), 1u), ref_div_max);
+ *ref_div = min(max((den/post_div), 1u), ref_div_max);
  *fb_div = DIV_ROUND_CLOSEST(nom * *ref_div * post_div, den);

  /* limit fb divider to its maximum */
  if (*fb_div > fb_div_max) {
- *ref_div = DIV_ROUND_CLOSEST(*ref_div * fb_div_max, *fb_div);
+ // was: *ref_div = DIV_ROUND_CLOSEST(*ref_div * fb_div_max, *fb_div);
+ *ref_div = (*ref_div * fb_div_max) / (*fb_div);
   *fb_div = fb_div_max;
  }
 }
client@client-LIFEBOOK-AH531 ~/Téléchargements $

Created attachment 143381
.config file specifically for Compaq NX9420 on linux 4.19.21

Created attachment 143413
patch radeon-display.c for latest kernel (5.0.0-rc7)

tags: added: patch
Kai-Heng Feng (kaihengfeng) wrote :

Paul,

Since you already bisected the commit, please file an upstream bug at https://bugs.freedesktop.org/
Product: DRI
Component: DRM/Radeon

So the radeon maintainers can work on a fix.

Thanks to Paul Dufresne a patch in "radeon_display.c" seems to fix the bug.
So the radeon maintainers should work on an upstream fix.

Is there any chance to get the patch implemented into 18.04 LTS?
The flickering screen is really annoying ...

Timo Jyrinki (timo-jyrinki) wrote :

Being fixed in upstream https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2&id=2e26ccb119bde03584be53406bbd22e711b0d6e6

Maybe a candidate for SRUs too after the fix hits eoan (19.10).

Whatsapp is well known messenger app.It is used worldwide for messaging when we download status from it we can face problem. By the use of this site https://downloadstatus.xyz we can download it for free.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
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.