| Summary: | [NVC3] Reverse prime sometimes freezes the machine | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Mike <michele.cane> | ||||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | ||||||||||
| Version: | 7.7 (2012.06) | ||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 86713 [details]
output of /var/log/syslog
Perhaps an interesting resource for you: http://nouveau.freedesktop.org/wiki/Optimus/ I'm no expect in the matter, but I'm pretty sure that you shouldn't be using vgaswitcheroo in conjunction with the new runtime pm stuff. Try disabling it (vgaswitcheroo). Alternatively (or in addition to), try disabling the new runtime pm logic, perhaps it doesn't work correctly for you. Is this a new issue? IOW, did this work properly on older kernels? If so, and the above fails, a bisect may be in order. With 3.10 is working fine. Have not tried with 3.11. I recompiled 3.12-rc1 without vgaswitcheroo and the problem persists. 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. There has been quite a few changes in the window you've mentioned. Thus to narrow it down further you can try - boot with "nouveau.config=MSI=0" to disable MSI interrupts(introduced in 3.12) If that does not help git bisect might be in order :) Had a typo previously, the correct argument is nouveau.config=NvMSI=0 Created attachment 87285 [details]
dmesg output from nouveau.debug=trace
(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 When nouveau.runpm=0 no freeze occurs. 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 Is this still an issue with 3.13.x or later? Some runpm issues were fixed there. 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@freedesktop.org> wrote: > *Comment # 11 <https://bugs.freedesktop.org/show_bug.cgi?id=69876#c11> > on bug 69876 <https://bugs.freedesktop.org/show_bug.cgi?id=69876> from Ilia > Mirkin <imirkin@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 reported the bug. > > |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 86712 [details] output of /var/log/Xorg.0.log I have a thinkpad with optimus (the nvidia card is a quadro 2000 m). I am running on Debian sid and a self compiled kernel (3.12-rc1). When I try to activate the nvidia card for using my external monitor a nolmally use: xrandr --setprovideroutputsource nouveau Intel and then xrandr --setprovideroffloadsink nouveau Intel Some time when I enter the first command the whole machine freezes. I retrived the syslog and the x logs and you can find them attached. Cheers Mike