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@)

Reply via email to