Bug 1825298

Thank-you for your report.

The attached log is missing some information. Could you attach another log using this procedure:

1. Attempt to shutdown.
2. Wait for the hang.
3. Press the caps-lock key to see if it controls the caps-lock light.
4. Press "ctrl-alt-f2" to see if you can get to a console.
5. Press and hold the power button to power down.
6. Press the power button to restart and login.
7. After getting to a desktop, in a terminal window run:

$ journalctl --no-hostname -k -b -1 > /tmp/dmesg-1.txt

The "-b -1" option selects the log for the previous boot.

Attach /tmp/dmesg-1.txt.

(In reply to Steve from comment #1)
> Thank-you for your report.
> 
> The attached log is missing some information. Could you attach another log
> using this procedure:
> 
> 1. Attempt to shutdown.
> 2. Wait for the hang.
> 3. Press the caps-lock key to see if it controls the caps-lock light.
> 4. Press "ctrl-alt-f2" to see if you can get to a console.
> 5. Press and hold the power button to power down.
> 6. Press the power button to restart and login.
> 7. After getting to a desktop, in a terminal window run:
> 
> $ journalctl --no-hostname -k -b -1 > /tmp/dmesg-1.txt
> 
> The "-b -1" option selects the log for the previous boot.
> 
> Attach /tmp/dmesg-1.txt.

So, two things here:

Running kernel-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33 didn't do anything when I pressed caps-lock or ctrl-alt-f2, but when I pressed any key it was able to light up the backlit keyboard. I am attaching the dmesg-1.txt for this kernel.

Running 5.7.0-0.rc2.1.fc33 same thing happened as above but it *didn't* light up the backlit keyboard. I guess thats a progress, but still I need to hard shut it off. I am attaching the dmesg-2.txt for this kernel.

Created attachment 1680696 [details]
Reboot with kernel-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33

Created attachment 1680697 [details]
Reboot with 5.7.0-0.rc2.1.fc33

Thanks for the additional test reports and for attaching the logs.

In dmesg-1.txt, it looks like you attempted to suspend. Does suspend work?

Could you post the output from:

$ grep -s '' /sys/power/*

Some of the log entries below are in another bug, also with a Dell XPS 13:

Bug 1812010 - Kernel 5.5.7-200 does not suspend on Dell XPS-13 

==
$ egrep -B3 'suspend|s2idle|serio1: Failed' dmesg-1.txt 
...
Apr 17 15:59:16 kernel: PM: suspend entry (s2idle) <<<<<<
--
Apr 17 17:32:56 kernel: Freezing user space processes ... (elapsed 0.259 seconds) done.
Apr 17 17:32:56 kernel: OOM killer disabled.
Apr 17 17:32:56 kernel: Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
Apr 17 17:32:56 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Apr 17 17:32:56 kernel: wlp0s20f3: deauthenticating from 14:dd:a9:8d:26:64 by local choice (Reason: 3=DEAUTH_LEAVING)
Apr 17 17:32:56 kernel: psmouse serio1: Failed to disable mouse on isa0060/serio1 <<<<<<
Apr 17 17:32:56 kernel: PM: suspend devices took 2.121 seconds
--
Apr 17 17:32:56 kernel: Restarting tasks ... 
Apr 17 17:32:56 kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Apr 17 17:32:56 kernel: done.
Apr 17 17:32:56 kernel: PM: suspend exit

For the record:

$ grep DMI: dmesg-1.txt 
Apr 17 15:50:53 kernel: DMI: Dell Inc. XPS 13 9300/0WX9VX, BIOS 1.0.6 01/17/2020

This may not be related to the shutdown hang, but there are some errors related to wireless firmware. How is your wireless working?

$ fgrep -A17 'Intel(R) Wireless WiFi driver for Linux' dmesg-1.txt 
Apr 17 15:52:57 kernel: Intel(R) Wireless WiFi driver for Linux
Apr 17 15:52:57 kernel: Copyright(c) 2003- 2015 Intel Corporation
Apr 17 15:52:57 kernel: iwlwifi 0000:00:14.3: enabling device (0000 -> 0002)
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-hr-b0-53.ucode failed with error -2 <<<<<<
...
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 43.2.23.17
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: Found debug destination: EXTERNAL_DRAM
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: Found debug configuration: 0
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: loaded firmware version 48.4fa0041f.0 Qu-c0-hr-b0-48.ucode op_mode iwlmvm
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: Direct firmware load for iwl-debug-yoyo.bin failed with error -2 <<<<<<
Apr 17 15:52:58 kernel: thunderbolt 0000:00:0d.2: 0: uid crc8 mismatch (expected: 0x0, got: 0xfe)
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: Detected Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW), REV=0x338
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: Applying debug destination EXTERNAL_DRAM
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: Allocated 0x00400000 bytes for firmware monitor.
Apr 17 15:52:58 kernel: iwlwifi 0000:00:14.3: base HW address: 54:8d:5a:75:b4:d0

Hi Steve,

I just figured I would chime in with a "me too", and offer to help with any providing data from another laptop with the same issue.

Just to recap, at the moment a reboot or shutdown won't fully complete.  Systemctl finishes properly without any errors, then the laptop just doesn't turn off (or reset).  Black screen, keyboard backlight will respond when touched.  Press and hold power for >8 seconds and the machine is forced off.  It's like Linux can't get the laptop to reset or power off!


And to ask about WiFi?  It wasn't working, but that's been fixed as of newer 5.6 kernels, per bug #1788150 that I have been watching closely.  Up until that point, I was using a firmware for an alternate card from the Chromium project, but now I'm using what comes with Fedora.

I'm still on FC31.  Kernel 5.6.8-200, Dell BIOS 1.0.7 (latest).  I've found so much history with Dell Laptops and workstations not behaving properly at shutdown/reboot that I've taken to messing with the ACPI params in the kernel command line.  No such luck.  Sadly, I didn't document all the things I tried.  At the moment I'm booting with "acpi_rev_override=1" with no improvement.

This may be my first post, but I'm a long-time Linux user and administrator, I can get this ticket what it needs.  I was thinking about jumping to FC32 this weekend or a day next week, so I can catch up to the latest Fedora if you're looking to hit me up for more logs and tests.

(In reply to Marc C from comment #8)

Thanks for your report. Could you open a new bug report? That makes it easier to see how many people are having a certain problem, and it makes it easier to keep track of attachments.

If a problem appears to be the same in several cases, some of the bug reports can be closed as duplicates.*

Please select "kernel" for the component.

I suggest a bug summary something like this:

"Dell [model number] hangs with black screen on shutdown or reboot"

Your second paragraph is a good description of the problem, so you can just copy it and paste it into the new bug report.

* https://bugzilla.redhat.com/page.cgi?id=fields.html#resolution

Mohan: Marc may have found a workaround for the shutdown problem you reported:

'Go into the BIOS of the laptop, under Virtualization, and DISABLE the option "VT for Direct I/O".'

That's from this upstream bug report:

Bug_206571 - [Bisected] On kernel 5.5 system hangs on shutdown or reboot 
https://bugzilla.kernel.org/show_bug.cgi?id=206571

Related downstream bug report:

Bug 1834277 - Dell XPS 13 9300 (2020) hangs with black screen on shutdown or reboot and 5.7.0-0.rc4

I'm having the same issue running Fedora 32 on a Dell XPS 13 7390.

FWIW it works as expected when booting the Fedora 32 Live DVD image from a pen drive. Yet, it doesn't work with the system that was just installed from the very same pen drive.

Hello Teams, 

Same issue with a new HP Spectre X360 (2019)
as mentioned by Marten no issue with the live CD
The workaround proposed by Marc solve temporary the issue.

Additional information, my computer CPU : 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 126
model name	: Intel(R) Core(TM) i5-1035G4 CPU @ 1.10GHz

I'm no longer experiencing this issue with Kernel version 5.8.4-200.fc32.x86_64.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
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 '32'.

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 32 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 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 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.