Taking long time to shutdown (nouveau related logs)

Support
1

Hello,

My laptop (Asus FX505DT) is taking a long time to shutdown (around 60 seconds).

Here is the output of inxi -Fxxxz:

❯ inxi -Fxxxz
System:    Kernel: 5.9.11-3-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.0 Desktop: Xfce 4.14.3 tk: Gtk 3.24.23
           info: xfce4-panel wm: xfwm4 dm: LightDM 1.30.0 Distro: Manjaro Linux
Machine:   Type: Laptop System: ASUSTeK product: TUF Gaming FX505DT_FX505DT v: 1.0 serial: <filter>
           Mobo: ASUSTeK model: FX505DT v: 1.0 serial: <filter> UEFI: American Megatrends v: FX505DT.310 date: 12/24/2019
Battery:   ID-1: BAT0 charge: 26.9 Wh condition: 39.6/48.1 Wh (82%) volts: 10.9/11.7 model: FX50442 type: Li-ion serial: N/A
           status: Discharging
CPU:       Info: Quad Core model: AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx bits: 64 type: MT MCP arch: Zen+ rev: 1
           L2 cache: 2048 KiB
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 33552
           Speed: 1355 MHz max: 1400 MHz boost: disabled Core speeds (MHz): 1: 1347 2: 1285 3: 1227 4: 1236 5: 1315 6: 1327
           7: 1362 8: 1297
Graphics:  Device-1: NVIDIA TU117M [GeForce GTX 1650 Mobile / Max-Q] driver: nouveau v: kernel bus ID: 01:00.0
           chip ID: 10de:1f91
           Device-2: Advanced Micro Devices [AMD/ATI] Picasso vendor: ASUSTeK driver: amdgpu v: kernel bus ID: 05:00.0
           chip ID: 1002:15d8
           Device-3: IMC Networks USB2.0 HD UVC WebCam type: USB driver: uvcvideo bus ID: 3-1:2 chip ID: 13d3:56e5
           serial: <filter>
           Display: x11 server: X.Org 1.20.10 driver: amdgpu,ati,modesetting,nouveau alternate: fbdev,nv,vesa
           resolution: 1920x1080~120Hz s-dpi: 96
           OpenGL: renderer: AMD Radeon Vega 8 Graphics (RAVEN DRM 3.39.0 5.9.11-3-MANJARO LLVM 11.0.0) v: 4.6 Mesa 20.2.3
           direct render: Yes
Audio:     Device-1: NVIDIA driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 10de:10fa
           Device-2: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel
           bus ID: 05:00.6 chip ID: 1022:15e3
           Sound Server: ALSA v: k5.9.11-3-MANJARO
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK driver: r8169 v: kernel port: e000
           bus ID: 02:00.0 chip ID: 10ec:8168
           IF: enp2s0 state: down mac: <filter>
           Device-2: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter vendor: AzureWave driver: rtw_8822ce v: N/A
           port: d000 bus ID: 04:00.0 chip ID: 10ec:c822
           IF: wlp4s0 state: up mac: <filter>
Drives:    Local Storage: total: 476.94 GiB used: 175.96 GiB (36.9%)
           ID-1: /dev/nvme0n1 vendor: Micron model: 2200V MTFDHBA512TCK size: 476.94 GiB speed: 31.6 Gb/s lanes: 4
           serial: <filter> rev: P1MA0V4 scheme: GPT
Partition: ID-1: / size: 196.25 GiB used: 175.93 GiB (89.6%) fs: ext4 dev: /dev/nvme0n1p4
Swap:      Alert: No Swap data was found.
Sensors:   System Temperatures: cpu: 47.6 C mobo: N/A
           Fan Speeds (RPM): N/A
           GPU: device: amdgpu temp: 47.0 C device: nouveau temp: N/A
Info:      Processes: 261 Uptime: 15m Memory: 13.67 GiB used: 2.70 GiB (19.8%) Init: systemd v: 246 Compilers: gcc: 10.2.0
           clang: 11.0.0 Packages: 1594 pacman: 1591 snap: 3 Shell: fish v: 3.1.2 running in: server inxi: 3.1.08

The logs obtained using journalctl -b -1 | rg -i -A99999 "system is powering down" are available at pastebin (due to size limits).

Almost all the time is spent in some logs related to nouveau. I am unable to find out how to resolve these.

Some of the things that I have tried:

  • Reinstalling nouveau.
  • Trying both 5.9 and 5.8 kernels

Can someone please guide me as to how can I fix this.

Thanks!

1 Like
2

Just bumping the thread. If anyone else has experienced the same, can you please share how to go about resolving this. Thanks.

3

Hello :slightly_smiling_face:!
Kernel 5.8+ seems to hang on shutdown more often than previous versions for me aswell.
So far I haven’t found a cause yet, but at least a workaround.
You can try putting

DefaultTimeoutStopSec=20s

into the config file

/etc/systemd/system.conf

(If editing an existing line, make sure to uncomment it by removing the # at the beginning of the line)
That will lower the time systemd waits for processes that aren’t willing to terminate on shutdown.
If 20s is too long, you can reduce it even further, to like 10 or 5 seconds.
You could also try installing proprietary NVIDIA drivers with PRIME and check if that makes a differece.

1 Like
4

Thank you for the pointers! I will try them out and report back.

5

I can confirm the problem, yet I am already on kernel 5.10.2-2

The problem is as can be seen by calling journalctl -b -1 -e:

Jän 08 21:37:28 ebola systemd[1091]: Stopped D-Bus User Message Bus.
Jän 08 21:37:28 ebola systemd[1091]: Started D-Bus User Message Bus.
Jän 08 21:37:28 ebola tracker-miner-fs-3[5128]: OK
Jän 08 21:37:28 ebola systemd[1091]: tracker-miner-fs-3.service: Succeeded.
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: State 'stop-sigterm' timed out. Killing.
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: Killing process 1091 (systemd) with signal SIGKILL.
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: Killing process 5733 (pipewire) with signal SIGKILL.
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: Killing process 5735 (pipewire-media-) with signal SIGKILL.
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: Killing process 5736 (pipewire-media-) with signal SIGKILL.
Jän 08 21:39:27 ebola pipewire[5733]: Asked to handle disabled watch: 0x55698ed419f0 21
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: Killing process 15130 (dbus-daemon) with signal SIGKILL.
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: Main process exited, code=killed, status=9/KILL
Jän 08 21:39:27 ebola systemd[1]: user@1000.service: Failed with result 'timeout'.

See the two minutes timeout?

I suspect either DBus get’s reborn (first two lines) or it is pipewire-related.

6

Most likely it is because of this errors:

Fix requested for merge: data: Fix indirect conflict with exit.target via app.slice (!55) · Merge Requests · GNOME / gnome-session · GitLab

Background: Systemd changed, Gnome has to adapt, otherwise DBus gets (as I suspected) respawned despite a shutdown request.

7

Hey thanks for sharing this. I am using XFCE. Will the gnome-session issue affect manjaro-xfce as well?