Created attachment 27200 [details]
xorg.conf

Created attachment 27201 [details]
Xorg.log

What's your mother board model?
I'm not sure if this is related to bug#21574.

Is there an older version of driver/kernel ever working on this machine before?

(In reply to comment #3)
> What's your mother board model?
$dmidecode
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
        Manufacturer: Gigabyte Technology Co., Ltd.
        Product Name: EG41M-S2H
        Version: x.x
        Serial Number:  
> I'm not sure if this is related to bug#21574.
No, although I have the same mother board as Jarek Kuboš (one of the reporters of #21574), our dmesg logs are dirrerent, so the problems may not be the same.
> 
> Is there an older version of driver/kernel ever working on this machine before?
The old xserver and drivers (installed from Debian lenny repository) work all right with the same kernel and xorg.conf.
xserver-org-core                        1.4.2-10.lenny2
xserver-xorg-video-intel                2.3.2-2+lenny6
mesa                                    7.0.3-7
libdrm2                                 2.3.1-2
> 

Your monitor's EDID does appear to be bad, because the header is broken.  The way we could verify it would be to plug that monitor into another vendor's graphics adaptor and attach the output of xrandr --prop and Xorg.0.log, which is the next step here.  KMS should still feed you some modes on VGA in the absence of EDID, though.

However, given that it appears to be a single-monitor issue, I'm downgrading the priority for now.

Oh, the other question I have: Is the EDID block dumped out in dmesg same every time?

So this looks like not G41 issue but EDID issue. Reassign to Yakui.

H, Peng
   Will you please check whether this issue also exists with KMS disabled?
   Please add the modedebug option in xorg.conf and attach the Xorg.0.log in UMS mode?
   
   Will you please also attach the vbios.dump? The vbios.dump can be obtained by using the following commands:
   
   1. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
    2. cat /sys/devices/pci0000:00/0000:00:02.0/rom > vbios.dump
   3. echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom

Thanks.

Will you please try the Dave's drm-next tree and see whether the xserver can be started correctly? It will be great if you can add the boot option of "drm.debug=0x7" and attach the output of dmesg.
    If you can't know how to switch to Dave's drm-next tree, please use the following command to use the Dave's drm-next tree.

1. git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
   2. git branch -r
   3. git checkout -b origin/drm-next


thanks.

Hi,

sorry to response so late.
Sadly I can't do more test. The mentioned PC belongs to others and I don't have access to it any more. But the problem did disappear w/o KMS.

(In reply to comment #10)
> Hi,
> 
> sorry to response so late.
> Sadly I can't do more test. The mentioned PC belongs to others and I don't have
> access to it any more. But the problem did disappear w/o KMS.
> 
As you can't access the machine again, the bug will be rejected.

The main issue is related with BAD EDID.

Now in the KMS mode we will add some default modes for the output device without EDID. Of course the output device with bad edid is also regarded as the output device without EDID.

thanks.