Bug 109402 - modeset(0): failed to set mode: No such file or directory
Summary: modeset(0): failed to set mode: No such file or directory
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Dhinakaran Pandiyan
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-21 09:55 UTC by Kirill A. Shutemov
Modified: 2019-07-19 14:13 UTC (History)
3 users (show)

See Also:
i915 platform: SKL
i915 features: display/DP MST


Attachments
Xorg.0.lo (53.54 KB, text/x-log)
2019-01-21 09:55 UTC, Kirill A. Shutemov
no flags Details
dmesg with drm.debug=0x1e (471.71 KB, text/plain)
2019-01-21 09:55 UTC, Kirill A. Shutemov
no flags Details
i915_display_info.before (6.99 KB, text/plain)
2019-01-24 09:51 UTC, Kirill A. Shutemov
no flags Details
i915_display_info.after (6.99 KB, text/plain)
2019-01-24 09:51 UTC, Kirill A. Shutemov
no flags Details
dmesg with drm.debug=0x1e (840.34 KB, text/plain)
2019-01-28 21:40 UTC, Kirill A. Shutemov
no flags Details
Xorg.0.log (85.75 KB, text/x-log)
2019-01-28 21:41 UTC, Kirill A. Shutemov
no flags Details
gentoo-configs.tar.bz2 (12.80 KB, application/x-bzip2)
2019-01-30 09:21 UTC, Kirill A. Shutemov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill A. Shutemov 2019-01-21 09:55:01 UTC
Created attachment 143174 [details]
Xorg.0.lo

System is Thinkpad T460p with external display attached over DisplayPort. Kernel is v5.0-rc2. Xorg is 1.20.3.

Xorg starts normally, but if external display gets through power cycle switching to console and back leads to Xorg crash with "modeset(0): failed to set mode: No such file or directory". See attached log.

The external display is Dell UP2414Q, which is 4k, but the bug can be reproduced with MST disabled too.
Comment 1 Kirill A. Shutemov 2019-01-21 09:55:31 UTC
Created attachment 143175 [details]
dmesg with drm.debug=0x1e
Comment 2 James Ausmus 2019-01-22 23:39:21 UTC
Kirill - what WM/Desktop Environment are you using?
Comment 3 Kirill A. Shutemov 2019-01-23 09:20:20 UTC
AwesomeWM as an window manager and SLiM as an login manager.
Comment 4 James Ausmus 2019-01-24 00:48:20 UTC
Thanks Kirill - could you also provide the output of:

sudo su
cat /sys/kernel/debug/dri/0/i915_display_info


both before and after the issue occurs?
Comment 5 Kirill A. Shutemov 2019-01-24 09:51:15 UTC
Created attachment 143221 [details]
i915_display_info.before
Comment 6 Kirill A. Shutemov 2019-01-24 09:51:39 UTC
Created attachment 143222 [details]
i915_display_info.after
Comment 7 James Ausmus 2019-01-24 22:57:07 UTC
Hmm - I wonder if this is the same issue as https://bugs.freedesktop.org/show_bug.cgi?id=88124

DK, what do you think?
Comment 8 Kirill A. Shutemov 2019-01-25 12:47:14 UTC
I *think* you are right (but I would like somebody to confirm it). Connecting the display directly to the laptop solves the issue.

Is there any guidance on how window managers have to deal with this?
Comment 9 Dhinakaran Pandiyan 2019-01-26 00:27:03 UTC
What's interesting is dmesg shows modeset on the new connector succeeded after vt switch. Can you please attach dmesg with drm.debug=0x1e, the file that's currently attached is with drm.debug=0xe? Also verbose xserver logging will be helpful.
Comment 10 Dhinakaran Pandiyan 2019-01-26 02:46:33 UTC
(In reply to Kirill A. Shutemov from comment #8)
> I *think* you are right (but I would like somebody to confirm it).
> Connecting the display directly to the laptop solves the issue.
> 
> Is there any guidance on how window managers have to deal with this?

Do you see the same problem if you power cycle the monitor by pressing the power button or hotplugging the monitor?
Comment 11 Kirill A. Shutemov 2019-01-28 21:40:33 UTC
Created attachment 143245 [details]
dmesg with drm.debug=0x1e
Comment 12 Kirill A. Shutemov 2019-01-28 21:41:12 UTC
Created attachment 143246 [details]
Xorg.0.log
Comment 13 Kirill A. Shutemov 2019-01-28 21:42:49 UTC
(In reply to Dhinakaran Pandiyan from comment #9)
> What's interesting is dmesg shows modeset on the new connector succeeded
> after vt switch.

Clarification: text console comes up normally, crash happens when I switch back to Xserver. Login manager gets Xserver restarted just after the crash.
Comment 14 Kirill A. Shutemov 2019-01-28 21:44:49 UTC
(In reply to Dhinakaran Pandiyan from comment #10)
> Do you see the same problem if you power cycle the monitor by pressing the
> power button or hotplugging the monitor?

Display doesn't comes back after power cycle (goes to power saving mode), but Xserver doesn't crash at this point.

I have not tried hotplugging. I'll come back to you on this.
Comment 15 Kirill A. Shutemov 2019-01-28 21:49:01 UTC
Hotplug behaves the same way as power cycling: display doesn't come back, but it doesn't crash Xserver either.
Comment 16 James Ausmus 2019-01-29 21:57:17 UTC
Kirill - We're having a bit of trouble replicating your error locally here. It appears that you're running Gentoo - if that's correct I'll try to build a replica system locally. Would you be able to post the following:

--The /var/lib/portage/world file
--The output of 'equery list "*"'
--The output of 'emerge --info"
--The /etc/portage/package.use file (or the files in that directory)
--The /etc/conf.d/xdm file

Thanks!
Comment 17 Kirill A. Shutemov 2019-01-30 09:21:57 UTC
Created attachment 143255 [details]
gentoo-configs.tar.bz2
Comment 18 James Ausmus 2019-02-27 20:56:26 UTC
Thanks Kirill - haven't been able to get a replica system up and running yet, I will let you know when that happens
Comment 19 Lakshmi 2019-07-19 10:03:29 UTC
DK, What are the next steps here? Verifying the issue with drm-tip will give more ideas?
Comment 20 Dhinakaran Pandiyan 2019-07-19 14:13:57 UTC
Sorry, I got busy with other things. 

Is the bug still reproducible?


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.