Date: Sat, 4 Aug 2018 13:12:17 +0100 From: Johannes Lundberg <johalun0@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Linux process causes kernel panic Message-ID: <CAECmPwt0kifzPFpgyYWJj7UvnUn2CGjUfQz2tuS5G0BYttTkZQ@mail.gmail.com> In-Reply-To: <20180803204250.GE6049@kib.kiev.ua> References: <CAECmPwvAaSTimVyV1n%2B9PNKd_0JP6kLXnXyihoWEB3FHRHqa9w@mail.gmail.com> <20180803204250.GE6049@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov <kostikbel@gmail.com> wrote: > 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. > No panic over night with that tunable so it seems you're on the right track.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAECmPwt0kifzPFpgyYWJj7UvnUn2CGjUfQz2tuS5G0BYttTkZQ>