r8169: No network access with newer hardware revision

[warpuser]

The r8169 driver from may 2013 is loaded fine and lantran.log shows no error. The IP setup of the network interface is also ok. The localhost interface is working but access to other hosts on the network fails (e.g. with ping). RtlChipId shows that the hardware revision for this device is 39. Using an older adapter with hardware revision 32 works without any problems.

[psmedley]

You might want to try ​http://smedley.id.au/tmp/r8169-3.12.8.zip which has the r8169 code updated to the most recent linux kernel level.

[David Azarewicz]

please read the debugging page ​http://svn.ecomstation.nl/multimac/wiki/Debugging%20Guide and attach a testlog log file as required.

[lewisr]

This may be tied to the issue of the driver not getting a MAC from the hardware and none being assigned in PROTOCOL.INI.

I am dealing with this very issue right now. netstat -n shows ffffffffffff for the MAC. Both r8169-1.0.0-BETA-20140202 and Paul's r8169-3.12.8 initialized properly, but we got no MAC. Both work when a MAC is manually configured in PROTOCOL.INI.

I have not had time to run the trace version of the driver and get any real debugging info from this machine, as I must return it to my client this evening (new system board), but I will make arrangements to either get it back or will order similar parts and build a test machine for this in the coming weeks.

[warpuser]

First thanks for everyone that is working on the drivers and for the comments. The mac address was never a problem, the driver always could get the right mac address. I tried again with Pauls r8169-3.12.8.zip driver and could now see what was going on. I opened a cmd window and then start ping to another host but the ping was never answered, now by moving the mouse on the desktop (not on this window) made the ping somehow work:

64 bytes from 10.10.0.1: icmp_seq=112. time=465410. ms
64 bytes from 10.10.0.1: icmp_seq=113. time=464400. ms
64 bytes from 10.10.0.1: icmp_seq=114. time=463390. ms
64 bytes from 10.10.0.1: icmp_seq=115. time=462380. ms
64 bytes from 10.10.0.1: icmp_seq=116. time=461370. ms

The connection was not in a usable state and i switched the usb drivers to newer or older without a change in this case.
I then tried the latest beta driver r8169-1.0.0-BETA-20140211.wpi from David with the same result. Switching the system from the pic to apic mode surprisingly made all test drivers now work and data transfers are ok for the moment.

[David Azarewicz]

Interrupt issues such as you are describing have been seen before, primarily on Dell hardware, and indicates that your system has defective or non-standard interrupt logic. It has nothing to do with any drivers.

I find it extremely odd that you would choose to override the defaults and run you system in PIC mode when you have APIC hardware available. The best way to run the PSD is with no switches at all.