Re: btintel_pcie: hibernation intermittently aborted by -EBUSY from D3 entry timeout

[Sergey Lebedev <lsa.uz@pm.me>]

Ferenc,

Two patches already on this list address exactly your signature, and they
fix different halves of it. Both are reviewed and neither has been applied
yet, so testing them is useful rather than redundant.

Your path is btintel_pcie_hibernate() -> btintel_pcie_suspend_late(
PMSG_HIBERNATE) -> btintel_pcie_set_dxstate(D3_COLD). After each 200 ms
timeout that function does not give up blindly: it falls back to asking
whether the controller reached the state anyway, because the alive
interrupt is known to go missing. The fallback is btintel_pcie_in_d3(),
which reads data->boot_stage_cache and not the register.

And boot_stage_cache is refreshed in exactly one place on this path: the
alive interrupt handler. So the fallback that exists to survive a missed
interrupt is disabled by the very miss it exists for - it re-reads a value
last written before the transition, three times, and returns -EBUSY after
the image is already on disk.

  Vladimir V. Kondratyev, v4 - re-read BOOT_STAGE_REG before the fallback
  check, so a genuinely missed interrupt becomes survivable:
  https://lore.kernel.org/linux-bluetooth/20260903192245.135310-2-vladimirkondratyev2@gmail.com/

  Ravindra (Intel), v2 - move data->gp0_received = false out of the retry
  loop, so an interrupt that arrives late is not discarded by the next
  iteration:
  https://lore.kernel.org/linux-bluetooth/20260902042840.2432862-1-ravindra@intel.com/

I reproduced your exact three-retry signature deterministically on a
Surface Pro 11 (Lunar Lake, BE201 8086:a876) by dropping the alive
interrupt on demand, and measured the two patches per hunk: with only
Ravindra's, the missed-interrupt case still fails as unpatched; with only
Vladimir's, it passes. They do not interfere. I have also seen the failure
happen on its own, injection disabled, once in six s2idle cycles.

So my guess is Vladimir's patch alone will fix your hibernation, and it
would be worth knowing. If it does not, that is more interesting still:
it would mean your controller genuinely never reaches D3, which is a
different bug from this one and worth reporting as such.

If you do test it, a Tested-by would carry real weight. Everything above
is one machine, one controller, one firmware - which I have said in every
message I have sent on this - and yours is Panther Lake with 8086:e476, a
different generation. The two patches are being combined into a single
series, so there is a window in which a second machine can still be part
of it.

Your report: 22771256-6dcb-4ab9-ae77-3a88480e7d21@lengyelf.eu

Sergey