On Tue, 21 Mar 2017, at 08:19 PM, Hans de Goede wrote: > Hi, > > On 21-03-17 10:04, Arun Raghavan wrote: > > > > > > On Tue, 21 Mar 2017, at 02:26 PM, Hans de Goede wrote: > >> Hi, > >> > >> On 21-03-17 08:54, Arun Raghavan wrote: > >>> On Tue, 21 Mar 2017, at 11:10 AM, Takashi Iwai wrote: > >>>> On Tue, 21 Mar 2017 00:09:22 +0100, > >>>> Pierre-Louis Bossart wrote: > >>>>> > >>>>> On 3/20/17 4:52 AM, Takashi Iwai wrote: > >>>>>> On Mon, 20 Mar 2017 12:42:58 +0100, > >>>>>> Hans de Goede wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Lately I've been working on fixing various issues people > >>>>>>> are having with baytrail / cherrytrail devices. One thing > >>>>>>> I noticed when moving my testing / development to 4.11 is > >>>>>>> that pulseaudio does not work (it aborts while starting) > >>>>>>> this seemed to be caused by the new snd_hdmi_lpe_audio > >>>>>>> module. If I blacklist that all is fine. Any idea what > >>>>>>> is causing this ? > >>>>>> > >>>>>> I noticed it once, too, but I had no time to check further. > >>>>>> More interestingly, PA works fine when LPE audio is the single driver > >>>>>> (i.e. blacklist Intel SST instead), too. So it's more likely a bug in > >>>>>> PA. > >>>>>> > >>>>>> What happens when you modprobe LPE audio driver after starting the > >>>>>> session? If it kills PA, we can debug more easily :) > >>>>> > >>>>> I've seen this as well, I could get either one of the two but not > >>>>> both, could this be due to the fact that one set of mixers is > >>>>> configured with UCM and the other driver isn't configured by UCM? > >>>> > >>>> No idea, and I had still no time to check (still processing the > >>>> pile of pending mails and other bugs :). Let me add PA guys to Cc. > >>> > >>> Not sure if anyone here has the hardware and I haven't seen any > >>> complaints either -- having a backtrace (or even location of the assert) > >>> would be a good start. > >> > >> Ok, this is weird. Since you were asking for more info I tried to > >> collect a backtrace / logs. But what is happening is that after > >> the snd_hdmi_lpe_audio module loads, pulse does its thing and > >> then exits with a message of "killed" in gdb / on the terminal > >> from which I started it. I don't get a chance to get a backtrace > >> in gdb ... So this does feel like a kernel bug to me, normally > >> this sort of "killed" behavior is seen on some kernel oopses... > >> > >> But dmesg is free of any oopses ? > >> > >> Anyways here is a log of pulseaudio -v first without the > >> hdmi module and then the module gets probed. Where the log > >> abruptly ends is where I got the "Killed" message on the > >> terminal. > > > > That's the kernel killing of PA for exceeding RT limits (there's a patch > > in the timers tip that'll now provide an error in dmesg). > > > > It sounds possible that there is some call to the ALSA API that we are > > making that results in the driver blocking for long enough to exceed the > > RT limit. You can verify this by setting 'realtime-scheduling = no' in > > /etc/pulse/daemon.conf and then starting PA. > > > > If that works, > > Yep that works, good call. > > > perf will likely be able to show you what's blocking. > > I'm not all that familiar with perf, can you provide me with > a perf cmdline to start pulseaudio with which will generate a log > file with the info you are looking for ? I'm no perf expert myself, but I'd start with: 1. sudo perf sched record 2. Start PA in another tab 3. sudo perf sched latency > latency.txt The latency report should show you at what time the maximum delay occurred and how large it was. Thinking about it, a simple 'perf record pulseaudio' and 'perf report' might also tell you where CPU time was spent. Cheers, Arun
