Re: VIA VT1828S hda_intel errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux