All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: [Bug 64858] New: Nouveau sees invalid EDID for eDP-1 whenever that display is turned off
Date: Wed, 22 May 2013 09:50:15 +0000	[thread overview]
Message-ID: <bug-64858-8800@http.bugs.freedesktop.org/> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2902 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=64858

          Priority: medium
            Bug ID: 64858
          Assignee: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
           Summary: Nouveau sees invalid EDID for eDP-1 whenever that
                    display is turned off
        QA Contact: xorg-team-go0+a7rfsptAfugRpC6u6w@public.gmane.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: gspreemann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: unspecified
         Component: Driver/nouveau
           Product: xorg

With kernel 3.8.8 and 3.9.0, nouveau sees an EDID with incorrect checksum for
the display on eDP-1 as soon as that connector is turned off. Repeatedly
re-fetching that EDID causes so much stuttering that the system becomes
unusuable. A kworker thread rises to near 100% CPU usage, so I suspect the EDID
is being re-fetched repeatedly. Turning the connector back on restores normal
behavior (the correct EDID, with correct checksum, is obtained, and there is no
stuttering). Kernel 3.5.7.9 did not behave like this.

Extracting the correct EDID when the display is on and supplying it as a custom
EDID does not seem to prevent re-fetching of the invalid one. Passing
drm_kms_helper.poll=0 does not seem to prevent the re-fetching either.

I apologize in advance if it turns out that it is in fact my hardware that
simply supplies the wrong EDID when the display is turned off. In that case,
maybe one could add an option to stop re-fetching after N failed checksums? (I
guess that's not in the domain of nouveau, though...)

Device: 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS
3100M] (rev a2)

Example of kernel message:
[  169.657456] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 64
[  169.657461] Raw EDID:
[  169.657464]          00 ff ff ff ff ff ff 00 06 af 47 41 00 00 00 00
[  169.657465]          22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[  169.657466]          01 01 01 01 01 01 94 25 a0 3e 51 84 0c 30 40 20
[  169.657468]          33 00 2f bd 10 00 00 1a 0d 19 a0 3e 51 84 0c 30
[  169.657469]          40 20 33 00 2f bd 10 00 00 1a 00 00 00 fe 00 43
[  169.657470]          43 58 4d 57 80 42 31 34 31 50 57 34 00 00 00 00
[  169.657471]          00 00 41 21 1e 00 00 00 00 09 01 0a 20 20 00 9d
[  169.657473]          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  171.713571] nouveau E[     I2C][0000:01:00.0] AUXCH(1): tx req timeout
0x01114000

(The tx req timeout message is not always present. The EDID checksum failure is
repeated for as long as eDP-1 is disabled. As soon as eDP-1 is turned on, the
messages stop appearing and the stuttering described above stops.)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4195 bytes --]

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

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

             reply	other threads:[~2013-05-22  9:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22  9:50 bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ [this message]
     [not found] ` <bug-64858-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
2013-05-22 10:08   ` [Bug 64858] Nouveau sees invalid EDID for eDP-1 whenever that display is turned off bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-05-22 10:18   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-05-25 14:46   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-05-25 14:48   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-05-25 16:26   ` [Bug 64858] [BISECTED] " bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-05-27  8:04   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-08-28  8:11   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-08-28 17:04   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-08-28 17:17   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-08-31  1:49   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-09-01 13:08   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2013-10-02  7:28   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
2019-12-04  8:34   ` bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-64858-8800@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon-cc+yj3umiyqdupfqwhejaq@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.