LWN: Comments on "Danger with NVIDIA drivers 180.29"

Danger with NVIDIA drivers 180.29

nix — Mon, 18 May 2009 20:32:00 +0000

Yeah. It's embarrassing to have drivers that have Just Worked on every
Radeon card I've tried them on for the last eight years.

The trick is to look for those cards that already work reasonably well,
not to think 'ooh, the driver's called "radeon" so anything ATI ever made
should work perfectly'.

(but you know that of course)

Danger with NVIDIA drivers 180.29

daenzer — Mon, 18 May 2009 18:03:13 +0000

> Probably my vote for the "Lifetime Embarrassment Award" would go to the perpetually unfinished open-source Radeon driver.

(No) thanks for the award; it's very rewarding and motivating for the people who've put effort into improving those drivers, isn't it.</sarcasm>

There's no question that as far as features and performance are concerned, currently no free drivers compare to the major IHV proprietary drivers. However, it's quite disappointing to have to read something like the above on this site, from someone who judging from his other comments seemed to have some appreciation for what free software is (not) about.

Danger with NVIDIA drivers 180.29

lkundrak — Thu, 30 Apr 2009 10:55:55 +0000

Well, kerneloops doesn't include much data from real crashes, since it's usually too late for automatic submit of crash log once the machine completely stops responding. Well, you can grab the panic message via serial console and post it to bugzilla or mailing list, but nobody does that for nvidia drivers for obvious reason.

Secondly, most kerneloops data is collected from bleeding edge and development releases. More reports from non-nvidia hardware generally mean more development is happening there.

When it comes to stable Linux-based OS-es, let's consider RHEL 5 (I haven't used other comparable OS-es, but I believe most widely used enterprise-class distribution is a pretty good example). ATi and Intel works mostly flawlessly there compared to NVidia, which for example can not resume from suspend, or freezes for minutes (on T61, again fairly common platform). And no, no kerneloops messages were sent for it.

Danger with NVIDIA drivers 180.29

pharm — Sun, 26 Apr 2009 11:31:57 +0000

<i>Note that free drivers ever brick hardware.</i>

Yup: there was a period a while back when the i2c drivers would brick some IBM laptops. Then there was the mess with the Intel network cards...

Hardware isn't perfect, and there's always the risk that you tickle an edge case that does something permanent, even if you're doing things strictly by the book (assuming you have the docs at all).

feature request

nix — Fri, 24 Apr 2009 20:43:37 +0000

True enough. After all, we *know* the Goo Corporation is evil.

feature request

sbergman27 — Fri, 24 Apr 2009 18:43:50 +0000

Probably best to stick to just FOSS announcements. We shouldn't be undermining the great work the OpenGoo team is doing.

feature request

nix — Fri, 24 Apr 2009 10:01:38 +0000

Well, the World of Goo release got an announcement :)

feature request

tetromino — Fri, 24 Apr 2009 03:16:16 +0000

Before laughing at Nvidia, how about getting *any* open-source video driver to perform at the same level that Nvidia does? I suggest you start with the Intel driver - which remains amazingly unstable, and whose performance gets worse with every release, despite being open and supported by Intel's hardware people. And even if Intel doesn't cause as many kernel oopses as Nvidia, it causes far more X lockups and crashes.

Danger with NVIDIA drivers 180.29

pr1268 — Fri, 24 Apr 2009 01:29:58 +0000

LWN does not normally carry announcements for proprietary driver releases, but...

Thank you, Jon, for this article. Especially as it has cultivated such a nifty little discussion. Even if the crux of the discussion is in reference to a touchy subject regarding binary-only drivers.

Danger with NVIDIA drivers 180.29

gcallow — Thu, 23 Apr 2009 21:05:42 +0000

True, but i915_* and radeon_* also figure prominently. I don't believe kerneloops.org provides
conclusive evidence that the Free graphics drivers are any more reliable than nvidia. My own
(subjective) experiences with a number of i915 and nvidia machines are similar. Both run pretty
well, but the intel machines aren't immune to problems.

Personally I think the claim of FUD has some merit. The nvidia driver isn't perfect, but I don't see
evidence that the Free drivers are doing a significantly better job, and nvidia have demonstrably
better performance.

If you want to use only Free software, then fine. If you're unhappy with the additional maintenance
overhead, or the fact that nvidia drop support for older cards out of newer drivers then that's also
fine. However, If you want to claim the nvidia drivers are bug-ridden and imply that the Free
drivers are intrinsically more reliable then, at the moment, I don't think the evidence is there.

Danger with NVIDIA drivers 180.29

k8to — Thu, 23 Apr 2009 16:37:24 +0000

There is nothing at all wrong with the instability of Linux kernel internal interfaces. They refuse to have their hands tied in order to fix bugs and improve things. We all reap the benefits.

If you think this is bad (obviously), then why don't you go over to OpenSolaris or FreeBSD and stop insisting that something is wrong with Linux?

Whether or not you think it's reasonable for the Linux developers to alter the Linux kernel, it's certainly unreasonable to ship end user drivers which repeatedly fail in this environment.

No evidence of bricking

GreyWizard — Thu, 23 Apr 2009 15:37:20 +0000

This comment just made my day. Well said.

No evidence of bricking

Duncan — Thu, 23 Apr 2009 11:21:09 +0000

"It's a brick that stays warm."

Great example of that famous Corbet humor! Sure you aren't related to any
of that Python troop? (Still laughing.)

"I'm not a brick!"

"You are a brick. You're a brick that stays warm!" [conk]

...

(See what all those first-week readers missed! =:^)

Danger with NVIDIA drivers 180.29

Duncan — Thu, 23 Apr 2009 11:08:11 +0000

> Finally, the X server has been pretty pathetic about video driver
selection; in Windows there are often fallbacks so that if one driver
can't be loaded something else is, so that you at least get SOME display.
X? zip. nothing. Just a console. nVidia's fault? hardly.

The console /is/ the fallback, in that case. It's the ultimate "safe
mode".

Meanwhile, I agree with Seyman, no need to blame nVidia for the kernel
policy, when they could simply release decent specs and let the community
handle it at far less trouble than they are going to (despite nVidia) with
the nouveau driver.

FWIW, I did run the nVidia driver when I first got serious about switching
to Linux, because while I had done enough pre-buy (pre-switch) research to
know nVidia had Linux drivers and that they worked with TwinView, but I
had unfortunately NOT groked the difference (again, while doing pre-switch
research still on MS Windows) between unfreedomware Linux drivers and
freedomware Linux drivers.

It didn't take me long to figure it out tho once I switched, tho, as those
separate recompiles (I was building my own kernel before I had even chosen
my Linux mail client) got old VERY quickly, and that was the last
proprietaryware needing card I ever bought (and will ever buy, if I have
anything to say about it). I very quickly decided I did NOT dump a decade
of experience on proprietaryware just to continue to be subject to the
mastery of unfreedomware on Linux, as well. If I were to subject myself
to that, what was the point of dumping all that experience to start over
again? Not much. That one taste of freedom was all it took.

Duncan (I'll close with the quote I use as a sig on the mailing lists,
that I referred to above with that "subject to the mastery of
unfreedomware" bit.)

"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

No evidence of bricking

gnb — Thu, 23 Apr 2009 08:29:52 +0000

>You're surprised that a BIOS is crappy?
No, I realize that's the standard. Disappointed maybe.

Danger with NVIDIA drivers 180.29

epeeist — Thu, 23 Apr 2009 07:03:53 +0000

"Still get some graphical corruption with KDE4, mind :P"

So did I, it would seem to be some contention between KDE and the NVidia driver when trying to do anti-aliasing.

I changed the anti-alias configuration setting of the driver to allow it override the application setting and this seems to have fixed the problem.

Internalizing issues

man_ls — Thu, 23 Apr 2009 06:54:12 +0000

And Microsoft internalizing all driver issues is not bad at all. In fact I would say that Linux distributors might gain a lot from this practice. It is also a great opportunity now that Microsoft has managed to forget it.

feature request

proski — Thu, 23 Apr 2009 02:50:16 +0000

How about proprietary userspace software?

Danger with NVIDIA drivers 180.29

sbergman27 — Wed, 22 Apr 2009 23:55:28 +0000

"""
It was insightful to read a comment by one of the ext4 developers (I think it was Greg Kroah-Hartman) about the fsync 0-byte file issue.
"""

No. It was Ted Tso. He initially tried to blame the whole problem on NVidia and Ubuntu users... and then on the majority of application developers... but then ended up fixing the worst problems with his filesystem, instead, when enough people pointed out what he was doing.

I followed those discussions closely, and would hardly call that particular part of them "insightful". "Wildly Blameful" would probably be a more accurate term to apply.

I would prefer FOSS drivers to proprietary ones. I would like to see NVidia open up. But the fact remains that NVidia's drivers have historically been of higher quality than most of the FOSS video drivers. And denying that doesn't help FOSS. Higher quality FOSS drivers would help FOSS.

No evidence of bricking

nix — Wed, 22 Apr 2009 23:19:26 +0000

You're surprised that a BIOS is crappy?

I've had systems whose BIOSes went into an infinite loop because a hard
drive was larger than they expected, or because two hard drives were
attached, or because the keyboard was not attached, or because the wrong
model of keyboard was attached, or because the machine was plugged into a
docking station with an attached display which was not made by the right
vendor.

These days I'm rather surprised if I attach *anything* I didn't buy with a
PC to the machine and the BIOS doesn't toss its cookies over the side.

I think I may be getting cynical in my old age.

Danger with NVIDIA drivers 180.29

seyman — Wed, 22 Apr 2009 23:13:48 +0000

> Please... you're blaming nVidia because the kernel doesn't have a stable API, and thus when users use the nVidia driver then update their kernel the driver stops working?

No, I'm blaming nVidia because they refuse to publish the source to their driver which prevents the open source community from shipping a rebuilt version along with every new kernel.

Danger with NVIDIA drivers 180.29

flammon — Wed, 22 Apr 2009 22:49:03 +0000

FUD! You've gotta to be kidding. Here's a nice list of people who have been dealing with crashes for the last 5 months.

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

Nvidia drivers have been crashing most systems that I've worked on for the past year. Just because you have a combination of hardware that doesn't crash, lucky for you, doesn't mean that it's FUD. It's real. Go ahead buy yourself an HP G60 laptop with an nvidia 8200, install your favourite distribution and the latest stable nvidia drivers and I'll eat my shorts if it doesn't crash.

Danger with NVIDIA drivers 180.29

joey — Wed, 22 Apr 2009 21:58:40 +0000

kerneloops.org has broad data that differs with your personal ancedote. nv_* is frequently in the top ten causes of oopsen there.

feature request

dmarti — Wed, 22 Apr 2009 21:57:53 +0000

If you're going to post stories about bugs in proprietary drivers, at least please add tagging functionality to LWN so we can tag them "haha". [[!tag haha]]

Danger with NVIDIA drivers 180.29

mrshiny — Wed, 22 Apr 2009 21:57:14 +0000

Please... you're blaming nVidia because the kernel doesn't have a stable API, and thus when users use the nVidia driver then update their kernel the driver stops working? And calling this a crash, or somehow a symptom of instability?

First, when you install third part software it sometimes breaks when you update your distro (or even just parts of your distro). Whose fault this is isn't even important, it happens, but it's certainly not a "Crash".

Second, the kernel's no-stable-abi/api nonsense is hardly nVidia's fault. Any out-of-tree drivers will have this problem. nVidia just happens to be the poster-boy for this particular issue.

Finally, the X server has been pretty pathetic about video driver selection; in Windows there are often fallbacks so that if one driver can't be loaded something else is, so that you at least get SOME display. X? zip. nothing. Just a console. nVidia's fault? hardly.

Dont' get me wrong, I can't wait for the nouveau guys to fix everything that's wrong with nVidia's driver. But "stability"? that's not one of the things.

Danger with NVIDIA drivers 180.29

SLi — Wed, 22 Apr 2009 21:30:29 +0000

You probably also think the kernel developers are just being asses for not accepting backtraces from non-graphics parts of the kernels when you have nvidia binary blobs insmodded?

It was insightful to read a comment by one of the ext4 developers (I think it was Greg Kroah-Hartman) about the fsync 0-byte file issue. He very specifically pointed to nvidia binary blob issues where it is known to randomly corrupt memory when wondering about people who tolerate kernel crashes.

Call it bashing if you wish, but I don't want anything unsupportable crap like that near my computer, thank you, and I do feel I'm the pragmatic one here.

Danger with NVIDIA drivers 180.29

jengelh — Wed, 22 Apr 2009 21:24:40 +0000

I wholeheartedly agree. I have seen so much more soft bricking (=no permanent hardware damage) or broken/unsupported features with e.g. VIA hardware and the free drivers that exist for it. And I am not even talking 3d.

No evidence of bricking

gnb — Wed, 22 Apr 2009 21:22:48 +0000

Although the fact that the system is bricked at that point seems as much a
BIOS deficiency as anything. The BIOS could do something sensible like look
for an external display, or try falling back to some lowest common
denominator display spec. and hope the hardware can manage this, or just boot
with no video and hope the OS supports a serial console. Simply dying because
the EDID is garbage is feeble.

Danger with NVIDIA drivers 180.29

SLi — Wed, 22 Apr 2009 21:22:35 +0000

Well, there's a very good solution. Don't buy hardware that doesn't work
properly with tolerable drivers in a tolerable OS.

Danger with NVIDIA drivers 180.29

seyman — Wed, 22 Apr 2009 21:09:01 +0000

> The "binary nVidia driver crashes your kernel" bit is FUD, IMO.

I'm not sure. When the nvidia driver needed to be rebuilt against your kernel every time you upgraded, the Red Hat mailing lists were submerged with mails complaining that the kernel upgrade had crashed their machine (in fact, X hadn't started).

The same thing happened with upgrading to the next version of the distribution which upgraded your kernel but didn't rebuild the nvidia driver to match.

Feel free to argue that this isn't a crash, per se but the heart of the matter is that a) users didn't like it and b) it happened with the nvidia driver, not the nv one.

No evidence of bricking

proski — Wed, 22 Apr 2009 18:34:51 +0000

Thanks for the details! That's bad indeed.

Danger with NVIDIA drivers 180.29

rakoenig — Wed, 22 Apr 2009 17:55:38 +0000

You're right. Nobody should put the blame on nVidia in this case as they were very much helpful in fixing this issue after it was reported to them. Luckily Fujitsu was able to quickly provide a test machine to the nVIDIA developers and a repair tool that fixes the problem without the need of sending the machine back for repair (sorry guys, that is non-free and not to be redistributed). But at least in that way it was possible to give bugfixes some "test shots" without the hazard that a false move means sending the machine back for repair and waiting some days for the next shot.

And they also provided beta drivers early that already fixed the problem quickly, but it took still a while for the public release.

So besides of the GPL vs. proprietary driver discussion I have to say that even in a mixed world with OSS software and proprietary drives customers should be aware that they get full support for problems. And currently nVIDIA is "state-of-the-art" in 3D graphics and BTW: in a notebook you don't have much choice to replace the graphics card. :-)

So thanks to the team that provided all the knowledge, tools and skills to quickly fix this bug and thanks to the (thank god) few customers that were patiently waiting for the final bugfix.

Rainer (The reporter of bug 433 on RPMFusion :-)

No evidence of bricking

rakoenig — Wed, 22 Apr 2009 17:41:21 +0000

If the error occurs the system boots exactly to the point where BIOS/Video-BIOS want to identify the display. Since the EDID data is corrupt the system locks up, so you don't even have a chance booting with an external monitor attached. So you have an expensive brick that keeps your desk at moderate temperature (to quote Jonathan).

The only way to "repair" this requires opening the housing and will make the customers warranty void. So the process is contacting the vendor and letting someone from them repair it with the proper tools.

BTW: This issue seems to be happening on drivers of the 180.xx series only. Debian 5.0 with packaged 173.xx drivers are not affected.

Rainer (that "bricked" and repaired his H270 several times)

Danger with NVIDIA drivers 180.29

nye — Wed, 22 Apr 2009 16:53:49 +0000

Agreed. I had some stability problems a few years ago, but that was when manually enabling options clearly marked as experimental (IIRC it was when the option to enable damage and composite with GLX was first added). Since then every system crash I might have blamed on it has turned out to be caused by hardware problems.

Still get some graphical corruption with KDE4, mind :P

No evidence of bricking

corbet — Wed, 22 Apr 2009 16:42:40 +0000

If you don't like my term, then fine. You still have to send it back to the vendor to get a system that works. It's a brick that stays warm.

No evidence of bricking

proski — Wed, 22 Apr 2009 16:34:44 +0000

The announcement says:

Using earlier NVIDIA Linux drivers on the Celsius H270 notebook will result in a corrupt EDID, which will persist across reboots

If a system reboots, it's not bricked. Bricked systems don't reboot.

Danger with NVIDIA drivers 180.29

pr1268 — Wed, 22 Apr 2009 16:32:39 +0000

Welcome to the world of Microsoft. It's all too easy to blame the OS for grief caused by 3rd-party buggy drivers (or user-space apps).

Of course, Microsoft tends to internalize this problem and fix problems themselves (according to this Raymond Chen blog post from several years ago about unsavory programming practices at a game software company).

Danger with NVIDIA drivers 180.29

sbergman27 — Wed, 22 Apr 2009 16:25:16 +0000

I wondered how long it would take for the mindless and uninformed bashing to begin. As a casual, but long time Linux gamer, I've been watching the Linux graphics situation since about 1997, having owned quite a number of different graphics cards over that time. All in all, and despite a huge wind of FUD coming from certain agenda-driven Linux kernel developers, I have found NVidia's drivers to be about the highest quality of any Linux drivers I have ever run, open source or closed.

Probably my vote for the "Lifetime Embarrassment Award" would go to the perpetually unfinished open-source Radeon driver. At least my Intel X4500 graphics are finally stable. I purchased an MB with a G43 chipset last Fall, specifically because Intel was supposed to be doing such a great job supporting Linux FOSS drivers. And it was, without a doubt, the *worst* Linux graphics experience I have ever had. I had to go back to my NVidia for a couple of months, waiting for even the *text consoles* to become usable.

So be careful about trashing NVidia and making implied claims about FOSS video driver quality. Because there is a lot more embarrassing evidence I could throw back at you.

Danger with NVIDIA drivers 180.29

dilinger — Wed, 22 Apr 2009 16:15:42 +0000

There's a pretty major difference between non-free drivers being installed by default (which means an end user isn't even going to realize that non-free drivers are installed, and problems will be seen as "Linux problems") versus an end user having to manually install a non-free driver in order to gain additional functionality. In the latter scenario, a user may actually realize that the lack of stability occurs after installing the non-free driver, and might therefore blame the driver (and pester the vendor to fix it).

Danger with NVIDIA drivers 180.29

trasz — Wed, 22 Apr 2009 16:00:39 +0000

Actually, given that nVidia cards were the only ones with usable 3D acceleration for quite a few
years, I'd say the opposite.