nvidia-390xx AUR package discussion thread

canolucas · 2022-12-11 02:05:10

Yes, the updated version of the driver v157 has been released more than a month ago. It also seems that there is a git clone of the package definition has been created here:
https://github.com/FiestaLake/nvidia-390xx-utils/

Is it possible to get this changes merged to the AUR package so it gets updated to the new version of the driver ?

vnctdj · 2022-12-11 16:01:32

I made the needed changes in the Git repo on my PC, I could have just pushed the changes to the remote but I don't have the correct access rights (that's normal, I guess?).
Can anyone help me? How to get approval?

Slithery · 2022-12-11 16:15:37

vnctdj wrote:

Can anyone help me? How to get approval?

Only the current maintainer for an AUR package has push access to the repo.
Either email them or post your updated PKGBUILD as a comment on the AUR requesting they take a look.

vnctdj · 2022-12-11 16:40:24

The current maintainer, jonathon, hasn't posted an update in quite a while and had asked for someone with compatible hardware to become a maintainer, see https://aur.archlinux.org/pkgbase/nvidi … ent-771255
I have an old laptop with a GT 540M and know how to use Git, would it be enough to become the new maintainer?

Slithery · 2022-12-11 16:50:17

You would first have to apply for a successful orphan request and then take over the package as the new mintainer.
https://wiki.archlinux.org/title/Arch_U … ut-of-date

vnctdj · 2022-12-11 17:02:35

Thanks for your help, I just applied for a request.

vnctdj · 2022-12-13 23:36:33

I noticed I now have write access on the nvidia-390xx repositories: thanks to the person who added them!
I have updated https://aur.archlinux.org/pkgbase/nvidia-390xx-utils and also https://aur.archlinux.org/pkgbase/nvidia-390xx-settings and https://aur.archlinux.org/pkgbase/lib32 … 90xx-utils
However I don't use the last 2 at the moment, so I haven't tested them...

yochananmarqos · 2022-12-13 23:39:55

@vnctdj: I'm pretty sure you can drop the kernel-4.16.patch.

loqs · 2022-12-14 00:11:22

yochananmarqos wrote:

@vnctdj: I'm pretty sure you can drop the kernel-4.16.patch.

Technically the patch is still correct, it would only matter if the system had encrypted memory support enabled. I think that was broken in the 390xx series for other reasons.

vnctdj · 2022-12-14 21:04:27

loqs wrote:

yochananmarqos wrote:
@vnctdj: I'm pretty sure you can drop the kernel-4.16.patch.
Technically the patch is still correct, it would only matter if the system had encrypted memory support enabled. I think that was broken in the 390xx series for other reasons.

I'm not sure to understand what is "broken" here: is this patch still useful?

loqs · 2022-12-15 21:26:20

vnctdj wrote:

I'm not sure to understand what is "broken" here: is this patch still useful?

In 4.16 the linux kernel moved the function prototype for phys_to_dma. Nvidia did not update their conftest.sh for this so the function is marked as unavailable.
None the arch kernels ship with CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y so you would need a system that supports AMD Memory Encryption and add mem_encrypt=on on the kernel command line, to test if the patch makes a difference.

vnctdj · 2022-12-16 23:15:47

Thanks for the explanations!
So this is for rather niche systems... but as long as it doesn't cause problems let's keep it.
I've renamed the patch to better understand its purpose.

drankinatty · 2023-02-08 07:09:29

Well, pacman update that pulls in linux 6.1.9.arch1-1 -> 6.1.9.arch1-2 breaks the ability to connect to the X-server using nvidia-390xx-utis. Intel graphics work fine, so it's not a generic xorg problem, it's something in the nvidia-390xx-utils package that is no longer playing nicely establishing a connection to the server.

The kernel change isn't the cause, but a package contemporaneous in time with the break. glibc (2.36-7 -> 2.37-2) may be the likely culprit, as the failure is the same under linux-LTS now too. The first indication on my system was lightdm appearing as a black screen with artifacts around the edge -- but this is an xorg break, not lightdm specific (the lightdm screen state is just due it it failing to clean up after itself). The driver builds and is loaded fine by X. No issues in Xorg.0.log.

With startx/xinit the error is

xinit: unable to connect to X server: Connection refused

, e.g.:

$ startx

X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
Current Operating System: Linux valkyrie 6.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 03 Feb 2023 18:49:53 +0000 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=515ef9dc-769f-4548-9a08-3a92fa83d86b rw iommu=soft amd_iommu_dump= quiet audit=0

Current version of pixman: 0.42.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Tue Feb  7 21:02:15 2023
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

All nvidia-390xx packages are freshly built today:

$ pmq | grep nvidia
nvidia-390xx-dkms 390.157-1
nvidia-390xx-settings 390.157-1
nvidia-390xx-utils 390.157-1
opencl-nvidia-390xx 390.157-1

And all modules are loaded and happy:

$ lsmod | grep nvidia
nvidia_drm             57344  0
nvidia_modeset       1318912  1 nvidia_drm
nvidia_uvm           1912832  0
nvidia              19505152  2 nvidia_uvm,nvidia_modeset
video                  65536  1 nvidia
ipmi_msghandler        81920  2 ipmi_devintf,nvidia

When using startx, X appears to fully start before being shut down by the Connection Refused error. This isn't just on my box as an additional confirmation was received on the AUR page after I posted my original comment AUR-nvidia-390xx-utils.

I understand the package maintainer doesn't have a card to test with, so I'm happy to test here and post relevant details, but I'm a bit confused on what testing would be the most helpful to narrow down the issue? strace startx? I can post the Xorg.0.log or any other details that will help, but will wait for a request since the Xorg.0.log doesn't show anything accept a successful load of the nvidia driver.

Let me know where to look next and I'm happy to provide the information.

Last edited by drankinatty (2023-02-08 07:11:40)

seth · 2023-02-08 07:27:49

https://bbs.archlinux.org/viewtopic.php?id=283327

drankinatty · 2023-02-08 08:56:20

The strace of startx wasn't helpful -- everything worked. The problem is xinit is failing, but again everything seems to work fine. Even a sh -x /usr/bin/startx &> file shows all commands for auth, mcookie and authcookie succeeding, but xinit simply fails with an return of -1. For example, the final setup and execution of xinit is fine, all tests pass and the command line looks correct, but then the connection refused error occurs:

++ mktemp -p /tmp serverauth.XXXXXXXXXX
+ xserverauthfile=/tmp/serverauth.OGjWOmCBK1
+ trap 'rm -f '\''/tmp/serverauth.OGjWOmCBK1'\''' HUP INT QUIT ILL TRAP BUS TERM
+ xauth -q -f /tmp/serverauth.OGjWOmCBK1
+ serverargs=' vt1 -keeptty -auth /tmp/serverauth.OGjWOmCBK1'
+ for displayname in $authdisplay $hostname/unix$authdisplay
++ xauth list :3
++ sed -n 's/.*valkyrie\/unix:3[[:space:]*].*[[:space:]*]//p'
+ authcookie=
+ '[' z = z ']'
+ xauth -q
+ removelist=':3 '
+ for displayname in $authdisplay $hostname/unix$authdisplay
++ xauth list valkyrie/unix:3
++ sed -n 's/.*valkyrie\/unix:3[[:space:]*].*[[:space:]*]//p'
+ authcookie=ab0f21940c2bdde0a532991312b22174
+ '[' zab0f21940c2bdde0a532991312b22174 = z ']'
+ dummy=1
+ xauth -q -f /tmp/serverauth.OGjWOmCBK1
+ xinit /home/david/.xinitrc -- /etc/X11/xinit/xserverrc :3 vt1 -keeptty -auth /tmp/serverauth.OGjWOmCBK1


X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
(snip rest of same error posted above)

So if the auth token creation is all good, then it has to be something in the driver and whatever interfaces with it to check the tokens that broke. Or writing to /tmp may have changed? With each attempted startx, stale lock files are left, e.g.

# cd /tmp
# l
drwxrwxrwt  2 root  root    40 Feb  7 19:06 .ICE-unix
drwxrwxrwt  2 root  root   120 Feb  8 02:32 .X11-unix
drwxrwxrwt  2 root  root    40 Feb  7 19:06 .XIM-unix
drwxrwxrwt  2 root  root    40 Feb  7 19:06 .font-unix
-r--r--r--  1 root  david   11 Feb  7 19:15 .X0-lock
-r--r--r--  1 root  david   11 Feb  7 21:02 .X1-lock
-r--r--r--  1 root  david   11 Feb  8 01:28 .X2-lock
-r--r--r--  1 root  david   11 Feb  8 02:32 .X3-lock

(note: systemd dirs and . and .. omitted)

In the .X11-unix directory you have:

# ll .X11-unix/
total 0
srwxrwxrwx 1 root david 0 Feb  7 19:15 X0
srwxrwxrwx 1 root david 0 Feb  7 21:02 X1
srwxrwxrwx 1 root david 0 Feb  8 01:28 X2
srwxrwxrwx 1 root david 0 Feb  8 02:32 X3

So the cleanup of lock files isn't being handled either.

drankinatty · 2023-02-08 08:56:55

Oops thanks Seth, sorry.

drankinatty · 2023-08-31 01:55:28

NOTE: UNTESTED in dkms build, but I've prepared the patch based on Ubuntu patch for 6.5 kernel Actually, I have prepared two-versions, one with full whitespace correction (fixes tab/space variance in e-mailed copy of original patch) in kernel-6.5-full.patch and a second version correcting only the substantive additions/subtractions in kernel-6.5.patch. They were prepared with diff -uNr and -uNrb respectively. I have posted to paste.opensuse.org in:

kernel-6.5-full.patch

kernel-6.5.patch

Links expire Tue 26 Sep 2023 11:36:12 PM CDT

Just add to the PKGBUILD prepare() section after the kernel-6.4.patch (where you have already done cd kernel) and you will call patch with:

patch -Np1 -i ../../kernel-6.5.patch

canolucas · 2023-09-04 16:47:33

drankinatty wrote:

NOTE: UNTESTED in dkms build, but I've prepared the patch based on Ubuntu patch for 6.5 kernel

@drankinatty, I finally was able to test the patch, but I got:

( 8/13) Install DKMS modules
==> dkms install --no-depmod nvidia/390.157 -k 6.5.1-arch1-1
Error! Bad return status for module build on kernel: 6.5.1-arch1-1 (x86_64)
Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information.

There were other modifications that I needed to include as well to be able to build succesfully.
Here is the working patch, which includes all the necessary modifications: https://paste.opensuse.org/pastes/c4d14a243326
Its tested and working fine with the latest kernel (6.5.1).

NOTE:
The herecura repo has already been updated, and it already includes these fixes, here is the link: https://gitlab.com/herecura/packages/nvidia-390xx-dkms

You can use it by adding to your /etc/pacman.conf the following lines:

[herecura]
Server = https://repo.herecura.eu/herecura/x86_64

Credits go to drankinatty for the ubuntu debdiff, thanks a lot for that find.

canolucas · 2024-01-27 17:09:00

Hi guys, maybe this is not the correct thread for the following concern, maybe it partially is, please let me know if you think it will be better placed on another thread and I'll happily do so.

Anyways, here goes my concern:

Do you know if its possible for the nouveau driver to recognize an NVIDIA 820M GPU ?
I'm currently using propietaly drivers from the AUR (packages: nvidia-390xx-dkms nvidia-390xx-settings nvidia-390xx-utils lib32-nvidia-390xx-utils) however these need to be patched on almost every new version of the kernel, as official support for nvidia 390xx reached EOL, no new version is getting released officially from NVIDIA.

Some time ago I started an attempt to switch to nouveau in case the 390xx drivers will fail on any new version of the kernel, however these attempt was not successfull so far. I followed the official guides on the wiki when attempting to transition to nouveau:

Added nouveau to the MODULES array in /etc/mkinitcpio.conf
Removed every package related to the legacy 390xx drivers: yay -R nvidia-390xx-dkms nvidia-390xx-settings nvidia-390xx-utils lib32-nvidia-390xx-utils
Tried changing the driver in /etc/X11/xorg.conf
In /etc/gdm/custom.conf I tried booting with both WaylandEnable=false and WaylandEnable=true
I tried booting with xf86-video-nouveau installed
Also tried booting with xf86-video-nouveau uninstalled, to allow falling back on the modesetting driver (as suggested in the wiki)
Made sure the nouveau driver is not blacklisted within /etc/modprobe.d/

But all I get is the kernel to boot into the console and then the screen starts to flicker forever. Is there anything I may be missing ?
I think the 820M should be old and simple enough for the nouveau driver to support it, compared to the newer and powerfull new models. Thank you very much in advance, and I'm looking forward to be able to move to the open source driver to avoid this inminent compatibility breakage that will certainly happen in the near future.

Last edited by canolucas (2024-05-13 04:07:53)

Lone_Wolf · 2024-01-27 17:23:33

Better start a new thread.

According to https://nouveau.freedesktop.org/CodeNames.html#NVC0 that card is part of the Fermi / NVC0 family.
The https://nouveau.freedesktop.org/FeatureMatrix.html shows a lot of things work with that card.

wayland requires GBM support from the driver (possibly also OpenGL ES 3.2, not sure about that) .
run (and post the output) of

$ eglinfo -B  #comes_with_mesa-utils

to check. (It works fine from inside X )

canolucas · 2024-01-27 17:33:24

Here goes the new thread.
https://bbs.archlinux.org/viewtopic.php … 1#p2146841

I'll post the output of "eglinfo -B" there shortly. Thank you very much for the help so far.

Arch Linux

#126 2022-12-11 02:05:10

Re: nvidia-390xx AUR package discussion thread

#127 2022-12-11 16:01:32

Re: nvidia-390xx AUR package discussion thread

#128 2022-12-11 16:15:37

Re: nvidia-390xx AUR package discussion thread

#129 2022-12-11 16:40:24

Re: nvidia-390xx AUR package discussion thread

#130 2022-12-11 16:50:17

Re: nvidia-390xx AUR package discussion thread

#131 2022-12-11 17:02:35

Re: nvidia-390xx AUR package discussion thread

#132 2022-12-13 23:36:33

Re: nvidia-390xx AUR package discussion thread

#133 2022-12-13 23:39:55

Re: nvidia-390xx AUR package discussion thread

#134 2022-12-14 00:11:22

Re: nvidia-390xx AUR package discussion thread

#135 2022-12-14 21:04:27

Re: nvidia-390xx AUR package discussion thread

#136 2022-12-15 21:26:20

Re: nvidia-390xx AUR package discussion thread

#137 2022-12-16 23:15:47

Re: nvidia-390xx AUR package discussion thread

#138 2023-02-08 07:09:29

Re: nvidia-390xx AUR package discussion thread

#139 2023-02-08 07:27:49

Re: nvidia-390xx AUR package discussion thread

#140 2023-02-08 08:56:20

Re: nvidia-390xx AUR package discussion thread

#141 2023-02-08 08:56:55

Re: nvidia-390xx AUR package discussion thread

#142 2023-08-31 01:55:28

Re: nvidia-390xx AUR package discussion thread

#143 2023-09-04 16:47:33

Re: nvidia-390xx AUR package discussion thread

#144 2024-01-27 17:09:00

Re: nvidia-390xx AUR package discussion thread

#145 2024-01-27 17:23:33

Re: nvidia-390xx AUR package discussion thread

#146 2024-01-27 17:33:24

Re: nvidia-390xx AUR package discussion thread

Board footer