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@xxxxxxx>
To: Enrico Mioso <mrkiko.rs@xxxxxxxxx>
Cc: hui.wang@xxxxxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, kailang@xxxxxxxxxxx
Subject: Re: 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
