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
nvidia-bug-report.log.gz (176 KB)
nvidia-bug-report.log.gz (180 KB)

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.

according to the logs 4.15 is loaded with nvidia-drm.modeset=0, so the nodes are not created.

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

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.

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,

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

bisect log.txt (2.9 KB)

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

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

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

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.

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

I have fixed this issue using a source patch from the Arch Linux bug reports.

Dear justcrunkle,

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

Cheers,

Wouter

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[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

Cheers,

Wouter

Dear justcrunkle,

Yes, that patch solves it.

Thanks!