Created attachment 53592 [details] xorg log with debug=full Sometimes (in about 10%) X doesn't start on my "Toshiba tecra A8" notebook. This sometimes happens when cold-booting the system, sometimes when I restart X. Haven't seen this behaviour with earlier drivers, as far as I remember I saw it the first time with Fedora-15. When X fails to start I get the following messages in syslog: Nov 16 10:48:17 localhost kernel: [ 292.191165] [drm:intel_lvds_mode_fixup] *ERROR* Can't enable LVDS and another encoder on the same pipe Nov 16 10:48:17 localhost kernel: [ 292.191175] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:4] Nov 16 10:48:17 localhost kernel: [ 292.191181] detected fb_set_par error, error code: -22 Nov 16 10:48:17 localhost kernel: [ 292.191213] [drm:intel_lvds_mode_fixup] *ERROR* Can't enable LVDS and another encoder on the same pipe Nov 16 10:48:17 localhost kernel: [ 292.191219] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:4]
sorry, forgot to mention: intel i945GM libdrm-2.4.27 pixman-0.23.8 linux-3.1.1 xorg 1.11.2
Jesse, not quite in the same league as your 3-pipe/2-output problem, but it does look to be of the same ilk - X choosing the wrong default configuration.
dont know if this has anything to do with the problem I experience - just noticed an unusual delay at boot which usually isn't there, and found the following log-statement in syslog: [ 20.432573] vboxpci: IOMMU not found (not registered) [ 26.857435] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. [ 28.330885] wlan0: authenticate with 00:1e:69:e9:63:40 (try 1)
Seems to be timing related too, my SSD died so I am using my old HDD again - which makes me experience this bug a lot more frequently.
I am quite confident this is related to Fedora's graphical boot sequence. Usually rhgb displays a Fedora logo that is animated right before X is started. In case X doesn't start, it hangs right before this animation. I also had those "animation-hangs" when booting into runlevel 3 directly with the same sympthoms - I wasn't able to switch to any VTs and always saw the rhgb stuck right before the animation. If I can provide further details, please let me know. I'll meanwhile try to get a stacktrace of a hanging rhgb.
I wonder if this is related to the race fix recently posted to dri-devel. That bug manifests as some sort of boot error because a boot splash program opens the DRM device before it's finished initializing. Given the racy nature of yours, that seems like a possibility.
(In reply to comment #6) > I wonder if this is related to the race fix recently posted to dri-devel. That > bug manifests as some sort of boot error because a boot splash program opens > the DRM device before it's finished initializing. Given the racy nature of > yours, that seems like a possibility. I don't think so. That race manifests itself in X or libdrm not being able to open the i915.ko device and exploding very early on. Whereas this failure is much later with (presumably) X requesting a completely bogus configuration, LVDS and another encoder on the same crtc? Madness!
Looking the debug file more closely, the instructive error is that we fail to become DRM master which at 180s suggests that something else was... I think this is actually a system config issue rather than X being broken and choosing an invalid config like I first presumed.
Hi, I noticed this bug is marked invalid/closed but let me connect to this thread related to userspace race : https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/982889#149 { Wondering why this bug has not been forwarded upstream ? https://bugs.freedesktop.org/show_bug.cgi?id=42972 does not mention about : setversion 1.4 failed nor https://bugzilla.redhat.com/show_bug.cgi?id=855677 Also I feel the patch worth to be forwarded/upstreamed too : https://launchpadlibrarian.net/131169748/0001-If-drm-device-couldn-t-be-opened-keep-trying-for-a-s.patch } May this help, if not then excuse me for the noise and excuse some ubuntu monkey too :)
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.