ubuntu 18.04 flickering screen with Radeon X1600

[Werner Lueckel]

=== SRU Justification ===
[Impact]
Screen flickers when using radeon.ko.
It's a regression, it didn't happen on Trusty.

[Fix]
Quote the original commit log:
"Instead of the closest reference divider prefer the lowest".

[Test]
Affected user confirms it fixes the issue.

[Regression Potential]
Low. Only affect radeaon, and it's in upstream stable tree.

=== Original Bug Report ===
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 ???

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

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.

[Werner Lueckel (werner-lueckel)]

you can find the missing logfile as attachment:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791312/+attachment/5186052/+files/apport.linux-image-4.15.0-33-generic.s5j_wb2y.apport

[Werner Lueckel (werner-lueckel)]

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

[Joseph Salisbury (jsalisbury)]

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

[Werner Lueckel (werner-lueckel)]

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.

[Werner Lueckel (werner-lueckel)]

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".

[Werner-lueckel-m (werner-lueckel-m)]

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?

[Alexdeucher (alexdeucher)]

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).

[Werner-lueckel-m (werner-lueckel-m)]

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

[Werner-lueckel-m (werner-lueckel-m)]

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

[Werner-lueckel-m (werner-lueckel-m)]

- 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 ...

[Werner-lueckel-m (werner-lueckel-m)]

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

[Werner-lueckel-m (werner-lueckel-m)]

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

[Werner-lueckel-m (werner-lueckel-m)]

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.

[Werner-lueckel-m (werner-lueckel-m)]

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?

[Werner-lueckel-m (werner-lueckel-m)]

(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.

[Werner-lueckel-m (werner-lueckel-m)]

(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" ...

[Klaus-weiss (klaus-weiss)]

(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

[Werner-lueckel-m (werner-lueckel-m)]

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)]

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)]

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)]

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!

[Werner Lueckel (werner-lueckel)]

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)]

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)]

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)]

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.

[Werner Lueckel (werner-lueckel)]

.. 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)]

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)]

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)]

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)]

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.

[Paul Dufresne (paulduf)]

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!

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

Created attachment 143334
output of sudo dmidecode > dmidecode.txr

[Paul Dufresne (paulduf)]

Created attachment 143335
sudo lspci -nnvvk > lspci_while_flickering.txt

[fv (fratiman-vladut)]

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

[Paul Dufresne (paulduf)]

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 $

[Paul Dufresne (paulduf)]

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 $

[Paul Dufresne (paulduf)]

Created attachment 143368
git show of firt bad commit

[Antonio Ferraro (anfe67)]

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.

[Paul Dufresne (paulduf)]

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 $

[Paul Dufresne (paulduf)]

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

[Paul Dufresne (paulduf)]

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

[Kai-Heng Feng (kaihengfeng)]

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.

[Werner-lueckel-m (werner-lueckel-m)]

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.

[Werner-lueckel-m (werner-lueckel-m)]

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

[Timo Jyrinki (timo-jyrinki)]

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).

[Bholeshankar1992crax (bholeshankar1992crax)]

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.

[Paul Dufresne (paulduf)]

The patch is included in:
Linux 4.14.125
Linux 4.19.50
Linux 5.1.9

[Paul Dufresne (paulduf)]

The patch is included in:
Linux 4.14.125
Linux 4.19.50
Linux 5.1.9
I don't have access to the laptop on which I investigated this problem anymore.

But it could be tested from the built kernel packages at:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.125/
https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.50/
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.1.9/
Install linux-headers then linux-modules then linux-image (I think)

In fact, testing on other ATI hardware too see not bad results happen would be... reassuring.

[Kai-Heng Feng (kaihengfeng)]

Please test kernel here:
https://people.canonical.com/~khfeng/lp1791312/

[Werner Lueckel (werner-lueckel)]

I've tested the kernel 4.15.0-52 (from khfeng) on my laptop and found: THE FLICKERING IS GONE!
Screen is O.K. in text and graphic - mode. Console switching works too.
So, Paul's bugfix seems to work! Many thanks!
I found one small thing:
the new radeon.ko - module identifies itself still as
"... Initialized radeon 2.50.0 20080528";
same like the buggy version.
So it is difficult to distinguish the "good" from the "buggy" - module.

[Werner Lueckel (werner-lueckel)]

today I've updated the kernel to the current version 4.15.0-54 and ... the screen flickers again (!!!)
while the version from https://launchpad.net/~kaihengfeng is working perfectly!!!
The differences:
current kernel 4.15.0-54: radeon.ko version: 2.50.0; module-size: 2342342
kaihengfeng kernel 4.15.0-52 unsigned: radeon.ko version: 2.50.0; module-size: 2343086
So the module in 4.15.0-54 seems NOT to be the same as that one corrected by Paul Dufresne / Kai-Heng Feng.
And: wouldn't it be a good idea to change the radeon.ko version-number too to identify the different versions?

[Werner Lueckel (werner-lueckel)]

Fix in Bionic does NOT work; see comment #65

[Werner Lueckel (werner-lueckel)]

instead of "In Progress" I better set the Status to "Confirmed"

[Kleber Sacilotto de Souza (kleber-souza)]

Hi Werner,

The fix for this bug hasn't been released yet, so kernel 4.15.0-54 is expected to still have the issue. A new kernel version containing the fix is planned to be published to -proposed this week and an automated comment will be added when the new version is available for testing. Meanwhile please keep the tasks as 'Fix Committed' to correct reflect their current status.

Thank you.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-cosmic' to 'verification-done-cosmic'. If the problem still exists, change the tag 'verification-needed-cosmic' to 'verification-failed-cosmic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Werner Lueckel (werner-lueckel)]

I've tested the kernel from
http://at.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
 linux-headers-4.15.0-55-generic Linux kernel headers for version 4.15.0 on 64 bit x86 SMP
 linux-image-4.15.0-55-generic Signed kernel image generic
 linux-modules-4.15.0-55-generic Linux kernel extra modules for version 4.15.0 on 64 bit x86 SMP
 linux-modules-extra-4.15.0-55-generic Linux kernel extra modules for version 4.15.0 on 64 bit x86 SMP
and: NO flickering screen! So the problem seems to be solved!

I don't have a cosmic / disco installation, so I can't test these versions.

So I set the verification-done-bionic - tag.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.15.0-55.60

---------------
linux (4.15.0-55.60) bionic; urgency=medium

  * linux: 4.15.0-55.60 -proposed tracker (LP: #1834954)

  * Request backport of ceph commits into bionic (LP: #1834235)
    - ceph: use atomic_t for ceph_inode_info::i_shared_gen
    - ceph: define argument structure for handle_cap_grant
    - ceph: flush pending works before shutdown super
    - ceph: send cap releases more aggressively
    - ceph: single workqueue for inode related works
    - ceph: avoid dereferencing invalid pointer during cached readdir
    - ceph: quota: add initial infrastructure to support cephfs quotas
    - ceph: quota: support for ceph.quota.max_files
    - ceph: quota: don't allow cross-quota renames
    - ceph: fix root quota realm check
    - ceph: quota: support for ceph.quota.max_bytes
    - ceph: quota: update MDS when max_bytes is approaching
    - ceph: quota: add counter for snaprealms with quota
    - ceph: avoid iput_final() while holding mutex or in dispatch thread

  * QCA9377 isn't being recognized sometimes (LP: #1757218)
    - SAUCE: USB: Disable USB2 LPM at shutdown

  * hns: fix ICMP6 neighbor solicitation messages discard problem (LP: #1833140)
    - net: hns: fix ICMP6 neighbor solicitation messages discard problem
    - net: hns: fix unsigned comparison to less than zero

  * Fix occasional boot time crash in hns driver (LP: #1833138)
    - net: hns: Fix probabilistic memory overwrite when HNS driver initialized

  * use-after-free in hns_nic_net_xmit_hw (LP: #1833136)
    - net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw()

  * hns: attempt to restart autoneg when disabled should report error
    (LP: #1833147)
    - net: hns: Restart autoneg need return failed when autoneg off

  * systemd 237-3ubuntu10.14 ADT test failure on Bionic ppc64el (test-seccomp)
    (LP: #1821625)
    - powerpc: sys_pkey_alloc() and sys_pkey_free() system calls
    - powerpc: sys_pkey_mprotect() system call

  * [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different
    (LP: #1832625)
    - pkey: Indicate old mkvp only if old and current mkvp are different

  * [UBUNTU] kernel: Fix gcm-aes-s390 wrong scatter-gather list processing
    (LP: #1832623)
    - s390/crypto: fix gcm-aes-s390 selftest failures

  * System crashes on hot adding a core with drmgr command (4.15.0-48-generic)
    (LP: #1833716)
    - powerpc/numa: improve control of topology updates
    - powerpc/numa: document topology_updates_enabled, disable by default

  * Kernel modules generated incorrectly when system is localized to a non-
    English language (LP: #1828084)
    - scripts: override locale from environment when running recordmcount.pl

  * [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
    (LP: #1832624)
    - s390/zcrypt: Fix wrong dispatching for control domain CPRBs

  * CVE-2019-11815
    - net: rds: force to destroy connection if t_sock is NULL in
      rds_tcp_kill_sock().

  * Sound device not detected after resume from hibernate (LP: #1826868)
    - drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
    - drm/i915: Save the old CDCLK atomic state
...

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 5.0.0-21.22

---------------
linux (5.0.0-21.22) disco; urgency=medium

  * linux: 5.0.0-21.22 -proposed tracker (LP: #1834902)

  * Disco update: 5.0.15 upstream stable release (LP: #1834529)
    - net: stmmac: Use bfsize1 in ndesc_init_rx_desc
    - Drivers: hv: vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup()
    - ubsan: Fix nasty -Wbuiltin-declaration-mismatch GCC-9 warnings
    - staging: greybus: power_supply: fix prop-descriptor request size
    - staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context.
    - staging: most: cdev: fix chrdev_region leak in mod_exit
    - staging: most: sound: pass correct device when creating a sound card
    - ASoC: tlv320aic3x: fix reset gpio reference counting
    - ASoC: hdmi-codec: fix S/PDIF DAI
    - ASoC: stm32: sai: fix iec958 controls indexation
    - ASoC: stm32: sai: fix exposed capabilities in spdif mode
    - ASoC: stm32: sai: fix race condition in irq handler
    - ASoC:soc-pcm:fix a codec fixup issue in TDM case
    - ASoC:hdac_hda:use correct format to setup hda codec
    - ASoC:intel:skl:fix a simultaneous playback & capture issue on hda platform
    - ASoC: dpcm: prevent snd_soc_dpcm use after free
    - ASoC: nau8824: fix the issue of the widget with prefix name
    - ASoC: nau8810: fix the issue of widget with prefixed name
    - ASoC: samsung: odroid: Fix clock configuration for 44100 sample rate
    - ASoC: rt5682: Check JD status when system resume
    - ASoC: rt5682: fix jack type detection issue
    - ASoC: rt5682: recording has no sound after booting
    - ASoC: wm_adsp: Add locking to wm_adsp2_bus_error
    - clk: meson-gxbb: round the vdec dividers to closest
    - ASoC: stm32: dfsdm: manage multiple prepare
    - ASoC: stm32: dfsdm: fix debugfs warnings on entry creation
    - ASoC: cs4270: Set auto-increment bit for register writes
    - ASoC: dapm: Fix NULL pointer dereference in snd_soc_dapm_free_kcontrol
    - drm/omap: hdmi4_cec: Fix CEC clock handling for PM
    - IB/hfi1: Clear the IOWAIT pending bits when QP is put into error state
    - IB/hfi1: Eliminate opcode tests on mr deref
    - IB/hfi1: Fix the allocation of RSM table
    - MIPS: KGDB: fix kgdb support for SMP platforms.
    - ASoC: tlv320aic32x4: Fix Common Pins
    - drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata()
    - perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS
    - perf/x86/intel: Initialize TFA MSR
    - linux/kernel.h: Use parentheses around argument in u64_to_user_ptr()
    - iov_iter: Fix build error without CONFIG_CRYPTO
    - xtensa: fix initialization of pt_regs::syscall in start_thread
    - ASoC: rockchip: pdm: fix regmap_ops hang issue
    - drm/amdkfd: Add picasso pci id
    - drm/amdgpu: Adjust IB test timeout for XGMI configuration
    - drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in
      shadow_list
    - drm/amd/display: fix cursor black issue
    - ASoC: cs35l35: Disable regulators on driver removal
    - objtool: Add rewind_stack_do_exit() to the noreturn list
    - slab: fix a crash by reading /proc/slab_allocators
    - drm/sun4i: tcon top: Fix NULL/inv...

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Werner Lueckel (werner-lueckel)]

I did the verification with 18.04 "Bionic" and it was o.k; see Comment# 72.
But I don't have a 16.04 "Xenial" installation, so I can't verify this version.

[Statuslife55 (statuslife55)]

thank you for your tip, we can face a problem. Can I use free this

[dueller (dueller)]

The patch 2e26ccb119bde03584be53406bbd22e711b0d6e6 created for this bug brokes the ATI Radeon HD3450/70 RV620 card. Please take a look at bug #1861554 and freedesktop issue here:
https://gitlab.freedesktop.org/drm/amd/issues/1045

[bfluehr (bfluehr)]

I still have flickering problems with the X1300, kernel 5.4, Ubuntu 20.04.

$ lspci | grep Radeon
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV515/M52 [Mobility Radeon X1300]
$ uname -r
5.4.0-33-generic
$ lsb_release -r
Release: 20.04

The display is a laptop panel on a Dell Inspiron 6400.

$ xrandr
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800 60.04*+

When the display wakes from sleep, it is "random" whether the flickering occurs or not.

My workaround: use xrandr to force mode switches until the flickering goes away. For example, run the following command one or more times:

$ xrandr -s 1 && xrandr -s 0

[Kai-Heng Feng (kaihengfeng)]

Werner,
Can you please test the kernel here:
https://people.canonical.com/~khfeng/lp1861554/

I'd like to see if fix for LP: #1861554 doesn't introduce a regression on your system.

[Werner Lueckel (werner-lueckel)]

Hello,
I've tested the khfeng-kernel Linux version 5.8.0+ (khfeng@ubuntu) and unfortunately the screen on my system flickers again!

You may watch some videos:
flicker_5.8.0.mpg via
https://drive.google.com/file/d/1mHsmJcgkMf7H26kQSFrhccTkdOju4APe/view?usp=sharing
flicker1_5.8.0.mpg
https://drive.google.com/file/d/1683YHs3O804zgX5x7wdzl7hxyi0fSjws/view?usp=sharing
flicker2_5.8.0.mpg
https://drive.google.com/file/d/1CETTCoRWUir4o5JxPGuoMAnl9IXfAdUD/view?usp=sharing

[Werner Lueckel (werner-lueckel)]

Hello,
I've tested your kernel  Linux version 5.8.0+ (khfeng@ubuntu) and
unfortunately the screen  on my system flickers again!

You may watch some videos:
flicker_5.8.0.mpg via
https://drive.google.com/file/d/1mHsmJcgkMf7H26kQSFrhccTkdOju4APe/view?usp=sharing
flicker1_5.8.0.mpg
https://drive.google.com/file/d/1683YHs3O804zgX5x7wdzl7hxyi0fSjws/view?usp=sharing
flicker2_5.8.0.mpg
https://drive.google.com/file/d/1CETTCoRWUir4o5JxPGuoMAnl9IXfAdUD/view?usp=sharing

On 12.08.20 17:40, Kai-Heng Feng wrote:
> Werner,
> Can you please test the kernel here:
> https://people.canonical.com/~khfeng/lp1861554/
>
> I'd like to see if fix for LP: #1861554 doesn't introduce a regression
> on your system.
>

[Kai-Heng Feng (kaihengfeng)]

Ok, can you please test this one:
https://people.canonical.com/~khfeng/lp1861554-2/

[Werner Lueckel (werner-lueckel)]

Hello,
... good news! "lp1861554-2/" seems to work!
I got: linux-image-5.9.0-rc1+
giving:
- Linux version 5.9.0-rc1+ (khfeng@ubuntu)
- /lib/modules/5.9.0-rc1+/kernel/drivers/gpu/drm/radeon/radeon.ko
  size: 2244937 date: Aug 17 11:19
- radeon driver still tells: 2.50.0 20080528 (see: dmesg)
  (shouldn't it be better to modify it's version / date ??)

I tried several reboots and got NO flickering!
- text screen during boot-messages:
  when radeon get started the screen switches resolution but continues WITHOUT flickering!
- grafic screen: o.k. NO flickering!

SO: "lp1861554-2/" seems to be a "good one" !

[Kai-Heng Feng (kaihengfeng)]

https://lkml.org/lkml/2020/8/25/934

[sattamatka (dpboss)]

https://sattamatkamarket.in/

[bala (balaa456)]

https://cafedelites.net/cafe-delites
https://cafedelites.net
https://mahabharti.net
https://mahabharti.net/majhinaukri