On Fri 2020-01-24 17:09:29, Eugeniu Rosca wrote: > Hi Geert, > > On Wed, Jan 22, 2020 at 08:48:12PM +0100, Geert Uytterhoeven wrote: > > 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 > > Slight amendment the above statement. Below results are got on R-Car > H3ULCB running renesas-drivers-2020-01-14-v5.5-rc6 (cX stands for CPUx, > whitespace stands for clean audio, '!' stands for distorted audio): > > printk @: > c0 c1 c2 c3 c4 c5 c6 c7 > speaker-test @ c0 ! > c1 ! ! > c2 ! ! > c3 ! ! > c4 ! ! > c5 ! ! > c6 ! ! > c7 ! ! > > One can see two patterns in the chart. The audio has glitches whenever: > - printk and the audio application run on the same CPU, or: > - printk runs on CPU0 The proper longterm solution seems to be offloading printk console handling to a kthread so that it can be bound to a particular CPU and does not block audio. Anyway, there is a question whether you really need to send all messages via the serial console. It might make sense to filter less important messages using "loglevel=" or "quiet" kernel parameters. The full log can be read later from userspace (dmesg, syslog, /dev/kmsg). Filtering can get disabled when debugging non-booting kernel. In this case, a distorted audio is the least problem. Best Regards, Petr
