http://bugzilla.opensuse.org/show_bug.cgi?id=1106842 Bug ID: 1106842 Summary: Hard freeze when using nouveau driver Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: xorg-maintainer-bugs@forge.provo.novell.com Reporter: tutux84@onenetbeyond.org QA Contact: xorg-maintainer-bugs@forge.provo.novell.com Found By: --- Blocker: --- Created attachment 781635 --> http://bugzilla.opensuse.org/attachment.cgi?id=781635&action=edit inxi Hi there, I have been using Leap 15 on my laptop (Kaby Lake, Optimus with GeForce GTX 1060 Mobile, see attachment for inxi output) with a lot of pleasure since its release until the beginning of August, where troubles started to happen with output rendering (I can't pinpoint an exact date nor kernel version unfortunately). The home setup was the laptop with an external monitor through HDMI. Single screen on the external monitor, the integrated screen was off as long as I was on home setup. Starting from beginning of August, when the screen would lock because of inactivity or because I locked the session myself (Gnome), the system would hard lock, and I would be forced to hard reboot the laptop. It seemed to occur after a few seconds or minutes. Not right after lockup. Example: manually locking then unlocking right after would be successful. But unfortunately I didn't play much with that part. At some point, I decided to open a ticket, but first do some test and see if the problem appears on the integrated screen. So I switched the screen roles in Gnome panel config (switch integrated screen on, switch external screen off). And now: 1) The laptop suffers of a hard lock systematically after loading the Gnome desktop (after entering credentials on GDM). Like 10-20 seconds. I'm forced to hard reboot it. 2) To avoid situation #1, I have to set nouveau.modeset=0 at boot in kernel parameters. I can tell that the issue does NOT happen when on single screen with the integrated one. Unlocking sessions is successful any time, however long the session remains locked. Note that there is also an up to date Tumbleweed system on this laptop that do NOT suffer such issue. In attachment, the inxi and journalctl of a debugging session. Some notes about journalctl: 19h50m00s - boot 19h51m00s to 05s - Gnome session loaded and hard locked. Mouse still moving. 19h52m00s - ctrl-alt-suppr (without any visible consequence) 19h52m25s - hard reboot by pushing the power button 19h52m50s to 19h54m05s - new boot and another hard reboot, but for a bug that would probably deserve a specific bug entry. You probably should skip this part for now. 19h55m00s to the end: a new boot, with kernel parameter to disable nouveau driver, if I recall correct. Any idea how to proceed to troubleshoot this issue further ? Thanks ! -- You are receiving this mail because: You are on the CC list for the bug.