On 22.09.20 07:51, monochrome wrote: > Rainer, I'm all up and running and clean with the latest again, if it > still doesn't work after your next try, send me your step-by-step to > patch and i'll try it here. I'm using ryzen video so I have to disable > stuff to even see the fault messages.
Hi monochrome, The attached file is the patched version, I put in the files dir of emulators/virtualbox-ose (the main port, not the kernel modules one). Then I rebuilt and reinstall the ports mulators/virtualbox-ose-kmod and mulators/virtualbox-ose and rebooted the box. In my case, the boot process freezes after the page fault messages. > > On 9/22/20 1:06 AM, Rainer Hurling wrote: >> Am 22.09.20 um 00:13 schrieb Konstantin Belousov: >>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 31; apic id = 1f >>>> fault virtual address = 0x25407efa >>> This address is very suspicious. >>> >>> I cannot claim it as the fact, but most likely cause for such garbage >>> pointer value is mismatched ABI between kernel and module. In other >>> words, the module was built against headers from different kernel. >> >> Hmm, thanks for the pointer. I will double check this evening and >> reporting back. >> >> Normally, this module should have been built and installed with the >> kernel build. >> >>> >>>> fault code = supervisor read data, page not present >>>> instruction pointer = 0x20:0xffffffff80ec0b63 >>>> stack pointer = 0x28:0xffffffff826018b0 >>>> frame pointer = 0x28:0xffffffff82601940 >>>> 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 >>>> 0xffffffff82601560 >>>> vpanic() at vpanic+0x182/frame 0xffffffff826015b0 >>>> panic() at panic+0x43/frame 0xffffffff82601610 >>>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff82601670 >>>> trap_pfault() at trap_pfault+0x97/frame 0xffffffff826016d0 >>>> trap() at trap+0x2ab/frame 0xffffffff826017e0 >>>> calltrap() at calltrap+0x8/frame 0xffffffff826017e0 >>>> --- trap 0xc, rip = 0xffffffff80ec0b63, rsp = 0xffffffff826018b0, rbp = >>>> 0xffffffff82601940 --- >>>> vm_map_insert() at vm_map_insert+0x2f3/framw 0xffffffff82601940 >>>> vm_map_find() at vm_map_find+0x4a4/frame 0xffffffff82601a00 >>>> rtR0MemObjFreeBSDAllocHelper() at >>>> rtR0MemObjFreeBSDAllocHelper+0x96/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,0x10b5616(%rip) >>>> db> >>>> >>>> >>>> Perhaps this gives some more insight into the problem? I can't assess, >>>> sorry. >> _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
