Bug 28229

Created attachment 35821 [details]
Xorg.0.log-with UMS

When loading radeon module with modeset=1
the dmesg gets flooded with:

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 255
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>02 03 20 f1 4c 05 04 03 14 93 12 01 02 11 15 16  .. .L...........
<3>1e 23 09 07 07 83 01 00 00 66 03 0c 00 10 00 80  .#.......f......
<3>00 1d 00 bc 52 d0 1e 20 b8 28 55 40 bd fa 10 00  ....R.. .(U@....
<3>00 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 bd fa  ......q.. X,%...
<3>10 00 00 9e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00  ........ .-..>..
<3>bd fa 10 00 00 18 01 1d 80 d0 72 1c 16 20 10 2c  ..........r.. .,
<3>25 80 bd fa 10 00 00 9e 01 1d 00 bc 52 d0 1e 20  %...........R.. 
<3>b8 28 55 40 bd fa 10 00 00 1e 00 00 00 00 00 a2  .(U@............

the drmradeonfb also sets a lower resolution than normal (1024x768)

Created attachment 35822 [details]
Xorg.0.log - with KMS

Created attachment 35823 [details]
dmesg-current

Created attachment 35824 [details]
dmesg-boot

I should add that i'm trying drm-radeon-testing from git repository
and i have also tried compiling latest 2.6.34 git from kernel.org.

Just to make it clear what's going on here: the CEA extension block really does have a broken checksum, although it looks correct otherwise.

so i guess it's not a bug then, but isn't there any way to circumvent the problem, other that flashing a new edid or buying a new tv?
(b.t.w i managed to get correct screen resolution in X by using CustomEDID option in xorg.conf with an edid bin i grabbed using 2.6.33.3 kernel, but only if i load X before module, but then i still get no HDMI audio because xf86-video-ati doesn't get the modesetting)

What i thought was strange was that it doesn't react this way on stock 2.6.33.3 kernel. On that kernel HDMI works beautifully with audio.
 i am pretty sure i compiled the kernel correctly.

So i think it may be a regression (or rather progression since my EDID seems to  really be broken) that causes trouble for me with the drm driver.

Should we add a quirk for this particular monitor or add some logic to use edids with faulty checksums?  It would probably be better to attempt to use an edid than to not, at least for digital monitors.

sorry i meant to say 2.6.33.4 that's the stock kernel in slackware64-current

Invalid checksums on CEA extension is a problem I have found on a couple of A/V receivers + TV combinations. The A/V receivers usually try to update the audio infos and CEC physical address in the CEA extension, but sometimes fails to recalculate the checksum of the block.

I would suggest to lower the error to a simple warning and try to use the infos in the extension block anyway.

Created attachment 35839 [details]
edid from "/sys/class/drm/card0-HDMI Type A-1/"

This is the edid it sees when booting with Linux kernel 2.6.33.4.

fixed here:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4a638b4e38234233f5c7e6705662fbc0b58d80c2

Yes that works for me. Now gets the correct output HDMI-0 not VGA, i don't have any 3d anymore though that's a different story...

Created attachment 35862 [details]
dmesg after fix patch

Just wanted u to know that dmesg still get's a lot of these error messages

Thank you! the fix works perfect AFAI can see. I had to apply it manually in the drm-radeon-testing tree since something breaks 3D and XV for me in the d-r-n branch.
but now HDMI picture,audio and 3d is working perfectly for me, using d-r-t branch
with patch applied.

(In reply to comment #16)
> Thank you! the fix works perfect AFAI can see. I had to apply it manually in
> the drm-radeon-testing tree since something breaks 3D and XV for me in the
> d-r-n branch.
> but now HDMI picture,audio and 3d is working perfectly for me, using d-r-t
> branch
> with patch applied.

You need this patch if you are using the drm-next branch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4fa07bf146aaee1e8409d35ab08624041c2e3867