Can confirm this fixes the reported panic, thanks! Tested xfce and KDE can survive repeated restarts. fwiw this looks and seems reasonable to me but you'll want someone who knows vm code properly to sign off too.

Can confirm that vm_fault proposal also works to prevent the panic.

Also, I think the fault is for read access because the fault_flags do not contain write like you mentioned (vm_fault_trap). The fault is originating from the Xorg process although I'm not sure what the userspace stack is.

It's coming from vm_fault_populate. Here's the core.txt output: https://pastebin.com/ajLGGr9m

To clarify, this is my best guess for how to fix this but am very open to suggestions if this is not a good approach. I also confirmed that with this patch meteorlake graphics work properly, it does indeed resolve the panic. From my testing it seems things are fine, this seems like a solid strategy to ensure proper semantics, but I'm open to alternative suggestions for how to fix this. My theory is that normally this path is happening for unmanaged memory local to a specific device, but because the memory in this case is sysmem it is managed and PG_M does not get forced on earlier in this function.

The capitalization we normally use is NVIDIA, at least these days. I believe all of our official docs follow that but there's plenty of people who don't and it's not that big of a deal. I would recommend "NVIDIA".

We can definitely import this into the official driver

+kbowling (mentor)

+kbowling (mentor) to confirm I can submit this myself.

Thanks, updated.

+1 to including nvidia-drm for consistency, although I think since it's dependent on the others it will fail to load as-is.

Thanks, I think this seems reasonable to me but we probably want to give time for others to sign off on the new approach as well.

Thanks for implementing this. I'm hopeful it will help detect issues earlier, let users more easily consume the latest drivers, and avoid having to do large (550 -> 570) upgrades.

Thanks, I think this seems reasonable now.

The Op want to use 525.78.01 for compatibility with a specific Linux application (here, ComfyUI) and it requires Linux version of libnvidia-egl-wayland.so.1.1.10

Thanks for updating. Sorry I had it on my todo list to look up where to do this for you, but seems you've figured it out anyway.

I think a better idea would be to adjust the patch I made for disabling GSP. That patch was pretty heavy handed and turned off a global which enabled GSP. I think instead we could make the patch default only the sysctl value to zero, disabling GSP by default but allowing users to enable it by setting the tunable in loader.conf. That would prevent us from having to have a build option and prevent users from having to compile things themselves.

@kbowling can you please confirm this is good for me to merge?

LGTM but shouldn't the other nvidia-drm-*-kmod ports also have this updated?

The suspend issue comes from nv_alias_pages not being implemented in our FreeBSD layer. Unfortunately when I resolve that there are still a few issues that GSP encounters when resuming, so I think the best course of action is to disable GSP by default until the issues are resolved.

Thanks, good catch on the revision. Bumped it now.

I don't think Fixes is a good fit for that but I did include the commit hash of the 570 bump to document the previous change.

You want a Fixes tag in this commit? Or are you saying in the future commit that removes this? I don't think putting a Fixes tag in this commit makes sense, this commit doesn't contain a fix it only documents a workaround.

The suspend/resume breakage was found after this commit, it wasn't something known before committing or else it would not have landed.

@grahamperrin so this "failed to allocate memory" issue happens when you are using displays connected through the HP display dock? Does it ever happen when you are just using the monitors directly connected to the NVIDIA card? Is this a laptop? Those docks have always given me all kinds of problems, the thinkpad dock I have likes to turn one particular monitor of mine off and on randomly.

Still LGTM, thanks

Looks good, thanks

Aside from the one note about the fbdev comment this looks good to me, thanks.

+mentor and also manu to double check everything looks compatible with the new drm-66-kmod.

So the stock MODULE_PNP_INFOs do handle structures such as that, I guess the problem is we don't use them for ACPI things. from the manpage:

static struct my_pciids {
               uint32_t devid;
               const char *desc;
       } my_ids[] = {
               { 0x12345678, "Foo bar" },
               { 0x9abcdef0, "Baz fizz" },
       };

Curious your opinions on this. Maybe I'm misreading the pnp code but it looks like we have been handing it the wrong format and it thinks it's a list of strings when it isn't.

No worries, thanks for submitting a fix.

I'm not in the wireless group but I suppose I could be. I also lurk in the kernel/desktop/gaming channels in the freebsd discord if you use that, feel free to ping or email me.