lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hva71s4wz.wl-tiwai@suse.de>
Date:   Wed, 19 Sep 2018 20:44:44 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Paul Menzel <pmenzel+alsa-devel@...gen.mpg.de>
Cc:     alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: snd_hda_codec_hdmi: `hdaudio hdaudioC0D2: Unable to bind the codec`

On Wed, 19 Sep 2018 13:14:43 +0200,
Paul Menzel wrote:
> 
> Dear Takashi,
> 
> On 09/18/18 23:00, Takashi Iwai wrote:
> > On Tue, 18 Sep 2018 17:55:15 +0200, Paul Menzel wrote:
> 
> >> With drm-tip (v4.19-rc3-946-g09b295662edd) Linux prints
> >> `snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec`
> >> to the log.
> >>
> >> ```
> >> […]
> >> [   12.481788] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC671: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:line
> >> [   12.482536] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=1 (0x17/0x0/0x0/0x0/0x0)
> >> [   12.483184] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
> >> [   12.483737] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
> >> [   12.484198] snd_hda_codec_realtek hdaudioC0D0:    inputs:
> >> [   12.484582] snd_hda_codec_realtek hdaudioC0D0:      Front Mic=0x19
> >> [   12.485100] snd_hda_codec_realtek hdaudioC0D0:      Rear Mic=0x18
> >> [   12.485519] snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
> >> [   12.497685] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec
> >> [   12.498311] hdaudio hdaudioC0D2: Unable to bind the codec
> >> [   12.498789] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
> >> [   12.499567] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7
> >> [   12.500268] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8
> >> [   12.501039] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9
> >> [   12.501683] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10
> >> [   17.743338] [drm:intel_pch_type [i915]] Found SunrisePoint PCH
> >> […]
> >> ```
> >>
> >> Is that an error or just a notice?
> > 
> > This must be a side-effect of the recent change in i915 to be async
> > probe.  This made me checking the corresponding ALSA audio binding
> > code change, and actually found a bug.
> > 
> > Could you try the fix below?
> 
> Thank you for your quick reply. Of course, and can try it.
> 
> > -- 8< --
> > From: Takashi Iwai <tiwai@...e.de>
> > Subject: [PATCH] ALSA: hda: Fix the audio-component completion timeout
> > 
> > The timeout of audio component binding was incorrectly specified in
> > msec, not in jiffies, which results in way too shorter timeout than
> > expected.
> > 
> > Along with fixing it, add the information print about the binding
> > failure to show the unexpected situation more clearly.
> > 
> > Fixes: a57942bfdd61 ("ALSA: hda: Make audio component support more generic")
> > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> > ---
> >  sound/hda/hdac_i915.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> > index b5282cbbe489..617ff1aa818f 100644
> > --- a/sound/hda/hdac_i915.c
> > +++ b/sound/hda/hdac_i915.c
> > @@ -145,9 +145,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
> >  	if (!acomp->ops) {
> >  		request_module("i915");
> >  		/* 10s timeout */
> > -		wait_for_completion_timeout(&bind_complete, 10 * 1000);
> > +		wait_for_completion_timeout(&bind_complete,
> > +					    msecs_to_jiffies(10 * 1000));
> >  	}
> >  	if (!acomp->ops) {
> > +		dev_info(bus->dev, "couldn't bind with audio component\n");
> >  		snd_hdac_acomp_exit(bus);
> >  		return -ENODEV;
> >  	}
> 
> Unfortunately, it doesn’t seem to help.
> 
> ```
> [   12.471105] snd_hda_intel 0000:00:1f.3: couldn't bind with audio component

So it has waited for 10 seconds and timed out.  You can check the
calls via init_debug option or such to verify it.

> [   12.483298] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC671: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:line
> [   12.484068] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=1 (0x17/0x0/0x0/0x0/0x0)
> [   12.484643] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
> [   12.485268] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
> [   12.485700] snd_hda_codec_realtek hdaudioC0D0:    inputs:
> [   12.486135] snd_hda_codec_realtek hdaudioC0D0:      Front Mic=0x19
> [   12.486558] snd_hda_codec_realtek hdaudioC0D0:      Rear Mic=0x18
> [   12.487051] snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
> [   12.498994] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec
> [   12.499707] hdaudio hdaudioC0D2: Unable to bind the codec
> [   12.500294] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
> [   12.501194] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7
> [   12.502084] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8
> [   12.502800] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9
> [   12.503525] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10
> [   17.734286] [drm:intel_pch_type [i915]] Found SunrisePoint PCH
> [   17.734300] [drm:i915_driver_load [i915]] WOPCM size: 1024KiB

Why the i915 driver gets initialized *so late*?


BTW, could you strip the mail to more lightweight?  We don't need so
much things, just the relevant kernel messages should suffice.


thanks,

Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ