[alsa-devel] VIA VT1828S hda_intel errors

Takashi Iwai tiwai at suse.de
Fri Oct 30 13:31:59 CET 2009


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.

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


Takashi


More information about the Alsa-devel mailing list