Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: I am finding that on cold boots, I get a black, non-backlit screen when I am expected to enter my LUKS password (for plymouth). Once I blindly enter my password, the splash screen then shows and my PC boots normally. I do not face this issue at the password screen when either I: 1. Set my GPU mode from hybrid to discrete NVIDIA GPU via my BIOS 2. Reboot my PC I have 2 GPUs, Intel graphics and also NVIDIA graphics. Graphics: Device-1: Intel Alder Lake-P GT2 [Iris Xe Graphics] driver: i915 v: kernel Device-2: NVIDIA GA106M [GeForce RTX 3060 Mobile / Max-Q] driver: nvidia v: 545.29.06 Display: server: X.Org v: 23.2.4 with: Xwayland v: 23.2.4 driver: X: loaded: N/A failed: nvidia dri: iris gpu: i915 resolution: 2560x1440~240Hz API: OpenGL v: 4.6 vendor: intel mesa v: 23.3.6 renderer: Mesa Intel Graphics (ADL GT2) API: EGL Message: EGL data requires eglinfo. Check --recommends. I am suspecting I am facing a backlight issue. I can tell that my laptop is using nvidia_wmi_ec_backlight once fully booted in order to change the brightness via the keyboard. This works fine and if I unload this module I no longer can change the brightness. However it's hard to tell what role perhaps intel_backlight or acpi_backlight might need, or if none, then why nvidia_wmi_ec_backlight has trouble on cold boots (is it not storing brightness levels?) I think I can rule out this being a plymouth issue because when my screen is black, I can plug my laptop into an external monitor and see the password screen just fine. 2. What is the Version-Release number of the kernel: Linux 6.7.6-200.fc39.x86_64 x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1. Cold boot Razer laptop w/ Intel GPU and NVIDIA GPU with an encrypted hard drive 2. Observe that on the password screen, the backlight does not illuminate 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Reproducible: Always
Created attachment 2019702 [details] acpidump
Created attachment 2019703 [details] dmidecode
Created attachment 2019704 [details] dmesg
Created attachment 2019705 [details] backlight
Thank you for your bug report. I see in your ls /sys/class/backlight attachment that your laptop is indeed using the nvidia_wmi_ec_backlight driver. By default this driver will not be included in your initrd, which may explain why things only work after you have typed your LUKS password and the system has switched from the initrd to the crypted rootfs, which does have the nvidia_wmi_ec_backlight driver. Can you try creating an /etc/dracut.conf.d/nvidia_wmi_ec_backlight.conf file with the following line in there: drivers+=" nvidia_wmi_ec_backlight " note the dracut.conf syntax requires spaces around the module-name! And then regenerate the initrd for your currently booted kernel by running: sudo dracut -f and then try cold-booting the same kernel and see if this helps. If this does not help, please verify that nvidia-wmi-ec-backlight.ko is now part of the initrd for the booted kernel by running: sudo lsinitrd | grep nvidia-wmi-ec-backlight Also if this does not help, lets verify that the issue really is the backlight, please try shining into the display with a flashlight (e.g. the one from your phone) you should then be able to more or less see the contours of the passwd entry box when aiming the flashlight at an angle (not straight) to the screen near the passwd box area.
Hans, Thank you for your suggestions. I went ahead and reinstalled Fedora from scratch and it appears to be working. One thing I notice about the clean install is the i915 kernel module is not loaded in initramfs by default. Perhaps that being in there was messing up my last iteration of Fedora. I was at first seeing the plymouth prompt again but in low-resolution. I then just had to change GRUB_TERMINAL_OUTPUT from console to gfxterm and now it's in a normal resolution. Hard to say what the core issue was, but I can at least confirm its no longer a kernel bug so I will resolve this. Thanks Alex
Alex, it sounds to me like not having i915 in the initrd fixes things, but this likely happened because you had the laptop in discrete gfx only mode during the installation (at least I think that is what happened). I expect future kernel updates to add i915 back to the initrd re-introducing the problem. It would be nice if I were wrong, but if the problem indeed resurfaces then please re-open this bug and then we can try to figure out a proper fix for this.
Hans, you are exactly correct. Taking a new kernel update seems to have reintroduced the problem. Let me know what you need to help diagnose this issue.
> Let me know what you need to help diagnose this issue. Please try the steps from comment 5 and see if those help.
When adding the nvidia backlight to initrd, I was shown a black screen even after blindly typing in my password. I could not see anything when I shined a flashlight into my monitor.
> When adding the nvidia backlight to initrd, I was shown a black screen even after blindly typing in my password. I could not see anything when I shined a flashlight into my monitor. So when the nvidia backlight driver is added to the initrd then the screen stays black the entire time, rather then lighting up after blindly typing the disk unlock password ? Did you check the logs to make sure that you did type the disk unlock password correctly and that the system did actually boot,but you just could not see anything ? Something else you can try is dropping the: /etc/dracut.conf.d/nvidia_wmi_ec_backlight.conf file and then creating a: /etc/dracut.conf.d/i915.conf with: omit_drivers+=" i915 " in there and then regenerate the initrd. I think that will workaround the issue, but I must admit I still don't really understand the root cause here. Note I'm busy with other stuff next week, so I likely won't reply here until the week after next week.
It has been working to omit i915.
> It has been working to omit i915. Ok. I suggest you use that as a workaround then. The new nvidia-wmi-ec-backlight equipped laptops are quite buggy (at the hw/firmware level) wrt backlight handling. I've been working with nvidia to improve the situation, but there has not been much movement on fixing this lately. So I believe that this workaround is the best which we can do for now.
Closing, since I don't expect a fix other then the workaround to happen anytime soon.
By default nvidia-wmi-ec-backlight is not loaded to initrd, so when I added nvidia-wmi-ec-backlight to initrd it failed to boot completely. However when I omitted i915 the password screen showed again. Wouldn't that point to an issue with i915, since by default that is loaded into initrd?
(In reply to alexknoptech from comment #15) > By default nvidia-wmi-ec-backlight is not loaded to initrd, so when I added > nvidia-wmi-ec-backlight to initrd it failed to boot completely. However when > I omitted i915 the password screen showed again. Wouldn't that point to an > issue with i915, since by default that is loaded into initrd? According to the specification for the WMI GUID to which the nvidia-wmi-ec-backlight driver binds when a WMI device with that GUID is present and its query method indicates that nvidia-wmi-ec-backlight should be used then the backlight is fully controlled by the nvidia-wmi-ec-backlight driver and other drivers should not touch the backlight. This is the behavior which the kernel currently implements. So the i915 driver is not touching the backlight. Also why do things work when the i915 driver loads after the initrd? That suggests that the i915 driver is fine, but only if loaded later, which is quite weird. In practice on other laptops we have seen that even though the WMI interfaces indicates that nvidia-wmi-ec-backlight should be used this is not necessarily true and sometimes the behavior changes when e.g. plugging in a charger, requiring using the i915 native backlight control on battery and nvidia-wmi-ec-backlight when connected to a charger... This basically is all a big mess, created by nvidia. Note that the Linux nvidia-wmi-ec-backlight driver is actually written by nvidia themselves... So as I mentioned for now I suggest you just stick with the workaround.