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.

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.

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!!

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.

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

mhh nforce3 support that would be good , appleyukon kext doesn't support marvell 80E001 your kext would be a god send, pls post it after you take a rest

I've uploaded the zip file. Again, if people want stuff other than the a8n-sli to work, getting the device and vendor ids to me would be helpful so I can add implementations, if necessary.

great work mate, i want to try this out so bad, but my the machine I use mac on, it's CPU died and my other two comps don't even have SSE2 err..

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

Hi there,

I'm not sure on which device/vendor IDs to report (the network controller, or the other one?), so I posted screenshots.

10DE, 0057?



Thanks!

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.

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.

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.

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.

I just tried the newest one and it works fine thx

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.

Hi there,

This is my debug log:



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.

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.

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.

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.

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.

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.

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?

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.

Here's the output from "ifconfig -a". MAC address changed to protect the innocent.

# ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::250:8dff:xxxx:xxxx%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.247 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:50:8d:xx:xx:xx
media: autoselect (<unknown type>) status: active
supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 100baseTX <full-duplex> 100baseTX <half-duplex> 1000baseT
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030
lladdr 00:50:8d:00:00:xx:xx:xx
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>

I'm having the same problem. From the network utility, the link is active but somehow the phy is not picking up the media speed or negotiating with the router. I've tried 10HD,FD,100HD,FD and 1000. Also, packets are being sent but none are received. Will try to get the debug info out if needed.

planetbeing

Excuse, I have slightly mixed: in my system Yukon - en0 and Intel - en1. But it is unimportant, nF4 is en2.


I have tried to disable in "Preferences/Network" Yukon and Intel and configure nF4, but unsuccessfully: via DHCP nF4-NIC receives incorrect IP. At manual adjustment unsuccessfully too: when i ping, i get
"PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: Host is down".
All the same. Below is my ifconfig.

Click to view attachment
If you want, I can remove Intel from PCI-slot and disable Yukon in BIOS

Be advised that I did not write any interface for allowing forcing the media type and speed, so doing that will have an unknown behavior: it will certainly not work, though!

But excellent, a lot of good data to work with, but they seem like lots of different problems that occur after... "forcedeth: Link speed now 100Mbps, code 0x10064"?

It's strange. After this message, forcedeth (unless the link dies again, in which there should be a message) should set the interface to active, and set the media correctly. For johnzbesko, that's not being done. It says active... but unknown type.

johnzbesko: Did you see a message like "forcedeth: Link speed now 100Mbps, code 0x10064"? If the code is different, please tell me. Also, it seems like you have an IP address, subnet mask and everything. Were these successfully set with DHCP?

everyone: With "tail -f /var/log/system.log" running, load the kext in builds/debug (using kextload. There are a few script files in the directory now for your convenience, loadkextd loads the debug one). Tell me whether plugging in and unplugging the ethernet after it reports a link makes it update properly, ie. "Network link down" and then "Link speed now 100Mbps" after you plug it back in. Try this a couple of times. This lets me determine whether IRQs are being sent and received correctly.

Then tell me how many times (approximately) you see "packet <some number> - <some other number>". This is (sort of) a receive event.

Then tell me how many times you see "ck: <something>, start <something>, end <something>" or "NIC ring full, stalling". Those are send events.

Or best of all, attach the relevant parts of /var/log/system.log.

planetbeing
Because i don't know what strings from system.log you need,

I have made
1) Has cleared system.log
2) Has inserted a cable in nF4
3) Rebooted
4) kextload
5) Waited
6) Has taken out a cable, waited few sec.
7) Has inserted a cable, waited
8) kextunload
9) Has copied system.log to other place

system.log I send you in PM (zipped, 8kb)

Pretty much the same issue as npwski. Only difference is that I'm at en0.

Actually, you're even worse off than most, since you can't even see the 100Mbps link. As far as the driver knows, you don't have a cable plugged in. It may be the link timer bug on nForce LANs. The original forcedeth driver had a fix for it, but I didn't include it since it wasn't necessary for me. I'll upload a fix later today.

Actually it's there but quite a few hundred lines down! Looking forward to your fix. Thanks for your efforts.

Oh, I didn't see that. Then it means you have the same problem as the others after all (probably). This is really strange: IRQ is activating, link status is working, but no packets received. Maybe some sent, but none logged (perhaps all the spam pushed it out of the buffer). I'm starting to think this is a problem on boards with dual controllers. You guys all have your PHYs at addr 1, while I have mine all the way at address 9. So it's possible that there are multiple PHYs and I've been listening on the wrong one.

Attached update changes it so it tries to detect and report multiple PHYs and uses the last one it detects. Give it a shot, and give me the system.log snippet. I've also made a couple of other versions, and if that doesn't fix it, you should also try forcedeth-d.kext in the release folder. As it is running, type ping 192.168.0.1 and leave it running for awhile and see if anything comes up in system.log. This will let me know whether OS X is attempting to send out packets or not after all.

hey planetbieng good work so far,

few tips(steps) to get this fully working

- don't work because is writen for PPC only

1: you will need to lose all conversation big2 endian (x86 is little endian , PPC big )
2: lose all OSSynchronizeIO(); - is only for PPC CPU, does nothing under x86
3: add IODeviceMap and map device (IOPCIDevice) mem ( not idea what mmiobase use that Yukon ) but must be at 0x10;( kIOPCIConfigBaseAddress0 ) ie IODeviceMemory *mymmio = device->mapDeviceMemoryWithRegister( kIOPCIConfigBaseAddress0 );

4: replace read/writeRegister your own read/write function (mem i/o)

readRegister(UInt16 offset) { return (((UInt16 *)(baseAddress))[(offset)/2]) ; }
writeRegister(UInt16 offset, UInt32 data) { (((UInt16 *)(baseAddress))[(offset)/2]=(data)); }

where baseAddres = (char *) mymmio->getVirtualAddress();

but check deeply how much real size yukon use for memio registers ( if need use IODeviceMemory::withRange to specify exact size of io range )

and you have it....

hope i give you some "bad" ideas

Hi,
Just to confirm that this works.
Managed to get it running, and I am posting this on 10.4.5 as I speak..
Am using the default forcedeth.kext.

Been really tied up with stuff these few days, will try to get a system log out.

Thank you very much! I wrote this driver without benefit of really proper specific instruction, so this is really appreciated. I had a devil of a time getting memory mapping to work initially, and I looked at tuxx's early code for his (not working yet) IW2000 driver.

I had managed to get it to work even without your suggestions, but that's probably because you just pointed out the places where the extra code I added does absolutely zilch, like you said, as a quick glance at the documentation for OSSynchronizeIO shows. The reason for this is I tried to follow the Linux device driver as closely as possible, and since Linux is designed to work on multiple architectures, it needed a command to enforce strong memory ordering and the correct endianness. I suppose it's not necessary here.

1. My endian conversions are sort of a just in case type of thing. I realize that right now they do nothing, but I have them convert from whatever the native endianness is to the little-endian format compatible with PCI devices like the network card. So it does work with those bits of code still in there. And it'll continue to work even if someone decided, for some impossible reason, to mix a nForce LAN on a PPC motherboard... okay, so that's not ever happening, so maybe I'll take those out.

2. Those will be removed as soon as I get the chance. Thanks for the heads up!

3. kIOPCIConfigBaseAddress0 IS used, but the latest version scans all of the BARs for a correctly sized space, just in case it's not on the first one. It might be a good idea, because a similar problem (with the PHYS being on different addresses) was the reason why my driver hasn't been working for so many people. But borez just got it work, so I have my hopes.

4. Those actually ARE my custom routines, pretty much stolen from tuxx's code, and they work.

So basically, the memory and endian stuff DOES work as of right now, and your suggestions merely helped explain to me what is really going on. But I'm really quite grateful that you took a look at my code, and I'm sure I had a couple of other questions I wanted to ask someone at some point about OS X architecture. I'm blanking at the moment, but I'll be sure to chuck them over your way from now on. Thanks again, though!




@borez: Glad you have it working! The default kext you're using right now supports all the features I've implemented so far, which includes offload checksumming, memory scatter/gather, and a IRQ polling system that should be easier on your CPU in general, so it's really the best version to use if you can.

Would you mind digging in your /var/log/system.log and telling me what PHY the driver is using? It'll be a line like:

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

If you have two lines like that in a row, maybe one at address 1 and one at address 9, paste me both of them. This would be immensely helpful because in the future I can make the driver pick a PHY more intelligently (instead of just picking the last one detected, as I am doing currently).

hi,
i already posted that it works for me... but so far i just thought that it worked because i unplugged my usb ethernet... well at least i thaught that i unplugged it.. in real i unplugged my usb hub and the usb ethernet was still connected. but with the last kext you postet i can confirm that it works (with now the right one unplugged )

thanks for your efforts

Working perfect. Thankz a lot.

Great work!

Now I regret spending $9 on a seperate NIC 2 weeks ago

It works now! Thanks planetbeing!

I'm writing this post using Safari and the latest forcedeth driver! Thank you for your efforts. I now have a usable, if unstable, OS X system.

The nVidia SATA still gives me trouble- sometimes my NTFS and FAT32 partitions are recognized, sometimes not. If I delete the Extensions.kextcache and Extensions.mkext files and reboot, the SATA partitions are seen until the next boot. Guess I'll have to check another forum thread...

I also have a strange latency problem- I can be scrolling through a file list or maybe hitting a bunch of backspaces on the terminal command line and the computer sort of stops a second or two and then resumes. Any ideas?

John, you might want to try a PATA drive instead while waiting for the NF SATA support to mature.

Could someone tell me the PHY address they're using now?

# cat /var/log/system.log|grep PHY
Mar 26 12:41:42 john-zbeskos-computer kernel[0]: forcedeth: Found PHY 0x04c0:0x0013 at address 1.
Mar 26 12:53:32 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x0013 at address 1.
Mar 26 13:55:25 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x0013 at address 1.
Mar 26 13:58:14 john-zbeskos-computer kernel[0]: forcedeth: Found PHY 0x04c0:0x0013 at address 1.
Mar 26 14:36:33 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x0013 at address 1.
Mar 26 14:42:03 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x002f at address 1.
Mar 27 14:26:38 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x002f at address 1.
Mar 27 14:31:13 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x000f at address 1.
Mar 27 16:34:37 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x000f at address 1.
Mar 27 16:40:44 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x002f at address 1.
Mar 28 13:25:21 localhost kernel[0]: forcedeth: Found PHY 0x04c0:0x002f at address 1.
Mar 28 13:57:06 john-zbeskos-computer kernel[0]: forcedeth: Found PHY 0x03c0:0x0031 at address 1.
Mar 28 20:03:24 localhost kernel[0]: forcedeth: Found PHY 0x03c0:0x0031 at address 1.
Mar 28 22:24:10 localhost kernel[0]: forcedeth: Found PHY 0x03c0:0x0031 at address 1.
Mar 28 22:34:04 localhost kernel[0]: forcedeth: Found PHY 0x03c0:0x0031 at address 1.

Hope this helps! The first entries obviously refer to the use of the earlier versions of forcedeth.kext

BTW, I am using a PATA drive. When I discovered that nVidia SATA didn't work (with the tiger vmware image), I added an old 8GB drive, partitioned with 6GB HFS and 2GB FAT32 volumes. Maybe this old funky drive is the cause of my latency problem. Also, my keyboard and mouse occasionally go dead and I have no choice but to physically reboot. Maybe support for PS/2 connections is also buggy? Do the Mac 86 machines use USB keyboards and mice?

Finally, forcedeth works for me perfectly, no garbage in logs. Great work, thank you very much!

Mar 28 11:35:00 Gemastud kernel[0]: forcedeth: Found PHY 0x04c0:0x000f at address 1.
Mar 29 07:46:58 Gemastud kernel[0]: forcedeth: Found PHY 0x04c0:0x0000 at address 1.
Mar 29 07:57:31 Gemastud kernel[0]: forcedeth: Found PHY 0x03c0:0x0031 at address 1.
Mar 29 08:13:20 localhost kernel[0]: forcedeth: Found PHY 0x03c0:0x0031 at address 1

Mine is at address 1 as well.

I should have decided to code this a long time ago. If everyone paid me half the amount they spent for cheap NICs....

For those who are interested, I've isolated the problem the earlier version was having, but the latest update essentially fixes it anyway, so there won't be a new release. Please continue to report bugs here.

Hi there,

This is what I got. There's only 1 line here.

Mar 29 15:25:22 localhost kernel[0]: forcedeth: Found PHY 0x03c0:0x0031 at address 1.
I do sometimes get some system lockups, but there doesn't seem to be anything logged in the system.log.
Hope they don't happen again..

@planetbeing

How do you stop the driver from spamming system.log with the following message? I'm still getting quite a bit of it. Thanks.
Mar 28 02:00:22 Gemastud kernel[0]: forcedeth: packet 80000000 - 8000062e
Mar 28 02:00:22 Gemastud kernel[0]: forcedeth: packet 80000000 - 8000062e