Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

RTX 2060 SUPER (TU106, 10DE:1F06) on Ryzen 5 5600 / A520: desktop works on 1.9.0, but ~56% of dirty-surface updates are refused and windows show black boxes on redraw

Open
  • Is something wrong?
#92 3 comments 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
20/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
operating-systems

Research direction

Start with the related issues #75 and #78 and the reported surfvram dirty refusal and imported-host-pointer errors; the issue does not name source files or tests. First determine whether the refusal rate is expected on small-BAR Turing hardware and whether a setting can avoid it. Done means establishing the cause and a supported workaround or fix; logs are available on request.

Written by the indexing model from the issue text.

Description

Hardware: RTX 2060 SUPER (TU106, 10DE:1F06), Ryzen 5 5600, MSI A520M-A PRO, Above 4G + ReBar enabled in BIOS, CSM off. macOS 15.8.1, OpenCore REL-109, SMBIOS iMacPro1,1, driver 1.9.0 via 1401 app, one 1080p@60 display.

Works: accelerated desktop (Metal 3, 8 GB VRAM), BAR1 256 MB, Night Shift and wallpaper render correctly.

Problem: occasional black boxes when content updates (window raise/lower, mouse movement). Kernel log shows more than half of dirty-surface updates being refused, with the count still growing:

NVAccel: surfvram dirty: surface N plane 0 type 0xc0 -> ... (dirty 55001, refused 31015)
NullMoth: surface N dirty refused (0x...) - copy-out
NullMoth: item 7: surface 4 plane 0: family VRAM import refused (-1000072003) - private image + copies
NullMoth: vk: vkAllocateMemory refused the imported host pointer 0x... (66355200 bytes, memory type 2)
NullMoth: reflection: GPUPass has no AIR - cannot be reflected

Also seen: hw vblank on head 0: REFUSED by NVKMS - timer stays; Unable to program runlist for CE0 then copy queue on a graphics channel; LOCAL+mapped memory -> system RAM.

Earlier boots, same hardware/BIOS: 1.0.8 never published the framebuffer (busy timeout 'NVRM', WindowServer crash loop). 1.9.0 once logged BAR1 = 64 MB and then dmaAllocMapping_GM107: can't alloc VA space / NV_ERR_NO_MEMORY (black screen). I don't know why BAR1 later became 256 MB. -nvrmnoflip made no difference.

Question: is the high surfvram dirty refusal rate expected on small-BAR Turing, and is there a setting to avoid it?

Related: #75, #78. Logs on request.

Dominant language
Rust
Stars
2.5k
Forks
233
No merged PRs in 30d

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.