Project

General

Profile

Actions

Bug #11948

open

early kernel allocates too much memory when large displays are attached

Added by Brian Bennett about 2 years ago. Updated almost 2 years ago.

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

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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.

Actions #1

Updated by Toomas Soome about 2 years 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.

Actions #2

Updated by John Levon about 2 years 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...

Actions #3

Updated by John Levon about 2 years ago

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

Actions #4

Updated by John Levon almost 2 years ago

NB: I have some changes coming into illumos-joyent that won't fix this as such, but will at least make dboot fail more elegantly.

Actions #5

Updated by John Levon almost 2 years ago

These were those changes:

https://github.com/joyent/illumos-joyent/commit/2c0eb3d4f98089c725b93d03ed8ad8f439bb0ab3

along with:

https://github.com/joyent/ipxe/commit/ab25dde3d656adfccecb04882b60849655e36be2

Brian Bennett reported that these changes actually let his system boot, although there are other
problems when not chain-loading iPXE from loader.

Actions

Also available in: Atom PDF