Discussion:
kernel panic while copying files
Gary Jennejohn
2021-06-07 09:01:09 UTC
Permalink
I've seen this panic three times in the last two days:

[first panic]
Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x801118000
fault code = supervisor write data, page not present
instruction pointer = 0x20:0xffffffff808d2212
stack pointer = 0x28:0xfffffe00dbc8c760
frame pointer = 0x28:0xfffffe00dbc8c7a0
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 = 28 (dom0)
trap number = 12
panic: page fault
cpuid = 3
time = 1622963058
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00dbc8c410
vpanic() at vpanic+0x181/frame 0xfffffe00dbc8c460
panic() at panic+0x43/frame 0xfffffe00dbc8c4c0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe00dbc8c520
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00dbc8c580
trap() at trap+0x253/frame 0xfffffe00dbc8c690
calltrap() at calltrap+0x8/frame 0xfffffe00dbc8c690
--- trap 0xc, rip = 0xffffffff808d2212, rsp = 0xfffffe00dbc8c760, rbp = 0xfffffe00dbc8c7a0 ---
zone_release() at zone_release+0x1f2/frame 0xfffffe00dbc8c7a0
bucket_drain() at bucket_drain+0xda/frame 0xfffffe00dbc8c7d0
bucket_cache_reclaim_domain() at bucket_cache_reclaim_domain+0x30a/frame 0xfffffe00dbc8c830
zone_reclaim() at zone_reclaim+0x162/frame 0xfffffe00dbc8c880
uma_reclaim_domain() at uma_reclaim_domain+0xa2/frame 0xfffffe00dbc8c8b0
vm_pageout_worker() at vm_pageout_worker+0x41e/frame 0xfffffe00dbc8cb70
vm_pageout() at vm_pageout+0x21e/frame 0xfffffe00dbc8cbb0
fork_exit() at fork_exit+0x7e/frame 0xfffffe00dbc8cbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00dbc8cbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
pc_curthread)));

One difference was that in the second and third panics the fault virtual
address was 0x0. But the backtrace was the same.

Relevant info from the info.x files:
Architecture: amd64
Architecture Version: 2
Version String: FreeBSD 14.0-CURRENT #33 main-n247184-1970d693039: Sat Jun
5 09:58:55 CEST 2021

CPU: AMD Ryzen 5 1600 Six-Core Processor (3194.09-MHz K8-class CPU)
Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1
AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
AMD Features2=0x35c233ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX>
AMD Extended Feature Extensions ID EBX=0x1007<CLZERO,IRPerf,XSaveErPtr,IBPB>

I have 16GiB of memory in the box.

The panic occurred while copying files from an internal SATA SSD to a
SATA 8TB disk in an external USB3 docking station. The panic seems to
occur quite quickly, after only a few files have been copied.

swap is on a different internal disk.

I can poke around in the crash dumps with kgdb if anyone wants more
information.
--
Gary Jennejohn
Mark Johnston
2021-06-07 20:54:11 UTC
Permalink
Post by Gary Jennejohn
[first panic]
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x801118000
fault code = supervisor write data, page not present
instruction pointer = 0x20:0xffffffff808d2212
stack pointer = 0x28:0xfffffe00dbc8c760
frame pointer = 0x28:0xfffffe00dbc8c7a0
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 = 28 (dom0)
trap number = 12
panic: page fault
cpuid = 3
time = 1622963058
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00dbc8c410
vpanic() at vpanic+0x181/frame 0xfffffe00dbc8c460
panic() at panic+0x43/frame 0xfffffe00dbc8c4c0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe00dbc8c520
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00dbc8c580
trap() at trap+0x253/frame 0xfffffe00dbc8c690
calltrap() at calltrap+0x8/frame 0xfffffe00dbc8c690
--- trap 0xc, rip = 0xffffffff808d2212, rsp = 0xfffffe00dbc8c760, rbp = 0xfffffe00dbc8c7a0 ---
zone_release() at zone_release+0x1f2/frame 0xfffffe00dbc8c7a0
bucket_drain() at bucket_drain+0xda/frame 0xfffffe00dbc8c7d0
bucket_cache_reclaim_domain() at bucket_cache_reclaim_domain+0x30a/frame 0xfffffe00dbc8c830
zone_reclaim() at zone_reclaim+0x162/frame 0xfffffe00dbc8c880
uma_reclaim_domain() at uma_reclaim_domain+0xa2/frame 0xfffffe00dbc8c8b0
vm_pageout_worker() at vm_pageout_worker+0x41e/frame 0xfffffe00dbc8cb70
vm_pageout() at vm_pageout+0x21e/frame 0xfffffe00dbc8cbb0
fork_exit() at fork_exit+0x7e/frame 0xfffffe00dbc8cbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00dbc8cbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
pc_curthread)));
One difference was that in the second and third panics the fault virtual
address was 0x0. But the backtrace was the same.
Architecture: amd64
Architecture Version: 2
Version String: FreeBSD 14.0-CURRENT #33 main-n247184-1970d693039: Sat Jun
5 09:58:55 CEST 2021
CPU: AMD Ryzen 5 1600 Six-Core Processor (3194.09-MHz K8-class CPU)
Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1
AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
AMD Features2=0x35c233ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX>
AMD Extended Feature Extensions ID EBX=0x1007<CLZERO,IRPerf,XSaveErPtr,IBPB>
I have 16GiB of memory in the box.
The panic occurred while copying files from an internal SATA SSD to a
SATA 8TB disk in an external USB3 docking station. The panic seems to
occur quite quickly, after only a few files have been copied.
swap is on a different internal disk.
I can poke around in the crash dumps with kgdb if anyone wants more
information.
Are you running with invariants configured in the kernel? If not,
please try to reproduce this in a kernel with

options INVARIANT_SUPPORT
options INVARIANTS

configured.

A stack trace with line numbers would also be helpful.

Loading...