From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 15:40:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF6B9106566B for ; Sun, 20 Nov 2011 15:40:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 915998FC0C for ; Sun, 20 Nov 2011 15:40:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RS9V0-00054m-1C for freebsd-stable@freebsd.org; Sun, 20 Nov 2011 16:40:06 +0100 Received: from dyn1243-74.vpn.ic.ac.uk ([129.31.243.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2011 16:40:06 +0100 Received: from johannes by dyn1243-74.vpn.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2011 16:40:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Johannes Totz Date: Sun, 20 Nov 2011 15:34:36 +0000 Lines: 1695 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1243-74.vpn.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 Subject: panic: make_dev_credv: bad si_name (error=17, si_name=pass2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 15:40:08 -0000 Hi! (Sent twice, first one bounced...) Just got a panic on 9-stable, running inside VirtualBox, trying to build a release-set. Don't know yet if reproducable, just happened a few minutes ago. The whole core.txt stuff follows below (beware of line-breaks): zfstest dumped core - see /var/crash/vmcore.1 Sat Nov 19 10:51:49 UTC 2011 FreeBSD zfstest 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0 r227727: Sat Nov 19 07:52:17 UTC 2011 root@zfstest:/usr/obj/usr/src/sys/GENERIC i386 panic: make_dev_credv: bad si_name (error=17, si_name=pass2) 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: (ada1:ahcich0:0:0:0): lost device panic: make_dev_credv: bad si_name (error=17, si_name=pass2) cpuid = 0 KDB: stack backtrace: #0 0xc0a4aff7 at kdb_backtrace+0x47 #1 0xc0a185c7 at panic+0x117 #2 0xc09d05de at make_dev_credv+0x9e #3 0xc09d080a at make_dev+0x4a #4 0xc04b79e0 at passregister+0x230 #5 0xc048ece3 at cam_periph_alloc+0x4e3 #6 0xc04b7525 at passasync+0x85 #7 0xc0490442 at xpt_async_bcast+0x32 #8 0xc0492715 at xpt_async+0x105 #9 0xc04991f3 at probedone+0xc33 #10 0xc04958a1 at camisr_runqueue+0x2e1 #11 0xc04959ff at camisr+0x13f #12 0xc09ed69b at intr_event_execute_handlers+0x13b #13 0xc09eee5a at ithread_loop+0x7a #14 0xc09ea8a7 at fork_exit+0x97 #15 0xc0d32734 at fork_trampoline+0x8 Uptime: 7m57s (ada1:ahcich0:0:0:0): Synchronize cache failed Physical memory: 495 MB Dumping 409 MB: 394 378 362 346 330 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc0a1836a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:442 #2 0xc0a18601 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:607 #3 0xc09d05de in make_dev_credv (flags=0, dres=0xc2ea8700, devsw=Variable "devsw" is not available. ) at /usr/src/sys/kern/kern_conf.c:759 #4 0xc09d080a in make_dev (devsw=0xc0f52340, unit=2, uid=0, gid=5, mode=384, fmt=0xc0d77b8c "%s%d") at /usr/src/sys/kern/kern_conf.c:816 #5 0xc04b79e0 in passregister (periph=0xd8658600, arg=0xc33fc000) at /usr/src/sys/cam/scsi/scsi_pass.c:335 #6 0xc048ece3 in cam_periph_alloc (periph_ctor=0xc04b77b0 , periph_oninvalidate=0xc04b75e0 , periph_dtor=0xc04b7ad0 , periph_start=0xc04b75a0 , name=0xc0d9bcef "pass", type=CAM_PERIPH_BIO, path=0xc7f58bd0, ac_callback=0xc04b74a0 , code=AC_FOUND_DEVICE, arg=0xc33fc000) at /usr/src/sys/cam/cam_periph.c:243 #7 0xc04b7525 in passasync (callback_arg=0x0, code=128, path=0xc3a737e0, arg=0xc33fc000) at /usr/src/sys/cam/scsi/scsi_pass.c:236 #8 0xc0490442 in xpt_async_bcast (async_head=0x0, async_code=128, path=0xc3a737e0, async_arg=0xc33fc000) at /usr/src/sys/cam/cam_xpt.c:4037 #9 0xc0492715 in xpt_async (async_code=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/cam/cam_xpt.c:4016 #10 0xc04991f3 in probedone (periph=0xd8658280, done_ccb=0xc33fc000) at /usr/src/sys/cam/ata/ata_xpt.c:1075 #11 0xc04958a1 in camisr_runqueue (V_queue=Variable "V_queue" is not available. ) at /usr/src/sys/cam/cam_xpt.c:4960 #12 0xc04959ff in camisr (dummy=0x0) at /usr/src/sys/cam/cam_xpt.c:4863 #13 0xc09ed69b in intr_event_execute_handlers (p=0xc3172588, ie=0xc327c080) at /usr/src/sys/kern/kern_intr.c:1257 #14 0xc09eee5a in ithread_loop (arg=0xc3171bb0) at /usr/src/sys/kern/kern_intr.c:1270 #15 0xc09ea8a7 in fork_exit (callout=0xc09eede0 , arg=0xc3171bb0, frame=0xc2ea8d28) at /usr/src/sys/kern/kern_fork.c:995 #16 0xc0d32734 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs ?? 0:00.05 [kernel] 0 1 0 0 20 0 8032 1955216 wait DLs ?? 0:00.02 [init] 0 2 0 0 -16 0 0 0 waitin DL ?? 0:00.00 [sctp_itera 0 3 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 4 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [pagedaemon 0 5 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [vmdaemon] 0 6 0 0 155 0 0 0 pgzero DL ?? 0:00.00 [pagezero] 0 7 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [bufdaemon] 0 8 0 0 -16 0 0 0 vlruwt DL ?? 0:00.00 [vnlru] 0 9 0 0 16 0 0 0 zio->i DL ?? 0:00.00 [syncer] 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL ?? 0:03.80 [idle] 0 12 0 0 -84 0 0 0 - WL ?? 0:00.09 [intr] 0 13 0 0 -8 0 0 0 - DL ?? 0:00.15 [geom] 0 14 0 0 -16 0 0 0 - DL ?? 0:00.03 [yarrow] 0 15 0 0 -68 0 0 0 - DL ?? 0:00.01 [usb] 0 16 0 0 -16 0 0 0 sdflus DL ?? 0:00.00 [softdepflu 0 34 0 0 -8 0 0 0 zio->i DL ?? 0:00.00 [zfskern] 0 499 1 0 52 0 9540 1958928 select Ds ?? 0:00.00 [dhclient] 65 554 1 0 52 0 9540 1951504 select Ds ?? 0:00.00 [dhclient] 0 569 1 0 52 0 12128 1962640 select Ds ?? 0:00.00 [devd] 0 709 1 0 20 0 9616 1950576 select Ds ?? 0:00.01 [syslogd] 0 955 1 0 20 0 11324 1963568 select Ds ?? 0:00.01 [sendmail] 25 959 1 0 52 0 11324 1954288 pause Ds ?? 0:00.01 [sendmail] 0 965 1 0 20 0 9644 1964496 nanslp Ds ?? 0:00.00 [cron] 0 1023 1 0 52 0 9616 1957072 ttyin Ds+ ?? 0:00.01 [getty] 0 1024 1 0 24 0 10124 1960784 wait Ds ?? 0:00.01 [login] 0 1025 1 0 52 0 9616 1952432 ttyin Ds+ ?? 0:00.01 [getty] 0 1026 1 0 52 0 9616 1966960 ttyin Ds+ ?? 0:00.01 [getty] 0 1027 1 0 52 0 9616 1958000 ttyin Ds+ ?? 0:00.00 [getty] 0 1028 1 0 52 0 9616 1956144 ttyin Ds+ ?? 0:00.01 [getty] 0 1029 1 0 52 0 9616 1739440 ttyin Ds+ ?? 0:00.01 [getty] 0 1030 1 0 52 0 9616 1738512 ttyin Ds+ ?? 0:00.00 [getty] 0 1031 1024 0 20 0 10940 1979024 pause D ?? 0:00.02 [csh] 0 1555 1031 0 42 0 8032 1978096 wait D+ ?? 0:00.00 [make] 0 1558 1555 0 52 0 8032 1972528 wait D+ ?? 0:00.00 [make] 0 1560 1558 0 52 0 8032 1971600 wait D+ ?? 0:00.00 [make] 0 1564 1560 0 52 0 8032 1979952 wait D+ ?? 0:00.00 [make] 0 1691 1564 0 52 0 9924 1737584 wait D+ ?? 0:00.00 [sh] 0 1692 1691 0 52 0 8032 1975312 wait D+ ?? 0:00.00 [make] 0 1700 1692 0 52 0 8032 1973456 wait D+ ?? 0:00.00 [make] 0 1715 1700 0 36 0 9924 1747792 wait D+ ?? 0:00.00 [sh] 0 21858 1715 0 52 0 8032 1740368 wait D+ ?? 0:00.00 [make] 0 21860 21858 0 52 0 9924 3241200 zio->i D+ ?? 0:00.00 [sh] ------------------------------------------------------------------------ vmstat -s 359992 cpu context switches 233650 device interrupts 56121 software interrupts 1863866 traps 1702573 system calls 17 kernel threads created 14863 fork() calls 7306 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 834 vnode pager pageins 2373 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 233 pages reactivated 340712 copy-on-write faults 244 copy-on-write optimized faults 1032155 zero fill pages zeroed 63531 zero fill pages prezeroed 3 intransit blocking page faults 1789980 total VM faults taken 0 pages affected by kernel thread creation 14155206 pages affected by fork() 6606983 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 1842752 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 3425 pages active 1746 pages inactive 0 pages in VM cache 97451 pages wired down 21727 pages free 4096 bytes per page 2191000 total name lookups cache hits (91% pos + 3% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) LED 2 1K - 2 16,64 feeder 7 1K - 7 16 acpiintr 1 1K - 1 32 isadev 9 1K - 9 64 acpica 2073 119K - 29726 16,32,64,128,256,512,1024,4096 cdev 8 1K - 8 128 acpitask 1 1K - 1 1024 sigio 1 1K - 1 32 filedesc 44 11K - 22187 256 kenv 110 9K - 121 16,32,64,128,4096 kqueue 0 0K - 26 128,1024 CAM dev queue 4 1K - 4 128 proc-args 24 2K - 22341 16,32,64,128,256 hhook 2 1K - 2 128 ithread 52 5K - 52 16,64,128 CAM queue 18 1K - 66 16,128 KTRACE 100 13K - 100 128 acpisem 16 2K - 16 64,128 linker 168 1642K - 199 16,32,256,1024,4096 lockf 17 1K - 29 32,64 loginclass 2 1K - 5 64 ip6ndp 4 1K - 4 64,128 temp 13 157K - 45052 16,32,64,128,256,512,1024,2048,4096 devbuf 1285 3079K - 1301 16,32,64,128,256,512,1024,2048,4096 module 497 32K - 497 64,128 mtx_pool 2 8K - 2 4096 osd 3 1K - 4 16,32 CAM SIM 4 1K - 4 128 subproc 110 193K - 22253 256,4096 proc 2 4K - 2 2048 session 16 1K - 20 64 pgrp 18 2K - 25 64 cred 38 4K - 86114 64,128 uidinfo 4 1K - 7 64,512 plimit 20 5K - 1930 256 scsi_cd 0 0K - 6 16 CAM periph 9 2K - 25 16,32,64,128 CAM XPT 59 43K - 134 16,32,64,1024,2048 sysctltmp 0 0K - 346 16,32,64,128,4096 sysctloid 2259 68K - 2296 16,32,64 sysctl 0 0K - 7804 16,32,64 tidhash 1 4K - 1 4096 umtx 470 45K - 470 64,128 p1003.1b 1 1K - 1 16 SWAP 2 277K - 2 64 bus-sc 34 51K - 1363 16,64,128,256,512,1024,2048,4096 bus 991 42K - 3022 16,32,64,128,256,1024 devstat 6 13K - 6 16,4096 eventhandler 84 5K - 84 32,64,128 kobj 358 716K - 418 2048 Per-cpu 1 1K - 1 16 ata_pci 1 1K - 1 32 rman 90 6K - 244 32,64 sbuf 0 0K - 666 16,32,64,128,256,512,1024,2048,4096 stack 0 0K - 2 128 taskqueue 57 3K - 87 16,32,64,512 Unitno 14 1K - 3164 16,64 iov 0 0K - 644 64,128,256 select 7 1K - 7 64 ioctlops 0 0K - 18328 16,32,64,128,256,512,1024 msg 4 25K - 4 1024,4096 sem 4 101K - 4 1024,4096 shm 1 12K - 1 tty 19 10K - 21 512,1024 mbuf_tag 0 0K - 18 32 shmfd 1 4K - 1 4096 pcb 15 79K - 36 16,64,512,1024,2048,4096 soname 3 1K - 159 16,32,128 biobuf 182 364K - 186 2048 vfscache 1 256K - 1 cl_savebuf 0 0K - 11 32,64 vfs_hash 1 128K - 1 acpidev 27 1K - 27 32 vnodes 2 1K - 2 128 vnodemarker 0 0K - 246 512 mount 86 3K - 208 16,32,64,128,256 BPF 8 9K - 8 64,128,256,4096 ether_multi 15 1K - 22 16,32,64 ifaddr 35 8K - 36 16,32,64,128,256,512,2048 ifnet 4 4K - 4 64,1024 USBdev 4 2K - 4 32,128,1024 clone 6 24K - 6 4096 arpcom 1 1K - 1 16 lltable 10 3K - 10 128,256 USB 7 2K - 7 16,32,64,1024 routetbl 31 4K - 87 16,32,64,128,256 igmp 3 1K - 3 128 in_multi 2 1K - 3 128 sctp_iter 0 0K - 3 256 sctp_ifn 2 1K - 2 128 sctp_ifa 4 1K - 4 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 3 16 hostcache 1 16K - 1 syncache 1 72K - 1 entropy 1024 64K - 1024 64 in6_multi 12 2K - 12 16,256 pci_link 8 1K - 8 16,128 mld 3 1K - 3 128 rpc 2 1K - 2 128 audit_evclass 179 3K - 218 16 savedino 0 0K - 23 256 freework 1 1K - 11 32,128 newdirblk 0 0K - 4 32 dirrem 0 0K - 22 64 mkdir 0 0K - 8 64 diradd 0 0K - 32 64 freefile 0 0K - 13 32 freeblks 0 0K - 10 128 freefrag 0 0K - 2 64 newblk 1 16K - 24 128 bmsafemap 1 4K - 11 128,4096 inodedep 1 128K - 50 256 pagedep 1 16K - 11 128 ufs_dirhash 39 8K - 42 16,32,64,128,512 ufs_mount 9 19K - 9 256,2048,4096 vm_pgdata 2 33K - 2 64 DEVFS1 82 21K - 88 256 atkbddev 2 1K - 2 32 DEVFS3 95 12K - 105 128 DEVFS 18 1K - 19 16,64 DEVFSP 1 1K - 1 32 apmdev 1 1K - 1 64 pfs_nodes 21 3K - 21 128 nexusdev 3 1K - 3 16 GEOM 74 18K - 462 16,32,64,128,512,1024,2048 kbdmux 6 18K - 6 16,256,1024,2048 solaris 81901 312538K - 1780499 16,32,64,128,256,512,1024,2048,4096 kstat_data 4 1K - 4 32 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 128, 0, 182, 28, 182, 0, 0 UMA Zones: 152, 0, 182, 10, 182, 0, 0 UMA Slabs: 284, 0, 15396, 2594, 39478, 0, 0 UMA RCntSlabs: 544, 0, 195, 1, 195, 0, 0 UMA Hash: 128, 0, 82, 8, 82, 0, 0 16 Bucket: 76, 0, 22, 28, 62, 0, 0 32 Bucket: 140, 0, 14, 42, 55, 0, 0 64 Bucket: 268, 0, 12, 16, 92, 30, 0 128 Bucket: 524, 0, 73, 74, 2338, 657, 0 VM OBJECT: 136, 0, 8745, 2333, 315488, 0, 0 MAP: 140, 0, 7, 21, 7, 0, 0 KMAP ENTRY: 72, 31482, 2056, 170, 91029, 0, 0 MAP ENTRY: 72, 0, 344, 133, 519624, 0, 0 fakepg: 72, 0, 0, 0, 0, 0, 0 mt_zone: 2060, 0, 306, 125, 306, 0, 0 16: 16, 0, 13191, 816, 177976, 0, 0 32: 32, 0, 15070, 32051, 508817, 0, 0 64: 64, 0, 15556, 3737, 541209, 0, 0 128: 128, 0, 8457, 3993, 169411, 0, 0 256: 256, 0, 757, 1148, 124184, 0, 0 512: 512, 0, 24866, 806, 426184, 0, 0 1024: 1024, 0, 734, 154, 9730, 0, 0 2048: 2048, 0, 5160, 408, 13894, 0, 0 4096: 4096, 0, 2075, 384, 53606, 0, 0 Files: 56, 0, 48, 86, 124721, 0, 0 TURNSTILE: 72, 0, 236, 34, 236, 0, 0 umtx pi: 52, 0, 0, 0, 0, 0, 0 MAC labels: 20, 0, 0, 0, 0, 0, 0 PROC: 708, 0, 43, 22, 22186, 0, 0 THREAD: 728, 0, 233, 2, 369, 0, 0 SLEEPQUEUE: 44, 0, 236, 59, 236, 0, 0 VMSPACE: 232, 0, 27, 41, 22171, 0, 0 cpuset: 40, 0, 2, 182, 2, 0, 0 audit_record: 824, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 256, 141, 280, 0, 0 mbuf: 256, 0, 1, 140, 88, 0, 0 mbuf_cluster: 2048, 16832, 384, 6, 384, 0, 0 mbuf_jumbo_page: 4096, 8416, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 12624, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 8416, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 140, 0, 16, 208, 72396, 0, 0 ttyinq: 152, 0, 120, 36, 255, 0, 0 ttyoutq: 256, 0, 64, 11, 136, 0, 0 ata_request: 208, 0, 1, 37, 12429, 0, 0 ata_composite: 180, 0, 0, 0, 0, 0, 0 VNODE: 272, 0, 10955, 973, 35105, 0, 0 VNODEPOLL: 60, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 1, 11, 405356, 0, 0 S VFS Cache: 72, 0, 8577, 6687, 79664, 0, 0 L VFS Cache: 292, 0, 1, 129, 462, 0, 0 NCLNODE: 372, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 52, 4, 54, 0, 0 pipe: 400, 0, 1, 19, 785, 0, 0 Mountpoints: 648, 0, 8, 10, 8, 0, 0 ksiginfo: 80, 0, 56, 88, 72, 0, 0 itimer: 220, 0, 0, 0, 0, 0, 0 KNOTE: 72, 0, 0, 106, 26, 0, 0 socket: 416, 16839, 11, 16, 143, 0, 0 unpcb: 172, 16836, 6, 40, 30, 0, 0 ipq: 32, 565, 0, 0, 0, 0, 0 udp_inpcb: 252, 16845, 2, 28, 100, 0, 0 udpcb: 8, 16849, 2, 201, 100, 0, 0 tcp_inpcb: 252, 16845, 1, 29, 3, 0, 0 tcpcb: 688, 16835, 1, 9, 3, 0, 0 tcptw: 52, 3384, 0, 0, 0, 0, 0 syncache: 120, 15360, 0, 0, 0, 0, 0 hostcache: 76, 15400, 0, 0, 0, 0, 0 tcpreass: 20, 1183, 0, 0, 0, 0, 0 sackhole: 20, 0, 0, 0, 0, 0, 0 sctp_ep: 924, 16832, 0, 0, 0, 0, 0 sctp_asoc: 1500, 40000, 0, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 145, 3, 0, 0 sctp_raddr: 496, 80000, 0, 0, 0, 0, 0 sctp_chunk: 96, 400000, 0, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0, 0 sctp_stream_msg_out: 72, 400044, 0, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0, 0 ripcb: 252, 16845, 1, 29, 1, 0, 0 rtentry: 108, 0, 13, 59, 14, 0, 0 selfd: 28, 0, 16, 238, 339, 0, 0 SWAPMETA: 276, 62230, 0, 0, 0, 0, 0 FFS inode: 116, 0, 1585, 1352, 3053, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 1585, 1355, 3053, 0, 0 taskq_zone: 24, 0, 0, 145, 624, 0, 0 zio_cache: 700, 0, 729, 231, 212935, 0, 0 zio_link_cache: 24, 0, 726, 3624, 112857, 0, 0 zio_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_data_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_data_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_data_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_data_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_data_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_data_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_data_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_data_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_data_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_data_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_data_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_data_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_data_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_data_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_data_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_data_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_data_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_data_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_data_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_data_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_data_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_data_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_data_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_data_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_data_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_data_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_data_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 0, 0, 0, 0, 0 zio_data_buf_131072: 131072, 0, 0, 0, 0, 0, 0 sa_cache: 44, 0, 9339, 993, 32008, 0, 0 dnode_t: 532, 0, 23480, 621, 29356, 0, 0 dmu_buf_impl_t: 136, 0, 35445, 4517, 73412, 0, 0 arc_buf_hdr_t: 148, 0, 21467, 1855, 37667, 0, 0 arc_buf_t: 60, 0, 12644, 3925, 40178, 0, 0 zil_lwb_cache: 168, 0, 16, 30, 46, 0, 0 zfs_znode_cache: 268, 0, 9339, 881, 32008, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq0: attimer0 204315 2128 irq1: atkbd0 764 7 irq5: ahci0 22384 233 irq10: em0 32 0 irq14: ata0 6129 63 irq15: ata1 25 0 Total 233649 2433 ------------------------------------------------------------------------ pstat -T 48/7944 files 0M/2047M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ada0s1a 4194048 0 4194048 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 ada1 cd0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 12.95 60 0.76 13.59 251 3.34 0.00 0 0.00 9 0 24 9 58 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 616 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 2 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 13 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 13 delivered 13 datagrams output 0 times multicast source filter matched ip: 14 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 13 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 1 packet not forwardable 0 packets received for unknown multicast group 0 redirects sent 13 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 2 ARP requests sent 0 ARP replies sent 0 ARP requests received 1 ARP reply received 1 ARP packet received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 257/281/538 mbufs in use (current/cache/total) 243/147/390/16832 mbuf clusters in use (current/cache/total/max) 256/141 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/8416 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/12624 9k jumbo clusters in use (current/cache/total/max) 0/0/0/8416 16k jumbo clusters in use (current/cache/total/max) 550K/364K/914K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 08:00:27:ad:dc:7f 15 0 0 16 0 0 0 em0 1500 10.0.2.0 10.0.2.15 13 - - 13 - - - usbus 0 0 0 0 0 0 0 0 lo0 16384 0 0 0 0 0 0 0 lo0 16384 localhost ::1 0 - - 0 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 0 - - 0 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.2.2 UGS 0 13 em0 10.0.2.0/24 link#1 U 0 0 em0 10.0.2.15 link#1 UHS 0 0 lo0 127.0.0.1 link#3 UH 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c3bb0ac0 tcp4 0 0 127.0.0.1.25 *.* LISTEN c3a811f8 udp4 0 0 *.514 *.* c3a81000 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c3b38e1c stream 0 0 c3a7ecc0 0 0 0 /var/run/devd.pipe c3b382b0 dgram 0 0 0 c3b38000 0 c3b38158 c3b38204 dgram 0 0 0 c3b380ac 0 0 c3b38158 dgram 0 0 0 c3b38000 0 0 c3b38000 dgram 0 0 c3ba6550 0 c3b382b0 0 /var/run/logpriv c3b380ac dgram 0 0 c3ba6660 0 c3b38204 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/10 localhost.smtp unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root sh 21860 root / 2 drwxr-xr-x 512 r root sh 21860 wd /usr/src 8686 ?-----S--- 3274606368 r root sh 21860 text / 496962 -r-xr-xr-x 119900 r root sh 21860 ctty /dev 42 crw------- ttyv1 rw root sh 21860 0 /dev 42 crw------- ttyv1 rw root sh 21860 1 /dev 42 crw------- ttyv1 rw root sh 21860 2 /dev 42 crw------- ttyv1 rw root make 21858 root / 2 drwxr-xr-x 512 r root make 21858 wd /usr/obj 3436 ?-----S--- 0 r root make 21858 text / 496969 -r-xr-xr-x 383448 r root make 21858 ctty /dev 42 crw------- ttyv1 rw root make 21858 0 /dev 42 crw------- ttyv1 rw root make 21858 1 /dev 42 crw------- ttyv1 rw root make 21858 2 /dev 42 crw------- ttyv1 rw root sh 1715 root / 2 drwxr-xr-x 512 r root sh 1715 wd /usr/src 40 ?--S------ 3278985312 r root sh 1715 text / 496962 -r-xr-xr-x 119900 r root sh 1715 ctty /dev 42 crw------- ttyv1 rw root sh 1715 0 /dev 42 crw------- ttyv1 rw root sh 1715 1 /dev 42 crw------- ttyv1 rw root sh 1715 2 /dev 42 crw------- ttyv1 rw root make 1700 root / 2 drwxr-xr-x 512 r root make 1700 wd /usr/obj 6 ?-----S--- 3274606368 r root make 1700 text / 496969 -r-xr-xr-x 383448 r root make 1700 ctty /dev 42 crw------- ttyv1 rw root make 1700 0 /dev 42 crw------- ttyv1 rw root make 1700 1 /dev 42 crw------- ttyv1 rw root make 1700 2 /dev 42 crw------- ttyv1 rw root make 1692 root / 2 drwxr-xr-x 512 r root make 1692 wd /usr/obj 6 ?-----S--- 3274606368 r root make 1692 text / 496969 -r-xr-xr-x 383448 r root make 1692 ctty /dev 42 crw------- ttyv1 rw root make 1692 0 /dev 42 crw------- ttyv1 rw root make 1692 1 /dev 42 crw------- ttyv1 rw root make 1692 2 /dev 42 crw------- ttyv1 rw root sh 1691 root / 2 drwxr-xr-x 512 r root sh 1691 wd /usr/src 3 ?--S--S--- 3282391840 r root sh 1691 text / 353311 -r-xr-xr-x 119900 r root sh 1691 ctty /dev 42 crw------- ttyv1 rw root sh 1691 0 /dev 42 crw------- ttyv1 rw root sh 1691 1 /dev 42 crw------- ttyv1 rw root sh 1691 2 /dev 42 crw------- ttyv1 rw root make 1564 root / 2 drwxr-xr-x 512 r root make 1564 wd /usr/obj 6 ?-----S--- 3274606368 r root make 1564 text / 427792 -r-xr-xr-x 383448 r root make 1564 ctty /dev 42 crw------- ttyv1 rw root make 1564 0 /dev 42 crw------- ttyv1 rw root make 1564 1 /dev 42 crw------- ttyv1 rw root make 1564 2 /dev 42 crw------- ttyv1 rw root make 1560 root / 2 drwxr-xr-x 512 r root make 1560 wd /usr/obj 6 ?-----S--- 3274606368 r root make 1560 text / 427792 -r-xr-xr-x 383448 r root make 1560 ctty /dev 42 crw------- ttyv1 rw root make 1560 0 /dev 42 crw------- ttyv1 rw root make 1560 1 /dev 42 crw------- ttyv1 rw root make 1560 2 /dev 42 crw------- ttyv1 rw root make 1558 root / 2 drwxr-xr-x 512 r root make 1558 wd /usr/obj 54033 ?-----S--- 0 r root make 1558 text / 427792 -r-xr-xr-x 383448 r root make 1558 ctty /dev 42 crw------- ttyv1 rw root make 1558 0 /dev 42 crw------- ttyv1 rw root make 1558 1 /dev 42 crw------- ttyv1 rw root make 1558 2 /dev 42 crw------- ttyv1 rw root make 1555 root / 2 drwxr-xr-x 512 r root make 1555 wd /usr/obj 54033 ?-----S--- 0 r root make 1555 text / 427792 -r-xr-xr-x 383448 r root make 1555 ctty /dev 42 crw------- ttyv1 rw root make 1555 0 /dev 42 crw------- ttyv1 rw root make 1555 1 /dev 42 crw------- ttyv1 rw root make 1555 2 /dev 42 crw------- ttyv1 rw root csh 1031 root / 2 drwxr-xr-x 512 r root csh 1031 wd /usr/src 10335 ?-----S--- 3274606368 r root csh 1031 text / 353313 -r-xr-xr-x 328084 r root csh 1031 ctty /dev 42 crw------- ttyv1 rw root csh 1031 15 /dev 42 crw------- ttyv1 rw root csh 1031 16 /dev 42 crw------- ttyv1 rw root csh 1031 17 /dev 42 crw------- ttyv1 rw root csh 1031 18 /dev 42 crw------- ttyv1 rw root csh 1031 19 /dev 42 crw------- ttyv1 rw root getty 1030 root / 2 drwxr-xr-x 512 r root getty 1030 wd / 2 drwxr-xr-x 512 r root getty 1030 text / 428113 -r-xr-xr-x 22368 r root getty 1030 ctty /dev 48 crw------- ttyv7 rw root getty 1030 0 /dev 48 crw------- ttyv7 rw root getty 1030 1 /dev 48 crw------- ttyv7 rw root getty 1030 2 /dev 48 crw------- ttyv7 rw root getty 1029 root / 2 drwxr-xr-x 512 r root getty 1029 wd / 2 drwxr-xr-x 512 r root getty 1029 text / 428113 -r-xr-xr-x 22368 r root getty 1029 ctty /dev 47 crw------- ttyv6 rw root getty 1029 0 /dev 47 crw------- ttyv6 rw root getty 1029 1 /dev 47 crw------- ttyv6 rw root getty 1029 2 /dev 47 crw------- ttyv6 rw root getty 1028 root / 2 drwxr-xr-x 512 r root getty 1028 wd / 2 drwxr-xr-x 512 r root getty 1028 text / 428113 -r-xr-xr-x 22368 r root getty 1028 ctty /dev 46 crw------- ttyv5 rw root getty 1028 0 /dev 46 crw------- ttyv5 rw root getty 1028 1 /dev 46 crw------- ttyv5 rw root getty 1028 2 /dev 46 crw------- ttyv5 rw root getty 1027 root / 2 drwxr-xr-x 512 r root getty 1027 wd / 2 drwxr-xr-x 512 r root getty 1027 text / 428113 -r-xr-xr-x 22368 r root getty 1027 ctty /dev 45 crw------- ttyv4 rw root getty 1027 0 /dev 45 crw------- ttyv4 rw root getty 1027 1 /dev 45 crw------- ttyv4 rw root getty 1027 2 /dev 45 crw------- ttyv4 rw root getty 1026 root / 2 drwxr-xr-x 512 r root getty 1026 wd / 2 drwxr-xr-x 512 r root getty 1026 text / 428113 -r-xr-xr-x 22368 r root getty 1026 ctty /dev 44 crw------- ttyv3 rw root getty 1026 0 /dev 44 crw------- ttyv3 rw root getty 1026 1 /dev 44 crw------- ttyv3 rw root getty 1026 2 /dev 44 crw------- ttyv3 rw root getty 1025 root / 2 drwxr-xr-x 512 r root getty 1025 wd / 2 drwxr-xr-x 512 r root getty 1025 text / 428113 -r-xr-xr-x 22368 r root getty 1025 ctty /dev 43 crw------- ttyv2 rw root getty 1025 0 /dev 43 crw------- ttyv2 rw root getty 1025 1 /dev 43 crw------- ttyv2 rw root getty 1025 2 /dev 43 crw------- ttyv2 rw root login 1024 root / 2 drwxr-xr-x 512 r root login 1024 wd / 471040 drwxr-xr-x 512 r root login 1024 text / 427782 -r-sr-xr-x 21576 r root login 1024 ctty /dev 42 crw------- ttyv1 rw root login 1024 0 /dev 42 crw------- ttyv1 rw root login 1024 1 /dev 42 crw------- ttyv1 rw root login 1024 2 /dev 42 crw------- ttyv1 rw root login 1024 3* local dgram c3b382b0 <-> c3b38000 root getty 1023 root / 2 drwxr-xr-x 512 r root getty 1023 wd / 2 drwxr-xr-x 512 r root getty 1023 text / 428113 -r-xr-xr-x 22368 r root getty 1023 ctty /dev 41 crw------- ttyv0 rw root getty 1023 0 /dev 41 crw------- ttyv0 rw root getty 1023 1 /dev 41 crw------- ttyv0 rw root getty 1023 2 /dev 41 crw------- ttyv0 rw root cron 965 root / 2 drwxr-xr-x 512 r root cron 965 wd /var 447488 drwxr-x--- 512 r root cron 965 text / 427919 -r-xr-xr-x 34512 r root cron 965 0 /dev 33 crw-rw-rw- null rw root cron 965 1 /dev 33 crw-rw-rw- null rw root cron 965 2 /dev 33 crw-rw-rw- null rw root cron 965 3 /var 588827 -rw------- 3 w smmsp sendmail 959 root / 2 drwxr-xr-x 512 r smmsp sendmail 959 wd /var 894982 drwxrwx--- 512 r smmsp sendmail 959 text / 426949 -r-xr-sr-x 699120 r smmsp sendmail 959 0 /dev 33 crw-rw-rw- null r smmsp sendmail 959 1 /dev 33 crw-rw-rw- null w smmsp sendmail 959 2 /dev 33 crw-rw-rw- null w smmsp sendmail 959 3* local dgram c3b38204 <-> c3b380ac smmsp sendmail 959 4 /var 894984 -rw------- 49 w root sendmail 955 root / 2 drwxr-xr-x 512 r root sendmail 955 wd /var 894979 drwxr-xr-x 512 r root sendmail 955 text / 426949 -r-xr-sr-x 699120 r root sendmail 955 0 /dev 33 crw-rw-rw- null r root sendmail 955 1 /dev 33 crw-rw-rw- null w root sendmail 955 2 /dev 33 crw-rw-rw- null w root sendmail 955 3* internet stream tcp c3bb0ac0 root sendmail 955 4* local dgram c3b38158 <-> c3b38000 root sendmail 955 5 /var 588826 -rw------- 78 w root syslogd 709 root / 2 drwxr-xr-x 512 r root syslogd 709 wd / 2 drwxr-xr-x 512 r root syslogd 709 text / 427931 -r-xr-xr-x 36204 r root syslogd 709 0 /dev 33 crw-rw-rw- null rw root syslogd 709 1 /dev 33 crw-rw-rw- null rw root syslogd 709 2 /dev 33 crw-rw-rw- null rw root syslogd 709 3 /var 588821 -rw------- 3 w root syslogd 709 4* local dgram c3b380ac root syslogd 709 5* local dgram c3b38000 root syslogd 709 6* internet6 dgram udp c3a81000 root syslogd 709 7* internet dgram udp c3a811f8 root syslogd 709 8 /dev 13 crw------- klog r root syslogd 709 10 - - bad - root syslogd 709 11 /var 683024 -rw-r--r-- 73851 w root syslogd 709 12 /var 683019 -rw------- 62 w root syslogd 709 13 /var 683012 -rw------- 4128 w root syslogd 709 14 /var 683033 -rw-r----- 3485 w root syslogd 709 15 /var 683015 -rw-r--r-- 62 w root syslogd 709 16 /var 683020 -rw------- 62 w root syslogd 709 17 /var 683013 -rw------- 47046 w root syslogd 709 18 /var 683014 -rw------- 62 w root syslogd 709 19 /var 683018 -rw-r----- 62 w root devd 569 root / 2 drwxr-xr-x 512 r root devd 569 wd / 2 drwxr-xr-x 512 r root devd 569 text / 282720 -r-xr-xr-x 382500 r root devd 569 0 /dev 33 crw-rw-rw- null rw root devd 569 1 /dev 33 crw-rw-rw- null rw root devd 569 2 /dev 33 crw-rw-rw- null rw root devd 569 3 /dev 6 crw------- devctl r root devd 569 4* local stream c3b38e1c root devd 569 5 /var 588812 -rw------- 3 w _dhcp dhclient 554 root /var 117760 dr-xr-xr-x 512 r _dhcp dhclient 554 wd /var 117760 dr-xr-xr-x 512 r _dhcp dhclient 554 jail /var 117760 dr-xr-xr-x 512 r _dhcp dhclient 554 text / 282721 -r-xr-xr-x 78796 r _dhcp dhclient 554 0 /dev 33 crw-rw-rw- null rw _dhcp dhclient 554 1 /dev 33 crw-rw-rw- null rw _dhcp dhclient 554 2 /dev 33 crw-rw-rw- null rw _dhcp dhclient 554 4* route raw 0 c3a7f680 _dhcp dhclient 554 5* pipe c344b0bc <-> c344b000 0 rw _dhcp dhclient 554 6 /var 1012746 ---------- 838 w _dhcp dhclient 554 7 /dev 16 crw------- bpf rw _dhcp dhclient 554 8* internet raw ip c3b42000 root dhclient 499 root / 2 drwxr-xr-x 512 r root dhclient 499 wd / 2 drwxr-xr-x 512 r root dhclient 499 text / 282721 -r-xr-xr-x 78796 r root dhclient 499 0 /dev 33 crw-rw-rw- null rw root dhclient 499 1 /dev 33 crw-rw-rw- null rw root dhclient 499 2 /dev 33 crw-rw-rw- null rw root dhclient 499 4* pipe c344b000 <-> c344b0bc 0 rw root zfskern 34 root / 2 drwxr-xr-x 512 r root zfskern 34 wd / 2 drwxr-xr-x 512 r root init 1 root / 2 drwxr-xr-x 512 r root init 1 wd / 2 drwxr-xr-x 512 r root init 1 text / 282662 -r-xr-xr-x 712236 r root kernel 0 root / 2 drwxr-xr-x 512 r root kernel 0 wd / 2 drwxr-xr-x 512 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2011 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 9.0-PRERELEASE #0 r227727: Sat Nov 19 07:52:17 UTC 2011 root@zfstest:/usr/obj/usr/src/sys/GENERIC i386 CPU: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz (2396.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x783fbff Features2=0x209 AMD Features=0x20100800 AMD Features2=0x1 real memory = 536805376 (511 MB) avail memory = 505782272 (482 MB) pnpbios: Bad PnP BIOS data checksum kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link2: BIOS IRQ 9 for 0.7.INTA does not match previous BIOS IRQ 10 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 ata0: on atapci0 ata1: on atapci0 vgapci0: mem 0xe0000000-0xe0ffffff irq 11 at device 2.0 on pci0 em0: port 0xd010-0xd017 mem 0xf0000000-0xf001ffff irq 10 at device 3.0 on pci0 em0: Ethernet address: 08:00:27:ad:dc:7f pci0: at device 4.0 (no driver attached) ohci0: mem 0xf0804000-0xf0804fff irq 11 at device 6.0 on pci0 usbus0: on ohci0 pci0: at device 7.0 (no driver attached) ahci0: port 0xd040-0xd047,0xd050-0xd057,0xd060-0xd06f mem 0xf0806000-0xf0807fff irq 5 at device 13.0 on pci0 ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 battery0: on acpi0 acpi_acad0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: parallel port not found. Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ahcich0 bus 0 scbus2 target 0 lun 0 ada1: ATA-6 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad4 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Timecounter "TSC" frequency 2396495148 Hz quality 800 Root mount waiting for: usbus0 uhub0: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad0s1a [rw]... Setting hostuuid: f36c009e-da3a-4d14-9e92-206d812d3316. Setting hostid: 0x67533753. ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 1692667 free (3747 frags, 211115 blocks, 0.2% fragmentation) /dev/ad0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 3044989 free (21 frags, 380621 blocks, 0.0% fragmentation) /dev/ad0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1d: clean, 3891432 free (440 frags, 486374 blocks, 0.0% fragmentation) Mounting local file systems:. Setting hostname: zfstest. Starting Network: lo0 em0. lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 em0: flags=8843 metric 0 mtu 1500 options=9b ether 08:00:27:ad:dc:7f nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active Starting devd. Starting Network: usbus0. DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 10.0.2.15 -- renewal in 43200 seconds. add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Generating host.conf. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Updating motd:. Configuring syscons: keymap blanktime. Starting cron. Starting background file system checks in 60 seconds. Sat Nov 19 10:39:48 UTC 2011 Nov 19 10:39:52 zfstest login: ROOT LOGIN (root) ON ttyv1 ahcich0: Timeout on slot 20 port 0 ahcich0: is 00000000 cs 00000000 ss 00200000 rs 00300000 tfd 50 serr 00000000 cmd 1000d517 (ada1:ahcich0:0:0:0): lost device panic: make_dev_credv: bad si_name (error=17, si_name=pass2) cpuid = 0 KDB: stack backtrace: #0 0xc0a4aff7 at kdb_backtrace+0x47 #1 0xc0a185c7 at panic+0x117 #2 0xc09d05de at make_dev_credv+0x9e #3 0xc09d080a at make_dev+0x4a #4 0xc04b79e0 at passregister+0x230 #5 0xc048ece3 at cam_periph_alloc+0x4e3 #6 0xc04b7525 at passasync+0x85 #7 0xc0490442 at xpt_async_bcast+0x32 #8 0xc0492715 at xpt_async+0x105 #9 0xc04991f3 at probedone+0xc33 #10 0xc04958a1 at camisr_runqueue+0x2e1 #11 0xc04959ff at camisr+0x13f #12 0xc09ed69b at intr_event_execute_handlers+0x13b #13 0xc09eee5a at ithread_loop+0x7a #14 0xc09ea8a7 at fork_exit+0x97 #15 0xc0d32734 at fork_trampoline+0x8 Uptime: 7m57s (ada1:ahcich0:0:0:0): Synchronize cache failed Physical memory: 495 MB Dumping 409 MB: 394 378 362 346 330 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident GENERIC machine i386 cpu I686_CPU cpu I586_CPU cpu I486_CPU makeoptions DEBUG=-g options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options NATIVE options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD options ISAPNP device isa device npx device mem device io device uart_ns8250 device atpic device apic device cpufreq device acpi device eisa device pci device fdc device ahci device ata device mvs device siis device ahb device ahc device ahd device esp device hptiop device isp device mpt device sym device trm device adv device adw device aha device aic device bt device ncv device nsp device stg device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device asr device ciss device dpt device hptmv device hptrr device iir device ips device mly device twa device tws device aac device aacp device ida device mfi device mlx device pst device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device pmtimer device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device puc device bxe device de device em device igb device ixgb device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device dc device et device fxp device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device vte device wb device xl device cs device ed device ex device ep device fe device ie device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device run device uath device upgt device ural device urtw device zyd device firewire device fwe device fwip device dcons device dcons_crom device sound device snd_es137x device snd_hda device snd_ich device snd_uaudio device snd_via8233 ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 16:03:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF861065670 for ; Sun, 20 Nov 2011 16:03:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id C68478FC14 for ; Sun, 20 Nov 2011 16:03:09 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta08.emeryville.ca.mail.comcast.net with comcast id zThu1h0021eYJf8A8U32Mz; Sun, 20 Nov 2011 16:03:02 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id zTiC1h00A1t3BNj01TiDtS; Sun, 20 Nov 2011 15:42:13 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0042D102C1D; Sun, 20 Nov 2011 08:03:07 -0800 (PST) Date: Sun, 20 Nov 2011 08:03:07 -0800 From: Jeremy Chadwick To: Johannes Totz Message-ID: <20111120160307.GA20262@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: panic: make_dev_credv: bad si_name (error=17, si_name=pass2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 16:03:09 -0000 On Sun, Nov 20, 2011 at 03:34:36PM +0000, Johannes Totz wrote: > (Sent twice, first one bounced...) > Just got a panic on 9-stable, running inside VirtualBox, trying to > build a release-set. Don't know yet if reproducable, just happened a > few minutes ago. > The whole core.txt stuff follows below (beware of line-breaks): > > ... > Unread portion of the kernel message buffer: > (ada1:ahcich0:0:0:0): lost device > panic: make_dev_credv: bad si_name (error=17, si_name=pass2) > cpuid = 0 > KDB: stack backtrace: > #0 0xc0a4aff7 at kdb_backtrace+0x47 > #1 0xc0a185c7 at panic+0x117 > #2 0xc09d05de at make_dev_credv+0x9e > #3 0xc09d080a at make_dev+0x4a > #4 0xc04b79e0 at passregister+0x230 > #5 0xc048ece3 at cam_periph_alloc+0x4e3 > #6 0xc04b7525 at passasync+0x85 > #7 0xc0490442 at xpt_async_bcast+0x32 > #8 0xc0492715 at xpt_async+0x105 > #9 0xc04991f3 at probedone+0xc33 > #10 0xc04958a1 at camisr_runqueue+0x2e1 > #11 0xc04959ff at camisr+0x13f > #12 0xc09ed69b at intr_event_execute_handlers+0x13b > #13 0xc09eee5a at ithread_loop+0x7a > #14 0xc09ea8a7 at fork_exit+0x97 > #15 0xc0d32734 at fork_trampoline+0x8 > ... > Uptime: 7m57s > (ada1:ahcich0:0:0:0): Synchronize cache failed According to the above, your ada1 "virtual disk" fell off the bus entirely. Relevant storage bits taken from your dmesg: > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > ahci0: port 0xd040-0xd047,0xd050-0xd057,0xd060-0xd06f mem 0xf0806000-0xf0807fff irq 5 at device 13.0 on pci0 > ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ... > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-6 device > ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) > ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > ada1 at ahcich0 bus 0 scbus2 target 0 lun 0 > ada1: ATA-6 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad4 My recommendation is to remove VirtualBox from the picture entirely and instead do whatever you were doing (running zfstest) on bare metal. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 16:32:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DCB4106564A for ; Sun, 20 Nov 2011 16:32:49 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id DF55C8FC08 for ; Sun, 20 Nov 2011 16:32:48 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RSAJy-00057c-91 for freebsd-stable@freebsd.org; Sun, 20 Nov 2011 17:32:46 +0100 Received: from dyn1243-74.vpn.ic.ac.uk ([129.31.243.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2011 17:32:46 +0100 Received: from johannes by dyn1243-74.vpn.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2011 17:32:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Johannes Totz Date: Sun, 20 Nov 2011 16:32:33 +0000 Lines: 64 Message-ID: References: <20111120160307.GA20262@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1243-74.vpn.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <20111120160307.GA20262@icarus.home.lan> Subject: Re: panic: make_dev_credv: bad si_name (error=17, si_name=pass2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 16:32:49 -0000 On 20/11/2011 16:03, Jeremy Chadwick wrote: > On Sun, Nov 20, 2011 at 03:34:36PM +0000, Johannes Totz wrote: >> (Sent twice, first one bounced...) >> Just got a panic on 9-stable, running inside VirtualBox, trying to >> build a release-set. Don't know yet if reproducable, just happened a >> few minutes ago. >> The whole core.txt stuff follows below (beware of line-breaks): >> >> ... >> Unread portion of the kernel message buffer: >> (ada1:ahcich0:0:0:0): lost device >> panic: make_dev_credv: bad si_name (error=17, si_name=pass2) >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xc0a4aff7 at kdb_backtrace+0x47 >> #1 0xc0a185c7 at panic+0x117 >> #2 0xc09d05de at make_dev_credv+0x9e >> #3 0xc09d080a at make_dev+0x4a >> #4 0xc04b79e0 at passregister+0x230 >> #5 0xc048ece3 at cam_periph_alloc+0x4e3 >> #6 0xc04b7525 at passasync+0x85 >> #7 0xc0490442 at xpt_async_bcast+0x32 >> #8 0xc0492715 at xpt_async+0x105 >> #9 0xc04991f3 at probedone+0xc33 >> #10 0xc04958a1 at camisr_runqueue+0x2e1 >> #11 0xc04959ff at camisr+0x13f >> #12 0xc09ed69b at intr_event_execute_handlers+0x13b >> #13 0xc09eee5a at ithread_loop+0x7a >> #14 0xc09ea8a7 at fork_exit+0x97 >> #15 0xc0d32734 at fork_trampoline+0x8 >> ... >> Uptime: 7m57s >> (ada1:ahcich0:0:0:0): Synchronize cache failed > > According to the above, your ada1 "virtual disk" fell off the bus > entirely. Relevant storage bits taken from your dmesg: > >> atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 >> ata0: on atapci0 >> ata1: on atapci0 >> ahci0: port 0xd040-0xd047,0xd050-0xd057,0xd060-0xd06f mem 0xf0806000-0xf0807fff irq 5 at device 13.0 on pci0 >> ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported >> ahcich0: at channel 0 on ahci0 >> ... >> ada0 at ata0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-6 device >> ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) >> ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) >> ada0: Previously was known as ad0 >> ada1 at ahcich0 bus 0 scbus2 target 0 lun 0 >> ada1: ATA-6 SATA 2.x device >> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada1: Command Queueing enabled >> ada1: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) >> ada1: Previously was known as ad4 > > My recommendation is to remove VirtualBox from the picture entirely and > instead do whatever you were doing (running zfstest) on bare metal. Yeah, would love to. But http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 prevents me from doing so. I'm trying to build a live-disc that includes http://svnweb.freebsd.org/base?view=revision&revision=226617 so I can recover the pool. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 16:41:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1F01065670 for ; Sun, 20 Nov 2011 16:41:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id A59AC8FC12 for ; Sun, 20 Nov 2011 16:41:29 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta15.emeryville.ca.mail.comcast.net with comcast id zUg31h0020cQ2SLAFUhN6P; Sun, 20 Nov 2011 16:41:22 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta10.emeryville.ca.mail.comcast.net with comcast id zUfE1h00G1t3BNj8WUfEef; Sun, 20 Nov 2011 16:39:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 57BBA102C19; Sun, 20 Nov 2011 08:41:28 -0800 (PST) Date: Sun, 20 Nov 2011 08:41:28 -0800 From: Jeremy Chadwick To: Johannes Totz Message-ID: <20111120164128.GA29952@icarus.home.lan> References: <20111120160307.GA20262@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: panic: make_dev_credv: bad si_name (error=17, si_name=pass2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 16:41:29 -0000 On Sun, Nov 20, 2011 at 04:32:33PM +0000, Johannes Totz wrote: > On 20/11/2011 16:03, Jeremy Chadwick wrote: > >On Sun, Nov 20, 2011 at 03:34:36PM +0000, Johannes Totz wrote: > >>(Sent twice, first one bounced...) > >>Just got a panic on 9-stable, running inside VirtualBox, trying to > >>build a release-set. Don't know yet if reproducable, just happened a > >>few minutes ago. > >>The whole core.txt stuff follows below (beware of line-breaks): > >> > >>... > >>Unread portion of the kernel message buffer: > >>(ada1:ahcich0:0:0:0): lost device > >>panic: make_dev_credv: bad si_name (error=17, si_name=pass2) > >>cpuid = 0 > >>KDB: stack backtrace: > >>#0 0xc0a4aff7 at kdb_backtrace+0x47 > >>#1 0xc0a185c7 at panic+0x117 > >>#2 0xc09d05de at make_dev_credv+0x9e > >>#3 0xc09d080a at make_dev+0x4a > >>#4 0xc04b79e0 at passregister+0x230 > >>#5 0xc048ece3 at cam_periph_alloc+0x4e3 > >>#6 0xc04b7525 at passasync+0x85 > >>#7 0xc0490442 at xpt_async_bcast+0x32 > >>#8 0xc0492715 at xpt_async+0x105 > >>#9 0xc04991f3 at probedone+0xc33 > >>#10 0xc04958a1 at camisr_runqueue+0x2e1 > >>#11 0xc04959ff at camisr+0x13f > >>#12 0xc09ed69b at intr_event_execute_handlers+0x13b > >>#13 0xc09eee5a at ithread_loop+0x7a > >>#14 0xc09ea8a7 at fork_exit+0x97 > >>#15 0xc0d32734 at fork_trampoline+0x8 > >>... > >>Uptime: 7m57s > >>(ada1:ahcich0:0:0:0): Synchronize cache failed > > > >According to the above, your ada1 "virtual disk" fell off the bus > >entirely. Relevant storage bits taken from your dmesg: > > > >>atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 > >>ata0: on atapci0 > >>ata1: on atapci0 > >>ahci0: port 0xd040-0xd047,0xd050-0xd057,0xd060-0xd06f mem 0xf0806000-0xf0807fff irq 5 at device 13.0 on pci0 > >>ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported > >>ahcich0: at channel 0 on ahci0 > >>... > >>ada0 at ata0 bus 0 scbus0 target 0 lun 0 > >>ada0: ATA-6 device > >>ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) > >>ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) > >>ada0: Previously was known as ad0 > >>ada1 at ahcich0 bus 0 scbus2 target 0 lun 0 > >>ada1: ATA-6 SATA 2.x device > >>ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >>ada1: Command Queueing enabled > >>ada1: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) > >>ada1: Previously was known as ad4 > > > >My recommendation is to remove VirtualBox from the picture entirely and > >instead do whatever you were doing (running zfstest) on bare metal. > > Yeah, would love to. > But http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 prevents > me from doing so. I'm trying to build a live-disc that includes > http://svnweb.freebsd.org/base?view=revision&revision=226617 so I > can recover the pool. Can you not use mfsBSD for this task? http://mfsbsd.vx.sk/ The 9.0-RELEASE image provided by mm@ on his site is dated 2011/10/26, while SVN rev 226617 was committed on 2011/10/21 (5 days prior). You might also want to try a 9.0-RC2 build, which was just announced and put on the mirrors a couple days ago: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/ ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ (Comment in passing: I still have no idea why the architecture directories for 9.0 are "doubled up" like that; it almost looks like the result of someone using rsync with a missing trailing slash on the source directory). I can't explain why your ada1 "virtual disk" would drop off the bus entirely. Possibly too much I/O and stress via VirtualBox causes too long a delay, resulting in ahci.ko or CAM bits dropping the idsk from the bus. kern.cam.ada.default_timeout is, by default, 30 seconds, which is an awful long time, but I don't know if that is the only timeout available (e.g. no idea what ahci.ko uses internally, I'd need to check the code). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 17:21:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40B88106566C for ; Sun, 20 Nov 2011 17:21:19 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9C68FC18 for ; Sun, 20 Nov 2011 17:21:18 +0000 (UTC) Received: from fd11.matik.com.br (baded69e.virtua.com.br [186.222.214.158] (may be forged)) by msrv.matik.com.br (8.14.5/8.14.2) with ESMTP id pAKH6xL5058944 for ; Sun, 20 Nov 2011 15:06:59 -0200 (BRST) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at msrv.matik.com.br Authentication-Results: msrv.matik.com.br; dkim=none (no signature) header.i=unknown; x-dkim-adsp=fail Authentication-Results: msrv.matik.com.br; domainkeys=fail (no signature) (testing) header.from=hm@hm.net.br Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br From: H Organization: HM-Net To: freebsd-stable@freebsd.org Date: Sun, 20 Nov 2011 15:06:45 -0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.2; i386; ; ) References: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> In-Reply-To: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1447391.flqbuxQdo0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201111201506.58703.hm@hm.net.br> X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_05, SARE_RECV_VIRTUACOMBR, TW_PF autolearn=no version=3.3.1-dcmatik_hm_4.18.a X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1-dcmatik_hm_4.18.a (2010-03-16) on msrv.matik.com.br Subject: ipfw nat 1 config not_good_anymore? (FreeBSD 9.0-RC2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 17:21:19 -0000 --nextPart1447391.flqbuxQdo0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable somebody else experience problems with ipfw nat? even the most simple ruleset as ipfw add nat 1 ip from any to any via em0 =20 ipfw nat 1 config if em0 reset ipfw add pass proto ip is not working anymore, funny is the counter of each rule increase (ipfw sh= ow)=20 but there is no traffic outgoing on the LAN_IF neither get some to the clie= nt=20 machine (yeah, the IFs are up and cable is plugged in :) tcpdump captures 0 (zero) returning traffic on the LAN=20 I can access normally from the machine any destiny on either side of it please don't ask for IPFIREWALL_FORWARD, IPFIREWALL_NAT LIBALIAS and IPDIVE= RT =20 nor sysctls .. unless there is an undocumented change.=20 thank's HM --nextPart1447391.flqbuxQdo0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEABECAAYFAk7JM7IACgkQvKVfg5xjCDx7GgCfVuAphmRGzKldP2efrNPwjpRC B9AAni57sH6F198QyJ61jhjj3Hpr/j2L =Zmpq -----END PGP SIGNATURE----- --nextPart1447391.flqbuxQdo0-- From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 18:04:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 231B6106564A for ; Sun, 20 Nov 2011 18:04:23 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from fep20.mx.upcmail.net (fep20.mx.upcmail.net [62.179.121.40]) by mx1.freebsd.org (Postfix) with ESMTP id 993978FC15 for ; Sun, 20 Nov 2011 18:04:22 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep20-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20111120180420.BCTH1579.viefep20-int.chello.at@edge02.upcmail.net> for ; Sun, 20 Nov 2011 19:04:20 +0100 Received: from pinky ([213.93.232.119]) by edge02.upcmail.net with edge id zW4J1h00h2bDWHx02W4Kzg; Sun, 20 Nov 2011 19:04:20 +0100 X-SourceIP: 213.93.232.119 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <678178215ed5d725a42eb2b4ae25102c.squirrel@eternamente.info> <20111119095808.GA87444@icarus.home.lan> <5f508e72e9cfcf7ebfe8ec53a68851e9.squirrel@eternamente.info> Date: Sun, 20 Nov 2011 19:04:20 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <5f508e72e9cfcf7ebfe8ec53a68851e9.squirrel@eternamente.info> User-Agent: Opera Mail/11.52 (Win32) X-Cloudmark-Analysis: v=1.1 cv=jqrf5qXv5urL2URZ3a9OklEvUdrM81ZtB3GWlHLPCVk= c=1 sm=0 a=Rj6e-IpH9S4A:10 a=Hl2ftkGO2xcA:10 a=bgpUlknNv7MA:10 a=kj9zAlcOel0A:10 a=hzHASVDcAAAA:8 a=6I5d2MoRAAAA:8 a=TXjBXONV0XiDYqYJgDYA:9 a=2ciXEIzci0ajh2O1CcoA:7 a=CjuIK1q_8ugA:10 a=il6ZqaaW9nAA:10 a=vXa-fTo6yJYA:10 a=SV7veod9ZcQA:10 a=Zsqsj9UJ7ZU5mCKm:21 a=g5qsXgXI-DKSZEMp:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: mount GPT from Windows 7 in FreeBSD 9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 18:04:23 -0000 On Sat, 19 Nov 2011 14:51:19 +0100, Nenhum_de_Nos wrote: > > On Sat, November 19, 2011 07:58, Jeremy Chadwick wrote: >> On Fri, Nov 18, 2011 at 10:55:10PM -0200, Nenhum_de_Nos wrote: >>> hail, >>> >>> I have two disks, and the one holding Windows appears just as ada1 or >>> ad8, despite fdisk shows >>> all >>> partitions fine. >>> >>> I tried to kldload geom_gpt_something, but it says it was already >>> loaded. I couldn't mount using >>> mount_ntfs, so I would use fuse to have ability to write on it :) >>> >>> is there a way to solve this ? >>> two disks. One just FreeBSD, the other just Windows. > > Jeremy, thanks and let's to the answers. > >> First: to my knowledge, fdisk does not support GPT, so I'm not sure what >> you mean when you say "it shows all partitions fine". You should >> probably use gpart(8) instead, e.g. "gpart show" and/or "gpart list". >> See the man page for usage. It will work with all types, and tell you >> what scheme is used (MBR, GPT, etc.). > > its all here :) > > macgyver# fdisk ada1 > ******* Working on device /dev/ada1 ******* > parameters extracted from in-core disklabel are: > cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) > > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX) > start 2048, size 204800 (100 Meg), flag 80 (active) > beg: cyl 0/ head 107/ sector 16; > end: cyl 48/ head 134/ sector 14 > The data for partition 2 is: > sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX) > start 206848, size 103165952 (50374 Meg), flag 0 > beg: cyl 48/ head 134/ sector 15; > end: cyl 1023/ head 223/ sector 19 > The data for partition 3 is: > sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX) > start 103372800, size 385019904 (187998 Meg), flag 0 > beg: cyl 1023/ head 239/ sector 63; > end: cyl 1023/ head 239/ sector 63 > The data for partition 4 is: > > macgyver# gpart show ada1 > => 34 488397101 ada1 GPT (232G) > 34 488397101 - free - (232G) > > macgyver# gpart list ada1 > Geom name: ada1 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 > last: 488397134 > first: 34 > entries: 128 > scheme: GPT > Consumers: > 1. Name: ada1 > Mediasize: 250059350016 (232G) > Sectorsize: 512 > Mode: r0w0e0 > > macgyver# dmesg | grep ada1 > ada1 at ahcich2 bus 0 scbus2 target 0 lun 0 > ada1: ATA-7 SATA 1.x device > ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad8 > macgyver# > >> Next item: what do you mean it appears as "ada1 **or** ad8"? ada1 >> indicates you're using ahci.ko (not ataahci.ko) which supports AHCI via >> CAM(4), while the latter indicates you're using ata(4) (even if AHCI is >> in use; that would be ataahci.ko). Why/how would this change unless you >> are messing with cables or enabling/disabling drivers? > > As now I'm on FreeBSD in this machine, there is: > > macgyver# ls /dev/ada1* > /dev/ada1 > > but the FreeBSD disk: > > macgyver# ls /dev/ada0* > /dev/ada0 /dev/ada0s1 /dev/ada0s1a /dev/ada0s1b > /dev/ada0s2 /dev/ada0s2a > /dev/ada0s3 /dev/ada0s4 /dev/ada0s4a /dev/ada0s4b > > and I still have old ad4 and ad8: > > macgyver# ls /dev/ad4* /dev/ad8* > /dev/ad4 /dev/ad4s1 /dev/ad4s1a /dev/ad4s1b > /dev/ad4s2 /dev/ad4s2a > /dev/ad4s3 /dev/ad4s4 /dev/ad4s4a /dev/ad4s4b /dev/ad8 > > and my point here is there even though fdisk shows some windows > partitions, I can't even address > them as I just see ada1/ad8. no ada1s1 or anything alike. > >> Next item: I think you're referring to the geom_part_gpt.ko module, >> but you don't need to do that. GEOM and related kernel bits will load >> it automatically, which is why it told you it's already loaded. You can >> use "kldstat" to verify. Otherwise it's statically-included in your >> kernel. > > I noticed that. I got to put it on loader.conf: for the record, no good > and won't be able to boot > the box (usb live solved). I thought I needed to load the module to see > the gpt. > >> Next item: this sounds like the crux of your issue. As I understand it, >> NTFS support via kernel on FreeBSD is in an extremely bad state on >> numerous levels. You can find complaints about lack-of or badly-done >> UTF-8 filename/path support, lack of full write support, and the more >> important/major Non-MPSAFE filesystem declaration here: >> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > > unfortunately I didn't got to this point as I never got to see the > partitions :( but I plan to use > ntfs from fuse. > >> It looks like attilio@freebsd.org has taken ownership of the NTFS driver >> in the kernel at this point. You may want to ask him if there are any >> patches you could try. >> >> However, as I understand it, the fuse-based NTFS is more reliable and >> has much higher compatibility. The trade-offs are added complexity >> getting it all to work, and slower speed. >> >> Final item: you sent this mail twice, once to stable@freebsd.org, once >> to >> freebsd-stable@freebsd.org. The mail ID headers appear to indicate >> they were separate/unique and the mail content themselves slightly >> differs (extra newlines, etc.). No need for this; they are the same >> list. >> >> 3909 11/18 22:55 Nenhum_de_Nos (0.8K) mount GPT from Windows >> 7 in FreeBSD 9 >> Message-ID: >> <678178215ed5d725a42eb2b4ae25102c.squirrel@eternamente.info> >> 3910 11/19 03:20 Nenhum_de_Nos (1.1K) mount GPT from Windows >> 7 in FreeBSD 9 >> Message-ID: >> <1c312a399e23d546f05f5e8396763323.squirrel@eternamente.info> > > and this, sorry for the double post. I sent the message to > freebsd-stable@ and waited a couple of > hours. Nothing showed on the list. I thought was a problem with it, then > sent again: > > stable@freebsd.org 03:20 1.4 k mount GPT from Windows 7 in FreeBSD 9 > freebsd-stable@freebsd.org Fri, 22:55 1.1 k mount GPT from Windows 7 in > FreeBSD 9 > > this is from squirrelmail. first message 22:55 from Friday in my time > zone, the second was 3:20 > from Saturday. then I tried to subscribe again to the list (I thought I > was no more on it), and > got the message I was there ... > > again, sorry but I just thought I was not there anymore. Was there any > issues with the list > yesterday ? usually it is not that slow (I think). > > thanks, > > matheus > Hi, fdisk /dev/ada0 ******* Working on device /dev/ada0 ******* parameters extracted from in-core disklabel are: cylinders=1938021 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1938021 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 1953525167 (953869 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Mind, that fdisk mentions that I have a GPT partition on my GPT disk. So there is something wacky on your disk. Gpart sees your disk as GPT, fdisk sees it as MBR. Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 18:34:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E0D3106564A; Sun, 20 Nov 2011 18:34:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BC1A48FC15; Sun, 20 Nov 2011 18:34:38 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAKIYYaQ053251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2011 20:34:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAKIYY0i031343; Sun, 20 Nov 2011 20:34:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAKIYYKo031342; Sun, 20 Nov 2011 20:34:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 20 Nov 2011 20:34:34 +0200 From: Kostik Belousov To: Doug Barton Message-ID: <20111120183434.GA50300@deviant.kiev.zoral.com.ua> References: <20111115100904.GA92795@icarus.home.lan> <4EC4ADC3.2060604@FreeBSD.org> <20111117074909.GL50300@deviant.kiev.zoral.com.ua> <4EC4BECA.5040705@FreeBSD.org> <20111117081210.GN50300@deviant.kiev.zoral.com.ua> <4EC4D359.4040406@FreeBSD.org> <20111117105744.GS50300@deviant.kiev.zoral.com.ua> <4EC610B9.8080406@FreeBSD.org> <20111118091937.GA50300@deviant.kiev.zoral.com.ua> <4EC6BB17.20706@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EUdKUZvr8YK8ET4E" Content-Disposition: inline In-Reply-To: <4EC6BB17.20706@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Daniil Cherednik , freebsd-apache@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: 8.2 + apache == a LOT of sigprocmask X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 18:34:39 -0000 --EUdKUZvr8YK8ET4E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2011 at 12:07:51PM -0800, Doug Barton wrote: > On 11/18/2011 01:19, Kostik Belousov wrote: > > On Fri, Nov 18, 2011 at 12:00:57AM -0800, Doug Barton wrote: > >> On 11/17/2011 02:57, Kostik Belousov wrote: > >>>>> It's not catching there though: > >>>>> > >>>>> Reading symbols from /libexec/ld-elf.so.1...done. > >>>>> Loaded symbols for /libexec/ld-elf.so.1 > >>>>> 0x28183b2d in accept () at accept.S:3 > >>>>> 3 RSYSCALL(accept) > >>>>> (gdb) c > >>>>> Continuing. > >>>>> no thread to satisfy query > >>>>> 0x28183b2d in accept () at accept.S:3 > >>>>> 3 RSYSCALL(accept) > >>>>> (gdb) info threads > >>>>> Cannot get thread info: invalid key > >>>>> (gdb) > >>> Err, the other part of my message was that you shall set the breakpoi= nt > >>> on sigprocmask. > >> > >> I'm sorry I'm not making myself clear. We are setting the breakpoint on > >> sigprocmask. But, maybe I'm doing it wrong. Can you give precise > >> instructions as to what you want me to do, from the beginning? Sorry to > >> be so dense. > > Find the pid of the process issuing excessive number of sigprocmask > > calls. Do > > $ gdb /usr/local/bin/httpd > > (gdb) attach > > (gdb) b _sigprocmask > > (gdb) c > > Bah ! Breakpoint fired. > > (gdb) bt > > (gdb) c > > <... Repeat ... > >=20 > Right, so we're on the same page at least. I've been abbreviating the > output of gdb to make it easier to see the problem, but here is a > (nearly) complete transcript: >=20 > gdb /usr/local/bin/httpd > 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 detail= s. > This GDB was configured as "i386-marcel-freebsd"... > (gdb) attach 1380 > Attaching to program: /usr/local/bin/httpd, process 1380 > Reading symbols from .... (lots of symbol-reading snipped) > 3 RSYSCALL(accept) > Current language: auto; currently asm > (gdb) b _sigprocmask > Breakpoint 1 at 0x282d9055: file /usr/src/lib/libthr/thread/thr_sig.c, > line 210. > (gdb) c > Continuing. > no thread to satisfy query > 0x28183b2d in accept () at accept.S:3 > 3 RSYSCALL(accept) > (gdb) c > Continuing. > no thread to satisfy query > 0x28183b2d in accept () at accept.S:3 > 3 RSYSCALL(accept) > (gdb) c > Continuing. > no thread to satisfy query > 0x28183b2d in accept () at accept.S:3 > 3 RSYSCALL(accept) >=20 > .... etc. This is an issue with either your environment or your gdb, or bug in gdb. It seems that 'continue' did not worked for you at all. I tried to reproduce this locally, but was not able to. And, I am unable to hit sigprocmask for my apache anywhere except rtld. I also have libthr linked in. So the way forward to catch sigprocmask callers is one of - figure out why your gdb does not work and fix it; might be, try to use gdb from ports. - or add libunwind backtraces into sigprocmask - or use dtrace (I doubt that 8.2 has neccessary usermode bits, and seriously doubt its stability). --EUdKUZvr8YK8ET4E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7JSDoACgkQC3+MBN1Mb4gSQQCgj/cHVj0SnYIRJCLpOnbxVGGd aXAAmwSjgSH1sxgfgRq7qH/p4ZxWVv/Y =3m7i -----END PGP SIGNATURE----- --EUdKUZvr8YK8ET4E-- From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 20:18:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39A4E1065673 for ; Sun, 20 Nov 2011 20:18:42 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id B96A08FC12 for ; Sun, 20 Nov 2011 20:18:41 +0000 (UTC) Received: from wkoszek-thinkpad-t410 (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id pAKKHWXY049236; Sun, 20 Nov 2011 20:17:32 GMT (envelope-from wkoszek@freebsd.czest.pl) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Date: Sun, 20 Nov 2011 21:18:38 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Wojciech A. Koszek" Organization: FreeBSD.czest.pl Message-ID: User-Agent: Opera Mail/11.60 (Linux) X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [127.0.0.2]); Sun, 20 Nov 2011 20:17:32 +0000 (UTC) Cc: Subject: The FreeBSD Project in the Google Code-In 2011 contest X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 20:18:42 -0000 Hello, (cross-posted message; please keep eventual comments on freebsd-hackers@) The FreeBSD project has been accepted to the Google Code-In 2011 contest. http://google-opensource.blogspot.com/2011/11/google-code-in-2011-participating.html We have proposed 50 tasks so far, and more are still coming! This is an event similar to the Google Summer of Code, but is targetted to people in the 13-17 age range. Young people will be working on FreeBSD-related tasks for the next weeks. If you know any potential candidates, feel free to forward this message. Brief summary: T-shirts and possibility of earning some $$$ for participants. The best participants get a chance to see the Google complex in Mountain View, Silicon Valley, California, USA. FreeBSD tasks are here: http://wiki.freebsd.org/GoogleCodeIn/2011 Ideas page can be extended till December, 16th! Contest's home page: http://www.google-melange.com/gci/homepage/google/gci2011 After you create an account, you can acquire tasks which you're interested in (if any of them are left!) Start date: November, 21st (tomorrow) Official communication channels: IRC (EFNet): #freebsd-soc Q/A: wkoszek@FreeBSD.ORG, jceel@FreeBSD.ORG, eadler@FreeBSD.org wkoszek, jceel, eadler on IRC Mailing list: freebsd-hackers@ Please coordinate communication with your mentor. Include '[GCIN]' header when posting to freebsd-hackers@ In case of potential task candidates, ideas and suggestions, feel free to contact me. -- Wojciech A. Koszek wkoszek@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-stable@FreeBSD.ORG Sun Nov 20 22:51:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFCB41065670 for ; Sun, 20 Nov 2011 22:51:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE2A8FC08 for ; Sun, 20 Nov 2011 22:51:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RSGEu-0007x7-96 for freebsd-stable@freebsd.org; Sun, 20 Nov 2011 23:51:56 +0100 Received: from 78-86-4-158.zone2.bethere.co.uk ([78.86.4.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2011 23:51:56 +0100 Received: from johannes by 78-86-4-158.zone2.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Nov 2011 23:51:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Johannes Totz Date: Sun, 20 Nov 2011 22:51:43 +0000 Lines: 104 Message-ID: References: <20111120160307.GA20262@icarus.home.lan> <20111120164128.GA29952@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-86-4-158.zone2.bethere.co.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <20111120164128.GA29952@icarus.home.lan> Subject: Re: panic: make_dev_credv: bad si_name (error=17, si_name=pass2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 22:51:59 -0000 On 20/11/2011 16:41, Jeremy Chadwick wrote: > On Sun, Nov 20, 2011 at 04:32:33PM +0000, Johannes Totz wrote: >> On 20/11/2011 16:03, Jeremy Chadwick wrote: >>> On Sun, Nov 20, 2011 at 03:34:36PM +0000, Johannes Totz wrote: >>>> (Sent twice, first one bounced...) >>>> Just got a panic on 9-stable, running inside VirtualBox, trying to >>>> build a release-set. Don't know yet if reproducable, just happened a >>>> few minutes ago. >>>> The whole core.txt stuff follows below (beware of line-breaks): >>>> >>>> ... >>>> Unread portion of the kernel message buffer: >>>> (ada1:ahcich0:0:0:0): lost device >>>> panic: make_dev_credv: bad si_name (error=17, si_name=pass2) >>>> cpuid = 0 >>>> KDB: stack backtrace: >>>> #0 0xc0a4aff7 at kdb_backtrace+0x47 >>>> #1 0xc0a185c7 at panic+0x117 >>>> #2 0xc09d05de at make_dev_credv+0x9e >>>> #3 0xc09d080a at make_dev+0x4a >>>> #4 0xc04b79e0 at passregister+0x230 >>>> #5 0xc048ece3 at cam_periph_alloc+0x4e3 >>>> #6 0xc04b7525 at passasync+0x85 >>>> #7 0xc0490442 at xpt_async_bcast+0x32 >>>> #8 0xc0492715 at xpt_async+0x105 >>>> #9 0xc04991f3 at probedone+0xc33 >>>> #10 0xc04958a1 at camisr_runqueue+0x2e1 >>>> #11 0xc04959ff at camisr+0x13f >>>> #12 0xc09ed69b at intr_event_execute_handlers+0x13b >>>> #13 0xc09eee5a at ithread_loop+0x7a >>>> #14 0xc09ea8a7 at fork_exit+0x97 >>>> #15 0xc0d32734 at fork_trampoline+0x8 >>>> ... >>>> Uptime: 7m57s >>>> (ada1:ahcich0:0:0:0): Synchronize cache failed >>> >>> According to the above, your ada1 "virtual disk" fell off the bus >>> entirely. Relevant storage bits taken from your dmesg: >>> >>>> atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 >>>> ata0: on atapci0 >>>> ata1: on atapci0 >>>> ahci0: port 0xd040-0xd047,0xd050-0xd057,0xd060-0xd06f mem 0xf0806000-0xf0807fff irq 5 at device 13.0 on pci0 >>>> ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported >>>> ahcich0: at channel 0 on ahci0 >>>> ... >>>> ada0 at ata0 bus 0 scbus0 target 0 lun 0 >>>> ada0: ATA-6 device >>>> ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) >>>> ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) >>>> ada0: Previously was known as ad0 >>>> ada1 at ahcich0 bus 0 scbus2 target 0 lun 0 >>>> ada1: ATA-6 SATA 2.x device >>>> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada1: Command Queueing enabled >>>> ada1: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C) >>>> ada1: Previously was known as ad4 >>> >>> My recommendation is to remove VirtualBox from the picture entirely and >>> instead do whatever you were doing (running zfstest) on bare metal. >> >> Yeah, would love to. >> But http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 prevents >> me from doing so. I'm trying to build a live-disc that includes >> http://svnweb.freebsd.org/base?view=revision&revision=226617 so I >> can recover the pool. > > Can you not use mfsBSD for this task? > > http://mfsbsd.vx.sk/ > > The 9.0-RELEASE image provided by mm@ on his site is dated 2011/10/26, > while SVN rev 226617 was committed on 2011/10/21 (5 days prior). Haven't tried mfs. But r226617 was MFC'd only yesterday, so I'd guess it would not include it. > You might also want to try a 9.0-RC2 build, which was just announced and > put on the mirrors a couple days ago: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/ > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ RC2 crashes for me, i.e. does not fix the issue (but otoh does not include r226617 either). > (Comment in passing: I still have no idea why the architecture > directories for 9.0 are "doubled up" like that; it almost looks like > the result of someone using rsync with a missing trailing slash on the > source directory). > > I can't explain why your ada1 "virtual disk" would drop off the bus > entirely. Possibly too much I/O and stress via VirtualBox causes too > long a delay, resulting in ahci.ko or CAM bits dropping the idsk from > the bus. kern.cam.ada.default_timeout is, by default, 30 seconds, which > is an awful long time, but I don't know if that is the only timeout > available (e.g. no idea what ahci.ko uses internally, I'd need to check > the code). The build finished eventually. It was just a one-time crash but I thought might as well report it here. Seems like it is entirely Vbox's fault though: my update to 4.1.6 was prob not a good idea. There are other things that are wonky... (it just trashed the disk image is used to build a new release). From owner-freebsd-stable@FreeBSD.ORG Mon Nov 21 01:41:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DBBF106566B for ; Mon, 21 Nov 2011 01:41:06 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B98D48FC0C for ; Mon, 21 Nov 2011 01:41:05 +0000 (UTC) Received: by faap15 with SMTP id p15so5839854faa.13 for ; Sun, 20 Nov 2011 17:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aBLUjvFuJv2J2TVSAizR0YU0e6pK4UxDtzPMpijJfQg=; b=EwkgxMyUyaXr7c+MDAJ93xCJUBFdinD43GcbVe5flgcDklS3Fe0Y14eF+0sfkKXoXf cs767tFNyvII5SJDgQkl4U2R2UTmZYqroefQbot8S+xcBaP2z9LOMPkCnlK7UnvX2cVe rSyr2NApZoPejPQSICnN1HhIL2HdLIMwl/2ts= MIME-Version: 1.0 Received: by 10.152.123.144 with SMTP id ma16mr7709127lab.32.1321838060972; Sun, 20 Nov 2011 17:14:20 -0800 (PST) Received: by 10.152.36.106 with HTTP; Sun, 20 Nov 2011 17:14:20 -0800 (PST) In-Reply-To: <20111120164128.GA29952@icarus.home.lan> References: <20111120160307.GA20262@icarus.home.lan> <20111120164128.GA29952@icarus.home.lan> Date: Sun, 20 Nov 2011 19:14:20 -0600 Message-ID: From: Scot Hetzel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Johannes Totz Subject: Re: panic: make_dev_credv: bad si_name (error=17, si_name=pass2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 01:41:06 -0000 On Sun, Nov 20, 2011 at 10:41 AM, Jeremy Chadwick > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/ > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ > > (Comment in passing: I still have no idea why the architecture > directories for 9.0 are "doubled up" like that; it almost looks like > the result of someone using rsync with a missing trailing slash on the > source directory). > This change to the ftp servers occurred due to the new installer: ftp://ftp.freebsd.org/pub/FreeBSD/releases/${MACHINE}/${MACHINE_ARCH} Scot From owner-freebsd-stable@FreeBSD.ORG Mon Nov 21 06:44:32 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92712106564A for ; Mon, 21 Nov 2011 06:44:32 +0000 (UTC) (envelope-from roycs@upcmail.nl) Received: from fep31.mx.upcmail.net (fep31.mx.upcmail.net [62.179.121.49]) by mx1.freebsd.org (Postfix) with ESMTP id 0729E8FC12 for ; Mon, 21 Nov 2011 06:44:31 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep11-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20111121062501.KDTQ9371.viefep11-int.chello.at@edge03.upcmail.net> for ; Mon, 21 Nov 2011 07:25:01 +0100 Received: from [192.168.0.8] ([62.163.114.185]) by edge03.upcmail.net with edge id ziR01h00E4049QE03iR1As; Mon, 21 Nov 2011 07:25:01 +0100 X-SourceIP: 62.163.114.185 From: Roy Stuivenberg To: freebsd-stable@freebsd.org Date: Mon, 21 Nov 2011 07:24:38 +0100 Message-ID: <1321856678.48792.9.camel@shadenet.roycs.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Cloudmark-Analysis: v=1.1 cv=HWkYZS0+VrF7DBwcY/1jDCl9/vw+sclK/cqazKbcp2w= c=1 sm=0 a=ybJQ6PovAlAA:10 a=84RgG4PYRqRjQkefcvkA:9 a=aI9IzDZPAg3PM6M07okA:7 a=CjuIK1q_8ugA:10 a=bH8bmhnBrXxHxep6:21 a=tUVC7YkEuaSq7_r1:21 a=kvz3qRr4LUcQX9t3hDIA:7 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kernel: deget(): pcbmap returned 6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 06:44:32 -0000 Hello, I'm running FreeBSD 8.2 stable amd64 uname -a : FreeBSD shadenet.roycs.nl 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Nov 17 16:54:43 CET 2011 dhondub@shadenet.roycs.nl:/usr/obj/usr/src/sys/GENERIC-ROYCS amd64 I found this error msg in tail -f /var/log/messages kernel: deget(): pcbmap returned 6 dmesg : root@shadenet dhondub # dmesg Copyright (c) 1992-2011 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 8.2-STABLE #0: Thu Nov 17 16:54:43 CET 2011 dhondub@shadenet.roycs.nl:/usr/obj/usr/src/sys/GENERIC-ROYCS amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz (2331.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Family = 6 Model = 17 Stepping = 7 Features=0xbfebfbff Features2=0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2034466816 (1940 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x1D, should be 0x14 (20101013/tbutils-354) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfc000000-0xfcffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] uhci0: port 0xb800-0xb81f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xbc00-0xbc1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfbfffc00-0xfbffffff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xfbff8000-0xfbffbfff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib2: irq 17 at device 28.0 on pci0 pci4: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfeaffc00-0xfeaffdff irq 16 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] pcib4: irq 16 at device 28.5 on pci0 pci2: on pcib4 ale0: port 0xcc00-0xcc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. miibus0: on ale0 atphy0: PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ale0: Ethernet address: 00:24:8c:02:ea:83 ale0: [FILTER] uhci3: port 0xb080-0xb09f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb480-0xb49f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfbfff800-0xfbfffbff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib5: at device 30.0 on pci0 pci5: on pcib5 rl0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff irq 16 at device 0.0 on pci5 miibus1: on rl0 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:10:a7:07:ca:98 rl0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xa000-0xa007,0x9c00-0x9c03,0x9880-0x9887,0x9800-0x9803,0x9480-0x948f,0x9400-0x940f irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa48f,0xa400-0xa40f irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 acd0: DVDR at ata2-slave UDMA66 ad6: 953869MB at ata3-master UDMA100 SATA 3Gb/s ad8: 238475MB at ata4-master UDMA100 SATA 3Gb/s hdac0: HDA Codec #0: Realtek ALC888 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm3: at cad 0 nid 1 on hdac0 SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! GEOM: ad6s1: geometry does not match label (255h,63s != 16h,63s). GEOM: ad8s1: geometry does not match label (255h,63s != 16h,63s). uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 ugen4.2: at usbus4 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 ums0: on usbus4 ums0: 4 buttons and [XYZ] coordinates ID=0 (probe0:ata2:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata2:0:1:0): CAM status: SCSI Status Error (probe0:ata2:0:1:0): SCSI status: Check Condition (probe0:ata2:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) cd0 at ata2 bus 0 scbus0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present ugen5.2: at usbus5 uhub8: on usbus5 uhub8: 4 ports with 4 removable, self powered ugen7.2: at usbus7 umass0: <201010261648> on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x4100 umass0:3:0:-1: Attached to scbus3 Trying to mount root from ufs:/dev/ad6s1a ale0: link state changed to UP (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry pid 93480 (gnome-mplayer), uid 1000: exited on signal 11 (core dumped) pid 93483 (gnome-mplayer), uid 1000: exited on signal 11 (core dumped) pid 93488 (gnome-mplayer), uid 1000: exited on signal 11 (core dumped) pid 93493 (gnome-mplayer), uid 1000: exited on signal 11 (core dumped) ugen7.3: at usbus7 umass1: on usbus7 umass1: SCSI over Bulk-Only; quirks = 0x0100 umass1:4:1:-1: Attached to scbus4 da0 at umass-sim1 bus 1 scbus4 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7583MB (1941441 4096 byte sectors: 255H 63S/T 120C) GEOM: da0: partition 1 does not end on a track boundary. ugen5.3: at usbus5 umass2: on usbus5 umass2: SCSI over Bulk-Only; quirks = 0x0100 umass2:5:2:-1: Attached to scbus5 da1 at umass-sim2 bus 2 scbus5 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 15680MB (32112640 512 byte sectors: 255H 63S/T 1998C) ugen7.4: at usbus7 umass3: on usbus7 umass3: SCSI over Bulk-Only; quirks = 0x0100 umass3:6:3:-1: Attached to scbus6 da2 at umass-sim3 bus 3 scbus6 target 0 lun 0 da2: Removable Direct Access SCSI-2 device da2: 40.000MB/s transfers da2: 3856MB (7897088 512 byte sectors: 255H 63S/T 491C) GEOM: da2: partition 1 does not start on a track boundary. GEOM: da2: partition 1 does not end on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not start on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not end on a track boundary. ugen5.4: at usbus5 umass4: on usbus5 umass4: SCSI over Bulk-Only; quirks = 0x4100 umass4:7:4:-1: Attached to scbus7 da3 at umass-sim4 bus 4 scbus7 target 0 lun 0 da3: Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: 3824MB (7831552 512 byte sectors: 255H 63S/T 487C) GEOM: da3: partition 1 does not start on a track boundary. GEOM: da3: partition 1 does not end on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not start on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not end on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not start on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not end on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not start on a track boundary. GEOM: iso9660/Debian 6.0.3 amd64 1: partition 1 does not end on a track boundary. ugen7.2: at usbus7 (disconnected) umass0: at uhub7, port 5, addr 2 (disconnected) GEOM: ad8s1: geometry does not match label (255h,63s != 16h,63s). ugen7.3: at usbus7 (disconnected) umass1: at uhub7, port 4, addr 3 (disconnected) (da0:umass-sim1:1:0:0): lost device (da0:umass-sim1:1:0:0): Synchronize cache failed, status == 0xa, scsi status == 0x0 (da0:umass-sim1:1:0:0): removing device entry Device da0s1 went missing before all of the data could be written to it; expect data loss. ugen5.4: at usbus5 (disconnected) umass4: at uhub8, port 3, addr 4 (disconnected) (da3:umass-sim4:4:0:0): lost device (da3:umass-sim4:4:0:0): removing device entry ugen5.3: at usbus5 (disconnected) umass2: at uhub8, port 2, addr 3 (disconnected) (da1:umass-sim2:2:0:0): lost device (da1:umass-sim2:2:0:0): removing device entry ugen5.3: at usbus5 umass0: on usbus5 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0:-1: Attached to scbus3 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 15680MB (32112640 512 byte sectors: 255H 63S/T 1998C) deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 deget(): pcbmap returned 6 /etc/rc.conf : # -- sysinstall generated deltas -- # Mon Jan 3 03:29:55 2011 # Created: Mon Jan 3 03:29:55 2011 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. hostname="shadenet.roycs.nl" defaultrouter="192.168.0.1" ifconfig_ale0="inet 192.168.0.8 netmask 255.255.255.0" sshd_enable="YES" clamav_clamd_enable="YES" font8x14="NO" font8x16="swiss-8x16" font8x8="swiss-8x8" keymap="us.iso" allscreens_flags="MODE_280" devd_enable="YES" dbus_enable="YES" hald_enable="YES" gnome_enable="YES" polkitd_enable="YES" fusefs_enable="YES" linux_enable="YES" /boot/loader.conf : hw.ata.atapi_dma="1" loader_logo="beastie" kern.maxdsiz="734003200" kern.maxfiles="16464" kern.maxusers="256" kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 nvidia_load="YES" msdosfs_load="YES" No smart answers searching google. Any help appreciated ;) Regards, Roy. -- , , /( )` \ \___ / | /- _ `-/ ' (/\/ \ \ /\ / / | ` \ O O ) / | `-^--'`< ' (_.) _ ) / `.___/` / `-----' / <----. __ / __ \ <----|====O)))==) \) /==== <----' `--' `.__,' \ | | \ / ______( (_ / \______ ,' ,-----' | \ `--{__________) \/ "Berkeley Unix Daemon" From owner-freebsd-stable@FreeBSD.ORG Mon Nov 21 07:16:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47E5A1065673 for ; Mon, 21 Nov 2011 07:16:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id EAE688FC14 for ; Mon, 21 Nov 2011 07:16:41 +0000 (UTC) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA11.westchester.pa.mail.comcast.net with comcast id zjDD1h0040ldTLk5BjGhbb; Mon, 21 Nov 2011 07:16:41 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta04.westchester.pa.mail.comcast.net with comcast id zjGg1h00W1t3BNj3QjGh8v; Mon, 21 Nov 2011 07:16:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A24EE102C19; Sun, 20 Nov 2011 23:16:39 -0800 (PST) Date: Sun, 20 Nov 2011 23:16:39 -0800 From: Jeremy Chadwick To: Roy Stuivenberg Message-ID: <20111121071639.GA43757@icarus.home.lan> References: <1321856678.48792.9.camel@shadenet.roycs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1321856678.48792.9.camel@shadenet.roycs.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: kernel: deget(): pcbmap returned 6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 07:16:42 -0000 On Mon, Nov 21, 2011 at 07:24:38AM +0100, Roy Stuivenberg wrote: > Hello, > > I'm running FreeBSD 8.2 stable amd64 > > uname -a : > FreeBSD shadenet.roycs.nl 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Nov 17 > 16:54:43 CET 2011 > dhondub@shadenet.roycs.nl:/usr/obj/usr/src/sys/GENERIC-ROYCS amd64 > > I found this error msg in tail -f /var/log/messages > > kernel: deget(): pcbmap returned 6 This is an error that comes from the MSDOS filesystem driver. $ grep -rn "pcbmap returned" /usr/src/sys /usr/src/sys/fs/msdosfs/msdosfs_denode.c:278: printf("deget(): pcbmap returned %d\n", error); Relevant code bits: 272 if (ldep->de_StartCluster != MSDOSFSROOT) { 273 error = pcbmap(ldep, 0xffff, 0, &size, 0); 274 if (error == E2BIG) { 275 ldep->de_FileSize = de_cn2off(pmp, size); 276 error = 0; 277 } else 278 printf("deget(): pcbmap returned %d\n", error); 279 } Maybe someone forgot to add #ifdef MSDOSFS_DEBUG/#endif around the else bits. A comparison (same source file, just further down): 377 } else { 378 error = pcbmap(dep, de_clcount(pmp, length) - 1, 0, 379 &eofentry, 0); 380 if (error) { 381 #ifdef MSDOSFS_DEBUG 382 printf("detrunc(): pcbmap fails %d\n", error); 383 #endif 384 return (error); 385 } 386 } Annotation for RELENG_8: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/msdosfs/msdosfs_denode.c?annotate=1.102.2.6.2.1 The relevant error handler bit was committed 17 years ago, while jkh@ last touched the surrounding bits 13 years ago. pcbmap() is a function in src/sys/fs/msdosfs/msdosfs_fat.c. There are "specific" error values which can get returned within it (such as E2BIG and EIO), otherwise it appears to rely upon bread() function bits. If the error number actually correlates with errno.h, then error 6 is ENXIO, or "Device not configured". Your dmesg, which I have snipped for brevity, contains a *lot* of messing about with different removable media, etc.. You conveniently removed the timestamps from your tail -f on /var/log/messages, so if I had to take a guess, it was that you stuck a device that had a FAT or FAT32 filesystem on it which tickled said message. You would be able to determine when it started/stopped based on timestamps in /var/log/messages vs. what you were doing at the time. If it happened when you weren't at the computer, possibly a cron job or periodic job iterated over the filesystem and tickled the error message in question. I do not know who is responsible for msdosfs at this time. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Nov 21 16:49:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E7A2106566B for ; Mon, 21 Nov 2011 16:49:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14DD48FC08 for ; Mon, 21 Nov 2011 16:49:43 +0000 (UTC) Received: from bigwig.baldwin.cx (96.47.65.170.static.nyinternet.net [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id B9AC346B23; Mon, 21 Nov 2011 11:49:42 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7EDDAB977; Mon, 21 Nov 2011 11:49:39 -0500 (EST) From: John Baldwin To: Xin LI Date: Mon, 21 Nov 2011 11:49:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111180310.pAI3ARbZ075115@mippet.ci.com.au> <201111180814.42656.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111211149.39932.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 21 Nov 2011 11:49:39 -0500 (EST) Cc: freebsd-stable@freebsd.org, Daryl Sayers Subject: Re: Low nfs write throughput X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:49:43 -0000 On Friday, November 18, 2011 7:36:47 pm Xin LI wrote: > Hi, > > > I don't know if it will help with your performance, but I have some patches > > to allow the NFS server to cluster writes. You can try > > www.freebsd.org/~jhb/patches/nfs_server_cluster.patch. I've tested it on 8, > > but it should probably apply fine to 9. > > I think 9 would need some changes, I just made them with minimal > compile testing, though. Oops, 8 has the same problems, and actually, it needs more fixes than that as the uio isn't initialized then. I've updated the patch at the URL so it should now work for the new server. Sorry. :/ -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Nov 22 15:43:32 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 291B1106566B for ; Tue, 22 Nov 2011 15:43:32 +0000 (UTC) (envelope-from sales@procut1.co.uk) Received: from deferred-out-118.livemail.co.uk (deferred-out-118.livemail.co.uk [213.171.216.118]) by mx1.freebsd.org (Postfix) with ESMTP id A5E3A8FC1A for ; Tue, 22 Nov 2011 15:43:30 +0000 (UTC) Received: from cust-smtp-193.fasthosts.net.uk (smtp-out-60.livemail.co.uk [213.171.216.60]) by deferred-out-118.livemail.co.uk (Postfix) with ESMTP id 94BD95A8506 for ; Tue, 22 Nov 2011 15:14:26 +0000 (GMT) Received: from kellyPC (109-170-215-94.xdsl.murphx.net [109.170.215.94]) by cust-smtp-193.fasthosts.net.uk (Postfix) with ESMTP id D18B914100A2 for ; Tue, 22 Nov 2011 15:14:24 +0000 (GMT) From: "Procut" To: Date: Tue, 22 Nov 2011 14:59:48 -0000 Message-ID: <0c6701cca929$5aa1d3d0$0fe57b70$@co.uk> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-gb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ProCut CNC Machining X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 15:43:32 -0000 Image 1 ProCut CNC Machining Service....High Volume Cutting & Routing Specialist Sales@ProCutuk.co.uk www.ProCutuk.co.uk Tel 01702 299540 Top picture...3100mm Schelling Beam Saw. Designed to cut all non-ferrous sheet material and with fully automatic rotating air bed to eliminate sketching and full CNC control for accuracy and repeatability. When the Schelling is used in conjunction with our dedicated Schelling Radiusing Machine it can eliminate routing all together! See below and find out how. ProCut A Better Cut All Round.. Image 3 Schelling Radiusing Machine When all you need is square or rectangles with radiused corners why pay for routing when ProCut has a dedicated Radiusing machine, so we cut them on the beam saw and produce the rad's on this machine which means a ?2 routed panel can cost as little as 45p! ProCut, the next best thing to a production line........ Image 4 Multihead Router with unique Sheet Stacking....... ProCut's pride and joy, The Multihead Multi Stacking 3m x 2m Axxiom routeing machine. The beauty of this machine is we can stack sheet material and with 2 routing and two drilling heads means we can produce up to 20 times more than a conventional router! ProCut. Saving you time and money..... Image 5 ProCut. Do Timber.... They don't make them like they used too! ProCut's Wadkin Thickness Planner is ideal for the odd 100,000 BBQ planks we produce as well as a variety of other timber jobs ProCut. Gives you the Cutting Edge.......... Image 2 4 Head Router! The above picture shows our Shoda 4 head router with 4 drilling stations, which makes short work of the smaller panel jobs as typically we will lay up from 20 to 60 panels at a time which means we can produce this quantity in one cut cycle. Pretty important when you need your job in double quick time! Phone today for your quote. 01702 299540 Did you know? that ProCut are believed to be the only known owners of the fully integrated clamping system on 2 of our larger routers giving x10, x20 x30 productivity over a conventional router! HOW'S THAT! And when you are open 24/7 meeting those deadlines is a breeze! | ProCut CNC Machining Services Ltd Unit 3 Towerfield Close Shoeburyness Essex SS3 9QP Tel 01702 299540 Sales@ProCutuk.co.uk www.proCutuk.co.uk | Click here to unsubscribe From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 05:23:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F693106564A for ; Thu, 24 Nov 2011 05:23:04 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 9A1788FC14 for ; Thu, 24 Nov 2011 05:23:03 +0000 (UTC) Received: (qmail 86580 invoked by uid 907); 24 Nov 2011 05:23:01 -0000 Received: from jmmacpro.transactionware.com (HELO jmmacpro.transactionware.com) (192.168.1.33) by midgard.transactionware.com (qpsmtpd/0.82) with ESMTP; Thu, 24 Nov 2011 16:23:01 +1100 From: Jan Mikkelsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2011 16:23:01 +1100 Message-Id: To: FreeBSD Stable Mailing List Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: bsdtar 9.0-RC2 --exclude regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 05:23:04 -0000 Hi, The --exclude option seems to have broken in 9.0-RC2. I see this behaviour on 9.0-RC2: $ mkdir dir1 dir2 $ touch dir1/a $ touch dir2/dir1 $ bsdtar -c -f - --exclude './dir1/*' . | bsdtar tf - ./ ./dir2/ And on 8.2-RELEASE (as expected): $ mkdir dir1 dir2 $ touch dir1/a $ touch dir2/dir1 $ bsdtar -c -f - --exclude './dir1/*' . | bsdtar tf - ./ ./dir2/ ./dir1/ ./dir2/dir1 There are two issues here: Excluding './dirname/*' excludes the directory 'dirname', not just the = contents of the directory. Excluding './dirname/*' excludes every file called 'dirname', regardless = of where the name is in the hierarchy. I'm assuming this is a bug, and not some intended change in behaviour. Regards, Jan Mikkelsen From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 07:29:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FDD6106564A for ; Thu, 24 Nov 2011 07:29:45 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3381F8FC08 for ; Thu, 24 Nov 2011 07:29:44 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3183953ggn.13 for ; Wed, 23 Nov 2011 23:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=8Cw7P9yURwC3OljNAxWMDzQnR49oaN1stQW9BUjVo4c=; b=va2sohBvWeNZsRGA/3yUlXOrXM9niJPxfJrNyfcTUCcHrz73ETZDL1m/kXv07vRTxU fQn0sj185FHc+6AIldu/5m/hhC3weEndp1u4uf3zb3aHVXam2XCDa+EXGEtejFbIBPLX 8NkDuJLQTFmtX1ahD/Xeqoj9prvZlVl5d7PSI= MIME-Version: 1.0 Received: by 10.50.17.199 with SMTP id q7mr31034094igd.20.1322118145761; Wed, 23 Nov 2011 23:02:25 -0800 (PST) Received: by 10.50.34.167 with HTTP; Wed, 23 Nov 2011 23:02:25 -0800 (PST) Date: Thu, 24 Nov 2011 01:02:25 -0600 Message-ID: From: Kris Bauer To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 07:29:45 -0000 Hello, I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 where the net.inet.tcp.reass.curesegments value is constantly increasing (and not descreasing when there is nominal traffic with the box). It is causing tcp slowdowns as described with kern/155407: Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session (for this socket and any other socket waiting for retransmited packets). After exhausted net.inet.tcp.reass.maxsegments allocation new entry in tcp_reass failed (for this socket and any other socket waiting for retransmited packets). I have increased the reass.maxsegments value to 16384 to temporarily avoid the problem, but the cursegments number keeps rising and it seems it will occur again. Is this an issue that anyone else has seen? I can provide more information if need be. Thanks, Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 16:30:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CAB1106566C for ; Thu, 24 Nov 2011 16:30:42 +0000 (UTC) (envelope-from kerbzo@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id CED208FC08 for ; Thu, 24 Nov 2011 16:30:41 +0000 (UTC) Received: by iakl21 with SMTP id l21so4897551iak.13 for ; Thu, 24 Nov 2011 08:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YkyM799LlESQWYuJQHymOO+biw3UfY9YSGpSK5EHiB0=; b=xp/4qWHNE0OqznwOIudnIUyI3asS0OefHI/NWvKZcBdfQCvjcwc3bQ5A9g5sCDSeNP +59/0yvhMc6gTTRxPHsS8hOxa0o9ivQ5d3fbnzaOYq7BYj6xRv1HhxhrjqTS2wJ2ncXi Bqb9vpewQKsA8INE6Eq+0DEe5rmi381jB6AME= MIME-Version: 1.0 Received: by 10.50.135.40 with SMTP id pp8mr33951008igb.1.1322150872251; Thu, 24 Nov 2011 08:07:52 -0800 (PST) Received: by 10.231.34.68 with HTTP; Thu, 24 Nov 2011 08:07:52 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Nov 2011 17:07:52 +0100 Message-ID: From: kerbzo To: Kris Bauer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 16:30:42 -0000 Hi, I 'm experiencing a similar issue but I don't know if mine could be considered normal behaviour: even if net.inet.tcp.reass.curesegments is set to 1680 and does not icrease, the output of vmstat -z shows a high tcpreass fail value that I don't remember in previous (8-STABLE) builds: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP [...] socket: 680, 25602, 740, 754, 4345747, 0, 0 unpcb: 240, 25600, 85, 459, 148595, 0, 0 ipq: 56, 819, 0, 378, 16126, 0, 0 udp_inpcb: 392, 25600, 24, 376, 222036, 0, 0 udpcb: 16, 25704, 24, 480, 222036, 0, 0 tcp_inpcb: 392, 25600, 719, 2391, 3958901, 0, 0 tcpcb: 976, 25600, 625, 707, 3958901, 0, 0 tcptw: 72, 5150, 93, 2357, 1486035, 0, 0 syncache: 152, 15375, 2, 398, 1587985, 0, 0 hostcache: 136, 15372, 1490, 4922, 119374, 0, 0 tcpreass: 40, 1680, 1680, 0, 108934,4800302, 0 sackhole: 32, 0, 0, 404, 134750, 0, 0 [...] System is FreeBSD 9.0-PRERELEASE #8 r227705 Bye, On Thu, Nov 24, 2011 at 8:02 AM, Kris Bauer wrot= e: > Hello, > > I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 where t= he > net.inet.tcp.reass.curesegments value is constantly increasing (and not > descreasing when there is nominal traffic with the box). =A0It is causing= tcp > slowdowns as described with kern/155407: > > Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session (fo= r > this socket and any other socket waiting for retransmited packets). After > exhausted net.inet.tcp.reass.maxsegments allocation new entry in tcp_reas= s > failed (for this socket and any other socket waiting for retransmited > packets). > > I have increased the reass.maxsegments value to 16384 to temporarily avoi= d > the problem, but the cursegments number keeps rising and it seems it will > occur again. > > Is this an issue that anyone else has seen? =A0I can provide more informa= tion > if need be. > > Thanks, > Kris > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 16:33:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B551065678 for ; Thu, 24 Nov 2011 16:33:46 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA6B8FC1B for ; Thu, 24 Nov 2011 16:33:46 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RTcF7-0002z9-77 for freebsd-stable@freebsd.org; Thu, 24 Nov 2011 17:33:45 +0100 Received: from cpe-188-129-114-88.dynamic.amis.hr ([188.129.114.88]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Nov 2011 17:33:45 +0100 Received: from ivoras by cpe-188-129-114-88.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Nov 2011 17:33:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 24 Nov 2011 17:33:25 +0100 Lines: 24 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-114-88.dynamic.amis.hr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 16:33:46 -0000 On 24.11.2011. 8:02, Kris Bauer wrote: > Hello, > > I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 where the > net.inet.tcp.reass.curesegments value is constantly increasing (and not > descreasing when there is nominal traffic with the box). It is causing tcp > slowdowns as described with kern/155407: > > Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session (for > this socket and any other socket waiting for retransmited packets). After > exhausted net.inet.tcp.reass.maxsegments allocation new entry in tcp_reass > failed (for this socket and any other socket waiting for retransmited > packets). > > I have increased the reass.maxsegments value to 16384 to temporarily avoid > the problem, but the cursegments number keeps rising and it seems it will > occur again. > > Is this an issue that anyone else has seen? I can provide more information > if need be. Is your configuration different than the default in some way? Do you use a firewall? Multithreaded netisr? One of the new TCP congestion control modules? From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 17:53:25 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E12E2106564A for ; Thu, 24 Nov 2011 17:53:25 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A01958FC15 for ; Thu, 24 Nov 2011 17:53:25 +0000 (UTC) Received: by iakl21 with SMTP id l21so5040597iak.13 for ; Thu, 24 Nov 2011 09:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y0Yl6YPTHSM2rPil5LRNUIe0Ou28MIwwlLWEzh5vOc8=; b=jiiXh5krjkBLDaTsydAABVHYFvWELCEubWJS2F6/iHjM2LvS9jYuUdM3JAdAWIEzXR i55sKrEcS6ovZkxFif22mX1RL8Eii2+KLaThSS2RlDpWHduMzvTFJ2zP/B8iyivHah/B Dg/E8YBBVqAuKlHeXbFlLdhT9M+6CsMmYrQBI= MIME-Version: 1.0 Received: by 10.42.162.130 with SMTP id y2mr7849267icx.26.1322157204439; Thu, 24 Nov 2011 09:53:24 -0800 (PST) Received: by 10.50.34.167 with HTTP; Thu, 24 Nov 2011 09:53:24 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Nov 2011 11:53:24 -0600 Message-ID: From: Kris Bauer To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 17:53:26 -0000 On Thu, Nov 24, 2011 at 10:33 AM, Ivan Voras wrote: > On 24.11.2011. 8:02, Kris Bauer wrote: > >> Hello, >> >> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 where >> the >> net.inet.tcp.reass.curesegments value is constantly increasing (and not >> descreasing when there is nominal traffic with the box). It is causing >> tcp >> slowdowns as described with kern/155407: >> >> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session (for >> this socket and any other socket waiting for retransmited packets). After >> exhausted net.inet.tcp.reass.maxsegments allocation new entry in tcp_reass >> failed (for this socket and any other socket waiting for retransmited >> packets). >> >> I have increased the reass.maxsegments value to 16384 to temporarily avoid >> the problem, but the cursegments number keeps rising and it seems it will >> occur again. >> >> Is this an issue that anyone else has seen? I can provide more >> information >> if need be. >> > > Is your configuration different than the default in some way? Do you use a > firewall? Multithreaded netisr? One of the new TCP congestion control > modules? > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I don't believe that my configuration is anything out of the usual. Just some standard LFN tuning. sysctl.conf net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.geom.eli.threads=2 kern.ipc.maxsockbuf=16777216 net.inet.tcp.cc.algorithm=htcp net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_inc=262144 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 net.inet.tcp.hostcache.expire=1 net.inet.tcp.delayed_ack=0 boot/loader.conf vm.kmem_size_max="5120M" vm.kmem_size="5120M" geom_mirror_load="YES" vfs.zfs.arc_max="4096M" vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout="15" vfs.zfs.write_limit_override="268435456" kern.ipc.nmbclusters="65536" cc_htcp_load="YES" net.inet.tcp.reass.maxsegments=16384 With the exception of the CC H-TCP and Reass maxsegments tunables, this is exactly what I was use with 8.2 with no issues. I have also seen the issue crop up (although I hadn't yet identified the source) while booting the box entirely with defaults (including using NewReno). The box is a 2 x Xeon E5405 Supermicro X7DCX with 8gb of RAM. Thanks, Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 19:38:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A998A106566B for ; Thu, 24 Nov 2011 19:38:20 +0000 (UTC) (envelope-from raul@turing.b2n.org) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id 3609A8FC0C for ; Thu, 24 Nov 2011 19:38:20 +0000 (UTC) Received: from mail1.isdefe.es (localhost [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id 720BD31A320 for ; Thu, 24 Nov 2011 20:19:46 +0100 (CET) Received: from turing.b2n.org (unknown [172.24.1.14]) by mail1.isdefe.es (Postfix) with ESMTP id 5CAE72BAC34 for ; Thu, 24 Nov 2011 20:19:46 +0100 (CET) Received: from [10.10.10.15] (ramc-desktop.pinlabs.b2n.org [10.10.10.15]) by turing.b2n.org (Postfix) with ESMTP id 08807A2116 for ; Thu, 24 Nov 2011 20:20:03 +0100 (CET) Message-ID: <4ECE9914.6020502@turing.b2n.org> Date: Thu, 24 Nov 2011 20:20:52 +0100 From: Raul User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 19:38:20 -0000 El 24/11/2011 17:07, kerbzo escribió: > I 'm experiencing a similar issue but I don't know if mine could be > considered normal behaviour: even if net.inet.tcp.reass.curesegments > is set to 1680 and does not icrease, the output of vmstat -z shows a > high tcpreass fail value that I don't remember in previous (8-STABLE) > builds: I see both, 'net.inet.tcp.reass.cursegments' reaching default 'net.inet.tcp.reass.maxsegments' after 38 minutes of uptime, apparently for never going down despite the amount of traffic and vmstat -z also show tcpreass failures. I also see sudden packet 'bursts' discarded by memory problems maybe related: [....] %date && netstat -s -p tcp | grep mem jueves, 24 de noviembre de 2011, 19:39:23 CET 5115 discarded due to memory problems %date && netstat -s -p tcp | grep mem jueves, 24 de noviembre de 2011, 19:39:30 CET 5268 discarded due to memory problems [....] My settings: [....] %cat /etc/sysctl.conf | grep -v ^\# debug.cpufreq.lowest=1000 %cat /boot/loader.conf | grep -v ^\# vfs.zfs.prefetch_disable=0 aio_load="YES" cc_cubic_load="YES" %sysctl net.isr net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct [....] cc cubic although loaded, not used in this 'pristine' reboot. About firewalling, pf using altq. Pretty recent compile: [....] %sysctl -a | grep RC2 kern.osrelease: 9.0-RC2 kern.version: FreeBSD 9.0-RC2 #0: Thu Nov 24 00:39:07 CET 2011 [....] Regards, Raúl. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 20:30:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67AE11065686 for ; Thu, 24 Nov 2011 20:30:47 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 301BD8FC2E for ; Thu, 24 Nov 2011 20:30:46 +0000 (UTC) Received: by iakl21 with SMTP id l21so5289440iak.13 for ; Thu, 24 Nov 2011 12:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aCwXMS3VuTziMvlm6w8SCGj+0FT7m9N2IjxkIrf07i0=; b=YE01wnma8mee+gfifGcaJe+ePZmc0yt06OrCfdYhRQ6vxgryK9ZyZCW/OD16TIWTgO 1hIgfEhErdU4GgA/67eTwYkwy0B6k002WM+zw3JnH9GSdHjJqjal305I8QoljQ6cwHuH K8R9bTit/o0BxEIsHCu6/1LoFVXtrfQsy8Org= MIME-Version: 1.0 Received: by 10.42.162.130 with SMTP id y2mr8432560icx.26.1322166646590; Thu, 24 Nov 2011 12:30:46 -0800 (PST) Received: by 10.50.34.167 with HTTP; Thu, 24 Nov 2011 12:30:46 -0800 (PST) In-Reply-To: <4ECE9914.6020502@turing.b2n.org> References: <4ECE9914.6020502@turing.b2n.org> Date: Thu, 24 Nov 2011 14:30:46 -0600 Message-ID: From: Kris Bauer To: Raul Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 20:30:47 -0000 On Thu, Nov 24, 2011 at 1:20 PM, Raul wrote: > El 24/11/2011 17:07, kerbzo escribi=F3: > > > I 'm experiencing a similar issue but I don't know if mine could be >> considered normal behaviour: even if net.inet.tcp.reass.curesegments >> is set to 1680 and does not icrease, the output of vmstat -z shows a >> high tcpreass fail value that I don't remember in previous (8-STABLE) >> builds: >> > > I see both, 'net.inet.tcp.reass.cursegments' reaching default > 'net.inet.tcp.reass.maxsegments' after 38 minutes of uptime, apparently f= or > never going down despite the amount of traffic and vmstat -z also show > tcpreass failures. > > I also see sudden packet 'bursts' discarded by memory problems maybe > related: > [....] > %date && netstat -s -p tcp | grep mem > jueves, 24 de noviembre de 2011, 19:39:23 CET > 5115 discarded due to memory problems > %date && netstat -s -p tcp | grep mem > jueves, 24 de noviembre de 2011, 19:39:30 CET > 5268 discarded due to memory problems > [....] > > My settings: > [....] > %cat /etc/sysctl.conf | grep -v ^\# > debug.cpufreq.lowest=3D1000 > > %cat /boot/loader.conf | grep -v ^\# > vfs.zfs.prefetch_disable=3D0 > aio_load=3D"YES" > cc_cubic_load=3D"YES" > > %sysctl net.isr > net.isr.numthreads: 1 > net.isr.maxprot: 16 > net.isr.defaultqlimit: 256 > net.isr.maxqlimit: 10240 > net.isr.bindthreads: 0 > net.isr.maxthreads: 1 > net.isr.direct: 0 > net.isr.direct_force: 0 > net.isr.dispatch: direct > [....] > > cc cubic although loaded, not used in this 'pristine' reboot. > About firewalling, pf using altq. > > Pretty recent compile: > [....] > %sysctl -a | grep RC2 > kern.osrelease: 9.0-RC2 > kern.version: FreeBSD 9.0-RC2 #0: Thu Nov 24 00:39:07 CET 2011 > [....] > > Regards, > Ra=FAl. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I am seeing the same sorts of things in netstat & vmstat: # netstat -s -p tcp |grep mem 742935 discarded due to memory problems # vmstat -z |grep tcpreass tcpreass: 40, 16464, 16340, 124, 131485,955443, 0 I also this filling up of reass.cursegments occur within an hour of reboot. Thanks, Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 22:06:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2930106566C for ; Thu, 24 Nov 2011 22:06:24 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 787508FC15 for ; Thu, 24 Nov 2011 22:06:24 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 59BF2110871 for ; Thu, 24 Nov 2011 23:06:23 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Stefan Bethke In-Reply-To: Date: Thu, 24 Nov 2011 23:06:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> References: <4ECE9914.6020502@turing.b2n.org> To: "freebsd-stable@freebsd.org List" X-Mailer: Apple Mail (2.1251.1) Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 22:06:24 -0000 Am 24.11.2011 um 21:30 schrieb Kris Bauer: > On Thu, Nov 24, 2011 at 1:20 PM, Raul wrote: >=20 > I am seeing the same sorts of things in netstat & vmstat: >=20 > # netstat -s -p tcp |grep mem > 742935 discarded due to memory problems >=20 > # vmstat -z |grep tcpreass > tcpreass: 40, 16464, 16340, 124, 131485,955443, 0 Same here: root@diesel:~# netstat -s -p tcp |grep mem 529211 discarded due to memory problems root@diesel:~# vmstat -z |grep tcpreass tcpreass: 40, 1680, 1679, 1, 118846,831450, = 0 root@diesel:~# uname -a FreeBSD diesel.lassitu.de 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #20: Fri = Nov 18 21:57:59 CET 2011 = root@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL amd64 root@diesel:~# uptime 11:01PM up 5 days, 23:15, 1 user, load averages: 0.14, 0.04, 0.01 root@diesel:~# svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: http://mirror.hanse.de/svn/freebsd/base/stable/9 Repository Root: http://mirror.hanse.de/svn/freebsd/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 227665 Node Kind: directory Schedule: normal Last Changed Author: fabient Last Changed Rev: 227664 Last Changed Date: 2011-11-18 15:41:48 +0100 (Fri, 18 Nov 2011) I regularly copy large files off my Tivo trans-atlantic (125ms RTT), and = TCP connections currently stall after about 500 megs, never recovering. = I suspect this is connected, as it started immediately after upgrading = the machine to 9-stable. As far as I can tell, the problem does not exist with 8-stable. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 22:38:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 384B2106564A for ; Thu, 24 Nov 2011 22:38:18 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id F140E8FC14 for ; Thu, 24 Nov 2011 22:38:17 +0000 (UTC) Received: by iakl21 with SMTP id l21so5481749iak.13 for ; Thu, 24 Nov 2011 14:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D6QNEo//b0WvwwXT1QPVuK//3Dn5Us17CgzbX8fpEto=; b=d+yrV6EI/reNPgN3SsVPEI0CSDqsZymLo/STR3t7erx6aOHodaJfkoHJ1A0czxXr+U ppqJuvx681pk/IPbUWy47buo/yFEipKkZ2NNxHA1oqw+lQTXzczHK5EFcdfZkRhPvb78 ocNyW8tsqaRKjBVVWIxg6DbNHazEbiWYUmO0Y= MIME-Version: 1.0 Received: by 10.43.53.1 with SMTP id vo1mr10145507icb.2.1322174296889; Thu, 24 Nov 2011 14:38:16 -0800 (PST) Received: by 10.50.34.167 with HTTP; Thu, 24 Nov 2011 14:38:16 -0800 (PST) In-Reply-To: <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> Date: Thu, 24 Nov 2011 16:38:16 -0600 Message-ID: From: Kris Bauer To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org List" Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 22:38:18 -0000 On Thu, Nov 24, 2011 at 4:06 PM, Stefan Bethke wrote: > Am 24.11.2011 um 21:30 schrieb Kris Bauer: > > > On Thu, Nov 24, 2011 at 1:20 PM, Raul wrote: > > > > I am seeing the same sorts of things in netstat & vmstat: > > > > # netstat -s -p tcp |grep mem > > 742935 discarded due to memory problems > > > > # vmstat -z |grep tcpreass > > tcpreass: 40, 16464, 16340, 124, 131485,955443, 0 > > Same here: > root@diesel:~# netstat -s -p tcp |grep mem > 529211 discarded due to memory problems > root@diesel:~# vmstat -z |grep tcpreass > tcpreass: 40, 1680, 1679, 1, 118846,831450, 0 > root@diesel:~# uname -a > FreeBSD diesel.lassitu.de 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #20: Fri > Nov 18 21:57:59 CET 2011 root@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL > amd64 > root@diesel:~# uptime > 11:01PM up 5 days, 23:15, 1 user, load averages: 0.14, 0.04, 0.01 > root@diesel:~# svn info /usr/src > Path: /usr/src > Working Copy Root Path: /usr/src > URL: http://mirror.hanse.de/svn/freebsd/base/stable/9 > Repository Root: http://mirror.hanse.de/svn/freebsd/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 227665 > Node Kind: directory > Schedule: normal > Last Changed Author: fabient > Last Changed Rev: 227664 > Last Changed Date: 2011-11-18 15:41:48 +0100 (Fri, 18 Nov 2011) > > I regularly copy large files off my Tivo trans-atlantic (125ms RTT), and > TCP connections currently stall after about 500 megs, never recovering. I > suspect this is connected, as it started immediately after upgrading the > machine to 9-stable. > > As far as I can tell, the problem does not exist with 8-stable. > > > Stefan > > -- > Stefan Bethke Fon +49 151 14070811 > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > 100-150ms RTT trans-atlantic transfers is what I saw (largely) driving up the reass.cursegments value. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 23:35:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20024106564A for ; Thu, 24 Nov 2011 23:35:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id CC0AB8FC08 for ; Thu, 24 Nov 2011 23:35:06 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so1905263vcb.13 for ; Thu, 24 Nov 2011 15:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Gk9IMHkvwSZTJWXcNY14q40Wy0Dpe86vsGA0a2ZDtOw=; b=ZmVRhLNPDucon3BJ5outzE6UN074y99lgUF6wVFePAPYCrTGZKPdFQlmw84qwlmG0O F/8kD/kg85lCdYCvPdN1G3FFCwmkS85T1L4D2rsGnaJdtSxcbfAnHL64gCRNuRoKWfDu KeHn38ChZ1NdAtoGZqARWu3myHt15MTd2UKTY= MIME-Version: 1.0 Received: by 10.52.34.78 with SMTP id x14mr31215526vdi.122.1322177705936; Thu, 24 Nov 2011 15:35:05 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.182.134 with HTTP; Thu, 24 Nov 2011 15:35:05 -0800 (PST) In-Reply-To: <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> Date: Fri, 25 Nov 2011 07:35:05 +0800 X-Google-Sender-Auth: 6tKZrgQZzr4nGXFnsSwcUka_DqM Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org List" Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 23:35:07 -0000 Have you tried disabling the tcp offload features of your NIC? Adrian From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 01:13:40 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D7F11065677 for ; Fri, 25 Nov 2011 01:13:40 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E74ED8FC0A for ; Fri, 25 Nov 2011 01:13:39 +0000 (UTC) Received: by iakl21 with SMTP id l21so5716367iak.13 for ; Thu, 24 Nov 2011 17:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pz2yQru8physgmdWNiu1c/tBSp5NS5x4c3hUx7ZZp8Y=; b=NpHnvregGa5qFgjfiRpPbe1rBRXFJBBy8IvGKRDnbPSQ1gkLKcyDfc1QX57PDZa2qz gRUYWN6LxIw/ipOt2T9uYpaw3D71je2puoMio7/JMmgZc/YkC7lnN4mXCkQ56fUfg+EW xw3rBUp3zWl4pbFsv0SvRQWgNqcwiSSxtZEL4= MIME-Version: 1.0 Received: by 10.50.17.199 with SMTP id q7mr35154608igd.20.1322183619067; Thu, 24 Nov 2011 17:13:39 -0800 (PST) Received: by 10.50.34.167 with HTTP; Thu, 24 Nov 2011 17:13:39 -0800 (PST) In-Reply-To: References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> Date: Thu, 24 Nov 2011 19:13:39 -0600 Message-ID: From: Kris Bauer To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org List" Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 01:13:40 -0000 On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd wrote: > Have you tried disabling the tcp offload features of your NIC? > > > Adrian > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > To test this, I added net.inet.tcp.tso=0 to sysctl.conf and restarted the box; it didn't work. net.inet.tcp.reass.cursegments immediately started climbing up and were exhausted within an hour. Kris. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 02:00:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561661065673 for ; Fri, 25 Nov 2011 02:00:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 263BE8FC08 for ; Fri, 25 Nov 2011 02:00:06 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 1Dy41i0011zF43QA1DzzXq; Fri, 25 Nov 2011 01:59:59 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id 1ENz1i00h1t3BNj8kEP0bp; Fri, 25 Nov 2011 02:23:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EEF17102C1A; Thu, 24 Nov 2011 18:00:04 -0800 (PST) Date: Thu, 24 Nov 2011 18:00:04 -0800 From: Jeremy Chadwick To: Kris Bauer Message-ID: <20111125020004.GA36109@icarus.home.lan> References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , "freebsd-stable@freebsd.org List" Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 02:00:07 -0000 On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote: > On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd wrote: > > > Have you tried disabling the tcp offload features of your NIC? > > > > > > Adrian > > > > To test this, I added net.inet.tcp.tso=0 to sysctl.conf and restarted the > box; it didn't work. net.inet.tcp.reass.cursegments immediately started > climbing up and were exhausted within an hour. I think Adrian was referring to RXCSUM and TXCSUM on your NIC; TSO is another offloading feature. See ifconfig(8) for how to disable those. Be aware that disabling them in real-time (e.g. ifconfig xxx -rxcsum -txcsum) may cause problems; there are some NIC drivers on FreeBSD which do not like you doing this once the NIC has established link (meaning "reloading the driver" (for lack of better term) results in wonky behaviour). So you may instead want to add those hyphen-options to your ifconfig_XXX lines in /etc/rc.conf and reboot the box. If none of this solves the problem, then I consider this a priority 0 blocker (read: "all hands on deck") issue with the IP stack in FreeBSD 9.x and will need immediate attention. I would strongly recommend a developer or clueful end-user begin tracking down who committed all of these bits and CC them into the thread. I would start by looking who implemented the net.inet.tcp.reass.cursegments sysctl, because that isn't in RELENG_8 at all. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 02:20:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE2F106564A for ; Fri, 25 Nov 2011 02:20:44 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 061368FC0A for ; Fri, 25 Nov 2011 02:20:42 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 638947E84F; Fri, 25 Nov 2011 13:01:33 +1100 (EST) Message-ID: <4ECEF6FD.5050006@freebsd.org> Date: Fri, 25 Nov 2011 13:01:33 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111016 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kris Bauer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 02:20:44 -0000 On 11/24/11 18:02, Kris Bauer wrote: > Hello, > > I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 where the > net.inet.tcp.reass.curesegments value is constantly increasing (and not > descreasing when there is nominal traffic with the box). It is causing tcp > slowdowns as described with kern/155407: > > Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session (for > this socket and any other socket waiting for retransmited packets). After > exhausted net.inet.tcp.reass.maxsegments allocation new entry in tcp_reass > failed (for this socket and any other socket waiting for retransmited > packets). > > I have increased the reass.maxsegments value to 16384 to temporarily avoid > the problem, but the cursegments number keeps rising and it seems it will > occur again. > > Is this an issue that anyone else has seen? I can provide more information > if need be. Thanks Kris, Raul and Stefan for the reports, I'll look into this. Cheers, Lawrence From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 03:19:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1887B106566C for ; Fri, 25 Nov 2011 03:19:53 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D24138FC08 for ; Fri, 25 Nov 2011 03:19:52 +0000 (UTC) Received: by iakl21 with SMTP id l21so5924043iak.13 for ; Thu, 24 Nov 2011 19:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=teOkewgBYt4oppO7XtwHQGqdAcvPvdWwqo7xGzYJaAg=; b=OjSBkERrsxW8qg/ToLxyrhTNQHiUGlHvNizI0x+uD15u4LOTNJbkfAvYm8oKCSMvFk K9pbfPC+wTLtMD7sStg3Hb0CPsoZIrHE/lpxYMReWJGL4UUfFXDo60gL5jPM5GrW3L99 hMHpczioCSUJYdwIci+OgqmO7ocWQL6mBBbkU= MIME-Version: 1.0 Received: by 10.43.53.1 with SMTP id vo1mr11018267icb.2.1322191192034; Thu, 24 Nov 2011 19:19:52 -0800 (PST) Received: by 10.50.34.167 with HTTP; Thu, 24 Nov 2011 19:19:51 -0800 (PST) In-Reply-To: <20111125020004.GA36109@icarus.home.lan> References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> <20111125020004.GA36109@icarus.home.lan> Date: Thu, 24 Nov 2011 21:19:51 -0600 Message-ID: From: Kris Bauer To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org List" Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 03:19:53 -0000 On Thu, Nov 24, 2011 at 8:00 PM, Jeremy Chadwick wrote: > On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote: > > On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd > wrote: > > > > > Have you tried disabling the tcp offload features of your NIC? > > > > > > > > > Adrian > > > > > > > To test this, I added net.inet.tcp.tso=0 to sysctl.conf and restarted the > > box; it didn't work. net.inet.tcp.reass.cursegments immediately started > > climbing up and were exhausted within an hour. > > I think Adrian was referring to RXCSUM and TXCSUM on your NIC; TSO is > another offloading feature. > > See ifconfig(8) for how to disable those. > > Be aware that disabling them in real-time (e.g. ifconfig xxx -rxcsum > -txcsum) may cause problems; there are some NIC drivers on FreeBSD which > do not like you doing this once the NIC has established link (meaning > "reloading the driver" (for lack of better term) results in wonky > behaviour). So you may instead want to add those hyphen-options to your > ifconfig_XXX lines in /etc/rc.conf and reboot the box. > > If none of this solves the problem, then I consider this a priority 0 > blocker (read: "all hands on deck") issue with the IP stack in FreeBSD > 9.x and will need immediate attention. > > I would strongly recommend a developer or clueful end-user begin > tracking down who committed all of these bits and CC them into the > thread. I would start by looking who implemented the > net.inet.tcp.reass.cursegments sysctl, because that isn't in RELENG_8 at > all. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > I have added -rxcsum -txcsum -tso to rc.conf and rebooted the box. This has not solved the problem. After a half-hour usage, I'm already up to reass.cursegments=2182 and it keeps climbing. Kris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 04:20:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3694B1065670 for ; Fri, 25 Nov 2011 04:20:41 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id E97508FC0C for ; Fri, 25 Nov 2011 04:20:40 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id DE8BE7E820; Fri, 25 Nov 2011 15:20:38 +1100 (EST) Message-ID: <4ECF1796.2060107@freebsd.org> Date: Fri, 25 Nov 2011 15:20:38 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111006 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kris Bauer References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> <20111125020004.GA36109@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: "freebsd-stable@freebsd.org List" , Jeremy Chadwick Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 04:20:41 -0000 On 11/25/11 14:19, Kris Bauer wrote: > On Thu, Nov 24, 2011 at 8:00 PM, Jeremy Chadwick > wrote: > >> On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote: >>> On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd >> wrote: >>> >>>> Have you tried disabling the tcp offload features of your NIC? >>>> >>>> >>>> Adrian >>>> >>> >>> To test this, I added net.inet.tcp.tso=0 to sysctl.conf and restarted the >>> box; it didn't work. net.inet.tcp.reass.cursegments immediately started >>> climbing up and were exhausted within an hour. >> >> I think Adrian was referring to RXCSUM and TXCSUM on your NIC; TSO is >> another offloading feature. >> >> See ifconfig(8) for how to disable those. >> >> Be aware that disabling them in real-time (e.g. ifconfig xxx -rxcsum >> -txcsum) may cause problems; there are some NIC drivers on FreeBSD which >> do not like you doing this once the NIC has established link (meaning >> "reloading the driver" (for lack of better term) results in wonky >> behaviour). So you may instead want to add those hyphen-options to your >> ifconfig_XXX lines in /etc/rc.conf and reboot the box. >> >> If none of this solves the problem, then I consider this a priority 0 >> blocker (read: "all hands on deck") issue with the IP stack in FreeBSD >> 9.x and will need immediate attention. >> >> I would strongly recommend a developer or clueful end-user begin >> tracking down who committed all of these bits and CC them into the >> thread. I would start by looking who implemented the >> net.inet.tcp.reass.cursegments sysctl, because that isn't in RELENG_8 at >> all. >> > > I have added -rxcsum -txcsum -tso to rc.conf and rebooted the box. This > has not solved the problem. After a half-hour usage, I'm already up to > reass.cursegments=2182 and it keeps climbing. This is pretty much guaranteed to be an accounting problem in the TCP reassembly code (netinet/tcp_reass.c), not a driver related issue. I would not expect any amount of tweaking, tuning or driver option twiddling to change the outcome (but if you do find something which alleviates it, do let us know). Kris, are you in a position to test kernel patches on the machine which is experiencing this problem? Cheers, Lawrence From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 04:22:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C77BA1065674 for ; Fri, 25 Nov 2011 04:22:11 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7D63A8FC16 for ; Fri, 25 Nov 2011 04:22:11 +0000 (UTC) Received: by iakl21 with SMTP id l21so6028280iak.13 for ; Thu, 24 Nov 2011 20:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b5HDsaxG/GA8L+sGmGzqhJLk7er7n+EvK4Y/YsesoDA=; b=YZ33sDBRHWFDy8WA0ikIpVHLbO7hSkPak0j+oquQCsy98CXBuRROSAF0e7JtggoRLi 4DRNUnRHIgIFBIGIvilulxhaPG2lC+efMahAZzIq20OTDV/dpDVvR9+xYBUZC1WIXNQU WOuquHx41DLfy8nFCmkFG/lsY55cVq9RNnQN4= MIME-Version: 1.0 Received: by 10.43.53.1 with SMTP id vo1mr11217256icb.2.1322194931046; Thu, 24 Nov 2011 20:22:11 -0800 (PST) Received: by 10.50.34.167 with HTTP; Thu, 24 Nov 2011 20:22:11 -0800 (PST) In-Reply-To: <4ECF1796.2060107@freebsd.org> References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> <20111125020004.GA36109@icarus.home.lan> <4ECF1796.2060107@freebsd.org> Date: Thu, 24 Nov 2011 22:22:11 -0600 Message-ID: From: Kris Bauer To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org List" Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 04:22:11 -0000 On Thu, Nov 24, 2011 at 10:20 PM, Lawrence Stewart wrote: > On 11/25/11 14:19, Kris Bauer wrote: > >> On Thu, Nov 24, 2011 at 8:00 PM, Jeremy Chadwick >> wrote: >> >> On Thu, Nov 24, 2011 at 07:13:39PM -0600, Kris Bauer wrote: >>> >>>> On Thu, Nov 24, 2011 at 5:35 PM, Adrian Chadd >>>> >>> wrote: >>> >>>> >>>> Have you tried disabling the tcp offload features of your NIC? >>>>> >>>>> >>>>> Adrian >>>>> >>>>> >>>> To test this, I added net.inet.tcp.tso=0 to sysctl.conf and restarted >>>> the >>>> box; it didn't work. net.inet.tcp.reass.cursegments immediately started >>>> climbing up and were exhausted within an hour. >>>> >>> >>> I think Adrian was referring to RXCSUM and TXCSUM on your NIC; TSO is >>> another offloading feature. >>> >>> See ifconfig(8) for how to disable those. >>> >>> Be aware that disabling them in real-time (e.g. ifconfig xxx -rxcsum >>> -txcsum) may cause problems; there are some NIC drivers on FreeBSD which >>> do not like you doing this once the NIC has established link (meaning >>> "reloading the driver" (for lack of better term) results in wonky >>> behaviour). So you may instead want to add those hyphen-options to your >>> ifconfig_XXX lines in /etc/rc.conf and reboot the box. >>> >>> If none of this solves the problem, then I consider this a priority 0 >>> blocker (read: "all hands on deck") issue with the IP stack in FreeBSD >>> 9.x and will need immediate attention. >>> >>> I would strongly recommend a developer or clueful end-user begin >>> tracking down who committed all of these bits and CC them into the >>> thread. I would start by looking who implemented the >>> net.inet.tcp.reass.cursegments sysctl, because that isn't in RELENG_8 at >>> all. >>> >>> >> I have added -rxcsum -txcsum -tso to rc.conf and rebooted the box. This >> has not solved the problem. After a half-hour usage, I'm already up to >> reass.cursegments=2182 and it keeps climbing. >> > > This is pretty much guaranteed to be an accounting problem in the TCP > reassembly code (netinet/tcp_reass.c), not a driver related issue. I would > not expect any amount of tweaking, tuning or driver option twiddling to > change the outcome (but if you do find something which alleviates it, do > let us know). > > Kris, are you in a position to test kernel patches on the machine which is > experiencing this problem? > > Cheers, > Lawrence > I'd be happy to test kernel patches with this machine. Thanks, Kris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 07:46:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D7AA106564A for ; Fri, 25 Nov 2011 07:46:47 +0000 (UTC) (envelope-from raul@b2n.org) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id 343E98FC08 for ; Fri, 25 Nov 2011 07:46:47 +0000 (UTC) Received: from mail1.isdefe.es (localhost [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id AF32B2BAC7C for ; Fri, 25 Nov 2011 08:27:27 +0100 (CET) Received: from turing.b2n.org (unknown [172.24.1.14]) by mail1.isdefe.es (Postfix) with ESMTP id 9BA4A2BAC7B for ; Fri, 25 Nov 2011 08:27:27 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by turing.b2n.org (Postfix) with ESMTP id 69E64A2116 for ; Fri, 25 Nov 2011 08:27:45 +0100 (CET) Message-ID: <4ECF4371.4040900@b2n.org> Date: Fri, 25 Nov 2011 08:27:45 +0100 From: Raul User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 07:46:47 -0000 El 25/11/2011 0:35, Adrian Chadd escribió: > Have you tried disabling the tcp offload features of your NIC? In my case, there is no tcp on the ethernet interface. It is pppoe (mpd / netgraph) so no fancy hardware acceleration there. [...] %ifconfig ng0 | head -n1 ng0: flags=88d1 metric 0 mtu 1492 [...] Regards, Raúl. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 08:47:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB9AE106566B; Fri, 25 Nov 2011 08:47:55 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2498FC14; Fri, 25 Nov 2011 08:47:55 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id B84001026BB; Fri, 25 Nov 2011 09:47:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Fri, 25 Nov 2011 09:47:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: "freebsd-stable@freebsd.org List" Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 08:47:55 -0000 Am 25.11.2011 um 00:35 schrieb Adrian Chadd: > Have you tried disabling the tcp offload features of your NIC? I'm using my em0 as a VLAN trunk, and I'm under the impression that that = disables all the hardware assists in the controller. Also, the LAN vlan = is bridged via OpenVPN and tap, making the whole bunch promiscous, which = I believe also forces off the acceleration. em0: flags=3D8943 metric = 0 mtu 1500 = options=3D219b ether 00:1c:c0:7d:8c:50 inet6 fe80::21c:c0ff:fe7d:8c50%em0 prefixlen 64 scopeid 0x1=20 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active bridge0: flags=3D8843 metric 0 = mtu 1500 ether 02:00:00:00:00:01 inet6 2001:470:1f0b:1064::1 prefixlen 64=20 inet 44.128.65.1 netmask 0xffffffc0 broadcast 44.128.65.63 inet6 fe80::21c:c0ff:fe7d:8c50%bridge0 prefixlen 64 scopeid 0xd=20= nd6 options=3D21 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vlan1 flags=3D143 ifmaxaddr 0 port 15 priority 128 path cost 55 member: tap0 flags=3D143 ifmaxaddr 0 port 14 priority 128 path cost 2000000 vlan1: flags=3D8943 = metric 0 mtu 1500 options=3D3 ether 00:1c:c0:7d:8c:50 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active vlan: 1 parent interface: em0 em0@pci0:0:25:0: class=3D0x020000 card=3D0x50038086 = chip=3D0x10cd8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82567LF-2 Gigabit Network Connection' class =3D network subclass =3D ethernet cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit enabled with 1 message cap 09[e0] =3D vendor (length 6) Intel cap 2 version 0 --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 08:51:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3058106566C for ; Fri, 25 Nov 2011 08:51:29 +0000 (UTC) (envelope-from raul@turing.b2n.org) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id 7929A8FC0C for ; Fri, 25 Nov 2011 08:51:28 +0000 (UTC) Received: from mail1.isdefe.es (localhost [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id DFA582BAC7D for ; Fri, 25 Nov 2011 09:51:07 +0100 (CET) Received: from turing.b2n.org (unknown [172.24.1.14]) by mail1.isdefe.es (Postfix) with ESMTP id CB4872BAC79 for ; Fri, 25 Nov 2011 09:51:07 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by turing.b2n.org (Postfix) with ESMTP id 9BA1BA2116 for ; Fri, 25 Nov 2011 09:51:25 +0100 (CET) Message-ID: <4ECF570D.4070105@turing.b2n.org> Date: Fri, 25 Nov 2011 09:51:25 +0100 From: Raul User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> In-Reply-To: <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 08:51:29 -0000 El 24/11/2011 23:06, Stefan Bethke escribió: [....] > I regularly copy large files off my Tivo trans-atlantic (125ms RTT), > and TCP connections currently stall after about 500 megs, never > recovering. I suspect this is connected, as it started immediately > after upgrading the machine to 9-stable. I've not seen not recovering nor completely stalled (mpd tcpmssfix related?). What I see is a normal start, normal bandwidth increase, peak performance using all available bandwidth and after that bandwidth drops to a 'unreasonable' level and stay there most of time during transfer. Numbers always depend on too much factors, but to illustrate how dramatic it is: [....] %ping -c100 XX.au PING XX.au (136.186.XX.XX): 56 data bytes ... 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 352.036/354.258/374.731/3.593 ms [....] downloading by ftp an iso image from that host (wget), transfer peaks at about 1.4MBytes/sec before falling up to 2,9?KBytes/sec where most transfer happens. Please note, this numbers come from a pppoe link (DSL) established by mpd55 with *'tcpmsswilink'*: [....] %cat /usr/local/etc/mpd5/mpd.conf | grep fix set iface enable tcpmssfix [....] I hope that shed some light. Regards, Raúl. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 15:18:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F951065670 for ; Fri, 25 Nov 2011 15:18:12 +0000 (UTC) (envelope-from linuxmail@4lin.net) Received: from mail.4lin.net (mail.4lin.net [IPv6:2a01:4f8:130:6021::50]) by mx1.freebsd.org (Postfix) with ESMTP id 95D4E8FC08 for ; Fri, 25 Nov 2011 15:18:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.4lin.net (Postfix) with ESMTP id 9BD683C868 for ; Fri, 25 Nov 2011 16:18:46 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.4lin.net Received: from mail.4lin.net ([127.0.0.1]) by localhost (mail.4lin.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSgqUH957MoW for ; Fri, 25 Nov 2011 16:18:40 +0100 (CET) Received: from pcdenny.rbg.informatik.tu-darmstadt.de (pcdenny.rbg.informatik.tu-darmstadt.de [130.83.160.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.4lin.net (Postfix) with ESMTPSA id 328243C841 for ; Fri, 25 Nov 2011 16:18:40 +0100 (CET) From: Denny Schierz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Nov 2011 16:18:01 +0100 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: What about network virtualization for jails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 15:18:12 -0000 hi, I searched for network problems for my jail (can get out, via ssh from = jail, but not ssh into the jail, other as the host) and reading = something about network virtualization for jails: http://imunes.tel.fer.hr/virtnet/ does this work for FreeBSD9 ? cu denny= From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 15:54:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75DB81065673 for ; Fri, 25 Nov 2011 15:54:39 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 375C48FC0C for ; Fri, 25 Nov 2011 15:54:38 +0000 (UTC) Received: by ghbg20 with SMTP id g20so3899489ghb.13 for ; Fri, 25 Nov 2011 07:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nO+4Axr1vi4nMInHDgDeC8WRgr6wrQGwWKwHxSpwbUw=; b=Yhs6PA/EWPRUvP+0MuXqCiq8t7OMgG1aS1jCcmnJdEyMCAFdyc7QN/DapNKBx0ziL7 RWNcGs/JrPpPqUH6PpAq8HdpNH74zcK+BLCjsRWtM01lK7mb3+B6SMCpDF1ObWY5qdCI UWzIMDyASk2le9togkpBsBbTL6NIyXCz0u4/Q= MIME-Version: 1.0 Received: by 10.182.44.35 with SMTP id b3mr10215386obm.26.1322236478379; Fri, 25 Nov 2011 07:54:38 -0800 (PST) Received: by 10.182.110.74 with HTTP; Fri, 25 Nov 2011 07:54:38 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Nov 2011 08:54:38 -0700 Message-ID: From: Shawn Webb To: Denny Schierz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: What about network virtualization for jails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 15:54:39 -0000 Yes. You can use VIMAGE/vnet with jails. In fact, I just blogged about how to set it up: http://0xfeedface.org/blog/2011-11-21/lattera/freebsd-vnet-jail-admin-proje= ct I'm also writing a php project that will help administer FreeBSD jails: https://github.com/lattera/jailadmin Thanks, Shawn On Fri, Nov 25, 2011 at 8:18 AM, Denny Schierz wrote: > hi, > > I =A0searched for network problems for my jail (can get out, via ssh from= jail, but not ssh into the jail, other as the host) and reading something = about network virtualization for jails: > > http://imunes.tel.fer.hr/virtnet/ > > does this work for FreeBSD9 ? > > cu denny_______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 18:05:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 016E81065672 for ; Fri, 25 Nov 2011 18:05:13 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-3-2-0-2.r20.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id A71298FC0A for ; Fri, 25 Nov 2011 18:05:12 +0000 (UTC) Received: from scollay.m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id pAPI56lQ080449 for ; Fri, 25 Nov 2011 13:05:11 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <4ECFD8D2.4030604@m5p.com> Date: Fri, 25 Nov 2011 13:05:06 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111111 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> <20111125020004.GA36109@icarus.home.lan> In-Reply-To: <20111125020004.GA36109@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Fri, 25 Nov 2011 13:05:11 -0500 (EST) X-Scanned-By: MIMEDefang 2.72 on IPv6:2001:418:3fd::f7 Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 18:05:13 -0000 On 11/24/11 21:00, Jeremy Chadwick wrote: >[...] > If none of this solves the problem, then I consider this a priority 0 > blocker (read: "all hands on deck") issue with the IP stack in FreeBSD > 9.x and will need immediate attention. > > I would strongly recommend a developer or clueful end-user begin > tracking down who committed all of these bits and CC them into the > thread. I would start by looking who implemented the > net.inet.tcp.reass.cursegments sysctl, because that isn't in RELENG_8 at > all. > I've tried out the 9.0 release candidates, and what I notice is that for a few minutes after the system starts, I get wonderful NFS read throughput (7+ MB/s over a 100 megabit interface) -- more than twice as fast as 7.n or 8.n on the same hardware -- quickly degrading to abysmal (less than 0.5 MB/s). Is this possibly related to the problem under discussion? -- George Mitchell P.S. A lot of other 9.0 features look very nice indeed! From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 20:32:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F12E8106566B for ; Fri, 25 Nov 2011 20:32:12 +0000 (UTC) (envelope-from linuxmail@4lin.net) Received: from mail.4lin.net (mail.4lin.net [IPv6:2a01:4f8:130:6021::50]) by mx1.freebsd.org (Postfix) with ESMTP id 849048FC0C for ; Fri, 25 Nov 2011 20:32:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.4lin.net (Postfix) with ESMTP id A50A53C879 for ; Fri, 25 Nov 2011 21:32:48 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.4lin.net Received: from mail.4lin.net ([127.0.0.1]) by localhost (mail.4lin.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cegU-jJkSgba for ; Fri, 25 Nov 2011 21:32:44 +0100 (CET) Received: from denny-schierzs-mac-mini.fritz.box (ip-92-50-81-210.unitymediagroup.de [92.50.81.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.4lin.net (Postfix) with ESMTPSA id D863F3C85A for ; Fri, 25 Nov 2011 21:32:43 +0100 (CET) From: Denny Schierz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_FDC0C34A-151D-4C0E-9608-DBE0CABAC7EF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Fri, 25 Nov 2011 21:32:03 +0100 In-Reply-To: To: freebsd-stable@freebsd.org References: Message-Id: <8DC79843-9CF8-4C49-B871-0B0BB591B95C@4lin.net> X-Mailer: Apple Mail (2.1251.1) Subject: Re: What about network virtualization for jails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 20:32:13 -0000 --Apple-Mail=_FDC0C34A-151D-4C0E-9608-DBE0CABAC7EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi Shawn, Am 25.11.2011 um 16:54 schrieb Shawn Webb: > Yes. You can use VIMAGE/vnet with jails. In fact, I just blogged about > how to set it up: >=20 > = http://0xfeedface.org/blog/2011-11-21/lattera/freebsd-vnet-jail-admin-proj= ect >=20 > I'm also writing a php project that will help administer FreeBSD = jails: >=20 > https://github.com/lattera/jailadmin that's extremely cool :-) I will test it the next days, with our most = important services. Does the new features-set make any differences for = NFS server in a jail? I want to switch from two Solaris 10 NFS servers = to FreeBSD Jails. At the moment I know only, that this is bad idea, because of kernel = problems. User-space NFS is also no way, to serve as NFS Server for 130 = NFS (Linux) clients, booting there "/" over NFS. cu denny= --Apple-Mail=_FDC0C34A-151D-4C0E-9608-DBE0CABAC7EF Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk7P+0QACgkQKlzhkqt9P+CzswCfW76LPpnPqSYjz/UGes9CFp53 4MQAn1zX9jVoq+hmGwsVC809RbOhnPHW =gJQG -----END PGP SIGNATURE----- --Apple-Mail=_FDC0C34A-151D-4C0E-9608-DBE0CABAC7EF-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 20:36:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06251106564A for ; Fri, 25 Nov 2011 20:36:13 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA47E8FC13 for ; Fri, 25 Nov 2011 20:36:12 +0000 (UTC) Received: by yenq9 with SMTP id q9so5426482yen.13 for ; Fri, 25 Nov 2011 12:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jHvaaLfDV3GXYGNnvfc5tHoVG1Ku9+8NwZ7FaU1VuhU=; b=A2dkUqUi2Vg3NgsoQ1ZccsonY9TxEntw6RDnsoRPRaAoGoy7Dpu5Pss9HVgphhaK9S ZWW3wB9z7SgNiv2HoyY+m/aoDeaTy3f8Qnba+Qr0BveMGdeP/RgHSqcbJKG6XwEjQ0N4 yJZQRf4PwZmjIjjDJGKwsXIhx6J45tZUzCk1g= MIME-Version: 1.0 Received: by 10.182.31.68 with SMTP id y4mr6991031obh.66.1322253371927; Fri, 25 Nov 2011 12:36:11 -0800 (PST) Received: by 10.182.110.74 with HTTP; Fri, 25 Nov 2011 12:36:11 -0800 (PST) In-Reply-To: <8DC79843-9CF8-4C49-B871-0B0BB591B95C@4lin.net> References: <8DC79843-9CF8-4C49-B871-0B0BB591B95C@4lin.net> Date: Fri, 25 Nov 2011 13:36:11 -0700 Message-ID: From: Shawn Webb To: Denny Schierz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: What about network virtualization for jails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 20:36:13 -0000 I don't really know much about how using vnet with jails will affect NFS services. I would suggest setting up a test environment before attempting anything on production servers. Please also note that my jail admin project is written mainly to fit my particular use-case, but I'll always gladly accept patches if another use-case needs to be addressed. Thanks, Shawn On Fri, Nov 25, 2011 at 1:32 PM, Denny Schierz wrote: > hi Shawn, > > Am 25.11.2011 um 16:54 schrieb Shawn Webb: > >> Yes. You can use VIMAGE/vnet with jails. In fact, I just blogged about >> how to set it up: >> >> http://0xfeedface.org/blog/2011-11-21/lattera/freebsd-vnet-jail-admin-pr= oject >> >> I'm also writing a php project that will help administer FreeBSD jails: >> >> https://github.com/lattera/jailadmin > > that's extremely cool :-) I will test it the next days, with our most imp= ortant services. Does the new features-set make any differences for NFS ser= ver in a jail? I want to switch from two Solaris 10 NFS =A0servers to FreeB= SD Jails. > At the moment I know only, that this is bad idea, because of kernel probl= ems. User-space NFS is also no way, to serve as NFS Server for 130 NFS =A0(= Linux) clients, booting there "/" =A0over NFS. > > cu denny > -----BEGIN PGP SIGNATURE----- > > iEYEARECAAYFAk7P+0QACgkQKlzhkqt9P+CzswCfW76LPpnPqSYjz/UGes9CFp53 > 4MQAn1zX9jVoq+hmGwsVC809RbOhnPHW > =3DgJQG > -----END PGP SIGNATURE----- > > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 20:38:17 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 314DB106566B for ; Fri, 25 Nov 2011 20:38:17 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B8AD88FC0A for ; Fri, 25 Nov 2011 20:38:16 +0000 (UTC) Received: by wwe5 with SMTP id 5so2636017wwe.31 for ; Fri, 25 Nov 2011 12:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:x-pgp-keyid:x-pgp-uri:x-pgp-fingerprint :x-mailer; bh=Oq8OnpoMbin/sFQuNuXfd3sjpZZDH7c07q+gvFlF8F0=; b=HwD5Ass13gk0b8E3JnEs1KbL+YF5p1dmg5inIR5s7OldmpOsbF0fmvC2Z2xtXPyMr0 xz5JNIo4QkQCsFXWxwbsu6V/5R14y7dU/pZ9/i0GpkR5o5mplklpLsKpz89oHfAl126I R3dQgDTTlRlL8+OY6TYnNl3l5vHPwVn2ZZfc0= Received: by 10.216.153.137 with SMTP id f9mr144520wek.4.1322252026245; Fri, 25 Nov 2011 12:13:46 -0800 (PST) Received: from localhost ([82.113.98.137]) by mx.google.com with ESMTPS id fg15sm5146086wbb.7.2011.11.25.12.13.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Nov 2011 12:13:45 -0800 (PST) Date: Fri, 25 Nov 2011 21:13:31 +0100 From: Thomas Zander To: stable@freebsd.org Message-ID: <20111125201331.GA2193@marvin2011.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline X-PGP-KeyID: 0xC85996CD X-PGP-URI: http://pgpkeys.pca.dfn.de/pks/lookup?search=0xC85996CD X-PGP-Fingerprint: 4F59 75B4 4CE3 3B00 BC61 5400 8DD4 8929 C859 96CD X-Mailer: Marvin Mail (Build 1322247649) Cc: Subject: Sandy Bridge and MCA UNCOR PCC (problem + solution) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 20:38:17 -0000 List, here's a rant about a recent problem I had and the surprising solution. I recently had to investigate weird unexpected issues on a workstation. Relevant hardware: Asus P8B-WS, Xeon E3-1260L (Sandy Bride, Intel HD-2000 graphics) Since we don't have kms and friends in STABLE yet, and I can live without accelerated video for now, I am using the vesa driver on this machine. Initially, this had two major drawbacks: 1) 1280x1024 resolution utterly sucks on a 1680x1050 screen. 2) Reproducable unhandled MCA events (and subsequent kernel panics) like the following whenever I switch from X to console: panic: machine check trap ... MCA: CPU 6 UNCOR UNCOR UNCOR PCC PCC PCC internal error 2internal error 2PCC internal error 2 The kernel dump _always_ showed something like: current process = 11 (idle: cpu3) trap number = 28 #1 0xffffffff805db167 at panic+0x187 #2 0xffffffff808c6820 at trap_fatal+0x290 #3 0xffffffff808c6d3a at trap+0x10a #4 0xffffffff808ae894 at calltrap+0x8 #5 0xffffffff801f6b9a at acpi_cpu_idle+0x20a #6 0xffffffff806003af at sched_idletd+0x11f #7 0xffffffff805afe6f at fork_exit+0x11f #8 0xffffffff808aedde at fork_trampoline+0xe mcelog did not help decoding the MCA output and the "internal error2" message made me suspect that this CPU was maybe just broken. However, due to my utter inabilty of producing the slightest other problem with this machine (constantly heavy CPU + IO load) or any problem using other operating systems I derived the wild speculation that there might be something with the Sandy Bridge silicon which this exact sequence of actions on FreeBSD reliably could trigger. Long story short: I got the latest Bios from Asus for this Board. The changelog of course said absolutely nothing about fixing any known problem. Upon boot I entered the Bios settings and noticed that it apparently contained a microcode update. The changelog for microcode from Intel is of course non-existing. And since this boot there has not been a single problem with this machine. Vesa now works in 1680x1050 and switching from X to console and back does not trigger MCA events anymore. I like to believe that for the first time a microcode update from Intel fixed my specific problem. Anyway, now the story is on the list and for Google to find, in case anyone else has this problem as well. Best regards Riggs -- - Now the world has gone to bed | Now I lay me down to sleep - -- Darkness won't engulf my head | Try to count electric sheep -- --- I can see by infra-red | Sweet dream wishes you can keep --- ---- How I hate the night | How I hate the night ---- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 20:49:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49558106566B for ; Fri, 25 Nov 2011 20:49:27 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C5F678FC17 for ; Fri, 25 Nov 2011 20:49:26 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so6250965bkb.13 for ; Fri, 25 Nov 2011 12:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FGKUkLY7w1nmmuBEQ8sX29jQM7GEnG7Bi9hSWsQKIgY=; b=NKuGxRxKlnyCv/up3CyUEk6QXVgjgte+i9iryF3AreDG0RQUduakEEA2dMjLr3v6Ru RkyT7g+SLj4nhNjIjYIbBfwVYXuXFjOK7NeRTU7Ad48YoJSb2jX0vAPhjMjmUBHRtRFx 3EPDkCrE68PMNDUpz3xs7xu9BlU8RbmEySmus= MIME-Version: 1.0 Received: by 10.205.131.3 with SMTP id ho3mr35555661bkc.11.1322254165207; Fri, 25 Nov 2011 12:49:25 -0800 (PST) Received: by 10.223.83.14 with HTTP; Fri, 25 Nov 2011 12:49:25 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Nov 2011 14:49:25 -0600 Message-ID: From: Adam Vande More To: Denny Schierz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: What about network virtualization for jails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 20:49:27 -0000 On Fri, Nov 25, 2011 at 9:18 AM, Denny Schierz wrote: > hi, > > I searched for network problems for my jail (can get out, via ssh from > jail, but not ssh into the jail, other as the host) and reading something > about network virtualization for jails: > > http://imunes.tel.fer.hr/virtnet/ > > does this work for FreeBSD9 ? > http://druidbsd.sourceforge.net/vimage.html -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 21:38:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C884106564A for ; Fri, 25 Nov 2011 21:38:55 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5F58FC0C for ; Fri, 25 Nov 2011 21:38:54 +0000 (UTC) Received: from [192.92.129.101] ([192.92.129.101]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pAPLI9PZ051562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 25 Nov 2011 23:18:15 +0200 (EET) (envelope-from daniel@digsys.bg) From: Daniel Kalchev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Nov 2011 23:18:11 +0200 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: igb hang when cable unplugged X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 21:38:55 -0000 I am observing an transmit hang of the igb driver when the cable is = unplugged. It only recovers after unit reset, such as ifconfig igb0 down up This is with kernel FreeBSD xxx 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Sep 30 16:17:47 EEST = 2011 root@xxx:/usr/obj/usr/src/sys/GENERIC amd64 igb0: port = 0x3020-0x303f mem = 0xb1d60000-0xb1d7ffff,0xb1d40000-0xb1d5ffff,0xb1e04000-0xb1e07fff irq 37 = at device 0.0 on pci13 igb0: Using MSIX interrupts with 9 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:25:90:36:ee:7c The interface is quad port Supermicro branded PCI-E card with=20 pciconf -vl igb0@pci0:13:0:0: class=3D0x020000 card=3D0x10c915d9 = chip=3D0x10c98086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet igb1@pci0:13:0:1: class=3D0x020000 card=3D0x10c915d9 = chip=3D0x10c98086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet igb2@pci0:16:0:0: class=3D0x020000 card=3D0x10c915d9 = chip=3D0x10c98086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet igb3@pci0:16:0:1: class=3D0x020000 card=3D0x10c915d9 = chip=3D0x10c98086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet Has anyone experience something like this? Is there solution? It is very = inconvenient to have to down/up the interfaces manually via the IPMI = console when such thing happens. Daniel= From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 21:39:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C3F3106566B for ; Fri, 25 Nov 2011 21:39:00 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9898FC08 for ; Fri, 25 Nov 2011 21:38:59 +0000 (UTC) Received: from [192.92.129.101] ([192.92.129.101]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pAPLCIHA051556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Nov 2011 23:12:46 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Daniel Kalchev In-Reply-To: Date: Fri, 25 Nov 2011 23:12:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DC79843-9CF8-4C49-B871-0B0BB591B95C@4lin.net> To: Shawn Webb X-Mailer: Apple Mail (2.1251.1) Cc: Denny Schierz , freebsd-stable@freebsd.org Subject: Re: What about network virtualization for jails? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 21:39:00 -0000 On Nov 25, 2011, at 10:36 PM, Shawn Webb wrote: > I don't really know much about how using vnet with jails will affect > NFS services. I would suggest setting up a test environment before > attempting anything on production servers. I was unsuccessful in setting up NFS from within a VIMAGE jail -- that = had to run in the host environment. If there is a way to do it, that = would be great news. Daniel= From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 23:18:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00ECE106566B for ; Fri, 25 Nov 2011 23:18:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA158FC13 for ; Fri, 25 Nov 2011 23:18:27 +0000 (UTC) Received: by wwe5 with SMTP id 5so2840672wwe.31 for ; Fri, 25 Nov 2011 15:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sZAOA7xVSoH08T8oz9efIjwyZnw2HnAILjSWE1d+SOs=; b=VTQwHUzUboFJZQ49uImgUgbxPVG0TEFFQs7XKlORdlbTrPl6/gKUAAIYpcKXimW/LT h86uHU+YvHh33smBJCRcZAoo6YXfh241S5xMmY9glfPDP65k7hSgtNGfpmDp/0FtUPeM LaeLHeX7kw10afQbKsPTi9V7sEWg4TBRwZr8A= MIME-Version: 1.0 Received: by 10.180.81.73 with SMTP id y9mr36403850wix.37.1322261572583; Fri, 25 Nov 2011 14:52:52 -0800 (PST) Received: by 10.180.93.200 with HTTP; Fri, 25 Nov 2011 14:52:52 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Nov 2011 14:52:52 -0800 Message-ID: From: Jack Vogel To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: igb hang when cable unplugged X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 23:18:28 -0000 On Fri, Nov 25, 2011 at 1:18 PM, Daniel Kalchev wrote: > I am observing an transmit hang of the igb driver when the cable is > unplugged. It only recovers after unit reset, such as > > ifconfig igb0 down up > > This is with kernel > > FreeBSD xxx 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Sep 30 16:17:47 EEST > 2011 root@xxx:/usr/obj/usr/src/sys/GENERIC amd64 > > igb0: port > 0x3020-0x303f mem > 0xb1d60000-0xb1d7ffff,0xb1d40000-0xb1d5ffff,0xb1e04000-0xb1e07fff irq 37 at > device 0.0 on pci13 > igb0: Using MSIX interrupts with 9 vectors > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: Ethernet address: 00:25:90:36:ee:7c > > The interface is quad port Supermicro branded PCI-E card with > > pciconf -vl > > igb0@pci0:13:0:0: class=0x020000 card=0x10c915d9 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > igb1@pci0:13:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > igb2@pci0:16:0:0: class=0x020000 card=0x10c915d9 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > igb3@pci0:16:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > > Has anyone experience something like this? Is there solution? It is very > inconvenient to have to down/up the interfaces manually via the IPMI > console when such thing happens. > > Ya, don't unplug the cable .... :) Just a bit of holiday humor.... will look into the issue after the long weekend. Jack From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 01:29:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418BE1065670 for ; Sat, 26 Nov 2011 01:29:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id F28D68FC13 for ; Sat, 26 Nov 2011 01:29:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EANZA0E6DaFvO/2dsb2JhbABEhQOnAoFyAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdkCKRjkTCBMIgcgRYEiCGKCYIgkik X-IronPort-AV: E=Sophos;i="4.69,575,1315195200"; d="scan'208";a="145662711" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 25 Nov 2011 20:29:53 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E79A7B3F86; Fri, 25 Nov 2011 20:29:53 -0500 (EST) Date: Fri, 25 Nov 2011 20:29:53 -0500 (EST) From: Rick Macklem To: George Mitchell Message-ID: <1629066195.410848.1322270993899.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4ECFD8D2.4030604@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 01:29:55 -0000 George Mitchell wrote: > On 11/24/11 21:00, Jeremy Chadwick wrote: > >[...] > > If none of this solves the problem, then I consider this a priority > > 0 > > blocker (read: "all hands on deck") issue with the IP stack in > > FreeBSD > > 9.x and will need immediate attention. > > > > I would strongly recommend a developer or clueful end-user begin > > tracking down who committed all of these bits and CC them into the > > thread. I would start by looking who implemented the > > net.inet.tcp.reass.cursegments sysctl, because that isn't in > > RELENG_8 at > > all. > > > > I've tried out the 9.0 release candidates, and what I notice is that > for > a few minutes after the system starts, I get wonderful NFS read > throughput (7+ MB/s over a 100 megabit interface) -- more than twice > as > fast as 7.n or 8.n on the same hardware -- quickly degrading to > abysmal > (less than 0.5 MB/s). Is this possibly related to the problem under > discussion? -- George Mitchell > Well, when I've seen NFS perf. degrade like this, it has usually been related to RPC transport (and TCP is the default for 9.0). Just from reading some of the thread, it sounds like this problem will result in the FAIL count (the last #) for "vmstat -z" for tcpreass will increase and/or net.inet.tcp.reass.cursegments increases to net.inet.tcp.reass.maxsegments. I'd suggest that, after the NFS perf has degrades, you: # vmstat -z | fgrep tcpreass - and see how big the last # is # sysctl -a | fgrep reass - and see how cursegments compares with maxsegments If these don't indicate that is the TCP Reassembly Issue, then... There are many other possibilities w.r.t. the NFS perf. degradation. Most often I've seen it when the net interface hardware/device driver starts dropping packets (like happens on this laptop with an el-cheapo re net interface in it). You can capture a packet trace after the performance has degraded with tcpdump and look to see if TCP segments are being lost/retransmitted. (Although wireshark knows NFS and is nice for this, because it shows relative sequence numbers, the TCP dump will show you the TCP level retries, etc.) Good luck with it, rick > P.S. A lot of other 9.0 features look very nice indeed! > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 01:47:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC58D1065677 for ; Sat, 26 Nov 2011 01:47:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 756128FC13 for ; Sat, 26 Nov 2011 01:47:14 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id 1dbL1i0011wpRvQ54dnEmc; Sat, 26 Nov 2011 01:47:14 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.westchester.pa.mail.comcast.net with comcast id 1dnD1i00M1t3BNj3ednEZu; Sat, 26 Nov 2011 01:47:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 858BE102C19; Fri, 25 Nov 2011 17:47:12 -0800 (PST) Date: Fri, 25 Nov 2011 17:47:12 -0800 From: Jeremy Chadwick To: George Mitchell Message-ID: <20111126014712.GA58776@icarus.home.lan> References: <4ECE9914.6020502@turing.b2n.org> <1A5B3A48-7DF3-4018-A244-152BDE96299A@lassitu.de> <20111125020004.GA36109@icarus.home.lan> <4ECFD8D2.4030604@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ECFD8D2.4030604@m5p.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 01:47:14 -0000 On Fri, Nov 25, 2011 at 01:05:06PM -0500, George Mitchell wrote: > On 11/24/11 21:00, Jeremy Chadwick wrote: > >[...] > >If none of this solves the problem, then I consider this a priority 0 > >blocker (read: "all hands on deck") issue with the IP stack in FreeBSD > >9.x and will need immediate attention. > > > >I would strongly recommend a developer or clueful end-user begin > >tracking down who committed all of these bits and CC them into the > >thread. I would start by looking who implemented the > >net.inet.tcp.reass.cursegments sysctl, because that isn't in RELENG_8 at > >all. > > > > I've tried out the 9.0 release candidates, and what I notice is that for > a few minutes after the system starts, I get wonderful NFS read > throughput (7+ MB/s over a 100 megabit interface) -- more than twice as > fast as 7.n or 8.n on the same hardware -- quickly degrading to abysmal > (less than 0.5 MB/s). Is this possibly related to the problem under > discussion? -- George Mitchell > > P.S. A lot of other 9.0 features look very nice indeed! You could try forcing UDP NFS (assuming this is possible; I would assume on the server side "nfsd -u" is needed and on the client side use of the mntudp option would be needed in /etc/fstab; see mount_nfs(8)) description that others have given indicate the problem being discussed affects purely TCP. Regarding NFS performance in general -- and this is in no way shape or form a slam against Rick -- it would be good to get some actual Linux vs. FreeBSD numbers when it comes to NFS performance, including what protocols are used (TCP vs. UDP) and NFS versions are used (3 vs. 4). I have a gut feeling NFS on Linux is significantly faster, and it would be really helpful to find out how/why. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 05:23:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78DB9106566B; Sat, 26 Nov 2011 05:23:14 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACC28FC08; Sat, 26 Nov 2011 05:23:13 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 7F7D17E84A; Sat, 26 Nov 2011 16:23:11 +1100 (EST) Message-ID: <4ED077BF.10205@freebsd.org> Date: Sat, 26 Nov 2011 16:23:11 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111016 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kris Bauer References: <4ECEF6FD.5050006@freebsd.org> In-Reply-To: <4ECEF6FD.5050006@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: kerbzo@gmail.com, freebsd-stable@freebsd.org, stb@lassitu.de, raul@turing.b2n.org, george+freebsd@m5p.com, FreeBSD Release Engineering Team , freebsd@jdc.parodius.com Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 05:23:14 -0000 On 11/25/11 13:01, Lawrence Stewart wrote: > On 11/24/11 18:02, Kris Bauer wrote: >> Hello, >> >> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 >> where the >> net.inet.tcp.reass.curesegments value is constantly increasing (and not >> descreasing when there is nominal traffic with the box). It is causing >> tcp >> slowdowns as described with kern/155407: >> >> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session >> (for >> this socket and any other socket waiting for retransmited packets). After >> exhausted net.inet.tcp.reass.maxsegments allocation new entry in >> tcp_reass >> failed (for this socket and any other socket waiting for retransmited >> packets). >> >> I have increased the reass.maxsegments value to 16384 to temporarily >> avoid >> the problem, but the cursegments number keeps rising and it seems it will >> occur again. >> >> Is this an issue that anyone else has seen? I can provide more >> information >> if need be. > > Thanks Kris, Raul and Stefan for the reports, I'll look into this. I think I've got it - a stupid 1 line logic bug. My apologies for missing it when I reviewed the patch which introduced the bug (patch was committed to head as r226113, MFCed to stable/9 as r226228). Due to some miscommunication, the initial patch was committed to and MFCed from head much later than it should have been in the 9.0 release cycle and instead of being included in the BETAs, didn't make it in until 9.0-RC1 I believe i.e. only RC1 and RC2 should be experiencing the issue. Could those who have reported the bug and are able to recompile their kernel to test a patch please try the following and report back to the list: http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch The patch is against head r227986 but will apply and work correctly for 9.0 as well. Cheers, Lawrence From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 06:49:25 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF9EE106564A; Sat, 26 Nov 2011 06:49:25 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6448FC0C; Sat, 26 Nov 2011 06:49:25 +0000 (UTC) Received: by iakl21 with SMTP id l21so8612013iak.13 for ; Fri, 25 Nov 2011 22:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kI8rp8TF7+VaYUoNPiiRaFtum3aApX1vhCiNi9/CHaI=; b=d6xaxTH1HIzUea7RYxrcbT1aTTHODnwzRRbaYejefw+To/AdMospX1EBDmz3x/g2Tm RYqt/edDAvmM9GssydI7SzrtO423JBgqsJ0Bqmr0DcT9zF3j4k/1AXekhD85zxF6DnbV CjIUHxYzm8nnxpTRVm5sC4nEXqs8xeCs9ROVk= MIME-Version: 1.0 Received: by 10.43.46.1 with SMTP id um1mr16049440icb.18.1322290164750; Fri, 25 Nov 2011 22:49:24 -0800 (PST) Received: by 10.50.34.167 with HTTP; Fri, 25 Nov 2011 22:49:24 -0800 (PST) In-Reply-To: <4ED077BF.10205@freebsd.org> References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> Date: Sat, 26 Nov 2011 00:49:24 -0600 Message-ID: From: Kris Bauer To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kerbzo@gmail.com, freebsd-stable@freebsd.org, stb@lassitu.de, raul@turing.b2n.org, george+freebsd@m5p.com, FreeBSD Release Engineering Team , freebsd@jdc.parodius.com Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 06:49:25 -0000 On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewart wrote: > On 11/25/11 13:01, Lawrence Stewart wrote: > >> On 11/24/11 18:02, Kris Bauer wrote: >> >>> Hello, >>> >>> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 >>> where the >>> net.inet.tcp.reass.curesegments value is constantly increasing (and not >>> descreasing when there is nominal traffic with the box). It is causing >>> tcp >>> slowdowns as described with kern/155407: >>> >>> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session >>> (for >>> this socket and any other socket waiting for retransmited packets). After >>> exhausted net.inet.tcp.reass.maxsegments allocation new entry in >>> tcp_reass >>> failed (for this socket and any other socket waiting for retransmited >>> packets). >>> >>> I have increased the reass.maxsegments value to 16384 to temporarily >>> avoid >>> the problem, but the cursegments number keeps rising and it seems it will >>> occur again. >>> >>> Is this an issue that anyone else has seen? I can provide more >>> information >>> if need be. >>> >> >> Thanks Kris, Raul and Stefan for the reports, I'll look into this. >> > > I think I've got it - a stupid 1 line logic bug. My apologies for missing > it when I reviewed the patch which introduced the bug (patch was committed > to head as r226113, MFCed to stable/9 as r226228). > > Due to some miscommunication, the initial patch was committed to and MFCed > from head much later than it should have been in the 9.0 release cycle and > instead of being included in the BETAs, didn't make it in until 9.0-RC1 I > believe i.e. only RC1 and RC2 should be experiencing the issue. > > Could those who have reported the bug and are able to recompile their > kernel to test a patch please try the following and report back to the list: > > > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch > > The patch is against head r227986 but will apply and work correctly for > 9.0 as well. > > Cheers, > Lawrence > I have patched, recompiled, and rebooted. net.inet.tcp.reass.cursegments is no longer incrementing, and connectivity is holding steady. If anything changes over the next couple of hours, I'll be sure to report it; but all preliminary signs of the problem are gone. Thanks for all the help! Kris From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 07:56:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6420106564A for ; Sat, 26 Nov 2011 07:56:52 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE708FC12 for ; Sat, 26 Nov 2011 07:56:51 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id 1jws1i0011swQuc5FjwsHy; Sat, 26 Nov 2011 07:56:52 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id 1jwp1i0021t3BNj3bjwpWj; Sat, 26 Nov 2011 07:56:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E497C102C19; Fri, 25 Nov 2011 23:56:47 -0800 (PST) Date: Fri, 25 Nov 2011 23:56:47 -0800 From: Jeremy Chadwick To: Kris Bauer Message-ID: <20111126075647.GA33048@icarus.home.lan> References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kerbzo@gmail.com, freebsd-stable@freebsd.org, stb@lassitu.de, raul@turing.b2n.org, Steven Hartland , george+freebsd@m5p.com, FreeBSD Release Engineering Team , Lawrence Stewart Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 07:56:52 -0000 On Sat, Nov 26, 2011 at 12:49:24AM -0600, Kris Bauer wrote: > On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewart wrote: > > > On 11/25/11 13:01, Lawrence Stewart wrote: > > > >> On 11/24/11 18:02, Kris Bauer wrote: > >> > >>> Hello, > >>> > >>> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 > >>> where the > >>> net.inet.tcp.reass.curesegments value is constantly increasing (and not > >>> descreasing when there is nominal traffic with the box). It is causing > >>> tcp > >>> slowdowns as described with kern/155407: > >>> > >>> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session > >>> (for > >>> this socket and any other socket waiting for retransmited packets). After > >>> exhausted net.inet.tcp.reass.maxsegments allocation new entry in > >>> tcp_reass > >>> failed (for this socket and any other socket waiting for retransmited > >>> packets). > >>> > >>> I have increased the reass.maxsegments value to 16384 to temporarily > >>> avoid > >>> the problem, but the cursegments number keeps rising and it seems it will > >>> occur again. > >>> > >>> Is this an issue that anyone else has seen? I can provide more > >>> information > >>> if need be. > >>> > >> > >> Thanks Kris, Raul and Stefan for the reports, I'll look into this. > >> > > > > I think I've got it - a stupid 1 line logic bug. My apologies for missing > > it when I reviewed the patch which introduced the bug (patch was committed > > to head as r226113, MFCed to stable/9 as r226228). > > > > Due to some miscommunication, the initial patch was committed to and MFCed > > from head much later than it should have been in the 9.0 release cycle and > > instead of being included in the BETAs, didn't make it in until 9.0-RC1 I > > believe i.e. only RC1 and RC2 should be experiencing the issue. > > > > Could those who have reported the bug and are able to recompile their > > kernel to test a patch please try the following and report back to the list: > > > > > > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch > > > > The patch is against head r227986 but will apply and work correctly for > > 9.0 as well. > > > > Cheers, > > Lawrence > > > > I have patched, recompiled, and rebooted. net.inet.tcp.reass.cursegments > is no longer incrementing, and connectivity is holding steady. If anything > changes over the next couple of hours, I'll be sure to report it; but all > preliminary signs of the problem are gone. > > Thanks for all the help! Let's not be hasty in concluding everything is fixed. Why I'm a bit on edge about this: I took the time to find the CVS commits that induced this issue in the first place, and it seems there is some history. The commit that caused this problem to begin with was supposedly a fix for a different problem: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_reass.c#rev1.375 A week later, that commit went from HEAD/MAIN into RELENG_9: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_reass.c#rev1.374.2.2 Be sure to read the description of the problem that was being fixed in the first place. I've also CC'd the original problem reporter, Steven Hartland, because we're going to need him to try the above patch from Lawrence to make sure there aren't other problems. Meaning: for all we know, the above fix might work great for Kris but cause problems for Steve. This entire situation leads me to believe very few people are doing quality testing of RELENG_9, yet we're already into 9.0-RC2. Please don't tell me "that's exactly why you should be running RELENG_9!"; that is completely backwards and I refuse to get into a flame war about it, because it's this simple: 90%+ of those running FreeBSD on servers need something that's stable, we can't risk wonkiness (especially of this degree!) on systems taking production traffic. Did no one actually test the change *thoroughly*? Imagine had this lay dormant until 9.0-RELEASE. Lawrence: please don't take my comments personally or to mean "you broke it and caused this mess!" It's meant to read more along the lines of "you committed a fix for something that broke other bits badly, but nobody noticed this, including the original reporter of a different problem? How/why?" You get the idea. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 08:01:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8A22106566B for ; Sat, 26 Nov 2011 08:01:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id AAE658FC0A for ; Sat, 26 Nov 2011 08:01:55 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 1k1n1i00616AWCUA4k1osN; Sat, 26 Nov 2011 08:01:48 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta06.emeryville.ca.mail.comcast.net with comcast id 1k1W1i00H1t3BNj8Sk1Whh; Sat, 26 Nov 2011 08:01:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 61419102C19; Sat, 26 Nov 2011 00:01:53 -0800 (PST) Date: Sat, 26 Nov 2011 00:01:53 -0800 From: Jeremy Chadwick To: Kris Bauer Message-ID: <20111126080153.GA33335@icarus.home.lan> References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> <20111126075647.GA33048@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111126075647.GA33048@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kerbzo@gmail.com, freebsd-stable@freebsd.org, stb@lassitu.de, raul@turing.b2n.org, george+freebsd@m5p.com, Steven Hartland , Lawrence Stewart , FreeBSD Release Engineering Team Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 08:01:55 -0000 On Fri, Nov 25, 2011 at 11:56:47PM -0800, Jeremy Chadwick wrote: > On Sat, Nov 26, 2011 at 12:49:24AM -0600, Kris Bauer wrote: > > On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewart wrote: > > > > > On 11/25/11 13:01, Lawrence Stewart wrote: > > > > > >> On 11/24/11 18:02, Kris Bauer wrote: > > >> > > >>> Hello, > > >>> > > >>> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 > > >>> where the > > >>> net.inet.tcp.reass.curesegments value is constantly increasing (and not > > >>> descreasing when there is nominal traffic with the box). It is causing > > >>> tcp > > >>> slowdowns as described with kern/155407: > > >>> > > >>> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session > > >>> (for > > >>> this socket and any other socket waiting for retransmited packets). After > > >>> exhausted net.inet.tcp.reass.maxsegments allocation new entry in > > >>> tcp_reass > > >>> failed (for this socket and any other socket waiting for retransmited > > >>> packets). > > >>> > > >>> I have increased the reass.maxsegments value to 16384 to temporarily > > >>> avoid > > >>> the problem, but the cursegments number keeps rising and it seems it will > > >>> occur again. > > >>> > > >>> Is this an issue that anyone else has seen? I can provide more > > >>> information > > >>> if need be. > > >>> > > >> > > >> Thanks Kris, Raul and Stefan for the reports, I'll look into this. > > >> > > > > > > I think I've got it - a stupid 1 line logic bug. My apologies for missing > > > it when I reviewed the patch which introduced the bug (patch was committed > > > to head as r226113, MFCed to stable/9 as r226228). > > > > > > Due to some miscommunication, the initial patch was committed to and MFCed > > > from head much later than it should have been in the 9.0 release cycle and > > > instead of being included in the BETAs, didn't make it in until 9.0-RC1 I > > > believe i.e. only RC1 and RC2 should be experiencing the issue. > > > > > > Could those who have reported the bug and are able to recompile their > > > kernel to test a patch please try the following and report back to the list: > > > > > > > > > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch > > > > > > The patch is against head r227986 but will apply and work correctly for > > > 9.0 as well. > > > > > > Cheers, > > > Lawrence > > > > > > > I have patched, recompiled, and rebooted. net.inet.tcp.reass.cursegments > > is no longer incrementing, and connectivity is holding steady. If anything > > changes over the next couple of hours, I'll be sure to report it; but all > > preliminary signs of the problem are gone. > > > > Thanks for all the help! > > Let's not be hasty in concluding everything is fixed. Why I'm a bit on > edge about this: I took the time to find the CVS commits that induced > this issue in the first place, and it seems there is some history. > > The commit that caused this problem to begin with was supposedly a fix > for a different problem: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_reass.c#rev1.375 > > A week later, that commit went from HEAD/MAIN into RELENG_9: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_reass.c#rev1.374.2.2 > > Be sure to read the description of the problem that was being fixed in > the first place. I've also CC'd the original problem reporter, Steven > Hartland, because we're going to need him to try the above patch from > Lawrence to make sure there aren't other problems. Meaning: for all we > know, the above fix might work great for Kris but cause problems for > Steve. > > This entire situation leads me to believe very few people are doing > quality testing of RELENG_9, yet we're already into 9.0-RC2. Please > don't tell me "that's exactly why you should be running RELENG_9!"; that > is completely backwards and I refuse to get into a flame war about it, > because it's this simple: 90%+ of those running FreeBSD on servers need > something that's stable, we can't risk wonkiness (especially of this > degree!) on systems taking production traffic. Did no one actually test > the change *thoroughly*? Imagine had this lay dormant until 9.0-RELEASE. > > Lawrence: please don't take my comments personally or to mean "you broke > it and caused this mess!" It's meant to read more along the lines of > "you committed a fix for something that broke other bits badly, but > nobody noticed this, including the original reporter of a different > problem? How/why?" You get the idea. Re-sending, because the "Tested by" commit line had someone who replaced the "@" character with "-at-", so my mail client assumed the Email address was on my local machine. Sorry about that folks. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 11:29:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14637106566C for ; Sat, 26 Nov 2011 11:29:23 +0000 (UTC) (envelope-from raul@b2n.org) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id BBD0C8FC17 for ; Sat, 26 Nov 2011 11:29:21 +0000 (UTC) Received: from mail1.isdefe.es (localhost [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id E98302BAC7B; Sat, 26 Nov 2011 12:29:01 +0100 (CET) Received: from turing.b2n.org (unknown [172.24.1.14]) by mail1.isdefe.es (Postfix) with ESMTP id D51A92BAC79; Sat, 26 Nov 2011 12:29:01 +0100 (CET) Received: from [10.10.10.15] (ramc-desktop.pinlabs.b2n.org [10.10.10.15]) by turing.b2n.org (Postfix) with ESMTP id EC123A2116; Sat, 26 Nov 2011 12:29:18 +0100 (CET) Message-ID: <4ED0CDC3.50808@b2n.org> Date: Sat, 26 Nov 2011 12:30:11 +0100 From: Raul User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Lawrence Stewart References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> In-Reply-To: <4ED077BF.10205@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: kerbzo@gmail.com, FreeBSD Release Engineering Team , stb@lassitu.de, Kris Bauer , george+freebsd@m5p.com, freebsd-stable@freebsd.org, freebsd@jdc.parodius.com Subject: Re: TCP Reassembly Issues [SOLVED?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 11:29:23 -0000 El 26/11/2011 6:23, Lawrence Stewart escribió: ... > kernel to test a patch please try the following and report back to the > list: > > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch > > > The patch is against head r227986 but will apply and work correctly for > 9.0 as well. Cleanly applied against RELENG_9_0. As my case was not exactly the same as Kris or Stefan I'd wait their feedback but as far I concern, *it works perfect!*. [....] %sysctl kern.version | head -n1 kern.version: FreeBSD 9.0-RC2 #1: Sat Nov 26 10:24:38 CET 2011 %uptime 12:06PM up 1:30, 3 users, load averages: 0,07 0,08 0,10 %vmstat -z | head -n1 ; vmstat -z | grep reass ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP tcpreass: 40, 1680, 58, 1370, 276624, 0, 0 %sysctl net.inet.tcp.reass net.inet.tcp.reass.overflows: 5 net.inet.tcp.reass.cursegments: 17 net.inet.tcp.reass.maxsegments: 1680 %netstat -s -p tcp | grep mem 5 discarded due to memory problems [....] I'll leave the box stressing the tcp stack a couple of days, just in case. Thanks a lot. Regards, Raúl. From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 12:06:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 991D2106564A; Sat, 26 Nov 2011 12:06:55 +0000 (UTC) (envelope-from kristoph.bauer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4551D8FC15; Sat, 26 Nov 2011 12:06:54 +0000 (UTC) Received: by iakl21 with SMTP id l21so9064855iak.13 for ; Sat, 26 Nov 2011 04:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Otvzp0WYneNClz4N7pIw6R0oN5Li+o+vrNTCWlmREAo=; b=HJSjlQZZ57RbsKFYc26fVTI7XmO3RRxf8ij5bsIdbNsPZFANQXn0ig5c/fO4AoyGP3 YSZ8XrQfXUouaOMv9lxrROpJ8VV1Rs0EL7yL2CLb42bf8IWHUQ09Z5tXul6DXgPMyYXa aDuTs7yv1x7NSWnApws+p6TEm+lXxYKlWKHtw= MIME-Version: 1.0 Received: by 10.50.17.168 with SMTP id p8mr1954795igd.20.1322309214068; Sat, 26 Nov 2011 04:06:54 -0800 (PST) Received: by 10.50.34.167 with HTTP; Sat, 26 Nov 2011 04:06:54 -0800 (PST) In-Reply-To: <4ED0CDC3.50808@b2n.org> References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> <4ED0CDC3.50808@b2n.org> Date: Sat, 26 Nov 2011 06:06:54 -0600 Message-ID: From: Kris Bauer To: Raul Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kerbzo@gmail.com, freebsd-stable@freebsd.org, stb@lassitu.de, george+freebsd@m5p.com, FreeBSD Release Engineering Team , Lawrence Stewart , freebsd@jdc.parodius.com Subject: Re: TCP Reassembly Issues [SOLVED?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 12:06:55 -0000 On Sat, Nov 26, 2011 at 5:30 AM, Raul wrote: > El 26/11/2011 6:23, Lawrence Stewart escribi=F3: > > ... > >> kernel to test a patch please try the following and report back to the >> list: >> >> >> http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzonele= ak_10.x.r227986.patch >> >> >> The patch is against head r227986 but will apply and work correctly for >> 9.0 as well. >> > > Cleanly applied against RELENG_9_0. > > As my case was not exactly the same as Kris or Stefan I'd wait their > feedback but as far I concern, *it works perfect!*. > > [....] > %sysctl kern.version | head -n1 > kern.version: FreeBSD 9.0-RC2 #1: Sat Nov 26 10:24:38 CET 2011 > > %uptime > 12:06PM up 1:30, 3 users, load averages: 0,07 0,08 0,10 > > %vmstat -z | head -n1 ; vmstat -z | grep reass > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > tcpreass: 40, 1680, 58, 1370, 276624, 0, 0 > > %sysctl net.inet.tcp.reass > net.inet.tcp.reass.overflows: 5 > net.inet.tcp.reass.cursegments: 17 > net.inet.tcp.reass.maxsegments: 1680 > > %netstat -s -p tcp | grep mem > 5 discarded due to memory problems > [....] > > I'll leave the box stressing the tcp stack a couple of days, just in case= . > > Thanks a lot. > > Regards, > Ra=FAl. > After 5 hours and a few gigs of traffuc, things have been fine: # sysctl net.inet.tcp.reass net.inet.tcp.reass.overflows: 155 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 4116 Kris From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 13:44:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7A82106564A; Sat, 26 Nov 2011 13:44:00 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 8BFF88FC15; Sat, 26 Nov 2011 13:44:00 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 4E29311191D; Sat, 26 Nov 2011 14:43:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: <4ED077BF.10205@freebsd.org> Date: Sat, 26 Nov 2011 14:43:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92483E2B-F878-434A-B291-48AE06A9D9F7@lassitu.de> References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> To: Lawrence Stewart X-Mailer: Apple Mail (2.1251.1) Cc: kerbzo@gmail.com, freebsd-stable@freebsd.org, raul@turing.b2n.org, Kris Bauer , george+freebsd@m5p.com, FreeBSD Release Engineering Team , freebsd@jdc.parodius.com Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 13:44:00 -0000 > I think I've got it - a stupid 1 line logic bug. My apologies for = missing it when I reviewed the patch which introduced the bug (patch was = committed to head as r226113, MFCed to stable/9 as r226228). >=20 > Due to some miscommunication, the initial patch was committed to and = MFCed from head much later than it should have been in the 9.0 release = cycle and instead of being included in the BETAs, didn't make it in = until 9.0-RC1 I believe i.e. only RC1 and RC2 should be experiencing the = issue. >=20 > Could those who have reported the bug and are able to recompile their = kernel to test a patch please try the following and report back to the = list: >=20 > = http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak= _10.x.r227986.patch >=20 > The patch is against head r227986 but will apply and work correctly = for 9.0 as well. I'm a happy camper! Thanks, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 16:17:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CBAD1065670; Sat, 26 Nov 2011 16:17:05 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-3-2-0-2.r20.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 514A88FC12; Sat, 26 Nov 2011 16:17:05 +0000 (UTC) Received: from wonderland.m5p.com (wonderland.m5p.com [IPv6:2001:418:3fd::19]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id pAQGGwMJ090984; Sat, 26 Nov 2011 11:17:03 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <4ED110FA.4060406@m5p.com> Date: Sat, 26 Nov 2011 11:16:58 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111023 Thunderbird/7.0.1 MIME-Version: 1.0 To: Lawrence Stewart , freebsd-stable@freebsd.org References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> In-Reply-To: <4ED077BF.10205@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sat, 26 Nov 2011 11:17:04 -0500 (EST) X-Scanned-By: MIMEDefang 2.72 on IPv6:2001:418:3fd::f7 Cc: Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 16:17:05 -0000 On 11/26/11 00:23, Lawrence Stewart wrote: > [...] > Could those who have reported the bug and are able to recompile their > kernel to test a patch please try the following and report back to the > list: > > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch > [...] Works for me! I'm now getting a sustained throughput of 7.4MB/s, compared to 4.3MB/s on 8.2-STABLE and 3.2MB/s on 7.4-RELEASE, all on the same hardware (HP notebook with re 100Mb/s interface, reading from an 8.2-STABLE server with an alc 1000Mb/s interface, via two gigabit switches). But I'm still bemused that there should have been any TCP reassembly going on. Doesn't that imply that there was packet fragmentation? My network is uniformly 1500 byte MTU. -- George From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 16:30:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46283106566B for ; Sat, 26 Nov 2011 16:30:30 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-3-2-0-2.r20.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id D3F668FC0C for ; Sat, 26 Nov 2011 16:30:29 +0000 (UTC) Received: from wonderland.m5p.com (wonderland.m5p.com [IPv6:2001:418:3fd::19]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id pAQGUNLO091065; Sat, 26 Nov 2011 11:30:28 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <4ED1141F.3010501@m5p.com> Date: Sat, 26 Nov 2011 11:30:23 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111023 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd@jdc.parodius.com References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> <20111126075647.GA33048@icarus.home.lan> In-Reply-To: <20111126075647.GA33048@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sat, 26 Nov 2011 11:30:28 -0500 (EST) X-Scanned-By: MIMEDefang 2.72 on IPv6:2001:418:3fd::f7 Cc: Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 16:30:30 -0000 On 11/26/11 02:56, Jeremy Chadwick wrote: > [...] > This entire situation leads me to believe very few people are doing > quality testing of RELENG_9, yet we're already into 9.0-RC2. Please > don't tell me "that's exactly why you should be running RELENG_9!"; that > is completely backwards and I refuse to get into a flame war about it, > because it's this simple: 90%+ of those running FreeBSD on servers need > something that's stable, we can't risk wonkiness (especially of this > degree!) on systems taking production traffic. Did no one actually test > the change *thoroughly*? Imagine had this lay dormant until 9.0-RELEASE. > [...] PPPP L U U SSSS OOO N N EEEEE P P L U U S O O NN N E PPPP L U U SSS O O N N N EEE P L U U S O O N NN E P LLLLL UUU SSSS OOO N N EEEEE I didn't get a warm, fuzzy feeling about FreeBSD 7 until 7.1, and FreeBSD 8 was worse -- no warm, fuzzy feeling until 8.2. And I am still not sold on SCHED_ULE: Start as many compute-bound programs as there are CPUs, and prepare for poor (to put it kindly) interactive response. That's not everybody's usage pattern, but it seems plausible enough to me to preclude SCHED_ULE as the default scheduler until it is fixed. On the good side, I'm pleased with the new 9.0 boot menu, and I'm very happy that the ahci driver automatically creates symbolic links to the old device names for its disks. I like that I don't have to tab to the "Okay" button in configuration dialogs any more (though I was surprised the first time it happened). But I hope this gets fixed for my flash card reader/writer: ugen0.5: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 umass0:2:0:-1: Attached to scbus2 (probe0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device - 0 outstanding (da0:umass-sim0:0:0:0): removing device entry -- George Mitchell From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 16:57:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3660E106564A; Sat, 26 Nov 2011 16:57:11 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id B805B8FC0C; Sat, 26 Nov 2011 16:57:10 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id C01727E880; Sun, 27 Nov 2011 03:57:08 +1100 (EST) Message-ID: <4ED11A64.90306@freebsd.org> Date: Sun, 27 Nov 2011 03:57:08 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111016 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> <20111126075647.GA33048@icarus.home.lan> In-Reply-To: <20111126075647.GA33048@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: kerbzo@gmail.com, freebsd-stable@freebsd.org, stb@lassitu.de, raul@turing.b2n.org, Steven Hartland , Kris Bauer , george+freebsd@m5p.com, FreeBSD Release Engineering Team Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 16:57:11 -0000 Hi Jeremy, On 11/26/11 18:56, Jeremy Chadwick wrote: > On Sat, Nov 26, 2011 at 12:49:24AM -0600, Kris Bauer wrote: >> On Fri, Nov 25, 2011 at 11:23 PM, Lawrence Stewartwrote: >> >>> On 11/25/11 13:01, Lawrence Stewart wrote: [snip] >>>> Thanks Kris, Raul and Stefan for the reports, I'll look into this. >>>> >>> >>> I think I've got it - a stupid 1 line logic bug. My apologies for missing >>> it when I reviewed the patch which introduced the bug (patch was committed >>> to head as r226113, MFCed to stable/9 as r226228). >>> >>> Due to some miscommunication, the initial patch was committed to and MFCed >>> from head much later than it should have been in the 9.0 release cycle and >>> instead of being included in the BETAs, didn't make it in until 9.0-RC1 I >>> believe i.e. only RC1 and RC2 should be experiencing the issue. >>> >>> Could those who have reported the bug and are able to recompile their >>> kernel to test a patch please try the following and report back to the list: >>> >>> >>> http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch >>> >>> The patch is against head r227986 but will apply and work correctly for >>> 9.0 as well. >>> >>> Cheers, >>> Lawrence >>> >> >> I have patched, recompiled, and rebooted. net.inet.tcp.reass.cursegments >> is no longer incrementing, and connectivity is holding steady. If anything >> changes over the next couple of hours, I'll be sure to report it; but all >> preliminary signs of the problem are gone. >> >> Thanks for all the help! > > Let's not be hasty in concluding everything is fixed. Why I'm a bit on > edge about this: I took the time to find the CVS commits that induced > this issue in the first place, and it seems there is some history. > > The commit that caused this problem to begin with was supposedly a fix > for a different problem: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_reass.c#rev1.375 The original patch you reference (equivalent to svn r226113 as noted in my previous email) was indeed for a separate problem. Unfortunately the fix introduced a new problem. > A week later, that commit went from HEAD/MAIN into RELENG_9: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_reass.c#rev1.374.2.2 > > Be sure to read the description of the problem that was being fixed in > the first place. I've also CC'd the original problem reporter, Steven > Hartland, because we're going to need him to try the above patch from > Lawrence to make sure there aren't other problems. Meaning: for all we > know, the above fix might work great for Kris but cause problems for > Steve. Even though my patch is a multi-line diff, it only effectively changes one thing - that the "te == NULL" condition must be true for both the case where "th->th_seq != tp->rcv_nxt" (current segment does not plug the hole) and where they are equal (current segment does plug the hole; a new case introduced in r226113). I can say with confidence based on the change in the logic that my patch is not a regression as far as Steven's original bug report is concerned. > This entire situation leads me to believe very few people are doing > quality testing of RELENG_9, yet we're already into 9.0-RC2. Please > don't tell me "that's exactly why you should be running RELENG_9!"; that > is completely backwards and I refuse to get into a flame war about it, > because it's this simple: 90%+ of those running FreeBSD on servers need > something that's stable, we can't risk wonkiness (especially of this > degree!) on systems taking production traffic. Did no one actually test > the change *thoroughly*? Imagine had this lay dormant until 9.0-RELEASE. The latter half is fair criticism, more comments below. The fact we're having this discussion now prior to 9.0 being released somewhat negates the assertion in the former part of your paragraph. > Lawrence: please don't take my comments personally or to mean "you broke > it and caused this mess!" It's meant to read more along the lines of All good, not taken personally. > "you committed a fix for something that broke other bits badly, but > nobody noticed this, including the original reporter of a different > problem? How/why?" You get the idea. Your concerns are valid. To clarify, I did not propose or commit the patch which introduced this bug (r226113). Generally speaking, it is a committer's responsibility to ensure that a patch which they commit has been sufficiently tested prior to commit. Normally the committer will solicit testing from the original problem reporter and do some testing themselves. I believe Steven tested Andre's patch and reported to the mailing list that it resolved his immediate problem. I was not privy to any other testing conducted by Andre, so can't comment further on that. As to how this could have been missed: TCP is impressively robust, capable of working even when it has both arms tied behind its back and is missing a leg. It may not work well, but will limp along all the same. People tend to notice and report scenarios where something is definitively broken far more readily than the more complicated case where it degrades to an unreasonable but still working state after a non-deterministic amount of time. Even if basic testing had been performed, it would be fairly easy to miss the effects of this bug, which only manifest after a relatively long time, except for those on the receiving end of large bandwidth-delay product, non-zero-loss TCP connections which would exacerbate the issue quicker. My involvement in all this was that I introduced the original bug r226113 was designed to solve, and reviewed a pre-cursor to, but did not test the r226113 patch. Hope I've provided some useful insight. Cheers, Lawrence From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 17:17:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7852106566C for ; Sat, 26 Nov 2011 17:17:08 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3E98FC16 for ; Sat, 26 Nov 2011 17:17:08 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 96C3E7E8C5; Sun, 27 Nov 2011 04:17:07 +1100 (EST) Message-ID: <4ED11F13.8090501@freebsd.org> Date: Sun, 27 Nov 2011 04:17:07 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111016 Thunderbird/7.0.1 MIME-Version: 1.0 To: George Mitchell References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> <4ED110FA.4060406@m5p.com> In-Reply-To: <4ED110FA.4060406@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 17:17:08 -0000 Hi George, On 11/27/11 03:16, George Mitchell wrote: > On 11/26/11 00:23, Lawrence Stewart wrote: >> [...] >> Could those who have reported the bug and are able to recompile their >> kernel to test a patch please try the following and report back to the >> list: >> >> http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch >> >> [...] > Works for me! I'm now getting a sustained throughput of 7.4MB/s, > compared to 4.3MB/s on 8.2-STABLE and 3.2MB/s on 7.4-RELEASE, all on > the same hardware (HP notebook with re 100Mb/s interface, reading from > an 8.2-STABLE server with an alc 1000Mb/s interface, via two gigabit > switches). Good stuff. > But I'm still bemused that there should have been any TCP reassembly > going on. Doesn't that imply that there was packet fragmentation? My > network is uniformly 1500 byte MTU. -- George TCP reassembly refers to queuing packets received out of order until the missing segment is received i.e. not IP layer fragmentation related, but packet loss or packet reordering related. I guess something in your setup is dropping the odd packet which is why your NFS performance isn't closer to the 10+MB/s (I'm not sure how much overhead NFS adds, but ~12MB/s is max application-layer throughput of 100Mbps Ethernet so achievable NFS throughput should be a bit less than that) it could be if everything was peachy. siftr(4) and some tcpdumping on both client/server could probably help you figure out where you're dropping packets if you want to improve your current performance even further. Cheers, Lawrence From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 21:06:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD1E106566B for ; Sat, 26 Nov 2011 21:06:03 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [IPv6:2604:e700:b0:1::200]) by mx1.freebsd.org (Postfix) with ESMTP id 63EA28FC08 for ; Sat, 26 Nov 2011 21:06:03 +0000 (UTC) Received: from magnum.bit0.com (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id B7F6D16985 for ; Sat, 26 Nov 2011 16:06:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=bit0.com; h=message-id :date:from:mime-version:to:subject:content-type; s=boogity; bh=8 Edrs3Ko8VXh+ZqdumdGpK51cccpHUM2g6CYQ9UuRKc=; b=M6UA6GGYorGhTzXG4 PeS9nQOWxtKAaSvzT6N5jLKUgnNrqJyRmS3K5bsYOfsF7xMd+sx4hGE+Ckaqpwvr GV849n6D1red1r6KvDlpyOQI0lokmds6XxCwG3WYqNiwaZ7ftsNBvA0j21ngPjwz KIZ37Xzk2kR2+MYhTaYPyqDuXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bit0.com; h=message-id:date :from:mime-version:to:subject:content-type; q=dns; s=boogity; b= VvofLF4+dmtfSbH5omzqZ2QNsXeTWeWVKqXounh+pnymcZYJsl3rPqLFj3NdHhD2 COxhwCUIVa57S1vJvbz1LKb+lTHZbbm9lf+VlTu9Dhsznjvonxiq/QOBcKOxNDnf S4Hi3f6Dlhx7BeTnPzgaHEBEZZ6zAPA5ff0Q8fnHQHI= Received: from millenniumforce.int.bit0.com (207-246-87-56.dsl.static.blueone.net [207.246.87.56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id 9138D16984 for ; Sat, 26 Nov 2011 16:06:02 -0500 (EST) Message-ID: <4ED154B6.2030304@bit0.com> Date: Sat, 26 Nov 2011 16:05:58 -0500 From: Mike Andrews User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 9.0-RC2 re(4) "no memory for jumbo buffers" issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 21:06:04 -0000 I have a Supermicro 5015A-H (Intel Atom 330) server with two Realtek RTL8111C-GR gigabit NICs on it. As far as I can tell, these support jumbo frames up to 7422 bytes. When running them at an MTU of 5000 on FreeBSD 9.0-RC2, after a week or so of update, with fairly light network activity, the interfaces die with "no memory for jumbo buffers" errors on the console. Unloading and reloading the driver (via serial console) doesn't help; only rebooting seems to clear it up. I don't have this issue with any of my em(4) based systems that are also using a 5000 byte MTU -- and they push considerably more traffic. I don't really consider this a regression from FreeBSD 8.2 because 8.2 didn't support jumbos at all on this hardware... :) What's the best way to go about debugging this... which sysctl's should I be looking at first? I have already tried raising kern.ipc.nmbjumbo9 to 16384 and it doesn't seem to help things... maybe prolonging it slightly, but not by much. The problem is it takes a week or so to reproduce the problem each time... From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 21:07:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6BFA1065670 for ; Sat, 26 Nov 2011 21:07:18 +0000 (UTC) (envelope-from kerbzo@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 74DC58FC15 for ; Sat, 26 Nov 2011 21:07:18 +0000 (UTC) Received: by iakl21 with SMTP id l21so9830869iak.13 for ; Sat, 26 Nov 2011 13:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vpb0fRtD+/1Gj0DrfQyvea9gaje3kbjwYk9DYuzPAAs=; b=DGZ9gaO+eAdYZG0A1Z/RNC9efCSCPm4OFcrvXEvqdg0ln5ueNh3DEf4X3og/fL1Fmw aEGJm+bl0oltSLCGtnyyjkEAYNPzzhwcWUvERJxxjWxInMQR9WprASlS+Ma3MCcyzE2o bT4W2ICqM81Kg6qgFwToSv25YGBSDzzMly7Xo= MIME-Version: 1.0 Received: by 10.50.10.163 with SMTP id j3mr36499510igb.15.1322341637986; Sat, 26 Nov 2011 13:07:17 -0800 (PST) Received: by 10.231.34.68 with HTTP; Sat, 26 Nov 2011 13:07:17 -0800 (PST) In-Reply-To: <4ED077BF.10205@freebsd.org> References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> Date: Sat, 26 Nov 2011 22:07:17 +0100 Message-ID: From: kerbzo To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, stb@lassitu.de, raul@turing.b2n.org, Kris Bauer , george+freebsd@m5p.com, FreeBSD Release Engineering Team , freebsd@jdc.parodius.com Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 21:07:18 -0000 Hi, this patch works for me, also. Reass counter now does not increase ( tcpreass: 40, 1680, 21, 399, 572562, 0, 0 ) and a severe network performance issue of netatalk and afpd, used as a "Time Capsule" server for mac os x, seems now disappeared. Really thank you, best regards, On Sat, Nov 26, 2011 at 6:23 AM, Lawrence Stewart wrote: > On 11/25/11 13:01, Lawrence Stewart wrote: >> >> On 11/24/11 18:02, Kris Bauer wrote: >>> >>> Hello, >>> >>> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 >>> where the >>> net.inet.tcp.reass.curesegments value is constantly increasing (and not >>> descreasing when there is nominal traffic with the box). It is causing >>> tcp >>> slowdowns as described with kern/155407: >>> >>> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session >>> (for >>> this socket and any other socket waiting for retransmited packets). After >>> exhausted net.inet.tcp.reass.maxsegments allocation new entry in >>> tcp_reass >>> failed (for this socket and any other socket waiting for retransmited >>> packets). >>> >>> I have increased the reass.maxsegments value to 16384 to temporarily >>> avoid >>> the problem, but the cursegments number keeps rising and it seems it will >>> occur again. >>> >>> Is this an issue that anyone else has seen? I can provide more >>> information >>> if need be. >> >> Thanks Kris, Raul and Stefan for the reports, I'll look into this. > > I think I've got it - a stupid 1 line logic bug. My apologies for missing it > when I reviewed the patch which introduced the bug (patch was committed to > head as r226113, MFCed to stable/9 as r226228). > > Due to some miscommunication, the initial patch was committed to and MFCed > from head much later than it should have been in the 9.0 release cycle and > instead of being included in the BETAs, didn't make it in until 9.0-RC1 I > believe i.e. only RC1 and RC2 should be experiencing the issue. > > Could those who have reported the bug and are able to recompile their kernel > to test a patch please try the following and report back to the list: > > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch > > The patch is against head r227986 but will apply and work correctly for 9.0 > as well. > > Cheers, > Lawrence > From owner-freebsd-stable@FreeBSD.ORG Sat Nov 26 23:56:25 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BDD6106566C for ; Sat, 26 Nov 2011 23:56:25 +0000 (UTC) (envelope-from stylinae@mail.uc.edu) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by mx1.freebsd.org (Postfix) with ESMTP id 5926C8FC0C for ; Sat, 26 Nov 2011 23:56:24 +0000 (UTC) Received: from mail104-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.22; Sat, 26 Nov 2011 23:40:36 +0000 Received: from mail104-db3 (localhost [127.0.0.1]) by mail104-db3-R.bigfish.com (Postfix) with ESMTP id 60CDA3200AC for ; Sat, 26 Nov 2011 23:40:14 +0000 (UTC) X-SpamScore: 0 X-BigFish: PS0(zzzz1202hzz8275bhz2dh2a8h668h839h8e2h8e3h34h) X-Forefront-Antispam-Report: CIP:207.46.198.81; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0102HT016.prod.exchangelabs.com; RD:none; EFVD:NLI Received: from mail104-db3 (localhost.localdomain [127.0.0.1]) by mail104-db3 (MessageSwitch) id 1322350814298007_4037; Sat, 26 Nov 2011 23:40:14 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.252]) by mail104-db3.bigfish.com (Postfix) with ESMTP id 3A3DB6E0042 for ; Sat, 26 Nov 2011 23:40:14 +0000 (UTC) Received: from CH1PRD0102HT016.prod.exchangelabs.com (207.46.198.81) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 26 Nov 2011 23:40:36 +0000 Received: from freebsdbox.adamsnet (72.49.234.31) by pod51000.outlook.com (10.42.118.39) with Microsoft SMTP Server (TLS) id 14.15.9.3; Sat, 26 Nov 2011 23:41:18 +0000 Date: Sat, 26 Nov 2011 18:41:17 -0500 From: Adam Stylinski To: Message-ID: <20111126234117.GA1821@freebsdbox.adamsnet> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [72.49.234.31] X-OriginatorOrg: mail.uc.edu Subject: ataraid and 9.0 RC-2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 23:56:25 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I just ran freebsd-update to get up to 9.0-RC2 and discovered that ataraid = does not work. I realize I'm an edge case and my scenario is not ideal (I = use an ITE controller and performance is actually impressively slow), but I= cannot boot 9.0 from my stripe, even after manually loading ataraid from t= he loader prompt (after running an unload command). I mention it mostly be= cause other people using the fakeraid setup by their motherboards for whate= ver reason (perhaps to share a partition table with windows on the same mir= ror or stripe) may have a similar problem. It seems like the ar0 device di= sappeared for me completely (even though it finds ada0 and ada1). I'm usin= g the following device: atapci0@pci0:2:11:0: class=3D0x010400 card=3D0x00000000 chip=3D0x8212128= 3 rev=3D0x13 hdr=3D0x00 vendor =3D 'Integrated Technology Express (ITE) Inc' device =3D 'ATA 133 IDE RAID Controller (IT8212F)' class =3D mass storage subclass =3D RAID rl0@pci0:2:13:0: class=3D0x020000 card=3D0x80ea104d chip=3D0x813910e= c rev=3D0x10 hdr=3D0x00 At first I figured because it may be loading AHCI (as per the device naming= schemes ada0 and ada1). I haven't looked too much into it (these devices = are actually PATA not SATA, so AHCI doesn't even exist for these), but mayb= e there's an ATA/AHCI driver that's built into the default kernelthat is in= terfering with ataraid.ko? Maybe this interferes with my stupidly slow and= unpopular configuration. =20 Thanks for any help, I'll also have a gander at the new DEFAULTS for the ge= neric kernel in the 9.0 source tree. --=20 Adam Stylinski PGP Key: http://pohl.ececs.uc.edu/~adam/publickey.pub Blog: http://technicallyliving.blogspot.com --zhXaljGHf11kAtnf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJO0XkbAAoJED6sRHE6Tvmn8YUP/07qNFr9jvu+ZiABQZnkcZ7+ PzZbeX0X168mmXkCI1bBcHkWcmi811pL2Ao+sbZ3LjJqUrvHXq3E8isHNWTDjUtV eZPZlXVnV3YP+zL85fJrYVc+RqhFrks083y5Iy0So9ieGhicLfqTEhH6C9SnaIOR bZL8qVqDossKYJDcR+9yv17oELKDmmTuulxIe+RouT7q/IS0BzufRmdbkUvKbbuZ 39lijmGWgkz7uUq7nFDhTf/9d5z2mIkdFlHVPuIx8cP8eTBDsyXilHyXnjmS/qO+ rQpe8JBdNdoOxPONa819LpM4lsuLf3Lw24dj+9jhPVGwIDEGeEMyfoHzds8P5spS FxagVFSy73A9YqMna33l1CWAmyUOzeqsSEhR5gJ6R01AQEXgbmO3d4iesJ8FzVaB gh+/zF/kfdUjo1Fcj658i1iNbG+aQjmHgtodP7YkP/hNRzegye28+huT498k08sc 3u01rh3LoTuxTx9IQ6Kv+s8rpcRpBLpfZ6Ad44CEKZVK7PNRnoC18NjCbIbuJ6VU ri6TSIHKQmWHHPEYPcsMJDWxGY3Q8rxYUvaBdgoJQclUy5xP6Nl3AB810rDhSV0F oP5gvK5FJXhfqas9z5v0SPQTnbrvrgrqmVCjwno5EIhGFQfns4EDpk6D3q2k7S4C 9daAPuXqlQIRoeGsJKQT =r26D -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--