Date: Sun, 20 Sep 2020 22:55:26 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: rhurlin@freebsd.org Cc: Hans Petter Selasky <hps@selasky.org>, monochrome <monochrome@twcny.rr.com>, freebsd-current@freebsd.org Subject: Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X Message-ID: <20200920195526.GH94807@kib.kiev.ua> In-Reply-To: <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de> References: <69ff9432-fc8f-b0ab-8ad2-8e3daa77f8e1@twcny.rr.com> <1a88773b-d2fa-a790-c7e2-868d3884ba8b@twcny.rr.com> <865D6BF0-9F1E-4125-81D3-FB9A369FED8D@gwdg.de> <88af31d4-9ed9-172a-d48f-1780f19841e3@twcny.rr.com> <11d27d41-029a-d7f5-eccc-0ba3a3fcfe97@gwdg.de> <b6d7aa27-948a-b820-76b9-1f91a1df0471@selasky.org> <2bbfb4b3-92e9-b3ca-9c31-6c513cee2f2d@gwdg.de> <20200920093814.GD94807@kib.kiev.ua> <0249197f-29f6-4df4-eb63-ca786aaea39d@gwdg.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> >>> On 2020-09-20 10:05, Rainer Hurling wrote:
> >>>> Hi monochrome,
> >>>>
> >>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
> >>>> with newest sources the error occurs.
> >>>>
> >>>> After looking around somewhat more, I found some hints about Virtualbox
> >>>> kernel module having problems with r365488. Unfortunately, I am not able
> >>>> to find the thread again :(
> >>>>
> >>>> What seems to help as a workaround is to disable the loading of
> >>>> VirtualBox in /boot/loader.conf
> >>>>
> >>>> #vboxdrv_load="YES"
> >>>>
> >>>> and in /etc/rc.conf
> >>>>
> >>>> #vboxnet_enable="YES"
> >>>> #vboxguest_enable="YES"
> >>>>
> >>>>
> >>>> So probably, this page fault is not restricted to AMD Ryzen?
> >>>>
> >>>
> >>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
> >>> version was not bumped correctly.
> >>>
> >>> --HPS
> >>>
> >>
> >> Thanks for the hint. But I did rebuild all kernel modules before
> >> rebooting, in my case vbox*.ko, nvidia*.ko.
> >
> > Provide backtrace of the panic.
> >
>
> Hi Konstantin,
>
> Thanks for your response.
>
> After trying several ways to produce a core dump or a working kdb prompt
> without success, all I can offer is the following screen contents. I
> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
> via /boot/loader.conf and /etc/rc.conf as described above:
>
>
> [..snip..]
> procfs registered
> modulte_register_init: MOD_LOAD (tmpfs, 0xffffffff80caa060,
> 0xffffffff82520a70) error 17
> Timecounters tick every 1.000 msec
> lo0: bpf attached
> vlan: initialized, using hash tables with chaining
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 31; apic id = 1f
> fault virtual address = 0x0
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0xffffffff80ea889b
> stack pointer = 0x20:0xffffffff826017e0
> frame pointer = 0x20:0xffffffff826017e0
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 0 (swapper)
> trap number = 12
> panic: page fault
> cpuid = 31
> time = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xffffffff82601490
> vpanic() at vpanic+0x182/frame 0xffffffff826014e0
> panic() at panic+0x43/frame 0xffffffff82601540
> trap_fatal() at trap_fatal+0x387/frame 0xffffffff826015a0
> trap_pfault() at trap_pfault+0x97/frame 0xffffffff82601600
> calltrap() at calltrap+0x8/frame 0xffffffff82601710
> --- trap 0xc, rip = 0xffffffff80ea889b, rsp = 0xffffffff826017e0, rbp =
> 0xffffffff826017e0 ---
> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0xffffffff826017e0
> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0xffffffff82601830
> vm_fault() at vm_fault+0x5d6/frame 0xffffffff82601940
> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0xffffffff826019f0
> vm_map_wire() at vm_map_wire+0x6b/frame 0xffffffff82601a20
> rtR0MemObjFreeBSDAllocHelper() at
> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0xffffffff82601a70
> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
> 0xffffffff82601ac0
> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xffffffff82601b60
> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xffffffff82601bd0
> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
> 0xffffffff82601bf0
> module_register_init() at module_register_init+0xbd/frame 0xffffffff82601c20
> mi_startup() at mi_startup+0xec/frame 0xffffffff82601c70
> btext() at btext+0x2c
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at kdb_enter+0x37: movq $0,0x10b5796(%rip9
> db>
>
>
> The system freezes at this point, no core dump is generated ;) This
> does not happen without loading VBoxDrv.
>
> At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope,
> this is of some help.
>
Yes it seems to be enough for me to see where the possible issue is.
Try this patch, I did not even compiled it. Probably you need to put
it into ports/emulators/virtualbox-ose-kmod/files with the name ending
with .patch.
--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.xxx 2020-09-20 19:40:07.471956776 +0000
+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2020-09-20 19:46:03.606966773 +0000
@@ -323,7 +323,8 @@
size_t cPages = atop(pMemFreeBSD->Core.cb);
int rc;
- pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages);
+ pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
+ pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
/* No additional object reference for auto-deallocation upon unmapping. */
#if __FreeBSD_version >= 1000055
@@ -457,7 +458,8 @@
return VERR_NO_MEMORY;
}
- pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb));
+ pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, cb, VM_PROT_ALL,
+ 0, curthread->td_ucred);
if (PhysHighest != NIL_RTHCPHYS)
VmPhysAddrHigh = PhysHighest;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200920195526.GH94807>