Mailinglist Archive: radeonhd (290 mails)

[bugzilla-daemon@xxxxxxxxxxxxxxx]

http://bugs.freedesktop.org/show_bug.cgi?id=15989





--- Comment #11 from Egbert Eich <eich@xxxxxxxxxxxxxxxxxxx>  2008-08-01 
03:52:37 PST ---
(In reply to comment #9)
> Created an attachment (id=18048)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=18048) [details]
> Xorg.log file without a configuration, -logverbose 9
>
> This is the new log file with -logverbose 9.
Thanks a lot! It was quite helpful.

> Yes, I'm sure there's nothing connected to the HDMI connector, only to the DVI
> conector.  Actually the other day I opened the case just to inspect it and 
> look
> for anything suspicious and I couldn't spot anything.

I've got exactly the same board but the HDMI variant. It comes with an HDMI
riser card that's plugged into the PEG slot (PCI-E 16x).
Now your VBIOS the connector table shows this HDMI port although the HDMI riser
card is not present. This would not be a problem, but according to the log that
you've sent there is i2c data transaction on the DDC line that belongs to this
non-existing HDMI port. On my system (with the riser card present) I get a NACK
when I try to start an I2C transaction on this DDC line without any device
detected.
Apparently the checksum of the data that's transferred is incorrect according
to the  DDC specs so the Xserver doesn't try to interpret it as an EDID block.
I wonder how this data looks like...
rhd_conntest will help you to dump this data:
 ./rhd_conntest 1:5.0 -x 128

Presently with no hot plug information available we check for the presence of a
device by trying to access the DDC line. If we receive an ACK on addressing the
DDC slave address we assume a device is present.
This heuristic seems to fail in your case which would be bad. It would mean
that we'd have to transfer a full EDID blck and calculate the checksum to know
if anything is connected. Here it would be good if RandR could be instructed to
treat an output reading an existing but invalid EDID block as unconnected -
especially for digital interfaces as for them the availability of EDID data is
a requirement.
But this would be more an randr less a driver issue.
> Should I consider the possibility of a bad motherboard?  Something else
> happens, namely every now and then the screen goes black for a second or two
> and then it resumes to normal.  Initially I blamed the driver, but I've 
> noticed
> that this happens with all the drivers that I've tried.  Then I thought it
> could be the monitor, but I attached it to another machine and it seemed to
> work fine for a couple of hours (that's not conclusive, since the problem
> doesn't seem to have a pattern to it, sometimes hours go by before it happens
> and sometimes it happens several times in a row).  I have noticed that it
> happens less often with this driver.

It could be that the electrical characteristics of the TMDS link to the monitor
are slightly off. You could also try to switch to coherent mode. This is
implemented as an output property. Please use
xrandr --prop
to check
and 
xrandr --set <property> <value>
change the state.
Once I get face time with my machine again I will try to reproduce this by
pulling out the HDMI riser card.

> I used 3e2ee2f4722db20dcaf0d08f572b39541b8ec19f to test.
>
> Something else: I'm running a amd64 distribution, if that's somehow relevant.
No, this is completely irrelevant here.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
_______________________________________________
xorg-team mailing list
xorg-team@xxxxxxxxxxx
http://lists.x.org/mailman/listinfo/xorg-team
-- 
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx