Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On 2021-06-18 12:19, Neel Chauhan wrote: 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. Good news! While I don't have a fix, I have figured out what the issue is. Apparently, the vm_start values is for some reason coming as 0 when it is passed into vm_fault_cpu(). That's why it's giving these errors: of course the address at 0 is mapped, it is (probably) used by the kernel. I will look more into it tomorrow, but my brother has come over to Seattle from Connecticut so I may not be able to dedicate as much time as I would like to. -Neel (nc@)
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@)
Re: drm-kmod kernel crash fatal trap 12
On Jun 18, 2021, at 7:05 AM, Thomas Laus wrote:
>
> On 6/10/21 11:13 AM, Bakul Shah wrote:
>> This is what I did:
>>
>> git clone https://github.com/freebsd/drm-kmod
>> ln -s $PWD/drm-kmod /usr/local/sys/modules
>>
>> Now it gets compiled every time you do make buildkernel.
>> If things break you can do a git pull in the drm-kmod dir
>> and rebuild.
>>
> That did not work for me. The buildkernel operation failed at the
> operation 'cleandir' phase. The message was 'don't know how to make
> cleandir stop'.
I suspect you are not using WITH_META_MODE=yes. That seems to obviate
the need for running cleandir though I don't how (and I don't have the
patience to wade through the complex logic in /usr/src/Makefile*).
FWIW, my build flags:
$ cat /etc/{make,src,src-env}.conf
MALLOC_PRODUCTION=yes
WITHOUT_CLANG=yes
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/usr/obj/ccache
WITH_META_MODE=yes
If you forget to "kldload filemon" make build{kernel,world} will
remind you!
Re: drm-kmod kernel crash fatal trap 12
On 6/10/21 11:13 AM, Bakul Shah wrote: > This is what I did: > > git clone https://github.com/freebsd/drm-kmod > ln -s $PWD/drm-kmod /usr/local/sys/modules > > Now it gets compiled every time you do make buildkernel. > If things break you can do a git pull in the drm-kmod dir > and rebuild. > That did not work for me. The buildkernel operation failed at the operation 'cleandir' phase. The message was 'don't know how to make cleandir stop'. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On Wed, Jun 16, 2021 at 10:16:56PM -0700, Neel Chauhan wrote: > Hi Mark, > > Thank you so much for your response! > > On 2021-06-16 14:05, Mark Johnston wrote: > > > > The function in question appears to implement a device page fault > > handler. In FreeBSD, such handlers are responsible only for ensuring > > that the requested page(s) are present in the VM object backing the > > mapping that was faulted on. The generic fault handler in > > sys/vm/vm_fault.c is responsible for actually updating the faulting > > process' page tables by calling pmap_enter(). In other words, our > > fault > > handler interface is quite different from OpenBSD's and their example > > should not be followed exactly. Adding a vm_object_busy() call in the > > loop will silence the assertion I guess but the handler is still wrong. > > Good to hear. No wonder why I still had the "blank screen of death" with > the (now previous) code. > > > If you look further down at vm_fault_gtt() (and in earlier versions of > > the DRM drivers, i915_gem_fault()), the remap_io_mapping() > > implementation in the LinuxKPI does basically what I'm describing. > > Something similar is required for vm_fault_cpu(), though I don't quite > > understand when vm_fault_cpu() is supposed to be used. > > I have some code to implement remap_io_sg() based on remap_io_mapping(), > but it's not complete. > > I am still trying to figure out how to get the physical address. Right > now, I have: > > https://github.com/neelchauhan/drm-kmod/commit/92a3d9bb585acb55c1dab9c5ed11190f7db73ecf > > My get_pfn() function (Lines 221-231) attempts to get the physical > address, and it is called at Line 248. > > Note: This code is probably incorrect, since it gives me an "page > already inserted" panic. That seems surprising, since the vm_page_grab() call should return the page at pidx if one exists. > 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.
Add support for -c to sha256sum to fix port build failures
The sha256 et.al. programs have recently been extended to provide GNU compatible features if invoked as sha256sum. This does now lead to port build issues, since there are ports that assume that the -c option is implemented and that treat an error exit of sha256sum -c as an indication of corrupted source files. I have created https://reviews.freebsd.org/D30812 as a quick attempt to provide a GNU compatible sha256sum -c feature and I'd appreciate a review this change. An alternative to adding this feature would be changes to all ports that now fail due to the assumption that sha256sum does provide that option. I could have used linked list macros, but given the simple structure I did not think the extra dependency was required here, and it does not really simplify the program, IMHO. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
