Kernel Bug Tracker – Bug 7236
Headphone jack not detected after resuming from suspend-to-RAM
Last modified: 2013-04-09 06:23:26 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
$ 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_timer 21636 1 snd_pcm
snd 46372 9
soundcore 7904 1 snd
snd_page_alloc 8008 3 snd_intel8x0,snd_intel8x0m,snd_pcm
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.
Have you tried the suspend to disk without the suspend2 patch?
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.
*** Bug 6072 has been marked as a duplicate of this bug. ***
*** Bug 6181 has been marked as a duplicate of this bug. ***
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
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.
oops, obviously I meant the I meant the #6244 ...
Any progress with this bug?
Any updates on this bug please.
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.
Well, I think that we have not enough information. Rejecting.
I wonder what kind of progress or update you want to hear.
I tried kernel 184.108.40.206 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.
Please attach your dmesgto the bugzilla . I think Tommi mentioned error messages that were there. Jae-hyeon, you probably have those too.
Created attachment 12505 [details]
dmesg during suspend-to-ram and resume
Created attachment 12506 [details]
dmesg during software suspend 2 and resume
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 220.127.116.11 + software suspend 2 2.2.10.
Should I try a patch or a more recent version of kernel?
Created attachment 12507 [details]
dmesg during suspend-to-ram and resume
Sorry, the previous attachment was a dmesg of software suspend 2.
Can you please try the 2.6.23-rc4 kernel and produce a suspend-to-RAM dmesg from that, if possible?
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?
No, thanks. I wanted to confirm that the problem is still present.
This has been working since Ubuntu 8.04 (2.6.24)
(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 18.104.22.168 and it still does not work.
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
(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.
no, HP 8220 nx laptop.
i can't comment on the ubuntu kernel, but it does not work with vanilla 2.6.28-rc6.
2.6.28 does not work.
I guess the issue is still present in 2.6.32-rc5, is this correct?
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.
(In reply to comment #28)
> I guess the issue is still present in 2.6.32-rc5, is this correct?
I can't reproduce this anymore on 2.6.31.
(I'm on a X41 non-tablet, but had the same problem on earlier kernels.)
OK, closing. If the problem reappears, please file a new bug report.