Since updating my Tumbleweed, and kernel went from 6.3.7 to 6.3.9, (the one with the bugfixes in Nouveau), my laptop’s screen turns black at the point in the boot process when it should be kernel-modesetting (before drawing the boot splash) and stays this way.
(Rest of system boots normally and is accessible over SSH: I could fetch other informations if needed).
Reverting back to kernel 6.3.7 fixes this for now.
I’ve kept the Xorg’s log from the unsuccessful run (no error reported in the log, so it’s only the modesetting failing to turn the laptop’s screen, everything else seems to run fine).
What other information could be useful?
And best place to report the bug would be upstream nouveau, right?
I commented in your freedesktop report that I cannot reproduce your problem with my GT218 desktop PC (Tesla) or a slightly newer GF108 desktop PC (Fermi).
subtle difference between the GeForce 210 and NVS 3100M (e.g.: it’s a failure to initialise the e-DP output, which obviously your desktop card doesn’t have)
my UEFI initializing it differently than your firmware (BIOS or UEFI).
I don’t even get to the desktop or to the point where I can choose what graphical server (Wayland vs X11).
Crash (and loss of picture) happens early in boot, when the framebuffer would be initialised, right before the bootsplash.
That’s another possible difference between your crash and my not. Plymouth is never installed here, unless forced, in which case it is neutered. Have you tried appending noplymouth, plymouth.enable=0 or plymouth=0 to your Grub linu line?
I just did a dup to 20230628/6.3.9 on a TW/Fermi GF119 [NVS 310] chip-ID: 10de:107d with 2 DisplayPorts, works fine; and did same afterward with a different Tesla/TW than yesterday, G98 [GeForce 8400 GS Rev. 2] chip-ID: 10de:06e4 with DVI/VGA/SVidio outputs, using DVI+VGA, also works as expected.
Nope, confirmed with testing: crash happens right before the point where plymouth would have kicked in, when the nouveau-specific drm framebuffer driver is loaded and takes over the previously used driver (efifb / simple-frame-buffer).
But…
Confirmed pluggin another monitor in:
only the initialisation of the eDP crashes and leads to a black screen on the laptop.
other displays initialise normally and show mirrors of the log-in screen (SDDM).
So you failure of reproduction boils down to the fact that you have no display connected on eDP (obviously given that yours is a desktop card).
Booting in BIOS-mode (CSM tough my laptop is so old it probably wasn’t called that way back then) instead of UEFI: still fails, when nouveaufb tries to take over after vgaarb + simple-frame-buffer
so it’s not UEFI leaving the screen in a weird mode.
Booting with nomodeset options (which disables kernel mode setting, and thus prevents nouveaufb from taking over) works (including bootsplash).
well, except of course, then X11 only works on top of the framebuffer, because Nouveau’s X driver requires kernel mode setting and cannot thus run without nouveaufb.
again proof that it’s probably the display initialisations routines in nouveau.
Conclusion: confirms further that crash only happens when nouveau specifically fails to initialise the eDP display. Everything else, including an external display on another port, work normally.