Created attachment 132495 [details]
kernel log

Created attachment 132496 [details]
execution output

(In reply to Armando Antonio from comment #1)
> Created attachment 132495 [details]
> kernel log

Not sure which assert you hit... Why doesn't it print any Critical messages?  Can you run with --debug?

Also, please check the value of fbc_status in debugfs.

Hello, this is the assertion:

(kms_fbcon_fbt:8185) igt-debugfs-DEBUG: Opening debugfs directory '/sys/kernel/debug/dri/0'
(kms_fbcon_fbt:8185) CRITICAL: Test assertion failure function subtest, file kms_fbcon_fbt.c:217:
(kms_fbcon_fbt:8185) CRITICAL: Failed assertion: feature->wait_until_enabled(drm.fd)
(kms_fbcon_fbt:8185) CRITICAL: Last errno: 2, No such file or directory
****  END  ****
Subtest fbc: FAIL (10.101s)
(kms_fbcon_fbt:8185) igt-core-DEBUG: Exiting with status code 99
(kms_fbcon_fbt:8185) igt-kms-DEBUG: VT: original mode 0x0 restored

Created attachment 132739 [details] [review]
debug patch - no fbc reason

(In reply to Armando Antonio from comment #4)
> Hello, this is the assertion:
> 
> (kms_fbcon_fbt:8185) igt-debugfs-DEBUG: Opening debugfs directory
> '/sys/kernel/debug/dri/0'
> (kms_fbcon_fbt:8185) CRITICAL: Test assertion failure function subtest, file
> kms_fbcon_fbt.c:217:
> (kms_fbcon_fbt:8185) CRITICAL: Failed assertion:
> feature->wait_until_enabled(drm.fd)

So, looks like fbc is not enabling. Probably because you don't have enough stolen memory.  you can try going to the BIOS and increase it?

Can you also apply the following patch and provide the output, so we can confirm why the fbc is not loading?

Changing priority since it's IGT non-basic Failure and NEEDINFO for comment #5.

The following test FAIL on IVB with this commit

Tests List:

igt@kms_fbcon_fbt@fbc


This is my configuration:

====================================================
Graphic Stack
====================================================
Component: drm
    tag: libdrm-2.4.81-33-g3876bc2
    commit: 3876bc246a07070a6043159cd7623d4def9bbd4c

Component: cairo
    tag: 1.15.6-2-g57b4050
    commit: 57b40507dda3f58dfc8635548d606b86dc7bcf51

Component: intel-gpu-tools
    tag: intel-gpu-tools-1.19-112-g493151b
    commit: 493151b0768aa4ca535cef49cb7efa174a9c3a77

Component: piglit
    tag: piglit-v1
    commit: 973892687cf5c2f8e2dbe1d22998b82736643787

(In reply to Hector Velazquez from comment #7)
> The following test FAIL on IVB with this commit
> 

Yes, it is a patch to collect information, but I need the entire igt log of the execution

Created attachment 133076 [details]
Tests Log (IVB)

Test and dmesg logs added of the Comment 7....

Created attachment 133077 [details]
Dmesg.log (IVB)

Created attachment 133081 [details]
kernel log

Created attachment 133082 [details]
dmesg log

Attached new info, regards

(In reply to Hector Velazquez from comment #9)
> Created attachment 133076 [details]
> Tests Log (IVB)
> 
> Test and dmesg logs added of the Comment 7....

I don't see the output of my test patch there and I don't see the FBC critical messages like mentioned in Comment 4.  So I suppose we have two crashes, one related to FBC not being enabled, which is "ok", and one that is generating this quite useless trace.   What is the condition that we falsely asserted on in this case:

Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [subtest+0x466]

I'm really confused by this output.

Created attachment 133381 [details]
dmesg log-patch

Created attachment 133382 [details]
kernel log-patch

Created attachment 133383 [details]
test log-patch

Attached new logs with the patch applied. Regards

Also seen on Sandybridge: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_2993/shard-snb3/igt@kms_fbcon_fbt@fbc.html

According to https://intel-gfx-ci.01.org/tree/drm-tip/igt@kms_fbcon_fbt@fbc.html, HSW doesn't fail this test anymore.

CI_DRM_3268 GLK-shards igt@kms_fbcon_fbt@psr-suspend fail:

(kms_fbcon_fbt:1573) CRITICAL: Test assertion failure function subtest, file kms_fbcon_fbt.c:217:
(kms_fbcon_fbt:1573) CRITICAL: Failed assertion: feature->wait_until_enabled(drm.fd)
(kms_fbcon_fbt:1573) CRITICAL: Last errno: 2, No such file or directory
Subtest psr-suspend failed.

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3268/shard-glkb5/igt@kms_fbcon_fbt@psr-suspend.html

Also, CI_DRM_3268 igt@kms_fbcon_fbt@psr fail:

(kms_fbcon_fbt:1534) CRITICAL: Test assertion failure function subtest, file kms_fbcon_fbt.c:217:
(kms_fbcon_fbt:1534) CRITICAL: Failed assertion: feature->wait_until_enabled(drm.fd)
(kms_fbcon_fbt:1534) CRITICAL: Last errno: 2, No such file or directory
Subtest psr failed.

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3268/shard-glkb1/igt@kms_fbcon_fbt@psr.html

(In reply to Marta Löfstedt from comment #22)
> Also, CI_DRM_3268 igt@kms_fbcon_fbt@psr fail:
> 
> (kms_fbcon_fbt:1534) CRITICAL: Test assertion failure function subtest, file
> kms_fbcon_fbt.c:217:
> (kms_fbcon_fbt:1534) CRITICAL: Failed assertion:
> feature->wait_until_enabled(drm.fd)
> (kms_fbcon_fbt:1534) CRITICAL: Last errno: 2, No such file or directory
> Subtest psr failed.
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3268/shard-glkb1/
> igt@kms_fbcon_fbt@psr.html

I submitted a patch to get the feature status when this happens.  Hopefully we will have more information to figure it out.

Patch merged 
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=9fe5a9a3de9e2ce345d5967a1e10a9a586b19836

Resolving.

please check if resolving good or was this only for getting more info...

The issue is still present on SNB-shards:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-snb2/igt@kms_fbcon_fbt@fbc.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-snb3/igt@kms_fbcon_fbt@fbc-suspend.html

The issue is also still present on GLK-shards:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-glkb4/igt@kms_fbcon_fbt@psr.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3317/shard-glkb3/igt@kms_fbcon_fbt@psr-suspend.html

The IGT-Version: 1.20-gbde7d72f (x86_64) (Linux: 4.14.0-rc8-CI-CI_DRM_3317+ x86_64) on mentioned runs indicates that we don't have runs yet when the patch is used.
If you are closing a bug because a patch that may solve the issue has been integrated, please provide patchwork results that indicates that the problem is solved before closing.

(In reply to Jani Saarinen from comment #25)
> please check if resolving good or was this only for getting more info...

Hi Jani,

The patch improves the test to provide more information on the fail.  It is not a fix on itself.

Looking forward for the CI results with the patch applied, though.

Also,
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7096/shard-snb4/igt@kms_fbcon_fbt@fbc-suspend.html

(In reply to Marta Löfstedt from comment #30)
> Also,
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7096/shard-snb4/
> igt@kms_fbcon_fbt@fbc-suspend.html

Here we go.  The patch output was:

(kms_fbcon_fbt:7815) DEBUG: FBC status: FBC disabled: not enough stolen memory

So, we need someone to verify if the BIOS supports increasing the stolen memory on SNB4.  

Several months ago, I submitted a patch to skip tests on cases like this, but it was rejected on the argument that the user should know better and increase the memory.  So, either the BIOS supports it for these machines, or we will have a good point on reviving that patch.

Setting to NEEDINFO until someone at Intel can verify the BIOS.

(In reply to krisman from comment #31)
> (In reply to Marta Löfstedt from comment #30)
> > Also,
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7096/shard-snb4/
> > igt@kms_fbcon_fbt@fbc-suspend.html
> 
> Here we go.  The patch output was:
> 
> (kms_fbcon_fbt:7815) DEBUG: FBC status: FBC disabled: not enough stolen
> memory
> 
> So, we need someone to verify if the BIOS supports increasing the stolen
> memory on SNB4.  
> 
> Several months ago, I submitted a patch to skip tests on cases like this,
> but it was rejected on the argument that the user should know better and
> increase the memory.  So, either the BIOS supports it for these machines, or
> we will have a good point on reviving that patch.
> 
> Setting to NEEDINFO until someone at Intel can verify the BIOS.

krisman, SNB solen memory is handled in bug 103516.
I believe Ville has a patch for that, but I don't know what that is happening to it.

Shard-SNBs have 8GB memory each.

The hardware is Dell XPS 8300 which has very simplistic BIOS, without stolen tuning knobs.

(In reply to Marta Löfstedt from comment #32)

> krisman, SNB solen memory is handled in bug 103516.

Thanks.  Since they are different tests I think we should keep both opened for now.

> I believe Ville has a patch for that, but I don't know what that is
> happening to it.

Ok.  So, next step here is to wait for the following patch to be applied and see if it helps with the issue here:

https://lists.freedesktop.org/archives/intel-gfx/2017-November/145378.html

Ville's patch has been tested already:
https://patchwork.freedesktop.org/series/33060/
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6930/shards.html

(In reply to Tomi Sarvela from comment #35)
> Ville's patch has been tested already:
> https://patchwork.freedesktop.org/series/33060/
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6930/shards.html

Since this flip-flops, I think we should get more tries before closing.

I will close this, since VIlles patch fix the:
igt@kms_fbcon_fbt@fbc and igt@kms_fbcon_fbt@fbc-suspend for SNB.

I created bug 103833 for the GLK-shard PSR related issues.