Description of problem: When I return to my desk and try to wake up my machine the screen never activates. It remains completely dark and unusable until I power cycle the machine. Version-Release number of selected component (if applicable): fedora 33 How reproducible: Repeatable every time Steps to Reproduce: 1. wait for the screen to go blank 2. try to wake the machine back up with keyboard or mouse activity Actual results: nothing happens, the screen remains completely dark Expected results: something happens, notable I can resume working on my machine Additional info:
I could really use help on this so adding a few more pertinent details: * this only just started happening after a recent software update; prior to this update my computer would go to sleep and recover fine * I'm not sure which component to log this against so guessed at gnome-shell; please let me know if I should try elsewhere * I haven't been able to debug or workaround this issue; I don't see any obvious errors when I scan journald and I haven't been able to recover using any magic key combos (like SysRq) but I can ssh into the machine to poke around Thanks in advance.
* this only just started happening after a recent software update; prior to this update my computer would go to sleep and recover fine Could you run for n in $(dnf history list mutter gnome-shell gnome-settings-daemon -q | head -6 | tail -4 | awk '{ print $1; }'); do dnf history info $n | grep -e '\(mutter-3\|gnome-shell-3\|gnome-settings-daemon-3\|Begin time\)'; done It should print when mutter, gnome-shell or gnome-settings-daemon was upgraded the last 4 times. With that, could you paste the result, and make a guess on when it started to happen? > * I'm not sure which component to log this against so guessed at gnome-shell; please let me know if I should try elsewhere Most likely mutter I'd say. > * I haven't been able to debug or workaround this issue; I don't see any obvious errors when I scan journald and I haven't been able to recover using any magic key combos (like SysRq) but I can ssh into the machine to poke around Try 'dnf downgrade mutter gnome-shell' for now. As for the journal, could you check the kernel log too? I.e. journalctl -k. Is there anything at all printed when it happens?
Hi Jonas, Thanks for your note. Below is the recent upgrade history: # for n in $(dnf history list mutter gnome-shell gnome-settings-daemon -q | head -6 | tail -4 | awk '{ print $1; }'); do dnf history info $n | grep -e '\(mutter-3\|gnome-shell-3\|gnome-settings-daemon-3\|Begin time\)'; done Begin time : Mon 23 Nov 2020 12:35:47 PM EST Upgrade gnome-shell-3.38.1-3.fc33.x86_64 @updates Upgrade mutter-3.38.1-2.fc33.x86_64 @updates Upgraded gnome-shell-3.38.1-2.fc33.x86_64 @@System Upgraded mutter-3.38.1-1.fc33.x86_64 @@System Begin time : Sat 14 Nov 2020 11:43:33 AM EST Upgrade gnome-shell-3.38.1-2.fc33.x86_64 @fedora Upgrade mutter-3.38.1-1.fc33.x86_64 @fedora Upgrade gnome-settings-daemon-3.38.1-1.fc33.x86_64 @updates Upgraded gnome-shell-3.36.7-1.fc32.x86_64 @@System Upgraded mutter-3.36.7-1.fc32.x86_64 @@System Upgraded gnome-settings-daemon-3.36.1-1.fc32.x86_64 @@System Begin time : Sat 17 Oct 2020 12:11:39 PM EDT Upgrade gnome-shell-3.36.7-1.fc32.x86_64 @updates Upgraded gnome-shell-3.36.5-1.fc32.x86_64 @@System Upgrade mutter-3.36.7-1.fc32.x86_64 @updates Upgraded mutter-3.36.5-1.fc32.x86_64 @@System Begin time : Sun 06 Sep 2020 12:31:57 PM EDT Upgrade gnome-shell-3.36.5-1.fc32.x86_64 @updates Upgrade mutter-3.36.5-1.fc32.x86_64 @updates Upgraded gnome-shell-3.36.4-1.fc32.x86_64 @@System Upgraded mutter-3.36.4-1.fc32.x86_64 @@System Based on these timestamps I'm certain this problem was introduced on 11/23. Thanks for the tip on `journal -k`. A quick scan did turn up an interesting error from earlier: Nov 24 08:53:10 XXX kernel: snd_hda_codec_hdmi hdaudioC0D2: Monitor plugged-in, Failed to power up codec ret=[-13] Does this suggest the kernel is the problem? LMK if I should still try downgrading mutter and gnome-shell. Thanks!
> Does this suggest the kernel is the problem? LMK if I should still try downgrading mutter and gnome-shell. Not necessarily. I think downgrading mutter and gnome-shell to check whether that helps would be a good idea.
Hi Jonas, I was able to downgrade to the older versions of mutter and shell: $ dnf downgrade gnome-shell-3.38.1-2.fc33.x86_64 mutter-3.38.1-1.fc33.x86_64 but can still reproduce the problem easily with the command: $ systemctl suspend Once suspended like this my screen doesn't wake back up. Please let me know if there are other experiments I can run to help triage this further. Thx.
In case it's helpful for hardware I'm using a Dell 24.1" IPS U2415 connected to an Intel NUC using the Intel UHD Graphics 605 chip. Please let me know if I can provide any more details to help with the triage. I'd like to ensure this bug is categorized against the right component to help drive towards a fix.
Exactly the same thing is happening to me. Also Intel NUC. Philips Monitor. Easily reproducible by "Lock" item in the upper right corner menu. * Keyboard is dead, Num lock or Shift lock does not activate. Cannot switch to virtual console. * Mouse is powered on, but doesn't wake up either. * Same hardware worked perfectly for months on F32. * NUC firmware was updated to the latest in hopes that this would fix the problem, but it didn't. * journalctl shows nothing helpful.
* Update to gnome-shell-3.38.2-1.fc33 didn't help. When I click "Lock" in the right upper corner menu, this happens: ----------------- Dec 07 17:50:03 silent1 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Dec 07 17:50:08 silent1 gsd-usb-protect[1439]: Error calling USBGuard DBus to change the protection after a screensaver event: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable Dec 07 17:50:08 silent1 rtkit-daemon[733]: Supervising 3 threads of 1 processes of 1 users. Dec 07 17:50:08 silent1 rtkit-daemon[733]: Successfully made thread 2125 of process 1251 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5. Dec 07 17:50:08 silent1 rtkit-daemon[733]: Supervising 4 threads of 1 processes of 1 users. Dec 07 17:50:08 silent1 rtkit-daemon[733]: Supervising 3 threads of 1 processes of 1 users. Dec 07 17:50:08 silent1 rtkit-daemon[733]: Successfully made thread 2128 of process 1251 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5. Dec 07 17:50:08 silent1 rtkit-daemon[733]: Supervising 4 threads of 1 processes of 1 users. Dec 07 17:50:08 silent1 gsd-media-keys[1417]: Unable to get default sink Dec 07 17:50:08 silent1 gnome-shell[1239]: Bogus presentation time 0 travelled back in time, using current time. Dec 07 17:50:09 silent1 systemd[1]: Starting Fingerprint Authentication Daemon... Dec 07 17:50:09 silent1 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 07 17:50:09 silent1 systemd[1]: Started Fingerprint Authentication Daemon. ------ Keyboard and mouse are dead after this. Any hints? What can I do to further help debug this? Pretty stumped at this point.
What I've found: Debian: https://forum.endeavouros.com/t/display-does-not-wake-from-sleep/9609 https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1773593.html Debian aarch64: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974172
(In reply to andreas.mack from comment #9) > What I've found: > > Debian: https://forum.endeavouros.com/t/display-does-not-wake-from-sleep/9609 > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1773593. > html > Debian aarch64: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974172 If it's the same, the fix in the debian bug report is available in mutter-3.38.2: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ad05098237
Thanks for your input, Andreas. This has been a troublesome bug to track down so the more help the better. > If it's the same, the fix in the debian bug report is available in mutter-3.38.2: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-ad05098237 I just tested mutter-3.38.2 but it didn't address my symptoms. Specifically I upgraded mutter and rebooted to make sure that the right version was in use. Then I suspended my machine. The PC went into suspend mode (could tell because the power LED started blinking instead of being solidly lit) and the monitor also shut off since there was no video signal. I then tried to wake the machine and the CPU turned back on (LED back to solid) but the screen still never reactivated. I had to manually reboot the machine to wake the screen. I'm happy to help continue testing or providing info to help triage this issue. It's definitely a recent regression since this hardware had been working perfectly with Fedora over the past few years. It wasn't until a `dnf upgrade` in Nov. that this problem appeared.
Do you have the possibility to access your computer remotely via ssh after it was unsuspended?
> Do you have the possibility to access your computer remotely via ssh after it was unsuspended? Yes I believe so.
ssh is still possible. All services run, I can kill gdm and it will be started again, screen stays black and keyboard and mouse input is ignored, Scroll-Lock/NumLock can't be activated (as per the small LEDs on the keyboard) I think it's the kernel. 5.9 may have a problem here. I can't test it since all 5.8 kernels are already uninstalled. I had trouble with 5.9 before, a bluetooth 5 dongle (rtl8761) stopped working also.
Running 3.38.2, does running gdbus call -e -d org.gnome.Mutter.DisplayConfig -m org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' from ssh have any effect?
Not really. [root@silent1 ~]# gdbus call -e -d org.gnome.Mutter.DisplayConfig -m org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable [root@silent1 ~]# su - viola [viola@silent1 ~]$ gdbus call -e -d org.gnome.Mutter.DisplayConfig -m org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' Fehler beim Verbinden: D-Bus kann nicht automatisch ohne X11 $DISPLAY gestartet werden [viola@silent1 ~]$ export DISPLAY=:0 [viola@silent1 ~]$ gdbus call -e -d org.gnome.Mutter.DisplayConfig -m org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' Fehler: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Mutter.DisplayConfig was not provided by any .service files [viola@silent1 ~]$
I downgraded to kernel-5.8.18-300.fc33. * Screen lock is now possible again, unlock screen with password field comes back and works * Suspend/Hibernate wakeup does not work. System goes into hibernate/suspend (white button led flashes) but when I press it, screen stays dark and no keyboard/mouse input. Button goes back to solid white again.
Hi. Just wondering if anyone CCed on this ticket had suggestions on how to proceed? From the discussions it seems likely that andreas.mack and I are experiencing very similar, if not the same, problem with our screens waking back up after suspend. I'm happy to provide as much info as I can to help with debugging to get this resolved. Just let me know what info would be helpful. Thanks in advance.
Let me whole-heartedly second Brian's request. I'm a Linux user since 1995, Red Hat since 1999, and it's been a very long time since I had such a hardware issue. An Intel NUC didn't strike me as exotic or a niche hardware which is hard to support. In a recent HN discussion about Linux sleep/wake problems somebody even brought up NUCs as well supported. If there is anything I can help with, please let me know.
(In reply to andreas.mack from comment #16) > Not really. > > [root@silent1 ~]# gdbus call -e -d org.gnome.Mutter.DisplayConfig -m > org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig > org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' > Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is > not activatable > > [root@silent1 ~]# su - viola > [viola@silent1 ~]$ gdbus call -e -d org.gnome.Mutter.DisplayConfig -m > org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig > org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' > Fehler beim Verbinden: D-Bus kann nicht automatisch ohne X11 $DISPLAY > gestartet werden > [viola@silent1 ~]$ export DISPLAY=:0 > [viola@silent1 ~]$ gdbus call -e -d org.gnome.Mutter.DisplayConfig -m > org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig > org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' > Fehler: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.gnome.Mutter.DisplayConfig was not provided by any .service files > [viola@silent1 ~]$ Is $XDG_RUNTIME_DIR and $DBUS_SESSION_BUS_ADDRESS set to anything? If not, try to set them as this: export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus export XDG_RUNTIME_DIR=/run/user/1000 (assuming your user-ID is 1000), then try the gdbus call again.
(timeout) [viola@silent1 ~]$ export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus [viola@silent1 ~]$ export XDG_RUNTIME_DIR=/run/user/1000 [viola@silent1 ~]$ export DISPLAY=:0 [viola@silent1 ~]$ gdbus call -e -d org.gnome.Mutter.DisplayConfig -m org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' Fehler: Zeitüberschreitung wurde erreicht viola@silent1 ~]$ [viola@silent1 ~]$ uname -a Linux silent1 5.9.13-200.fc33.x86_64 #1 SMP Tue Dec 8 15:42:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux (If I just "Lock" the screen. In "Suspend", the power led comes on again, but I can't ssh to the box)
It's the SecureBoot setting. Once you switch it off, the system will wake up again. The line in dmesg made me think: kernel: Lockdown: swapper/0: hibernation is restricted; see man kernel_lockdown.7 Solved for me for now.
Thanks Andreas. I tried disabling SecureBoot but when I scanned my BIOS I realized that I already had it disabled. This did help me realize that my BIOS was out of date so I took the opportunity to update but the machine still fails to reactivate the display after being suspended. One subtle detail that I noticed is that the NUC does seem to turn the monitor back on after it has gone to sleep but the display is always blank. In other words the monitor does wake up it just doesn't display anything. Sharing this detail in case it's helpful. Anyone have further suggestions for how to track down this problem?
Bummer. Here a few suggestions: 1. What does "cat /sys/kernel/security/lockdown" say? Should be to "none", I read you can switch it off. 2. Are you on UEFI? 3. Are the power options in the BIOS active? SpeedStep, C States I can confirm the blank screen when in suspend mode.
Sure... > 1. What does "cat /sys/kernel/security/lockdown" say? Should be to "none", I read you can switch it off. $ cat /sys/kernel/security/lockdown [none] integrity confidentiality > 2. Are you on UEFI? Yes, I believe so. The BIOS shows it enabled and /sys/firmware/efi exists. $ ls /sys/firmware/efi config_table esrt fw_vendor runtime-map efivars fw_platform_size runtime systab > 3. Are the power options in the BIOS active? SpeedStep, C States Yes, I see SpeedStep and C States ("OS ACPI C2 Report") enabled in the BIOS.
Weird. Can you ssh to the computer, run "journalctl -f", trigger "Lock" or "Suspend" and then re-wakeup? I'd be interested in the output of journal.
Here's a link to the full `journalctl -f` output during a suspect: https://gist.github.com/bfallik/02364bc27c32c372ac06bbb62ede4530 A few interesting call outs are: Dec 15 14:43:27 XXX gsd-media-keys[2590]: Unable to get default sink Dec 15 14:43:27 XXX gnome-shell[2411]: Bogus presentation time 0 travelled back in time, using current time. Dec 15 14:43:28 XXX gsd-usb-protect[2653]: Error calling USBGuard DBus to change the protection after a screensaver event: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable and Dec 15 14:43:44 XXX google-chrome.desktop[3140]: [3133:3155:1215/144344.494441:ERROR:connection_factory_impl.cc(428)] Failed to connect to MCS endpoint with error -105 It's also strange that node_exporter is complaining about not having permissions to read power info but I can't imagine that would prevent the screen from resuming after suspend.
Mine is: https://gist.github.com/andrm/2cc8584a54694eed6fb7d9997257b428 Notably absent from mine are Dec 15 14:43:27 XXX gnome-shell[2411]: Bogus presentation time 0 travelled back in time, using current time. and Dec 15 14:43:44 XXX kernel: smpboot: Scheduler frequency invariance went wobbly, disabling! I had both of them when I had SecureBoot enabled..
More BIOS pointers: In Boot -> Boot Configuration -> OS Selection ? I have "Linux" In Power -> Secondary Power Settings -> (all the way down) "PCIe ASPM Support" is on as well as "Native ACPI OS Support" on.
This is interesting: $ dmesg | grep -i secure [ 0.000000] secureboot: Secure boot disabled [ 0.011620] secureboot: Secure boot disabled [ 3.499314] sdhci: Secure Digital Host Controller Interface driver [ 7.736081] Bluetooth: hci0: Secure boot is enabled I wanted to confirm that I had disabled secureboot and clearly the kernel thinks so. But why does the Bluetooth stack have a different opinion? Thx Andreas, I will go confirm that my BIOS settings match yours.
My BIOS config already had the two settings enabled in Secondary Power Settings but I did switch the OS Selection from Windows to Linux. Interestingly now I don't see the Bluetooth line in dmesg anymore: $ dmesg | grep secure [ 0.000000] secureboot: Secure boot disabled [ 0.011029] secureboot: Secure boot disabled ... but my screen still doesn't show anything after I resume from suspend. =(
Can you post (or send me) the full journalctl -b after a boot and suspend? Did you change other power settings in BIOS (power capping)
Andreas, here's a link to the journalctl -b output: https://gist.github.com/bfallik/a3ad27e6a99abda42482a6cd6837e45d I do not remember changing any other BIOS settings. Is there an easy way to check my active config against the defaults?
I just re-checked: A Kernel 5.8, Secure Boot On: Resume works, but blank screen / "Lock": blank screen trying after hitting a key on the keyboard B Kernel 5.8, Secure Boot Off: everything works C Kernel 5.9, Secure Boot On or Off: Resume in a weird state, no ssh possible / "Lock": blank screen Brian, workaround is to install the last 5.8 kernel, downloaded from Bodhi, that's what I did ( kernel-5.8.18-300.fc33.x86_64.rpm kernel-core-5.8.18-300.fc33.x86_64.rpm kernel-modules-5.8.18-300.fc33.x86_64.rpm) Case A/B is clearly the Lockdown feature. For Case C: I don't know if this helps, but I did a diff of the journal outputs, and I think the ACPI stuff is being read differently between 5.8 and 5.9: diff -W 260 -d -y --suppress-common-lines x5.8 x5.9 Thu 2020-05-07 14:31:06 CEST, end at Wed 2020-12-16 17:31:00 CET. -- | Thu 2020-05-07 14:31:06 CEST, end at Wed 2020-12-16 17:29:26 CET. -- kernel: Linux version 5.8.18-300.fc33.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 10.2.1 20201016 (Red Hat | kernel: Linux version 5.9.13-200.fc33.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 10.2.1 20201125 (Red Hat kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.8.18-300.fc33.x86_64 root=/dev/mapper/fedora_localhost--live-root00 ro | kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.9.13-200.fc33.x86_64 root=/dev/mapper/fedora_localhost--live-root00 ro kernel: e820: update [mem 0x5cf00018-0x5cf10057] usable ==> usable | kernel: e820: update [mem 0x5cefa018-0x5cf0a057] usable ==> usable kernel: e820: update [mem 0x5cf00018-0x5cf10057] usable ==> usable | kernel: e820: update [mem 0x5cefa018-0x5cf0a057] usable ==> usable kernel: e820: update [mem 0x5cef1018-0x5ceff057] usable ==> usable | kernel: e820: update [mem 0x5ceeb018-0x5cef9057] usable ==> usable kernel: e820: update [mem 0x5cef1018-0x5ceff057] usable ==> usable | kernel: e820: update [mem 0x5ceeb018-0x5cef9057] usable ==> usable kernel: reserve setup_data: [mem 0x0000000012151000-0x000000005cef1017] usable | kernel: reserve setup_data: [mem 0x0000000012151000-0x000000005ceeb017] usable kernel: reserve setup_data: [mem 0x000000005cef1018-0x000000005ceff057] usable | kernel: reserve setup_data: [mem 0x000000005ceeb018-0x000000005cef9057] usable kernel: reserve setup_data: [mem 0x000000005ceff058-0x000000005cf00017] usable | kernel: reserve setup_data: [mem 0x000000005cef9058-0x000000005cefa017] usable kernel: reserve setup_data: [mem 0x000000005cf00018-0x000000005cf10057] usable | kernel: reserve setup_data: [mem 0x000000005cefa018-0x000000005cf0a057] usable kernel: reserve setup_data: [mem 0x000000005cf10058-0x00000000673ebfff] usable | kernel: reserve setup_data: [mem 0x000000005cf0a058-0x00000000673ebfff] usable kernel: efi: ACPI 2.0=0x69caa000 ACPI=0x69caa000 TPMFinalLog=0x69cec000 SMBIOS=0x69f6b000 SMBIOS 3.0=0x69f6a000 MEMATTR=0x634 | kernel: efi: ACPI 2.0=0x69caa000 ACPI=0x69caa000 TPMFinalLog=0x69cec000 SMBIOS=0x69f6b000 SMBIOS 3.0=0x69f6a000 MEMATTR=0x634 kernel: RAMDISK: [mem 0x5cf17000-0x5f24dfff] | kernel: RAMDISK: [mem 0x5cf11000-0x5f24dfff] kernel: PM: hibernation: Registered nosave memory: [mem 0x5cef1000-0x5cef1fff] | kernel: PM: hibernation: Registered nosave memory: [mem 0x5ceeb000-0x5ceebfff] kernel: PM: hibernation: Registered nosave memory: [mem 0x5ceff000-0x5cefffff] | kernel: PM: hibernation: Registered nosave memory: [mem 0x5cef9000-0x5cef9fff] kernel: PM: hibernation: Registered nosave memory: [mem 0x5cf00000-0x5cf00fff] | kernel: PM: hibernation: Registered nosave memory: [mem 0x5cefa000-0x5cefafff] kernel: PM: hibernation: Registered nosave memory: [mem 0x5cf10000-0x5cf10fff] | kernel: PM: hibernation: Registered nosave memory: [mem 0x5cf0a000-0x5cf0afff] kernel: Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.8.18-300.fc33.x86_64 root=/dev/mapper/fedora_localhost--live-roo | kernel: Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.9.13-200.fc33.x86_64 root=/dev/mapper/fedora_localhost--live-roo kernel: Memory: 7656616K/7958624K available (14339K kernel code, 2499K rwdata, 8752K rodata, 2504K init, 4636K bss, 302008K r | kernel: Memory: 7656332K/7958624K available (14339K kernel code, 2518K rwdata, 9408K rodata, 2516K init, 4580K bss, 302032K r kernel: random: get_random_u64 called from __kmem_cache_create+0x3e/0x610 with crng_init=0 | kernel: random: get_random_u64 called from __kmem_cache_create+0x2e/0x550 with crng_init=0 kernel: ftrace: allocating 43532 entries in 171 pages | kernel: ftrace: allocating 44235 entries in 173 pages kernel: ftrace: allocated 171 pages with 5 groups | kernel: ftrace: allocated 173 pages with 5 groups kernel: ACPI: Core revision 20200528 | kernel: ACPI: Core revision 20200717 kernel: prefetch64-sse: 10076.000 MB/sec | kernel: prefetch64-sse: 10080.000 MB/sec kernel: generic_sse: 8656.000 MB/sec | kernel: generic_sse: 8660.000 MB/sec kernel: xor: using function: prefetch64-sse (10076.000 MB/sec) | kernel: xor: using function: prefetch64-sse (10080.000 MB/sec) kernel: PM: RTC time: 16:25:59, date: 2020-12-16 | kernel: PM: RTC time: 16:27:51, date: 2020-12-16
I just tried again after upgrading to 5.9.14-200.fc33.x86_64 but the problem still persists.
yes, there is no progress on this issue. I guess we need to wait until the Debian-based distros update to kernel 5.9, they have more installations on NUC probably. Wake/resume works on other platforms, e.g. my Dell XPS doesn't have this problem.
Hello guys, I hope posting adding my information here will help narrowing down the issue. I haven't tried suspending my system, but my screen doesn't come back after going blank (which I used to have set to 5 min in Settings > Power > Power Saving > Blank Screen, in Gnome). I have this issue ever since I upgraded to Fedora 33 (still with kernel 5.8.17-300). In Fedora 32 I didn't have this problem. However, my system is a little different from what you guys posted here. I have a laptop (so, no independent turning on/off monitor) with NVIDIA RTX-2060, and I'm using the nouveau drivers (no proprietary NVIDIA drivers, so far). I'm relatively new to Linux, but please do ask more information or give me instructions if it can be helpful.
I have found that using CTRL+ALT+F2 followed by CTRL+ALT+F1 restarts the display service. I don't see any entries on either my primary HDMI 4k screen or on my aux 1080p vga screen when I switch to F1, and the login prompt appears.
Oh, forgot to mention .. I recently upgraded to F33, like in the past 2 weeks. Linux wkstn 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux And, also updated the NVidia Drivers from Nvidia directly .. NVIDIA-Linux-x86_64-455.45.01
Also, I can prevent the display manager from dying, if I keep CHEESE running.
Thanks for the information! After installing the RPM fusion NVidia drivers, my screen does come back from blank. The CTRL+ALT+F2 CTRL+ALT+F1 wasn't even needed.
@oswaldo, do you know if there is a difference between the nVidia drivers and the RPM Fusion nVidia drivers?
@mfuhrman I honestly don't know if there is a difference. I'm not that experienced. But I usually like to stick with the official repositories.
With the newest updates and kernel 5.10 suspend/wakeup works again! The system wakes up after suspend and showing the screen and everything works. "Lock"/Screenlock does not work so it seems to be a mutter/Gnome problem.
Andreas, Trying to understand your most recent comment 44. I just upgraded my NUC to latest F33 (including 5.10.7-200.fc33.x86_64) and waking up still doesn't work for me. After I suspend my machine I try to wake it back up again but the screen remains dark so I'm forced to hard reboot it. This is the same symptom I original reported when I opened this ticket. Fedora has been broken for me almost two months now and I'm not even sure what next steps to take to try and help identify the root cause so I can resolve it. It's hard for me to even believe that this common of a feature is broken on relatively modern hardware.
Sorry to hear that, Brian. All I can say is that waking up from suspend works again. The NUC goes to suspend after a while, wakup works with a key press. The screen lock thing still does *not* work. I've disabled the "Lock the screen after.." setting. If I use "Lock Screen", the display will not come back. (I also use the "autologin" feature, so when the NUC boots it will automatically login the user). Can you ssh into the NUC after you triggered a wakeup?
Andreas, Perhaps we're talking about different things. In my case I'm pretty sure suspend/resume was always working. The CPU itself would wake up, responding to pings and accepting ssh connections, but the screen would never reactivate and so the machine was unusable locally. Since this is my desktop system I need it to wake from suspect. It's difficult to SSH into it from another system. My only recourse when it enters this state is to physically power cycle the NUC. When you say that you've disabled the "Lock the screen after.." setting where is that setting? In the Gnome settings app, within the "Power" tab I have Blank Screen set to "Never" and "Automatic Suspect" set to off. Thanks, brian
Another thing to try to see if you can "force-enable" the session again is to try this, which is similar to what you tried before: From inside your session screen -S session Suspend, then resume, then from ssh (to the same user as logged in): screen -x session gdbus call -e -d org.gnome.Mutter.DisplayConfig -m org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>'
Hi Jonas, Thanks for that suggestion. I just tried your suggested approach and gdbus responded with a timeout: $ gdbus call -e -d org.gnome.Mutter.DisplayConfig -m org.freedesktop.DBus.Properties.Set -o /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode '<int32 0>' Error: Timeout was reached I don't know what that means but it seems possible that this gdbus call is having similar trouble to whatever is trying to wake up the screen during the a suspect/resume cycle. Any ideas on how to further debug this? Thx, brian
Could you check what your users gnome-shell process is doing at the time? When I try this locally (I lock the screen, ssh, attach to the screen and run the gdbus commands), the screen turns on, though it doesn't draw until I move tho mouse. Could you check what the gnome-shell process of your session is doing? It should be able to respond to that method call no matter what. E.g. from ssh gdb -p $(pgrep -x gnome-shell -u $USER) This should attach gdb to the gnome-shell process, then in gdb, run thread apply all backtrace
Brian, could be that I was wrong, but the I do get the Workplace back after suspend, this didn't happen before. The "Lock screen" thing I meant is in Settings -> Power -> "Blank screen". Sorry, it's different in the German locale. Jonas, I tried this before and also got the timeout. gdb problem: [root@silent1 ~]# gdb -p 1192 GNU gdb (GDB) Fedora 10.1-2.fc33 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 1192 ^C^C^C^C^C ^C^C^C^C^C^C
> Jonas, I tried this before and also got the timeout. Ah, sorry about that, then indeed it is stuck somewhere in the kernel. Maybe run gnome-shell in strace to see where it stopped? Should be possible by editing either /usr/lib/systemd/user/org.gnome.Shell or /usr/lib/systemd/user/org.gnome.Shell.
Process is in "D" state: root@silent1 ~]# ps waux | grep gnome-shell earlyoom 728 0.0 0.0 2496 1708 ? SLs 19:35 0:00 /usr/bin/earlyoom -r 0 -m 4 -M 409600 --prefer ^Web Content$ --avoid ^(dnf|packagekitd|gnome-shell|gnome-session-c|gnome-session-b|lightdm|sddm|sddm-helper|gdm|gdm-wayland-ses|gdm-session-wor|gdm-x-session|Xorg|Xwayland|systemd|systemd-logind|dbus-daemon|dbus-broker|cinnamon|cinnamon-sessio|kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session|startplasma-way|xfce4-session|mate-session|marco|lxqt-session|openbox)$ viola 1221 0.9 2.2 4229536 180788 ? Dsl 19:35 0:06 /usr/bin/gnome-shell viola 1328 0.0 0.2 592896 21600 ? Ssl 19:35 0:00 /usr/libexec/gnome-shell-calendar-server viola 1426 0.0 0.3 2730484 25928 ? Ssl 19:35 0:00 /usr/bin/gjs /usr/share/gnome-shell/org.gnome.Shell.Notifications root 2330 0.0 0.0 221564 840 pts/0 S+ 19:45 0:00 grep --color=auto gnome-shell [root@silent1 ~]# I'm on wayland, let me check if I can get the bt.
[ 1894.483794] sysrq: Show Blocked State [ 1894.483810] task:kworker/1:1 state:D stack: 0 pid: 25 ppid: 2 flags:0x00004000 [ 1894.483882] Workqueue: events i915_hotplug_work_func [i915] [ 1894.483884] Call Trace: [ 1894.483893] __schedule+0x262/0x840 [ 1894.483898] schedule+0x46/0xb0 [ 1894.483900] schedule_preempt_disabled+0xa/0x10 [ 1894.483902] __ww_mutex_lock.constprop.0+0x1f9/0x720 [ 1894.483932] drm_modeset_lock+0x48/0x100 [drm] [ 1894.483949] drm_helper_probe_detect_ctx+0x53/0xd0 [drm_kms_helper] [ 1894.483998] intel_encoder_hotplug+0x3d/0xe0 [i915] [ 1894.484045] intel_ddi_hotplug+0x58/0x3a0 [i915] [ 1894.484091] ? intel_disable_ddi+0x120/0x120 [i915] [ 1894.484136] i915_hotplug_work_func+0x1b2/0x2a0 [i915] [ 1894.484142] process_one_work+0x1b6/0x350 [ 1894.484145] worker_thread+0x53/0x3e0 [ 1894.484147] ? process_one_work+0x350/0x350 [ 1894.484149] kthread+0x11b/0x140 [ 1894.484152] ? __kthread_bind_mask+0x60/0x60 [ 1894.484156] ret_from_fork+0x1f/0x30 [ 1894.484205] task:alsactl state:D stack: 0 pid: 787 ppid: 1 flags:0x00000000 [ 1894.484207] Call Trace: [ 1894.484210] __schedule+0x262/0x840 [ 1894.484213] schedule+0x46/0xb0 [ 1894.484216] schedule_preempt_disabled+0xa/0x10 [ 1894.484217] __mutex_lock.constprop.0+0x12f/0x460 [ 1894.484224] hdmi_eld_ctl_info+0x36/0xa0 [snd_hda_codec_hdmi] [ 1894.484232] __snd_ctl_elem_info.constprop.0+0x1d/0x110 [snd] [ 1894.484238] snd_ctl_elem_info_user+0x86/0xf0 [snd] [ 1894.484246] snd_ctl_ioctl+0x1f1/0x790 [snd] [ 1894.484250] ? eoi_ioapic_pin+0x24/0xe0 [ 1894.484253] __x64_sys_ioctl+0x83/0xb0 [ 1894.484258] do_syscall_64+0x33/0x40 [ 1894.484260] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1894.484264] RIP: 0033:0x7f7cc419838b [ 1894.484265] RSP: 002b:00007fff2a57a268 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1894.484268] RAX: ffffffffffffffda RBX: 0000562705436260 RCX: 00007f7cc419838b [ 1894.484269] RDX: 00007fff2a57a280 RSI: 00000000c1105511 RDI: 0000000000000004 [ 1894.484270] RBP: 00007fff2a57a3f0 R08: 0000000000000000 R09: 0000000000000003 [ 1894.484271] R10: 0000000000000013 R11: 0000000000000246 R12: 00007fff2a57a400 [ 1894.484272] R13: 00007fff2a57a280 R14: 0000562705436270 R15: 0000562705436280 [ 1894.484308] task:gnome-shell state:D stack: 0 pid: 1221 ppid: 1054 flags:0x00004000 [ 1894.484310] Call Trace: [ 1894.484314] __schedule+0x262/0x840 [ 1894.484316] schedule+0x46/0xb0 [ 1894.484318] schedule_preempt_disabled+0xa/0x10 [ 1894.484320] __ww_mutex_lock.constprop.0+0x1f9/0x720 [ 1894.484341] ? drm_atomic_state_init+0x61/0xd0 [drm] [ 1894.484361] drm_modeset_lock+0x48/0x100 [drm] [ 1894.484408] glk_force_audio_cdclk+0x80/0x160 [i915] [ 1894.484456] i915_audio_component_get_power+0xe0/0x100 [i915] [ 1894.484464] snd_hdac_display_power+0xd7/0x150 [snd_hda_core] [ 1894.484488] __azx_runtime_resume+0x1d/0xe0 [snd_hda_intel] [ 1894.484493] azx_runtime_resume+0x39/0x90 [snd_hda_intel] [ 1894.484497] pci_pm_runtime_resume+0xaa/0xc0 [ 1894.484499] ? remove_id_store+0x160/0x160 [ 1894.484503] __rpm_callback+0xce/0x180 [ 1894.484505] ? remove_id_store+0x160/0x160 [ 1894.484507] rpm_callback+0x1f/0x70 [ 1894.484509] ? remove_id_store+0x160/0x160 [ 1894.484511] rpm_resume+0x547/0x7a0 [ 1894.484514] ? __switch_to+0x279/0x450 [ 1894.484516] rpm_resume+0x2e8/0x7a0 [ 1894.484519] __pm_runtime_resume+0x4a/0x80 [ 1894.484523] sync_eld_via_acomp+0xc3/0x330 [snd_hda_codec_hdmi] [ 1894.484527] check_presence_and_report+0x57/0x80 [snd_hda_codec_hdmi] [ 1894.484573] intel_audio_codec_enable+0x12a/0x1a0 [i915] [ 1894.484745] intel_enable_ddi+0x423/0x550 [i915] [ 1894.484786] ? fwtable_write32+0x4c/0x230 [i915] [ 1894.484832] intel_encoders_enable+0x80/0xa0 [i915] [ 1894.484878] hsw_crtc_enable+0x1ba/0x5a0 [i915] [ 1894.485036] intel_enable_crtc+0x53/0x60 [i915] [ 1894.485082] skl_commit_modeset_enables+0x24f/0x520 [i915] [ 1894.485129] intel_atomic_commit_tail+0x301/0x12a0 [i915] [ 1894.485132] ? flush_workqueue_prep_pwqs+0x128/0x140 [ 1894.485134] ? flush_workqueue+0x14f/0x400 [ 1894.485181] intel_atomic_commit+0x333/0x3b0 [i915] [ 1894.485195] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] [ 1894.485214] drm_mode_setcrtc+0x1d3/0x6f0 [drm] [ 1894.485235] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 1894.485252] drm_ioctl_kernel+0x86/0xd0 [drm] [ 1894.485255] ? sched_clock+0x5/0x10 [ 1894.485273] drm_ioctl+0x20f/0x3a0 [drm] [ 1894.485291] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 1894.485294] __x64_sys_ioctl+0x83/0xb0 [ 1894.485297] do_syscall_64+0x33/0x40 [ 1894.485299] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1894.485301] RIP: 0033:0x7f41b985938b [ 1894.485302] RSP: 002b:00007ffdbd9d4aa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1894.485304] RAX: ffffffffffffffda RBX: 00007ffdbd9d4ae0 RCX: 00007f41b985938b [ 1894.485305] RDX: 00007ffdbd9d4ae0 RSI: 00000000c06864a2 RDI: 0000000000000009 [ 1894.485306] RBP: 00000000c06864a2 R08: 0000000000000000 R09: 000055f479ceb720 [ 1894.485307] R10: 0000000000000000 R11: 0000000000000246 R12: 000055f477245360 [ 1894.485308] R13: 0000000000000009 R14: 00007f419c006650 R15: 000055f478ee0300 [ 1894.485314] task:pulseaudio state:D stack: 0 pid: 1233 ppid: 1054 flags:0x00000320 [ 1894.485316] Call Trace: [ 1894.485319] __schedule+0x262/0x840 [ 1894.485322] schedule+0x46/0xb0 [ 1894.485324] schedule_preempt_disabled+0xa/0x10 [ 1894.485325] __mutex_lock.constprop.0+0x12f/0x460 [ 1894.485329] hdmi_eld_ctl_info+0x36/0xa0 [snd_hda_codec_hdmi] [ 1894.485334] __snd_ctl_elem_info.constprop.0+0x1d/0x110 [snd] [ 1894.485340] snd_ctl_elem_info_user+0x86/0xf0 [snd] [ 1894.485347] snd_ctl_ioctl+0x1f1/0x790 [snd] [ 1894.485350] __x64_sys_ioctl+0x83/0xb0 [ 1894.485352] do_syscall_64+0x33/0x40 [ 1894.485354] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1894.485356] RIP: 0033:0x7f5ecf50038b [ 1894.485357] RSP: 002b:00007fffcf90a368 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1894.485358] RAX: ffffffffffffffda RBX: 00007fffcf90a9d0 RCX: 00007f5ecf50038b [ 1894.485359] RDX: 00007fffcf90a850 RSI: 00000000c1105511 RDI: 0000000000000010 [ 1894.485360] RBP: 00007fffcf90a9b0 R08: 000000000000ffff R09: 0000000000000000 [ 1894.485361] R10: 00007f5ecf547d10 R11: 0000000000000246 R12: 000055e77e879fa0 [ 1894.485362] R13: 00007fffcf90a380 R14: 00007fffcf90a850 R15: 000055e77e879fa0
Oh crap, it's the built-in sound chip thing. Brian, disable the sound system in the BIOS. Does that work for you?
holy #$%#$%# that did it! Of course now I don't have audio but disabling audio in the BIOS fixed the behavior I was seeing. Now I can suspend, then resume, and the screen activates again! Woohoo, progress! Now that we've figured out that onboard audio seems to be related to this problem what are next steps to work towards a fix? And is there another workaround that doesn't require me to disable audio entirely? Thanks!
This looks suspicious: https://gitlab.freedesktop.org/drm/intel/-/issues/2623
Jonas, Yes that looks *very* similar to what I was seeing. In that linked issue someone claimed that this problem is already fixed in "drm-tip". How does that code flow into Fedora? Is that built into the kernel or part of libdrm, which I found by a quick `sudo dnf search drm`. brian
drm-tip is the development branch for the graphics subsystem in the kernel. Eventually things on drm-tip will reach Linux proper and thus Fedora, unless they are backported by Fedora kernel maintainers, in which case it may arrive earlier.
Thanks Jonas. As a somewhat well-educated Fedora user how can I know when the fix might be available for me? I have no idea how to track a specific patch in drm-tip though the kernel and into Fedora. Or is the simple answer to just wait for Fedora 34?
If you can find what commit contains the fix, you can look for it using "git tag --contains <sha>" in https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git for stable releases, and https://gitlab.com/cki-project/kernel-ark for rawhide. The fdo gitlab issue, however, doesn't seem to point out what might have fixed it.
Brian, can you test a workaround? Re-enable the Builtin Audio, but disable "DSP" and the "Digital Microphone". Boot the newest kernel. "cat /sys/module/snd_hda_intel/parameters/power_save" should give a "1", disable power save for this device with "echo 0 >/sys/module/snd_hda_intel/parameters/power_save" It seems to work on my system.
Andreas, Woohoo, that workaround also worked for me! Thanks for sharing. I don't fully understand the impact of disabling power_save and the DSP but if audio output and suspend/resume are working then this is a good workaround for me until Fedora pulls in the fix from drm-tip. Thanks. brian
Brian, with the newest kernel it works without the workaround. I left the DSP and the digital microphone off though. Solved for me.
Andreas, Weird, that didn't work for me. I upgraded to 5.10.9-201, enabled microphone and DSP in the BIOS, and turned back on the power_save parameter to snd_hda_intel but my NUC did not recover from being suspended. brian
Brian, I think the problem is with the mic and the DSP. I have the following reasoning: * snd_hda_intel sound chip is very widely used, laptops etc. * digital mic and DSP are not used in these settings, not connected within the sound chip * all this other hardware does not have our problem (hang of the kernel because of power save functions * NUC is Intel hardware, maybe even reference hardware. * Intel has enabled all features within the chip * The powersave functions of the hardware is not tested by kernel/gnome devs * Waking the hardware mic / dsp / chip from sleep results in a deadlock. => We see this problem with the NUC, but nowhere else. I suspect we would have never seen this problem if the digital mic / DSP would have been disabled by default in the BIOS.
Makes sense, thanks. For now I'll leave the modprobe.d snippet in-place that disables /sys/module/snd_hda_intel/parameters/power_save since that seems necessary for both suspend/resume and audio to work. Whenever this bug is fixed I'll be able to re-enable power_save.
Hi! I have the same issue with an Asus Mini PC PN40 using an Intel N4000 processor on F33 and kernel- 5.10.20-200.fc33.x86_64. First, I suspected that it was related to GNOME and Wayland. However, I started GNOME on Xorg, and after each time I pushed the Lock button, the screen went blank but nothing recovered the usual password box. So, I left that idea and came across with this bug related to an Intel Nuc which seems quite a similar host as mine. Unfortunately, there aren't any DSP and digital microphone options in my BIOS. Thus, I couldn't test your solution. I did try "echo 0 >/sys/module/snd_hda_intel/parameters/power_save" but it didn't solve my problem either. Thanks in advance. Homero
Yes it's back :( Even with power_save disabled. gnome-shell in D state. [ 423.472066] sysrq: Show Blocked State [ 423.472102] task:kworker/0:1 state:D stack: 0 pid: 7 ppid: 2 flags:0x00004000 [ 423.472268] Workqueue: events i915_hotplug_work_func [i915] [ 423.472272] Call Trace: [ 423.472288] __schedule+0x262/0x840 [ 423.472295] schedule+0x46/0xb0 [ 423.472300] schedule_preempt_disabled+0xa/0x10 [ 423.472305] __ww_mutex_lock.constprop.0+0x1f9/0x720 [ 423.472375] drm_modeset_lock+0x48/0x100 [drm] [ 423.472412] drm_helper_probe_detect_ctx+0x53/0xd0 [drm_kms_helper] [ 423.472548] intel_encoder_hotplug+0x3d/0xe0 [i915] [ 423.472684] intel_ddi_hotplug+0x58/0x3a0 [i915] [ 423.472696] ? sched_clock+0x5/0x10 [ 423.472702] ? sched_clock_cpu+0xc/0xa0 [ 423.472706] ? newidle_balance+0x1c3/0x3a0 [ 423.472834] i915_hotplug_work_func+0x1af/0x290 [i915] [ 423.472843] process_one_work+0x1b6/0x350 [ 423.472850] worker_thread+0x53/0x3e0 [ 423.472854] ? process_one_work+0x350/0x350 [ 423.472860] kthread+0x11b/0x140 [ 423.472865] ? __kthread_bind_mask+0x60/0x60 [ 423.472871] ret_from_fork+0x1f/0x30 [ 423.472967] task:alsactl state:D stack: 0 pid: 805 ppid: 1 flags:0x00000000 [ 423.472972] Call Trace: [ 423.472978] __schedule+0x262/0x840 [ 423.472983] schedule+0x46/0xb0 [ 423.472987] schedule_preempt_disabled+0xa/0x10 [ 423.472992] __mutex_lock.constprop.0+0x12f/0x460 [ 423.473005] hdmi_eld_ctl_info+0x36/0xa0 [snd_hda_codec_hdmi] [ 423.473023] __snd_ctl_elem_info.constprop.0+0x1d/0x110 [snd] [ 423.473038] snd_ctl_elem_info_user+0x86/0xf0 [snd] [ 423.473057] snd_ctl_ioctl+0x1f1/0x790 [snd] [ 423.473067] __x64_sys_ioctl+0x83/0xb0 [ 423.473099] do_syscall_64+0x33/0x40 [ 423.473106] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 423.473113] RIP: 0033:0x7f6046fff5db [ 423.473116] RSP: 002b:00007ffdf34eb2d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 423.473121] RAX: ffffffffffffffda RBX: 00005594da1e3260 RCX: 00007f6046fff5db [ 423.473124] RDX: 00007ffdf34eb2f0 RSI: 00000000c1105511 RDI: 0000000000000004 [ 423.473128] RBP: 00007ffdf34eb460 R08: 0000000000000000 R09: 0000000000000003 [ 423.473130] R10: 0000000000000013 R11: 0000000000000246 R12: 00007ffdf34eb470 [ 423.473133] R13: 00007ffdf34eb2f0 R14: 00005594da1e3270 R15: 00005594da1e3280 [ 423.473180] task:gnome-shell state:D stack: 0 pid: 1250 ppid: 1059 flags:0x00004000 [ 423.473185] Call Trace: [ 423.473191] __schedule+0x262/0x840 [ 423.473196] schedule+0x46/0xb0 [ 423.473200] schedule_preempt_disabled+0xa/0x10 [ 423.473204] __ww_mutex_lock.constprop.0+0x1f9/0x720 [ 423.473264] ? drm_atomic_state_init+0x61/0xd0 [drm] [ 423.473322] drm_modeset_lock+0x48/0x100 [drm] [ 423.473460] glk_force_audio_cdclk+0x80/0x160 [i915] [ 423.473596] i915_audio_component_get_power+0xe0/0x100 [i915] [ 423.473623] snd_hdac_display_power+0xd7/0x150 [snd_hda_core] [ 423.473653] hda_codec_runtime_resume+0x61/0x70 [snd_hda_codec] [ 423.473675] ? hda_call_codec_resume+0x140/0x140 [snd_hda_codec] [ 423.473683] __rpm_callback+0xce/0x180 [ 423.473703] ? hda_call_codec_resume+0x140/0x140 [snd_hda_codec] [ 423.473708] rpm_callback+0x1f/0x70 [ 423.473727] ? hda_call_codec_resume+0x140/0x140 [snd_hda_codec] [ 423.473732] rpm_resume+0x547/0x7a0 [ 423.473739] __pm_runtime_resume+0x4a/0x80 [ 423.473749] sync_eld_via_acomp+0xc3/0x330 [snd_hda_codec_hdmi] [ 423.473760] check_presence_and_report+0x57/0x80 [snd_hda_codec_hdmi] [ 423.473893] intel_audio_codec_enable+0x12a/0x1a0 [i915] [ 423.474029] intel_enable_ddi+0x41c/0x530 [i915] [ 423.474154] ? fwtable_write32+0x4c/0x230 [i915] [ 423.474351] intel_encoders_enable+0x80/0xa0 [i915] [ 423.474518] hsw_crtc_enable+0x1ba/0x5a0 [i915] [ 423.474687] intel_enable_crtc+0x53/0x60 [i915] [ 423.474853] skl_commit_modeset_enables+0x24f/0x520 [i915] [ 423.475015] intel_atomic_commit_tail+0x301/0x12a0 [i915] [ 423.475030] ? flush_workqueue_prep_pwqs+0x128/0x140 [ 423.475037] ? flush_workqueue+0x14f/0x400 [ 423.475203] intel_atomic_commit+0x333/0x3b0 [i915] [ 423.475259] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] [ 423.475334] drm_mode_setcrtc+0x1d3/0x6f0 [drm] [ 423.475408] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 423.475474] drm_ioctl_kernel+0x86/0xd0 [drm] [ 423.475485] ? sched_clock+0x5/0x10 [ 423.475551] drm_ioctl+0x20f/0x3a0 [drm] [ 423.475627] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 423.475635] __x64_sys_ioctl+0x83/0xb0 [ 423.475640] do_syscall_64+0x33/0x40 [ 423.475645] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 423.475649] RIP: 0033:0x7f7523bf35db [ 423.475652] RSP: 002b:00007ffdacb026c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 423.475656] RAX: ffffffffffffffda RBX: 00007ffdacb02700 RCX: 00007f7523bf35db [ 423.475659] RDX: 00007ffdacb02700 RSI: 00000000c06864a2 RDI: 0000000000000009 [ 423.475661] RBP: 00000000c06864a2 R08: 0000000000000000 R09: 000055e6a30c8ca0 [ 423.475664] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e6a1cc60c0 [ 423.475666] R13: 0000000000000009 R14: 00007f7504006650 R15: 000055e6a30d4fd0 [ 423.475678] task:pulseaudio state:D stack: 0 pid: 1255 ppid: 1059 flags:0x00000320 [ 423.475682] Call Trace: [ 423.475688] __schedule+0x262/0x840 [ 423.475693] schedule+0x46/0xb0 [ 423.475697] schedule_preempt_disabled+0xa/0x10 [ 423.475701] __mutex_lock.constprop.0+0x12f/0x460 [ 423.475711] hdmi_eld_ctl_info+0x36/0xa0 [snd_hda_codec_hdmi] [ 423.475727] __snd_ctl_elem_info.constprop.0+0x1d/0x110 [snd] [ 423.475741] snd_ctl_elem_info_user+0x86/0xf0 [snd] [ 423.475761] snd_ctl_ioctl+0x1f1/0x790 [snd] [ 423.475768] __x64_sys_ioctl+0x83/0xb0 [ 423.475773] do_syscall_64+0x33/0x40 [ 423.475778] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 423.475781] RIP: 0033:0x7f357f6ad5db [ 423.475784] RSP: 002b:00007fff94174648 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 423.475788] RAX: ffffffffffffffda RBX: 00007fff94174cb0 RCX: 00007f357f6ad5db [ 423.475791] RDX: 00007fff94174b30 RSI: 00000000c1105511 RDI: 0000000000000010 [ 423.475793] RBP: 00007fff94174c90 R08: 000000000000ffff R09: 0000000000000000 [ 423.475796] R10: 00007f357f6f4f60 R11: 0000000000000246 R12: 0000561c63c15f60 [ 423.475802] R13: 00007fff94174660 R14: 00007fff94174b30 R15: 0000561c63c15f60
I've nominated this bug as "Prioritzed Bug" as per https://fedoramagazine.org/something-bugging-you-in-fedora-linux-lets-get-it-fixed/ If this doesn't help, Fedora comes off. This bug is "NEW" since half a year now, with a lot of user activity, and still nobody seems to be interested in fixing it. 99% of bugs that I have filed with Fedora gets closed after few months by a bot with the comment "Fedora XX has reached end-of-life". That's depressing.
In today's Prioritized Bug meeting, we agreed to reject this as it will be obviated by the SOF Change. This was planned for Fedora Linux 34. The change to SOF as the default was deferred to F35, however F34 will have support for enabling it. We asked the owner of the SOF change to add instructions on how to opt-in: https://fedoraproject.org/wiki/Changes/SofDefaultForIntelLpe
From the page: "First of all to test you will need to be running Fedora on hardware which is affected by this change. You can check for this by running the following 2 commands from a terminal: cat /sys/bus/acpi/devices/80860F28:*/status 2> /dev/null cat /sys/bus/acpi/devices/808622A8:*/status 2> /dev/null If either of these commands outputs "15" then you have a device which will be switched to the SOF driver as part of this change. " On my system with F33, those commands output nothing. The entries in /sys/bus/acpi/devices/ look very different. Do I need to be on F34 to check this out?
In my first attempt to upgrade from F33 to F32 via dnf system-upgrade .. the system locked after F33 did a final update, and refused to boot back to a command prompt. It kept saying thta it was waiting for a process to finish, and access to a terminal on tty2 .. 12 .. kept flipping back to tty1. So, I pulled the drives, installed new drives and loaded F34 from a fresh install. So far, I have not experience the inability for my system to wake up. I don't consider this resolved, but if the issue is going to just be swept under the rug and not resolved via updates, then I guess we are all stuck at the mercy of waiting for a fresh system install to resolve this bug.
I recently newly build my system with Fedora 34 on my Lenovo X380 Yoga thinkpad. I am experiencing this problem on my system now. When I suspend and attempt to re-awake my system, I get a black screen and nothing seems to work. I have to hold the power button until the system shuts down and reboot. I attempt the last items above: [mswallow@fedora ~]$ cat /sys/bus/acpi/devices/80860f28:*/status 2> /dev/null [mswallow@fedora ~]$ cat /sys/bus/acpi/devices/808622a8:*/status 2> /dev/null [mswallow@fedora ~]$ With no response. I'm not sure what this means exactly. I don't have an option in my bios to turn off sound so that won't help me. The other option that was used as a work around above doesn't seem to be an option for me either: [mswallow@fedora ~]$ cat /sys/module/snd_hda_intel/parameters/power_save 1 [mswallow@fedora ~]$ echo 0 >/sys/module/snd_hda_intel/parameters/power_save bash: /sys/module/snd_hda_intel/parameters/power_save: Permission denied [mswallow@fedora ~]$ sudo echo 0 >/sys/module/snd_hda_intel/parameters/power_save bash: /sys/module/snd_hda_intel/parameters/power_save: Permission denied [mswallow@fedora ~]$ I'm on Kernel 5.13.4-200.fc34 Let me know what additional information I can provide.
I figured out what my problem was ... after looking through many posts, there was one about GRUB options. So I went to look at my GRUB and saw an option called "nomodeset." I didn't know what that did but it didn't make sense that it was being specified. So I booted up a Fedora 34 Live USB and tried to suspend and it worked perfectly. So that, to me, meant it wasn't a hardware issue. Then I looked at the GRUB file and didn't see the "nomodeset" option in the Live USB version. So I booted up from my installed Fedora 34, brought up the GRUB values, removed the "nomodeset" option and the system came up. I then suspended and was able to successfully resume! So it turned out to be a GRUB option (GRUB2). I know that I did not specify it, so no idea where it came from but I suspect some update.
I have a Dell XPS 15 9510, with a fresh Fedora 34 install about 1 month ago, and I have a similar issue. When the system is 'suspended' (but this is via s2idle or Modern Standby, and not S3 Suspend), or if the screen just blanks after the system hasn't been used for some time, and then I try to resume/wake up the screen then some times it does and sometimes I get a 'frozen black screen'. The only thing I can then do is SSH into the machine and reboot it. There doesn't seem to be any other way to get the screen to activate again. I have used various 5.13.x kernels, and all have the problem, and currently have 5.13.15. This laptop has an Intel i7 11800H + nVidia Mobile RTX 3050 Ti (GA107M). I have the following sound module loaded: snd_sof_intel_hda so I assume I have the SOF Intel driver. # cat /sys/module/snd_hda_intel/parameters/power_save 1 My grub file does not have "nomodeset". I have the rpmfusion nvidia driver installed, but the problem was happening from before when I had nouveau (I tried the nvidia driver to see if that would resolve it) Just wondering if this is still a problem others are seeing too?
It still happens with F34, kernel 5.14.10-200.fc34.x86_64. Switching to SOF does not work, I have not sound output device if I do the grubby --update-kernel=ALL --args="snd_intel_dspcfg.dsp_driver=3" I do see this in dmesg with the default driver: snd_hda_codec_hdmi hdaudioC0D2: Monitor plugged-in, Failed to power up codec ret=[-13] blocked trace below. 145.612457] sysrq: Show Blocked State [ 145.612541] task:alsactl state:D stack: 0 pid: 832 ppid: 1 flags:0x00004000 [ 145.612547] Call Trace: [ 145.612553] __schedule+0x316/0x1500 [ 145.612563] ? finish_task_switch.isra.0+0xb1/0x2d0 [ 145.612570] ? __schedule+0x31e/0x1500 [ 145.612573] schedule+0x44/0xa0 [ 145.612576] schedule_preempt_disabled+0xa/0x10 [ 145.612579] __mutex_lock.constprop.0+0x274/0x420 [ 145.612586] hdmi_eld_ctl_info+0x36/0x90 [snd_hda_codec_hdmi] [ 145.612595] snd_ctl_elem_info+0x85/0x190 [snd] [ 145.612608] snd_ctl_elem_info_user+0x45/0xa0 [snd] [ 145.612619] snd_ctl_ioctl+0x1bd/0x7e0 [snd] [ 145.612629] ? security_file_ioctl+0x2f/0x50 [ 145.612634] __x64_sys_ioctl+0x7f/0xb0 [ 145.612640] do_syscall_64+0x38/0x90 [ 145.612645] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 145.612649] RIP: 0033:0x7f84a3c630ab [ 145.612652] RSP: 002b:00007ffc3d9d7768 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 145.612699] RAX: ffffffffffffffda RBX: 00005646bcc227b0 RCX: 00007f84a3c630ab [ 145.612701] RDX: 00007ffc3d9d7780 RSI: 00000000c1105511 RDI: 0000000000000004 [ 145.612702] RBP: 00007ffc3d9d78f0 R08: 0000000000000000 R09: 0000000000000013 [ 145.612704] R10: 00007f84a3d2fa00 R11: 0000000000000246 R12: 00007ffc3d9d7900 [ 145.612705] R13: 00007ffc3d9d7780 R14: 00005646bcc227c0 R15: 00005646bcc227d0 [ 145.612736] task:gnome-shell state:D stack: 0 pid: 1241 ppid: 1078 flags:0x00004000 [ 145.612739] Call Trace: [ 145.612741] __schedule+0x316/0x1500 [ 145.612745] ? sysvec_reschedule_ipi+0x34/0xe0 [ 145.612748] ? asm_sysvec_reschedule_ipi+0x12/0x20 [ 145.612752] schedule+0x44/0xa0 [ 145.612755] schedule_preempt_disabled+0xa/0x10 [ 145.612758] __ww_mutex_lock.constprop.0+0x35c/0x690 [ 145.612763] drm_modeset_lock+0x4a/0x100 [drm] [ 145.612810] glk_force_audio_cdclk+0x7e/0x160 [i915] [ 145.612929] i915_audio_component_get_power+0xe8/0x100 [i915] [ 145.613026] snd_hdac_display_power+0xd1/0x150 [snd_hda_core] [ 145.613042] hda_codec_runtime_resume+0x53/0x60 [snd_hda_codec] [ 145.613059] ? hda_call_codec_resume+0x140/0x140 [snd_hda_codec] [ 145.613071] __rpm_callback+0x43/0x120 [ 145.613077] ? hda_call_codec_resume+0x140/0x140 [snd_hda_codec] [ 145.613089] rpm_callback+0x59/0x70 [ 145.613093] ? hda_call_codec_resume+0x140/0x140 [snd_hda_codec] [ 145.613104] rpm_resume+0x4db/0x770 [ 145.613108] ? input_handle_event+0x1f0/0x5f0 [ 145.613112] __pm_runtime_resume+0x4a/0x80 [ 145.613115] hdmi_present_sense+0x1a3/0x480 [snd_hda_codec_hdmi] [ 145.613122] check_presence_and_report+0x41/0x60 [snd_hda_codec_hdmi] [ 145.613128] intel_audio_codec_enable+0x15e/0x1a0 [i915] [ 145.613225] intel_enable_ddi+0x1ba/0x890 [i915] [ 145.613322] ? fwtable_write32+0x4c/0x230 [i915] [ 145.613405] intel_encoders_enable+0x7d/0xa0 [i915] [ 145.613502] hsw_crtc_enable+0x1d1/0x6b0 [i915] [ 145.613597] intel_enable_crtc+0x56/0x70 [i915] [ 145.613765] skl_commit_modeset_enables+0x272/0x560 [i915] [ 145.614076] intel_atomic_commit_tail+0x46c/0x1450 [i915] [ 145.614383] ? flush_workqueue+0x171/0x450 [ 145.614397] intel_atomic_commit+0x314/0x390 [i915] [ 145.614710] drm_mode_atomic_ioctl+0x8fd/0xac0 [drm] [ 145.614832] ? __cond_resched+0x14/0x40 [ 145.614842] ? drm_connector_init.cold+0x5a/0x5a [drm] [ 145.614960] ? drm_atomic_set_property+0xb30/0xb30 [drm] [ 145.615073] drm_ioctl_kernel+0x84/0xd0 [drm] [ 145.615189] drm_ioctl+0x220/0x3e0 [drm] [ 145.615298] ? drm_atomic_set_property+0xb30/0xb30 [drm] [ 145.615412] ? security_file_ioctl+0x2f/0x50 [ 145.615423] __x64_sys_ioctl+0x7f/0xb0 [ 145.615433] do_syscall_64+0x38/0x90 [ 145.615443] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 145.615452] RIP: 0033:0x7f7f43b750ab [ 145.615458] RSP: 002b:00007ffd9b11a108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 145.615466] RAX: ffffffffffffffda RBX: 00007ffd9b11a150 RCX: 00007f7f43b750ab [ 145.615471] RDX: 00007ffd9b11a150 RSI: 00000000c03864bc RDI: 000000000000000b [ 145.615476] RBP: 00000000c03864bc R08: 0000000000000011 R09: 0000000000000011 [ 145.615481] R10: 00007f7f43c41a00 R11: 0000000000000246 R12: 000055753d036400 [ 145.615486] R13: 000000000000000b R14: 000055753df7ecf0 R15: 000055753d351e00
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.