rtems-record-lttng: Corrupted timestamps after translating to CTF

[Sebastian Huber]

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 
clock driver.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
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:
https://embedded-brains.de/datenschutzerklaerung/