In D60130#1392694, @ashafer wrote:

Overall I think the direction is reasonable, outside of one suggestion on tracking attrs. @oleglelchuk_gmail.com could you please clarify how you tested just this change? There's a lot of verbose LLM generated notes in the test plan and it's hard to tell if you tested this change in isolation or with other local changes applied.

In D59481#1385248, @adrian wrote:

@oleglelchuk_gmail.com did you test https://reviews.freebsd.org/D59883 instead of this diff? did it help at all?

It's been almost a week since I applied the patch. I haven't experienced any shutdown/restart hangs since I did it.

With a vanilla kernel/vanilla drm-kmod, I reproduced the ownership bug on the computer whose GPU is Intel UHD 620. It's a 9-year-old GPU. It means you don't need to own something that came out relatively recently to encounter the bug.

I have replaced the uploaded diff with a git diff -U9999 version so the complete contents of every changed file are available, as requested. The LLM verified that the full-context diff produces exactly the same source tree as the previous upload and reverses to the same base. This update changes context only; it makes no code changes.

I have replaced the uploaded diff with a git diff -U9999 version so the complete contents of every changed file are available, as requested. The LLM verified that the full-context diff produces exactly the same source tree as the previous upload and reverses to the same base. This update changes context only; it makes no code changes.

I have separated the additional vmap lifetime handling into D60130 so it can be reviewed independently of my PFN ownership implementation and the drm-kmod changes. The LLM added a per-page table, compatible-mapping references and rejection of conflicting requests. The general patch still relies on the page owner to coordinate mappings outside this bookkeeping; it is not a replacement for FreeBSD's native page-ownership contract.

The LLM fixed additional bugs, such as stale VM map-entry access, retries while holding busy pages, and unsafe cache-attribute changes in the earlier PFN implementation.

I have some new results, but I am still confused about how D59436 in its original form relates to the GPU problems on my Meteor Lake machine. Could you help clarify its scope and a mapping-lifetime concern?

I have re-uploaded the same fix using git diff --full-index -U9999, so the complete linux_work.c context is available. I also changed the edit policy from Administrators to All Users (logged-in users), so other developers can adjust the reviewers.

In D59481#1374253, @ziaee wrote:

(I may not be following, please excuse me if my assessment is incorrect)
Please stop this.
If you don't know what is going on in the patch, and cannot explain it, and use many words, also the patch is large, it is not useful and hurts.

Please file a bug report concisely explaining, in your own words, what you are observing, and what you expect to see instead.
Here are some instructions to get you started: https://freebsdfoundation.org/our-work/journal/browser-based-edition/embedded-2/writing-effective-bug-reports/

I have uploaded a new standalone patch against FreeBSD main 46d383af0dbdb3871354f344b9c1ba99da691121:

I have uploaded a replacement standalone patch based on FreeBSD main eca31490322f181a415c14c6bf03e656e81fb4aa, pinned on September 19. The exact patch file is

The technical language that you guys are using is above my head. I take it that you guys now understand the nature of the bug, so I'll just move out of your way and let you fix it. Thank you in advance for the fix! I don't understand though why no one else reported the bug before I did it myself: doesn't a regular Joe who uses Sway/Plasma often want to download files over his home LAN without changing the default "automatically sized ZFS ARC" setting first? He doesn't need to change this setting because he has no idea in the first place it needs to be changed.

Not quite. Since my last comment, I reproduced the hang with an unmodified
FreeBSD main GENERIC kernel at 7f8feee5ab922e6645f4061e9ca29109411aadef
and unmodified drm-kmod at 1d04976c1870bce01094b78e46c48f6eab810867.
With the LLM's assistance, I also collected a live DTrace recording. It does
not show the shrinker reclaiming pages while the GPU is actively using them.
__i915_gem_object_put_pages() refuses an object whose backing pages are
pinned. The problem is that an earlier FreeBSD PFN mmap changes the ownership
of the pages, so a later legitimate page release can destroy backing that i915
expects shmem to retain.

Let me explain what happened. I noticed a problem: when ZFS ARC was automatically sized and I started downloading multi-gigabyte files over my home LAN, eventually a recoverable GPU hang would happen on either Sway or Plasma. If, for example, I downloaded around 4 or 5 multi-gigabyte files in the automatically sized ZFS ARC environment, I would get a 100% guarantee a recoverable GPU hang would happen on either Sway or Plasma. I would have to remotely kill kwin_wayland_wrapper and kwin_wayland through ssh; otherwise, the computer wouldn't be accessible directly. Sway wouldn't block direct access, but I would still have to kill it due to such hangs. When I capped ZFS ARC and repeated the file downloading experiments, GPU hangs stopped happening, so I thought the problem was resolved. However, GPU hangs returned on Sway/Plasma when an LLM I was working with started doing computationally intensive things in this capped ARC environment. I asked the LLM to explain to me the cause of these GPU hangs, and it told me I was dealing with an ownership/bookkeeping bug which caused pages to lose access to their original backing objects and that's why these GPU hangs occurred. I asked it to fix the bug, and with the code that I later posted here, I stopped experiencing GPU hangs in either automatically sized ZFS ARC combined with file downloading situations or LLM-doing-computationally-intensive-work situations. I am not really knowledgeable about computer-related stuff, so I don't know what was going on behind the scenes when the GPU hangs occurred. Maybe a memory pressure thing indirectly triggered this ownership bug. All I know is that I encountered a bug and the LLM seems to have fixed it for me.

I tested your patch with vanilla drm-kmod today, and it didn't solve the problem that my github PR's code had solved for me. But thanks anyway for writing it.

I take it, this code fixes the problem reported here: https://github.com/freebsd/drm-kmod/pull/496 ? If it does, thank you very much for writing it! I'll test this code later.

Clarification of my earlier comment: descriptions of my own desktop experience now use the first person. The patch, technical analysis, summary and test plan remain AI-assisted and are submitted for independent maintainer review.

Because an LLM wrote the patch, summary, and test plan, you can see things such as "The user reports", instead of "I noticed" while reading all this stuff.