On 18/03/2021 23:06, [email protected] 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: [email protected]
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/
_______________________________________________
users mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/users
