Created attachment 126169 [details]
IVB_igt-basic_guc-commands_output

Reproduced on all families before BSW (not reproduced on BSW)

> Steps:
> ------
> 1. Boot with kernel boot command lines: 
i915.enable_guc_loading=2 i915.enable_guc_submission=2

Please note that these variables are marked as UNSAFE.
That means that:
(a) you shouldn't set them unless you know what you're doing, and what they mean, and
(b) the kernel is *tainted* when you do so, which in turn means,
(c) whatever happens, it's not a bug, because you asked for it.

Secondly, the number "2" for these variables means that you are telling the driver that loading and use of the GuC is *mandatory*, and the driver *must* fail startup (leaving the GPU wedged) if *for any reason* those mandatory requirements cannot be fulfilled.

Good reasons to fail here include
(a) you don't have the (correct) GuC firmware installed, or
(b) the driver doesn't know what GuC firmware would be appropriate, or
(c) you don't have a GuC!

Therefore, this part of the bug report is wrong
> Expected result:
> ---------------
> 2. Trying to load GuC has no impact

The expected result of telling the driver that it *must* use the GuC on a platform that doesn't have one, is that it will develop paranoid schizophrenia ^W^W^W log an error and leave the GPU wedged. Which, according to the attached log, is exactly what it is doing :)

Note that setting either or both of these variables to "1" is much more sensible. That means "try to load/use the GuC, but continue in execlist mode if you can't". Or even "-1", meaning "try to use the GuC *if it's supported on this platform*, but fall back to execlist mode if it isn't supported, or the firmware is missing, or there's any other reason it can't be used".

I understand the reason and your point of view but adding a kernel boot command should not break the system even if what you are doing is not expected. This is a negative case. It is happening because of "(c) you don't have a GuC!" and I don't know why this is not happening on BSW.

drivers/gpu/drm/i915/intel_guc_loader.c
What about adding a check for the platforms without GuC, to do nothing whatever the kernel boot command lines?
because I will also test 1 and -1, and I will also install some firmware on platforms for which it is not intended.

I think the module parameters should be no-ops on platforms that do not have GuC.

https://patchwork.freedesktop.org/patch/111622/

Please check if this helps.

I confirm.
Thanks

Please retest with https://patchwork.freedesktop.org/series/13815/

(In reply to yann from comment #8)
> Please retest with https://patchwork.freedesktop.org/series/13815/

Patch merged. I came here to close the bug but it was already closed...

I launched IGT Basic on HSW, IVB, BDW with kernel boot command lines:  i915.enable_guc_loading=2 i915.enable_guc_submission=2
There is no timeout.
I see in kernel log: 
[drm:intel_device_info_dump [i915]] i915 device info: has_guc: no
[drm:intel_guc_setup [i915]] GuC fw status: path (null), fetch NONE, load NONE

Kernel: 4.9.0-rc2 194359e from http://cgit.freedesktop.org/drm-intel/
  commit 194359e4a31ff988c7a290093820c5ef28d3752b
  Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
  Date:   Mon Oct 24 17:44:02 2016 -0200
  drm-intel-nightly: 2016y-10m-24d-19h-42m-14s UTC integration manifest
libdrm-2.4.71 9e24d0c from git://anongit.freedesktop.org/mesa/drm
mesa: mesa-12.0.0 8b06176 from git://anongit.freedesktop.org/mesa/mesa
cairo 1.15.2 db8a7f1 from git://anongit.freedesktop.org/cairo
xorg-server-1.18.99.901-80 5dcb066 from git://git.freedesktop.org/git/xorg/xserver
xf86-video-intel 2.99.917-720 388fd4a from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
libva-1.7.2-38 3b7e499 from git://git.freedesktop.org/git/vaapi/libva 
vaapi-intel-driver: 1.7.2-140 852cea1 from git://git.freedesktop.org/git/vaapi/intel-driver
IGT: intel-gpu-tools-1.16-96 93437cb from http://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools.git

So closed.