Bug 111837 - GuC submission disabled Linux 5.3.1 on Kaby Lake laptop, worked till 5.2.13
Summary: GuC submission disabled Linux 5.3.1 on Kaby Lake laptop, worked till 5.2.13
Status: RESOLVED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: not set not set
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-27 03:18 UTC by Sayash Kumar
Modified: 2019-10-30 20:17 UTC (History)
2 users (show)

See Also:
i915 platform: KBL
i915 features: firmware/guc


Attachments
Full dmesg 5.3.1 where GuC submission is disabled (89.60 KB, text/plain)
2019-09-27 03:18 UTC, Sayash Kumar
no flags Details

Description Sayash Kumar 2019-09-27 03:18:28 UTC
Created attachment 145537 [details]
Full dmesg 5.3.1 where GuC submission is disabled

Boot linux 5.3.1 with i915.enable_guc=3 on Kaby Lake with Intel Corporation HD Graphics 630 (rev 04) and dmesg has following logs indicating GuC submission is disabled (full log attached, extract pasted below). This worked atleast till 5.2.13:

  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] Incompatible option detected: enable_guc=3, GuC submission not supported!
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] Switching to non-GuC submission mode!
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] VT-d active for gfx access
  Sep 26 19:32:53 gentoo-13r3 kernel: fb0: switching to inteldrmfb from EFI VGA
  Sep 26 19:32:53 gentoo-13r3 kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] Driver supports precise vblank timestamp query.
  Sep 26 19:32:53 gentoo-13r3 kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] GuC: Loaded firmware i915/kbl_guc_32.0.3.bin (version 32.0)
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] CT: enabled
  Sep 26 19:32:53 gentoo-13r3 kernel: i915 0000:00:02.0: GuC firmware version 32.0
  Sep 26 19:32:53 gentoo-13r3 kernel: i915 0000:00:02.0: GuC submission disabled
  Sep 26 19:32:53 gentoo-13r3 kernel: i915 0000:00:02.0: HuC enabled
  Sep 26 19:32:53 gentoo-13r3 kernel: [drm] Initialized i915 1.6.0 20190619 for 0000:00:02.0 on minor 0
  Sep 26 19:32:53 gentoo-13r3 kernel: fbcon: i915drmfb (fb0) is primary device
  Sep 26 19:32:53 gentoo-13r3 kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
  Sep 26 19:32:53 gentoo-13r3 kernel: i915 0000:00:02.0: fb0: i915drmfb frame buffer device
  Sep 26 19:32:53 gentoo-13r3 kernel: mei_hdcp mei::b638ab7e-94e2-4ea2-a552-d1c54b627f04:01: bound 0000:00:02.0 (ops i915_globals_exit [i915])

With GuC submission disabled, the system usually takes 13-14W when idling instead of 6-7W.

On the same hardware, when I go back to linux 5.2.13, with the same module parameters, GuC submission works, with the following extract of dmesg logs:

  Sep 26 19:36:56 gentoo-13r3 kernel: [drm] VT-d active for gfx access
  Sep 26 19:36:56 gentoo-13r3 kernel: fb0: switching to inteldrmfb from EFI VGA
  Sep 26 19:36:56 gentoo-13r3 kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
  Sep 26 19:36:56 gentoo-13r3 kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
  Sep 26 19:36:56 gentoo-13r3 kernel: [drm] Driver supports precise vblank timestamp query.
  Sep 26 19:36:56 gentoo-13r3 kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
  Sep 26 19:36:56 gentoo-13r3 kernel: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
  Sep 26 19:36:56 gentoo-13r3 kernel: [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)
  Sep 26 19:36:56 gentoo-13r3 kernel: mei_hdcp mei::b638ab7e-94e2-4ea2-a552-d1c54b627f04:01: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
  Sep 26 19:36:56 gentoo-13r3 kernel: [drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)
  Sep 26 19:36:56 gentoo-13r3 kernel: i915 0000:00:02.0: GuC firmware version 9.39
  Sep 26 19:36:56 gentoo-13r3 kernel: i915 0000:00:02.0: GuC submission enabled
  Sep 26 19:36:56 gentoo-13r3 kernel: i915 0000:00:02.0: HuC enabled
  Sep 26 19:36:56 gentoo-13r3 kernel: [drm] Initialized i915 1.6.0 20190417 for 0000:00:02.0 on minor 0
  Sep 26 19:36:56 gentoo-13r3 kernel: fbcon: i915drmfb (fb0) is primary device
  Sep 26 19:36:56 gentoo-13r3 kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
  Sep 26 19:36:56 gentoo-13r3 kernel: i915 0000:00:02.0: fb0: i915drmfb frame buffer device

I tried to explicitly point the i915 module in linux 5.3.1 to the firmware it used in 5.2.13 with guc_firmware_path but the system didn't startup with that.

Further system information:

1. uname -m : x86_64
2. uname -r : 5.3.1-gentoo
3. Linux distirbution: Gentoo
4. Machine: Alienware 13R3
5. Display Connector: eDP
6. Attached dmesg (no crash, hence no crash dump to attach)

Reporting a bug with this tool for the first time, apologies if I missed required information or am on the wrong channel.

Thanks.
Comment 1 Lakshmi 2019-09-27 06:29:25 UTC
(In reply to Sayash Kumar from comment #0)
> Created attachment 145537 [details]
> Full dmesg 5.3.1 where GuC submission is disabled
> 
> Boot linux 5.3.1 with i915.enable_guc=3 on Kaby Lake with Intel Corporation
> HD Graphics 630 (rev 04) and dmesg has following logs indicating GuC
> submission is disabled (full log attached, extract pasted below). This
> worked atleast till 5.2.13:

@Daniele, Any comments here?
Comment 2 Daniele Ceraolo Spurio 2019-09-27 16:50:50 UTC
We decided to deprecate support for GuC submission on gen9, also considering the fact that we never made it an "official" non-tainting option and that it had several known bugs. Currently we do not support GuC submission on any gen, but we plan to re-enable it, with a revamped logic, on ICL+. The fact that GuC submission can't be enabled on KBL (which is gen9) is therefore not a bug, but the fact that we get a much higher idle power consumption without it is.
Comment 3 deathlock13 2019-10-03 12:20:35 UTC
"much higher idle power consumption"
1. what about kbl_huc_4.0.0.bin/kbl_guc_ver33_00.bin (build 3150) , is it the same as build 1810 ?
2. what about under workload power consumption ? 4me (Lenovo Y520-15IKBA) for example : mpv+vaapi/firefox runs a lot cooler (according to lm_sensor) with (G/H)uC
3. had a look at kernel 5.4rc1 - looks like it will support kbl_guc_ver33_00.bin
4. I couldn't get pass 'Loading initial ramdisk ...' with i915.enable_guc=3 , but I build mine from src
https://patchwork.kernel.org/patch/11135983  - this got me a bit confused
Comment 4 Daniele Ceraolo Spurio 2019-10-08 20:24:06 UTC
1) I do not have numbers for those at hand, but as far as I'm aware of nothing is changed in the firmwares that would cause a difference in idle power usage

2) Which options are you comparing here? guc=0 and guc=2 or guc=2 and the old guc=3? HuC adds some extra efficiency for media decoding so that might help keeping the power usage down for those workloads with guc=2/3 (if the media driver you're running uses the HuC). Depending on the workload, with guc=3 we're also a bit slower in driving the HW, which means less utilization and therefore less power usage, but also less performance (which is why we're revamping the whole thing).

3) yes, but not by default and not for submission. GuC can will only be used if required to authenticate the HuC

The patch series just introduces new version of the HuC binaries, but we took the occasion to switch to a new naming scheme to make the naming consistent across GuC and Huc.
Comment 5 Sayash Kumar 2019-10-11 03:19:35 UTC
Update:

I discovered the increased power consumption on 5.3 kernels is not due to the changes w/ GuC, or anything to do with i915 at all.

It looks like the snd-hda-intel code can now detect HDMI / DP ports on an Nvidia card on Optimus laptops, and that powers up part of the second GPU, even when no nouveau or nvidia modules are present. That was increasing the power consumption, _not_ i915's changes with GuC.

Sorry for the incorrect bug report, and thanks for the follow ups.


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.