Issues with Lenovo T490 and (X)Ubuntu 19.10

Update 2020-03-12: X.Org sluggishness, Fan

Update 2020-05-09: Upgrade to Xubuntu 20.04 LTS fixed most issues

My company notebook is a brand new Lenovo T490 with 8 Gigabytes of RAM:

• Type 20N2-CTO1WW
• Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
• Intel Corporation UHD Graphics 620 (Whiskey Lake) (rev 02)

I replaced Windows 10 after a week with the most up-to-date Xubuntu which is based on Ubuntu 19.10. That's basically a normal Ubuntu with the Xfce environment instead of Ubuntu's GNOME decision.

Although I'm using GNU/Linux for decades, I can hardly remember running a system which is as unstable as this one. In this blog article, I summarize my current issues just to give others a landing page with my findings in case they face similar problems.

This is a general issue of (X)Ubuntu 19.10 and not specific to this hardware. I though I add it here in order to warn others before they set up their system.

If you do trust the setup routine of (X)Ubuntu 19.10 to setting up your hard disk partitioning, you will end up with only one Gigabyte of swap space.

This caused my system to hard crash when I tried to start LibreOffice or VirtualBox. Both consuming a considerable amount of RAM. With my limit of eight Gigabytes of physical RAM, this resulted in swapping. When the 1GB swap space was used up, Linux is crashing instantly. Not good.

You should not allow (X)Ubuntu to partition your hard disk. Do it on your own. Choose a swap partition size which is at least as large as your RAM. This way, you also enable suspend to disk which otherwise does not work as well.

For mitigating the crashes, I had to add additional swap space using a method similar to this. Since this additional swap file is a regular file on my LUKS-encrypted partition, I can not use suspend to disk with it. To fix this, I would have had to re-partition everything to get more space for a regular swap partition. I did not want to go through this hell: either resizing LUKS and the partition plus make bootable again with risking my whole data or starting from scratch and re-configuring from scratch in any case.

So, back to issues that are more related to the Lenovo T490.

Sometimes five times an hour, sometimes not for days, the system freezes and then continues working without any issue.

The syslog contains many lines like this:

Jan 23 10:50:11 hostname kernel: [212252.789082] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Jan 23 10:50:19 hostname kernel: [212260.788958] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Jan 23 10:50:45 hostname kernel: [212286.804494] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Jan 23 10:50:53 hostname kernel: [212294.804349] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0	  

According to this, it is an issue with intel GPU and also depends on external monitor. Some people also report that it also depends on software being run ("troubles in using IntelliJ IDEA").

This bug report says that it is fixed with Linux kernel 5.4.0. A similar issue is reported here. The patched 5.4.14 is reported to be fine but some people still reported the issue with the patched kernel.

I'm waiting for the Xubuntu 20.04 update which should contain kernel 5.5.

At least, this is an issue that I can live with for a certain period of time.

What's more compelling to me are - so far - four crashes of X.Org, the graphical subsystem of GNU/Linux. Without any upfront indication, the Xfce login screen appears while working with the computer. This way, everything not saved gets lost when apps are "closed".

The syslog shows normal output until, for example:

Feb 10 16:11:06 hostname kglobalaccel5[350]: kglobalaccel5: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Feb 10 16:11:06 hostname org.kde.ActivityManager[2438]: The X11 connection broke (error 1). Did the X11 server die?
Feb 10 16:11:06 hostname pulseaudio[2408]: X connection to :0.0 broken (explicit kill or server shutdown).
Feb 10 16:11:06 hostname at-spi-bus-launcher[2530]: X connection to :0 broken (explicit kill or server shutdown).
Feb 10 16:11:06 hostname [2763]: xfce4-notifyd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Feb 10 16:11:06 hostname systemd[2385]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE
Feb 10 16:11:06 hostname systemd[2385]: xfce4-notifyd.service: Failed with result 'exit-code'.
Feb 10 16:11:06 hostname systemd[2385]: pulseaudio.service: Main process exited, code=exited, status=1/FAILURE
Feb 10 16:11:06 hostname systemd[2385]: pulseaudio.service: Failed with result 'exit-code'.
Feb 10 16:11:07 hostname systemd[2385]: pulseaudio.service: Service RestartSec=100ms expired, scheduling restart.
Feb 10 16:11:07 hostname systemd[2385]: pulseaudio.service: Scheduled restart job, restart counter is at 1.
Feb 10 16:11:07 hostname systemd[2385]: Stopped Sound Service.
Feb 10 16:11:07 hostname systemd[2385]: Starting Sound Service...
[...]	  

Therefore, I don't get any error message that might give me a hint what's going on here.

I had to configure my emacs so that it saves each buffer every five minutes to minimize data loss. The first time that happened, I've lost a couple of hours of work. There is hardly anything that makes me more frustrated than having to invest the same effort twice for no reason.

Since I can not debug this any further, I hope that the (X)Ubuntu 20.04 LTS upgrade will fix that.

My device is going to suspend (to RAM) after a while being in idle mode. I also put my device to suspend mode over night or when traveling.

In three instances, the resume did end up with non-working mouse/trackpoint and keyboard on the login prompt. Internal as well as external. I assume this applies to the whole HCI stack. Maybe it affects all devices connected via USB?

Either way. The first time, I had to reboot in order to get back a working environment. However, I could switch to the text console via Ctrl-Alt-F3 and log in. So no total loss of keyboard. Once logged in, killing the xfce4-screensaver allowed me to continue. However, (auto-)lock of the screen is gone with killing the screensaver process.

The second time, plugging in and out my D6000 docking station caused the devices to resume.

Following incidents, I always had to kill the xfce4-screensaver process.

Very unfortunate.

I hope (X)Ubuntu 20.04 LTS will cause a positive effect here as well.

The media featured the news already: Some Lenovo devices get severe hardware failure because of a BIOS bug. The T590 is part of this misery.

I guess it is because I was using Windows 10 for the first week on that device that I already got the firmware update to version 20.00 which is already patched.

My brother has a T490 with 16 GB of RAM. He had severe issues with this firmware upgrade, which looked like bricking his device: black screens, weird BIOS auto-healing processes, necessity of hard resets (there's a hardware reset hole at the bottom of the T490!), ...

I'm glad that I did not have to use the shaky Linux firmware workflow in order to avoid hardware failure.

After working a couple of hours, X.Org sometimes starts to feel sluggish. I noticed that the /usr/lib/xorg/Xorg process is consuming constantly six to eight percent of a CPU core. To me, this is unusual.

Maybe this is also the reason why the fan is quite noisy almost all the time. When nothing is going on, the fan may sleep for a minute or so. But then it starts to make noise again although the system load was not affected by the user and my CPU load visualization widget does not show much of an activity.

Things like this decrease the user happiness factor.

However, there are reports on the Internet where people got constantly running fans with BIOS upgrades and so forth. Thankfully, this is not the case here.

Sorry when you thought that I've solutions for all these issues yet. I just wanted to write down the current situation also for myself. This is a good future reference in case I tend to think that GNU/Linux on a Lenovo is almost a guarantee for a stable working environment. It is not.

This came to my surprise because my private Lenovo X-Series (X61, X220, and X260 on various Xubuntu LTS) as well as my intel NUC i5 (Debian 9.0 Stretch) did and do provide me really stable GNU/Linux environments.

Meanwhile, Xubuntu 20.04 LTS (based on Ubuntu 20.04 LTS Focal Fossa) was released. I upgraded my system right after its official release date. The upgrade process was good. Just some minor issues I could easily fix afterwards.

The good news after two weeks of running the new system is that most of the issues above got fixed in the meantime:

• No short-period freezes.
• X.Org didn't crash any more.
• Keyboard/mouse did fine after resuming the system.
• Fan noise did not bother me that often.
• X.Org sluggishness vanished after getting rid of snap.

Be careful because Ubuntu 20.04 introduced more snap packages. On my todo-list, there is a task to purging snap completely from my system.

I found this German howto which I translated to:

1. Locate installed snaps via snap list
2. Uninstall snaps via sudo snap remove <package>
3. Remove snapd with sudo apt purge snapd
4. Remove snap directories in your $HOME with rm -rf ~/snap
5. If you face an issue while removing snap, you can try sudo rm -rf /var/cache/snapd followed by sudo apt purge snapd

It looks to me that my lenovo T490 got its GNU/Linux support one year after its release. I thought that especially this device is popular among GNU/Linux developers. Therefore, support should have hit the popular GNU/Linux distributions way faster.

This might indicate that you still have to be careful with brand new hardware and GNU/Linux.