https://bsdimp@github.com/bsdimp/freebsd branch drm-kbi-hacks has what I think will restore KBI, but again, I don't understand why the last two break
drm-kbi-hacks along with restoring of linux_kmem_cache_free_rcu visibility (10235ad0567) allowed me to run Xorg+DE session succesfully.
on 13-STABLE with drm-kmod built on 13.0-RELEASE
[irc] <bsdimp_> I'll bump FreeBSD_versrion too
[irc] <bsdimp_> Thanks for testing! much appreciated.
[irc] <bsdimp_> I'll land it tomorrow unless someone tells me not to do so.
[irc] <bsdimp_> All it does is rebase and add the linux_kmem_cache_free_rcu symbol back.
[irc] <kbowling> he is partially receptive, at least to the kernel bits
[irc] <kbowling> although I don't know if he can do anything to deliver it
[irc] <kbowling> says the userspace stack should stay on Linux ABI which I do see some logic in
[irc] <bsdimp_> jkh has a recent mixed track record of being able to deliver on his promises, so I think your skepticism is warranted.
[irc] <bsdimp_> Presenting the same Userland api/abi as Linux likely would be an advantage.
[irc] <bsdimp_> kbowling btw, just sent an updated meeting invite. lemme know if this works out to get you repeating.
Kernel bits for basic CUDA are pretty much all there except for a small part described here: https://forums.developer.nvidia.com/t/cuda-and-nv-un-register-os-un-lock-user-pages/174678. (I have a POC patch for it, which you can test if you want.) The rest of CUDA support is provided by the nvidia-uvm kernel module, which is moderately large and will take quite a bit of work to port.
https://lists.freebsd.org/archives/freebsd-ports/2021-July/000445.html -- pkg bug deleting mesa-libs (even tho it says it's installed, i think) strikes again
maybe it'll go away with 1.17.0 tho
[irc] <bsdimp_> I assume people have seen https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257335 right?
@bsdimp looks to be for drm-devel
I just asked if they can reproduce it with the release version of mesa.
Should we just punt the PR that way then?
[irc] <manu_> it's not selected by default for mesa-devel too
But it seems, on manu, that crocus is also not the default in mesa-devel. And the hardware the submitter is using is 12 years old.
5.5-wip rarely panicked under heavy load/swapping, but the current drm-devel-kmod does not, at least there were not panics for >2 weeks (i915 0x3E9B), seems to be stable, great work.
My WARN_ON issue is not related to FreeBSD, Linux apparently is also confused by ES CPU.
[irc] <kbowling> I’m skeptical of the missing interference comment that seems like it would blow up at compile time?
[irc] <manu_> it's new in 5.6
[irc] <manu_> crocus might fall back to not use it but fails
[irc] <manu_> could be wrong though
[irc] <manu_> airlied didn't had much more info on irc this morning
[irc] <manu_> I'm not sure how that part should work
[irc] <manu_> I915_PARAM_MMAP_GTT_VERSION is 40 on both 5.5 and 5.6