Bug 241604 - NFS kernel panic after running iozone on share while idle
Summary: NFS kernel panic after running iozone on share while idle
Status: Closed DUPLICATE of bug 234296
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
Keywords: panic
Depends on:
Reported: 2019-10-31 02:11 UTC by e.moe
Modified: 2019-10-31 14:30 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description e.moe 2019-10-31 02:11:34 UTC
After running and completing the full suite of iozone tests on an NFS share my client system running 12.0-RELEASE-p2 GENERIC amd64 had a GPF.  The NFS server is FreeNAS 11.2-U6 exporting a basic NFS share.  The client system, the system that panicked, had the share mounted.  I ran the full battery of iozone 3.487 tests using the following command: iozone -a -g 32G.  All the tests completed in about 16 hours, the system was idle for about 5 hours after the test.  I was able to view the results.  I then walked away for about an hour, came back and the system had rebooted with the following:

pid 1573 (tracker-miner-fs), uid 1001: exited on signal 11
Limiting closed port RST response from 277 to 200 packets/sec
Limiting closed port RST response from 206 to 200 packets/sec
newnfs: server '' error: fileid changed. fsid 0:0: expected fileid 0x4, got 0x2. (BROKEN NFS SERVER OR MIDDLEWARE)
kernel trap 9 with interrupts disabled

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer	= 0x20:0xffffffff80bb524f
stack pointer	        = 0x28:0xfffffe003fe92710
frame pointer	        = 0x28:0xfffffe003fe92780
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= resume, IOPL = 0
current process		= 11 (idle: cpu0)
trap number		= 9
panic: general protection fault
cpuid = 0
time = 1572482669
KDB: stack backtrace:
#0 0xffffffff80be7977 at kdb_backtrace+0x67
#1 0xffffffff80b9b563 at vpanic+0x1a3
#2 0xffffffff80b9b3b3 at panic+0x43
#3 0xffffffff8107496f at trap_fatal+0x35f
#4 0xffffffff81073dbd at trap+0x6d
#5 0xffffffff8104f315 at calltrap+0x8
#6 0xffffffff811aa358 at handleevents+0x1a8
#7 0xffffffff811aa9c9 at timercb+0xa9
#8 0xffffffff811e8af6 at lapic_handle_timer+0xb6
#9 0xffffffff81050f3e at Xtimerint+0xae
#10 0xffffffff811df68f at cpu_idle_acpi+0x3f
#11 0xffffffff811df747 at cpu_idle+0xa7
#12 0xffffffff80bcfb25 at sched_idletd+0x515
#13 0xffffffff80b5bf33 at fork_exit+0x83
#14 0xffffffff810502fe at fork_trampoline+0xe
Uptime: 39d2h38m52s
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RELEASE-p2 GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)

The FreeNAS server is fine.  It had been up for a day and has no issues
Comment 1 Mark Johnston freebsd_committer 2019-10-31 02:33:11 UTC
Can you reproduce this with the latest 12.0 patches?  There was a fix for an erratum which matches what you're seeing; it is described in bug 234296.  It was fixed in -p3, which you do not have.
Comment 2 e.moe 2019-10-31 04:55:22 UTC
I updated to the latest patch, 12.0-RELEASE-p10.  I haven't had any panics on this system except this one.  It was up for almost 40 days before that happened and I've run a number of similar iozone tests in that time.  I started a new iozone test with the same settings and will report if it happens again.
Comment 3 Mark Johnston freebsd_committer 2019-10-31 14:30:19 UTC
(In reply to e.moe from comment #2)
Thanks.  In the meantime I will close the bug report, please reopen if you hit this panic again.

*** This bug has been marked as a duplicate of bug 234296 ***