Bug 7236
| 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) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, alan, christoph.neuroth, christoph.neuroth, jani, me, protasnb, rjw, rjwysocki, tiwai |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.28 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 7216, 56331 | ||
| Attachments: |
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
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 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. oops, obviously I meant the I meant the #6244 ... Any progress with this bug? Any updates on this bug please. Thanks. 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 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. Please attach your dmesgto the bugzilla . I think Tommi mentioned error messages that were there. Jae-hyeon, you probably have those too. Thanks. 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 2.6.22.2 + 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 2.6.26.5 and it still does not work. ping jani 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. Thanks. (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. |