N1X (10de:2e03) on Surface Laptop Ultra: GPU carveout missing from EFI memory map, vmap() WARN, LUT allocation fails, oops in nvSetupOutputLUT5, machine resets

Open
  • Is something wrong?
#1,458 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c, linux
Domain
operating-systems

Research direction

Start by reading the failing call path from nv_vm_map_pages() and nv_alloc_kernel_mapping() to osMapSystemMemory(), then inspect AllocateDevice() and nvSetupOutputLUT5() for the NULL dereference. The issue identifies the memory-map hole, the vmap() warning, and a working memremap_pages() workaround; reproduce on the specified N1X hardware or a matching test setup. Done means safely handling failed LUT allocation and validating mapping behavior for carveout pages without the vmap warning, oops, or reset.

Written by the indexing model from the issue text.

Description

NVIDIA Open GPU Kernel Modules Version

615.78.08 (nvidia-open-dkms 615.78.08-3, Arch packaging, built with DKMS)

Please confirm this issue does not happen with the proprietary driver (of the same version).

Not applicable / not tested: this is a Blackwell (GB20B) integrated GPU, which the proprietary kernel modules don't support, so only the open modules can be used.

Operating System and Version

Omarchy 4 (Arch Linux based, aarch64), BUILD_ID=4.0.0.r7052.ga6dcc31

Kernel Release

Linux 7.2.8-13-omarchy #1 SMP PREEMPT_DYNAMIC Sat, 17 Oct 2026 16:47:02 +0000 aarch64 GNU/Linux (distribution kernel: 7.2.8 stable plus Omarchy's N1X patch set, which carries NVIDIA's N1X SAUCE patches). The failure log below is from 7.2.8-11-omarchy; nothing relevant changed between -11 and -13.

Please confirm you are running a stable release kernel (e.g. not a -rc).

Yes, 7.2.8 (stable), with distribution patches.

Hardware: GPU

GPU 0: NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU), PCI 10de:2e03 (GB20B) at 000f:01:00.0, VBIOS 9A.0B.36.00.04. Machine: Microsoft Surface Laptop Ultra (SKU Surface_Laptop_Ultra_2115), UEFI 7.1.0 (Microsoft Project Mu), 64 GB unified memory.

Describe the bug

On the Surface Laptop Ultra, loading nvidia-drm with modeset=1 makes nvidia-modeset fail to map its display LUT, then oops on a NULL pointer in nvSetupOutputLUT5, and the machine hard-resets a few seconds later. GSP boots fine before this.

Root cause, as far as I can tell: the firmware leaves the GPU carveout out of the EFI memory map entirely, so Linux has no struct page for it, and the driver maps carveout pages with vmap().

  • The IORT has one RMR node for the GPU's stream IDs with the ranges 0x1fd000000+48M (boot framebuffer), 0x200000000+4G (exactly the EXPOSED_DISP_FRM block, set to 4 GiB) and 0xa1600000+386M.
  • With efi=debug, the EFI memory map jumps from 0x0001fcffffff to 0x000300000000 (and has similar gaps around 0xa1600000): the carveouts are absent, not typed Reserved. So memblock never sees them and there is no memmap.
  • On the Dell and ASUS N1X laptops the firmware lists the same region as reserved (Omarchy's N1X setup checks for 1fd000000-119fffffff : reserved in /proc/iomem there), so there it has struct pages with no linear mapping, and the driver's vmap() path works.
  • The page in the WARN (decoded from the registers) is 0x27fffb000, inside the hole. The WARN site (vmap_small_pages_range_noflush+0x388) is the pfn_valid() check. A small probe module confirmed pfn_valid() is 0 for the whole 0x200000000-0x2ffffffff block.
  • The allocation behind the LUT is scattered and mixes pages that have a struct page with carveout pages that don't, so neither vmap() nor vmap_pfn() can map it as a whole.

There are two separate driver problems here:

  1. nv_alloc_kernel_mapping() / nv_vm_map_pages() assume every page it is given has a struct page, which isn't true when firmware hands the GPU memory that isn't in the EFI memory map (IORT RMR only).
  2. nvidia-modeset doesn't handle the failed LUT allocation: after "Failed to allocate memory for the display color lookup table", AllocateDevice() continues into nvSetupOutputLUT5() and dereferences NULL. Even if (1) is a firmware problem, this should fail the device allocation cleanly rather than oops.

Kernel log of the failure (stock 615.78.08, 7.2.8-11-omarchy; trimmed: module list and the first register dump removed):

WARN + oops 
[   28.671263] kernel: WARNING: mm/vmalloc.c:576 at vmap_small_pages_range_noflush+0x388/0x4a0, CPU#5: (udev-worker)/826
[   28.671871] kernel: CPU: 5 UID: 0 PID: 826 Comm: (udev-worker) Tainted: G           OE       7.2.8-11-omarchy #1 PREEMPT(full) 
[   28.671945] kernel: Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[   28.672048] kernel: Hardware name: Microsoft Corporation Microsoft Surface Laptop Ultra/Microsoft Surface Laptop Ultra, BIOS 7.1.0 10/05/2026
[   28.672117] kernel: pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[   28.672177] kernel: pc : vmap_small_pages_range_noflush+0x388/0x4a0
[   28.672225] kernel: lr : vmap+0xc0/0x190
[   28.672895] kernel: Call trace:
[   28.672947] kernel:  vmap_small_pages_range_noflush+0x388/0x4a0 (P)
[   28.672998] kernel:  vmap+0xc0/0x190
[   28.673039] kernel:  nv_vm_map_pages+0xf8/0x2a0 [nvidia]
[   28.673090] kernel:  nv_alloc_kernel_mapping+0x100/0x2d8 [nvidia]
[   28.673145] kernel:  osMapSystemMemory+0xc0/0x540 [nvidia]
[   28.673190] kernel:  memMap_IMPL+0x8dc/0x1060 [nvidia]
[   28.673236] kernel:  serverMap+0x280/0x3a0 [nvidia]
[   28.673287] kernel:  rmapiMapToCpuWithSecInfoV2+0x198/0x2a0 [nvidia]
[   28.673313] kernel:  rmapiMapToCpuWithSecInfoTls+0x5c/0x80 [nvidia]
[   28.673339] kernel:  _nv04MapMemory.constprop.0+0x74/0xa0 [nvidia]
[   28.673388] kernel:  rm_kernel_rmapi_op+0x58/0x120 [nvidia]
[   28.673422] kernel:  nvkms_call_rm+0x60/0xc0 [nvidia_modeset]
[   28.673465] kernel:  nvRmApiMapMemory+0x5c/0x80 [nvidia_modeset]
[   28.673508] kernel:  AllocateDevice+0xcc/0x360 [nvidia_modeset]
[   28.673542] kernel:  nv_drm_register_drm_device+0x148/0x280 [nvidia_drm]
[   28.673593] kernel:  EnumerateGpus+0x154/0x180 [nvidia_modeset]
[   28.673645] kernel:  nv_drm_init+0x48/0xa0 [nvidia_drm]
[   28.673690] kernel:  nv_linux_drm_init+0x1c/0xfd0 [nvidia_drm]
[   28.673733] kernel:  do_one_initcall+0x60/0x4b8
[   28.673774] kernel:  do_init_module+0xa0/0x308
[   28.673803] kernel:  load_module+0x1c50/0x2528
[   28.673830] kernel:  init_module_from_file+0x10c/0x180
[   28.673870] kernel:  __arm64_sys_finit_module+0x228/0x380
[   28.673914] kernel:  invoke_syscall.constprop.0+0xb0/0x130
[   28.673943] kernel:  el0_svc_common.constprop.0+0x114/0x140
[   28.673985] kernel:  do_el0_svc+0x28/0x58
[   28.674024] kernel:  el0_svc+0x48/0x310
[   28.674063] kernel:  el0t_64_sync_handler+0xc0/0x110
[   28.674110] kernel:  el0t_64_sync+0x1b8/0x1c0
[   28.674131] kernel: ---[ end trace 0000000000000000 ]---
[   28.674171] kernel: NVRM: failed to map pages!
[   28.674206] kernel: NVRM: osMapSystemMemory: failed to create system memory kernel mapping!
[   28.674240] kernel: nvidia-modeset: ERROR: GPU:0: Unable to allocate LUT memory from sysmem
[   28.674288] kernel: nvidia-modeset: ERROR: GPU:0: Failed to allocate memory for the display color lookup table.
[   28.827289] kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f0
[   28.827914] kernel: Mem abort info:
[   28.847448] kernel:   ESR = 0x0000000096000004
[   28.847571] kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
[   28.847754] kernel:   SET = 0, FnV = 0
[   28.847969] kernel:   EA = 0, S1PTW = 0
[   28.848162] kernel:   FSC = 0x04: level 0 translation fault
[   28.848287] kernel: Data abort info:
[   28.848407] kernel:   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[   28.848518] kernel:   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   28.848617] kernel:   GCS = 0, Overlay = 0, DirtyBit = 0
[   28.848738] kernel: user pgtable: 4k pages, 48-bit VAs, pgdp=0000000108b48000
[   28.848867] kernel: [00000000000000f0] pgd=0000000000000000, p4d=0000000000000000
[   28.848993] kernel: Internal error: Oops: 0000000096000004 [#1]  SMP
[   28.849318] kernel: CPU: 5 UID: 0 PID: 826 Comm: (udev-worker) Tainted: G        W  OE       7.2.8-11-omarchy #1 PREEMPT(full) 
[   28.849348] kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[   28.849379] kernel: Hardware name: Microsoft Corporation Microsoft Surface Laptop Ultra/Microsoft Surface Laptop Ultra, BIOS 7.1.0 10/05/2026
[   28.849402] kernel: pstate: 41400009 (nZcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[   28.849429] kernel: pc : nvSetupOutputLUT5+0x4c/0x200 [nvidia_modeset]
[   28.849451] kernel: lr : EvoSetOutputLutC9+0xec/0x440 [nvidia_modeset]
[   28.849474] kernel: sp : ffff800083c227e0
[   28.849504] kernel: x29: ffff800083c231f0 x28: 0000000000000000 x27: 0000000000000000
[   28.849527] kernel: x26: ffff800087724008 x25: ffff800085b4f008 x24: 0000000000000000
[   28.849554] kernel: x23: ffff8000876cd510 x22: ffff800083c22918 x21: ffff800085fd8008
[   28.849579] kernel: x20: ffff800085b4f068 x19: ffff000095a60608 x18: ffff800083777080
[   28.849605] kernel: x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[   28.849632] kernel: x14: ffff800087c79008 x13: 0000000000000004 x12: 0000000000730157
[   28.849659] kernel: x11: 0000000000002878 x10: 0000000000002100 x9 : ffffc3c59277033c
[   28.849686] kernel: x8 : ffff800085fd8008 x7 : ffff800083c228aa x6 : ffff800083c228b8
[   28.849711] kernel: x5 : ffff800083c228ac x4 : ffff800083c228b0 x3 : 0000000000000000
[   28.849738] kernel: x2 : 0000000000000000 x1 : ffff800085b4f068 x0 : 0000000000000000
[   28.849765] kernel: Call trace:
[   28.849781] kernel:  nvSetupOutputLUT5+0x4c/0x200 [nvidia_modeset] (P)
[   28.849807] kernel:  AllocateDevice+0xcc/0x360 [nvidia_modeset]
[   28.849836] kernel:  nv_drm_register_drm_device+0x148/0x280 [nvidia_drm]
[   28.849856] kernel:  EnumerateGpus+0x154/0x180 [nvidia_modeset]
[   28.849875] kernel:  nv_drm_init+0x48/0xa0 [nvidia_drm]
[   28.849894] kernel:  nv_linux_drm_init+0x1c/0xfd0 [nvidia_drm]
[   28.849918] kernel:  do_one_initcall+0x60/0x4b8
[   28.849941] kernel:  do_init_module+0xa0/0x308
[   28.849964] kernel:  load_module+0x1c50/0x2528
[   28.849986] kernel:  init_module_from_file+0x10c/0x180
[   28.850023] kernel:  __arm64_sys_finit_module+0x228/0x380
[   28.850049] kernel:  invoke_syscall.constprop.0+0xb0/0x130
[   28.850073] kernel:  el0_svc_common.constprop.0+0x114/0x140
[   28.850105] kernel:  do_el0_svc+0x28/0x58
[   28.850127] kernel:  el0_svc+0x48/0x310
[   28.850145] kernel:  el0t_64_sync_handler+0xc0/0x110
[   28.850169] kernel:  el0t_64_sync+0x1b8/0x1c0
[   28.850186] kernel: Code: f9000080 f90000ca f953fd00 b9680502 (f9407806) 
[   28.850264] kernel: ---[ end trace 0000000000000000 ]---
To Reproduce
  • Microsoft Surface Laptop Ultra (NVIDIA N1X, 10de:2e03), UEFI 7.1.0, EXPOSED_DISP_FRM set to 4 GiB.
  • Kernel with the N1X platform patches (here Omarchy's linux-omarchy 7.2.8 for aarch64), nvidia-open 615.78.08, nvidia_drm.modeset=1 fbdev=1.
  • Boot; nvidia, nvidia-modeset and nvidia-drm load (from the initramfs or by hand).
  • The WARN above appears as nvidia-drm registers its device, then the oops, then the machine resets.
Bug Incidence

Always

nvidia-bug-report.log.gz

Not attached. In the failing configuration the machine hard-resets within seconds of nvidia-drm loading, so nvidia-bug-report.sh can't run in that state; the kernel log above is from the journal of that boot. The machine now runs with the workaround below, and I can run nvidia-bug-report.sh in that state and share it on request, or capture anything else you need.

More Info

Workaround (works): a small out-of-tree module, n1x_carveout_memmap, loaded before nvidia, calls memremap_pages() with MEMORY_DEVICE_PRIVATE over 0x200000000-0x2ffffffff and 0xa1600000-0xb7ffffff. That creates struct pages with no linear mapping, i.e. the same state the Dell/ASUS firmware gives the carveout. With it loaded, the stock vmap() path maps everything: 0 WARNINGs, eDP-1 connected on nvidia-drm, Hyprland on NVIDIA, OpenGL 4.6 and Vulkan 1.4, glmark2/vkmark complete, and 24 GiB of GPU buffers resident with exact read-back. The ranges are hard-coded for a 4 GiB EXPOSED_DISP_FRM.

Driver patch (defensive): nvidia-615.78.08-n1x-carveout.patch makes kernel mappings fall back to vmap_pfn()/ioremap only for pages with no struct page (and log the page list if nothing fits), and makes nvidia_mmap use remap_pfn_range instead of vm_insert_page for carveout pages. With the memmap module loaded the fallback never runs; it is there for when the module is missing. It doesn't solve the mixed-page case on its own, which is why the memmap module is the real fix.

Both are in this gist: https://gist.github.com/teo-casares/8b64949638e1952602a7f435bb34d5b8 (n1x_carveout_memmap.c, nvidia-615.78.08-n1x-carveout.patch).

What I think the proper fix is: either the firmware describes the carveout as reserved in the EFI memory map, or the driver (or kernel platform code) creates a ZONE_DEVICE memmap for IORT RMR ranges assigned to the GPU that are missing from the memory map, instead of assuming vmap() will work. And independently, nvidia-modeset should handle the LUT allocation failure without the NULL dereference.

Hardware support discussion with more detail: https://github.com/omacom/omarchy/discussions/15885

Investigated and written up with AI assistance (Claude); all data above comes from the affected machine and was tested on it.

Dominant language
C
Stars
17.5k
Forks
1.9k
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/open-gpu-kernel-modules

All issues in NVIDIA/open-gpu-kernel-modules

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.