| 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: <s5hzloqyk8x.wl%tiwai@suse.de>
Date: Wed, 09 Jul 2008 20:39:58 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Johannes Weiner <hannes@...urebad.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
At Mon, 07 Jul 2008 01:17:38 +0200,
Johannes Weiner wrote:
>
> Hi Takashi,
>
> Takashi Iwai <tiwai@...e.de> writes:
>
> > At Tue, 01 Jul 2008 17:12:02 +0200,
> > Johannes Weiner wrote:
> >>
> >> 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 ;)
> >
> > Well, for example, some laptops with maestro3 have a similar problem,
> > but in that case, you just need to touch one mixer element
> > (e.g. Master), and you don't have to re-adjust PCM volume.
> >
> >> >> >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.
> >
> > Yeah, that'll be appreciated.
>
> Okay, I redid the test with something (pretty stupid) like this:
>
> --- a/sound/pci/ac97/ac97_codec.c
> +++ b/sound/pci/ac97/ac97_codec.c
> @@ -28,6 +28,7 @@
> #include <linux/pci.h>
> #include <linux/moduleparam.h>
> #include <linux/mutex.h>
> +#include <linux/kallsyms.h>
> #include <sound/core.h>
> #include <sound/pcm.h>
> #include <sound/tlv.h>
> @@ -2456,8 +2457,23 @@ static void snd_ac97_restore_status(struct snd_ac97 *ac97)
> * are accessed..!
> */
> if (test_bit(i, ac97->reg_accessed)) {
> + printk("restoring register %d\n", i);
> snd_ac97_write(ac97, i, ac97->regs[i]);
> - snd_ac97_read(ac97, i);
> + msleep(800);
> + if (snd_ac97_read(ac97, i) != ac97->regs[i]) {
> + printk("double write register %d\n", i);
> + snd_ac97_write(ac97, i, ac97->regs[i]);
> + }
> + msleep(800);
> + if (snd_ac97_read(ac97, i) != ac97->regs[i]) {
> + printk("triple write register %d\n", i);
> + snd_ac97_write(ac97, i, ac97->regs[i]);
> + }
> + msleep(800);
> + if (snd_ac97_read(ac97, i) != ac97->regs[i]) {
> + printk("quadruple write register %d\n", i);
> + snd_ac97_write(ac97, i, ac97->regs[i]);
> + }
> }
> }
> }
>
> This makes the device resume properly, but the delays are insanely long
> and still sometimes it comes to the third write!
>
> I suspect that this issue is not a problem in the writeback code but in
> the init/exit code of the driver (either intel8x0 or ac97 itself, no
> idea).
>
> Because the following behaviour can be seen:
>
> 1. modprobe snd-intel8x0: everything fine.
> 2. rmmod snd-intel8x0: everything fine.
> 3. modprobe snd-intel8x0:
> ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
> PCI: Setting latency timer of device 0000:00:1f.5 to 64
> ALSA sound/pci/ac97/ac97_codec.c:2054: AC'97 0 does not respond - RESET
> ACPI: PCI interrupt for device 0000:00:1f.5 disabled
> Intel ICH: probe of 0000:00:1f.5 failed with error -13
> 2. rmmod snd-intel8x0: everything fine.
> 3. modprobe snd-intel8x0: everything fine
>
> So I suspect that the device is not shut down properly on
> deactivation/suspension.
>
> Therefor this module reloading fails and the resume tries to writeback
> registers on the not-properly-initialized hardware. The delays appear
> way too long for me to be expectable from this hardware if it is
> properly initialized, no?
>
> May this be a possible?
Yes, possible.
BTW, is CONFIG_SND_AC97_POWER_SAVE enabled? The reset sequence is a
bit dependent on POWER_SAVE kconfig. When it's set, the driver always
tries a cold reset. What happens if you turn it on/off?
Also, any relation with the ac97 modem (i.e. snd-intel8x0m driver)?
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