SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Nvidia added libEGL in the new version of the driver, but only on 32bit. On 64bit you get a warning: something about it being unable to determine the architecture for conflict testing (I would have expected the 'lib64' to be a fairly blatant clue, but whatever...). The driver actually installs, but removes libEGL.la, while leaving mesa's libEGL.so still in-place. What I'm not sure about is whether the appropriate action is to put the .la file back, or to also remove the libEGL.so that belongs to mesa and was left behind. Thankfully, I don't think there's much that actually uses it as yet, so it's not an urgent issue. I expect NVIDIA will get their act together and fix it sooner or later (probably later ).
Yeah, I got that warning too with 331.20. But since the driver installed successfully, and I hadn't a clue what effect it would have, I decided to ignore it 'til something nasty happened. Nothing has...yet. Touch wood with fingers crossed.
Yeah, I got that warning too with 331.20. But since the driver installed successfully, and I hadn't a clue what effect it would have, I decided to ignore it 'til something nasty happened. Nothing has...yet. Touch wood with fingers crossed.
How long does it take for your shutdown from X? My machine used to take about 10 seconds to get to tty1, now it takes about 2 seconds. I'm running multi-lib, that might make a difference.
No noticeable difference from what it was with 14.0. I had multilib with 14.0, but haven't made my mind up yet: pure 64-bit or multilib, with 14.1.
P.S.
My graphics card is a GTS 450.
Yeah, I got that warning too with 331.20. But since the driver installed successfully, and I hadn't a clue what effect it would have, I decided to ignore it 'til something nasty happened. Nothing has...yet. Touch wood with fingers crossed.
I'd suggest to avoid 331.20 anyway because it masks out SIGINT by default for X applications (the previous 319.60 sets the default signal mask to block both SIGHUP and SIGINT).
The last working versions of the NVidia driver are 319.49 of the long life and 325.15 of the short life branch.
I'd suggest to avoid 331.20 anyway because it masks out SIGINT by default for X applications (the previous 319.60 sets the default signal mask to block both SIGHUP and SIGINT).
The last working versions of the NVidia driver are 319.49 of the long life and 325.15 of the short life branch.
Thanks, guanx. I'll get rid of 331.20 and install 319.49. I suppose I should reinstall mesa using slackpkg to restore that deleted file?
EDIT
Didn't need to reinstall mesa to get libEGL.la back. Installing 319.49 removed 331.20 and restored libEGL.la.
Big thanks to Pat and the crew. I installed 14.1 on my Lenovo R61 Thinkpad laptop the day it was released and everything just works. Beautiful perfection! The quickest and easiest install of Slackware I have done yet. Slackware Rocks!
I'd suggest to avoid 331.20 anyway because it masks out SIGINT by default for X applications (the previous 319.60 sets the default signal mask to block both SIGHUP and SIGINT).
The last working versions of the NVidia driver are 319.49 of the long life and 325.15 of the short life branch.
On my box pkill -HUP glxgears, pkill -SIGINT glxgears both seem to work as expected with 331.20, as do the traditional X11 apps I tried it on such as xclock. Also, ctrl-c in xterm seems to do exactly what it is expected to.
On my box pkill -HUP glxgears, pkill -SIGINT glxgears both seem to work as expected with 331.20, as do the traditional X11 apps I tried it on such as xclock. Also, ctrl-c in xterm seems to do exactly what it is expected to.
What is it you are seeing?
I see "screen" not detaching (SIGHUP blocked) and ^C doesn't work in shell (SIGINT blocked) sometimes. This is ~90% reproducible with 319.60 and 40% reproducible with 331.20 on my computer. Your machine may well be lucky to not trigger this bug. Check that the following program returns true --
Code:
#include <signal.h>
int main()
{
return siggetmask();
}
It always returns 0. Tried it both in my normal session, started by xdm, and with a simple xinit /usr/bin/xterm from runlevel 3.
I don't install kde so I can't test that or kdm.
So far so good. My T510 Thinkpad is running Slackware 14.1 like a champ. None of the problems it exhibited under 14.0 are showing up. It's nice to finally upgrade from 13.1!
thanks for slackware 14.1, upgraded yesterday (It took half a day - didnt expect that lol), all works well, no problem so far (but a tiny thing about my 8168 nic.. but i have the orginal 8168 driver so if i need it i can fix it, no worrys there ).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
).
