| Message ID | 1416402089-2366-11-git-send-email-deathsimple@vodafone.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dear Christian, Christian König wrote on 19.11.2014 14:01: > From: Christian König <christian.koenig@amd.com> > > This way the necessary VM update is kicked off immediately > if all BOs involved are in GPU accessible memory. > > v2: fix vm lock > v3: immediately update unmaps as well > > Signed-off-by: Christian König <christian.koenig@amd.com> > --- > drivers/gpu/drm/radeon/radeon_gem.c | 64 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 64 insertions(+) Is this a fix for <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> which I bisected to the v2 of this patch (<http://thread.gmane.org/gmane.comp.video.dri.devel/118415/focus=118425>) as present on the drm-next-3.19-wip branch? Cheers, Kai
Am 19.11.2014 um 14:16 schrieb Kai Wasserbäch: > Dear Christian, > Christian König wrote on 19.11.2014 14:01: >> From: Christian König <christian.koenig@amd.com> >> >> This way the necessary VM update is kicked off immediately >> if all BOs involved are in GPU accessible memory. >> >> v2: fix vm lock >> v3: immediately update unmaps as well >> >> Signed-off-by: Christian König <christian.koenig@amd.com> >> --- >> drivers/gpu/drm/radeon/radeon_gem.c | 64 +++++++++++++++++++++++++++++++++++++ >> 1 file changed, 64 insertions(+) > Is this a fix for <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> > which I bisected to the v2 of this patch > (<http://thread.gmane.org/gmane.comp.video.dri.devel/118415/focus=118425>) as > present on the drm-next-3.19-wip branch? Yes and no, it was actually the patch before this one which triggered the problem. The last one just made it much more likely to appear. Please test the whole patchset on top of Dave's drm-next tree if your problem still exists. Thanks, Christian. > > Cheers, > Kai >
Dear Christian, Christian König wrote on 19.11.2014 14:35: > Am 19.11.2014 um 14:16 schrieb Kai Wasserbäch: >> Dear Christian, >> Christian König wrote on 19.11.2014 14:01: >>> From: Christian König <christian.koenig@amd.com> >>> >>> This way the necessary VM update is kicked off immediately >>> if all BOs involved are in GPU accessible memory. >>> >>> v2: fix vm lock >>> v3: immediately update unmaps as well >>> >>> Signed-off-by: Christian König <christian.koenig@amd.com> >>> --- >>> drivers/gpu/drm/radeon/radeon_gem.c | 64 +++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 64 insertions(+) >> Is this a fix for <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> >> which I bisected to the v2 of this patch >> (<http://thread.gmane.org/gmane.comp.video.dri.devel/118415/focus=118425>) as >> present on the drm-next-3.19-wip branch? > > Yes and no, it was actually the patch before this one which triggered the > problem. The last one just made it much more likely to appear. > > Please test the whole patchset on top of Dave's drm-next tree if your problem > still exists. this is still bad: [ 117.818981] BUG: unable to handle kernel paging request at ffffeae3801564d8 [ 117.819019] IP: [<ffffffff8111e6b1>] virt_to_head_page+0x33/0x4a [ 117.819049] PGD 0 [ 117.819059] Oops: 0000 [#1] SMP [ 117.819077] Modules linked in: serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic blowfish_x86_64 blowfish_common ecb cmac sha512_ssse3 sha512_generic sha256_ssse3 sha256_generic nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc nls_utf8 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support radeon snd_hda_intel x86_pkg_temp_thermal snd_hda_controller drm_kms_helper ttm snd_hda_codec snd_hwdep snd_pcm_oss mei_me video snd_mixer_oss i2c_i801 coretemp snd_pcm mei lpc_ich mfd_core evdev joydev processor snd_timer snd soundcore button serio_raw kvm_intel kvm pcspkr efivars fuse parport_pc ppdev lp parport ext4 crc16 mbcache jbd2 btrfs xor raid6_pq twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common [ 117.819454] xts af_alg hid_generic usbhid dm_crypt dm_mod microcode hid_lg_g710_plus(O) hid sg sr_mod sd_mod cdrom crct10dif_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci libata atl1c thermal fan thermal_sys [ 117.819587] CPU: 1 PID: 1959 Comm: Dreamfall Chapt Tainted: G O 3.18.0-rc4-citadel-airlied-drm-next-with-ck-patches.0.1 #1 [ 117.819634] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77-DS3H, BIOS F11a 11/13/2013 [ 117.819673] task: ffff8800d4417650 ti: ffff8800d21a0000 task.ti: ffff8800d21a0000 [ 117.819702] RIP: 0010:[<ffffffff8111e6b1>] [<ffffffff8111e6b1>] virt_to_head_page+0x33/0x4a [ 117.819737] RSP: 0018:ffff8800d21a3cf0 EFLAGS: 00010086 [ 117.819758] RAX: ffffeae3801564d8 RBX: 0000000000000286 RCX: 000077ff80000000 [ 117.819787] RDX: ffffea0000000000 RSI: ffff8800d21a3d30 RDI: ffffc900061cd000 [ 117.819815] RBP: ffffc900061cd000 R08: 0000000000000000 R09: ffff880407859008 [ 117.819843] R10: ffff880407858fe0 R11: 000000000007ffff R12: ffffffffa0602de8 [ 117.819870] R13: ffff880407858000 R14: ffff88039f261ac0 R15: ffff880403d876c0 [ 117.819898] FS: 00007f10c309b780(0000) GS:ffff88041ec40000(0000) knlGS:0000000000000000 [ 117.819930] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 117.819952] CR2: ffffeae3801564d8 CR3: 00000000dcad1000 CR4: 00000000001407e0 [ 117.819979] Stack: [ 117.819988] ffffffff8111eda1 ffff8800d21a3de0 0000000000000000 ffff8800d21a3d30 [ 117.820022] ffffffffa0602de8 ffffc900061cd000 00000000a060245a 0000000000000000 [ 117.820055] ffffc900061ce0a8 ffff8800d21a3d58 ffff8800d4417650 0000000000001e7d [ 117.820089] Call Trace: [ 117.820101] [<ffffffff8111eda1>] ? kfree+0x2e/0x6d [ 117.820137] [<ffffffffa0602de8>] ? radeon_gem_va_ioctl+0x28c/0x2d3 [radeon] [ 117.820176] [<ffffffffa0602601>] ? radeon_gem_create_ioctl+0xa4/0xc3 [radeon] [ 117.820207] [<ffffffff812be431>] ? drm_ioctl+0x35b/0x3e1 [ 117.820238] [<ffffffffa0602b5c>] ? radeon_gem_get_tiling_ioctl+0x8e/0x8e [radeon] [ 117.820270] [<ffffffff81440f2c>] ? _raw_spin_unlock_irqrestore+0xc/0xd [ 117.820303] [<ffffffffa05de04b>] ? radeon_drm_ioctl+0x4b/0x7a [radeon] [ 117.820331] [<ffffffff8113e795>] ? do_vfs_ioctl+0x34e/0x404 [ 117.820355] [<ffffffff811312a4>] ? vfs_read+0xbc/0xea [ 117.820377] [<ffffffff8113e89c>] ? SyS_ioctl+0x51/0x77 [ 117.820398] [<ffffffff814414e9>] ? system_call_fastpath+0x12/0x17 [ 117.820423] Code: 00 00 80 ff 77 00 00 48 01 fa 48 0f 42 0d 78 99 6f 00 48 8d 04 11 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 6b c0 38 48 01 d0 <48> 8b 10 80 e6 80 74 0e 48 8b 50 30 48 8b 08 80 e5 80 48 0f 45 [ 117.820582] RIP [<ffffffff8111e6b1>] virt_to_head_page+0x33/0x4a [ 117.820608] RSP <ffff8800d21a3cf0> [ 117.820622] CR2: ffffeae3801564d8 [ 117.838461] ---[ end trace a6e2a6aa1df3196f ]--- I've used Dave Airlie's drm-next as a base (commit d0d6c524bf1d72e6d64134c3a315b77deecc9252) and "git am"-applied your series (no issues, applied cleanly) on top. Steam games are still entering the defunct state as soon as the 3D engines are fired up on a kernel built from that source tree. This is with (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/b69c7c5dac libdrm: Git:master/00847fa48b LLVM: SVN:trunk/r222254 (3.6 devel) X.Org: 2:1.16.1-1 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> # 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin # c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin # 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin # c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin # 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin # ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin # 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin # 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin libclc: Git:master/7f6f5bff1f DDX: 1:7.5.0-1 Let me know, if you need something else; see also the original thread <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further information. Cheers, Kai
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index f752c7f..2e0e370 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -518,6 +518,68 @@ out: return r; } +/** + * radeon_gem_va_update_vm -update the bo_va in its VM + * + * @rdev: radeon_device pointer + * @bo_va: bo_va to update + * + * Update the bo_va directly after setting it's address. Errors are not + * vital here, so they are not reported back to userspace. + */ +static void radeon_gem_va_update_vm(struct radeon_device *rdev, + struct radeon_bo_va *bo_va) +{ + struct ttm_validate_buffer tv, *entry; + struct radeon_cs_reloc *vm_bos; + struct ww_acquire_ctx ticket; + struct list_head list; + unsigned domain; + int r; + + INIT_LIST_HEAD(&list); + + tv.bo = &bo_va->bo->tbo; + tv.shared = true; + list_add(&tv.head, &list); + + vm_bos = radeon_vm_get_bos(rdev, bo_va->vm, &list); + if (!vm_bos) + return; + + r = ttm_eu_reserve_buffers(&ticket, &list, true); + if (r) + goto error_free; + + list_for_each_entry(entry, &list, head) { + domain = radeon_mem_type_to_domain(entry->bo->mem.mem_type); + /* if anything is swapped out don't swap it in here, + just abort and wait for the next CS */ + if (domain == RADEON_GEM_DOMAIN_CPU) + goto error_unreserve; + } + + mutex_lock(&bo_va->vm->mutex); + r = radeon_vm_clear_freed(rdev, bo_va->vm); + if (r) + goto error_unlock; + + if (bo_va->it.start) + r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); + +error_unlock: + mutex_unlock(&bo_va->vm->mutex); + +error_unreserve: + ttm_eu_backoff_reservation(&ticket, &list); + +error_free: + kfree(vm_bos); + + if (r) + DRM_ERROR("Couldn't update BO_VA (%d)\n", r); +} + int radeon_gem_va_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) { @@ -612,6 +674,8 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data, default: break; } + if (!r) + radeon_gem_va_update_vm(rdev, bo_va); args->operation = RADEON_VA_RESULT_OK; if (r) { args->operation = RADEON_VA_RESULT_ERROR;