Re: Linux process causes kernel panic

On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov <kostikbel_at_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.