Jump to content

Driver for nForce4 LAN


planetbeing
 Share

765 posts in this topic

Recommended Posts

I'm one of the unlucky/poor ones who own a A8N-SLI... and not even the deluxe edition that gives you the Marvell-Yukon chip which would work for OS X. I didn't want to buy another LAN board, because I'm perversely repulsed by that sort of redundancy and inelegance.

 

After a few attempts at trying to manipulate the vendor and device ids to make the Apple drivers work, I decided to write my own from scratch. :happymac:

 

Well, more precisely, I decided to blatantly rip off of the GPL'ed forcedeth driver for Linux, which someone had mentioned earlier (but I had a really difficult time getting a copy of the source code on Google, I only managed to get several old versions so far). But I figured 2000 odd lines of code isn't too unreasonable and I could figure it out mostly, and also figure out enough of OS X's innards so I can port it.

 

Luckily, I was right, and it's partially thanks to the Apple team for providing a surprisingly friendly platform to code... device drivers on. I've never coded one in my life, and I've never coded for Macs, either, but I was able to get the hang of it pretty quickly. (However, I must say the documentation wasn't the best... I mean at least do a better job of hyperlinking it! And also I had quite a fun time trying to get the provided interrupt request handler to work right... it actually crashed my computer a lot more than the "unsafe" method I used earlier did)

 

The driver is pretty crappy, I have severe doubts about its stability, and indeed, I've had to restart my computer a lot during the development process, but having your code running at the kernel level doesn't give you a lot of room for error. ;) But, hey it works (sort of... I think it might still want to murder USB if I try to unload the kext... "unsafe" method didn't have this problem). Also, I wasn't able to implement the latest and greatest features. Like scatter-gather, TOS and so forth. For those things, I'd probably have to actually talk to a real person to figure out what's going on instead of just looking at the code (which is pretty much not commented at all).

 

Anyway, I'm not how much interest is there (all the other nForce4 people seem to have other LAN cards or have the Deluxe or Platinum version and using the Marvell Yukon driver), and the driver so far is still pretty humiliatingly unstable (though I haven't tested it out extensively). If you want the source, it'll be all GPL'ed and such.

 

But I mostly wanted to brag about how I wrote a OS X driver. :) It doesn't seem like that happens a lot... Pretty good for a Apple newb, eh?

 

EDIT:

 

The driver attached should now be fairly stable, but as with all OS X drivers, there is no guarantee of support. Complete system freezes have been known to occur with older versions and may reoccur, so avoid doing critical work on OS X. Source code is included for the sake of future generations. Here are my recommended instructions for getting it working on your computer:

 

1. Download the attached driver

2. Extract the contents onto the desktop

3. Open the Terminal application in the Applications/Utilities folder

4. Type "tail -f /var/log/system.log" to obtain debugging output for the first run.

5. Use the menu bar to open up a new Terminal window.

6. In this new window, type "cd ~/Desktop/forcedeth/build/Release"

7. sudo chown -R root:wheel forcedeth.kext

8. sudo chmod -R 755 forcedeth.kext

9. sudo kextload -v forcedeth.kext

10. Observe in the log window what happens. If there are no errors, and you eventually see the link going up with a proper speed, then the driver will work with your hardware. Otherwise, paste the log in this thread for help.

11. Test out the driver by browsing some websites, etc.

12. If there were any problems in steps 10 or 11, type "sudo kextunload forcedeth.kext", then repeat steps 7-11 for forcedeth-nockd.kext

13. To install the driver, type "sudo cp -R forcedeth.kext /System/Library/Extensions"

14. Lastly, update the extensions cache with "sudo kextcache -k /System/Library/Extensions"

 

 

EDIT: I needed to do some work on OS X again, so I installed Leopard. The original version of my driver seemed to not work/immediately kernel panic so I made a small change. I think it's probably the same change I made awhile ago when I was trying to fix it for stability. I also cleaned up the plists a bit. But if it didn't work for you at all before, it will probably not work for you now either. But if it worked for you before, this version should work better.

 

It was compiled under 10.5, so it might need a recompile for your version of the OS.

 

EDIT2: Replaced old version with a newer version that fixes a bug that caused kernel panics for me before. After some work figuring out how to get panic logs, I traced it to the occasional failure of replaceOrCopyPacket. I did a quick Google search to see why that could possibly happen -- only it lead me right back to this thread, where someone named chuttenh had already traced it to the very same problem. D'oh! I can't keep track of this huge thread. Anyway, I posted my version of the fix. There's some weirdness with refilling the ring with "available packets" after errors that I think may come up with earlier versions and chuttenh's version, but I am not sure. His version has a few other changes, I think, and is available from his post somewhere in here.

 

EDIT3 I merged MeDevil's changes for MCP61 and called it 0.3 (thanks, MeDevil!). I cannot test these changes myself, but according to MeDevil, it should take care of the waking up from sleep problem and backwards MAC address issue for MCP61. Note that the device ID is hardcoded in there, so if anyone has these issues and do not have MCP61, change where it checks specifically for 0x03EF, stick in your device ID, recompile and see if it works for you. If it does, tell me and we can add it. (EDIT3.1: Updated 0.3 to actually add MCP61 to the Info.plist, forgot to do that last time. Oops!)

 

EDIT3.2: Github repository up at http://github.com/planetbeing/forcedeth-osx/. Issue pull requests whenever. It also has a wiki if people would like to share their experiences with the driver there.

forcedeth.zip

forcedeth_0.2c_leopard.zip

forcedeth_0.3_leopard.zip

Link to comment
Share on other sites

Hi there,

 

It'll be godsend to all the nForce 4 users.. Not all users have available PCI slots to spare for an additional network card (ie, me..)

 

I'm using an Abit KN8 Ultra (I don't think they are using the Yukon drivers right?)

 

Thanks!! :)

Link to comment
Share on other sites

I'm too tired to package up the file right now, spent all night getting it to work, but I'll upload it later on the day. I'm now loading it directly during startup and it works fine. It still does screw up the whole IRQ/USB bus, but when it's unloading it, I'm turning off my computer, so it doesn't really affect me anymore. However, it may be an indicator of some magical instability that will cause it to not work on anyone's computer but mine. :) I think I have an idea of how to fix it, though, but that'll have to wait until the weekend.

 

Otherwise it works like a charm and as fast as anything, though I haven't tortured it with bittorrent or anything yet.

 

If you get a chance, please find your device and vendor ids for your particular LAN chip. You can find it under device manager. In their properties, in one of those advanced configuration drop downs, there should be a string that's like PCIblahblahVENblahblahDEV. You just have to pay attention to the hex numbers near VEN and DEV. VEN should be 10DE (I think), since that's the ID for nVidia. I'd like to know these numbers so I can see if forcedeth mentioned them. As I've said, my driver borrows heavily from forcedeth (except the actual physical communication part, and scheduling tasks and such so its cool with the OS... most of the algorithm, though). That driver was able to support quite a range of chips, many different flavors of nForce3 and others, and the code required for such additional support was essentially negligible. So I want to see if my implementation will support your motherboard, and if it doesn't, so I can make a few tweaks.

Link to comment
Share on other sites

Post the source code as well as the actual thing. That way more development can be made on this.

 

Also, just as a warning. You may get alot of people asking how to load it etc etc etc. You may want to make a little tutorial, which should save you time instead of having to answer questions over and over.

 

But thanks :( This is great progress! Hopefully soon, nForce will be fully supported, lol

 

TheFighter

Link to comment
Share on other sites

hi, i dunno if it's supposed to work with my nforce3 marvell 80E001 , i've tried adding my device id but it doesn't seem to work.

 

In the system log i see:

 

ar 25 11:51:53 localhost kernel[0]: VT86: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: USB0: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: USB1: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: USB2: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: MAPU: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: MACI: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: pci1022,1103: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: pci1022,1102: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: pci1022,1101: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: pci1022,1100: family specific matching fails

Mar 25 11:51:53 localhost kernel[0]: Matching service count = 1

Mar 25 11:51:53 localhost kernel[0]: Initializing

Mar 25 11:51:53 localhost kernel[0]: com_triton_forcedeth::probe(ethernet)

Mar 25 11:51:53 localhost kernel[0]: Probing

Mar 25 11:51:53 localhost kernel[0]: com_triton_forcedeth::start(ethernet) <1>

 

 

but nothing shows up in the network panel section and from the terminal using ifconfig

 

i've attached my iolog hoping it can help

myz.txt.zip

Link to comment
Share on other sites

0057 is the same device id as the one I have on my motherboard, so the driver should work fine. As you can see, they're actually both the same device. I'm not sure why nVidia wanted us to load a second "bus enumerator" thing. Maybe it has to do with dual controller support (I heard those things have two PHYs and one MAC, so they're not two completely separate devices).

 

I uploaded a new version that supports multicasting properly and fixed the bug with the USB bus. Also, I added some checksum offloading. I only had the register names to work off of, so I don't really know what precisely they do, but the receive part seems to work. At least, I'm able to load this page on OS X to post this. :) Also, I did some testing, and I don't see any memory leaks or anything like that, so I changed it to a release version and removed the debugging flags. You should now use the build/release compiled version.

 

@myzar: The vendor id doesn't seem to be nVidia, so I figure it must be a Marvell chip on an nVidia motherboard. I definitely owe you one since if I'm not mistaken, you're the one responsible for my boot cd, but if the motherboard only came with a Marvell chip, it's likely to be wholely different from the nForce LAN chip, so there's really not much I can do. All the registers have different addresses, and so on. Actually I thought the AppleYukon.kext driver would have solved your problems with this thing... did that not work?

 

However, I'm surprised that no further messages appeared in the log, and didn't crash your computer either. I'm going to guess it's hanging as it waits to read the PHY through the MII. Of course, the interface for the MII is going to be in completely different locations on Marvell and nForce, so it's going to be waiting a long time, but this shouldn't be infinite. It should at least have logged that it has indeed found a PCI device at the address you forced it to use. I'm not sure what's up with that.

 

Out of curiosity, if you want to try your hand at helping me figure out the problem (though I'll probably still not be able to help you in the long run), you can edit the code and add a "break;" statement after where it says "forcedeth: PCI subsystem 0x%04X:0x%04X opened" and compile and load that. Unless something is horribly wrong, that should give you a message after com_triton_forcedeth::start(ethernet) <1>

 

If it does, progressively move the break statement down until it stops working. I'm going to bet the PHY detection routine.

Link to comment
Share on other sites

Yes you are right after searching around i've noticed your mobo has two network card, an nvidia one and a marvell yukon so your driver is for the nvidia only.

 

About the appleyukon kext it only works with the marvel yukon 2 , with a marvel yukon 1 like mine it keeps saying that the cable isn't plugged in, i wonder if is there a way to force detection.

Link to comment
Share on other sites

Hi,

 

Placed this driver in IONetworking, and forcedeth managed to find my PHY. Yay!

 

Encountered some initial problems with the driver, I can't connect to the Net. It seems that it is unable to grab a DHCP IP from my router, the IP is still stuck at 169.254.198.124, subnet 255.255.0.0

 

I've tried to set an manual IP, but to no avail. There's no activity on my router.

 

Is there anything that I've missed out? I am using the build/release version.

Link to comment
Share on other sites

Hi,

 

Placed this driver in IONetworking, and forcedeth managed to find my PHY. Yay!

 

Encountered some initial problems with the driver, I can't connect to the Net. It seems that it is unable to grab a DHCP IP from my router, the IP is still stuck at 169.254.198.124, subnet 255.255.0.0

 

I've tried to set an manual IP, but to no avail. There's no activity on my router.

 

Is there anything that I've missed out? I am using the build/release version.

 

i have the same problem, and i used the same build/release.

Link to comment
Share on other sites

I recommend loading it and unloading it manually with the command (in Terminal):

 

kextload -v <path to forcedeth.kext>

 

Before that, you should (in a separate Terminal window), type "tail -f /var/log/system.log", so that you can get the debugging output from the kernel. If necessary, unload it later by:

 

kextunload <path to forcedeth.kext>

 

Load it and tell me all the messages from forcedeth. It looks something like this for me (this is how it should work):

 

forcedeth: Initializing.

forcedeth: Probing.

Starting.

forcedeth: PCI subsystem 0x1043:0x8141 opened.

forcedeth: Mapped from 0xD2100000 of length 4096.

forcedeth: Allocated 3072 bytes of contiguous memory for DMA: rx at 0x34d22000, tx at 0x34d22400, wired at 0x2902e000.

forcedeth: Found nForce4 LAN with MAC: 00:15:F2:50:EF:C6.

forcedeth: Found PHY 0x3080:0x000c at address 9.

com_triton_forcedeth: Ethernet address 00:15:f2:50:ef:c6

forcedeth: Enabling

forcedeth: Network link down.

forcedeth: Link speed now 100Mbps, code 0x10064.

 

This should all appear in quick succession, though a second or two is needed before the last link is displayed and the network is established.

 

What I'm specifically curious about is whether forcedeth ever gets to the "enabling" part.

 

EDIT: I've changed the driver a little so it's slightly more verbose, also I removed an tx/rx control flag that wasn't supposed to be there.

Link to comment
Share on other sites

here is what i get, from the debuggin output.

 

I dunno, it should have been okay at that stage. The network went up, so that means the driver is able to dynamically respond to events, so the interrupts are working. You can experiment with unplugging and replugging in the cable. In the log, it should tell you when you unplugged it "Network link down" and when it's able to reestablish a connection.

 

In terminal, try typing in "netstat -I en0". It should give you statistics on how many packets are sent and received, and how many errors there have been. If there's no errors and this is constantly increasing, then it means pretty much everything is good, so the problem is then on the TCP/IP side, which is OS X's responsibility, and you'll have to mess with the router configurations or something for that. The other possibility is that the checksum code is screwing up somehow; I'll provide tools for diagnosing for that if that's the case.

 

EDIT:

 

@myzar: Actually my motherboard only has one ethernet controller, which is why I had to write a driver in the first place. A8N-SLI: one controller. A8N SLI Deluxe or Platium: two controllers, one of which is a Marvell, which can work with AppleYukon.kext.

Link to comment
Share on other sites

Hi there,

 

This is my debug log:

 

Mar 26 10:11:42 xs-computer kernel[0]: forcedeth: Found nForce4 LAN with MAC: 00:50:xx:xx:xx:xx.
Mar 26 10:11:42 xs-computer kernel[0]: forcedeth: Found PHY 0x04c0:0x0000 at address 1.
Mar 26 10:11:43 xs-computer kernel[0]: com_triton_forcedeth: Ethernet address 00:50:xx:xx:xx:xx
Mar 26 10:11:43 xs-computer kernel[0]: forcedeth: Enabling... 1 2 3 4 5 6 7
Mar 26 10:11:43 xs-computer kernel[0]: forcedeth: Starting transmit/receive engines
Mar 26 10:11:43 xs-computer kernel[0]: forcedeth: Network link down.
Mar 26 10:11:44 xs-computer kernel[0]: forcedeth: Link speed now 100Mbps, code 0x10064.
Mar 26 10:11:48 xs-computer launchd: Server 0 in bootstrap 1103 uid 0: "/usr/sbin/lookupd"[111]: exited abnormally: Hangup
Mar 26 10:11:48 xs-computer configd[53]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/enable-network
Mar 26 10:11:48 xs-computer configd[53]: posting notification com.apple.system.config.network_change
Mar 26 10:11:49 xs-computer lookupd[198]: lookupd (version 369.3) starting - Sun Mar 26 10:11:49 2006
Mar 26 10:11:49 xs-computer configd[53]:   target=enable-network: disabled

 

I did the netstat thing, and it showed no packet transmissions at all. The activity LED on my router was as dead as a fish. :)

Link to comment
Share on other sites

Try the latest build, but use build/debug. It should spam the log file with activity if it comes across packets at all. Also, the beginning part of it is changed to give me more information on your detected dev and vend.

 

If it does spam the log file, it means some thing is wrong in rxProcess, if it doesn't it means the IRQ handler is not being called enough for some reason. Also try disconnecting and reconnecting your ethernet cable, to see if it registers in the log.

Link to comment
Share on other sites

I also have an A8N-SLI mobo and have installed the forcedeth.kext driver. Ii works to the extent that I can ping en0, but the rest of my network shows "no route to host". I tried the various suggestions in the above posts- kextload, netstat, etc., but no luck.

 

Where is the "latest" version referred to in post #11? Is there a date stamp to identify it?

 

Thanks for your help.

Link to comment
Share on other sites

I always just upload the latest version in the first post.

 

Those things I suggested are not meant to get it working. You're meant to get the results of them to me somehow so I can find out what the problem is, and "no luck" is not terribly descriptive. Tell me precisely what's logged to /var/log/system.log by builds/debug/forcedeth.kext, and paste the output of netstat -I en0.

Link to comment
Share on other sites

planetbeing

 

I tried two versions of your forcedeth.kext - v002(??) and v003(??). With both versions system recognise my nForce4 NIC (right mac-address). My network (100mbps) has 192.168.x.x with mask 255.255.255.248 (small net). I played with various network settings (manual, DHCP), but no success. If manual - then nothing (no ping), if via DHCP - wrong IPs (169.254.26.27 etc). Lights of my ADSL-router - no reaction. With ver.003(??) - so many lines "forcedeth: packet 80000000 - 8000062e" in log.

 

I opened two rootconsoles. In ttyp1 i doing "kextload/kextunload". In ttyp2 i typed "tail -f /var/log/system.log" and "netstat -I en2" (en2 because in my system Intel-82558 is en0, MarvellYukon is en1 and nForce4 is en2).

 

Below attached my logs

1) with forcedeth.kext ver.002(-??) [less verbose version]

2) with forcedeth.kext ver.003(-??) [more verbose version]

 

Maybe these logs will help you, i hope. Sorry my bad english.

Link to comment
Share on other sites

Your logs indicate that OS X didn't even ATTEMPT to use the ethernet driver. I'm getting log entries indicating that packets are being received, but none at all about OS X even attempting to send a packet (if it had, it would indicate whether the request was successful or a failure). Packets should be going out for DHCP at the very least. The fact that the interface is attached to en2 might be the problem. Mine is attached to en0, so it looks like there might be two ethernet adapters OS X is trying to connect to before the nForce LAN.

 

Let me see the results of ifconfig -a

 

Also try going to System Preferences:Network:Show:Network Port Configuration and unchecking everything that's not the nForce thing. My nForce driver is listed as "built-in ethernet". That position might have gone to some other device on your computer.

Link to comment
Share on other sites

I can report the same behavior. I also tried manually setting the ethernet settings for speed and duplex and no combination worked. My error messages are the same as the previous post.

 

INAP (I am Not A Programmer), but I think a few more debug statements are called for. Noobie question: how would I compile the forcedeth.kext from the supplied source myself? Is it similar to the linux "./configure;make;make install"?

 

Would using the BSD nve driver also be a way of successfully getting this nvidia ethernet to work?

Link to comment
Share on other sites

Well, it's quite simple to compile the code using xcode. You just open up the project and click the build menu option. Unfortunately, typical of Apple bloat, xcode tools comes on a 900 MB dmg.

 

I've put debug statements now in most of the places that make sense in the context of the driver itself, but not all. They appear in the debug build. johnzbesko, my request for you is the same as for npwski... If you have the exact same thing: no packets being output, then tell me what ifconfig -a shows.

 

Apple drivers are completely different from BSD drivers, which is why this port exists.

Link to comment
Share on other sites

 Share

×
×
  • Create New...