[alsa-devel] VIA VT1828S hda_intel errors

[Robert Hancock]

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?

>
>> 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)..