dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[Bug 93893] R9 390 Hawaii fails resuming from hibernation on amdgpu (linux-4.5.0-rc1)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=93893 Bug ID: 93893 Summary: R9 390 Hawaii fails resuming from hibernation on amdgpu (linux-4.5.0-rc1) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: h.judt(a)gmx.at Created attachment 121330 --> https://bugs.freedesktop.org/attachment.cgi?id=121330&action=edit dmesg I've hoped it would work better than with radeon, but unfortunately it is even worse and will not even perform a single cycle. All ring tests fail with CAFEDEAD. Dmesg attached. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 92993] Powerplay: Thermal controller fails to start on R9 Nano (Fiji)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=92993 Bug ID: 92993 Summary: Powerplay: Thermal controller fails to start on R9 Nano (Fiji) Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: master.homer(a)gmail.com Just got a Sapphire R9 Nano and noticed some problems while running with the latest powerplay kernel from agd5f (commit 256ca780500bc445752763f32b246dc9ee396b62). I don't know how well implemented this is just yet, but it seems like the thermal controller fails to start on my card due to hwmgr->start_thermal_controller->function_list being NULL: [ 2.057417] powerplay: phm_start_thermal_controller [ 2.057419] [ powerplay ] phm_dispatch_table Invalid Parameter! ffff880425cd2000 ffff880425cd2230 (null) The first address refers to hwmgr, the second to rt_table and the last to rt_table->function_list. This, in turn, causes the hwmon interface to not work, and sensors gives me a 0.0 temperature. I'm unsure if this causes the fan to not speed up, but I haven't noticed any sound difference when running valley for example. I've noticed another (possibly unrelated) thing too, checking amdgpu_pm_info I can see that the mclk never changes, just the sclk. I did notice that it fails to find the virtual voltage 65281 in the vdd list, but of course I'm not sure this is related: [ 2.006036] powerplay: us_vdd 900 vs virtual_voltage_id 65281 [ 2.006037] powerplay: us_vdd 65282 vs virtual_voltage_id 65281 [ 2.006038] powerplay: us_vdd 65283 vs virtual_voltage_id 65281 [ 2.006038] powerplay: us_vdd 65284 vs virtual_voltage_id 65281 [ 2.006039] powerplay: us_vdd 65285 vs virtual_voltage_id 65281 [ 2.006040] powerplay: us_vdd 65286 vs virtual_voltage_id 65281 [ 2.006040] powerplay: us_vdd 65287 vs virtual_voltage_id 65281 [ 2.006041] powerplay: us_vdd 65288 vs virtual_voltage_id 65281 [ 2.006042] Can't find requested voltage id in vdd_dep_on_sclk table! -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 92974] Fiji Nano long boot up and long X startup with amdgpu-powerplay enabled
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=92974 Bug ID: 92974 Summary: Fiji Nano long boot up and long X startup with amdgpu-powerplay enabled Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: bug0xa3d2(a)hushmail.com Created attachment 119727 --> https://bugs.freedesktop.org/attachment.cgi?id=119727&action=edit Output of dmesg after startup. With AMD Powerplay enabled in the kernel (cloned from http://cgit.freedesktop.org/~agd5f/linux/?h=amdgpu-powerplay)--when the computer boots there is text, as usual, before modesetting tries to switch to the native resolution of the monitor. At this point, the monitor backlight turns off for about 5 seconds and then stays on for approximately 2 minutes displaying nothing as if the computer locked up with no other boot activity occuring. The Alt+PrintScreen+E/I/U/R button combo still works at this time. If left alone the system finishes booting normally after about 2 minutes. dmesg gives these new error/messages: "Failed to send Previous Message." and ..."[drm] ib test on ring 12 succeeded" that I have not noticed when AMD Powerplay is disabled. Trying to run, "startx" at the console also simulates a system freeze for about 2 minutes or so then X starts normally. To work around the long boot and long X startup bug the kernel option, "Device Drivers/Graphics support/Direct Rendering Manager/Enable legacy fbdev support for your modesetting driver" must be set with, "n". This gives a black screen or no console after the machine boots to log in blind with. X can also be started blind and displayed normally with no startup delay. Another option is to autologin with KDM or such like to boot directly into X after legacy fbdev has been disabled in the kernel options. With AMD Powerplay disabled in the kernel there are no startup issues. Toggling or including/excluding these kernel boot, "lilo.conf" options have no effect on the bug: "amdgpu.enable_scheduler=0 ; radeon.modeset=1 ; radeon.hw_i2c=1 ; radeon.disp_priority=2 ; radeon.fastfb=1 ; radeon.backlight=1 ; radeon.pcie_gen2=-1 ; radeon.hard_reset=0" These patches (applied and not applied) have no effect on the bug: http://people.freedesktop.org/~agd5f/0001-radeonsi-fix-fiji-raster-config.p… http://people.freedesktop.org/~agd5f/0001-drm-amdgpu-update-Fiji-s-tiling-m… Hardware: Fury Nano git: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=amdgpu-powerplay&id=256c… Sidenote: hang check timer is disabled in the kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 18

[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=92827 Bug ID: 92827 Summary: Tonga: No Sound over HDMI with connected AV receiver Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: winlux(a)gmail.com Created attachment 119417 --> https://bugs.freedesktop.org/attachment.cgi?id=119417&action=edit cat /proc/asound/card1/eld#0.0 I'm using the new amdgpu driver on Linux 4.2 and 4.3 RC7 with my new Radeon R9 380. I want to use my 5.1 receiver to get audio over HDMI, it works just fine under Windows 8.1. Under Manjaro Linux, I have configured a standard FullHD output on HDMI with 60 Hz – with my former Radeon HD 7770 using radeonsi this was the rule to get audio (don't get me started on broken HDMI audio on radeonsi. With Linux 4.0+ until now, I needed to use the 3.18 kernel to *not* see only "unplugged" outputs in PulseAudio. See bug 90777.). In fortunate distinction to radeonsi on Linux 4.0+, PulseAudio shows 2.0, 5.1 and 7.1 output over HDMI as plugged in and available. But I don't get any output. No HDMI audio output on Tonga using amdgpu on Linux 4.2 and 4.3 RC7. -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 91790] TONGA hang in amdgpu_ring_lock
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=91790 Bug ID: 91790 Summary: TONGA hang in amdgpu_ring_lock Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: master.homer(a)gmail.com Created attachment 117962 --> https://bugs.freedesktop.org/attachment.cgi?id=117962&action=edit dmesg of hang I've been getting random hangs in amdgpu_ring_lock, this causes X to hang, meaning I can't use the computer at all. I can sometimes switch to a tty, but this doesn't always work either. I'm running Ubuntu 15.04 with mesa and libdrm from the oibaf ppa, with a self-compiled xf86-video-amdgpu and a self-compiled kernel from agd5f, drm-next-4.3-wip (9066b0c318589f47b754a3def4fe8ec4688dc21a). I haven't been able to predict when the hang will happen, sometimes I can use it for several hours before it hangs, other times it happens just a few minutes after booting. -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 91727] alloca means including <alloca.h> on SunOS
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=91727 Bug ID: 91727 Summary: alloca means including <alloca.h> on SunOS Product: DRI Version: XOrg git Hardware: Other OS: Solaris Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: richard(a)netbsd.org came across this issue in amdgpu/amdgpu_cs.c while building libdrm-2.4.64 The following patch get over it for me: >$NetBSD: patch-amdgpu_amdgpu__cs.c,v 1.1 2015/08/18 13:26:29 richard Exp $ >at least on SunOS, alloca needs alloca.h >--- amdgpu/amdgpu_cs.c.orig 2015-08-13 22:27:03.000000000 +0000 >+++ amdgpu/amdgpu_cs.c >@@ -32,7 +32,9 @@ > #include <pthread.h> > #include <sched.h> > #include <sys/ioctl.h> >- >+#ifdef HAVE_ALLOCA_H >+#include <alloca.h> >+#endif > #include "xf86drm.h" > #include "amdgpu_drm.h" > #include "amdgpu_internal.h" -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 91386] Tonga HDMI Audio needs CPU load
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=91386 Bug ID: 91386 Summary: Tonga HDMI Audio needs CPU load Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com There are other reports I know for 270x/280x about HDMI audio needing CPU load I've been testing again on this issue recently with R9 285 and wanted to get a clean report out. Cpu phenom II x4 965be now in a new mobo (asrock) with the tonga. Previous mobo (asus) with 270x also had the issue. I see from other si bugs that people with intel cpu/boards are also affected. rv 790 and onboard rs880 on old mobo didn't have the issue. rv770 on current setup didn't have the issue. Symptoms are that with no cpu load it sounds like the same buffer gets played out repeatedly. With a bit more load progress can be made but there are repeats as well. With almost enough load sounds like a bit of analogue crackle. I've recently found that saying "cpu load" is not really accurate - I can spin cpus without curing the sound, with eg. dd if=/dev/urandom of=/dev/null or tests like cpuburn-1.4a and certain p95/mprime loads. Using mprime it seems what is needed is actually ram/memory controller load. The "torture test" has three options described as - Choose a type of torture test to run. 1 = Small FFTs (maximum heat and FPU stress, data fits in L2 cache, RAM not tested much). 2 = In-place large FFTs (maximum power consumption, some RAM tested). 3 = Blend (tests some of everything, lots of RAM tested). 1 = no fix, 2 = better than 1 but nowhere near right, 3 = OK sound. Historically and recently I've tried many things with no luck - Many sound debugging options, building without hres timers. Disabling cool n quiet in bios. Testing with different hdmi sinks/modes/sample rates/sizes. I only till now used LFS + alsa but now pulse also tested as - Yesterday I dug up an old HD and installed ubuntu 15.04 and installed/updated fglrx - it also has the issue (I was kind of hoping it wouldn't so regs could be compared). The issue does not exist if I boot into windows 7 (unless it's fooling me by always doing something behind the scenes!) So where to go from here? First thought - is there an obvious difference between the way the pre-si driver code does things and what code later h/w hits? Does the type of load needed give any clues? Do people have this h/w on setups without the issue? I don't know what proportion will test HDMI and then they may just look to eg. the kodi forums and be told it's a known issue rather than filing new bugs/adding "a me too". Anything else to test that I've missed? I don't mind spraying printfs/changing things, but don't really know where to start in the code. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 91371] Tonga HDMI Audio none on TV working on monitor - possible eld issue
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=91371 Bug ID: 91371 Summary: Tonga HDMI Audio none on TV working on monitor - possible eld issue Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com I have so far not managed to get any HDMI audio from my TV via R9 285. I can get HDMI sound when connected to a monitor (with cpu load) With other h/w this TV has recently been OK with a bit of messing around eg. extra run of xrandr + cpu load for R9 270x. RS880 and rv770 worked without the cpu load. Added complication since getting a new mobo I sometimes get i2c edid read fails on the TV - but then it's not always and the rv770 produced them and worked and the tonga always works for sound with the TV in windows. I noticed that for the TV the eld does not match what edid decode reports - it only shows one sample rate and shows "Fl/Fr C" when it's only 2 channel. TBH I don't know what eld said historically with different h/w. edid-decode and eld for TV attached. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 91202] output to DVI-I is blank
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=91202 Bug ID: 91202 Summary: output to DVI-I is blank Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: bpaterni(a)gmail.com Created attachment 116902 --> https://bugs.freedesktop.org/attachment.cgi?id=116902&action=edit dmesg for e965b8ce4215ac2b22b23ffc8a8dfbae964b9496 I have a radeon r9 285 (tonga) and I'm trying to run dual DVI displays via the new AMDGPU driver. The problem I'm having though is that the display connected to the DVI-I output goes blank during drm initialization on boot, and thereafter never 'recovers'. If I plug either DVI-D or DVI-I in individually, however, and disconnect the other on a fresh boot, either outputs work just fine. Additionally, dual displays do work if I use any combination of DVI-D, HDMI, or DisplayPort; which leads me to believe that the problem has something to do with how amdgpu is handling output to DVI-I or a hardware problem. Hopefully it is not the latter. Please let me know if there is anything I can do to help debug this problem! I'm using Debian unstable, with the latest linux kernel compiled from git mainline (e965b8ce4215ac2b22b23ffc8a8dfbae964b9496) dmesg and Xorg log should be attached. -- You are receiving this mail because: You are the assignee for the bug.

1 29

[Bug 51042] New: Turning off connector polling in drm_kms_helper inhibits HDMI hot plug
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=51042 Bug #: 51042 Summary: Turning off connector polling in drm_kms_helper inhibits HDMI hot plug Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: dargllun(a)gmail.com When turning off connector polling in drm_kms_helper using the poll=N module parameter HDMI hot plugging does not work anymore. Quoting Alex Deucher: See this discussion for details and some logs: http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/22107 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016