| Message ID | s5hr346ht46.wl-tiwai@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
I tried to modprobe -r the module at some point... the system did actually panic I think. the system wasn't able to reboot in this case. So, don't know why ... but something might be going wrong. Anyway... I was alone and not able to read the screen, easily at least. Now I rebooted in the kernel with your modification, where digit_convert_2 verb was omitted with #if 0 . I'll let you know. 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; >
Thank you very much to all of you, Takashi. Enrico Mioso Mobile Phone Number: +393807096934 ( +Telegram :) ) My Tox ID is: 7C593F402A3C8632D87AB4B948D492294C39A6A614464ECF843CA3429FB023284180472C7475 I like / recommend the usage of open messaging standards. 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; >
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; >
Hello all guys, hellokind Takashi. So, first of all I would like to thank you. At the end, at least unless some stuning revelation arrives, I think we can let go of this thing. But I still like the modification you did regarding the single_cmd fallback: and I would propose to still upstream it. Tested-By: Enrico Mioso <mrkiko.rs@gmail.com> I like it for two reasons: 1 - I think that, no matter in this case, avoiding a crash is fine. 2 - I apreciated your work and assistance + help. this patch might also be useful for others. thank you, really. Enrico Enrico Mioso Mobile Phone Number: +393807096934 ( +Telegram :) ) My Tox ID is: 7C593F402A3C8632D87AB4B948D492294C39A6A614464ECF843CA3429FB023284180472C7475 I like / recommend the usage of open messaging standards. 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; >
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;