Jump to content

Driver for nForce4 LAN


planetbeing
 Share

765 posts in this topic

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

planetbeing

 

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

nf4nic7hr.th.png

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

forcedeth.zip

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

# 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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Great work!

 

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

 

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

 Share

×
×
  • Create New...