| Summary: | [SKL-Y] GuC does not load when resuming from suspend to DISK | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | cprigent <christophe.prigent> | ||||||
| Component: | DRM/Intel | Assignee: | Dave Gordon <dg11491352> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | chris.harris, harmanpreet.s.bambah, intel-gfx-bugs, yu.dai | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | SKL | i915 features: | firmware/guc, power/suspend-resume | ||||||
| Attachments: |
|
||||||||
|
Description
cprigent
2016-03-03 18:33:46 UTC
Created attachment 122104 [details]
i915_guc_load_status
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. Do we have any latest update on this issue status ? A fix for this issue is in progress. It's based on the change posted at https://patchwork.freedesktop.org/series/3985/ and an update should be posted in the next few days. It tuns out that the Linux hibernate/resume cycle is weirdly asymmetric :( In a suspend (to RAM) cycle, devices are frozen, then the CPU power is turned "off", leaving the system in a low-power state. On resume, the CPU power comes up, then devices are thawed and normal operation continues. This is therefore essentially symmetrical. In hibernation, OTOH, things are much stranger. First, devices are frozen, including the display/GPU and presumably the HD/SSD; then, the kernel builds a compressed hibernation image; then, devices are *thawed* again, and the image written out. Finally, the power is turned off; there doesn't appear to be any re-freeze or controlled/phased shutdown at this stage. Therefore, the final state of devices just before poweroff is "active" -- not a problem for i915 or the GuC, but potentially an issue for self-powered devices or those with nonvolatile state. It's resume-from-hibernation where things really get strange. First, the system boots as though from cold: BIOS, GRUB, kernel. Drivers are initialised and the GuC firmware may be loaded. THEN the system discovers the hibernation image. It doesn't (AFAICT) freeze devices at this point; it simply overwrites the running kernel with the hibernated image. This means that the hardware (e.g. GuC) is left active, having been initialised by the booted kernel. But the reloaded driver state says the device is frozen, and must be reinitialised, including (re)loading the GuC firmware. For most devices, reinitialising an already-active device wouldn't be a problem; but the GuC's program memory is write-once. So when the restored driver tries to reload the GuC, the write fails. There are several ways to resolve this; for example, we could ignore the failure and discover afterwards that the GuC is in fact running anyway. Or we could check in advance, before even trying to load the GuC, and skip the entire sequence if it's already loaded. However the preferred solution will be to reset the GuC just before loading it, this guaranteeing that it starts out in a known state. (Otherwise, we would at least have to reprogram various options, and it might still be possible that the state of the running firmware is not identical with that which the driver would have loaded). This solution has been coded, tested locally and by the reporter, and sent to the upstream mailing list. The fix is now merged at https://cgit.freedesktop.org/drm-intel/commit/?id=d761701c55a99598477f3cb25c03d939a7711e74 For info, I don't reproduce it on KBL-U with GuC 9.14. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.