This gist will show you how to tune your Intel-based Skylake, Kabylake and beyond Integrated Graphics Core for performance and reliability through GuC and HuC firmware usage on Linux.

skylake-tuning-linux.md

Tuning Intel Skylake and beyond for optimal performance and feature level support on Linux:

Note that on Skylake, Kabylake (and the now cancelled "Broxton") SKUs, functionality such as power saving, GPU scheduling and HDMI audio have been moved onto binary-only firmware, and as such, the GuC and the HuC blobs must be loaded at run-time to access this functionality.

Enabling GuC and HuC on Skylake and above requires a few extra parameters be passed to the kernel before boot.

Instructions provided for both Fedora and Ubuntu (including Debian):

Note that the firmware for these GPUs is often packaged by your distributor, and as such, you can confirm the firmware blob's availability by running:

1. On Fedora:

rpm -ql linux-firmware | fgrep i915

Sample output:

/usr/lib/firmware/i915 
/usr/lib/firmware/i915/bxt_dmc_ver1_07.bin 
/usr/lib/firmware/i915/kbl_dmc_ver1.bin
/usr/lib/firmware/i915/kbl_dmc_ver1_01.bin 
/usr/lib/firmware/i915/skl_dmc_ver1_23.bin 
/usr/lib/firmware/i915/skl_guc_ver1.bin 
/usr/lib/firmware/i915/skl_guc_ver4.bin 
/usr/lib/firmware/i915/skl_guc_ver6.bin 
/usr/lib/firmware/i915/skl_guc_ver6_1.bin 
/usr/share/doc/linux-firmware/LICENSE.i915

2. On Ubuntu:

dpkg -L linux-firmware | fgrep i915

It may be wise to install the linux-firmware-nonfree package as it may contain extra firmware blobs on Ubuntu releases prior to 16.04LTS. Don't install this on 16.04LTS and above.

Now, to the real meat:

See the supported module options:

Let's see if the features we're after are supported:

sudo modinfo i915 | egrep -i "guc|huc|dmc"

firmware:       i915/bxt_dmc_ver1_07.bin
firmware:       i915/skl_dmc_ver1_27.bin
firmware:       i915/kbl_dmc_ver1_04.bin
firmware:       i915/glk_dmc_ver1_04.bin
firmware:       i915/cnl_dmc_ver1_07.bin
firmware:       i915/icl_dmc_ver1_07.bin
firmware:       i915/kbl_guc_ver9_39.bin
firmware:       i915/bxt_guc_ver9_29.bin
firmware:       i915/skl_guc_ver9_33.bin
firmware:       i915/kbl_huc_ver02_00_1810.bin
firmware:       i915/bxt_huc_ver01_8_2893.bin
firmware:       i915/skl_huc_ver01_07_1398.bin
parm:           enable_guc:Enable GuC load for GuC submission and/or HuC load. Required functionality can be selected using bitmask values. (-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load) (int)
parm:           guc_log_level:GuC firmware logging level. Requires GuC to be loaded. (-1=auto [default], 0=disable, 1..4=enable with verbosity min..max) (int)
parm:           guc_firmware_path:GuC firmware path to use instead of the default one (charp)
parm:           huc_firmware_path:HuC firmware path to use instead of the default one (charp)
parm:           dmc_firmware_path:DMC firmware path to use instead of the default one (charp)

Note: The intel_pstate driver is the default since Linux 4.10 on SKL+. Thanks for the updates on this @pcordes and the correction on module options syntax in /etc/modprobe.d/i915.conf, @vinzent. Gr33ts ;-)

Then, update grub on Fedora:

(Run commands as root):

For EFI boot (More common):

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

And if you're still booting up in legacy BIOS mode on an MBR-style partitioning scheme or with CSM enabled on Fedora for whatever reason:

grub2-mkconfig -o /boot/grub2/grub.cfg

Then rebuild initramfs:

On Fedora:

dracut --force

On Debian-based distributions:

Simply run:

sudo update-initramfs

update-grub

Then reboot.

Your modern Intel HD Graphics processor graphics will work just fine.

You can also add this to: /etc/modprobe.d/i915.conf

In the following syntax:

options i915 enable_guc=3

Other safe options to pass are enable_fbc=1.

Reference:

See modinfo output for i915 for available GuC options:

modinfo i915 | grep guc

Further notes:

A list of all options along with short descriptions and default values can be generated with the following command:

$ modinfo -p i915

To check which options are currently enabled, run:

# systool -m i915 -av

You will note that many options default to -1, resulting in per-chip power-saving defaults. It is however possible to configure more aggressive powersaving by using module options. Warning: Diverting from the defaults will mark the kernel as tainted from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers.

The following set of options should be generally safe to enable:

/etc/modprobe.d/i915.conf

options i915 enable_fbc=1 enable_guc=3

On Linux 4.16+, GuC firmware loading and submission is now handled by the enable_guc parameter in place of the former enable_guc_loading=1 and enable_guc_submission=1 parameters. Adjust as needed.

RC6 sleep modes (enable_rc6):

You can experiment with higher values for enable_rc6, but your GPU may not support them or the activation of the other options:

The available enable_dc values are a bitmask with bit values RC6=1, RC6p=2, RC6pp=4[4] - where "RC6p" and "RC6pp" are lower power states.

To confirm the current running RC6 level, you can look in sysfs:

# cat /sys/class/drm/card0/power/rc6_enable

If the value read is a lower number than expected, the other RC6 level are probably not supported. Passing drm.debug=0xe to the kernel boot options will add DRM debugging information to the kernel log - possibly including a line like this:

[drm:sanitize_rc6_option] Adjusting RC6 mask to 1 (requested 7, valid 1)

Framebuffer compression (enable_fbc):

Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:

kernel: drm: not enough stolen space for compressed buffer, disabling.

Tear-free video:

With the SNA acceleration method enabled, tearing may be observed. To fix this, enable the "TearFree" option in the driver by adding the following line to your xorg.conf (or ideally, a sub-configuration file under xorg.conf.d) configuration file:

Option "TearFree" "true"

This is not needed on server-grade SKUs where Xorg is unwelcome.

Debugging:

Simply inspect dmesg:

dmesg | grep drm

And also look at the output of:

journalctl -b -o short-monotonic -k

To confirm that the settings you wanted have been applied, run:

dmesg | grep -iE "huc|guc|dmc"

Output may look like this:

[    2.014699] Setting dangerous option enable_guc - tainting kernel
[    2.019971] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    2.030651] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)
[    2.040648] [drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)
[    2.051850] i915 0000:00:02.0: GuC firmware version 9.39
[    2.051850] i915 0000:00:02.0: GuC submission enabled
[    2.051851] i915 0000:00:02.0: HuC enabled

Which means you're good to go.

You can also take a look at:

1. GuC load status:

sudo cat /sys/kernel/debug/dri/0/i915_guc_load_status

GuC firmware: i915/kbl_guc_ver9_39.bin
	status: fetch SUCCESS, load SUCCESS
	version: wanted 9.39, found 9.39
	header: offset 0, size 128
	uCode: offset 128, size 147392
	RSA: offset 147520, size 256

GuC status 0x800330ec:
	Bootrom status = 0x76
	uKernel status = 0x30
	MIA Core status = 0x3

Scratch registers:
	 0: 	0xf0000000
	 1: 	0x1
	 2: 	0xc
	 3: 	0x0
	 4: 	0x2
	 5: 	0x0
	 6: 	0x7f2000
	 7: 	0x8
	 8: 	0x3
	 9: 	0x403240
	10: 	0x0
	11: 	0x0
	12: 	0x0
	13: 	0x0
	14: 	0x0
	15: 	0x0

2. HuC load status:

sudo cat /sys/kernel/debug/dri/0/i915_huc_load_status

 HuC firmware: i915/kbl_huc_ver02_00_1810.bin
	status: fetch SUCCESS, load SUCCESS
	version: wanted 2.0, found 2.0
	header: offset 0, size 128
	uCode: offset 128, size 218304
	RSA: offset 218432, size 256

HuC status 0x00006080:

Also see: https://01.org/linuxgraphics/downloads/firmware

Screen corruption observed when waking up from suspend

This is often observed as font and screen corruption in GTK+ applications (missing glyphs after suspend/resume).

Should you experience missing font glyphs in GTK+ applications, the following workaround might help. Edit /etc/environment to add the following line:

/etc/environment
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer

See this bug here for more details.

Thanks and regards,

Brainiarc7

Just an update:

I upgraded from Debian 9 to 10 today, upgraded to Linux Kernel 5.2, upgraded firmware-misc-nonfree to 20190717-2 and the HuC/GuC firmwares still won't load. I have these firmware but the system still won't recognize that there are Gemini Lake firmware available to load:

 ls -1 /lib/firmware/i915/
bxt_dmc_ver1_07.bin
bxt_dmc_ver1.bin
bxt_guc_32.0.3.bin
bxt_guc_33.0.0.bin
bxt_guc_ver8_7.bin
bxt_guc_ver9_29.bin
bxt_huc_ver01_07_1398.bin
cnl_dmc_ver1_07.bin
glk_dmc_ver1_04.bin
glk_guc_32.0.3.bin
glk_guc_33.0.0.bin
glk_huc_ver03_01_2893.bin
icl_guc_32.0.3.bin
icl_guc_33.0.0.bin
icl_huc_ver8_4_3238.bin
kbl_dmc_ver1_01.bin
kbl_dmc_ver1_04.bin
kbl_dmc_ver1.bin
kbl_guc_32.0.3.bin
kbl_guc_33.0.0.bin
kbl_guc_ver9_14.bin
kbl_guc_ver9_39.bin
kbl_huc_ver02_00_1810.bin
skl_dmc_ver1_23.bin
skl_dmc_ver1_26.bin
skl_dmc_ver1_27.bin
skl_dmc_ver1.bin
skl_guc_32.0.3.bin
skl_guc_33.0.0.bin
skl_guc_ver1.bin
skl_guc_ver4.bin
skl_guc_ver6_1.bin
skl_guc_ver6.bin
skl_guc_ver9_33.bin
skl_huc_ver01_07_1398.bin

It works starting with the 5.3 Kernel. At least for me with Manjaro

I see. Did you still have to modify the i915.conf file to make it work though? What firmware-misc-nonfree version do you have?

Yes, I still have to set enable_guc=-1, because it's disabled by default.
Manjaro does not have the nonfree firmware package, but that is installed:

linux-firmware 20190815.07b925b-1

-rw-r--r-- 1 root root 8800 16. Aug 08:17 /usr/lib/firmware/i915/glk_dmc_ver1_04.bin
-rw-r--r-- 1 root root 176640 16. Aug 08:17 /usr/lib/firmware/i915/glk_guc_32.0.3.bin
-rw-r--r-- 1 root root 182336 16. Aug 08:17 /usr/lib/firmware/i915/glk_guc_33.0.0.bin
-rw-r--r-- 1 root root 222080 16. Aug 08:17 /usr/lib/firmware/i915/glk_huc_ver03_01_2893.bin

Setting enable_guc to any value makes the monitor output hang upon reboot but I can still SSH into the box and it's working just fine. So there's still something wrong here.

What does GuC and HuC do really? I was able to make QuickSync work even though I can't make the GuC/HuC work.

Typically, they expose low power encoding availability. If you don’t use (or need) that, then there’s no need to force load HuC or GuC. I should update the docs with that disclaimer.

…

On Wed, 25 Sep 2019 at 10:51, Kevin ***@***.***> wrote: Setting enable_guc to any value makes the monitor output hang upon reboot but I can still SSH into the box and it's working just fine. So there's still something wrong here. What does GuC and HuC do really? I was able to make QuickSync work even though I can't make the GuC/HuC work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://gist.github.com/aa43570f512906e882ad6cdd835efe57?email_source=notifications&email_token=AAR7NBZ5ETJ3B6USDHML7ETQLMKBXA5CNFSM4HM342S2YY3PNVWWK3TUL52HS4DFVNDWS43UINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAFZLOW#gistcomment-3036907>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAR7NB7OQ4FJJ2ILNQVK643QLMKBXANCNFSM4HM342SQ> .

I kinda do. I use the CPU for encoding/decoding (conversion of mkv to mp4) and that would help.

So in Debian, is this all that I need to do? What value should I use with enable_guc? I have not updated grub yet. Could that be the issue why my system is hanging and unable to load GuC/HuC?

For the /etc/modprobe.d/i915.conf part, in your docs it says "you can also add this". Does that mean it's optional or required? Sorry, I'm confused with all these.

On Debian-based distributions:

Simply run:

sudo update-initramfs

update-grub

Then reboot.

Your modern Intel HD Graphics processor graphics will work just fine.

You can also add this to: /etc/modprobe.d/i915.conf

In the following syntax:

options i915 enable_guc=3

Other safe options to pass are enable_fbc=1.

But do you use the low power encoding feature set (such as VDENC)?

…

On Wed, 25 Sep 2019 at 11:24, Kevin ***@***.***> wrote: I kinda do. I use the CPU for encoding/decoding (conversion of mkv to mp4) and that would help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://gist.github.com/aa43570f512906e882ad6cdd835efe57?email_source=notifications&email_token=AAR7NB7YJJZG32RVXS64FCLQLMN3RA5CNFSM4HM342S2YY3PNVWWK3TUL52HS4DFVNDWS43UINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAFZLQ2#gistcomment-3036941>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAR7NB7UUBLGDW23AR5KDJ3QLMN3RANCNFSM4HM342SQ> .

I don't think so. As far as I'm aware, the ffmpeg script that I use (I'm not the developer) uses normal VAAPI but if my CPU (J5005) supports VDENC then I'm sure it will "eventually" get supported by the script.

I am an i915 developer, and I would strongly suggest users not to use GuC/HuC on Gen9 unless specifically needed for some media use cases. In this case, use enable_guc=2. Be aware that there are still some bugs, and this is why it is not enabled by default yet!

Thanks for the comment @mupuf

This is way clearer than most wikis out there. I now disabled this parameter to reduce my open risk surface.

I have been using enable_guc=2 with the 5.2 kernel for a while successfully now. I just upgraded to 5.3.9, 5.3.10, then 5.3.11 and was unsuccessful getting the enable_guc option to work. I tried enable_guc=-1 and enable_guc=2 options. When I boot, my system freezes with the final message being "fb: switching to inteldrmfb from EFI VGA". If I switch back to the 5.2 kernel without any other changes, it boots up fine with enable_guc=2, or if I remove the enable_guc option with 5.3 it boots as well (just no guc/huc loads). I have the firmware available that it tries to load with both kernels. Any ideas what could cause this to happen between those two kernel versions? 5.2 is now EOL so I want to get on 5.3 to have the latest security updates.

Also, they specify that the modesetting driver will not be benefited by Intel GuC/HuC/DMC firmware.

@zeronote Who is "they" and where is this cited? Neither on Arch Wiki or the Plasma 5.9 Errata page that was referenced/linked on the Arch Wiki mentions this.

Do not switch to the modesetting driver under any circumstances. Ignore that recommendation by KDE.

@Brainiarc7 can you elaborate on that further as to why? There's plenty of users claiming a better experience on modern hardware with modesetting vs Intel's DDX(which is only useful with X11 btw).

I am an i915 developer, and I would strongly suggest users not to use GuC/HuC on Gen9 unless specifically needed for some media use cases.

@mupuf Does that also apply to Comet Lake(which I've seen referred to as Gen9.5, UHD620?)? Future generations(11/12) are in better shape for GuC/HuC? Will Gen9 improve in 2020 for the advice to avoid GuC/HuC become invalid?

GuC-based command submission is completely unsupported, so enable_guc=1/3 should never be advised for people to use.

Is that intended to stay that way from now on, or will it be revisited at a later date? (EDIT: I see in official docs that it's being rewritten and will be available in future firmware, users ideally don't need these i915.enable_guc tweaks, or can set to -1 and will benefit once support becomes available?)

Could you also confirm above in regards to xf86-video-intel being required for HuC to be of benefit and unavailable via modesetting?

I've also heard that Vulkan support is only available with the X11 Intel DDX, not modesetting, does this tie it to X11? No Vulkan with intel graphics on Wayland natively?

@polarathene: Many questions :D Let's see what I can answer.

Does that also apply to Comet Lake(which I've seen referred to as Gen9.5, UHD620?)? Will Gen9 improve in 2020 for the advice to avoid GuC/HuC become invalid?

Yes, HuC loading is still not fully supported, but work is being done towards enabling it on gen 9+. I can't give an estimate nor a guarantee though.

Is that intended to stay that way from now on, or will it be revisited at a later date? (EDIT: I see in official docs that it's being rewritten and will be available in future firmware, users ideally don't need these i915.enable_guc tweaks, or can set to -1 and will benefit once support becomes available?)

This comment will always remain true. Do not set any parameter and let the kernel do what is best for for you ;) When HuC and/or GuC is ready, it will get loaded automatically for you.

If you need low-power VP9/h265 encoding before that, then you'll need to load the HuC by using enable_guc=2.

Could you also confirm above in regards to xf86-video-intel being required for HuC to be of benefit and unavailable via modesetting?

I fail to see why this would be the case.

I've also heard that Vulkan support is only available with the X11 Intel DDX, not modesetting, does this tie it to X11?

Vulkan definitely works on modesetting, I personally made sure of that by landing DRI3 fixes and assisting to the transition to modesetting.

If anything, it is the Intel DDX that might have issues since it defaults to DRI2 which is not supported by vulkan. That being said, I did not test it myself so take it with a grain of salt and try yourself ;)

No Vulkan with intel graphics on Wayland natively?

Never heard of this issue before. At least, it works for me on my HSW (to some extent, since it is not supported by ANV).

@mupuf Thank you for the prompt and informative response! ❤️

When HuC and/or GuC is ready, it will get loaded automatically for you.

Is the status on Windows 10 different? Or is it leveraging the same efforts being done for Linux?

If you need low-power VP9/h265 encoding before that

Is that the only(or current) benefit from HuC? The official Intel page on the firmware states:

The HEVC/H.265 micro (µ) Controller (HuC) offloads some of the media functions from CPU to the GPU and is utilized by the iHD Intel media driver.

I thought it might have been for more than just encoding video, perhaps decoding as well. I've heard of the Intel Media Driver and VA-API support provided through that, and it seems to handle encoding as well. The HuC is an improvement on that requiring less power to encode video but not decode?

Meanwhile until a later date, the GuC has nothing to offer beyond enabling HuC, but may lead to improved power savings eventually, which will be automatically available via kernel like past features(PSR/FBC) when ready?

---

xf86-video-intel being required for HuC to be of benefit and unavailable via modesetting?
I fail to see why this would be the case.

Vulkan definitely works on modesetting

Thanks for clearing those two up! There's quite a few users and wiki's stating otherwise(albeit lacking sources to the claims).

I personally made sure of that by landing DRI3 fixes and assisting to the transition to modesetting.

That's awesome! :)

So xf86-video-intel should be avoided with Gen 9+ products and modesetting preferred instead?

That being said, I did not test it myself so take it with a grain of salt and try yourself

Will do, Comet Lake system will be arriving this week.

No Vulkan with intel graphics on Wayland natively?
Never heard of this issue before.

That's just a guess/question on my end from those that have stated Vulkan support is only available with the xf86-video-ddx driver instead of modesetting, which if true somehow, would have meant no support without X11. Glad that's not the case!

For ubuntu 19.10 with kernel 5.3.0 on i7-8665u (CoffeeLake) the fix was to set the grub commandline parameter to:
i915.enable_guc=-1

Also, the commands about updating the initramfs don't work. I also don't see why it is necessary since there are no changes done.

@polarathene "they" at the time of when I was writing were exactly the people who wrote the Intel Graphics Arch Wiki page.

Since then the page has been updated and the same information I put in italic (the modesetting driver will not be benefited by Intel GuC/HuC/DMC firmware) is not there anymore.

You can still find it via google (see the attached screenshot) or by looking at the page revision diff as of 16:10, 1 October 2019.

Reason for removal was: Remove incorrect piece of information, GuC/HuC firmware are of kernel level relevance, there's no reference to this in the Xorg DDX source

Note from Arch Wiki regarding Kernel 5.4+:

GuC submission has been completely disabled for the kernel 5.4 and later, due to it reducing performance and causing bugs. Setting enable_guc=3 has no effect.

Source: https://patchwork.kernel.org/patch/10904591/

https://patchwork.kernel.org/project/intel-gfx/patch/[email protected]/

+++ b/drivers/gpu/drm/i915/i915_params.h
+	param(int, enable_guc, 2, 0400) \

Daniele comes up with a new patch. Is this depracted on modesetting?

This patch is simply to force the CI machines to enable the HUC which will better-test the code he is sending. The situation has not yet improved.

Full disclosure: I left Intel about a month ago, so I might not be the most up to date anymore.

Hi, i don't know about anything and how this stuff should work, but long story short my /etc/modprobe.d/i915.conf
options i915 enable_dc=2 enable_fbc=0
By default enable_fbc was 1, and i decided to turn it off because my CPU was hot as f when i was playing some youtube in 1080p60 or something. I found about this feature and decided to play with it a little and in result my CPU is no more on fire and i wasting less energy in semi-stale situations. Don't know what enable_dc=2 does btw, but it sound good to me and i turned it on too.

Disabling this feature (Framebuffer compression) resulted in no lags in highres video but significantly higher power usage (and lesser °C on CPU) and lesser power usage in stale and browser surfing modes.
i5-8625U with UHD 620. Now my laptop draws down to 5 watts and even 4 watts if i turn down backlight (on max it adds up to +2 watts), and all this with wi-fi on and active internet usage.

@mupuf
hmm i know this is old, dunno if u are still active, can u give us some kind of update if something if this is fixed? or were we can look for known bugs. i fiddle around with it and there is more stuff that doenst seem to work like c-states on package level.

I lost all hope that intel is ever going to fix their drivers...
It gets more broken with every new kernel version

@h1ght: Sorry, I don't work at Intel anymore nor do I use any Intel hardware hardware anymore (save a couple of nvme drives).

@kev300: I am not surprised. Hundreds of thousands of man hours have been spent refactoring a driver really not meant for discrete GPUs before finally doing what was needed to do (create a new driver, xe), along with the people the most vocal and active about quality quitting. Everything was foretold years ago, but met with deaf hears.

When is this going to be fixed? I tried this on a new system (Intel NUC 11) and it's still not loading the proper firmware:

echo "options i915 enable_guc=2" > /etc/modprobe.d/i915.conf

[    3.771239] i915 0000:00:02.0: firmware: direct-loading firmware i915/tgl_dmc_ver2_12.bin
[    3.771701] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
[    3.772206] i915 0000:00:02.0: firmware: failed to load i915/tgl_guc_70.1.1.bin (-2)
[    3.772212] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[    3.772222] i915 0000:00:02.0: firmware: failed to load i915/tgl_guc_70.1.1.bin (-2)
[    3.772226] i915 0000:00:02.0: GuC firmware i915/tgl_guc_70.1.1.bin: fetch failed with error -2
[    3.772229] i915 0000:00:02.0: [drm] GuC firmware(s) can be downloaded from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    3.772817] i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_70.1.1.bin version 0.0
[    3.772833] i915 0000:00:02.0: [drm] GuC is uninitialized
[    3.781715] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[    3.782541] ACPI: video: Video Device [GFX0] (multi-head: yes  rom: no  post: no)

What am I missing here?

@kevindd992002, sounds like you're missing some firmware files... You can try this project and see if it solves your issue.

@Brainiarc7,

I've just did the required changes except I've used 2 instead of 3 as value for enable_guc and the two commands you're giving to check the status does not work anymore:

$ sudo cat /sys/kernel/debug/dri/0/i915_guc_load_status
cat: /sys/kernel/debug/dri/0/i915_guc_load_status: No such file or directory

$ sudo cat /sys/kernel/debug/dri/0/i915_huc_load_status
cat: /sys/kernel/debug/dri/0/i915_huc_load_status: No such file or directory

But I've found something equivalent:

$ sudo cat /sys/kernel/debug/dri/0/i915_gpu_info
Kernel: 5.15.0-60-generic x86_64
Driver: 20201103
Time: 1676850545 s 362798 us
Boottime: 606 s 323519 us
Uptime: 604 s 787730 us
Capture: 4295043846 jiffies; 0 ms ago
Reset count: 0
Suspend count: 0
Platform: SKYLAKE
Subplatform: 0x0
PCI ID: 0x193b
PCI Revision: 0x09
PCI Subsystem: 8086:2064
IOMMU enabled?: 0
DMC loaded: yes
DMC fw version: 1.27
RPM wakelock: yes
PM suspended: no
GT awake: no
EIR: 0x00000000
IER: 0x08080000
GTIER[0]: 0x09090909
GTIER[1]: 0x09090909
GTIER[2]: 0x80000000
GTIER[3]: 0x00000909
PGTBL_ER: 0x00000000
FORCEWAKE: 0xffff0001
DERRMR: 0x2077efef
  fence[0] = 00000000
  fence[1] = 00000000
  fence[2] = 00000000
  fence[3] = 00000000
  fence[4] = 00000000
  fence[5] = 00000000
  fence[6] = 00000000
  fence[7] = 00000000
  fence[8] = 00000000
  fence[9] = 00000000
  fence[10] = 00000000
  fence[11] = 00000000
  fence[12] = 00000000
  fence[13] = 00000000
  fence[14] = 00000000
  fence[15] = 00000000
  fence[16] = 00000000
  fence[17] = 00000000
  fence[18] = 00000000
  fence[19] = 00000000
  fence[20] = 00000000
  fence[21] = 00000000
  fence[22] = 00000000
  fence[23] = 00000000
  fence[24] = 00000000
  fence[25] = 00000000
  fence[26] = 00000000
  fence[27] = 00000000
  fence[28] = 00000000
  fence[29] = 00000000
  fence[30] = 00000000
  fence[31] = 00000000
ERROR: 0x00000000
DONE_REG: 0x07ffffff
FAULT_TLB_DATA: 0x00000011 0xbe6b88de
GTT_CACHE_EN: 0xf0007fff
GuC firmware: i915/skl_guc_62.0.0.bin
	status: RUNNING
	version: wanted 62.0, found 62.0
	uCode: 199168 bytes
	RSA: 256 bytes
HuC firmware: i915/skl_huc_2.0.0.bin
	status: RUNNING
	version: wanted 2.0, found 2.0
	uCode: 135936 bytes
	RSA: 256 bytes
global --- GuC log buffer = 0x00000000 007ef000
:cg@6I5f*i4Mr4dR*BQ;RZk^D"E/+R?:0+`W1(jZIXfl,`e?Q6+5mtUCr"KIVpUdq!mOQW?Y8uH)d1)uI&jj4)''d'"Y?e$sHm6I7!!!#[$p3pnDiHfYBZ6=+fV]06LbNg]Bti?.e'G;FCsMI_(.m%]^V>'31A+W%qqpR`!!!!*zzzzzzzzzzzzzzzz^]4?7,QN1@!8/`5
available engines: 40f
slice total: 3, mask=0007
subslice total: 9
slice0: 3 subslices, mask=00000007
slice1: 3 subslices, mask=00000007
slice2: 3 subslices, mask=00000007
EU total: 72
EU per subslice: 8
has slice power gating: yes
has subslice power gating: no
has EU power gating: yes
slice0: 3 subslice(s) (0x00000007):
	subslice0: 8 EUs (0xff)
	subslice1: 8 EUs (0xff)
	subslice2: 8 EUs (0xff)
	subslice3: 0 EUs (0x0)
slice1: 3 subslice(s) (0x00000007):
	subslice0: 8 EUs (0xff)
	subslice1: 8 EUs (0xff)
	subslice2: 8 EUs (0xff)
	subslice3: 0 EUs (0x0)
slice2: 3 subslice(s) (0x00000007):
	subslice0: 8 EUs (0xff)
	subslice1: 8 EUs (0xff)
	subslice2: 8 EUs (0xff)
	subslice3: 0 EUs (0x0)
graphics version: 9
media version: 9
display version: 9
gt: 4
iommu: disabled
memory-regions: 5
page-sizes: 11000
platform: SKYLAKE
ppgtt-size: 48
ppgtt-type: 2
dma_mask_size: 39
is_mobile: no
is_lp: no
require_force_probe: no
is_dgfx: no
has_64bit_reloc: yes
gpu_reset_clobbers_display: no
has_reset_engine: yes
has_global_mocs: no
has_gt_uc: yes
has_l3_dpf: no
has_llc: yes
has_logical_ring_contexts: yes
has_logical_ring_elsq: no
has_mslices: no
has_pooled_eu: no
has_rc6: yes
has_rc6p: no
has_rps: yes
has_runtime_pm: yes
has_snoop: no
has_coherent_ggtt: yes
unfenced_needs_alignment: no
hws_needs_physical: no
cursor_needs_physical: no
has_cdclk_crawl: no
has_dmc: yes
has_ddi: yes
has_dp_mst: yes
has_dsb: no
has_dsc: no
has_fbc: yes
has_fpga_dbg: yes
has_gmch: no
has_hdcp: yes
has_hotplug: yes
has_hti: no
has_ipc: yes
has_modular_fia: no
has_overlay: no
has_psr: yes
has_psr_hw_tracking: yes
overlay_needs_physical: no
supports_tv: no
rawclk rate: 24000 kHz
Has logical contexts? yes
scheduler: 1f
i915.vbt_firmware=(null)
i915.modeset=-1
i915.lvds_channel_mode=0
i915.panel_use_ssc=-1
i915.vbt_sdvo_panel_type=-1
i915.enable_dc=-1
i915.enable_fbc=1
i915.enable_psr=-1
i915.psr_safest_params=no
i915.enable_psr2_sel_fetch=no
i915.disable_power_well=1
i915.enable_ips=1
i915.invert_brightness=0
i915.enable_guc=2
i915.guc_log_level=-1
i915.guc_firmware_path=(null)
i915.huc_firmware_path=(null)
i915.dmc_firmware_path=(null)
i915.mmio_debug=0
i915.edp_vswing=0
i915.reset=3
i915.inject_probe_failure=0
i915.fastboot=-1
i915.enable_dpcd_backlight=-1
i915.force_probe=
i915.fake_lmem_start=0
i915.request_timeout_ms=20000
i915.enable_hangcheck=yes
i915.load_detect_test=no
i915.force_reset_modeset_test=no
i915.error_capture=yes
i915.disable_display=no
i915.verbose_state_checks=yes
i915.nuclear_pageflip=no
i915.enable_dp_mst=yes
i915.enable_gvt=no

And you can filter it to just get the guc and huc status that way:

$ sudo cat /sys/kernel/debug/dri/0/i915_gpu_info | grep -i "firmware:" -A1
GuC firmware: i915/skl_guc_62.0.0.bin
	status: RUNNING
--
HuC firmware: i915/skl_huc_2.0.0.bin
	status: RUNNING

Just found on the ArchWiki page that the right commands are:

$ sudo cat /sys/kernel/debug/dri/0/gt/uc/guc_info
GuC firmware: i915/skl_guc_62.0.0.bin
	status: RUNNING
	version: wanted 62.0, found 62.0
	uCode: 199168 bytes
	RSA: 256 bytes

GuC status 0x800330ec:
	Bootrom status = 0x76
	uKernel status = 0x30
	MIA Core status = 0x3

Scratch registers:
	 0: 	0xf0000000
	 1: 	0x0
	 2: 	0x1021000
	 3: 	0x1022000
	 4: 	0x40
	 5: 	0x1004
	 6: 	0x0
	 7: 	0x0
	 8: 	0x0
	 9: 	0x0
	10: 	0x0
	11: 	0x0
	12: 	0x0
	13: 	0x0
	14: 	0x0
	15: 	0x0

GuC log relay not created

$ sudo cat /sys/kernel/debug/dri/0/gt/uc/huc_info
HuC firmware: i915/skl_huc_2.0.0.bin
	status: RUNNING
	version: wanted 2.0, found 2.0
	uCode: 135936 bytes
	RSA: 256 bytes
HuC status: 0x00006080

Hope it can be helpful to someone else.