[irc] <bsdimp_> they are both pci_dev
[irc] <bsdimp_> 1eaaada457d6 adds to the middle of irq_ent. I've not chased it down, but it looks linuxkpi internal
[irc] <bsdimp_> so maybe it could too.
[irc] <bsdimp_> 3a606aadf2e7 is another that can move items to the end.
[irc] <bsdimp_> 10235ad0567f looks harder.
[irc] <bsdimp_> I could come up with a patch for the first 4 I think would work, but don't know about the last one.
[irc] <bsdimp_> wulf7 would you be interested in testing that patch? Or do you think it's too crazy a train to try to ride?
[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