| Message ID | 546CC2B8.6020300@vodafone.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Yes, that seems to fix the problem! You can have my Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org> Thanks, Kai Christian König wrote on 19.11.2014 17:18: > Ah! Yes of course, we have changed we way memory is allocated for the BO list in > the meantime. > > Does it work if you replace the last patch in the list with the attached one? > > Thanks for pointing this out, > Christian. > > Am 19.11.2014 um 16:43 schrieb Kai Wasserbäch: >> 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 >> >
From 845c26dbe3ace8d3f593f9e8ccd5e53373c50627 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com> Date: Fri, 12 Sep 2014 12:25:45 +0200 Subject: [PATCH] drm/radeon: update the VM after setting BO address v4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 v4: use drm_free_large instead of kfree Signed-off-by: Christian König <christian.koenig@amd.com> --- drivers/gpu/drm/radeon/radeon_gem.c | 64 +++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index f752c7f..a748a64 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: + drm_free_large(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; -- 1.9.1