Bug 1180543

Maybe worth a try: https://www.linuxquestions.org/questions/slackware-14/kernel-5-10-4-i915-and-dual-screen-freeze-on-intel-gpu-4175687776/page5.html#post6203909

If that helps, it's a known regression in HD-audio Intel HDMI stuff.  The fix has been destined to Linus tree in today.  I'll backport the fix to stable branch.

FWIW, the simplest check is to boot with the following boot option:
  snd_hda_codec_hdmi.enable_silent_stream=0

(In reply to Frank Krüger from comment #1)
> Maybe worth a try:
> https://www.linuxquestions.org/questions/slackware-14/kernel-5-10-4-i915-and-
> dual-screen-freeze-on-intel-gpu-4175687776/page5.html#post6203909

Today after lunch my screen had gone black and there was no other way to revive my system but to do a hard reset.

My system:

Operating System: openSUSE Tumbleweed 20210103
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2
Kernel Version: 5.10.4-1-default
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 30.8 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600

I generated the .conf-file (as proposed in the link above) and restarted my system.

This afternoon after my tea-break my screen had gone black again but this time i could just type my password to get access to my system.

Hope this helps.

(In reply to Bit Juggler from comment #4)
> Hope this helps.

It would actually have helped if you had tried what is suggested in comment #3.

(In reply to Jiri Slaby from comment #5)
> (In reply to Bit Juggler from comment #4)
> > Hope this helps.
> 
> It would actually have helped if you had tried what is suggested in comment
> #3.

Had the same problem today with my DELL XPS.
Using snd_hda_codec_hdmi.enable_silent_stream=0 worked around the problem, and I got back my graphics environment.

Thx!

Bye.
Michael.

I'm hit by the same issue on my HP EliteBook 820G1: on boot, I am greeted by a 'gray splash' (background of gdm, but no actual gdm login screen

(In reply to Takashi Iwai from comment #3)
> FWIW, the simplest check is to boot with the following boot option:
>   snd_hda_codec_hdmi.enable_silent_stream=0

This workaround was successful - my machine booted 5.10.4 up to GDM, currently in a standard GNOME/Wayland session again

FYI: Kernel:stable contains the above-mentioned patch of T. Iwai. Thank you for the speedy fix!

*** Bug 1180609 has been marked as a duplicate of this bug. ***

(In reply to Takashi Iwai from comment #3)
> FWIW, the simplest check is to boot with the following boot option:
>   snd_hda_codec_hdmi.enable_silent_stream=0

As others already reported, I can confirm that adding this parameter fixes the problem for me, too. I'll next try the current version 5.10.4-4.1.g086fc4c without the parameter and report back. Anyway, thanks a lot for your explanation and the quick fix, Takashi!

Final update for me: kernel-default-5.10.4-4.1.g086fc4c works without the additional boot parameter on all four systems. Thanks again to Takashi for the fix!

There is SR#860601 to factory:update only with that fix.

There is SR#860967 to factory with a full update to 5.10.5.

Feel free to act on them as you think.

(In reply to Jiri Slaby from comment #12)
> There is SR#860601 to factory:update only with that fix.

Thanks, generally seen, I like that approach. the big pain will be the KMP modules all around, as the check-in counter will differ. I will have to collect all packages with KMPs to make this work
 
> There is SR#860967 to factory with a full update to 5.10.5.

That one definitively goes to Staging (picked D)

*** Bug 1180677 has been marked as a duplicate of this bug. ***

*** Bug 1180563 has been marked as a duplicate of this bug. ***

*** Bug 1180691 has been marked as a duplicate of this bug. ***

*** Bug 1180710 has been marked as a duplicate of this bug. ***

Let's close.

Same error here: screen frozen, net frozen, usb, mice & keyboards frozen.

Tried: 
sudo vi /etc/modprobe.d/snd_hda.conf
options snd_hda_codec_hdmi.enable_silent_stream=N

but it doesn't fix 

(Kernel 5.10.4)
Intel i5-7600T

(In reply to filippos Filippos from comment #21)
> Tried: 
> sudo vi /etc/modprobe.d/snd_hda.conf
> options snd_hda_codec_hdmi.enable_silent_stream=N
> 
> but it doesn't fix 

Obviously.

(In reply to filippos Filippos from comment #21)
> Same error here: screen frozen, net frozen, usb, mice & keyboards frozen.
> 
> Tried: 
> sudo vi /etc/modprobe.d/snd_hda.conf
> options snd_hda_codec_hdmi.enable_silent_stream=N
> 
> but it doesn't fix 
> 

@Filippos You need to add it to GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and update grub (grub2-mkconfig -o /boot/grub2/grub.cfg).

(In reply to Jiri Slaby from comment #22)
> (In reply to filippos Filippos from comment #21)
> > Tried: 
> > sudo vi /etc/modprobe.d/snd_hda.conf
> > options snd_hda_codec_hdmi.enable_silent_stream=N
> > 
> > but it doesn't fix 
> 
> Obviously.

What a witty remark!

However it would have been of much more help to explain why there is supposed to be a difference between supplying an option to a module via kernel command line or supplying it via a file in /etc/modprobe.d

Please don't play pingpong.

There are two ways to pass the module options.  One is to pass via boot option, and in this case, the format is
   MODULENAME.OPTION=VALUE

So you'd need to pass
  snd_hda_codec_hdmi.enable_silent_stream=0
there.

OTOH, alternative is to pass via a module config file in /etc/modprobe.d/*.conf file, and in this case, the format is
   options MODULENAME OPTION=VALUE

So you'd need to create a file /etc/modprobe.d/hda.conf containing
   options snd_hda_codec_hdmi enable_silent_stream=0
instead.

In anyway, the fix appears in 5.10.5 kernel package.  Please test with it, then you need no workaround any longer.  Reopen the entry only if the issue is still seen with the new package.  Thanks.

(In reply to Bit Juggler from comment #24)
> However it would have been of much more help to explain why there is
> supposed to be a difference between supplying an option to a module via
> kernel command line or supplying it via a file in /etc/modprobe.d

There is none if done right, of course. But noone here suggested this. If someone wants to do it differently, they are free to, but don't complain when it doesn't work. The workaround suggested here apparently works for others. The kernel was fixed too, so why would one to reopen this already fixed bug in the first place? That is, if someone still has an issue (where the _suggested_ workaround doesn't work), open a new bug. 

P.S. The problem is elsewhere: the parameter is wrong (look at it, it's _obvious_, so the comment was aimed that way).

(In reply to Takashi Iwai from comment #25)
> Please don't play pingpong.
> 
Thank you very much for your elaborate and helpful statement!

Sorry! I do not want to cause any disturbance.

Now and then i roam the forums and occasionally get asked to file a bug report. Replies like comment #5 or #22 are of no avail and really discouraging and have stopped me from doing so a long time ago.

If openSUSE developers want to use bugzilla to improve their software then that sort of replies does not look very promising to me.

(In reply to Bit Juggler from comment #27)
> Now and then i roam the forums and occasionally get asked to file a bug
> report. Replies like comment #5 or #22 are of no avail and really
> discouraging and have stopped me from doing so a long time ago.
> 
> If openSUSE developers want to use bugzilla to improve their software then
> that sort of replies does not look very promising to me.

On the other hand, only adding me-too comments (like your comment #4), without actually trying what was already suggested (comment #3) only makes our lives harder.

Not speaking about trying what was _not_ suggested and is obviously different from what was suggested.

(In reply to Jiri Slaby from comment #28)
> (In reply to Bit Juggler from comment #27)
> > Now and then i roam the forums and occasionally get asked to file a bug
> > report. Replies like comment #5 or #22 are of no avail and really
> > discouraging and have stopped me from doing so a long time ago.
> > 
> > If openSUSE developers want to use bugzilla to improve their software then
> > that sort of replies does not look very promising to me.
> 
> On the other hand, only adding me-too comments (like your comment #4),
> without actually trying what was already suggested (comment #3) only makes
> our lives harder.

I will elaborate as I didn't mean to offend anybody. It's nice people report bugs. Look at this one, the reporter reported this one and had a workaround in 2 hours. In the next days, Takashi submitted the fix and I submitted the kernel with the fix 3 days after the initial report!

BUT: it would be nice if people also did a quick search for existing reports and read them before they create/append their me-too story. The same holds for opensuse lists (look how many reports of this very issue occurred there).

These should be basic principles when reporting bugs. Search first, try the suggested fixes and only if it is not found or still doesn't work, append info about a new use case. The KDE bug reporter has a nice interface which does most of this...

(In reply to Jiri Slaby from comment #29)
> 
> BUT: it would be nice if people also did a quick search for existing reports
> and read them before they create/append their me-too story. The same holds
> for opensuse lists (look how many reports of this very issue occurred there).
> 
In comment #4 i confirmed that i had the same problem as discussed in this bug report and that the proposed solution/workaround did help me to successfully get back to a proper functioning system.

To give all details on what i did i described as well that i did not supply the option via grub kernel command line but (as mentioned in some other link given in comment #1) via a file /etc/modprobe.d (because to me both ways deemed valid what got confirmed in comment #25).

So if this was just some unwanted "me-too"-story i beg to accept my apology.

Thank you, it now works well with the fix in kernel 5.10.5
Happy new year without covid-19 or other malicious viruses.

Special thanks to Takashi for explaining the fix, too.

(In reply to Bit Juggler from comment #30)
> In comment #4 i confirmed that i had the same problem as discussed in this
> bug report and that the proposed solution/workaround did help me to
> successfully get back to a proper functioning system.

Ah, so in that case I misunderstood that comment.

> So if this was just some unwanted "me-too"-story i beg to accept my apology.

No, I truly apologize you.