linux-kernel - Re: Longstanding bug in ac97/intel8x0 resume/init

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: <87k5g54qmh.fsf@skyscraper.fehenstaub.lan>
Date:	Tue, 01 Jul 2008 16:37:42 +0200
From:	Johannes Weiner <hannes@...urebad.de>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Mathieu Chouquet-Stringer <mchouque@...e.fr>,
	Jaroslav Kysela <perex@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: Longstanding bug in ac97/intel8x0 resume/init

Hi,

Takashi Iwai <tiwai@...e.de> writes:

> At 30 Jun 2008 20:58:03 +0200,
> Mathieu Chouquet-Stringer wrote:
>> 
>>         Hey there,
>> 
>> hannes@...urebad.de (Johannes Weiner) writes:
>> > Johannes Weiner <hannes@...urebad.de> writes:
>> > > my laptop has muted sound after resuming the soundcard (by
>> > > s2ram/hibernation).  The problem seems to be that the cached register
>> > > values are not written back to the device properly.
>> 
>> I've got the same exact issue on a Thinkpad T30:
>> 
>>  0 [I82801CAICH3   ]: ICH - Intel 82801CA-ICH3
>>                       Intel 82801CA-ICH3 with AD1881A at irq 5
>> 
>> 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02)
>
> Does this happen for both hibernation and S2RAM?
> And, resetting the mixer repairs the mute state, right?
> If yes, the problem appears independently from the codec chip.  Hmm...

Yes, happens in both cases here.

The alsamixer shows the state of the channels before the suspension(!).
If I change the channel state, the sound works again.  No complete reset
needed at all, I just have to increase/decrease the value a bit (for
each affected channel).

>From my experiments with the code, I figured that the cached register
values are not written back properly on resume.  The cache is in the
correct state but the hardware is not.  This also explains the behaviour
when changing the channels with alsamixer; the register cache is touched
and written back (and this time, the value really gets through to the
hardware).

	Hannes
--
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/