[alsa-devel] Intel HDA audio on EEE PC 1101HGo

[Enrico Mioso]

Hello Takashi,
thank you very much again for your kindness and patience...

I'll enable the tracepoint.
Discrepancies in the single_cmd value are derived from the fact that I am still using the hackish version of the patch, since I didn't reboot... otherwise I should have started from scratch some very-long operations.
But the value has remained to 0, and the fallback didn't happen, as expected.

Ok, reading note.rst now.
I was wondering, but I may well be wrong: in the past that fallback code brought my system to single cmd mode after polling... Now it crashes, and as I said before, the switching from polling to last_cmd is kind-of immediate most of the times these days (e.g.: on this kernel).
May be something goes wrong in the fallback path? Or is this caused by an invalid verb ?
Guessing verb = something like a command...
Thank you again,
Enrico

On Sat, 14 Jan 2017, Takashi Iwai wrote:

> Date: Sat, 14 Jan 2017 09:44:12
> From: Takashi Iwai <tiwai at suse.de>
> To: Enrico Mioso <mrkiko.rs at gmail.com>
> Cc: hui.wang at canonical.com, alsa-devel at alsa-project.org, kailang at realtek.com
> Subject: Re: [alsa-devel] Intel HDA audio on EEE PC 1101HGo
> 
> On Fri, 13 Jan 2017 20:42:06 +0100,
> Enrico Mioso wrote:
>>
>> Hello guys.
>> I finally can report some interesting news.
>> Now audio stopped working - still, the system didn't panic. So I consider this a good good point.
>> My system is alive and I can keep it alive indefinitely, clearly if hardware doesn't break and/or other events out of my control cause an interruption.
>>
>> In my dmesg, the following messages started to appear:
>> snd_hda_intel 0000:00:1b.0: azx_get_response timeout, switching to polling mode: last cmd=0x020c0000
>
> I suppose the last_cmd value isn't always same?
>
>> snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x1f0e00. -5
>
> Hm, this might be an invalid verb.
>
>> And they appear apparently when the driver tries to send new commands to the device, but this is only my impression.
>> Let me know what I could do to report on what's happening. My system is acually running with kdump active, so in case I may also invoke the crash sysrq action and send back results.
>
> When a crash no longer happens, kdump isn't needed.  Instead, we need
> to track what triggers the stall.
>
> Try to enable the tracepoint, as mentioned in
> Documentation/sound/hd-audio/notes.rst.
>
>
> thanks,
>
> Takashi
>