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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <s5h368uy94d.wl-tiwai@suse.de>
Date:   Thu, 23 Apr 2020 09:05:54 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>,
        alsa-devel@...a-project.org, Roy Spliet <nouveau@...iet.org>,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pm@...r.kernel.org
Subject: Re: Unrecoverable AER error when resuming from RAM (hda regression in 5.7-rc2)

On Thu, 23 Apr 2020 01:21:27 +0200,
Bjorn Helgaas wrote:
> 
> On Wed, Apr 22, 2020 at 11:25:04PM +0200, Takashi Iwai wrote:
> > On Wed, 22 Apr 2020 22:50:28 +0200,
> > Bjorn Helgaas wrote:
> > > ...
> > > I feel like this UR issue could be a PCI core issue or maybe some sort
> > > of misuse of PCI power management, but I can't seem to get traction on
> > > it.
> > > 
> > > > 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.
> > > 
> > > FWIW, the complete citation is c4c8dd6ef807 ("ALSA: hda: Skip
> > > controller resume if not needed"),
> > > https://git.kernel.org/linus/c4c8dd6ef807, which first appeared in
> > > v5.7-rc2.
> > 
> > Yes, and I posted the fix patch right now:
> >   https://lore.kernel.org/r/20200422203744.26299-1-tiwai@suse.de
> > 
> > The possible cause was the tricky resume code that both HD-audio
> > controller (the parent PCI device) and the codec devices used.
> > 
> > At least the patch above seems working for the reporter's machine.
> > Now we need a bit more testing before merging, but it looks promising,
> > so far.
> 
> Great, I'm glad you figured something out because I sure wasn't
> getting anywhere!
> 
> Maybe this is a tangent, but I can't figure out what
> snd_power_change_state() is doing.  It *looks* like it's supposed to
> change the PCI power state, but I gave up trying to figure out where
> it actually touches the device.

Not really, it merely updates the internal state field stored in the
sound card object, see in include/sound/core.h:

static inline void snd_power_change_state(struct snd_card *card, unsigned int state)
{
	card->power_state = state;
	wake_up(&card->power_sleep);
}

The sound API blocks the operation while suspend/resume explicitly
with this card top-level signal.


thanks,

Takashi