From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 02:43:55 2007 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 5A36D16A418; Sun, 16 Dec 2007 02:43:55 +0000 (UTC) (envelope-from efinleywork@efinley.com) Received: from postmaster.etv.net (postmaster.etv.net [66.111.113.15]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCDF13C457; Sun, 16 Dec 2007 02:43:55 +0000 (UTC) (envelope-from efinleywork@efinley.com) Received: from efinley04.etv.net ([74.214.237.51] helo=science3.efinley.com) by postmaster.etv.net with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J3jTu-0003v4-Vj; Sat, 15 Dec 2007 19:43:55 -0700 From: Elliot Finley To: Jeremy Chadwick Date: Sat, 15 Dec 2007 19:43:55 -0700 Organization: Emery Telcom Message-ID: <8249m3pqc4qn9g2dt2got69m40hl77aslv@4ax.com> References: <20071215235810.GA81924@eos.sc1.parodius.com> In-Reply-To: <20071215235810.GA81924@eos.sc1.parodius.com> X-Mailer: Forte Agent 4.1/32.1088 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, User Questions Subject: Re: OS bug in taskq X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: efinleywork@efinley.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2007 02:43:55 -0000 On Sat, 15 Dec 2007 15:58:10 -0800, you wrote: >On Sat, Dec 15, 2007 at 01:03:14PM -0700, Elliot Finley wrote: >> I have: >> dumpdev=3D"AUTO" >> in /etc/rc.conf and: >> ...=20 >> in the kernel and I'm still unable to obtain a crash dump. Hopefully >> there is enough info in this email for a hacker to point me in the >> right direction to debug this. > >I can't help with the panic itself, but the reason for the inability to >obtain a crash dump is mentioned in a thread I started in November: > >http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038069.h= tml > >The explanation of the problem was documented best by Doug Barton in >this thread (over at freebsd-rc@): > >http://lists.freebsd.org/pipermail/freebsd-rc/2007-November/001263.html In this thread it states: Short term fix is to disable swapping on the system long enough to get the dump, then reboot with swapping turned back on. how do I turn swapping off? I don't think I can just not mount it, because then it wouldn't exist for the dump. > >Open PR: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=3D118255 From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 11:05:09 2007 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 D54BF16A41B for ; Sun, 16 Dec 2007 11:05:09 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [75.160.109.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE4613C447 for ; Sun, 16 Dec 2007 11:05:08 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id lBGB5069048794 for ; Sun, 16 Dec 2007 03:05:06 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id lBGB50V9048765 for freebsd-stable@freebsd.org; Sun, 16 Dec 2007 03:05:00 -0800 (PST) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [75.160.109.235]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Sun, 16 Dec 2007 03:04:59 -0800 Message-ID: <20071216030459.pp8cn3yagckksgko@webmail.1command.com> X-Priority: 3 (Normal) Date: Sun, 16 Dec 2007 03:04:59 -0800 From: "Chris H." To: freebsd-stable@freebsd.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Re: Server motherboard recommendation wanted 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, 16 Dec 2007 11:05:09 -0000 Quoting Pete French : >> We have great success using the Tyan Thunder K8SD-Pro (S2882-D) >> motherboard. It is a dual socket 940 motherboard that supports AMD >> Opteron 200-series CPU (including dual-core), 16 GB ECC DDR400 RAM, with >> 2 64-bit/133 MHz PCI-X slots, 2 64-bit/100 MHz PCI-X slots, and 1 >> 32-bit/33 MHz PCI slot. Comes with onboard SATA and (optional) SCSI >> controllers. > > I can second this - I bought one after a recopmmendation on this > list for a dual core Opteron board to replace a rather flaky MSI. > It has performed magnificently, and is comletel stable, plus being > well supported by FreBSD 9amd64 in my case). I run Adaptec SCSI > controllers, and the onboard NIC's are good quality as well. > definitely recommended. > > -pcf. I would also have to concur with this, and the previous post. We're running 3 Intel based Tyan dual CPU boards and they run/perform very well. Have dual onboard NIC's, 1 64bit PCI slot and 1 PCI-X slot, onboard video, 2 U-160 SCSI ports, 2 133 UATA IDE ports. The only possible "gotcha" with Tyan boards is they are very picky about RAM. So best bet is to use what Tyan approves of. or you may run into trouble. Other than that, I would have a real hard time finding anything but good to say about their boards. In short; FreeBSD (the OS) loves these boards. > _______________________________________________ > 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" > -- panic: kernel trap (ignored) From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 11:39:06 2007 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 5906816A468 for ; Sun, 16 Dec 2007 11:39:06 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id E3B5513C45A for ; Sun, 16 Dec 2007 11:39:05 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 2687 invoked from network); 16 Dec 2007 05:39:05 -0600 Received: from 124-170-40-102.dyn.iinet.net.au (HELO localhost) (124.170.40.102) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Dec 2007 05:39:04 -0600 Date: Sun, 16 Dec 2007 22:38:30 +1100 From: Norberto Meijome To: FreeBSD Stable ML Message-ID: <20071216223830.72e99802@meijome.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Right way to use geli + gjournal ? 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, 16 Dec 2007 11:39:06 -0000 Hi everyone, In my laptop, I am running 7.0 Beta-4 (today's kernel + world). my /usr (ad0s1f ) is using gjournal, with its journal on ad0s1h . I have it mounted with what I believe are the recommended settings: $ mount [...] /dev/ad0s1f.journal on /usr (ufs, asynchronous, local, noatime, gjournal) [...] I also have some file-backed geli disks which reside in /usr/home/betom. They are still using soft-updates (from before I had gjournal on /usr): /dev/md11.eli on /usr/home/betom/_11 (ufs, local, noatime, soft-updates) /dev/md13.eli on /usr/home/betom/_13 (ufs, local, noatime, soft-updates) /dev/md12.eli on /usr/home/betom/_12 (ufs, local, noatime, soft-updates) Does it make sense to set these GELI disks to async / no-soft-updates as well? thanks! Beto _________________________ {Beto|Norberto|Numard} Meijome There are no stupid questions, but there are a LOT of inquisitive idiots. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 16:09:10 2007 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 B67A616A419 for ; Sun, 16 Dec 2007 16:09:10 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6987D13C457 for ; Sun, 16 Dec 2007 16:09:10 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J3w3B-0006NV-E2 for freebsd-stable@FreeBSD.ORG; Sun, 16 Dec 2007 16:09:09 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J3w3B-0008sQ-C3 for freebsd-stable@FreeBSD.ORG; Sun, 16 Dec 2007 16:09:09 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J3w3B-000Iuy-Aw for freebsd-stable@FreeBSD.ORG; Sun, 16 Dec 2007 16:09:09 +0000 To: freebsd-stable@FreeBSD.ORG Message-Id: From: Pete French Date: Sun, 16 Dec 2007 16:09:09 +0000 Cc: Subject: Is it safe to use CPUTYPE?=native on 7.0 ? 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, 16 Dec 2007 16:09:10 -0000 fairly simple question really - on machines where I never use the compiled binaries anywhere else, is it O.K. to set the CPU type to 'native' in make.conf ? According to gcc this should detect the processor type and set the various flas as approrpiate, which is nice, as we have a mix of P3, P4 and AMD processors around the place, and having one make.conf which will do the right thing on all of them would be nice. I've been trying it out on a couple of machines, and it seems to work fine, but I have a feeling that various bits of the kerenel complie are sensetive to the cpu type, so am just asking to check if it's O.K. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 16:39:16 2007 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 8453116A419; Sun, 16 Dec 2007 16:39:16 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE4413C442; Sun, 16 Dec 2007 16:39:16 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <476554AF.4000701@intersonic.se> Date: Sun, 16 Dec 2007 17:39:11 +0100 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 2.0.0.6 (X11/20071103) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: -net or kernel: where does this belong? 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, 16 Dec 2007 16:39:16 -0000 Posted on -questions but got no response, trying -current and -stable as well. Sorry for the cross-post but I'm getting kind of desperate... Hi all, Since quite a while I have had problems with {CURRENT|RELENG_7} SMP machines that lock up when accessed from a remote location over a vpn (ipsec) link and sees a ICMP_REDIRECT. A message, "kernel: rtfree: has 1 refs, will be present in logs. Stefan Lambrev opened a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=117913 that I thought dealt with this but not sure if this maybe just touches the messages, not lockups. Later, I opened another PR http://www.freebsd.org/cgi/query-pr.cgi?pr=118044 and so far there is absolute silence. See below for the (what I believe) interesting part. Question 1: Am I the only one on the planet that sees this problem? Question 2: Could someone with some knowledge please tell if this is a real bug or just something I cooked up myself? Thanks a lot! --per Tracing command irq21: bge0 pid 33 tid 100025 td 0xc5119880 cpustop_handler(1,e3ccf958,c0a05b10,1,0,...) at cpustop_handler+0x32 ipi_nmi_handler(1,0,0,0,13,...) at ipi_nmi_handler+0x2f trap(e3ccf964) at trap+0x30 calltrap() at calltrap+0x6 --- trap 0x13, eip = 0xc074e586, esp = 0xe3ccf9a4, ebp = 0xe3ccf9c8 --- panic(c0a9b762,c5117660,c0aa0a06,c5117660,186ae,...) at panic+0x26 _mtx_lock_spin_failed(1,19,c0aa0a32,cb,19,...) at _mtx_lock_spin_failed+0x51 _thread_lock_flags(c57c6440,10,c0aa0a32,cb,1,...) at _thread_lock_flags+0xc7 propagate_priority(c0bbceec,0,c0aa0a32,2e2,c50f2a00,...) at propagate_priority+0xe0 turnstile_wait(c50f2a00,c57c6440,0,17a,c5874678,...) at turnstile_wait+0x48c _mtx_lock_sleep(c5874678,c5119880,0,c0aaa355,41c,...) at _mtx_lock_sleep+0x15a _mtx_lock_flags(c5874678,0,c0aaa355,41c,e3ccfaf4,...) at _mtx_lock_flags+0xef rt_setgate(c5874618,cb4ee2c0,e3ccfbac,c5119880,e3ccfb18,...) at rt_setgate+0x196 rtredirect(e3ccfbbc,e3ccfbac,0,26,e3ccfb9c,...) at rtredirect+0x18e icmp_input(c6fb6500,14,246,c0b9c7c0,e3ccfc0c,...) at icmp_input+0x50f ip_input(c6fb6500,14e,800,c526a400,800,...) at ip_input+0x650 netisr_dispatch(2,c6fb6500,10,3,0,...) at netisr_dispatch+0x73 ether_demux(c526a400,c6fb6500,3,0,3,...) at ether_demux+0x1f1 ether_input(c526a400,c6fb6500,c0a6af05,bc4,c526a400,...) at ether_input+0x37f bge_intr(c526d000,0,c0a99497,471,c515e564,...) at bge_intr+0x7da ithread_loop(c5271160,e3ccfd38,c0a9920b,2ea,c52512a8,...) at ithread_loop+0x1b5 fork_exit(c0732ea0,c5271160,e3ccfd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3ccfd70, ebp = 0 --- From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 16:47:58 2007 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 170F316A419 for ; Sun, 16 Dec 2007 16:47:58 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 90BD113C474 for ; Sun, 16 Dec 2007 16:47:57 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so217905fgg.35 for ; Sun, 16 Dec 2007 08:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=qOjW4nyjl7kYuCr/Sii3099xh+Hp3pS97W+vj53VUUg=; b=CSjx1iLGCU9oi2+73mxbi6RZ3WYifB+lhsoHSOsxOCiDefjU3CeUXgh2aQHSo4eVllqK6I67Xvc0cMiRdN0ARzyUZ1DYue3aZ9JYNEjsH9FXAPslOhUljuEp1WP9zgP+KT6z8mDLqFGfVzjlDH7W/cIhymu9FgAsubz0qqIT8Kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KhtNBcY0xpJ1A2sgHVZSG0lflRn8BG2xUkzvOg7H+13MR1jX+oPZBa8Xc5i4W3HsQoXtYGvVkB5zJNyNQsMu0LyKzFlbivmAzKgCYAuCZMris6okSmQKPrm51IvoyAqmumoGF04XgJxGz8rSGaoworeAhabDb//PKSHZncQ+cgI= Received: by 10.86.1.1 with SMTP id 1mr5479091fga.2.1197823676307; Sun, 16 Dec 2007 08:47:56 -0800 (PST) Received: by 10.86.3.20 with HTTP; Sun, 16 Dec 2007 08:47:56 -0800 (PST) Message-ID: <790a9fff0712160847m4c25cf31t756f0a7988e2e1f8@mail.gmail.com> Date: Sun, 16 Dec 2007 10:47:56 -0600 From: "Scot Hetzel" To: "Pete French" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3857_17702457.1197823676294" References: Cc: freebsd-stable@freebsd.org Subject: Re: Is it safe to use CPUTYPE?=native on 7.0 ? 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, 16 Dec 2007 16:47:58 -0000 ------=_Part_3857_17702457.1197823676294 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/16/07, Pete French wrote: > fairly simple question really - on machines where I never use the compiled > binaries anywhere else, is it O.K. to set the CPU type to 'native' in > make.conf ? According to gcc this should detect the processor type and > set the various flas as approrpiate, which is nice, as we have a mix of P3, > P4 and AMD processors around the place, and having one make.conf which will > do the right thing on all of them would be nice. > > I've been trying it out on a couple of machines, and it seems to work fine, > but I have a feeling that various bits of the kerenel complie are > sensetive to the cpu type, so am just asking to check if it's O.K. > While setting CPUTYPE=native in /etc/make.conf may work, it fails to set MACHINE_CPU to the correct values for your processor type. The problem is that bsd.cpu.mk doesn't know how to handle CPU type 'native'. There is a simple fix for this problem by applying the attached patch which uses: gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//' to reset CPUTYPE to the processor type of your system when CPUTYPE=native. Scot ------=_Part_3857_17702457.1197823676294 Content-Type: text/x-diff; name=bsd.cpu.mk.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fa9t80qp Content-Disposition: attachment; filename=bsd.cpu.mk.patch SW5kZXg6IGJzZC5jcHUubWsKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc2hh cmUvbWsvYnNkLmNwdS5tayx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS42MwpkaWZmIC11IC1yMS42 MyBic2QuY3B1Lm1rCi0tLSBic2QuY3B1Lm1rCTE2IE9jdCAyMDA3IDE4OjMyOjM3IC0wMDAwCTEu NjMKKysrIGJzZC5jcHUubWsJMTcgT2N0IDIwMDcgMjI6Mjg6MzIgLTAwMDAKQEAgLTE4LDYgKzE4 LDE0IEBACiAuIGVuZGlmCiAuZWxzZQogCisjIEhhbmRsZSAnbmF0aXZlJyBieSBjb252ZXJ0aW5n IGl0IHRvIHRoZSBhcHByb3ByaWF0ZSBDUFVUWVBFCisKKy5pZiAke01BQ0hJTkVfQVJDSH0gPT0g ImkzODYiIHx8ICR7TUFDSElORV9BUkNIfSA9PSAiYW1kNjQiCisuIGlmICR7Q1BVVFlQRX0gPT0g Im5hdGl2ZSIKK0NQVVRZUEUgIT0gZ2NjIC12IC14IGMgLUUgLW10dW5lPW5hdGl2ZSAvZGV2L251 bGwgLW8gL2Rldi9udWxsIDI+JjEgfCBncmVwIG10dW5lIHwgc2VkIC1lICdzLy4qbXR1bmU9Ly8n CisuIGVuZGlmCisuZW5kaWYKKwogIyBIYW5kbGUgYWxpYXNlcyAobm90IGRvY3VtZW50ZWQgaW4g bWFrZS5jb25mIHRvIGF2b2lkIHVzZXIgY29uZnVzaW9uCiAjIGJldHdlZW4gZS5nLiBpNTg2IGFu ZCBwZW50aXVtKQogCg== ------=_Part_3857_17702457.1197823676294-- From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 17:45:12 2007 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 4C3E516A41B for ; Sun, 16 Dec 2007 17:45:12 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0399813C4D3 for ; Sun, 16 Dec 2007 17:45:12 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J3xY7-000706-BV; Sun, 16 Dec 2007 17:45:11 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J3xY7-0009RA-9R; Sun, 16 Dec 2007 17:45:11 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J3xY7-00011v-9H; Sun, 16 Dec 2007 17:45:11 +0000 To: swhetzel@gmail.com In-Reply-To: <790a9fff0712160847m4c25cf31t756f0a7988e2e1f8@mail.gmail.com> Message-Id: From: Pete French Date: Sun, 16 Dec 2007 17:45:11 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: Is it safe to use CPUTYPE?=native on 7.0 ? 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, 16 Dec 2007 17:45:12 -0000 > While setting CPUTYPE=native in /etc/make.conf may work, it fails to > set MACHINE_CPU to the correct values for your processor type. > > The problem is that bsd.cpu.mk doesn't know how to handle CPU type 'native'. Ah, O.K. - thats the kind of thing I was worried about... > There is a simple fix for this problem by applying the attached patch > which uses: Great, thanks. Out of curiosity, how come this patch isn't in 7.0 ? -pete. From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 18:01:31 2007 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 3BD2316A418 for ; Sun, 16 Dec 2007 18:01:31 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id B63CC13C455 for ; Sun, 16 Dec 2007 18:01:30 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so224358fgg.35 for ; Sun, 16 Dec 2007 10:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nigJsW4RSxvHOWJVogXa7QEvmHsJczxuULvLMv1PIZk=; b=wpH4N9qAOpaiDQEqo32JZOoz3r2M8svGdVoWahIzRjhqQNrBrOk70Ep43AuF1sWT7cfcCf1/UDdOE3DaXluETHX8ormKikVDn8qtLXT+5QaZiGwjyb/Zp/Lkr9iA8jaW6QM7JEMB2VqR0YYeYOoEnyncQxkmUn2zvrvGwghkcTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=u+NNdL4FpWKehDzsL9v695SY6kB0AW7bNAgCAHIhu6zEHY1NQgAmqVkw/DDhhEISQD9pQhSAyxCMeMrYPamvYYM7ig7dTiLef/EBOJX8VY4VlAnJdPBxYnuBWK2fUPAW6kwAe4XAzcBN8iVeZFpW+smxvyRazqxCC042/L9LMLc= Received: by 10.86.4.2 with SMTP id 2mr5511185fgd.41.1197828089448; Sun, 16 Dec 2007 10:01:29 -0800 (PST) Received: by 10.86.3.20 with HTTP; Sun, 16 Dec 2007 10:01:29 -0800 (PST) Message-ID: <790a9fff0712161001m3f152373jc7e03e0dd9b8e914@mail.gmail.com> Date: Sun, 16 Dec 2007 12:01:29 -0600 From: "Scot Hetzel" To: "Pete French" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0712160847m4c25cf31t756f0a7988e2e1f8@mail.gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: Is it safe to use CPUTYPE?=native on 7.0 ? 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, 16 Dec 2007 18:01:31 -0000 On 12/16/07, Pete French wrote: > > While setting CPUTYPE=native in /etc/make.conf may work, it fails to > > set MACHINE_CPU to the correct values for your processor type. > > > > The problem is that bsd.cpu.mk doesn't know how to handle CPU type 'native'. > > Ah, O.K. - thats the kind of thing I was worried about... > > > There is a simple fix for this problem by applying the attached patch > > which uses: > > Great, thanks. Out of curiosity, how come this patch isn't in 7.0 ? > PR 112997 was submitted to resolve this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 it just didn't have enough attention to get someone interested in committing it. Scot From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 20:28:07 2007 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 691F816A41B for ; Sun, 16 Dec 2007 20:28:07 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing02.lava.net (outgoing02.lava.net [64.65.64.125]) by mx1.freebsd.org (Postfix) with ESMTP id 343F613C461 for ; Sun, 16 Dec 2007 20:28:07 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id AA3C8B8A47; Sun, 16 Dec 2007 10:28:06 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 15980153882; Sun, 16 Dec 2007 10:28:04 -1000 (HST) Date: Sun, 16 Dec 2007 10:28:03 -1000 From: Clifton Royston To: Jeremy Chadwick Message-ID: <20071216202803.GC2036@lava.net> Mail-Followup-To: Jeremy Chadwick , Elliot Finley , freebsd-stable@freebsd.org, User Questions References: <20071215235810.GA81924@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071215235810.GA81924@eos.sc1.parodius.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, User Questions Subject: Re: OS bug in taskq 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, 16 Dec 2007 20:28:07 -0000 On Sat, Dec 15, 2007 at 03:58:10PM -0800, Jeremy Chadwick wrote: > On Sat, Dec 15, 2007 at 01:03:14PM -0700, Elliot Finley wrote: > > I have: > > dumpdev="AUTO" > > in /etc/rc.conf and: > > ... > > in the kernel and I'm still unable to obtain a crash dump. Hopefully > > there is enough info in this email for a hacker to point me in the > > right direction to debug this. > > I can't help with the panic itself, but the reason for the inability to > obtain a crash dump is mentioned in a thread I started in November: > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038069.html > > The explanation of the problem was documented best by Doug Barton in > this thread (over at freebsd-rc@): > > http://lists.freebsd.org/pipermail/freebsd-rc/2007-November/001263.html > > Open PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=118255 Why does it work *sometimes* then? Or was this particular problem introduced more recently than the 6.2 branch? I have two apparently similarly configured systems running 6.2p8, with identical hardware, identical apps, and identical load, and I have at least attempted to configure them the same way. Both have /var/crash set up and "dumpon" enabled in rc.conf. Both crashed in the last week. I got a dump on one, which I now need to analyze, but have twice failed to get a dump on the other. (Once this past week, once the previous month.) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Dec 16 23:23:01 2007 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 3CD1516A418 for ; Sun, 16 Dec 2007 23:23:01 +0000 (UTC) (envelope-from msnkipa@mail.ru) Received: from mx44.mail.ru (mx44.mail.ru [195.239.211.10]) by mx1.freebsd.org (Postfix) with ESMTP id 83B5313C45B for ; Sun, 16 Dec 2007 23:23:00 +0000 (UTC) (envelope-from msnkipa@mail.ru) Received: from f127.mail.ru (f127.mail.ru [194.67.57.236]) by mx44.mail.ru (mPOP.Fallback_MX) with ESMTP id 5A160380042DE for ; Mon, 17 Dec 2007 02:01:31 +0300 (MSK) Received: from mail by f127.mail.ru with local id 1J42UD-0008Zn-00 for freebsd-stable@freebsd.org; Mon, 17 Dec 2007 02:01:29 +0300 Received: from [91.192.191.141] by win.mail.ru with HTTP; Mon, 17 Dec 2007 02:01:29 +0300 From: =?koi8-r?Q?=ED=C9=C8=C1=C9=CC_=EB=C9=D0=C1?= To: freebsd-stable@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [91.192.191.141] Date: Mon, 17 Dec 2007 02:01:29 +0300 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Subject: FreeBSD 7.0beta4 panic on ftp transfer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?koi8-r?Q?=ED=C9=C8=C1=C9=CC_=EB=C9=D0=C1?= List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2007 23:23:01 -0000 SO I have 7.0beta4 on my server. My HDD have such configuration: ad4: 476940MB at ata2-master SATA300 ad6: 476940MB at ata3-master SATA300 ad10: 152627MB at ata5-master SATA150 ad12: 152627MB at ata6-master SATA150 ar0: 476928MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (mirror) using ad6 at ata3-master ar1: 152627MB status: READY ar1: disk0 READY (master) using ad10 at ata5-master ar1: disk1 READY (mirror) using ad12 at ata6-master SMP: AP CPU #1 Launched! During ftp transfer (among 10GB to server) I have kernel panic and reboon wiht such log messages: Dec 17 01:27:24 SERVER ftpd[11594]: ANONYMOUS FTP LOGIN REFUSED FROM MISHA.w Dec 17 01:34:25 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491351 Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491479 Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491479 Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491607 Dec 17 01:49:17 SERVER syslogd: kernel boot file is /boot/kernel/kernel Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:35:41 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491607 Dec 17 01:49:17 SERVER syslogd: kernel boot file is /boot/kernel/kernel Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491735 Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=211491863 Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=211491607 Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=211491735 Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=211491735 Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=211491863 Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: FAILURE - WRITE_DMA timed out LBA=211491607 Dec 17 01:49:17 SERVER kernel: ad4: WARNING - WRITE_DMA taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: ad6: WARNING - WRITE_DMA taskqueue timeout - completing request directly Dec 17 01:49:17 SERVER kernel: Dec 17 01:49:17 SERVER kernel: Dec 17 01:49:17 SERVER kernel: Fatal trap 12: page fault while in kernel mode Dec 17 01:49:17 SERVER kernel: cpuid = 0; apic id = 00 Dec 17 01:49:17 SERVER kernel: fault virtual address = 0x18 Dec 17 01:49:17 SERVER kernel: fault code = supervisor read data, page not present Dec 17 01:49:17 SERVER kernel: instruction pointer = 0x8:0xffffffff80221bec Dec 17 01:49:17 SERVER kernel: stack pointer = 0x10:0xffffffffab692af0 Dec 17 01:49:17 SERVER kernel: frame pointer = 0x10:0xffffff0029b72bd0 Dec 17 01:49:17 SERVER kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Dec 17 01:49:17 SERVER kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Dec 17 01:49:17 SERVER kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Dec 17 01:49:17 SERVER kernel: current process = 17 (swi6: task queue) Dec 17 01:49:17 SERVER kernel: trap number = 12 Dec 17 01:49:17 SERVER kernel: panic: page fault Dec 17 01:49:17 SERVER kernel: cpuid = 0 Dec 17 01:49:17 SERVER kernel: Uptime: 3d5h9m56s ad4 and ad6 is my mirror RAID on which I try to write! Anyone can explain to what does it mean??? Mihail From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 05:21:19 2007 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 64C6A16A420 for ; Mon, 17 Dec 2007 05:21:19 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 2D7AF13C46B for ; Mon, 17 Dec 2007 05:21:19 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 31882 invoked from network); 17 Dec 2007 04:54:38 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 17 Dec 2007 04:54:38 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Sun, 16 Dec 2007 23:54:28 -0500 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@FreeBSD.org Subject: Packet loss every 30.999 seconds 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, 17 Dec 2007 05:21:19 -0000 While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated November 8, 2007 it looks like I've stumbled across a broken driver or kernel routine which stops interrupt processing long enough to severly degrade network performance every 30.99 seconds. Packets appear to make it as far as ether_input() then get lost. Test setup: A - ethernet_switch - B A sends UDP packets to B through an ethernet switch. The interface input packet count and output packet count on the switch match what A is sending and B should be receiving. A UDP receiver running on B sees windows of packet loss with a period of 30.99 seconds. The lost packets are counted based on an incrementing sequence number. On an isolated network the Ipkts counter on B matches what A is sending, but the packets never show up in any of the IP/UDP counters or the program trying to receive them. This behavior can be seen with both em and fxp interfaces. Problem is it only occurs after the receiving host has been up about a day. Reboot, problem clears. GENERIC kernel, nothing more than default daemons running. Behavior seen on three different motherboards so far. It also appears this is not just lost network interrupts. Whatever is spinning in the kernel also impacts syscall latency. An easy way to replicate what I'm seeing is to run gettimeofday() in a tight loop and note when the real time syscall delay exceeds some value (which is dependent on processor speed). As an example on an 3.20GHz CPU a small program will output when the syscall latency is > 5000 usecs. Note the periodic behavior at 30.99 seconds. These big jumps in latency correspond to when packets are being dropped. usecs (epoch) latency diff ------------------------------------------------ 1197861705805078 478199 0 1197861721012298 25926 15207220 1197861726332036 11729 5319738 1197861757331549 11691 30999513 1197861788331266 11878 30999717 1197861819330647 11708 30999381 1197861850330192 11698 30999545 1197861881329733 11667 30999541 1197861900018297 6516 18688564 1197861912329282 11684 12310985 1197861943328849 11699 30999567 1197861974328413 11692 30999564 1197862005328228 11916 30999815 1197862036327598 11684 30999370 1197862067327229 11680 30999631 1197862098326860 11667 30999631 1197862129326559 11704 30999699 1197862160326377 11844 30999818 1197862191325890 11674 30999513 (output from packet loss tester) window_start/window_end is packet counter time_start/time_end is absolute time in usecs. window_diff is # of packets missing The test is run at about 15.5Kpps / 132Mbits/second, certainly a lot less than this hardware is capable of running BSD4.X. :missing window_start=311510, time_start=1197861726332008,window_end=311638, time_end=1197861726332011, window_diff=128, time_diff=3 :missing window_start=794482, time_start=1197861757331505,window_end=794609, time_end=1197861757331509, window_diff=127, time_diff=4 :missing window_start=1277313, time_start=1197861788331245,window_end=1277444, time_end=1197861788331249, window_diff=131, time_diff=4 :missing window_start=1760104, time_start=1197861819330625,window_end=1760232, time_end=1197861819330629, window_diff=128, time_diff=4 :missing window_start=2242789, time_start=1197861850330170,window_end=2242916, time_end=1197861850330174, window_diff=127, time_diff=4 :missing window_start=2725818, time_start=1197861881329712,window_end=2725946, time_end=1197861881329715, window_diff=128, time_diff=3 :missing window_start=3208594, time_start=1197861912329261,window_end=3208722, time_end=1197861912329264, window_diff=128, time_diff=3 :missing window_start=3691395, time_start=1197861943328802,window_end=3691522, time_end=1197861943328805, window_diff=127, time_diff=3 :missing window_start=4173793, time_start=1197861974328369,window_end=4173921, time_end=1197861974328373, window_diff=128, time_diff=4 :missing window_start=4656236, time_start=1197862005328176,window_end=4656367, time_end=1197862005328179, window_diff=131, time_diff=3 :missing window_start=5139197, time_start=1197862036327576,window_end=5139325, time_end=1197862036327580, window_diff=128, time_diff=4 :missing window_start=5621958, time_start=1197862067327208,window_end=5622085, time_end=1197862067327211, window_diff=127, time_diff=3 :missing window_start=6104597, time_start=1197862098326839,window_end=6104725, time_end=1197862098326843, window_diff=128, time_diff=4 :missing window_start=6587241, time_start=1197862129326514,window_end=6587369, time_end=1197862129326534, window_diff=128, time_diff=20 :missing window_start=7070051, time_start=1197862160326368,window_end=7070183, time_end=1197862160326371, window_diff=132, time_diff=3 :missing window_start=7552828, time_start=1197862191325873,window_end=7552954, time_end=1197862191325876, window_diff=126, time_diff=3 :missing window_start=8035434, time_start=1197862222325572,window_end=8035560, time_end=1197862222325576, window_diff=126, time_diff=4 I'm building a more up to date copy of RELENG_6 to make sure I'm not chasing something that's been fixed. As a side note this appears to also be happening on a RELENG_6 build dated Mar 11 2007. Included is the gettimeofday() looper. Run as ./a.out 1 5000, where 5000 will depend on your system speed. This probably won't provide any meaningful results on a loaded system. E-mail me off list for a copy of the packet tester or more diagnostics. #include #include #include #include #include #include #include #include main(int argc, char **argv) { struct timeval tv; struct timezone tz; u_int64_t time_now, time_last, time_mark; int quiet, max; if (argc != 3) errx(1, "Usage: %s ", argv[0]); quiet=atoi(argv[1]); max=atoi(argv[2]); gettimeofday(&tv, &tz); time_last = (u_int64_t)tv.tv_sec * 1000000LL + (u_int64_t)tv.tv_usec; time_mark = 0LL; for (;;) { gettimeofday(&tv, &tz); time_now = (u_int64_t)tv.tv_sec * 1000000LL + (u_int64_t) tv.tv_usec; if (!quiet) { printf("%llu %llu %llu\n", time_now, time_now-time_last, time_now-time_mark); time_mark = time_now; } else { if ((time_now-time_last) > max) { if (time_mark == 0) time_mark = time_now; printf("%llu %llu %llu\n", time_now, time_now-time_last, time_now-time_mark); time_mark = time_now; } } time_last = time_now; } } /* main */ From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 05:21:53 2007 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 CF91216A421 for ; Mon, 17 Dec 2007 05:21:53 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 954E513C448 for ; Mon, 17 Dec 2007 05:21:53 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 35963 invoked from network); 17 Dec 2007 05:21:52 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 17 Dec 2007 05:21:52 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: Mark Fullmer Date: Mon, 17 Dec 2007 00:21:43 -0500 X-Mailer: Apple Mail (2.752.3) Subject: Packet loss every 30.999 seconds 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, 17 Dec 2007 05:21:53 -0000 While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated November 8, 2007 it looks like I've stumbled across a broken driver or kernel routine which stops interrupt processing long enough to severly degrade network performance every 30.99 seconds. Packets appear to make it as far as ether_input() then get lost. Test setup: A - ethernet_switch - B A sends UDP packets to B through an ethernet switch. The interface input packet count and output packet count on the switch match what A is sending and B should be receiving. A UDP receiver running on B sees windows of packet loss with a period of 30.99 seconds. The lost packets are counted based on an incrementing sequence number. On an isolated network the Ipkts counter on B matches what A is sending, but the packets never show up in any of the IP/UDP counters or the program trying to receive them. This behavior can be seen with both em and fxp interfaces. Problem is it only occurs after the receiving host has been up about a day. Reboot, problem clears. GENERIC kernel, nothing more than default daemons running. Behavior seen on three different motherboards so far. It also appears this is not just lost network interrupts. Whatever is spinning in the kernel also impacts syscall latency. An easy way to replicate what I'm seeing is to run gettimeofday() in a tight loop and note when the real time syscall delay exceeds some value (which is dependent on processor speed). As an example on an 3.20GHz CPU a small program will output when the syscall latency is > 5000 usecs. Note the periodic behavior at 30.99 seconds. These big jumps in latency correspond to when packets are being dropped. usecs (epoch) latency diff ------------------------------------------------ 1197861705805078 478199 0 1197861721012298 25926 15207220 1197861726332036 11729 5319738 1197861757331549 11691 30999513 1197861788331266 11878 30999717 1197861819330647 11708 30999381 1197861850330192 11698 30999545 1197861881329733 11667 30999541 1197861900018297 6516 18688564 1197861912329282 11684 12310985 1197861943328849 11699 30999567 1197861974328413 11692 30999564 1197862005328228 11916 30999815 1197862036327598 11684 30999370 1197862067327229 11680 30999631 1197862098326860 11667 30999631 1197862129326559 11704 30999699 1197862160326377 11844 30999818 1197862191325890 11674 30999513 (output from packet loss tester) window_start/window_end is packet counter time_start/time_end is absolute time in usecs. window_diff is # of packets missing The test is run at about 15.5Kpps / 132Mbits/second, certainly a lot less than this hardware is capable of running BSD4.X. :missing window_start=311510, time_start=1197861726332008,window_end=311638, time_end=1197861726332011, window_diff=128, time_diff=3 :missing window_start=794482, time_start=1197861757331505,window_end=794609, time_end=1197861757331509, window_diff=127, time_diff=4 :missing window_start=1277313, time_start=1197861788331245,window_end=1277444, time_end=1197861788331249, window_diff=131, time_diff=4 :missing window_start=1760104, time_start=1197861819330625,window_end=1760232, time_end=1197861819330629, window_diff=128, time_diff=4 :missing window_start=2242789, time_start=1197861850330170,window_end=2242916, time_end=1197861850330174, window_diff=127, time_diff=4 :missing window_start=2725818, time_start=1197861881329712,window_end=2725946, time_end=1197861881329715, window_diff=128, time_diff=3 :missing window_start=3208594, time_start=1197861912329261,window_end=3208722, time_end=1197861912329264, window_diff=128, time_diff=3 :missing window_start=3691395, time_start=1197861943328802,window_end=3691522, time_end=1197861943328805, window_diff=127, time_diff=3 :missing window_start=4173793, time_start=1197861974328369,window_end=4173921, time_end=1197861974328373, window_diff=128, time_diff=4 :missing window_start=4656236, time_start=1197862005328176,window_end=4656367, time_end=1197862005328179, window_diff=131, time_diff=3 :missing window_start=5139197, time_start=1197862036327576,window_end=5139325, time_end=1197862036327580, window_diff=128, time_diff=4 :missing window_start=5621958, time_start=1197862067327208,window_end=5622085, time_end=1197862067327211, window_diff=127, time_diff=3 :missing window_start=6104597, time_start=1197862098326839,window_end=6104725, time_end=1197862098326843, window_diff=128, time_diff=4 :missing window_start=6587241, time_start=1197862129326514,window_end=6587369, time_end=1197862129326534, window_diff=128, time_diff=20 :missing window_start=7070051, time_start=1197862160326368,window_end=7070183, time_end=1197862160326371, window_diff=132, time_diff=3 :missing window_start=7552828, time_start=1197862191325873,window_end=7552954, time_end=1197862191325876, window_diff=126, time_diff=3 :missing window_start=8035434, time_start=1197862222325572,window_end=8035560, time_end=1197862222325576, window_diff=126, time_diff=4 I'm building a more up to date copy of RELENG_6 to make sure I'm not chasing something that's been fixed. As a side note this appears to also be happening on a RELENG_6 build dated Mar 11 2007. Included is the gettimeofday() looper. Run as ./a.out 1 5000, where 5000 will depend on your system speed. This probably won't provide any meaningful results on a loaded system. E-mail me off list for a copy of the packet tester or more diagnostics. #include #include #include #include #include #include #include #include main(int argc, char **argv) { struct timeval tv; struct timezone tz; u_int64_t time_now, time_last, time_mark; int quiet, max; if (argc != 3) errx(1, "Usage: %s ", argv[0]); quiet=atoi(argv[1]); max=atoi(argv[2]); gettimeofday(&tv, &tz); time_last = (u_int64_t)tv.tv_sec * 1000000LL + (u_int64_t)tv.tv_usec; time_mark = 0LL; for (;;) { gettimeofday(&tv, &tz); time_now = (u_int64_t)tv.tv_sec * 1000000LL + (u_int64_t) tv.tv_usec; if (!quiet) { printf("%llu %llu %llu\n", time_now, time_now-time_last, time_now-time_mark); time_mark = time_now; } else { if ((time_now-time_last) > max) { if (time_mark == 0) time_mark = time_now; printf("%llu %llu %llu\n", time_now, time_now-time_last, time_now-time_mark); time_mark = time_now; } } time_last = time_now; } } /* main */ From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 05:43:06 2007 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 327D516A469 for ; Mon, 17 Dec 2007 05:43:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC3B13C465 for ; Mon, 17 Dec 2007 05:43:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 0648F1CC079; Sun, 16 Dec 2007 21:43:06 -0800 (PST) Date: Sun, 16 Dec 2007 21:43:06 -0800 From: Jeremy Chadwick To: Mark Fullmer Message-ID: <20071217054305.GA18268@eos.sc1.parodius.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 17 Dec 2007 05:43:06 -0000 On Mon, Dec 17, 2007 at 12:21:43AM -0500, Mark Fullmer wrote: > While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated > November 8, 2007 it looks like I've stumbled across a broken driver or > kernel routine which stops interrupt processing long enough to severly > degrade network performance every 30.99 seconds. > > Packets appear to make it as far as ether_input() then get lost. Are you sure this isn't being caused by something the switch is doing, such as MAC/ARP cache clearing or LACP? I'm just speculating, but it would be worthwhile to remove the switch from the picture (crossover cable to the rescue). I know that at least in the case of fxp(4) and em(4), Jack Vogel does some through testing of throughput using a professional/high-end packet generator (some piece of hardware, I forget the name...) -- | Jeremy Chadwick jdc at 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 Dec 17 05:45:17 2007 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 9AE5916A420 for ; Mon, 17 Dec 2007 05:45:17 +0000 (UTC) (envelope-from maf@splintered.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 5EDFA13C4D9 for ; Mon, 17 Dec 2007 05:45:17 +0000 (UTC) (envelope-from maf@splintered.net) Received: (qmail 35630 invoked from network); 17 Dec 2007 05:18:36 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 17 Dec 2007 05:18:36 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: Mark Fullmer Date: Mon, 17 Dec 2007 00:18:26 -0500 X-Mailer: Apple Mail (2.752.3) Subject: Packet loss every 30.999 seconds 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, 17 Dec 2007 05:45:17 -0000 While trying to diagnose a packet loss problem in a RELENG_6 snapshot dated November 8, 2007 it looks like I've stumbled across a broken driver or kernel routine which stops interrupt processing long enough to severly degrade network performance every 30.99 seconds. Packets appear to make it as far as ether_input() then get lost. Test setup: A - ethernet_switch - B A sends UDP packets to B through an ethernet switch. The interface input packet count and output packet count on the switch match what A is sending and B should be receiving. A UDP receiver running on B sees windows of packet loss with a period of 30.99 seconds. The lost packets are counted based on an incrementing sequence number. On an isolated network the Ipkts counter on B matches what A is sending, but the packets never show up in any of the IP/UDP counters or the program trying to receive them. This behavior can be seen with both em and fxp interfaces. Problem is it only occurs after the receiving host has been up about a day. Reboot, problem clears. GENERIC kernel, nothing more than default daemons running. Behavior seen on three different motherboards so far. It also appears this is not just lost network interrupts. Whatever is spinning in the kernel also impacts syscall latency. An easy way to replicate what I'm seeing is to run gettimeofday() in a tight loop and note when the real time syscall delay exceeds some value (which is dependent on processor speed). As an example on an 3.20GHz CPU a small program will output when the syscall latency is > 5000 usecs. Note the periodic behavior at 30.99 seconds. These big jumps in latency correspond to when packets are being dropped. usecs (epoch) latency diff ------------------------------------------------ 1197861705805078 478199 0 1197861721012298 25926 15207220 1197861726332036 11729 5319738 1197861757331549 11691 30999513 1197861788331266 11878 30999717 1197861819330647 11708 30999381 1197861850330192 11698 30999545 1197861881329733 11667 30999541 1197861900018297 6516 18688564 1197861912329282 11684 12310985 1197861943328849 11699 30999567 1197861974328413 11692 30999564 1197862005328228 11916 30999815 1197862036327598 11684 30999370 1197862067327229 11680 30999631 1197862098326860 11667 30999631 1197862129326559 11704 30999699 1197862160326377 11844 30999818 1197862191325890 11674 30999513 (output from packet loss tester) window_start/window_end is packet counter time_start/time_end is absolute time in usecs. window_diff is # of packets missing The test is run at about 15.5Kpps / 132Mbits/second, certainly a lot less than this hardware is capable of running BSD4.X. :missing window_start=311510, time_start=1197861726332008,window_end=311638, time_end=1197861726332011, window_diff=128, time_diff=3 :missing window_start=794482, time_start=1197861757331505,window_end=794609, time_end=1197861757331509, window_diff=127, time_diff=4 :missing window_start=1277313, time_start=1197861788331245,window_end=1277444, time_end=1197861788331249, window_diff=131, time_diff=4 :missing window_start=1760104, time_start=1197861819330625,window_end=1760232, time_end=1197861819330629, window_diff=128, time_diff=4 :missing window_start=2242789, time_start=1197861850330170,window_end=2242916, time_end=1197861850330174, window_diff=127, time_diff=4 :missing window_start=2725818, time_start=1197861881329712,window_end=2725946, time_end=1197861881329715, window_diff=128, time_diff=3 :missing window_start=3208594, time_start=1197861912329261,window_end=3208722, time_end=1197861912329264, window_diff=128, time_diff=3 :missing window_start=3691395, time_start=1197861943328802,window_end=3691522, time_end=1197861943328805, window_diff=127, time_diff=3 :missing window_start=4173793, time_start=1197861974328369,window_end=4173921, time_end=1197861974328373, window_diff=128, time_diff=4 :missing window_start=4656236, time_start=1197862005328176,window_end=4656367, time_end=1197862005328179, window_diff=131, time_diff=3 :missing window_start=5139197, time_start=1197862036327576,window_end=5139325, time_end=1197862036327580, window_diff=128, time_diff=4 :missing window_start=5621958, time_start=1197862067327208,window_end=5622085, time_end=1197862067327211, window_diff=127, time_diff=3 :missing window_start=6104597, time_start=1197862098326839,window_end=6104725, time_end=1197862098326843, window_diff=128, time_diff=4 :missing window_start=6587241, time_start=1197862129326514,window_end=6587369, time_end=1197862129326534, window_diff=128, time_diff=20 :missing window_start=7070051, time_start=1197862160326368,window_end=7070183, time_end=1197862160326371, window_diff=132, time_diff=3 :missing window_start=7552828, time_start=1197862191325873,window_end=7552954, time_end=1197862191325876, window_diff=126, time_diff=3 :missing window_start=8035434, time_start=1197862222325572,window_end=8035560, time_end=1197862222325576, window_diff=126, time_diff=4 I'm building a more up to date copy of RELENG_6 to make sure I'm not chasing something that's been fixed. As a side note this appears to also be happening on a RELENG_6 build dated Mar 11 2007. Included is the gettimeofday() looper. Run as ./a.out 1 5000, where 5000 will depend on your system speed. This probably won't provide any meaningful results on a loaded system. E-mail me off list for a copy of the packet tester or more diagnostics. #include #include #include #include #include #include #include #include main(int argc, char **argv) { struct timeval tv; struct timezone tz; u_int64_t time_now, time_last, time_mark; int quiet, max; if (argc != 3) errx(1, "Usage: %s ", argv[0]); quiet=atoi(argv[1]); max=atoi(argv[2]); gettimeofday(&tv, &tz); time_last = (u_int64_t)tv.tv_sec * 1000000LL + (u_int64_t)tv.tv_usec; time_mark = 0LL; for (;;) { gettimeofday(&tv, &tz); time_now = (u_int64_t)tv.tv_sec * 1000000LL + (u_int64_t) tv.tv_usec; if (!quiet) { printf("%llu %llu %llu\n", time_now, time_now-time_last, time_now-time_mark); time_mark = time_now; } else { if ((time_now-time_last) > max) { if (time_mark == 0) time_mark = time_now; printf("%llu %llu %llu\n", time_now, time_now-time_last, time_now-time_mark); time_mark = time_now; } } time_last = time_now; } } /* main */ From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 05:52:38 2007 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 104B516A469 for ; Mon, 17 Dec 2007 05:52:38 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id BF21813C468 for ; Mon, 17 Dec 2007 05:52:37 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 40383 invoked from network); 17 Dec 2007 05:52:37 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 17 Dec 2007 05:52:37 -0000 In-Reply-To: <20071217054305.GA18268@eos.sc1.parodius.com> References: <20071217054305.GA18268@eos.sc1.parodius.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4EDA6951-C422-4A5C-BB5A-1C292BD8BBFE@eng.oar.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Mon, 17 Dec 2007 00:52:27 -0500 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.752.3) Cc: Jeremy Chadwick Subject: Re: Packet loss every 30.999 seconds 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, 17 Dec 2007 05:52:38 -0000 I'm about 99% sure right now. I'll set this up in a lab tomorrow without an ethernet switch. It takes about a day of uptime before the problem shows up. Sorry for the duplicate messages, I misread a bounce notification. -- mark On Dec 17, 2007, at 12:43 AM, Jeremy Chadwick wrote: > On Mon, Dec 17, 2007 at 12:21:43AM -0500, Mark Fullmer wrote: >> While trying to diagnose a packet loss problem in a RELENG_6 >> snapshot dated >> November 8, 2007 it looks like I've stumbled across a broken >> driver or >> kernel routine which stops interrupt processing long enough to >> severly >> degrade network performance every 30.99 seconds. >> >> Packets appear to make it as far as ether_input() then get lost. > > Are you sure this isn't being caused by something the switch is doing, > such as MAC/ARP cache clearing or LACP? I'm just speculating, but it > would be worthwhile to remove the switch from the picture (crossover > cable to the rescue). > > I know that at least in the case of fxp(4) and em(4), Jack Vogel does > some through testing of throughput using a professional/high-end > packet > generator (some piece of hardware, I forget the name...) > > -- > | Jeremy Chadwick jdc at > parodius.com | > | Parodius Networking http:// > www.parodius.com/ | > | UNIX Systems Administrator Mountain View, > CA, USA | > | Making life hard for others since 1977. PGP: > 4BD6C0CB | > > _______________________________________________ > 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 Dec 17 06:10:42 2007 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 7E96416A421 for ; Mon, 17 Dec 2007 06:10:42 +0000 (UTC) (envelope-from finances@wht-info.info.dm-4.com) Received: from mta224a.dm-4.com (mta224a.dm-4.com [64.40.113.224]) by mx1.freebsd.org (Postfix) with ESMTP id E2B8913C45A for ; Mon, 17 Dec 2007 06:10:41 +0000 (UTC) (envelope-from finances@wht-info.info.dm-4.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=x; d=dm-4.com; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding; i=finances@wht-info.info.dm-4.com; bh=/tpN9vYJWIEHUHnp7QiYoQlEf1g=; b=LR70afZbPxtSgTkKQHdevCOnlIPdBKYngAOTkoVzI9jwVRm901DhrD/mIm11kKpcyhoXyYXVejXM nyz6UpZseiFIEfPGVV24NYVISHxkTM3c8d/4C3dJ83nXuYDzcZJy2wDSoW05JAn6jjTAMDs5LnQu qnne6UcY4C/edVKO1Kw= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=x; d=dm-4.com; b=PuT/Mes3GS+2Gun6IDKpAZFccGjJ34HF+zaL+8wPjS5xpd9ar7LgLtiF0BKEV/fheoe/nm+tyu46 pzyj3rw1esWoOlr0rSqI82KH/iAHPzRftOpNSWayXhzEl2ATfF6iRidsLRyr/BeqmIAueXJLZZeQ 4mbXP2liDhWcOM2D2I4=; Received: by mta224a.dm-4.com (PowerMTA(TM) v3.2r17) id hco9ga0dao81 for ; Sun, 16 Dec 2007 22:00:11 -0800 (envelope-from ) Message-ID: Date: Mon, 17 Dec 2007 06:00:11 GMT From: "Guide CF" To: "freebsd-stable@FreeBSD.org" X-Mailer: MB3S0M VODT2KI RZQTVPK 4O44FA Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Generation Y - Gerer sans deprimer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: finances@wht-info.info.dm-4.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2007 06:10:42 -0000 =0D=0A =0D=0A =0D=0A <=21--mstheme -->=0D=0A = =0D=0A =0D=0A =0D=0A =0D=0A= FORMATION GEN= ERATION Y : RECRUTEMENT ET GESTION RECONCILIER LES GENERATIONS POUR PL= US D=27EFFICACITE =0D=0A M=26Eacute;THODE P=26= Eacute;DAGOGIQUE: Apports m=26eacute;thodologiques, exercices pra= tiques et mises en situation, compl=26eacute;t=26eacute;es et enrichies d= e partage d=27exp=26eacute;riences v=26eacute;cues et de t=26eacute;moign= age d=27expert=2E Travail et discussions =26agrave; partir des cas pr=26e= acute;sent=26eacute;s par les participants=2E =26nbsp; =0D=0A <= p align=3D=22center=22>POUR INFORMATIONS COMMUNIQUER AU = =0D=0A 450-22= 6-2238 OU 1-800-861-6618 =0D=0A =0D=0A PUBLIC VIS=26Eacute;: Les Dirigeants d=27entreprises, et, par d=26= eacute;l=26eacute;gation, toute personne en charge du recrutement, eT l=27= int=26eacute;gration et du management de travailleurs issus de la g=26eac= ute;n=26eacute;ration Y=2E INTRODUCTION: Les =27Y=27 e= n entreprise sont caract=26eacute;ris=26eacute;s comme des =27ind=26eacut= e;pendants=27, des =27multi-t=26acirc;ches=27 voire des =27impatients=27,= =2E Ils ont pour eux l=27aisance dans les nouvelles technologies, la volo= nt=26eacute; et la capacit=26eacute; d=27apprendre sans cesse, la mobilit= =26eacute;=2E=2E=2Eet ils ont le choix de s=27engager ou non, selon que l= es conditions mat=26eacute;rielles et l=27ambiance observ=26eacute;e renc= ontrent ou non leur id=26eacute;e du travail=2E Le contexte de ple= in emploi n=27incite pas =26agrave; rapprocher les nouvelles g=26eacute;n= =26eacute;rations des anciennes : des compromis succ=26egrave;dent aux d=26= eacute;ceptions, pour seulement quelques rares succ=26egrave;s d=27int=26= eacute;gration=2E Il en r=26eacute;sulte un sentiment d=27impuissa= nce de la part d=27une majorit=26eacute; d=27employeurs, voire de ras-le-= bol=2E Cette formation vise =26agrave; faire sortir les cadres et dirigea= nts de leurs orni=26egrave;res en leur procurant une m=26eacute;thode pou= r recruter et g=26eacute;rer l=27int=26eacute;gration de la g=26eacute;n=26= eacute;ration Y dans les autres g=26eacute;n=26eacute;rations=2E P= OUR INFORMATIONS suppl=26eacute;mentaires contactez-nous au 1=2E877=2E726= =2E2238 OBJECTIFS: * Comprendre ce et ceux qui se cachent d= erri=26egrave;re =27la g=26eacute;n=26eacute;ration Y=27 * Prendre con= science des v=26eacute;ritables d=26eacute;fis pos=26eacute;s par cette g= =26eacute;n=26eacute;ration * Int=26eacute;grer les besoins de cette g= =26eacute;n=26eacute;ration dans l=27environnement et le cadre de travail= au quotidien * Savoir r=26eacute;diger une offre d=27emploi dans le l= angage de la g=26eacute;n=26eacute;ration Y * Savoir communiquer, en p= articulier dans les =26eacute;tapes de recrutement et d=27accueil - conna= =26icirc;tre le langage =26agrave; bannir * Apprendre les bonnes prati= ques dans les phases-cl=26eacute;s d=27acquisition d=27autonomie des trav= ailleurs de cette g=26eacute;n=26eacute;ration * Rep=26eacute;rer les = vraies sources de motivation sur le long terme et concevoir les strat=26e= acute;gies pour y faire face * Conduire le changement aupr=26egrave;s = des autres populations et savoir rapprocher les g=26eacute;n=26eacute;rat= ions * Poser les bases d=27une pr=26eacute;paration efficace de la rel= =26egrave;ve, =26agrave; tous les =26eacute;chelons et niveaux des entrep= rises * Devenir un =27employeur de choix=27 pour la g=26eacute;n=26eac= ute;ration Y PLAN DE COURS 1 - CASSER LES MYTHES : LA G= ENERATION Y EST UN PHENOMENE MONDIAL ET UNE TENDANCE LOURDE 2 - CE QUE= NOUS POUVONS ATTENDRE DE LA GENERATION Y 3 - L=27ENGAGEMENT POUR LA G= ENERATION Y : IDEAUX ET VALEURS 4 - LA SEDUCTION RECIPROQUE ET LA CONF= IANCE RECIPROQUE 5 - COMMENT ATTIRER LES JEUNES SANS FAIRE FUIR LES AN= CIENS : TROIS NIVEAUX DE PROBLEMES 6 - LES NOUVELLES DIMENSIONS ET IND= ICATEURS DE LA QUALITE DE VIE AU TRAVAIL 7 - L=27EMBAUCHE ET LE PROCES= SUS D=27INTEGRATION 8 - LE DEVELOPPEMENT DES COMPETENCES ET LE ROLE D= ES MENTORS 9 - LE DEVELOPPEMENT DE LA RELEVE ET LE ROLE DU MANAGER = 10 - LA GESTION DES SITUATIONS DIFFICILES ET LE ROLE DES SUPERVISEURS = =26nbsp; =0D=0A [1]Visitez notre s= ite internet =0D=0A DATES ET LIEUX DE LA FORMATION: DUR=26Eacute;E de la FORMATION: 2 jours N=2EB=2E Nombre de place= s limit=26eacute;s ( 15 Personnes ) R=26eacute;gion de = Montr=26eacute;al: Les 7 et 8=26nbsp;OU les 28 et 29 f=26= eacute;vrier 2008 H=26ocirc;tel Sheraton, 2440, Autoroute des Laurenti= des, Laval R=26eacute;gion de Qu=26eacute;bec:= Les 26 et 27 f=26eacute;vrier 2008 H=26ocirc;tel Des Gouverneu= rs, 3030 boulevard Laurier, Ste-Foy Pour inscription, veuillez= contacter Mme Maryse Morin au 1=2E877=2E726=2E2238 CF Formation 707, = rue du Village, suite 202, Morin-Heights, QC J0R 1H0 =26nbsp; [?78=2EOdbRG=] 1- Si vous so= uhaitez recevoir nos offres de formation, [2]cliquez ici 2- Si vous souhaitez vous retirer d=26= eacute;finitivement de notre base de donn=26eacute;es, [3]cliquez ici =0D=0A =0D=0A =0D=0A References 1. 3D=22http://content=/ 2. 3D=22http://content=2Ed=/ 3. 3D=22http:= From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 10:39:37 2007 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 6D01816A476; Mon, 17 Dec 2007 10:39:37 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC3313C44B; Mon, 17 Dec 2007 10:39:37 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBHAdamq056533; Mon, 17 Dec 2007 02:39:36 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBHAdaju056532; Mon, 17 Dec 2007 02:39:36 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Mon, 17 Dec 2007 02:39:36 -0800 From: David G Lawrence To: Mark Fullmer Message-ID: <20071217103936.GR25053@tnn.dglawrence.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Mon, 17 Dec 2007 02:39:36 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 17 Dec 2007 10:39:37 -0000 One more comment on my last email... The patch that I included is not meant as a real fix - it is just a bandaid. The real problem appears to be that a very large number of vnodes (all of them?) are getting synced (i.e. calling ffs_syncvnode()) every time. This should normally only happen for dirty vnodes. I suspect that something is broken with this check: if (vp->v_type == VNON || ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && vp->v_bufobj.bo_dirty.bv_cnt == 0)) { VI_UNLOCK(vp); continue; } ...like the i_flag flags aren't ever getting properly cleared (or bv_cnt is always non-zero). ...but I don't have the time to chase this down. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 10:42:28 2007 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 1FD7E16A418 for ; Mon, 17 Dec 2007 10:42:28 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 7854113C4F7 for ; Mon, 17 Dec 2007 10:42:27 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from [10.38.0.12] (unknown [194.50.70.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTP id ACFC4B0281; Mon, 17 Dec 2007 11:42:25 +0100 (CET) Message-ID: <47665299.4050208@kernel32.de> Date: Mon, 17 Dec 2007 11:42:33 +0100 From: Marian Hettwer User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Jeremy Chadwick References: <6d41e00a0d0deb2e305b1a4f86b9c601@127.0.0.1> <20071213205053.GA10017@eos.sc1.parodius.com> In-Reply-To: <20071213205053.GA10017@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 BETA4 no serial console 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, 17 Dec 2007 10:42:28 -0000 Hi Jeremy, Jeremy Chadwick schrieb: > On Thu, Dec 13, 2007 at 04:12:15PM +0100, Marian Hettwer wrote: > >> here's a snipped of a verbose boot: >> sio0: configured irq 3 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> > > This is somewhat normal (depends on the system), and can sometimes > even function normally (as is the case on your system). > > good. >> looks like some garbled output between bce0 and it seems to say: >> bec0: link state changed to up >> NFS ROOT: 10.38.0.14:/usr/local/nfsroot/freebsd-70-amd64 >> > > Please see http://jdc.parodius.com/freebsd/common_issues.txt for > that problem. > > jup. That was nothing I was worried about, though :) >> my configuration as is: >> /boot.config >> -Dh >> > > Change this to -S9600 -Dh, and remove the lines from /boot/loader.conf. > > did that. Still no login prompt via serial console. Although my getty is running: marian46-23# ps ax | grep ttyd 810 ?? I 0:00.00 /usr/libexec/getty std.9600 ttyd1 809 d0 Is+ 0:00.00 /usr/libexec/getty std.9600 ttyd0 882 p1 R+ 0:00.00 grep ttyd marian46-23# grep ttyd /etc/ttys ttyd0 "/usr/libexec/getty std.9600" vt220 on secure ttyd1 "/usr/libexec/getty std.9600" vt220 on secure ttyd2 "/usr/libexec/getty std.9600" dialup off secure ttyd3 "/usr/libexec/getty std.9600" dialup off secure This was of course logged in via ssh. >> /etc/ttys >> [mhettwer@blowfish] grep ttyd0 etc/ttys [16:10:55 on 07-12-13] >> ttyd0 "/usr/libexec/getty std.9600" vt220 on secure >> >> I believe my configuration is correct, isn't it? >> > > Looks correct. > > No serial login prompt, though :-/ >> Where's my login prompt? :) >> >> It's there with VGA output... >> > > conscontrol(8) might be able to tell you. It's very likely dedicated to > the VGA system at this point. conscontrol(8) appears to simply read and > parse the output of the kern.console sysctl. > > actually that sysctl looks fine to me: marian46-23# sysctl kern.console kern.console: ttyd0,dcons,consolectl,/dcons,consolectl,ttyd0, FWIW here's the complete serial output of the boot process. And yeah, it's really missing the login prompt. marian46-23# cat /tmp/boot.txt ? or [Space] to pause timer 0 ? ??????????????????????????????????????????? Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-BETA4 #0: Thu Dec 13 13:47:35 CET 2007 root@blowfish:/usr/obj/amd64/usr/src/sys/MOBILE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2600.12-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f13 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 usable memory = 4280684544 (4082 MB) avail memory = 4119326720 (3928 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 cpu2: on acpi0 powernow2: on cpu2 cpu3: on acpi0 powernow3: on cpu3 pcib0: on acpi0 pci0: on pcib0 vgapci0: port 0x1000-0x10ff mem 0xe8000000-0xefffffff,0xf7ff0000-0xf7ffffff irq 20 at device 3.0 on pci0 pci0: at device 4.0 (no driver attached) pci0: at device 4.2 (no driver attached) uhci0: port 0x1800-0x181f irq 21 at device 4.4 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: <(0x103c) UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 4.6 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 bce0: mem 0xfa000000-0xfbffffff irq 22 at device 3.0 on pci2 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 1000baseSX-FDX, auto bce0: Ethernet address: 00:1c:c4:aa:08:58 bce0: [ITHREAD] bce0: ASIC (0x57060021); Rev (A2); Bus (PCI-X, 64-bit, 100MHz); F/W (0x01090605); Flags( MSI ) bce1: mem 0xf8000000-0xf9ffffff irq 23 at device 4.0 on pci2 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 1000baseSX-FDX, auto bce1: Ethernet address: 00:1c:c4:aa:08:88 bce1: [ITHREAD] bce1: ASIC (0x57060021); Rev (A2); Bus (PCI-X, 64-bit, 100MHz); F/W (0x01090605); Flags( MSI ) isab0: at device 6.2 on pci0 isa0: on isab0 ohci0: port 0x1c00-0x1cff mem 0xf7ee0000-0xf7ee0fff irq 5 at device 7.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci0 usb1: USB revision 1.0 uhub1: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1 uhub1: 2 ports with 2 removable, self powered ohci1: port 0x3000-0x30ff mem 0xf7ed0000-0xf7ed0fff irq 5 at device 7.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci1 usb2: USB revision 1.0 uhub2: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: port 0x3400-0x34ff mem 0xf7ec0000-0xf7ec0fff irq 5 at device 7.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: <(0x1166) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3 uhub3: 4 ports with 4 removable, self powered pcib3: on acpi0 pci4: on pcib3 pcib4: irq 16 at device 15.0 on pci4 pci5: on pcib4 pcib5: irq 20 at device 16.0 on pci4 pci12: on pcib5 pcib6: irq 19 at device 17.0 on pci4 pci19: on pcib6 pcib7: at device 0.0 on pci19 pci20: on pcib7 pcib8: at device 4.0 on pci20 pci21: on pcib8 ciss0: port 0x4000-0x40ff mem 0xfdf80000-0xfdffffff,0xfdf70000-0xfdf77fff irq 19 at device 8.0 on pci20 ciss0: [ITHREAD] pcib9: irq 18 at device 18.0 on pci4 pci22: on pcib9 pcib10: irq 17 at device 19.0 on pci4 pci25: on pcib10 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcefff,0xcf000-0xd07ff,0xe6000-0xe7fff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub0 kbd2 at ukbd0 ums0: on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 uhub4: on uhub0 uhub4: 7 ports with 7 removable, self powered Timecounters tick every 1.000 msec SMP: APd aC0P Ua #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! t ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 69973MB (143305920 512 byte sectors: 255H 32S/T 17562C) Trying to mount root from ufs:/dev/da0s1a bce0: link state changed to DOWN bce0: link state changed to UP bce1: link state changed to UP More hints on what's going on? :) TIA, Marian From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 10:49:51 2007 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 05B5916A417 for ; Mon, 17 Dec 2007 10:49:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B76BA13C4F5 for ; Mon, 17 Dec 2007 10:49:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 38E724726D; Mon, 17 Dec 2007 05:49:50 -0500 (EST) Date: Mon, 17 Dec 2007 10:49:50 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Elliot Finley In-Reply-To: Message-ID: <20071217103625.S90185@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, User Questions Subject: Re: OS bug in taskq 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, 17 Dec 2007 10:49:51 -0000 On Sat, 15 Dec 2007, Elliot Finley wrote: > in the kernel and I'm still unable to obtain a crash dump. Hopefully there > is enough info in this email for a hacker to point me in the right direction > to debug this. If you're unable to obtain a crash dump, you should still be able to use interactive console-based debugging with DDB. I find this is easiest to do with a serial console from an adjacent machine, so that I can copy-and-paste the results into an e-mail rather than hand-transcribe. You can also use firewire consoles to the same effect, although I've never done that. Once the system panics, it will drop into DDB. I usually kick off debugging by doing a backtrace, "bt", and showing the status of the current and then all processors "show pcpu", "show allpcpu". Depending on the type of bug, I find output from "ps", "alltrace", "show lockedvnods", "show alllocks", "show uma", "show malloc" quite useful. The below panic is a NULL pointer dereference in the taskqueue code, but it's likely triggered by a bug in a consumer of the task queue service, rather than the task queue code itself. That means we'll need to identify what consumer that is. That information should become visible by looking at the arguments to the stack trace in DDB. If not, we may need to work a little harder to get a dump, or set up serial or firewire kgdb to inspect the live running system with a full debugger. On the swap / dump / etc thing. In order to capture a saved kernel dump, you need sufficient room for the full dump on whatever partition /var/crash is on, and it must be writable. Because dumps are normally written to swap partitions, running fsck before the dump is captured can lead to portions of the dump being overwritten if fsck uses a lot of memory (and hence overflows into swap). As many systems have a separate /var and /var is often small, it could well be that you can successfully capture the dump by just booting to single-user, manually fscking /var, mounting /var, and running savecore in the /var/crash directory. You can also configure additional partitions as purely dump partitions, rather than swap partitions. One trick I've used previousy is to add a disk temporarily just for the purposes of dumping to, and manually doing a dumpon for a partition on that disk (but not a swapon). Robert N M Watson Computer Laboratory University of Cambridge > > dmesg: > > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.2-RELEASE-p5 #1: Mon Nov 19 11:16:44 MST 2007 > root@postmaster.etv.net:/usr/obj/usr/src/sys/DDB-SMP > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.20-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 > > Features=0xbfebfbff > Features2=0x641d> > AMD Features=0x20100000 > AMD Features2=0x1 > Logical CPUs per core: 2 > real memory = 3220963328 (3071 MB) > avail memory = 3150856192 (3004 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > ioapic1: WARNING: intbase 32 != expected base 24 > ioapic2: Changing APIC ID to 10 > ioapic2: WARNING: intbase 64 != expected base 56 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 32-55 on motherboard > ioapic2 irqs 64-87 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > amr0: mem > 0xd80f0000-0xd80fffff,0xdfdc0000-0xdfdfffff irq 46 at device 14.0 on > pci2 > amr0: delete logical drives supported by controller > amr0: Firmware 522A, BIOS H430, 256MB RAM > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > pcib4: at device 4.0 on pci0 > pci4: on pcib4 > pcib5: at device 5.0 on pci0 > pci5: on pcib5 > pcib6: at device 0.0 on pci5 > pci6: on pcib6 > em0: port > 0xecc0-0xecff mem 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6 > em0: Ethernet address: 00:18:8b:34:70:50 > pcib7: at device 0.2 on pci5 > pci7: on pcib7 > em1: port > 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 65 at device 8.0 on pci7 > em1: Ethernet address: 00:18:8b:34:70:51 > pcib8: at device 6.0 on pci0 > pci8: on pcib8 > uhci0: port 0xbce0-0xbcff > irq 16 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xbcc0-0xbcdf > irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xbca0-0xbcbf > irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem > 0xdff00000-0xdff003ff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub3: 6 ports with 6 removable, self powered > uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 > uhub4: multiple transaction translators > uhub4: 2 ports with 2 removable, self powered > pcib9: at device 30.0 on pci0 > pci9: on pcib9 > pci9: at device 5.0 (no driver attached) > pci9: at device 5.1 (no driver attached) > pci9: at device 5.2 (no driver attached) > atapci0: port > 0xccf0-0xccf7,0xcce4-0xcce7,0xccd8-0xccdf,0xccd0-0xccd3,0xcc70-0xcc7f > mem 0xdf5fec00-0xdf5fecff irq 23 at device 6.0 on pci9 > ata2: on atapci0 > ata3: on atapci0 > pci9: at device 13.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on > pci0 > ata0: on atapci1 > ata1: on atapci1 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse, device ID 3 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 > on acpi0 > sio0: type 16550A > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xec000-0xeffff on > isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > ukbd0: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 > kbd2 at ukbd0 > ums0: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 > ums0: X report 0x0002 not supported > device_attach: ums0 attach returned 6 > Timecounters tick every 1.000 msec > acd0: CDROM at ata0-master UDMA33 > device_attach: afd0 attach returned 6 > acd1: CDROM at ata2-slave PIO3 > amr0: delete logical drives supported by controller > amrd0: on amr0 > amrd0: 559600MB (1146060800 sectors) RAID 5 (optimal) > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > Trying to mount root from ufs:/dev/amrd0s1a > fire_saver: the console does not support M_VGA_CG320 > module_register_init: MOD_LOAD (fire_saver, 0xc8d50c10, 0) error 19 > > _______________________________________________ > 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 Dec 17 10:59:19 2007 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 C50E916A420; Mon, 17 Dec 2007 10:59:19 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id B390513C45A; Mon, 17 Dec 2007 10:59:19 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBHAOY1Y046966; Mon, 17 Dec 2007 02:24:34 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBHAOX2L046965; Mon, 17 Dec 2007 02:24:33 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Mon, 17 Dec 2007 02:24:33 -0800 From: David G Lawrence To: Mark Fullmer Message-ID: <20071217102433.GQ25053@tnn.dglawrence.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Mon, 17 Dec 2007 02:24:34 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 17 Dec 2007 10:59:19 -0000 > While trying to diagnose a packet loss problem in a RELENG_6 snapshot > dated > November 8, 2007 it looks like I've stumbled across a broken driver or > kernel routine which stops interrupt processing long enough to severly > degrade network performance every 30.99 seconds. I noticed this as well some time ago. The problem has to do with the processing (syncing) of vnodes. When the total number of allocated vnodes in the system grows to tens of thousands, the ~31 second periodic sync process takes a long time to run. Try this patch and let people know if it helps your problem. It will periodically wait for one tick (1ms) every 500 vnodes of processing, which will allow other things to run. Index: ufs/ffs/ffs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.290.2.16 diff -c -r1.290.2.16 ffs_vfsops.c *** ufs/ffs/ffs_vfsops.c 9 Oct 2006 19:47:17 -0000 1.290.2.16 --- ufs/ffs/ffs_vfsops.c 25 Apr 2007 01:58:15 -0000 *************** *** 1109,1114 **** --- 1109,1115 ---- int softdep_deps; int softdep_accdeps; struct bufobj *bo; + int flushed_count = 0; fs = ump->um_fs; if (fs->fs_fmod != 0 && fs->fs_ronly != 0) { /* XXX */ *************** *** 1174,1179 **** --- 1175,1184 ---- allerror = error; vput(vp); MNT_ILOCK(mp); + if (flushed_count++ > 500) { + flushed_count = 0; + msleep(&flushed_count, MNT_MTX(mp), PZERO, "syncw", 1); + } } MNT_IUNLOCK(mp); /* -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 11:21:30 2007 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 F19DC16A417 for ; Mon, 17 Dec 2007 11:21:30 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 02EA613C447 for ; Mon, 17 Dec 2007 11:21:30 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id D48511CC079; Mon, 17 Dec 2007 03:21:30 -0800 (PST) Date: Mon, 17 Dec 2007 03:21:30 -0800 From: Jeremy Chadwick To: Marian Hettwer Message-ID: <20071217112130.GA25140@eos.sc1.parodius.com> References: <6d41e00a0d0deb2e305b1a4f86b9c601@127.0.0.1> <20071213205053.GA10017@eos.sc1.parodius.com> <47665299.4050208@kernel32.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47665299.4050208@kernel32.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 BETA4 no serial console 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, 17 Dec 2007 11:21:31 -0000 On Mon, Dec 17, 2007 at 11:42:33AM +0100, Marian Hettwer wrote: >> Change this to -S9600 -Dh, and remove the lines from /boot/loader.conf. >> > did that. > Still no login prompt via serial console. Although my getty is running: > > More hints on what's going on? :) The only other thing I can think of would be an improperly wired serial adapter or serial cable. It's been a while since I've messed with serial wiring, but I believe DSR/DCD not being tied to DTR on the DB9 female connector (which connects to the PC) could cause this. This applies to getty specifically, I believe. I'd try replacing the std.9600 part of /etc/ttys with 3wire.9600 and doing an "init q", or a reboot. You can compare the two by looking at /etc/gettytab and the gettytab(5) manpage. If that doesn't work, can you set ttyd0 to off in /etc/ttys, reboot, and after the box comes back up do `stty -a -f /dev/ttyd0` ? Regarding wiring -- DB25-to-DB9 and DB9-to-DB9 wiring diagrams are here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html#SERIAL-CABLES-PORTS For RJ45-to-DB9, it's "worse" since it often depends upon what kind of device (model/brand) drives the RJ45 port. In the case of Xyplex or MRV InReach products, the following wiring diagram works perfectly (I know because we use it) with standard CAT5 cables (not crossover), and does proper hardware flow control: RJ45 DB9 Female Female =========== ======= (CTS) 1 <----> 7 (RTS) (DTR) 2 <----> 6 (DSR) (TxD) 3 <----> 2 (RxD) (TxD GND) 4 <----> 5 (GND) (RxD GND) 5 <----> 5 (GND) (RxD) 6 <----> 3 (TxD) (DSR/DCD) 7 <----> 4 (DTR) (RTS) 8 <----> 8 (CTS) Pins 1 (DCD) and 9 (RI) on the DB9 are unconnected/unused. These adapters are often labelled as part no. XFDCE91. www.apacn.com sells them. -- | Jeremy Chadwick jdc at 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 Dec 17 11:50:03 2007 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 6C51316A41B; Mon, 17 Dec 2007 11:50:03 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF9D13C469; Mon, 17 Dec 2007 11:50:02 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from [10.38.0.12] (unknown [194.50.70.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTP id 312ADB0281; Mon, 17 Dec 2007 12:50:01 +0100 (CET) Message-ID: <4766626F.8030606@kernel32.de> Date: Mon, 17 Dec 2007 12:50:07 +0100 From: Marian Hettwer User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Jeremy Chadwick References: <6d41e00a0d0deb2e305b1a4f86b9c601@127.0.0.1> <20071213205053.GA10017@eos.sc1.parodius.com> <47665299.4050208@kernel32.de> <20071217112130.GA25140@eos.sc1.parodius.com> In-Reply-To: <20071217112130.GA25140@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 BETA4 no serial console 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, 17 Dec 2007 11:50:03 -0000 Jeremy Chadwick schrieb: > On Mon, Dec 17, 2007 at 11:42:33AM +0100, Marian Hettwer wrote: > >>> Change this to -S9600 -Dh, and remove the lines from /boot/loader.conf. >>> >>> >> did that. >> Still no login prompt via serial console. Although my getty is running: >> >> More hints on what's going on? :) >> > > The only other thing I can think of would be an improperly wired serial > adapter or serial cable. It's been a while since I've messed with > serial wiring, but I believe DSR/DCD not being tied to DTR on the DB9 > female connector (which connects to the PC) could cause this. This > applies to getty specifically, I believe. > > hm... I don't think thats the case, since I'm able to see the whole bootprocess of this box. The only thing missing is my login prompt ;) Additionally, this is a HP Blade with iLo, so it's just a "emulated" serial port. No adapters or wiring there. > I'd try replacing the std.9600 part of /etc/ttys with 3wire.9600 and > doing an "init q", or a reboot. You can compare the two by looking at > /etc/gettytab and the gettytab(5) manpage. > > I did a kill -HUP 1 to have them paramters changed. The 3write makes no different to std.9600 marian46-23# ps ax | grep ttyd 1067 ?? I 0:00.00 /usr/libexec/getty 3wire.9600 ttyd1 1068 d0 Is+ 0:00.00 /usr/libexec/getty 3wire.9600 ttyd0 > If that doesn't work, can you set ttyd0 to off in /etc/ttys, reboot, > and after the box comes back up do `stty -a -f /dev/ttyd0` ? > > Okay, it's off now: marian46-23# ps ax | grep ttyd 1083 p1 R+ 0:00.00 grep ttyd marian46-23# stty -a -f /dev/ttyd0 speed 9600 baud; 0 rows; 0 columns; lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk brkint -inpck -ignpar -parmrk oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ; eol2 = ; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; hm... I'm not sure what to do with those informations ;) Ideas left anyone? It's really really strange that I can see the whole boot process but don't have a login prompt in the end. strange. regards, Marian From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 12:46:32 2007 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 2ED9A16A420 for ; Mon, 17 Dec 2007 12:46:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [82.208.36.70]) by mx1.freebsd.org (Postfix) with ESMTP id C317413C448 for ; Mon, 17 Dec 2007 12:46:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id EC9EC19E023; Mon, 17 Dec 2007 13:46:30 +0100 (CET) Received: from [192.168.1.2] (r3a200.net.upc.cz [213.220.192.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id 7465319E019; Mon, 17 Dec 2007 13:46:24 +0100 (CET) Message-ID: <47666FBA.1040606@quip.cz> Date: Mon, 17 Dec 2007 13:46:50 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: =?KOI8-R?Q?=ED=C9=C8=C1=C9=CC_=EB=C9=D0=C1?= References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0beta4 panic on ftp transfer 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, 17 Dec 2007 12:46:32 -0000 íÉÈÁÉÌ ëÉÐÁ wrote: > SO I have 7.0beta4 on my server. My HDD have such configuration: > > ad4: 476940MB at ata2-master SATA300 > ad6: 476940MB at ata3-master SATA300 > ad10: 152627MB at ata5-master SATA150 > ad12: 152627MB at ata6-master SATA150 > ar0: 476928MB status: READY > ar0: disk0 READY (master) using ad4 at ata2-master > ar0: disk1 READY (mirror) using ad6 at ata3-master > ar1: 152627MB status: READY > ar1: disk0 READY (master) using ad10 at ata5-master > ar1: disk1 READY (mirror) using ad12 at ata6-master > SMP: AP CPU #1 Launched! > > > During ftp transfer (among 10GB to server) I have kernel panic and reboon wiht > such log messages: [...] > Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE > taskqueue timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE > taskqueue timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue > timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue > timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad4: WARNING - SET_MULTI taskqueue timeout - > completing request directly > Dec 17 01:49:17 SERVER kernel: ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) > LBA=211491863 > Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE > taskqueue timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE > taskqueue timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue > timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue > timeout - completing request directly > Dec 17 01:49:17 SERVER kernel: ad6: WARNING - SET_MULTI taskqueue timeout - > completing request directly > Dec 17 01:49:17 SERVER kernel: ad6: FAILURE - WRITE_DMA timed out LBA=211491607 > Dec 17 01:49:17 SERVER kernel: ad4: WARNING - WRITE_DMA taskqueue timeout - > completing request directly > Dec 17 01:49:17 SERVER kernel: ad6: WARNING - WRITE_DMA taskqueue timeout - > completing request directly > Dec 17 01:49:17 SERVER kernel: > Dec 17 01:49:17 SERVER kernel: > Dec 17 01:49:17 SERVER kernel: Fatal trap 12: page fault while in kernel mode > Dec 17 01:49:17 SERVER kernel: cpuid = 0; apic id = 00 > Dec 17 01:49:17 SERVER kernel: fault virtual address = 0x18 > Dec 17 01:49:17 SERVER kernel: fault code = supervisor read data, > page not present > Dec 17 01:49:17 SERVER kernel: instruction pointer = 0x8:0xffffffff80221bec > Dec 17 01:49:17 SERVER kernel: stack pointer = 0x10:0xffffffffab692af0 > Dec 17 01:49:17 SERVER kernel: frame pointer = 0x10:0xffffff0029b72bd0 > Dec 17 01:49:17 SERVER kernel: code segment = base 0x0, limit 0xfffff, > type 0x1b > Dec 17 01:49:17 SERVER kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > Dec 17 01:49:17 SERVER kernel: processor eflags = interrupt enabled, resume, IOPL > = 0 > Dec 17 01:49:17 SERVER kernel: current process = 17 (swi6: task queue) > Dec 17 01:49:17 SERVER kernel: trap number = 12 > Dec 17 01:49:17 SERVER kernel: panic: page fault > Dec 17 01:49:17 SERVER kernel: cpuid = 0 > Dec 17 01:49:17 SERVER kernel: Uptime: 3d5h9m56s > > ad4 and ad6 is my mirror RAID on which I try to write! > Anyone can explain to what does it mean??? > Mihail From my experience - it is caused by poor onboard HTT/RAID controller, failing HDD or SATA cables. Try another pair of cables, check HDD with smartmontools (from ports tree), or try to switch from ataraid to gmirror. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 12:51:43 2007 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 E2CA616A420 for ; Mon, 17 Dec 2007 12:51:43 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id E71C513C4E5 for ; Mon, 17 Dec 2007 12:51:43 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id BA4F01CC079; Mon, 17 Dec 2007 04:51:43 -0800 (PST) Date: Mon, 17 Dec 2007 04:51:43 -0800 From: Jeremy Chadwick To: Marian Hettwer Message-ID: <20071217125143.GA27007@eos.sc1.parodius.com> References: <6d41e00a0d0deb2e305b1a4f86b9c601@127.0.0.1> <20071213205053.GA10017@eos.sc1.parodius.com> <47665299.4050208@kernel32.de> <20071217112130.GA25140@eos.sc1.parodius.com> <4766626F.8030606@kernel32.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4766626F.8030606@kernel32.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 BETA4 no serial console 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, 17 Dec 2007 12:51:44 -0000 On Mon, Dec 17, 2007 at 12:50:07PM +0100, Marian Hettwer wrote: > marian46-23# stty -a -f /dev/ttyd0 > speed 9600 baud; 0 rows; 0 columns; > lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl > -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo > -extproc > iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk > brkint -inpck -ignpar -parmrk > oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret > cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow > -dtrflow -mdmbuf > cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ; > eol2 = ; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; > lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; > status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; > > hm... Identical to ours... Well, the reason you'd get boot messages and kernel output would be that neither of those (AFIAK) bothers to check for things like DTR/DSR and DCD. getty, on the other hand, does. That's what makes me think it might be a cabling or adapter issue. The 3wire.9600 test, I assume, should've worked though... > It's really really strange that I can see the whole boot process but don't > have a login prompt in the end. strange. Has this box been "upgraded" from RELENG_6 or anything like that? I remember encountering a situation with one of our RELENG_6 boxes where serial console would work fine up until the point of getting a login prompt via getty, which never worked. Rebuilding kernel + world fixed the problem (time delta between kernel/world builds was over 100 days, and during that time I'm sure there were serial console changes). -- | Jeremy Chadwick jdc at 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 Dec 17 13:00:21 2007 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 7932C16A417; Mon, 17 Dec 2007 13:00:21 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4C26713C43E; Mon, 17 Dec 2007 13:00:20 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from [10.38.0.12] (unknown [194.50.70.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTP id 9A1F2B0281; Mon, 17 Dec 2007 14:00:19 +0100 (CET) Message-ID: <476672E8.6010503@kernel32.de> Date: Mon, 17 Dec 2007 14:00:24 +0100 From: Marian Hettwer User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Jeremy Chadwick References: <6d41e00a0d0deb2e305b1a4f86b9c601@127.0.0.1> <20071213205053.GA10017@eos.sc1.parodius.com> <47665299.4050208@kernel32.de> <20071217112130.GA25140@eos.sc1.parodius.com> <4766626F.8030606@kernel32.de> <20071217125143.GA27007@eos.sc1.parodius.com> In-Reply-To: <20071217125143.GA27007@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 BETA4 no serial console 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, 17 Dec 2007 13:00:21 -0000 Hi Ho, Jeremy Chadwick schrieb: > On Mon, Dec 17, 2007 at 12:50:07PM +0100, Marian Hettwer wrote: > >> marian46-23# stty -a -f /dev/ttyd0 >> speed 9600 baud; 0 rows; 0 columns; >> lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl >> -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo >> -extproc >> iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk >> brkint -inpck -ignpar -parmrk >> oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret >> cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow >> -dtrflow -mdmbuf >> cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ; >> eol2 = ; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; >> lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; >> status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; >> >> hm... >> > > Identical to ours... > > Well, the reason you'd get boot messages and kernel output would be that > neither of those (AFIAK) bothers to check for things like DTR/DSR and > DCD. getty, on the other hand, does. That's what makes me think it > might be a cabling or adapter issue. The 3wire.9600 test, I assume, > should've worked though... > > Well, I enabled the 2wirte.9600 test via "kill -HUP 1". And according to my processlist, getty was running with 3wire.9600. I could try to reboot, although this should make a difference at all. >> It's really really strange that I can see the whole boot process but don't >> have a login prompt in the end. strange. >> > > Has this box been "upgraded" from RELENG_6 or anything like that? I > remember encountering a situation with one of our RELENG_6 boxes where > serial console would work fine up until the point of getting a login > prompt via getty, which never worked. Rebuilding kernel + world fixed > the problem (time delta between kernel/world builds was over 100 days, > and during that time I'm sure there were serial console changes). > > Nope, my installation was built from source via "make buildworld TARGET_ARCH=amd64", afterwards pxebooted the box and copied my nfsroot to hard disk and then booted of hard disk. I can't think of a mistake in that process. thats really odd. hhmm... I cvsup today to RELENG_7 and give make buildworld another go. regards, Marian From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 13:37:07 2007 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 5366816A418 for ; Mon, 17 Dec 2007 13:37:07 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-04.prod.mesa1.secureserver.net [64.202.165.17]) by mx1.freebsd.org (Postfix) with SMTP id 306AC13C4CC for ; Mon, 17 Dec 2007 13:37:06 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 21509 invoked from network); 17 Dec 2007 13:37:06 -0000 Received: from unknown (24.144.77.185) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 17 Dec 2007 13:37:06 -0000 Message-ID: <47667B82.80306@seclark.us> Date: Mon, 17 Dec 2007 08:37:06 -0500 From: Stephen Clark User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IP Filter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2007 13:37:07 -0000 Hello List, Can someone tell me why ipf_nattable_max is not a sysctl variable. The only way to change this currently is via a edit the source and rebuild. It looks like it would be as simple as adding: SYSCTL_IPF(_net_inet_ipf, OID_AUTO, pf_nattable_max, CTLFLAG_RWO, &ipf_nattable_max, 0, ""); to mlfk_ipl.c Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 13:42:40 2007 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 5400716A420 for ; Mon, 17 Dec 2007 13:42:40 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id B6A6713C468 for ; Mon, 17 Dec 2007 13:42:39 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 17 Dec 2007 13:42:37 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO homeKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp005) with SMTP; 17 Dec 2007 14:42:37 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX185yn5D0PA51gauRfpxQM0Orlh1WzegzizzE9yFNL 452WWq6MLkdyDw Message-ID: <47667CC5.8040509@gmx.de> Date: Mon, 17 Dec 2007 14:42:29 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20071203) MIME-Version: 1.0 To: Ariff Abdullah References: <476053BB.2000806@gmx.de> <20071213080609.6c028849.ariff@FreeBSD.org> <476182FB.1040206@gmx.de> <20071214074231.1c3082bc.ariff@FreeBSD.org> In-Reply-To: <20071214074231.1c3082bc.ariff@FreeBSD.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 vchans broken Maestro 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, 17 Dec 2007 13:42:40 -0000 Ariff Abdullah wrote: > On Thu, 13 Dec 2007 20:07:39 +0100 > Dominic Fandrey wrote: >> Ariff Abdullah wrote: >>> On Wed, 12 Dec 2007 22:33:47 +0100 >>> Dominic Fandrey wrote: >>>> Since the switch to BETA4 (it might actually have happened >>> earlier > and I didn't recognize) vchans don't work properly >>> anymore (for me). > >>>> Instead of hearing a second source there only gets a lot of noise >>>> mixed into the first audio stream. >>>> >>> Try changing AGG_MAXPLAYCH from 4 to 1 >>> (around line 80, sys/dev/sound/pci/maestro.c). >>> >> That fixes my problem. Will this be changed or will I always have to >> do this myself? > > It will be changed. In the meantime, try playing with the above #def, > say like setting it to 2 or 3. 3 seems to work fine. I tested it with 4 simultaneous audio streams. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 17:57:21 2007 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 CF1CC16A41B for ; Mon, 17 Dec 2007 17:57:21 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 969BE13C45D for ; Mon, 17 Dec 2007 17:57:21 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 54024 invoked from network); 17 Dec 2007 17:57:20 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 17 Dec 2007 17:57:20 -0000 In-Reply-To: <20071217054305.GA18268@eos.sc1.parodius.com> References: <20071217054305.GA18268@eos.sc1.parodius.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Mon, 17 Dec 2007 12:57:05 -0500 To: Jeremy Chadwick X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 17 Dec 2007 17:57:21 -0000 Back to back test with no ethernet switch between two em interfaces, same result. The receiving side has been up > 1 day and exhibits the problem. These are also two different servers. The small gettimeofday() syscall tester also shows the same ~30 second pattern of high latency between syscalls. Receiver test application reports 3699 missed packets Sender netstat -i: (before test) em1 1500 00:04:23:cf:51:b7 20 0 15975785 0 0 em1 1500 10.1/24 10.1.0.2 37 - 15975801 - - (after test) em1 1500 00:04:23:cf:51:b7 22 0 25975822 0 0 em1 1500 10.1/24 10.1.0.2 39 - 25975838 - - total IP packets sent in during test = end - start 25975838-15975801 = 10000037 (expected, 1,000,000 packets test + overhead) Receiver netstat -i: (before test) em1 1500 00:04:23:c4:cc:89 15975785 0 21 0 0 em1 1500 10.1/24 10.1.0.1 15969626 - 19 - - (after test) em1 1500 00:04:23:c4:cc:89 25975822 0 23 0 0 em1 1500 10.1/24 10.1.0.1 25965964 - 21 - - total ethernet frames received during test = end - start 25975822-15975785 = 10000037 (as expected) total IP packets processed during test = end - start 25965964-15969626 = 9996338 (expecting 10000037) Missed packets = expected - received 10000037-9996338 = 3699 netstat -i accounts for the 3699 missed packets also reported by the application Looking closer at the tester output again shows the periodic ~30 second windows of packet loss. There's a second problem here in that packets are just disappearing before they make it to ip_input(), or there's a dropped packets counter I've not found yet. I can provide remote access to anyone who wants to take a look, this is very easy to duplicate. The ~ 1 day uptime before the behavior surfaces is not making this easy to isolate. -- mark On Dec 17, 2007, at 12:43 AM, Jeremy Chadwick wrote: > On Mon, Dec 17, 2007 at 12:21:43AM -0500, Mark Fullmer wrote: >> While trying to diagnose a packet loss problem in a RELENG_6 >> snapshot dated >> November 8, 2007 it looks like I've stumbled across a broken >> driver or >> kernel routine which stops interrupt processing long enough to >> severly >> degrade network performance every 30.99 seconds. >> >> Packets appear to make it as far as ether_input() then get lost. > > Are you sure this isn't being caused by something the switch is doing, > such as MAC/ARP cache clearing or LACP? I'm just speculating, but it > would be worthwhile to remove the switch from the picture (crossover > cable to the rescue). > > I know that at least in the case of fxp(4) and em(4), Jack Vogel does > some through testing of throughput using a professional/high-end > packet > generator (some piece of hardware, I forget the name...) > > -- > | Jeremy Chadwick jdc at > parodius.com | > | Parodius Networking http:// > www.parodius.com/ | > | UNIX Systems Administrator Mountain View, > CA, USA | > | Making life hard for others since 1977. PGP: > 4BD6C0CB | > > _______________________________________________ > 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 Dec 17 18:08:56 2007 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 6109216A419 for ; Mon, 17 Dec 2007 18:08:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 26F1113C455 for ; Mon, 17 Dec 2007 18:08:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 36B24EBB81C; Tue, 18 Dec 2007 02:08:55 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id Gz3lmMLQzsBX; Tue, 18 Dec 2007 02:08:50 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 1EFD0EBB810; Tue, 18 Dec 2007 02:08:49 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=DV+tNINihhviPJQLfwt0Y2yOEEx11HX+0Hsn1ciDbI9i5qt9Q9oifD8vLDu8e0FIV MhjgrUfjsYRegR7KWpBlQ== Message-ID: <4766BB30.9000103@delphij.net> Date: Mon, 17 Dec 2007 10:08:48 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: Subject: ZFS stuck in zfs:&buf_hash_table.ht_locks[i].ht_lock] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2007 18:08:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It seems that with a lot of file on ZFS (used as / but I don't think this would make change) w/ compression configuration, the nightly locate(8) scan would finally cause the box to enter a livelock/deadlock where locate would stuck in 'zfs:lo' state, and new process accessing the file system would stuck in 'zfs:&buf_hash_table.ht_locks[i].ht_lock]'. Is this a known issue (any workaround)? This is a production box without serial port, and is several miles away from me, but I will try to provide some debugging aid if necessary. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHZrswhcUczkLqiksRAlbQAJ96llqty5JzasitfaEvFXeRzKYuGACg2L7H xJcPPYmu1AwgMAT56JdwSPg= =SEG+ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 18:45:30 2007 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 2FC2C16A418 for ; Mon, 17 Dec 2007 18:45:30 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id E5D1F13C44B for ; Mon, 17 Dec 2007 18:45:29 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 4F14239D1F for ; Mon, 17 Dec 2007 19:26:19 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJHsvo5pEJKO for ; Mon, 17 Dec 2007 19:26:16 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id E0F4939D17; Mon, 17 Dec 2007 19:26:16 +0100 (CET) Date: Mon, 17 Dec 2007 19:26:16 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20071217182616.GA58000@keltia.freenix.fr> References: <47667B82.80306@seclark.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47667B82.80306@seclark.us> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.15 (2007-04-06) Subject: Re: IP Filter 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, 17 Dec 2007 18:45:30 -0000 According to Stephen Clark: > It looks like it would be as simple as adding: > SYSCTL_IPF(_net_inet_ipf, OID_AUTO, pf_nattable_max, CTLFLAG_RWO, > &ipf_nattable_max, 0, ""); Isn't the "pf_nattable_max" a typo for "ipf_nattable_max"? BTW, talk to Darren Reed about that, he is the author and ipf is contributed software :) Cheers, -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 8.10.1: Wed May 23 16:33:00 PDT 2007 i386 From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 18:58:50 2007 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 5A92116A418 for ; Mon, 17 Dec 2007 18:58:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id EE59913C4E9 for ; Mon, 17 Dec 2007 18:58:49 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-064-191-210.pools.arcor-ip.net [88.64.191.210]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1J4LAs3cB9-0001fz; Mon, 17 Dec 2007 19:58:47 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Mon, 17 Dec 2007 19:58:30 +0100 User-Agent: KMail/1.9.7 References: <47667B82.80306@seclark.us> <20071217182616.GA58000@keltia.freenix.fr> In-Reply-To: <20071217182616.GA58000@keltia.freenix.fr> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1369190.Ihs7xmcq2W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712171958.44094.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/K484lJtzancBxYnWwOAVaKjR3VgaRbD2HJOm Mab1Z6qCHoKkSXJlm/YIIHD1ktTPlYCEwrre09fxLj2G443j+g 6e1lJidD/30EQrJlL3CmXGRlqGKRmsQnnkbbp9YXkI= Cc: Subject: Re: IP Filter 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, 17 Dec 2007 18:58:50 -0000 --nextPart1369190.Ihs7xmcq2W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 17 December 2007, Ollivier Robert wrote: > According to Stephen Clark: > > It looks like it would be as simple as adding: > > SYSCTL_IPF(_net_inet_ipf, OID_AUTO, pf_nattable_max, CTLFLAG_RWO, > > &ipf_nattable_max, 0, ""); > > Isn't the "pf_nattable_max" a typo for "ipf_nattable_max"? > > BTW, talk to Darren Reed about that, he is the author and ipf is > contributed software :) > > Cheers, # ipf -T list =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1369190.Ihs7xmcq2W Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHZsbkXyyEoT62BG0RAo/bAJ9YrQnl1A9TlDIOeENavQFnf+XHyQCfdtBk nlFgIqLU9Aq1+wV+8Ku/2M0= =RLCF -----END PGP SIGNATURE----- --nextPart1369190.Ihs7xmcq2W-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 21:55:42 2007 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 7B47016A417 for ; Mon, 17 Dec 2007 21:55:42 +0000 (UTC) (envelope-from morphalus@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 15B7813C4CE for ; Mon, 17 Dec 2007 21:55:41 +0000 (UTC) (envelope-from morphalus@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so368199fgg.35 for ; Mon, 17 Dec 2007 13:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; bh=JTLON1ZUL99aEL8tMznKEnx4nsNe+x1o8gjNf1nsxsY=; b=xJRNYz7578VhV3wbhLflmPDZBSLdn9PgdOb/Vkt5YhE3QnNjE4AT5cwTo44TLiLw1SKAQMVage0WXUFA/vrLPa4+aWK8FJ8qoKNQXxk8mOzUsISmYt4fPmsjwBm494EvPlQZ9Ro/jbfkGd/llKkp6oMQRdGvKcJ/J1UXPQTO6j8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=RRhm8tE+hPdUMuG66YO5XCTRdeNa51f9u4fA9Pf3K7JyiJJErV7C8WdhnLHp/vZDBNaXPGZ8cTgQ4pjzD2PyGuycwi8bQRHM2TIJZhh3CUjsVEVssg6kqSBxL6oJvmw+433H00yT3QCs9XjfkjWdGwfNY74FVZ/3ZHehZuM1q8A= Received: by 10.86.50.8 with SMTP id x8mr6886988fgx.25.1197926896910; Mon, 17 Dec 2007 13:28:16 -0800 (PST) Received: from localhost.localdomain ( [77.202.166.30]) by mx.google.com with ESMTPS id 4sm7331330fgg.2007.12.17.13.28.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2007 13:28:16 -0800 (PST) Date: Mon, 17 Dec 2007 22:28:06 +0100 From: Fabien Degomme To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20071217222806.4dfd1312@gmail.com> X-Mailer: Claws Mail 3.1.0 (GTK+ 2.12.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Motherboard Asus P5N-E SLI compatibility with FreeBSD 7 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, 17 Dec 2007 21:55:42 -0000 Hi, my question is about the Asus P5N-E SLI motherboard. I searched if this MB is compatible with FreeBSD 7 but I don't have concrete answer. So I just want to know if anyone owns this card with FreeBSD 6 or 7 and if it works well. Thanks in advance :) morphalus From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 00:11:00 2007 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 1539316A41B; Tue, 18 Dec 2007 00:11:00 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id A63AF13C44B; Tue, 18 Dec 2007 00:10:59 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-064-182-010.pools.arcor-ip.net [88.64.182.10]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1J4Q2y2g3e-0007WG; Tue, 18 Dec 2007 01:10:57 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Tue, 18 Dec 2007 01:11:15 +0100 User-Agent: KMail/1.9.7 References: <20071217222806.4dfd1312@gmail.com> In-Reply-To: <20071217222806.4dfd1312@gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6886501.qPUtRedebj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712180111.21928.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+8DaGBzYyhfam4GCmx9jbWtL4e4j8d2O+5kGH RRFDTpwvvNCJcIG/mvn8Ke5MNHgmbBoPAZdOcP/u4+jRY1FmJp sDLgP62MrQ57jKRZGCX4Ch4HaMI10RoJZAtlyanPE4= Cc: Fabien Degomme , freebsd-current@freebsd.org Subject: Re: Motherboard Asus P5N-E SLI compatibility with FreeBSD 7 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, 18 Dec 2007 00:11:00 -0000 --nextPart6886501.qPUtRedebj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 17 December 2007, Fabien Degomme wrote: > Hi, > > my question is about the Asus P5N-E SLI motherboard. I searched if > this MB is compatible with FreeBSD 7 but I don't have concrete > answer. > > So I just want to know if anyone owns this card with FreeBSD 6 > or 7 and if it works well. > > Thanks in advance :) Last time I checked there was something wrong with the apic. =20 hint.apic.0.disabled=3D1 from the loader got it booting and working well,=20 but you loose SMP. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart6886501.qPUtRedebj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHZxApXyyEoT62BG0RAk9bAJ95nI4OCQZH+e2p+9TPwqhVuy2qJQCfeNIb pP1yCnm+9NmgLucLfcngBJ8= =a8cR -----END PGP SIGNATURE----- --nextPart6886501.qPUtRedebj-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 01:59:23 2007 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 D016B16A417; Tue, 18 Dec 2007 01:59:23 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3F89913C461; Tue, 18 Dec 2007 01:59:18 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from epia-2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id 30563DF073; Tue, 18 Dec 2007 02:59:16 +0100 (CET) Date: Tue, 18 Dec 2007 02:59:14 +0100 From: cpghost To: Julian Elischer Message-ID: <20071218025914.3e4f1930@epia-2.farid-hajji.net> In-Reply-To: <475C65B7.20708@elischer.org> References: <20071206030500.746c782d@epia-2.farid-hajji.net> <4757E39C.8020009@FreeBSD.org> <20071206161107.3c0c9a82@epia-2.farid-hajji.net> <20071209173359.710ea5bd@epia-2.farid-hajji.net> <475C3E49.6000906@elischer.org> <20071209215808.68c22b2c@epia-2.farid-hajji.net> <475C65B7.20708@elischer.org> Organization: Cordula's Web X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Brian, Alexander Motin , freebsd-stable@freebsd.org, Somers Subject: Re: "no matching session" in ng_pppoe.c 1.74.2.4? (RELENG_6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 01:59:23 -0000 On Sun, 09 Dec 2007 14:01:27 -0800 Julian Elischer wrote: > cpghost wrote: > > On Sun, 09 Dec 2007 11:13:13 -0800 > > Julian Elischer wrote: > > > >>> ----------- manually restarting ppp(1), then: > >>> ------------------------ > >>> > >>> 17:10:47.306928 00:00:24:c2:45:74 > ff:ff:ff:ff:ff:ff, ethertype > >>> PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] > >>> [Service-Name] > >>> > >>> 17:10:47.306939 00:00:24:c2:45:74 > ff:ff:ff:ff:ff:ff, ethertype > >>> PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] > >>> [Service-Name] > >>> > >> we still have 2 sessions instead of 1, but there is less confusion > >> so things sort themselves out. > > > > Just one more thing: > > > > If I remember correctly, sending two PADIs in quick succession > > was ppp's "normal" behaviour for *years* now (is it expected or > > required by the protocol? I don't know). I've always wondered > > why it was so. But that didn't cause any harm as it seemed one > > of the two PADO was picked up and eventually turned into a session. > > > > -cpghost. > > > > btw try mpd as well. So... I'm running net/mpd5 on that router for a few days now, and it managed 3 forced disconnects in a row and no session chaos at all, while ppp(8) would probably have initiated a lot of parallel sessions again but no connection. So up until now (but perhaps it's too early to be sure?), net/mpd5 is fine, while ppp(8) is not. Btw, I've compared the sources of ppp(8) from 2007-09-24/25 when it was still working, and 2007-11-30 when I've updated the router, and there's NO difference there at all. Whatever broke ppp(8), it was not ppp(8) but something else (I suspect ng_pppoe.c): maybe the code clean up exposed some hidden bug in ppp(8)? I hope ppp(8) will be fixed before 6.3-RELEASE; even though net/mpd5 is excellent and very snappy as well. ;-) Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 02:04:38 2007 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 2BE3C16A41A for ; Tue, 18 Dec 2007 02:04:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1669D13C45D for ; Tue, 18 Dec 2007 02:04:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 17 Dec 2007 18:04:37 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 64193126CEE; Mon, 17 Dec 2007 18:04:36 -0800 (PST) Message-ID: <47672AB3.2020206@elischer.org> Date: Mon, 17 Dec 2007 18:04:35 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: cpghost References: <20071206030500.746c782d@epia-2.farid-hajji.net> <4757E39C.8020009@FreeBSD.org> <20071206161107.3c0c9a82@epia-2.farid-hajji.net> <20071209173359.710ea5bd@epia-2.farid-hajji.net> <475C3E49.6000906@elischer.org> <20071209215808.68c22b2c@epia-2.farid-hajji.net> <475C65B7.20708@elischer.org> <20071218025914.3e4f1930@epia-2.farid-hajji.net> In-Reply-To: <20071218025914.3e4f1930@epia-2.farid-hajji.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brian Somers , Alexander Motin , freebsd-stable@freebsd.org Subject: Re: "no matching session" in ng_pppoe.c 1.74.2.4? (RELENG_6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 02:04:38 -0000 cpghost wrote: > On Sun, 09 Dec 2007 14:01:27 -0800 > Julian Elischer wrote: > >> cpghost wrote: >>> On Sun, 09 Dec 2007 11:13:13 -0800 >>> Julian Elischer wrote: >>> >>>>> ----------- manually restarting ppp(1), then: >>>>> ------------------------ >>>>> >>>>> 17:10:47.306928 00:00:24:c2:45:74 > ff:ff:ff:ff:ff:ff, ethertype >>>>> PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] >>>>> [Service-Name] >>>>> >>>>> 17:10:47.306939 00:00:24:c2:45:74 > ff:ff:ff:ff:ff:ff, ethertype >>>>> PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] >>>>> [Service-Name] >>>>> >>>> we still have 2 sessions instead of 1, but there is less confusion >>>> so things sort themselves out. >>> Just one more thing: >>> >>> If I remember correctly, sending two PADIs in quick succession >>> was ppp's "normal" behaviour for *years* now (is it expected or >>> required by the protocol? I don't know). I've always wondered >>> why it was so. But that didn't cause any harm as it seemed one >>> of the two PADO was picked up and eventually turned into a session. >>> >>> -cpghost. >>> >> btw try mpd as well. > > So... I'm running net/mpd5 on that router for a few days now, and > it managed 3 forced disconnects in a row and no session chaos at > all, while ppp(8) would probably have initiated a lot of parallel > sessions again but no connection. > > So up until now (but perhaps it's too early to be sure?), > net/mpd5 is fine, while ppp(8) is not. > > Btw, I've compared the sources of ppp(8) from 2007-09-24/25 > when it was still working, and 2007-11-30 when I've updated > the router, and there's NO difference there at all. Whatever > broke ppp(8), it was not ppp(8) but something else > (I suspect ng_pppoe.c): maybe the code clean up exposed > some hidden bug in ppp(8)? > > I hope ppp(8) will be fixed before 6.3-RELEASE; even though > net/mpd5 is excellent and very snappy as well. ;-) mpd is also using ng_pppoe of course. > > Regards, > -cpghost. > From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 03:37:42 2007 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 9021016A41B for ; Tue, 18 Dec 2007 03:37:42 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 4A8B513C45B for ; Tue, 18 Dec 2007 03:37:42 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 42358 invoked from network); 18 Dec 2007 03:37:41 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 18 Dec 2007 03:37:41 -0000 In-Reply-To: <20071217102433.GQ25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Mon, 17 Dec 2007 22:37:25 -0500 To: David G Lawrence X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 03:37:42 -0000 Thanks. Have a kernel building now. It takes about a day of uptime after reboot before I'll see the problem. -- mark On Dec 17, 2007, at 5:24 AM, David G Lawrence wrote: >> While trying to diagnose a packet loss problem in a RELENG_6 snapshot >> dated >> November 8, 2007 it looks like I've stumbled across a broken >> driver or >> kernel routine which stops interrupt processing long enough to >> severly >> degrade network performance every 30.99 seconds. > > I noticed this as well some time ago. The problem has to do with > the > processing (syncing) of vnodes. When the total number of allocated > vnodes > in the system grows to tens of thousands, the ~31 second periodic sync > process takes a long time to run. Try this patch and let people > know if > it helps your problem. It will periodically wait for one tick (1ms) > every > 500 vnodes of processing, which will allow other things to run. > > Index: ufs/ffs/ffs_vfsops.c > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v > retrieving revision 1.290.2.16 > diff -c -r1.290.2.16 ffs_vfsops.c > *** ufs/ffs/ffs_vfsops.c 9 Oct 2006 19:47:17 -0000 1.290.2.16 > --- ufs/ffs/ffs_vfsops.c 25 Apr 2007 01:58:15 -0000 > *************** > *** 1109,1114 **** > --- 1109,1115 ---- > int softdep_deps; > int softdep_accdeps; > struct bufobj *bo; > + int flushed_count = 0; > > fs = ump->um_fs; > if (fs->fs_fmod != 0 && fs->fs_ronly != 0) { /* XXX */ > *************** > *** 1174,1179 **** > --- 1175,1184 ---- > allerror = error; > vput(vp); > MNT_ILOCK(mp); > + if (flushed_count++ > 500) { > + flushed_count = 0; > + msleep(&flushed_count, MNT_MTX(mp), PZERO, "syncw", 1); > + } > } > MNT_IUNLOCK(mp); > /* > > -DG > > David G. Lawrence > President > Download Technologies, Inc. - http://www.downloadtech.com - (866) > 399 8500 > The FreeBSD Project - http://www.freebsd.org > Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 06:20:38 2007 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 27E8916A41A; Tue, 18 Dec 2007 06:20:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id AAEE513C47E; Tue, 18 Dec 2007 06:20:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBI6KUvC013824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 17:20:31 +1100 Date: Tue, 18 Dec 2007 17:20:30 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David G Lawrence In-Reply-To: <20071217103936.GR25053@tnn.dglawrence.com> Message-ID: <20071218170133.X32807@delplex.bde.org> References: <20071217103936.GR25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 06:20:38 -0000 On Mon, 17 Dec 2007, David G Lawrence wrote: > One more comment on my last email... The patch that I included is not > meant as a real fix - it is just a bandaid. The real problem appears to > be that a very large number of vnodes (all of them?) are getting synced > (i.e. calling ffs_syncvnode()) every time. This should normally only > happen for dirty vnodes. I suspect that something is broken with this > check: > > if (vp->v_type == VNON || ((ip->i_flag & > (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && > vp->v_bufobj.bo_dirty.bv_cnt == 0)) { > VI_UNLOCK(vp); > continue; > } Isn't it just the O(N) algorithm with N quite large? Under ~5.2, on a 2.2GHz A64 UP in 32-bit mode, I see a latency of 3 ms for 17500 vnodes, which would be explained by the above (and the VI_LOCK() and loop overhead) taking 171 ns per vnode. I would expect it to take more like 20 ns per vnode for UP and 60 for SMP. The comment before this code shows that the problem is known, and says that a subroutine call cannot be afforded unless there is work to do, but the, the locking accesses look like subroutine calls, have subroutine calls in their internals, and take longer than simple subroutine calls in the SMP case even when they don't make subroutine calls. (IIRC, on A64 a minimal subroutine call takes 4 cycles while a minimal locked instructions takes 18 cycles; subroutine calls are only slow when their branches are mispredicted.) Bruce From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 06:54:59 2007 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 CF62A16A41A for ; Tue, 18 Dec 2007 06:54:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 6EDEB13C47E for ; Tue, 18 Dec 2007 06:54:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBI6slA5077050; Mon, 17 Dec 2007 23:54:48 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47676E96.4030708@samsco.org> Date: Mon, 17 Dec 2007 23:54:14 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Bruce Evans References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> In-Reply-To: <20071218170133.X32807@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Mon, 17 Dec 2007 23:54:48 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 06:54:59 -0000 Bruce Evans wrote: > On Mon, 17 Dec 2007, David G Lawrence wrote: > >> One more comment on my last email... The patch that I included is not >> meant as a real fix - it is just a bandaid. The real problem appears to >> be that a very large number of vnodes (all of them?) are getting synced >> (i.e. calling ffs_syncvnode()) every time. This should normally only >> happen for dirty vnodes. I suspect that something is broken with this >> check: >> >> if (vp->v_type == VNON || ((ip->i_flag & >> (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && >> vp->v_bufobj.bo_dirty.bv_cnt == 0)) { >> VI_UNLOCK(vp); >> continue; >> } > > Isn't it just the O(N) algorithm with N quite large? Under ~5.2, on > a 2.2GHz A64 UP in 32-bit mode, I see a latency of 3 ms for 17500 vnodes, > which would be explained by the above (and the VI_LOCK() and loop > overhead) taking 171 ns per vnode. I would expect it to take more like > 20 ns per vnode for UP and 60 for SMP. > > The comment before this code shows that the problem is known, and says > that a subroutine call cannot be afforded unless there is work to do, > but the, the locking accesses look like subroutine calls, have subroutine > calls in their internals, and take longer than simple subroutine calls > in the SMP case even when they don't make subroutine calls. (IIRC, on > A64 a minimal subroutine call takes 4 cycles while a minimal locked > instructions takes 18 cycles; subroutine calls are only slow when their > branches are mispredicted.) > > Bruce Right, it's a non-optimal loop when N is very large, and that's a fairly well understood problem. I think what DG was getting at, though, is that this massive flush happens every time the syncer runs, which doesn't seem correct. Sure, maybe you just rsynced 100,000 files 20 seconds ago, so the upcoming flush is going to be expensive. But the next flush 30 seconds after that shouldn't be just as expensive, yet it appears to be so. This is further supported by the original poster's claim that it takes many hours of uptime before the problem becomes noticeable. If vnodes are never truly getting cleaned, or never getting their flags cleared so that this loop knows that they are clean, then it's feasible that they'll accumulate over time, keep on getting flushed every 30 seconds, keep on bogging down the loop, and so on. Scott From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 06:57:46 2007 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 CA0BF16A46B for ; Tue, 18 Dec 2007 06:57:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8D36313C4D9 for ; Tue, 18 Dec 2007 06:57:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1J4WOf-000DUM-CO for freebsd-stable@freebsd.org; Tue, 18 Dec 2007 08:57:45 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Dec 2007 08:57:45 +0200 From: Danny Braniss Message-ID: Subject: unionfs lock problems 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, 18 Dec 2007 06:57:46 -0000 with 7.0-Beta4, I'm getting quiet a few of these: lockmgr: thread 0xffffff00039269f0 unlocking unheld lock KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _lockmgr() at _lockmgr+0x6ae VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 unionfs_unlock() at unionfs_unlock+0x22f VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 vn_read() at vn_read+0x264 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x254 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80187b18c, rsp = 0x7fffffffafb8, rbp = 0x7fffffffb045 --- danny From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 07:13:43 2007 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 5D8CC16A418 for ; Tue, 18 Dec 2007 07:13:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1E57713C43E for ; Tue, 18 Dec 2007 07:13:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1J4We5-000Dfw-Ua for freebsd-stable@freebsd.org; Tue, 18 Dec 2007 09:13:41 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Dec 2007 09:13:41 +0200 From: Danny Braniss Message-ID: Subject: ufs_rename: fvp == tvp (can't happen) 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, 18 Dec 2007 07:13:43 -0000 Hi, I'm also getting quiet a few of this can't happen. The system is running 7.0-beta4, and is doing 'portsupgrade -af' danny From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 08:06:38 2007 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 6603716A41A for ; Tue, 18 Dec 2007 08:06:38 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.net [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2A813C442 for ; Tue, 18 Dec 2007 08:06:38 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from c-75-75-30-250.hsd1.va.comcast.net ([75.75.30.250]:64798 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1J4XTI-000JZo-GM for freebsd-stable@freebsd.org; Tue, 18 Dec 2007 08:06:36 +0000 Message-ID: <47677F89.5040501@conducive.net> Date: Tue, 18 Dec 2007 08:06:33 +0000 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20071217222806.4dfd1312@gmail.com> In-Reply-To: <20071217222806.4dfd1312@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Motherboard Asus P5N-E SLI compatibility with FreeBSD 7 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, 18 Dec 2007 08:06:38 -0000 Fabien Degomme wrote: > Hi, > > my question is about the Asus P5N-E SLI motherboard. I searched if > this MB is compatible with FreeBSD 7 but I don't have concrete > answer. > > So I just want to know if anyone owns this card with FreeBSD 6 > or 7 and if it works well. > > Thanks in advance :) > > > morphalus > _______________________________________________ > 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" > There are significant differences among the P5 'family, but AFAIK, all P5(xx) do work with just about any release of FreeBSD, (we've used 6.2 thru 6.3, all 7.X, 8-CURRENT). That said, there are MB, 'glue' chipset, and BIOS differences that can require special attention or reduce networking or Xorg utility, i.e. - getting a USB mouse to play nice (BIOS USB settings), perhaps having an onboard NIC (P5K & Alantec) that is not supported, and less than optimal graphics adapter choices. Some (again P5K) rob signal & interrupt lines for the 'faster' of two PCI-e sockets in such a way as to preclude effective use of the onnboard PCI slots when that socket is populated. Not so if the 'slower' PCI-e (only) is used. JM2CW, but, other than their 'bespoke' server MB, ASUS seem to place so much emphasis on Win-Gaming performance (or benchmarks..) that the compromises they make to 'win' do not make life easy for applying their consumer-grade MB to *N*X server or desktop use. We've had better results and far less hassle for both server and 'power user' desktop with comparably easy to find GigaByte MB. HTH, Bill From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 08:59:26 2007 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 E728C16A419 for ; Tue, 18 Dec 2007 08:59:26 +0000 (UTC) (envelope-from d.komaleev@konliga.ru) Received: from mail.konliga.ru (mail.konliga.ru [195.16.56.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3723513C45A for ; Tue, 18 Dec 2007 08:59:25 +0000 (UTC) (envelope-from d.komaleev@konliga.ru) Received: from exch01.konliga.ru ([192.168.1.252]) by mail.konliga.ru with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Dec 2007 11:41:43 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 18 Dec 2007 11:42:19 +0300 Message-ID: <2335ED0A1B2A294FACC6EB01EF0965F73B1533@exch01.konliga.ru> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: System hangs up every day Thread-Index: Acgbu+UjpSA8K1rPSO+DzNp1Ixma5gli2NAg From: =?koi8-r?B?5M3J1NLJyiDrz83BzMXF1w==?= To: X-OriginalArrivalTime: 18 Dec 2007 08:41:43.0468 (UTC) FILETIME=[D10066C0:01C84151] Subject: RE: System hangs up every day 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, 18 Dec 2007 08:59:27 -0000 Hello everybody Unfortunately my problem still doesn't have any solution. But I have an interesting observation. The gateway freezes very quickly, = if torrent client programs are running on workstations. I assume the cause of the problem consists in many number of TCP/IP = connections that torrent client establishes. Any ideas? Maybe I can tune somehow a TCP/IP via kernel, sysctl or pf settings? > There is one FreeBSD server in our company. The server platform is: = Supermicro SuperServer 6014V-T2B (2x Intel > Xeon 2.8, 1Gb RAM, 3WARE = 3W-8006-2LP RAID-Controller). > The server works as: > - a gateway between LAN and Internet > - an Intranet web- and database server (Apache + MySQL + PHP) > - a firewall (OpenBSD pf) > - a transparent proxy server (Squid) > A mounthly traffic through this server is about 100Gb. There is about = 200 internet users in our conpany. > FreeBSD 6.2-RELEASE-p8 > This server hangs up every day without any messages in the log files = and on the system console. A keyboard dosen't work too. I can make only = hard reset and after restart coredump files are not appearing. > If I make and install a kernel with SMP options the system under = working load begins hang up every two hours. > The two days "Memtest" gave no result. > I tried to install the newest Intel ethernet adapter driver, but = without any results. > As an experiment I tried also to plug a system HDD to another sever = platform (SuperServer 6015V-TB), but system hanging didn't stop. > I think that it is not only hardware problem. > Linux (Gentoo) and Windows server 2003 on this hardware were working = fine. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 09:27:08 2007 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 6ED2416A46E for ; Tue, 18 Dec 2007 09:27:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1202E13C461 for ; Tue, 18 Dec 2007 09:27:06 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBI5hqYM027979 for ; Tue, 18 Dec 2007 16:43:52 +1100 Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBI5heff027162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 16:43:43 +1100 Date: Tue, 18 Dec 2007 16:43:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David G Lawrence In-Reply-To: <20071217102433.GQ25053@tnn.dglawrence.com> Message-ID: <20071218155642.D32807@delplex.bde.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 09:27:08 -0000 On Mon, 17 Dec 2007, David G Lawrence wrote: >> While trying to diagnose a packet loss problem in a RELENG_6 snapshot >> dated >> November 8, 2007 it looks like I've stumbled across a broken driver or >> kernel routine which stops interrupt processing long enough to severly >> degrade network performance every 30.99 seconds. I see the same behaviour under a heavily modified version of FreeBSD-5.2 (except the period was 2 ms longer and the latency was 7 ms instead of 11 ms when numvnodes was at a certain value. Now with numvnodes = 17500, the latency is 3 ms. > I noticed this as well some time ago. The problem has to do with the > processing (syncing) of vnodes. When the total number of allocated vnodes > in the system grows to tens of thousands, the ~31 second periodic sync > process takes a long time to run. Try this patch and let people know if > it helps your problem. It will periodically wait for one tick (1ms) every > 500 vnodes of processing, which will allow other things to run. However, the syncer should be running at a relative low priority and not cause packet loss. I don't see any packet loss even in ~5.2 where the network stack (but not drivers) is still Giant-locked. Other too-high latencies showed up: - syscons LED setting and vt switching gives a latency of 5.5 msec because syscons still uses busy-waiting for setting LEDs :-(. Oops, I do see packet loss -- this causes it under ~5.2 but not under -current. For the bge and/or em drivers, the packet loss shows up in netstat output as a few hundred errors for every LED setting on the receiving machine, while receiving tiny packets at the maximum possible rate of 640 kpps. sysctl is completely Giant-locked and so are upper layers of the network stack. The bge hardware rx ring size is 256 in -current and 512 in ~5.2. At 640 kpps, 512 packets take 800 us so bge wants to call the the upper layers with a latency of far below 800 us. I don't know exactly where the upper layers block on Giant. - a user CPU hog process gives a latency of over 200 ms every half a second or so when the hog starts up, and a 300-400 ms after the hog has been running for some time. Two user CPU hog processes double the latency. Reducing kern.sched.quantum from 100 ms to 10 ms and/or renicing the hogs don't seem to affect this. Running the hogs at idle priority fixes this. This won't affect packet loss, but it might affect user network processes -- they might need to run at real time priority to get low enough latency. They might need to do this anyway -- a scheduling quantum of 100 ms should give a latency of 100 ms per CPU hog quite often, though not usually since the hogs should never be prefered to a higher-prioerity process. Previously I've used a less specialized clock-watching program to determine the syscall latency. It showed similar problems for CPU hogs. I just remembered that I found the fix for these under ~5.2 -- remove a local hack that sacrifices latency for reduced context switches between user threads. -current with SCHED_4BSD does this non-hackishly, but seems to have a bug somehwhere that gives a latency that is large enough to be noticeable in interactive programs. Bruce From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 09:36:51 2007 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 B444216A469 for ; Tue, 18 Dec 2007 09:36:51 +0000 (UTC) (envelope-from plaidoiries@formgestion.net.dm-4.com) Received: from mta224a.dm-4.com (mta224a.dm-4.com [64.40.113.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8F0A713C46A for ; Tue, 18 Dec 2007 09:36:51 +0000 (UTC) (envelope-from plaidoiries@formgestion.net.dm-4.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=x; d=dm-4.com; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type; i=plaidoiries@formgestion.net.dm-4.com; bh=loITW6cEbq81DykzXxyOWMu8ugA=; b=hiXxXujVVCerbZ9g//4wWITJrlWWU5EypC1pRnJZWW2+Eax8F90WGg/xmmUuiIfc2nUY3guiLCzs mI0IZdyL/pnRIBzoOy1Omh6ZFYl15z5Kx2+NwtyMbX7rhy00KJWAXkC+TlCM3VUPgNDyA5pJ3qey CDDngBg/SUOGN1UvSzk= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=x; d=dm-4.com; b=TvdMCigyMILVpblgwghgPvOcBAxpJjBRSuYzFDPASSmH5OVwdEyD3PA7Ha2yVbcUSRpPC3vTTFut ztdCqaKc3bzm0VzJO4cIRTGxdI8yIue0/2D9jrWU6uyEUdj01tbJOwlvWrv82bolYDoD+h26O9cN gMfIRAAt8mkDZZ4EaR4=; Received: by mta224a.dm-4.com (PowerMTA(TM) v3.2r17) id hcuade0dao8t for ; Tue, 18 Dec 2007 01:17:22 -0800 (envelope-from ) Message-ID: <2bns1mvodsukyzzqrfo14mwxfi@dm.msg> Date: Tue, 18 Dec 2007 09:17:22 GMT From: "VP Exploitation" To: "freebsd-stable@FreeBSD.org" X-Mailer: 2BNS1M VODSUKY ZZQRFO1 4MWXFI Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Cc: Subject: Recouvrement - Reduire les comptes recevables X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: plaidoiries@formgestion.net.dm-4.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 09:36:51 -0000 Formation Des méthodes efficaces pour le recouvrement des comptes clients «Accélérées et performantes» Introduction: Le service des comptes à recevoir a un impact direct sur tous les autres départements tels que ; Finances, approvisionnements, Production et même les Ventes. En sous-estimer l'importance peut s'avérer être désastreux. Il est d'une importance vitale pour toute compagnie de bien implanter un système de suivi adéquat sur lequel il est possible de bien gérer ses comptes recevables. Cette formation couvrira les différentes étapes nécessaires à la réalisation et la gestion du service des comptes à recevoir pour établir des stratégies de collection plus efficaces et plus rapide. POUR INFORMATIONS COMMUNIQUER AU 450-226-2238 OU AU 1-800-861-6618 Public Visé : Les Directeurs généraux, les contrôleurs, les comptables, les chargés du recouvrement de créances clients, commis services administratifs ou des comptes à recevoir, Objectifs: Établir des politiques de recouvrement conformes aux objectifs fixés. Révision et compréhension des enjeux au sein du Dépt. de la Comptabilité face au volet ''collection''. Définir et élaborer une stratégie et des conditions de ventes en fonction des recevables. Gestion du stress Implanter une méthodologie assurant la standardisation des procédures de collection de façon à maintenir un bon fonds de roulement. Identifier et actionner la bonne procédure de contentieux RESULTAT : Améliorer la rentabilité à l'entreprise par le biais d'un contrôle très serré sur les recevables. Plan sommaire du cours 1 - Mesurer l'impact des retards de paiement sur la trésorerie A. AU PLAN FINANCIER B. AU PLAN COMMERCIAL 2 - Diagnostiquer son propre département de recouvrement A. Inventaire des Situations courantes de recouvrement B. Inventaire de l'arsenal des outils et techniques de recouvrement C. INVENTAIRE AVEC LES BONNES PRATIQUES DU SECTEUR, PAR TYPE DE CLIENTS D. CONNAÎTRE SON CLIENT (SITUATION ÉCONOMIQUE - FRÉQUENCE ET VOLUME D'ACHATS) E. CONNAÎTRE SES CONCURRENTS COMMERCIAUX : LEURS POLITIQUES, LEURS PRIX, ETC.. F. CONNAÎTRE SES POLITIQUES ET SES MARGES DE MANOUVRE G. DÉTERMINER LES LEVIERS EMOTIONNELS CÔTÉ CLIENTS DIFFICILE H. DÉTERMINER LES LEVIERS EMOTIONNELS A PRENDRE EN CONSIDERATION POUR ÊTRE EFFICACE A L'INTERNE 3 - BÂTIR UNE STRATÉGIE DE COLLECTION POUR MINIMISER LES MAUVAISES CRÉANCES A. IDENTIFIER LES MAUVAIS CLIENTS (RÉPERTORIER, CATÉGORISER) B. IDENTIFIER LES RISQUES (AMPLEUR ET STATISTIQUES) C. DÉTERMINER UN RATIO RECEVABLE VS VENTES SOUHAITABLE, ACCEPTABLE ET CRITIQUE 4 - SAVOIR AGIR EN MATIÈRE DE RECOUVREMENT à L'AMIABLE A. DÉTERMINER DES INCITATIFS POUR LES PAYEURS RAPIDES ET DES PÉNALITÉS POUR LES RETARDATAIRES EN COLLABORATION AVEC LE SERVICE DES VENTES (EX : PERTE DE PRIVILÈGES) 5 - LIMITER LES CAS DE RECOUVREMENT JUDICIAIRE A. RÉDIGER DES CONDITIONS GENERALES DE VENTE EFFICACES B. ORGANISER L'INFORMATION COMMERCIALE POUR FAIRE LA PREUVE DE LA CREANCE C. ESTIMER, NÉGOCIER, IMPOSER SON DELAIS DE REGLEMENT AU CLIENT 6 - COMMENT IDENTIFIER LES ACTEURS ET JURIDICTIONS COMPETENTES ? A. PAR QUELLES AUTORITES JUDICAIRES ? B. POUR QUELLES ACTIONS ? C. POUR QUELS COÛTS ? D. POUR QUELS RESULTATS ? E. POUR QUELLES CONSEQUENCES ? 7 - ANTICIPER ET GERER LA FAILLITE D'UN CLIENT A. LES INDICES PRÉCURSEURS B. MESURER ET NOTER LE RISQUE CLIENT C. CRÉER PLUSIEURS SCÉNARIOS POUR PRENDRE LES BONNES DÉCISIONS PÉDAGOGIE : ÉTUDES DE CAS ET EXERCICES SUR CHACUN DES CHAPITRES CI-DESSUS. MÉTHODOLOGIE DE L'ENSEIGNEMENT Apports méthodologiques, exercices pratiques et mises en situation, complétées et enrichies de partage d'expériences vécues et de témoignage d'expert. Travail et discussions à partir des cas présentés par les participants. Visitez notre site internet Dates et Lieux De La Formation: Région de Montréal: Les 19 et 20 février 2008 Hôtel Sheraton, 2440, Autoroute des Laurentides, Laval Région de Québec : Les 24 et 25 janvier 2008 Hôtel Des Gouverneurs, 3030 boulevard Laurier Ste-Foy N.B. Nombre de places limitées 15 Personnes Pour inscription, veuillez contacter Mme Maryse Morin au 1.877.726.2238 1- Si vous souhaitez recevoir nos offres de formation, cliquez ici: http://content.dynamicmessenger.com/compufinder/?o8jKpYDLscF5RaKZV0hpvBA2cjo 2- Si vous souhaitez vous retirer definitivement de notre base de donnees, cliquez ici: http://content.dynamicmessenger.com/compufinder/?o8jKpYDLscF5RaKZV0hpvBA2cjo From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 09:51:30 2007 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 E231416A475; Tue, 18 Dec 2007 09:51:30 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by mx1.freebsd.org (Postfix) with ESMTP id D09A213C4EC; Tue, 18 Dec 2007 09:51:29 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx30.mail.ru (mx30.mail.ru [194.67.23.238]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 9A14A10B366A; Tue, 18 Dec 2007 12:20:53 +0300 (MSK) Received: from [78.140.2.237] (port=26518 helo=nuclight.avtf.net) by mx30.mail.ru with esmtp id 1J4Yd9-000FkY-00; Tue, 18 Dec 2007 12:20:51 +0300 Date: Tue, 18 Dec 2007 15:20:48 +0600 To: "freebsd-ipfw@freebsd.org" , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: multipart/mixed; boundary=----------2UNlkgEOncIwckbiXYzy0f MIME-Version: 1.0 Message-ID: User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: maxim@freebsd.org, mlaier@freebsd.org, phk@freebsd.org Subject: [PATCH] ipfwpcap(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: Tue, 18 Dec 2007 09:51:31 -0000 ------------2UNlkgEOncIwckbiXYzy0f Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r Content-Transfer-Encoding: 8bit Hi, I've recently found a patch (also available at http://antigreen.org/vadim/freebsd/ipfwpcap/) made by me and my friend in January to ipfwpcap(8) introduced in 7.0. Now it have more features, some of which were already present in pflogd(8) counterpart. Patched version were tested in about to 200 parallel processes, on both 5.5 and 6.2 for half a year, without any bugs. If possible, could it be committed to ongoing 7.0-RELEASE ? It would be nice to not break POLA after release is being stable and widely available (some option meaning were changed (to be more consistent with pflogd and overall FreeBSD-ish, though), but I forgot to post it earlier, before 7.0-STABLE fork, sorry). Please. List of changes: 1. Program now daemonizes itself by defaul, and -d option not only enables debug, but cancels daemonizing too. 2. Log is now re-opened on SIGHUP; if log pathname was not absolute, will not do chdir("/") after daemonizing. 3. Log is now flushed on SIGALRM, new option -i can be used to specify flush interval (using alarm(3)), default is 60 seconds. 4. Added option -z, which resets log-limiting counters to zero on each log re-open. 5. Added pid-file checking - if exists, check if process with it's value still exists (ignore signal 0 ourselves), if not, rewrite stale pid-file and begin working. 6. Signal handlers now do only variable setting, all work is done in main loop, changed from for(;;) to while(!quit). 7. Minor changes - less global variables, changed strcpy() -> strlcpy(), added some macros, less output from usage (as we now have manpage), most exit codes changed from custom ones to sysexits(3). 8. More style(9), and new features are documented in man page, some old statements in man were made more detailed. -- WBR, Vadim Goncharov ------------2UNlkgEOncIwckbiXYzy0f Content-Disposition: attachment; filename=ipfwpcap.patch Content-Type: application/octet-stream; name=ipfwpcap.patch Content-Transfer-Encoding: 8bit --- ipfwpcap.c.orig Sat Nov 11 05:22:06 2006 +++ ipfwpcap.c Tue Dec 19 08:30:00 2006 @@ -1,95 +1,120 @@ +/*- + * Copyright (c) 2004 University of Toronto. All rights reserved. + * Anyone may use or copy this software except that this copyright + * notice remain intact and that credit is given where it is due. + * The University of Toronto and the author make no warranty and + * accept no liability for this software. + * + * $FreeBSD: /repoman/r/ncvs/src/usr.sbin/ipfwpcap/ipfwpcap.c,v 1.2 2006/09/04 19:30:44 sam Exp $ + */ + /* - * copy diverted (or tee'd) packets to a file in 'tcpdump' format + * Copy diverted (or tee'd) packets to a file in 'tcpdump' format * (ie. this uses the '-lpcap' routines). * - * example usage: - * # ipfwpcap -r 8091 divt.log & + * Example usage: + * # ipfwpcap -r 8091 divt.log * # ipfw add 2864 divert 8091 ip from 128.432.53.82 to any * # ipfw add 2864 divert 8091 ip from any to 128.432.53.82 * * the resulting dump file can be read with ... * # tcpdump -nX -r divt.log - */ -/* - * Written by P Kern { pkern [AT] cns.utoronto.ca } - * - * Copyright (c) 2004 University of Toronto. All rights reserved. - * Anyone may use or copy this software except that this copyright - * notice remain intact and that credit is given where it is due. - * The University of Toronto and the author make no warranty and - * accept no liability for this software. * - * From: Header: /local/src/local.lib/SRC/ipfwpcap/RCS/ipfwpcap.c,v 1.4 2004/01/15 16:19:07 pkern Exp - * - * $FreeBSD: /repoman/r/ncvs/src/usr.sbin/ipfwpcap/ipfwpcap.c,v 1.2 2006/09/04 19:30:44 sam Exp $ + * Written by P Kern { pkern [AT] cns.utoronto.ca } + * Adopted by V Pavluk (vladvic_r@mail.ru) + * - changed sighup handler to reopen log file + * - added sigalrm handler to flush data + * - some of exit() codes changed to sysexits(3) + * Major code reworking by Vadim Goncharov + * - signals and daemonizing rewritten + * - style(9) reformat, more sysexits(3) and other cleanups + * - enabled own alarm sending, changed options and updated man page */ +#include +#include +#include /* For MAXPATHLEN */ +#include +#include + +#include +#include /* For IP_MAXPACKET */ +#include /* For IP_MAXPACKET */ + #include #include #include #include #include #include -#include -#include -#include /* for MAXPATHLEN */ -#include -#include - -#include /* for IP_MAXPACKET */ -#include /* for IP_MAXPACKET */ +#include /* XXX normally defined in config.h */ -#define HAVE_STRLCPY 1 -#define HAVE_SNPRINTF 1 -#define HAVE_VSNPRINTF 1 -#include /* see pcap(3) and /usr/src/contrib/libpcap/. */ +#define HAVE_STRLCPY 1 +#define HAVE_SNPRINTF 1 +#define HAVE_VSNPRINTF 1 +#include /* See pcap(3) and /usr/src/contrib/libpcap/. */ #ifdef IP_MAXPACKET -#define BUFMAX IP_MAXPACKET +#define BUFMAX IP_MAXPACKET #else -#define BUFMAX 65535 +#define BUFMAX 65535 #endif #ifndef MAXPATHLEN #define MAXPATHLEN 1024 #endif -static int debug = 0; -static int reflect = 0; /* 1 == write packet back to socket. */ +#define MAXPIDLEN 9 /* Max decimal pid length in characters. */ +#define DEFINTERVAL 60 /* How often to do flush (in seconds). */ -static ssize_t totbytes = 0, maxbytes = 0; -static ssize_t totpkts = 0, maxpkts = 0; +static char *prog = NULL; +static char pidfile[MAXPATHLEN] = { '\0' }; -char *prog = NULL; -char pidfile[MAXPATHLEN] = { '\0' }; +static int quit = 0; /* Is it time to exit? */ +static int do_flush = 0; /* Time to flush log. */ +static int do_reopen = 0; /* Time for log rotating. */ +static int flush_interval = DEFINTERVAL; /* - * tidy up. + * Tidy up macro. */ -void -quit(sig) -int sig; +#define QUIT(code) do { \ + pcap_dump_flush(dp); \ + (void)unlink(pidfile); \ + exit(code); \ +} while(0); + +void +quit_sig(int sig) +{ + quit = 1; +} + +void +flush_log(int sigalrm) +{ + do_flush = 1; + alarm(flush_interval); +} + +void +reopen_log(int sighup) { - (void) unlink(pidfile); - exit(sig); + do_reopen = 1; } /* - * do the "paper work" - * - save my own pid in /var/run/$0.{port#}.pid + * Do the "paper work". + * - fork and detach from terminal, if needed. + * - save my own pid in /var/run/$0.{port#}.pid. */ -okay(pn) -int pn; +void +okay(int pn, int detach, int nochdir) { - FILE *fp; - int fd, numlen, n; - char *p, numbuf[80]; - - numlen = sizeof(numbuf); - bzero(numbuf, numlen); - snprintf(numbuf, numlen-1, "%ld\n", getpid()); - numlen = strlen(numbuf); + int pf; + char *p, strpid[MAXPIDLEN + 1]; + pid_t pid; if (pidfile[0] == '\0') { p = (char *)rindex(prog, '/'); @@ -99,93 +124,158 @@ "%s%s.%d.pid", _PATH_VARRUN, p, pn); } - fd = open(pidfile, O_WRONLY|O_CREAT|O_EXCL, 0644); - if (fd < 0) { perror(pidfile); exit(21); } + pf = open(pidfile, O_WRONLY | O_CREAT | O_EXCL | O_EXLOCK, 0644); - siginterrupt(SIGTERM, 1); - siginterrupt(SIGHUP, 1); - signal (SIGTERM, quit); - signal (SIGHUP, quit); - - n = write(fd, numbuf, numlen); - if (n < 0) { perror(pidfile); quit(23); } - (void) close(fd); + /* + * We couldn't create pid file + */ + if (pf == -1) { + if (errno == EEXIST) { + /* + * If it is because it's already exists + */ + bzero(strpid, MAXPIDLEN + 1); + fprintf(stderr, "PID file already exists!\n"); + + /* + * Try to read the PID stored in the existing file + */ + pf = open(pidfile, O_RDONLY); + if (pf == -1) { + perror("Error opening PID file for reading"); + exit(EX_IOERR); + } + if (read(pf, strpid, MAXPIDLEN) < 0) { + perror("Error reading PID file"); + exit(EX_IOERR); + } + pid = atol(strpid); + close(pf); + + /* + * We found PID, try to determine, whether process + * is running + */ + if (kill(pid, 0) == 0) { + /* + * Signal is delivered, though process with + * such PID exists + */ + fprintf(stderr, "%s already running with PID=%d, exiting...\n", prog, pid); + exit(1); + } else { + /* + * It seems, like the process is killed, so + * we can proceed... + */ + fprintf(stderr, "Stale PID file, overwriting...\n"); + pf = open(pidfile, O_WRONLY | O_TRUNC | O_EXLOCK); + if (pf == -1) { + perror("Error opening PID file for writing"); + exit(EX_IOERR); + } + } + } else { + perror("Error creating PID file"); + exit(EX_IOERR); + } + } + + if (detach) { + if (daemon(nochdir, 0) != 0) { + close(pf); + (void)unlink(pidfile); + perror("daemon"); + exit(EX_OSERR); + } + } + + /* + * Set signal handlers and system behaviour. This must be done + * before saving PID to prevent small, but possible race condition + * when another instance failed to create PID, reads it and tries + * to send signal to us. + */ + siginterrupt(SIGTERM, 1); + siginterrupt(SIGHUP, 1); + + /* Ignore 0th signal, or process may be killed with it by default... */ + signal(0, SIG_IGN); + signal(SIGINT, quit_sig); + signal(SIGTERM, quit_sig); + signal(SIGHUP, reopen_log); + signal(SIGALRM, flush_log); + + /* Save our PID to pidfile. */ + bzero(strpid, MAXPIDLEN + 1); + snprintf(strpid, MAXPIDLEN, "%ld\n", getpid()); + if (write(pf, strpid, strlen(strpid)) < 0) { + perror("Error writing PID file"); + exit(EX_IOERR); + } + close(pf); } +void usage() { - fprintf(stderr, "\ -\n\ -usage:\n\ - %s [-dr] [-b maxbytes] [-p maxpkts] [-P pidfile] portnum dumpfile\n\ -\n\ -where:\n\ - '-d' = enable debugging messages.\n\ - '-r' = reflect. write packets back to the divert socket.\n\ - (ie. simulate the original intent of \"ipfw tee\").\n\ - '-rr' = indicate that it is okay to quit if packet-count or\n\ - byte-count limits are reached (see the NOTE below\n\ - about what this implies).\n\ - '-b bytcnt' = stop dumping after {bytcnt} bytes.\n\ - '-p pktcnt' = stop dumping after {pktcnt} packets.\n\ - '-P pidfile' = alternate file to store the PID\n\ - (default: /var/run/%s.{portnum}.pid).\n\ -\n\ - portnum = divert(4) socket port number.\n\ - dumpfile = file to write captured packets (tcpdump format).\n\ - (specify '-' to write packets to stdout).\n\ -\n\ -", prog, prog); - - fprintf(stderr, "\ -The '-r' option should not be necessary, but because \"ipfw tee\" is broken\n\ -(see BUGS in ipfw(8) for details) this feature can be used along with\n\ -an \"ipfw divert\" rule to simulate the original intent of \"ipfw tee\".\n\ -\n\ -NOTE: With an \"ipfw divert\" rule, diverted packets will silently\n\ - disappear if there is nothing listening to the divert socket.\n\ -\n\ -"); - exit(-1); + fprintf(stderr, + "usage: %s [-dz] [-r | -rr] [-i flush_interval] [-b maxbytes] [-p maxpkts] [-P pidfile] portnum dumpfile\n", + prog); + + exit(EX_USAGE); } -main(ac, av) -int ac; -char *av[]; +main(int argc, char *argv[]) { int r, sd, portnum, l; - struct sockaddr_in sin; - int errflg = 0; + struct sockaddr_in sin; + int errflg = 0, zeroize = 0; int nfd; fd_set rds; ssize_t nr; - char *dumpf, buf[BUFMAX]; + char buf[BUFMAX]; + + int debug = 0; + int reflect = 0; /* 1 == write packet back to socket. */ + + ssize_t totbytes = 0, maxbytes = 0; + ssize_t totpkts = 0, maxpkts = 0; - pcap_t *p; - pcap_dumper_t *dp; struct pcap_pkthdr phd; + pcap_t *p; + pcap_dumper_t *dp; /* Global, as signal handlers may want it. */ + char *dumpf; - prog = av[0]; + prog = argv[0]; - while ((r = getopt(ac, av, "drb:p:P:")) != -1) { + while ((r = getopt(argc, argv, "drzb:i:p:P:")) != -1) { switch (r) { case 'd': - debug++; + debug = 1; break; case 'r': reflect++; break; + case 'i': + flush_interval = atoi(optarg); + if ((flush_interval < 5) || (flush_interval > 3600)) + flush_interval = DEFINTERVAL; + break; case 'b': - maxbytes = (ssize_t) atol(optarg); + maxbytes = (ssize_t)atol(optarg); break; case 'p': - maxpkts = (ssize_t) atoi(optarg); + maxpkts = (ssize_t)atoi(optarg); + break; + case 'z': + zeroize = 1; break; case 'P': - strcpy(pidfile, optarg); + strlcpy(pidfile, optarg, sizeof(pidfile)); break; case '?': default: @@ -194,17 +284,18 @@ } } - if ((ac - optind) != 2 || errflg) + if (((argc - optind) != 2) || errflg) usage(); - portnum = atoi(av[optind++]); - dumpf = av[optind]; + portnum = atoi(argv[optind++]); + dumpf = argv[optind]; -if (debug) fprintf(stderr, "bind to %d.\ndump to '%s'.\n", portnum, dumpf); + if (debug) + fprintf(stderr, "bind to %d.\ndump to '%s'.\n", portnum, dumpf); if ((r = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) == -1) { perror("socket(DIVERT)"); - exit(2); + exit(EX_OSERR); } sd = r; @@ -214,92 +305,136 @@ if (bind(sd, (struct sockaddr *)&sin, sizeof(sin)) == -1) { perror("bind(divert)"); - exit(3); + exit(EX_OSERR); } p = pcap_open_dead(DLT_RAW, BUFMAX); dp = pcap_dump_open(p, dumpf); if (dp == NULL) { pcap_perror(p, dumpf); - exit(4); + exit(EX_OSFILE); } + + /* + * We will not chdir() to root directory if user specified + * non-absolute pathname to logfile, because in this case + * logfile will be created in another directory after first + * reopening on SIGHUP. + */ + okay(portnum, !debug, dumpf[0] == '/' ? 0 : 1); - okay(portnum); + alarm(flush_interval); /* Start timer. */ nfd = sd + 1; - for (;;) { + while (!quit) { + /* + * Handle signal actions on next iteration after select()'s EINTR. + */ + if (do_flush) { + if (debug) + fprintf(stderr, "Flushing log.\n"); + pcap_dump_flush(dp); + do_flush = 0; + } + + if (do_reopen) { + if (debug) + fprintf(stderr, "Reopening log.\n"); + pcap_dump_close(dp); + dp = pcap_dump_open(p, dumpf); + if (zeroize) { + totbytes = 0; + totpkts = 0; + } + do_reopen = 0; + } + + /* Prepare for select(). */ FD_ZERO(&rds); FD_SET(sd, &rds); r = select(nfd, &rds, NULL, NULL, NULL); if (r == -1) { - if (errno == EINTR) continue; + if (errno == EINTR) + continue; perror("select"); - quit(11); + QUIT(EX_OSERR); } - if (!FD_ISSET(sd, &rds)) - /* hmm. no work. */ - continue; + continue; /* Hmm. No work. */ /* - * use recvfrom(3 and sendto(3) as in natd(8). - * see /usr/src/sbin/natd/natd.c - * see ipfw(8) about using 'divert' and 'tee'. + * Use recvfrom(3 and sendto(3) as in natd(8). + * See /usr/src/sbin/natd/natd.c. + * See ipfw(8) about using 'divert' and 'tee'. */ /* - * read packet. + * Read packet. */ l = sizeof(sin); nr = recvfrom(sd, buf, sizeof(buf), 0, (struct sockaddr *)&sin, &l); -if (debug) fprintf(stderr, "recvfrom(%d) = %d (%d)\n", sd, nr, l); - if (nr < 0 && errno != EINTR) { + + if (debug) + fprintf(stderr, "recvfrom(%d) = %d (%d)\n", sd, nr, l); + + if ((nr < 0) && (errno != EINTR)) { perror("recvfrom(sd)"); - quit(12); + QUIT(EX_IOERR); } - if (nr <= 0) continue; + if (nr <= 0) + continue; - if (reflect) { + if (reflect > 0) { /* - * write packet back so it can continue - * being processed by any further IPFW rules. + * Write packet back so it can continue being + * processed by any further IPFW rules. */ l = sizeof(sin); r = sendto(sd, buf, nr, 0, (struct sockaddr *)&sin, l); -if (debug) fprintf(stderr, " sendto(%d) = %d\n", sd, r); - if (r < 0) { perror("sendto(sd)"); quit(13); } + if (debug) + fprintf(stderr, "sendto(%d) = %d\n", sd, r); + if (r < 0) { + perror("sendto(sd)"); + QUIT(EX_IOERR); + } } /* - * check maximums, if any. - * but don't quit if must continue reflecting packets. + * Check maximums, if any. But don't quit if must continue + * reflecting packets. However, it's ok to exit when + * reflect > 1. */ if (maxpkts) { totpkts++; if (totpkts > maxpkts) { - if (reflect == 1) continue; - quit(0); + if (reflect == 1) + continue; + QUIT(EX_OK); } } if (maxbytes) { totbytes += nr; if (totbytes > maxbytes) { - if (reflect == 1) continue; - quit(0); + if (reflect == 1) + continue; + QUIT(EX_OK); } } /* - * save packet in tcpdump(1) format. see pcap(3). - * divert packets are fully assembled. see ipfw(8). + * Save packet in tcpdump(1) format. See pcap(3). Divert + * packets are fully assembled, see ipfw(8). */ - (void) gettimeofday(&(phd.ts), NULL); + (void)gettimeofday(&(phd.ts), NULL); phd.caplen = phd.len = nr; pcap_dump((u_char *)dp, &phd, buf); - if (ferror((FILE *)dp)) { perror(dumpf); quit(14); } - (void) fflush((FILE *)dp); + if (ferror((FILE *)dp)) { + perror(dumpf); + QUIT(EX_IOERR); + } + } - quit(0); + QUIT(EX_OK); } --- ipfwpcap.8.orig Sat Nov 11 05:08:21 2006 +++ ipfwpcap.8 Thu Dec 21 09:04:28 2006 @@ -24,7 +24,7 @@ .\" .\" $FreeBSD: /repoman/r/ncvs/src/usr.sbin/ipfwpcap/ipfwpcap.8,v 1.3 2006/09/30 19:07:03 ru Exp $ .\" -.Dd May 22, 2006 +.Dd Dec 20, 2006 .Dt IPFWPCAP 8 .Os .Sh NAME @@ -32,7 +32,9 @@ .Nd "copy diverted packets to a file in tcpdump format" .Sh SYNOPSIS .Nm -.Op Fl dr +.Op Fl dz +.Op Fl r | rr +.Op Fl i Ar flush_interval .Op Fl b Ar maxbytes .Op Fl p Ar maxpkts .Op Fl P Ar pidfile @@ -48,19 +50,44 @@ .Xr ipfw 8 to a port on which .Nm -listens. +daemon listens. The packets are then dropped unless .Fl r is used. .Pp +.Nm +closes and then re-opens the dump file when it receives +.Dv SIGHUP , +permitting +.Xr newsyslog 8 +to rotate dump logfiles automatically. +Note that already existing file will be truncated on open or re-open. +Receiving +.Dv SIGALRM +causes +.Nm +to flush the current logfile buffers to the disk, thus making the most +recent logs available. +The buffers are also flushed every +.Ar flush_interval +seconds. +.Pp The options are as follows: .Bl -tag -width indent .It Fl d -Turns on extra debugging messages. +Turns on debugging messages and prevents +.Nm +from making itself a background daemon. .It Fl r Writes packets back to the .Xr divert 4 socket. +This option can be used to reflect packets back to +.Xr ipfw 8 +if you for some reasons want to use +.Dq divert +rule action instead of usually more suitable +.Dq tee . .It Fl rr Indicates that it is okay to quit if .Ar maxbytes @@ -74,6 +101,17 @@ Stop dumping after .Ar maxbytes bytes. +Note that size of resulting +.Ar dumpfile +will be greater than +.Ar maxbytes +because +.Xr pcap 3 +stores additional headers for each packet in the file. +.It Fl i Ar flush_interval +Time in seconds to delay between automatic flushes of the file. +This may be specified with a value between 5 and 3600 seconds. +If not specified, the default is 60 seconds. .It Fl p Ar maxpkts Stop dumping after .Ar maxpkt @@ -81,7 +119,10 @@ .It Fl P Ar pidfile File to store PID number in. Default is -.Pa /var/run/ipwfpcap.portnr.pid . +.Pa /var/run/ipwfpcap. Ns Ao Ar portnum Ac Ns Pa .pid . +.It Fl z +Reset byte and packet counters to zero after each reopening of the +.Ar dumpfile . .El .Pp The @@ -98,7 +139,7 @@ .Sh EXIT STATUS .Ex -std .Sh EXAMPLES -.Dl "ipfwpcap -r 8091 divt.log &" +.Dl "ipfwpcap -r 8091 divt.log" .Pp Starts .Nm @@ -117,12 +158,13 @@ .Xr tcpdump 1 , .Xr pcap 3 , .Xr divert 4 , -.Xr ipfw 8 +.Xr ipfw 8 , +.Xr pflogd 8 .Sh HISTORY The .Nm utility first appeared in -.Fx 7.0 . +.Fx 6.3 . .Sh AUTHORS .An -nosplit .Nm ------------2UNlkgEOncIwckbiXYzy0f-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 11:08:27 2007 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 22D2E16A468 for ; Tue, 18 Dec 2007 11:08:27 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 71DC513C447 for ; Tue, 18 Dec 2007 11:08:25 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A4DA4.dip.t-dialin.net [84.154.77.164]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lBIB8MTq091143 for ; Tue, 18 Dec 2007 11:08:23 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id lBIB8xNL046508 for ; Tue, 18 Dec 2007 12:08:59 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lBIB8rAL090380 for ; Tue, 18 Dec 2007 12:08:58 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200712181108.lBIB8rAL090380@fire.js.berklix.net> To: stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich/Muenchen. User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com/~jhs/cv/ Date: Tue, 18 Dec 2007 12:08:53 +0100 Sender: jhs@berklix.org Cc: Subject: 7.0BETA4 /usr/src/gnu/usr.bin/cc/cc_int Thrashes 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, 18 Dec 2007 11:08:27 -0000 Has 7.0-BETA4 perhaps wrongly got a -pipe in the .mk macros ? Please someone with generic 7.0BETA4 check with eg: A single line /etc/make.conf CFLAGS += -Dzonk=bla ~/tmp/Makefile tst: @echo "XX ${CFLAGS} YY" make tst XX -O2 -fno-strict-aliasing -pipe -Dzonk=bla YY Is pipe coming from generic mk/ ? Or from my local hacked version ? Could someone test please: My /usr/src is no longer generic, on a very slow CPU, SLIP linked, building rest of src/ & I'm about to go away, & will miss the 7-RELEASE date, but -pipe should not be in generic, needs to be a host dependent choice. ) Thanks PS Discovered after thrashing, never getting past /usr/src/gnu/usr.bin/cc/cc_int cc -O2 -fno-strict-aliasing -pipe -march=i586 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -c ../cc_tools/insn-attrtab.c & many swap_pager_getswapspace(3): failed Then I got desperate & dd if=/dev/zero of=/var/tmp/SWAP count=200000 mdconfig -a -t vnode -f /var/tmp/SWAP swapon /dev/md0 I've hashed out cc in src/gnu/usr.bin/Makefile to nurse it on. Julian -- Julian Stacey. Munich Consultant: BSD Unix Linux. http://berklix.com Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 11:18:49 2007 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 1372E16A468; Tue, 18 Dec 2007 11:18:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 997B213C4E7; Tue, 18 Dec 2007 11:18:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBIBIZCE016955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 22:18:38 +1100 Date: Tue, 18 Dec 2007 22:18:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mark Fullmer In-Reply-To: <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> Message-ID: <20071218220924.P6176@besplex.bde.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 11:18:49 -0000 On Mon, 17 Dec 2007, Mark Fullmer wrote: > Thanks. Have a kernel building now. It takes about a day of uptime after > reboot before I'll see the problem. Yes run "find / >/dev/null" to see the problem if it is the syncer one. At least the syscall latency problem does seem to be this. Under ~5.2, with the above find and also "while :; do sync; done" (to give latency spike more often), your program (with some fflush(stdout)'s and args 1 7700) gives: % 1197976029041677 12696 0 % 1197976033196396 9761 4154719 % 1197976034060031 13360 863635 % 1197976039080632 13749 5020601 % 1197976043195594 8536 4114962 % 1197976044100601 13505 905007 % 1197976049121870 14562 5021269 % 1197976052195631 8192 3073761 % 1197976054141545 14024 1945914 % 1197976059162357 14623 5020812 % 1197976063195735 7830 4033378 % 1197976064182564 14618 986829 % 1197976069202982 14823 5020418 % 1197976074223722 15350 5020740 % 1197976079244311 15726 5020589 % 1197976084264690 15893 5020379 % 1197976089289409 15058 5024719 % 1197976094315433 16209 5026024 % 1197976095197277 8015 881844 % 1197976099335529 16092 4138252 % 1197976104356513 16863 5020984 % 1197976109376236 16373 5019723 % 1197976114396803 16727 5020567 % 1197976119416822 16533 5020019 % 1197976124437790 17288 5020968 % 1197976126200637 10060 1762847 % 1197976127198459 7839 997822 % 1197976129457321 16606 2258862 % 1197976134477582 16654 5020261 This clearly shows the spike every 5 seconds, and the latency creeping up as vfs.numvnodes increases. It started at about 20000 and ended at about 64000. The syncer won't be fixed soon, so the fix for dropped packets requires figuring out why the syncer affects networking. Bruce From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 11:59:12 2007 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 7DCB316A580; Tue, 18 Dec 2007 11:59:12 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 22B2413C442; Tue, 18 Dec 2007 11:59:12 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from dhcp250-210.yandex.ru ([87.250.250.210]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1J4aY9-0006g8-Cu; Tue, 18 Dec 2007 14:23:49 +0300 Message-ID: <4767AD27.8070901@FreeBSD.org> Date: Tue, 18 Dec 2007 14:21:11 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Vadim Goncharov References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: maxim@freebsd.org, mlaier@freebsd.org, "freebsd-stable@freebsd.org" , "freebsd-net@freebsd.org" , "freebsd-ipfw@freebsd.org" , "freebsd-current@freebsd.org" , phk@freebsd.org Subject: Re: [PATCH] ipfwpcap(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: Tue, 18 Dec 2007 11:59:12 -0000 Vadim Goncharov wrote: > Hi, > > I've recently found a patch (also available at > http://antigreen.org/vadim/freebsd/ipfwpcap/) made by me and my friend > in January to ipfwpcap(8) introduced in 7.0. Now it have more features, Unfortunately too old to apply. And using of pidfile_* functions from libutil is preferable IMHO. -- Dixi. Sem. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 12:17:09 2007 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 B4ED116A417; Tue, 18 Dec 2007 12:17:09 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 49CBA13C467; Tue, 18 Dec 2007 12:17:08 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 342DD1045DC; Tue, 18 Dec 2007 17:52:19 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECq9l8TNcU15; Tue, 18 Dec 2007 17:52:15 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id A2BE2104605; Tue, 18 Dec 2007 17:52:15 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 17:52:15 +0600 Received: from nuclight.avtf.net ([78.140.2.237]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 17:52:15 +0600 Date: Tue, 18 Dec 2007 17:52:11 +0600 To: "Sergey Matveychuk" References: <4767AD27.8070901@FreeBSD.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: multipart/mixed; boundary=----------GJeOyVu3xITaB9Flyz9pX0 MIME-Version: 1.0 Message-ID: In-Reply-To: <4767AD27.8070901@FreeBSD.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 18 Dec 2007 11:52:15.0158 (UTC) FILETIME=[6ED1DD60:01C8416C] Cc: maxim@freebsd.org, mlaier@freebsd.org, "freebsd-stable@freebsd.org" , "freebsd-net@freebsd.org" , "freebsd-ipfw@freebsd.org" , "freebsd-current@freebsd.org" , phk@freebsd.org Subject: Re: [PATCH] ipfwpcap(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: Tue, 18 Dec 2007 12:17:09 -0000 ------------GJeOyVu3xITaB9Flyz9pX0 Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r Content-Transfer-Encoding: 8bit 18.12.07 @ 17:21 Sergey Matveychuk wrote: >> I've recently found a patch (also available at >> http://antigreen.org/vadim/freebsd/ipfwpcap/) made by me and my friend >> in January to ipfwpcap(8) introduced in 7.0. Now it have more features, > > Unfortunately too old to apply. Mislooked that, sorry. But revision 1.3 differs only with line signal (SIGINT, ...); - which my patch also includes. I've attached patch against current revision 1.3 (use it instead of original letter's one). > And using of pidfile_* functions from libutil is preferable IMHO. Surely, but I think that should be another commit, as not a user-visible change. -- WBR, Vadim Goncharov ------------GJeOyVu3xITaB9Flyz9pX0 Content-Disposition: attachment; filename=ipfwpcap.patch Content-Type: application/octet-stream; name=ipfwpcap.patch Content-Transfer-Encoding: 8bit --- ipfwpcap.c.1.3 Tue Dec 18 17:35:14 2007 +++ ipfwpcap.c Tue Dec 19 08:30:00 2006 @@ -1,95 +1,120 @@ +/*- + * Copyright (c) 2004 University of Toronto. All rights reserved. + * Anyone may use or copy this software except that this copyright + * notice remain intact and that credit is given where it is due. + * The University of Toronto and the author make no warranty and + * accept no liability for this software. + * + * $FreeBSD: /repoman/r/ncvs/src/usr.sbin/ipfwpcap/ipfwpcap.c,v 1.2 2006/09/04 19:30:44 sam Exp $ + */ + /* - * copy diverted (or tee'd) packets to a file in 'tcpdump' format + * Copy diverted (or tee'd) packets to a file in 'tcpdump' format * (ie. this uses the '-lpcap' routines). * - * example usage: - * # ipfwpcap -r 8091 divt.log & + * Example usage: + * # ipfwpcap -r 8091 divt.log * # ipfw add 2864 divert 8091 ip from 128.432.53.82 to any * # ipfw add 2864 divert 8091 ip from any to 128.432.53.82 * * the resulting dump file can be read with ... * # tcpdump -nX -r divt.log - */ -/* - * Written by P Kern { pkern [AT] cns.utoronto.ca } * - * Copyright (c) 2004 University of Toronto. All rights reserved. - * Anyone may use or copy this software except that this copyright - * notice remain intact and that credit is given where it is due. - * The University of Toronto and the author make no warranty and - * accept no liability for this software. - * - * From: Header: /local/src/local.lib/SRC/ipfwpcap/RCS/ipfwpcap.c,v 1.4 2004/01/15 16:19:07 pkern Exp - * - * $FreeBSD: src/usr.sbin/ipfwpcap/ipfwpcap.c,v 1.3 2007/10/12 14:57:39 csjp Exp $ + * Written by P Kern { pkern [AT] cns.utoronto.ca } + * Adopted by V Pavluk (vladvic_r@mail.ru) + * - changed sighup handler to reopen log file + * - added sigalrm handler to flush data + * - some of exit() codes changed to sysexits(3) + * Major code reworking by Vadim Goncharov + * - signals and daemonizing rewritten + * - style(9) reformat, more sysexits(3) and other cleanups + * - enabled own alarm sending, changed options and updated man page */ +#include +#include +#include /* For MAXPATHLEN */ +#include +#include + +#include +#include /* For IP_MAXPACKET */ +#include /* For IP_MAXPACKET */ + #include #include #include #include #include #include -#include -#include -#include /* for MAXPATHLEN */ -#include -#include - -#include /* for IP_MAXPACKET */ -#include /* for IP_MAXPACKET */ +#include /* XXX normally defined in config.h */ -#define HAVE_STRLCPY 1 -#define HAVE_SNPRINTF 1 -#define HAVE_VSNPRINTF 1 -#include /* see pcap(3) and /usr/src/contrib/libpcap/. */ +#define HAVE_STRLCPY 1 +#define HAVE_SNPRINTF 1 +#define HAVE_VSNPRINTF 1 +#include /* See pcap(3) and /usr/src/contrib/libpcap/. */ #ifdef IP_MAXPACKET -#define BUFMAX IP_MAXPACKET +#define BUFMAX IP_MAXPACKET #else -#define BUFMAX 65535 +#define BUFMAX 65535 #endif #ifndef MAXPATHLEN #define MAXPATHLEN 1024 #endif -static int debug = 0; -static int reflect = 0; /* 1 == write packet back to socket. */ +#define MAXPIDLEN 9 /* Max decimal pid length in characters. */ +#define DEFINTERVAL 60 /* How often to do flush (in seconds). */ -static ssize_t totbytes = 0, maxbytes = 0; -static ssize_t totpkts = 0, maxpkts = 0; +static char *prog = NULL; +static char pidfile[MAXPATHLEN] = { '\0' }; -char *prog = NULL; -char pidfile[MAXPATHLEN] = { '\0' }; +static int quit = 0; /* Is it time to exit? */ +static int do_flush = 0; /* Time to flush log. */ +static int do_reopen = 0; /* Time for log rotating. */ +static int flush_interval = DEFINTERVAL; /* - * tidy up. + * Tidy up macro. */ -void -quit(sig) -int sig; +#define QUIT(code) do { \ + pcap_dump_flush(dp); \ + (void)unlink(pidfile); \ + exit(code); \ +} while(0); + +void +quit_sig(int sig) +{ + quit = 1; +} + +void +flush_log(int sigalrm) { - (void) unlink(pidfile); - exit(sig); + do_flush = 1; + alarm(flush_interval); +} + +void +reopen_log(int sighup) +{ + do_reopen = 1; } /* - * do the "paper work" - * - save my own pid in /var/run/$0.{port#}.pid + * Do the "paper work". + * - fork and detach from terminal, if needed. + * - save my own pid in /var/run/$0.{port#}.pid. */ -okay(pn) -int pn; +void +okay(int pn, int detach, int nochdir) { - FILE *fp; - int fd, numlen, n; - char *p, numbuf[80]; - - numlen = sizeof(numbuf); - bzero(numbuf, numlen); - snprintf(numbuf, numlen-1, "%ld\n", getpid()); - numlen = strlen(numbuf); + int pf; + char *p, strpid[MAXPIDLEN + 1]; + pid_t pid; if (pidfile[0] == '\0') { p = (char *)rindex(prog, '/'); @@ -99,94 +124,158 @@ "%s%s.%d.pid", _PATH_VARRUN, p, pn); } - fd = open(pidfile, O_WRONLY|O_CREAT|O_EXCL, 0644); - if (fd < 0) { perror(pidfile); exit(21); } + pf = open(pidfile, O_WRONLY | O_CREAT | O_EXCL | O_EXLOCK, 0644); - siginterrupt(SIGTERM, 1); - siginterrupt(SIGHUP, 1); - signal (SIGTERM, quit); - signal (SIGHUP, quit); - signal (SIGINT, quit); - - n = write(fd, numbuf, numlen); - if (n < 0) { perror(pidfile); quit(23); } - (void) close(fd); + /* + * We couldn't create pid file + */ + if (pf == -1) { + if (errno == EEXIST) { + /* + * If it is because it's already exists + */ + bzero(strpid, MAXPIDLEN + 1); + fprintf(stderr, "PID file already exists!\n"); + + /* + * Try to read the PID stored in the existing file + */ + pf = open(pidfile, O_RDONLY); + if (pf == -1) { + perror("Error opening PID file for reading"); + exit(EX_IOERR); + } + if (read(pf, strpid, MAXPIDLEN) < 0) { + perror("Error reading PID file"); + exit(EX_IOERR); + } + pid = atol(strpid); + close(pf); + + /* + * We found PID, try to determine, whether process + * is running + */ + if (kill(pid, 0) == 0) { + /* + * Signal is delivered, though process with + * such PID exists + */ + fprintf(stderr, "%s already running with PID=%d, exiting...\n", prog, pid); + exit(1); + } else { + /* + * It seems, like the process is killed, so + * we can proceed... + */ + fprintf(stderr, "Stale PID file, overwriting...\n"); + pf = open(pidfile, O_WRONLY | O_TRUNC | O_EXLOCK); + if (pf == -1) { + perror("Error opening PID file for writing"); + exit(EX_IOERR); + } + } + } else { + perror("Error creating PID file"); + exit(EX_IOERR); + } + } + + if (detach) { + if (daemon(nochdir, 0) != 0) { + close(pf); + (void)unlink(pidfile); + perror("daemon"); + exit(EX_OSERR); + } + } + + /* + * Set signal handlers and system behaviour. This must be done + * before saving PID to prevent small, but possible race condition + * when another instance failed to create PID, reads it and tries + * to send signal to us. + */ + siginterrupt(SIGTERM, 1); + siginterrupt(SIGHUP, 1); + + /* Ignore 0th signal, or process may be killed with it by default... */ + signal(0, SIG_IGN); + signal(SIGINT, quit_sig); + signal(SIGTERM, quit_sig); + signal(SIGHUP, reopen_log); + signal(SIGALRM, flush_log); + + /* Save our PID to pidfile. */ + bzero(strpid, MAXPIDLEN + 1); + snprintf(strpid, MAXPIDLEN, "%ld\n", getpid()); + if (write(pf, strpid, strlen(strpid)) < 0) { + perror("Error writing PID file"); + exit(EX_IOERR); + } + close(pf); } +void usage() { - fprintf(stderr, "\ -\n\ -usage:\n\ - %s [-dr] [-b maxbytes] [-p maxpkts] [-P pidfile] portnum dumpfile\n\ -\n\ -where:\n\ - '-d' = enable debugging messages.\n\ - '-r' = reflect. write packets back to the divert socket.\n\ - (ie. simulate the original intent of \"ipfw tee\").\n\ - '-rr' = indicate that it is okay to quit if packet-count or\n\ - byte-count limits are reached (see the NOTE below\n\ - about what this implies).\n\ - '-b bytcnt' = stop dumping after {bytcnt} bytes.\n\ - '-p pktcnt' = stop dumping after {pktcnt} packets.\n\ - '-P pidfile' = alternate file to store the PID\n\ - (default: /var/run/%s.{portnum}.pid).\n\ -\n\ - portnum = divert(4) socket port number.\n\ - dumpfile = file to write captured packets (tcpdump format).\n\ - (specify '-' to write packets to stdout).\n\ -\n\ -", prog, prog); - - fprintf(stderr, "\ -The '-r' option should not be necessary, but because \"ipfw tee\" is broken\n\ -(see BUGS in ipfw(8) for details) this feature can be used along with\n\ -an \"ipfw divert\" rule to simulate the original intent of \"ipfw tee\".\n\ -\n\ -NOTE: With an \"ipfw divert\" rule, diverted packets will silently\n\ - disappear if there is nothing listening to the divert socket.\n\ -\n\ -"); - exit(-1); + fprintf(stderr, + "usage: %s [-dz] [-r | -rr] [-i flush_interval] [-b maxbytes] [-p maxpkts] [-P pidfile] portnum dumpfile\n", + prog); + + exit(EX_USAGE); } -main(ac, av) -int ac; -char *av[]; +main(int argc, char *argv[]) { int r, sd, portnum, l; - struct sockaddr_in sin; - int errflg = 0; + struct sockaddr_in sin; + int errflg = 0, zeroize = 0; int nfd; fd_set rds; ssize_t nr; - char *dumpf, buf[BUFMAX]; + char buf[BUFMAX]; + + int debug = 0; + int reflect = 0; /* 1 == write packet back to socket. */ + + ssize_t totbytes = 0, maxbytes = 0; + ssize_t totpkts = 0, maxpkts = 0; - pcap_t *p; - pcap_dumper_t *dp; struct pcap_pkthdr phd; + pcap_t *p; + pcap_dumper_t *dp; /* Global, as signal handlers may want it. */ + char *dumpf; - prog = av[0]; + prog = argv[0]; - while ((r = getopt(ac, av, "drb:p:P:")) != -1) { + while ((r = getopt(argc, argv, "drzb:i:p:P:")) != -1) { switch (r) { case 'd': - debug++; + debug = 1; break; case 'r': reflect++; break; + case 'i': + flush_interval = atoi(optarg); + if ((flush_interval < 5) || (flush_interval > 3600)) + flush_interval = DEFINTERVAL; + break; case 'b': - maxbytes = (ssize_t) atol(optarg); + maxbytes = (ssize_t)atol(optarg); break; case 'p': - maxpkts = (ssize_t) atoi(optarg); + maxpkts = (ssize_t)atoi(optarg); + break; + case 'z': + zeroize = 1; break; case 'P': - strcpy(pidfile, optarg); + strlcpy(pidfile, optarg, sizeof(pidfile)); break; case '?': default: @@ -195,17 +284,18 @@ } } - if ((ac - optind) != 2 || errflg) + if (((argc - optind) != 2) || errflg) usage(); - portnum = atoi(av[optind++]); - dumpf = av[optind]; + portnum = atoi(argv[optind++]); + dumpf = argv[optind]; -if (debug) fprintf(stderr, "bind to %d.\ndump to '%s'.\n", portnum, dumpf); + if (debug) + fprintf(stderr, "bind to %d.\ndump to '%s'.\n", portnum, dumpf); if ((r = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) == -1) { perror("socket(DIVERT)"); - exit(2); + exit(EX_OSERR); } sd = r; @@ -215,92 +305,136 @@ if (bind(sd, (struct sockaddr *)&sin, sizeof(sin)) == -1) { perror("bind(divert)"); - exit(3); + exit(EX_OSERR); } p = pcap_open_dead(DLT_RAW, BUFMAX); dp = pcap_dump_open(p, dumpf); if (dp == NULL) { pcap_perror(p, dumpf); - exit(4); + exit(EX_OSFILE); } + + /* + * We will not chdir() to root directory if user specified + * non-absolute pathname to logfile, because in this case + * logfile will be created in another directory after first + * reopening on SIGHUP. + */ + okay(portnum, !debug, dumpf[0] == '/' ? 0 : 1); - okay(portnum); + alarm(flush_interval); /* Start timer. */ nfd = sd + 1; - for (;;) { + while (!quit) { + /* + * Handle signal actions on next iteration after select()'s EINTR. + */ + if (do_flush) { + if (debug) + fprintf(stderr, "Flushing log.\n"); + pcap_dump_flush(dp); + do_flush = 0; + } + + if (do_reopen) { + if (debug) + fprintf(stderr, "Reopening log.\n"); + pcap_dump_close(dp); + dp = pcap_dump_open(p, dumpf); + if (zeroize) { + totbytes = 0; + totpkts = 0; + } + do_reopen = 0; + } + + /* Prepare for select(). */ FD_ZERO(&rds); FD_SET(sd, &rds); r = select(nfd, &rds, NULL, NULL, NULL); if (r == -1) { - if (errno == EINTR) continue; + if (errno == EINTR) + continue; perror("select"); - quit(11); + QUIT(EX_OSERR); } - if (!FD_ISSET(sd, &rds)) - /* hmm. no work. */ - continue; + continue; /* Hmm. No work. */ /* - * use recvfrom(3 and sendto(3) as in natd(8). - * see /usr/src/sbin/natd/natd.c - * see ipfw(8) about using 'divert' and 'tee'. + * Use recvfrom(3 and sendto(3) as in natd(8). + * See /usr/src/sbin/natd/natd.c. + * See ipfw(8) about using 'divert' and 'tee'. */ /* - * read packet. + * Read packet. */ l = sizeof(sin); nr = recvfrom(sd, buf, sizeof(buf), 0, (struct sockaddr *)&sin, &l); -if (debug) fprintf(stderr, "recvfrom(%d) = %d (%d)\n", sd, nr, l); - if (nr < 0 && errno != EINTR) { + + if (debug) + fprintf(stderr, "recvfrom(%d) = %d (%d)\n", sd, nr, l); + + if ((nr < 0) && (errno != EINTR)) { perror("recvfrom(sd)"); - quit(12); + QUIT(EX_IOERR); } - if (nr <= 0) continue; + if (nr <= 0) + continue; - if (reflect) { + if (reflect > 0) { /* - * write packet back so it can continue - * being processed by any further IPFW rules. + * Write packet back so it can continue being + * processed by any further IPFW rules. */ l = sizeof(sin); r = sendto(sd, buf, nr, 0, (struct sockaddr *)&sin, l); -if (debug) fprintf(stderr, " sendto(%d) = %d\n", sd, r); - if (r < 0) { perror("sendto(sd)"); quit(13); } + if (debug) + fprintf(stderr, "sendto(%d) = %d\n", sd, r); + if (r < 0) { + perror("sendto(sd)"); + QUIT(EX_IOERR); + } } /* - * check maximums, if any. - * but don't quit if must continue reflecting packets. + * Check maximums, if any. But don't quit if must continue + * reflecting packets. However, it's ok to exit when + * reflect > 1. */ if (maxpkts) { totpkts++; if (totpkts > maxpkts) { - if (reflect == 1) continue; - quit(0); + if (reflect == 1) + continue; + QUIT(EX_OK); } } if (maxbytes) { totbytes += nr; if (totbytes > maxbytes) { - if (reflect == 1) continue; - quit(0); + if (reflect == 1) + continue; + QUIT(EX_OK); } } /* - * save packet in tcpdump(1) format. see pcap(3). - * divert packets are fully assembled. see ipfw(8). + * Save packet in tcpdump(1) format. See pcap(3). Divert + * packets are fully assembled, see ipfw(8). */ - (void) gettimeofday(&(phd.ts), NULL); + (void)gettimeofday(&(phd.ts), NULL); phd.caplen = phd.len = nr; pcap_dump((u_char *)dp, &phd, buf); - if (ferror((FILE *)dp)) { perror(dumpf); quit(14); } - (void) fflush((FILE *)dp); + if (ferror((FILE *)dp)) { + perror(dumpf); + QUIT(EX_IOERR); + } + } - quit(0); + QUIT(EX_OK); } --- ipfwpcap.8.orig Sat Nov 11 05:08:21 2006 +++ ipfwpcap.8 Thu Dec 21 09:04:28 2006 @@ -24,7 +24,7 @@ .\" .\" $FreeBSD: /repoman/r/ncvs/src/usr.sbin/ipfwpcap/ipfwpcap.8,v 1.3 2006/09/30 19:07:03 ru Exp $ .\" -.Dd May 22, 2006 +.Dd Dec 20, 2006 .Dt IPFWPCAP 8 .Os .Sh NAME @@ -32,7 +32,9 @@ .Nd "copy diverted packets to a file in tcpdump format" .Sh SYNOPSIS .Nm -.Op Fl dr +.Op Fl dz +.Op Fl r | rr +.Op Fl i Ar flush_interval .Op Fl b Ar maxbytes .Op Fl p Ar maxpkts .Op Fl P Ar pidfile @@ -48,19 +50,44 @@ .Xr ipfw 8 to a port on which .Nm -listens. +daemon listens. The packets are then dropped unless .Fl r is used. .Pp +.Nm +closes and then re-opens the dump file when it receives +.Dv SIGHUP , +permitting +.Xr newsyslog 8 +to rotate dump logfiles automatically. +Note that already existing file will be truncated on open or re-open. +Receiving +.Dv SIGALRM +causes +.Nm +to flush the current logfile buffers to the disk, thus making the most +recent logs available. +The buffers are also flushed every +.Ar flush_interval +seconds. +.Pp The options are as follows: .Bl -tag -width indent .It Fl d -Turns on extra debugging messages. +Turns on debugging messages and prevents +.Nm +from making itself a background daemon. .It Fl r Writes packets back to the .Xr divert 4 socket. +This option can be used to reflect packets back to +.Xr ipfw 8 +if you for some reasons want to use +.Dq divert +rule action instead of usually more suitable +.Dq tee . .It Fl rr Indicates that it is okay to quit if .Ar maxbytes @@ -74,6 +101,17 @@ Stop dumping after .Ar maxbytes bytes. +Note that size of resulting +.Ar dumpfile +will be greater than +.Ar maxbytes +because +.Xr pcap 3 +stores additional headers for each packet in the file. +.It Fl i Ar flush_interval +Time in seconds to delay between automatic flushes of the file. +This may be specified with a value between 5 and 3600 seconds. +If not specified, the default is 60 seconds. .It Fl p Ar maxpkts Stop dumping after .Ar maxpkt @@ -81,7 +119,10 @@ .It Fl P Ar pidfile File to store PID number in. Default is -.Pa /var/run/ipwfpcap.portnr.pid . +.Pa /var/run/ipwfpcap. Ns Ao Ar portnum Ac Ns Pa .pid . +.It Fl z +Reset byte and packet counters to zero after each reopening of the +.Ar dumpfile . .El .Pp The @@ -98,7 +139,7 @@ .Sh EXIT STATUS .Ex -std .Sh EXAMPLES -.Dl "ipfwpcap -r 8091 divt.log &" +.Dl "ipfwpcap -r 8091 divt.log" .Pp Starts .Nm @@ -117,12 +158,13 @@ .Xr tcpdump 1 , .Xr pcap 3 , .Xr divert 4 , -.Xr ipfw 8 +.Xr ipfw 8 , +.Xr pflogd 8 .Sh HISTORY The .Nm utility first appeared in -.Fx 7.0 . +.Fx 6.3 . .Sh AUTHORS .An -nosplit .Nm ------------GJeOyVu3xITaB9Flyz9pX0-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 12:37:02 2007 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 5481216A419; Tue, 18 Dec 2007 12:37:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id D586C13C469; Tue, 18 Dec 2007 12:37:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBICapqd006882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 23:36:53 +1100 Date: Tue, 18 Dec 2007 23:36:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Scott Long In-Reply-To: <47676E96.4030708@samsco.org> Message-ID: <20071218233644.U756@besplex.bde.org> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 12:37:02 -0000 On Mon, 17 Dec 2007, Scott Long wrote: > Bruce Evans wrote: >> On Mon, 17 Dec 2007, David G Lawrence wrote: >> >>> One more comment on my last email... The patch that I included is not >>> meant as a real fix - it is just a bandaid. The real problem appears to >>> be that a very large number of vnodes (all of them?) are getting synced >>> (i.e. calling ffs_syncvnode()) every time. This should normally only >>> happen for dirty vnodes. I suspect that something is broken with this >>> check: >>> >>> if (vp->v_type == VNON || ((ip->i_flag & >>> (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && >>> vp->v_bufobj.bo_dirty.bv_cnt == 0)) { >>> VI_UNLOCK(vp); >>> continue; >>> } >> >> Isn't it just the O(N) algorithm with N quite large? Under ~5.2, on > Right, it's a non-optimal loop when N is very large, and that's a fairly > well understood problem. I think what DG was getting at, though, is > that this massive flush happens every time the syncer runs, which > doesn't seem correct. Sure, maybe you just rsynced 100,000 files 20 > seconds ago, so the upcoming flush is going to be expensive. But the > next flush 30 seconds after that shouldn't be just as expensive, yet it > appears to be so. I'm sure it doesn't cause many bogus flushes. iostat shows zero writes caused by calling this incessantly using "while :; do sync; done". > This is further supported by the original poster's > claim that it takes many hours of uptime before the problem becomes > noticeable. If vnodes are never truly getting cleaned, or never getting > their flags cleared so that this loop knows that they are clean, then > it's feasible that they'll accumulate over time, keep on getting flushed > every 30 seconds, keep on bogging down the loop, and so on. Using "find / >/dev/null" to grow the problem and make it bad after a few seconds of uptime, and profiling of a single sync(2) call to show that nothing much is done except the loop containing the above: under ~5.2, on a 2.2GHz A64 UP ini386 mode: after booting, with about 700 vnodes: % % cumulative self self total % time seconds seconds calls ns/call ns/call name % 30.8 0.000 0.000 0 100.00% mcount [4] % 14.9 0.001 0.000 0 100.00% mexitcount [5] % 5.5 0.001 0.000 0 100.00% cputime [16] % 5.0 0.001 0.000 6 13312 13312 vfs_msync [18] % 4.3 0.001 0.000 0 100.00% user [21] % 3.5 0.001 0.000 5 11321 11993 ffs_sync [23] after "find / >/dev/null" was stopped after saturating at 64000 vnodes (desiredvodes is 70240): % % cumulative self self total % time seconds seconds calls ns/call ns/call name % 50.7 0.008 0.008 5 1666427 1667246 ffs_sync [5] % 38.0 0.015 0.006 6 1041217 1041217 vfs_msync [6] % 3.1 0.015 0.001 0 100.00% mcount [7] % 1.5 0.015 0.000 0 100.00% mexitcount [8] % 0.6 0.015 0.000 0 100.00% cputime [22] % 0.6 0.016 0.000 34 2660 2660 generic_bcopy [24] % 0.5 0.016 0.000 0 100.00% user [26] vfs_msync() is a problem too. It uses an almost identical loop for the case where the vnode is not dirty (but has a different condition for being dirty). ffs_sync() is called 5 times because there are 5 ffs file systems mounted r/w. There is another ffs file system mounted r/o and that combined with a missing r/o optimization might give the extra call to vfs_msync(). With 64000 vnodes, the calls take 1-2 ms each. That is already quite a lot, and there are many calls. Each call only looks at vnodes under the mount point so the number of mounted file systems doesn't affect the total time much. ffs_sync() i taking 125 ns per vnode. That is a more than I would have expected. Bruce From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 14:17:43 2007 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 AC8CE16A419; Tue, 18 Dec 2007 14:17:43 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 716BE13C4F2; Tue, 18 Dec 2007 14:17:43 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBIEHgwi017772; Tue, 18 Dec 2007 06:17:42 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBIEHg1v017771; Tue, 18 Dec 2007 06:17:42 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Tue, 18 Dec 2007 06:17:42 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071218141742.GS25053@tnn.dglawrence.com> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218233644.U756@besplex.bde.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Tue, 18 Dec 2007 06:17:42 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 14:17:43 -0000 > >Right, it's a non-optimal loop when N is very large, and that's a fairly > >well understood problem. I think what DG was getting at, though, is > >that this massive flush happens every time the syncer runs, which > >doesn't seem correct. Sure, maybe you just rsynced 100,000 files 20 > >seconds ago, so the upcoming flush is going to be expensive. But the > >next flush 30 seconds after that shouldn't be just as expensive, yet it > >appears to be so. > > I'm sure it doesn't cause many bogus flushes. iostat shows zero writes > caused by calling this incessantly using "while :; do sync; done". I didn't say it caused any bogus disk I/O. My original problem (after a day or two of uptime) was an occasional large scheduling delay for a process that needed to process VoIP frames in real-time. It was happening every 31 seconds and was causing voice frames to be dropped due to the large latency causing the frame to be outside of the jitter window. I wrote a program that measures the scheduling delay by sleeping for one tick and then comparing the timeofday offset from what was expected. This revealed that every 31 seconds, the process was seeing a 17ms delay in scheduling. Further investigation found that 1) the syncer was the process that was running every 31 seconds and causing the delay (and it was the only one in the system with that timing interval), and that 2) lowering the kern.maxvnodes to something lowish (5000) would mostly mitigate the problem. The patch to limit the number of vnodes to process in the loop before sleeping was then developed and it completely resolved the problem. Since the wait that I added is at the bottom of the loop and the limit is 500 vnodes, this tells me that every 31 seconds, there are a whole lot of vnodes that are being "synced", when there shouldn't have been any (this fact wasn't apparent to me at the time, but when I later realized this, I had no time to investigate further). My tests and analysis have all been on an otherwise quiet system (no disk I/O), so the bottom of the ffs_sync vnode loop should not have been reached at all, let alone tens of thousands of times every 31 seconds. All machines were uni- processor, FreeBSD 6+. I don't know if this problem is present in 5.2. I didn't see ffs_syncvnode in your call graph, so it probably is not. Anyway, someone needs to instrument the vnode loop in ffs_sync and figure out what is going on. As you've pointed out, it is necessary to first read a lot of files (I use tar to /dev/null and make sure it reads at least 100K files) in order to get the vnodes allocated. As I mentioned previously, I suspect that either ip->i_flag is not getting completely cleared in ffs_syncvnode or its children or v_bufobj.bo_dirty.bv_cnt accounting is broken. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 14:33:31 2007 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 8CEA616A419 for ; Tue, 18 Dec 2007 14:33:31 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E3FC313C459 for ; Tue, 18 Dec 2007 14:33:30 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A7965.dip.t-dialin.net [84.154.121.101]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lBIEXSuJ092251 for ; Tue, 18 Dec 2007 14:33:29 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id lBIEYBSK048067 for ; Tue, 18 Dec 2007 15:34:11 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lBIEY6jB095569 for ; Tue, 18 Dec 2007 15:34:11 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200712181434.lBIEY6jB095569@fire.js.berklix.net> To: stable@freebsd.org In-reply-to: <200712181108.lBIB8rAL090380@fire.js.berklix.net> References: <200712181108.lBIB8rAL090380@fire.js.berklix.net> Comments: In-reply-to "Julian Stacey" message dated "Tue, 18 Dec 2007 12:08:53 +0100." Date: Tue, 18 Dec 2007 15:34:06 +0100 From: "Julian H. Stacey" Cc: Subject: Re: 7.0BETA4 /usr/src/gnu/usr.bin/cc/cc_int Thrashes 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, 18 Dec 2007 14:33:31 -0000 > Has 7.0-BETA4 perhaps wrongly got a -pipe in the .mk macros ? > Please someone with generic 7.0BETA4 check with eg: > A single line /etc/make.conf > CFLAGS += -Dzonk=bla > ~/tmp/Makefile > tst: > @echo "XX ${CFLAGS} YY" > make tst > XX -O2 -fno-strict-aliasing -pipe -Dzonk=bla YY > Is pipe coming from generic mk/ ? > Or from my local hacked version ? > Could someone test please: > My /usr/src is no longer generic, on a very slow CPU, SLIP > linked, building rest of src/ & I'm about to go away, & > will miss the 7-RELEASE date, but -pipe should not be in > generic, needs to be a host dependent choice. ) Error found. I will send-pr. Patch below stored in : http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/share/mk/sys.mk.REL=ALL.diff pipe should not be on by default as - It cripples machines with limited memory. - Pipe can be enabled by any memory rich host in /etc/make.conf with: CFLAGS += -pipe - Man cc lists how to turn it on but not off. - Man cc also notes assembler problems *** /pub/FreeBSD/branches/-current/src/share/mk/sys.mk.orig Tue Dec 18 15:11:26 2007 --- /pub/FreeBSD/branches/-current/src/share/mk/sys.mk Tue Dec 18 15:12:23 2007 *************** *** 36,44 **** .else CC ?= cc .if ${MACHINE_ARCH} == "arm" ! CFLAGS ?= -O -fno-strict-aliasing -pipe .else ! CFLAGS ?= -O2 -fno-strict-aliasing -pipe .endif .if defined(NO_STRICT_ALIASING) CFLAGS += -fno-strict-aliasing --- 36,44 ---- .else CC ?= cc .if ${MACHINE_ARCH} == "arm" ! CFLAGS ?= -O -fno-strict-aliasing .else ! CFLAGS ?= -O2 -fno-strict-aliasing .endif .if defined(NO_STRICT_ALIASING) CFLAGS += -fno-strict-aliasing *** 6.2-RELEASE/src/share/mk/sys.mk.orig Tue Sep 18 09:32:40 2007 --- 6.2-RELEASE/src/share/mk/sys.mk Tue Dec 18 15:21:09 2007 *************** *** 35,41 **** CFLAGS ?= -O .else CC ?= cc ! CFLAGS ?= -O2 -fno-strict-aliasing -pipe .endif CXX ?= c++ --- 35,41 ---- CFLAGS ?= -O .else CC ?= cc ! CFLAGS ?= -O2 -fno-strict-aliasing .endif CXX ?= c++ -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 14:41:35 2007 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 05D5F16A418; Tue, 18 Dec 2007 14:41:35 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id C345413C45B; Tue, 18 Dec 2007 14:41:34 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBIEfXxC033146; Tue, 18 Dec 2007 06:41:33 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBIEfXlY033145; Tue, 18 Dec 2007 06:41:33 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Tue, 18 Dec 2007 06:41:33 -0800 From: David G Lawrence To: Mark Fullmer Message-ID: <20071218144133.GT25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Tue, 18 Dec 2007 06:41:33 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 14:41:35 -0000 > Thanks. Have a kernel building now. It takes about a day of uptime > after reboot before I'll see the problem. You may also wish to try to get the problem to occur sooner after boot on a non-patched system by doing a "tar cf /dev/null /" (note: substitute /dev/zero instead of /dev/null, if you use GNU tar, to disable its "optimization"). You can stop it after it has gone through a 100K files. Verify by looking at "sysctl vfs.numvnodes". Doing this would help to further prove that lots of allocated vnodes is the prerequisite for the problem. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 15:17:30 2007 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 4022D16A417 for ; Tue, 18 Dec 2007 15:17:30 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from mail.webreality.org (mailserver.webreality.org [217.75.141.5]) by mx1.freebsd.org (Postfix) with ESMTP id CDFBA13C455 for ; Tue, 18 Dec 2007 15:17:28 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from [10.0.1.100] (unknown [87.121.18.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webreality.org (Postfix) with ESMTP id 087CAFFEA96 for ; Tue, 18 Dec 2007 17:00:24 +0200 (EET) Message-ID: <4767E08C.2090803@lozenetz.org> Date: Tue, 18 Dec 2007 17:00:28 +0200 From: Anton - Valqk User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-HostIT-MailScanner-Information: Please contact the ISP for more information X-HostIT-MailScanner: Found to be clean X-HostIT-MailScanner-From: lists@lozenetz.org Cc: Subject: jlogin.sh - a small nice jails helper! 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, 18 Dec 2007 15:17:30 -0000 Because I'm lazy and love the scripts, I wrote a nice small script that matches a jailname and do a jexec JAILPID SHELL so I can login fast to my jails. According to me, there should be such tool! Hopes something like this goes to STABLE! here it is.... #!/bin/sh loginSHELL="/bin/tcsh" [ -z "$1" ] && echo "No jail specified." && exit 1; jName=$1; jID=`jls | awk '{print $1,$3}'|grep $jName|awk '{print $1}'` jRealName=`jls | awk '{print $1,$3}'|grep $jName|awk '{print $2}'` [ -z "$jID" ] && echo "No such jail name $jName!" && exit 1; echo "Logging in to $jRealName" jexec $jID $loginSHELL -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 15:19:38 2007 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 4A31316A47B; Tue, 18 Dec 2007 15:19:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id AC6CF13C501; Tue, 18 Dec 2007 15:19:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBIFJSa2029561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2007 02:19:31 +1100 Date: Wed, 19 Dec 2007 02:19:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David G Lawrence In-Reply-To: <20071218144133.GT25053@tnn.dglawrence.com> Message-ID: <20071219020952.A34422@delplex.bde.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> <20071218144133.GT25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 15:19:38 -0000 On Tue, 18 Dec 2007, David G Lawrence wrote: >> Thanks. Have a kernel building now. It takes about a day of uptime >> after reboot before I'll see the problem. > > You may also wish to try to get the problem to occur sooner after boot > on a non-patched system by doing a "tar cf /dev/null /" (note: substitute > /dev/zero instead of /dev/null, if you use GNU tar, to disable its > "optimization"). You can stop it after it has gone through a 100K files. > Verify by looking at "sysctl vfs.numvnodes". Hmm, I said to use "find /", but that is not so good since it only looks at directories and directories (and their inodes) are not packed as tightly as files (and their inodes). Optimized tar, or "find / -type f", or "ls -lR /", should work best, by doing not much more than stat()ing lots of files, while full tar wastes time reading file data. Bruce From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 15:22:20 2007 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 607B416A420; Tue, 18 Dec 2007 15:22:19 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 25E2A13C4E8; Tue, 18 Dec 2007 15:22:19 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBIFMI5p059376; Tue, 18 Dec 2007 07:22:18 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBIFMIUi059375; Tue, 18 Dec 2007 07:22:18 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Tue, 18 Dec 2007 07:22:18 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071218152217.GU25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <089C1524-B8E0-4C70-B69A-ECBE0C8DFC90@eng.oar.net> <20071218144133.GT25053@tnn.dglawrence.com> <20071219020952.A34422@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219020952.A34422@delplex.bde.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Tue, 18 Dec 2007 07:22:18 -0800 (PST) Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 15:22:20 -0000 > On Tue, 18 Dec 2007, David G Lawrence wrote: > > >>Thanks. Have a kernel building now. It takes about a day of uptime > >>after reboot before I'll see the problem. > > > > You may also wish to try to get the problem to occur sooner after boot > >on a non-patched system by doing a "tar cf /dev/null /" (note: substitute > >/dev/zero instead of /dev/null, if you use GNU tar, to disable its > >"optimization"). You can stop it after it has gone through a 100K files. > >Verify by looking at "sysctl vfs.numvnodes". > > Hmm, I said to use "find /", but that is not so good since it only > looks at directories and directories (and their inodes) are not packed > as tightly as files (and their inodes). Optimized tar, or "find / > -type f", or "ls -lR /", should work best, by doing not much more than > stat()ing lots of files, while full tar wastes time reading file data. I have no reason to believe that just reading directories will reproduce the problem with file vnodes. You need to open the files and read them. Nothing else will do. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 15:29:39 2007 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 3025916A468 for ; Tue, 18 Dec 2007 15:29:39 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id D51BD13C461 for ; Tue, 18 Dec 2007 15:29:38 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J4eO1-00015V-TR for freebsd-stable@FreeBSD.ORG; Tue, 18 Dec 2007 15:29:37 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J4eO1-0003vb-RF for freebsd-stable@FreeBSD.ORG; Tue, 18 Dec 2007 15:29:37 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4eO1-0000Fq-QX for freebsd-stable@FreeBSD.ORG; Tue, 18 Dec 2007 15:29:37 +0000 To: freebsd-stable@FreeBSD.ORG Message-Id: From: Pete French Date: Tue, 18 Dec 2007 15:29:37 +0000 Cc: Subject: Problem with 'reply' in /usr/bin/mail 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, 18 Dec 2007 15:29:39 -0000 Just revently I have been having some problems using 'mail' - unfortunately I dont know if it predates my upgrade to 7.0 or not, but basically the symptom is that when doing a simple reply to mail sent from some windows machines it only replies to the send and the last person in the 'To' line rather than to all of them. Extremely annoying - but I am nto sure if mail has chnaged or if the Microsoft users have changed their systems to addresse are slightly sifferent: Anyway, the email lines look like this: #From: "Jane Drakesmith" #To: "Emma Farmer" ,"Robin Allen" ,"Adam Stott Everett" ,"Phil Wright" ,"Jason McLaughlin" ,"Pete French" ,"Michelle Hurst" ,"Jon Dalladay" ,"Jac Evans" #Subject: RE: Christmas opening times If I hit 'r' then I get: #To: Jac@ticketswitch.com JaneDrakesmith@ticketswitch.com #Subject: RE: Christmas opening times All the previous people in the 'To:' line are missed out. Does anyone else see this ? I am sure it didn't used to behave this way.... -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 16:20:40 2007 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 8861C16A46B; Tue, 18 Dec 2007 16:20:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 10CCA13C4D1; Tue, 18 Dec 2007 16:20:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBIGKSE0008461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2007 03:20:31 +1100 Date: Wed, 19 Dec 2007 03:20:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David G Lawrence In-Reply-To: <20071218141742.GS25053@tnn.dglawrence.com> Message-ID: <20071219022102.I34422@delplex.bde.org> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 16:20:40 -0000 On Tue, 18 Dec 2007, David G Lawrence wrote: > I didn't say it caused any bogus disk I/O. My original problem > (after a day or two of uptime) was an occasional large scheduling delay > for a process that needed to process VoIP frames in real-time. It was > happening every 31 seconds and was causing voice frames to be dropped > due to the large latency causing the frame to be outside of the jitter > window. I wrote a program that measures the scheduling delay by sleeping > for one tick and then comparing the timeofday offset from what was > expected. This revealed that every 31 seconds, the process was seeing > a 17ms delay in scheduling. Further investigation found that 1) the I got an almost identical delay (with 64000 vnodes). Now, 17ms isn't much. Delays much have been much longer when CPUs were many times slower and RAM/vnodes were not so many times smaller. High-priority threads just need to be able to preempt the syncer so that they don't lose data (unless really hard real time is supported, which it isn't). This should work starting with about FreeBSD-6 (probably need "options PREEMPT"). I doesn't work in ~5.2 due to Giant locking, but I find Giant locking to rarely matter for UP. Old versions of FreeBSD were only able to preempt to non-threads (interrupt handlers) yet they somehow survived the longer delays. They didn't have Giant locking to get in the way, and presumably avoided packet loss by doing lots in interrupt handlers (hardware isr and netisr). I just remembered that I have seen packet loss even under -current when I leave out or turn off "options PREEMPT". > ... > and it completely resolved the problem. Since the wait that I added > is at the bottom of the loop and the limit is 500 vnodes, this tells > me that every 31 seconds, there are a whole lot of vnodes that are > being "synced", when there shouldn't have been any (this fact wasn't > apparent to me at the time, but when I later realized this, I had > no time to investigate further). My tests and analysis have all been > on an otherwise quiet system (no disk I/O), so the bottom of the > ffs_sync vnode loop should not have been reached at all, let alone > tens of thousands of times every 31 seconds. All machines were uni- > processor, FreeBSD 6+. I don't know if this problem is present in 5.2. > I didn't see ffs_syncvnode in your call graph, so it probably is not. I chopped to a float profile with only top callers. Any significant calls from ffs_sync() would show up as top callers. I still have the data, and the call graph shows much more clearly that there was just one dirty vnode for the whole sync(): % 0.00 0.01 1/1 syscall [3] % [4] 88.7 0.00 0.01 1 sync [4] % 0.01 0.00 5/5 ffs_sync [5] % 0.01 0.00 6/6 vfs_msync [6] % 0.00 0.00 7/8 vfs_busy [260] % 0.00 0.00 7/8 vfs_unbusy [263] % 0.00 0.00 6/7 vn_finished_write [310] % 0.00 0.00 6/6 vn_start_write [413] % 0.00 0.00 1/1 vfs_stdnosync [472] % % ----------------------------------------------- % % 0.01 0.00 5/5 sync [4] % [5] 50.7 0.01 0.00 5 ffs_sync [5] % 0.00 0.00 1/1 ffs_fsync [278] % 0.00 0.00 1/60 vget [223] % 0.00 0.00 1/60 ufs_vnoperatespec [78] % 0.00 0.00 1/26 vrele [76] It passed the flags test just once to get to the vget(). ffs_syncvnode() doesn't exist in 5.2, and ffs_fsync() is called instead. % % ----------------------------------------------- % % 0.01 0.00 6/6 sync [4] % [6] 38.0 0.01 0.00 6 vfs_msync [6] % % ----------------------------------------------- % ... % % 0.00 0.00 1/1 ffs_sync [5] % [278] 0.0 0.00 0.00 1 ffs_fsync [278] % 0.00 0.00 1/1 ffs_update [368] % 0.00 0.00 1/4 vn_isdisk [304] This is presumbly to sync the 1 dirty vnode. BTW I use noatime a lot, including for all file systems used in the test, so the tree walk didn't dirty any vnodes. A tar to /dev/zero would dirty all vnodes if everything were mounted without this option. % ... % % cumulative self self total % time seconds seconds calls ns/call ns/call name % 50.7 0.008 0.008 5 1666427 1667246 ffs_sync [5] % 38.0 0.015 0.006 6 1041217 1041217 vfs_msync [6] % 3.1 0.015 0.001 0 100.00% mcount [7] % 1.5 0.015 0.000 0 100.00% mexitcount [8] % 0.6 0.015 0.000 0 100.00% cputime [22] % 0.6 0.016 0.000 34 2660 2660 generic_bcopy [24] % 0.5 0.016 0.000 0 100.00% user [26] Bruce From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 16:57:33 2007 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 5C69C16A417; Tue, 18 Dec 2007 16:57:33 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 20E1213C459; Tue, 18 Dec 2007 16:57:32 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBIGvWsD020266; Tue, 18 Dec 2007 08:57:32 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBIGvWU6020265; Tue, 18 Dec 2007 08:57:32 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Tue, 18 Dec 2007 08:57:32 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071218165732.GV25053@tnn.dglawrence.com> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219022102.I34422@delplex.bde.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Tue, 18 Dec 2007 08:57:32 -0800 (PST) Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 16:57:33 -0000 > I got an almost identical delay (with 64000 vnodes). > > Now, 17ms isn't much. Says you. On modern systems, trying to run a pseudo real-time application on an otherwise quiescent system, 17ms is just short of an eternity. I agree that the syncer should be preemptable (which is what my bandaid patch attempts to do), but that probably wouldn't have helped my specific problem since my application was a user process, not a kernel thread. All of my systems have options PREEMPTION - that is the default in 6+. It doesn't affect this problem. On the other hand, the syncer shouldn't be consuming this much CPU in the first place. There is obviously a bug here. Of course looking through all of the vnodes in the system for something dirty is stupid in the first place; there should be a seperate list for that. ...but a simple fix is what is needed right now. I'm going to have to bow out of this discussion now. I just don't have the time for it. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 18:07:37 2007 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 51C5016A419 for ; Tue, 18 Dec 2007 18:07:37 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EF84613C455 for ; Tue, 18 Dec 2007 18:07:36 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J4gqS-0003UQ-Eq for freebsd-stable@freebsd.org; Tue, 18 Dec 2007 18:07:08 +0000 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Dec 2007 18:07:08 +0000 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Dec 2007 18:07:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Joshua Coombs Date: Tue, 18 Dec 2007 13:06:42 -0500 Lines: 30 Message-ID: References: <20071213220841.116ba698.maxx@mobistarmail.be> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <20071213220841.116ba698.maxx@mobistarmail.be> Sender: news Subject: Re: FreeBSD 7 on old SMP server? 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, 18 Dec 2007 18:07:37 -0000 MaXX wrote: > Hi list, > > I have an old netfinity 7000 (Quad PIII 500, 1Gb RAM) running 6.2 at the moment. I was wondering if it will take benefit of all the SMP improvement of 7 or is it too old? It runs a few postgresql databases, peak loads in the 2 to 4 range. > > As I do not have another equivalent machine, I prefer to ask before trying myself. > > I quite happy with the performances of my laptop (centrino duo) under 7, and hope my old server will be as happy as my laptop. > > > thanks in advance, > -- > MaXX My hacked up 386 showed gains going from 6.2 to 7, the big win that I've noticed is scp throughput, I can sustain 40 to 45kbps where in the past the box walled at around 30kbps. Apache seems to have less latency responding to gets also. I'm just running a 7b3 kernel at the moment, I'm going to have to repartition with a lot more swap space to be able to build a 7 world (When did the ram use for a buildworld skyrocket?!) but even with this setup, 7 + ULE is a win for me. My other test case is a dual P3 1ghz box, running qmail, and moving from 6 to 7 has given me a decent boost in mail throughput capacity. (The box can now sustain approx 250 messages a second where before it would start backlogging before 200 messages a second.) http://www.x386.net/about.html Josh C From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 18:10:24 2007 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 4388916A41A; Tue, 18 Dec 2007 18:10:24 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 083A813C4E8; Tue, 18 Dec 2007 18:10:23 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBIIANZd067229; Tue, 18 Dec 2007 10:10:23 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBIIANK3067228; Tue, 18 Dec 2007 10:10:23 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Tue, 18 Dec 2007 10:10:23 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071218181023.GW25053@tnn.dglawrence.com> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218165732.GV25053@tnn.dglawrence.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Tue, 18 Dec 2007 10:10:23 -0800 (PST) Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 18:10:24 -0000 > > I got an almost identical delay (with 64000 vnodes). > > > > Now, 17ms isn't much. > > Says you. On modern systems, trying to run a pseudo real-time application > on an otherwise quiescent system, 17ms is just short of an eternity. I agree > that the syncer should be preemptable (which is what my bandaid patch > attempts to do), but that probably wouldn't have helped my specific problem > since my application was a user process, not a kernel thread. One more followup (I swear I'm done, really!)... I have a laptop here that runs at 150MHz when it is in the lowest running CPU power save mode. At that speed, this bug causes a delay of more than 300ms and is enough to cause loss of keyboard input. I have to switch into high speed mode before I try to type anything, else I end up with random typos. Very annoying. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 20:26:36 2007 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 9115016A46B for ; Tue, 18 Dec 2007 20:26:36 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [82.208.36.70]) by mx1.freebsd.org (Postfix) with ESMTP id 41B4713C465 for ; Tue, 18 Dec 2007 20:26:36 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A947619E023; Tue, 18 Dec 2007 21:06:54 +0100 (CET) Received: from [192.168.1.2] (r3a200.net.upc.cz [213.220.192.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id 9774E19E019; Tue, 18 Dec 2007 21:06:48 +0100 (CET) Message-ID: <47682873.8050601@quip.cz> Date: Tue, 18 Dec 2007 21:07:15 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Anton - Valqk References: <4767E08C.2090803@lozenetz.org> In-Reply-To: <4767E08C.2090803@lozenetz.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: jlogin.sh - a small nice jails helper! 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, 18 Dec 2007 20:26:36 -0000 Anton - Valqk wrote: > Because I'm lazy and love the scripts, I wrote a nice small script that > matches a jailname and do a jexec JAILPID SHELL > so I can login fast to my jails. > According to me, there should be such tool! > Hopes something like this goes to STABLE! > > here it is.... > > #!/bin/sh > loginSHELL="/bin/tcsh" > [ -z "$1" ] && echo "No jail specified." && exit 1; > jName=$1; > jID=`jls | awk '{print $1,$3}'|grep $jName|awk '{print $1}'` > jRealName=`jls | awk '{print $1,$3}'|grep $jName|awk '{print $2}'` > [ -z "$jID" ] && echo "No such jail name $jName!" && exit 1; > echo "Logging in to $jRealName" > jexec $jID $loginSHELL It is nice idea, but I think you should have a better scripting style ;) #!/bin/sh login_shell="/bin/tcsh" if [ -z "$1" ]; then echo "No jail specified." exit 1 fi jail_name=$1 jail_id=`jls | awk '$3 ~ /^'${jail_name}'\./ { print $1 }'` jail_hostname=`jls | awk '$3 ~ /^'${jail_name}'\./ { print $3 }'` if [ -z "$jail_id" ]; then echo "No such jail name ${jail_name}!" exit 1 fi echo "Logging in to ${jail_hostname}" jexec $jail_id $login_shell And still there are some imperfections. 1) script assume first part of a hostname as name, but in the rc.conf jail name can be different 2) script does not expect multiple occurrence of the same first part of a hostname example: johndoe.example.org and johndoe.comethingelse.org 3) script does not expect multiple occurrence of exactly matching hostname (coused by jail zombies) Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Dec 18 21:49:31 2007 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 9363916A419 for ; Tue, 18 Dec 2007 21:49:31 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 3732313C4DD for ; Tue, 18 Dec 2007 21:49:31 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 84735 invoked from network); 18 Dec 2007 21:49:30 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 18 Dec 2007 21:49:30 -0000 In-Reply-To: <20071217102433.GQ25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Tue, 18 Dec 2007 16:49:14 -0500 To: David G Lawrence X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 18 Dec 2007 21:49:31 -0000 A little progress. I have a machine with a KTR enabled kernel running. Another machine is running David's ffs_vfsops.c's patch. I left two other machines (GENERIC kernels) running the packet loss test overnight. At ~ 32480 seconds of uptime the problem starts. This is really close to a 16 bit overflow... See http://www.eng.oar.net/~maf/bsd6/ p1.png and http://www.eng.oar.net/~maf/bsd6/p2.png. The missing impulses at 31 second marks are the intervals between test runs. The window of missing packets (timestamps between two packets where a sequence number is missing) is usually less than 4us, altough I'm not sure gettimeofday() can be trusted for measuring this. See https://www.eng.oar.net/~maf/bsd6/ p3.png Things I'll try tonight: o check on the patched kernel o Try KTR debugging enabled before and after an expected high latency period. o Dump all files to /dev/null to trigger the behavior. I would expect the vnode problem to look a little different on the packet loss graphs over time. If this leads anywher I'll add a counter before the msleep() and see how often it's getting there. On Dec 17, 2007, at 5:24 AM, David G Lawrence wrote: > I noticed this as well some time ago. The problem has to do with > the > processing (syncing) of vnodes. When the total number of allocated > vnodes > in the system grows to tens of thousands, the ~31 second periodic sync > process takes a long time to run. Try this patch and let people > know if > it helps your problem. It will periodically wait for one tick (1ms) > every > 500 vnodes of processing, which will allow other things to run. > > Index: ufs/ffs/ffs_vfsops.c > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v > retrieving revision 1.290.2.16 > diff -c -r1.290.2.16 ffs_vfsops.c > *** ufs/ffs/ffs_vfsops.c 9 Oct 2006 19:47:17 -0000 1.290.2.16 > --- ufs/ffs/ffs_vfsops.c 25 Apr 2007 01:58:15 -0000 > *************** > *** 1109,1114 **** > --- 1109,1115 ---- > int softdep_deps; > int softdep_accdeps; > struct bufobj *bo; > + int flushed_count = 0; > > fs = ump->um_fs; > if (fs->fs_fmod != 0 && fs->fs_ronly != 0) { /* XXX */ > *************** > *** 1174,1179 **** > --- 1175,1184 ---- > allerror = error; > vput(vp); > MNT_ILOCK(mp); > + if (flushed_count++ > 500) { > + flushed_count = 0; > + msleep(&flushed_count, MNT_MTX(mp), PZERO, "syncw", 1); > + } > } > MNT_IUNLOCK(mp); > /* > > -DG > > David G. Lawrence > President > Download Technologies, Inc. - http://www.downloadtech.com - (866) > 399 8500 > The FreeBSD Project - http://www.freebsd.org > Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 14:15:55 2007 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 1FF3F16A468; Wed, 19 Dec 2007 14:15:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id B18A313C4D9; Wed, 19 Dec 2007 14:15:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBJEFe3D024477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 01:15:48 +1100 Date: Thu, 20 Dec 2007 01:15:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David G Lawrence In-Reply-To: <20071218181023.GW25053@tnn.dglawrence.com> Message-ID: <20071219235444.K928@besplex.bde.org> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 14:15:55 -0000 On Tue, 18 Dec 2007, David G Lawrence wrote: >>> I got an almost identical delay (with 64000 vnodes). >>> >>> Now, 17ms isn't much. >> >> Says you. On modern systems, trying to run a pseudo real-time application >> on an otherwise quiescent system, 17ms is just short of an eternity. I agree >> that the syncer should be preemptable (which is what my bandaid patch >> attempts to do), but that probably wouldn't have helped my specific problem >> since my application was a user process, not a kernel thread. FreeBSD isn't a real-time system, and 17ms isn't much for it. I saw lots of syscall delays of nearly 1 second while debugging this. (With another hat, I would say that 17 us was a long time in 1992. 17 us is hundreds of times longer now.) > One more followup (I swear I'm done, really!)... I have a laptop here > that runs at 150MHz when it is in the lowest running CPU power save mode. > At that speed, this bug causes a delay of more than 300ms and is enough > to cause loss of keyboard input. I have to switch into high speed mode > before I try to type anything, else I end up with random typos. Very > annoying. Yes, something is wrong if keystrokes are lost with CPUs that run at 150 kHz (sic) or faster. Debugging shows that the problem is like I said. The loop really does take 125 ns per iteration. This time is actually not very much. The the linked list of vnodes could hardly be designed better to maximize cache thrashing. My system has a fairly small L2 cache (512K or 1M), and even a few words from the vnode and the inode don't fit in the L2 cache when there are 64000 vnodes, but the vp and ip are also fairly well desgined to maximize cache thrashing, so L2 cache thrashing starts at just a few thousand vnodes. My system has fairly low latency main memory, else the problem would be larger: % Memory latencies in nanoseconds - smaller is better % (WARNING - may not be correct, check graphs) % --------------------------------------------------- % Host OS Mhz L1 $ L2 $ Main mem Guesses % --------- ------------- ---- ----- ------ -------- ------- % besplex.b FreeBSD 7.0-C 2205 1.361 5.6090 42.4 [PC3200 CL2.5 overclocked] % sledge.fr FreeBSD 8.0-C 1802 1.666 8.9420 99.8 % freefall. FreeBSD 7.0-C 2778 0.746 6.6310 155.5 The loop makes the following memory accesses, at least in 5.2: % loop: % for (vp = TAILQ_FIRST(&mp->mnt_nvnodelist); vp != NULL; vp = nvp) { % /* % * If the vnode that we are about to sync is no longer % * associated with this mount point, start over. % */ % if (vp->v_mount != mp) % goto loop; % % /* % * Depend on the mntvnode_slock to keep things stable enough % * for a quick test. Since there might be hundreds of % * thousands of vnodes, we cannot afford even a subroutine % * call unless there's a good chance that we have work to do. % */ % nvp = TAILQ_NEXT(vp, v_nmntvnodes); Access 1 word at vp offset 0x90. Costs 1 cache line. IIRC, my system has a cache line size of 0x40. Assume this, and that vp is aligned on a cache line boundary. So this access costs the cache line at vp offsets 0x80-0xbf. % VI_LOCK(vp); Access 1 word at vp offset 0x1c. Costs the cache line at vp offsets 0-0x3f. % if (vp->v_iflag & VI_XLOCK) { Access 1 word at vp offset 0x24. Cache hit. % VI_UNLOCK(vp); % continue; % } % ip = VTOI(vp); Access 1 word at vp offset 0xa8. Cache hit. % if (vp->v_type == VNON || ((ip->i_flag & Access 1 word at vp offset 0xa0. Cache hit. Access 1 word at ip offset 0x18. Assume that ip is aligned, as above. Costs the cache line at ip offsets 0-0x3f. % (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && % TAILQ_EMPTY(&vp->v_dirtyblkhd))) { Access 1 word at vp offset 0x48. Costs the cache line at vp offsets 0x40- 0x7f. % VI_UNLOCK(vp); Reaccess 1 word at vp offset 0x1c. Cache hit. % continue; % } The total cost is 4 cache lines or 256 bytes per vnode. So with an L2 cache size of 1MB, the L2 cache will start thrashing at numvnodes = 4096. With thrashing, an at my main memory latency of 42.4 nsec, it might take 4*42.4 = 169.6 nsec to read main memory. This is similar to my observed time. Presumably things aren't quite that bad because there is some locality for the 3 lines in each vp. It might be possible to improve this a bit by accessing the lines sequentially and not interleaving the access to ip. Better, repack vp and move the IN* flags from ip to vp (a change that has other advantages), so that everything is in 1 cache line per vp. This isn't consistent with the delay increasing to 300 ms when the CPU is throttled -- memory shouldn't be throttled so much. On old machines, the memory was faster relative to the CPU, else noticeable 300[0] ms delays would have been common long ago. I think numvnodes grew large enough to bust L2 caches in the usual case even in 1992. This code clearly wasn't designed with caches in mind :-). The cost of subroutine calls would be in the noise compared with the cost of cache misses. Bruce From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 14:54:30 2007 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 BAFFA16A420; Wed, 19 Dec 2007 14:54:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 5679B13C468; Wed, 19 Dec 2007 14:54:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBJEsLqA004385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 01:54:22 +1100 Date: Thu, 20 Dec 2007 01:54:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mark Fullmer In-Reply-To: Message-ID: <20071220011626.U928@besplex.bde.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 14:54:30 -0000 On Tue, 18 Dec 2007, Mark Fullmer wrote: > A little progress. > > I have a machine with a KTR enabled kernel running. > > Another machine is running David's ffs_vfsops.c's patch. > > I left two other machines (GENERIC kernels) running the packet loss test > overnight. At ~ 32480 seconds of uptime the problem starts. This is really Try it with "find / -type f >/dev/null" to duplicate the problem almost instantly. > marks are the intervals between test runs. The window of missing packets > (timestamps between two packets where a sequence number is missing) > is usually less than 4us, altough I'm not sure gettimeofday() can be > trusted for measuring this. See https://www.eng.oar.net/~maf/bsd6/p3.png gettimeofday() can normally be trusted to better than 1 us for time differences of up to about 1 second. However, gettimeofday() should not be used in any program written after clock_gettime() became standard in 1994. clock_gettime() has a resolution of 1 ns. It isn't quite that accurate on current machines, but I trust it to measure differences of 10 nsec between back to back clock_gettime() calls here. Sample output from wollman@'s old clock-watching program converted to clock_gettime(): %%% 2007/12/05 (TSC) bde-current, -O2 -mcpu=athlon-xp min 238, max 99730, mean 240.025380, std 77.291436 1th: 239 (1203207 observations) 2th: 240 (556307 observations) 3th: 241 (190211 observations) 4th: 238 (50091 observations) 5th: 242 (20 observations) 2007/11/23 (TSC) bde-current min 247, max 11890, mean 247.857786, std 62.559317 1th: 247 (1274231 observations) 2th: 248 (668611 observations) 3th: 249 (56950 observations) 4th: 250 (23 observations) 5th: 263 (8 observations) 2007/05/19 (TSC) plain -current-noacpi min 262, max 286965, mean 263.941187, std 41.801400 1th: 264 (1343245 observations) 2th: 263 (626226 observations) 3th: 265 (26860 observations) 4th: 262 (3572 observations) 5th: 268 (8 observations) 2007/05/19 (TSC) plain -current-acpi min 261, max 68926, mean 279.848650, std 40.477440 1th: 261 (999391 observations) 2th: 320 (473325 observations) 3th: 262 (373831 observations) 4th: 321 (148126 observations) 5th: 312 (4759 observations) 2007/05/19 (ACPI-fast timecounter) plain -current-acpi min 558, max 285494, mean 827.597038, std 78.322301 1th: 838 (1685662 observations) 2th: 839 (136980 observations) 3th: 559 (72160 observations) 4th: 837 (48902 observations) 5th: 558 (31217 observations) 2007/05/19 (i8254) plain -current-acpi min 3352, max 288288, mean 4182.774148, std 257.977752 1th: 4190 (1423885 observations) 2th: 4191 (440158 observations) 3th: 3352 (65261 observations) 4th: 5028 (39202 observations) 5th: 5029 (15456 observations) %%% "min" here gives the minimum latency of a clock_gettime() syscall. The improvement from 247 nsec to 240 nsec in the "mean" due to -O2 -march-athlon-xp can be trusted to be measured very accurately since it is an average over more than 100 million trials, and the improvement from 247 nsec to 238 nsec for "min" can be trusted because it is consistent with the improvement in the mean. The program had to be converted to use clock_gettime() a few years ago when CPU speeds increased so much that the correct "min" became significantly less than 1. With gettimeofday(), it cannot distinguish between an overhead of 1 ns and an overhead of 1 us. For the ACPI and i8254 timecounter, you can see that the low-level timecounters have a low frequency clock from the large gaps between the observations. There is a gap of 279-280 ns for the acpi timecounter. This is the period of the acpi timecounter's clock (frequency 14318182/4 = period 279.3651 ns. Since we can observe this period to within 1 ns, we must have a basic accuracy of nearly 1 ns, but if we make only 2 observations we are likely to have an inaccuracy of 279 ns due to the granularity of the clock. The TSC has a clock granuarity of 6 ns on my CPU, and delivers almost that much accuracy with only 2 observations, but technical problems prevent general use of the TSC. Bruce From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 15:19:27 2007 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 DA03A16A41A; Wed, 19 Dec 2007 15:19:27 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id B5AF113C478; Wed, 19 Dec 2007 15:19:27 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBJFJR29078751; Wed, 19 Dec 2007 07:19:27 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBJFJREq078750; Wed, 19 Dec 2007 07:19:27 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Wed, 19 Dec 2007 07:19:27 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071219151926.GA25053@tnn.dglawrence.com> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219235444.K928@besplex.bde.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Wed, 19 Dec 2007 07:19:27 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 15:19:28 -0000 > On Tue, 18 Dec 2007, David G Lawrence wrote: > > >>>I got an almost identical delay (with 64000 vnodes). > >>> > >>>Now, 17ms isn't much. > >> > >> Says you. On modern systems, trying to run a pseudo real-time > >> application > >>on an otherwise quiescent system, 17ms is just short of an eternity. I > >>agree > >>that the syncer should be preemptable (which is what my bandaid patch > >>attempts to do), but that probably wouldn't have helped my specific > >>problem > >>since my application was a user process, not a kernel thread. > > FreeBSD isn't a real-time system, and 17ms isn't much for it. I saw lots I never said it was, but that doesn't stop us from using FreeBSD in pseudo real-time applications. This is made possible by fast CPUs and dedicated-task systems where the load is carefully controlled. > of syscall delays of nearly 1 second while debugging this. (With another I can make the delay several minutes by pushing the reset button. > Debugging shows that the problem is like I said. The loop really does > take 125 ns per iteration. This time is actually not very much. The Considering that the CPU clock cycle time is on the order of 300ps, I would say 125ns to do a few checks is pathetic. In any case, it appears that my patch is a no-op, at least for the problem I was trying to solve. This has me confused, however, because at one point the problem was mitigated with it. The patch has gone through several iterations, however, and it could be that it was made to the top of the loop, before any of the checks, in a previous version. Hmmm. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 15:48:58 2007 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 382E316A419; Wed, 19 Dec 2007 15:48:58 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 18B8213C46E; Wed, 19 Dec 2007 15:48:57 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBJFmuac097907; Wed, 19 Dec 2007 07:48:56 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBJFmuvg097900; Wed, 19 Dec 2007 07:48:56 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Wed, 19 Dec 2007 07:48:56 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071219154856.GC25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220011626.U928@besplex.bde.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Wed, 19 Dec 2007 07:48:56 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 15:48:58 -0000 > Try it with "find / -type f >/dev/null" to duplicate the problem almost > instantly. FreeBSD used to have some code that would cause vnodes with no cached pages to be recycled quickly (which would have made a simple find ineffective without reading the files at least a little bit). I guess that got removed when the size of the vnode pool was dramatically increased. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 16:02:24 2007 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 9C8B116A418; Wed, 19 Dec 2007 16:02:24 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 79ED213C478; Wed, 19 Dec 2007 16:02:24 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBJG2Ont007111; Wed, 19 Dec 2007 08:02:24 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBJG2OrV007110; Wed, 19 Dec 2007 08:02:24 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Wed, 19 Dec 2007 08:02:24 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071219160224.GD25053@tnn.dglawrence.com> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219151926.GA25053@tnn.dglawrence.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Wed, 19 Dec 2007 08:02:24 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 16:02:24 -0000 > In any case, it appears that my patch is a no-op, at least for the > problem I was trying to solve. This has me confused, however, because at > one point the problem was mitigated with it. The patch has gone through > several iterations, however, and it could be that it was made to the top > of the loop, before any of the checks, in a previous version. Hmmm. (replying to myself) I just found an earlier version of the patch, and sure enough, it was to the top of the loop. Unfortunately, that version caused the system to crash because vp was occasionally invalid after the wakeup. Anyway, let's see if Mark's packet loss problem is indeed related to this code. If he does the find just after boot and immediately sees the problem, then I would say that is fairly conclusive. He could also release the cached vnodes by temporarily setting kern.maxvnodes=10000 and then setting it back to whatever it was previously (probably 60000-100000). If the problem then goes away for awhile, that would be another good indicator. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 16:31:10 2007 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 073F516A419 for ; Wed, 19 Dec 2007 16:31:10 +0000 (UTC) (envelope-from ups@freebsd.org) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by mx1.freebsd.org (Postfix) with SMTP id C8A4013C45A for ; Wed, 19 Dec 2007 16:31:09 +0000 (UTC) (envelope-from ups@freebsd.org) Received: (qmail 32630 invoked from network); 19 Dec 2007 16:04:29 -0000 Received: from unknown (66.23.216.53) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 19 Dec 2007 16:04:28 -0000 Message-ID: <4769410E.3050005@freebsd.org> Date: Wed, 19 Dec 2007 11:04:30 -0500 From: Stephan Uphoff User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David G Lawrence References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <20071219154856.GC25053@tnn.dglawrence.com> In-Reply-To: <20071219154856.GC25053@tnn.dglawrence.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 16:31:10 -0000 David G Lawrence wrote: >> Try it with "find / -type f >/dev/null" to duplicate the problem almost >> instantly. >> > > FreeBSD used to have some code that would cause vnodes with no cached > pages to be recycled quickly (which would have made a simple find > ineffective without reading the files at least a little bit). I guess > that got removed when the size of the vnode pool was dramatically > increased. > You can decrease vfs.wantfreevnodes if caching files without cached data is not beneficial for your application. > -DG > > David G. Lawrence > President > Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 > The FreeBSD Project - http://www.freebsd.org > Pave the road of life with opportunities. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 16:49:52 2007 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 D589B16A419; Wed, 19 Dec 2007 16:49:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 77EE913C465; Wed, 19 Dec 2007 16:49:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBJGnk3A028545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 03:49:47 +1100 Date: Thu, 20 Dec 2007 03:49:45 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David G Lawrence In-Reply-To: <20071219151926.GA25053@tnn.dglawrence.com> Message-ID: <20071220032223.V38101@delplex.bde.org> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 16:49:52 -0000 On Wed, 19 Dec 2007, David G Lawrence wrote: >> Debugging shows that the problem is like I said. The loop really does >> take 125 ns per iteration. This time is actually not very much. The > > Considering that the CPU clock cycle time is on the order of 300ps, I > would say 125ns to do a few checks is pathetic. As I said, 125 nsec is a short time in this context. It is approximately the time for a single L2 cache miss on a machine with slow memory like freefall (Xeon 2.8 GHz with L2 cache latency of 155.5 ns). As I said, the code is organized so as to give about 4 L2 cache misses per vnode if there are more than a few thousand vnodes, so it is doing very well to take only 125 nsec for a few checks. > In any case, it appears that my patch is a no-op, at least for the > problem I was trying to solve. This has me confused, however, because at > one point the problem was mitigated with it. The patch has gone through > several iterations, however, and it could be that it was made to the top > of the loop, before any of the checks, in a previous version. Hmmm. The patch should work fine. IIRC, it yields voluntarily so that other things can run. I committed a similar hack for uiomove(). It was easy to make syscalls that take many seconds (now tenths of seconds insted of seconds?), and without yielding or PREEMPTION or multiple CPUs, everything except interrupts has to wait for these syscalls. Now the main problem is to figure out why PREEMPTION doesn't work. I'm not working on this directly since I'm running ~5.2 where nearly-full kernel preemption doesn't work due to Giant locking. Bruce From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 17:00:04 2007 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 DA9CA16A47A; Wed, 19 Dec 2007 17:00:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 657E113C4EF; Wed, 19 Dec 2007 17:00:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBJGxts6007170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 03:59:57 +1100 Date: Thu, 20 Dec 2007 03:59:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David G Lawrence In-Reply-To: <20071219154856.GC25053@tnn.dglawrence.com> Message-ID: <20071220035129.R38221@delplex.bde.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <20071219154856.GC25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 17:00:05 -0000 On Wed, 19 Dec 2007, David G Lawrence wrote: >> Try it with "find / -type f >/dev/null" to duplicate the problem almost >> instantly. > > FreeBSD used to have some code that would cause vnodes with no cached > pages to be recycled quickly (which would have made a simple find > ineffective without reading the files at least a little bit). I guess > that got removed when the size of the vnode pool was dramatically > increased. It might still. The data should be cached somewhere, but caching it in both the buffer cache/VMIO and the vnode/inode is wasteful. I may have been only caching vnodes for directories. I switched to using a find or a tar on /home/ncvs/ports since that has a very high density of directories. Bruce From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 17:04:34 2007 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 D62B716A417; Wed, 19 Dec 2007 17:04:34 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id B4B1213C447; Wed, 19 Dec 2007 17:04:34 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBJH4Yt0046644; Wed, 19 Dec 2007 09:04:34 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBJH4YCu046643; Wed, 19 Dec 2007 09:04:34 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Wed, 19 Dec 2007 09:04:34 -0800 From: David G Lawrence To: Bruce Evans Message-ID: <20071219170434.GG25053@tnn.dglawrence.com> References: <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> <20071220032223.V38101@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220032223.V38101@delplex.bde.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Wed, 19 Dec 2007 09:04:34 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 17:04:34 -0000 > > In any case, it appears that my patch is a no-op, at least for the > >problem I was trying to solve. This has me confused, however, because at > >one point the problem was mitigated with it. The patch has gone through > >several iterations, however, and it could be that it was made to the top > >of the loop, before any of the checks, in a previous version. Hmmm. > > The patch should work fine. IIRC, it yields voluntarily so that other > things can run. I committed a similar hack for uiomove(). It was It patches the bottom of the loop, which is only reached if the vnode is dirty. So it will only help if there are thousands of dirty vnodes. While that condition can certainly happen, it isn't the case that I'm particularly interested in. > CPUs, everything except interrupts has to wait for these syscalls. Now > the main problem is to figure out why PREEMPTION doesn't work. I'm > not working on this directly since I'm running ~5.2 where nearly-full > kernel preemption doesn't work due to Giant locking. I don't understand how PREEMPTION is supposed to work (I mean to any significant detail), so I can't really comment on that. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 17:07:23 2007 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 7E71616A4E9 for ; Wed, 19 Dec 2007 17:07:23 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 1E81F13C45D for ; Wed, 19 Dec 2007 17:07:17 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 43387 invoked from network); 19 Dec 2007 17:07:17 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 19 Dec 2007 17:07:17 -0000 In-Reply-To: <20071220011626.U928@besplex.bde.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Wed, 19 Dec 2007 12:06:59 -0500 To: Bruce Evans X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 17:07:23 -0000 On Dec 19, 2007, at 9:54 AM, Bruce Evans wrote: > On Tue, 18 Dec 2007, Mark Fullmer wrote: > >> A little progress. >> >> I have a machine with a KTR enabled kernel running. >> >> Another machine is running David's ffs_vfsops.c's patch. >> >> I left two other machines (GENERIC kernels) running the packet >> loss test >> overnight. At ~ 32480 seconds of uptime the problem starts. This >> is really > > Try it with "find / -type f >/dev/null" to duplicate the problem > almost > instantly. I was able to verify last night that (cd /; tar -cpf -) > all.tar would trigger the problem. I'm working getting a test running with David's ffs_sync() workaround now, adding a few counters there should get this narrowed down a little more. Thanks for the other info on timer resolution, I overlooked clock_gettime(). -- mark From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 17:13:32 2007 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 C0FE716A419; Wed, 19 Dec 2007 17:13:32 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id A121B13C458; Wed, 19 Dec 2007 17:13:32 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBJHDVgN052479; Wed, 19 Dec 2007 09:13:31 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBJHDVFL052478; Wed, 19 Dec 2007 09:13:31 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Wed, 19 Dec 2007 09:13:31 -0800 From: David G Lawrence To: Mark Fullmer Message-ID: <20071219171331.GH25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Wed, 19 Dec 2007 09:13:31 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 17:13:32 -0000 > >Try it with "find / -type f >/dev/null" to duplicate the problem > >almost > >instantly. > > I was able to verify last night that (cd /; tar -cpf -) > all.tar would > trigger the problem. I'm working getting a test running with > David's ffs_sync() workaround now, adding a few counters there should > get this narrowed down a little more. Unfortunately, the version of the patch that I sent out isn't going to help your problem. It needs to yield at the top of the loop, but vp isn't necessarily valid after the wakeup from the msleep. That's a problem that I'm having trouble figuring out a solution to - the solutions that come to mind will all significantly increase the overhead of the loop. As a very inadequate work-around, you might consider lowering kern.maxvnodes to something like 20000 - that might be low enough to not trigger the problem, but also be high enough to not significantly affect system I/O performance. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 18:09:34 2007 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 C720B16A420; Wed, 19 Dec 2007 18:09:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 6986413C448; Wed, 19 Dec 2007 18:09:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBJI9Ni5005222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 05:09:25 +1100 Date: Thu, 20 Dec 2007 05:09:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20071220032223.V38101@delplex.bde.org> Message-ID: <20071220044515.K4939@besplex.bde.org> References: <20071217103936.GR25053@tnn.dglawrence.com> <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> <20071220032223.V38101@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 18:09:34 -0000 On Thu, 20 Dec 2007, Bruce Evans wrote: > On Wed, 19 Dec 2007, David G Lawrence wrote: >> Considering that the CPU clock cycle time is on the order of 300ps, I >> would say 125ns to do a few checks is pathetic. > > As I said, 125 nsec is a short time in this context. It is approximately > the time for a single L2 cache miss on a machine with slow memory like > freefall (Xeon 2.8 GHz with L2 cache latency of 155.5 ns). As I said, Perfmon counts for the cache misses during sync(1); ==> /tmp/kg1/z0 <== vfs.numvnodes: 630 # s/kx-dc-accesses 484516 # s/kx-dc-misses 20852 misses = 4% ==> /tmp/kg1/z1 <== vfs.numvnodes: 9246 # s/kx-dc-accesses 884361 # s/kx-dc-misses 89833 misses = 10% ==> /tmp/kg1/z2 <== vfs.numvnodes: 20312 # s/kx-dc-accesses 1389959 # s/kx-dc-misses 178207 misses = 13% ==> /tmp/kg1/z3 <== vfs.numvnodes: 80802 # s/kx-dc-accesses 4122411 # s/kx-dc-misses 658740 misses = 16% ==> /tmp/kg1/z4 <== vfs.numvnodes: 138557 # s/kx-dc-accesses 7150726 # s/kx-dc-misses 1129997 misses = 16% === I forgot to only count active vnodes in the above. vfs.freevnodes was small (< 5%). I set kern.maxvnodes to 200000, but vfs.numvnodes saturated at 138557 (probably all that fits in kvm or main memory on i386 with 1GB RAM). With 138557 vnodes, a null sync(2) takes 39673 us according to kdump -R. That is 35.1 ns per miss. This is consistent with lmbench2's estimate of 42.5 ns for main memory latency. Watching vfs.*vnodes confirmed that vnode caching still works like you said: o "find /home/ncvs/ports -type f" only gives a vnode for each directory o a repeated "find /home/ncvs/ports -type f" is fast because everything remains cached by VMIO. FreeBSD performed very badly at this benchmark before VMIO existed and was used for directories o "tar cf /dev/zero /home/ncvs/ports" gives a vnode for files too. Bruce From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 18:12:12 2007 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 6FF6816A46E; Wed, 19 Dec 2007 18:12:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 0E94713C458; Wed, 19 Dec 2007 18:12:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J53Ol-000621-AH; Wed, 19 Dec 2007 20:12:10 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBJIBxCx002569; Wed, 19 Dec 2007 20:11:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBJIBxik002568; Wed, 19 Dec 2007 20:11:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Dec 2007 20:11:59 +0200 From: Kostik Belousov To: David G Lawrence Message-ID: <20071219181158.GC57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QRj9sO5tAVLaXnSD" Content-Disposition: inline In-Reply-To: <20071219171331.GH25053@tnn.dglawrence.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: eb35aeac2b84d7677a861f668fbe3b20 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1929 [Dec 19 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 18:12:12 -0000 --QRj9sO5tAVLaXnSD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2007 at 09:13:31AM -0800, David G Lawrence wrote: > > >Try it with "find / -type f >/dev/null" to duplicate the problem =20 > > >almost > > >instantly. > >=20 > > I was able to verify last night that (cd /; tar -cpf -) > all.tar would > > trigger the problem. I'm working getting a test running with > > David's ffs_sync() workaround now, adding a few counters there should > > get this narrowed down a little more. >=20 > Unfortunately, the version of the patch that I sent out isn't going to > help your problem. It needs to yield at the top of the loop, but vp isn't > necessarily valid after the wakeup from the msleep. That's a problem that > I'm having trouble figuring out a solution to - the solutions that come > to mind will all significantly increase the overhead of the loop. > As a very inadequate work-around, you might consider lowering > kern.maxvnodes to something like 20000 - that might be low enough to > not trigger the problem, but also be high enough to not significantly > affect system I/O performance. I think the following may be safe. It counts only the clean scanned vnodes and does not evaluate the vp, that indeed may be reclaimed, after the sleep. I never booted with the change. diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c index cbccc62..e686b97 100644 --- a/sys/ufs/ffs/ffs_vfsops.c +++ b/sys/ufs/ffs/ffs_vfsops.c @@ -1176,6 +1176,7 @@ ffs_sync(mp, waitfor, td) struct ufsmount *ump =3D VFSTOUFS(mp); struct fs *fs; int error, count, wait, lockreq, allerror =3D 0; + int yield_count; int suspend; int suspended; int secondary_writes; @@ -1216,6 +1217,7 @@ loop: softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps); MNT_ILOCK(mp); =20 + yield_count =3D 0; MNT_VNODE_FOREACH(vp, mp, mvp) { /* * Depend on the mntvnode_slock to keep things stable enough @@ -1233,6 +1235,11 @@ loop: (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) =3D=3D 0 && vp->v_bufobj.bo_dirty.bv_cnt =3D=3D 0)) { VI_UNLOCK(vp); + if (yield_count++ =3D=3D 500) { + yield_count =3D 0; + msleep(&yield_count, MNT_MTX(mp), PZERO, + "ffspause", 1); + } continue; } MNT_IUNLOCK(mp); --QRj9sO5tAVLaXnSD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHaV7uC3+MBN1Mb4gRAqLNAJ471VG5oznpot2N3bfli+CxXeDDlQCfb3r5 c/Pmx/oykpmlmw9bqog0ci4= =Z4qH -----END PGP SIGNATURE----- --QRj9sO5tAVLaXnSD-- From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 18:24:54 2007 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 4F62D16A417; Wed, 19 Dec 2007 18:24:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id E2AC713C45D; Wed, 19 Dec 2007 18:24:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J53bA-0008x5-5b; Wed, 19 Dec 2007 20:24:52 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBJIOn83006616; Wed, 19 Dec 2007 20:24:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBJIOmJ3006615; Wed, 19 Dec 2007 20:24:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Dec 2007 20:24:48 +0200 From: Kostik Belousov To: David G Lawrence Message-ID: <20071219182448.GD57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071219181158.GC57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wULyF7TL5taEdwHz" Content-Disposition: inline In-Reply-To: <20071219181158.GC57756@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: c743d2f542030c7d5376417eb66b5b31 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1929 [Dec 19 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 18:24:54 -0000 --wULyF7TL5taEdwHz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2007 at 08:11:59PM +0200, Kostik Belousov wrote: > On Wed, Dec 19, 2007 at 09:13:31AM -0800, David G Lawrence wrote: > > > >Try it with "find / -type f >/dev/null" to duplicate the problem =20 > > > >almost > > > >instantly. > > >=20 > > > I was able to verify last night that (cd /; tar -cpf -) > all.tar wou= ld > > > trigger the problem. I'm working getting a test running with > > > David's ffs_sync() workaround now, adding a few counters there should > > > get this narrowed down a little more. > >=20 > > Unfortunately, the version of the patch that I sent out isn't going = to > > help your problem. It needs to yield at the top of the loop, but vp isn= 't > > necessarily valid after the wakeup from the msleep. That's a problem th= at > > I'm having trouble figuring out a solution to - the solutions that come > > to mind will all significantly increase the overhead of the loop. > > As a very inadequate work-around, you might consider lowering > > kern.maxvnodes to something like 20000 - that might be low enough to > > not trigger the problem, but also be high enough to not significantly > > affect system I/O performance. >=20 > I think the following may be safe. It counts only the clean scanned vnodes > and does not evaluate the vp, that indeed may be reclaimed, after the sle= ep. >=20 > I never booted with the change. >=20 > diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c > index cbccc62..e686b97 100644 Or, better to use uio_yield(). See below. diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c index cbccc62..5d2535f 100644 --- a/sys/ufs/ffs/ffs_vfsops.c +++ b/sys/ufs/ffs/ffs_vfsops.c @@ -1176,6 +1176,7 @@ ffs_sync(mp, waitfor, td) struct ufsmount *ump =3D VFSTOUFS(mp); struct fs *fs; int error, count, wait, lockreq, allerror =3D 0; + int yield_count; int suspend; int suspended; int secondary_writes; @@ -1216,6 +1217,7 @@ loop: softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps); MNT_ILOCK(mp); =20 + yield_count =3D 0; MNT_VNODE_FOREACH(vp, mp, mvp) { /* * Depend on the mntvnode_slock to keep things stable enough @@ -1233,6 +1235,12 @@ loop: (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) =3D=3D 0 && vp->v_bufobj.bo_dirty.bv_cnt =3D=3D 0)) { VI_UNLOCK(vp); + if (yield_count++ =3D=3D 500) { + MNT_IUNLOCK(mp); + yield_count =3D 0; + uio_yield(); + goto relock_mp; + } continue; } MNT_IUNLOCK(mp); @@ -1247,6 +1255,7 @@ loop: if ((error =3D ffs_syncvnode(vp, waitfor)) !=3D 0) allerror =3D error; vput(vp); + relock_mp: MNT_ILOCK(mp); } MNT_IUNLOCK(mp); --wULyF7TL5taEdwHz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHaWHwC3+MBN1Mb4gRArC6AJ4rYZhWlamxL8uvszTZp2sVfNACkQCgqugO 4roWpidQRMN1XzFyhqB/2f0= =e7xk -----END PGP SIGNATURE----- --wULyF7TL5taEdwHz-- From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 18:33:52 2007 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 5390716A41B for ; Wed, 19 Dec 2007 18:33:52 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 1D51C13C474 for ; Wed, 19 Dec 2007 18:33:51 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 60029 invoked from network); 19 Dec 2007 18:33:51 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 19 Dec 2007 18:33:51 -0000 In-Reply-To: <20071219171331.GH25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50B64D0B-35E6-453F-A8AF-65982A503E20@eng.oar.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Wed, 19 Dec 2007 13:33:34 -0500 To: David G Lawrence X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 18:33:52 -0000 Just to confirm the patch did not change the behavior. I ran with it last night and double checked this morning to make sure. It looks like if you put the check at the top of the loop and the next node is changed during msleep() SLIST_NEXT will walk into the trash. I'm in over my head here.... Setting kern.maxvnodes=1000 does stop both the periodic packet loss and the high latency syscall's, so it does look like walking this chain without yielding the processor is part of the problem I'm seeing. The other behavior I don't understand is why the em driver is able to increment if_ipackets but still lose the packet. Dumping the internal stats with dev.em.1.stats=1: Dec 19 13:07:46 dytnq-nf1 kernel: em1: Excessive collisions = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Sequence errors = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Defer count = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Missed Packets = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Receive No Buffers = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Receive Length Errors = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Receive errors = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Crc errors = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Alignment errors = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Collision/Carrier extension errors = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: RX overruns = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: watchdog timeouts = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: XON Rcvd = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: XON Xmtd = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: XOFF Rcvd = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: XOFF Xmtd = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Good Packets Rcvd = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: Good Packets Xmtd = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: TSO Contexts Xmtd = 0 Dec 19 13:07:46 dytnq-nf1 kernel: em1: TSO Contexts Failed = 0 With FreeBSD 4 I was able to run a UDP data collector with rtprio set, kern.ipc.maxsockbuf=20480000, then use setsockopt() with SO_RCVBUF in the application. If packets were dropped they would show up with netstat -s as "dropped due to full socket buffers". Since the packet never makes it to ip_input() I no longer have any way to count drops. There will always be corner cases where interrupts are lost and drops not accounted for if the adapter hardware can't report them, but right now I've got no way to estimate any loss. -- mark On Dec 19, 2007, at 12:13 PM, David G Lawrence wrote: >>> Try it with "find / -type f >/dev/null" to duplicate the problem >>> almost >>> instantly. >> >> I was able to verify last night that (cd /; tar -cpf -) > all.tar >> would >> trigger the problem. I'm working getting a test running with >> David's ffs_sync() workaround now, adding a few counters there should >> get this narrowed down a little more. > > Unfortunately, the version of the patch that I sent out isn't > going to > help your problem. It needs to yield at the top of the loop, but vp > isn't > necessarily valid after the wakeup from the msleep. That's a > problem that > I'm having trouble figuring out a solution to - the solutions that > come > to mind will all significantly increase the overhead of the loop. > As a very inadequate work-around, you might consider lowering > kern.maxvnodes to something like 20000 - that might be low enough to > not trigger the problem, but also be high enough to not significantly > affect system I/O performance. > > -DG > > David G. Lawrence > President > Download Technologies, Inc. - http://www.downloadtech.com - (866) > 399 8500 > The FreeBSD Project - http://www.freebsd.org > Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 19:41:12 2007 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 736E616A417; Wed, 19 Dec 2007 19:41:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 167C713C4DD; Wed, 19 Dec 2007 19:41:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBJJf3qs021871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 06:41:08 +1100 Date: Thu, 20 Dec 2007 06:41:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David G Lawrence In-Reply-To: <20071219170434.GG25053@tnn.dglawrence.com> Message-ID: <20071220051751.E38491@delplex.bde.org> References: <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> <20071220032223.V38101@delplex.bde.org> <20071219170434.GG25053@tnn.dglawrence.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 19:41:12 -0000 On Wed, 19 Dec 2007, David G Lawrence wrote: >> The patch should work fine. IIRC, it yields voluntarily so that other >> things can run. I committed a similar hack for uiomove(). It was > > It patches the bottom of the loop, which is only reached if the vnode > is dirty. So it will only help if there are thousands of dirty vnodes. > While that condition can certainly happen, it isn't the case that I'm > particularly interested in. Oops. When it reaches the bottom of the loop, it will probably block on i/o sometimes, so that the problem is smaller anyway. >> CPUs, everything except interrupts has to wait for these syscalls. Now >> the main problem is to figure out why PREEMPTION doesn't work. I'm >> not working on this directly since I'm running ~5.2 where nearly-full >> kernel preemption doesn't work due to Giant locking. > > I don't understand how PREEMPTION is supposed to work (I mean > to any significant detail), so I can't really comment on that. Me neither, but I will comment anyway :-). I think PREEMPTION should even preempt kernel threads in favor of (higher priority of course) user threads that are in the kernel, but doesn't do this now. Even interrupt threads should have dynamic priorities so that when they become too hoggish they can be preempted even by user threads subject to the this priority rule. This is further from happening. ffs_sync() can hold the mountpoint lock for a long time. That gives problems preempting it. To move your fix to the top of the loop, I think you just need to drop the mountpoint lock every few hundred iterations while yielding. This would help for PREEMPTION too. Dropping the lock must be safe because it is already done while flushing. Hmm, the loop is nicely obfuscated and pessimized in current (see rev.1.234). The fast (modulo no cache misses) path used to be just a TAILQ_NEXT() to reach the next vnode, but now unnecessarily joins the slow path at MNT_VNODE_FOREACH(), and MNT_VNODE_FOREACH() hides a function call. Bruce From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 19:44:02 2007 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 616AC16A417 for ; Wed, 19 Dec 2007 19:44:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outD.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4940D13C44B for ; Wed, 19 Dec 2007 19:44:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 19 Dec 2007 11:44:00 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 26311126CF7; Wed, 19 Dec 2007 11:44:00 -0800 (PST) Message-ID: <47697480.9070208@elischer.org> Date: Wed, 19 Dec 2007 11:44:00 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David G Lawrence References: <20071218170133.X32807@delplex.bde.org> <47676E96.4030708@samsco.org> <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> <20071220032223.V38101@delplex.bde.org> <20071219170434.GG25053@tnn.dglawrence.com> In-Reply-To: <20071219170434.GG25053@tnn.dglawrence.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 19:44:02 -0000 David G Lawrence wrote: >>> In any case, it appears that my patch is a no-op, at least for the >>> problem I was trying to solve. This has me confused, however, because at >>> one point the problem was mitigated with it. The patch has gone through >>> several iterations, however, and it could be that it was made to the top >>> of the loop, before any of the checks, in a previous version. Hmmm. >> The patch should work fine. IIRC, it yields voluntarily so that other >> things can run. I committed a similar hack for uiomove(). It was > > It patches the bottom of the loop, which is only reached if the vnode > is dirty. So it will only help if there are thousands of dirty vnodes. > While that condition can certainly happen, it isn't the case that I'm > particularly interested in. > >> CPUs, everything except interrupts has to wait for these syscalls. Now >> the main problem is to figure out why PREEMPTION doesn't work. I'm >> not working on this directly since I'm running ~5.2 where nearly-full >> kernel preemption doesn't work due to Giant locking. > > I don't understand how PREEMPTION is supposed to work (I mean > to any significant detail), so I can't really comment on that. It's really very simple. When you do a "wakeup" (or anything else that puts a thread on a run queue) i.e. use setrunqueue() then if that thread has more priority than you do, (and in the general case is an interrupt thread), you immedialty call mi_switch so that it runs imediatly. You get guaranteed to run again when it finishes. (you are not just put back on the run queue at the end). the critical_enter()/critical_exit() calls disable this from happening to you if you really must not be interrupted by another thread. there is an option where it is not jsut interrupt threads that can jump in, but I think it's usually disabled. > > -DG > > David G. Lawrence > President > Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 > The FreeBSD Project - http://www.freebsd.org > Pave the road of life with opportunities. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 20:35:56 2007 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 85D5616A419; Wed, 19 Dec 2007 20:35:56 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E7DCF13C442; Wed, 19 Dec 2007 20:35:55 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A724C.dip.t-dialin.net [84.154.114.76]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lBJKZqM6001207; Wed, 19 Dec 2007 20:35:53 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id lBJKabjq066572; Wed, 19 Dec 2007 21:36:37 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lBJKaWYp008250; Wed, 19 Dec 2007 21:36:37 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200712192036.lBJKaWYp008250@fire.js.berklix.net> To: stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich/Muenchen. User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com/~jhs/cv/ Date: Wed, 19 Dec 2007 21:36:32 +0100 Sender: jhs@berklix.org Cc: re@freebsd.org Subject: 7.0BETA4 ../cc_tools/insn-attrtab.c compiles forever 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, 19 Dec 2007 20:35:56 -0000 Anyone else noticed on 7.0BETA4 (& hence Ive cc'd re@) This runs forever: ===> cc_int (all) Warning: Object directory not changed from original /usr/src/gnu/usr.bin/cc/cc_int cc -O2 -fno-strict-aliasing -march=i586 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -c ../cc_tools/insn-attrtab.c With or without -pipe & with or without /usr/obj All the rest of /usr/src compiles OK though. FreeBSD lapn.js.berklix.net 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Sun Dec 16 09:18:21 CET 2007 jhs@lapn.js.berklix.net:/usr/src/sys/i386/compile/GENERIC i386 Julian -- Julian Stacey. Munich Consultant: BSD Unix Linux. http://berklix.com Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 19 20:47:22 2007 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 2E35616A41B; Wed, 19 Dec 2007 20:47:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id C241613C458; Wed, 19 Dec 2007 20:47:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J55oz-000MMU-8c; Wed, 19 Dec 2007 22:47:20 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBJKlDd2009333; Wed, 19 Dec 2007 22:47:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBJKlCAJ009332; Wed, 19 Dec 2007 22:47:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Dec 2007 22:47:12 +0200 From: Kostik Belousov To: Julian Elischer Message-ID: <20071219204712.GE57756@deviant.kiev.zoral.com.ua> References: <20071218233644.U756@besplex.bde.org> <20071218141742.GS25053@tnn.dglawrence.com> <20071219022102.I34422@delplex.bde.org> <20071218165732.GV25053@tnn.dglawrence.com> <20071218181023.GW25053@tnn.dglawrence.com> <20071219235444.K928@besplex.bde.org> <20071219151926.GA25053@tnn.dglawrence.com> <20071220032223.V38101@delplex.bde.org> <20071219170434.GG25053@tnn.dglawrence.com> <47697480.9070208@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ffoCPvUAPMgSXi6H" Content-Disposition: inline In-Reply-To: <47697480.9070208@elischer.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 3f6c5f504711b4b2e39067d20b60c9d6 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1930 [Dec 19 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 19 Dec 2007 20:47:22 -0000 --ffoCPvUAPMgSXi6H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2007 at 11:44:00AM -0800, Julian Elischer wrote: > David G Lawrence wrote: > >>> In any case, it appears that my patch is a no-op, at least for the > >>>problem I was trying to solve. This has me confused, however, because = at > >>>one point the problem was mitigated with it. The patch has gone through > >>>several iterations, however, and it could be that it was made to the t= op > >>>of the loop, before any of the checks, in a previous version. Hmmm. > >>The patch should work fine. IIRC, it yields voluntarily so that other > >>things can run. I committed a similar hack for uiomove(). It was > > > > It patches the bottom of the loop, which is only reached if the vnode > >is dirty. So it will only help if there are thousands of dirty vnodes. > >While that condition can certainly happen, it isn't the case that I'm > >particularly interested in. > > > >>CPUs, everything except interrupts has to wait for these syscalls. Now > >>the main problem is to figure out why PREEMPTION doesn't work. I'm > >>not working on this directly since I'm running ~5.2 where nearly-full > >>kernel preemption doesn't work due to Giant locking. > > > > I don't understand how PREEMPTION is supposed to work (I mean > >to any significant detail), so I can't really comment on that. >=20 > It's really very simple. >=20 > When you do a "wakeup"=20 > (or anything else that puts a thread on a run queue) > i.e. use setrunqueue() > then if that thread has more priority than you do, (and in the general ca= se > is an interrupt thread), you immedialty call mi_switch so that it runs=20 > imediatly. > You get guaranteed to run again when it finishes.=20 > (you are not just put back on the run queue at the end). As far as I see it, only the interrupt threads can put the kernel thread off the CPU. More, the thread being forced out shall be an "idle user thread". See kern_switch.c, maybe_preempt(), the #ifndef FULL_PREEMPTION block. >=20 > the critical_enter()/critical_exit() calls disable this from happening to= =20 > you if you really must not be interrupted by another thread. >=20 > there is an option where it is not jsut interrupt threads that can jump i= n, > but I think it's usually disabled. Do you mean FULL_PREEMPTION ? --ffoCPvUAPMgSXi6H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHaYNPC3+MBN1Mb4gRAs3VAKCAuYRei7c6tM7PCglA0MhS1wv9YgCg2qQD rtEKhVPITTealtAh8v2AClM= =as0Z -----END PGP SIGNATURE----- --ffoCPvUAPMgSXi6H-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 07:09:32 2007 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 7062216A419 for ; Thu, 20 Dec 2007 07:09:32 +0000 (UTC) (envelope-from horaire@cfew.net.dm-4.com) Received: from mta224a.dm-4.com (mta224a.dm-4.com [64.40.113.224]) by mx1.freebsd.org (Postfix) with ESMTP id 59C0913C468 for ; Thu, 20 Dec 2007 07:09:32 +0000 (UTC) (envelope-from horaire@cfew.net.dm-4.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=x; d=dm-4.com; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type; i=horaire@cfew.net.dm-4.com; bh=/NNy/TcmVv4V9Wc4C0ODOE7rl6I=; b=glR4CKdYs2XT0isu1Bb9ApyOLCgeSdi92HsyqyhbLStbAsK0d5AWEotfhOCqny8r+wvlsT4kcR77 Qq6n5SJ0ijkvff54iZe3nDphG6iN73q44UihqVB+mPv3hdLjn/s9M5JisRNoIiFviyg0AL8U4UmY DghLzfPtX/U5kH95sXo= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=x; d=dm-4.com; b=HTuhsZEqteKF6P7D+8poPFzs36bELeusnQvoBpaJMLezmPk6neHOAjebnHgQrMvtz3YSaUxwiLct I1fqOh1geZVwj9NQ+RmahSG8xgIZQN9UozYgBQi0RxF5I5HbM8sBGC53eKkOo/293S/MZxaxpLJ5 HD1EiOh9FGtwxcRxHdw=; Received: by mta224a.dm-4.com (PowerMTA(TM) v3.2r17) id hd8al00dao8s for ; Wed, 19 Dec 2007 23:00:04 -0800 (envelope-from ) Message-ID: Date: Thu, 20 Dec 2007 07:00:04 GMT From: "La Direction" To: "freebsd-stable@FreeBSD.org" X-Mailer: MBMQZE VODSUKY RZYTFH0 4M45VA Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Cc: Subject: Encadrer et motiver une equipe X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: horaire@cfew.net.dm-4.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 07:09:32 -0000 Titre du Cours Encadrer et motiver une équipe Comme manager et chef d'équipe, votre rôle consiste à assurer la contribution des membres de votre équipe, à la réalisation des objectifs et de la mission de l'organisation. Vous vous questionnez sur votre style de gestion, votre leadership et sur la façon d'obtenir l'engagement de vos collaborateurs. Cette formation fournira, sous forme d'ateliers pratiques, les ressources et des méthodes efficaces pour amener vos équipes à un niveau d'autonomie essentiel à la réussite des objectifs de l'organisation. Pour plus de renseignements, contactez nous au 450-226-2238 ou 1-800-861-6618 OBJECTIFS : Fournir les techniques et outils nécessaires au manager pour l'encadrement et la motivation de leur équipe. CONTENU : - Le rôle et la mission du manager - Animation des réunions de travail - La cohésion des membres de son équipe à la réalisation des objectifs et de la mission de l'organisation - Assurer au quotidien la réalisation des résultats de son équipe - Multiplier les résultats que l'on obtiendrait en exécutant soi-même certaines tâches - Comprendre les comportements individuels - Résolution de conflits - Participer à l'épanouissement professionnel de ses collaborateurs dans une volonté d'amélioration continue des performances et des compétences L'encadrement : - Définir les objectifs quantitatifs et qualitatifs - Les objectifs de groupe et individuels - La responsabilisation des membres de son équipe - Déterminer les standards de rendements - Mise en place de méthodes de planification, de communication, de délégation, de validation et de contrôle - Supervision et discipline - Déléguer le niveau d'autorité correspondant à la responsabilité Comment motiver les membres de son équipe : - Prise en compte de la diversité des modes de fonctionnement individuels et les enjeux inter-personnels - Outils d'évaluation des compétences et du potentiel de chacun - Développer un plan de carrière - Techniques efficaces d'écoute - Identifier les points forts et les points faibles en vue de déterminer les besoins en formation - Comprendre les motivations individuelles et de groupe - Comment impliquer les collaborateurs et encourager les initiatives - Techniques pour motiver un individu et motiver un groupe - Communiquer de manière formelle et informelle DATES ET LIEUX DE LA FORMATION Région de Montréal : Les 19-20-21 FÉVRIER 2008 Sheraton, 2440, Autoroute des Laurentides, Laval Région de Québec : Les 15-16-17 JANVIER 2008 Hôtel des Gouverneurs, 3030 boul. Laurier, Ste-Foy N.B. Nombre de places limitées à 15 personnes Pour inscription, veuillez nous contacter au 450-226-2238 / 1-800-861-6618 1- Si vous souhaitez recevoir nos offres de formation, cliquez ici: http://content.dynamicmessenger.com/compufinder/?oAYGpb.KUfU571ioL0APMl32c5o 2- Si vous souhaitez vous retirer definitivement de notre base de donnees, cliquez ici: http://content.dynamicmessenger.com/compufinder/?oAYGpb.KUfU571ioL0APMl32c5o From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 08:36:02 2007 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 81D1316A41A; Thu, 20 Dec 2007 08:36:02 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8D913C44B; Thu, 20 Dec 2007 08:36:01 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBK8Zuap004999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 19:35:57 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id lBK8ZuxA064436; Thu, 20 Dec 2007 19:35:56 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id lBK8Zt5O064435; Thu, 20 Dec 2007 19:35:55 +1100 (EST) (envelope-from peter) Date: Thu, 20 Dec 2007 19:35:55 +1100 From: Peter Jeremy To: Mark Fullmer Message-ID: <20071220083555.GO79196@server.vk2pj.dyndns.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 20 Dec 2007 08:36:02 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2007 at 12:06:59PM -0500, Mark Fullmer wrote: >Thanks for the other info on timer resolution, I overlooked >clock_gettime(). If you have a UP system with a usable TSC (or equivalent) then using rdtsc() (or equivalent) is a much cheaper way to measure short durations with high resolution. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHailr/opHv/APuIcRAqRQAJ4x4iTL9WiMWXy6VHcl9DLyMRWLEACdHJXI I3yP2HkQ+YAf+Ka8s/qSEoM= =6ncl -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 10:50:13 2007 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 C110C16A418 for ; Thu, 20 Dec 2007 10:50:13 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D18113C467 for ; Thu, 20 Dec 2007 10:50:13 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1J5IyY-0000td-Lc for freebsd-stable@freebsd.org; Thu, 20 Dec 2007 10:50:02 +0000 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, 20 Dec 2007 10:50:02 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Dec 2007 10:50:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 20 Dec 2007 11:47:57 +0100 Lines: 27 Message-ID: References: <200712192036.lBJKaWYp008250@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD67C0B7579D92032054794D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <200712192036.lBJKaWYp008250@fire.js.berklix.net> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: 7.0BETA4 ../cc_tools/insn-attrtab.c compiles forever 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, 20 Dec 2007 10:50:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD67C0B7579D92032054794D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Julian Stacey wrote: > Anyone else noticed on 7.0BETA4 (& hence Ive cc'd re@) I did see some weird behaviour while compiling gcc, though I don't remember if it's the same file (looks like it). They usually disappeared after removing CPUTYPE and -O2 from compiler flags. --------------enigAD67C0B7579D92032054794D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHakhdldnAQVacBcgRApaNAKCuZ1U2TOlc2JNjjUG/df97PdQzlQCgr0lS V0KnwKQxFOSKZ6WSm3Q/MFs= =2MgR -----END PGP SIGNATURE----- --------------enigAD67C0B7579D92032054794D-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 12:01:16 2007 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 5104E16A46E for ; Thu, 20 Dec 2007 12:01:16 +0000 (UTC) (envelope-from ntarmos@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id C6C3913C4E3 for ; Thu, 20 Dec 2007 12:01:15 +0000 (UTC) (envelope-from ntarmos@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 23986EB5750; Thu, 20 Dec 2007 13:33:33 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id D62051587A4; Thu, 20 Dec 2007 13:33:32 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXjo+eo6qlSM; Thu, 20 Dec 2007 13:33:32 +0200 (EET) Received: from ace.netcins.ceid.upatras.gr (vfppp079167010077.dsl.hol.gr [79.167.10.77]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 7739D157F6A; Thu, 20 Dec 2007 13:33:32 +0200 (EET) Received: by ace.netcins.ceid.upatras.gr (Postfix, from userid 1001) id 64DCD3F44E; Thu, 20 Dec 2007 13:33:31 +0200 (EET) Date: Thu, 20 Dec 2007 13:33:31 +0200 From: Nikos Ntarmos To: Julian Stacey Message-ID: <20071220113331.GA83912@ace.netcins.ceid.upatras.gr> References: <200712192036.lBJKaWYp008250@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200712192036.lBJKaWYp008250@fire.js.berklix.net> Organization: NetCInS Lab., C.E.I.D., U. of Patras, Greece WWW-Homepage: http://ntarmos.dyndns.org/ X-PGP-Fingerprint: 9680 60A7 DE60 0298 B1F0 9B22 9BA2 7569 CF95 160A Office-Phone: +30-2610-996919 Office-Fax: +30-2610-969011 GPS-Info: 38.31N, 21.82E User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: stable@freebsd.org Subject: Re: 7.0BETA4 ../cc_tools/insn-attrtab.c compiles forever 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, 20 Dec 2007 12:01:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 19, 2007 at 09:36:32PM +0100, Julian Stacey wrote: > Anyone else noticed on 7.0BETA4 (& hence Ive cc'd re@) > > This runs forever: > > ===> cc_int (all) > Warning: Object directory not changed from original /usr/src/gnu/usr.bin/cc/cc_int > cc -O2 -fno-strict-aliasing -march=i586 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -c ../cc_tools/insn-attrtab.c > > With or without -pipe & with or without /usr/obj > All the rest of /usr/src compiles OK though. > > FreeBSD lapn.js.berklix.net 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Sun Dec 16 09:18:21 CET 2007 jhs@lapn.js.berklix.net:/usr/src/sys/i386/compile/GENERIC i386 Hi there. I'd bet you're seeing some serious thrashing there. I've come across at least one other user having problems with that particular part of buildworld and -O2/-Os optimization levels. Seems like gcc4 is quite the memory hog so I don't know whether something can be done, other than either adding more RAM, trying to tweak swappiness, or taking a break while this thing compiles itself. Cheers. \n\n -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Nikos Ntarmos iD8DBQFHalMLm6J1ac+VFgoRAiE0AJ94qpti098fL9xs5XV2Jbeg/Al5NgCcClxA AC8C6HMO6d13OoKlfdqy9Wc= =fUnL -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 12:24:10 2007 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 8B9F616A417 for ; Thu, 20 Dec 2007 12:24:10 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 76C4513C45B for ; Thu, 20 Dec 2007 12:24:09 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 204216272E for ; Thu, 20 Dec 2007 14:24:08 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64529-03 for ; Thu, 20 Dec 2007 14:24:04 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 1D37E62757 for ; Thu, 20 Dec 2007 14:24:04 +0200 (EET) Message-ID: <476A5EE1.9000003@bulinfo.net> Date: Thu, 20 Dec 2007 14:24:01 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: FreeBSD X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: Performance! 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, 20 Dec 2007 12:24:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have read all related threads about performance problems with multi core systems but still have no idea what to do to make thinks better. Below are results of testing postgresql on HP DL380G5 using sysbench. The results are comparable to: http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 but the same tests running on the same hardware using Linux (kernel 2.6.18-53.1.4.el5 SMP x86_64) are very different. PostgreSQL is tuned equal. dmesg: ... CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd> AMD Features=0x20000800 AMD Features2=0x1 Cores per package: 4 usable memory = 8575655936 (8178 MB) avail memory = 8288337920 (7904 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs ... test: sysbench --num-threads=${i} --test=oltp --pgsql-user=bench - --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0 - --oltp-read-only=on run tuning: kern.ipc.shmmax=2147483647 kern.ipc.shmall=524288 kern.ipc.semmsl=512 kern.ipc.semmap=256 kern.ipc.somaxconn=2048 kern.maxfiles=65536 vfs.read_max=32 kern.ipc.semmni=256 kern.ipc.semmns=2048 results: FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE #threads #transactions/sec user/system 1 500 7.4%,5.3% 5 1990 30.9%,23.4% 10 2510 39.9%,35.0% 20 2549 44.5%,43.5% 40 1921 29.8%,59.4% 60 1580 22.7%,70.6% 80 1341 18.9%,75.9% 100 1227 16.5%,79.3% Linux #threads #transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 What can be done to improve these results? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHal7hxJBWvpalMpkRAsaiAJ9G3ZoTv6cUbR4yix07TEMf7PKm7gCgoroM +xvcXkcaFjSTxYfjk5rqMko= =Tpsq -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 12:39:52 2007 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 6F1BA16A417 for ; Thu, 20 Dec 2007 12:39:52 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [213.186.42.107]) by mx1.freebsd.org (Postfix) with ESMTP id 3B85E13C448 for ; Thu, 20 Dec 2007 12:39:51 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from roxette.lamaiziere.net (unknown [77.192.6.103]) by smtp.lamaiziere.net (Postfix) with ESMTP id 738C811805AA for ; Thu, 20 Dec 2007 13:24:30 +0100 (CET) Received: from roxette.lamaiziere.net (localhost [127.0.0.1]) by roxette.lamaiziere.net (Postfix) with ESMTP id 4B26941D6 for ; Thu, 20 Dec 2007 13:24:28 +0100 (CET) Date: Thu, 20 Dec 2007 13:24:26 +0100 From: Patrick Lamaiziere To: "freebsd-stable@FreeBSD.org" Message-ID: <20071220132426.16092f14@roxette.lamaiziere.net> Organization: /dave/nulle X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: [7.0 beta4] iwi : firmware stuck in state 4, resetting 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, 20 Dec 2007 12:39:52 -0000 Hi, I've got many deconnections with iwi on 7.0 with WPA, far more than on 6.2. iwi0: firmware error iwi0: link state changed to DOWN iwi0: link state changed to UP iwi0: firmware stuck in state 4, resetting [...] Then I have to make an "/etc/rc.d/netif restart iwi0" to reconnect. With debug enable on iwi : Dec 15 01:12:03 roxette kernel: sending command idx=13 type=26 len=96 Dec 15 01:12:03 roxette kernel: Beacon miss: 26 >= 24 Dec 15 01:12:03 roxette kernel: Beacon miss: 27 >= 24 Dec 15 01:12:03 roxette kernel: Beacon miss: 28 >= 24 Dec 15 01:12:04 roxette kernel: Beacon miss: 29 >= 24 Dec 15 01:12:08 roxette kernel: iwi0: firmware stuck in state 4, resetting I put the complete log here : http://user.lamaiziere.net/patrick/messages.4.bz2 Any idea ? Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 12:50:36 2007 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 E055016A420 for ; Thu, 20 Dec 2007 12:50:36 +0000 (UTC) (envelope-from chris@shenton.org) Received: from shenton.org (static-71-246-241-106.washdc.fios.verizon.net [71.246.241.106]) by mx1.freebsd.org (Postfix) with SMTP id 716D513C4D3 for ; Thu, 20 Dec 2007 12:50:36 +0000 (UTC) (envelope-from chris@shenton.org) Received: (qmail 29467 invoked by uid 1001); 20 Dec 2007 12:50:35 -0000 From: Chris Shenton To: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org References: <86hciuilpx.fsf@PECTOPAH.shenton.org> <86bq8yjwii.fsf@PECTOPAH.shenton.org> Date: Thu, 20 Dec 2007 07:50:35 -0500 In-Reply-To: <86bq8yjwii.fsf@PECTOPAH.shenton.org> (Chris Shenton's message of "Mon, 10 Dec 2007 12:21:41 -0500") Message-ID: <863atxil7o.fsf@Bacalao.shenton.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on Dell T105? ($350 dual-core Opteron) 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, 20 Dec 2007 12:50:37 -0000 [I'm adding -current as there are other discussions of hardware compatibility there, trim if appropriate] Chris Shenton writes: > http://www.dell.com/downloads/global/products/pedge/en/pe_T105_spec_sheet.pdf > > Processors Single AMD Opteron TM 1000 series at up to 2.8GHz; > Single AMD SempronTM LE1250 at 2.2GHz > > HyperTransportTM HyperTransport at 2000MT/s > > Chipset nVidia CK8-04 Pro > > Network Interfaces Single embedded Gigabit3 NIC I installed FreeBSD 7.0-BETA4 amd64 this morning and it boots fine, detects both CPUs, but can't seem to find a driver for the ethernet. It doesn't offer anything at install time (only slip and ppp) and shows nothing in ifconfig when running. The one thing I see in dmesg is: pci2: at device 0.0 (no driver attached) Some pages I've found say this is a Broadcom 5721J chipset: http://www1.ap.dell.com/content/products/features.aspx/servers_Q4_W5_2007-12-01_pedge_t105_Q421211?c=my&cs=mybsd1&l=en&s=bsd An Ubuntu message says they see it with a Broadcom NetXtreme BCM5722 driver: http://ubuntuforums.org/showthread.php?p=3961378 Any suggestions on how I can poke at it to find what kind of hardware it's using and what driver I need to use for it? Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 13:09:16 2007 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 5EC0C16A41A; Thu, 20 Dec 2007 13:09:16 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id E05CE13C4E9; Thu, 20 Dec 2007 13:09:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-059-174.pools.arcor-ip.net [88.66.59.174]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1J5L9B2oVs-00078i; Thu, 20 Dec 2007 14:09:14 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Thu, 20 Dec 2007 14:09:00 +0100 User-Agent: KMail/1.9.7 References: <86hciuilpx.fsf@PECTOPAH.shenton.org> <86bq8yjwii.fsf@PECTOPAH.shenton.org> <863atxil7o.fsf@Bacalao.shenton.org> In-Reply-To: <863atxil7o.fsf@Bacalao.shenton.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart32384406.7d5tQoNgAs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712201409.08385.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+vZcNf3oOccoXWhs95KFX1WiLm9kmIrJGQhpr 23F00HT8RjaLYRIfhPkZ8xG9Mc+bQrVcaxOByMwjONXYQ9RDtP NlVsHI0QaJwHae/H83g6yNcviLzTBtelrhIOX9onh0= Cc: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: FreeBSD on Dell T105? ($350 dual-core Opteron) 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, 20 Dec 2007 13:09:16 -0000 --nextPart32384406.7d5tQoNgAs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 20 December 2007, Chris Shenton wrote: > [I'm adding -current as there are other discussions of hardware > compatibility there, trim if appropriate] > > Chris Shenton writes: > > =20 > > http://www.dell.com/downloads/global/products/pedge/en/pe_T105_spec_s > >heet.pdf > > > > Processors Single AMD Opteron TM 1000 series at up to > > 2.8GHz; Single AMD SempronTM LE1250 at 2.2GHz > > > > HyperTransportTM HyperTransport at 2000MT/s > > > > Chipset nVidia CK8-04 Pro > > > > Network Interfaces Single embedded Gigabit3 NIC > > I installed FreeBSD 7.0-BETA4 amd64 this morning and it boots fine, > detects both CPUs, but can't seem to find a driver for the ethernet. It > doesn't offer anything at install time (only slip and ppp) and shows > nothing in ifconfig when running. > > The one thing I see in dmesg is: > > pci2: at device 0.0 (no driver attached) > > Some pages I've found say this is a Broadcom 5721J chipset: > > =20 > http://www1.ap.dell.com/content/products/features.aspx/servers_Q4_W5_20 >07-12-01_pedge_t105_Q421211?c=3Dmy&cs=3Dmybsd1&l=3Den&s=3Dbsd > > An Ubuntu message says they see it with a Broadcom NetXtreme BCM5722 > driver: > > > http://ubuntuforums.org/showthread.php?p=3D3961378 > > Any suggestions on how I can poke at it to find what kind of hardware > it's using and what driver I need to use for it? Sounds like the bge(4) driver might work. Take a look at "pciconfig -lv"=20 to identify the chip and PCI vendor id. Try adding that information to=20 src/sys/dev/bge/if_bge.c::bge_devs[] and subsequent chip revision arrays. = =20 It's easiest to build a kernel w/o device bge and loading bge from=20 modules. This way you can cd to src/sys/modules/bge and "make load;=20 #test; make unload; #change source; #repeat" until it works. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart32384406.7d5tQoNgAs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHaml0XyyEoT62BG0RAu6JAJ4siW1lj/psgDkefZ4N5P+2FuYTOwCdFCu/ mdJ+XPLur18lW4v8MvAF4Jg= =tBtJ -----END PGP SIGNATURE----- --nextPart32384406.7d5tQoNgAs-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 13:21:58 2007 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 9045C16A417 for ; Thu, 20 Dec 2007 13:21:58 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 5013A13C46B for ; Thu, 20 Dec 2007 13:21:58 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0JTC00L0YNBRPAB0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 20 Dec 2007 14:11:51 +0100 (CET) Received: from kg-work.kg4.no ([80.202.173.59]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0JTC00LL5NBQP2A1@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 20 Dec 2007 14:11:51 +0100 (CET) Date: Thu, 20 Dec 2007 14:11:50 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20071220141150.0f6c17ed.torfinn.ingolfsen@broadpark.no> In-reply-to: <863atxil7o.fsf@Bacalao.shenton.org> References: <86hciuilpx.fsf@PECTOPAH.shenton.org> <86bq8yjwii.fsf@PECTOPAH.shenton.org> <863atxil7o.fsf@Bacalao.shenton.org> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.3; i386-portbld-freebsd6.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD on Dell T105? ($350 dual-core Opteron) 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, 20 Dec 2007 13:21:58 -0000 On Thu, 20 Dec 2007 07:50:35 -0500 Chris Shenton wrote: > Any suggestions on how I can poke at it to find what kind of hardware > it's using and what driver I need to use for it? 'pciconf -lv' is usually good for the "poking" part. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 13:22:33 2007 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 ABD5116A469 for ; Thu, 20 Dec 2007 13:22:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6B77C13C447 for ; Thu, 20 Dec 2007 13:22:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id A3CFF74400F; Thu, 20 Dec 2007 14:59:13 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjDNZhbOHwlh; Thu, 20 Dec 2007 14:59:13 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 81EC474400E; Thu, 20 Dec 2007 14:59:13 +0200 (EET) Message-ID: <476A6721.5020404@icyb.net.ua> Date: Thu, 20 Dec 2007 14:59:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 References: <475FC26C.3030508@icyb.net.ua> <200712130930.08558.nvass@teledomenet.gr> <4760FE68.60001@icyb.net.ua> <200712131213.37478.nvass@teledomenet.gr> <47610957.8020800@icyb.net.ua> In-Reply-To: <47610957.8020800@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Nikos Vassiliadis Subject: mounted cd, tray locking, cdcontrol 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, 20 Dec 2007 13:22:33 -0000 FreeBSD 6.2-RELEASE-p6 amd64 This is what "cdcontrol eject" performs (incidentally, on a mounted acd device): 11991 cdcontrol CALL open(0x7fffffffe130,0,0x9) 11991 cdcontrol NAMI "/dev/acd0" 11991 cdcontrol RET open 3 11991 cdcontrol CALL ioctl(0x3,CDIOCALLOW,0) 11991 cdcontrol RET ioctl 0 11991 cdcontrol CALL ioctl(0x3,CDIOCEJECT,0) 11991 cdcontrol RET ioctl -1 errno 16 Device busy 11991 cdcontrol CALL exit(0xffffffff) This is how handling of the above ioctls looks in atapi-cd.c: ... case CDIOCALLOW: error = acd_prevent_allow(dev, 0); cdp->flags &= ~F_LOCKED; break; ... case CDIOCEJECT: if (pp->acr != 1) { error = EBUSY; break; } error = acd_tray(dev, 0); break; ... In other words: CDIOCALLOW - unconditionally send "allow" to the device CDIOCEJECT - if device is opened by anybody else other than ioctl issuer then return EBUSY, otherwise send "stop (without eject)", "allow", "eject". So, if you issue cdcontrol eject on a mounted (or otherwise opened device) the net result is weird: CD tray is not ejected but it is unlocked, i.e pressing a button on the physical device will eject the tray. I think this is messy. The most obvious target is cdcontrol - it doesn't have to issue CDIOCALLOW and actually this ioctl creates all the mess (but read about SCSI devices below). Possible secondary target: maybe CDIOCALLOW should also do some checking of current access to the device. BTW, it would be also nice to have separate 'allow' and 'prevent' commands of cdcontrol, if just for the sake of testing. >From a cursory glance at scsi_cd.c it seems that for SCSI CD-ROMs there are no "in-use" checks for either of the ioctls: CDIOCALLOW - unconditionally send "allow" to the device CDIOCEJECT - unconditionally send "eject" I am not sure if I like this but at least this is consistent: if I'd issue "cdcontrol eject" on a cd device, then it would be actually ejected no matter what. (And this is exactly because of the explicit CDIOCALLOW from cdcontrol, because "prevent" was internally issued to a drive on device open). For acd it neither ejects nor preserves original state. So another target is inconsistency in ioctl handling between cd and acd. And I don't want yet to cloud the matters with interaction between scsi-cd driver and atapi-cd driver when atapicam is enabled :-) P.S. a PR with a terse description is already opened for the above behavior of acd: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118779 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 13:56:38 2007 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 210FD16A46B for ; Thu, 20 Dec 2007 13:56:38 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 78CDB13C455 for ; Thu, 20 Dec 2007 13:56:36 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id lBKDuY3o073067; Thu, 20 Dec 2007 20:56:34 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id lBKDuYcN073065; Thu, 20 Dec 2007 20:56:34 +0700 (KRAT) (envelope-from eugen) Date: Thu, 20 Dec 2007 20:56:34 +0700 From: Eugene Grosbein To: Andriy Gapon Message-ID: <20071220135634.GA72031@svzserv.kemerovo.su> References: <475FC26C.3030508@icyb.net.ua> <200712130930.08558.nvass@teledomenet.gr> <4760FE68.60001@icyb.net.ua> <200712131213.37478.nvass@teledomenet.gr> <47610957.8020800@icyb.net.ua> <476A6721.5020404@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476A6721.5020404@icyb.net.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Nikos Vassiliadis Subject: Re: mounted cd, tray locking, cdcontrol 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, 20 Dec 2007 13:56:38 -0000 On Thu, Dec 20, 2007 at 02:59:13PM +0200, Andriy Gapon wrote: > P.S. a PR with a terse description is already opened for the above > behavior of acd: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118779 This is a regression since RELENG_4 (RELENG_3 was OK), please take a look at (incorrectly closed) PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/28166 Eugene From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 14:35:54 2007 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 1895B16A419 for ; Thu, 20 Dec 2007 14:35:54 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id C764C13C442 for ; Thu, 20 Dec 2007 14:35:53 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so982542anc.13 for ; Thu, 20 Dec 2007 06:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zQxfidO1x8+uYnfwRxx1VftC5JbwuFfc3RgT2e0MJT0=; b=JlA3+IUouPhThDc3hajXfbPly61DT5EwROr4C+2zrMZF+8jFwH3VSiF/TV4ZQv3ZdKEXL8WnTE2yrMCCSssgkAMTInX8mEDQf+6ZaHeuJqEZB0C9H3vC2n5wVZ1anpsiS4y9bJPPEQVo4UiO6ny61FiZqPyG+L72+lIV2Nww8cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jF9fi61oqGZYNW62eB1NLLGJV+mdFR/avcXUuQmsl6cNpOqpwR4fdrg725di4YPBZ1/cetnfQyDh8F+HCOayQfxiAPDy0RiA1w+iCGD2FP3thb7SdmveIMSkNS24X/8MrTfT6LCbrIAlkenh2ErNRB6PCqYW+hvTbaYg5MmCNnM= Received: by 10.100.229.10 with SMTP id b10mr93456anh.37.1198161352627; Thu, 20 Dec 2007 06:35:52 -0800 (PST) Received: by 10.100.228.15 with HTTP; Thu, 20 Dec 2007 06:35:52 -0800 (PST) Message-ID: Date: Thu, 20 Dec 2007 15:35:52 +0100 From: "Claus Guttesen" To: "Krassimir Slavchev" In-Reply-To: <476A5EE1.9000003@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <476A5EE1.9000003@bulinfo.net> Cc: FreeBSD Subject: Re: Performance! 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, 20 Dec 2007 14:35:54 -0000 > I have read all related threads about performance problems with multi > core systems but still have no idea what to do to make thinks better. > Below are results of testing postgresql on HP DL380G5 using sysbench. > The results are comparable to: > http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 > but the same tests running on the same hardware using Linux (kernel > 2.6.18-53.1.4.el5 SMP x86_64) are very different. > PostgreSQL is tuned equal. > > results: > FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE > #threads #transactions/sec user/system > 1 500 7.4%,5.3% > 5 1990 30.9%,23.4% > 10 2510 39.9%,35.0% > 20 2549 44.5%,43.5% > 40 1921 29.8%,59.4% > 60 1580 22.7%,70.6% > 80 1341 18.9%,75.9% > 100 1227 16.5%,79.3% > > Linux > #threads #transactions/sec > 1 693 > 5 3539 > 10 5789 > 20 5791 > 40 5661 > 60 5517 > 80 5401 > 100 5319 > > What can be done to improve these results? What postgres-version did you use for this benchmark? Eventhough this is a synthetic benchmark the difference in performance may indicate some penalties on 8-core servers on FreeBSD. According to http://people.freebsd.org/~kris/scaling/mysql.html mysql scale the same until until 8 clients on both Linux and FreeBSD. This is an older test though and Linux has probably done some optimizations. Could be interesting so see whether the results differ if you disable one of the cpu's and rerun the tests. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 17:06:49 2007 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 456A616A418 for ; Thu, 20 Dec 2007 17:06:49 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9F44A13C467 for ; Thu, 20 Dec 2007 17:06:48 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id lBKH6fPu067682; Thu, 20 Dec 2007 18:06:46 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBKH6fwn067680; Thu, 20 Dec 2007 18:06:41 +0100 (CET) (envelope-from olli) Date: Thu, 20 Dec 2007 18:06:41 +0100 (CET) Message-Id: <200712201706.lBKH6fwn067680@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, maxx@mobistarmail.be, jcoombs@gwi.net In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 20 Dec 2007 18:06:47 +0100 (CET) Cc: Subject: Re: FreeBSD 7 on old SMP server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, maxx@mobistarmail.be, jcoombs@gwi.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 17:06:49 -0000 Joshua Coombs wrote: > MaXX wrote: > > I have an old netfinity 7000 (Quad PIII 500, 1Gb RAM) running 6.2 > > at the moment. I was wondering if it will take benefit of all the > > SMP improvement of 7 or is it too old? It runs a few postgresql > > databases, peak loads in the 2 to 4 range. It's not too old, and I would recommend that you give 7.0 a try. Don't forget to enable the ULE scheduler. I've got a dual Celeron-466 with 448 MB RAM, and it's certainly not too old, either. (OK, Celerons aren't the best processor to build an SMP system, but it does work nicely for me. And it was dead cheap for an SMP system at the time when I built it, about 10 years ago.) > My hacked up 386 showed gains going from 6.2 to 7, the big win that I've > noticed is scp throughput, I can sustain 40 to 45kbps where in the past > the box walled at around 30kbps. Apache seems to have less latency > responding to gets also. I'm just running a 7b3 kernel at the moment, > I'm going to have to repartition with a lot more swap space to be able > to build a 7 world (When did the ram use for a buildworld skyrocket?!) > but even with this setup, 7 + ULE is a win for me. Are you saying you run FreeBSD 7 on an 80386(SX/DX) machine? How exactly did you hack it? As far as I know, support for 80386 processors was removed from FreeBSD a while ago. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 17:26:51 2007 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 90C3D16A46C for ; Thu, 20 Dec 2007 17:26:51 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id E793F13C47E for ; Thu, 20 Dec 2007 17:26:50 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id lBKHQeUS068644; Thu, 20 Dec 2007 18:26:48 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBKHQcOd068643; Thu, 20 Dec 2007 18:26:38 +0100 (CET) (envelope-from olli) Date: Thu, 20 Dec 2007 18:26:38 +0100 (CET) Message-Id: <200712201726.lBKHQcOd068643@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, jhs@berklix.org In-Reply-To: <200712181108.lBIB8rAL090380@fire.js.berklix.net> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 20 Dec 2007 18:26:48 +0100 (CET) Cc: Subject: Re: 7.0BETA4 /usr/src/gnu/usr.bin/cc/cc_int Thrashes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, jhs@berklix.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 17:26:51 -0000 Julian Stacey wrote: > Has 7.0-BETA4 perhaps wrongly got a -pipe in the .mk macros ? It was added 9 years 7 months ago my JKH (see the CVS repository, src/share/mk/sys.mk rev 1.31). He wrote: "Add -pipe to default CFLAGS. The optimization it provides is cheap and does not require any special action on the part of the user to take advantage of it." It might not be that "cheap" anymore with gcc 4.2 being the default compiler now, known to be somewhat more RAM- hungry than its predecessors. However, I still think that -pipe should be kept on by default, because it will help on the vast majority of machines. Old machines with very little RAM need some special-tuning anyway, so it's reasonable to give them special CFLAGS that don't contain -pipe. (Apart from that I would recommend to use a faster and sufficiently RAM-equipped machine for building and then perform only the install on the smaller machine, or install directly on its harddisk by plugging it into the faster machine temporarily. That's how I used to update an old 486SX notebook that had only 4 MB RAM and no network except SLIP/PLIP.) YMMV, of course. Please take the above only as my personal opinion on the matter. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 17:41:22 2007 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 AD96016A46B for ; Thu, 20 Dec 2007 17:41:22 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 12F8013C474 for ; Thu, 20 Dec 2007 17:41:21 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id lBKHfFLD069153; Thu, 20 Dec 2007 18:41:20 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBKHfDRb069152; Thu, 20 Dec 2007 18:41:13 +0100 (CET) (envelope-from olli) Date: Thu, 20 Dec 2007 18:41:13 +0100 (CET) Message-Id: <200712201741.lBKHfDRb069152@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, 000.fbsd@quip.cz, lists@lozenetz.org In-Reply-To: <47682873.8050601@quip.cz> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 20 Dec 2007 18:41:21 +0100 (CET) Cc: Subject: Re: jlogin.sh - a small nice jails helper! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, 000.fbsd@quip.cz, lists@lozenetz.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 17:41:22 -0000 Miroslav Lachman wrote: > It is nice idea, but I think you should have a better scripting style ;) Yes, it almost looked like perl. :-) May I suggest a few further improvements? > login_shell="/bin/tcsh" I certainly wouldn't want tcsh. How about looking at $SHELL, and if it doesn't exist, then fall back to the standard shell (which is /bin/sh). Also, the last command (jexec) should be preceded by "exec" so the shell doesn't hang around. So the last part of the script would look like this: jail_path=$(jls | awk '$1=='$jail_id' {print $4}') if [ -z "$SHELL" -o ! -x "$jail_path/$SHELL" ]; then login_shell="$SHELL" else login_shell="/bin/sh" fi echo "Logging in to $jail_hostname" exec jexec $jail_id $login_shell Best regards Oliver PS: By the way, here's another useful script that displays processes running in jails, ordered by jail IDs: http://www.secnetix.de/~olli/scripts/jps -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 18:13:47 2007 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 0C38C16A420 for ; Thu, 20 Dec 2007 18:13:47 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AC7A013C457 for ; Thu, 20 Dec 2007 18:13:46 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J5PTo-0007Ic-8p for freebsd-stable@freebsd.org; Thu, 20 Dec 2007 17:46:44 +0000 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Dec 2007 17:46:44 +0000 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Dec 2007 17:46:44 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Joshua Coombs Date: Thu, 20 Dec 2007 12:14:49 -0500 Lines: 24 Message-ID: References: <200712201706.lBKH6fwn067680@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <200712201706.lBKH6fwn067680@lurza.secnetix.de> Sender: news Subject: Re: FreeBSD 7 on old SMP server? 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, 20 Dec 2007 18:13:47 -0000 Oliver Fromme wrote: > > > My hacked up 386 showed gains going from 6.2 to 7, the big win that I've > > noticed is scp throughput, I can sustain 40 to 45kbps where in the past > > the box walled at around 30kbps. Apache seems to have less latency > > responding to gets also. I'm just running a 7b3 kernel at the moment, > > I'm going to have to repartition with a lot more swap space to be able > > to build a 7 world (When did the ram use for a buildworld skyrocket?!) > > but even with this setup, 7 + ULE is a win for me. > > Are you saying you run FreeBSD 7 on an 80386(SX/DX) machine? > How exactly did you hack it? As far as I know, support for > 80386 processors was removed from FreeBSD a while ago. For a very short while with 6.0 I was tweaking the kernel to detect 386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok luck. I've now got a Cyrix 486DrX-2 66 installed in place of my Am386DX-40, which supports CMPXCHG as well as ID'ing as a 486 so I don't need to do any tweaking to stay running. If I can get another viable 386DX box reassembled I'll see if 7 can be pressed into functioning on it as 6 could. Joshua Coombs From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 19:21:44 2007 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 7E32316A419 for ; Thu, 20 Dec 2007 19:21:44 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [82.208.36.70]) by mx1.freebsd.org (Postfix) with ESMTP id 3314E13C4E3 for ; Thu, 20 Dec 2007 19:21:43 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B55AD19E023 for ; Thu, 20 Dec 2007 20:21:42 +0100 (CET) Received: from [192.168.1.2] (r3a200.net.upc.cz [213.220.192.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id 03B7719E019 for ; Thu, 20 Dec 2007 20:21:30 +0100 (CET) Message-ID: <476AC0D7.7090402@quip.cz> Date: Thu, 20 Dec 2007 20:21:59 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG References: <200712201741.lBKHfDRb069152@lurza.secnetix.de> In-Reply-To: <200712201741.lBKHfDRb069152@lurza.secnetix.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: jlogin.sh - a small nice jails helper! 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, 20 Dec 2007 19:21:44 -0000 Oliver Fromme wrote: > Miroslav Lachman wrote: > > It is nice idea, but I think you should have a better scripting style ;) > > Yes, it almost looked like perl. :-) > May I suggest a few further improvements? > > > login_shell="/bin/tcsh" > > I certainly wouldn't want tcsh. How about looking at > $SHELL, and if it doesn't exist, then fall back to the > standard shell (which is /bin/sh). I have tought about optional second argument with shell name, your idea about $SHELL is also good. > Also, the last command (jexec) should be preceded by > "exec" so the shell doesn't hang around. So the last > part of the script would look like this: > > jail_path=$(jls | awk '$1=='$jail_id' {print $4}') > > if [ -z "$SHELL" -o ! -x "$jail_path/$SHELL" ]; then > login_shell="$SHELL" > else > login_shell="/bin/sh" > fi > > echo "Logging in to $jail_hostname" > exec jexec $jail_id $login_shell > > Best regards > Oliver > > PS: By the way, here's another useful script that displays > processes running in jails, ordered by jail IDs: > > http://www.secnetix.de/~olli/scripts/jps I am using your jps in slightly modified version ;) ME="${0##*/}" Usage() { cat <<-tac $ME -- List processes that are running inside a jail. This is intended to complement the standard jls(8) command. Usage: $ME list all jailed processes $ME list only processes in jail Run the jls(8) command to get a list of jails and JIDs. tac exit 1 } if [ $# -gt 2 ]; then Usage fi if [ $# -eq 1 ]; then case "$1" in ""|*[!0-9]*) Usage ;; esac FILTER='$1=="'$1'"' sum_jid="$1" jname=`jls | awk "$FILTER"'{ print $3 }'` else FILTER='$1!="0"' sum_jid="all" jname="-" fi ps -axww -o jid,pid,%mem,rss,user,command | awk '$1!~/[0-9]/||'"$FILTER" | sort -n echo echo "==============================" echo " summary for JID $sum_jid / $jname" echo " %MEM RSS VSZ %CPU " ps -axww -o jid,%mem,rss,vsz,%cpu | awk '$1!~/[0-9]/||'"$FILTER" | awk '{ sm += $2; sp += $3; sv += $4; sc += $5 } END { printf(" %3d %9i %9i %3d \n", sm, sp, sv, sc) }' #-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 19:32:22 2007 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 372F516A46B for ; Thu, 20 Dec 2007 19:32:22 +0000 (UTC) (envelope-from bri@brianwhalen.net) Received: from entwistle.sonicboom.org (entwistle.sonicboom.org [66.93.34.170]) by mx1.freebsd.org (Postfix) with ESMTP id E29AD13C4CC for ; Thu, 20 Dec 2007 19:32:21 +0000 (UTC) (envelope-from bri@brianwhalen.net) Received: from [127.0.0.1] (entwistle.sonicboom.org [66.93.34.170]) by entwistle.sonicboom.org (8.14.2/8.14.1) with ESMTP id lBKJ84wt002091; Thu, 20 Dec 2007 11:08:04 -0800 (PST) (envelope-from bri@brianwhalen.net) Message-ID: <476ABD93.3080707@brianwhalen.net> Date: Thu, 20 Dec 2007 11:08:03 -0800 From: Brian User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Joshua Coombs References: <200712201706.lBKH6fwn067680@lurza.secnetix.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7 on old SMP server? 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, 20 Dec 2007 19:32:22 -0000 Joshua Coombs wrote: > Oliver Fromme wrote: >> >> > My hacked up 386 showed gains going from 6.2 to 7, the big win >> that I've > noticed is scp throughput, I can sustain 40 to 45kbps >> where in the past > the box walled at around 30kbps. Apache seems >> to have less latency > responding to gets also. I'm just running a >> 7b3 kernel at the moment, > I'm going to have to repartition with a >> lot more swap space to be able > to build a 7 world (When did the >> ram use for a buildworld skyrocket?!) > but even with this setup, 7 >> + ULE is a win for me. >> >> Are you saying you run FreeBSD 7 on an 80386(SX/DX) machine? >> How exactly did you hack it? As far as I know, support for >> 80386 processors was removed from FreeBSD a while ago. > > For a very short while with 6.0 I was tweaking the kernel to detect > 386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok > luck. I've now got a Cyrix 486DrX-2 66 installed in place of my > Am386DX-40, which supports CMPXCHG as well as ID'ing as a 486 so I > don't need to do any tweaking to stay running. > > If I can get another viable 386DX box reassembled I'll see if 7 can be > pressed into functioning on it as 6 could. > > Joshua Coombs > > _______________________________________________ > 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" Would that be a multiday buildworld? Brian From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 20:45:53 2007 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 B3CBD16A41B for ; Thu, 20 Dec 2007 20:45:53 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 59CF813C43E for ; Thu, 20 Dec 2007 20:45:53 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 79588 invoked from network); 20 Dec 2007 20:45:52 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 20 Dec 2007 20:45:52 -0000 In-Reply-To: <20071219181158.GC57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071219181158.GC57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C1F9DB7-1B79-4718-9A27-379D1E6F0F10@eng.oar.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Thu, 20 Dec 2007 15:45:35 -0500 To: Kostik Belousov X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 20 Dec 2007 20:45:53 -0000 Thanks, I'll test this later on today. On Dec 19, 2007, at 1:11 PM, Kostik Belousov wrote: > On Wed, Dec 19, 2007 at 09:13:31AM -0800, David G Lawrence wrote: >>>> Try it with "find / -type f >/dev/null" to duplicate the problem >>>> almost >>>> instantly. >>> >>> I was able to verify last night that (cd /; tar -cpf -) > all.tar >>> would >>> trigger the problem. I'm working getting a test running with >>> David's ffs_sync() workaround now, adding a few counters there >>> should >>> get this narrowed down a little more. >> >> Unfortunately, the version of the patch that I sent out isn't >> going to >> help your problem. It needs to yield at the top of the loop, but >> vp isn't >> necessarily valid after the wakeup from the msleep. That's a >> problem that >> I'm having trouble figuring out a solution to - the solutions that >> come >> to mind will all significantly increase the overhead of the loop. >> As a very inadequate work-around, you might consider lowering >> kern.maxvnodes to something like 20000 - that might be low enough to >> not trigger the problem, but also be high enough to not significantly >> affect system I/O performance. > > I think the following may be safe. It counts only the clean scanned > vnodes > and does not evaluate the vp, that indeed may be reclaimed, after > the sleep. > > I never booted with the change. > > diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c > index cbccc62..e686b97 100644 > --- a/sys/ufs/ffs/ffs_vfsops.c > +++ b/sys/ufs/ffs/ffs_vfsops.c > @@ -1176,6 +1176,7 @@ ffs_sync(mp, waitfor, td) > struct ufsmount *ump = VFSTOUFS(mp); > struct fs *fs; > int error, count, wait, lockreq, allerror = 0; > + int yield_count; > int suspend; > int suspended; > int secondary_writes; > @@ -1216,6 +1217,7 @@ loop: > softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps); > MNT_ILOCK(mp); > > + yield_count = 0; > MNT_VNODE_FOREACH(vp, mp, mvp) { > /* > * Depend on the mntvnode_slock to keep things stable enough > @@ -1233,6 +1235,11 @@ loop: > (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && > vp->v_bufobj.bo_dirty.bv_cnt == 0)) { > VI_UNLOCK(vp); > + if (yield_count++ == 500) { > + yield_count = 0; > + msleep(&yield_count, MNT_MTX(mp), PZERO, > + "ffspause", 1); > + } > continue; > } > MNT_IUNLOCK(mp); From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 21:35:09 2007 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 9EAAD16A417 for ; Thu, 20 Dec 2007 21:35:09 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 53ECA13C448 for ; Thu, 20 Dec 2007 21:35:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J5SkE-00051J-4O for freebsd-stable@freebsd.org; Thu, 20 Dec 2007 21:15:54 +0000 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Dec 2007 21:15:54 +0000 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Dec 2007 21:15:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Joshua Coombs Date: Thu, 20 Dec 2007 15:57:05 -0500 Lines: 13 Message-ID: References: <200712201706.lBKH6fwn067680@lurza.secnetix.de> <476ABD93.3080707@brianwhalen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <476ABD93.3080707@brianwhalen.net> Sender: news Subject: Re: FreeBSD 7 on old SMP server? 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, 20 Dec 2007 21:35:09 -0000 Brian wrote: > Would that be a multiday buildworld? > > Brian 10 days on average. : ) I'm trying a 7 build without -pipe to see if I can squeak it through with 64MB RAM + 384MB swap, I'd much prefer not having to do a dump/restore to reallocate space for more swap. I'm almost thinking a non -pipe build may be quicker given the limited ram I have. Josh C From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 22:47:57 2007 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 EC31B16A417 for ; Thu, 20 Dec 2007 22:47:57 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 880C213C468 for ; Thu, 20 Dec 2007 22:47:57 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id lBKMIRga085827 for ; Thu, 20 Dec 2007 23:18:27 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id lBKMIP03041305 for ; Thu, 20 Dec 2007 23:18:25 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id lBKMIPTh041302; Thu, 20 Dec 2007 23:18:25 +0100 (MET) (envelope-from arno) To: stable@freebsd.org From: "Arno J. Klaassen" Date: 20 Dec 2007 23:18:25 +0100 Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.164]); Thu, 20 Dec 2007 23:18:27 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.7/5195/Thu Dec 20 20:25:28 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 476AEA33.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: Subject: more cpufreq woes 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, 20 Dec 2007 22:47:58 -0000 Hi, I once again have a freeze with cpufreq, this time on a Tyan S3950 MB + X2 BE 2400 proc; dev.cpu.0.freq_levels: 2277/100000 2178/91708 1980/76426 1782/62805 990/30193 Same proc works OK with Asus M2N32 WS Pro ... Same Tyan MB works OK with X2 BE 2350 which shows dev.cpu.0.freq_levels: 2079/100000 1980/91311 1782/75334 990/40013 With 'sysctl debug.cpufreq.lowest=1000' it works OK, but that's not really what I'd like to do. This is on RELENG_6. Best, Arno From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 23:56:20 2007 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 798DB16A419 for ; Thu, 20 Dec 2007 23:56:20 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0008B13C442 for ; Thu, 20 Dec 2007 23:56:19 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id lBKNuE2r091686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Dec 2007 00:56:17 +0100 (CET) (envelope-from h.schmalzbauer@omnisec.de) Message-ID: <476B0108.4000005@omnisec.de> Date: Fri, 21 Dec 2007 00:55:52 +0100 From: Harald Schmalzbauer Organization: OmniSEC User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30E09F8BD5156F573695DA55" Subject: ACPI STR (s3) makes machine behave very odd 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, 20 Dec 2007 23:56:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30E09F8BD5156F573695DA55 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, with Beta4 I tried 'acpiconf -s3'. The machine shut down but I couldn't wake it up with the keyboard. Pressing the power button makes the drives start up but the machine switches off two seconds later. This is done in an endless loop. I tried a kernel without any driver, just the absolut neccesarry like sc, no USB etc. Hardware is a ich9 board (Gigabyte p965-DS4) Here's some dmesg which looks suspicious: acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fde0000 (3) failed If someone can help diagnose the problem I can come up wtih the acpi tabl= es. Thanks in advance, STR is a really big "must have" these days taking incredable fast machines booting incredible slowly and consuming increadible much power while idling... -Harry --------------enig30E09F8BD5156F573695DA55 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHawEeLDqVQ9VXb8gRAjP+AJ9b+fho6dVzB9k8Tb+UCKdD6JxEXgCfSGs7 DXtU8XY+cFxZSEbql0rw+EY= =QiTY -----END PGP SIGNATURE----- --------------enig30E09F8BD5156F573695DA55-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 00:00:14 2007 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 DBC6416A417 for ; Fri, 21 Dec 2007 00:00:14 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 61A6C13C4D9 for ; Fri, 21 Dec 2007 00:00:14 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id lBL00DG5091776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Dec 2007 01:00:13 +0100 (CET) (envelope-from h.schmalzbauer@omnisec.de) Message-ID: <476B020D.1010901@omnisec.de> Date: Fri, 21 Dec 2007 01:00:13 +0100 From: Harald Schmalzbauer Organization: OmniSEC User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <476B0108.4000005@omnisec.de> In-Reply-To: <476B0108.4000005@omnisec.de> X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8FA863132BAED18D4415599C" Subject: Re: ACPI STR (s3) makes machine behave very odd 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, 21 Dec 2007 00:00:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FA863132BAED18D4415599C Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 21.12.2007 00:55 (localtime): > Hello, >=20 > with Beta4 I tried 'acpiconf -s3'. The machine shut down but I couldn't= > wake it up with the keyboard. > Pressing the power button makes the drives start up but the machine > switches off two seconds later. > This is done in an endless loop. >=20 > I tried a kernel without any driver, just the absolut neccesarry like > sc, no USB etc. Hardware is a ich9 board (Gigabyte p965-DS4) Hmm, nonsense, it's something like P35-DS4, sorry > Here's some dmesg which looks suspicious: > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 3fde0000 (3) failed >=20 > If someone can help diagnose the problem I can come up wtih the acpi ta= bles. >=20 > Thanks in advance, STR is a really big "must have" these days taking > incredable fast machines booting incredible slowly and consuming > increadible much power while idling... --------------enig8FA863132BAED18D4415599C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHawINLDqVQ9VXb8gRAvWEAKCjSr6OYcsEhreIBDkUtUV5J70sVgCgnRMP F4O2SaS88U+FCSfsUzMxYmI= =B75K -----END PGP SIGNATURE----- --------------enig8FA863132BAED18D4415599C-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 06:24:02 2007 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 49F6C16A468 for ; Fri, 21 Dec 2007 06:24:02 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 0270113C44B for ; Fri, 21 Dec 2007 06:24:01 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 27714 invoked from network); 21 Dec 2007 00:24:01 -0600 Received: from 124-170-40-102.dyn.iinet.net.au (HELO localhost) (124.170.40.102) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Dec 2007 00:24:01 -0600 Date: Fri, 21 Dec 2007 17:23:28 +1100 From: Norberto Meijome To: freebsd-stable@freebsd.org Message-ID: <20071221172328.5951c045@meijome.net> In-Reply-To: References: <476A5EE1.9000003@bulinfo.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Performance! 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, 21 Dec 2007 06:24:02 -0000 On Thu, 20 Dec 2007 15:35:52 +0100 "Claus Guttesen" wrote: > > What postgres-version did you use for this benchmark? Eventhough this > is a synthetic benchmark the difference in performance may indicate > some penalties on 8-core servers on FreeBSD. > > According to http://people.freebsd.org/~kris/scaling/mysql.html mysql > scale the same until until 8 clients on both Linux and FreeBSD. This > is an older test though and Linux has probably done some > optimizations. > > Could be interesting so see whether the results differ if you disable > one of the cpu's and rerun the tests. > I would try asking in the pgsql's performance mailing list , pgsql-performance@postgresql.org (u'll need to subscribe first). there was a bit of discussion on this subject recently on a somewhat unrelated thread ( http://archives.postgresql.org/pgsql-performance/2007-12/msg00276.php )... B _________________________ {Beto|Norberto|Numard} Meijome If you're not part of the solution, you're part of the precipitate. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 09:46:41 2007 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 5117E16A469 for ; Fri, 21 Dec 2007 09:46:41 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0E55313C442 for ; Fri, 21 Dec 2007 09:46:40 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 80D0F63937; Fri, 21 Dec 2007 11:46:38 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63136-02; Fri, 21 Dec 2007 11:46:36 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id C699F63900; Fri, 21 Dec 2007 11:46:36 +0200 (EET) Message-ID: <476B8B7A.1020008@bulinfo.net> Date: Fri, 21 Dec 2007 11:46:34 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Claus Guttesen References: <476A5EE1.9000003@bulinfo.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: FreeBSD Subject: Re: Performance! 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, 21 Dec 2007 09:46:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Claus Guttesen wrote: >> I have read all related threads about performance problems with multi >> core systems but still have no idea what to do to make thinks better. >> Below are results of testing postgresql on HP DL380G5 using sysbench. >> The results are comparable to: >> http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 >> but the same tests running on the same hardware using Linux (kernel >> 2.6.18-53.1.4.el5 SMP x86_64) are very different. >> PostgreSQL is tuned equal. >> >> results: >> FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE >> #threads #transactions/sec user/system >> 1 500 7.4%,5.3% >> 5 1990 30.9%,23.4% >> 10 2510 39.9%,35.0% >> 20 2549 44.5%,43.5% >> 40 1921 29.8%,59.4% >> 60 1580 22.7%,70.6% >> 80 1341 18.9%,75.9% >> 100 1227 16.5%,79.3% >> >> Linux >> #threads #transactions/sec >> 1 693 >> 5 3539 >> 10 5789 >> 20 5791 >> 40 5661 >> 60 5517 >> 80 5401 >> 100 5319 >> >> What can be done to improve these results? > > What postgres-version did you use for this benchmark? Eventhough this > is a synthetic benchmark the difference in performance may indicate > some penalties on 8-core servers on FreeBSD. 8.2.5 from ports > > According to http://people.freebsd.org/~kris/scaling/mysql.html mysql > scale the same until until 8 clients on both Linux and FreeBSD. This > is an older test though and Linux has probably done some > optimizations. > > Could be interesting so see whether the results differ if you disable > one of the cpu's and rerun the tests. > 2 cores: #threads #transactions/sec user/system 1 541 27.8%,19.0% 5 1068 57.1%,28.4% 40 1086 55.2%,32.1% 100 997 57.5%,28.9% 4 cores: #threads #transactions/sec user/system 1 512 12.3%,8.8% 5 1531 50.3%,31.5% 10 1651 51.6%,33.7% 40 1490 47.3%,37.8% 60 1320 44.0%,44.8% 100 1117 37.5%,51.8% -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHa4t6xJBWvpalMpkRAgKOAKCgZiNdHgL5zyIcrjKp9W8/2gW2JACfVcWz HdAOjT+DS6ysVohTUtNg9Fg= =pGDK -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 10:24:39 2007 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 4F2E216A41A for ; Fri, 21 Dec 2007 10:24:39 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id AF4EC13C448 for ; Fri, 21 Dec 2007 10:24:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id lBLAOMxs099606; Fri, 21 Dec 2007 11:24:29 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBLAOLIS099605; Fri, 21 Dec 2007 11:24:21 +0100 (CET) (envelope-from olli) Date: Fri, 21 Dec 2007 11:24:21 +0100 (CET) Message-Id: <200712211024.lBLAOLIS099605@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, bri@brianwhalen.net, jcoombs@gwi.net In-Reply-To: <476ABD93.3080707@brianwhalen.net> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 21 Dec 2007 11:24:30 +0100 (CET) Cc: Subject: Re: FreeBSD 7 on old SMP server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, bri@brianwhalen.net, jcoombs@gwi.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2007 10:24:39 -0000 Brian wrote: > Joshua Coombs wrote: > > For a very short while with 6.0 I was tweaking the kernel to detect > > 386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok > > luck. I've now got a Cyrix 486DrX-2 66 installed in place of my > > Am386DX-40, which supports CMPXCHG as well as ID'ing as a 486 so I > > don't need to do any tweaking to stay running. > > > > If I can get another viable 386DX box reassembled I'll see if 7 can be > > pressed into functioning on it as 6 could. > > Would that be a multiday buildworld? I would certainly be wise to perform the buildworld on a faster machine and only do the installworld on the slow one. ALternatively, install directly on the slow machines disk if you can plug it into the fast one temporarily. By the way, I don't think that omitting -pipe helps that much on a machine that is really low on memory. It only separates the preprocessor and assembly stages from the main compilation, but it is the main compilation which is the actual memory hog (at least with gcc 4.2) due to the code optimization. Of course, omitting -pipe might help a little, but don't hold your breath. It might help much better to reduce the optimization level from the default -O2 to -O1 (in addition to omitting -pipe). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 10:28:14 2007 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 A1B0A16A419 for ; Fri, 21 Dec 2007 10:28:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 102B313C467 for ; Fri, 21 Dec 2007 10:28:13 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id lBLAS7x7099675; Fri, 21 Dec 2007 11:28:12 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBLAS5T4099674; Fri, 21 Dec 2007 11:28:05 +0100 (CET) (envelope-from olli) Date: Fri, 21 Dec 2007 11:28:05 +0100 (CET) Message-Id: <200712211028.lBLAS5T4099674@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, 000.fbsd@quip.cz In-Reply-To: <476AC0D7.7090402@quip.cz> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 21 Dec 2007 11:28:13 +0100 (CET) Cc: Subject: Re: jlogin.sh - a small nice jails helper! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, 000.fbsd@quip.cz List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2007 10:28:14 -0000 Miroslav Lachman wrote: > Oliver Fromme wrote: > > if [ -z "$SHELL" -o ! -x "$jail_path/$SHELL" ]; then > > login_shell="$SHELL" > > else > > login_shell="/bin/sh" > > fi Ian Smith brought to my attention that I got the logic reversed in the if statement. He suggested to reverse (i.e. undo) the negation, which is much better. Thanks Ian! if [ -n "$SHELL" -a -x "$jail_path/$SHELL" ]; then login_shell="$SHELL" else login_shell="/bin/sh" fi > I am using your jps in slightly modified version ;) > [...] > echo "==============================" > echo " summary for JID $sum_jid / $jname" That seems to be useful indeed. I'll have a closer look and possibly integrate it back into my jps. Thanks! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd PI: int f[9814],b,c=9814,g,i;long a=1e4,d,e,h; main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a) while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;} From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 10:40:33 2007 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 3FDB116A419 for ; Fri, 21 Dec 2007 10:40:33 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id EA6E213C455 for ; Fri, 21 Dec 2007 10:40:32 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 555E26349B for ; Fri, 21 Dec 2007 12:40:31 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69676-03 for ; Fri, 21 Dec 2007 12:40:29 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id D6BC0624D5 for ; Fri, 21 Dec 2007 12:40:29 +0200 (EET) Message-ID: <476B981B.1010107@bulinfo.net> Date: Fri, 21 Dec 2007 12:40:27 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: FreeBSD References: <476A5EE1.9000003@bulinfo.net> In-Reply-To: <476A5EE1.9000003@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: Re: Performance! 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, 21 Dec 2007 10:40:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Krassimir Slavchev wrote: > Hello, > > I have read all related threads about performance problems with multi > core systems but still have no idea what to do to make thinks better. > Below are results of testing postgresql on HP DL380G5 using sysbench. > The results are comparable to: > http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 > but the same tests running on the same hardware using Linux (kernel > 2.6.18-53.1.4.el5 SMP x86_64) are very different. > PostgreSQL is tuned equal. > > dmesg: > ... > CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > > Features=0xbfebfbff > > Features2=0xce3bd> > AMD Features=0x20000800 > AMD Features2=0x1 > Cores per package: 4 > usable memory = 8575655936 (8178 MB) > avail memory = 8288337920 (7904 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > ... > > test: > sysbench --num-threads=${i} --test=oltp --pgsql-user=bench > --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0 > --oltp-read-only=on run > > tuning: > kern.ipc.shmmax=2147483647 > kern.ipc.shmall=524288 > kern.ipc.semmsl=512 > kern.ipc.semmap=256 > kern.ipc.somaxconn=2048 > kern.maxfiles=65536 > vfs.read_max=32 > > kern.ipc.semmni=256 > kern.ipc.semmns=2048 > > results: > FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE > #threads #transactions/sec user/system > 1 500 7.4%,5.3% > 5 1990 30.9%,23.4% > 10 2510 39.9%,35.0% > 20 2549 44.5%,43.5% > 40 1921 29.8%,59.4% > 60 1580 22.7%,70.6% > 80 1341 18.9%,75.9% > 100 1227 16.5%,79.3% With kern.hz=100 #threads #transactions/sec 1 553 5 2133 10 2168 20 2567 40 2279 60 1773 80 1529 100 1463 > > > What can be done to improve these results? > > Best Regards > _______________________________________________ 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHa5gaxJBWvpalMpkRAgjFAJ9Yqz7Yj6ee/z7FUQkDncRuetAwTwCfSBXY h66FOS97LRGr/VmAmdQcJKQ= =jEDa -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 12:53:56 2007 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 33A9316A417 for ; Fri, 21 Dec 2007 12:53:56 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id DB63913C4DB for ; Fri, 21 Dec 2007 12:53:55 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J5hNy-00035P-OT for freebsd-stable@FreeBSD.ORG; Fri, 21 Dec 2007 12:53:54 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J5hNy-00052v-MM for freebsd-stable@FreeBSD.ORG; Fri, 21 Dec 2007 12:53:54 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5hNy-0000Lt-Lp for freebsd-stable@FreeBSD.ORG; Fri, 21 Dec 2007 12:53:54 +0000 To: freebsd-stable@FreeBSD.ORG Message-Id: From: Pete French Date: Fri, 21 Dec 2007 12:53:54 +0000 Cc: Subject: odd zfs behaviour on reboot 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, 21 Dec 2007 12:53:56 -0000 was just experimenting with zfs on a spare slice on the disc - this may all be entirely my fault for doing it worng, if so please tell me, but I appear to be gettign a zfs pool ounted on reboot but with none of the data appearing in it! what I did: 1) take a space slice, only got one partition on it being 'c' the whole disc 2) glabeled it as 'zfstest' so it appears in /dev/label/zfstest 3) create a pool with 'zpool create tank /dev/label/zfstest 4) create another file system on it as 'zfs create tank/newfs' 5) sprinkle some files into both directories so thois gives me a /tank and a /tank/newfs, with some files in them (there was no /tank director previously). I can zpool export and zpool import the tank and it all works fine. so then I reboot ...and after reboot I get /tank, but it is empty! a 'zpool status' tells me that the pool is there and imported, but it doesnt show up when I type 'mount'. If I do an export and import then all the files appear again and the filesystem shows up in 'mount' though. any ideas ? it is obviosuly finding the pool, but not mounting any of the files systems from the looks of things. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 13:17:14 2007 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 78C0E16A417 for ; Fri, 21 Dec 2007 13:17:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id DFDC013C448 for ; Fri, 21 Dec 2007 13:17:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id A14BD74400C; Fri, 21 Dec 2007 15:17:11 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCewYfnfzwGq; Fri, 21 Dec 2007 15:17:11 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2238074400A; Fri, 21 Dec 2007 15:17:11 +0200 (EET) Message-ID: <476BBCD6.2070804@icyb.net.ua> Date: Fri, 21 Dec 2007 15:17:10 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jeremy Messenger Subject: reduce verboseness for certain scsi error 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, 21 Dec 2007 13:17:14 -0000 I would like to request your opinion on the following proposal: 1. introduce new scsi_sense_action_qualifier value SSQ_PRINT_SENSE_VERBOSE, which would mean that detailed command and response information is to be printed only if bootverbose==1; 2. introduce new define SS_FATAL_NORMAL with value of (SS_FAIL|SSQ_PRINT_SENSE_VERBOSE), which would mean a fatal SCSI error that can happen in "normal conditions", i.e. in the most cases the error doesn't imply a problem with a peripheral device, media, bus, controller, etc; 3. use the above SS_FATAL_NORMAL for at least the following conditions: (a)"Medium not present" (a)"Illegal mode for this track" (a) seems to be a common place for empty CD-ROM drive, empty card-reader, multi-slot card-readers with empty slots etc; (b) seems to be produced when certain pieces of software try to analyze media (distinguish data CD from audio CD, I think); 4. modify camperiphscsisenseerror() to honor the new flag defined above; Rationale for this request is that kernel messages easily get spammed with the error reports which do not really mean error conditions. Some amount of such noise comes from the kernel-land actions, lots more can come from user-land programs unwittingly trying to do certain things on the devices with no media or wrong media (example: hald). P.S. couple of links describing end-user experience (mine included): http://lists.freebsd.org/pipermail/freebsd-gnome/2007-January/016544.html http://forums.pcbsd.org/viewtopic.php?f=7&t=7044 http://lists.freebsd.org/pipermail/freebsd-gnome/2007-December/018816.html P.P.S. I am not saying that the issue is a kernel problem and must be resolved in kernel. It would be nice to see hald becoming a little bit smarter too. But I think that the above change would be nice and proper regardless of hald. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 13:34:36 2007 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 51C5616A417 for ; Fri, 21 Dec 2007 13:34:36 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0561613C468 for ; Fri, 21 Dec 2007 13:34:36 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J5i1L-0003Py-8r for freebsd-stable@FreeBSD.ORG; Fri, 21 Dec 2007 13:34:35 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J5i1L-0005C3-6X; Fri, 21 Dec 2007 13:34:35 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5i1L-0000M0-4H; Fri, 21 Dec 2007 13:34:35 +0000 To: freebsd-stable@FreeBSD.ORG, petefrench@ticketswitch.com In-Reply-To: Message-Id: From: Pete French Date: Fri, 21 Dec 2007 13:34:35 +0000 Cc: Subject: Re: odd zfs behaviour on reboot 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, 21 Dec 2007 13:34:36 -0000 O.K., even odder - it seems that something is creating a real '/tank' directory in '/' for some reaosn, but not mounting the filesystems onto it. when I reboot I get this: # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 label/zfstest ONLINE 0 0 0 errors: No known data errors # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 134K 29.3G 21.5K /tank tank/newfs 18.5K 29.3G 18.5K /tank/newfs but nothing is actually mouunted. a quick 'zpool export tank' followed by a 'zpool import tank' fixes this, but surely it should either mount them at boot or not ,ount them at boot ? saying they are mounted when they actuall arent seems wrong... -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 13:55:04 2007 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 879AC16A46B for ; Fri, 21 Dec 2007 13:55:04 +0000 (UTC) (envelope-from peter.thoenen@yahoo.com) Received: from smtp101.plus.mail.re1.yahoo.com (smtp101.plus.mail.re1.yahoo.com [69.147.102.64]) by mx1.freebsd.org (Postfix) with SMTP id 0BBFC13C4D5 for ; Fri, 21 Dec 2007 13:55:03 +0000 (UTC) (envelope-from peter.thoenen@yahoo.com) Received: (qmail 41640 invoked from network); 21 Dec 2007 13:55:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QZO1JGxuBmJkbzrSPk462Qzn5MyCw1+6fJ/e3anvX5SOtjQE6So1RdM1FteS8SWlushucVCGIdjW3rpVBPyiijQJVpTFL7AcJmRk/rPM83pMZRkdpVOcXp3EXb0HAknoQJ0I3+48ZNfk2jRMFaOkOVUEofxJbeuR6HIAVj4iWaY= ; Received: from unknown (HELO ssfbsd.securestate.org) (eol1@70.227.5.28 with plain) by smtp101.plus.mail.re1.yahoo.com with SMTP; 21 Dec 2007 13:55:02 -0000 X-YMail-OSG: 3A0RlLsVM1l.8kXKq.90zBXh7ktDoiNFBC2dGuyGsWlkr0bXpUUHZh08WRbLijgpC07fjkUSbA-- Message-ID: <476BC5B1.3050208@yahoo.com> Date: Fri, 21 Dec 2007 08:54:57 -0500 From: Peter Thoenen User-Agent: Thunderbird 2.0.0.9 (X11/20071210) MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: Re: odd zfs behaviour on reboot 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, 21 Dec 2007 13:55:04 -0000 heh I had the same prob a couple days back. Check the archives last week, 10DEC07 "Re: Various Issues with 7.0-BETA4" Step by step directions on how to fix From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 14:19:21 2007 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 6BCF716A418 for ; Fri, 21 Dec 2007 14:19:21 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCA613C46A for ; Fri, 21 Dec 2007 14:19:21 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from smaug.rattatosk ([10.50.50.2]) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J5iic-0003hv-7t; Fri, 21 Dec 2007 14:19:18 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1J5iic-0005UK-5q; Fri, 21 Dec 2007 14:19:18 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5iia-0000Iw-BU; Fri, 21 Dec 2007 14:19:16 +0000 To: peter.thoenen@yahoo.com In-Reply-To: <476BC5B1.3050208@yahoo.com> Message-Id: From: Pete French Date: Fri, 21 Dec 2007 14:19:16 +0000 Cc: freebsd-stable@FreeBSD.ORG Subject: Re: odd zfs behaviour on reboot 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, 21 Dec 2007 14:19:21 -0000 > heh I had the same prob a couple days back. Check the archives last > week, 10DEC07 "Re: Various Issues with 7.0-BETA4" actually, it wsa that thread which motivated me to experiment ... and I was thinking all along "must remember to add zfs to loader.conf to avoid that". Of course I then forgot to add zfs_enable to rc.conf! doh... sorry for the noise, and thanks for the pointer - works fine now. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 18:01:22 2007 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 A386016A419 for ; Fri, 21 Dec 2007 18:01:22 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6407713C442 for ; Fri, 21 Dec 2007 18:01:22 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so683547waf.3 for ; Fri, 21 Dec 2007 10:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Scux7xz1gbqa90Tr1yhcR4lbz1nIAUNN9zsOvx3sXA4=; b=oaUEFF+ZpceN2v2iQSUkAoYV8O1LqQIaLN9CXOb8WNXKc70riR+MacSJV4yMJRUCIKYjeM158K7igGAQVJ1S3CFEs92zL0x7CXSCptAr4Cw6zYJuwJwtF+zxjLDyrvDkn2xPGNid3b7hIoCTgF+wW4qt10qh1hPO1UhUDX08q3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SzSJ7vLzsmNiAOWfCLZJNZVEIYYrH4G1t+Wb+Gw/DGem+0PTdNYNPFujKiGLsPrTzuPnSCBNH8+YWK5MB7R2enRcCoOHaX5rgB20dXw4xkmjfMumMi/c8FC+JGk7htdIfTKl8yyOjN6+3FoYi0aSp2JfXoFrjEkZvMFTlfh1Po4= Received: by 10.115.74.1 with SMTP id b1mr497190wal.93.1198260081563; Fri, 21 Dec 2007 10:01:21 -0800 (PST) Received: by 10.114.255.11 with HTTP; Fri, 21 Dec 2007 10:01:21 -0800 (PST) Message-ID: Date: Fri, 21 Dec 2007 10:01:21 -0800 From: "Kip Macy" To: "Krassimir Slavchev" , FreeBSD In-Reply-To: <476A5EE1.9000003@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <476A5EE1.9000003@bulinfo.net> Cc: Subject: Re: Performance! 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, 21 Dec 2007 18:01:22 -0000 Are you sure that the settitle call is disabled on FreeBSD? On 12/20/07, Krassimir Slavchev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I have read all related threads about performance problems with multi > core systems but still have no idea what to do to make thinks better. > Below are results of testing postgresql on HP DL380G5 using sysbench. > The results are comparable to: > http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 > but the same tests running on the same hardware using Linux (kernel > 2.6.18-53.1.4.el5 SMP x86_64) are very different. > PostgreSQL is tuned equal. > > dmesg: > ... > CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > > Features=0xbfebfbff > > Features2=0xce3bd> > AMD Features=0x20000800 > AMD Features2=0x1 > Cores per package: 4 > usable memory = 8575655936 (8178 MB) > avail memory = 8288337920 (7904 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > ... > > test: > sysbench --num-threads=${i} --test=oltp --pgsql-user=bench > - --pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0 > - --oltp-read-only=on run > > tuning: > kern.ipc.shmmax=2147483647 > kern.ipc.shmall=524288 > kern.ipc.semmsl=512 > kern.ipc.semmap=256 > kern.ipc.somaxconn=2048 > kern.maxfiles=65536 > vfs.read_max=32 > > kern.ipc.semmni=256 > kern.ipc.semmns=2048 > > results: > FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE > #threads #transactions/sec user/system > 1 500 7.4%,5.3% > 5 1990 30.9%,23.4% > 10 2510 39.9%,35.0% > 20 2549 44.5%,43.5% > 40 1921 29.8%,59.4% > 60 1580 22.7%,70.6% > 80 1341 18.9%,75.9% > 100 1227 16.5%,79.3% > > Linux > #threads #transactions/sec > 1 693 > 5 3539 > 10 5789 > 20 5791 > 40 5661 > 60 5517 > 80 5401 > 100 5319 > > > What can be done to improve these results? > > Best Regards > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFHal7hxJBWvpalMpkRAsaiAJ9G3ZoTv6cUbR4yix07TEMf7PKm7gCgoroM > +xvcXkcaFjSTxYfjk5rqMko= > =Tpsq > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 20:09:38 2007 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 B20BB16A417; Fri, 21 Dec 2007 20:09:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8989F13C461; Fri, 21 Dec 2007 20:09:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CD0981A4D7C; Fri, 21 Dec 2007 12:08:10 -0800 (PST) Date: Fri, 21 Dec 2007 12:08:10 -0800 From: Alfred Perlstein To: David G Lawrence Message-ID: <20071221200810.GY16982@elvis.mu.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219171331.GH25053@tnn.dglawrence.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 21 Dec 2007 20:09:38 -0000 * David G Lawrence [071219 09:12] wrote: > > >Try it with "find / -type f >/dev/null" to duplicate the problem > > >almost > > >instantly. > > > > I was able to verify last night that (cd /; tar -cpf -) > all.tar would > > trigger the problem. I'm working getting a test running with > > David's ffs_sync() workaround now, adding a few counters there should > > get this narrowed down a little more. > > Unfortunately, the version of the patch that I sent out isn't going to > help your problem. It needs to yield at the top of the loop, but vp isn't > necessarily valid after the wakeup from the msleep. That's a problem that > I'm having trouble figuring out a solution to - the solutions that come > to mind will all significantly increase the overhead of the loop. > As a very inadequate work-around, you might consider lowering > kern.maxvnodes to something like 20000 - that might be low enough to > not trigger the problem, but also be high enough to not significantly > affect system I/O performance. I apologize for not reading the code as I am swamped, but a technique that Matt Dillon used for bufs might work here. Can you use a placeholder vnode as a place to restart the scan? you might have to mark it special so that other threads/things (getnewvnode()?) don't molest it, but it can provide for a convenient restart point. -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Fri Dec 21 23:43:48 2007 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 DCF5A16A418; Fri, 21 Dec 2007 23:43:48 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBA413C4FB; Fri, 21 Dec 2007 23:43:48 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBLNhlEH044230; Fri, 21 Dec 2007 15:43:47 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBLNhlZD044229; Fri, 21 Dec 2007 15:43:47 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Fri, 21 Dec 2007 15:43:47 -0800 From: David G Lawrence To: Alfred Perlstein Message-ID: <20071221234347.GS25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071221200810.GY16982@elvis.mu.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Fri, 21 Dec 2007 15:43:47 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 21 Dec 2007 23:43:49 -0000 > > Unfortunately, the version of the patch that I sent out isn't going to > > help your problem. It needs to yield at the top of the loop, but vp isn't > > necessarily valid after the wakeup from the msleep. That's a problem that > > I'm having trouble figuring out a solution to - the solutions that come > > to mind will all significantly increase the overhead of the loop. > > I apologize for not reading the code as I am swamped, but a technique > that Matt Dillon used for bufs might work here. > > Can you use a placeholder vnode as a place to restart the scan? > you might have to mark it special so that other threads/things > (getnewvnode()?) don't molest it, but it can provide for a convenient > restart point. That was one of the solutions that I considered and rejected since it would significantly increase the overhead of the loop. The solution provided by Kostik Belousov that uses uio_yield looks like a find solution. I intend to try it out on some servers RSN. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 00:26:00 2007 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 BA67B16A417; Sat, 22 Dec 2007 00:26:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 91BA213C45D; Sat, 22 Dec 2007 00:26:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1AE051A4D7C; Fri, 21 Dec 2007 16:24:32 -0800 (PST) Date: Fri, 21 Dec 2007 16:24:32 -0800 From: Alfred Perlstein To: David G Lawrence Message-ID: <20071222002432.GK16982@elvis.mu.org> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071221234347.GS25053@tnn.dglawrence.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 00:26:00 -0000 * David G Lawrence [071221 15:42] wrote: > > > Unfortunately, the version of the patch that I sent out isn't going to > > > help your problem. It needs to yield at the top of the loop, but vp isn't > > > necessarily valid after the wakeup from the msleep. That's a problem that > > > I'm having trouble figuring out a solution to - the solutions that come > > > to mind will all significantly increase the overhead of the loop. > > > > I apologize for not reading the code as I am swamped, but a technique > > that Matt Dillon used for bufs might work here. > > > > Can you use a placeholder vnode as a place to restart the scan? > > you might have to mark it special so that other threads/things > > (getnewvnode()?) don't molest it, but it can provide for a convenient > > restart point. > > That was one of the solutions that I considered and rejected since it > would significantly increase the overhead of the loop. > The solution provided by Kostik Belousov that uses uio_yield looks like > a find solution. I intend to try it out on some servers RSN. Out of curiosity's sake, why would it make the loop slower? one would only add the placeholder when yielding, not for every iteration. -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 01:54:14 2007 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 CAD9116A41B; Sat, 22 Dec 2007 01:54:14 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from mail1.webmaster.com (mail1.webmaster.com [216.152.64.169]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE9B13C44B; Sat, 22 Dec 2007 01:54:14 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from however by webmaster.com (MDaemon.PRO.v8.1.3.R) with ESMTP id md50001820320.msg; Fri, 21 Dec 2007 17:44:30 -0800 From: "David Schwartz" To: "Freebsd-Net@Freebsd. Org" Date: Fri, 21 Dec 2007 17:43:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20071221234347.GS25053@tnn.dglawrence.com> X-Authenticated-Sender: joelkatz@webmaster.com X-Spam-Processed: mail1.webmaster.com, Fri, 21 Dec 2007 17:44:30 -0800 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 206.171.168.138 X-Return-Path: davids@webmaster.com X-MDAV-Processed: mail1.webmaster.com, Fri, 21 Dec 2007 17:44:32 -0800 Cc: freebsd-stable@freebsd.org Subject: RE: Packet loss every 30.999 seconds X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davids@webmaster.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2007 01:54:14 -0000 I'm just an observer, and I may be confused, but it seems to me that this is motion in the wrong direction (at least, it's not going to fix the actual problem). As I understand the problem, once you reach a certain point, the system slows down *every* 30.999 seconds. Now, it's possible for the code to cause one slowdown as it cleans up, but why does it need to clean up so much 31 seconds later? Why not find/fix the actual bug? Then work on getting the yield right if it turns out there's an actual problem for it to fix. If the problem is that too much work is being done at a stretch and it turns out this is because work is being done erroneously or needlessly, fixing that should solve the whole problem. Doing the work that doesn't need to be done more slowly is at best an ugly workaround. Or am I misunderstanding? DS From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 03:31:10 2007 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 E481B16A421 for ; Sat, 22 Dec 2007 03:31:10 +0000 (UTC) (envelope-from maf@splintered.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 7F85F13C4D3 for ; Sat, 22 Dec 2007 03:31:10 +0000 (UTC) (envelope-from maf@splintered.net) Received: (qmail 59559 invoked from network); 22 Dec 2007 03:31:09 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 22 Dec 2007 03:31:09 -0000 In-Reply-To: <20071221234347.GS25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Fri, 21 Dec 2007 22:30:51 -0500 To: David G Lawrence X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, Alfred Perlstein , freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 03:31:11 -0000 The uio_yield() idea did not work. Still have the same 31 second interval packet loss. Is it safe to assume the vp will be valid after a msleep() or uio_yield()? If so can we do something a little different: Currently: /* this takes too long when list is large */ MNT_VNODE_FOREACH(vp, mp, mvp) { do work } Why not do this incrementally and call ffs_sync() more often, or break it out into ffs_isync() (incremental sync). static struct vnode *vp; /* first? */ if (!vp) vp = __mnt_vnode_first(&mvp, mp); for (vcount = 0; vp && (vcount != 500); ++vcount) { do work vp = __mnt_vnode_next(&mvp, mp); } The problem I see with this is a race condition where this list may change between the incremental calls. -- mark On Dec 21, 2007, at 6:43 PM, David G Lawrence wrote: >>> Unfortunately, the version of the patch that I sent out isn't >>> going to >>> help your problem. It needs to yield at the top of the loop, but >>> vp isn't >>> necessarily valid after the wakeup from the msleep. That's a >>> problem that >>> I'm having trouble figuring out a solution to - the solutions >>> that come >>> to mind will all significantly increase the overhead of the loop. >> >> I apologize for not reading the code as I am swamped, but a technique >> that Matt Dillon used for bufs might work here. >> >> Can you use a placeholder vnode as a place to restart the scan? >> you might have to mark it special so that other threads/things >> (getnewvnode()?) don't molest it, but it can provide for a convenient >> restart point. > > That was one of the solutions that I considered and rejected > since it > would significantly increase the overhead of the loop. > The solution provided by Kostik Belousov that uses uio_yield > looks like > a find solution. I intend to try it out on some servers RSN. > > -DG > > David G. Lawrence > President > Download Technologies, Inc. - http://www.downloadtech.com - (866) > 399 8500 > The FreeBSD Project - http://www.freebsd.org > Pave the road of life with opportunities. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 05:07:58 2007 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 7182916A417; Sat, 22 Dec 2007 05:07:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 1354213C448; Sat, 22 Dec 2007 05:07:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J5waY-000KaF-Ky; Sat, 22 Dec 2007 07:07:57 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBM57hHT070611; Sat, 22 Dec 2007 07:07:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBM57hwm070610; Sat, 22 Dec 2007 07:07:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2007 07:07:43 +0200 From: Kostik Belousov To: David Schwartz Message-ID: <20071222050743.GP57756@deviant.kiev.zoral.com.ua> References: <20071221234347.GS25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRkqPRiqIDKgfg/F" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 1118cf21f7425d415ed61e91afc5cb63 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1938 [Dec 21 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: "Freebsd-Net@Freebsd. Org" , freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 05:07:58 -0000 --TRkqPRiqIDKgfg/F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 21, 2007 at 05:43:09PM -0800, David Schwartz wrote: >=20 >=20 > I'm just an observer, and I may be confused, but it seems to me that this= is > motion in the wrong direction (at least, it's not going to fix the actual > problem). As I understand the problem, once you reach a certain point, the > system slows down *every* 30.999 seconds. Now, it's possible for the code= to > cause one slowdown as it cleans up, but why does it need to clean up so m= uch > 31 seconds later? >=20 > Why not find/fix the actual bug? Then work on getting the yield right if = it > turns out there's an actual problem for it to fix. >=20 > If the problem is that too much work is being done at a stretch and it tu= rns > out this is because work is being done erroneously or needlessly, fixing > that should solve the whole problem. Doing the work that doesn't need to = be > done more slowly is at best an ugly workaround. >=20 > Or am I misunderstanding? Yes, rewriting the syncer is the right solution. It probably cannot be done quickly enough. If the yield workaround provide mitigation for now, it shall go in. --TRkqPRiqIDKgfg/F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHbJueC3+MBN1Mb4gRAvPyAJ9Zp0lEBJmQvkFNRhu2hq/ABVh4qACfc8C0 K4g5W+0PuhHCJNCG9GrUwpw= =Hb5f -----END PGP SIGNATURE----- --TRkqPRiqIDKgfg/F-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 05:11:33 2007 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 CF08916A419; Sat, 22 Dec 2007 05:11:33 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1D313C45B; Sat, 22 Dec 2007 05:11:33 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.1/8.14.1) with ESMTP id lBM4fiJ4064588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Dec 2007 23:41:44 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.14.1/8.14.1/Submit) id lBM4fiT1064587; Fri, 21 Dec 2007 23:41:44 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: stable@FreeBSD.org Date: Fri, 21 Dec 2007 23:41:43 -0500 User-Agent: KMail/1.9.7 X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: freebsd-usb@FreeBSD.org Subject: usb/umass, devfs: this sucks 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, 22 Dec 2007 05:11:33 -0000 Another attempt to use USB-storage with FreeBSD, another moment of hair-pulling frustration. I attach the card-reader with the media card already inserted (detection of card-insertion has not worked in a long time, if ever). The "disk" appears: umass1: Genesys USB Reader, rev 2.00/91.38, addr 3 da6 at umass-sim1 bus 1 target 0 lun 0 da6: Removable Direct Access SCSI-0 device da6: 40.000MB/s transfers da6: 1938MB (3970048 512 byte sectors: 255H 63S/T 247C) (da6:umass-sim1:1:0:0): AutoSense Failed But the "slices" (/dev/da6s1, etc.) don't appear: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/76461 In the past, trying to mount, or otherwise read the da6 would result in the slices appearing -- an awful wart, when it works. So I try it, but it does not work: root@aldan:/home/mi (116) mount -tmsdosfs /dev/da6 /mnt ... hang ... Pressing Ctrl-T: load: 0.58 cmd: mount_msdosfs 64452 [GEOM topology] 0.00u 0.00s 0% 804k ... load: 0.47 cmd: mount_msdosfs 64452 [GEOM topology] 0.00u 0.00s 0% 804k It still hangs, and now other things hang too. top, for example, hangs on start-up: mi@aldan:~ (1084) top ... hang ... Pressing Ctrl-T: load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k No new window can be opened either -- presumably due to devfs hanging. I suspect, that anything attempting to use even the /dev/null is hanging now. So, not only the USB itself is broken, our wonderful devfs is rather creaky too -- nothing should be in an uninterruptible state like this for more than a millisecond. 25 minutes later the mount finally gave up: umass1: BBB reset failed, TIMEOUT umass1: BBB bulk-in clear stall failed, TIMEOUT umass1: BBB bulk-out clear stall failed, TIMEOUT mount_msdosfs: /dev/da6: Input/output error Things are back to "normal" again, but the media card is still inaccessible. I'll try to work with it using mtools -- I had some success in the pass accessing the FAT-filesystem on the media cards using mcopy, mdir, etc. I'm using 6.3-PRERELEASE as of Dec 6th, but a search for umass-related bugs http://www.freebsd.org/cgi/query-pr-summary.cgi?text=umass reveals plenty of really old problems, which don't even have a single follow-up from FreeBSD-developers. Like: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/95037 http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/95173 http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/107848 Looks like USB is unmaintained and getting worse. Are we really shipping this as "the most recent stable release"? -mi From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 05:37:00 2007 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 A469716A419; Sat, 22 Dec 2007 05:37:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 4340813C457; Sat, 22 Dec 2007 05:37:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J5x2a-000Pvz-KS; Sat, 22 Dec 2007 07:36:59 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBM5anNG082478; Sat, 22 Dec 2007 07:36:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBM5amIA082477; Sat, 22 Dec 2007 07:36:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2007 07:36:48 +0200 From: Kostik Belousov To: Mark Fullmer Message-ID: <20071222053648.GQ57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ubuMVesmirrCclZT" Content-Disposition: inline In-Reply-To: <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: b22dd54e5e410b0526d530b08df0ebb5 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1938 [Dec 21 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org, Alfred Perlstein , freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 05:37:00 -0000 --ubuMVesmirrCclZT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote: > The uio_yield() idea did not work. Still have the same 31 second =20 > interval packet loss. What patch you have used ? Lets check whether the syncer is the culprit for you. Please, change the value of the syncdelay at the sys/kern/vfs_subr.c around the line 238 from 30 to some other value, e.g., 45. After that, check the interval of the effect you have observed. It would be interesting to check whether completely disabling the syncer eliminates the packet loss, but such system have to be operated with extreme caution. >=20 > Is it safe to assume the vp will be valid after a msleep() or =20 > uio_yield()? If No. --ubuMVesmirrCclZT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHbKJvC3+MBN1Mb4gRAnz/AKDTPhR99Hw1sOHoYcE66Zq2MNZe5ACeMB/H BzkSI7Ud0ro/w6gCAAvxSpY= =XQ4k -----END PGP SIGNATURE----- --ubuMVesmirrCclZT-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 05:37:40 2007 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 1996D16A419; Sat, 22 Dec 2007 05:37:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9F86413C43E; Sat, 22 Dec 2007 05:37:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J5x3I-00003U-CG; Sat, 22 Dec 2007 07:37:38 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBM5bXmS082494; Sat, 22 Dec 2007 07:37:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBM5bW0G082493; Sat, 22 Dec 2007 07:37:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2007 07:37:32 +0200 From: Kostik Belousov To: Alfred Perlstein Message-ID: <20071222053732.GR57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <20071222002432.GK16982@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="soWJpSPh+l8Y6Fy7" Content-Disposition: inline In-Reply-To: <20071222002432.GK16982@elvis.mu.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: f2683d8df775da069012ccac6e6e6321 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1938 [Dec 21 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 05:37:40 -0000 --soWJpSPh+l8Y6Fy7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 21, 2007 at 04:24:32PM -0800, Alfred Perlstein wrote: > * David G Lawrence [071221 15:42] wrote: > > > > Unfortunately, the version of the patch that I sent out isn't go= ing to > > > > help your problem. It needs to yield at the top of the loop, but vp= isn't > > > > necessarily valid after the wakeup from the msleep. That's a proble= m that > > > > I'm having trouble figuring out a solution to - the solutions that = come > > > > to mind will all significantly increase the overhead of the loop. > > >=20 > > > I apologize for not reading the code as I am swamped, but a technique > > > that Matt Dillon used for bufs might work here. > > >=20 > > > Can you use a placeholder vnode as a place to restart the scan? > > > you might have to mark it special so that other threads/things > > > (getnewvnode()?) don't molest it, but it can provide for a convenient > > > restart point. > >=20 > > That was one of the solutions that I considered and rejected since it > > would significantly increase the overhead of the loop. > > The solution provided by Kostik Belousov that uses uio_yield looks l= ike > > a find solution. I intend to try it out on some servers RSN. >=20 > Out of curiosity's sake, why would it make the loop slower? one > would only add the placeholder when yielding, not for every iteration. Marker is already reinserted into the list on every iteration. --soWJpSPh+l8Y6Fy7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHbKKcC3+MBN1Mb4gRAoT1AKCBmHGiMjE36UzMRadhMvV4puYuSwCfQby3 vGqKmgClkrEd3/x3ytBSUao= =HhMC -----END PGP SIGNATURE----- --soWJpSPh+l8Y6Fy7-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 06:01:29 2007 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 10ECE16A417 for ; Sat, 22 Dec 2007 06:01:29 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id A377813C457 for ; Sat, 22 Dec 2007 06:01:28 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id WAA09277 for ; Fri, 21 Dec 2007 22:31:25 -0700 (MST) Message-Id: <200712220531.WAA09277@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Dec 2007 22:31:24 -0700 To: stable@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 06:01:29 -0000 I will need to build several Web caches over the next few months, and just took advantage of the Christmas lull (and a snowy day, when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how it will perform at this task. I built up a 4 core FreeBSD box, and asked a friend who's a Linux fanatic to do the same with Linux on identical hardware. I didn't watch closely how he installed everything, but asked him not to tune it beyond setting it up properly for SMP. We then ran a test suite in which a client starts several processes. Each uses wget to fetch a series of objects in rapid succession via the cache. The fetches done by each process are the same batch of URLS, but shuffled differently, so each URL will get a miss the first time and then hits each time it comes up thereafter unless the cache overflows. We're doing all GETs, with no tricky stuff like subranges. As has been reported in some other messages on this list, Linux is currently blowing FreeBSD away. It's taking as much as 20% less time to get through the benchmark, depending on exactly how the random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. It appears, though I'd need to instrument the code more to be sure, that the slowdown is coming from file I/O. Could it be that there less concurrency or more overhead in FreeBSD file operations than there is in Linux? Even with SoftUpdates turned on, the cache volume mounted with -noatime, and aufs (which uses kqueues -- a FreeBSD invention -- to optimize multithreaded disk access), the benchmark shows FreeBSD losing out. Why? --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 06:28:49 2007 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 F299C16A417 for ; Sat, 22 Dec 2007 06:28:49 +0000 (UTC) (envelope-from maf@splintered.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id B5F2C13C4F3 for ; Sat, 22 Dec 2007 06:28:49 +0000 (UTC) (envelope-from maf@splintered.net) Received: (qmail 82942 invoked from network); 22 Dec 2007 06:28:49 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 22 Dec 2007 06:28:49 -0000 In-Reply-To: <20071222053648.GQ57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> <20071222053648.GQ57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3647BB78-BA10-432B-A52B-04E402E155CC@splintered.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Sat, 22 Dec 2007 01:28:31 -0500 To: Kostik Belousov X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 06:28:50 -0000 On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote: > On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote: >> The uio_yield() idea did not work. Still have the same 31 second >> interval packet loss. > What patch you have used ? This is hand applied from the diff you sent December 19, 2007 1:24:48 PM EST sr1400-ar0.eng:/usr/src/sys/ufs/ffs# diff -c ffs_vfsops.c ffs_vfsops.c.orig *** ffs_vfsops.c Fri Dec 21 21:08:39 2007 --- ffs_vfsops.c.orig Sat Dec 22 00:51:22 2007 *************** *** 1107,1113 **** struct ufsmount *ump = VFSTOUFS(mp); struct fs *fs; int error, count, wait, lockreq, allerror = 0; - int yield_count; int suspend; int suspended; int secondary_writes; --- 1107,1112 ---- *************** *** 1148,1154 **** softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps); MNT_ILOCK(mp); - yield_count = 0; MNT_VNODE_FOREACH(vp, mp, mvp) { /* * Depend on the mntvnode_slock to keep things stable enough --- 1147,1152 ---- *************** *** 1166,1177 **** (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && vp->v_bufobj.bo_dirty.bv_cnt == 0)) { VI_UNLOCK(vp); - if (yield_count++ == 100) { - MNT_IUNLOCK(mp); - yield_count = 0; - uio_yield(); - goto relock_mp; - } continue; } MNT_IUNLOCK(mp); --- 1164,1169 ---- *************** *** 1186,1192 **** if ((error = ffs_syncvnode(vp, waitfor)) != 0) allerror = error; vput(vp); - relock_mp: MNT_ILOCK(mp); } MNT_IUNLOCK(mp); --- 1178,1183 ---- > > Lets check whether the syncer is the culprit for you. > Please, change the value of the syncdelay at the sys/kern/vfs_subr.c > around the line 238 from 30 to some other value, e.g., 45. After that, > check the interval of the effect you have observed. Changed it to 13. Not sure if SYNCER_MAXDELAY also needed to be increased if syncdelay was increased. static int syncdelay = 13; /* max time to delay syncing data */ Test: ; use vnodes % find / -type f -print > /dev/null ; verify % sysctl vfs.numvnodes vfs.numvnodes: 32128 ; run packet loss test now have periodic loss every 13994633us (13.99 seconds). ; reduce # of vnodes with sysctl kern.maxvnodes=1000 test now runs clean. > > It would be interesting to check whether completely disabling the > syncer > eliminates the packet loss, but such system have to be operated with > extreme caution. > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 06:50:30 2007 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 BDC5F16A469; Sat, 22 Dec 2007 06:50:30 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 933C413C4D5; Sat, 22 Dec 2007 06:50:30 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBM6oURH017372; Fri, 21 Dec 2007 22:50:30 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBM6oTKL017371; Fri, 21 Dec 2007 22:50:29 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Fri, 21 Dec 2007 22:50:29 -0800 From: David G Lawrence To: Mark Fullmer Message-ID: <20071222065029.GT25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> <20071222053648.GQ57756@deviant.kiev.zoral.com.ua> <3647BB78-BA10-432B-A52B-04E402E155CC@splintered.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3647BB78-BA10-432B-A52B-04E402E155CC@splintered.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Fri, 21 Dec 2007 22:50:30 -0800 (PST) Cc: Kostik Belousov , freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 06:50:30 -0000 > >What patch you have used ? > > This is hand applied from the diff you sent December 19, 2007 1:24:48 > PM EST Mark, try the previos patch from Kostik - the one that does the one tick msleep. I think you'll find that that one does work. The likely problem with the second version is that uio_yield doesn't lower the priority enough for the other threads to run. Forcing it to msleep for a tick will eliminate the priority from the consideration. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 07:03:27 2007 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 E4AA816A41B; Sat, 22 Dec 2007 07:03:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 7B65F13C461; Sat, 22 Dec 2007 07:03:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J5yOH-000HOX-D6; Sat, 22 Dec 2007 09:03:26 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBM73IMb030376; Sat, 22 Dec 2007 09:03:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBM73IJ3030375; Sat, 22 Dec 2007 09:03:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2007 09:03:18 +0200 From: Kostik Belousov To: Mark Fullmer Message-ID: <20071222070318.GT57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> <20071222053648.GQ57756@deviant.kiev.zoral.com.ua> <3647BB78-BA10-432B-A52B-04E402E155CC@splintered.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N7HXVILz59yg1nI8" Content-Disposition: inline In-Reply-To: <3647BB78-BA10-432B-A52B-04E402E155CC@splintered.net> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: ebef06da57613c13a9510a9a5e517e93 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1938 [Dec 21 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 07:03:28 -0000 --N7HXVILz59yg1nI8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 22, 2007 at 01:28:31AM -0500, Mark Fullmer wrote: >=20 > On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote: > >Lets check whether the syncer is the culprit for you. > >Please, change the value of the syncdelay at the sys/kern/vfs_subr.c > >around the line 238 from 30 to some other value, e.g., 45. After that, > >check the interval of the effect you have observed. >=20 > Changed it to 13. Not sure if SYNCER_MAXDELAY also needed to be > increased if syncdelay was increased. >=20 > static int syncdelay =3D 13; /* max time to delay syncing = =20 > data */ >=20 > Test: >=20 > ; use vnodes > % find / -type f -print > /dev/null >=20 > ; verify > % sysctl vfs.numvnodes > vfs.numvnodes: 32128 >=20 > ; run packet loss test > now have periodic loss every 13994633us (13.99 seconds). >=20 > ; reduce # of vnodes with sysctl kern.maxvnodes=3D1000 > test now runs clean. Definitely syncer.=20 > > > >It would be interesting to check whether completely disabling the =20 > >syncer > >eliminates the packet loss, but such system have to be operated with > >extreme caution. Ok, no need to do this. As Bruce Evans noted, there is a vfs_msync() that do almost the same traversal of the vnodes. It was missed in the previous patch. Try this one. diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 3c2e1ed..6515d6a 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -2967,7 +2967,9 @@ vfs_msync(struct mount *mp, int flags) { struct vnode *vp, *mvp; struct vm_object *obj; + int yield_count; =20 + yield_count =3D 0; MNT_ILOCK(mp); MNT_VNODE_FOREACH(vp, mp, mvp) { VI_LOCK(vp); @@ -2996,6 +2998,12 @@ vfs_msync(struct mount *mp, int flags) MNT_ILOCK(mp); } else VI_UNLOCK(vp); + if (yield_count++ =3D=3D 500) { + MNT_IUNLOCK(mp); + yield_count =3D 0; + uio_yield(); + MNT_ILOCK(mp); + } } MNT_IUNLOCK(mp); } diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c index cbccc62..9e8b887 100644 --- a/sys/ufs/ffs/ffs_vfsops.c +++ b/sys/ufs/ffs/ffs_vfsops.c @@ -1182,6 +1182,7 @@ ffs_sync(mp, waitfor, td) int secondary_accwrites; int softdep_deps; int softdep_accdeps; + int yield_count; struct bufobj *bo; =20 fs =3D ump->um_fs; @@ -1216,6 +1217,7 @@ loop: softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps); MNT_ILOCK(mp); =20 + yield_count =3D 0; MNT_VNODE_FOREACH(vp, mp, mvp) { /* * Depend on the mntvnode_slock to keep things stable enough @@ -1233,6 +1235,12 @@ loop: (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) =3D=3D 0 && vp->v_bufobj.bo_dirty.bv_cnt =3D=3D 0)) { VI_UNLOCK(vp); + if (yield_count++ =3D=3D 500) { + MNT_IUNLOCK(mp); + yield_count =3D 0; + uio_yield(); + MNT_ILOCK(mp); + } continue; } MNT_IUNLOCK(mp); --N7HXVILz59yg1nI8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHbLa1C3+MBN1Mb4gRAjZAAKDOZCUCmfjbFX61IvwpSDfMg8dTCgCgqxLE LsxaM+dv/WP5wHW2z1lYJZ8= =yi5I -----END PGP SIGNATURE----- --N7HXVILz59yg1nI8-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 07:09:38 2007 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 391DD16A46C; Sat, 22 Dec 2007 07:09:38 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1316413C458; Sat, 22 Dec 2007 07:09:37 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBM79b5I029206; Fri, 21 Dec 2007 23:09:37 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBM79bC6029205; Fri, 21 Dec 2007 23:09:37 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Fri, 21 Dec 2007 23:09:37 -0800 From: David G Lawrence To: David Schwartz Message-ID: <20071222070937.GU25053@tnn.dglawrence.com> References: <20071221234347.GS25053@tnn.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Fri, 21 Dec 2007 23:09:37 -0800 (PST) Cc: "Freebsd-Net@Freebsd. Org" , freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 07:09:38 -0000 > I'm just an observer, and I may be confused, but it seems to me that this is > motion in the wrong direction (at least, it's not going to fix the actual > problem). As I understand the problem, once you reach a certain point, the > system slows down *every* 30.999 seconds. Now, it's possible for the code to > cause one slowdown as it cleans up, but why does it need to clean up so much > 31 seconds later? > > Why not find/fix the actual bug? Then work on getting the yield right if it > turns out there's an actual problem for it to fix. > > If the problem is that too much work is being done at a stretch and it turns > out this is because work is being done erroneously or needlessly, fixing > that should solve the whole problem. Doing the work that doesn't need to be > done more slowly is at best an ugly workaround. > > Or am I misunderstanding? It's the syncer that is causing the problem, and it runs every 31 seconds. Historically, the syncer ran every 30 seconds, but things have changed a bit over time. The reason that the syncer takes so muck time is that ffs_sync is a bit stupid in how it works - it loops through all of the vnodes on each ffs mountpoint (typically almost all of the vnodes in the system) to see if any of them need to be synced out. This was marginally okay when there were perhaps a thousand vnodes in the system, but when the maximum number of vnodes was dramatically increased in FreeBSD some years ago (to typically 50000-100000) and combined with kernel threads of FreeBSD 5, this has resulted in some rather bad side effects. I think the proper solution would be to create a ffs_sync work list (another TAILQ/LISTQ), probably with the head in the mountpoint struct, that has on it any vnodes that need to be synced. Unfortuantely, such a change would be extensive, scattered throughout much of the ufs/ffs code. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 07:15:17 2007 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 C055C16A41B; Sat, 22 Dec 2007 07:15:17 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 97BCE13C461; Sat, 22 Dec 2007 07:15:17 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBM7FHrJ033326; Fri, 21 Dec 2007 23:15:17 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBM7FH0c033325; Fri, 21 Dec 2007 23:15:17 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Fri, 21 Dec 2007 23:15:17 -0800 From: David G Lawrence To: Kostik Belousov Message-ID: <20071222071517.GV25053@tnn.dglawrence.com> References: <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> <20071222053648.GQ57756@deviant.kiev.zoral.com.ua> <3647BB78-BA10-432B-A52B-04E402E155CC@splintered.net> <20071222070318.GT57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071222070318.GT57756@deviant.kiev.zoral.com.ua> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Fri, 21 Dec 2007 23:15:17 -0800 (PST) Cc: Mark Fullmer , freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 07:15:17 -0000 > As Bruce Evans noted, there is a vfs_msync() that do almost the same > traversal of the vnodes. It was missed in the previous patch. Try this one. I forgot to comment on that when Bruce pointed that out. My solution has been to comment out the call to vfs_msync. :-) It comes into play when you have files modified through the mmap interface (kind of rare on most systems). Obviously I have mixed feelings about vfs_msync, but I'm not suggesting here that we should get rid of it as any sort of solution. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 07:32:37 2007 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 5999716A41B; Sat, 22 Dec 2007 07:32:37 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (static-72-90-113-2.ptldor.fios.verizon.net [72.90.113.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2214113C447; Sat, 22 Dec 2007 07:32:37 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id lBM7WaXn044068; Fri, 21 Dec 2007 23:32:36 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id lBM7WaHO044067; Fri, 21 Dec 2007 23:32:36 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Fri, 21 Dec 2007 23:32:36 -0800 From: David G Lawrence To: Alfred Perlstein Message-ID: <20071222073236.GW25053@tnn.dglawrence.com> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <20071222002432.GK16982@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071222002432.GK16982@elvis.mu.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Fri, 21 Dec 2007 23:32:36 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 07:32:37 -0000 > > > Can you use a placeholder vnode as a place to restart the scan? > > > you might have to mark it special so that other threads/things > > > (getnewvnode()?) don't molest it, but it can provide for a convenient > > > restart point. > > > > That was one of the solutions that I considered and rejected since it > > would significantly increase the overhead of the loop. > > The solution provided by Kostik Belousov that uses uio_yield looks like > > a find solution. I intend to try it out on some servers RSN. > > Out of curiosity's sake, why would it make the loop slower? one > would only add the placeholder when yielding, not for every iteration. Actually, I misread your suggestion and was thinking marker flag, rather than placeholder vnode. Sorry about that. The current code actually already uses a marker vnode. It is hidden and obfuscated in the MNT_VNODE_FOREACH macro, further hidden in the __mnt_vnode_first/next functions, so it should be safe from vnode reclaimation/free problems. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 08:34:08 2007 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 C5C8116A468 for ; Sat, 22 Dec 2007 08:34:08 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 8868913C45B for ; Sat, 22 Dec 2007 08:34:08 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so164865anc.13 for ; Sat, 22 Dec 2007 00:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=WrsETWUWPjPtD/mNxQbMARsT9op3CKZX5PGVBlaH4Dk=; b=rkpxfEaRIT65825BKk2ucC+qWAURIxwdg3y3HRc+pMmNS66p6RBaCxYSHbDoLHw4k9Ec4EJxOnsDwkVJnBKkwGhpMHcQEKVvIfdKMdEQ0pLLm9VC3Wmq2reQFfP7dkbrWTXwQ7AFAJIJTWk84V7/Vp0ghSRRRFffrnoHEkOlNps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cUMeho0kFdgQm9eL6lxe6BxvoxwMXYfe9qmIivB8j+oj13J4TWMS1/UsaxzWEyjQlnXjxGa1PATuSKdE4I0RbGuo1wU3umRu7N1Vq71+i6YlQhhXju90vk3fe6+F6GmlEjpjz74FGUaf3kRJOKV2rWdCIXVgJZ/ko+UANY2zOQ8= Received: by 10.100.247.14 with SMTP id u14mr2662612anh.79.1198310882828; Sat, 22 Dec 2007 00:08:02 -0800 (PST) Received: by 10.100.228.15 with HTTP; Sat, 22 Dec 2007 00:08:02 -0800 (PST) Message-ID: Date: Sat, 22 Dec 2007 09:08:02 +0100 From: "Claus Guttesen" To: "Brett Glass" In-Reply-To: <200712220531.WAA09277@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712220531.WAA09277@lariat.net> Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 08:34:08 -0000 > I will need to build several Web caches over the next few months, > and just took advantage of the Christmas lull (and a snowy day, > when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how > it will perform at this task. I built up a 4 core FreeBSD box, and > asked a friend who's a Linux fanatic to do the same with Linux on > identical hardware. I didn't watch closely how he installed > everything, but asked him not to tune it beyond setting it up > properly for SMP. > > We then ran a test suite in which a client starts several > processes. Each uses wget to fetch a series of objects in rapid > succession via the cache. The fetches done by each process are the > same batch of URLS, but shuffled differently, so each URL will get > a miss the first time and then hits each time it comes up > thereafter unless the cache overflows. We're doing all GETs, with > no tricky stuff like subranges. > > As has been reported in some other messages on this list, Linux is > currently blowing FreeBSD away. It's taking as much as 20% less > time to get through the benchmark, depending on exactly how the > random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD > SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. > > It appears, though I'd need to instrument the code more to be sure, > that the slowdown is coming from file I/O. Could it be that there > less concurrency or more overhead in FreeBSD file operations than > there is in Linux? Even with SoftUpdates turned on, the cache > volume mounted with -noatime, and aufs (which uses kqueues -- a > FreeBSD invention -- to optimize multithreaded disk access), the > benchmark shows FreeBSD losing out. Why? I have noticed an entry in GENERIC called device cpufreq Could this have any influence on the performance (on FreeBSD)? I saw this device late in the 7.0 release-process and I since I'm accustomed to comment out any devices and options I don't need I have commented this out as well. So I haven't performed any tests with and without this device. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 09:40:00 2007 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 2BD9E16A417 for ; Sat, 22 Dec 2007 09:40:00 +0000 (UTC) (envelope-from ota@animenfo.com) Received: from smtp.unitz.ca (mx1.unitz.ca [69.60.224.6]) by mx1.freebsd.org (Postfix) with ESMTP id EC11B13C4EC for ; Sat, 22 Dec 2007 09:39:59 +0000 (UTC) (envelope-from ota@animenfo.com) Received: from localhost (localhost [127.0.0.1]) by smtp.unitz.ca (Postfix) with ESMTP id C63F27D0AD8; Sat, 22 Dec 2007 04:00:54 -0500 (EST) Received: from smtp.unitz.ca ([127.0.0.1]) by localhost (smtp.unitz.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO25r-+zqhfs; Sat, 22 Dec 2007 04:00:54 -0500 (EST) Received: from unitz.ca (dsl-69-60-252-220.unitz.ca [69.60.252.220]) by smtp.unitz.ca (Postfix) with SMTP id 33D0A7D0AD3; Sat, 22 Dec 2007 04:00:54 -0500 (EST) Received: by unitz.ca (nbSMTP-1.00) for uid 1001 ota@animenfo.com; Sat, 22 Dec 2007 04:05:54 -0500 (EST) Date: Sat, 22 Dec 2007 04:05:53 -0500 From: User Ota To: Claus Guttesen Message-ID: <20071222090553.GB16381@noah.ota.homelinux.net> References: <200712220531.WAA09277@lariat.net> 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: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? freenx@deweyonline.com 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, 22 Dec 2007 09:40:00 -0000 On Sat, Dec 22, 2007 at 09:08:02AM +0100, Claus Guttesen wrote: > > I will need to build several Web caches over the next few months, > > and just took advantage of the Christmas lull (and a snowy day, > > when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how > > it will perform at this task. I built up a 4 core FreeBSD box, and > > asked a friend who's a Linux fanatic to do the same with Linux on > > identical hardware. I didn't watch closely how he installed > > everything, but asked him not to tune it beyond setting it up > > properly for SMP. > > > > We then ran a test suite in which a client starts several > > processes. Each uses wget to fetch a series of objects in rapid > > succession via the cache. The fetches done by each process are the > > same batch of URLS, but shuffled differently, so each URL will get > > a miss the first time and then hits each time it comes up > > thereafter unless the cache overflows. We're doing all GETs, with > > no tricky stuff like subranges. > > > > As has been reported in some other messages on this list, Linux is > > currently blowing FreeBSD away. It's taking as much as 20% less > > time to get through the benchmark, depending on exactly how the > > random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD > > SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. > > > > It appears, though I'd need to instrument the code more to be sure, > > that the slowdown is coming from file I/O. Could it be that there > > less concurrency or more overhead in FreeBSD file operations than > > there is in Linux? Even with SoftUpdates turned on, the cache > > volume mounted with -noatime, and aufs (which uses kqueues -- a > > FreeBSD invention -- to optimize multithreaded disk access), the > > benchmark shows FreeBSD losing out. Why? > > I have noticed an entry in GENERIC called > > device cpufreq > > Could this have any influence on the performance (on FreeBSD)? > > I saw this device late in the 7.0 release-process and I since I'm > accustomed to comment out any devices and options I don't need I have > commented this out as well. So I haven't performed any tests with and > without this device. > > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare > _______________________________________________ > 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" Cpufreq is for CPU frequency scaling. In the linux world, the cpufreq daemon allows you to control your cpu speed and voltage using power profiles and such, which makes it a definite power saving tool for laptops. The cpufreq driver is already included with the Linux kernel, so I'm going to assume that they've just implemented the cpufreq driver in the kernel recently :) If enabled, it probably would have an impact on performance, however I have lost the ability to test such a function since my laptop decides not to POST anymore. Russell Doucette From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 10:55:53 2007 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 3A60616A41A for ; Sat, 22 Dec 2007 10:55:53 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id D083D13C45B for ; Sat, 22 Dec 2007 10:55:52 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180138246.adsl.alicedsl.de [85.180.138.246]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id lBMAXvW3050133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Dec 2007 11:33:58 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id lBMAXqTj003287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Dec 2007 11:33:52 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id lBMAXpU3003286; Sat, 22 Dec 2007 11:33:51 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Sat, 22 Dec 2007 11:33:50 +0100 From: Ulrich Spoerlein To: Brett Glass Message-ID: <20071222103350.GA2747@roadrunner.spoerlein.net> Mail-Followup-To: Brett Glass , stable@freebsd.org References: <200712220531.WAA09277@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712220531.WAA09277@lariat.net> User-Agent: Mutt/1.5.16 (2007-06-09) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on acme.spoerlein.net Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 10:55:53 -0000 On Fri, 21.12.2007 at 22:31:24 -0700, Brett Glass wrote: > As has been reported in some other messages on this list, Linux is currently > blowing FreeBSD away. It's taking as much as 20% less time to get through > the benchmark, depending on exactly how the random shuffle came out. This is > with 4 GB RAM, the GENERIC FreeBSD SMP kernel (using SCHED_ULE), and aufs as > the storage schema for Squid. Apples and Oranges, I know, but if you're building a "simple" reverse cacheing proxy, have you considered Varnish? Would be very interessting how it would compare to a) FreeBSD+Squid b) Linux+Squid and c) Linux+Varnish. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 11:32:32 2007 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 51B1F16A41A for ; Sat, 22 Dec 2007 11:32:32 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from mail.webreality.org (mailserver.webreality.org [217.75.141.5]) by mx1.freebsd.org (Postfix) with ESMTP id 19FB213C4E1 for ; Sat, 22 Dec 2007 11:32:31 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from [192.168.224.203] (unknown [77.78.9.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webreality.org (Postfix) with ESMTP id D59CDFFE333; Sat, 22 Dec 2007 13:07:27 +0200 (EET) Message-ID: <476CEFE7.3060402@lozenetz.org> Date: Sat, 22 Dec 2007 13:07:19 +0200 From: Anton - Valqk User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, 000.fbsd@quip.cz, lists@lozenetz.org References: <200712201741.lBKHfDRb069152@lurza.secnetix.de> In-Reply-To: <200712201741.lBKHfDRb069152@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-HostIT-MailScanner-Information: Please contact the ISP for more information X-HostIT-MailScanner: Found to be clean X-HostIT-MailScanner-From: lists@lozenetz.org Cc: Subject: Re: jlogin.sh - a small nice jails helper! 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, 22 Dec 2007 11:32:32 -0000 Hi there, your script didn't had what I wanted for the ps, that's why I wrote simpler one for myself, that's do the job for me - finds a string from ps axu from any jail :) here it is, hopes it's useful (quick 15mins hack script). #!/bin/sh #list all jails processes #$1 - jid - jail pattern || ALL #$2 - string in jail ps axu cmd if [ -n "$2" ]; then psFilter="grep $2" fi if [ -n "$1" ] && [ "$1" != "ALL" ]; then jName=$1 jID=`jls | grep $jName|awk '{print $1}'` jRealName=`jls |grep $jName|awk '{print $3}'` echo "Listing processes for $jRealName ( $jID )..." if [ -n "$psFilter" ]; then jexec $jID ps axu|$psFilter else jexec $jID ps axu fi else for jID in `jls|awk '{print $1}'`; do if [ "$jID" -gt 0 ]; then jRealName=`jls|grep $jID|awk '{print $3}'` echo "Listing processes for $jRealName ( $jID )..." if [ -n "$psFilter" ]; then jexec $jID ps axu|$psFilter else jexec $jID ps axu fi fi done fi Oliver Fromme wrote: > Miroslav Lachman wrote: > > It is nice idea, but I think you should have a better scripting style ;) > > Yes, it almost looked like perl. :-) > May I suggest a few further improvements? > > > login_shell="/bin/tcsh" > > I certainly wouldn't want tcsh. How about looking at > $SHELL, and if it doesn't exist, then fall back to the > standard shell (which is /bin/sh). > > Also, the last command (jexec) should be preceded by > "exec" so the shell doesn't hang around. So the last > part of the script would look like this: > > jail_path=$(jls | awk '$1=='$jail_id' {print $4}') > > if [ -z "$SHELL" -o ! -x "$jail_path/$SHELL" ]; then > login_shell="$SHELL" > else > login_shell="/bin/sh" > fi > > echo "Logging in to $jail_hostname" > exec jexec $jail_id $login_shell > > Best regards > Oliver > > PS: By the way, here's another useful script that displays > processes running in jails, ordered by jail IDs: > > http://www.secnetix.de/~olli/scripts/jps > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 12:00:15 2007 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 7D63316A49A for ; Sat, 22 Dec 2007 12:00:15 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DAD8213C467 for ; Sat, 22 Dec 2007 12:00:14 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 22 Dec 2007 12:00:12 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO homeKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp007) with SMTP; 22 Dec 2007 13:00:12 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX192te1Qm1l2YVNBD3DNkL70BKzCsMPJj8aYsc9YHa JIDpFlgovHMPZq Message-ID: <476CFC45.40107@gmx.de> Date: Sat, 22 Dec 2007 13:00:05 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20071203) MIME-Version: 1.0 To: Joshua Coombs References: <200712201706.lBKH6fwn067680@lurza.secnetix.de> <476ABD93.3080707@brianwhalen.net> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7 on old SMP server? 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, 22 Dec 2007 12:00:15 -0000 Joshua Coombs wrote: > Brian wrote: > >> Would that be a multiday buildworld? >> >> Brian > > 10 days on average. : ) I'm trying a 7 build without -pipe to see if I > can squeak it through with 64MB RAM + 384MB swap, I'd much prefer not > having to do a dump/restore to reallocate space for more swap. I'm > almost thinking a non -pipe build may be quicker given the limited ram I > have. > > Josh C Why don't you just do the buildworld on another machine? From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 12:21:31 2007 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 CB08B16A417; Sat, 22 Dec 2007 12:21:31 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb5:7e66]) by mx1.freebsd.org (Postfix) with ESMTP id E19B013C458; Sat, 22 Dec 2007 12:21:30 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id lBMCLMfr000376; Sat, 22 Dec 2007 13:21:23 +0100 From: Pieter de Goeje To: freebsd-stable@freebsd.org Date: Sat, 22 Dec 2007 13:21:22 +0100 User-Agent: KMail/1.9.7 References: <200712220531.WAA09277@lariat.net> In-Reply-To: <200712220531.WAA09277@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712221321.22666.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Brett Glass , stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 12:21:31 -0000 On Saturday 22 December 2007, Brett Glass wrote: > I will need to build several Web caches over the next few months, > and just took advantage of the Christmas lull (and a snowy day, > when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how > it will perform at this task. I built up a 4 core FreeBSD box, and > asked a friend who's a Linux fanatic to do the same with Linux on > identical hardware. I didn't watch closely how he installed > everything, but asked him not to tune it beyond setting it up > properly for SMP. > > We then ran a test suite in which a client starts several > processes. Each uses wget to fetch a series of objects in rapid > succession via the cache. The fetches done by each process are the > same batch of URLS, but shuffled differently, so each URL will get > a miss the first time and then hits each time it comes up > thereafter unless the cache overflows. We're doing all GETs, with > no tricky stuff like subranges. > > As has been reported in some other messages on this list, Linux is > currently blowing FreeBSD away. It's taking as much as 20% less > time to get through the benchmark, depending on exactly how the > random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD > SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. > > It appears, though I'd need to instrument the code more to be sure, > that the slowdown is coming from file I/O. Could it be that there > less concurrency or more overhead in FreeBSD file operations than > there is in Linux? Even with SoftUpdates turned on, the cache > volume mounted with -noatime, and aufs (which uses kqueues -- a > FreeBSD invention -- to optimize multithreaded disk access), the > benchmark shows FreeBSD losing out. Why? Since you're using the fs as a cache, I presume it wouldn't be a big problem if the data was lost by a power outage (or crash). If so, you can try the async mount option to seriously increase fs performance. Pieter de Goeje From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 12:21:31 2007 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 CB08B16A417; Sat, 22 Dec 2007 12:21:31 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb5:7e66]) by mx1.freebsd.org (Postfix) with ESMTP id E19B013C458; Sat, 22 Dec 2007 12:21:30 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id lBMCLMfr000376; Sat, 22 Dec 2007 13:21:23 +0100 From: Pieter de Goeje To: freebsd-stable@freebsd.org Date: Sat, 22 Dec 2007 13:21:22 +0100 User-Agent: KMail/1.9.7 References: <200712220531.WAA09277@lariat.net> In-Reply-To: <200712220531.WAA09277@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712221321.22666.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Brett Glass , stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 12:21:31 -0000 On Saturday 22 December 2007, Brett Glass wrote: > I will need to build several Web caches over the next few months, > and just took advantage of the Christmas lull (and a snowy day, > when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how > it will perform at this task. I built up a 4 core FreeBSD box, and > asked a friend who's a Linux fanatic to do the same with Linux on > identical hardware. I didn't watch closely how he installed > everything, but asked him not to tune it beyond setting it up > properly for SMP. > > We then ran a test suite in which a client starts several > processes. Each uses wget to fetch a series of objects in rapid > succession via the cache. The fetches done by each process are the > same batch of URLS, but shuffled differently, so each URL will get > a miss the first time and then hits each time it comes up > thereafter unless the cache overflows. We're doing all GETs, with > no tricky stuff like subranges. > > As has been reported in some other messages on this list, Linux is > currently blowing FreeBSD away. It's taking as much as 20% less > time to get through the benchmark, depending on exactly how the > random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD > SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. > > It appears, though I'd need to instrument the code more to be sure, > that the slowdown is coming from file I/O. Could it be that there > less concurrency or more overhead in FreeBSD file operations than > there is in Linux? Even with SoftUpdates turned on, the cache > volume mounted with -noatime, and aufs (which uses kqueues -- a > FreeBSD invention -- to optimize multithreaded disk access), the > benchmark shows FreeBSD losing out. Why? Since you're using the fs as a cache, I presume it wouldn't be a big problem if the data was lost by a power outage (or crash). If so, you can try the async mount option to seriously increase fs performance. Pieter de Goeje From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 12:40:01 2007 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 9D10816A417 for ; Sat, 22 Dec 2007 12:40:01 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 69A5F13C455 for ; Sat, 22 Dec 2007 12:40:01 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so180202anc.13 for ; Sat, 22 Dec 2007 04:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=N2hL/zRb/YVdCNhp0fgNbQ12czbww9FcURW+BvF3Y6c=; b=Sx7NgA5adHPWAlJcbkn97RXw1lZgLnYdLFf8FkcT0d1GAbPlDmb2AWv1uzFVGWC6cY7UJKcoq2KV8DCaPDqCQqqNzWCMBTDjM3O/YRLmwccWjpVE94jZrtoufaBP+QkyZGWgsDaTA5t5Mmm2TwHETzsSlGAUFWhJl3DJdGQsAG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GBgjLlGa/umxaW6x0KmqxAOZPW0wrzGlxDr6lZg4sTZdWBMlt4DXp/NYC6IKhWdnFN/mUb4t+n7XI9Wto7vePnxh841XlC2WdHcgixNZFU9S1vjxRRhaMW2j4bRBBl9qqtBdceB3H8oeakK5adK0fD43FHtTsz00n1lPMAOSku0= Received: by 10.100.202.9 with SMTP id z9mr3085953anf.16.1198327200630; Sat, 22 Dec 2007 04:40:00 -0800 (PST) Received: by 10.100.228.15 with HTTP; Sat, 22 Dec 2007 04:40:00 -0800 (PST) Message-ID: Date: Sat, 22 Dec 2007 13:40:00 +0100 From: "Claus Guttesen" To: "User Ota" In-Reply-To: <20071222090553.GB16381@noah.ota.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712220531.WAA09277@lariat.net> <20071222090553.GB16381@noah.ota.homelinux.net> Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? freenx@deweyonline.com 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, 22 Dec 2007 12:40:01 -0000 > > > It appears, though I'd need to instrument the code more to be sure, > > > that the slowdown is coming from file I/O. Could it be that there > > > less concurrency or more overhead in FreeBSD file operations than > > > there is in Linux? Even with SoftUpdates turned on, the cache > > > volume mounted with -noatime, and aufs (which uses kqueues -- a > > > FreeBSD invention -- to optimize multithreaded disk access), the > > > benchmark shows FreeBSD losing out. Why? > > > > I have noticed an entry in GENERIC called > > > > device cpufreq > > > > Could this have any influence on the performance (on FreeBSD)? > > > > I saw this device late in the 7.0 release-process and I since I'm > > accustomed to comment out any devices and options I don't need I have > > commented this out as well. So I haven't performed any tests with and > > without this device. > > > > Cpufreq is for CPU frequency scaling. In the linux world, the cpufreq > daemon allows you to control your cpu speed and voltage using power > profiles and such, which makes it a definite power saving tool for > laptops. The cpufreq driver is already included with the Linux kernel, > so I'm going to assume that they've just implemented the cpufreq driver > in the kernel recently :) > > If enabled, it probably would have an impact on performance, however I > have lost the ability to test such a function since my laptop decides > not to POST anymore. Yes, I did figure out what the purpose of this device was. :-) My point was that this could lead to lower benchmarks on servers if GENERIC is used. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 13:23:44 2007 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 4B74516A419 for ; Sat, 22 Dec 2007 13:23:44 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id C693913C45B for ; Sat, 22 Dec 2007 13:23:43 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id GAA15374; Sat, 22 Dec 2007 06:23:34 -0700 (MST) Message-Id: <200712221323.GAA15374@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Dec 2007 06:23:32 -0700 To: Pieter de Goeje , freebsd-stable@freebsd.org From: Brett Glass In-Reply-To: <200712221321.22666.pieter@degoeje.nl> References: <200712220531.WAA09277@lariat.net> <200712221321.22666.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 13:23:44 -0000 At 05:21 AM 12/22/2007, Pieter de Goeje wrote: >Since you're using the fs as a cache, I presume it wouldn't be a big problem >if the data was lost by a power outage (or crash). If so, you can try the >async mount option to seriously increase fs performance. Linux also speeds up if you try mounting the volume -async, maintaining a similar advantage. And mounting the volume -async is a bit dangerous, because the cache can become very inconsistent during a crash.... SoftUpdates is generally what's recommended. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 13:34:13 2007 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 5B3B916A418 for ; Sat, 22 Dec 2007 13:34:13 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id E1D6413C4E3 for ; Sat, 22 Dec 2007 13:34:12 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id GAA15374; Sat, 22 Dec 2007 06:23:34 -0700 (MST) Message-Id: <200712221323.GAA15374@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Dec 2007 06:23:32 -0700 To: Pieter de Goeje , freebsd-stable@freebsd.org From: Brett Glass In-Reply-To: <200712221321.22666.pieter@degoeje.nl> References: <200712220531.WAA09277@lariat.net> <200712221321.22666.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 13:34:13 -0000 At 05:21 AM 12/22/2007, Pieter de Goeje wrote: >Since you're using the fs as a cache, I presume it wouldn't be a big problem >if the data was lost by a power outage (or crash). If so, you can try the >async mount option to seriously increase fs performance. Linux also speeds up if you try mounting the volume -async, maintaining a similar advantage. And mounting the volume -async is a bit dangerous, because the cache can become very inconsistent during a crash.... SoftUpdates is generally what's recommended. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 13:46:46 2007 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 26DFE16A473; Sat, 22 Dec 2007 13:46:46 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E255D13C4F8; Sat, 22 Dec 2007 13:46:45 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id lBMDE00M076466; Sat, 22 Dec 2007 08:14:00 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id lBMDDx5M036478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Dec 2007 08:13:59 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200712221313.lBMDDx5M036478@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Dec 2007 08:14:04 -0500 To: Mikhail Teterin , stable@freebsd.org From: Mike Tancsa In-Reply-To: <200712212341.44308@aldan> References: <200712212341.44308@aldan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-usb@freebsd.org Subject: Re: usb/umass, devfs: this sucks 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, 22 Dec 2007 13:46:46 -0000 At 11:41 PM 12/21/2007, Mikhail Teterin wrote: >Another attempt to use USB-storage with FreeBSD, another moment of >hair-pulling frustration. > >I attach the card-reader with the media card already inserted (detection of >card-insertion has not worked in a long time, if ever). Perhaps its the one card reader you are using is particularly problematic ? I have been using the multi-type cheapo reader below for some time port 6 addr 2: high speed, power 100 mA, config 1, Mass Storage Device(0x6362), Generic(0x058f), rev 1.26 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 976MB (2000880 512 byte sectors: 64H 32S/T 976C) da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present We go through the following steps when using it. We always plug the reader in without a card. Then we put the card in and do a cat /dev/null > /dev/da1 ... or whatever the device is. Its been quite reliable this way for us. The other caveat is never to pull the card or reader when its mounted. ---Mike >The "disk" appears: > > umass1: Genesys USB Reader, rev 2.00/91.38, addr 3 > da6 at umass-sim1 bus 1 target 0 lun 0 > da6: Removable Direct Access > SCSI-0 device > da6: 40.000MB/s transfers > da6: 1938MB (3970048 512 byte sectors: 255H 63S/T 247C) > (da6:umass-sim1:1:0:0): AutoSense Failed > >But the "slices" (/dev/da6s1, etc.) don't appear: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/76461 > >In the past, trying to mount, or otherwise read the da6 would result in the >slices appearing -- an awful wart, when it works. So I try it, but it does >not work: > > root@aldan:/home/mi (116) mount -tmsdosfs /dev/da6 /mnt > ... hang ... > >Pressing Ctrl-T: > load: 0.58 cmd: mount_msdosfs 64452 [GEOM topology] 0.00u > 0.00s 0% 804k > ... > load: 0.47 cmd: mount_msdosfs 64452 [GEOM topology] 0.00u > 0.00s 0% 804k > >It still hangs, and now other things hang too. top, for example, hangs on >start-up: > > mi@aldan:~ (1084) top > ... hang ... >Pressing Ctrl-T: > load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k > load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k > load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k > load: 0.57 cmd: top 64480 [devfs] 0.00u 0.00s 0% 1652k > >No new window can be opened either -- presumably due to devfs hanging. I >suspect, that anything attempting to use even the /dev/null is hanging now. > >So, not only the USB itself is broken, our wonderful devfs is rather creaky >too -- nothing should be in an uninterruptible state like this for more than >a millisecond. > >25 minutes later the mount finally gave up: > > umass1: BBB reset failed, TIMEOUT > umass1: BBB bulk-in clear stall failed, TIMEOUT > umass1: BBB bulk-out clear stall failed, TIMEOUT > mount_msdosfs: /dev/da6: Input/output error > >Things are back to "normal" again, but the media card is still inaccessible. >I'll try to work with it using mtools -- I had some success in the pass >accessing the FAT-filesystem on the media cards using mcopy, mdir, etc. > >I'm using 6.3-PRERELEASE as of Dec 6th, but a search for umass-related bugs > > http://www.freebsd.org/cgi/query-pr-summary.cgi?text=umass > >reveals plenty of really old problems, which don't even have a single >follow-up from FreeBSD-developers. Like: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/95037 > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/95173 > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/107848 > >Looks like USB is unmaintained and getting worse. Are we really shipping this >as "the most recent stable release"? > > -mi >_______________________________________________ >freebsd-usb@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-usb >To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 14:16:22 2007 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 2229616A419; Sat, 22 Dec 2007 14:16:22 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id E4F8513C468; Sat, 22 Dec 2007 14:16:21 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id lBMEGFCu085329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Dec 2007 09:16:15 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pwlMBXfwLkG6xaJPeHLN" Organization: U. Buffalo CSE Department Date: Sat, 22 Dec 2007 09:16:15 -0500 Message-Id: <1198332975.54116.25.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1029; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Subject: HEADS-UP: RELENG_7_0 created... 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, 22 Dec 2007 14:16:22 -0000 --=-pwlMBXfwLkG6xaJPeHLN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In preparation for 7.0-RC1 the release branch, RELENG_7_0, has been created. I'll send another message when the 7.0-RC1 builds are done, this is just to let people who use cvsup updates know about the new branch. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-pwlMBXfwLkG6xaJPeHLN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHbRwv/G14VSmup/YRAiAyAKCHw6J+GKZJWsBcxg4kY7NJJW8KAACdHwTj GMVwq/pxWSBzdNG3Jqr+sk8= =llk7 -----END PGP SIGNATURE----- --=-pwlMBXfwLkG6xaJPeHLN-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 15:59:29 2007 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 EE97616A468 for ; Sat, 22 Dec 2007 15:59:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 82D3213C4CC for ; Sat, 22 Dec 2007 15:59:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id CAA14515; Sun, 23 Dec 2007 02:59:08 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 23 Dec 2007 02:59:08 +1100 (EST) From: Ian Smith To: Claus Guttesen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@freebsd.org, User Ota Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? freenx@deweyonline.com 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, 22 Dec 2007 15:59:30 -0000 On Sat, 22 Dec 2007, Claus Guttesen wrote: > > > I have noticed an entry in GENERIC called > > > > > > device cpufreq > > > > > > Could this have any influence on the performance (on FreeBSD)? > > > > > > I saw this device late in the 7.0 release-process and I since I'm > > > accustomed to comment out any devices and options I don't need I have > > > commented this out as well. So I haven't performed any tests with and > > > without this device. > > > > > > > Cpufreq is for CPU frequency scaling. In the linux world, the cpufreq > > daemon allows you to control your cpu speed and voltage using power > > profiles and such, which makes it a definite power saving tool for > > laptops. The cpufreq driver is already included with the Linux kernel, > > so I'm going to assume that they've just implemented the cpufreq driver > > in the kernel recently :) > > > > If enabled, it probably would have an impact on performance, however I > > have lost the ability to test such a function since my laptop decides > > not to POST anymore. > > Yes, I did figure out what the purpose of this device was. :-) My > point was that this could lead to lower benchmarks on servers if > GENERIC is used. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC ======================= Revision 1.473: download - view: text, markup, annotated - select for diffs Sun Jul 1 21:47:45 2007 UTC (5 months, 3 weeks ago) by njl Branches: MAIN Diff to: previous 1.472: preferred, colored Changes since revision 1.472: +3 -0 lines Add cpufreq(4) to GENERIC. It does not change the frequency by default, so systems should be relatively unaffected. Users can then simply enable powerd(8) in rc.conf to take advantage of it. Approved by: re ======================= FWIW, both my 5.5-STABLE APM laptop and 6.1-RELEASE GENERIC ACPI laptop show cpu/cpufreq in kernel (kldstat -v) so it's been there a long while. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 16:50:08 2007 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 288A916A417 for ; Sat, 22 Dec 2007 16:50:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id ED99A13C45A for ; Sat, 22 Dec 2007 16:50:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1740731pyb.3 for ; Sat, 22 Dec 2007 08:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=dr1Pfu5GXndLcHlukLX9eeNtmQbNyTT5xSvAVeuhBlQ=; b=u0rAum7u2nZoT4JMrUw+PBB3DmaZukfeEdWjnqZTKEIroLX3V+miMqXdXJeyzcXAWa+5UUn1vmN6WkDBGNz/dtsWjEQpyTq2A9kLKGiS2QwlFd84i46lHJcBtqKrd4CkXWh2ugRcvy5wcq0jqzzV5fk2jGqpyxU/EFYTM/ESx5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=k99ml+9igr5NoEdQjbwjVH2uaSwiQ55uhCElK1gQdrOeenZBDizqotnB9xwEkkLDMlGBvtOSu6+Tc5/ihCSPQ/omWT2ypFkfUxv6/NqAzKKOaEDEiASKVo7HTk1CwknV0FMcA/tKx09Oi62+dWWg9KIBRI0+alj2F2gLSpQ1MoQ= Received: by 10.65.20.18 with SMTP id x18mr3582032qbi.92.1198340576352; Sat, 22 Dec 2007 08:22:56 -0800 (PST) Received: by 10.65.237.12 with HTTP; Sat, 22 Dec 2007 08:22:56 -0800 (PST) Message-ID: Date: Sun, 23 Dec 2007 01:22:56 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Brett Glass" , stable@freebsd.org In-Reply-To: <20071222103350.GA2747@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712220531.WAA09277@lariat.net> <20071222103350.GA2747@roadrunner.spoerlein.net> X-Google-Sender-Auth: 1cf1ea33c06389be Cc: Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? 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, 22 Dec 2007 16:50:08 -0000 On 22/12/2007, Ulrich Spoerlein wrote: > Apples and Oranges, I know, but if you're building a "simple" reverse > cacheing proxy, have you considered Varnish? Would be very interessting > how it would compare to a) FreeBSD+Squid b) Linux+Squid and c) > Linux+Varnish. Personally, I'd be more interesting in more information about the methodology and the raw data. I'm busy going through and optimising Squid to, amusingly, have slightly Varnish-like internals. Having raw data and methodology both helps me see whether the tests are valid, figure out why the results are different, and helps me know when my work is on the right track. :) -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 17:08:15 2007 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 509EF16A418; Sat, 22 Dec 2007 17:08:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id EA4AA13C46B; Sat, 22 Dec 2007 17:08:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBMH897M022272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Dec 2007 04:08:11 +1100 Date: Sun, 23 Dec 2007 04:08:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Kostik Belousov In-Reply-To: <20071222050743.GP57756@deviant.kiev.zoral.com.ua> Message-ID: <20071223032944.G48303@delplex.bde.org> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Freebsd-Net@Freebsd. Org" , freebsd-stable@FreeBSD.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 17:08:15 -0000 On Sat, 22 Dec 2007, Kostik Belousov wrote: > On Fri, Dec 21, 2007 at 05:43:09PM -0800, David Schwartz wrote: >> >> I'm just an observer, and I may be confused, but it seems to me that this is >> motion in the wrong direction (at least, it's not going to fix the actual >> problem). As I understand the problem, once you reach a certain point, the >> system slows down *every* 30.999 seconds. Now, it's possible for the code to >> cause one slowdown as it cleans up, but why does it need to clean up so much >> 31 seconds later? It is just searching for things to clean up, and doing this pessimally due to unnecessary cache misses and (more recently) introduction of overheads to handling the case where the mount point is locked into the fast path where the mount point is not unlocked. The search every 30 seconds or so is probably more efficient, and is certainly simpler, than managing the list on every change to every vnode for every file system. However, it gives a high latency in non-preemptible kernels. >> Why not find/fix the actual bug? Then work on getting the yield right if it >> turns out there's an actual problem for it to fix. Yielding is probably the correct fix for non-preemptible kernels. Some operations just take a long time, but are low priority so they can be preempted. This operation is partly under user control, since any user can call sync(2) and thus generate the latency every seconds. But this is no worse than a user generating even larger blocks of latency by reading huge amounts from /dev/zero. My old latency workaround for the latter (and other huge i/o's) is still sort of necessary, though it now works bogusly (hogticks doesn't work since it is reset on context switches to interrupt handlers; however, any context switch mostly fixes the problem). My old latency workaround only reduces the latency to a multiple of 1/HZ, so a default of 200 ms, so it still is supposed to allow latencies much larger than the ones that cause problems here, but its bogus current operation tends to give latencies of more like 1/HZ which is short enough when HZ has its default misconfiguration to 1000. I still don't understand the original problem, that the kernel is not even preemptible enough for network interrupts to work (except in 5.2 where Giant breaks things). Perhaps I misread the problem, and it is actually that networking works but userland is unable to run in time to avoid packet loss. >> If the problem is that too much work is being done at a stretch and it turns >> out this is because work is being done erroneously or needlessly, fixing >> that should solve the whole problem. Doing the work that doesn't need to be >> done more slowly is at best an ugly workaround. Lots of necessary work is being done. > Yes, rewriting the syncer is the right solution. It probably cannot be done > quickly enough. If the yield workaround provide mitigation for now, it > shall go in. I don't think rewriting the syncer just for this is the right solution. Rewriting the syncer so that it schedules actual i/o more efficiently might involve a solution. Better scheduling would probably take more CPU and increase the problem. Note that MNT_VNODE_FOREACH() is used 17 times, so the yielding fix is needed in 17 places if it isn't done internally in MNT_VNODE_FOREACH(). There are 4 places in vfs and 13 places in 6 file systems: % ./ufs/ffs/ffs_snapshot.c: MNT_VNODE_FOREACH(xvp, mp, mvp) { % ./ufs/ffs/ffs_snapshot.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./ufs/ffs/ffs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./ufs/ffs/ffs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./ufs/ufs/ufs_quota.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./ufs/ufs/ufs_quota.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./ufs/ufs/ufs_quota.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./fs/msdosfs/msdosfs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, nvp) { % ./fs/coda/coda_subr.c: MNT_VNODE_FOREACH(vp, mp, nvp) { % ./gnu/fs/ext2fs/ext2_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./gnu/fs/ext2fs/ext2_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./kern/vfs_default.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./kern/vfs_subr.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./kern/vfs_subr.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./nfs4client/nfs4_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { % ./nfsclient/nfs_subs.c: MNT_VNODE_FOREACH(vp, mp, nvp) { % ./nfsclient/nfs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { Only file systems that support writing need it (for VOP_SYNC() and for MNT_RELOAD), else there would be many more places. There would also be more places if MNT_RELOAD support were not missing for some file systems. Bruce From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 18:02:29 2007 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 5E8C416A421 for ; Sat, 22 Dec 2007 18:02:29 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id 36E0513C4DB for ; Sat, 22 Dec 2007 18:02:29 +0000 (UTC) (envelope-from maf@eng.oar.net) Received: (qmail 7917 invoked from network); 22 Dec 2007 18:02:28 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 22 Dec 2007 18:02:28 -0000 In-Reply-To: <20071223032944.G48303@delplex.bde.org> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <985A3F99-B3F4-451E-BD77-E2EB4351E323@eng.oar.net> Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Sat, 22 Dec 2007 13:02:12 -0500 To: Bruce Evans X-Mailer: Apple Mail (2.752.3) Cc: Kostik Belousov , freebsd-net@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 18:02:29 -0000 On Dec 22, 2007, at 12:08 PM, Bruce Evans wrote: > > I still don't understand the original problem, that the kernel is not > even preemptible enough for network interrupts to work (except in 5.2 > where Giant breaks things). Perhaps I misread the problem, and it is > actually that networking works but userland is unable to run in time > to avoid packet loss. > The test is done with UDP packets between two servers. The em driver is incrementing the received packet count correctly but the packet is not making it up the network stack. If the application was not servicing the socket fast enough I would expect to see the "dropped due to full socket buffers" (udps_fullsock) counter incrementing, as shown by netstat -s. I grab a copy of netstat -s, netstat -i, and netstat -m before and after testing. Other than the link packets counter, I haven't seen any other indication of where the packet is getting lost. The em driver has a debugging stats option which does not indicate receive side overflows. I'm fairly certain this same behavior can be seen with the fxp driver, but I'll need to double check. These are results I sent a few days ago after setting up a test without an ethernet switch between the sender and receiver. The switch was originally used to verify the sender was actually transmitting. With spanning tree, ethernet keepalives, and CDP (cisco proprietary neighbor protocol) disabled and static ARP entries on the sender and receiver I can account for all packets making it to the receiver. ## > Back to back test with no ethernet switch between two em interfaces, > same result. The receiving side has been up > 1 day and exhibits > the problem. These are also two different servers. The small > gettimeofday() syscall tester also shows the same ~30 > second pattern of high latency between syscalls. > > Receiver test application reports 3699 missed packets > > Sender netstat -i: > > (before test) > em1 1500 00:04:23:cf:51:b7 20 0 > 15975785 0 0 > em1 1500 10.1/24 10.1.0.2 37 - > 15975801 - - > > (after test) > em1 1500 00:04:23:cf:51:b7 22 0 > 25975822 0 0 > em1 1500 10.1/24 10.1.0.2 39 - > 25975838 - - > > total IP packets sent in during test = end - start > 25975838-15975801 = 10000037 (expected, 1,000,000 packets test + > overhead) > > Receiver netstat -i: > > (before test) > em1 1500 00:04:23:c4:cc:89 15975785 0 > 21 0 0 > em1 1500 10.1/24 10.1.0.1 15969626 - > 19 - - > > (after test) > em1 1500 00:04:23:c4:cc:89 25975822 0 > 23 0 0 > em1 1500 10.1/24 10.1.0.1 25965964 - > 21 - - > > total ethernet frames received during test = end - start > 25975822-15975785 = 10000037 (as expected) > > total IP packets processed during test = end - start > 25965964-15969626 = 9996338 (expecting 10000037) > > Missed packets = expected - received > 10000037-9996338 = 3699 > > netstat -i accounts for the 3699 missed packets also reported by the > application > > Looking closer at the tester output again shows the periodic > ~30 second windows of packet loss. > > There's a second problem here in that packets are just disappearing > before they make it to ip_input(), or there's a dropped packets > counter I've not found yet. > > I can provide remote access to anyone who wants to take a look, this > is very easy to duplicate. The ~ 1 day uptime before the behavior > surfaces is not making this easy to isolate. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 18:06:19 2007 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 D8EAB16A418 for ; Sat, 22 Dec 2007 18:06:19 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from emma.lautre.net (emma.lautre.net [80.67.160.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8968613C46E for ; Sat, 22 Dec 2007 18:06:19 +0000 (UTC) (envelope-from thierry@pompo.net) Received: by graf.pompo.net (Postfix, from userid 1001) id 90BF011428; Sat, 22 Dec 2007 18:34:32 +0100 (CET) Date: Sat, 22 Dec 2007 18:34:32 +0100 From: Thierry Thomas To: FreeBSD-stable Message-ID: <20071222173432.GB4946@graf.pompo.net> Mail-Followup-To: FreeBSD-stable Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-BETA4 i386 Organization: Kabbale Eros X-PGP: 0xC71405A2 Cc: Subject: 7.0-BETA4: freeze caused by hostapd / ath0 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, 22 Dec 2007 18:06:19 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I have migrated a machine from 6.2-STABLE to 7.0-BETA4; this machine is configured as an access point, with the following PCI card: ath0: mem 0xfbed0000-0xfbedffff irq 18 at device 2.0 on pci2 With the same configuration, which used to work without any problem on 6.2-STABLE, the machine freezes when I launch hostapd, since I have installed a 7.0-BETA4. The following error is displayed: ath0: IEEE 802.11 Fetching hardware channel/rate support not supported. Hereunder is a complete typescript: ---------- # ifconfig ath0 inet 192.168.4.128 netmask 255.255.255.0 ssid freebsdap mod= e 11g mediaopt hostap Dec 22 18:02:35 bsdap kernel: ath0: ath_chan_set: unable to reset channel 6= (2437 Mhz, flags 0x490 hal flags 0x150) # ifconfig ath0 ath0: flags=3D8843 metric 0 mtu 1500 ether 00:0f:b5:86:ba:73 inet 192.168.4.128 netmask 0xffffff00 broadcast 192.168.4.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:0f:b5:86:ba:73 authmode OPEN privacy OFF txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst dtimperiod 1 # hostapd -dd /etc/hostapd.conf Configuration file: /etc/hostapd.conf ctrl_interface_group=3D0 (from group name 'wheel') bsd_set_iface_flags: dev_up=3D0 BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) ath0: IEEE 802.11 Fetching hardware channel/rate support not supported. Flushing old station entries bsd_sta_deauth: addr=3Dff:ff:ff:ff:ff:ff reason_code=3D3 Deauthenticate all stations bsd_set_privacy: enabled=3D0 bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D0 bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D1 bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D2 bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D3 bsd_get_ssid: ssid=3D"freebsdap" Using interface ath0 with hwaddr 00:0f:b5:86:ba:73 and ssid 'freebsdap' SSID - hexdump_ascii(len=3D9): 66 72 65 65 62 73 64 61 70 freebsdap =20 PSK (ASCII passphrase) - hexdump_ascii(len=3D8): XX XX XX XX XX XX XX XX [removed] PSK (from passphrase) - hexdump(len=3D32): xx xx xx xx xx [removed] bsd_set_ieee8021x: enabled=3D1 bsd_configure_wpa: group key cipher=3DTKIP (1) bsd_configure_wpa: pairwise key ciphers=3D0x2 ---------- and at this point the machine is no more responsive. Is this a known problem? I have found some similar messages in the madwifi archives, but no freeze, and nothing related to FreeBSD. Best regards, --=20 Th. Thomas. --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHbUqoc95pjMcUBaIRAnmMAJ0T/4hODi6A8g5CSyLpiWjKZkJDRQCfYoh7 l3qWB1TK5dgjipDvKRT/plA= =imLk -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 18:23:40 2007 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 25C6316A421 for ; Sat, 22 Dec 2007 18:23:40 +0000 (UTC) (envelope-from maf@splintered.net) Received: from sv1.eng.oar.net (sv1.eng.oar.net [192.148.251.86]) by mx1.freebsd.org (Postfix) with SMTP id D7E4C13C448 for ; Sat, 22 Dec 2007 18:23:39 +0000 (UTC) (envelope-from maf@splintered.net) Received: (qmail 11183 invoked from network); 22 Dec 2007 18:23:38 -0000 Received: from dev1.eng.oar.net (HELO ?127.0.0.1?) (192.148.251.71) by sv1.eng.oar.net with SMTP; 22 Dec 2007 18:23:38 -0000 In-Reply-To: <20071222070318.GT57756@deviant.kiev.zoral.com.ua> References: <20071217102433.GQ25053@tnn.dglawrence.com> <20071220011626.U928@besplex.bde.org> <814DB7A9-E64F-4BCA-A502-AB5A6E0297D3@eng.oar.net> <20071219171331.GH25053@tnn.dglawrence.com> <20071221200810.GY16982@elvis.mu.org> <20071221234347.GS25053@tnn.dglawrence.com> <6D374B4C-0D98-4916-A762-7A85912B3058@splintered.net> <20071222053648.GQ57756@deviant.kiev.zoral.com.ua> <3647BB78-BA10-432B-A52B-04E402E155CC@splintered.net> <20071222070318.GT57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Fullmer Date: Sat, 22 Dec 2007 13:23:22 -0500 To: Kostik Belousov X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 18:23:40 -0000 This appears to work. No packet loss with vfs.numvnodes at 32132, 16K PPS test with 1 million packets. I'll run some additional tests bringing vfs.numvnodes closer to kern.maxvnodes. On Dec 22, 2007, at 2:03 AM, Kostik Belousov wrote: > > As Bruce Evans noted, there is a vfs_msync() that do almost the same > traversal of the vnodes. It was missed in the previous patch. Try > this one. > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index 3c2e1ed..6515d6a 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -2967,7 +2967,9 @@ vfs_msync(struct mount *mp, int flags) > { > struct vnode *vp, *mvp; > struct vm_object *obj; > + int yield_count; > > + yield_count = 0; > MNT_ILOCK(mp); > MNT_VNODE_FOREACH(vp, mp, mvp) { > VI_LOCK(vp); > @@ -2996,6 +2998,12 @@ vfs_msync(struct mount *mp, int flags) > MNT_ILOCK(mp); > } else > VI_UNLOCK(vp); > + if (yield_count++ == 500) { > + MNT_IUNLOCK(mp); > + yield_count = 0; > + uio_yield(); > + MNT_ILOCK(mp); > + } > } > MNT_IUNLOCK(mp); > } > diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c > index cbccc62..9e8b887 100644 > --- a/sys/ufs/ffs/ffs_vfsops.c > +++ b/sys/ufs/ffs/ffs_vfsops.c > @@ -1182,6 +1182,7 @@ ffs_sync(mp, waitfor, td) > int secondary_accwrites; > int softdep_deps; > int softdep_accdeps; > + int yield_count; > struct bufobj *bo; > > fs = ump->um_fs; > @@ -1216,6 +1217,7 @@ loop: > softdep_get_depcounts(mp, &softdep_deps, &softdep_accdeps); > MNT_ILOCK(mp); > > + yield_count = 0; > MNT_VNODE_FOREACH(vp, mp, mvp) { > /* > * Depend on the mntvnode_slock to keep things stable enough > @@ -1233,6 +1235,12 @@ loop: > (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 && > vp->v_bufobj.bo_dirty.bv_cnt == 0)) { > VI_UNLOCK(vp); > + if (yield_count++ == 500) { > + MNT_IUNLOCK(mp); > + yield_count = 0; > + uio_yield(); > + MNT_ILOCK(mp); > + } > continue; > } > MNT_IUNLOCK(mp); From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 19:05:43 2007 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 A360416A49E for ; Sat, 22 Dec 2007 19:05:43 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 95D7E13C461 for ; Sat, 22 Dec 2007 19:05:43 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: (qmail 6739 invoked from network); 22 Dec 2007 18:39:02 -0000 Received: from marconi.jellydonut.org (HELO localhost) ([216.27.165.148]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Dec 2007 18:39:01 -0000 Received: from plato.localnet (192.168.0.11) by marconi.localnet Message-ID: <476D59B6.4030609@jellydonut.org> Date: Sat, 22 Dec 2007 13:38:46 -0500 From: Michael Proto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Trying to initialize padlock support on Via C7 Eden CPU 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, 22 Dec 2007 19:05:43 -0000 Hello, I purchased a Jetway J7F4K1G2E w/VIA Eden 1.2GHz cpu/motherboard combo (http://e-itx.com/jetway-j7f4k1g2e-mini-itx-motherboard.html) that I'm trying to get working with the FreeBSD padlock driver. Based on what I see from the manufacturer's CPU support list , http://www.jetwaycomputer.com/VIA3.html, I have a C7 Esther processer. It looks like the CPUID for this processor isn't recognized by FreeBSD 6.3-RC1 or 7.0-BETA3. GENERIC on 7.0-BETA3 detects the CPU as follows: CPU: VIA/IDT Unknown (1200.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 Features=0xa7c9baff Features2=0x4181 ... padlock0: No ACE support. The other list posts I've seen for the C7 reference a 0x6a9 Id with a stepping of 9. I added a small patch to /sys/i386/i386/identcpu.c to detect this Id: --- sys/i386/i386/identcpu.c.old 2007-05-29 19:39:18.000000000 +0000 +++ sys/i386/i386/identcpu.c 2007-12-21 13:54:57.000000000 +0000 @@ -585,6 +585,8 @@ goto via_common; case 0x6a0: strcpy(cpu_model, "VIA C7 Esther"); + case 0x6d0: + strcpy(cpu_model, "VIA C7 Esther"); via_common: do_cpuid(0xc0000000, regs); i = regs[0]; And now GENERIC sees the Esther along with the supported crypto functions, but padlock doesn't initialize: CPU: VIA C7 Esther+RNG+AES+AES-CTR+SHA1+SHA256+RSA (1200.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 Features=0xa7c9baff Features2=0x4181 ... padlock0: No ACE support. Unfortunately I'm at a loss on where to go next. I looked through initcpu.c and everything in /sys/crypto/via/ but I don't grok C so I don't really know what I'm looking at. Any ideas on how to get this CPU supported with padlock would be much appreciated. Thanks and happy holidays, -Michael Proto Below is a verbose 7.0-BETA3 dmesg.boot (with my above identcpu.c patch applied) Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-BETA3 #0: Sat Dec 22 07:39:36 UTC 2007 root@tester.localnet:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0d6e000. Preloaded elf module "/boot/kernel/padlock.ko" at 0xc0d6e19c. Preloaded elf module "/boot/kernel/crypto.ko" at 0xc0d6e248. Preloaded elf module "/boot/kernel/zlib.ko" at 0xc0d6e2f4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0d6e3a0. Calibrating clock(s) ... i8254 clock: 1193579 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1200010302 Hz CPU: VIA C7 Esther+RNG+AES+AES-CTR+SHA1+SHA256+RSA (1200.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 Features=0xa7c9baff Features2=0x4181 real memory = 1055784960 (1006 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000003dce4fff, 1019990016 bytes (249021 pages) avail memory = 1019531264 (972 MB) Table 'FACP' at 0x3eee3080 Table 'APIC' at 0x3eee83c0 MADT: Found table at 0x3eee83c0 MP Configuration Table version 1.4 found at 0xc00f22f0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00f9d30 bios32: Entry = 0xfa1b0 (c00fa1b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xa200 pnpbios: Found PnP BIOS data at 0xc00fac30 pnpbios: Entry = f0000:ac60 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 ACPI: RSDP @ 0x0xf7c40/0x0014 (v 0 CN700 ) ACPI: RSDT @ 0x0x3eee3000/0x002C (v 1 CN700 AWRDACPI 0x42302E31 AWRD 0x00000000) ACPI: FACP @ 0x0x3eee3080/0x0074 (v 1 CN700 AWRDACPI 0x42302E31 AWRD 0x00000000) ACPI: DSDT @ 0x0x3eee3100/0x5281 (v 1 CN700 AWRDACPI 0x00001000 MSFT 0x03000000) ACPI: FACS @ 0x0x3eee0000/0x0040 ACPI: APIC @ 0x0x3eee83c0/0x005A (v 1 CN700 AWRDACPI 0x42302E31 AWRD 0x00000000) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 wlan_amrr: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 io: mem: crypto: null: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Dec 22 2007 07:28:16) npx0: INT 16 interface cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 padlock0: No ACE support. acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000760 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=03141106) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \\_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.PATA.PAPR -> bus 0 dev 15 func 1 acpi0: Power Button (fixed) acpi0: wakeup code va 0xd7e45000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.PCI0.IDE0.VIDE -> bus 0 dev 17 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SAPR -> bus 0 dev 15 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.USB0.SB72 -> bus 0 dev 17 func 2 AcpiOsDerivePciId: \\_SB_.PCI0.USB1.SB73 -> bus 0 dev 17 func 3 AcpiOsDerivePciId: \\_SB_.PCI0.USB2.SB74 -> bus 0 dev 17 func 4 AcpiOsDerivePciId: \\_SB_.PCI0.USB3.U2F0 -> bus 0 dev 16 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.USB4.U2F1 -> bus 0 dev 16 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.USB5.U2F2 -> bus 0 dev 16 func 2 AcpiOsDerivePciId: \\_SB_.PCI0.USB6.U2F3 -> bus 0 dev 16 func 3 AcpiOsDerivePciId: \\_SB_.PCI0.USB7.U2F4 -> bus 0 dev 16 func 4 AcpiOsDerivePciId: \\_SB_.PCI0.VT86.USBC -> bus 0 dev 17 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ede0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 Validation 0 11 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 Validation 0 11 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 Validation 0 10 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 20 N 0 20 Validation 0 20 N 0 20 After Disable 0 255 N 0 20 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 21 N 0 21 Validation 0 21 N 0 21 After Disable 0 255 N 0 21 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 22 N 0 22 Validation 0 22 N 0 22 After Disable 0 255 N 0 22 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 23 N 0 23 Validation 0 23 N 0 23 After Disable 0 255 N 0 23 cpu0: on acpi0 cpu0: switching to generic Cx mode est0: on cpu0 p4tcc0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1106, dev=0x0314, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xf8000000, size 25, enabled found-> vendor=0x1106, dev=0x1314, revid=0x00 domain=0, bus=0, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x2314, revid=0x00 domain=0, bus=0, slot=0, func=2 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x3208, revid=0x00 domain=0, bus=0, slot=0, func=3 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x4314, revid=0x00 domain=0, bus=0, slot=0, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x7314, revid=0x00 domain=0, bus=0, slot=0, func=7 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0xb198, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D3 current D0 found-> vendor=0x10ec, dev=0x8167, revid=0x10 domain=0, bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xf000, size 8, enabled map[14]: type Memory, range 32, base 0xfdfff000, size 8, enabled pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 18 found-> vendor=0x10ec, dev=0x8167, revid=0x10 domain=0, bus=0, slot=11, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xf200, size 8, enabled map[14]: type Memory, range 32, base 0xfdffe000, size 8, enabled pcib0: matched entry for 0.11.INTA pcib0: slot 11 INTA hardwired to IRQ 19 found-> vendor=0x1106, dev=0x3149, revid=0x80 domain=0, bus=0, slot=15, func=0 class=01-04-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled map[24]: type I/O Port, range 32, base 0xf400, size 8, enabled pcib0: matched entry for 0.15.INTB (src \\_SB_.PCI0.ALKA:0) pcib0: slot 15 INTB routed to irq 20 via \\_SB_.PCI0.ALKA found-> vendor=0x1106, dev=0x0571, revid=0x06 domain=0, bus=0, slot=15, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x81 domain=0, bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf900, size 5, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.ALKB:0) pcib0: slot 16 INTA routed to irq 21 via \\_SB_.PCI0.ALKB found-> vendor=0x1106, dev=0x3038, revid=0x81 domain=0, bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf800, size 5, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.ALKB:0) pcib0: slot 16 INTA routed to irq 21 via \\_SB_.PCI0.ALKB found-> vendor=0x1106, dev=0x3038, revid=0x81 domain=0, bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf700, size 5, enabled pcib0: matched entry for 0.16.INTB (src \\_SB_.PCI0.ALKB:0) pcib0: slot 16 INTB routed to irq 21 via \\_SB_.PCI0.ALKB found-> vendor=0x1106, dev=0x3038, revid=0x81 domain=0, bus=0, slot=16, func=3 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf600, size 5, enabled pcib0: matched entry for 0.16.INTB (src \\_SB_.PCI0.ALKB:0) pcib0: slot 16 INTB routed to irq 21 via \\_SB_.PCI0.ALKB found-> vendor=0x1106, dev=0x3104, revid=0x86 domain=0, bus=0, slot=16, func=4 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfdffd000, size 8, enabled pcib0: matched entry for 0.16.INTC (src \\_SB_.PCI0.ALKB:0) pcib0: slot 16 INTC routed to irq 21 via \\_SB_.PCI0.ALKB found-> vendor=0x1106, dev=0x3227, revid=0x00 domain=0, bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfb000000-0xfcffffff pcib1: prefetched decode 0xf4000000-0xf7ffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1106, dev=0x3344, revid=0x01 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xf4000000, size 26, enabled pcib1: requested memory range 0xf4000000-0xf7ffffff: good map[14]: type Memory, range 32, base 0xfb000000, size 24, enabled pcib1: requested memory range 0xfb000000-0xfbffffff: good pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 vgapci0: mem 0xf4000000-0xf7ffffff,0xfb000000-0xfbffffff irq 16 at device 0.0 on pci1 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xf000 re0: port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:30:18:ab:e9:65 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 49 re0: [MPSAFE] re0: [FILTER] re1: Reserved 0x100 bytes for rid 0x10 type 4 at 0xf200 re1: port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: bpf attached re1: Ethernet address: 00:30:18:ab:e9:66 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 50 re1: [MPSAFE] re1: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f,0xf400-0xf4ff irq 20 at device 15.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 51 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x100 bytes for rid 0x24 type 4 at 0xf400 ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xff00 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xfe00 ata2: SATA connect status=00000000 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xfd00 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xfc00 ata3: SATA connect status=00000000 ata3: [MPSAFE] ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 15.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 52 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 53 ata1: [MPSAFE] ata1: [ITHREAD] uhci0: port 0xf900-0xf91f irq 21 at device 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf900 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 54 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xf800-0xf81f irq 21 at device 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf800 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xf700-0xf71f irq 21 at device 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf700 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xf600-0xf61f irq 21 at device 16.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf600 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfdffd000-0xfdffd0ff irq 21 at device 16.4 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfdffd000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] ehci0: Dropped interrupts workaround enabled usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 acpi_tz0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4001 0x4001 0x4001 0x4001 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4001 0x4001 0x4001 0x4001 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 55 sio0: [FILTER] sio1: irq maps: 0x4001 0x4009 0x4001 0x4001 sio1: irq maps: 0x4001 0x4009 0x4001 0x4001 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 sio1: [FILTER] psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 59 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 50000448 hz Timecounter "TSC" frequency 1200010302 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on 8237 chip ad0: setting UDMA100 on 8237 chip ad0: 29312MB at ata0-master UDMA100 ad0: 60032448 sectors [59556C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on 8237 chip acd0: setting UDMA33 on 8237 chip acd0: FAILURE - DEVICE_RESET status=7f error=1 acd0: DVDROM drive at ata0 as slave acd0: read 3445KB/s (8268KB/s), 512KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 19:07:26 2007 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 4E37916A420 for ; Sat, 22 Dec 2007 19:07:26 +0000 (UTC) (envelope-from ota@animenfo.com) Received: from smtp.unitz.ca (mx1.unitz.ca [69.60.224.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE3413C478 for ; Sat, 22 Dec 2007 19:07:25 +0000 (UTC) (envelope-from ota@animenfo.com) Received: from localhost (localhost [127.0.0.1]) by smtp.unitz.ca (Postfix) with ESMTP id 4CA517D24E2; Sat, 22 Dec 2007 14:02:34 -0500 (EST) Received: from smtp.unitz.ca ([127.0.0.1]) by localhost (smtp.unitz.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW-fIqbagmG9; Sat, 22 Dec 2007 14:02:31 -0500 (EST) Received: from unitz.ca (dsl-69-60-252-220.unitz.ca [69.60.252.220]) by smtp.unitz.ca (Postfix) with SMTP id A3CA57D24E4; Sat, 22 Dec 2007 14:02:31 -0500 (EST) Received: by unitz.ca (nbSMTP-1.00) for uid 1001 ota@animenfo.com; Sat, 22 Dec 2007 14:07:34 -0500 (EST) Date: Sat, 22 Dec 2007 14:07:34 -0500 From: User Ota To: Claus Guttesen Message-ID: <20071222190734.GA54222@noah.ota.homelinux.net> References: <200712220531.WAA09277@lariat.net> <20071222090553.GB16381@noah.ota.homelinux.net> 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: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? freenx@deweyonline.com 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, 22 Dec 2007 19:07:26 -0000 On Sat, Dec 22, 2007 at 01:40:00PM +0100, Claus Guttesen wrote: > > > > It appears, though I'd need to instrument the code more to be sure, > > > > that the slowdown is coming from file I/O. Could it be that there > > > > less concurrency or more overhead in FreeBSD file operations than > > > > there is in Linux? Even with SoftUpdates turned on, the cache > > > > volume mounted with -noatime, and aufs (which uses kqueues -- a > > > > FreeBSD invention -- to optimize multithreaded disk access), the > > > > benchmark shows FreeBSD losing out. Why? > > > > > > I have noticed an entry in GENERIC called > > > > > > device cpufreq > > > > > > Could this have any influence on the performance (on FreeBSD)? > > > > > > I saw this device late in the 7.0 release-process and I since I'm > > > accustomed to comment out any devices and options I don't need I have > > > commented this out as well. So I haven't performed any tests with and > > > without this device. > > > > > > > Cpufreq is for CPU frequency scaling. In the linux world, the cpufreq > > daemon allows you to control your cpu speed and voltage using power > > profiles and such, which makes it a definite power saving tool for > > laptops. The cpufreq driver is already included with the Linux kernel, > > so I'm going to assume that they've just implemented the cpufreq driver > > in the kernel recently :) > > > > If enabled, it probably would have an impact on performance, however I > > have lost the ability to test such a function since my laptop decides > > not to POST anymore. > > Yes, I did figure out what the purpose of this device was. :-) My > point was that this could lead to lower benchmarks on servers if > GENERIC is used. > > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare > _______________________________________________ > 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" Oh, yeah, I see what you mean now. We have GENERIC and SMP kernel configs, with the cpufreq driver now, there should be like a LAPTOP kernel config file with laptop-specific options :P Once I get my laptop working again, though, I'll try testing it out when 7.0-RELEASE comes about. Russell Doucette From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 19:34:18 2007 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 6E84116A419 for ; Sat, 22 Dec 2007 19:34:18 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E28413C455 for ; Sat, 22 Dec 2007 19:34:17 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J6A6o-0008WV-69 for freebsd-stable@freebsd.org; Sat, 22 Dec 2007 19:34:06 +0000 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 19:34:06 +0000 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 19:34:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Joshua Coombs Date: Sat, 22 Dec 2007 14:33:51 -0500 Lines: 23 Message-ID: References: <200712201706.lBKH6fwn067680@lurza.secnetix.de> <476ABD93.3080707@brianwhalen.net> <476CFC45.40107@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <476CFC45.40107@gmx.de> Sender: news Subject: Re: FreeBSD 7 on old SMP server? 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, 22 Dec 2007 19:34:18 -0000 Dominic Fandrey wrote: > Why don't you just do the buildworld on another machine? As I don't use the machine as a primary workstation at the moment, it doesn't really matter to me if it takes 1 hour or 3 months, I start the buildworld in a screen'd shell and check on it periodically. When it finishes, I set aside 10 to 20 minutes to do an installworld/kernel & mergemaster via serial console, 'just in case.' The closest it gets to annoying is when I start a buildworld based on a new security fix, and 3 days in the fix is revised. : ) And Oliver, you were correct, omitting -pipe didn't allow a buildworld to finish with 448MB ram + swap. Guess I get to repartition after all. My new plan is going to be sourcing a Gigabyte I-RAM, putting 4GB on it, and wiring up an external power supply for it. That plus an SATA to IDE adapter from NewEgg should let me run the I-RAM on my empty ATA controller, giving me 4GB of swap running as fast as the machine can take it. Depending on how it behaves, I may track down a 2MB ISA VGA card again and throw KDE4 on it just to be truly insane. They say it's much better about memory utilization now... :P Joshua Coombs From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 20:16:26 2007 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 7A45D16A417; Sat, 22 Dec 2007 20:16:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 2441113C455; Sat, 22 Dec 2007 20:16:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J6Ald-000LAK-OO; Sat, 22 Dec 2007 22:16:24 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBMKGE83034471; Sat, 22 Dec 2007 22:16:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBMKGEiI034470; Sat, 22 Dec 2007 22:16:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2007 22:16:13 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20071222201613.GX57756@deviant.kiev.zoral.com.ua> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0k4Rxg87Lb8yV0u3" Content-Disposition: inline In-Reply-To: <20071223032944.G48303@delplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 69ad68b945e79e087f1af101bf3fefec X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1946 [Dec 22 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: "Freebsd-Net@Freebsd. Org" , freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 20:16:26 -0000 --0k4Rxg87Lb8yV0u3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 23, 2007 at 04:08:09AM +1100, Bruce Evans wrote: > On Sat, 22 Dec 2007, Kostik Belousov wrote: > >Yes, rewriting the syncer is the right solution. It probably cannot be d= one > >quickly enough. If the yield workaround provide mitigation for now, it > >shall go in. >=20 > I don't think rewriting the syncer just for this is the right solution. > Rewriting the syncer so that it schedules actual i/o more efficiently > might involve a solution. Better scheduling would probably take more > CPU and increase the problem. I think that we can easily predict what vnode(s) become dirty at the places where we do vn_start_write(). >=20 > Note that MNT_VNODE_FOREACH() is used 17 times, so the yielding fix is > needed in 17 places if it isn't done internally in MNT_VNODE_FOREACH(). > There are 4 places in vfs and 13 places in 6 file systems: >=20 > % ./ufs/ffs/ffs_snapshot.c: MNT_VNODE_FOREACH(xvp, mp, mvp) { > % ./ufs/ffs/ffs_snapshot.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./ufs/ffs/ffs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./ufs/ffs/ffs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./ufs/ufs/ufs_quota.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./ufs/ufs/ufs_quota.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./ufs/ufs/ufs_quota.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./fs/msdosfs/msdosfs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, nvp) { > % ./fs/coda/coda_subr.c: MNT_VNODE_FOREACH(vp, mp, nvp) { > % ./gnu/fs/ext2fs/ext2_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./gnu/fs/ext2fs/ext2_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./kern/vfs_default.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./kern/vfs_subr.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./kern/vfs_subr.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./nfs4client/nfs4_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { > % ./nfsclient/nfs_subs.c: MNT_VNODE_FOREACH(vp, mp, nvp) { > % ./nfsclient/nfs_vfsops.c: MNT_VNODE_FOREACH(vp, mp, mvp) { >=20 > Only file systems that support writing need it (for VOP_SYNC() and for > MNT_RELOAD), else there would be many more places. There would also > be more places if MNT_RELOAD support were not missing for some file > systems. Ok, since you talked about this first :). I already made the following patch, but did not published it since I still did not inspected all callers of MNT_VNODE_FOREACH() for safety of dropping mount interlock. It shall be safe, but better to check. Also, I postponed the check until it was reported that yielding does solve the original problem. diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c index 14acc5b..046af82 100644 --- a/sys/kern/vfs_mount.c +++ b/sys/kern/vfs_mount.c @@ -1994,6 +1994,12 @@ __mnt_vnode_next(struct vnode **mvp, struct mount *m= p) mtx_assert(MNT_MTX(mp), MA_OWNED); =20 KASSERT((*mvp)->v_mount =3D=3D mp, ("marker vnode mount list mismatch")); + if ((*mvp)->v_yield++ =3D=3D 500) { + MNT_IUNLOCK(mp); + (*mvp)->v_yield =3D 0; + uio_yield(); + MNT_ILOCK(mp); + } vp =3D TAILQ_NEXT(*mvp, v_nmntvnodes); while (vp !=3D NULL && vp->v_type =3D=3D VMARKER) vp =3D TAILQ_NEXT(vp, v_nmntvnodes); diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index dc70417..6e3119b 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -131,6 +131,7 @@ struct vnode { struct socket *vu_socket; /* v unix domain net (VSOCK) */ struct cdev *vu_cdev; /* v device (VCHR, VBLK) */ struct fifoinfo *vu_fifoinfo; /* v fifo (VFIFO) */ + int vu_yield; /* yield count (VMARKER) */ } v_un; =20 /* @@ -185,6 +186,7 @@ struct vnode { #define v_socket v_un.vu_socket #define v_rdev v_un.vu_cdev #define v_fifoinfo v_un.vu_fifoinfo +#define v_yield v_un.vu_yield =20 /* XXX: These are temporary to avoid a source sweep at this time */ #define v_object v_bufobj.bo_object --0k4Rxg87Lb8yV0u3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHbXCNC3+MBN1Mb4gRAl8eAJ9DvGYrFBcvBUeaesQfI8K8NZa8CwCfabpZ P1ojIQjyRhEbd8gCeutenLM= =t5ni -----END PGP SIGNATURE----- --0k4Rxg87Lb8yV0u3-- From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 21:46:20 2007 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 05F1D16A417 for ; Sat, 22 Dec 2007 21:46:20 +0000 (UTC) (envelope-from me@che78-3-82-246-30-233.fbx.proxad.net) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id D205213C448 for ; Sat, 22 Dec 2007 21:46:19 +0000 (UTC) (envelope-from me@che78-3-82-246-30-233.fbx.proxad.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by postfix1-g20.free.fr (Postfix) with ESMTP id 6B4822083026 for ; Sat, 22 Dec 2007 22:20:41 +0100 (CET) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 3BC7617F50A for ; Sat, 22 Dec 2007 22:20:39 +0100 (CET) Received: from che78-3-82-246-30-233.fbx.proxad.net (che78-3-82-246-30-233.fbx.proxad.net [82.246.30.233]) by smtp8-g19.free.fr (Postfix) with ESMTP id 1AEEC17F564 for ; Sat, 22 Dec 2007 22:20:38 +0100 (CET) Received: by che78-3-82-246-30-233.fbx.proxad.net (Postfix, from userid 1001) id 9104645232; Sat, 22 Dec 2007 22:20:21 +0100 (CET) Date: Sat, 22 Dec 2007 22:20:21 +0100 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20071222212021.GA72633@pollux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: amsn-0.96_1 does not build 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, 22 Dec 2007 21:46:20 -0000 amsn-0.96_1 does not build because of the following error: ===> Building for amsn-0.96_1 CXX utils/TkCximage/src/TkCximage.cpp.o In file included from utils/TkCximage/src/TkCximage.cpp:11: utils/TkCximage/src/TkCximage.h:23:25: tkPlatDecls.h: No such file or directory gmake: *** [utils/TkCximage/src/TkCximage.cpp.o] Error 1 *** Error code 2 Stop in /usr/ports/net-im/amsn. === My ports tree is up to date (portsnap fetch and update alright). Any idea why this header file is missing ? Thank you in advance for any help. HW -- FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:56:09 UTC 2007 From owner-freebsd-stable@FreeBSD.ORG Sat Dec 22 23:20:37 2007 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 6AE3016A417; Sat, 22 Dec 2007 23:20:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 143A113C44B; Sat, 22 Dec 2007 23:20:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBMNKVRO030159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Dec 2007 10:20:33 +1100 Date: Sun, 23 Dec 2007 10:20:31 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Kostik Belousov In-Reply-To: <20071222201613.GX57756@deviant.kiev.zoral.com.ua> Message-ID: <20071223095314.G1323@delplex.bde.org> References: <20071221234347.GS25053@tnn.dglawrence.com> <20071222050743.GP57756@deviant.kiev.zoral.com.ua> <20071223032944.G48303@delplex.bde.org> <20071222201613.GX57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Freebsd-Net@Freebsd. Org" , freebsd-stable@freebsd.org, Bruce Evans Subject: Re: Packet loss every 30.999 seconds 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, 22 Dec 2007 23:20:37 -0000 On Sat, 22 Dec 2007, Kostik Belousov wrote: > On Sun, Dec 23, 2007 at 04:08:09AM +1100, Bruce Evans wrote: >> On Sat, 22 Dec 2007, Kostik Belousov wrote: >>> Yes, rewriting the syncer is the right solution. It probably cannot be done >>> quickly enough. If the yield workaround provide mitigation for now, it >>> shall go in. >> >> I don't think rewriting the syncer just for this is the right solution. >> Rewriting the syncer so that it schedules actual i/o more efficiently >> might involve a solution. Better scheduling would probably take more >> CPU and increase the problem. > I think that we can easily predict what vnode(s) become dirty at the > places where we do vn_start_write(). This works for writes to regular files at most. There are also reads (for ffs, these set IN_ATIME unless the file system is mounted with noatime) and directory operations. By grepping for IN_CHANGE, I get 78 places in ffs alone where dirtying of the inode occurs or is scheduled to occur (ffs = /sys/ufs). The efficiency of "marking" timestamps, especially for atimes, depends on just setting a flag in normal operation and picking up coalesced settings of the flag later, often at sync time by scanning all vnodes. >> Note that MNT_VNODE_FOREACH() is used 17 times, so the yielding fix is >> needed in 17 places if it isn't done internally in MNT_VNODE_FOREACH(). >> There are 4 places in vfs and 13 places in 6 file systems: >> ... >> >> Only file systems that support writing need it (for VOP_SYNC() and for >> MNT_RELOAD), else there would be many more places. There would also >> be more places if MNT_RELOAD support were not missing for some file >> systems. > > Ok, since you talked about this first :). I already made the following > patch, but did not published it since I still did not inspected all > callers of MNT_VNODE_FOREACH() for safety of dropping mount interlock. > It shall be safe, but better to check. Also, I postponed the check > until it was reported that yielding does solve the original problem. Good. I'd still like to unobfuscate the function call. > diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c > index 14acc5b..046af82 100644 > --- a/sys/kern/vfs_mount.c > +++ b/sys/kern/vfs_mount.c > @@ -1994,6 +1994,12 @@ __mnt_vnode_next(struct vnode **mvp, struct mount *mp) > mtx_assert(MNT_MTX(mp), MA_OWNED); > > KASSERT((*mvp)->v_mount == mp, ("marker vnode mount list mismatch")); > + if ((*mvp)->v_yield++ == 500) { > + MNT_IUNLOCK(mp); > + (*mvp)->v_yield = 0; > + uio_yield(); Another unobfuscation is to not name this uio_yield(). > + MNT_ILOCK(mp); > + } > vp = TAILQ_NEXT(*mvp, v_nmntvnodes); > while (vp != NULL && vp->v_type == VMARKER) > vp = TAILQ_NEXT(vp, v_nmntvnodes); > diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h > index dc70417..6e3119b 100644 > --- a/sys/sys/vnode.h > +++ b/sys/sys/vnode.h > @@ -131,6 +131,7 @@ struct vnode { > struct socket *vu_socket; /* v unix domain net (VSOCK) */ > struct cdev *vu_cdev; /* v device (VCHR, VBLK) */ > struct fifoinfo *vu_fifoinfo; /* v fifo (VFIFO) */ > + int vu_yield; /* yield count (VMARKER) */ > } v_un; > > /* Putting the count in the union seems fragile at best. Even if nothing can access the marker vnode, you need to context-switch its old contents while using it for the count, in case its old contents is used. Vnode- printing routines might still be confused. Bruce