Wind River Support Network

Description

Where systemd prevented that the system date started since 01-01-1970. This was solved with the solution presented on case [LIN1018-4382|https://jira.wrs.com/browse/LIN1018-4382] 

However, the proposed solution above introduced a new problem on lttng. When using lttng to view traces, it reports the following errors:

[error] ctf_clock_declaration_visit: unexpected unary expression for clock offset

[error] ctf_visitor_construct_metadata: clock declaration error

[error] Error in CTF metadata constructor -22

[warning] Unable to open trace metadata for path "/tmp/csrpTrace/trace/ust/uid/0/32-bit".

[warning] [Context] Cannot open_trace of format ctf at path /tmp/csrpTrace/trace/ust/uid/0/32-bit.

[warning] [Context] cannot open trace "/tmp/csrpTrace/trace/ust/uid/0/32-bit" from /tmp/csrpTrace/trace for reading.

[error] Cannot open any trace for reading.

[error] opening trace "/tmp/csrpTrace/trace" for reading.

[error] none of the specified trace paths could be opened.

 

In the lttng file "metadata", offset of clock is negative:

clock {

name = "monotonic";

uuid = "f18ef9e3-93fb-432b-bd8c-2c0da378d22c";

description = "Monotonic Clock";

freq = 1000000000; /* Frequency, in Hz */

/* clock value offset from Epoch is: offset * (1/freq) */

offset = -40;

};

 

This is with lttng version 2.9.5

The customer suggest the following patch may be useful:

[https://lists.lttng.org/pipermail/lttng-dev/2016-February/025487.html]

 

 

Workaround

The attached patch [^0001-Revert-clock-offset-print-negative-value-in-metadata.patch] was provided to the customer as a workaround. This patch reverts a patch in lttng to restore a feature that sets the time offset at 0 if it is negative. The customer confirmed that it works to solve the issue, however, they rejected the solution because they don't want to modify the time offset and cause a possible time precision issue, so they are looking forward to the definitive solution with the babeltrace patch.

Steps to Reproduce

I tried to repro on qemu and a xilinx zcu102 board onsite but was unable to see the customer's issue. There are the steps I've followed:

1. In LTS18 project. Configure kernel to remove RTC support (in order to avoid any time synchronization) with "bitbake -c menuconfig linux-yocto" then disable Device Drivers>Real Time Clock.

2. Add to conf/local.conf:

EXTRA_OEMESON_append_pn-systemd = " -Dtime-epoch=0"

IMAGE_INSTALL_append = " lttng-tools lttng-modules lttng-ust babeltrace"

3. Boot target without network (to avoid time sync from kernel or systemd)

4. Login and use lttng to create trace session and trace anything (example with scheduler switch tracing):

lttng create
 lttng enable-event -k sched_switch
 lttng start
 lttng stop
 lttng destroy

5. Use lttng view. This should provoke the error due to the negative offset.

lttng view

6. Check metadata file from the lttng trace outputs and confirm the negative offset (example from customer's metadata)

clock

{ name = "monotonic"; uuid = "f18ef9e3-93fb-432b-bd8c-2c0da378d22c"; description = "Monotonic Clock"; freq = 1000000000; /* Frequency, in Hz */ /* clock value offset from Epoch is: offset * (1/freq) */ offset = -40; }

;