| Summary: | [drm:edid_is_valid] *ERROR* Raw EDID in dmesg every 10 seconds, temporarily freezing the desktop | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Harald Hvaal <haraldhv> |
| Component: | Driver/intel | Assignee: | ykzhao <yakui.zhao> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | michael.fu, mpower, sitsofe |
| Version: | git | Keywords: | patch |
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Harald Hvaal
2009-08-02 18:54:10 UTC
please provide more info according to http://intellinuxgraphics.org/how_to_report_bug.html. btw, this doesn't looks like a driver bug but something daemon app keeps asking the driver to reprobe all outputs... ping~ sorry for not responding yet; i am actually moving to a whole other country these days which leaves little time for bugfixing. I am still experiencing the bug, and will follow the linked bug procedure and post again within the next few days System environment: -- chipset: 945GM/GMS/GME -- system architecture: 32-bit -- xf86-video-intel: see below -- xserver: 1.6.3 -- mesa: 1.4 Mesa 7.6-devel -- libdrm: 2.4.12+git20090806.d74c67fb-0ubuntu0sarvatt -- kernel: 2.6.30-8-generic -- Linux distribution: (k)ubuntu -- Machine or mobo model: sony vgn-g2 vaio laptop -- Display connector: just a normal flatscreen, no external stuff connected Reproducing steps: happens about 80% of the time, sometimes it seems to stop Additional: (II) Module intel: vendor="X.Org Foundation" · compiled for 1.6.3, module version = 2.8.0 · Module class: X.Org Video Driver · ABI class: X.Org Video Driver, version 5.0 X.Org X Server package version: 2:2.8.0+git20090814.926c7e7d-0ubuntu0sarvatt Created attachment 28780 [details]
dmesg output
Created attachment 28781 [details]
Xorg.0.log log
partly snipped the logfile because it has big repeating parts making it exceed the maximum filesize
Created attachment 28782 [details]
xrandr --verbose output
I only noticed now the large repeating parts in Xorg.0.log, please have a look at it as it may be of interest. looks like something in the X is keep querying modelines from KMS... Harald, how about other sister Ubuntu release next to kbuntu? such as the default Ubuntu liveCD. Does it still procedure the long xorg.log? thanks. ping~ Harald ping~ Harald Will you please 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. /sys/devices/pci0000:00/0000:00:02.0/rom
Thanks.
From the dmesg log it seems that we can't get the correct EDID for LVDS and then it complains the following warning message: >drm:edid_is_valid] *ERROR* Raw EDID: At the same time it seems that the system will check the state of LVDS and then try to get the supported mode periodically. But as it can't read the EDID correctly. Maybe we should avoid to read the EDID for LVDS on this box. Please attach the output of vbios.dump and dmidecode. Thanks. lost connection with bug reporter... Sorry about the silence, real life stuff keeps getting in my way :) Will now attach the requested data. I see you have marked the bug as resolved, and even though it seems partially based on the fact that I disappeared, I will not attempt to change that back now. But know that I am still interested in helping out with this bug, even if I did a bad job at staying active until now... Created attachment 29581 [details]
dmidecode output
Created attachment 29582 [details]
rom
Created attachment 29583 [details]
rom (this timed marked as binary)
Created attachment 29584 [details]
vbios.dump
Further comments: I just upgraded to the newest 2.8.99 drivers from svn, and the bug still persists (whatever may be causing it). I also did the cat 1 > /devices/...../rom as instructed above, before dumping these files. reopening then (In reply to comment #10) > Harald, how about other sister Ubuntu release next to kbuntu? such as the > default Ubuntu liveCD. Does it still procedure the long xorg.log? thanks. > Harald, have you tried this? thanks. Created attachment 29877 [details] [review] Don't read the EDID for LVDS when the LVDS_EDID is unsupported in VBT Will you please try the debug patch and see whether the issue still exists? From the vbios.dump it seems that the LVDS_EDID is unsupported in VBT. Maybe it is unnecessary to read the EDID for the LVDS on this box. Thanks. there are cases that LVDS supports EDID but VBT is wrong.. why not use a flag in private structure to set that, if first take of reading EDID has been failed, we won't bother to read EDID again? nobody is able to hotplug a LVDS panel anyway :) Even though , the problem is more likely because a buggy user space tool that keep asking for EDID... I took this bug in my upgrade to karmic: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/438435 I hope info recollected by ubuntu-bug are ok, but tell me if more info are needed from any other source Thank you ! Created attachment 30614 [details] [review] try the debug patch to get the process which always tries to read EDID will you please try the debug patch and attach the output of dmesg? Thanks. I came to this bug from a ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/475756 This bug is similar in that I see EDID output in the xorg.0.log multiple times. It is different in that the driver never attempts to read the EDID from the DVI1 port because it thinks the port is not connected. However I see the screen activate on boot so the connection is there. This could be the same or different bug, so before I spam the comments with a whole bundle of attachments, tell me if you want me to put the information in here or in a new bug. (In reply to comment #28) > I came to this bug from a ubuntu bug: > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/475756 > > This bug is similar in that I see EDID output in the xorg.0.log multiple times. > It is different in that the driver never attempts to read the EDID from the > DVI1 port because it thinks the port is not connected. However I see the > screen activate on boot so the connection is there. > > This could be the same or different bug, so before I spam the comments with a > whole bundle of attachments, tell me if you want me to put the information in > here or in a new bug. > Mike, you issue is dup of bug# 23842, not related with this bug. pls try the patch over there. thanks. since there is no response for more than one month, this bug will be rejected. If the problem still exists, please try the debug patch in comment #27 and re-open this bug. Thanks. (In reply to comment #30) > since there is no response for more than one month, this bug will be rejected. > > If the problem still exists, please try the debug patch in comment #27 and > re-open this bug. > > Thanks. > So I tried the 2.9.1 build of the Intel driver (via xorg-edgers Ubuntu ppa) and I still have this problem. dmseg prints out tons of EDID Invalid messages and I cannot use dual monitors on my 945GM chip. Unfortunately I also had to downgrade back to 2.9.0 and all related packages because what came on xorg-edgers was very unstable. I will try to build 2.9.1 from source and do what I can to help you get to the bottom of this. (In reply to comment #31) > (In reply to comment #30) > > since there is no response for more than one month, this bug will be rejected. > > > > If the problem still exists, please try the debug patch in comment #27 and > > re-open this bug. > > > > Thanks. > > > > So I tried the 2.9.1 build of the Intel driver (via xorg-edgers Ubuntu ppa) and > I still have this problem. dmseg prints out tons of EDID Invalid messages and I > cannot use dual monitors on my 945GM chip. > > Unfortunately I also had to downgrade back to 2.9.0 and all related packages > because what came on xorg-edgers was very unstable. I will try to build 2.9.1 > from source and do what I can to help you get to the bottom of this. > Will you please try the debug patch in comment #27 and attach the output of dmesg on your box? Thanks. Created attachment 32070 [details]
dmesg output w/ the dump_stack patch
My case is slightly different from the original poster now that I look at it. I don't get a spew of EDID invalid messages, but every time my system does something to try to read the EDID (say, running xrandr -q), a new EDID Invalid message shows up.
That said, it does appear that there are successful calls to drm_get_edid, as this attached file contains quite a few call stacks that are not followed by an EDID error.
Let me know if there's more information you need.
Any update on this? I even tried the "Don't read the EDID for LVDS when the LVDS_EDID is unsupported in VBT" patch, but nothing changed (still no recognition of other monitor, still EDID Invalid error). Created attachment 32493 [details]
dmesg output with patched kernel
I'm sorry for taking so long with getting this done, it was surprisingly complicated to get the kernel compiled on another pc and finally installed here.
In any case, I applied the debug patch and have a backtraced dmesg output ready for you, here it is.
Created attachment 33190 [details] [review] ignore the LVDS edid when it is unavailable or invalid Will you please try the attached patch and see whether it still frequently reports the following message? >i915 0000:00:02.0: LVDS-1: EDID invalid. thanks. Yakui Thanks a lot for your patch. No, with this patch it does no longer report the message frequently, only once as a part of kernel boot. I can also happily report that there is no freezing, and for the first time in at least a year, I can actually play a video smoothly all the way through! :) Please let me know if there is anything more you would like to test before you commit the patch. Created attachment 33486 [details] [review] try the updated pathc that ignores the LVDS edid when it is unavailabe or invalid Will you please help me test the updated patch again? thanks. Applied and tested, it runs fine, still without the bug. Not sure if there is anything else I should look for? I can confirm that this patch worked for me too (Toshiba Portege M400, graphics card 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03), 2.6.33-rc8-00113-gf8b55f2 running on Fedora 12). Here is the a snippet of the dmesg output with the patch: [ 1.944430] [drm] set up 7M of stolen space [ 2.571575] [drm:edid_is_valid] *ERROR* Raw EDID: [ 2.571643] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571646] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571648] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571668] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571671] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571673] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571676] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571678] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2.571680] [ 3.174390] [drm:edid_is_valid] *ERROR* Raw EDID: [ 3.174457] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174459] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174462] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174464] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174466] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174486] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174489] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174491] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.174493] [ 3.777037] [drm:edid_is_valid] *ERROR* Raw EDID: [ 3.777104] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777107] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777109] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777111] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777114] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777134] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777136] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777138] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 3.777140] [ 4.381295] [drm:edid_is_valid] *ERROR* Raw EDID: [ 4.381362] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381364] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381367] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381369] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381390] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381392] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381394] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381397] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 4.381399] [ 4.381459] i915 0000:00:02.0: LVDS-1: EDID invalid. [ 4.833944] [drm] initialized overlay support Without the patch that message is printed over and over as the system is running. The strange thing is that this error only seems to happen when the laptop is booted from cold - it seemingly does not happen after reboots or booting a few minutes after the laptop has been switched off... Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Now the corresponding patch is already shipped. And after the patch is applied, it can avoid the warning message of "drm:edid_is_valid" perodically. commit bfac4d6725baacbfc085c38e231b8582a1b8f62b Author: Zhao Yakui <yakui.zhao@intel.com> Date: Wed Apr 7 17:11:22 2010 +0800 drm/i915: Ignore LVDS EDID when it is unavailabe or invalid So this bug will be marked as resolved. Thanks. |
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.