dri-devel August 2016

dri-devel@lists.freedesktop.org

239 participants
1433 discussions

[Bug 96712] Kernel hard LOCKUP related to radeon driver
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96712 Bug ID: 96712 Summary: Kernel hard LOCKUP related to radeon driver 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: lebedev.ri(a)gmail.com Created attachment 124765 --> https://bugs.freedesktop.org/attachment.cgi?id=124765&action=edit dmesg of all that boot This is debian testing, fully updated as of 28 jun 2016 (today) I believe the lockup happened while rendering video via kdenlive (all multithreading options set to 6, gpu acceleration on (not sure it works)), and then trying to change a page in google chrome. $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 6 On-line CPU(s) list: 0-5 Thread(s) per core: 1 Core(s) per socket: 6 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 16 Model: 10 Model name: AMD Phenom(tm) II X6 1075T Processor Stepping: 0 CPU MHz: 3000.000 CPU max MHz: 3000.0000 CPU min MHz: 800.0000 BogoMIPS: 6019.74 Virtualization: AMD-V L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 6144K NUMA node0 CPU(s): 0-5 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 96487] Cannot force power_dpm_force_performance_level to high
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96487 Bug ID: 96487 Summary: Cannot force power_dpm_force_performance_level to high Product: DRI Version: XOrg 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: ltjbour(a)gmail.com Created attachment 124464 --> https://bugs.freedesktop.org/attachment.cgi?id=124464&action=edit Information about the supported gpu states Linux 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/Linux I thought my problem was perhaps a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=70654 but I'm pretty sure that this isn't the same problem. The problem I'm having is that I can't set the highest frequency state from my gpu (AMD A8-4500M APU + HD 7640G), in a consistent and persistent way. And this is regardless of whether uvd is enabled or not (as I assume this is enabled automatically and I haven't been running any application that requires it) In other words I would like to be able to set the dpm level to 'high' so that it stays in the higher frequency state, but I can't set the power_dpm_force_performance variable to anything other than 'auto' and 'low'. I get the following output: λ echo high | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level high tee: /sys/class/drm/card0/device/power_dpm_force_performance_level: Invalid argument It turns out that after some testing, I have noticed that it's more stable to set 'performance' dpm state and force it to 'low', which leaves the GPU frequency at ~335MHz, than setting it to auto which makes the frequencies jump between modes [335/490/655]MHz depending on the load. I would obviously like to be able to set a single mode and have a constant frequency. If I can set 655MHz permanently that would be ideal. I've already tried using 'dynpm' and 'profile' modes, but they don't work. I tried a bunch of times, even enabled/disabled some radeon parameters to see if they were somehow conflicting but I wasn't able to succesfully change states a single time. It would permanently stay at 200MHz with either of these two profile modes set. That left me with the single choice of using 'dpm', as it was the only mode that was able to at least change the states. I was told in IRC that the reason I couldn't set the 'high' value permanently was due to a hardware limitation of Trinity chips. I don't see how this can possibly be true as I can get this same GPU to be consistently at its highest frequency state in Windows 8. So if anything this is a limitation of the driver? I've attached the kernel info about the available states, the list of radeon parameters and their values in my system, and the output of /proc/cpuinfo. As of now I don't know what else to add so feel free to ask for any additional information, I'll make it available as soon as I can. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96326 Bug ID: 96326 Summary: Heavy screen flickering in OpenGL apps on R9 390 Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: 0xe2.0x9a.0x9b(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org GPU: R9 390 GPU manufacturer: Gigabyte Kernel: 4.5, 4.6, etc Firmware: both hawaii_smc.bin and hawaii_k_smc.bin Hello, I am experiencing heavy LCD screen flickering in OpenGL apps when automatic GPU power management is enabled. The flickering is related to mclk transitions. Forcing mclk=1.5GHz, and letting sclk be controlled by DPM, removes the flickering. Related issues: http://bugs.freedesktop.org/show_bug.cgi?id=91880 http://bugs.freedesktop.org/show_bug.cgi?id=92302 -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 95298] Can't "connect" to external display attached to docking station via DP on laptop with Intel/AMD dual
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=95298 Bug ID: 95298 Summary: Can't "connect" to external display attached to docking station via DP on laptop with Intel/AMD dual Product: DRI Version: XOrg 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: debian(a)onerussian.com Created attachment 123520 --> https://bugs.freedesktop.org/attachment.cgi?id=123520&action=edit entire dmesg from the boot #1 I have HP zbook 14 and using Debian testing/unstable. External monitor is connected to docking station serving two DP connections. To make those visible to xrandr I do xrandr --setprovideroffloadsink 1 0 xrandr --setprovideroutputsource 1 0 where 0 corresponds to Intel, 1 to Radeon/OLAND (name changed when upgraded). Setup was working with stock debian packages (kernel was 4.4.2-3) for awhile but there was an issue that display didn't refresh correctly and often I had blank patches and had to go to gnome overview and back to re-render. So I have decided to upgrade to a current state of testing + some unstable. Currently have xserver-xorg-core 2:1.18.3-1 xserver-xorg-video-ati 1:7.7.0-1 and kernel 4.5.1-1 . Unfortunately I can't "turn on" the external display connected to the docking station -- screen blinks and comes back to display on the laptop, xrandr reports xrandr: Configure crtc 4 failed and agd5f on IRC looking at http://www.onerussian.com/tmp/dmesg-20160506-1.txt (attached to this report as well) summarized as "link training failed on the display" -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 95261] R5 M330 GPU lockup with DPM + high power states
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=95261 Bug ID: 95261 Summary: R5 M330 GPU lockup with DPM + high power states 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: andrzej.mendel(a)gmail.com Created attachment 123454 --> https://bugs.freedesktop.org/attachment.cgi?id=123454&action=edit /var/log/syslog at the moment of hangup (photo) System: Ubuntu 16.06 with Mesa git (padoka ppa) and kernel 4.6-rc6 GPU: Intel HD 5500 + AMD R5 M330 - all command below run with DRI_PRIME=1 I get GPU hangups, which result in freeze after a soft reset, whenever the load is high enough to push the GPU into higher power states. If I run, for example, glmark2, only the first frame gets rendered and then the GPU lockups. After ~30s system freezes with information about GPU soft reset as the last message in syslog (see attachment) If I run a non-GPU-intensive commands (say, glxgears with vsync), then the GPU stays in low power states and I do not get this hangup. If I force lower power states (echo battery > /sys/class/drm/card1/device/power_dpm_state), I don't get this hangup even with glmark2. If I force high power states (echo performance > /sys/class/drm/card1/device/power_dpm_state; echo high > /sys/class/drm/card1/device/power_dpm_force_performance_level; echo on > /sys/class/drm/card1/device/power/control) then I do not get the hangup as long as there is no activity at all on the GPU. A simple glxgears is enough to trigger a hangup in this situation. This bug is present since at least kernel 4.2. I would appreciate any info on how to debug this further and will provide more info if requested. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=95247 Bug ID: 95247 Summary: System hangs after ~10 minutes when using Radeon R9 390 Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: sandy.8925(a)gmail.com Hardware specs: Intel Core i5-6600k MSI Z170A Gaming Pro motherboard Radeon R9 390 Boot system with Radeon R9 390 as main output (by choosing PEG as output in UEFI settings). Started up Gnome Wayland session. System hangs after some time. Does not respond to keyboard and mouse input. Cannot switch to TTYs either. Can however restart the system using Ctrl + Alt + PrtScr R-S-E-I-S-U-B Works perfectly fine with the integrated Intel GPU. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 95015] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=95015 Bug ID: 95015 Summary: [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) Product: DRI Version: XOrg git Hardware: PowerPC OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: rsalvaterra(a)gmail.com Created attachment 123045 --> https://bugs.freedesktop.org/attachment.cgi?id=123045&action=edit dmesg Full dmesg attached. I have a Power Mac G5 (late 2005, PCIe) with a Radeon HD 6450 (CAICOS, x86 BIOS) installed on the PCIe x16 slot, and I get this error on boot. I also have a GeForce 6600 (Open Firmware) on a PCIe x8 slot, which works fine, minus the usual nouveau caveats. I have no idea if this is related at all, but the x16 slot is directly connected to the U4 northbridge, and is capable of bypassing the DART IOMMU for 64-bit DMA capable devices (like the Radeon). The other slots are connected to a PCIe bridge on the HyperTransport bus, and DMA always goes through the DART. If needed, I can provide ssh access to the machine. -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 94933] [RV610] Freeze when turning on an external monitor after resume from suspend
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=94933 Bug ID: 94933 Summary: [RV610] Freeze when turning on an external monitor after resume from suspend 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: nicolamori(a)aol.com I have a laptop with a Mobility Radeon HD3470 (RV610) and Plasma 5.6.2 as desktop environment. After suspending to RAM and resuming, I experience a system freeze when trying to switch to a dual monitor setup using an external monitor connected to the VGA output. The dual monitor can be turned on without problems before the suspend/resume cycle. I don't know which logs/information could be useful to diagnose the problem, so I will provide it on demand. Thanks. System details -------------- VGA: Mobility Radeon HD3470 (RV610) OS: ArchLinux 64 bit, kernel 4.4.7, xf86-video-ati 7.7.0 Desktop: Plasma 5.6.2 (with KF5 5.21 and Qt 5.6.0) Steps to reproduce ------------------ - Start the system with only the laptop panel turned on - Suspend to RAM and then resume - Connect an external monitor - Enable the external monitor with xrandr or with the KCM module (System settings -> Display and Monitor -> Display configuration) -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 94903] Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays.
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=94903 Bug ID: 94903 Summary: Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays. Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: johngaltfirstrun(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org When running weston on this hardware with Shimian QHD270 displays, vblanks are skipped resulting in stuttering video playback on any framerate other than 60fps (with multiple players and vo including opengl and wayland (shm)). System: Mesa: git linux: 4.4, 4.5, 4.6 from a drm-next-wip branch wayland: git weston: git A few notes: - This doesn't occur when using amdgpu (for instance building with hawaii amdgpu support. - This bug goes back as far as a year, and another user verified they had this issue on a radeonsi card with a specific monitor. - When utilizing amdgpu, the EDID is correctly read from these monitors. Without, the EDID read fails. I've written the EDID to a file in /lib/firmware/ and successfully loaded with no change however. - Outside of video playback, there are no vblank skips. It was explained that each application affects the entire compositor. - No change on video size. The issue is apparent (with no discernible change) on non-60fps 360p youtube videos on up to high bitrate x265 4K tv shows. - By increasing repaint-window, I'm able to get consistent playback and no vblank skips. However I do run into other issues with it, showing it's clearly not a real solution for wayland support on radeon. - During video playback, weston-presentation-shm shows the missing vblanks just as a timeline does (so including weston-presentation-shm log for readability instead). weston-presentation-shm log with video playback at beginning: https://bpaste.net/show/f8c9b910ddc1. When vblanks are no longer skipped, the video playback has stopped. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=94708 Bug ID: 94708 Summary: Open source radeon drivers not working properly with Radeon HD 8550M 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: markotikvic(a)gmail.com Dear Maintainer, I have a Lenovo laptop with hybrid AMD/Intel graphics cards. I would like to use the discrete Radeon card for heavy rendering operations such as game development and gaming. Output of xrandr --listproviders: Provider 0: id: 0x76 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:Intel Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 1 name:radeon But I get lower fps when I run games with discrete GPU: xrandr --setprovideroffloadsink radeon Intel env DRI_PRIME=1 <game> <- results in barely 20 fps for Dota 2 than if I run them with integrated Intel's card: env DRI_PRIME=0 <game> <- results in 50-60 fps for Dota 2 The output of DRI_PRIME=0 glxinfo | grep 'OpenGL renderer' is: OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile and the ouput of DRI_PRIME=1 glxinfo | grep 'OpenGL renderer' is: OpenGL renderer string: Gallium 0.4 on AMD HAINAN >From dmesg I can see this error occuring after starting the game with DRI_PRIME=1 flag set: [ 1406.107887] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 1406.107892] [drm] PCIE gen 2 link speeds already enabled [ 1406.110997] [drm] PCIE GART of 1024M enabled (table at 0x0000000000040000). [ 1406.111090] radeon 0000:0a:00.0: WB enabled [ 1406.111093] radeon 0000:0a:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff88009ae5bc00 [ 1406.111094] radeon 0000:0a:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff88009ae5bc04 [ 1406.111096] radeon 0000:0a:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff88009ae5bc08 [ 1406.111097] radeon 0000:0a:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff88009ae5bc0c [ 1406.111098] radeon 0000:0a:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff88009ae5bc10 [ 1406.305207] [drm] ring test on 0 succeeded in 1 usecs [ 1406.305213] [drm] ring test on 1 succeeded in 1 usecs [ 1406.305218] [drm] ring test on 2 succeeded in 1 usecs [ 1406.305226] [drm] ring test on 3 succeeded in 4 usecs [ 1406.305233] [drm] ring test on 4 succeeded in 4 usecs [ 1406.305294] [drm] ib test on ring 0 succeeded in 0 usecs [ 1406.305347] [drm] ib test on ring 1 succeeded in 0 usecs [ 1406.305399] [drm] ib test on ring 2 succeeded in 0 usecs [ 1406.305412] [drm] ib test on ring 3 succeeded in 0 usecs [ 1406.305424] [drm] ib test on ring 4 succeeded in 0 usecs [ 1406.305677] [drm:si_dpm_set_power_state] *ERROR* si_upload_sw_state failed I know the GPU is being used because the vgaswitcheroo shows it as DynPwr when I run apps with it. What I would expect to see is performance AT LEAST as good as integrated GPU, instead I get a very bad performance. The poor perfomance is also observable when I run Unity 3D editor (with DRI_PRIME=1) in terms of screen tearing and system freezing. I also tried running the game with vblank_mode=0 option but it had no effect on performance. The scenario is similar with any app I run with DRI_PRIME=1 and it's mostly noticeable with screen tearing. Kernel version: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux I have searched tons of forum threads and websites and I couldn't find a solution (there were some similar open and unresolved threads but nothing useful), so I turn to you for some hardcore professional help. Is there anything I can try to fix this? Oh, I also tried using LXDE desktop but it made no difference, the problems were the same. Let me know if you need other logs and outputs in order to figure this thing out. I am more than happy to help. Thank you in advance, Marko. P.S. Forgive me if I've post this to the wrong package thread but it definitely has something to do with DRI/radeon/xserver package(s). -- You are receiving this mail because: You are the assignee for the bug.

1 30

← Newer
1
2
3
4
5
6
7
...
144
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2016