[alsa-devel] VIA VT1828S hda_intel errors

[Takashi Iwai]

At Wed, 4 Nov 2009 17:52:47 -0600,
Robert Hancock wrote:
> 
> 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.

OK.  Some pulseaudio black magic here.

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

It's still older version.  The latest one turns off polling mode
first.


Takashi