Bug 7236 - Headphone jack not detected after resuming from suspend-to-RAM
Summary: Headphone jack not detected after resuming from suspend-to-RAM
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Takashi Iwai
URL:
Keywords:
Depends on:
Blocks: 7216 56331
  Show dependency tree
 
Reported: 2006-09-29 20:35 UTC by Jae-hyeon Park
Modified: 2013-04-09 06:23 UTC (History)
10 users (show)

See Also:
Kernel Version: 2.6.28
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg during suspend-to-ram and resume (5.46 KB, text/plain)
2007-08-23 06:57 UTC, Jae-hyeon Park
Details
dmesg during software suspend 2 and resume (5.46 KB, text/plain)
2007-08-23 06:58 UTC, Jae-hyeon Park
Details
dmesg during suspend-to-ram and resume (8.17 KB, text/plain)
2007-08-23 07:10 UTC, Jae-hyeon Park
Details
dmesg from suspend-to-ram of kernel 2.6.23-rc4 (6.94 KB, text/plain)
2007-08-30 05:43 UTC, Jae-hyeon Park
Details

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 2.6.22.2 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 2.6.22.2 + 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 2.6.26.5 and it still does not work.
Comment 22 Zhang Rui 2008-11-19 22:53:04 UTC
ping jani
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.

Note You need to log in before you can comment on or make changes to this bug.