Bug 983861

Summary: HDA_intel: No sound after resume from standby with SigmaTel STAC9228
Product: [Fedora] Fedora Reporter: casi.wehmeier
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mail, superquad.vortex2
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-08 18:00:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of alsa-info.sh before standby
none
Output of alsa-info.sh after resume none

Description casi.wehmeier 2013-07-12 06:54:27 UTC 
Created attachment 772551 [details]
Output of alsa-info.sh before standby

Description of problem:
With my Dell Inspiron 1525 notebook (Intel Corporation 82801H ICH8 Family HD Audio Controller rev 02, codec SigmaTel STAC9228) I have no sound after resuming from standby in Fedora 18 (after a kernel Update) and 19. After a reboot sound works fine. I attached the output of alsa-info before (with working sound) and after resuming (with broken sound). Mixer levels in Gnome and alsa-mixer are o.k. , sound is not muted. A similar bug report for Fedora 18 exists already (Bug 974225). 

Version-Release number of selected component (if applicable):
3.9.9-301.fc19.i686

How reproducible:
Resume from standby after a reboot.

Steps to Reproduce:
1. Boot System -> Sound works
2. Go to standby (suspend to RAM S3)
3. Resume from standby -> Sound doesn't work

Actual results:
Sound doesn't work after resume from standby

Expected results:
Sound works after resume from standby

Additional info:
In Fedora 18 I was able to help me with scripts in /usr/lib/systemd/system-slepp which killed pulseaudio and rmmod / modprobe snd_hda_intel before standby / after resume. In Fedora 19 these scrips do not work. The module snd_hda_intel is in use although pulseaudio was killed before rmmod. I tried different models of the driver for the codec SigmaTel STAC9228 by creating /etc/modprobe.d/snd_hda_intel.conf. With the "ref" model I was able to resume from standby two times with working sound, then the sound didn't work any more, too.
Comment 1 casi.wehmeier 2013-07-12 06:55:58 UTC 
Created attachment 772552 [details]
Output of alsa-info.sh after resume
Comment 2 Raymond 2013-07-14 01:23:46 UTC 
pin ctls of speaker node should be OUT instead of zero

strange that unsolicited event was not enabled at line out Jack when the notebook has two headphone jacks


Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
  Control: name="Front Headphone Surround Jack", index=0, device=0
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x0221101f: [Jack] HP Out at Ext Front
    Conn = 1/8, Color = Black
    DefAssociation = 0x1, Sequence = 0xf
  Pin-ctls: 0xc0: OUT HP VREF_HIZ
  Unsolicited: tag=01, enabled=1
  Connection: 2
     0x02 0x03*

Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
  Control: name="Speaker Phantom Jack", index=0, device=0
  Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x90170110: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x00: VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x02

Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
  Control: name="Front Headphone Front Phantom Jack", index=0, device=0
  Pincap 0x00001737: IN OUT Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x02011020: [Jack] Line Out at Ext Front
    Conn = 1/8, Color = Black
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0x40: OUT VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x05
Comment 3 casi.wehmeier 2013-07-16 06:35:01 UTC 
A friendly editorial journalist of a German computer magazine gave me the hint, that the service alsa-state has to be stopped before snd_hda_intel can be unloaded. So I was able to fix my workaround scripts for Fedora 19.

Before standby:
killall pulseaudio && systemctl stop alsa-state.service && rmmod snd_hda_intel

After resume:
killall pulseaudio && modprobe snd_hda_intel &&  && systemctl start alsa-state.service

That's not elegant, but it works until there will hopefully be a bug fix.
Comment 4 Raymond 2013-07-25 15:30:53 UTC 
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=f3e351eef3a7fd1e36a3e18d4f2f069b00deb23c
Comment 5 Josh Boyer 2013-09-18 20:31:09 UTC 
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 6 Josh Boyer 2013-10-08 18:00:59 UTC 
(In reply to Raymond from comment #4)
> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/
> ?id=f3e351eef3a7fd1e36a3e18d4f2f069b00deb23c

That was included in 3.11-rc4, so it should be fixed.
Comment 7 Andras Horvath 2014-02-10 07:06:13 UTC 
The same problem still persists on the same hardware on an up-to-date Fedora 20 x64 with kernel version 3.12.9-301. No sound after resume.