Hi,
So this seems to be unrelated to the partition table type and the boot
mode. If it is related to NVMe this is just one factor. I have just
observed it with / on BTRFS. On a new install the proprietary nvidia
driver is also needed to trigger this, but on my old install it also
occurred with the nvidia driver removed.
Things I have not tried yet (might try when I find the time again):
- older kernel version
- ext4 root but with separate boot partition (unlikely cause)
- non-nvidia graphics card (don't have one)
- logging kernel messages on different device using some serial output
(there is a way, right?) to see what really is failing
I have now done some more debugging and I think I found out what happens:
The firmware loading for my Hauppauge WinTV-dualHD USB DVB tuner fails
and locks up the system during resume when /usr/lib/firmware resides on
a btrfs.
The resume fails if all of the following is true:
1. the root file system is btrfs (not ext4)
2. the DVB tuner USB device is plugged in
3. the nvidia driver or dvb-firmware from rpmfusion is installed
It might be needed that the root is on a NVMe drive, but I have not
tested that, yet.
Apparently the Si2168-B40 on that device needs some firmware upload to
function. During normal resume, the si2168 kernel module seems to load
the binary firmware /usr/lib/firmware/dvb-demod-si2168-b40-01.fw into
the device. During initial device initialization (boot or device plug)
the firmware files are not loaded but just on first actual usage.
The third condition boils down to:
There are disc accesses needed to get or find the firmware file.
If the firmware is already in RAM buffer and no actual disc access is
needed, the resume succeeds.
If the firmware file is not present, the resume also succeeds, but only
if the content of /usr/lib/firmware is cached in RAM. If the directory
content is not known, the kernel still tries to load the non-existing
file and the resume fails.
Installing the nvidia driver is harmful apparently not through the
actual driver itself but through the non-usage of the nouveau driver,
which also needs firmware files from /usr/lib/firmware. Loading of the
nouveau driver apparently lists the content of that directory and the
non-existence of the si2168 firmware files is cached in RAM.
A workaround seems to be (before suspend)
ls -R /usr/lib/firmware/ > /dev/null
cat /usr/lib/firmware/dvb* > /dev/null
The first part apparently is only needed if no other driver (like
nouveau) has loaded firmware which lists and caches the content of
/usr/lib/firmware .
Another option is to actually use the tuner and trigger a firmware
upload before suspend. This also puts the file into cache.
When the nouveau driver is used, and the system is running in text mode,
and console_suspend of printk is disabled
(echo N > /sys/module/printk/parameters/console_suspend)
I can actually see kernel messages of the resume process, even when it
is locking up. During a successful resume there are messages related to
the firmware load. When resume is unsuccessful, however, there seem to
be no messages related to the DVB tuner.
The problem is present at least on kernels 5.5.18, 5.6.19 and 5.7.10 ,
so this does not seem to be a recent regression.
I had a quick look into the kernel source file
drivers/media/dvb-frontends/si2168.c
and the actual firmware reading is done by request_firmware(). It might
not be as safe to call during resume as the kernel documentation
specifies when root is on a btrfs.
Any suggestions on where I should report my findings to have those
properly looked into? I think I have narrowed the cause down far enough
so that somebody with knowledge of the kernel code might have a chance
to identify and fix the bug.
Best regards
Lukas
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
