On Sat, Apr 03, 2021 at 12:24:07PM +0200, Lukas Middendorf wrote:
>
> On 02/04/2021 20:02, Luis Chamberlain wrote:
> > No sorry, I dropped the ball on this but I managed to now spawn up the
> > virtual guests where I was doing development to reproduce this. Give
> > me some time and I will zero in on this now.
> >
> > For now what I have is the following to test this, I next will work
> > on the userspace part.
>
> I can report that your patch for test_firmware works (applied to current
> master from linus d93a0d4; I get some offsets and had to adjust some
> whitespace for it to apply). With that module (and resume test enabled) I
> get freezes at resume in the same cases that would also cause problems with
> si2168.
Beautiful!
> I'm testing this on bare metal F34 beta with / on a btrfs. I'm using nvidia
> driver again to make sure the system does not otherwise use any firmware
> from /usr/lib/firmware (confirmed with kernel debug messages for
> firmware_loader). My si2168 is not plugged in.
OK I was not able to reproduce but the details below also clarify why,
so I now was able to reproduce! So I don't need to specifically test
with this distro, but others may do so.
> I tested it with a normal population of files in /usr/lib/firmware , without
> test-firmware.bin and also with a random 1MiB file in place. I tested after
> a reboot so it does not do caching.
> With /usr/lib/firmware on a separate ext4 partition I can confirm with dmesg
> that the test_firmware suspend test actually works (does not freeze).
> With /usr/lib/firmware on btrfs it fails in both cases (with and without the
> firmware files).
> With caching (first suspend with the ext4 partition mounted, then a second
> suspend without) it does not freeze even with the firmware on btrfs.
OK thanks for confirming!
> One further thing I noticed which might be problematic in rare cases:
> According to the kernel debug messages, the firmware-loader does not attempt
> to cache the firmware during suspend,
Correct, the goal with this test was to purposely *not* call for the
firmware prior to suspend, and instead *race* (do the wrong thing) at
resume. It shouldn't really stall... fail yes, but stall, that seems
fishy.
> if the previous call to
> request_firmware() has failed (file not present; call made during previous
> resume). In my opinion it should attempt to cache the firmware on suspend
> even in this case
Yes, that is the *proper* way to do use the firmware API, but we want to
reproduce the stall, and so we have to recreate the issue you reported
by doing something bad.
> (If I remember correctly, firmware_request_cache also
> works without the file being present). In case some low-memory condition has
> caused the file system cache to lose the information about the file being
> non-present (or the file has been written after the initial attempt and is
> no longer in the file system cache), this might lead to freezes even for
> well-behaved drivers in case they reattempt to do request_firmware() on
> resume.
> If the firmware is found during resume, it is cached on further suspends.
Right.
> Given how long it took me to narrow down this problem in this (for me)
> reliably reproducible case, something like this happening at random would be
> almost impossible to debug/locate and might actually happen frequently in
> the wild.
OK thanks for the report!
> On 03/04/2021 00:19, Luis Chamberlain wrote:
> > Lukas, can you share your /etc/fstab ?
>
> This is the core part (everything else is unmounted), I shortened the UUIDs.
> The ext4 mount of course is also unmounted when I want it to fail, with it
> in place it reliably not-fails.
>
> UUID=<1> / btrfs subvol=linux1 0 0
> UUID=<2> /usr/lib/firmware ext4 defaults 1 1
> UUID=<1> /home/lukas btrfs subvol=linux1-f34-lukas 0 0
> tmpfs /home/lukas/.cache tmpfs size=16g,gid=lukas,uid=lukas,mode=700 0 0
>
> > Also, how long do you stay in the boot before you try to suspend?
>
> During my reproduction sessions usually only shortly 1-5min, but I think I
> have seen this also after a slightly longer time. I can try to let it sit
> for longer if you think that is important.
No, I was looking to see how easy it is to reproduce right after a
fresh boot, now that I can reproduce I confirm it happens right away.
> On 03/04/2021 00:58, Luis Chamberlain wrote:
> > On Fri, Apr 2, 2021 at 3:19 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> > >
> > > Lukas, can you share your /etc/fstab ? Also, how long do you stay in
> > > the boot before you try to suspend?
> >
> > OK I cannot reproduce the issue with the modified patch I sent to
> > test_firmware, which if you enable config_enable_resume_test will
> > trigger a request_firmware() on resume, thus trying to mimic the race
> > you note. To test this you can simply use a loopback filesystem for
> > your /lib/firmware and create a btrfs filesystem for it, and then run:
> >
> > echo 1 > /sys/devices/virtual/misc/test_firmware/config_enable_resume_test
> >
> > systemctl suspend
> >
> > Then resume. You should see "resume test" print on dmesg. I keep my
> > /lib/firmware/ empty and still, nothing.
>
> Did you also try to create a random test-firmware.bin (I used 1M from
> /dev/urandom) instead of an empty /lib/firmware ?
No, right now I want to to just focus on fixing the stall you saw.
> If the directory is completely empty, it also does not freeze for me.
This is a very important piece of information, thanks!
> If the
> directory is empty, any attempt to access its content can likely be directly
> served from cache, even if the actual directory has never been accessed
> before, as long as /lib (which is a symlink to /usr/lib on fedora) has been
> accessed (which will likely always be true). So I have to further add to my
> previous findings that "firmware directory is not completely empty" is a
> further prerequisite for it to fail.
Indeed, that helps!
So creating say 1000 random files in /lib/firmware on a freshly created
btrfs partition helps reproduce:
mkfs.btrfs /dev/whatever
mount /dev/wahtever /lib/firmware
# Put it on /etc/fstab too
Generate 1000 random files on it:
```
for n in {1..1000}; do
dd if=/dev/urandom of=/lib/firmware/file$( printf %03d "$n" ).bin bs=1 count=$((RANDOM + 1024 ))
done
```
Then reboot, upon reboot do:
modprobe test_firmware
echo 1 > /sys/devices/virtual/misc/test_firmware/config_enable_resume_test
systemctl suspend
If its a guest wake it up:
virsh dompmwakeup domidofguest
> > Can you provide kernel logs for where you are seeing things get stuck
> > at?
>
> The log does not have any entries from resume. For the attempts where it
> freezes the last entry in journalctl is
> systemd-sleep[5050]: Suspending system...
I confirm.
> > Note that I had mentioned the races on suspend/resume do exist for any journaling
> > filesystem, but this typically happens if you are doing ongoing
> > writes. I suppose you are *not* doing writes and your filesystem is
> > idle.
>
> I can of course not completely rule out some random write (log files or
> similar), but there is definitely no heavy writing going on. I think only
> writes caused by the act of suspending and resuming could cause it this
> reliably. I have seen it also with a completely isolated btrfs file system
> for /usr/lib/firmware, where there should not have been any writes. For ext4
> (which is also journaling) it works properly.
Nope, no writes are going on.
> > As such without kernel logs I cannot be sure what the issue is, but at
> > this point after the initial testing I've done I don't suspect this is
> > a firmware API issue. You might be better off just reposting your
> > patches with the respective Reviewed-by tags and pestering your
> > maintainer.
>
> I will try to be a little bit more insistent this time. Is "just repost" the
> usual way to handle if patches are ignored?
You can repost, v2 just add my reviewed-by. Those patches are indeed
correct as they are calling for the firmware prior to resume. Maybe
clarify that.
But indeed there is also another issue which you reported which needs to
be fixed, and for that thanks so much for you patience! I'll be looking
into this!
Luis
