Issues with vgacon with kernels >= 6.13

Issues with vgacon with kernels >= 6.13

[Adam Stylinski]

I apologize in advance if this is the wrong tree to be barking up but I'm hitting a wall on this and I'm hoping someone on this ML can point me in the right direction.  Ever since kernel 6.13 (I've not yet bisected but that may be my next step) I've been unable to get my potato system booting up via the any of the simple framebuffer consoles.  The kernel simply hangs right after loading the disk IO schedulers (which, looking at my dmesg logs from 6.12 is _just_ before the vga framebuffer is supposed to take over).  The system is definitely in the realm of antique, with a Core 2 Quad Q9650 and a pre EFI boot stage. I've tried simplefb set as the default console, I've tried vesafb, and I've tried vga=normal, all of these seem to fail just before the GPU handoff.

The major change I do see around 6.13 was a change to support the DRM friendly panic message and I'm tempted to maybe think that's where the regression lives. I also realize I may be one of maybe 6 people affected by this by keeping this system limping along, but I do use it regularly to test SIMD related performance, as it's the last CPU family in Intel's line that actually has the unaligned load penalty.

This is the last kernel message I see prior to boot (hopefully LKML doesn't flag me for adding a URL, but I figured attaching an image would be worse):
https://imgur.com/a/3QkVs2O

Does anyone know of any major changes that might have caused this and anything I should try? My previous configuration is actually to use uvesafb, of which has been failing due to v86d being missing from my distribution for some time now, but it would gracefully fallback. I have an nvidia GPU in this system so the nicer fb options aren't really a thing.  The builtin nvidia modeset is a thing and it does work but that doesn't happen until much later in the boot process. For all intents and purposes, I'm relying on VBE right until that module is loaded, but it hangs much much earlier than that.

Re: Issues with vgacon with kernels >= 6.13

[Adam Stylinski]

On Sat, May 31, 2025 at 07:06:09PM -0400, Adam Stylinski wrote:
> On Sun, Jun 01, 2025 at 12:48:51AM +0200, Helge Deller wrote:
> > What is your .config?
> > 
> > You could try to:
> > - disable DRM:
> > # CONFIG_DRM is not set
> > 
> > - enable:
> > CONFIG_FB=y
> > CONFIG_VGA_CONSOLE=y
> > CONFIG_DUMMY_CONSOLE=y
> > CONFIG_DUMMY_CONSOLE_COLUMNS=80
> > CONFIG_DUMMY_CONSOLE_ROWS=25
> > CONFIG_FRAMEBUFFER_CONSOLE=y
> > CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION=y
> > 
> > Helge
> > 
> > On 5/31/25 23:46, Adam Stylinski wrote:
> > > I apologize in advance if this is the wrong tree to be barking up but I'm hitting a wall on this and I'm hoping someone on this ML can point me in the right direction.  Ever since kernel 6.13 (I've not yet bisected but that may be my next step) I've been unable to get my potato system booting up via the any of the simple framebuffer consoles.  The kernel simply hangs right after loading the disk IO schedulers (which, looking at my dmesg logs from 6.12 is _just_ before the vga framebuffer is supposed to take over).  The system is definitely in the realm of antique, with a Core 2 Quad Q9650 and a pre EFI boot stage. I've tried simplefb set as the default console, I've tried vesafb, and I've tried vga=normal, all of these seem to fail just before the GPU handoff.
> > > 
> > > The major change I do see around 6.13 was a change to support the DRM friendly panic message and I'm tempted to maybe think that's where the regression lives. I also realize I may be one of maybe 6 people affected by this by keeping this system limping along, but I do use it regularly to test SIMD related performance, as it's the last CPU family in Intel's line that actually has the unaligned load penalty.
> > > 
> > > This is the last kernel message I see prior to boot (hopefully LKML doesn't flag me for adding a URL, but I figured attaching an image would be worse):
> > > https://imgur.com/a/3QkVs2O
> > > 
> > > Does anyone know of any major changes that might have caused this and anything I should try? My previous configuration is actually to use uvesafb, of which has been failing due to v86d being missing from my distribution for some time now, but it would gracefully fallback. I have an nvidia GPU in this system so the nicer fb options aren't really a thing.  The builtin nvidia modeset is a thing and it does work but that doesn't happen until much later in the boot process. For all intents and purposes, I'm relying on VBE right until that module is loaded, but it hangs much much earlier than that.
> > > 
> > 
> 
> So, DRM I'm building as a module with 2 or 3 devices I'm not using (strictly it was required for the proprietary nvidia drivers). These modules aren't being loaded though.  Here's what those options are in my config (along with a few others):
> 
> CONFIG_FB=y
> CONFIG_FB_UVESA=y
> CONFIG_FB_VESA=y
> CONFIG_FB_CORE=y
> CONFIG_FB_NOTIFY=y
> CONFIG_FB_DEVICE=y
> CONFIG_FB_CFB_FILLRECT=y
> CONFIG_FB_CFB_COPYAREA=y
> CONFIG_FB_CFB_IMAGEBLIT=y
> CONFIG_FB_SYS_FILLRECT=y
> CONFIG_FB_SYS_COPYAREA=y
> CONFIG_FB_SYS_IMAGEBLIT=y
> CONFIG_FB_SYSMEM_FOPS=y
> CONFIG_FB_DEFERRED_IO=y
> CONFIG_FB_IOMEM_FOPS=y
> CONFIG_FB_IOMEM_HELPERS=y
> CONFIG_FB_SYSMEM_HELPERS=y
> CONFIG_FB_SYSMEM_HELPERS_DEFERRED=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_VGA_CONSOLE=y
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_DUMMY_CONSOLE_COLUMNS=80
> CONFIG_DUMMY_CONSOLE_ROWS=25
> CONFIG_FRAMEBUFFER_CONSOLE=y
> # CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
> # CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is not se
> CONFIG_DRM=m
> # CONFIG_DRM_DEBUG_MM is not set
> CONFIG_DRM_KMS_HELPER=m
> # CONFIG_DRM_PANIC is not set
> CONFIG_DRM_CLIENT=y
> CONFIG_DRM_CLIENT_LIB=m
> CONFIG_DRM_CLIENT_SELECTION=m
> CONFIG_DRM_CLIENT_SETUP=y
> CONFIG_DRM_FBDEV_EMULATION=y
> CONFIG_DRM_FBDEV_OVERALLOC=100
> # CONFIG_DRM_CLIENT_LOG is not set
> CONFIG_DRM_CLIENT_DEFAULT_FBDEV=y
> CONFIG_DRM_CLIENT_DEFAULT="fbdev"
> # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
> CONFIG_DRM_TTM=m
> CONFIG_DRM_EXEC=m
> CONFIG_DRM_TTM_HELPER=m
> CONFIG_DRM_GEM_SHMEM_HELPER=m
> # CONFIG_DRM_RADEON is not set
> # CONFIG_DRM_AMDGPU is not set
> # CONFIG_DRM_NOUVEAU is not set
> # CONFIG_DRM_I915 is not set
> # CONFIG_DRM_XE is not set
> CONFIG_DRM_VGEM=m
> # CONFIG_DRM_VKMS is not set
> # CONFIG_DRM_GMA500 is not set
> # CONFIG_DRM_UDL is not set
> # CONFIG_DRM_AST is not set
> # CONFIG_DRM_MGAG200 is not set
> CONFIG_DRM_QXL=m
> 
> The "TTM" bit is what was needed for nvidia drivers if I remember correctly.

Oh and here are the boot messages on a kernel that can boot, right around those timestamps:

[    0.663455] io scheduler mq-deadline registered
[    0.663496] io scheduler kyber registered
[    0.663539] io scheduler bfq registered
[    0.663851] pcieport 0000:00:1c.0: enabling device (0106 -> 0107)
[    0.664474] uvesafb: failed to execute /sbin/v86d
[    0.664521] uvesafb: make sure that the v86d helper is installed and executable                                                                                                
[    0.664570] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)                                                                                                        
[    0.664613] uvesafb: vbe_init() failed with -22
[    0.664654] uvesafb uvesafb.0: probe with driver uvesafb failed with error -22
[    0.664783] Monitor-Mwait will be used to enter C-1 state
[    0.664818] Monitor-Mwait will be used to enter C-2 state
[    0.664853] Monitor-Mwait will be used to enter C-3 state
[    0.665084] tsc: Marking TSC unstable due to TSC halts in idle
[    0.665222] clocksource: Switched to clocksource hpet
[    0.665573] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    0.665679] ACPI: button: Power Button [PWRB]
[    0.665775] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    0.665923] ACPI: button: Power Button [PWRF]
[    0.681553] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.681772] 00:07: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    0.682710] Non-volatile memory driver v1.3

I'll CC the list as well, as I think that's the proper etiquette.

Re: Issues with vgacon with kernels >= 6.13

[Thomas Zimmermann]

Hi

Am 31.05.25 um 23:46 schrieb Adam Stylinski:
> I apologize in advance if this is the wrong tree to be barking up but I'm hitting a wall on this and I'm hoping someone on this ML can point me in the right direction.  Ever since kernel 6.13 (I've not yet bisected but that may be my next step) I've been unable to get my potato system booting up via the any of the simple framebuffer consoles.  The kernel simply hangs right after loading the disk IO schedulers (which, looking at my dmesg logs from 6.12 is _just_ before the vga framebuffer is supposed to take over).  The system is definitely in the realm of antique, with a Core 2 Quad Q9650 and a pre EFI boot stage. I've tried simplefb set as the default console, I've tried vesafb, and I've tried vga=normal, all of these seem to fail just before the GPU handoff.
>
> The major change I do see around 6.13 was a change to support the DRM friendly panic message and I'm tempted to maybe think that's where the regression lives. I also realize I may be one of maybe 6 people affected by this by keeping this system limping along, but I do use it regularly to test SIMD related performance, as it's the last CPU family in Intel's line that actually has the unaligned load penalty.
>
> This is the last kernel message I see prior to boot (hopefully LKML doesn't flag me for adding a URL, but I figured attaching an image would be worse):
> https://imgur.com/a/3QkVs2O

Try booting the kernel with fb.lockless_register_fb=1 on the kernel 
command line. With might give more output when the display driver loads.

Best regards
Thomas

>
> Does anyone know of any major changes that might have caused this and anything I should try? My previous configuration is actually to use uvesafb, of which has been failing due to v86d being missing from my distribution for some time now, but it would gracefully fallback. I have an nvidia GPU in this system so the nicer fb options aren't really a thing.  The builtin nvidia modeset is a thing and it does work but that doesn't happen until much later in the boot process. For all intents and purposes, I'm relying on VBE right until that module is loaded, but it hangs much much earlier than that.
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)