From owner-freebsd-stable@FreeBSD.ORG Sun May 25 07:05:17 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38EEE106566C for ; Sun, 25 May 2008 07:05:17 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id E07F48FC18 for ; Sun, 25 May 2008 07:05:16 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-73-164-48.dsl.telstraclear.net [121.73.164.48]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0K1E006BRX0PO740@smtp3.clear.net.nz>; Sun, 25 May 2008 19:05:15 +1200 (NZST) Date: Sun, 25 May 2008 19:05:13 +1200 From: Mark Kirkwood In-reply-to: <200805231811.01936.jhb@freebsd.org> To: John Baldwin Message-id: <48390FA9.5080503@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7bit References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080419) Cc: Kostik Belousov , freebsd-stable@freebsd.org, James Seward Subject: Re: BTX loader hangs after version info X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 May 2008 07:05:17 -0000 John Baldwin wrote: > > Try this patch. I'm not 100% certain this will fix it as I can't reproduce > the issue, but I think it might help. Specifically, when the boot code makes > a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via > the v86 structure including the eflags register. However, none of the boot > programs actually initialized the v86 structure. Thus, the BIOS routines > would start off running with whatever garbage was in v86.efl when each boot > program started. This meant that we could end up invoking BIOS routines with > interrupts disabled, and I think this might explain a hard hang (if a BIOS > routine was waiting for an interrupt the interrupt would never fire). The > patch fixes all the boot programs to initialize v86 to a better known state. > At the least it sets v86.efl to a sane value (0x202) rather than random. (The > random might have always been 0x0 BTW, not sure on that one.) > > Thanks John, Unfortunately this patch does *not* cure the issue for my old Supermicro P3TDDE, it still hangs just before presenting the menu. I had to boot off the livefs and copy /boot/loader.old -> /boot/loader to get back to being bootable again - but at least the old fella is on a more up-to-date 7-STABLE now :-) Cheers Mark From owner-freebsd-stable@FreeBSD.ORG Sun May 25 08:33:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F041065670; Sun, 25 May 2008 08:33:29 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD8B8FC16; Sun, 25 May 2008 08:33:28 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-73-164-48.dsl.telstraclear.net [121.73.164.48]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0K1F00B2O132WM30@smtp4.clear.net.nz>; Sun, 25 May 2008 20:33:27 +1200 (NZST) Date: Sun, 25 May 2008 20:33:01 +1200 From: Mark Kirkwood In-reply-to: <48390FA9.5080503@paradise.net.nz> To: John Baldwin Message-id: <4839243D.7000700@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7bit References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> User-Agent: Thunderbird 2.0.0.9 (X11/20080419) Cc: freebsd-stable Subject: Re: BTX loader hangs after version info X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 May 2008 08:33:29 -0000 I wrote: > John Baldwin wrote: >> >> Try this patch. I'm not 100% certain this will fix it as I can't >> reproduce >> the issue, but I think it might help. Specifically, when the boot >> code makes >> a v86 call, the loader/boot2/whatever swaps in/out a new set of >> registers via >> the v86 structure including the eflags register. However, none of >> the boot >> programs actually initialized the v86 structure. Thus, the BIOS >> routines >> would start off running with whatever garbage was in v86.efl when >> each boot >> program started. This meant that we could end up invoking BIOS >> routines with >> interrupts disabled, and I think this might explain a hard hang (if a >> BIOS >> routine was waiting for an interrupt the interrupt would never >> fire). The >> patch fixes all the boot programs to initialize v86 to a better known >> state. At the least it sets v86.efl to a sane value (0x202) rather >> than random. (The >> random might have always been 0x0 BTW, not sure on that one.) >> >> > Thanks John, > > Unfortunately this patch does *not* cure the issue for my old > Supermicro P3TDDE, it still hangs just before presenting the menu. I > had to boot off the livefs and copy /boot/loader.old -> /boot/loader > to get back to being bootable again - but at least the old fella is on > a more up-to-date 7-STABLE now :-) Given that the patch *did* cure Peters Tyan S2720, I'll double check I didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, whereas the P3TDDE has Award BIOS). Anyway, I'll double check and report back... Cheers Mark From owner-freebsd-stable@FreeBSD.ORG Sun May 25 08:55:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39441106564A for ; Sun, 25 May 2008 08:55:37 +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 AFF5C8FC1A for ; Sun, 25 May 2008 08:55:36 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 25206 invoked from network); 25 May 2008 03:55:36 -0500 Received: from 124-171-240-53.dyn.iinet.net.au (HELO ayiin) (124.171.240.53) by sigma.octantis.com.au with (DHE-RSA-AES128-SHA encrypted) SMTP; 25 May 2008 03:55:35 -0500 Date: Sun, 25 May 2008 18:55:03 +1000 From: Norberto Meijome To: FreeBSD Stable ML Message-ID: <20080525185503.7642e736@ayiin> In-Reply-To: <4836660D.1070801@icyb.net.ua> References: <48351A70.8090402@icyb.net.ua> <4836660D.1070801@icyb.net.ua> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Is it possible to create a directory under /dev? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 May 2008 08:55:37 -0000 On Fri, 23 May 2008 09:37:01 +0300 Andriy Gapon wrote: > >> But, by the way, there is a (slightly) more valid reason to want to > >> create a directory under /dev, I recently had it. For one non-standard > >> third-party application I needed to create a link to existing device in > >> a certain subdirectory. I.e.: > >> /dev/subdirX/device -> /dev/deviceX > >> And I couldn't do that. > >> Or maybe link operation for devfs just needs to be taught about creating > >> subdirectories on demand. I don't know. > > > > you can create links with devfs - man devfs.conf > > [...] > > link This action creates a symbolic link named arg that points to > > devname, the name of the device created by devfs(5). > > [..] > > I do know that. > Maybe I wasn't clear enough: "/dev/deviceX" was existing device node and > I needed to create "/dev/subdirX/device" link, where directory > "/dev/subdirX" didn't exist. > Any help on this? Not sure, but like someone mentioned parts of the system create this (geom?) . you can check its code to see how its done. good luck, B _________________________ {Beto|Norberto|Numard} Meijome Commitment is active, not passive. Commitment is doing whatever you can to bring about the desired result. Anything less is half-hearted. 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 May 25 10:31:29 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24A751065671 for ; Sun, 25 May 2008 10:31:29 +0000 (UTC) (envelope-from jille@quis.cx) Received: from istud.quis.cx (ip83-113-174-82.adsl2.versatel.nl [82.174.113.83]) by mx1.freebsd.org (Postfix) with ESMTP id D3BFC8FC1F for ; Sun, 25 May 2008 10:31:28 +0000 (UTC) (envelope-from jille@quis.cx) Received: by istud.quis.cx (Postfix, from userid 100) id 5BFA639820; Sun, 25 May 2008 12:12:20 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on istud.quis.cx X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id 75C813981D; Sun, 25 May 2008 12:12:13 +0200 (CEST) Message-ID: <48393B70.7010405@quis.cx> Date: Sun, 25 May 2008 12:12:00 +0200 From: Jille User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, avg@icyb.net.ua References: <200805231600.m4NG0oWq025982@lurza.secnetix.de> In-Reply-To: <200805231600.m4NG0oWq025982@lurza.secnetix.de> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Is it possible to create a directory under /dev? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 May 2008 10:31:29 -0000 Please note that unionfs still has a few bugs! You will need at least patchset p19 for mounting devfs below/above unionfs mounts. There is also a patchset p20, still experimental, you might want to try it. -- Jille Oliver Fromme schreef: > Andriy Gapon wrote: > > But, by the way, there is a (slightly) more valid reason to want to > > create a directory under /dev, I recently had it. For one non-standard > > third-party application I needed to create a link to existing device in > > a certain subdirectory. I.e.: > > /dev/subdirX/device -> /dev/deviceX > > And I couldn't do that. > > You could create a directory elsewhere and use UNIONFS to > merge it with your existing /dev. I haven't tried this, > but I think it should work. > > # mkdir /mydev > # mount -t unionfs -o below /mydev /dev > # cd /mydev > # mkdir subdirX > # ln -s /dev/deviceX subdirX/device > > The "-o below" option is used so that any modifications on > /dev -- such as creating symlinks -- still happen on the > real /dev, not on /mydev. > > Best regards > Oliver > From owner-freebsd-stable@FreeBSD.ORG Sun May 25 12:24:27 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4517B106566B for ; Sun, 25 May 2008 12:24:27 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57005.mail.re3.yahoo.com (web57005.mail.re3.yahoo.com [66.196.97.109]) by mx1.freebsd.org (Postfix) with SMTP id 05A6F8FC15 for ; Sun, 25 May 2008 12:24:26 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 15804 invoked by uid 60001); 25 May 2008 12:24:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KrM364Ytd/FxxovrV4n3ATqBdTD6KNcbClPodPqrCHi8h+aZ8Kz0M6+dyyATdyR8jedLCxkwgE3lvtXL8lsgALaVyqwCL47e+Wv4sqVQhBRfMASuOYGpErWZYM6cBZYVNGrn3sTAiFtVRSCIgHotEgrBJW3b7QMGqsIBBOLAvz8=; X-YMail-OSG: Fo4aOqQVM1k.jBzpO4qzD2Z3j8fRcicLQTbuQAOKqYE5138GdvY0GaRMRE7baZRKH4xJc7N5Ck1GCTXS4SdvLwJKnSloX32YUMQUNweScFFSsK3qqR.JQXlxIt4- Received: from [165.21.155.68] by web57005.mail.re3.yahoo.com via HTTP; Sun, 25 May 2008 05:24:25 PDT Date: Sun, 25 May 2008 05:24:25 -0700 (PDT) From: Unga To: Chuck Swiger In-Reply-To: <35C9A4DD-3491-4850-92D5-CBE2BE4F814F@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <81954.15280.qm@web57005.mail.re3.yahoo.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: sched_ule performance on single 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: Sun, 25 May 2008 12:24:27 -0000 --- Chuck Swiger wrote: > On May 23, 2008, at 6:37 PM, Unga wrote: > > When open an pdf has two types of scenarios in > FreeBSD: > > 1. When X run as a realtime-prio process, X go mad > and swallow up > > almost all of CPU cycles, making audio hiccups. > > > > 2. When X run as a normal-prio process, X behaves > well and rarely > > gets an audible hiccup. > > > > Why X behave different under different priority > categories? Isn't > > this scheduler related? > > Sure. To generalize, the traditional scheduler goal > for Unix has been > to maximize overall throughput and avoid starvation > of even low- > priority tasks, at the expense of higher and > unpredictable latency. > Using realtime priority means that the kernel is > told to minimize > latency for that process even if it means starving > other processes of > CPU time. > > That is well suited for things like CD/DVD burning > or audio/visual > capture, but as you've experienced yourself, it does > poorly for > heavily client-server oriented stuff like X11's > architecture. > > > I wonder the issue I mentioned, open a pdf while > playback audio, is > > it a issue on Apple Mac OSX? > > Nope. :-) > > > Could somebody give some light here who uses an > Apple Mac OSX on > > this list? > > > > If it is not an issue in Mac OSX, how they have > overcome it then? > > > While both FreeBSD and MacOS X are general-purpose > operating systems, > doing multimedia creation and playback is among the > primary > functionality goals for MacOS X, in much the same > way that FreeBSD > regards providing "robust network services" like > Apache, DNS, email, > databases and so forth. > > Core Audio is probably the biggest user of realtime > thread scheduling > under MacOS X, followed by QuickTime or DVD playback > over Core Video. > These frameworks were designed to handle multimedia > without skipping > by preallocating sensible amounts of buffer space, > and they take > advantage of the Mach kernel and IOKit drivers which > are intended to > support realtime needs. Unlike the traditional BSD > kernels, the Mach > kernel was originally designed with SMP, soft & hard > realtime > scheduling in the kernel. The original userland > threads library which > came with Mach, called CThreads, was largely > responsible for the > design that was abstracted into the portable POSIX > threads model > widely used today. > > After FreeBSD 4, there has been a tremendous amount > of work in the > kernel on fine-grained locking and moving device > drivers from running > in the non-preemptable interrupt context to having > device kernel > threads which can be preempted, and there has also > been a lot of work > on the userland side to improve the C threading > libraries and to > improve multithreaded malloc() performance via > jemalloc, but this is > still ongoing and higher level applications like X11 > programs haven't > had years to adapt and take advantage of these > changes. > > Simple things like auto-tuning the size of the audio > buffers to avoid > or minimize skipping or dropouts isn't really in > place yet with > FreeBSD. Realtime video on FreeBSD is dependent > upon X11, which was > originally designed by a bunch of guys at MIT to be > able to display > lots of xterms or other things involving simple > blits of bits, > possibly over the network, in order to replace the > Andrew window > manager system used by CMU, MIT, IBM, and a few > others. X11 wasn't > designed to do alpha channel (aka transparency), > much less stream a > couple of hundred MB per second of data for realtime > OpenGL texturing > or video. (Although, Composite and GLX have since > been added to X11, > they are extensions rather than core functionality, > and hardware > driver support for GLX is less than perfectly > available, especially > once you start looking at the AMD64/EM64T platform, > rather than 32-bit > x86....) > > There's a 2002 BSDcon paper here, written around the > time of FreeBSD > 5.x's release, which has more details: > > http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/ > Thank you very much for the detailed info. It seems FreeBSD may need two schedulers, one for desktop and one for server, among other things. Kind regards Unga From owner-freebsd-stable@FreeBSD.ORG Sun May 25 14:59:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C89AB1065672 for ; Sun, 25 May 2008 14:59:10 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 6FDC88FC28 for ; Sun, 25 May 2008 14:59:10 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 52312 invoked from network); 25 May 2008 14:59:09 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 25 May 2008 14:59:09 -0000 X-pair-Authenticated: 87.58.145.180 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id m4PEx7M4097102; Sun, 25 May 2008 16:59:07 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id m4PEx7iH097101; Sun, 25 May 2008 16:59:07 +0200 (CEST) (envelope-from pho) Date: Sun, 25 May 2008 16:59:06 +0200 From: Peter Holm To: Mark Kirkwood Message-ID: <20080525145906.GA96904@peter.osted.lan> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4839243D.7000700@paradise.net.nz> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable , John Baldwin Subject: Re: BTX loader hangs after version info X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 May 2008 14:59:10 -0000 On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > I wrote: > >John Baldwin wrote: > >> > >>Try this patch. I'm not 100% certain this will fix it as I can't > >>reproduce > >>the issue, but I think it might help. Specifically, when the boot > >>code makes > >>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>registers via > >>the v86 structure including the eflags register. However, none of > >>the boot > >>programs actually initialized the v86 structure. Thus, the BIOS > >>routines > >>would start off running with whatever garbage was in v86.efl when > >>each boot > >>program started. This meant that we could end up invoking BIOS > >>routines with > >>interrupts disabled, and I think this might explain a hard hang (if a > >>BIOS > >>routine was waiting for an interrupt the interrupt would never > >>fire). The > >>patch fixes all the boot programs to initialize v86 to a better known > >>state. At the least it sets v86.efl to a sane value (0x202) rather > >>than random. (The > >>random might have always been 0x0 BTW, not sure on that one.) > >> > >> > >Thanks John, > > > >Unfortunately this patch does *not* cure the issue for my old > >Supermicro P3TDDE, it still hangs just before presenting the menu. I > >had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >to get back to being bootable again - but at least the old fella is on > >a more up-to-date 7-STABLE now :-) > > Given that the patch *did* cure Peters Tyan S2720, I'll double check I > didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > whereas the P3TDDE has Award BIOS). > > Anyway, I'll double check and report back... > > Cheers > > Mark I now have booted some more with this patch and it would seem that the problem is still there, from time to time! Most of the time I now boot without any problems but once in a while the loader still hangs. I'll try to gather some statistics... -- Peter From owner-freebsd-stable@FreeBSD.ORG Sun May 25 16:05:16 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E03106567E; Sun, 25 May 2008 16:05:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 64C888FC14; Sun, 25 May 2008 16:05:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 3F39F28448; Mon, 26 May 2008 00:05:15 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id DDABCEB9ED4; Mon, 26 May 2008 00:05:14 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id QS1CIu90HtO9; Mon, 26 May 2008 00:05:10 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id B8D52EB427D; Mon, 26 May 2008 00:05:08 +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:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=tTzOailEqJBrL/RhpFK8gWaZyqD1ZrschQQgZQsFUFpM0arGphXcPH96UcPVCVqoK gvHCQpFS/Ez0GXvWeudDQ== Message-ID: <48398E31.1030001@delphij.net> Date: Sun, 25 May 2008 09:05:05 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Gavin Atkinson References: <481560AC.90109@delphij.net> <1209376409.59233.14.camel@buffy.york.ac.uk> <4818BF27.2080209@delphij.net> <200804301544.20802.jhb@freebsd.org> <1209660552.68622.53.camel@buffy.york.ac.uk> <4819F6D3.80104@delphij.net> <1211448313.71119.1.camel@buffy.york.ac.uk> In-Reply-To: <1211448313.71119.1.camel@buffy.york.ac.uk> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , d@delphij.net, John Baldwin Subject: Re: What does system do after "Uptime: "? 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: Sun, 25 May 2008 16:05:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gavin Atkinson wrote: | On Thu, 2008-05-01 at 09:58 -0700, Xin LI wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Gavin Atkinson wrote: |> | FWIW, there have been probably around 10 PRs in in the last few months |> | about this behaviour. I'd vote for it as an errata candidate. |> |> FWIW I have written to re@ indicating some changes I wanted for |> RELENG_7_0 as candidates. Could you please let me know if I have missed |> something important? |> |> http://www.delphij.net/errata-20080430.xml | | Did you get anywhere with this request? PRs are still coming in about | the "hang after Uptime:" issue. | | If the errata candidates were turned down, I think we need to have an | entry in the release notes errata... The latest list is: http://www.delphij.net/errata-20080511.xml And what would be finally made into errata is still under discussion. Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg5jjEACgkQi+vbBBjt66BmUACfUWWd1M3Ribis+YvvhEb78mlS 5LsAoLhcGhxBbpHBzUjVVVgB+M3IAnmM =aI4C -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun May 25 17:16:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC10C1065675 for ; Sun, 25 May 2008 17:16:35 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 9452E8FC1A for ; Sun, 25 May 2008 17:16:35 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 37774 invoked from network); 25 May 2008 17:16:34 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 25 May 2008 17:16:34 -0000 X-pair-Authenticated: 87.58.145.180 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id m4PHGXPs001765; Sun, 25 May 2008 19:16:33 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id m4PHGWAf001764; Sun, 25 May 2008 19:16:32 +0200 (CEST) (envelope-from pho) Date: Sun, 25 May 2008 19:16:32 +0200 From: Peter Holm To: Mark Kirkwood Message-ID: <20080525171632.GA1305@peter.osted.lan> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4839243D.7000700@paradise.net.nz> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable , John Baldwin Subject: Re: BTX loader hangs after version info X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 May 2008 17:16:36 -0000 On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > I wrote: > >John Baldwin wrote: > >> > >>Try this patch. I'm not 100% certain this will fix it as I can't > >>reproduce > >>the issue, but I think it might help. Specifically, when the boot > >>code makes > >>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>registers via > >>the v86 structure including the eflags register. However, none of > >>the boot > >>programs actually initialized the v86 structure. Thus, the BIOS > >>routines > >>would start off running with whatever garbage was in v86.efl when > >>each boot > >>program started. This meant that we could end up invoking BIOS > >>routines with > >>interrupts disabled, and I think this might explain a hard hang (if a > >>BIOS > >>routine was waiting for an interrupt the interrupt would never > >>fire). The > >>patch fixes all the boot programs to initialize v86 to a better known > >>state. At the least it sets v86.efl to a sane value (0x202) rather > >>than random. (The > >>random might have always been 0x0 BTW, not sure on that one.) > >> > >> > >Thanks John, > > > >Unfortunately this patch does *not* cure the issue for my old > >Supermicro P3TDDE, it still hangs just before presenting the menu. I > >had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >to get back to being bootable again - but at least the old fella is on > >a more up-to-date 7-STABLE now :-) > > Given that the patch *did* cure Peters Tyan S2720, I'll double check I > didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > whereas the P3TDDE has Award BIOS). > > Anyway, I'll double check and report back... > > Cheers > > Mark I did 18 boots with and with out John's patch. With the patch I got 6 actual boots and 12 hangs in the loaders progress bar. Without the patch I got 10 boots and 8 hangs. But, my Tyan M/B is old and with known ACPI issues so I'm not sure if this is of much value. Mark, it would be nice if you also observe if a sequence of reboots eventually boots your system. My longest bad streek was 8 reboots. - Peter From owner-freebsd-stable@FreeBSD.ORG Mon May 26 01:49:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7338D1065717; Mon, 26 May 2008 01:49:12 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1078FC1B; Mon, 26 May 2008 01:49:06 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-73-165-252.dsl.telstraclear.net [121.73.165.252]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0K1G0037QD1R6M20@smtp3.clear.net.nz>; Mon, 26 May 2008 13:49:06 +1200 (NZST) Date: Mon, 26 May 2008 13:49:02 +1200 From: Mark Kirkwood In-reply-to: <20080525171632.GA1305@peter.osted.lan> To: Peter Holm Message-id: <483A170E.3090204@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> <20080525171632.GA1305@peter.osted.lan> User-Agent: Thunderbird 2.0.0.9 (X11/20080419) Cc: freebsd-stable , John Baldwin Subject: Re: BTX loader hangs after version info X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2008 01:49:12 -0000 Peter Holm wrote: > On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > >> I wrote: >> >>> John Baldwin wrote: >>> >>>> Try this patch. I'm not 100% certain this will fix it as I can't >>>> reproduce >>>> the issue, but I think it might help. Specifically, when the boot >>>> code makes >>>> a v86 call, the loader/boot2/whatever swaps in/out a new set of >>>> registers via >>>> the v86 structure including the eflags register. However, none of >>>> the boot >>>> programs actually initialized the v86 structure. Thus, the BIOS >>>> routines >>>> would start off running with whatever garbage was in v86.efl when >>>> each boot >>>> program started. This meant that we could end up invoking BIOS >>>> routines with >>>> interrupts disabled, and I think this might explain a hard hang (if a >>>> BIOS >>>> routine was waiting for an interrupt the interrupt would never >>>> fire). The >>>> patch fixes all the boot programs to initialize v86 to a better known >>>> state. At the least it sets v86.efl to a sane value (0x202) rather >>>> than random. (The >>>> random might have always been 0x0 BTW, not sure on that one.) >>>> >>>> >>>> >>> Thanks John, >>> >>> Unfortunately this patch does *not* cure the issue for my old >>> Supermicro P3TDDE, it still hangs just before presenting the menu. I >>> had to boot off the livefs and copy /boot/loader.old -> /boot/loader >>> to get back to being bootable again - but at least the old fella is on >>> a more up-to-date 7-STABLE now :-) >>> >> Given that the patch *did* cure Peters Tyan S2720, I'll double check I >> didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - >> same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, >> whereas the P3TDDE has Award BIOS). >> >> Anyway, I'll double check and report back... >> >> Cheers >> >> Mark >> > > I did 18 boots with and with out John's patch. With the patch I got 6 > actual boots and 12 hangs in the loaders progress bar. > > Without the patch I got 10 boots and 8 hangs. > > But, my Tyan M/B is old and with known ACPI issues so I'm not sure if > this is of much value. > > Mark, it would be nice if you also observe if a sequence of reboots > eventually boots your system. My longest bad streek was 8 reboots. > > Ok, will do. Incidentally, checking showed that the patch *was* correctly applied. I'll report back in several reboots :-) Mark From owner-freebsd-stable@FreeBSD.ORG Mon May 26 02:23:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD4711065676; Mon, 26 May 2008 02:23:35 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 648E98FC13; Mon, 26 May 2008 02:23:35 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-73-165-252.dsl.telstraclear.net [121.73.165.252]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0K1G00HROEMNO210@smtp3.clear.net.nz>; Mon, 26 May 2008 14:23:12 +1200 (NZST) Date: Mon, 26 May 2008 14:23:11 +1200 From: Mark Kirkwood In-reply-to: <20080525171632.GA1305@peter.osted.lan> To: Peter Holm Message-id: <483A1F0F.1060502@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> <20080525171632.GA1305@peter.osted.lan> User-Agent: Thunderbird 2.0.0.9 (X11/20080419) Cc: freebsd-stable , John Baldwin Subject: Re: BTX loader hangs after version info X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2008 02:23:35 -0000 Peter Holm wrote: > On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > >> I wrote: >> >>> John Baldwin wrote: >>> >>>> Try this patch. I'm not 100% certain this will fix it as I can't >>>> reproduce >>>> the issue, but I think it might help. Specifically, when the boot >>>> code makes >>>> a v86 call, the loader/boot2/whatever swaps in/out a new set of >>>> registers via >>>> the v86 structure including the eflags register. However, none of >>>> the boot >>>> programs actually initialized the v86 structure. Thus, the BIOS >>>> routines >>>> would start off running with whatever garbage was in v86.efl when >>>> each boot >>>> program started. This meant that we could end up invoking BIOS >>>> routines with >>>> interrupts disabled, and I think this might explain a hard hang (if a >>>> BIOS >>>> routine was waiting for an interrupt the interrupt would never >>>> fire). The >>>> patch fixes all the boot programs to initialize v86 to a better known >>>> state. At the least it sets v86.efl to a sane value (0x202) rather >>>> than random. (The >>>> random might have always been 0x0 BTW, not sure on that one.) >>>> >>>> >>>> >>> Thanks John, >>> >>> Unfortunately this patch does *not* cure the issue for my old >>> Supermicro P3TDDE, it still hangs just before presenting the menu. I >>> had to boot off the livefs and copy /boot/loader.old -> /boot/loader >>> to get back to being bootable again - but at least the old fella is on >>> a more up-to-date 7-STABLE now :-) >>> >> Given that the patch *did* cure Peters Tyan S2720, I'll double check I >> didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - >> same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, >> whereas the P3TDDE has Award BIOS). >> >> Anyway, I'll double check and report back... >> >> Cheers >> >> Mark >> > > I did 18 boots with and with out John's patch. With the patch I got 6 > actual boots and 12 hangs in the loaders progress bar. > > Without the patch I got 10 boots and 8 hangs. > > But, my Tyan M/B is old and with known ACPI issues so I'm not sure if > this is of much value. > > Mark, it would be nice if you also observe if a sequence of reboots > eventually boots your system. My longest bad streek was 8 reboots. > > Yeah, I see the same thing - with John's patch applied, out of 9 reboots I got 7 hangs and 2 actual boots. (didn't try without the patch). Mark From owner-freebsd-stable@FreeBSD.ORG Mon May 26 02:52:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DA9C106566C for ; Mon, 26 May 2008 02:52:08 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id C7EC48FC1A for ; Mon, 26 May 2008 02:52:07 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so367820uge.37 for ; Sun, 25 May 2008 19:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=fJbLVuZ8KHzrCc42HNFlFVjqeWng8JAs9+bWj0l1W24=; b=r0A2cOreQyobnlb+StrHgReE41mNuU34AiYYYQPfJeqzwX5GIUVnY2GNDfp9ZdxBM44Ds4LJhvPoRICYsMqMLYAxiiWnegFQyZlN4QYyLovyk9Kom+VKqkELQy2oKFNU6qBcTkprp8oN+g72xyKjGCYuszRlJEEoXA+3ed0aaFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=IEAusSLSp69WEO75sxVQia0LCzugjfJgdwPldWC3ARungQsDQ3VWIB/3K73l/Yv5mL4z7b8/WDqHTYJa9c/Rrl8fK5Z57MTF3dqH07ock/gUzbVayzYNB6bzCq6FER5qkjBQQQQNDobNVtslHudAfJsp6apbC/bDag7iOr7wxHo= Received: by 10.67.115.6 with SMTP id s6mr1584683ugm.71.1211770326246; Sun, 25 May 2008 19:52:06 -0700 (PDT) Received: by 10.67.98.5 with HTTP; Sun, 25 May 2008 19:52:06 -0700 (PDT) Message-ID: Date: Sun, 25 May 2008 23:52:06 -0300 From: "Carlos A. M. dos Santos" To: "FreeBSD Stable" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_13508_33435167.1211770326242" Subject: Why does sysinstall still limits cylinders to 65535? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2008 02:52:08 -0000 ------=_Part_13508_33435167.1211770326242 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I have been struglling with sysinstall, attempting to make it handle the geometry of some large SATA drives. After a lot of effort I decided to stop suffering and modified the program in order to circumvent the outdated limit of 65535 cylinders (see attached patch). I'm thinking about submitting a PR with a change request but I'd like to get some additional opinions first. I did not test it in "batch" mode, so it would be great if any kind soul did this. Thanks in advance for your comments and/or suggestions. -- Carlos A. M. dos Santos ------=_Part_13508_33435167.1211770326242 Content-Type: application/octet-stream; name=sysinstall-64kcyl.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_fgogr7zc0 Content-Disposition: attachment; filename=sysinstall-64kcyl.diff ZGlmZiAtZHVyUCBzeXNpbnN0YWxsLm9yaWcvZGlza3MuYyBzeXNpbnN0YWxsL2Rpc2tzLmMKLS0t IHN5c2luc3RhbGwub3JpZy9kaXNrcy5jCTIwMDgtMDItMDEgMTg6Mjg6NDQuMDAwMDAwMDAwIC0w MjAwCisrKyBzeXNpbnN0YWxsL2Rpc2tzLmMJMjAwOC0wNS0yNSAyMzo0MzozNi4wMDAwMDAwMDAg LTAzMDAKQEAgLTEwNiw2ICsxMDYsNDcgQEAKIHN0YXRpYyBkYWRkcl90IFRvdGFsOwogCiBzdGF0 aWMgdm9pZAorY2hlY2tfZ2VvbWV0cnkoRGlzayAqZCkKK3sKKyAgICBpbnQgc2c7CisKKyNpZmRl ZiBQQzk4CisgICAgaWYgKGQtPmJpb3NfY3lsID49IDY1NTM2IHx8IGQtPmJpb3NfaGQgPiAyNTYg fHwgZC0+Ymlvc19zZWN0ID49IDI1NikKKyNlbHNlCisgICAgaWYgKGQtPmJpb3NfY3lsID4gNjU1 MzYgfHwgZC0+Ymlvc19oZCA+IDI1NiB8fCBkLT5iaW9zX3NlY3QgPj0gNjQpCisjZW5kaWYKKyAg ICB7CisJZGlhbG9nX2NsZWFyX25vcmVmcmVzaCgpOworCXNnID0gbXNnWWVzTm8oIldBUk5JTkc6 ICBJdCBpcyBzYWZlIHRvIHVzZSBhIGdlb21ldHJ5IG9mICVsdS8lbHUvJWx1IGZvciAlcyBvblxu IgorCQkgICAgICAiY29tcHV0ZXJzIHdpdGggbW9kZXJuIEJJT1MgdmVyc2lvbnMuICBJZiB0aGlz IGRpc2sgaXMgdG8gYmUgdXNlZFxuIgorCQkgICAgICAib24gcmF0aGVyIG9sZCBtYWNoaW5lcywg aG93ZXZlciwgaXQgaXMgcmVjb21tZW5kZWQgdG8gZW5zdXJlIHRoYXRcbiIKKwkJICAgICAgIml0 IGRvZXMgbm90IGhhdmUgbW9yZSB0aGFuIDY1NTM1IGN5bGluZGVycywgb3IgbW9yZSB0aGFuIDI1 NSBoZWFkc1xuIgorCQkgICAgICAib3IgbW9yZSB0aGFuICIKKyNpZmRlZiBQQzk4CisJCSAgICAg ICIyNTUiCisjZWxzZQorCQkgICAgICAiNjMiCisjZW5kaWYKKwkJICAgICAgIiBzZWN0b3JzIHBl ciB0cmFjay5cbiIKKwkJICAgICAgIlxuIgorCQkgICAgICAiV291bGQgeW91IGxpa2UgdGhhdCB0 byBrZWVwIHVzaW5nIHRoZSBjdXJyZW50IGdlb21ldHJ5P1xuIiwKKwkJICAgICAgZC0+Ymlvc19j eWwsIGQtPmJpb3NfaGQsIGQtPmJpb3Nfc2VjdCwgZC0+bmFtZSk7CisJaWYgKHNnID09IDEpIHsK KwkgICAgU2FuaXRpemVfQmlvc19HZW9tKGQpOworCSAgICBtc2dDb25maXJtKCJBIGdlb21ldHJ5 IG9mICVsdS8lbHUvJWx1IHdhcyBjYWxjdWxhdGVkIGZvciAlcy5cbiIKKwkJICAgICAgICJcbiIK KwkJICAgICAgICJJZiB5b3UgYXJlIG5vdCBzdXJlIGFib3V0IHRoaXMsIHBsZWFzZSBjb25zdWx0 IHRoZSBIYXJkd2FyZSBHdWlkZVxuIgorCQkgICAgICAgImluIHRoZSBEb2N1bWVudGF0aW9uIHN1 Ym1lbnUgb3IgdXNlIHRoZSAoRyllb21ldHJ5IGNvbW1hbmQgdG9cbiIKKwkJICAgICAgICJjaGFu Z2UgaXQuICBSZW1lbWJlcjogeW91IG5lZWQgdG8gZW50ZXIgd2hhdGV2ZXIgeW91ciBCSU9TIHRo aW5rc1xuIgorCQkgICAgICAgInRoZSBnZW9tZXRyeSBpcyEgIEZvciBJREUsIGl0J3Mgd2hhdCB5 b3Ugd2VyZSB0b2xkIGluIHRoZSBCSU9TXG4iCisJCSAgICAgICAic2V0dXAuICBGb3IgU0NTSSwg aXQncyB0aGUgdHJhbnNsYXRpb24gbW9kZSB5b3VyIGNvbnRyb2xsZXIgaXNcbiIKKwkJICAgICAg ICJ1c2luZy4gIERvIE5PVCB1c2UgYSBgYHBoeXNpY2FsIGdlb21ldHJ5JycuXG4iLAorCQkgICAg ICAgZC0+Ymlvc19jeWwsIGQtPmJpb3NfaGQsIGQtPmJpb3Nfc2VjdCwgZC0+bmFtZSk7CisJfQor ICAgIH0KK30KKworc3RhdGljIHZvaWQKIHByaW50X2NodW5rcyhEaXNrICpkLCBpbnQgdSkKIHsK ICAgICBpbnQgcm93OwpAQCAtMTE5LDI0ICsxNjAsNiBAQAogICAgIFRvdGFsID0gMDsKICAgICBm b3IgKGkgPSAwOyBjaHVua19pbmZvW2ldOyBpKyspCiAJVG90YWwgKz0gY2h1bmtfaW5mb1tpXS0+ c2l6ZTsKLSNpZmRlZiBQQzk4Ci0gICAgaWYgKGQtPmJpb3NfY3lsID49IDY1NTM2IHx8IGQtPmJp b3NfaGQgPiAyNTYgfHwgZC0+Ymlvc19zZWN0ID49IDI1NikgewotI2Vsc2UKLSAgICBpZiAoZC0+ Ymlvc19jeWwgPiA2NTUzNiB8fCBkLT5iaW9zX2hkID4gMjU2IHx8IGQtPmJpb3Nfc2VjdCA+PSA2 NCkgewotI2VuZGlmCi0JZGlhbG9nX2NsZWFyX25vcmVmcmVzaCgpOwotCW1zZ0NvbmZpcm0oIldB Uk5JTkc6ICBBIGdlb21ldHJ5IG9mICVsdS8lbHUvJWx1IGZvciAlcyBpcyBpbmNvcnJlY3QuICBV c2luZ1xuIgotCQkgICAiYSBtb3JlIGxpa2VseSBnZW9tZXRyeS4gIElmIHRoaXMgZ2VvbWV0cnkg aXMgaW5jb3JyZWN0IG9yIHlvdVxuIgotCQkgICAiYXJlIHVuc3VyZSBhcyB0byB3aGV0aGVyIG9y IG5vdCBpdCdzIGNvcnJlY3QsIHBsZWFzZSBjb25zdWx0XG4iCi0JCSAgICJ0aGUgSGFyZHdhcmUg R3VpZGUgaW4gdGhlIERvY3VtZW50YXRpb24gc3VibWVudSBvciB1c2UgdGhlXG4iCi0JCSAgICIo Ryllb21ldHJ5IGNvbW1hbmQgdG8gY2hhbmdlIGl0IG5vdy5cblxuIgotCQkgICAiUmVtZW1iZXI6 IHlvdSBuZWVkIHRvIGVudGVyIHdoYXRldmVyIHlvdXIgQklPUyB0aGlua3MgdGhlXG4iCi0JCSAg ICJnZW9tZXRyeSBpcyEgIEZvciBJREUsIGl0J3Mgd2hhdCB5b3Ugd2VyZSB0b2xkIGluIHRoZSBC SU9TXG4iCi0JCSAgICJzZXR1cC4gRm9yIFNDU0ksIGl0J3MgdGhlIHRyYW5zbGF0aW9uIG1vZGUg eW91ciBjb250cm9sbGVyIGlzXG4iCi0JCSAgICJ1c2luZy4gIERvIE5PVCB1c2UgYSBgYHBoeXNp Y2FsIGdlb21ldHJ5JycuIiwKLQkgIGQtPmJpb3NfY3lsLCBkLT5iaW9zX2hkLCBkLT5iaW9zX3Nl Y3QsIGQtPm5hbWUpOwotCVNhbml0aXplX0Jpb3NfR2VvbShkKTsKLSAgICB9CiAgICAgYXR0cnNl dChBX05PUk1BTCk7CiAgICAgbXZhZGRzdHIoMCwgMCwgIkRpc2sgbmFtZTpcdCIpOwogICAgIGNs cnRvYm90KCk7CkBAIC0zNDEsNiArMzY0LDkgQEAKICAgICAvKiBTZXQgdXAgdGhlIGNodW5rIGFy cmF5ICovCiAgICAgcmVjb3JkX2NodW5rcyhkKTsKIAorICAgIC8qIEdpdmUgdGhlIHVzZXIgYSBj aGFuY2UgdG8gc2FuaXRpemUgdGhlIGRpc2sgZ2VvbWV0cnksIGlmIG5lY2Vzc2FyeSAqLworICAg IGNoZWNrX2dlb21ldHJ5KGQpOworCiAgICAgd2hpbGUgKGNodW5raW5nKSB7CiAJY2hhciAqdmFs LCBnZW9tZXRyeVs4MF07CiAJICAgIApAQCAtOTE2LDIxICs5NDIsMjQgQEAKICAgICByZWNvcmRf Y2h1bmtzKGQpOwogICAgIGNwID0gdmFyaWFibGVfZ2V0KFZBUl9HRU9NRVRSWSk7CiAgICAgaWYg KGNwKSB7Ci0JbXNnRGVidWcoIlNldHRpbmcgZ2VvbWV0cnkgZnJvbSBzY3JpcHQgdG86ICVzXG4i LCBjcCk7Ci0JZC0+Ymlvc19jeWwgPSBzdHJ0b2woY3AsICZjcCwgMCk7Ci0JZC0+Ymlvc19oZCA9 IHN0cnRvbChjcCArIDEsICZjcCwgMCk7Ci0JZC0+Ymlvc19zZWN0ID0gc3RydG9sKGNwICsgMSwg MCwgMCk7Ci0gICAgfSBlbHNlIHsKKwlpZiAoIXN0cmNhc2VjbXAoY3AsICJzYW5lIikpIHsKICNp ZmRlZiBQQzk4Ci0JaWYgKGQtPmJpb3NfY3lsID49IDY1NTM2IHx8IGQtPmJpb3NfaGQgPiAyNTYg fHwgZC0+Ymlvc19zZWN0ID49IDI1NikgeworCSAgICBpZiAoZC0+Ymlvc19jeWwgPj0gNjU1MzYg fHwgZC0+Ymlvc19oZCA+IDI1NiB8fCBkLT5iaW9zX3NlY3QgPj0gMjU2KQogI2Vsc2UKLQlpZiAo ZC0+Ymlvc19jeWwgPiA2NTUzNiB8fCBkLT5iaW9zX2hkID4gMjU2IHx8IGQtPmJpb3Nfc2VjdCA+ PSA2NCkgeworCSAgICBpZiAoZC0+Ymlvc19jeWwgPiA2NTUzNiB8fCBkLT5iaW9zX2hkID4gMjU2 IHx8IGQtPmJpb3Nfc2VjdCA+PSA2NCkKICNlbmRpZgotCSAgICBtc2dEZWJ1ZygiV2FybmluZzog IEEgZ2VvbWV0cnkgb2YgJWx1LyVsdS8lbHUgZm9yICVzIGlzIGluY29ycmVjdC5cbiIsCi0JCWQt PmJpb3NfY3lsLCBkLT5iaW9zX2hkLCBkLT5iaW9zX3NlY3QsIGQtPm5hbWUpOwotCSAgICBTYW5p dGl6ZV9CaW9zX0dlb20oZCk7Ci0JICAgIG1zZ0RlYnVnKCJTYW5pdGl6ZWQgZ2VvbWV0cnkgZm9y ICVzIGlzICVsdS8lbHUvJWx1LlxuIiwKLQkJZC0+bmFtZSwgZC0+Ymlvc19jeWwsIGQtPmJpb3Nf aGQsIGQtPmJpb3Nfc2VjdCk7CisJICAgIHsKKwkJbXNnRGVidWcoIldhcm5pbmc6ICBBIGdlb21l dHJ5IG9mICVsdS8lbHUvJWx1IGZvciAlcyBpcyBpbmNvcnJlY3QuXG4iLAorCQkgICAgZC0+Ymlv c19jeWwsIGQtPmJpb3NfaGQsIGQtPmJpb3Nfc2VjdCwgZC0+bmFtZSk7CisJCVNhbml0aXplX0Jp b3NfR2VvbShkKTsKKwkJbXNnRGVidWcoIlNhbml0aXplZCBnZW9tZXRyeSBmb3IgJXMgaXMgJWx1 LyVsdS8lbHUuXG4iLAorCQkgICAgZC0+bmFtZSwgZC0+Ymlvc19jeWwsIGQtPmJpb3NfaGQsIGQt PmJpb3Nfc2VjdCk7CisJICAgIH0KKwl9IGVsc2UgeworCSAgICBtc2dEZWJ1ZygiU2V0dGluZyBn ZW9tZXRyeSBmcm9tIHNjcmlwdCB0bzogJXNcbiIsIGNwKTsKKwkgICAgZC0+Ymlvc19jeWwgPSBz dHJ0b2woY3AsICZjcCwgMCk7CisJICAgIGQtPmJpb3NfaGQgPSBzdHJ0b2woY3AgKyAxLCAmY3As IDApOworCSAgICBkLT5iaW9zX3NlY3QgPSBzdHJ0b2woY3AgKyAxLCAwLCAwKTsKIAl9CiAgICAg fQogCmRpZmYgLWR1clAgc3lzaW5zdGFsbC5vcmlnL3N5c2luc3RhbGwuOCBzeXNpbnN0YWxsL3N5 c2luc3RhbGwuOAotLS0gc3lzaW5zdGFsbC5vcmlnL3N5c2luc3RhbGwuOAkyMDA3LTA2LTI1IDEz OjM3OjE2LjAwMDAwMDAwMCAtMDMwMAorKysgc3lzaW5zdGFsbC9zeXNpbnN0YWxsLjgJMjAwOC0w NS0yMyAyMjo1MzoyOC4wMDAwMDAwMDAgLTAzMDAKQEAgLTI0OSw2ICsyNDksMTIgQEAKIC5CbCAt dGFnIC13aWR0aCBmaW5keAogLkl0IGdlb21ldHJ5CiBUaGUgZGlzayBnZW9tZXRyeSwgYXMgYSBj eWxzL2hlYWRzL3NlY3RvcnMgZm9ybWF0dGVkIHN0cmluZy4KK1RoZSB3b3JkICJzYW5lIiBpbnN0 cnVjdHMKKy5ObQordG8gY2FsY3VsYXRlIGEgc2FmZSAobm90IG5lY2Vzc2FyaWx5IG9wdGltYWwp IGdlb21ldHJ5IGlmIHRoZQorY3VycmVudCBvbmUgaGFzIG1vcmUgdGhhbiA2NTUzNSBjeWxpbmRl cnMsIG1vcmUgdGhhbiAyNTYgaGVhZHMgb3IKK21vcmUgdGhhbiA2MyBzZWN0b3JzIHBlciB0cmFj ayAoMjU1IHNlY3RvcnMgb24gdGhlIFBDOTgKK2FyY2hpdGVjdHVyZSkuCiBEZWZhdWx0OiBubwog Y2hhbmdlIHRvIGdlb21ldHJ5LgogLkl0IHBhcnRpdGlvbgo= ------=_Part_13508_33435167.1211770326242-- From owner-freebsd-stable@FreeBSD.ORG Mon May 26 05:27:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BDE11065670 for ; Mon, 26 May 2008 05:27:32 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 3666F8FC27 for ; Mon, 26 May 2008 05:27:31 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 52654 invoked from network); 26 May 2008 05:27:30 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 26 May 2008 05:27:30 -0000 X-pair-Authenticated: 87.58.145.180 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id m4Q5RT5J026304; Mon, 26 May 2008 07:27:29 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id m4Q5RTrp026303; Mon, 26 May 2008 07:27:29 +0200 (CEST) (envelope-from pho) Date: Mon, 26 May 2008 07:27:29 +0200 From: Peter Holm To: Mark Kirkwood Message-ID: <20080526052729.GA25171@peter.osted.lan> References: <720051dc0805220159n23eb6205yfcf9450be7af5c77@mail.gmail.com> <200805230829.09524.jhb@freebsd.org> <20080523132645.GO29770@deviant.kiev.zoral.com.ua> <200805231811.01936.jhb@freebsd.org> <48390FA9.5080503@paradise.net.nz> <4839243D.7000700@paradise.net.nz> <20080525171632.GA1305@peter.osted.lan> <483A1F0F.1060502@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <483A1F0F.1060502@paradise.net.nz> User-Agent: Mutt/1.4.2.1i Cc: Peter Holm , freebsd-stable , John Baldwin Subject: Re: BTX loader hangs after version info X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2008 05:27:32 -0000 On Mon, May 26, 2008 at 02:23:11PM +1200, Mark Kirkwood wrote: > Peter Holm wrote: > >On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > > > >>I wrote: > >> > >>>John Baldwin wrote: > >>> > >>>>Try this patch. I'm not 100% certain this will fix it as I can't > >>>>reproduce > >>>>the issue, but I think it might help. Specifically, when the boot > >>>>code makes > >>>>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>>>registers via > >>>>the v86 structure including the eflags register. However, none of > >>>>the boot > >>>>programs actually initialized the v86 structure. Thus, the BIOS > >>>>routines > >>>>would start off running with whatever garbage was in v86.efl when > >>>>each boot > >>>>program started. This meant that we could end up invoking BIOS > >>>>routines with > >>>>interrupts disabled, and I think this might explain a hard hang (if a > >>>>BIOS > >>>>routine was waiting for an interrupt the interrupt would never > >>>>fire). The > >>>>patch fixes all the boot programs to initialize v86 to a better known > >>>>state. At the least it sets v86.efl to a sane value (0x202) rather > >>>>than random. (The > >>>>random might have always been 0x0 BTW, not sure on that one.) > >>>> > >>>> > >>>> > >>>Thanks John, > >>> > >>>Unfortunately this patch does *not* cure the issue for my old > >>>Supermicro P3TDDE, it still hangs just before presenting the menu. I > >>>had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >>>to get back to being bootable again - but at least the old fella is on > >>>a more up-to-date 7-STABLE now :-) > >>> > >>Given that the patch *did* cure Peters Tyan S2720, I'll double check I > >>didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > >>same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > >>whereas the P3TDDE has Award BIOS). > >> > >>Anyway, I'll double check and report back... > >> > >>Cheers > >> > >>Mark > >> > > > >I did 18 boots with and with out John's patch. With the patch I got 6 > >actual boots and 12 hangs in the loaders progress bar. > > > >Without the patch I got 10 boots and 8 hangs. > > > >But, my Tyan M/B is old and with known ACPI issues so I'm not sure if > >this is of much value. > > > >Mark, it would be nice if you also observe if a sequence of reboots > >eventually boots your system. My longest bad streek was 8 reboots. > > > > > > Yeah, I see the same thing - with John's patch applied, out of 9 reboots > I got 7 hangs and 2 actual boots. (didn't try without the patch). > > Mark OK, that is at least nice with consistency across different HW. -- Peter From owner-freebsd-stable@FreeBSD.ORG Mon May 26 06:24:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5821065678 for ; Mon, 26 May 2008 06:24:18 +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 DD97A8FC1A for ; Mon, 26 May 2008 06:24:17 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 876EA1CC033; Sun, 25 May 2008 23:24:17 -0700 (PDT) Date: Sun, 25 May 2008 23:24:17 -0700 From: Jeremy Chadwick To: "Carlos A. M. dos Santos" Message-ID: <20080526062417.GA61084@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.17 (2007-11-01) Cc: FreeBSD Stable Subject: Re: Why does sysinstall still limits cylinders to 65535? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2008 06:24:18 -0000 On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: > I have been struglling with sysinstall, attempting to make it handle > the geometry of some large SATA drives. After a lot of effort I > decided to stop suffering and modified the program in order to > circumvent the outdated limit of 65535 cylinders (see attached patch). > I'm thinking about submitting a PR with a change request but I'd like > to get some additional opinions first. I did not test it in "batch" > mode, so it would be great if any kind soul did this. Carlos, bottom line is to simply ignore the geometry warning you see. For others... This is just added evidence that the humongous warning spit out during sysinstall's fdisk is confusing users (many taking it very seriously when there's really no problem at all). I think this is the third time someone's brought this up in the past couple months... -- | 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 May 26 17:14:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0994B1065678 for ; Mon, 26 May 2008 17:14:45 +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 B4C828FC27 for ; Mon, 26 May 2008 17:14:44 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 9631C64D79 for ; Mon, 26 May 2008 20:14:41 +0300 (EEST) 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 30945-06 for ; Mon, 26 May 2008 20:14:40 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id C4CC564D6E for ; Mon, 26 May 2008 20:14:40 +0300 (EEST) Message-ID: <483AEFFE.8080302@bulinfo.net> Date: Mon, 26 May 2008 20:14:38 +0300 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: shmat() return values? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2008 17:14:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, When I try: if ((*shm = shmat(shmid, NULL, 0)) == -1) The gcc complains with: warning: comparison between pointer and integer shmat() is declared in shm.h as: void *shmat(int, const void *, int); but 'man 4 shmat; RETURN VALUES Upon success, shmat() returns the address where the segment is attached; otherwise, -1 is returned and errno is set to indicate the error. What is the correct return value on failure, -1 or NULL? I think it should be NULL? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFIOu/+xJBWvpalMpkRAjZUAJ9UWQhOaUw/xtoNTfMydiudWv7apwCaAomp gJhTr9Iwh0jalQL+r8KwKdY= =m30h -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon May 26 20:56:10 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C712106571E for ; Mon, 26 May 2008 20:56:10 +0000 (UTC) (envelope-from jille@quis.cx) Received: from istud.quis.cx (ip83-113-174-82.adsl2.versatel.nl [82.174.113.83]) by mx1.freebsd.org (Postfix) with ESMTP id C2BB88FC2C for ; Mon, 26 May 2008 20:56:09 +0000 (UTC) (envelope-from jille@quis.cx) Received: by istud.quis.cx (Postfix, from userid 100) id 6E5A739826; Mon, 26 May 2008 22:56:08 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on istud.quis.cx X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id C4C5D39820; Mon, 26 May 2008 22:56:05 +0200 (CEST) Message-ID: <483B23D8.6010606@quis.cx> Date: Mon, 26 May 2008 22:55:52 +0200 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sam Leffler X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: ath network (wifi) driver (Fujitsu Siemens Amilo Pro V3515 laptop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2008 20:56:10 -0000 Hello Sam, I've got a Fujitsu Siemens Amilo Pro V3515 laptop, with a builtin autheros-wifi card, but I can't get it working. I am running FreeBSD 7.0-STABLE, I don't know whether it works in -CURRENT. Over here I have the dmesg: http://junk.quis.cx/VNViVksv/blackbox.dmesg.txt I haven't compiled it in, it didn't boot that way (kernel panic iirc). When I kldload if_ath I get this: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 3 device_attach: ath0 attach returned 6 # pciconf -l | grep ath ath0@pci0:5:1:0: class=0x020000 card=0x2052168c chip=0x001a168c rev=0x01 hdr=0x00 Full pciconf: http://junk.quis.cx/unvZDYnA/blackbox.pciconf.txt Could you please help me out ? Do you want more info ? -- Jille From owner-freebsd-stable@FreeBSD.ORG Tue May 27 08:02:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B144106564A for ; Tue, 27 May 2008 08:02:18 +0000 (UTC) (envelope-from z@zlo.nu) Received: from mzh.zlo.nu (ns0.zlo.nu [85.17.141.90]) by mx1.freebsd.org (Postfix) with ESMTP id 248998FC2F for ; Tue, 27 May 2008 08:02:17 +0000 (UTC) (envelope-from z@zlo.nu) Received: by mzh.zlo.nu (Postfix, from userid 1000) id 6D8A314232; Tue, 27 May 2008 09:45:18 +0200 (CEST) Date: Tue, 27 May 2008 09:45:18 +0200 From: Marc Olzheim To: Krassimir Slavchev Message-ID: <20080527074518.GA2593@zlo.nu> References: <483AEFFE.8080302@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <483AEFFE.8080302@bulinfo.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Subject: Re: shmat() return values? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 May 2008 08:02:18 -0000 On Mon, May 26, 2008 at 08:14:38PM +0300, Krassimir Slavchev wrote: > Hello, > > When I try: > > if ((*shm = shmat(shmid, NULL, 0)) == -1) > > The gcc complains with: > warning: comparison between pointer and integer > > shmat() is declared in shm.h as: > void *shmat(int, const void *, int); > > but 'man 4 shmat; > > RETURN VALUES > Upon success, shmat() returns the address where the segment is > attached; > otherwise, -1 is returned and errno is set to indicate the error. > > > What is the correct return value on failure, -1 or NULL? > I think it should be NULL? The return value is a void pointer, with value equivalent to -1, so (void *)-1 So you can replace it with: if ((*shm = shmat(shmid, NULL, 0)) == (void*)-1) Marc From owner-freebsd-stable@FreeBSD.ORG Tue May 27 12:19:10 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 680441065671 for ; Tue, 27 May 2008 12:19:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD26E8FC17 for ; Tue, 27 May 2008 12:19:09 +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 m4RCJ7k8038125; Tue, 27 May 2008 14:19:08 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m4RCJ7Q6038124; Tue, 27 May 2008 14:19:07 +0200 (CEST) (envelope-from olli) Date: Tue, 27 May 2008 14:19:07 +0200 (CEST) Message-Id: <200805271219.m4RCJ7Q6038124@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, unga888@yahoo.com In-Reply-To: <555870.1659.qm@web57010.mail.re3.yahoo.com> 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]); Tue, 27 May 2008 14:19:08 +0200 (CEST) Cc: Subject: Re: sched_ule performance on single CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2008 12:19:10 -0000 Unga wrote: > When open an pdf has two types of scenarios in > FreeBSD: > 1. When X run as a realtime-prio process, X go mad and > swallow up almost all of CPU cycles, making audio > hiccups. That's expected. Running the X server with rtprio is not a good idea. There's no reason to do that. > 2. When X run as a normal-prio process, X behaves well > and rarely gets an audible hiccup. That's good. :-) > Why X behave different under different priority > categories? Isn't this scheduler related? Very simple: Sometimes the X server consumes lots of CPU for a short time. If it runs with rtprio, then no other process gets a chance to execute, so your audio program will starve. My recommendation is to not use rtprio or renice. I think many people who try to use them are making things worse. (In fact I think rtprio and idprio should die.) > I wonder the issue I mentioned, open a pdf while > playback audio, is it a issue on Apple Mac OSX? Could > somebody give some light here who uses an Apple Mac > OSX on this list? OSX has a vastly different kernel, scheduler, I/O system, audio drivers and so on. It's a completely different animal. Have you tried increasing the audio driver's buffersize? It probably helps to alleviate your problem. I think OSX sizes the buffer dynamically (not sure though). 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 "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ From owner-freebsd-stable@FreeBSD.ORG Tue May 27 15:23:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB514106564A for ; Tue, 27 May 2008 15:23:47 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 597788FC15 for ; Tue, 27 May 2008 15:23:47 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4REqWqs013408 for ; Tue, 27 May 2008 16:52:34 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id C7E951E5 for ; Tue, 27 May 2008 16:52:32 +0200 (CEST) Date: Tue, 27 May 2008 16:52:32 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.27.73739 Subject: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 May 2008 15:23:47 -0000 Hi folks, I have four identical ITX boards from Jetway here, each having two re(4) onboard nics: re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 rev=0x80 I run FreeBSD 7-stable from early March 08 on three of these machines and noticed no problems with networking with that so far. Some days ago I installed a fourth machine with 7-stable from early May (and some days later -because of the problems described below- to May 17th). With this new machine I see several networking problems. The most prominent are these two: - heavy networking traffic (in this case backup via tar & NFS) causes hangs for about 10s-30s and sometimes also leads to watchdog timeouts: May 27 09:04:07 protoserve kernel: re0: watchdog timeout May 27 09:04:07 protoserve kernel: re0: link state changed to DOWN May 27 09:04:10 protoserve kernel: re0: link state changed to UP - copying large files (more than some 100MB) via ssh/scp drops the connection due to "corrupted MAC on input": Disconnecting: Corrupted MAC on input. lost connection In the latter case the networking traffic should actually not be that high, because these are nanobsd systems which are transferring a new image file (system update, 2GB) via ssh (so the bottleneck should be the write speed of the CF card used to hold the system). I do not see these problems with the old codebase from March 08 on my old machines. The cvs shows a large MFC for the re-driver in April, so I guessed something came in there which broke things here. Therefore I downgraded the new system to a cvs codebase from March 1st, but the problems persist. They also exist on both interfaces. memtest86 is running for hours now without finding something wrong. Any hints what I should do next to find the culprit? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue May 27 15:45:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 040AE1065679 for ; Tue, 27 May 2008 15:45:21 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail3.secureworks.net (mail3.secureworks.net [65.114.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id D1B638FC1B for ; Tue, 27 May 2008 15:45:20 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from localhost (localhost [127.0.0.1]) by mail3.secureworks.net (Postfix) with ESMTP id 1976F19E066; Tue, 27 May 2008 15:45:20 +0000 (GMT) X-Virus-Scanned: amavisd-new at secureworks.net Received: from mail3.secureworks.net ([127.0.0.1]) by localhost (mail3.secureworks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO8i9wMFgtrV; Tue, 27 May 2008 15:45:19 +0000 (GMT) Received: from [192.168.23.35] (mole1.secureworks.net [63.239.86.3]) by mail3.secureworks.net (Postfix) with ESMTP id CB4FF19E03B; Tue, 27 May 2008 15:45:19 +0000 (GMT) Message-ID: <483C2C8F.7070909@jellydonut.org> Date: Tue, 27 May 2008 11:45:19 -0400 From: Michael Proto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080502 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "freebsd-stable@freebsd.org" Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 May 2008 15:45:21 -0000 Gerrit Kühn wrote: > Hi folks, > > I have four identical ITX boards from Jetway here, each having two re(4) > onboard nics: > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec > rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 > rev=0x80 > > > I run FreeBSD 7-stable from early March 08 on three of these > machines and noticed no problems with networking with that so far. > Some days ago I installed a fourth machine with 7-stable from early May > (and some days later -because of the problems described below- to May > 17th). With this new machine I see several networking problems. The most > prominent are these two: > > - heavy networking traffic (in this case backup via tar & NFS) causes hangs > for about 10s-30s and sometimes also leads to watchdog timeouts: > May 27 09:04:07 protoserve kernel: re0: watchdog timeout > May 27 09:04:07 protoserve kernel: re0: link state changed to DOWN > May 27 09:04:10 protoserve kernel: re0: link state changed to UP > > - copying large files (more than some 100MB) via ssh/scp drops the > connection due to "corrupted MAC on input": > Disconnecting: Corrupted MAC on input. > lost connection > > In the latter case the networking traffic should actually not be that > high, because these are nanobsd systems which are transferring a new image > file (system update, 2GB) via ssh (so the bottleneck should be the write > speed of the CF card used to hold the system). > > > I do not see these problems with the old codebase from March 08 on my old > machines. The cvs shows a large MFC for the re-driver in April, so I > guessed something came in there which broke things here. Therefore I > downgraded the new system to a cvs codebase from March 1st, but the > problems persist. They also exist on both interfaces. memtest86 is running > for hours now without finding something wrong. > > Any hints what I should do next to find the culprit? > I'm running 6.3 on the exact same Jetway board at home, and while I haven't been bitten by the DOWN/UP issue I have seen the occasional "corrupted MAC on input" error when doing an ssh/scp. Seems to have simmered-down since moving from 6.3-RELEASE to 6.3-STABLE (last supped/rebuilt on 5/6/08). Note this is using only one of the 2 on-board NICs. I disabled the 2nd one in the BIOS as I don't need it at the moment. -Proto From owner-freebsd-stable@FreeBSD.ORG Tue May 27 22:15:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85CF8106567D for ; Tue, 27 May 2008 22:15:41 +0000 (UTC) (envelope-from david.buxton@zen.co.uk) Received: from doppler.zen.co.uk (doppler.zen.co.uk [212.23.3.27]) by mx1.freebsd.org (Postfix) with ESMTP id BBEA88FC14 for ; Tue, 27 May 2008 22:15:40 +0000 (UTC) (envelope-from david.buxton@zen.co.uk) Received: from [212.23.3.140] (helo=smarthost01.mail.zen.net.uk) by doppler.zen.co.uk with esmtp (Exim 4.63) (envelope-from ) id 1K17DL-0000W9-Sw for freebsd-stable@freebsd.org; Tue, 27 May 2008 22:00:15 +0000 Received: from [82.69.23.129] (helo=[192.168.0.2]) by smarthost01.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1K17DI-0008Or-UV for freebsd-stable@freebsd.org; Tue, 27 May 2008 22:00:14 +0000 Message-Id: From: David Buxton To: FreeBSD-stable Content-Type: multipart/mixed; boundary=Apple-Mail-9--457304079 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 23:00:13 +0100 X-Mailer: Apple Mail (2.919.2) X-Originating-Smarthost01-IP: [82.69.23.129] Subject: SCSI bus reset with Adaptec 29320ALP and Eonstor RAID X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 May 2008 22:15:41 -0000 --Apple-Mail-9--457304079 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, I am trying to use a 1.5TB Eonstor raid array with FreeBSD 7.0, but I don't understand whether it is the raid or the scsi card or something else that is causing the computer problems when accessing the raid. My problem is that soon after recognizing the attached disk during boot, FreeBSD appears to hang for about 10 seconds and then says ahd0: Recovery Initiated - Card was not paused followed by a great detail of SCSI status information. Eventually it says (da1:ahd0:0:0:0): SCB 255 - timed out (da1:ahd0:0:0:0): no longer in timeout, status = 24b ahd0: Issued Channel A Bus Reset. 1 SCBs aborted (da1:ahd0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:ahd0:0:0:0): CAM Status: SCSI Status Error (da1:ahd0:0:0:0): SCSI Status: Check Condition (da1:ahd0:0:0:0): UNIT ATTENTION asc:29,0 (da1:ahd0:0:0:0): Power on, reset, or bus device reset occurred (da1:ahd0:0:0:0): Retrying Command (per Sense Data) and then finishes booting as normal. Trying to use the disk after boot makes this happen again. Attached is my dmesg. Would someone tell me if the problem is with my computer? Or likely to be with the Adaptec SCSI card? Or should I suspect the Eonstor drive? Unfortunately I don't have a replacement SCSI card to test with nor a replacement Eonstor. Thanks for any suggestions, David B. FreeBSD 7.0-RELEASE for amd64 Computer is IBM xSeries 336 with 2 GB RAM and 2 x dual core Xeon @ 3.2 GHz. Boot device is a hardware mirror attached to the internal LSILogic raid card. External raid array is Eonstore A08U-1410 U320 LVD SCSI with 8 disks configured as a single 1.6 terabyte RAID-5 disk. RAID controller is Adaptec 29320ALP card with no other devices attached. --Apple-Mail-9--457304079 Content-Disposition: attachment; filename=dmesg.txt Content-Type: text/plain; x-unix-mode=0644; name="dmesg.txt" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2008 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-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 = Features=3D0xbfebfbff Features2=3D0x641d AMD Features=3D0x20000800 Logical CPUs per core: 2 usable memory =3D 2134503424 (2035 MB) avail memory =3D 2059800576 (1964 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 ioapic2 irqs 48-71 on motherboard ioapic1 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, = RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci2: on pcib1 pcib2: at device 4.0 on pci0 pci3: on pcib2 pcib3: at device 0.0 on pci3 pci4: on pcib3 mpt0: port 0x4000-0x40ff mem = 0xdeff0000-0xdeffffff,0xdefe0000-0xdefeffff irq 28 at device 1.0 on pci4 mpt0: [ITHREAD] mpt0: MPI Version=3D1.2.15.0 mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) ahd0: port = 0x4100-0x41ff,0x4200-0x42ff mem 0xdefde000-0xdefdffff irq 24 at device = 2.0 on pci4 ahd0: [ITHREAD] aic7901: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs pcib4: at device 0.2 on pci3 pci5: on pcib4 pcib5: at device 6.0 on pci0 pci6: on pcib5 bge0: = mem 0xdcff0000-0xdcffffff irq 16 at device 0.0 on pci6 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-FDX, auto bge0: Ethernet address: 00:11:25:a8:85:42 bge0: [ITHREAD] pcib6: at device 7.0 on pci0 pci7: on pcib6 bge1: = mem 0xdaff0000-0xdaffffff irq 16 at device 0.0 on pci7 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-FDX, auto bge1: Ethernet address: 00:11:25:a8:85:43 bge1: [ITHREAD] pci0: at device 8.0 (no driver attached) uhci0: port 0x2200-0x221f = irq 16 at device 29.0 on pci0 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 0x2600-0x261f = irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem = 0xf9000000-0xf90003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcib7: at device 30.0 on pci0 pci1: on pcib7 vgapci0: port 0x3000-0x30ff mem = 0xf0000000-0xf7ffffff,0xf8000000-0xf800ffff irq 16 at device 1.0 on pci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x480-0x48f at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on = acpi0 sio0: type 16550A sio0: [FILTER] orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcefff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> 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 Timecounters tick every 1.000 msec hptrr: no controller detected. Waiting 5 seconds for SCSI devices to settle mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:0:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:0): Physical (mpt0:0:0:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:0): Online (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:1): Online acd0: DVDROM at ata0-master UDMA33 ses0 at mpt0 bus 0 target 8 lun 0 ses0: Fixed Processor SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20= da0: 320.000MB/s transfers (160.000MHz DT, offset 127, 16bit) da0: Command Queueing Enabled da0: 69878MB (143110144 512 byte sectors: 255H 63S/T 8908C) da1 at ahd0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device=20 da1: 320.000MB/s transfers (160.000MHz DT, offset 127, 16bit) da1: Command Queueing Enabled da1: 1667498MB (3415035904 512 byte sectors: 255H 63S/T 212576C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! ahd0: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x32 Mode 0x11 INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0]=20 INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11]=20 DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE)=20 SCSISIGI[0x25]:(P_DATAOUT_DT|ACKI|BSYI) SCSIPHASE[0x0]=20 SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE)=20 SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI)=20 SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0]=20 QFREEZE_COUNT[0x1] KERNEL_QFREEZE_COUNT[0x1] MK_MESSAGE_SCB[0xff00]=20 MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE)=20 SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0]:(HIPERR|HIZERO)=20 SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0]=20 LQISTAT1[0x0] LQISTAT2[0x80]:(PACKETIZED) LQOSTAT0[0x0]=20 LQOSTAT1[0x0] LQOSTAT2[0xe1]:(LQOSTOP0|LQOPKT)=20 SCB Count =3D 512 CMDS_PENDING =3D 1 LASTSCB 0xffff CURRSCB 0x1ff = NEXTSCB 0xff00 qinstart =3D 120 qinfifonext =3D 120 QINFIFO: WAITING_TID_QUEUES: Pending list: 511 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7]=20 Total 1 Kernel Free SCB lists:=20 Any Device: 497 498 499 500 501 502 503 504 505 506 507 508 509 510 = 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 = 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 = 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 = 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 = 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 = 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 = 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 = 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 = 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 = 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 = 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 = 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 = 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 = 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 = 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 = 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 = 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 = 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 = 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 = 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 = 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 = 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 = 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 = 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 = 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 = 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 = 1 0=20 Sequencer Complete DMA-inprog list:=20 Sequencer Complete list:=20 Sequencer DMA-Up and Complete list:=20 Sequencer On QFreeze and Complete list:=20 ahd0: FIFO0 Free, LONGJMP =3D=3D 0x826c, SCB 0x1ff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 ahd0: FIFO1 Free, LONGJMP =3D=3D 0x8063, SCB 0x1ff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 LQIN: 0x8 0x0 0x1 0xff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = 0x0 0x0 0x0 0x0=20 ahd0: LQISTATE =3D 0x1, LQOSTATE =3D 0x0, OPTIONMODE =3D 0x52 ahd0: OS_SPACE_CNT =3D 0x20 MAXCMDCNT =3D 0x1 ahd0: SAVED_SCSIID =3D 0x0 SAVED_LUN =3D 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR)=20 CCSCBCTL[0x4]:(CCSCBDIR)=20 ahd0: REG0 =3D=3D 0x1ff, SINDEX =3D 0x102, DINDEX =3D 0x102 ahd0: SCBPTR =3D=3D 0x1ff, SCB_NEXT =3D=3D 0xff00, SCB_NEXT2 =3D=3D = 0xff25 CDB 8 0 0 3f 1 0 STACK: 0x1f 0x0 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da1:ahd0:0:0:0): SCB 511 - timed out (da1:ahd0:0:0:0): BDR message in message buffer ahd0: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x31 Mode 0x11 INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0]=20 INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11]=20 DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE)=20 SCSISIGI[0x35]:(P_DATAOUT_DT|ACKI|BSYI|ATNI) SCSIPHASE[0x0]=20 SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE)=20 SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI)=20 SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0]=20 QFREEZE_COUNT[0x1] KERNEL_QFREEZE_COUNT[0x1] MK_MESSAGE_SCB[0xff00]=20 MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE)=20 SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0xc0]:(HIPERR|HIZERO)=20 SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0]=20 LQISTAT1[0x0] LQISTAT2[0x80]:(PACKETIZED) LQOSTAT0[0x0]=20 LQOSTAT1[0x0] LQOSTAT2[0xe1]:(LQOSTOP0|LQOPKT)=20 SCB Count =3D 512 CMDS_PENDING =3D 1 LASTSCB 0xffff CURRSCB 0x1ff = NEXTSCB 0xff00 qinstart =3D 120 qinfifonext =3D 120 QINFIFO: WAITING_TID_QUEUES: Pending list: 511 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7]=20 Total 1 Kernel Free SCB lists:=20 Any Device: 497 498 499 500 501 502 503 504 505 506 507 508 509 510 = 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 = 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 = 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 = 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 = 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 = 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 = 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 = 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 = 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 = 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 = 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 = 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 = 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 = 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 = 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 = 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 = 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 = 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 = 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 = 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 = 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 = 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 = 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 = 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 = 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 = 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 = 1 0=20 Sequencer Complete DMA-inprog list:=20 Sequencer Complete list:=20 Sequencer DMA-Up and Complete list:=20 Sequencer On QFreeze and Complete list:=20 ahd0: FIFO0 Free, LONGJMP =3D=3D 0x826c, SCB 0x1ff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 ahd0: FIFO1 Free, LONGJMP =3D=3D 0x8063, SCB 0x1ff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 LQIN: 0x8 0x0 0x1 0xff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = 0x0 0x0 0x0 0x0=20 ahd0: LQISTATE =3D 0x1, LQOSTATE =3D 0x0, OPTIONMODE =3D 0x52 ahd0: OS_SPACE_CNT =3D 0x20 MAXCMDCNT =3D 0x1 ahd0: SAVED_SCSIID =3D 0x0 SAVED_LUN =3D 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR)=20 CCSCBCTL[0x4]:(CCSCBDIR)=20 ahd0: REG0 =3D=3D 0x1ff, SINDEX =3D 0x102, DINDEX =3D 0x102 ahd0: SCBPTR =3D=3D 0x1ff, SCB_NEXT =3D=3D 0xff00, SCB_NEXT2 =3D=3D = 0xff25 CDB 8 0 0 3f 1 0 STACK: 0x1f 0x0 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da1:ahd0:0:0:0): SCB 511 - timed out (da1:ahd0:0:0:0): no longer in timeout, status =3D 24b ahd0: Issued Channel A Bus Reset. 1 SCBs aborted (da1:ahd0:0:0:0): READ(06). CDB: 8 0 0 3f 1 0=20 (da1:ahd0:0:0:0): CAM Status: SCSI Status Error (da1:ahd0:0:0:0): SCSI Status: Check Condition (da1:ahd0:0:0:0): UNIT ATTENTION asc:29,0 (da1:ahd0:0:0:0): Power on, reset, or bus device reset occurred (da1:ahd0:0:0:0): Retrying Command (per Sense Data) ahd0: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x16 Mode 0x33 INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0]=20 INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11]=20 DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE)=20 SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0]=20 LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0]=20 SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x0]=20 SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x2]=20 KERNEL_QFREEZE_COUNT[0x2] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff]=20= SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) SSTAT2[0x0] SSTAT3[0x0]=20 PERRDIAG[0xc0]:(HIPERR|HIZERO) = SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO)=20 LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0]=20 LQOSTAT1[0x0] LQOSTAT2[0xe1]:(LQOSTOP0|LQOPKT)=20 SCB Count =3D 512 CMDS_PENDING =3D 1 LASTSCB 0xffff CURRSCB 0xff NEXTSCB = 0xffc0 qinstart =3D 128 qinfifonext =3D 128 QINFIFO: WAITING_TID_QUEUES: Pending list: 255 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7]=20 Total 1 Kernel Free SCB lists:=20 Any Device: 511 497 498 499 500 501 502 503 504 505 506 507 508 509 = 510 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 = 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 = 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 = 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 = 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 = 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 = 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 = 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 = 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 = 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 = 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 = 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 = 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 = 263 262 261 260 259 258 257 256 254 253 252 251 250 249 248 247 246 245 = 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 = 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 = 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 = 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 = 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 = 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 = 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 = 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 = 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 = 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 = 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 = 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 = 1 0=20 Sequencer Complete DMA-inprog list:=20 Sequencer Complete list:=20 Sequencer DMA-Up and Complete list:=20 Sequencer On QFreeze and Complete list:=20 ahd0: FIFO0 Free, LONGJMP =3D=3D 0x826c, SCB 0xff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 ahd0: FIFO1 Free, LONGJMP =3D=3D 0x8063, SCB 0x1ff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 LQIN: 0x8 0x0 0x0 0xff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = 0x0 0x0 0x0 0x0=20 ahd0: LQISTATE =3D 0x0, LQOSTATE =3D 0x0, OPTIONMODE =3D 0x52 ahd0: OS_SPACE_CNT =3D 0x20 MAXCMDCNT =3D 0x1 ahd0: SAVED_SCSIID =3D 0x0 SAVED_LUN =3D 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR)=20 CCSCBCTL[0x4]:(CCSCBDIR)=20 ahd0: REG0 =3D=3D 0x1ff, SINDEX =3D 0x102, DINDEX =3D 0x102 ahd0: SCBPTR =3D=3D 0xff, SCB_NEXT =3D=3D 0xffc0, SCB_NEXT2 =3D=3D = 0xff2d CDB 25 0 0 0 0 0 STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da1:ahd0:0:0:0): SCB 255 - timed out (da1:ahd0:0:0:0): BDR message in message buffer ahd0: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x1d Mode 0x33 INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0]=20 INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11]=20 DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE)=20 SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0]=20 LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0]=20 SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x0]=20 SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x2]=20 KERNEL_QFREEZE_COUNT[0x2] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff]=20= SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) SSTAT2[0x0] SSTAT3[0x0]=20 PERRDIAG[0xc0]:(HIPERR|HIZERO) = SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO)=20 LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0]=20 LQOSTAT1[0x0] LQOSTAT2[0xe1]:(LQOSTOP0|LQOPKT)=20 SCB Count =3D 512 CMDS_PENDING =3D 1 LASTSCB 0xffff CURRSCB 0xff NEXTSCB = 0xffc0 qinstart =3D 128 qinfifonext =3D 128 QINFIFO: WAITING_TID_QUEUES: Pending list: 255 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7]=20 Total 1 Kernel Free SCB lists:=20 Any Device: 511 497 498 499 500 501 502 503 504 505 506 507 508 509 = 510 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 = 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 = 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 = 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 = 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 = 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 = 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 = 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 = 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 = 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 = 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 = 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 = 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 = 263 262 261 260 259 258 257 256 254 253 252 251 250 249 248 247 246 245 = 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 = 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 = 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 = 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 = 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 = 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 = 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 = 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 = 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 = 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 = 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 = 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 = 1 0=20 Sequencer Complete DMA-inprog list:=20 Sequencer Complete list:=20 Sequencer DMA-Up and Complete list:=20 Sequencer On QFreeze and Complete list:=20 ahd0: FIFO0 Free, LONGJMP =3D=3D 0x826c, SCB 0xff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 ahd0: FIFO1 Free, LONGJMP =3D=3D 0x8063, SCB 0x1ff = SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|E= NSAVEPTRS)=20 SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)=20= SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0]=20 SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR =3D 0x00, SHCNT =3D = 0x0=20 HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL)=20 LQIN: 0x8 0x0 0x0 0xff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = 0x0 0x0 0x0 0x0=20 ahd0: LQISTATE =3D 0x0, LQOSTATE =3D 0x0, OPTIONMODE =3D 0x52 ahd0: OS_SPACE_CNT =3D 0x20 MAXCMDCNT =3D 0x1 ahd0: SAVED_SCSIID =3D 0x0 SAVED_LUN =3D 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR)=20 CCSCBCTL[0x4]:(CCSCBDIR)=20 ahd0: REG0 =3D=3D 0x1ff, SINDEX =3D 0x102, DINDEX =3D 0x102 ahd0: SCBPTR =3D=3D 0xff, SCB_NEXT =3D=3D 0xffc0, SCB_NEXT2 =3D=3D = 0xff2d CDB 25 0 0 0 0 0 STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da1:ahd0:0:0:0): SCB 255 - timed out (da1:ahd0:0:0:0): no longer in timeout, status =3D 24b ahd0: Issued Channel A Bus Reset. 1 SCBs aborted (da1:ahd0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da1:ahd0:0:0:0): CAM Status: SCSI Status Error (da1:ahd0:0:0:0): SCSI Status: Check Condition (da1:ahd0:0:0:0): UNIT ATTENTION asc:29,0 (da1:ahd0:0:0:0): Power on, reset, or bus device reset occurred (da1:ahd0:0:0:0): Retrying Command (per Sense Data) Trying to mount root from ufs:/dev/da0s1a bge0: link state changed to UP --Apple-Mail-9--457304079 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-9--457304079-- From owner-freebsd-stable@FreeBSD.ORG Wed May 28 00:28:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ACA1106566C for ; Wed, 28 May 2008 00:28:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id C89708FC16 for ; Wed, 28 May 2008 00:28:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3199339rvf.43 for ; Tue, 27 May 2008 17:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=UeGUfgpysm2hQ5Bxy4zQxzdv59BxUnfqYA3odYZUogk=; b=WBQckJk/umMuLG3REAFVe2tEDEReUy3ycp9H5e9JjoqQNbYGkBtYlxz4/b+vliNjYsl3Y/JRGPh7N7PH0zTEZvqoIXKKY7DuvS2oxVrMKEyR4VssRmYNiIJ/GZxUlNzrf1wZzIG8bC+0mX0k2CjVwJFmmVmHldcduQR8+5u4RMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=S9bO+IzJRussDPZOhp79JedjdaOGP5o7bCNaqOaPwFjEy4qJcIaP1JfRqvJVE6loYfSHxS/edXysccsp3PeHmybcklCpdTbHIPzxEy0PkDFjG3jPaSxlXfc2JKJztoRkkIfOQRx6qf4cKUP/WQgME8wWumfQqtv5X+lqK1ODZWk= Received: by 10.141.171.1 with SMTP id y1mr832771rvo.86.1211934511491; Tue, 27 May 2008 17:28:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l31sm13191209rvb.6.2008.05.27.17.28.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 May 2008 17:28:30 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m4S0SPGv063862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2008 09:28:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m4S0SNIg063861; Wed, 28 May 2008 09:28:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 28 May 2008 09:28:23 +0900 From: Pyun YongHyeon To: Gerrit K?hn Message-ID: <20080528002823.GA63696@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 00:28:32 -0000 On Tue, May 27, 2008 at 04:52:32PM +0200, Gerrit K?hn wrote: > Hi folks, > > I have four identical ITX boards from Jetway here, each having two re(4) > onboard nics: > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec > rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 > rev=0x80 > > > I run FreeBSD 7-stable from early March 08 on three of these > machines and noticed no problems with networking with that so far. > Some days ago I installed a fourth machine with 7-stable from early May > (and some days later -because of the problems described below- to May > 17th). With this new machine I see several networking problems. The most > prominent are these two: > > - heavy networking traffic (in this case backup via tar & NFS) causes hangs > for about 10s-30s and sometimes also leads to watchdog timeouts: > May 27 09:04:07 protoserve kernel: re0: watchdog timeout > May 27 09:04:07 protoserve kernel: re0: link state changed to DOWN > May 27 09:04:10 protoserve kernel: re0: link state changed to UP > > - copying large files (more than some 100MB) via ssh/scp drops the > connection due to "corrupted MAC on input": > Disconnecting: Corrupted MAC on input. > lost connection > > In the latter case the networking traffic should actually not be that > high, because these are nanobsd systems which are transferring a new image > file (system update, 2GB) via ssh (so the bottleneck should be the write > speed of the CF card used to hold the system). > > > I do not see these problems with the old codebase from March 08 on my old > machines. The cvs shows a large MFC for the re-driver in April, so I > guessed something came in there which broke things here. Therefore I > downgraded the new system to a cvs codebase from March 1st, but the > problems persist. They also exist on both interfaces. memtest86 is running > for hours now without finding something wrong. > > Any hints what I should do next to find the culprit? > There were similiar reports on this issue. It seems that it's very hard to make re(4) work so many RTL8168/8169/8111 revisions without documentation as different revisions require different workaround. Anyway, would you try this one? The patch was generated against HEAD but it would apply to STABLE too. http://people.freebsd.org/~yongari/re/re.HEAD.20080519 -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Wed May 28 02:51:18 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8932B106566B for ; Wed, 28 May 2008 02:51:18 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57008.mail.re3.yahoo.com (web57008.mail.re3.yahoo.com [66.196.97.112]) by mx1.freebsd.org (Postfix) with SMTP id 38D778FC12 for ; Wed, 28 May 2008 02:51:17 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 26261 invoked by uid 60001); 28 May 2008 02:51:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1moquRHD6NiyoAkRpQpvvtUflo+vY29oeakHPe8+vE0sE3DLNOhGiQwvPNhHARi4bwdtHtbJLeZZQgvScQfuZSQsPWLc1GlekT75JLdEvqMTZB5umHXDeNlJ/dAcGevNAVImglPXa/cxq936Q3pQtvqlwW/bIwEa/S++YU43fkY=; X-YMail-OSG: eWTUyXgVM1mWmbN42KnQhHBf6yvCR0zLbagDxoIC1BOZ5MejaK6SFWX1Gvu8e4.Mwe9NxIq37dYwDNPC5l7Iih4mcw3NgzMyuSDqFA-- Received: from [165.21.155.17] by web57008.mail.re3.yahoo.com via HTTP; Tue, 27 May 2008 19:51:16 PDT Date: Tue, 27 May 2008 19:51:16 -0700 (PDT) From: Unga To: freebsd-stable@FreeBSD.ORG In-Reply-To: <200805271219.m4RCJ7Q6038124@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <501295.26204.qm@web57008.mail.re3.yahoo.com> Cc: Oliver Fromme Subject: Re: sched_ule performance on single 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: Wed, 28 May 2008 02:51:18 -0000 --- Oliver Fromme wrote: > Unga wrote: > > When open an pdf has two types of scenarios in > > FreeBSD: > > 1. When X run as a realtime-prio process, X go > mad and > > swallow up almost all of CPU cycles, making audio > > hiccups. > > That's expected. Running the X server with rtprio > is not > a good idea. There's no reason to do that. > I disagree for this. This may most probably depends on what priority X's clients run. Appreciate if Chuck Swiger could enlighten us again on what priority X run on Mac OSX? realtime or normal? > > 2. When X run as a normal-prio process, X behaves > well > > and rarely gets an audible hiccup. > > That's good. :-) > > > Why X behave different under different priority > > categories? Isn't this scheduler related? > > Very simple: Sometimes the X server consumes lots > of CPU > for a short time. If it runs with rtprio, then no > other > process gets a chance to execute, so your audio > program > will starve. > The audio application obviously run on realtime-prio. So can it starve? If it starve? :) > My recommendation is to not use rtprio or renice. I > think > many people who try to use them are making things > worse. > (In fact I think rtprio and idprio should die.) > Again I disagree on this. I think rtprio and idprio are a great asset to distribute different processes to different priority categories. Example, I may be having the openoffice compilation running for a day. I maybe donating my CPU time to protein synthesis program, SETI, etc and they are running all the time. When I'm not compiling, I may be encoding a hi-def footage running for 10 hours. At the same time, I need to browse and aware what's going on around world and listen to music also. Family members also want to access the computer. You want all of these activities run in one priority category? > > I wonder the issue I mentioned, open a pdf while > > playback audio, is it a issue on Apple Mac OSX? > Could > > somebody give some light here who uses an Apple > Mac > > OSX on this list? > > OSX has a vastly different kernel, scheduler, I/O > system, > audio drivers and so on. It's a completely > different > animal. > Hope by improving things on FreeBSD side, FreeBSD can call it a brother, may be a big bother, rather than an animal :) > Have you tried increasing the audio driver's > buffersize? > It probably helps to alleviate your problem. I > think > OSX sizes the buffer dynamically (not sure though). > This is something I really want to try as soon as I get bit of time. Kind regards Unga From owner-freebsd-stable@FreeBSD.ORG Wed May 28 04:32:58 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3CD8106564A for ; Wed, 28 May 2008 04:32:58 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id A19998FC0A for ; Wed, 28 May 2008 04:32:58 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id B42F15D1C; Wed, 28 May 2008 00:32:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ccVqs434Ook; Wed, 28 May 2008 00:32:55 -0400 (EDT) Received: from [10.152.145.158] (72-165-115-225.dia.static.qwest.net [72.165.115.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTPSA id C5BF95D17; Wed, 28 May 2008 00:32:53 -0400 (EDT) Message-Id: <85506AE6-A37B-4644-B854-89397FFD6E19@mac.com> From: Chuck Swiger To: Unga In-Reply-To: <501295.26204.qm@web57008.mail.re3.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 21:32:50 -0700 References: <501295.26204.qm@web57008.mail.re3.yahoo.com> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: sched_ule performance on single 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: Wed, 28 May 2008 04:32:58 -0000 On May 27, 2008, at 7:51 PM, Unga wrote: > Appreciate if Chuck Swiger could enlighten us again on > what priority X run on Mac OSX? realtime or normal? The X11 server seems to run with mildly elevated priority (46, where realtime is > 60 or so); something like an xterm runs with normal/ default priority of 31: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME PRI COMMAND root 69 0.0 0.2 79700 3904 ?? Ss 16May08 0:02.74 63 /usr/sbin/coreaudiod cswiger 89 0.0 0.1 350800 2308 ?? S 16May08 0:00.70 63 /usr/sbin/UserEventAgent -l Aqua root 37 0.0 0.0 599664 704 ?? Ss 16May08 0:00.01 63 /sbin/dynamic_pager -F /private/var/vm/swapfile windowserver57 0.4 3.2 477116 66272 ?? Ss 16May08 51:38.50 63 /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ CoreGraphics.framework/Resources/WindowServer -daemon cswiger 31 0.0 1.0 454876 19936 ?? Ss 16May08 2:41.97 63 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/ loginwindow console cswiger 2142 0.0 3.5 530720 73700 ?? S Fri07PM 75:16.23 62 /Applications/iTunes.app/Contents/MacOS/iTunes -psn_0_884952 [ ... ] cswiger 6449 0.0 0.4 437152 8456 s02 S+ 9:16PM 0:06.87 46 /usr/X11/bin/X/Applications/Utilities/X11.app/Contents/MacOS/X11 - auth /Users/cswiger/.Xauthority -launchd :1 cswiger 6461 0.0 0.3 83768 6060 s03 S 9:17PM 0:00.10 31 xterm cswiger 6467 0.0 0.1 356520 2512 ?? S 9:17PM 0:00.05 31 quartz-wm [ ...the above may wrap poorly, curse you format=flowed MIME type... ] Note that realtime tasks like iTunes uses up a lot of CPU time compared with normal processes; it's even using more CPU time than the WindowServer has. (This is from a MBP with a 2.33 GHz Core2Duo, running 10.5.2...) -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Wed May 28 05:31:42 2008 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 735CA106564A for ; Wed, 28 May 2008 05:31:42 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 01B708FC1C for ; Wed, 28 May 2008 05:31:41 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from sp34.ipt.ru ([194.62.233.107] helo=bs1.sp34.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1K1E1A-0006WH-4l for stable@FreeBSD.org; Wed, 28 May 2008 09:16:08 +0400 Received: from bsam by bs1.sp34.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K17Ru-0000Zk-T2 for stable@FreeBSD.org; Wed, 28 May 2008 02:15:18 +0400 To: stable@FreeBSD.org From: Boris Samorodov Date: Wed, 28 May 2008 02:15:18 +0400 Message-ID: <72197513@bs1.sp34.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: 7-STABLE: bridge and em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 05:31:42 -0000 Hello list! When em0 has an inet address while bridge0 doesn't, it seems to be OK: ----- bs1% uname -a FreeBSD bs1.sp34.ru 7.0-STABLE FreeBSD 7.0-STABLE #0: Sun May 25 20:15:26 MSD 2008 root@bs1.sp34.ru:/usr/obj/usr/src/sys/BSM i386 bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 em0: flags=8943 metric 0 mtu 1500 options=98 ether 00:0c:f1:6c:37:4c inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 media: Ethernet autoselect (100baseTX ) status: active tap0: flags=8943 metric 0 mtu 1500 ether 00:bd:3e:24:00:00 bridge0: flags=8843 metric 0 mtu 1500 ether ea:8b:1f:65:2a:5c id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 7 priority 128 path cost 2000000 member: em0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 2000000 bs1% netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.16.254 UGS 0 357 em0 127.0.0.1 127.0.0.1 UH 0 3934 lo0 192.168.16.0/24 link#1 UC 0 0 em0 192.168.16.1 00:07:e9:80:33:bc UHLW 1 16 em0 951 192.168.16.254 00:07:e9:80:33:bc UHLW 2 0 em0 1002 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#5 UHL lo0 ff01:5::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 bs1% ping -c 3 192.168.16.254 PING 192.168.16.254 (192.168.16.254): 56 data bytes 64 bytes from 192.168.16.254: icmp_seq=0 ttl=64 time=0.316 ms 64 bytes from 192.168.16.254: icmp_seq=1 ttl=64 time=0.263 ms 64 bytes from 192.168.16.254: icmp_seq=2 ttl=64 time=0.266 ms --- 192.168.16.254 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.263/0.282/0.316/0.024 ms ----- But if I move ip address from em0 to bridge0: ----- bs1% sudo ifconfig em0 inet 192.168.16.30 netmask 0xffffff00 delete bs1% sudo ifconfig bridge0 inet 192.168.16.30 netmask 0xffffff00 bs1% sudo route add default 192.168.16.254 add net default: gateway 192.168.16.254 bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 em0: flags=8943 metric 0 mtu 1500 options=98 ether 00:0c:f1:6c:37:4c media: Ethernet autoselect (100baseTX ) status: active tap0: flags=8943 metric 0 mtu 1500 ether 00:bd:3e:24:00:00 bridge0: flags=8843 metric 0 mtu 1500 ether ea:8b:1f:65:2a:5c inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 7 priority 128 path cost 2000000 member: em0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 2000000 bs1% netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.16.254 UGS 0 0 bridge 127.0.0.1 127.0.0.1 UH 0 3934 lo0 192.168.16.0/24 link#6 UC 0 0 bridge 192.168.16.254 link#6 UHLW 2 0 bridge Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#5 UHL lo0 ff01:5::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 bs1% ping -c 3 192.168.16.254 PING 192.168.16.254 (192.168.16.254): 56 data bytes --- 192.168.16.254 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss ----- Did I miss something? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Wed May 28 08:00:07 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20F2A1065678 for ; Wed, 28 May 2008 08:00:07 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57003.mail.re3.yahoo.com (web57003.mail.re3.yahoo.com [66.196.97.107]) by mx1.freebsd.org (Postfix) with SMTP id 91CBF8FC1F for ; Wed, 28 May 2008 08:00:06 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 2506 invoked by uid 60001); 28 May 2008 08:00:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3bCgOouRb4eg8pTqKJmvDgT3cw7HQpFklSFjRMCVP9BM6qjl+gFZcd9PFhu0T7gGlJg/GZGEA8Ku574t7WEGVgY4lolVnzJ4MTtqXNjLjBUr6SbcwkyzZc80BRXiZs2vuxJVg9jvibTpLPNna96vmBFqVICGB1mhPb0lu0cXPxg=; X-YMail-OSG: RqrNJ54VM1kSfpgCiOzatCUpj_w75C4hOq.WmN_p3cZOCn0YTJC35lDuHuHIYP8_NyNMUfnBHmXVGulksUBbFy.LYYZzWEBg2mvYRg-- Received: from [165.21.154.76] by web57003.mail.re3.yahoo.com via HTTP; Wed, 28 May 2008 01:00:00 PDT Date: Wed, 28 May 2008 01:00:00 -0700 (PDT) From: Unga To: Chuck Swiger In-Reply-To: <85506AE6-A37B-4644-B854-89397FFD6E19@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <984332.1518.qm@web57003.mail.re3.yahoo.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: sched_ule performance on single 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: Wed, 28 May 2008 08:00:07 -0000 --- Chuck Swiger wrote: > On May 27, 2008, at 7:51 PM, Unga wrote: > > Appreciate if Chuck Swiger could enlighten us > again on > > what priority X run on Mac OSX? realtime or > normal? > > The X11 server seems to run with mildly elevated > priority (46, where > realtime is > 60 or so); something like an xterm > runs with normal/ > default priority of 31: > > USER PID %CPU %MEM VSZ RSS TT STAT > STARTED TIME > PRI COMMAND > root 69 0.0 0.2 79700 3904 ?? Ss > 16May08 0:02.74 > 63 /usr/sbin/coreaudiod Chuck, thank you very much for the info. Can I trouble you a little bit? Is there something equivalent to rtprio(1) (/usr/sbin/rtprio) in Mac OSX? If there is, could you also send following: 1. rtprio 2. rtprio 3. rtprio 4. rtprio Regards Unga From owner-freebsd-stable@FreeBSD.ORG Wed May 28 08:12:16 2008 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 9AABC106564A for ; Wed, 28 May 2008 08:12:16 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 489888FC26 for ; Wed, 28 May 2008 08:12:16 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id A9251130C3C; Wed, 28 May 2008 09:54:32 +0200 (CEST) Date: Wed, 28 May 2008 09:54:32 +0200 From: Guido Falsi To: Boris Samorodov Message-ID: <20080528075432.GA48519@megatron.madpilot.net> References: <72197513@bs1.sp34.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72197513@bs1.sp34.ru> X-Operating-System: FreeBSD 7.0-STABLE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@FreeBSD.org Subject: Re: 7-STABLE: bridge and em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 08:12:16 -0000 On Wed, May 28, 2008 at 02:15:18AM +0400, Boris Samorodov wrote: > Hello list! > > > When em0 has an inet address while bridge0 doesn't, it seems to be OK: [...] > Did I miss something? Thanks! I discovered the same thing while experimenting with qemu and bridgeng. I think it simply works different from (for example) widnows bridging. I think it's meant to be like that. It also looks more logical either. I think of the bridge as just a packet router, which routes them to all the interfaces(physical and virtual as well) so if the bridge intercepts them with it's own address they can't ereach other interfaces, obviosusly. Maybe I'm wrong here? -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Wed May 28 08:38:43 2008 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 7032D1065677 for ; Wed, 28 May 2008 08:38:43 +0000 (UTC) (envelope-from daniel@skytek.it) Received: from mail.skytek.it (mail.skytek.it [217.194.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id C3F808FC2A for ; Wed, 28 May 2008 08:38:42 +0000 (UTC) (envelope-from daniel@skytek.it) Received: from [192.168.30.100] ([192.168.30.100]) by mail.skytek.it (Skytek Mail Server v.11.47-p9) with ASMTP id INC62401; Wed, 28 May 2008 10:26:01 +0200 Message-ID: <483D171E.90109@skytek.it> Date: Wed, 28 May 2008 10:26:06 +0200 From: Daniel Ponticello User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Guido Falsi References: <72197513@bs1.sp34.ru> <20080528075432.GA48519@megatron.madpilot.net> In-Reply-To: <20080528075432.GA48519@megatron.madpilot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Boris Samorodov , stable@FreeBSD.org Subject: Re: 7-STABLE: bridge and em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 08:38:43 -0000 Guido Falsi ha scritto: > I discovered the same thing while experimenting with qemu and bridgeng. > I think it simply works different from (for example) widnows bridging. > > I think it's meant to be like that. > > It also looks more logical either. I think of the bridge as just a > packet router, which routes them to all the interfaces(physical and > virtual as well) so if the bridge intercepts them with it's own address > they can't ereach other interfaces, obviosusly. > > Maybe I'm wrong here? > > No, you are absolutely right! This is how bridging works. It is not necessary for the birdge interface to have its own mac address, since it will just forward the ethernet frame to all interfaces that are part of the bridge device, with an exception for the interface that received the frame. Later, when the bridge learns the mac address location, it will just forward the ethernet frame to the correct interface. Therefore, if the frame destination is the mac address of the bridge, it will not forward it, since it simply already arrived at destination. Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From owner-freebsd-stable@FreeBSD.ORG Wed May 28 09:08:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5BE1065673 for ; Wed, 28 May 2008 09:08:51 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 47C748FC12 for ; Wed, 28 May 2008 09:08:51 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4S98mXG011495; Wed, 28 May 2008 11:08:49 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 2F0931E5; Wed, 28 May 2008 11:08:48 +0200 (CEST) Date: Wed, 28 May 2008 11:08:48 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20080528110848.560f9f07.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080528002823.GA63696@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.28.15445 Cc: pyunyh@gmail.com Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 09:08:52 -0000 On Wed, 28 May 2008 09:28:23 +0900 Pyun YongHyeon wrote about Re: broken re(4): PY> > Any hints what I should do next to find the culprit? PY> There were similiar reports on this issue. It seems that it's very PY> hard to make re(4) work so many RTL8168/8169/8111 revisions without PY> documentation as different revisions require different workaround. I know. However, in this case I think I have identical hardware, but two boards work, and one doesn't (which seems very strange to me). PY> Anyway, would you try this one? The patch was generated against HEAD PY> but it would apply to STABLE too. PY> http://people.freebsd.org/~yongari/re/re.HEAD.20080519 Thanks. I applied the patch and a new nanobsd image is build right now. I will report later today about the results. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed May 28 09:14:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2768106566C; Wed, 28 May 2008 09:14:58 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id 256558FC12; Wed, 28 May 2008 09:14:58 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id 9ABA21420B9; Wed, 28 May 2008 11:56:05 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from iris.teledomenet.local (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id E473614205A; Wed, 28 May 2008 11:55:59 +0300 (EEST) From: Nikos Vassiliadis To: freebsd-stable@freebsd.org Date: Wed, 28 May 2008 11:54:56 +0300 User-Agent: KMail/1.9.7 References: <72197513@bs1.sp34.ru> In-Reply-To: <72197513@bs1.sp34.ru> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805281154.57305.nvass@teledomenet.gr> Cc: Boris Samorodov , stable@freebsd.org Subject: Re: 7-STABLE: bridge and em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 09:14:58 -0000 On Wednesday 28 May 2008 01:15:18 Boris Samorodov wrote: > Hello list! > > > When em0 has an inet address while bridge0 doesn't, it seems to be OK: > ----- > bs1% uname -a > FreeBSD bs1.sp34.ru 7.0-STABLE FreeBSD 7.0-STABLE #0: Sun May 25 > 20:15:26 MSD 2008 root@bs1.sp34.ru:/usr/obj/usr/src/sys/BSM i386 > bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 > em0: flags=8943 metric 0 > mtu 1500 options=98 > ether 00:0c:f1:6c:37:4c > inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 > media: Ethernet autoselect (100baseTX ) > status: active > tap0: flags=8943 metric > 0 mtu 1500 ether 00:bd:3e:24:00:00 > bridge0: flags=8843 metric 0 mtu > 1500 ether ea:8b:1f:65:2a:5c > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000000 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 2000000 > bs1% netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire default 192.168.16.254 UGS 0 357 > em0 127.0.0.1 127.0.0.1 UH 0 3934 lo0 > 192.168.16.0/24 link#1 UC 0 0 em0 > 192.168.16.1 00:07:e9:80:33:bc UHLW 1 16 em0 > 951 192.168.16.254 00:07:e9:80:33:bc UHLW 2 0 em0 > 1002 > > Internet6: > Destination Gateway Flags > Netif Expire > > ::1 ::1 UHL > :: lo0 > > fe80::%lo0/64 fe80::1%lo0 U > lo0 fe80::1%lo0 link#5 > UHL lo0 ff01:5::/32 fe80::1%lo0 > UC lo0 ff02::%lo0/32 fe80::1%lo0 > UC lo0 bs1% ping -c 3 192.168.16.254 > PING 192.168.16.254 (192.168.16.254): 56 data bytes > 64 bytes from 192.168.16.254: icmp_seq=0 ttl=64 time=0.316 ms > 64 bytes from 192.168.16.254: icmp_seq=1 ttl=64 time=0.263 ms > 64 bytes from 192.168.16.254: icmp_seq=2 ttl=64 time=0.266 ms > > --- 192.168.16.254 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.263/0.282/0.316/0.024 ms > ----- > > But if I move ip address from em0 to bridge0: > ----- > bs1% sudo ifconfig em0 inet 192.168.16.30 netmask 0xffffff00 delete > bs1% sudo ifconfig bridge0 inet 192.168.16.30 netmask 0xffffff00 > bs1% sudo route add default 192.168.16.254 > add net default: gateway 192.168.16.254 > bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 > em0: flags=8943 metric 0 > mtu 1500 options=98 > ether 00:0c:f1:6c:37:4c > media: Ethernet autoselect (100baseTX ) > status: active > tap0: flags=8943 metric > 0 mtu 1500 ether 00:bd:3e:24:00:00 > bridge0: flags=8843 metric 0 mtu > 1500 ether ea:8b:1f:65:2a:5c > inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000000 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 2000000 > bs1% netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire default 192.168.16.254 UGS 0 0 > bridge 127.0.0.1 127.0.0.1 UH 0 3934 > lo0 192.168.16.0/24 link#6 UC 0 0 bridge > 192.168.16.254 link#6 UHLW 2 0 bridge > > Internet6: > Destination Gateway Flags > Netif Expire > > ::1 ::1 UHL > :: lo0 > > fe80::%lo0/64 fe80::1%lo0 U > lo0 fe80::1%lo0 link#5 > UHL lo0 ff01:5::/32 fe80::1%lo0 > UC lo0 ff02::%lo0/32 fe80::1%lo0 > UC lo0 bs1% ping -c 3 192.168.16.254 > PING 192.168.16.254 (192.168.16.254): 56 data bytes > > --- 192.168.16.254 ping statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss > ----- > > Did I miss something? Thanks! Yes, if_bridge uses its own MAC address, so the first time that host 192.168.16.30 pinged host 192.168.16.254, it used MAC address 00:0c:f1:6c:37:4c. When you did assign the IP address on the bridge0 interface, it used the bridge0's MAC address. If host 192.168.16.254 is a bit stubborn about 192.168.16.30's MAC address things will not work(for some time). Nevertheless there is no reason(apparent to me) moving around IP addresses, so if you assign your IP to the bridge interface, things will work. HTH, Nikos From owner-freebsd-stable@FreeBSD.ORG Wed May 28 09:14:58 2008 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 A2768106566C; Wed, 28 May 2008 09:14:58 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id 256558FC12; Wed, 28 May 2008 09:14:58 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id 9ABA21420B9; Wed, 28 May 2008 11:56:05 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from iris.teledomenet.local (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id E473614205A; Wed, 28 May 2008 11:55:59 +0300 (EEST) From: Nikos Vassiliadis To: freebsd-stable@freebsd.org Date: Wed, 28 May 2008 11:54:56 +0300 User-Agent: KMail/1.9.7 References: <72197513@bs1.sp34.ru> In-Reply-To: <72197513@bs1.sp34.ru> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805281154.57305.nvass@teledomenet.gr> Cc: Boris Samorodov , stable@freebsd.org Subject: Re: 7-STABLE: bridge and em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 09:14:58 -0000 On Wednesday 28 May 2008 01:15:18 Boris Samorodov wrote: > Hello list! > > > When em0 has an inet address while bridge0 doesn't, it seems to be OK: > ----- > bs1% uname -a > FreeBSD bs1.sp34.ru 7.0-STABLE FreeBSD 7.0-STABLE #0: Sun May 25 > 20:15:26 MSD 2008 root@bs1.sp34.ru:/usr/obj/usr/src/sys/BSM i386 > bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 > em0: flags=8943 metric 0 > mtu 1500 options=98 > ether 00:0c:f1:6c:37:4c > inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 > media: Ethernet autoselect (100baseTX ) > status: active > tap0: flags=8943 metric > 0 mtu 1500 ether 00:bd:3e:24:00:00 > bridge0: flags=8843 metric 0 mtu > 1500 ether ea:8b:1f:65:2a:5c > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000000 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 2000000 > bs1% netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire default 192.168.16.254 UGS 0 357 > em0 127.0.0.1 127.0.0.1 UH 0 3934 lo0 > 192.168.16.0/24 link#1 UC 0 0 em0 > 192.168.16.1 00:07:e9:80:33:bc UHLW 1 16 em0 > 951 192.168.16.254 00:07:e9:80:33:bc UHLW 2 0 em0 > 1002 > > Internet6: > Destination Gateway Flags > Netif Expire > > ::1 ::1 UHL > :: lo0 > > fe80::%lo0/64 fe80::1%lo0 U > lo0 fe80::1%lo0 link#5 > UHL lo0 ff01:5::/32 fe80::1%lo0 > UC lo0 ff02::%lo0/32 fe80::1%lo0 > UC lo0 bs1% ping -c 3 192.168.16.254 > PING 192.168.16.254 (192.168.16.254): 56 data bytes > 64 bytes from 192.168.16.254: icmp_seq=0 ttl=64 time=0.316 ms > 64 bytes from 192.168.16.254: icmp_seq=1 ttl=64 time=0.263 ms > 64 bytes from 192.168.16.254: icmp_seq=2 ttl=64 time=0.266 ms > > --- 192.168.16.254 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.263/0.282/0.316/0.024 ms > ----- > > But if I move ip address from em0 to bridge0: > ----- > bs1% sudo ifconfig em0 inet 192.168.16.30 netmask 0xffffff00 delete > bs1% sudo ifconfig bridge0 inet 192.168.16.30 netmask 0xffffff00 > bs1% sudo route add default 192.168.16.254 > add net default: gateway 192.168.16.254 > bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 > em0: flags=8943 metric 0 > mtu 1500 options=98 > ether 00:0c:f1:6c:37:4c > media: Ethernet autoselect (100baseTX ) > status: active > tap0: flags=8943 metric > 0 mtu 1500 ether 00:bd:3e:24:00:00 > bridge0: flags=8843 metric 0 mtu > 1500 ether ea:8b:1f:65:2a:5c > inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000000 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 2000000 > bs1% netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire default 192.168.16.254 UGS 0 0 > bridge 127.0.0.1 127.0.0.1 UH 0 3934 > lo0 192.168.16.0/24 link#6 UC 0 0 bridge > 192.168.16.254 link#6 UHLW 2 0 bridge > > Internet6: > Destination Gateway Flags > Netif Expire > > ::1 ::1 UHL > :: lo0 > > fe80::%lo0/64 fe80::1%lo0 U > lo0 fe80::1%lo0 link#5 > UHL lo0 ff01:5::/32 fe80::1%lo0 > UC lo0 ff02::%lo0/32 fe80::1%lo0 > UC lo0 bs1% ping -c 3 192.168.16.254 > PING 192.168.16.254 (192.168.16.254): 56 data bytes > > --- 192.168.16.254 ping statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss > ----- > > Did I miss something? Thanks! Yes, if_bridge uses its own MAC address, so the first time that host 192.168.16.30 pinged host 192.168.16.254, it used MAC address 00:0c:f1:6c:37:4c. When you did assign the IP address on the bridge0 interface, it used the bridge0's MAC address. If host 192.168.16.254 is a bit stubborn about 192.168.16.30's MAC address things will not work(for some time). Nevertheless there is no reason(apparent to me) moving around IP addresses, so if you assign your IP to the bridge interface, things will work. HTH, Nikos From owner-freebsd-stable@FreeBSD.ORG Wed May 28 15:56:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F052C1065676 for ; Wed, 28 May 2008 15:56:16 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7348FC20 for ; Wed, 28 May 2008 15:56:16 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4SFuAjb017187; Wed, 28 May 2008 17:56:13 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8790F72; Wed, 28 May 2008 17:56:10 +0200 (CEST) Date: Wed, 28 May 2008 17:56:10 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: pyunyh@gmail.com Message-Id: <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080528002823.GA63696@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.28.83852 Cc: freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 15:56:17 -0000 On Wed, 28 May 2008 09:28:23 +0900 Pyun YongHyeon wrote about Re: broken re(4): PY> > Any hints what I should do next to find the culprit? PY> There were similiar reports on this issue. It seems that it's very PY> hard to make re(4) work so many RTL8168/8169/8111 revisions without PY> documentation as different revisions require different workaround. PY> Anyway, would you try this one? The patch was generated against HEAD PY> but it would apply to STABLE too. PY> http://people.freebsd.org/~yongari/re/re.HEAD.20080519 Well, I tested this one with some success: After booting the patched system, my re0-Interface was working fine, at least I could transmit GBs of data without getting the problems mentioned before. :-) However, on the other hand re1 did not work at all :-(. The interface was up and running, has an IP and everything, but I could not get a single packet from or to it. After trying everything I could think of, I rebooted the machine. Then both interfaces were working again. Therefore, the errors described above when transmitting large amounts of data are back. :-( Somehow the two interfaces seem to interfer with each other. Can I provide further information for fixing this? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed May 28 18:20:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A585B1065674 for ; Wed, 28 May 2008 18:20:56 +0000 (UTC) (envelope-from daniel@skytek.it) Received: from mail.skytek.it (mail.skytek.it [217.194.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id E03A08FC24 for ; Wed, 28 May 2008 18:20:55 +0000 (UTC) (envelope-from daniel@skytek.it) Received: from [192.168.30.100] ([192.168.30.100]) by mail.skytek.it (Skytek Mail Server v.11.47-p9) with ASMTP id IXW71855 for ; Wed, 28 May 2008 20:20:55 +0200 Message-ID: <483DA28D.3020306@skytek.it> Date: Wed, 28 May 2008 20:21:01 +0200 From: Daniel Ponticello User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: lagg interfaces on -stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 18:20:56 -0000 Hello, i have configured lagg interface on two Broacom (bce0 bce1). I have tried with laggproto lacp (supported by the Nortel switch), with fce and failover, but they all shows the same symptom: Everything works fine until i unplug the cable of the first interface (bce0), it will show status: no carrier even on lagg0 interface, while bce0 shows no carrier (correct) and bce1 is active. Any ideas? Thanks! Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From owner-freebsd-stable@FreeBSD.ORG Wed May 28 19:57:16 2008 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 E49B9106566B for ; Wed, 28 May 2008 19:57:16 +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 3E7728FC13 for ; Wed, 28 May 2008 19:57:15 +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.14.2/jtpda-5.4) with ESMTP id m4SJvDpj058848 ; Wed, 28 May 2008 21:57:14 +0200 (CEST) X-Ids: 168 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 m4SJvCHx050064 ; Wed, 28 May 2008 21:57:12 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m4SJvBHb050061; Wed, 28 May 2008 21:57:11 +0200 (MEST) (envelope-from arno) To: net@freebsd.org From: "Arno J. Klaassen" Date: 28 May 2008 21:57:11 +0200 Message-ID: Lines: 17 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.168]); Wed, 28 May 2008 21:57:14 +0200 (CEST) X-Virus-Scanned: ClamAV 0.92/7278/Wed May 28 17:00:15 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 483DB919.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 483DB919.004/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 483DB919.004 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.056 -> S=0.056 X-j-chkmail-Status: Ham Cc: stable@freebsd.org Subject: nfs buildworld blocked by rpc.lockd ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 19:57:17 -0000 Hello, my buildworld on a 7-stable-amd64 blocks on the following line : TERM=dumb TERMCAP=dumb: ex - /files/bsd/src7/share/termcap/termcap.src < /files/bsd/src7/share/termcap/reorder ex(1) stays in lockd state, and is unkillable, either by Ctl-C or kill -9 /files/bsd is nfs-mounted as follows : push:/raid1/bsd /files/bsd nfs rw,bg,soft,nfsv3,intr,noconn,noauto,-r=32768,-w=32768 0 0 I can provide tcpdumps on server and client if helpful. Thanx, Arno From owner-freebsd-stable@FreeBSD.ORG Wed May 28 20:14:38 2008 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 5B1991065670; Wed, 28 May 2008 20:14:38 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 1936F8FC19; Wed, 28 May 2008 20:14:38 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 6A5F63F8F; Wed, 28 May 2008 21:14:36 +0100 (BST) Message-Id: <5E032C03-6857-4E7F-9C3D-B5C06A79934C@rabson.org> From: Doug Rabson To: Arno J. Klaassen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 21:14:35 +0100 References: X-Mailer: Apple Mail (2.919.2) Cc: stable@freebsd.org, net@freebsd.org Subject: Re: nfs buildworld blocked by rpc.lockd ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 20:14:38 -0000 On 28 May 2008, at 20:57, Arno J. Klaassen wrote: > > Hello, > > my buildworld on a 7-stable-amd64 blocks on the following line : > > TERM=dumb TERMCAP=dumb: ex - /files/bsd/src7/share/termcap/ > termcap.src < /files/bsd/src7/share/termcap/reorder > > ex(1) stays in lockd state, and is unkillable, either by Ctl-C or > kill -9 > > /files/bsd is nfs-mounted as follows : > > push:/raid1/bsd /files/bsd nfs > rw,bg,soft,nfsv3,intr,noconn,noauto,-r=32768,-w=32768 0 0 > > I can provide tcpdumps on server and client if helpful. I would very much like to see tcpdumps (from either client or server). This problem is often caused by the fact that unless you use the '-p' flag, rpc.lockd isn't wired down to any particular port number. Since it is started at boot time, it will usually end up with the same one each time but the new kernel implementation in 7-stable typically ends up with a different port number to the old userland implementation. Quirks of the locking protocol make it difficult for the server to notice this without a lengthy timeout. Workarounds include using '-p' to wire it down to a consistent port (port 4045 is reserved for this) or restarting rpc.lockd on the server. From owner-freebsd-stable@FreeBSD.ORG Wed May 28 22:33:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2E6B1065674 for ; Wed, 28 May 2008 22:33:18 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-a.inoc.net (mx1-a.inoc.net [64.246.131.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8E10D8FC1D for ; Wed, 28 May 2008 22:33:18 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=ZuWmLH5fTHYxBjQoZk/FlYbc9fsz3RgEwdCYXjNMG0EeT/nYff3OrkWdW/ANuO8kOQJVuZ5zCRIkr4+ekIJlHcy1unTltWmBGo/8KwZ3PtQJkJHgs2jX9jmnuTGcFTHBE+V/ttpzFKoyc0oGqoFp+yzlyu4Pziw8IetrdrDesM0=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx1-a.inoc.net (build v8.3.29) with ESMTP id 148351714-1941382 for ; Wed, 28 May 2008 22:13:07 +0000 (UTC) Message-Id: From: Robert Blayzor To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 28 May 2008 18:13:04 -0400 X-Mailer: Apple Mail (2.924) Subject: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 22:33:18 -0000 I have a rather busy Apache 2.2 server; tons of small & some large requests. It's a standard Dell 2650 server using the bge (broadcom) network driver. I seem to have a rather strange problem where after just a day or so Apache just stops processing new connections. You can connect to port 80, but trying to get Apache to process any data just hangs. There is nothing strange in dmesg or in /var/log/messages. The server has plenty free available physical RAM, swap is untouched, CPU load is low, etc. Apache is setup to handle a max of 100 clients using prefork model. If I stop and restart Apache, it does not help. What I do notice is 1000's of sockets stuck in "FIN_WAIT_1" in netstat: [web0:~] netstat -an | grep FIN_WAIT | wc -l 1827 These stick around forever. Some eventually trickle away after hours, but the only thing that appears to fix it is to reboot the server. Then all is fine for another day or so. I've tried just about every tuning trick out there but to no eval. I can mitigate the problem by increasing available socket buffs and decreasing the tcp.sendspace. I've tried different versions of Apache and I've tried with and without the accf_http kernel filter. Here is what I have on the server now: sysctl.conf: kern.maxfiles=65535 kern.maxfilesperproc=16384 kern.ipc.maxsockbuf=4194304 kern.ipc.somaxconn=1024 net.inet.tcp.sendspace=8192 net.inet.tcp.recvspace=8192 net.inet.tcp.keepidle=900000 net.inet.tcp.keepintvl=30000 net.inet.tcp.msl=5000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.tcp.inflight_enable=1 and loader.conf accf_http_load="YES" kern.ipc.nmbclusters=32768 net.inet.tcp.tcbhashsize=4096 kern.ipc.maxsockets=131072 ipfw: 00200 allow tcp from any to me 80 setup 00200 allow icmp from any to me icmptype 0,3,8,11 00200 deny log ip from any to me ifconfig: bge0: flags=8843 mtu 1500 options=3 inet 1.2.3.4 netmask 0xfffffff8 broadcast 5.6.7.8 ether 00:06:5b:f7:c8:7b media: Ethernet autoselect (1000baseTX ) Any ideas would be greatly appreciated. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Wed May 28 22:43:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7002106564A for ; Wed, 28 May 2008 22:43:10 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7C58FC0A for ; Wed, 28 May 2008 22:43:10 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 700F72E8FFCC; Wed, 28 May 2008 15:43:10 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 552FE28098; Wed, 28 May 2008 15:43:10 -0700 (PDT) X-AuditID: 1180711d-a8b91bb000000ed7-5b-483ddffc9ec8 Received: from cswiger1.apple.com (cswiger1.apple.com [17.227.140.124]) by relay13.apple.com (Apple SCV relay) with ESMTP id 7C7A128085; Wed, 28 May 2008 15:43:08 -0700 (PDT) Message-Id: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> From: Chuck Swiger To: Robert Blayzor In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 15:43:08 -0700 References: X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 22:43:10 -0000 Hi-- You didn't mention which version of FreeBSD you are running-- that's rather important info. On May 28, 2008, at 3:13 PM, Robert Blayzor wrote: > ipfw: > > 00200 allow tcp from any to me 80 setup > 00200 allow icmp from any to me icmptype 0,3,8,11 > 00200 deny log ip from any to me Also, surely these can't be the only IPFW rules you are using? If you want to use stateful rules, you need a keep-state argument, and you shouldn't be combining allow rules and deny rules into the same ruleset number... -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Wed May 28 22:49:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0E9106566C for ; Wed, 28 May 2008 22:49:02 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx0-a.inoc.net (mx0-a.inoc.net [64.246.130.30]) by mx1.freebsd.org (Postfix) with ESMTP id A57068FC22 for ; Wed, 28 May 2008 22:49:01 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=ID2ujVH9wLSt9E9wtvuHVI0up8J9UZZ/coUaoIZ7ARbieNPU7t6neBZryNn2rU0X23eoVehqgGqJvief2SAMp9iDenJsf0DQ51hLZwGI7NqeWyGSELIBVAE/2+lQyqvyKvILMlZKWxoG2xr15p0/VdkpAPzI3KzJaKVGv0ZSDz4=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx0-a.inoc.net (build v8.3.29) with ESMTP id 157810043-1941382 for multiple; Wed, 28 May 2008 22:48:58 +0000 (UTC) Message-Id: <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> From: Robert Blayzor To: Chuck Swiger In-Reply-To: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 28 May 2008 18:48:54 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 22:49:02 -0000 On May 28, 2008, at 6:43 PM, Chuck Swiger wrote: > You didn't mention which version of FreeBSD you are running-- that's > rather important info. Actually, I just checked, this is a 4.11 server, I thought it was running at least 6.2. >> 00200 allow tcp from any to me 80 setup >> 00200 allow icmp from any to me icmptype 0,3,8,11 >> 00200 deny log ip from any to me > > Also, surely these can't be the only IPFW rules you are using? If > you want to use stateful rules, you need a keep-state argument, and > you shouldn't be combining allow rules and deny rules into the same > ruleset number... Right, I have a : 00100 allow tcp from any to any established in there as well, but noted on the later part. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Wed May 28 23:02:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CECC610656D8 for ; Wed, 28 May 2008 23:02:24 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-b.inoc.net (mx1-b.inoc.net [64.246.131.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6C44A8FC3D for ; Wed, 28 May 2008 23:02:24 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=GLWZ8aMM3jePfqR9IiM1Mp9Un6YZzQIDJ6VQ2U1+vR6nEBTJQ+6MAroej94JKEYhCiOmKNCNu1vxWILf6kmz/EHW8+HRPiLPYnweFvEZBYv80SeFhck1xNWFRmO+NtzzybnO5+RGdmYOGFAJLluCxkMVTLJchvw0O3L6YkYtqeQ=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx1-b.inoc.net (build v8.3.29) with ESMTP id 149511224-1941382 for multiple; Wed, 28 May 2008 23:02:23 +0000 (UTC) Message-Id: From: Robert Blayzor To: Doug Barton In-Reply-To: <483DE2E0.90003@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 28 May 2008 19:02:19 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 23:02:27 -0000 On May 28, 2008, at 6:55 PM, Doug Barton wrote: > That's a known problem with FreeBSD 4, which is now well past EOL. I > would suggest moving to FreeBSD 7 ASAP. Is it? I searched and searched and never found any hits or PR's regarding this. When was it first fixed? 5.x? 6.x? or not until 7? -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Wed May 28 23:22:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CC221065673 for ; Wed, 28 May 2008 23:22:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id B3CBA8FC17 for ; Wed, 28 May 2008 23:22:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 29198 invoked by uid 399); 28 May 2008 23:07:15 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 28 May 2008 23:07:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <483DE2E0.90003@FreeBSD.org> Date: Wed, 28 May 2008 15:55:28 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> In-Reply-To: <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 May 2008 23:22:13 -0000 Robert Blayzor wrote: > On May 28, 2008, at 6:43 PM, Chuck Swiger wrote: >> You didn't mention which version of FreeBSD you are running-- that's >> rather important info. > > Actually, I just checked, this is a 4.11 server, I thought it was > running at least 6.2. That's a known problem with FreeBSD 4, which is now well past EOL. I would suggest moving to FreeBSD 7 ASAP. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu May 29 04:53:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A9C81065687 for ; Thu, 29 May 2008 04:53:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id E57288FC28 for ; Thu, 29 May 2008 04:53:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10423 invoked by uid 399); 29 May 2008 05:05:23 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 May 2008 05:05:23 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <483E36CE.3060400@FreeBSD.org> Date: Wed, 28 May 2008 21:53:34 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080525) MIME-Version: 1.0 To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 04:53:37 -0000 Robert Blayzor wrote: > On May 28, 2008, at 6:55 PM, Doug Barton wrote: >> That's a known problem with FreeBSD 4, which is now well past EOL. I >> would suggest moving to FreeBSD 7 ASAP. > > > > Is it? I searched and searched and never found any hits or PR's > regarding this. Not sure where you looked then, but I not only saw the discussion multiple times on various lists, I know I posted about our experiences with it. :) > When was it first fixed? 5.x? 6.x? or not until 7? The reason I suggested moving to 7 is that it was branched most recently, has the best new features, etc. If you have to jump FreeBSD versions, this is the one that will get you the most bang for your buck. If you aren't using SMP boxes and have a risk-averse environment, the latest version of 6 will get you where you need to go. Please also note that while this problem has been tweaked somewhat in later versions, it's not always a problem that can be "fixed" in the OS. I'm guessing that you're using an Apache web server, since this is the application that most often leads to this problem. There used to be some helpful hints on Apache's web site for ways you can tune it to reduce the problem, not sure if they're still there or not. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu May 29 05:16:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 548D1106566C for ; Thu, 29 May 2008 05:16:44 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 376618FC1C for ; Thu, 29 May 2008 05:16:44 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-73-161-76.dsl.telstraclear.net [121.73.161.76]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0K1M00HI96NSZU40@smtp4.clear.net.nz>; Thu, 29 May 2008 17:16:42 +1200 (NZST) Date: Thu, 29 May 2008 17:16:22 +1200 From: Mark Kirkwood In-reply-to: <483E36CE.3060400@FreeBSD.org> To: Doug Barton Message-id: <483E3C26.3060103@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080419) Cc: freebsd-stable@freebsd.org, Robert Blayzor Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 05:16:44 -0000 Doug Barton wrote: > Robert Blayzor wrote: >> On May 28, 2008, at 6:55 PM, Doug Barton wrote: >>> That's a known problem with FreeBSD 4, which is now well past EOL. I >>> would suggest moving to FreeBSD 7 ASAP. >> >> >> >> Is it? I searched and searched and never found any hits or PR's >> regarding this. > > Not sure where you looked then, but I not only saw the discussion > multiple times on various lists, I know I posted about our experiences > with it. :) > >> When was it first fixed? 5.x? 6.x? or not until 7? > > The reason I suggested moving to 7 is that it was branched most > recently, has the best new features, etc. If you have to jump FreeBSD > versions, this is the one that will get you the most bang for your > buck. If you aren't using SMP boxes and have a risk-averse > environment, the latest version of 6 will get you where you need to go. > > Please also note that while this problem has been tweaked somewhat in > later versions, it's not always a problem that can be "fixed" in the > OS. I'm guessing that you're using an Apache web server, since this is > the application that most often leads to this problem. There used to > be some helpful hints on Apache's web site for ways you can tune it to > reduce the problem, not sure if they're still there or not. > > > hth, > > Doug > The Apache page: http://httpd.apache.org/docs/2.3/misc/perf-tuning.html It mentions FIN_WAIT_2 not 1, so this might be a different/new problem. Cheers Mark From owner-freebsd-stable@FreeBSD.ORG Thu May 29 05:59:54 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98D4D106564A for ; Thu, 29 May 2008 05:59:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id 42AD58FC14 for ; Thu, 29 May 2008 05:59:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 3379 invoked by uid 399); 29 May 2008 06:11:41 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 May 2008 06:11:41 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <483E4657.9060906@FreeBSD.org> Date: Wed, 28 May 2008 22:59:51 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080525) MIME-Version: 1.0 To: Mark Kirkwood References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> In-Reply-To: <483E3C26.3060103@paradise.net.nz> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Robert Blayzor Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 05:59:54 -0000 Mark Kirkwood wrote: > Doug Barton wrote: > The Apache page: > > http://httpd.apache.org/docs/2.3/misc/perf-tuning.html > > It mentions FIN_WAIT_2 not 1, so this might be a different/new problem. IIRC it actually is the same problem, but in any case you're missing the bit where 4.x is EOL. :) Hence my advice to upgrade to 7.0 and try again, since on the off chance this actually IS a new problem, it stands the best chance of getting fixed. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu May 29 06:07:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 824F1106566B for ; Thu, 29 May 2008 06:07:08 +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 8442B8FC16 for ; Thu, 29 May 2008 06:07:08 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 5B64F1CC031; Wed, 28 May 2008 23:07:08 -0700 (PDT) Date: Wed, 28 May 2008 23:07:08 -0700 From: Jeremy Chadwick To: Robert Blayzor Message-ID: <20080529060708.GA66432@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.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 06:07:08 -0000 On Wed, May 28, 2008 at 06:13:04PM -0400, Robert Blayzor wrote: > Here is what I have on the server now: > > and loader.conf > > accf_http_load="YES" You shouldn't bother with this. Let the apache22 rc.d script handle loading it dynamically. Use apache22_http_accept_enable="yes" in rc.conf. I've read reports in the past how the accept filter can cause FIN_WAIT issues, but I can't remember if that's FIN_WAIT_2 or FIN_WAIT_1. I've also read that pf(4) could possibly cause what you're seeing, so if you have broken firewall rules, those may be responsible for this behaviour. Finally, for what it's worth, we don't have this problem on RELENG_6 or RELENG_7 using Apache 2.2 with the accept filter, and also use pf(4). We use absolutely no tuning in sysctl.conf for any of the things you have listed. -- | 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 Thu May 29 08:16:27 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59FBD106575C for ; Thu, 29 May 2008 08:16:25 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC2B8FC26 for ; Thu, 29 May 2008 08:16:23 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4T8GKRh004004; Thu, 29 May 2008 10:16:22 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 6E8731E5; Thu, 29 May 2008 10:16:20 +0200 (CEST) Date: Thu, 29 May 2008 10:16:20 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Michael Proto Message-Id: <20080529101620.e7d44cc8.gerrit@pmp.uni-hannover.de> In-Reply-To: <483C2C8F.7070909@jellydonut.org> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <483C2C8F.7070909@jellydonut.org> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.29.10100 Cc: "freebsd-stable@freebsd.org" Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 08:16:27 -0000 On Tue, 27 May 2008 11:45:19 -0400 Michael Proto wrote about Re: broken re(4): MP> > Any hints what I should do next to find the culprit? MP> I'm running 6.3 on the exact same Jetway board at home, and while I MP> haven't been bitten by the DOWN/UP issue I have seen the occasional MP> "corrupted MAC on input" error when doing an ssh/scp. Seems to have MP> simmered-down since moving from 6.3-RELEASE to 6.3-STABLE (last MP> supped/rebuilt on 5/6/08). MP> Note this is using only one of the 2 on-board NICs. I disabled the 2nd MP> one in the BIOS as I don't need it at the moment. After my experiences with the patch Pyun provided is seems to me that running one or two nics makes somehow a difference. I am still wondering why I have two boards with the same hardware that work flawlessly. However, when comparing all things, I found some minor differences: The working boards are some months older and their CPU shows up like this: CPU: VIA C7 Esther+RNG+AES+AES-CTR+SHA1+SHA256+RSA (1500.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6a9 Stepping = 9 Features=0xa7c9baff Features2=0x181 The one that doesn't work is newer and dmesg identifies: CPU: VIA C7 Processor 1500MHz (1500.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 Features=0xa7c9baff Features2=0x4181 VIA Padlock Features=0xffcc This is the only difference I can make out so far. Which board do you exactly have? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu May 29 09:58:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DDD51065672 for ; Thu, 29 May 2008 09:58:29 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id F12008FC1F for ; Thu, 29 May 2008 09:58:28 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4T9wPmm012599; Thu, 29 May 2008 11:58:27 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id E1B0C4F; Thu, 29 May 2008 11:58:25 +0200 (CEST) Date: Thu, 29 May 2008 11:58:25 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Gerrit =?ISO-8859-1?Q?K=FChn?= Message-Id: <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.29.24305 Cc: pyunyh@gmail.com, freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 09:58:29 -0000 On Wed, 28 May 2008 17:56:10 +0200 Gerrit K=FChn wrote about Re: broken re(4): GK> PY> http://people.freebsd.org/~yongari/re/re.HEAD.20080519 GK> Somehow the two interfaces seem to interfer with each other. Can I GK> provide further information for fixing this? Meanwhile I booted the machine with the patch several times. I get either the same status as without the patch (both interfaces basically working, but with hangs and checksum errors under load) or I get one interface working fine and one not working at all. I tried turning one if off in the bios, but this didn't change the situation: The remaining one is either working with problems or not at all. Can I do anything else? Is the newer patch (from yesterday) in your directory above worth giving a try? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu May 29 11:10:49 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6BD91065672 for ; Thu, 29 May 2008 11:10:49 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6CAB08FC30 for ; Thu, 29 May 2008 11:10:49 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:19dc:ae3d:fbec:8ec] (unknown [IPv6:2001:7b8:3a7:0:19dc:ae3d:fbec:8ec]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 387803C; Thu, 29 May 2008 13:10:47 +0200 (CEST) Message-ID: <483E8F38.6070109@andric.com> Date: Thu, 29 May 2008 13:10:48 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.15pre (Windows/20080517) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 11:10:49 -0000 On 2008-05-29 11:58, Gerrit K=FChn wrote: > Can I do anything else? Is the newer patch (from yesterday) in your > directory above worth giving a try? FYI, that patch doesn't compile, due to a typo... Fix below: --- re.HEAD.20080528.orig 2008-05-29 13:08:15.000000000 +0200 +++ re.HEAD.20080528 2008-05-29 13:07:28.000000000 +0200 @@ -352,7 +352,7 @@ + if ((sc->rl_flags & RL_FLAG_PAR) !=3D 0) { + /* XXX Should have a way to get station address from EEPROM. */ + uint32_t vpdc, word; -+ int offet, verr; ++ int offset, verr; + + if (pci_find_extcap(sc->rl_dev, PCIY_VPD, &vpdc) =3D=3D 0) { + for (offset =3D 0; offset < 0x20; offset +=3D 4) { From owner-freebsd-stable@FreeBSD.ORG Thu May 29 12:03:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CDFD106574E; Thu, 29 May 2008 12:03:46 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from alaranth.tzim.net (alaranth.tzim.net [91.121.97.143]) by mx1.freebsd.org (Postfix) with ESMTP id 347478FC0A; Thu, 29 May 2008 12:03:45 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from localhost ([127.0.0.1]) by alaranth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1gm4-0004Vu-8O; Thu, 29 May 2008 13:58:28 +0200 Message-ID: <483E9A5D.4010702@tzim.net> Date: Thu, 29 May 2008 13:58:21 +0200 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <48341CF9.3040008@tzim.net> <20080529114556.GC3159@garage.freebsd.pl> In-Reply-To: <20080529114556.GC3159@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Cc: freebsd-stable@freebsd.org Subject: Re: ZFS on root and disk write caching. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 12:03:46 -0000 Pawel Jakub Dawidek a écrit : > On Wed, May 21, 2008 at 03:00:41PM +0200, Arnaud Houdelette wrote: > >> I'm playing around with ZFS. >> >> Currently, I just use it for storage, with a zpool of 4 sata disks. >> The system and boot disk is still formatted with UFS. >> >> As I'm quite pleased with ZFS features, I'd like to try ZFS on root. The >> ZFS wiki is quite clear on how to proceed : if the boot and root are on >> the same disk, you'll have to use bsd labels. >> >> The thing is, I read somewhere that ZFS doesn't enable write caching on >> drives if not used on whole disks. >> > > This is only the case for Solaris, as it turns off write cache by > default. In FreeBSD we always turn on write cache, so don't worry, it > will just work on FreeBSD. > Thanks for the info. > [...] > >> 3. I'd like to keep the storage pool (zraid1) separated from the system >> pool (just one disk). The wiki states that we may encounter problems >> with more than one pool in use : is it still the case ? >> > > AFAIK it was never the case. Where did you find that information > exactly? I've two systems that have more than one pool configured and > never had any problems. > It's clearly stated in the ZFS page of the FreeBSD Wiki : http://wiki.freebsd.org/ZFSKnownProblems , 3rd entry states : Kernel panic and/or data loss may result when more than one ZPOOL is active / in use. Symptoms: various, including (unverified) possibility of data loss. References: http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/004377.html I'll try for myself then. Arnaud Houdelette From owner-freebsd-stable@FreeBSD.ORG Thu May 29 12:06:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAD74106566B for ; Thu, 29 May 2008 12:06:31 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id 599AF8FC28 for ; Thu, 29 May 2008 12:06:31 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CC90945C8C; Thu, 29 May 2008 13:46:04 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 13F7B456B1; Thu, 29 May 2008 13:45:56 +0200 (CEST) Date: Thu, 29 May 2008 13:45:56 +0200 From: Pawel Jakub Dawidek To: Arnaud Houdelette Message-ID: <20080529114556.GC3159@garage.freebsd.pl> References: <48341CF9.3040008@tzim.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qbvjkv9qwOGw/5Fx" Content-Disposition: inline In-Reply-To: <48341CF9.3040008@tzim.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS on root and disk write caching. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 12:06:32 -0000 --Qbvjkv9qwOGw/5Fx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 21, 2008 at 03:00:41PM +0200, Arnaud Houdelette wrote: > I'm playing around with ZFS. >=20 > Currently, I just use it for storage, with a zpool of 4 sata disks. > The system and boot disk is still formatted with UFS. >=20 > As I'm quite pleased with ZFS features, I'd like to try ZFS on root. The= =20 > ZFS wiki is quite clear on how to proceed : if the boot and root are on= =20 > the same disk, you'll have to use bsd labels. >=20 > The thing is, I read somewhere that ZFS doesn't enable write caching on= =20 > drives if not used on whole disks. This is only the case for Solaris, as it turns off write cache by default. In FreeBSD we always turn on write cache, so don't worry, it will just work on FreeBSD. [...] > 3. I'd like to keep the storage pool (zraid1) separated from the system= =20 > pool (just one disk). The wiki states that we may encounter problems=20 > with more than one pool in use : is it still the case ? AFAIK it was never the case. Where did you find that information exactly? I've two systems that have more than one pool configured and never had any problems. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Qbvjkv9qwOGw/5Fx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIPpd0ForvXbEpPzQRAsPqAKDPSdSWCAY5F43tz8Er0+cg3flmxwCdHWYb v3xUloIDIlUqUCM+Ophpndo= =GXAv -----END PGP SIGNATURE----- --Qbvjkv9qwOGw/5Fx-- From owner-freebsd-stable@FreeBSD.ORG Thu May 29 12:23:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C43321065672 for ; Thu, 29 May 2008 12:23:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8AF8FC18 for ; Thu, 29 May 2008 12:23:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 24E6E45CD8; Thu, 29 May 2008 13:52:53 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 767F845C8A; Thu, 29 May 2008 13:52:49 +0200 (CEST) Date: Thu, 29 May 2008 13:52:50 +0200 From: Pawel Jakub Dawidek To: Zaphod Beeblebrox Message-ID: <20080529115250.GD3159@garage.freebsd.pl> References: <16a6ef710805240926t3b4f631bja349fed8df6785ff@mail.gmail.com> <5f67a8c40805241308s15c98737w29bd66c0273bfe95@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P+33d92oIH25kiaB" Content-Disposition: inline In-Reply-To: <5f67a8c40805241308s15c98737w29bd66c0273bfe95@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Andrew Hill , freebsd-stable@freebsd.org, Arnaud Houdelette Subject: Re: ZFS on root and disk write caching. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 12:23:11 -0000 --P+33d92oIH25kiaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 24, 2008 at 04:08:28PM -0400, Zaphod Beeblebrox wrote: > On Sat, May 24, 2008 at 12:26 PM, Andrew Hill wrote: >=20 >=20 > > but what struck me as odd is the desire to create two separate zpools -= one > > for data storage and one for the system. i think one of zfs's greatest > > strengths is the abstraction/separation between disks and filesystems. >=20 >=20 > There are a few reasons to consider more than one zpool. One is > performance. Another is the ability to boot from it (AFAIK, you can only > boot from mirror'd pools). The ZFS abstraction is cool --- but it's not > magic. There is no ZFSboot support committed. You can only have root file system on ZFS and /boot/ on UFS. In this case you can put your root file system on any kind of pool. The reason for multiple pools is data importance. You may have a pool with no redundancy at all for unimportant data, then you can have another pool with RAIDZ2 for more important data and at the end mirrored pool on top of encrypted disks for secret data. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --P+33d92oIH25kiaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIPpkRForvXbEpPzQRAkGdAKD3WH7ixEEI2asRZ2M/AInlMkQbEACgiM3V uUQxqsy2WThVtz3mA4Y2fl8= =B/SB -----END PGP SIGNATURE----- --P+33d92oIH25kiaB-- From owner-freebsd-stable@FreeBSD.ORG Thu May 29 12:44:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CB27106566C for ; Thu, 29 May 2008 12:44:06 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by mx1.freebsd.org (Postfix) with ESMTP id 26C988FC15 for ; Thu, 29 May 2008 12:44:06 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sWjgLcAOfCOuwCpWBEsXo7pUYEJ5AAgQk4PTAoBCzr7tVyYxkDOdSIMqVOOnnA2F; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [24.144.77.185] (helo=joker.seclark.com) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1K1hUD-0003wA-9v; Thu, 29 May 2008 08:44:05 -0400 Message-ID: <483EA513.4070409@earthlink.net> Date: Thu, 29 May 2008 08:44:03 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Doug Barton References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> In-Reply-To: <483E4657.9060906@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec795eec1253a37dbf7a431173c166c63cc3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.144.77.185 Cc: freebsd-stable@freebsd.org, Mark Kirkwood , Robert Blayzor Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 12:44:06 -0000 Doug Barton wrote: > Mark Kirkwood wrote: >> Doug Barton wrote: > >> The Apache page: >> >> http://httpd.apache.org/docs/2.3/misc/perf-tuning.html >> >> It mentions FIN_WAIT_2 not 1, so this might be a different/new problem. > > IIRC it actually is the same problem, but in any case you're missing the > bit where 4.x is EOL. :) Hence my advice to upgrade to 7.0 and try > again, since on the off chance this actually IS a new problem, it stands > the best chance of getting fixed. > > Doug > You know it really pains me when people blithely say just upgrade to X.X where X is the latest release. It is generally just not that simple to upgrade - there are all sorts of dependencies with other software that have to be considered. My $.02 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 Thu May 29 13:02:55 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C4761065678 for ; Thu, 29 May 2008 13:02:55 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx0-a.inoc.net (mx0-a.inoc.net [64.246.130.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5118FC22 for ; Thu, 29 May 2008 13:02:55 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=G3Nf3iK1uAznJqDJ4BJwRjsbJAJHjiu+OycfW79aOgID9i2ZFRqqVt1KqeKZkysitjl67XNUq+37KZBsm4Kzz+9hWuSTD/kmeflW9A/FHeI/b+HGmvRxfrafxNiQVljKGj+V9Z1xBFHLLKNg1hClJTgq/ppc9lvPGywnFShfu6s=; Received: from void.ops.inoc.net (vanguard.noc.albyny.inoc.net [64.246.135.8]) by mx0-a.inoc.net (build v8.3.29) with ESMTP id 157898787-1941382 for multiple; Thu, 29 May 2008 13:02:53 +0000 (UTC) Message-Id: <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> From: Robert Blayzor To: sclark46@earthlink.net In-Reply-To: <483EA513.4070409@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 09:02:52 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 13:02:55 -0000 On May 29, 2008, at 8:44 AM, Stephen Clark wrote: > You know it really pains me when people blithely say just upgrade to > X.X where X is the latest release. > > It is generally just not that simple to upgrade - there are all > sorts of dependencies with other software that have to be considered. I don't mind upgrading this box, it does need it, and it's just a web server. But I see your point. What bothers me is that suggesting an upgrade "may" fix the problem. I really want to know that upgrading WILL fix the problem. I know it might not hurt, but if it doesn't address the primary issue at hand, I can spend time and resources trying to figure out why. Regardless since this is just a mirror web server, I'm going to run it on box using 7.0 and see what I get. I realize a lot of network code has changed from 4.x to 6.x (and maybe 7.x) so I'm going to give that a go. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Thu May 29 13:25:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BC871065683 for ; Thu, 29 May 2008 13:25:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id B71788FC22 for ; Thu, 29 May 2008 13:25:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10874 invoked by uid 399); 29 May 2008 13:37:35 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 May 2008 13:37:35 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <483EAED1.2050404@FreeBSD.org> Date: Thu, 29 May 2008 06:25:37 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> In-Reply-To: <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sclark46@earthlink.net, freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 13:25:44 -0000 Robert Blayzor wrote: > On May 29, 2008, at 8:44 AM, Stephen Clark wrote: >> You know it really pains me when people blithely say just upgrade to >> X.X where X is the latest release. In my first message I did not say it "blithely," I actually said something like "begin looking at 7.0 ASAP." However, when you're dealing with free software "upgrade then try again" Is generally a reasonable request since it's extremely common for bugs to be fixed as a side effect of other updates, and you're dealing with busy people who are volunteering their time and expect you to put in your share of the work. If that cost is too high for you, no worries. But if you're going to use free software you need to understand that it IS a cost (sometimes). It's probably also worthwhile at this point to insert a PSA for more regular, incremental updates instead of just letting things bitrot because they work today, but I digress. >> It is generally just not that simple to upgrade - there are all sorts >> of dependencies with other software that have to be considered. > > > > I don't mind upgrading this box, it does need it, and it's just a web > server. But I see your point. > > What bothers me is that suggesting an upgrade "may" fix the problem. I > really want to know that upgrading WILL fix the problem. Sorry if I wasn't sufficiently clear. I am pretty sure upgrading _will_ fix the problem. Note the message from Jeremy on this point. However, there is a bigger issue that y'all keep wanting to ignore. FREEBSD 4 IS PAST END OF LIFE. You're incredibly unlikely to get someone interested in helping you with this problem since everyone knowledgeable enough to help you will tell you first to upgrade, since a lot of stuff in the network stack has improved. Also, even if you did find someone willing to help you, any time that you spent on a fix for the problem will be irrelevant, since no one but you will care. So, I'm asking you to spend your time and resources on the solution that is going to help you the most in the long run. Best of luck, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu May 29 13:51:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 591231065671 for ; Thu, 29 May 2008 13:51:43 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id C8FA68FC14 for ; Thu, 29 May 2008 13:51:42 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4TDpdxJ031749; Thu, 29 May 2008 15:51:40 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 5BA6072; Thu, 29 May 2008 15:51:39 +0200 (CEST) Date: Thu, 29 May 2008 15:51:39 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: "Dewayne Geraghty" Message-Id: <20080529155139.cb05360d.gerrit@pmp.uni-hannover.de> In-Reply-To: <7827655D32C747BE861B939EDF20F6E3@hs> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> <7827655D32C747BE861B939EDF20F6E3@hs> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.29.63722 Cc: freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 13:51:43 -0000 On Thu, 29 May 2008 23:03:01 +1000 "Dewayne Geraghty" wrote about RE: broken re(4): DG> You might try, after rebooting, to physically unplug and replug your DG> networking cables. I already did try that one or twice, without any success. DG> I have a few EN-15000 and SN-18000 motherboards attached to different DG> types of switches. With the SN-18000 on FreeBSD 7.0R-p1 to make the DG> vge NIC function even after rebooting I need to unplug the NIC's. DG> Doesn't matter what switch, or even using a crossover cable, the card DG> needs to reinitialise itself. This may be similar the problem that DG> you're experiencing. And as Pyon YongHyeon mentions there is a lot of DG> variety with rl and re cards, I also use re in my ITX motherboards, DG> without experiencing your issues. Sounds like I should play around with the cabeling some more. Thanks for the hint. DG> Also, after rebooting your machines try performing tcpdump -vv on the DG> interface that isn't working while (ie before & after) you try the DG> unplug/plug sequence. (vge's since 6.1R experience a lot of incorrect DG> checksums.) I'm suggesting these steps as they might also assist DG> others with clues to assist diagnoses with your re's) I ran tcpdump on the dead interface and remember seeing at least broadcast packages and such arriving from other machines. If I see an interface in this state again I will do some more debugging. Maybe it just cannot send packets, and is receiving just fine? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu May 29 14:30:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E5621065674 for ; Thu, 29 May 2008 14:30:50 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from alaranth.tzim.net (alaranth.tzim.net [91.121.97.143]) by mx1.freebsd.org (Postfix) with ESMTP id E70E28FC1E for ; Thu, 29 May 2008 14:30:49 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from localhost ([127.0.0.1]) by alaranth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1j4R-0004o2-LO for freebsd-stable@freebsd.org; Thu, 29 May 2008 16:25:35 +0200 Message-ID: <483EBCDD.2070408@tzim.net> Date: Thu, 29 May 2008 16:25:33 +0200 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Subject: Bad TCP performance with large MTU on 7-stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 14:30:50 -0000 I got really poor performance when I try to upload files to the box (via pureFTP or Samba) when using jumbo frames somewhat above 2k. uname -a : FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28 17:45:14 CEST 2008 tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 It seems that TCP acks are delayed for about a second, so the upload rate nevers goes above 60kB/s. I can provide wireshark captures done on the box uploading the files if necessary. The client is a Windows XP64 box, but I do not recall having the same problem on 6.2. I did got about 100 MB/s for similar file transfers, but I had to disable jumbo frames when I upgraded to 7.0-Release because of some bug on txcsum/rxcsum on re(4) so I only noticed the issue recently. The txcsum bug doesn't seem to occur anymore, but now I have this strange rate issue, with or without checksum offloading disabled. I also tried with tso disabled. Same results. Is it related to the re(4) driver ? Or to the TCP stack ? Arnaud Houdelette From owner-freebsd-stable@FreeBSD.ORG Thu May 29 15:04:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAEE1106567B for ; Thu, 29 May 2008 15:04:05 +0000 (UTC) (envelope-from prvs=1035d7911d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 24BDD8FC2B for ; Thu, 29 May 2008 15:04:04 +0000 (UTC) (envelope-from prvs=1035d7911d=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1212072323; x=1212677123; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=lyq1wck2udB30uaetdxmA LAAIx741vkaZlZZdpDMkns=; b=VCtV8Svau3h08fgSyI7Agxgb1jMS52FyRrsjp ubChYfWU64Ebkzawq5OnxyHL3VBhgCYJEHjbkXcVb1aSZMWCK6xlLX8qe4oTAcjn Td/xcUCUen8u7RtoCFXl7z8d2nfSpa95hVN4eGu2aPi4mwIBWPXdmE68E/jnDIGu oQgEJo= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, FORGED_MUA_OUTLOOK, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.5) with ESMTP id md50005687022.msg for ; Thu, 29 May 2008 15:45:21 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=1035d7911d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Arnaud Houdelette" , References: <483EBCDD.2070408@tzim.net> Date: Thu, 29 May 2008 15:45:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 29 May 2008 15:45:22 +0100 X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 29 May 2008 15:45:23 +0100 Cc: Subject: Re: Bad TCP performance with large MTU on 7-stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 15:04:05 -0000 Does the trace show the window size being negotiated correctly? ----- Original Message ----- From: "Arnaud Houdelette" >I got really poor performance when I try to upload files to the box (via > pureFTP or Samba) when using jumbo frames somewhat above 2k. > > uname -a : > FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28 > 17:45:14 CEST 2008 > tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 > > It seems that TCP acks are delayed for about a second, so the upload > rate nevers goes above 60kB/s. I can provide wireshark captures done on > the box uploading the files if necessary. > The client is a Windows XP64 box, but I do not recall having the same > problem on 6.2. I did got about 100 MB/s for similar file transfers, but > I had to disable jumbo frames when I upgraded to 7.0-Release because of > some bug on txcsum/rxcsum on re(4) so I only noticed the issue recently. > > The txcsum bug doesn't seem to occur anymore, but now I have this > strange rate issue, with or without checksum offloading disabled. > I also tried with tso disabled. Same results. Is it related to the re(4) > driver ? Or to the TCP stack ? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu May 29 15:13:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847EC1065670 for ; Thu, 29 May 2008 15:13:56 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id D90A48FC27 for ; Thu, 29 May 2008 15:13:55 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4TFDqMq007117; Thu, 29 May 2008 17:13:53 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id E68694F; Thu, 29 May 2008 17:13:51 +0200 (CEST) Date: Thu, 29 May 2008 17:13:51 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Dimitry Andric Message-Id: <20080529171351.a3dd5111.gerrit@pmp.uni-hannover.de> In-Reply-To: <483E8F38.6070109@andric.com> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> <483E8F38.6070109@andric.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.29.75758 Cc: pyunyh@gmail.com, freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 15:13:56 -0000 On Thu, 29 May 2008 13:10:48 +0200 Dimitry Andric wrote about Re: broken re(4): DA> FYI, that patch doesn't compile, due to a typo... Fix below: Thanks, I will try that patch tomorrow. Meanwhile I have set up two more machines. Now I have 5 ITX systems, each with 2 re-NICs, and only one is behaving strange. The only hardware thing that is different in this system from the others is an additional SATA-controller. Can there be conflicts with this card which are triggering the problems? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu May 29 15:19:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33DA1065673 for ; Thu, 29 May 2008 15:19:44 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail3.secureworks.net (mail3.secureworks.net [65.114.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id 73E598FC1B for ; Thu, 29 May 2008 15:19:44 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from localhost (localhost [127.0.0.1]) by mail3.secureworks.net (Postfix) with ESMTP id 140FC19E0BF; Thu, 29 May 2008 15:19:44 +0000 (GMT) X-Virus-Scanned: amavisd-new at secureworks.net Received: from mail3.secureworks.net ([127.0.0.1]) by localhost (mail3.secureworks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwFXUQXnUYa7; Thu, 29 May 2008 15:19:43 +0000 (GMT) Received: from [192.168.23.35] (mole1.secureworks.net [63.239.86.3]) by mail3.secureworks.net (Postfix) with ESMTP id DB53F19E0B1; Thu, 29 May 2008 15:19:43 +0000 (GMT) Message-ID: <483EC98F.20901@jellydonut.org> Date: Thu, 29 May 2008 11:19:43 -0400 From: Michael Proto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080502 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <483C2C8F.7070909@jellydonut.org> <20080529101620.e7d44cc8.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080529101620.e7d44cc8.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "freebsd-stable@freebsd.org" Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 15:19:44 -0000 Gerrit Kühn wrote: > On Tue, 27 May 2008 11:45:19 -0400 Michael Proto > wrote about Re: broken re(4): > > MP> > Any hints what I should do next to find the culprit? > > MP> I'm running 6.3 on the exact same Jetway board at home, and while I > MP> haven't been bitten by the DOWN/UP issue I have seen the occasional > MP> "corrupted MAC on input" error when doing an ssh/scp. Seems to have > MP> simmered-down since moving from 6.3-RELEASE to 6.3-STABLE (last > MP> supped/rebuilt on 5/6/08). > > MP> Note this is using only one of the 2 on-board NICs. I disabled the 2nd > MP> one in the BIOS as I don't need it at the moment. > > After my experiences with the patch Pyun provided is seems to me that > running one or two nics makes somehow a difference. > I am still wondering why I have two boards with the same hardware that > work flawlessly. > However, when comparing all things, I found some minor differences: > The working boards are some months older and their CPU shows up like this: > > CPU: VIA C7 Esther+RNG+AES+AES-CTR+SHA1+SHA256+RSA (1500.01-MHz 686-class > CPU) Origin = "CentaurHauls" Id = 0x6a9 Stepping = 9 > Features=0xa7c9baff > Features2=0x181 > > > The one that doesn't work is newer and dmesg identifies: > > CPU: VIA C7 Processor 1500MHz (1500.01-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 > Features=0xa7c9baff > Features2=0x4181 > VIA Padlock Features=0xffcc > > > This is the only difference I can make out so far. Which board do you > exactly have? > > > cu > Gerrit > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" I've got the newer revision: CPU: VIA Eden Processor 1200MHz (1200.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 Features=0xa7c9baff Features2=0x4181 VIA Padlock Features=0xffcc That's actually why I had to move to 6-STABLE. The CPUID detection routines for the 0x6d0 revision aren't in 6.3-RELEASE. -Proto From owner-freebsd-stable@FreeBSD.ORG Thu May 29 15:56:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A0AF106566C for ; Thu, 29 May 2008 15:56:05 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from qsrv01sl.mx.bigpond.com (qsrv01sl.mx.bigpond.com [144.140.92.181]) by mx1.freebsd.org (Postfix) with ESMTP id 73D2B8FC1E for ; Thu, 29 May 2008 15:56:04 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwotgx03p.mx.bigpond.com ([58.172.113.127]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20080529130307.VHJQ23069.nschwmtas02p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Thu, 29 May 2008 13:03:07 +0000 Received: from mail.heuristicsystems.com.au ([58.172.113.127]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20080529130306.GPIO1860.nschwotgx03p.mx.bigpond.com@mail.heuristicsystems.com.au>; Thu, 29 May 2008 13:03:06 +0000 Received: from black (black.hs [10.0.5.1]) (authenticated bits=0) by mail.heuristicsystems.com.au (8.14.3/8.14.3) with ESMTP id m4TD31md056051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 May 2008 23:03:01 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "=?iso-8859-1?Q?'Gerrit_K=FChn'?=" References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de><20080528002823.GA63696@cdnetworks.co.kr><20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> Date: Thu, 29 May 2008 23:03:01 +1000 Message-ID: <7827655D32C747BE861B939EDF20F6E3@hs> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjBcseln6K40tSIQPytBcGUxLmJVQAF7Q6Q X-RPD-ScanID: Class confirmed; VirusThreatLevel unknown, RefID str=0001.0A150204.483E1461.008C,ss=4,sh,fgs=12 Cc: freebsd-stable@freebsd.org Subject: RE: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 15:56:05 -0000 >-----Original Message----- >From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Gerrit K=FChn >Sent: Thursday, 29 May 2008 7:58 PM >To: Gerrit K=FChn >Cc: pyunyh@gmail.com; freebsd-stable@freebsd.org >Subject: Re: broken re(4) > >On Wed, 28 May 2008 17:56:10 +0200 Gerrit K=FChn = wrote about Re: broken re(4): > >GK> PY> http://people.freebsd.org/~yongari/re/re.HEAD.20080519 . >GK> Somehow the two interfaces seem to interfer with each other. Can I=20 >GK> provide further information for fixing this? > >Meanwhile I booted the machine with the patch several times. I get = either the same status as without the patch (both interfaces basically working, = but with hangs and checksum errors under load) or I get one interface = working fine and one not working at all. >I tried turning one if off in the bios, but this didn't change the >situation: The remaining one is either working with problems or not at = all. > >Can I do anything else? Is the newer patch (from yesterday) in your directory above worth giving a try? > > >cu > Gerrit --- Reply --- You might try, after rebooting, to physically unplug and replug your networking cables. I have a few EN-15000 and SN-18000 motherboards attached to different = types of switches. With the SN-18000 on FreeBSD 7.0R-p1 to make the vge NIC function even after rebooting I need to unplug the NIC's. Doesn't matter what switch, or even using a crossover cable, the card needs to = reinitialise itself. This may be similar the problem that you're experiencing. And = as Pyon YongHyeon mentions there is a lot of variety with rl and re cards, = I also use re in my ITX motherboards, without experiencing your issues. Also, after rebooting your machines try performing tcpdump -vv on the interface that isn't working while (ie before & after) you try the unplug/plug sequence. (vge's since 6.1R experience a lot of incorrect checksums.) I'm suggesting these steps as they might also assist others with clues to assist diagnoses with your re's) Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Thu May 29 16:52:58 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F9E31065671 for ; Thu, 29 May 2008 16:52:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 71F0C8FC18 for ; Thu, 29 May 2008 16:52:57 +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 m4TGqtU2060680; Thu, 29 May 2008 18:52:55 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m4TGqt2o060679; Thu, 29 May 2008 18:52:55 +0200 (CEST) (envelope-from olli) Date: Thu, 29 May 2008 18:52:55 +0200 (CEST) Message-Id: <200805291652.m4TGqt2o060679@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, gerrit@pmp.uni-hannover.de In-Reply-To: <20080529171351.a3dd5111.gerrit@pmp.uni-hannover.de> 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, 29 May 2008 18:52:56 +0200 (CEST) Cc: Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, gerrit@pmp.uni-hannover.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 16:52:58 -0000 Gerrit Kühn wrote: > Meanwhile I have set up two more machines. Now I have 5 ITX systems, > each with 2 re-NICs, and only one is behaving strange. In that case I would suspect that the one piece of hardware that is misbehaving is broken and needs to be replaced. > The only hardware thing that is different in this system from the > others is an additional SATA-controller. Can there be conflicts with > this card which are triggering the problems? I think it's unlikely. Do they share interrupts? (The output of "vmstat -i" will tell you.) In theory it could also be a power supply problem. I assume that you use rather small (thus possibly weak) power supplies for your ITX machines. Maybe the SATA controller in that problematic machine drives the power supply to its limit, and the re(4) interfaces suffer. You could check whether removing the SATA controller improves things. Or try to connect a stronger power supply if you have one available. Other than that, typical things to do to diagnose such problems: - Do you see any non-zero numbers in the collision or error columns of "netstat -i"? - Are you sure the interfaces don't have the same MAC addresses (it's unlikely, but it doesn't hurt to check in the ifconfig output). - Are you sure that media and duplex settings are correct on both sides (i.e. PC and switch)? - Have you tried replacing cables, switch ports, or the whole switch? - Have you tried to disable hardware support features of the driver? In 7-stable re(4) supports quite a lot of hardware features. See "ifconfig -m". You could check whether disabling RXCSUM, TXCSUM and/or TSO4 makes a difference. 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 "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel From owner-freebsd-stable@FreeBSD.ORG Thu May 29 17:09:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7B7E1065679 for ; Thu, 29 May 2008 17:09:14 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 80ACA8FC0C for ; Thu, 29 May 2008 17:09:14 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:19dc:ae3d:fbec:8ec] (unknown [IPv6:2001:7b8:3a7:0:19dc:ae3d:fbec:8ec]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6BD713C; Thu, 29 May 2008 19:09:13 +0200 (CEST) Message-ID: <483EE338.9080609@andric.com> Date: Thu, 29 May 2008 19:09:12 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.15pre (Windows/20080517) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> <483E8F38.6070109@andric.com> <20080529171351.a3dd5111.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080529171351.a3dd5111.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 17:09:14 -0000 On 2008-05-29 17:13, Gerrit K=FChn wrote: > On Thu, 29 May 2008 13:10:48 +0200 Dimitry Andric > Meanwhile I have set up two more machines. Now I have 5 ITX systems, ea= ch > with 2 re-NICs, and only one is behaving strange. Just as a data point, my ITX board is a JetWay J7F4K1G2E.=20 =2E.. re0: port 0xf000-0xf= 0ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000= baseT-FDX, auto re0: Ethernet address: 00:30:18:a6:f1:a8 re0: [FILTER] re1: port 0xf200-0xf= 2ff mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0 re1: Chip rev. 0x18000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000= baseT-FDX, auto re1: Ethernet address: 00:30:18:a6:f1:a9 re1: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0= xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f,0xf400-0xf4ff irq 20 at device 1= 5.0 on pci0 atapci0: [ITHREAD] As you can see, re0 is on irq 18, re1 on irq 19 and the SATA controller on irq 20, so no conflicts there. It also seems to work okay with this latest patch. > The only hardware thing > that is different in this system from the others is an additional > SATA-controller. Can there be conflicts with this card which are > triggering the problems? I'd just suspect a bad board instead... From owner-freebsd-stable@FreeBSD.ORG Thu May 29 18:45:49 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D837106566C for ; Thu, 29 May 2008 18:45:49 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id B8B9A8FC1C for ; Thu, 29 May 2008 18:45:48 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4TIjjkq027037; Thu, 29 May 2008 20:45:46 +0200 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 21A834F; Thu, 29 May 2008 20:45:45 +0200 (CEST) Date: Thu, 29 May 2008 20:45:43 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@FreeBSD.ORG Message-Id: <20080529204543.d4aa927e.gerrit@pmp.uni-hannover.de> In-Reply-To: <200805291652.m4TGqt2o060679@lurza.secnetix.de> References: <20080529171351.a3dd5111.gerrit@pmp.uni-hannover.de> <200805291652.m4TGqt2o060679@lurza.secnetix.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.29.112922 Cc: Oliver Fromme Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 18:45:49 -0000 On Thu, 29 May 2008 18:52:55 +0200 (CEST) Oliver Fromme wrote about Re: broken re(4): OF> In that case I would suspect that the one piece of hardware OF> that is misbehaving is broken and needs to be replaced. I agree. I just do not know yet which part is broken. OF> > The only hardware thing that is different in this system from the OF> > others is an additional SATA-controller. Can there be conflicts with OF> > this card which are triggering the problems? OF> I think it's unlikely. Do they share interrupts? (The OF> output of "vmstat -i" will tell you.) protoserve# vmstat -i interrupt total rate irq0: clk 31564049 1000 irq7: ppbus0 ppc0 1 0 irq8: rtc 4038754 127 irq9: uhci0 uhci1+ 2 0 irq10: re0 re1+ 2401340 76 irq11: atapci0+++ 655498 20 irq14: ata0 11167 0 Total 38670811 1225 Just the two NICs on the same IRQ. A system that is working fine looks like this: firefly1# vmstat -i interrupt total rate irq0: clk 2614761182 1000 irq1: atkbd0 902 0 irq7: ppbus0 ppc0 1 0 irq8: rtc 334559120 127 irq10: re0 re1+ 24354774 9 irq11: atapci0++++ 70905 0 irq14: ata0 800110 0 Total 2974546994 1138 OF> In theory it could also be a power supply problem. I OF> assume that you use rather small (thus possibly weak) OF> power supplies for your ITX machines. Maybe the SATA OF> controller in that problematic machine drives the power OF> supply to its limit, and the re(4) interfaces suffer. OF> You could check whether removing the SATA controller OF> improves things. Or try to connect a stronger power OF> supply if you have one available. I have Travla C146/C147 chassis these macines and use the power supply that comes with them. However, the ultimate test for checking the controller-related things is to simply remove it. I will try this tomorrow (the systems are at work, and I am at home now - can't unplug a controller via ssh :-). OF> - Do you see any non-zero numbers in the collision or OF> error columns of "netstat -i"? No: protoserve# netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll re0 1500 00:30:18:af:19:6a 131032 0 271757 0 0 re0 1500 10.117.0.0 protoserve 80442 - 271722 - - re1 1500 00:30:18:af:19:6b 1474484 0 1114542 0 0 re1 1500 192.168.0.0 192.168.2.1 1471156 - 1114457 - - plip0 1500 0 0 0 0 0 lo0 16384 0 0 0 0 0 lo0 16384 fe80:4::1 fe80:4::1 0 - 0 - - lo0 16384 localhost ::1 0 - 0 - - lo0 16384 your-net localhost 0 - 0 - - OF> - Are you sure the interfaces don't have the same MAC OF> addresses (it's unlikely, but it doesn't hurt to check OF> in the ifconfig output). Yes: protoserve# ifconfig re0: flags=8843 metric 0 mtu 1500 options=399b ether 00:30:18:af:19:6a inet 10.117.15.1 netmask 0xffff0000 broadcast 10.117.255.255 media: Ethernet autoselect (1000baseTX ) status: active re1: flags=8843 metric 0 mtu 1500 options=399b ether 00:30:18:af:19:6b inet 192.168.2.1 netmask 0xffff0000 broadcast 192.168.255.255 media: Ethernet autoselect (1000baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 OF> - Are you sure that media and duplex settings are OF> correct on both sides (i.e. PC and switch)? The systems are all on the same switch (I also changed the switch during the tests with no change), all devices show a 1GB link. OF> - Have you tried replacing cables, switch ports, or the OF> whole switch? Yes, all of that. OF> - Have you tried to disable hardware support features OF> of the driver? In 7-stable re(4) supports quite a lot OF> of hardware features. See "ifconfig -m". You could OF> check whether disabling RXCSUM, TXCSUM and/or TSO4 OF> makes a difference. Another good idea, thanks. I will try that tomorrow, too. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu May 29 18:56:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 227F3106566B for ; Thu, 29 May 2008 18:56:04 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 874298FC18 for ; Thu, 29 May 2008 18:56:03 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4TItxat027576; Thu, 29 May 2008 20:56:01 +0200 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id D8F4372; Thu, 29 May 2008 20:55:59 +0200 (CEST) Date: Thu, 29 May 2008 20:55:58 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Dimitry Andric Message-Id: <20080529205558.d2b064bf.gerrit@pmp.uni-hannover.de> In-Reply-To: <483EE338.9080609@andric.com> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> <483E8F38.6070109@andric.com> <20080529171351.a3dd5111.gerrit@pmp.uni-hannover.de> <483EE338.9080609@andric.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.29.113830 Cc: pyunyh@gmail.com, freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 18:56:04 -0000 On Thu, 29 May 2008 19:09:12 +0200 Dimitry Andric wrote about Re: broken re(4): DA> > I have 5 ITX systems, each with 2 re-NICs, and only one is behaving DA> > strange. DA> Just as a data point, my ITX board is a JetWay J7F4K1G2E. The ones I have are JW J7F4K1G5 A, I guess. I will check tomorrow if this is really printed on all boards (I just bought them as such). DA> As you can see, re0 is on irq 18, re1 on irq 19 and the SATA controller DA> on irq 20, so no conflicts there. Sorry, but this is the onboard controller. The additional one is this: atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfdfff000-0xfdfff3ff irq 11 at device 8.0 on pci0 But it is not on the same irq, either. DA> It also seems to work okay with this latest patch. This is not the latest patch (of 28th May) in my case, it is still the one from the 19th. The other image was still building when I left work, I will try it tomorrow. DA> > The only hardware thing DA> > that is different in this system from the others is an additional DA> > SATA-controller. Can there be conflicts with this card which are DA> > triggering the problems? DA> I'd just suspect a bad board instead... As Oliver already suggested, I will take out the controller and see what happens then. Talking about this controller: This is also the only board I am using with PCI cards (and thus with a PCI riser) at all. I remember vaguely that I had a few problems getting the controller to work in the riser card when it put the system together. The riser has two ports, and the controller would only work in the upper one afaicr. This is the riser card which comes with the Travla C146 chassis. Does anyone else here have experience with it? It came without any documentation, and I was not able to find anything about it on the web. There is even a jumper on it I do not know anything about?! cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu May 29 19:12:17 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E63B4106564A for ; Thu, 29 May 2008 19:12:17 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 870E68FC1B for ; Thu, 29 May 2008 19:12:17 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m4TJCGiF025526; Thu, 29 May 2008 12:12:16 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m4TJCG56025525; Thu, 29 May 2008 12:12:16 -0700 (PDT) Date: Thu, 29 May 2008 12:12:16 -0700 (PDT) From: Matthew Dillon Message-Id: <200805291912.m4TJCG56025525@apollo.backplane.com> To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 19:12:18 -0000 I guess nobody mentioned the obvious thing to check: Make sure TCP keepalive is turned on. sysctl net.inet.tcp.always_keepalive=1 If you don't do this then dead TCP connections can build up, particularly on busy servers, due to the other end simply disappearing. Without this option the TCP protocol can get stuck, because it does not usually send packets to the other end of an idle connection unless (1) its window has closed completely or (2) it has unackncowledged data or state pending. The keepalive forces a probe to occur every so often on an idle connection (like once every 30min-2hrs, I forget what the default is), to check that the connection still exists. It is possible to get stuck during normal data operation and while in a half-closed state. The 2MSL timeout does not activate until you go into a fully closed state (FIN2/TIME_WAIT). Pretty much if you are running any sort of service on the internet, and even if you aren't, you need to make sure keepalive is turned on for the long term health of your system. -Matt From owner-freebsd-stable@FreeBSD.ORG Thu May 29 19:19:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93F25106567C for ; Thu, 29 May 2008 19:19:33 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-b.inoc.net (mx1-b.inoc.net [64.246.131.28]) by mx1.freebsd.org (Postfix) with ESMTP id 07FC48FC2B for ; Thu, 29 May 2008 19:19:32 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=VQ1uilCPj7YpXjF6jMY1F5yKBVVMTxAXf/rWUIl/HpiZVVfkR1YHlxMGVFKwjDcj8ymgPTDNVnRFvON8NlRN+UfhBmzPqnmj4Vp1zx3sdgg1yckxOVQaoNxzLajkSxYzZUcsm9AXNS9/Kehb/AtdDiUpygHhX+oBsHibtAd4oyI=; Received: from void.ops.inoc.net (vanguard.noc.albyny.inoc.net [64.246.135.8]) by mx1-b.inoc.net (build v8.3.29) with ESMTP id 149670731-1941382 for multiple; Thu, 29 May 2008 19:19:29 +0000 (UTC) Message-Id: <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> From: Robert Blayzor To: Matthew Dillon In-Reply-To: <200805291912.m4TJCG56025525@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 15:19:29 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 19:19:33 -0000 On May 29, 2008, at 3:12 PM, Matthew Dillon wrote: > I guess nobody mentioned the obvious thing to check: Make sure > TCP keepalive is turned on. > > sysctl net.inet.tcp.always_keepalive=1 Thanks Matt. I also thought that a keepalives were not running and sessions just stuck around forever, however I do have: net.inet.tcp.keepidle=900000 net.inet.tcp.keepintvl=30000 net.inet.tcp.msl=5000 net.inet.tcp.always_keepalive=1 (default) I believe keep idle was defaulted to 2hrs, I changed it to 15 minutes with a 30 second tick... I still found FIN_WAIT_1 sessions stuck for several hours, if not infinite. Nonet he less, I have a new server up running 7.0-p1, I'll be pumping a lot of traffic to that box soon and I'll see how that makes out. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Thu May 29 19:30:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B4D1065676 for ; Thu, 29 May 2008 19:30:41 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 992D88FC19 for ; Thu, 29 May 2008 19:30:40 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m4TJUeqT025816; Thu, 29 May 2008 12:30:40 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m4TJUeGX025815; Thu, 29 May 2008 12:30:40 -0700 (PDT) Date: Thu, 29 May 2008 12:30:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200805291930.m4TJUeGX025815@apollo.backplane.com> To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 19:30:41 -0000 :On May 29, 2008, at 3:12 PM, Matthew Dillon wrote: :> I guess nobody mentioned the obvious thing to check: Make sure :> TCP keepalive is turned on. :> :> sysctl net.inet.tcp.always_keepalive=1 : : :Thanks Matt. : :I also thought that a keepalives were not running and sessions just :stuck around forever, however I do have: : : :net.inet.tcp.keepidle=900000 :net.inet.tcp.keepintvl=30000 :net.inet.tcp.msl=5000 :net.inet.tcp.always_keepalive=1 (default) : : :I believe keep idle was defaulted to 2hrs, I changed it to 15 minutes :with a 30 second tick... I still found FIN_WAIT_1 sessions stuck for :several hours, if not infinite. : :Nonet he less, I have a new server up running 7.0-p1, I'll be pumping :a lot of traffic to that box soon and I'll see how that makes out. : :-- :Robert Blayzor, BOFH :INOC, LLC :rblayzor@inoc.net :http://www.inoc.net/~rblayzor/ If it is still giving you trouble I recommend using tcpdump to observe the IP/port pair of one of the stuck connections over the keepalive period and see if the keepalives are still being sent and, if they are, what kind of response you get from the other end. It is quite possible that the other ends of the connection are still live and that the issue could very well be a timeout setting in the server config file instead of something in the TCP stack. This is what you should see when a keepalive occurs over an idle connection: * A TCP packet w/ 0 data sent to the remote * A response from the remote: Either a pure ACK, or a TCP RESET If no response occurs from the remote the keepalive code will then retry a couple of times over keepintvl (every 30 seconds in your case), and if it still gets no response after I think 3 retries (30+30+30 = 90 seconds later) it should terminate the connection state. -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Thu May 29 19:41:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F712106564A for ; Thu, 29 May 2008 19:41:04 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-b.inoc.net (mx1-b.inoc.net [64.246.131.28]) by mx1.freebsd.org (Postfix) with ESMTP id D11938FC19 for ; Thu, 29 May 2008 19:41:03 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=FHw3ER3/d/ko4feX/fmzcQbpVGepX7IhI8zbQjBFtLjzUJgB2mWRYqh2h13r+dYfvKpcstnmEIzQv2VerkgHCrHHBpmibXiz8DS8mIHF0LoNIy10VwZ2hTw74YBvkNJXAML5HEOoEcv8GW00bQwy2UtHvcZvhgxb2naUO1h8uz8=; Received: from void.ops.inoc.net (vanguard.noc.albyny.inoc.net [64.246.135.8]) by mx1-b.inoc.net (build v8.3.29) with ESMTP id 149673562-1941382 for multiple; Thu, 29 May 2008 19:41:00 +0000 (UTC) Message-Id: <66F73A31-847D-483D-B2C1-CC7E52484C7B@inoc.net> From: Robert Blayzor To: Matthew Dillon In-Reply-To: <200805291930.m4TJUeGX025815@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 15:41:00 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 19:41:04 -0000 On May 29, 2008, at 3:30 PM, Matthew Dillon wrote: > It is quite possible that the other ends of the connection are > still > live and that the issue could very well be a timeout setting in the > server config file instead of something in the TCP stack. Good point, I didn't think about this, but once i started getting over 1000 of these and it just kept growing, I started to rule it out, but I won't this time. I've moved the server over to 7.0 now which is taking load. I'm already thinking this problem is NOT fixed and is the same behavior as in 4.x because I'm seeing quite a few FIN_WAIT_1's collect now. [mirror0:~] netstat -an | grep FIN_WAIT_1 | wc -l I set the keepalive lower as I've mentioned, 15 mins and 30 sec intervals... I'll see if I have any specifically that stick around for a while and I'll try dumping one of those sessions and see.... -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Thu May 29 20:24:39 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAFFA1065672 for ; Thu, 29 May 2008 20:24:39 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx0-b.inoc.net (mx0-b.inoc.net [64.246.130.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC308FC1C for ; Thu, 29 May 2008 20:24:38 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=2WqBCDBJjtoznXQKBq9E1RmTNPyXGBu+QtMG9lpBR8UWyu8xxmIteTA5wkDTSyqMiYUkEksd6X280MZSEo0nBk0CTBX8gXhVNPbAcxOjnizuRSX8l4jPhxqf67AXdJHNqo3mMCd7VXU9W/uNdq14NeD0LH7rWSLf/nDj38E2Y0o=; Received: from void.ops.inoc.net (vanguard.noc.albyny.inoc.net [64.246.135.8]) by mx0-b.inoc.net (build v8.3.29) with ESMTP id 148977759-1941382 for multiple; Thu, 29 May 2008 20:24:34 +0000 (UTC) Message-Id: <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> From: Robert Blayzor To: Matthew Dillon In-Reply-To: <200805291930.m4TJUeGX025815@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 16:24:33 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 20:24:39 -0000 On May 29, 2008, at 3:30 PM, Matthew Dillon wrote: > It is quite possible that the other ends of the connection are > still > live and that the issue could very well be a timeout setting in the > server config file instead of something in the TCP stack. I think we're onto something here, but for some reason it doesn't make any sense. I have keepalives turned OFF in Apache: In the OS I have: net.inet.tcp.keepidle: 900000 net.inet.tcp.keepintvl: 30000 net.inet.tcp.keepinit: 75000 net.inet.tcp.always_keepalive: 1 I see FIN_WAIT_1 connections collecting like crazy again. I managed to investigate one that's been hung around for several minutes. 1.1.1.1 = our server ip 2.2.2.2 = remote client ip [mirror0:/usr/local/etc/apache22] netstat -an | grep 2.2.2.2 tcp4 0 25861 1.1.1.1.80 2.2.2.2.33379 FIN_WAIT_1 When I tcpdump this, I see something sending ack's back and forth every 60 seconds, but what? Apache? I'm not sure why. I don't see any timeouts in Apache for ~60 seconds. As you can see, sometimes we send an ack, but never see a reply. I'm gathering the OS level keepalives don't come into play because this session is not considered idle? 0:13:07.640426 IP 1.1.1.1.80 > 2.2.2.2.33379: . 4208136508:4208136509(1) ack 1471446041 win 520 20:13:07.736505 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:14:07.702647 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:15:07.764920 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:15:07.860988 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:16:07.827262 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:16:07.923341 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:17:07.889690 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:17:07.984770 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:18:07.952167 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:18:08.048249 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:19:08.014715 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:19:08.110803 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:20:08.077321 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:21:08.139995 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:21:08.236063 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:22:08.202435 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:22:08.297499 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:23:08.264631 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:23:08.360700 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 I'm finding several of these sessions doing the same exact thing.... -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Thu May 29 20:47:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E6321065678 for ; Thu, 29 May 2008 20:47:48 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 165698FC0C for ; Thu, 29 May 2008 20:47:41 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 54C1317D9A; Fri, 30 May 2008 06:47:40 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [119.11.34.115] (unknown [119.11.34.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id C038E17350; Fri, 30 May 2008 06:47:35 +1000 (EST) Message-ID: <483F165C.6030709@modulus.org> Date: Fri, 30 May 2008 06:47:24 +1000 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <483EBCDD.2070408@tzim.net> In-Reply-To: <483EBCDD.2070408@tzim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Arnaud Houdelette Subject: Re: Bad TCP performance with large MTU on 7-stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 20:47:48 -0000 Arnaud Houdelette wrote: > I also tried with tso disabled. Same results. Is it related to the re(4) > driver ? Or to the TCP stack ? Having used em driver with 7-RELEASE and 7-STABLE, I can assure you that large MTU size (9100) works well and gives 100mb/s transfer rates easily. So I can only conclude it is releated to the re driver. - Andrew From owner-freebsd-stable@FreeBSD.ORG Thu May 29 21:32:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4512F1065682 for ; Thu, 29 May 2008 21:32:45 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id CE7D48FC21 for ; Thu, 29 May 2008 21:32:44 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m4TLWiiK026721; Thu, 29 May 2008 14:32:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m4TLWhCv026720; Thu, 29 May 2008 14:32:43 -0700 (PDT) Date: Thu, 29 May 2008 14:32:43 -0700 (PDT) From: Matthew Dillon Message-Id: <200805292132.m4TLWhCv026720@apollo.backplane.com> To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 21:32:45 -0000 :I think we're onto something here, but for some reason it doesn't make :any sense. I have keepalives turned OFF in Apache: : :When I tcpdump this, I see something sending ack's back and forth :every 60 seconds, but what? Apache? I'm not sure why. I don't see :any timeouts in Apache for ~60 seconds. As you can see, sometimes we :send an ack, but never see a reply. I'm gathering the OS level :keepalives don't come into play because this session is not considered :idle? : : :0:13:07.640426 IP 1.1.1.1.80 > 2.2.2.2.33379: . :4208136508:4208136509(1) ack 1471446041 win 520 :20:13:07.736505 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 : :20:14:07.702647 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 : :20:15:07.764920 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 : :20:15:07.860988 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 : :20:16:07.827262 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 :... Yah, the connection is valid so keepalives do not come into play. What is happening is that 1.1.1.1 wants to send something to 2.2.2.2, but 2.2.2.2 is telling 1.1.1.1 that it has no buffer space (win 0). This forces the TCP stack on 1.1.1.1 (the kernel, not the apache server) to 'probe' the connection, which it appears to be doing once a minute. It is probing the connection waiting for 2.2.2.2 to tell it that buffer space is available (win != 0). The connection remains valid because 2.2.2.2 continues to respond to the probes. Now, the connection is also in a half-closed state, which means that one direction is closed. I can't tell which direction that is but my guess is that 1.1.1.1 (the apache server) closed the 1.1.1.1->2.2.2.2 direction and the 2.2.2.2 box has a broken TCP implementation and can't deal with it. :I'm finding several of these sessions doing the same exact thing.... : :-- :Robert Blayzor, BOFH :INOC, LLC I can suggest two things. First, the TCP connection is good but you still may be able to tell Apache, in the apache configuration file, to timeout after a certain period of time and clear the connection. Secondly, it may be beneficial to identify exactly what the client and server were talking about which caused the client to hang with a live tcp connection. The only way to do that is to tcpdump EVERYTHING going on related to the apache srever, save it to a big-ass disk partition (like 500G), and then when you see a stuck connection go back through the tcpdump log file and locate it, grep it out, and review what exactly it was talking about. You'd have to tcpdump with options to tell it to dump the TCP data payloads. It seems likely that the client is running an applet or javascript that receives a stream over the connection, and that applet or javascript program has locked up, causing the data sent from the server to build up and for the client's buffer space to run out, and start advertising the 0 window. -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Thu May 29 22:12:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E60DF10656B0 for ; Thu, 29 May 2008 22:12:02 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx0-a.inoc.net (mx0-a.inoc.net [64.246.130.30]) by mx1.freebsd.org (Postfix) with ESMTP id 85FAC8FC15 for ; Thu, 29 May 2008 22:12:02 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=IO5hi1UqlZhYQFRZRe0FdWovERIxls3wPsSvuHG3gAjscDMxlazVt8khQVCQjQz8EdrmwQPzcXNigDeTozMTbM5EYeb2H7j2WewsOVAFTq+34IOWSJMGNOzbFR3wohdUcBPvw+cpjXiCvzD+uHbjJxDmdnazxWVy/o2s1qDZDD0=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx0-a.inoc.net (build v8.3.29) with ESMTP id 157982838-1941382 for multiple; Thu, 29 May 2008 22:11:58 +0000 (UTC) Message-Id: From: Robert Blayzor To: Matthew Dillon In-Reply-To: <200805292132.m4TLWhCv026720@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 18:11:56 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 May 2008 22:12:03 -0000 On May 29, 2008, at 5:32 PM, Matthew Dillon wrote: > Now, the connection is also in a half-closed state, which means > that > one direction is closed. I can't tell which direction that is > but my > guess is that 1.1.1.1 (the apache server) closed the 1.1.1.1- > >2.2.2.2 > direction and the 2.2.2.2 box has a broken TCP implementation and > can't > deal with it. This is exactly what we're seeing, it's VERY strange. I did kill off Apache, and all the FIN_WAIT_1's stuck around, so the kernel is in fact sending these probe packets, every 60 seconds, which the client responds to... (most of the time). > I can suggest two things. First, the TCP connection is good but > you > still may be able to tell Apache, in the apache configuration > file, to > timeout after a certain period of time and clear the connection. I don't think this helps since Apache sees the connection as long gone. As far as Apache is concerned (as far as I can tell), this connection doesn't exist. This may be proved by killing off Apache, the connection still lives and while Apache is running, I have the max clients connected most of the time... so I don't think the linger around and jam up sockets to Apache. If they did, I think Apache would spiral down quite quickly. > Secondly, it may be beneficial to identify exactly what the > client and > server were talking about which caused the client to hang with a > live > tcp connection. The only way to do that is to tcpdump EVERYTHING > going > on related to the apache srever, save it to a big-ass disk > partition > (like 500G), and then when you see a stuck connection go back > through > the tcpdump log file and locate it, grep it out, and review what > exactly > it was talking about. You'd have to tcpdump with options to tell > it to > dump the TCP data payloads. Unfortunately it's not possible for me, not nearly enough space. This is a VERY busy server, a spikey 20Mbps+ (8-12Mbps on average) of web traffic almost constantly. The traffic is VERY static, just small data files and occasional large ones (12Mb+), but the majority are 2-5k files. (it's a clamav mirror server) > It seems likely that the client is running an applet or > javascript that > receives a stream over the connection, and that applet or > javascript > program has locked up, causing the data sent from the server to > build up > and for the client's buffer space to run out, and start > advertising the > 0 window. 98% of the clients are clamav (freshclam) clients on various platforms. Using p0f most of them are various flavors of Linux, but I can't say what OS the clients are connecting to for sure since I'd have to look at the OS finger print of the SYN packets... Don't get me wrong, the server keeps up well, low CPU, lots of RAM free, lots of network available, and 99% of all HTTP connections are completed just fine. I just see these FIN_WAIT_1 connections build up over time until the server runs out of socket space and then things just stop working. Only way to correct it seems to reboot the server... even under RELENG_7_0.... so the upgrade from 4_11 did not fix the problem. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 00:55:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50B771065672 for ; Fri, 30 May 2008 00:55:48 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9278FC0A for ; Fri, 30 May 2008 00:55:47 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m4U0tkm4027966; Thu, 29 May 2008 17:55:46 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m4U0tkqx027965; Thu, 29 May 2008 17:55:46 -0700 (PDT) Date: Thu, 29 May 2008 17:55:46 -0700 (PDT) From: Matthew Dillon Message-Id: <200805300055.m4U0tkqx027965@apollo.backplane.com> To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 00:55:48 -0000 :This is exactly what we're seeing, it's VERY strange. I did kill off :Apache, and all the FIN_WAIT_1's stuck around, so the kernel is in :fact sending these probe packets, every 60 seconds, which the client :responds to... (most of the time). Ach. Now that I think about it, it is still possible for it to happen that way. Apache closed the connection while there was still data in the scoket buffer to the client. The client then refused to read it, but otherwise left the connection alive. It's got to a be a bug on the client(s) in question. I can't think of anything else. You may have to resort to injecting a TCP RST packet (e.g. via a TUN device) to clear the connections. -Matt From owner-freebsd-stable@FreeBSD.ORG Fri May 30 01:16:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3FE3106566B for ; Fri, 30 May 2008 01:16:03 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-a.inoc.net (mx1-a.inoc.net [64.246.131.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0B28FC16 for ; Fri, 30 May 2008 01:16:03 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=YXSw5TDVt1WadKXfW2R4sLnObCZ797PJ0cEotjcM158tdhUbFsE/Q5bHhB083z7Mn5FOADopQoobNoDsgyA6BfyETghKVfSImwcJ/wjj5Juk2PqLQLM1l8i7X10bRpk2V2vT0FTfoI7ahfxOHrOb+29e/ZDSNArpUHdgvPg2j94=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx1-a.inoc.net (build v8.3.29) with ESMTP id 148556723-1941382 for multiple; Fri, 30 May 2008 01:15:58 +0000 (UTC) Message-Id: From: Robert Blayzor To: Matthew Dillon In-Reply-To: <200805300055.m4U0tkqx027965@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 21:15:55 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <200805300055.m4U0tkqx027965@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 01:16:04 -0000 On May 29, 2008, at 8:55 PM, Matthew Dillon wrote: > It's got to a be a bug on the client(s) in question. I can't think > of anything else. You may have to resort to injecting a TCP RST > packet (e.g. via a TUN device) to clear the connections. That would be most unpleasant... and also seems like some sort of exploit if a client and run a server out of socket buffers so easily. On a side note, I may be onto something... The server traffic right now is calming down, but it picks up... I made a change to the IPFW rules which basically went from something like: 100 permit tcp from any to any established 200 permit tcp from any to me 80 setup 300 deny log ip from any to me to: 100 check-state 150 deny tcp from any to any established 200 permit tcp from any to me 80 setup keep-state 300 deny log ip from any to me While the traffic is lower now, I don't see the FIN_WAIT_1's going up like I did before. At least I'm not going to count my chickens before they hatch. I'm going to watch this over the next 24 hours and see what comes up. Unfortunately if it doesn't end up being part of the solution I may have to resort to running some flavor of Linux 2.6 (*sob*). -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 03:07:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F9961065671 for ; Fri, 30 May 2008 03:07:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5278FC1A for ; Fri, 30 May 2008 03:07:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 28731 invoked by uid 399); 30 May 2008 03:19:20 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 May 2008 03:19:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <483F6F66.4050909@FreeBSD.org> Date: Thu, 29 May 2008 20:07:18 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080525) MIME-Version: 1.0 To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <200805300055.m4U0tkqx027965@apollo.backplane.com> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 03:07:21 -0000 Robert Blayzor wrote: > On May 29, 2008, at 8:55 PM, Matthew Dillon wrote: >> It's got to a be a bug on the client(s) in question. I can't think >> of anything else. You may have to resort to injecting a TCP RST >> packet (e.g. via a TUN device) to clear the connections. > > > > That would be most unpleasant... and also seems like some sort of > exploit if a client and run a server out of socket buffers so easily. There are way more exciting things about a web server to exploit. :) > On a side note, I may be onto something... The server traffic right now > is calming down, but it picks up... I made a change to the IPFW rules Hrrm, are you running ipfw ON the web server box? If so, I'd be curious as to why, and whether or not the problem goes away if you take IPFW out of the equation. If IPFW is running on another machine, never mind. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri May 30 04:42:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0D7E1065670 for ; Fri, 30 May 2008 04:42:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5C78FC1A for ; Fri, 30 May 2008 04:42:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4482286rvf.43 for ; Thu, 29 May 2008 21:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=QgU8zNgRZlRH91YtbQCBwyzxMeiCEO6aByQEObPo7nw=; b=wvKgMTCoHPjxucZ1Yd5SpQ7t0Vmkf+/TgkAznCE+bdPwc24mQuwHXFZvuOrwyqjK4BloO160y7fXdMvntSXBnvsQ5KqUXYTZ6ncUsCPcD7lA6hBj1LJSX4XaSESnxp1DK1puNrB4OWeyyzKRatSg2YEVyJ4WWSE07PQFwOP9Zso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=MRrPIZ+aYQw2i1Z3U+xIBbUZoTvKdhS9Ym11JNUa7wrW+GJKaqxWH5cMKfZry+WQWGcXztpdwHdSxEacdRYRobHNJjPw51ITlA9We9awHb+bml9aNsZ+TzxcnJuL9ojgVtlImHbAqUHcdJ7NBXP0G8dJtgitCz75LPYBGXOVlqw= Received: by 10.141.22.1 with SMTP id z1mr2724589rvi.277.1212122533918; Thu, 29 May 2008 21:42:13 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l31sm2277937rvb.6.2008.05.29.21.42.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 May 2008 21:42:12 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m4U4g8vD072953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2008 13:42:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m4U4g7x5072952; Fri, 30 May 2008 13:42:07 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 30 May 2008 13:42:07 +0900 From: Pyun YongHyeon To: Arnaud Houdelette Message-ID: <20080530044207.GH64177@cdnetworks.co.kr> References: <483EBCDD.2070408@tzim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <483EBCDD.2070408@tzim.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Bad TCP performance with large MTU on 7-stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 04:42:14 -0000 On Thu, May 29, 2008 at 04:25:33PM +0200, Arnaud Houdelette wrote: > I got really poor performance when I try to upload files to the box (via > pureFTP or Samba) when using jumbo frames somewhat above 2k. > > uname -a : > FreeBSD carenath.tzim.net 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 28 > 17:45:14 CEST 2008 > tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 > > It seems that TCP acks are delayed for about a second, so the upload > rate nevers goes above 60kB/s. I can provide wireshark captures done on > the box uploading the files if necessary. > The client is a Windows XP64 box, but I do not recall having the same > problem on 6.2. I did got about 100 MB/s for similar file transfers, but > I had to disable jumbo frames when I upgraded to 7.0-Release because of > some bug on txcsum/rxcsum on re(4) so I only noticed the issue recently. > > The txcsum bug doesn't seem to occur anymore, but now I have this > strange rate issue, with or without checksum offloading disabled. > I also tried with tso disabled. Same results. Is it related to the re(4) > driver ? Or to the TCP stack ? > It seems that handling jumbo frame in re(4) is one of trickiest feature. Would you show me the following information? - Captured tcpdump data on receiving side(i.e. host with re(4)) in your test. - dmesg output of re(4) - MTU size you've configured - output of "netstat -nd -I re0" - output of "ifconfig re0" -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Fri May 30 05:03:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663921065677 for ; Fri, 30 May 2008 05:03:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 218F58FC20 for ; Fri, 30 May 2008 05:03:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4487762rvf.43 for ; Thu, 29 May 2008 22:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=ST/OEtSNKdR1oHEiMhlf/GX/nzTDoyCZ80dic7sDbUo=; b=m5seiiDmbKU5Bo2ZxPgwzrQZ0mPJkli+XtYzTuqap8WOvGbuYnqmOIEUIzJuAs/ANXVVzVYD1haJu9Zsq4JWcq2NtkK9Qt1O+PlBnED7etSZpPFCmANV1aqSLFRzVjGgchIY1dDuglWS7sWjattWOUXv0SKwOO9BOt9ok58pRhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=nGJsQTve/yaG1gKcds1zYAZws+nK9UZudTjtBhnLpoKD3WFLYGbecJpJ2XZwLlO11Va0iRTjJT9PMXsurpgVkLj3stD0GGcUkIqD0epZay7Ss1XlL/uy3cP4wP0OL9X8DDV3p+nlQ/2w5mtxpeYnXEWqxEOz7QKDdIN+Kr+TogM= Received: by 10.141.212.5 with SMTP id o5mr2756419rvq.20.1212123795675; Thu, 29 May 2008 22:03:15 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l31sm2300759rvb.6.2008.05.29.22.03.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 May 2008 22:03:13 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m4U539OT073042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2008 14:03:09 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m4U538fk073041; Fri, 30 May 2008 14:03:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 30 May 2008 14:03:08 +0900 From: Pyun YongHyeon To: Dimitry Andric Message-ID: <20080530050308.GJ64177@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> <483E8F38.6070109@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <483E8F38.6070109@andric.com> User-Agent: Mutt/1.4.2.1i Cc: Gerrit K?hn , freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 05:03:16 -0000 On Thu, May 29, 2008 at 01:10:48PM +0200, Dimitry Andric wrote: > On 2008-05-29 11:58, Gerrit K?hn wrote: > > Can I do anything else? Is the newer patch (from yesterday) in your > > directory above worth giving a try? > > FYI, that patch doesn't compile, due to a typo... Fix below: > > --- re.HEAD.20080528.orig 2008-05-29 13:08:15.000000000 +0200 > +++ re.HEAD.20080528 2008-05-29 13:07:28.000000000 +0200 > @@ -352,7 +352,7 @@ > + if ((sc->rl_flags & RL_FLAG_PAR) != 0) { > + /* XXX Should have a way to get station address from EEPROM. */ > + uint32_t vpdc, word; > -+ int offet, verr; > ++ int offset, verr; > + > + if (pci_find_extcap(sc->rl_dev, PCIY_VPD, &vpdc) == 0) { > + for (offset = 0; offset < 0x20; offset += 4) { > > Thanks for pointing out! Since you're running this patch would you post dmesg output related with re(4)? Also please post the output of "devinfo -rv | grep oui". -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Fri May 30 06:48:59 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3202106566B; Fri, 30 May 2008 06:48:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id 5E80E8FC1B; Fri, 30 May 2008 06:48:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5AB2045C8C; Fri, 30 May 2008 08:48:56 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 687C74569A; Fri, 30 May 2008 08:48:51 +0200 (CEST) Date: Fri, 30 May 2008 08:48:52 +0200 From: Pawel Jakub Dawidek To: Joe Peterson Message-ID: <20080530064851.GA3596@garage.freebsd.pl> References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> <47ACF0AE.3040802@skyrush.com> <1202747953.27277.7.camel@buffy.york.ac.uk> <47B0A45C.4090909@skyrush.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <47B0A45C.4090909@skyrush.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum 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, 30 May 2008 06:48:59 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2008 at 12:39:08PM -0700, Joe Peterson wrote: > Gavin Atkinson wrote: > > Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt > > block before or after the datestamp of the file it was found within? > > i.e. was the corrupt block on the disk before or after the mp3 was > > written there? >=20 > Hi Gavin, those dated are later than the original copy (I do not have > the file timestamps to prove this, but according to my email record, I > am pretty sure of this). So the corrupt block is later than the > original write. >=20 > If this is the case, I assume that the block got written, by mistake, > into the middle of the mp3 file. Someone else suggested that it could > be caused by a bad transfer block number or bad drive command (corrupted > on the way to the drive, since these are not checksummed in the > hardware). If the block went to the wrong place, AND if it was a HW > glitch, I suppose the best ZFS could then do is retry the write (if its > failure was even detected - still not sure if ZFS does a re-check of the > disk data checksum after the disk write), not knowing until the later > scrub that the block had corrupted a file. ZFS doesn't verify checksum after write, it would be pointless for two reasons: 1. The read will come most likely from disk cache and not from the stable storage. 2. This would kill performance. ZFS test checksum only on read. What you observe is either a misdirected read/write (you asked to read/write sector X, but the data was read from or wrote to sector Y) or a phantom write (you asked to write, but the data never reach the disk, so you have old data there). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIP6NTForvXbEpPzQRAquWAKCV3zdQRV84Rgo2wOVqcTEpT+Sq+QCg5vsx dysO0Htb8e2R/zqPIzAJzGU= =GOYO -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-stable@FreeBSD.ORG Fri May 30 07:02:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B07E1065676 for ; Fri, 30 May 2008 07:02:50 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id F030D8FC19 for ; Fri, 30 May 2008 07:02:49 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C6F5845C9F; Fri, 30 May 2008 09:02:48 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 239C345685; Fri, 30 May 2008 09:02:44 +0200 (CEST) Date: Fri, 30 May 2008 09:02:44 +0200 From: Pawel Jakub Dawidek To: Arnaud Houdelette Message-ID: <20080530070244.GC3596@garage.freebsd.pl> References: <48341CF9.3040008@tzim.net> <20080529114556.GC3159@garage.freebsd.pl> <483E9A5D.4010702@tzim.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="da4uJneut+ArUgXk" Content-Disposition: inline In-Reply-To: <483E9A5D.4010702@tzim.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS on root and disk write caching. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 07:02:50 -0000 --da4uJneut+ArUgXk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 29, 2008 at 01:58:21PM +0200, Arnaud Houdelette wrote: > Pawel Jakub Dawidek a =E9crit : > >On Wed, May 21, 2008 at 03:00:41PM +0200, Arnaud Houdelette wrote: > >>3. I'd like to keep the storage pool (zraid1) separated from the system= =20 > >>pool (just one disk). The wiki states that we may encounter problems=20 > >>with more than one pool in use : is it still the case ? > >> =20 > > > >AFAIK it was never the case. Where did you find that information > >exactly? I've two systems that have more than one pool configured and > >never had any problems. > > =20 >=20 > It's clearly stated in the ZFS page of the FreeBSD Wiki : > http://wiki.freebsd.org/ZFSKnownProblems , 3rd entry states : > Kernel panic and/or data loss may result when more than one ZPOOL is=20 > active / in use. Symptoms: various, including (unverified) possibility=20 > of data loss. References:=20 > http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/004377.html >=20 > I'll try for myself then. Grr. I removed this totally bogus entry from the wiki. The problem reported in this e-mail is totally unrelated. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --da4uJneut+ArUgXk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIP6aUForvXbEpPzQRAuobAKCwyUt4xRoHz6lcnlFPME2RjuJSbACg1sJn XC9mp3Co8o6xE4+Y1yQrz4w= =QerB -----END PGP SIGNATURE----- --da4uJneut+ArUgXk-- From owner-freebsd-stable@FreeBSD.ORG Fri May 30 07:05:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75361065679 for ; Fri, 30 May 2008 07:05:34 +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 9BEF88FC19 for ; Fri, 30 May 2008 07:05:34 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 5E0801CC031; Fri, 30 May 2008 00:05:34 -0700 (PDT) Date: Fri, 30 May 2008 00:05:34 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20080530070534.GA25479@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: RELENG_7 amd64; memory and vm.kmem_size X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 07:05:34 -0000 As has been pointed out on wikis, mailing lists, and even on IRC, ZFS requires a bit of tuning -- specifically in regards to vm.kmem_size and vm.kmem_size_max. The opinion is: ZFS is memory-hungry. On my home RELENG_7 amd64 box (2GB RAM), I could panic the system with heavy I/O due to kmem_size being too small, until I used the following values: vm.kmem_size="1536M" vm.kmem_size_max="1536M" I decided to upgrade the box to 4GB of RAM, since I was worried about memory exhaustion under even higher loads (during heavy I/O with ZFS, I'd often see the "Wired" value in top reach 1.3-1.4GB). I received the RAM today, installed it, works fine. I then chose to adjust the vm.kmem_size and kmem_size_max settings to something larger, which seemed like the logical choice. I went with: vm.kmem_size="3584M" vm.kmem_size_max="3584M" Upon reboot, the kernel immediately panic'd with the following message: kmem_suballoc(): bad status return of 3. I then chose smaller values (going with 2048M); same panic. Can someone shed some light on this? I'm guessing it's intentional; from what I've found online, it seems to indicate that when the kmem_size value is set too large, there isn't enough memory available for allocation in other pieces of the kernel, hence the panic. I'm worried that there's a limit of some sort being hit, and that inadvertantly systems with lots of ZFS usage (multiple zpools comes to mind), one will not be able to increase kmem_size past ~1.5GB, despite how much memory is physically installed. -- | 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 Fri May 30 08:11:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5842C106567A for ; Fri, 30 May 2008 08:11:48 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id C91D28FC14 for ; Fri, 30 May 2008 08:11:47 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m4U8BiQR012140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2008 18:11:45 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m4U8BhNG009408; Fri, 30 May 2008 18:11:43 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m4U8BhNW009407; Fri, 30 May 2008 18:11:43 +1000 (EST) (envelope-from peter) Date: Fri, 30 May 2008 18:11:43 +1000 From: Peter Jeremy To: Robert Blayzor Message-ID: <20080530081143.GI1028@server.vk2pj.dyndns.org> References: <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 08:11:48 -0000 --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-May-29 18:11:56 -0400, Robert Blayzor wrot= e: >working. Only way to correct it seems to reboot the server... even under= =20 >RELENG_7_0.... so the upgrade from 4_11 did not fix the problem. Unfortunately, your issue is a bug in the client: The server is trying to send data and the client is continuously reporting that it is still around but can't accept the data right now. The server is behaving perfectly correctly. As a work-around, you could write a cronjob that scans "netstat" and temporarily creates an ipfw 'reset' rule that matches each FIN_WAIT_1 socket (possibly only if data is queued and/or matching packets that advertise a 0 windowsize). This rule would have to preceed any check-state rule. This is a hack but it will save you having to reboot the server. (Create them all with the same rule number and delete that rule number as the first step in the cronjob would handle rule cleanup). A real solution would require more thought. I suspect you need a mechanism similar to the keepalive timer that starts when there is data queued and is reset when (some) data is sent - this would catch your situation but I'm not sure if it's a general solution. I'm not sure if one of the existing TCP timers could be (ab)used to achieve this. --=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. --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg/tr8ACgkQ/opHv/APuIcQjQCfSXBGEFmmjlapdvMFO/ffnank UXEAoIoitdipH3k/+0H7aRoFIHJg89l/ =lMGg -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- From owner-freebsd-stable@FreeBSD.ORG Fri May 30 08:37:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25198106566B for ; Fri, 30 May 2008 08:37:40 +0000 (UTC) (envelope-from devin@spamcop.net) Received: from mail.distalzou.net (203.141.139.231.static.zoot.jp [203.141.139.231]) by mx1.freebsd.org (Postfix) with ESMTP id D0BCA8FC1B for ; Fri, 30 May 2008 08:37:39 +0000 (UTC) (envelope-from devin@spamcop.net) Received: from plexi.pun-pun.prv ([192.168.7.29]) by mail.distalzou.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K1zog-000B8n-Jb; Fri, 30 May 2008 17:18:26 +0900 Date: Fri, 30 May 2008 17:18:26 +0900 (JST) From: Tod McQuillin X-X-Sender: devin@plexi.pun-pun.prv To: Peter Jeremy In-Reply-To: <20080530081143.GI1028@server.vk2pj.dyndns.org> Message-ID: <20080530171642.S87269@plexi.pun-pun.prv> References: <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <20080530081143.GI1028@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Robert Blayzor Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 08:37:40 -0000 On Fri, 30 May 2008, Peter Jeremy wrote: > As a work-around, you could write a cronjob that scans "netstat" and > temporarily creates an ipfw 'reset' rule that matches each FIN_WAIT_1 > socket In the past, I've used something like this: netstat -an | grep FIN_WAIT_1 | perl -pe 's/.*\s((?:\d+\.){3}\d+)\.(\d+)\s*((?:\d+\.){3}\d+)\.(\d+).*/tcpdrop $1 $2 $3 $4/' | sh -x This relies on tcpdrop, included as /usr/sbin/tcpdrop on FreeBSD 6.x; you may need to install it from a port on FreeBSD 4.x. -- Tod McQuillin From owner-freebsd-stable@FreeBSD.ORG Fri May 30 08:42:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13F80106564A for ; Fri, 30 May 2008 08:42:16 +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 41D768FC13 for ; Fri, 30 May 2008 08:42:13 +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 SAA06960; Fri, 30 May 2008 18:41:43 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 30 May 2008 18:41:42 +1000 (EST) From: Ian Smith To: Robert Blayzor In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 08:42:16 -0000 On Thu, 29 May 2008, Robert Blayzor wrote: > On May 29, 2008, at 8:55 PM, Matthew Dillon wrote: > > It's got to a be a bug on the client(s) in question. I can't think > > of anything else. You may have to resort to injecting a TCP RST > > packet (e.g. via a TUN device) to clear the connections. > > > > That would be most unpleasant... and also seems like some sort of > exploit if a client and run a server out of socket buffers so easily. > > On a side note, I may be onto something... The server traffic right > now is calming down, but it picks up... I made a change to the IPFW > rules which basically went from something like: > > 100 permit tcp from any to any established > 200 permit tcp from any to me 80 setup > 300 deny log ip from any to me > > to: > > 100 check-state > 150 deny tcp from any to any established > 200 permit tcp from any to me 80 setup keep-state > 300 deny log ip from any to me I've just rescanned this thread, and noticed that your original ipfw rules (with your later correction including rule 100) were: 00100 allow tcp from any to any established 00200 allow tcp from any to me 80 setup 00200 allow icmp from any to me icmptype 0,3,8,11 00200 deny log ip from any to me Without debating your stateful alternative - either should work fine for TCP applications - this allowed inbound icmp packets for types 0,3,8,11 but no outbound icmp at all (assuming your firewall defaults to deny). I can't help wondering if allowing icmp outbound mightn't help, eg: 00300 allow icmp from me to any icmptype 0,3,8,11 but I know too little about the stack to be sure if TCP needs it, though suppose you'd want to negotiate MTU which needs icmptype 3 outbound .. and your later ruleset appears not to allow any icmp traffic at all. > While the traffic is lower now, I don't see the FIN_WAIT_1's going up > like I did before. At least I'm not going to count my chickens before > they hatch. I'm going to watch this over the next 24 hours and see > what comes up. Unfortunately if it doesn't end up being part of the > solution I may have to resort to running some flavor of Linux 2.6 > (*sob*). I used to see quite a few FIN_WAIT_1 that never went away and built up over months on a 2.2.6 system, but not since, including 4.x systems. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri May 30 08:47:28 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D3391065673 for ; Fri, 30 May 2008 08:47:28 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 5E7D88FC2A for ; Fri, 30 May 2008 08:47:27 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 30 May 2008 09:47:25 +0100 (BST) Date: Fri, 30 May 2008 09:47:24 +0100 From: David Malone To: Peter Jeremy Message-ID: <20080530084724.GA37672@walton.maths.tcd.ie> References: <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <20080530081143.GI1028@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080530081143.GI1028@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-stable@freebsd.org, Robert Blayzor Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 08:47:28 -0000 On Fri, May 30, 2008 at 06:11:43PM +1000, Peter Jeremy wrote: > A real solution would require more thought. I suspect you need a > mechanism similar to the keepalive timer that starts when there is > data queued and is reset when (some) data is sent - this would catch > your situation but I'm not sure if it's a general solution. I'm not > sure if one of the existing TCP timers could be (ab)used to achieve > this. There has been some talk about this sort of problem on the IETF TCP Maintainers list. I don't think any good conclusion was reached - whatever the solution was certainly needs to be tunable per-socket because this behaviour is perfectly valid in some situations but a bit of a pain in others. David. From owner-freebsd-stable@FreeBSD.ORG Fri May 30 09:09:39 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3681C106566B for ; Fri, 30 May 2008 09:09:39 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 72AA88FC16 for ; Fri, 30 May 2008 09:09:38 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:c895:3692:998f:52d4] (unknown [IPv6:2001:7b8:3a7:0:c895:3692:998f:52d4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 76A763C; Fri, 30 May 2008 11:09:36 +0200 (CEST) Message-ID: <483FC451.7060506@andric.com> Date: Fri, 30 May 2008 11:09:37 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.15pre (Windows/20080517) MIME-Version: 1.0 To: Pyun YongHyeon References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> <483E8F38.6070109@andric.com> <20080530050308.GJ64177@cdnetworks.co.kr> In-Reply-To: <20080530050308.GJ64177@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Gerrit_K=FChn?= , freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 09:09:39 -0000 On 2008-05-30 07:03, Pyun YongHyeon wrote: > Since you're running this patch would you post dmesg output related > with re(4)? Also please post the output of "devinfo -rv | grep > oui". dmesg ---------------------------------------------------------------------- Copyright (c) 1992-2008 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-STABLE #2: Thu May 29 13:00:50 CEST 2008 dim@vfbsd7.home.andric.com:/usr/obj/usr/src/sys/TENSOR Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: VIA Esther processor 1200MHz (1200.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6a9 Stepping = 9 Features=0xa7c9baff Features2=0x181 VIA Padlock Features=0x3fcc real memory = 518914048 (494 MB) avail memory = 498270208 (475 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1ede0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xf4000000-0xf7ffffff,0xfb000000-0xfbffffff irq 16 at device 0.0 on pci1 re0: port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:a6:f1:a8 re0: [FILTER] re1: port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0 re1: Chip rev. 0x18000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:a6:f1:a9 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: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xf900-0xf91f irq 21 at device 16.0 on pci0 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: [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: [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: [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: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: waiting for BIOS to give up control usb4: timed out waiting for BIOS 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 pci0: at device 17.5 (no driver attached) acpi_tz0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1200007233 Hz quality 800 Timecounters tick every 1.000 msec ad4: 114473MB at ata2-master SATA150 Trying to mount root from ufs:/dev/ad4s1a ---------------------------------------------------------------------- devinfo -rv ---------------------------------------------------------------------- nexus0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x74-0x7f 0x91-0x93 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x400-0x47f 0x4d0-0x4d1 0x500-0x50f 0x800-0x805 I/O memory addresses: 0xf0000-0xf3fff 0xf4000-0xf7fff 0xf8000-0xfbfff 0xfc000-0xfffff 0x1eee0000-0x1eefffff 0xfec00000-0xfecfffff 0xfee00000-0xfeefffff 0xfff80000-0xfffeffff 0xffff0000-0xffffffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x414 0x415 acpi_throttle0 est0 p4tcc0 acpi_perf0 cpufreq0 acpi_button0 pnpinfo _HID=PNP0C0C _UID=0 at handle=\_SB_.PWRB acpi_sysresource0 pnpinfo _HID=PNP0C01 _UID=0 at handle=\_SB_.MEM_ pcib0 pnpinfo _HID=PNP0A03 _UID=1 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x1106 device=0x0314 subvendor=0x1106 subdevice=0x0314 class=0x060000 at slot=0 function=0 I/O memory addresses: 0xe8000000-0xefffffff agp0 hostb1 pnpinfo vendor=0x1106 device=0x1314 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=0 function=1 hostb2 pnpinfo vendor=0x1106 device=0x2314 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=0 function=2 hostb3 pnpinfo vendor=0x1106 device=0x3208 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=0 function=3 hostb4 pnpinfo vendor=0x1106 device=0x4314 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=0 function=4 hostb5 pnpinfo vendor=0x1106 device=0x7314 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=0 function=7 pcib1 pnpinfo vendor=0x1106 device=0xb198 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=1 function=0 pci1 vgapci0 pnpinfo vendor=0x1106 device=0x3344 subvendor=0x1106 subdevice=0x3344 class=0x030000 at slot=0 function=0 I/O memory addresses: 0xf4000000-0xf7ffffff 0xfb000000-0xfbffffff drm0 re0 pnpinfo vendor=0x10ec device=0x8167 subvendor=0x16f3 subdevice=0x10ec class=0x020000 at slot=9 function=0 Interrupt request lines: 18 I/O ports: 0xf000-0xf0ff I/O memory addresses: 0xfdfff000-0xfdfff0ff miibus0 rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 re1 pnpinfo vendor=0x10ec device=0x8167 subvendor=0x16f3 subdevice=0x10ec class=0x020000 at slot=11 function=0 Interrupt request lines: 19 I/O ports: 0xf200-0xf2ff I/O memory addresses: 0xfdffe000-0xfdffe0ff miibus1 rgephy1 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 atapci0 pnpinfo vendor=0x1106 device=0x3149 subvendor=0x1106 subdevice=0x3149 class=0x01018f at slot=15 function=0 handle=\_SB_.PCI0.SATA Interrupt request lines: 20 I/O ports: 0xf400-0xf4ff 0xfb00-0xfb0f 0xfc00-0xfc03 0xfd00-0xfd07 0xfe00-0xfe03 0xff00-0xff07 ata2 ad4 subdisk4 ata3 atapci1 pnpinfo vendor=0x1106 device=0x0571 subvendor=0x1106 subdevice=0x0571 class=0x01018a at slot=15 function=1 handle=\_SB_.PCI0.PATA I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfa00-0xfa0f ata0 Interrupt request lines: 14 ata1 Interrupt request lines: 15 uhci0 pnpinfo vendor=0x1106 device=0x3038 subvendor=0x1106 subdevice=0x3038 class=0x0c0300 at slot=16 function=0 handle=\_SB_.PCI0.USB3 Interrupt request lines: 21 I/O ports: 0xf900-0xf91f usb0 uhub0 uhci1 pnpinfo vendor=0x1106 device=0x3038 subvendor=0x1106 subdevice=0x3038 class=0x0c0300 at slot=16 function=1 handle=\_SB_.PCI0.USB4 I/O ports: 0xf800-0xf81f usb1 uhub1 uhci2 pnpinfo vendor=0x1106 device=0x3038 subvendor=0x1106 subdevice=0x3038 class=0x0c0300 at slot=16 function=2 handle=\_SB_.PCI0.USB5 I/O ports: 0xf700-0xf71f usb2 uhub2 uhci3 pnpinfo vendor=0x1106 device=0x3038 subvendor=0x1106 subdevice=0x3038 class=0x0c0300 at slot=16 function=3 handle=\_SB_.PCI0.USB6 I/O ports: 0xf600-0xf61f usb3 uhub3 ehci0 pnpinfo vendor=0x1106 device=0x3104 subvendor=0x1106 subdevice=0x3104 class=0x0c0320 at slot=16 function=4 handle=\_SB_.PCI0.USB7 I/O memory addresses: 0xfdffd000-0xfdffd0ff usb4 uhub4 isab0 pnpinfo vendor=0x1106 device=0x3227 subvendor=0x1106 subdevice=0x3227 class=0x060100 at slot=17 function=0 handle=\_SB_.PCI0.VT86 isa0 adv0 aha0 aic0 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 psm0 bt0 cs0 ed0 fdc0 I/O ports: 0x3f7 fe0 ie0 le0 sc0 sio2 sio3 sn0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff vt0 orm0 pnpinfo pnpid=ORM0000 I/O memory addresses: 0xc0000-0xcffff pmtimer0 unknown pnpinfo vendor=0x1106 device=0x3059 subvendor=0x16f3 subdevice=0x4765 class=0x040100 at slot=17 function=5 handle=\_SB_.PCI0.AC97 I/O ports: 0xee00-0xeeff acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=2 at handle=\_SB_.PCI0.PMIO unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN0.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.CHN1.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PATA.CHN0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PATA.CHN0.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PATA.CHN0.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PATA.CHN1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PATA.CHN1.DRV0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PATA.CHN1.DRV1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.USB2 pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.PCI0.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.PCI0.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.PCI0.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.PCI0.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.PCI0.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.PCI0.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.PCI0.LNK0 pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.PCI0.LNK1 pci_link8 pnpinfo _HID=PNP0C0F _UID=9 at handle=\_SB_.PCI0.ALKA pci_link9 pnpinfo _HID=PNP0C0F _UID=10 at handle=\_SB_.PCI0.ALKB pci_link10 pnpinfo _HID=PNP0C0F _UID=11 at handle=\_SB_.PCI0.ALKC pci_link11 pnpinfo _HID=PNP0C0F _UID=12 at handle=\_SB_.PCI0.ALKD acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=1 at handle=\_SB_.PCI0.SYSR atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.PIC_ atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.DMA1 attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.TMR_ attimer1 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.RTC_ unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.SPKR npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.COPR sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.UAR1 Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.UAR2 Interrupt request lines: 3 I/O ports: 0x2f8-0x2ff unknown pnpinfo _HID=PNP0510 _UID=0 at handle=\_SB_.PCI0.IRDA ppc0 pnpinfo _HID=PNP0400 _UID=1 at handle=\_SB_.PCI0.LPT1 Interrupt request lines: 7 I/O ports: 0x378-0x37f ppbus0 plip0 lpt0 ppi0 unknown pnpinfo _HID=PNP0401 _UID=1 at handle=\_SB_.PCI0.ECP1 unknown pnpinfo _HID=PNP0F13 _UID=0 at handle=\_SB_.PCI0.PS2M unknown pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.PS2K unknown pnpinfo _HID=PNP0C02 _UID=3 at handle=\_SB_.PCI0.PSMR unknown pnpinfo _HID=PNP0C0B _UID=0 at handle=\_TZ_.FAN_ acpi_tz0 pnpinfo _HID=none _UID=0 at handle=\_TZ_.THRM acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x408-0x40b apic0 legacy0 ram0 I/O memory addresses: 0x0-0x9efff 0x100000-0x1eedffff npx0 ---------------------------------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Fri May 30 09:26:55 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE4791065686; Fri, 30 May 2008 09:26:55 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-b.inoc.net (mx1-b.inoc.net [64.246.131.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC018FC1E; Fri, 30 May 2008 09:26:55 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=b8ALbCwSy4Odny81ajkjMmSTNzvmFYNfZPYEQYx9u53P55/bPKJG3q5/N1RCBpPJiGlwUbe5axKXPvTlWmobGf1ZaOA2N6Vi03ysclNhxFWKzdwF8RV9hpeHZN+JgMzsHB3mYK8hZgqRarvRhG/megZ8OR7feoqKO1HqqLAanss=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx1-b.inoc.net (build v8.3.29) with ESMTP id 149767499-1941382 for multiple; Fri, 30 May 2008 09:26:54 +0000 (UTC) Message-Id: From: Robert Blayzor To: Doug Barton In-Reply-To: <483F6F66.4050909@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 05:26:51 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <200805300055.m4U0tkqx027965@apollo.backplane.com> <483F6F66.4050909@FreeBSD.org> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 09:26:56 -0000 On May 29, 2008, at 11:07 PM, Doug Barton wrote: > Hrrm, are you running ipfw ON the web server box? If so, I'd be > curious as to why, and whether or not the problem goes away if you > take IPFW out of the equation. If IPFW is running on another > machine, never mind. Yes, IPFW is running on the box. Why not? -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 09:32:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 225701065671 for ; Fri, 30 May 2008 09:32:04 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-a.inoc.net (mx1-a.inoc.net [64.246.131.30]) by mx1.freebsd.org (Postfix) with ESMTP id B46798FC19 for ; Fri, 30 May 2008 09:32:03 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=oQxJlgFZnToBLbrQb2/I8BFE4c1DB/AUiK7/L1ESH/ByyMIfFu/5NFH7lRePSPqwEs4H87s1y4/bYc2CTKYMuad2/IKhyBEVidgwhrENuODmk+2obGD6j+fWft0RLl+xiovLUN/b2YpM9y6dw8DsBdMEchJDEAmnGt6g9JCE3kM=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx1-a.inoc.net (build v8.3.29) with ESMTP id 148610351-1941382 for multiple; Fri, 30 May 2008 09:31:54 +0000 (UTC) Message-Id: <2F37E54D-BB78-431E-87D0-A7976BE203C3@inoc.net> From: Robert Blayzor To: Ian Smith In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 05:31:50 -0400 References: X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 09:32:04 -0000 On May 30, 2008, at 4:41 AM, Ian Smith wrote: > Without debating your stateful alternative - either should work fine > for > TCP applications - this allowed inbound icmp packets for types > 0,3,8,11 > but no outbound icmp at all (assuming your firewall defaults to deny). I didn't post all the rules, just the TCP based ones for the web server. I don't have an outbound send restriction. I believe I have a: permit ip from me to any out In there somewhere! ;-) -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 09:36:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A79541065674 for ; Fri, 30 May 2008 09:36:03 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-b.inoc.net (mx1-b.inoc.net [64.246.131.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2DDA48FC22 for ; Fri, 30 May 2008 09:36:03 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=APJIVBPQYIBIyxL5p6iDjkXSgKzwAd+cAcRF4Bycd8K4iC9b6wySjY8XCUobX85Q69KeoAhrvD9e1eOlhfFhp3pCmvmYNXWykWt4TqwuonGTsIq1Xum7RFCLny9paNFzOnGxxfLqu7+ZCHqQPUiNvmJPC/tK/6eWD3VZYHPh3DA=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx1-b.inoc.net (build v8.3.29) with ESMTP id 149768593-1941382 for multiple; Fri, 30 May 2008 09:35:59 +0000 (UTC) Message-Id: From: Robert Blayzor To: David Malone In-Reply-To: <20080530084724.GA37672@walton.maths.tcd.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 05:35:56 -0400 References: <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <20080530081143.GI1028@server.vk2pj.dyndns.org> <20080530084724.GA37672@walton.maths.tcd.ie> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 09:36:03 -0000 On May 30, 2008, at 4:47 AM, David Malone wrote: > There has been some talk about this sort of problem on the IETF TCP > Maintainers list. I don't think any good conclusion was reached - > whatever the solution was certainly needs to be tunable per-socket > because this behaviour is perfectly valid in some situations but a > bit of a pain in others. A timeout value would be fine. Obviously if the client keeps sending back packets with a 0 size, there should be some option or work around to tell the stack to drop the connection. There than to have the server lock up resources on a "dead connection". Unfortunately we're talking about the internet here, we can't insure that every one of the clients connecting to our servers behaves correctly! ;-) On a side note, I could easily fix this problem by frontending the server with a Cisco PIX or ASA. I believe they have "half closed" timers just for this purpose... Perhaps a kernel tunable knob would be a nice option/fix/hack also. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 09:38:41 2008 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 1915A106566B for ; Fri, 30 May 2008 09:38:41 +0000 (UTC) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5B28FC1A for ; Fri, 30 May 2008 09:38:28 +0000 (UTC) (envelope-from huang@gddsn.org.cn) Received: from tp.gddsn.org.cn (unknown [124.81.160.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id CAFC538CB89; Wed, 28 May 2008 23:10:20 +0800 (CST) Message-ID: <483D75D7.10907@gddsn.org.cn> Date: Wed, 28 May 2008 15:10:15 +0000 From: Huang wen hui User-Agent: Thunderbird 2.0.0.12 (X11/20080421) MIME-Version: 1.0 To: stable@freebsd.org, java Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: Subject: JDK+libthr on STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 09:38:41 -0000 hi, I try to run java to call external program heavily on very recent STABLE. Somtimes java hang on calling external program. ps show some process name. 11599 p9 RL+ 0:02.77 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell 12431 p9 R+ 0:00.00 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell 12432 p9 Z+ 0:00.01 12433 p9 R+ 0:00.00 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell 12434 p9 R+ 0:00.00 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell 12435 p9 RL+ 0:00.00 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell 12436 p9 R+ 0:00.00 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell 12438 p9 R+ 0:00.00 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell and top show java suck on umtxn status. Ctl+\ also could not dump hotspot info. Both JDK5 and JDK6 have same problem. But under FreeBSD 7.0R, the problem gone. Any ideas? This is the sample java code: import java.io.BufferedReader; import java.io.File; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.util.concurrent.Callable; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Future; public class TestShell { int maxTrial = 100; ExecutorService pool = Executors.newFixedThreadPool(10); private TrialThread[] tialThreads; public TestShell() { tialThreads = new TrialThread[maxTrial]; for (int i = 0; i < maxTrial; i++) { tialThreads[i] = new TrialThread(); } } public static void main(String[] args) { TestShell ts = new TestShell(); for (int i = 0; i < 100; i++) ts.test(); System.exit(0); } public void test() { Future[] futs = new Future[maxTrial]; for (int i = 0; i < maxTrial; i++) { // tialThreads[i].setTrialOrg(); futs[i] = pool.submit(tialThreads[i]); } try { for (int j = 0; j < tialThreads.length; j++) { // System.out.println(futs[j].isDone()); Boolean b = futs[j].get(); System.out.println("name: "+j+" "+b); } } catch (Exception ex) { ex.printStackTrace(); } } class TrialThread implements Callable { private ShellWrapper shell = new ShellWrapper(); public TrialThread() { } public Boolean call() { try { shell.shell(); } catch (Exception ex) { ex.printStackTrace(); } return new Boolean(true); } } } class ShellWrapper { public void shell() { //long now = System.currentTimeMillis(); try { final Process process = new ProcessBuilder( new String[]{ "/bin/test", ///home/hwh/try/locsat/src/LocSAT/LocSAT", "-s", "sta", "-d", "in", "-c" ,"ctl", "-o", "o" }) .directory(new File("/home/hwh/try/locsat/src/LocSAT/")) .redirectErrorStream(true).start(); /*final Process process = new ProcessBuilder(new String[] { "/bin/ls", "/" }).redirectErrorStream(true).start(); */ // System.out.println("process create time: // "+(System.currentTimeMillis()-now)); //new StreamGobbler(process.getInputStream()).start(); process.waitFor(); /** * XXX The current behavior dates back to the rewrite of the Process code * back in 1.2/1.3 which removed the dangerous buffering of all subprocess * output. In order to release all resources, user code must either invoke * Process.destroy or manually close the three subprocess streams */ // see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4784692 //process.getErrorStream().close(); //process.getInputStream().close(); //process.getOutputStream().close(); process.destroy(); // System.out.println("shell time: "+(System.currentTimeMillis()-now)); } catch (Exception ex) { ex.printStackTrace(); } } } class StreamGobbler extends Thread { private InputStream is; StreamGobbler(InputStream is) { this.is = is; } public void run() { try { BufferedReader br = new BufferedReader(new InputStreamReader(is)); while (br.readLine() != null) ; br.close(); } catch (IOException ioe) { ioe.printStackTrace(); } } } From owner-freebsd-stable@FreeBSD.ORG Fri May 30 09:41:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BCA4106568C for ; Fri, 30 May 2008 09:41:06 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx0-b.inoc.net (mx0-b.inoc.net [64.246.130.28]) by mx1.freebsd.org (Postfix) with ESMTP id 151EE8FC1E for ; Fri, 30 May 2008 09:41:05 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=mGDUdiY64+TwxsaJOcYwjQv5CmqSkG2WarR2hTO/z+ZhLcsx7QFpFzpi57cpJgIVvW3GJ7ca/JdJIZZphnkiVLC9GhmtabNhWsGtITtyuRbL56RVp+ID6Xs8DOdNYXbnWFdxj5MwEqjIVhUfpIyI8TSwHOM7Ma5STmWPe5XMU1E=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx0-b.inoc.net (build v8.3.29) with ESMTP id 149070551-1941382 for multiple; Fri, 30 May 2008 09:41:04 +0000 (UTC) Message-Id: <50A99D80-AB5A-4CBE-A38E-AC25F39D20CB@inoc.net> From: Robert Blayzor To: Tod McQuillin In-Reply-To: <20080530171642.S87269@plexi.pun-pun.prv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 05:41:00 -0400 References: <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <20080530081143.GI1028@server.vk2pj.dyndns.org> <20080530171642.S87269@plexi.pun-pun.prv> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 09:41:06 -0000 On May 30, 2008, at 4:18 AM, Tod McQuillin wrote: > This relies on tcpdrop, included as /usr/sbin/tcpdrop on FreeBSD > 6.x; you may need to install it from a port on FreeBSD 4.x. Thanks, that seems like a reasonable "band aid" for now. Worked perfectly. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 09:46:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB8E11065670 for ; Fri, 30 May 2008 09:46:21 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx0-b.inoc.net (mx0-b.inoc.net [64.246.130.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC1A8FC2C for ; Fri, 30 May 2008 09:46:21 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=MKyoe79BoIpQFEfTJIfmkC8lZjlGm2MGKd4kT4MAozSL12fNqsXQ+iGg3ztd1K6FoVfVQSaQUpdZqDg+70ZWgPHqPJWALOBszXz8jo5rYxy1Kxu8OJa8Irm1JOrAnU4Dgg5A96bhrzIpxygRrBgI2kU2fkSeg0l08NboflhYRrA=; Received: from [172.16.0.199] (cpe-67-240-119-200.nycap.res.rr.com [67.240.119.200]) by mx0-b.inoc.net (build v8.3.29) with ESMTP id 149071268-1941382 for ; Fri, 30 May 2008 09:46:21 +0000 (UTC) Message-Id: <9DBF00BA-5FD1-402A-8448-0D33B694EE1F@inoc.net> From: Robert Blayzor To: freebsd-stable@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 05:46:17 -0400 References: X-Mailer: Apple Mail (2.924) Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 09:46:22 -0000 On May 30, 2008, at 4:41 AM, Ian Smith wrote: > Without debating your stateful alternative - either should work fine > for > TCP applications - this allowed inbound icmp packets for types > 0,3,8,11 > but no outbound icmp at all (assuming your firewall defaults to deny). Switching the ipfw rules over to be stateful did not help, the server just wasn't busy enough. Overnight the FIN_WAIT_1's continued to pile up to over 600... and I'm sure they'll just keep going up until I have to reboot the box again. However Tod's suggestion to use a small sh script and tcpdrop seems to at least put a band-aid on things, so I don't have to reboot now. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 10:12:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C3331065676 for ; Fri, 30 May 2008 10:12:46 +0000 (UTC) (envelope-from peterjeremy@optushome.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 D1D338FC2A for ; Fri, 30 May 2008 10:12:45 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m4UACfX8003389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2008 20:12:43 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m4UACfwI009950; Fri, 30 May 2008 20:12:41 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m4UACffp009949; Fri, 30 May 2008 20:12:41 +1000 (EST) (envelope-from peter) Date: Fri, 30 May 2008 20:12:41 +1000 From: Peter Jeremy To: Robert Blayzor Message-ID: <20080530101241.GS1028@server.vk2pj.dyndns.org> References: <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <20080530081143.GI1028@server.vk2pj.dyndns.org> <20080530084724.GA37672@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h56sxpGKRmy85csR" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 10:12:46 -0000 --h56sxpGKRmy85csR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-May-30 05:35:56 -0400, Robert Blayzor wrot= e: >A timeout value would be fine. The problem is selecting a sensible timeout - 30-60s might be reasonable for a webserver that serves static content but is a bit short for a shell session... >On a side note, I could easily fix this problem by frontending the server= =20 >with a Cisco PIX or ASA. I believe they have "half closed" timers just fo= r=20 >this purpose... Perhaps a kernel tunable knob would be a nice=20 >option/fix/hack also. I don't think your problem is related to half-closed connections. You would get exactly the same behaviour if the server didn't close its end of the connection. OTOH, a long-lived half-closed connection is perfectly valid - many years ago, I wrote a tool that logged data in one direction only and so closed the other direction. I agree that a kernel tunable would be nice but I'm not in a position to write a suitable patch at present. --=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. --h56sxpGKRmy85csR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg/0xkACgkQ/opHv/APuIc57wCfYBPPNnvo9y0C5/lj2tWGhLHT YZkAoMD4/fMKTSpK5GpkHS5Ti55yxWop =ae4V -----END PGP SIGNATURE----- --h56sxpGKRmy85csR-- From owner-freebsd-stable@FreeBSD.ORG Fri May 30 11:04:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77AC51065673 for ; Fri, 30 May 2008 11:04:44 +0000 (UTC) (envelope-from darkgray@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4A18F8FC18 for ; Fri, 30 May 2008 11:04:44 +0000 (UTC) (envelope-from darkgray@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4607010rvf.43 for ; Fri, 30 May 2008 04:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=TaxUgaiFCKeD4K1QD7cQbfDUth+StDfYUWSFutgc1Bs=; b=rN7c7983WoHLqmulNxUCWltN9xfaCqjcltmwKo8dUkjv/KkpcCfrDKfxxaIFs/cDVPsPU8np4yoUVMVyA9JNBcCOrf6C4hD5eQhliOpKyx1mYaBCWzQ+J/dgwNEh0/C+unWOCnUn1FhfWYs7ZihIYJcUj5rBgGCjBydodZSl0g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=NKpi7FYe/XF9Aurtp3MWz8aHrki3wVo37yAjm9Sbbt6P9nz3Tzc9wOTmGXNBEejm3XyQDQ4lKiZYLYW4HpzyGdza5oC1gVOefqh5XJikoto2fxMbEMI08nHUN1lrpAmf1TpcBrL2rZmdCWRKJlAIuyTY0LGLIpva/gOEdySF1oM= Received: by 10.141.70.18 with SMTP id x18mr2884056rvk.284.1212143959276; Fri, 30 May 2008 03:39:19 -0700 (PDT) Received: by 10.141.34.16 with HTTP; Fri, 30 May 2008 03:39:19 -0700 (PDT) Message-ID: <7537818a0805300339s6520a060o553f5bdd9be032e@mail.gmail.com> Date: Fri, 30 May 2008 12:39:19 +0200 From: "Patrik Roos" Sender: darkgray@gmail.com To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: fb2997900221c349 Subject: 3Com NIC choking X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 11:04:44 -0000 Since getting my cable upgraded to 24Mbit down and 10Mbit up and getting excited with torrents, I've started experiencing weird errors with my 3Com NIC whenever it's being used at high speeds. It'll basically work fine for a while until it suddenly stops sending any packets and the connection to the switch is dropped, combined with this error message: xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes I can "fix" it by running ifconfig xl1 down; ifconfig xl1 up, but then it'll bork out again later on when it feels the traffic's too congested (which happens around 2MB/s torrent downloads, I think). The machine in question is FreeBSD 6.0-STABLE and works as a router, with two 3Coms, like so: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0x1000-0x107f mem 0xe8000000-0xe800007f irq 11 at device 14.0 on pci0 xl1: <3Com 3c905-TX Fast Etherlink XL> port 0x1080-0x10bf irq 10 at device 15.0 on pci0 xl0 is connected to the cable modem, xl1 is connected to the internal network switch, and the traffic should be pretty much the same on both interfaces, but only xl1 chokes, for some reason. In case this is interesting: xl0: flags=8843 mtu 1500 options=9 inet6 fe80::213:4bff:fe02:279d%xl0 prefixlen 64 scopeid 0x1 inet 84.254.172.155 netmask 0xffffe000 broadcast 255.255.255.255 ether 00:10:4b:07:27:9d media: Ethernet autoselect (100baseTX ) status: active xl1: flags=8847 mtu 1500 options=8 inet6 fe80::260:8ff:fe6d:3c00%xl1 prefixlen 64 scopeid 0x2 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:60:08:6d:3c:00 media: Ethernet autoselect (100baseTX ) status: active Any clues as to what I can do to stop it? Regards, Patrik Roos From owner-freebsd-stable@FreeBSD.ORG Fri May 30 11:44:45 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13221065674 for ; Fri, 30 May 2008 11:44:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD9E8FC0A for ; Fri, 30 May 2008 11:44:45 +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 m4UBihWg002205; Fri, 30 May 2008 13:44:43 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m4UBihd2002204; Fri, 30 May 2008 13:44:43 +0200 (CEST) (envelope-from olli) Date: Fri, 30 May 2008 13:44:43 +0200 (CEST) Message-Id: <200805301144.m4UBihd2002204@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, gerrit@pmp.uni-hannover.de In-Reply-To: <20080529205558.d2b064bf.gerrit@pmp.uni-hannover.de> 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, 30 May 2008 13:44:44 +0200 (CEST) Cc: Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, gerrit@pmp.uni-hannover.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 11:44:46 -0000 Gerrit Kühn wrote: > As Oliver already suggested, I will take out the controller and see what > happens then. > > Talking about this controller: This is also the only board I am using with > PCI cards (and thus with a PCI riser) at all. I remember vaguely that I > had a few problems getting the controller to work in the riser card when > it put the system together. The riser has two ports, and the controller > would only work in the upper one afaicr. That rings a bell ... I remember reports of riser cards that apparently changed the timing on the PCI bus so they were only marginally compliant with the spec, or maybe not even that anymore. If you try to remove the controller, please also remove the riser card. It could well be that it's causing problems, especially if it's on the same PCI bus as the onboard re(4) interfaces. There are various kinds of riser cards (passive, active, with fixed IRQs, or with jumpers, and so on). For a related discussion see this one, for example: http://lkml.org/lkml/2007/6/24/39 Typing "pci riser card jumper" in Google will give you many more pages with interesting (or frightening) stuff to read. 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 "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-stable@FreeBSD.ORG Fri May 30 11:49:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B57C1065676 for ; Fri, 30 May 2008 11:49:26 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id DB9BE8FC14 for ; Fri, 30 May 2008 11:49:25 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [82.95.250.254]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id m4UBnO1N009138; Fri, 30 May 2008 13:49:24 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.14.2/8.13.3) with ESMTP id m4UBnOsF052138; Fri, 30 May 2008 13:49:24 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.14.2/8.14.2/Submit) id m4UBnO2I052137; Fri, 30 May 2008 13:49:24 +0200 (CEST) (envelope-from wb) Date: Fri, 30 May 2008 13:49:24 +0200 From: Wilko Bulte To: freebsd-stable@freebsd.org, gerrit@pmp.uni-hannover.de Message-ID: <20080530114924.GB52107@freebie.xs4all.nl> References: <20080529205558.d2b064bf.gerrit@pmp.uni-hannover.de> <200805301144.m4UBihd2002204@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200805301144.m4UBihd2002204@lurza.secnetix.de> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 11:49:26 -0000 Quoting Oliver Fromme, who wrote on Fri, May 30, 2008 at 01:44:43PM +0200 .. > Gerrit Kühn wrote: > > As Oliver already suggested, I will take out the controller and see what > > happens then. > > > > Talking about this controller: This is also the only board I am using with > > PCI cards (and thus with a PCI riser) at all. I remember vaguely that I > > had a few problems getting the controller to work in the riser card when > > it put the system together. The riser has two ports, and the controller > > would only work in the upper one afaicr. > > That rings a bell ... > > I remember reports of riser cards that apparently changed > the timing on the PCI bus so they were only marginally > compliant with the spec, or maybe not even that anymore. > > If you try to remove the controller, please also remove > the riser card. It could well be that it's causing > problems, especially if it's on the same PCI bus as the > onboard re(4) interfaces. > > There are various kinds of riser cards (passive, active, > with fixed IRQs, or with jumpers, and so on). For a > related discussion see this one, for example: > http://lkml.org/lkml/2007/6/24/39 > > Typing "pci riser card jumper" in Google will give you > many more pages with interesting (or frightening) stuff > to read. Well, if you know how the PCI bus electrically works this kind of problem is hardly a surprise ;-) -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Fri May 30 11:50:34 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91AFD106566B; Fri, 30 May 2008 11:50:34 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 133BB8FC26; Fri, 30 May 2008 11:50:33 +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 m4UBoWBL002589; Fri, 30 May 2008 13:50:32 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m4UBoWoi002588; Fri, 30 May 2008 13:50:32 +0200 (CEST) (envelope-from olli) Date: Fri, 30 May 2008 13:50:32 +0200 (CEST) Message-Id: <200805301150.m4UBoWoi002588@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, koitsu@FreeBSD.ORG In-Reply-To: <20080530070534.GA25479@eos.sc1.parodius.com> 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, 30 May 2008 13:50:32 +0200 (CEST) Cc: Subject: Re: RELENG_7 amd64; memory and vm.kmem_size X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, koitsu@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 11:50:34 -0000 Jeremy Chadwick wrote: > [...] > vm.kmem_size="3584M" > vm.kmem_size_max="3584M" > > Upon reboot, the kernel immediately panic'd with the following message: > > kmem_suballoc(): bad status return of 3. > > I then chose smaller values (going with 2048M); same panic. I remember someone on the -fs list explained that there's currently a hard limit for kmem at 2 GB minus epsilon. So I suggest trying to set it to slightly less than 2 GB. And yes, I agree that is unfortunate, because there are high ZFS workloads where more than 2 GB kmem would be useful. I hope this design limitation can be alleviated somehow in the future. 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 "The last good thing written in C was Franz Schubert's Symphony number 9." -- Erwin Dieterich From owner-freebsd-stable@FreeBSD.ORG Fri May 30 12:45:13 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994B81065716 for ; Fri, 30 May 2008 12:45:13 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6FD8FC19 for ; Fri, 30 May 2008 12:45:12 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4UCj98L001249; Fri, 30 May 2008 14:45:11 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 12D194F; Fri, 30 May 2008 14:45:10 +0200 (CEST) Date: Fri, 30 May 2008 14:45:10 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@FreeBSD.ORG Message-Id: <20080530144510.c1e1be28.gerrit@pmp.uni-hannover.de> In-Reply-To: <200805301144.m4UBihd2002204@lurza.secnetix.de> References: <20080529205558.d2b064bf.gerrit@pmp.uni-hannover.de> <200805301144.m4UBihd2002204@lurza.secnetix.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.30.53115 Cc: Oliver Fromme Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 12:45:13 -0000 On Fri, 30 May 2008 13:44:43 +0200 (CEST) Oliver Fromme wrote about Re: broken re(4): OF> > Talking about this controller: This is also the only board I am OF> > using with PCI cards (and thus with a PCI riser) at all. I remember OF> > vaguely that I had a few problems getting the controller to work in OF> > the riser card when it put the system together. The riser has two OF> > ports, and the controller would only work in the upper one afaicr. OF> That rings a bell ... OF> I remember reports of riser cards that apparently changed OF> the timing on the PCI bus so they were only marginally OF> compliant with the spec, or maybe not even that anymore. Meanwhile I played through all combinations, and guess what? I can get rid of the problems in two ways: 1. Taking out the controller card. Without the controller, everthing works fine. The riser is still in. 2. Turn of rxcsum and txcsum. The driver can only turn them on or off together. They're on by default, and turning them off also lets the problems vanish. OF> If you try to remove the controller, please also remove OF> the riser card. It could well be that it's causing OF> problems, especially if it's on the same PCI bus as the OF> onboard re(4) interfaces. Somehow the controller seems to interfer with rxc/txc. OF> There are various kinds of riser cards (passive, active, OF> with fixed IRQs, or with jumpers, and so on). For a OF> related discussion see this one, for example: OF> http://lkml.org/lkml/2007/6/24/39 OF> Typing "pci riser card jumper" in Google will give you OF> many more pages with interesting (or frightening) stuff OF> to read. Thanks for the hint, now I have something to read over the weekend. ;-) For now, I am happy that I have a working system (with controller ands disks inside). It seems to me that the transfer rates with rxc/txc turned off are a bit lower, but it is much more important to me that the networking runs reliably. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri May 30 12:48:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DF231065674 for ; Fri, 30 May 2008 12:48:06 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id CE48C8FC16 for ; Fri, 30 May 2008 12:48:05 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4UClxtg001426; Fri, 30 May 2008 14:48:00 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8C3544F; Fri, 30 May 2008 14:47:59 +0200 (CEST) Date: Fri, 30 May 2008 14:47:59 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Wilko Bulte Message-Id: <20080530144759.d8c4b8c3.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080530114924.GB52107@freebie.xs4all.nl> References: <20080529205558.d2b064bf.gerrit@pmp.uni-hannover.de> <200805301144.m4UBihd2002204@lurza.secnetix.de> <20080530114924.GB52107@freebie.xs4all.nl> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.30.53622 Cc: freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 12:48:06 -0000 On Fri, 30 May 2008 13:49:24 +0200 Wilko Bulte wrote about Re: broken re(4): WB> > Typing "pci riser card jumper" in Google will give you WB> > many more pages with interesting (or frightening) stuff WB> > to read. WB> Well, if you know how the PCI bus electrically works this kind of WB> problem is hardly a surprise ;-) Well, the riser that came with this 1HU-chassis is probably even more frightening: it plugs into the pci port and uses a short ribbon cable to connect to an extra board which holds the cards. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri May 30 13:32:51 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02A031065679 for ; Fri, 30 May 2008 13:32:51 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 76ED08FC26 for ; Fri, 30 May 2008 13:32:50 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4UDWjQI004697; Fri, 30 May 2008 15:32:46 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8E5534F; Fri, 30 May 2008 15:32:45 +0200 (CEST) Date: Fri, 30 May 2008 15:32:45 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@FreeBSD.ORG Message-Id: <20080530153245.13a78d69.gerrit@pmp.uni-hannover.de> In-Reply-To: <200805301144.m4UBihd2002204@lurza.secnetix.de> References: <20080529205558.d2b064bf.gerrit@pmp.uni-hannover.de> <200805301144.m4UBihd2002204@lurza.secnetix.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.30.61658 Cc: Oliver Fromme Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 13:32:51 -0000 On Fri, 30 May 2008 13:44:43 +0200 (CEST) Oliver Fromme wrote about Re: broken re(4): OF> That rings a bell ... OF> I remember reports of riser cards that apparently changed OF> the timing on the PCI bus so they were only marginally OF> compliant with the spec, or maybe not even that anymore. You're perfectly right... I just took out the riser card and plugged the controller into the pci slot of the board directly - all problems gone, even with txc/rxc turned on. I still do not know how the riser interfers with the checksum offloading, but I guess I should look out for a better riser card - although Wilkos comment already lets me fear that there is no such thing as a "good" riser card... cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri May 30 13:34:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0B31065675 for ; Fri, 30 May 2008 13:34:41 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id D526B8FC1C for ; Fri, 30 May 2008 13:34:40 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m4UDYbcR004807; Fri, 30 May 2008 15:34:38 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 49BF94F; Fri, 30 May 2008 15:34:37 +0200 (CEST) Date: Fri, 30 May 2008 15:34:37 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: pyunyh@gmail.com Message-Id: <20080530153437.7a2ffdf5.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080530050308.GJ64177@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <20080528002823.GA63696@cdnetworks.co.kr> <20080528175610.0ffe4c1c.gerrit@pmp.uni-hannover.de> <20080529115825.2da70cba.gerrit@pmp.uni-hannover.de> <483E8F38.6070109@andric.com> <20080530050308.GJ64177@cdnetworks.co.kr> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.30.61658 Cc: Dimitry Andric , freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 13:34:41 -0000 On Fri, 30 May 2008 14:03:08 +0900 Pyun YongHyeon wrote about Re: broken re(4): PY> Since you're running this patch would you post dmesg output related PY> with re(4)? Also please post the output of "devinfo -rv | grep PY> oui". Here is my output with the latest (28th May) patch: rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 rgephy1 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 re0: port 0xea00-0xeaff mem 0xfdffe000-0xfdffe0ff irq 10 at device 9.0 on pci0 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:af:19:6a re0: [FILTER] re1: port 0xec00-0xecff mem 0xfdffd000-0xfdffd0ff irq 10 at device 11.0 on pci0 re1: Chip rev. 0x18000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:af:19:6b re1: [FILTER] cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri May 30 13:58:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D69E21065672 for ; Fri, 30 May 2008 13:58:46 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC588FC23 for ; Fri, 30 May 2008 13:58:46 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [82.95.250.254]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id m4UDwiLm009181; Fri, 30 May 2008 15:58:45 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.14.2/8.13.3) with ESMTP id m4UDwiaF052766; Fri, 30 May 2008 15:58:44 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.14.2/8.14.2/Submit) id m4UDwiNv052765; Fri, 30 May 2008 15:58:44 +0200 (CEST) (envelope-from wb) Date: Fri, 30 May 2008 15:58:44 +0200 From: Wilko Bulte To: Gerrit =?iso-8859-1?Q?K=FChn?= Message-ID: <20080530135844.GC52712@freebie.xs4all.nl> References: <20080529205558.d2b064bf.gerrit@pmp.uni-hannover.de> <200805301144.m4UBihd2002204@lurza.secnetix.de> <20080530114924.GB52107@freebie.xs4all.nl> <20080530144759.d8c4b8c3.gerrit@pmp.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080530144759.d8c4b8c3.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 13:58:46 -0000 Quoting Gerrit Khn, who wrote on Fri, May 30, 2008 at 02:47:59PM +0200 .. > On Fri, 30 May 2008 13:49:24 +0200 Wilko Bulte > wrote about Re: broken re(4): > > WB> > Typing "pci riser card jumper" in Google will give you > WB> > many more pages with interesting (or frightening) stuff > WB> > to read. > > WB> Well, if you know how the PCI bus electrically works this kind of > WB> problem is hardly a surprise ;-) > > Well, the riser that came with this 1HU-chassis is probably even more > frightening: it plugs into the pci port and uses a short ribbon cable to > connect to an extra board which holds the cards. Hmmm... brr.... -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Fri May 30 14:42:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 378F81065678 for ; Fri, 30 May 2008 14:42:41 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id CCED68FC0C for ; Fri, 30 May 2008 14:42:40 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-064-185-208.pools.arcor-ip.net [88.64.185.208]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1K25cK0soF-0007bc; Fri, 30 May 2008 16:30:04 +0200 Received: (qmail 64836 invoked from network); 30 May 2008 14:28:12 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 30 May 2008 14:28:12 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Fri, 30 May 2008 16:29:54 +0200 User-Agent: KMail/1.9.9 References: <483EA513.4070409@earthlink.net> <20080530084724.GA37672@walton.maths.tcd.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805301629.54542.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/BsmQlJw6bAh8GHwF4icsgEWFXEtec9QQnBRV wn/RAig39CTFRk5mqusBDzewefSzfdwutN3AkVJXZaCC5VTPVw YlpFytA0beqm8cKosEcTQ== Cc: David Malone , Robert Blayzor Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 14:42:41 -0000 On Friday 30 May 2008 11:35:56 Robert Blayzor wrote: > On May 30, 2008, at 4:47 AM, David Malone wrote: > > There has been some talk about this sort of problem on the IETF TCP > > Maintainers list. I don't think any good conclusion was reached - > > whatever the solution was certainly needs to be tunable per-socket > > because this behaviour is perfectly valid in some situations but a > > bit of a pain in others. > > A timeout value would be fine. Obviously if the client keeps sending > back packets with a 0 size, there should be some option or work around > to tell the stack to drop the connection. There than to have the > server lock up resources on a "dead connection". Unfortunately we're > talking about the internet here, we can't insure that every one of the > clients connecting to our servers behaves correctly! ;-) > > On a side note, I could easily fix this problem by frontending the > server with a Cisco PIX or ASA. I believe they have "half closed" > timers just for this purpose... Perhaps a kernel tunable knob would be > a nice option/fix/hack also. pf does that, too. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Fri May 30 16:43:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F52B106566B for ; Fri, 30 May 2008 16:43:30 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 001678FC0A for ; Fri, 30 May 2008 16:43:29 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m4UGhSK4033919; Fri, 30 May 2008 09:43:28 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m4UGhSa0033918; Fri, 30 May 2008 09:43:28 -0700 (PDT) Date: Fri, 30 May 2008 09:43:28 -0700 (PDT) From: Matthew Dillon Message-Id: <200805301643.m4UGhSa0033918@apollo.backplane.com> To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <200805300055.m4U0tkqx027965@apollo.backplane.com> <483F6F66.4050909@FreeBSD.org> Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 16:43:30 -0000 :Yes, IPFW is running on the box. Why not? : :-- :Robert Blayzor, BOFH :INOC, LLC :rblayzor@inoc.net :http://www.inoc.net/~rblayzor/ There's nothing wrong with running IPFW on the same box :-) But, I think that rule change is masking the problem rather then solving it. The keep-state is limited. The reason the number of dead connections isn't going up is probably because IPFW is either hitting its keep-state limit and dropping connections, or the connection becomes idle long enough for IPFW to recycle the keep-state for it, also causing it to drop. Once the keep-state is lost that deny established rule will cause the connection to fail. I would be very careful with any type of ruleset (IPFW or PF) which relies on keep-state. You can wind up causing legitimate connections to drop if it isn't carefully tuned. It might be a reasonable bandaid, though. -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Fri May 30 17:34:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24C89106567B for ; Fri, 30 May 2008 17:34:18 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-a.inoc.net (mx1-a.inoc.net [64.246.131.30]) by mx1.freebsd.org (Postfix) with ESMTP id CF4608FC21 for ; Fri, 30 May 2008 17:34:17 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=3Kgzyd9seIeoRQ1YwIbZVdp0C/iID6DgXV8rrpF7aa7k3u9hfWT4zn5Gth+VWUBbEAu0+gXTGaIoy/NBA3w8flbop7TnUzh8pkvbvVn3Qa6HHaPgyWtQ2bKs5Fit1dgIkrx1RXTZEuBxYrhMwsHaQNVZ82qYAc43eX4yDJLRZRM=; Received: from void.ops.inoc.net (vanguard.noc.albyny.inoc.net [64.246.135.8]) by mx1-a.inoc.net (build v8.3.29) with ESMTP id 148685672-1941382 for multiple; Fri, 30 May 2008 17:34:13 +0000 (UTC) Message-Id: <69B2392D-E349-4E29-B028-900C8D1693A8@inoc.net> From: Robert Blayzor To: Matthew Dillon In-Reply-To: <200805301643.m4UGhSa0033918@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 13:34:13 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <200805300055.m4U0tkqx027965@apollo.backplane.com> <483F6F66.4050909@FreeBSD.org> <200805301643.m4UGhSa0033918@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 17:34:18 -0000 On May 30, 2008, at 12:43 PM, Matthew Dillon wrote: > I would be very careful with any type of ruleset (IPFW or PF) which > relies on keep-state. You can wind up causing legitimate > connections > to drop if it isn't carefully tuned. Thanks again Matt... I do agree on the firewall and keep-state and scaling issue. It wasn't the magic bullet I thought it may have been. The stuck connections just dropped off due to the load dropping at night. The bandaid I have is the tcpdrop hack that was posted here. That seems to clear all the stuck sessions. While it's probably not the best thing to do, it protects the server at least. I don't know what more to do at this point. While these may be broken client issues, it's breaking the server. I don't know if it makes sense to push something upstream to see if some type of knob can be implemented into the network stack to force close/drop these or to just let it go and deal with it as-is. I have a message into the clamav-devel list to see if this is a problem on the freshclam client and the way it handles closing connections/broken connections. It's quite possible it's something broken in freshclam where it's failing to deal with a network failure properly.... -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Fri May 30 19:17:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5C291065673 for ; Fri, 30 May 2008 19:17:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9478FC27 for ; Fri, 30 May 2008 19:17:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 5070 invoked by uid 399); 30 May 2008 19:29:22 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 May 2008 19:29:22 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <484052B7.2050906@FreeBSD.org> Date: Fri, 30 May 2008 12:17:11 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080525) MIME-Version: 1.0 To: Robert Blayzor References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <200805300055.m4U0tkqx027965@apollo.backplane.com> <483F6F66.4050909@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 19:17:13 -0000 Robert Blayzor wrote: > On May 29, 2008, at 11:07 PM, Doug Barton wrote: >> Hrrm, are you running ipfw ON the web server box? If so, I'd be >> curious as to why, and whether or not the problem goes away if you >> take IPFW out of the equation. If IPFW is running on another machine, >> never mind. > > > > Yes, IPFW is running on the box. Why not? I'm not sure why, but I sense hostility on your part. I'm not sure why, since that is an odd reaction to someone who is trying to help you. If I'm wrong about that, never mind. A basic rule of system administration is to have a good reason for everything you do. If you have some kind of need for a firewall on your web server, that's fine. Personally I prefer not to run firewalls on application servers, but TIMTOWTDI. The real crux of my question (which you did not answer) is, does the problem go away if you take IPFW completely out of the equation? If the answer to that is yes, it greatly narrows the focus of the investigation. I think that the theories that have been proposed by others that the FIN_WAITs are a symptom of a problem in the clients is not only possible, it's likely. I'm just not sure it's the complete story. In any case, I wish you luck with this, I think I've done all the good I can do here. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri May 30 19:30:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37701065677; Fri, 30 May 2008 19:30:50 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mx1-b.inoc.net (mx1-b.inoc.net [64.246.131.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7792B8FC14; Fri, 30 May 2008 19:30:50 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=U4FgiWrSOUPDudjzMa5eb55t/fn+hL5Fu5haiMvBj3IgCY8MpiVFVx29x8ZiHqBWAeRPf0wJOqc1eOxGXQZT8TGA8sARwNWAO8HbylMR7rUXSkvSOSCXydm9/W5eaVqSoCeNOWxf3uCVkIxfgIWnZXHJxaCR17UyfvGRv3UKSAw=; Received: from void.ops.inoc.net (vanguard.noc.albyny.inoc.net [64.246.135.8]) by mx1-b.inoc.net (build v8.3.29) with ESMTP id 149862239-1941382 for multiple; Fri, 30 May 2008 19:30:49 +0000 (UTC) Message-Id: From: Robert Blayzor To: Doug Barton In-Reply-To: <484052B7.2050906@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 15:30:49 -0400 References: <1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com> <23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net> <483DE2E0.90003@FreeBSD.org> <483E36CE.3060400@FreeBSD.org> <483E3C26.3060103@paradise.net.nz> <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <200805300055.m4U0tkqx027965@apollo.backplane.com> <483F6F66.4050909@FreeBSD.org> <484052B7.2050906@FreeBSD.org> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 May 2008 19:30:50 -0000 On May 30, 2008, at 3:17 PM, Doug Barton wrote: > I'm not sure why, but I sense hostility on your part. I'm not sure > why, since that is an odd reaction to someone who is trying to help > you. If I'm wrong about that, never mind. I'm not being hostile, geez. ;) I simply asked "why not"? Plenty of people do it, and with good reason. It's always been effective, if this is some sort of an IPFW load issue, then surely I concede your point to use an external firewall, which I can do with basic external router ACL's. > A basic rule of system administration is to have a good reason for > everything you do. If you have some kind of need for a firewall on > your web server, that's fine. Personally I prefer not to run > firewalls on application servers, but TIMTOWTDI. Of course, but every situation is different. In this case, an external firewall is not available and the application doesn't really require it, so simple IPFW rules are sufficient. > The real crux of my question (which you did not answer) is, does the > problem go away if you take IPFW completely out of the equation? If > the answer to that is yes, it greatly narrows the focus of the > investigation. No, turning IPFW off does not make the problem go away. I originally thought of this when the issue came up. I've tried with and without both the http accept filter and IPFW. > I think that the theories that have been proposed by others that the > FIN_WAITs are a symptom of a problem in the clients is not only > possible, it's likely. I'm just not sure it's the complete story. I'm thinking it probably is bad client behavior. I'm leaning toward all of the freshclam clients not handling a network error correctly. It's quite possible when something in the connection fouls up the client, it just behaves badly. I don't know much about how freshclam uses sockets, I'm trying to figure that out now. (if they use some native code, http library, etc). It not might even be that at all, but it's a good starting point. The other half of the story however is if it's that easy to hose up TCP sockets on a server, that's a bigger problem IMHO. :-/ -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/