All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 64858] New: Nouveau sees invalid EDID for eDP-1 whenever that display is turned off
@ 2013-05-22  9:50 bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
       [not found] ` <bug-64858-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
  0 siblings, 1 reply; 14+ messages in thread
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2013-05-22  9:50 UTC (permalink / raw)
  To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW


[-- 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

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-12-04  8:34 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-22  9:50 [Bug 64858] New: Nouveau sees invalid EDID for eDP-1 whenever that display is turned off bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ
     [not found] ` <bug-64858-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
2013-05-22 10:08   ` [Bug 64858] " 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

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.