Only headphones work after suspend on HP nx8220

by no longer works I mean nothing is heard irrespective of the level of the
volume status

Is there anything in dmesg when sound isn't working? Does the program show that
sound is being played?

nothing suspicious (to me) in dmesg, but I'll post a full one when I try this
again on the laptop.
The programs behave as if sound was there, the volume buttons as well, it's just
muted as if it was beyond the softwares control.

Matthew, I see you patched the intel8x0 driver in todays kernel for the
microphone jack support.
I think around there should be the patches that make sound work after resuming
from sleep.
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;h=3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da;f=sound/pci/intel8x0.c
The most likely to me looks the one named Fix resume on intel8x0 but some others
touch the PM code as well.
Unless you spot the fix quickly and import it I can try myself tomorrow. Also
there seems to be some overlap between your recent changes and upstreams
regarding the quirk entries for various laptops.

can not reproduce this after today's update,even though nothing specific to this
seems to have been introduced.
I'll need to retest with a preview or around to see which was the latest that
did not work for me.
Sound seems to work fine after multiple sleep/resume cycles.

happened today again with an oct 6 dist-upgrade. Will try with today's updates.

This is what I see new in dmesg (a coupel of weeks ago when sound wasn't
resuming I did not see errors in dmesg so it may not be related.)

Back to C!
[4302057.865000] write EC, IB not empty
[4302057.866000] ACPI-0423: *** Error: Handler for [EmbeddedControl]
returned AE_TIME
[4302057.867000] ACPI-0508: *** Error: Method execution failed
[\_SB_.C003.C004.C005.C114] (Node dffb63c0), AE_TIME
[4302057.868000] ACPI-0508: *** Error: Method execution failed [\_WAK] (Node
dffb1400), AE_TIME
[4302057.869000] ACPI-0567: *** Error: Method _WAK failed, AE_TIME

Hmm sound works but only through the headset! On resume from sleep only this is
enabled and all the while I have been listening to the speakers.
It may be that when I said earlier that sound works it was one of my headset
periods.
now I am rebuilding the module with various changes from upstream kernels see if
I can get it sorted out.

same problem with flight 4.

Sounds like a kernel issue

And one that also affects the nc6220.

As noted above, the headphone jack works after resume, but the speakers do not.

Rejecting unnecessary acpi-support task; bug remains open on linux-source-2.6.15

Same problem with Dell Inspiron 630m (didn't try with headphones). However, if I change volume level or mute/unmute (through direct keys), sound is back. I also tried with 'amixer set Master toggle' but the results are not consistent: 2 toggling are not always enough and last time I tried 'speaker-test' it blocked after printing (the line "Rate set to 48000Hz (requested 48000Hz)" is never printed):
"speaker-test 0.0.8

Playback device is plughw:0,0
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise"

After another experiment I wonder if there is not maybe in addition a timeout somewhere because speaker-test begins to work "suddenly".

Probably same problem: on HP nc8230 after a suspend speakers give no sound, headphones work fine.

Nothing interesting in dmesg but attaching it and lsmod output anyway.

dmesg after recoving from suspend and losing sound

lsmod output on my hp nc8230 after returning from suspect without sound

Confirm for Sony VAIO VGN-FS115MR
Dapper, kernel 2.6.15-26.46

After update of kernel much troubles after resume from hibernation: sound not work, ON button, bluetooth mouse :(

I have this exact problem with HP nw8240. After suspend-to-RAM, the internal speakers do not work, but headphones are ok. A suspend-to-disc (power off) cycle fixes the problem.

I tried comparing all the AC97 registers and other info in /proc/asound but they are identical in the working and not-working cases.

I have not done any ALSA development so I am not sure if there is an easy way of playing with the AC97 registers with a userspace program. Otherwise I am not sure how to easily debug this problem. Obviously something subtle has to be initialised after resume.

Is anyone else working on this?

I checked the hardware on my HP nw8240 laptop and the problem occurs because after suspend to RAM, the 5V power supply to the audio power amp IC is turned off. This is *not* controlled by the amplifier power down pin of the AC97 codec as would usually be the case, so nothing you can do with the AC97 will fix the problem. Indeed, all the AC97 registers are the same before and after suspend. The audio controller PCI configuration space registers are also the same.

Clearly, the nw8240 (and maybe other HP laptops) control the audio power amp power supply from somewhere else. I couldn't figure out physically where the signal comes from on the motherboard. I guess it has to do with the ACPI subsystem and the embedded controller-- but as I don't know much about this I am not able to debug it. I am not even sure whether the embedded controller is part of the Intel chipset, or a separate chip. I did play around with an adapted version of the kernel ibm_acpi module's ecdump utility to read and modify the embedded controller registers--but the best I could do by randomly tweaking the registers was crash my machine. Maybe someone who knows a bit about ACPI could suggest some productive ways of mapping out the hardware? Presumably other special features of the laptop, like the shock sensor, could also be accessed through ACPI if this could be figured out.

It is important to note that this issue is almost certainly HP-specific and not related to the numerous other "no sound after resume" issues that people have, which are fixable by simply setting the AC97 codec registers correctly.

It would be great if someone who is interested in this issue and knows something about ACPI and/or HP laptops could contact me so we could diagnose it. You can contact me on <email address hidden>

I have the same problem with Acer Aspire 1524WMLI.

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)

Built in speakers are deaf after resume, but sound works great if I plug headphones.

No sound problems with hibernation.

I forgot to add:

Linux owl 2.6.17-10-386 #2 Fri Oct 13 18:41:40 UTC 2006 i686 GNU/Linux

I just read that from /usr/share/doc/alsa-base/README.Debian. Maybe that could help.

reloading modules across APM suspend-and-resume
-----------------------------------------------
During suspension many peripherals are switched off; on resuming the
machine these peripherals need to be re-initialized. Many ALSA
drivers do this properly but some still do not.
...

This is finally fixed in kernel 2.6.20 (Feisty)!
However this kernel adds a new problem with suspend/resume on nx8220 and similar models: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/74877 that can be fixed with some kernel patching.

This problem still exists for me with the latest feisty kernel (2.6.20-13-generic). I am on an HP nc6000. Here are the relevant lines from lspci -vvv

00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
        Subsystem: Hewlett-Packard Company NC6000 laptop
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 11
        Region 0: I/O ports at 3000 [size=256]
        Region 1: I/O ports at 3880 [size=64]
        Region 2: Memory at a0100000 (32-bit, non-prefetchable) [size=512]
        Region 3: Memory at a0180000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

There are a number of bugs with similar symptoms, no sound after resume: bug #96230, bug #21574, bug# 94036. Noting them here in case they are related.

I can also confirm that this bug still exists with the latest feisty kernel (2.6.20-14-generic). dmesg doesn't show anything obvious relating to this, lspci -vv output is as follows:

00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
        Subsystem: Hewlett-Packard Company Unknown device 0934
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 22
        Region 0: I/O ports at 3100 [size=256]
        Region 1: I/O ports at 3200 [size=64]
        Region 2: Memory at c8c01000 (32-bit, non-prefetchable) [size=512]
        Region 3: Memory at c8c02000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Hi all,
I'm a relative newbie to linux (but was a bit of a windows pro before i made the switch from the dark side). I'm using Linux Mint 3 (more or less Ubuntu Feisty) on an HP NC6000.
 Does anyone have some newbie directions to correcting the no internal sound after resume problem?

Thanks in advance for any help!!!

Cheers,
Shaun

PS I've been using ubuntu and mint for a few months now and besides a few things that I haven't got around to addressing I totally dig linux.

I have the same problem, either using suspend 2 or suspend to ram. The problem does not exist on Fedora FC 5 using Suspend 2.

An update: as someone else has mentioned: at some stage this problem was fixed, and at least for me in the 2.6.19 kernel the problem had gone away. Since upgrading to 2.6.22.9 the problem has come back again on my nw8240.

I have no idea what actually fixed the problem or exactly which kernel version it was fixed in, or exactly when it came back.

See my notes at:

http://hpwiki.cactii.net/hpwiki/nw8240

I will try and put up some more detailed information. As explained there, you can fix it by hacking your hardware, but that is not really an ideal solution.

The main problem is I don't know where the extra signal comes from that turns the amplifier off so I am no closer to knowing how to fix it. I also do not understand why they have bother having this signal since it is already controlled from the AC97 codec anyway.

Help!

I have tracked it down! (Still don't know the mechanism, but there is a fix.)

The bug was fixed in commit 30b35399ceb2398d05837863476dcb12f12f3a82

It was broken again in commit 19bfafb2ed1a59efb979b6725ab7626a94f7e078

The latter only removes one line, a call to pci_set_power_state() in intel8x0_suspend() (a line that had been added in the first commit).

Simply unapplying that commit fixes the problem. The bizarre thing is that the latter commit was designated as correcting the speaker problem on suspend to RAM. At least for my laptop (HP nw8240) this patch actually *causes* the problem.

I tried unapplying the patch with still no joy on my nc6000. I'm glad that it fixes it for you, but something more quirky is going on.

This is related to https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/151111, except this one is for Gutsy.

I'm happy to finally have found a solution to this problem (I hope). It's probably not the right place to ask, but I've been searching on how to unapply this (or any) patch, without success...

Could anyone give some pointers or perhaps a how to on on how to do this? (I've been fiddling around with gentoo for a year, just don't know how to do this kind of stuff on ubuntu).

Thanks!

micschk <email address hidden> writes:

> I'm happy to finally have found a solution to this problem (I hope).
> It's probably not the right place to ask, but I've been searching on how
> to unapply this (or any) patch, without success...
>
> Could anyone give some pointers or perhaps a how to on on how to do
> this? (I've been fiddling around with gentoo for a year, just don't know
> how to do this kind of stuff on ubuntu).

It may still be touch-and-go; someone else said reversing this patch did
not fix the problem on their machine--so you'll have to try it and
see. It definitely works for me on my nw8240.

I don't know anything about dealing with the patch on ubuntu in
particular, but assuming that you can build the kernel, all you need to
do is go and manually change the relevant line of code and then rebuild
your kernel (or just the relevant module).

Good luck!

--
Mario Becroft <email address hidden>

Hey Mario,
Finally came to recompiling the kernel modules, works like a charm!
Thanks for your help.
- Michael

On Mon, 2007-12-31 at 08:32 +0000, Mario Becroft wrote:
> micschk <email address hidden> writes:
>
> > I'm happy to finally have found a solution to this problem (I hope).
> > It's probably not the right place to ask, but I've been searching on how
> > to unapply this (or any) patch, without success...
> >
> > Could anyone give some pointers or perhaps a how to on on how to do
> > this? (I've been fiddling around with gentoo for a year, just don't know
> > how to do this kind of stuff on ubuntu).
>
> It may still be touch-and-go; someone else said reversing this patch did
> not fix the problem on their machine--so you'll have to try it and
> see. It definitely works for me on my nw8240.
>
> I don't know anything about dealing with the patch on ubuntu in
> particular, but assuming that you can build the kernel, all you need to
> do is go and manually change the relevant line of code and then rebuild
> your kernel (or just the relevant module).
>
> Good luck!
>
> --
> Mario Becroft <email address hidden>
>

Mario,
is this still broken upstream?

Jani Monoses <email address hidden> writes:

> Mario,
> is this still broken upstream?

> --
> Only headphones work after suspend on HP nx8220
> https://bugs.launchpad.net/bugs/21574

I don't know about the latest linux, but as of 2.6.22.9 it was still
broken.

I just got mail from someone else who had the same problem and the same
fix worked for them.

But a while ago I heard from someone else who tried it and it did not
help with the problem on their system. It seems there may be a few
different problems that result in similar symptoms.

There may be a good reason for the original patch--it may fix some other
problem on a different system. This audio stuff is all a bit crazy. All
I know is, the fix works for me, and at least some other people.

I guess it really needs someone to look into this chipset in depth and
understand what is actually going on, rather than just randomly patching
things.

Sorry I can't be more specific.

--
Mario Becroft <email address hidden>

I can confirm that on 2.6.22-14 kernel that a suspend from RAM works except for Sound. This is on a Dell Dimension 8300 w/ 2GB RAM, PIV-HT and a SB Live sound card. The only way to rest the sound is reboot. I did not create a new Bug report as this seemed very similar to this thread.

Fixed in 2.6.24-11.15 as it is essentially the same as bug #151111