Created attachment 26303 [details]
I'm forwarding a bug from an ubuntu user:
On a Asus Mini Barebone (Pundit P3-PH4C SK775 DDR2) with 945G chipset, the monitor connected on the VGA port is not detected and the X server therefore exits with "Fatal server error: no screens found". Normally a Samsung TV (LE27S7) is connected via a VGA cable, but also when an Eizo CRT was connected, it is not detected. Both get-edid and ddcprobe is able to read the EDID of the monitor. When using the vesa driver it works normally.
It used to work in ubuntu 8.04 (which has intel driver 2.2.1), but stopped working in 8.10 (with driver version 2.4.1). It has been tested and found not to work in 2.7.1. While the default AccelMethod for ubuntu packages (including 2.7.1) is EXA, it has also been tested with UXA without working.
-- chipset: 945G
-- system architecture: 32-bit
-- xf86-video-intel: 2.7.1
-- xserver: 1.6.0-0ubuntu14
-- mesa: 7.4-0ubuntu3
-- libdrm: 2.4.5-0ubuntu4
-- kernel: 2.6.28-11-generic
-- Linux distribution: Ubuntu 9.04 (Jaunty)
-- Machine or mobo model: ASUS PUNDIT P3-PH4C SK775 DDR2
-- Display connector: VGA
00:00.0 Host bridge : Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:817a]
00:02.0 VGA compatible controller : Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:817a]
Created attachment 26304 [details]
Xorg.0.log with ModeDebug using the 2.7.1 driver
Created attachment 26305 [details]
Xorg.0.log from driver version 2.2.1
I'm the original user who submitted the bug in launchpad. I'll be glad to test anything you might need to test. I plan to re-format the machine, but still will wait several weeks.
Created attachment 26346 [details] [review]
please try the patch on your machine. thanks
It's surprising to know that 2.2.1 works for you but 2.4.1 doesn't . git diff shows that there is really no difference on the crt detection code between these two releases. hmm..
I speak too fast..seems that Ubuntu has cherry picked more patches against upstream..
Maybe 7b6f4d22211d71480caf6335a3eacaacff369371 cause this?
How do I have to proceed to try the patch?
Jordi, we will figure out the details about how to add the patch in the dowstream report (to keep noise down here).
Ling, can we try the patch against 2.7.1, or do we have to get git-master to test?
(In reply to comment #8)
> Jordi, we will figure out the details about how to add the patch in the
> dowstream report (to keep noise down here).
> Ling, can we try the patch against 2.7.1, or do we have to get git-master to
yes, you can try the patch against 2.7.1.
I also can not find any differnece between 2.2.1 and 2.4.1.
Because we have no hardware, would you please like to do git bisec to find which patch caused the regression between two versions
Michael mentioned 7b6f4d22211d71480caf6335a3eacaacff369371 ?
Thanks for your help.
(In reply to comment #9)
> (In reply to comment #8)
> > Jordi, we will figure out the details about how to add the patch in the
> > dowstream report (to keep noise down here).
> > Ling, can we try the patch against 2.7.1, or do we have to get git-master to
> > test?
> yes, you can try the patch against 2.7.1.
> I also can not find any differnece between 2.2.1 and 2.4.1.
> Because we have no hardware, would you please like to do git bisec to find
> which patch caused the regression between two versions
> Michael mentioned 7b6f4d22211d71480caf6335a3eacaacff369371 ?
> Thanks for your help.
> Ma Ling
yes, Ubuntu didn't just take our original 2.4.1 release, but cheery picked more in post-2.4.1 master, such as the commit 7b6f.. I think. check out the link I posted in comment# 6...
(In reply to comment #7)
> How do I have to proceed to try the patch?
Jordi, could you try to check out 2.4.1 from freedesktop upstream repository and see if it works for your system? this may help us narrow the issue down because from upstream change log, 2.2.1 and 2.4.1 really makes no different on CRT detection. if upstream 2.4.1 works for you, then it should be the patch cherry picked by Ubuntu from our post-2.4 release.
Created attachment 26407 [details]
xorg.0.log with ModeDebug using 2.7.1 driver with patch provided
Just tried the patch provided (comment #4) and it doesn't work. I attached the Xorg.0.log file with debug option activated. Now we are working on checking 2.4.1 from freedesktop upstream repository.
The 2.4.1 driver from git (well, really from http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.4.1.tar.gz) but I guess that would be the same) didn't compile properly on Ubuntu 9.04 (Jaunty). Instead I took the ubuntu package from https://launchpad.net/~siretart/+archive/ppa which is the same as the Intrepid (8.10) package but with a couple of extra patches to make it compile on Jaunty. I then disabled the patch 22_no_pipe_for_hotplug_detection.patch which is exactly the 7b6f... commit mentioned above. I hope that provides an equally good test case as your unpatched 2.4.1 would. If the deb-package with the patch disabled works for Jordi, it should be clear that 7b6f... is the problem.
Created attachment 26518 [details]
test with 2.4.1 with the path (fails)
Created attachment 26519 [details]
test with 2.4.1 without the patch (works!!)
We've done the suggested tests and 2.4.1 without the patch works properly. I've attached both xorg.0.log with mode debug activated.
The patch in question (22_no_pipe_for_hotplug_detection.patch) was added to ubuntu for fixing this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/256142 . But from the comments, it seems it did not actually fix it (but it stopped Timo's mouse pointer from jumping during monitor probing).
(In reply to comment #17)
> The patch in question (22_no_pipe_for_hotplug_detection.patch) was added to
> ubuntu for fixing this bug:
> . But from the comments, it seems it did not actually fix it (but it stopped
> Timo's mouse pointer from jumping during monitor probing).
you're right, the patch will help to reduce flicking. Until this bug, we didn't run into any issue about doing so..
Created attachment 26636 [details] [review]
please try the debug patch on your machine against lastest 2D driver, thanks.
(In reply to comment #19)
> Created an attachment (id=26636) [details]
> please try the debug patch on your machine against lastest 2D driver, thanks.
Jordi reports downstream that when using the deb-package that I built with the patch, X does not even start and is not producing an Xorg.0.log. I didn't get more details or verification that the deb-package that I built without the patch worked normally (I like to build packages in pairs with and without patches so that I know that different behavior is not due to my build environment). Is there any specific information you want from the non-starting X-session?
When I reported this problem Geir, he asked me to do more tests, but I haven't had time to do it. I'll try to find some time and do it ASAP.
(In reply to comment #22)
> When I reported this problem Geir, he asked me to do more tests, but I haven't
> had time to do it. I'll try to find some time and do it ASAP.
> Thanks, Jordi.
The problems Jordi reported earlier with the patched version went away after a reboot (just installing the driver and restarting X was problematic). The patch in comment #19 didn't make any difference. The logs created with and without the patch are as equal as they can be (only the timestamp and a memory address in the backtrace differ).
Xorg.0.log with git-master without patch:
Xorg.0.log with git-master with patch:
Created attachment 28033 [details]
please try the debug patch
In this patch against latest 2D driver I move load detect sequence to match environment of your successful detection, meanwhile dump register before and after load detect function. Please try it then upload your xorg file.
Geir Ove Myhr , would you please help to ping Jordi to provide log after patch in comment# 25? thanks.
First of all my apologies for the delay. I am quite busy during summer and haven't had time to check on that.
I tested the driver with the patch and it works. You can find the xorg.1.log file (it is 1 because somehow session number 0 got stuck and the new driver opened the session in number 1) at http://launchpadlibrarian.net/30765627/Xorg.1.log
And as I said, the patch works: It detects the screen correctly and gets the right resolution.
we've known that i830GetLoadDetectPipe is the key to this bug - without invoke it, hotplug detection fails. comparing the regdump before and after the call shows that disabling VGA (VGACNTRL register) might be the root-cause.
Created attachment 29031 [details] [review]
disable VGA plane before doing CRT hotplug
Will you please try the debug patch on the latest graphics driver and see whether the issue still exists?
Please try it on UMS mode.
(In reply to comment #32)
> ping~ Jordi
Jordi reported downstream that he is on holiday 10 days from Sept. 2.
Created attachment 29504 [details]
Xorg.0.log with the patch in comment #31
Here is the Xorg.0.log from Jordi downstream. He doesn't say whether it fixes the issue or not, but maybe it is obvious from the log or he can comment here.
(In reply to comment #34)
> Created an attachment (id=29504) [details]
> Xorg.0.log with the patch in comment #31
> Here is the Xorg.0.log from Jordi downstream. He doesn't say whether it fixes
> the issue or not, but maybe it is obvious from the log or he can comment here.
looks it's fixed...
(In reply to comment #35)
> (In reply to comment #34)
> > Created an attachment (id=29504) [details] [details]
> > Xorg.0.log with the patch in comment #31
> > Here is the Xorg.0.log from Jordi downstream. He doesn't say whether it fixes
> > the issue or not, but maybe it is obvious from the log or he can comment here.
> looks it's fixed...
No, it's not. I was in a rush and forgot to write it down. The screen went black (on power save).
Created attachment 29654 [details] [review]
disable VGA plane before doing CRT hotplug detect
Will you please try the updated debug patch and see whether the issue still exists?
Ping ~ Jordi
Created attachment 29883 [details]
xorg.1.log file after testing last patch
I tried the patch and didn't work. I get the "Ubuntu is running in low graphics mode" message. I attach the xorg log file.
I would like to add my own experience here:I have a g33 based MB with the same problem on Karmic: actually it does not even boot correctly with KMS as it cannot find a screen as it thinks VGA is disconnected. All details (with a patch that forces ddc probing instead of hotplug detection) are here:https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/467841
Let me know if I can post some more logs to help.
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 212e227..e505144 100644
@@ -262,8 +262,8 @@ static bool intel_crt_detect_hotplug(struct drm_connector *connector)
} while (time_after(timeout, jiffies));
- if ((I915_READ(PORT_HOTPLUG_STAT) & CRT_HOTPLUG_MONITOR_MASK) ==
+ if ((I915_READ(PORT_HOTPLUG_STAT) & CRT_HOTPLUG_MONITOR_MASK) !=
I post zhenyu's patch here that works for manu. Jordi, would you please have a try?
Note this is a patch against KMS driver, i.e. kernel.
I've been told that it is not possible to test a kernel patch using a live CD. The computer is now being used with a Ubuntu Hardy and I cannot format it. If there is no other way to test it I am afraid it won't be possible.
If we can't get testing, I guess we can't fix this one. Hopefully it got fixed anyway.
I just tested a new Ubuntu 10.04 live CD and seems to work perfectly. So after all it seems it got solved.