<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [NV96] Unable to handle page request from nv50_crtc_prepare" href="https://bugs.freedesktop.org/show_bug.cgi?id=86537#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [NV96] Unable to handle page request from nv50_crtc_prepare" href="https://bugs.freedesktop.org/show_bug.cgi?id=86537">bug 86537</a> from <a class="email" href="mailto:j@greyltc.com" title="l3iggs <j@greyltc.com>"> l3iggs</a> <pre>I've found a workaround for this bug (tested with 3.18-rc5): (1) Append 'modprobe.blacklist=nouveau' to the kernel boot parameters This allows the system to boot. (2) Once booted, as root, reset the 9600M GPU: 'echo 1 > /sys/bus/pci/devices/0000:02:00.0/reset' (3) 'echo 1 > /sys/bus/pci/devices/0000:02:00.0/rescan' (4) 'modprobe nouveau' Note that 0000:02:00.0 is the PCI bus address of my 9600M GT GPU, which I learned by inspecting the output of lspci. The trick here is getting the GPU into the proper state before the nouveau module is loaded. I've found that the internal state of the GPU can frequently be inconsistent across reboots making troubleshooting difficult. Resetting and then rescanning it before loading nouveau seems to solve things for every scenario I've tested. With the above workaround I can start a display manager (GDM for gnome 3.14.2) and everything seems to work as expected, ex. glxgears. The 9400M GPU can optionally be disabled between steps (3) and (4): 'echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove' where 0000:03:00.0 is the PCI address of my 9400M.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>