nVidia re-init fails on logout

I have noticed a problem on my desktop machine. Hardware is an i7-6850K cpu on an Asus X99A motherboard. The GPU is an nVidia RTX-3060Ti. I'm running 13.2p4, and KDE with PCDM, and
nvidia-driver-535.104.05_1, nvidia-settings-470.86_1, and nvidia-xconfig-525.116.04 (which appear to be the latest, since I just did a pkg upgrade this morning. For some period of time when I log out of the GUI (which I rarely do), apparently when it tries to reset the GPU in order to restart PCDM (I'm not sure how it is supposed to work), the screen blanks, and never comes back. I usually have to ssh in from a remote system, and reboot. It did not do this earlier in the year, just in the past couple of months.

When this happens, I see:
Code:
Nov 19 09:04:53 defiant kernel: NVRM: GPU at PCI:0000:01:00: GPU-41662ba1-d217-2728-cb14-6bba8ea9ada3
Nov 19 09:04:53 defiant kernel: NVRM: Xid (PCI:0000:01:00): 62, pid='<unknown>', name=<unknown>, 0000(0000) 00000000 00000000
Nov 19 09:04:57 defiant kernel: nvidia-modeset: ERROR: GPU:0: Display engine push buffer channel allocation failed: 0x65 (Call timed out [NV_ERR_TIMEOUT])
Nov 19 09:04:57 defiant kernel: nvidia-modeset: ERROR: GPU:0: Failed to allocate display engine core DMA push buffer

And then I get a constant streams of the following until I reboot:

Code:
Nov 19 09:05:07 defiant pcdm[2671]: [: missing ]
Nov 19 09:05:07 defiant kernel: NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x23:0xffff:1426)
Nov 19 09:05:07 defiant kernel: nvidia0: NVRM: rm_init_adapter() failed!
Nov 19 09:05:07 defiant kernel: NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x23:0xffff:1426)
Nov 19 09:05:07 defiant kernel: nvidia0: NVRM: rm_init_adapter() failed!

Has anyone encountered this issue, and is there a fix for it? I want to say that it started occuring since I upgraded to, maybe, 13.2...I generally don't log out, because the only time I would need to log out is to reboot (e.g. after a pkg upgrade, and when I do, I issue a sudo shutdown -r now instead of logging out and clicking Restart.
 
x11/pcdm

<https://github.com/beanpole135/pcdm> was archived more than three years ago, and from <https://www.linkedin.com/in/q5sys/details/experience/> I assume that the maintainer's email address is outdated.



If you start and end Plasma without pcdm, is there an issue?

exec ck-launch-session /usr/local/bin/startplasma-x11

Is the issue reproducible with SDDM in lieu of pcdm?

Reproducible with 14.0-RELEASE-p2?

Does graphics/nvidia-drm-kmod improve the situation?

Upcoming:

 
FYI:
I've just updated my patch for x11/nvidia-driver and x11/linux-nvidia-libs to 535.146.02.
This is just an update for distinfo and Makefile.version.

Beware! I cannot update the patch for nvidia-drm*-kmod ports, as distfiles are needed to be updated upstream. Users of these should wait for Austin Shafer to create distfiles and updated patch.

So my previous patch and subject are kept for now.
And as I'm neither maintainer nor committer, I cannot promise these patches would be committed or not.
 
So my previous patch and subject are kept for now.
Austin Shafer kindly uploaded his patch for updated driver. Now the subject is fixed, but unfortunately, I couldn't find the way to obsolete previous patch, so my old patch is still listed.
Maybe patches can be obsoleted only when superceding version is uploaded.
 
… couldn't find the way to obsolete previous patch, …

A few months ago, I had difficulty finding the feature even after it was described to me, repeatedly, in writing.

It's a weird interface, with edit-related stuff in three or more places.

In the attached screenshot, the feature is in the uppermost circle. (An example, but not the attachment that you wanted to obsolete. Someone else already did that, for you.)

Not just patches. Any type of attachment can be obsoleted by the person who made the attachment, or by some other person who has the privilege.
 

Attachments

  • 1702343275260.png
    1702343275260.png
    206.4 KB · Views: 43
… Now the subject is fixed, …

(The bug report is, unfortunately, defined as New.)

From <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275569#c2>:

Intentionally set depreated "patch" keyword,

Please remove the keyword.

as I can't understand how one can know there's any patch(es) available or not. …

<https://wiki.freebsd.org/Bugzilla> ‣ search queries ‣ ports and packages ‣ maintainer-approval +, non-obsolete patch, open or in progress, assigned to ports-bugs@ (not yet assigned to a person)
  • currently finds 24 reports
  • does not find 275569 because the status there is wrong.
The #freebsd-bugs channel in IRC has gaps in communication (the nature of IRC). FreeBSD's Matrix server has a bugzilla-triage room:
 
In the attached screenshot, the feature is in the uppermost circle. (An example, but not the attachment that you wanted to obsolete. Someone else already did that, for you.)
Thanks! I'd be able to do next time.
This time, Jung-uk Kim already kindly did it.

(The bug report is, unfortunately, defined as New.)
Should I, reporter, allowed change the status to "Open" myself?
My guess was that it should be done by moderators/admins or maintainers, after confirming the validity. What I've done before was to close or reopen (when the problem was resurrected) only.
If allowed, I'd be happy to change it to "Open" myself.

Please remove the keyword.
I'll do it later.

FreeBSD's Matrix server has a bugzilla-triage room:
I'm neither admin/moderator of Bugzilla, committer nor even maintainer.
Would it allowed to register and comment/request there for persons like me?
I was told that anyone want to comment to Differential Revisions on Phablicator is allowed to register when I've first requested for comments there, but is it true for this Matrix room, too? If OK, I would pop in this time.

By the way, it seems that accessing the room requires something to install.
Do you have any recommendation? Maybe www/element-web or net-im/nheko?
 
Back
Top