https://bugs.freedesktop.org/show_bug.cgi?id=100308
Bug ID: 100308
Summary: *ERROR* clock recovery reached max voltage
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: alex.c.liang(a)gmail.com
The following starting happening after upradeing to
xf86-video-ati-1:7.9.0-1-x86_64.pkg.tar.xz on arch linux. (ALL Monitors go
blank) First thought it was kernel and tried rolling back a few versions and
was still happening. On the new kernel versions it just happens ramdonly. On
the older kernels it only happens when trying to wake monitors. It's always the
following errors.
Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery reached max voltage
Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery failed
I've switched to AMDGPU since it now has experimental support for southern
islands.
Thx much for the hardwork!!!!
stack trace...
------------[ cut here ]------------
Mar 18 10:05:00 showdownarch kernel: WARNING: CPU: 3 PID: 13100 at
./include/drm/drm_crtc.h:1403 drm_helper_choose_encoder_dpms+0x8a/0x90
[drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel: Modules linked in: xt_multiport
iptable_filter overlay snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_codec_hdmi iTCO_wdt gpio_ich iTCO_ven
Mar 18 10:05:00 showdownarch kernel: mii fb_sys_fops i2c_algo_bit button
snd_timer snd mei_me soundcore mei intel_agp shpchp intel_gtt acpi_cpufreq
tpm_tis tpm_tis_core tpm sch_fq_
Mar 18 10:05:00 showdownarch kernel: CPU: 3 PID: 13100 Comm: kworker/3:256
Tainted: G W 4.9.14-1-lts #1
Mar 18 10:05:00 showdownarch kernel: Hardware name: Gigabyte Technology Co.,
Ltd. H55-USB3/H55-USB3, BIOS F7 08/20/2010
Mar 18 10:05:00 showdownarch kernel: Workqueue: events radeon_dp_work_func
[radeon]
Mar 18 10:05:00 showdownarch kernel: ffffc90010d63d20 ffffffff812f890d
0000000000000000 0000000000000000
Mar 18 10:05:00 showdownarch kernel: ffffc90010d63d60 ffffffff8107cb0b
0000057b9e861d09 ffff88030a843000
Mar 18 10:05:00 showdownarch kernel: ffff88030ffe7a00 ffff88030f5f9000
0000000000000003 ffff88030aa92660
Mar 18 10:05:00 showdownarch kernel: Call Trace:
Mar 18 10:05:00 showdownarch kernel: [<ffffffff812f890d>] dump_stack+0x63/0x86
Mar 18 10:05:00 showdownarch kernel: [<ffffffff8107cb0b>] __warn+0xcb/0xf0
Mar 18 10:05:00 showdownarch kernel: [<ffffffff8107cc3d>]
warn_slowpath_null+0x1d/0x20
Mar 18 10:05:00 showdownarch kernel: [<ffffffffa044408a>]
drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel: [<ffffffffa04444eb>]
drm_helper_connector_dpms+0x4b/0x100 [drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel: [<ffffffffa04465cb>] ?
drm_dp_dpcd_read_link_status+0x1b/0x20 [drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel: [<ffffffffa05ab477>]
radeon_connector_hotplug+0xf7/0x100 [radeon]
Mar 18 10:05:00 showdownarch kernel: [<ffffffffa05b91ff>]
radeon_dp_work_func+0x3f/0x60 [radeon]
Mar 18 10:05:00 showdownarch kernel: [<ffffffff81096399>]
process_one_work+0x1e9/0x440
Mar 18 10:05:00 showdownarch kernel: [<ffffffff8109663b>]
worker_thread+0x4b/0x4f0
Mar 18 10:05:00 showdownarch kernel: [<ffffffff810965f0>] ?
process_one_work+0x440/0x440
Mar 18 10:05:00 showdownarch kernel: [<ffffffff8109c0c9>] kthread+0xd9/0xf0
Mar 18 10:05:00 showdownarch kernel: [<ffffffff8102c74e>] ?
__switch_to+0x2ce/0x5b0
Mar 18 10:05:00 showdownarch kernel: [<ffffffff8109bff0>] ?
kthread_park+0x60/0x60
Mar 18 10:05:00 showdownarch kernel: [<ffffffff815f8a55>]
ret_from_fork+0x25/0x30
Mar 18 10:05:00 showdownarch kernel: ---[ end trace 6a290eae4410f871 ]---
Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery reached max voltage
Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery failed
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
Bug ID: 100289
Summary: 'flip queue failed in radeon_scanout_flip: Invalid
argument' error and small frame buffer allocated on
turning off and on new monitor
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: OmegaPhil(a)startmail.com
Created attachment 130326
--> https://bugs.freedesktop.org/attachment.cgi?id=130326&action=edit
Xorg log
I have just bought a 3rd monitor, successfully hooked up via Display Port to
the R9 290X (Tahiti XT) card and configured fine as 3 non-mirrored outputs in
XFCE4.
I found that when I turned it off for ~10 seconds or more, after turning it
back on all screens would go black and appear to reinialise. XFCE4 gets
confused and clones the primary monitor output to the new 3rd screen, fiddling
in the XFCE4 Display program fixes this (after the problem happens it seems to
put the primary and new monitor on top of each other...).
Looking into Xorg.0.log, when I turn the monitor off for less than 10 seconds,
I just get the following event:
===============================================================================
[ 512.737] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
===============================================================================
Being off for 10 seconds or more results in:
===============================================================================
[ 1891.671] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840
[ 1891.677] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device
or resource busy
[ 1891.678] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device
or resource busy
===============================================================================
It now makes sense why monitor output appears to be mirrored (only 2 unique
outputs) - 3840 is 1920*2. When I fix the configuration with XFCE4, the correct
frame buffer is set up:
===============================================================================
[ 2001.120] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760
===============================================================================
I have attached the X log.
I'm currently running Devuan Testing (based off Debian Testing)
uname -a: Linux omega1 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64
GNU/Linux
X: 1.19.2-1
radeon: 7.8.0
Thanks for any help.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100222
Bug ID: 100222
Summary: Hang regression with R7 M370, identified possible
culprit commit
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: registo.mailling(a)gmail.com
Created attachment 130246
--> https://bugs.freedesktop.org/attachment.cgi?id=130246&action=edit
lspci -nnk and dmesg output
After updating from kernel 4.9 series to 4.10 series I have identified a
regression when using the discrete GPU on my laptop (Lenovo Thinkpad E560).
When running any demanding application with DRI_PRIME=1 the card will hang, one
example would be running 'DRI_PRIME=1 glmark2 -b texture'.
I have noticed that the content of /sys/kernel/debug/dri/1/radeon_pm_info has
changed between kernel 4.9 and 4.10 when running glmark2.
With 4.9:
power level 4 sclk: 75000 mclk: 80000 vddc: 1050 vddci: 0 pcie gen: 2
With 4.10:
power level 4 sclk: 87500 mclk: 90000 vddc: 1050 vddci: 0 pcie gen: 2
This led me to revert commit 3a69adfe5617ceba04ad3cff0f9ccad470503fb2 which
prevents the card from hanging.
You can find the output of lspci and dmesg in the attachment for the case with
commit 3a69adfe5617ceba04ad3cff0f9ccad470503fb2 reverted.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99970
Bug ID: 99970
Summary: DRI3 steam login window is empty
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: cosiekvfj(a)o2.pl
Created attachment 129927
--> https://bugs.freedesktop.org/attachment.cgi?id=129927&action=edit
screenshot
Steam login window is empty with dri3. Window is functional. I can write my
password and when I press enter I can login to steam. After that everything is
normal. With dri2 bug is not present.
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RC410M [Mobility Radeon Xpress 200M]
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99881
Bug ID: 99881
Summary: Lockup/Freezes on Laptop with switchable graphics
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: matthew(a)tech3.me
Created attachment 129781
--> https://bugs.freedesktop.org/attachment.cgi?id=129781&action=edit
dmesg log
Hi,
I have a HP Pavilion dv6-3111sa laptop (circa 2010) with 2 GPUs:
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] [1002:9712]
02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470] [1002:68e0] (rev ff)
I am running Ubuntu 16.04.2 with kernel Ubuntu 4.8.0-36.36~16.04.1-generic
4.8.11
The screen usually freezes for a fraction of a second and then again a few
seconds later. It may do this several times. In addition, the computer usually
locks up before/after graphical login requiring a hard shutdown, although it
doesn't always lock up. It seems to be preventing the computer from shutting
down normally as well.
This appears in dmesg output whenever a freeze occurs:
186.427140] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[ 186.431201] [drm] PCIE GART of 512M enabled (table at 0x000000000014C000).
[ 186.431293] radeon 0000:02:00.0: WB enabled
[ 186.431301] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr
0x0000000020000c00 and cpu addr 0xffff958c0f4f3c00
[ 186.431306] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr
0x0000000020000c0c and cpu addr 0xffff958c0f4f3c0c
[ 186.431703] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr
0x000000000005c418 and cpu addr 0xffffad3d81a1c418
[ 186.447926] [drm] ring test on 0 succeeded in 1 usecs
[ 186.447934] [drm] ring test on 3 succeeded in 2 usecs
[ 186.634582] [drm] ring test on 5 succeeded in 1 usecs
[ 186.634592] [drm] UVD initialized successfully.
[ 186.634648] [drm] ib test on ring 0 succeeded in 0 usecs
[ 186.634686] [drm] ib test on ring 3 succeeded in 0 usecs
[ 186.805724] [drm] ib test on ring 5 succeeded
[ 186.838322] snd_hda_intel 0000:02:00.1: Enabling via vga_switcheroo
[ 186.942052] snd_hda_intel 0000:02:00.1: CORB reset timeout#2, CORBRP = 65535
[ 196.033454] snd_hda_intel 0000:02:00.1: Disabling via vga_switcheroo
[ 196.646111] snd_hda_intel 0000:02:00.1: Cannot lock devices!
Adding radeon.runpm=0 to my boot cmdline solves the issues as a workaround.
With previous ubuntu/kernel versions, the main issue was the freezing which
would happen every seven seconds with the corresponding dmesg block. This would
continue ad infinitum, although on rare occasions it would stop after many
freezes. However with my current kernel this pattern doesn't seem to occur - it
freezes a few times before the freezing stops and the freezes do not occur at
regular intervals.
I'm not sure if this is a graphics or sound issue from the dmesg block. There's
also some ACPI errors in the dmesg log so maybe a firmware problem, or faulty
hardware? I tried some lower level debugging previously but couldn't conclude
anything.
Thanks for any assistance.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99679
Bug ID: 99679
Summary: DRI PRIME doesn't always work with intel/radeon
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: lev258(a)freemail.hu
Hello.
I am running Ubuntu 16.04, with MATE installed later on it, using the latter
currently. Beside normal system updates, I am using the Mesa stable ppa.
Recently I started using DRI_PRIME=1 in some cases, to make the AMD videocard
working. I found that it doesn't always work and the Intel one is used instead,
like DRI_PRIME didn't even matter to it. This happens with Unigine Heaven,
Steam and even glxinfo.
Strangely, glxgears is not affected, it always does what it should be.
I cannot reproduce this behaviour, it just happens sometimes. And it seems to
solve itself after a reboot.
Tell me, what you need to look into it.
Thanks.
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
Integrated Graphics Controller (rev 09)
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Venus PRO [Radeon HD 8850M / R9 M265X] (rev ff)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99368
Bug ID: 99368
Summary: Full aspect scaling introduces interlacing on specific
resolutions
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: gamwizh00(a)gmail.com
Created attachment 128897
--> https://bugs.freedesktop.org/attachment.cgi?id=128897&action=edit
dmesg log
When using full aspect scaling in xrandr on a laptop with an A6-6310 apu the
display is showing interlaced lines across the whole display.
This happens only on some of the supported resolutions of the integrated
display, those being 1280x720 and 1152x768.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99326
Bug ID: 99326
Summary: Boot problem and White
dots/noise/speckling/shimmering/corruption on Radeon
HD6320
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: mrj(a)advancedcontrols.com.au
A default Gnome install of either Fedora 25 or Fedora 24 (latest spin)
Workstation, on a machine with a Radeon HD6320 (AMD G-series T56N) graphics
chip running 1360x768@60Hz, has a display that most of the time is black on
boot (reboot required -- hangs?), but occasionally completes booting with a
display that all over shimmers with white noise, as seen in the following
video:
https://www.youtube.com/watch?v=dHW6kM4koQ0
The problem has been traced to this Linux kernel commit
https://github.com/torvalds/linux/commit/ff0bd441bdfbfa09d05fdba9829a0401a4…
, made to fix Bug 95206.
Xorg logs and xrandr output seem to indicate the the same modeline is selected
after this commit is reversed, even though the boot and display problems no
longer occur.
The equivalent Red Hat bug is
https://bugzilla.redhat.com/show_bug.cgi?id=1402293
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99316
Bug ID: 99316
Summary: Radeon crash when laptop on AC power
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: major
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: LordSamanon(a)gmail.com
Created attachment 128807
--> https://bugs.freedesktop.org/attachment.cgi?id=128807&action=edit
AC Power Unigine Heaven dmesg
I have a Dell laptop with an Intel iGPU and a Radeon dGPU (a Firepro W5130M,
recognized as a Radeon HD 8830M by lspci).
Whenever I attempt to use the Radeon card via DRI_PRIME=1 while the laptop is
plugged in, the card crashes. When on battery the card performs fine.
One way I have tested this is with glxgears. Often glxgears will work the first
time it is run, but if it is closed and then opened a few seconds later, it
will crash.
I have also tried running programs like Portal 2 and Unigine Heaven. These
always hang. Unfortunately the error messages produced in dmesg are not the
most consistent. Sometimes I get a backtrace, sometimes even a kernel panic on
reboot.
I'll post the various logs I have. One thing I have found is that glxgears does
not crash if I use radeon.runpm=0, however it still hangs when running
something like Portal.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99181
Bug ID: 99181
Summary: RS780 blank screen on boot
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: chithanh(a)gentoo.org
Hardware: BIOSTAR A780L
When booting with 3.15 or newer kernels, a monitor connected to the DVI port of
the BIOSTAR A780L will stay blank.
Kernel 3.14 and older work fine.
I tried forcing the output to on with video=HDMI-A-1:e but this made no
difference.
--
You are receiving this mail because:
You are the assignee for the bug.