Project

General

Profile

Bug #11948

early kernel allocates too much memory when large displays are attached

Added by Brian Bennett 12 days ago. Updated 8 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:

Description

A 4k display attached will cause the framebuffer to allocate 31MB (3840x2160*4 B). This will cause the system to crash later in boot.

This can be worked around by dropping to the loader prompt and setting a different framebuffer value.

Here's an example from the system I encountered this issue on:

ok framebuffer list
mode 0: 1600x1200x32
mode 1: 1280x1024x32
mode 2: 1024x768x32
mode 3: 640x480x32
mode 4: 800x600x32
mode 5: 3840x2160x32
ok framebuffer set 5

However, the modes can vary. When using VMware fusion the modes are hex numbers (e.g.: 0x100=640x400x8) so it doesn't seem like we can just set a value in loader.rc.

Note: we can use resolution: framebuffer set 1024x768.

tsoome suggested to cap the boot_fb_shadow_init() allocation.

History

#1

Updated by Toomas Soome 12 days ago

  • Subject changed from loader allocates too much memory when large displays are attached to early kernel allocates too much memory when large displays are attached
  • Description updated (diff)

Brian Bennett wrote:

A 4k display attached will cause the framebuffer to allocate 31MB (3840x2160*4 B). This will cause the system to crash later in boot.

This can be worked around by dropping to the loader prompt and setting a different framebuffer value.

Here's an example from the system I encountered this issue on:

[...]

However, the modes can vary. When using VMware fusion the modes are hex numbers (e.g.: 0x100=640x400x8) so it doesn't seem like we can just set a value in loader.rc.

Note we can use resolution like: framebuffer set 1024x768 (or 1024x768x24 in BIOS mode, UEFI only does support 32-bit depths).

tsoome suggested to cap the boot_fb_shadow_init() allocation.

This could be quick fix, however the issue really is about very simplified early allocator we are using in dboot and locore - it does naive assumption we do have contiguous memory we can allocate from. So even if we set limit on shadow fb allocation, we do not know which limit is enough.

#2

Updated by John Levon 8 days ago

Given how bad the results are currently, should we force a lower-res mode? Seems better to have at least a
chance of booting with lower res...

#3

Updated by John Levon 8 days ago

Also, doesn't even the fakebop allocator respect the phys mem map returned from the bootloader?
Or is this a vaddr thing?

Also available in: Atom PDF