From: Luis Chamberlain <mcgrof@kernel.org>
To: Lukas Middendorf <kernel@tuxforce.de>
Cc: Anand Jain <anand.jain@oracle.com>,
linux-btrfs@vger.kernel.org, Antti Palosaari <crope@iki.fi>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org
Subject: Re: Is request_firmware() really safe to call in resume callback when /usr/lib/firmware is on btrfs?
Date: Tue, 18 Aug 2020 14:37:15 +0000 [thread overview]
Message-ID: <20200818143715.GF4332@42.do-not-panic.com> (raw)
In-Reply-To: <9e5c716e-1736-9890-54be-75739ea5462f@tuxforce.de>
On Tue, Aug 18, 2020 at 12:04:51AM +0200, Lukas Middendorf wrote:
> On 17/08/2020 17:20, Luis Chamberlain wrote:
> A freeze can happen on resume with and without the si2168 firmware files
> installed. It however is easier to hit the freeze with the firmware files
> installed. Without the firmware files present the freeze happens only if no
> other driver uses the firmware loader.
>
> >
> > This helps, thanks so much, now we'll have to write a reproducer, thanks
> > for the report!!
>
> Will you do it yourself or do you expect me to do anything for this?
I meant to imply that we'd do this, now that we understand the problem. Thanks
for your report!
> > > The nouveau driver in use seems to be equivalent to running "ls -R
> > > /usr/lib/firmware" before suspend.
> > >
> > > All the cases seem to boil down to:
> > > It freezes if the file system has to be accessed to list the content of
> > > /usr/lib/firmware or to read the si2168 firmware file
> >
> > Let's confirm first whether or not your system is using other firmware
> > files too or not.
>
> I confirmed that above. Why is this so important, anyway?
A reproducer is easier to write if the actual file neeed is not needed.
That's all.
Luis
next prev parent reply other threads:[~2020-08-18 14:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 18:51 Is request_firmware() really safe to call in resume callback when /usr/lib/firmware is on btrfs? Lukas Middendorf
2020-08-13 16:37 ` Luis Chamberlain
2020-08-13 21:53 ` Lukas Middendorf
2020-08-13 22:13 ` Luis Chamberlain
2020-08-14 11:38 ` Lukas Middendorf
2020-08-14 16:37 ` Luis Chamberlain
2020-08-14 21:59 ` Lukas Middendorf
2020-08-17 15:20 ` Luis Chamberlain
2020-08-17 22:04 ` Lukas Middendorf
2020-08-18 14:37 ` Luis Chamberlain [this message]
2021-04-01 14:59 ` Lukas Middendorf
2021-04-02 18:02 ` Luis Chamberlain
2021-04-02 22:19 ` Luis Chamberlain
2021-04-02 22:58 ` Luis Chamberlain
2021-04-03 10:24 ` Lukas Middendorf
2021-04-03 16:07 ` Lukas Middendorf
2021-04-03 20:25 ` Luis Chamberlain
2021-04-03 21:04 ` Luis Chamberlain
2021-04-05 9:52 ` Lukas Middendorf
2021-04-04 0:50 ` Lukas Middendorf
2021-04-08 18:02 ` Luis Chamberlain
2021-04-16 23:17 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200818143715.GF4332@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=anand.jain@oracle.com \
--cc=crope@iki.fi \
--cc=kernel@tuxforce.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.