Bug 1177177

Summary:	xf86-video-intel: Resuming from suspend results in a freeze on newer Intel GPU (0x0f31), but works fine with modesetting driver
Product:	[openSUSE] openSUSE Distribution	Reporter:	Tristan Miller <psychonaut>
Component:	X.Org	Assignee:	Gfx Bugs <gfx-bugs>
Status:	RESOLVED WONTFIX	QA Contact:	Gfx Bugs <gfx-bugs>
Severity:	Critical
Priority:	P3 - Medium	CC:	bjoernv, fvogt, psychonaut
Version:	Leap 15.2
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	journalctl output for an occasion when this bug occurred

Description Tristan Miller 2020-10-01 09:35:19 UTC

Created attachment 842151 [details]
journalctl output for an occasion when this bug occurred

I use KDE Plasma on openSUSE 15.2. After resuming my computer from a suspend, the login screen appears but sometimes becomes unresponsive within a few seconds (usually in the middle of me typing my password, but sometimes earlier).  The problem occurs seemingly at random, about 10% of the time after resuming from a suspend.

Once the login screen is frozen like this, I can still move the mouse pointer around the screen, though it does not respond to any mouse clicks or any further keyboard input.  It is still possible to switch to a TTY with Ctrl+Alt+F1 and then log into the console.  From there, trying to manually unlock the Plasma session using "loginctl unlock-session n" (where n is the session number) has no effect.  Trying to force a logout using "qdbus org.kde.ksmserver /KSMServer logout 0 0 0", or doing a killall of all my user processes, or restarting the X Display Manager with "rcxdm restart", or switching to runlevel 3 and then back to runlevel 5, never fully solve the problem.  Sometimes these measures (alone or in combination) return me to the SDDM login screen, but if I try to log in again, the Plasma panel and desktop fail to appear, making the system almost unusable.  Even trying to force a shudown or reboot with "shutdown -h now" or "shutdown -r now" sometimes doesn't work -- even after waiting several minutes, the system never powers off or resets, and I have to end up holding down the power button.  This suggests a rather low-level problem (maybe in the kernel?) that is possibly being triggered by something in kscreenlocker, though since I don't use other desktop environments I'm not sure if the problem is specific to KDE Plasma.

Many other people have reported similar issues against kscreenlocker upstream at <https://bugs.kde.org/show_bug.cgi?id=395583>.

The problem started occurring very soon after I upgraded from openSUSE 15.1 to openSUSE 15.2.  The problem never occurred with openSUSE 15.1 or earlier.

Attached is the output of journalctl for one occasion when this bug occurred for me.  Here is a high-level timeline:

08:00:16 I suspend my computer by pressing the suspend key.

08:24:29 I wake up my computer.  The login screen appears but after typing the first couple 
characters of my password, the login screen becomes unresponsive.

08:24:42 I switch to tty1 and log in as root (and do the same on tty2) and then issue a shutdown -r command.

08:26:24 The system reboots.

Perhaps something in this log indicates what the problem might be.

Comment 1 Fabian Vogt 2020-10-01 09:49:39 UTC

Probably graphics driver issues. Do you use intel or nvidia?
Does Ctrl-Alt-BkSp+BkSp work to quit X?

Comment 2 Tristan Miller 2020-10-01 10:00:10 UTC

I'm using the Intel driver, and yes, Ctrl+Alt+Backspace can still kill the X server when the login screen has frozen.

Comment 3 Fabian Vogt 2020-10-01 10:02:50 UTC

(In reply to Tristan Miller from comment #2)
> I'm using the Intel driver, and yes, Ctrl+Alt+Backspace can still kill the X
> server when the login screen has frozen.

Ok. If you have xf86-video-intel installed, remove it. If not, install it. Does the situation change?

Comment 4 Tristan Miller 2020-10-01 10:24:46 UTC

Yes, I had xf86-video-intel-2.99.917+git8674.25c9a2fcc-lp152.3.7 installed.  I removed it and rebooted, and then suspended and resumed by computer 30 times without encountering the bug.  So you are probably right about the problem being linked to the video driver.

Comment 5 Fabian Vogt 2020-10-01 10:58:11 UTC

(In reply to Tristan Miller from comment #4)
> Yes, I had xf86-video-intel-2.99.917+git8674.25c9a2fcc-lp152.3.7 installed. 
> I removed it and rebooted, and then suspended and resumed by computer 30
> times without encountering the bug.  So you are probably right about the
> problem being linked to the video driver.

The xf86-video-intel driver is deprecated and won't work with newer hardware, so that's probably just a symptom of that. Reassigning.

Comment 6 Stefan Dirsch 2020-10-01 11:08:02 UTC

This driver is only meant for older Intel GPUs. Could you please add the output when runnning 

  hwinfo --gfxcard

as root? Thanks!

Comment 7 Tristan Miller 2020-10-01 11:35:56 UTC

(In reply to Stefan Dirsch from comment #6)
> Could you please add the output when runnning 
> 
>   hwinfo --gfxcard
> 
> as root? Thanks!

17: PCI 02.0: 0300 VGA compatible controller (VGA)
  [Created at pci.386]
  Unique ID: _Znp.mmNJ9QS5Da0
  SysFS ID: /devices/pci0000:00/0000:00:02.0
  SysFS BusID: 0000:00:02.0
  Hardware Class: graphics card
  Model: "Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x0f31 "Atom Processor Z36xxx/Z37xxx Series Graphics & Display"
  SubVendor: pci 0x1025 "Acer Incorporated [ALI]"
  SubDevice: pci 0x0860 
  Revision: 0x0e
  Driver: "i915"
  Driver Modules: "i915"
  Memory Range: 0x90000000-0x903fffff (rw,non-prefetchable)
  Memory Range: 0x80000000-0x8fffffff (ro,non-prefetchable)
  I/O Ports: 0x2050-0x2057 (rw)
  Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled)
  IRQ: 94 (16868 events)
  Module Alias: "pci:v00008086d00000F31sv00001025sd00000860bc03sc00i00"
  Driver Info #0:
    Driver Status: i915 is active
    Driver Activation Cmd: "modprobe i915"
  Config Status: cfg=no, avail=yes, need=no, active=unknown

Primary display adapter: #17

Comment 8 Tristan Miller 2020-10-01 11:45:09 UTC

The machine is about six years old, running one of these processors (with onboard graphics): <https://ark.intel.com/content/www/us/en/ark/compare.html?productIds=81074>  I'm not sure whether you count that as "older" hardware or not.

Comment 9 Stefan Dirsch 2020-10-01 14:38:10 UTC

No, that's not such an old hardware. xf86-video-intel package shouldn't be installed by default during a new installation. Most likely you were updating from a newer openSUSE release (in this case we don't uninstall this package assuming the driver is still working; well - apparently not in your case) and now you stumbled across a regression in the driver. But since our default "modesetting" driver works for you nothing needs to be done here.

Comment 10 Stefan Dirsch 2020-10-01 14:41:52 UTC

wontfix ...

Comment 11 Tristan Miller 2020-10-01 14:49:53 UTC

OK, I will inform the people discussing the same issue on the KDE Bugzilla in case the cause of the lockup is the same for some or all of them.

Would it be helpful to report this issue to the xf86-video-intel developers?

Comment 12 Stefan Dirsch 2020-10-01 18:16:27 UTC

(In reply to Tristan Miller from comment #11)
> OK, I will inform the people discussing the same issue on the KDE Bugzilla
> in case the cause of the lockup is the same for some or all of them.
> 
> Would it be helpful to report this issue to the xf86-video-intel developers?

Unfortunately no. It's unlikely they will still look into issues, which do not exist when using modeset driver.