Created attachment 208510 [details]
core.txt.0 from crash
FreeBSD flap.gateway.sonic.net 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC i386
+Fatal trap 1: privileged instruction fault while in kernel mode
+cpuid = 0; apic id = 00
+error code = 0
+instruction pointer = 0x20:0xffc033d9
+stack pointer = 0x28:0xfba0bc0
+frame pointer = 0x28:0xfba0bd0
+code segment = base rx0, limit 0xfffff, type 0x1b
+ = DPL 0, pres 1, def32 1, gran 1
+processor eflags = resume, IOPL = 0
+current process = 11 (idle: cpu0)
+trap number = 1
+panic: privileged instruction fault
+cpuid = 0
+time = 1571652112
+KDB: stack backtrace:
+#0 0x110848f at kdb_backtrace+0x4f
+#1 0x10bb467 at vpanic+0x147
+#2 0x10bb31b at panic+0x1b
+#3 0x16920b5 at trap_fatal+0x395
+#4 0x169144e at trap+0xde
+#5 0xffc0315d at PTDpde+0x4165
+#6 0xa0c89c at acpi_cpu_idle+0x30c
+#7 0x16aa93f at cpu_idle_acpi+0x3f
+#8 0x16aa9fb at cpu_idle+0xab
+#9 0x10ef456 at sched_idletd+0x376
+#10 0x107cad1 at fork_exit+0x71
+#11 0xffc033ba at PTDpde+0x43c2
+Physical memory: 931 MB
+Dumping 161 MB: 146 130 114 98 82 66 50 34 18 2
I have attached core.txt.0, and have the vmcore.0 if it is of use.
This looks like a memory corruption, maybe a hardware a problem.
Specifically I mean this address: 0xffc033ba.
This is the code sequence it was executing:
0x00a0c87c <+748>: mov %eax,%edx
0x00a0c87e <+750>: in (%dx),%al
0x00a0c87f <+751>: mov -0x14(%ebp),%ebx
0x00a0c882 <+754>: cmpb $0x0,0x30(%edi,%ebx,4)
0x00a0c887 <+759>: je 0xa0c897 <acpi_cpu_idle+775>
0x00a0c889 <+761>: mov 0x34(%edi,%ebx,4),%eax
0x00a0c88d <+765>: mov %eax,(%esp)
0x00a0c890 <+768>: call 0x16aa370 <acpi_cpu_idle_mwait>
0x00a0c895 <+773>: jmp 0xa0c89c <acpi_cpu_idle+780>
0x00a0c897 <+775>: call 0x16aa360 <acpi_cpu_c1>
0x00a0c89c <+780>: lea 0x30(%edi,%ebx,4),%eax
0x00a0c8a0 <+784>: mov %eax,-0x10(%ebp)
0x00a0c8a3 <+787>: call *0x1d2af74
Are you (Andriy) sure that you're interpreting the stack trace correctly?
I see exactly the same location in the stack trace in, for example, bug #227654, comment #4
Created attachment 208547 [details]
Output from "/usr/local/bin/acpidump -o /tmp/acpidump.txt"
Since this crash seems to be in an ACPI related area, I've attached the acpidump output. If I use the system supplied /usr/sbin/acpidump -dt, it produces inconsistent results on each execution, so I've attached the output from the ports version.
Maybe I am indeed incorrectly interpreting 0xffc0315d. Maybe it's a low level trap handler that calls trap(). But I see do not see anything near 0x00a0c89c in acpi_cpu_idle or in acpi_cpu_c1 that could cause that fault.
Were you, by chance, doing anything with DTrace when the crash happened?
(In reply to Andriy Gapon from comment #5)
No DTrace. The machine was sitting idle with nobody logged in when it failed.
The only trap that the LEA instruction is documented as able to cause is:
#UD If source operand is not a memory location.
Have you seen any similar crashes since the initial one?
Re: "Have you seen any similar crashes since the initial one?"
No, it has not happened again.
Since the original report I upgraded the system to FreeBSD 12.1 (as soon it was released) and am currently on 12.1-RELEASE-p5.
(In reply to Nick Briggs from comment #8)
Thanks for the reply. Since you have upgraded, I will close the bug for now. Please re-open the bug if the panic occurs again.