Menu ▾ ▴

bugfix 65 lost in version control process

Help
Pieter Hoeben
2015-08-25
2015-09-23

  • Pieter Hoeben

    Pieter Hoeben - 2015-08-25

    Hi,

    Bug# 65 was solved, see commit R465 about adding an IPMODE_NONE. The bugfix
    is still present in commit R466. But it has been lost in commit R467. There
    is no comment on the bug fix being removed.

    Probably there was a bad merging of versions or version control went wrong.
    I think R467 is based on a version before R465. Can you add the fix again?

    Notice that other bug fixes may have gone lost too.

    Regards,
    Pieter Hoeben

     
    alternate

  • Wojciech Owczarek

    Wojciech Owczarek - 2015-08-25

    Hi,

    Can you confirm that the bug itself, #65, still exists and is still reproducible, or rather just the code is not what you're expecting it to be?

    Regards,
    Wojciech

     

    Last edit: Wojciech Owczarek 2015-08-25

  • Wojciech Owczarek

    Wojciech Owczarek - 2015-08-25

    Chances for a bad merge are very slim because there is only a handful of developers and we can see the diffs coming in if anything changes, plus everybody does pre-commit diffs and checks for updates before commits.

    This was a while ago but looking at the R467 commit, this was not a bad merge: I specifically removed IPMODE_NONE, because I found the idea confusing. What mode are you running when you configure IPMODE_NONE and disable the Ethernet transport? As far as I remember I just fixed the config file conditional macros for this to work properly, rather than by introducing IPMODE_NONE.

    I tried re-creating this just a second ago and I couldn't. Are you auditing the code / bugs or have you run into the actual bug in testing?

     

  • Pieter Hoeben

    Pieter Hoeben - 2015-09-22

    Here is what happens when I try to load new servo parameters (especially filters). I need to make it fast because we (I do consultance for Bosch Rexroth) are working with realtime servosystems and the customer does not want to wait minutes for the clock to stabilize.

    <test SIGHUP="" with="" identical="" parameters="">
    01:00:47 ptpd2[500]: SIGHUP received
    01:00:47 ptpd2[500]: Reloading configuration file: /tmp/ptpd2_slave.conf
    01:00:47 ptpd2[500]: Checking configuration
    01:00:47 ptpd2[500]: Configuration OK
    01:00:47 ptpd2[500]: Configuration unchanged
    01:00:51 ptpd2[500]: Clock servo now stable - took 35 seconds
    01:00:51 ptpd2[500]: Clock servo now stable - took 35 seconds
    <now test="" SIGHUP="" with="" updated="" parameters,="" the="" ptpd2_slave.conf="" has="" been="" changed="">
    01:02:28 ptpd2[500]: SIGHUP received
    01:02:28 ptpd2[500]: Reloading configuration file: /tmp/ptpd2_slave.conf
    01:02:28 ptpd2[500]: Checking configuration
    01:02:28 ptpd2[500]: Configuration OK
    01:02:28 ptpd2[500]: *** ptpd2: parseConfig returned NULL during config commit - this is a BUG - report the follow-ing:
    01:02:28 ptpd2[500]: Checking configuration
    01:02:28 ptpd2[500]: Configuration error: option "ptpengine:ip_mode=ethernet" cannot be used with option "ptpen-gine:ip_mode"
    01:02:28 ptpd2[500]: There are errors in the configuration - see previous messages
    01:02:28 ptpd2[500]:     **ptpd2 shutting down ****
    < we do not have "ptpengine:ip_mode=ethernet" in our .conf files>

    We only try to reload the conf file, that is all.

    Our version is based on 2.3.1

     

  • Wojciech Owczarek

    Wojciech Owczarek - 2015-09-22

    Hi,

    Can you provide the "before" and "after" configuration please so I can test?

    Thanks,
    Wojciech

     

  • Wojciech Owczarek

    Wojciech Owczarek - 2015-09-22

    Pieter,

    Since you are using a modified version, I can't be sure what modifications you made - are you absolutely sure that the file src/dep/daemonconfig.c is from 2.3.1? There were some issues with config conflict checks for ptpengine:transport and ptpengine:ip_mode but looking at 2.3.1 source, they should be disabled. When you set ptpengine:transport=ethernet, ip_mode is being ignored. You may be running an older source. Would you mind sharing your daemonconfig.c file?

    Again, I can't reproduce this issue when using Ethernet transport on 2.3.1.

     

  • Pieter Hoeben

    Pieter Hoeben - 2015-09-23

    Hi,

    The daemonconfig.cm and conf files are attached.

    In the slave .conf files we have:

    ptpengine:interface=eth0
    ptpengine:transport = ethernet
    ;ptpengine:ip_mode = <<< commented out so this is the default multicast
    ptpengine:use_libpcap = y
    ptpengine:delay_mechanism = E2E

    My goal is to let PTP synchronize quickly. So I want two servo/filter parameter sets, one for a fast start and a stable one during running. The SIGHUP issue makes this impossible.

    Regards,
    Pieter Hoeben

     
    daemonconfig.c
    ptpd2_slave_at-SIGHUP_for-sourceforge.conf
    ptpd2_slave_at-startup_for-sourceforge.conf

  • Wojciech Owczarek

    Wojciech Owczarek - 2015-09-23

    Pieter,

    Your daemonconfig.c is from ptpd 2.3.1-rc3, NOT from ptpd 2.3.1:

    wowczarek@wowczarek-desktop:~/ptpd-code/tags$ md5sum ptpd-2.3.1-rc3/src/dep/daemonconfig.c /guest/daemonconfig.c.pieter
2eb01444897d1d40674649a3c1cfdc02  ptpd-2.3.1-rc3/src/dep/daemonconfig.c
2eb01444897d1d40674649a3c1cfdc02  /guest/daemonconfig.c.pieter

    RC3 is from October 2014, final 2.3.1 is from June 2015. There have been significant changes inbetween. We do not support release candidates. You should update your code to the final 2.3.1 release. This issue is fixed in 2.3.1.

    If you need a quick fix for your current issue, just remove the following from daemonconfig.c - lines 1181...1187:

    #ifdef PTPD_PCAP
        /* ethernet mode - cannot specify IP mode */
        CONFIG_KEY_CONDITIONAL_CONFLICT("ptpengine:ip_mode",
                                    rtOpts->transport == IEEE_802_3,
                                    "ethernet",
                                    "ptpengine:ip_mode");
#endif

    Regards,
    Wojciech

     

Log in to post a comment.