Created attachment 27199 [details]
dmseg error log
After installing the newest drivers/libs for KMS/GEM, the new xorg refuses to start. dmesg complains about drm(as attached) and there is no error reported in Xorg.log with ModeDebug enabled.
1. G41 with GMA 4500 Integrated Graphics Card
2. kernel 2.6.30 merged with drm-intel-next, Debian lenny X86_64
3. mesa: git commit 1510c3cae1d840a065a22c891ad6db794dfe7a00
libdrm: git commit 3d4bfe8c893d016ef43d1ebf28e4607aa1f540a4
build and install all mentioned drivers/libs, run Xorg
Created attachment 27200 [details]
Created attachment 27201 [details]
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?
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: EG41M-S2H
> 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.
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.
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
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
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)
> 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.