Bug 91864

Summary: [SKL Regression] 2D and 3D accelerated programs are slow after booting on 4.2.0-rc8 drm-intel-nightly kernel
Product: DRI Reporter: Olivier Berthier <olivierx.berthier>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED NOTOURBUG QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: medium CC: intel-gfx-bugs
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:
Description Flags
dmesg log file
kern.log file
Xor.0.log file
piglit sanity test result
dmesg log file with all drm.debug tags
startx stderr log
xsession-errors file none

Description Olivier Berthier 2015-09-03 12:34:07 UTC
Created attachment 118062 [details]
dmesg log file

2D and 3D accelerated programs become slow with all drm-intel kernels after booting on 4.2.0-rc8 drm-intel-nightly.

Setup :

Platform: SKY LAKE Y A0 
CPU : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz (family: 6, model: 78  stepping: 3)
MCP : SKL-Y  D1 2+2 (ou ULX-D1)
Chipset PCH: Sunrise Point LP C1       
Reworks : All Mandatories + FBS02,FBS03, F23, O-02 & O-06

BIOS : SKLSE2R1.R00.X093.B02.1507222151 07/22/2015
Ksc (EC FW): 1.15
Linux : Ubuntu 14.04 LTS 64 bits

Kernel : 4.2.0-rc8 drm-intel-nightly
commit 78a01ed08ac09d84cb47db59dd10fe9de1ee6c4a
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Aug 31 18:43:56 2015 +0300

    drm-intel-nightly: 2015y-08m-31d-15h-42m-59s UTC integration manifes

cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d
libdrm: (HEAD, origin/master, origin/HEAD, master) c3301d013444b7b5d02c58307e188e292d8cf18a
mesa: (HEAD, origin/10.6) 99793e2541510fe208d29e69fedf97a6fff006f8
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master) 9b0ed16385ae076c262a2e09639822d9488ccf57
xserver: (HEAD, origin/master) 533fb627398e20f863234d780f4463e37007515b

Steps :
1. Boot on the 4.2.0-rc8 drm-intel-nightly kernel.
2. Use the system.
3. Reboot on the 4.2.0-rc8 drm-intel-testing-2015-08-28 or older kernel (eg. 4.2.0-rc4 drm-intel-testing-2015-07-31) .
4. Use the system.

Actual result :
On step 2, the Unity desktop environment is slow, and after rebooting on another kernel (steps 4), the system kept to be slow. This has an impact on all 2D and 3D applications and the test suites (see the piglit sanity test result file). On Unity environment, compiz is now a very heavy cost process on the CPU.

Expected result :
No lag on all kernels.

Also tested with mesa on origin/master, same result.
Comment 1 Olivier Berthier 2015-09-03 12:34:38 UTC
Created attachment 118063 [details]
kern.log file
Comment 2 Olivier Berthier 2015-09-03 12:35:02 UTC
Created attachment 118064 [details]
Xor.0.log file
Comment 3 Olivier Berthier 2015-09-03 12:35:37 UTC
Created attachment 118065 [details]
piglit sanity test result
Comment 4 Chris Wilson 2015-09-03 16:01:03 UTC
The trigger is mesa/dri2 not loading:

[    10.124] (EE) AIGLX error: Calling driver entry point failed
[    10.125] (EE) AIGLX: reverting to software rendering
[    10.218] (II) AIGLX: Loaded and initialized swrast
[    10.218] (II) GLX: Initialized DRISWRAST GL provider for screen 0

which I guess is due to no context support. One most likely error from the kernel is

Sep  3 11:40:41 SKLY7 kernel: [    6.301563] [drm:guc_fw_fetch] before requesting firmware: GuC fw fetch status PENDING
Sep  3 11:40:41 SKLY7 kernel: [    6.302057] i915 0000:00:02.0: Direct firmware load for i915/skl_guc_ver3.bin failed with error -2
Sep  3 11:40:41 SKLY7 kernel: [    6.302068] [drm:guc_fw_fetch] GuC fw fetch status FAIL; err -2, fw           (null), obj           (null)
Sep  3 11:40:41 SKLY7 kernel: [    6.302166] [drm:intel_guc_ucode_init [i915]] *ERROR* Failed to fetch GuC firmware from i915/skl_guc_ver3.bin (error -2)
Sep  3 11:40:41 SKLY7 kernel: [    6.309483] [drm:intel_guc_ucode_load] GuC fw status: fetch FAIL, load NONE
Sep  3 11:40:41 SKLY7 kernel: [    6.309562] [drm:intel_guc_ucode_load] GuC fw fetch status FAIL
Sep  3 11:40:41 SKLY7 kernel: [    6.309674] [drm:i915_gem_init_hw [i915]] *ERROR* Failed to initialize GuC, error -5 (ignored)

which is meant to be ignored. However, the dmesg lacks the logging (needs drm.debug|=1) to see why the context failed.
Comment 5 Olivier Berthier 2015-09-03 17:15:04 UTC
Created attachment 118070 [details]
dmesg log file with all drm.debug tags

This file must contain all drm.debug tags.
Comment 6 Chris Wilson 2015-09-03 17:57:30 UTC
Ok, that scratched my theory. No unexpected errors from a drm_ioctl(). Then again, no attempt to create a context either. Can you search for something like lightdm/:0.log ? Or start X from a VT and see if any addition warnings are written out to stderr to explain why mesa fails to load?
Comment 7 Olivier Berthier 2015-09-04 08:54:59 UTC
Created attachment 118074 [details]
startx stderr log
Comment 8 Olivier Berthier 2015-09-04 08:58:28 UTC
Created attachment 118075 [details]
xsession-errors file

I add startx stderr and xsession-errors files.
Maybe this is related to these two lines :

libGL error: pci id for fd 4: 8086:191e, driver (null)
i965_dri.so does not support the 0x191e PCI ID.
Comment 9 Chris Wilson 2015-09-04 09:05:54 UTC
(In reply to Olivier Berthier from comment #8)
> Created attachment 118075 [details]
> xsession-errors file
> I add startx stderr and xsession-errors files.
> Maybe this is related to these two lines :
> libGL error: pci id for fd 4: 8086:191e, driver (null)
> i965_dri.so does not support the 0x191e PCI ID.

Yes, X is not using the right i965_dri.so. No idea how different kernels affect that, and that should not be impacting 2D either.
Comment 10 Olivier Berthier 2015-09-16 14:56:34 UTC
For the 2D, I think it's because compiz was very slow.
I had this problem when I have installed Ubuntu 14.04.3 LTS instead of Ubuntu 14.04 LTS. My script for the installation of the graphic stack had automatically removed some package with a suffix like *-lts-vivid so I don't think it's a Sky Lake regression, just a none support from some packages.

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.