From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 00:30:37 2010 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 5D05A1065675 for ; Sun, 29 Aug 2010 00:30:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 481E18FC14 for ; Sun, 29 Aug 2010 00:30:36 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 00JH1f0051smiN4A50WcQo; Sun, 29 Aug 2010 00:30:36 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta20.emeryville.ca.mail.comcast.net with comcast id 00Wb1f00R3LrwQ28g0WcAL; Sun, 29 Aug 2010 00:30:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B6DE19B425; Sat, 28 Aug 2010 17:30:35 -0700 (PDT) Date: Sat, 28 Aug 2010 17:30:35 -0700 From: Jeremy Chadwick To: Dan Langille Message-ID: <20100829003035.GA81036@icarus.home.lan> References: <4C79732E.2010606@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C79732E.2010606@langille.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ACPI Warning: Optional field Pm2ControlBlock has zero address 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, 29 Aug 2010 00:30:37 -0000 On Sat, Aug 28, 2010 at 04:35:58PM -0400, Dan Langille wrote: > This this something to be concerned about: > > ACPI Warning: Optional field Pm2ControlBlock has zero address or > length: 0x0000000000000000/0x1 (20100331/tbfadt-655) CC'ing freebsd-acpi. OS version is unknown. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 00:35:20 2010 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 2105110656A8 for ; Sun, 29 Aug 2010 00:35:20 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id EA9058FC19 for ; Sun, 29 Aug 2010 00:35:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 41D8250BA0; Sun, 29 Aug 2010 01:35:19 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8loh+wnPrEB; Sun, 29 Aug 2010 01:35:18 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 440FD50B9A ; Sun, 29 Aug 2010 01:35:18 +0100 (BST) Message-ID: <4C79AB43.7010603@langille.org> Date: Sat, 28 Aug 2010 20:35:15 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C79732E.2010606@langille.org> <20100829003035.GA81036@icarus.home.lan> In-Reply-To: <20100829003035.GA81036@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ACPI Warning: Optional field Pm2ControlBlock has zero address 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, 29 Aug 2010 00:35:20 -0000 On 8/28/2010 8:30 PM, Jeremy Chadwick wrote: > On Sat, Aug 28, 2010 at 04:35:58PM -0400, Dan Langille wrote: >> This this something to be concerned about: >> >> ACPI Warning: Optional field Pm2ControlBlock has zero address or >> length: 0x0000000000000000/0x1 (20100331/tbfadt-655) > > CC'ing freebsd-acpi. OS version is unknown. FreeBSD-Stable 8.1 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 03:49:34 2010 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 6E3C010656A7 for ; Sun, 29 Aug 2010 03:49:34 +0000 (UTC) (envelope-from rick@rix.kiwi-computer.com) Received: from rix.kiwi-computer.com (66-191-70-202.static.stcd.mn.charter.com [66.191.70.202]) by mx1.freebsd.org (Postfix) with SMTP id E2FFC8FC0A for ; Sun, 29 Aug 2010 03:49:33 +0000 (UTC) Received: (qmail 81785 invoked by uid 2000); 29 Aug 2010 03:22:52 -0000 Date: Sat, 28 Aug 2010 22:22:52 -0500 From: "Rick C. Petty" To: Rick Macklem Message-ID: <20100829032252.GA81736@rix.kiwi-computer.com> References: <20100627221607.GA31646@kay.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 03:49:34 -0000 Hi. I'm still having problems with NFSv4 being very laggy on one client. When the NFSv4 server is at 50% idle CPU and the disks are < 1% busy, I am getting horrible throughput on an idle client. Using dd(1) with 1 MB block size, when I try to read a > 100 MB file from the client, I'm getting around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s with the same test (on a different file). On the broken client: # uname -mv FreeBSD 8.1-STABLE #5 r211534M: Sat Aug 28 15:53:10 CDT 2010 user@example.com:/usr/obj/usr/src/sys/GENERIC i386 # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:e0:4c:xx:yy:zz inet xx.yy.zz.3 netmask 0xffffff00 broadcast xx.yy.zz.255 media: Ethernet autoselect (1000baseT ) status: active # netstat -m 267/768/1035 mbufs in use (current/cache/total) 263/389/652/25600 mbuf clusters in use (current/cache/total/max) 263/377 mbuf+clusters out of packet secondary zone in use (current/cache) 0/20/20/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 592K/1050K/1642K 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/5/6656 sfbufs in use (current/peak/max) 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 -idn Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop re0 1500 00:e0:4c:xx:yy:zz 232135 0 0 68984 0 0 0 re0 1500 xx.yy.zz.0/2 xx.yy.zz.3 232127 - - 68979 - - - nfe0* 1500 00:22:15:xx:yy:zz 0 0 0 0 0 0 0 plip0 1500 0 0 0 0 0 0 0 lo0 16384 42 0 0 42 0 0 0 lo0 16384 fe80:4::1/64 fe80:4::1 0 - - 0 - - - lo0 16384 ::1/128 ::1 0 - - 0 - - - lo0 16384 127.0.0.0/8 127.0.0.1 42 - - 42 - - - # sysctl kern.ipc.maxsockbuf kern.ipc.maxsockbuf: 1048576 # sysctl net.inet.tcp.sendbuf_max net.inet.tcp.sendbuf_max: 16777216 # sysctl net.inet.tcp.recvbuf_max net.inet.tcp.recvbuf_max: 16777216 # sysctl net.inet.tcp.sendspace net.inet.tcp.sendspace: 65536 # sysctl net.inet.tcp.recvspace net.inet.tcp.recvspace: 131072 # sysctl hw.pci | grep msi hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 # vmstat -i interrupt total rate irq14: ata0 47 0 irq16: re0 219278 191 irq21: ohci0+ 5939 5 irq22: vgapci0+ 77990 67 cpu0: timer 2294451 1998 irq256: hdac0 44069 38 cpu1: timer 2293983 1998 Total 4935757 4299 Any ideas? -- Rick C. Petty From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 09:24:57 2010 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 384921065693 for ; Sun, 29 Aug 2010 09:24:57 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 809288FC16 for ; Sun, 29 Aug 2010 09:24:56 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA17169 for ; Sun, 29 Aug 2010 12:24:54 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ope8D-000AtR-Sa for freebsd-stable@FreeBSD.org; Sun, 29 Aug 2010 12:24:54 +0300 Message-ID: <4C7A2764.3050608@freebsd.org> Date: Sun, 29 Aug 2010 12:24:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> In-Reply-To: <4C7835E6.6070309@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: patch for topology detection of Intel CPUs 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, 29 Aug 2010 09:24:57 -0000 [Reposted from stable@; edited] The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff The patch is substantially based on the Junk-uk's patch, but with some changes and additions: - topo_prob_0x4() is rewritten so that it does APIC ID matching against masks as described in the Intel article. The code still heavily depends on the assumption of the uniform topology, it discovers number of cores in BSP package and number of threads in BSP core and extrapolates that to global topology. The difference with current code and Junk-uk's patch is that actual APIC ID matching is done as opposed to deriving counts purely from max. values. - topo_prob_0x4() is invoked for 1 <= cpu_high < 4 case as well as for 4 <= cpu_high < 11 case as done in the current code, but unlike Junk-uk's patch. The code should be able to properly handle that class of CPUs and either detect hyperthreading topology or fallback to one processor per package topology. - added a few comments that describe uniformity assumption, plus couple other useful things. - changed "final fallback" code, so that each logical CPU is considered to be in its own physical package as opposed to current code placing all logical CPUs as cores of a single package. The rest is Junk-uk's work. Concerns: - about my code: ilog2_round_pow2 name is ugly; looking for suggestions on a better name or re-arranging/writing that code, so that the function is not needed. - about current code: logical_cpus variable (don't confuse with cpu_logical) doesn't seem to be consistently used; e.g. it is not set at all by topo_probo_0xb(); also, the method of using it for setting logical_cpus_mask doesn't seem to be reliable - BSP may be missed. Reviews, comments and test reports are very welcome! Please test the patch if you have any problems with how CPU topology is reported by the current code. Please test even if everything is OK, to avoid regressions. Thanks! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 14:09:39 2010 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 33BF01065670; Sun, 29 Aug 2010 14:09:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id E853E8FC17; Sun, 29 Aug 2010 14:09:38 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7TE9Q9W021201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2010 10:09:26 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7TE9QCJ082862; Sun, 29 Aug 2010 10:09:26 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008291409.o7TE9QCJ082862@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Aug 2010 10:09:20 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: andre@freebsd.org Subject: syncache errors 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, 29 Aug 2010 14:09:39 -0000 After upgrading to a recent STABLE, I have been seeing the following sporadic errors Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: Socket create failed due to limits or memory shortage this is with FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 and the previous kernel was from July 20th. The odd thing is that the error is triggered from a RELENG_6 host only it would seem. I noticed there are a number of syncache and tcp updates to RELENG_8, is it possible this is related ? I dont have any specific tweaks in /etc/sysctl.conf other than net.inet.tcp.log_in_vain: 1 net.inet.udp.log_in_vain: 1 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 15:44:08 2010 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 207DC1065670 for ; Sun, 29 Aug 2010 15:44:08 +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 D4E358FC21 for ; Sun, 29 Aug 2010 15:44:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKccekyDaFvO/2dsb2JhbACDFpAOjhenfJB5gSKBU4FPcwSKCQ X-IronPort-AV: E=Sophos;i="4.56,287,1280721600"; d="scan'208";a="90068270" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Aug 2010 11:44:03 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 743FEB3E95; Sun, 29 Aug 2010 11:44:06 -0400 (EDT) Date: Sun, 29 Aug 2010 11:44:06 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <2002105637.244211.1283096646412.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100829032252.GA81736@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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, 29 Aug 2010 15:44:08 -0000 > Hi. I'm still having problems with NFSv4 being very laggy on one > client. > When the NFSv4 server is at 50% idle CPU and the disks are < 1% busy, > I am > getting horrible throughput on an idle client. Using dd(1) with 1 MB > block > size, when I try to read a > 100 MB file from the client, I'm getting > around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s > with > the same test (on a different file). On the broken client: > Since other client(s) are working well, that seems to suggest that it is a network related problem and not a bug in the NFS code. First off, the obvious question: How does this client differ from the one that performs much better? Do they both use the same "re" network interface for the NFS traffic? (If the answer is "no", I'd be suspicious that the "re" hardware or device driver is the culprit.) Things that I might try in an effort to isolate the problem: - switch the NFS traffic to use the nfe0 net interface. - put a net interface identical to the one on the client that works well in the machine and use that for the NFS traffic. - turn off TXCSUM and RXCSUM on re0 - reduce the read/write data size, using rsize=N,wsize=N on the mount. (It will default to MAXBSIZE and some net interfaces don't handle large bursts of received data well. If you drop it to rsize=8192,wszie=8192 and things improve, then increase N until it screws up.) - check the port configuration on the switch end, to make sure it is also 1000bps-full duplex. - move the client to a different net port on the switch or even a different switch (and change the cable, while you're at it). - Look at "netstat -s" and see if there are a lot of retransmits going on in TCP. If none of the above seems to help, you could look at a packet trace and see what is going on. Look for TCP reconnects (SYN, SYN-ACK...) or places where there is a large time delay/retransmit of a TCP segment. Hopefully others who are more familiar with the networking side can suggest other things to try, rick From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 16:00:23 2010 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 64F331065674 for ; Sun, 29 Aug 2010 16:00:23 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CD5218FC0C for ; Sun, 29 Aug 2010 16:00:22 +0000 (UTC) Received: (qmail 43803 invoked from network); 29 Aug 2010 15:31:39 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Aug 2010 15:31:39 -0000 Message-ID: <4C7A7DD4.9020803@freebsd.org> Date: Sun, 29 Aug 2010 17:33:40 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mike Tancsa References: <201008291409.o7TE9QCJ082862@lava.sentex.ca> In-Reply-To: <201008291409.o7TE9QCJ082862@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: syncache errors 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, 29 Aug 2010 16:00:23 -0000 On 29.08.2010 16:09, Mike Tancsa wrote: > After upgrading to a recent STABLE, I have been seeing the following sporadic errors > > Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: > Socket create failed due to limits or memory shortage > > this is with > FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 > and the previous kernel was from July 20th. > > The odd thing is that the error is triggered from a RELENG_6 host only it would seem. I noticed > there are a number of syncache and tcp updates to RELENG_8, is it possible this is related ? I dont > have any specific tweaks in /etc/sysctl.conf > > other than > net.inet.tcp.log_in_vain: 1 > net.inet.udp.log_in_vain: 1 The log_in_vain sysctl would cause the logging of syncache errors as well (net.inet.tcp.log_debug). This was a POLA violation and I've separated them on August 27 on 8-stable. So if you update you won't see them anymore. That doesn't change the fact that the socket create failed though. If it only happens from a RELENG_6 box it probably is a problem with port re-usage by RELENG_6. The difficulty is that sonewconn() fails and doesn't return an error code. Hence it may be one of listen queue limits reached, memory shortage or a problem with inserting the inpcb into the hash lists. -- Andre From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 17:17:08 2010 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 A8F4F10656A3; Sun, 29 Aug 2010 17:17:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 668808FC1A; Sun, 29 Aug 2010 17:17:08 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7THH0Cq027618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2010 13:17:00 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7THGxcF083744; Sun, 29 Aug 2010 13:16:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008291716.o7THGxcF083744@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Aug 2010 13:16:54 -0400 To: Andre Oppermann From: Mike Tancsa In-Reply-To: <4C7A7DD4.9020803@freebsd.org> References: <201008291409.o7TE9QCJ082862@lava.sentex.ca> <4C7A7DD4.9020803@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: freebsd-stable@freebsd.org Subject: Re: syncache errors 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, 29 Aug 2010 17:17:08 -0000 At 11:33 AM 8/29/2010, Andre Oppermann wrote: >On 29.08.2010 16:09, Mike Tancsa wrote: >>After upgrading to a recent STABLE, I have been seeing the >>following sporadic errors >> >>Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to >>[xx.yy.164.50]:25; syncache_socket: >>Socket create failed due to limits or memory shortage >> >>this is with >>FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 >>and the previous kernel was from July 20th. >> >>The odd thing is that the error is triggered from a RELENG_6 host >>only it would seem. I noticed >>there are a number of syncache and tcp updates to RELENG_8, is it >>possible this is related ? I dont >>have any specific tweaks in /etc/sysctl.conf >> >>other than >>net.inet.tcp.log_in_vain: 1 >>net.inet.udp.log_in_vain: 1 > >The log_in_vain sysctl would cause the logging of syncache errors >as well (net.inet.tcp.log_debug). This was a POLA violation and >I've separated them on August 27 on 8-stable. So if you update >you won't see them anymore. That doesn't change the fact that >the socket create failed though. > >If it only happens from a RELENG_6 box it probably is a problem >with port re-usage by RELENG_6. The difficulty is that sonewconn() >fails and doesn't return an error code. Hence it may be one of >listen queue limits reached, memory shortage or a problem with >inserting the inpcb into the hash lists. Actually, I think I might have found the issue. I was focusing on the "memory" part not the limits. The 'RELENG_6 only' is just a fluke as thats a box that sends a lot of email to this particular server. It turns out, sendmail was rate limiting the server sm-mta[25923]: deferring connections on daemon IPv4: 8 per second and somehow syncache is aware/logs this now where as it did not before ? ---Mike >-- >Andre -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 18:32:37 2010 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 1539B1065696 for ; Sun, 29 Aug 2010 18:32:37 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5DF8FC14 for ; Sun, 29 Aug 2010 18:32:36 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id o7TIGxkN035648 for ; Sun, 29 Aug 2010 20:16:59 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id o7TIGxYQ035647 for freebsd-stable@freebsd.org; Sun, 29 Aug 2010 20:16:59 +0200 (CEST) (envelope-from byshenknet) Date: Sun, 29 Aug 2010 20:16:59 +0200 From: Greg Byshenk To: freebsd-stable@freebsd.org Message-ID: <20100829181659.GB12467@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Subject: igb related(?) panics on 7.3-STABLE 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, 29 Aug 2010 18:32:37 -0000 I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, with two igb nics in use. Previously the machine was fine, running earlier versions of 7-STABLE, although the load on the network has increased due to additional machines being added to the network (the machine functions as a fileserver, serving files to compute machines via NFS(v3)). Any advice is much appreciated. System info is below. -greg Machine: ======= FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 root@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 Kernel was csup'd earlier in the day on 25 August, immediately prior to the build. Panic: ====== Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0xffffffff8052f40c stack pointer = 0x10:0xffffff82056819d0 frame pointer = 0x10:0xffffff82056819f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 65 (igb1 que) trap number = 9 panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x294 trap() at trap+0x106 calltrap() at calltrap+0x8 --- trap 0x9, rip = 0xffffffff8052f40c, rsp = 0xffffff82056819d0, rbp = 0xffffff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c uma_zfree_arg() at uma_zfree_arg+0x41 m_freem() at m_freem+0x54 ether_demux() at ether_demux+0x85 ether_input() at ether_input+0x1bb igb_rxeof() at igb_rxeof+0x29d igb_handle_que() at igb_handle_que+0x9a taskqueue_run() at taskqueue_run+0xac taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x122 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8205681d30, rbp = 0 --- Uptime: 11h57m6s Physical memory: 18411 MB Dumping 3770 MB: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8000000000 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff80188b5f stack pointer = 0x10:0xffffff82056811f0 frame pointer = 0x10:0xffffff82056812f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 65 (igb1 que) trap number = 12 pciconf: ======= igb0@pci0:10:0:0: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb1@pci0:10:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet dmesg: ===== igb0: port 0xe880-0xe89f mem 0xfbe60000-0xfbe 7ffff,0xfbe40000-0xfbe5ffff,0xfbeb8000-0xfbebbfff irq 16 at device 0.0 on pci10 igb0: Using MSIX interrupts with 10 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:30:48:ca:cd:72 igb1: port 0xec00-0xec1f mem 0xfbee0000-0xfbe fffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff irq 17 at device 0.1 on pci10 igb1: Using MSIX interrupts with 10 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:30:48:ca:cd:73 -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 19:10:44 2010 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 25A191065693 for ; Sun, 29 Aug 2010 19:10:44 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1D58FC1B for ; Sun, 29 Aug 2010 19:10:43 +0000 (UTC) Received: (qmail 45682 invoked from network); 29 Aug 2010 19:08:39 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Aug 2010 19:08:39 -0000 Message-ID: <4C7AB0B2.9020003@freebsd.org> Date: Sun, 29 Aug 2010 21:10:42 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mike Tancsa References: <201008291409.o7TE9QCJ082862@lava.sentex.ca> <4C7A7DD4.9020803@freebsd.org> <201008291716.o7THGxcF083744@lava.sentex.ca> In-Reply-To: <201008291716.o7THGxcF083744@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: syncache errors 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, 29 Aug 2010 19:10:44 -0000 On 29.08.2010 19:16, Mike Tancsa wrote: > At 11:33 AM 8/29/2010, Andre Oppermann wrote: >> On 29.08.2010 16:09, Mike Tancsa wrote: >>> After upgrading to a recent STABLE, I have been seeing the following sporadic errors >>> >>> Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to [xx.yy.164.50]:25; syncache_socket: >>> Socket create failed due to limits or memory shortage >>> >>> this is with >>> FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 >>> and the previous kernel was from July 20th. >>> >>> The odd thing is that the error is triggered from a RELENG_6 host only it would seem. I noticed >>> there are a number of syncache and tcp updates to RELENG_8, is it possible this is related ? I dont >>> have any specific tweaks in /etc/sysctl.conf >>> >>> other than >>> net.inet.tcp.log_in_vain: 1 >>> net.inet.udp.log_in_vain: 1 >> >> The log_in_vain sysctl would cause the logging of syncache errors >> as well (net.inet.tcp.log_debug). This was a POLA violation and >> I've separated them on August 27 on 8-stable. So if you update >> you won't see them anymore. That doesn't change the fact that >> the socket create failed though. >> >> If it only happens from a RELENG_6 box it probably is a problem >> with port re-usage by RELENG_6. The difficulty is that sonewconn() >> fails and doesn't return an error code. Hence it may be one of >> listen queue limits reached, memory shortage or a problem with >> inserting the inpcb into the hash lists. > > Actually, I think I might have found the issue. I was focusing on the "memory" part not the limits. > The 'RELENG_6 only' is just a fluke as thats a box that sends a lot of email to this particular > server. It turns out, sendmail was rate limiting the server > sm-mta[25923]: deferring connections on daemon IPv4: 8 per second > and somehow syncache is aware/logs this now where as it did not before ? When sendmail is deferring the connections it should not show up in the syncache logs. The accept() by sendmail is much later than when the socket for a new connection is created in syncache. Here it points to the limits in the listen queue. Maybe sendmail is getting behind in accepting new connections and the listen queue is overflowing. -- Andre From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 21:11:26 2010 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 7ADEE10656AC for ; Sun, 29 Aug 2010 21:11:26 +0000 (UTC) (envelope-from pistoletik@freebsd-go-go.ru) Received: from freebsd-go-go.ru (freebsd-go-go.ru [217.149.183.250]) by mx1.freebsd.org (Postfix) with ESMTP id 1AAE98FC14 for ; Sun, 29 Aug 2010 21:11:25 +0000 (UTC) Received: from [93.157.161.153] (port=61496 helo=firma.local) by freebsd-go-go.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Opojd-0002IN-Jv for freebsd-stable@freebsd.org; Mon, 30 Aug 2010 00:44:13 +0400 Message-ID: <4C7AC69A.2080001@freebsd-go-go.ru> Date: Mon, 30 Aug 2010 00:44:10 +0400 From: Baby Boy User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 93.157.161.153 X-SA-Exim-Mail-From: pistoletik@freebsd-go-go.ru X-SA-Exim-Scanned: No (on freebsd-go-go.ru); SAEximRunCond expanded to false Subject: Broadcom 4315 not working 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, 29 Aug 2010 21:11:26 -0000 Hi. WiFi BCM4315 not working. Please help me. ------- = 1 ------- # uname -a FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r211965: Sun Aug 29 22:18:05 MSD 2010 root@:/usr/obj/usr/src/sys/GENERIC i386 # cd /usr/src/sys/modules/siba_bwn && make && make install # cat /boot/loader.conf if_bwn_load="YES" # pciconf -lvbc siba_bwn0@pci0:3:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' class = network bar [10] = type Memory, range 64, base 0xd4200000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) # reboot # kldstat Id Refs Address Size Name 1 8 0xc0400000 bc14f4 kernel 2 1 0xc0fc2000 37248 if_bwn.ko 3 2 0xc0ffa000 a1dc siba_bwn.ko # ifconfig bwn0: flags=8802 metric 0 mtu 2290 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier .... ------- = 2 ------- # kldload bwn_v4_lp_ucode.ko # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 up # ifconfig bwn0: flags=8843 metric 0 mtu 2290 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ... wlan0: flags=8843 metric 0 mtu 1500 ether 0c:ee:e6:a1:50:cc media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 4 (2427 MHz 11g) country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme bintval 0 in series ifconfig can see: ... channel 4 (2427 MHz 11g) ... ... channel 5 (2432 MHz 11g) ... ... channel 9 (2452 MHz 11g) ... ... channel 12 (2467 MHz 11g) ... ... channel 14 (2484 MHz 11g) ... ... channel 1 (2412 MHz 11g) ... ... # cat /var/log/messages Aug 30 00:11:19 kernel: wlan0: Ethernet address: 0c:ee:e6:a1:50:cc Aug 30 00:11:41 kernel: bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) Aug 30 00:11:42 kernel: wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost Aug 30 00:12:09 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:09 kernel: bwn0: please turns on the RF switch Aug 30 00:12:10 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:17 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:17 kernel: bwn0: please turns on the RF switch Aug 30 00:12:19 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:21 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:21 kernel: bwn0: please turns on the RF switch Aug 30 00:12:25 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:33 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:33 kernel: bwn0: please turns on the RF switch Aug 30 00:12:34 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:12:35 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:12:35 kernel: bwn0: please turns on the RF switch Aug 30 00:12:36 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:13:49 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:13:49 kernel: bwn0: please turns on the RF switch Aug 30 00:13:50 kernel: bwn0: status of RF switch is changed to ON Aug 30 00:14:39 kernel: bwn0: status of RF switch is changed to OFF Aug 30 00:14:39 kernel: bwn0: please turns on the RF switch Aug 30 00:14:40 kernel: bwn0: status of RF switch is changed to ON From owner-freebsd-stable@FreeBSD.ORG Sun Aug 29 22:05:47 2010 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 CDC5810656A9; Sun, 29 Aug 2010 22:05:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 89EA68FC08; Sun, 29 Aug 2010 22:05:47 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7TM5GvU002102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2010 18:05:16 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7TLq6AC085028; Sun, 29 Aug 2010 17:52:06 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008292152.o7TLq6AC085028@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Aug 2010 17:52:01 -0400 To: Andre Oppermann From: Mike Tancsa In-Reply-To: <4C7AB0B2.9020003@freebsd.org> References: <201008291409.o7TE9QCJ082862@lava.sentex.ca> <4C7A7DD4.9020803@freebsd.org> <201008291716.o7THGxcF083744@lava.sentex.ca> <4C7AB0B2.9020003@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: freebsd-stable@freebsd.org Subject: Re: syncache errors 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, 29 Aug 2010 22:05:47 -0000 At 03:10 PM 8/29/2010, Andre Oppermann wrote: >On 29.08.2010 19:16, Mike Tancsa wrote: >>At 11:33 AM 8/29/2010, Andre Oppermann wrote: >>>On 29.08.2010 16:09, Mike Tancsa wrote: >>>>After upgrading to a recent STABLE, I have been seeing the >>>>following sporadic errors >>>> >>>>Aug 28 04:15:15 smarthost2 kernel: TCP: [xx.yy.165.120]:53617 to >>>>[xx.yy.164.50]:25; syncache_socket: >>>>Socket create failed due to limits or memory shortage >>>> >>>>this is with >>>>FreeBSD 8.1-STABLE #7: Wed Aug 25 15:32:05 EDT 2010 >>>>and the previous kernel was from July 20th. > >When sendmail is deferring the connections it should not show up >in the syncache logs. The accept() by sendmail is much later than >when the socket for a new connection is created in syncache. Here >it points to the limits in the listen queue. Maybe sendmail is >getting behind in accepting new connections and the listen queue >is overflowing. How would I track that down to confirm it ? ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Aug 30 00:57:42 2010 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 9D2AD10656A4 for ; Mon, 30 Aug 2010 00:57:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6276B8FC19 for ; Mon, 30 Aug 2010 00:57:42 +0000 (UTC) Received: by pwi8 with SMTP id 8so2319614pwi.13 for ; Sun, 29 Aug 2010 17:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=yn01JPjREcoOOegzY/D13PSTfH5S22JuwNRbTK97b/o=; b=w17xyc+qPKLniKfZi7+ot8nsRlE4DKGuKe9W3jf7w0Qxpa8C5sjJIceq2QX/tO/ScL rY2Hs3VVU5R732lmp0izWPimxDP9hNmnYp2dRiLqskErHcf1rAz20LU+R7Z5zVU5FHg2 bcSVoSW4xXIrYfYlwvLq1Ok99ipOJzOqPTEbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=nohk5eKnlK5lLxfu7g/UFxg3ydYxOjXQyq0LR9K/JBY441TW7P/Dh2/vyyYezHU86Q U/pnzM8DtTfwZZ+nIGJT4saZiauiGD6nylQQ78Kucycefmo57rdh4yrsjcTgzRDH5hVi 9ipxVs8E5TAbkBzL5RIvhBRkfp5amq/tV1tOM= Received: by 10.142.174.4 with SMTP id w4mr4007376wfe.119.1283129861839; Sun, 29 Aug 2010 17:57:41 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y16sm8877881wff.14.2010.08.29.17.57.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 29 Aug 2010 17:57:40 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 29 Aug 2010 17:57:14 -0700 From: Pyun YongHyeon Date: Sun, 29 Aug 2010 17:57:14 -0700 To: Philipp Wuensche Message-ID: <20100830005714.GB1330@michelle.cdnetworks.com> References: <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> <4C77B7DA.3040801@h3q.com> <4C781707.9020201@h3q.com> <4C791ADB.9040505@h3q.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <4C791ADB.9040505@h3q.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Jack Vogel , Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 00:57:42 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Aug 28, 2010 at 04:19:07PM +0200, Philipp Wuensche wrote: > Philipp Wuensche wrote: > > > > It just now started running the kernel without IPSEC and ALTQ. > > Here we go again, this time it crashed with IPSEC and ALTQ disabled, > crashdump looks different this time though. > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xffff80400bc58038 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff808a41ae > stack pointer = 0x28:0xffffff80000e69a0 > frame pointer = 0x28:0xffffff80000e69b0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (em1 taskq) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 23h30m3s > Physical memory: 4079 MB > Dumping 1907 MB: 1892 1876em1: Watchdog timeout -- resetting > 1860 1844 1828 1812 1796 1780 1764 1748 1732 1716 1700 1684 1668 1652 > 1636 1620 1604 1588 1572 1556 1540 1524 1508 1492 1476 1460 1444 1428 > 1412 1396 1380 1364 1348 1332 1316 1300 1284 1268 1252 1236 1220 1204 > 1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 > 948 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 > 660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 > 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 > 84 68 52 36 20 4 > > 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 > Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from > /boot/kernel/geom_stripe.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_stripe.ko > Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from > /boot/kernel/coretemp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/ahci.ko...Reading symbols from > /boot/kernel/ahci.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ahci.ko > Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from > /boot/kernel/ipmi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ipmi.ko > Reading symbols from /boot/kernel/smbus.ko...Reading symbols from > /boot/kernel/smbus.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/smbus.ko > Reading symbols from /boot/kernel/pflog.ko...Reading symbols from > /boot/kernel/pflog.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/pflog.ko > Reading symbols from /boot/kernel/pf.ko...Reading symbols from > /boot/kernel/pf.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/pf.ko > #0 doadump () at pcpu.h:224 > 224 __asm("movq %%gs:0,%0" : "=r" (td)); > (kgdb) list *0xffffffff808a41ae > 0xffffffff808a41ae is in pmap_kextract > (/usr/src/sys/amd64/amd64/pmap.c:1172). > 1167 vm_paddr_t pa; > 1168 > 1169 if (va >= DMAP_MIN_ADDRESS && va < DMAP_MAX_ADDRESS) { > 1170 pa = DMAP_TO_PHYS(va); > 1171 } else { > 1172 pde = *vtopde(va); > 1173 if (pde & PG_PS) { > 1174 pa = (pde & PG_PS_FRAME) | (va & PDRMASK); > 1175 } else { > 1176 /* > (kgdb) backtrace > #0 doadump () at pcpu.h:224 > #1 0xffffffff805b2b5e in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff805b2f6c in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:590 > #3 0xffffffff808ac70d in trap_fatal (frame=0xffffffff80c5cc60, > eva=Variable "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:777 > #4 0xffffffff808acacf in trap_pfault (frame=0xffffff80000e68f0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:693 > #5 0xffffffff808ad2e2 in trap (frame=0xffffff80000e68f0) > at /usr/src/sys/amd64/amd64/trap.c:451 > #6 0xffffffff808923b4 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #7 0xffffffff808a41ae in pmap_kextract (va=51771551252551) > at /usr/src/sys/amd64/amd64/pmap.c:1172 > #8 0xffffffff80890f83 in bus_dmamap_load_mbuf_sg (dmat=0xffffff0002727c00, > map=0xffffffff80c99d40, m0=Variable "m0" is not available. > ) > at /usr/src/sys/amd64/amd64/busdma_machdep.c:659 > #9 0xffffffff8032f8fc in em_refresh_mbufs (rxr=0xffffff0002712600, > limit=975) > at /usr/src/sys/dev/e1000/if_em.c:3691 > #10 0xffffffff8032ff3c in em_rxeof (rxr=0xffffff0002712600, count=100, > done=0x0) at /usr/src/sys/dev/e1000/if_em.c:4210 > #11 0xffffffff80330788 in em_handle_que (context=Variable "context" is > not available. > ) > at /usr/src/sys/dev/e1000/if_em.c:1451 > #12 0xffffffff805efc94 in taskqueue_run (queue=0xffffff0002727b80) > at /usr/src/sys/kern/subr_taskqueue.c:239 > #13 0xffffffff805eff06 in taskqueue_thread_loop (arg=Variable "arg" is > not available. > ) > at /usr/src/sys/kern/subr_taskqueue.c:360 > #14 0xffffffff80589998 in fork_exit ( > callout=0xffffffff805efec0 , > arg=0xffffff80003c2740, frame=0xffffff80000e6c80) > at /usr/src/sys/kern/kern_fork.c:844 > #15 0xffffffff8089288e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:566 > #16 0x0000000000000000 in ?? () > #17 0x0000000000000000 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000000000000000 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x000000000109b000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000000000 in ?? () > #43 0xffffffff80c823e0 in sleepq_chains () > #44 0xffffff00025087c0 in ?? () > #45 0xffffff80000e6b20 in ?? () > #46 0xffffff80000e6ad8 in ?? () > #47 0xffffff000267f7c0 in ?? () > #48 0xffffffff805d6a8a in sched_switch (td=0xffffff80003c2740, > newtd=0xffffffff805efec0, flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1844 > Previous frame inner to this frame (corrupt stack?) Ok, thanks for the backtrace. This one indicates suspicious code path in em(4). Would you try attached patch and let me know whether it makes any difference on your box? Note, the patch was not extensively tested so make sure to test first before applying the patch to production box. The patch generated against HEAD but I guess it could be applied to stable/8. --d6Gm4EdcadzBjdND Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="em.rxdma.patch" Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 211984) +++ sys/dev/e1000/if_em.c (working copy) @@ -244,7 +244,7 @@ static void em_set_promisc(struct adapter *); static void em_disable_promisc(struct adapter *); static void em_set_multi(struct adapter *); static void em_update_link_status(struct adapter *); -static void em_refresh_mbufs(struct rx_ring *, int); +static int em_refresh_mbufs(struct rx_ring *, int); static void em_register_vlan(void *, struct ifnet *, u16); static void em_unregister_vlan(void *, struct ifnet *, u16); static void em_setup_vlan_hw_support(struct adapter *); @@ -3675,68 +3675,51 @@ em_txeof(struct tx_ring *txr) * Refresh RX descriptor mbufs from system mbuf buffer pool. * **********************************************************************/ -static void -em_refresh_mbufs(struct rx_ring *rxr, int limit) +static int +em_refresh_mbufs(struct rx_ring *rxr, int i) { struct adapter *adapter = rxr->adapter; struct mbuf *m; bus_dma_segment_t segs[1]; bus_dmamap_t map; struct em_buffer *rxbuf; - int i, error, nsegs, cleaned; + int error, nsegs; - i = rxr->next_to_refresh; - cleaned = -1; - while (i != limit) { - m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); - if (m == NULL) - goto update; - m->m_len = m->m_pkthdr.len = MCLBYTES; + m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); + if (m == NULL) + return (ENOBUFS); + m->m_len = m->m_pkthdr.len = MCLBYTES; - if (adapter->max_frame_size <= (MCLBYTES - ETHER_ALIGN)) - m_adj(m, ETHER_ALIGN); + if (adapter->max_frame_size <= (MCLBYTES - ETHER_ALIGN)) + m_adj(m, ETHER_ALIGN); - /* - * Using memory from the mbuf cluster pool, invoke the - * bus_dma machinery to arrange the memory mapping. - */ - error = bus_dmamap_load_mbuf_sg(rxr->rxtag, rxr->rx_sparemap, - m, segs, &nsegs, BUS_DMA_NOWAIT); - if (error != 0) { - m_free(m); - goto update; - } + /* + * Using memory from the mbuf cluster pool, invoke the + * bus_dma machinery to arrange the memory mapping. + */ + error = bus_dmamap_load_mbuf_sg(rxr->rxtag, rxr->rx_sparemap, m, segs, + &nsegs, 0); + if (error != 0) { + m_free(m); + return (error); + } - /* If nsegs is wrong then the stack is corrupt. */ - KASSERT(nsegs == 1, ("Too many segments returned!")); + /* If nsegs is wrong then the stack is corrupt. */ + KASSERT(nsegs == 1, ("Too many segments returned!")); - rxbuf = &rxr->rx_buffers[i]; - if (rxbuf->m_head != NULL) - bus_dmamap_unload(rxr->rxtag, rxbuf->map); + rxbuf = &rxr->rx_buffers[i]; + if (rxbuf->m_head != NULL) { + bus_dmamap_sync(rxr->rxtag, rxbuf->map, BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(rxr->rxtag, rxbuf->map); + } - map = rxbuf->map; - rxbuf->map = rxr->rx_sparemap; - rxr->rx_sparemap = map; - bus_dmamap_sync(rxr->rxtag, - rxbuf->map, BUS_DMASYNC_PREREAD); - rxbuf->m_head = m; - rxr->rx_base[i].buffer_addr = htole64(segs[0].ds_addr); - - cleaned = i; - /* Calculate next index */ - if (++i == adapter->num_rx_desc) - i = 0; - /* This is the work marker for refresh */ - rxr->next_to_refresh = i; - } -update: - bus_dmamap_sync(rxr->rxdma.dma_tag, rxr->rxdma.dma_map, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); - if (cleaned != -1) /* Update tail index */ - E1000_WRITE_REG(&adapter->hw, - E1000_RDT(rxr->me), cleaned); - - return; + map = rxbuf->map; + rxbuf->map = rxr->rx_sparemap; + rxr->rx_sparemap = map; + bus_dmamap_sync(rxr->rxtag, rxbuf->map, BUS_DMASYNC_PREREAD); + rxbuf->m_head = m; + rxr->rx_base[i].buffer_addr = htole64(segs[0].ds_addr); + return (0); } @@ -3840,6 +3823,7 @@ em_setup_receive_ring(struct rx_ring *rxr) BUS_DMASYNC_POSTREAD); bus_dmamap_unload(rxr->rxtag, rxbuf->map); m_freem(rxbuf->m_head); + rxbuf->m_head = NULL; } } @@ -3873,7 +3857,7 @@ em_setup_receive_ring(struct rx_ring *rxr) /* Setup our descriptor indices */ rxr->next_to_check = 0; - rxr->next_to_refresh = 0; + rxr->rxdiscard = 0; bus_dmamap_sync(rxr->rxdma.dma_tag, rxr->rxdma.dma_map, BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); @@ -4107,13 +4091,13 @@ em_rxeof(struct rx_ring *rxr, int count, int *done struct mbuf *mp, *sendmp; u8 status = 0; u16 len; - int i, processed, rxdone = 0; + int i, processed, rdt, rxdone = 0; bool eop; struct e1000_rx_desc *cur; EM_RX_LOCK(rxr); - for (i = rxr->next_to_check, processed = 0; count != 0;) { + for (i = rdt = rxr->next_to_check, processed = 0; count != 0;) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) break; @@ -4133,9 +4117,21 @@ em_rxeof(struct rx_ring *rxr, int count, int *done count--; if ((cur->errors & E1000_RXD_ERR_FRAME_ERR_MASK) == 0) { - + mp = rxr->rx_buffers[i].m_head; + if (em_refresh_mbufs(rxr, i) != 0) { + ifp->if_iqdrops++; + if (rxr->fmp != NULL) { + /* Mark discarding chanined mbufs. */ + if (eop == 0) + rxr->rxdiscard++; + m_freem(rxr->fmp); + rxr->fmp = NULL; + rxr->lmp = NULL; + } + sendmp = NULL; + goto discard; + } /* Assign correct length to the current fragment */ - mp = rxr->rx_buffers[i].m_head; mp->m_len = len; if (rxr->fmp == NULL) { @@ -4151,6 +4147,14 @@ em_rxeof(struct rx_ring *rxr, int count, int *done } if (eop) { + if (rxr->rxdiscard > 0) { + m_freem(rxr->fmp); + rxr->fmp = NULL; + rxr->lmp = NULL; + rxr->rxdiscard = 0; + sendmp = NULL; + goto discard; + } rxr->fmp->m_pkthdr.rcvif = ifp; ifp->if_ipackets++; em_receive_checksum(cur, rxr->fmp); @@ -4179,6 +4183,9 @@ skip: } } else { ifp->if_ierrors++; + /* Mark discarding chanined mbufs. */ + if (eop == 0) + rxr->rxdiscard++; /* Reuse loaded DMA map and just update mbuf chain */ mp = rxr->rx_buffers[i].m_head; mp->m_len = mp->m_pkthdr.len = MCLBYTES; @@ -4195,11 +4202,18 @@ skip: sendmp = NULL; } +discard: /* Zero out the receive descriptors status. */ cur->status = 0; ++rxdone; /* cumulative for POLL */ - ++processed; - + /* Only refresh mbufs every 8 descriptors */ + rdt = i; + if (++processed == 8) { + bus_dmamap_sync(rxr->rxdma.dma_tag, rxr->rxdma.dma_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + E1000_WRITE_REG(&adapter->hw, E1000_RDT(rxr->me), rdt); + processed = 0; + } /* Advance our pointers to the next descriptor. */ if (++i == adapter->num_rx_desc) i = 0; @@ -4212,18 +4226,13 @@ skip: EM_RX_LOCK(rxr); i = rxr->next_to_check; } - - /* Only refresh mbufs every 8 descriptors */ - if (processed == 8) { - em_refresh_mbufs(rxr, i); - processed = 0; - } } /* Catch any remaining refresh work */ if (processed != 0) { - em_refresh_mbufs(rxr, i); - processed = 0; + bus_dmamap_sync(rxr->rxdma.dma_tag, rxr->rxdma.dma_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + E1000_WRITE_REG(&adapter->hw, E1000_RDT(rxr->me), rdt); } rxr->next_to_check = i; Index: sys/dev/e1000/if_em.h =================================================================== --- sys/dev/e1000/if_em.h (revision 211984) +++ sys/dev/e1000/if_em.h (working copy) @@ -310,11 +310,11 @@ struct rx_ring { struct taskqueue *tq; struct e1000_rx_desc *rx_base; struct em_dma_alloc rxdma; - u32 next_to_refresh; u32 next_to_check; struct em_buffer *rx_buffers; struct mbuf *fmp; struct mbuf *lmp; + u8 rxdiscard; /* Interrupt resources */ void *tag; --d6Gm4EdcadzBjdND-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 30 03:37:17 2010 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 0BDD510656A6 for ; Mon, 30 Aug 2010 03:37:17 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B693E8FC08 for ; Mon, 30 Aug 2010 03:37:16 +0000 (UTC) Received: by gwj23 with SMTP id 23so2157801gwj.13 for ; Sun, 29 Aug 2010 20:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version :content-type:content-transfer-encoding; bh=U3P1EBIGaJsNSSoBG7EWYYbc7XZOdr88yt7U4T5Ppp4=; b=uOVyH/rxeWqJKB7wSuKBit7BZRkbkOZwve7cHZMCZu0MaG5cSWCl+A19j373s3nSLo BXNRGM758bcMRcfLuYeq8iQdZo/JNQKvC64eJok6eCVvBSv6rcHB9tUogNbo1RXH2j4L 0SMUL29CsYa2bBM/zvX3PfAGk3jjIZiLTqPAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; b=Janyno9LuT1OIiAvefbRY2IQE7u0wvDN5Tf7gcGK2mPUFhI1oxIhk/pyY4aCU9ArIF 6OaKKDoDrq+mSPE0ZXx9KSFvwTqlcmOocmaxBHkT0VuPEHUK1Yx90eZGR3OjEWHqgROW 1iEQJjr90vmvKCsO236Gb96EGwUoXkl0ny2YA= Received: by 10.101.69.5 with SMTP id w5mr3856649ank.211.1283139435707; Sun, 29 Aug 2010 20:37:15 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id e18sm8983509ana.35.2010.08.29.20.37.14 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Aug 2010 20:37:14 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C7B2768.4030604@DataIX.net> Date: Sun, 29 Aug 2010 23:37:12 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Joseph Koshy X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: hwpmc(4) driver / compiler warnings 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, 30 Aug 2010 03:37:17 -0000 I have received the following warnings about enumerated values for enum pmc_event on stable/8 i386. I am not sure how long this has been going on because I do not really use the PMC, therefore its not built into the kernel. This is just a heads up because though this warning has no effect on my machines it may in other area's. WARNING: hwpmc_amd.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_core.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_intel.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_logging.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_mod.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_pentium.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_piv.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_ppro.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_tsc.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_uncore.c: enum pmc_event has too many values: 1121 > 1023 WARNING: hwpmc_x86.c: enum pmc_event has too many values: 1121 > 1023 Regards, -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Mon Aug 30 06:45:58 2010 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 D4D2210656AD for ; Mon, 30 Aug 2010 06:45:58 +0000 (UTC) (envelope-from adrian.chadd@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 1A51F8FC17 for ; Mon, 30 Aug 2010 06:45:57 +0000 (UTC) Received: by yxn35 with SMTP id 35so1559356yxn.13 for ; Sun, 29 Aug 2010 23:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+DWF+/Tashng1fC6X464umNgU+uhEyrFbgz0swEQ3O4=; b=uxm11Yhy58VzssQI3M1BaMGaMjRiSzRRYkAo+jOddlDW7Pef0hgF5qMDrH5ftVnT4E GyeK61XrMr2d0DQBxCtlFN0RiRyy93cNvCvCG7kpULYsxABl9vVGgmZT0JegylkDQrER 8FGvreMBP21WHiI2LJiRw6kU9sLIxheRJWsD0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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 :content-transfer-encoding; b=i3kqn8fw/rleB6yGE2AKSEkSq5+wjKkHwIhPGqKCVlxoyMQb/exsquElXlMHRiyCZ8 8a/BMWqDy7fUpxG9phUcbN2rSZI98KE/XLNVXksEMMqw4Om+r9r81Xeyuw8MVqAgfjMn ZW0LODrsLaKV3yT5aKu2iBJ1cuVcOUWwKsKC4= MIME-Version: 1.0 Received: by 10.150.190.16 with SMTP id n16mr4967794ybf.144.1283150757316; Sun, 29 Aug 2010 23:45:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.168.14 with HTTP; Sun, 29 Aug 2010 23:45:57 -0700 (PDT) In-Reply-To: <4C7522AA.90004@aldan.algebra.com> References: <4C749E8C.1020506@aldan.algebra.com> <201008250827.13482.jhb@freebsd.org> <4C7522AA.90004@aldan.algebra.com> Date: Mon, 30 Aug 2010 14:45:57 +0800 X-Google-Sender-Auth: i6aK3KFxE3U8-xypPs5Z58HqsDU Message-ID: From: Adrian Chadd To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, sam@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: Can't compile ath(4) into kernel 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, 30 Aug 2010 06:45:59 -0000 Please just create a PR for it. I haven't tried compiling ath without AR5416 support so I have no idea whether it'll work. adrian On 25 August 2010 22:03, Mikhail T. wrote: > =A0On 8/25/2010 8:27 AM, John Baldwin wrote: >> You are missing: >> >> options =A0 =A0 =A0 =A0 AH_SUPPORT_AR5416 =A0 =A0 =A0 # enable AR5416 tx= /rx descriptors >> > But I don't have the ar5416 chipset... Mine is AR2312... And it is an > option, so should not it be optional? Anyway, I tried adding that option > and the error is the same (did cleandepend && depend, saw ah.c > recompiled anew). >> For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at th= e >> changes to GENERIC across your upgrade. It would save you several e-mail= s to >> the mailing list > Thanks, I did that. After several attempts to fiddle with > options/devices, the wireless section now looks like: > > =A0 =A0# Wireless NIC cards > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan =A0 =A0 =A0 =A0 =A0 =A0# 802.11 sup= port > =A0 =A0options =A0 =A0 =A0 =A0 IEEE80211_DEBUG # enable debug msgs > =A0 =A0options =A0 =A0 =A0 =A0 IEEE80211_AMPDU_AGE # age frames in AMPDU = reorder q's > =A0 =A0options =A0 =A0 =A0 =A0 IEEE80211_SUPPORT_MESH =A0# enable 802.11s= draft support > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_wep =A0 =A0 =A0 =A0# 802.11 WEP sup= port > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_ccmp =A0 =A0 =A0 # 802.11 CCMP supp= ort > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_tkip =A0 =A0 =A0 # 802.11 TKIP supp= ort > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_amrr =A0 =A0 =A0 # AMRR transmit ra= te control algorithm > =A0 =A0device =A0 =A0 =A0 =A0 =A0ath > =A0 =A0device =A0 =A0 =A0 =A0 =A0ath_rate_sample # SampleRate tx rate con= trol for ath > =A0 =A0device =A0 =A0 =A0 =A0 =A0ath_ar5212 > =A0 =A0#device =A0 =A0 =A0 =A0 ath_rate_onoe > =A0 =A0#options =A0 =A0 =A0 =A0AH_SUPPORT_AR5416 =A0 =A0 =A0 # enable AR5= 416 tx/rx > =A0 =A0descriptors > > Generic simply uses the entire ath_hal, but ath_hal(4) suggests, that > picking out a single driver should work... > > =A0 =A0-mi > > _______________________________________________ > 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 Mon Aug 30 07:13:09 2010 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 9A9EF1065670 for ; Mon, 30 Aug 2010 07:13:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5175E8FC08 for ; Mon, 30 Aug 2010 07:13:09 +0000 (UTC) Received: by ywt2 with SMTP id 2so2206472ywt.13 for ; Mon, 30 Aug 2010 00:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+DWF+/Tashng1fC6X464umNgU+uhEyrFbgz0swEQ3O4=; b=uxm11Yhy58VzssQI3M1BaMGaMjRiSzRRYkAo+jOddlDW7Pef0hgF5qMDrH5ftVnT4E GyeK61XrMr2d0DQBxCtlFN0RiRyy93cNvCvCG7kpULYsxABl9vVGgmZT0JegylkDQrER 8FGvreMBP21WHiI2LJiRw6kU9sLIxheRJWsD0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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 :content-transfer-encoding; b=i3kqn8fw/rleB6yGE2AKSEkSq5+wjKkHwIhPGqKCVlxoyMQb/exsquElXlMHRiyCZ8 8a/BMWqDy7fUpxG9phUcbN2rSZI98KE/XLNVXksEMMqw4Om+r9r81Xeyuw8MVqAgfjMn ZW0LODrsLaKV3yT5aKu2iBJ1cuVcOUWwKsKC4= MIME-Version: 1.0 Received: by 10.150.190.16 with SMTP id n16mr4967794ybf.144.1283150757316; Sun, 29 Aug 2010 23:45:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.168.14 with HTTP; Sun, 29 Aug 2010 23:45:57 -0700 (PDT) In-Reply-To: <4C7522AA.90004@aldan.algebra.com> References: <4C749E8C.1020506@aldan.algebra.com> <201008250827.13482.jhb@freebsd.org> <4C7522AA.90004@aldan.algebra.com> Date: Mon, 30 Aug 2010 14:45:57 +0800 X-Google-Sender-Auth: i6aK3KFxE3U8-xypPs5Z58HqsDU Message-ID: From: Adrian Chadd To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, sam@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: Can't compile ath(4) into kernel 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, 30 Aug 2010 07:13:09 -0000 Please just create a PR for it. I haven't tried compiling ath without AR5416 support so I have no idea whether it'll work. adrian On 25 August 2010 22:03, Mikhail T. wrote: > =A0On 8/25/2010 8:27 AM, John Baldwin wrote: >> You are missing: >> >> options =A0 =A0 =A0 =A0 AH_SUPPORT_AR5416 =A0 =A0 =A0 # enable AR5416 tx= /rx descriptors >> > But I don't have the ar5416 chipset... Mine is AR2312... And it is an > option, so should not it be optional? Anyway, I tried adding that option > and the error is the same (did cleandepend && depend, saw ah.c > recompiled anew). >> For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at th= e >> changes to GENERIC across your upgrade. It would save you several e-mail= s to >> the mailing list > Thanks, I did that. After several attempts to fiddle with > options/devices, the wireless section now looks like: > > =A0 =A0# Wireless NIC cards > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan =A0 =A0 =A0 =A0 =A0 =A0# 802.11 sup= port > =A0 =A0options =A0 =A0 =A0 =A0 IEEE80211_DEBUG # enable debug msgs > =A0 =A0options =A0 =A0 =A0 =A0 IEEE80211_AMPDU_AGE # age frames in AMPDU = reorder q's > =A0 =A0options =A0 =A0 =A0 =A0 IEEE80211_SUPPORT_MESH =A0# enable 802.11s= draft support > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_wep =A0 =A0 =A0 =A0# 802.11 WEP sup= port > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_ccmp =A0 =A0 =A0 # 802.11 CCMP supp= ort > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_tkip =A0 =A0 =A0 # 802.11 TKIP supp= ort > =A0 =A0device =A0 =A0 =A0 =A0 =A0wlan_amrr =A0 =A0 =A0 # AMRR transmit ra= te control algorithm > =A0 =A0device =A0 =A0 =A0 =A0 =A0ath > =A0 =A0device =A0 =A0 =A0 =A0 =A0ath_rate_sample # SampleRate tx rate con= trol for ath > =A0 =A0device =A0 =A0 =A0 =A0 =A0ath_ar5212 > =A0 =A0#device =A0 =A0 =A0 =A0 ath_rate_onoe > =A0 =A0#options =A0 =A0 =A0 =A0AH_SUPPORT_AR5416 =A0 =A0 =A0 # enable AR5= 416 tx/rx > =A0 =A0descriptors > > Generic simply uses the entire ath_hal, but ath_hal(4) suggests, that > picking out a single driver should work... > > =A0 =A0-mi > > _______________________________________________ > 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 Mon Aug 30 09:46:33 2010 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 1F5E910656B1 for ; Mon, 30 Aug 2010 09:46:32 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5852F8FC1E for ; Mon, 30 Aug 2010 09:46:30 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id o7U9kVgj051366 for ; Mon, 30 Aug 2010 11:46:31 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id o7U9kVvW051365 for freebsd-stable@freebsd.org; Mon, 30 Aug 2010 11:46:31 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 30 Aug 2010 11:46:31 +0200 From: Greg Byshenk To: freebsd-stable@freebsd.org Message-ID: <20100830094631.GD12467@core.byshenk.net> References: <20100829181659.GB12467@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100829181659.GB12467@core.byshenk.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Subject: Re: igb related(?) panics on 7.3-STABLE 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, 30 Aug 2010 09:46:33 -0000 On Sun, Aug 29, 2010 at 08:16:59PM +0200, Greg Byshenk wrote: > I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, > with two igb nics in use. Previously the machine was fine, running earlier > versions of 7-STABLE, although the load on the network has increased due > to additional machines being added to the network (the machine functions > as a fileserver, serving files to compute machines via NFS(v3)). > > Any advice is much appreciated. System info is below. Followup with more information. The machine just panic'ed again, with a lot of load on the network. Output from the 'systat' that was running at the time: 3 users Load 54.47 42.35 24.25 Aug 30 11:17 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 46232 5504 868140 10548 943324 count All 456484 7852 1074772k 27740 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 54220 total 1 170 392k 8 278 22k 195 1 zfod sio0 irq4 ozfod fdc0 irq6 70.4%Sys 3.1%Intr 0.0%User 0.0%Nice 26.5%Idle %ozfod 27 twa0 uhci0 | | | | | | | | | | | daefr 2001 cpu0: time ===================================++ prcfr igb0 256 9938 dtbuf 1247 totfr igb0 257 Namei Name-cache Dir-cache 100000 desvn react igb0 258 Calls hits % hits % 34443 numvn 1 pdwak igb0 259 24996 frevn 112852 pdpgs igb0 262 intrn igb0 263 Disks da0 da1 pass0 pass1 2570672 wire igb0 264 KB/t 0.00 12.23 0.00 0.00 46760 act igb0 265 tps 0 26 0 0 14706896 inact 19449 igb1 266 MB/s 0.00 0.31 0.00 0.00 0 769796 26585 0 21 0 0 173528 -greg > Machine: > ======= > > FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 root@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 > > Kernel was csup'd earlier in the day on 25 August, immediately prior to > the build. > > > Panic: > ====== > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 2; apic id = 02 > instruction pointer = 0x8:0xffffffff8052f40c > stack pointer = 0x10:0xffffff82056819d0 > frame pointer = 0x10:0xffffff82056819f0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 65 (igb1 que) > trap number = 9 > panic: general protection fault > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > trap_fatal() at trap_fatal+0x294 > trap() at trap+0x106 > calltrap() at calltrap+0x8 > --- trap 0x9, rip = 0xffffffff8052f40c, rsp = 0xffffff82056819d0, rbp = 0xffffff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c > uma_zfree_arg() at uma_zfree_arg+0x41 > m_freem() at m_freem+0x54 > ether_demux() at ether_demux+0x85 > ether_input() at ether_input+0x1bb > igb_rxeof() at igb_rxeof+0x29d > igb_handle_que() at igb_handle_que+0x9a > taskqueue_run() at taskqueue_run+0xac > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x122 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8205681d30, rbp = 0 --- > Uptime: 11h57m6s > Physical memory: 18411 MB > Dumping 3770 MB: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8000000000 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff80188b5f > stack pointer = 0x10:0xffffff82056811f0 > frame pointer = 0x10:0xffffff82056812f0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 65 (igb1 que) > trap number = 12 > > > pciconf: > ======= > > igb0@pci0:10:0:0: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > igb1@pci0:10:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > > dmesg: > ===== > > igb0: port 0xe880-0xe89f mem 0xfbe60000-0xfbe > 7ffff,0xfbe40000-0xfbe5ffff,0xfbeb8000-0xfbebbfff irq 16 at device 0.0 on pci10 > igb0: Using MSIX interrupts with 10 vectors > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: [ITHREAD] > igb0: Ethernet address: 00:30:48:ca:cd:72 > igb1: port 0xec00-0xec1f mem 0xfbee0000-0xfbe > fffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff irq 17 at device 0.1 on pci10 > igb1: Using MSIX interrupts with 10 vectors > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: Ethernet address: 00:30:48:ca:cd:73 > > > -- > greg byshenk - gbyshenk@byshenk.net - Leiden, NL > _______________________________________________ > 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" -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Mon Aug 30 11:08:47 2010 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 71B1510656A7 for ; Mon, 30 Aug 2010 11:08:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 592CF8FC20 for ; Mon, 30 Aug 2010 11:08:47 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta06.emeryville.ca.mail.comcast.net with comcast id 0b8X1f0050vp7WLA6b8nEf; Mon, 30 Aug 2010 11:08:47 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta05.emeryville.ca.mail.comcast.net with comcast id 0b8l1f0063LrwQ28Rb8mlx; Mon, 30 Aug 2010 11:08:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D6A719B42E; Mon, 30 Aug 2010 04:08:45 -0700 (PDT) Date: Mon, 30 Aug 2010 04:08:45 -0700 From: Jeremy Chadwick To: Greg Byshenk Message-ID: <20100830110845.GA31629@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Crashes on X7SPE-HF with em 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, 30 Aug 2010 11:08:47 -0000 Bcc: Subject: Re: igb related(?) panics on 7.3-STABLE Reply-To: In-Reply-To: <20100830094631.GD12467@core.byshenk.net> On Mon, Aug 30, 2010 at 11:46:31AM +0200, Greg Byshenk wrote: > On Sun, Aug 29, 2010 at 08:16:59PM +0200, Greg Byshenk wrote: > > > I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, > > with two igb nics in use. Previously the machine was fine, running earlier > > versions of 7-STABLE, although the load on the network has increased due > > to additional machines being added to the network (the machine functions > > as a fileserver, serving files to compute machines via NFS(v3)). > > > > Any advice is much appreciated. System info is below. > > > Followup with more information. The machine just panic'ed again, with > a lot of load on the network. > > Output from the 'systat' that was running at the time: > > 3 users Load 54.47 42.35 24.25 Aug 30 11:17 > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 46232 5504 868140 10548 943324 count > All 456484 7852 1074772k 27740 pages > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt cow 54220 total > 1 170 392k 8 278 22k 195 1 zfod sio0 irq4 > ozfod fdc0 irq6 > 70.4%Sys 3.1%Intr 0.0%User 0.0%Nice 26.5%Idle %ozfod 27 twa0 uhci0 > | | | | | | | | | | | daefr 2001 cpu0: time > ===================================++ prcfr igb0 256 > 9938 dtbuf 1247 totfr igb0 257 > Namei Name-cache Dir-cache 100000 desvn react igb0 258 > Calls hits % hits % 34443 numvn 1 pdwak igb0 259 > 24996 frevn 112852 pdpgs igb0 262 > intrn igb0 263 > Disks da0 da1 pass0 pass1 2570672 wire igb0 264 > KB/t 0.00 12.23 0.00 0.00 46760 act igb0 265 > tps 0 26 0 0 14706896 inact 19449 igb1 266 > MB/s 0.00 0.31 0.00 0.00 0 769796 26585 > 0 21 0 0 173528 > > > -greg > > > > > Machine: > > ======= > > > > FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 root@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 > > > > Kernel was csup'd earlier in the day on 25 August, immediately prior to > > the build. > > > > > > Panic: > > ====== > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 2; apic id = 02 > > instruction pointer = 0x8:0xffffffff8052f40c > > stack pointer = 0x10:0xffffff82056819d0 > > frame pointer = 0x10:0xffffff82056819f0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 65 (igb1 que) > > trap number = 9 > > panic: general protection fault > > cpuid = 2 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > panic() at panic+0x182 > > trap_fatal() at trap_fatal+0x294 > > trap() at trap+0x106 > > calltrap() at calltrap+0x8 > > --- trap 0x9, rip = 0xffffffff8052f40c, rsp = 0xffffff82056819d0, rbp = 0xffffff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c > > uma_zfree_arg() at uma_zfree_arg+0x41 > > m_freem() at m_freem+0x54 > > ether_demux() at ether_demux+0x85 > > ether_input() at ether_input+0x1bb > > igb_rxeof() at igb_rxeof+0x29d > > igb_handle_que() at igb_handle_que+0x9a > > taskqueue_run() at taskqueue_run+0xac > > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > > fork_exit() at fork_exit+0x122 > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffff8205681d30, rbp = 0 --- > > Uptime: 11h57m6s > > Physical memory: 18411 MB > > Dumping 3770 MB: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x8000000000 > > fault code = supervisor write data, page not present > > instruction pointer = 0x8:0xffffffff80188b5f > > stack pointer = 0x10:0xffffff82056811f0 > > frame pointer = 0x10:0xffffff82056812f0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 65 (igb1 que) > > trap number = 12 > > > > > > pciconf: > > ======= > > > > igb0@pci0:10:0:0: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > igb1@pci0:10:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > > > > > dmesg: > > ===== > > > > igb0: port 0xe880-0xe89f mem 0xfbe60000-0xfbe > > 7ffff,0xfbe40000-0xfbe5ffff,0xfbeb8000-0xfbebbfff irq 16 at device 0.0 on pci10 > > igb0: Using MSIX interrupts with 10 vectors > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: [ITHREAD] > > igb0: Ethernet address: 00:30:48:ca:cd:72 > > igb1: port 0xec00-0xec1f mem 0xfbee0000-0xfbe > > fffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff irq 17 at device 0.1 on pci10 > > igb1: Using MSIX interrupts with 10 vectors > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: [ITHREAD] > > igb1: Ethernet address: 00:30:48:ca:cd:73 Adding Jack Vogel of Intel and Yong-Hyeon PYUN to the mix... I don't know if this is possible for you to do, but do you see the same problem when running 8.1-STABLE? I know there has been a lot of positive work on igb(4) in RELENG_8, but not too many of the fixes and improvements are backported to RELENG_7. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_igb.c Be sure to check out Revision 1.54 there (which is for HEAD/CURRENT, but I'm not sure if it's been backported/incorporated in some other way). Otherwise, as a test/workaround you might try disabling MSI-X support entirely to see if there's any improvement. This could degrade system performance a bit (under heavy interrupt load). In /boot/loader.conf, set hw.pci.enable_msix="0" and reboot. If there's no improvement, be sure to remove this. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Aug 30 11:26:03 2010 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 5C9291065695 for ; Mon, 30 Aug 2010 11:26:03 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id DBDD48FC12 for ; Mon, 30 Aug 2010 11:26:02 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id o7UBQ3FB053923; Mon, 30 Aug 2010 13:26:03 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id o7UBQ3XS053922; Mon, 30 Aug 2010 13:26:03 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 30 Aug 2010 13:26:03 +0200 From: Greg Byshenk To: Jeremy Chadwick Message-ID: <20100830112603.GE12467@core.byshenk.net> References: <20100830110845.GA31629@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100830110845.GA31629@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Crashes on X7SPE-HF with em 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, 30 Aug 2010 11:26:03 -0000 On Mon, Aug 30, 2010 at 04:08:45AM -0700, Jeremy Chadwick wrote: > Bcc: > Subject: Re: igb related(?) panics on 7.3-STABLE > Reply-To: > In-Reply-To: <20100830094631.GD12467@core.byshenk.net> > > On Mon, Aug 30, 2010 at 11:46:31AM +0200, Greg Byshenk wrote: > > On Sun, Aug 29, 2010 at 08:16:59PM +0200, Greg Byshenk wrote: > > > > > I've begun seeing problems on a machine running FreeBSD-7.3-STABLE, 64-bit, > > > with two igb nics in use. Previously the machine was fine, running earlier > > > versions of 7-STABLE, although the load on the network has increased due > > > to additional machines being added to the network (the machine functions > > > as a fileserver, serving files to compute machines via NFS(v3)). > > > > > > Any advice is much appreciated. System info is below. > > > > > > Followup with more information. The machine just panic'ed again, with > > a lot of load on the network. > > > > Output from the 'systat' that was running at the time: > > > > 3 users Load 54.47 42.35 24.25 Aug 30 11:17 > > > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > > Tot Share Tot Share Free in out in out > > Act 46232 5504 868140 10548 943324 count > > All 456484 7852 1074772k 27740 pages > > Proc: Interrupts > > r p d s w Csw Trp Sys Int Sof Flt cow 54220 total > > 1 170 392k 8 278 22k 195 1 zfod sio0 irq4 > > ozfod fdc0 irq6 > > 70.4%Sys 3.1%Intr 0.0%User 0.0%Nice 26.5%Idle %ozfod 27 twa0 uhci0 > > | | | | | | | | | | | daefr 2001 cpu0: time > > ===================================++ prcfr igb0 256 > > 9938 dtbuf 1247 totfr igb0 257 > > Namei Name-cache Dir-cache 100000 desvn react igb0 258 > > Calls hits % hits % 34443 numvn 1 pdwak igb0 259 > > 24996 frevn 112852 pdpgs igb0 262 > > intrn igb0 263 > > Disks da0 da1 pass0 pass1 2570672 wire igb0 264 > > KB/t 0.00 12.23 0.00 0.00 46760 act igb0 265 > > tps 0 26 0 0 14706896 inact 19449 igb1 266 > > MB/s 0.00 0.31 0.00 0.00 0 769796 26585 > > 0 21 0 0 173528 > > > > > > -greg > > > > > > > > > Machine: > > > ======= > > > > > > FreeBSD server.example.com 7.3-STABLE FreeBSD 7.3-STABLE #36: Wed Aug 25 11:01:07 CEST 2010 root@server.example.com:/usr/obj/usr/src/sys/KERNEL amd64 > > > > > > Kernel was csup'd earlier in the day on 25 August, immediately prior to > > > the build. > > > > > > > > > Panic: > > > ====== > > > > > > Fatal trap 9: general protection fault while in kernel mode > > > cpuid = 2; apic id = 02 > > > instruction pointer = 0x8:0xffffffff8052f40c > > > stack pointer = 0x10:0xffffff82056819d0 > > > frame pointer = 0x10:0xffffff82056819f0 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 65 (igb1 que) > > > trap number = 9 > > > panic: general protection fault > > > cpuid = 2 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > panic() at panic+0x182 > > > trap_fatal() at trap_fatal+0x294 > > > trap() at trap+0x106 > > > calltrap() at calltrap+0x8 > > > --- trap 0x9, rip = 0xffffffff8052f40c, rsp = 0xffffff82056819d0, rbp = 0xffffff82056819f0 --- m_tag_delete_chain() at m_tag_delete_chain+0x1c > > > uma_zfree_arg() at uma_zfree_arg+0x41 > > > m_freem() at m_freem+0x54 > > > ether_demux() at ether_demux+0x85 > > > ether_input() at ether_input+0x1bb > > > igb_rxeof() at igb_rxeof+0x29d > > > igb_handle_que() at igb_handle_que+0x9a > > > taskqueue_run() at taskqueue_run+0xac > > > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > > > fork_exit() at fork_exit+0x122 > > > fork_trampoline() at fork_trampoline+0xe > > > --- trap 0, rip = 0, rsp = 0xffffff8205681d30, rbp = 0 --- > > > Uptime: 11h57m6s > > > Physical memory: 18411 MB > > > Dumping 3770 MB: > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x8000000000 > > > fault code = supervisor write data, page not present > > > instruction pointer = 0x8:0xffffffff80188b5f > > > stack pointer = 0x10:0xffffff82056811f0 > > > frame pointer = 0x10:0xffffff82056812f0 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 65 (igb1 que) > > > trap number = 12 > > > > > > > > > pciconf: > > > ======= > > > > > > igb0@pci0:10:0:0: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 > > > vendor = 'Intel Corporation' > > > class = network > > > subclass = ethernet > > > igb1@pci0:10:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 > > > vendor = 'Intel Corporation' > > > class = network > > > subclass = ethernet > > > > > > > > > dmesg: > > > ===== > > > > > > igb0: port 0xe880-0xe89f mem 0xfbe60000-0xfbe > > > 7ffff,0xfbe40000-0xfbe5ffff,0xfbeb8000-0xfbebbfff irq 16 at device 0.0 on pci10 > > > igb0: Using MSIX interrupts with 10 vectors > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: [ITHREAD] > > > igb0: Ethernet address: 00:30:48:ca:cd:72 > > > igb1: port 0xec00-0xec1f mem 0xfbee0000-0xfbe > > > fffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff irq 17 at device 0.1 on pci10 > > > igb1: Using MSIX interrupts with 10 vectors > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: [ITHREAD] > > > igb1: Ethernet address: 00:30:48:ca:cd:73 > Adding Jack Vogel of Intel and Yong-Hyeon PYUN to the mix... > > I don't know if this is possible for you to do, but do you see the same > problem when running 8.1-STABLE? I know there has been a lot of > positive work on igb(4) in RELENG_8, but not too many of the fixes and > improvements are backported to RELENG_7. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_igb.c > > Be sure to check out Revision 1.54 there (which is for HEAD/CURRENT, > but I'm not sure if it's been backported/incorporated in some other > way). > > Otherwise, as a test/workaround you might try disabling MSI-X support > entirely to see if there's any improvement. This could degrade system > performance a bit (under heavy interrupt load). In /boot/loader.conf, > set hw.pci.enable_msix="0" and reboot. If there's no improvement, be > sure to remove this. I'd forgotten to mention it, but disabling msix does NOT help -- AT ALL; indeed, with msix disabled, the panics come FASTER. I think that I can probably move this machine to 8.1-STABLE. In fact, I have some other fileservers running 8.1-STABLE without problems (though they are only similar, not identical, and are not as heavily loaded). But I would like to have some reasonable expectation that my problem is fixed in 8-STABLE if I am going to migrate right now. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Mon Aug 30 12:22:49 2010 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 7E0F910656A9 for ; Mon, 30 Aug 2010 12:22:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 63D628FC0C for ; Mon, 30 Aug 2010 12:22:49 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 0beQ1f0061Y3wxoA2cNogR; Mon, 30 Aug 2010 12:22:48 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id 0cNn1f0053LrwQ28bcNouU; Mon, 30 Aug 2010 12:22:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 954029B425; Mon, 30 Aug 2010 05:22:47 -0700 (PDT) Date: Mon, 30 Aug 2010 05:22:47 -0700 From: Jeremy Chadwick To: Greg Byshenk Message-ID: <20100830122247.GA33429@icarus.home.lan> References: <20100830094631.GD12467@core.byshenk.net> <20100830110845.GA31629@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100830110845.GA31629@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: igb related(?) panics on 7.3-STABLE 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, 30 Aug 2010 12:22:49 -0000 On Mon, Aug 30, 2010 at 04:08:45AM -0700, Jeremy Chadwick wrote: > Bcc: > Subject: Re: igb related(?) panics on 7.3-STABLE > Reply-To: > In-Reply-To: <20100830094631.GD12467@core.byshenk.net> > {snip} My apologies -- somehow my mail client completely broke the Subject line and pulled it from another thread. I'm not quite sure how mutt managed to do that, but probably an extraneous newline when editing mail headers, e.g. PEBKAC. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Aug 30 17:23:01 2010 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 F41271065670 for ; Mon, 30 Aug 2010 17:23:00 +0000 (UTC) (envelope-from rick@rix.kiwi-computer.com) Received: from rix.kiwi-computer.com (66-191-70-202.static.stcd.mn.charter.com [66.191.70.202]) by mx1.freebsd.org (Postfix) with SMTP id 8D0BF8FC08 for ; Mon, 30 Aug 2010 17:23:00 +0000 (UTC) Received: (qmail 28044 invoked by uid 2000); 30 Aug 2010 17:22:59 -0000 Date: Mon, 30 Aug 2010 12:22:59 -0500 From: "Rick C. Petty" To: Rick Macklem Message-ID: <20100830172259.GA20421@rix.kiwi-computer.com> References: <20100829032252.GA81736@rix.kiwi-computer.com> <2002105637.244211.1283096646412.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2002105637.244211.1283096646412.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 17:23:01 -0000 On Sun, Aug 29, 2010 at 11:44:06AM -0400, Rick Macklem wrote: > > Hi. I'm still having problems with NFSv4 being very laggy on one > > client. > > When the NFSv4 server is at 50% idle CPU and the disks are < 1% busy, > > I am > > getting horrible throughput on an idle client. Using dd(1) with 1 MB > > block > > size, when I try to read a > 100 MB file from the client, I'm getting > > around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s > > with > > the same test (on a different file). On the broken client: > > Since other client(s) are working well, that seems to suggest that it > is a network related problem and not a bug in the NFS code. Well I wouldn't say "well". Every client I've set up has had this issue, and somehow through tweaking various settings and restarting nfs a bunch of times, I've been able to make it tolerable for most clients. Only one client is behaving well, and that happens to be the only machine I haven't rebooted since I enabled NFSv4. Other clients are seeing 2-3 MiB/s on my dd(1) test. I should point out that caching is an issue. The second time I run a dd on the same input file, I get upwards of 20-35 MiB/s on the "bad" client. But I can "invalidate" the cache by unmounting and remounting the file system so it looks like client-side caching. I'm not sure how you can say it's network-related and not NFS. Things worked just fine with NFSv3 (in fact NFSv3 client using the same NFSv4 server doesn't have this problem). Using rsync over ssh I get around 15-20 MiB/s throughput, and dd piped through ssh gets almost 40 MiB/s (neither one is using compression)! > First off, the obvious question: How does this client differ from the > one that performs much better? Different hardware (CPU, board, memory). I'm also hoping it was some sysctl tweak I did, but I can't seem to determine what it was. > Do they both use the same "re" network interface for the NFS traffic? > (If the answer is "no", I'd be suspicious that the "re" hardware or > device driver is the culprit.) That's the same thing you and others said about the *other* NFSv4 clients I set up. How is v4 that much different than v3 in terms of network traffic? The other clients are all using re0 and exactly the same ifconfig "options" and flags, including the client that's behaving fine. > Things that I might try in an effort to isolate the problem: > - switch the NFS traffic to use the nfe0 net interface. I'll consider it. I'm not convinced it's a NIC problem yet. > - put a net interface identical to the one on the client that > works well in the machine and use that for the NFS traffic. It's already close enough. Bad client: re0@pci0:1:7:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Single Gigabit LOM Ethernet Controller (RTL8110)' class = network subclass = ethernet Good client: re0@pci0:1:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet Mediocre client: re0@pci0:1:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet The mediocre and good clients have exactly identical hardware, and often I'll witness the "slow client" behavior on the mediocre client, and rarely on the "good client" although in previous emails to you, it was the "good client" which was behaving the worst of all. Other differences: good client = 8.1 GENERIC r210227M amd64 12GB RAM Athlon II X2 255 med. client = 8.1 GENERIC r209555M i386 4GB RAM Athlon II X2 255 bad client = 8.1 GENERIC r211534M i386 2GB RAM Athlon 64 X2 5200+ > - turn off TXCSUM and RXCSUM on re0 Tried that, didn't help although it seemed to slow things down a little. > - reduce the read/write data size, using rsize=N,wsize=N on the > mount. (It will default to MAXBSIZE and some net interfaces don't > handle large bursts of received data well. If you drop it to > rsize=8192,wszie=8192 and things improve, then increase N until it > screws up.) 8k didn't improve things at all. > - check the port configuration on the switch end, to make sure it > is also 1000bps-full duplex. It is, and has been. > - move the client to a different net port on the switch or even a > different switch (and change the cable, while you're at it). I've tried that too. The switches are great and my cables are fine. Like I said, NFSv3 on the same moint point works just fine (dd does around 30-35 MiB/s). > - Look at "netstat -s" and see if there are a lot of retransmits > going on in TCP. 2 of 40k TCP packets retransmitted, 7k of 40k duplicate acks received. I don't see anything else in "netstat -s" with numbers larger than 10. > If none of the above seems to help, you could look at a packet trace > and see what is going on. Look for TCP reconnects (SYN, SYN-ACK...) > or places where there is a large time delay/retransmit of a TCP > segment. Is that something easily scriptable with tcpdump? I'd rather not look for such things manually. > Hopefully others who are more familiar with the networking side > can suggest other things to try, rick I'm still not convinced it's a network issue. Here are some specs I tested with dd(1) on the same file on the file server, listed in the order I performed these tests: client mount first attempt second attempt ------ ----- ------------- -------------- bad NFSv3 32954968 B/s 643911087 B/s bad NFSv4 439672 B/s 6694992 B/s med. NFSv4 333837 B/s 617387 B/s med. NFSv3 95043062 B/s 1617717600 B/s good NFSv4 64276844 B/s 2488692465 B/s good NFSv3 98051629 B/s 2697787313 B/s bad NFSv4 580284 B/s 13554608 B/s It seems pretty obvious to me that v3 outperforms v4, and that there are some caching effects on the client. But even with the cache, the performance from v4 is pretty pitiful, except for one of my clients. I'm not sure what I tweaked. I'll include a diff of the relevant "sysctl -a" outputs from those two machines: --- bad client +++ good client -kern.version: FreeBSD 8.1-STABLE #5 r211534M: Sat Aug 28 15:53:10 CDT 2010 +kern.version: FreeBSD 8.1-PRERELEASE #1 r210227M: Sun Jul 18 23:24:16 CDT 2010 -kern.ipc.maxsockbuf: 1048576 +kern.ipc.maxsockbuf: 524288 -kern.ipc.max_datalen: 124 +kern.ipc.max_datalen: 92 -kern.ipc.pipekva: 114688 -kern.ipc.maxpipekva: 16777216 +kern.ipc.pipekva: 589824 +kern.ipc.maxpipekva: 207671296 -kern.ipc.numopensockets: 59 +kern.ipc.numopensockets: 202 -kern.ipc.nsfbufspeak: 5 -kern.ipc.nsfbufs: 6656 +kern.ipc.nsfbufspeak: 0 +kern.ipc.nsfbufs: 0 -kern.openfiles: 144 +kern.openfiles: 632 -kern.maxssiz: 67108864 +kern.maxssiz: 536870912 -kern.maxdsiz: 536870912 +kern.maxdsiz: 34359738368 -kern.maxbcache: 209715200 +kern.maxbcache: 0 -kern.nbuf: 7224 +kern.nbuf: 79194 -vfs.ufs.dirhash_lowmemcount: 351 +vfs.ufs.dirhash_lowmemcount: 1725 -vfs.ufs.dirhash_mem: 1123139 -vfs.freevnodes: 24960 +vfs.freevnodes: 25000 vfs.wantfreevnodes: 25000 -vfs.numvnodes: 36966 +vfs.numvnodes: 88150 -net.inet.icmp.bmcastecho: 0 +net.inet.icmp.bmcastecho: 1 -net.inet.tcp.sendspace: 65536 -net.inet.tcp.recvspace: 131072 +net.inet.tcp.sendspace: 32768 +net.inet.tcp.recvspace: 65536 -net.inet.tcp.hostcache.count: 3 +net.inet.tcp.hostcache.count: 8 -net.inet.tcp.recvbuf_max: 16777216 +net.inet.tcp.recvbuf_max: 262144 -net.inet.tcp.sendbuf_max: 16777216 +net.inet.tcp.sendbuf_max: 262144 -net.inet.tcp.reass.overflows: 0 +net.inet.tcp.reass.overflows: 1993 -net.inet.tcp.pcbcount: 16 +net.inet.tcp.pcbcount: 34 -machdep.tsc_freq: 2712350646 +machdep.tsc_freq: 3110426281 -- Rick From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 01:59:39 2010 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 EAD4C10656AC for ; Tue, 31 Aug 2010 01:59:39 +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 AC3788FC13 for ; Tue, 31 Aug 2010 01:59:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAFf+e0yDaFvO/2dsb2JhbACDFp5ErVWRfoEigyJzBIoJ X-IronPort-AV: E=Sophos;i="4.56,295,1280721600"; d="scan'208";a="90227861" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 30 Aug 2010 21:59:38 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 93BD8B3F25; Mon, 30 Aug 2010 21:59:38 -0400 (EDT) Date: Mon, 30 Aug 2010 21:59:38 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <378785023.301734.1283219978549.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100830172259.GA20421@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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, 31 Aug 2010 01:59:40 -0000 > > Well I wouldn't say "well". Every client I've set up has had this > issue, > and somehow through tweaking various settings and restarting nfs a > bunch of > times, I've been able to make it tolerable for most clients. Only one > client is behaving well, and that happens to be the only machine I > haven't > rebooted since I enabled NFSv4. Other clients are seeing 2-3 MiB/s on > my > dd(1) test. > All I can tell you is that, for my old hardware (100Mbps networking) I see 10Mbytes/sec (all you can hope for) using the regular NFSv3 client. I see about 10% slower for NFSv3 and NFSv4 using the experimental client (NFSv3 and NFSv4 about identical). The 10% doesn't surprise me, since the experimental client is based on a FreeBSD6 client and, although I plan on carrying all the newer client changes over to it, I haven't gotten around to doing that. If it is still 10% slower after the changes are carried over, I will be looking at why. I don't tune anything with sysctl, I just use what I get from an install from CD onto i386 hardware. (I don't even bother to increase kern.ipc.maxsockbuf although I suggest that in the mount message.) I also do not specify any mount options other than the protocol version. My mount commands look like: # mount -t nfs -o nfsv3 :/path /mnt # mount -t newnfs -o nfsv3 :/path /mnt So, I don't see dramatically slower NFSv4 and expect to get the 10% perf. reduction fixed when I bring the exp. client in line with the current one, but can't be sure. So, I have no idea what you are seeing. It might be an issue that will be fixed when I bring the exp. client up to date, but I have no idea if that's the case? (It will be a few months before the client update happens.) The only thing I can suggest is trying: # mount -t newnfs -o nfsv3 :/path /mnt and seeing if that performs like the regukar NFSv3 or has the perf. issue you see for NFSv4? If this does have the perf. issue, then the exp. client is most likely the cause and may get better in a few months when I bring it up-to-date. rick From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 02:24:52 2010 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 5192D1065672 for ; Tue, 31 Aug 2010 02:24:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1241F8FC16 for ; Tue, 31 Aug 2010 02:24:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABYFfEyDaFvO/2dsb2JhbACDFp5ErTSRfoEigyJzBIoJ X-IronPort-AV: E=Sophos;i="4.56,295,1280721600"; d="scan'208";a="92289825" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Aug 2010 22:24:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6F7F1B3EA3; Mon, 30 Aug 2010 22:24:50 -0400 (EDT) Date: Mon, 30 Aug 2010 22:24:50 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <257768957.302339.1283221490386.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100830172259.GA20421@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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, 31 Aug 2010 02:24:52 -0000 > On Sun, Aug 29, 2010 at 11:44:06AM -0400, Rick Macklem wrote: > > > Hi. I'm still having problems with NFSv4 being very laggy on one > > > client. > > > When the NFSv4 server is at 50% idle CPU and the disks are < 1% > > > busy, > > > I am > > > getting horrible throughput on an idle client. Using dd(1) with 1 > > > MB > > > block > > > size, when I try to read a > 100 MB file from the client, I'm > > > getting > > > around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s > > > with > > > the same test (on a different file). On the broken client: > > > > Since other client(s) are working well, that seems to suggest that > > it > > is a network related problem and not a bug in the NFS code. > Oh, one more thing...Make sure that the user and group name/number space is consistent across all machines and nfsuserd is working on them all. (Look at "ls -lg" on the clients and see that the correct user/group names are showing up.) If this mapping isn't working correctly, it will do an upcall to the userland nfsuserd for every RPC and that would make NFSv4 run very slowly. It will also use the domain part (after first '.') of each machine's hostname, so make sure that all the hostnames (all clients and server) are the same. ie: server.cis.uoguelph.ca, client1.cis.uoguelph.ca,... are all .cis.uoguelph.ca. If that is the problem # mount -t newnfs -o nfsv3 :/path /mnt will work fine, since NFSv3 doesn't use the mapping daemon. > > Is that something easily scriptable with tcpdump? I'd rather not look > for such things manually. > I've always done this manually and, although tcpdump can be used to do the packet capture, wireshark actually understands NFS packets and, as such, is much better for looking at the packets. rick From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 10:30:56 2010 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 0801210656AA for ; Tue, 31 Aug 2010 10:30:56 +0000 (UTC) (envelope-from amdmiek@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B96F38FC0C for ; Tue, 31 Aug 2010 10:30:55 +0000 (UTC) Received: by gwj23 with SMTP id 23so2850808gwj.13 for ; Tue, 31 Aug 2010 03:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=pV5NvKCgpMkLQiORT5p56snJe8/8jpXP5DYGEty60aQ=; b=DBBI8f8ZUjXVwfw3ENn0qnMQKaIcjnp/insPRIc5MzRzmSxl5pqFh1Ovxo28Od2l12 ev0mC5c5MJk3R0GDanXV8R6alKUAbNHyPxxf5bEpqbabtsWqVmE1kw2XaQ4FBxNPvN/H vCcwKGOfoNnreR9RJy0kaUVdPnCK74NpveM2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HtQMDRFNZE7PMEHwkPW/gbkmX+1WOpQboiaGUoaiOS1EPTCaWHzF5rS7tqYF57eH++ 63dotu0Ko+lTkGUJS0hgwd9tDcxRQEZ5aj2k7tIK1N1zs07bpXqU3qqG3F7J9GaMjISC O6qOXWokpDGD5NgJyIemVJcXCDB1dGcuQU+fU= MIME-Version: 1.0 Received: by 10.220.122.203 with SMTP id m11mr3514785vcr.118.1283250654814; Tue, 31 Aug 2010 03:30:54 -0700 (PDT) Received: by 10.220.194.203 with HTTP; Tue, 31 Aug 2010 03:30:54 -0700 (PDT) Date: Tue, 31 Aug 2010 14:30:54 +0400 Message-ID: From: Michael BlackHeart To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles 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, 31 Aug 2010 10:30:56 -0000 Hello I've got a problem with Broadcomm Wireless. I have notebook HP Compaq 6720s with BCM4312. I disassemblied book and saw there plugable Wireless Module but I'm lazy to do it again to werify it's ID. Windows XP drivers works fine and says that is's PCI\VEN_14E4&DEV_4312&SUBSYS_1371103C&REV_02\4&29E2C51B&0&00E1 MEMORY E4000000 - E4003FFF IRQ 17 I've tried : FreeBSD 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 And noting as i386 8.1 release. Now I'm running: FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r211991: Mon Aug 30 14:58:34 MSD 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64 With no driver attached "pciconf -l -cvb" says: none1@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART (Wireless Ethernet Adapter)' class = network bar [10] = type Memory, range 64, base 0xe4000000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) Clean install, trying bwi driver first cd /usr/ports/net/bwi-firmware-kmod && make install clean && rehash kldload bwi_ucode_v3 cd /usr/sys/src/modules/bwi make all obj depend install clean kldload if_bwi Aug 18 12:19:58 kernel: bwi0: mem 0xe4000000-0xe4003fff irq 17 at device 0.0 on pci16 Aug 18 12:19:58 kernel: bwi0: [ITHREAD] Aug 18 12:19:58 kernel: bwi0: BBP: id 0x4311, rev 0x2, pkg 0 Aug 18 12:19:58 kernel: bwi0: MAC rev 13 is not supported Aug 18 12:19:58 kernel: bwi0: no MAC was found Aug 18 12:19:58 kernel: device_attach: bwi0 attach returned 6 pciconf -l -cvb says: bwi0@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART (Wireless Ethernet Adapter)' class = network cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) now rebooting 'cos even after kldunloading if_bwi module it's still lists in pciconfand trying bwn cd /usr/ports/net/bwn-firmware-kmod && make install clean && rehash kldload bwn_v4_ucode.ko kldload if_bwn pciconf -l -cvb says: siba_bwn0: mem 0xe4000000-0xe4003fff irq 17 at device 0.0 on pci16 siba_bwn0: unsupported coreid (USB 1.1 Host) bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4311 rev 13) PHY (analog 4 type 2 rev 9) RADIO (manuf 0x17f ver 0x2050 rev 2) bwn0: DMA (64 bits) bwn0: Using 1 MSI messages bwn0: [FILTER] siba_bwn0@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART (Wireless Ethernet Adapter)' class = network bar [10] = type Memory, range 64, base 0xe4000000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) ifconfig bwn0 up scan bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) ifconfig: unable to get scan results bwn0: status of RF switch is changed to OFF book have a switch to turn on/off all radio and it's always on. also when i'm switching it FreeBSD says nothing Also I tried acpi_hp - no sense And i didn't find any apropriate in sysctl Moving next - ndis I've tried couple of drivers With WinXP that running on drivers v. VERSION: 7.10 REV: B from sp41680 And OS goes to kernel panic just when I kldloaded it. No dump, sorry, but I don't think that it matters a thing Another one - VERSION: 6.10 REV: A from sp34152 works a bit better It converts and loads without panic but in debug: kldload bcmwl564_sys.ko ndis0: mem 0xe4000000-0xe4003fff irq 17 at device 0. 0 on pci16 ndis0: [ITHREAD] ndis0: NDIS API version: 5.1 fpudna in kernel mode! pciconf -lcvb says: ndis0@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART (Wireless Ethernet Adapter)' class = network bar [10] = type Memory, range 64, base 0xe4000000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) ifconfig says: ndis0: flags=8802 metric 0 mtu 2290 ether 00:21:00:43:56:0e media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier and everything doesn't work again. I think this as all info I can get, huh. I've got only two questions: 1)Is there a way to determine what exactly microcode uses Windows Driver (There's no info in devmgmgt.msc or I just don't get that it's info I'm looking for) 2)Have u got any advices to me how to get it all working? From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 12:00:50 2010 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 CA74D1065866 for ; Tue, 31 Aug 2010 12:00:50 +0000 (UTC) (envelope-from ds@chaos.ukrhub.net) Received: from chaos.ukrhub.net (chaos.ukrhub.net [212.90.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8920F8FC25 for ; Tue, 31 Aug 2010 12:00:50 +0000 (UTC) Received: by chaos.ukrhub.net (Postfix, from userid 1000) id 8CE50410F; Tue, 31 Aug 2010 14:44:28 +0300 (EEST) Date: Tue, 31 Aug 2010 14:44:28 +0300 From: Taras Korenko To: Michael BlackHeart Message-ID: <20100831114428.GA96964@chaos.ukrhub.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Taras Korenko List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 12:00:50 -0000 On Tue, Aug 31, 2010 at 02:30:54PM +0400, Michael BlackHeart wrote: > Hello > > I've got a problem with Broadcomm Wireless. > I have notebook HP Compaq 6720s with BCM4312. > [...] > ifconfig bwn0 up scan > bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) > ifconfig: unable to get scan results > [...] Why don't you try to play with wlan(4) on top of bwi/bwn? An example is here: handbook / 31.3.3.1.1 How to Find Access Points. -- Best regards, Taras Korenko From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 13:35:44 2010 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 E249610656AB for ; Tue, 31 Aug 2010 13:35:44 +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 70D8E8FC13 for ; Tue, 31 Aug 2010 13:35:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A3A0B46B23; Tue, 31 Aug 2010 09:35:43 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 38F448A03C; Tue, 31 Aug 2010 09:35:31 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, Taras Korenko Date: Tue, 31 Aug 2010 09:20:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100831114428.GA96964@chaos.ukrhub.net> In-Reply-To: <20100831114428.GA96964@chaos.ukrhub.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Message-Id: <201008310920.49730.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 31 Aug 2010 09:35:31 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Michael BlackHeart Subject: Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles 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, 31 Aug 2010 13:35:45 -0000 On Tuesday, August 31, 2010 7:44:28 am Taras Korenko wrote: > On Tue, Aug 31, 2010 at 02:30:54PM +0400, Michael BlackHeart wrote: > > Hello > > > > I've got a problem with Broadcomm Wireless. > > I have notebook HP Compaq 6720s with BCM4312. > > [...] > > > ifconfig bwn0 up scan > > bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) > > ifconfig: unable to get scan results > > [...] > > Why don't you try to play with wlan(4) on top of bwi/bwn? > An example is here: handbook / 31.3.3.1.1 How to Find Access Points. Yes, even with ndis (which is what I use for this adapter, albeit on i386), you have to use wlan. (ndis on i386 will not have the 'fpudna' issues since 32-bit Windows drivers do not use SSE instructions.) Even with ndis I have to run ndis_events for WPA auth to work FWIW. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 13:35:53 2010 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 8367D10656B7 for ; Tue, 31 Aug 2010 13:35:53 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 187388FC27 for ; Tue, 31 Aug 2010 13:35:53 +0000 (UTC) Received: from [2a01:348:132:51::10] (helo=carrick-users) by carrick.bishnet.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqR0G-0006nV-MX; Tue, 31 Aug 2010 14:35:56 +0100 Received: (from tdb@localhost) by carrick-users (8.14.4/8.14.4/Submit) id o7VDZumZ026132; Tue, 31 Aug 2010 14:35:56 +0100 (BST) (envelope-from tdb) Date: Tue, 31 Aug 2010 14:35:56 +0100 From: Tim Bishop To: Dan Nelson Message-ID: <20100831133556.GB45316@carrick-users.bishnet.net> References: <20100821220435.GA6208@carrick-users.bishnet.net> <20100821222429.GB73221@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100821222429.GB73221@dan.emsphone.com> X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1R ZFS almost locking up system 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, 31 Aug 2010 13:35:53 -0000 On Sat, Aug 21, 2010 at 05:24:29PM -0500, Dan Nelson wrote: > In the last episode (Aug 21), Tim Bishop said: > > A few items from top, including zfskern: > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 5 root 4 -8 - 0K 60K zio->i 0 54:38 3.47% zfskern > > 91775 70 1 44 0 53040K 31144K tx->tx 1 2:11 0.00% postgres > > 39661 tdb 1 44 0 55776K 32968K tx->tx 0 0:39 0.00% mutt > > 14828 root 1 47 0 14636K 1572K tx->tx 1 0:03 0.00% zfs > > 11188 root 1 51 0 14636K 1572K tx->tx 0 0:03 0.00% zfs > > > > At some point during this process my zfs snapshots have been failing to > > complete: > > > > root 5 0.8 0.0 0 60 ?? DL 7Aug10 54:43.83 [zfskern] > > root 8265 0.0 0.0 14636 1528 ?? D 10:00AM 0:03.12 zfs snapshot -r pool0@2010-08-21_10:00:01--1d > > root 11188 0.0 0.1 14636 1572 ?? D 11:00AM 0:02.93 zfs snapshot -r pool0@2010-08-21_11:00:01--1d > > root 14828 0.0 0.1 14636 1572 ?? D 12:00PM 0:03.04 zfs snapshot -r pool0@2010-08-21_12:00:00--1d > > root 17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs snapshot -r pool0@2010-08-21_13:00:01--1d > > root 20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs snapshot -r pool0@2010-08-21_14:00:01--1d > > procstat -k on some of these processes might help to pinpoint what part of > the zfs code they're all waiting in. It happened again this Saturday (clearly something in the weekly periodic run is triggering the issue). procstat -kk shows the following for processes doing something zfs related (where zfs related means the string 'zfs' in the procstat -kk output): 0 100084 kernel zfs_vn_rele_task mi_switch+0x16f sleepq_wait+0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_trampoline+0xe 5 100031 zfskern arc_reclaim_thre mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 fork_exit+0x118 fork_trampoline+0xe 5 100032 zfskern l2arc_feed_threa mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be fork_exit+0x118 fork_trampoline+0xe 5 100085 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_exit+0x118 fork_trampoline+0xe 5 100086 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea spa_sync+0x355 txg_sync_thread+0x195 fork_exit+0x118 fork_trampoline+0xe 17 100040 syncer - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_sync+0xa6 sync_fsync+0x184 sync_vnode+0x16b sched_sync+0x1c9 fork_exit+0x118 fork_trampoline+0xe 2210 100156 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 3500 100177 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 3783 100056 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 4064 100165 mysqld initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 4441 100224 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 4444 100227 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 4445 100228 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 4446 100229 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 4447 100089 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 5352 100270 mutt - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_freebsd_fsync+0xd7 null_bypass+0xd3 fsync+0x161 syscall+0x1e7 Xfast_syscall+0xe1 52686 100200 tarsnap - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 59049 100207 webalizer initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_pwritev+0x63 pwrite+0x59 syscall+0x1e7 Xfast_syscall+0xe1 77573 100479 perl - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 write+0x55 syscall+0x1e7 Xfast_syscall+0xe1 78595 100275 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 81989 100596 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 I'm not sure if this shows anything useful? Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 13:37:17 2010 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 DF3FB10656A7 for ; Tue, 31 Aug 2010 13:37:16 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id 367998FC26 for ; Tue, 31 Aug 2010 13:37:16 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id CC2779F317 for ; Tue, 31 Aug 2010 15:22:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id y5wSV8fvei24 for ; Tue, 31 Aug 2010 15:21:58 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 1D8A39F300 for ; Tue, 31 Aug 2010 15:21:58 +0200 (CEST) Message-ID: <4C7D01F7.4010003@zirakzigil.org> Date: Tue, 31 Aug 2010 15:21:59 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100621 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: About zfs + nfs stability 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, 31 Aug 2010 13:37:17 -0000 I have a 8.0 stable (last build around April 2010) which I use as a nfs server : amd64, 8GB RAM, ~7TB storage. I had a lot of grief with the (sadly) well know "kmem map too small" bug, which really compromised the quality of the service that server was deputed to. There wasn't (and there still isn't) any relevant indication in the official freebsd zfs documentation on how to bypass the problem. Only thanks to the effort and goodwill of other users in this list and with hours on end of trying, I could come up with something working: (in /boot/loader.conf) vm.kmem_size="6096M" vfs.zfs.arc_max="3584M" vfs.zfs.prefetch_disable="1" vfs.zfs.txg.timeout="5" The freezes are gone, thankfully, but I often get huge slow-downs: looking in the logs of the nfs clients I get plenty of: ... kernel: nfs server ...:/path/to/dir: lockd not responding ... kernel: nfs server ...:/path/to/dir: lockd is alive again I don't know if this has anything to do with zfs. What I'd like to know is the answer to the following questions by other users and/or developers. I don't need opinions, only punctual facts people have verified for themselves. 1) Is it a good idea to upgrade this production system to the latest 8 stable (8.1 stable I believe)? Is it really stable? 2) Are the zfs aforementioned tuning in /boot/loader.conf still necessary? 3) Is it a good idea to switch to nfsv4? Performance? Stability? and above all: 4) will I get a more stable and performant system by upgrading? Thanks in advance for the answers... From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 15:19:31 2010 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 402C610656A6 for ; Tue, 31 Aug 2010 15:19:31 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4D18FC14 for ; Tue, 31 Aug 2010 15:19:30 +0000 (UTC) Received: by pvg4 with SMTP id 4so2915105pvg.13 for ; Tue, 31 Aug 2010 08:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=a+XRrGnMB4f8zPe2+XMSxOSdfEt/QzMaNAP401Zldmc=; b=wKsySW3FkC+sOeKkr8faf4lJHfRwwIoB6HqJhMlMpa1CH+xjcp0Z5/vlOVaBaEC2Xm Vi22Gsp92PKAeQsu2+N9paEBIwht2RLWOARA1vqhQWkZjNUGRGFhnKDHYieYtBED+l5F 5Bnq4lFkeUm/yGZMV9D0JxtUl0x0yC0T24WmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=Fc2ttGGGk0+YttuhRn0xu93CzoFg7SnhDFRaZ2Dtx00F4n90ZfnINx9c0qXRT/KNov GF75cWCg1pyPeW4Cs0jHNgaThKIMCxeZGaxm12dyUo0Okq5Pnod7zWfGdp5brnC7GsXX 7MkmwqN5jkZ/nexOlLxhKxWGgKERKl0BC2ir4= Received: by 10.142.44.14 with SMTP id r14mr6095452wfr.76.1283267970431; Tue, 31 Aug 2010 08:19:30 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id n20sm8896338ibe.23.2010.08.31.08.19.28 (version=SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 08:19:29 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C7D1D7F.709@DataIX.net> Date: Tue, 31 Aug 2010 11:19:27 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Giulio Ferro References: <4C7D01F7.4010003@zirakzigil.org> In-Reply-To: <4C7D01F7.4010003@zirakzigil.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------040408020704020505010009" Cc: freebsd-stable@freebsd.org Subject: Re: About zfs + nfs stability 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, 31 Aug 2010 15:19:31 -0000 This is a multi-part message in MIME format. --------------040408020704020505010009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/31/2010 09:21, Giulio Ferro wrote: > 1) Is it a good idea to upgrade this production system to the latest 8 > stable (8.1 stable I believe)? Is it really stable? For this question alone, I can verify that it is stable to upgrade to the stable branch. Though on one hand it might be reasonable for you to locally merge changes from the two points of CDDL into your source tree. Example: (Tested here) cd /usr/src svn merge svn://svn.freebsd.org/base/stable/8/cddl cddl svn merge svn://svn.freebsd.org/base/stable/8/sys/cddl sys/cddl If you do not have any local changes to your source tree for those parts of the branch then you should not have any problems or conflicts upon merge & this will bring your system up-to-date with ZFSv14 in stable/8. Another route if you use CVS would be to checkout the source tree using Subversion and diff it locally but you should still end up with the same result. There are a few patches that I can recommend but they are for stable/8 that has been patched with ZFSv15 that is due to be committed some time in September - November. Patches and descriptions below. And attached is a UMA patch for the VFS subsystem that helps a little with performance but not near as much as the patches below. http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch http://people.freebsd.org/~mm/patches/zfs/zfs_metaslab.patch http://people.freebsd.org/~mm/patches/zfs/zfs_abe_stat_rrwlock.patch And for the better performance question by upgrading... that is a real hard question to answer not knowing your hardware implementation. There really has not been that much of a performance increase that I can account for regarding stable/8 vs. releng/8.1, or at least not yet. PS: I have done minimal testing for V4: /nfs either my understanding of it or the way it is setup to work is somewhat confusing but this is only with very little knowledge of NFSv4 so please only take this as opinion but I would not upgrade a production system to use V4: /nfs quite yet unless the need demands it. Regards & Good Luck, -- jhell,v --------------040408020704020505010009 Content-Type: text/plain; name="uma.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="uma.patch" diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c index 2dcd14f..ed07ecb 100644 --- a/sys/vm/uma_core.c +++ b/sys/vm/uma_core.c @@ -2727,14 +2727,26 @@ zone_free_item(uma_zone_t zone, void *item, void *udata, } MPASS(keg == slab->us_keg); - /* Do we need to remove from any lists? */ + /* Move to the appropriate list or re-queue further from the head. */ if (slab->us_freecount+1 == keg->uk_ipers) { + /* Partial -> free. */ LIST_REMOVE(slab, us_link); LIST_INSERT_HEAD(&keg->uk_free_slab, slab, us_link); } else if (slab->us_freecount == 0) { + /* Full -> partial. */ LIST_REMOVE(slab, us_link); LIST_INSERT_HEAD(&keg->uk_part_slab, slab, us_link); } + else { + /* Partial -> partial. */ + uma_slab_t tmp; + + tmp = LIST_NEXT(slab, us_link); + if (tmp != NULL && slab->us_freecount > tmp->us_freecount) { + LIST_REMOVE(slab, us_link); + LIST_INSERT_AFTER(tmp, slab, us_link); + } + } /* Slab management stuff */ freei = ((unsigned long)item - (unsigned long)slab->us_data) --------------040408020704020505010009-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 15:28:48 2010 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 D3C1510656AA for ; Tue, 31 Aug 2010 15:28:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9018C8FC21 for ; Tue, 31 Aug 2010 15:28:48 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAB69fEyDaFvO/2dsb2JhbACDGJ4vrRKSJIEigyJzBIoR X-IronPort-AV: E=Sophos;i="4.56,298,1280721600"; d="scan'208";a="92351997" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 31 Aug 2010 11:28:46 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CA703B3E95; Tue, 31 Aug 2010 11:28:46 -0400 (EDT) Date: Tue, 31 Aug 2010 11:28:46 -0400 (EDT) From: Rick Macklem To: Giulio Ferro Message-ID: <332176575.321479.1283268526770.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4C7D01F7.4010003@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-stable@freebsd.org Subject: Re: About zfs + nfs stability 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, 31 Aug 2010 15:28:48 -0000 > > The freezes are gone, thankfully, but I often get huge slow-downs: > looking in the logs of the nfs clients I get plenty of: > ... kernel: nfs server ...:/path/to/dir: lockd not responding > ... kernel: nfs server ...:/path/to/dir: lockd is alive again > If you don't need file locking to work across multiple clients concurrently (ie. multiple clients aren't locking the same file at the same time), then you can avoid the NLM by using the "nolockd" mount option on the clients. (Linux has a similar mount option under a different name.) > I don't know if this has anything to do with zfs. I don't believe it has anything to do with zfs. The NLM is a separate protocol from NFS. > 3) Is it a good idea to switch to nfsv4? Performance? Stability? > NFSv4 will provide better file locking (if you need that) imho, but is still considered experimental, so it is hard to say how well it will work for you. Some seem to use it without difficulties, whereas others have problems. There is a recent unresolved thread where a guy has perf. problems on some of his clients, but not all. rick From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 15:58:31 2010 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 A0F881065782 for ; Tue, 31 Aug 2010 15:58:31 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 590B18FC0C for ; Tue, 31 Aug 2010 15:58:31 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o7VFwUZw093570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2010 10:58:30 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o7VFwUb1054518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2010 10:58:30 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o7VFwTxN054480; Tue, 31 Aug 2010 10:58:29 -0500 (CDT) (envelope-from dan) Date: Tue, 31 Aug 2010 10:58:29 -0500 From: Dan Nelson To: Tim Bishop Message-ID: <20100831155829.GC5913@dan.emsphone.com> References: <20100821220435.GA6208@carrick-users.bishnet.net> <20100821222429.GB73221@dan.emsphone.com> <20100831133556.GB45316@carrick-users.bishnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100831133556.GB45316@carrick-users.bishnet.net> X-OS: FreeBSD 8.1-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Tue, 31 Aug 2010 10:58:30 -0500 (CDT) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1R ZFS almost locking up system 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, 31 Aug 2010 15:58:31 -0000 In the last episode (Aug 31), Tim Bishop said: > On Sat, Aug 21, 2010 at 05:24:29PM -0500, Dan Nelson wrote: > > In the last episode (Aug 21), Tim Bishop said: > > > A few items from top, including zfskern: > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > > 5 root 4 -8 - 0K 60K zio->i 0 54:38 3.47% zfskern > > > 91775 70 1 44 0 53040K 31144K tx->tx 1 2:11 0.00% postgres > > > 39661 tdb 1 44 0 55776K 32968K tx->tx 0 0:39 0.00% mutt > > > 14828 root 1 47 0 14636K 1572K tx->tx 1 0:03 0.00% zfs > > > 11188 root 1 51 0 14636K 1572K tx->tx 0 0:03 0.00% zfs > > > > > > At some point during this process my zfs snapshots have been failing to > > > complete: > > > > > > root 5 0.8 0.0 0 60 ?? DL 7Aug10 54:43.83 [zfskern] > > > root 8265 0.0 0.0 14636 1528 ?? D 10:00AM 0:03.12 zfs snapshot -r pool0@2010-08-21_10:00:01--1d > > > root 11188 0.0 0.1 14636 1572 ?? D 11:00AM 0:02.93 zfs snapshot -r pool0@2010-08-21_11:00:01--1d > > > root 14828 0.0 0.1 14636 1572 ?? D 12:00PM 0:03.04 zfs snapshot -r pool0@2010-08-21_12:00:00--1d > > > root 17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs snapshot -r pool0@2010-08-21_13:00:01--1d > > > root 20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs snapshot -r pool0@2010-08-21_14:00:01--1d > > > > procstat -k on some of these processes might help to pinpoint what part of > > the zfs code they're all waiting in. > > It happened again this Saturday (clearly something in the weekly > periodic run is triggering the issue). procstat -kk shows the following > for processes doing something zfs related (where zfs related means the > string 'zfs' in the procstat -kk output): > > 0 100084 kernel zfs_vn_rele_task mi_switch+0x16f sleepq_wait+0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_trampoline+0xe > 5 100031 zfskern arc_reclaim_thre mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 fork_exit+0x118 fork_trampoline+0xe > 5 100032 zfskern l2arc_feed_threa mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be fork_exit+0x118 fork_trampoline+0xe > 5 100085 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_exit+0x118 fork_trampoline+0xe > 5 100086 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea spa_sync+0x355 txg_sync_thread+0x195 fork_exit+0x118 fork_trampoline+0xe > 17 100040 syncer - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_sync+0xa6 sync_fsync+0x184 sync_vnode+0x16b sched_sync+0x1c9 fork_exit+0x118 fork_trampoline+0xe > 2210 100156 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > 3500 100177 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > 3783 100056 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > 4064 100165 mysqld initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 > 4441 100224 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > 4444 100227 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > 4445 100228 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > 4446 100229 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > 4447 100089 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > 5352 100270 mutt - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_freebsd_fsync+0xd7 null_bypass+0xd3 fsync+0x161 syscall+0x1e7 Xfast_syscall+0xe1 > 52686 100200 tarsnap - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 > 59049 100207 webalizer initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_pwritev+0x63 pwrite+0x59 syscall+0x1e7 Xfast_syscall+0xe1 > 77573 100479 perl - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 write+0x55 syscall+0x1e7 Xfast_syscall+0xe1 > 78595 100275 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 > 81989 100596 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 > > I'm not sure if this shows anything useful? All your userland processes are basically waiting for the kernel to finish writing a ZFS transaction group to disk. mutt has called fsync, which may have been the trigger. Usually writing a transaction group is fast, though, because ZFS will batch up all the new data into one contiguous block and write it at full speed to disk. That's why I asked about full filesystems before, since if your FS has been near 99%, you may not have any large runs of freespace left. I noticed in your original post: capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- pool0 117G 16.7G 248 114 865K 269K mirror 117G 16.7G 248 114 865K 269K ad4s3 - - 43 56 2.47M 269K ad6s3 - - 39 56 2.41M 269K ---------- ----- ----- ----- ----- ----- ----- # gstat ... L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1 48 48 3042 9.8 0 0 0.0 47.6| ad4 0 38 38 2406 10.5 0 0 0.0 39.5| ad6 You have a pair of mirrored disks, each doing around 40% I/O load, which is 80% load if a single-threaded task is driving all the I/O. I see the syncer process is also trying to write to the ZIL. Are you running something that does a lot of fsync calls (a database server for example)? Is this system an NFS server maybe? Try setting the sysctl vfs.zfs.zil_disable=1 and see if your performance improves. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 18:08:50 2010 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 8B79210656AB for ; Tue, 31 Aug 2010 18:08:50 +0000 (UTC) (envelope-from amdmiek@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2ACD48FC1D for ; Tue, 31 Aug 2010 18:08:49 +0000 (UTC) Received: by vws7 with SMTP id 7so6590379vws.13 for ; Tue, 31 Aug 2010 11:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=A58sJITWqV8quNeAciba/4m4RiiDDuXB/r85t6xol9E=; b=bHN7kPkPpo8BPF+kauf1qerb1ietH+vUeN7Remi2fZNmEJQTJUDYCEtR7TV4dtHiuG GQiStmEqqPG4YI6QEg5/hPnx7msgc8LOD4MEEJU9YVq2oV9LcbeCD6yRmvk6NZJR4uyv qNyai/4OhsDO34AgnLApjgoIX/BEPLzN93f1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cWpYlGh5mLolUmuu6EWnhGlrja3olSeT9jorFo+rNIXGHrR3BruRpEWWuq9lg/6oxz fOUhwEeAXeKXL2SZpWfakEYEa7tYbbPWKNHLfKuFaHlvWMIihv8UlvVFWj/Wa9zX8Hzv +6qOn2KILbrfXR8EmhyrIjLAXA3wTW+eUyPnA= MIME-Version: 1.0 Received: by 10.220.60.13 with SMTP id n13mr3312305vch.51.1283278129264; Tue, 31 Aug 2010 11:08:49 -0700 (PDT) Received: by 10.220.194.203 with HTTP; Tue, 31 Aug 2010 11:08:49 -0700 (PDT) In-Reply-To: <201008310920.49730.jhb@freebsd.org> References: <20100831114428.GA96964@chaos.ukrhub.net> <201008310920.49730.jhb@freebsd.org> Date: Tue, 31 Aug 2010 22:08:49 +0400 Message-ID: From: Michael BlackHeart To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles 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, 31 Aug 2010 18:08:50 -0000 > Why don't you try to play with wlan(4) on top of bwi/bwn? > An example is here: handbook / 31.3.3.1.1 How to Find Access Points. wlan appeared in 7.2 or 7.3 and 8.0 as I remember and I always thought that it's just a matter of security and easy maintaining and probably multi-wlan routing. In a real daily usage I use it as well, for example it works great on my server, but I guess it doesn't matter for a testing hardware, does it? > Yes, even with ndis (which is what I use for this adapter, albeit on i386), > you have to use wlan. (ndis on i386 will not have the 'fpudna' issues since > 32-bit Windows drivers do not use SSE instructions.) Even with ndis I have to > run ndis_events for WPA auth to work FWIW. I've tried i386 as well with ndis and it doesn't make a sense. Could you please tell me the driver version you use, it's SP number if it's official HP driver, or link to download the one you have to work with. And a link how to use ndis_events will be great, I've never try this one. Thanks From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 18:37:55 2010 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 5943D10656AB; Tue, 31 Aug 2010 18:37:55 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E75E8FC14; Tue, 31 Aug 2010 18:37:55 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o7VIbs83016757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Aug 2010 11:37:54 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id F27CF1CC3A; Tue, 31 Aug 2010 11:37:53 -0700 (PDT) To: Michael BlackHeart In-reply-to: Your message of "Tue, 31 Aug 2010 22:08:49 +0400." Date: Tue, 31 Aug 2010 11:37:53 -0700 From: "Kevin Oberman" Message-Id: <20100831183753.F27CF1CC3A@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-31_10:2010-08-31, 2010-08-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008310084 Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles 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, 31 Aug 2010 18:37:55 -0000 > Date: Tue, 31 Aug 2010 22:08:49 +0400 > From: Michael BlackHeart > Sender: owner-freebsd-stable@freebsd.org > > > Why don't you try to play with wlan(4) on top of bwi/bwn? > > An example is here: handbook / 31.3.3.1.1 How to Find Access Points. > > wlan appeared in 7.2 or 7.3 and 8.0 as I remember and I always thought that > it's just a matter of security and easy maintaining and probably multi-wlan > routing. In a real daily usage I use it as well, for example it works great > on my server, but I guess it doesn't matter for a testing hardware, does it? Sorry, but wlan(4) is now mandatory for all wireless cards. wlans_ath0="wlan0" ifconfig_wlan0="inet 192.168.0.7/24 wepkey 1:SECRET ssid mylan weptxkey 1 wepmode on mode 11g -bgscan" -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 20:46:26 2010 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 06F6910656AA for ; Tue, 31 Aug 2010 20:46:26 +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 C84358FC1F for ; Tue, 31 Aug 2010 20:46:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 485E146B4C; Tue, 31 Aug 2010 16:46:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 62EE68A04E; Tue, 31 Aug 2010 16:46:24 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 31 Aug 2010 16:44:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201008310920.49730.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008311644.37434.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 31 Aug 2010 16:46:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Michael BlackHeart Subject: Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles 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, 31 Aug 2010 20:46:26 -0000 On Tuesday, August 31, 2010 2:08:49 pm Michael BlackHeart wrote: > > Why don't you try to play with wlan(4) on top of bwi/bwn? > > An example is here: handbook / 31.3.3.1.1 How to Find Access Points. > > wlan appeared in 7.2 or 7.3 and 8.0 as I remember and I always thought that > it's just a matter of security and easy maintaining and probably multi-wlan > routing. In a real daily usage I use it as well, for example it works great > on my server, but I guess it doesn't matter for a testing hardware, does it? As others have noted, wlan devices are mandatory. > > Yes, even with ndis (which is what I use for this adapter, albeit on > i386), > > you have to use wlan. (ndis on i386 will not have the 'fpudna' issues > since > > 32-bit Windows drivers do not use SSE instructions.) Even with ndis I > have to > > run ndis_events for WPA auth to work FWIW. > > I've tried i386 as well with ndis and it doesn't make a sense. Could you > please tell me the driver version you use, it's SP number if it's official > HP driver, or link to download the one you have to work with. And a link how > to use ndis_events will be great, I've never try this one. Hmm, I downloaded the driver over a year ago. The INF file is UTF-16 or some such which I cannot parse by hand very easily. It is just called 'bcmwl5' and the driver copyright is 1998-2008 Broadcom. For ndis_events you just need to run it without any arguments. I think you can run it after wpa_supplicant has been started. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 21:02:32 2010 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 881171065698 for ; Tue, 31 Aug 2010 21:02:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 469D08FC15 for ; Tue, 31 Aug 2010 21:02:32 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7VL2N2s061575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2010 17:02:23 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7VL2MJr000894 for ; Tue, 31 Aug 2010 17:02:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008312102.o7VL2MJr000894@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Aug 2010 17:02:20 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Subject: if_rtdel: error 47 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, 31 Aug 2010 21:02:32 -0000 On a RELENG_8 box from aug 25th, I started seeing a constant spew of Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47 Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:29 gate8 last message repeated 2 times Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:37 gate8 last message repeated 2 times Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:38 gate8 last message repeated 2 times What do they mean and how can I find the cause of it ? The box acts as an LNS with about 700 ng interfaces with mpd5.5. ipv6 is enabled on this server as well, so I am guessing it might be related to ipv6 as I havent seen it on the other LNS boxes that have the same setup, except no ipv6. It was happily running for a few days until this error started showing up ? The error seems to be in sys/if.c if_rtdel(struct radix_node *rn, void *arg) { struct rtentry *rt = (struct rtentry *)rn; struct ifnet *ifp = arg; int err; if (rt->rt_ifp == ifp) { /* * Protect (sorta) against walktree recursion problems * with cloned routes */ if ((rt->rt_flags & RTF_UP) == 0) return (0); err = rtrequest_fib(RTM_DELETE, rt_key(rt), rt->rt_gateway, rt_mask(rt), rt->rt_flags|RTF_RNH_LOCKED, (struct rtentry **) NULL, rt->rt_fibnum); if (err) { log(LOG_WARNING, "if_rtdel: error %d\n", err); } } return (0); } ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 21:44:39 2010 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 69CF51065673 for ; Tue, 31 Aug 2010 21:44:39 +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 52BB58FC15 for ; Tue, 31 Aug 2010 21:44:39 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 105P1f0011u4NiLA89keo7; Tue, 31 Aug 2010 21:44:38 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta21.emeryville.ca.mail.comcast.net with comcast id 19ke1f0073LrwQ28h9keiL; Tue, 31 Aug 2010 21:44:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E32389B425; Tue, 31 Aug 2010 14:44:37 -0700 (PDT) Date: Tue, 31 Aug 2010 14:44:37 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100831214437.GA81938@icarus.home.lan> References: <201008312102.o7VL2MJr000894@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008312102.o7VL2MJr000894@lava.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: if_rtdel: error 47 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, 31 Aug 2010 21:44:39 -0000 On Tue, Aug 31, 2010 at 05:02:20PM -0400, Mike Tancsa wrote: > On a RELENG_8 box from aug 25th, I started seeing a constant spew of > > Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47 > Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:29 gate8 last message repeated 2 times > Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:37 gate8 last message repeated 2 times > Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:38 gate8 last message repeated 2 times > > What do they mean and how can I find the cause of it ? [...] src/sys/net/if.c 1371 err = rtrequest_fib(RTM_DELETE, rt_key(rt), rt->rt_gateway, 1372 rt_mask(rt), rt->rt_flags|RTF_RNH_LOCKED, 1373 (struct rtentry **) NULL, rt->rt_fibnum); 1374 if (err) { 1375 log(LOG_WARNING, "if_rtdel: error %d\n", err); 1376 } Now looking for return() values in rtrequest_fib(): src/sys/net/route.c 745 int 746 rtrequest_fib(int req, ... 756 if (dst->sa_len == 0) 757 return(EINVAL); ... 764 return rtrequest1_fib(req, &info, ret_nrt, fibnum); 765 } And on to rtrequest1_fib, which has a ton of error conditions which can be returned (some natively, some from other functions like rn_mpath_update(), plus a fun macro in use (senderr)). A lot of this code is #ifdef'd too, based on routing features (FLOWTABLE, RADIX_MPATH) that are defined. Direct values that rtrequest1_fib() returns in whatever circumstance: n/a = 0 = no error EAFNOSUPPORT = 47 = Address family not supported by protocol family EINVAL = 22 = Invalid argument ESRCH = 3 = No such process ENOBUFS = 55 = No buffer space available EEXIST = 17 = File exists EOPNOTSUPP = 45 = Operation not supported Functions that rtrequest1_fib() calls whose error codes are passed directly via return() or senderr: rn_mpath_update() = can return 0 (success) or ESRCH rt_getifa_fib() = can return 0 (success) or 51 (ENETUNREACH) rt_setgate() = can return 0 (success) or ENOBUFS So in summary, your error 47 would be the result of code inside of rtrequest1_fib() itself (someone will need to look at that), while your error 3 could be caused by rtequest1_fib() or rn_mpath_update(). I have no familiarity with this code, so someone familiar with the networking layer will have to help. freebsd-net or freebsd-hackers might be worthwhile. Possibly your machine acts as a forwarding gateway and isn't able to properly route/forward/process certain kinds of packets? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 02:19:42 2010 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 DD5B01065698 for ; Wed, 1 Sep 2010 02:19:42 +0000 (UTC) (envelope-from frank@zzattack.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 693A28FC15 for ; Wed, 1 Sep 2010 02:19:42 +0000 (UTC) Received: by ewy4 with SMTP id 4so4492289ewy.13 for ; Tue, 31 Aug 2010 19:19:41 -0700 (PDT) Received: by 10.213.52.5 with SMTP id f5mr10341269ebg.35.1283305899591; Tue, 31 Aug 2010 18:51:39 -0700 (PDT) Received: from [10.31.45.197] (21-78-ftth.onsneteindhoven.nl [88.159.78.21]) by mx.google.com with ESMTPS id v8sm15122589eeh.14.2010.08.31.18.51.37 (version=SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 18:51:38 -0700 (PDT) Message-ID: <4C7DB18F.5030501@zzattack.org> Date: Wed, 01 Sep 2010 03:51:11 +0200 From: Frank Razenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: kernel panic when accessing /dev/tap0 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: Wed, 01 Sep 2010 02:19:42 -0000 Hi, Robert Watson described a problem in this discussion: http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025880.html Currently I'm experiencing a similar problem, but on amd64 and FreeBSD 8.1 Release. Accessing /dev/tap0 instantly results in a kernel panic, so it's most likely if_tap related. Is this a known problem? I've started encountering it ever since I rebuilt my kernel with "options vimage". Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x28 If more debugging information is required I will gladly provide it. Frank Razenberg From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 07:21:51 2010 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 C05F710656B7; Wed, 1 Sep 2010 07:21:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 447E88FC17; Wed, 1 Sep 2010 07:21:51 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o817LmIF028225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2010 03:21:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.4/8.14.4) with ESMTP id o817LmUo043184; Wed, 1 Sep 2010 03:21:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 50CC01B5060; Wed, 1 Sep 2010 03:21:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100901072148.50CC01B5060@freebsd-stable.sentex.ca> Date: Wed, 1 Sep 2010 03:21:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 07:21:51 -0000 TB --- 2010-09-01 05:39:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-09-01 05:39:04 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2010-09-01 05:39:04 - cleaning the object tree TB --- 2010-09-01 05:39:33 - cvsupping the source tree TB --- 2010-09-01 05:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2010-09-01 05:39:43 - building world TB --- 2010-09-01 05:39:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 05:39:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 05:39:43 - TARGET=amd64 TB --- 2010-09-01 05:39:43 - TARGET_ARCH=amd64 TB --- 2010-09-01 05:39:43 - TZ=UTC TB --- 2010-09-01 05:39:43 - __MAKE_CONF=/dev/null TB --- 2010-09-01 05:39:43 - cd /src TB --- 2010-09-01 05:39:43 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 1 05:39:43 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Sep 1 07:12:52 UTC 2010 TB --- 2010-09-01 07:12:52 - generating LINT kernel config TB --- 2010-09-01 07:12:52 - cd /src/sys/amd64/conf TB --- 2010-09-01 07:12:52 - /usr/bin/make -B LINT TB --- 2010-09-01 07:12:52 - building LINT kernel TB --- 2010-09-01 07:12:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 07:12:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 07:12:52 - TARGET=amd64 TB --- 2010-09-01 07:12:52 - TARGET_ARCH=amd64 TB --- 2010-09-01 07:12:52 - TZ=UTC TB --- 2010-09-01 07:12:52 - __MAKE_CONF=/dev/null TB --- 2010-09-01 07:12:52 - cd /src TB --- 2010-09-01 07:12:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Sep 1 07:12:52 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_novell.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_em.c:1350: error: conflicting types for 'em_poll' /src/sys/dev/e1000/if_em.c:285: error: previous declaration of 'em_poll' was here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-01 07:21:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-01 07:21:47 - ERROR: failed to build lint kernel TB --- 2010-09-01 07:21:47 - 4868.06 user 550.59 system 6163.21 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 07:29:36 2010 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 50C791065787 for ; Wed, 1 Sep 2010 07:29:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id E6D0F8FC21 for ; Wed, 1 Sep 2010 07:29:35 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id 1KUv1f0010Fqzac58KVcKR; Wed, 01 Sep 2010 07:29:36 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta08.westchester.pa.mail.comcast.net with comcast id 1KVa1f0073LrwQ23UKVbg8; Wed, 01 Sep 2010 07:29:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5B8579B425; Wed, 1 Sep 2010 00:29:33 -0700 (PDT) Date: Wed, 1 Sep 2010 00:29:33 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100901072933.GA95770@icarus.home.lan> References: <20100901072148.50CC01B5060@freebsd-stable.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100901072148.50CC01B5060@freebsd-stable.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: amd64@freebsd.org, Jack Vogel Subject: Re: [releng_7 tinderbox] failure on amd64/amd64 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: Wed, 01 Sep 2010 07:29:36 -0000 On Wed, Sep 01, 2010 at 03:21:48AM -0400, FreeBSD Tinderbox wrote: > TB --- 2010-09-01 05:39:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca > TB --- 2010-09-01 05:39:04 - starting RELENG_7 tinderbox run for amd64/amd64 > TB --- 2010-09-01 05:39:04 - cleaning the object tree > TB --- 2010-09-01 05:39:33 - cvsupping the source tree > TB --- 2010-09-01 05:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile > TB --- 2010-09-01 05:39:43 - building world > TB --- 2010-09-01 05:39:43 - MAKEOBJDIRPREFIX=/obj > TB --- 2010-09-01 05:39:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-09-01 05:39:43 - TARGET=amd64 > TB --- 2010-09-01 05:39:43 - TARGET_ARCH=amd64 > TB --- 2010-09-01 05:39:43 - TZ=UTC > TB --- 2010-09-01 05:39:43 - __MAKE_CONF=/dev/null > TB --- 2010-09-01 05:39:43 - cd /src > TB --- 2010-09-01 05:39:43 - /usr/bin/make -B buildworld > >>> World build started on Wed Sep 1 05:39:43 UTC 2010 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > >>> World build completed on Wed Sep 1 07:12:52 UTC 2010 > TB --- 2010-09-01 07:12:52 - generating LINT kernel config > TB --- 2010-09-01 07:12:52 - cd /src/sys/amd64/conf > TB --- 2010-09-01 07:12:52 - /usr/bin/make -B LINT > TB --- 2010-09-01 07:12:52 - building LINT kernel > TB --- 2010-09-01 07:12:52 - MAKEOBJDIRPREFIX=/obj > TB --- 2010-09-01 07:12:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-09-01 07:12:52 - TARGET=amd64 > TB --- 2010-09-01 07:12:52 - TARGET_ARCH=amd64 > TB --- 2010-09-01 07:12:52 - TZ=UTC > TB --- 2010-09-01 07:12:52 - __MAKE_CONF=/dev/null > TB --- 2010-09-01 07:12:52 - cd /src > TB --- 2010-09-01 07:12:52 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Wed Sep 1 07:12:52 UTC 2010 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_novell.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c > awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue eisa_if.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 > /src/sys/dev/e1000/if_em.c:1350: error: conflicting types for 'em_poll' > /src/sys/dev/e1000/if_em.c:285: error: previous declaration of 'em_poll' was here > *** Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2010-09-01 07:21:47 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2010-09-01 07:21:47 - ERROR: failed to build lint kernel > TB --- 2010-09-01 07:21:47 - 4868.06 user 550.59 system 6163.21 real > > http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full Looks like the recent src/sys/dev/e1000/if_em.c commit broke this (appears to be conflicting prototype vs. function declarations (void vs. int)). http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 08:10:51 2010 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 9C02D106566C for ; Wed, 1 Sep 2010 08:10:51 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5080C8FC0C for ; Wed, 1 Sep 2010 08:10:51 +0000 (UTC) Received: by vws7 with SMTP id 7so7324392vws.13 for ; Wed, 01 Sep 2010 01:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=bt+XLZTpqFnAZ+F+7B10O9WPYmssq5Rn1Hf8D7bKWdc=; b=ULaxXsb5A7NzqoueypjGD1W8npgKBvLRWeELSBsMXmFxQz57X6zaNOceCoDinycNWe iDFypzA7+SCl4kJAh70aN2zdQK7AxBmACVI22FVDZA+zQK69o/GR6Uo+bdQ22NFc20s6 9iyifiuaUKD2kvZUAopnJdIFJW/QqXQzW17y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mVUGUvT+EY/hbYk8jYY10UFew2LPMsMRMiZhd9MCawrNDzsVx+OhGN3n3ggJK9rn+A pxc7Gpl4PHnLr6WFNgIZay2JCM8C0+3w6elcJ8nl5CYCoMV66jyY4Y5/K5z/1prhu+CE cl3aM8ivt69lbDmLb+QdpGH2A8lJbF3ZVaykk= Received: by 10.220.76.200 with SMTP id d8mr4675866vck.121.1283326833091; Wed, 01 Sep 2010 00:40:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.179.69 with HTTP; Wed, 1 Sep 2010 00:40:13 -0700 (PDT) In-Reply-To: References: From: Paul B Mahol Date: Wed, 1 Sep 2010 07:40:13 +0000 Message-ID: To: Michael BlackHeart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles 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: Wed, 01 Sep 2010 08:10:51 -0000 On Tue, Aug 31, 2010 at 10:30 AM, Michael BlackHeart wrote: > Hello > > I've got a problem with Broadcomm Wireless. > I have notebook HP Compaq 6720s with BCM4312. I disassemblied book and saw > there plugable Wireless Module but I'm lazy to do it again to werify it's > ID. > > Windows XP drivers works fine and says that is's > > PCI\VEN_14E4&DEV_4312&SUBSYS_1371103C&REV_02\4&29E2C51B&0&00E1 > MEMORY E4000000 - E4003FFF > IRQ 17 > > I've tried : > FreeBSD 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 > root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > And noting as i386 8.1 release. > > Now I'm running: > FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r211991: Mon Aug 30 14:58:34 MSD > 2010 > root@:/usr/obj/usr/src/sys/GENERIC amd64 > > With no driver attached "pciconf -l -cvb" says: > > none1@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > class = network > bar [10] = type Memory, range 64, base 0xe4000000, size 16384, enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > Clean install, trying bwi driver first > > cd /usr/ports/net/bwi-firmware-kmod && make install clean && rehash > kldload bwi_ucode_v3 > cd /usr/sys/src/modules/bwi > make all obj depend install clean > kldload if_bwi > > Aug 18 12:19:58 kernel: bwi0: > mem 0xe4000000-0xe4003fff irq 17 at device 0.0 on pci16 > Aug 18 12:19:58 kernel: bwi0: [ITHREAD] > Aug 18 12:19:58 kernel: bwi0: BBP: id 0x4311, rev 0x2, pkg 0 > Aug 18 12:19:58 kernel: bwi0: MAC rev 13 is not supported bwi(4) does not support your card. > Aug 18 12:19:58 kernel: bwi0: no MAC was found > Aug 18 12:19:58 kernel: device_attach: bwi0 attach returned 6 > > pciconf -l -cvb says: > > bwi0@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > class = network > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > now rebooting 'cos even after kldunloading if_bwi module it's still lists in > pciconfand trying bwn > > cd /usr/ports/net/bwn-firmware-kmod && make install clean && rehash > kldload bwn_v4_ucode.ko > kldload if_bwn > > pciconf -l -cvb says: > > siba_bwn0: mem 0xe4000000-0xe4003fff > irq 17 at device 0.0 on pci16 > siba_bwn0: unsupported coreid (USB 1.1 Host) > bwn0 on siba_bwn0 > bwn0: WLAN (chipid 0x4311 rev 13) PHY (analog 4 type 2 rev 9) RADIO (manuf > 0x17f ver 0x2050 rev 2) > bwn0: DMA (64 bits) > bwn0: Using 1 MSI messages > bwn0: [FILTER] > > siba_bwn0@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 > rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > class = network > bar [10] = type Memory, range 64, base 0xe4000000, size 16384, enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > ifconfig bwn0 up scan > bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) > ifconfig: unable to get scan results > bwn0: status of RF switch is changed to OFF You must create wlanX first. > > book have a switch to turn on/off all radio and it's always on. also when > i'm switching it FreeBSD says nothing > Also I tried acpi_hp - no sense > And i didn't find any apropriate in sysctl > > Moving next - ndis > I've tried couple of drivers > With WinXP that running on drivers v. VERSION: 7.10 REV: B from sp41680 > And OS goes to kernel panic just when I kldloaded it. NDISulator on amd64 is mostly broken. It can panic on driver initialization (fixed in my git repo). Also fpudna in kernel mode can cause panic (not yet fixed). > No dump, sorry, but I don't think that it matters a thing > > Another one - VERSION: 6.10 REV: A from sp34152 works a bit better > It converts and loads without panic but in debug: > kldload bcmwl564_sys.ko > > ndis0: mem 0xe4000000-0xe4003fff irq 17 at > device 0. > 0 on pci16 > > ndis0: [ITHREAD] > > ndis0: NDIS API version: 5.1 > > fpudna in kernel mode! Interesting, that version of driver does not use symbols which cause crash on driver initialization of older driver... Of course most 6.X drivers dont have support for older NDIS 5.1 API. > pciconf -lcvb says: > ndis0@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 > hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > > class = network > > bar [10] = type Memory, range 64, base 0xe4000000, size 16384, enabled > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit > > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > ifconfig says: > > > ndis0: flags=8802 metric 0 mtu 2290 > > ether 00:21:00:43:56:0e > > media: IEEE 802.11 > Wireless Ethernet autoselect (autoselect) > > status: no carrier > > and everything doesn't work again. > > I think this as all info I can get, huh. > I've got only two questions: > 1)Is there a way to determine what exactly microcode uses Windows Driver > (There's no info in devmgmgt.msc or I just don't get that it's info I'm > looking for) > 2)Have u got any advices to me how to get it all working? > _______________________________________________ > 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 Wed Sep 1 08:11:18 2010 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 A882310656F1; Wed, 1 Sep 2010 08:11:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2828FC26; Wed, 1 Sep 2010 08:11:18 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o818BGr3030677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2010 04:11:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.4/8.14.4) with ESMTP id o818BGvQ069946; Wed, 1 Sep 2010 04:11:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id EC1141B5060; Wed, 1 Sep 2010 04:11:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100901081115.EC1141B5060@freebsd-stable.sentex.ca> Date: Wed, 1 Sep 2010 04:11:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 08:11:18 -0000 TB --- 2010-09-01 06:54:06 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-09-01 06:54:06 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2010-09-01 06:54:06 - cleaning the object tree TB --- 2010-09-01 06:54:29 - cvsupping the source tree TB --- 2010-09-01 06:54:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2010-09-01 06:54:38 - building world TB --- 2010-09-01 06:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 06:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 06:54:38 - TARGET=i386 TB --- 2010-09-01 06:54:38 - TARGET_ARCH=i386 TB --- 2010-09-01 06:54:38 - TZ=UTC TB --- 2010-09-01 06:54:38 - __MAKE_CONF=/dev/null TB --- 2010-09-01 06:54:38 - cd /src TB --- 2010-09-01 06:54:38 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 1 06:54:39 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Sep 1 08:04:41 UTC 2010 TB --- 2010-09-01 08:04:41 - generating LINT kernel config TB --- 2010-09-01 08:04:41 - cd /src/sys/i386/conf TB --- 2010-09-01 08:04:41 - /usr/bin/make -B LINT TB --- 2010-09-01 08:04:41 - building LINT kernel TB --- 2010-09-01 08:04:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 08:04:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 08:04:41 - TARGET=i386 TB --- 2010-09-01 08:04:41 - TARGET_ARCH=i386 TB --- 2010-09-01 08:04:41 - TZ=UTC TB --- 2010-09-01 08:04:41 - __MAKE_CONF=/dev/null TB --- 2010-09-01 08:04:41 - cd /src TB --- 2010-09-01 08:04:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Sep 1 08:04:42 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_em.c:1350: error: conflicting types for 'em_poll' /src/sys/dev/e1000/if_em.c:285: error: previous declaration of 'em_poll' was here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-01 08:11:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-01 08:11:15 - ERROR: failed to build lint kernel TB --- 2010-09-01 08:11:15 - 3592.26 user 386.20 system 4629.27 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 08:34:21 2010 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 0E93E1065693; Wed, 1 Sep 2010 08:34:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 896EC8FC15; Wed, 1 Sep 2010 08:34:20 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o818YIf0031767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2010 04:34:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.4/8.14.4) with ESMTP id o818YIZM009162; Wed, 1 Sep 2010 04:34:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 2FA281B5060; Wed, 1 Sep 2010 04:34:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100901083418.2FA281B5060@freebsd-stable.sentex.ca> Date: Wed, 1 Sep 2010 04:34:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 08:34:21 -0000 TB --- 2010-09-01 07:21:48 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-09-01 07:21:48 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2010-09-01 07:21:48 - cleaning the object tree TB --- 2010-09-01 07:22:24 - cvsupping the source tree TB --- 2010-09-01 07:22:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2010-09-01 07:22:34 - building world TB --- 2010-09-01 07:22:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 07:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 07:22:34 - TARGET=pc98 TB --- 2010-09-01 07:22:34 - TARGET_ARCH=i386 TB --- 2010-09-01 07:22:34 - TZ=UTC TB --- 2010-09-01 07:22:34 - __MAKE_CONF=/dev/null TB --- 2010-09-01 07:22:34 - cd /src TB --- 2010-09-01 07:22:34 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 1 07:22:35 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Sep 1 08:28:55 UTC 2010 TB --- 2010-09-01 08:28:55 - generating LINT kernel config TB --- 2010-09-01 08:28:55 - cd /src/sys/pc98/conf TB --- 2010-09-01 08:28:55 - /usr/bin/make -B LINT TB --- 2010-09-01 08:28:55 - building LINT kernel TB --- 2010-09-01 08:28:55 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 08:28:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 08:28:55 - TARGET=pc98 TB --- 2010-09-01 08:28:55 - TARGET_ARCH=i386 TB --- 2010-09-01 08:28:55 - TZ=UTC TB --- 2010-09-01 08:28:55 - __MAKE_CONF=/dev/null TB --- 2010-09-01 08:28:55 - cd /src TB --- 2010-09-01 08:28:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Sep 1 08:28:55 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_novell.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_em.c:1350: error: conflicting types for 'em_poll' /src/sys/dev/e1000/if_em.c:285: error: previous declaration of 'em_poll' was here *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-01 08:34:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-01 08:34:18 - ERROR: failed to build lint kernel TB --- 2010-09-01 08:34:18 - 3475.62 user 389.05 system 4349.80 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 13:26:24 2010 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 548471065675 for ; Wed, 1 Sep 2010 13:26:24 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 17B8A8FC1C for ; Wed, 1 Sep 2010 13:26:23 +0000 (UTC) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Oqn3c-0002R3-Ca; Wed, 01 Sep 2010 14:08:55 +0100 Received: from cse-jg.cse.bris.ac.uk ([137.222.12.37]:61072) by mail.ilrt.bris.ac.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Oqn3Y-0004tn-Hy; Wed, 01 Sep 2010 14:08:48 +0100 Date: Wed, 1 Sep 2010 14:08:48 +0100 (BST) From: jan.grant@bristol.ac.uk X-X-Sender: cmjg@tribble.ilrt.bris.ac.uk To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ILRT-MailScanner: Found to be clean X-ILRT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.41, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.99, BAYES_00 -2.60) X-ILRT-MailScanner-From: jan.grant@bristol.ac.uk X-Spam-Status: No X-Spam-Score: -1.1 X-Spam-Level: - Subject: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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: Wed, 01 Sep 2010 13:26:24 -0000 I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so "non-interactive" in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Once I pay attention to any particular window, the scheduler rapidly (like, in 15 agonising seconds or so) decides that the processes associated with that particular window are "interactive" and performance there picks up again. But it only takes 10 seconds (not timed; ballpark figures) or so of inattention for a window's processes to lapse back into a low-priority state, with the attendant performance problems. I don't think my desktop usage is particularly abnormal; I doubt my level of frustration is, either :-) I think the issue here is that a modern desktop has quite a lot of associated processes, and you can't keep them all sufficiently "interactive" in the eyes of sched_ule to ensure they stay responsive. Are there particular tunables associated with sched_ule (the manpage says not) that I might look at to try to address this? Or process flags I can set on my desktop tasks to keep them nearer the interactive end of the spectrum? Claimed is: o Interactivity heuristics that detect interactive applications and schedules them preferentially under high load. but compared to the performance under sched_4bsd, what I'm seeing is an atrocious user experience. At the moment I'm fiddling around with cpusets to try to pin my port builds to a subset of the available processors. Suggestions are welcome! Cheers, jan PS. I've stuck it out with sched_ule since it's been available, but I should point out this isn't a sudden change in its behaviour; it's done this for a while. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ "No generalised law is without exception." A self-demonstrating axiom. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 14:05:08 2010 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 369F710656AC for ; Wed, 1 Sep 2010 14:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id B880F8FC08 for ; Wed, 1 Sep 2010 14:05:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B5CC241C756; Wed, 1 Sep 2010 16:05:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id XtkQIJXBhJEt; Wed, 1 Sep 2010 16:05:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D54AC41C752; Wed, 1 Sep 2010 16:05:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1E1664448F3; Wed, 1 Sep 2010 14:04:00 +0000 (UTC) Date: Wed, 1 Sep 2010 14:04:00 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mike Tancsa In-Reply-To: <201008312102.o7VL2MJr000894@lava.sentex.ca> Message-ID: <20100901140319.Y31898@maildrop.int.zabbadoz.net> References: <201008312102.o7VL2MJr000894@lava.sentex.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: if_rtdel: error 47 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: Wed, 01 Sep 2010 14:05:08 -0000 On Tue, 31 Aug 2010, Mike Tancsa wrote: Hey Mike, > On a RELENG_8 box from aug 25th, I started seeing a constant spew of > > Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47 > Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:29 gate8 last message repeated 2 times > Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:37 gate8 last message repeated 2 times > Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:38 gate8 last message repeated 2 times > > > What do they mean and how can I find the cause of it ? The box acts as an LNS > with about 700 ng interfaces with mpd5.5. ipv6 is enabled on this server as > well, so I am guessing it might be related to ipv6 as I havent seen it on the > other LNS boxes that have the same setup, except no ipv6. It was happily > running for a few days until this error started showing up ? I thought this was fixed already but maybe only in HEAD and not merged. I'll go and look. /bz -- Bjoern A. Zeeb This signature is about you not me. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 14:14:19 2010 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 73B0510656A3 for ; Wed, 1 Sep 2010 14:14:19 +0000 (UTC) (envelope-from h2+freebsd@fsfe.org) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.freebsd.org (Postfix) with ESMTP id F12E88FC1D for ; Wed, 1 Sep 2010 14:14:18 +0000 (UTC) X-Envelope-From: h2+freebsd@fsfe.org X-Envelope-To: Received: from fbsdmain.soldiner.lan (dslb-088-072-008-255.pools.arcor-ip.net [88.72.8.255]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id o81DdHMZ018312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Sep 2010 15:39:17 +0200 From: Hannes Hauswedell To: freebsd-stable@freebsd.org Date: Wed, 1 Sep 2010 13:39:15 +0000 User-Agent: KMail/1.13.3 (FreeBSD/8.1-RC1; KDE/4.4.5; amd64; ; ) Organization: Free Software Foundation Europe MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: <201009011339.15898.h2+freebsd@fsfe.org> X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Why is NFSv4 so slow? 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: Wed, 01 Sep 2010 14:14:19 -0000 SGkgZXZlcnlvbmUsCgpJIGFtIGV4cGVyaWVuY2luZyBzaW1pbGFyIGlzc3VlcyB3aXRoIG5ld25m czoKCjEpIEkgaGF2ZSB0d28gY2xpZW50cyB0aGF0IGVhY2ggZ2V0IGFyb3VuZCAwLjVNaUIvcyB0 byAyLjZNaUIvcyByZWFkaW5nIApmcm9tIHRoZSBORlM0LXNoYXJlIG9uIEdiaXQtTGFuCgoyKSBN b3VudGluZyB3aXRoIC10IG5ld25mcyAtbyBuZnN2MyByZXN1bHRzIGluIG5vIHBlcmZvcm1hbmNl IGdhaW4gCndoYXRzb2V2ZXIuCgozKSBNb3VudGluZyB3aXRoIC10IG5mcyByZXN1bHRzIGluIDU4 TWlCL3MgISAoTmV0Y2F0IGhhcyBzaW1pbGFyIApwZXJmb3JtYW5jZSkg4oaSIG5vdCBhIGhhcmR3 YXJlL2RyaXZlciBpc3N1ZSBmcm9tIG15IHBvdgoKSXMgdGhlcmUgYW55dGhpbmcgSSBjYW4gZG8g dG8gaGVscCBmaXggdGhpcz8KClRoYW5rIHlvdSwKLS0gCiAgICAgICAgICAgICAgICAgICAgICAg ICDilIzilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilJAKQmVzdCBSZWdhcmRzLCAgICAgICAgICAgIOKUgiBGcmVlIFNvZnR3 YXJlIEZvdW5kYXRpb24gRXVyb3BlICAgIOKWiOKWiSAgIOKUggpIYW5uZXMgSGF1c3dlZGVsbCAg ICAgICAg4pSCICAgICAgICAgICBHZXJtYW4gVGVhbSAgICAgICAgICAgIOKWiOKWieKWiOKWieKW iOKWiSDilIIKICAgICAgICAgICAgICAgICAgICAgICAgIOKUgiBDb29yZGluYXRvciBmb3IgcGRm cmVhZGVycy5vcmcgICAgIOKWieKWiSAgIOKUggogICAgICAgICAgICAgICAgICAgICAgICAg4pSU 4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA 4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA 4pSA4pSA4pSA4pSYCg== From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 14:30:07 2010 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 784BD10656A9 for ; Wed, 1 Sep 2010 14:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA3C8FC19 for ; Wed, 1 Sep 2010 14:30:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6306A41C752; Wed, 1 Sep 2010 16:30:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id wXR-XM-R7aWD; Wed, 1 Sep 2010 16:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id CB9E641C75A; Wed, 1 Sep 2010 16:30:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AB4554448F3; Wed, 1 Sep 2010 14:28:45 +0000 (UTC) Date: Wed, 1 Sep 2010 14:28:45 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Frank Razenberg In-Reply-To: <4C7DB18F.5030501@zzattack.org> Message-ID: <20100901142700.X31898@maildrop.int.zabbadoz.net> References: <4C7DB18F.5030501@zzattack.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic when accessing /dev/tap0 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: Wed, 01 Sep 2010 14:30:07 -0000 On Wed, 1 Sep 2010, Frank Razenberg wrote: Hey, > Robert Watson described a problem in this discussion: > http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025880.html > Currently I'm experiencing a similar problem, but on amd64 and FreeBSD 8.1 > Release. Accessing /dev/tap0 instantly results in a kernel panic, so it's > most likely if_tap related. Is this a known problem? I've started > encountering it ever since I rebuilt my kernel with "options vimage". this is expected. I have a work in progress fix in perforce for most/all cloned interfaces. It's only a matter of extracting patches now but it'll be anohter few days till I'll get to that. /bz PS: freebsd-virtualization@ might be the better place to post VIMAGE problems. -- Bjoern A. Zeeb This signature is about you not me. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 15:19:34 2010 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 2DF721065674 for ; Wed, 1 Sep 2010 15:19:34 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B64AF8FC16 for ; Wed, 1 Sep 2010 15:19:33 +0000 (UTC) Received: from [2a01:348:132:51::10] (helo=carrick-users) by carrick.bishnet.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqp63-0003Yn-R3; Wed, 01 Sep 2010 16:19:31 +0100 Received: (from tdb@localhost) by carrick-users (8.14.4/8.14.4/Submit) id o81FJVqk013688; Wed, 1 Sep 2010 16:19:31 +0100 (BST) (envelope-from tdb) Date: Wed, 1 Sep 2010 16:19:31 +0100 From: Tim Bishop To: Dan Nelson Message-ID: <20100901151931.GB9224@carrick-users.bishnet.net> References: <20100821220435.GA6208@carrick-users.bishnet.net> <20100821222429.GB73221@dan.emsphone.com> <20100831133556.GB45316@carrick-users.bishnet.net> <20100831155829.GC5913@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100831155829.GC5913@dan.emsphone.com> X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1R ZFS almost locking up system 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: Wed, 01 Sep 2010 15:19:34 -0000 On Tue, Aug 31, 2010 at 10:58:29AM -0500, Dan Nelson wrote: > In the last episode (Aug 31), Tim Bishop said: > > On Sat, Aug 21, 2010 at 05:24:29PM -0500, Dan Nelson wrote: > > > In the last episode (Aug 21), Tim Bishop said: > > > > A few items from top, including zfskern: > > > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > > > 5 root 4 -8 - 0K 60K zio->i 0 54:38 3.47% zfskern > > > > 91775 70 1 44 0 53040K 31144K tx->tx 1 2:11 0.00% postgres > > > > 39661 tdb 1 44 0 55776K 32968K tx->tx 0 0:39 0.00% mutt > > > > 14828 root 1 47 0 14636K 1572K tx->tx 1 0:03 0.00% zfs > > > > 11188 root 1 51 0 14636K 1572K tx->tx 0 0:03 0.00% zfs > > > > > > > > At some point during this process my zfs snapshots have been failing to > > > > complete: > > > > > > > > root 5 0.8 0.0 0 60 ?? DL 7Aug10 54:43.83 [zfskern] > > > > root 8265 0.0 0.0 14636 1528 ?? D 10:00AM 0:03.12 zfs snapshot -r pool0@2010-08-21_10:00:01--1d > > > > root 11188 0.0 0.1 14636 1572 ?? D 11:00AM 0:02.93 zfs snapshot -r pool0@2010-08-21_11:00:01--1d > > > > root 14828 0.0 0.1 14636 1572 ?? D 12:00PM 0:03.04 zfs snapshot -r pool0@2010-08-21_12:00:00--1d > > > > root 17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs snapshot -r pool0@2010-08-21_13:00:01--1d > > > > root 20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs snapshot -r pool0@2010-08-21_14:00:01--1d > > > > > > procstat -k on some of these processes might help to pinpoint what part of > > > the zfs code they're all waiting in. > > > > It happened again this Saturday (clearly something in the weekly > > periodic run is triggering the issue). procstat -kk shows the following > > for processes doing something zfs related (where zfs related means the > > string 'zfs' in the procstat -kk output): > > > > 0 100084 kernel zfs_vn_rele_task mi_switch+0x16f sleepq_wait+0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_trampoline+0xe > > 5 100031 zfskern arc_reclaim_thre mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 fork_exit+0x118 fork_trampoline+0xe > > 5 100032 zfskern l2arc_feed_threa mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be fork_exit+0x118 fork_trampoline+0xe > > 5 100085 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_exit+0x118 fork_trampoline+0xe > > 5 100086 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea spa_sync+0x355 txg_sync_thread+0x195 fork_exit+0x118 fork_trampoline+0xe > > 17 100040 syncer - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_sync+0xa6 sync_fsync+0x184 sync_vnode+0x16b sched_sync+0x1c9 fork_exit+0x118 fork_trampoline+0xe > > 2210 100156 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > 3500 100177 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > 3783 100056 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > 4064 100165 mysqld initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 > > 4441 100224 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > 4444 100227 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > 4445 100228 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > 4446 100229 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > 4447 100089 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > 5352 100270 mutt - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_freebsd_fsync+0xd7 null_bypass+0xd3 fsync+0x161 syscall+0x1e7 Xfast_syscall+0xe1 > > 52686 100200 tarsnap - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 > > 59049 100207 webalizer initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_pwritev+0x63 pwrite+0x59 syscall+0x1e7 Xfast_syscall+0xe1 > > 77573 100479 perl - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 write+0x55 syscall+0x1e7 Xfast_syscall+0xe1 > > 78595 100275 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 > > 81989 100596 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 > > > > I'm not sure if this shows anything useful? > > All your userland processes are basically waiting for the kernel to finish > writing a ZFS transaction group to disk. mutt has called fsync, which may > have been the trigger. Usually writing a transaction group is fast, though, > because ZFS will batch up all the new data into one contiguous block and > write it at full speed to disk. That's why I asked about full filesystems > before, since if your FS has been near 99%, you may not have any large runs > of freespace left. Right. But I wouldn't have thought that'd be effectively terminal? It's not just a bit slow - the machine freezes up, sometimes for many hours until rebooted. > I noticed in your original post: > > capacity operations bandwidth > pool used avail read write read write > ---------- ----- ----- ----- ----- ----- ----- > pool0 117G 16.7G 248 114 865K 269K > mirror 117G 16.7G 248 114 865K 269K > ad4s3 - - 43 56 2.47M 269K > ad6s3 - - 39 56 2.41M 269K > ---------- ----- ----- ----- ----- ----- ----- I did a scrub the other day and I noticed this same pattern (reads happening more on the disks and the pool). > # gstat > ... > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 1 48 48 3042 9.8 0 0 0.0 47.6| ad4 > 0 38 38 2406 10.5 0 0 0.0 39.5| ad6 > > You have a pair of mirrored disks, each doing around 40% I/O load, which is > 80% load if a single-threaded task is driving all the I/O. I see the syncer > process is also trying to write to the ZIL. Are you running something that > does a lot of fsync calls (a database server for example)? Is this system > an NFS server maybe? Try setting the sysctl vfs.zfs.zil_disable=1 and see > if your performance improves. I am running both MySQL and PostgreSQL in jails, but both are extremely lightly loaded. No NFS. I've looked at disabling the ZIL, but it doesn't seem to be a recommended thing to do? I've also just upgraded to 8-STABLE to see if the few ZFS updates in there make any difference. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 15:22:01 2010 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 813231065694 for ; Wed, 1 Sep 2010 15:22:01 +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 0BC218FC16 for ; Wed, 1 Sep 2010 15:22:00 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Oqp8O-0005Ea-Kt for freebsd-stable@freebsd.org; Wed, 01 Sep 2010 17:21:56 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Sep 2010 17:21:56 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Sep 2010 17:21:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 01 Sep 2010 17:21:47 +0200 Lines: 47 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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: Wed, 01 Sep 2010 15:22:01 -0000 On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: > I'm running -STABLE with a kde-derived desktop. This setup (which is > pretty standard) is providing abysmal interactive performance on an > eight-core machine whenever I try to do anything CPU-intensive (such as > building a port). > > Basically, trying to build anything from ports rapidly renders everything > else so "non-interactive" in the eyes of the scheduler that, for instance, > switching between virtual desktops (I have six of them in reasonably > frequent use) takes about a minute of painful waiting on redraws to > complete. Are you sure this is about the scheduler or maybe bad X11 drivers? > Once I pay attention to any particular window, the scheduler rapidly > (like, in 15 agonising seconds or so) decides that the processes > associated with that particular window are "interactive" and performance > there picks up again. But it only takes 10 seconds (not timed; ballpark > figures) or so of inattention for a window's processes to lapse back into > a low-priority state, with the attendant performance problems. "windows" in X11 have nothing to do with the scheduler (contrary to MS Windows where the OS actually "re-nices" processes whose windows have focus) - here you are just interacting with a process. > I don't think my desktop usage is particularly abnormal; I doubt my level > of frustration is, either :-) I think the issue here is that a modern I'm writing this on a quad-core Core2 machine with 4 GB RAM, amd64 arch, Radeon 2500 HD, with KDE4 with most of the 3D visual effects turned on. I have not yet experienced problems like you describe. On the other hand, I have noticed that a 2xQuad-core machine I have access too has more X11 interactivity problems than this single quad-core machine, though again not as serious as yours. I don't know why this is. From the hardware side it might be the shared FSB or from the software side it might be the scheduler. If you want to try something I think it's easier for you to disable one CPU in BIOS or pin X.org and its descendant processes to CPUs of a single socket than to diagnose scheduler problems. > but compared to the performance under sched_4bsd, what I'm seeing is an > atrocious user experience. It would be best if you could quantify this in some way. I have no idea how. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 15:31:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1F2DA10656CD for ; Wed, 1 Sep 2010 15:31:55 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 133F114ECF5 for ; Wed, 1 Sep 2010 15:31:40 +0000 (UTC) Received: (qmail 79849 invoked from network); 1 Sep 2010 15:31:40 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 1 Sep 2010 15:31:40 -0000 Message-ID: <4C7E71DC.1040808@freebsd.org> Date: Wed, 01 Sep 2010 08:31:40 -0700 From: FreeBSD Security Officer Organization: FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100803 Thunderbird/3.0.6 MIME-Version: 1.0 To: FreeBSD Stable , freebsd security X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: security-officer@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 15:31:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Since FreeBSD 6.4 is the last remaining supported release from the FreeBSD 6.x stable branch, support for the FreeBSD 6.x stable branch will also cease at the same point. Users of either of these FreeBSD releases are strongly encouraged to upgrade to either FreeBSD 7.3 or FreeBSD 8.1 before that date. The FreeBSD Ports Management Team wishes to remind users that November 30 is also the end of support for the Ports Collection for both FreeBSD 6.4 RELEASE and the FreeBSD 6.x STABLE branch. Neither the infrastructure nor individual ports are guaranteed to work on these FreeBSD versions after that date. A CVS tag will be created for users who cannot upgrade for some reason, at which time these users are advised to stop tracking the latest ports CVS repository and use the RELEASE_6_EOL tag instead. The current supported branches and expected EoL dates are: +---------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |---------------------------------------------------------------------| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |---------------------------------------------------------------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |-----------+------------+--------+-----------------+-----------------| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_0 |8.0-RELEASE |Normal |November 25, 2009|November 30, 2010| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010 |July 31, 2012 | +---------------------------------------------------------------------+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx+cdwACgkQFdaIBMps37K/VACgnkGPT1G76AYaor9ifcTeFDA2 dzgAn0Oqz5UsoaoCvWycUSsFFlpBi0gB =WWDq -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 15:46:32 2010 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 7646610656BB for ; Wed, 1 Sep 2010 15:46:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 321378FC1B for ; Wed, 1 Sep 2010 15:46:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEACESfkyDaFvO/2dsb2JhbACDGJ45rGuSD4EigyRzBIoU X-IronPort-AV: E=Sophos;i="4.56,304,1280721600"; d="scan'208";a="92484580" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Sep 2010 11:46:27 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 82A6DB3F0A; Wed, 1 Sep 2010 11:46:30 -0400 (EDT) Date: Wed, 1 Sep 2010 11:46:30 -0400 (EDT) From: Rick Macklem To: Hannes Hauswedell Message-ID: <2070918035.372723.1283355990476.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201009011339.15898.h2+freebsd@fsfe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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: Wed, 01 Sep 2010 15:46:32 -0000 > Hi everyone, >=20 > I am experiencing similar issues with newnfs: >=20 > 1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s > reading > from the NFS4-share on Gbit-Lan >=20 > 2) Mounting with -t newnfs -o nfsv3 results in no performance gain > whatsoever. >=20 > 3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar > performance) =E2=86=92 not a hardware/driver issue from my pov >=20 The experimental client does reads in larger MAXBSIZE chunks, which did cause a similar problem in Mac OS X until rsize=3D32768,wsize=3D32768 was specified. Rick already tried that, but you might want to try it for your case. > Is there anything I can do to help fix this? >=20 Ok, so it does sound like an issue in the experimental client and not NFSv4. For the most part, the read code is the same as the regular client, but it hasn't been brought up-to-date with recent changes. One thing you could try is building a kernel without SMP enabled and see if that helps? (I only have single core hardware, so I won't see any SMP races.) If that helps, I can compare the regular vs experimental client for smp locking in the read stuff. rick From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 15:53:25 2010 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 957CE10656B1 for ; Wed, 1 Sep 2010 15:53:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 45B358FC0C for ; Wed, 1 Sep 2010 15:53:25 +0000 (UTC) Received: by qwg5 with SMTP id 5so31214qwg.13 for ; Wed, 01 Sep 2010 08:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=2GfB/UDiH/36B7KaOVALngcr9Vn25D0fg+R1yj99i8o=; b=RFx2mK8FehPxZd33xm1e83rjNitQVeYAt5qyxKg+/mufmkhcZfyutzTqiYmL2a/W6C sT+tcVJXkf8Na72yngrOk4Aq9/ViGvjcaammOoBt2eZy/Scp52r0JxPF8FweUrwjJR/m ragKVmPXKK7ncQDN+MVWrDvSnZFeE1QBri3XU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uvoSE42cUBeJb8ONd5j8ApQWVTXJAwUlVWsOIGsTcRb+qkyiehUloDZNb8hjtU4jMX YjjW/u7i3l+8cvn8eWFEbR1hXPZ+lItMxXYh5VKoM6zcHh44AnVKUKO/kpczIAIhnLo3 CtF+y/v6oAnT+hMDn06/cTZbvQOAjZsCdqbTM= MIME-Version: 1.0 Received: by 10.229.192.21 with SMTP id do21mr5736444qcb.57.1283356390718; Wed, 01 Sep 2010 08:53:10 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Wed, 1 Sep 2010 08:53:09 -0700 (PDT) Date: Wed, 1 Sep 2010 19:53:09 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR 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: Wed, 01 Sep 2010 15:53:25 -0000 Hi. This is reproducible from time to time on boot when handling SIOCAIFADDR called from ifconfig on igb on fresh (and not so fresh) 8-STABLE. How can I help with debugging? Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex igb0 (IGB Core Lock) r = 0 (0xc2655534) locked @ /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965 KDB: stack backtrace: db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(3c5,0,ffffffff,c0a94864,cce577f0,...) at kdb_backtrace+0x29 _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe trap(cce57890) at trap+0x195 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 --- e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...) at e1000_clear_hw_cntrs_base_generic+0x3e7 igb_init_locked(c2655534,0,c31ac72f,3c5,c31c3d00,...) at igb_init_locked+0x16e2 igb_ioctl(c2642c00,8020690c,c31c3d00,cce57a8c,c457ea9b,...) at igb_ioctl+0x495 in_ifinit(0,c08c391b,1aa,1a6,c2642c00,...) at in_ifinit+0x29e in_control(c2a58b44,8040691a,c31bd100,c2642c00,c2948000,...) at in_control+0xccb ifioctl(c2a58b44,8040691a,c31bd100,c2948000,c31c3b00,...) at ifioctl+0x1820 soo_ioctl(c29b7bd0,8040691a,c31bd100,c254b100,c2948000,...) at soo_ioctl+0x415 kern_ioctl(c2948000,3,8040691a,c31bd100,6073c0,...) at kern_ioctl+0x1fd ioctl(c2948000,cce57cf8,c08e3073,c08c398f,c2956000,...) at ioctl+0x134 syscall(cce57d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281c1543, esp = 0xbfbfe60c, ebp = 0xbfbfe648 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xcc5af000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc3192477 stack pointer = 0x28:0xcce578d0 frame pointer = 0x28:0xcce578e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 700 (ifconfig) db> show ifnet 0xc2642c00 igb0: if_dname = igb if_dunit = 0 if_description = (null) if_index = 2 if_refcount = 2 if_softc = 0xc2651000 if_l2com = 0xc2676b80 if_vnet = 0 if_home_vnet = 0 if_addr = 0xc31c4500 if_llsoftc = 0 if_label = 0 if_pcount = 0 if_flags = 0x00008803 if_drv_flags = 0x00000040 if_capabilities = 0x000101bb if_capenable = 0x000001bb if_snd.ifq_head = 0 if_snd.ifq_tail = 0 if_snd.ifq_len = 0 if_snd.ifq_maxlen = 1023 if_snd.ifq_drops = 0 if_snd.ifq_drv_head = 0 if_snd.ifq_drv_tail = 0 if_snd.ifq_drv_len = 0 if_snd.ifq_drv_maxlen = 1023 if_snd.altq_type = 0 if_snd.altq_flags = 1 -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 15:56:50 2010 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 640EE1065674 for ; Wed, 1 Sep 2010 15:56:50 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5058FC08 for ; Wed, 1 Sep 2010 15:56:48 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 01 Sep 2010 11:25:47 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::2215 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@freebsd.org X-SMFBL: ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= Message-ID: <4C7E743A.1040506@comcast.net> Date: Wed, 01 Sep 2010 11:41:46 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.7) Gecko/20100805 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, Rick Macklem References: <538823.39365.qm@web50508.mail.re2.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: NFS 75 second stall 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: Wed, 01 Sep 2010 15:56:50 -0000 On 07/01/10 15:23, Garrett Cooper wrote: > On Thu, Jul 1, 2010 at 11:51 AM, alan bryan wrote: >> >> --- On Thu, 7/1/10, Garrett Cooper wrote: >> >>> From: Garrett Cooper >>> Subject: Re: NFS 75 second stall >>> To: "alan bryan" >>> Cc: freebsd-stable@freebsd.org >>> Date: Thursday, July 1, 2010, 11:13 AM >>> On Thu, Jul 1, 2010 at 11:01 AM, alan >>> bryan >>> wrote: >>>> Setup: >>>> >>>> server - FreeBSD 8-stable from today. 2 UFS dirs >>> exported via NFS. >>>> client - FreeBSD 8.0-Release. Running a test php >>> script that copies around various files to/from 2 separate >>> NFS mounts. >>>> Situation: >>>> >>>> script is started (forked to do 20 simultaneous runs) >>> and 20 1GB files are copied to the NFS dir which works >>> fine. When it then switches to reading those files back >>> and simultaneously writing to the other NFS mount I see a >>> hang of 75 seconds. If I do an "ls -l" on the NFS mount it >>> hangs too. After 75 seconds the client has reported: >>>> nfs server 192.168.10.133:/usr/local/export1: not >>> responding >>>> nfs server 192.168.10.133:/usr/local/export1: is alive >>> again >>>> nfs server 192.168.10.133:/usr/local/export1: not >>> responding >>>> nfs server 192.168.10.133:/usr/local/export1: is alive >>> again >>>> and then things start working again. The server was >>> originally FreeBSD 8.0-Release also but was upgraded to the >>> latest stable to see if this issue could be avoided. >>>> # nfsstat -s -W -w 1 >>>> GtAttr Lookup Rdlink Read Write Rename >>> Access Rddir >>>> 0 0 0 222 257 >>> 0 0 0 >>>> 0 0 0 178 135 >>> 0 0 0 >>>> 0 0 0 85 127 >>> 0 0 0 >>>> 0 0 0 0 0 >>> 0 0 0 >>>> 0 0 0 0 0 >>> 0 0 0 >>>> 0 0 0 0 0 >>> 0 0 0 >>>> 0 0 0 0 0 >>> 0 0 0 >>>> 0 0 0 0 0 >>> 0 0 0 >>>> ... for 75 rows of all zeros >>>> >>>> 0 0 0 272 266 >>> 0 0 0 >>>> 0 0 0 167 165 >>> 0 0 0 >>>> I also tried runs with 15 simultaneous processes and >>> 25. 15 processes gave only about a 5 second stall but 25 >>> gave again the same 75 second stall. >>>> Further, I tested with 2 mounts to the same server but >>> from ZFS filesytems with the exact same stall/timeout >>> periods. So, it doesn't appear to matter what the >>> underlying filesystem is - it's something in NFS or >>> networking code. >>>> Any ideas on what's going on here? What's causing >>> the complete stall period of zero NFS activity? Any flaws >>> with my testing methods? >>>> Thanks for any and all help/ideas. >>> What network driver are you using? Have you tried >>> tcpdumping the packets? >>> -Garrett >>> >> I'm using igb currently but have also used em. I have not tried tcpdumping the packets yet on this test. Any suggestions on things to look out for (I'm not that familiar with that whole process). >> >> Which brings up another point - I'm using TCP connections for NFS, not UDP. > Is the net.inet.tcp.tso sysctl enabled or not? What about rxcsum and txcsum? > Thanks, > -Garrett We're occaisionally seeing these same types of stalls (+ repeated "is not responding" "is alive again" messages in quick succession). We're seeing it only on our 8.1-RELEASE systems against a variety of NFS servers (6.3-RELEASE, 7.2-RELEASE, and 8-STABLE from before the release of 8.1). We also see it happen with a variety of client hardware and network adapters (em, bce, bge); the only common denominator is 8.1-RELEASE on the clients. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 16:05:49 2010 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 1F1091065695 for ; Wed, 1 Sep 2010 16:05:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C71E68FC19 for ; Wed, 1 Sep 2010 16:05:48 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EANEWfkyDaFvO/2dsb2JhbACDGI90jkWtCZIOhEZzBIoU X-IronPort-AV: E=Sophos;i="4.56,304,1280721600"; d="scan'208";a="92488191" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Sep 2010 12:05:44 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EA27CB3EA8; Wed, 1 Sep 2010 12:05:47 -0400 (EDT) Date: Wed, 1 Sep 2010 12:05:47 -0400 (EDT) From: Rick Macklem To: Steve Polyack Message-ID: <1767168849.374184.1283357147943.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4C7E743A.1040506@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_374183_1556044666.1283357147941" X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: yanefbsd@gmail.com, freebsd-stable@freebsd.org Subject: Re: NFS 75 second stall 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: Wed, 01 Sep 2010 16:05:49 -0000 ------=_Part_374183_1556044666.1283357147941 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > On 07/01/10 15:23, Garrett Cooper wrote: > > On Thu, Jul 1, 2010 at 11:51 AM, alan bryan > > wrote: > >> > >> --- On Thu, 7/1/10, Garrett Cooper wrote: > >> > >>> From: Garrett Cooper > >>> Subject: Re: NFS 75 second stall > >>> To: "alan bryan" > >>> Cc: freebsd-stable@freebsd.org > >>> Date: Thursday, July 1, 2010, 11:13 AM > >>> On Thu, Jul 1, 2010 at 11:01 AM, alan > >>> bryan > >>> wrote: > >>>> Setup: > >>>> > >>>> server - FreeBSD 8-stable from today. 2 UFS dirs > >>> exported via NFS. > >>>> client - FreeBSD 8.0-Release. Running a test php > >>> script that copies around various files to/from 2 separate > >>> NFS mounts. > >>>> Situation: > >>>> > >>>> script is started (forked to do 20 simultaneous runs) > >>> and 20 1GB files are copied to the NFS dir which works > >>> fine. When it then switches to reading those files back > >>> and simultaneously writing to the other NFS mount I see a > >>> hang of 75 seconds. If I do an "ls -l" on the NFS mount it > >>> hangs too. After 75 seconds the client has reported: > >>>> nfs server 192.168.10.133:/usr/local/export1: not > >>> responding > >>>> nfs server 192.168.10.133:/usr/local/export1: is alive > >>> again > >>>> nfs server 192.168.10.133:/usr/local/export1: not > >>> responding > >>>> nfs server 192.168.10.133:/usr/local/export1: is alive > >>> again > >>>> and then things start working again. The server was > >>> originally FreeBSD 8.0-Release also but was upgraded to the > >>> latest stable to see if this issue could be avoided. > >>>> # nfsstat -s -W -w 1 > >>>> GtAttr Lookup Rdlink Read Write Rename > >>> Access Rddir > >>>> 0 0 0 222 257 > >>> 0 0 0 > >>>> 0 0 0 178 135 > >>> 0 0 0 > >>>> 0 0 0 85 127 > >>> 0 0 0 > >>>> 0 0 0 0 0 > >>> 0 0 0 > >>>> 0 0 0 0 0 > >>> 0 0 0 > >>>> 0 0 0 0 0 > >>> 0 0 0 > >>>> 0 0 0 0 0 > >>> 0 0 0 > >>>> 0 0 0 0 0 > >>> 0 0 0 > >>>> ... for 75 rows of all zeros > >>>> > >>>> 0 0 0 272 266 > >>> 0 0 0 > >>>> 0 0 0 167 165 > >>> 0 0 0 > >>>> I also tried runs with 15 simultaneous processes and > >>> 25. 15 processes gave only about a 5 second stall but 25 > >>> gave again the same 75 second stall. > >>>> Further, I tested with 2 mounts to the same server but > >>> from ZFS filesytems with the exact same stall/timeout > >>> periods. So, it doesn't appear to matter what the > >>> underlying filesystem is - it's something in NFS or > >>> networking code. > >>>> Any ideas on what's going on here? What's causing > >>> the complete stall period of zero NFS activity? Any flaws > >>> with my testing methods? > >>>> Thanks for any and all help/ideas. > >>> What network driver are you using? Have you tried > >>> tcpdumping the packets? > >>> -Garrett > >>> > >> I'm using igb currently but have also used em. I have not tried > >> tcpdumping the packets yet on this test. Any suggestions on things > >> to look out for (I'm not that familiar with that whole process). > >> > >> Which brings up another point - I'm using TCP connections for NFS, > >> not UDP. > > Is the net.inet.tcp.tso sysctl enabled or not? What about > > rxcsum and txcsum? > > Thanks, > > -Garrett > > We're occaisionally seeing these same types of stalls (+ repeated "is > not responding" "is alive again" messages in quick succession). We're > seeing it only on our 8.1-RELEASE systems against a variety of NFS > servers (6.3-RELEASE, 7.2-RELEASE, and 8-STABLE from before the > release > of 8.1). We also see it happen with a variety of client hardware and > network adapters (em, bce, bge); the only common denominator is > 8.1-RELEASE on the clients. > You could try the attached patch. It won't fix anything, but it should print out what the errno is that is causing a TCP reconnect and might give us a hint w.r.t. what is going on. rick ------=_Part_374183_1556044666.1283357147941 Content-Type: text/x-patch; name=clnt_rc.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=clnt_rc.patch LS0tIHJwYy9jbG50X3JjLmMuc2F2CTIwMTAtMDktMDEgMTA6NTY6NTYuMDAwMDAwMDAwIC0wNDAw CisrKyBycGMvY2xudF9yYy5jCTIwMTAtMDktMDEgMTE6MDA6NDkuMDAwMDAwMDAwIC0wNDAwCkBA IC0yNjQsNiArMjY0LDcgQEAKIAkJCW10eF91bmxvY2soJnJjLT5yY19sb2NrKTsKIAkJCXN0YXQg PSBjbG50X3JlY29ubmVjdF9jb25uZWN0KGNsKTsKIAkJCWlmIChzdGF0ID09IFJQQ19TWVNURU1F UlJPUikgeworcHJpbnRmKCJyZWNvbiBlcnI9JWRcbiIsIHJwY19jcmVhdGVlcnIuY2ZfZXJyb3Iu cmVfZXJybm8pOwogCQkJCWVycm9yID0gdHNsZWVwKCZmYWtlX3djaGFuLAogCQkJCSAgICByYy0+ cmNfaW50ciA/IFBDQVRDSCB8IFBCRFJZIDogMCwgInJwY2NvbiIsCiAJCQkJICAgIGh6KTsK ------=_Part_374183_1556044666.1283357147941-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 16:06:28 2010 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 5FD3710656D8 for ; Wed, 1 Sep 2010 16:06:28 +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 2ED998FC2D for ; Wed, 1 Sep 2010 16:06:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B128246B2A; Wed, 1 Sep 2010 12:06:27 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DFD018A03C; Wed, 1 Sep 2010 12:06:26 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 1 Sep 2010 12:06:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009011206.15494.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 01 Sep 2010 12:06:26 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: pluknet Subject: Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR 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: Wed, 01 Sep 2010 16:06:28 -0000 On Wednesday, September 01, 2010 11:53:09 am pluknet wrote: > Hi. > > This is reproducible from time to time on boot when > handling SIOCAIFADDR called from ifconfig on igb > on fresh (and not so fresh) 8-STABLE. > > How can I help with debugging? > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex igb0 (IGB Core Lock) r = 0 (0xc2655534) locked @ > /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965 > KDB: stack backtrace: > db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(3c5,0,ffffffff,c0a94864,cce577f0,...) at kdb_backtrace+0x29 > _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe > trap(cce57890) at trap+0x195 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 --- > e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...) > at e1000_clear_hw_cntrs_base_generic+0x3e7 Can you use gdb on your kernel.debug to map this to a source file and line? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 16:28:22 2010 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 7489E10656A3; Wed, 1 Sep 2010 16:28:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E6E3F8FC18; Wed, 1 Sep 2010 16:28:21 +0000 (UTC) Received: from park.js.berklix.net (p549A5790.dip.t-dialin.net [84.154.87.144]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o81G9sR4030603; Wed, 1 Sep 2010 16:09:55 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o81G9nxa072715; Wed, 1 Sep 2010 18:09:49 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o81G9XEQ011268; Wed, 1 Sep 2010 18:09:38 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201009011609.o81G9XEQ011268@fire.js.berklix.net> To: security-officer@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 01 Sep 2010 08:31:40 PDT." <4C7E71DC.1040808@freebsd.org> Date: Wed, 01 Sep 2010 18:09:33 +0200 Sender: jhs@berklix.com Cc: freebsd security , Deb Goodkin , FreeBSD Stable , gljennjohn@googlemail.com Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon 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: Wed, 01 Sep 2010 16:28:22 -0000 > On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their FreeBSD -7 & -8 do not support ISDN I'm told. So 6.4 is the last working FreeBSD ISDN. DSL is faster than ISDN, but Losing ISDN would be unfortunate: - Not all can get DSL speed, if they live far from phone exchange. - ISDN allows one more security (caller ID comes from phone company), additional to whatever crypto keys/passwords. - ISDN on the PC allows one to have Name (via lookup of number) of phone caller & which incoming destination number received call, show up on an X Term - I've had that with FreeBSD over 10+ years now :-) Could easily be hooked to a database springing up a a custome xterm according to calling customer ID, called number & time of day (all being used to select which service info ) But if we drop ISDN ...! Could FreeBSD reinsert ISDN back into current/8/7 support ? Perhaps via: - a student SOC project ? - FreeBSD foundation paying a FreeBSD consultant (I know one who has the expertise already, has the time, & could use some money (I don't mean me, & he didn't aske me to post this, it'll come as a suprise to him :-) - Or whatever other method to get ISDN back in kernel ? Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 16:51:15 2010 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 23E9E1065695 for ; Wed, 1 Sep 2010 16:51:15 +0000 (UTC) (envelope-from me@janh.de) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id A97DD8FC1D for ; Wed, 1 Sep 2010 16:51:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id 6A008901F5; Wed, 1 Sep 2010 18:33:02 +0200 (CEST) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mWkixs8Ne7k5; Wed, 1 Sep 2010 18:33:02 +0200 (CEST) Received: from pc911.math.uni-hamburg.de (pc911.math.uni-hamburg.de [134.100.220.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 536F9901BF; Wed, 1 Sep 2010 18:33:02 +0200 (CEST) Message-ID: <4C7E803F.1090606@janh.de> Date: Wed, 01 Sep 2010 18:33:03 +0200 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100821 Thunderbird/3.0.6 MIME-Version: 1.0 To: stable-list freebsd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: GSSAPI (for OpenLDAP) on FreeBSD 8? 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: Wed, 01 Sep 2010 16:51:15 -0000 I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) There were at least two discussions, multiple bug reports, and patches about broken GSSAPI on FreeBSD 8, the longest (I found) starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html After reading through these discussions, I do not know what the proper fix is -- I would like to change as little as possible introducing SASL authentication to a (production) OpenLDAP server. I have got: An i386 kerberos server, a ldap server in a jail on i386, some amd64 clients -- all running 8.1-RELEASE. Eventually there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. What do I need to "fix"? Just the ldap server? Is it enough to change the jail or does the host needs to be patches, too? Or do I need to fix the client, too? The kerberos server? From the discussion, multiple fixes were possible. Patching libgssapi and reinstalling everything depending on it (what?), installing the heimdal-1.0 port (while FreeBSD 8 comes with heimdal-1.1), installing an unofficial heimdal-1.2 port, ... Is that correct? Anything new after the discussion in July? From the discussion, some patches should already be in 8-STABLE, but I could not find the revision (after 8.1-RELEASE). If I upgraded the ldap jail to 8-STABLE, I guess the host needs to be updated, too. Hence I would prefer to just change ports or update single libraries. Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? Thanks, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 16:54:19 2010 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 A4CC71065679; Wed, 1 Sep 2010 16:54:19 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 288DD8FC1D; Wed, 1 Sep 2010 16:54:18 +0000 (UTC) Received: from park.js.berklix.net (p549A5790.dip.t-dialin.net [84.154.87.144]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o81GsDJI031180; Wed, 1 Sep 2010 16:54:14 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o81Gs6gq073091; Wed, 1 Sep 2010 18:54:07 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o81Grkm4056064; Wed, 1 Sep 2010 18:53:51 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201009011653.o81Grkm4056064@fire.js.berklix.net> From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 01 Sep 2010 18:09:33 +0200." <201009011609.o81G9XEQ011268@fire.js.berklix.net> Date: Wed, 01 Sep 2010 18:53:46 +0200 Sender: jhs@berklix.com Cc: FreeBSD Stable , Deb Goodkin , Hans Petter Selasky , freebsd security , security-officer@freebsd.org, gljennjohn@googlemail.com Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon 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: Wed, 01 Sep 2010 16:54:19 -0000 > FreeBSD -7 & -8 do not support ISDN I'm told. > So 6.4 is the last working FreeBSD ISDN. > Could FreeBSD reinsert ISDN back into current/8/7 support ? > Perhaps via: > - a student SOC project ? > - FreeBSD foundation paying a FreeBSD consultant (I know one who has the > expertise already, has the time, & could use some money (I don't mean me, > & he didn't aske me to post this, it'll come as a suprise to him :-) > - Or whatever other method to get ISDN back in kernel ? It seems code exists :-) http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html ISDN4BSD package has been updated to compile on FreeBSD 8-current http://www.selasky.org/hans_petter/isdn4bsd/ Apparently needs massaging into main FreeBSD tree. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 17:11:33 2010 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 4195010656AD; Wed, 1 Sep 2010 17:11:33 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BCF1C8FC0A; Wed, 1 Sep 2010 17:11:32 +0000 (UTC) Received: by qwg5 with SMTP id 5so12452qwg.13 for ; Wed, 01 Sep 2010 10:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=086znzPZmodyu1oIlB9IOS2Tvi4HSOG91PRtCZrADAI=; b=OIJHHf8qT/w/SNq3y5/86XV06RYcago3BrFT+qHUKts0gd0ufVV4R9sLv0QtKpPSx6 dgcWUWjfvGHZ9Yzr0uat629JNyXpVo6/1nhdpvMbx4Y9+SVp1uzQeVw4K7UzVaDPMXe/ xZTYyPDjb38ZybcWwO2cN1BQjSlHOvmIvdCtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jJtbK/zPgzQ2Z1uZp6OMoG8K+xhJWnFimJ9isl1+5/SZCL0auLVCkYvf+0pIElbH9m zT2gis5MJopiDoIRZQq8vOFMNUBZlzz+SUD/T/SV0thTb/FxD5DM7pdudbMHg3eJzPQO BbghYej4DHhArEk+Q4UdlBeXg91C+lZb0mOxA= MIME-Version: 1.0 Received: by 10.224.67.6 with SMTP id p6mr5077591qai.58.1283361091714; Wed, 01 Sep 2010 10:11:31 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Wed, 1 Sep 2010 10:11:31 -0700 (PDT) In-Reply-To: <201009011206.15494.jhb@freebsd.org> References: <201009011206.15494.jhb@freebsd.org> Date: Wed, 1 Sep 2010 21:11:31 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR 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: Wed, 01 Sep 2010 17:11:33 -0000 On 1 September 2010 20:06, John Baldwin wrote: > On Wednesday, September 01, 2010 11:53:09 am pluknet wrote: >> Hi. >> >> This is reproducible from time to time on boot when >> handling SIOCAIFADDR called from ifconfig on igb >> on fresh (and not so fresh) 8-STABLE. >> >> How can I help with debugging? >> >> Kernel page fault with the following non-sleepable locks held: >> exclusive sleep mutex igb0 (IGB Core Lock) r =3D 0 (0xc2655534) locked @ >> /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965 >> KDB: stack backtrace: >> db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at >> db_trace_self_wrapper+0x26 >> kdb_backtrace(3c5,0,ffffffff,c0a94864,cce577f0,...) at kdb_backtrace+0x2= 9 >> _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x25 >> witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe >> trap(cce57890) at trap+0x195 >> calltrap() at calltrap+0x6 >> --- trap 0xc, eip =3D 0xc3192477, esp =3D 0xcce578d0, ebp =3D 0xcce578e0= --- >> e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...) >> at e1000_clear_hw_cntrs_base_generic+0x3e7 > > Can you use gdb on your kernel.debug to map this to a source file and lin= e? > Here it is (btw, it took about 10-15 reboots to reproduce after adding swap and dumpon setup). Hmm.. don't see where it might access an invalid pointer. #0 doadump () at pcpu.h:231 #1 0xc04a3679 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1062122144, dummy4=3D0xcce636a8 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04a3a71 in db_command (last_cmdp=3D0xc093d19c, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04a3bca in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04a5aed in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= .c:229 #5 0xc05fa64e in kdb_trap (type=3D12, code=3D0, tf=3D0xcce63890) at /usr/src/sys/kern/subr_kdb.c:535 #6 0xc084dcdf in trap_fatal (frame=3D0xcce63890, eva=3D3428511744) at /usr/src/sys/i386/i386/trap.c:929 #7 0xc084e553 in trap (frame=3D0xcce63890) at /usr/src/sys/i386/i386/trap.= c:328 #8 0xc082f66c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=3D0xc2655004) at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643 #10 0xc317ec82 in igb_init_locked (adapter=3D0xc2655000) at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:1202 #11 0xc31801e5 in igb_ioctl (ifp=3D0xc2943c00, command=3D2149607692, data=3D0xc29db600 "=E2=95=A2=E2=95=A4\235=D0=B1=D0=B4=E2=95=A4\235=D0= =B1=D1=82=E2=95=A4\235=D0=B1") at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:966 #12 0xc0696c4e in in_ifinit (ifp=3D0xc2943c00, ia=3D0xc29db600, sin=3DVariable "sin" is not available. ) at /usr/src/sys/netinet/in.c:848 #13 0xc06980cb in in_control (so=3D0xc2a5d9a8, cmd=3D2151704858, data=3D0xc2649400 "igb0", ifp=3D0xc2943c00, td=3D0xc29b8280) ---Type to continue, or q to quit--- at /usr/src/sys/netinet/in.c:563 #14 0xc067c860 in ifioctl (so=3D0xc2a5d9a8, cmd=3D2151704858, data=3D0xc2649400 "igb0", td=3D0xc29b8280) at /usr/src/sys/net/if.c:252= 3 #15 0xc0617395 in soo_ioctl (fp=3D0xc29ce310, cmd=3D2151704858, data=3D0xc2= 649400, active_cred=3D0xc254b100, td=3D0xc29b8280) at /usr/src/sys/kern/sys_socket.c:212 #16 0xc06113dd in kern_ioctl (td=3D0xc29b8280, fd=3D3, com=3D2151704858, data=3D0xc2649400 "igb0") at file.h:262 #17 0xc0611564 in ioctl (td=3D0xc29b8280, uap=3D0xcce63cf8) at /usr/src/sys/kern/sys_generic.c:678 #18 0xc084e160 in syscall (frame=3D0xcce63d38) at /usr/src/sys/i386/i386/trap.c:1111 #19 0xc082f6d1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:264 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 9 #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=3D0xc2655004) at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643 643 E1000_READ_REG(hw, E1000_SYMERRS); (kgdb) list 638 void e1000_clear_hw_cntrs_base_generic(struct e1000_hw *hw) 639 { 640 DEBUGFUNC("e1000_clear_hw_cntrs_base_generic"); 641 642 E1000_READ_REG(hw, E1000_CRCERRS); 643 E1000_READ_REG(hw, E1000_SYMERRS); 644 E1000_READ_REG(hw, E1000_MPC); 645 E1000_READ_REG(hw, E1000_SCC); 646 E1000_READ_REG(hw, E1000_ECOL); 647 E1000_READ_REG(hw, E1000_MCC); (kgdb) p *(struct e1000_osdep *)hw->back $6 =3D {mem_bus_space_tag =3D 1, mem_bus_space_handle =3D 3428495360, io_bus_space_tag =3D 0, io_bus_space_handle =3D 0, flash_bus_space_tag = =3D 0, flash_bus_space_handle =3D 0, dev =3D 0xc261a600} (kgdb) p *hw [...] power_down =3D 0xc3186340 }, type =3D e1000_p= hy_vf, [...] (kgdb) p (struct e1000_mac_info *)hw->mac.type $8 =3D (struct e1000_mac_info *) 0x1a (kgdb) p *(struct e1000_mac_info *)hw->mac $10 =3D {ops =3D {init_params =3D 0x8be58955, id_led_init =3D 0x80c70845, blink_led =3D 0x390, check_for_link =3D 0, check_mng_mode =3D 0x2d480c7= , cleanup_led =3D 0, clear_hw_cntrs =3D 0x80c70000, clear_vfta =3D 0x2d0, get_bus_info =3D 0, set_lan_id =3D 0x2c880c7, get_link_up_info =3D 0, led_on =3D 0xc7660000, led_off =3D 0xbe80, update_mc_addr_list =3D 0x66= 008000, reset_hw =3D 0x2c480c7, init_hw =3D 0x10000, shutdown_serdes =3D 0xf058= 40c7, power_up_serdes =3D 0xc7c31a4f, setup_link =3D 0x50003040, setup_physical_interface =3D 0x40c7c31a, setup_led =3D 0x1a539048, write_vfta =3D 0x4c40c7c3, config_collision_dist =3D 0xc31a5360 , rar_set =3D 0x901c40c7, read_mac_addr =3D 0xc7c31a55, validate_mdi_setting =3D 0x55103840, mng_host_if_write =3D 0x40c7c31a, mng_write_cmd_header =3D 0x1a502044, mng_enable_host_if =3D 0x6c40c7c3, wait_autoneg =3D 0xc31a52a0 }, addr =3D "=D0=B3@p@R\0= 32", perm_addr =3D "=D1=861=D1=8E]=D1=86\215", type =3D 182, collision_delta = =3D 666668288, ledctl_default =3D 0, ledctl_mode1 =3D 2347075925, ledctl_mode2 =3D 10867= 85605, mc_filter_type =3D 441389072, tx_packet_delta =3D 3095447491, txcw =3D 3758096387, current_ifs_val =3D 6734, ifs_max_val =3D 51139, ifs_min_val =3D 5248, ifs_ratio =3D 3, ifs_step_size =3D 45056, mta_reg_count =3D 6734, uta_reg_count =3D 51139, mta_shadow =3D {18790481= 96, 1573067352, 7769539, 4294883413, 3851026431, 3062743901, 0, 1575323989, 645172675, 666668288, 0, 2311074133, 2311282149, 666668534, 0, 2347075925, 2160527429, 1016, 4, 66879687, 393216, 3224436736, 4136223581, 1474660693, 3968029526, 209554260, 504397187, 1170701942, ---Type to continue, or q to quit--- 503317428, 273008384, 30, 3339212171, 45125, 3071213568, 48770, 9861555= 2, 838817933, 4294672841, 3187671040, 8, 3526433396, 2298593923, 340092924= 0, 4282247379, 1962934272, 573167, 3458793472, 88585743, 72857103, 4052345043, 3490314963, 565204363, 4280641240, 1149855247, 1301002325, 29524752, 967857545, 2199679946, 2817197767, 3239069067, 3364032736, 3024455939, 2232436107, 2038763456, 2348810239, 1166870613, 608487348, 12, 608487168, 4104, 608471296, 605325572, 68719359, 3296919552, 1600019284, 3029189469, 38, 666668288, 0, 2212858197, 1300961516, 1169624848, 139823884, 83379655, 2231369728, 4232415689, 1170671476, 16778488, 4165307648, 203703495, 0, 136594631, 2, 69485705, 4280554633, 268434, 2311309568, 666668534, 0, 2212858197, 3071219948, 1166740565, 4165322504, 5, 203703495, 0, 2382124425, 1153955925, 133156, 1418264576= , 76088356, 412155684, 3372220420, 649366979, 0, 2212858197, 1435180268, 4166879500, 2299026827, 1170734197, 1780, 33194752, 812861556, 3354686861, 795716, 3338665984, 17310788, 2298478592}, rar_entry_count =3D 9332, forced_speed_duplex =3D 4 '\004', adaptive_ifs =3D -1811995620, has_fwsm =3D 1048, arc_subsystem_valid =3D 745848965, asf_firmware_present =3D -1946657397, autoneg =3D -326501259, autoneg_failed =3D -158743715, get_link_status =3D 1946352259, in_ifs_mode =3D 66749261, report_tx_early =3D -1096, serdes_link_state =3D 3353703935, serdes_has_link =3D 455749, tx_pkt_filtering =3D 1300299778} (kgdb) p *hw $13 =3D {back =3D 0xc2659498, hw_addr =3D 0xc265949c "", flash_address =3D = 0x0, io_base =3D 0, mac =3D {ops =3D { init_params =3D 0xc31a4f10 , id_led_init = =3D 0, blink_led =3D 0xc318b140 , check_for_link =3D 0xc31a5590 , check_mng_mode =3D 0xc318b170 , cleanup_led =3D 0xc318b140 , clear_hw_cntrs =3D 0xc318b150 , clear_vfta =3D 0xc318b150 , get_bus_info =3D 0xc31a5000 , set_lan_id =3D 0xc318b9f0 , get_link_up_info =3D 0xc31a5510 , led_on =3D 0xc318b140 , led_off =3D 0xc318b140 , update_mc_addr_list =3D 0xc31a5020 , reset_hw =3D 0xc31a5390 , init_hw =3D 0xc31a5360 , shutdown_serdes =3D 0, power_up_serdes =3D 0, setup_link =3D 0xc31a4ff0 , setup_physical_interface =3D 0xc318b140 , setup_led =3D 0xc318b140 , write_vfta =3D 0xc318b190 , config_collision_dist =3D 0xc318dbf0 , rar_set =3D 0xc31a52a0 , read_mac_addr =3D 0xc31a5240 , ---Type to continue, or q to quit--- validate_mdi_setting =3D 0xc318b490 , mng_host_if_write =3D 0xc318ed90 , mng_write_cmd_header =3D 0xc318f070 , mng_enable_host_if =3D 0xc318e880 , wait_autoneg =3D 0xc3187a20 }, addr =3D "&\177=D0=92h=E2=95=91\221", perm_addr =3D "&\177=D0=92h=E2=95= =91\221", type =3D e1000_vfadapt, collision_delta =3D 0, ledctl_default =3D 0, ledctl_mode1 =3D 0, ledctl_mode2 =3D 0, mc_filter_type =3D 0, tx_packet_delta =3D 0, txcw = =3D 0, current_ifs_val =3D 0, ifs_max_val =3D 0, ifs_min_val =3D 0, ifs_ratio = =3D 0, ifs_step_size =3D 0, mta_reg_count =3D 128, uta_reg_count =3D 0, mta_sh= adow =3D { 0 }, rar_entry_count =3D 1, forced_speed_duplex =3D 0 '\0', adaptive_ifs =3D 0, has_fwsm =3D 0, arc_subsystem_valid =3D 0, asf_firmware_present =3D 0, autoneg =3D 1, autoneg_failed =3D 0, get_link_status =3D 0, in_ifs_mode =3D 0, report_tx_early =3D 0, serdes_link_state =3D e1000_serdes_link_down, serdes_has_link =3D 0, tx_pkt_filtering =3D 0}, fc =3D {high_water =3D = 58976, low_water =3D 58960, pause_time =3D 1664, refresh_time =3D 0, send_xon = =3D 1, strict_ieee =3D 0, current_mode =3D e1000_fc_full, requested_mode =3D e1000_fc_full}, phy =3D {ops =3D { init_params =3D 0xc31a4eb0 , acquire =3D 0xc31a4fd0 , cfg_on_link_up =3D 0xc318b140 , check_polarity =3D 0xc318b140 , check_reset_block =3D 0xc318b140 , ---Type to continue, or q to quit--- commit =3D 0xc318b140 , force_speed_duplex =3D 0xc318b140 , get_cfg_done =3D 0xc318b140 , get_cable_length =3D 0xc318b140 , get_info =3D 0xc318b140 , read_reg =3D 0xc3186330 , read_reg_locked =3D 0xc3186330 , release =3D 0xc31a4fe0 , reset =3D 0xc318b140 , set_d0_lplu_state =3D 0xc3186350 , set_d3_lplu_state =3D 0xc3186350 , write_reg =3D 0xc3186360 , write_reg_locked =3D 0xc3186360 , power_up =3D 0xc3186340 , power_down =3D 0xc3186340 }, type =3D e1000_p= hy_vf, local_rx =3D e1000_1000t_rx_status_not_ok, remote_rx =3D e1000_1000t_rx_status_not_ok, ms_type =3D e1000_ms_hw_def= ault, original_ms_type =3D e1000_ms_hw_default, cable_polarity =3D e1000_rev_polarity_normal, smart_speed =3D e1000_smart_speed_default, addr =3D 0, id =3D 0, reset_delay_us =3D 0, revision =3D 0, media_type =3D e1000_media_type_u= nknown, autoneg_advertised =3D 47, autoneg_mask =3D 0, cable_length =3D 0, max_cable_length =3D 0, min_cable_length =3D 0, mdix =3D 0 '\0', disable_polarity_correction =3D 0, is_mdix =3D 0, polarity_correction = =3D 0, ---Type to continue, or q to quit--- reset_disable =3D 0, speed_downgraded =3D 0, autoneg_wait_to_complete = =3D 0}, nvm =3D {ops =3D {init_params =3D 0xc31a4ee0 , acquire =3D 0xc31a4fd0 , read =3D 0xc3189970 , release =3D 0xc31a4fe0 , reload =3D 0xc318ada0 , update =3D 0xc318b140 , valid_led_default =3D 0xc3189990 , validate =3D 0xc318b140 , write =3D 0xc31899a0 }, type =3D e1000_nvm_none= , override =3D e1000_nvm_override_none, flash_bank_size =3D 0, flash_base_addr =3D 0, word_size =3D 0, delay_usec =3D 0, address_bits = =3D 0, opcode_bits =3D 0, page_size =3D 0}, bus =3D {type =3D e1000_bus_type_r= eserved, speed =3D e1000_bus_speed_2500, width =3D e1000_bus_width_unknown, func= =3D 0, pci_cmd_word =3D 7}, mbx =3D {ops =3D { init_params =3D 0xc31a5870 , read =3D 0xc31a60d0 , write =3D 0xc31a5e80 , read_posted =3D 0xc31a5dd0 , write_posted =3D 0xc31a5d00 , check_for_msg =3D 0xc31a5cd0 , check_for_ack =3D 0xc31a5ca0 , check_for_rst =3D 0xc31a5c70 }, stats =3D { msgs_tx =3D 8, msgs_rx =3D 8, acks =3D 8, reqs =3D 8, rsts =3D 0}, ---Type to continue, or q to quit--- timeout =3D 2000, usec_delay =3D 500, size =3D 16}, mng_cookie =3D { signature =3D 0, status =3D 0 '\0', reserved0 =3D 0 '\0', vlan_id =3D 0= , reserved1 =3D 0, reserved2 =3D 0, reserved3 =3D 0 '\0', checksum =3D 0 = '\0'}, dev_spec =3D {_82541 =3D {dsp_config =3D e1000_dsp_config_disabled, ffe_config =3D e1000_ffe_config_enabled, spd_default =3D 0, phy_init_script =3D 0}, _82542 =3D {dma_fairness =3D 0}, _82543 =3D { tbi_compatibility =3D 0, dma_fairness =3D 0, init_phy_disabled =3D 0}= , _82571 =3D {laa_is_present =3D 0, smb_counter =3D 0}, _80003es2lan =3D = { mdic_wa_enable =3D 0}, ich8lan =3D {kmrn_lock_loss_workaround_enabled= =3D 0, shadow_ram =3D {{value =3D 0, modified =3D 0} }, nvm_mutex =3D {lock_object =3D {lo_name =3D 0x0, lo_flags =3D 0, lo_d= ata =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 0}, swflag_mutex =3D {lock_obje= ct =3D { lo_name =3D 0x0, lo_flags =3D 0, lo_data =3D 0, lo_witness =3D 0x= 0}, mtx_lock =3D 0}, nvm_k1_enabled =3D 0}, _82575 =3D {sgmii_active = =3D 0, global_device_reset =3D 0}, vf =3D {vf_number =3D 0, v2p_mailbox =3D = 0}}, device_id =3D 4298, subsystem_vendor_id =3D 32902, subsystem_device_id = =3D 41020, vendor_id =3D 32902, revision_id =3D 1 '\001'} --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 17:16:17 2010 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 45B8910656C1; Wed, 1 Sep 2010 17:16:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE598FC18; Wed, 1 Sep 2010 17:16:16 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sIybwy0z7bWw0ilx/SziPN3xnsQN4yn8NMXKZM3k7p4= c=1 sm=1 a=_BJ4-cef_n8A:10 a=Q9fys5e9bTEA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=9I5xiGouAAAA:8 a=ndaoGXS1AAAA:8 a=TegXpj-boEs4gfiFrXcA:9 a=IP8rCA5-S-lGEPKSpdXJWKBwWUgA:4 a=PUjeQqilurYA:10 a=xWb-EmPy6c4A:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 14534062; Wed, 01 Sep 2010 19:06:10 +0200 From: Hans Petter Selasky To: "Julian H. Stacey" Date: Wed, 1 Sep 2010 19:02:06 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201009011653.o81Grkm4056064@fire.js.berklix.net> In-Reply-To: <201009011653.o81Grkm4056064@fire.js.berklix.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201009011902.06538.hselasky@c2i.net> Cc: freebsd security , security-officer@freebsd.org, FreeBSD Stable , Deb Goodkin , gljennjohn@googlemail.com Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon 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: Wed, 01 Sep 2010 17:16:17 -0000 On Wednesday 01 September 2010 18:53:46 Julian H. Stacey wrote: > > FreeBSD -7 & -8 do not support ISDN I'm told. > > So 6.4 is the last working FreeBSD ISDN. > > > > Could FreeBSD reinsert ISDN back into current/8/7 support ? > > Perhaps via: > > - a student SOC project ? > > - FreeBSD foundation paying a FreeBSD consultant (I know one who has the > > > > expertise already, has the time, & could use some money (I don't mean > > me, & he didn't aske me to post this, it'll come as a suprise to him > > :-) > > > > - Or whatever other method to get ISDN back in kernel ? > > It seems code exists :-) > > http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html > ISDN4BSD package has been updated to compile on FreeBSD > 8-current > > http://www.selasky.org/hans_petter/isdn4bsd/ > > Apparently needs massaging into main FreeBSD tree. I agree that my I4B code should be re-written somewhat before committed. Possibly we should update the API's present too, to support IP-telephony aswell. --HPS From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 17:17:54 2010 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 C1A9710656CF; Wed, 1 Sep 2010 17:17:54 +0000 (UTC) (envelope-from emss.mail@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 E8DEE8FC29; Wed, 1 Sep 2010 17:17:53 +0000 (UTC) Received: by wwb34 with SMTP id 34so8847094wwb.31 for ; Wed, 01 Sep 2010 10:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received :x-virus-scanned:received:received:to:cc:subject:from:in-reply-to :references:x-operating-system:date:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=j2SSUiAMxTxNSTS+kUSQulmGNsJdF7ITb3TcVylVJ8o=; b=xHKq/oak49DK+zFDOTXG3jjYEXkEnjelbS/2Vgke6Mm3Rkg6TqInvThjOgiDiKoatF S/P3PmKS3UFBFEBex+/pY8goetZGDb4+tlezySuKjtYCxW/sxu/VRmfypAB2sY+/6+Oo rTXsbZyWjV+TXZXJZhAvT8p0cWS0zOU0+F2MQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:x-virus-scanned:to:cc:subject:from:in-reply-to:references :x-operating-system:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; b=dT+LFmtBmJ9uBmSmJHGj6TYfGB4SWj/MUoENbVLo4HSGgezdwjYhSRE9RVDpnwwlCY RipUMOiXnjlz/rQ8u2/GYQ51+eIAkgWZ1rtGfLQl+WpoWRGiCzxht2UoohcsDlLarilx Vm7DFwS6j1pFwHHrqi4AuPlMteKY9xPidKAww= Received: by 10.227.134.69 with SMTP id i5mr8255889wbt.165.1283359946996; Wed, 01 Sep 2010 09:52:26 -0700 (PDT) Received: from srvbsdfenssv.interne.associated-bears.org (LCaen-151-92-21-48.w217-128.abo.wanadoo.fr [217.128.200.48]) by mx.google.com with ESMTPS id m25sm8977199wbc.19.2010.09.01.09.52.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Sep 2010 09:52:25 -0700 (PDT) Sender: Eric Masson Received: from srvbsdfenssv.interne.associated-bears.org (localhost [127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id C3EDA1CD41; Wed, 1 Sep 2010 18:52:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at interne.associated-bears.org Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (srvbsdfenssv.interne.associated-bears.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMwNAvJKWbij; Wed, 1 Sep 2010 18:52:19 +0200 (CEST) Received: by srvbsdfenssv.interne.associated-bears.org (Postfix, from userid 1001) id DDA371CD24; Wed, 1 Sep 2010 18:52:19 +0200 (CEST) To: "Julian H. Stacey" From: Eric Masson In-Reply-To: <201009011609.o81G9XEQ011268@fire.js.berklix.net> (Julian H. Stacey's message of "Wed, 01 Sep 2010 18:09:33 +0200") References: <201009011609.o81G9XEQ011268@fire.js.berklix.net> X-Operating-System: FreeBSD 8.1-RELEASE amd64 Date: Wed, 01 Sep 2010 18:52:19 +0200 Message-ID: <8662ypo18c.fsf@srvbsdfenssv.interne.associated-bears.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd security , security-officer@freebsd.org, FreeBSD Stable , Deb Goodkin , gljennjohn@googlemail.com Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon 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: Wed, 01 Sep 2010 17:17:54 -0000 "Julian H. Stacey" writes: Hello, > FreeBSD -7 & -8 do not support ISDN I'm told. It seems that hps@ maintains an isdn stack outside of freebsd tree : http://www.selasky.org/hans_petter/isdn4bsd/ Regards Éric Masson -- >Une RedHat (je ne connais pas les autres distributions) ce configure >aussi simplement que windows pour un poste client. Hélas, elle génère un maximum de traffic sur Usenet -+- TP in guide du linuxien pervers - "Je veux revoir ma SLS ! -+- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 17:25:03 2010 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 BC5E2106574A for ; Wed, 1 Sep 2010 17:25:03 +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 73B798FC08 for ; Wed, 1 Sep 2010 17:25:03 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0A88746B06; Wed, 1 Sep 2010 13:25:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BA2A98A04E; Wed, 1 Sep 2010 13:25:01 -0400 (EDT) From: John Baldwin To: pluknet Date: Wed, 1 Sep 2010 13:24:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009011206.15494.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201009011324.59934.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 01 Sep 2010 13:25:01 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR 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: Wed, 01 Sep 2010 17:25:03 -0000 On Wednesday, September 01, 2010 1:11:31 pm pluknet wrote: > On 1 September 2010 20:06, John Baldwin wrote: > > On Wednesday, September 01, 2010 11:53:09 am pluknet wrote: > >> Hi. > >> > >> This is reproducible from time to time on boot when > >> handling SIOCAIFADDR called from ifconfig on igb > >> on fresh (and not so fresh) 8-STABLE. > >> > >> How can I help with debugging? > >> > >> Kernel page fault with the following non-sleepable locks held: > >> exclusive sleep mutex igb0 (IGB Core Lock) r =3D 0 (0xc2655534) locked= @ > >> /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965 > >> KDB: stack backtrace: > >> db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at > >> db_trace_self_wrapper+0x26 > >> kdb_backtrace(3c5,0,ffffffff,c0a94864,cce577f0,...) at kdb_backtrace+0= x29 > >> _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x= 25 > >> witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe > >> trap(cce57890) at trap+0x195 > >> calltrap() at calltrap+0x6 > >> --- trap 0xc, eip =3D 0xc3192477, esp =3D 0xcce578d0, ebp =3D 0xcce578= e0 --- > >> e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...) > >> at e1000_clear_hw_cntrs_base_generic+0x3e7 > > > > Can you use gdb on your kernel.debug to map this to a source file and=20 line? > > >=20 > Here it is (btw, it took about 10-15 reboots to reproduce after adding > swap and dumpon setup). > Hmm.. don't see where it might access an invalid pointer. >=20 > #0 doadump () at pcpu.h:231 > #1 0xc04a3679 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1062122144, > dummy4=3D0xcce636a8 "") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04a3a71 in db_command (last_cmdp=3D0xc093d19c, cmd_table=3D0x0,=20 dopager=3D1) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04a3bca in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04a5aed in db_trap (type=3D12, code=3D0) at=20 /usr/src/sys/ddb/db_main.c:229 > #5 0xc05fa64e in kdb_trap (type=3D12, code=3D0, tf=3D0xcce63890) > at /usr/src/sys/kern/subr_kdb.c:535 > #6 0xc084dcdf in trap_fatal (frame=3D0xcce63890, eva=3D3428511744) > at /usr/src/sys/i386/i386/trap.c:929 > #7 0xc084e553 in trap (frame=3D0xcce63890) at=20 /usr/src/sys/i386/i386/trap.c:328 > #8 0xc082f66c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=3D0xc2655004) > at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643 > #10 0xc317ec82 in igb_init_locked (adapter=3D0xc2655000) > at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:1202 > #11 0xc31801e5 in igb_ioctl (ifp=3D0xc2943c00, command=3D2149607692, > data=3D0xc29db600 "=E2=95=A2=E2=95=A4\235=D0=B1=D0=B4=E2=95=A4\235=D0= =B1=D1=82=E2=95=A4\235=D0=B1") > at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:966 > #12 0xc0696c4e in in_ifinit (ifp=3D0xc2943c00, ia=3D0xc29db600, > sin=3DVariable "sin" is not available. > ) > at /usr/src/sys/netinet/in.c:848 > #13 0xc06980cb in in_control (so=3D0xc2a5d9a8, cmd=3D2151704858, > data=3D0xc2649400 "igb0", ifp=3D0xc2943c00, td=3D0xc29b8280) > ---Type to continue, or q to quit--- > at /usr/src/sys/netinet/in.c:563 > #14 0xc067c860 in ifioctl (so=3D0xc2a5d9a8, cmd=3D2151704858, > data=3D0xc2649400 "igb0", td=3D0xc29b8280) at /usr/src/sys/net/if.c:2= 523 > #15 0xc0617395 in soo_ioctl (fp=3D0xc29ce310, cmd=3D2151704858, data=3D0x= c2649400, > active_cred=3D0xc254b100, td=3D0xc29b8280) > at /usr/src/sys/kern/sys_socket.c:212 > #16 0xc06113dd in kern_ioctl (td=3D0xc29b8280, fd=3D3, com=3D2151704858, > data=3D0xc2649400 "igb0") at file.h:262 > #17 0xc0611564 in ioctl (td=3D0xc29b8280, uap=3D0xcce63cf8) > at /usr/src/sys/kern/sys_generic.c:678 > #18 0xc084e160 in syscall (frame=3D0xcce63d38) > at /usr/src/sys/i386/i386/trap.c:1111 > #19 0xc082f6d1 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:264 > #20 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 > (kgdb) f 9 > #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=3D0xc2655004) > at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643 > 643 E1000_READ_REG(hw, E1000_SYMERRS); > (kgdb) list > 638 void e1000_clear_hw_cntrs_base_generic(struct e1000_hw *hw) > 639 { > 640 DEBUGFUNC("e1000_clear_hw_cntrs_base_generic"); > 641 > 642 E1000_READ_REG(hw, E1000_CRCERRS); > 643 E1000_READ_REG(hw, E1000_SYMERRS); > 644 E1000_READ_REG(hw, E1000_MPC); > 645 E1000_READ_REG(hw, E1000_SCC); > 646 E1000_READ_REG(hw, E1000_ECOL); > 647 E1000_READ_REG(hw, E1000_MCC); >=20 > (kgdb) p *(struct e1000_osdep *)hw->back > $6 =3D {mem_bus_space_tag =3D 1, mem_bus_space_handle =3D 3428495360, > io_bus_space_tag =3D 0, io_bus_space_handle =3D 0, flash_bus_space_tag = =3D 0, > flash_bus_space_handle =3D 0, dev =3D 0xc261a600} >=20 > (kgdb) p *hw > [...] > power_down =3D 0xc3186340 }, type =3D=20 e1000_phy_vf, > [...] >=20 > (kgdb) p (struct e1000_mac_info *)hw->mac.type > $8 =3D (struct e1000_mac_info *) 0x1a >=20 > (kgdb) p *(struct e1000_mac_info *)hw->mac > $10 =3D {ops =3D {init_params =3D 0x8be58955, id_led_init =3D 0x80c70845, > blink_led =3D 0x390, check_for_link =3D 0, check_mng_mode =3D 0x2d480= c7, > cleanup_led =3D 0, clear_hw_cntrs =3D 0x80c70000, clear_vfta =3D 0x2d= 0, > get_bus_info =3D 0, set_lan_id =3D 0x2c880c7, get_link_up_info =3D 0, > led_on =3D 0xc7660000, led_off =3D 0xbe80, update_mc_addr_list =3D 0x= 66008000, > reset_hw =3D 0x2c480c7, init_hw =3D 0x10000, shutdown_serdes =3D 0xf0= 5840c7, > power_up_serdes =3D 0xc7c31a4f, setup_link =3D 0x50003040, > setup_physical_interface =3D 0x40c7c31a, setup_led =3D 0x1a539048, > write_vfta =3D 0x4c40c7c3, > config_collision_dist =3D 0xc31a5360 , > rar_set =3D 0x901c40c7, read_mac_addr =3D 0xc7c31a55, > validate_mdi_setting =3D 0x55103840, mng_host_if_write =3D 0x40c7c31a, > mng_write_cmd_header =3D 0x1a502044, mng_enable_host_if =3D 0x6c40c7c= 3, > wait_autoneg =3D 0xc31a52a0 }, addr =3D "=D0=B3@p@R= \032", > perm_addr =3D "=D1=861=D1=8E]=D1=86\215", type =3D 182, collision_delta= =3D 666668288, > ledctl_default =3D 0, ledctl_mode1 =3D 2347075925, ledctl_mode2 =3D 108= 6785605, > mc_filter_type =3D 441389072, tx_packet_delta =3D 3095447491, > txcw =3D 3758096387, current_ifs_val =3D 6734, ifs_max_val =3D 51139, > ifs_min_val =3D 5248, ifs_ratio =3D 3, ifs_step_size =3D 45056, > mta_reg_count =3D 6734, uta_reg_count =3D 51139, mta_shadow =3D {187904= 8196, > 1573067352, 7769539, 4294883413, 3851026431, 3062743901, 0, 157532398= 9, > 645172675, 666668288, 0, 2311074133, 2311282149, 666668534, 0, > 2347075925, 2160527429, 1016, 4, 66879687, 393216, 3224436736, > 4136223581, 1474660693, 3968029526, 209554260, 504397187, 1170701942, > ---Type to continue, or q to quit--- > 503317428, 273008384, 30, 3339212171, 45125, 3071213568, 48770,=20 98615552, > 838817933, 4294672841, 3187671040, 8, 3526433396, 2298593923,=20 3400929240, > 4282247379, 1962934272, 573167, 3458793472, 88585743, 72857103, > 4052345043, 3490314963, 565204363, 4280641240, 1149855247, 1301002325, > 29524752, 967857545, 2199679946, 2817197767, 3239069067, 3364032736, > 3024455939, 2232436107, 2038763456, 2348810239, 1166870613, 608487348, > 12, 608487168, 4104, 608471296, 605325572, 68719359, 3296919552, > 1600019284, 3029189469, 38, 666668288, 0, 2212858197, 1300961516, > 1169624848, 139823884, 83379655, 2231369728, 4232415689, 1170671476, > 16778488, 4165307648, 203703495, 0, 136594631, 2, 69485705, 428055463= 3, > 268434, 2311309568, 666668534, 0, 2212858197, 3071219948, 1166740565, > 4165322504, 5, 203703495, 0, 2382124425, 1153955925, 133156, 14182645= 76, > 76088356, 412155684, 3372220420, 649366979, 0, 2212858197, 1435180268, > 4166879500, 2299026827, 1170734197, 1780, 33194752, 812861556, > 3354686861, 795716, 3338665984, 17310788, 2298478592}, > rar_entry_count =3D 9332, forced_speed_duplex =3D 4 '\004', > adaptive_ifs =3D -1811995620, has_fwsm =3D 1048, > arc_subsystem_valid =3D 745848965, asf_firmware_present =3D -1946657397, > autoneg =3D -326501259, autoneg_failed =3D -158743715, > get_link_status =3D 1946352259, in_ifs_mode =3D 66749261, > report_tx_early =3D -1096, serdes_link_state =3D 3353703935, > serdes_has_link =3D 455749, tx_pkt_filtering =3D 1300299778} >=20 > (kgdb) p *hw > $13 =3D {back =3D 0xc2659498, hw_addr =3D 0xc265949c "", flash_address = =3D 0x0, > io_base =3D 0, mac =3D {ops =3D { > init_params =3D 0xc31a4f10 , id_led_init = =3D 0, Hmm, this is a VF interface. I know that VF adapters have a different set = of=20 stats than all the other e1000 adapters. Perhaps that is related? Maybe m= ake=20 the call to e1000_clear_hw_cntrs_base_generic() in igb_init_locked() conditional on 'if (adapter->hw.mac.type !=3D e1000_vfadapt)'? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 17:31:19 2010 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 0D5F510656C2; Wed, 1 Sep 2010 17:31:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0458FC0A; Wed, 1 Sep 2010 17:31:17 +0000 (UTC) Received: by eyx24 with SMTP id 24so5092429eyx.13 for ; Wed, 01 Sep 2010 10:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=k1iQjOlJaeaTH4VX8zsfUllfj9P+Cov3qSg7a/0a7ag=; b=VZjn3W/RYmg39eG+SSPiaHclKdAd+DcI+3xyWouqD4LDeo7rfsqG0aK19AzcRb4ueW NLn9R3JRFT4fww0Ggb/Ut5mCyQ/pQarYZofAA5Cu45vTSuyYS0GbnhQQd6oSpAUsKR/O jOzl8Updgn8/cDb+lemK72H1dUtU/KjDyYyss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tPikcunr2rtXidczZgAM98b0QNri45VdRrUG6KAaZhefANMXqvMrdIZ+IXl/L9tp9c fo8C72F8JUqmHToG3XsXrGqxQyM9cRhTUx1Ls40wtKavYZwqlsst0ORjfphA8xwu9qNN fMegzz5gDsARRaX4cpWKSSDEs+UIcICBi5n2s= MIME-Version: 1.0 Received: by 10.216.23.129 with SMTP id v1mr575140wev.49.1283362277023; Wed, 01 Sep 2010 10:31:17 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Wed, 1 Sep 2010 10:31:15 -0700 (PDT) In-Reply-To: <201009011324.59934.jhb@freebsd.org> References: <201009011206.15494.jhb@freebsd.org> <201009011324.59934.jhb@freebsd.org> Date: Wed, 1 Sep 2010 10:31:15 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pluknet , freebsd-stable@freebsd.org Subject: Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR 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: Wed, 01 Sep 2010 17:31:19 -0000 LOL, if its the VF its pretty new code, PLEASE anyone, if this is the case make it clear in the title somewhere, ok? Thanks. Jack On Wed, Sep 1, 2010 at 10:24 AM, John Baldwin wrote: > On Wednesday, September 01, 2010 1:11:31 pm pluknet wrote: > > On 1 September 2010 20:06, John Baldwin wrote: > > > On Wednesday, September 01, 2010 11:53:09 am pluknet wrote: > > >> Hi. > > >> > > >> This is reproducible from time to time on boot when > > >> handling SIOCAIFADDR called from ifconfig on igb > > >> on fresh (and not so fresh) 8-STABLE. > > >> > > >> How can I help with debugging? > > >> > > >> Kernel page fault with the following non-sleepable locks held: > > >> exclusive sleep mutex igb0 (IGB Core Lock) r =3D 0 (0xc2655534) lock= ed @ > > >> /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965 > > >> KDB: stack backtrace: > > >> db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at > > >> db_trace_self_wrapper+0x26 > > >> kdb_backtrace(3c5,0,ffffffff,c0a94864,cce577f0,...) at > kdb_backtrace+0x29 > > >> _witness_debugger(c08b74fe,cce57804,4,1,0,...) at > _witness_debugger+0x25 > > >> witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1= fe > > >> trap(cce57890) at trap+0x195 > > >> calltrap() at calltrap+0x6 > > >> --- trap 0xc, eip =3D 0xc3192477, esp =3D 0xcce578d0, ebp =3D 0xcce5= 78e0 --- > > >> e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,..= .) > > >> at e1000_clear_hw_cntrs_base_generic+0x3e7 > > > > > > Can you use gdb on your kernel.debug to map this to a source file and > line? > > > > > > > Here it is (btw, it took about 10-15 reboots to reproduce after adding > > swap and dumpon setup). > > Hmm.. don't see where it might access an invalid pointer. > > > > #0 doadump () at pcpu.h:231 > > #1 0xc04a3679 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-10621221= 44, > > dummy4=3D0xcce636a8 "") at /usr/src/sys/ddb/db_command.c:548 > > #2 0xc04a3a71 in db_command (last_cmdp=3D0xc093d19c, cmd_table=3D0x0, > dopager=3D1) > > at /usr/src/sys/ddb/db_command.c:445 > > #3 0xc04a3bca in db_command_loop () at /usr/src/sys/ddb/db_command.c:4= 98 > > #4 0xc04a5aed in db_trap (type=3D12, code=3D0) at > /usr/src/sys/ddb/db_main.c:229 > > #5 0xc05fa64e in kdb_trap (type=3D12, code=3D0, tf=3D0xcce63890) > > at /usr/src/sys/kern/subr_kdb.c:535 > > #6 0xc084dcdf in trap_fatal (frame=3D0xcce63890, eva=3D3428511744) > > at /usr/src/sys/i386/i386/trap.c:929 > > #7 0xc084e553 in trap (frame=3D0xcce63890) at > /usr/src/sys/i386/i386/trap.c:328 > > #8 0xc082f66c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > > #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=3D0xc2655004) > > at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643 > > #10 0xc317ec82 in igb_init_locked (adapter=3D0xc2655000) > > at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:1202 > > #11 0xc31801e5 in igb_ioctl (ifp=3D0xc2943c00, command=3D2149607692, > > data=3D0xc29db600 "=E2=95=A2=E2=95=A4\235=D0=B1=D0=B4=E2=95=A4\235= =D0=B1=D1=82=E2=95=A4\235=D0=B1") > > at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:966 > > #12 0xc0696c4e in in_ifinit (ifp=3D0xc2943c00, ia=3D0xc29db600, > > sin=3DVariable "sin" is not available. > > ) > > at /usr/src/sys/netinet/in.c:848 > > #13 0xc06980cb in in_control (so=3D0xc2a5d9a8, cmd=3D2151704858, > > data=3D0xc2649400 "igb0", ifp=3D0xc2943c00, td=3D0xc29b8280) > > ---Type to continue, or q to quit--- > > at /usr/src/sys/netinet/in.c:563 > > #14 0xc067c860 in ifioctl (so=3D0xc2a5d9a8, cmd=3D2151704858, > > data=3D0xc2649400 "igb0", td=3D0xc29b8280) at /usr/src/sys/net/if.c= :2523 > > #15 0xc0617395 in soo_ioctl (fp=3D0xc29ce310, cmd=3D2151704858, > data=3D0xc2649400, > > active_cred=3D0xc254b100, td=3D0xc29b8280) > > at /usr/src/sys/kern/sys_socket.c:212 > > #16 0xc06113dd in kern_ioctl (td=3D0xc29b8280, fd=3D3, com=3D2151704858= , > > data=3D0xc2649400 "igb0") at file.h:262 > > #17 0xc0611564 in ioctl (td=3D0xc29b8280, uap=3D0xcce63cf8) > > at /usr/src/sys/kern/sys_generic.c:678 > > #18 0xc084e160 in syscall (frame=3D0xcce63d38) > > at /usr/src/sys/i386/i386/trap.c:1111 > > #19 0xc082f6d1 in Xint0x80_syscall () > > at /usr/src/sys/i386/i386/exception.s:264 > > #20 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > > > (kgdb) f 9 > > #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=3D0xc2655004) > > at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643 > > 643 E1000_READ_REG(hw, E1000_SYMERRS); > > (kgdb) list > > 638 void e1000_clear_hw_cntrs_base_generic(struct e1000_hw *hw) > > 639 { > > 640 DEBUGFUNC("e1000_clear_hw_cntrs_base_generic"); > > 641 > > 642 E1000_READ_REG(hw, E1000_CRCERRS); > > 643 E1000_READ_REG(hw, E1000_SYMERRS); > > 644 E1000_READ_REG(hw, E1000_MPC); > > 645 E1000_READ_REG(hw, E1000_SCC); > > 646 E1000_READ_REG(hw, E1000_ECOL); > > 647 E1000_READ_REG(hw, E1000_MCC); > > > > (kgdb) p *(struct e1000_osdep *)hw->back > > $6 =3D {mem_bus_space_tag =3D 1, mem_bus_space_handle =3D 3428495360, > > io_bus_space_tag =3D 0, io_bus_space_handle =3D 0, flash_bus_space_ta= g =3D 0, > > flash_bus_space_handle =3D 0, dev =3D 0xc261a600} > > > > (kgdb) p *hw > > [...] > > power_down =3D 0xc3186340 }, type =3D > e1000_phy_vf, > > [...] > > > > (kgdb) p (struct e1000_mac_info *)hw->mac.type > > $8 =3D (struct e1000_mac_info *) 0x1a > > > > (kgdb) p *(struct e1000_mac_info *)hw->mac > > $10 =3D {ops =3D {init_params =3D 0x8be58955, id_led_init =3D 0x80c7084= 5, > > blink_led =3D 0x390, check_for_link =3D 0, check_mng_mode =3D 0x2d4= 80c7, > > cleanup_led =3D 0, clear_hw_cntrs =3D 0x80c70000, clear_vfta =3D 0x= 2d0, > > get_bus_info =3D 0, set_lan_id =3D 0x2c880c7, get_link_up_info =3D = 0, > > led_on =3D 0xc7660000, led_off =3D 0xbe80, update_mc_addr_list =3D > 0x66008000, > > reset_hw =3D 0x2c480c7, init_hw =3D 0x10000, shutdown_serdes =3D > 0xf05840c7, > > power_up_serdes =3D 0xc7c31a4f, setup_link =3D 0x50003040, > > setup_physical_interface =3D 0x40c7c31a, setup_led =3D 0x1a539048, > > write_vfta =3D 0x4c40c7c3, > > config_collision_dist =3D 0xc31a5360 , > > rar_set =3D 0x901c40c7, read_mac_addr =3D 0xc7c31a55, > > validate_mdi_setting =3D 0x55103840, mng_host_if_write =3D 0x40c7c3= 1a, > > mng_write_cmd_header =3D 0x1a502044, mng_enable_host_if =3D 0x6c40c= 7c3, > > wait_autoneg =3D 0xc31a52a0 }, addr =3D "=D0=B3@p= @R\032", > > perm_addr =3D "=D1=861=D1=8E]=D1=86\215", type =3D 182, collision_del= ta =3D 666668288, > > ledctl_default =3D 0, ledctl_mode1 =3D 2347075925, ledctl_mode2 =3D > 1086785605, > > mc_filter_type =3D 441389072, tx_packet_delta =3D 3095447491, > > txcw =3D 3758096387, current_ifs_val =3D 6734, ifs_max_val =3D 51139, > > ifs_min_val =3D 5248, ifs_ratio =3D 3, ifs_step_size =3D 45056, > > mta_reg_count =3D 6734, uta_reg_count =3D 51139, mta_shadow =3D {1879= 048196, > > 1573067352, 7769539, 4294883413, 3851026431, 3062743901, 0, > 1575323989, > > 645172675, 666668288, 0, 2311074133, 2311282149, 666668534, 0, > > 2347075925, 2160527429, 1016, 4, 66879687, 393216, 3224436736, > > 4136223581, 1474660693, 3968029526, 209554260, 504397187, 117070194= 2, > > ---Type to continue, or q to quit--- > > 503317428, 273008384, 30, 3339212171, 45125, 3071213568, 48770, > 98615552, > > 838817933, 4294672841, 3187671040, 8, 3526433396, 2298593923, > 3400929240, > > 4282247379, 1962934272, 573167, 3458793472, 88585743, 72857103, > > 4052345043, 3490314963, 565204363, 4280641240, 1149855247, > 1301002325, > > 29524752, 967857545, 2199679946, 2817197767, 3239069067, 3364032736= , > > 3024455939, 2232436107, 2038763456, 2348810239, 1166870613, > 608487348, > > 12, 608487168, 4104, 608471296, 605325572, 68719359, 3296919552, > > 1600019284, 3029189469, 38, 666668288, 0, 2212858197, 1300961516, > > 1169624848, 139823884, 83379655, 2231369728, 4232415689, 1170671476= , > > 16778488, 4165307648, 203703495, 0, 136594631, 2, 69485705, > 4280554633, > > 268434, 2311309568, 666668534, 0, 2212858197, 3071219948, 116674056= 5, > > 4165322504, 5, 203703495, 0, 2382124425, 1153955925, 133156, > 1418264576, > > 76088356, 412155684, 3372220420, 649366979, 0, 2212858197, > 1435180268, > > 4166879500, 2299026827, 1170734197, 1780, 33194752, 812861556, > > 3354686861, 795716, 3338665984, 17310788, 2298478592}, > > rar_entry_count =3D 9332, forced_speed_duplex =3D 4 '\004', > > adaptive_ifs =3D -1811995620, has_fwsm =3D 1048, > > arc_subsystem_valid =3D 745848965, asf_firmware_present =3D -19466573= 97, > > autoneg =3D -326501259, autoneg_failed =3D -158743715, > > get_link_status =3D 1946352259, in_ifs_mode =3D 66749261, > > report_tx_early =3D -1096, serdes_link_state =3D 3353703935, > > serdes_has_link =3D 455749, tx_pkt_filtering =3D 1300299778} > > > > (kgdb) p *hw > > $13 =3D {back =3D 0xc2659498, hw_addr =3D 0xc265949c "", flash_address = =3D 0x0, > > io_base =3D 0, mac =3D {ops =3D { > > init_params =3D 0xc31a4f10 , id_led_ini= t =3D > 0, > > Hmm, this is a VF interface. I know that VF adapters have a different se= t > of > stats than all the other e1000 adapters. Perhaps that is related? Maybe > make > the call to e1000_clear_hw_cntrs_base_generic() in igb_init_locked() > conditional on 'if (adapter->hw.mac.type !=3D e1000_vfadapt)'? > > -- > John Baldwin > _______________________________________________ > 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 Wed Sep 1 18:01:51 2010 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 1DCDC10656B8; Wed, 1 Sep 2010 18:01:51 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id A9D358FC16; Wed, 1 Sep 2010 18:01:50 +0000 (UTC) Received: by qyk4 with SMTP id 4so8862294qyk.13 for ; Wed, 01 Sep 2010 11:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=b6bNq1GRuQRnF2NvjEjy8H9SgiODK4GkgwSDdXfYjk0=; b=nB93+B3gt5X9Kwp0E/0Z778vJbwatj1SOIK3lfa1U1yH0FC6mKZ52meSoG86lk2m/8 mwfaNitVvhxLaXIMZ2uxwDW2gV6sZAN2t3vTfAIwW0sQRKjOxZi5LnV2WtLHjxbhRw0a GtrydX6GR1HRLx+DYBh1TZQfm+ViGT44hmWA8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eLZ2SnCb0NMPxTc1NNIL2KzX4aTnLKCf0xzMFApUg3qTqj/X34SQtydeOQgpMHMC8D uTWWDZtKuB2FfW6Mq2MMPX5gngN3+GIu9oE7tkNQsBCqDcSYQP0alvw+opMjV8oTr4Vy vYipT4lySm5wJm+PAeyRIPVdBZLkaR/350TJc= MIME-Version: 1.0 Received: by 10.224.53.161 with SMTP id m33mr5315589qag.356.1283364109696; Wed, 01 Sep 2010 11:01:49 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Wed, 1 Sep 2010 11:01:49 -0700 (PDT) In-Reply-To: References: <201009011206.15494.jhb@freebsd.org> <201009011324.59934.jhb@freebsd.org> Date: Wed, 1 Sep 2010 22:01:49 +0400 Message-ID: From: pluknet To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR 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: Wed, 01 Sep 2010 18:01:51 -0000 On 1 September 2010 21:31, Jack Vogel wrote: > LOL, if its the VF its pretty new code, PLEASE anyone, if this is the case > make it clear in the title somewhere, ok? Thanks. > Sure, this is the VF. I'm sorry, I didn't mention this directly. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 18:26:34 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1C3BB10657C8; Wed, 1 Sep 2010 18:26:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Wed, 1 Sep 2010 14:26:22 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C77F6D6.9020402@icyb.net.ua> <201008271536.08773.jkim@FreeBSD.org> In-Reply-To: <201008271536.08773.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009011426.26111.jkim@FreeBSD.org> Cc: jeff@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly 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: Wed, 01 Sep 2010 18:26:34 -0000 On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote: > [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and > my patch won't work on them. If anyone has a Bulldozer sample, > please look into it. I checked AMD website today and found out a new CPUID Spec. Rev. 2.34 was just released: http://support.amd.com/us/Embedded_TechDocs/25481.pdf They have added CPUID 0x8000001d and 0x8000001e to detect topology, it seems. Also, CPUID 0x80000001 %ecx bit 22 (TopologyExtensions) tells you whether the above CPUID functions are supported. Interesting... Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 19:36:32 2010 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 A0AF31065675; Wed, 1 Sep 2010 19:36:32 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF968FC12; Wed, 1 Sep 2010 19:36:31 +0000 (UTC) Received: from park.js.berklix.net (p549A5790.dip.t-dialin.net [84.154.87.144]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o81JaQFA032988; Wed, 1 Sep 2010 19:36:26 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o81JaNgT073932; Wed, 1 Sep 2010 21:36:23 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o81Ja2bo046886; Wed, 1 Sep 2010 21:36:07 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201009011936.o81Ja2bo046886@fire.js.berklix.net> To: Hans Petter Selasky From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 01 Sep 2010 19:02:06 +0200." <201009011902.06538.hselasky@c2i.net> Date: Wed, 01 Sep 2010 21:36:02 +0200 Sender: jhs@berklix.com Cc: freebsd security , security-officer@freebsd.org, FreeBSD Stable , Deb Goodkin , gljennjohn@googlemail.com Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon 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: Wed, 01 Sep 2010 19:36:32 -0000 Hans Petter Selasky wrote: > On Wednesday 01 September 2010 18:53:46 Julian H. Stacey wrote: > > > FreeBSD -7 & -8 do not support ISDN I'm told. > > > So 6.4 is the last working FreeBSD ISDN. > > > > > > Could FreeBSD reinsert ISDN back into current/8/7 support ? > > > Perhaps via: > > > - a student SOC project ? > > > - FreeBSD foundation paying a FreeBSD consultant (I know one who has the > > > > > > expertise already, has the time, & could use some money (I don't mean > > > me, & he didn't aske me to post this, it'll come as a suprise to him > > > :-) > > > > > > - Or whatever other method to get ISDN back in kernel ? > > > > It seems code exists :-) > > > > http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html > > ISDN4BSD package has been updated to compile on FreeBSD > > 8-current > > > > http://www.selasky.org/hans_petter/isdn4bsd/ > > > > Apparently needs massaging into main FreeBSD tree. > > I agree that my I4B code should be re-written somewhat before committed. > Possibly we should update the API's present too, to support IP-telephony > aswell. > > --HPS Sorry, I didn't know your code existed, till I was told & searched, Great ! I'll build a new PC soonish to try with current (my gates are 6.2 & 6.4 now). isdn@freebsd.org : I just re-subscribed (used to be on long ago). Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 21:28:59 2010 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 E4C5110656A5 for ; Wed, 1 Sep 2010 21:28:59 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8F28FC0A for ; Wed, 1 Sep 2010 21:28:59 +0000 (UTC) Received: from bel.soho.vwsoft.com (p57A0D00F.dip.t-dialin.net [87.160.208.15]) by Mail.elbekies.net (Postfix) with ESMTPA id C6DDF2E037 for ; Wed, 1 Sep 2010 23:10:52 +0200 (CEST) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id BC2E833C86; Wed, 1 Sep 2010 23:08:58 +0200 (CEST) Message-ID: <4C7EC148.9040104@vwsoft.com> Date: Wed, 01 Sep 2010 23:10:32 +0200 From: volker@vwsoft.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.11) Gecko/20100811 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201009011609.o81G9XEQ011268@fire.js.berklix.net> In-Reply-To: <201009011609.o81G9XEQ011268@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: C6DDF2E037.AB733 X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com MailScanner-NULL-Check: 1283980257.93501@9zvOkR2fztu2CjvjNky2YA Cc: FreeBSD Stable , gljennjohn@googlemail.com Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon 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: Wed, 01 Sep 2010 21:29:00 -0000 [trimmed cc list] Julian, On 09/01/10 18:09, Julian H. Stacey wrote: >> On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their > > FreeBSD -7& -8 do not support ISDN I'm told. > So 6.4 is the last working FreeBSD ISDN. Somebody told you wrong. There's still i4b code in 7-STABLE. It's been axed out for 8-CURRENT short before 8.0-R. So you may want to run 7.x if you depend on ISDN (AFAIK it's still in a working condition for 7). Cheers, Volker From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 22:16:11 2010 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 A78F910656A9 for ; Wed, 1 Sep 2010 22:16:11 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 351AA8FC08 for ; Wed, 1 Sep 2010 22:16:11 +0000 (UTC) Received: from park.js.berklix.net (p549A4552.dip.t-dialin.net [84.154.69.82]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o81MG8SM034165; Wed, 1 Sep 2010 22:16:09 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o81MFwfw074576; Thu, 2 Sep 2010 00:15:58 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o81MFNZo040376; Thu, 2 Sep 2010 00:15:33 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201009012215.o81MFNZo040376@fire.js.berklix.net> To: volker@vwsoft.com From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 01 Sep 2010 23:10:32 +0200." <4C7EC148.9040104@vwsoft.com> Date: Thu, 02 Sep 2010 00:15:22 +0200 Sender: jhs@berklix.com Cc: FreeBSD Stable , gljennjohn@googlemail.com Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon 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: Wed, 01 Sep 2010 22:16:11 -0000 Hi, Reference: > From: volker@vwsoft.com > Date: Wed, 01 Sep 2010 23:10:32 +0200 > Message-id: <4C7EC148.9040104@vwsoft.com> volker@vwsoft.com wrote: > [trimmed cc list] > > Julian, > > On 09/01/10 18:09, Julian H. Stacey wrote: > >> On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their > > > > FreeBSD -7& -8 do not support ISDN I'm told. > > So 6.4 is the last working FreeBSD ISDN. > > Somebody told you wrong. Or I maybe misheard. > There's still i4b code in 7-STABLE. It's been axed out for 8-CURRENT > short before 8.0-R. So you may want to run 7.x if you depend on ISDN > (AFAIK it's still in a working condition for 7). Thanks Volker, I've started upgrading a box 7.2 to 7.3-rel then will insert card & try. Any tech issues thay may arise I'll raise on isdn@ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 22:32:51 2010 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 60F33106564A for ; Wed, 1 Sep 2010 22:32:51 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 35B108FC17 for ; Wed, 1 Sep 2010 22:32:51 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o81MJJFl027487; Wed, 1 Sep 2010 15:19:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Sep 2010 15:19:01 -0700 Message-ID: In-Reply-To: <201008312102.o7VL2MJr000894@lava.sentex.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: if_rtdel: error 47 Thread-Index: ActJT/fSqmKjYUW7S7Cf9CfKG3pSYwA0Olcw References: <201008312102.o7VL2MJr000894@lava.sentex.ca> From: "Li, Qing" To: "Mike Tancsa" , Cc: Subject: RE: if_rtdel: error 47 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: Wed, 01 Sep 2010 22:32:51 -0000 Hi, Without seeing your mpd link configuration, I am guessing the IP address of all of=20 the local end points of your ppp links is the same IP address. If that's the case,=20 the error message is harmless. The reason being, for ppp links and in pre 8.0 release, if you try pinging the local=20 end IP address, you will see packets are leaked out towards the default gateway. I fixed this issue by installing a loopback route for the local end. Since multiple ppp links all having the same local IP address, but only one such loopback route is installed, when links are torn down they would try deleting but=20 that entry would stay until the final link referring to that self-pointing route=20 is gone. --Qing > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Mike Tancsa > Sent: Tuesday, August 31, 2010 2:02 PM > To: freebsd-stable@freebsd.org > Subject: if_rtdel: error 47 >=20 > On a RELENG_8 box from aug 25th, I started seeing a constant spew of >=20 > Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47 > Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:29 gate8 last message repeated 2 times > Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:37 gate8 last message repeated 2 times > Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed > Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3 > Aug 31 00:18:38 gate8 last message repeated 2 times >=20 >=20 > What do they mean and how can I find the cause of it ? The box acts > as an LNS with about 700 ng interfaces with mpd5.5. ipv6 is enabled > on this server as well, so I am guessing it might be related to ipv6 > as I havent seen it on the other LNS boxes that have the same setup, > except no ipv6. It was happily running for a few days until this > error started showing up ? >=20 > The error seems to be in sys/if.c >=20 > if_rtdel(struct radix_node *rn, void *arg) > { > struct rtentry *rt =3D (struct rtentry *)rn; > struct ifnet *ifp =3D arg; > int err; >=20 > if (rt->rt_ifp =3D=3D ifp) { >=20 > /* > * Protect (sorta) against walktree recursion problems > * with cloned routes > */ > if ((rt->rt_flags & RTF_UP) =3D=3D 0) > return (0); >=20 > err =3D rtrequest_fib(RTM_DELETE, rt_key(rt), rt- > >rt_gateway, > rt_mask(rt), rt- > >rt_flags|RTF_RNH_LOCKED, > (struct rtentry **) NULL, rt- > >rt_fibnum); > if (err) { > log(LOG_WARNING, "if_rtdel: error %d\n", err); > } > } >=20 > return (0); > } >=20 >=20 >=20 > ---Mike >=20 >=20 > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike >=20 > _______________________________________________ > 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 Wed Sep 1 22:55:32 2010 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 2DE2710656AB for ; Wed, 1 Sep 2010 22:55:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id C474B8FC0C for ; Wed, 1 Sep 2010 22:55:31 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o81MtN1Z085023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Sep 2010 18:55:23 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o81MtMXn009701; Wed, 1 Sep 2010 18:55:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009012255.o81MtMXn009701@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Sep 2010 18:55:23 -0400 To: "Li, Qing" , From: Mike Tancsa In-Reply-To: References: <201008312102.o7VL2MJr000894@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: RE: if_rtdel: error 47 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: Wed, 01 Sep 2010 22:55:32 -0000 At 06:19 PM 9/1/2010, Li, Qing wrote: >Hi, > >Without seeing your mpd link configuration, I am guessing the IP address >of all of >the local end points of your ppp links is the same IP address. If that's >the case, >the error message is harmless. Hi, Thanks for looking! Yes, they are the same. However, I dont see this error on the other box which does not have ipv6 negotiation on the line (set bundle enable ipv6cp). Only since enabling ipv6 negotiation and oddly enough only after a few days did the error start happening. # Create clonable bundle template named B create bundle template B set iface idle 1800 set iface enable tcpmssfix set ipcp disable vjcomp set bundle enable ipv6cp set ipcp deny vjcomp set ipcp ranges xx.yy.zz.6/32 ippool pool1 #set ipcp nbns 127.0.0.1 # Set bundle template to use create link template L l2tp set l2tp disable dataseq set link action bundle B # Enable peer authentication set link disable eap set link enable pap set link disable acfcomp set link disable protocomp set link disable check-magic set link deny acfcomp set link keep-alive 10 60 set link deny protocomp load radius set link mtu 1492 set link mru 1492 set link enable incoming set link disable peer-as-calling I also noticed that the odd time I see as a result of ifconfig ifconfig: ioctl(SIOCGIFAFLAG_IN6): Device not configured ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured The other issue I noticed was that the link local ipv6 stopped working on a test machine. eg pinging the multicast address on the local link stopped working for some reason ie ping ff02::1%ng155 stopped working on a machine I was testing just the day before. Killing the l2tp session and having it reconnect fixed the issue. OK, another issue I am seeing. The routing table seems to have "junk" in it. eg fe80::21b:21ff:fe53:ca87%ng77 link#84 UHS 0 0 16384 lo0 fe80::%ng78/64 link#85 U 0 0 1448 (Hx~^F(l^N(<80>SL^GV (` (^A fe80::21b:21ff:fe53:ca87%ng78 link#85 UHS 0 0 16384 lo0 fe80::%ng79/64 I will send a you a full copy offlist ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 23:24:54 2010 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 1843A1065679 for ; Wed, 1 Sep 2010 23:24:54 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 002298FC12 for ; Wed, 1 Sep 2010 23:24:53 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o81NOrxa019509; Wed, 1 Sep 2010 16:24:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Sep 2010 16:24:35 -0700 Message-ID: In-Reply-To: <201009012255.o81MtMXn009701@lava.sentex.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: if_rtdel: error 47 Thread-Index: ActKKMkED6SGao3OSrWVm4yBwiSMZAAAtP5Q References: <201008312102.o7VL2MJr000894@lava.sentex.ca> <201009012255.o81MtMXn009701@lava.sentex.ca> From: "Li, Qing" To: "Mike Tancsa" , Cc: Subject: RE: if_rtdel: error 47 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: Wed, 01 Sep 2010 23:24:54 -0000 >=20 > Hi, > Thanks for looking! Yes, they are the same. However, I > dont see this error on the other box which does not have ipv6 > negotiation on the line (set bundle enable ipv6cp). Only since > enabling ipv6 negotiation and oddly enough only after a few days did > the error start happening. >=20 I went through the change history and noticed I made the following changelist for IPv4,=20 http://svn.freebsd.org/viewvc/base/head/sys/netinet/in.c?r1=3D201811&r2=3D= 20 3401 Maybe related and something similar needs to be done for IPv6 ... =20 >=20 > The other issue I noticed was that the link local ipv6 stopped > working on a test machine. > eg > pinging the multicast address on the local link stopped working for > some reason > ie ping ff02::1%ng155 > stopped working on a machine I was testing just the day > before. Killing the l2tp session and having it reconnect fixed the > issue. >=20 Nothing obvious comes to mind at the moment. > > OK, another issue I am seeing. The routing table seems to have "junk" > in it. eg >=20 That explains the errno =3D 47, EAFNOSUPPORT. I also noticed in your routing table output that all of entries that have junk are related to the ng interface. -- Qing From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 00:09:58 2010 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 DE21510656A3; Thu, 2 Sep 2010 00:09:58 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 66F688FC14; Thu, 2 Sep 2010 00:09:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o81Nx7oE069483; Thu, 2 Sep 2010 03:59:07 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 2 Sep 2010 03:59:07 +0400 (MSD) From: Dmitry Morozovsky To: stable@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (woozle.rinet.ru [0.0.0.0]); Thu, 02 Sep 2010 03:59:07 +0400 (MSD) Cc: mux@FreeBSD.org, lulf@FreeBSD.org Subject: csup in repomirror mode dumps core @ stable/8 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, 02 Sep 2010 00:09:58 -0000 Dear colleagues, some 2 days ago my repo mirror (stable/8@amd64) starts dumping core on copying repo: ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v Segmentation fault (core dumped) deleting files from sup/cvsroot-all/ did not help unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup does not work, and I did not dig into this deeply yet, so trace are without parameters: (gdb) bt #0 0x0000000000410676 in rcsdelta_addlog () #1 0x0000000000412b15 in rcsparse_run () #2 0x0000000000412453 in rcsfile_frompath () #3 0x0000000000417c45 in updater_rcsedit () #4 0x0000000000419a59 in updater_batch () #5 0x000000000041a1d1 in updater () #6 0x00000000004158c4 in thread_start () #7 0x0000000800a1c511 in pthread_getprio () from /lib/libthr.so.3 #8 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffff1fa000 Any hints? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 00:31:06 2010 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 8073D1065679 for ; Thu, 2 Sep 2010 00:31:06 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3944E8FC0A for ; Thu, 2 Sep 2010 00:31:06 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o820UwBP089246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Sep 2010 20:30:58 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o820UvOu010173; Wed, 1 Sep 2010 20:30:57 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009020030.o820UvOu010173@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Sep 2010 20:30:57 -0400 To: "Li, Qing" , From: Mike Tancsa In-Reply-To: References: <201008312102.o7VL2MJr000894@lava.sentex.ca> <201009012255.o81MtMXn009701@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: RE: if_rtdel: error 47 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, 02 Sep 2010 00:31:06 -0000 At 07:24 PM 9/1/2010, Li, Qing wrote: > That explains the errno = 47, EAFNOSUPPORT. > > I also noticed in your routing table output that all of entries > that have junk are related to the ng interface. Is it more to do with the interfaces coming and going or ipv6 ? The non ipv6 enabled mpd box doesnt show this behaviour however. ---Mike > -- Qing -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 05:56:34 2010 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 D24E710656B3; Thu, 2 Sep 2010 05:56:34 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id D97D78FC1D; Thu, 2 Sep 2010 05:56:33 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 1463F3985F; Thu, 2 Sep 2010 07:56:31 +0200 (SAST) Date: Thu, 2 Sep 2010 07:56:31 +0200 From: John Hay To: Dmitry Morozovsky Message-ID: <20100902055630.GA55668@zibbi.meraka.csir.co.za> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: mux@FreeBSD.org, stable@FreeBSD.org, lulf@FreeBSD.org Subject: Re: csup in repomirror mode dumps core @ stable/8 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, 02 Sep 2010 05:56:34 -0000 On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: > Dear colleagues, > > some 2 days ago my repo mirror (stable/8@amd64) starts dumping core on copying > repo: > > ... > SetAttrs CVSROOT-src/Emptydir > Edit CVSROOT-src/access,v > Segmentation fault (core dumped) > > deleting files from sup/cvsroot-all/ did not help > > unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup > does not work, and I did not dig into this deeply yet, so trace are without > parameters: > > (gdb) bt > #0 0x0000000000410676 in rcsdelta_addlog () > #1 0x0000000000412b15 in rcsparse_run () > #2 0x0000000000412453 in rcsfile_frompath () > #3 0x0000000000417c45 in updater_rcsedit () > #4 0x0000000000419a59 in updater_batch () > #5 0x000000000041a1d1 in updater () > #6 0x00000000004158c4 in thread_start () > #7 0x0000000800a1c511 in pthread_getprio () from /lib/libthr.so.3 > #8 0x0000000000000000 in ?? () > Cannot access memory at address 0x7fffff1fa000 > I see it here too on both a 7.2 and 8-stable machine. It looks like something in CVSROOT-src/access,v confuse it because moving that file away make the crash go away. I still have the old access,v if somebody is interested. A diff does not show anything wierd that I can see. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org --- /tmp/access,v-csup.crash 2010-07-31 16:57:51.000000000 +0200 +++ /home/freebsd-cvs/CVSROOT-src/access,v 2010-08-30 22:31:11.000000000 +0200 @@ -1,10 +1,15 @@ -head 1.941; +head 1.942; access; symbols; locks; strict; comment @# @; +1.942 +date 2010.08.30.20.30.48; author rpaulo; state Exp; +branches; +next 1.941; + 1.941 date 2010.07.31.14.57.38; author philip; state Exp; branches; @@ -4715,11 +4720,13 @@ @@ -1.941 +1.942 log -@SVN rev 210685 on 2010-07-31 14:57:38Z by philip +@SVN rev 212009 on 2010-08-30 20:30:48Z by rpaulo -Take cbzimmer's commit bit into safekeeping per his request. +Please welcome Dimitry Andric (dim@@) as a src committer. Dimitry will be +work on Clang for now. +ed@@ is a co-mentor. Approved by: core @ @@ -4789,6 +4796,7 @@ des dfr dg +dim dougb dumbbell dwhite @@ -4972,6 +4980,19 @@ @ +1.941 +log +@SVN rev 210685 on 2010-07-31 14:57:38Z by philip + +Take cbzimmer's commit bit into safekeeping per his request. + +Approved by: core +@ +text +@d66 1 +@ + + 1.940 log @SVN rev 210462 on 2010-07-25 10:06:56Z by philip From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 06:17:00 2010 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 A37BA1065701 for ; Thu, 2 Sep 2010 06:17:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 456988FC13 for ; Thu, 2 Sep 2010 06:16:59 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id 1iH01f0011YDfWL58iH0Yq; Thu, 02 Sep 2010 06:17:00 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta20.westchester.pa.mail.comcast.net with comcast id 1iGy1f0073LrwQ23giGzVM; Thu, 02 Sep 2010 06:17:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EA6EE9B425; Wed, 1 Sep 2010 23:16:56 -0700 (PDT) Date: Wed, 1 Sep 2010 23:16:56 -0700 From: Jeremy Chadwick To: John Hay Message-ID: <20100902061656.GA29424@icarus.home.lan> References: <20100902055630.GA55668@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100902055630.GA55668@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mux@FreeBSD.org, lulf@FreeBSD.org, stable@FreeBSD.org, Dmitry Morozovsky Subject: Re: csup in repomirror mode dumps core @ stable/8 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, 02 Sep 2010 06:17:00 -0000 On Thu, Sep 02, 2010 at 07:56:31AM +0200, John Hay wrote: > On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: > > Dear colleagues, > > > > some 2 days ago my repo mirror (stable/8@amd64) starts dumping core on copying > > repo: > > > > ... > > SetAttrs CVSROOT-src/Emptydir > > Edit CVSROOT-src/access,v > > Segmentation fault (core dumped) > > > > deleting files from sup/cvsroot-all/ did not help > > > > unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup > > does not work, and I did not dig into this deeply yet, so trace are without > > parameters: This won't work. You need to do: make DEBUG_FLAGS="-g3 -ggdb -O0" The important part is not using -D. make.conf variables aren't exported into the compiler environment (I'm not phrasing this eloquently because I don't know how to describe it). The rest of the gcc arguments I provided are highly recommended (especially -O0, otherwise you probably won't get access to any variable data). I can confirm this works, by the way. Look closely at the cc line (past the initial -O2 -pipe -march=nocona). cc -O2 -pipe -march=nocona -I. -I/usr/src/usr.bin/csup/../../contrib/csup -DHAVE_FFLAGS -DNDEBUG -ggdb -g3 -O0 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/src/usr.bin/csup/../../contrib/csup/updater.c -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 08:16:23 2010 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 9214A10656CB for ; Thu, 2 Sep 2010 08:16:23 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 48EEF8FC0A for ; Thu, 2 Sep 2010 08:16:22 +0000 (UTC) Received: by qwg5 with SMTP id 5so222710qwg.13 for ; Thu, 02 Sep 2010 01:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=i2EC/jLpwGjFqDpMFvouJZfTGiyOdGNZ/aLujkYDhQs=; b=tf0rGNcsAj0ZlOJHlhBivIkKZ6a8fXPCiJ34vKSPiv1M3R9KeNx0gzxhpJZBsWhFtW jNJ58Fs1olPZjb3/spuH4Km7abh++btvO9mJI5XFehMuYhVfgQl0DqVN/vWn94KrqU2d qgKgDJafI32wtqPjJoVupR5CU9NLaNEIe1Yzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u03IdiyvXQmMkKzaWSWNtJtdQTQsxJ+dS0sbP5YPtFNMcroTp0jFhZ0I1PKXcV7fPb S5RSAGaC/SBQfEhplJTUM6O75mlZMpbcj7WSzju7J82vTkdijsXktPwRnDhIL3RM27gk aJKh2SKGozKQAaPqYb/NA0Y0ZLc8F7tSttNFQ= MIME-Version: 1.0 Received: by 10.224.73.131 with SMTP id q3mr6281047qaj.171.1283413697075; Thu, 02 Sep 2010 00:48:17 -0700 (PDT) Received: by 10.229.17.18 with HTTP; Thu, 2 Sep 2010 00:48:17 -0700 (PDT) Date: Thu, 2 Sep 2010 09:48:17 +0200 Message-ID: From: Christer Solskogen To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 Subject: NFS and mount_nullfs, kernel panic? 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, 02 Sep 2010 08:16:23 -0000 I have a machine which works as a prison for a couple of jails. That particular machine has its /usr/ports, /usr/ports/distfiles, and /usr/ports/packages mounted via NFS from another FreeBSD machine. The machine that crases also nullmounts those filesystems into each jail. I'm not completly sure that this is the reason the machine crashes, but i suspect that is the reason. What can I do to figure it how? What kind of debugging knobs do I need to apply to learn more about the problem? -- chs, From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 08:25:56 2010 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 D0CB11065731; Thu, 2 Sep 2010 08:25:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B398F8FC20; Thu, 2 Sep 2010 08:25:55 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA18794; Thu, 02 Sep 2010 11:25:53 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Or57J-0003CW-2R; Thu, 02 Sep 2010 11:25:53 +0300 Message-ID: <4C7F5F90.3030407@icyb.net.ua> Date: Thu, 02 Sep 2010 11:25:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C77F6D6.9020402@icyb.net.ua> <201008271536.08773.jkim@FreeBSD.org> <201009011426.26111.jkim@FreeBSD.org> In-Reply-To: <201009011426.26111.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jeff@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly 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, 02 Sep 2010 08:25:56 -0000 on 01/09/2010 21:26 Jung-uk Kim said the following: > On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote: >> [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and >> my patch won't work on them. If anyone has a Bulldozer sample, >> please look into it. > > I checked AMD website today and found out a new CPUID Spec. Rev. 2.34 > was just released: > > http://support.amd.com/us/Embedded_TechDocs/25481.pdf > > They have added CPUID 0x8000001d and 0x8000001e to detect topology, it > seems. Also, CPUID 0x80000001 %ecx bit 22 (TopologyExtensions) tells > you whether the above CPUID functions are supported. > > Interesting... Yeah, I've heard that they are adding SMT capabilities in "Bulldozer" processors, so I guess they have to change CPU topology detection indicators. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 08:51:38 2010 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 7A76610656A8; Thu, 2 Sep 2010 08:51:38 +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 E3A7B8FC0C; Thu, 2 Sep 2010 08:51:37 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o828DrYH004632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Sep 2010 11:13:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o828Dr8A056107; Thu, 2 Sep 2010 11:13:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o828Drh3056106; Thu, 2 Sep 2010 11:13:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Sep 2010 11:13:53 +0300 From: Kostik Belousov To: Dmitry Morozovsky Message-ID: <20100902081353.GH2396@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YgjvKiquOwI93ip4" Content-Disposition: inline In-Reply-To: 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.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: mux@freebsd.org, stable@freebsd.org, lulf@freebsd.org Subject: Re: csup in repomirror mode dumps core @ stable/8 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, 02 Sep 2010 08:51:38 -0000 --YgjvKiquOwI93ip4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: > Dear colleagues, >=20 > some 2 days ago my repo mirror (stable/8@amd64) starts dumping core on co= pying=20 > repo: >=20 > ... > SetAttrs CVSROOT-src/Emptydir > Edit CVSROOT-src/access,v > Segmentation fault (core dumped) >=20 > deleting files from sup/cvsroot-all/ did not help >=20 > unfortunately, quick usual `make -DDEBUG_FLAGS=3D-g' in /usr/src/usr.bin/= csup=20 > does not work, and I did not dig into this deeply yet, so trace are witho= ut=20 > parameters: I think it should be DEBUG_FLAGS=3D-g and not -D"...". --YgjvKiquOwI93ip4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx/XMEACgkQC3+MBN1Mb4juggCdH65jPqXf6E8+UKhWNSDXvmPA o6kAn0Y7jDlox/VN9QTuGbxn++QWTHAb =KoDw -----END PGP SIGNATURE----- --YgjvKiquOwI93ip4-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 09:06:39 2010 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 D740710656AE for ; Thu, 2 Sep 2010 09:06:39 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 5630C8FC13 for ; Thu, 2 Sep 2010 09:06:39 +0000 (UTC) Received: from [131.234.21.116] (baloo.cs.uni-paderborn.de [131.234.21.116]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id o828XiVK029931 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 2 Sep 2010 10:33:45 +0200 (CEST) Message-ID: <4C7F6167.6070609@FreeBSD.org> Date: Thu, 02 Sep 2010 10:33:43 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <4C7E803F.1090606@janh.de> In-Reply-To: <4C7E803F.1090606@janh.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: GSSAPI (for OpenLDAP) on FreeBSD 8? 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, 02 Sep 2010 09:06:39 -0000 Am 01.09.2010 18:33, schrieb Jan Henrik Sylvester: > I have got problems with GSSAPI authentication to OpenLDAP: > ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) > error (80) > additional info: SASL(-1): generic failure: GSSAPI Error: No > credentials were supplied, or the credentials were unavailable or > inaccessible. (unknown mech-code 0 for mech unknown) Did you run kinit to obtain tickets? You didn't mention that. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 09:08:34 2010 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 28E2510656A3 for ; Thu, 2 Sep 2010 09:08:34 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id DCA888FC1E for ; Thu, 2 Sep 2010 09:08:33 +0000 (UTC) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Or5mW-0000ol-NI; Thu, 02 Sep 2010 10:08:33 +0100 Received: from cse-jg.cse.bris.ac.uk ([137.222.12.37]:22572) by mail.ilrt.bris.ac.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Or5mP-000433-Rl; Thu, 02 Sep 2010 10:08:21 +0100 Date: Thu, 2 Sep 2010 10:08:21 +0100 (BST) From: jan.grant@bristol.ac.uk X-X-Sender: cmjg@tribble.ilrt.bris.ac.uk To: Ivan Voras In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ILRT-MailScanner: Found to be clean X-ILRT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.41, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.99, BAYES_00 -2.60) X-ILRT-MailScanner-From: jan.grant@bristol.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 X-Spam-Level: -- Cc: freebsd-stable@freebsd.org Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 02 Sep 2010 09:08:34 -0000 On Wed, 1 Sep 2010, Ivan Voras wrote: > On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: > > I'm running -STABLE with a kde-derived desktop. This setup (which is > > pretty standard) is providing abysmal interactive performance on an > > eight-core machine whenever I try to do anything CPU-intensive (such as > > building a port). > > > > Basically, trying to build anything from ports rapidly renders everything > > else so "non-interactive" in the eyes of the scheduler that, for instance, > > switching between virtual desktops (I have six of them in reasonably > > frequent use) takes about a minute of painful waiting on redraws to > > complete. > > Are you sure this is about the scheduler or maybe bad X11 drivers? Not 100%, but mostly convinced; I've just started looking at this. It's my first stab at what might be going on. X11 performance is usually pretty snappy. There's no paging pressure at all. > > Once I pay attention to any particular window, the scheduler rapidly > > (like, in 15 agonising seconds or so) decides that the processes > > associated with that particular window are "interactive" and performance > > there picks up again. But it only takes 10 seconds (not timed; ballpark > > figures) or so of inattention for a window's processes to lapse back into > > a low-priority state, with the attendant performance problems. > > "windows" in X11 have nothing to do with the scheduler (contrary to MS Windows > where the OS actually "re-nices" processes whose windows have focus) - here > you are just interacting with a process. Yup, and it does seem that by interacting with the process, things'll start to pick up again - for the processes associated with that window. > On the other hand, I have noticed that a 2xQuad-core machine I have access too > has more X11 interactivity problems than this single quad-core machine, though > again not as serious as yours. I don't know why this is. From the hardware > side it might be the shared FSB or from the software side it might be the > scheduler. If you want to try something I think it's easier for you to disable > one CPU in BIOS or pin X.org and its descendant processes to CPUs of a single > socket than to diagnose scheduler problems. > > > but compared to the performance under sched_4bsd, what I'm seeing is an > > atrocious user experience. > > It would be best if you could quantify this in some way. I have no idea how. Yeah, I realised that my report was "this doesn't work [very well]!" which is fairly terrible when it comes to tracking things down; mostly, I was hoping to prompt none, some or lots of "same here"s to see if the problem was commonly seen. Also (as you're aware) a desktop environment is a complex beast, and putting numbers against "look and feel" is tricky - however in this situation, I can get numbers from a wall-clock, the behaviour is that pronounced. I'll certainly try getting the whole X tree onto a single socket, to see if that makes any difference. I'll certainly have a stab with your suggestion - thanks Ivan. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 09:40:58 2010 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 DDA4B10656C2 for ; Thu, 2 Sep 2010 09:40:58 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 77E568FC0C for ; Thu, 2 Sep 2010 09:40:58 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id o829f69a042585; Thu, 2 Sep 2010 11:41:06 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id o829f6Eq042584; Thu, 2 Sep 2010 11:41:06 +0200 (CEST) (envelope-from byshenknet) Date: Thu, 2 Sep 2010 11:41:06 +0200 From: Greg Byshenk To: Jeremy Chadwick Message-ID: <20100902094106.GI12467@core.byshenk.net> References: <20100830094631.GD12467@core.byshenk.net> <20100830110845.GA31629@icarus.home.lan> <20100830122247.GA33429@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100830122247.GA33429@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: igb related(?) panics on 7.3-STABLE 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, 02 Sep 2010 09:40:58 -0000 On Mon, Aug 30, 2010 at 05:22:47AM -0700, Jeremy Chadwick wrote: > On Mon, Aug 30, 2010 at 04:08:45AM -0700, Jeremy Chadwick wrote: > > Bcc: > > Subject: Re: igb related(?) panics on 7.3-STABLE > > Reply-To: > > In-Reply-To: <20100830094631.GD12467@core.byshenk.net> > > {snip} > My apologies -- somehow my mail client completely broke the Subject line > and pulled it from another thread. I'm not quite sure how mutt managed > to do that, but probably an extraneous newline when editing mail > headers, e.g. PEBKAC. As an informational followup on this issue, I've updated the problem machine to 8-STABLE (FreeBSD 8.1-STABLE #7: Mon Aug 23 13:01:15 CEST 2010) and the problem seems to have gone away. I had a journal overflow this morning, but that is a different problem, and I think that it should be fixable via tuning a bit. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 09:59:22 2010 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 05E0D1065713; Thu, 2 Sep 2010 09:59:22 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 848058FC1D; Thu, 2 Sep 2010 09:59:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o829x8nc015028; Thu, 2 Sep 2010 13:59:08 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 2 Sep 2010 13:59:08 +0400 (MSD) From: Dmitry Morozovsky To: Kostik Belousov In-Reply-To: <20100902081353.GH2396@deviant.kiev.zoral.com.ua> Message-ID: References: <20100902081353.GH2396@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (woozle.rinet.ru [0.0.0.0]); Thu, 02 Sep 2010 13:59:08 +0400 (MSD) Cc: mux@freebsd.org, stable@freebsd.org, lulf@freebsd.org Subject: Re: csup in repomirror mode dumps core @ stable/8 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, 02 Sep 2010 09:59:22 -0000 On Thu, 2 Sep 2010, Kostik Belousov wrote: KB> On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: KB> > Dear colleagues, KB> > KB> > some 2 days ago my repo mirror (stable/8@amd64) starts dumping core on copying KB> > repo: KB> > KB> > ... KB> > SetAttrs CVSROOT-src/Emptydir KB> > Edit CVSROOT-src/access,v KB> > Segmentation fault (core dumped) KB> > KB> > deleting files from sup/cvsroot-all/ did not help KB> > KB> > unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup KB> > does not work, and I did not dig into this deeply yet, so trace are without KB> > parameters: KB> I think it should be DEBUG_FLAGS=-g and not -D"...". Yes, surely you're right. BTW, I can confirm moving away access,v file helps avoiding core. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 10:28:12 2010 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 1AF841065743 for ; Thu, 2 Sep 2010 10:28:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 24C018FC17 for ; Thu, 2 Sep 2010 10:28:10 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA21308; Thu, 02 Sep 2010 13:27:28 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Or70x-0003Nx-Tm; Thu, 02 Sep 2010 13:27:27 +0300 Message-ID: <4C7F7C0F.8080004@icyb.net.ua> Date: Thu, 02 Sep 2010 13:27:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: jan.grant@bristol.ac.uk References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 02 Sep 2010 10:28:12 -0000 on 02/09/2010 12:08 jan.grant@bristol.ac.uk said the following: > On Wed, 1 Sep 2010, Ivan Voras wrote: > >> On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: >>> I'm running -STABLE with a kde-derived desktop. This setup (which is >>> pretty standard) is providing abysmal interactive performance on an >>> eight-core machine whenever I try to do anything CPU-intensive (such as >>> building a port). >>> >>> Basically, trying to build anything from ports rapidly renders everything >>> else so "non-interactive" in the eyes of the scheduler that, for instance, >>> switching between virtual desktops (I have six of them in reasonably >>> frequent use) takes about a minute of painful waiting on redraws to >>> complete. >> >> Are you sure this is about the scheduler or maybe bad X11 drivers? > > Not 100%, but mostly convinced; I've just started looking at this. It's my > first stab at what might be going on. X11 performance is usually pretty > snappy. There's no paging pressure at all. >From my experience: 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - enabling OpenGL desktop effects in KDE4 leads to the consequences like what you describe. With all GUI bells and whistles disabled the system behaves quite like the AMD system. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 10:46:17 2010 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 A15CA10656CB; Thu, 2 Sep 2010 10:46:17 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB3B8FC16; Thu, 2 Sep 2010 10:46:17 +0000 (UTC) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Or7J7-0003Cw-Am; Thu, 02 Sep 2010 11:46:16 +0100 Received: from cse-jg.cse.bris.ac.uk ([137.222.12.37]:61066) by mail.ilrt.bris.ac.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Or7Iy-0006RD-DF; Thu, 02 Sep 2010 11:46:04 +0100 Date: Thu, 2 Sep 2010 11:46:04 +0100 (BST) From: jan.grant@bristol.ac.uk X-X-Sender: cmjg@tribble.ilrt.bris.ac.uk To: Andriy Gapon In-Reply-To: <4C7F7C0F.8080004@icyb.net.ua> Message-ID: References: <4C7F7C0F.8080004@icyb.net.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ILRT-MailScanner: Found to be clean X-ILRT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.411, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.99, BAYES_00 -2.60) X-ILRT-MailScanner-From: jan.grant@bristol.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 X-Spam-Level: -- Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 02 Sep 2010 10:46:17 -0000 On Thu, 2 Sep 2010, Andriy Gapon wrote: > on 02/09/2010 12:08 jan.grant@bristol.ac.uk said the following: > > On Wed, 1 Sep 2010, Ivan Voras wrote: > > > >> On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: > >>> I'm running -STABLE with a kde-derived desktop. This setup (which is > >>> pretty standard) is providing abysmal interactive performance on an > >>> eight-core machine whenever I try to do anything CPU-intensive (such as > >>> building a port). > >>> > >>> Basically, trying to build anything from ports rapidly renders everything > >>> else so "non-interactive" in the eyes of the scheduler that, for instance, > >>> switching between virtual desktops (I have six of them in reasonably > >>> frequent use) takes about a minute of painful waiting on redraws to > >>> complete. > >> > >> Are you sure this is about the scheduler or maybe bad X11 drivers? > > > > Not 100%, but mostly convinced; I've just started looking at this. It's my > > first stab at what might be going on. X11 performance is usually pretty > > snappy. There's no paging pressure at all. > > From my experience: > 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with > interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). > 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - > enabling OpenGL desktop effects in KDE4 leads to the consequences like what you > describe. With all GUI bells and whistles disabled the system behaves quite > like the AMD system. All desktop effects are disabled. The graphics are from an nVidia GeForce 8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour that's affected, though: the box runs a number of small headless [interactive] server processes which also appear to get rapidly starved of CPU time.) The behaviour isn't visible with the 4bsd scheduler; "stuff" generally remains snappy and responsive. I'll keep poking around and see if I can get to the bottom of it. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Rereleasing dolphins into the wild since 1998. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 11:14:07 2010 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 3D70C10656B7 for ; Thu, 2 Sep 2010 11:14:07 +0000 (UTC) (envelope-from me@janh.de) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id EC6D98FC12 for ; Thu, 2 Sep 2010 11:14:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id 0AA969035E; Thu, 2 Sep 2010 13:14:06 +0200 (CEST) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id USHizHcPAyP6; Thu, 2 Sep 2010 13:14:05 +0200 (CEST) Received: from nb895.math (g224012120.adsl.alicedsl.de [92.224.12.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id C6A459006F; Thu, 2 Sep 2010 13:14:05 +0200 (CEST) Message-ID: <4C7F86F4.6020505@janh.de> Date: Thu, 02 Sep 2010 13:13:56 +0200 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100821 Thunderbird/3.0.6 MIME-Version: 1.0 To: stable-list freebsd References: <4C7E803F.1090606@janh.de> <4C7F6167.6070609@FreeBSD.org> In-Reply-To: <4C7F6167.6070609@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: GSSAPI (for OpenLDAP) on FreeBSD 8? 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, 02 Sep 2010 11:14:07 -0000 On 01/-10/-28163 20:59, Matthias Andree wrote: > Am 01.09.2010 18:33, schrieb Jan Henrik Sylvester: >> I have got problems with GSSAPI authentication to OpenLDAP: >> ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) >> error (80) >> additional info: SASL(-1): generic failure: GSSAPI Error: No >> credentials were supplied, or the credentials were unavailable or >> inaccessible. (unknown mech-code 0 for mech unknown) > > Did you run kinit to obtain tickets? You didn't mention that. Yes, I did, and klist shows the tgt and the ldap ticket -- the latter only after the call. You do get a "Local error" and not "Other" if you have no ticket. (And the ldap ticket is in /etc/krb5.keytab on the ldap server and owner by ldap.) Thanks, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 11:50:50 2010 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 35C2A10657D3 for ; Thu, 2 Sep 2010 11:50:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 1C53E8FC0C for ; Thu, 2 Sep 2010 11:50:48 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 1ni51f00516AWCUA5nqo86; Thu, 02 Sep 2010 11:50:48 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta06.emeryville.ca.mail.comcast.net with comcast id 1nqn1f0093LrwQ28Snqn7i; Thu, 02 Sep 2010 11:50:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 83B0D9B425; Thu, 2 Sep 2010 04:50:47 -0700 (PDT) Date: Thu, 2 Sep 2010 04:50:47 -0700 From: Jeremy Chadwick To: Jan Henrik Sylvester Message-ID: <20100902115047.GA37856@icarus.home.lan> References: <4C7E803F.1090606@janh.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7E803F.1090606@janh.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable-list freebsd Subject: Re: GSSAPI (for OpenLDAP) on FreeBSD 8? 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, 02 Sep 2010 11:50:50 -0000 On Wed, Sep 01, 2010 at 06:33:03PM +0200, Jan Henrik Sylvester wrote: > I have got problems with GSSAPI authentication to OpenLDAP: > ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) > error (80) > additional info: SASL(-1): generic failure: GSSAPI Error: > No credentials were supplied, or the credentials were unavailable or > inaccessible. (unknown mech-code 0 for mech unknown) > > There were at least two discussions, multiple bug reports, and > patches about broken GSSAPI on FreeBSD 8, the longest (I found) > starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html > > After reading through these discussions, I do not know what the > proper fix is -- I would like to change as little as possible > introducing SASL authentication to a (production) OpenLDAP server. > > I have got: An i386 kerberos server, a ldap server in a jail on > i386, some amd64 clients -- all running 8.1-RELEASE. Eventually > there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. > > What do I need to "fix"? Just the ldap server? Is it enough to > change the jail or does the host needs to be patches, too? Or do I > need to fix the client, too? The kerberos server? > > From the discussion, multiple fixes were possible. Patching > libgssapi and reinstalling everything depending on it (what?), > installing the heimdal-1.0 port (while FreeBSD 8 comes with > heimdal-1.1), installing an unofficial heimdal-1.2 port, ... > > Is that correct? Anything new after the discussion in July? > > From the discussion, some patches should already be in 8-STABLE, but > I could not find the revision (after 8.1-RELEASE). > > If I upgraded the ldap jail to 8-STABLE, I guess the host needs to > be updated, too. Hence I would prefer to just change ports or update > single libraries. > > Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the > libgssapi patch? With the heimdal-1.2 port? Can you please try the patch I proposed and see if it improves your situation? Thanks. http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057830.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 12:55:41 2010 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 76B5B10657F4 for ; Thu, 2 Sep 2010 12:55:41 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [62.220.235.15]) by mx1.freebsd.org (Postfix) with ESMTP id D18358FC1C for ; Thu, 2 Sep 2010 12:55:40 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id EA7421CC5D; Thu, 2 Sep 2010 15:30:25 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net EA7421CC5D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1283430626; bh=JlvrVeHh5fyIqSztsNCxJCCfz7oDzo7/EZ8IG3A94ak=; h=Message-ID:From:To:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xp9doD6Pq4hmqcLOS1OYmew7hr+D29o0pPhb8GfRXczt3aNRBvyF9PDqeXDFMZYWC A2gIzWc++Btf/AO65Xfts/zxwCAFs/FrDkiYMZgfmxYHMIHNZdZc6ppGmWzLj84cB6 JGgBlOZHWHtwe2xOR1fMAQ3BtXyn21fhr03hrMeg= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gxhLOOW+LQeN; Thu, 2 Sep 2010 15:30:21 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 4926F1CC5B; Thu, 2 Sep 2010 15:30:19 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 4926F1CC5B Message-ID: <99188991995E491B8101975CE4485ECC@rivendell> From: "Reko Turja" To: "Jan Henrik Sylvester" , "stable-list freebsd" References: <4C7E803F.1090606@janh.de> In-Reply-To: <4C7E803F.1090606@janh.de> Date: Thu, 2 Sep 2010 15:30:31 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: Subject: Re: GSSAPI (for OpenLDAP) on FreeBSD 8? 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, 02 Sep 2010 12:55:41 -0000 -------------------------------------------------- From: "Jan Henrik Sylvester" Sent: Wednesday, September 01, 2010 7:33 PM To: "stable-list freebsd" Subject: GSSAPI (for OpenLDAP) on FreeBSD 8? > Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the=20 > libgssapi patch? With the heimdal-1.2 port? I got running and fully functional Heimdal/GSSAPI setup with Benjamins=20 patch from = http://www.freebsd.org/cgi/query-pr.cgi?pr=3D147454&cat=3Dkern,=20 although I didn't test it with LDAP. Jeremys patch as far as I know removes the symptom, but it doesn't fix=20 the cause, which is completely missing heimdal code in the base system=20 preventing the functional operation of heimdal. -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 13:07:21 2010 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 758DB1065802 for ; Thu, 2 Sep 2010 13:07:21 +0000 (UTC) (envelope-from l.pizzamiglio@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id 00A3A8FC21 for ; Thu, 2 Sep 2010 13:07:20 +0000 (UTC) Received: from bwex.bally-wulff.de (unknown [192.168.204.106]) by mail2.bally-wulff-berlin.de (Postfix) with ESMTP id C3CB79906E; Thu, 2 Sep 2010 14:39:02 +0200 (CEST) Received: from [192.9.205.177] ([192.9.205.177]) by bwex.bally-wulff.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Sep 2010 14:39:03 +0200 Message-ID: <4C7F9ACE.80705@bally-wulff.de> Date: Thu, 02 Sep 2010 14:38:38 +0200 From: Luca Pizzamiglio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 MIME-Version: 1.0 To: jan.grant@bristol.ac.uk References: <4C7F7C0F.8080004@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Sep 2010 12:39:03.0793 (UTC) FILETIME=[D3704E10:01CB4A9B] Cc: freebsd-stable@freebsd.org Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 02 Sep 2010 13:07:21 -0000 Hello, My machine has a similar behavior. For instance, during intensive workload (portupgrade), everything is quite not-responsive. I made an alias of portupgrade, nice -n 5 portupgrade, that solves the problem just in that particular case. My system is AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class CPU) with openGL effects disabled, KDE as desktop environment. There is an interesting mib kern.sched.interact. But I don't know the meaning of it (my value is 30). Cheers, Luca On 09/02/2010 12:46, jan.grant@bristol.ac.uk wrote: > On Thu, 2 Sep 2010, Andriy Gapon wrote: > >> on 02/09/2010 12:08 jan.grant@bristol.ac.uk said the following: >>> On Wed, 1 Sep 2010, Ivan Voras wrote: >>> >>>> On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: >>>>> I'm running -STABLE with a kde-derived desktop. This setup (which is >>>>> pretty standard) is providing abysmal interactive performance on an >>>>> eight-core machine whenever I try to do anything CPU-intensive (such as >>>>> building a port). >>>>> >>>>> Basically, trying to build anything from ports rapidly renders everything >>>>> else so "non-interactive" in the eyes of the scheduler that, for instance, >>>>> switching between virtual desktops (I have six of them in reasonably >>>>> frequent use) takes about a minute of painful waiting on redraws to >>>>> complete. >>>> >>>> Are you sure this is about the scheduler or maybe bad X11 drivers? >>> >>> Not 100%, but mostly convinced; I've just started looking at this. It's my >>> first stab at what might be going on. X11 performance is usually pretty >>> snappy. There's no paging pressure at all. >> >> From my experience: >> 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with >> interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). >> 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - >> enabling OpenGL desktop effects in KDE4 leads to the consequences like what you >> describe. With all GUI bells and whistles disabled the system behaves quite >> like the AMD system. > > All desktop effects are disabled. The graphics are from an nVidia GeForce > 8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour > that's affected, though: the box runs a number of small headless > [interactive] server processes which also appear to get rapidly starved of > CPU time.) > > The behaviour isn't visible with the 4bsd scheduler; "stuff" generally > remains snappy and responsive. > > I'll keep poking around and see if I can get to the bottom of it. > > > -- Mit herzlichen Grüßen, Luca Pizzamiglio Systementwicklung BALLY WULFF Entertainment GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 149 From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 13:16:52 2010 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 49E361065733 for ; Thu, 2 Sep 2010 13:16:52 +0000 (UTC) (envelope-from rbyrnes@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 D692D8FC17 for ; Thu, 2 Sep 2010 13:16:51 +0000 (UTC) Received: by fxm4 with SMTP id 4so201851fxm.13 for ; Thu, 02 Sep 2010 06:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=/Jn5Piql4q6m4CIhUOCWhDQUvNXgvkxQcmNFo0pazf0=; b=gnzl+x2bcYHEBNGy4XIIxAYZdLVzA4Z5WgOhR+JNBSJWFDYDiaEbGGkXk2dRqvz/K1 GQx/ePzQqvaBp/3d3tX9fGUaxPQhUs4ENjOX5SkOp3LYFaFmpPGNmaF+sZyrX+Ol6TR8 sisfMIUWYnjtpV74dTW8r+73njHaW2TN7VSJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=N1tkoTFpp3t8z9TZuqsaoACnROofkvLKsP6/FK98vJxcVRjEavHBN8L1xWhFrFMMvl i0pXhNKAy3MHIsWGORNIWU2+jpse+vtLobnWxJvqYT3a3BO2Q/38RGy34vGQB8+fqnlk teMyiY51UNfVqH5Od2pMcMfnv3tfCItiAQHgc= Received: by 10.239.132.71 with SMTP id 7mr485571hbq.182.1283431843182; Thu, 02 Sep 2010 05:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.181.68 with HTTP; Thu, 2 Sep 2010 05:50:23 -0700 (PDT) From: Rob Byrnes Date: Thu, 2 Sep 2010 22:50:23 +1000 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: AMD64 Buildworld error in i386-elf 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, 02 Sep 2010 13:16:52 -0000 Source is current as at 0030 on 2nd Sept. and I'm seeing this buildworld error: ===> gnu/lib/csu (obj,depend,all,install) sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o /usr/obj/usr/src/lib32/usr/lib32/crtend.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.So /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.So /usr/obj/usr/src/lib32/usr/lib32/crtendS.o ===> lib/csu/i386-elf (obj,depend,all,install) ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 -o gcrt1.o -r crt1_s.o gcrt1_c.o ld: Relocatable linking with relocations from format elf64-x86-64 (gcrt1_c.o) to format elf32-i386-freebsd (gcrt1.o) is not supported *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 /usr/src % uname -a FreeBSD aylee.number6 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Jul 27 08:48:05 EST 2010 root@aylee.number6:/usr/obj/usr/src/sys/AYLEE amd64 thanks in advance rob From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 13:38:08 2010 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 88EA51065814 for ; Thu, 2 Sep 2010 13:38:08 +0000 (UTC) (envelope-from michal@sharescope.co.uk) Received: from mail1.sharescope.co.uk (mail1.ionic.co.uk [85.159.80.19]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7BD8FC08 for ; Thu, 2 Sep 2010 13:38:08 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail1.sharescope.co.uk (Postfix) with ESMTP id E0A07FC0C5 for ; Thu, 2 Sep 2010 13:20:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at sharescope.co.uk Received: from mail1.sharescope.co.uk ([127.0.0.1]) by localhost (mail1.sharescope.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2BLMVh20Pdu for ; Thu, 2 Sep 2010 14:20:10 +0100 (BST) Received: from [192.168.2.50] (unknown [85.159.85.2]) (Authenticated sender: chris@sharescope.co.uk) by mail1.sharescope.co.uk (Postfix) with ESMTPSA id 5D481FC0AB for ; Thu, 2 Sep 2010 14:20:10 +0100 (BST) Message-ID: <4C7FA50D.4000409@sharescope.co.uk> Date: Thu, 02 Sep 2010 14:22:21 +0100 From: Michal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Extending your zfs pool with multiple devices 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, 02 Sep 2010 13:38:08 -0000 I have a small problem that I am trying to work out a solution for. Imagine you create a NAS box. Fill a small server with 5 hard drives, zfs them with raidz or whatever, create your pools and then shear this to the network using samba. Simple NAS box for your network to put their files and they just connenct to \\nas1 This box is now full, my problem is that I could create a 2nd NAS box and people use \\nas1 and \\nas2 but it's not very use friendly. Can I somehow build a 2nd box which is identicle, but extend my pools into nas2. I was thinking something like exporting the nas2 drives via iscsi and then nas1 add's the drives to the pool...or something similar. I find that with any NAS whether its home build or shop bought you will eventually run out of space, and sure you can replace the HDD's with bigger ones but you will see run out of space, and having multiple locations, in my mind, is not very elegant. I cannot simply add more HDD's to the box as well as it's at full capacity Thanks From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 13:52:19 2010 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 B17EF10656F8 for ; Thu, 2 Sep 2010 13:52:19 +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 67FDC8FC1A for ; Thu, 2 Sep 2010 13:52:19 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OrADC-0006d5-HX for freebsd-stable@freebsd.org; Thu, 02 Sep 2010 15:52:18 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Sep 2010 15:52:18 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Sep 2010 15:52:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 02 Sep 2010 15:52:11 +0200 Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Cc: freebsd-net@freebsd.org Subject: Re: 8-stable crashes in vmware (possible em driver 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: Thu, 02 Sep 2010 13:52:19 -0000 On 02/25/10 01:23, Ivan Voras wrote: > Ivan Voras wrote: >> I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 >> (amd64 guest), which apparently crashes every few days from the same >> causes: >> >> em0: discard frame w/o packet header >> em0: discard frame w/o packet header >> em0: discard frame w/o packet header >> Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf >> 0xffffff00490a6400 clashing > > In case someone is interested or has an idea - on this machine I have > multiple crashed cores with similarily strange problems all connected > with networking and/or the em driver: ... It looks like the most probable culprit are stf (6to4) support and/or something dealing with stf routing (the machine was a stf gateway for a small subnet). When disabled, the crashes stop. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 13:52:29 2010 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 6B64E10656EC for ; Thu, 2 Sep 2010 13:52:29 +0000 (UTC) (envelope-from me@janh.de) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id ED6E68FC1C for ; Thu, 2 Sep 2010 13:52:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id E343A90143; Thu, 2 Sep 2010 15:52:27 +0200 (CEST) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u7h40xXSWjkG; Thu, 2 Sep 2010 15:52:27 +0200 (CEST) Received: from nb895.math (g224012120.adsl.alicedsl.de [92.224.12.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 829C890016; Thu, 2 Sep 2010 15:52:27 +0200 (CEST) Message-ID: <4C7FAC14.3040507@janh.de> Date: Thu, 02 Sep 2010 15:52:20 +0200 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100821 Thunderbird/3.0.6 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C7E803F.1090606@janh.de> <20100902115047.GA37856@icarus.home.lan> In-Reply-To: <20100902115047.GA37856@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable-list freebsd Subject: Re: GSSAPI (for OpenLDAP) on FreeBSD 8? 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, 02 Sep 2010 13:52:29 -0000 On 09/02/2010 13:50, Jeremy Chadwick wrote: > On Wed, Sep 01, 2010 at 06:33:03PM +0200, Jan Henrik Sylvester wrote: >> I have got problems with GSSAPI authentication to OpenLDAP: >> ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) >> error (80) >> additional info: SASL(-1): generic failure: GSSAPI Error: >> No credentials were supplied, or the credentials were unavailable or >> inaccessible. (unknown mech-code 0 for mech unknown) >> >> There were at least two discussions, multiple bug reports, and >> patches about broken GSSAPI on FreeBSD 8, the longest (I found) >> starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html >> >> After reading through these discussions, I do not know what the >> proper fix is -- I would like to change as little as possible >> introducing SASL authentication to a (production) OpenLDAP server. >> >> I have got: An i386 kerberos server, a ldap server in a jail on >> i386, some amd64 clients -- all running 8.1-RELEASE. Eventually >> there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. >> >> What do I need to "fix"? Just the ldap server? Is it enough to >> change the jail or does the host needs to be patches, too? Or do I >> need to fix the client, too? The kerberos server? >> >> From the discussion, multiple fixes were possible. Patching >> libgssapi and reinstalling everything depending on it (what?), >> installing the heimdal-1.0 port (while FreeBSD 8 comes with >> heimdal-1.1), installing an unofficial heimdal-1.2 port, ... >> >> Is that correct? Anything new after the discussion in July? >> >> From the discussion, some patches should already be in 8-STABLE, but >> I could not find the revision (after 8.1-RELEASE). >> >> If I upgraded the ldap jail to 8-STABLE, I guess the host needs to >> be updated, too. Hence I would prefer to just change ports or update >> single libraries. >> >> Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the >> libgssapi patch? With the heimdal-1.2 port? > > Can you please try the patch I proposed and see if it improves your > situation? Thanks. > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057830.html I had already tried the gss_release_buffer patch. It fixes that crash doing the GSSAPI operation from i386 and brings i386 in par with amd64 -- to the error message I mentioned above. I have also tried the change to /usr/bin/krb5-config before building OpenLDAP -- with no effect, either. I have not tried the "big" libgssapi patch from kern/147454 as I was hoping to do a smaller change. Cheers, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 13:58:04 2010 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 038E41065697 for ; Thu, 2 Sep 2010 13:58:04 +0000 (UTC) (envelope-from me@janh.de) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id B04298FC1B for ; Thu, 2 Sep 2010 13:58:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id D5F1A908DE; Thu, 2 Sep 2010 15:58:02 +0200 (CEST) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fsT3DYRMQimW; Thu, 2 Sep 2010 15:58:02 +0200 (CEST) Received: from nb895.math (g224012120.adsl.alicedsl.de [92.224.12.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 94A16908E0; Thu, 2 Sep 2010 15:58:02 +0200 (CEST) Message-ID: <4C7FAD64.40807@janh.de> Date: Thu, 02 Sep 2010 15:57:56 +0200 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100821 Thunderbird/3.0.6 MIME-Version: 1.0 To: Reko Turja References: <4C7E803F.1090606@janh.de> <99188991995E491B8101975CE4485ECC@rivendell> In-Reply-To: <99188991995E491B8101975CE4485ECC@rivendell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable-list freebsd Subject: Re: GSSAPI (for OpenLDAP) on FreeBSD 8? 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, 02 Sep 2010 13:58:04 -0000 On 09/02/2010 14:30, Reko Turja wrote: > -------------------------------------------------- > From: "Jan Henrik Sylvester" > Sent: Wednesday, September 01, 2010 7:33 PM > To: "stable-list freebsd" > Subject: GSSAPI (for OpenLDAP) on FreeBSD 8? > >> Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the >> libgssapi patch? With the heimdal-1.2 port? > > I got running and fully functional Heimdal/GSSAPI setup with Benjamins > patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=147454&cat=kern, > although I didn't test it with LDAP. Still my question, do I only have to patch the ldap server or the client doing gssapi ldap queries -- or even the kerberos server? Would a heimdal port be an alternative? Would that only have to be running on the ldap server or the client, too? Sorry, my understanding of gssapi is limited. Thanks, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:11:03 2010 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 274CF10657C3; Thu, 2 Sep 2010 14:11:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DDA5C8FC13; Thu, 2 Sep 2010 14:11:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82EB1nb032079; Thu, 2 Sep 2010 10:11:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82EB1Wu032078; Thu, 2 Sep 2010 14:11:01 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:11:01 GMT Message-Id: <201009021411.o82EB1Wu032078@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:11:03 -0000 TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for amd64/amd64 TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:39:09 - cvsupping the source tree TB --- 2010-09-02 13:39:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/amd64/amd64/supfile TB --- 2010-09-02 14:11:01 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:11:01 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:11:01 - 1.06 user 45.49 system 1983.73 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:12:32 2010 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 CDB0A10656D0; Thu, 2 Sep 2010 14:12:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3268FC08; Thu, 2 Sep 2010 14:12:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82ECVtP032087; Thu, 2 Sep 2010 10:12:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82ECVvx032086; Thu, 2 Sep 2010 14:12:31 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:12:31 GMT Message-Id: <201009021412.o82ECVvx032086@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:12:32 -0000 TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for arm/arm TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:38:29 - cvsupping the source tree TB --- 2010-09-02 13:38:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/arm/arm/supfile TB --- 2010-09-02 14:12:31 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:12:31 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:12:31 - 0.60 user 22.95 system 2073.61 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:13:20 2010 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 4812910656C5; Thu, 2 Sep 2010 14:13:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 09A7B8FC14; Thu, 2 Sep 2010 14:13:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82EDJQF032095; Thu, 2 Sep 2010 10:13:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82EDJRe032094; Thu, 2 Sep 2010 14:13:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:13:19 GMT Message-Id: <201009021413.o82EDJRe032094@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:13:20 -0000 TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for i386/pc98 TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:38:57 - cvsupping the source tree TB --- 2010-09-02 13:38:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/pc98/supfile TB --- 2010-09-02 14:13:19 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:13:19 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:13:19 - 1.03 user 39.16 system 2121.23 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:17:23 2010 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 3890810657D8; Thu, 2 Sep 2010 14:17:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EF21A8FC08; Thu, 2 Sep 2010 14:17:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82EHMFH032116; Thu, 2 Sep 2010 10:17:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82EHMC6032115; Thu, 2 Sep 2010 14:17:22 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:17:22 GMT Message-Id: <201009021417.o82EHMC6032115@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:17:23 -0000 TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:38:59 - cvsupping the source tree TB --- 2010-09-02 13:38:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2010-09-02 14:17:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:17:22 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:17:22 - 1.04 user 40.66 system 2364.02 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:46:21 2010 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 1899610656CF; Thu, 2 Sep 2010 14:46:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C98598FC17; Thu, 2 Sep 2010 14:46:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82EkKih032217; Thu, 2 Sep 2010 10:46:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82EkKWi032216; Thu, 2 Sep 2010 14:46:20 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:46:20 GMT Message-Id: <201009021446.o82EkKWi032216@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:46:21 -0000 TB --- 2010-09-02 14:11:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:11:02 - starting RELENG_8_0 tinderbox run for ia64/ia64 TB --- 2010-09-02 14:11:02 - cleaning the object tree TB --- 2010-09-02 14:11:29 - cvsupping the source tree TB --- 2010-09-02 14:11:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/ia64/ia64/supfile TB --- 2010-09-02 14:46:20 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:46:20 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:46:20 - 0.80 user 23.23 system 2117.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:48:22 2010 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 ED0061065708; Thu, 2 Sep 2010 14:48:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AEA6F8FC17; Thu, 2 Sep 2010 14:48:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82EmMnT032226; Thu, 2 Sep 2010 10:48:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82EmM0a032225; Thu, 2 Sep 2010 14:48:22 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:48:22 GMT Message-Id: <201009021448.o82EmM0a032225@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:48:23 -0000 TB --- 2010-09-02 14:13:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:13:19 - starting RELENG_8_0 tinderbox run for powerpc/powerpc TB --- 2010-09-02 14:13:19 - cleaning the object tree TB --- 2010-09-02 14:13:47 - cvsupping the source tree TB --- 2010-09-02 14:13:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/powerpc/powerpc/supfile TB --- 2010-09-02 14:48:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:48:22 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:48:22 - 0.77 user 21.16 system 2102.57 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:51:47 2010 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 CE940106579A; Thu, 2 Sep 2010 14:51:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 816A58FC14; Thu, 2 Sep 2010 14:51:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82EpkVL032243; Thu, 2 Sep 2010 10:51:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82EpkdM032242; Thu, 2 Sep 2010 14:51:46 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:51:46 GMT Message-Id: <201009021451.o82EpkdM032242@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:51:48 -0000 TB --- 2010-09-02 14:17:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:17:22 - starting RELENG_8_0 tinderbox run for sparc64/sparc64 TB --- 2010-09-02 14:17:22 - cleaning the object tree TB --- 2010-09-02 14:17:40 - cvsupping the source tree TB --- 2010-09-02 14:17:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/sparc64/sparc64/supfile TB --- 2010-09-02 14:51:46 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:51:46 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:51:46 - 0.68 user 12.12 system 2064.38 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:52:23 2010 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 865D810656C1; Thu, 2 Sep 2010 14:52:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 47E318FC14; Thu, 2 Sep 2010 14:52:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82EqMkj032251; Thu, 2 Sep 2010 10:52:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82EqMt0032250; Thu, 2 Sep 2010 14:52:22 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 14:52:22 GMT Message-Id: <201009021452.o82EqMt0032250@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:52:23 -0000 TB --- 2010-09-02 14:12:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:12:31 - starting RELENG_8_0 tinderbox run for mips/mips TB --- 2010-09-02 14:12:31 - cleaning the object tree TB --- 2010-09-02 14:12:46 - cvsupping the source tree TB --- 2010-09-02 14:12:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/mips/mips/supfile TB --- 2010-09-02 14:52:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:52:22 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:52:22 - 0.55 user 12.10 system 2390.79 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 14:57:02 2010 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 E424C1065694 for ; Thu, 2 Sep 2010 14:57:02 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 94AE68FC16 for ; Thu, 2 Sep 2010 14:57:02 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o82Ev0N6014279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2010 09:57:00 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o82Ev0Xm032509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2010 09:57:00 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o82Ev0ht032438; Thu, 2 Sep 2010 09:57:00 -0500 (CDT) (envelope-from dan) Date: Thu, 2 Sep 2010 09:57:00 -0500 From: Dan Nelson To: Tim Bishop Message-ID: <20100902145700.GG5913@dan.emsphone.com> References: <20100821220435.GA6208@carrick-users.bishnet.net> <20100821222429.GB73221@dan.emsphone.com> <20100831133556.GB45316@carrick-users.bishnet.net> <20100831155829.GC5913@dan.emsphone.com> <20100901151931.GB9224@carrick-users.bishnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100901151931.GB9224@carrick-users.bishnet.net> X-OS: FreeBSD 8.1-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Thu, 02 Sep 2010 09:57:01 -0500 (CDT) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1R ZFS almost locking up system 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, 02 Sep 2010 14:57:03 -0000 In the last episode (Sep 01), Tim Bishop said: > On Tue, Aug 31, 2010 at 10:58:29AM -0500, Dan Nelson wrote: > > In the last episode (Aug 31), Tim Bishop said: > > > It happened again this Saturday (clearly something in the weekly > > > periodic run is triggering the issue). procstat -kk shows the > > > following for processes doing something zfs related (where zfs related > > > means the string 'zfs' in the procstat -kk output): > > > > > > 0 100084 kernel zfs_vn_rele_task mi_switch+0x16f sleepq_wait+0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_trampoline+0xe > > > 5 100031 zfskern arc_reclaim_thre mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 fork_exit+0x118 fork_trampoline+0xe > > > 5 100032 zfskern l2arc_feed_threa mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be fork_exit+0x118 fork_trampoline+0xe > > > 5 100085 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_exit+0x118 fork_trampoline+0xe > > > 5 100086 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea spa_sync+0x355 txg_sync_thread+0x195 fork_exit+0x118 fork_trampoline+0xe > > > 17 100040 syncer - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_sync+0xa6 sync_fsync+0x184 sync_vnode+0x16b sched_sync+0x1c9 fork_exit+0x118 fork_trampoline+0xe > > > 2210 100156 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > > 3500 100177 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > > 3783 100056 syslogd - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > > 4064 100165 mysqld initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 > > > 4441 100224 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > > 4444 100227 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > > 4445 100228 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > > 4446 100229 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > > 4447 100089 python2.6 initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > > 5352 100270 mutt - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_freebsd_fsync+0xd7 null_bypass+0xd3 fsync+0x161 syscall+0x1e7 Xfast_syscall+0xe1 > > > 52686 100200 tarsnap - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 > > > 59049 100207 webalizer initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_pwritev+0x63 pwrite+0x59 syscall+0x1e7 Xfast_syscall+0xe1 > > > 77573 100479 perl - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 null_bypass+0xd3 VOP_WRITE_APV+0x141 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 write+0x55 syscall+0x1e7 Xfast_syscall+0xe1 > > > 78595 100275 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 > > > 81989 100596 zfs - mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c dsl_sync_task_group_wait+0x11c dmu_objset_snapshot+0x1b8 zfs_ioc_snapshot+0x7c zfsdev_ioctl+0x8d devfs_ioctl_f+0x77 kern_ioctl+0xf6 ioctl+0xfd syscall+0x1e7 Xfast_syscall+0xe1 > > > > > > I'm not sure if this shows anything useful? > > > > All your userland processes are basically waiting for the kernel to > > finish writing a ZFS transaction group to disk. mutt has called fsync, > > which may have been the trigger. Usually writing a transaction group is > > fast, though, because ZFS will batch up all the new data into one > > contiguous block and write it at full speed to disk. That's why I asked > > about full filesystems before, since if your FS has been near 99%, you > > may not have any large runs of freespace left. > > Right. But I wouldn't have thought that'd be effectively terminal? It's > not just a bit slow - the machine freezes up, sometimes for many hours > until rebooted. > > > I noticed in your original post: > > > > capacity operations bandwidth > > pool used avail read write read write > > ---------- ----- ----- ----- ----- ----- ----- > > pool0 117G 16.7G 248 114 865K 269K > > mirror 117G 16.7G 248 114 865K 269K > > ad4s3 - - 43 56 2.47M 269K > > ad6s3 - - 39 56 2.41M 269K > > ---------- ----- ----- ----- ----- ----- ----- > > I did a scrub the other day and I noticed this same pattern (reads > happening more on the disks and the pool). A scrub works down the ZFS tree, and due to COW the upper levels of metadata are likely to be scattered across the disk in small chunks, so the first 10% or so of the scrub will be tiny random reads. Once it gets down to actually checking file data it should max out all your disks throughput. > > # gstat > > ... > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > > 1 48 48 3042 9.8 0 0 0.0 47.6| ad4 > > 0 38 38 2406 10.5 0 0 0.0 39.5| ad6 > > > > You have a pair of mirrored disks, each doing around 40% I/O load, which > > is 80% load if a single-threaded task is driving all the I/O. I see the > > syncer process is also trying to write to the ZIL. Are you running > > something that does a lot of fsync calls (a database server for > > example)? Is this system an NFS server maybe? Try setting the sysctl > > vfs.zfs.zil_disable=1 and see if your performance improves. > > I am running both MySQL and PostgreSQL in jails, but both are extremely > lightly loaded. No NFS. > > I've looked at disabling the ZIL, but it doesn't seem to be a > recommended thing to do? This is just for debugging, to see whether ZIL is your problem. ZIL logs synchronous actions (fsync() and writes to O_SYNC files) as they happen, and is always replayed on reboot (as opposed to the rest of the txg which gets rolled back). http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 > I've also just upgraded to 8-STABLE to see if the few ZFS updates in > there make any difference. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 15:21:44 2010 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 D680D106566C; Thu, 2 Sep 2010 15:21:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 97ECA8FC19; Thu, 2 Sep 2010 15:21:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82FLhDX032354; Thu, 2 Sep 2010 11:21:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82FLh4r032353; Thu, 2 Sep 2010 15:21:43 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 15:21:43 GMT Message-Id: <201009021521.o82FLh4r032353@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:21:44 -0000 TB --- 2010-09-02 14:46:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:46:20 - starting RELENG_8_1 tinderbox run for amd64/amd64 TB --- 2010-09-02 14:46:20 - cleaning the object tree TB --- 2010-09-02 14:46:45 - cvsupping the source tree TB --- 2010-09-02 14:46:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/amd64/amd64/supfile TB --- 2010-09-02 15:21:43 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:21:43 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:21:43 - 0.80 user 14.66 system 2123.57 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 15:26:04 2010 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 3396310657F3; Thu, 2 Sep 2010 15:26:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A91BF8FC1C; Thu, 2 Sep 2010 15:26:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82FQ2Ap032382; Thu, 2 Sep 2010 11:26:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82FQ2Pe032381; Thu, 2 Sep 2010 15:26:02 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 15:26:02 GMT Message-Id: <201009021526.o82FQ2Pe032381@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:26:04 -0000 TB --- 2010-09-02 14:52:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:52:22 - starting RELENG_8_1 tinderbox run for i386/pc98 TB --- 2010-09-02 14:52:22 - cleaning the object tree TB --- 2010-09-02 14:52:39 - cvsupping the source tree TB --- 2010-09-02 14:52:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/pc98/supfile TB --- 2010-09-02 15:26:02 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:26:02 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:26:02 - 0.61 user 8.32 system 2019.98 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 15:26:22 2010 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 BA7A8106582D; Thu, 2 Sep 2010 15:26:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7ACC88FC08; Thu, 2 Sep 2010 15:26:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82FQLVK032390; Thu, 2 Sep 2010 11:26:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82FQLr6032389; Thu, 2 Sep 2010 15:26:21 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 15:26:21 GMT Message-Id: <201009021526.o82FQLr6032389@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:26:22 -0000 TB --- 2010-09-02 14:48:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:48:22 - starting RELENG_8_1 tinderbox run for arm/arm TB --- 2010-09-02 14:48:22 - cleaning the object tree TB --- 2010-09-02 14:48:28 - cvsupping the source tree TB --- 2010-09-02 14:48:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/arm/arm/supfile TB --- 2010-09-02 15:26:21 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:26:21 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:26:21 - 0.30 user 4.77 system 2279.44 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 15:27:22 2010 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 CD9D910656D2; Thu, 2 Sep 2010 15:27:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 88E148FC14; Thu, 2 Sep 2010 15:27:22 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o82FRGbD042834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Sep 2010 11:27:16 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o82FRGLo015592; Thu, 2 Sep 2010 11:27:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009021527.o82FRGLo015592@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Sep 2010 11:27:13 -0400 To: FreeBSD Tinderbox , FreeBSD Tinderbox , From: Mike Tancsa In-Reply-To: <201009021452.o82EqMt0032250@freebsd-current.sentex.ca> References: <201009021452.o82EqMt0032250@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: Re: [releng_8_0 tinderbox] failure on mips/mips 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, 02 Sep 2010 15:27:22 -0000 The cvsup server the tinder boxes update from is getting some more disk space installed. It should be able back up in another 45min or so. ---Mike At 10:52 AM 9/2/2010, FreeBSD Tinderbox wrote: >TB --- 2010-09-02 14:12:31 - tinderbox 2.6 running on >freebsd-current.sentex.ca >TB --- 2010-09-02 14:12:31 - starting RELENG_8_0 tinderbox run for mips/mips >TB --- 2010-09-02 14:12:31 - cleaning the object tree >TB --- 2010-09-02 14:12:46 - cvsupping the source tree >TB --- 2010-09-02 14:12:46 - /usr/bin/csup -z -r 3 -g -L 1 -h >cvsup.sentex.ca /tinderbox/RELENG_8_0/mips/mips/supfile >TB --- 2010-09-02 14:52:22 - WARNING: /usr/bin/csup returned exit code 1 >TB --- 2010-09-02 14:52:22 - ERROR: unable to cvsup the source tree >TB --- 2010-09-02 14:52:22 - 0.55 user 12.10 system 2390.79 real > > >http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-mips-mips.full >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 15:28:34 2010 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 4C878106566C; Thu, 2 Sep 2010 15:28:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1238FC08; Thu, 2 Sep 2010 15:28:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82FSXuP032398; Thu, 2 Sep 2010 11:28:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82FSX8B032397; Thu, 2 Sep 2010 15:28:33 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 15:28:33 GMT Message-Id: <201009021528.o82FSX8B032397@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:28:34 -0000 TB --- 2010-09-02 14:51:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:51:46 - starting RELENG_8_1 tinderbox run for i386/i386 TB --- 2010-09-02 14:51:46 - cleaning the object tree TB --- 2010-09-02 14:52:02 - cvsupping the source tree TB --- 2010-09-02 14:52:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/i386/supfile TB --- 2010-09-02 15:28:33 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:28:33 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:28:33 - 0.56 user 10.76 system 2206.35 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 15:55:42 2010 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 2C37310657D9; Thu, 2 Sep 2010 15:55:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DFAC18FC17; Thu, 2 Sep 2010 15:55:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82FtfEw032500; Thu, 2 Sep 2010 11:55:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82FtfON032499; Thu, 2 Sep 2010 15:55:41 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 15:55:41 GMT Message-Id: <201009021555.o82FtfON032499@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:55:42 -0000 TB --- 2010-09-02 15:21:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:21:43 - starting RELENG_8_1 tinderbox run for ia64/ia64 TB --- 2010-09-02 15:21:43 - cleaning the object tree TB --- 2010-09-02 15:21:58 - cvsupping the source tree TB --- 2010-09-02 15:21:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/ia64/ia64/supfile TB --- 2010-09-02 15:55:41 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:55:41 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:55:41 - 0.56 user 9.05 system 2037.13 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:00:12 2010 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 5713A10656E5; Thu, 2 Sep 2010 16:00:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5017B8FC19; Thu, 2 Sep 2010 16:00:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82G01gP032529; Thu, 2 Sep 2010 12:00:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82G01ht032528; Thu, 2 Sep 2010 16:00:01 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 16:00:01 GMT Message-Id: <201009021600.o82G01ht032528@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 16:00:12 -0000 TB --- 2010-09-02 15:26:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:26:21 - starting RELENG_8_1 tinderbox run for powerpc/powerpc TB --- 2010-09-02 15:26:21 - cleaning the object tree TB --- 2010-09-02 15:26:41 - cvsupping the source tree TB --- 2010-09-02 15:26:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/powerpc/powerpc/supfile TB --- 2010-09-02 16:00:01 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:00:01 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:00:01 - 0.48 user 9.36 system 2019.63 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:03:19 2010 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 58424106572B; Thu, 2 Sep 2010 16:03:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 157348FC14; Thu, 2 Sep 2010 16:03:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82G3IQJ032538; Thu, 2 Sep 2010 12:03:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82G3IJY032537; Thu, 2 Sep 2010 16:03:18 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 16:03:18 GMT Message-Id: <201009021603.o82G3IJY032537@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 16:03:19 -0000 TB --- 2010-09-02 15:26:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:26:03 - starting RELENG_8_1 tinderbox run for mips/mips TB --- 2010-09-02 15:26:03 - cleaning the object tree TB --- 2010-09-02 15:26:09 - cvsupping the source tree TB --- 2010-09-02 15:26:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/mips/mips/supfile TB --- 2010-09-02 16:03:18 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:03:18 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:03:18 - 0.30 user 4.59 system 2235.22 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:04:42 2010 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 06BB810656B0; Thu, 2 Sep 2010 16:04:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BCFD28FC29; Thu, 2 Sep 2010 16:04:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82G4fVL032546; Thu, 2 Sep 2010 12:04:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82G4fmS032545; Thu, 2 Sep 2010 16:04:41 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 16:04:41 GMT Message-Id: <201009021604.o82G4fmS032545@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 16:04:42 -0000 TB --- 2010-09-02 15:28:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:28:33 - starting RELENG_8_1 tinderbox run for sparc64/sparc64 TB --- 2010-09-02 15:28:33 - cleaning the object tree TB --- 2010-09-02 15:28:46 - cvsupping the source tree TB --- 2010-09-02 15:28:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/sparc64/sparc64/supfile TB --- 2010-09-02 16:04:41 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:04:41 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:04:41 - 0.62 user 8.91 system 2167.56 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:33:01 2010 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 9F19910657B1; Thu, 2 Sep 2010 16:33:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 612788FC18; Thu, 2 Sep 2010 16:33:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82GX0lw032634; Thu, 2 Sep 2010 12:33:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82GX0uS032633; Thu, 2 Sep 2010 16:33:00 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 16:33:00 GMT Message-Id: <201009021633.o82GX0uS032633@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 16:33:01 -0000 TB --- 2010-09-02 15:55:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:55:41 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-09-02 15:55:41 - cleaning the object tree TB --- 2010-09-02 15:56:02 - cvsupping the source tree TB --- 2010-09-02 15:56:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-09-02 16:33:00 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:33:00 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:33:00 - 0.76 user 10.60 system 2239.22 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:38:09 2010 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 3A2A310656FF; Thu, 2 Sep 2010 16:38:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F0DA98FC17; Thu, 2 Sep 2010 16:38:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82Gc8he032664; Thu, 2 Sep 2010 12:38:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82Gc81Q032663; Thu, 2 Sep 2010 16:38:08 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 16:38:08 GMT Message-Id: <201009021638.o82Gc81Q032663@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 16:38:09 -0000 TB --- 2010-09-02 16:00:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:00:01 - starting RELENG_8 tinderbox run for arm/arm TB --- 2010-09-02 16:00:01 - cleaning the object tree TB --- 2010-09-02 16:00:08 - cvsupping the source tree TB --- 2010-09-02 16:00:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2010-09-02 16:38:08 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:38:08 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:38:08 - 0.30 user 4.76 system 2286.32 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:40:37 2010 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 A20FF10656BF; Thu, 2 Sep 2010 16:40:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 636088FC17; Thu, 2 Sep 2010 16:40:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82GeaWg032680; Thu, 2 Sep 2010 12:40:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82GeaUR032679; Thu, 2 Sep 2010 16:40:36 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 16:40:36 GMT Message-Id: <201009021640.o82GeaUR032679@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 16:40:37 -0000 TB --- 2010-09-02 16:04:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:04:41 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-09-02 16:04:41 - cleaning the object tree TB --- 2010-09-02 16:04:52 - cvsupping the source tree TB --- 2010-09-02 16:04:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-09-02 16:40:36 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:40:36 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:40:36 - 0.62 user 8.16 system 2155.63 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:42:25 2010 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 3868910656AD; Thu, 2 Sep 2010 16:42:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EEE748FC15; Thu, 2 Sep 2010 16:42:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82GgO4Z032693; Thu, 2 Sep 2010 12:42:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82GgObw032692; Thu, 2 Sep 2010 16:42:24 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 16:42:24 GMT Message-Id: <201009021642.o82GgObw032692@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 16:42:25 -0000 TB --- 2010-09-02 16:03:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:03:18 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-09-02 16:03:18 - cleaning the object tree TB --- 2010-09-02 16:03:35 - cvsupping the source tree TB --- 2010-09-02 16:03:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-09-02 16:42:24 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:42:24 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:42:24 - 0.55 user 8.98 system 2345.92 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 16:48:06 2010 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 3C59310656D6 for ; Thu, 2 Sep 2010 16:48:06 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE7198FC21 for ; Thu, 2 Sep 2010 16:48:05 +0000 (UTC) Received: by fxm4 with SMTP id 4so443180fxm.13 for ; Thu, 02 Sep 2010 09:48:04 -0700 (PDT) Received: by 10.223.123.79 with SMTP id o15mr8867833far.12.1283446084237; Thu, 02 Sep 2010 09:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.137 with HTTP; Thu, 2 Sep 2010 09:47:44 -0700 (PDT) In-Reply-To: <4C7FA50D.4000409@sharescope.co.uk> References: <4C7FA50D.4000409@sharescope.co.uk> From: Joshua Boyd Date: Thu, 2 Sep 2010 12:47:44 -0400 Message-ID: To: Michal Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Extending your zfs pool with multiple devices 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, 02 Sep 2010 16:48:06 -0000 You need an HP SAS expander card in the new box, and an HBA in your primary box with external ports to hook it into. Then the drives in the other box will show up as local drives on your primary box. You don't even need an operating system on the second box, it just needs enough hardware in it to supply power to the SAS expander. On Thu, Sep 2, 2010 at 9:22 AM, Michal wrote: > I have a small problem that I am trying to work out a solution for. Imagine > you create a NAS box. Fill a small server with 5 hard drives, zfs them with > raidz or whatever, create your pools and then shear this to the network > using samba. Simple NAS box for your network to put their files and they > just connenct to \\nas1 > > This box is now full, my problem is that I could create a 2nd NAS box and > people use \\nas1 and \\nas2 but it's not very use friendly. Can I somehow > build a 2nd box which is identicle, but extend my pools into nas2. I was > thinking something like exporting the nas2 drives via iscsi and then nas1 > add's the drives to the pool...or something similar. I find that with any > NAS whether its home build or shop bought you will eventually run out of > space, and sure you can replace the HDD's with bigger ones but you will see > run out of space, and having multiple locations, in my mind, is not very > elegant. I cannot simply add more HDD's to the box as well as it's at full > capacity > > Thanks > _______________________________________________ > 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" > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 17:06:01 2010 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 9A8411065769; Thu, 2 Sep 2010 17:06:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5BEDC8FC14; Thu, 2 Sep 2010 17:05:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82H5wXv032782; Thu, 2 Sep 2010 13:05:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82H5wbu032781; Thu, 2 Sep 2010 17:05:58 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 17:05:58 GMT Message-Id: <201009021705.o82H5wbu032781@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 17:06:01 -0000 TB --- 2010-09-02 16:33:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:33:00 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2010-09-02 16:33:00 - cleaning the object tree TB --- 2010-09-02 16:33:16 - cvsupping the source tree TB --- 2010-09-02 16:33:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2010-09-02 17:05:58 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:05:58 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:05:58 - 0.58 user 7.76 system 1977.35 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 17:11:41 2010 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 D8FD410657E1; Thu, 2 Sep 2010 17:11:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD2A8FC19; Thu, 2 Sep 2010 17:11:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82HBeqj032808; Thu, 2 Sep 2010 13:11:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82HBeXj032807; Thu, 2 Sep 2010 17:11:40 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 17:11:40 GMT Message-Id: <201009021711.o82HBeXj032807@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 17:11:42 -0000 TB --- 2010-09-02 16:38:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:38:08 - starting RELENG_8 tinderbox run for mips/mips TB --- 2010-09-02 16:38:08 - cleaning the object tree TB --- 2010-09-02 16:38:15 - cvsupping the source tree TB --- 2010-09-02 16:38:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2010-09-02 17:11:40 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:11:40 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:11:40 - 0.27 user 4.62 system 2012.45 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 17:16:30 2010 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 1277E1065705; Thu, 2 Sep 2010 17:16:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BFADA8FC08; Thu, 2 Sep 2010 17:16:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82HGSEP032820; Thu, 2 Sep 2010 13:16:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82HGSx2032819; Thu, 2 Sep 2010 17:16:28 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 17:16:28 GMT Message-Id: <201009021716.o82HGSx2032819@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 17:16:30 -0000 TB --- 2010-09-02 16:40:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:40:37 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-09-02 16:40:37 - cleaning the object tree TB --- 2010-09-02 16:40:50 - cvsupping the source tree TB --- 2010-09-02 16:40:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-09-02 17:16:28 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:16:28 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:16:28 - 0.48 user 8.31 system 2151.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 17:16:34 2010 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 A5233106567A; Thu, 2 Sep 2010 17:16:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 676D68FC1B; Thu, 2 Sep 2010 17:16:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o82HGXRo032824; Thu, 2 Sep 2010 13:16:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o82HGXB4032823; Thu, 2 Sep 2010 17:16:33 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Sep 2010 17:16:33 GMT Message-Id: <201009021716.o82HGXB4032823@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 17:16:34 -0000 TB --- 2010-09-02 16:42:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:42:24 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-09-02 16:42:24 - cleaning the object tree TB --- 2010-09-02 16:42:36 - cvsupping the source tree TB --- 2010-09-02 16:42:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-09-02 17:16:33 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:16:33 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:16:33 - 0.54 user 8.34 system 2049.27 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 19:30:59 2010 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 211D310656F3 for ; Thu, 2 Sep 2010 19:30:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D6F978FC18 for ; Thu, 2 Sep 2010 19:30:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b47d:8c09:9df6:b96a] (unknown [IPv6:2001:7b8:3a7:0:b47d:8c09:9df6:b96a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1AD855C59; Thu, 2 Sep 2010 21:30:58 +0200 (CEST) Message-ID: <4C7FFB73.2000400@FreeBSD.org> Date: Thu, 02 Sep 2010 21:30:59 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.10pre) Gecko/20100831 Lanikai/3.1.4pre MIME-Version: 1.0 To: Rob Byrnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: AMD64 Buildworld error in i386-elf 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, 02 Sep 2010 19:30:59 -0000 On 2010-09-02 14:50, Rob Byrnes wrote: > Source is current as at 0030 on 2nd Sept. and I'm seeing this buildworld error: > > ===> gnu/lib/csu (obj,depend,all,install) > sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o > /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o > /usr/obj/usr/src/lib32/usr/lib32/crtend.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o > /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.So > /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o > sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.So > /usr/obj/usr/src/lib32/usr/lib32/crtendS.o > ===> lib/csu/i386-elf (obj,depend,all,install) > ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 -o gcrt1.o > -r crt1_s.o gcrt1_c.o > ld: Relocatable linking with relocations from format elf64-x86-64 > (gcrt1_c.o) to format elf32-i386-freebsd (gcrt1.o) is not supported > *** Error code 1 What is the contents of your /etc/make.conf and /etc/src.conf ? From owner-freebsd-stable@FreeBSD.ORG Thu Sep 2 21:26:36 2010 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 0EB2C1065834 for ; Thu, 2 Sep 2010 21:26:36 +0000 (UTC) (envelope-from zbeeble@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 B0F218FC1B for ; Thu, 2 Sep 2010 21:26:35 +0000 (UTC) Received: by gyg4 with SMTP id 4so472276gyg.13 for ; Thu, 02 Sep 2010 14:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HbFCH/6qTml4T2vSo8/fqfz+KPDxl8ztS72+J5F/AjU=; b=fbQcSdIcFNn1O5ItyKyagNgGENMkmUUJ+b97Do8hg0g0aNmKG4tLhpLYxBYjLUZapS ENuffgyn4jxUJp2OTU73YCfupRNfhzFqY323TWBWTPXl/vgiKxh0fACU2U7lmory5o3c +g/xMH3EW/VLx7b51Em3tPX7bK3kVsKjbnhiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WEAiq5I9Xh+GBJr4I/UnX7weoZOo9q5iRIIPkmvnnCt5jYcrnCMnZsbOEWLb+WaG+H Zny+4gnMb/JGUMHBiZUsJzgzF/d8qggM0kCrVnthMSm+J3euJDaTQOUKVEiV1kpIyVr7 jMumTLfyJNhC68iVRjNzLoYORIa/uqNTH5AAI= MIME-Version: 1.0 Received: by 10.150.12.19 with SMTP id 19mr140270ybl.50.1283460965049; Thu, 02 Sep 2010 13:56:05 -0700 (PDT) Received: by 10.150.186.5 with HTTP; Thu, 2 Sep 2010 13:56:04 -0700 (PDT) In-Reply-To: References: <4C7FA50D.4000409@sharescope.co.uk> Date: Thu, 2 Sep 2010 16:56:04 -0400 Message-ID: From: Zaphod Beeblebrox To: Joshua Boyd Content-Type: text/plain; charset=ISO-8859-1 Cc: Michal , freebsd-stable@freebsd.org Subject: Re: Extending your zfs pool with multiple devices 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, 02 Sep 2010 21:26:36 -0000 [regarding getting more disks in a machine] On Thu, Sep 2, 2010 at 12:47 PM, Joshua Boyd wrote: > You need an HP SAS expander card in the new box, and an HBA in your primary > box with external ports to hook it into. > > Then the drives in the other box will show up as local drives on your > primary box. > > You don't even need an operating system on the second box, it just needs > enough hardware in it to supply power to the SAS expander. An inexpensive option are SATA port replicators. Think SATA switch or hub. 1:4 is common and cheap. I have a motherboard with intel ICH10 chipset. It commonly provides 6 ports. This chipset is happy to configure port replicators. Meaning you can put 24 drives on this motherboard. Be warned that many SATA chipsets (even plugin cards) will not work with port replicators... But the ICH10 does and it makes a wonderfully cheap ZFS server. With 1.5T disks, I find that the 4 to 1 multipliers have a small effect on speed. The 4 drives I have on the multipler are saturated at 100% a little bit more than the drives directly connected. Essentially you have 3 gigabit for 4 drives instead of 3 gigabit for 1 drive. The ICH10 motherboard ports can be connected to the back of your system by cables and faceplaces that deliver eSATA connectors. I have my drives in a case that delivers eSATA (or USB). One USB for 4 drives was a dog, but the eSATA conneciton works well. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 04:08:44 2010 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 795211065782 for ; Fri, 3 Sep 2010 04:08:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 21B628FC08 for ; Fri, 3 Sep 2010 04:08:43 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id 23l81f0061wpRvQ5D48k0v; Fri, 03 Sep 2010 04:08:44 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta18.westchester.pa.mail.comcast.net with comcast id 248i1f0063LrwQ23e48j6r; Fri, 03 Sep 2010 04:08:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 59DAE9B425; Thu, 2 Sep 2010 21:08:41 -0700 (PDT) Date: Thu, 2 Sep 2010 21:08:41 -0700 From: Jeremy Chadwick To: Zaphod Beeblebrox Message-ID: <20100903040841.GA59175@icarus.home.lan> References: <4C7FA50D.4000409@sharescope.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Michal , Joshua Boyd , freebsd-stable@freebsd.org Subject: Re: Extending your zfs pool with multiple devices 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, 03 Sep 2010 04:08:44 -0000 On Thu, Sep 02, 2010 at 04:56:04PM -0400, Zaphod Beeblebrox wrote: > [regarding getting more disks in a machine] > > On Thu, Sep 2, 2010 at 12:47 PM, Joshua Boyd wrote: > > You need an HP SAS expander card in the new box, and an HBA in your primary > > box with external ports to hook it into. > > > > Then the drives in the other box will show up as local drives on your > > primary box. > > > > You don't even need an operating system on the second box, it just needs > > enough hardware in it to supply power to the SAS expander. > > An inexpensive option are SATA port replicators. Think SATA switch or > hub. 1:4 is common and cheap. > > I have a motherboard with intel ICH10 chipset. It commonly provides 6 > ports. This chipset is happy to configure port replicators. Meaning > you can put 24 drives on this motherboard. > > ... > > With 1.5T disks, I find that the 4 to 1 multipliers have a small > effect on speed. The 4 drives I have on the multipler are saturated > at 100% a little bit more than the drives directly connected. > Essentially you have 3 gigabit for 4 drives instead of 3 gigabit for 1 > drive. 1:4 SATA replicators impose a bottleneck on the overall bandwidth available between the replicator and the disks attached, as you stated. Diagram: ICH10 |||___ (SATA300) Port 0, Disk 0 ||____ (SATA300) Port 1, Disk 1 |_____ (SATA300) Port 2, eSATA Replicator ||||________ (SATA300) Port 0, Disk 2 |||_________ (SATA300) Port 1, Disk 3 ||__________ (SATA300) Port 2, Disk 4 |___________ (SATA300) Port 3, Disk 5 If Disks 2 through 5 are decent disks (pushing 100MB/sec), essentially you have 100*4 = 400MB/sec worth of bandwidth being shoved across a 300MB/sec link. That's making the assumption the disks attached are magnetic and not SSD, and not taking into consideration protocol overhead. Given the evolutionary rate of hard disks and SSDs, replicators are (in my opinion) not a viable solution mid or long-term. Even Silicon Image's products at this point are starting to force a 1:2 ratio on the replicators, probably to address the bottleneck issue: http://www.siliconimage.com/products/product.aspx?pid=154 http://www.siliconimage.com/products/product.aspx?pid=155 A better choice is a SATA multilane HBA, which are usually PCIe-based with a single connector on the back of the HBA which splits out to multiple disks (usually 4, but sometimes more). An ideal choice is ane Areca ARC-1300 series SAS-based PCIe x4 multilane adapters, which provides SATA300 to each individual disk and uses PCIe x4 (which can handle about 1GByte/sec in each direction, so 2GByte/sec total)... http://www.areca.com.tw/products/sasnoneraid.htm ...but there doesn't appear to be driver support for FreeBSD for this series of controller (arcmsr(4) doesn't mention the ARC-1300 series). I also don't know what Areca means on their site when they say "BSD/FreeBSD (will be available with 6Gb/s Host Adapter"), given that none of the ARC-1300 series cards are SATA600. If people are more focused on total number of devices (disks) that are available, then they should probably be looking at dropping a pretty penny on a low-end filer. Otherwise, consider replacing the actual hard disks themselves with drives of a higher capacity. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 04:39:03 2010 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 8713A106586B for ; Fri, 3 Sep 2010 04:39:03 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED298FC12 for ; Fri, 3 Sep 2010 04:39:02 +0000 (UTC) Received: by gwb15 with SMTP id 15so562046gwb.13 for ; Thu, 02 Sep 2010 21:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VlUVH08o63ZYnfHNdPa7UjDClLd284b7CuYodRtZB1I=; b=Brk472hFR2xzuE5zC0OcqBfhXePVO1tAhpwb4iZkRyv7p8lvDYhKWcmluCu268t/u8 ACUWkMVed4X6FGJzwaUyytCnbClEYqXnB7RyFSe8u35wYEfyPh3yaOcBpEV1/njBb8Bu Fl1tSiHOgOAylO2PucaHPuExlzIQeDt4zwLn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Uv4uMYNS91b2BZbRuEwSp74GmuVI8fhfh+CE3qG+1yyOLcZzXkyaLHvnbopODUGzvj IJHNOBzZfDxKftkrWmlaqPP1xI9mZBP0KkApRzVXgdydS4b5lye1nfyDiJY4KpSSJaKi h200lAvPgznPwHMc7ihOt4CCOlUt6B4Kb7Zko= MIME-Version: 1.0 Received: by 10.150.181.10 with SMTP id d10mr540949ybf.263.1283488742041; Thu, 02 Sep 2010 21:39:02 -0700 (PDT) Received: by 10.150.186.5 with HTTP; Thu, 2 Sep 2010 21:39:01 -0700 (PDT) In-Reply-To: <20100903040841.GA59175@icarus.home.lan> References: <4C7FA50D.4000409@sharescope.co.uk> <20100903040841.GA59175@icarus.home.lan> Date: Fri, 3 Sep 2010 00:39:01 -0400 Message-ID: From: Zaphod Beeblebrox To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michal , Joshua Boyd , freebsd-stable@freebsd.org Subject: Re: Extending your zfs pool with multiple devices 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, 03 Sep 2010 04:39:03 -0000 On Fri, Sep 3, 2010 at 12:08 AM, Jeremy Chadwick wrote: > On Thu, Sep 02, 2010 at 04:56:04PM -0400, Zaphod Beeblebrox wrote: >> With 1.5T disks, I find that the 4 to 1 multipliers have a small >> effect on speed. =A0The 4 drives I have on the multipler are saturated >> at 100% a little bit more than the drives directly connected. >> Essentially you have 3 gigabit for 4 drives instead of 3 gigabit for 1 >> drive. > > 1:4 SATA replicators impose a bottleneck on the overall bandwidth > available between the replicator and the disks attached, as you stated. > Diagram: > > ICH10 > =A0|||___ (SATA300) Port 0, Disk 0 > =A0||____ (SATA300) Port 1, Disk 1 > =A0|_____ (SATA300) Port 2, eSATA Replicator > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ||||________ (SATA300= ) Port 0, Disk 2 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |||_________ (SATA300= ) Port 1, Disk 3 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ||__________ (SATA300= ) Port 2, Disk 4 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |___________ (SATA300= ) Port 3, Disk 5 > > If Disks 2 through 5 are decent disks (pushing 100MB/sec), essentially > you have 100*4 =3D 400MB/sec worth of bandwidth being shoved across a > 300MB/sec link. =A0That's making the assumption the disks attached are > magnetic and not SSD, and not taking into consideration protocol > overhead. > A better choice is a SATA multilane HBA, which are usually PCIe-based > with a single connector on the back of the HBA which splits out to > multiple disks (usually 4, but sometimes more). That's just connector-foo. The cards are still very expensive. Many ZFS loads don't saturate disks ... or don't saturate them consistently. I just built several systems with one port per disk --- and those cards tended towards $100/port. 1:4 replicators are less than $10/port and the six port motherboards don't seem to add any cost (4 or 6 SATA ports seem standard now). My point is: if you're building a database server and speed is all you care about, then one port per disk makes sense. If you are building a pile of disk and you're on a budget, port replicators are a good solution. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 05:19:39 2010 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 29E6C1065873 for ; Fri, 3 Sep 2010 05:19:39 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E11D18FC0A for ; Fri, 3 Sep 2010 05:19:38 +0000 (UTC) Received: by iwn34 with SMTP id 34so1392995iwn.13 for ; Thu, 02 Sep 2010 22:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=45fguV2k1Qguc6SXgy09LrvlUh+lrLqfY/r4nZUhiKU=; b=JR4fiqedw4iAC+UgIpTwel9dxo8u70ZsSmCcAkLChWKaipAwj0RFcLQ2dxip8Qe0YM PFdenkAoJBm3EFSZjv7xPH6cUqVzmXVdFaURg2/3xvOR8oLTu0KBw9qYgdbO+rT5QFdB n2D3vbFlxXSx2qcHsIzZRMHHQDHFLbXC5xoMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=H7duU834qJVcvZPs6AzgqlkF3EE30UU19gLAkeGQ8K+WxbwJ7JnADooz8z3qAasPJv tQHeEXy1kpHAkCPqLqu4C5VV8bg4BA6vs8crVYVX7Xk3nPUmzaQyI2qB7GJ8oZWCdm52 3kOkUKmDNQ45doN+npVW89G3D2HF6RLvMkMvs= MIME-Version: 1.0 Received: by 10.231.17.1 with SMTP id q1mr354568iba.17.1283489852725; Thu, 02 Sep 2010 21:57:32 -0700 (PDT) Received: by 10.231.168.83 with HTTP; Thu, 2 Sep 2010 21:57:32 -0700 (PDT) In-Reply-To: References: <4C7FA50D.4000409@sharescope.co.uk> <20100903040841.GA59175@icarus.home.lan> Date: Fri, 3 Sep 2010 11:57:32 +0700 Message-ID: From: Edho P Arief To: Zaphod Beeblebrox Content-Type: text/plain; charset=UTF-8 Cc: Michal , Joshua Boyd , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Extending your zfs pool with multiple devices 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, 03 Sep 2010 05:19:39 -0000 geom_gate - ggated(8) Not going to be fast though (sorry for bad reply, mobile gmail sucks) -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 07:43:42 2010 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 53EED106570E for ; Fri, 3 Sep 2010 07:43:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 5A6A18FC22 for ; Fri, 3 Sep 2010 07:43:40 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id o835grvr044134; Thu, 2 Sep 2010 22:42:57 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201009030542.o835grvr044134@gw.catspoiler.org> Date: Thu, 2 Sep 2010 22:42:53 -0700 (PDT) From: Don Lewis To: freebsd@jdc.parodius.com In-Reply-To: <20100903040841.GA59175@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: boydjd@jbip.net, michal@sharescope.co.uk, zbeeble@gmail.com, freebsd-stable@freebsd.org Subject: Re: Extending your zfs pool with multiple devices 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, 03 Sep 2010 07:43:42 -0000 On 2 Sep, Jeremy Chadwick wrote: > On Thu, Sep 02, 2010 at 04:56:04PM -0400, Zaphod Beeblebrox wrote: >> [regarding getting more disks in a machine] >> An inexpensive option are SATA port replicators. Think SATA switch or >> hub. 1:4 is common and cheap. >> >> I have a motherboard with intel ICH10 chipset. It commonly provides 6 >> ports. This chipset is happy to configure port replicators. Meaning >> you can put 24 drives on this motherboard. >> >> ... >> >> With 1.5T disks, I find that the 4 to 1 multipliers have a small >> effect on speed. The 4 drives I have on the multipler are saturated >> at 100% a little bit more than the drives directly connected. >> Essentially you have 3 gigabit for 4 drives instead of 3 gigabit for 1 >> drive. > > 1:4 SATA replicators impose a bottleneck on the overall bandwidth > available between the replicator and the disks attached, as you stated. > Diagram: > > ICH10 > |||___ (SATA300) Port 0, Disk 0 > ||____ (SATA300) Port 1, Disk 1 > |_____ (SATA300) Port 2, eSATA Replicator > ||||________ (SATA300) Port 0, Disk 2 > |||_________ (SATA300) Port 1, Disk 3 > ||__________ (SATA300) Port 2, Disk 4 > |___________ (SATA300) Port 3, Disk 5 > > If Disks 2 through 5 are decent disks (pushing 100MB/sec), essentially > you have 100*4 = 400MB/sec worth of bandwidth being shoved across a > 300MB/sec link. That's making the assumption the disks attached are > magnetic and not SSD, and not taking into consideration protocol > overhead. > > Given the evolutionary rate of hard disks and SSDs, replicators are (in > my opinion) not a viable solution mid or long-term. > A better choice is a SATA multilane HBA, which are usually PCIe-based > with a single connector on the back of the HBA which splits out to > multiple disks (usually 4, but sometimes more). > > An ideal choice is ane Areca ARC-1300 series SAS-based PCIe x4 multilane > adapters, which provides SATA300 to each individual disk and uses PCIe > x4 (which can handle about 1GByte/sec in each direction, so 2GByte/sec > total)... > > http://www.areca.com.tw/products/sasnoneraid.htm > > ...but there doesn't appear to be driver support for FreeBSD for this > series of controller (arcmsr(4) doesn't mention the ARC-1300 series). I > also don't know what Areca means on their site when they say > "BSD/FreeBSD (will be available with 6Gb/s Host Adapter"), given that > none of the ARC-1300 series cards are SATA600. > > If people are more focused on total number of devices (disks) that are > available, then they should probably be looking at dropping a pretty > penny on a low-end filer. Otherwise, consider replacing the actual hard > disks themselves with drives of a higher capacity. [raises hand] Here's what I've got on my mythtv box (running Fedora ... sorry): Filesystem Size /dev/sda4 439G /dev/sdb1 1.9T /dev/sdc1 1.9T /dev/sdd1 1.9T /dev/sde1 1.9T /dev/sdf1 1.4T /dev/sdg1 1.4T /dev/sdh1 932G /dev/sdi1 932G /dev/sdj1 1.4T /dev/sdk1 1.9T /dev/sdl1 932G /dev/sdm1 1.9T /dev/sdn1 932G /dev/sdo1 699G /dev/sdp1 1.4T I'm currently upgrading the older drives as I run out of space, and I'm really hoping that >> 2TB drives arrive soon. The motherboard is full-size ATX with six onboard SATA ports, all of which are in use. The only x16 PCIe slot is occupied by a graphics card, and all but one of the x1 PCIe slots are in use. One of the x1 PCIe slots has a Silicon Image two-port ESATA controller, which connects to two external enclosures with 1:4 and 1:5 port replicators. At the moment there are also three external USB drives. This weekend's project is to install a new 2TB drive and do some consolidation. Fortunately the bandwidth requirements aren't too high ... From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 08:23:52 2010 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 04D041065902 for ; Fri, 3 Sep 2010 08:23:52 +0000 (UTC) (envelope-from michal@sharescope.co.uk) Received: from mail1.sharescope.co.uk (mail1.ionic.co.uk [85.159.80.19]) by mx1.freebsd.org (Postfix) with ESMTP id B99EB8FC1B for ; Fri, 3 Sep 2010 08:23:51 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail1.sharescope.co.uk (Postfix) with ESMTP id AC5F1FC0C5 for ; Fri, 3 Sep 2010 08:23:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at sharescope.co.uk Received: from mail1.sharescope.co.uk ([127.0.0.1]) by localhost (mail1.sharescope.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU29mvtPHJBS for ; Fri, 3 Sep 2010 09:23:34 +0100 (BST) Received: from [192.168.2.50] (unknown [85.159.85.2]) (Authenticated sender: chris@sharescope.co.uk) by mail1.sharescope.co.uk (Postfix) with ESMTPSA id BA437FC0C3 for ; Fri, 3 Sep 2010 09:23:34 +0100 (BST) Message-ID: <4C80B116.1040800@sharescope.co.uk> Date: Fri, 03 Sep 2010 09:25:58 +0100 From: Michal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C7FA50D.4000409@sharescope.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Extending your zfs pool with multiple devices 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, 03 Sep 2010 08:23:52 -0000 What is really odd is I see your replies but not my original post, how very strange?? Thank you for all of your assistance. I would like to move to being able to build a cheap san-like storage area for a DB, I don't know how well it would work but I'd like to try it anyway since things like HP MSA's are hugely expensive. I like these suggestions of filling a second box and connecting this to the 1st box using these expanders and port replicators. I don't really need as fast as I can get as this is not a high-use DB backend or many user file server. A few users here and there but nothing that worries me about the bottleneck caused by these replicators. This way is ALOT better then my system of trying to export iscsi disks or something like that. This way I can add create a second box then have a cable into an expander or replicator on the 1st box, a 3rd box could then be added to the expander/replicator at a later date. There is a limit on how far this could go realistically, but I like this way. I could go further by adding SSD's for the L2ARC and ZIL if I wanted to. I found zfsbuild.com to be a quite nice site/blog Thanks for all your help From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 10:57:48 2010 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 1DA7710657BF for ; Fri, 3 Sep 2010 10:57:48 +0000 (UTC) (envelope-from jhellenthal@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 C42588FC1E for ; Fri, 3 Sep 2010 10:57:47 +0000 (UTC) Received: by gyg4 with SMTP id 4so742994gyg.13 for ; Fri, 03 Sep 2010 03:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=eHFD5HPkyEHU6sRbPiswYOKXB5IsM9XB/J1bU0b8h2s=; b=htrnYl4sjDGdKVeYwXf7O63rpl3ioubws4QMqvYUF+LpWdwMya7e+KP3VHc8nJmtx4 23VaG+Lw87uMEYs6mIZxkFTSE1Oa25Y6gNYjGtFX8pllNMY+bGEx/nwBzU9HEyBEH0pW PEgE9J0juTCG7FImIXPPZdqjXxUcasejc9a8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=v8Bn/cN6Yt3T2H0YHs0gq3bRjeG8pFf8DAx83sgKXq1+6zU13GSaTLvfNV9LMdlCiU I7Br/IwLChp+ItPA4uBc7nQ6815zgN6YKnyj+C/QKwv0gleYwL08EQ3OXsJ3a/ZljZ8U exJDPpdR/bZj0YJmXMugvWYcu/DMSheVkQ85s= Received: by 10.100.235.9 with SMTP id i9mr660395anh.218.1283511465170; Fri, 03 Sep 2010 03:57:45 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-137-20.dsl.klmzmi.sbcglobal.net [99.181.137.20]) by mx.google.com with ESMTPS id w6sm2515448anb.23.2010.09.03.03.57.43 (version=SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 03:57:44 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C80D4A6.9010403@DataIX.net> Date: Fri, 03 Sep 2010 06:57:42 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Michal References: <4C7FA50D.4000409@sharescope.co.uk> <4C80B116.1040800@sharescope.co.uk> In-Reply-To: <4C80B116.1040800@sharescope.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Extending your zfs pool with multiple devices 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, 03 Sep 2010 10:57:48 -0000 On 09/03/2010 04:25, Michal wrote: > What is really odd is I see your replies but not my original post, how > very strange?? > > Thank you for all of your assistance. I would like to move to being able > to build a cheap san-like storage area for a DB, I don't know how well > it would work but I'd like to try it anyway since things like HP MSA's > are hugely expensive. > > I like these suggestions of filling a second box and connecting this to > the 1st box using these expanders and port replicators. I don't really > need as fast as I can get as this is not a high-use DB backend or many > user file server. A few users here and there but nothing that worries me > about the bottleneck caused by these replicators. This way is ALOT > better then my system of trying to export iscsi disks or something like > that. This way I can add create a second box then have a cable into an > expander or replicator on the 1st box, a 3rd box could then be added to > the expander/replicator at a later date. There is a limit on how far > this could go realistically, but I like this way. I could go further by > adding SSD's for the L2ARC and ZIL if I wanted to. I found zfsbuild.com > to be a quite nice site/blog > Thanks for the link: zfsbuild.com I'm going to check that out. Anyway... not that this is a great solution but if it is windows clients that are connecting to this that your worried about and would like to split off storage to separate machines etc... you can use DFS with Samba. Imagine building two more machines and having them be completely transparent to the clients that connect to the main server. Using a Samba DFS server would allow you to distribute out the file-systems to different shares on different machines without the client ever having to know that the actual location that the directory lays on is another machine and allows you to easily migrate new servers into the network without client ever seeing the change. Implement ISCSI, ZFS & HAST into this mix and you have yourself one hell of a network. Just an idea, Regards, -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 19:30:23 2010 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 ABCA710656C3 for ; Fri, 3 Sep 2010 19:30:23 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 506DB8FC19 for ; Fri, 3 Sep 2010 19:30:23 +0000 (UTC) Received: by ywt2 with SMTP id 2so1078422ywt.13 for ; Fri, 03 Sep 2010 12:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xKkiARaGzgLky2u+et4LkzFmZ50BNgR9/8WTnoqdXjY=; b=rn2JK45fsB4C9JcZI/csf69TFnXvwvrUkT5F6DANwUEDc2PCdilZtWPC7gT/u2oq/e pwzpLIvQRWqwVpQBBEc9m0VAW5q+qgLSG1qXqr2cT/BNGr2HNcIgDPhL6VWWFK0ZDHCO NspjjrE17MtvYnSF5PvqWbZNmbMCeOz7fAHTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IB7RLCrbfxhvHZmUQuKoojDYX2eRtCbvPMhY51lCiYQgfwZFB7NDfaXXecZGfkj/tO TfCsVI1XnW6lPGuaWW3yugFwBhkoB0riidN+CJKw+GjKi/F5JLhFwHmhyvwvgmuIpmrq b1vfjH5+qWtGwl7LeLB3sF80njDGa16vrqgB8= Received: by 10.101.84.18 with SMTP id m18mr241218anl.60.1283540591097; Fri, 03 Sep 2010 12:03:11 -0700 (PDT) Received: from orb.electron-tube.net (71-217-215-181.cdrr.qwest.net [71.217.215.181]) by mx.google.com with ESMTPS id d4sm3132214and.19.2010.09.03.12.03.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 12:03:09 -0700 (PDT) Message-ID: <4C814665.3070306@gmail.com> Date: Fri, 03 Sep 2010 14:03:01 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100731) MIME-Version: 1.0 To: Luca Pizzamiglio References: <4C7F7C0F.8080004@icyb.net.ua> <4C7F9ACE.80705@bally-wulff.de> In-Reply-To: <4C7F9ACE.80705@bally-wulff.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 03 Sep 2010 19:30:23 -0000 i just noticed this too... had a build going of qt-creator, and then started a /usr/src make clean, and had to abort the qt-creator build to get the make clean to finish. it was taking forever to even paint the xterm in the make clean window. -stable built as of last week, amd64 kernel, core2 duo e8200, 4G ram (3.9G usable), intel dq45ek motherboard, kde4, compositing turned off. Luca Pizzamiglio wrote: > Hello, > > My machine has a similar behavior. For instance, during intensive > workload (portupgrade), everything is quite not-responsive. > > I made an alias of portupgrade, nice -n 5 portupgrade, that solves the > problem just in that particular case. > > My system is AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class > CPU) with openGL effects disabled, KDE as desktop environment. > > There is an interesting mib kern.sched.interact. But I don't know the > meaning of it (my value is 30). > > Cheers, > Luca > > On 09/02/2010 12:46, jan.grant@bristol.ac.uk wrote: >> On Thu, 2 Sep 2010, Andriy Gapon wrote: >> >>> on 02/09/2010 12:08 jan.grant@bristol.ac.uk said the following: >>>> On Wed, 1 Sep 2010, Ivan Voras wrote: >>>> >>>>> On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: >>>>>> I'm running -STABLE with a kde-derived desktop. This setup (which is >>>>>> pretty standard) is providing abysmal interactive performance on an >>>>>> eight-core machine whenever I try to do anything CPU-intensive >>>>>> (such as >>>>>> building a port). >>>>>> >>>>>> Basically, trying to build anything from ports rapidly renders >>>>>> everything >>>>>> else so "non-interactive" in the eyes of the scheduler that, for >>>>>> instance, >>>>>> switching between virtual desktops (I have six of them in reasonably >>>>>> frequent use) takes about a minute of painful waiting on redraws to >>>>>> complete. >>>>> >>>>> Are you sure this is about the scheduler or maybe bad X11 drivers? >>>> >>>> Not 100%, but mostly convinced; I've just started looking at this. >>>> It's my >>>> first stab at what might be going on. X11 performance is usually >>>> pretty >>>> snappy. There's no paging pressure at all. >>> >>> From my experience: >>> 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no >>> issues with >>> interaction between buildworld and GUI with all KDE4 effects enabled >>> (OpenGL). >>> 2. system with comparable Core2 Duo CPU and onboard Intel graphics >>> (G33) - >>> enabling OpenGL desktop effects in KDE4 leads to the consequences >>> like what you >>> describe. With all GUI bells and whistles disabled the system >>> behaves quite >>> like the AMD system. >> >> All desktop effects are disabled. The graphics are from an nVidia >> GeForce >> 8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour >> that's affected, though: the box runs a number of small headless >> [interactive] server processes which also appear to get rapidly >> starved of >> CPU time.) >> >> The behaviour isn't visible with the 4bsd scheduler; "stuff" generally >> remains snappy and responsive. >> >> I'll keep poking around and see if I can get to the bottom of it. >> >> >> > From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 20:23:39 2010 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 5934210656CD for ; Fri, 3 Sep 2010 20:23:39 +0000 (UTC) (envelope-from kc5vdj.freebsd@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 077B88FC1E for ; Fri, 3 Sep 2010 20:23:38 +0000 (UTC) Received: by gyg4 with SMTP id 4so1114938gyg.13 for ; Fri, 03 Sep 2010 13:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=aiNsRroQn756bj4XZfDl+cV5OfuZ3FxOzTQU39KCaic=; b=ZAI9TTL7Xu/Vjk+GEPfjnpp+sbRnCk6+1K0SncGHhqvzGtJmQ/WsKiO5C06TsidBwu dICNXIq01/kE4zNdwGBd8OdQ6UQ4hqjA/GKdjS1HCY/wp1qSwJYK8acK0qvxE0X0sHYn 2PQrnFmUERPvxSUc6tfYxG1Vz0lw6CeqTLOl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=MxVI5mJ50WJrdjRGDAlqgFcx+XaJT0ahdAR0lCKN9oJdiGpda3E4SWjCzKFtdUGuBa MN8Q1bFcXTpXhzLmXD1o8QfOQPDkvwj0zm2biLtGJxnDJ4rXOObwfZ55z4yVm7umB3lS vYWGWmDw1AP5ZCpQKvTQgWwg+eBq1hXdvkFqM= Received: by 10.100.41.9 with SMTP id o9mr326818ano.240.1283544016094; Fri, 03 Sep 2010 13:00:16 -0700 (PDT) Received: from orb.electron-tube.net (71-217-215-181.cdrr.qwest.net [71.217.215.181]) by mx.google.com with ESMTPS id x19sm3208059anc.25.2010.09.03.13.00.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 13:00:14 -0700 (PDT) Message-ID: <4C8153C4.70507@gmail.com> Date: Fri, 03 Sep 2010 15:00:04 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100731) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: what's up with cvsup? 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, 03 Sep 2010 20:23:39 -0000 is it just me, or are all the cvsup servers down? i've tried this on several machines, i can ping some of them (not all), and the ones that can be pinged all timeout when doing a make update in /usr/src. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 20:29:24 2010 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 BC37510656C8 for ; Fri, 3 Sep 2010 20:29:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 63C2D8FC16 for ; Fri, 3 Sep 2010 20:29:23 +0000 (UTC) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id 2CMN1f00316LCl052LVQLp; Fri, 03 Sep 2010 20:29:24 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta06.westchester.pa.mail.comcast.net with comcast id 2LVP1f0053LrwQ23SLVPjk; Fri, 03 Sep 2010 20:29:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 224919B425; Fri, 3 Sep 2010 13:29:22 -0700 (PDT) Date: Fri, 3 Sep 2010 13:29:22 -0700 From: Jeremy Chadwick To: Jim Bryant Message-ID: <20100903202922.GA84852@icarus.home.lan> References: <4C8153C4.70507@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C8153C4.70507@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org Subject: Re: what's up with cvsup? 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, 03 Sep 2010 20:29:24 -0000 On Fri, Sep 03, 2010 at 03:00:04PM -0500, Jim Bryant wrote: > is it just me, or are all the cvsup servers down? > > i've tried this on several machines, i can ping some of them (not > all), and the ones that can be pinged all timeout when doing a make > update in /usr/src. It's just you. Timestamp below is in PDT (UTC-0700). (13:27:42 jdc@icarus) ~ $ all_csup -------------------------------------------------------------- >>> Running /usr/bin/csup -------------------------------------------------------------- Parsing supfile "/usr/share/examples/cvsup/ports-supfile" Connecting to cvsup10.freebsd.org Connected to 69.147.83.48 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection ports-all/cvs ^CCleaning up ... Interrupted If you received any sort of error or informational message from any of the servers (such as indication that the server was unreachable and the client would retry in 10 (?) minutes), then all of the cvsup servers you tried were, at that moment in time, syncing from cvsup-master. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 20:32:46 2010 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 DCDD310656C0 for ; Fri, 3 Sep 2010 20:32:46 +0000 (UTC) (envelope-from varga.michal@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 1CD1F8FC0A for ; Fri, 3 Sep 2010 20:32:45 +0000 (UTC) Received: by bwz20 with SMTP id 20so2273007bwz.13 for ; Fri, 03 Sep 2010 13:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:organization:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=ukW7rghEmybZzWubT4DH5lioAnOU6ZjsNL9opXTILdE=; b=R81T5fqi6xBJxF9k7SVU1f+6Exku+Vpq/ouMrow3fxm3a7QX8JljXkk5OpodGosF+N H/fuqNVwhAD3Koilu62NzyafTK0vO5flU4wRM07kTGspI0W4FW732mgDrrD7z7gvoHU5 0Q34tekce7dkWhFWUnifsmzSWEbvUQyPAmQzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=nX4xyLtxiGfdxD4hRukJUT8Tm9oI/m8a59LvlNsWMXrClxG7RIY2XcQ3vC4HR/g8F4 3d8Y53t1Pgw4uouKSsnoLpMABE983YNhTDlerNKgoMXVs2IMA9vZvsRd2G/SRyj6dMbD wzaMSt59lYxCjNoFWDVZBwSejXjm/kSq79ON4= Received: by 10.204.141.16 with SMTP id k16mr826317bku.177.1283544522645; Fri, 03 Sep 2010 13:08:42 -0700 (PDT) Received: from [10.0.101.2] (73.44.broadband10.iol.cz [90.177.44.73]) by mx.google.com with ESMTPS id f18sm1784904bkf.3.2010.09.03.13.08.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 13:08:41 -0700 (PDT) From: Michal Varga To: Jim Bryant In-Reply-To: <4C814665.3070306@gmail.com> References: <4C7F7C0F.8080004@icyb.net.ua> <4C7F9ACE.80705@bally-wulff.de> <4C814665.3070306@gmail.com> Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Fri, 03 Sep 2010 22:08:38 +0200 Message-ID: <1283544518.26203.33.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org, Luca Pizzamiglio Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 03 Sep 2010 20:32:46 -0000 On Fri, 2010-09-03 at 14:03 -0500, Jim Bryant wrote: > i just noticed this too... had a build going of qt-creator, and then > started a /usr/src make clean, and had to abort the qt-creator build to > get the make clean to finish. it was taking forever to even paint the > xterm in the make clean window. This has been the state of -stable for at least an year, I have yet to see a 7-stable machine that doesn't exhibit this behavior. This wasn't the case with 7 in the very beginning and only started slowly building up over time, particularly around the time of one specific xorg import - which one it was? 7.4? I guess. Every bit of performance went down the drain hole by that time and it's on that same level ever since (it's rather easy to get used to it while working on a 7-stable desktop, but would be nice having the old pre-ULE performance levels back, sometime). On the other hand, at least from some of my observations, the terrible desktop performance isn't strictly CPU-bound, I/O definitely has some say in this. You can (you should, mileage may vary) see this by trying to extract a few-GB archive in the background. While clearly no more than a single CPU is ever occupied by that process (and there's few other happily idling), you can spend waiting up to a few minutes just to get a new application launched (or even just a running one getting redrawn, in case part of it was swapped out at the moment). But as I said, for 7-stable, this has been the case for a veeeeeery long time. m. -- Michal Varga, Stonehenge (Gmail account) From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 20:50:12 2010 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 44D0710656AB for ; Fri, 3 Sep 2010 20:50:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2407A8FC17 for ; Fri, 3 Sep 2010 20:50:11 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 2EN91f0060x6nqcA2LqBzp; Fri, 03 Sep 2010 20:50:11 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta12.emeryville.ca.mail.comcast.net with comcast id 2LqA1f0053LrwQ28YLqASV; Fri, 03 Sep 2010 20:50:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2EC779B425; Fri, 3 Sep 2010 13:50:10 -0700 (PDT) Date: Fri, 3 Sep 2010 13:50:10 -0700 From: Jeremy Chadwick To: Michal Varga Message-ID: <20100903205010.GA85105@icarus.home.lan> References: <4C7F7C0F.8080004@icyb.net.ua> <4C7F9ACE.80705@bally-wulff.de> <4C814665.3070306@gmail.com> <1283544518.26203.33.camel@xenon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1283544518.26203.33.camel@xenon> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org, Jim Bryant , Luca Pizzamiglio Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 03 Sep 2010 20:50:12 -0000 On Fri, Sep 03, 2010 at 10:08:38PM +0200, Michal Varga wrote: > On Fri, 2010-09-03 at 14:03 -0500, Jim Bryant wrote: > > i just noticed this too... had a build going of qt-creator, and then > > started a /usr/src make clean, and had to abort the qt-creator build to > > get the make clean to finish. it was taking forever to even paint the > > xterm in the make clean window. > > ... > > On the other hand, at least from some of my observations, the terrible > desktop performance isn't strictly CPU-bound, I/O definitely has some > say in this. You can (you should, mileage may vary) see this by trying > to extract a few-GB archive in the background. While clearly no more > than a single CPU is ever occupied by that process (and there's few > other happily idling), you can spend waiting up to a few minutes just to > get a new application launched (or even just a running one getting > redrawn, in case part of it was swapped out at the moment). Could this be caused by lack of disk I/O scheduler on FreeBSD, at least with regards to launching a new application? Can you try making use of gsched(8) and see if things improve in this regard? Just be aware of this problem[1] when using it. (I've been working on a proper fix -- not a hack -- for the problem for about a week now. Stress level is very high given the ambiguous nature of many aspects of GEOM and libgeom lacking in numerous areas. So far I've managed to figure out how to parse the results from geom_gettree() in attempt to replace kern.geom.conftxt...) [1]: http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016883.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 20:57:24 2010 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 AD39910656E7 for ; Fri, 3 Sep 2010 20:57:24 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5828B8FC14 for ; Fri, 3 Sep 2010 20:57:24 +0000 (UTC) Received: by ywt2 with SMTP id 2so1138009ywt.13 for ; Fri, 03 Sep 2010 13:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jkytgRehWTy0Lj6aGrKsSOQMmhwne8iczGw/YLkue3g=; b=Fuz5fN4rYKSwzyWSObaXKsNIG7q3XNRwkw/CfwY61uDr3in5bgCQ7EPt57gNgRzHVg wVpIyVUV0Vo4vvY6kKuxWdhvN2G+oFZgEyoM7auEgilHm9++0+0QRs6btkqn1Bh57/yw aCZWE4Ny3FfXo9CSaJBLkePMfs5fk1M7O0FO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rtbrLykl/bZbJhAoZ+XzxI/rn68tzZCA2oDz+P1MR5ajqGkmM4OBsMs2C7qyo4LiXL z+e4uOfAvQzA8m0e5p+AmDywYc8WQCio9apqYM6Uv6VEb7CPqISwAQLEsyFIx1sZ05hv uM6aR8SRp1rTPxxBDhsCEi2iQ6XvplladCtXU= Received: by 10.101.59.14 with SMTP id m14mr449930ank.127.1283547443516; Fri, 03 Sep 2010 13:57:23 -0700 (PDT) Received: from orb.electron-tube.net (71-217-215-181.cdrr.qwest.net [71.217.215.181]) by mx.google.com with ESMTPS id t24sm3285437ano.12.2010.09.03.13.57.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 13:57:20 -0700 (PDT) Message-ID: <4C816128.1000506@gmail.com> Date: Fri, 03 Sep 2010 15:57:12 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100731) MIME-Version: 1.0 To: Jeremy Chadwick References: <4C8153C4.70507@gmail.com> <20100903202922.GA84852@icarus.home.lan> In-Reply-To: <20100903202922.GA84852@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: what's up with cvsup? 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, 03 Sep 2010 20:57:24 -0000 my bad. it was a router firewall setting. Jeremy Chadwick wrote: > On Fri, Sep 03, 2010 at 03:00:04PM -0500, Jim Bryant wrote: > >> is it just me, or are all the cvsup servers down? >> >> i've tried this on several machines, i can ping some of them (not >> all), and the ones that can be pinged all timeout when doing a make >> update in /usr/src. >> > > It's just you. Timestamp below is in PDT (UTC-0700). > > (13:27:42 jdc@icarus) ~ $ all_csup > -------------------------------------------------------------- > >>>> Running /usr/bin/csup >>>> > -------------------------------------------------------------- > Parsing supfile "/usr/share/examples/cvsup/ports-supfile" > Connecting to cvsup10.freebsd.org > Connected to 69.147.83.48 > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing multiplexed-mode data connection > Running > Updating collection ports-all/cvs > ^CCleaning up ... > Interrupted > > If you received any sort of error or informational message from any of > the servers (such as indication that the server was unreachable and the > client would retry in 10 (?) minutes), then all of the cvsup servers you > tried were, at that moment in time, syncing from cvsup-master. > > From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 21:15:43 2010 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 33C441065707 for ; Fri, 3 Sep 2010 21:15:43 +0000 (UTC) (envelope-from benschumacher@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id D9E2E8FC13 for ; Fri, 3 Sep 2010 21:15:42 +0000 (UTC) Received: by ywt2 with SMTP id 2so1148075ywt.13 for ; Fri, 03 Sep 2010 14:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=YW0FrmH9zRIAtXSu/KwRLICwzhL1RhaybTI1ArKJlxw=; b=QwQjopnC9VWA8RlDN8/a+bpYQl1KTxZCHPoxsAyD4QajWlYsY3FxsiF5w8qyEgsNzB ZuvPB7z/TdpXpSWTg5P+ilt123e9p/cXXJMHf+3gtlTOvDJfxeEZx8/5oZ92bEIMzTNE Dmc6NmTxI7b/mI0oXByRbU3msoVkAlMMh9VAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WBldztfSGNZgRxvPqtnbP5S63Hr41SwYAc9RWAzrdtirT22Gax2rP0mseYBygGpsMV +lAq4/NMv0ulITTXzNcs51sOkddbPfCnw4Y0V0p3iu5mc3iUcWE6oMF4lT4NZ3L8dwtw Qow7jE5GgxVC2DDdrS6smTpic9NUCy7ULXuWM= MIME-Version: 1.0 Received: by 10.101.152.40 with SMTP id e40mr323176ano.198.1283546647715; Fri, 03 Sep 2010 13:44:07 -0700 (PDT) Received: by 10.100.243.20 with HTTP; Fri, 3 Sep 2010 13:44:07 -0700 (PDT) Date: Fri, 3 Sep 2010 14:44:07 -0600 Message-ID: From: Ben Schumacher To: apcupsd-users@lists.sourceforge.net, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: apcupsd, USB and FreeBSD 8.1 aren't getting along 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, 03 Sep 2010 21:15:43 -0000 All- It seems that something about the combination of FreeBSD 8.1 and apcupsd connecting to an APC Back-UPS RS 1500. Here's what I've got: 1. FreeBSD 8.1 (source compiled up to RELENG_8_1 for security fixes) 2. apcupsd 3.14.8 compiled from FreeBSD Ports 3. APC Back-UPS RS 1500 This was working fine in FreeBSD 8.0, but it appears to be broken with FreeBSD 8.1. I've done a little debugging to try to figure out what's going on and was best I can tell it's not able to communicate at all with the UPS. Here's what I've come up with so far: # usbconfig list ugen0.1: at usbus0, cfg=255 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen7.1: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON # usbconfig -d 1.2 dump_info ugen1.2: at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON # usbconfig -d 1.2 dump_device_desc ugen1.2: at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x051d idProduct = 0x0002 bcdDevice = 0x0106 iManufacturer = 0x0003 iProduct = 0x0001 iSerialNumber = 0x0002 bNumConfigurations = 0x0001 # truss -o apctest.truss apctest -d 200 2010-09-03 14:23:00 apctest 3.14.8 (16 January 2010) freebsd Checking configuration ... 0.000 apcupsd: apcconfig.c:799 After config scriptdir: "/usr/local/etc/apcupsd" 0.000 apcupsd: apcconfig.c:800 After config pwrfailpath: "/var/run" 0.000 apcupsd: apcconfig.c:801 After config nologinpath: "/var/run" 0.000 apcupsd: newups.c:102 write_lock at drivers.c:208 0.000 apcupsd: drivers.c:210 Looking for driver: usb 0.000 apcupsd: drivers.c:214 Driver apcsmart is configured. 0.000 apcupsd: drivers.c:214 Driver net is configured. 0.000 apcupsd: drivers.c:214 Driver usb is configured. 0.000 apcupsd: drivers.c:217 Driver usb found and attached. 0.000 apcupsd: newups.c:108 write_unlock at drivers.c:234 0.000 apcupsd: drivers.c:236 Driver ptr=0x8064e60 Attached to driver: usb sharenet.type = DISABLE cable.type = USB_CABLE You are using a USB cable type, so I'm entering USB test mode mode.type = USB_UPS Setting up the port ... usb_set_debug: Setting debugging level to 2 (on) 0.000 apcupsd: newups.c:102 write_lock at generic-usb.c:614 0.000 apcupsd: generic-usb.c:398 Initializing libusb 0.001 apcupsd: generic-usb.c:403 Found 0 USB busses 0.002 apcupsd: generic-usb.c:405 Found 0 USB devices 0.002 apcupsd: newups.c:108 write_unlock at generic-usb.c:633 apctest FATAL ERROR in generic-usb.c at line 636 Cannot find UPS device -- For a link to detailed USB trouble shooting information, please see . 0.002 apcupsd: newups.c:102 write_lock at generic-usb.c:656 0.002 apcupsd: newups.c:108 write_unlock at generic-usb.c:663 apctest error termination completed This is what I think the issue is: # grep '/dev' apctest.truss open("/dev/usb0",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb1",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb2",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb3",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb4",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb5",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb6",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb7",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb8",O_RDWR,00) ERR#2 'No such file or directory' open("/dev/usb9",O_RDWR,00) ERR#2 'No such file or directory' FreeBSD's USB stack no longer appears to generate the '/dev/usb#' entries. I tried symlinking the appropriate 'ugen' to 'usb0', but this didn't help either. # ln -s /dev/ugen1.2 /dev/usb0 # apctest -d 200 2010-09-03 14:29:04 apctest 3.14.8 (16 January 2010) freebsd Checking configuration ... 0.000 apcupsd: apcconfig.c:799 After config scriptdir: "/usr/local/etc/apcupsd" 0.000 apcupsd: apcconfig.c:800 After config pwrfailpath: "/var/run" 0.000 apcupsd: apcconfig.c:801 After config nologinpath: "/var/run" 0.000 apcupsd: newups.c:102 write_lock at drivers.c:208 0.000 apcupsd: drivers.c:210 Looking for driver: usb 0.000 apcupsd: drivers.c:214 Driver apcsmart is configured. 0.000 apcupsd: drivers.c:214 Driver net is configured. 0.000 apcupsd: drivers.c:214 Driver usb is configured. 0.000 apcupsd: drivers.c:217 Driver usb found and attached. 0.000 apcupsd: newups.c:108 write_unlock at drivers.c:234 0.000 apcupsd: drivers.c:236 Driver ptr=0x8064e60 Attached to driver: usb sharenet.type = DISABLE cable.type = USB_CABLE You are using a USB cable type, so I'm entering USB test mode mode.type = USB_UPS Setting up the port ... usb_set_debug: Setting debugging level to 2 (on) 0.000 apcupsd: newups.c:102 write_lock at generic-usb.c:614 0.001 apcupsd: generic-usb.c:398 Initializing libusb usb_os_find_busses: Found /dev/usb0 0.002 apcupsd: generic-usb.c:403 Found 1 USB busses 0.004 apcupsd: generic-usb.c:405 Found 0 USB devices 0.004 apcupsd: newups.c:108 write_unlock at generic-usb.c:633 apctest FATAL ERROR in generic-usb.c at line 636 Cannot find UPS device -- For a link to detailed USB trouble shooting information, please see . 0.004 apcupsd: newups.c:102 write_lock at generic-usb.c:656 0.004 apcupsd: newups.c:108 write_unlock at generic-usb.c:663 apctest error termination completed Okay. Extremely lengthy email, but if anybody can help me with this it'd be much appreicated. Cheers, Ben From owner-freebsd-stable@FreeBSD.ORG Fri Sep 3 21:22:18 2010 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 2536E10656B4 for ; Fri, 3 Sep 2010 21:22:18 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from honeysuckle.london.02.net (honeysuckle.london.02.net [87.194.255.144]) by mx1.freebsd.org (Postfix) with ESMTP id A46D08FC13 for ; Fri, 3 Sep 2010 21:22:17 +0000 (UTC) Received: from unknown (94.193.93.212) by honeysuckle.london.02.net (8.5.124.10) id 4C655360008500B3; Fri, 3 Sep 2010 22:10:43 +0100 Date: Fri, 3 Sep 2010 22:10:00 +0100 From: Bruce Cran To: Jeremy Chadwick Message-ID: <20100903221000.00001365@unknown> In-Reply-To: <20100903205010.GA85105@icarus.home.lan> References: <4C7F7C0F.8080004@icyb.net.ua> <4C7F9ACE.80705@bally-wulff.de> <4C814665.3070306@gmail.com> <1283544518.26203.33.camel@xenon> <20100903205010.GA85105@icarus.home.lan> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org, Jim Bryant , Pizzamiglio , Luca, Michal Varga Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 03 Sep 2010 21:22:18 -0000 On Fri, 3 Sep 2010 13:50:10 -0700 Jeremy Chadwick wrote: > Just be aware of this problem[1] when using it. (I've been working > on a proper fix -- not a hack -- for the problem for about a week now. > Stress level is very high given the ambiguous nature of many aspects > of GEOM and libgeom lacking in numerous areas. So far I've managed to > figure out how to parse the results from geom_gettree() in attempt to > replace kern.geom.conftxt...) I'm hoping to replace most of the geom code in sysinstall for 9.0 - it needs to parse the output of geom_gettree, use gpart to create partitions etc. So far I've got code that can parse the existing partition layout but not much more. Take a look at user/ae/usr.sbin/sade in svn to see how to interact with geom - ae@ has been working on adding support for gpt, zfs etc. to sade. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 00:14:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8438210656A4; Sat, 4 Sep 2010 00:14:35 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4C818F65.3000603@freebsd.org> Date: Sat, 04 Sep 2010 08:14:29 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: jan.grant@bristol.ac.uk References: <4C7F7C0F.8080004@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Andriy Gapon , Ivan Voras Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. 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, 04 Sep 2010 00:14:36 -0000 jan.grant@bristol.ac.uk wrote: > On Thu, 2 Sep 2010, Andriy Gapon wrote: > > >> on 02/09/2010 12:08 jan.grant@bristol.ac.uk said the following: >> >>> On Wed, 1 Sep 2010, Ivan Voras wrote: >>> >>> >>>> On 09/01/10 15:08, jan.grant@bristol.ac.uk wrote: >>>> >>>>> I'm running -STABLE with a kde-derived desktop. This setup (which is >>>>> pretty standard) is providing abysmal interactive performance on an >>>>> eight-core machine whenever I try to do anything CPU-intensive (such as >>>>> building a port). >>>>> >>>>> Basically, trying to build anything from ports rapidly renders everything >>>>> else so "non-interactive" in the eyes of the scheduler that, for instance, >>>>> switching between virtual desktops (I have six of them in reasonably >>>>> frequent use) takes about a minute of painful waiting on redraws to >>>>> complete. >>>>> >>>> Are you sure this is about the scheduler or maybe bad X11 drivers? >>>> >>> Not 100%, but mostly convinced; I've just started looking at this. It's my >>> first stab at what might be going on. X11 performance is usually pretty >>> snappy. There's no paging pressure at all. >>> >> From my experience: >> 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with >> interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). >> 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - >> enabling OpenGL desktop effects in KDE4 leads to the consequences like what you >> describe. With all GUI bells and whistles disabled the system behaves quite >> like the AMD system. >> > > All desktop effects are disabled. The graphics are from an nVidia GeForce > 8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour > that's affected, though: the box runs a number of small headless > [interactive] server processes which also appear to get rapidly starved of > CPU time.) > > The behaviour isn't visible with the 4bsd scheduler; "stuff" generally > remains snappy and responsive. > > I'll keep poking around and see if I can get to the bottom of it. > > > > I think sysctl kern.sched.preempt_thresh is too low, default is only 64. I always tune it up to 200 on my desktop machine which is running gnome and other GUI applications, for a heavy GUI deskkop, I would tune it up to 224 to get better result. Regards, David Xu From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 02:31:15 2010 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 DD38B10656D0 for ; Sat, 4 Sep 2010 02:31:15 +0000 (UTC) (envelope-from rick@rix.kiwi-computer.com) Received: from rix.kiwi-computer.com (66-191-70-202.static.stcd.mn.charter.com [66.191.70.202]) by mx1.freebsd.org (Postfix) with SMTP id 726D18FC14 for ; Sat, 4 Sep 2010 02:31:15 +0000 (UTC) Received: (qmail 47884 invoked by uid 2000); 4 Sep 2010 02:31:14 -0000 Date: Fri, 3 Sep 2010 21:31:14 -0500 From: "Rick C. Petty" To: Rick Macklem Message-ID: <20100904023114.GA47730@rix.kiwi-computer.com> References: <20100830172259.GA20421@rix.kiwi-computer.com> <378785023.301734.1283219978549.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <378785023.301734.1283219978549.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 02:31:15 -0000 On Mon, Aug 30, 2010 at 09:59:38PM -0400, Rick Macklem wrote: > > I don't tune anything with sysctl, I just use what I get from an > install from CD onto i386 hardware. (I don't even bother to increase > kern.ipc.maxsockbuf although I suggest that in the mount message.) Sure. But maybe you don't have server mount points with 34k+ files in them? I notice when I increase maxsockbuf, the problem of "disappearing files" goes away, mostly. Often a "find /mnt" fixes the problem temporarily, until I unmount and mount again. > The only thing I can suggest is trying: > # mount -t newnfs -o nfsv3 :/path /mnt > and seeing if that performs like the regukar NFSv3 or has > the perf. issue you see for NFSv4? Yes, that has the same exact problem. However, if I use: mount -t nfs :/path /mnt The problem does indeed go away! But it means I have to mount all the subdirectories independently, which I'm trying to avoid and is the reason I went to NFSv4. > If this does have the perf. issue, then the exp. client > is most likely the cause and may get better in a few months > when I bring it up-to-date. Then that settles it-- the newnfs client seems to be the problem. Just to recap... These two are *terribly* slow (e.g. a VBR mp3 avg 192kbps cannot be played without skips): mount -t newnfs -o nfsv4 server:/path /mnt mount -t newnfs -o nfsv3 server:/path /mnt But this one works just fine (H.264 1080p video does not skip): mount -t nfs server:/path /mnt I guess I will have to wait for you to bring the v4 client up to date. Thanks again for all of your contributions and for porting NFSv4 to FreeBSD! -- Rick C. Petty From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 02:35:51 2010 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 C9D8610656A7 for ; Sat, 4 Sep 2010 02:35:51 +0000 (UTC) (envelope-from rick@rix.kiwi-computer.com) Received: from rix.kiwi-computer.com (66-191-70-202.static.stcd.mn.charter.com [66.191.70.202]) by mx1.freebsd.org (Postfix) with SMTP id 605508FC08 for ; Sat, 4 Sep 2010 02:35:51 +0000 (UTC) Received: (qmail 47979 invoked by uid 2000); 4 Sep 2010 02:35:50 -0000 Date: Fri, 3 Sep 2010 21:35:50 -0500 From: "Rick C. Petty" To: Rick Macklem Message-ID: <20100904023550.GB47730@rix.kiwi-computer.com> References: <201009011339.15898.h2+freebsd@fsfe.org> <2070918035.372723.1283355990476.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2070918035.372723.1283355990476.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: Hannes Hauswedell , freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 02:35:51 -0000 On Wed, Sep 01, 2010 at 11:46:30AM -0400, Rick Macklem wrote: > > > > I am experiencing similar issues with newnfs: > > > > 1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s > > reading > > from the NFS4-share on Gbit-Lan > > > > 2) Mounting with -t newnfs -o nfsv3 results in no performance gain > > whatsoever. > > > > 3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar > > performance) ??? not a hardware/driver issue from my pov > > Ok, so it does sound like an issue in the experimental client and > not NFSv4. For the most part, the read code is the same as > the regular client, but it hasn't been brought up-to-date > with recent changes. Do you (or will you soon) have some patches I/we could test? I'm willing to try anything to avoid mounting ten or so subdirectories in each of my mount points. > One thing you could try is building a kernel without SMP enabled > and see if that helps? (I only have single core hardware, so I won't > see any SMP races.) If that helps, I can compare the regular vs > experimental client for smp locking in the read stuff. I can try disabling SMP too. Should that really matter, if you're not even pegging one CPU? The locks shouldn't have *that* much overhead... -- Rick C. Petty From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 06:00:51 2010 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 D82B6106564A for ; Sat, 4 Sep 2010 06:00:51 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id B4DB88FC0C for ; Sat, 4 Sep 2010 06:00:51 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o8460nje030028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Sep 2010 23:00:50 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o8460neH030026; Fri, 3 Sep 2010 23:00:49 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA19465; Fri, 3 Sep 10 22:58:28 PDT Date: Fri, 03 Sep 2010 22:58:23 -0700 From: perryh@pluto.rain.com To: michal@sharescope.co.uk Message-Id: <4c81dfff.4oQY3NAFRXeryd1n%perryh@pluto.rain.com> References: <4C7FA50D.4000409@sharescope.co.uk> <4C80B116.1040800@sharescope.co.uk> In-Reply-To: <4C80B116.1040800@sharescope.co.uk> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Extending your zfs pool with multiple devices 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, 04 Sep 2010 06:00:51 -0000 Michal wrote: > What is really odd is I see your replies but not my original post, > how very strange?? One of your subscription options is whether you get your own posts back. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 11:37:49 2010 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 3395810656E9 for ; Sat, 4 Sep 2010 11:37:49 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 935A28FC18 for ; Sat, 4 Sep 2010 11:37:48 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o84BbeGw071815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 4 Sep 2010 07:37:41 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o84BbeYR030751; Sat, 4 Sep 2010 07:37:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201009041137.o84BbeYR030751@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Sep 2010 07:37:40 -0400 To: Ben Schumacher , apcupsd-users@lists.sourceforge.net, freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: Re: apcupsd, USB and FreeBSD 8.1 aren't getting along 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, 04 Sep 2010 11:37:49 -0000 At 04:44 PM 9/3/2010, Ben Schumacher wrote: >All- > >It seems that something about the combination of FreeBSD 8.1 and >apcupsd connecting to an APC Back-UPS RS 1500. > >Here's what I've got: >1. FreeBSD 8.1 (source compiled up to RELENG_8_1 for security fixes) >2. apcupsd 3.14.8 compiled from FreeBSD Ports >3. APC Back-UPS RS 1500 Hi, I am running RELENG_8 with such a ups. 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed Sep 1 11:42:00 EDT 2010 % apcaccess APC : 001,038,0989 DATE : 2010-09-04 07:32:09 -0400 HOSTNAME : backup3.sentex.ca VERSION : 3.14.8 (16 January 2010) freebsd UPSNAME : RAPIDS CABLE : USB Cable MODEL : Back-UPS RS 1500 UPSMODE : Stand Alone STARTTIME: 2010-09-01 12:05:12 -0400 STATUS : ONLINE LINEV : 117.0 Volts LOADPCT : 38.0 Percent Load Capacity BCHARGE : 100.0 Percent TIMELEFT : 83.5 Minutes MBATTCHG : 10 Percent MINTIMEL : -1 Minutes MAXTIME : 0 Seconds SENSE : Medium LOTRANS : 097.0 Volts HITRANS : 132.0 Volts ALARMDEL : 30 seconds BATTV : 26.9 Volts LASTXFER : Low line voltage NUMXFERS : 1 XONBATT : 2010-09-01 16:27:30 -0400 TONBATT : 0 seconds CUMONBATT: 26 seconds XOFFBATT : 2010-09-01 16:27:56 -0400 SELFTEST : NO STATFLAG : 0x07000008 Status Flag MANDATE : 2007-09-07 SERIALNO : 8B0736R21784 BATTDATE : 2007-09-07 NOMINV : 120 Volts NOMBATTV : 24.0 Volts NOMPOWER : 865 Watts FIRMWARE : 8.g9a.D USB FW:g9a APCMODEL : Back-UPS RS 1500 END APC : 2010-09-04 07:32:37 -0400 I just leave the DEVICE line blank UPSNAME STATN UPSCABLE usb UPSTYPE usb DEVICE LOCKFILE /var/spool/lock ONBATTERYDELAY 7 BATTERYLEVEL 10 MINUTES -1 TIMEOUT 0 ANNOY 10 ANNOYDELAY 10 NOLOGON disable KILLDELAY 2 NETSERVER on NISIP 127.0.0.1 NISPORT 3551 EVENTSFILE /var/log/apcupsd.events EVENTSFILEMAX 100 UPSCLASS standalone UPSMODE disable STATTIME 600 STATFILE /var/log/apcupsd.status LOGSTATS off DATATIME 600 FACILITY local2 UPSNAME RAPIDS SENSITIVITY H WAKEUP 010 SLEEP 000 RETURNCHARGE 00 BEEPSTATE T SELFTEST 336 You dont need to do any symlinks in /dev # usbconfig -d 5.2 dump_device_desc ugen5.2: at usbus5, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x051d idProduct = 0x0002 bcdDevice = 0x0106 iManufacturer = 0x0003 iProduct = 0x0001 iSerialNumber = 0x0002 <8B0736R21784 > bNumConfigurations = 0x0001 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 16:24:40 2010 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 DCBE010656D1 for ; Sat, 4 Sep 2010 16:24:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 973FB8FC0C for ; Sat, 4 Sep 2010 16:24:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAPYPgkyDaFvO/2dsb2JhbACDF5BdjhmpRZEihEl0BIoX X-IronPort-AV: E=Sophos;i="4.56,318,1280721600"; d="scan'208";a="92829093" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 04 Sep 2010 12:24:38 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E37DBB3F29; Sat, 4 Sep 2010 12:24:38 -0400 (EDT) Date: Sat, 4 Sep 2010 12:24:38 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <987774370.493418.1283617478821.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100904023550.GB47730@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_493417_877221575.1283617478819" X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: Hannes Hauswedell , freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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, 04 Sep 2010 16:24:40 -0000 ------=_Part_493417_877221575.1283617478819 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > > Do you (or will you soon) have some patches I/we could test? I'm > willing to try anything to avoid mounting ten or so subdirectories in > each of my mount points. > Attached is a small patch for the only difference I can spot in the read code between the regular and experimental NFS client. I have asked jhb@ to try and do some testing, to see if he can reproduce it. If he does reproduce it, maybe he can figure out what is going on. (I don't think I'll have any further patches to try, unless he spots something.) > > One thing you could try is building a kernel without SMP enabled > > and see if that helps? (I only have single core hardware, so I won't > > see any SMP races.) If that helps, I can compare the regular vs > > experimental client for smp locking in the read stuff. > > I can try disabling SMP too. Should that really matter, if you're not > even pegging one CPU? The locks shouldn't have *that* much overhead... > > -- Rick C. Petty > If running UMP fixes the problem, it is most likely a missing lock that allows a race to put things in a weird state. But for these things, it is often something I'd never expect that turns out to be the culprit. rick ------=_Part_493417_877221575.1283617478819 Content-Type: text/x-patch; name=nfsclbio.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nfsclbio.patch LS0tIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYy5zYXYJMjAxMC0wOS0wNCAxMDo0NjowNi4wMDAw MDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2xiaW8uYwkyMDEwLTA5LTA0IDEwOjQ3 OjA2LjAwMDAwMDAwMCAtMDQwMApAQCAtNTEwLDEwICs1MTAsNyBAQAogCQkJICAgIHJhYnAgPSBu ZnNfZ2V0Y2FjaGVibGsodnAsIHJhYm4sIGJpb3NpemUsIHRkKTsKIAkJCSAgICBpZiAoIXJhYnAp IHsKIAkJCQllcnJvciA9IG5ld25mc19zaWdpbnRyKG5tcCwgdGQpOwotCQkJCWlmIChlcnJvcikK LQkJCQkgICAgcmV0dXJuIChlcnJvcik7Ci0JCQkJZWxzZQotCQkJCSAgICBicmVhazsKKwkJCQly ZXR1cm4gKGVycm9yID8gZXJyb3IgOiBFSU5UUik7CiAJCQkgICAgfQogCQkJICAgIGlmICgocmFi cC0+Yl9mbGFncyAmIChCX0NBQ0hFfEJfREVMV1JJKSkgPT0gMCkgewogCQkJCXJhYnAtPmJfZmxh Z3MgfD0gQl9BU1lOQzsK ------=_Part_493417_877221575.1283617478819-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 4 16:55:36 2010 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 11A5D10656CD for ; Sat, 4 Sep 2010 16:55:36 +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 C1CFE8FC13 for ; Sat, 4 Sep 2010 16:55:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAF0XgkyDaFvO/2dsb2JhbACDGJBdjhmpPZEkgSKDJ3QEihc X-IronPort-AV: E=Sophos;i="4.56,318,1280721600"; d="scan'208";a="90785912" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 Sep 2010 12:55:28 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 867FAB3F2A; Sat, 4 Sep 2010 12:55:28 -0400 (EDT) Date: Sat, 4 Sep 2010 12:55:28 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <1144621878.493708.1283619328514.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100904023550.GB47730@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: Hannes Hauswedell , freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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, 04 Sep 2010 16:55:36 -0000 ----- Original Message ----- > On Wed, Sep 01, 2010 at 11:46:30AM -0400, Rick Macklem wrote: > > > > > > I am experiencing similar issues with newnfs: > > > > > > 1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s > > > reading > > > from the NFS4-share on Gbit-Lan > > > > > > 2) Mounting with -t newnfs -o nfsv3 results in no performance gain > > > whatsoever. > > > > > > 3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar > > > performance) ??? not a hardware/driver issue from my pov > > > > Ok, so it does sound like an issue in the experimental client and > > not NFSv4. For the most part, the read code is the same as > > the regular client, but it hasn't been brought up-to-date > > with recent changes. > > Do you (or will you soon) have some patches I/we could test? I'm > willing to try anything to avoid mounting ten or so subdirectories in > each of my mount points. > One other thing you could do is run this in a loop while you have a slow read running. The client threads must be blocked somewhere a lot if the read rate is so slow. (Then take a look at "xxx" and please email it to me too.) ps axHl >> xxx sleep 1 rick