Slashdot Mirror
GPL'ed Drivers For NVIDIA nForce Ethernet Devices
An anonymous reader writes "Manfred Spraul has released a GPLed driver for the ethernet device found in motherboards based on the Nvidia Nforce/Nforce2/Nforce3 chipsets. Drivers provided by Nvidia on the other hand, are closed. Andrew Morton has integrated this driver in the 2.6.9-mm2 release of his mm tree. And if you are using a 2.4x kernel, you may want to check out this post."
Its great that drivers are available for this new chipset, but is this really worth being a /. topic???
Wow, I didn't know the kernel left -test status and increased 9 versions since yesterday. Andrew Morton must be on top of things to get a -mm patch out that quick, too.
;)
Good job editors.
This is great - now I just need to get the XFree86 nv driver to play nice with my nForce2 w/ integrated video, and I'll be able to run a non-tainted kernel.
:(
Has anybody else had problems with X on such a board? There's apparantly a bug somewhere in the rendering code that crops up because the nv driver doesn't use hardware acceleration as much as the nvidia driver. I filed bug #811 on bugzilla, but no resolution yet
I always thought most modern ethernet cards were compatible with some generic brands.. like ne2000.
If I understand correctly, the Ethernet is built right onto the mainboard, with the chipset.
Audio processing went down this route a while back. Old soundcards aren't needed when the functionality was built into the chipset.
For high speed networking (like GigE), avoiding the PCI bus can potentially be faster.
"Provided by the management for your protection."
A good analogy would be there are 5 people all trying to call one guy, and Mr. Ethernet is one of the people. By being in the chipset and not on the bus, he doesn't have to keep trying to call and getting a busy signal, he can just say his message. This is because Mr. CPU could talk to 3 or 4 people at a time (he's that fast), but the phone (PCI bus) only has one line. He just skipps the problem.
OK, that's a bit simplified, but the fact is that not waiting on bus contention is good. The ethernet doesn't have to wait for/fight against the sound card, the tv tuner, and the add in raid controller.
On a side note, while NE2000 is a standard, it's for ISA, and as far as I know the NE2000 PCI standard never got big. I could be wrong. And even then, that's like using VESA to controll your GeForce FX video card. You can do it, but you could lose alot of the performance and features that you paid for because VESA doesn't know about 'em.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
The transactions occur across a much faster interconnect (which can go by different names according to the chipset design), but it's still linear and you still access resources in a PCI-like manner. Just faster.
The only bus that was different was ISA.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
All true, however in the context of the story. Having GPL drivers means that people with ethernet connections to the internet i.e. Cable or DSL can connect and get the drivers they need from Nvidia's site. The VESA standard and the 'nv' drivers allows one to have the basic functionality to at least get the OS installed and get 'something' done.
When NVDIA's binary drivers are with every distribution, then the GPL driver will be of less concern.
I know integrated sound cards sap a much larger portion of CPU time then PCI cards, making them a poor choice for gamers. I've avoided using integrated Ethernet on the same principle. Should I reconsider?
How much I care on the Y, title index on the X.
____
/ |
/ |
1.0| / |
| / |
0.5| / |
| _________________/ |
0.0|/_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _
GPL'ed Drivers for NVIDIA nForce...
Way to get my hopes up, Slashdot. I guess my kernel will continue to be tainted.
Under 2.6.0-test9-mm2 this driver works good for me. I am managing to download from the net at full speeds (120kb/sec), and transfer large files over my lan at 11mb/sec (which is as good as I got with the nvidia binary driver).
For an alpha driver, I think thats pretty impressive. I wasn't even expecting it to work.
However, I did read someone saying that under heavy network load, the driver did not perform as well as the nvidia binary one (he was running a FTP server or something).
Apart from the non-GPL'd status, I'm not aware of big problems with ethernet drivers for nForce boards - as noted elsewhere in this thread they seem to be functionally supported out of the box.
But getting the sound components of the nForce board to work is altogether more challenging - the nVidia drivers are very basic and don't always work. Various patches exist (e.g. this entry from the Gentoo Discussion Forum) and some people report installing SBLive type cards to get around the problem.
Apparently one problem that is preventing GPL'd audio drivers is that nVidia won't release the technical specifications of the nForce audio components...
Reverse engineering the binary driver for the ethernet chip and making a GPL'd source tree for anyone to review is great. :-)
However, I don't think that it offers much except for hypothetical multiplatform portability. Without any specs it would be extremely hard to modify the driver and it's even harder to add new features.
Now I just hope someone has the time and skills to reverse engineer the NVidia video driver and GL libraries so that my 2.6.0-test9-mm2 kernel wouldn't give me pages of tracebacks every time I launch X using the nvidia driver.
No, you shouldn't.
The reason for this is that the vast majority of 'integrated sound cards' are not really dsp's, but are mere codecs. Thus they hog the CPU for many, if not all sound processing tasks.
On the other hand, integrated ethernet devices aren't codecs - they're just those ethernet chips planted onto the main motherboard PCB instead of a separate card. They can have a slight performance benefit because of a high-speed interconnection with the chipset, too.