• LINUX

Lenovo Intel i915 Video Drivers in Linux, Part 2

#linux , #intel , #i915 , #video , #T460s , #Lenovo

Lenovo Intel i915 Video Drivers in Linux, Part 2

Problem Scenario/Steps:
Lenovo T460s
thinkpad ultra dock P/N SD20A06046 Type 40A2 S/N M3-A0AC8E 16/11+ fedora 26/27/28/29, according to my records any kernel since 4.15.9-300.fc27.x86_64

  1. Dock laptop in docking station with two connected monitors, one HDMI and one DVI.

  2. Undock laptop.

  3. Redock laptop → screen failure and system lock until undock again. Leave it long enough and it will reboot itself.

Interestingly enough for myself, I have another docking station with two DisplayPort monitors that does not produce this problem.

In Part 1, I ended up with a somewhat misdirected analysis. So here is the new working solution I have come up with.

I had still been having problems getting the video drivers to work correctly the second time I docked my laptop. See these bugs for similar descriptions and issues.

I had a few options to consider for debugging this problem:

  1. Update to latest stable fedora release and kernel.

    1. Update to vanilla kernel options.

    2. Build custom drm module for current fedora kernel.

  2. Update to rawhide fedora release and kernel.

    1. Build custom drm module for rawhide fedora kernel.

Since I was recently on fedora 28, I figured the best next step is to update to the latest fedora 29. I ran my test against fedora 29 and found no change. The next step was either to remain at fedora 29 and test with a later unsupported kernel or upgrade to fedora 30 or rawhide, both of which are in current development as I write this article. Obviously none of this is supported. Wait a minute, does anyone actually care about fedora support? Nah, I didn’t think so. Let’s just go with fedora 29 and a cutting edge kernel. That puts the system at a stable point and the kernel at an unstable point. Maybe that’s better than both at an unstable point, but I don’t care since I’m just testing stuff out and would like to have a stable system to revert back to.

I built kernel from drm-tip, where we have the latest and greatest from the development teams. I used documentation from intel, although the steps for building a custom kernel are pretty generic. I didn’t need to test any of the other drivers or libraries.

On my first kernel boot I made no custom changes, using the default generated .config file (created by the make defconfig step).

However I got an error from LUKS after entering my disk encryption password.

         Starting Cryptography Setup for luks-48ef18c-7da6-4260-942b-2a203048b76f...
[FAILED] Failed to start Cryptography Setup for luks-48ef18c-7da6-4260-942b-2a203048b76f.
See 'systemctl status "systemd-cryptsetup@luks\\x2d48e8f18c\\x2d7da6\\x2d4260\\x2d942b\\x2d2a203048b76f.service"' for details.
[DEPEND] Dependency failed for Local Encrypted Volumes.

Since the panic did not leave me at a command prompt, nor did I figure there were any actual journals recording this event, I just popped back to the working kernel and tested output there to see what it should look like in a success.

[bward@archimedes 2018]$ systemctl status systemd-cryptsetup@luks\\x2d48e8f18c\\x2d7da6\\x2d4260\\x2d942b\\x2d2a203048b76f.service
● systemd-cryptsetup@luks\x2d48e8f18c\x2d7da6\x2d4260\x2d942b\x2d2a203048b76f.service - Cryptography Setup for luks-48e8f18c-7da6-4260-942b-2a203>
   Loaded: loaded (/etc/crypttab; generated)
   Active: active (exited) since Wed 2019-01-02 21:58:45 EST; 4min 12s ago
     Docs: man:crypttab(5)
           man:systemd-cryptsetup-generator(8)
           man:systemd-cryptsetup@.service(8)
 Main PID: 428 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/system-systemd\x2dcryptsetup.slice/systemd-cryptsetup@luks\x2d48e8f18c\x2d7da6\x2d4260\x2d942b\x2d2a203048b76f.service

Jan 02 21:58:35 archimedes.home.dataxf.com systemd[1]: Starting Cryptography Setup for luks-48e8f18c-7da6-4260-942b-2a203048b76f...
Jan 02 21:58:35 archimedes.home.dataxf.com systemd[1]: systemd-cryptsetup@luks\x2d48e8f18c\x2d7da6\x2d4260\x2d942b\x2d2a203048b76f.service: Curre>
Jan 02 21:58:43 archimedes.home.dataxf.com systemd-cryptsetup[428]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-u>
Jan 02 21:58:45 archimedes.home.dataxf.com systemd[1]: Started Cryptography Setup for luks-48e8f18c-7da6-4260-942b-2a203048b76f.

At this point I don’t know much about the internals of LUKS and its service, but I do know how to configure it when building a fedora system. However, documenation for LUKS on fedora is flat-out awful. Even worse is figuring out how to build a custom kernel with LUKS. I basically ran trial and error with some hints here and there from other people’s problems found by your favorite search engine.

Kernel configuration changes are made in the .config file.

I tried setting the following…​

CONFIG_DM_CRYPT=y

But that alone did not work. Then I tried this…​

# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
CONFIG_CRYPTO_SHA512=y

But it corrected itself to this…​

CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y

It still did not work. But I got a different error this time. It seems I got a little farther!

[   24.868618] device-mapper: table: 253:0 crypt: Error allocating crypto tfm
[   24.869944] device-mapper: ioctl: error adding target to table

So let’s see what other configuration settings were missing. Maybe looking a the original crytography setup (using my good kernel) will tell me something:

[root@archimedes drm-tip]# cryptsetup status luks-48e8f18c-7da6-4260-942b-2a203048b76f
/dev/mapper/luks-48e8f18c-7da6-4260-942b-2a203048b76f is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sda2
  sector size:  512
  offset:  4096 sectors
  size:    998111232 sectors
  mode:    read/write

Searching around on the internet shows some aes-xts-plain64 things…​ let’s set that value…​

CONFIG_CRYPTO_XTS=y

Bingo that worked!!

Here are the results from the latest drm-tip build:

  1. first outputs of i915 in dmesg (no debug)

    [bward@archimedes 2019]$ dmesg | grep i915
[    1.608743] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    1.609003] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_27.bin failed with error -2
[    1.609006] i915 0000:00:02.0: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling runtime power management.
[    1.609009] i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    1.631612] [drm] Initialized i915 1.6.0 20181221 for 0000:00:02.0 on minor 0
[    3.239497] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

  2. Docked it and searched again.

    [bward@archimedes 2019]$ dmesg | grep i915
[    1.608743] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    1.609003] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_27.bin failed with error -2
[    1.609006] i915 0000:00:02.0: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling runtime power management.
[    1.609009] i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    1.631612] [drm] Initialized i915 1.6.0 20181221 for 0000:00:02.0 on minor 0
[    3.239497] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

  3. Screen undocked and searched again

    [bward@archimedes 2019]$ dmesg | grep i915
[    1.608743] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    1.609003] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_27.bin failed with error -2
[    1.609006] i915 0000:00:02.0: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling runtime power management.
[    1.609009] i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    1.631612] [drm] Initialized i915 1.6.0 20181221 for 0000:00:02.0 on minor 0
[    3.239497] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

  4. Screen docked a second time. Holy shit it works. Someone already fixed my problem!!!

    [bward@archimedes 2019]$ dmesg | grep i915
[    1.608743] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    1.609003] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_27.bin failed with error -2
[    1.609006] i915 0000:00:02.0: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling runtime power management.
[    1.609009] i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    1.631612] [drm] Initialized i915 1.6.0 20181221 for 0000:00:02.0 on minor 0
[    3.239497] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

Just in case you don’t believe me…​

[bward@archimedes 2019]$ uname -a
Linux archimedes.home.dataxf.com 4.20.0+ #4 SMP Wed Jan 2 22:54:25 EST 2019 x86_64 x86_64 x86_64 GNU/Linux

This is the commit I built from…​

commit c6a0276a5007c01c64a8a80552b78c115e8a0dae (HEAD -> drm-tip, origin/drm-tip, origin/HEAD)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jan 2 12:26:48 2019 +0000

    drm-tip: 2019y-01m-02d-12h-25m-13s UTC integration manifest

Patch the 4.19 and 4.18 kernels with the appropriate fixes, starting from https://patchwork.freedesktop.org/patch/261135/.

This issue was resolve by the 4.20 kernel release.