Alan,how did u build the nVidia driver via the install script?
Dean S. Messing wrote:
Alan wrote:
: Well, that depends on what you used and how you built it.
:
: I have been using the nVIDIA driver for a very long time. I build the
: driver via the install script. I do not use the
: Livna/FreshRPMS/whatever RPM kernel module. (I have tried. Will
: explain later.)
:
: If you build the nVIDIA driver and then update X components that use
: 3d acceleration, using an OpenGL program can crash your X server. It
: is not a kernel panic, but sure as hell looks like one. The solution
: is to rebuild the kernel driver (and replace the Mesa/3d code) every
: time X gets updated via Yum. (I also start in init level 3, but I am
: old...)
:
: I have also seen problems with lockups with older hardware and the
: legacy drivers using the Livna RPM on x86_64. (My laptop has a 440go
: chipset.) I solved this by going back to the "build by hand" method.
:
: The only time I have seen kernel panics with the nVIDIA drivers, it
: was not nVIDIA's fault. I had a dual core Athlon system that had
: undervoltage 4x AGP. If you had the motherboard set to 4x AGP, it
: would flake every once in a while. It did not matter if it was Linux
: or Windows either. (That ate up over a month of my life too. It was a
: royal pain to find the cause.)
:
: There is one valid point that has been brought up. If you do get
: kernel panics and the kernel developers and you mention that you are
: using the closed source drivers, they will use it as an excuse to deny
: coverage. (As well as vent hostility.) I can understand their point
: to an extent, but it is not helpful getting the problem solved.
: Unless you can show that the fault is in the driver, then it is just
: an excuse to get out of looking at the problem. (Kind of like the
: kind of answers you get if you call Stream's tech support.)
Thanks, Alan, for these clarifying points. My point was that lots of
people (who don't have "religious issues" with running binary drivers)
will help you if you choose to run them. In my case the author of the
driver helped me on a number of occasions when I had sticky situations
I needed to solve. He taught me how to control the type of scaling
and centering the driver does so I could get it to drive a 1366x768
panel my company makes which, at the time, even windows machines could
not drive at native resolution. He made valuable suggestions on how to
get it to frame-sync to the vertical blanking pulse so I could get
perfect frame synchronisation---a must for psychophysics experiments.
And he pointed me to the marvelous ReadMe that comes with the binary
driver. Many others on the lists have helped me too.
On the other hand you are certainly right, that the kernel maintainers
will turn a deaf ear to you if your kernel crashes and you are running
the binary driver. They are religious zealots. And frankly, in most
cases, I'm glad they are else the kernel would be a mess. But for
ordinary users to be pure OSS zealots is, to me, just silly. I'm not
about to throw out VMware or nVidia or scilab (which is OSS but not
GNU) or any of the other myriad subsystems I run for a non-issue like
"GNU purity".
Regarding the use of nVidia from livna, my limited experience (about a
year) has been that they are good at providing both the kernel and the
xorg modules and extensions. On my system I have
kmod-nvidia-100.14.19-1.2.6.23.8_34.fc7.x86_64
xorg-x11-drv-nvidia-100.14.19-3.lvn7.x86_64
The former has a Build Date of 6th December 2007, the latter 12th
October, so it seems livna keep up well. You mention legacy hardware.
My hardware is not too "legacy" so that may be what the difference is.
Or it may be that I don't do any 3D work, which may tickle the
problems you had.
Anyway, apologies if I have misunderstood your reasons for not using a
pre-compiled rpm. For me they "just work".
Dean
