Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 6, 2009 at 6:59 PM, lee <lee@yun.yagibdah.de> wrote:
>
> And nvidia-kernel-common:
>
>
> "This package contains files shared between NVIDIA module packages."
Common refers essentially to support files., You should install the
package, but it's not dependent on the driver or the version of the
kernel.
> nvidia-kernel-source:
>
>
> "This package builds the NVIDIA Xorg binary kernel module needed by
> nvidia-glx."
For whatever kernel you have. It's tied to the specific release of the
driver version, whatever that may be from testing/unstable. Since it
is source, after you do a module-assistant auto-install, it'll compile
that driver for the kernel you have. Since you have a non-standard
kernel, there might be problems, but then again there may not be.
> I don't know about vdpaul --- is that included in the nvidia
> installer?
vdpau is something that's special to some higher-end nvidia cards. You
may not need that, depending on what card you have.
The link here [1] itemizes supported cards.
> Why are the package descriptions so poor, and why can't there just be
> one package you install?
It would be nice, but essentially you need three components,
nvidia-glx, nvidia-common and nvidia-kernel-source. The first and
third have to match as far as the driver revision, otherwise you get
nasty messages from X. One of these should autoinstall nvidia-common
since it may be dependent on the other two. But it's been sometime
since I messed with nvidia (now using on board Intel graphics).
> Since my card isn't even supported in testing, I'd have to get those
> packages from unstable. I've tried using packages from unstable a
> couple times, but the results haven't been good.
Using pinning and judicious use of aptitude install <package> -t
unstable when only necessary should make things easier. There have
been occasions when I needed the nvidia driver from (then) unstable.
This was over a year ago when I was using an nvidia card on an old 32
bit system. Once it worked like a charm, the other time I found that
the driver update had (wrongly) decided to include support for
instructions that my processor did not support (movaps/movups). Turns
out that the driver was compiled this way, and the only recourse to
get it to work was to downgrade the package to the prior version.
Since I now have an amd64 I can put such frustration behind me, but
it's bitten me before several times. (My prior cpu was an Athlon
Tbird/1000 which had some support for mmx/3dnow, but assumptions were
made occasionally that said basically any modern 386 based system
would support these instructions, and support for them only arrived in
later versions of the AMD platform.)
And it was with some other distributions at well.
--
thanks for letting me change the magnetic patterns on your hard disk.
Reply to: