In xfdrake, select "latest legacy"
https://wiki.mageia.org/en/Setup_the_graphical_server#Nvidia_driver_versions

CC: (none) => fri

I chose latest legacy and It failed..

Did you install kernel-devel before the driver?
https://wiki.mageia.org/en/Setup_the_graphical_server#Known_Nvidia_issues

Your GT630 uses an old Fermi chip (GF108) which is only supported with v390. As this driver is EOL it is no longer available in Mageia. That is way the driver detection installs snd uses Bouveau.

You can try if xorg modesetting works better than nouveau.

In this case nvidia390 doesn´t work with latest kernels.. it would be great to be able to keep kernel 5.19 from mageia 8 and still use nvidia390 on mageia 9.

Once mageia is upgraded to 9 XFdrake changes everything. It would be great to have an option to keep old video driver and kernel if possible.

Is there some significant problem with using xorg modesetting?

For proprietary 390 om mga9
https://wiki.mageia.org/en/Setup_the_graphical_server#Elder_Nvidia_drivers

You may ask on another forum if someone have tried and have more info.

Is this the same thing as Bug 33678 ?

GeForce GT630 should be supported by nvidia470 drivers. If "lspcidrake -v" shows for that  card a device id of 0xfc2 or 0x1284 then it's supported, otherwise it's an older variant of GT630 not supported by this version of drivers.

CC: (none) => ghibomgx

(In reply to Giuseppe Ghibò from comment #9)
> GeForce GT630 should be supported by nvidia470 drivers. If "lspcidrake -v"
> shows for that  card a device id of 0xfc2 or 0x1284 then it's supported,
> otherwise it's an older variant of GT630 not supported by this version of
> drivers.

As far as I know, nvidia 470 only supports kepler chips and not fermi. My friends is a fermi chip GT630.

Even on windows, nvidia experience keeps saying 470 update is available but it won't install. So the only way it's to use nvidia 390 with kernel 5.19.

Well, there are some GT630 supported (probably they are in the Kepler arch) with the id above. Your friend probably has device id 0x0f00 which is not supported in 470.xx. I already seen this with some other GT cards. Same card model but different archs (and thus deviceIDs).

Another way would be a bit of challenging: e.g. try to resurrect nvidia390 for building in current kernel (locally), by taking the sources from our svn of nvidia390 (i.e. here https://svnweb.mageia.org/packages/obsolete/nvidia390/current/SPECS/), and applying the patches for current kernel from arch, for instance: e.g. from https://aur.archlinux.org/packages/nvidia-390xx-dkms) and get them compiling with current 6.6 kernel. But it's not said that the driver ABI would still be compatible with current Xorg. In that case you might require to start the Xorg server adding "Option IgnoreABI 1" in the server flags of xorg.conf (note that it could start Xorg but then for some advanced desktop the missed ABI could cause some instability or crash when libraries are trying to use them).

Alternative use some out-of-tree kernel. I've an uptodate 5.10.228 and 5.15.167 here in the older series 5.10.x and 5.15.x:

https://download.copr.fedorainfracloud.org/results/ghibo/mageia9-bonus/mageia-9-x86_64/08020882-kernel/

https://download.copr.fedorainfracloud.org/results/ghibo/mageia9-bonus/mageia-9-x86_64/08168931-kernel/

(In reply to Giuseppe Ghibò from comment #11)
> Well, there are some GT630 supported (probably they are in the Kepler arch)
> with the id above. Your friend probably has device id 0x0f00 which is not
> supported in 470.xx. I already seen this with some other GT cards. Same card
> model but different archs (and thus deviceIDs).
> 
> Another way would be a bit of challenging: e.g. try to resurrect nvidia390
> for building in current kernel (locally), by taking the sources from our svn
> of nvidia390 (i.e. here
> https://svnweb.mageia.org/packages/obsolete/nvidia390/current/SPECS/), and
> applying the patches for current kernel from arch, for instance: e.g. from
> https://aur.archlinux.org/packages/nvidia-390xx-dkms) and get them compiling
> with current 6.6 kernel. But it's not said that the driver ABI would still
> be compatible with current Xorg. In that case you might require to start the
> Xorg server adding "Option IgnoreABI 1" in the server flags of xorg.conf
> (note that it could start Xorg but then for some advanced desktop the missed
> ABI could cause some instability or crash when libraries are trying to use
> them).
> 
> Alternative use some out-of-tree kernel. I've an uptodate 5.10.228 and
> 5.15.167 here in the older series 5.10.x and 5.15.x:
> 
> https://download.copr.fedorainfracloud.org/results/ghibo/mageia9-bonus/
> mageia-9-x86_64/08020882-kernel/
> 
> https://download.copr.fedorainfracloud.org/results/ghibo/mageia9-bonus/
> mageia-9-x86_64/08168931-kernel/

Unfortunately he's nvidia 630 has fermi so only driver 390 works.

He is using mageia 8 with kernel 5.19. I wonder if he upgrades to mageia 9 and keeps using kernel 5.19 will mageia 9 still works with driver 390.

What I described in comment #33549#c11, can be achieved now easily building locally the RPM packages off-tree, using:

mgarepo co svn://svn.mageia.org/svn/packages/obsolete/nvidia390
bm -l nvidia390/SPECS/nvidia390.spec

having previously installed mgarepo, bm, and the other building tools required. That command would build an 390.157's rpm version building on newer kernels (including 6.6.x).

In theory it should work, and also without any IgnoreABI, as Xorg ABI 25 is still supported. But can't say about stability. Of course it has two limits: 

a) it doesn't include any security fixes as upstream support for nvidia390-390.157 ended 2 years ago.

b) you can't use current drakx11 anymore for configuring it (e.g. with automatic retrieving of the right packages, etc.) because it's no longer supported in current ldetect-lst, so in case you need to reconfigure it, you need to do that manually.

(In reply to Giuseppe Ghibò from comment #13)
> What I described in comment #33549#c11, can be achieved now easily building
> locally the RPM packages off-tree, using:
> 
> mgarepo co svn://svn.mageia.org/svn/packages/obsolete/nvidia390
> bm -l nvidia390/SPECS/nvidia390.spec
> 
> having previously installed mgarepo, bm, and the other building tools
> required. That command would build an 390.157's rpm version building on
> newer kernels (including 6.6.x).
> 
> In theory it should work, and also without any IgnoreABI, as Xorg ABI 25 is
> still supported. But can't say about stability. Of course it has two limits: 
> 
> a) it doesn't include any security fixes as upstream support for
> nvidia390-390.157 ended 2 years ago.
> 
> b) you can't use current drakx11 anymore for configuring it (e.g. with
> automatic retrieving of the right packages, etc.) because it's no longer
> supported in current ldetect-lst, so in case you need to reconfigure it, you
> need to do that manually.

When you say: configure it manually, do you mean install the packages manually and configuring /etc/X11/xorg.conf  and update inits?

(In reply to Ezequiel Partida from comment #14)
> (In reply to Giuseppe Ghibò from comment #13)
> > What I described in comment #33549#c11, can be achieved now easily building
> > locally the RPM packages off-tree, using:
> > 
> > mgarepo co svn://svn.mageia.org/svn/packages/obsolete/nvidia390
> > bm -l nvidia390/SPECS/nvidia390.spec
> > 
> > having previously installed mgarepo, bm, and the other building tools
> > required. That command would build an 390.157's rpm version building on
> > newer kernels (including 6.6.x).
> > 
> > In theory it should work, and also without any IgnoreABI, as Xorg ABI 25 is
> > still supported. But can't say about stability. Of course it has two limits: 
> > 
> > a) it doesn't include any security fixes as upstream support for
> > nvidia390-390.157 ended 2 years ago.
> > 
> > b) you can't use current drakx11 anymore for configuring it (e.g. with
> > automatic retrieving of the right packages, etc.) because it's no longer
> > supported in current ldetect-lst, so in case you need to reconfigure it, you
> > need to do that manually.
> 
> When you say: configure it manually, do you mean install the packages
> manually and configuring /etc/X11/xorg.conf  and update inits?

Sort of, as just installing the packages *390 is not enough for automatically config nvidia. There is a procedure in the README.manual-setup file in the doc dir of the package (this is file is also in other driver package series, like nvidia-current, nvidia470, etc.).

A simple tip is to configure the card using nvidia470, so that it will install the 470 packages and generates the proper /etc/X11/xorg.conf files to use the nvidia470 driver, then replace the 470 with nvidia390 packages and run the 'update-alternatives --set gl_conf /etc/nvidia390/ld.so.conf; ldconfig -X'

Above post is now linked to from
https://wiki.mageia.org/en/Setup_the_graphical_server#Elder_Nvidia_drivers

Feedback if procedure works will be much appreciated, and we can then write it out clearly there directly :-)

I can confirm that nvidia390 drivers can be built, installed, and run on a ThinkPad Edge E350 laptop (Intel-i915/Nvidia Fermi-GF108M graphics) with Mageia 9 following the above instructions with a slight change. This laptop was running only Intel graphics, and I didn't bother with the Nvidia card, but lately I found a use for it, so this solution works for me. 

To sum it up:

1. Build nvidia390 packages from the svn-obsolete repository.

2. Ensure that the dkms and the kernel-desktop-devel packages are installed.

3. Install the "nvidia470" drivers (Giuseppe's great tip).

   dkms-nvidia470, nvidia470-lib32, x11-driver-video-nvidia470

4. Uninstall all nvidia470 packages and install nvidia390 ones.

5. At this point I should have followed Giuseppe's step by running the "update-alternatives" command as the last step in comment#15, but I haven't done so. I installed the "mageia-prime" package and ran "mageia-prime-install" (there are some messages about nvidia470; just ignore them and wait for it to finish) and rebooted. Now, the system is running with the "nvidia390" driver, and "mageia-prime" allows back and forth between Intel and Nvidia cards(https://wiki.mageia.org/en/Mageia-prime_for_Optimus).

Great, thanks.

CC: (none) => arusanu

Thank you!

Please check:
https://wiki.mageia.org/en/Setup_the_graphical_server#Self_compiling_R390


BTW i guess my Nvidia GT218M [NVS 3100M] need R340?

Is there a place we can drop a GPU name and get a required driver??

I want to write a not on how to know what driver a user should try when he knows the GPU chip he have.

(In reply to Morgan Leijström from comment #18)
> Please check:
> https://wiki.mageia.org/en/Setup_the_graphical_server#Self_compiling_R390
In my case, I haven't used drakx11 (step 3 in that procedure). If there is a need for drakx11, I think it should be after the nvidia390 driver is installed.

N.B.: This procedure works only for x86_64 systems. The nvidia390 packages fail to build for i586 arches because the kernel-6.3.patch fails to be applied (remove the "kernel/nvidia-uvm/uvm8.c" hunk from kernel-6.3.patch to complete building for i586). I haven't test it though.

Cheers.

(In reply to Morgan Leijström from comment #18)

> Thank you!
> 
> Please check:
> https://wiki.mageia.org/en/Setup_the_graphical_server#Self_compiling_R390
> 
> 
> BTW i guess my Nvidia GT218M [NVS 3100M] need R340?

Indeed yes, as shown here:

https://www.nvidia.com/en-us/drivers/details/156163/

however, if you are thinking to to apply the same trick of nvidia390 also for nvidia340 and the NVS3100M card there are a certain number of problems:

- as we now the 340.xx series, like 390.xx dropped support upstream, either for newer kernels as well as for security problems, so it won't build for newer kernels. A temporary solution could be to use an older kernel series to the version it was booting up, admitting other problems in the newer compiler aren't showing up.

- I've a 340.xx series package with the patches to let it compiling on newer kernels, at least of up 6.6 kernel, however I can't upload to 'obsolete' svn, because I've not authorized perms by the mgarepo.

- Even if we could get the 340.xx series compiling on newer kernels, another problem arise, which is the Xorg ABI. Our Xorg 21 has a ABI 25, while maximum ABI supported by nvidia340.xx series is 24. A trick to circumvent this is to add the "IgnoreABI"  "True" directive to xorg.conf in the ServerFlags section. However, this would expose missed functions in libraries when you start X, and there are already desktops like newer Plasma or gnome using them, so in the end you might get a desktop with some crash, unless you start with a tiny desktop like openbox (apparently worked to me, but crashed as soon it was used something of more substantial like a web camera application). Another solution is to build an older Xorg in the 1.20 series, maybe with all the security patches applied from LTS distros, however it's not enough too, as it would require all the stack of old (plus patches) libraries (QT, etc.) to the point they were not using newer ABI. I tried a bit, but while it was successful in getting a 1.20 Xorg, it's a too much work for getting the whole old toolchain.

- Beyond Xorg ABI it might arise the problem of OpenGL level. Mostly newer desktops have a minimum OpenGL level of 3.3, while some old card with hardware 3D acceleration (even with nvidia340.xx) have a maximum level of 2.1, so you might have a desktop crashing with an unsupported hardware OpenGL level, so you have to disable the 3D acceleration, and fallback to llvmpipe software acceleration, though it's not the case of NVS 3100, which has an hardware OpenGL support of 3.3.

- So if it's crashing, a further solution could be to report upstream (which might be the nouveau kernel modules, mesa, etc.).

> 
> Is there a place we can drop a GPU name and get a required driver??
> 
> I want to write a not on how to know what driver a user should try when he
> knows the GPU chip he have.

Sometimes to remove the xorg.conf and let the Xorg choose automatically its driver (but in the end is usually modesetting). That's remind we should add such feature (i.e. a button to let Xorg removing the xorg.conf and start without) to the drakx11/XFdrake, at least starting from a bug# of enhancing, so to remind.

(In reply to Aurelian R from comment #17)
> I can confirm that nvidia390 drivers can be built, installed, and run on a
> ThinkPad Edge E350 laptop (Intel-i915/Nvidia Fermi-GF108M graphics) with
> Mageia 9 following the above instructions with a slight change. This laptop
> was running only Intel graphics, and I didn't bother with the Nvidia card,
> but lately I found a use for it, so this solution works for me. 
> 
> To sum it up:
> 
> 1. Build nvidia390 packages from the svn-obsolete repository.
> 
> 2. Ensure that the dkms and the kernel-desktop-devel packages are installed.
> 
> 3. Install the "nvidia470" drivers (Giuseppe's great tip).
> 
>    dkms-nvidia470, nvidia470-lib32, x11-driver-video-nvidia470
> 
> 4. Uninstall all nvidia470 packages and install nvidia390 ones.
> 
> 5. At this point I should have followed Giuseppe's step by running the
> "update-alternatives" command as the last step in comment#15, but I haven't
> done so. I installed the "mageia-prime" package and ran
> "mageia-prime-install" (there are some messages about nvidia470; just ignore
> them and wait for it to finish) and rebooted. Now, the system is running
> with the "nvidia390" driver, and "mageia-prime" allows back and forth
> between Intel and Nvidia
> cards(https://wiki.mageia.org/en/Mageia-prime_for_Optimus).
> 
> Great, thanks.


yes, mageia-prime helped for optimus.

(In reply to Aurelian R from comment #19)
> (In reply to Morgan Leijström from comment #18)
> > Please check:
> > https://wiki.mageia.org/en/Setup_the_graphical_server#Self_compiling_R390
> In my case, I haven't used drakx11 (step 3 in that procedure). If there is a
> need for drakx11, I think it should be after the nvidia390 driver is
> installed.
> 
> N.B.: This procedure works only for x86_64 systems. The nvidia390 packages
> fail to build for i586 arches because the kernel-6.3.patch fails to be
> applied (remove the "kernel/nvidia-uvm/uvm8.c" hunk from kernel-6.3.patch to
> complete building for i586). I haven't test it though.
> 
> Cheers.

Does applying in i586 %patch4 (which is applied only for x86_64) before the kernel-6.3 patch would let patches applying correctly and compiles on i586?

(In reply to Giuseppe Ghibò from comment #22)
> Does applying in i586 %patch4 (which is applied only for x86_64) before the
> kernel-6.3 patch would let patches applying correctly and compiles on i586?

Nope, same failure.
build log output snippets for i586 with patch4 enabled:
...
Patch #4 (NVIDIA-Linux-x86_64-375.39-disable-phys_to_dma-check.patch):
+ /usr/bin/patch --no-backup-if-mismatch -f -p1 --fuzz=0
...
The text leading up to this was:
--------------------------
|diff --git a/kernel/nvidia-uvm/uvm8.c b/kernel/nvidia-uvm/uvm8.c
|index 11cb373..49e1047 100644
|--- a/kernel/nvidia-uvm/uvm8.c
|+++ b/kernel/nvidia-uvm/uvm8.c
--------------------------
No file to patch.  Skipping patch.
...

File "kernel/nvidia-uvm/uvm8.c" is not generated by "NVIDIA-Linux-x86-390.157.run", so nothing to patch.

(In reply to Aurelian R from comment #19)
> (In reply to Morgan Leijström from comment #18)
> > Please check:
> > https://wiki.mageia.org/en/Setup_the_graphical_server#Self_compiling_R390
> In my case, I haven't used drakx11 (step 3 in that procedure). If there is a
> need for drakx11, I think it should be after the nvidia390 driver is
> installed.

That step is from Giuseppeś instruction, 
I think it was easiest to explain this way.
IIUC drakx11 need to be run to create xorg.conf correctly, but it can only use a driver it "knows" and it do not know 390, so user replace those packages *after* drakx11 had done the correct configuration (but installed 470).

---

Giuseppe:

>> BTW i guess my Nvidia GT218M [NVS 3100M] need R340?

> Indeed yes, as shown here:
> https://www.nvidia.com/en-us/drivers/details/156163/

Yep I do not have time to dig into 340 for this machine.

(In reply to Aurelian R from comment #23)
> (In reply to Giuseppe Ghibò from comment #22)
> > Does applying in i586 %patch4 (which is applied only for x86_64) before the
> > kernel-6.3 patch would let patches applying correctly and compiles on i586?
> 
> Nope, same failure.
> build log output snippets for i586 with patch4 enabled:
> ...
> Patch #4 (NVIDIA-Linux-x86_64-375.39-disable-phys_to_dma-check.patch):
> + /usr/bin/patch --no-backup-if-mismatch -f -p1 --fuzz=0
> ...
> The text leading up to this was:
> --------------------------
> |diff --git a/kernel/nvidia-uvm/uvm8.c b/kernel/nvidia-uvm/uvm8.c
> |index 11cb373..49e1047 100644
> |--- a/kernel/nvidia-uvm/uvm8.c
> |+++ b/kernel/nvidia-uvm/uvm8.c
> --------------------------
> No file to patch.  Skipping patch.
> ...
> 
> File "kernel/nvidia-uvm/uvm8.c" is not generated by
> "NVIDIA-Linux-x86-390.157.run", so nothing to patch.

Ok, 32 and 64bit have a different source, try with current 390.157-4, should compile.

(In reply to Morgan Leijström from comment #24)

> (In reply to Aurelian R from comment #19)
> > (In reply to Morgan Leijström from comment #18)
> > > Please check:
> > > https://wiki.mageia.org/en/Setup_the_graphical_server#Self_compiling_R390
> > In my case, I haven't used drakx11 (step 3 in that procedure). If there is a
> > need for drakx11, I think it should be after the nvidia390 driver is
> > installed.
> 
> That step is from Giuseppeś instruction, 
> I think it was easiest to explain this way.
> IIUC drakx11 need to be run to create xorg.conf correctly, but it can only
> use a driver it "knows" and it do not know 390, so user replace those
> packages *after* drakx11 had done the correct configuration (but installed
> 470).

Exactly, at least for discrete card. A working xorg.conf for an nvidia card had to be created before it's usage of the driver, as just installing the 390.xx packages wouldn't let to automatically use them.

Indeed I had a legacy ldetect-lst-0.6.58-2.legacy.mga9 in my copr out of tree page, which might facilitate to choose directly "NVIDIA Driver: 390.xx Legacy" under the drakx11's NVIDIA->... menu, but the page URL is subject to change and also ldetect-lst is surpassed by 0.6.59 upstream.

> 
> ---
> 
> Giuseppe:
> 
> >> BTW i guess my Nvidia GT218M [NVS 3100M] need R340?
> 
> > Indeed yes, as shown here:
> > https://www.nvidia.com/en-us/drivers/details/156163/
> 
> Yep I do not have time to dig into 340 for this machine.

IMHO, as I've described, chances for getting chipset working with resuming 340.xx series (even if they compile correctly with current kernels) with mga9 are pretty tight at the moment, due to the chain of problems, so I wouldn't cite 340.xx anymore.

Let's see with the upcoming mesa-24.3.2|3.

(In reply to Giuseppe Ghibò from comment #25)
> Ok, 32 and 64bit have a different source, try with current 390.157-4, should compile.
Yep, it builds now without a glitch on both arches.

(In reply to Morgan Leijström from comment #24)
> That step is from Giuseppeś instruction, 
Thanks to both of you for the extended explanations. In my case I might have already had an Nvidia config xorg file available on that laptop, so no need to run drakx11 for me. I might try to redo the whole setup from zero. No promises, though. 

> (In reply to Morgan Leijström from comment #18)
> > Please check:
> > https://wiki.mageia.org/en/Setup_the_graphical_server#Self_compiling_R390
For general users building locally rpm packages, I think "mock" should be promoted, because "mock" isn't that disruptive to one's system (just mock permissions and a bit more extra storage to be available).
To use mock, replace the bm command with something like
>mock --root mageia-9-x86_64 --spec nvidia390/SPECS/nvidia390.spec --sources nvidia390/SOURCES --resultdir mock_pkgs
A link to the mock or packaging wiki page might help too.

Thank you. Wiki updated with suggested hints.