[Bug] Turing laptop GPU (GTX 1660 Ti Max-Q): cold boot with USB-C/DP monitor connected never reaches desktop, WindowServer crashloops in nvk_UpdateDescriptorSets

Open
  • Is something wrong?
#520 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, rust
Domain
backend, operating-systems

Research direction

Start by comparing this cold-boot crash with the linked issues #183, #204, #169, #185, #320, #387, and #138; the report identifies nvk_UpdateDescriptorSets in libvulkan_nouveau.dylib as the repeated fault. Check the driver’s display initialization path for the USB-C/DP monitor present at boot, then reproduce with the monitor attached and inspect WindowServer crash reports. Done means cold boot reaches the desktop with the external monitor attached without the crash loop.

Written by the indexing model from the issue text.

Description

bug
Send logs report ID

NM-NWSBFGYE, NM-EP405XWD, NM-P9HASG9B, NM-G0P2VJR5, NM-PHS2MN9H, NM-YDTPYCMQ, NM-PZ5WKTTG, NM-52XPMFVN, NM-JF4V33MP, NM-19YKBWBA, NM-PZGXEV93, NM-VKS9KDP1, NM-K6Y816Z6

Where does it go wrong?

Booting macOS after the driver (black / grey screen, restarts)

What happens

Summary

The driver installs and works correctly on this laptop: with no external monitor attached, the Mac boots cleanly to desktop on the internal panel, kmutil showloaded shows all 4 NVIDIA components loaded, and system_profiler SPDisplaysDataType reports the GTX 1660 Ti with Metal: supported. The problem below is isolated entirely to the USB-C/DP external-monitor scenario — it does not affect internal-panel-only boots in any way.

On this laptop (Optimus-style wiring: internal panel on AMD iGPU, external USB-C DisplayPort output wired directly to the NVIDIA GPU), connecting a monitor to the USB-C port before power-on prevents the Mac from ever reaching the desktop. Verbose boot text displays fine on the USB-C monitor (firmware/GOP framebuffer), but the handoff to NVRMFB never completes — WindowServer enters a crash loop inside nvk_UpdateDescriptorSets (NULL pointer, cr2=0), repeating every 6-11 seconds.

Separately, hot-plugging the USB-C monitor into an already-booted, working desktop session does not bring up the display at all (consistent with #138 — slot table built once per boot).

This looks like the same class of problem as #183 / #204 / #169 / #185 / #320 / #387 (Turing/small-BAR GPUs, 256 MB BAR1, no Resizable BAR support on Turing, BAR1 surface-budget exhaustion), but filing separately since it's specifically the cold-boot-with-monitor-attached path on a laptop dGPU wired directly to a USB-C DP output, not a desktop HDMI/DP scenario, and it fails before ever reaching a desktop rather than flickering or degrading at runtime.

Hardware
Laptop ASUS ROG Zephyrus G14 GA401IU
CPU AMD Ryzen 7 4800HS (Renoir)
iGPU AMD Radeon Vega (Renoir) — drives internal panel, NootedRed
dGPU NVIDIA GeForce GTX 1660 Ti Max-Q (Turing, device ID 10DE:2191)
External output USB-C w/ DisplayPort Alt Mode, wired directly to the NVIDIA GPU's own USB-C Port Policy Controller (10DE:1AED) — not routed through the iGPU
SMBIOS MacBookPro16,3
macOS 15.8.2 (24H232)
Driver NullMoth NVIDIA driver 2.7.2, installed via 1401

Steps to reproduce

  1. Install the driver normally (internal panel only, no external monitor attached). Works fine — internal panel gets NVIDIA acceleration, kmutil showloaded shows all 4 components, system_profiler SPDisplaysDataType shows the GTX 1660 Ti with Metal: supported.
  2. Fully power off.
  3. Connect a monitor to the USB-C port.
  4. Power on.

Result: verbose boot text displays correctly on the USB-C monitor through GOP. Boot proceeds past EXITBS:START. The internal panel never lights up and the USB-C monitor never reaches a graphical desktop. The 1401-written logs folder on the EFI partition captured 7 WindowServer crash reports over about 3 minutes (01:55:29 through 01:58:16), each one an EXC_BAD_ACCESS (SIGSEGV) at cr2=0 inside nvk_UpdateDescriptorSets — launchd relaunches WindowServer each time and it crashes again within 6-11 seconds.

Separately: plugging the USB-C monitor into a session that's already fully booted (internal panel only, no monitor at boot) does not bring up the display either — consistent with the no-rescan behavior described in #138.

Crash signature (identical across all 7 captures)

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000
cr2: 0x0000000000000000
Crashed Thread:  ws_main_thread
Faulting frame:  nvk_UpdateDescriptorSets + 1836  (libvulkan_nouveau.dylib)

All 7 crash reports share the exact same imageOffset for the top frame; only ASLR slide differs between relaunches. Timestamps: 2026-11-07 01:55:29, 01:55:35, 01:55:46, 01:55:56, 01:56:07, 01:56:18, 01:58:16 (+0700).

config.plist relevant settings (post-install, 1401-managed)

UEFI > Quirks > ResizeGpuBars        = -1
Booter > Quirks > ResizeAppleGpuBars = 0
Kernel > Block > com.apple.iokit.IONDRVSupport = Exclude (Enabled)
csr-active-config = 430A0000
boot-args: -v debug=0x100 ... nvfb=1 nvaccel=1 nvfbheads=4 -nvkmsnosmooth
           amfi_get_out_of_my_way=0x1 amfi=0x80 ipc_control_port_options=0
           nvrmsettle=10000

(1401 left ResizeGpuBars at the installer-safe -1 rather than 13; on Turing this likely makes no difference per the discussion in #183, since Turing has no Resizable BAR support to move BAR1 off the boot screen regardless of this setting.)

What I've already tried

  • -nvrmnoflip: added to boot-args, cold boot with USB-C monitor attached — no change, same crash loop.
  • Confirmed the internal-panel-only boot (no monitor attached at power-on) is 100% reliable on the same EFI/config.
  • Confirmed hot-plugging after a working boot does not bring up the external display (separate from the above).
Written by you

It's in my interest to help extend support for this driver, so I'm sharing what I found in case it's useful. The analysis was done with AI assistance.

Dominant language
Rust
Stars
2.5k
Forks
233
Avg merge
3d 14h
Merged PRs (30d)
14

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 nullmoth/nvidia-macos-driver

All issues in nullmoth/nvidia-macos-driver

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.