Date: Sun, 8 Dec 2019 00:09:40 +0200 From: Christos Chatzaras <chris@cretaforce.gr> To: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: kernel panic Message-ID: <6A5B8B89-31C5-4AB7-AE35-D48E93D54E66@cretaforce.gr> In-Reply-To: <CAC=ypSW4Tbx5UvhOw_eUDfzkzyG1aLxBwPTOEH_m2-CFwfvyMw@mail.gmail.com> References: <6014CAB6-4827-4D6D-B5DD-A9E901047F69@cretaforce.gr> <6C26CD72-2149-4082-BCAF-C7B846092194@cretaforce.gr> <CAC=ypSVJbgbz0jqDR3oGOZOPzM_Lr0PQC_2oAEn91XwM=0XAwA@mail.gmail.com> <F889BFFC-64C1-4BBC-94F5-800A596582D1@cretaforce.gr> <CAC=ypSW4Tbx5UvhOw_eUDfzkzyG1aLxBwPTOEH_m2-CFwfvyMw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 7 Dec 2019, at 19:44, HiMyNameIsIlNano <kappei84@gmail.com> wrote: >=20 > Il sab 7 dic 2019, 18:25 Christos Chatzaras <chris@cretaforce.gr> ha > scritto: >=20 >>=20 >>=20 >>> On 7 Dec 2019, at 19:01, Daniele Mazzotti <kappei84@gmail.com> = wrote: >>>=20 >>> Il giorno ven 6 dic 2019 alle ore 18:21 Christos Chatzaras < >>> chris@cretaforce.gr> ha scritto: >>>=20 >>>> I upload full core.txt here: >>>>=20 >>>> https://we.tl/t-AGwrZJbHYP <https://we.tl/t-AGwrZJbHYP>; >>>>=20 >>>>=20 >>>>> On 6 Dec 2019, at 18:39, Christos Chatzaras <chris@cretaforce.gr> >> wrote: >>>>>=20 >>>>> Today and yesterday I had a server crash. The server runs FreeBSD = 12.1 >>>> without the last "FreeBSD-SA-19:25.mcepsc" patch. >>>>>=20 >>>>> Today I got this: >>>>>=20 >>>>> Dec 6 18:27:18 server36.example.com kernel: Fatal trap 12: page = fault >>>> while in kernel mode >>>>> Dec 6 18:27:18 server36.example.com kernel: cpuid =3D 3; apic id = =3D 03 >>>>> Dec 6 18:27:18 server36.example.com kernel: fault virtual >> address#011=3D >>>> 0xffffffff82fb8f38 >>>>> Dec 6 18:27:18 server36.example.com kernel: fault code#011#011=3D >>>> supervisor read data, page not present >>>>> Dec 6 18:27:18 server36.example.com kernel: instruction = pointer#011=3D >>>> 0x20:0xffffffff810954b6 >>>>> Dec 6 18:27:18 server36.example.com kernel: stack pointer#011 >> =3D >>>> 0x0:0xfffffe00c3c9f600 >>>>> Dec 6 18:27:18 server36.example.com kernel: frame pointer#011 >> =3D >>>> 0x0:0xfffffe00c3c9f6b0 >>>>> Dec 6 18:27:18 server36.example.com kernel: code segment#011#011=3D= >> base >>>> 0x0, limit 0xfffff, type 0x1b >>>>> Dec 6 18:27:18 server36.example.com kernel: #011#011#011=3D DPL = 0, pres >>>> 1, long 1, def32 0, gran 1 >>>>> Dec 6 18:27:18 server36.example.com kernel: processor eflags#011=3D= >>>> interrupt enabled, resume, IOPL =3D 0 >>>>> Dec 6 18:27:18 server36.example.com kernel: current = process#011#011=3D >>>> 86140 (nginx) >>>>> Dec 6 18:27:18 server36.example.com kernel: trap number#011#011=3D = 12 >>>>> Dec 6 18:27:18 server36.example.com kernel: panic: page fault >>>>> Dec 6 18:27:18 server36.example.com kernel: cpuid =3D 3 >>>>> Dec 6 18:27:18 server36.example.com kernel: time =3D 1575649514 >>>>> Dec 6 18:27:18 server36.example.com kernel: KDB: stack backtrace: >>>>> Dec 6 18:27:18 server36.example.com kernel: #0 0xffffffff80c1d207 = at >>>> kdb_backtrace+0x67 >>>>> Dec 6 18:27:18 server36.example.com kernel: #1 0xffffffff80bd053d = at >>>> vpanic+0x19d >>>>> Dec 6 18:27:18 server36.example.com kernel: #2 0xffffffff80bd0393 = at >>>> panic+0x43 >>>>> Dec 6 18:27:18 server36.example.com kernel: #3 0xffffffff810a7d2c = at >>>> trap_fatal+0x39c >>>>> Dec 6 18:27:18 server36.example.com kernel: #4 0xffffffff810a7d79 = at >>>> trap_pfault+0x49 >>>>> Dec 6 18:27:18 server36.example.com kernel: #5 0xffffffff810a736f = at >>>> trap+0x29f >>>>> Dec 6 18:27:18 server36.example.com kernel: #6 0xffffffff8108132c = at >>>> calltrap+0x8 >>>>> Dec 6 18:27:18 server36.example.com kernel: #7 0xffffffff80f0c340 = at >>>> vm_fault_hold+0x1b90 >>>>> Dec 6 18:27:18 server36.example.com kernel: #8 0xffffffff80f0a760 = at >>>> vm_fault+0x60 >>>>> Dec 6 18:27:18 server36.example.com kernel: #9 0xffffffff810a7e94 = at >>>> trap_pfault+0x164 >>>>> Dec 6 18:27:18 server36.example.com kernel: #10 = 0xffffffff810a74fb at >>>> trap+0x42b >>>>> Dec 6 18:27:18 server36.example.com kernel: #11 = 0xffffffff8108132c at >>>> calltrap+0x8 >>>>>=20 >>>>> Do you think it's hardware related? >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> freebsd-questions@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-questions >>>> To unsubscribe, send any mail to " >>>> freebsd-questions-unsubscribe@freebsd.org" >>>>=20 >>>=20 >>> I do not know if this might be relevant, but these line in your log = file >>> looks suspicious to me: >>>=20 >>> __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 >>> *234 /usr/src/sys/amd64/include/pcpu.h: No such file or directory.* >>> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 >>> #1 doadump (textdump=3D<optimized out>) >>=20 >> Why you think this line is suspicious? >>=20 >> I was running FreeBSD-12.1-BETA3. I upgrade it today to = FreeBSD-12.1-p1. >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to " >> freebsd-questions-unsubscribe@freebsd.org" >>=20 >=20 > Because it is just a few lines above the kernel panic and it says that = the > file could not be found. That is why I am asking if that can be a = problem > or not. >=20 > Also, is the problem occurring during boot or after startup or when = exactly? >=20 I fetch /usr/src only for upgrading the system and then I remove it. = That's why it says that it doesn't find this file. No the problem didn't occur during boot. I think it happened during a = Nginx restart.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6A5B8B89-31C5-4AB7-AE35-D48E93D54E66>