Hi,
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.
Before suspend, the registers look like this:
0:00 = 1990
0:02 = 0000
0:04 = 9f1f
0:06 = 801f
0:08 = 0000
0:0a = 801e
0:0c = 801f
0:0e = 801f
0:10 = 9f1f
0:12 = 9f1f
0:14 = 9f1f
0:16 = 9f1f
0:18 = 0b0b
0:1a = 0000
0:1c = 0000
0:1e = 0000
0:20 = 0000
0:22 = 0000
0:24 = 0000
0:26 = 000f
0:28 = 0201
0:2a = 0001
0:2c = bb80
0:2e = 0000
0:30 = 0000
0:32 = bb80
0:34 = 0000
0:36 = 0000
0:38 = 0000
0:3a = 0000
0:3c = 0000
0:3e = 0000
0:40 = 0000
0:42 = 0000
0:44 = 0000
0:46 = 0000
0:48 = 0000
0:4a = 0000
0:4c = 0000
0:4e = 0000
0:50 = 0000
0:52 = 0000
0:54 = 0000
0:56 = ffff
0:58 = 0000
0:5a = 0604
0:5c = 0000
0:5e = 0080
0:60 = 0023
0:62 = 0000
0:64 = 0000
0:66 = 0000
0:68 = 0824
0:6a = 0000
0:6c = 0000
0:6e = 0000
0:70 = 0000
0:72 = 0000
0:74 = 0000
0:76 = 0000
0:78 = 003c
0:7a = 0000
0:7c = 4352
0:7e = 5936
and right after a resume, they look like this (annotations by me):
0:00 = 1990
0:02 = 8000 ! Master Volume
0:04 = 8000 ! Headphone Volume
0:06 = 8000 ! Master Mono Volume
0:08 = 0000
0:0a = 0000 ! PC Beep Volume
0:0c = 8008 ! Phone Volume
0:0e = 8008 ! Mic Volume
0:10 = 8808 ! Line In Volume
0:12 = 8808 ! CD Volume
0:14 = 8808 ! Video Volume
0:16 = 8808 ! AUX Volume
0:18 = 8808 ! PCM Volume
0:1a = 0000
0:1c = 8000 ! Record gain
0:1e = 0000
0:20 = 0000
0:22 = 0000
0:24 = 0000
0:26 = 000f
0:28 = 0201
0:2a = 0001
0:2c = bb80
0:2e = 0000
0:30 = 0000
0:32 = bb80
0:34 = 0000
0:36 = 0000
0:38 = 0000
0:3a = 0000
0:3c = 0000
0:3e = 0000
0:40 = 0000
0:42 = 0000
0:44 = 0000
0:46 = 0000
0:48 = 0000
0:4a = 0000
0:4c = 0000
0:4e = 0000
0:50 = 0000
0:52 = 0000
0:54 = 0000
0:56 = ffff
0:58 = 0000
0:5a = 0604
0:5c = 0000
0:5e = 0080
0:60 = 0023
0:62 = 0000
0:64 = 0000
0:66 = 0000
0:68 = 0824
0:6a = 0000
0:6c = 0000
0:6e = 0000
0:70 = 0000
0:72 = 0000
0:74 = 0000
0:76 = 0000
0:78 = 003c
0:7a = 0000
0:7c = 4352
0:7e = 5936
When I run alsamixer and change around the values of Master and PCM in a
purely random way - a bit higher/lower, mute/unmute, etc. - sound comes
back to life.
I remember to `fix' this by adding more delays between waking the device
and syncing back the cache. But I think that took up to 6 seconds,
sometimes, so there must be something else going on (see below).
The chip is the following:
0-0/0: Cirrus Logic CS4299 rev 6
PCI Subsys Vendor: 0x1014
PCI Subsys Device: 0x0222
Capabilities : -headphone out-
DAC resolution : 20-bit
ADC resolution : 18-bit
3D enhancement : Crystal Semi 3D Stereo Enhancement
Current setup
Mic gain : +0dB [+0dB]
POP path : pre 3D
Sim. stereo : off
3D enhancement : off
Loudness : off
Mono output : MIX
Mic select : Mic1
ADC/DAC loopback : off
Extended ID : codec=0 rev=0 AMAP DSA=0 VRA
Extended status : VRA
PCM front DAC : 48000Hz
PCM ADC : 48000Hz
SPDIF Control : Consumer PCM Copyright Category=0x22 Generation=1 Rate=48kHz
Something else is strange, too. When I have the driver as a module and
unload it once, another load will succeed module-wise but the device is
unusable then. Here is the dmesg snippet:
[ 1462.343612] ACPI: PCI interrupt for device 0000:00:1f.5 disabled
[ 1487.092547] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
[ 1487.094499] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[ 1488.347180] ALSA sound/pci/ac97/ac97_codec.c:2053: AC'97 0 does not respond - RESET
[ 1488.347442] ACPI: PCI interrupt for device 0000:00:1f.5 disabled
[ 1488.347569] Intel ICH: probe of 0000:00:1f.5 failed with error -13
After another unload-load cycle, I get a working device again and this
in dmesg:
[ 2623.093209] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
[ 2623.095264] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[ 2623.975121] intel8x0_measure_ac97_clock: measured 50399 usecs
[ 2623.975268] intel8x0: clocking to 48000
Please let me know if you need more information to debug this issue.
It's really annoying :/
Many thanks in advance,
Hannes
Johannes Weiner <[email protected]> writes:
> Hi,
>
> 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.
>
> Before suspend, the registers look like this:
>
> 0:00 = 1990
> 0:02 = 0000
> 0:04 = 9f1f
> 0:06 = 801f
> 0:08 = 0000
> 0:0a = 801e
> 0:0c = 801f
> 0:0e = 801f
> 0:10 = 9f1f
> 0:12 = 9f1f
> 0:14 = 9f1f
> 0:16 = 9f1f
> 0:18 = 0b0b
> 0:1a = 0000
> 0:1c = 0000
> 0:1e = 0000
> 0:20 = 0000
> 0:22 = 0000
> 0:24 = 0000
> 0:26 = 000f
> 0:28 = 0201
> 0:2a = 0001
> 0:2c = bb80
> 0:2e = 0000
> 0:30 = 0000
> 0:32 = bb80
> 0:34 = 0000
> 0:36 = 0000
> 0:38 = 0000
> 0:3a = 0000
> 0:3c = 0000
> 0:3e = 0000
> 0:40 = 0000
> 0:42 = 0000
> 0:44 = 0000
> 0:46 = 0000
> 0:48 = 0000
> 0:4a = 0000
> 0:4c = 0000
> 0:4e = 0000
> 0:50 = 0000
> 0:52 = 0000
> 0:54 = 0000
> 0:56 = ffff
> 0:58 = 0000
> 0:5a = 0604
> 0:5c = 0000
> 0:5e = 0080
> 0:60 = 0023
> 0:62 = 0000
> 0:64 = 0000
> 0:66 = 0000
> 0:68 = 0824
> 0:6a = 0000
> 0:6c = 0000
> 0:6e = 0000
> 0:70 = 0000
> 0:72 = 0000
> 0:74 = 0000
> 0:76 = 0000
> 0:78 = 003c
> 0:7a = 0000
> 0:7c = 4352
> 0:7e = 5936
>
> and right after a resume, they look like this (annotations by me):
>
> 0:00 = 1990
> 0:02 = 8000 ! Master Volume
> 0:04 = 8000 ! Headphone Volume
> 0:06 = 8000 ! Master Mono Volume
> 0:08 = 0000
> 0:0a = 0000 ! PC Beep Volume
> 0:0c = 8008 ! Phone Volume
> 0:0e = 8008 ! Mic Volume
> 0:10 = 8808 ! Line In Volume
> 0:12 = 8808 ! CD Volume
> 0:14 = 8808 ! Video Volume
> 0:16 = 8808 ! AUX Volume
> 0:18 = 8808 ! PCM Volume
> 0:1a = 0000
> 0:1c = 8000 ! Record gain
> 0:1e = 0000
> 0:20 = 0000
> 0:22 = 0000
> 0:24 = 0000
> 0:26 = 000f
> 0:28 = 0201
> 0:2a = 0001
> 0:2c = bb80
> 0:2e = 0000
> 0:30 = 0000
> 0:32 = bb80
> 0:34 = 0000
> 0:36 = 0000
> 0:38 = 0000
> 0:3a = 0000
> 0:3c = 0000
> 0:3e = 0000
> 0:40 = 0000
> 0:42 = 0000
> 0:44 = 0000
> 0:46 = 0000
> 0:48 = 0000
> 0:4a = 0000
> 0:4c = 0000
> 0:4e = 0000
> 0:50 = 0000
> 0:52 = 0000
> 0:54 = 0000
> 0:56 = ffff
> 0:58 = 0000
> 0:5a = 0604
> 0:5c = 0000
> 0:5e = 0080
> 0:60 = 0023
> 0:62 = 0000
> 0:64 = 0000
> 0:66 = 0000
> 0:68 = 0824
> 0:6a = 0000
> 0:6c = 0000
> 0:6e = 0000
> 0:70 = 0000
> 0:72 = 0000
> 0:74 = 0000
> 0:76 = 0000
> 0:78 = 003c
> 0:7a = 0000
> 0:7c = 4352
> 0:7e = 5936
>
> When I run alsamixer and change around the values of Master and PCM in a
> purely random way - a bit higher/lower, mute/unmute, etc. - sound comes
> back to life.
>
> I remember to `fix' this by adding more delays between waking the device
> and syncing back the cache. But I think that took up to 6 seconds,
> sometimes, so there must be something else going on (see below).
>
> The chip is the following:
>
> 0-0/0: Cirrus Logic CS4299 rev 6
>
> PCI Subsys Vendor: 0x1014
> PCI Subsys Device: 0x0222
>
> Capabilities : -headphone out-
> DAC resolution : 20-bit
> ADC resolution : 18-bit
> 3D enhancement : Crystal Semi 3D Stereo Enhancement
>
> Current setup
> Mic gain : +0dB [+0dB]
> POP path : pre 3D
> Sim. stereo : off
> 3D enhancement : off
> Loudness : off
> Mono output : MIX
> Mic select : Mic1
> ADC/DAC loopback : off
> Extended ID : codec=0 rev=0 AMAP DSA=0 VRA
> Extended status : VRA
> PCM front DAC : 48000Hz
> PCM ADC : 48000Hz
> SPDIF Control : Consumer PCM Copyright Category=0x22 Generation=1 Rate=48kHz
>
> Something else is strange, too. When I have the driver as a module and
> unload it once, another load will succeed module-wise but the device is
> unusable then. Here is the dmesg snippet:
>
> [ 1462.343612] ACPI: PCI interrupt for device 0000:00:1f.5 disabled
> [ 1487.092547] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
> [ 1487.094499] PCI: Setting latency timer of device 0000:00:1f.5 to 64
> [ 1488.347180] ALSA sound/pci/ac97/ac97_codec.c:2053: AC'97 0 does not respond - RESET
> [ 1488.347442] ACPI: PCI interrupt for device 0000:00:1f.5 disabled
> [ 1488.347569] Intel ICH: probe of 0000:00:1f.5 failed with error -13
>
> After another unload-load cycle, I get a working device again and this
> in dmesg:
>
> [ 2623.093209] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
> [ 2623.095264] PCI: Setting latency timer of device 0000:00:1f.5 to 64
> [ 2623.975121] intel8x0_measure_ac97_clock: measured 50399 usecs
> [ 2623.975268] intel8x0: clocking to 48000
>
> Please let me know if you need more information to debug this issue.
> It's really annoying :/
>
> Many thanks in advance,
> Hannes
Ping?
Hey there,
[email protected] (Johannes Weiner) writes:
> Johannes Weiner <[email protected]> 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)
--
Mathieu Chouquet-Stringer
The sun itself sees not till heaven clears.
-- William Shakespeare --
At Sun, 29 Jun 2008 12:35:31 +0200,
Johannes Weiner wrote:
>
> Johannes Weiner <[email protected]> writes:
>
> > Hi,
> >
> > 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.
> >
> > Before suspend, the registers look like this:
> >
> > 0:00 = 1990
> > 0:02 = 0000
> > 0:04 = 9f1f
> > 0:06 = 801f
> > 0:08 = 0000
> > 0:0a = 801e
> > 0:0c = 801f
> > 0:0e = 801f
> > 0:10 = 9f1f
> > 0:12 = 9f1f
> > 0:14 = 9f1f
> > 0:16 = 9f1f
> > 0:18 = 0b0b
> > 0:1a = 0000
> > 0:1c = 0000
> > 0:1e = 0000
> > 0:20 = 0000
> > 0:22 = 0000
> > 0:24 = 0000
> > 0:26 = 000f
> > 0:28 = 0201
> > 0:2a = 0001
> > 0:2c = bb80
> > 0:2e = 0000
> > 0:30 = 0000
> > 0:32 = bb80
> > 0:34 = 0000
> > 0:36 = 0000
> > 0:38 = 0000
> > 0:3a = 0000
> > 0:3c = 0000
> > 0:3e = 0000
> > 0:40 = 0000
> > 0:42 = 0000
> > 0:44 = 0000
> > 0:46 = 0000
> > 0:48 = 0000
> > 0:4a = 0000
> > 0:4c = 0000
> > 0:4e = 0000
> > 0:50 = 0000
> > 0:52 = 0000
> > 0:54 = 0000
> > 0:56 = ffff
> > 0:58 = 0000
> > 0:5a = 0604
> > 0:5c = 0000
> > 0:5e = 0080
> > 0:60 = 0023
> > 0:62 = 0000
> > 0:64 = 0000
> > 0:66 = 0000
> > 0:68 = 0824
> > 0:6a = 0000
> > 0:6c = 0000
> > 0:6e = 0000
> > 0:70 = 0000
> > 0:72 = 0000
> > 0:74 = 0000
> > 0:76 = 0000
> > 0:78 = 003c
> > 0:7a = 0000
> > 0:7c = 4352
> > 0:7e = 5936
> >
> > and right after a resume, they look like this (annotations by me):
> >
> > 0:00 = 1990
> > 0:02 = 8000 ! Master Volume
> > 0:04 = 8000 ! Headphone Volume
> > 0:06 = 8000 ! Master Mono Volume
> > 0:08 = 0000
> > 0:0a = 0000 ! PC Beep Volume
> > 0:0c = 8008 ! Phone Volume
> > 0:0e = 8008 ! Mic Volume
> > 0:10 = 8808 ! Line In Volume
> > 0:12 = 8808 ! CD Volume
> > 0:14 = 8808 ! Video Volume
> > 0:16 = 8808 ! AUX Volume
> > 0:18 = 8808 ! PCM Volume
> > 0:1a = 0000
> > 0:1c = 8000 ! Record gain
> > 0:1e = 0000
> > 0:20 = 0000
> > 0:22 = 0000
> > 0:24 = 0000
> > 0:26 = 000f
> > 0:28 = 0201
> > 0:2a = 0001
> > 0:2c = bb80
> > 0:2e = 0000
> > 0:30 = 0000
> > 0:32 = bb80
> > 0:34 = 0000
> > 0:36 = 0000
> > 0:38 = 0000
> > 0:3a = 0000
> > 0:3c = 0000
> > 0:3e = 0000
> > 0:40 = 0000
> > 0:42 = 0000
> > 0:44 = 0000
> > 0:46 = 0000
> > 0:48 = 0000
> > 0:4a = 0000
> > 0:4c = 0000
> > 0:4e = 0000
> > 0:50 = 0000
> > 0:52 = 0000
> > 0:54 = 0000
> > 0:56 = ffff
> > 0:58 = 0000
> > 0:5a = 0604
> > 0:5c = 0000
> > 0:5e = 0080
> > 0:60 = 0023
> > 0:62 = 0000
> > 0:64 = 0000
> > 0:66 = 0000
> > 0:68 = 0824
> > 0:6a = 0000
> > 0:6c = 0000
> > 0:6e = 0000
> > 0:70 = 0000
> > 0:72 = 0000
> > 0:74 = 0000
> > 0:76 = 0000
> > 0:78 = 003c
> > 0:7a = 0000
> > 0:7c = 4352
> > 0:7e = 5936
> >
> > When I run alsamixer and change around the values of Master and PCM in a
> > purely random way - a bit higher/lower, mute/unmute, etc. - sound comes
> > back to life.
> >
> > I remember to `fix' this by adding more delays between waking the device
> > and syncing back the cache. But I think that took up to 6 seconds,
> > sometimes, so there must be something else going on (see below).
> >
> > The chip is the following:
> >
> > 0-0/0: Cirrus Logic CS4299 rev 6
> >
> > PCI Subsys Vendor: 0x1014
> > PCI Subsys Device: 0x0222
> >
> > Capabilities : -headphone out-
> > DAC resolution : 20-bit
> > ADC resolution : 18-bit
> > 3D enhancement : Crystal Semi 3D Stereo Enhancement
> >
> > Current setup
> > Mic gain : +0dB [+0dB]
> > POP path : pre 3D
> > Sim. stereo : off
> > 3D enhancement : off
> > Loudness : off
> > Mono output : MIX
> > Mic select : Mic1
> > ADC/DAC loopback : off
> > Extended ID : codec=0 rev=0 AMAP DSA=0 VRA
> > Extended status : VRA
> > PCM front DAC : 48000Hz
> > PCM ADC : 48000Hz
> > SPDIF Control : Consumer PCM Copyright Category=0x22 Generation=1 Rate=48kHz
> >
> > Something else is strange, too. When I have the driver as a module and
> > unload it once, another load will succeed module-wise but the device is
> > unusable then. Here is the dmesg snippet:
> >
> > [ 1462.343612] ACPI: PCI interrupt for device 0000:00:1f.5 disabled
> > [ 1487.092547] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
> > [ 1487.094499] PCI: Setting latency timer of device 0000:00:1f.5 to 64
> > [ 1488.347180] ALSA sound/pci/ac97/ac97_codec.c:2053: AC'97 0 does not respond - RESET
> > [ 1488.347442] ACPI: PCI interrupt for device 0000:00:1f.5 disabled
> > [ 1488.347569] Intel ICH: probe of 0000:00:1f.5 failed with error -13
> >
> > After another unload-load cycle, I get a working device again and this
> > in dmesg:
> >
> > [ 2623.093209] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
> > [ 2623.095264] PCI: Setting latency timer of device 0000:00:1f.5 to 64
> > [ 2623.975121] intel8x0_measure_ac97_clock: measured 50399 usecs
> > [ 2623.975268] intel8x0: clocking to 48000
> >
> > Please let me know if you need more information to debug this issue.
> > It's really annoying :/
> >
> > Many thanks in advance,
> > Hannes
>
> Ping?
Sorry for the delay. Just caught up your mail now.
Yes, it's an annoying bug, as I don't see any clear point what is
wrong in the current code. To be sure, does it happen also with
hibernation with the latest kernel, too? I vaguely remember some
cases that happen only with S2RAM and have been fixed recently.
Takashi
At 30 Jun 2008 20:58:03 +0200,
Mathieu Chouquet-Stringer wrote:
>
> Hey there,
>
> [email protected] (Johannes Weiner) writes:
> > Johannes Weiner <[email protected]> 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...
thanks,
Takashi
Hi,
Takashi Iwai <[email protected]> writes:
> At 30 Jun 2008 20:58:03 +0200,
> Mathieu Chouquet-Stringer wrote:
>>
>> Hey there,
>>
>> [email protected] (Johannes Weiner) writes:
>> > Johannes Weiner <[email protected]> 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
At Tue, 01 Jul 2008 16:37:42 +0200,
Johannes Weiner wrote:
>
> Hi,
>
> Takashi Iwai <[email protected]> writes:
>
> > At 30 Jun 2008 20:58:03 +0200,
> > Mathieu Chouquet-Stringer wrote:
> >>
> >> Hey there,
> >>
> >> [email protected] (Johannes Weiner) writes:
> >> > Johannes Weiner <[email protected]> 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.
> 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?
> >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.
thanks,
Takashi
Hi,
Takashi Iwai <[email protected]> writes:
> At Tue, 01 Jul 2008 16:37:42 +0200,
> Johannes Weiner wrote:
>>
>> Hi,
>>
>> Takashi Iwai <[email protected]> writes:
>>
>> > At 30 Jun 2008 20:58:03 +0200,
>> > Mathieu Chouquet-Stringer wrote:
>> >>
>> >> Hey there,
>> >>
>> >> [email protected] (Johannes Weiner) writes:
>> >> > Johannes Weiner <[email protected]> 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
At Tue, 01 Jul 2008 17:12:02 +0200,
Johannes Weiner wrote:
>
> Hi,
>
> Takashi Iwai <[email protected]> writes:
>
> > At Tue, 01 Jul 2008 16:37:42 +0200,
> > Johannes Weiner wrote:
> >>
> >> Hi,
> >>
> >> Takashi Iwai <[email protected]> writes:
> >>
> >> > At 30 Jun 2008 20:58:03 +0200,
> >> > Mathieu Chouquet-Stringer wrote:
> >> >>
> >> >> Hey there,
> >> >>
> >> >> [email protected] (Johannes Weiner) writes:
> >> >> > Johannes Weiner <[email protected]> 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.
thanks,
Takashi
Hi Takashi,
Takashi Iwai <[email protected]> writes:
> At Tue, 01 Jul 2008 17:12:02 +0200,
> Johannes Weiner wrote:
>>
>> Hi,
>>
>> Takashi Iwai <[email protected]> writes:
>>
>> > At Tue, 01 Jul 2008 16:37:42 +0200,
>> > Johannes Weiner wrote:
>> >>
>> >> Hi,
>> >>
>> >> Takashi Iwai <[email protected]> writes:
>> >>
>> >> > At 30 Jun 2008 20:58:03 +0200,
>> >> > Mathieu Chouquet-Stringer wrote:
>> >> >>
>> >> >> Hey there,
>> >> >>
>> >> >> [email protected] (Johannes Weiner) writes:
>> >> >> > Johannes Weiner <[email protected]> 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?
If you need any more information, please say so. This bug is really
annoying :/
Hannes
At Mon, 07 Jul 2008 01:17:38 +0200,
Johannes Weiner wrote:
>
> Hi Takashi,
>
> Takashi Iwai <[email protected]> writes:
>
> > At Tue, 01 Jul 2008 17:12:02 +0200,
> > Johannes Weiner wrote:
> >>
> >> Hi,
> >>
> >> Takashi Iwai <[email protected]> writes:
> >>
> >> > At Tue, 01 Jul 2008 16:37:42 +0200,
> >> > Johannes Weiner wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Takashi Iwai <[email protected]> writes:
> >> >>
> >> >> > At 30 Jun 2008 20:58:03 +0200,
> >> >> > Mathieu Chouquet-Stringer wrote:
> >> >> >>
> >> >> >> Hey there,
> >> >> >>
> >> >> >> [email protected] (Johannes Weiner) writes:
> >> >> >> > Johannes Weiner <[email protected]> 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