Jump to content

Driver for nForce4 LAN


  • Please log in to reply
764 replies to this topic

#21
planetbeing

planetbeing

    InsanelyMac Protégé

  • Members
  • PipPip
  • 95 posts
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.

#22
npwski

npwski

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts
  • Gender:Male
  • Location:Moscow, Russia
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.

#23
planetbeing

planetbeing

    InsanelyMac Protégé

  • Members
  • PipPip
  • 95 posts
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.

#24
johnzbesko

johnzbesko

    InsanelyMac Protégé

  • Members
  • Pip
  • 14 posts
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?

#25
planetbeing

planetbeing

    InsanelyMac Protégé

  • Members
  • PipPip
  • 95 posts
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.

#26
johnzbesko

johnzbesko

    InsanelyMac Protégé

  • Members
  • Pip
  • 14 posts
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>

#27
wkweksl

wkweksl

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male
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.

#28
npwski

npwski

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts
  • Gender:Male
  • Location:Moscow, Russia
planetbeing

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

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.


If you want, I can remove Intel from PCI-slot and disable Yukon in BIOS :D

#29
planetbeing

planetbeing

    InsanelyMac Protégé

  • Members
  • PipPip
  • 95 posts
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.

#30
npwski

npwski

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts
  • Gender:Male
  • Location:Moscow, Russia
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)

#31
wkweksl

wkweksl

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male
Pretty much the same issue as npwski. Only difference is that I'm at en0.

Attached Files



#32
planetbeing

planetbeing

    InsanelyMac Protégé

  • Members
  • PipPip
  • 95 posts
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.

#33
wkweksl

wkweksl

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

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.

#34
planetbeing

planetbeing

    InsanelyMac Protégé

  • Members
  • PipPip
  • 95 posts
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.

Attached Files



#35
np_

np_

  • Retired Developers
  • 339 posts
  • Gender:Male

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 :)

#36
borez

borez

    InsanelyMac Protégé

  • Members
  • PipPip
  • 60 posts

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.


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

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

#37
planetbeing

planetbeing

    InsanelyMac Protégé

  • Members
  • PipPip
  • 95 posts
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. :P

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. :D

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!

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 :)



@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).

#38
MatrixMan07

MatrixMan07

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
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

#39
ona2x

ona2x

    InsanelyMac Protégé

  • Members
  • Pip
  • 16 posts
Working perfect. :2cents: Thankz a lot.

#40
theSpam

theSpam

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 176 posts
  • Location:Toronto, Canada
  • Interests:Computing
Great work!

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





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy