dri-devel May 2016

dri-devel@lists.freedesktop.org

212 participants
1404 discussions

[Bug 79223] New: extra vsync when reading back pixels in xbmc
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=79223 Priority: medium Bug ID: 79223 Assignee: dri-devel(a)lists.freedesktop.org Summary: extra vsync when reading back pixels in xbmc Severity: normal Classification: Unclassified OS: All Reporter: pierre-bugzilla(a)ossman.eu Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Something is causing an extra wait for vsync in xbmc when it needs to read back pixels. This seems to be specific to the radeon driver as I'm not seeing it with nouveau. Test scenario: - Configure xbmc to wait for vsync - Install something that activates xbmc's capture code (e.g. xbmc's boblight plugin) - Play a video whose framerate > screen refresh / 2 You'll see the frame rate reliably locked to screen refresh / 2 under these circumstances. A major problem as you generally want to run with a 24 Hz refresh rate for 24 Hz films. I'm unable to pinpoint exactly the offending GL command as xbmc's rendering is quite complex. I hope you're more experienced in finding these things. :) The rough sequence of events is: 1. xbmc renders the scene 2. Wait for vsync 3. Map PBO and memcpy data. (from previous frame) 4. Render small version of scene 5. glReadPixels into PBO -- You are receiving this mail because: You are the assignee for the bug.

1 19

[Bug 78096] New: Linux 3.14 doesn't boot with Radeon HD 5870
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=78096 Priority: medium Bug ID: 78096 Assignee: dri-devel(a)lists.freedesktop.org Summary: Linux 3.14 doesn't boot with Radeon HD 5870 Severity: normal Classification: Unclassified OS: All Reporter: stephane.raimbault(a)gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI I updated to the kernel 3.14 provided by Archlinux (https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=package…) and I'm not able to boot without passing radeon.modeset=0 to the kernel command line. The kernel 3.13 from package 3.13.8-1-ARCH is working properly. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 77677] New: HDMI audio on ati7750 choppy with ALSA multi-channel apps
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=77677 Priority: medium Bug ID: 77677 Assignee: dri-devel(a)lists.freedesktop.org Summary: HDMI audio on ati7750 choppy with ALSA multi-channel apps Severity: normal Classification: Unclassified OS: Linux (All) Reporter: socalfisher(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 97618 --> https://bugs.freedesktop.org/attachment.cgi?id=97618&action=edit Alsa No Pulseaudio xorg.0.log dmesg aplayL/l codec logs I am having issues playing sounds over HDMI stereo directly to TV. I am using XBMC. When Pulse Audio is installed the sounds play fine in stereo. When I try a pure alsa installation (no pulse audio) there is severe distortion. Pure ALSA is needed for applications that only support ALSA, and for HDMI pass-through. My dedicated Radeon 7750 card only outputs cyclical sounds, quiet voices like wrong channel, and echos. Setup PC to TV directly HDMI (2.0 audio selected). I have had the same issue when cpu was an AMD 955BE, and now Intel i7 4770. Windows 7 plays hdmi audio just fine on the same exact PC/Panasonic plasma/setup. 1) speaker-test -l 4 -c 2 -r 48000 -D hw:1,3 plays choppy sounds with or without pulse installed. 2) aplay -D plughw:1,3 /usr/share/sounds/alsa/Front_Center.wav plays fine Using an A4-3400 HDMI plays perfectly fine on the same TV. As does my Zotac AQ01. Not sure if this is related (http://ubuntuforums.org/showthread.php?t=2207698): SND_PCM_ACCESS_RW_INTERLEAVED vs. SND_PCM_ACCESS_MMAP_INTERLEAVED I believe XBMC uses SND_PCM_ACCESS_RW_INTERLEAVED for ALSA. Thanks in advance. -- You are receiving this mail because: You are the assignee for the bug.

1 34

[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

← Newer
1
...
9
10
11
12
13
14
15
...
141
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2016