Monitor resets many times on boot after new udev rule installed

[pallaswept]

Monitor resets many times on boot after new udev rule installed

[rockowitz]

Offhand, checking for a nvidia gpu is not straightforward. However, looking for driver/ sys/module/nvidia is. chkusbmon could terminate without checking any hiddev device is the nvidia driver is loaded.

[w8jcik]

For me it is obvious why the author wants so many details. To avoid asking few dozens of questions.
Just attach the report instead of pasting it directly and then there is no issue that it is long.

[rockowitz]

As @w8jcik has pointed out, the interrogate command output is voluminous because it has to handle an extreme variety of physical and software configurations It short-circuit's what otherwise could be a long back and forth of specific questions. Just attach the report or submit it in some other way that does not entail pasting it inline. That makes issues unreadable.

Also, please run sudo ddcutil usbenvironment --verbose and submit the output as a attachment. This explores the system's USB configuration.

Monitors that use USB for communication with their virtual control panel, and which adhere to the relevant specifications, are rare. Once you've run sudo ddcutil environment --verbose, try erasing or renaming file /usr/lib/udev/rules.d/60-ddcutil-usb.rules.

[pallaswept]

Hi there, and thanks for your help!

I must apologise, I did not want to seem to make a fuss, so I was trying to be subtle... But maybe I was too subtle. I do understand and agree why a detailed and long log may be needed, but this one is so detailed that it included such details as real names, banking details, etc. I still feel confident that this is not your intention.

I thought that I must be doing it wrong, and that the expectation was that I run the commands with my applications closed, so that this info is not collected from them - I tried this as soon as I was able, but that didn't work, either. I rebooted as soon as I could, to try again, but again, I find info from the logs it has collected, which is private and personal, and I really can't post it online... I'm sorry! I tried!

The logs that contain the sensitive info, only seem to go back a couple of days, I could maybe try again then? My availability is very low right now, so I may fail in that endeavour. Apologies for this, I am doing my best to help out now while I still can. Please let me know if there's any other useful info I could provide.

[rockowitz]

Please identify the logs that contain sensitive information, along with the lines that concern you (with the sensitive information redacted, of course).

[pallaswept]

/var/log/messages and journalctl each contained information from both my browser and pipewire (which contained info from my browser and a couple other apps).

Anyway, the personal stuff has rolled off those, so I'll get you those fresh logs as soon as I can shut down, which should be sometime today. Thanks for your help and patience!

[pallaswept]

Reading through these compiled logs, I noticed a pattern, and I've managed to isolate the cause (repeatably). This is a conflict between nvidia-settings and ddcutil.

Running the commands you've given actually breaks nvidia-settings ability to set fan speeds, until I restart, and this (after some digging) made me realise that, attempting to read the temp with nvidia-smi, and set the fan speed on the card using nvidia-settings at boot, when the udev rule is calling ddcutil, is the trigger for the behaviour I reported.

Fixing this by removing the usb udev rule, has removed not only the 'new' flickering (10-20 resets) on startup, but also some other flashing (5 resets) that have been a thing for...at least a year... I read were the fault of the nvidia driver/X11/sddm - but, I know better now. Now at boot I see it modeset exactly three times; 1 for the console, one for the DM (sddm on X11), and 1 for the DE (Wayland). As it should be. So I don't think this is actually new, just, the new udev rule really kicked it past 'this is mildly annoying' to 'this is potentially dangerous'.

I tried the kernel params suggested Although nvidia apparently patched the bug which is the original source for these commands, it seems they are obsolete, I tried anyway. No luck.

I'll keep trying to get a clean log to you but hopefully this helps give you something 'tangible'. Thanks again for your patience.

[rockowitz]

Thanks for the update. Do you know how nvidia-settings is invoked during initialization? Moving the udev rule later in execution order, i.e. by changing its name to 69-ddcutil-usb.rules, might address the problem.

I will consider not automatically installing 60-ddcutil-usb.rules, but instead leaving it for the user to install. As noted, it is relevant only in the highly unusual case of a monitor with which ddcutil can communicate using USB.

[pallaswept]

nvidia-settings here was invoked from a systemd service. I disabled the service to confirm the conflict in my earlier testing. I had to reboot today, so while I was doing that, I did try delaying it, hopefully allowing the ddcutil rule to run first, but I still saw a bunch of flicking, which actually kicked in at the moment the mode is usually set for the console, courtesy of the nvidia driver's fbdev option.

It reset the monitor a dozen times or so, culminating (possibly after the 10 second delay I put on the service) in kwin (or was it plasma?) freezing up the system and having to hit the power button. The kernel responded to the power button press (I didn't have to hold the switch in), so it seems that the kernel was alive, but certainly, none of my input was working (eg couldn't switch TTY, ctrl+alt+, etc).

Related: Since a while ago (a few months), I've had a weird but seemingly cosmetic-only issue with my machine, where when I shutdown/rebooted, and I would normally see a broadcast message notifying me of the shutdown; here, the line above the message, would have some seemingly-random number of @ symbols. That problem has also disappeared with the removal of the usb rule. I initially did not consider these issues might be related but now, I do.

It seems I have various means of exposing conflicts between the nvidia driver and ddcutil. This round of tests has me looking more at the framebuffer console part of the driver (courtesy of weird characters in the console, and the timing of the flickering at boot), and as far as I'm aware, it is still considered experimental, so that checks out. I'd kinda like to try it again without that option set, but I am not game to punish my machine like that again. When you are able to repro I'm sure you'll understand my hesitance, it's got a real "oof, that can't be healthy" vibe to it.

But maybe, it might be a bug for nvidia to fix. But we both know how long that can take, so for now, I've just disabled the rule. Thinking of a long term solution, I wonder if maybe it might be more desirable to have the rule only run if there is no nvidia GPU present in the machine? Edit: Come to think of it, the interrogate command broke stuff, too, so maybe such a rough approach is not accurate enough to avoid problems.