similar to: Gart to vram/vram to gart transfers broken on NVS 140M

https://bugs.freedesktop.org/show_bug.cgi?id=76605 Priority: medium Bug ID: 76605 Assignee: nouveau at lists.freedesktop.org Summary: Screen corruption and crashes in bastion on NVS-140M (G86) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: matthias at blankertz.org

For now pixmaps will only be tiled if driver pixmaps are being used and we're told to with the NOUVEAU_CREATE_PIXMAP_TILED usage hint. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- src/nouveau_exa.c | 31 ++++++++++++++++++++----------- src/nv50_exa.c | 6 +++--- src/nv50_xv.c | 2 +- src/nv_proto.h | 2 +- src/nv_type.h | 1 + 5 files

With this patch the DDX almost works with GK20A, the missing piece is adding COHERENT mappings to the right places. ;-) If you specify NOUVEAU_BO_APER the kernel will truncate valid_domains to the domains specified at creation time. This means that as long as we only specify the correct domain in nouveau_allocate_surface the effect is still the same. Signed-off-by: Maarten Lankhorst <dev at

In case it's any use for debugging, I get these error messages in dmesg on my NV86 (Quadro NVS 140M) card: [ 21.729435] [drm] Initialized drm 1.1.0 20060810 [ 21.749414] nouveau 0000:01:00.0: power state changed by ACPI to D0 [ 21.749425] nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 21.749432] nouveau 0000:01:00.0: setting latency timer to 64 [ 21.749528]

https://bugs.freedesktop.org/show_bug.cgi?id=53535 Bug #: 53535 Summary: G84M [Quadro NVS 140M] X crash after waking up from suspend: Process /usr/bin/Xorg was killed by signal 6 (SIGABRT) Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version:

https://bugs.freedesktop.org/show_bug.cgi?id=30842 Summary: G84M/NVS 140M GPU Lockup Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

Hi, I've just tried nouveau for the first time and I'd like to thank you all for your hard work. It works well, and I'm especially impressed to see xv running on my card (NV50 generation). Here is a brief report of my test. Details: - Card is Quadro NVS 140M - nouveau-drm and xf86-video-nouveau are from today's git - linux 2.6.26.3 from archlinux - X.Org X Server 1.4.99.906

https://bugs.freedesktop.org/show_bug.cgi?id=109631 Bug ID: 109631 Summary: Moving gbm bo from GART to VRAM does not wait for rendering Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

http://bugs.freedesktop.org/show_bug.cgi?id=25762 Summary: Quadro NVS 140M doesn't wake up anymore Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

- map should handle this. --- src/nouveau_exa.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c index b656ca7..20ad380 100644 --- a/src/nouveau_exa.c +++ b/src/nouveau_exa.c @@ -259,7 +259,7 @@ nouveau_exa_mark_sync(ScreenPtr pScreen) static void nouveau_exa_wait_marker(ScreenPtr pScreen, int marker) { -

Hi, I've been using the nouveau driver for some time on my Latitude T61p with a Quadro NVS 140M card: 4pll00555 ~ # lspci 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c) 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection

http://bugs.freedesktop.org/show_bug.cgi?id=27288 Summary: EXA corruption on small pixmaps Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

- Only for sufficiently new xserver's and exa_driver_pixmaps. --- src/nouveau_exa.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++++++-- src/nv_driver.c | 51 +++++++++++-- src/nv_proto.h | 4 + src/nv_type.h | 12 +++- 4 files changed, 267 insertions(+), 17 deletions(-) diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c index 93fc3c5..074a226 100644 ---

Hi Do you have an idea why am I getting random reboots and (sometimes) this stacktrace? : http://people.eisenbits.com/~stf/load/20151222-kernel-stack-trace.png This should probably go as a bug report, but I have already uninstalled the driver --- sorry. This is a fresh install of Debian 8.3 (latest stable) (Jessie). After switching to VESA everything is stable --- the only problem is that this

http://bugs.freedesktop.org/show_bug.cgi?id=23231 Summary: Nouveau driver from git fails to build Product: xorg Version: 6.99.99.904 (7.0 RC4) Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: high Component: Driver/nouveau AssignedTo: nouveau at

http://bugs.freedesktop.org/show_bug.cgi?id=15792 Summary: nv04 (TNT2) video blitter problem. Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

I looked a bit more into the problem of vertex corruption with GART vertex buffers that disappears putting the buffers in VRAM that I'm experiencing on my card. The system I'm seeing this on is a Dell Inspiron 9400 notebook with a GeForce Go 7900 GS on a PCI Express Intel i945 chipset. First, I've looked into the behavior of the nVidia driver: 1. On all NV3x and NV4x traces, and my

http://bugs.freedesktop.org/show_bug.cgi?id=16978 Summary: "tile offscreen pixmaps" causing graphics corruption on NV50? Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

Hello folks. I would like to ask You for help with the following problem. Am I missing anything important? Thanks. make all-recursive make[1]: Entering directory `/home/tavvva/Install/nouveau/xf86-video-nouveau' Making all in src make[2]: Entering directory `/home/tavvva/Install/nouveau/xf86-video-nouveau/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..

I am trying to figure out why the ttm_bo_vm_fault is stitching pages from the GART instead of the pages allocated via DRM_NOUVEAU_GEM_NEW. And also why OUR_RINGp is writing 16, 256 and 512 bytes of zero filled data *1 in the GART? Perhaps I should mention that I know _why_ it is taking the pages from the GART and giving them to the userland - but I don't know if that is correct way of doing