|Summary:||Headphone jack not detected after resuming from suspend-to-RAM|
|Product:||Drivers||Reporter:||Jae-hyeon Park (jhyeon)|
|Component:||Sound(ALSA)||Assignee:||Takashi Iwai (tiwai)|
|Severity:||normal||CC:||acpi-bugzilla, alan, christoph.neuroth, christoph.neuroth, jani, me, protasnb, rjw, rjwysocki, tiwai|
|Bug Depends on:|
|Bug Blocks:||7216, 56331|
dmesg during suspend-to-ram and resume
dmesg during software suspend 2 and resume
dmesg during suspend-to-ram and resume
dmesg from suspend-to-ram of kernel 2.6.23-rc4
Description Jae-hyeon Park 2006-09-29 20:35:46 UTC
Most recent kernel where this bug did not occur: unknown Distribution: Debian testing (etch) as of 2006-09-21 Hardware Environment: Thinkpad X41 Tablet Software Environment: gcc-3.4 $ lsmod | grep snd snd_intel8x0 30364 1 snd_intel8x0m 14924 0 snd_ac97_codec 95392 2 snd_intel8x0,snd_intel8x0m snd_ac97_bus 1920 1 snd_ac97_codec snd_pcm_oss 45472 0 snd_mixer_oss 16640 1 snd_pcm_oss snd_pcm 75656 4 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss snd_timer 21636 1 snd_pcm snd 46372 9 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 7904 1 snd snd_page_alloc 8008 3 snd_intel8x0,snd_intel8x0m,snd_pcm Problem Description: If a headphone jack is plugged in, the buildt-in speaker should be muted and sound should be played through the headphones. This is usually the case. After resuming from suspend-to-RAM, however, the built-in speaker plays sound and the headphones keep silent, as if the jack were unplugged. This problem does not happen after resuming from software suspend 2. Steps to reproduce: 1. Turn on the PC and boot the kernel. 2. Play some sound such as an mp3 music with no headphone jack plugged in. Sound plays through the speaker. 3. Plug in the jack. The speaker is muted and sound plays through the headphones. 4. Unplug the jack. 5. Suspend-to-RAM the PC. 6. Resume the PC. 7. Play the mp3 music. It plays through the speaker. 8. Plug in the jack. Music still plays through the speaker and the headphones don't work.
Comment 1 Rafael J. Wysocki 2006-11-15 04:49:12 UTC
Have you tried the suspend to disk without the suspend2 patch?
Comment 2 Jae-hyeon Park 2006-11-15 06:22:46 UTC
I just tried suspend-to-disk in vanilla 2.6.18. Headphones work okay even after a suspend-to-disk, as was the case with software suspend 2. One thing to add is that suspend-to-disk or software suspend 2, temporarily "cures" the problem, which means that if I do a suspend-to-disk and resume from it, after Step 8 in my first posting, then the headphones begin to work again. It seems that rebooting somehow resets the machinery of recognizing headphone jack insertion. Of course, one more suspend-to-RAM brings back the problem.
Comment 3 Rafael J. Wysocki 2006-11-19 04:07:44 UTC
*** Bug 6072 has been marked as a duplicate of this bug. ***
Comment 4 Adrian Bunk 2006-11-19 14:58:49 UTC
*** Bug 6181 has been marked as a duplicate of this bug. ***
Comment 5 Tommi Kyntola 2007-03-08 01:49:26 UTC
I'd like to point out here the same this as I said in bug #7236. I have exact opposite. Up to 2.6.18 things worked ok, then commit 30b35399ceb2398d05837863476dcb12f12f3a82 in 2.6.19-rc3 triggers this bug. After a s2mem speakers are dead and headphones play music ok. Suspend to disk after that fixes this until anothed suspend to memory is performed. Headphone jack sense setting has no effect after the s2mem. rmmod/insmod for any/all snd module has no effect after the s2mem. Speakers remain dead (as if headphones were constantly plugged in). All I see is a bunch of : codec_write 0: semaphore is not ready for register 0xXX messages. This strongly seems related to this bug. And removing the pci_set_power_state line from intel8x0_suspend function _avoids_ the problem and things work as before.
Comment 6 Tommi Kyntola 2007-03-08 01:51:24 UTC
oops, obviously I meant the I meant the #6244 ...
Comment 7 Rafael J. Wysocki 2007-05-30 10:46:30 UTC
Any progress with this bug?
Comment 8 Natalie Protasevich 2007-07-23 17:13:24 UTC
Any updates on this bug please. Thanks.
Comment 9 Tommi Kyntola 2007-07-27 04:50:50 UTC
Well, my comment about this bug can be disregarded as a patch (19bfafb2ed1...) that prevented the pci power state setting during s3 suspend fixed the speakers-dead-problem after s3 cycle on affected HP laptos. I only mentioned it because the symptoms were at the time also explainable by the headphone jack state not working properly after an s3 cycle but the cause has likely more to do with the internal amplifier settings getting b0rked/not-restored propely (but that's not much more than guess-work either) and hence it's probably unrelated to this bug.
Comment 10 Rafael J. Wysocki 2007-08-08 10:47:34 UTC
Well, I think that we have not enough information. Rejecting.
Comment 11 Jae-hyeon Park 2007-08-22 22:36:52 UTC
I wonder what kind of progress or update you want to hear. I tried kernel 188.8.131.52 recently, and the problem was remaining without any change. After a suspend-to-ram, sound plays through the built-in speaker regardless of whether a headphone is plugged in or not.
Comment 12 Natalie Protasevich 2007-08-22 22:54:51 UTC
Please attach your dmesgto the bugzilla . I think Tommi mentioned error messages that were there. Jae-hyeon, you probably have those too. Thanks.
Comment 13 Jae-hyeon Park 2007-08-23 06:57:57 UTC
Created attachment 12505 [details] dmesg during suspend-to-ram and resume
Comment 14 Jae-hyeon Park 2007-08-23 06:58:47 UTC
Created attachment 12506 [details] dmesg during software suspend 2 and resume
Comment 15 Jae-hyeon Park 2007-08-23 07:06:39 UTC
I attached dmesg produced during a suspend-to-ram and resume cycle, but I don't see anything like an error message. I also attached dmesg during a software suspend 2 and resume, which as I said above, revives the headphone. I used kernel 184.108.40.206 + software suspend 2 2.2.10. Should I try a patch or a more recent version of kernel?
Comment 16 Jae-hyeon Park 2007-08-23 07:10:29 UTC
Created attachment 12507 [details] dmesg during suspend-to-ram and resume Sorry, the previous attachment was a dmesg of software suspend 2.
Comment 17 Rafael J. Wysocki 2007-08-29 10:05:47 UTC
Can you please try the 2.6.23-rc4 kernel and produce a suspend-to-RAM dmesg from that, if possible?
Comment 18 Jae-hyeon Park 2007-08-30 05:43:10 UTC
Created attachment 12628 [details] dmesg from suspend-to-ram of kernel 2.6.23-rc4 This is dmesg from suspend-to-ram. I used vanilla kernel 2.6.23-rc4. The problem is remaining yet. I don't see many changes in dmesg from the previous version except a few occurrences of "ACPI handle has no context!" Should I enable some debugging options?
Comment 19 Rafael J. Wysocki 2007-08-31 07:26:39 UTC
No, thanks. I wanted to confirm that the problem is still present.
Comment 20 Jani Monoses 2008-09-22 22:15:29 UTC
This has been working since Ubuntu 8.04 (2.6.24)
Comment 21 Jae-hyeon Park 2008-10-07 18:46:30 UTC
(In reply to comment #20) > This has been working since Ubuntu 8.04 (2.6.24) > Does it work with vanilla 2.6.24, or do you need a kernel patched for Ubuntu? I tried vanilla 220.127.116.11 and it still does not work.
Comment 22 Zhang Rui 2008-11-19 22:53:04 UTC
Comment 23 Jani Monoses 2008-11-19 23:01:23 UTC
I use standard Ubuntu kernels which may have been patched. I did not look into the details. It also works with the kernel in 8.10
Comment 24 Jae-hyeon Park 2008-11-20 04:38:30 UTC
(In reply to comment #23) > I use standard Ubuntu kernels which may have been patched. I did not look > into > the details. It also works with the kernel in 8.10 > Do you use Thinkpad X41 Tablet? I will try an Ubuntu kernel if I can.
Comment 25 Jani Monoses 2008-11-20 04:52:57 UTC
no, HP 8220 nx laptop.
Comment 26 Tobias Florek 2008-11-26 15:31:00 UTC
i can't comment on the ubuntu kernel, but it does not work with vanilla 2.6.28-rc6.
Comment 27 Jae-hyeon Park 2008-12-26 13:04:06 UTC
2.6.28 does not work.
Comment 28 Rafael J. Wysocki 2009-10-25 10:42:04 UTC
I guess the issue is still present in 2.6.32-rc5, is this correct?
Comment 29 Jae-hyeon Park 2009-10-25 15:38:45 UTC
Now I am using a different model of laptop, and so I cannot test this issue any more. Sorry. I wish somebody else with a Thinkpad X41 Tablet could contribute. Thanks. (In reply to comment #28) > I guess the issue is still present in 2.6.32-rc5, is this correct?
Comment 30 christoph.neuroth 2009-10-26 15:00:04 UTC
I can't reproduce this anymore on 2.6.31.
Comment 31 christoph.neuroth 2009-10-26 15:00:44 UTC
(I'm on a X41 non-tablet, but had the same problem on earlier kernels.)
Comment 32 Rafael J. Wysocki 2009-10-26 16:23:46 UTC
OK, closing. If the problem reappears, please file a new bug report.