WITHOUT_MODULES=if_lmc not working in NanoBSD
I try to disable device bpf in the kernel, which results in a compilation error of if_lmc: [...] --- /empty/src/ALG/CURRENT/sys/modules/lmc/../../dev/lmc/if_lmc.c:4357:33: error: use of undeclared identifier 'DEV_BPF' ALTQ_PRESENT ? "ALTQ " : "", NBPFILTER ? "BPF " : "", ^ /empty/src/ALG/CURRENT/sys/modules/lmc/../../dev/lmc/if_lmc.c:94:20: note: expanded from macro 'NBPFILTER' # define NBPFILTER DEV_BPF ^ 4 errors generated. *** [if_lmc.o] Error code 1 In NanoBSD's common.conf, I defined therefore CONF_WORLD=' WITHOUT_MODULES=if_lmc ... ' or, since it doesn't work as expected, CONF_WORLD=' WITHOUT_MODULES=lmc ... ' It doesn't work as expected! WITHOUT_MODULES= doesn't work at all. Module/driver if_lmc (lmc) is compiled everytime and running therefore into that error, the build of the driver/module is not skipped. How can I securely disable bpf AND exclude modules from being build? Thanks in advance, O. Hartmann ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Virtio network: poor performance with KVM hypervisor (latest Proxmox)
Hi all!
I am using the latest Proxmox 4.1 with all updates installed.
I have several VM's with FreeBSD guests and 1 VM with Ubuntu 14 (all KVM).
Host system file download speed: 60 MBps.
FreeBSD guest download speed: 2 MBps on virtio network with TSO enabled, 5-9
MBps with TSO disabled; 12 MBps on e1000 network.
Ubuntu guest: 60 MBps with virtio.
I've tried the following:
1) Different FreeBSD versions: 9.3, 10.2, 10.3-BETA3.
2) Different TSO settings, enabling/disabling RXCSUM.
3) Different TSO settings on host system.
The best results I got described above :(
Does anyone have any ideas how to get full network performance inside FreeBSD
guests?
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
smime.p7s
Description: S/MIME cryptographic signature
CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833)
Hello.
I get kernel panic on high loaded server with messages
savecore: reboot after panic:
vn_sendfile: mlen 326 space -20 hdrlen 326
# kgdb kernel.debug /var/crash/vmcore.0
Unread portion of the kernel message buffer:
panic: vn_sendfile: mlen 326 space -20 hdrlen 326
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe20206314f0
vpanic() at vpanic+0x182/frame 0xfe2020631570
kassert_panic() at kassert_panic+0x126/frame 0xfe20206315e0
vn_sendfile() at vn_sendfile+0x14ca/frame 0xfe2020631900
sys_sendfile() at sys_sendfile+0x11e/frame 0xfe20206319a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe2020631ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe2020631ab0
--- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x801ef062a, rsp =
0x7fffd8d8, rbp = 0x7fffe1d0 ---
KDB: enter: panic
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/carp.ko...Reading symbols from
/usr/lib/debug//boot/kernel/carp.ko.debug...done.
done.
Loaded symbols for /boot/kernel/carp.ko
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ums.ko
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/tmpfs.ko
#0 doadump (textdump=0) at pcpu.h:221
221 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0 doadump (textdump=0) at pcpu.h:221
#1 0x80384a0b in db_dump (dummy=, dummy2=false,
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
#2 0x803847fe in db_command (cmd_table=0x0) at
/usr/src/sys/ddb/db_command.c:440
#3 0x80384594 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:493
#4 0x8038702b in db_trap (type=, code=0) at
/usr/src/sys/ddb/db_main.c:251
#5 0x80a656e3 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6 0x80ea1298 in trap (frame=0xfe2020631420) at
/usr/src/sys/amd64/amd64/trap.c:556
#7 0x80e81a77 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:234
#8 0x80a64dcb in kdb_enter (why=0x813b6c2f "panic", msg=0x80
) at cpufunc.h:63
#9 0x80a27b5f in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:750
#10 0x80a279b6 in kassert_panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:647
#11 0x80a25efa in vn_sendfile (fp=, sockfd=1619,
hdr_uio=, trl_uio=0x0, offset=0,
nbytes=, sent=, flags=, kflags=, td=0xa8)
at /usr/src/sys/kern/kern_sendfile.c:833
#12 0x80a2641e in sys_sendfile (td=0xf80253593000,
uap=0xfe2020631a40) at file.h:382
#13 0x80ea214b in amd64_syscall (td=0xf80253593000, traced=0) at
subr_syscall.c:135
#14 0x80e81d5b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:394
#15 0x000801ef062a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language: auto; currently minimal
(kgdb) list *0x80a25efa
0x80a25efa is in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833).
828 free(sfio, M_TEMP);
829 goto done;
830 }
831
832 /* Add the buffer chain to the socket buffer. */
833 KASSERT(m_length(m, NULL) == space + hdrlen,
834 ("%s: mlen %u space %d hdrlen %d",
835 __func__, m_length(m, NULL), space, hdrlen));
836
837 CURVNET_SET(so->so_vnet);
System have 128Gb memory
zfs as FS
DB's worked on it and web pages served by this server.
core saved.
panic periodicaly repeted (few hours -- up to few days)
Before this, old current (about two year old CURRENT ) work on this server
without crashes.
Can anybody point me to way of more complex problem diagnostic or any other
useful things
Thank you.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ERROR: ctfconvert: *.o doesn't have type data to convert
I've just finished building world, and am building a custom kernel. (11-CURRENT svn co from yesterday, and on an i386) I see the following message emitted on every lib being processed during the build: ERROR: ctfconvert: *.o doesn't have type data to convert (replace the asterisk (*) with any given library) Will this result in an unusable kernel? Should I be concerned? Thanks! --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ERROR: ctfconvert: *.o doesn't have type data to convert
On Fri, 04 Mar 2016 08:47:44 -0800 "Chris H" wrote > I've just finished building world, and am building a custom kernel. > (11-CURRENT svn co from yesterday, and on an i386) > > I see the following message emitted on every lib being processed > during the build: > > ERROR: ctfconvert: *.o doesn't have type data to convert > (replace the asterisk (*) with any given library) > > Will this result in an unusable kernel? Should I be concerned? > Well. It didn't seem to cause any *real* harm. (new) kernel doesn't (yet) seem to exhibit any unexpected behavior. --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ERROR: ctfconvert: *.o doesn't have type data to convert
On Fri, Mar 04, 2016 at 08:47:44AM -0800, Chris H wrote: > I've just finished building world, and am building a custom kernel. > (11-CURRENT svn co from yesterday, and on an i386) > > I see the following message emitted on every lib being processed > during the build: > > ERROR: ctfconvert: *.o doesn't have type data to convert > (replace the asterisk (*) with any given library) This is probably because your kernel config contains "makeoptions WITH_CTF=1" but not "DEBUG=-g". ctfconvert has nothing to do because no DWARF info is available, and emits that error as a result. > > Will this result in an unusable kernel? Should I be concerned? No, it'll work fine. Some parts of DTrace will not work. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Several LOR's with most recent install media
On Thu, 03 Mar 2016 07:24:11 -0800 "Chris H" wrote > On Wed, 02 Mar 2016 23:00:44 -0800 "Chris H" wrote > > > On Wed, 02 Mar 2016 21:49:39 -0800 "Chris H" wrote > > > > > Hello all, > > > I just finished an install off of the > > > 11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD. > > > After rebooting to the fresh install; shutting down the system > > > results in several LOR's. Given so much information is dumped to > > > screen, and that I no longer have access to the system; How can I > > > get a copy of the LOR's output? I can capture the screen with my > > > cell phone. But the information would sure be a lot more valuable > > > in text form; no? :-) > > > > > > Thanks for any suggestions. > > > > > OK. Just got a couple more while checking out head/ports > > > > Mar 2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K > > Mar 2 22:12:00 spare kernel: lock order reversal: > > Mar 2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) @ > > /usr/src/sys/kern/vfs_bio.c:3488 > > Mar 2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) @ > > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > > Mar 2 22:12:00 spare kernel: stack backtrace: > > Mar 2 22:12:00 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > > Mar 2 22:12:00 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > > Mar 2 22:12:00 spare kernel: #2 0xc0c31a5 > > Mar 2 22:12:00 spare kernel: 1 at _sx_xlock+0x71 > > Mar 2 22:12:00 spare kernel: #3 0xc0ef0b > > Mar 2 22:12:01 spare kernel: 70 at ufsdirhash_add+0x40 > > Mar 2 22:12:01 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682 > > Mar 2 22:12:01 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb > > Mar 2 22:12:01 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108 > > Mar 2 22:12:01 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a > > Mar 2 22:12:01 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31 > > Mar 2 22:12:01 spare kernel: #9 0xc117d4ed at syscall+0x37d > > Mar 2 22:12:01 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f > > Mar 2 22:19:31 spare kernel: lock order reversal: > > Mar 2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:873 > > Mar 2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) @ > > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > > Mar 2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:2476 > > Mar 2 22:19:31 spare kernel: stack backtrace: > > Mar 2 22:19:31 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > > Mar 2 22:19:31 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > > Mar 2 22:19:31 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57 > > Mar 2 22:19:31 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84 > > Mar 2 22:19:31 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118 > > Mar 2 22:19:31 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96 > > Mar 2 22:19:31 spare kernel: #6 0xc0cdf2d4 at vget+0x64 > > Mar 2 22:19:31 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1 > > Mar 2 22:19:31 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44 > > Mar 2 22:19:31 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b > > Mar 2 22:19:31 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa > > Mar 2 22:19:31 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26 > > Mar 2 22:19:31 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108 > > Mar 2 22:19:31 spare kernel: #13 0xc0cbfc40 at bufsync+0x40 > > Mar 2 22:19:31 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94 > > Mar 2 22:19:31 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0 > > Mar 2 22:19:31 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b > > Mar 2 22:19:31 spare kernel: #17 0xc0bead5e at fork_exit+0x7e > > > > Sorry for any undesirable line-wraps. > > I can attache the output, if needed. > > > > Thanks for any help preventing these. > > > OK. Got another one wile checking out /usr/src > > Mar 3 06:45:41 spare kernel: 1st 0xda5fc478 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3488 > Mar 3 06:45:41 spare kernel: 2nd 0xcbf89a00 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > Mar 3 06:45:41 spare kernel: stack backtrace: > Mar 3 06:45:41 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > Mar 3 06:45:41 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > Mar 3 06:45:41 spare kernel: #2 0xc0c31a51 at _sx_xlock+0x71 > Mar 3 06:45:41 spare kernel: #3 0xc0ef0b70 at ufsdirhash_add+0x40 > Mar 3 06:45:41 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682 > Mar 3 06:45:41 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb > Mar 3 06:45:41 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108 > Mar 3 06:45:41 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a > Mar 3 06:45:41 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31 > Mar 3 06:45:41 spare kernel: #9 0xc117d4ed at syscall+0x37d > Mar 3 06:45:41 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f > Mar 3 06:50:42 spare kernel: lock order reversal: > Mar 3 06:50:42 spare kernel: 1st 0xc880ca30
Re: ERROR: ctfconvert: *.o doesn't have type data to convert
On Fri, 4 Mar 2016 11:21:33 -0800 Mark Johnston wrote > On Fri, Mar 04, 2016 at 08:47:44AM -0800, Chris H wrote: > > I've just finished building world, and am building a custom kernel. > > (11-CURRENT svn co from yesterday, and on an i386) > > > > I see the following message emitted on every lib being processed > > during the build: > > > > ERROR: ctfconvert: *.o doesn't have type data to convert > > (replace the asterisk (*) with any given library) > > This is probably because your kernel config contains > "makeoptions WITH_CTF=1" but not "DEBUG=-g". ctfconvert has nothing to > do because no DWARF info is available, and emits that error as a result. Right you are. I also considered something to that affect, but was *sure* I had commented *both* DEBUG=-g and WITH_CFT=1. But a quick check reveals I forgot WITH_CFT=1 -- D'OH! Thanks, Mark! > > > > > Will this result in an unusable kernel? Should I be concerned? > > No, it'll work fine. Some parts of DTrace will not work. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Several LOR's with most recent install media
On Thu, 3 Mar 2016, Chris H wrote: > > > > Mar 2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K > > Mar 2 22:12:00 spare kernel: lock order reversal: > > Mar 2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) @ > > /usr/src/sys/kern/vfs_bio.c:3488 > > Mar 2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) @ > > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 bufwait/dirhash is "well-known" and harmless > > Mar 2 22:19:31 spare kernel: lock order reversal: > > Mar 2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:873 > > Mar 2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) @ > > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > > Mar 2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:2476 As is this one. > OK. Got another one wile checking out /usr/src > > Mar 3 06:45:41 spare kernel: 1st 0xda5fc478 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3488 > Mar 3 06:45:41 spare kernel: 2nd 0xcbf89a00 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 This is the same as the first one; still harmless. > > Please let me know if you need any more info, or I should blow > this attempted install away, and wait for another (newer) revision. I don't think any of those actions are called for; you should just ignore these particular LORs and continue using the system. (LOR printouts are conditional on certain debugging kernel options that are disabled in official release builds.) -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
