rtems-record-lttng: Corrupted timestamps after translating to CTF
sebastian.huber at embedded-brains.de
Fri Mar 19 05:25:08 UTC 2021
On 18/03/2021 23:06, Jan.Sommer at dlr.de wrote:
>>> The to_bt_scaler is quite a large value and I don't fully get what it scales.
>> Does someone have some hints?
>> It could be related to ring buffer overflows. Do you get
>> RTEMS_RECORD_PER_CPU_OVERFLOW items? There could be also some
>> bugs in record-client.c. More unit tests for it would be helpful.
> I had some more time to look at this.
> It turns out that the RTEMS_RECORD_UPTIME_* events are always assigned to cpu 0.
> I checked the watchdog and indeed the _Record_Watchdog (https://git.rtems.org/rtems/tree/cpukit/libtrace/record/record-sysinit.c#n64) is executed twice, but always on cpu 0.
> I tested with the rv32imac bsp with 2 cores, each with its own RTEMS_SCHEDULER_PRIORITY_SMP and with the following defines:
> #define CONFIGURE_RECORD_PER_PROCESSOR_ITEMS 2048
> #define CONFIGURE_RECORD_EXTENSIONS_ENABLED
> #define CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB
> Do I need to configure something else? I am not familiar with the watchdog part. The initialization looks good as far as I can tell.
Ok, I thought you use the Zynq. In a production SMP system, the clock
driver interrupt must fire on all processors used by the system. That
the current RISC-V clock driver uses only the boot processor is a known
limitation and you see this in the smpclock01 test failure. I would fix
the clock driver and use an approach similar to the Arm Generic Timer
embedded brains GmbH
Herr Sebastian HUBER
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
More information about the users