Bug 1313434 - No audio with kernel 4.4 [NEEDINFO]
No audio with kernel 4.4
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
25
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
: 1313849 (view as bug list)
Depends On: 1313790 1321266
Blocks: 1313849
  Show dependency treegraph
 
Reported: 2016-03-01 10:26 EST by Francisco Cribari
Modified: 2017-07-04 09:27 EDT (History)
39 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 14:09:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
james.r.wyatt: needinfo? (kernel-maint)


Attachments (Terms of Use)
enable capture for ADC0 (47.50 KB, image/png)
2016-07-08 12:14 EDT, Enrico Tagliavini
no flags Details

  None (edit)
Description Francisco Cribari 2016-03-01 10:26:05 EST
Description of problem:

After upgrading to kernel 4.4 (4.4.2-301.fc23.x86_64) I have no sound. I run Fedora 23 on a Dell XPS 13 (model 9343, 2015 - bios A07). I run Fedora on this notebook since version 22 and I never had problems with audio. 

I did made several cold reboots but still no sound.

cat /proc/asound/cards yields:

0 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xf741c000 irq 50

1 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7418000 irq 49

alsa-info.sh --no-upload yields:

cat: /sys/module/snd_soc_sst_broadwell/parameters/*: No such file or directory

Your ALSA information is in /tmp/alsa-info.txt.Pp6IMe7EJQ

This file is available at

https://dl.dropboxusercontent.com/u/2171814/alsa-info.txt.Pp6IMe7EJQ

lspci -nn | grep -i audio yields

00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09)

play -l yields

**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 0: System Playback/Capture (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 1: Offload0 Playback (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 2: Offload1 Playback (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

With kernel 4.3.5, I get: 

aplay -l 
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC3263 Analog [ALC3263 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

lspci -nn | grep -i audio
00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09)
00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition Audio Controller [8086:9ca0] (rev 03)

There is an Arch wiki for this machine. Even though the Arch kernel is different from the Fedora kernel, the wiki contains important information. See 

https://wiki.archlinux.org/index.php/Dell_XPS_13_(2015)

There we read that several Arch users are having the same problem after they upgraded to kernel 4.4. 

Version-Release number of selected component (if applicable):


How reproducible:

Very reproducible


Steps to Reproduce:
1. Boot into kernel 4.4. 
2. Test sound. 
3.

Actual results:

No sound whatsoever. 


Expected results:

Audio should work. 


Additional info:
Comment 1 Laura Abbott 2016-03-02 12:46:43 EST
*** Bug 1313849 has been marked as a duplicate of this bug. ***
Comment 2 Laura Abbott 2016-03-02 13:29:08 EST
The CONFIG_ACPI_REV_OVERRIDE_POSSIBLE that switches between HDA and I2S mode got turned off unintentionally when I did the upgrade to 4.4. I turned it back on and this should be showing up when I do the 4.4.4 update tomorrow or friday. You can run the scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=13204127 as well when it finishes. Make sure you do multiple cold boots to get it to properly switch.
Comment 3 Laura Abbott 2016-03-02 16:38:55 EST
Someone pointed out that Dell XPS 13 does work without the config option if you change alsa setttings https://bugzilla.redhat.com/show_bug.cgi?id=1255070#c76.

Long term we want to get rid of that config option if we can. Please test with the settings suggested in that comment before trying the scratch build.
Comment 4 bhrti45mok 2016-03-02 17:53:27 EST
Applying the alsa settings gave me sound again (like https://bugzilla.redhat.com/show_bug.cgi?id=1255070#c77 and the mentioned cracking).

Furthermore I could record audio through the internal microphone with arecord.
But pavucontrol shows at "Input Devices" for broadwell-rt286 only the port "Microphone (unplugged)" and GNOME Settings > Sound has no device available for "Input".
Comment 5 mvetter 2016-03-02 21:59:26 EST
In addition to fixing this current regression, can we also make sure this problem doesn't pop up again in the F23->F24 upgrade?  This exact same problem happened in the last upgrade (F22->F23).
Comment 6 Francisco Cribari 2016-03-03 05:58:26 EST
Still no sound with kernel 4.4.3-300.fc23.x86_64 .
Comment 7 Michael Meschenmoser 2016-03-03 06:53:14 EST
As requested in Bug 1255070 Comment 78:

"""
The alsamixer settings from Bug 1255070 Comment 76 did the trick.

-> Working sound with 4.4.2-301.fc23.x86_64 & broadwell-rt268
(1 sec After sound playback stops the headphones are cracking once, but from quick testing no glitches/noises)

Seems I didn't try enough settings after Bug 1255070 Comment 69 pointed out where to search...
"""

"""
The alsamixer settings from Bug 1255070 Comment 76 also did the trick for me.

Model: 2015 Dell XPS 13 (9343)
Kernel: 4.4.3-300.fc23.x86_64
Bios: A07

Alsa packages installed:

alsa-lib-1.0.29-2.fc23.x86_64
alsa-plugins-pulseaudio-1.0.29-2.fc23.i686
alsa-plugins-pulseaudio-1.0.29-2.fc23.x86_64
alsa-ucm-1.0.29-2.fc23.x86_64
alsa-utils-1.0.29-2.fc23.x86_64
alsa-lib-1.0.29-2.fc23.i686
"""

It seems like a correct, but perhaps more time needing, fix would be to fix the (default?) alsa settings.
Comment 8 Francisco Cribari 2016-03-03 10:07:32 EST
Using the alsamixer settings cited above I have sound with kernel 4.4.3-300.fc23.x86_64 . 

However, the internal mic does not work. Screenshot available at 

https://dl.dropboxusercontent.com/u/2171814/sound-input.png
Comment 9 Francisco Cribari 2016-03-03 19:57:00 EST
After using the computer for several hours, sound was gone, restored by a reboot. Still no mic.
Comment 10 Francisco Cribari 2016-03-03 21:13:50 EST
A couple of hours after reboot, sound was gone again.
Comment 11 Laura Abbott 2016-03-03 21:14:42 EST
After talking it over with others, I'm going to drop the CONFIG_ACPI_REV_OVERRIDE_POSSIBLE from 4.4 for at least another stable release. It's good to get an idea about what is actually working and not working so we can actually file bugs to make  sound work.
Comment 12 mvetter 2016-03-03 23:19:01 EST
(In reply to Laura Abbott from comment #11)
> After talking it over with others, I'm going to drop the
> CONFIG_ACPI_REV_OVERRIDE_POSSIBLE from 4.4 for at least another stable
> release. It's good to get an idea about what is actually working and not
> working so we can actually file bugs to make  sound work.

So how do I get sound working on XPS 13 with kernel 4.4 _without_ mucking about with obscure ALSA settings ?

For example, will there be an update to the ALSA packages?

The current set of updates for F23 will cause the sound breakage (regression) on many systems (not just the XPS 13).  Is this wise?

I do realize that Fedora is essentially a continuous test release for RHEL, but breaking things willy-nilly and then hoping people will file bugs is not exactly the greatest way to treat users. In fact, I would say it borders on being unethical.

I'm tempted to simply versionlock the kernel to 4.3.
Comment 13 mvetter 2016-03-03 23:53:12 EST
For other users reading the comments here:

To prevent the silliness with the broken kernel 4.4 upgrade from bothering you each time you do an update, follow these steps:

- make sure you have at least two kernels installed; by default dnf should keep the last 3 kernel versions around, but to make sure:
  sudo dnf install kernel-4.3.5-300.fc23.x86_64

- reboot into kernel 4.3 by changing the kernel version during boot

- remove kernel 4.4:
  sudo dnf remove kernel-4.4.3-300.fc23.x86_64
  sudo dnf remove kernel-modules-4.4.3-300.fc23.x86_64
  sudo dnf remove kernel-core-4.4.3-300.fc23.x86_64

- install the versionlock dnf plugin:
  sudo dnf install python-dnf-plugins-extras-versionlock.noarch
  sudo dnf install python3-dnf-plugins-extras-versionlock.noarch

- lock the kernel to 4.3:
  sudo dnf versionlock kernel-4.3.5-300.fc23.x86_64
  sudo dnf versionlock kernel-modules-4.3.5-300.fc23.x86_64
  sudo dnf versionlock kernel-core-4.3.5-300.fc23.x86_64

- cold start twice (ie. turn the machine completely off twice) to get the previous sound behavior.

The versionlock will prevent the kernel from being updated during normal updates. To remove the versionlock:
sudo dnf versionlock clear
Comment 14 H.J. Lu 2016-03-04 10:43:07 EST
(In reply to Laura Abbott from comment #11)
> After talking it over with others, I'm going to drop the
> CONFIG_ACPI_REV_OVERRIDE_POSSIBLE from 4.4 for at least another stable
> release. It's good to get an idea about what is actually working and not
> working so we can actually file bugs to make  sound work.

FYI, CONFIG_ACPI_REV_OVERRIDE_POSSIBLE causes the 32-bit kernel to reboot
as soon as the 32-bit kernel boots.
Comment 15 mvetter 2016-03-08 01:02:59 EST
Related bug in Arch:
https://bugs.archlinux.org/task/47989

Excerpt:

On the XPS 13 9350 2015 I2S Audio operates correctly and for that model of the Dell XPS 13 the flag is not needed; however on the Dell XPS 13 [9343] (early 2015) model, audio is still broken and HDA audio is needed. Both Fedora Rawhide and Arch have made the decision to disable this flag and in both cases on the Dell XPS 13 9343 Audio is broken. 

DMESG Output "broadwell-audio broadwell-audio: ASoC: CODEC DAI rt286-aif1 not registered" 

I have tested the 4.4 kernel with the flag off on the Dell XPS 9350 and I2S works well so on that model it would be recommended to use I2S but the flag needs to be enabled for the 9343 model.
Comment 16 mvetter 2016-03-08 01:18:16 EST
Related bug at kernel.org:
https://bugzilla.kernel.org/show_bug.cgi?id=112611
Comment 17 Herald van der Breggen 2016-03-10 06:51:31 EST
(In reply to mvetter from comment #13)
> For other users reading the comments here:
> 
> To prevent the silliness with the broken kernel 4.4 upgrade from bothering
> you each time you do an update, follow these steps:

[...]

Thanks, very helpful tips! It looks like my laptop can stay now on kernel 4.3 until the problem is fixed.

I hope the problem will solved soon.
Comment 18 Tristan hoar 2016-03-12 07:47:37 EST
I've updated to kernel-4.4.4-301.fc23.x86_64 and sound is still not working for me on my XPS 9343, BIOS A07.

[trishoar@killua ~]$ dmesg -t | egrep "(audio|snd|INT3438)"
DMAR: ACPI device "INT3438:00" under DMAR at fed91000 as 00:13.0
snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
sst-acpi INT3438:00: DesignWare DMA Controller, 8 channels
haswell-pcm-audio haswell-pcm-audio: Direct firmware load for intel/IntcPP01.bin failed with error -2
haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not available(-2)
haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> System Pin mapping ok
broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload0 Pin mapping ok
broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload1 Pin mapping ok
broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Loopback Pin mapping ok
broadwell-audio broadwell-audio: rt286-aif1 <-> snd-soc-dummy-dai mapping ok
input: broadwell-rt286 Headset as /devices/pci0000:00/INT3438:00/broadwell-audio/sound/card1/input16
haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19

[trishoar@killua ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 0: System Playback/Capture (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 1: Offload0 Playback (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: broadwellrt286 [broadwell-rt286], device 2: Offload1 Playback (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
Comment 19 Enrico Tagliavini 2016-03-17 04:56:29 EDT
Same laptop here: Dell XPS 13 (model 9343, 2015 - bios A07). I'm running Fedora 22, with kernel 4.4.4 atm. Audio works normally for me, except one thing: internal microphone is not detected at all. This is unfortunate as it makes video conferences impossible. I don't have an headset with microphone so I can't test if that one works.

I've reported the bug upstream as well: https://bugzilla.kernel.org/show_bug.cgi?id=114171

Is there a way to override the _REV with a kernel command line argument? Seems like using acpi_rev_override is possible, but only if ACPI_REV_OVERRIDE_POSSIBLE is enabled in the kernel, and it's not. However in kernel 4.3.5 (where ACPI_REV_OVERRIDE_POSSIBLE was enabled) the override was done automatically without any kernel command line present... the doc is a bit unclear here to me :).
Comment 20 Francisco Cribari 2016-03-18 08:06:40 EDT
Fedora 23, Dell XPS 13 (model 9343), bios A07, kernel 4.4.5-300.fc23.x86_64. Problems: (1) Internal microphone is not detected, (2) Sound works for a couple of hours and then is gone. After sound is gone, dmesg reports

[ 3977.821164] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 3977.821167] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 3977.821169]  System PCM: error: failed to commit stream -110
[ 3977.821171] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 3977.821173]  System PCM: ASoC: hw_params FE failed -110
[ 3978.127212] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 3978.127216] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 3978.127218]  System PCM: error: failed to commit stream -110
[ 3978.127220] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 3978.127222]  System PCM: ASoC: hw_params FE failed -110
[ 3978.433128] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 3978.433133] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 3978.433135]  System PCM: error: failed to commit stream -110
[ 3978.433138] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 3978.433140]  System PCM: ASoC: hw_params FE failed -110
Comment 21 Enrico Tagliavini 2016-03-18 08:27:45 EDT
I tried adding acpi_rev_override to the kernel command line, did double cold reboot to no avail. I2S mode is used

I finally found a way to get microphone back, enabling capture on ADC0 is the the magic secret needed, found in http://forthescience.org/blog/2015/03/20/installing_ubuntu_14_04_on_the_new_dell_xps_13/

However there's no way every owner of a Dell XPS 13 is going to do this, or to find this help in the first place. It's quite confusing also because pulseaudio will still report the microphone as unplugged.

I'd recommend to enable CONFIG_ACPI_REV_OVERRIDE_POSSIBLE again until I2S mode works a little bit better out of the box, I'm also available to test it out in advance if needed, given I own the hardware. Feel free to contact me.
Comment 22 Francisco Cribari 2016-03-18 14:35:58 EDT
This is what I have installed: 

[cribari@darwin4 ~] $ dnf list installed | grep pulseaudio
alsa-plugins-pulseaudio.i686          1.0.29-2.fc23                @@commandline
alsa-plugins-pulseaudio.x86_64        1.0.29-2.fc23                @@commandline
pulseaudio.x86_64                     7.1-1.fc23                   @@commandline
pulseaudio-equalizer.noarch           2.7-16.fc23                  @fedora      
pulseaudio-gdm-hooks.x86_64           7.1-1.fc23                   @@commandline
pulseaudio-libs.i686                  7.1-1.fc23                   @@commandline
pulseaudio-libs.x86_64                7.1-1.fc23                   @@commandline
pulseaudio-libs-glib2.x86_64          7.1-1.fc23                   @@commandline
pulseaudio-module-bluetooth.x86_64    7.1-1.fc23                   @@commandline
pulseaudio-module-x11.x86_64          7.1-1.fc23                   @@commandline
pulseaudio-utils.x86_64               7.1-1.fc23                   @@commandline
wine-pulseaudio.i686                  1.9.5-2.fc23                 @updates     
wine-pulseaudio.x86_64                1.9.5-2.fc23                 @updates  
   
[cribari@darwin4 ~] $ dnf list installed | grep alsa
alsa-lib.i686                         1.0.29-2.fc23                @@commandline
alsa-lib.x86_64                       1.0.29-2.fc23                @@commandline
alsa-lib-devel.x86_64                 1.0.29-2.fc23                @@commandline
alsa-plugins-pulseaudio.i686          1.0.29-2.fc23                @@commandline
alsa-plugins-pulseaudio.x86_64        1.0.29-2.fc23                @@commandline
alsa-ucm.x86_64                       1.0.29-2.fc23                @fedora      
alsa-utils.x86_64                     1.0.29-2.fc23                @@commandline
alsamixergui.x86_64                   0.9.0-0.21.rc2.fc23          @@commandline
wine-alsa.i686                        1.9.5-2.fc23                 @updates     
wine-alsa.x86_64                      1.9.5-2.fc23                 @updates
Comment 23 Enrico Tagliavini 2016-03-22 04:36:39 EDT
Disclaimer: not sure if I understood correctly. Somebody in the upstream kernel bug pointed out some changes in alsa-lib

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=404951da5ed66c80caf5e3fa3d703f291002cb24;hp=434f2f021f00045abcf79c9048b808c5dccfc930

Looking at the date I think there are included only in the very latest version 1.1.0 and not in 1.0.29 which is what Fedora currently ship.
Comment 24 Antón R. Yuste 2016-03-23 07:56:07 EDT
As many other users, I don't have mic running Fedora 23 on a Dell XPS 13 (model 9343, 2015 - bios A07) with kernel 4.4.5-300.

It's weird PulseAudio is able to measure the internal mic but not the headphones, even when connected. Screenshot: https://cloud.githubusercontent.com/assets/7526373/13984404/5111eb74-f0f6-11e5-9441-0c62a6a59087.png

I've tried mvetter workarround but:

sudo dnf install kernel-4.3.5-300.fc23.x86_64
Last metadata expiration check: 0:16:18 ago on Wed Mar 23 12:39:05 2016.
No package kernel-4.3.5-300.fc23.x86_64 available.
Error: Unable to find a match.


Any help would be welcomed.
Comment 25 Francisco Cribari 2016-03-24 10:13:58 EDT
Fedora 23, Dell XPS 13 (model: 9343, bios: A07), kernel: 4.4.6-300.fc23.x86_64. 

1) Internal microphone was not recognized. 

2) Sound worked for several hours. Then it suddenly stopped working. At that point, from dmesg: 

[ 6948.512295] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 6948.512300]  System PCM: ASoC: hw_params FE failed -110
[ 6948.815217] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 6948.815220] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 6948.815222]  System PCM: error: failed to commit stream -110
[ 6948.815224] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 6948.815226]  System PCM: ASoC: hw_params FE failed -110
[ 6949.118140] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 6949.118143] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 6949.118145]  System PCM: error: failed to commit stream -110
[ 6949.118147] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 6949.118149]  System PCM: ASoC: hw_params FE failed -110
Comment 26 Antony 2016-03-25 12:56:20 EDT
(In reply to Antón R. Yuste from comment #24)
> As many other users, I don't have mic running Fedora 23 on a Dell XPS 13
> (model 9343, 2015 - bios A07) with kernel 4.4.5-300.
> 
> It's weird PulseAudio is able to measure the internal mic but not the
> headphones, even when connected. Screenshot:
> https://cloud.githubusercontent.com/assets/7526373/13984404/5111eb74-f0f6-
> 11e5-9441-0c62a6a59087.png
> 
> I've tried mvetter workarround but:
> 
> sudo dnf install kernel-4.3.5-300.fc23.x86_64
> Last metadata expiration check: 0:16:18 ago on Wed Mar 23 12:39:05 2016.
> No package kernel-4.3.5-300.fc23.x86_64 available.
> Error: Unable to find a match.
> 
> 
> Any help would be welcomed.

Same problem, looks like DNF does not look this far back. 

To work around this, manually download the packages from here: http://koji.fedoraproject.org/koji/buildinfo?buildID=715046 for your architecture to a directory e.g. ~/kernel-tmp. 

If like me you are running a 9343 you may well also have akmods installed. Do

sudo dnf list "kmod-wl*"

and uninstall any packages with source @@commandline (this removes packages generated by akmods).

Then run

sudo rpm -Uvh --oldpackage ~/kernel/temp/kernel*.rpm

expanding as necessary. This will fail if you have the kmod-wl-`uname-r` packages still installed. Also, before you run this, make absolutely certain you pulled kernel-headers and kernel-devel from koji, as you will need these for akmods.

This will uninstall all your latest kernels and install 4.3.5. You can then perform the required two cold boots and you'll have your audio back. If you're missing your wireless card after this, run sudo akmods.
Comment 27 pllauria 2016-03-26 15:04:08 EDT
I have a 9343 as well, and with 4.4.6 it seems to work -- but only after I had to enter alsamixer's broadwell settings and unmute  'SP0' -- regular unmuting from the keyboard doesn't work. Not sure if this will work for you guys or if this is the problem you were experiencing.

On a side note, it seems ridiculous I had to use the ancient alsamixer to fix this...
Comment 28 Niccolò Belli 2016-03-26 15:39:40 EDT
AFAIK this will automatically get fixed when Fedora will switch to alsa 1.1
Comment 29 Francisco Cribari 2016-03-26 15:50:37 EDT
(In reply to pllauria from comment #27)
> I have a 9343 as well, and with 4.4.6 it seems to work -- but only after I
> had to enter alsamixer's broadwell settings and unmute  'SP0' -- regular
> unmuting from the keyboard doesn't work. Not sure if this will work for you
> guys or if this is the problem you were experiencing.

In my case: 1) Internal microphone does not work, 2) After using alsamixer, sound works for a couple of hours and then stops working. I posted above the dmesg output, 3) Which alsa and pulseaudio packages do you have installed on your machine?
Comment 30 pllauria 2016-03-26 16:07:51 EDT
I admit that I haven't been using my computer for that long. If it stops working I'll report back.

You are right, my microphone does not work.

Everything is the latest version on my laptop as of 3/26/16 for Fedora 23, I have no changes from stock. pulseaudio 7.1.1, alsa 1.0.29.
Comment 31 Enrico Tagliavini 2016-03-26 20:18:57 EDT
You can fix your microphone by going into alsamixer as well (set capture on ADC0 by pressing the spacebar when selected). And yes, that's the bug, this is supposed to happen automatically. To happen automatically alsa-ucm (the needed config files) should be installed by default. Alsa UCM config files are not installed automatically or by default in Fedora and only with alsa version 1.1 comes a config file for broadwell audio. Unfortunately that version is tuned for the nexus 7 and not for laptops and jack detection for headphones will be broken. For the time being the best out of the box experience for the user is HDA mode, but CONFIG_ACPI_REV_OVERRIDE_POSSIBLE must be enabled again for that.

See also https://bugzilla.kernel.org/show_bug.cgi?id=114171
Comment 32 Elad Alfassa 2016-03-27 04:16:26 EDT
I can reproduce this issue with kernel-4.4.6-300.fc23.x86_64

However, in this specific case (4.4) it's not exactly the kernel's fault. To make sound work, you need alsa-ucm installed with a version that has the files for broadwell-rt286.

This is version 1.1 of alsa-ucm, and for reasons unknown it's only available in Fedora 24.

Installing alsa-lib and alsa-ucm from http://koji.fedoraproject.org/koji/buildinfo?buildID=716204

fixes the problem on F23. I guess the proper fix here is to ask the alsa-lib maintainers to backport the 1.1 release to F23 as well.
Comment 33 Antón R. Yuste 2016-03-27 10:15:37 EDT
Antony, thanks for the help! Finally I've installed alsa-lib-1.1.0-4.fc24.x86_64.rpm and alsa-ucm-1.1.0-4.fc24.x86_64.rpm as indicated by Elad, and mic is back, but I think it's not detecting the headphone mic, only working with the internal. Headphones are working for output.

My configuration: 9343, bios A07, 4.4.6-300. 

wget https://kojipkgs.fedoraproject.org//packages/alsa-lib/1.1.0/4.fc24/x86_64/alsa-lib-1.1.0-4.fc24.x86_64.rpm

wget https://kojipkgs.fedoraproject.org//packages/alsa-lib/1.1.0/4.fc24/x86_64/alsa-ucm-1.1.0-4.fc24.x86_64.rpm

sudo rpm -Uvh --oldpackage --force alsa-lib-1.1.0-4.fc24.x86_64.rpm alsa-ucm-1.1.0-4.fc24.x86_64.rpm
Comment 34 Francisco Cribari 2016-04-03 05:52:39 EDT
I am still having problems even after upgrading alsa-lib and alsa-ucm to version 1.1.1-1. The only progress is that the internal microphone seems to be recognized now. I have sound a few hours (sometimes just for a few minutes) and then sound stops works. At that point, the sound panel in Settings does not even list a sound card. The dmesg messages are as I quoted before. Kernel is 4.4.6-300.fc23 . The packages I have installed: 

[cribari@darwin4 ~] $ dnf list installed | grep alsa
alsa-lib.i686                         1.1.1-1.fc23                 @updates     
alsa-lib.x86_64                       1.1.1-1.fc23                 @updates     
alsa-lib-devel.x86_64                 1.1.1-1.fc23                 @updates     
alsa-plugins-pulseaudio.i686          1.1.1-1.fc23                 @updates     
alsa-plugins-pulseaudio.x86_64        1.1.1-1.fc23                 @updates     
alsa-ucm.x86_64                       1.1.1-1.fc23                 @updates     
alsa-utils.x86_64                     1.1.1-1.fc23                 @updates     
alsamixergui.x86_64                   0.9.0-0.21.rc2.fc23          @@commandline
wine-alsa.i686                        1.9.6-1.fc23                 @updates     
wine-alsa.x86_64                      1.9.6-1.fc23                 @updates    

Is there anything I could try?
Comment 35 Francisco Cribari 2016-04-03 07:00:07 EDT
The kernel parameters I have in /etc/default/grub are: 

psmouse.resetafter=0 pcie_aspm=force i915.enable_fbc=1 i915.enable_rc6=7

Do I need to add acpi.os="!Windows 2013" ?
Comment 36 Igor 2016-04-04 17:31:47 EDT
same problem as everyone else on this thread -- upgraded to kernel 4.4 and sound stopped working. this is an XPS 13 9343 BIOS A7.

i installed alsa-ucm and rebooted, which got sound output working again. however, the sound quality is quite poor -- it sort of dies if you're not using it, and takes a moment to start up again, plus it has these weird pops and crackles occasionally.

also, there was nothing i could do to get the microphone working again. i looked in alsamixer under broadwell-rt286 for ADC0 but couldn't find such a setting. i twiddled a few knobs in alsamixer anyway, but nothing i did made the microphone start working.

i am going back to kernel 4.3 for now. for anyone else reading this thread, i think that's the safest and easiest workaround for now.
Comment 37 Francisco Cribari 2016-04-04 20:37:15 EDT
Dell XPS 13 (model 9343), bios A07, Fedora 23, kernel 4.4.6-300.fc23.x86_64, alsa-lib and alsa-ucm version 1.1.1-1.fc23. Sound works for a few minutes or hours and then stop working. 

dmesg info available at 

https://dl.dropboxusercontent.com/u/2171814/sound-dmesg.txt

Is there anything else I should try?
Comment 38 Francisco Cribari 2016-04-04 20:45:22 EDT
More info: 

cribari@darwin4 ~] $ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version k4.4.6-300.fc23.x86_64.
[cribari@darwin4 ~] $ cat /proc/asound/cards
 0 [HDMI           ]: HDA-Intel - HDA Intel HDMI
                      HDA Intel HDMI at 0xf7418000 irq 49
 1 [broadwellrt286 ]: broadwell-rt286 - broadwell-rt286
                      broadwell-rt286
[cribari@darwin4 ~] $ cat /proc/asound/devices
  1:        : sequencer
  2: [ 0]   : control
  3: [ 0- 3]: digital audio playback
  4: [ 0- 7]: digital audio playback
  5: [ 0- 8]: digital audio playback
  6: [ 0- 0]: hardware dependent
  7: [ 1]   : control
  8: [ 1- 0]: digital audio playback
  9: [ 1- 0]: digital audio capture
 10: [ 1- 1]: digital audio playback
 11: [ 1- 2]: digital audio playback
 12: [ 1- 3]: digital audio capture
 33:        : timer
[cribari@darwin4 ~] $ cat /proc/asound/oss-devices
cat: /proc/asound/oss-devices: No such file or directory
[cribari@darwin4 ~] $ cat /proc/asound/timers
G0: system timer : 1000.000us (10000000 ticks)
P0-3-0: PCM playback 0-3-0 : SLAVE
P0-7-0: PCM playback 0-7-0 : SLAVE
P0-8-0: PCM playback 0-8-0 : SLAVE
P1-0-0: PCM playback 1-0-0 : SLAVE
P1-0-1: PCM capture 1-0-1 : SLAVE
P1-1-0: PCM playback 1-1-0 : SLAVE
P1-2-0: PCM playback 1-2-0 : SLAVE
P1-3-1: PCM capture 1-3-1 : SLAVE
[cribari@darwin4 ~] $ cat /proc/asound/pcm
00-03: HDMI 0 : HDMI 0 : playback 1
00-07: HDMI 1 : HDMI 1 : playback 1
00-08: HDMI 2 : HDMI 2 : playback 1
01-00: System Playback/Capture (*) :  : playback 1 : capture 1
01-01: Offload0 Playback (*) :  : playback 1
01-02: Offload1 Playback (*) :  : playback 1
01-03: Loopback snd-soc-dummy-dai-3 :  : capture 1
[cribari@darwin4 ~] $
Comment 39 Francisco Cribari 2016-04-08 21:35:05 EDT
kernel 4.4.6-301.fc23.x86_64: same problem. Sound works for a while, then stops working and dmesg yields: 

[  197.319636]  System PCM: error: failed to commit stream -110
[  197.319638] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
Comment 40 Przemyslaw Szypowicz 2016-04-11 12:25:14 EDT
The temporary solution for that problem is: 

$ dnf update alsa-lib alsa-ucm --releasever=24

That worked for me at least.
Comment 41 James Cimino 2016-04-13 00:36:39 EDT
(In reply to Przemyslaw Szypowicz from comment #40)
> The temporary solution for that problem is: 
> $ dnf update alsa-lib alsa-ucm --releasever=24
> That worked for me at least.

Does this actually solve the problem permanently? ie. does this work for more than a few minutes?

According to https://bugzilla.redhat.com/show_bug.cgi?id=1321266#c5 upgrading to alsa 1.1.1 doesn't solve the problem.
Comment 42 Tristan hoar 2016-04-13 05:17:55 EDT
(In reply to James Cimino from comment #41)
> (In reply to Przemyslaw Szypowicz from comment #40)
> > The temporary solution for that problem is: 
> > $ dnf update alsa-lib alsa-ucm --releasever=24
> > That worked for me at least.
> 
> Does this actually solve the problem permanently? ie. does this work for
> more than a few minutes?
> 
> According to https://bugzilla.redhat.com/show_bug.cgi?id=1321266#c5
> upgrading to alsa 1.1.1 doesn't solve the problem.

When I last tried this on 4.4.6-300 it did only lasted a few minutes. I'm still using 4.3.5 which is the last kernel that audio correctly worked with this laptop.
Comment 43 Przemyslaw Szypowicz 2016-04-13 06:08:21 EDT
I do did this before installing new alsa packages.

There is section: Getting stuff working with a newer kernel, which provides manual reconfiguration in alsamixer
http://forthescience.org/blog/2015/03/20/installing_ubuntu_14_04_on_the_new_dell_xps_13/

```The audio board should now be detected. You can open the sound settings from the small speaker in the top-right corner, it should list broadwell-rt286 on the output tab. Switch to the input tab to check if that also lists the broadwell-rt286, and then back to output. Open a new terminal window and start alsamixer. Press F6 and select the broadwell-rt286 device. on the playback tab (F3), set the following settings:

Master: 100 (all the way up, arrow keys)
Headphones: 00 (press m to flip between mute and on, 00 means on)
Speaker: 00
Front DAC: 00
Front REC: mm
ADC 0 Mux: Dmic (arrow keys)
ADC 1 Mux: Dmic
AMIC: 100
DAC0: 100
HPO L: 00
HPO Mux: front
HPO R: 00
Media0: 100
Media1: 100
RECMIX Beep: 00
RECMIX line1: 00
RECMIX mic1: 00
SPK Mux: front
SPO: 00
Switch to the record tab (F4), and set the following settings:

Mic: 100
ADC0: 100 and CAPTURE (use the space bar to set CAPTURE)
AMIC: 100
Congratulations, you should now have sound! Open your favorite youtube clip to check this.
```

I'm using new kernel with this changes almost 2 weeks without an issue.
Comment 44 James Cimino 2016-04-13 12:11:12 EDT
(In reply to Przemyslaw Szypowicz from comment #43)
> Master: 100 (all the way up, arrow keys)
> Headphones: 00 (press m to flip between mute and on, 00 means on)
> Speaker: 00
> ...
> 
> I'm using new kernel with this changes almost 2 weeks without an issue.

Do the above setting survive reboots and power cycles?  If so, is there a way to configure the ALSA package to have these settings in the first place?

It's completely ridiculous to have to do this manually.
Comment 45 Przemyslaw Szypowicz 2016-04-13 12:26:47 EDT
> It's completely ridiculous to have to do this manually.

100% Agree.
Comment 46 James Cimino 2016-04-13 12:40:41 EDT
(In reply to Przemyslaw Szypowicz from comment #45)
> > It's completely ridiculous to have to do this manually.
> 
> 100% Agree.

It's rather curious that the Fedora kernel maintainers (Laura Abbott and Justin Forbes) are staying very quiet about this bug. They have caused the regression, and yet they do not seem to want to fix it.
Comment 47 Justin M. Forbes 2016-04-13 14:16:22 EDT
I have been silent because I am not maintaining 4.4, I am maintaining 4.5, but I will say this after spending a lot of time on IRC with someone today dealing with this. You are running on hardware which has a poorly implemented firmware hack to allow HDA or I2S mode depending on OS support. Still, the kernel did implement a bad hack of its own to force HDA mode, while proper kernel support for the I2S mode was implemented, because we genuinely want things to work. 

The 4.4 kernel fixed the I2S issues with support of this hackish implementation. A requirement to make a config change for odd hardware is not ridiculous, or even that uncommon. I have devices that required some config changes to work properly as well. That is why there are configurable items in drivers.  The effort spent trying to force the old hack to come back instead of simply making those config changes on your system is strange to me. The hardware was meant to be run in I2S mode, and only had a weird hack to fall back for older operating systems. No one is testing these systems in HDA mode upstream going forward, I2S is supported.  Think about the lifecycle of hardware, the XPS 13 is a decent laptop that most users expect a minimum of 3-5 years out of.  At some point, we have to stop carrying the hack, people will be running the XPS 13 with F24, F25, possibly even Fedora 30. The hack was enabled because at the time, it was an unworkable situation, the other answer was "no sound until the 4.4 rebase". At the time it was implemented, we said it would only be there until I2S was working. It is working, you have to make some minor changes in userspace to take advantage of them.

Yes, 4.5 has a regression that I am hoping will be fixed before the F24 release, if not, I will work around it, it's a kernel problem, and will be addressed in kernel as is appropriate.  We are aware of it, and that issue wouldn't make it to a stable Fedora release.
Comment 48 Antony 2016-04-13 21:04:15 EDT
(In reply to Justin M. Forbes from comment #47)

> The effort spent trying to force the old hack to come back instead of simply making those config changes on your system is strange to me.

For me personally, the major reason for doing this is that most "fixes" for this kind of thing online do not work (in the general sense of X does not work). In all of the above "change this setting here and there appears to work for me" is not a definite answer and I've lost count of the number of times I've tried this sort of thing and found it to be a load of nonsense.

So, what I do is go back to the last known working config. I shall now be trying alsamixer, but I'll leave the 4.3 series kernel around just in case.
Comment 49 James Cimino 2016-04-13 23:28:16 EDT
(In reply to Justin M. Forbes from comment #47)
> The effort spent trying to force the old hack to come back
> instead of simply making those config changes on your system
> is strange to me.

The point is that a kernel upgrade introduced a regression on an otherwise working system. The underlying reasoning for the regression doesn't matter (ie. disabling of a hack etc). From a user perspective, audio worked in kernel 4.3 and then it was broken in 4.4. User space programs (alsa) were not updated at the same time, meaning that no care was taken to ensure that disabling CONFIG_ACPI_REV_OVERRIDE_POSSIBLE didn't have adverse effects. This is not how good engineering is done. At best this shows lack of reasonable foresight (given the previous problems with I2S), and at worst this is dangerous behavior.

What's more worrying is that the entire attitude of breaking stuff during updates still hasn't been eradicated in Fedora.
Comment 50 James Cimino 2016-04-13 23:31:32 EDT
(In reply to Antony from comment #48)
> I shall now be trying alsamixer, but I'll leave the 4.3 series
> kernel around just in case.

Can you keep us updated how alsamixer went for you?
Comment 51 Josh Boyer 2016-04-14 08:27:42 EDT
(In reply to James Cimino from comment #49)
> (In reply to Justin M. Forbes from comment #47)
> > The effort spent trying to force the old hack to come back
> > instead of simply making those config changes on your system
> > is strange to me.
> 
> The point is that a kernel upgrade introduced a regression on an otherwise
> working system. The underlying reasoning for the regression doesn't matter
> (ie. disabling of a hack etc). From a user perspective, audio worked in
> kernel 4.3 and then it was broken in 4.4. User space programs (alsa) were
> not updated at the same time, meaning that no care was taken to ensure that
> disabling CONFIG_ACPI_REV_OVERRIDE_POSSIBLE didn't have adverse effects.
> This is not how good engineering is done. At best this shows lack of
> reasonable foresight (given the previous problems with I2S), and at worst
> this is dangerous behavior.
> 
> What's more worrying is that the entire attitude of breaking stuff during
> updates still hasn't been eradicated in Fedora.

Stop.  There is no attitude in play here other than yours.  The maintainers understand this is frustrating and are frustrated as well.  Shouting at them about what you perceive to be poor engineering is not helpful.

It is literally impossible for us to avoid all regressions.  The variety of machines Fedora can be installed on is huge and we have not even a tiny fraction to test on.  Regressions will happen and we then try and fix them.  The alternative is to never update the kernel and do extremely specific backporting of security fixes only.  That is fine for one class of users (who should arguably be using something like RHEL), but it means people that buy new machines can't install Fedora on them because drivers are missing or functionality doesn't exist in the GA kernel.  Then they get angry because their shiny machine doesn't work.

There's also the fact that with over 600 bugs and everyone thinking their bug is the highest possible priority, we have to do internal triage and prioritization.  Otherwise all we would do is reply to bugs like this and never actually get things done.  So a sound bug, while frustrating, isn't going to trump a bug where someone can't even see what is on their screen or cannot even boot.

It's fine to feel upset and we're upset too, but it is not OK to slander the people doing their best to fix things across all the issues.  It would be more helpful, and certainly more in the spirit of Fedora and open source in general, to keep comments focused on solutions and helping others.  If you insist upon being indignant and passive aggressive in bugs, I can't stop you but it is a quick way to get ignored.
Comment 52 Igor 2016-04-14 12:22:32 EDT
@jwboyer: thanks! that needed to be said.

i'm still using the old kernel as a workaround. going forward, will everyone using a dell xps 13 still need to make those alsamixer config changes? or is the goal that at some point, after updating to more recent kernel or more recent alsa packages, everything will work automagically? if it's the latter, i'm happy to wait to confirm the fix when it's released; if it's the former i might as well reboot into the new kernel and make the config changes now.

i wish there was a way to bring this bug to the attention of the dell engineers who implement the firmware. does anyone know how to do that?
Comment 53 James Cimino 2016-04-15 00:13:58 EDT
(In reply to Josh Boyer from comment #51)
> Stop.  There is no attitude in play here other than yours.  The maintainers
> understand this is frustrating and are frustrated as well.  Shouting at them
> about what you perceive to be poor engineering is not helpful.

I apologize for the rude tone and the disparaging remarks. Indeed I am frustrated, mainly as there is a simple solution to all of this.
Comment 54 Sebastian Plamauer 2016-04-15 05:37:45 EDT
If those alsamixer settings actually solved the problem, it would be nice.

Sound works for some time, but then still crashes:

dmesg
[ 3102.798485] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 3102.798489] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 3102.798491]  System PCM: error: failed to commit stream -110
[ 3102.798494] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 3102.798495]  System PCM: ASoC: hw_params FE failed -110

After that, alsamixer won't even open. If you go into settings all the audio devices are gone. Sometimes they show up again, but if you test the speakers, the settings app crashes. It's broken so badly that video playback isn't working right anymore - not just sound missing, but video not playing properly. I even get UI freezes that paranoid me attributes to this issue, although I can't pin-point it.

And the most annoying part is that I fixed this issues a couple of times already. But ever since 4.2 every update breaks it again. The funniest fix is booting from an Ubuntu thumb-drive once and then booting into Fedora again - doing that, everything works perfectly until the next reboot.

It's a sad mess.

I figured maybe one of the crazy things I did to fix this earlier causes this. I reverted most of that back already, but my alsa packages are still pointing to releasever=24 and I still have some crazy boot options:
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap psmouse.resetafter=0 pcie_aspm=force i915.enable_fbc=1 i915.enable_rc6=7 acpi_backlight=vendor acpi_osi='!Windows 2013' acpi_osi='!Windows 2012'"

... most of which I don't even understand.

It would be great if someone who has working sound via alsamixer settings could share the output of her alsa-info.sh and boot options so I can compare.

Thanks.
Comment 55 Antón R. Yuste 2016-04-15 05:50:36 EDT
Hello Sebastian,

Here my Alsa configuration: https://paste.fedoraproject.org/355984/14607133/

GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet"

I think we have the same device and setup (Fedora 23), with alsa-lib-1.1.0-4.fc24.x86_64.rpm and alsa-ucm-1.1.0-4.fc24.x86_64.rpm installed.

In my case, everything works well and sound never stops, the only thing is the mic of the headphone, which it's not detected. 

I hope this helps you.
Comment 56 Enrico Tagliavini 2016-04-15 05:55:38 EDT
That's weird. What model is that exactly? I have XPS 13 9343, just doing quite a few changes in alsamixer solved all problems for me, and I never saw the crash you are mentioning. I have the default kernel command line, no need to specify acpi_osi, and I never needed it. I would advise to remove it. Also note I'm still on Fedora 22.

I would try removing pcie_aspm=force. There is really no need for it, battery life is great already (imho). Install tlp instead (it will switch on the PCI power management when on battery automatically, among other things; it's also daemon-less).

Also Intel FBC is not enabled by default in the current kernel. Surely with the next one it will be since Intel finally switched on by default upstream. That being said, since you mention rendering issues, I would definitely try few days without it. Also why acpi_backlight=vendor?

I'd recommend to switch all boot options back to default, so remove everything after (and including) psmouse.resetafter=0. None of them should be needed and most of them can cause mess up.

You can find my alsa-info.sh output in upstream kernel bug I opened https://bugzilla.kernel.org/show_bug.cgi?id=114171 . There is also some talk about new alsa libraries. The only thing actually missing, to my best understanding, is the UCM configuration file. I've used the one for the nexus 7 and installed it on my fedora and kept stock alsa libraries. Jack detection doesn't work for me, but pulseaudio now correctly detects the ports (speaker / headphones) so there is some improvement I think. However a dedicated config file for laptops is missing, using the nexus 7 one is not ideal probably.
Comment 57 Francisco Cribari 2016-04-15 06:31:14 EDT
My experience is similar to that of Sebastian Plamauer (#54). Sound works for some time in Fedora 23, but then crashes. dmesg reports: 

[ 3102.798485] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 3102.798489] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 3102.798491]  System PCM: error: failed to commit stream -110
[ 3102.798494] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 3102.798495]  System PCM: ASoC: hw_params FE failed -110

That continued to happen even after alsa-lib and alsa-ucm were upgraded to version 1.1.1-1.  

Same problem with Arch Linux and kernel 4.4. With Arch Linux and kernel 4.5 the sound card is not even recognized. 

Hardware is Dell XPS 13 model 9343 (model 2015) and bios is A07. 

Are the bios settings that can be played with?
Comment 58 Sebastian Plamauer 2016-04-15 06:40:22 EDT
It's a 9343.

I reverted grub back to default, but no cigar.

I'd have to do a fresh install to make sure it's not something I did, but, honestly, if I'm going to do that, I'll switch back to Ubuntu.

@Francisco Cribari are you having UI freeze issues, too? When I open gnome-terminal and hit TAB a couple of times, it freezes up, and I have to CTRL-ALT-F1 and log back in.
Comment 59 Francisco Cribari 2016-04-15 07:01:18 EDT
@Sebastian Plamauer Yes, exactly as you described in #54. I only did not try the booting with Ubuntu trick. I thought the problem was caused by some specific configuration I had. I then installed Arch (Antergos, actually), made no additional configs and added no boot parameters. With kernel 4.4 I had exactly the same problems as in Fedora 23 (described by you in #54). With kernel 4.5 the soundcard is not even recognized. What I am now doing: running Arch Linux with their LTS kernel. This computer is my main working machine and this bug has caused me a lot problems. It causes me concern that the proposed fix seems to work on some 9343 machines but not on others.
Comment 60 Enrico Tagliavini 2016-04-15 09:40:39 EDT
(In reply to Sebastian Plamauer from comment #58)
> It's a 9343.
> 
> I reverted grub back to default, but no cigar.

Very weird. Was it with Windows or Ubuntu pre-installed? Mine was the developer edition, came with Ubuntu from factory. I wonder if there are two slightly different revision of the same hardware.
Comment 61 Sebastian Plamauer 2016-04-15 10:10:29 EDT
Developer Edition
Comment 62 Antony 2016-04-15 15:37:13 EDT
(In reply to James Cimino from comment #50)
> (In reply to Antony from comment #48)
> > I shall now be trying alsamixer, but I'll leave the 4.3 series
> > kernel around just in case.
> 
> Can you keep us updated how alsamixer went for you?

Of course :)

Firstly, my setup (since comparing Apples and Oranges is unhelpful), 9343 Bios A07. I'm running kernel 4.4.6-301.fc23.x86_64 (from Fedora) and I have not upgraded alsa to the version in release=24. My grub config line has no special switches for acpi or anything other - those that were needed to get the system working initially were removed as soon as A02 was available.

The Alsamixer settings work for me in that I can play sound. I have not seen issues with sound failing a few hours later. I will report back if this happens.

For the other questions on models etc, my laptop came with Windows preinstalled, although I introduced it to a Fedora USB stick reasonably quickly.

@maintainers if you'd like some output from /sys or some such I'm happy to provide it.
Comment 63 Cody 2016-04-15 19:30:46 EDT
I have not read the this entire thread but what I have read though seems familiar.

The way this issue came about for me seems to be (but again I have not read the entire thread or referenced any of the other bugs linked to) a bit different - at least in that yes I am under kernel 4.4 but all was okay until I updated the following packages FROM:

alsa-lib-1.0.29-2.fc23.x86_64
alsa-lib-1.0.29-2.fc23.i686
alsa-lib-devel-1.0.29-2.fc23.x86_64
alsa-plugins-pulseaudio-1.0.29-2.fc23.x86_64
alsa-plugins-pulseaudio-1.0.29-2.fc23.i686
alsa-utils-1.0.29-2.fc23.x86_64

TO:
alsa-lib-1.1.1-1.fc23.x86_64
alsa-lib-1.1.1-1.fc23.i686
alsa-lib-devel-1.1.1-1.fc23.x86_64
alsa-plugins-pulseaudio-1.1.1-1.fc23.x86_64
alsa-plugins-pulseaudio-1.1.1-1.fc23.i686
alsa-utils-1.1.1-1.fc23.x86_64

Shortly after I updated I had paused (or stopped) audacious from playing. A normal thing for me to do. But upon resume (or play) no sound came. I want to say the position (i.e. location in the track that the player is in) bar did not update but I am not certain of this now. I recalled that I had just updated alsa so I figured it must be related. Once I downgraded it all was okay. I've tried updating it again and each time the same symptoms (if I want to make sure it happens I will close audacious right after updating, start it again and no sound).

Whether one would call this the fault of the kernel, alsa or both is I suppose up to debate but it is a debate I care not to get into. To those who have this issue (and it seems the same version of alsa that I cite as a problem have been cited by others too) you might want to downgrade alsa and see how that goes. For the time being I exclude it from updates but I do it manually (so I don't forget about it later on and run into a problem).

FYI I built this system myself and I did so if I recall in 2014. I believe I saw a reference to Haswell and my CPU is a Haswell i7 4790K (and I do use onboard audio). I don't know what information to provide (I'm barely able to write this as I'm dead tired as I am very often) but if any information is requested I will do my best to respond.

Incidentally, I didn't have this problem until it seems April 4. I guess this based on what is in /var/log/yum.log - updating and then installing the version that appears to work. Yes I use yum-deprecated because its logging is far superior than dnf.

(Kernel is: Linux 4.4.6-301.fc23.x86_64)
Comment 64 Francisco Cribari 2016-04-16 06:07:52 EDT
The comments above indicate that the proposed fix works on some 9343 machines but not on others (my case). I don't know whether that makes a difference but my machine is: Core i7-5500U, 8 GB of RAM, 256 GB SSD, QHD+ touchscreen.
Comment 65 Cody 2016-04-16 11:43:07 EDT
(In reply to Francisco Cribari from comment #64)
> The comments above indicate that the proposed fix works on some 9343
> machines but not on others (my case). I don't know whether that makes a
> difference but my machine is: Core i7-5500U, 8 GB of RAM, 256 GB SSD, QHD+
> touchscreen.

Does it work for some people? What proposed fix, anyway ? Ah, maybe the alsa mixer settings. It still seems to me that the problem is in alsa but whether or not that is because of a change in the kernel I do not know (certainly the impossible can made possible and as a programmer I know this very well).

Did you try downgrading alsa (as I suggested)? I have more information wrt errors on my end. When updating alsa I got the following in /var/log/messages (which makes me question whether this is related to this bug; it definitely does not match the other logs but then maybe it was filtered out with the grep - I'll leave this up to the maintainers because the symptoms seem to match fairly close). I should also point out that there is no reference to Haswell sound card (but see below on that):

# tail -n +13230 /var/log/messages|head -n $[13269 - 13230]|egrep -i 'alsa|audio|sound'
Apr 15 15:57:38 sonic yum[9656]: Updated: alsa-lib-1.1.1-1.fc23.x86_64
Apr 15 15:57:41 sonic yum[9656]: Updated: alsa-utils-1.1.1-1.fc23.x86_64
Apr 15 15:57:43 sonic yum[9656]: Updated: alsa-lib-1.1.1-1.fc23.i686
Apr 15 15:57:45 sonic yum[9656]: Updated: alsa-plugins-pulseaudio-1.1.1-1.fc23.x86_64
Apr 15 15:57:47 sonic yum[9656]: Updated: alsa-lib-devel-1.1.1-1.fc23.x86_64
Apr 15 15:57:48 sonic yum[9656]: Updated: alsa-plugins-pulseaudio-1.1.1-1.fc23.i686
Apr 15 15:57:56 sonic systemd: Stopping Manage Sound Card State (restore and store)...
Apr 15 15:57:56 sonic alsactl[1163]: alsactl daemon stopped
Apr 15 15:57:56 sonic audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 15 15:57:56 sonic audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 15 15:57:56 sonic systemd: Started Manage Sound Card State (restore and store).
Apr 15 15:57:56 sonic systemd: Starting Manage Sound Card State (restore and store)...
Apr 15 15:57:56 sonic audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 15 15:57:56 sonic alsactl[9739]: alsactl 1.1.1 daemon started
Apr 15 15:58:27 sonic pulseaudio[2688]: [alsa-sink-ALC1150 Analog] alsa-sink.c: Error opening PCM device front:0: Invalid argument
Apr 15 15:58:29 sonic pulseaudio[2688]: [alsa-sink-ALC1150 Analog] alsa-sink.c: Error opening PCM device front:0: Invalid argument
Apr 15 15:59:19 sonic yum[10013]: Installed: alsa-lib-1.0.29-2.fc23.x86_64
Apr 15 15:59:23 sonic yum[10013]: Installed: alsa-utils-1.0.29-2.fc23.x86_64
Apr 15 15:59:25 sonic yum[10013]: Installed: alsa-lib-1.0.29-2.fc23.i686
Apr 15 15:59:26 sonic yum[10013]: Installed: alsa-plugins-pulseaudio-1.0.29-2.fc23.x86_64
Apr 15 15:59:28 sonic yum[10013]: Installed: alsa-lib-devel-1.0.29-2.fc23.x86_64
Apr 15 15:59:29 sonic yum[10013]: Installed: alsa-plugins-pulseaudio-1.0.29-2.fc23.i686
Apr 15 15:59:34 sonic systemd: Stopping Manage Sound Card State (restore and store)...
Apr 15 15:59:35 sonic alsactl[9739]: alsactl daemon stopped
Apr 15 15:59:35 sonic audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 15 15:59:35 sonic audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 15 15:59:35 sonic systemd: Started Manage Sound Card State (restore and store).
Apr 15 15:59:35 sonic systemd: Starting Manage Sound Card State (restore and store)...
Apr 15 15:59:35 sonic audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 15 15:59:35 sonic alsactl[10054]: alsactl 1.0.29 daemon started

Looking at the errors and in particular:

> Apr 15 15:58:27 sonic pulseaudio[2688]: [alsa-sink-ALC1150 Analog] alsa-sink.c: Error opening PCM device front:0: Invalid argument
> Apr 15 15:58:29 sonic pulseaudio[2688]: [alsa-sink-ALC1150 Analog] alsa-sink.c: Error opening PCM device front:0: Invalid argument

It makes me think it is related to pulseaudio in particular and in the file alsa-sink.c (not looked at it yet but it clearly is getting EINVAL).

From lspci -v:

00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
        Subsystem: ASUSTeK Computer Inc. Device 8608
        Flags: bus master, fast devsel, latency 0, IRQ 46
        Memory at df220000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel
Comment 66 Enrico Tagliavini 2016-04-22 04:28:55 EDT
I've an interesting update. Today, for the first time, audio failed on me. I also get these messages now:

Apr 22 10:25:51 quantdell kernel: haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
Apr 22 10:25:51 quantdell kernel: haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
Apr 22 10:25:51 quantdell kernel: System PCM: error: failed to commit stream -110
Apr 22 10:25:51 quantdell kernel: haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
Apr 22 10:25:51 quantdell kernel: System PCM: ASoC: hw_params FE failed -110

It happened immediately as soon as I tried to start Amarok after a cold boot, not after some time. Yesterday it worked the entire day without a problem. 

The only updates I did yesterday seems unrelated (ntfs stuff). Also no setting was changed in the BIOS. This seems to suggest it might be just a matter of luck if it happens for you or not.
Comment 67 Cody 2016-04-22 11:50:45 EDT
Actually I have an interesting update too. Yesterday I was looking further at audacity settings and the output plugin is PulseAudio - not ALSA (but it's available). Yet when I update alsa the sound stops.

Maybe there is some relation I am not familiar with (or aware of) but yet it still only happens when alsa is updated. Looking at 'KDE Mixer ->  Settings -> Audio Setup -> (Phonon Audio and Video) -> Backend' shows 'Phonon GStreamer'.

On April 20 there was a kernel update:

$ rpm -q --changelog kernel
* Wed Mar 16 2016 Laura Abbott <labbott@redhat.com> - 4.4.6-300
- Linux v4.4.6

But I added --exclude=alsa\* to the command line. I haven't looked at the actual kernel changelog but I somehow suspect it will not have fixed this problem. I would check but when an update causes breakage it doesn't take much time before I start to lose patience in trying to find workarounds (because unless the issue is caused by a security fix or some such I might as well just exclude the packages in question); sound for desktop computers is a must for me (my servers don't run Fedora and I only have no desire for sound at the console anyway).

Comment #66 makes a reference to BIOS and that is an interesting point to consider but experimenting with that (when sound otherwise works with the currently installed version of alsa) would be even more annoying and frustrating (esp since it's worked since I built this system in 2014). This is to say I think it somewhat absurd to suggest it is the BIOS (it would be one thing if it never worked before or there was a BIOS firmware upgrade but that isn't the case here).
Comment 68 Kostya Berger 2016-04-24 15:16:44 EDT
I really don't think the problem on MY system has anything to do nor can somehow be fixed by alsa software manipulation.

Fortunately, I have upgraded from previous Fedora 21, so I have 4.1.13 kernel still installed. When I boot that one, EVERYTHING WORKS. No additional alsa packages needed (still, they are all installed).

BTW, with this new kernel not only sound malfunctions, but also wireless card is not detected. It works by manually loading the needed driver.

This happens on two different machines, one is Lenovo T61, the other Gigabyte z77n-wifi based desktop. Both are well-known hardware, well supported by other OSes.
Kernels starting from 4.2.8 have this behaviour. That's something REALLY broken, compated to what I've experienced before with all my 15+ years of Linux experience.
Comment 69 Kostya Berger 2016-04-24 15:26:12 EDT
...So, the last properly working kernel for me is 4.1.13-100.fc21.x86_64
Comment 70 Kostya Berger 2016-04-25 04:52:44 EDT
Does anybody know if it works in 4.4.8?
Comment 71 axel 2016-04-26 10:12:05 EDT
Hi there

I do not get sound working:

[ 1030.437956] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 1030.754802] haswell-pcm-audio haswell-pcm-audio: Direct firmware load for intel/IntcPP01.bin failed with error -2
[ 1030.754807] haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not available(-2)
[ 1030.755391] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
[ 1030.786802] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> System Pin mapping ok
[ 1030.786858] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload0 Pin mapping ok
[ 1030.786909] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload1 Pin mapping ok
[ 1030.786957] broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Loopback Pin mapping ok
[ 1030.794268] broadwell-audio broadwell-audio: rt286-aif1 <-> snd-soc-dummy-dai mapping ok
[ 1030.808003] input: broadwell-rt286 Headset as /devices/pci0000:00/INT3438:00/broadwell-audio/sound/card1/input17


Dell XPS 2015, Kernel 4.4.7-300.fc23.x86_64

00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
	Subsystem: Dell Device 0665
Comment 72 Enrico Tagliavini 2016-05-02 07:06:21 EDT
Interesting update for my case: I upgraded to Fedora 23, now jack detection works as expected! Pulseaudio will switch port automatically when I plug/unplug my hear plugs.

Notable changes between Fedora 22 and 23 are:
 - kernel upgraded from 4.4.6 to 4.4.8. No idea if anything relevant happened or was backported here
 - alsa user space upgraded to 1.1.1. I did no change to the config files as shipped by this.
 - pulseaudio upgraded from 6.0 to 7.1.

There is still one open question: does it work out of the box for a fresh install? After all this is one of the two main problem of this bug (the other being the driver crashing after some use time).

To answer this can I get alsa to "forget" any changes I made to the mixer and roll back to the state a user would get after a fresh install? I don't mind trying.
Comment 73 Cody 2016-05-02 12:32:17 EDT
(In reply to Enrico Tagliavini from comment #72)
> There is still one open question: does it work out of the box for a fresh
> install? After all this is one of the two main problem of this bug (the
> other being the driver crashing after some use time).
> 
I think I did a clean install but that was before this change so I would rather say it is irrelevant. But it seems to me it would still be a problem.

> To answer this can I get alsa to "forget" any changes I made to the mixer
> and roll back to the state a user would get after a fresh install? I don't
> mind trying.

Is it user-specific? If so why don't you just create a new user and test it? Or create a new user and then copy the relevant files to your primary user? I personally have never touched global configuration of sound so I presume there are at least some user specifics involved in which case creating a new user should be sufficient.
Comment 74 Chaoyi Zha 2016-05-04 20:27:01 EDT
I have the same bug. Alsa settings as indicated in 
https://bugzilla.redhat.com/show_bug.cgi?id=1255070#c76 fixed the sound problem, however mic is still not working. On XPS 13, Fedora 23. Sound worked in 4.3.3
Comment 75 Francisco Cribari 2016-05-10 19:45:58 EDT
I believe the bug may affect differently different 9343 models. My model is 0310JH

cribari@darwin4 ~ $ dmesg | grep "XPS 13"
[ 0.000000] DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015

It has Intel i7 processor, touchscreen, screen resolution: 3200 x 1800 pixels and Broadcom wireless. I believe for this model (0310JH) the crashes occur with messages such as the ones I reported here and are also in #54 and #66. 

@Sebastian Plamauer and @Enrico Tagliavini: Do you also have the 0310JH model?
Comment 76 Enrico Tagliavini 2016-05-11 03:33:22 EDT
(In reply to Francisco Cribari from comment #75)
> @Sebastian Plamauer and @Enrico Tagliavini: Do you also have the 0310JH
> model?

No model is 0TM99H:
enrico@quantdell ~ $ dmesg | grep XPS
[    0.000000] DMI: Dell Inc. XPS 13 9343/0TM99H, BIOS A07 11/11/2015

And, to be clear, I only had one single crash in about one year usage as reported in comment #66 but it never happened again.
Comment 77 Arnaud Kleinveld 2016-05-12 07:21:12 EDT
I also have a 0310JH model and as far as I know my sound has always worked. Except for the headphones jack, which is making a disturbing ticking sound. The microphone has not worked since the regression was introduced. Fiddling with ALSA settings has no effect on anything.
Comment 78 Michael Meschenmoser 2016-05-18 16:30:40 EDT
I updated to kernel-4.4.9 this evening and sound seemed to work smoothly. But after just 3 tries I was able to reproduce Bug 1317235 (Laptop freezes/crashes on suspend).

My hardware:
DMI: Dell Inc. XPS 13 9343/0TM99H, BIOS A07 11/11/2015
ACPI: DMI detected: DELL XPS 13 (2015) (force ACPI _REV to 5)

Are other people running the XPS 13 hardware with kernel 4.4? Can you please state in Bug 1317235 if you see any problems on your machines?
Comment 79 Francisco Cribari 2016-05-18 16:49:44 EDT
@Michael Meschenmoser Which 9343 configuration do you have? I have the 0310JH configuration (Intel i7 processor, touchscreen, screen resolution: 3200 x 1800 pixels and Broadcom wireless): 

cribari@darwin4 ~ $ dmesg | grep "XPS 13"
[    0.000000] DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015

I've had problems with I2S sound in both Fedora and Arch, even with the most recent 4.5 kernel. See, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=118051 . For me, (I2S) sound works for a while and then crashes, as reported above. 

After the system crash in your machine, does dmesg give you messages like 

[ 634.776942] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 634.776946] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 634.776949] System PCM: error: failed to commit stream -110
[ 634.776951] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110

? This seems to be my case. A colleague of mine is also having problems with (I2S). He runs Fedora and has the same machine as I have: 

[raydonal@buda ~] $ dmesg | grep "XPS 13"
[    0.000000] DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A03 03/25/2015
Comment 80 Niccolò Belli 2016-05-19 05:17:47 EDT
This laptop is a nightmare regarding random crashes. One of the known ones which Dell has no intention to solve is the hid-multitouch one, which happens only on touch models: https://bugzilla.kernel.org/show_bug.cgi?id=105251
But there are plenty of them: http://comments.gmane.org/gmane.comp.file-systems.btrfs/56036
Bugs are ok if someone is willing to fix them, but since Dell developers couldn't care less this is a note for the future me: do not buy Dell anymore.
Comment 81 Griddick 2016-05-19 10:25:25 EDT
Hi, I've not had sound from the speakers on my XPS for a while now and there does not seem to be any magic bullet mentioned in this thread (missed the versionlock boat and a bit of a computer layman).

Is this problem likely to be solved when we leap to kernel-4.5.0 or is it more complex than that?

Laptop breed:
[    0.000000] DMI: Dell Inc. XPS 13 9343/0TM99H, BIOS A05 07/14/2015
Comment 82 Herald van der Breggen 2016-05-19 10:45:14 EDT
I am only aware of a "rusty" bullet: stay with kernel 4.3.5 like mvetter suggested in comment 13. It works for me, but ... well... :-/
Comment 83 pip 2016-05-19 12:49:05 EDT
I got sound back with kernel 4.5.2-302 @  Fedora 24 alpha.
Comment 84 Mads Villadsen 2016-05-19 13:08:20 EDT
I am at 4.5.4-300 with Fedora 24 Beta. Sound is back with the alsa-mixer hack but the microphone doesn't work
Comment 85 Cody 2016-05-19 14:12:05 EDT
(In reply to Enrico Tagliavini from comment #72)
> Notable changes between Fedora 22 and 23 are:
>  - kernel upgraded from 4.4.6 to 4.4.8. No idea if anything relevant
> happened or was backported here

Seeing your comment https://bugzilla.kernel.org/show_bug.cgi?id=114171#c23 (which is the same I'm quoting but had I not looked at that other bug I might not have reread the comment and the part about the kernel) I was inspired once more to try updating alsa:

alsa-lib.i686                          1.1.1-1.fc23                    @updates
alsa-lib.x86_64                        1.1.1-1.fc23                    @updates
alsa-lib-devel.x86_64                  1.1.1-1.fc23                    @updates
alsa-plugins-pulseaudio.i686           1.1.1-1.fc23                    @updates
alsa-plugins-pulseaudio.x86_64         1.1.1-1.fc23                    @updates
alsa-utils.x86_64                      1.1.1-1.fc23                    @updates

And then I got in /var/log/messages :

[alsa-sink-ALC1150 Analog] alsa-sink.c: Error opening PCM device front:0: Invalid argument

Every second (when e.g. audacious or vlc were playing). This time I decided to look up the error (I knew the process was getting an EINVAL but that was about all I knew; initially I tinkered with alsamixer but then no luck so restored back to defaults). https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Users/Troubleshooting/ suggests starting pulseaudio manually with -vvv for debugging purposes. So I sent pulseaudio a SIGTERM and was about to start it again but to be sure I checked if it was running again; it was.

But a wondrous thing happened: sound works! I did get an error (but I'm not sure if that's right as I terminated the pulseaudio process; it does seem like it is related but I have no interest whatsoever to look at the source code so it's only a hunch) as such:

> dbus[1191]: [system] Failed to activate service 'org.bluez': timed out
> pulseaudio[16412]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Before: Linux 4.4.6-301.fc23.x86_64
Now: Linux 4.4.9-300.fc23.x86_64
4.4.9-300.fc23.x86_64

So it seems that restarting pulseaudio did the trick for me; whether I have problems after a system reboot (or even before) I will worry about later; any problems and I'll report (and will downgrade to the previous alsa version as sound is mandatory on this box at least if I don't want to become even more insane).
Comment 86 Enrico Tagliavini 2016-05-19 15:33:36 EDT
(In reply to Cody from comment #85)
> So I sent pulseaudio a SIGTERM and was about to start it
> again but to be sure I checked if it was running again; it was.

FYI pulseaudio respawn itself if terminated or killed. The kill is effective in making it fully reinitialize. Seems to suggest the first initialization gone wrong for some reason. Also note that with the update I did mentioned a major update of pulseaudio was present alongside alsa, be sure to apply both.

If you need to temporary disable pulseaudio autospawn you can uncomment the entry in /etc/pulse/client.conf. See: https://wiki.debian.org/PulseAudio#Solving_Problems
Comment 87 Cody 2016-05-19 18:57:06 EDT
(In reply to Enrico Tagliavini from comment #86)
> (In reply to Cody from comment #85)
> > So I sent pulseaudio a SIGTERM and was about to start it
> > again but to be sure I checked if it was running again; it was.
> 
> FYI pulseaudio respawn itself if terminated or killed. The kill is effective
> in making it fully reinitialize. Seems to suggest the first initialization
> gone wrong for some reason. Also note that with the update I did mentioned a
> major update of pulseaudio was present alongside alsa, be sure to apply both.

Yes, I presumed as such. I also had everything updated except alsa. But the recent version of alsa (and pulseaudio plugin) caused sound to fail. It was on a whim that I decided to bother with this - and I'm glad I did. I'll report if there are additional problems.

Thank you for additional information; I can't see myself needing to disable it from restarting, though - the idea was to increase verbosity but it seems that might not be needed after all.
Comment 88 Cody 2016-05-20 10:48:59 EDT
(In reply to Cody from comment #87)It was
> ... on a whim that I decided to bother with this - and I'm glad I did. I'll
> report if there are additional problems.

So from my end all seems OK even after a reboot. Yesterday sound was stopped (I mean to say I stopped and also paused) several times and it was fine in both vlc and audacious. The following applies on this box :

> $ uname -r
> 4.4.9-300.fc23.x86_64
> $ rpm -q alsa-{plugins-pulseaudio,lib,utils} pulseaudio
> alsa-plugins-pulseaudio-1.1.1-1.fc23.x86_64
> alsa-plugins-pulseaudio-1.1.1-1.fc23.i686
> alsa-lib-1.1.1-1.fc23.x86_64
> alsa-lib-1.1.1-1.fc23.i686
> alsa-utils-1.1.1-1.fc23.x86_64
> pulseaudio-7.1-1.fc23.1.x86_64

And my audio set up is default. No changes in hardware nor did I change any settings elsewhere.

But of course I can't say this will work for everyone; indeed this is a custom built box and it seems others have a laptop. I am on Haswell (i7 4790k):

> 00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
> Subsystem: ASUSTeK Computer Inc. Device 8608
> [...]
> Kernel driver in use: snd_hda_intel
> Kernel modules: snd_hda_intel

Snipped out some of lspci -vvv (audio specific obviously) because I didn't think it relevant. By all means if anyone wants more information just say so (and what you want me to do).
Comment 89 Arnaud Kleinveld 2016-05-23 11:14:46 EDT
Suddenly everything is working again. No ticking sounds through my headphones and input device showing up in sound settings and working.

Before this I tried to install a few older kernels because I needed my input device for a recording. None of the kernels (4.2 & 4.3) I tried made the input device work.

Then I restarted back into 4.4.9-200 and audio was working but as usual with headphone ticking and input device missing. After a while an event triggered a sound effect a short cracking sound was audible and then the sound device stopped working. Didn't see any messages on this with dmesg. 

I opened alsamixer and unmuted 2 or 3 channels which didn't help. Then I tried to manually reload the sound modules, starting with unloading snd_soc_sst_acpi. The command hang and I my mouse stopped working. I managed to shut down the running applications using my keyboard and I had to hard shutdown the OS with the power button.

After the reboot all devices were mysteriously working again. Even the headphones and headphone microphone show nicely in the devices list, and the ticking sound is gone. All completely back to normal again, as it was before the first issues appeared.

Dell Inc. XPS 13 9343/0310JH, BIOS A05 07/14/2015
Comment 90 James R. Wyatt 2016-05-25 22:05:26 EDT
I tried 4.4.9-300 and no such luck. I am pinned on 4.3.5 without issue other than wasting time on uninformed reports on this thread. To me this remains a regression with a lame excuse for not being reverted.
Comment 91 Cody 2016-05-25 23:33:08 EDT
(In reply to James R. Wyatt from comment #90)
> I tried 4.4.9-300 and no such luck. I am pinned on 4.3.5 without issue other
> than wasting time on uninformed reports on this thread. To me this remains a
> regression with a lame excuse for not being reverted.

(If it isn't obvious this first part is rhetorical) Uninformed reports? What do you expect us to report? Or maybe you mean the devs? In that case I somewhat understand.

But as for regressions... it seems to me there are a lot of those in recent years and I won't argue with 'lame excuses'. I will however offer this (and this comes from being both a developer - not related to RH - as well as a user [including but not only my own software]): no one can see all ends, so whilst this is possibly a ridiculous regression there is the possibility that it isn't that simple; there are multiple components here, after all. Critically, the fact it works for some of us means it most certainly is *not* necessarily that simple. This is meant to be reciprocal; developer works with user in order to resolve problems and happily coexist (this includes showing appreciation; do not undervalue appreciation!). It can be frustrating, yes, but developers can be frustrated too! I hope you understand that although I'm not going to argue on the matter, either; indeed you're welcome to believe whatever you like (i.e. don't take this to be a personal attack).
Comment 92 Arnaud Kleinveld 2016-05-26 03:48:02 EDT
I was able to reproduce the fix I comment #89 before. After a waking from suspend the sound was not working and the sound configuration was showing the devices I normally see when I connect my headphones. 

Trying to change the volume with FN+F2/F3 showed it was changing the headphone volume, while I never connect them. In the sound configuration I also tried selecting the broadwell speakers but without luck. Sound was not working.

Then I was able to reproduce the fix of comment #89.

1) Shut down the OS completely. Reboot alone didn't work.
2) Boot into 4.2.8-200. I assume any version for which the sound is known to work well will do.
3) Open sound configuration and check if sound works.
4) Reboot into 4.4.9-200 without shutting down completely.

The sound will work until the next suspend or complete shutdown. Both have different outcomes. I have tried many variations and only the exact above steps made it working again. Also the microphone input and headphone jack are working again. At one point I had to follow the above steps twice.

Dell Inc. XPS 13 9343/0310JH, BIOS A05 07/14/2015
Comment 93 gil cattaneo 2016-05-30 06:14:11 EDT
hi
i have the same problem (i need to disable hdmi support). i use kde

$ lsmod | grep snd
snd_hda_codec_realtek    73728  0
snd_hda_codec_generic    69632  2 snd_hda_codec_realtek
snd_hda_codec_hdmi     49152  4
snd_hda_intel          32768  7
snd_hda_codec         114688  4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
snd_hda_core           57344  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
snd_hwdep              16384  1 snd_hda_codec
snd_seq                57344  0
snd_seq_device         16384  1 snd_seq
snd_pcm                98304  4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core
snd_timer              28672  2 snd_pcm,snd_seq
snd                    65536  24 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device
soundcore              16384  1 snd

$ lspci | grep -i audio
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40)
04:00.1 Audio device: NVIDIA Corporation GT216 HDMI Audio Controller (rev a1)
$ lspci -k | grep -E "Audio" -A 2
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40)
        Subsystem: ASRock Incorporation Device 0892
        Kernel driver in use: snd_hda_intel
--
04:00.1 Audio device: NVIDIA Corporation GT216 HDMI Audio Controller (rev a1)
        Subsystem: ASUSTeK Computer Inc. Device 830f
        Kernel driver in use: snd_hda_intel

$  dnf list installed | grep pulseaudio

alsa-plugins-pulseaudio.i686             1.1.1-1.fc23              @System      
kde-settings-pulseaudio.noarch           23-11.fc23.1              @System      
pulseaudio.i686                          7.1-1.fc23.1              @System      
pulseaudio-libs.i686                     7.1-1.fc23.1              @System      
pulseaudio-libs-glib2.i686               7.1-1.fc23.1              @System      
pulseaudio-module-bluetooth.i686         7.1-1.fc23.1              @System      
pulseaudio-module-x11.i686               7.1-1.fc23.1              @System      
pulseaudio-utils.i686                    7.1-1.fc23.1              @System  
    
$  dnf list installed | grep alsa

alsa-lib.i686                            1.1.1-1.fc23              @updates     
alsa-plugins-pulseaudio.i686             1.1.1-1.fc23              @System      
alsa-utils.i686                          1.1.1-1.fc23              @updates

$  dnf list installed | grep kernel
abrt-addon-kerneloops.i686               2.8.0-5.fc23              @updates     
kernel.i686                              4.4.7-300.fc23            @updates     
kernel.i686                              4.4.8-300.fc23            @updates     
kernel.i686                              4.4.9-300.fc23            @System      
kernel-core.i686                         4.4.7-300.fc23            @updates     
kernel-core.i686                         4.4.8-300.fc23            @updates     
kernel-core.i686                         4.4.9-300.fc23            @updates     
kernel-debug-devel.i686                  4.4.7-300.fc23            @updates     
kernel-debug-devel.i686                  4.4.8-300.fc23            @updates     
kernel-debug-devel.i686                  4.4.9-300.fc23            @updates     
kernel-headers.i686                      4.4.9-300.fc23            @updates     
kernel-modules.i686                      4.4.7-300.fc23            @updates     
kernel-modules.i686                      4.4.8-300.fc23            @updates     
kernel-modules.i686                      4.4.9-300.fc23            @updates     
kernel-modules-extra.i686                4.4.7-300.fc23            @updates     
kernel-modules-extra.i686                4.4.8-300.fc23            @updates     
kernel-modules-extra.i686                4.4.9-300.fc23            @updates

journalctl -b
https://gil.fedorapeople.org/journalctl2016-05-30.txt
Comment 94 gil cattaneo 2016-05-30 18:46:02 EDT
pulseaudio -vvvv
https://gil.fedorapeople.org/pulseverbose.log
Comment 95 Francisco Cribari 2016-05-31 18:44:55 EDT
For some people (myself included) I2S audio crashes after a while and dmesg informs

[ 3977.821164] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 3977.821167] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 3977.821169]  System PCM: error: failed to commit stream -110
[ 3977.821171] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110

I believe those crashes are somehow cause by gdm (perhaps through pulseaudio). They do not happen when LightDM is used. My 9343 model is that with Intel i7, 3200 x 1800 resolution, touchscreen, Broadcom wireless: 

cribari@darwin4 ~ $ dmesg | grep "XPS 13"
[    0.000000] DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
Comment 96 Brennan Ashton 2016-06-08 13:47:25 EDT
Is there any information that you need to help resolve this bug? I have had the constant clicking in my headphones when no sound is playing since I installed the alsa-ucm 1.1.1 update.
Comment 97 James R. Wyatt 2016-06-18 12:41:18 EDT
Found the solution. Ubuntu. 16.06 installs without issue. So long Fedora, it has been real.
Comment 98 Arnaud Kleinveld 2016-06-18 23:09:40 EDT
(In reply to James R. Wyatt from comment #97)
> Found the solution. Ubuntu. 16.06 installs without issue. So long Fedora, it
> has been real.

What is your kernel version? Output of uname -a please

Thanks,
Arnaud
Comment 99 Francisco Cribari 2016-06-19 12:07:53 EDT
I am the person who filed this bug report. I switched to Arch Linux when it was using kernel 4.4 (like Fedora, at the time). I had the same problem with Arch. And I had the same problem with Arch and kernel 4.5 and I've been having the same problem with Arch and the 4.6 kernel series. I currently run kernel 4.6.2. I know that Fedora is Fedora and Arch is Arch, but I decided to share my experience here because I believe the bug that affects me is common to both distributions (and perhaps to other distributions). My 9343 machine is that with Intel i7 processor, 3200 x 1800 pixels resolution, touchscreen, Broadcom wireless (+ bios A07): 

cribari@darwin4 ~ $ dmesg | grep "XPS 13"
[    0.000000] DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015

(Notice: touchscreen.) I run Gnome 3.20 + GDM. My problem in nutshell: I2S sound works for a while and then crashes. A dmesg dump is available at http://pastebin.com/D3iyt0GA . 

After the crash dmgesg informs

dmesg informs

[ 4832.751107] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 4832.751115] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 4832.751119] System PCM: error: failed to commit stream -110
[ 4832.751124] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 4832.751128] System PCM: ASoC: hw_params FE failed -110
[ 4833.054400] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000
[ 4833.054404] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed
[ 4833.054407] System PCM: error: failed to commit stream -110
[ 4833.054409] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110
[ 4833.054412] System PCM: ASoC: hw_params FE failed -110

Upon inspection of the dmesg dump available at http://pastebin.com/D3iyt0GA I get the feeling that the crash happens at this point 

[ 5193.181346] haswell-pcm-audio haswell-pcm-audio: error: audio DSP boot timeout IPCD 0x0 IPCX 0x0

There is a discussion of the problem at https://bugs.archlinux.org/task/48936 . I filed an Arch bug report: https://bugs.archlinux.org/task/49556 . 

After trying many tweaks, I found out the problem is somehow caused by GDM (perhaps through pulseaudio). The crashes no longer happen when LightDM is used. This is my experience and also that of other people who have the touchscreen 9343 notebook + GDM.

I thus believe that there is still a problem that affects users who run GDM and have the touchscreen 9343 model. More details can be obtained in the above links.
Comment 100 James R. Wyatt 2016-06-19 21:19:15 EDT
uname -a:

Linux ***** 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


dmesg |grep "XPS 13":

DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015


Mis-type in my earlier snarky response. It is Ubuntu 16.04 not 16.06. No problems and a simple checkbox installed all necessary proprietary drivers. Sound is working fine after several reboots. 


Thank you Francisco for filing this report and following up with more than enough detail for the kernel maintainers to fix. If you read this ridiculously long thread, one of the maintainers owned up the changing a compiler flag on the first 4.4 build which exposed an issue that was being covered up by what was admittedly a hack. Rather than revert, the group decided they would leave the change so as to gather as much information as possible before implementing a fix. I am completely okay with this as well, but that was over 100 days ago. 

You can argue academic reasons for creative responses to software flaws , but what you can't do is impact users over a known issue that could easily be recreated on a few developer machines with a simple flag and custom kernel build.

I left Ubuntu for Fedora around 5 years ago when they unilaterally switched the user experience to Unity which I thought was a major downgrade (even given the problems Gnome was having at the time). Now there is a Gnome remix of Ubuntu that is almost identical to the Fedora experience. The only difference I have found so far is that the user experience is noticeably faster.

I hate to be critical about what is otherwise a great project, but I am tired of stuff breaking and not being fixed when a fix is known based on motivations that are not doing what is best for the users. 

My only remaining problem is how to remove my Fedora stickers I so proudly put on my laptop case. First world problem I guess.
Comment 101 Herald van der Breggen 2016-06-22 11:39:10 EDT
I noticed Fedora 24 is released yesterday. This makes me wonder... did the Fedora engineers nail the problem in this release? Anyone?
Comment 102 pip 2016-06-22 16:12:49 EDT
(In reply to Herald van der Breggen from comment #101)
> I noticed Fedora 24 is released yesterday. This makes me wonder... did the
> Fedora engineers nail the problem in this release? Anyone?

Yes, I had the sound system back in Fedora 24 beta.
Comment 103 James R. Wyatt 2016-06-22 20:16:39 EDT
Kernel panic for me on boot after upgrade but after the freeze. I am going to do a fresh install of the official release so I don't have to change my stickers :) Ubuntu is nice, but my loyalty lies with RedHat. If however this doesn't work, I will be back to call it out. I apologize for the snarkiness but if I pulled something like this I would be fired.
Comment 104 Francisco Cribari 2016-06-22 20:42:37 EDT
#102 and #103 Do you have the touchscreen model? Do you run GDM+Gnome?
Comment 105 James R. Wyatt 2016-06-22 22:32:01 EDT
Yes and yes.

Installed fresh official release and no dice on the sound. Also no coordination with proprietary driver repos on the release. I can deal with the proprietary drivers lagging behind, and I get it. I am a FSF contributor, but what I can't deal with is people who don't understand what a valid test is. Yes, pip, I am talking to you.

https://www.youtube.com/watch?v=cqhLO3SRyXU. 

I really wish I didn't have to go the Ubuntu route, but what choice am I left with? I couldn't put a space in my name (not username) in the installer. This is sloppy, and not just my sound, but a space validation on my name? It's like you when you lie about little things. How do I know you are telling the truth on the things that matter? You let the little bugs through and then expect me to trust your distro? Kernel panic on upgrade after the freeze? So many things.

Also ditching this amateur hour on my desktop. My completely open source and FSF approved wireless adapter was working fine on F23 after some issues on F22. Now it has regressed. This is just beyond sloppy and not at all an indication of the strength of the community. This is an indication on the quality of folks who are cutting releases and accepting patches. I get it if you are volunteering your time, and I appreciate it, but if you are getting paid then you should find another career path.

Maybe a simple questionnaire for contributors/maintainers: have you ever written anything beyond hobby software? Check yes for maybe, check no for find another distro. 

Goddammit. I hate Ubuntu!
Comment 106 James R. Wyatt 2016-06-22 22:39:13 EDT
For anyone else struggling. Download the gnome remix:

http://cdimage.ubuntu.com/ubuntu-gnome/releases/xenial/release/ubuntu-gnome-16.04-desktop-amd64.iso 

find a usb key, and:

sudo dd if=ubuntu-gnome-16.04-desktop-amd64.iso of=<insert your drive here something like /dev/sdd, but make sure you unmount any file systems first> bs=1M

Boot and enjoy a better product.

Okay, no more rants. Take it easy.
Comment 107 Francisco Cribari 2016-06-22 23:06:59 EDT
I have the touchscreen 9343 model. I have been struggling with I2S audio crashes since I filed this bug report. I am a regular, average Linux user. I have already spent a large number of hours on this bug. Quite large! Regular users shouldn't have to do that. I am not beta user. I switched from Fedora to Arch hoping that even more bleeding edge software would bring me a faster solution. It did not. The silver lining is that it's very easy to compile Arch kernels via ABS: https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System . What I am doing: I am compiling my kernels with  

CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y

so that I have HDA sound (not I2S). Otherwise, audio crashes after a while. I filed bug reports (Fedora, Arch and kernel), I experimented with possible solutions, I narrowed down the problem to GDM etc. I hoped for a solution. No solution came (at least for the touchscreen + GDM combo). I hoped for some hint that this nasty bug was a priority to Fedora and Arch developers. Sincerely, I believe it was never a priority. (I may be wrong. I hope I am wrong. I am willing to apologize if I am wrong.) I live in a third world country (Brazil). This XPS machine is quite expensive where I live. I cannot simply throw it away and buy another machine right now. 

This bug has been my worst experience with Linux. Ever. I would hate to have to go back to Ubuntu. My current choices are: (i) go back to Ubuntu or (ii) keep compiling my Arch kernels (it only takes about 50 minutes to compile the kernel). I am terribly disappointed. As a user, I dutifully reported the bug and shared relevant information. The solution never came. 

Arch bug I submitted: https://bugzilla.kernel.org/show_bug.cgi?id=118781
Kernel bug I submitted: https://bugzilla.kernel.org/show_bug.cgi?id=118051
Fedora bug I submitted: this one
Where I shared a lot of information: https://bugs.archlinux.org/task/48936

What else can be done? Is there still hope?
Comment 108 James R. Wyatt 2016-06-22 23:52:23 EDT
Nothing. No. All is forsaken.
Comment 109 Enrico Tagliavini 2016-06-23 03:06:12 EDT
@Francisco you did well reporting the bug indeed, but fixes do not happen by magic. This is a very nasty issue (the crash part of it). What makes it nasty is that it's hard to reproduce. I would claim you are having an hardware issue, but the crash you mentioned actually happened to me twice. Twice in more than one full year. And it happens right after boot, not during runtime to me. So you have an issue almost impossible to reproduce which affect only a very specific model of laptop. Probably few thousands machines in the worlds out of millions running Linux. No it's not a priority I'm afraid :(. And if the fix would be easy they would have applied it already, believe me (and no CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not a fix, it's a corner cut).

And about the hardware issue: don't be so hasty blaming the driver. Sometimes it's actually an hardware issue. I was having problems with iwlwifi once. Driver was spitting out a lot of stuff on the kernel message, almost one month try to fix it with Intel developers. Then I simply tried to attach bluetooth antenna to WiFi (yes you can, yes it is supposed to work) and everything worked. My WiFi antenna was busted, changed it, everything was good.

I can suggest you two things at this point. You did what needs to be done with the community, try to escalate this with the vendor. Dell sells the same model with Ubuntu, and that's still Linux. Also try with Intel and Realtek (don't have much hope with the latter honestly) the driver is called broadwell-rt286 after all. That's the people you ultimately pay, it's worth a try. If you do claim that a lot of other people are not having it and link all the reports you done :).

Also to consider as a different workaround (which I used in the past when my sound card was fried): http://www.terratec.com/details.php?artnr=195448
Comment 110 pip 2016-06-23 07:45:20 EDT
(In reply to Francisco Cribari from comment #104)
> #102 and #103 Do you have the touchscreen model? Do you run GDM+Gnome?

Yes and yes. Fresh install of Fedora 24 two days ago, since I bought a new SSD. 
Only microphone was muted, got it back by alsamixer, F6 (broadwell-rt286), F4 capture settings. 
Kernel is 4.5.7-3oo, alsa 1.1.1.
@James, teach me, what'd be the proper test in my case?
Comment 111 Francisco Cribari 2016-06-23 08:39:05 EDT
@Enrico Thank you for the suggestions. If you look at 

https://bugs.archlinux.org/task/48936#comment146935

you will notice that this user (@Willy) is having exactly the same problem as I am having (i.e., the same audio crashes). And he also points out to GDM as the root of the problem; see https://bugs.archlinux.org/task/48936#comment147488 . 

On a different front, some users do not even have their sound card recognized (MAX98090 on Bay Trail); see https://bugs.archlinux.org/task/48936#comment147531 .
Comment 112 Michael 2016-06-24 08:58:18 EDT
If anybody needs them, here are the kernel RPMs built with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y

http://self.run/dell-xps-13-9343

I have subscribed to all the forums and bugzillas where this bug is reported and discussed. Not sure there is even anything going on though. AFAIK nobody behind the drivers or alsa has accepted this as their responsibility. So I'll stick with compiling kernels and exclude=kernel* for the time being.
Comment 113 ph0boss33 2016-06-26 13:38:51 EDT
(In reply to Michael from comment #112)
I had the same problem with 9343 in fedora 23. Have not tried F24 though, so can't comment on that. Switched to opensuse tumbleweed and didn't have a problem since then. In opensuse leap the sound didn't work too if I remember correctly, but I might be wrong. Do not consider this an advertisement please, just maybe they solved this problem already.
Comment 114 Herald van der Breggen 2016-06-27 08:54:53 EDT
FWIW, it tried F24 using a live-image from USB-stick and sound worked out of the box. I played an .ogg file for 45 minutes or so, without any problem. So, it looks like the problem (at least for the hardware I use) is solved and I'll upgrade soon (right now still F23 with 4.3.5 kernel). 

Thanks, Fedora team!

For the record, my hardware:
Dell Inc. XPS 13 9343/0310JH, BIOS A05 07/14/2015

$ lspci -nn | grep -i audio 
00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09)
00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition Audio Controller [8086:9ca0] (rev 03)
Comment 115 Michael 2016-06-27 09:14:57 EDT
@Herald,

Before you jump to conclusions be sure that:

1. You don't need/want BIOS update. Current is A07 and you have A05.
2. You did power off the machine twice between 4.3 and 4.5 kernels (I2S to HDA and viceversa).
3. You can hear sound without clicking and crackling noises in the headphones.
4. The inline microphone is detected and can be recorded from.

I understand that you may not care about some of these but the fc24 upgrade doesn't bring anything new with it. I2S problem is still there.
Comment 116 Michael 2016-06-27 09:30:47 EDT
@ph0boss33,

There is no distribution that can SOLVE this problem without someone SOLVING it in kernel. There is a workaround that had been disabled in most of the distributions. There is no guarantee that opensuse or bubuntu or whatever sabayon will keep the  CONFIG_ACPI_REV_OVERRIDE_POSSIBLE there until the I2S will be fixed. If ever.
Comment 117 Herald van der Breggen 2016-06-27 10:00:41 EDT
(In reply to Michael from comment #115)
> @Herald,
> 
> Before you jump to conclusions be sure that:
> 
> 1. You don't need/want BIOS update. Current is A07 and you have A05.
> 2. You did power off the machine twice between 4.3 and 4.5 kernels (I2S to
> HDA and viceversa).
> 3. You can hear sound without clicking and crackling noises in the
> headphones.
> 4. The inline microphone is detected and can be recorded from.
> 
> I understand that you may not care about some of these but the fc24 upgrade
> doesn't bring anything new with it. I2S problem is still there.

Thanks for your comments, you saved me a lot of trouble!

I did notice the difference in BIOS version, but I was not aware of the need to power off twice. When doing the second reboot on F24, sound is absent. And system is confused, it needs the power switch to powering the system down.

So no upgrade for me :-(
Comment 118 James R. Wyatt 2016-06-28 23:36:31 EDT
@Michael

Ubuntu has not "fixed" the hack for I2S as of today and I would be willing to bet that they won't until there is a fix for the root cause in the kernel available. So, they can't fix the issue, but at least they don't unnecessarily and academically force it on their users.

As of updates available today, Ubuntu 16.04 is working just fine for me. The Linux desktop has made it a long way, just not on Fedora where the kernel maintainers don't seem to care about end user hardware.
Comment 119 Enrico Tagliavini 2016-06-29 04:39:26 EDT
James the Fedora kernel maintainers explained their reasons for not disabling I2S in a previous comment, and that's not the only distro doing so (see also arch linux for example). It's not a matter of if the reason is right or not, it's just a choice. I can very well understand you don't agree with it and that's fine. You also suggested an alternative for the people in a similar situation as you, moving to Ubuntu. And that's fine as well.

But now please I kindly ask to stop it here, since it's not adding any help on solving the problem.

I opened a bug in the upstream kernel bugzilla, where this issue should be solved. Who wants to help can go here https://bugzilla.kernel.org/show_bug.cgi?id=114171

Note: I just reported the missing audio out of the box. The crash problem Francisco is having is not something I experience frequently, hence I will not report it.
Comment 120 ph0boss33 2016-07-01 04:06:45 EDT
Just installed Fedora 24, kernel 4.5.7, everything works fine. The sound card is recognized as broadwell-rt286. I've got 9343 with Core i5. From what I've read the problem occured in i7 models only.
Comment 121 ph0boss33 2016-07-03 14:45:45 EDT
F24, kernel 4.6.3 broke the sound for me. Soundcard is not recognized anymore. Rebooting in 4.5.7 - everything works. How should I collect the details and should they be posted here or start a new bug?
Comment 122 Josh Boyer 2016-07-03 22:55:23 EDT
(In reply to ph0boss33 from comment #121)
> F24, kernel 4.6.3 broke the sound for me. Soundcard is not recognized
> anymore. Rebooting in 4.5.7 - everything works. How should I collect the
> details and should they be posted here or start a new bug?

It's already been reported and will be fixed in the next build.
Comment 123 Francisco Cribari 2016-07-08 11:45:20 EDT
@Enrico Tagliavini You claimed that I was having a hardware issue and suggested I contacted Dell. I followed your advice. Dell does not sell notebooks with (Ubuntu) Linux installed in my country (Brazil) and offers no support for machines running Linux. After a fairly large of phone calls back and forth, however, they agreed to replace my notebook's motherboard. (Kudos to Dell!) I am still running Arch with kernel 4.6.3-1. I can report that audio now works and that I am no longer experiencing the I2S audio crashes I reported. (At least, so far. It has been 3 days already since they serviced my notebook.) I hence believe you were right. 

I still have one problem, though: internal mic does not work.
Comment 124 Enrico Tagliavini 2016-07-08 12:14 EDT
Created attachment 1177701 [details]
enable capture for ADC0

@Francisco Cribari I'm glad you don't have the crash anymore. Well I assume you might still have it rarely since, as I said, I have it too, just extremely rare.

About the internal microphone: I had to enable the CAPTURE on ADC0 in alsamixer, this was the trick to have it back working for me. I've attached a screenshot of alsamixer as it should look like with CAPTURE enabled (note the red label "CAPTURE" above ADC0, it must be present, if not it's disabled).

To enable CAPTURE select ADC0 and then press space bar. I hope this helps you as well.
Comment 125 Nabeel88@gmail.com 2016-07-12 23:50:03 EDT
This bug is also affecting me.  Is there any idea on when the next kernel will allow this to be fixed?  I have installed Ubuntu in the mean time, but I would like to get back to Fedora.
Comment 127 Nabeel88@gmail.com 2016-07-13 12:15:20 EDT
(In reply to Francisco Cribari from comment #126)
> I believe this patch will fix some issues:
> 
> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/
> ?h=topic/intel&id=a395bdd6b24b692adbce0df6510ec9f2af57573e

Thanks for the quick follow up.  Unfortunately, I am not a programmer, so I can't really follow along.  Do you know what will be required to get this patched version of the kernel?  Will we simply have to upgrade to the latest one when it comes out?
Comment 128 Francisco Cribari 2016-07-13 12:36:04 EDT
(In reply to Nabeel88@gmail.com from comment #127)

> Thanks for the quick follow up.  Unfortunately, I am not a programmer, so I
> can't really follow along.  Do you know what will be required to get this
> patched version of the kernel?  Will we simply have to upgrade to the latest
> one when it comes out?

I am not a programmer either. From what I read elsewhere (an Arch Linux bug report), this patch will most likely be merged in the 4.8 kernel series.
Comment 129 Josh Boyer 2016-07-13 12:47:40 EDT
(In reply to Francisco Cribari from comment #128)
> (In reply to Nabeel88@gmail.com from comment #127)
> 
> > Thanks for the quick follow up.  Unfortunately, I am not a programmer, so I
> > can't really follow along.  Do you know what will be required to get this
> > patched version of the kernel?  Will we simply have to upgrade to the latest
> > one when it comes out?
> 
> I am not a programmer either. From what I read elsewhere (an Arch Linux bug
> report), this patch will most likely be merged in the 4.8 kernel series.

Again, the Fedora release kernels should already have the config change necessary such that the aforementioned patch doesn't matter.  Only the rawhide kernel lacks the config settings.
Comment 130 Nabeel88@gmail.com 2016-07-13 17:10:14 EDT
(In reply to Josh Boyer from comment #129)
> (In reply to Francisco Cribari from comment #128)
> > (In reply to Nabeel88@gmail.com from comment #127)
> > 
> > > Thanks for the quick follow up.  Unfortunately, I am not a programmer, so I
> > > can't really follow along.  Do you know what will be required to get this
> > > patched version of the kernel?  Will we simply have to upgrade to the latest
> > > one when it comes out?
> > 
> > I am not a programmer either. From what I read elsewhere (an Arch Linux bug
> > report), this patch will most likely be merged in the 4.8 kernel series.
> 
> Again, the Fedora release kernels should already have the config change
> necessary such that the aforementioned patch doesn't matter.  Only the
> rawhide kernel lacks the config settings.

Thanks for the follow up Josh.  Sorry for all the simplistic questions, I am still learning.  Does this mean that if I reinstall Fedora today that this problem should no longer exist?  If so, I can give it a shot and report back so that you can close the bug.
Comment 131 Kostya Berger 2016-07-14 04:09:26 EDT
(In reply to James R. Wyatt from comment #118)
> @Michael
> 
> Ubuntu has not "fixed" the hack for I2S as of today and I would be willing
> to bet that they won't until there is a fix for the root cause in the kernel
> available. So, they can't fix the issue, but at least they don't
> unnecessarily and academically force it on their users.
> 
> As of updates available today, Ubuntu 16.04 is working just fine for me. The
> Linux desktop has made it a long way, just not on Fedora where the kernel
> maintainers don't seem to care about end user hardware.

Right. Not only does my sound fail to work with kernels starting from 4.2* series, but also wifi driver doesn't load automatically. Version 4.1.13 has no problems in either of these...

Tried to report MY sound problem in one of these sound-related bug threads here, but was answered that the thread was "specifically" about some HP laptops not having sound with that kernel and NOT about newer kernels in general. Fine! Let's open, then, a new bug for every instance of sound not working with new kernels?

...So yes, I'm using now Ubuntu 16.04 and had to say bye to Fedora.

Neither is Fedora forum of any help at all: you wait for eternity until finally you get some obvious answer pretending to reveal some hidden truth... by which time you've already figured out the solution yourself.
Comment 132 Cody 2016-07-14 10:50:29 EDT
This is meant for everyone so please do not take this as targeting you (Kostya). As a developer (of much smaller projects but nevertheless with user bases throughout the years) and obviously also a user I want to offer perspective. I'm not trying to criticise you or anyone else (who am I to criticise someone I don't even know ?) but if you want to call it that my intent is to be constructive.


(In reply to Kostya Berger from comment #131)

> Tried to report MY sound problem in one of these sound-related bug threads
> here, but was answered that the thread was "specifically" about some HP
> laptops not having sound with that kernel and NOT about newer kernels in
> general. Fine! Let's open, then, a new bug for every instance of sound not
> working with new kernels?

I understand and sympathise with you. It is frustrating; the system should work and shouldn't be broken by updates. But software is created by humans and so it is inevitable at times it breaks (doesn't make it any less frustrating but it is worth remembering). On my behalf sound is absolutely critical this computer (as this computer in question isn't a server). I had an issue here too and I don't have a laptop at all (custom built). Whether the bug in question (you refer to) is 'only' for HP laptops or not I don't know nor do I care (or think it relevant). But look at it this way: there are more users with problems than developers here (okay maybe I'm wrong but it seems to me likely) and at least in this bug report the (or some) problems are hard to reproduce and those types of bugs are especially frustrating for all parties - and they can be extremely difficult to find. Is that all valid here? I don't know or care but it's something to keep in mind anyway.

> 
> ...So yes, I'm using now Ubuntu 16.04 and had to say bye to Fedora.
> 
> Neither is Fedora forum of any help at all: you wait for eternity until
> finally you get some obvious answer pretending to reveal some hidden
> truth... by which time you've already figured out the solution yourself.

Right. Even people who are paid to help others will only take so much ungratefulness and/or abuse/criticism/whatever you wish to call it before they become less helpful (if not try to undermine you without your knowledge). But these people aren't paid (well okay maybe some of them are but it isn't exactly a forum of paid tech support or it isn't last I knew). Of course, since you already figured out the solution (if changing to another distribution is a 'fix' in your mind then so be it) I guess it doesn't matter.

In the end everyone (all parties) should remember this: there are at least two sides to these problems and if you are rude/disrespectful/unhelpful then you can't (reasonably i.e. shouldn't) expect anything else in return (and yes I fully realise some developers do the exact same thing but is that a reason to not bother on your behalf?). Do what you will with that knowledge but as both a user and a developer I can tell you this is the way it is (it isn't even specific to software) whether you like it or not.

Cheers.
Comment 133 Nabeel88@gmail.com 2016-07-15 17:18:37 EDT
Tested the LiveCD today.  Problem continues.  Get dummy output that shows that attempts to output to the HDMI port/headphone port.
Comment 134 Herald van der Breggen 2016-07-16 03:11:26 EDT
@redhat: can somebody please give an update on this problem? 

It is clear that kernel 4.3.5-300.fc23.x86_64 is the last one that did not break sound and it is also clear that it is not possible to upgrade to Fedora 24 without breaking sound (unless you build custom kernels of course).

I can live with that for another few months, but what worries me is that there is no idea about who will solve the problem and how it will be solved. It is even unclear to me if the problem will be solved. I guess this is what frustrates people most.

If you don't know the answer either, that would also be valuable information to me. 

Thanks in advance.
Comment 135 Nabeel88@gmail.com 2016-07-16 09:01:24 EDT
Just retested with the latest release kernel and it works.  In order to update to the latest kernel, type this as root in terminal:

dnf install kernel kernel-devel --enablerepo=updates-testing --best
Comment 136 Francisco Cribari 2016-07-16 09:33:55 EDT
I am no expert or programmer, but from I've read in Arch Linux bug reports, the implemented solution still does not work on all 9343 machines, for instance, it does not work on those with MAX98090 on Bay Trail. Nor even the most recent patch, i.e., 

https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=topic/intel&id=a395bdd6b24b692adbce0df6510ec9f2af57573e

(which still has not been merged to the kernel) can make I2S sound work on machines with MAX98090 on Bay Trail.
Comment 137 Arnaud Kleinveld 2016-08-14 07:09:16 EDT
I installed F24 and tested kernel 4.6.5-300 and then testing kernel 4.6.6-300. Both with no luck.

Then I installed kernel 4.3.6-201 from koji and that made everything working again.

Dell Inc. XPS 13 9343/0310JH, BIOS A05 07/14/2015
Comment 138 Kostya Berger 2016-08-15 03:46:35 EDT
Good for you!(In reply to Cody from comment #132)
> This is meant for everyone so please do not take this as targeting you
> (Kostya). As a developer (of much smaller projects but nevertheless with
> user bases throughout the years) and obviously also a user I want to offer
> perspective. I'm not trying to criticise you or anyone else (who am I to
> criticise someone I don't even know ?) but if you want to call it that my
> intent is to be constructive.
> 
> 
> (In reply to Kostya Berger from comment #131)
> 
> > Tried to report MY sound problem in one of these sound-related bug threads
> > here, but was answered that the thread was "specifically" about some HP
> > laptops not having sound with that kernel and NOT about newer kernels in
> > general. Fine! Let's open, then, a new bug for every instance of sound not
> > working with new kernels?
> 
> I understand and sympathise with you. It is frustrating; the system should
> work and shouldn't be broken by updates. But software is created by humans
> and so it is inevitable at times it breaks (doesn't make it any less
> frustrating but it is worth remembering). On my behalf sound is absolutely
> critical this computer (as this computer in question isn't a server). I had
> an issue here too and I don't have a laptop at all (custom built). Whether
> the bug in question (you refer to) is 'only' for HP laptops or not I don't
> know nor do I care (or think it relevant). But look at it this way: there
> are more users with problems than developers here (okay maybe I'm wrong but
> it seems to me likely) and at least in this bug report the (or some)
> problems are hard to reproduce and those types of bugs are especially
> frustrating for all parties - and they can be extremely difficult to find.
> Is that all valid here? I don't know or care but it's something to keep in
> mind anyway.
> 
> > 
> > ...So yes, I'm using now Ubuntu 16.04 and had to say bye to Fedora.
> > 
> > Neither is Fedora forum of any help at all: you wait for eternity until
> > finally you get some obvious answer pretending to reveal some hidden
> > truth... by which time you've already figured out the solution yourself.
> 
> Right. Even people who are paid to help others will only take so much
> ungratefulness and/or abuse/criticism/whatever you wish to call it before
> they become less helpful (if not try to undermine you without your
> knowledge). But these people aren't paid (well okay maybe some of them are
> but it isn't exactly a forum of paid tech support or it isn't last I knew).
> Of course, since you already figured out the solution (if changing to
> another distribution is a 'fix' in your mind then so be it) I guess it
> doesn't matter.
> 
> In the end everyone (all parties) should remember this: there are at least
> two sides to these problems and if you are rude/disrespectful/unhelpful then
> you can't (reasonably i.e. shouldn't) expect anything else in return (and
> yes I fully realise some developers do the exact same thing but is that a
> reason to not bother on your behalf?). Do what you will with that knowledge
> but as both a user and a developer I can tell you this is the way it is (it
> isn't even specific to software) whether you like it or not.
> 
> Cheers.
Sure, sure. And thanks for your reply, you're right about being rude and its consequences. I myself always try to be helpful and share my solutions whenever it seems to be of any use. 

Regarding Fedora forums your guess is hardly right. Cases of abuse are relatively rare at Linux forums and are quite effectively handled there. In any case, they cannot be the cause of a forum's lack of activity. I can be sure of this after more than 10 years of active participation in Linux and FreeBSD  forums. Can see some difference, too.
Comment 139 Herald van der Breggen 2016-08-15 05:17:07 EDT
Since there is no sign of activity on this bug, I have the feeling it might not be solved. I am still running F23 with the 4.3.5 kernel.

This make me wonder... is it an idea to maintain separate kernels for F24 (and later) that support the sound hardware having problems with the recent kernels. Similar to kernels from koji, but up to date and maintained. Maybe it would even be possible to let anaconda install the appropriate kernel. This would be extremely helpful.
Comment 140 Michael 2016-08-15 05:26:24 EDT
Interestingly, people don't really understand where it should be fixed. https://bugzilla.kernel.org/show_bug.cgi?id=114171 has 5 CCed as compared to 38 CCed on this report.

@Herald, that's what I've planned to do but setting up a copr for it didn't go smoothly so I've left it half way done. I believe that we are at our own 9343 fate for quite some time. Still running 4.5.7-300.gfdsa.fc24.x86_64 with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y.
Comment 141 Cody 2016-08-15 13:21:42 EDT
(In reply to Kostya Berger from comment #138)

> Sure, sure. And thanks for your reply, you're right about being rude and its
> consequences. I myself always try to be helpful and share my solutions
> whenever it seems to be of any use.

Which is how it should be, yes. 
> 
> Regarding Fedora forums your guess is hardly right. Cases of abuse are
> relatively rare at Linux forums and are quite effectively handled there. In
> any case, they cannot be the cause of a forum's lack of activity. I can be
> sure of this after more than 10 years of active participation in Linux and
> FreeBSD  forums. Can see some difference, too.

I wasn't implying that; I was pointing out that even those who are paid will only take so much (of whatever might bother them and is it their interpretation and their decision which matters, sometimes unjustified but it doesn't change the reality) before they stop being helpful - and specifically I was responding to the comment:
> > > 
> > > Neither is Fedora forum of any help at all: you wait for eternity until
> > > finally you get some obvious answer pretending to reveal some hidden
> > > truth... by which time you've already figured out the solution yourself.

Now maybe it wasn't meant to be ungrateful but I interpreted it that way (and perhaps it is the tone of the overall message combined) (because it is on their own time). I get it: frustration can also boil over (and I know this personally very well) and at that point you might not even realise exactly how something comes across; it might also be because I have a real problem with people being ungrateful and thankless (and many people are unfortunately that exactly) I am more inclined to read that meaning.

I myself have issues with the way some software has headed - and the way developers of said software have acted - in recent years but I try to be as reasonable as possible when dealing with them (there is a right time and place for all manners and when you're dealing with them I find it most helpful to remember they are people too although admittedly some people - users and developers alike - make it extremely tiring if not impossible). I think that's what I was trying to say; help them help you even if they don't do the same (although they shouldn't complain if they don't but many probably still would/do).
Comment 142 Herald van der Breggen 2016-08-17 05:28:16 EDT
Some advise please: suppose I would upgrade to F24 and would want audio to be working normally. Would that be a matter of simply upgrading and recompiling the kernel with option CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y and reboot with that kernel?
Comment 143 Arnaud Kleinveld 2016-08-17 05:36:05 EDT
(In reply to Herald van der Breggen from comment #142)
> Some advise please: suppose I would upgrade to F24 and would want audio to
> be working normally. Would that be a matter of simply upgrading and
> recompiling the kernel with option CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y and
> reboot with that kernel?

I got it working without compiling on a XPS 13 9343/0310JH, BIOS A05 07/14/2015.

After upgrading to F24 I downloaded and installed kernel 4.3.6-201 from Koji.

[http://koji.fedoraproject.org/koji/packageinfo?buildStart=200&packageID=8&buildOrder=-completion_time&tagOrder=name&tagStart=0#buildlist]

kernel-4.3.6-201.fc22.x86_64.rpm
kernel-headers-4.3.6-201.fc22.x86_64.rpm
kernel-tools-4.3.6-201.fc22.x86_64.rpm
kernel-core-4.3.6-201.fc22.x86_64.rpm
kernel-modules-4.3.6-201.fc22.x86_64.rpm
kernel-tools-libs-4.3.6-201.fc22.x86_64.rpm
kernel-devel-4.3.6-201.fc22.x86_64.rpm
kernel-modules-extra-4.3.6-201.fc22.x86_64.rpm
Comment 144 Francisco Cribari 2016-08-17 06:26:46 EDT
@Herald 

Yes.
Comment 145 Herald van der Breggen 2016-08-19 13:53:08 EDT
Indeed, that worked. Now running a 4.6.6 kernel with audio.

I downloaded and installed kernel-4.6.6-300.fc24.src.rpm and added the line

sed -ri 's/# CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set/CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y/' .config

to the spec-file, just after the line "cp configs/$Config .config"

And then, compile, install and boot 2x.

There might be more elegant ways, but anyway, this works.

@Arnaud:
After upgrading to F24, the kernel I used on F23 was still there. So there was no need to install another (old) one. It was just matter booting the F23 kernel.
Comment 146 Michael 2016-09-12 11:30:11 EDT
Tried 4.7.2-201 today, no joy. Clicks and noises, headset mic isn't detected.
Configured and compiled on copr with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y and it works as always in HDA mode.

So in the meanwhile:
https://copr.fedorainfracloud.org/coprs/gfdsa/CONFIG_ACPI_REV_OVERRIDE_POSSIBLE/

The only change is adding CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y into the generic x86_64 config and rebuilding the srpm.
Comment 147 Kai-Heng Feng 2016-09-22 01:22:21 EDT
Regarding to the headphone noise issue, can you guys give patch in [1] a try?

I'll send it to upstream if the result is positive.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=112611#c10
Comment 148 Fedora End Of Life 2016-11-24 10:52:29 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 149 Herald van der Breggen 2016-11-24 12:02:06 EST
This bug is still relevant for fedora 24 as well. Please update the bug info so that this bug is not forgotten when fedora 23 goes EOL.

So far I recompiled each and every kernel that is pushed via updates with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y. It's not fun. But it is the only way to get around this problem. I would welcome a real solution. Very much. Thank you.
Comment 150 Herald van der Breggen 2016-11-25 08:39:59 EST
For those who are tired building kernels or gave up already, you can download kernels for fc24 from https://xps13.landweg.nl. I'll try to keep it more or less up to date. But no guarantees ;-) See README file for instructions how to build them yourself.

When I upgrade to fc25, I'll build those kernels of course. Probably next month...
Comment 151 Cody 2016-11-25 11:10:00 EST
And to those who have speaker output but mic fails to work you might (can't promise this but it works for me) want to kill pulseaudio (it'll restart automatically) and then try again. I have to do this for Skype (the 32-bit version; I've not tried the 64-bit version MS has been working on since this works and I'd rather the version that works until they have the 64-bit in full working order (ehm, maybe that is 'MS working order' rather than 'working order'). This I suppose is similar to one of my earlier comments about pulseaudio except that for some time the problem went away for me (at least as far as output - at the time I didn't make use of a microphone so I wasn't aware of this issue or it didn't exist at the time).

You can restart pulseaudio like:

$ pkill pulseaudio

..for example.

Cheers.
Comment 152 Niklas Wenzel 2016-11-26 18:45:40 EST
@Herald: Thanks a lot for uploading both your kernels and the build instructions in the README file.

Having upgraded to Fedora 25 today, I can confirm that this bug affects that version as well.

Therefore, I went ahead and used the instructions to build kernel 4.8.8 with working audio. If you are facing the same issue, you can get it here: https://drive.google.com/file/d/0B19TeQHX9rTYLTZ0MTBMNW1qMlE/view?usp=sharing

Reboot twice after installing the packages and audio will be working again. :)
Comment 153 Trystram 2016-12-06 04:39:27 EST
This is still relevant on fedora 25 indeed. The audio works fine on my unit (2015 XPS 9343), but no microphone.

killing pulseaudio doesn't works. What information is needed to help ?
Comment 154 Herald van der Breggen 2016-12-06 05:07:32 EST
@Trystram: did you try a kernel compiled with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y setting? See post of Niklas Wenzel 2016-11-26 18:45:40 EST...
Comment 155 Enrico Tagliavini 2016-12-06 05:12:42 EST
(In reply to Herald van der Breggen from comment #154)
> @Trystram: did you try a kernel compiled with
> CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y setting? See post of Niklas Wenzel
> 2016-11-26 18:45:40 EST...

To be clear: this is just a workaround, an hack, not a proper fix.

@Trystram: did you tried to enable capture for ADC0 in alsamixer as shown in attachment #1177701 [details] ? For me that fixed the issue. Basically the problem is the default alsamixer settings are wrong when using the new driver approach, to my best understanding.
Comment 156 Trystram 2016-12-06 05:23:42 EST
(In reply to Enrico Tagliavini from comment #155)
> (In reply to Herald van der Breggen from comment #154)
> > @Trystram: did you try a kernel compiled with
> > CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y setting? See post of Niklas Wenzel
> > 2016-11-26 18:45:40 EST...
> 
> To be clear: this is just a workaround, an hack, not a proper fix.
But the sound card is detected as i have audio output.
> 
> @Trystram: did you tried to enable capture for ADC0 in alsamixer as shown in
> attachment #1177701 [details] ? For me that fixed the issue. Basically the
> problem is the default alsamixer settings are wrong when using the new
> driver approach, to my best understanding.

Yes i did. Exact same setup as your screenshot : still no input device displayed in the gnome settings pannel.
However, the mic seems to work in applications. Why isn'it displayed in gnome?
Comment 157 Enrico Tagliavini 2016-12-06 05:35:47 EST
(In reply to Trystram from comment #156)
> Yes i did. Exact same setup as your screenshot : still no input device
> displayed in the gnome settings pannel.
> However, the mic seems to work in applications. Why isn'it displayed in
> gnome?

I don't know about gnome sorry. However I advise to do a double check using the utility pavucontrol. I guess gnome will show you what pulseaudio sees, pavucontrol is a GUI tool from the pulseaudio project itself. In theory they should match in what they present, if not there might be an issue with one of the two (or in the way the information is displayed). Sometimes pulseaudio will not show a device with the correct type / name because alsa or the kernel is not describing it correctly.

To make is simpler than it is think like this: pulseaudio sits on top of alsa which sits on top of the kernel. Any issue can be anywhere in these three.
Comment 158 Trystram 2016-12-06 07:20:37 EST
(In reply to Enrico Tagliavini from comment #157)
> (In reply to Trystram from comment #156)
> > Yes i did. Exact same setup as your screenshot : still no input device
> > displayed in the gnome settings pannel.
> > However, the mic seems to work in applications. Why isn'it displayed in
> > gnome?
> 
> I don't know about gnome sorry. However I advise to do a double check using
> the utility pavucontrol. I guess gnome will show you what pulseaudio sees,
> pavucontrol is a GUI tool from the pulseaudio project itself. In theory they
> should match in what they present, if not there might be an issue with one
> of the two (or in the way the information is displayed). Sometimes
> pulseaudio will not show a device with the correct type / name because alsa
> or the kernel is not describing it correctly.
> 
> To make is simpler than it is think like this: pulseaudio sits on top of
> alsa which sits on top of the kernel. Any issue can be anywhere in these
> three.

Thanks for the heads-up :) The mic shows up in pavucontrol. So it must be pulseaudio that doesn't show the correct information !
Comment 159 Arnaud Kleinveld 2016-12-06 09:08:30 EST
On my laptop pavucontrol prints (unplugged) next the to microphone drop down entry.

Whatever I try in alsamixer I can get the mic to work. It has not worked for 10 months now.

The sound is working on my laptop, however I hear a loud click sound when I boot.
Comment 160 Niklas Wenzel 2016-12-16 10:31:36 EST
Fedora 23 is hitting end of life on Dezember 20th, so I created a new bug report for Fedora 25: https://bugzilla.redhat.com/show_bug.cgi?id=1405474

I'd like to ask those who have sound but no microphone input to create a second issue for their problem.

If you'd like to follow the bug, make sure to add yourself to the CC list of the new one.
Comment 161 Arnaud Kleinveld 2016-12-17 05:09:39 EST
Why not change this bug's Fedora version?

And how about the loud click at boot time, another reparate bug as well? 

From a user perspective the sound issues are a collective all introduced by the same regression at the same time. It would be more user friendly to keep all the information together.

Thanks,
Arnaud
Comment 162 Niklas Wenzel 2016-12-19 07:46:45 EST
@Arnaud:

> Why not change this bug's Fedora version?

Three weeks ago I tried contacting the kernel maintainers at kernel-maint@redhat.com in order to have them change the Fedora version but did not get any response. Furthermore, I think we can provide the relevant information in a much shorter form in the new bug report. Who will read 162 comments?

> And how about the loud click at boot time, another reparate bug as well?

I would say so. I don't get that loud click.

> From a user perspective the sound issues are a collective all introduced by the
> same regression at the same time. It would be more user friendly to keep all
> the information together.

However, I believe those issues have different causes code-wise. And as we want devs to fix our issues, I think we should supply the info to them in the form they can most easily process.
Comment 163 Fedora End Of Life 2016-12-20 14:09:56 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 164 Niklas Wenzel 2016-12-21 14:55:41 EST
@Arnaud: Part of my last comment might have been wrong. See https://bugzilla.redhat.com/show_bug.cgi?id=1405474.
Comment 165 Arnaud Kleinveld 2017-01-21 03:18:50 EST
(In reply to Niklas Wenzel from comment #162)
> @Arnaud:
> 
> > Why not change this bug's Fedora version?
> 
> Three weeks ago I tried contacting the kernel maintainers at
> kernel-maint@redhat.com in order to have them change the Fedora version but
> did not get any response. Furthermore, I think we can provide the relevant
> information in a much shorter form in the new bug report. Who will read 162
> comments?
> 

This would be against industry support best practices. I strongly suggest Francisco Cribari to reopen this report and change it to Fedora version 25. We don't need to contact kernel maintainers for that as far as I know.

> > And how about the loud click at boot time, another reparate bug as well?
> 
> I would say so. I don't get that loud click.
> 
> > From a user perspective the sound issues are a collective all introduced by the
> > same regression at the same time. It would be more user friendly to keep all
> > the information together.
> 
> However, I believe those issues have different causes code-wise. And as we
> want devs to fix our issues, I think we should supply the info to them in
> the form they can most easily process.

We can not make assumptions on where the bugs are originating code-wise. As users we should only do our best with reporting the bug as requested by the bug report template. It's up to the developers to decide if bug report should be broken into multiple reports.

What is clear to me that the developers are pushing users to minimize the number duplicate reports, specifically those that have similar titles. Hence the title search when a new bug report is created.
Comment 166 Matthew Garrett 2017-07-04 01:55:01 EDT
Reopening since it's still an issue.

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