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
| ||
|
Message-ID: <20130112114024.551d37b5@jelerak.scrye.com>
Date: Sat, 12 Jan 2013 11:40:24 -0700
From: Kevin Fenzi <kevin@...ye.com>
To: Takashi Iwai <tiwai@...e.de>
Cc: linux-kernel@...r.kernel.org
Subject: Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave
regression
On Tue, 08 Jan 2013 16:26:38 +0100
Takashi Iwai <tiwai@...e.de> wrote:
> At Sat, 22 Dec 2012 14:23:24 -0700,
> Kevin Fenzi wrote:
> >
> > Greetings.
> >
> > I've got an issue with sound on my t510. It started in the late
> > 3.4.x kernels. Sound works on boot and for 5-10min after, then the
> > speakers stop working at all.
> >
> > I posted a while back on the alsa-users list, and someone else had
> > the same issue:
> >
> > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html
> >
> > It seems that the speakers(?) are getting moved to state D3 and
> > turning off. You can manually get it to come back for a few minutes
> > by using hda-verb to move it back to D0:
> >
> > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0
> >
> > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd
> > is my alsa-info.
> >
> > I'd file a bug on the alsa bug tracker, but it still seems to be
> > down (for many months now?). No response on alsa-users, so now that
> > I have a bit of time, I am posting here in hopes someone can
> > look. ;)
> >
> > Happy to provide more info or try things.
>
> It's a known problem that some people have already reported, but
> currently no clue who actually turns down the pin to D3.
> Conexant guys wrote me that the codec doesn't do it by itself, and the
> driver neither, AFAIK. A possible answer is the firmware / BIOS, but
> who knows.
>
> In anyway, could you try to trace the hd-audio events and see whether
> the power down is *not* issued by the driver when you see this state?
> See Documentation/sound/alsa/HD-Audio.txt, the section "Tracepoints"
> for a brief instruction.
ok. I am not sure I am doing the right thing, but:
- echo 1 > /sys/kernel/debug/tracing/events/hda/enable
- Run hda-verb to get sound working.
- Play a video to confirm.
- check /sys/kernel/debug/tracing/trace
- Wait a while.
- Play another sound that doesn't come out of speakers.
- check /sys/kernel/debug/tracing/trace for anything new.
The only things I see in the trace file are my hda-verb call, and the
sounds playing. Nothing else.
I then tried to duplicate it, but the trace file didn't seem to update
properly. Is there some reset needed?
Or is this not the info you were looking for?
hda-verb-27187 [001] .... 78907.305149: hda_power_count: [0:0]
power_count=1, power_on=1, power_transition=0
hda-verb-27187 [001] .... 78907.305152: hda_send_cmd: [0:0]
val=1f70500
hda-verb-27187 [001] .... 78907.305214: hda_get_response: [0:0]
val=0
hda-verb-27187 [001] .... 78907.305214: hda_power_count: [0:0]
power_count=0, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.682478: hda_power_count: [0:0]
power_count=1, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683330: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683335: hda_power_count: [0:0]
power_count=3, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683336: hda_send_cmd: [0:0]
val=103a047
alsa-sink-17958 [000] .... 78933.683378: hda_get_response: [0:0]
val=0
alsa-sink-17958 [000] .... 78933.683379: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
alsa-sink-17958 [000] .... 78933.683380: hda_power_count: [0:0]
power_count=3, power_on=1, power_transition=0
...
kevin
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists