On Tue, 10 Dec 2019 16:10:37 +0100,
Klaus Ethgen wrote:
>
> Hi Takashi,
>
> Am Di den 10. Dez 2019 um 15:43 schrieb Takashi Iwai:
> > > There is also a issue with a swapper thread in ath9k code but the one
> > > with the biggest CPU hook is still alsa.
> >
> > Do you see the relevant kernel messages, e.g. switch to polling mode?
>
> Nope.
>
> Here is the relevant logs starting from undocking event up to the sleep
> that I mentioned fixing the issue:
....
> 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.
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.
> > > Let me add that this time I encountered the issue after taking the
> > > laptop from the docking station.
> >
> > ... this can be the cause: the hardware doesn't react to the pin jack
> > sense request for the dock that isn't present any longer.
> > Or something goes wrong here, repeating, etc.
>
> I think, it might have to do with that as I often use the dock.
>
> However, I think, I even seen the problem after I did a fresh boot far
> away from the dock.
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.
But, the same is true for the suspend/resume, even for runtime PM, so
this might hit even more often. Hmm.
> > > After sending it to sleep and waking it up again, the problem is gone
> > > (as it often can be solved).
> >
> > So the problem is very likely some flaky hardware response.
>
> 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.
thanks,
Takashi
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -282,7 +282,7 @@ enum {
/* quirks for old Intel chipsets */
#define AZX_DCAPS_INTEL_ICH \
- (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE)
+ (AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE)
/* quirks for Intel PCH */
#define AZX_DCAPS_INTEL_PCH_BASE \
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
