*sigh* some more info please. Which machine, what dmesg, etc.

There is no dmesg, the problem is that the igt testcase skips:

IGT-Version: 1.12-ge10ba6b (x86_64) (Linux: 4.4.0-rc2-gfxbench+ x86_64)
Runtime PM support: 1
PC8 residency support: 0
Test requirement not met in function enable_one_screen, file pm_rpm.c:332:
Test requirement: enable_one_screen_with_type(data, SCREEN_TYPE_ANY)
Last errno: 22, Invalid argument
Subtest basic-rte: SKIP (2.489s)

The machine is bsw-nuc-2 (we only have 1 bsw in CI).

Afaik the issue is that this bsw machines only supports outputs that work on pipe C (as can be seen that the crc-pipe tests skip for both A and B), but pm_rpm only tries to light up pipe A. The fix is to teach pm_rpm to try any of the crtc, if pipe A can't be light up).

So this is a bug in the test suite, not in the kernel.

Sorry for the inclarity.

(In reply to Daniel Vetter from comment #2)
> 
> The machine is bsw-nuc-2 (we only have 1 bsw in CI).
> 
> Afaik the issue is that this bsw machines only supports outputs that work on
> pipe C (as can be seen that the crc-pipe tests skip for both A and B), but
> pm_rpm only tries to light up pipe A. The fix is to teach pm_rpm to try any
> of the crtc, if pipe A can't be light up).

To clarify a bit more; The machine has HDMI on port D, and DP->VGA bridge on port B or C (can't recall which). Port D can be driven with pipe C only, port B/C can be drive with pipe A/B only. We have only HDMI plugged in so we need to use pipe C. We could work around the problem by plugging something into the VGA connector, but it would be better to fix the test instead.

I gather the problem is this line in init_modeset_params_for_type():

	params->crtc_id = data->res->crtcs[0];

and that should take into account the encoder possible crtcs. Is that right?

Bug scrub:
Assigned to Paulo

(In reply to Jani Nikula from comment #4)
> I gather the problem is this line in init_modeset_params_for_type():
> 
> 	params->crtc_id = data->res->crtcs[0];
> 
> and that should take into account the encoder possible crtcs. Is that right?

Yes, I assumed anything would work on pipe A.

Maybe we could try to use the atomic interfaces to try multiple CRTCs :)

Another possibility would be to convert the test to use the igt_kms interface, but the last time I tried to do that I gave up since it just hides the lower-level libdrm things in favor of its own structures. It also lacks documentation.

(In reply to Paulo Zanoni from comment #6)
> (In reply to Jani Nikula from comment #4)
> > I gather the problem is this line in init_modeset_params_for_type():
> > 
> > 	params->crtc_id = data->res->crtcs[0];
> > 
> > and that should take into account the encoder possible crtcs. Is that right?
> 
> Yes, I assumed anything would work on pipe A.
> 
> Maybe we could try to use the atomic interfaces to try multiple CRTCs :)
> 
> Another possibility would be to convert the test to use the igt_kms
> interface, but the last time I tried to do that I gave up since it just
> hides the lower-level libdrm things in favor of its own structures. It also
> lacks documentation.

Even better: just call kmstest_get_connector_config() (or extract part of its code to a new function and call it).

Bug scrub:
Hi Paulo,
What the progress on this?

Created attachment 120839 [details] [review]
Possible fix

Hello

Can you please confirm the following patch fixes the problem?

Thanks,
Paulo

C(In reply to Paulo Zanoni from comment #9)
> Created attachment 120839 [details] [review] [review]
> Possible fix
> 
> Hello
> 
> Can you please confirm the following patch fixes the problem?

Christophe, please test the patch on IGT.

Oh, well, since I had some confidence in the patch and since this was taking some time, I just sent the patch to the list, got an Ack from Daniel and merged it today.

I suppose not we have to keep an eye on the IGT results page for pm_rpm/basic-rte and see if the squares turn green on BSW.

I just took a look at the results page see occasional green squares on bsw-nuc-2. The bug description suggests that without a fix I'd only see gray. So I'm closing the bug since the patch was merged and I believe this is fixed. Please reopen if that's not the case.

Double checked on my BSW with one screen connected
35 tests are Pass (2 basic tests are Pass), 8 are skip

So closed.


Hardware: Acer Desktop
Motherboard: Aspire XC-704
CPU: Intel(R) Pentium(R) CPU N3700 @ 1.60GHz (Family 6, Model 76, Stepping 3)
GPU:  Intel® HD Graphics - Intel Corporation Device 22b1 (rev 21)
Memory card: 1 card 4GB Hynix HMT451S6BFR8APB
HDD: Western Digital WDC WD10EZEX-21M (1TB)

Software:
Bios: R01-A2
Linux distribution: Ubuntu 16.04 64 bits
Kernel: 4.8.0-rc2 f53a8d1 from http://cgit.freedesktop.org/drm-intel/
    commit f53a8d1853e8a97ad4a6308ffa8a2011fbd80467
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Fri Aug 19 17:24:52 2016 +0100
    drm-intel-nightly: 2016y-08m-19d-16h-24m-21s UTC integration manifest
libdrm-2.4.70-2 b214b05 from git://anongit.freedesktop.org/mesa/drm
mesa: mesa-11.2.2 3a9f628from git://anongit.freedesktop.org/mesa/mesa
cairo 1.15.2 db8a7f1 from git://anongit.freedesktop.org/cairo
xorg-server-1.18.0- 532 6e5bec2 from git://git.freedesktop.org/git/xorg/xserver
xf86-video-intel 2.99.697 12c14de from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
libva-1.7.0-45 b27feb9 from git://git.freedesktop.org/git/vaapi/libva 
vaapi-intel-driver: 1.7.0-89 b53fad9 from git://git.freedesktop.org/git/vaapi/intel-driver
Intel-Gpu-Tools 1.15 a147ef2 from http://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools.git