Bug 241417 - panic: Fatal trap 1: privileged instruction fault while in kernel mode
Summary: panic: Fatal trap 1: privileged instruction fault while in kernel mode
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-RELEASE
Hardware: i386 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Keywords: panic
Depends on:
Reported: 2019-10-22 18:38 UTC by Nick Briggs
Modified: 2020-06-06 15:34 UTC (History)
2 users (show)

See Also:

core.txt.0 from crash (165.80 KB, text/plain)
2019-10-22 18:38 UTC, Nick Briggs
no flags Details
Output from "/usr/local/bin/acpidump -o /tmp/acpidump.txt" (119.08 KB, text/plain)
2019-10-24 02:16 UTC, Nick Briggs
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Briggs 2019-10-22 18:38:42 UTC
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
+Uptime: 2d12h11m14s
+Physical memory: 931 MB
+Dumping 161 MB: 146 130 114 98 82 66 50 34 18 2
+Dump complete

I have attached core.txt.0, and have the vmcore.0 if it is of use.
Comment 1 Andriy Gapon freebsd_committer 2019-10-23 08:06:43 UTC
This looks like a memory corruption, maybe a hardware a problem.
Specifically I mean this address: 0xffc033ba.
Comment 2 Nick Briggs 2019-10-24 01:50:54 UTC
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
Comment 3 Nick Briggs 2019-10-24 02:16:30 UTC
Created attachment 208547 [details]
Output from "/usr/local/bin/acpidump -o /tmp/acpidump.txt"
Comment 4 Nick Briggs 2019-10-24 02:18:33 UTC
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.
Comment 5 Andriy Gapon freebsd_committer 2019-10-24 11:12:40 UTC
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?
Comment 6 Nick Briggs 2019-10-24 17:37:26 UTC
(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.
Comment 7 Mark Johnston freebsd_committer 2020-06-02 14:38:29 UTC
Have you seen any similar crashes since the initial one?
Comment 8 Nick Briggs 2020-06-05 18:23:01 UTC
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.
Comment 9 Mark Johnston freebsd_committer 2020-06-06 15:34:33 UTC
(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.