Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
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@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On Tue, Jun 15, 2021 at 08:36:07PM -0700, Neel Chauhan wrote: > Hi current@, > > First off, sorry if I spammed developers@ and other mailing lists with > my previous message, and to bz@/hselasky@/manu@ sent so many duplicate > emails. > > Right now, I am attempting to update the drm-kmod driver to the Linux > 5.7 code, and am having an issue with the pmap lock. I am new-ish to the > kernel, meaning not a whole lot of "experience", but do have patches in > src. > > But like it not we need kernel newbies, they're the next generation of > experts. If we don't, we'd be the next Minix with **zero** development > since Tanenbaum retired. > > Going back, the code in question is here: > https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L346 > > The lines important are 346-356, but lines of interest are also the > non-"#ifdef __linux__" sections of vm_fault_cpu(). > > The code gives this error: panic: Assertion > vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455 > > I have attached the core dump log. > > To those who aren't graphics driver experts, it happens when I load Xorg > when Xorg attempts to map the I/O to userspace. But I feel this is more > of me not using page locks correctly (which is needed for the pmap), or > maybe a linuxkpi issue, rather than a graphics-specific issue. > > I spent days on this (all my non-$DAYJOB hours at one point + all my > weekends) and haven't figured out the locks completely. Does anyone have > suggestions to what I'm doing wrong in my code and locks? > > If it is important, OpenBSD's version of this code is here: > https://github.com/openbsd/src/blob/2207c4325726fdc5c4bcd0011af0fdf7d3dab137/sys/dev/pci/drm/i915/gem/i915_gem_mman.c#L459 > > (lines 459-523, but some calls are unsurprisingly different). > 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. 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.
Re: akonadiconsole and SQL 57
On Wednesday, June 16, 2021 6:17:50 PM CEST Lizbeth Mutterhunt, Ph.D wrote: > hi people, > > first at the moment I have to short-cut my web as not at home and > /etc/rc.conf doesn't take my wlan0 interface; I changed rooter IP to > 192.168.8.1 and edited /etc/wpa_supplicant.conf. but still at booting the > field with the web stays "". I have mysql at startup. after recent update > on my grandmas notebook I have problems with loading kmail. > > Here's an excerpt of kmail start: > org.kde.pim.akonadiserver: Running DB initializer > org.kde.pim.akonadiserver: DB initializer done > Connecting to deprecated signal > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) > Assertion failed: (param->buffer_length != 0), function There was a workaround posted here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255748#c16
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
Hi Neel,
On 6/16/21 5:28 PM, Neel Chauhan wrote:
Hi,
On 2021-06-16 00:35, Hans Petter Selasky wrote:
Do you have the full backtrace?
Yes.
I have attached a stack trace in the previous email, but if you didn't
get it, I have uploaded it to GitHub:
https://gist.github.com/neelchauhan/437bd10239f84c563aafb37ab440029a
Doesn't this code work in the current DRM - kmod? What changed? Did
you perhaps miss a patch?
I think there is new code with Linux 5.6 which changes how this is done.
I have been attempting to make a FreeBSD equivalent, but it panics. It
is **not** from missing Linux commits since I believe I added them all.
The code in my GH repo:
https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L346
I think the following changes are needed. CC'ing Jeff.
for_each_sg_page(pages->sgl, _iter, pages->nents, 0) {
pmap_t pmap = vm_map_pmap(map);
struct vm_page *pa = sg_page_iter_page(_iter);
VM_OBJECT_RLOCK(pa->object);
Try adding this:
vm_object_busy(pa->object);
if (pmap_enter(pmap, va, pa, 0, flags, 0)) {
Try adding this:
vm_object_unbusy(pa->object);
VM_OBJECT_RUNLOCK(pa->object);
err = -ENOMEM;
break;
}
Try adding this:
vm_object_unbusy(pa->object);
VM_OBJECT_RUNLOCK(pa->object);
va += PAGE_SIZE;
--HPS
akonadiconsole and SQL 57
hi people, first at the moment I have to short-cut my web as not at home and /etc/rc.conf doesn't take my wlan0 interface; I changed rooter IP to 192.168.8.1 and edited /etc/wpa_supplicant.conf. but still at booting the field with the web stays "". I have mysql at startup. after recent update on my grandmas notebook I have problems with loading kmail. Here's an excerpt of kmail start: org.kde.pim.akonadiserver: Running DB initializer org.kde.pim.akonadiserver: DB initializer done Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Assertion failed: (param->buffer_length != 0), function setup_one_fetch_function, file /wrkdirs/usr/ports/databases/mysql57-client/work/mysql-5.7.34/libmysql/libmysql.c, line 4112. QSocketNotifier: Invalid socket 6 and type 'Read', disabling... KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = akonadiserver path = /usr/local/bin pid = 5695 KCrash: Arguments: /usr/local/bin/akonadiserver KCrash: Attempting to start /usr/local/lib/libexec/drkonqi akonaditest: org.kde.pim.akonadiserver: Failed to connect to database! org.kde.pim.akonadiserver: Database error: "Can't connect to local MySQL server through socket '/var/run/user/1001/akonadi/mysql.socket' (2) QMYSQL: Unable to connect" org.kde.pim.akonadiserver: Shutting down AkonadiServer... when reopening the akonadi-console I don't get a connection to PAM and can't enter my password. User 1001 doesn't exist, maybe SQL group? I had a quite similiar problem one update before in march from sql-client and sql-to be solved with a simple Q in [MYSQL] the local SQL-config; but this time it is much more trickier. any help? lizbeth
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
Hi, On 2021-06-16 00:35, Hans Petter Selasky wrote: Do you have the full backtrace? Yes. I have attached a stack trace in the previous email, but if you didn't get it, I have uploaded it to GitHub: https://gist.github.com/neelchauhan/437bd10239f84c563aafb37ab440029a Doesn't this code work in the current DRM - kmod? What changed? Did you perhaps miss a patch? I think there is new code with Linux 5.6 which changes how this is done. I have been attempting to make a FreeBSD equivalent, but it panics. It is **not** from missing Linux commits since I believe I added them all. The code in my GH repo: https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L346 --HPS -Neel (nc@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On 6/16/21 5:36 AM, Neel Chauhan wrote: Hi current@, First off, sorry if I spammed developers@ and other mailing lists with my previous message, and to bz@/hselasky@/manu@ sent so many duplicate emails. Right now, I am attempting to update the drm-kmod driver to the Linux 5.7 code, and am having an issue with the pmap lock. I am new-ish to the kernel, meaning not a whole lot of "experience", but do have patches in src. But like it not we need kernel newbies, they're the next generation of experts. If we don't, we'd be the next Minix with **zero** development since Tanenbaum retired. Going back, the code in question is here: https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L346 The lines important are 346-356, but lines of interest are also the non-"#ifdef __linux__" sections of vm_fault_cpu(). The code gives this error: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455 I have attached the core dump log. To those who aren't graphics driver experts, it happens when I load Xorg when Xorg attempts to map the I/O to userspace. But I feel this is more of me not using page locks correctly (which is needed for the pmap), or maybe a linuxkpi issue, rather than a graphics-specific issue. I spent days on this (all my non-$DAYJOB hours at one point + all my weekends) and haven't figured out the locks completely. Does anyone have suggestions to what I'm doing wrong in my code and locks? If it is important, OpenBSD's version of this code is here: https://github.com/openbsd/src/blob/2207c4325726fdc5c4bcd0011af0fdf7d3dab137/sys/dev/pci/drm/i915/gem/i915_gem_mman.c#L459 (lines 459-523, but some calls are unsurprisingly different). Hope you all can help. Hi, Do you have the full backtrace? Doesn't this code work in the current DRM - kmod? What changed? Did you perhaps miss a patch? --HPS
