At Mon, 21 Dec 2009 20:08:34 +0100,
Éric Piel wrote:
>
> Op 21-12-09 19:12, Maciej Rutecki schreef:
> > 2009/12/21 Takashi Iwai <tiwai@xxxxxxx>:
> >> At Sun, 20 Dec 2009 18:27:45 +0100,
> >> Maciej Rutecki wrote:
> >>>
> >>> Hi
> >>>
> >>> Affected kernel: 2.6.33-rc1
> >>> Last known good: 2.6.32
> >>
> >> The only fundamental change, AFAIK, is the use of MSI as default.
> >> Could you try to add enable_msi=0 option to snd-hda-intel?
> >>
> >
> > root@gumis:/# cat /sys/module/snd_hda_intel/parameters/enable_msi
> > 0
> >
> > Still the same:
> > ps aux:
> >
> > root 1117 27.4 0.0 0 0 ? S 19:00 2:05 [hd-audio0]
> >
> > I also notice short sound during booting system, when sound modules is
> > loading. I can try bisection, but in next week; already I don't have
> > to much time.
> Hello,
> I've got the same problem here (high hd-audio0 usage + clicks in the
> output sound).
>
> Hardware is identical:
> /proc/asound/pcm
> 00-00: AD198x Analog : AD198x Analog : playback 1 : capture 1
>
> I haven't tried the enable_msi parameter but, just to give more info,
> here is the log ("dmesg | grep -i hda") when the bug happens:
> Dec 18 10:39:10 dutifh kernel: HDA Intel 0000:00:1b.0: power state
> changed by ACPI to D0
> Dec 18 10:39:10 dutifh kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI
> 17 (level, low) -> IRQ 17
> Dec 18 10:39:10 dutifh kernel: input: HDA Digital PCBeep as
> /devices/pci0000:00/0000:00:1b.0/input/input12
> Dec 18 10:39:10 dutifh kernel: hda-intel: azx_get_response timeout,
> switching to polling mode: last cmd=0x006f0900
>
> And here is with 2.6.32, working fine
> Dec 18 11:46:03 dutifh kernel: HDA Intel 0000:00:1b.0: power state
> changed by ACPI to D0
> Dec 18 11:46:03 dutifh kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI
> 17 (level, low) -> IRQ 17
> Dec 18 11:46:03 dutifh kernel: input: HDA Digital PCBeep as
> /devices/pci0000:00/0000:00:1b.0/input/input11
>
> Could it be coming from this timeout?
It shouldn't. The polling mode doesn't give any behavioral change,
and the CPU usage can't be that high.
Try is to pass bdl_pos_adj=0 option. This should reduce the CPU hog,
at least. But it doesn't mean it's the right fix...
Another thing to try is to replace the whole HD-audio stack with the
last working one (was it 2.6.32?), and check whether it works with
2.6.32 core.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
