Date: Fri, 3 Aug 2018 23:42:50 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Johannes Lundberg <johalun0@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Linux process causes kernel panic Message-ID: <20180803204250.GE6049@kib.kiev.ua> In-Reply-To: <CAECmPwvAaSTimVyV1n%2B9PNKd_0JP6kLXnXyihoWEB3FHRHqa9w@mail.gmail.com> References: <CAECmPwvAaSTimVyV1n%2B9PNKd_0JP6kLXnXyihoWEB3FHRHqa9w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote: > Hi > > After install new kernel+world built from today's checkout I keep getting > the same crash over and over. Never had this problem before. The previous > kernel was from 3 weeks ago. > > Looks familiar to anyone? > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xfffe665c > fault code = supervisor write data, protection violation > instruction pointer = 0x20:0xffffffff82282db3 > stack pointer = 0x0:0xfffffe004c74c8c8 > frame pointer = 0x0:0xfffffe004c74c980 > 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 = 1579 (wcgrid_zika_vina_7.) > trap number = 12 > panic: page fault > cpuid = 0 > time = 1533327428 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe004c74c580 > vpanic() at vpanic+0x1a3/frame 0xfffffe004c74c5e0 > panic() at panic+0x43/frame 0xfffffe004c74c640 > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe004c74c690 > trap_pfault() at trap_pfault+0x62/frame 0xfffffe004c74c6e0 > trap() at trap+0x2ba/frame 0xfffffe004c74c7f0 > calltrap() at calltrap+0x8/frame 0xfffffe004c74c7f0 > --- trap 0xc, rip = 0xffffffff82282db3, rsp = 0xfffffe004c74c8c8, rbp = > 0xfffffe004c74c980 --- > futex_xchgl() at futex_xchgl+0x23/frame 0xfffffe004c74c980 > ia32_syscall() at ia32_syscall+0x29f/frame 0xfffffe004c74cab0 > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x4000001 > Uptime: 7m29s > Dumping 411 out of 8056 MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% > Dump complete Post first 40 lines from the verbose dmesg boot of your machine. I have a guess what is going on, I need the dmesg to confirm. If my guess is correct, you can use a workaround by setting the "hw.cpu_stdext_disable=0x00100000" tunable at the loader prompt for now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180803204250.GE6049>