<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - [KBL] Video corrupted during playback with audio in KBL NUC using Clear Linux OS (Root Caused to GuC/HuC Firmware Authentication Issue)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=110617#c5">Comment # 5</a>
              on <a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - [KBL] Video corrupted during playback with audio in KBL NUC using Clear Linux OS (Root Caused to GuC/HuC Firmware Authentication Issue)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=110617">bug 110617</a>
              from <span class="vcard"><a class="email" href="mailto:lakshminarayana.vudum@intel.com" title="Lakshmi <lakshminarayana.vudum@intel.com>"> <span class="fn">Lakshmi</span></a>
</span></b>
        <pre>(In reply to Jon Ewins from <a href="show_bug.cgi?id=110617#c3">comment #3</a>)
<span class="quote">> GuC and HuC are closed source signed binaries.  They are loaded, with the
> GuC first authenticated based on its embedded key and the GuC then
> supporting authentication of the HuC.  Of the kernel params you mentioned,
> i915.enable_guc=0x02 configures the system for use of the HuC.  The nuclear
> flip param should not be relevant.
> One observation is that the kernel in use here appears to have late uc
> loading (i915_gem_init_hw_late) that was required for Android boot
> operation, but never part of the upstream kernel. It is not clear if that is
> related.  
> * Please confirm that HuC authentication is successful on APL, not just that
> no video corruption is seen.  Mihgt be case if case media operation is
> different on APL.

> * Is the guc/huc failure consistent on every run?

> Note that we have confirmed locally that current drm-tip kernel with v32.0.3
> GuC fw is not showing an issue for KBL on general boot, IGT tests.

> To aid further debugging, please enable following logging.
> First ensure the drm i915 debug level is set 
> drm.debug=0xe
> For GUC logs, set:
> i915.guc_log_level=3
> This requires that debugfs is configured.  GuC logs will be located after
> the test run at:
> /sys/kernel/debug/dri/0/i915_guc_log_dump
> (no debugfs must be enabled)
> If an issue happens in guc load such that the driver load fails, the driver
> will copy the log to
> /sys/kernel/debug/dri/0/i915_guc_load_err_log_dump
> before the driver is unrolled.
> please update the content of these files to this bugzilla, along with kernel
> dmesg log.</span >

Reporter, can you please provide all necessary details as requested above.</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>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>