[alsa-devel] VIA VT1828S hda_intel errors

[Robert Hancock]

On Mon, Nov 2, 2009 at 10:55 PM, Robert Hancock <hancockrwd at gmail.com> wrote:
> On Mon, Nov 2, 2009 at 4:27 AM, Takashi Iwai <tiwai at suse.de> wrote:
>> At Sun, 1 Nov 2009 14:03:18 -0600,
>> Robert Hancock wrote:
>>>
>>> On Fri, Oct 30, 2009 at 6:31 AM, Takashi Iwai <tiwai at suse.de> wrote:
>>> > At Thu, 29 Oct 2009 19:05:15 -0600,
>>> > Robert Hancock wrote:
>>> >>
>>> >> I've been using the VT1828S codec support from ALSA git for the last few
>>> >> weeks. It seems to work fine, but there are some problems showing up in
>>> >> dmesg:
>>> >>
>>> >> Oct 25 20:46:14 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:683: No
>>> >> response from codec, disabling MSI: last cmd=0x02af0900
>>> >> Oct 25 20:46:15 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:698:
>>> >> azx_get_response timeout, switching to polling mode: last cmd=0x02af0900
>>> >
>>> > Note that this isn't always a severe problem.  If polling mode works
>>> > (you don't see the similar errors after this), it means the IRQ isn't
>>> > properly generated at verb handling.
>>> >
>>> >> It seems like the cmd isn't always the same, previously it was
>>> >> 0x024f0c00. Is there something bad about this command that could be
>>> >> causing the response timeout?
>>> >
>>> > Hm, both aren't really same, pointing to different widgets.  So,
>>> > it looks like a generic problem in the codec communication on your
>>> > board.
>>>
>>> Something VIA guys should look into?
>>
>> Hopefully.  This is a bit hard problem to track, though...
>>
>>> >> Also, disabling MSI for one occurrence of
>>> >> this seems a bit paranoid..
>>> >
>>> > MSI was unstable for long time, so disabling it was a sane option :)
>>> > Now it gets better, so it should be a second option.
>>> > I changed the code now.
>>> >
>>> >> Also saw one of these:
>>> >>
>>> >> Oct 26 21:13:20 newcastle kernel: hda-intel: IRQ timing workaround is
>>> >> activated for card #0. Suggest a bigger bdl_pos_adj.
>>> >>
>>> >> and PulseAudio also complained:
>>> >>
>>> >> Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: ALSA woke us
>>> >> up to write new data to the device, but there was actually nothing to write!
>>> >> Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: Most likely
>>> >> this is a bug in the ALSA driver 'snd_hda_intel'. Please report this
>>> >> issue to the ALSA developers.
>>> >> Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: We were woken
>>> >> up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0
>>> >> or another value < min_avail.
>>> >
>>> > Well, this is the case where the hardware reports bad position data.
>>> > This is usually a hardware bug, and hard to fix properly.  We have some
>>> > mechanism to correct or take back to the last position.  This should
>>> > usually work, but apparently not in your case...
>>>
>>> Well, it looks like PulseAudio complained before the IRQ timing
>>> workaround was activated (about 20 hours earlier)..
>>
>> Then try to pass bdl_pos_adj=0 option to snd-hda-intel module.
>> The PA complaining still present?
>
> With bdl_pos_adj=0, so far no complaints from PulseAudio after some
> hours of audio playing.. I'll keep monitoring it.

Nope, saw one again:

Nov  2 23:53:18 newcastle pulseaudio[6306]: alsa-sink.c: ALSA woke us
up to write new data to the device, but there was actually nothing to
write!
Nov  2 23:53:18 newcastle pulseaudio[6306]: alsa-sink.c: Most likely
this is a bug in the ALSA driver 'snd_hda_intel'. Please report this
issue to the ALSA developers.
Nov  2 23:53:18 newcastle pulseaudio[6306]: alsa-sink.c: We were woken
up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0
or another value < min_avail.

>
> Actually there's been no codec response timeout errors either since
> making that change, though I don't know if it's just by luck.. doesn't
> seem like it should be related.

Saw some more of these as well. Interestingly enough an ACPI GPE storm
was reported very close in time to it (same second in the log):

Nov  2 23:49:13 newcastle kernel: ACPI: EC: GPE storm detected,
transactions will use polling mode
Nov  2 23:49:13 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:683:
No response from codec, disabling MSI: last cmd=0x024f0c00
Nov  2 23:49:14 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:698:
azx_get_response timeout, switching to polling mode: last
cmd=0x024f0c00