On any kernel version >3.14.3 I`ve tried, including the recent 4.0.0, at system bootup, just after "waiting for uevents" the screen goes black, and I have no terminal or X any more. If I boot with nomodeset vga=normal kernel parameters, text console is OK, but X won`t start (X says EE no devices detected) H/W: Sony VAIO multiflip VGA: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) O/S: Gentoo
Created attachment 115085 [details] Xorg.log Xorg log
Can you attach your dmesg as well? Sounds like a config problem, like maybe you don't have the i915 kernel driver loaded or something. Please boot with drm.debug=0xf on the kernel command line and attach the dmesg from a fresh boot when this issue happens.
Created attachment 115116 [details] dmesg dmesg content attached
I`d be kind of tempted to exclude the configuration problem, as I just upgraded from an existing and working kernel with --oldconfig.
Created attachment 115175 [details] lsmod.txt BTW, i915 is loaded
[Thu Apr 16 10:22:45 2015] [drm:i915_init] KMS and UMS disabled. The i915 module is loaded but disabled. Please try again with drm.debug=0xf and *without* nomodeset and attach your dmesg again.
Created attachment 115561 [details] dmesg with modesetting enabled adding new logs, removed nomodeset from kernel arguments
Created attachment 115562 [details] lsmod with modesetting
Created attachment 115563 [details] xorg.log with modesetting
The dmesg got truncated. Can you also add log_buf_len=16M and attach again? You might need to compress the file before attaching.
Created attachment 115604 [details] dmesg full compressed Adding full dmesg, compressed
Created attachment 115619 [details] dmesg full compressed replacing previous attachment with fixed content type
(In reply to skaumo from comment #12) > Created attachment 115619 [details] > dmesg full compressed > > replacing previous attachment with fixed content type There is no call into the i915 driver after it is loaded. It looks like there is no X server or other display server running. Could you check whether your init sequence is aborted before the X server is launched? Also, once you get the black screen, what happens if you type on the keyboard?
If I boot normally then the keyboard doesn`t seem to do anything after the screen went black (which happens just after the "waiting for uevents" message), so even the VGA consoles are gone. When I boot with nomodeset vga=normal then I can only use the console and keyboard (mouse also works with gpm). The init sequence does not get aborted (I`m using openrc, not systemd). Only the xdm service fails, whilst the rest of the services all start up properly.
addition: there is no X server running, because it just refuses to start. It still works fine with the old kernel.
There is a mismatch between your logs. Your xorg.log shows: [ 33.252] (==) intel(0): Depth 24, (--) framebuffer bpp 32 [ 33.252] (==) intel(0): RGB weight 888 [ 33.252] (==) intel(0): Default visual is TrueColor [ 33.253] (II) intel(0): Output eDP1 has no monitor section [ 33.253] (--) intel(0): Found backlight control interface intel_backlight (type 'raw') for output eDP1 [ 33.253] (II) intel(0): Enabled output eDP1 [ 33.253] (II) intel(0): Output HDMI1 has no monitor section [ 33.253] (II) intel(0): Enabled output HDMI1 But if that happened, at least a DRM_IOCTL_MODE_GETCONNECTOR call would have to be done to the kernel driver. But your dmesg log shows no such call.
Created attachment 116260 [details] dmesg I managed to get another dmesg, and now it finally shows traces of DRM_IOCTL_MODE_GETCONNECTOR Thanks for your patience and your help :)
Looking at your dmesg, it seems X turns off all CRTCs (which is normal behavior). The odd part is that after that no CRTCs are turned on. Could you try the latest xorg driver from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ ? If that still doesn't work, could you compile the driver with --debug=full and attach your Xorg.log again.
Created attachment 116262 [details] dmesg Tried xf86-video-intel-9999 but no luck. udpated dmesg with a bit more logging attached. Hope it`s verbose enough.
(In reply to skaumo from comment #19) > Created attachment 116262 [details] > dmesg > > Tried xf86-video-intel-9999 but no luck. > > > udpated dmesg with a bit more logging attached. Hope it`s verbose enough. I need you *Xorg.0.log* with a driver compiled with debug enabled (i.e. run ./configure --enable-debug=full ).
(In reply to Ander Conselvan de Oliveira from comment #18) > Looking at your dmesg, it seems X turns off all CRTCs (which is normal > behavior). The odd part is that after that no CRTCs are turned on. It's not X that is turning them off, the kernel reports all outputs as unknown status, including the one currently active.
Hmm, connector->status is orthogonal to whether the mode is correctly inherited from the BIOS.
(In reply to Chris Wilson from comment #21) > (In reply to Ander Conselvan de Oliveira from comment #18) > > Looking at your dmesg, it seems X turns off all CRTCs (which is normal > > behavior). The odd part is that after that no CRTCs are turned on. > > It's not X that is turning them off, the kernel reports all outputs as > unknown status, including the one currently active. What I saw is: [ 34.584653] [drm:drm_ioctl] pid=1987, dev=0xe200, auth=1, DRM_IOCTL_MODE_SETCRTC [ 34.584663] [drm:drm_mode_setcrtc] [CRTC:20] [ 34.584667] [drm:intel_crtc_set_config] [CRTC:20] [NOFB] ... [ 34.854489] [drm:drm_ioctl] pid=1987, dev=0xe200, auth=1, DRM_IOCTL_MODE_SETCRTC [ 34.854493] [drm:drm_mode_setcrtc] [CRTC:24] [ 34.854495] [drm:intel_crtc_set_config] [CRTC:24] [NOFB] ... [ 34.854505] [drm:drm_ioctl] pid=1987, dev=0xe200, auth=1, DRM_IOCTL_MODE_SETCRTC [ 34.854508] [drm:drm_mode_setcrtc] [CRTC:28] [ 34.854510] [drm:intel_crtc_set_config] [CRTC:28] [NOFB] I might have missed something, but that seems consistent with X behavior to me. Before those SetCrtc calls, I see: [ 34.075768] [drm:drm_mode_getconnector] [CONNECTOR:31:?] [ 34.075770] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:31:eDP-1] [ 34.075772] [drm:intel_dp_detect] [CONNECTOR:31:eDP-1] [ 34.075777] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:31:eDP-1] status updated from 3 to 1 [ 34.075787] [drm:drm_add_display_info] eDP-1: Assigning EDID-1.4 digital sink color depth as 6 bpc. [ 34.075788] [drm:drm_edid_to_eld] ELD: no CEA Extension found [ 34.075791] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:31:eDP-1] probed modes : [ 34.075795] [drm:drm_mode_debug_printmodeline] Modeline 32:"1920x1080" 60 138700 1920 1968 2000 2080 1080 1083 1088 1111 0x48 0xa And I see this in drm_crtc.h enum drm_connector_status { connector_status_connected = 1, connector_status_disconnected = 2, connector_status_unknown = 3, }; So it seems connector status changed from disconnected (3) to (1). Did I miss something?
Created attachment 116285 [details] xorg.log I tried to configure with --debug=full, but it said there is no such option. It worked with --enable-debug. Hope it`s going to be verbose enough.
(In reply to Ander Conselvan de Oliveira from comment #23) > (In reply to Chris Wilson from comment #21) > > (In reply to Ander Conselvan de Oliveira from comment #18) > > > Looking at your dmesg, it seems X turns off all CRTCs (which is normal > > > behavior). The odd part is that after that no CRTCs are turned on. > > > > It's not X that is turning them off, the kernel reports all outputs as > > unknown status, including the one currently active. > > What I saw is: > > [ 34.584653] [drm:drm_ioctl] pid=1987, dev=0xe200, auth=1, > DRM_IOCTL_MODE_SETCRTC > [ 34.584663] [drm:drm_mode_setcrtc] [CRTC:20] > [ 34.584667] [drm:intel_crtc_set_config] [CRTC:20] [NOFB] > > ... > > [ 34.854489] [drm:drm_ioctl] pid=1987, dev=0xe200, auth=1, > DRM_IOCTL_MODE_SETCRTC > [ 34.854493] [drm:drm_mode_setcrtc] [CRTC:24] > [ 34.854495] [drm:intel_crtc_set_config] [CRTC:24] [NOFB] which is not present in the last dmesg, which appears to just contain X startup. > [ 34.854505] [drm:drm_ioctl] pid=1987, dev=0xe200, auth=1, > DRM_IOCTL_MODE_SETCRTC > [ 34.854508] [drm:drm_mode_setcrtc] [CRTC:28] > [ 34.854510] [drm:intel_crtc_set_config] [CRTC:28] [NOFB] > > I might have missed something, but that seems consistent with X behavior to > me. X only disables CRTC that have mismatching kernel state as X tries to use whatever mode and configuration the kernel reports. This set of disabling is from after X initialisation. > Before those SetCrtc calls, I see: > > [ 34.075768] [drm:drm_mode_getconnector] [CONNECTOR:31:?] > [ 34.075770] [drm:drm_helper_probe_single_connector_modes_merge_bits] > [CONNECTOR:31:eDP-1] > [ 34.075772] [drm:intel_dp_detect] [CONNECTOR:31:eDP-1] > [ 34.075777] [drm:drm_helper_probe_single_connector_modes_merge_bits] > [CONNECTOR:31:eDP-1] status updated from 3 to 1 > [ 34.075787] [drm:drm_add_display_info] eDP-1: Assigning EDID-1.4 digital > sink color depth as 6 bpc. > [ 34.075788] [drm:drm_edid_to_eld] ELD: no CEA Extension found > [ 34.075791] [drm:drm_helper_probe_single_connector_modes_merge_bits] > [CONNECTOR:31:eDP-1] probed modes : > [ 34.075795] [drm:drm_mode_debug_printmodeline] Modeline 32:"1920x1080" 60 > 138700 1920 1968 2000 2080 1080 1083 1088 1111 0x48 0xa > > And I see this in drm_crtc.h > > enum drm_connector_status { > connector_status_connected = 1, > connector_status_disconnected = 2, > connector_status_unknown = 3, > }; > > So it seems connector status changed from disconnected (3) to (1). Did I > miss something? unknown -> connected and implies that no active mode was found during the initial probe.
Is there any other information I can provide to help progressing this? It`s still an open issue as of 4.1.x
(In reply to skaumo from comment #26) > Is there any other information I can provide to help progressing this? It`s > still an open issue as of 4.1.x We seem to have neglected this bug a bit. Apologies. Does the problem persist with latest kernels?
Just tried with kernel 4.5.2, but it didn`t get any better, unfortunately.
Same problem Bug 96930 ?
removing needinfo status, info was provided.
Good afternoon, This problem seems to be fixed on 4.8 and up. So I'm closing the bug, if problem arise with latest kernel versions please open a new bug case with HW, SW and logs required. Thank you. (In reply to Adam Pribyl from comment #2) > As we reported in redhat bugzilla this seems to be resolved in kernels > 4.8.10+. > Thanks anyway.
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.