Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About planetbeing

  • Rank
    InsanelyMac Protégé
  1. 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.
  2. Driver for nForce4 LAN

    Would've been helpful to see the log. :/
  3. 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.
  4. 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
  5. 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?
  6. 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.
  7. Driver for nForce4 LAN

    I meant for someone to implement. =P Here, give this a shot. No guarantees though. forcedeth.zip
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. Driver for nForce4 LAN

    So would you characterize it as a reduction in panics, or just about the same?
  15. 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.