[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1ededf38-8f2a-49ef-8453-85399bf4fe12@maciej.szmigiero.name>
Date: Sat, 19 Oct 2024 17:08:19 +0200
From: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: "Darrick J. Wong" <djwong@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <len.brown@...el.com>,
Pavel Machek <pavel@....cz>, linux-pm <linux-pm@...r.kernel.org>,
linux-kernel@...r.kernel.org, Russ Weight <russ.weight@...ux.dev>,
Danilo Krummrich <dakr@...hat.com>, Ping-Ke Shih <pkshih@...ltek.com>,
linux-wireless <linux-wireless@...r.kernel.org>,
Marcel Holtmann <marcel@...tmann.org>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>
Subject: Re: Root filesystem read access for firmware load during hibernation
image writing
On 12.10.2024 01:11, Luis Chamberlain wrote:
> On Sat, Oct 05, 2024 at 03:16:27PM +0200, Maciej S. Szmigiero wrote:
>> 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.
>
> No, there are races possible if you trigger IO to a fs before a suspend
> is going on. If you have *more* IO ongoing, then you are likely to stall
> suspend and not be able to recover.
That's more or less the same answer as Pavel wrote 2 weeks ago,
but thanks for confirming it and providing more details on the subject.
Since it essentially makes this an rtw88/btrtl specific issue (and not
a generic PM/hibernation one) I have updated and reassigned the
aforementioned kernel bug accordingly.
As it is just my personal system that is affected by this hibernation
issue I'm content with just patching its kernel with a simple
workaround [1].
WiFi/BT NIC is hardly useful for hibernation snapshot writing anyway.
But of course if someone has the bandwidth to get a clean fix merged
then it would be great to have this fixed upstream for everyone.
> Luis
Thanks,
Maciej
[1]: https://github.com/maciejsszmigiero/linux/commit/f6188a940324b4bc8f51dcb1a9ae1a489e57bd1d
Powered by blists - more mailing lists