Re: [alsa-devel] CPU hook snd_hda_intel

From: Klaus Ethgen <Klaus@ethgen.ch>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] CPU hook snd_hda_intel
Date: Tue, 10 Dec 2019 16:28:44 +0100	[thread overview]
Message-ID: <20191210152844.GC23758@ikki.ethgen.ch> (raw)
In-Reply-To: <s5hfthsw6mo.wl-tiwai@suse.de>

[-- Attachment #1.1: Type: text/plain, Size: 2894 bytes --]

Hi Takashi,

Am Di den 10. Dez 2019 um 16:19 schrieb Takashi Iwai:
> >    Dec 10 15:33:55 chua kernel: [15488.497441] snd_hdac_bus_update_rirb: 58 callbacks suppressed
> >    Dec 10 15:33:55 chua kernel: [15488.497449] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497453] snd_hda_intel 0000:00:1b.0: spurious response 0x7fffffff:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497457] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497461] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497464] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497468] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497471] snd_hda_intel 0000:00:1b.0: spurious response 0x7fffffff:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497475] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497478] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> >    Dec 10 15:33:55 chua kernel: [15488.497481] snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x11f0900
> 
> OK, these lines look already suspicious.

These are logged after wakeup as at this position, most of the system
seems already been sleeping. But it is really just before the sleep.

> The driver gets stuck at executing the same verb and repeated it until
> it gets some result.  This verb is GET_PIN_SENSE to the pin 0x11, as I
> somehow expected.
> However, the pin 0x11 is the headphone pin, and this should work even
> after the undock, but by some reason, it screws up.  Or it might be
> the read of the previous one (that doesn't appear here) that stalls
> the communication.
[...]
> Then it might be a problem of the headphone jack detection in
> general.  It happens at undock because the jack detection is performed
> on all pins.

I think, I always seen the headphone pin note there. Is it possible to
disable that detection? Maybe that is not working with that old
hardware?

> > Anything you think can be done against that?
> 
> Could you try the patch below in addition to the previous one?
> The similar trick was applied to the recent Intel chips for the
> unreliable communications, and the same might work for older chips,
> too.

I'll do and by the same compilation, I'll enable
CONFIG_SND_HDA_CODEC_ANALOG.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 688 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel