[Bug 94390] [SKL-Y] GuC does not load when resuming from suspend to DISK

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94390

--- Comment #2 from david.s.gordon at intel.com ---
Hi,
you seem to have two entirely different scenarios here.

The second attachment labelled "i915_guc_load_status" unfortunately isn't the
output from the debugfs file of the same name, it's a dmesg log showing a
situation where the GuC firmware isn't loaded at all; the request_firmware()
call fails to find the firmware, triggers the user-helper, which waits a minute
(waiting for rootfs?) before failing. In the absence of any valid firmware, the
driver correctly falls back to execlist mode as expected.

The first attachment (correctly labelled "dmesg") is rather more interesting.
At startup, the GuC firmware has been fetched and successfully loaded into the
GuC. After the suspend-resume cycle, the firmware is reloaded into the GuC --
but the GuC doesn't complete the startup handshake!

My first suspicion would have been that the GuC firmware image in host memory
might have been lost or corrupted during the suspend-resume cycle, but the GuC
status code tells us that the GuC's BootRom has validated the newly-loaded
image and the RSA signature is (still) correct. This essentially proves that
the host-side image as copied by the DMA engine was still intact after it was
re-copied into the GuC's memory.

So what went wrong? The GuC status decodes as "uKernel got unexpected
exception". If you did manage to capture the contents of the debugfs
i915_guc_load_status, that might contain some more details, as the exception
handler may (depending on GuC build configuration options) put additional data
about the exception in the shared registers for the host to capture. Otherwise
there's not much more we can deduce from this.

Does it happen every time, or at least frequently? Or just once or very rarely?
We do know of a h/w bug that can occasionally result in the GuC reload not
working; Arun Siluvery recently posted a patch to work around this. If this is
also just occasional, the same workaround will fix it too. If it's every time,
it probably means the GuC h/w is not being reinitialised properly on resume,
and we will need to change something, maybe power sequencing?

.Dave.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160304/e5ea2e1d/attachment-0001.html>