[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On 02/05/2011 14:17, Jonathan Nieder wrote:
> Vincent Danjean wrote:
>> For info, sometimes ago, I also add a problem with spurious
>> "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."
>> Sorry, I do not remember from which exact kernel version it was. The
>> problems occurs for a second screen on DVI output of a laptop. It was
>> intermittent (ie most of the time, the EDID was correct but sometimes
>> the EDID was read incorrectly and the output was disabled).
> There was recently (v2.6.39-rc2~3^2~24) an interesting fix in the
> area:
> | $ git show v2.6.39-rc2~3^2~24
> | commit 4819d2e4310796c4e9eef674499af9b9caf36b5a
> | Author: Chris Wilson <chris@chris-wilson.co.uk>
> | Date:   Tue Mar 15 11:04:41 2011 +0000
> | 
> |     drm: Retry i2c transfer of EDID block after failure
> |     
> |     Usually EDID retrieval is fine. However, sometimes, especially when the
> |     machine is loaded, it fails, but succeeds after a few retries.
> |     
> |     Based on a patch by Michael Buesch.
> |     
> |     Reported-by: Michael Buesch <mb@bu3sch.de>
> |     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> |     Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
> |     Signed-off-by: Dave Airlie <airlied@redhat.com>
> So I'd be interested in results using the kernel from experimental if
> you're willing.

I'm willing (I usually use the latest packaged kernel). However, if I
followed correctly the debian-kernel ML, the current experimental
kernel does not have the support for Intel wifi 4965 (new 'legacy intel'
config option to enable). So, I'm waiting for the next one.

> It would also be interesting to know approximately
> when "sometimes ago" is --- one month? one year? five years?

I would say a few months.

>>   I "solved" this by adding
>> options drm_kms_helper poll=N
> Someone mentioned this workaround on lkml, too.  I'm not so fond of
> workarounds before fixes; they hide bugs. :)

You are right. However, when there is no special log and its not easy
to reproduce, I usually prefer to wait and see if this is corrected
in next kernels.
  If you want to know, I still have some problems with s2disk. Some
kernel are a better than others but having a failure every 10 s2disk
at best is very inconvenient for a day-to-day working laptop.
I already reported these bugs (even upstream) but, here again, without
specific scenario to reproduce, it is very difficult to even tell if
the bug has been fixed or not. I switched about 2 months ago to use
s2ram instead of s2disk and I did not experiment any crash since.

  For this particular bug (EDID checksum), I can easily try a new
kernel because:
- it is easy to workaround again the problem if the bug is not fixed
- if the bug is still here, I will just have a screen that switch-off
  (and not a crash of the kernel)
So, when a experimental kernel with intel wifi will be available, I
will try and report.


> Thanks, this seems useful.

Vincent Danjean                 Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11            ENSIMAG - antenne de Montbonnot
Fax:        +33 4 76 61 20 99            ZIRST 51, avenue Jean Kuntzmann
Email: Vincent.Danjean@imag.fr           38330 Montbonnot Saint Martin

Reply to: