Slashdot Mirror

My main complaint about the whole issue is that I only found out because it was posted here. I don't have time to go checking for updates and exploits for all my different drivers and software, that's why yum runs from cron every night. It would have been nice if somebody (nVidia) had posted that a new version was available that fixed potential security holes, or even had a version checker built in to notify me of an update.

Disabling RenderAccel:
Option "RenderAccel" "False"
will serve as a workaround for those who are not comfortable with running a 1.0-962x driver.

Disabling RenderAccel:
Option "RenderAccel" "False"
will serve as a workaround for those who are not comfortable with running a 1.0-962x driver.

That version seems to have come out of beta 3 days ago:
http://www.nvnews.net/vbulletin/showthread.php?t=7 8188
http://www.nvidia.com/object/linux_display_ia32_1. 0-9626.html

It's perfectly stable here - no crashes ever. Driver version 9625, Xorg 7.1, kernel 2.6.18, Gentoo, GeForce FX 5700.

Some nVidia Linux driver devs hang out here, try searching and asking about your problem:
http://www.nvnews.net/vbulletin/forumdisplay.php?f =14

it seems that the original forums post, found here http://www.nvnews.net/vbulletin/showthread.php?p=9 31048
stipulates that you use the nvidia driver aka 'nvidia' in correlation to gedit. This will crash X.
HOWEVER
if you were to use the driver 'nvidia' with Kate, this would not crash it.

nvidia driver flaw? yes, noting the use of gtk in addition

According to the first comment over on kerneltrap, this was fixed by NVidia last month in a beta release. However, the issue in question was not mentioned in the release notes.
http://kerneltrap.org/node/7228/
http://www.nvnews.net/vbulletin/showpost.php?s=878 67d1f473f5e912c412a23e19a8dc3&p=1027749&postcount= 11/
http://www.nzone.com/object/nzone_downloads_rel70b etadriver.html/

I tried running things like Doom 3/Quake 4 in Linux with the same card before it exploded, and instead of a BSOD which Linux prides itself on not having... the games simply froze up requiring a hard reset. I'm not sure if this is supposed to be better than a BSOD, but at least a BSOD provides some information (even if it's often unintelligible).

I had a series of major problems with video. It did, in fact, turn out to be that the video card I'd purchased was defective. The new eVGA card works fine. In fact, I'm hard-pressed to crash it now.

Why is the submitter only pimping the HotHardware review? Here's more (in no particular order):

HardOCP
Guru3D
Anandtech
Bjorn3D
PCPerspective
nV News

And how is that different than the roadkill of http://www.nvnews.net/vbulletin/forumdisplay.php?f =14 - 20 new problem threads each day???

Not with the "7" series cards. As far as I know the last card that could be Quadro-modded was the 6800 with the nv40 core: http://www.nvnews.net/vbulletin/showthread.php?t=5 3058

• http://www.theinquirer.net/?article=28855
  http://www.nvnews.net/vbulletin/showthread.php?t=7 0486

Whoops - I meant to include a link to someone with framebuffer problems.

I repeat here folks - if you want to use linux to its full capabilities DO NOT BUY NVIDIA OR ATI

If you want to have fast 3d in X & are happy with bugs elswhere, follow evershill's advice.

I will use the drivers that work, regardless of license.

My experience with Nvidia in this regard has not been great. About half of the time, the drivers install and work perfectly, but sometimes they don't, and it takes a lot of work to try and figure out why. My current setup (amd64 and geforce fx6200TC) required me to apply a patch to the nvidia driver, then installed the files in the wrong place (there is a workaround for that that I wasn't aware of at the time), and now I have a setup that works fine as long as I don't use the Gliedescope or AntSpotlight xscreensavers (in which case the machine locks up hard, often with a message "BUG: soft lockup detected on CPU#0!" followed by a stacktrace that implicates the nvidia driver as the cause. (for the curious, a more detailed post on fedora forum is here)

I wish the open-source drivers were at least more stable and useable, but they seem to have a tendency display random garbage on the screen from time to time. (I've seen this on three different computers with different Nvidia cards, so I doubt this is a rare occurance.)

I haven't tried ATI, but perhaps I will next time. How are the drivers in that camp these days?

I will use the drivers that work, regardless of license.

My experience with Nvidia in this regard has not been great. About half of the time, the drivers install and work perfectly, but sometimes they don't, and it takes a lot of work to try and figure out why. My current setup (amd64 and geforce fx6200TC) required me to apply a patch to the nvidia driver, then installed the files in the wrong place (there is a workaround for that that I wasn't aware of at the time), and now I have a setup that works fine as long as I don't use the Gliedescope or AntSpotlight xscreensavers (in which case the machine locks up hard, often with a message "BUG: soft lockup detected on CPU#0!" followed by a stacktrace that implicates the nvidia driver as the cause. (for the curious, a more detailed post on fedora forum is here)

I wish the open-source drivers were at least more stable and useable, but they seem to have a tendency display random garbage on the screen from time to time. (I've seen this on three different computers with different Nvidia cards, so I doubt this is a rare occurance.)

I will use the drivers that work, regardless of license.

My experience with Nvidia in this regard has not been great. About half of the time, the drivers install and work perfectly, but sometimes they don't, and it takes a lot of work to try and figure out why. My current setup (amd64 and geforce fx6200TC) required me to apply a patch to the nvidia driver, then installed the files in the wrong place (there is a workaround for that that I wasn't aware of at the time), and now I have a setup that works fine as long as I don't use the Gliedescope or AntSpotlight xscreensavers (in which case the machine locks up hard, often with a message "BUG: soft lockup detected on CPU#0!" followed by a stacktrace that implicates the nvidia driver as the cause. (for the curious, a more detailed post on fedora forum is here)

I wish the open-source drivers were at least more stable and useable, but they seem to have a tendency display random garbage on the screen from time to time. (I've seen this on three different computers with different Nvidia cards, so I doubt this is a rare occurance.)

I haven't tried ATI, but perhaps I will next time. How are the drivers in that camp these days?

I will use the drivers that work, regardless of license.

My experience with Nvidia in this regard has not been great. About half of the time, the drivers install and work perfectly, but sometimes they don't, and it takes a lot of work to try and figure out why. My current setup (amd64 and geforce fx6200TC) required me to apply a patch to the nvidia driver, then installed the files in the wrong place (there is a workaround for that that I wasn't aware of at the time), and now I have a setup that works fine as long as I don't use the Gliedescope or AntSpotlight xscreensavers (in which case the machine locks up hard, often with a message "BUG: soft lockup detected on CPU#0!" followed by a stacktrace that implicates the nvidia driver as the cause. (for the curious, a more detailed post on fedora forum is here)

I wish the open-source drivers were at least more stable and useable, but they seem to have a tendency display random garbage on the screen from time to time. (I've seen this on three different computers with different Nvidia cards, so I doubt this is a rare occurance.)

From my experience the nvidia drivers aren't very stable.

That's odd. What card(s)/motherboard(s)/kernel version(s)/nVidia driver version(s)?

They've always been perfectly stable with my GeForce 4 MX and GeForce FX 5700. A motherboard with Via AGP and an nForce 2 motherboard (all nVidia chipsets, nVidia AGP etc). Stable on Arch Linux, Gentoo Linux, kernels compiled with GCC 3.3.x, 3.4.x, and now 4.1 beta, and stable with both the kernel's AGP driver and the nVidia driver's built in driver.

The only trouble I remember was console framebuffer not working on the 4 MX, and nVidia drivers at the time (not a problem now) not being compatible with the 4K stacks option introduced in kernel 2.6.6.

Here's a good place for nVidia Linux driver help:
NVIDIA Linux Forum @ NVnews.net

Listed alphabetically.

http://www.anandtech.com/video/showdoc.aspx?i=2593
http://www.avault.com/hardware/getreview.asp?revie w=evga6800gs
http://www.computerbase.de/artikel/hardware/grafik karten/2005/test_nvidia_geforce_6800_gs/
http://www.driverheaven.net/reviews/X16_GS/index.h tm
http://www.guru3d.com/article/Videocards/278/
http://www.hardocp.com/article.html?art=ODgy
http://www.hothardware.com/viewarticle.aspx?articl eid=747&cid=2
http://www.noticias3d.com/articulo.asp?idarticulo= 541
http://www.nvnews.net/previews/geforce_6800_gs/ind ex.shtml
http://techreport.com/reviews/2005q4/geforce-6800g s/index.x?pg=1

There are lots of other reviews out there, too. Looks like the 6800GS kicks the X1600 where it hurts. Over and over and over again.

- [H]ard|OCP
- Avault
- Computer Base
- Driver Heaven
- Guru3D
- Hartware
- HotHardware
- Noticia3D
- nV News
- The Tech Report

I shamelessly stole this list from Hardocp.com

Well the first hint would be the GL_ lines in the config file.....

Then there's this. Note that Doom 3 and Riddick are used as OpenGL performance benchmarks.

And finally, this, particularly the quote "The Doom 3 engine is important to the gaming community as it continues id Software's commitment to OpenGL."

If I was in front of my desktop right now, I'd take a look at what libraries Doom 3 and Quake 4 link to for further proof, but alas, I'm on my Tablet PC which has no hope of even running Half-Life 1 at a decent framerate.

Unfortunately there are lots of reasons why it could be going wrong.

Honestly the best thing you can do is to post to the nv forum and then send a message to NVidia themselves (see the "CONTACTING US" part of the README that came with the drivers). You may well have hit a genuine problem (Which only NVidia will be able to confirm) but you don't provide enough information - (which card? What were you doing at the time? Were there any Xids? The list goes on and on). *Don't post the reply to those questions here* though - go to NVidia. That way you can skip the speculation. Good luck.

I ran into this when migrating from the xfree86 to the xorg server in sid:

http://www.nvnews.net/vbulletin/showthread.php?t=2 8708

[nvidia] can keep the drivers closed till hell freezes over for all I care - they work, they work great... ...as the folks in this 22-page long, nearly year old thread on the nVidia Linux forum, titled " 'screen frozen, but mouse pointer moves' bug", would no doubt agree.

BSDs more likely than Linux because of licensing restrictions. Although a good number of drivers for the linux kernel are written as modules and don't have to have to be GPL'd. In fact there are a number of drivers that are released under a BSD license as well as proprietary, binary-only drivers. Also more hardware venders might support the Solaris x86 platform. nVidia released Solaris 10 x86/x64 drivers.

speaking of the Tyan K8WE, here's someone who has maxed it out (wow, that's easily more than $12K worth of hardware at retail!):

http://www.nvnews.net/vbulletin/showthread.php?t=4 5575

He mentions running (SuSE) GNU/Linux on it too.

Supermicro apparently has a similar board although they are being very quiet about it; see for example this machine:

http://www.colfax-intl.com/jlrid/SpotLight_more.as p?L=88&S=14&B=1004

Currently nVidia is developing drivers for 32 bit Linux and FreeBSD, as well as for 64 bit Linux (on amd64). They are not developing drivers for FreeBSD on amd64.

An nVidia representative has responded to queries on the NVIDIA Linux Forum in two places:

FreeBSD-amd64 driver ?
There are no plans to support FreeBSD amd64 at this point in time, but customer requests will certainly help prioritize future projects. (01-14-05)

Any ideas when FreeBSD AMD64 driver is out?
It seems that FreeBSD/amd64 doesn't currently support loadable kernel modules; there also doesn't seem to be FreeBSD/x86 (?), let alone Linux binary compatibility. (04-16-04)

If you are interested in having nVidia drivers for FreeBSD on amd64, then I would encourage you to request these drivers from nVidia. Perhaps if they receive enough requests they will develop the amd64 FreeBSD drivers.

Currently nVidia is developing drivers for 32 bit Linux and FreeBSD, as well as for 64 bit Linux (on amd64). They are not developing drivers for FreeBSD on amd64.

An nVidia representative has responded to queries on the NVIDIA Linux Forum in two places:

FreeBSD-amd64 driver ?
There are no plans to support FreeBSD amd64 at this point in time, but customer requests will certainly help prioritize future projects. (01-14-05)

Any ideas when FreeBSD AMD64 driver is out?
It seems that FreeBSD/amd64 doesn't currently support loadable kernel modules; there also doesn't seem to be FreeBSD/x86 (?), let alone Linux binary compatibility. (04-16-04)

If you are interested in having nVidia drivers for FreeBSD on amd64, then I would encourage you to request these drivers from nVidia. Perhaps if they receive enough requests they will develop the amd64 FreeBSD drivers.

Currently nVidia is developing drivers for 32 bit Linux and FreeBSD, as well as for 64 bit Linux (on amd64). They are not developing drivers for FreeBSD on amd64.

An nVidia representative has responded to queries on the NVIDIA Linux Forum in two places:

FreeBSD-amd64 driver ?
There are no plans to support FreeBSD amd64 at this point in time, but customer requests will certainly help prioritize future projects. (01-14-05)

Any ideas when FreeBSD AMD64 driver is out?
It seems that FreeBSD/amd64 doesn't currently support loadable kernel modules; there also doesn't seem to be FreeBSD/x86 (?), let alone Linux binary compatibility. (04-16-04)

If you are interested in having nVidia drivers for FreeBSD on amd64, then I would encourage you to request these drivers from nVidia. Perhaps if they receive enough requests they will develop the amd64 FreeBSD drivers.

If only Nvidia could do likewise. Although they've done some wonderful work supporting their Linux drivers, a quick browse of the nvidia linux forums (which are by far the most popular at the nV News forums - not coincidentaly) shows the huge number of people who've been experiencing bugs (and in particularly the "screen frozen, but mouse pointer moves" bug) who would love to help, but can't.

Graphics card drivers are precisely the software that needs to be open source. It is simply too crucial an element of a stable system to let one company attempt to handle the vast range of systems and configurations out there.

Unless you're using an older Toshiba laptop (pre-A/M/P/R series) with an nVidia GPU and are experiencing the infamous Black Bar problem.

For us joe twelve packs (or just people that don't care about flashy boxes), the Retail BFG 6800 Ultra (and I think other models) come in a nice flashy white box.

Sure, their drivers are perfect. Must be why several other people have had problems with them too.

You immediately made me think of this :P.

check
http://www.nvnews.net/vbulletin/showthread.php?t=4 6676/

will work for 2.6.11 final.
nvidia *does* care

good luck!
rSl

zanders at nvForums has posted patches to improve performance with 2.6.x kernels. Here's the thread:
http://www.nvnews.net/vbulletin/showthread.php?t=4 6676

This is the cumulative patch:
http://www.nvnews.net/vbulletin/attachment.php?att achmentid=10558

zanders at nvForums has posted patches to improve performance with 2.6.x kernels. Here's the thread:
http://www.nvnews.net/vbulletin/showthread.php?t=4 6676

This is the cumulative patch:
http://www.nvnews.net/vbulletin/attachment.php?att achmentid=10558

That, and wasting several hours recently trying to get nVidia's most recent drivers working with the latest FC3 errata kernels on a Toshiba notebook really puts me off using ANY closed drivers in the future (hint: revert to 6111 and patch the kernel AND the nVidia kernel driver - details here).

I got a black screen with X using NVIDIA's 1.0-6629 drivers. The system could still be restarted with ctrl+alt+del, but nothing else worked.

If anyone else is having the same problem, there's some patches attached to a post at the nvnews forums that fixed it for me.

First set your system up without graphical login, which most distributions configure by default.
To do this edit /etc/inittab and change the default runlevel to 3, this means find the line
id:3:initdefault:
which will normally read 5 and change it to 3 (like mine is), Fedora inittab files are well commented and explain what to do, others are probably similar.
To go into X (the windowing system) you type startx after logging in, this gives you your regular desktop, gnome, kde, xfce, whatever.
When you are bored with email quit out of X and run your game with (I think)
xinit /usr/local/games/doom3/doom3

I read that here

The Linux and Windows NVidia drivers are feature for feature compatible

Explain this problem question from nvnews.net...

the linke once again:
"screen frozen, but mouse pointer moves" bug

I'm not really sure you understand the issues at stake here.

First, a stable module API doesn't matter. nV's drivers have the same fucking bugs for years' worth of releases. It's normal to expect some bugs for such a complicated piece of software when porting it to a new kernel major release, but these bugs happen in 2.4, 2.6, probably 2.2.

Even Microsoft is pissed off about this. I was told by a Microsoft engineer a couple years ago that drivers are the #1 cause of BSOD's on Windows by a long shot. If the Windows kernel is hobbled by bad drivers, what do you think happens to the Linux kernel, which is arguably better quality overall? The fact is, with all the code running in ring 0, and with privileged access to hardware that cannot be easily reinitialized if the driver crashes (ever tried to reload the NVdriver module?), it doesn't matter how good the kernel is. The Linux kernel developers are right to not support this madness because it dramatically lowers the delivered quality of their product. It's just plain old QA.

I do see a potential compromise that I'd embrace. NVidia could work with X.org to add hooks to the "nv" driver, so 2D could be rock solid all the time and I could use the same driver without rebooting for 3D. Even if 3D crashes every now and then, it matters a lot less, especially because I'm not going to get the same 3D elsewhere.

For the most part, you are correct. However, check here to read about people that have the same issues with nvidia as most do with ati. Nvidia works great on 2 of 3 of my machines, but on the third, it doesn't work at all, and nvidia won't respond to bug reports, nor say, "Yes, there is a problem with some chipsets, we are working on it." Yeah, I'll still buy an nvidia card next time around, just because it will *probably* work better.

Now the interesting post is here. They edited the last one posted.

Check it out at nV News.

Exactly! The Radeon 9600SE cards or GeForceFX 5200 cards that run about $50 are more than sufficient to run DOOM3 at medium quality, according to previous remarks by developers and the review posted here.

Doom 3 fast approaches, and the newest edition of PC Gamer has the "world exclusive" review. How did it score? It scored a 94%. Check out its highs, lows and bottom line:

Highs: Extraordinary graphics and sound; incredible tension, atmosphere, and mayhem.

Lows: Some stabs at humor fall a bit flat.

Bottom Line: Just as we'd hoped, it's a non-stop ride of tension, carnage and terror. A new classic.

Here's the cover.

Check out this HardForum Thread for more information.

UPDATE: Here's some more info I've found over at NVNews:The game will apparantly have a DVD version. There are multiple covers for the PC Gamer mag and the game boxes are different than the pre-order boxes.

August 4th, in stores...August 4th in stores!!!

Yeah, I was lucky enough to receive my copy today, so I'll share it with you guys.

1. 6800 is a tad faster than X800 cards. Both run it in full glory

2. The game has four render paths: NV10, NV20, R200, and ARB2. All paths look awesome, even down to a g4mx, but the ARB2 path is the "full package," and is used for the R300+ and Geforce FX+ cards. It does all it's fancy **** in one pass.

3. PCI Express enhances NOTHING.

4. The difference between a 128mb and 256mb card is that the former uses compressed textures whereas the latter only compresses diffuse and specualr maps. In another words, no big deal. However, a 500mb card is needed to run the game in Ultra Quality mode.

5. 512MB is the ideal system total memory. 384 is required, 1GB is nice, but the difference is negligible.

6. Nothing special is included for a 64-bit OS.

7. A 1.5 Ghz processor is the least recommended, but a 2Ghz and above will help since...

8...The sound engine is entirely CPU dependant. Therefore a crappy soundcard works flawlessly. Not to worry, the enfine only uses a "small percentage of cycles, much less than if the engine relied on a soundcard.

9. The only reccommendation regarding faster framerates is to disable to "advanced special effects option." In other words, upgrade if you have problems.

10. They tie it up by providing three levels of "Doom lovin' PC's"

Low-End:
1.5GhzP4 or equivalent
512MB Ram
Geforce4 Ti 4800 or Radeon 9500

Mid-Range:
2.4GhzP4 or equivalent
1GB RAM
Geforce5950 or Radeon 9800 Pro/XT

High_End: Aka Hardware that doesn't exist, but best guess anyway
3.4GhzP4 or AMD equivalent
2GB RAM
GeForce 6800 Ultra or Radeon X800 XT PE.

In conclusion, the game will run well on a variety of hardware, and Rob Duffy, the lead programmer, says that the game looks real good no matter what, and that it will continue to look better as hardware improves. Like all previous id engines, we'll be playing games based on D3 for another five years down the road.

Yeah, I was lucky enough to receive my copy today, so I'll share it with you guys.

1. 6800 is a tad faster than X800 cards. Both run it in full glory

2. The game has four render paths: NV10, NV20, R200, and ARB2. All paths look awesome, even down to a g4mx, but the ARB2 path is the full package, and is used for the R300+ and Geforce FX+ cards. It does all it's fancy **** in one pass.

3. PCI Express enhances NOTHING.

4. The difference between a 128mb and 256mb card is that the former uses compressed textures whereas the latter only compresses diffuse and specualr maps. In another words, no big deal. However, a 500mb card is needed to run the game in Ultra Quality mode.

5. 512MB is the ideal system total memory. 384 is required, 1GB is nice, but the difference is negligible.

6. Nothing special is included for a 64-bit OS.

7. A 1.5 Ghz processor is the least recommended, but a 2Ghz and above will help since...

8...The sound engine is entirely CPU dependant. Therefore a crappy soundcard works flawlessly. Not to worry, the enfine only uses a small percentage of cycles, much less than if the engine relied on a soundcard.

9. The only reccommendation regarding faster framerates is to disable to advanced special effects option. In other words, upgrade if you have problems.

10. They tie it up by providing three levels of Doom lovin' PC's

Low-End:
1.5GhzP4 or equivalent
512MB Ram
Geforce4 Ti 4800 or Radeon 9500

Mid-Range:
2.4GhzP4 or equivalent
1GB RAM
Geforce5950 or Radeon 9800 Pro/XT

High_End: Aka Hardware that doesn't exist, but best guess anyway
3.4GhzP4 or AMD equivalent
2GB RAM
GeForce 6800 Ultra or Radeon X800 XT PE.

In conclusion, the game will run well on a variety of hardware, and Rob Duffy, the lead programmer, says that the game looks real good no matter what, and that it will continue to look better as hardware improves. Like all previous id engines, we'll be playing games based on D3 for another five years down the road.

Enjoy everybody!

PC Gamer magazine reviewed Doom3 in its newest edition and gave the game a 94%.
Here is an interesting post in the nvNews boards, with the full review, hardware and multiplayer details

What pain and suffering? Nvidia's drivers are the most pain-free to install of any third-party driver. The useful module options are well documented, and there is a support community. Hell, Nvidia just added a new configuration utility. Unlike other drivers that are included with the kernel, Nvidia's modules are consistently functional, and aren't mystified by outdated HOW-TOs or the requirement to poke around inside the kernel source tree for a text file with module options; A file that may or may not exist.

On the contrary, my issue with hardware installation and Nvidia had to do with the open source components not produced by Nvidia. The Mesa OGL library changed their build scripts (which was the source of much confusion) because of issues with automake. Installing Mesa at the wrong time breaks Nvidia's OGL interface. The agpgart module was also the source of much frustration because it wouldn't support faster transfer modes on certain chipsets. So, when I couldn't get my GF3 Ti to run at 4x, I discovered that - in true OSS developer fashion - the option appears only inside a source code file, with no explanation. Thank heavens for the 'modinfo' utility and experience, whereas a less technically-inclined user wouldn't have a clue what an "int" is.

Nvidia shows a lot enthusiasm for GNU/Linux that other vendors do not. Their Linux drivers are always current, and well documented. They host a lot of complete or demo games for free and without registration hassles. Nvidia is fighting tooth-and-nail with ATI in a technology war that has resulted in ultra-high performance at affordable prices, yet even with ATI nipping at their heels, they've still managed to find the time to cater to the OSS community. Since there is a wide range of acceleration features that modern applications may or may not support, Nvidia's peformance secrets still remain inside their drivers. Putting these trade secrets out in the open would guarantee Nvidia's end. As much as I'd like to see the drivers become part of the kernel's source tree, I wouldn't want to see a friend of open source operating systems put out of business. Continued criticism of Nvidia only reinforces the Linux community's reputation as the enfant terrible of the computing world.