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 lsof-4.88,8 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 : ler@lerctr.org WWW : http://people.freebsd.org/~abe/ Comment : Lists information about open files (similar to fstat(1)) Annotations : repo_type : binary repository : FreeBSD Flat size : 223KiB Description : 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 socket). See also fstat(1) in the base system. WWW: http://people.freebsd.org/~abe/ 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. in pcpu.h (kgdb)
let me know if I need to get Vic involved.... Larry Rosenman Maintainer, sysutils/lsof
> 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: Author: kib Date: Sat Jan 3 01:28:59 UTC 2015 New revision: 276600 URL: https://svnweb.freebsd.org/changeset/base/276600 Log: For /dev/mem and /dev/kmem accesses, avoid asserting that addresses are within direct map. We want to return error instead of panicing. PR: 194995 Sponsored by: The FreeBSD Foundation Changes: head/sys/amd64/amd64/mem.c head/sys/amd64/include/vmparam.h
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. Thank you. Glen
This sure seems fixed now. Cannot reproduce on any of my systems. Now to see if I can close a bugzilla PR. :-)