No /sys/class/drm/card0-* entries on kernel 4.15
Dear forum user/support, I am trying out 390.25 on linux kernels 4.14.17 and 4.15.1. On the former I have these entries: ls -1 /sys/class/drm card0 card0-DP-1 card0-DP-2 card0-eDP-1 card0-HDMI-A-1 renderD128 version while on 4.15.1 I only find card0 version So the links for the external connectors are missing. Is this intentional? I was using these to get to the EDIDs of my monitors. Cheers, Wouter
Dear forum user/support,

I am trying out 390.25 on linux kernels 4.14.17 and 4.15.1. On the former I have these entries:

ls -1 /sys/class/drm
card0
card0-DP-1
card0-DP-2
card0-eDP-1
card0-HDMI-A-1
renderD128
version

while on 4.15.1 I only find

card0
version

So the links for the external connectors are missing. Is this intentional? I was using these to get to the EDIDs of my monitors.

Cheers,

Wouter

#1
Posted 02/05/2018 12:49 PM   
I noticed that the drm_kms_helper module is no longer loaded by the nvidia driver on 4.15, while it is on 4.14 (and earlier). Loading it manually does not create the /syc/class/drm entries.
I noticed that the drm_kms_helper module is no longer loaded by the nvidia driver on 4.15, while it is on 4.14 (and earlier). Loading it manually does not create the /syc/class/drm entries.

#2
Posted 02/05/2018 06:35 PM   
according to the logs 4.15 is loaded with nvidia-drm.modeset=0, so the nodes are not created.
according to the logs 4.15 is loaded with nvidia-drm.modeset=0, so the nodes are not created.

#3
Posted 02/05/2018 07:59 PM   
Hi generic, Can you be more specific? The phrase "modeset=0" does not occur in my log. I am setting the modeset=1 flag as follows: cat /etc/modprobe.d/wouter-nvidia-modeset.conf options nvidia-current-drm modeset=1 and see that it is indeed set: sudo cat /sys/module/nvidia_drm/parameters/modeset Y I am at a loss as to why this no longer works for 4.15. Cheers, Wouter
Hi generic,

Can you be more specific? The phrase "modeset=0" does not occur in my log.

I am setting the modeset=1 flag as follows:

cat /etc/modprobe.d/wouter-nvidia-modeset.conf
options nvidia-current-drm modeset=1

and see that it is indeed set:

sudo cat /sys/module/nvidia_drm/parameters/modeset
Y

I am at a loss as to why this no longer works for 4.15.

Cheers,

Wouter

#4
Posted 02/05/2018 09:13 PM   
If you have indeed sudo cat /sys/module/nvidia_drm/parameters/modeset Y with kernel 4.15 then there's more not working, I deducted the modeset=0 parameter indirectly from the missing lines in dmesg: [code] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query.[/code]
If you have indeed
sudo cat /sys/module/nvidia_drm/parameters/modeset
Y
with kernel 4.15 then there's more not working, I deducted the modeset=0 parameter indirectly from the missing lines in dmesg:
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.

#5
Posted 02/05/2018 10:08 PM   
Dear generix, You are right that those two log lines are missing in 4.15. These generated in drivers/gpu/drm/drm_vblank.c, which saw one change between 4.14 and 4.15. Yet I do have that "Y" in 4.15.1 There appears to be only one commit (e99e88a9d2b0) difference between 4.14 and 4.15 in drm_vblank.c. I will try to revert that and see what happens. Cheers, Wouter
Dear generix,

You are right that those two log lines are missing in 4.15. These generated in drivers/gpu/drm/drm_vblank.c, which saw one change between 4.14 and 4.15.

Yet I do have that "Y" in 4.15.1

There appears to be only one commit (e99e88a9d2b0) difference between 4.14 and 4.15 in drm_vblank.c. I will try to revert that and see what happens.

Cheers,

Wouter

#6
Posted 02/05/2018 10:38 PM   
Dear generix, I bisected this regression (disappearing connector files) on the kernel side. The first bad commit is: commit 77ac3b00b13185741effd0d5e2f1f05e4bfef7dc (refs/bisect/bad) Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Wed Jul 19 16:39:20 2017 +0200 drm/atomic: Remove deprecated accessor macros Now that the last users have been converted, we can finally get rid of for_each_obj_in_state, we have better macros to replace them with. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20170719143920.25685-8-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> This might help finding what went wrong in the kernel - nvidia interaction. Cheers, Wouter
Dear generix,

I bisected this regression (disappearing connector files) on the kernel side. The first bad commit is:

commit 77ac3b00b13185741effd0d5e2f1f05e4bfef7dc (refs/bisect/bad)
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Wed Jul 19 16:39:20 2017 +0200

drm/atomic: Remove deprecated accessor macros

Now that the last users have been converted, we can finally get rid of
for_each_obj_in_state, we have better macros to replace them with.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719143920.25685-8-maarten.lankhorst@linux.intel.com

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


This might help finding what went wrong in the kernel - nvidia interaction.

Cheers,

Wouter
Attachments

bisect log.txt

#7
Posted 02/06/2018 10:15 AM   
Dear generix, Interesting. After commit 77ac3b00b131, in the kernel source, > git grep for_each_connector_in_state returns 0 hits. While in the nvidia source we get one hit: > grep for_each_connector_in_state -r /var/lib/dkms/nvidia-current/390.25/source nvidia-drm/nvidia-drm-crtc.c: for_each_connector_in_state(crtc_state->state, Now checking why this compiles... Cheers, Wouter
Dear generix,

Interesting.
After commit 77ac3b00b131, in the kernel source,
> git grep for_each_connector_in_state
returns 0 hits.

While in the nvidia source we get one hit:
> grep for_each_connector_in_state -r /var/lib/dkms/nvidia-current/390.25/source
nvidia-drm/nvidia-drm-crtc.c: for_each_connector_in_state(crtc_state->state,

Now checking why this compiles...

Cheers,

Wouter

#8
Posted 02/06/2018 10:24 AM   
Okay, from the nvidia compilation logs > grep NV_DRM_ATOMIC_MODESET /var/lib/dkms/nvidia-current/390.25/4.14.17/x86_64/log/make.log #define NV_DRM_ATOMIC_MODESET_AVAILABLE #define NV_DRM_ATOMIC_MODESET_NONBLOCKING_COMMIT_AVAILABLE > grep NV_DRM_ATOMIC_MODESET /var/lib/dkms/nvidia-current/390.25/4.15.1/x86_64/log/make.log #undef NV_DRM_ATOMIC_MODESET_AVAILABLE #define NV_DRM_ATOMIC_MODESET_NONBLOCKING_COMMIT_AVAILABLE and the contents of nvidia-drm-crtc.c get #ifdeffed out. Next, why does this variable get unset? Cheers, Wouter
Okay, from the nvidia compilation logs

> grep NV_DRM_ATOMIC_MODESET /var/lib/dkms/nvidia-current/390.25/4.14.17/x86_64/log/make.log
#define NV_DRM_ATOMIC_MODESET_AVAILABLE
#define NV_DRM_ATOMIC_MODESET_NONBLOCKING_COMMIT_AVAILABLE

> grep NV_DRM_ATOMIC_MODESET /var/lib/dkms/nvidia-current/390.25/4.15.1/x86_64/log/make.log
#undef NV_DRM_ATOMIC_MODESET_AVAILABLE
#define NV_DRM_ATOMIC_MODESET_NONBLOCKING_COMMIT_AVAILABLE

and the contents of nvidia-drm-crtc.c get #ifdeffed out.

Next, why does this variable get unset?

Cheers,

Wouter

#9
Posted 02/06/2018 10:30 AM   
Dear generix, I think that the check in conftest.h:2151 fails after kernel commit 77ac3b00b131. This check tests usability of the old iterator paradigm. Commit 77ac3b00b131 has an extended commit log with instructions for converting to the new style of iterators. Not sure I can help here. Seems like a task for an actual developer... Cheers, Wouter
Dear generix,

I think that the check in conftest.h:2151 fails after kernel commit 77ac3b00b131. This check tests usability of the old iterator paradigm.

Commit 77ac3b00b131 has an extended commit log with instructions for converting to the new style of iterators. Not sure I can help here. Seems like a task for an actual developer...

Cheers,

Wouter

#10
Posted 02/06/2018 10:36 AM   
I second this bug, no entries and only a single display detected. This is causing a few issues with my Xorg having to be run twice in a row to get anywhere, as well as a black screen on all but one monitor after boot.
I second this bug, no entries and only a single display detected.

This is causing a few issues with my Xorg having to be run twice in a row to get anywhere, as well as a black screen on all but one monitor after boot.

#11
Posted 02/07/2018 12:48 PM   
Dear justcrunkle, Just to clarify my situation, I am running 4.15 on a two screen setup (HDMI external monitor and laptop internal DP). After booting I see sddm on both screens. I can control both screens with nvidia-settings. Cheers, Wouter
Dear justcrunkle,

Just to clarify my situation, I am running 4.15 on a two screen setup (HDMI external monitor and laptop internal DP). After booting I see sddm on both screens. I can control both screens with nvidia-settings.

Cheers,

Wouter

#12
Posted 02/07/2018 06:32 PM   
I have fixed this issue using a source patch from the Arch Linux bug reports.
I have fixed this issue using a source patch from the Arch Linux bug reports.

#13
Posted 02/10/2018 04:23 AM   
Dear justcrunkle, Good news for you. Could you please help everyone else out by posting a link? Cheers, Wouter
Dear justcrunkle,

Good news for you. Could you please help everyone else out by posting a link?

Cheers,

Wouter

#14
Posted 02/10/2018 07:32 AM   
Dear justcrunkle, I guess you mean this patch https://bugs.archlinux.org/task/57305?getfile=16124 in this post https://bugs.archlinux.org/task/57305?string=nvidia+4.15&project=1&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Cheers, Wouter
Scroll To Top

Add Reply