Bug 208609 - Regression: snd_hda_intel causes screen freeze on nvidia GPU if nouveau is blacklisted
Summary: Regression: snd_hda_intel causes screen freeze on nvidia GPU if nouveau is bl...
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-19 12:35 UTC by Nathan Bryant
Modified: 2020-07-28 08:37 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.5
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Test fix patch (818 bytes, patch)
2020-07-24 15:46 UTC, Takashi Iwai
Details | Diff

Description Nathan Bryant 2020-07-19 12:35:01 UTC
If nouveau is blacklisted in /etc/modprobe.d and the proprietary Nvidia driver is not installed either, the efifb driver should be used as a fallback. This works fine on the 5.4-series stable kernels >= 5.4.1.

However, on all the >=5.5 kernels I've tested through 5.7.9 and 5.8-rc*, using my Geforce GTX 1070 with nouveau blacklisted, the screen freezes when userland attempts to initialize ALSA. This occurs shortly after the gdm login screen renders or partially renders, and the result is a frozen mouse pointer and no way to login to gdm nor switch to a text VT. About the only thing that seems to work is Ctrl-Alt-Del for a clean(?) reboot. (I haven't tried SSHing in remotely.)

The reason why 5.4 stable series works, is the following commit which was introduced in 5.4.1, but it looks like this was never applied to mainline because nouveau added audio support.

b730b2ceb2cfd953031242cd562f0b17cd6d6e07 is the first [good] commit
commit b730b2ceb2cfd953031242cd562f0b17cd6d6e07
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 22 14:20:00 2019 +0100

    ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs
    
    commit 5a858e79c911330678b5a9be91a24830e94a0dc9 upstream.
    
    The old Nvidia chips have multiple HD-audio codecs on the same
    HD-audio controller, and this doesn't work as expected with the current
    audio component binding that is implemented under the one-codec-per-
    controller assumption; at the probe time, the driver leads to several
    kernel WARNING messages.
    
    For the proper support, we may change the pin2port and port2pin to
    traverse the codec list per the given pin number, but this needs more
    development and testing.
    
    As a quick workaround, instead, this patch drops the binding in the
    audio side for these legacy chips since the audio component support in
    nouveau graphics driver is still not merged (hence it's basically
    unused).
    
    [ Unlike the original commit, this patch actually disables the audio
      component binding for all Nvidia chips, not only for legacy chips.
      It doesn't matter much, though: nouveau gfx driver still doesn't
      provide the audio component binding on 5.4.y, so it's only a
      placeholder for now.  Also, another difference from the original
      commit is that this removes the nvhdmi_audio_ops and other
      definitions completely in order to avoid a compile warning due to
      unused stuff.  -- tiwai ]
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205625
    Fixes: ade49db337a9 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
    Link: https://lore.kernel.org/r/20191122132000.4460-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 sound/pci/hda/patch_hdmi.c | 22 ----------------------
 1 file changed, 22 deletions(-)
Comment 1 Nathan Bryant 2020-07-19 12:36:28 UTC
Surprisingly, also blacklisting snd_hda_intel makes the situation worse, not better.
Comment 2 Nathan Bryant 2020-07-20 22:09:13 UTC
A workaround exists. 

When configuring the blacklist, put the following content in the config file (for example, /etc/modprobe.d/blacklist-nouveau.conf)

blacklist nouveau
options snd_hda_codec_hdmi enable_acomp=N
Comment 3 Takashi Iwai 2020-07-24 15:45:55 UTC
OK, then does the patch below fix the problem?
Comment 4 Takashi Iwai 2020-07-24 15:46:18 UTC
Created attachment 290539 [details]
Test fix patch
Comment 5 Nathan Bryant 2020-07-27 23:26:51 UTC
Hi Takashi,

Thanks, yes, the patch seems to fix the problem. Tested several configurations and state transitions when applying the patch to 5.7.10 vanilla stable and 5.8-rc7+drm-tip. Looks good.
Comment 6 Takashi Iwai 2020-07-28 08:37:53 UTC
OK, thanks.  I'm going to submit the proper patch and merge into sound git tree.
Not sure whether it'll be pushed to 5.8-final, but should be included in 5.9-rc1.

Note You need to log in before you can comment on or make changes to this bug.