On Tue, Jan 25, 2022 at 08:27:19AM +1100, Jonathan Gray wrote: > On Sun, Jan 23, 2022 at 02:40:21PM -0700, Thomas Frohwein wrote: > > On Sun, Jan 23, 2022 at 10:19:24AM +1100, Jonathan Gray wrote: > > > On Fri, Jan 21, 2022 at 03:31:14PM -0700, Thomas Frohwein wrote: > > > > On Fri, Jan 21, 2022 at 07:54:29PM +1100, Jonathan Gray wrote: > > > > > On Thu, Jan 20, 2022 at 04:08:28PM -0700, Thomas Frohwein wrote: > > > > > > On Fri, Jan 21, 2022 at 12:22:49AM +1100, Jonathan Gray wrote: > > > > > > > On Wed, Jan 19, 2022 at 11:04:26PM -0800, guent...@openbsd.org > > > > > > > wrote: > > > > > > [...] > > > > > > > > The backtrace is kinda nonsensical, showing a copyout() call > > > > > > > > with no > > > > > > > > predecessor, but maybe that's just from copy*() not setting up > > > > > > > > a proper > > > > > > > > frame? However, that's not a change. Neither has there been > > > > > > > > any change > > > > > > > > in the pmap layer in multiple months. The areas of concern IMO > > > > > > > > are DRM > > > > > > > > and (because it was the last thing mentioned) iwm, but the > > > > > > > > former seems > > > > > > > > _much_ more likely. > > > > > > > > > > > > > > Booting bsd.mp with inteldrm disabled works? > > > > > > > > > > > > yes, boots and uses llvmpipe after I disable inteldrm* > > > > > > > > > > this fixes sleeping with a mtx held found with kern.pool_debug=2 > > > > > which may help > > > > > > > > thanks, however no change after I built MP kernel and installed it. > > > > Still the > > > > same pmap error that I posted in the original bug report. > > > > > > Can you try a kernel with this diff and 'option WITNESS' uncommented > > > in sys/arch/amd64/conf/GENERIC.MP ? > > > > I built a kernel with this after updating the CVS checkout. To my > > surprise, MP kernel now boots fine and I don't see any of the WITNESS > > messages that I was expecting. Looked through dmesg, /var/log/messages, > > even Xorg.0.log. I'm positive that I built the kernel on the previous > > try and installed it correctly. I checked the dmesg at the time that it > > showed the locally built kernel and it did. > > if you revert the previous and try this does it still boot?
this would be more interesting to try corresponds to 'drm/i915: Add object locking to vm_fault_cpu' 9fa1f4785f2a54286ccb8a850cda5661f0a3aaf9 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?&id=9fa1f4785f2a54286ccb8a850cda5661f0a3aaf9 Index: sys/dev/pci/drm/i915/gem/i915_gem_mman.c =================================================================== RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_mman.c,v retrieving revision 1.7 diff -u -p -r1.7 i915_gem_mman.c --- sys/dev/pci/drm/i915/gem/i915_gem_mman.c 23 Jan 2022 22:53:03 -0000 1.7 +++ sys/dev/pci/drm/i915/gem/i915_gem_mman.c 24 Jan 2022 23:46:19 -0000 @@ -563,6 +563,9 @@ vm_fault_cpu(struct i915_mmap_offset *mm return VM_PAGER_BAD; } + if (i915_gem_object_lock_interruptible(obj, NULL)) + return VM_PAGER_ERROR; + err = i915_gem_object_pin_pages(obj); if (err) goto out; @@ -602,6 +605,7 @@ vm_fault_cpu(struct i915_mmap_offset *mm i915_gem_object_unpin_pages(obj); out: + i915_gem_object_unlock(obj); uvmfault_unlockall(ufi, NULL, &obj->base.uobj); return i915_error_to_vmf_fault(err); }
