[alsa-devel] HDA timeouts
Hi,
Sometimes (1 in 5 boots) I see the following: azx_get_response timeout, switching to polling mode: last cmd=0x014f0900
I initially blamed MSI that I enabled explicitly. If it is enabled, there is another timeout just before this line. Now I explicitly disable msi, and still see this.
It seems that codec hangs or so.
my codec#0 attached.
Best regards, Maxim Levitsky
On Sat, 2009-11-07 at 21:06 +0200, Maxim Levitsky wrote:
Hi,
Sometimes (1 in 5 boots) I see the following: azx_get_response timeout, switching to polling mode: last cmd=0x014f0900
I initially blamed MSI that I enabled explicitly. If it is enabled, there is another timeout just before this line. Now I explicitly disable msi, and still see this.
It seems that codec hangs or so.
my codec#0 attached.
Best regards, Maxim Levitsky
I also filled a bugreport: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4796
Best regards, Maxim Levitsky
At Sat, 07 Nov 2009 21:06:54 +0200, Maxim Levitsky wrote:
Hi,
Sometimes (1 in 5 boots) I see the following: azx_get_response timeout, switching to polling mode: last cmd=0x014f0900
I initially blamed MSI that I enabled explicitly. If it is enabled, there is another timeout just before this line. Now I explicitly disable msi, and still see this.
It seems that codec hangs or so.
Unless it switches to the single_cmd mode, this isn't so serious at all. Usually this is a problem of either the timing or that the IRQ isn't generated by the chip properly. But the communication via CORB/RIRB still works usually, so the driver runs fine in the polling mode.
thanks,
Takashi
On Sun, 2009-11-08 at 09:06 +0100, Takashi Iwai wrote:
At Sat, 07 Nov 2009 21:06:54 +0200, Maxim Levitsky wrote:
Hi,
Sometimes (1 in 5 boots) I see the following: azx_get_response timeout, switching to polling mode: last cmd=0x014f0900
I initially blamed MSI that I enabled explicitly. If it is enabled, there is another timeout just before this line. Now I explicitly disable msi, and still see this.
It seems that codec hangs or so.
Unless it switches to the single_cmd mode, this isn't so serious at all. Usually this is a problem of either the timing or that the IRQ isn't generated by the chip properly. But the communication via CORB/RIRB still works usually, so the driver runs fine in the polling mode.
Yes, it does work fine, but it disables MSI first, although its not to blame...
Any ideas, about what can be the cause of the hang?
Its not the timing, I increased the timeout to 10 seconds, and got same results.
Best regard, Maxim Levitsky
At Sun, 08 Nov 2009 19:53:29 +0200, Maxim Levitsky wrote:
On Sun, 2009-11-08 at 09:06 +0100, Takashi Iwai wrote:
At Sat, 07 Nov 2009 21:06:54 +0200, Maxim Levitsky wrote:
Hi,
Sometimes (1 in 5 boots) I see the following: azx_get_response timeout, switching to polling mode: last cmd=0x014f0900
I initially blamed MSI that I enabled explicitly. If it is enabled, there is another timeout just before this line. Now I explicitly disable msi, and still see this.
It seems that codec hangs or so.
Unless it switches to the single_cmd mode, this isn't so serious at all. Usually this is a problem of either the timing or that the IRQ isn't generated by the chip properly. But the communication via CORB/RIRB still works usually, so the driver runs fine in the polling mode.
Yes, it does work fine, but it disables MSI first, although its not to blame...
The logic was changed in the latest code. Now switched to the polling mode before disabling MSI.
Any ideas, about what can be the cause of the hang?
Its not the timing, I increased the timeout to 10 seconds, and got same results.
If so, it should have something to do with the interrupts. The difference between the normal mode and the polling mode is that the former expects and waits for the RIRB interrupt while the latter polls actively.
thanks,
Takashi
participants (2)
-
Maxim Levitsky -
Takashi Iwai