Hello,
One of my systems works fine with 2.6.32, but hangs when trying to
boot 2.6.33-rc2. Git bisect says
7923c615b811945a9d9f456c92a7a32c34167458 is the first bad commit:
drm/radeon/kms: make sure mc is initialized before mapping blit bo
We need to make sure the the MC is intialized before we map the
blit shader object on r6xx+.
(So the problem was already present in -rc1.)
The last message I see during a 2.6.33-rc2 boot is about attaching a
disk. Then everything stops until I press Ctrl-Alt-Del. With a
working kernel, the next thing would be switching the console to a
higher resolution mode. The graphics card is
01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350]
Please Cc me directly on replies.
Andrei
On Fri, Dec 25, 2009 at 7:31 PM, Andrei Gaponenko
<[email protected]> wrote:
> Hello,
>
> One of my systems works fine with 2.6.32, but hangs when trying to
> boot 2.6.33-rc2. ?Git bisect says
> 7923c615b811945a9d9f456c92a7a32c34167458 is the first bad commit:
>
> ? ?drm/radeon/kms: make sure mc is initialized before mapping blit bo
>
> ? ?We need to make sure the the MC is intialized before we map the
> ? ?blit shader object on r6xx+.
>
> (So the problem was already present in -rc1.)
>
> The last message I see during a 2.6.33-rc2 boot is about attaching a
> disk. ?Then everything stops until I press Ctrl-Alt-Del. ?With a
> working kernel, the next thing would be switching the console to a
> higher resolution mode. ?The graphics card is
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350]
>
> Please Cc me directly on replies.
Can you wait for a minute or so and see if it continues? though this sounds like
something different than others have seen.
Dave.
On Fri, 25 Dec 2009, Dave Airlie wrote:
> On Fri, Dec 25, 2009 at 7:31 PM, Andrei Gaponenko
> <[email protected]> wrote:
> > Hello,
> >
> > One of my systems works fine with 2.6.32, but hangs when trying to
> > boot 2.6.33-rc2. ?Git bisect says
> > 7923c615b811945a9d9f456c92a7a32c34167458 is the first bad commit:
> > [...]
>
> Can you wait for a minute or so and see if it continues? though this sounds like
> something different than others have seen.
I did let it to sit for many minutes during some of iterations of the
bisection; did not notice any progress.
Andrei
Please Cc me directly on replies.
$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)
...
Thanks!
--
Sergei
On Fri, Dec 25, 2009 at 8:08 PM, Andrei Gaponenko
<[email protected]> wrote:
> On Fri, 25 Dec 2009, Dave Airlie wrote:
>
>> On Fri, Dec 25, 2009 at 7:31 PM, Andrei Gaponenko
>> <[email protected]> wrote:
>> > Hello,
>> >
>> > One of my systems works fine with 2.6.32, but hangs when trying to
>> > boot 2.6.33-rc2. ?Git bisect says
>> > 7923c615b811945a9d9f456c92a7a32c34167458 is the first bad commit:
>> > [...]
>>
>> Can you wait for a minute or so and see if it continues? though this sounds like
>> something different than others have seen.
>
> I did let it to sit for many minutes during some of iterations of the
> bisection; did not notice any progress.
>
> Andrei
>
> Please Cc me directly on replies.
Did you install the irq firmware from
http://people.freedesktop.org/~agd5f/radeon_ucode/
I need to add a pointer to the Kconfig (just wasn't there when I sent it i).
Dave.
On Fri, 25 Dec 2009, Dave Airlie wrote:
> On Fri, Dec 25, 2009 at 8:08 PM, Andrei Gaponenko
> <[email protected]> wrote:
> > On Fri, 25 Dec 2009, Dave Airlie wrote:
> >
> >> On Fri, Dec 25, 2009 at 7:31 PM, Andrei Gaponenko
> >> <[email protected]> wrote:
> >> > Hello,
> >> >
> >> > One of my systems works fine with 2.6.32, but hangs when trying to
> >> > boot 2.6.33-rc2. ?Git bisect says
> >> > 7923c615b811945a9d9f456c92a7a32c34167458 is the first bad commit:
> >> > [...]
> >>
>
> Did you install the irq firmware from
> http://people.freedesktop.org/~agd5f/radeon_ucode/
That was the problem! 2.6.33-rc2 boots after I installed the
firmware. Thank you, Dave!
Andrei
Please Cc me directly on replies.
>
> I need to add a pointer to the Kconfig (just wasn't there when I sent it i).
>
> Dave.
>
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
* Dave Airlie ([email protected]) wrote:
> On Fri, Dec 25, 2009 at 8:08 PM, Andrei Gaponenko
<snip>
> >> Can you wait for a minute or so and see if it continues? though this sounds like
> >> something different than others have seen.
> >
> > I did let it to sit for many minutes during some of iterations of the
> > bisection; did not notice any progress.
> >
> > Andrei
> >
> > Please Cc me directly on replies.
>
> Did you install the irq firmware from
> http://people.freedesktop.org/~agd5f/radeon_ucode/
>
> I need to add a pointer to the Kconfig (just wasn't there when I sent it i).
I had the same problem (and the same fix); For me it gave up after 60
seconds of waiting for the firmware and panic'd.
Unfortunately at that point it was still at a VGA display without
much res, so while I got the backtrace I didn't get the top of the oops.
(and it was too early for netconsole)
It would be better if the firmware was missing for it just not to do
modeswitching and carry on; I wonder if it was hangcheck or the like
that killed it?
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Fri, 25 Dec 2009 12:18:57 +0100
Takashi Iwai <[email protected]> wrote:
> 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,
Done:
d56757abc11a21996d9839c0d4e3b2c3666cd318 is the first bad commit
commit d56757abc11a21996d9839c0d4e3b2c3666cd318
Author: Takashi Iwai <[email protected]>
Date: Wed Nov 18 08:00:14 2009 +0100
ALSA: hda - Replace the rest of jack-detections with snd_hda_jack_detect()
Signed-off-by: Takashi Iwai <[email protected]>
:040000 040000 46040881f7bc4b662a784ac66a6482c2a5b3dca5 6a76aa47a3d0cccad0c8a3ae62cb63ecbdd9b44d M sound
Bisect log:
git bisect start '--' 'sound/pci/hda'
# bad: [55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f] Linux 2.6.33-rc1
git bisect bad 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# good: [123c07aeddd71fbb295842a8c19866e780b9a100] ALSA: hda_intel: Digital PC Beep - change behaviour for input layer
git bisect good 123c07aeddd71fbb295842a8c19866e780b9a100
# good: [123c07aeddd71fbb295842a8c19866e780b9a100] ALSA: hda_intel: Digital PC Beep - change behaviour for input layer
git bisect good 123c07aeddd71fbb295842a8c19866e780b9a100
# bad: [0b587fc4d35afb1bc0fc3d890084bb14c78372dc] ALSA: hda: Fix max PCM level to 0 dB for Fujitsu-Siemens laptops using CX2054
9 (Venice)
git bisect bad 0b587fc4d35afb1bc0fc3d890084bb14c78372dc
# good: [23ccc2bd246a5bdb1ac03dc9040a0585c1890ef3] ALSA: intelhdmi - export monitor-presence and ELD-valid status
git bisect good 23ccc2bd246a5bdb1ac03dc9040a0585c1890ef3
# bad: [d56757abc11a21996d9839c0d4e3b2c3666cd318] ALSA: hda - Replace the rest of jack-detections with snd_hda_jack_detect()
git bisect bad d56757abc11a21996d9839c0d4e3b2c3666cd318
# good: [848de598eef9603d6f2c174f90fded4e63ac5e23] ALSA: intelhdmi - sticky infoframe
git bisect good 848de598eef9603d6f2c174f90fded4e63ac5e23
# good: [81bf31e2d0a6a9f5d83da0a757f8ca03db908162] ALSA: intelhdmi - sticky channel count
git bisect good 81bf31e2d0a6a9f5d83da0a757f8ca03db908162
# good: [83d605fd63e704419ccb92d48b735c6890ce3d6a] ALSA: hda - show EPSS capability in proc
git bisect good 83d605fd63e704419ccb92d48b735c6890ce3d6a
Sorry, was unable to revert that commit on top of current 2.6.33-rc2 and verify it's guilty.
> Takashi
--
Sergei
2009/12/25 Sergei Trofimovich <[email protected]>:
> Done:
>
> d56757abc11a21996d9839c0d4e3b2c3666cd318 is the first bad commit
> commit d56757abc11a21996d9839c0d4e3b2c3666cd318
> Author: Takashi Iwai <[email protected]>
> Date: Wed Nov 18 08:00:14 2009 +0100
>
> ALSA: hda - Replace the rest of jack-detections with snd_hda_jack_detect()
>
> Signed-off-by: Takashi Iwai <[email protected]>
>
> :040000 040000 46040881f7bc4b662a784ac66a6482c2a5b3dca5 6a76aa47a3d0cccad0c8a3ae62cb63ecbdd9b44d M sound
>
> Bisect log:
> git bisect start '--' 'sound/pci/hda'
> # bad: [55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f] Linux 2.6.33-rc1
> git bisect bad 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f
> # good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
> git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
> # good: [123c07aeddd71fbb295842a8c19866e780b9a100] ALSA: hda_intel: Digital PC Beep - change behaviour for input layer
> git bisect good 123c07aeddd71fbb295842a8c19866e780b9a100
> # good: [123c07aeddd71fbb295842a8c19866e780b9a100] ALSA: hda_intel: Digital PC Beep - change behaviour for input layer
> git bisect good 123c07aeddd71fbb295842a8c19866e780b9a100
> # bad: [0b587fc4d35afb1bc0fc3d890084bb14c78372dc] ALSA: hda: Fix max PCM level to 0 dB for Fujitsu-Siemens laptops using CX2054
> 9 (Venice)
> git bisect bad 0b587fc4d35afb1bc0fc3d890084bb14c78372dc
> # good: [23ccc2bd246a5bdb1ac03dc9040a0585c1890ef3] ALSA: intelhdmi - export monitor-presence and ELD-valid status
> git bisect good 23ccc2bd246a5bdb1ac03dc9040a0585c1890ef3
> # bad: [d56757abc11a21996d9839c0d4e3b2c3666cd318] ALSA: hda - Replace the rest of jack-detections with snd_hda_jack_detect()
> git bisect bad d56757abc11a21996d9839c0d4e3b2c3666cd318
> # good: [848de598eef9603d6f2c174f90fded4e63ac5e23] ALSA: intelhdmi - sticky infoframe
> git bisect good 848de598eef9603d6f2c174f90fded4e63ac5e23
> # good: [81bf31e2d0a6a9f5d83da0a757f8ca03db908162] ALSA: intelhdmi - sticky channel count
> git bisect good 81bf31e2d0a6a9f5d83da0a757f8ca03db908162
> # good: [83d605fd63e704419ccb92d48b735c6890ce3d6a] ALSA: hda - show EPSS capability in proc
> git bisect good 83d605fd63e704419ccb92d48b735c6890ce3d6a
>
> Sorry, was unable to revert that commit on top of current 2.6.33-rc2 and verify it's guilty.
>
>> Takashi
>
> --
>
> Sergei
>
Good work. I already find some time to test, and I have the same
bisection's result, so I think that this commit cause problem.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
At Fri, 25 Dec 2009 16:31:58 +0100,
Maciej Rutecki wrote:
>
> 2009/12/25 Sergei Trofimovich <[email protected]>:
>
> > Done:
> >
> > d56757abc11a21996d9839c0d4e3b2c3666cd318 is the first bad commit
> > commit d56757abc11a21996d9839c0d4e3b2c3666cd318
> > Author: Takashi Iwai <[email protected]>
> > Date: Wed Nov 18 08:00:14 2009 +0100
> >
> > ALSA: hda - Replace the rest of jack-detections with snd_hda_jack_detect()
> >
> > Signed-off-by: Takashi Iwai <[email protected]>
> >
> > :040000 040000 46040881f7bc4b662a784ac66a6482c2a5b3dca5 6a76aa47a3d0cccad0c8a3ae62cb63ecbdd9b44d M sound
> >
> > Bisect log:
> > git bisect start '--' 'sound/pci/hda'
> > # bad: [55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f] Linux 2.6.33-rc1
> > git bisect bad 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f
> > # good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
> > git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
> > # good: [123c07aeddd71fbb295842a8c19866e780b9a100] ALSA: hda_intel: Digital PC Beep - change behaviour for input layer
> > git bisect good 123c07aeddd71fbb295842a8c19866e780b9a100
> > # good: [123c07aeddd71fbb295842a8c19866e780b9a100] ALSA: hda_intel: Digital PC Beep - change behaviour for input layer
> > git bisect good 123c07aeddd71fbb295842a8c19866e780b9a100
> > # bad: [0b587fc4d35afb1bc0fc3d890084bb14c78372dc] ALSA: hda: Fix max PCM level to 0 dB for Fujitsu-Siemens laptops using CX2054
> > 9 (Venice)
> > git bisect bad 0b587fc4d35afb1bc0fc3d890084bb14c78372dc
> > # good: [23ccc2bd246a5bdb1ac03dc9040a0585c1890ef3] ALSA: intelhdmi - export monitor-presence and ELD-valid status
> > git bisect good 23ccc2bd246a5bdb1ac03dc9040a0585c1890ef3
> > # bad: [d56757abc11a21996d9839c0d4e3b2c3666cd318] ALSA: hda - Replace the rest of jack-detections with snd_hda_jack_detect()
> > git bisect bad d56757abc11a21996d9839c0d4e3b2c3666cd318
> > # good: [848de598eef9603d6f2c174f90fded4e63ac5e23] ALSA: intelhdmi - sticky infoframe
> > git bisect good 848de598eef9603d6f2c174f90fded4e63ac5e23
> > # good: [81bf31e2d0a6a9f5d83da0a757f8ca03db908162] ALSA: intelhdmi - sticky channel count
> > git bisect good 81bf31e2d0a6a9f5d83da0a757f8ca03db908162
> > # good: [83d605fd63e704419ccb92d48b735c6890ce3d6a] ALSA: hda - show EPSS capability in proc
> > git bisect good 83d605fd63e704419ccb92d48b735c6890ce3d6a
> >
> > Sorry, was unable to revert that commit on top of current 2.6.33-rc2 and verify it's guilty.
> >
> >> Takashi
> >
> > --
> >
> > Sergei
> >
>
> Good work. I already find some time to test, and I have the same
> bisection's result, so I think that this commit cause problem.
OK, thanks for quick tests.
It's a bit surprising that this resulted in the high CPU usage
instead of erroneous behavior. This should be rather a bug of
codec chip...
Anyway, Segei, which codec is on your machine? Is it Analog Device
one?
IIRC, the one's on Maciej and Eric machines are AD codecs.
If so, we can just revert the changes to patch_analog.c in that
commit.
thanks,
Takashi
On Fri, 25 Dec 2009 17:05:16 +0100
Takashi Iwai <[email protected]> wrote:
> It's a bit surprising that this resulted in the high CPU usage
> instead of erroneous behavior. This should be rather a bug of
> codec chip...
>
> Anyway, Segei, which codec is on your machine? Is it Analog Device
> one?
> IIRC, the one's on Maciej and Eric machines are AD codecs.
> If so, we can just revert the changes to patch_analog.c in that
> commit.
How can I check? alsamixer shows
Chip: Analog Devices AD1981
Not sure it's valid though.
It's a HP Compaq 2510p laptop.
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
Subsystem: Hewlett-Packard Company Device 30c9
(posted whole lspci output slightly earlier if needed)
--
Sergei
2009/12/25 Takashi Iwai <[email protected]>:
>
> OK, thanks for quick tests.
>
> It's a bit surprising that this resulted in the high CPU usage
> instead of erroneous behavior. This should be rather a bug of
> codec chip...
>
> Anyway, Segei, which codec is on your machine? Is it Analog Device
> one?
> IIRC, the one's on Maciej and Eric machines are AD codecs.
> If so, we can just revert the changes to patch_analog.c in that
> commit.
>
So all we have hp notebook and AD codecs? Maybe You are right, that is
bug in codec chip.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
At Fri, 25 Dec 2009 18:32:05 +0200,
Sergei Trofimovich wrote:
>
> On Fri, 25 Dec 2009 17:05:16 +0100
> Takashi Iwai <[email protected]> wrote:
>
> > It's a bit surprising that this resulted in the high CPU usage
> > instead of erroneous behavior. This should be rather a bug of
> > codec chip...
> >
> > Anyway, Segei, which codec is on your machine? Is it Analog Device
> > one?
> > IIRC, the one's on Maciej and Eric machines are AD codecs.
> > If so, we can just revert the changes to patch_analog.c in that
> > commit.
>
> How can I check? alsamixer shows
> Chip: Analog Devices AD1981
> Not sure it's valid though.
>
> It's a HP Compaq 2510p laptop.
>
> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
> Subsystem: Hewlett-Packard Company Device 30c9
> (posted whole lspci output slightly earlier if needed)
OK, they all seem to have AD codecs indeed.
Instead of reverting, how about the patch below?
thanks,
Takashi
---
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 950ee5c..f98b47c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1327,11 +1327,13 @@ EXPORT_SYMBOL_HDA(snd_hda_query_pin_caps);
*/
u32 snd_hda_pin_sense(struct hda_codec *codec, hda_nid_t nid)
{
- u32 pincap = snd_hda_query_pin_caps(codec, nid);
-
- if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
- snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
+ u32 pincap;
+ if (!codec->no_trigger_sense) {
+ pincap = snd_hda_query_pin_caps(codec, nid);
+ if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
+ snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
+ }
return snd_hda_codec_read(codec, nid, 0,
AC_VERB_GET_PIN_SENSE, 0);
}
diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 1d541b7..0a770a2 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -817,6 +817,7 @@ struct hda_codec {
unsigned int pin_amp_workaround:1; /* pin out-amp takes index
* (e.g. Conexant codecs)
*/
+ unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */
#ifdef CONFIG_SND_HDA_POWER_SAVE
unsigned int power_on :1; /* current (global) power-state */
unsigned int power_transition :1; /* power-state in transition */
diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
index 1a36137..69a941c 100644
--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -1186,6 +1186,8 @@ static int patch_ad1986a(struct hda_codec *codec)
*/
spec->multiout.no_share_stream = 1;
+ codec->no_trigger_sense = 1;
+
return 0;
}
@@ -1371,6 +1373,8 @@ static int patch_ad1983(struct hda_codec *codec)
codec->patch_ops = ad198x_patch_ops;
+ codec->no_trigger_sense = 1;
+
return 0;
}
@@ -1813,6 +1817,9 @@ static int patch_ad1981(struct hda_codec *codec)
codec->patch_ops.unsol_event = ad1981_hp_unsol_event;
break;
}
+
+ codec->no_trigger_sense = 1;
+
return 0;
}
@@ -3118,6 +3125,8 @@ static int patch_ad1988(struct hda_codec *codec)
#endif
spec->vmaster_nid = 0x04;
+ codec->no_trigger_sense = 1;
+
return 0;
}
@@ -3330,6 +3339,8 @@ static int patch_ad1884(struct hda_codec *codec)
codec->patch_ops = ad198x_patch_ops;
+ codec->no_trigger_sense = 1;
+
return 0;
}
@@ -4287,6 +4298,8 @@ static int patch_ad1884a(struct hda_codec *codec)
break;
}
+ codec->no_trigger_sense = 1;
+
return 0;
}
@@ -4623,6 +4636,9 @@ static int patch_ad1882(struct hda_codec *codec)
spec->mixers[2] = ad1882_6stack_mixers;
break;
}
+
+ codec->no_trigger_sense = 1;
+
return 0;
}
On Fri, 25 Dec 2009 18:06:00 +0100
Takashi Iwai <[email protected]> wrote:
> At Fri, 25 Dec 2009 18:32:05 +0200,
> Sergei Trofimovich wrote:
> >
> > On Fri, 25 Dec 2009 17:05:16 +0100
> > Takashi Iwai <[email protected]> wrote:
> >
> > > It's a bit surprising that this resulted in the high CPU usage
> > > instead of erroneous behavior. This should be rather a bug of
> > > codec chip...
> > >
> > > Anyway, Segei, which codec is on your machine? Is it Analog Device
> > > one?
> > > IIRC, the one's on Maciej and Eric machines are AD codecs.
> > > If so, we can just revert the changes to patch_analog.c in that
> > > commit.
> >
> > How can I check? alsamixer shows
> > Chip: Analog Devices AD1981
> > Not sure it's valid though.
> >
> > It's a HP Compaq 2510p laptop.
> >
> > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
> > Subsystem: Hewlett-Packard Company Device 30c9
> > (posted whole lspci output slightly earlier if needed)
>
> OK, they all seem to have AD codecs indeed.
> Instead of reverting, how about the patch below?
Fixed both CPU load and crackling sounds for me!
Thank You!
> ---
> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> index 950ee5c..f98b47c 100644
> --- a/sound/pci/hda/hda_codec.c
> +++ b/sound/pci/hda/hda_codec.c
> @@ -1327,11 +1327,13 @@ EXPORT_SYMBOL_HDA(snd_hda_query_pin_caps);
> */
> u32 snd_hda_pin_sense(struct hda_codec *codec, hda_nid_t nid)
> {
> - u32 pincap = snd_hda_query_pin_caps(codec, nid);
> -
> - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
> - snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
> + u32 pincap;
>
> + if (!codec->no_trigger_sense) {
> + pincap = snd_hda_query_pin_caps(codec, nid);
> + if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
> + snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
> + }
> return snd_hda_codec_read(codec, nid, 0,
> AC_VERB_GET_PIN_SENSE, 0);
> }
> diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
> index 1d541b7..0a770a2 100644
> --- a/sound/pci/hda/hda_codec.h
> +++ b/sound/pci/hda/hda_codec.h
> @@ -817,6 +817,7 @@ struct hda_codec {
> unsigned int pin_amp_workaround:1; /* pin out-amp takes index
> * (e.g. Conexant codecs)
> */
> + unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */
> #ifdef CONFIG_SND_HDA_POWER_SAVE
> unsigned int power_on :1; /* current (global) power-state */
> unsigned int power_transition :1; /* power-state in transition */
> diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
> index 1a36137..69a941c 100644
> --- a/sound/pci/hda/patch_analog.c
> +++ b/sound/pci/hda/patch_analog.c
> @@ -1186,6 +1186,8 @@ static int patch_ad1986a(struct hda_codec *codec)
> */
> spec->multiout.no_share_stream = 1;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -1371,6 +1373,8 @@ static int patch_ad1983(struct hda_codec *codec)
>
> codec->patch_ops = ad198x_patch_ops;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -1813,6 +1817,9 @@ static int patch_ad1981(struct hda_codec *codec)
> codec->patch_ops.unsol_event = ad1981_hp_unsol_event;
> break;
> }
> +
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -3118,6 +3125,8 @@ static int patch_ad1988(struct hda_codec *codec)
> #endif
> spec->vmaster_nid = 0x04;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -3330,6 +3339,8 @@ static int patch_ad1884(struct hda_codec *codec)
>
> codec->patch_ops = ad198x_patch_ops;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -4287,6 +4298,8 @@ static int patch_ad1884a(struct hda_codec *codec)
> break;
> }
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -4623,6 +4636,9 @@ static int patch_ad1882(struct hda_codec *codec)
> spec->mixers[2] = ad1882_6stack_mixers;
> break;
> }
> +
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
--
Sergei
2009/12/25 Takashi Iwai <[email protected]>:
> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> index 950ee5c..f98b47c 100644
> --- a/sound/pci/hda/hda_codec.c
> +++ b/sound/pci/hda/hda_codec.c
> @@ -1327,11 +1327,13 @@ EXPORT_SYMBOL_HDA(snd_hda_query_pin_caps);
> */
> u32 snd_hda_pin_sense(struct hda_codec *codec, hda_nid_t nid)
> {
> - u32 pincap = snd_hda_query_pin_caps(codec, nid);
> -
> - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
> - snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
> + u32 pincap;
>
> + if (!codec->no_trigger_sense) {
> + pincap = snd_hda_query_pin_caps(codec, nid);
> + if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
> + snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
> + }
> return snd_hda_codec_read(codec, nid, 0,
> AC_VERB_GET_PIN_SENSE, 0);
> }
> diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
> index 1d541b7..0a770a2 100644
> --- a/sound/pci/hda/hda_codec.h
> +++ b/sound/pci/hda/hda_codec.h
> @@ -817,6 +817,7 @@ struct hda_codec {
> unsigned int pin_amp_workaround:1; /* pin out-amp takes index
> * (e.g. Conexant codecs)
> */
> + unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */
> #ifdef CONFIG_SND_HDA_POWER_SAVE
> unsigned int power_on :1; /* current (global) power-state */
> unsigned int power_transition :1; /* power-state in transition */
> diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
> index 1a36137..69a941c 100644
> --- a/sound/pci/hda/patch_analog.c
> +++ b/sound/pci/hda/patch_analog.c
> @@ -1186,6 +1186,8 @@ static int patch_ad1986a(struct hda_codec *codec)
> */
> spec->multiout.no_share_stream = 1;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -1371,6 +1373,8 @@ static int patch_ad1983(struct hda_codec *codec)
>
> codec->patch_ops = ad198x_patch_ops;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -1813,6 +1817,9 @@ static int patch_ad1981(struct hda_codec *codec)
> codec->patch_ops.unsol_event = ad1981_hp_unsol_event;
> break;
> }
> +
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -3118,6 +3125,8 @@ static int patch_ad1988(struct hda_codec *codec)
> #endif
> spec->vmaster_nid = 0x04;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -3330,6 +3339,8 @@ static int patch_ad1884(struct hda_codec *codec)
>
> codec->patch_ops = ad198x_patch_ops;
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -4287,6 +4298,8 @@ static int patch_ad1884a(struct hda_codec *codec)
> break;
> }
>
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
> @@ -4623,6 +4636,9 @@ static int patch_ad1882(struct hda_codec *codec)
> spec->mixers[2] = ad1882_6stack_mixers;
> break;
> }
> +
> + codec->no_trigger_sense = 1;
> +
> return 0;
> }
>
>
Patch solves the problem.
Tested-by Maciej Rutecki <[email protected]>
Thanks!
--
Maciej Rutecki
http://www.maciek.unixy.pl
At Fri, 25 Dec 2009 20:01:46 +0100,
Maciej Rutecki wrote:
>
> 2009/12/25 Takashi Iwai <[email protected]>:
>
> > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> > index 950ee5c..f98b47c 100644
> > --- a/sound/pci/hda/hda_codec.c
> > +++ b/sound/pci/hda/hda_codec.c
> > @@ -1327,11 +1327,13 @@ EXPORT_SYMBOL_HDA(snd_hda_query_pin_caps);
> > */
> > u32 snd_hda_pin_sense(struct hda_codec *codec, hda_nid_t nid)
> > {
> > - u32 pincap = snd_hda_query_pin_caps(codec, nid);
> > -
> > - if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
> > - snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
> > + u32 pincap;
> >
> > + if (!codec->no_trigger_sense) {
> > + pincap = snd_hda_query_pin_caps(codec, nid);
> > + if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
> > + snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_PIN_SENSE, 0);
> > + }
> > return snd_hda_codec_read(codec, nid, 0,
> > AC_VERB_GET_PIN_SENSE, 0);
> > }
> > diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
> > index 1d541b7..0a770a2 100644
> > --- a/sound/pci/hda/hda_codec.h
> > +++ b/sound/pci/hda/hda_codec.h
> > @@ -817,6 +817,7 @@ struct hda_codec {
> > unsigned int pin_amp_workaround:1; /* pin out-amp takes index
> > * (e.g. Conexant codecs)
> > */
> > + unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */
> > #ifdef CONFIG_SND_HDA_POWER_SAVE
> > unsigned int power_on :1; /* current (global) power-state */
> > unsigned int power_transition :1; /* power-state in transition */
> > diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
> > index 1a36137..69a941c 100644
> > --- a/sound/pci/hda/patch_analog.c
> > +++ b/sound/pci/hda/patch_analog.c
> > @@ -1186,6 +1186,8 @@ static int patch_ad1986a(struct hda_codec *codec)
> > */
> > spec->multiout.no_share_stream = 1;
> >
> > + codec->no_trigger_sense = 1;
> > +
> > return 0;
> > }
> >
> > @@ -1371,6 +1373,8 @@ static int patch_ad1983(struct hda_codec *codec)
> >
> > codec->patch_ops = ad198x_patch_ops;
> >
> > + codec->no_trigger_sense = 1;
> > +
> > return 0;
> > }
> >
> > @@ -1813,6 +1817,9 @@ static int patch_ad1981(struct hda_codec *codec)
> > codec->patch_ops.unsol_event = ad1981_hp_unsol_event;
> > break;
> > }
> > +
> > + codec->no_trigger_sense = 1;
> > +
> > return 0;
> > }
> >
> > @@ -3118,6 +3125,8 @@ static int patch_ad1988(struct hda_codec *codec)
> > #endif
> > spec->vmaster_nid = 0x04;
> >
> > + codec->no_trigger_sense = 1;
> > +
> > return 0;
> > }
> >
> > @@ -3330,6 +3339,8 @@ static int patch_ad1884(struct hda_codec *codec)
> >
> > codec->patch_ops = ad198x_patch_ops;
> >
> > + codec->no_trigger_sense = 1;
> > +
> > return 0;
> > }
> >
> > @@ -4287,6 +4298,8 @@ static int patch_ad1884a(struct hda_codec *codec)
> > break;
> > }
> >
> > + codec->no_trigger_sense = 1;
> > +
> > return 0;
> > }
> >
> > @@ -4623,6 +4636,9 @@ static int patch_ad1882(struct hda_codec *codec)
> > spec->mixers[2] = ad1882_6stack_mixers;
> > break;
> > }
> > +
> > + codec->no_trigger_sense = 1;
> > +
> > return 0;
> > }
> >
> >
> Patch solves the problem.
>
> Tested-by Maciej Rutecki <[email protected]>
Thanks for testing.
I merged the patch now.
Takashi
On Fri, Dec 25, 2009 at 7:35 AM, Dr. David Alan Gilbert
<[email protected]> wrote:
> * Dave Airlie ([email protected]) wrote:
>> On Fri, Dec 25, 2009 at 8:08 PM, Andrei Gaponenko
>
> <snip>
>
>> >> Can you wait for a minute or so and see if it continues? though this sounds like
>> >> something different than others have seen.
>> >
>> > I did let it to sit for many minutes during some of iterations of the
>> > bisection; did not notice any progress.
>> >
>> > Andrei
>> >
>> > Please Cc me directly on replies.
>>
>> Did you install the irq firmware from
>> http://people.freedesktop.org/~agd5f/radeon_ucode/
>>
>> I need to add a pointer to the Kconfig (just wasn't there when I sent it i).
>
> I had the same problem (and the same fix); For me it gave up after 60
> seconds of waiting for the firmware and panic'd.
>
> Unfortunately at that point it was still at a VGA display without
> much res, so while I got the backtrace I didn't get the top of the oops.
> (and it was too early for netconsole)
>
> It would be better if the firmware was missing for it just not to do
> modeswitching and carry on; I wonder if it was hangcheck or the like
> that killed it?
Dave's tree already has support for falling back gracefully if any of
the ucode is missing.
Alex