[Linuxptp-devel] i210 doesn't want to eavesdrop on RX only ? (apologies for OT)
( once again my attachments were over the size limit, see them here: http://support.fccps.cz/download/adv/frr/tap/tap-schematic.pdf http://support.fccps.cz/download/adv/frr/tap/tap-board.pdf ) -- Dear gentlemen, apologies for this off-topic question. I should probably ask this in lkml or some specific Linux list at the vger, or electronics.stackexchange... yet, I've noticed some relevant souls in this list, maybe someone will know... In the context of my previously mentioned idea, to sync multiple i210 chips via external PPS for precise packet capturing/timestamping, I've built a prototype pseudo-passive Ethernet tap for 100Base-TX. Schematic and board layout are attached. The unrouted traces for power supply rails are implemented by wire bridges (and a section of symmetric 100-Ohms cable for the missing signal interconnect). The "straight through" direction is as free of stubs / impedance impurities as possible, and the "tap outputs" are buffered by analog amps (electric repeaters, not data buffers) to reconstruct the correct voltage. I've paid meticulous attention to impedance matching and series termination. The op-amps used do have the needed bandwidth. I can see beautiful waveforms on the output (when loaded=terminated by 100 Ohms at the input of my oscilloscope). An urban legend would have it, that Ethernet NIC's readily accept this sort of tap output, even from a simple wired splitter that's impedance-mismatched = suffers from lower voltage and reflections. I had my doubt, but wanted to try, and... it doesn't seem to work against an i210. The two peers in the straight-through direction connect just fine, I can see nice output on the tap-out jacks with a 'scope, but if I attach an i210 by a straight patch-cord, its link remains down. 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). The tap outputs are attached to pins 3 and 6 in the RJ45 (the green pair). I haven't tried yet to load the orange pair from the eavesdropping NIC. Makes me wonder if the NIC could wait for a 100 Ohms load on the TX pair. Not very likely to me... I actually have 2 pcs of the i210 currently in the bench system: one as a PTP slave, one for eavesdropping. I'm wondering if perhaps the i210 actually depends on the autoneg handshake for "link up", in spite of it being disabled via ethtool for speed and duplex negotiation. The autoneg handshake is two-way, in principle. Needs both directions to work between the handshaking PHY peers :-( I suspect that this is also an explanation why the i210 won't link against the Meinberg GM if I configure both ends for 100/full without autoneg. Maybe the i210 still awaits autoneg and won't link. If I configure both ends for autoneg, and just tell the i210 to advertise 100/full, the handshake happens and the link works perfectly. The autoneg handshake appears to be responsible for several "smart" features, such as the eee - i.e., it is no longer just a matter of speed+duplex :-/ Any ideas welcome... is there something I could tweak in the driver maybe, to make "autoneg off" actually remove any dependency on a bilateral handshake to bring the link up? Frank Rysanek WPM$BQ1R.PM$ Description: Mail message body -- 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
Re: [Linuxptp-devel] i210 doesn't want to eavesdrop on RX only ? (apologies for OT)
Hmm... maybe I should also take another look at common mode noise / signal grounding. Just in case. Frank On 24 Dec 2017 at 1:23, linuxptp-devel@lists.sourcefo wrote: > ( > once again my attachments were over the size limit, see them here: > http://support.fccps.cz/download/adv/frr/tap/tap-schematic.pdf > http://support.fccps.cz/download/adv/frr/tap/tap-board.pdf > ) > > -- > Dear gentlemen, > > apologies for this off-topic question. > I should probably ask this in lkml or some specific Linux list at the > > vger, or electronics.stackexchange... yet, I've noticed some relevant > > souls in this list, maybe someone will know... > > In the context of my previously mentioned idea, to sync multiple i210 > > chips via external PPS for precise packet capturing/timestamping, > I've built a prototype pseudo-passive Ethernet tap for 100Base-TX. > Schematic and board layout are attached. > The unrouted traces for power supply rails are implemented by wire > bridges (and a section of symmetric 100-Ohms cable for the missing > signal interconnect). > The "straight through" direction is as free of stubs / impedance > impurities as possible, and the "tap outputs" are buffered by analog > amps (electric repeaters, not data buffers) to reconstruct the > correct voltage. I've paid meticulous attention to impedance matching > > and series termination. The op-amps used do have the needed > bandwidth. I can see beautiful waveforms on the output (when > loaded=terminated by 100 Ohms at the input of my oscilloscope). > > An urban legend would have it, that Ethernet NIC's readily accept > this sort of tap output, even from a simple wired splitter that's > impedance-mismatched = suffers from lower voltage and reflections. > I had my doubt, but wanted to try, and... it doesn't seem to work > against an i210. > > The two peers in the straight-through direction connect just fine, > I can see nice output on the tap-out jacks with a 'scope, > but if I attach an i210 by a straight patch-cord, its link remains > down. > > 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). > > The tap outputs are attached to pins 3 and 6 in the RJ45 (the green > pair). > > I haven't tried yet to load the orange pair from the eavesdropping > NIC. Makes me wonder if the NIC could wait for a 100 Ohms load > on the TX pair. Not very likely to me... > > I actually have 2 pcs of the i210 currently in the bench system: one > as a PTP slave, one for eavesdropping. > I'm wondering if perhaps the i210 actually depends on the autoneg > handshake for "link up", in spite of it being disabled via ethtool > for speed and duplex negotiation. > The autoneg handshake is two-way, in principle. Needs both directions > > to work between the handshaking PHY peers :-( I suspect that this is > also an explanation why the i210 won't link against the Meinberg GM > if I configure both ends for 100/full without autoneg. Maybe the i210 > > still awaits autoneg and won't link. If I configure both ends for > autoneg, and just tell the i210 to advertise 100/full, the handshake > happens and the link works perfectly. The autoneg handshake appears > to be responsible for several "smart" features, such as the eee - > i.e., it is no longer just a matter of speed+duplex :-/ > > Any ideas welcome... is there something I could tweak in the driver > maybe, to make "autoneg off" actually remove any dependency on a > bilateral handshake to bring the link up? > > Frank Rysanek > > > Attachments: > C:\Users\frr\AppData\Local\Temp\WPM$BQ1R.PM$ -- 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
Re: [Linuxptp-devel] i210 doesn't want to eavesdrop on RX only ? (apologies for OT)
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
