dri-devel July 2017

dri-devel@lists.freedesktop.org

212 participants
1542 discussions

[Bug 98634] Fedora 32bits kernel 4.8.4-200.fc24.i686+PAE is not able to resume from hibernate
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=98634 Bug ID: 98634 Summary: Fedora 32bits kernel 4.8.4-200.fc24.i686+PAE is not able to resume from hibernate Product: DRI Version: XOrg git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: humberto.i.perez.rodriguez(a)intel.com Created attachment 127824 --> https://bugs.freedesktop.org/attachment.cgi?id=127824&action=edit dmesg.log Bug description ======================================= Fedora 32bits kernel 4.8.4-200.fc24.i686+PAE is not able to resume from hibernate, after send the platform to S4 / hibernate looks like that the platforms is not able to enter to S4 because the post code remains in "0004" and never shutdown completly how does it happen in Fedora 64bits Note : this bug does not appears in Fedora 64bit with kernel 4.5.5-300-fc24.x86_64 Steps to reproduce ======================================= 1. Install Fedora 24 32bits 2. Go to hibernate with either of the following commands : # rtcwake -s 60 -m disk # echo disk > /sys/power/state 3. if you try with the second command try to wake up the platform pushing any key / if you try with the first command wait 60 seconds Expected behavior ======================================= The platforms must resume from S4 / hibernate Actual result ======================================= After the step 3 the platform does not resume from S4 / hibernate Software configuration ============================================ Linux OS : Fedora 32Bit Kernel version : 4.8.4-200.fc24.i686+PAE Bios revision : 144.10 Bios release date : 06/27/2016 KSC revision : 1.15 Hardware information ============================================ Platform : BXT-P Motherboard model : BroxtonP Motherboard type : NOTEBOOK Hand Held Motherboard manufacturer : IntelCorp. CPU family : Other CPU information : 06/5c GPU Card : Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series Integrated Graphics Controller (rev 0a) (prog-if 00 [VGA controller]) Memory ram : 8 GB Maximum memory ram allowed : 16 GB CPU thread : 4 CPU core : 4 Attachments =========================================== dmesg.log, which containg the log when the platforms try to enter to S4 state Additional information =========================================== in order to send the platform to S3 (suspend) / S4 (hibernate) you have to enable it in the grub in the following way : 1. $ dmesg | grep -i "swap on" # to know where is your swap partition example : /dev/mapper/fedora-swap 2. add the following parameter in the file /etc/default/grub resume=/dev/mapper/fedora-swap add it at the end of the line : GRUB_CMDLINE_LINUX= 3. update the grub : grub2-mkconfig -o /boot/grub2/grub.cfg this a common issue in Fedora, for more detail information please read the following article : https://fedoraproject.org/wiki/Common_F24_bugs#Hibernation_doesn.27t_work_f… Please correct me if i am placing this issue in the wrong component, thanks i915_error_state = no error state collected cat /sys/class/drm/card0/error = no error state collected -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 91481] [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=91481 Bug ID: 91481 Summary: [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault Product: DRI Version: XOrg git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: adam_richter2004(a)yahoo.com Created attachment 117412 --> https://bugs.freedesktop.org/attachment.cgi?id=117412&action=edit Path to make drm_dp_send_link_address set link_address_sent before hotplug handler changes the pointer to it When I "hot plug" insert a DisplayPort multistream transport ("MST") hub into a computer that is running a Linux 4.2-rc4 kernel or any recent version, I get a kernel memory fault in drm_dp_add_port. In earlier kernels, I traced it to the line after drm_dp_add_port's call to drm_dp_send_link_address: drm_dp_send_link_address(mstb->mgr, port->mstb); port->mstb->link_address_sent = true; I believe that the problem is that drm_dp_send_link_address can call a hotplug handler, which can change port->mstb so that it cannot be dereferenced (I think it is set to NULL, but I have forgotten). Since drm_dp_send_link_address is a static function in this file, its address is never taken, and there are only two call sites, both of which set link_address_sent to true, the patch that I have attached changes drm_dp_send_link_address so that it sets that flag, reducing duplication of code, and also allowing drm_dp_send_link_address to skip setting the flag if sending the link address fails. An intentional behavior change introduced by this patch is that the mstb->link_address_sent is not set if sending the link address was aborted due to the memory allocation in drm_dp_send_link_address failing. Perhaps it should also not be set if the action receives a NAK reply, but I haven't studied the code and DisplayPort documentation enough to guess. Whoever examines this patch should feel free to revise it as they see fit. I should also warn that after I made this change in linux-4.2-rc4, the resulting kernel eventually got another kernel memory fault in i2c_transfer (called by drm_do_probe_ddc_edid), but I believe that that is a separate issue. I am happy to answer questions about this patch. If nobody sees any problems with it, I would ask that whoever takes this bug report submit the patch upstream. Thanks for considering this bug report and proposed patch. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 91749] Tonga IH ring misaligned
by bugzilla-daemon＠freedesktop.org 02 Oct '19

02 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=91749 Bug ID: 91749 Summary: Tonga IH ring misaligned 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: jay(a)jcornwall.me >From amdgpu_ih.c: adev->irq.ih.ring = kzalloc(adev->irq.ih.ring_size + 8, GFP_KERNEL); if (adev->irq.ih.ring == NULL) return -ENOMEM; adev->irq.ih.rb_dma_addr = pci_map_single(adev->pdev, (void *)adev->irq.ih.ring, adev->irq.ih.ring_size, PCI_DMA_BIDIRECTIONAL); The Tonga IH_RB_BASE register requires 256B alignment. kzalloc does not guarantee this, e.g.: adev->irq.ih.ring: 0xFFFF880835B22148 adev->irq.ih.rb_dma_addr: 0x835B22148 IH_RB_BASE: 0835b221 This causes amdgpu_ih_decode_iv to read ahead of the last written IV, missing it, when this misalignment occurs. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 101384] [Hero Siege] si_shader: segfault in libLLVM-5.0.so.1
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=101384 Bug ID: 101384 Summary: [Hero Siege] si_shader: segfault in libLLVM-5.0.so.1 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: freedesktop(a)lanig.email QA Contact: dri-devel(a)lists.freedesktop.org Ubuntu 17.04 Padoka-PPA RX 480 Ryzen 7 1700X 32GiB RAM Hero Siege doesn't start. The kernel message is: si_shader:1[3325]: segfault at 0 ip 00000000e17b64f5 sp 00000000df6addf0 error 6 in libLLVM-5.0.so.1[e10c3000+360b000] The error number differs for each attempt. To reproduce this issue you might have to install these dependencies firstly: - libopenal-dev:i386 - libxrandr-dev:i386 - libglu-dev:i386 -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 101675] Peace, Death! crashed on start-up
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=101675 Bug ID: 101675 Summary: Peace, Death! crashed on start-up 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: t_arceri(a)yahoo.com.au QA Contact: dri-devel(a)lists.freedesktop.org Crashes on LLVMpipe and radeonsi. #0 0xf7fd4c89 in __kernel_vsyscall () #1 0xf76bd9a0 in raise () from /lib/libc.so.6 #2 0xf76bf067 in abort () from /lib/libc.so.6 #3 0xf76fc3ff in __libc_message () from /lib/libc.so.6 #4 0xf7705fde in _int_free () from /lib/libc.so.6 #5 0xf77098c3 in free () from /lib/libc.so.6 #6 0xf2441a0c in operator delete(void*) () from /lib/libLLVM-5.0svn.so #7 0xf244050c in operator delete(void*, unsigned int) () from /lib/libLLVM-5.0svn.so #8 0xf370ae33 in check_explicit_uniform_locations (ctx=<optimized out>, prog=<optimized out>) at glsl/linker.cpp:3485 #9 link_shaders (ctx=<optimized out>, prog=<optimized out>) at glsl/linker.cpp:4870 #10 0xf3648ecd in _mesa_glsl_link_shader (ctx=0x891b9f8, prog=0x895c798) at program/ir_to_mesa.cpp:3101 #11 0xf344e042 in create_new_program (key=0xffffacec, ctx=<optimized out>) at main/ff_fragment_shader.cpp:1126 #12 _mesa_get_fixed_func_fragment_program (ctx=<optimized out>) at main/ff_fragment_shader.cpp:1156 #13 0xf354b05d in update_program (ctx=ctx@entry=0x891b9f8) at main/state.c:134 #14 0xf354b355 in _mesa_update_state_locked (ctx=0x891b9f8) at main/state.c:348 #15 0xf354b452 in _mesa_update_state (ctx=0x891b9f8) at main/state.c:386 #16 0xf3563701 in teximage (no_error=false, pixels=0x0, imageSize=0, type=5121, format=6408, border=0, depth=<optimized out>, height=<optimized out>, width=<optimized out>, internalFormat=32856, level=0, target=3553, dims=2, compressed=0 '\000', ctx=0x891b9f8) at main/teximage.c:3035 #17 teximage_err (ctx=0x891b9f8, compressed=compressed@entry=0 '\000', dims=dims@entry=2, target=3553, level=0, internalFormat=<optimized out>, width=2000, height=2000, depth=1, border=<optimized out>, format=6408, type=5121, imageSize=0, pixels=0x0) at main/teximage.c:3084 #18 0xf3565c5a in _mesa_TexImage2D (target=3553, level=0, internalFormat=32856, width=2000, height=2000, border=0, format=6408, type=5121, pixels=0x0) at main/teximage.c:3122 -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 101769] 2X performance regression on Mesa 17.1 vs 17.0
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=101769 Bug ID: 101769 Summary: 2X performance regression on Mesa 17.1 vs 17.0 Product: Mesa Version: 17.1 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: david(a)lunarg.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 132646 --> https://bugs.freedesktop.org/attachment.cgi?id=132646&action=edit hack to apitrace for duplicating problem We have an internal OpenGL benchmarking tool that measures the performance of certain frames in apitrace files. We have been using this tool to measure the performance of various releases of Mesa. We recently found a large regression in Mesa performance of Half Life Episode 2, as measured by our benchmarking tool. We measured the following frame rates when running the benchmark with Mesa built from the listed source tags: tag mesa-17.0.0 358.6 fps tag mesa-17.1.3 151.1 fps This is a reduction in performance of more than 2X. Since the tool we use to measure performance is an internal tool and we cannot distribute it, I hacked apitrace to behave similar to our tool so that apitrace can be used to measure the performance of the problem frame. The frame rates I measured with this hacked apitrace benchmark are: tag mesa-17.0.0 417.7 fps commit 071d80b 393.9 fps commit f81ede4 324.6 fps tag mesa-17.1.3 196.0 fps The hacked apitrace shows about the same performance drop between mesa-17.0.0 and mesa-17.1.3 as our original benchmark. I also include the results for commits 071d80b and f81ede4 because commit f81ede4 seemed to show the single largest performance drop of all commits between mesa-17.0.0 and mesa-17.1.3. The configuration of the system I have been using to measure Mesa performance is: CPU: Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz RAM: 16Gb GPU: AMD RX480 Attached is the patch I applied to apitrace to create my hacked apitrace that attempts to duplicate the original benchmark. After building apitrace with the above patch, I used the following command to measure performance: vblank_mode=0 glretrace -b hl2_linux.trace I can make the hl2_linux.trace trace file available on request. We cannot widely distribute it because it contains Valve IP (i.e. game images). Please send a request directly to david(a)lunarg.com. Note that we have observed similar performance drops for other games, but I have concentrated on isolating and reporting on one frame in one game for now. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 101584] clover: ethminer -G --benchmark: ring buffer overflow, GPU faults
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=101584 Bug ID: 101584 Summary: clover: ethminer -G --benchmark: ring buffer overflow, GPU faults 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: haagch(a)frickel.club QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 132229 --> https://bugs.freedesktop.org/attachment.cgi?id=132229&action=edit dmesg Tested with my RX 480 on mesa git and Linux 4.11 and 4.12-rc. To reproduce, get https://github.com/ethereum-mining/ethminer in libethash-cl/ethash_cl_miner_kernel.cl add #pragma OPENCL EXTENSION cl_clang_storage_class_specifiers : enable then cmake . and make and in ethminer/ run ./ethminer -G --benchmark it outputs some progress and at 97% something goes wrong and I get GPU faults and/or GPU hangs. Interestingly with the closed source OpenCL runtime from amdgpu-pro it fails at 97% too. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=101325 Bug ID: 101325 Summary: UE4Editor crash after pressing "play" with radeon southern island card (7850 HD) Product: Mesa Version: git 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: dodgyville+freedesktop(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 131758 --> https://bugs.freedesktop.org/attachment.cgi?id=131758&action=edit ~/ddebug_dumps/ file with environment variables R600_DEBUG=check_vm GALLIUM_DDEBUG="pipelined 10000" Hi, thanks for your great work on bringing hardware accelerated graphics to linux. I have a recurring problem with one 3D program (UE4editor) crashing my computer during a particular operation (pressing "play" on any project including blank). I believe the problem is at the mesa layer. Brief details: Radeon 7850HD It crashes using radeon and amdgpu (on ubuntu 17.04, linux 4.11, padoka ppa). It does not crash using the fglrx driver (on ubuntu 14.04). The entire machine hangs and requires a reset. Following a suggestion from Michael I set the following environment variables for running ue4editor: R600_DEBUG=check_vm GALLIUM_DDEBUG="pipelined 10000" Now the program dumps without taking out the whole system. It created a file in ~/ddebug_dumps/ with more information about the GPU hang (attached). I have also attached the two dmesg logs for two separate trials involving the radeon and amdgpu modules. I blacklisted them both in grub2 and rebooted. I first manually loaded amdgpu and then after triggering the crash in ue4editor, rebooted and tried again with the manually loaded radeon module. The radeon one seems to give more information and the screen flashed a few times before freezing. When running amdgpu the x session just hangs and does nothing. I made sure I was running the latest (git 17-06-05) padoka builds. I was able to ssh into the machine for a while after the x session had completely frozen (including frozen mouse) until it also disconnected after a few minutes. This is the part of dmesg running radeon where it appears to go off the rails: radeon 0000:07:00.0: ring 4 stalled for more than 10024msec [ +0.000004] radeon 0000:07:00.0: GPU lockup (current fence id 0x0000000000000fd0 last fence id 0x0000000000000fd2 on ring 4) [ +0.485614] radeon 0000:07:00.0: Saved 724 dwords of commands on ring 0. [ +0.000126] radeon 0000:07:00.0: GPU softreset: 0x0000004D [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS = 0xA0403028 [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS_SE0 = 0x08000006 [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS_SE1 = 0x08000006 [ +0.000001] radeon 0000:07:00.0: SRBM_STATUS = 0x200000C0 [ +0.000118] radeon 0000:07:00.0: SRBM_STATUS2 = 0x00000000 [ +0.000002] radeon 0000:07:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008678_CP_STALLED_STAT2 = 0x00018000 [ +0.000001] radeon 0000:07:00.0: R_00867C_CP_BUSY_STAT = 0x00400006 [ +0.000001] radeon 0000:07:00.0: R_008680_CP_STAT = 0x84038647 [ +0.000001] radeon 0000:07:00.0: R_00D034_DMA_STATUS_REG = 0x44C83106 [ +0.000001] radeon 0000:07:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [ +0.000002] radeon 0000:07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ +0.000001] radeon 0000:07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ +0.465637] radeon 0000:07:00.0: GRBM_SOFT_RESET=0x0000DDFF [ +0.000052] radeon 0000:07:00.0: SRBM_SOFT_RESET=0x00100100 [ +0.001146] radeon 0000:07:00.0: GRBM_STATUS = 0x00003028 [ +0.000002] radeon 0000:07:00.0: GRBM_STATUS_SE0 = 0x00000006 [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS_SE1 = 0x00000006 [ +0.000000] radeon 0000:07:00.0: SRBM_STATUS = 0x200000C0 [ +0.000111] radeon 0000:07:00.0: SRBM_STATUS2 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008680_CP_STAT = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ +0.000001] radeon 0000:07:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [ +0.000247] radeon 0000:07:00.0: GPU reset succeeded, trying to resume [ +0.025448] [drm] probing gen 2 caps for device 8086:151 = 261a103/e [ +0.000003] [drm] PCIE gen 3 link speeds already enabled [ +0.002586] [drm] PCIE GART of 2048M enabled (table at 0x00000000001D6000). [ +0.000120] radeon 0000:07:00.0: WB enabled [ +0.000002] radeon 0000:07:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff94260bdd8c00 [ +0.000001] radeon 0000:07:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff94260bdd8c04 [ +0.000000] radeon 0000:07:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff94260bdd8c08 [ +0.000001] radeon 0000:07:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff94260bdd8c0c [ +0.000001] radeon 0000:07:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff94260bdd8c10 [ +0.000314] radeon 0000:07:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffaa3d89635a18 [ +0.010136] radeon 0000:07:00.0: failed VCE resume (-22). [ +0.159454] [drm] ring test on 0 succeeded in 4 usecs [ +0.000004] [drm] ring test on 1 succeeded in 1 usecs [ +0.000003] [drm] ring test on 2 succeeded in 1 usecs [ +0.000009] [drm] ring test on 3 succeeded in 6 usecs [ +0.000007] [drm] ring test on 4 succeeded in 5 usecs [ +0.175707] [drm] ring test on 5 succeeded in 2 usecs [ +0.000004] [drm] UVD initialized successfully. [ +1.041140] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed out. [ +0.000018] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110). [ +0.474934] radeon 0000:07:00.0: GPU softreset: 0x00000048 [ +0.000002] radeon 0000:07:00.0: GRBM_STATUS = 0xA0003028 [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS_SE0 = 0x00000006 [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS_SE1 = 0x00000006 [ +0.000001] radeon 0000:07:00.0: SRBM_STATUS = 0x200000C0 [ +0.000118] radeon 0000:07:00.0: SRBM_STATUS2 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008678_CP_STALLED_STAT2 = 0x00010000 [ +0.000001] radeon 0000:07:00.0: R_00867C_CP_BUSY_STAT = 0x00400002 [ +0.000002] radeon 0000:07:00.0: R_008680_CP_STAT = 0x84010243 [ +0.000001] radeon 0000:07:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ +0.000001] radeon 0000:07:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [ +0.000002] radeon 0000:07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ +0.000001] radeon 0000:07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ +0.465304] radeon 0000:07:00.0: GRBM_SOFT_RESET=0x0000DDFF [ +0.000056] radeon 0000:07:00.0: SRBM_SOFT_RESET=0x00000100 [ +0.001147] radeon 0000:07:00.0: GRBM_STATUS = 0x00003028 [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS_SE0 = 0x00000006 [ +0.000001] radeon 0000:07:00.0: GRBM_STATUS_SE1 = 0x00000006 [ +0.000001] radeon 0000:07:00.0: SRBM_STATUS = 0x200000C0 [ +0.000110] radeon 0000:07:00.0: SRBM_STATUS2 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_008680_CP_STAT = 0x00000000 [ +0.000001] radeon 0000:07:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ +0.000001] radeon 0000:07:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [ +0.000238] radeon 0000:07:00.0: GPU reset succeeded, trying to resume Eventually it starts to do this: [ +1.153721] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait timed out. [ +0.000018] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on ring 5 (-110). [ +0.000008] radeon 0000:07:00.0: scheduling IB failed (-12). [ +0.000011] [drm:radeon_vce_get_create_msg [radeon]] *ERROR* radeon: failed to schedule ib (-12). [ +0.000018] [drm:radeon_vce_ib_test [radeon]] *ERROR* radeon: failed to get create msg (-12). [ +0.000010] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on ring 6 (-12). [ +0.000002] radeon 0000:07:00.0: scheduling IB failed (-12). [ +0.000010] [drm:radeon_vce_get_create_msg [radeon]] *ERROR* radeon: failed to schedule ib (-12). [ +0.000009] [drm:radeon_vce_ib_test [radeon]] *ERROR* radeon: failed to get create msg (-12). [ +0.000009] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on ring 7 (-12). [ +0.001058] radeon 0000:07:00.0: GPU fault detected: 147 0x00044802 [ +0.000003] radeon 0000:07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000FF000 [ +0.000001] radeon 0000:07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x04048002 [ +0.000001] VM fault (0x02, vmid 2) at page 1044480, read from TC (72) [ +10.114896] radeon 0000:07:00.0: ring 0 stalled for more than 10116msec [ +0.000004] radeon 0000:07:00.0: GPU lockup (current fence id 0x0000000000001506 last fence id 0x000000000000151a on ring 0) [ +0.000022] radeon 0000:07:00.0: ring 4 stalled for more than 10112msec [ +0.000003] radeon 0000:07:00.0: GPU lockup (current fence id 0x0000000000000fd3 last fence id 0x0000000000000fd7 on ring 4) [ +0.000029] radeon 0000:07:00.0: ring 3 stalled for more than 10116msec [ +0.000002] radeon 0000:07:00.0: GPU lockup (current fence id 0x00000000000018b7 last fence id 0x000000000000190c on ring 3) [ +0.507937] radeon 0000:07:00.0: ring 3 stalled for more than 10624msec [ +0.000001] radeon 0000:07:00.0: ring 0 stalled for more than 10624msec Then the log repeats a few hundred times the non-utf-8 character "\00" before it cuts off. This is the part of dmesg running amdgpu where it appears to go off the rails: [Jun 6 11:16] INFO: task RenderThread 3:6190 blocked for more than 120 seconds. [ +0.000006] Tainted: G OE 4.11.0-mytest #2 [ +0.000002] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ +0.000002] RenderThread 3 D 0 6190 1612 0x00000000 [ +0.000003] Call Trace: [ +0.000007] __schedule+0x3c6/0x8c0 [ +0.000004] schedule+0x36/0x80 [ +0.000043] amd_sched_entity_push_job+0xc4/0x110 [amdgpu] [ +0.000003] ? wake_atomic_t_function+0x60/0x60 [ +0.000031] amdgpu_job_submit+0x72/0x90 [amdgpu] [ +0.000027] amdgpu_vm_bo_split_mapping+0x51f/0x7c0 [amdgpu] [ +0.000024] ? amdgpu_vm_do_copy_ptes+0x90/0x90 [amdgpu] [ +0.000024] amdgpu_vm_clear_freed+0x70/0xb0 [amdgpu] [ +0.000024] amdgpu_gem_va_ioctl+0x39a/0x3f0 [amdgpu] [ +0.000014] drm_ioctl+0x218/0x4b0 [drm] [ +0.000010] ? drm_ioctl+0x218/0x4b0 [drm] [ +0.000023] ? amdgpu_gem_metadata_ioctl+0x1d0/0x1d0 [amdgpu] [ +0.000003] ? kmem_cache_free+0x1b6/0x1e0 [ +0.000020] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] [ +0.000003] do_vfs_ioctl+0xa3/0x600 [ +0.000002] ? ____fput+0xe/0x10 [ +0.000003] ? task_work_run+0x85/0xa0 [ +0.000002] SyS_ioctl+0x79/0x90 [ +0.000002] entry_SYSCALL_64_fastpath+0x1e/0xad [ +0.000002] RIP: 0033:0x7fb15e3cb987 [ +0.000001] RSP: 002b:00007faefab6a778 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ +0.000002] RAX: ffffffffffffffda RBX: 00007faf340060e0 RCX: 00007fb15e3cb987 [ +0.000001] RDX: 00007faefab6a7c0 RSI: 00000000c0286448 RDI: 0000000000000009 [ +0.000001] RBP: 00007faefab6a810 R08: 000000011c430000 R09: 000000000000000e [ +0.000001] R10: 0000000000000002 R11: 0000000000000246 R12: 0000000040086409 [ +0.000001] R13: 0000000000000009 R14: 00007faf34ef5700 R15: 00007faf34d61780 [Jun 6 11:17] wlp4s0: disconnect from AP 80:2a:a8:11:23:5e for new auth to 80:2a:a8:11:24:29 [ +0.011326] wlp4s0: authenticate with 80:2a:a8:11:24:29 [ +0.020720] wlp4s0: send auth to 80:2a:a8:11:24:29 (try 1/3) [ +0.002594] wlp4s0: authenticated [ +0.002803] wlp4s0: associate with 80:2a:a8:11:24:29 (try 1/3) [ +0.005088] wlp4s0: RX AssocResp from 80:2a:a8:11:24:29 (capab=0x431 status=0 aid=2) [ +0.000223] wlp4s0: associated End of xorg.log.0 (for an earlier run) [ 12.056] (II) systemd-logind: got pause for 13:79 [ 32.415] (II) config/udev: removing GPU device /sys/devices/pci0000:00/0000:00:01.0/0000:07:00.0/drm/card0 /dev/dri/card0 [ 32.415] (II) config/udev: Adding drm device (/dev/dri/card0) [ 32.415] (II) xfree86: Adding drm device (/dev/dri/card0) [ 35.984] (II) systemd-logind: got resume for 13:81 [ 35.984] (EE) FBDEV(0): FBIOPUT_VSCREENINFO: No such device [ 35.984] (EE) Fatal server error: [ 35.984] (EE) EnterVT failed for screen 0 [ 35.984] (EE) [ 35.984] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 35.984] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 35.984] (EE) [ 35.984] (EE) FBDEV(0): FBIOPUT_VSCREENINFO: No such device [ 36.074] (EE) Server terminated with error (1). Closing log file. -- You are receiving this mail because: You are the assignee for the bug.

1 27

[Bug 101229] Global screen tearing (scrolling, Hz miss-match?)
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=101229 Bug ID: 101229 Summary: Global screen tearing (scrolling, Hz miss-match?) Product: Mesa Version: 17.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: Paul.Hancock.17041993(a)live.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 131571 --> https://bugs.freedesktop.org/attachment.cgi?id=131571&action=edit glxinfo System exhibits uncontrolled screen-tearing that can be seen when moving windows, watching videos or playing games, or any graphical movement in general. The tearing gradually shifts up or down the screen, suggesting its a cycle frequency miss-match (or floating-point error). Has affected mesa 12 and kernel 4.8 onwards. -- You are receiving this mail because: You are the assignee for the bug.

1 20

[Bug 101185] System hang during piglit tests
by bugzilla-daemon＠freedesktop.org 25 Sep '19

25 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=101185 Bug ID: 101185 Summary: System hang during piglit tests Product: Mesa Version: git 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: keppi5(a)gmx.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 131505 --> https://bugs.freedesktop.org/attachment.cgi?id=131505&action=edit crash logs and piglit result json I was running "piglit run tests/quick results/quick" yesterday and system suddenly stopped responding at test 36216/39353. I was forced to do 5 second power switch shut down. Today I ran the test again and it didn't hang the system but stopped progressing at 38239/39353 where I did Ctrl-C. Attached is backtrace of crashes. $ inxi -G Graphics: Card: Advanced Micro Devices [AMD/ATI] Tonga PRO [Radeon R9 285/380] Display Server: X.Org 1.19.3 driver: amdgpu Resolution: 1920x1080(a)60.00hz, 1920x1080(a)60.00hz GLX Renderer: Gallium 0.4 on AMD TONGA (DRM 3.15.0 / 4.12.0-rc1-g2ea659a9ef48, LLVM 5.0.0) GLX Version: 3.0 Mesa 17.2.0-devel (git-1586768e74) -- 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 July 2017