similar to: [Bug 69982] New: GPU+system crash with nouveau and kernel 3.12-rc3

https://bugs.freedesktop.org/show_bug.cgi?id=69928 Priority: medium Bug ID: 69928 Assignee: nouveau at lists.freedesktop.org Summary: [NVAA] Boot of linux kernel 3.12-rc2 hangs QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: dirkneukirchen at

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

2014-02-09 23:12 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki <zajec5 at gmail.com> wrote: >> 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

https://bugs.freedesktop.org/show_bug.cgi?id=69952 Priority: medium Bug ID: 69952 Assignee: nouveau at lists.freedesktop.org Summary: [NVAA] Xorg crash+restart after glxgears on 3.12-rc2 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter:

On Wed, Dec 11, 2013 at 6:43 AM, Bruno Pr?mont <bonbons at linux-vserver.org> wrote: > Hi Ilia, > >> On Thu, 5 Dec 2013 10:55:06 -0500 Ilia Mirkin wrote: >> > On Thu, Dec 5, 2013 at 10:17 AM, Bruno Pr?mont wrote: >> > > With drm-nouveau-next branch on top of 3.13-rc2 and a few sound commits >> > > I get following errors in kernel log (repeating

https://bugs.freedesktop.org/show_bug.cgi?id=52244 Bug #: 52244 Summary: [ 4.876531] [drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major

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

Hi guys, With a GeForce 320M GPU running linux 3.13.2 and Xorg 1.15.0, I'm seeing significant graphical corruption and later unrecoverable GPU lockup, accompanied by thousands of ILLEGAL_MTHD or related kernel messages [1]. I see similar issues on 3.12 also. Is there any debugging or testing I can do to help diagnose this? Many thanks, Daniel --- [1] http://quora.org/nouveau-dmesg.txt

https://bugs.freedesktop.org/show_bug.cgi?id=84932 Bug ID: 84932 Summary: Optimus with nouveau no longer works with xorg-server 1.16.1 Product: Mesa Version: 10.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

https://bugs.freedesktop.org/show_bug.cgi?id=43323 Bug #: 43323 Summary: GPU lockup - X does not start on MacMini4,1 on 3.2.0-rc3-gf2d092a Classification: Unclassified Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority:

On 08.09.2013 23:33, Dave Airlie wrote: >>> Looks like you have Optimus (intel + nvidia), and the backtrace has >>> runtime pm in it, which is something new Dave added for 3.12, adding >>> him in explicitly. The simplest explanation is that disp->init is >>> NULL. And it seems like there are no outputs from the earlier nouveau >>> init prints. I

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)

nouveau_compiler.c: In function ‘main’: nouveau_compiler.c:216:27: warning: ‘code’ may be used uninitialized in this function [-Wmaybe-uninitialized] printf("%08x ", code[i / 4]); ^ nouveau_compiler.c:215:4: warning: ‘size’ may be used uninitialized in this function [-Wmaybe-uninitialized] for (i = 0; i < size; i += 4) { Signed-off-by: Tobias

https://bugs.freedesktop.org/show_bug.cgi?id=83079 Priority: medium Bug ID: 83079 Assignee: nouveau at lists.freedesktop.org Summary: Dota 2 under Wine freezes with Nouveau Drivers Severity: normal Classification: Unclassified OS: All Reporter: lukebenes at hotmail.com Hardware: Other Status:

This fixes wrong temperature outputs e.g. 511°C if the card is asleep. Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c index

Hi Ilia, On Thu, 5 Dec 2013 10:55:06 -0500 Ilia Mirkin wrote: > On Thu, Dec 5, 2013 at 10:17 AM, Bruno Pr?mont wrote: > > With drm-nouveau-next branch on top of 3.13-rc2 and a few sound commits > > I get following errors in kernel log (repeating much more often). > > (once there was a corrupted fbcon with matrix-like strings of > > unrecognizable glyph-strings hanging

> On 24 May 2015, at 16:03, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > > On 24.05.2015 10:38, Samuel Pitoiset wrote: >> >> >> On 05/24/2015 06:58 AM, Ilia Mirkin wrote: >>> nv30_validate_clip depends on the rasterizer state. Also we should >>> upload all the new clip planes on change since next time the

Hi, yeah in the long run showing both in an ordered manner would be a nice thing to have! That would include patching the output and the tgsi parser (who wants to delete half the output to parse it again e.g. with nouveau_compiler). I can image an output similar to the one below: IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} ^ IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,

Not sure if i understand completely what you intend to say here, with this we prevent hwmon from reporting utterly wrong temperature values returning an error (we could return -EBUSY or somehting instead, granted), yet if the device is shadowed, getting a sane temp value out of is seems unlikely to me! Greetings, Tobias On 1/26/18 12:40 PM, Karol Herbst wrote: > no, we can't do that.

Printing without this could lead to the following output, while the values are not exactly zero: IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} IMM[6] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} IMM[7] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} when printing the values as hex, we can now see the differences: IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,