From nobody Thu Jun 17 05:16:56 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6528A11CD861 for ; Thu, 17 Jun 2021 05:17:00 +0000 (UTC) (envelope-from nc@FreeBSD.org) Received: from rainpuddle.neelc.org (locks.neelc.org [IPv6:2602:fed2:7106:25ff::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G59K825g3z3GyR; Thu, 17 Jun 2021 05:16:59 +0000 (UTC) (envelope-from nc@FreeBSD.org) Received: from mail.neelc.org (locks.neelc.org [IPv6:2602:fed2:7106:25ff::1]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 0EAE689171; Wed, 16 Jun 2021 22:16:57 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Wed, 16 Jun 2021 22:16:56 -0700 From: Neel Chauhan To: Mark Johnston Cc: current@freebsd.org Subject: Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455 In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.11 Message-ID: <8bd27c2a72ebfa9299bca7d930297faf@FreeBSD.org> X-Sender: nc@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G59K825g3z3GyR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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. Any hints on where the physical address is? Should we have an FreeBSD-specific "pa" argument for the physical address if it's needed? Sorry for the kernel newbie questions. -Neel (nc@)