At Wed, 4 Nov 2009 17:52:47 -0600, Robert Hancock wrote: > > On Mon, Nov 2, 2009 at 10:55 PM, Robert Hancock <hancockrwd@xxxxxxxxx> wrote: > > On Mon, Nov 2, 2009 at 4:27 AM, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
