linux-kernel - Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 08 Jan 2013 16:26:38 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Kevin Fenzi <kevin@...ye.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

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.


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/