Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455

Hi Mark,

On 2021-06-18 06:57, Mark Johnston wrote:
> That seems surprising, since the vm_page_grab() call should return the
> page at pidx if one exists.

I believe that's not the case. I did pringfs

>> Any hints on where the physical address is? Should we have an
>> FreeBSD-specific "pa" argument for the physical address if it's 
>> needed?
> 
> I'm not sure.  I'll just note that the Linux code appears to be trying
> to map a set of pages belonging to a scatter-gather list.  Taking the
> physical address of the first page and assuming that all subsequent
> pages are physically contiguous doesn't seem correct, but this is what
> is happening in that loop, since each iteration simply increments pa by
> PAGE_SIZE.

Based on this email and our private one, and prior debugging it seems 
this panic comes on the first iteration. Something must be

vm_page_grab() returns NULL, and then we run:

	if (!vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL))
		goto retry;
	if (vm_page_insert(m, vm_obj, pidx)) {
		vm_page_xunbusy(m);
		VM_OBJECT_WUNLOCK(vm_obj);
		vm_wait(NULL);
		VM_OBJECT_WLOCK(vm_obj);
		goto retry;
	}

Source: 
https://github.com/neelchauhan/drm-kmod/blob/d0eee96973ee0772e977b813678f92c5becf0507/drivers/gpu/drm/i915/intel_freebsd.c#L245

The first if() doesn't panic, but we panic at the second one, it doesn't 
go into or jumo over the statement.

I could use for() or for_each_sg_page() and they both panic.

I am almost feeling I'd have to hire a FreeBSD kernel consultant and/or 
sell my TigerLake laptop for an AMD Ryzen-based laptop.

-Neel (nc@)