dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[RFC 0/6] udmabuf guest <--> host interaction model
by Gurchetan Singh 05 Aug '19

05 Aug '19

It's desirable to use zero-copy mechanisms when using various graphics buffers. With udmabuf, two cases come to mind: 1) Directly scan-out a guest-mapped buffer 2) Import into VK with VK_EXT_external_memory_dma_buf However, displays are not generally coherent with the CPU and many GPUs aren't either. So we need to map write-combine in the guest. One way to achieve this is to synchronize on the host. [warning] -- only compile tested at this point to get feedback Gurchetan Singh (6): udmabuf: use cache_sgt_mapping option udmabuf: add ability to set access flags on udmabuf udmabuf: enforce access flags udmabuf: add a pointer to the miscdevice in dma-buf private data udmabuf: separate out creating/destroying scatter-table udmabuf: implement begin_cpu_access/end_cpu_access hooks drivers/dma-buf/udmabuf.c | 103 +++++++++++++++++++++++++++++------ include/uapi/linux/udmabuf.h | 5 +- 2 files changed, 90 insertions(+), 18 deletions(-) -- 2.17.1

2 11

[Bug 105282] Divinity: Original Sin Enhanced Edition blocky and jagged shadows.
by bugzilla-daemon＠freedesktop.org 05 Aug '19

05 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=105282 Bug ID: 105282 Summary: Divinity: Original Sin Enhanced Edition blocky and jagged shadows. Product: Mesa Version: 17.3 Hardware: All OS: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: e.singularitycat(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org After working around the bugs described in #93551 and getting the game running, I noticed that unless the shadow quality setting was at "Ultra", all rendered shadows are blocky and jagged, with gaps appearing between the shadows cast be apparently solid objects. I messed around with some driconf options, and discovered that this rendering issue goes away if setting the "glsl_correct_derivatives_after_discard" option. Unfortunately, I couldn't get a working apitrace because of the LD_PRELOAD hacks, but attached are two screenshots of roughly the same area, one without the option (before.png) and one with (after.png). -- You are receiving this mail because: You are the assignee for the bug.

1 3

Re: Linux Kernel 5.1.21 (i915)
by Randy Dunlap 05 Aug '19

05 Aug '19

On 8/4/19 8:11 PM, Nathaniel Russell wrote: > I'm getting an error message when the uvcvideo module is loaded into > the kernel. Can somebody help me figure this out please? > Looks more like it is related to i915 driver: [ 18.728238] ------------[ cut here ]------------ [ 18.728248] timed out waiting for port C ready: got 0x20, expected 0xe0 [ 18.728705] WARNING: CPU: 1 PID: 239 at drivers/gpu/drm/i915/intel_display.c:1614 vlv_wait_port_ready+0x8d/0xd0 [i915] [ 18.728708] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops rtsx_usb videobuf2_v4l2 videodev videobuf2_common btusb btrtl btbcm btintel bluetooth ecdh_generic joydev intel_xhci_usb_role_switch wmi_bmof dell_wmi roles sparse_keymap iwlmvm mac80211 dell_smm_hwmon dell_laptop ledtrig_audio dell_smbios dell_wmi_descriptor dcdbas coretemp hwmon iwlwifi intel_rapl cfg80211 intel_powerclamp kvm_intel psmouse kvm i915 irqbypass evdev crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw cec ghash_clmulni_intel intel_cstate rc_core drm_kms_helper snd_hda_intel tpm_crb tpm_tis ac drm intel_gtt tpm_tis_core snd_hda_codec battery agpgart i2c_algo_bit snd_hda_core wmi fb_sys_fops snd_hwdep snd_pcm syscopyarea fan thermal sdhci_pci snd_timer sysfillrect snd dell_rbtn sysimgblt mei_txe cqhci sdhci tpm i2c_hid hid mei video mmc_core processor_thermal_device rfkill int340x_thermal_zone int3400_thermal intel_soc_dts_iosf acpi_thermal_rel soundcore i2c_i801 xhci_pci button xhci_hcd [ 18.728876] pinctrl_cherryview i2c_core lpc_ich pcc_cpufreq loop [ 18.728897] CPU: 1 PID: 239 Comm: kworker/u4:3 Not tainted 5.1.21 #3 [ 18.728901] Hardware name: Dell Inc. Inspiron 15-3552/001T3K, BIOS 4.2.0 10/27/2017 [ 18.728916] Workqueue: events_unbound async_run_entry_fn [ 18.729188] RIP: 0010:vlv_wait_port_ready+0x8d/0xd0 [i915] Full dmesg is reattached. -- ~Randy

1 0

The issue with page allocation 5.3 rc1-rc2 (seems drm culprit here)
by Mikhail Gavrilov 05 Aug '19

05 Aug '19

Hi folks, Two weeks ago when commit 22051d9c4a57 coming to my system. Started happen randomly errors: "gnome-shell: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0" Symptoms: The screen goes out as in energy saving. And it is impossible to wake the computer in a few minutes. I am making bisect and looks like the first bad commit is 476e955dd679. Here full bisect logs: https://mega.nz/#F!kgYFxAIb!v1tcHANPy2ns1lh4LQLeIg I wrote about my find to the amd-gfx mailing list, but no one answer me. Until yesterday, I thought it was a bug in the amdgpu driver. But yesterday, after the next occurrence of an error, the system hangs completely already with another error. [ 3225.317560] BUG: unable to handle page fault for address: 000000000000c9f4 [ 3225.317562] #PF: supervisor read access in kernel mode [ 3225.317563] #PF: error_code(0x0000) - not-present page [ 3225.317565] PGD 0 P4D 0 [ 3225.317567] Oops: 0000 [#1] SMP NOPTI [ 3225.317571] CPU: 2 PID: 12717 Comm: Xorg Tainted: G W 5.3.0-0.rc2.git4.1.fc31.x86_64 #1 [ 3225.317572] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 2406 06/21/2019 [ 3225.317625] RIP: 0010:dc_resource_state_copy_construct+0x18/0xf0 [amdgpu] [ 3225.317627] Code: 00 49 83 c4 01 44 39 e0 7f b5 5b 5d 41 5c 41 5d c3 c3 0f 1f 44 00 00 41 56 ba f8 c9 00 00 41 55 41 54 49 89 f4 55 4c 89 e5 53 <44> 8b ae f4 c9 00 00 48 89 fe 4c 89 e7 e8 16 86 48 f7 49 8d 84 24 [ 3225.317630] RSP: 0018:ffffb439c3e377d0 EFLAGS: 00010246 [ 3225.317631] RAX: ffff9b0ba19a0000 RBX: ffffffffc08380b0 RCX: 0000000000000006 [ 3225.317633] RDX: 000000000000c9f8 RSI: 0000000000000000 RDI: ffff9b0ab7fc0000 [ 3225.317635] RBP: 0000000000000000 R08: 000002eef3c694b7 R09: 0000000000000000 [ 3225.317636] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 3225.317638] R13: ffff9b0bb5381000 R14: ffff9b09acc68598 R15: ffff9b09acc68540 [ 3225.317640] FS: 00007fdde56cbf00(0000) GS:ffff9b0bba400000(0000) knlGS:0000000000000000 [ 3225.317641] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3225.317643] CR2: 000000000000c9f4 CR3: 00000007382ee000 CR4: 00000000003406e0 [ 3225.317644] Call Trace: [ 3225.317714] amdgpu_dm_atomic_commit_tail.cold+0xad/0xe1 [amdgpu] [ 3225.317719] ? lockdep_hardirqs_on+0xf0/0x180 [ 3225.317723] ? debug_check_no_obj_freed+0x107/0x1d8 [ 3225.317786] ? dm_determine_update_type_for_commit+0x34c/0x420 [amdgpu] [ 3225.317850] ? dm_determine_update_type_for_commit+0x34c/0x420 [amdgpu] [ 3225.317855] ? kfree+0x1b6/0x3b0 [ 3225.317918] ? dm_determine_update_type_for_commit+0x34c/0x420 [amdgpu] [ 3225.317923] ? __lock_acquire+0x247/0x1910 [ 3225.317928] ? find_held_lock+0x32/0x90 [ 3225.317931] ? mark_held_locks+0x50/0x80 [ 3225.317934] ? _raw_spin_unlock_irq+0x29/0x40 [ 3225.317937] ? lockdep_hardirqs_on+0xf0/0x180 [ 3225.317939] ? _raw_spin_unlock_irq+0x29/0x40 [ 3225.317942] ? wait_for_completion_timeout+0x75/0x190 [ 3225.317954] ? commit_tail+0x3c/0x70 [drm_kms_helper] [ 3225.317960] commit_tail+0x3c/0x70 [drm_kms_helper] [ 3225.317968] drm_atomic_helper_commit+0xe3/0x150 [drm_kms_helper] [ 3225.317975] drm_atomic_helper_disable_plane+0x82/0xb0 [drm_kms_helper] [ 3225.317994] drm_mode_cursor_universal+0x12c/0x240 [drm] [ 3225.318011] drm_mode_cursor_common+0xd8/0x230 [drm] [ 3225.318026] ? drm_mode_setplane+0x1a0/0x1a0 [drm] [ 3225.318038] drm_mode_cursor_ioctl+0x4d/0x70 [drm] [ 3225.318049] drm_ioctl_kernel+0xaa/0xf0 [drm] [ 3225.318061] drm_ioctl+0x208/0x390 [drm] [ 3225.318075] ? drm_mode_setplane+0x1a0/0x1a0 [drm] [ 3225.318079] ? lockdep_hardirqs_on+0xf0/0x180 [ 3225.318145] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [ 3225.318164] do_vfs_ioctl+0x411/0x750 [ 3225.318175] ksys_ioctl+0x5e/0x90 [ 3225.318179] __x64_sys_ioctl+0x16/0x20 [ 3225.318188] do_syscall_64+0x5c/0xb0 [ 3225.318191] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 3225.318194] RIP: 0033:0x7fdde5b4007b [ 3225.318203] Code: 0f 1e fa 48 8b 05 0d 9e 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 9d 0c 00 f7 d8 64 89 01 48 [ 3225.318209] RSP: 002b:00007ffec481a6d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 3225.318213] RAX: ffffffffffffffda RBX: 00007ffec481a710 RCX: 00007fdde5b4007b [ 3225.318215] RDX: 00007ffec481a710 RSI: 00000000c01c64a3 RDI: 000000000000000e [ 3225.318217] RBP: 00000000c01c64a3 R08: 0000000000000080 R09: 0000000000000000 [ 3225.318218] R10: 0000000000000004 R11: 0000000000000246 R12: 00000000000006f1 [ 3225.318220] R13: 000000000000000e R14: 000056201b5b5490 R15: 000056201bbe7820 [ 3225.318225] Modules linked in: macvtap macvlan tap rfcomm xt_CHECKSUM xt_MASQUERADE nf_nat_tftp nf_conntrack_tftp tun bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter cmac bnep sunrpc vfat fat snd_hda_codec_realtek edac_mce_amd snd_hda_codec_generic ledtrig_audio kvm_amd rtwpci snd_hda_codec_hdmi rtw88 kvm snd_hda_intel snd_usb_audio snd_hda_codec mac80211 snd_hda_core snd_usbmidi_lib irqbypass snd_rawmidi uvcvideo snd_hwdep snd_seq videobuf2_vmalloc videobuf2_memops btusb videobuf2_v4l2 crct10dif_pclmul snd_seq_device videobuf2_common btrtl crc32_pclmul eeepc_wmi snd_pcm btbcm btintel asus_wmi xpad snd_timer sparse_keymap [ 3225.318261] videodev ff_memless bluetooth joydev ghash_clmulni_intel cfg80211 video snd mc k10temp wmi_bmof soundcore ecdh_generic sp5100_tco ecc rfkill ccp i2c_piix4 libarc4 gpio_amdpt gpio_generic acpi_cpufreq binfmt_misc ip_tables hid_logitech_hidpp amdgpu amd_iommu_v2 gpu_sched ttm drm_kms_helper drm igb crc32c_intel dca i2c_algo_bit hid_logitech_dj nvme nvme_core wmi pinctrl_amd [ 3225.318283] CR2: 000000000000c9f4 Every time when I see "SMP NOPTI" error I think that something wrong happens with memory management. So I decided to ask for help on the linux-mm mailing list. Anyway for unknown reasons AMD developers ignored me. Thanks. -- Best Regards, Mike Gavrilov.

2 1

[PATCH hmm] drm/amdkfd: fix a use after free race with mmu_notififer unregister
by Jason Gunthorpe 04 Aug '19

04 Aug '19

When using mmu_notififer_unregister_no_release() the caller must ensure there is a SRCU synchronize before the mn memory is freed, otherwise use after free races are possible, for instance: CPU0 CPU1 invalidate_range_start hlist_for_each_entry_rcu(..) mmu_notifier_unregister_no_release(&p->mn) kfree(mn) if (mn->ops->invalidate_range_end) The error unwind in amdkfd misses the SRCU synchronization. amdkfd keeps the kfd_process around until the mm is released, so split the flow to fully initialize the kfd_process and register it for find_process, and with the notifier. Past this point the kfd_process does not need to be cleaned up as it is fully ready. The final failable step does a vm_mmap() and does not seem to impact the kfd_process global state. Since it also cannot be undone (and already has problems with undo if it internally fails), it has to be last. This way we don't have to try to unwind the mmu_notifier_register() and avoid the problem with the SRCU. Along the way this also fixes various other error unwind bugs in the flow. Fixes: 45102048f77e ("amdkfd: Add process queue manager module") Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 74 +++++++++++------------- 1 file changed, 35 insertions(+), 39 deletions(-) amdkfd folks, this little bug is blocking some rework I have for the mmu notifiers (ie mm/mmu_notifiers: remove unregister_no_release) Can I get your help to review and if needed polish this change? I'd like to send this patch through the hmm tree along with the rework, thanks You can see the larger series here: https://github.com/jgunthorpe/linux/commits/mmu_notifier Jason diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 8f1076c0c88a25..81e3ee3f1813bf 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -62,8 +62,8 @@ static struct workqueue_struct *kfd_restore_wq; static struct kfd_process *find_process(const struct task_struct *thread); static void kfd_process_ref_release(struct kref *ref); -static struct kfd_process *create_process(const struct task_struct *thread, - struct file *filep); +static struct kfd_process *create_process(const struct task_struct *thread); +static int kfd_process_init_cwsr_apu(struct kfd_process *p, struct file *filep); static void evict_process_worker(struct work_struct *work); static void restore_process_worker(struct work_struct *work); @@ -289,7 +289,15 @@ struct kfd_process *kfd_create_process(struct file *filep) if (process) { pr_debug("Process already found\n"); } else { - process = create_process(thread, filep); + process = create_process(thread); + if (IS_ERR(process)) + goto out; + + ret = kfd_process_init_cwsr_apu(process, filep); + if (ret) { + process = ERR_PTR(ret); + goto out; + } if (!procfs.kobj) goto out; @@ -609,64 +617,56 @@ static int kfd_process_device_init_cwsr_dgpu(struct kfd_process_device *pdd) return 0; } -static struct kfd_process *create_process(const struct task_struct *thread, - struct file *filep) +/* + * On return the kfd_process is fully operational and will be freed when the + * mm is released + */ +static struct kfd_process *create_process(const struct task_struct *thread) { struct kfd_process *process; int err = -ENOMEM; process = kzalloc(sizeof(*process), GFP_KERNEL); - if (!process) goto err_alloc_process; - process->pasid = kfd_pasid_alloc(); - if (process->pasid == 0) - goto err_alloc_pasid; - - if (kfd_alloc_process_doorbells(process) < 0) - goto err_alloc_doorbells; - kref_init(&process->ref); - mutex_init(&process->mutex); - process->mm = thread->mm; - - /* register notifier */ - process->mmu_notifier.ops = &kfd_process_mmu_notifier_ops; - err = mmu_notifier_register(&process->mmu_notifier, process->mm); - if (err) - goto err_mmu_notifier; - - hash_add_rcu(kfd_processes_table, &process->kfd_processes, - (uintptr_t)process->mm); - process->lead_thread = thread->group_leader; - get_task_struct(process->lead_thread); - INIT_LIST_HEAD(&process->per_device_data); - + INIT_DELAYED_WORK(&process->eviction_work, evict_process_worker); + INIT_DELAYED_WORK(&process->restore_work, restore_process_worker); + process->last_restore_timestamp = get_jiffies_64(); kfd_event_init_process(process); + process->is_32bit_user_mode = in_compat_syscall(); + + process->pasid = kfd_pasid_alloc(); + if (process->pasid == 0) + goto err_alloc_pasid; + + if (kfd_alloc_process_doorbells(process) < 0) + goto err_alloc_doorbells; err = pqm_init(&process->pqm, process); if (err != 0) goto err_process_pqm_init; /* init process apertures*/ - process->is_32bit_user_mode = in_compat_syscall(); err = kfd_init_apertures(process); if (err != 0) goto err_init_apertures; - INIT_DELAYED_WORK(&process->eviction_work, evict_process_worker); - INIT_DELAYED_WORK(&process->restore_work, restore_process_worker); - process->last_restore_timestamp = get_jiffies_64(); - - err = kfd_process_init_cwsr_apu(process, filep); + /* Must be last, have to use release destruction after this */ + process->mmu_notifier.ops = &kfd_process_mmu_notifier_ops; + err = mmu_notifier_register(&process->mmu_notifier, process->mm); if (err) goto err_init_cwsr; + get_task_struct(process->lead_thread); + hash_add_rcu(kfd_processes_table, &process->kfd_processes, + (uintptr_t)process->mm); + return process; err_init_cwsr: @@ -675,15 +675,11 @@ static struct kfd_process *create_process(const struct task_struct *thread, err_init_apertures: pqm_uninit(&process->pqm); err_process_pqm_init: - hash_del_rcu(&process->kfd_processes); - synchronize_rcu(); - mmu_notifier_unregister_no_release(&process->mmu_notifier, process->mm); -err_mmu_notifier: - mutex_destroy(&process->mutex); kfd_free_process_doorbells(process); err_alloc_doorbells: kfd_pasid_free(process->pasid); err_alloc_pasid: + mutex_destroy(&process->mutex); kfree(process); err_alloc_process: return ERR_PTR(err); -- 2.22.0

2 1

[PATCH v1] drm/tegra: dc: Turn off and reset hardware across suspend-resume
by Dmitry Osipenko 04 Aug '19

04 Aug '19

The drivers core bumps runtime PM refcount during of entering into suspend to workaround some problem where parent device may become turned off before its children. For now CRTCs are only getting disabled on suspend and in order to actually suspend the display controllers hardware, the runtime PM needed to be "forced" into suspend mode. Signed-off-by: Dmitry Osipenko <digetx(a)gmail.com> --- drivers/gpu/drm/tegra/dc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 4a75d149e368..6c8f5222d558 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -2572,6 +2572,8 @@ static int tegra_dc_resume(struct device *dev) static const struct dev_pm_ops tegra_dc_pm_ops = { SET_RUNTIME_PM_OPS(tegra_dc_suspend, tegra_dc_resume, NULL) + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, + pm_runtime_force_resume) }; struct platform_driver tegra_dc_driver = { -- 2.22.0

1 0

[PATCH 0/3] RFT: PL111 DRM conversion of nspire
by Linus Walleij 04 Aug '19

04 Aug '19

So this is a cold-coded attempt to move the TI nspire over to using DRM. It is more or less the last user of the old fbdev driver so it is a noble cause and interesting usecase. This can be applied on top of a vanilla Torvalds v5.3-rc1 kernel out since sunday. I do not expect these patches to "just work", I expect them to need some hacking, so someone who is actually working on the hardware will need to step in and fix it up. It does outline the overall idea of how to do this. I found no defconfig for nspire in the kernel so I used ARMv4t multi. Configuring the driver for nspire: - Disable CONFIG_FB_ARMCLCD - Enable CONFIG_DRM_PL111, CONFIG_DRM_PANEL_SIMPLE Hacker notes for nspire: - I don't know which PrimeCell ID this hardware has, I hope the amba_id mask in drivers/gpu/drm/pl111/pl111_drv.c for PL111 and PL110 will match it. Please confirm that you get a clean probe call, else report what ID this has. - The 24bit RGB frame buffer may be a bit much for the PL111 in the TI nspire to handle. Try editing the .fb_bpp in drivers/gpu/drm/pl111/pl111_drv.c down to 16 if this is the PL111 variant. If it is the PL110 variant, we will get 16 buts framebuffer anyway. - I have hard-coded the panels to 1MHz, based on the fact that the AHB clock into the CLCD appears to be 48 MHz and the hard-coded TIM2 value for the classic means "divide by 48" and this seems to want the clock freq divided down to 1MHz. Verify this by adding prints inside drivers/gpu/drm/pl111/pl111_display.c in the function pl111_clk_div_set_rate() to verify that the divider gets set to 48 in TIM2_PCD_HI and TIM2_PCD_LO. TIM2_PCD_LO bits 0..4 = 10000 and TIM2_PCD_HI bits 27..31 = 00001 in that register. Please test and fix, if you can. Linus Walleij (3): RFT: drm/pl111: Support grayscale RTF: drm/panel: simple: Add TI nspire panels RFT: ARM: nspire: Move CLCD set-up to device tree arch/arm/boot/dts/nspire-classic.dtsi | 19 ++++- arch/arm/boot/dts/nspire-cx.dts | 18 +++- arch/arm/boot/dts/nspire.dtsi | 10 ++- arch/arm/mach-nspire/Makefile | 1 - arch/arm/mach-nspire/clcd.c | 114 -------------------------- arch/arm/mach-nspire/clcd.h | 10 --- arch/arm/mach-nspire/nspire.c | 25 ------ drivers/gpu/drm/panel/panel-simple.c | 63 ++++++++++++++ drivers/gpu/drm/pl111/pl111_display.c | 28 ++++++- include/linux/amba/clcd-regs.h | 1 + 10 files changed, 133 insertions(+), 156 deletions(-) delete mode 100644 arch/arm/mach-nspire/clcd.c delete mode 100644 arch/arm/mach-nspire/clcd.h -- 2.21.0

7 20

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
by bugzilla-daemon＠freedesktop.org 04 Aug '19

04 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #78 from Mauro Gaspari <ilvipero(a)gmx.com> --- (In reply to Sylvain BERTRAND from comment #77) > On Sun, Aug 04, 2019 at 05:05:52AM +0000, bugzilla-daemon(a)freedesktop.org > wrote: > > By the way, Interesting to see that even my ubuntu budgie LTS with valve > > mesa-aco and different kernel, has the same warning. > > [ 5.739656] amdgpu 0000:0a:00.0: Direct firmware load for > > amdgpu/vega20_ta.bin failed with error -2 > > [ 5.739659] amdgpu 0000:0a:00.0: psp v11.0: Failed to load firmware > > "amdgpu/vega20_ta.bin" > > I don't know of an AMD GPU part able to run without properly loaded firmware. > > That would have to be confirmed by official AMD devs which are the sole ppl > with that knowledge. > > In the very probable case that the firmware _must_ be loaded for proper gpu > operations, you have to tell the maintainers of the distros you use to update > their linux/amdgpu firmware package. I believe so, and yes it makes total sense that you need the correct firmware for a piece of hardware to work properly. I will open bugs for openSUSE and ubuntu, and ask the questions, point to this bug tracker. Let's see what comes out. I will report back as I hear from distribution maintainers. I am using a RadeonVII at the moment. Is there anyone with a Vega64 or Vega56 that can do the same tests and let me know if they see same issue? I am happy to include those cards in my same bug reports if someone can confirm. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
by bugzilla-daemon＠freedesktop.org 04 Aug '19

04 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #77 from Sylvain BERTRAND <sylvain.bertrand(a)gmail.com> --- On Sun, Aug 04, 2019 at 05:05:52AM +0000, bugzilla-daemon(a)freedesktop.org wrote: > By the way, Interesting to see that even my ubuntu budgie LTS with valve > mesa-aco and different kernel, has the same warning. > [ 5.739656] amdgpu 0000:0a:00.0: Direct firmware load for > amdgpu/vega20_ta.bin failed with error -2 > [ 5.739659] amdgpu 0000:0a:00.0: psp v11.0: Failed to load firmware > "amdgpu/vega20_ta.bin" I don't know of an AMD GPU part able to run without properly loaded firmware. That would have to be confirmed by official AMD devs which are the sole ppl with that knowledge. In the very probable case that the firmware _must_ be loaded for proper gpu operations, you have to tell the maintainers of the distros you use to update their linux/amdgpu firmware package. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
by bugzilla-daemon＠freedesktop.org 04 Aug '19

04 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #76 from Mauro Gaspari <ilvipero(a)gmx.com> --- (In reply to Sylvain BERTRAND from comment #75) > On Sat, Aug 03, 2019 at 05:43:01PM +0000, bugzilla-daemon(a)freedesktop.org > wrote: > > > > [ 5.759204] amdgpu 0000:0a:00.0: Direct firmware load for > > > > amdgpu/vega20_ta.bin failed with error -2 > > > > [ 5.759205] amdgpu 0000:0a:00.0: psp v11.0: Failed to load firmware > > > > "amdgpu/vega20_ta.bin" > > It seems you have a corrupted/old/missing vega20_ta.bin firmware file. > It looks like outdated distro files. Hello, I did some quick search online and it seems a common problem for many users amdgpu. And looking around on other reports they seem to be dismissed as warnings and not mandatory. I am not an expert and I do not want to dismiss it here, just report what I see. By the way, Interesting to see that even my ubuntu budgie LTS with valve mesa-aco and different kernel, has the same warning. [ 5.435346] [drm] amdgpu kernel modesetting enabled. [ 5.435500] fb0: switching to amdgpudrmfb from EFI VGA [ 5.735058] amdgpu 0000:0a:00.0: No more image in the PCI ROM [ 5.735102] amdgpu 0000:0a:00.0: VRAM: 16368M 0x0000008000000000 - 0x00000083FEFFFFFF (16368M used) [ 5.735103] amdgpu 0000:0a:00.0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF [ 5.735104] amdgpu 0000:0a:00.0: AGP: 267894784M 0x0000008400000000 - 0x0000FFFFFFFFFFFF [ 5.735185] [drm] amdgpu: 16368M of VRAM memory ready [ 5.735186] [drm] amdgpu: 16368M of GTT memory ready. [ 5.739656] amdgpu 0000:0a:00.0: Direct firmware load for amdgpu/vega20_ta.bin failed with error -2 [ 5.739659] amdgpu 0000:0a:00.0: psp v11.0: Failed to load firmware "amdgpu/vega20_ta.bin" [ 6.354308] fbcon: amdgpudrmfb (fb0) is primary device [ 6.354490] amdgpu 0000:0a:00.0: fb0: amdgpudrmfb frame buffer device [ 6.384079] amdgpu 0000:0a:00.0: ring gfx uses VM inv eng 0 on hub 0 [ 6.384080] amdgpu 0000:0a:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0 [ 6.384081] amdgpu 0000:0a:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0 [ 6.384082] amdgpu 0000:0a:00.0: ring comp_1.2.0 uses VM inv eng 5 on hub 0 [ 6.384083] amdgpu 0000:0a:00.0: ring comp_1.3.0 uses VM inv eng 6 on hub 0 [ 6.384084] amdgpu 0000:0a:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0 [ 6.384084] amdgpu 0000:0a:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0 [ 6.384085] amdgpu 0000:0a:00.0: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [ 6.384086] amdgpu 0000:0a:00.0: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [ 6.384087] amdgpu 0000:0a:00.0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0 [ 6.384088] amdgpu 0000:0a:00.0: ring sdma0 uses VM inv eng 0 on hub 1 [ 6.384089] amdgpu 0000:0a:00.0: ring page0 uses VM inv eng 1 on hub 1 [ 6.384089] amdgpu 0000:0a:00.0: ring sdma1 uses VM inv eng 4 on hub 1 [ 6.384090] amdgpu 0000:0a:00.0: ring page1 uses VM inv eng 5 on hub 1 [ 6.384090] amdgpu 0000:0a:00.0: ring uvd_0 uses VM inv eng 6 on hub 1 [ 6.384091] amdgpu 0000:0a:00.0: ring uvd_enc_0.0 uses VM inv eng 7 on hub 1 [ 6.384092] amdgpu 0000:0a:00.0: ring uvd_enc_0.1 uses VM inv eng 8 on hub 1 [ 6.384092] amdgpu 0000:0a:00.0: ring uvd_1 uses VM inv eng 9 on hub 1 [ 6.384093] amdgpu 0000:0a:00.0: ring uvd_enc_1.0 uses VM inv eng 10 on hub 1 [ 6.384094] amdgpu 0000:0a:00.0: ring uvd_enc_1.1 uses VM inv eng 11 on hub 1 [ 6.384094] amdgpu 0000:0a:00.0: ring vce0 uses VM inv eng 12 on hub 1 [ 6.384095] amdgpu 0000:0a:00.0: ring vce1 uses VM inv eng 13 on hub 1 [ 6.384096] amdgpu 0000:0a:00.0: ring vce2 uses VM inv eng 14 on hub 1 [ 7.067068] [drm] Initialized amdgpu 3.27.0 20150101 for 0000:0a:00.0 on minor 0 -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019