| Summary: | [bisected HSW ULT]igt/testdisplay -d 16 cause blackscreen with HDMI | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | pengcheng.jiang | ||||||||
| Component: | DRM/Intel | Assignee: | Ville Syrjala <ville.syrjala> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | high | CC: | guang.a.yang, intel-gfx-bugs, qingshuai.tian, yangweix.shui | ||||||||
| Version: | unspecified | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
|
Description
pengcheng.jiang
2013-09-16 08:47:00 UTC
Created attachment 85895 [details]
dmesge_on_HSW_ULT
(In reply to comment #0) > What's more I test with the latest nightly image of 20130916,it also has the > problem. If necessary I can bisect. Yes, I think a bisect would be really useful here. Ville discovered hard hangs when doing modest on HSW, but this seems to be a different issue. And I have no idea what's really going on here ... > Yes, I think a bisect would be really useful here. Ville discovered hard > hangs when doing modest on HSW, but this seems to be a different issue. And > I have no idea what's really going on here ... I have finished bisect, the result shows: e6e792092e816bea0797995c886fb057c91d4546 is the first bad commit commit e6e792092e816bea0797995c886fb057c91d4546 Author: Ville Syrj盲l盲 <ville.syrjala@linux.intel.com> Date: Fri May 31 15:23:41 2013 +0300 drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list Sorry for take some time, the amount of the steps is a little large. What's more, I think the problem may be caused by this mode: CRTS(3):[12] 1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x40 74250 > Yes, I think a bisect would be really useful here. Ville discovered hard > hangs when doing modest on HSW, but this seems to be a different issue. And > I have no idea what's really going on here ... I have finished bisect, the result shows: e6e792092e816bea0797995c886fb057c91d4546 is the first bad commit commit e6e792092e816bea0797995c886fb057c91d4546 Author: Ville Syrj盲l盲 <ville.syrjala@linux.intel.com> Date: Fri May 31 15:23:41 2013 +0300 drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list Sorry for take some time, the amount of the steps is a little large. What's more, I think the problem may be caused by this mode: CRTS(3):[12] 1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x40 74250 (In reply to comment #4) > > Yes, I think a bisect would be really useful here. Ville discovered hard > > hangs when doing modest on HSW, but this seems to be a different issue. And > > I have no idea what's really going on here ... > > I have finished bisect, the result shows: > > e6e792092e816bea0797995c886fb057c91d4546 is the first bad commit > commit e6e792092e816bea0797995c886fb057c91d4546 > Author: Ville Syrj盲l盲 <ville.syrjala@linux.intel.com> > Date: Fri May 31 15:23:41 2013 +0300 > > drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list > > Sorry for take some time, the amount of the steps is a little large. What's > more, I think the problem may be caused by this mode: > CRTS(3):[12] 1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x40 74250 Most likely that mode was already present before your bisect commit. It could be the 1280x720 mode with 72.176 MHz clock. But if the monitor claims to be CEA compatible, then according to the spec it must support both frequencies. Do you have another monitor you can try with the same failing mode? Please attach the EDID for the monitor, and a full log w/ drm.debug=0xe which includes the failing modeset could be helpful. Created attachment 87585 [details]
dmesg of first monitor
I ran "./testdisplay -d 16" with the latest nightly and next-queued kernel of 20131014 on three different monitor in turn. But I can't reproduce this bug.It functioned well.
Then I changed to the nightly kernel of 20130916. This bug appeared on two of them.
The first failed at 832*624 mode.
CRTC(3):[0] 832x624 75 832 864 928 1152 624 625 628 667 0xa 0x40 57284
EDID as follows:
00ffffffffffff000469fa2201010101
2b15010380301b78ea3d25a35951a025
0f5054bfef00714f818081409500a940
b300d1c00101023a801871382d40582c
4500dd0c1100001e000000fd00324c1e
5311000a202020202020000000fc0056
453232380a20202020202020000000ff
0042414c4d51533034303034370a0145
02031ef14b900504030201111213141f
230907078301000065030c0010001a36
80a070381e4030203500dd0c1100001a
662156aa51001e30468f3300dd0c1100
001e011d007251d01e206e285500dd0c
1100001e8c0ad08a20e02d10103e9600
dd0c11000018011d8018711c1620582c
2500dd0c1100009f0000000000000032
Created attachment 87586 [details]
dmesg of second monitor
The second faied at
CRTC(3):[0] 1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000
EDID as follows:
00ffffffffffff005a632b8301010101
33160103803c22782e2595a9544fa126
0a5054bfef80b300a940a9c095008180
010101010101023a801871382d40582c
250055502100001e000000ff00544450
3132353130303031390a000000fd0032
4b0f5e1b000a202020202020000000fc
00565032373730205345524945530127
02032af1559005040302070608090e0f
1f1413121115161d1e0123097f078301
000067030c0010000136023a80187138
2d40582c450055502100001e011d8018
711c1620582c250055502100009e011d
007251d01e206e28550055502100001e
8c0ad08a20e02d10103e960055502100
00180000000000000000000000000025
> CRTC(3):[0] 832x624 75 832 864 928 1152 624 625 628 667 0xa 0x40 57284
> CRTC(3):[0] 1024x768 60 1024 1048 1184 1344 768 771 777 806 0xa 0x40 65000
Neither of these are CEA modes, so I think your bisect result is bogus.
This bug no longer appeared on the latest -nightly kernel(nightlytop_c53fbc_20131015). (In reply to comment #9) > This bug no longer appeared on the latest -nightly > kernel(nightlytop_c53fbc_20131015). Are you sure? This bug seems to be a bit unstable to reproduce since in the past few days there really haven't been any patches which might affect hsw hdmi. Can you please test a few times in a loop to make sure the bug is indeed gone? I tested this case with five different monitor equipped with HDMI. But I still cannot reproduce this bug on the latest -nightly kernel(nightlytop_a6ce64_20131016).Even I changed the kernel back to 2013-10-03,I still cannot reproduce the bug like it apeared in 2013-09-16. Ok, let's close this again and see what happens ... Closing old verified. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.