Bug 106804

Summary: i195: modesetting stops working on kernel 4.17, works fine on 4.16
Product: DRI Reporter: Arkadiusz Miskiewicz <arekm>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard: Triaged, ReadyForDev
i915 platform: i915 features:
Attachments:
Description Flags
xorg log
none
dmesg with debug
none
drm debug 0x1f none

Description Arkadiusz Miskiewicz 2018-06-04 04:32:35 UTC
Created attachment 140000 [details]
xorg log

xserver 1.20, kernel 4.17 and modesetting fails:

[   126.170] (EE) modeset(0): failed to set mode: Invalid argument

while it works fine on 4.16 kernel.

Bisected to commit below and indeed, reverting it on current
kernel git makes the problem go away.



commit e995ca0b8139c5f6807095464e969931b443f55a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Nov 14 20:32:58 2017 +0200

    drm/i915: Provide a device level .mode_valid() hook
    
    We never support certain mode flags etc. Reject those early on in the
    mode_config.mode_valid() hook. That allows us to remove some duplicated
    checks from the connector .mode_valid() hooks, and it guarantees that
    we never see those flags even from user mode as the
    mode_config.mode_valid() hooks gets executed for those as well.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-11-ville.syrjala@linux.intel.com
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 1 Arkadiusz Miskiewicz 2018-06-04 04:35:32 UTC
From strace:

1880  ioctl(14, DRM_IOCTL_I915_GEM_MMAP <unfinished ...>
1895  <... read resumed> 0x2163e98, 7752) = -1 EAGAIN (Resource temporarily unavailable)
1880  <... ioctl resumed> , 0x7ffe47fdf6b0) = 0
1895  read(37, 0x2163e80, 7776)         = -1 EAGAIN (Resource temporarily unavailable)
1895  read(37, 0x2163e68, 7800)         = -1 EAGAIN (Resource temporarily unavailable)
1895  read(37,  <unfinished ...>
1880  ioctl(16, DRM_IOCTL_MODE_LIST_LESSEES <unfinished ...>
1895  <... read resumed> 0x2163e50, 7824) = -1 EAGAIN (Resource temporarily unavailable)
1880  <... ioctl resumed> , 0x7ffe47fdf9a0) = 0
1880  ioctl(16, DRM_IOCTL_MODE_LIST_LESSEES, 0x7ffe47fdf9a0) = 0
1880  ioctl(14, DRM_IOCTL_MODE_DIRTYFB, 0x7ffe47fdf980) = -1 ENOENT (No such file or directory)
1880  ioctl(14, DRM_IOCTL_MODE_SETGAMMA <unfinished ...>
1895  write(22, "\0", 1)                = 1
1895  epoll_wait(25,  <unfinished ...>
1880  <... ioctl resumed> , 0x7ffe47fdf8e0) = 0
1880  ioctl(14, DRM_IOCTL_MODE_ADDFB2, 0x7ffe47fdf6e0) = 0
1880  ioctl(14, DRM_IOCTL_MODE_CREATEPROPBLOB, 0x7ffe47fdf740) = 0
1880  ioctl(14, DRM_IOCTL_MODE_ATOMIC, 0x7ffe47fdf7f0) = -1 EINVAL (Invalid argument)
1880  write(4, "[   126.170] ", 13)     = 13
1880  write(4, "(EE) modeset(0): failed to set mode: Invalid argument\n", 54) = 54
1880  epoll_wait(3, [{EPOLLIN, {u32=31794656, u64=31794656}}], 256, 599996) = 1
Comment 2 Maarten Lankhorst 2018-06-04 07:58:58 UTC
drm.debug=0x1f ?
Comment 3 Arkadiusz Miskiewicz 2018-06-04 08:01:48 UTC
Created attachment 140001 [details]
dmesg with debug
Comment 4 Arkadiusz Miskiewicz 2018-06-04 08:04:00 UTC
That was done back then but with 0xe, is that enough?
Comment 5 Maarten Lankhorst 2018-06-04 08:26:52 UTC
0x1f gives slightly more useful information.
Comment 6 Arkadiusz Miskiewicz 2018-06-04 08:40:23 UTC
Created attachment 140003 [details]
drm debug 0x1f
Comment 7 Maarten Lankhorst 2018-06-04 10:00:39 UTC
Do you happen to have the Xorg log from the same run? I want to see the timing of Xorg.0.log versus that dmesg, so I can see where it fails exactly on what call.
Comment 8 Maarten Lankhorst 2018-06-04 10:06:22 UTC
hm then again guessing it's the first atomic call that fails with -22, probably in drm_mode_convert_umode from drm_atomic_set_mode_prop_for_crtc.

Probably intel_mode_valid that fails, could you dump mode->flags ?
Comment 9 Maarten Lankhorst 2018-06-04 10:11:10 UTC
Oh nm, the clue is in the Xorg log..

[   123.751] (II) modeset(0): Printing probed modes for output eDP-1
[   123.751] (II) modeset(0): Modeline "1920x1080"x120.0  356.38  1920 2080 2288 2656  1080 1081 1084 1118 doublescan -hsync +vsync (134.2 kHz UdP)
[   123.751] (II) modeset(0): Modeline "3200x1800"x60.0  373.25  3200 3248 3280 3360  1800 1803 1808 1852 -hsync -vsync (111.1 kHz eP)
[   123.751] (II) modeset(0): Modeline "3200x1800"x60.0  492.00  3200 3456 3800 4400  1800 1803 1808 1865 -hsync +vsync (111.8 kHz d)
[   123.751] (II) modeset(0): Modeline "3200x1800"x59.9  373.00  3200 3248 3280 3360  1800 1803 1808 1852 +hsync -vsync (111.0 kHz d)

doublescan being set somehow..
Comment 10 Ville Syrjala 2018-06-04 10:26:53 UTC
Possibly fixed by:
https://patchwork.freedesktop.org/patch/225189/

The bigger mystery is why modesetting would default to a dblscan mode. That makes no sense. Sadly our debugs for atomic are woefully inadequate so the logs don't contain the reason for the failure :(
Comment 11 Arkadiusz Miskiewicz 2018-06-04 11:10:39 UTC
That patch fixes it for me.

No xorg.log from the same run but can make it if needed.
Comment 12 Arkadiusz Miskiewicz 2018-06-04 11:13:41 UTC
btw. this laptop has native 3200x1800 screen resolution but I'm using:

               Modes   "1920x1080"

in xorg.conf
Comment 13 Maarten Lankhorst 2018-06-04 11:37:15 UTC
Ah, that is the missing piece why it chooses that mode.
X.org is borked and just sets doublescan/interlaced is always possible with modesetting:
    output->interlaceAllowed = TRUE;
    output->doubleScanAllowed = TRUE;

And because it has the highest clock, you get your 1920 mode with doublescan..
Comment 14 Ville Syrjala 2018-06-04 11:43:08 UTC
(In reply to Maarten Lankhorst from comment #13)
> Ah, that is the missing piece why it chooses that mode.
> X.org is borked and just sets doublescan/interlaced is always possible with
> modesetting:
>     output->interlaceAllowed = TRUE;
>     output->doubleScanAllowed = TRUE;
> 
> And because it has the highest clock, you get your 1920 mode with
> doublescan..

Also the mode flags aren't even checked by the xf86DefaulltModes stuff. So even if we set doubleScanAllowed=FALSE we'd still get doublescan modes in the list :(
Comment 15 Ville Syrjala 2018-06-13 18:11:29 UTC
commit e4dd27aadd205417a2e9ea9902b698a0252ec3a0
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu May 24 15:54:03 2018 +0300

    drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI
Comment 16 Arkadiusz Miskiewicz 2018-06-13 19:46:11 UTC
Push it to -stable please.
Comment 17 Ville Syrjala 2018-06-21 13:24:01 UTC
(In reply to Arkadiusz Miskiewicz from comment #16)
> Push it to -stable please.

The patch has cc:stable, so it'll get there eventually.

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.