I'll post the output of "eglinfo -B" there shortly. Thank you very much for the help so far.
]]>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 )
]]>Anyways, here goes my concern:
Do you know if its possible for the nouveau driver to recognize an NVIDIA 520M 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 520M 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.
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.
]]>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
++ 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.
]]>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.
]]>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.
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?
]]>@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.
]]>