Problem: Grub startup Turning on, starting up desktop, there is no screen. Monitor actually enters sleep.
Fedora 36 continues—the nVidia output has no “signal-detected” in monitor.
HP monitor picks this up as “out of range” and suggests setting for “60Hz”! This is opposed to suggested ranges 50 and 59.9* for options in gnome-settings.
Power-off, and re-start computer sometimes goes into the same track. Otherwise, gnome-settings are normal, as the 60Hz has not seen changes.
video player disagrees with any media play. Nouveau throws off complaints about I/O, data, and a fifo it engages. Other-wise there are no clues on PCIe-3.0 nVidia card.
I don’t know if this helps you, but I had a similar issue at work and the issue was that my monitor had a default 20 second timeout and it was timing out before DisplayPort got the signal on boot and not responding. I increased the timeout on my monitor to a minute and that fixed it for me.
Notation: Turn system-on, monitor is on, and first “light” is a terminal-logo “Welcome to grub” which disappears and the screen goes blank. B/W words show in upper-left first line.
The system is loading … somewhere in turn-on sequence, some of the time, is a flash of ‘init’ ops. But is is just that sometimes the list, it just flashes.
Then either the screen will be blank, or, there is the monitor display is “Monitor going to sleep”
The screen notification center-screen overlay says, “Out of range” and suggests the “Try 60Hz” setting. Other onscreen notifications :: VGA DVI HDMI are not active, where generally “HDMI” is highlight green to show status. But in problem area, reports “Not Active”, or “No Activity”.
It’s fickle, or is strictly a contemporaneous action. I use the same monitor with at lest 4 other OS. But this start up is happening in novel fc36. It could be the hardware, specific to this system. But the other Linuxes do not give this performance. Also, I am certainly not on any source-grid of 50Hz (Euro style), but I have experimented on the 59.9* gnome-settings list for this parameter.
-nouveau 0000:01:00.0: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] ch 3 [00ff76d000 totem
subc 0 class c197 mthd 2384 data 20010811
-nouveau 0000:01:00.0: fifo: PBDMA0: 00040000 [PBENTRY] ch 3 [00ff76d000 totem] subc 4 mthd 0000 data 00000000
- nouveau 0000:01:00.0: gr: DATA_ERROR 00000004 [INVALID_VALUE] ch 3 [00ff76d000 totem] subc 0 class c197 mthd 2388 data 0007f0b0
-nouveau 0000:01:00.0: fifo: PBDMA0: 00040000 [PBENTRY] ch 3 [00ff76d000 totem] subc 0 mthd 0000 data 00000000
-nouveau 0000:01:00.0: fifo: fault 00 [READ] at 0000000000000000 engine 00 [gr] client 10 [HUB/PD] reason 02 [PTE] on channel 3 [00ff76d000 totem]
-nouveau 0000:01:00.0: fifo: channel 3: killed
- nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery
-nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery
- nouveau 0000:01:00.0: fifo: engine 7: scheduled for recovery
- nouveau 0000:01:00.0: totem: channel 3 killed!
[edited output messages, late ‘dmesg’]
This messaging output is thrown up here for discussion. Here, I offer no comment.
Oh, that is also an issue of Windows start, from BIOS: Delay notice typically is 30sec for the fast boot on the config start. It would be issue if that ‘win.ini’ setting has bled actually into the BIOS environments. I will note your experience on a display port (virtually, they work on a quaisi-mode of not being a part of the operating system) because there are settings I believe that the OS just cannot undertake. Before I went to Win10 pro, it is why a display-port uses their own installation to put workable drivers in place.
A. The graphics card, nVidia [GP107] is current, and has ticks that are noticed, such as DRM BIT tables where bits “A” and bits “L” are not found in that card’s hardware interface. B. The existence of app Totem complaints in the logs, shown above—direct in relation to ‘nouveau’ engagements. It does not excuse perhaps the presence of damage in my HP monitor (problem not seen with other OS in use as system is turned on). But there it is: there is something bucking the normal system equilibrium. The logs are telling. [the monitor does not have the kind of controls it should have to extend that time-out you have banked on.]
Apparently issue is resolved.
Solution is achieved because problem does not replicate.
From default, doubling the grub time-out makes sense to my system, i7 Intel *(motherboard 2001).