Hi Eugeniu,

On Wed, Jan 22, 2020 at 5:59 PM Eugeniu Rosca [off-list ref] wrote:

On Wed, Jan 22, 2020 at 08:31:44AM +0100, Geert Uytterhoeven wrote:

quoted

On Wed, Jan 22, 2020 at 3:34 AM Eugeniu Rosca [off-list ref] wrote:

quoted

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@linux-m68k.org

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