[solved] Video signal cuts during pacman -Syu

JATothrim · 2024-09-07 00:14:26

I don't think I actually have a problem with my system, and I just want to find an explanation for this:

If I run pacman -Syu the video signal gets *always* cut for a brief moment, if the update isn't just a few pkgs.
This specifically happens somewhere during the update hooks. Sometimes the second display (HDMI) manages to stay on.
However, the displays always recover immediately, and nothing odd seems to be going on otherwise.

So the question is why my displays are "reset" during a system upgrade? Does this happen to anyone else's system?

DE: Cinnamon/X11
glxinfo:
OpenGL renderer string: AMD Radeon RX 580 Series (radeonsi, polaris10, LLVM 18.1.8, DRM 3.57, 6.10.7-77-rzen (self-built) )
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.2.2-arch1.1
I do have autorandr installed, but it's start is disabled in cinnamon settings. (mostly to switch off the second display)

Edit: I'm marking this as solved. I rarely use autorandr now days and assuming the problem was caused solely by it, I don't need it.

Last edited by JATothrim (2024-09-12 13:50:46)

seth · 2024-09-07 07:38:02

This specifically happens somewhere during the update hooks.

So not wifi interference on the cables

Can you make out a specific hook?
Check the system journal/dmesg whether you got a GPU reset at this moment.

There's no systematic "and now let's fade to black" related to updates and I've never seen this (of course dpms will kick in if you're keeping your hands away from the system and just stare at the update messages, as you're supposed to and we all totally do all the time

gromit · 2024-09-07 12:33:27

Do you have any (custom) udev rules in place? It might be the udevadm stuff from systemd: https://gitlab.archlinux.org/archlinux/ … /issues/26

https://gitlab.archlinux.org/archlinux/ … ads#L60-67

You could try to create the file "/etc/systemd/do-not-udevadm-trigger-on-update" so it does not do the udevadm trigger (which is apparently problematic for some setups)

Lone_Wolf · 2024-09-07 13:24:24

gromit wrote:

You could try to create the file "/etc/systemd/do-not-udevadm-trigger-on-update" so it does not do the udevadm trigger (which is ~~apparently~~ problematic for some setups)

I applied the strike-through to apparently, as I'm one of the persons that suffer from this.

Without that file I encounter exactly the same as OP on 1 laptop and 3 desktops.
(All run X, but different WM/DE )

seth · 2024-09-07 13:26:43

All same kind of GPU (family)?
Do you get GPU resets from the udev update?

Lone_Wolf · 2024-09-07 13:48:13

Intel integrated (2015) , amd integrated (2017) , amd discrete (2018) , amd integrated (2022) .

No sign of gpu resets in my logs.

https://bugs.archlinux.org/task/77789 is the original bugreport.

seth · 2024-09-07 14:22:01

I'm aware of the bug but not the temporary output signal loss.
Are those all eDPs? Maybe it's PSR and the bus probe…

Lone_Wolf · 2024-09-07 14:35:31

The intel one connects to a VGA LCD monitor (has no other connectors) , the oldest amd integrated uses VGA or DVI.
The amd discrete card uses DP and the newest amd integrated is the laptop builtin-screen, so eDP .

The systems with the 2 oldest cards/monitors are from friends that rely on me for tech support and only updated from tty .
In that mode the udev reload stuff gives no issues.

On the rare occasions where they were updated from within a gui session they exhibited the same behaviour .

The systems with the 2 newer cards are my own systems and have the do-not-udevadm-trigger-on-update zero-length file that disables the trigger .
(both are often upgraded from within gui sessions during building/updating aur packages) .

JATothrim · 2024-09-08 00:36:38

Can you make out a specific hook?
Check the system journal/dmesg whether you got a GPU reset at this moment.

There are no kernel messages related to GPU, when this happens or afterwards. Also no WiFi, plain wired connection.
The main display is via DP, and this is a desktop/workstation.

A bit of relief to hear that I'm not alone with this. I usually do updates from the GUI session, and this "glitch" is annoying, but I'm been ignoring it for last half-a-year or so.

Lone_Wolf wrote:

I applied the strike-through to apparently, as I'm one of the persons that suffer from this.
Without that file I encounter exactly the same as OP on 1 laptop and 3 desktops.

Ok, I'll try this. I have had same thinking that this has to be related to udev/systemd update hooks somehow

Edit: I tested running 'udevadm trigger' and this had 100% same effect as on update. And surprisingly removing autorandr stopped this, so it was in fact related.
I can't really know if creating the /etc/systemd/do-not-udevadm-trigger-on-update magic file and removing autorandr solved the issue, until an update arrives which touches the udev rules. So I'll report back later.

Last edited by JATothrim (2024-09-08 04:41:09)

seth · 2024-09-08 05:42:38

Does https://aur.archlinux.org/packages/x-on-resize fire when you run "udevadm trigger" ?

JATothrim · 2024-09-11 22:35:16

seth wrote:

Does https://aur.archlinux.org/packages/x-on-resize fire when you run "udevadm trigger" ?

With the magic file /etc/systemd/do-not-udevadm-trigger-on-update in place:
No. And neither at reinstalling autorandr. However after reinstalling autorandr

udevadm trigger -c change

does cause the the displays to flicker again.

I would say the mystery is solved, but I'm waiting for a big enough update to see if it still happens at pacman -Syu time without autorandr and the magic file.

Awebb · 2024-09-12 05:29:08

I had this on X with autorandr, it went away after getting rid of both.

seth · 2024-09-12 05:55:55

Autorandr ships usr/lib/udev/rules.d/40-monitor-hotplug.rules - haven't looked at them but i assume they're Not lazy enough and autorandr acts as If your monitors Had dis- and reappeared instead of scheduling an Update and 1s later notice that actually nothing has happened.

You might also want to Take at https://aur.archlinux.org/packages/x-on-resize

Arch Linux

#1 2024-09-07 00:14:26

[solved] Video signal cuts during pacman -Syu

#2 2024-09-07 07:38:02

Re: [solved] Video signal cuts during pacman -Syu

#3 2024-09-07 12:33:27

Re: [solved] Video signal cuts during pacman -Syu

#4 2024-09-07 13:24:24

Re: [solved] Video signal cuts during pacman -Syu

#5 2024-09-07 13:26:43

Re: [solved] Video signal cuts during pacman -Syu

#6 2024-09-07 13:48:13

Re: [solved] Video signal cuts during pacman -Syu

#7 2024-09-07 14:22:01

Re: [solved] Video signal cuts during pacman -Syu

#8 2024-09-07 14:35:31

Re: [solved] Video signal cuts during pacman -Syu

#9 2024-09-08 00:36:38

Re: [solved] Video signal cuts during pacman -Syu

#10 2024-09-08 05:42:38

Re: [solved] Video signal cuts during pacman -Syu

#11 2024-09-11 22:35:16

Re: [solved] Video signal cuts during pacman -Syu

#12 2024-09-12 05:29:08

Re: [solved] Video signal cuts during pacman -Syu

#13 2024-09-12 05:55:55

Re: [solved] Video signal cuts during pacman -Syu

Board footer