Hi
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
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?
thanks,
Takashi
2009/12/21 Takashi Iwai <[email protected]>:
> 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
Op 21-12-09 19:12, Maciej Rutecki schreef:
> 2009/12/21 Takashi Iwai <[email protected]>:
>> 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?
Eric
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 <[email protected]>:
> >> 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
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?
Eric
At Tue, 22 Dec 2009 10:15:20 +0100,
É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
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
Just tried: it doesn't have any effect, as enable_msi=0. Still 25% of
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 .
:
>
> I'd try first only sound/pci/hda/* files.
Ok, I'll try later. Or maybe I'll just do a bisection...
Eric
At Tue, 22 Dec 2009 16:15:57 +0100,
É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
> Just tried: it doesn't have any effect, as enable_msi=0. Still 25% of
> 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.
Takashi
Op 22-12-09 16:40, Takashi Iwai schreef:
:
>
> 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
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.
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
At Wed, 23 Dec 2009 15:27:08 +0100,
É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