if_em, legacy nic and GbE saturation
Hello, I recycled an older box and put an i350-2 together with a second 82541GI (PCI-slot, one already on-board) into it. The two i350-ports are used with VMDq for ESXi5.1. The two 82541GI are used as lagg-nics by a 9.2-RC (amd64) guest as passthrou PCI device. Always had good results with such setups, but found out, that nics which use the legacy driver part of if_em max out at ~0.6Gbits/s (1500 MTU). There's another NIC on board of this recycle-box, a 82566-PHY (ICH9 integrated MAC). This one uses also if_em, but not legacy code, it reports version 7.3.8 (compared to 1.0.6). And it has no problem fully saturating GbE (~925Mbits/s, no jumbo Frames support anyways). I'm using iperf, with and without lagg (doesn't change anyhing, like it doesn't influence tests on some other boxes with 82576 and i350 (igb)) I see enough idle cycles so CPU shouldn't limit the legacy if_em nics. Also, I see the 82541 consuming arround 8k irqs. Same does the 82566-PHY, but with much higher throughput... I'd like to know if I can't generally expect to saturate older (PCI) GbE nics the line for any reason... I can remember tigeon cards from more than a decade ago, which indeed seemd to lack the performance to gain GbE, but I thought that was no issue shortly later and no modern Intel-GbE card had such constraints!? Is there any special tuning for legacy if_em (no need for any TCP tuning, 82566 doesn't have any issue)? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: wpi fatal firmware error with country de
On 24/08/2013 17:57, Victor Balada Diaz wrote: On Mon, Aug 19, 2013 at 12:27:04AM +0200, Dominic Fandrey wrote: On 19/08/2013 00:13, Adrian Chadd wrote: That's really odd. But then, it's a firmware driven NIC, who knows what kind of weird crap is going on under the hood. Yes, it's a black box. So how do I get in contact with intel support and dump that in their laps? Maybe you could experiment by looking at what changing the regulatory domain does when programming the firmware and see if it's a channel thing, a regulatory domain thing or something else. It looks like anything that results in regdomain FCC is all right. Everything else blows up. I've reported the same issue nearly a year ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172706 If you get to find additional information, please add it to the PR so it doesn't get lost. I didn't actually find any way to fix it. Sorry, I've got nothing. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: if_em, legacy nic and GbE saturation
Hi, There's bus limits on how much data you can push over a PCI bus. You can look around online to see what 32/64 bit, 33/66MHz PCI throughput estimates are. It changes massively if you use small versus large frames as well. The last time I tried it i couldn't hit gige on PCI; I only managed to get to around 350mbit doing TCP tests. -adrian On 26 August 2013 00:06, Harald Schmalzbauer h.schmalzba...@omnilan.dewrote: Hello, I recycled an older box and put an i350-2 together with a second 82541GI (PCI-slot, one already on-board) into it. The two i350-ports are used with VMDq for ESXi5.1. The two 82541GI are used as lagg-nics by a 9.2-RC (amd64) guest as passthrou PCI device. Always had good results with such setups, but found out, that nics which use the legacy driver part of if_em max out at ~0.6Gbits/s (1500 MTU). There's another NIC on board of this recycle-box, a 82566-PHY (ICH9 integrated MAC). This one uses also if_em, but not legacy code, it reports version 7.3.8 (compared to 1.0.6). And it has no problem fully saturating GbE (~925Mbits/s, no jumbo Frames support anyways). I'm using iperf, with and without lagg (doesn't change anyhing, like it doesn't influence tests on some other boxes with 82576 and i350 (igb)) I see enough idle cycles so CPU shouldn't limit the legacy if_em nics. Also, I see the 82541 consuming arround 8k irqs. Same does the 82566-PHY, but with much higher throughput... I'd like to know if I can't generally expect to saturate older (PCI) GbE nics the line for any reason... I can remember tigeon cards from more than a decade ago, which indeed seemd to lack the performance to gain GbE, but I thought that was no issue shortly later and no modern Intel-GbE card had such constraints!? Is there any special tuning for legacy if_em (no need for any TCP tuning, 82566 doesn't have any issue)? Thanks, -Harry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: if_em, legacy nic and GbE saturation
Bezüglich Adrian Chadd's Nachricht vom 26.08.2013 10:34 (localtime): Hi, There's bus limits on how much data you can push over a PCI bus. You can look around online to see what 32/64 bit, 33/66MHz PCI throughput estimates are. It changes massively if you use small versus large frames as well. The last time I tried it i couldn't hit gige on PCI; I only managed to get to around 350mbit doing TCP tests. Thanks, I'm roughly aware about the PCI bus limit, but I guess it should be good for almost GbE: 33*10^6*32=1056, so if one considers overhead and other bus-blocking things (nothing of significance is active on the PCI bus in this case), I'd expect at least 800Mbis/s, which is what I get with jumbo frames. I also know that lagg won't help in regard of concurrent throughput because of the PCI limit. But it's the redundancy why I also use 2 nics in that parking-maschine. I just have no explanation why I see that noticable difference between mtu 1500 and 9000 on legacy if_em nic, which doesn't show up with the second on-board nic (82566), which uses different if_em code. I can imagine that it's related to PCI transfer limits (the 82566 is ICH9 integrated which connects via DMI to the CPU, so no PCI constraint), but if someone has more than an imagination, an explanation was highly appreciated :-) But if you saw similar constraints on other (non-if_em?) PCI-connected nics, I'll leave it as it is. Just wanted some kind of confirmation that it's normal that single-GbE doesn't play well with PCI. Thank you, -Harry signature.asc Description: OpenPGP digital signature
Re: [SOLVED] Re: Shutdown problem with an USB memory stick as ZFS cache device
On 24/07/2013 13.19, Ronald Klop wrote: On Thu, 18 Jul 2013 09:52:13 +0200, Maurizio Vairani maurizio.vair...@cloverinformatica.it wrote: On 17/07/2013 17:29, Julian H. Stacey wrote: Maurizio Vairani wrote: On 17/07/2013 11:50, Ronald Klop wrote: On Wed, 17 Jul 2013 10:27:09 +0200, Maurizio Vairani maurizio.vair...@cloverinformatica.it wrote: Hi all, on a Compaq Presario laptop I have just installed the latest stable #uname -a FreeBSD presario 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0: Tue Jul 16 16:32:39 CEST 2013 root@presario:/usr/obj/usr/src/sys/GENERIC amd64 For speed up the compilation I have added to the pool, tank0, a SanDisk memory stick as cache device with the command: # zpool add tank0 cache /dev/da0 But when I shutdown the laptop the process will halt with this screen shot: http://www.dump-it.fr/freebsd-screen-shot/2f9169f18c7c77e52e873580f9c2d4bf.jpg.html and I need to press the power button for more than 4 seconds to switch off the laptop. The problem is always reproducible. Does sysctl hw.usb.no_shutdown_wait=1 help? Ronald. Thank you Ronald it works ! In /boot/loader.conf added the line hw.usb.no_shutdown_wait=1 Maurizio I wonder (from ignorance as I dont use ZFS yet), if that merely masks the symptom or cures the fault ? Presumably one should use a ZFS command to disassociate whatever might have the cache open ? (in case something might need to be written out from cache, if it was a writeable cache ?) I too had a USB shutdown problem (non ZFS, now solved) several people made useful comments on shutdown scripts etc, so I'm cross referencing: http://lists.freebsd.org/pipermail/freebsd-mobile/2013-July/012803.html Cheers, Julian Probably it masks the symptom. Andriy Gapon hypothesizes a bug in the ZFS clean up code: http://lists.freebsd.org/pipermail/freebsd-fs/2013-July/017857.html Surely one can use a startup script with the command: zpool add tank0 cache /dev/da0 and a shutdown script with: zpool remove tank0 /dev/da0 but this mask the symptom too. I prefer the Ronald solution because: - is simpler: it adds only one line (hw.usb.no_shutdown_wait=1) to one file (/boot/loader.conf). - is fastest: the zpool add/remove commands take time and “hw.usb.no_shutdown_wait=1” in /boot/loader.conf speeds up the shutdown process. - is cleaner: the zpool add/remove commands pair will fill up the tank0 pool history. Regards Maurizio Keep an eye on this commit when it is merged to 9-stable. http://svnweb.freebsd.org/changeset/base/253606 It might be the fix of the problem. Ronald. It works ! Just upgraded the laptop to r254783. Shutdown and reboot works fine, regardless of the hw.usb.no_shutdown_wait value. Thanks Maurizio ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.2-RC3 Now Available
The third release candidate builds of the 9.2-RELEASE release cycle are now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64, and sparc64 architectures. This is expected to be the final release candidate for the 9.2-RELEASE cycle. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.2/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use releng/9.2. Please be aware that cvsup and CVS are both deprecated, and are not supported methods of updating the src/ tree. Changes between -RC2 and -RC3 include: o Fix an integer overflow in computing the size of a temporary buffer, which can result in a buffer which is too small for the requested operation. (FreeBSD-SA-13:09.ip_multicast) o Revert fixes and improvements to sendfile(2), which uncovered a bug in the NFS implementation that in turn can cause deadlocks. o Default net.inet.tcp.experimental.initcwnd10 to off. The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 9.2-RC3 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 8.x. Alternatively, the user can install misc/compat8x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install Checksums: amd64: SHA256 (FreeBSD-9.2-RC3-amd64-bootonly.iso) = f981e308b638b754418a359bf200bb8287733cfab7c0baa6440950104e406160 SHA256 (FreeBSD-9.2-RC3-amd64-disc1.iso) = aea3dbbc6fb11eea71ebbce71e8b0b0dcc3e6b66846040a420c6097acb3a93d4 SHA256 (FreeBSD-9.2-RC3-amd64-dvd1.iso) = a3ab1daea0af0dbc5a790a384390f6d1f91d2d385215d2d3de5ea7a332b01919 SHA256 (FreeBSD-9.2-RC3-amd64-memstick.img) = ba7b8d1ce52b8e00213eb7c3551eb2c4d4ed9b02150310cd4f598290e119b4bf MD5 (FreeBSD-9.2-RC3-amd64-bootonly.iso) = d247cc4ca217a964f479dbe8cfc22fc0 MD5 (FreeBSD-9.2-RC3-amd64-disc1.iso) = 4e430da45f95cf861747cdad71c0cbe8 MD5 (FreeBSD-9.2-RC3-amd64-dvd1.iso) = 4eef235c2be6653eaea922dbebf7a33e MD5 (FreeBSD-9.2-RC3-amd64-memstick.img) = 32a77a37bea65773794ff41745709988 i386: SHA256 (FreeBSD-9.2-RC3-i386-bootonly.iso) = 68d36132ce13b39079641adc688f6e6a51dfce1d0a3dde4452e756d16bb5ddca SHA256 (FreeBSD-9.2-RC3-i386-disc1.iso) = 9e0a42a0622449092804da9ddf68a9b3d424d7535d13386e617e08e5059ec821 SHA256 (FreeBSD-9.2-RC3-i386-dvd1.iso) = be8f284d3c2958f04bbc94b482bfd7945c2b7464776a6de7912634e2b8a7dad8 SHA256 (FreeBSD-9.2-RC3-i386-memstick.img) = 4555133510cda8d38367a10cfd37b90eca9e194c137cfdabe264d5fac0b56aae MD5 (FreeBSD-9.2-RC3-i386-bootonly.iso) = 9f2d8496d9192a4ca1204cbbd9536d1a MD5 (FreeBSD-9.2-RC3-i386-disc1.iso) = 96bcc893a021e0d5e3c2b689c767569f MD5 (FreeBSD-9.2-RC3-i386-dvd1.iso) = 4562e0f482991c92ac86eee536eefd34 MD5 (FreeBSD-9.2-RC3-i386-memstick.img) = 47d9ab6b2cecd6791b4578e460259a27 ia64: SHA256 (FreeBSD-9.2-RC3-ia64-bootonly.iso) = 91608258d93a70c5941d927c10c0822b4e6b8a75b7493629b11caa765c6b57ce SHA256 (FreeBSD-9.2-RC3-ia64-disc1.iso) = 441978cbaaaf8e559ab3b856bad1ccacdca09d9a81e7fc1f6a3f8984191cdab9 SHA256 (FreeBSD-9.2-RC3-ia64-memstick.img) = d8506b3168fd5873515f0392afbfb525869cbf2b388580b749f39c845229eb5e MD5 (FreeBSD-9.2-RC3-ia64-bootonly.iso) = 781e8ac16d266cc1deaf9e9cbf795ffe MD5 (FreeBSD-9.2-RC3-ia64-disc1.iso) = 147bd004a65dfd565fb26dcb8101906f MD5 (FreeBSD-9.2-RC3-ia64-memstick.img) = db68dd2d741b483a015d123965b6f517 powerpc: SHA256 (FreeBSD-9.2-RC3-powerpc-bootonly.iso) = 56e66ae55cb475a7d075548393b1a0e71956a95dab3728645da569e2e0c94bdc SHA256 (FreeBSD-9.2-RC3-powerpc-disc1.iso) = f9abf5ee0b1fb9404219fe9fff577405875963d43fc5347cfdc5426e2036bfb3 SHA256 (FreeBSD-9.2-RC3-powerpc-memstick.img) = 65d284cbdeae605107e2c2799bd18de99dabbb9eb7989d1055e43fe9e97eca3d MD5 (FreeBSD-9.2-RC3-powerpc-bootonly.iso) = ce2b32e584adbfc82089674e41a97700 MD5 (FreeBSD-9.2-RC3-powerpc-disc1.iso) =
Re: 9.2-RC3 Now Available
Updated via svnup from releng/9.0 to releng/9.2 (r254910) and I got this in buildworld: cc1: warnings being treated as errors /usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log': /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaration of function 'strsvis' /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern declaration of 'strsvis' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error Shouldn't buildworld use includes from /usr/src and not from the installed system? signature.asc Description: OpenPGP digital signature
another? NFS deadlock on 9.2-PRERELEASE
I upgraded our web server, and only after 3 hours it hung :-( (as a side note, I have 2 other web servers, also running 9.2 doing great :-) go figure. anyways, in ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 is the info after a forced panic. my guts say its running out of resources - mainly network related, but can't pinpoint it. any help will be most welcomed cheers, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Stack overflow with kernel r254683
Hello, yesterday I got a kernel crash on my server (a ProLiant DL380 G5): panic: stack overflow detected; backtrace may be corrupted Kernel is 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #7 r254683 The stack trace reads: #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:249 #1 0xc0668a4d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xc0668f07 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xc0691da2 in __stack_chk_fail () at /usr/src/sys/kern/stack_protector.c:17 #4 0xc7fdb175 in nfsrvd_setattr (nd=0xc73b4400, isdgram=-952596480, vp=0xc8001140, p=0xf405ecc8, exp=0xc07af7f0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:371 #5 0xc7fdb6e0 in nfsrvd_releaselckown (nd=0xc7442a00, isdgram=-952596480, vp=0xc7388848, p=0xf405ecb8, exp=0x0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:3481 #6 0xc07af7f0 in svc_run_internal (pool=0xc7de8b80, ismaster=0) at /usr/src/sys/rpc/svc.c:1109 #7 0xc07b006d in svc_thread_start (arg=0xc7de8b80) at /usr/src/sys/rpc/svc.c:1200 #8 0xc06384f7 in fork_exit (callout=0xc07b0060 svc_thread_start, arg=0xc7de8b80, frame=0xf405ed08) at /usr/src/sys/kern/kern_fork.c:992 #9 0xc08787c4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:279 I have all the files in /var/crash, so if someone wants additional informations I should be able to deliver them. The kernel config file is customized in the sense that I have removed kernel items, that aren't used on that machine. One major difference: I use options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server instead of options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server because a kernel a few weeks ago immediately crashed with the new NFS-code. But it seems now, that the old NFS-code is also somehow damaged. Ah, and I still have from older releases of FreeBSD the following loader options - do they still make sense? geom_vinum_load=YES kern.maxdsiz=734003200 vm.pmap.shpgperproc=256 vm.pmap.pv_entry_max=3145728 'geom_vinum' is used as LVM only, no RAIDs are configured. This server is primarily a Samba server with the SMB-shares exported as NFS-shares as well for the other *nix-servers around. Because this is the most loaded production server, testing is a bit difficult, restricted to the evening and the weekends. On my two other FreeBSD machines I have no problems at all, one of them is an identical ProLiant server with a nearly identical kernel config - runs like a charm... Has someone a good advice or further questions? with best regards Matthias Schündehütte ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: if_em, legacy nic and GbE saturation
Am 26.08.2013 11:28, schrieb Harald Schmalzbauer: Bezüglich Adrian Chadd's Nachricht vom 26.08.2013 10:34 (localtime): Hi, There's bus limits on how much data you can push over a PCI bus. You can look around online to see what 32/64 bit, 33/66MHz PCI throughput estimates are. It changes massively if you use small versus large frames as well. The last time I tried it i couldn't hit gige on PCI; I only managed to get to around 350mbit doing TCP tests. Thanks, I'm roughly aware about the PCI bus limit, but I guess it should be good for almost GbE: 33*10^6*32=1056, so if one considers overhead and other bus-blocking things (nothing of significance is active on the PCI bus in this case), I'd expect at least 800Mbis/s, which is what I get with jumbo frames. But PCI bus throughput might be much lower than expected: - The arbitration overhead is quite high, in the order of 0.2 to 0.3us. - Depending on device capabilities and chip-set configuration and features there may be many more arbitration phases than one might expect. - A cache line flush is requested for data held in the CPU, unless the bus-master uses special transfer commands to indicate that the full cache line will be invalidated within the requested transfer. These overheads combined may reduce the effective PCI throughput to a fraction of the nominal performance (1/3 to 1/4 for bursts of 16 bytes). The minimum grant value is the minimum burst length the device wants (to avoid a buffer underrun/overrun due to too low effective bandwidth) the maximum latency corresponds to the number of PCI clocks the device is willing to wait for the bus to be granted (to avoid buffer underrun/overrun while waiting to get access to the bus granted). The maximum latency value is useful to calculate the maximum arbitration unit for which no device is stalled longer than allowed by MAXLAT. MINGNT and MAXLAT of a device can be displayed with pciconf: # pciconf -r -b pci0:1:0 0x3e:0x3f (e.g., for bus 0 device 1 function 0) The PCI bus will be lost whenever another device gets access to the bus, whether CPU or another PCI (or PCIe) device. Especially when simultanously sending and receiving packets with two Ethernet controllers, bus arbitration will occur for every 16 to 32 transfers (depending on bus arbiter settings and programmed MINGNT). Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RELENG_9 build error
Does anyone have any idea how to correct this issue ? Already blew away /usr/src and /usr/obj in case something got corrupted. cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o ed buf.o cbc.o glbl.o io.o main.o re.o sub.o undo.o -lcrypto gzip -cn /usr/src/bin/ed/ed.1 ed.1.gz === bin/expr (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c expr.c cc1: warnings being treated as errors expr.c:812: warning: redundant redeclaration of 'yyparse' /usr/src/bin/expr/expr.y:77: warning: previous declaration of 'yyparse' was here *** [expr.o] Error code 1 Stop in /usr/src/bin/expr. *** [all] Error code 1 Stop in /usr/src/bin. *** [bin.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. 1(cage)# cd /usr -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_9 build error
On Mon, 26 Aug 2013 15:07:42 -0400 Mike Tancsa wrote: Does anyone have any idea how to correct this issue ? Already blew away /usr/src and /usr/obj in case something got corrupted. I think I've resolved this issue by rebuilding and reinstalling yacc from /usr/src/usr.bin/yacc before running 'make buildworld'. -- Herbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_9 build error
On Mon, 26 Aug 2013 15:07:42 -0400 Mike Tancsa m...@sentex.net wrote: Does anyone have any idea how to correct this issue ? Already blew away /usr/src and /usr/obj in case something got corrupted. Taking it you mean stable/9 by RELENG_9, it can be ``fixed'' by updating your sources, to any revision more recent than r254669 (which reverted the breaking commit) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Change in loader or kernel: won't boot with kfreebsd in grub2
On Sun, Aug 25, 2013 at 03:35:06PM -0700, Thomas Mueller wrote: On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: Some updates: I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. That failed (invalid signature). You probably need to chainload a freebsd-boot partition, _if_ you want to chainload at all. I was trying to chainload the freebsd-boot partition! But grub2 didn't like it. Hmm I guess it doesn't know about that partition type yet then... I could also try kfreebsd /boot/kernel/kernel That failed to boot the proper partition, went to the debugger (db), whereupon all I could type was reboot. You didn't get a mountroot prompt? If you did you can try typing a question mark and return, that should list possible partitions to mount root from. If you didn't, or you don't want to do this manually you need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, or wherever your root partition is. I remember pressing a key, but then the system rushed past the mountroot prompt into the debugger prompt. If you pressed return w/o typing anything I guess that's what will happen... Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? gpart -p /boot/boot -i 3 That would be for /dev/ada0p3, but I am afraid of damaging something. That would need to be on a freebsd-boot partition, and you want /boot/gptboot not /boot/boot. I believe bsdlabel can be used to install boot code to a partition, but believe that is not for GPT. Indeed. I could try bsdlabel on a giant floppy image as I used installboot on a giant floppy image for NetBSD. Uhm, why not just get grub2 kfreebsd booting working? Best, Juergen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9-STABLE, clang, and virtualbox
I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* Imagination is not a talent of some men, but it is the health of every man. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE, clang, and virtualbox
On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) What is the svn revision of your /usr/src/ checkout? Glen pgpH0FEQU6LAY.pgp Description: PGP signature
Re: RELENG_9 build error
On 8/26/2013 3:59 PM, Schaich Alonso wrote: On Mon, 26 Aug 2013 15:07:42 -0400 Mike Tancsa m...@sentex.net wrote: Does anyone have any idea how to correct this issue ? Already blew away /usr/src and /usr/obj in case something got corrupted. Taking it you mean stable/9 by RELENG_9, it can be ``fixed'' by updating your sources, to any revision more recent than r254669 (which reverted the breaking commit) Actually, I had done that. The correct solution was to rebuild and install yacc first (as suggested by Herbert), as I was running FreeBSD 9.2-PRERELEASE #0 r254663 So the bogus yacc was installed and I needed to clobber that. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: another? NFS deadlock on 9.2-PRERELEASE
Daniel Braniss wrote: I upgraded our web server, and only after 3 hours it hung :-( (as a side note, I have 2 other web servers, also running 9.2 doing great :-) go figure. anyways, in ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 is the info after a forced panic. Looks like the same hang to me. Several threads are sleeping on pgrbwt and lots are waiting for an NFS vnode lock. It should be fixed in RC3 (or revert r250907). If it still hangs with RC3 (or r250907 reverted), email again. rick my guts say its running out of resources - mainly network related, but can't pinpoint it. any help will be most welcomed cheers, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE, clang, and virtualbox
On 08/26/13 13:16, Glen Barber wrote: On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) What is the svn revision of your /usr/src/ checkout? 251391. See the uname above. :) -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* A question about the sky -- The answer about a rope. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE, clang, and virtualbox
On Mon, Aug 26, 2013 at 02:16:39PM -0700, Dave Hayes wrote: On 08/26/13 13:16, Glen Barber wrote: On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) What is the svn revision of your /usr/src/ checkout? 251391. See the uname above. :) That does not mean your current checkout matches that revision. Glen pgpWwSpyRacFE.pgp Description: PGP signature
Re: 9-STABLE, clang, and virtualbox
On 08/26/13 14:21, Glen Barber wrote: On Mon, Aug 26, 2013 at 02:16:39PM -0700, Dave Hayes wrote: On 08/26/13 13:16, Glen Barber wrote: On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) What is the svn revision of your /usr/src/ checkout? 251391. See the uname above. :) That does not mean your current checkout matches that revision. In my case it doesI checked with svn info before I sent the mail. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* Only one who is seeking certainty can be uncertain. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Stack overflow with kernel r254683
Matthias Schuendehuette wrote: Hello, yesterday I got a kernel crash on my server (a ProLiant DL380 G5): panic: stack overflow detected; backtrace may be corrupted Kernel is 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #7 r254683 The stack trace reads: #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:249 #1 0xc0668a4d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xc0668f07 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xc0691da2 in __stack_chk_fail () at /usr/src/sys/kern/stack_protector.c:17 #4 0xc7fdb175 in nfsrvd_setattr (nd=0xc73b4400, isdgram=-952596480, vp=0xc8001140, p=0xf405ecc8, exp=0xc07af7f0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:371 #5 0xc7fdb6e0 in nfsrvd_releaselckown (nd=0xc7442a00, isdgram=-952596480, vp=0xc7388848, p=0xf405ecb8, exp=0x0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:3481 #6 0xc07af7f0 in svc_run_internal (pool=0xc7de8b80, ismaster=0) at /usr/src/sys/rpc/svc.c:1109 #7 0xc07b006d in svc_thread_start (arg=0xc7de8b80) at /usr/src/sys/rpc/svc.c:1200 #8 0xc06384f7 in fork_exit (callout=0xc07b0060 svc_thread_start, arg=0xc7de8b80, frame=0xf405ed08) at /usr/src/sys/kern/kern_fork.c:992 #9 0xc08787c4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:279 Well, when I've looked on i386, the nfsd threads normally don't use 1 page and the stacks are 2 pages, so I doubt an nfsd thread is blowing the stack. Also, nfsrvd_releaselckown() doesn't call nfsrvd_setattr(), so the backtrace doesn't make much sense. Afraid I can't help more than this. Good luck with it, rick I have all the files in /var/crash, so if someone wants additional informations I should be able to deliver them. The kernel config file is customized in the sense that I have removed kernel items, that aren't used on that machine. One major difference: I use options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server instead of options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server because a kernel a few weeks ago immediately crashed with the new NFS-code. But it seems now, that the old NFS-code is also somehow damaged. Ah, and I still have from older releases of FreeBSD the following loader options - do they still make sense? geom_vinum_load=YES kern.maxdsiz=734003200 vm.pmap.shpgperproc=256 vm.pmap.pv_entry_max=3145728 'geom_vinum' is used as LVM only, no RAIDs are configured. This server is primarily a Samba server with the SMB-shares exported as NFS-shares as well for the other *nix-servers around. Because this is the most loaded production server, testing is a bit difficult, restricted to the evening and the weekends. On my two other FreeBSD machines I have no problems at all, one of them is an identical ProLiant server with a nearly identical kernel config - runs like a charm... Has someone a good advice or further questions? with best regards Matthias Schündehütte ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Stack overflow with kernel r254683
On Mon, Aug 26, 2013 at 07:11:48PM -0400, Rick Macklem wrote: Matthias Schuendehuette wrote: Hello, yesterday I got a kernel crash on my server (a ProLiant DL380 G5): panic: stack overflow detected; backtrace may be corrupted Kernel is 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #7 r254683 The stack trace reads: #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:249 #1 0xc0668a4d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xc0668f07 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xc0691da2 in __stack_chk_fail () at /usr/src/sys/kern/stack_protector.c:17 #4 0xc7fdb175 in nfsrvd_setattr (nd=0xc73b4400, isdgram=-952596480, vp=0xc8001140, p=0xf405ecc8, exp=0xc07af7f0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:371 #5 0xc7fdb6e0 in nfsrvd_releaselckown (nd=0xc7442a00, isdgram=-952596480, vp=0xc7388848, p=0xf405ecb8, exp=0x0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:3481 #6 0xc07af7f0 in svc_run_internal (pool=0xc7de8b80, ismaster=0) at /usr/src/sys/rpc/svc.c:1109 #7 0xc07b006d in svc_thread_start (arg=0xc7de8b80) at /usr/src/sys/rpc/svc.c:1200 #8 0xc06384f7 in fork_exit (callout=0xc07b0060 svc_thread_start, arg=0xc7de8b80, frame=0xf405ed08) at /usr/src/sys/kern/kern_fork.c:992 #9 0xc08787c4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:279 Well, when I've looked on i386, the nfsd threads normally don't use 1 page and the stacks are 2 pages, so I doubt an nfsd thread is blowing the stack. It is overflowing the frame, not the whole stack. In other word, something overwrote the canary which was put on the stack between local variables and the return address, possibly corrupting the return address as well. Also, nfsrvd_releaselckown() doesn't call nfsrvd_setattr(), so the backtrace doesn't make much sense. Yes, this might be one of the consequences of the stack smashing. Afraid I can't help more than this. Good luck with it, rick I have all the files in /var/crash, so if someone wants additional informations I should be able to deliver them. The kernel config file is customized in the sense that I have removed kernel items, that aren't used on that machine. One major difference: I use options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server instead of options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server because a kernel a few weeks ago immediately crashed with the new NFS-code. But it seems now, that the old NFS-code is also somehow damaged. Ah, and I still have from older releases of FreeBSD the following loader options - do they still make sense? geom_vinum_load=YES kern.maxdsiz=734003200 vm.pmap.shpgperproc=256 vm.pmap.pv_entry_max=3145728 'geom_vinum' is used as LVM only, no RAIDs are configured. This server is primarily a Samba server with the SMB-shares exported as NFS-shares as well for the other *nix-servers around. Because this is the most loaded production server, testing is a bit difficult, restricted to the evening and the weekends. On my two other FreeBSD machines I have no problems at all, one of them is an identical ProLiant server with a nearly identical kernel config - runs like a charm... Has someone a good advice or further questions? with best regards Matthias Sch??ndeh??tte ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org pgpYfAs_z36Ei.pgp Description: PGP signature
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime): Hi, I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a lot of cleanup, bug fixes, new features, etc (+2000 new lines) along the way so there is not much of a resemblance left. The driver is in good enough shape I'd like additional testers. A patch against -CURRENT is at [1]. Alternatively, the driver and a Makefile is at [2]; this should compile at least as far back as 9.1. I can look at 8-STABLE if there is interest. Obviously, besides reports of 'it works', I'm interested performance vs the emulated e1000, and (for those using it) the VMware tools vmxnet3 driver. Hopefully it is no worse :) Hello Bryan, thanks a lot for your hard work! It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get »vmx0: cannot populate Rx queue 0«, I have no problems using jumbo frames with vmxnet3. This could fail for two reasons - could not allocate an mbuf cluster, or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf_sg() changed between 9.1 and 9.2, and I know it was broken for awhile. I don't recall exactly when I fixed it (I think shortly after I made the original announcement). Could you retry with the files from HEAD @ [1]? Also, there are new sysctl oids (dev.vmx.X.mbuf_load_failed dev.vmx.X.mgetcl_failed) for these errors. I just compiled the driver on 9.2-RC2 with the sources from HEAD and was able to change the MTU to 9000. [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi 5.1U1 and FreeBSD-9.2-RC2 Two guests are connected to one MTU9000 VMware Software Switch. I've got a few performance things to still look at. What's the sysctl dev.vmx.X output for the if_vmx-if_vmx tests? Simple iperf (standard TCP) results: vmxnet3jumbo - vmxnet3jumbo 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr vmxnet3 - vmxnet3 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr if_vmx - if_vmx 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr !!! if_vmxjumbo - if_vmxjumbo not possible if_em(e1000) - if_em(e1000) 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr if_em(e1000)jumbo - if_em(e1000)jumbo 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr if_igb(e1000e)junmbo - if_igb(e1000e)jumbo 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr if_igb(e1000e) - if_igb(e1000e) 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr f_igb(e1000e) - if_igb(e1000e), both hw.em.[rt]xd=4096 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr if_igb(e1000e)junmbo - if_igb(e1000e)jumbo, both hw.em.[rt]xd=4096 4.81 Gbits/s, load: 65%Sys 0.5%Intr Conclusion: if_vmx performs well compared to the regular emulated nics and standard MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3 performance with regular mtu. If one needs throughput, the missing jumbo frame support in if_vmx is a show stopper. e1000e is preferable over e1000, even if not officially choosable with FreeBSD-selection as guest (edit .vmx and alter ethernet0.virtualDev = e1000e, and dont forget to set hw.em.enable_msix=0 in loader.conf, although the driver e1000e attaches is if_igb!) Thanks, -Harry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Vos nouveaux tarifs panneaux Akilux et impression brochures
Cette newsletter vous a été envoyée au format graphique HTML. Si vous lisez cette version, alors votre logiciel de messagerie préfère les e-mails au format texte. Vous pouvez lire la version originale en ligne: http://ymlp225.net/z2Sppv Nouveaux tarifs panneaux akilux, livraison gratuite Acceder directement sur le site ( http://www.flyers.entreprise-com.fr/page/61676 ) Nous proposons tous les formats et decoupes e personnalisées sur demande Télécharger tout les tarifs en PDF ( http://www.flyers.entreprise-com.fr/upload/21juin/tarifs_akilux_septembre_2013.pdf ) Tarifs panneaux akilux sans oeillet Panneaux 30x40 Panneau 40x60 Panneau 60x80 R° R°V° R° R°/V° R° R°V° 2 22 € 23 € 23 € 25 € 26 € 30 € 4 24 € 27 € 27 € 31 € 33 € 40 € 6 27 € 31 € 31 € 36 € 40 € 50 € 8 29 € 34 € 34 € 42 € 46 € 60 € 10 32 € 38 € 38 € 48 € 53 € 70 € 15 38 € 48 € 48 € 62 € 70 € 95 € 20 44 € 57 € 57 € 76 € 87 € 116 € 30 57 € 76 € 76 € 100 € 116 € 146 € 35 63 € 85 € 85 € 113 € 132 € 170 € 40 69 € 94 € 94 € 127 € 140 € 194 € 50 82 € 109 € 109 € 135 € 162 € 233 € 75 109 € 135 € 135 € 194 € 233 € 341 € 100 120 € 180 € 180 € 259 € 311 € 432 € 125 150 € 216 € 216 € 324 € 379 € 513 € 150 180 € 259 € 259 € 360 € 432 € 575 € 175 202 € 302 € 302 € 399 € 479 € 626 € 200 230 € 337 € 337 € 433 € 520 € 680 € 250 288 € 421 € 421 € 515 € 596 € 807 € 300 337 € 480 € 480 € 567 € 680 € 920 € 350 393 € 532 € 523 € 628 € 754 € 1 020 € 400 449 € 568 € 558 € 682 € 818 € 1 108 € 450 497 € 596 € 596 € 729 € 874 € 1 221 € 500 552 € 630 € 630 € 769 € 976 € 1 330 € 600 629 € 718 € 718 € 877 € 1 172 € 1 564 € 700 685 € 795 € 795 € 972 € 1 367 € 1 803 € 800 744 € 864 € 864 € 1 085 € 1 562 € 2 061 € 900 795 € 923 € 915 € 1 220 € 1 757 € 2 319 € 1000 839 € 974 € 1 016 € 1 356 € 1 953 € 2 576 € Tarifs panneaux akilux avec oeillet Panneaux 30x40 Panneau 40x60 Panneau 60x80 R° R°/ V° R° R° /V° R° R°/V° 2 24 € 25 € 25 € 27 € 28 € 32 € 4 28 € 31 € 31 € 35 € 37 € 44 € 6 33 € 37 € 37 € 42 € 46 € 56 € 8 37 € 42 € 42 € 50 € 54 € 68 € 10 42 € 48 € 48 € 58 € 63 € 80 € 15 53 € 63 € 63 € 77 € 85 € 110 € 20 64 € 77 € 77 € 96 € 107 € 136 € 30 87 € 106 € 106 € 130 € 146 € 176 € 35 98 € 120 € 120 € 148 € 167 € 205 € 40 109 € 134 € 134 € 167 € 180 € 234 € 50 132 € 159 € 159 € 185 € 212 € 283 € 75 184 € 210 € 210 € 269 € 308 € 416 € 100 220 € 280 € 280 € 359 € 411 € 532 € 125 275 € 341 € 341 € 449 € 504 € 638 € 150 330 € 409 € 409 € 510 € 582 € 725 € 175 377 € 477 € 477 € 574 € 654 €
