Bug 96053

The following tests cases fail with the following configuration :


Tests cases
===============================================
igt@pm_rpm@basic-rte
igt@pm_rpm@basic-pci-d3-state


Gfx stack information
===============================================
 --> Component : drm 
	 tag : libdrm-2.4.68-4-g7aab852 
	 commit : 7aab852 
 --> Component : mesa 
	 tag : mesa-11.1.2 
	 commit : 7bcd827 
 --> Component : cairo 
	 tag : 1.15.2 
	 commit : db8a7f1 
 --> Component : intel-gpu-tools
	 tag : intel-gpu-tools-1.14-346-gcce2ff0
	 commit : cce2ff0


Software information
===============================================
Kernel version                      : 4.6.0-rc7-drm-intel-nightly-ww20-commit-5528ede+
Linux distribution                  : Ubuntu 15.10
Architecture                        : 64-bit
Bios revision                       : 138.22
KSC revision                        : 1.12
DMC revision                        : 1.07
GUC revision                        : 8.7


Hardware information
===============================================
Platform                            : BXT-P
Motherboard model                   : Broxton P
Motherboard type                    : NOTEBOOK Hand Held
Motherboard manufacturer            : Intel Corp.
CPU family                          : Other
CPU information                     : 06/5c
GPU Card                            : Intel Corporation Device 5a84 (rev 0a) (prog-if 00 [VGA controller])


kernel
===============================================
commit 2ec823981d62c56d1511bda42b8295e31ece800f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 22 18:23:13 2016 +0200

    drm-intel-nightly: 2016y-05m-22d-16h-22m-45s UTC integration manifest

Luis,
What the result without kernel boot command lines:
maxcpus=1 i915.enable_rc6=0 i915.preliminary_hw_support=1
and use only "processor.max_cstate=2" instead ?

(In reply to cprigent from comment #2)
> Luis,
> What the result without kernel boot command lines:
> maxcpus=1 i915.enable_rc6=0 i915.preliminary_hw_support=1
> and use only "processor.max_cstate=2" instead ?

From the attached dmesg.log:
[    1.768050] [drm] RC6 disabled, disabling runtime PM support

Please keep RC6 enabled for runtime PM tests.

I got the following results:

# ./pm_rpm --run-subtest basic-pci-d3-state --debug
IGT-Version: 1.14-g303b380 (x86_64) (Linux: 4.6.0-drm-intel-nightly-ww23-commit-fb023a2+ x86_64)
(pm_rpm:1945) drmtest-DEBUG: Test requirement passed: fd >= 0
(pm_rpm:1945) drmtest-DEBUG: Test requirement passed: fd >= 0
(pm_rpm:1945) drmtest-DEBUG: Test requirement passed: drmSetMaster(fd) == 0
(pm_rpm:1945) igt-kms-DEBUG: VT: graphics mode set (mode was 0x0)
(pm_rpm:1945) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=1920, height=1080, format=0x34325258, tiling=0x0, size=0)
(pm_rpm:1945) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=1, pitch=7680)
(pm_rpm:1945) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=1920, height=1080, format=0x34325258, tiling=0x0, size=0)
(pm_rpm:1945) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=2, pitch=7680)
Runtime PM support: 1
PC8 residency support: 0
(pm_rpm:1945) DEBUG: Test requirement passed: has_runtime_pm
(pm_rpm:1945) igt-core-DEBUG: Starting subtest: basic-pci-d3-state
(pm_rpm:1945) DEBUG: Test requirement passed: has_runtime_pm
(pm_rpm:1945) DEBUG: device_in_pci_d3: PCI D3 state=3
(pm_rpm:1945) DEBUG: Test requirement passed: enable_one_screen_with_type(data, SCREEN_TYPE_ANY)
(pm_rpm:1945) DEBUG: device_in_pci_d3: PCI D3 state=0
Subtest basic-pci-d3-state: SUCCESS (5.910s)
(pm_rpm:1945) igt-core-DEBUG: Exiting with status code 0
(pm_rpm:1945) igt-kms-DEBUG: VT: original mode 0x0 restored

# ./pm_rpm --run-subtest basic-rte --debug
IGT-Version: 1.14-g303b380 (x86_64) (Linux: 4.6.0-drm-intel-nightly-ww23-commit-fb023a2+ x86_64)
(pm_rpm:1948) drmtest-DEBUG: Test requirement passed: fd >= 0
(pm_rpm:1948) drmtest-DEBUG: Test requirement passed: fd >= 0
(pm_rpm:1948) drmtest-DEBUG: Test requirement passed: drmSetMaster(fd) == 0
(pm_rpm:1948) igt-kms-DEBUG: VT: graphics mode set (mode was 0x0)
(pm_rpm:1948) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=1920, height=1080, format=0x34325258, tiling=0x0, size=0)
(pm_rpm:1948) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=1, pitch=7680)
(pm_rpm:1948) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=1920, height=1080, format=0x34325258, tiling=0x0, size=0)
(pm_rpm:1948) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=2, pitch=7680)
Runtime PM support: 1
PC8 residency support: 0
(pm_rpm:1948) DEBUG: Test requirement passed: has_runtime_pm
(pm_rpm:1948) igt-core-DEBUG: Starting subtest: basic-rte
(pm_rpm:1948) DEBUG: Test requirement passed: enable_one_screen_with_type(data, SCREEN_TYPE_ANY)
Subtest basic-rte: SUCCESS (1.141s)
(pm_rpm:1948) igt-core-DEBUG: Exiting with status code 0
(pm_rpm:1948) igt-kms-DEBUG: VT: original mode 0x0 restored

|=== Software information ===|

 ++ Kernel version                      : 4.6.0-drm-intel-nightly-ww23-commit-fb023a2+
 ++ Linux distribution                  : Ubuntu 16.04 LTS
 ++ Architecture                        : 64-bit
 ++ Mesa version                        : 11.2.2 (git-3a9f628
 ++ xf86-video-intel version            : 2.99.917
 ++ Xorg-Xserver version                : 1.18.3
 ++ DRM version                         : 2.4.68
 ++ VAAPI version                       : Intel i965 driver for Intel(R) Kabylake - 1.7.0
 ++ Cairo version                       : 1.15.2
 ++ Intel GPU Tools version             : Tag [intel-gpu-tools-1.14-348-g303b380] / Commit [303b380]
 ++ Dmc                                 : bxt_dmc_ver1_07

Hardware information
============================

 ++ Platform                            : BXT-P
 ++ Motherboard model                   : Broxton P RVP1A 
 ++ Motherboard manufacturer            : Intel Corp.
 ++ GPU Card                            : Intel Corporation Device 5a84 (rev 0a) (prog-if 00 [VGA controller])
 ++ Memory ram                          : 8 GB

======== Kernel parameters =============
vmlinuz root=/dev/sda2 maxcpus=1 initrd=initrd.img acpi_enforce_resources=lax processor.max_cstate=2 no_console_suspend log_buf_len=4M i915.enable_rc6=1 i915.preliminary_hw_support=1 drm.debug=14 i915.enable_guc_submission=1

(In reply to Luis Botello from comment #4)
> I got the following results:
> 
> # ./pm_rpm --run-subtest basic-pci-d3-state --debug
>[...]
> Subtest basic-pci-d3-state: SUCCESS (5.910s)
>[...]
> Subtest basic-rte: SUCCESS (1.141s)

Can we close this bug based on the above?

>[...]
> vmlinuz root=/dev/sda2 maxcpus=1 initrd=initrd.img
> acpi_enforce_resources=lax processor.max_cstate=2 no_console_suspend
> log_buf_len=4M i915.enable_rc6=1 i915.preliminary_hw_support=1 drm.debug=14
> i915.enable_guc_submission=1

Any particular reason you're booting with the following parameters, they shouldn't be needed AFAICS?:
maxcpus=1 acpi_enforce_resources=lax i915.enable_rc6=1 i915.preliminary_hw_support=1

I think that instead of the processor.max_cstate=2 workaround we should use idle=halt until BIOS is fixed, this is the last suggestion from Len Brown.

Also was there a decision to test things with i915.enable_guc_submission=1? Last that I checked this caused problems and it is disabled now by default for that reason.

(In reply to Imre Deak from comment #5)
> (In reply to Luis Botello from comment #4)
>[...]
> Any particular reason you're booting with the following parameters, they
> shouldn't be needed AFAICS?:
> maxcpus=1 acpi_enforce_resources=lax i915.enable_rc6=1
> i915.preliminary_hw_support=1

Err, i915.preliminary_hw_support is still needed, I have it in enabled in Kconfig.

I have tested both with the same last configuration and the following kernel commands:

vmlinuz root=/dev/sda2 initrd=initrd.img no_console_suspend log_buf_len=4M i915.preliminary_hw_support=1 drm.debug=14 idle=halt

And both test are "pass".

(In reply to Imre Deak from comment #5)
> (In reply to Luis Botello from comment #4)
> > I got the following results:
> > 
> > # ./pm_rpm --run-subtest basic-pci-d3-state --debug
> >[...]
> > Subtest basic-pci-d3-state: SUCCESS (5.910s)
> >[...]
> > Subtest basic-rte: SUCCESS (1.141s)
> 
> Can we close this bug based on the above?
> 
> >[...]
> > vmlinuz root=/dev/sda2 maxcpus=1 initrd=initrd.img
> > acpi_enforce_resources=lax processor.max_cstate=2 no_console_suspend
> > log_buf_len=4M i915.enable_rc6=1 i915.preliminary_hw_support=1 drm.debug=14
> > i915.enable_guc_submission=1
> 
> Any particular reason you're booting with the following parameters, they
> shouldn't be needed AFAICS?:
> maxcpus=1 acpi_enforce_resources=lax i915.enable_rc6=1
> i915.preliminary_hw_support=1
> 
> I think that instead of the processor.max_cstate=2 workaround we should use
> idle=halt until BIOS is fixed, this is the last suggestion from Len Brown.
> 
> Also was there a decision to test things with i915.enable_guc_submission=1?
> Last that I checked this caused problems and it is disabled now by default
> for that reason.

Hi Imre Deak :

actually we noticed a strange behavior with the guc in APL and this parameter "i915.enable_guc_submission=1", only the first time it was loaded correctly the guc, but after reboot the guc is not load anymore, the guc version is 8.7, so you recommend not istall the guc or simply put a different option to enable it ?

(In reply to Humberto Israel Perez Rodriguez from comment #8)
> (In reply to Imre Deak from comment #5)
> > (In reply to Luis Botello from comment #4)
>[...]
> > Also was there a decision to test things with i915.enable_guc_submission=1?
> > Last that I checked this caused problems and it is disabled now by default
> > for that reason.
> 
> Hi Imre Deak :
> 
> actually we noticed a strange behavior with the guc in APL and this
> parameter "i915.enable_guc_submission=1", only the first time it was loaded
> correctly the guc, but after reboot the guc is not load anymore, the guc
> version is 8.7, so you recommend not istall the guc or simply put a
> different option to enable it ?

GUC is disabled in the kernel by default so unless there were explicit instructions for testing GUC I would keep it disabled for now, that is boot without i915.enable_guc_submission=1. I haven't seen any problem booting w/o this kernel parameter, if you do then that should be tracked on a separate ticket.

Closing this bug since test pass now.

Moreover and as advised by Imre, GUC is disabled in the kernel by default and is out scope of this bug. If you notice any issue booting w/o this kernel parameter, please fill a new bug.