Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

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.
>>