* VIA VT1828S hda_intel errors @ 2009-10-30 1:05 Robert Hancock 2009-10-30 12:31 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Robert Hancock @ 2009-10-30 1:05 UTC (permalink / raw) To: Alsa-Devel; +Cc: Takashi Iwai, LydiaWang, Logan Li, Harald Welte 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 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? Also, disabling MSI for one occurrence of this seems a bit paranoid.. 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VIA VT1828S hda_intel errors 2009-10-30 1:05 VIA VT1828S hda_intel errors Robert Hancock @ 2009-10-30 12:31 ` Takashi Iwai 2009-11-01 20:03 ` Robert Hancock 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2009-10-30 12:31 UTC (permalink / raw) To: Robert Hancock; +Cc: Alsa-Devel, LydiaWang, Logan Li, Harald Welte 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VIA VT1828S hda_intel errors 2009-10-30 12:31 ` Takashi Iwai @ 2009-11-01 20:03 ` Robert Hancock 2009-11-02 10:27 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Robert Hancock @ 2009-11-01 20:03 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-Devel, LydiaWang, Logan Li, Harald Welte On Fri, Oct 30, 2009 at 6:31 AM, Takashi Iwai <tiwai@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).. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VIA VT1828S hda_intel errors 2009-11-01 20:03 ` Robert Hancock @ 2009-11-02 10:27 ` Takashi Iwai 2009-11-03 4:55 ` Robert Hancock 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2009-11-02 10:27 UTC (permalink / raw) To: Robert Hancock; +Cc: Alsa-Devel, LydiaWang, Logan Li, Harald Welte At Sun, 1 Nov 2009 14:03:18 -0600, Robert Hancock wrote: > > On Fri, Oct 30, 2009 at 6:31 AM, Takashi Iwai <tiwai@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? thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VIA VT1828S hda_intel errors 2009-11-02 10:27 ` Takashi Iwai @ 2009-11-03 4:55 ` Robert Hancock 2009-11-04 23:52 ` Robert Hancock 0 siblings, 1 reply; 7+ messages in thread From: Robert Hancock @ 2009-11-03 4:55 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-Devel, LydiaWang, Logan Li, Harald Welte On Mon, Nov 2, 2009 at 4:27 AM, Takashi Iwai <tiwai@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@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. 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VIA VT1828S hda_intel errors 2009-11-03 4:55 ` Robert Hancock @ 2009-11-04 23:52 ` Robert Hancock 2009-11-05 6:59 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Robert Hancock @ 2009-11-04 23:52 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-Devel, LydiaWang, Logan Li, Harald Welte On Mon, Nov 2, 2009 at 10:55 PM, Robert Hancock <hancockrwd@gmail.com> wrote: > On Mon, Nov 2, 2009 at 4:27 AM, Takashi Iwai <tiwai@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@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. > > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: VIA VT1828S hda_intel errors 2009-11-04 23:52 ` Robert Hancock @ 2009-11-05 6:59 ` Takashi Iwai 0 siblings, 0 replies; 7+ messages in thread From: Takashi Iwai @ 2009-11-05 6:59 UTC (permalink / raw) To: Robert Hancock; +Cc: Alsa-Devel, LydiaWang, Logan Li, Harald Welte At Wed, 4 Nov 2009 17:52:47 -0600, Robert Hancock wrote: > > On Mon, Nov 2, 2009 at 10:55 PM, Robert Hancock <hancockrwd@gmail.com> wrote: > > On Mon, Nov 2, 2009 at 4:27 AM, Takashi Iwai <tiwai@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@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 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-11-05 6:59 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-10-30 1:05 VIA VT1828S hda_intel errors Robert Hancock 2009-10-30 12:31 ` Takashi Iwai 2009-11-01 20:03 ` Robert Hancock 2009-11-02 10:27 ` Takashi Iwai 2009-11-03 4:55 ` Robert Hancock 2009-11-04 23:52 ` Robert Hancock 2009-11-05 6:59 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.