similar to: [Bug 69876] [NVC3] Reverse prime sometimes freezes the machine

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #6 from Emil Velikov <emil.l.velikov at gmail.com> --- Had a typo previously, the correct argument is nouveau.config=NvMSI=0 -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=69876 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Revers prime sometime |[NVC3] Reverse prime |freezes the machine |sometimes freezes the |

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #3 from Mike <michele.cane at gmail.com> --- With 3.10 is working fine. Have not tried with 3.11. I recompiled 3.12-rc1 without vgaswitcheroo and the problem persists. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #4 from Kevin N. <vekinn at gmail.com> --- I experience the same thing with my Thinkpad t530 and NVS 5400m in Optimus mode with 3.12-rc2 on Fedora 19. Locks up if I use xrandr or try to do anything with the displayport unless I have it plugged in at boot. Works fine if I change in bios to discrete nvidia. -- You are

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #12 from Mike <michele.cane at gmail.com> --- I dropped Gnome and I now use Compton as compositor and the problem is no more present. I do not know if is due to newer kernel 3.16 or is a compositor related issue. Cheers Michele Cane, PhD. Sent from my Android device. On Aug 21, 2014 11:25 PM, <bugzilla-daemon at

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #7 from Mike <michele.cane at gmail.com> --- Created attachment 87285 --> https://bugs.freedesktop.org/attachment.cgi?id=87285&action=edit dmesg output from nouveau.debug=trace -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #8 from Mike <michele.cane at gmail.com> --- (In reply to comment #6) > Had a typo previously, the correct argument is > nouveau.config=NvMSI=0 The behaviour remain the same with nouveau.config=NvMSI=0 -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #9 from Mike <michele.cane at gmail.com> --- When nouveau.runpm=0 no freeze occurs. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #10 from Mike <michele.cane at gmail.com> --- If after xrandr --setprovideroffloadsink nouveau Intel i turn on the card with, for example, DRI_PRIME glxgers and then I xrandr --setprovideroutputsource nouveau Intel there is no freeze -- You are receiving this mail because: You are the assignee for the bug. --------------

https://bugs.freedesktop.org/show_bug.cgi?id=69876 --- Comment #11 from Ilia Mirkin <imirkin at alum.mit.edu> --- Is this still an issue with 3.13.x or later? Some runpm issues were fixed there. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=69876 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are

https://bugs.freedesktop.org/show_bug.cgi?id=69876 Aaron Plattner <aplattner at nvidia.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|aplattner at nvidia.com |nouveau at lists.freedesktop.o | |rg

https://bugs.freedesktop.org/show_bug.cgi?id=70464 Priority: medium Bug ID: 70464 Assignee: nouveau at lists.freedesktop.org Summary: [NVC3] runpm not working QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: michele.cane at gmail.com

https://bugs.freedesktop.org/show_bug.cgi?id=75279 Emil Velikov <emil.l.velikov at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #42 from Emil Velikov

Well, I don't pretend to know anything about X, but this is the commit that added the code in question: commit 297fd0d0755bda698be1d0b30cc60a41d7673c0b Author: Dave Airlie <airlied at redhat.com> Date: Tue Oct 16 16:15:16 2012 +1000 nouveau/dri2: fix pixmap/window offset calcs. This should fix prime rendering under kwin, and not break it under the others.

On 2019/05/23, Ben Skeggs wrote: > On Thu, 23 May 2019 at 01:03, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > > > From: Emil Velikov <emil.velikov at collabora.com> > > > > Cc: Ben Skeggs <bskeggs at redhat.com> > > Cc: nouveau at lists.freedesktop.org > > Signed-off-by: Emil Velikov <emil.velikov at collabora.com> >

Commit 'drm/nv50-nvc0/vm: support unsnooped system memory' caused a regression on certain nv50 IGP due to not passing the correct target type to nv50_vm_addr() Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=45746 Reported-by: Johannes Obermayr <johannesobermayr at gmx.de> Tested-by: Johannes Obermayr <johannesobermayr at gmx.de> Signed-off-by: Emil Velikov

On Mon, 27 May 2019 at 09:19, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > From: Emil Velikov <emil.velikov at collabora.com> > > The authentication can be circumvented, by design, by using the render > node. > > From the driver POV there is no distinction between primary and render > nodes, thus we can drop the token. > > Note: the outstanding

On Mon, 27 May 2019 at 09:19, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > From: Emil Velikov <emil.velikov at collabora.com> > > The authentication can be circumvented, by design, by using the render > node. > > From the driver POV there is no distinction between primary and render > nodes, thus we can drop the token. > > Cc: Gerd Hoffmann

Thanks for finding this Emil! The change you point out also landed on 4.19.49 and I am able to reproduce the fan speed issue with that kernel as well, whereas previous 4.19.x series kernels were fine. I'll attempt to build both the latest 4.19.x and 5.1.x stable kernels with that patch reverted and see if it's the sole culprit. On Friday, June 21, 2019, 1:32:19 PM EDT, Emil Velikov