So my el-cheapo UHD Dell monitor is unhappy with dmps, and just never wakes up from it.
I work around it with just doing "xset -dpms" and it's not a big deal, but I thought I'd report it anyway, since there are actual debug messages, and maybe there's a better way to handle it. Does anybody have any idea of why it would do this:
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 111 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00 d1 c0 d1 00 7f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 240 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 87 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 35 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00 d1 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 212 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
it looks like the beginning is the same, but then it just turns to all ones at a random point (even *within* a byte).
Does anything spring to mind?
Linus
Linus Torvalds torvalds@linux-foundation.org writes:
it looks like the beginning is the same, but then it just turns to all ones at a random point (even *within* a byte).
Looks like the EDID ROM is dropping off the i2c bus in the middle of the transfer. Wonder if it's being 'clever' if things go too slowly at some point, or if there's a bug in the DDC code that's in use.
On Tue, Jan 06, 2015 at 10:07:58PM -0800, Keith Packard wrote:
- PGP Signed by an unknown key
Linus Torvalds torvalds@linux-foundation.org writes:
it looks like the beginning is the same, but then it just turns to all ones at a random point (even *within* a byte).
Looks like the EDID ROM is dropping off the i2c bus in the middle of the transfer. Wonder if it's being 'clever' if things go too slowly at some point, or if there's a bug in the DDC code that's in use.
FWIW, I've seen that exact symptom on some monitors when the +5V pin on the DVI or HDMI cable from the GPU isn't enabled (or isn't providing enough current). Some monitors power the i2c/edid/DDC logic from that +5V either exclusively or when in the DPMS off state, and the i2c chip will just stop responding after a few cycles if not provided sufficient power.
- Robert
Robert Morell rmorell@nvidia.com writes:
FWIW, I've seen that exact symptom on some monitors when the +5V pin on the DVI or HDMI cable from the GPU isn't enabled (or isn't providing enough current). Some monitors power the i2c/edid/DDC logic from that +5V either exclusively or when in the DPMS off state, and the i2c chip will just stop responding after a few cycles if not provided sufficient power.
Makes sense -- the chip will power itself from the i2c when not transmitting, and can talk until whatever energy is stored in various capacitors on the Vcc rail discharge.
On Tue, Jan 6, 2015 at 10:21 PM, Robert Morell rmorell@nvidia.com wrote:
FWIW, I've seen that exact symptom on some monitors when the +5V pin on the DVI or HDMI cable from the GPU isn't enabled (or isn't providing enough current). Some monitors power the i2c/edid/DDC logic from that +5V either exclusively or when in the DPMS off state, and the i2c chip will just stop responding after a few cycles if not provided sufficient power.
That makes a ton of sense, especially the "when in DPMS off state" case.
I'll do the drm.debug=0xe thing, and maybe Daniel can make more sense of the details. Maybe the i2c driver ends up powering down too soon (or maybe it needs to power up a bit earlier)?
This is a bog-standard intel motherboard (DH87RL), but I actually needed to update the BIOS for it to get it to POST reliably with this monitor. I was blaming that on the odd 3840x2160@30Hz mode, but maybe it's related to the EDID being finicky wrt i2c power.
I'm assuming even the hdmi +5V line is under sw control at least for power management reasons. Maybe dpms off turns it off, and shouldn't? My monitor actually says "No HDMI (HML) Cable" when I do "xset dpms force off". Maybe that's normal, but maybe that's indicative of dpms turning things a bit *too* off?
Linus
On Wed, Jan 7, 2015 at 6:07 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Jan 6, 2015 at 10:21 PM, Robert Morell rmorell@nvidia.com wrote:
FWIW, I've seen that exact symptom on some monitors when the +5V pin on the DVI or HDMI cable from the GPU isn't enabled (or isn't providing enough current). Some monitors power the i2c/edid/DDC logic from that +5V either exclusively or when in the DPMS off state, and the i2c chip will just stop responding after a few cycles if not provided sufficient power.
That makes a ton of sense, especially the "when in DPMS off state" case.
I'll do the drm.debug=0xe thing, and maybe Daniel can make more sense of the details. Maybe the i2c driver ends up powering down too soon (or maybe it needs to power up a bit earlier)?
This is a bog-standard intel motherboard (DH87RL), but I actually needed to update the BIOS for it to get it to POST reliably with this monitor. I was blaming that on the odd 3840x2160@30Hz mode, but maybe it's related to the EDID being finicky wrt i2c power.
I'm assuming even the hdmi +5V line is under sw control at least for power management reasons. Maybe dpms off turns it off, and shouldn't? My monitor actually says "No HDMI (HML) Cable" when I do "xset dpms force off". Maybe that's normal, but maybe that's indicative of dpms turning things a bit *too* off?
Not sure whether that'd be the same voltage rails, but i915.disable_power_wells=0 disable all the runtime pm we do (which does kick in for dpms off and shut down the entire display block and a bunch more). Maybe we just need to detect that the chip dropped off the bus and retry after 50ms (to give the caps some time to charge). -Daniel
On Wed, Jan 7, 2015 at 9:51 AM, Daniel Vetter daniel@ffwll.ch wrote:
Not sure whether that'd be the same voltage rails, but i915.disable_power_wells=0 disable all the runtime pm we do (which does kick in for dpms off and shut down the entire display block and a bunch more)
I still get the "No HDMI (MHL) Cable" with that kernel command line, and the same failure to come back after an extended dpms off.
So it doesn't seem to be related to the runtime pm you do on a chip level.
Linus
Linus Torvalds torvalds@linux-foundation.org writes:
I'm assuming even the hdmi +5V line is under sw control at least for power management reasons. Maybe dpms off turns it off, and shouldn't? My monitor actually says "No HDMI (HML) Cable" when I do "xset dpms force off". Maybe that's normal, but maybe that's indicative of dpms turning things a bit *too* off?
How about getting a breakout cable so we can actually check the +5V line to see when it turns off?
Total Phase makes one, although they only have the DVI ones in stock. A couple of HDMI to DVI converters would let you use this.
http://www.totalphase.com/products/video-dvi/
I've even got an i2c protocol sniffer if you want to see what's going on the DDC bus directly.
On Wed, Jan 7, 2015 at 3:01 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
So my el-cheapo UHD Dell monitor is unhappy with dmps, and just never wakes up from it.
I work around it with just doing "xset -dpms" and it's not a big deal, but I thought I'd report it anyway, since there are actual debug messages, and maybe there's a better way to handle it. Does anybody have any idea of why it would do this:
Yeah if the edid probe fails userspace will get a hotplug and autodisable the output. With a failsafe X session (just a dumb terminal) we can avoid that to check that dpms on itself would work or whether the edid probe fail here is just indicative of more trouble. Also please boot with drm.debug=0xe, repro and grab dmesg, that might shed some more light on what's failing.
Thanks, Daniel
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 111 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00 d1 c0 d1 00 7f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 240 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 87 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 35 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00 d1 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 212 Raw EDID: 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
it looks like the beginning is the same, but then it just turns to all ones at a random point (even *within* a byte).
Does anything spring to mind?
Linus
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jan 6, 2015 at 11:32 PM, Daniel Vetter daniel@ffwll.ch wrote:
Yeah if the edid probe fails userspace will get a hotplug and autodisable the output. With a failsafe X session (just a dumb terminal) we can avoid that to check that dpms on itself would work or whether the edid probe fail here is just indicative of more trouble. Also please boot with drm.debug=0xe, repro and grab dmesg, that might shed some more light on what's failing.
Here is an annotated attachment with the dpms off output witj drm.debug=0xe.
It turns out the real failure case doesn't seem to be when the bad EDID happens. See my notes interspersed with the dmesg output.
Linus
On Wed, Jan 7, 2015 at 6:51 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Jan 6, 2015 at 11:32 PM, Daniel Vetter daniel@ffwll.ch wrote:
Yeah if the edid probe fails userspace will get a hotplug and autodisable the output. With a failsafe X session (just a dumb terminal) we can avoid that to check that dpms on itself would work or whether the edid probe fail here is just indicative of more trouble. Also please boot with drm.debug=0xe, repro and grab dmesg, that might shed some more light on what's failing.
Here is an annotated attachment with the dpms off output witj drm.debug=0xe.
It turns out the real failure case doesn't seem to be when the bad EDID happens. See my notes interspersed with the dmesg output.
Yeah some interesting stuff in there, but no idea why your screen is ragequitting. - The edid fail is indeed transiet. There's a bunch of hpd flip-flop and some screaming (looks like crappy hw booting), but eventually the kernel gets the full edid and mode list when you kick your hdmi screen. But ofc the kernel doesn't do modeset since that's already done. Have you tried whether a force full modeset with xrandr --off/--auto fixes anything? - There's nothing different for the deep-sleep dpms cycle that fails to light up on the sink side - no errors from the modeset and no hpd from the screen. - But there is a difference on what userspace does: Somehow an additionl very fast dpms off/on sneaks in when waking things up. Dunno where that's from, but fickle screens tend to get upset by that. Maybe try with the UXA backend in xorg.conf (which has a slightly different dpms handling):
Section "Device" Identifier "igd" Driver "intel" Option "AccelMethod" "UXA" EndSection
Otherwise I draw a blank. For the record do you know the old/new bios versions, in case I can get hold of them and get a real changelog? -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Keith Packard -
Linus Torvalds -
Robert Morell