From: Daniel Vetter <daniel@ffwll.ch>
To: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: daniel.vetter@ffwll.ch, michel@daenzer.net,
dri-devel@lists.freedesktop.org, ppaalanen@gmail.com,
amd-gfx@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
ckoenig.leichtzumerken@gmail.com, alexdeucher@gmail.com
Subject: Re: [PATCH v2 2/8] drm/ttm: Remap all page faults to per process dummy page.
Date: Wed, 24 Jun 2020 09:19:42 +0200 [thread overview]
Message-ID: <20200624071942.GS20149@phenom.ffwll.local> (raw)
In-Reply-To: <63be2315-b123-0d8f-729f-9ae47fb2138b@amd.com>
On Tue, Jun 23, 2020 at 11:31:45PM -0400, Andrey Grodzovsky wrote:
>
> On 6/22/20 5:41 AM, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 02:03:02AM -0400, Andrey Grodzovsky wrote:
> > > On device removal reroute all CPU mappings to dummy page per drm_file
> > > instance or imported GEM object.
> > >
> > > Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > > ---
> > > drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 ++++++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 57 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > index 389128b..2f8bf5e 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > @@ -35,6 +35,8 @@
> > > #include <drm/ttm/ttm_bo_driver.h>
> > > #include <drm/ttm/ttm_placement.h>
> > > #include <drm/drm_vma_manager.h>
> > > +#include <drm/drm_drv.h>
> > > +#include <drm/drm_file.h>
> > > #include <linux/mm.h>
> > > #include <linux/pfn_t.h>
> > > #include <linux/rbtree.h>
> > > @@ -328,19 +330,66 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> > Hm I think diff and code flow look a bit bad now. What about renaming the
> > current function to __ttm_bo_vm_fault and then having something like the
> > below:
> >
> > ttm_bo_vm_fault(args) {
> >
> > if (drm_dev_enter()) {
> > __ttm_bo_vm_fault(args);
> > drm_dev_exit();
> > } else {
> > drm_gem_insert_dummy_pfn();
> > }
> > }
> >
> > I think drm_gem_insert_dummy_pfn(); should be portable across drivers, so
> > another nice point to try to unifiy drivers as much as possible.
> > -Daniel
> >
> > > pgprot_t prot;
> > > struct ttm_buffer_object *bo = vma->vm_private_data;
> > > vm_fault_t ret;
> > > + int idx;
> > > + struct drm_device *ddev = bo->base.dev;
> > > - ret = ttm_bo_vm_reserve(bo, vmf);
> > > - if (ret)
> > > - return ret;
> > > + if (drm_dev_enter(ddev, &idx)) {
> > > + ret = ttm_bo_vm_reserve(bo, vmf);
> > > + if (ret)
> > > + goto exit;
> > > +
> > > + prot = vma->vm_page_prot;
> > > - prot = vma->vm_page_prot;
> > > - ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
> > > - if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> > > + ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
> > > + if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> > > + goto exit;
> > > +
> > > + dma_resv_unlock(bo->base.resv);
> > > +
> > > +exit:
> > > + drm_dev_exit(idx);
> > > return ret;
> > > + } else {
> > > - dma_resv_unlock(bo->base.resv);
> > > + struct drm_file *file = NULL;
> > > + struct page *dummy_page = NULL;
> > > + int handle;
> > > - return ret;
> > > + /* We are faulting on imported BO from dma_buf */
> > > + if (bo->base.dma_buf && bo->base.import_attach) {
> > > + dummy_page = bo->base.dummy_page;
> > > + /* We are faulting on non imported BO, find drm_file owning the BO*/
> > Uh, we can't fish that out of the vma->vm_file pointer somehow? Or is that
> > one all wrong? Doing this kind of list walk looks pretty horrible.
> >
> > If the vma doesn't have the right pointer I guess next option is that we
> > store the drm_file page in gem_bo->dummy_page, and replace it on first
> > export. But that's going to be tricky to track ...
> >
> > > + } else {
> > > + struct drm_gem_object *gobj;
> > > +
> > > + mutex_lock(&ddev->filelist_mutex);
> > > + list_for_each_entry(file, &ddev->filelist, lhead) {
> > > + spin_lock(&file->table_lock);
> > > + idr_for_each_entry(&file->object_idr, gobj, handle) {
> > > + if (gobj == &bo->base) {
> > > + dummy_page = file->dummy_page;
> > > + break;
> > > + }
> > > + }
> > > + spin_unlock(&file->table_lock);
> > > + }
> > > + mutex_unlock(&ddev->filelist_mutex);
> > > + }
> > > +
> > > + if (dummy_page) {
> > > + /*
> > > + * Let do_fault complete the PTE install e.t.c using vmf->page
> > > + *
> > > + * TODO - should i call free_page somewhere ?
> > Nah, instead don't call get_page. The page will be around as long as
> > there's a reference for the drm_file or gem_bo, which is longer than any
> > mmap. Otherwise yes this would like really badly.
>
>
> So actually that was my thinking in the first place and I indeed avoided
> taking reference and this ended up
> with multiple BUG_ONs as seen bellow where refcount:-63 mapcount:-48 for a
> page are deep into negative
> values... Those warnings were gone once i added get_page(dummy) which in my
> opinion implies that there
> is a page reference per each PTE and that when there is unmapping of the
> process address
> space and PTEs are deleted there is also put_page somewhere in mm core and
> the get_page per mapping
> keeps it balanced.
>
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762929] BUG: Bad page map in
> process glxgear:disk$0 pte:8000000132284867 pmd:15aaec067
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762931]
> page:ffffe63384c8a100 refcount:-63 mapcount:-48 mapping:0000000000000000
> index:0x0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762932] flags:
> 0x17fff8000000008(dirty)
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762933] raw:
> 017fff8000000008 dead000000000100 dead000000000122 0000000000000000
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762934] raw:
> 0000000000000000 0000000000000000 ffffffc1ffffffcf 0000000000000000
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762935] page dumped because: bad pte
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762937]
> addr:00007fe086263000 vm_flags:1c0440fb anon_vma:0000000000000000
> mapping:ffff9b5cd42db268 index:1008b3
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762981] file:renderD129
> fault:ttm_bo_vm_fault [ttm] mmap:amdgpu_mmap [amdgpu] readpage:0x0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762984] CPU: 5 PID: 2619
> Comm: glxgear:disk$0 Tainted: G B OE 5.6.0-dev+ #51
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762985] Hardware name:
> System manufacturer System Product Name/RAMPAGE IV FORMULA, BIOS 4804
> 12/30/2013
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762985] Call Trace:
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762988] dump_stack+0x68/0x9b
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762990] print_bad_pte+0x19f/0x270
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762992] ? lock_page_memcg+0x5/0xf0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762995] unmap_page_range+0x777/0xbe0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763000] unmap_vmas+0xcc/0x160
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763004] exit_mmap+0xb5/0x1b0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763009] mmput+0x65/0x140
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763010] do_exit+0x362/0xc40
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763013] do_group_exit+0x47/0xb0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763016] get_signal+0x18b/0xc30
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763019] do_signal+0x36/0x6a0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763021] ?
> __set_task_comm+0x62/0x120
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763024] ?
> __x64_sys_futex+0x88/0x180
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763028]
> exit_to_usermode_loop+0x6f/0xc0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763030] do_syscall_64+0x149/0x1c0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763032]
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763034] RIP: 0033:0x7fe091bd9360
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763037] Code: Bad RIP value.
Uh, I guess that just shows how little I understand how this all works.
But yeah if we set vmf->page then I guess core mm takes care of
everything, but apparently expects a page reference.
-Daniel
> Andrey
>
>
> >
> > > + */
> > > + get_page(dummy_page);
> > > + vmf->page = dummy_page;
> > > + return 0;
> > > + } else {
> > > + return VM_FAULT_SIGSEGV;
> > Hm that would be a kernel bug, wouldn't it? WARN_ON() required here imo.
> > -Daniel
> >
> > > + }
> > > + }
> > > }
> > > EXPORT_SYMBOL(ttm_bo_vm_fault);
> > > --
> > > 2.7.4
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: daniel.vetter@ffwll.ch, michel@daenzer.net,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
ckoenig.leichtzumerken@gmail.com
Subject: Re: [PATCH v2 2/8] drm/ttm: Remap all page faults to per process dummy page.
Date: Wed, 24 Jun 2020 09:19:42 +0200 [thread overview]
Message-ID: <20200624071942.GS20149@phenom.ffwll.local> (raw)
In-Reply-To: <63be2315-b123-0d8f-729f-9ae47fb2138b@amd.com>
On Tue, Jun 23, 2020 at 11:31:45PM -0400, Andrey Grodzovsky wrote:
>
> On 6/22/20 5:41 AM, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 02:03:02AM -0400, Andrey Grodzovsky wrote:
> > > On device removal reroute all CPU mappings to dummy page per drm_file
> > > instance or imported GEM object.
> > >
> > > Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > > ---
> > > drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 ++++++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 57 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > index 389128b..2f8bf5e 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > @@ -35,6 +35,8 @@
> > > #include <drm/ttm/ttm_bo_driver.h>
> > > #include <drm/ttm/ttm_placement.h>
> > > #include <drm/drm_vma_manager.h>
> > > +#include <drm/drm_drv.h>
> > > +#include <drm/drm_file.h>
> > > #include <linux/mm.h>
> > > #include <linux/pfn_t.h>
> > > #include <linux/rbtree.h>
> > > @@ -328,19 +330,66 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> > Hm I think diff and code flow look a bit bad now. What about renaming the
> > current function to __ttm_bo_vm_fault and then having something like the
> > below:
> >
> > ttm_bo_vm_fault(args) {
> >
> > if (drm_dev_enter()) {
> > __ttm_bo_vm_fault(args);
> > drm_dev_exit();
> > } else {
> > drm_gem_insert_dummy_pfn();
> > }
> > }
> >
> > I think drm_gem_insert_dummy_pfn(); should be portable across drivers, so
> > another nice point to try to unifiy drivers as much as possible.
> > -Daniel
> >
> > > pgprot_t prot;
> > > struct ttm_buffer_object *bo = vma->vm_private_data;
> > > vm_fault_t ret;
> > > + int idx;
> > > + struct drm_device *ddev = bo->base.dev;
> > > - ret = ttm_bo_vm_reserve(bo, vmf);
> > > - if (ret)
> > > - return ret;
> > > + if (drm_dev_enter(ddev, &idx)) {
> > > + ret = ttm_bo_vm_reserve(bo, vmf);
> > > + if (ret)
> > > + goto exit;
> > > +
> > > + prot = vma->vm_page_prot;
> > > - prot = vma->vm_page_prot;
> > > - ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
> > > - if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> > > + ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
> > > + if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> > > + goto exit;
> > > +
> > > + dma_resv_unlock(bo->base.resv);
> > > +
> > > +exit:
> > > + drm_dev_exit(idx);
> > > return ret;
> > > + } else {
> > > - dma_resv_unlock(bo->base.resv);
> > > + struct drm_file *file = NULL;
> > > + struct page *dummy_page = NULL;
> > > + int handle;
> > > - return ret;
> > > + /* We are faulting on imported BO from dma_buf */
> > > + if (bo->base.dma_buf && bo->base.import_attach) {
> > > + dummy_page = bo->base.dummy_page;
> > > + /* We are faulting on non imported BO, find drm_file owning the BO*/
> > Uh, we can't fish that out of the vma->vm_file pointer somehow? Or is that
> > one all wrong? Doing this kind of list walk looks pretty horrible.
> >
> > If the vma doesn't have the right pointer I guess next option is that we
> > store the drm_file page in gem_bo->dummy_page, and replace it on first
> > export. But that's going to be tricky to track ...
> >
> > > + } else {
> > > + struct drm_gem_object *gobj;
> > > +
> > > + mutex_lock(&ddev->filelist_mutex);
> > > + list_for_each_entry(file, &ddev->filelist, lhead) {
> > > + spin_lock(&file->table_lock);
> > > + idr_for_each_entry(&file->object_idr, gobj, handle) {
> > > + if (gobj == &bo->base) {
> > > + dummy_page = file->dummy_page;
> > > + break;
> > > + }
> > > + }
> > > + spin_unlock(&file->table_lock);
> > > + }
> > > + mutex_unlock(&ddev->filelist_mutex);
> > > + }
> > > +
> > > + if (dummy_page) {
> > > + /*
> > > + * Let do_fault complete the PTE install e.t.c using vmf->page
> > > + *
> > > + * TODO - should i call free_page somewhere ?
> > Nah, instead don't call get_page. The page will be around as long as
> > there's a reference for the drm_file or gem_bo, which is longer than any
> > mmap. Otherwise yes this would like really badly.
>
>
> So actually that was my thinking in the first place and I indeed avoided
> taking reference and this ended up
> with multiple BUG_ONs as seen bellow where refcount:-63 mapcount:-48 for a
> page are deep into negative
> values... Those warnings were gone once i added get_page(dummy) which in my
> opinion implies that there
> is a page reference per each PTE and that when there is unmapping of the
> process address
> space and PTEs are deleted there is also put_page somewhere in mm core and
> the get_page per mapping
> keeps it balanced.
>
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762929] BUG: Bad page map in
> process glxgear:disk$0 pte:8000000132284867 pmd:15aaec067
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762931]
> page:ffffe63384c8a100 refcount:-63 mapcount:-48 mapping:0000000000000000
> index:0x0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762932] flags:
> 0x17fff8000000008(dirty)
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762933] raw:
> 017fff8000000008 dead000000000100 dead000000000122 0000000000000000
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762934] raw:
> 0000000000000000 0000000000000000 ffffffc1ffffffcf 0000000000000000
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762935] page dumped because: bad pte
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762937]
> addr:00007fe086263000 vm_flags:1c0440fb anon_vma:0000000000000000
> mapping:ffff9b5cd42db268 index:1008b3
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762981] file:renderD129
> fault:ttm_bo_vm_fault [ttm] mmap:amdgpu_mmap [amdgpu] readpage:0x0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762984] CPU: 5 PID: 2619
> Comm: glxgear:disk$0 Tainted: G B OE 5.6.0-dev+ #51
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762985] Hardware name:
> System manufacturer System Product Name/RAMPAGE IV FORMULA, BIOS 4804
> 12/30/2013
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762985] Call Trace:
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762988] dump_stack+0x68/0x9b
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762990] print_bad_pte+0x19f/0x270
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762992] ? lock_page_memcg+0x5/0xf0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.762995] unmap_page_range+0x777/0xbe0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763000] unmap_vmas+0xcc/0x160
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763004] exit_mmap+0xb5/0x1b0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763009] mmput+0x65/0x140
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763010] do_exit+0x362/0xc40
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763013] do_group_exit+0x47/0xb0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763016] get_signal+0x18b/0xc30
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763019] do_signal+0x36/0x6a0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763021] ?
> __set_task_comm+0x62/0x120
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763024] ?
> __x64_sys_futex+0x88/0x180
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763028]
> exit_to_usermode_loop+0x6f/0xc0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763030] do_syscall_64+0x149/0x1c0
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763032]
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763034] RIP: 0033:0x7fe091bd9360
> Jun 20 01:36:43 ubuntu-1604-test kernel: [ 98.763037] Code: Bad RIP value.
Uh, I guess that just shows how little I understand how this all works.
But yeah if we set vmf->page then I guess core mm takes care of
everything, but apparently expects a page reference.
-Daniel
> Andrey
>
>
> >
> > > + */
> > > + get_page(dummy_page);
> > > + vmf->page = dummy_page;
> > > + return 0;
> > > + } else {
> > > + return VM_FAULT_SIGSEGV;
> > Hm that would be a kernel bug, wouldn't it? WARN_ON() required here imo.
> > -Daniel
> >
> > > + }
> > > + }
> > > }
> > > EXPORT_SYMBOL(ttm_bo_vm_fault);
> > > --
> > > 2.7.4
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-06-24 7:19 UTC|newest]
Thread overview: 194+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-21 6:03 [PATCH v2 0/8] RFC Support hot device unplug in amdgpu Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-21 6:03 ` [PATCH v2 1/8] drm: Add dummy page per device or GEM object Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:35 ` Daniel Vetter
2020-06-22 9:35 ` Daniel Vetter
2020-06-22 14:21 ` Pekka Paalanen
2020-06-22 14:21 ` Pekka Paalanen
2020-06-22 14:24 ` Daniel Vetter
2020-06-22 14:24 ` Daniel Vetter
2020-06-22 14:28 ` Pekka Paalanen
2020-06-22 14:28 ` Pekka Paalanen
2020-11-09 20:34 ` Andrey Grodzovsky
2020-11-09 20:34 ` Andrey Grodzovsky
2020-11-15 6:39 ` Andrey Grodzovsky
2020-11-15 6:39 ` Andrey Grodzovsky
2020-06-22 13:18 ` Christian König
2020-06-22 13:18 ` Christian König
2020-06-22 14:23 ` Daniel Vetter
2020-06-22 14:23 ` Daniel Vetter
2020-06-22 14:32 ` Andrey Grodzovsky
2020-06-22 14:32 ` Andrey Grodzovsky
2020-06-22 17:45 ` Christian König
2020-06-22 17:45 ` Christian König
2020-06-22 17:50 ` Daniel Vetter
2020-06-22 17:50 ` Daniel Vetter
2020-11-09 20:53 ` Andrey Grodzovsky
2020-11-09 20:53 ` Andrey Grodzovsky
2020-11-13 20:52 ` Andrey Grodzovsky
2020-11-13 20:52 ` Andrey Grodzovsky
2020-11-14 8:41 ` Christian König
2020-11-14 8:41 ` Christian König
2020-11-14 9:51 ` Daniel Vetter
2020-11-14 9:51 ` Daniel Vetter
2020-11-14 9:57 ` Daniel Vetter
2020-11-14 9:57 ` Daniel Vetter
2020-11-16 9:42 ` Michel Dänzer
2020-11-16 9:42 ` Michel Dänzer
2020-11-15 6:34 ` Andrey Grodzovsky
2020-11-15 6:34 ` Andrey Grodzovsky
2020-11-16 9:48 ` Christian König
2020-11-16 9:48 ` Christian König
2020-11-16 19:00 ` Andrey Grodzovsky
2020-11-16 19:00 ` Andrey Grodzovsky
2020-11-16 20:36 ` Christian König
2020-11-16 20:36 ` Christian König
2020-11-16 20:42 ` Andrey Grodzovsky
2020-11-16 20:42 ` Andrey Grodzovsky
2020-11-19 10:01 ` Christian König
2020-11-19 10:01 ` Christian König
2020-06-21 6:03 ` [PATCH v2 2/8] drm/ttm: Remap all page faults to per process dummy page Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:41 ` Daniel Vetter
2020-06-22 9:41 ` Daniel Vetter
2020-06-24 3:31 ` Andrey Grodzovsky
2020-06-24 3:31 ` Andrey Grodzovsky
2020-06-24 7:19 ` Daniel Vetter [this message]
2020-06-24 7:19 ` Daniel Vetter
2020-11-10 17:41 ` Andrey Grodzovsky
2020-11-10 17:41 ` Andrey Grodzovsky
2020-06-22 19:30 ` Christian König
2020-06-22 19:30 ` Christian König
2020-06-21 6:03 ` [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:45 ` Daniel Vetter
2020-06-22 9:45 ` Daniel Vetter
2020-06-23 5:00 ` Andrey Grodzovsky
2020-06-23 5:00 ` Andrey Grodzovsky
2020-06-23 10:25 ` Daniel Vetter
2020-06-23 10:25 ` Daniel Vetter
2020-06-23 12:55 ` Christian König
2020-06-23 12:55 ` Christian König
2020-06-22 19:37 ` Christian König
2020-06-22 19:37 ` Christian König
2020-06-22 19:47 ` Alex Deucher
2020-06-22 19:47 ` Alex Deucher
2020-06-21 6:03 ` [PATCH v2 4/8] drm/amdgpu: Split amdgpu_device_fini into early and late Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:48 ` Daniel Vetter
2020-06-22 9:48 ` Daniel Vetter
2020-11-12 4:19 ` Andrey Grodzovsky
2020-11-12 4:19 ` Andrey Grodzovsky
2020-11-12 9:29 ` Daniel Vetter
2020-11-12 9:29 ` Daniel Vetter
2020-06-21 6:03 ` [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:51 ` Daniel Vetter
2020-06-22 9:51 ` Daniel Vetter
2020-06-22 11:21 ` Greg KH
2020-06-22 11:21 ` Greg KH
2020-06-22 16:07 ` Andrey Grodzovsky
2020-06-22 16:07 ` Andrey Grodzovsky
2020-06-22 16:45 ` Greg KH
2020-06-22 16:45 ` Greg KH
2020-06-23 4:51 ` Andrey Grodzovsky
2020-06-23 4:51 ` Andrey Grodzovsky
2020-06-23 6:05 ` Greg KH
2020-06-23 6:05 ` Greg KH
2020-06-24 3:04 ` Andrey Grodzovsky
2020-06-24 3:04 ` Andrey Grodzovsky
2020-06-24 6:11 ` Greg KH
2020-06-24 6:11 ` Greg KH
2020-06-25 1:52 ` Andrey Grodzovsky
2020-06-25 1:52 ` Andrey Grodzovsky
2020-11-10 17:54 ` Andrey Grodzovsky
2020-11-10 17:54 ` Andrey Grodzovsky
2020-11-10 17:59 ` Greg KH
2020-11-10 17:59 ` Greg KH
2020-11-11 15:13 ` Andrey Grodzovsky
2020-11-11 15:13 ` Andrey Grodzovsky
2020-11-11 15:34 ` Greg KH
2020-11-11 15:34 ` Greg KH
2020-11-11 15:45 ` Andrey Grodzovsky
2020-11-11 15:45 ` Andrey Grodzovsky
2020-11-11 16:06 ` Greg KH
2020-11-11 16:06 ` Greg KH
2020-11-11 16:34 ` Andrey Grodzovsky
2020-11-11 16:34 ` Andrey Grodzovsky
2020-12-02 15:48 ` Andrey Grodzovsky
2020-12-02 15:48 ` Andrey Grodzovsky
2020-12-02 17:34 ` Greg KH
2020-12-02 17:34 ` Greg KH
2020-12-02 18:02 ` Andrey Grodzovsky
2020-12-02 18:02 ` Andrey Grodzovsky
2020-12-02 18:20 ` Greg KH
2020-12-02 18:20 ` Greg KH
2020-12-02 18:40 ` Andrey Grodzovsky
2020-12-02 18:40 ` Andrey Grodzovsky
2020-06-22 13:19 ` Christian König
2020-06-22 13:19 ` Christian König
2020-06-21 6:03 ` [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:56 ` Daniel Vetter
2020-06-22 9:56 ` Daniel Vetter
2020-06-22 19:38 ` Christian König
2020-06-22 19:38 ` Christian König
2020-06-22 19:48 ` Alex Deucher
2020-06-22 19:48 ` Alex Deucher
2020-06-23 10:22 ` Daniel Vetter
2020-06-23 10:22 ` Daniel Vetter
2020-06-23 13:16 ` Christian König
2020-06-23 13:16 ` Christian König
2020-06-24 3:12 ` Andrey Grodzovsky
2020-06-24 3:12 ` Andrey Grodzovsky
2020-06-21 6:03 ` [PATCH v2 7/8] drm/amdgpu: Fix sdma code crash post device unplug Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:55 ` Daniel Vetter
2020-06-22 9:55 ` Daniel Vetter
2020-06-22 19:40 ` Christian König
2020-06-22 19:40 ` Christian König
2020-06-23 5:11 ` Andrey Grodzovsky
2020-06-23 5:11 ` Andrey Grodzovsky
2020-06-23 7:14 ` Christian König
2020-06-23 7:14 ` Christian König
2020-06-21 6:03 ` [PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged Andrey Grodzovsky
2020-06-21 6:03 ` Andrey Grodzovsky
2020-06-22 9:53 ` Daniel Vetter
2020-06-22 9:53 ` Daniel Vetter
2020-11-17 18:38 ` Andrey Grodzovsky
2020-11-17 18:38 ` Andrey Grodzovsky
2020-11-17 18:52 ` Daniel Vetter
2020-11-17 18:52 ` Daniel Vetter
2020-11-17 19:18 ` Andrey Grodzovsky
2020-11-17 19:18 ` Andrey Grodzovsky
2020-11-17 19:49 ` Daniel Vetter
2020-11-17 19:49 ` Daniel Vetter
2020-11-17 20:07 ` Andrey Grodzovsky
2020-11-17 20:07 ` Andrey Grodzovsky
2020-11-18 7:39 ` Daniel Vetter
2020-11-18 7:39 ` Daniel Vetter
2020-11-18 12:01 ` Christian König
2020-11-18 12:01 ` Christian König
2020-11-18 15:43 ` Luben Tuikov
2020-11-18 15:43 ` Luben Tuikov
2020-11-18 16:20 ` Andrey Grodzovsky
2020-11-18 16:20 ` Andrey Grodzovsky
2020-11-19 7:55 ` Christian König
2020-11-19 7:55 ` Christian König
2020-11-19 15:02 ` Andrey Grodzovsky
2020-11-19 15:02 ` Andrey Grodzovsky
2020-11-19 15:29 ` Daniel Vetter
2020-11-19 15:29 ` Daniel Vetter
2020-11-19 21:24 ` Andrey Grodzovsky
2020-11-19 21:24 ` Andrey Grodzovsky
2020-11-18 0:46 ` Luben Tuikov
2020-11-18 0:46 ` Luben Tuikov
2020-06-22 9:46 ` [PATCH v2 0/8] RFC Support hot device unplug in amdgpu Daniel Vetter
2020-06-22 9:46 ` Daniel Vetter
2020-06-23 5:14 ` Andrey Grodzovsky
2020-06-23 5:14 ` Andrey Grodzovsky
2020-06-23 9:04 ` Michel Dänzer
2020-06-23 9:04 ` Michel Dänzer
2020-06-24 3:21 ` Andrey Grodzovsky
2020-06-24 3:21 ` Andrey Grodzovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200624071942.GS20149@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Andrey.Grodzovsky@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel@daenzer.net \
--cc=ppaalanen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.