This might be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194974, but it's a different panic message, so I opened a new PR. I figure the awesome power of bugzilla will let you chain PRs together if needed.
Fresh world & kernel, latest official packages:
FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r274435: Wed Nov 12 11:30:04 EST 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64
;pkg info lsof
Name : lsof
Version : 4.88,8
Installed on : Wed Nov 12 10:27:44 EST 2014
Origin : sysutils/lsof
Architecture : freebsd:11:x86:64
Prefix : /usr/local
Categories : sysutils
Maintainer : firstname.lastname@example.org
WWW : http://people.freebsd.org/~abe/
Comment : Lists information about open files (similar to fstat(1))
repo_type : binary
repository : FreeBSD
Flat size : 223KiB
Lsof (LiSt Open Files) lists information about files that are open by the
running processes. An open file may be a regular file, a directory, a block
special file, a character special file, an executing text reference, a
library, a stream or a network file (Internet socket, NFS file or Unix domain
See also fstat(1) in the base system.
Run "lsof -i" and CPU usage starts to climb. In 15-30 seconds I get a panic. I haven't done this for a while, so let me know if I kgdb'd wrong or you want more info.
storm/var/crash;kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
panic: virtual address 0xfffff810840fc985 not covered by the DMAP
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085d6aa610
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe085d6aa6c0
vpanic() at vpanic+0x189/frame 0xfffffe085d6aa740
kassert_panic() at kassert_panic+0x139/frame 0xfffffe085d6aa7b0
memrw() at memrw+0x163/frame 0xfffffe085d6aa810
giant_read() at giant_read+0x5b/frame 0xfffffe085d6aa850
devfs_read_f() at devfs_read_f+0xca/frame 0xfffffe085d6aa8b0
dofileread() at dofileread+0x95/frame 0xfffffe085d6aa900
kern_readv() at kern_readv+0x68/frame 0xfffffe085d6aa950
sys_read() at sys_read+0x63/frame 0xfffffe085d6aa9a0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe085d6aaab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe085d6aaab0
--- syscall (3, FreeBSD ELF64, sys_read), rip = 0x800b793aa, rsp = 0x7fffffffe238, rbp = 0x7fffffffe280 ---
KDB: enter: panic
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/ipmi.ko.symbols...done.
Loaded symbols for /boot/kernel/ipmi.ko.symbols
Reading symbols from /boot/kernel/smbus.ko.symbols...done.
Loaded symbols for /boot/kernel/smbus.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
#0 doadump (textdump=0) at pcpu.h:219
219 pcpu.h: No such file or directory.
let me know if I need to get Vic involved....
> let me know if I need to get Vic involved....
Will do; at this point I think it's not likely.
While clearly the kernel should not panic, why is lsof reading kernel memory?
What interfaces (if any) are missing?
As to why lsof is reading kernel memory, there are TONS of messages on various lists over the last few years.
Vic has said he'd use interfaces, but no one (tmk) has written what he needs.
A commit references this bug:
Date: Sat Jan 3 01:28:59 UTC 2015
New revision: 276600
For /dev/mem and /dev/kmem accesses, avoid asserting that addresses
are within direct map. We want to return error instead of panicing.
Sponsored by: The FreeBSD Foundation
To originators/assignees of this PR:
A commit to the tree references this PR, however the PR is still in a non-closed state.
Please review this PR and close as appropriate, or if closing the PR requires a merge to stable/10, please let re@ know as soon as possible.
This sure seems fixed now. Cannot reproduce on any of my systems.
Now to see if I can close a bugzilla PR. :-)