<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Kernel tainted even with unsupported options"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111918#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Kernel tainted even with unsupported options"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111918">bug 111918</a>
from <span class="vcard"><a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> <span class="fn">Eero Tamminen</span></a>
</span></b>
<pre>(In reply to Daniele Ceraolo Spurio from <a href="show_bug.cgi?id=111918#c1">comment #1</a>)
<span class="quote">> The enable_guc parameter is defined as unsafe, so the kernel will be tainted
> whenever the parameter is set, no matter if the support is there or not.</span >
>
<span class="quote">> Just to clarify, are you requesting to avoid a taint if the parameter is set
> on a platform that does not support GuC? If that is the case, I don't think
> that is something that will match the general handling of the i915
> parameters, because for other similar parameters for other features we do
> always taint no matter the HW support (e.g. i915.enable_psr).</span >
Tainting is supposed to indicate kernel being in specific (unsupported, unsafe
etc) state. If the unsafe operation isn't actually done or unsafe state
enabled, still tainting the kernel seems broken.
(I.e. this is generic i915 bug, not GuC/HuC specific one.)
Btw. Looking at the taint flag used for HuC loading, that seems odd too:
$ cat /proc/sys/kernel/tainted
64
According to kernel documentation:
<a href="https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html">https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html</a>
That's "taint requested by userspace application", which I think is supposed to
mean user space echoing taint to "/proc/sys/kernel/tainted" file, like
described here:
<a href="https://lwn.net/Articles/184879/">https://lwn.net/Articles/184879/</a>
None of the documented flags quite matches GuC case though, which is currently
"unsafe feature / firmware", but wouldn't e.g. one of these flags be closer:
"kernel issued warning" (512), "staging driver was loaded" (1024), "workaround
for bug in platform firmware applied" (2048)?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>