Bug 110030 - regression bisected black screen with cursor
Summary: regression bisected black screen with cursor
Status: RESOLVED DUPLICATE of bug 109806
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-13 12:24 UTC by Manuel Mommertz
Modified: 2019-05-29 11:23 UTC (History)
3 users (show)

See Also:
i915 platform: SNB
i915 features: display/Other


Attachments
Xorg log (31.94 KB, text/x-log)
2019-03-13 12:24 UTC, Manuel Mommertz
no flags Details
dmesg output (231.78 KB, text/plain)
2019-03-13 12:24 UTC, Manuel Mommertz
no flags Details
test-patch (882 bytes, patch)
2019-03-15 09:09 UTC, Manuel Mommertz
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Mommertz 2019-03-13 12:24:06 UTC
Created attachment 143642 [details]
Xorg log

Problem: when connecting two displays and starting X, both screens are just black with a static (not blinking) text cursor in the top left corner. With only one display (does not matter which one was disconnected) X starts normal after reboot. Restarting X after connecting/disconnecting a display does not change the behavior, the system has to be rebooted.

d8a648cae347dcad29dc976a1970f503eb27febf is the first bad commit
commit d8a648cae347dcad29dc976a1970f503eb27febf
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Feb 15 12:30:19 2019 +0000

    drm/i915/fbdev: Actually configure untiled displays
    
    commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 upstream.

With this commit applied an additional line shows in /var/log/Xorg.0.log:
[    31.581] (EE) modeset(0): failed to set mode: Invalid argument

Apart from this, the file is identical with or without the commit. No differences in dmesg.
Comment 1 Manuel Mommertz 2019-03-13 12:24:40 UTC
Created attachment 143643 [details]
dmesg output
Comment 2 Lakshmi 2019-03-13 12:46:22 UTC
@Maarten, to me this issue is a duplicate of Bug 109806.
Comment 3 Maarten Lankhorst 2019-03-13 14:07:49 UTC
Likely, yes
Comment 4 Manuel Mommertz 2019-03-15 09:09:36 UTC
Created attachment 143674 [details] [review]
test-patch

I try to understand what exactly changed here so I looked into the sources. I have found that the association between connectors and crtcs changes due to the patch mentioned above. With the attached test-patch X works again and the debugging output shows the exchange of crtc-pointers between the connectors:

[    2.878198] [drm:drm_setup_crtcs [drm_kms_helper]] NOT WORKING: CONN 4 - crtc: ffffa36ef4054f48
[    2.878201] [drm:drm_setup_crtcs [drm_kms_helper]] NOT WORKING: CONN 5 - crtc: ffffa36ef4054f00
[    2.878205] [drm:drm_setup_crtcs [drm_kms_helper]] WORKING:     CONN 4 - crtc: ffffa36ef4054f00
[    2.878207] [drm:drm_setup_crtcs [drm_kms_helper]] WORKING:     CONN 5 - crtc: ffffa36ef4054f48

In the duplicate bug you said:
> Not a bug in the kernel, xorg's modesetting driver needs to set all
> connectors/crtc's directly when using atomic. The legacy path disabled crtc
> B for you if you stole all its connectors for a different crtc. In the
> atomic case you need to disable it yourself.
> 
> This is a bug in x.org's modesetting driver.

Though it seems to me this is not related here as there are no stolen connectors involved. And the source of the modesetting-driver from xorg already has a part that disables crtcs without connection (see https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesetting/drmmode_display.c line 778)

So do you say the right path from here is to let the modesetting driver change the association between the connectors and crtcs?
Comment 5 Maarten Lankhorst 2019-03-15 11:10:01 UTC
The pointers are just locations in memory, any difference in timing can cause them to change. :)

The xorg-modesetting driver needs to do the setup in 1 atomic commit, and disable unused crtc's when stealing connectors from them.
Comment 6 Manuel Mommertz 2019-03-15 11:57:16 UTC
(In reply to Maarten Lankhorst from comment #5)
> The pointers are just locations in memory, any difference in timing can
> cause them to change. :)

I know what pointers are. ;) The point is that the call to 'drm_pick_crtcs' switched the associated crtcs between the outputs (look at the test-patch, the addresses are from the same run; once before, once after call to the function). And with this call added, X starts as expected.

drm_pick_crtcs looks hard to find the best match between connector and crtc while intel_fb_initial_config just uses the first crtc that has a matching mode.

So without understanding what all this stuff is, I come to the conclusion that the right association between connector and crtc is essential.
If the kernel now does not try its best to find this right association, the modesetting driver has to do it. I have looked at the code, tried some changes but with no success. It is just to complex for me to understand enough to fix this myself. :/
Comment 7 Thomas Pfaff 2019-04-04 08:26:10 UTC
I have the same problem, but this time it is not related to a dual monitor configuration.

On my Pentium N3710 based notebook the X server does not start anymore too.
I made some investigations, and i guess its because after the patch another crtcs is choosen for the desired mode.

Before the patch intel_fb_initial_config always returned false, and drm_setup_crtcs is choosing crtc 46:pipe A which is fine for the X server.
[drm:intel_fb_initial_config [i915]] Not using firmware configuration
[drm:drm_setup_crtcs [drm_kms_helper]] looking for cmdline mode on connector 91
[drm:drm_setup_crtcs [drm_kms_helper]] looking for preferred mode on connector 91 0
[drm:drm_setup_crtcs [drm_kms_helper]] found mode 1366x768
[drm:drm_setup_crtcs [drm_kms_helper]] picking CRTCs for 8192x8192 config
[drm:drm_setup_crtcs [drm_kms_helper]] desired mode 1366x768 set on crtc 46 (0,0)

Now intel_fb_initial_config is returning true, but is choosing crtc 63 instead, and with crtc 63 the X server doesn't come up
[drm:intel_fb_initial_config [i915]] looking for cmdline mode on connector eDP-1
[drm:intel_fb_initial_config [i915]] looking for preferred mode on connector eDP-1 0
[drm:intel_fb_initial_config [i915]] connector eDP-1 on [CRTC:63:pipe B]: 1366x768
[drm:intel_fb_initial_config [i915]] connector DP-1 not enabled, skipping
[drm:intel_fb_initial_config [i915]] connector HDMI-A-1 not enabled, skipping
[drm:intel_fb_initial_config [i915]] connector DP-2 not enabled, skipping
[drm:intel_fb_initial_config [i915]] connector HDMI-A-2 not enabled, skipping
[drm:drm_setup_crtcs [drm_kms_helper]] desired mode 1366x768 set on crtc 63 (0,0)

So probably the patch itself is correct, but it breaks a previously running system, and i do not see any progress in the X server about an atomic commit.
There was some initial work according to
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36/commits
but the patches are pending for almost half year.
Comment 8 Lakshmi 2019-05-02 12:02:29 UTC
@Manuel, if this is a duplicate of Bug 109806 or  https://gitlab.freedesktop.org/xorg/xserver/issues/542 I can close this bug.
Comment 9 Manuel Mommertz 2019-05-02 14:39:37 UTC
As you said, it is very likely.
Comment 10 Lakshmi 2019-05-29 11:23:43 UTC
Closing this as duplicate of Bug 109806.
Please reopen this issue if you disagree.

*** This bug has been marked as a duplicate of bug 109806 ***


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.