Bug 109583 - Black screen on skylake after 18.0 => 18.2 update
Summary: Black screen on skylake after 18.0 => 18.2 update
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 18.3
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-08 08:04 UTC by Alkis Georgopoulos
Modified: 2019-02-14 12:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alkis Georgopoulos 2019-02-08 08:04:22 UTC
Several schools reported black screens after normally updating their Ubuntu boxes from 18.0.5-0ubuntu0~18.04.1 to 18.2.2-0ubuntu1~18.04.1.

Downgrading mesa fixes the problem.

lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) 	Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:8694] 	Kernel modules: i915

Unfortunately I can't find a lot of useful information, here are some bits:
 * systemctl --failed says "gpu-manager" and "lightdm" have failed
 * Xorg.log is clean: https://termbin.com/6l2b
 * dmesg too: https://termbin.com/ip4e
 * It happens on lightdm/MATE, I don't know about Ubuntu GNOME.
 * If one runs `xinit` from ssh, it fails with:
i965: Failed to submit batchbuffer: Invalid argument
Comment 1 Denis 2019-02-08 08:59:14 UTC
Hello Alkis, thank you for the report.
Do you know, what kernel version was used on those machines? It might be helpful also.

I have HD 520 graphic card, quite close to mentioned by you, so can try to reproduce
Comment 2 Alkis Georgopoulos 2019-02-08 09:04:12 UTC
Thank you Denis,

I tried with the following Ubuntu-built kernels, all having the issue:
4.15.0-45, 4.15.0-44, 4.15.0-20.

It happens on both 32bit and 64bit installations.

The failed units logs are:
systemctl status gpu-manager: https://termbin.com/kkix
systemctl status lightdm: https://termbin.com/ybev
lightdm.log: https://termbin.com/ssrb

The weird part is that I don't see xorg segfaults or /var/crash/* reports or anything, the only error I got was that xinit line that I mentioned, "i965: Failed to submit batchbuffer: Invalid argument"

I have the `lspci` results from 4 schools so far, they're all 8086:1912 (HD Graphics 530), although from different vendors, ASUS, Dell etc.
Comment 3 Alkis Georgopoulos 2019-02-08 09:10:38 UTC
The Ubuntu folks uploaded 18.3.3 in their ppa:ubuntu-x-swat/updates PPA for me to test with, and it has the exact same issue.
Comment 4 Chris Wilson 2019-02-08 09:21:41 UTC
Can you please:

$ echo 0xf > /sys/modules/drm/parameters/debug
$ xinit
$ echo 0 > /sys/modules/drm/parameters/debug
$ dmesg > dmesg.txt # and upload

Hopefully we remembered to tag the EINVAL.
Comment 5 Alkis Georgopoulos 2019-02-08 09:32:05 UTC
I used "/sys/module" instead of "/sys/modules":

$ echo 0xf /sys/module/drm/parameters/debug
$ xinit
i965: Failed to submit batchbuffer: Invalid argument
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

$ echo 0 /sys/module/drm/parameters/debug
$ dmesg | nc termbin.com 9999

https://termbin.com/fb2m

I don't see any additional messages though...
Comment 6 Alkis Georgopoulos 2019-02-08 09:33:24 UTC
Sorry, I forgot the >

Here's the correct log:
https://termbin.com/6n12
Comment 7 Chris Wilson 2019-02-08 09:48:56 UTC
(In reply to Chris Wilson from comment #4)
> Hopefully we remembered to tag the EINVAL.

[ 1494.995482] [drm:drm_ioctl [drm]] pid=2746, dev=0xe200, auth=1, DRM_IOCTL_MODE_CREATE_DUMB
[ 1494.995493] [drm:drm_ioctl [drm]] pid=2746, dev=0xe200, auth=1, DRM_IOCTL_MODE_CREATE_DUMB
[ 1494.995584] [drm:drm_ioctl [drm]] pid=2746, dev=0xe200, auth=1, I915_GEM_EXECBUFFER2_WR
[ 1494.995595] [drm:drm_ioctl [drm]] ret = -22

That'll be no then.
Comment 8 Alkis Georgopoulos 2019-02-08 12:40:27 UTC
I just tried with 4.18.0-14-generic, the same issue happens there as well.

And, another school reported the issue on HD Graphics 630:

root@pc02:~# lspci -nn -k | grep -A 2 VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev 04)         Subsystem: ASRock Incorporation HD Graphics 630 [1849:5912]         Kernel driver in use: i915
Comment 9 Timo Aaltonen 2019-02-08 13:20:57 UTC
one theory is that this is related to legacy bios boot
Comment 10 Sergii Romantsov 2019-02-08 13:53:21 UTC
Hello, Alkis.
Could you, please, try to use a kernel not less than v4.19.3?

And could you provide outputs of
/usr/bin/glxinfo -B
file /usr/bin/glxinfo
uname -a
Comment 11 Alkis Georgopoulos 2019-02-08 14:31:31 UTC
Hello Sergii,

I tried with 4.20.7 and it appears to work fine! Thanks!

Output of the commands:

# uname -a
Linux srv-6gym-chalk 4.20.7-042007-generic #201902061234 SMP Wed Feb 6 17:49:39 UTC 2019 i686 i686 i686 GNU/Linux

# file /usr/bin/glxinfo
/usr/bin/glxinfo: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6cef7eab38835376734bdc80c5ab1ee786a6157a, stripped

# glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) x86/MMX/SSE2 (0x1912)   
    Version: 18.3.3
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) x86/MMX/SSE2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 18.3.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Comment 12 Sergii Romantsov 2019-02-08 15:04:04 UTC
< I tried with 4.20.7 and it appears to work fine! Thanks!

You are welcome :)
So closing?
Comment 13 Alkis Georgopoulos 2019-02-08 15:19:30 UTC
I don't know the software stacks involved:

If I understood it correctly,
mesa 18.3.3 doesn't work with older kernels while 18.0 did work,
and so I'll do a bisection to see which kernel commit fixes the issue,
and then distro kernel maintainers may cherrypick it for older kernels.

If there's no need for mesa to work with older kernels without the cherrypicked commit, then I guess yes, this issue should be closed, in which case please close it for me or tell me to close it.

Thanks again!
Comment 14 Sergii Romantsov 2019-02-08 15:32:45 UTC
Most likely mesa were broken with commit:
commit a363bb2cd0e2a141f2c60be005009703bffcbe4e
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Apr 10 01:18:25 2018 -0700

    i965: Allocate VMA in userspace for full-PPGTT systems.


In the kernel (especially 32-bit) it requires such commits (all of them are present from kernel 4.19.3):
1. commit 0014868b9c3c1dda1de6711cf58c3486fb422d07
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 2 16:12:09 2018 +0000

    drm/i915: Mark pin flags as u64

2. commit 085603287452fc96376ed4888bf29f8c095d2b40
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 25 10:18:23 2018 +0100

    drm/i915: Compare user's 64b GTT offset even on 32b

3. commit c58281056a8b26d5d9dc15c19859a7880835ef44
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 25 10:18:22 2018 +0100

    drm/i915: Mark up GTT sizes as u64

4. commit 83b466b1dc5f0b4d33f0a901e8b00197a8f3582d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 2 16:12:09 2018 +0000

    drm/i915: Mark pin flags as u64


5. commit 6fc4e48f9ed46e9adff236a0c350074aafa3b7fa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 25 10:18:23 2018 +0100

    drm/i915: Compare user's 64b GTT offset even on 32b

So its question to Chris if he could propagate such commits into kernel. Because looks like even 4.15 is commonly used still.
Comment 15 Sergii Romantsov 2019-02-08 15:34:11 UTC
Most likely mesa were broken with commit:
commit a363bb2cd0e2a141f2c60be005009703bffcbe4e
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Apr 10 01:18:25 2018 -0700

    i965: Allocate VMA in userspace for full-PPGTT systems.


In the kernel (especially 32-bit) it requires such commits (all of them are present from kernel 4.19.3):
1. commit 0014868b9c3c1dda1de6711cf58c3486fb422d07
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 2 16:12:09 2018 +0000

    drm/i915: Mark pin flags as u64

2. commit 085603287452fc96376ed4888bf29f8c095d2b40
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 25 10:18:23 2018 +0100

    drm/i915: Compare user's 64b GTT offset even on 32b

3. commit c58281056a8b26d5d9dc15c19859a7880835ef44
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 25 10:18:22 2018 +0100

    drm/i915: Mark up GTT sizes as u64

4. commit 83b466b1dc5f0b4d33f0a901e8b00197a8f3582d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 2 16:12:09 2018 +0000

    drm/i915: Mark pin flags as u64


5. commit 6fc4e48f9ed46e9adff236a0c350074aafa3b7fa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 25 10:18:23 2018 +0100

    drm/i915: Compare user's 64b GTT offset even on 32b

So its question to Chris if he could propagate such commits into kernel. Because looks like even 4.15 is commonly used still.
Comment 16 Alkis Georgopoulos 2019-02-08 16:20:39 UTC
I tried a small kernel bisection using the ubuntu kernel binaries,
4.19.2-041902=fails,
4.19.3-041903=works
Comment 17 Timo Aaltonen 2019-02-08 17:18:00 UTC
4.15 is EOL upstream, but Canonical does pull patches from stable to the distro kernel in 18.04, I'm not sure why these never got in.. probably didn't apply cleanly.

anyway, I'll make sure they get applied eventually, but for now will disable softpin from mesa so that 32bit 18.04.2 image will work on gen8+

closing again, thanks!
Comment 18 Clayton Craft 2019-02-08 17:40:53 UTC
FWIW, I am not able to reproduce this issue on Arch Linux with Mesa 18.3.3 and kernel 4.18.16.
Comment 19 Alkis Georgopoulos 2019-02-14 12:19:36 UTC
Just correcting a wrong comment (#2) I made:
> It happens on both 32bit and 64bit installations.

I asked the school that reported the issue on 64bit to check again, and they said they have a 32bit installation after all.

So the problem has only been reported in 32bit installations; I don't know if it happened on 64bit. And btw everything is fixed now, thanks again to all. :)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.