Thank you, Richard. Should I submit patches relative to the ‘tcng7’ branch? Or should I wait until you submit your TC work to the master branch?
Thank you, Rodney On 8/7/17, 12:46 AM, "Richard Cochran" <[email protected]> wrote: Rodney, On Fri, Aug 04, 2017 at 09:15:14PM +0200, Richard Cochran wrote: > I am going to make this a bit easier for you and rebase the original > series onto the current git head. Then, you can concentrate on > expanding on them. Please clone the 'tcng7' branch from: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_richardcochran_linuxptp.git&d=DwIBAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=GpDaKX6ZCYlJYQKXBWKDc6GAcTGdVUE6GyC033rWmAk&m=M9FFcCjwp8NWvLBmne5FsOZUPiWpbEg8oELLPeqyNLE&s=VCm2PcabrX82k_gBlgRtAivEKNrJkX5oXZtyDO-aHgQ&e= I did some light testing on this, both under clknetsim and using real HW, namely i210 cards synchronized via their SDP pins. There is an open issue WRT fault handling. The current code checks if a port event has caused the port to enter the FAULTY state, but there is an implicit assumption that a fault on a particular port is only generated as a result of an event on that same port. In the new TC code, an frame arriving on port-1 might generate a fault on port-2 during forwarding. In this case, the fault timer for port-2 is never set, and thus the fault never clears. See clock_poll() in clock.c. Even so, I wanted to make this series available so you can make progress on the TAB stuff. We will deal with the fault issue soon enough. Thanks, Richard ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
