I am having similar issues on an ASUS GL504GM (Intel i7 8570H, Nvidia GTX1060) on Linux 4.19.5. My system is stable with the nouveau driver if I use acpi_osi=! acpi_osi="Windows 2009", or if I patch SSDT9 (it appears to handle the dGPU power management) by removing any code conditional on OSI > 2009. However, in that case, the power draw of the laptop is around 28W when the Nvidia GPU is powered off (state DynPwr according to vga_switcheroo), which is lower than the 43W drawn when the Nvidia GPU is powered on, but higher than the 16W drawn with an unpatched SSDT9 and no acpi_osi setting. The latter configuration locks up on lspci or when initiating suspend or poweroff.
So the GPU seems to have 3 distinct power states (of course, the proprietary nvidia driver can set lots of different clock speeds that nouveau cannot, but they only come into play when the dGPU is turned on): 1. Fully powered off via ACPI. 2. Partially powered off by vga_switcheroo. 3. Fully powered on. In states 1 and 2, vga_switcheroo reports DynOff, while in state 3 it reports DynPwr. In contrast, bbswitch reports OFF only in state 1, and reports ON in states 2 and 3. It is possible to reach state 1 using bbswitch, but it leads to an unstable system even with the patched SSDT9. After applying patches https://bugzilla.kernel.org/attachment.cgi?id=278269 and https://bugzilla.kernel.org/attachment.cgi?id=278773, my system is stable after booting up and the card is actually in state 1 (I can check the state by looking at the power draw). After a suspend-resume cycle, the card is in state 2. It is possible to return to state 1 by "power cycling" the card: I run DRI_PRIME=1 glxgears to power the card on for PRIME offload and then exit glxgears to power it down. The suspend- resume-offload-exit cycle can be repeated without locking up the system, and lspci also works. The situation is less rosy if I try to connect an external monitor. If I plug in my monitor to the HDMI port, which is wired to the Nvidia GPU, when the card is in state 1, the system locks up. I can avoid the lockup and use the external monitor if I run DRI_PRIME=1 glxgears to put the card into state 3 while plugging in the HDMI cable. After that, gxgears may be exited and the HDMI output continues to function. However, after removing the external monitor this dance cannot be repeated: my monitor just displays "Unsupported output format", as if the card's internal state were corrupted and it sent garbage to the HDMI port. Although some parts of the card must be working correctly because even in this state I can run DRI_PRIME=1 glxgears without problems and see the gears spinning on the internal display of the laptop. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1803179 Title: System does not reliably come out of suspend To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1803179/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
