[2.6.33-rc1] [SOUND] HDA: high cpu usage, noise
Maciej Rutecki
Affected kernel: 2.6.33-rc1
Last known good: 2.6.32
Hadware:
/proc/asound/pcm
00-00: AD198x Analog : AD198x Analog : playback 1 : capture 1
00-06: Si3054 Modem : Si3054 Modem : playback 1 : capture 1
I notice high cpu load during idle/playing sounds. From "ps aux":
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1119 26.4 0.0 0 0 ? R 18:09 1:47 [hd-audio0]
Also I hear noise, during (probably) disk I/O operations. Any suggestions?
cat /proc/interrupts
CPU0 CPU1
0: 58385 0 IO-APIC-edge timer
1: 77 201 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc0
9: 67 117 IO-APIC-fasteoi acpi
12: 157 14303 IO-APIC-edge i8042
14: 1625 0 IO-APIC-edge ata_piix
15: 0 0 IO-APIC-edge ata_piix
16: 1115 0 IO-APIC-fasteoi i915@pci:0000:00:02.0, eth0
18: 0 0 IO-APIC-fasteoi yenta, uhci_hcd:usb4
19: 1 0 IO-APIC-fasteoi ohci1394, uhci_hcd:usb5
20: 146 2 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
27: 4013 10861 PCI-MSI-edge ahci
28: 3452 0 PCI-MSI-edge iwl3945
29: 1556997 0 PCI-MSI-edge HDA Intel
NMI: 0 0 Non-maskable interrupts
LOC: 16143 35244 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 27154 126864 Rescheduling interrupts
CAL: 59 34 Function call interrupts
TLB: 899 748 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
ERR: 0
MIS: 0
Config, dmesg and lspci:
http://unixy.pl/maciek/download/kernel/2.6.33-rc1/gumis/
--
Maciej Rutecki
http://www.maciek.unixy.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Takashi Iwai
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?
thanks,
Takashi
Maciej Rutecki
> 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.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
Éric Piel
> 2009/12/21 Takashi Iwai <ti...@suse.de>:
>> 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.
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?
Eric
Takashi Iwai
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
Éric Piel
> At Mon, 21 Dec 2009 20:08:34 +0100,
> Éric Piel wrote:
>> 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.
Could you give more details on how to do this?
Does it consist in taking the sound/ directory of 2.6.32 and copying it
over 2.6.33-rc1 ? Or less files?
Eric
Takashi Iwai
Éric Piel wrote:
>
> Op 22-12-09 08:04, Takashi Iwai schreef:
> > At Mon, 21 Dec 2009 20:08:34 +0100,
> > Éric Piel wrote:
> :
> >> 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...
> I'll try
>
> >
> > 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.
> Could you give more details on how to do this?
> Does it consist in taking the sound/ directory of 2.6.32 and copying it
> over 2.6.33-rc1 ? Or less files?
I'd try first only sound/pci/hda/* files.
Takashi
Takashi Iwai
Éric Piel wrote:
>
> Op 22-12-09 10:17, Takashi Iwai schreef:
> :
> >>> 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...
> >> I'll try
> the CPU used, as before.
> $ cat bdl_pos_adj
> 0,-1,-1,-1,-1,-1,-1,-1
>
> Could it be coming from the beeper? Also, just in case it can help,
> attached is my .config .
Do you have multiple HD-audio devices? See /proc/asound/cards.
If there are multiple, you need to pass a value for each.
Éric Piel
:
>
> Do you have multiple HD-audio devices? See /proc/asound/cards.
> If there are multiple, you need to pass a value for each.
# cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xe0624000 irq 17
So I guess there is only one device.
Eric
Éric Piel
:
>>> last working one (was it 2.6.32?), and check whether it works with
>>> 2.6.32 core.
>> Could you give more details on how to do this?
>> Does it consist in taking the sound/ directory of 2.6.32 and copying it
>> over 2.6.33-rc1 ? Or less files?
>
> I'd try first only sound/pci/hda/* files.
>
the problem.
When I find time, I'll try to git bisect on this particular directory...
but anyone willing to try to beat me at this is welcome, as Christmas is
going to keep me rather busy ;-)
Eric
Takashi Iwai
Éric Piel wrote:
>
> Op 22-12-09 10:17, Takashi Iwai schreef:
> :
> >>> 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.
> >> Could you give more details on how to do this?
> >> Does it consist in taking the sound/ directory of 2.6.32 and copying it
> >> over 2.6.33-rc1 ? Or less files?
> >
> > I'd try first only sound/pci/hda/* files.
> >
> Brute-force reverting these files to the version of 2.6.32.2 does fix
> the problem.
OK, that's good to know.
> When I find time, I'll try to git bisect on this particular directory...
> but anyone willing to try to beat me at this is welcome, as Christmas is
> going to keep me rather busy ;-)
bisecting would be indeed helpful. It needs to be done only in the
above directory, so there shouldn't be much.
thanks,
Takashi