dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[Bug 38364] New: Ignoring invalid EDID block 1 do entire edid is invalid and not just block 1
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=38364 Summary: Ignoring invalid EDID block 1 do entire edid is invalid and not just block 1 Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: General AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: zaverel(a)free.fr Hello , All is fine except i can't change resolution on my second monitor vga ,tv in fact, (reported as DVI-I-2 ) anymore with my 9400gt. Now , i'm on : linux-2.6.39-gentoo-r1 xorg-server-1.10.2 xf86-video-nouveau-0.0.16_pre20110323 libdrm-2.4.25 Errors in dmesg are: nouveau 0000:02:00.0: DVI-I-2: Ignoring invalid EDID block 1. [drm:drm_edid_block_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ whatever i valid with xrandr is not really do on my tv although xrandr say it's good , my tv always report 1202x670 50hz I tried with and without xorg.conf My last kernel working is linux-2.6.36-gentoo-r6. If, i tweak drm_edid.c from kernel-2.6.39-gentoo-r1 like this: --- drm_edid.c 2011-06-10 22:37:36.605848000 +0200 +++ linux/drivers/gpu/drm/drm_edid.c 2011-06-13 13:04:43.136786102 +0200 @@ -292,7 +292,7 @@ block + (valid_extensions + 1) * EDID_LENGTH, j, EDID_LENGTH)) goto out; - if (drm_edid_block_valid(block + (valid_extensions + 1) * EDID_LENGTH)) { + if (drm_edid_block_valid(block + (valid_extensions + 0) * EDID_LENGTH)) { valid_extensions++; break; } that work good like before but i'm not sure that is safe. More info in http://lists.freedesktop.org/archives/nouveau/2011-June/008548.html I can post logs here too , just tell me. See you -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[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 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016