similar to: [PATCH] drm/nouveau: Fix ttm move init with multiple GPUs

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #43 from Andreas Loew <awl1 at gmx.net> --- Hello again, so it looks like I have now tracked the issue down. The "offending" commit seems to be: 4c193d254ee94da02857b9670e815b1765a9579b (the first commit which showed the issue - I tried for more than half an hour with its direct predecessor

On Fri, 7 Aug 2020 at 11:13, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote: > > From: Rodrigo Vivi <rodrigo.vivi at gmail.com> > > These are missed cases that I just identified with allyesconfig build. > Is this against drm-tip? it's a merge problem, that I thought I'd already addressed, but tip seems to have lost it. Dave. > Fixes: 2966141ad2dd

From: Rodrigo Vivi <rodrigo.vivi at gmail.com> These are missed cases that I just identified with allyesconfig build. Fixes: 2966141ad2dd ("drm/ttm: rename ttm_mem_reg to ttm_resource.") Cc: Dave Airlie <airlied at redhat.com> Cc: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.h

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 +++

The page_count variable in nv04_bo_move_m2mf was redundantly initialized twice with the same value. Signed-off-by: Sergi Granell <xerpi.g.12 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 548f36d3..2724907a 100644 ---

Regression from "drm/nve0: use async copy engine for ttm buffer moves if available". Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 325b8cb..dc04395 100644 ---

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #45 from Andreas Loew <awl1 at gmx.net> --- Hmm... While my card definitely is not at all defective (it works the exact same way it always has), I indeed also have some issues that make it impossible for me to still use the "blob" even on an attic distro like RHEL6: The most recent version of the NVidia proprietary

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #47 from Andreas Loew <awl1 at gmx.net> --- Hi - it's me again ;-) > Well, given that it doesn't work on the blob makes it sound like you have some > sort of funkiness in your hardware. One unsubstantiated theory is that the > vdec clock is *disabled*, and pcrypt is hooked up to that clock. Or perhaps >

On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote: > On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding <thierry.reding at gmail.com> wrote: > > > > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > > > > > Hi, > > > >

On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote: > From: Ari Hirvonen <ahirvonen at nvidia.com> > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. > > Signed-off-by: Ari Hirvonen <ahirvonen at nvidia.com> >

Do not attach fences automatically to buffers that are marked for explicit synchronization. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drm/nouveau_bo.c | 8 ++++---- drm/nouveau_bo.h | 4 ++-- drm/nouveau_drm.c | 1 + drm/nouveau_gem.c | 47 +++++++++++++++++++++++++++++++++++++++------- drm/nouveau_gem.h | 6 ++++--

uhhhhhhhhhhhhh didn't we fix this weeks ago? with "drm/nouveau: tegra: Call nouveau_drm_device_init()" On Fri, 2018-12-07 at 23:31 +0000, Guillaume Tucker wrote: > Please find below an automated bisection report for a kernel Oops > seen during the initialisation of the nouveau GPU driver on > jetson-tk1. > > > All the LAVA test jobs for this bisection can be

On 08/12/2018 00:08, Lyude Paul wrote: > uhhhhhhhhhhhhh > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > nouveau_drm_device_init()" Yes here's the fix from Thierry: https://patchwork.freedesktop.org/patch/263587/ and I can confirm that it does fix the Oops when applied on top of next-20181206 (what I used for the bisection last week):

Please find below an automated bisection report for a kernel Oops seen during the initialisation of the nouveau GPU driver on jetson-tk1. All the LAVA test jobs for this bisection can be found here: http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-staging-7366#table Here's the beginning of the Oops stack trace: [ 7.485361] [00000064] *pgd=f9e7b835 [

> Hi Gerd, > > I've been seeing a regression on Nouveau with recent linux-next releases > and git bisect points at this commit as the first bad one. If I revert > it (there's a tiny conflict with a patch that was merged subsequently), > things are back to normal. > > I think the reason for this issue is that Nouveau doesn't use GEM > objects for all buffer

Hard-coded value of DMA_ATTR_WEAK_ORDERING is then compared with the symbol. This will stop matching if the value of symbol is changed (when switching DMA attributes to unsigned long). Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- arch/powerpc/platforms/cell/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

On 06/15/2015 04:09 PM, Alexandre Courbot wrote: > From: Ari Hirvonen <ahirvonen at nvidia.com> > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. Adding Thierry to the conversation since he knows best about exported buffers and attributes.

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

On Mon, Oct 21, 2019 at 4:14 PM Navid Emamdoost <navid.emamdoost at gmail.com> wrote: > > In the implementation of nouveau_bo_alloc() if it fails to determine the > target page size via pi, then the allocated memory for nvbo should be > released. > > Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") > Signed-off-by: Navid Emamdoost

ping... On Thu, Nov 21, 2019 at 12:09 PM Navid Emamdoost <navid.emamdoost at gmail.com> wrote: > > On Mon, Oct 21, 2019 at 4:14 PM Navid Emamdoost > <navid.emamdoost at gmail.com> wrote: > > > > In the implementation of nouveau_bo_alloc() if it fails to determine the > > target page size via pi, then the allocated memory for nvbo should be > >