after first splash boot, screen flickers displaying a bunch of drm: failed to restore crtc configuration

Hi eallaud-gmail,

Please attach the output of `lspci -vvnn` and `dmesg`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you're using a custom /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

OK I'll also post my theory about this one.
First I obtained the xorg log by booting the kernel in recovery mode and resuming the normal boot process to get a normal text console. No failed to restore crtc has appeared, but the connectors have no mode is still there in dmesg.
Then I tried startx which gives me the log which basically says that VGA is not connected, which is false. I guess that the flickering in the normal boot is due to X trying to start but failing to find a mode because it thinks that the vga output is not connected.
Hope someone can make sense out of this...

I think my bug is very similar to bug #429369. But it seems like this one is still open.
Is ther anyway to tell kms or X that there is a monitor connected to VGA even if it is not able to find one?

Hmm I tried ddcprobe which gets my monitor characteristics correctly, very odd. See attachment.

I also tried get-edid/parse-edid and it works great, I can see the modes returned by my monitor, they look sane. So how is it that I get this error?

Oh men, trying vesa driver and every thing is fine, it reads edid correctly via edid. I had booted in single mode and with i915.modeset=0. I will try booting directly not using kms (i915.modeset=0) and vesa to see how it goes: and it works!
OK Next try: booting normally (no i915.modeset=0) and vesa in xorg.conf: it works also, the only difference being that there is one line in dmesg saying: drm: *ERROR* connectors have no modes, using standard modes.
Basically the vesa driver seems to just go and read edid whereas intel kms driver is trying to be smarter about who is connected or not and for some reason think noone is connected and then xorg is not able to start.

Sorry for the constant flood of mesages ;-)
But looking at the code in drivers/gpu/drm/i915 it is clear that the culprit is the xxxx_detect_hotplug function which is called for 945 and everything "higher". Would the temporary patch be to do xxxx_detect_ddc instead?

Found a work-around change in drivers/gpu/drm/i915/intel_crtc.c in function intel_crt_detect
 if (IS_I9XX(dev) && !IS_I915G(dev) && !IS_I915GM(dev) && !IS_G33(dev)) {
                                                                                                        ^^^^^^^^^^^^^^^

which basically forces to use edid reading via ddc and not use detect_hotplug method which seems not to work. HTH

Just to be clear: I added the !IS_G33(dev) in the if clause to avoid the detect_hotplug methode for my chipset.

I have a Dell OptiPlex 620 running in headless mode, with no display connected. Looking at the Xorg.0.log I am experiencing similar issue.

This was only noticed last night as I don't have a display attached. I did not have this issue three weeks ago, one of the updates in the interim has triggered the change. I cannot be sure which package version as I haven't been keeing decent track during the lead up to the 9.10 release. I will look more into this as I wan't to get remote desktop working with "Gnome Remote Desktop" and "xvnc" or "LTSP" not sure yet which method.

Do you use kernel modesetting? If yes you should not be able even to boot normally, not even talking about starting Xorg, if you have the same problem.
But if i understand correctly the kms driver check if something is actually attached to the port and if not bails out appropriately ;-)
You might be able to tell him to go ahead though.
In any case no modesetting should get you going further (i915.modeset=0 on the kernel command line).

Any news on this???

Whether i915.modeset=0 or i915.modeset=1 is set in the startup i hve the issue that the display flickers. I have chosen to revert back to Hardy Heron.

Well if you feel like compiling your kernel you can have a look at the patch I posted it definitely works for me, but YMMV...

Adding "vga=792" to kernel boot options worked for me :-)

Bug #404421 seems related.
However none of the suggested workarounds did work for me.
Did anyone test the patch from manu?
How would I test that patch?
Up to now I did not find any other workaround to get my 9.10 running Xorg.

Hmm it's been a while. I have sent the patch upstream, so I know it has been fixed there.
Here is the commit msg.From e808e40278ee315eb6759dd40dc947e6fb2e642f Mon Sep 17 00:00:00 2001
From: Zhenyu Wang <email address hidden>
Date: Wed, 11 Nov 2009 10:22:01 +0800
Subject: [PATCH] drm/i915: Fix CRT hotplug detect by checking really no channels attached

For CRT hotplug detect status, we have four test results as blue
channel only, green channel only, both blue and green channel, and
no channel attached. Origin code only marks both blue and green channel
case as connected, but ignore other possible connected states. This one
trys to detect CRT by checking no channel attached case instead.

Signed-off-by: Zhenyu Wang <email address hidden>

[Since the patch is against the kernel, I'm retargeting this to linux]

Hmm so let me try to understand: as of now is this fixed in Karmic or not? I mean I have seen several kernel updates, so as it has been fixed upstream, has it been applied also in karmic?
Thx

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu development release http://cdimage.ubuntu.com/daily-live/current/ . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]