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: <87fxqt4p19.fsf@skyscraper.fehenstaub.lan>
Date:	Tue, 01 Jul 2008 17:12:02 +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 Tue, 01 Jul 2008 16:37:42 +0200,
> Johannes Weiner wrote:
>> 
>> 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(!).
>
> Yes.  The driver returns the cached values.

Okay.

>> 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).
>
> Just touching one mixer element?

What means `element' here?  I have to touch MASTER and PCM in order to
get some output again, at least ;)

>> >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).
>
> Right.  
>
> snd_ac97_resume() has a check whether the write to MASTER register
> succeeds, but its timeout is 100ms.  Could you check whether this
> check passes at resume or failed?  I remember that some device
> actually passed the test but didn't update the real hardware state.
> If it failed on yours, we may simply extend the timeout, or make it
> pending somehow.  If the hardware fools us, however, it'd be toucher.

By experimentation I found that the writeback works with a two seconds
delay before writeback.  I can't remember if it was before or after the
check.  Another approach was to hammer down the value by writing and
reading back in a loop until the hardware responded with the correct
value.

I will redo the tests later and report back to you what helped.

	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/