search for: nouveau_bo_move_ntfi

move_notify is called by ttm after the the object is idle and about to be destroyed. Clean up the vm list properly in that case. This is not a problem right now, since the list should already be empty, but if it wasn't empty, vm_put was not called which leads to random corruption later. With this fix, nouveau_gem_object_close can be safely changed to a noop, forcing the vm bindings to be

nv50_bo_move_m2mf might copy to tiled gart, in which case linear copy is not appropriate. --- drivers/gpu/drm/nouveau/nouveau_bo.c | 42 ++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 88f0c45..0daf3f0 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++

https://bugs.freedesktop.org/show_bug.cgi?id=103689 Bug ID: 103689 Summary: there is an exploitable page fault that can be reliably triggered from the chromium sandbox can possibly lead to remote attackers causing a denial of service condition or possibly running system code. Product: xorg

On 2/18/20 1:44 PM, Christian K?nig wrote: > Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >> Hi >> >> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>> GPU address handling is device specific and should be handle by its >>> device >>> driver. >>> >>> Signed-off-by: Nirmoy Das <nirmoy.das at amd.com> >>> ---

Am 18.02.20 um 19:16 schrieb Thomas Zimmermann: > Hi > > Am 18.02.20 um 18:13 schrieb Nirmoy: >> On 2/18/20 1:44 PM, Christian K?nig wrote: >>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >>>> Hi >>>> >>>> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>>>> GPU address handling is device specific and should be handle by its

https://bugs.freedesktop.org/show_bug.cgi?id=111940 Bug ID: 111940 Summary: frequent timeout warnings during normal operation Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Driver/nouveau

Am 18.02.20 um 19:28 schrieb Thomas Zimmermann: > Hi > > Am 18.02.20 um 19:23 schrieb Christian K?nig: >> Am 18.02.20 um 19:16 schrieb Thomas Zimmermann: >>> Hi >>> >>> Am 18.02.20 um 18:13 schrieb Nirmoy: >>>> On 2/18/20 1:44 PM, Christian K?nig wrote: >>>>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:

On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > The code expects non-VRAM mem nodes to have a pages list. If that's not > set, it will do a null deref down the line. Warn on that condition and > return an error. > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > > Reported-by: Pasi K?rkk?inen <pasik at iki.fi> >

Am 18.02.20 um 18:13 schrieb Nirmoy: > > On 2/18/20 1:44 PM, Christian K?nig wrote: >> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >>> Hi >>> >>> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>>> GPU address handling is device specific and should be handle by its >>>> device >>>> driver. >>>> >>>>

Hi Am 18.02.20 um 18:13 schrieb Nirmoy: > > On 2/18/20 1:44 PM, Christian K?nig wrote: >> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >>> Hi >>> >>> Am 17.02.20 um 16:04 schrieb Nirmoy Das: >>>> GPU address handling is device specific and should be handle by its >>>> device >>>> driver. >>>>

Without diving in any of the details, your commit message has me curious and concerned... In a "manager" kind of way, despite being neither a manager nor an insider or active contributor. ;-) On 24/01/2020 14:30, Christian K?nig wrote: > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru

https://bugs.freedesktop.org/show_bug.cgi?id=101220 --- Comment #19 from Pacho Ramos <pachoramos1 at gmail.com> --- Any news on this? I still need to run with noaccel with kernel 4.19.25, otherwise system ends up getting hung after showing this errors: feb 23 17:21:08 dell-2017 kernel: ------------[ cut here ]------------ feb 23 17:21:08 dell-2017 kernel: nouveau 0000:01:00.0: timeout feb

Hi Am 18.02.20 um 19:23 schrieb Christian K?nig: > Am 18.02.20 um 19:16 schrieb Thomas Zimmermann: >> Hi >> >> Am 18.02.20 um 18:13 schrieb Nirmoy: >>> On 2/18/20 1:44 PM, Christian K?nig wrote: >>>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann: >>>>> Hi >>>>> >>>>> Am 17.02.20 um 16:04 schrieb Nirmoy Das:

The code expects non-VRAM mem nodes to have a pages list. If that's not set, it will do a null deref down the line. Warn on that condition and return an error. See https://bugs.freedesktop.org/show_bug.cgi?id=64774 Reported-by: Pasi K?rkk?inen <pasik at iki.fi> Tested-by: Pasi K?rkk?inen <pasik at iki.fi> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: <stable

On Sat, 25 Jan 2020 at 00:30, Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru used by > Nouveau is actually not working at all. > > In general we should remove driver specific handling from the memory > management,

On Tue, Feb 18, 2020 at 07:37:44PM +0100, Christian K?nig wrote: > Am 18.02.20 um 19:28 schrieb Thomas Zimmermann: > > Hi > > > > Am 18.02.20 um 19:23 schrieb Christian K?nig: > > > Am 18.02.20 um 19:16 schrieb Thomas Zimmermann: > > > > Hi > > > > > > > > Am 18.02.20 um 18:13 schrieb Nirmoy: > > > > > On 2/18/20

Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian.

From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile

While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve v3: rebased and use both base and offset in the check v4:

On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote: > While working on TTM cleanups I've found that the io_reserve_lru used by > Nouveau is actually not working at all. > > In general we should remove driver specific handling from the memory > management, so this patch moves the io_reserve_lru handling into Nouveau > instead. > > The patch should be