linux-kernel - Re: intel hda regression: 2.6.33-rc{1,2}: hd-audio0 eats 25% CPU (according to top)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5h637vmhcu.wl%tiwai@suse.de>
Date:	Fri, 25 Dec 2009 12:18:57 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Sergei Trofimovich <slyich@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	Éric Piel <eric.piel@...mplin-utc.net>
Subject: Re: intel hda regression: 2.6.33-rc{1,2}: hd-audio0 eats 25% CPU (according to top)

At Fri, 25 Dec 2009 12:21:07 +0200,
Sergei Trofimovich wrote:
> 
> $SUBJ
> 
> $ git describe
> v2.6.33-rc2
> 
> No matter if I actually play any sounds that process consumes 23-24% CPU
> Don't know if it's related to above: even if there is no any sound activity
> I can hear crackling in headphones.
> 
> $ lspci -vvv
> 
> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
>         Subsystem: Hewlett-Packard Company Device 30c9
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 27
>         Region 0: Memory at e0644000 (64-bit, non-prefetchable) [size=16K]
>         Capabilities: [50] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
>                 Address: 00000000fee0300c  Data: 4191
>         Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
>                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
>                         ExtTag- RBE- FLReset-
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>                         RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                         MaxPayload 128 bytes, MaxReadReq 128 bytes
>                 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
>                 LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
>                         ClockPM- Surprise- LLActRep- BwNot-
>                 LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
>         Capabilities: [100] Virtual Channel <?>
>         Capabilities: [130] Root Complex Link <?>
>         Kernel driver in use: HDA Intel
>         Kernel modules: snd-hda-intel
> 
> $ powertop
> 
> Cn                Avg residency       P-states (frequencies)
> C0 (cpu running)        (25.1%)         1200 Mhz     4.7%
> C1                0.0ms ( 0.0%)         1067 Mhz     0.2%
> C2                0.3ms (74.9%)          933 Mhz     0.2%
>                                          800 Mhz    94.9%
> 
> 
> Wakeups-from-idle per second : 2931.9   interval: 10.0s
> no ACPI power usage estimate available
> 
> Top causes for wakeups:
>   80.6% (6766.8)       <interrupt> : HDA Intel 
>   10.5% (885.6)      <kernel IPI> : Rescheduling interrupts 
>    6.4% (541.3)     <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 
This has been already reported by some people, but unfortunately I
couldn't reproduce this on my test machines.

Eric figured out that replacing the whole sound/pci/hda/* files with
2.6.31 works, so this must be a regression in that area.
Could someone bisect it?  The commits to check are restricted only in
sound/pci/hda, so there shouldn't be many changes.

	% git bisect start -- sound/pci/hda
	% git bisect bad
	% git bisect good v2.6.32


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/