From nobody Sat Jun 19 03:03:59 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 A3EB311E31CF for ; Sat, 19 Jun 2021 03:04:02 +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 4G6LGp1SZHz4RL7; Sat, 19 Jun 2021 03:04:01 +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 84C5389249; Fri, 18 Jun 2021 20:03:59 -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: Fri, 18 Jun 2021 20:03:59 -0700 From: Neel Chauhan To: Neel Chauhan Cc: Mark Johnston , 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: <389e4560afdc211e9915746b11a0d0d0@FreeBSD.org> References: <8bd27c2a72ebfa9299bca7d930297faf@FreeBSD.org> <389e4560afdc211e9915746b11a0d0d0@FreeBSD.org> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <61de965123274866935935bded6c3d58@FreeBSD.org> X-Sender: nc@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G6LGp1SZHz4RL7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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@)