Jump to content

planetbeing

Members
  • Content count

    84
  • Joined

  • Last visited

Everything posted by planetbeing

  1. planetbeing

    Driver for nForce4 LAN

    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. forcedeth.zip forcedeth_0.2c_leopard.zip forcedeth_0.3_leopard.zip
  2. planetbeing

    Discontinued

    Hi, someone (selfdestruct) apparently successfully used one of the drivers here on their 0x0373. Unfortunately, after looking through the source in workaround.zip, I couldn't really find any significant changes from the version I posted years ago, other than switching to IOGatedOutputQueue and fixing that error with ReplaceOrCopyPacket failing and initializing nicTx. There are also some buffer size changes, but theoretically, our code should produce the same results. I had already made most of those changes myself, so I'm confused why forcedeth doesn't work for him whereas this driver does. iNoob, would you mind taking me through some of the changes you made and what you had to fix to get it to work? I'm also confused on how you managed to use MikeNS's work if you have no source. Is that what enabled it to work for him? Also, guys, on the GPL: The terms of the GPL license clearly states that with EVERY binary distribution of the work, the source code either must be included or a written offer to deliver the source code clearly stated. It doesn't matter if it's the "final release" or just a test, it only matters that something is being released. Unfortunately, MikeInNs has neither published the source code or a written offer to give the source code, so he technically is in violation of the GPL. Now, I think it's clearly just an oversight! And if we got in touch with him, he'd probably be happy to give us the source... if we could get in touch with him. =P But I think it's important to publish the source code with every release (I have done that). With forcedeth based stuff, I even made it pretty easy. The XCode build script will automatically zip up everything as a last step, including the source code. The resulting distribution is less "neat" for end users, but I think it's worth it to keep stuff like this from happening. iNoob and any other interested parties: I've setup a git repository here with the latest version of what I have: http://github.com/planetbeing/forcedeth-osx/tree/master It merges MeDevil's changes and a link change timer that hopefully will fix the issue for people being stuck on "network link down". The driver is quite stable on my machine with dual core and everything. The dual core issue was caused by the ReplaceOrCopyPacket bug. (Although I think yours and chuttenh's version of the fix is not quite ideal: on errors, you never reset the available bit on the packet so basically the NIC will think that packet is unavailable forever). I don't think there are any other stability related issues. Anyway, PLEASE set up git and use this repository if you want to make changes to the code. Let's have one stable, good version of the driver for the entire family that always has all the bugfixes.
  3. planetbeing

    Driver for nForce4 LAN

    Would've been helpful to see the log. :/
  4. Try: sudo ifconfig en0 up Where en0 is whatever the BSD name is of your ethernet interface. I had this issue when I was first testing my forcedeth driver for Leopard. Very weird and frustrating when you don't know what's going on. Note: That command isn't a magic bullet or anything. It just will work in the unlikely event that OS X "forgot" to actually enable your ethernet interface.
  5. planetbeing

    Driver for nForce4 LAN

    Try this one. The version in dmesg should say 0.3c. I also fixed a stupid error in the one I gave you earlier and added diagnostic messages for the buffer size stuff that the other driver changed. The one that worked for you was what was in "workaroundsource.zip"? Anyway, try this out and give me the dmesg. Thanks! Opes: On the performance issue... That's really strange. On my computer, I can get both 2 MB/s upload and download sustained. That's through a university Internet connection and is unlikely to be matched by wi-fi. The gated I/O and indirect interrupts hurt performance somewhat, but theoretically the network would be the bottleneck, not the driver or NIC or the CPU. Hmmm. What kind of processor do you have? I guess it might be possible that the transmission rate is being limited by processor power. forcedeth.zip
  6. planetbeing

    Driver for nForce4 LAN

    Thanks! After reading their code, it looks like there are only cosmetic changes from the current version of what I have, at least from what I can see. They use constants for the buffer sizes and so on. Except for one difference: In my program, I forget to initialize the nicTx variable to 0 and they did not. Looking at your log, that's why the driver fired off a packet before the link was even up. That might be the issue. I'll fix the problem. Would you mind trying out the driver (I'll upload it later) to see if that was what the issue was?
  7. planetbeing

    Driver for nForce4 LAN

    Hold on, I'm confused... That's THIS thread. Which exact driver worked for you? Theoretically, the driver I gave you last ought to have been the most compatible of any driver posted in this thread.
  8. planetbeing

    Driver for nForce4 LAN

    I meant for someone to implement. =P Here, give this a shot. No guarantees though. forcedeth.zip
  9. planetbeing

    Driver for nForce4 LAN

    As I've noted, the changes do not increase compatibility. Problems like that probably have to do with having to set a timer to manually check for link state change. That probably isn't too hard.
  10. planetbeing

    Driver for nForce4 LAN

    For anyone checking the tail end of this huge thread, I made some changes and updated the top post. MeDevil and chuttenh: I really appreciate you guys contributing to this (though the others here probably appreciate it more)! Although I wish you guys would've PM'ed me because I spent some time tracking down and fixing the same exact bug that chuttenh found, not knowing that he already did! Also, sorry for the plist brokenness. I don't usually use the no checksumming versions. I fixed that too. The canonical version should be pretty decent again now.
  11. planetbeing

    Driver for nForce4 LAN

    Guys, I don't really have the time to answer individual questions on the forum. You may have noticed that I was working on solving one specific issue: Namely, kernel panics under high load. Only Colonel had volunteered to test and without more testers, the effort has stalled. As for your questions, I really think they have all been addressed earlier in the thread: 1. If nothing comes up in dmesg after loading the kext, it's simply because the driver doesn't recognize the device id of your NIC. You'll have to edit Info.plist in the kext to insert yours. Instructions are everywhere. 2. If it still does not work, it's just not supported. Sorry. I don't know what's wrong. I don't have your hardware. I don't know how to fix it. I can rewrite the driver, porting from a newer version of forcedeth, but that's not guaranteed to solve your problem. It's also a massive effort and may not ever get started or done. 3. Tiger drivers work fine on Leopard, theoretically. I use Leopard, but I cross-compile the drivers to Tiger. They work fine on Leopard. Also, I get the impression that most people have gotten it working. The only definite issue I know about is simply that if you dual-boot, Windows may leave the NIC in an uninitializeable state. You might try disconnecting the power to the computer for 15 seconds, then rebooting into OS X only. That can be fixed after the kernel panics are resolved. mcsmart: I may have forgotten to update the Info.plist for nock properly. The dependencies section of the plist is probably the thing that is screwed up. You can fix it by copying it from the Info.plist of just the normal forcedeth or wait for me to do it.
  12. planetbeing

    Driver for nForce4 LAN

    It's not directly supported, but you can add the device id to the proper plist. Instructions ought to already be posted somewhere in this thread.
  13. planetbeing

    Driver for nForce4 LAN

    This version ought to report with "such-and-such function violated mutex" if a race condition occurs. Try it and see if any such messages appear. forcedeth.zip
  14. planetbeing

    Driver for nForce4 LAN

    Hmm. I believe it's no longer possible to have a race condition in the code, but I could be wrong. I will write a debug version that will make it possible to check for any race conditions. If there are none, then it's probably some other unidentified device driver bug, which would be difficult to fix.
  15. planetbeing

    Driver for nForce4 LAN

    So would you characterize it as a reduction in panics, or just about the same?
  16. planetbeing

    Driver for nForce4 LAN

    Yeah, the last version, I put the disable interrupt voodoo back into doNicPoll(). It's unclear why this is needed, as interrupts ought to be serialized with that function anyway. So the current list of changes are: - Changed IOBasicOutputQueue to IOGatedOutputQueue to serialize tx with everything else - Changed the way the IOWorkLoop is obtained: We now create our own explicitly, and this is now set as the work loop IONetworkController commands use. (previously, they may have been on separate work loops!) The real question is whether this works better than the really old version... does it? P.S.: The NIC ring full, stalling thing should be all right. Basically, the amount of packets that are being queued for sending is swamping the buffer of the NIC, so it's telling the OS not to bother it with more requests until there's more room in the buffer.
  17. planetbeing

    Driver for nForce4 LAN

    I feel like an optometrist. Is this better or worse? forcedeth.zip
  18. planetbeing

    Driver for nForce4 LAN

    Fun. -.- Hmm. Try this version. You'll still need to add in your device id. forcedeth.zip
  19. planetbeing

    Driver for nForce4 LAN

    No previous version of forcedeth was loaded? You do have a en0 device present. If no ethernet driver was present, that ought not exist.
  20. planetbeing

    Driver for nForce4 LAN

    Don't think this was taken right after the kextload happened. For example, here's what I get. It's also possible that for some reason, control was never passed to the driver at all. Perhaps another driver for the device was already loaded or something.
  21. planetbeing

    Driver for nForce4 LAN

    dmesg will show the kernel message buffer. When the message appears has nothing to do with whether dmesg will show it or not. More specific instructions: 1. Use kextunload to unload any old version of forcedeth that was loaded on startup. 2. Use kextload to load the new version of forcedeth 3. Check dmesg.
  22. planetbeing

    Driver for nForce4 LAN

    sudo dmesg
  23. planetbeing

    Driver for nForce4 LAN

    I compiled on Leopard, so that may be the problem. When does the kernel panic happen? What does "nothing" mean?
  24. planetbeing

    Driver for nForce4 LAN

    Here's the new version. Hopefully it does the trick. I'd appreciate testers. forcedeth.zip
  25. planetbeing

    Driver for nForce4 LAN

    I think I have a quick fix for this issue. I did some more research and the problem is a bit different than I had originally thought. It turned out that I did serialize interrupts with IOWorkLoop, but I did not serialize the transmission of the packets. The rest of the commands ought to be thread-safe as well, since they should be automatically serialized via a IOCommandGate on the provider's IOWorkLoop. The fix ought to be as simple as using an IOGatedOutputQueue instead of an IOBasicOutputQueue for the output packet queue. This should be the only change that is needed. Also, I don't see the need to disable interrupts in doNicPoll since everything is explicitly serialized, so that ought to be removed as well. I will compile a version later this afternoon, but I'll need testers to pound the {censored} out of the driver, since I currently use a wireless connection, not the ethernet nic.
×