Hello Takashi.
In trying to narrow down things a little bit further, I wrote a dirty hack script, in an attempt to trigger the bug. So far results seems "encouraging": I was able to trigger the same behaviour. I am now running with all your 2 patches applied: the single_cmd=0 one and the #if 0 removal of that code snippet in hda_beep.c . My test script is stupid, and is as follows: svtest.sh .
#!/bin/sh while [ 1 ]; do new_volume=$(echo $RANDOM / 1000 | bc) sleep 41 beep mpc volume $new_volume sleep 41 new_volume=$(echo $RANDOM / 1000 | bc) mpc volume $new_volume done
Where: - "sleep" sleeps 1 second more than the 40 secs set for power down: this way I stress the power down / power up of the device - "mpc" is a Music Player Daemon client: the volume command tells the daemon to set the volume; alsamixer would reflect those changes. The desired effect was only to randomly change the volume. - the "beep" program is used for beeping: but I intentionally switched to another console running the test, thus the program would emit a normal "bell" (e.g. an \a sequence in the shell passed to the echo command the right way). Now the problem would be to narrow down things enough to have a trace snapshot in the right moment: but actually I don't know what I can do. I suspect that when I can see snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2b8000. -5 as is the case in this moment, it would be already "too late". I think this test was able to trigger the problem in two hours or so... Don't know.
Thank you for all Takashi, and all of you. Have a good sunday all guys. Enrico
On Sat, 14 Jan 2017, Takashi Iwai wrote:
Date: Sat, 14 Jan 2017 10:46:01 From: Takashi Iwai tiwai@suse.de To: Enrico Mioso mrkiko.rs@gmail.com Cc: hui.wang@canonical.com, alsa-devel@alsa-project.org, kailang@realtek.com Subject: Re: [alsa-devel] Intel HDA audio on EEE PC 1101HGo
On Sat, 14 Jan 2017 10:20:16 +0100, Enrico Mioso wrote:
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...
Yes, maybe the fallback to single cmd got broken somehow. I'd need to check with a fault injection.
In anyway, the verb is DIGI_CONVERT_2, and the only possible place is the beep setup.
Could you try the below to see whether it makes any difference?
Takashi
diff --git a/sound/pci/hda/hda_beep.c b/sound/pci/hda/hda_beep.c index c397e7da0eac..07930e69812a 100644 --- a/sound/pci/hda/hda_beep.c +++ b/sound/pci/hda/hda_beep.c @@ -228,9 +228,11 @@ int snd_hda_attach_beep_device(struct hda_codec *codec, int nid) return -ENOMEM; snprintf(beep->phys, sizeof(beep->phys), "card%d/codec#%d/beep0", codec->card->number, codec->addr); +#if 0 /* enable linear scale */ snd_hda_codec_write_cache(codec, nid, 0, AC_VERB_SET_DIGI_CONVERT_2, 0x01); +#endif
beep->nid = nid; beep->codec = codec;