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 ? Regards, Hans
