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]
Message-ID: <s5hk3rnofv5.wl%tiwai@suse.de>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ