dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 93784] Hybrid graphics: GPU lockup when running glxgears
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=93784 Bug ID: 93784 Summary: Hybrid graphics: GPU lockup when running glxgears Product: Mesa Version: 11.0 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: nioko1337(a)googlemail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 121146 --> https://bugs.freedesktop.org/attachment.cgi?id=121146&action=edit dmesg output My laptop has the following discrete graphics card (lspci output): 0a:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun LE [Radeon HD 8550M / R5 M230] (rev ff) When running glxgears (or any graphical application) with DRI_PRIME=1, the window appears but it stays just black (also it does not print any FPS in the console). After starting glxgears the first time, the GPU locks up (see dmesg.txt). -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=93341 Bug ID: 93341 Summary: GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games Product: Mesa Version: 11.0 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: nekohayo(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Fedora 23, xorg-x11-drv-ati, on a Dell Precision T3500 (latest BIOS, A17) with a RadeonHD 7770 GPU. Running the latest up-to-date stock packages from Fedora. If I start a game like Xonotic (from the Fedora repos) or Unvanquished (latest alpha binary build downloaded from their github repo), after a minute or two of just looking around as a spectator player, I'll eventually see my computer's monitor turn off all of a sudden. Sound will continue to play for a while, then it might stop/loop. After a few seconds, the kernel will be locked up with the CapsLock LED no longer working. This also happened to me once simply by watching a video fullscreen in Totem (I'm running GNOME Shell, FWIW), but this is a much rarer occurrence. Unfortunately I don't have knowledge of debugging such things, and ABRT somehow thinks my kernel is tainted with the "I" status (meaning it's "working around a severe firmware bug"), which I suppose might be the radeon microcode, so I can't get ABRT to create a nice automated retrace/full debug thing for me. But at least it still has stuff stored on disk, if there's anything in there you'd need: # ls -lh /var/spool/abrt/oops-2015-12-10-21:50:22-777-1/ -rw-r----- 1 root abrt 5 10 déc 21:50 abrt_version -rw-r----- 1 root abrt 9 10 déc 21:50 analyzer -rw-r----- 1 root abrt 6 10 déc 21:50 architecture -rw-r----- 1 root abrt 3,7K 10 déc 21:50 backtrace -rw-r----- 1 root abrt 124 10 déc 21:50 cmdline -rw-r----- 1 root abrt 16 10 déc 21:50 component -rw-r----- 1 root abrt 1 10 déc 21:50 count -rw-r----- 1 root abrt 71K 10 déc 21:50 dmesg -rw-r----- 1 root abrt 40 10 déc 21:50 duphash -rw-r----- 1 root abrt 23 10 déc 21:50 extra-cc -rw-r----- 1 root abrt 8 10 déc 21:50 hostname -rw-r----- 1 root abrt 21 10 déc 21:50 kernel -rw-r----- 1 root abrt 25 10 déc 21:50 kernel_tainted_long -rw-r----- 1 root abrt 3 10 déc 21:50 kernel_tainted_short -rw-r----- 1 root abrt 10 10 déc 21:50 last_occurrence -rw-r----- 1 root abrt 173 10 déc 21:50 not-reportable -rw-r----- 1 root abrt 518 10 déc 21:50 os_info -rw-r----- 1 root abrt 32 10 déc 21:50 os_release -rw-r----- 1 root abrt 6 10 déc 21:50 package -rw-r----- 1 root abrt 7 10 déc 21:50 pkg_arch -rw-r----- 1 root abrt 2 10 déc 21:50 pkg_epoch -rw-r----- 1 root abrt 12 10 déc 21:50 pkg_name -rw-r----- 1 root abrt 9 10 déc 21:50 pkg_release -rw-r----- 1 root abrt 6 10 déc 21:50 pkg_version -rw-r----- 1 root abrt 4,4K 10 déc 21:50 proc_modules -rw-r----- 1 root abrt 37 10 déc 21:50 reason -rw-r----- 1 root abrt 8 10 déc 21:50 runlevel -rw-r----- 1 root abrt 269 10 déc 21:50 suspend_stats -rw-r----- 1 root abrt 10 10 déc 21:50 time -rw-r----- 1 root abrt 10 10 déc 21:50 type -rw-r----- 1 root abrt 40 10 déc 21:50 uuid This is what I get in journalctl/dmesg: -- Logs begin at lun 2015-11-30 21:48:19 EST, end at jeu 2015-12-10 23:48:33 EST. -- déc 10 21:49:00 the_PC kernel: radeon 0000:02:00.0: ring 3 stalled for more than 10115msec déc 10 21:49:00 the_PC kernel: radeon 0000:02:00.0: GPU lockup (current fence id 0x000000000000a5fe last fence id 0x000000000000a600 on ring 3) déc 10 21:49:01 the_PC kernel: BUG: unable to handle kernel paging request at ffffc90404239ffc déc 10 21:49:01 the_PC kernel: IP: [<ffffffffa00f850a>] radeon_ring_backup+0xda/0x190 [radeon] déc 10 21:49:01 the_PC kernel: PGD 6068a8067 PUD 0 déc 10 21:49:01 the_PC kernel: Oops: 0000 [#1] SMP déc 10 21:49:01 the_PC kernel: Modules linked in: fuse xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable déc 10 21:49:01 the_PC kernel: radeon i2c_algo_bit drm_kms_helper ttm drm serio_raw déc 10 21:49:01 the_PC kernel: CPU: 3 PID: 153 Comm: kworker/u64:7 Tainted: G I 4.2.6-301.fc23.x86_64 #1 déc 10 21:49:01 the_PC kernel: Hardware name: Dell Inc. Precision WorkStation T3500 /0K095G, BIOS A17 05/28/2013 déc 10 21:49:01 the_PC kernel: Workqueue: radeon-crtc radeon_flip_work_func [radeon] déc 10 21:49:01 the_PC kernel: task: ffff88060299b880 ti: ffff8805ff5c0000 task.ti: ffff8805ff5c0000 déc 10 21:49:01 the_PC kernel: RIP: 0010:[<ffffffffa00f850a>] [<ffffffffa00f850a>] radeon_ring_backup+0xda/0x190 [radeon] déc 10 21:49:01 the_PC kernel: RSP: 0018:ffff8805ff5c3c98 EFLAGS: 00010206 déc 10 21:49:01 the_PC kernel: RAX: ffffc9000fe50000 RBX: 00000000ffffffff RCX: 0000000000000000 déc 10 21:49:01 the_PC kernel: RDX: 0000000000000000 RSI: ffffc90404239ffc RDI: 0000000000080500 déc 10 21:49:01 the_PC kernel: RBP: ffff8805ff5c3cd8 R08: ffff8805771f8cc0 R09: 0000000000082000 déc 10 21:49:01 the_PC kernel: R10: 8000000000000163 R11: ffffffff81a609e9 R12: ffff880036a654d8 déc 10 21:49:01 the_PC kernel: R13: ffff880036a654b0 R14: 0000000000020141 R15: ffff8805ff5c3d30 déc 10 21:49:01 the_PC kernel: FS: 0000000000000000(0000) GS:ffff880606ec0000(0000) knlGS:0000000000000000 déc 10 21:49:01 the_PC kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b déc 10 21:49:01 the_PC kernel: CR2: ffffc90404239ffc CR3: 0000000001c0b000 CR4: 00000000000006e0 déc 10 21:49:01 the_PC kernel: Stack: déc 10 21:49:01 the_PC kernel: ffff8805ff5c3cc8 ffffffffa00f9413 ffff880036a64000 ffff880036a64000 déc 10 21:49:01 the_PC kernel: ffff880036a654d8 ffff8805ff5c3d30 ffff880036a654d8 0000000000000000 déc 10 21:49:01 the_PC kernel: ffff8805ff5c3da8 ffffffffa00c6c80 ffffffff810df990 ffff880036a64738 déc 10 21:49:01 the_PC kernel: Call Trace: déc 10 21:49:01 the_PC kernel: [<ffffffffa00f9413>] ? radeon_irq_kms_disable_hpd+0x73/0x80 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffffa00c6c80>] radeon_gpu_reset+0xd0/0x330 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffff810df990>] ? wake_atomic_t_function+0x70/0x70 déc 10 21:49:01 the_PC kernel: [<ffffffffa00e058f>] ? radeon_fence_wait+0x9f/0xe0 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffffa00ed960>] radeon_flip_work_func+0x130/0x170 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffff810b650e>] process_one_work+0x19e/0x3f0 déc 10 21:49:01 the_PC kernel: [<ffffffff810b67ae>] worker_thread+0x4e/0x450 déc 10 21:49:01 the_PC kernel: [<ffffffff810b6760>] ? process_one_work+0x3f0/0x3f0 déc 10 21:49:01 the_PC kernel: [<ffffffff810b6760>] ? process_one_work+0x3f0/0x3f0 déc 10 21:49:01 the_PC kernel: [<ffffffff810bc8b8>] kthread+0xd8/0xf0 déc 10 21:49:01 the_PC kernel: [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160 déc 10 21:49:01 the_PC kernel: [<ffffffff817797df>] ret_from_fork+0x3f/0x70 déc 10 21:49:01 the_PC kernel: [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160 déc 10 21:49:01 the_PC kernel: Code: 10 e1 48 85 c0 49 89 07 74 6c 41 8d 7e ff 31 d2 48 c1 e7 02 eb 07 49 8b 07 48 83 c2 04 49 8b 74 24 08 8d 4b 01 89 db 48 8d 34 9e <8b> 36 89 34 10 41 23 4c 24 54 48 39 d7 89 cb 75 da 4c 89 ef e8 déc 10 21:49:01 the_PC kernel: RIP [<ffffffffa00f850a>] radeon_ring_backup+0xda/0x190 [radeon] déc 10 21:49:01 the_PC kernel: RSP <ffff8805ff5c3c98> déc 10 21:49:01 the_PC kernel: CR2: ffffc90404239ffc déc 10 21:49:01 the_PC kernel: ---[ end trace 37e2470f6b251992 ]--- déc 10 21:49:01 the_PC kernel: BUG: unable to handle kernel paging request at ffffffffffffffd8 déc 10 21:49:01 the_PC kernel: IP: [<ffffffff810bcd40>] kthread_data+0x10/0x20 déc 10 21:49:01 the_PC kernel: PGD 1c0e067 PUD 1c10067 PMD 0 déc 10 21:49:01 the_PC kernel: Oops: 0000 [#2] SMP déc 10 21:49:01 the_PC kernel: Modules linked in: fuse xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable déc 10 21:49:01 the_PC kernel: radeon i2c_algo_bit drm_kms_helper ttm drm serio_raw déc 10 21:49:01 the_PC kernel: CPU: 3 PID: 153 Comm: kworker/u64:7 Tainted: G D I 4.2.6-301.fc23.x86_64 #1 déc 10 21:49:01 the_PC kernel: Hardware name: Dell Inc. Precision WorkStation T3500 /0K095G, BIOS A17 05/28/2013 déc 10 21:49:01 the_PC kernel: task: ffff88060299b880 ti: ffff8805ff5c0000 task.ti: ffff8805ff5c0000 déc 10 21:49:01 the_PC kernel: RIP: 0010:[<ffffffff810bcd40>] [<ffffffff810bcd40>] kthread_data+0x10/0x20 déc 10 21:49:01 the_PC kernel: RSP: 0018:ffff8805ff5c3918 EFLAGS: 00010096 déc 10 21:49:01 the_PC kernel: RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000005 déc 10 21:49:01 the_PC kernel: RDX: 0000000000000005 RSI: 0000000000000003 RDI: ffff88060299b880 déc 10 21:49:01 the_PC kernel: RBP: ffff8805ff5c3918 R08: ffff88060299b910 R09: 0000000000000000 déc 10 21:49:01 the_PC kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000167c0 déc 10 21:49:01 the_PC kernel: R13: ffff88060299b880 R14: ffff880606ed67c0 R15: 0000000000000003 déc 10 21:49:01 the_PC kernel: FS: 0000000000000000(0000) GS:ffff880606ec0000(0000) knlGS:0000000000000000 déc 10 21:49:01 the_PC kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b déc 10 21:49:01 the_PC kernel: CR2: 0000000000000028 CR3: 0000000001c0b000 CR4: 00000000000006e0 déc 10 21:49:01 the_PC kernel: Stack: déc 10 21:49:01 the_PC kernel: ffff8805ff5c3938 ffffffff810b7385 ffff8805ff5c3938 ffff880606ed67c0 déc 10 21:49:01 the_PC kernel: ffff8805ff5c3988 ffffffff81774fc0 ffff880500000000 ffff88060299b880 déc 10 21:49:01 the_PC kernel: ffff8805ff5c3988 ffff8805ff5c4000 ffff8805ff5c39f0 ffff8805ff5c39f0 déc 10 21:49:01 the_PC kernel: Call Trace: déc 10 21:49:01 the_PC kernel: [<ffffffff810b7385>] wq_worker_sleeping+0x15/0xa0 déc 10 21:49:01 the_PC kernel: [<ffffffff81774fc0>] __schedule+0x620/0x950 déc 10 21:49:01 the_PC kernel: [<ffffffff81775327>] schedule+0x37/0x80 déc 10 21:49:01 the_PC kernel: [<ffffffff810a103a>] do_exit+0x80a/0xae0 déc 10 21:49:01 the_PC kernel: [<ffffffff810180fe>] oops_end+0x9e/0xd0 déc 10 21:49:01 the_PC kernel: [<ffffffff81064c25>] no_context+0x135/0x380 déc 10 21:49:01 the_PC kernel: [<ffffffff81064ef0>] __bad_area_nosemaphore+0x80/0x1f0 déc 10 21:49:01 the_PC kernel: [<ffffffff81065073>] bad_area_nosemaphore+0x13/0x20 déc 10 21:49:01 the_PC kernel: [<ffffffff81065357>] __do_page_fault+0xb7/0x400 déc 10 21:49:01 the_PC kernel: [<ffffffff810656cf>] do_page_fault+0x2f/0x80 déc 10 21:49:01 the_PC kernel: [<ffffffff8177b378>] page_fault+0x28/0x30 déc 10 21:49:01 the_PC kernel: [<ffffffffa00f850a>] ? radeon_ring_backup+0xda/0x190 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffffa00f85b0>] ? radeon_ring_backup+0x180/0x190 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffffa00f9413>] ? radeon_irq_kms_disable_hpd+0x73/0x80 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffffa00c6c80>] radeon_gpu_reset+0xd0/0x330 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffff810df990>] ? wake_atomic_t_function+0x70/0x70 déc 10 21:49:01 the_PC kernel: [<ffffffffa00e058f>] ? radeon_fence_wait+0x9f/0xe0 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffffa00ed960>] radeon_flip_work_func+0x130/0x170 [radeon] déc 10 21:49:01 the_PC kernel: [<ffffffff810b650e>] process_one_work+0x19e/0x3f0 déc 10 21:49:01 the_PC kernel: [<ffffffff810b67ae>] worker_thread+0x4e/0x450 déc 10 21:49:01 the_PC kernel: [<ffffffff810b6760>] ? process_one_work+0x3f0/0x3f0 déc 10 21:49:01 the_PC kernel: [<ffffffff810b6760>] ? process_one_work+0x3f0/0x3f0 déc 10 21:49:01 the_PC kernel: [<ffffffff810bc8b8>] kthread+0xd8/0xf0 déc 10 21:49:01 the_PC kernel: [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160 déc 10 21:49:01 the_PC kernel: [<ffffffff817797df>] ret_from_fork+0x3f/0x70 déc 10 21:49:01 the_PC kernel: [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160 déc 10 21:49:01 the_PC kernel: Code: c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 4c 89 e7 e8 e7 eb fd ff eb 88 0f 1f 44 00 00 66 66 66 66 90 48 8b 87 90 05 00 00 55 48 89 e5 <48> 8b 40 d8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 déc 10 21:49:01 the_PC kernel: RIP [<ffffffff810bcd40>] kthread_data+0x10/0x20 déc 10 21:49:01 the_PC kernel: RSP <ffff8805ff5c3918> déc 10 21:49:01 the_PC kernel: CR2: ffffffffffffffd8 déc 10 21:49:01 the_PC kernel: ---[ end trace 37e2470f6b251993 ]--- déc 10 21:49:01 the_PC kernel: Fixing recursive fault but reboot is needed! -- Reboot -- -- You are receiving this mail because: You are the assignee for the bug.

1 31

[Bug 93101] GPU Fault almost burned the CPU
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=93101 Bug ID: 93101 Summary: GPU Fault almost burned the CPU Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: dev(a)illwieckz.net QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 120103 --> https://bugs.freedesktop.org/attachment.cgi?id=120103&action=edit syslog (short) Hi, this is an issue about the fact that some GPU lockup can lead to some CPU burn (for real). Some hours ago I get a GPU lockup while I was trying to read a DVD with VLC. The video rendering wasn't functionnal (no picture), then the GPU started to display weird things (see attached photo) then locked up. I've joined some log, one very long syslog, and some abstract for this one (more easy to read, but I gave you the original one in case of I missed something). To summarize, you can read lines like that in the syslog: ``` Nov 24 22:58:18 gollum gnome-session[3720]: [00007f134c173c20] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding Nov 24 22:58:18 gollum kernel: [97035.599456] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00002126 Nov 24 22:58:18 gollum kernel: [97035.599460] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0408800C Nov 24 22:58:18 gollum kernel: [97035.599465] VM fault (0x0c, vmid 2) at page 8486, read from 'TC4' (0x54433400) (136) Nov 24 22:58:55 gollum kernel: [97072.747472] radeon 0000:01:00.0: ring 0 stalled for more than 10088msec Nov 24 22:58:55 gollum kernel: [97072.747483] radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000059fcff last fence id 0x000000000059fd12 on ring 0) Nov 24 22:59:04 gollum kernel: [97081.259933] WARNING: CPU: 4 PID: 23502 at /home/kernel/COD/linux/drivers/gpu/drm/radeon/radeon_object.c:83 radeon_ttm_bo_destroy+0xe7/0xf0 [radeon]() ``` My system is running: vlc 3.0.0~~git20151123+r62463+34~ubuntu15.10.1 linux-image-4.3.0-040300-generic 4.3.0-040300.201511020949 libdrm-radeon1 2.4.65+git1511161830.8913cd~gd~w xserver-xorg-video-radeon 7.6.99+git1511170732.10b7c3~gd~w libgl1-mesa-dri 11.2~git1511231930.e4c122~gd~w mesa-vdpau-drivers 11.2~git1511231930.e4c122~gd~w That is a real issue but it's not the topic of this ticket. The really big problem is this bug almost burned my CPU. I explain. When the bug occurred, I tried to track it. Instead of rebooting my computer I started a laptop in order to connect to my computer using ssh, and to diagnose some stuff on the living system. While the laptop were booting, I took some photo of my screen. But suddenly, my computer shutdown itself. The CPU critical temperature was reached. Normal operation temperature is normally between 30°C and 40°C on my system. In case of emergency, I have two regulators running on my computer. The first one raises fan speed from 128 tr/min to 1400 tr/min when temperature reaches 50°C, and the second one downclocks all the 8 core from 4.7 GHz to 1.4GHz when the temperature reaches 70°C. Both regulators are userspace regulators. The first is the well-known fancontrol, and the other one is mine. Both works well (if I use cpuburn for example). The fact is, when the GPU lockup occurred, something from the driver goes wrong on the CPU side. It looks like some infinite loop started on my cores, doing some extensive tasks, probably without having to deal with external components (like central memory unit) in order to never slow done the CPU. In fact, the computer acted exactly like if I was running one cpuburn process per core using performance cpu governor during a summer noon. But there was an exception, the fan never accelerated (so it was still running at 128 tr/min when the CPU reached 90°, and the cpu was never downclocked too. That's why I wrote this issue. When this bug occured, the system goes so wrong the CPU was on knees and no regulator was able to control the CPU fan so the CPU endlessly heating. Hopefully, the internal CPU temperature protection shutdown automatically my computer to save itself. But if someone use a CPU with a faulty temperature safety mechanisme, this GPU lockup can lead to a CPU burn for real ! -- You are receiving this mail because: You are the assignee for the bug.

1 18

[Bug 92428] Sword Coast Legends causing GPU lockup. radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000afd1 last fence id 0x000000000000b194 on ring 3)
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=92428 Bug ID: 92428 Summary: Sword Coast Legends causing GPU lockup. radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000afd1 last fence id 0x000000000000b194 on ring 3) Product: Mesa Version: 10.6 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: h0ser(a)h0sed.org QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 118821 --> https://bugs.freedesktop.org/attachment.cgi?id=118821&action=edit System Logs Bear with me as it's my first time submitting a bug report. When loading a level in Sword Coast Legends, the driver crashes and hard locks the PC. Attached is what I believe are the relevant portions of the logs. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 92302] Unigine Tropics freeze-crashes R390X
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=92302 Bug ID: 92302 Summary: Unigine Tropics freeze-crashes R390X Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: mc.return(a)gmx.net QA Contact: dri-devel(a)lists.freedesktop.org I understand that this benchmark might not use the latest version of the Unigine engine, but starting it should not make my machine lock up with actual high-end hardware, especially since the benchmark works flawless on pre-GCN AMD hardware. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=91880 Bug ID: 91880 Summary: Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: luutifa(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org I have an r9 390, and I had to disable DPM (on Linux 4.2) to get a stable destop. The performance is less than half of r9 290 (which is almost the same GPU) on the same driver. How is Grenada support planned and can I get an estimate of it's arrival? -- You are receiving this mail because: You are the assignee for the bug.

2 212

[Bug 91315] When running JohnTheRipper OpenCL tests: The kernel rejected CS, see dmesg for more information. / [mi] EQ overflowing. Additional events will be discarded until existing events are processed.
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=91315 Bug ID: 91315 Summary: When running JohnTheRipper OpenCL tests: The kernel rejected CS, see dmesg for more information. / [mi] EQ overflowing. Additional events will be discarded until existing events are processed. Product: Mesa Version: 10.6 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: devurandom(a)gmx.net QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 117064 --> https://bugs.freedesktop.org/attachment.cgi?id=117064&action=edit Last lines of output from: john --test=0 --verbosity=5 I ran `john --test=0 --verbosity=5` from JohnTheRipper@e0e854e01e46e3e58dcec89d0e87b651c448cdff (plus a local patch as suggested in https://github.com/magnumripper/JohnTheRipper/issues/1470#issuecomment-1206…) as a regular non-root user, which made X crash. The last lines of output from `john --test=0 --verbosity=5`, when run as a regular non-root user): ``` [...] Testing: mscash-opencl, M$ Cache Hash [MD4 OpenCL]... Options used: -I /usr/share/john/kernels -cl-mad-enable -D__GPU__ -DDEVICE_INFO=10 -DDEV_VER_MAJOR=10 -DDEV_VER_MINOR=6 -D_OPENCL_COMPILER -D NUM_INT_KEYS=1 -D IS_STATIC_GPU_MASK=0 -D $ Build log: input.cl:365:18: warning: unknown attribute 'max_constant_size' ignored input.cl:375:18: warning: unknown attribute 'max_constant_size' ignored Self test GWS: 64, LWS: 8 FAILED (cmp_all(0)) Options used: -I /usr/share/john/kernels -cl-mad-enable -D__GPU__ -DDEVICE_INFO=10 -DDEV_VER_MAJOR=10 -DDEV_VER_MINOR=6 -D_OPENCL_COMPILER -D SALT_BUFFER_SIZE=260 Build log: input.cl:586:17: warning: unknown attribute 'max_constant_size' ignored binary size 107038 Error creating binary file $JOHN/kernels/pbkdf2_kernel_-D_SALT_BUFFER_SIZE=260_-DDEV_VER_MAJOR=10_-DDEV_VER_MINOR=6AMD_KAVERI_0.bin Device 0 GWS: 8192, LWS: 8 Testing: mscash2-opencl, MS Cache Hash 2 (DCC2) [PBKDF2-SHA1 OpenCL]... radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: Failed to allocate virtual address for buffer: radeon: size : 131072 bytes radeon: alignment : 4096 bytes radeon: domains : 2 radeon: va : 0x00000000020b2000 radeon: Failed to allocate virtual address for buffer: radeon: size : 131072 bytes radeon: alignment : 4096 bytes radeon: domains : 2 radeon: va : 0x00000000020b2000 Bus error ``` X logs: ``` [...] (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x4f) [0x586aff] (EE) 1: /usr/bin/X (mieqEnqueue+0x23b) [0x5690fb] (EE) 2: /usr/bin/X (QueuePointerEvents+0x5a) [0x44f57a] (EE) 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fa4741c7000+0x5f17) [0x7fa4741ccf17] (EE) 4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fa4741c7000+0x679d) [0x7fa4741cd79d] (EE) 5: /usr/bin/X (0x400000+0x74978) [0x474978] (EE) 6: /usr/bin/X (0x400000+0x9d350) [0x49d350] (EE) 7: /lib64/libc.so.6 (0x308b000000+0x336a0) [0x308b0336a0] (EE) 8: /lib64/libc.so.6 (ioctl+0x7) [0x308b0e0c67] (EE) 9: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x3bb1c04428] (EE) 10: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x3bb1c06ff3] (EE) 11: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x466944) [0x7fa47849d944] (EE) 12: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x467ff2) [0x7fa47849eff2] (EE) 13: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x4794ff) [0x7fa4784b04ff] (EE) 14: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x1bdec1) [0x7fa4781f4ec1] (EE) 15: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x13bb1c) [0x7fa478172b1c] (EE) 16: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x1c0f2e) [0x7fa4781f7f2e] (EE) 17: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x13cdbc) [0x7fa478173dbc] (EE) 18: /usr/lib64/dri/radeonsi_dri.so (0x7fa478037000+0x13d012) [0x7fa478174012] (EE) 19: /usr/lib64/xorg/modules/libglamoregl.so (0x7fa478a47000+0x215b6) [0x7fa478a685b6] (EE) 20: /usr/lib64/xorg/modules/libglamoregl.so (0x7fa478a47000+0xb2df) [0x7fa478a522df] (EE) 21: /usr/lib64/xorg/modules/libglamoregl.so (0x7fa478a47000+0xbb6a) [0x7fa478a52b6a] (EE) 22: /usr/bin/X (miCopyRegion+0x1a7) [0x5675a7] (EE) 23: /usr/bin/X (miDoCopy+0x43e) [0x567b2e] (EE) 24: /usr/lib64/xorg/modules/libglamoregl.so (0x7fa478a47000+0xbc04) [0x7fa478a52c04] (EE) 25: /usr/bin/X (0x400000+0x114a72) [0x514a72] (EE) 26: /usr/bin/X (0x400000+0x343ae) [0x4343ae] (EE) 27: /usr/bin/X (0x400000+0x3829f) [0x43829f] (EE) 28: /usr/bin/X (0x400000+0x3c32a) [0x43c32a] (EE) 29: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x308b020040] (EE) 30: /usr/bin/X (0x400000+0x26d2e) [0x426d2e] (EE) (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. (EE) [mi] mieq is *NOT* the cause. It is a victim. (EE) [mi] EQ overflow continuing. 100 events have been dropped. [...] ``` -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=91009 Bug ID: 91009 Summary: [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU Product: Mesa Version: 10.6 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: yurikoles(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 116559 --> https://bugs.freedesktop.org/attachment.cgi?id=116559&action=edit dmesg As I can count, it's happens about every 10-15 start of VDPAU decoding, kernel traces vary. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 90668] vertical stripes/glitches on secondary screen r9 280x
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=90668 Bug ID: 90668 Summary: vertical stripes/glitches on secondary screen r9 280x Product: Mesa Version: 10.5 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: net(a)ianni.de QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 116062 --> https://bugs.freedesktop.org/attachment.cgi?id=116062&action=edit photo This is my first bug report here, so I hope i got everything right. My system is Fedora 22. My GPU is a Sapphire 280x OC. My secondary screen, connected via dvi, is showing strange vertical stripes, ca 3 cm wide. It seems like someone cut the actual image in stripes and glued it together slightly overlapping with flickering borders. If I take a screenshot everything looks normal (as it actually should look). If I use it as the only screen, the stripes are also there. (Is it a problem with the screen or the dvi connection?) I tried the second dvi connection with the same result. Using Windows, the screen has no issues. output of xrandr: http://paste.fedoraproject.org/225798/67516614 output of glxinfo: http://paste.fedoraproject.org/225799/43267525 As mentioned, screenshots show the image as it should be, I had to take a photo of the screen. I used a text file with the repeated series if numbers from 1 to 7.So one can see where the overlapping I mentioned happens (also in the spacing of the buttons, missing glyphs etc..) for example, after the first 1-7 sequence, the 1 and 2 are left out and so on. I am sorry but I found no better way to show it, except making a video If you need more information please let me know. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 90515] memory use increase with vdpau
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=90515 Bug ID: 90515 Summary: memory use increase with vdpau Product: Mesa Version: 10.4 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: fabrice(a)bellet.info QA Contact: dri-devel(a)lists.freedesktop.org I noticed a constant increase of rss memory while playing a video using vdpau + radeonsi, caused by X events accumulating in read_packet (c=0x8275a0) at xcb_in.c:333, and never flushed, and corresponding to this backtrace : Breakpoint 6, read_packet (c=0x8275a0) at xcb_in.c:333 (gdb) bt #0 0x00007fffec99b281 in read_packet (c=0x8275a0) at xcb_in.c:333 #1 0x00007fffec99c742 in _xcb_in_read (c=0x8275a0) at xcb_in.c:936 #2 0x00007fffec999ae4 in _xcb_conn_wait (c=0x8275a0, cond=0x7fffe1636960, vector=0x0, count=0x0) at xcb_conn.c:495 #3 0x00007fffec99b78b in wait_for_reply (c=0x8275a0, request=207, e=0x0) at xcb_in.c:493 #4 0x00007fffec99b8a4 in xcb_wait_for_reply (c=0x8275a0, request=207, e=0x0) at xcb_in.c:523 #5 0x00007fffea7c5ac8 in xcb_dri2_swap_buffers_reply (c=0x8275a0, cookie=..., e=0x0) at dri2.c:893 #6 0x00007fffe6a982f0 in vl_dri2_get_flush_reply (scrn=0x83cab0) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:103 #7 0x00007fffe6a984b4 in vl_dri2_destroy_drawable (scrn=0x83cab0) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:146 #8 0x00007fffe6a98524 in vl_dri2_set_drawable (scrn=0x83cab0, drawable=41943041) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:162 #9 0x00007fffe6a988ed in vl_screen_get_timestamp (vscreen=0x83cab0, drawable=41943041) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:269 #10 0x00007fffe6aa193d in vlVdpPresentationQueueGetTime (presentation_queue=11, current_time=0x7fffe1636b80) at presentation.c:189 #11 0x00007fffe6aa1f04 in vlVdpPresentationQueueBlockUntilSurfaceIdle (presentation_queue=11, surface=13, first_presentation_time=0x7fffe1636b80) at presentation.c:335 #12 0x00007fffe719fb51 in put_surface () at /usr/lib64/dri/radeonsi_drv_video.so #13 0x00007fffe719fdcf in vdpau_PutSurface () at /usr/lib64/dri/radeonsi_drv_video.so #14 0x00007fffed5ead37 in gst_vaapi_texture_glx_put_surface (flags=0, crop_rect=0x7fffe1636d20, surface=0x7fffdc08fd90, base_texture=0x7fffcc1385a0) at gstvaapitexture_glx.c:315 #15 0x00007fffed5ead37 in gst_vaapi_texture_glx_put_surface (texture=0x7fffcc1385a0, surface=0x7fffdc08fd90, crop_rect=0x7fffe1636d20, flags=0) at gstvaapitexture_glx.c:378 #16 0x00007fffedf6e1b1 in gst_vaapi_texture_put_surface (texture=0x7fffcc1385a0, surface=0x7fffdc08fd90, crop_rect=<optimized out>, flags=<optimized out>) at gstvaapitexture.c:332 #17 0x00007fffe99118ec in _do_upload_with_meta (context=<optimized out>, upload=0x7fffdc029600 [GstGLUpload]) at gstglupload.c:357 #18 0x00007fffe9913198 in _run_message_sync (message=0x7fffe1e37840) at gstglwindow.c:353 #19 0x00007fffe9917a82 in _run_message (message=0x7fffd8001b60) at gstglwindow_x11.c:598 #20 0x00007ffff73857fb in g_main_context_dispatch (context=0x7fffcc010980) at gmain.c:3111 #21 0x00007ffff73857fb in g_main_context_dispatch (context=context@entry=0x7fffcc010980) at gmain.c:3710 #22 0x00007ffff7385b98 in g_main_context_iterate (context=0x7fffcc010980, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781 #23 0x00007ffff7385ec2 in g_main_loop_run (loop=0x7fffcc010b70) at gmain.c:3975 #24 0x00007fffe9901cf7 in gst_gl_context_create_thread (context=0x7fffdc023260 [GstGLContextGLX]) at gstglcontext.c:959 #25 0x00007ffff73ac3d5 in g_thread_proxy (data=0x7fffdc0234a0) at gthread.c:764 #26 0x00007ffff6f2352a in start_thread (arg=0x7fffe1637700) at pthread_create.c:310 #27 0x00007ffff6c5f22d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 The commands generating this case is : # ln -s vdpau_drv_video.so /usr/lib64/dri/radeonsi_drv_video.so $ export VDPAU_DRIVER=radeonsi $ wget http://samples.mplayerhq.hu/MPEG-4/NeroRecodeSample-MP4/NeroRecodeSample.mp4 $ gst-launch-1.0 filesrc location=NeroRecodeSample.mp4 ! qtdemux ! mpeg4videoparse ! vaapidecode ! videoconvert ! glimagesink The two malloc() occuring in libxcb in read_packet() are sufficient to make gst-launch-1.0 memory use grow out of control. It seems to occur because vl_dri2_set_drawable() is called alternatively with two different drawables, each call destroying the previous drawable. -- You are receiving this mail because: You are the assignee for the bug.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019