On 5.10.2024 19:40, Pavel Machek wrote:
Hi!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?I'd say not supported at this point. Reading file may still read to atime update, etc, and we can't really can't support that easily.
Thanks for this clarification. I've dropped btrfs folks from the CC list since this isn't a btrfs issue after all and added rtw88/btrtl maintainers instead.
Suggestion is to keep firmware cached in memory, or at least cache it in memory when hibernation begins.
Since a WiFi/BT NIC is hardly useful for hibernation snapshot writing operation it seems that an easier option would be to simply return something like -EPROBE_DEFER from both rtw88 and btrtl probe callbacks during PMSG_THAW hibernation stage. That -EPROBE_DEFER will hopefully handle the unlikely case that the hibernation snapshot writing fails or someone is running a HIBERNATION_TEST_RESUME. In turn, the easiest trigger for this would be the "in_suspend" variable being set, however this would require EXPORTing it - it looks like system_entering_hibernation() only covers the case when the system is hibernating using platform hibernation support. I will see whether this workaround works for me, if someone wants to implement the "firmware caching" approach instead then feel free to do so. By the way, I don't see any reason why other USB devices that load firmware at their probe time can't be affected too since that lock_device_hotplug() call in hibernate() seems to only prevent CPU/RAM/ACPI hotplug, not USB hotplug. So if such USB device happens to get reset during hibernation time (for example from hub EMI) it would suffer the same issue.
BR, Pavel
Thanks, Maciej
