Bug 112731

Created attachment 204071 [details]
Output of alsa-info.sh

Created attachment 204081 [details]
dmesg output

Created attachment 204091 [details]
Kernel config

Created attachment 204101 [details]
lspci output

You shouldn't build HD-audio driver as built-in while i915 graphics as module.  There is a weak dependency on i915 for HDMI/DP, and this may break things.
Try to build all sound driver as modules, too.

(In reply to Takashi Iwai from comment #5)
> You shouldn't build HD-audio driver as built-in while i915 graphics as
> module.  There is a weak dependency on i915 for HDMI/DP, and this may break
> things.
> Try to build all sound driver as modules, too.

Ugh. I used to have i915 builtin on my old laptop, but due to skylake requiring firmware I had to build it as module.

Anyways, building snd_hda_codec and friends as modules got me at least HDMI audio. I get the sound on my tv through HDMI. But still no sound through speakers.

Attached is the latest dmesg output.

Thanks for the quick response.

Created attachment 204111 [details]
Last dmesg output

A few more things to check:

- Whether any options relevant with audio in BIOS menu, e.g. DSP enablement;
  try to turn on/off if there is any

- Boot not after Windows; do a cold boot -- or vice/versa, try after Windows

- Pass acpi_osi="!Windows 2012" boot option

- Try to pass probe_mask=0x105 to snd-hda-intel module;
  this will force to probe the codecs #0 and #2 (see Documentation/sound/alsa/HD-Audio.txt)

(In reply to Takashi Iwai from comment #8)
> A few more things to check:
> 
> - Whether any options relevant with audio in BIOS menu, e.g. DSP enablement;
>   try to turn on/off if there is any
> 

Only settings related to sound card in BIOS are to either disable everything related to sound, or disable some/all components related to sound - internal speakers, mic or headphone jack. All of them are enabled.

There is however an issue (not sure with what, but Linux does cause it), where something leaves the hw in such state that it becomes invisible to all OS' after next boot, be it windows or linux. See #112711

> - Boot not after Windows; do a cold boot -- or vice/versa, try after Windows
> 

I'm not sure I really parsed this correct. Linux entry is first one in EFI boot order, so after power on or reboot from any os, it will get booted first. I tried completely turning off the laptop then turning it on, or booting windows and rebooting to linux. Nothing changed.

> - Pass acpi_osi="!Windows 2012" boot option
> 

Did that, dmesg changed a little, but still no sound. See attachment.

> - Try to pass probe_mask=0x105 to snd-hda-intel module;
>   this will force to probe the codecs #0 and #2 (see
> Documentation/sound/alsa/HD-Audio.txt)

Same as above.

Created attachment 204131 [details]
dmesg after passing acpi_osi="!Windows 2012"

Created attachment 204141 [details]
dmesg after passing probe_mask=0x105 to snd_hda_intel

Good news.

While looking for similar problems online, I stumbled upon the following:

https://askubuntu.com/questions/700167/no-sound-on-ubuntu-15-10

After using snd_hda_intel.probe_mask=1 snd_hda_intel.single_cmd=1 I could get the internal sound card to work.

But, that lost me HDMI output. It's like there's some kind of conflict between them.

Latest dmesg output is attached.

Created attachment 204151 [details]
latest dmesg output

Great news!

(In reply to Armin K. from comment #12)
> 
> But, that lost me HDMI output. It's like there's some kind of conflict
> between them.
> 

After removing snd_hda_intel.probe_mask=1 I got both Internal card and HDMI to work!

The solution is: Pass single_cmd=1 to snd-hda-intel driver.

Is there a way this can be worked around in the driver?

Hopefully final dmesg output is attached.

Created attachment 204161 [details]
Final dmesg output

(In reply to Armin K. from comment #14)
> Great news!
> 
> (In reply to Armin K. from comment #12)
> > 
> > But, that lost me HDMI output. It's like there's some kind of conflict
> > between them.
> > 
> 
> After removing snd_hda_intel.probe_mask=1 I got both Internal card and HDMI
> to work!

Something must be wrong there.  You need to pass probe_mask=0x105 or so.  Otherwise it means to ignore except for the codec address 0.
The bit 0x100 is to force the codec slots, while bits 0-7 indicate the slots to probe.
 
> The solution is: Pass single_cmd=1 to snd-hda-intel driver.

Sorry, this is definitely wrong.  single_cmd=1 means the emergency mode only for debugging.  See HD-Audio.txt.

> Is there a way this can be worked around in the driver?

Try again a cold boot only with probe_mask=0x105 option.  If it still doesn't work, give alsa-info.sh output and kernel messages again.

(In reply to Armin K. from comment #9)
> > - Boot not after Windows; do a cold boot -- or vice/versa, try after
> Windows
> > 
> 
> I'm not sure I really parsed this correct. Linux entry is first one in EFI
> boot order, so after power on or reboot from any os, it will get booted
> first. I tried completely turning off the laptop then turning it on, or
> booting windows and rebooting to linux. Nothing changed.

The thing is that this is a BIOS firmware bug.  We may try some workaround, but there is something wrong in BIOS.

The reason I asked this is that often Windows forcibly enables/disables some component power at boot and shutdown, and other OS suffers from it.  But, your case doesn't look like that.

... that said, it would be useful to check whether you get any BIOS updates.  This kind of problem gets fixed often just by the BIOS updates.

(In reply to Takashi Iwai from comment #16)
> (In reply to Armin K. from comment #14)
> > Great news!
> > 
> > (In reply to Armin K. from comment #12)
> > > 
> > > But, that lost me HDMI output. It's like there's some kind of conflict
> > > between them.
> > > 
> > 
> > After removing snd_hda_intel.probe_mask=1 I got both Internal card and HDMI
> > to work!
> 
> Something must be wrong there.  You need to pass probe_mask=0x105 or so. 
> Otherwise it means to ignore except for the codec address 0.
> The bit 0x100 is to force the codec slots, while bits 0-7 indicate the slots
> to probe.
>  
> > The solution is: Pass single_cmd=1 to snd-hda-intel driver.
> 
> Sorry, this is definitely wrong.  single_cmd=1 means the emergency mode only
> for debugging.  See HD-Audio.txt.
> 

O well, it's the only thing that makes it work.

> > Is there a way this can be worked around in the driver?
> 
> Try again a cold boot only with probe_mask=0x105 option.  If it still
> doesn't work, give alsa-info.sh output and kernel messages again.

See comment 11 for dmesg output when using probe_mask. I'll try again with cold boot, but doubt it will make any difference.

(In reply to Takashi Iwai from comment #17)
> (In reply to Armin K. from comment #9)
> > > - Boot not after Windows; do a cold boot -- or vice/versa, try after
> Windows
> > > 
> > 
> > I'm not sure I really parsed this correct. Linux entry is first one in EFI
> > boot order, so after power on or reboot from any os, it will get booted
> > first. I tried completely turning off the laptop then turning it on, or
> > booting windows and rebooting to linux. Nothing changed.
> 
> The thing is that this is a BIOS firmware bug.  We may try some workaround,
> but there is something wrong in BIOS.
> 
> The reason I asked this is that often Windows forcibly enables/disables some
> component power at boot and shutdown, and other OS suffers from it.  But,
> your case doesn't look like that.

I've experienced similar thing with Linux. It somehow forcibly disabled the card, making it not appear in either windows or linux. Removing all the power sources and holding the power button for ~10 secs fixed that though. HP explicitly states it doesn't support Linux as far as I'm aware.

(In reply to Takashi Iwai from comment #18)
> ... that said, it would be useful to check whether you get any BIOS updates.
> This kind of problem gets fixed often just by the BIOS updates.

I've updated the BIOS 2 days ago. It was 2 versions behind the original. That was before I even tried Linux.

Created attachment 204171 [details]
Latest alsa-info.sh output

Created attachment 204181 [details]
Latest dmesg output

Try to pass snoop=0 option to snd-hda-intel in addition to probe_mask.

Created attachment 204191 [details]
Latest dmesg output

Sadly, no changes yet.

Then no more clue for now.  It's something wrong with BIOS firmware, as this happens only with this machine.

You can use single_cmd=1 but this means it loses many functionality like the jack detection.  If single_cmd works, it implies that the communication with CORB/RIRB is broken.  Since the HDMI/DP codec seems working as is, the controller side should be OK.  So the issue is either the codec or an issue specific to the model.

In anyway, please give alsa-info.sh output with single_cmd=1 so that it contains the information of the builtin audio codec.

Created attachment 204221 [details]
Output of alsa-info.sh

Here you go. Thanks for taking your time and trying to find out what's wrong.

Created attachment 204231 [details]
Full dmesg that goes with the last alsa-info.sh

(In reply to Takashi Iwai from comment #26)
> Then no more clue for now.  It's something wrong with BIOS firmware, as this
> happens only with this machine.
> 
> You can use single_cmd=1 but this means it loses many functionality like the
> jack detection.

Jack detection seems to be working. It's possible that pulseaudio handles that.

I got another HP machine with Skylake, and I saw a similar problem.  Although it doesn't happen at the fresh boot, a similar missing-codec problem appears when reloading the module.

After contacting with Intel, the patch below was cooked, and this seems working on my test machine.  Could you give it a try?

Created attachment 204291 [details]
Test patch for Skylake

(In reply to Takashi Iwai from comment #30)
> I got another HP machine with Skylake, and I saw a similar problem. 
> Although it doesn't happen at the fresh boot, a similar missing-codec
> problem appears when reloading the module.
> 
> After contacting with Intel, the patch below was cooked, and this seems
> working on my test machine.  Could you give it a try?

Thank you for still working on this.

I can confirm the patch kinda works and the codec now loads without setting any options for snd_hda_intel module.

However, looking at alsa-info.sh output, it appears like the codec is initialized in fallback mode and all options have been set the way single_cmd would've set them.

The relevant part from the alsa-info.sh output:

!!Module: snd_hda_intel
        align_buffer_size : -1
        bdl_pos_adj : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
        beep_mode : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
        enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
        enable_msi : -1
        id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
        index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
        jackpoll_ms : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
        model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
        patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
        position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
        power_save : 0
        power_save_controller : Y
        probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
        probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
        single_cmd : N
        snoop : -1

Which is similar to the output from the same script (Comment 27) when single_cmd=1 was used (except for the single_cmd part in this one).

Could you give the full output of alsa-info.sh and kernel messages?

Created attachment 204331 [details]
Output from alsa-info.sh

Created attachment 204341 [details]
Output from dmesg

I see no fallback things, all messages look normal.  Did you experience any operation failure?

Everything works (sound, jack detection, multimedia keys).

However, those values seem like fallback ones. Even msi and snooping seem to be disabled. Is that bad?

No, it's normal: -1 means to take the system default, i.e. both enabled :)

Alright, this is it then. Thanks again for looking into it.

The patch is going to be merged to upstream soon later, likely in 4.5-rc6.