[2.6.33-rc3] HDA works in polling mode

[2.6.33-rc3] HDA works in polling mode

[Tvrtko Ursulin]

Hi,

I have a AMD 785G motherboard where there is a worrying situation logged by 
ALSA drivers. Sound nevertheless works.

lspci:
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)

dmesg:
HDA Intel 0000:01:05.1: PCI INT B disabled                                                       
HDA Intel 0000:00:14.2: PCI INT A disabled                                                       
HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16                               
HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19                               
HDA Intel 0000:01:05.1: irq 28 for MSI/MSI-X                                                     
HDA Intel 0000:01:05.1: setting latency timer to 64                                              
hda-intel: azx_get_response timeout, switching to polling mode: last 
cmd=0x000f0000

I tried position_fix=0, 1 and 2 with no difference. I also tried enable_msi=0 to 
make it use IO-APIC interrupt. Then this error is not displayed, sound 
works, but again no interrupts are generated at least count is not growing in 
/proc/interrupts.

Please tell me what else I can try and what debugging info you need.

Thanks,

Tvrtko

Re: [2.6.33-rc3] HDA works in polling mode

[Takashi Iwai]

At Sat, 9 Jan 2010 10:22:17 +0000,
Tvrtko Ursulin wrote:
> 
> 
> Hi,
> 
> I have a AMD 785G motherboard where there is a worrying situation logged by 
> ALSA drivers. Sound nevertheless works.
> 
> lspci:
> 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
> 
> dmesg:
> HDA Intel 0000:01:05.1: PCI INT B disabled                                                       
> HDA Intel 0000:00:14.2: PCI INT A disabled                                                       
> HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16                               
> HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19                               
> HDA Intel 0000:01:05.1: irq 28 for MSI/MSI-X                                                     
> HDA Intel 0000:01:05.1: setting latency timer to 64                                              
> hda-intel: azx_get_response timeout, switching to polling mode: last 
> cmd=0x000f0000
> 
> I tried position_fix=0, 1 and 2 with no difference. I also tried enable_msi=0 to 
> make it use IO-APIC interrupt. Then this error is not displayed, sound 
> works, but again no interrupts are generated at least count is not growing in 
> /proc/interrupts.
> 
> Please tell me what else I can try and what debugging info you need.

The switching to polling mode itself isn't a big problem at all.
This can be usually ignored.  If you have any other issues wrt sound
quality, just ignore this.


thanks,

Takashi

Re: [2.6.33-rc3] HDA works in polling mode

[Tvrtko Ursulin]

On Tuesday 12 Jan 2010 08:50:26 Takashi Iwai wrote:
> At Sat, 9 Jan 2010 10:22:17 +0000,
> 
> Tvrtko Ursulin wrote:
> > Hi,
> >
> > I have a AMD 785G motherboard where there is a worrying situation logged
> > by ALSA drivers. Sound nevertheless works.
> >
> > lspci:
> > 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
> >
> > dmesg:
> > HDA Intel 0000:01:05.1: PCI INT B disabled
> > HDA Intel 0000:00:14.2: PCI INT A disabled
> > HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> > HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> > HDA Intel 0000:01:05.1: irq 28 for MSI/MSI-X
> > HDA Intel 0000:01:05.1: setting latency timer to 64
> > hda-intel: azx_get_response timeout, switching to polling mode: last
> > cmd=0x000f0000
> >
> > I tried position_fix=0, 1 and 2 with no difference. I also tried
> > enable_msi=0 to make it use IO-APIC interrupt. Then this error is not
> > displayed, sound works, but again no interrupts are generated at least
> > count is not growing in /proc/interrupts.
> >
> > Please tell me what else I can try and what debugging info you need.
> 
> The switching to polling mode itself isn't a big problem at all.
> This can be usually ignored.  If you have any other issues wrt sound
> quality, just ignore this.

Hi,

Yes sounds quality seems OK. So there are no performance issues with polling? 
Messages as this usually raise attention so if it is normal I suggest changing 
the message to something less alarming.

Thanks,

Tvrtko

Re: [2.6.33-rc3] HDA works in polling mode

[Takashi Iwai]

At Tue, 12 Jan 2010 22:53:51 +0000,
Tvrtko Ursulin wrote:
> 
> On Tuesday 12 Jan 2010 08:50:26 Takashi Iwai wrote:
> > At Sat, 9 Jan 2010 10:22:17 +0000,
> > 
> > Tvrtko Ursulin wrote:
> > > Hi,
> > >
> > > I have a AMD 785G motherboard where there is a worrying situation logged
> > > by ALSA drivers. Sound nevertheless works.
> > >
> > > lspci:
> > > 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
> > >
> > > dmesg:
> > > HDA Intel 0000:01:05.1: PCI INT B disabled
> > > HDA Intel 0000:00:14.2: PCI INT A disabled
> > > HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> > > HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> > > HDA Intel 0000:01:05.1: irq 28 for MSI/MSI-X
> > > HDA Intel 0000:01:05.1: setting latency timer to 64
> > > hda-intel: azx_get_response timeout, switching to polling mode: last
> > > cmd=0x000f0000
> > >
> > > I tried position_fix=0, 1 and 2 with no difference. I also tried
> > > enable_msi=0 to make it use IO-APIC interrupt. Then this error is not
> > > displayed, sound works, but again no interrupts are generated at least
> > > count is not growing in /proc/interrupts.
> > >
> > > Please tell me what else I can try and what debugging info you need.
> > 
> > The switching to polling mode itself isn't a big problem at all.
> > This can be usually ignored.  If you have any other issues wrt sound
> > quality, just ignore this.
> 
> Hi,
> 
> Yes sounds quality seems OK. So there are no performance issues with polling?

It might be, but usually negligible.
 
> Messages as this usually raise attention so if it is normal I suggest changing 
> the message to something less alarming.

It's certainly a thing that should raise attention.  It means that
something is actually wrong.  But, not that too wrong to fix
urgently.


Takashi