I've used the livna repo before for nVidia driver downloads. But since installing Fedora 7, I've been having problems. Once I've done a yum install kmod-nvidia I do an xorg.conf update and run X, but I keep getting the message:
FATAL: Module nvidia not found. (EE) NVIDIA(0): Failed to load the NVIDIA kernel module! (EE) NVIDIA(0): *** Aborting ***
HELP! (please)
Am Freitag, den 22.06.2007, 22:00 +0200 schrieb warrick:
You might have a Nvidia GF440 or something like that?
Please use the nvidia-legacy driver. Nvidia decided to remove support for older cards from newer drivers.
On Fri, Jun 22, 2007 at 10:02:54PM +0200, Stefan Held wrote:
Am Freitag, den 22.06.2007, 22:00 +0200 schrieb warrick:
You might have a Nvidia GF440 or something like that?
Please use the nvidia-legacy driver. Nvidia decided to remove support for older cards from newer drivers.
Ubuntu can detect the nvidia card and select the correct driver correctly, but apparently Livna can't or won't. Short of that, I have a script that should at least tell you which driver to use. There are notes in the script on where to get the core information.
http://www.charlescurley.com/which.nvidia.html
On Fri, 2007-06-22 at 15:11 -0600, Charles Curley wrote:
Ubuntu can detect the nvidia card and select the correct driver correctly, but apparently Livna can't or won't. Short of that, I have a script that should at least tell you which driver to use. There are notes in the script on where to get the core information.
Didn't work with one of my cards. Notice the blank space below:
[root@serge ~]# ./which-nvidia Which NVIDIA, Time-stamp: <2007-06-20 10:59:08 ccurley which-nvidia.pl> Your NVIDIA card at 01:00.0 is a , which requires the driver. 1 NVIDIA cards were found. Download from http://www.nvidia.com/object/unix.html Or "yum list *nvidia*" and install as appropriate.
Is there anything I can provide that helps you add it to its detection?
[root@serge ~]# lspci 00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 11) 00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge (rev 11) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 05) 00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 05) 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 05) 00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 05) 00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 05) 00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 05) 00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio (rev 05) 01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15) 02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
On Fri, 2007-06-22 at 22:02 +0200, Stefan Held wrote:
Please use the nvidia-legacy driver. Nvidia decided to remove support for older cards from newer drivers.
I seemed to have that problem, despite having a GeForce4 card that was supposedly covered by the non-legacy driver. Though I've read conflicting information about that.
Is the legacy driver also supposed to support 3D acceleration? I got nowhere trying it.
On 6/22/07, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2007-06-22 at 22:02 +0200, Stefan Held wrote:
Please use the nvidia-legacy driver. Nvidia decided to remove support for older cards from newer drivers.
I seemed to have that problem, despite having a GeForce4 card that was supposedly covered by the non-legacy driver. Though I've read conflicting information about that.
Is the legacy driver also supposed to support 3D acceleration? I got nowhere trying it.
All nvidia drivers have acclerated 3D support. I'm not sure what you read, but the driver README is quite clear in what is supported.
Tim:
I seemed to have that problem, despite having a GeForce4 card that was supposedly covered by the non-legacy driver. Though I've read conflicting information about that.
Is the legacy driver also supposed to support 3D acceleration? I got nowhere trying it.
Lonni J Friedman:
All nvidia drivers have acclerated 3D support.
Good to know.
I'm not sure what you read, but the driver README is quite clear in what is supported.
The conflicting information was about whether to use legacy, or not, for the card I was using. I'd looked up card names and chipset names, and found it listed in two conflicting places. That was on the nvidia website, by the way.
'tis an Asus V8420/128M Rev 101 NVidia NV25 GeForce4 Ti 4200 rev a3 card. If anyone knows how to make it work with FC7, I'd like to hear about it. We had it working fine on FC5, long ago.
Additionally, information on making it run the monitor at the rates that I know it can run at, rather than Xorg thinks it can manage, are welcome (Compaq V75). I get variable results at configuring resolutions.
Compaq V75 monitor (according to the HP site) ------------------ Scanning frequencies: Horizontal scan range 30-70 KHz Vertical scan range 50-160 Hz
Maximum resolution (H x V): 1280 x 1024 @ 60 Hz
Recommended resolution (H x V): 1024 x 768 @ 85 Hz
It does work well at the maximum resolution, when X will let it.
'tis an Asus V8420/128M Rev 101 NVidia NV25 GeForce4 Ti 4200 rev a3 card. If anyone knows how to make it work with FC7, I'd like to hear about it. We had it working fine on FC5, long ago.
Additionally, information on making it run the monitor at the rates that I know it can run at, rather than Xorg thinks it can manage, are welcome (Compaq V75). I get variable results at configuring resolutions.
One minor complication theses days is there is effectively 2 legacy drivers. A 1.0-96xx driver that supports old cards, and a 1.0-71xx driver that supports really old cards...
The livna readme
http://us.download.nvidia.com/XFree86/Linux-x86/100.14.11/README/appendix-a....
Quite clearly shows that your card should be support by the 1.0-96xx driver.
I would recommend getting your driver from the livna (or atrpms, or freshrpms. I use livna personally) repo and not installing by hand via the official nvidia installer, as the rpms are more 'fedora-aware'. This can be done with
yum install kmod-nvidia-96xx
( kmod-nvidia-96xx-PAE if you have the PAE kernel etc.)
While you are at it, I would also grab the package yum-fedorakmod. When a new kernel is released there is, naturally, a short delay between the release and the various third party repos making the kernel modules for the new kernel available. If you where to upgrade during this period you would end up with a system with no X... This package fixes this by making yum hold back any kernel updates until all the kmods you have installed are also available.
I had a similar problem with the refresh rates as you seem to have. I found that whilst the nv driver found all the modes my screen can support just fine, the nvidia driver (I have to use the 1.0-71xx driver since my card is quite elderly) did not. The problem for me was the driver was not getting the horizontal and vert frequencies correctly, and default to very safe values... This can be easily fixed by supply your own. Add a section like
Section "Monitor" Identifier "Monitor0" HorizSync 30.0 - 130.0 VertRefresh 50.0 - 200.0 EndSection
where the freqs are what your screen can support. Make sure your Screen section also has
Monitor "Monitor0"
For me, that fixed the problem.
cheers Chris
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
The livna readme
That would be the NVIDIA driver README. Livna has absolutely nothing to do with it.
http://us.download.nvidia.com/XFree86/Linux-x86/100.14.11/README/appendix-a....
I had a similar problem with the refresh rates as you seem to have. I found that whilst the nv driver found all the modes my screen can support just fine, the nvidia driver (I have to use the 1.0-71xx driver since my card is quite elderly) did not. The problem for me was the driver was not getting the horizontal and vert frequencies correctly, and default to very safe values... This can be easily fixed by supply your own. Add a section like
This is inaccurate. The driver always tries to obtain the correct information from the EDID in your display device. Now if your display device has no EDID, or the EDID is broken in some way, then the driver is going to fall back to safe defaults, which can still be overridden.
This is inaccurate. The driver always tries to obtain the correct information from the EDID in your display device. Now if your display device has no EDID, or the EDID is broken in some way, then the driver is going to fall back to safe defaults, which can still be overridden.
How come then the nv found them find but the nvidia driver didn't ?
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
This is inaccurate. The driver always tries to obtain the correct information from the EDID in your display device. Now if your display device has no EDID, or the EDID is broken in some way, then the driver is going to fall back to safe defaults, which can still be overridden.
How come then the nv found them find but the nvidia driver didn't ?
I wouldn't know unless you post the X logs from each driver. My best guess is that the nv driver just falls back to different defaults than the nvidia driver.
I wouldn't know unless you post the X logs from each driver. My best guess is that the nv driver just falls back to different defaults than the nvidia driver.
The logs are now here
http://www.hep.phy.cam.ac.uk/~jonesc/Xorg.log.nv http://www.hep.phy.cam.ac.uk/~jonesc/Xorg.log.nvidia
for the nv and nvidia drivers respectively.
I'm no expert, so will defer to your expert opinion, but it seems to me that nv correctly identifies my monitor,
(II) NV(0): Monitor name: HM903D/DT
( which is a vision master pro 454, 19in)
and goes on to list the correct modes. 1600x1200, which is the mode I want is properly found and configured to run at 85Hz.
On the contary, the nvidia driver does no seem to do so well. and seems to decide my screen is only 800x600 and that most modes are out of freq range.
cheers Chris
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
I wouldn't know unless you post the X logs from each driver. My best guess is that the nv driver just falls back to different defaults than the nvidia driver.
The logs are now here
http://www.hep.phy.cam.ac.uk/~jonesc/Xorg.log.nv http://www.hep.phy.cam.ac.uk/~jonesc/Xorg.log.nvidia
for the nv and nvidia drivers respectively.
Those logs don't appear to have been generated under the same conditions. You've got a verbose 'nv' driver log, and a non-verbose nvidia driver log. However, it looks fairly obvious that the nvidia driver failed to validate most of your modes because your vrefresh or hsync values were out of the range required by the EDID of your display.
I'm no expert, so will defer to your expert opinion, but it seems to me that nv correctly identifies my monitor,
(II) NV(0): Monitor name: HM903D/DT
( which is a vision master pro 454, 19in)
and goes on to list the correct modes. 1600x1200, which is the mode I want is properly found and configured to run at 85Hz.
On the contary, the nvidia driver does no seem to do so well. and seems to decide my screen is only 800x600 and that most modes are out of freq range.
Right. If you'd like further assistance, please start X with the following command (for the nvidia driver): startx -- -logverbose 6
and then generate and provide an nvidia-bug-report.log.
Hi,
Those logs don't appear to have been generated under the same conditions. You've got a verbose 'nv' driver log, and a non-verbose nvidia driver log.
Not intentional. All I did was update xorg.conf to switch back from the nvidia driver to the nv one (and comment out the lines explicity setting the vert/hori freqs).
Right. If you'd like further assistance, please start X with the following command (for the nvidia driver): startx -- -logverbose 6
and then generate and provide an nvidia-bug-report.log.
Available here
http://www.hep.phy.cam.ac.uk/~jonesc/nvidia-bug-report.log
Note I'm quite happy just setting the freqs. by hand in my xorg.conf file, so no real problem here, but it would be interesting to know for sure where the error lies.
cheers Chris
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
Hi,
Those logs don't appear to have been generated under the same conditions. You've got a verbose 'nv' driver log, and a non-verbose nvidia driver log.
Not intentional. All I did was update xorg.conf to switch back from the nvidia driver to the nv one (and comment out the lines explicity setting the vert/hori freqs).
Right. If you'd like further assistance, please start X with the following command (for the nvidia driver): startx -- -logverbose 6
and then generate and provide an nvidia-bug-report.log.
Available here
http://www.hep.phy.cam.ac.uk/~jonesc/nvidia-bug-report.log
Note I'm quite happy just setting the freqs. by hand in my xorg.conf file, so no real problem here, but it would be interesting to know for sure where the error lies.
Thanks. There are a few problems here. First the EDID violates the specification standard: (II) NVIDIA(0): First detailed timing not preferred mode in violation of standard!
The the first detailed timing listed in the EDID should always be the preferred native mode. Your CRT is not doing that.
You've commented out the entire Monitor section, so the driver is going back to internal defaults for hsync & vrefresh, which gives you: (II) NVIDIA(0): <default monitor>: Using default hsync range of 31.50-37.90 kHz
However, the EDID for your display specifies that 1600x1200 needs an 85Hz refresh rate. However, this means that you need a 107.1Khz hsync: (II) NVIDIA(0): #0: hsize: 1600 vsize 1200 refresh: 85 vid: 22953
Since the internal defaults only go as high as 37.90, the mode fails to validate: (II) NVIDIA(0): Not using default mode "1600x1200" (hsync out of range)
So basically, if you uncomment the Monitor section, and specify much broader ranges, you'll likely fix the problem.
Hi,
Thanks for your feedback.
Thanks. There are a few problems here. First the EDID violates the specification standard: (II) NVIDIA(0): First detailed timing not preferred mode in violation of standard!
The the first detailed timing listed in the EDID should always be the preferred native mode. Your CRT is not doing that.
Ah. Ok.
You've commented out the entire Monitor section, so the driver is going back to internal defaults for hsync & vrefresh, which gives you: (II) NVIDIA(0): <default monitor>: Using default hsync range of 31.50-37.90 kHz
Actually, after I first installed F7 on this box, which gave me the nv driver. The xorg.conf file was minimal and did not have a Monitor section at all. When I then installed the nvidia driver (via livna) a monitor section was not added. I had to add a section myself together with a better set of freq. values in order to get the higher resolutions running.
I thought, for this test I would go back to what I had before I fixed the problem, to show you the original error.
However, the EDID for your display specifies that 1600x1200 needs an 85Hz refresh rate. However, this means that you need a 107.1Khz hsync: (II) NVIDIA(0): #0: hsize: 1600 vsize 1200 refresh: 85 vid: 22953
Since the internal defaults only go as high as 37.90, the mode fails to validate: (II) NVIDIA(0): Not using default mode "1600x1200" (hsync out of range)
So basically, if you uncomment the Monitor section, and specify much broader ranges, you'll likely fix the problem.
Thanks. I had already figured out that the problem was the freq. ranges where too narrow when using the nvidia driver, and I had to suply them by hand. That works just fine.
What I didn't know was why the nv driver was getting them and the nvidia driver did not. I'm still not really clear on this point. You say my monitor is not giving a correct EDID - Just for interest does this mean that the nv driver is better at 'working around' these problems - It seems to be getting them correctly ? Or is it just that the nvidia driver is stricter when it comes to the EDID standard and when it finds a problem defaults to safe default values ? Just wondering ...
cheers Chris
On 6/24/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
Hi,
Thanks for your feedback.
Thanks. There are a few problems here. First the EDID violates the specification standard: (II) NVIDIA(0): First detailed timing not preferred mode in violation of standard!
The the first detailed timing listed in the EDID should always be the preferred native mode. Your CRT is not doing that.
Ah. Ok.
You've commented out the entire Monitor section, so the driver is going back to internal defaults for hsync & vrefresh, which gives you: (II) NVIDIA(0): <default monitor>: Using default hsync range of 31.50-37.90 kHz
Actually, after I first installed F7 on this box, which gave me the nv driver. The xorg.conf file was minimal and did not have a Monitor section at all. When I then installed the nvidia driver (via livna) a monitor section was not added. I had to add a section myself together with a better set of freq. values in order to get the higher resolutions running.
I thought, for this test I would go back to what I had before I fixed the problem, to show you the original error.
However, the EDID for your display specifies that 1600x1200 needs an 85Hz refresh rate. However, this means that you need a 107.1Khz hsync: (II) NVIDIA(0): #0: hsize: 1600 vsize 1200 refresh: 85 vid: 22953
Since the internal defaults only go as high as 37.90, the mode fails to validate: (II) NVIDIA(0): Not using default mode "1600x1200" (hsync out of range)
So basically, if you uncomment the Monitor section, and specify much broader ranges, you'll likely fix the problem.
Thanks. I had already figured out that the problem was the freq. ranges where too narrow when using the nvidia driver, and I had to suply them by hand. That works just fine.
What I didn't know was why the nv driver was getting them and the nvidia driver did not. I'm still not really clear on this point. You say my monitor is not giving a correct EDID - Just for interest does this mean that the nv driver is better at 'working around' these problems - It seems to be getting them correctly ? Or is it just that the nvidia driver is stricter when it comes to the EDID standard and when it finds a problem defaults to safe default values ? Just wondering ...
The nvidia driver is stricter in its enforcement of a valid EDID.
Chris Jones:
I had a similar problem with the refresh rates as you seem to have. I found that whilst the nv driver found all the modes my screen can support just fine, the nvidia driver (I have to use the 1.0-71xx driver since my card is quite elderly) did not. The problem for me was the driver was not getting the horizontal and vert frequencies correctly, and default to very safe values... This can be easily fixed by supply your own. Add a section like
Lonni J Friedman:
This is inaccurate. The driver always tries to obtain the correct information from the EDID in your display device. Now if your display device has no EDID, or the EDID is broken in some way, then the driver is going to fall back to safe defaults, which can still be overridden.
There has to be more to it than just the monitor, as other things (prior releases) managed to work out how they should be using the monitor without a fight. But this combination didn't work well.
On 6/23/07, Tim ignored_mailbox@yahoo.com.au wrote:
Chris Jones:
I had a similar problem with the refresh rates as you seem to have. I found that whilst the nv driver found all the modes my screen can support just fine, the nvidia driver (I have to use the 1.0-71xx driver since my card is quite elderly) did not. The problem for me was the driver was not getting the horizontal and vert frequencies correctly, and default to very safe values... This can be easily fixed by supply your own. Add a section like
Lonni J Friedman:
This is inaccurate. The driver always tries to obtain the correct information from the EDID in your display device. Now if your display device has no EDID, or the EDID is broken in some way, then the driver is going to fall back to safe defaults, which can still be overridden.
There has to be more to it than just the monitor, as other things (prior releases) managed to work out how they should be using the monitor without a fight. But this combination didn't work well.
No, there really isn't more to it than just that. Unless you can provide an nvidia-bug-report.log which captures this problem, there really isn't any more to discuss here, as I'm quite confident in my understanding of how the driver validates modes, and you haven't provided much other than scant details about a problem.
On Sat, 2007-06-23 at 10:11 +0100, Chris Jones wrote:
One minor complication theses days is there is effectively 2 legacy drivers. A 1.0-96xx driver that supports old cards, and a 1.0-71xx driver that supports really old cards...
The livna readme
http://us.download.nvidia.com/XFree86/Linux-x86/100.14.11/README/appendix-a....
Quite clearly shows that your card should be support by the 1.0-96xx driver.
Clearly a URI that just jumps out at you as being the place too look... But being serious, I did google around with the information on my card, got one thing that suggested the plain-legacy-named file, another that didn't. Would it be too hard for Nvidia to have just one driver package, or at least an analysis package that could get the one that you need? It's the computer, not me.
Anyway, feeling adventurous, I had another bash at it. And this time, with that driver, it's working. The monitor's even selected with the right resolutions! I've given it a little stress test, and I haven't made it blow up, yet.
While you are at it, I would also grab the package yum-fedorakmod. When a new kernel is released there is, naturally, a short delay between the release and the various third party repos making the kernel modules for the new kernel available. If you where to upgrade during this period you would end up with a system with no X...
Which is another of those situations where that other business of uninstalling nvidia, to use something else while you wait, then re-installing, would be annoying.
This package fixes this by making yum hold back any kernel updates until all the kmods you have installed are also available.
Yes, I'll have a look at that too. I downloaded it, but haven't done anything more than an rpm -qi on it, so far. That wasn't clear whether it'd delay the installion of one thing or the other until all the needed parts had arrived. I would think it'd have to work both ways.
On 6/23/07, Tim ignored_mailbox@yahoo.com.au wrote:
Tim:
I seemed to have that problem, despite having a GeForce4 card that was supposedly covered by the non-legacy driver. Though I've read conflicting information about that.
Is the legacy driver also supposed to support 3D acceleration? I got nowhere trying it.
Lonni J Friedman:
All nvidia drivers have acclerated 3D support.
Good to know.
I'm not sure what you read, but the driver README is quite clear in what is supported.
The conflicting information was about whether to use legacy, or not, for the card I was using. I'd looked up card names and chipset names, and found it listed in two conflicting places. That was on the nvidia website, by the way.
'tis an Asus V8420/128M Rev 101 NVidia NV25 GeForce4 Ti 4200 rev a3 card. If anyone knows how to make it work with FC7, I'd like to hear about it. We had it working fine on FC5, long ago.
The process for installing the driver has not changed in years. Your NV25 is fully supported in the 1.0-9639 legacy driver.
On Friday 22 June 2007, warrick wrote:
I've used the livna repo before for nVidia driver downloads. But since installing Fedora 7, I've been having problems. Once I've done a yum install kmod-nvidia I do an xorg.conf update and run X, but I keep getting the message:
FATAL: Module nvidia not found. (EE) NVIDIA(0): Failed to load the NVIDIA kernel module! (EE) NVIDIA(0): *** Aborting ***
HELP! (please)
I guess this is what makes me feel lucky. I do not use the livna nvidia drivers, primarily because they don't keep up with the kernel version if you build your own, which I do.
So I check the nvidia site everytime I happen to think about it and download their latest *.run installer. So I can build a new kernel, reboot to my normal runlevel 3 login, then "sh ./N[tab][enter]" (if one of them is all there is in /root) answer a few ncurses yes/no's, and its installed. Yeah, its a pita & takes about 2 minutes. But guess what folks, it Just Works(TM)
On Fri, 2007-06-22 at 18:12 -0400, Gene Heskett wrote:
I guess this is what makes me feel lucky. I do not use the livna nvidia drivers, primarily because they don't keep up with the kernel version if you build your own, which I do.
So I check the nvidia site everytime I happen to think about it and download their latest *.run installer. So I can build a new kernel, reboot to my normal runlevel 3 login, then "sh ./N[tab][enter]" (if one of them is all there is in /root) answer a few ncurses yes/no's, and its installed. Yeah, its a pita & takes about 2 minutes. But guess what folks, it Just Works(TM)
But have NVidia stopped doing that thing where they mucked up other aspects of Xorg to suit themselves? That stung me badly when I had to pull out a NVidia card to try another one, and Xorg was buggered.
On 6/22/07, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2007-06-22 at 18:12 -0400, Gene Heskett wrote:
I guess this is what makes me feel lucky. I do not use the livna nvidia drivers, primarily because they don't keep up with the kernel version if you build your own, which I do.
So I check the nvidia site everytime I happen to think about it and download their latest *.run installer. So I can build a new kernel, reboot to my normal runlevel 3 login, then "sh ./N[tab][enter]" (if one of them is all there is in /root) answer a few ncurses yes/no's, and its installed. Yeah, its a pita & takes about 2 minutes. But guess what folks, it Just Works(TM)
But have NVidia stopped doing that thing where they mucked up other aspects of Xorg to suit themselves? That stung me badly when I had to pull out a NVidia card to try another one, and Xorg was buggered.
???
On Saturday 23 June 2007, Tim wrote:
On Fri, 2007-06-22 at 18:12 -0400, Gene Heskett wrote:
I guess this is what makes me feel lucky. I do not use the livna nvidia drivers, primarily because they don't keep up with the kernel version if you build your own, which I do.
So I check the nvidia site everytime I happen to think about it and download their latest *.run installer. So I can build a new kernel, reboot to my normal runlevel 3 login, then "sh ./N[tab][enter]" (if one of them is all there is in /root) answer a few ncurses yes/no's, and its installed. Yeah, its a pita & takes about 2 minutes. But guess what folks, it Just Works(TM)
But have NVidia stopped doing that thing where they mucked up other aspects of Xorg to suit themselves? That stung me badly when I had to pull out a NVidia card to try another one, and Xorg was buggered.
I don't believe so. During the install it would appear it puts its own OpenGL stuffs in, and runs ldconfig to fix the links. If that is what it takes to make it work, shrug. Since Intel isn't making aftermarket cards, and unless a bolt of lightning comes down to educate ati my next card will also be an nvidia, and nothing will be changed, I'll still have to re-install after every new boot to a new kernel unless the nauveau(sp?) driver is ready to run... I would offer to test it, but the url seems to be on the missing list. Of course I'd need a new round tuit also :)
Tim:
But have NVidia stopped doing that thing where they mucked up other aspects of Xorg to suit themselves? That stung me badly when I had to pull out a NVidia card to try another one, and Xorg was buggered.
Gene Heskett:
I don't believe so. During the install it would appear it puts its own OpenGL stuffs in, and runs ldconfig to fix the links. If that is what it takes to make it work, shrug.
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
Since Intel isn't making aftermarket cards, and unless a bolt of lightning comes down to educate ati my next card will also be an nvidia, and nothing will be changed, I'll still have to re-install after every new boot to a new kernel unless the nauveau(sp?) driver is ready to run... I would offer to test it, but the url seems to be on the missing list. Of course I'd need a new round tuit also :)
</aol> Me too...
It seems we have just about three choices for accelerated video. Motherboard Intel, some ATI, or some NVidia chipset cards.
Looking through the various X man pages, some other drivers to purport to support 3D, like some of the S3 range. But, of course, not *MY* S3 chipset. :-\ And, I don't know how *well* it was supported. It was rather crummy even with its original Windows setup...
I've a two motherboards with i810 chipsets, and no AGP slots. There's something that suggests some acceleration can be done with them, but I didn't get anywhere with it.
Just as well I'm not particularly keen on being able to play games. But I wouldn't mind having a try, or playing with some fancy screensavers.
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
This is the worst thing about the official nivida installer, and why I will never use it.
The livna rpms work around this and install the nvidia opengl libs in such a way that it doesn't conflict with the default ones, but exist side by side.
At a later date you can just remove the rpm and end up back where you start, with a work nv driver.
Chris
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
This is the worst thing about the official nivida installer, and why I will never use it.
Running: nvidia-installer --uninstall puts everything back to the way it was prior to installing the nvidia driver. You're also welcome to continue believing and/or spreading the misinformation of others.
The livna rpms work around this and install the nvidia opengl libs in such a way that it doesn't conflict with the default ones, but exist side by side.
That isnt' accurate. They still conflict. You can't use both sets of libGL libraries simultaneously. What is your need for having both sets when you'd only want to use NVIDIA's libGL?
At a later date you can just remove the rpm and end up back where you start, with a work nv driver.
Or run the command that I provided above.
On Saturday 23 June 2007 3:16:08 pm Lonni J Friedman wrote:
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
This is the worst thing about the official nivida installer, and why I will never use it.
Running: nvidia-installer --uninstall puts everything back to the way it was prior to installing the nvidia driver. You're also welcome to continue believing and/or spreading the misinformation of others.
Last time I tried that it didn't work properly. I admit it was about 6 months ago but I have no intention of trying it again seeing as the livna rpms work fine. If it does work now I apologize (but will continue to prefer an rpm)
The livna rpms work around this and install the nvidia opengl libs in such a way that it doesn't conflict with the default ones, but exist side by side.
That isnt' accurate. They still conflict. You can't use both sets of libGL libraries simultaneously. What is your need for having both sets when you'd only want to use NVIDIA's libGL?
Sorry, I was not clear. What I should have said was the livna rpms installs some startup scripts that automatically enable the nvidia driver during boot up. If it finds, for a given kernel it is not available it puts everything back so the nv driver works OK.
In this way you can have some kernels using the nv driver and others using the nvidia one, if you want, and you can boot between them as you want, without having to edit xorg.conf or mess around removing and adding back the nvidia driver.
If you use the official installer you cannot do this, you can only switch from the nv to the nvidia driver and back again by manually adding or removing the driver. I agree this is not a common use case, but I have occasionally wanted to do this for one reason or another.
Also, by installing the livna rpm I automatically get a new kernel module each time a kernel update comes around - No mucking around installing by hand. This is very convenient.
Please do get me wrong, I don't really have anything against the installer per se, and I'm very grateful for what nvidia is doing for linux support. Its just that for obvious reasons the official nvidia installer is somewhat distro-neutral, and a properly packaged rpm or whatever, for a given distro, is also going to me more convenient. Just my opinion.
Chris
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
On Saturday 23 June 2007 3:16:08 pm Lonni J Friedman wrote:
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
This is the worst thing about the official nivida installer, and why I will never use it.
Running: nvidia-installer --uninstall puts everything back to the way it was prior to installing the nvidia driver. You're also welcome to continue believing and/or spreading the misinformation of others.
Last time I tried that it didn't work properly. I admit it was about 6 months ago but I have no intention of trying it again seeing as the livna rpms work fine. If it does work now I apologize (but will continue to prefer an rpm)
If it didn't work properly that's a bug that should (have been) reported to NVIDIA.
The livna rpms work around this and install the nvidia opengl libs in such a way that it doesn't conflict with the default ones, but exist side by side.
That isnt' accurate. They still conflict. You can't use both sets of libGL libraries simultaneously. What is your need for having both sets when you'd only want to use NVIDIA's libGL?
Sorry, I was not clear. What I should have said was the livna rpms installs some startup scripts that automatically enable the nvidia driver during boot up. If it finds, for a given kernel it is not available it puts everything back so the nv driver works OK.
I guess I don't understand why that's preferably behavior. If you don't have the nvidia driver installed at boot time, then you're going to end up with poor performance regardless. And I've seen many reports of people who ended up with their system falling back to the 'nv' driver, they were unaware of it, and complained about poor performance. So the sword cuts both ways. Its only good if you understand what's happening, and in that case, wouldn't it be better to just install the nvidia driver?
In this way you can have some kernels using the nv driver and others using the nvidia one, if you want, and you can boot between them as you want, without having to edit xorg.conf or mess around removing and adding back the nvidia driver.
If you use the official installer you cannot do this, you can only switch from the nv to the nvidia driver and back again by manually adding or removing the driver. I agree this is not a common use case, but I have occasionally wanted to do this for one reason or another.
Also, by installing the livna rpm I automatically get a new kernel module each time a kernel update comes around - No mucking around installing by hand. This is very convenient.
I suppose, but I don't see what's so hard about installing the driver. Its not like its difficult or even time consuming.
Please do get me wrong, I don't really have anything against the installer per se, and I'm very grateful for what nvidia is doing for linux support. Its just that for obvious reasons the official nvidia installer is somewhat distro-neutral, and a properly packaged rpm or whatever, for a given distro, is also going to me more convenient. Just my opinion.
That's fine. I appreciate your feedback.
I guess I don't understand why that's preferably behavior. If you don't have the nvidia driver installed at boot time, then you're going to end up with poor performance regardless. And I've seen many reports of people who ended up with their system falling back to the 'nv' driver, they were unaware of it, and complained about poor performance. So the sword cuts both ways. Its only good if you understand what's happening, and in that case, wouldn't it be better to just install the nvidia driver?
Well, in my opinion Its preferable in the case when a new kernel (or X release) comes out that isn't supported by nvidia at that time. This has happen before. In this case it is a choice between booting into a system where X is borked, or X is working abeit without 3D. I know which I would prefer.
I suppose, but I don't see what's so hard about installing the driver. Its not like its difficult or even time consuming.
its not hard, but takes more than zero, zip effort. Which is what it is once you have setup your system to use livna and the rpm from there (+ the yum plugin to only upgrade kernels when all kmods you use are available).
In this case you automatically benefit from the same upgrade system as used by the rest of your fedora system. If a new kernel comes out you automatically get the kernel module installed, at the same time as the kernel. So it is there for the next reboot (no having to boot to the new kernel, start at init 3 build and install the module then restart to init 5).
You also benefit from automatically getting new nvidia drivers when they come out, since they will just appear as a normal livna update. With the official installer you have to keep an eye out yourself for updates. I prefer to let my system do it for me and worry about more important things myself...
cheers Chris
On 6/23/07, Chris Jones jonesc@hep.phy.cam.ac.uk wrote:
I guess I don't understand why that's preferably behavior. If you don't have the nvidia driver installed at boot time, then you're going to end up with poor performance regardless. And I've seen many reports of people who ended up with their system falling back to the 'nv' driver, they were unaware of it, and complained about poor performance. So the sword cuts both ways. Its only good if you understand what's happening, and in that case, wouldn't it be better to just install the nvidia driver?
Well, in my opinion Its preferable in the case when a new kernel (or X release) comes out that isn't supported by nvidia at that time. This has happen before. In this case it is a choice between booting into a system where X is borked, or X is working abeit without 3D. I know which I would prefer.
I'm not aware of any cases where the nvidia driver didn't work with a released Fedora kernel (other than the original FC6 kernel which didn't support non-GPL'd modules). Perhaps you're referring to Livna lacking the package, but that's a Livna problem.
On Sat, 2007-06-23 at 07:46 -0700, Lonni J Friedman wrote:
I suppose, but I don't see what's so hard about installing the driver. Its not like its difficult or even time consuming.
Can be for someone who's not *that* technically savvy, or not on a network at the time they need it.
But *why* even have to do that? I can swap sound cards, and the system sorts itself out. I don't have to remove this and replace that in software, as well. Likewise for network cards, and other things. What's so special about nvidia that it wants to behave like Windows?
On 6/23/07, Tim ignored_mailbox@yahoo.com.au wrote:
On Sat, 2007-06-23 at 07:46 -0700, Lonni J Friedman wrote:
I suppose, but I don't see what's so hard about installing the driver. Its not like its difficult or even time consuming.
Can be for someone who's not *that* technically savvy, or not on a network at the time they need it.
If you're not on a network, yum isn't going to help you either. As for being technically savy, I'd argue that using yum requires alot more technical aptitude than just running "./NVIDIA-Linux-x86-100.14.11-pkg1.run" as root.
But *why* even have to do that? I can swap sound cards, and the system sorts itself out. I don't have to remove this and replace that in software, as well. Likewise for network cards, and other things. What's so special about nvidia that it wants to behave like Windows?
It doesn't ship with the distribution. Any time you start using any driver which doesn't ship with the distribution, the path to success will be different. And there are plenty of GPL'd drivers which don't ship with the official kernel, so this isn't an issue specific to NVIDIA.
If you're not on a network, yum isn't going to help you either. As for being technically savy, I'd argue that using yum requires alot more technical aptitude than just running "./NVIDIA-Linux-x86-100.14.11-pkg1.run" as root.
Sorry, but I have to disagree on this (again... ;) )
Anyone who is maintaining a linux system (and thus has root access) really needs to learn about yum in order to get system updates. I would not like to be a user on a system maintained by someone who doesn't have at least some basic understanding of the up date system (preferably they should no a lot about it, its not hard...). Seeing as they have to do this anyway I (personally) think it is much more convenient to add the nvidia driver to the same update system.
Really, using the livna rpm + the kmod yum plugin (the atrpm repo has similar driver and plugin rpms, so if you prefer you can use that one) is a 'set it up and forget it' solution. Once you have it up and running you can safely leave the system to update itself (if you want) and be happy that the nvidia driver will also also be updated each time it is needed. With the official installer root has to log in each time and run it by hand. No where near as convenient.
cheers Chris
One of my boxes running FC6 and gnome automatically logs off its single user after a period of inactivity. Is there some parameter somewhere controlling this? If the origin isn't this obvious then what is the system log I should be looking at for clues as to what's happening?
Thanks for the help! --Jerry
On Sun, 2007-06-24 at 08:18 -0700, Gerhard Magnus wrote:
One of my boxes running FC6 and gnome automatically logs off its single user after a period of inactivity. Is there some parameter somewhere controlling this? If the origin isn't this obvious then what is the system log I should be looking at for clues as to what's happening?
This is a FAQ. Two common answers are:
1. You're not being logged off (everything that was running is still running), the terminal is just locked, and entering the password at the prompt unlocks it.
2. That one of the screensavers is crashing X. Change your preferences to not use the last one, or not pick random ones.
If that doesn't resolve it, write back to the list.
On Saturday 23 June 2007, Chris Jones wrote:
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
This is the worst thing about the official nivida installer, and why I will never use it.
The livna rpms work around this and install the nvidia opengl libs in such a way that it doesn't conflict with the default ones, but exist side by side.
At a later date you can just remove the rpm and end up back where you start, with a work nv driver.
Chris
Unforch Chris, that would take you out of the kernel development business since you'll have to wait for a kernel to make it to livna before you can use your machine. I'm one of those folks who play canary in the coal mine as I just booted to 2.6.22-rc5-cfs-v18 about 3 hours ago, and my card is working just fine. Google-Earth, Stellarium works great.
Unforch Chris, that would take you out of the kernel development business since you'll have to wait for a kernel to make it to livna before you can use your machine. I'm one of those folks who play canary in the coal mine as I just booted to 2.6.22-rc5-cfs-v18 about 3 hours ago, and my card is working just fine. Google-Earth, Stellarium works great.
In the cases where I have wanted to run a kernel that livna did not have an rpm for, I just download the srpm and roll my own nvidia kmod rpm for that kernel. If you are familiar with the system it takes no longer really than running the nvidia installer, plus it means I don't have to abandon the benefits of the fedora update system (yum/apt whatever rocks your boot).
This though, is surely a minority case. For most uses that just roll with the standard kernels, no one is going to convince me that an rpm based system isn't the most convenient... ( Challenge ;) )
On 6/23/07, Tim ignored_mailbox@yahoo.com.au wrote:
Tim:
But have NVidia stopped doing that thing where they mucked up other aspects of Xorg to suit themselves? That stung me badly when I had to pull out a NVidia card to try another one, and Xorg was buggered.
Gene Heskett:
I don't believe so. During the install it would appear it puts its own OpenGL stuffs in, and runs ldconfig to fix the links. If that is what it takes to make it work, shrug.
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
nvidia-installer --uninstall puts everything back where it was prior to installing the nvidia driver. This is documented.
Tim:
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
Lonni J Friedman:
nvidia-installer --uninstall puts everything back where it was prior to installing the nvidia driver. This is documented.
We *should* be able to just configure X with the driver to use at that time, we should't have to uninstall something to use a different driver. And what happens to someone with two graphics cards that they want to use simultaneously?
On 6/23/07, Tim ignored_mailbox@yahoo.com.au wrote:
Tim:
Grr, sods! Some might think that not an issue, since you don't change graphic cards that much, usually. But you may if you test people's machines. And the same issue bites you if you try to go back to the open source nv driver to get around something you can't get to work with the nvidia driver (I experienced that, myself).
Lonni J Friedman:
nvidia-installer --uninstall puts everything back where it was prior to installing the nvidia driver. This is documented.
We *should* be able to just configure X with the driver to use at that time, we should't have to uninstall something to use a different driver.
You aren't objecting to having to install something to use a different driver.
And what happens to someone with two graphics cards that they want to use simultaneously?
I don't understand the question. There's nothing stopping anyone from doing that, however you'd still need to have the nvidia driver installed if you wanted accelerated support.
Tim:
And what happens to someone with two graphics cards that they want to use simultaneously?
Lonni J Friedman:
I don't understand the question. There's nothing stopping anyone from doing that, however you'd still need to have the nvidia driver installed if you wanted accelerated support.
In the past, and I don't know if it's still the case. Installing nvidia's driver, from them, mangled parts of X to suit itself. How would that work if you wanted to use another video card, simultaneously that wanted X without mangling?
On 6/23/07, Tim ignored_mailbox@yahoo.com.au wrote:
Tim:
And what happens to someone with two graphics cards that they want to use simultaneously?
Lonni J Friedman:
I don't understand the question. There's nothing stopping anyone from doing that, however you'd still need to have the nvidia driver installed if you wanted accelerated support.
In the past, and I don't know if it's still the case. Installing nvidia's driver, from them, mangled parts of X to suit itself. How would that work if you wanted to use another video card, simultaneously that wanted X without mangling?
Without mangling of what? Its not clear to me what kind of configuration & use case you're referencing. If you want to use two completely different X drivers with full accleration in both, that isn't possible, and has nothing to do with nvidia's packaging or installer.