Re: Root filesystem read access for firmware load during hibernation image writing

From: Maciej S. Szmigiero
Date: Sat Oct 05 2024 - 10:05:41 EST


The issue below still happens on kernel version 6.11.1.

Created a kernel bugzilla entry for it:
https://bugzilla.kernel.org/show_bug.cgi?id=219353

It would be nice to at least know whether the filesystem read access supposed is
to be working normally at PMSG_THAW hibernation stage to assign the issue accordingly.

CC: request_firmware() maintainers

Thanks,
Maciej

On 28.08.2024 21:08, Maciej S. Szmigiero wrote:
Hi,

I have a quick question about hibernation "image writing" state - is
(root) filesystem *read* access supposed to be working normally at that point?

Specifically, I know that devices are resumed (PMSG_THAW) after preparing
the hibernation image.

In my case, a USB device (RTL8821CU) gets reset at that stage due to
commit 04b8c8143d46 ("btusb: fix Realtek suspend/resume") and so it tries
to request_firmware() from the root filesystem after that thaw/reset,
when the hibernation image is being written.

It usually succeeds, however often it deadlocks somewhere in Btrfs code
resulting in the system failing to power off after writing the hibernate
image:
power_off() calls dpm_suspend_start(), which calls dpm_prepare(), which
waits for device probe to finish.

And device probe is stuck forever trying to load that USB stick firmware
from the filesystem - so in the end the system never powers off during
(after) hibernation.

That's why I wonder whether this firmware load is supposed to work correctly
during that hibernation state and so the system may be hitting some kind of
a swsusp/btrfs/block layer race condition.

Or, alternatively, maybe  reading files is not supported at this point and
so this is really a btrtl/rtw88 bug?

CCing Btrfs people in case it is some known Btrfs issue.

Btw, this is on upstream kernel 6.10.6 and the "Show Blocked State" trace
during that failed power off is attached below.