[irc] <bsdimp_> 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 things.
[irc] <bsdimp_> I run -current on my laptop and it would be some significant pain
[irc] <bsdimp_> 10235ad0567f calls different things now, so I kinda understand it as well, but not what to do.
wulf7 would you be interested in testing that patch? Or do you think it's too crazy a train to try to ride?
I will be mostly AFK until sunday. With no access to 13-STABLE. Can smoke-test any patches after than as I am not 13-STABLE user too. I just made external USB 2.0 HDD and installed subj onto it to test. This HDD is ridiculousy slow but is useable
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