Puppy Linux Discussion Forum

baraka wrote: Wed Jan 25, 2023 8:31 am

If I try to manually build the driver, following jamesbond post, sandbox.sh command will throw this: (thx @dogcat for the idea)

Code: Select all

mount-FULL: /mnt/sb/fakeroot: wrong fs type, bad option, bad superblock on aufs, missing codepage or helper program, or other error.
Unable to mount aufs br:/mnt/sb/sandbox=rw:Error:=ro:Expected=ro:at=ro:least=ro:6=ro:tokens=ro:for=ro:--checklist,=ro:have=ro:4.=ro:Use=ro:--help=ro:to=ro:list=ro:options.=ro

Maybe the sandbox.sh is broken in the puppy you tried.
I found the version in BionicPup64 is broken and gave me the same error as you posted.

I found the version in FossaPup64 is working, it also works in BionicPup64. I attached the working version from FossaPup64_9.5, /usr/bin/ , better luck with this one maybe.

@dogcat
Yes, it was broken. Many thx, now I can eliminate getnvidia script from my quest.
The new results:
- with 5.4.53 kernel - compile error

cc1: some warnings being treated as errors
scripts/Makefile.build:265: recipe for target '/tmp/NVIDIA/kernel/nvidia/i2c_nvswitch.o' failed
make[2]: *** [/tmp/NVIDIA/kernel/nvidia/i2c_nvswitch.o] Error 1
make[2]: Target '__build' not remade because of errors.
Makefile:1706: recipe for target '/tmp/NVIDIA/kernel' failed
make[1]: *** [/tmp/NVIDIA/kernel] Error 2
make[1]: Target 'modules' not remade because of errors.
make[1]: Leaving directory '/usr/src/linux'
Makefile:80: recipe for target 'modules' failed
make: *** [modules] Error 2
ERROR: The nvidia kernel module was not created.
ERROR: Installation has failed.

I'm starting to blame the gcc version.

- with 5.4.5 I was able to bypass the kernel checking performed by getnvidia, and a driver was compiled and loaded, thankfully.
Everything was OK, bar the initial stumbling block, the jelly effect.
(jamesbond's tutorial is a very good one, it has a minor syntax mistake, but if you understand what it does, it's not a issue; and the driver should be loaded manually, xorgwizard nvidia blabla)

OK, moving forward anyway.

You can find a list of available drivers for GTX650 from nVidia site generated from this link
https://www.nvidia.com/Download/Find.aspx?lang=en-us

reason for edit: removed .png image and adjusted reply to reflect that

baraka wrote: Wed Jan 25, 2023 3:28 am

@mikeslr @shinobar
I wonder if someone has asked himself why I didn't use getnvidia in fossa, build the driver under 5.4.53.
Then switch the kernel in bionic with the 5.4.53 and, finally, load the previous obtained driver. (maybe that was the original mikeslr's question, before the second cup of coffee, and I didn't catch it)
Because it doesn't load.

Late to the discussion, but presumably when you're trying this way, you're exiting X, loading the nvidia driver with modprobe, and nouveau is not already loaded?

@dogcat
I've tried all of them and much more a few months ago , with every official 64bit puppy, same result and I might add this is true even in Palemoon.
At the time I gave up (force composition and that's it, with all the paraphernalia), but lately I found that fossa with 470.86 remove the bug.

Latest results: 5.15.34 (kernel made for bionic) - compile, install, load - but jelly.
5.4.5 - the same
I even compile de 5.4.53 linux kernel under bionic - same results - this is over the top for me, in 95% of my actions I didn't know what I've been doing.
I can't stop using bionic, I have all my stuff on it, plus fbbox (which doesn't work in fossa).

@bigpuppyfan
My mistake. The module IS loading. Xorg rejects the module.
This is a separate bug, bound to be a getnvidia problem. It happens only in bionic and is very easy to reproduce.
Any perfectly working driver sfs made and loaded with getnvidia; unload restart load restart and Xorg will stop using it.

Try uninstalling the getnvidia program. You already have the driver, so it's not really necessary. As long as nouveau is blacklisted, or not included in the puppy libraries, the nvidia driver should load automatically. That's how I have it in my puppy - never used the getnvidia (wouldn't work on PUPMODE 5 anyway, which is how I use puppy), just compiled the nvidia driver under the sandbox, included the output in the zdrv, and because I don't use this particular puppy in any other PC, removed the nouveau and radeon drivers to reduce the overall size (actually even removed a couple of nvidia very large libraries from that output, like optix, which I'm pretty sure would never come to use for me)

Should but it doesn't.
This is how the process stumble:

The NVIDIA driver is found, but the X-server is not currently using it. You need to restart X to enable the NVIDIA driver.

The module is loaded, the screen has the correct resolution, but I can't access Nvidia settings or when I start browsing is obvious that the driver is not active.
(I tried every option in xorgwizard, xorg.conf, I've no idea why this is happening, its not a nouveau issue)

The most interesting part is that I can't compile 470 driver in bionic if I replace the kernel with fossa's, sandbox or not.
And if I compile the driver in fossa, then the quoted error emerge in bionic (after kernel change, of course)

Do you happen to have a backup of your xorg.conf from before you installed getnvidia?
Also, which driver is currently being used? (you can find out with lsmod in terminal, or running the puppy welcome screen shortcut)?

If you don't have a copy of the previous xorg.conf, you could experiment running in ram mode only. You would need to add the nvidia driver/software to zdrv, for instance. For that, you would extract the zdrv sfs into a folder, add the nvidia stuff into it, right click the folder, dir2sfs and rename it back to the zdrv. When booting and getting the boot menu, you would select running without save file and click tab. Type the entry modprobe.blacklist=nouveau at the end. If this works, then at least we can try to pinpoint the problem more specifically

Also, when you're compiling on bionic with the fossa kernel, presumably you're using the devx from fossa as well?

@bigpuppyfan
Hi, it's not a xorg.conf issue or a nouveau one. In fact, the file is almost blank. (replace it with "a working" one - nothing)
lsmod shows loaded modules. Not what is in use. OK, nvidia is on the list, nouveau is not.
I tried both divx - same compile error.

Many thx for trying . I think is a bigger thinggy here. It's not the first time I tackle the problem. It took me almost 2 years before I searched for professional help.
Side note: I've been using puppy since 2010. nvidia was always a issue, apart for some periods not longer than 2 years, in which I would froze my configuration.

(funny result: if I use any 390 driver (is a recommended one), in any puppy64, and vdpau in smplayer (powered by any mplayer or mpv or mplayer2), the player will crash xorg so hard after no more than a couple of hours, that only hard physical reset will do, or plug out-in apart from that, the driver works flawlessly, except jelly e)

@baraka
There are a few 5.x kernels for bionic, with sources, generously provided and hosted by rockedge: https://rockedge.org/kernels/
eg: https://rockedge.org/kernels/data/Kerne ... 64.tar.bz2
https://rockedge.org/kernels/data/Kerne ... cpup64.sfs

And many more, several from ozsouth, here:
https://archive.org/download/Puppy_Linux_Kernels
(the link is not the same that was posted earlier in the thread - there are a few 5.4 bionicpup64 kernels, with sources files. Click show all on the right column of download options to see them)

Hopefully this will help overcome the problem you are facing

The OP is old, but I found a solution, or better said, an explanation.
I'll keep it very short.

1) Beware of the equation: vdpau + compton or picom = "very" non consistent results across all official puppies and various nvidia drivers.
Simple solution, deactivate any compositor (sometimes is on by default, verify Startup folder), and if you need one (to avoid jelly effect in browsers, for example), use "Force Composition" option supplied by nvidia driver (deactivate it when you use vdpau).

2) Never use "nouveau.modeset=0" as a kernel boot parameter (in menu.lst) IF getnvidia script is in play, let the script do the work. (this is an entirely different issue)

That's it. Thank you all.

@baraka :-

This sounds very like the issue I had when I first tried out FP64-9.5. PhilB and I between us figured it out.

Running my GT 710 with the 'nouveau' driver initially produced horrendous lag if, say, I tried to drag a window across the desktop.....you could actually see the window - several 'frames' behind, obviously - gradually redrawing itself closer & closer to where it needed to eventually be, in order to 'catch up'. I'd never seen owt like it!

Phil recommended using the 450.57 driver he'd packaged, built using the default kernel. I 'installed'/loaded it, re-booted, and it was nearly there. But not quite.

Phil said he'd had no end of trouble getting Compton & the 'nouveau' driver to 'play nice' together. That's why he eventually compiled the Nvidia driver, followed by disabling Compton entirely. It's not an issue that affects either AMD or Intel graphics.

So I disabled Compton (I've never seen the point of fancy window effects, anyway). Annnd.....Bingo. All sorted.

Window compositing just doesn't seem to work with Nvidia cards.

Mike.

@mikewalsh
Yes. A PhilB's post gave me the hint, I forgot it.

Vdpau and any compositor (including nvidia's) produce media playback with microstutter and/or an occasional crash.
Browsing without a compositor equals v-sync problems. Enabling v-sync in nvidia driver and playing with "--enable-gpu-vsync --disable-frame-rate-limit" launch options (in chrome based browsers) is a good idea but not a perfect one.

Picom and compton in effect can slow down dragging windows or create lag. The myriad options they have doesn't solve the issues that in part themselves create, or I didn't guess the right combination (many of them are obscure, one time solutions, with peculiar indications "may solve the...". And FbBox doesn't match well with either of them.

But I got my answer finally, 18 months later, and I'm very very happy.