Date: Tue, 17 Nov 2020 23:01:06 -0500 From: Mark Johnston <markj@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Johan Hendriks <joh.hendriks@gmail.com>, freebsd-current@freebsd.org Subject: Re: Samba kernel panics. Message-ID: <X7ScgudrWey7f9Ur@raichu> In-Reply-To: <X7QUICQLn1tBuezi@kib.kiev.ua> References: <aa73213c-eb10-d984-f770-46601b7a1a9d@gmail.com> <X7QUICQLn1tBuezi@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 17, 2020 at 08:19:12PM +0200, Konstantin Belousov wrote: > On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote: > > Hello all after updating FreeBSD13 from r367724 to r367755 my samba server > > craches the server. > > I did rebuild samba 4.11 but that does not help. > > > > The output on the console is the following. > > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3; apic id = 06 > > fault virtual address = 0x803a122b8 > > fault code = supervisor read instruction, protection > > violation > > instruction pointer = 0x20:0x803a122b8 > > stack pointer = 0x28:0xfffffe0127733a50 > > frame pointer = 0x28:0x803a122b0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = 17340 (smbd) > > trap number = 12 > > panic: page fault > > cpuid =3 > > time = 1605632521 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame > > 0xfffffe0127733700 > > vpanic() at vpanic+0x182/frame 0xfffffe0127733750 > > panic() at panic+0x43/frame 0xfffffe01277337b0 > > trap_fatal() at trap_fatal+0x387/frame 0xfffffe0127733810 > > trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0127733870 > > trap() at trap+0x27d/frame 0xfffffe0127733980 > > calltrap() at caltrap+0x8/frame 0xfffffe0127733980 > > --- trap 0xc, rip = 0x803a122b8, rsp = 0xfffffe0127733a50, rbp = 0x803a122b0 > > --- > > KDB: enter: panic > > [ thread pid 17340 tid 101772 ] > > stopped at kdb_enter+0x37: movq $0,0x1fa9446(%rip) > > db> > > This looks like SMEP catching an issue, but it is not clear why. Probably fixed by r367783? The bug would have partially overwritten the stack frame, resulting in a jump to a user address after a return. > Did you clean rebuild of the kernel ? > > What filesystems types do you use ? > > Can you bisect ? I would actually suspect not clean rebuild after recent > changes to kern_event.c.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X7ScgudrWey7f9Ur>