Re: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

Re: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Jonathan Nieder]

Hi dri developers,

Two corrupt-EDID/dmesg-spam puzzles for you.  Seems to be a
regression, though I'm not sure from when.

Stuart Pook writes[1]:

> Every 10 seconds I get the messages at the end of my bug report in
> /var/log/kern.log. My /var/log/kern.log is very big!
[...]
> I have a Benq Product Name FP241W manufactured February 2007 Revision
> B4-125 and used to use the DVI input. The EDID data in the DVI input
> suddenly failed and the my PC would not longer boot. I plugged my PC
> into the HDMI input of the monitor and the machine boots but X does not
> start at the correct resolution. It appears that the EDID data from HMDI
> input does not propose "1920x1200".
[...]
> So once X is running
> I unplug my PC from the HDMI input and plug it into the DVI input. All
> works well, the screen saver makes the screen go into standby mode,
> except that the kernel tells me that the EDID data is not correct every
> 10 seconds.  Is there a way to make it stop?
[...]
>	[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 34
>	[drm:drm_edid_block_valid] *ERROR* Raw EDID:
>	<3>a1 80 ff ff ff ff ff 00 09 d1 db 76 be 0f 00 00  ...........v....
>	<3>07 11 01 03 80 34 21 78 ea 5a d5 a7 56 4b 9b 24  .....4!x.Z..VK.$
>	<3>13 50 54 bd ef 80 71 4f 81 90 81 80 81 8c a9 40  .PT...qO.......@
>	<3>b3 00 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20  ......(<..p.#@0 
>	<3>36 00 07 44 21 00 00 1e d5 09 80 a0 20 5e 63 10  6..D!....... ^c.
>	<3>10 60 52 08 78 2d 11 00 00 1a 00 00 00 fd 00 38  .`R.x-.........8
>	<3>4c 1e 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc  L.S...      ....
>	<3>00 42 65 6e 51 20 32 34 31 57 0a 20 20 20 00 dc  .BenQ 241W.   ..

Lisandro Damián Nicanor Pérez Meyer writes[1]:

> With a dual screen setup. Not so long ago (less than a week) both monitors 
> (ViewSonic VG2021wm) were working fine. Somehow the monitor connected to the 
> DVI port started not being detected correctly on boot (wrong edid?). Dmesg 
> shows:
>
> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 54
> [drm:drm_edid_block_valid] *ERROR* Raw EDID:
> <3>00 ff ff ff ff ff ff 00 5a 63 1e d9 01 01 01 01  ........Zc......
> <3>18 11 01 03 0e 2b 1b 78 2e cf c5 a3 5a 49 a0 25  .....+.x....ZI.%
> <3>12 50 54 bf ef 80 81 80 81 40 71 4f 01 01 01 01  .PT......@qO....
> <3>01 01 01 01 01 01 21 39 90 30 62 1a 27 40 68 b0  ......!9.0b.'@h.
> <3>36 00 b1 0e 11 00 00 1c 36 00 00 ff 00 51 44 57  6.......6....QDW
> <3>30 37 32 34 36 30 38 36 37 0a 00 00 00 fd 00 32  072460867......2
> <3>4b 1e 52 11 00 0a 20 20 20 20 20 20 00 00 00 fc  K.R...      ....
> <3>00 56 47 32 30 32 31 77 6d 2d 32 0a 20 20 00 64  .VG2021wm-2.  .d
>
> And so I can't go more than 1024x768 on a 1680x1050 capable LCD. As this was 
> working some days ago, there must have been a regression somewhere :-/
[...]
> On Vie 29 Abr 2011 22:08:09 Jonathan Nieder escribió:

>> Thanks.  Could you try the patch from
>> 
>>   https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7
>> 
>> and see what happens when booting with the drm.edid_strict=0 option?
>
> The patch works perfectly, so at least I have a workaround :-) Thank you!
>
> Now the question is why the DVI port gets a corrupt EDID while the VGA port 
> gets it right. Or maybe the code processing the EDID of the DVI port is wrong?
>
> Don't heasitate in contacting me if I can be of any further help.

Known problem?  Ideas?

Jonathan

[1] There are many more details in the original reports, at
http://bugs.debian.org/622993

https://bugs.freedesktop.org/show_bug.cgi?id=31943 looks vaguely
similar.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Stuart Pook]

On 30/04/11 06:11, Jonathan Nieder wrote:
> Two corrupt-EDID/dmesg-spam puzzles for you.  Seems to be a
> regression, though I'm not sure from when.
>> I have a Benq Product Name FP241W manufactured February 2007 Revision
>> B4-125 and used to use the DVI input. The EDID data in the DVI input
>> suddenly failed and the my PC would not longer boot. I plugged my PC
>> into the HDMI input of the monitor and the machine boots but X does not
>> start at the correct resolution. It appears that the EDID data from HMDI
>> input does not propose "1920x1200".
>> On Vie 29 Abr 2011 22:08:09 Jonathan Nieder escribió:
>>> Thanks.  Could you try the patch from
>>>
>>>    https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7
>>>
>>> and see what happens when booting with the drm.edid_strict=0 option?

thanks, I applied the patch to my 2.6.38-2-amd64 kernel and created /etc/modprobe.d/drm-stuart.conf. Now the DVI input of my screen can be used without an xorg.conf. I can now reboot linux (using kexec) and start the X server using the DVI input of my screen. I still have to use the HDMI input to get past the BIOS.

This is a good patch. Please include it in the mainline kernel!

It appears that it is just the checksum on the DVI-I-1 input of my screen that went bad. I wonder why that happened. I did find reports of this happening to other BenQ 241W screens: http://forums.entechtaiwan.com/index.php?topic=6783.45

I still get a few messages in /var/log/syslog but they stop quickly.

:; cat /etc/modprobe.d/drm-stuart.conf
options drm edid_strict=0

:; grep drm syslog
May  1 12:26:42 kooka kernel: : [    3.839230] [drm] Initialized drm 1.1.0 20060810
May  1 12:26:42 kooka kernel: : [    3.925883] [drm] nouveau 0000:01:00.0: Detected an NV40 generation card (0x04b300b1)
May  1 12:26:42 kooka kernel: : [    3.927833] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN
May  1 12:26:42 kooka kernel: : [    3.969675] [drm] nouveau 0000:01:00.0: ... appears to be valid
May  1 12:26:42 kooka kernel: : [    3.969683] [drm] nouveau 0000:01:00.0: BIT BIOS found
May  1 12:26:42 kooka kernel: : [    3.969687] [drm] nouveau 0000:01:00.0: Bios version 05.73.22.61
May  1 12:26:42 kooka kernel: : [    3.969692] [drm] nouveau 0000:01:00.0: TMDS table version 1.1
May  1 12:26:42 kooka kernel: : [    3.969696] [drm] nouveau 0000:01:00.0: TMDS table script pointers not stubbed
May  1 12:26:42 kooka kernel: : [    3.969701] [drm] nouveau 0000:01:00.0: BIT table 'd' not found
May  1 12:26:42 kooka kernel: : [    3.969705] [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 3.0
May  1 12:26:42 kooka kernel: : [    3.969711] [drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000300 00000028
May  1 12:26:42 kooka kernel: : [    3.969715] [drm] nouveau 0000:01:00.0: Raw DCB entry 1: 03011312 00000000
May  1 12:26:42 kooka kernel: : [    3.969720] [drm] nouveau 0000:01:00.0: Raw DCB entry 2: 04011310 00000028
May  1 12:26:42 kooka kernel: : [    3.969724] [drm] nouveau 0000:01:00.0: Raw DCB entry 3: 020223f1 00c0c080
May  1 12:26:42 kooka kernel: : [    3.969729] [drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x30 5 10 2
May  1 12:26:42 kooka kernel: : [    3.969734] [drm] nouveau 0000:01:00.0:   0: 0x00001030: type 0x30 idx 0 tag 0x07
May  1 12:26:42 kooka kernel: : [    3.969739] [drm] nouveau 0000:01:00.0:   1: 0x00000100: type 0x00 idx 1 tag 0xff
May  1 12:26:42 kooka kernel: : [    3.969745] [drm] nouveau 0000:01:00.0:   2: 0x00000210: type 0x10 idx 2 tag 0xff
May  1 12:26:42 kooka kernel: : [    3.969750] [drm] nouveau 0000:01:00.0:   3: 0x00000211: type 0x11 idx 3 tag 0xff
May  1 12:26:42 kooka kernel: : [    3.969755] [drm] nouveau 0000:01:00.0:   4: 0x00000213: type 0x13 idx 4 tag 0xff
May  1 12:26:42 kooka kernel: : [    3.969764] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xCE4E
May  1 12:26:42 kooka kernel: : [    3.970015] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xD4F8
May  1 12:26:42 kooka kernel: : [    4.024025] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xDC2C
May  1 12:26:42 kooka kernel: : [    4.024049] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xDDB0
May  1 12:26:42 kooka kernel: : [    4.048061] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xDFBF
May  1 12:26:42 kooka kernel: : [    4.069604] [drm] nouveau 0000:01:00.0: 1 available performance level(s)
May  1 12:26:42 kooka kernel: : [    4.069614] [drm] nouveau 0000:01:00.0: 0: memory 400MHz core 400MHz voltage 1170mV fanspeed 100%
May  1 12:26:42 kooka kernel: : [    4.069626] [drm] nouveau 0000:01:00.0: c: memory 405MHz core 400MHz
May  1 12:26:42 kooka kernel: : [    4.069923] [drm] nouveau 0000:01:00.0: Detected 256MiB VRAM
May  1 12:26:42 kooka kernel: : [    4.078114] [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture)
May  1 12:26:42 kooka kernel: : [    4.079598] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
May  1 12:26:42 kooka kernel: : [    4.079604] [drm] No driver support for vblank timestamp query.
May  1 12:26:42 kooka kernel: : [    4.081129] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on vga encoder (output 0)
May  1 12:26:42 kooka kernel: : [    4.081137] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 1)
May  1 12:26:42 kooka kernel: : [    4.081142] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on vga encoder (output 2)
May  1 12:26:42 kooka kernel: : [    4.081148] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on TV encoder (output 3)
May  1 12:26:42 kooka kernel: : [    4.255585] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:42 kooka kernel: : [    4.255598] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:42 kooka kernel: : [    4.281220] [drm] nouveau 0000:01:00.0: allocated 1920x1200 fb: 0x49000, bo ffff880216515800
May  1 12:26:42 kooka kernel: : [    4.291630] [drm] nouveau 0000:01:00.0: 0xC271: Parsing digital output script table
May  1 12:26:42 kooka kernel: : [    4.344012] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 1)
May  1 12:26:42 kooka kernel: : [    4.344016] [drm] nouveau 0000:01:00.0: Output DVI-I-1 is running on CRTC 0 using output A
May  1 12:26:42 kooka kernel: : [    4.345277] drm: registered panic notifier
May  1 12:26:42 kooka kernel: : [    4.345282] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0
May  1 12:26:42 kooka kernel: : [   25.821760] Modules linked in: kvm fuse ipt_MASQUERADE iptable_nat nf_nat ip6t_LOG xt_limit nf_conntrack_ipv6 nf_defrag_ipv6 ts_bm xt_string xt_length ipt_REJECT xt_comment xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_physdev ipt_LOG ip6table_filter ip6_tables iptable_filter ip_tables x_tables isofs loop sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt ftdi_sio btusb bluetooth rfkill usbhid snd_usb_audio hid snd_usbmidi_lib usbsevseg(O) snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm nouveau snd_seq_midi snd_rawmidi snd_seq_midi_event ttmsnd_seq drm_kms_helper usbserial evdev drm(O) cdc_ether usbnet snd_timercdc_phonet cdc_acm snd_seq_device tpm_tis phonet i2c_i801 tpm tpm_bios i2c_algo_bit snd pcspkr serio_raw parport_pc i2c_core parport power_supplyvideo soundcore snd_page_alloc processor button thermal_sys ext4 mbcachejbd2 crc16 dm_mod sg sr_mod sd_mod crc_t
10dif cdrom ata_generic uhci_hcd ahci pata_jmicron libahci ata_piix ehci_hcd libata scsi_mod usbcore r8169 mii nls_base [last unloaded: scsi_wait_scan]
May  1 12:26:43 kooka kernel: : [   26.453489] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:43 kooka kernel: : [   26.453500] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:43 kooka kernel: : [   26.668673] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:43 kooka kernel: : [   26.668681] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:59 kooka kernel: : [   41.916309] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:59 kooka kernel: : [   41.916316] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:59 kooka kernel: : [   42.076590] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:26:59 kooka kernel: : [   42.076596] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:00 kooka kernel: : [   43.252318] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:00 kooka kernel: : [   43.252327] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:00 kooka kernel: : [   43.356667] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:00 kooka kernel: : [   43.577152] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:00 kooka kernel: : [   43.577162] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:00 kooka kernel: : [   43.740480] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:00 kooka kernel: : [   43.740490] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:01 kooka kernel: : [   43.901022] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:01 kooka kernel: : [   43.901030] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:01 kooka kernel: : [   44.064299] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:01 kooka kernel: : [   44.064306] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:01 kooka kernel: : [   44.224782] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:01 kooka kernel: : [   44.224790] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:02 kooka kernel: : [   44.916280] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:02 kooka kernel: : [   44.916291] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:02 kooka kernel: : [   45.087196] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34
May  1 12:27:02 kooka kernel: : [   45.087209] [drm:drm_edid_block_valid]*ERROR* EDID checksum is invalid, remainder is 34

thanks again
Stuart Pook (http://www.pook.it/)

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Thibaut Girka]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

[Sorry for the duplicate mail sent earlier to debian-kernel]

This whole bug really looks like #615598.
This might be a bug in nouveau or in the kernel.

Did the initial "breakage" of the screens occur with 2.6.38?
If so, you may want to try fixing your EDID info has explained in a
similar bug report[1], but be careful, it may cause more harm if
something goes wrong.
If you decided to do so, please check if the corruption appears again.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=34554

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Lisandro Damián Nicanor Pérez Meyer]

[-- Attachment #1: Type: Text/Plain, Size: 951 bytes --]

On Dom 01 May 2011 16:40:39 Thibaut Girka escribió:
> [Sorry for the duplicate mail sent earlier to debian-kernel]
> 
> This whole bug really looks like #615598.
> This might be a bug in nouveau or in the kernel.
> 
> Did the initial "breakage" of the screens occur with 2.6.38?
> If so, you may want to try fixing your EDID info has explained in a
> similar bug report[1], but be careful, it may cause more harm if
> something goes wrong.
> If you decided to do so, please check if the corruption appears again.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=34554

Considering my video card is an Ati, wich I suspect doesn't use nouveau, it 
must not be this last one.

And at least in my case, my card was working with a 2.6.38 kernel without 
problems, except I am missing something here.

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Thibaut Girka]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

Le dimanche 01 mai 2011 à 16:51 -0300, Lisandro Damián Nicanor Pérez
Meyer a écrit :
> On Dom 01 May 2011 16:40:39 Thibaut Girka escribió:
> > [Sorry for the duplicate mail sent earlier to debian-kernel]
> > 
> > This whole bug really looks like #615598.
> > This might be a bug in nouveau or in the kernel.
> > 
> > Did the initial "breakage" of the screens occur with 2.6.38?
> > If so, you may want to try fixing your EDID info has explained in a
> > similar bug report[1], but be careful, it may cause more harm if
> > something goes wrong.
> > If you decided to do so, please check if the corruption appears again.
> > 
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=34554
> 
> Considering my video card is an Ati, wich I suspect doesn't use nouveau, it 
> must not be this last one.

My bad, overlooked it since Stuart uses nouveau. However, it might be
related nonetheless (and might be a completely different issue as well).
Did your monitor fail right after an upgrade?

Anyway, I'd be really interested to hear from Stuart Pook: his story
sounds exactly like mine.

> And at least in my case, my card was working with a 2.6.38 kernel without 
> problems, except I am missing something here.

Your case sounds similar, though.
If the bug is the same, you can easily (even more easily since you have
an identical screen working just fine) fix your screen, using the method
mentioned on fdo.
But I'm no expert, and since this method tempers with your hardware, I'd
recommend you to be cautious.


Regards,
Thibaut Girka.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Lisandro Damián Nicanor Pérez Meyer]

[-- Attachment #1: Type: Text/Plain, Size: 995 bytes --]

On Dom 01 May 2011 17:26:42 Thibaut Girka escribió:
[snip] 
> My bad, overlooked it since Stuart uses nouveau. However, it might be
> related nonetheless (and might be a completely different issue as well).
> Did your monitor fail right after an upgrade?

Yes, but I failed to check the versions of the software I upgraded :-(

[snip]

> Your case sounds similar, though.
> If the bug is the same, you can easily (even more easily since you have
> an identical screen working just fine) fix your screen, using the method
> mentioned on fdo.

Did you mean the patch to tell dri to forget about bad checksums? If so, I 
already tried it and worked fine.

If you are talking about something else, please give me some link :-)

> But I'm no expert, and since this method tempers with your hardware, I'd
> recommend you to be cautious.

OK!

-- 
May the source be with you.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Thibaut Girka]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Le dimanche 01 mai 2011 à 17:47 -0300, Lisandro Damián Nicanor Pérez
Meyer a écrit :
[snip]
> Did you mean the patch to tell dri to forget about bad checksums? If so, I 
> already tried it and worked fine.
> 
> If you are talking about something else, please give me some link :-)

I'm not talking about ignoring broken EDIDs, but about actually fixing
them[1].
If you're fine as it is now, I wouldn't recommend trying it out, though.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=34554#c15

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Lisandro Damián Nicanor Pérez Meyer]

[-- Attachment #1: Type: Text/Plain, Size: 1164 bytes --]

On Dom 01 May 2011 18:09:27 Thibaut Girka escribió:
[snip] 
> I'm not talking about ignoring broken EDIDs, but about actually fixing
> them[1].

This is clearly not my problem. I have two monitors, both the same brand and 
model. One is connected to the VGA output and the other one on the DVI. No 
matter wich one I plug into the DVI port, it detetcts the EDID worngly, while 
the VGA does it correctly.

Or the VGA port is ignoring broken edids even without the "forget broken 
edids" patch, or somehow the DVI port is getting wrong edids, or checksumming 
them wrongly.

Kinds regards, Lisandro.

-- 
"One of the biggest wake-up calls of my career was when I saw a record 
contract.
I said, 'Wait - you sell it for $18.98 and I make 80 cents? And I have to pay
you back the money you lent me to make it and then you own it? Who the f**k
made that rule? Oh! The record labels made it because artists are dumb and
they'll sign anything' - like I did.
  Trent Reznor, Nine Inch Nails on http://contactmusic.com/
  http://tinyurl.com/c2wda4

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Alex Deucher]

2011/5/1 Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>:
> On Dom 01 May 2011 18:09:27 Thibaut Girka escribió:
> [snip]
>> I'm not talking about ignoring broken EDIDs, but about actually fixing
>> them[1].
>
> This is clearly not my problem. I have two monitors, both the same brand and
> model. One is connected to the VGA output and the other one on the DVI. No
> matter wich one I plug into the DVI port, it detetcts the EDID worngly, while
> the VGA does it correctly.
>
> Or the VGA port is ignoring broken edids even without the "forget broken
> edids" patch, or somehow the DVI port is getting wrong edids, or checksumming
> them wrongly.
>

You might try the patch here:
https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7

If you are using a DVI or HDMI port, some TV's don't properly update
their checksums for different ports if they have minor edid changes
for the port.  Also, some hdmi receivers/switches mangle the edids.

Alex

> Kinds regards, Lisandro.
>
> --
> "One of the biggest wake-up calls of my career was when I saw a record
> contract.
> I said, 'Wait - you sell it for $18.98 and I make 80 cents? And I have to pay
> you back the money you lent me to make it and then you own it? Who the f**k
> made that rule? Oh! The record labels made it because artists are dumb and
> they'll sign anything' - like I did.
>  Trent Reznor, Nine Inch Nails on http://contactmusic.com/
>  http://tinyurl.com/c2wda4
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Lisandro Damián Nicanor Pérez Meyer]

[-- Attachment #1: Type: Text/Plain, Size: 860 bytes --]

On Lun 02 May 2011 11:23:48 Alex Deucher escribió:
[snip] 
> You might try the patch here:
> https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7
> 
> If you are using a DVI or HDMI port, some TV's don't properly update
> their checksums for different ports if they have minor edid changes
> for the port.  Also, some hdmi receivers/switches mangle the edids.

Thanks, that's exactly the patch I'm already using. Works perfectly :-)

I should mention that both monitors are VGA, so I'm using a VGA←→DVI adpator. 
And as I said before, it used to work without the patch :-)

Kinds regards, Lisandro.

-- 
My favourite poem is the one that starts
'Thirty days hath September' because
it actually tells you something.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Alex Deucher]

2011/5/2 Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>:
> On Lun 02 May 2011 11:23:48 Alex Deucher escribió:
> [snip]
>> You might try the patch here:
>> https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7
>>
>> If you are using a DVI or HDMI port, some TV's don't properly update
>> their checksums for different ports if they have minor edid changes
>> for the port.  Also, some hdmi receivers/switches mangle the edids.
>
> Thanks, that's exactly the patch I'm already using. Works perfectly :-)
>
> I should mention that both monitors are VGA, so I'm using a VGA←→DVI adpator.
> And as I said before, it used to work without the patch :-)

Can you bisect?  I suspect the culprit is one of the patches that made
the kernel edid parser more strict.  Alternatively, you may have been
using ums previously which does not have the same strict checks as the
kernel.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Lisandro Damián Nicanor Pérez Meyer]

[-- Attachment #1: Type: Text/Plain, Size: 1105 bytes --]

On Monday 02 May 2011 12:25:07 Alex Deucher wrote:
[snip] 
> Can you bisect?  

I really don't know :-) Haven't done it before. On the other hand, I will 
surely not have time to do it until next sunday (if I have time next sunday). 
Sucks, yeah :-/

> I suspect the culprit is one of the patches that made
> the kernel edid parser more strict.  Alternatively, you may have been
> using ums previously which does not have the same strict checks as the
> kernel.

One simple question: is it possible to get the edid info provided by the VGA 
port? In that way one could compare both raw outputs.

-- 
FAQ del pequeño tomi:
P- ¿Porque los programas necesitan tanta RAM hoy?
R- Porque los que programamos somos todos unos subnormales que no
sabemos optimizar nada y nos gusta tener todo en RAM y hacer mmap
a cualquier archivo que queramos acceder en vez de hacerlo como
dios manda (mmap: funcion que mapea un archivo en memoria, no
usar)
  Textual de Martín "El Ruso" Ribelotta

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Stuart Pook]

On 01/05/11 22:26, Thibaut Girka wrote:
> Anyway, I'd be really interested to hear from Stuart Pook: his story
> sounds exactly like mine.

I'm not sure exactly what to say. My screen/PC died on about 23 February. At that time it would not even show BIOS messages. I started to try and understand what was wrong at the end of March. According to a "ls -lrtc /boot" I was probably running 2.6.37-1-amd64 on 23 February. Let me know if you need more information.

I read with interest the report of how to correct a broken EDID. I might give it a go but not before next week.  https://bugs.freedesktop.org/show_bug.cgi?id=34554

> But I'm no expert, and since this method tempers with your hardware, I'd
> recommend you to be cautious.

Yes, especially as I only have one Benq FP241W.

Stuart

Re: Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."

[Lisandro Damián Nicanor Pérez Meyer]

[-- Attachment #1.1.1: Type: text/plain, Size: 4188 bytes --]

=2D-nextPart1707384.WDPpQ5NUxF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

(Sorry if I'm spawning a very old thread here).

After all this time I have been patching my kernels to workaround [0][1=
]

[0] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D624549>
[1] <https://bugs.freedesktop.org/show_bug.cgi?id=3D37040>

Some time ago I found [2] and today I finally solved the problem.

[2] <http://www.blaicher.com/2012/06/howto-fixing-a-broken-edid-eeprom-=
with-a-bus-pirate-v4/>

Some stuff I learned: the kernel does ignores checksums mismatches by 8=
... in=20
the positive side! My mismatch was exactly -1, ie, 255.

I have been modifying the original patch to workaround this since 2011.=
 I'm=20
attaching my last patch in case someone else needs it. It does adds a k=
ernel=20
parameter to ignore edid mismatches.

Kinds regards, Lisandro.


=2D-=20
Theory and practice sometimes clash. And when that happens, theory lose=
s.
Every single time.
  Linus Benedict Torvalds.

Lisandro Dami=E1n Nicanor P=E9rez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

=2D-nextPart1707384.WDPpQ5NUxF
Content-Disposition: attachment; filename="drm-kms-add-a-module-param-to-disable-strict-EDID-3.12.patch"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="UTF-8"; name="drm-kms-add-a-module-param-to-disable-strict-EDID-3.12.patch"

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 830f750..773c5d0 100644
=2D-- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1018,6 +1018,9 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
 		}
 	}
 
+	if (!drm_edid_strict)
+        return 1;
+
 	for (i = 0; i < EDID_LENGTH; i++)
 		csum += raw_edid[i];
 	if (csum) {
@@ -2021,7 +2024,7 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
 	closure->modes += drm_dmt_modes_for_range(closure->connector,
 						  closure->edid,
 						  timing);
=2D	
+
 	if (!version_greater(closure->edid, 1, 1))
 		return; /* GTF not defined yet */
 
@@ -2258,7 +2261,7 @@ do_cvt_mode(struct detailed_timing *timing, void *c)
 
 static int
 add_cvt_modes(struct drm_connector *connector, struct edid *edid)
=2D{	
+{
 	struct detailed_mode_closure closure = {
 		connector, edid, 0, 0, 0
 	};
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 39d8645..487a6ef 100644
=2D-- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -49,6 +49,9 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
 unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 EXPORT_SYMBOL(drm_timestamp_precision);
 
+int drm_edid_strict = 1;   /* 0 to disable strict edid conformance */
+EXPORT_SYMBOL(drm_edid_strict);
+
 /*
  * Default to use monotonic timestamps for wait-for-vblank and page-flip
  * complete events.
@@ -63,12 +66,14 @@ MODULE_PARM_DESC(rnodes, "Enable experimental render nodes API");
 MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable [msecs]");
 MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps [usecs]");
 MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic timestamps");
+MODULE_PARM_DESC(edid_strict, "Strict EDID checks (0 = disable)");
 
 module_param_named(debug, drm_debug, int, 0600);
 module_param_named(rnodes, drm_rnodes, int, 0600);
 module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
 module_param_named(timestamp_precision_usec, drm_timestamp_precision, int, 0600);
 module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
+module_param_named(edid_strict, drm_edid_strict, int, 0600);
 
 struct idr drm_minors_idr;
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b46fb45..b86d239 100644
=2D-- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1462,6 +1462,7 @@ extern unsigned int drm_rnodes;
 extern unsigned int drm_vblank_offdelay;
 extern unsigned int drm_timestamp_precision;
 extern unsigned int drm_timestamp_monotonic;
+extern int drm_edid_strict;
 
 extern struct class *drm_class;
 extern struct dentry *drm_debugfs_root;

=2D-nextPart1707384.WDPpQ5NUxF--
This is a multi-part message in MIME format.

[-- Attachment #1.1.2: Type: text/plain, Size: 1010 bytes --]

(Sorry if I'm spawning a very old thread here).

After all this time I have been patching my kernels to workaround [0][1]

[0] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624549>
[1] <https://bugs.freedesktop.org/show_bug.cgi?id=37040>

Some time ago I found [2] and today I finally solved the problem.

[2] <http://www.blaicher.com/2012/06/howto-fixing-a-broken-edid-eeprom-with-a-bus-pirate-v4/>

Some stuff I learned: the kernel does ignores checksums mismatches by 8... in 
the positive side! My mismatch was exactly -1, ie, 255.

I have been modifying the original patch to workaround this since 2011. I'm 
attaching my last patch in case someone else needs it. It does adds a kernel 
parameter to ignore edid mismatches.

Kinds regards, Lisandro.


-- 
Theory and practice sometimes clash. And when that happens, theory loses.
Every single time.
  Linus Benedict Torvalds.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[-- Attachment #1.1.3: drm-kms-add-a-module-param-to-disable-strict-EDID-3.12.patch --]
[-- Type: text/x-patch, Size: 2682 bytes --]

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 830f750..773c5d0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1018,6 +1018,9 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
 		}
 	}
 
+	if (!drm_edid_strict)
+        return 1;
+
 	for (i = 0; i < EDID_LENGTH; i++)
 		csum += raw_edid[i];
 	if (csum) {
@@ -2021,7 +2024,7 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
 	closure->modes += drm_dmt_modes_for_range(closure->connector,
 						  closure->edid,
 						  timing);
-	
+
 	if (!version_greater(closure->edid, 1, 1))
 		return; /* GTF not defined yet */
 
@@ -2258,7 +2261,7 @@ do_cvt_mode(struct detailed_timing *timing, void *c)
 
 static int
 add_cvt_modes(struct drm_connector *connector, struct edid *edid)
-{	
+{
 	struct detailed_mode_closure closure = {
 		connector, edid, 0, 0, 0
 	};
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 39d8645..487a6ef 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -49,6 +49,9 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
 unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 EXPORT_SYMBOL(drm_timestamp_precision);
 
+int drm_edid_strict = 1;   /* 0 to disable strict edid conformance */
+EXPORT_SYMBOL(drm_edid_strict);
+
 /*
  * Default to use monotonic timestamps for wait-for-vblank and page-flip
  * complete events.
@@ -63,12 +66,14 @@ MODULE_PARM_DESC(rnodes, "Enable experimental render nodes API");
 MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable [msecs]");
 MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps [usecs]");
 MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic timestamps");
+MODULE_PARM_DESC(edid_strict, "Strict EDID checks (0 = disable)");
 
 module_param_named(debug, drm_debug, int, 0600);
 module_param_named(rnodes, drm_rnodes, int, 0600);
 module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
 module_param_named(timestamp_precision_usec, drm_timestamp_precision, int, 0600);
 module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
+module_param_named(edid_strict, drm_edid_strict, int, 0600);
 
 struct idr drm_minors_idr;
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b46fb45..b86d239 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1462,6 +1462,7 @@ extern unsigned int drm_rnodes;
 extern unsigned int drm_vblank_offdelay;
 extern unsigned int drm_timestamp_precision;
 extern unsigned int drm_timestamp_monotonic;
+extern int drm_edid_strict;
 
 extern struct class *drm_class;
 extern struct dentry *drm_debugfs_root;

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel