linux-kernel - Re: Unrecoverable AER error when resuming from RAM (hda regression in 5.7-rc2)

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 21 Apr 2020 21:40:30 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
Cc:     alsa-devel@...a-project.org, Roy Spliet <nouveau@...iet.org>,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: Unrecoverable AER error when resuming from RAM (hda regression in 5.7-rc2)

On Tue, 21 Apr 2020 21:08:44 +0200,
Alex Xu (Hello71) wrote:
> 
> With 5.7-rc2, after resuming from suspend to RAM, I get:
> 
> [   55.679382] pcieport 0000:00:03.1: AER: Multiple Uncorrected (Non-Fatal) error received: 0000:00:00.0
> [   55.679405] pcieport 0000:00:03.1: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
> [   55.679410] pcieport 0000:00:03.1: AER:   device [1022:1453] error status/mask=00100000/04400000
> [   55.679414] pcieport 0000:00:03.1: AER:    [20] UnsupReq               (First)
> [   55.679417] pcieport 0000:00:03.1: AER:   TLP Header: 40000004 0a0000ff fffc0e80 00000000
> [   55.679423] amdgpu 0000:0a:00.0: AER: can't recover (no error_detected callback)
> [   55.679425] snd_hda_intel 0000:0a:00.1: AER: can't recover (no error_detected callback)
> [   55.679455] pcieport 0000:00:03.1: AER: device recovery failed
> 
> Then the display freezes and the system basically falls apart (can't 
> even sudo reboot -f, need to use magic sysrq).
> 
> I bisected this to "ALSA: hda: Skip controller resume if not needed". 
> Setting snd_hda_intel.power_save=0 resolves the issue.

Hrm, it means the condition to skip the controller resume doesn't fit
well.  Does the patch below help?

But looking at the dmesg output:
> [    1.021452] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x7, too many assigned pins
> [    1.021461] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x9, too many assigned pins
> [    1.021471] snd_hda_codec_generic hdaudioC0D0: ignore pin 0xb, too many assigned pins
> [    1.021480] snd_hda_codec_generic hdaudioC0D0: ignore pin 0xd, too many assigned pins
> [    1.021482] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line
> [    1.021482] snd_hda_codec_generic hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> [    1.021483] snd_hda_codec_generic hdaudioC0D0:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
> [    1.021484] snd_hda_codec_generic hdaudioC0D0:    mono: mono_out=0x0
> [    1.021484] snd_hda_codec_generic hdaudioC0D0:    dig-out=0x3/0x5
> [    1.021485] snd_hda_codec_generic hdaudioC0D0:    inputs:

... it looks like snd-hda-codec-generic is used for HDMI/DP codec.
This can't work well.  Did you enable CONFIG_SND_HDA_HDMI?

In anyway, please give alsa-info.sh output.  Run the script with
--no-upload option and attach the output.


thanks,

Takashi

---
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1060,7 +1060,7 @@ static int azx_resume(struct device *dev)
 
 	/* check for the forced resume */
 	list_for_each_codec(codec, &chip->bus) {
-		if (hda_codec_need_resume(codec)) {
+		if (!codec->relaxed_resume) {
 			forced_resume = true;
 			break;
 		}