Re: [Nouveau] Video Engine Utilization
On Mon, Jun 27, 2016 at 3:10 AM, wrote: > Hi > > i-m not sure if these is the right place for my question but i will try. Probably not - you appear to be using the NVIDIA proprietary driver. You should reach out via their support channels, if any. > > I-m using Debian 8 with Gnome 3.14.1 i have Quadro NVS 290 Graphic processor > > in nvidia X Server Settings: Video Engine Utilization - 0 % always also > browser > > lag from time to time. In the supported GPU Quadro NVS 290 is listed. Code > Name: NV86 (G86) > > PrtScn Attached. You also appear to have forgotten to ask your question. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91632] Assert in nouveau_pushbuf_data
https://bugs.freedesktop.org/show_bug.cgi?id=91632 --- Comment #4 from Tomasz Paweł Gajc --- Hi, any news on this issue ? I'm running quite fresh system (OpenMandriva Lx 3.0) with: Qt 5.6.1 Mesa 12.0-rc4 libdrm 2.4.68 kernel 4.62 gfx card nv92 and Qupzilla 2.01 crashes for me with this error [tpg@lazur ~]$ LC_ALL=C qupzilla QupZilla: 0 extensions loaded Uncaught TypeError: Cannot read property 'restoreData' of null nouveau: kernel rejected pushbuf: No such file or directory nouveau: ch10: krec 0 pushes 0 bufs 1 relocs 0 nouveau: ch10: buf 0002 0004 0004 nouveau: kernel rejected pushbuf: No such file or directory nouveau: ch10: krec 0 pushes 0 bufs 1 relocs 0 nouveau: ch10: buf 0002 0004 0004 ATTENTION: default value of option force_s3tc_enable overridden by environment. QupZilla: Starting with profile 'default' QupZilla: 0 extensions loaded nouveau: kernel rejected pushbuf: No such file or directory nouveau: ch11: krec 0 pushes 0 bufs 2 relocs 0 nouveau: ch11: buf 0002 0004 0004 nouveau: ch11: buf 0001 0006 0004 0004 nouveau: kernel rejected pushbuf: No such file or directory nouveau: ch11: krec 0 pushes 0 bufs 1 relocs 0 nouveau: ch11: buf 0002 0004 0004 qupzilla: pushbuf.c:727: void nouveau_pushbuf_data(struct nouveau_pushbuf *, struct nouveau_bo *, uint64_t, uint64_t): Warunek zapewnienia `kref' nie został spełniony. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH v2] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page
On 21 June 2016 at 14:50, Ard Biesheuvel wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes > problems for platforms with no memory below 4 GB (such as AMD Seattle) > > So move the dma_map_page() to the .init hook, and set the streaming DMA > mask based on the MMU subdev parameters before performing the call. > > Signed-off-by: Ard Biesheuvel > --- > > I am sure there is a much better way to address this, but this fixes the > problem I get on AMD Seattle with a GeForce 210 PCIe card: > >nouveau :02:00.0: enabling device ( -> 0003) >nouveau :02:00.0: NVIDIA GT218 (0a8280b1) >nouveau :02:00.0: bios: version 70.18.a6.00.00 >nouveau :02:00.0: fb ctor failed, -14 >nouveau: probe of :02:00.0 failed with error -14 > > v2: replace incorrect comparison of dma_addr_t type var against NULL > Ping? > drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 37 ++-- > 1 file changed, 26 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c > index 1b5fb02eab2a..033ca0effb7e 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c > @@ -216,11 +216,30 @@ nv50_fb_init(struct nvkm_fb *base) > struct nv50_fb *fb = nv50_fb(base); > struct nvkm_device *device = fb->base.subdev.device; > > + if (!fb->r100c08) { > + /* > +* We are calling the DMA api way before the TTM layer sets > the > +* DMA mask based on the MMU subdev parameters. This means we > +* are using the default DMA mask of 32, which may cause > +* problems on systems with no RAM below the 4 GB mark. So set > +* the streaming DMA mask here as well. > +*/ > + dma_set_mask(device->dev, > DMA_BIT_MASK(device->mmu->dma_bits)); > + > + fb->r100c08 = dma_map_page(device->dev, fb->r100c08_page, 0, > + PAGE_SIZE, DMA_BIDIRECTIONAL); > + if (dma_mapping_error(device->dev, fb->r100c08)) { > + nvkm_warn(&fb->base.subdev, > + "dma_map_page() failed on 100c08 page\n"); > + } > + } > + > /* Not a clue what this is exactly. Without pointing it at a > * scratch page, VRAM->GART blits with M2MF (as in DDX DFS) > * cause IOMMU "read from address 0" errors (rh#561267) > */ > - nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8); > + if (fb->r100c08 != DMA_ERROR_CODE) > + nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8); > > /* This is needed to get meaningful information from 100c90 > * on traps. No idea what these values mean exactly. */ > @@ -233,11 +252,11 @@ nv50_fb_dtor(struct nvkm_fb *base) > struct nv50_fb *fb = nv50_fb(base); > struct nvkm_device *device = fb->base.subdev.device; > > - if (fb->r100c08_page) { > + if (fb->r100c08 && fb->r100c08 != DMA_ERROR_CODE) > dma_unmap_page(device->dev, fb->r100c08, PAGE_SIZE, >DMA_BIDIRECTIONAL); > - __free_page(fb->r100c08_page); > - } > + > + __free_page(fb->r100c08_page); > > return fb; > } > @@ -264,13 +283,9 @@ nv50_fb_new_(const struct nv50_fb_func *func, struct > nvkm_device *device, > *pfb = &fb->base; > > fb->r100c08_page = alloc_page(GFP_KERNEL | __GFP_ZERO); > - if (fb->r100c08_page) { > - fb->r100c08 = dma_map_page(device->dev, fb->r100c08_page, 0, > - PAGE_SIZE, DMA_BIDIRECTIONAL); > - if (dma_mapping_error(device->dev, fb->r100c08)) > - return -EFAULT; > - } else { > - nvkm_warn(&fb->base.subdev, "failed 100c08 page alloc\n"); > + if (!fb->r100c08_page) { > + nvkm_error(&fb->base.subdev, "failed 100c08 page alloc\n"); > + return -ENOMEM; > } > > return 0; > -- > 2.7.4 > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 38074] [NV96] Dual head doesn't work for some combination of DVI connected monitors (second screen still off)
https://bugs.freedesktop.org/show_bug.cgi?id=38074 --- Comment #32 from Ilia Mirkin --- There's a patch which may help here: https://github.com/skeggsb/nouveau/commit/bd320d9b0ee2f2443f7568e06bdc33a35cfb24ea -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 96553] Xorg freezes
https://bugs.freedesktop.org/show_bug.cgi?id=96553 --- Comment #1 from Agostino Sarubbo --- When the problem happens, In dmesg there is the following messages: [11449.585126] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] [11449.585132] nouveau :01:00.0: fifo: sw engine fault on channel 2, recovering... [11451.584882] nouveau :01:00.0: fifo: runlist 0 update timeout [11453.880225] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] bug 72180 seems to mention the same message error, but that bug was resolved as INVALID I didn't read all comments, but the last comment seems to indicate that the problem is fixed in 4.1. I'm using 4.4 and it is not fixed here. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nouveau_drv_video.so ?
nouveau_drv_video.so - what should it be? https://koji.fedoraproject.org/koji/buildinfo?buildID=722316 ... 0.7.4-13 - Revert symlinks - should be handled by mesa rhbz#1271842 https://bugzilla.redhat.com/show_bug.cgi?id=1271842 ... 0.7.4-12 - Add symlinks for radeonsi,r600,nouveau - rhbz#1264499 https://bugzilla.redhat.com/show_bug.cgi?id=1264499 $ rpm -q libva libva-vdpau-driver mesa-dri-drivers libva-1.7.1-1.fc24.x86_64 libva-vdpau-driver-0.7.4-14.fc24.x86_64 mesa-dri-drivers-11.2.2-2.20160614.fc24.x86_64 $ rpm -ql libva-vdpau-driver /usr/lib64/dri/nvidia_drv_video.so /usr/lib64/dri/s3g_drv_video.so /usr/lib64/dri/vdpau_drv_video.so /usr/share/doc/... ... $ rpm -ql mesa-dri-drivers /etc/drirc /usr/lib64/dri/gallium_drv_video.so /usr/lib64/dri/i915_dri.so /usr/lib64/dri/i965_dri.so /usr/lib64/dri/ilo_dri.so /usr/lib64/dri/kms_swrast_dri.so /usr/lib64/dri/nouveau_dri.so /usr/lib64/dri/nouveau_vieux_dri.so /usr/lib64/dri/r200_dri.so /usr/lib64/dri/r300_dri.so /usr/lib64/dri/r600_dri.so /usr/lib64/dri/radeon_dri.so /usr/lib64/dri/radeonsi_dri.so /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/virtio_gpu_dri.so /usr/lib64/dri/vmwgfx_dri.so /usr/lib64/gallium-pipe /usr/lib64/gallium-pipe/pipe_i965.so /usr/lib64/gallium-pipe/pipe_nouveau.so /usr/lib64/gallium-pipe/pipe_r300.so /usr/lib64/gallium-pipe/pipe_r600.so /usr/lib64/gallium-pipe/pipe_radeonsi.so /usr/lib64/gallium-pipe/pipe_swrast.so /usr/lib64/gallium-pipe/pipe_vmwgfx.so $ ll /usr/lib64/dri/ ... dummy_drv_video.so ... gallium_drv_video.so ... i915_dri.so ... i965_dri.so ... ilo_dri.so ... kms_swrast_dri.so ... nouveau_dri.so ... nouveau_vieux_dri.so ... nvidia_drv_video.so -> vdpau_drv_video.so ... r200_dri.so ... r300_dri.so ... r600_dri.so ... radeon_dri.so ... radeonsi_dri.so ... s3g_drv_video.so -> vdpau_drv_video.so ... swrast_dri.so ... vdpau_drv_video.so ... virtio_gpu_dri.so ... vmwgfx_dri.so $ icecat ... libva info: VA-API version 0.39.2 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so libva info: va_openDriver() returns -1 libva info: VA-API version 0.39.2 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so libva info: va_openDriver() returns -1 libva info: VA-API version 0.39.2 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/gallium_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau