Summary: | x11-drivers/nvidia-drivers: X login does not start with kernel 5.14.19 or 5.15.3 (need to enable CONFIG_DRM_KMS_HELPER) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Smith <chris> |
Component: | Current packages | Assignee: | Ionen Wolkens <ionen> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | dave.knippers, soap |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
boot log 5.15.3 (fails)
5.15.2 boot log (success) 5.15.3 boot log (fails) |
Description
Chris Smith
2021-11-18 22:10:05 UTC
It's sddm that doesn't start but the problem appears to be much earlier. Appears to be an nfs issue:as I get: rpc.mountd[764]: Caught signal 15, un-registering and exiting. systemd[1]: rpc-statd.service: Deactivated successfully. Created attachment 752682 [details]
boot log 5.15.3 (fails)
Created attachment 752686 [details]
5.15.2 boot log (success)
Created attachment 752690 [details]
5.15.3 boot log (fails)
I think the rpc thing is a red herring - that was on shutdown. New boot log of the failing kernel. (In reply to Chris Smith from comment #5) > I think the rpc thing is a red herring - that was on shutdown. > New boot log of the failing kernel. did you mean to attach something here? (In reply to Mike Pagano from comment #6) > (In reply to Chris Smith from comment #5) > > I think the rpc thing is a red herring - that was on shutdown. > > New boot log of the failing kernel. > > did you mean to attach something here? I did, a replacement for the previous 5.15.3 failing boot log. >nvidia_drm: unknown parameter 'modeset' ignored
This would happen if CONFIG_DRM_KMS_HELPER is not set in the kernel's .config, nvidia-drivers build.log is likely has:
* CONFIG_DRM_KMS_HELPER: is not set but needed for Xorg auto-detection
* of drivers (no custom config), and for wayland / nvidia-drm.modeset=1.
* Cannot be directly selected in the kernel's menuconfig, so enable
* options such as CONFIG_DRM_FBDEV_EMULATION instead.
Unfortunately the above instructions may not work anymore.
I believe it's due to this change in 5.15.3 which may have deselected it if have no other DRM selected (like amdgpu)
config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
- depends on DRM
- depends on FB=y || FB=DRM
- select DRM_KMS_HELPER
+ depends on DRM_KMS_HELPER
+ depends on FB=y || FB=DRM_KMS_HELPER
Honestly not quite sure what's a sane way to suggest enabling KMS_HELPER (not selectable on its own), not an issue on generic kernels but this been quite annoying for custom minimal ones.
Being unset will prevent auto-detection and the Xorg nvidia module won't be loaded.
There may be more to this too, I think may also have messed with nvidia's detection. Need to look more closely at this. Don't be surprised if enabling it still doesn't work. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=14a3189a2e07e59d2c2a28a7348aff842343e4c2 commit 14a3189a2e07e59d2c2a28a7348aff842343e4c2 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2021-11-19 06:07:59 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2021-11-19 07:03:13 +0000 x11-drivers/nvidia-drivers: update KMS_HELPER error message and sed Error message updated to help users enable it on kernel 5.15.3+ which no longer selects KMS_HELPER with CONFIG_DRM_FBDEV_EMULATION. This may unfortunately cause a poor surprise (failing Xorg) to users that did not notice this newly appearing message with minimal kernels and didn't have a custom xorg.conf forcing nvidia. Also modified sed to ensure nvidia-drm is properly built with support if KMS_HELPER is a module and DRM is not (revbump latest arch/~arch for this). Bug: https://bugs.gentoo.org/824594 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> x11-drivers/nvidia-drivers/nvidia-drivers-390.144-r1.ebuild | 10 ++++++---- x11-drivers/nvidia-drivers/nvidia-drivers-460.91.03-r1.ebuild | 8 +++++--- x11-drivers/nvidia-drivers/nvidia-drivers-470.62.12.ebuild | 8 +++++--- x11-drivers/nvidia-drivers/nvidia-drivers-470.82.00.ebuild | 8 +++++--- ...a-drivers-470.86.ebuild => nvidia-drivers-470.86-r1.ebuild} | 8 +++++--- ...rivers-495.44-r1.ebuild => nvidia-drivers-495.44-r2.ebuild} | 8 +++++--- x11-drivers/nvidia-drivers/nvidia-drivers-495.44.ebuild | 8 +++++--- 7 files changed, 36 insertions(+), 22 deletions(-) Guess there's still a chance the issue was something else (need confirmation), but I'll take it as a nvidia-drivers issue for now given it looks very likely for the sddm part. Not that there's really anything else I think I can do about this, I'll just leave the bug open for reference for a while and hope people notice the ebuild message. As mentioned in the commit, can set something like CONFIG_DRM_AMDGPU=m, DRM_I915=y or even DRM_NOUVEAU=m (nouveau is fine as long it's a module and not builtin, can be useful to have around as fallback) so they select the DRM_KMS_HELPER that can't be directly selected. DRM_SIMPLEDRM may sound nice, but it's known to cause other issues and should be left disabled (the ebuild warns about this if found enabled). Alternatively, can create a xorg.conf that force-loads nvidia as the driver. Although KMS_HELPER is still needed for wayland, without KMS_HELPER the entire nvidia-drm module is just a stub. The nvidia driver update has solved the issue. Note that I do build nouveau as a backup, although it's blacklisted. (In reply to Chris Smith from comment #12) > The nvidia driver update has solved the issue. > Note that I do build nouveau as a backup, although it's blacklisted. Nice to hear it works. If already had nouveau then I guess misdetection I mentioned in comment #9 is what caused issues for you then (did add a small fix for that). Looks like FBDEV_EMULATION once again selects KMS_HELPER in 5.15.4 so this should reduce amount of surprises and think can go ahead and close this. May possibly adjust the message again but will leave it alone for now as it's more fail-proof. (In reply to Ionen Wolkens from comment #14) > Looks like FBDEV_EMULATION once again selects KMS_HELPER in 5.15.4 so this > should reduce amount of surprises and think can go ahead and close this. > > May possibly adjust the message again but will leave it alone for now as > it's more fail-proof. And yes, leaving it alone given 5.16.x changed things around again. Suggesting FBDEV_EMULATION doesn't seem viable anymore. Guess the issue is still kind of there, but mitigated by the error message. I don't think much else I can do. |