search for: runlists

Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system memory. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/fifo/gf100.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engine/fifo/gf100.c

5.2.0-rc4-next-20190613 dmesg nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:01:00.0: fifo: channel 5: killed nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery

Address of the ENG_RUNLIST register should be 0x002284 + (engine * 8), not 0x002284 + (engine * 4). Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Stumbled upon this one and I'm quite certain the offset was not correct. This is inconsequential for GK20A which only features one runlist, but other GPUs might run into troubles because of this. Not tested, just reported for

Hi, I am having issues with nouveau driver in 4.11 Debian distribution kernel. I can start X session but the screen locks up e.g. when I try to exit mplayer fullscreen mode. The lock is swamped with tons of nouveau 0000:03:00.0: fifo: SCHED_ERROR 13 [] messages and I also can see some warnings ------------[ cut here ]------------ WARNING: CPU: 1 PID: 3535 at

https://bugs.freedesktop.org/show_bug.cgi?id=105814 Bug ID: 105814 Summary: Frequent Xorg lockups with GT710 after rad or write faults Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

This is the initial NTFS file system support for Syslinux :-) The following changes since commit 67954e370003d9bbfd8b58042669f2e9d532636f: ifmemdsk: remove spurious +x bit (2011-08-25 10:58:44 -0700) are available in the git repository at: git://github.com/pcacjr/syslinux.git ntfs-for-hpa Paulo Alcantara (34): Add NTFS filesystem support to Linux and Windows installers Initial

On (06/14/19 11:50), Sergey Senozhatsky wrote: > dmesg > > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery > nouveau 0000:01:00.0: fifo: channel 5: killed > nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery >

On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky <sergey.senozhatsky.work at gmail.com> wrote: > > On (06/14/19 11:50), Sergey Senozhatsky wrote: > > dmesg > > > > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon > > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > > nouveau 0000:01:00.0: fifo: runlist 0: scheduled for

https://bugs.freedesktop.org/show_bug.cgi?id=104421 Bug ID: 104421 Summary: System freeze on wayland with nouveau on NV137 (GP107) Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee:

Hello everyone, it seems that GP10B support has regressed recently. With linux-next, I need to modify device/base.c to set .mmu = gp10b_mmu_new for GP10B (makes sense - I guess this was left as gf100_mmu_new as a typo) to probe. After that, running a trivial testcase (running a NOP method in 3D class) fails with [ 110.084649] nouveau 17000000.gpu: fifo: read fault at 0000011000 engine 06

Hi, On 04-12-15 09:54, Samuel Pitoiset wrote: > > > On 12/04/2015 09:45 AM, Hans de Goede wrote: <snip> >>> Please give a shot at this branch : >>> http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute >>> >>> It fixes the initialization of the compute state and allows me to >>> launch 'test_input_global' (ie. ./compute

Twice now with v4.15-rc6, my display has gone belly up. Note: swiotlb: suppress warning when __GFP_NOWARN is set v2 is applied, but I don't _think_ it was the first time it happened. [ 3729.558261] nouveau 0000:01:00.0: gr: TRAP ch 2 [00ff842000 Xorg[3413]] [ 3729.558269] nouveau 0000:01:00.0: gr: GPC0/TPC0/TEX: 80000041 [ 3729.558273] nouveau 0000:01:00.0: gr: GPC0/TPC1/TEX: 80000041 [

From: Yonatan Maman <Ymaman at Nvidia.com> When `nouveau_dmem_copy_one` is called, the following error occurs: [272146.675156] nouveau 0000:06:00.0: fifo: PBDMA9: 00000004 [HCE_PRIV] ch 1 00000300 00003386 This indicates that a copy push command triggered a Host Copy Engine Privileged error on channel 1 (Copy Engine channel). To address this issue, modify the Copy Engine channel to allow

https://bugs.freedesktop.org/show_bug.cgi?id=104448 Bug ID: 104448 Summary: [NV106/GK208B] Multiple issues / hangs with nouveau driver Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component:

This is an initial series of patches to improve channel recovery on Turing GPUs with the goal of improving reliability enough to eventually enable SVM for Turing. It's likely follow up patches will be required to fully address problems with less trivial workloads than what I have been able to test thus far. This series primarily addresses a number of hardware changes to interrupt layout and

https://bugs.freedesktop.org/show_bug.cgi?id=107964 Bug ID: 107964 Summary: [GTX970] system hang when using libreoffice Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau

On Sat, Feb 01, 2014 at 12:16:54PM +0900, Alexandre Courbot wrote: > GK20A's FIFO is compatible with NVE0, but only features 128 channels and > 1 runlist. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/Makefile | 1 + > drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h | 1 + >

On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky <sergey.senozhatsky.work at gmail.com> wrote: > > On (06/19/19 01:20), Ilia Mirkin wrote: > > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky > > <sergey.senozhatsky.work at gmail.com> wrote: > > > > > > On (06/14/19 11:50), Sergey Senozhatsky wrote: > > > > dmesg > > > >

I applied the changes manually. This time, Xorg is actually starting... [ 16.862744] WARNING: CPU: 3 PID: 381 at drivers/gpu/drm/nouveau/nouveau_bo.c:280 nouveau_bo_new+0x450/0x4d0 [nouveau] [ 16.873333] Modules linked in: nouveau i2c_algo_bit ttm tegra_drm gpio_keys drm_kms_helper drm drm_panel_orientation_quirks(P) host1x dwmac_dwc_qos_eth stmmac_platform stmmac ptp pps_core syscopyarea

Using the kernel global workqueue to signal fences can lead to unexpected deadlocks. Some other work (e.g. from a different driver) could directly or indirectly depend on this fence to be signaled. However, if the WQ_MAX_ACTIVE limit is reached by waiters, this can prevent the work signaling the fence from running. While this seems fairly unlikely, it's potentially exploitable. Fixes: