On 24 Dec 2017 at 8:34, linuxptp-devel@lists.sourcefo wrote: > On 24 Dec 2017 at 1:23, linuxptp-devel@lists.sourcefo wrote: > > I've tried forcing 100 Mbit full duplex in the eavesdropping i210 and > > > > generally super-simple behavior: > > > > ethtool -s eth2 speed 100 duplex full autoneg off > > ethtool --set-eee eth0 eee off > > ethtool -A eth0 rx off rx off autoneg off > > ethtool -s eth2 mdix off (igb driver refuses this for full/100) > > ...and obviously ifconfig up. > > > > I've noticed that my distro's ethtool was a little stale (3.16) > > so I compiled 4.13 from source (the kernel is 4.13.12). > > Now I possibly get fewer errors from ethtool that "this combination > > of arguments is illegal", but still no go. > > > > I've tried mii-tool, but the net-tools package was last updated in > > 2010 or so, and the SIOCSMIIREG is apparently unsupported > > in e1000e and igb, only SIOCGMIIREG - so the ancient mii-tool > > is not much use, maybe as a check what ethtool has actually done > > (and not a very detailed check at that). > > > > Hmm... maybe I should also take another look at > common mode noise / signal grounding. Just in case. > ...and the outcome is: yes the problem was in reference ground noise.
Not sure if the mains transformer leaks a bit of something, or what the hell, but the truth is that I've seen before on a 'scope, that the tap output waveforms contained some common mode low-frequency garbage if I left the internal common ground float free. The "signal pair biasing" RL networks cannot take care of all the noise, I'd have to make the R too small (and I feel uncomfortable about that). Fortunately, simply connecting the tap's signal ground to the chassis of my probe computer seems to stabilize the ground enough that the buffered waveforms seem perfectly clear. And exactly that grounding link has helped me get the eavesdropping setup to work = after I linked the tap's internal GND to the nearby probe computer's chassis, the listening i210's link went up and tcpdump showed a waterfall of packets flying by. I actually got stuck (plugged the tap in and there was no link) just before calling it a day at work on Friday before X-mas :-) So I spent some christmas evenings studying the i210 datasheet, and trying things on the live animal. I've noticed the "energy detection" status bits in the i210 PHY and in the PHPM register (bar 0 reg 0x0E14). I found an easy way to peek and poke the IOMEM registers in bar 0, using the devmem2 utility. I was able to use that to poke things in the PHY via MII using the MDIC register (offset 0x0020). Peeks on the PHY are not feasible this way (via the MDIC), because a read attempt takes two transactions and something in the driver is always faster than I to slurp my result :-) but fortunately the mii-diag can do the PHY reads in a clean way. I tried stuff such as devmem2 0xdf100020 w 0x04105f70 ...to force the link up via MII PHYREG 16 (0x10) - did bring the link indication up, but no data was coming through (obviously, as I now know, as the payload was total garbage) mii-diag -v eth2 ...to see the effects of my configuration attempts in the PHY registers. I noticed that the "energy detection" bit stays up even if I unplug the RJ45 patch cord, so it's probably somewhat bogus anyway :-) And then I got back to work, did a few quick tests in the wiring, tried getting a forced 100Mbit link to come up with one way going through the tap instead of straight through, and then I tried the grounding... from then on, it's a problem solved. Much more work down the road to turn this into something useful in the context of my PTP trouble case. Frank ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
