{"uuid": "093cea31-eea2-41f8-96ff-529488dd5d6f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56552", "type": "seen", "source": "https://gist.github.com/red-c-karasu/8a71d948040bc301ce9e3f84409c01ba", "content": "# Arc A770 (DG2) hard lock on xe runtime-PM suspend \u2014 \"Suspend fence, guc_id failed to respond\" / \"VM worker error: -62\"\n\n## Summary\nFull-system hard lock (not just a GPU reset) when the `xe` driver attempts a\nruntime-PM suspend of an idle-but-loaded Arc A770, if a new compute workload\narrives during the in-flight suspend. No kernel panic, no auto-recovery; the\nmachine freezes and requires a hard power cycle. Captured over **netconsole**\n(the only recorder that survives, since the freeze is below the level the CPU\nwatchdogs catch \u2014 `hardlockup_panic=1` did not fire).\n\n## Signature (captured via netconsole at the moment of lock)\n```\nxe 0000:03:00.0: [drm] Tile0: GT0: Suspend fence, guc_id=6, failed to respond\nxe 0000:03:00.0: [drm] Tile0: GT0: Suspend fence, guc_id=2, failed to respond\nxe 0000:03:00.0: [drm] VM worker error: -62\n```\n`-62` is `-ETIME`. netconsole output stops immediately after \u2014 the box is dead here.\n\n## Environment\n- GPU: Intel Arc A770 16GB (DG2, PCI `8086:56a0`, `0000:03:00.0`), `xe` driver\n- GuC firmware: `i915/dg2_guc_70.bin` version 70.53.0\n- Kernel: 7.1.8-1-cachyos (also seen intermittently on prior 7.1.x)\n- CPU/board: Intel i7-9700 (9th gen, Coffee Lake) on ASRock Z390 Phantom Gaming 4S\n- Runtime PM at time of crash: `power/control=auto`, `autosuspend_delay_ms=1000`\n- Workload: llama.cpp SYCL inference (Level-Zero), model resident in VRAM\n\n## Trigger / mechanism\nCrashes occur at **idle\u2192active transitions, not under sustained load.**\n1. A model is resident; between requests the GT clock-gates to 0 MHz (idle, still D0).\n2. After `autosuspend_delay_ms` (1s) the driver begins a runtime suspend, quiescing\n   GuC submission contexts (`guc_id` 2 and 6) via suspend fences.\n3. A new compute submission arrives during the in-flight suspend and races it.\n4. The suspend fence never completes; the VM worker times out (`-ETIME`); hard lock.\n\nObservations supporting \"transitions, not load\":\n- 8+ minutes of *continuous* generation never crashed (GPU pinned active, never suspends).\n- Crash intervals ranged 4 min \u2013 29 h, i.e. race-dependent / timing-sensitive.\n- Frequent sysfs power/telemetry reads (which wake a suspended device) correlated\n  with instability \u2014 each read is another suspend/resume transition.\n\n## Workaround (no recurrence since applying it; short observation window)\nDisable GPU runtime PM so the failing D0\u2194D3hot transition never occurs:\n```\necho on > /sys/bus/pci/devices/0000:03:00.0/power/control\n```\nPersisted via a udev rule (match `8086:56a0`) plus a systemd oneshot backstop\n(the driver can reset `power/control` after udev). Cost: ~constant idle power\n(no D3hot). No lock-up since applying it. ASPM was independently disabled in BIOS\nearlier and did **not** prevent the crash (it happened 3.5 h later), so ASPM is\nnot implicated; PCIe AER counters were zero across all crashes.\n\n## Related but distinct\n- CVE-2024-56552 (`drm/xe/guc_submit: fix race around suspend_pending`) \u2014 same\n  subsystem, fixed in 6.12.4, present in this kernel. Different symptom strings,\n  so this appears to be a related-but-separate suspend race, or a hardware-timing\n  variant the existing fixes don't cover.\n- `drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout` \u2014 same class.\n- `drm/xe: Kill missing outer runtime PM protection warning` \u2014 PM-from-workqueue\n  during SUSPENDING, matching the \"VM worker\" path here.\n\n## Full-disclosure caveat\nThis board runs a **crossflashed BIOS** \u2014 the retail ASRock Z390 PG 4S beta\n`P1.40C` flashed onto an OEM 4S/ac board to enable Resizable BAR. This almost\ncertainly shifts PCIe/power-transition timing versus a stock board and likely\nwidens the race window. Reported anyway because the driver hard-locking the whole\nsystem on a suspend-fence timeout is a driver robustness issue regardless of BIOS,\nand the signature may help others on more standard hardware who hit the same race.\n", "creation_timestamp": "2026-08-18T00:59:26.765027Z"}