Hi Eugeniu, On Wed, Jan 22, 2020 at 5:59 PM Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote: > On Wed, Jan 22, 2020 at 08:31:44AM +0100, Geert Uytterhoeven wrote: > > On Wed, Jan 22, 2020 at 3:34 AM Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote: > > > So, what's specific to R-Car3, based on my testing, is that the issue > > > can only be reproduced if the printk storm originates on CPU0 (it does > > > not matter if from interrupt or task context, both have been tested). If > > > the printk storm is initiated on any other CPU (there are 7 secondary > > > ones on R-Car H3), there is no regression in the audio quality/latency. > > > > The secure stuff is running on CPU0, isn't it? > > Is that a coincidence? > > Nobody has ruled this out so far. As a side note, except for the ARMv8 > generic IPs, there seems to be quite poor IRQ balancing between the > CPU cores of R-Car H3 (although this might be unrelated to the issue): > > $ cat /proc/interrupts | egrep -v "(0[ ]*){8}" > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 > 3: 55879 17835 14132 33882 6626 4331 6710 4532 GICv2 30 Level arch_timer > 16: 1 0 0 0 0 0 0 0 GICv2 38 Level e6052000.gpio > 32: 203 0 0 0 0 0 0 0 GICv2 51 Level e66d8000.i2c > 33: 95 0 0 0 0 0 0 0 GICv2 205 Level e60b0000.i2c > 94: 19339 0 0 0 0 0 0 0 GICv2 71 Level eth0:ch0:rx_be > 112: 20599 0 0 0 0 0 0 0 GICv2 89 Level eth0:ch18:tx_be > 118: 2 0 0 0 0 0 0 0 GICv2 95 Level eth0:ch24:emac > 122: 442092 0 0 0 0 0 0 0 GICv2 196 Level e6e88000.serial:mux > 124: 2776685 0 0 0 0 0 0 0 GICv2 352 Level ec700000.dma-controller:0 > 160: 2896 0 0 0 0 0 0 0 GICv2 197 Level ee100000.sd > 161: 5652 0 0 0 0 0 0 0 GICv2 199 Level ee140000.sd > 162: 147 0 0 0 0 0 0 0 GICv2 200 Level ee160000.sd > 197: 5 0 0 0 0 0 0 0 GICv2 384 Level ec500000.sound > 208: 1 0 0 0 0 0 0 0 gpio-rcar 11 Level e6800000.ethernet-ffffffff:00 > IPI0: 12701 366358 545059 1869017 9817 8065 9327 10644 Rescheduling interrupts > IPI1: 21 34 111 86 238 191 149 161 Function call interrupts > IPI5: 16422 709 509 637 0 0 3346 0 IRQ work interrupts Yeah, cpu0 is always heavily loaded w.r.t. interrupts. Can you reproduce the problem after forcing all interrupts to e.g. cpu1? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds