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 [details]
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: