* Longstanding bug in ac97/intel8x0 resume/init @ 2008-06-03 23:31 Johannes Weiner 2008-06-29 10:35 ` Johannes Weiner 0 siblings, 1 reply; 11+ messages in thread From: Johannes Weiner @ 2008-06-03 23:31 UTC (permalink / raw) To: Takashi Iwai, Jaroslav Kysela; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-06-03 23:31 Longstanding bug in ac97/intel8x0 resume/init Johannes Weiner @ 2008-06-29 10:35 ` Johannes Weiner 2008-06-30 18:58 ` Mathieu Chouquet-Stringer 2008-07-01 13:42 ` Takashi Iwai 0 siblings, 2 replies; 11+ messages in thread From: Johannes Weiner @ 2008-06-29 10:35 UTC (permalink / raw) To: Takashi Iwai; +Cc: Jaroslav Kysela, linux-kernel Johannes Weiner <hannes@saeurebad.de> 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-06-29 10:35 ` Johannes Weiner @ 2008-06-30 18:58 ` Mathieu Chouquet-Stringer 2008-07-01 13:43 ` Takashi Iwai 2008-07-01 13:42 ` Takashi Iwai 1 sibling, 1 reply; 11+ messages in thread From: Mathieu Chouquet-Stringer @ 2008-06-30 18:58 UTC (permalink / raw) To: Johannes Weiner; +Cc: Takashi Iwai, Jaroslav Kysela, linux-kernel Hey there, hannes@saeurebad.de (Johannes Weiner) writes: > Johannes Weiner <hannes@saeurebad.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) -- Mathieu Chouquet-Stringer The sun itself sees not till heaven clears. -- William Shakespeare -- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-06-30 18:58 ` Mathieu Chouquet-Stringer @ 2008-07-01 13:43 ` Takashi Iwai 2008-07-01 14:37 ` Johannes Weiner 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2008-07-01 13:43 UTC (permalink / raw) To: Mathieu Chouquet-Stringer; +Cc: Johannes Weiner, Jaroslav Kysela, linux-kernel At 30 Jun 2008 20:58:03 +0200, Mathieu Chouquet-Stringer wrote: > > Hey there, > > hannes@saeurebad.de (Johannes Weiner) writes: > > Johannes Weiner <hannes@saeurebad.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... thanks, Takashi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-07-01 13:43 ` Takashi Iwai @ 2008-07-01 14:37 ` Johannes Weiner 2008-07-01 14:46 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Johannes Weiner @ 2008-07-01 14:37 UTC (permalink / raw) To: Takashi Iwai; +Cc: Mathieu Chouquet-Stringer, Jaroslav Kysela, linux-kernel Hi, Takashi Iwai <tiwai@suse.de> writes: > At 30 Jun 2008 20:58:03 +0200, > Mathieu Chouquet-Stringer wrote: >> >> Hey there, >> >> hannes@saeurebad.de (Johannes Weiner) writes: >> > Johannes Weiner <hannes@saeurebad.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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-07-01 14:37 ` Johannes Weiner @ 2008-07-01 14:46 ` Takashi Iwai 2008-07-01 15:12 ` Johannes Weiner 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2008-07-01 14:46 UTC (permalink / raw) To: Johannes Weiner; +Cc: Mathieu Chouquet-Stringer, Jaroslav Kysela, linux-kernel At Tue, 01 Jul 2008 16:37:42 +0200, Johannes Weiner wrote: > > Hi, > > Takashi Iwai <tiwai@suse.de> writes: > > > At 30 Jun 2008 20:58:03 +0200, > > Mathieu Chouquet-Stringer wrote: > >> > >> Hey there, > >> > >> hannes@saeurebad.de (Johannes Weiner) writes: > >> > Johannes Weiner <hannes@saeurebad.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. > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-07-01 14:46 ` Takashi Iwai @ 2008-07-01 15:12 ` Johannes Weiner 2008-07-01 15:16 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Johannes Weiner @ 2008-07-01 15:12 UTC (permalink / raw) To: Takashi Iwai; +Cc: Mathieu Chouquet-Stringer, Jaroslav Kysela, linux-kernel Hi, Takashi Iwai <tiwai@suse.de> writes: > At Tue, 01 Jul 2008 16:37:42 +0200, > Johannes Weiner wrote: >> >> Hi, >> >> Takashi Iwai <tiwai@suse.de> writes: >> >> > At 30 Jun 2008 20:58:03 +0200, >> > Mathieu Chouquet-Stringer wrote: >> >> >> >> Hey there, >> >> >> >> hannes@saeurebad.de (Johannes Weiner) writes: >> >> > Johannes Weiner <hannes@saeurebad.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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-07-01 15:12 ` Johannes Weiner @ 2008-07-01 15:16 ` Takashi Iwai 2008-07-06 23:17 ` Johannes Weiner 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2008-07-01 15:16 UTC (permalink / raw) To: Johannes Weiner; +Cc: Mathieu Chouquet-Stringer, Jaroslav Kysela, linux-kernel At Tue, 01 Jul 2008 17:12:02 +0200, Johannes Weiner wrote: > > Hi, > > Takashi Iwai <tiwai@suse.de> writes: > > > At Tue, 01 Jul 2008 16:37:42 +0200, > > Johannes Weiner wrote: > >> > >> Hi, > >> > >> Takashi Iwai <tiwai@suse.de> writes: > >> > >> > At 30 Jun 2008 20:58:03 +0200, > >> > Mathieu Chouquet-Stringer wrote: > >> >> > >> >> Hey there, > >> >> > >> >> hannes@saeurebad.de (Johannes Weiner) writes: > >> >> > Johannes Weiner <hannes@saeurebad.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. thanks, Takashi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-07-01 15:16 ` Takashi Iwai @ 2008-07-06 23:17 ` Johannes Weiner 2008-07-09 18:39 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: Johannes Weiner @ 2008-07-06 23:17 UTC (permalink / raw) To: Takashi Iwai; +Cc: Mathieu Chouquet-Stringer, Jaroslav Kysela, linux-kernel Hi Takashi, Takashi Iwai <tiwai@suse.de> writes: > At Tue, 01 Jul 2008 17:12:02 +0200, > Johannes Weiner wrote: >> >> Hi, >> >> Takashi Iwai <tiwai@suse.de> writes: >> >> > At Tue, 01 Jul 2008 16:37:42 +0200, >> > Johannes Weiner wrote: >> >> >> >> Hi, >> >> >> >> Takashi Iwai <tiwai@suse.de> writes: >> >> >> >> > At 30 Jun 2008 20:58:03 +0200, >> >> > Mathieu Chouquet-Stringer wrote: >> >> >> >> >> >> Hey there, >> >> >> >> >> >> hannes@saeurebad.de (Johannes Weiner) writes: >> >> >> > Johannes Weiner <hannes@saeurebad.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? If you need any more information, please say so. This bug is really annoying :/ Hannes ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-07-06 23:17 ` Johannes Weiner @ 2008-07-09 18:39 ` Takashi Iwai 0 siblings, 0 replies; 11+ messages in thread From: Takashi Iwai @ 2008-07-09 18:39 UTC (permalink / raw) To: Johannes Weiner; +Cc: Mathieu Chouquet-Stringer, Jaroslav Kysela, linux-kernel At Mon, 07 Jul 2008 01:17:38 +0200, Johannes Weiner wrote: > > Hi Takashi, > > Takashi Iwai <tiwai@suse.de> writes: > > > At Tue, 01 Jul 2008 17:12:02 +0200, > > Johannes Weiner wrote: > >> > >> Hi, > >> > >> Takashi Iwai <tiwai@suse.de> writes: > >> > >> > At Tue, 01 Jul 2008 16:37:42 +0200, > >> > Johannes Weiner wrote: > >> >> > >> >> Hi, > >> >> > >> >> Takashi Iwai <tiwai@suse.de> writes: > >> >> > >> >> > At 30 Jun 2008 20:58:03 +0200, > >> >> > Mathieu Chouquet-Stringer wrote: > >> >> >> > >> >> >> Hey there, > >> >> >> > >> >> >> hannes@saeurebad.de (Johannes Weiner) writes: > >> >> >> > Johannes Weiner <hannes@saeurebad.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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Longstanding bug in ac97/intel8x0 resume/init 2008-06-29 10:35 ` Johannes Weiner 2008-06-30 18:58 ` Mathieu Chouquet-Stringer @ 2008-07-01 13:42 ` Takashi Iwai 1 sibling, 0 replies; 11+ messages in thread From: Takashi Iwai @ 2008-07-01 13:42 UTC (permalink / raw) To: Johannes Weiner; +Cc: Jaroslav Kysela, linux-kernel At Sun, 29 Jun 2008 12:35:31 +0200, Johannes Weiner wrote: > > Johannes Weiner <hannes@saeurebad.de> 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-07-09 14:40 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-06-03 23:31 Longstanding bug in ac97/intel8x0 resume/init Johannes Weiner 2008-06-29 10:35 ` Johannes Weiner 2008-06-30 18:58 ` Mathieu Chouquet-Stringer 2008-07-01 13:43 ` Takashi Iwai 2008-07-01 14:37 ` Johannes Weiner 2008-07-01 14:46 ` Takashi Iwai 2008-07-01 15:12 ` Johannes Weiner 2008-07-01 15:16 ` Takashi Iwai 2008-07-06 23:17 ` Johannes Weiner 2008-07-09 18:39 ` Takashi Iwai 2008-07-01 13:42 ` Takashi Iwai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox