dri-devel April 2014

dri-devel@lists.freedesktop.org

153 participants
962 discussions

[Bug 77394] New: Desktop freezes often when KDE starts compositing or mplayer GL window changes
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=77394 Priority: medium Bug ID: 77394 Assignee: dri-devel(a)lists.freedesktop.org Summary: Desktop freezes often when KDE starts compositing or mplayer GL window changes Severity: major Classification: Unclassified OS: Linux (All) Reporter: nine(a)detonation.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI When I turn on KDE compositing the desktop freezes more often than not. These freezes can also be provoked when configuring mplayer for GL output and opening a video file. If that alone is not enough, just change repeatedly from window to fullscreen and back. Attaching Xorg.0.log and dmesg of such a crash. I can reboot the system cleanly using alt+sysrq+r and ctrl+alt+del but any attempts to get a nice backtrace of the X server with gdb failed due to the process hanging in kernel space. Hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT [Radeon R9 270X] Running: kernel 3.14, libdrm2-2.4.99~git20140411-1.1, xorg-x11-server-7.6_1.15.99.902-306.1 Mesa-10.2~git20140411-5.1 llvm-r600-3.5~svn20140408-1.1.x86_64 openSUSE 13.1 Downgrading components to openSUSE 13.1 stock versions did not help except for downgrading the kernel to 3.11. -- You are receiving this mail because: You are the assignee for the bug.

1 18

[Bug 77247] New: Suspend/Hibernate S3 Defect Fusion E350
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=77247 Priority: medium Bug ID: 77247 Assignee: dri-devel(a)lists.freedesktop.org Summary: Suspend/Hibernate S3 Defect Fusion E350 Severity: normal Classification: Unclassified OS: All Reporter: schumi2004(a)gmail.com Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 97144 --> https://bugs.freedesktop.org/attachment.cgi?id=97144&action=edit dmesg with drm.debug=0xe My first bug ticket so bare with me. System: AD02 E350 OS: OpenELEC Beta - Generic x86_64 3.95.5 System won't wakeup from Hibernate/Suspend, symptoms are: - Blackscreen - No SSH access to system possible at all. - Disconnect power to get it working again. The symptoms are only noticeable after a long period of suspend/hibernate (1 hour and up) If you suspend/hibernate system and directly waking it up again then you won't have it. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 77069] New: Use semantic naming for microcode files
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=77069 Priority: medium Bug ID: 77069 Assignee: dri-devel(a)lists.freedesktop.org Summary: Use semantic naming for microcode files Severity: minor Classification: Unclassified OS: Linux (All) Reporter: nmschulte(a)gmail.com Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI This is a rather trivial request, but it would help the uninitiated and long term maintenance. It would be nice if the microcode was more semantically named, rather than how it exists now. For example, I currently have an issue with UVD on a Radeon HD 8970M, which is "Neptune XT" based (which is "Pitcairn" based), and I receive the following logging: [ 15.942210] [drm] Loading PITCAIRN Microcode [ 15.966837] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_pfp.bin [ 15.976695] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_me.bin [ 15.996448] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_ce.bin [ 16.015403] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_rlc.bin [ 16.016529] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_mc.bin [ 16.026910] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_smc.bin [ 16.045744] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin .... [ 65.525470] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 66.537637] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 67.549797] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 68.561967] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 69.574142] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 70.586334] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 71.598533] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 72.610705] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 73.622877] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 74.635068] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 74.654938] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! [ 74.654955] [drm:si_startup] *ERROR* radeon: failed initializing UVD (-1). At first glance, I'm thinking: well clearly TAHITI_uvd.bin is incorrect for PITCAIRN Microcode, but that's not quite how things work. It would be nice to name the UVD microcode after the actual version of the platform the code is targeting. Perhaps this is simply a naming collision issue and the UVD microcode naming is semantic within the context (that is: my Radeon HD 8970M card really does run the TAHITI version of UVD), but that's doubtful and I would suggest the names change to be more meaningful, :). Another proposition is to skip the "fully semantic naming" idea above and just use symlinks to bridge the two namespaces. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 76957] New: Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=76957 Priority: medium Bug ID: 76957 Assignee: dri-devel(a)lists.freedesktop.org Summary: Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: benjamin.menant+debian(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 96797 --> https://bugs.freedesktop.org/attachment.cgi?id=96797&action=edit Screenshot Hello, Each time I tried to use the free radeon drivers with my desktop computer, I got those corrupted pixels when X starts. The issue effects increase as the session time grows: more and more artifacts, more and more character alterations (for instance, Thunderbird is displaying blocks instead of characters), more and more instabilities (programs ends up by a segmentation fault, and could eventually lead to a system freeze). Otherwise, Gnome Shell starts without error. `glxgears` works and returns good FPS. And the virtual consoles remain safe & clean; switching between them and X has no effect. The system was stable, without screen corruption when I used the AMD’s FGLRX drivers. How could I fix this issue? Any idea? This ticket seems quite similar, should I try the proposed patch? <https://bugs.freedesktop.org/show_bug.cgi?id=66932> Chipset: AMD Radeon HD 6570 (Turks family) with 512MB dedicated RAM (AFAIR). CPU: Intel DualCore E6300 with 4GB RAM. Kernel: Linux 3.13-1-amd64. And I use the defaut Xorg configuration (i.e. no configuration files). -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 76558] New: GPU lockup: radeon: wait for empty RBBM fifo failed ! when playing sauerbraten
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=76558 Priority: high Bug ID: 76558 Assignee: dri-devel(a)lists.freedesktop.org Summary: GPU lockup: radeon: wait for empty RBBM fifo failed ! when playing sauerbraten Severity: critical Classification: Unclassified OS: Linux (All) Reporter: fabio.ped(a)libero.it Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 96295 --> https://bugs.freedesktop.org/attachment.cgi?id=96295&action=edit dmesg after the lockup, got switching to a VT I am using kernel 3.11.0-18.32 (default Ubuntu 13.10 kernel) with mesa from git on a RV530. The system is usually very stable, however when running sauerbreaten with wake6 map (sauerbraten-wake6 package on Debian/Ubuntu) this way: sauerbraten -lwake6 after some minutes I get the following lockup: [ 8425.176130] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec [ 8425.176144] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000002845 last fence id 0x0000000000002844) [ 8425.349835] radeon: wait for empty RBBM fifo failed ! Bad things might happen. [ 8425.523469] Failed to wait GUI idle while programming pipes. Bad things might happen. [ 8425.524520] radeon 0000:01:00.0: Saved 59 dwords of commands on ring 0. [ 8425.530923] radeon 0000:01:00.0: (rs600_asic_reset:401) RBBM_STATUS=0x9401C100 [ 8426.029068] radeon 0000:01:00.0: (rs600_asic_reset:421) RBBM_STATUS=0x9401C100 [ 8426.526183] radeon 0000:01:00.0: (rs600_asic_reset:429) RBBM_STATUS=0x9400C100 [ 8427.023299] radeon 0000:01:00.0: (rs600_asic_reset:437) RBBM_STATUS=0x9400C100 [ 8427.023370] radeon 0000:01:00.0: failed to reset GPU [ 8427.024701] radeon 0000:01:00.0: GPU reset failed [ 8427.028124] radeon 0000:01:00.0: couldn't schedule ib [ 8427.028133] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! [ 8427.057855] radeon 0000:01:00.0: couldn't schedule ib ... Full dmesg is attached. After the lockup I can switch to/from console, but I have to reboot because the screen is corrupted/flashing. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 76297] New: open source radeon drivers for old graphics cards crash the system while booting kernels 3.12+
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=76297 Priority: medium Bug ID: 76297 Assignee: dri-devel(a)lists.freedesktop.org Summary: open source radeon drivers for old graphics cards crash the system while booting kernels 3.12+ Severity: critical Classification: Unclassified OS: Linux (All) Reporter: epp942(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 95971 --> https://bugs.freedesktop.org/attachment.cgi?id=95971&action=edit Dmesg There is no legacy driver for kernel 3.12+ for ati cards and now there is no open source drivers that can be used with kernel 3.12+ , the issue is that while it tries to load module radeon the whole system hangs on boot tried with kernels 3.12 and 3.13 and 3.14 on 3.14 once every 5-10 boots it MAYBE boot with radeon.dpm=0 but this is really random and may not happen for 1 day and may happen 2 times in a row but only with 3.14 on 3.12 and 3.13 system freeze is 100%. I put the dmesg as attachment hope i can help any other way you need me cause there is no driver available for radeon 2-3-4k anymore open or not so we can work with -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 76286] New: Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=76286 Priority: medium Bug ID: 76286 Assignee: dri-devel(a)lists.freedesktop.org Summary: Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870 Severity: major Classification: Unclassified OS: Linux (All) Reporter: OmegaPhil+FreeDesktop.BugTracker(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 95961 --> https://bugs.freedesktop.org/attachment.cgi?id=95961&action=edit Kernel log for session with manual radeon module loading with modesetting enabled Flagged as major as this prevents kernel boot if the user doesnt know how to disable the functionality with the kernel boot parameters. Originally reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619 , Debian kernel v3.13 enables dpm by default - partway through the boot process (when cryptsetup is opening encrypted disks), the kernel hangs (confirmed with no response to ping). The kernel boots fine with radeon.dpm=0. Following instructions (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741485#10) I booted with radeon.modeset=0, made sure X wasn't running and radeon was unloaded, then modprobe'd radeon modeset=1 - after a small delay everything hung. I have attached kern.log (REISUB FTW this time it seems?), there is an X log but that simply gave up after finding no modesetting support, before the point where I reloaded radeon. kern.log is verbose as I always boot with full debugging information, but in this case its useless as nothing appears to be logged associated with the radeon load (and I'm assuming the magic sync worked). In terms of fighting the issue, I have C and C++ experience but no real kernel debugging EXP and certainly nothing todo with the graphical stack. =============================== uname -a: Linux omega1 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux Debian Testing X server: 1.15.0 Radeon: 7.3.0 -- You are receiving this mail because: You are the assignee for the bug.

1 20

[Bug 76210] New: Temperature sensor is showing too high temperatures
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=76210 Priority: medium Bug ID: 76210 Assignee: dri-devel(a)lists.freedesktop.org Summary: Temperature sensor is showing too high temperatures Severity: minor Classification: Unclassified OS: All Reporter: nicolas.belouin(a)heptaoctet.net Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/radeonsi Product: Mesa The temperature sensors are showing a temperature of 511°C when the radeon card is in sleep mode, the normal temperature is displayed when the card is used. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 76130] New: Radeon HD 4570 set dpm state fails after suspend
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=76130 Priority: medium Bug ID: 76130 Assignee: dri-devel(a)lists.freedesktop.org Summary: Radeon HD 4570 set dpm state fails after suspend Severity: normal Classification: Unclassified OS: Linux (All) Reporter: crew4ok(a)gmail.com Hardware: x86 (IA32) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 95731 --> https://bugs.freedesktop.org/attachment.cgi?id=95731&action=edit dmesg Right before the system go to suspend, the following line appears in dmesg: [drm:rv730_stop_dpm] *ERROR* Could not force DPM to low After wakeup i see this in dmesg: [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed Also i notice a degradation in performance in some games (e.g. in Teeworlds before the suspend i have 60fps, after suspend - 30-40 fps). -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 75719] New: mplayer -vo gl consume more CPU on r200
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=75719 Priority: medium Bug ID: 75719 Assignee: dri-devel(a)lists.freedesktop.org Summary: mplayer -vo gl consume more CPU on r200 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: smoki00790(a)gmail.com Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI OS is current Debian Sid 32bit, card 1002:5960... So this is on r200 i spotted playing any video file vith gl render (but also many videos in games are also affected), bisecting says it started with this code in ttm: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=a095c60bd0… And it performs the same also in 3.14-rc5 kernel :). It consume cca 40% or more CPU power after that commit... that *more* depends on video file and if it is in game or playing video file with mplayer -vo gl. Mesa version seems doesn't metter i tried 9.2 git, 10.0 git, 10.1 git and current git master. -- You are receiving this mail because: You are the assignee for the bug.

1 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2014