similar to: [Bug 69375] New: [NV4E] GPU lockup when using chrome/flash

https://bugs.freedesktop.org/show_bug.cgi?id=55258 Priority: medium Bug ID: 55258 Assignee: nouveau at lists.freedesktop.org Summary: nouveau failure on resume (reloc wait_idle failed) QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: mr.dash.four at

https://bugs.freedesktop.org/show_bug.cgi?id=70388 Priority: medium Bug ID: 70388 Assignee: nouveau at lists.freedesktop.org Summary: [NV34] failed to idle channel 0xcccc0000 Severity: critical Classification: Unclassified OS: Linux (All) Reporter: rosti.bsd at gmail.com Hardware: x86 (IA32)

https://bugs.freedesktop.org/show_bug.cgi?id=73445 Priority: medium Bug ID: 73445 Assignee: nouveau at lists.freedesktop.org Summary: [NV4E] regression with 3.13 -rcX: glxgears etc. hard lockup/freezes machine, on 3.12 everything works Severity: critical Classification: Unclassified OS: Linux (All)

http://bugs.freedesktop.org/show_bug.cgi?id=26201 Summary: Some screen garbage, NoAccel and GPU lockup reported with NV4E Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=75464 Priority: medium Bug ID: 75464 Assignee: nouveau at lists.freedesktop.org Summary: [nv4e] [vdpau] causes hangs QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: ronald645 at gmail.com Hardware:

Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait") converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout(). However, dma_resv_wait_timeout() returns greater than zero on success as opposed to ttm_bo_wait_ctx(). As a result, relocs will fail and log errors even when it was a success. Change the return code handling to match that of nouveau_gem_ioctl_cpu_prep(), which was

Am 15.04.23 um 04:02 schrieb John Ogness: > Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait") > converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout(). > However, dma_resv_wait_timeout() returns greater than zero on > success as opposed to ttm_bo_wait_ctx(). As a result, relocs > will fail and log errors even when it was a success. > > Change the

https://bugs.freedesktop.org/show_bug.cgi?id=69488 Priority: medium Bug ID: 69488 Assignee: nouveau at lists.freedesktop.org Summary: GF108 (NVC1) GPU lockup QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: vekinn at gmail.com Hardware: Other

https://bugs.freedesktop.org/show_bug.cgi?id=71438 Priority: medium Bug ID: 71438 Assignee: nouveau at lists.freedesktop.org Summary: Application Konqueror crashes when connecting to asus.com QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All)

Hi. I am new to the listm so, first of all I'd like to say hello to everyone here in the list. I hope this list is an adequate place to post this; else, please, kindly direct me to the right list :) I write because I am having an issue with nouveau and mplayer. I have been only able to reproduce it with mplayer, but I think the issue lies in nouveau, either the kernel part or libdrm. The

Found by sparse. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 03d8935..d7ace31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@

https://bugs.freedesktop.org/show_bug.cgi?id=58615 Priority: medium Bug ID: 58615 Assignee: nouveau at lists.freedesktop.org Summary: nv43 hangs with direct rendering since 3.7 rework QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: randrik at

https://bugs.freedesktop.org/show_bug.cgi?id=74492 Priority: medium Bug ID: 74492 Assignee: nouveau at lists.freedesktop.org Summary: v3.13-rc8 nv4e + msi = random lockups QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: ronald645 at gmail.com

On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki <zajec5 at gmail.com> wrote: > 2014-02-11 11:41 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: >> (b) bisect. you can (almost) definitely restrict the bisect to >> drivers/gpu/drm/nouveau. if you have additional computational power, i >> would recommend looking into distcc for speeding up the compiles. it >>

https://bugs.freedesktop.org/show_bug.cgi?id=80942 Priority: medium Bug ID: 80942 Assignee: nouveau at lists.freedesktop.org Summary: NV4E - regular system crash with nouveau driver QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: b.torremans at

https://bugs.freedesktop.org/show_bug.cgi?id=78441 Priority: medium Bug ID: 78441 Assignee: nouveau at lists.freedesktop.org Summary: X does not start under kernel 3.13.x QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: aebenjam at opentext.com

2014-02-11 11:41 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > (b) bisect. you can (almost) definitely restrict the bisect to > drivers/gpu/drm/nouveau. if you have additional computational power, i > would recommend looking into distcc for speeding up the compiles. it > may be interesting to also try 3.6.x since 3.7 received a pretty big > rewrite. but a git bisect is a

Hi, I currently have a MySQL database containing all Puppet storeconfigs. My intention is to migrate to PuppetDB on a PostgreSQL server, so the first step is to use the ''storeconfigs'' face to export all the DB to a file PuppetDB can later consume. But the ''puppet storeconfigs export'' command always ends up being killed, I suspect due to some sort of OOM

Commit dceef5d87 (drm/nouveau/fb: initialise vram controller as pfb sub-object) moved some code around and introduced these null derefs. pfb->ram is set to the new ram object outside of this ctor. Reported-by: Ronald Uitermark <ronald645 at gmail.com> Tested-by: Ronald Uitermark <ronald645 at gmail.com> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> ---

On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki <zajec5 at gmail.com> wrote: > Hi guys, > > Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and > noticed nasty display corruptions when using nouveau. It seems that > changing parts of the screen are appearing for a fraction of second in > random places. I've recorded this behavior: >