Framebuffer woes. Kernel change request?

Martinus2u · 01-18-2021, 04:51 AM

I've switched to distro kernel (generic) and initrd and elilo.conf recently. Ever since then the kernel will boot with a framebuffer console, which later on conflicts with the nvidia blob in many ways.

I have provided kernel parameters to stop this. no avail.

Code:

append="root=/dev/nvme0n1p2 mitigations=off nomodeset nofb vga=normal"

I have blacklisted in /etc/modprobe.d. no avail.

I have looked into the initrd. No trace of framebuffer.

At last I checked the kernel config. Lo and behold:

Code:

CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_VMWGFX_FBCON=y
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
CONFIG_FB=y
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_CYBER2000_DDC=y
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA_I2C=y
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_INTEL_I2C=y
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_BACKLIGHT=y
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_VIA_X_COMPATIBILITY=y
CONFIG_FB_3DFX_I2C=y
CONFIG_FB_CARMINE_DRAM_EVAL=y
CONFIG_FB_MB862XX_PCI_GDC=y
CONFIG_FB_MB862XX_I2C=y
CONFIG_HID_PICOLCD_FB=y

It appears the framebuffer device including kms switching is compiled into the kernel.

Yes I know Nvidia is to blame for everything, but apart from that, what can I do to stop this madness? Do I seriously have to compile my own kernel??

And while we're at it, why is ext4 missing from the generic kernel and fb is compiled in? With ext4 99% of people wouldn't need an initrd.

Alien Bob · 01-18-2021, 04:56 AM

I have this in my kernel append statement and the Nvidia binary driver is working well with the generic Slackware kernel (I am typing this on that PC):

Code:

nvidia-drm.modeset=1

The nvidia installer also installed a blacklist file:

Code:

$ cat /etc/modprobe.d/nvidia-installer-disable-nouveau.conf
# generated by nvidia-installer
blacklist nouveau
options nouveau modeset=0

Martinus2u · 01-18-2021, 05:47 AM

Thanks for the input. The nouveau blacklist I had already, although not created by any installer.

I replaced my kernel parameters by "nvidia-drm.modeset=1" and rebooted. This had an effect, but for the worse:

The kernel still bootet in framebuffer mode with a row of penguins at the top. Presumably at the time of pivot_root() (when the initrd is swapped for the real root fs) the display became garbled, in the sense that the console output only went to an area in the centre of the screen.

In hindsight it is clear that kernel options relating to nvidia modules (like nvidia-drm) can only come into effect when the nvidia modules are loaded.

So what I really need is control of the kernel when it is loaded with the initrd.

keefaz · 01-18-2021, 09:25 AM

Could you post output with:

Code:

dmesg | grep -i fb

Martinus2u · 01-18-2021, 11:17 AM

sure:

Code:

[    0.004344] ACPI: SSDT 0x00000000BCCA4000 001FB1 (v02 AMD    AmdTable 00000001 AMD  00000001)
[    0.671690] pci 0000:09:00.0: reg 0x10: [mem 0xfb000000-0xfbffffff]
[    0.671754] pci 0000:09:00.0: BAR 1: assigned to efifb
[    0.672081] pci 0000:00:03.1:   bridge window [mem 0xfb000000-0xfc0fffff]
[    0.813273] pci 0000:00:03.1:   bridge window [mem 0xfb000000-0xfc0fffff]
[    0.813320] pci_bus 0000:09: resource 1 [mem 0xfb000000-0xfc0fffff]
[    0.931007] efifb: probing for efifb
[    0.931015] efifb: framebuffer at 0xd0000000, using 3072k, total 3072k
[    0.931016] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    0.931017] efifb: scrolling: redraw
[    0.931019] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.933236] fb0: EFI VGA frame buffer device
[   53.327988] eth3: 0xffffbe08c0129000, b4:2e:99:f4:ba:30, IRQ 61

keefaz · 01-18-2021, 11:40 AM

efifb is used as it should be, are there any kernel parameters boot used when you did the command?

Just to resume, at boot you get a readable resolution in console (1024x768), then the nvidia module is loaded and it messes with the resolution (too tiny) right?

LuckyCyborg · 01-18-2021, 11:41 AM

Quote:

Originally Posted by Martinus2u

sure:

Code:

[    0.004344] ACPI: SSDT 0x00000000BCCA4000 001FB1 (v02 AMD    AmdTable 00000001 AMD  00000001)
[    0.671690] pci 0000:09:00.0: reg 0x10: [mem 0xfb000000-0xfbffffff]
[    0.671754] pci 0000:09:00.0: BAR 1: assigned to efifb
[    0.672081] pci 0000:00:03.1:   bridge window [mem 0xfb000000-0xfc0fffff]
[    0.813273] pci 0000:00:03.1:   bridge window [mem 0xfb000000-0xfc0fffff]
[    0.813320] pci_bus 0000:09: resource 1 [mem 0xfb000000-0xfc0fffff]
[    0.931007] efifb: probing for efifb
[    0.931015] efifb: framebuffer at 0xd0000000, using 3072k, total 3072k
[    0.931016] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    0.931017] efifb: scrolling: redraw
[    0.931019] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.933236] fb0: EFI VGA frame buffer device
[   53.327988] eth3: 0xffffbe08c0129000, b4:2e:99:f4:ba:30, IRQ 61

Well, blame your UEFI graphical console for having the penguins shown.

BTW, the Linux kernel MUST use EFIFB to display something, because you console is not text, but graphical since the BIOS startup.

I am not a Guru on noble art of The Blob, but from what I read, it should play safe along with EFIFB.

If you have "various issues" better to look in another places.

Martinus2u · 01-18-2021, 12:11 PM

Quote:

Originally Posted by keefaz

efifb is used as it should be, are there any kernel parameters boot used when you did the command?

I've tried combinations of nomodeset, nofb, vga=normal, nvidia-drm.modeset=1, all with the same efifb output.

Quote:

Originally Posted by keefaz

Just to resume, at boot you get a readable resolution in console (1024x768), then the nvidia module is loaded and it messes with the resolution (too tiny) right?

I get a readable console resolution (larger than 1024 x 768), log in at run level 3. I am not sure if nvidia modules are already loaded at that point (I think in the past they were). I can work for hours in that mode, including switching virtual consoles.

Then I do telinit 4. X comes up using the nvidia modules. When switching back to "text" console (ctrl alt f1), the screen blanks out and the monitor goes to sleep. I can toggle back to desktop fine (alt f7).

When shutting down, again the screen blanks without a signal.

I also have a suspend/resume issue, which may be related to the PSU, I am not sure yet.

Quote:

Originally Posted by LuckyCyborg

BTW, the Linux kernel MUST use EFIFB to display something, because you console is not text, but graphical since the BIOS startup.

I didn't realize that. That makes the whole issue more difficult to solve.

I still wonder, am I the only one with this issue? Every motherboard of the last N years boots in EFI mode, no? maybe my screen size (4k)?

Addendum

Code:

video=efifb:off

using this kernel parameter leads to booting without any console output whatsoever. Every user name, password and command needs to be typed in blindly, but you will make it to the nvidia-powered desktop eventually.

Not recommended.

mark111 · 01-18-2021, 06:29 PM

I just want to point out that I have the very same problem.

- UEFI boot with pinguins
- Slackware current with latest huge kernel (5.10.8)
- NVIDIA propriertary blob (460.32.03)

I can boot into run level 3 and 4 without problems, but as soon as I try to go from run level 4 to 3, the monitor goes into standby. Enabling modeset for nvidia-drm makes it worse, reducing the usable screen space to one third of the upper display.

Code:

$ sudo dmesg | grep -i fb
[    0.151231] pci 0000:08:00.0: reg 0x10: [mem 0xfb000000-0xfbffffff]
[    0.151279] pci 0000:08:00.0: BAR 1: assigned to efifb
[    0.151557] pci 0000:00:03.1:   bridge window [mem 0xfb000000-0xfc0fffff]
[    0.294935] pci 0000:00:03.1:   bridge window [mem 0xfb000000-0xfc0fffff]
[    0.294985] pci_bus 0000:08: resource 1 [mem 0xfb000000-0xfc0fffff]
[    0.306275] efifb: probing for efifb
[    0.306285] efifb: framebuffer at 0xd0000000, using 3072k, total 3072k
[    0.306286] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    0.306287] efifb: scrolling: redraw
[    0.306289] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.308312] fb0: EFI VGA frame buffer device
[    0.318478] ahci 0000:0b:00.0: flags: 64bit ncq sntf ilck pm led clo only pmp fbs pio slum part

From searching the internet, it seems that other distributions are reporting similar issues. It all points to the nvidia blob. Unfortunately I cannot test downgrading the driver as I have a RTX 3000 card.

keefaz · 01-19-2021, 08:42 AM

Enabling nvidia-drm modeset, could you try fbset to change resolution, like

Code:

/usr/sbin/fbset -g 1024 768 1024 768 32

mark111 · 01-19-2021, 11:53 AM

Quote:

Originally Posted by keefaz

Enabling nvidia-drm modeset, could you try fbset to change resolution, like

Code:

/usr/sbin/fbset -g 1024 768 1024 768 32

I have tested this now, unfortunately it has zero effect on the distorted output. It seems to do nothing, even when changing the resolution values.

Enabling modeset also prevents XDM from starting. I got a black screen, showing only the mouse cursor.

LuckyCyborg · 01-19-2021, 03:50 PM

Quote:

Originally Posted by mark111

From searching the internet, it seems that other distributions are reporting similar issues. It all points to the nvidia blob. Unfortunately I cannot test downgrading the driver as I have a RTX 3000 card.

Because it is The Blob's fault.

Guys, if you really want to happy switch the virtual consoles and things alike, I strongly recommend you to buy another graphics card, made by another vendor which considers seriously the open-source, for example: AMD or Intel.

PS. I use (sometimes) a NVIDIA graphics card only and exclusivelly because I received it as gift. And only for experiments.

I would NOT give one ruble (or dollar) for any FaRTX 5000 made by NVIDIA. Because of The Blob they worth nothing.

When they will consider seriously to have open-source drivers for real, maybe I will reconsider my opinion myself.

keefaz · 01-20-2021, 07:30 AM

Or use nvidia but don't change runlevel on the fly, instead edit inittab and reboot :/

mark111 · 01-21-2021, 04:30 AM

Quote:

Originally Posted by keefaz

Or use nvidia but don't change runlevel on the fly, instead edit inittab and reboot :/

That's how I am doing it now. Not perfect, but no deal breaker.

Quote:

Originally Posted by LuckyCyborg

Because it is The Blob's fault.

Thanks, I will keep a close eye on my computer. Just in case some green slime - Nvidia green - is dripping out!

keefaz · 01-21-2021, 06:11 AM

Quote:

Originally Posted by mark111

That's how I am doing it now. Not perfect, but no deal breaker.

Just curious, why do you need often to change runlevels?