Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Sep 2017 09:43:07 -0700
From:      Pete Wright <pete@nomadlogic.org>
To:        Nils Beyer <nbe@renzel.net>, freebsd-x11@freebsd.org
Subject:   Re: drm-next-kmod panic
Message-ID:  <0d085613-cb55-c2e3-142f-93fc4fe388df@nomadlogic.org>
In-Reply-To: <fbc06fc9-a839-96e1-69ef-1603bbdefcea@renzel.net>
References:  <cf88383f-5f7a-9904-996e-b26d1d49bc65@alvermark.net> <69456e0e-8b97-51fd-8a65-023ecb093cfd@nomadlogic.org> <fbc06fc9-a839-96e1-69ef-1603bbdefcea@renzel.net>

next in thread | previous in thread | raw e-mail | index | archive | help


On 09/05/2017 08:10, Nils Beyer wrote:
> On 08/31/2017 19:09, Pete Wright wrote:
>> if there is no core in /var/crash you can try adding this sysctl knob 
>> which may increase the probability of capturing a core for analysis:
>
> Same problem - but I have a crash dump; here's a partial text portion:
> -------------------------------------------------------------------------------------- 
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x20
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff8280ddba
> stack pointer           = 0x28:0xfffffe0117fcf7e0
> frame pointer           = 0x28:0xfffffe0117fcf840
> 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 (linuxkpi_short_wq_2)
> trap number             = 12
> panic: page fault
> cpuid = 0
> time = 1504630325
> KDB: stack backtrace:
> #0 0xffffffff80abecf7 at kdb_backtrace+0x67
> #1 0xffffffff80a7b0bc at vpanic+0x19c
> #2 0xffffffff80a7af13 at panic+0x43
> #3 0xffffffff80efc18d at trap_fatal+0x34d
> #4 0xffffffff80efc1e9 at trap_pfault+0x49
> #5 0xffffffff80efba39 at trap+0x2a9
> #6 0xffffffff80edf0d1 at calltrap+0x8
> #7 0xffffffff8291cc44 at intel_fbdev_initial_config+0x14
> #8 0xffffffff82870957 at async_run_entry_fn+0x27
> #9 0xffffffff828641a0 at linux_work_fn+0xe0
> #10 0xffffffff80ad0667 at taskqueue_run_locked+0x147
> #11 0xffffffff80ad1848 at taskqueue_thread_loop+0xb8
> #12 0xffffffff80a3e4b5 at fork_exit+0x85
> #13 0xffffffff80edf6be at fork_trampoline+0xe
> Uptime: 6s
> Dumping 314 out of 3929 
> MB:..6%..11%..21%..31%..41%..51%..62%..72%..82%..92%
> -------------------------------------------------------------------------------------- 
>
>
> Shall I open a bug report?
>

I've filed this ticket in the drm-next Github project (I am running into 
this issue as well):
https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/173

what is confusing to me is that i have been running drm-next 
world+kernel for ages without issues, so i suspect something is 
happening with how the modules are created via ports/pkgs versus when i 
buildworld/installworld on my systems.

-p

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0d085613-cb55-c2e3-142f-93fc4fe388df>