From owner-freebsd-arch@FreeBSD.ORG Sun Nov 6 22:24:04 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1E7B16A41F for ; Sun, 6 Nov 2005 22:24:04 +0000 (GMT) (envelope-from rink@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F4BA43D6D for ; Sun, 6 Nov 2005 22:24:00 +0000 (GMT) (envelope-from rink@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id C1FBCA300B; Sun, 6 Nov 2005 23:23:59 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1796) id AB3E02288B; Sun, 6 Nov 2005 23:23:59 +0100 (CET) Date: Sun, 6 Nov 2005 23:23:59 +0100 From: Rink Springer To: freebsd-arch@freebsd.org Message-ID: <20051106222359.GC46752@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline X-Editor: Vim http://www.vim.org/ X-Info: http://rink.nu/ X-Operating-System: FreeBSD 5.4-RELEASE i386 User-Agent: Mutt/1.5.11 Cc: ed@fxq.nl Subject: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 22:24:04 -0000 --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, I'd like to present my 7.0-CURRENT XBOX patches. If you put 'options XBOX' in your kernel after applying this patch, you will get a kernel that is bootable on both ordinary i386 PC's as well as XBOX'es. 'device xboxfb' is an XBOX-capable frame buffer. You can download the patches from http://rink.nu/downloads/xbox-patches/xbox-7-current.diff. I hope this patch will be committed to the FreeBSD source tree. Let me know any suggestions for improvements. The XBOX option depends on I686_CPU and will error out if it is not supplied. The overall patch is just over 1000 lines, mainly due to the framebuffer driver. You will need the most recent CVS version of Cromwell [1], as it now fakes FreeBSD boot info so the initial entry won't halt the CPU. This removes the patches in the locore.s file. For some reason, the kernel will not work fine if you have syscons in your kernel. This only affects the XBOX, so either syscons crashes it somehow or it gets a higher priority. However, as the current framedriver driver needs to be syscon(4)-ized, I intend to port the framebuffer to the VESA framework. Assistance on this is very welcome. Finally, I am willing to maintain this so future FreeBSD's will run on the XBOX without any issues. Work is underway for the nForce ethernet as well as an improved syscons(4)-able console driver. [1] This is the Linux BIOS for the XBOX; it was patched in order to boot FreeBSD correctly. --=20 Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDboJ/b3O60uztv/8RAq4PAJ4/BK6U83pmn/w74TgiMK8JPUa3OgCgiG18 vVJkdcH2xg7c3dE9Kom9YmE= =0JhH -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 05:36:29 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9BCA16A41F for ; Mon, 7 Nov 2005 05:36:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54AAE43D46 for ; Mon, 7 Nov 2005 05:36:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA75YaX9003235; Sun, 6 Nov 2005 22:34:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 06 Nov 2005 22:35:03 -0700 (MST) Message-Id: <20051106.223503.97843133.imp@bsdimp.com> To: rink@stack.nl From: "M. Warner Losh" In-Reply-To: <20051106222359.GC46752@stack.nl> References: <20051106222359.GC46752@stack.nl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 06 Nov 2005 22:34:41 -0700 (MST) Cc: ed@fxq.nl, freebsd-arch@FreeBSD.ORG Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 05:36:29 -0000 In message: <20051106222359.GC46752@stack.nl> Rink Springer writes: : You can download the patches from : http://rink.nu/downloads/xbox-patches/xbox-7-current.diff. I hope this : patch will be committed to the FreeBSD source tree. Let me know any : suggestions for improvements. OK. I mostly like this patch. It is fairly clean and I'll be working on integrating it into the FreeBSD repo, with your help. I have just a few questions/comments on your patch. First, options XBOX shouldn't be in opt_global.h, but rather in opt_xbox.h that dev/fb/boot_font.c, i386/i386/machdep.c, i386/i386/pmap.c, i386/i386/vm_machdep, i386/isa/clock.c, and i386/pci/pci_cfgreg.c should be including. In general, we try to reserve opt_global.h for really global stuff. I don't understand the change to dev/fb/boot_font.c at all. Can you explain it in more detail? There's some style(9) issues with xboxfb.c. Specifically, there are a few cases in some switches that are inconsistantly formatted wrt other case statements. There are a few really gross hacks that are marked with XXX better fixes welcome. I'm a little torn about committing those, but at least they are all #ifdef XBOX. My question is how long do you think until there's a better solution for them? This is absolutely great work! Don't let my few quibbles and such get you down. I very much want to see xbox support committed to the tree. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 06:35:06 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 450D916A420 for ; Mon, 7 Nov 2005 06:35:06 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44FCE43D46 for ; Mon, 7 Nov 2005 06:35:00 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 157FD17038; Mon, 7 Nov 2005 07:34:54 +0100 (CET) Date: Mon, 7 Nov 2005 07:34:54 +0100 From: Ed Schouten To: "M. Warner Losh" Message-ID: <20051107063454.GE21781@hoeg.nl> References: <20051106222359.GC46752@stack.nl> <20051106.223503.97843133.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="//IivP0gvsAy3Can" Content-Disposition: inline In-Reply-To: <20051106.223503.97843133.imp@bsdimp.com> User-Agent: Mutt/1.5.11 Cc: freebsd-arch@FreeBSD.ORG, Rink Springer Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 06:35:06 -0000 --//IivP0gvsAy3Can Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, * M. Warner Losh wrote: > I don't understand the change to dev/fb/boot_font.c at all. Can you > explain it in more detail? It seems that boot_font.c includes the file 'machine/rpb.h' which is located at 'sys/alpha/include'. I'm not sure whether it is needed on Alpha anyway. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --//IivP0gvsAy3Can Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDbvWOmVI4SHXwmhERAmHMAKCAUY3WimK8jNf6UVwWDlueqy6jPgCfbNaz LVDZgnC8yPoIoCpI0zXGTzU= =R0pk -----END PGP SIGNATURE----- --//IivP0gvsAy3Can-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 07:45:15 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 364E916A41F for ; Mon, 7 Nov 2005 07:45:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AAEA43D49 for ; Mon, 7 Nov 2005 07:45:14 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA77gNKu004028; Mon, 7 Nov 2005 00:42:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 07 Nov 2005 00:42:50 -0700 (MST) Message-Id: <20051107.004250.112381934.imp@bsdimp.com> To: ed@fxq.nl From: "M. Warner Losh" In-Reply-To: <20051107063454.GE21781@hoeg.nl> References: <20051106222359.GC46752@stack.nl> <20051106.223503.97843133.imp@bsdimp.com> <20051107063454.GE21781@hoeg.nl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 07 Nov 2005 00:42:23 -0700 (MST) Cc: freebsd-arch@FreeBSD.ORG, rink@stack.nl Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 07:45:15 -0000 In message: <20051107063454.GE21781@hoeg.nl> Ed Schouten writes: : Hello, : : * M. Warner Losh wrote: : > I don't understand the change to dev/fb/boot_font.c at all. Can you : > explain it in more detail? : : It seems that boot_font.c includes the file 'machine/rpb.h' which is : located at 'sys/alpha/include'. I'm not sure whether it is needed on : Alpha anyway. OK. It isn't needed on the alpha. I just confirmed by building lint w/o the line. I've committed it. One fewer files to patch :-) Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 07:46:10 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7AC616A41F for ; Mon, 7 Nov 2005 07:46:10 +0000 (GMT) (envelope-from rink@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43FC143D48 for ; Mon, 7 Nov 2005 07:46:09 +0000 (GMT) (envelope-from rink@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 8735CA2FD5; Mon, 7 Nov 2005 08:46:08 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1796) id 683EB2287D; Mon, 7 Nov 2005 08:46:08 +0100 (CET) Date: Mon, 7 Nov 2005 08:46:08 +0100 From: Rink Springer To: "M. Warner Losh" Message-ID: <20051107074608.GE46752@stack.nl> References: <20051106222359.GC46752@stack.nl> <20051106.223503.97843133.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb" Content-Disposition: inline In-Reply-To: <20051106.223503.97843133.imp@bsdimp.com> X-Editor: Vim http://www.vim.org/ X-Info: http://rink.nu/ X-Operating-System: FreeBSD 5.4-RELEASE i386 User-Agent: Mutt/1.5.11 Cc: ed@fxq.nl, freebsd-arch@FreeBSD.ORG Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 07:46:10 -0000 --hoZxPH4CaxYzWscb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Warner, > I have just a few questions/comments on your patch. >=20 > First, options XBOX shouldn't be in opt_global.h, but rather in > opt_xbox.h that dev/fb/boot_font.c, i386/i386/machdep.c, > i386/i386/pmap.c, i386/i386/vm_machdep, i386/isa/clock.c, and > i386/pci/pci_cfgreg.c should be including. In general, we try to > reserve opt_global.h for really global stuff. Ah, ok. I'll update this; just curious: are guidelines like this outlined anywhere? > I don't understand the change to dev/fb/boot_font.c at all. Can you > explain it in more detail? You seem to have removed it alltogether already, just saw the commit :) > There's some style(9) issues with xboxfb.c. Specifically, there are a > few cases in some switches that are inconsistantly formatted wrt other > case statements. Ah ok, I'll see if I can fix these. > There are a few really gross hacks that are marked with XXX better > fixes welcome. I'm a little torn about committing those, but at least > they are all #ifdef XBOX. My question is how long do you think until > there's a better solution for them? Well, let's put them in an overview: 1) i386/i386/machdep.c: 64MB memory hardcoding on XBOX'es A normal XBOX as they are sold in most stores have 64MB RAM. However, so= me people have soldered 128MB memory on their XBOX, which also works but is non-standard. =20 Since BIOS interrupts are nonexistant in an XBOX, the only way is to hardcode or probe. I could a minor check which tries the 120th Megabyte of memory or so and adjust memory accordingly, would this be acceptable? The reason why I left it like this is because I have no way to test 128MB XBOX'es, they are quite rare. 2) i386/i386/pmap.c: Not clearing the pagetable This is indeed very gross. The framebuffer driver bluntly remaps the video memory to logical address 4KB and up; normally this space is unused and I use it for temporary video memory. Since we really want a console driver this early, but cannot yet do a sensible mapping, I used this hack. When the final console driver is used, it will make a good mapping using pmap_mapdev(). I am unsure how to fix this; I tried using pmap_mapdev() but this didn't work; perhaps due to the kmem_alloc_nofault() ? (malloc() isn't yet active there) People who have more experience with the VM are very welcome to assist here ... These are the main FIXME/XXX-es I can find. The xboxfb.c console driver stresses out the #2 and claims it should be fixed in a more neat way ;-) > This is absolutely great work! Don't let my few quibbles and such get > you down. I very much want to see xbox support committed to the tree. I'm very glad you are taking the time to help me out with this! I'll try to get an updated patch released tonight. Thanks! --=20 Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly --hoZxPH4CaxYzWscb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDbwZAb3O60uztv/8RAtRcAJoDMwCC3GxDgfy6U8zmtoQBMZWVqACghSfK Z71ta/tH1hTGnyN83Nmbgfg= =Fn2d -----END PGP SIGNATURE----- --hoZxPH4CaxYzWscb-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 14:04:56 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3390E16A41F; Mon, 7 Nov 2005 14:04:56 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id F32E143D58; Mon, 7 Nov 2005 14:04:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jA7E4q9u060373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2005 17:04:52 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jA7E4poX060372; Mon, 7 Nov 2005 17:04:51 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Nov 2005 17:04:51 +0300 From: Gleb Smirnoff To: arch@FreeBSD.org Message-ID: <20051107140451.GU91530@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: Subject: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 14:04:56 -0000 Colleagues, I have a proposition on changing the behavior of ARP retransmitting. Currently we after sending several ARP requests, sending ARP requests for given IP is suppressed for some interval (by default 20 seconds). Probably this feature was designed in early 90th, when sending one additional broadcast packet was an expensive thing. I suggest to keep sending ARP requests while there is a demand for this (we are trying to transmit packets to this particular IP), ratelimiting these requests to one per second. This will help in a quite common case, when some host on net is rebooting, and we are waiting for him to come up, and notice this only after 1 - 20 seconds since the time it is reachable. Any objections? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 14:29:01 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 040BB16A41F for ; Mon, 7 Nov 2005 14:29:01 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E057E43D49 for ; Mon, 7 Nov 2005 14:28:59 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jA7ESvsl060816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2005 17:28:58 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jA7ESvAZ060815; Mon, 7 Nov 2005 17:28:57 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 7 Nov 2005 17:28:57 +0300 From: Gleb Smirnoff To: Joseph Koshy Message-ID: <20051107142857.GY91530@cell.sick.ru> References: <20051107140451.GU91530@cell.sick.ru> <84dead720511070614j4dd7ddfdyc48d931279524bea@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <84dead720511070614j4dd7ddfdyc48d931279524bea@mail.gmail.com> User-Agent: Mutt/1.5.6i Cc: arch@freebsd.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 14:29:01 -0000 On Mon, Nov 07, 2005 at 07:44:17PM +0530, Joseph Koshy wrote: J> Wouldn't the host that is coming up send out a gratuituous J> ARP packet that could be used? It would if it is rebooted, but if a switch is rebooting, or in case of some other link level problems, it won't. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 14:40:50 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EF1F16A41F; Mon, 7 Nov 2005 14:40:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C73EB43D69; Mon, 7 Nov 2005 14:40:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CF5D846B8C; Mon, 7 Nov 2005 09:40:43 -0500 (EST) Date: Mon, 7 Nov 2005 14:40:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20051107140451.GU91530@cell.sick.ru> Message-ID: <20051107143620.P9690@fledge.watson.org> References: <20051107140451.GU91530@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 14:40:50 -0000 On Mon, 7 Nov 2005, Gleb Smirnoff wrote: > I have a proposition on changing the behavior of ARP retransmitting. > Currently we after sending several ARP requests, sending ARP requests > for given IP is suppressed for some interval (by default 20 seconds). > Probably this feature was designed in early 90th, when sending one > additional broadcast packet was an expensive thing. > > I suggest to keep sending ARP requests while there is a demand for this > (we are trying to transmit packets to this particular IP), ratelimiting > these requests to one per second. This will help in a quite common case, > when some host on net is rebooting, and we are waiting for him to come > up, and notice this only after 1 - 20 seconds since the time it is > reachable. While networks have gotten a lot faster in the last few years, I've noticed that many of the ones I deal with have also gotten a lot larger in terms of number of hosts. This has been possible both because of the absolute increase in bandwidth, and also because of the widespread use of switches to suppress unnecessary unicast traffic to segments. I worry that significantly increasing the amount of broadcast traffic will be a problem for sites with large bridged network configurations. On the other hand, they already have to deal with things like windows network neighborhoods, various service discovery protocols, and so on. Do you have any information on what other operating systems may have done in terms of tweaking ARP for improved responsiveness? I imagine we can't be the first to discuss such changes, and if there is already a widely deployed system with ARP adaptations of this sort, it would be interesting to know if they've seen any problems or have recommendations. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 14:53:03 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27AED16A420; Mon, 7 Nov 2005 14:53:03 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8211643D6E; Mon, 7 Nov 2005 14:52:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jA7EqrPG061101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2005 17:52:53 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jA7EqrgO061100; Mon, 7 Nov 2005 17:52:53 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Nov 2005 17:52:53 +0300 From: Gleb Smirnoff To: Robert Watson Message-ID: <20051107145253.GB91530@cell.sick.ru> References: <20051107140451.GU91530@cell.sick.ru> <20051107143620.P9690@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051107143620.P9690@fledge.watson.org> User-Agent: Mutt/1.5.6i Cc: arch@FreeBSD.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 14:53:03 -0000 On Mon, Nov 07, 2005 at 02:40:43PM +0000, Robert Watson wrote: R> > I have a proposition on changing the behavior of ARP retransmitting. R> >Currently we after sending several ARP requests, sending ARP requests R> >for given IP is suppressed for some interval (by default 20 seconds). R> >Probably this feature was designed in early 90th, when sending one R> >additional broadcast packet was an expensive thing. R> > R> > I suggest to keep sending ARP requests while there is a demand for this R> >(we are trying to transmit packets to this particular IP), ratelimiting R> >these requests to one per second. This will help in a quite common case, R> >when some host on net is rebooting, and we are waiting for him to come R> >up, and notice this only after 1 - 20 seconds since the time it is R> >reachable. R> R> While networks have gotten a lot faster in the last few years, I've R> noticed that many of the ones I deal with have also gotten a lot larger in R> terms of number of hosts. This has been possible both because of the R> absolute increase in bandwidth, and also because of the widespread use of R> switches to suppress unnecessary unicast traffic to segments. I worry R> that significantly increasing the amount of broadcast traffic will be a R> problem for sites with large bridged network configurations. On the other R> hand, they already have to deal with things like windows network R> neighborhoods, various service discovery protocols, and so on. R> R> Do you have any information on what other operating systems may have done R> in terms of tweaking ARP for improved responsiveness? I imagine we can't R> be the first to discuss such changes, and if there is already a widely R> deployed system with ARP adaptations of this sort, it would be interesting R> to know if they've seen any problems or have recommendations. Frankly speaking, I have written my email after looking at Linux behavior. It sends one ARP request per second while there is demand for this ARP entry. After demand has disapparead, it sends a few retransmits driven by timer. If again there is a demand, it starts to retransmit again. Under "demand" here I mean a traffic to this particular IP, either locally generated or routed. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 15:19:30 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40B9B16A41F; Mon, 7 Nov 2005 15:19:30 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC0A43D45; Mon, 7 Nov 2005 15:19:29 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.5/8.13.1) with ESMTP id jA7FJRgo006891; Mon, 7 Nov 2005 10:19:27 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.5/8.13.1/Submit) id jA7FJRkB006890; Mon, 7 Nov 2005 10:19:27 -0500 (EST) (envelope-from bv) Date: Mon, 7 Nov 2005 10:19:27 -0500 From: Bill Vermillion To: Gleb Smirnoff Message-ID: <20051107151927.GD1830@wjv.com> References: <20051107140451.GU91530@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051107140451.GU91530@cell.sick.ru> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on bilver.wjv.com Cc: arch@freebsd.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 15:19:30 -0000 On Mon, Nov 07, 2005 at 17:04 , the primordial soup was bombarded with cosmic radiation and a new life form of genus Gleb Smirnoff emerged to test its air breathing capabilities and with great effort gasped: > Colleagues, > I have a proposition on changing the behavior of ARP retransmitting. > Currently we after sending several ARP requests, sending ARP requests > for given IP is suppressed for some interval (by default 20 seconds). > Probably this feature was designed in early 90th, when sending one > additional broadcast packet was an expensive thing. The man page says the host is considered down "for a short period (normally 20 seconds), allowing an error to be returned to transmission attempts in this interval". > I suggest to keep sending ARP requests while there is a demand for > this (we are trying to transmit packets to this particular IP), > ratelimiting these requests to one per second. This will help in a > quite common case, when some host on net is rebooting, and we are > waiting for him to come up, and notice this only after 1 - 20 seconds > since the time it is reachable. > Any objections? Is the 20 second limit that much of a problem. And the 20 minute timeout for caching is certainly far more generous that my old big Cisco that had a 4 hour cache. A user complained that he put up new machines and things weren't working. I told him he should have called me before he put the IPs back the way they were as cleanring the arp-cache took care of that. How big is your network? Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 16:16:31 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC21816A420; Mon, 7 Nov 2005 16:16:31 +0000 (GMT) (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 6217943D46; Mon, 7 Nov 2005 16:16:30 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 887CF5E5F; Mon, 7 Nov 2005 11:16:29 -0500 (EST) 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 25081-10; Mon, 7 Nov 2005 11:16:27 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id C974E5C67; Mon, 7 Nov 2005 11:16:26 -0500 (EST) Message-ID: <436F7DDB.40703@mac.com> Date: Mon, 07 Nov 2005 11:16:27 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051107140451.GU91530@cell.sick.ru> In-Reply-To: <20051107140451.GU91530@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: arch@FreeBSD.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 16:16:31 -0000 Hi-- Gleb Smirnoff wrote: > I have a proposition on changing the behavior of ARP retransmitting. > Currently we after sending several ARP requests, sending ARP requests > for given IP is suppressed for some interval (by default 20 seconds). > Probably this feature was designed in early 90th, when sending one > additional broadcast packet was an expensive thing. Well, we've got ten or a hundred times as much bandwidth, so sending more data is relatively cheap, but the per-packet overhead hasn't improved to the same extent. ARP requests still get sent to and are processed by all machines on the network, even if a switch is being used. > I suggest to keep sending ARP requests while there is a demand for > this (we are trying to transmit packets to this particular IP), > ratelimiting these requests to one per second. This will help in a > quite common case, when some host on net is rebooting, and we are > waiting for him to come up, and notice this only after 1 - 20 seconds > since the time it is reachable. > > Any objections? No, no objection. However, this type of situation could be handled by either an incremental or exponential timeout. Instead of waiting: 1 1 1 1 1 ...seconds between packets as you proposed, consider waiting either of: 1 2 3 4 5 1 2 4 8 16 ...seconds, and cap the maximum wait between ARP requests to 16 or so. Backing off politely and gradually when the host is not getting any answers is more network-friendly. -- -Chuck From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 16:19:00 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22B3316A420 for ; Mon, 7 Nov 2005 16:19:00 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5E4A43D48 for ; Mon, 7 Nov 2005 16:18:45 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1523323 for multiple; Mon, 07 Nov 2005 11:20:42 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7GIXrO011431; Mon, 7 Nov 2005 11:18:35 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 7 Nov 2005 11:18:34 -0500 User-Agent: KMail/1.8.2 References: <20051106222359.GC46752@stack.nl> In-Reply-To: <20051106222359.GC46752@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071118.35041.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: ed@fxq.nl, Rink Springer Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 16:19:00 -0000 On Sunday 06 November 2005 05:23 pm, Rink Springer wrote: > Hello everyone, > > I'd like to present my 7.0-CURRENT XBOX patches. If you put 'options > XBOX' in your kernel after applying this patch, you will get a kernel > that is bootable on both ordinary i386 PC's as well as XBOX'es. 'device > xboxfb' is an XBOX-capable frame buffer. > > You can download the patches from > http://rink.nu/downloads/xbox-patches/xbox-7-current.diff. I hope this > patch will be committed to the FreeBSD source tree. Let me know any > suggestions for improvements. > > The XBOX option depends on I686_CPU and will error out if it is not > supplied. The overall patch is just over 1000 lines, mainly due to the > framebuffer driver. You will need the most recent CVS version of > Cromwell [1], as it now fakes FreeBSD boot info so the initial entry > won't halt the CPU. This removes the patches in the locore.s file. > > For some reason, the kernel will not work fine if you have syscons in your > kernel. This only affects the XBOX, so either syscons crashes it somehow > or it gets a higher priority. However, as the current framedriver driver > needs to be syscon(4)-ized, I intend to port the framebuffer to the VESA > framework. Assistance on this is very welcome. > > Finally, I am willing to maintain this so future FreeBSD's will run on > the XBOX without any issues. Work is underway for the nForce ethernet as > well as an improved syscons(4)-able console driver. > > [1] This is the Linux BIOS for the XBOX; it was patched in order to boot > FreeBSD correctly. It might be nice to have as much of pci16l.s in C as possible for ease of maintenance. For example, at least two of the functions I looked at in there just call a p16l_setbits() and that could be done via an inline function in a header file. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 17:49:22 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45FF916A420; Mon, 7 Nov 2005 17:49:22 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 743C643D45; Mon, 7 Nov 2005 17:49:21 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id jA7HnIR5009575; Mon, 7 Nov 2005 12:49:20 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <436F7DDB.40703@mac.com> References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> Date: Mon, 7 Nov 2005 12:49:17 -0500 To: Chuck Swiger , Gleb Smirnoff From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 Cc: arch@freebsd.org, Robert Watson Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 17:49:22 -0000 At 11:16 AM -0500 11/7/05, Chuck Swiger wrote: >Hi-- > >Gleb Smirnoff wrote: >> I suggest to keep sending ARP requests while there is a demand for >>this (we are trying to transmit packets to this particular IP), >>ratelimiting these requests to one per second. > >No, no objection. However, this type of situation could be handled >by either an incremental or exponential timeout. Instead of waiting: > >1 1 1 1 1 > >...seconds between packets as you proposed, consider waiting either of: > >1 2 3 4 5 >1 2 4 8 16 > >...seconds, and cap the maximum wait between ARP requests to 16 or >so. Backing off politely and gradually when the host is not getting >any answers is more network-friendly. I think Chuck's suggestion is a very good idea. In a separate message in this thread, Robert noted that: I worry that significantly increasing the amount of broadcast traffic will be a problem for sites with large bridged network configurations. On the other hand, they already have to deal with things like windows network neighborhoods, various service discovery protocols, and so on. While that "other hand" is true, here at RPI we deal with some of those other-hand issues by simply turning them off. We turn off multi-cast by default on some of our networks, for instance. But there's no way we can turn off ARP, so I think more care needs to be taken to make sure ARP remains network-friendly. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 17:55:44 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7A9A16A420; Mon, 7 Nov 2005 17:55:44 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EEA543D48; Mon, 7 Nov 2005 17:55:43 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail20.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jA7HtgeA022408 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Nov 2005 04:55:42 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jA7HtfHh077269; Tue, 8 Nov 2005 04:55:42 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id jA7HtfQQ077268; Tue, 8 Nov 2005 04:55:41 +1100 (EST) (envelope-from pjeremy) Date: Tue, 8 Nov 2005 04:55:41 +1100 From: Peter Jeremy To: Robert Watson Message-ID: <20051107175541.GT39882@cirb503493.alcatel.com.au> References: <20051107140451.GU91530@cell.sick.ru> <20051107143620.P9690@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051107143620.P9690@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: arch@freebsd.org, Gleb Smirnoff Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 17:55:44 -0000 On Mon, 2005-Nov-07 14:40:43 +0000, Robert Watson wrote: >Do you have any information on what other operating systems may have done >in terms of tweaking ARP for improved responsiveness? Solaris 8 and 9 appear to re-transmit ARP requests every second or so even when they know the response :-(. This does make for a noisy network. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 19:41:57 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3EF516A428 for ; Mon, 7 Nov 2005 19:41:57 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ABB343D5D for ; Mon, 7 Nov 2005 19:41:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jA7Jfr4q065638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Nov 2005 22:41:53 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jA7Jfqou065637 for arch@freebsd.org; Mon, 7 Nov 2005 22:41:52 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Nov 2005 22:41:52 +0300 From: Gleb Smirnoff To: arch@FreeBSD.org Message-ID: <20051107194152.GF91530@cell.sick.ru> References: <20051107140451.GU91530@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YkJPYEFdoxh/AXLE" Content-Disposition: inline In-Reply-To: <20051107140451.GU91530@cell.sick.ru> User-Agent: Mutt/1.5.6i Cc: Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 19:41:57 -0000 --YkJPYEFdoxh/AXLE Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Mon, Nov 07, 2005 at 05:04:51PM +0300, Gleb Smirnoff wrote: T> I suggest to keep sending ARP requests while there is a demand for T> this (we are trying to transmit packets to this particular IP), T> ratelimiting these requests to one per second. This will help in a T> quite common case, when some host on net is rebooting, and we are T> waiting for him to come up, and notice this only after 1 - 20 seconds T> since the time it is reachable. Here is code explaining what I am speaking about. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --YkJPYEFdoxh/AXLE Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="arp.request.diff" Index: if_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/if_ether.c,v retrieving revision 1.144 diff -u -r1.144 if_ether.c --- if_ether.c 4 Oct 2005 19:50:02 -0000 1.144 +++ if_ether.c 7 Nov 2005 19:39:10 -0000 @@ -79,14 +79,11 @@ /* timer values */ static int arpt_prune = (5*60*1); /* walk list every 5 minutes */ static int arpt_keep = (20*60); /* once resolved, good for 20 more minutes */ -static int arpt_down = 20; /* once declared down, don't send for 20 sec */ SYSCTL_INT(_net_link_ether_inet, OID_AUTO, prune_intvl, CTLFLAG_RW, &arpt_prune, 0, ""); SYSCTL_INT(_net_link_ether_inet, OID_AUTO, max_age, CTLFLAG_RW, &arpt_keep, 0, ""); -SYSCTL_INT(_net_link_ether_inet, OID_AUTO, host_down_time, CTLFLAG_RW, - &arpt_down, 0, ""); #define rt_expire rt_rmx.rmx_expire @@ -95,8 +92,7 @@ struct rtentry *la_rt; struct mbuf *la_hold; /* last packet until resolved/timeout */ u_short la_preempt; /* countdown for pre-expiry arps */ - u_short la_asked; /* #times we QUERIED following expiration */ -#define la_timer la_rt->rt_rmx.rmx_expire /* deletion time in seconds */ + u_short la_asked; /* # requests sent */ }; static LIST_HEAD(, llinfo_arp) llinfo_arp; @@ -104,13 +100,13 @@ static struct ifqueue arpintrq; static int arp_allocated; -static int arp_maxtries = 5; +static int arp_renew = 5; /* request this seconds before expiry */ static int useloopback = 1; /* use loopback interface for local traffic */ static int arp_proxyall = 0; static struct callout arp_callout; -SYSCTL_INT(_net_link_ether_inet, OID_AUTO, maxtries, CTLFLAG_RW, - &arp_maxtries, 0, ""); +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, renew, CTLFLAG_RW, + &arp_renew, 0, ""); SYSCTL_INT(_net_link_ether_inet, OID_AUTO, useloopback, CTLFLAG_RW, &useloopback, 0, ""); SYSCTL_INT(_net_link_ether_inet, OID_AUTO, proxyall, CTLFLAG_RW, @@ -150,7 +146,6 @@ if (rt->rt_refcnt > 1) { sdl->sdl_alen = 0; la->la_preempt = la->la_asked = 0; - rt->rt_flags &= ~RTF_REJECT; RT_UNLOCK(rt); continue; } @@ -448,8 +443,7 @@ /* * If entry has an expiry time and it is approaching, - * see if we need to send an ARP request within this - * arpt_down interval. + * send an ARP request. */ if ((rt->rt_expire != 0) && (time_uptime + la->la_preempt > rt->rt_expire)) { @@ -485,29 +479,33 @@ if (la->la_hold) m_freem(la->la_hold); la->la_hold = m; - if (rt->rt_expire) { - rt->rt_flags &= ~RTF_REJECT; - if (la->la_asked == 0 || rt->rt_expire != time_uptime) { - rt->rt_expire = time_uptime; - if (la->la_asked++ < arp_maxtries) { - struct in_addr sin = - SIN(rt->rt_ifa->ifa_addr)->sin_addr; - RT_UNLOCK(rt); - arprequest(ifp, &sin, &SIN(dst)->sin_addr, - IF_LLADDR(ifp)); - return (EWOULDBLOCK); - } else { - rt->rt_flags |= RTF_REJECT; - rt->rt_expire += arpt_down; - la->la_asked = 0; - la->la_preempt = arp_maxtries; - } + KASSERT(rt->rt_expire > 0, ("sending ARP request for static entry")); - } - } - RT_UNLOCK(rt); - return (EWOULDBLOCK); + /* + * Return EWOULDBLOCK if we are sending first request now, it + * will be masked by ether_output(). Return EHOSTDOWN/EHOSTUNREACH + * in case we have already sent ARP requests. Retransmit the + * ARP request, but not faster than one request per second. + */ + if (la->la_asked == 0) + error = EWOULDBLOCK; /* First request. */ + else + error = (rt == rt0) ? EHOSTDOWN : EHOSTUNREACH; + + if (la->la_asked++ == 0 || rt->rt_expire != time_uptime) { + struct in_addr sin = + SIN(rt->rt_ifa->ifa_addr)->sin_addr; + + rt->rt_expire = time_uptime; + RT_UNLOCK(rt); + + arprequest(ifp, &sin, &SIN(dst)->sin_addr, + IF_LLADDR(ifp)); + } else + RT_UNLOCK(rt); + + return (error); } /* @@ -786,9 +784,8 @@ } if (rt->rt_expire) rt->rt_expire = time_uptime + arpt_keep; - rt->rt_flags &= ~RTF_REJECT; la->la_asked = 0; - la->la_preempt = arp_maxtries; + la->la_preempt = arp_renew; hold = la->la_hold; la->la_hold = NULL; RT_UNLOCK(rt); --YkJPYEFdoxh/AXLE-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 19:44:31 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A9B316A41F for ; Mon, 7 Nov 2005 19:44:31 +0000 (GMT) (envelope-from rink@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6DB543D77 for ; Mon, 7 Nov 2005 19:44:26 +0000 (GMT) (envelope-from rink@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 55A08A2FD5; Mon, 7 Nov 2005 20:44:25 +0100 (CET) Received: by hammer.stack.nl (Postfix, from userid 1796) id 349C86243; Mon, 7 Nov 2005 20:44:25 +0100 (CET) Date: Mon, 7 Nov 2005 20:44:25 +0100 From: Rink Springer To: imp@bsdimp.com Message-ID: <20051107194424.GA35394@stack.nl> References: <20051106222359.GC46752@stack.nl> <200511071118.35041.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <200511071118.35041.jhb@freebsd.org> X-Editor: Vim http://www.vim.org/ X-Info: http://rink.nu/ X-Operating-System: FreeBSD 6.0-BETA4 amd64 User-Agent: Mutt/1.5.11 Cc: ed@fxq.nl, freebsd-arch@freebsd.org Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 19:44:31 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, OK, I've updated the patchset. Changes: - opt_xbox.h is now used instead of opt_global.h - xboxfb.c should follow style(9) better - boot_font.c is no longer patched - 128MB XBOX-es should work too [1] It is fetchable from http://rink.nu/downloads/xbox-patches/xbox-7-current.v2.diff Oh, and for John's comment: The reason pic16l.s is coded in assembly, was that it was used extensively while debugging (it even resided in locore.s for a while :-), as being able to change the LED's color is immensely useful if you don't have a framebuffer working already :) This is why I'd prefer to keep this file as-is. [1] I have no way of testing this; volunteers are very welcome! --=20 Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly * John Baldwin (jhb@freebsd.org) wrote: > On Sunday 06 November 2005 05:23 pm, Rink Springer wrote: > > Hello everyone, > > > > I'd like to present my 7.0-CURRENT XBOX patches. If you put 'options > > XBOX' in your kernel after applying this patch, you will get a kernel > > that is bootable on both ordinary i386 PC's as well as XBOX'es. 'device > > xboxfb' is an XBOX-capable frame buffer. > > > > You can download the patches from > > http://rink.nu/downloads/xbox-patches/xbox-7-current.diff. I hope this > > patch will be committed to the FreeBSD source tree. Let me know any > > suggestions for improvements. > > > > The XBOX option depends on I686_CPU and will error out if it is not > > supplied. The overall patch is just over 1000 lines, mainly due to the > > framebuffer driver. You will need the most recent CVS version of > > Cromwell [1], as it now fakes FreeBSD boot info so the initial entry > > won't halt the CPU. This removes the patches in the locore.s file. > > > > For some reason, the kernel will not work fine if you have syscons in y= our > > kernel. This only affects the XBOX, so either syscons crashes it somehow > > or it gets a higher priority. However, as the current framedriver driver > > needs to be syscon(4)-ized, I intend to port the framebuffer to the VESA > > framework. Assistance on this is very welcome. > > > > Finally, I am willing to maintain this so future FreeBSD's will run on > > the XBOX without any issues. Work is underway for the nForce ethernet as > > well as an improved syscons(4)-able console driver. > > > > [1] This is the Linux BIOS for the XBOX; it was patched in order to boot > > FreeBSD correctly. >=20 > It might be nice to have as much of pci16l.s in C as possible for ease of= =20 > maintenance. For example, at least two of the functions I looked at in t= here=20 > just call a p16l_setbits() and that could be done via an inline function = in a=20 > header file. >=20 > --=20 > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org >=20 --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDb66Yb3O60uztv/8RAqASAJ4/iAW1/C/6m1q42EvBQoDtFmGtNgCfUovP LBEMW9xEHjWZogCslJsTqIg= =q8zi -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 21:36:29 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3486716A436 for ; Mon, 7 Nov 2005 21:36:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46E8043D58 for ; Mon, 7 Nov 2005 21:36:03 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1540416 for multiple; Mon, 07 Nov 2005 16:38:00 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7LZexP019048; Mon, 7 Nov 2005 16:35:52 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 7 Nov 2005 16:35:37 -0500 User-Agent: KMail/1.8.2 References: <20051106222359.GC46752@stack.nl> <200511071118.35041.jhb@freebsd.org> <20051107194424.GA35394@stack.nl> In-Reply-To: <20051107194424.GA35394@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071635.39323.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: ed@fxq.nl, Rink Springer Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 21:36:29 -0000 On Monday 07 November 2005 02:44 pm, Rink Springer wrote: > Hi, > > OK, I've updated the patchset. Changes: > > - opt_xbox.h is now used instead of opt_global.h > - xboxfb.c should follow style(9) better > - boot_font.c is no longer patched > - 128MB XBOX-es should work too [1] > > It is fetchable from > http://rink.nu/downloads/xbox-patches/xbox-7-current.v2.diff > > Oh, and for John's comment: The reason pic16l.s is coded in assembly, was > that it was used extensively while debugging (it even resided in > locore.s for a while :-), as being able to change the LED's color is > immensely useful if you don't have a framebuffer working already :) This > is why I'd prefer to keep this file as-is. You do realize that you can call C functions from assembly, right? :) > [1] I have no way of testing this; volunteers are very welcome! -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 22:26:15 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D03216A428; Mon, 7 Nov 2005 22:26:15 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FFF643D48; Mon, 7 Nov 2005 22:26:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jA7MQ5Ht098578; Mon, 7 Nov 2005 15:26:06 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <436FD47D.2000802@samsco.org> Date: Mon, 07 Nov 2005 15:26:05 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20051106222359.GC46752@stack.nl> <200511071118.35041.jhb@freebsd.org> <20051107194424.GA35394@stack.nl> <200511071635.39323.jhb@freebsd.org> In-Reply-To: <200511071635.39323.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Rink Springer , ed@fxq.nl, freebsd-arch@freebsd.org Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 22:26:15 -0000 John Baldwin wrote: > On Monday 07 November 2005 02:44 pm, Rink Springer wrote: > >>Hi, >> >>OK, I've updated the patchset. Changes: >> >>- opt_xbox.h is now used instead of opt_global.h >>- xboxfb.c should follow style(9) better >>- boot_font.c is no longer patched >>- 128MB XBOX-es should work too [1] >> >>It is fetchable from >>http://rink.nu/downloads/xbox-patches/xbox-7-current.v2.diff >> >>Oh, and for John's comment: The reason pic16l.s is coded in assembly, was >>that it was used extensively while debugging (it even resided in >>locore.s for a while :-), as being able to change the LED's color is >>immensely useful if you don't have a framebuffer working already :) This >>is why I'd prefer to keep this file as-is. > > > You do realize that you can call C functions from assembly, right? :) > If this is the only remaining technical objection, then can it be something that gets resolved after it goes into the tree? It's code that is segregated and private to the XBOX port, so it would be a shame to make it stall this great work. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 22:44:36 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C5A16A420; Mon, 7 Nov 2005 22:44:36 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9DFC43DD8; Mon, 7 Nov 2005 22:43:40 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id jA7Mhd7H041246; Mon, 7 Nov 2005 14:43:39 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id jA7Mhc9R041245; Mon, 7 Nov 2005 14:43:38 -0800 (PST) (envelope-from jmg) Date: Mon, 7 Nov 2005 14:43:38 -0800 From: John-Mark Gurney To: Garance A Drosihn Message-ID: <20051107224338.GE775@funkthat.com> Mail-Followup-To: Garance A Drosihn , Chuck Swiger , Gleb Smirnoff , arch@freebsd.org, Robert Watson References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: arch@freebsd.org, Chuck Swiger , Robert Watson , Gleb Smirnoff Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 22:44:36 -0000 Garance A Drosihn wrote this message on Mon, Nov 07, 2005 at 12:49 -0500: > I think Chuck's suggestion is a very good idea. In a separate message > in this thread, Robert noted that: > > > I worry that significantly increasing the amount of broadcast > traffic will be a problem for sites with large bridged network > configurations. On the other hand, they already have to deal > with things like windows network neighborhoods, various service > discovery protocols, and so on. > > While that "other hand" is true, here at RPI we deal with some of > those other-hand issues by simply turning them off. We turn off > multi-cast by default on some of our networks, for instance. But > there's no way we can turn off ARP, so I think more care needs to > be taken to make sure ARP remains network-friendly. And most places that have VERY large number of hosts in a broadcast domain (a partially populated class b), have smart switches that cache arp requests, and prevent the arp traffic from killing the network... So, I'd vote for the change... Though we might want to increase the length we keep arp entries around... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 22:52:02 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 903E616A420 for ; Mon, 7 Nov 2005 22:52:02 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 443D343DBA for ; Mon, 7 Nov 2005 22:51:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1544755 for multiple; Mon, 07 Nov 2005 17:53:43 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7MpX4p019534; Mon, 7 Nov 2005 17:51:35 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Scott Long Date: Mon, 7 Nov 2005 17:51:31 -0500 User-Agent: KMail/1.8.2 References: <20051106222359.GC46752@stack.nl> <200511071635.39323.jhb@freebsd.org> <436FD47D.2000802@samsco.org> In-Reply-To: <436FD47D.2000802@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200511071751.32609.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Rink Springer , ed@fxq.nl, freebsd-arch@freebsd.org Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 22:52:02 -0000 On Monday 07 November 2005 05:26 pm, Scott Long wrote: > John Baldwin wrote: > > On Monday 07 November 2005 02:44 pm, Rink Springer wrote: > >>Hi, > >> > >>OK, I've updated the patchset. Changes: > >> > >>- opt_xbox.h is now used instead of opt_global.h > >>- xboxfb.c should follow style(9) better > >>- boot_font.c is no longer patched > >>- 128MB XBOX-es should work too [1] > >> > >>It is fetchable from > >>http://rink.nu/downloads/xbox-patches/xbox-7-current.v2.diff > >> > >>Oh, and for John's comment: The reason pic16l.s is coded in assembly, was > >>that it was used extensively while debugging (it even resided in > >>locore.s for a while :-), as being able to change the LED's color is > >>immensely useful if you don't have a framebuffer working already :) This > >>is why I'd prefer to keep this file as-is. > > > > You do realize that you can call C functions from assembly, right? :) > > If this is the only remaining technical objection, then can it be > something that gets resolved after it goes into the tree? It's code > that is segregated and private to the XBOX port, so it would be a shame > to make it stall this great work. Yes, certainly, that is only a minor nit! I just tend to prefer that we keep as much code in C as possible rather than asm as C has a lower learning curve. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 23:18:16 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3FA816A421 for ; Mon, 7 Nov 2005 23:18:16 +0000 (GMT) (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 7313143DA3 for ; Mon, 7 Nov 2005 23:17:53 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 0C3135F8B; Mon, 7 Nov 2005 18:17:53 -0500 (EST) 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 32906-08; Mon, 7 Nov 2005 18:17:52 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 21B5B5D40; Mon, 7 Nov 2005 18:17:52 -0500 (EST) In-Reply-To: <20051107224338.GE775@funkthat.com> References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> <20051107224338.GE775@funkthat.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Mon, 7 Nov 2005 18:17:51 -0500 To: John-Mark Gurney X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: arch@freebsd.org, Garance A Drosihn Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 23:18:17 -0000 On Nov 7, 2005, at 5:43 PM, John-Mark Gurney wrote: >> While that "other hand" is true, here at RPI we deal with some of >> those other-hand issues by simply turning them off. We turn off >> multi-cast by default on some of our networks, for instance. But >> there's no way we can turn off ARP, so I think more care needs to >> be taken to make sure ARP remains network-friendly. > > And most places that have VERY large number of hosts in a broadcast > domain (a partially populated class b), have smart switches that cache > arp requests, and prevent the arp traffic from killing the network... Really? You're saying that "tcpdump -nt arp" never shows any requests except those made by the local host? Which vendor and which switch model? Smart switches will generally keep track of 1000 or 4000 or so MAC addresses and the ports those MACs are associated with, but I am not aware of anything in them which blocks ARP traffic or anything else which uses the all-ones broadcast MAC address. I can see ARP requests going out from any/all of the other machines on the network I'm using right now (using several 3com SuperStack 3300's), and I've seen the same thing on networks using the HP Procurve or Cisco 29xx switches. -- -Chuck From owner-freebsd-arch@FreeBSD.ORG Mon Nov 7 23:45:50 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D7C616A41F for ; Mon, 7 Nov 2005 23:45:50 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id E816143D49 for ; Mon, 7 Nov 2005 23:45:49 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id jA7NjnHs042843; Mon, 7 Nov 2005 15:45:49 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id jA7NjnYw042842; Mon, 7 Nov 2005 15:45:49 -0800 (PST) (envelope-from jmg) Date: Mon, 7 Nov 2005 15:45:48 -0800 From: John-Mark Gurney To: Charles Swiger Message-ID: <20051107234548.GF775@funkthat.com> Mail-Followup-To: Charles Swiger , Garance A Drosihn , arch@freebsd.org References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> <20051107224338.GE775@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: arch@freebsd.org, Garance A Drosihn Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 23:45:50 -0000 Charles Swiger wrote this message on Mon, Nov 07, 2005 at 18:17 -0500: > On Nov 7, 2005, at 5:43 PM, John-Mark Gurney wrote: > >>While that "other hand" is true, here at RPI we deal with some of > >>those other-hand issues by simply turning them off. We turn off > >>multi-cast by default on some of our networks, for instance. But > >>there's no way we can turn off ARP, so I think more care needs to > >>be taken to make sure ARP remains network-friendly. > > > >And most places that have VERY large number of hosts in a broadcast > >domain (a partially populated class b), have smart switches that cache > >arp requests, and prevent the arp traffic from killing the network... > > Really? You're saying that "tcpdump -nt arp" never shows any > requests except those made by the local host? > > Which vendor and which switch model? Just a random search for smart arp large, turned up user's manual for the WaveSwitch 9000, from Plaintree Systems.. The docs say: Address Resolution Protocol (ARP) is the means by which a host or router maps an IP address to a physical address. WaveSwitch 9000 software contains the SmartARP feature that allows for reduced impact of ARP broadcasting. Normally, ARP broadcasts are flooded to all ports on a switch. Switch ports that are not connected to the target host must, therefore, receive and partially process the broadcast frames. This can potentially affect the performance of all hosts on the bridged network. With the SmartARP feature, ARP broadcasts are confined to only the applicable switch ports (see Figure 67). And the diagram shows the arp request being restricted to only the port with the router and the host on it... A coworker also says that the Foundary switches can do it, and did it like five years ago... I haven't confirmed this myself... > Smart switches will generally keep track of 1000 or 4000 or so MAC > addresses and the ports those MACs are associated with, but I am not > aware of anything in them which blocks ARP traffic or anything else > which uses the all-ones broadcast MAC address. I can see ARP > requests going out from any/all of the other machines on the network > I'm using right now (using several 3com SuperStack 3300's), and I've > seen the same thing on networks using the HP Procurve or Cisco 29xx > switches. I'd imagine you have to turn it on... since it'd have odd behavior if you weren't expecting it... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Nov 8 00:49:33 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D85816A41F for ; Tue, 8 Nov 2005 00:49:33 +0000 (GMT) (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 B695C43D48 for ; Tue, 8 Nov 2005 00:49:32 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 1D9425DDA; Mon, 7 Nov 2005 19:49:32 -0500 (EST) 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 90417-04; Mon, 7 Nov 2005 19:49:31 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 0DDF95D40; Mon, 7 Nov 2005 19:49:31 -0500 (EST) In-Reply-To: <20051107234548.GF775@funkthat.com> References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> <20051107224338.GE775@funkthat.com> <20051107234548.GF775@funkthat.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <036D3BD4-D856-4D50-A7D3-2300EFEA604F@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Mon, 7 Nov 2005 19:49:30 -0500 To: John-Mark Gurney X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: arch@freebsd.org, Garance A Drosihn Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 00:49:33 -0000 On Nov 7, 2005, at 6:45 PM, John-Mark Gurney wrote: >> Really? You're saying that "tcpdump -nt arp" never shows any >> requests except those made by the local host? >> >> Which vendor and which switch model? > > Just a random search for smart arp large, turned up user's manual > for the WaveSwitch 9000, from Plaintree Systems.. > > The docs say: > Address Resolution Protocol (ARP) is the means by which a host or > router > maps an IP address to a physical address. WaveSwitch 9000 software > contains the SmartARP feature that allows for reduced impact of ARP > broadcasting. > > Normally, ARP broadcasts are flooded to all ports on a switch. Switch > ports that are not connected to the target host must, therefore, > receive > and partially process the broadcast frames. This can potentially > affect > the performance of all hosts on the bridged network. [ ... ] > A coworker also says that the Foundary switches can do it, and did > it like five years ago... I haven't confirmed this myself... OK, I appreciate the response and the pointer to a specific model. This being said, I'd prefer a first-hand account from someone who has actually run tcpdump for a few days on a production network and confirmed that this feature really works as advertised. (There can be a big difference between what the documentation claims a switch does, and what the switch actually does. In particular, switch vendors have also claimed that VLAN tagging was reliable and secure and that traffic from one VLAN could never leak to a port on another VLAN...) ----- I think your other comment about extending the lifespan of entries in the ARP cache is a more useful idea, at least for extending the lifespan of valid entries. Negative response to an ARP request should not be cached for very long. Does FreeBSD update the ARP cache when ARPOP_REQUESTs are seen? At the very least, one could refresh the timer if you have an entry for the host making the request... -- -Chuck From owner-freebsd-arch@FreeBSD.ORG Tue Nov 8 00:54:30 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B1CD16A41F; Tue, 8 Nov 2005 00:54:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EAE843D48; Tue, 8 Nov 2005 00:54:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA80qWUk012587; Mon, 7 Nov 2005 17:52:32 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 07 Nov 2005 17:52:59 -0700 (MST) Message-Id: <20051107.175259.13769963.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <436FD47D.2000802@samsco.org> References: <20051107194424.GA35394@stack.nl> <200511071635.39323.jhb@freebsd.org> <436FD47D.2000802@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 07 Nov 2005 17:52:33 -0700 (MST) Cc: freebsd-arch@freebsd.org, ed@fxq.nl, rink@stack.nl Subject: Re: FreeBSD/xbox: updated 7.0 patchset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 00:54:30 -0000 In message: <436FD47D.2000802@samsco.org> Scott Long writes: : John Baldwin wrote: : : > On Monday 07 November 2005 02:44 pm, Rink Springer wrote: : > : >>Hi, : >> : >>OK, I've updated the patchset. Changes: : >> : >>- opt_xbox.h is now used instead of opt_global.h : >>- xboxfb.c should follow style(9) better : >>- boot_font.c is no longer patched : >>- 128MB XBOX-es should work too [1] : >> : >>It is fetchable from : >>http://rink.nu/downloads/xbox-patches/xbox-7-current.v2.diff : >> : >>Oh, and for John's comment: The reason pic16l.s is coded in assembly, was : >>that it was used extensively while debugging (it even resided in : >>locore.s for a while :-), as being able to change the LED's color is : >>immensely useful if you don't have a framebuffer working already :) This : >>is why I'd prefer to keep this file as-is. : > : > : > You do realize that you can call C functions from assembly, right? :) : > : : If this is the only remaining technical objection, then can it be : something that gets resolved after it goes into the tree? It's code : that is segregated and private to the XBOX port, so it would be a shame : to make it stall this great work. Don't worry. I have v1 of the patches sitting in a tree waiting for me to find some time to commit them. I was going to update to v2 tonight and see what had been fixed and integrate more into it either tonight or tomorrow night. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Nov 8 09:11:16 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EE6C16A41F for ; Tue, 8 Nov 2005 09:11:16 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BBC643D46 for ; Tue, 8 Nov 2005 09:11:14 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail03.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jA89BCeW021827 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Nov 2005 20:11:13 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jA89BCHh078142; Tue, 8 Nov 2005 20:11:12 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id jA89BCcY078141; Tue, 8 Nov 2005 20:11:12 +1100 (EST) (envelope-from pjeremy) Date: Tue, 8 Nov 2005 20:11:12 +1100 From: Peter Jeremy To: Charles Swiger Message-ID: <20051108091112.GU39882@cirb503493.alcatel.com.au> References: <20051107140451.GU91530@cell.sick.ru> <436F7DDB.40703@mac.com> <20051107224338.GE775@funkthat.com> <20051107234548.GF775@funkthat.com> <036D3BD4-D856-4D50-A7D3-2300EFEA604F@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036D3BD4-D856-4D50-A7D3-2300EFEA604F@mac.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: arch@freebsd.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 09:11:16 -0000 On Mon, 2005-Nov-07 19:49:30 -0500, Charles Swiger wrote: >does, and what the switch actually does. In particular, switch >vendors have also claimed that VLAN tagging was reliable and secure >and that traffic from one VLAN could never leak to a port on another >VLAN...) ISTR that some years ago, I did a check and found that ~0.5% of packets in our corporate network were being leaked into the incorrect VLAN. [Though my memory may be going] I haven't looked recently. I've also got a switch that believes that VLANs are only related to IP - it will happily copy DECnet packets to all switch ports irrespective of VLAN associations. (And this switch came from the company that DEC sold their switch business to). -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 03:43:40 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 275D816A421 for ; Thu, 10 Nov 2005 03:43:40 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7850C43D6E for ; Thu, 10 Nov 2005 03:43:39 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by wproxy.gmail.com with SMTP id i1so472987wra for ; Wed, 09 Nov 2005 19:43:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=VHe+ZnnwWWhl/Mc0O3nkwqiwcPdxxkp9U5J7qXInYP5dg9hKAQPKHU6Qc8McBkM9dzNQe573BRhaWJecrJQD9o538cnMWOoGKL9Qjt7hn36vV7e2bCwuGhsaBNcZbOlk0Es23pM+aJkFfYr+joCrXCePQCOhPWfecbVC3dOwp68= Received: by 10.64.179.4 with SMTP id b4mr29473qbf; Wed, 09 Nov 2005 19:43:38 -0800 (PST) Received: by 10.65.191.18 with HTTP; Wed, 9 Nov 2005 19:43:38 -0800 (PST) Message-ID: Date: Thu, 10 Nov 2005 11:43:38 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Cc: delphij@FreeBSD.org Subject: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 03:43:40 -0000 RGVhciBmb2xrcywKCkhlcmUgaXMgYSBwYXRjaHNldCB0aGF0IHRhdWdodCBpbmV0ZCg4KSBhYm91 dCBrcXVldWUsIGFuZCBzb21lIG90aGVyCmNsZWFudXBzIHRoYXQgcmFpc2VzIFdBUk5TIGxldmVs IGZyb20gMiB0byAzLCBldGMuCgpodHRwOi8vcGVvcGxlLmZyZWVic2Qub3JnL35kZWxwaGlqL2Zv cl9yZXZpZXcvcGF0Y2gtaW5ldGQta3F1ZXVlCgpUaGUga3F1ZXVlIHBhcnQgd2FzIGEgY29udGlu dWF0aW9uIG9mIGptZ0AncyBwYXRjaHNldC4KClRoYW5rcyBpbiBhZHZhbmNlIQoKQ2hlZXJzLAo= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 14:27:05 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC7D16A459; Thu, 10 Nov 2005 14:27:05 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23CCB43D48; Thu, 10 Nov 2005 14:27:04 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.3/8.13.3) with ESMTP id jAAER3So048529; Thu, 10 Nov 2005 17:27:03 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Thu, 10 Nov 2005 17:27:03 +0300 (MSK) From: Maxim Konovalov To: Xin LI In-Reply-To: Message-ID: <20051110172650.Q48388@mp2.macomnet.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: delphij@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 14:27:06 -0000 On Thu, 10 Nov 2005, 11:43+0800, Xin LI wrote: > Dear folks, > > Here is a patchset that taught inetd(8) about kqueue, and some other > cleanups that raises WARNS level from 2 to 3, etc. > > http://people.freebsd.org/~delphij/for_review/patch-inetd-kqueue > > The kqueue part was a continuation of jmg@'s patchset. Can I ask: why? -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 16:58:19 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA76B16A41F for ; Thu, 10 Nov 2005 16:58:19 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0581F43D4C for ; Thu, 10 Nov 2005 16:58:18 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by zproxy.gmail.com with SMTP id i11so428023nzh for ; Thu, 10 Nov 2005 08:58:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cq2sfC+/IfjLckKZtvH/ROF5gkg6cIPtW2gSdfINDvBSBiqJvsfdlY/oBygaqWpftAL4MHxKzAXFVWY979zp/SRZDG8Fvm5HR3kqW1x9+F1rvOgWsqSQ+qaSPb4zM16LaO6qqe0IYvWLuz9FsYdUpfd5m9ri4DVVcSEdzh/3cFM= Received: by 10.65.253.8 with SMTP id f8mr1085303qbs; Thu, 10 Nov 2005 08:58:18 -0800 (PST) Received: by 10.65.191.18 with HTTP; Thu, 10 Nov 2005 08:58:18 -0800 (PST) Message-ID: Date: Fri, 11 Nov 2005 00:58:18 +0800 From: Xin LI To: Maxim Konovalov In-Reply-To: <20051110172650.Q48388@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051110172650.Q48388@mp2.macomnet.net> Cc: delphij@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 16:58:19 -0000 T24gMTEvMTAvMDUsIE1heGltIEtvbm92YWxvdiA8bWF4aW1AbWFjb21uZXQucnU+IHdyb3RlOgpb Li4uXQo+IENhbiBJIGFzazogd2h5PwoKTXkgaW50ZW50aW9uIGlzIHRvIGdpdmUga3F1ZXVlIG1v cmUgZXhwb3N1cmUuCgpDaGVlcnMsCg== From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 20:48:58 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3822616A420; Thu, 10 Nov 2005 20:48:58 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31C443D4C; Thu, 10 Nov 2005 20:48:55 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id jAAKmqPv043403; Thu, 10 Nov 2005 12:48:52 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id jAAKmn2M043402; Thu, 10 Nov 2005 12:48:49 -0800 (PST) (envelope-from jmg) Date: Thu, 10 Nov 2005 12:48:49 -0800 From: John-Mark Gurney To: Maxim Konovalov Message-ID: <20051110204849.GC775@funkthat.com> Mail-Followup-To: Maxim Konovalov , Xin LI , delphij@freebsd.org, freebsd-arch@freebsd.org References: <20051110172650.Q48388@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051110172650.Q48388@mp2.macomnet.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: delphij@freebsd.org, Xin LI , freebsd-arch@freebsd.org Subject: Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 20:48:58 -0000 Maxim Konovalov wrote this message on Thu, Nov 10, 2005 at 17:27 +0300: > On Thu, 10 Nov 2005, 11:43+0800, Xin LI wrote: > > > Dear folks, > > > > Here is a patchset that taught inetd(8) about kqueue, and some other > > cleanups that raises WARNS level from 2 to 3, etc. > > > > http://people.freebsd.org/~delphij/for_review/patch-inetd-kqueue > > > > The kqueue part was a continuation of jmg@'s patchset. > > Can I ask: why? Or to ask a different question, why continue to use select? When I originally did the patch for inetd, I was VERY surprised at how little of the logic I had to change to make it use kqueue... Part of the reason I never committed it was that I did most of my work on 3.x at the time, and I had serious tcp connection rate issues with 4.x (-current) at the time, and people wanted benchmarks, but w/ 4.x, I couldn't get more than a hundred connections per second, while my 3.x box could do thousands... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 14:04:39 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80C2716A41F; Fri, 11 Nov 2005 14:04:39 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 107D443D45; Fri, 11 Nov 2005 14:04:38 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id C672A6541D; Fri, 11 Nov 2005 14:04:34 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10042-01-2; Fri, 11 Nov 2005 14:04:34 +0000 (GMT) Received: from empiric.dek.spc.org (unknown [62.53.14.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id A7D746538E; Fri, 11 Nov 2005 14:04:33 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 6525A6B39; Fri, 11 Nov 2005 14:04:24 +0000 (GMT) Date: Fri, 11 Nov 2005 14:04:24 +0000 From: Bruce M Simpson To: Maxim Konovalov , Xin LI , delphij@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20051111140424.GB733@empiric.icir.org> References: <20051110172650.Q48388@mp2.macomnet.net> <20051110204849.GC775@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051110204849.GC775@funkthat.com> Cc: Subject: Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 14:04:39 -0000 On Thu, Nov 10, 2005 at 12:48:49PM -0800, John-Mark Gurney wrote: > > > Here is a patchset that taught inetd(8) about kqueue, and some other > > > cleanups that raises WARNS level from 2 to 3, etc. > > > The kqueue part was a continuation of jmg@'s patchset. > > Can I ask: why? > Or to ask a different question, why continue to use select? When I > originally did the patch for inetd, I was VERY surprised at how little > of the logic I had to change to make it use kqueue... I'm ambivalent about the change. On one hand, more exposure for kqueue considered a good thing. On the other, this means change in inetd which causes it to deviate from common BSD -- although I think we're happy for inetd to deviate because we already have special cases for IPSEC in there, which is actually quite cool. On a slightly different note, writing a BSD-only routing daemon with kqueue is quite easy -- it readily facilitates event driven programming and explicit co-routines. If you can divide your program up into logical event-driven steps, whilst preserving the state you need, kqueue makes dispatch more simple. select() alone involves copying and maintenance of multiple fd_sets, as well as converting the results you get back into things which make sense. What I'd like to see from someone with free time on their hands is to look at how kqueue might be used within XORP, which has used a select() driven event loop for far too long: http://www.xorp.org/ Regards, BMS From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 14:09:37 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD24716A41F; Fri, 11 Nov 2005 14:09:37 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4647D43D69; Fri, 11 Nov 2005 14:09:37 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 80C8C6541D; Fri, 11 Nov 2005 14:09:36 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10042-01-15; Fri, 11 Nov 2005 14:09:36 +0000 (GMT) Received: from empiric.dek.spc.org (unknown [62.53.14.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id D90AF65410; Fri, 11 Nov 2005 14:09:35 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id AB0196B39; Fri, 11 Nov 2005 14:09:26 +0000 (GMT) Date: Fri, 11 Nov 2005 14:09:26 +0000 From: Bruce M Simpson To: Gleb Smirnoff Message-ID: <20051111140926.GC733@empiric.icir.org> References: <20051107140451.GU91530@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051107140451.GU91530@cell.sick.ru> Cc: arch@FreeBSD.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 14:09:37 -0000 On Mon, Nov 07, 2005 at 05:04:51PM +0300, Gleb Smirnoff wrote: > I suggest to keep sending ARP requests while there is a demand for > this (we are trying to transmit packets to this particular IP), > ratelimiting these requests to one per second. This will help in a > quite common case, when some host on net is rebooting, and we are > waiting for him to come up, and notice this only after 1 - 20 seconds > since the time it is reachable. > Any objections? In response to the other replies to this thread citing broadcast pollution on Ethernet-based networks: Please add this functionality under a sysctl where it is turned off by default. It is desirable in situations where ARP entries cached further upstream are stale, but it may cause flooding in an environment where the layer 2 backbone hasn't been split or has not been segregated well. Other people cited examples where vendor switch implementations were retransmitting across VLANs -- this week I've been offering moral support to a friend who is dealing with similar VLAN brokenness at his $DAYJOB (there was an extension to 802.1d to support multiple spanning tree instances across VLANs which I think not everyone supports correctly). Regards, BMS From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 14:15:24 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62B0016A41F for ; Fri, 11 Nov 2005 14:15:24 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1B6C43D49 for ; Fri, 11 Nov 2005 14:15:23 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jABEFKhw041764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2005 17:15:21 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jABEFKHp041763; Fri, 11 Nov 2005 17:15:20 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Nov 2005 17:15:19 +0300 From: Gleb Smirnoff To: Bruce M Simpson Message-ID: <20051111141519.GE1647@cell.sick.ru> References: <20051107140451.GU91530@cell.sick.ru> <20051111140926.GC733@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051111140926.GC733@empiric.icir.org> User-Agent: Mutt/1.5.6i Cc: arch@FreeBSD.org Subject: Re: ARP request retransmitting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 14:15:24 -0000 On Fri, Nov 11, 2005 at 02:09:26PM +0000, Bruce M Simpson wrote: B> On Mon, Nov 07, 2005 at 05:04:51PM +0300, Gleb Smirnoff wrote: B> > I suggest to keep sending ARP requests while there is a demand for B> > this (we are trying to transmit packets to this particular IP), B> > ratelimiting these requests to one per second. This will help in a B> > quite common case, when some host on net is rebooting, and we are B> > waiting for him to come up, and notice this only after 1 - 20 seconds B> > since the time it is reachable. B> > Any objections? B> B> In response to the other replies to this thread citing broadcast B> pollution on Ethernet-based networks: B> Please add this functionality under a sysctl where it is turned off by default. B> B> It is desirable in situations where ARP entries cached further upstream are B> stale, but it may cause flooding in an environment where the layer 2 backbone B> hasn't been split or has not been segregated well. B> B> Other people cited examples where vendor switch implementations were B> retransmitting across VLANs -- this week I've been offering moral support B> to a friend who is dealing with similar VLAN brokenness at his $DAYJOB B> (there was an extension to 802.1d to support multiple spanning tree instances B> across VLANs which I think not everyone supports correctly). I'd like to see a proven evidence that this functionality leads to a measurable increase in broadcast traffic. Many modern operating systems behave in such way and no-one complains. The increase of broadcast traffic is very theoretical, it happens only when there are downed hosts. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 00:03:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCF9716A41F; Sat, 12 Nov 2005 00:03:27 +0000 (GMT) (envelope-from fbsd-arch@mawer.org) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E32B43D46; Sat, 12 Nov 2005 00:03:26 +0000 (GMT) (envelope-from fbsd-arch@mawer.org) Received: from [127.0.0.1] (c220-237-120-88.thorn1.nsw.optusnet.com.au [220.237.120.88]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jAC035Rh025763; Sat, 12 Nov 2005 11:03:24 +1100 Message-ID: <43753142.7060002@mawer.org> Date: Sat, 12 Nov 2005 11:03:14 +1100 From: Antony Mawer User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Bruce M Simpson References: <20051110172650.Q48388@mp2.macomnet.net> <20051110204849.GC775@funkthat.com> <20051111140424.GB733@empiric.icir.org> In-Reply-To: <20051111140424.GB733@empiric.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: delphij@freebsd.org, Xin LI , freebsd-arch@freebsd.org Subject: Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 00:03:27 -0000 On 12/11/2005 1:04 AM, Bruce M Simpson wrote: > I'm ambivalent about the change. On one hand, more exposure for kqueue > considered a good thing. On the other, this means change in inetd which > causes it to deviate from common BSD -- although I think we're happy for > inetd to deviate because we already have special cases for IPSEC in there, > which is actually quite cool. While on the topic of inetd and deviating from the other BSDs, I noticed when playing with pf that OpenBSD has the ability to bind services to specific interfaces in the inetd.conf file. Is there any interest in bringing this capability across to the FreeBSD inetd? I noticed the OpenBSD PR database suggests this came from NetBSD: http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?numbers=175&full=yes >>Fix: > re-import the code from NetBSD or elsewhere. Though I haven't delved into this further. Is anyone else interested in seeing this imported? If no one else takes up the challenge I might have a look in a couple of weeks time, although at the moment I'm suffering from ENOTIME. Cheers Antony From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 08:48:19 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A3016A41F for ; Sat, 12 Nov 2005 08:48:19 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DCCF43D4C for ; Sat, 12 Nov 2005 08:48:19 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by xproxy.gmail.com with SMTP id t10so1223629wxc for ; Sat, 12 Nov 2005 00:48:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Du9zBHFDidO8W2GyR7wAzJ41M85muXUdiQppGL9SG41/VwbBwx01mXiRG/Bi0ZPS7b8Z2g0Isx0Ll7FkvWR8QyPK94R0TbuoRj/wsqv3OR5PqkMwKcH/5FRqlQJrVYRsmd3mlglkrM+9bbArjh3mO/OXio4JTGUlxx9jfralj4o= Received: by 10.65.20.6 with SMTP id x6mr1417730qbi; Fri, 11 Nov 2005 22:00:08 -0800 (PST) Received: by 10.65.191.18 with HTTP; Fri, 11 Nov 2005 22:00:08 -0800 (PST) Message-ID: Date: Sat, 12 Nov 2005 14:00:08 +0800 From: Xin LI To: Antony Mawer In-Reply-To: <43753142.7060002@mawer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051110172650.Q48388@mp2.macomnet.net> <20051110204849.GC775@funkthat.com> <20051111140424.GB733@empiric.icir.org> <43753142.7060002@mawer.org> Cc: Bruce M Simpson , delphij@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH FOR REVIEW] kqueue'ify inetd(8) and several other cleanups X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 08:48:19 -0000 T24gMTEvMTIvMDUsIEFudG9ueSBNYXdlciA8ZmJzZC1hcmNoQG1hd2VyLm9yZz4gd3JvdGU6Cj4g T24gMTIvMTEvMjAwNSAxOjA0IEFNLCBCcnVjZSBNIFNpbXBzb24gd3JvdGU6Cj4gV2hpbGUgb24g dGhlIHRvcGljIG9mIGluZXRkIGFuZCBkZXZpYXRpbmcgZnJvbSB0aGUgb3RoZXIgQlNEcywgSSBu b3RpY2VkCj4gd2hlbiBwbGF5aW5nIHdpdGggcGYgdGhhdCBPcGVuQlNEIGhhcyB0aGUgYWJpbGl0 eSB0byBiaW5kIHNlcnZpY2VzIHRvCj4gc3BlY2lmaWMgaW50ZXJmYWNlcyBpbiB0aGUgaW5ldGQu Y29uZiBmaWxlLiBJcyB0aGVyZSBhbnkgaW50ZXJlc3QgaW4KPiBicmluZ2luZyB0aGlzIGNhcGFi aWxpdHkgYWNyb3NzIHRvIHRoZSBGcmVlQlNEIGluZXRkPwo+Cj4gSSBub3RpY2VkIHRoZSBPcGVu QlNEIFBSIGRhdGFiYXNlIHN1Z2dlc3RzIHRoaXMgY2FtZSBmcm9tIE5ldEJTRDoKClllcywgdGhh dCB3YXMgaW4gbXkgVE9ETyBsaXN0LCB0b28uICBQZXJzb25hbGx5IEknZCBwcmVmZXIgT3BlbkJT RCdzCnZlcnNpb24sIGhvd2V2ZXIsIHRoZSBjaGFuZ2UgaXMgbm90IGp1c3QgdG8gaW1wb3J0IHRo ZWlyIGNoYW5nZXMsIGFzCndlIGFscmVhZHkgZGlkIG1hbnkgY2hhbmdlcyBhZ2FpbnN0IGluZXRk KDgpLCB3aGljaCBtYWRlIHNpbXBsZQpyZS1pbXBvcnQgaW1wcmFjdGljYWwuCgpDaGVlcnMsCi0t ClhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlqLm5ldAo= From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 09:12:35 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 949AA16A41F for ; Sat, 12 Nov 2005 09:12:35 +0000 (GMT) (envelope-from Juergen.Dankoweit@t-online.de) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE93143D46 for ; Sat, 12 Nov 2005 09:12:34 +0000 (GMT) (envelope-from Juergen.Dankoweit@t-online.de) Received: from fwd32.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1EarR3-0003cT-06; Sat, 12 Nov 2005 10:12:33 +0100 Received: from mailsmtp.juergendankoweit.net (X7lE+GZBYe0nOljno02gUfi6CfyR4nrhSoeJ58enARUkEtyakrq98T@[84.150.103.189]) by fwd32.sul.t-online.de with esmtp id 1EarQv-1yrYpc0; Sat, 12 Nov 2005 10:12:25 +0100 Received: from localhost.juergendankoweit.net (localhost.juergendankoweit.net [127.0.0.1]) by mailsmtp.juergendankoweit.net (Postfix) with ESMTP id E25CF33FF6 for ; Sat, 12 Nov 2005 10:12:24 +0100 (CET) Received: from mailsmtp.juergendankoweit.net (localhost.juergendankoweit.net [127.0.0.1]) by localhost.juergendankoweit.net (AvMailGate-2.0.2-9) id 03877-6CB179C2; Sat, 12 Nov 2005 10:12:24 +0100 Received: from primergy470.juergendankoweit.net (primergy470.juergendankoweit.net [192.168.1.1]) by mailsmtp.juergendankoweit.net (Postfix) with ESMTP id 7A6FB33C4C for ; Sat, 12 Nov 2005 10:12:24 +0100 (CET) From: Juergen Dankoweit To: freebsd-arch@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Date: Sat, 12 Nov 2005 10:12:22 +0100 Message-Id: <1131786743.2050.7.camel@primergy470.juergendankoweit.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-9; AVE: 6.32.0.58; VDF: 6.32.0.172; host: primergy470.juergendankoweit.net) X-ID: X7lE+GZBYe0nOljno02gUfi6CfyR4nrhSoeJ58enARUkEtyakrq98T X-TOI-MSGID: 3c859558-0839-4e27-ba0f-7fb66f59e45d Cc: Subject: FreeBSD on embedded systems X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Juergen.Dankoweit@T-Online.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 09:12:35 -0000 Hello, at the Munich trade fair "Systems 2005" I was asked from a visitor on which embedded systems FreeBSD is running (I was there to promote FreeBSD). He give me his vcard and pointed out that he is a developer on embedded systems. He is very interested in FreeBSD on such systems and he wants to migrate some applications to that platform. I was surprised about this question and the only system that comes in my mind was "Soekris". My question is now: is there an overview on which embedded systems FreeBSD runs? Many thanks for your answer J=C3=BCrgen Dankoweit From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 09:15:50 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D673116A41F for ; Sat, 12 Nov 2005 09:15:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EEC143D45 for ; Sat, 12 Nov 2005 09:15:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E05E0BC84; Sat, 12 Nov 2005 09:15:48 +0000 (UTC) To: Juergen.Dankoweit@T-Online.de From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 12 Nov 2005 10:12:22 +0100." <1131786743.2050.7.camel@primergy470.juergendankoweit.net> Date: Sat, 12 Nov 2005 10:15:48 +0100 Message-ID: <15738.1131786948@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@FreeBSD.org Subject: Re: FreeBSD on embedded systems X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 09:15:50 -0000 In message <1131786743.2050.7.camel@primergy470.juergendankoweit.net>, Juergen Dankoweit writes: >My question is now: is there an overview on which embedded systems >FreeBSD runs? Typically in this space, people select hardware based on I/O requirements and there is plenty to pick at. FreeBSD runs on pretty much anything with an i386 compatible CPU, and the soekris is merely the hackers favourite. Maintaining a comprehensive list would be a bit of work, but not a lot of work, so if somebody volunteers for it, I'm sure we can find a spot for it on our web-pages. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 10:42:58 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9B0216A41F for ; Sat, 12 Nov 2005 10:42:58 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2781443D46 for ; Sat, 12 Nov 2005 10:42:55 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jACAghCf046522 for ; Sat, 12 Nov 2005 10:42:43 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: arch@freebsd.org Date: Sat, 12 Nov 2005 10:42:42 +0000 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511121042.42425.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Sat, 12 Nov 2005 10:42:43 +0000 (GMT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1169/Fri Nov 11 21:28:05 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: Subject: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 10:42:59 -0000 For quite a while now (far too long in fact), I've been slowly working on an extension framework for GSS-API. This was partly prompted by an interest in NFSv4 which requires both LIPKEY [RFC2847] as well as Kerberosv5 as security providers. The existing FreeBSD GSS-API library comes from Heimdal and only provides Kerberosv5. It is also a necessary pre-requisite for an implementation of RPCSEC_GSS which I'm not quite ready to commit. The new GSS-API code acts as a plugin framework which can use any shared library GSS-API implementation that conforms to the C-bindings set out in RFC2744. I have changed the heimdal build process to build its GSS-API implementation as a plugin. I have not implemented any new GSS-API mechanisms. One clear advantage to this system is that the GSS-API framework itself is tiny (20k of code on i386) and includes no crypto code. It also has no dependencies so applications don't have to supply a random list of heimdal implementation details when they link with it. In an attempt to move us closer to the de-facto standard for GSS-API, I've moved the gssapi header file to /usr/include/gssapi. This is where it lives on every non-BSD system that I've looked at, including OS X. I have also included a complete set of manpages for the api with text culled from the RFC (markup by me - mandoc police take note). It is currently missing manpages for two new config files, /etc/gss/mech and /etc/gss/qop. You can read the Solaris manpages for these files at http://docs.sun.com/app/docs/doc/816-5174/6mbb98uh0?a=view. The patch is too large to post here but you can find it at http://people.freebsd.org/~dfr/gss-12112005.diff. It has survived limited buildworld testing on one architecture and limited testing on a newly install FreeBSD-current machine. I have not attempted to build any GSS-API using ports and I expect there to be problems in that area due to the moved header file and changed linking requirements. Any comments, feedback, patches welcome... From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 11:06:29 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA27416A41F for ; Sat, 12 Nov 2005 11:06:29 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A774643D45 for ; Sat, 12 Nov 2005 11:06:29 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B2EC946BB5; Sat, 12 Nov 2005 06:06:26 -0500 (EST) Date: Sat, 12 Nov 2005 11:06:26 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Rabson In-Reply-To: <200511121042.42425.dfr@nlsystems.com> Message-ID: <20051112110504.X33260@fledge.watson.org> References: <200511121042.42425.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 11:06:30 -0000 On Sat, 12 Nov 2005, Doug Rabson wrote: > For quite a while now (far too long in fact), I've been slowly working > on an extension framework for GSS-API. This was partly prompted by an > interest in NFSv4 which requires both LIPKEY [RFC2847] as well as > Kerberosv5 as security providers. The existing FreeBSD GSS-API library > comes from Heimdal and only provides Kerberosv5. It is also a necessary > pre-requisite for an implementation of RPCSEC_GSS which I'm not quite > ready to commit. This is great news! Have you taken a look at the Solaris inclusion of gssapi parts in their kernel: http://fxr.watson.org/fxr/source/common/gssapi/?v=OPENSOLARIS I assume this is associated with NFSv4 support, but haven't dug around at all yet other than noticing it there the other day. Most other discussion of GSSAPI I've seen assumes that the crypto takes place in user space, but having it in kernel has some significant advantages (especially if you have a fully preemptive kernel, which we now have). Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 11:15:53 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DAED16A420; Sat, 12 Nov 2005 11:15:53 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47D8D43D46; Sat, 12 Nov 2005 11:15:52 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jACBFe9K046651; Sat, 12 Nov 2005 11:15:40 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Robert Watson Date: Sat, 12 Nov 2005 11:15:38 +0000 User-Agent: KMail/1.8.2 References: <200511121042.42425.dfr@nlsystems.com> <20051112110504.X33260@fledge.watson.org> In-Reply-To: <20051112110504.X33260@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511121115.38732.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Sat, 12 Nov 2005 11:15:40 +0000 (GMT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1169/Fri Nov 11 21:28:05 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: arch@freebsd.org Subject: Re: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 11:15:53 -0000 On Saturday 12 November 2005 11:06, Robert Watson wrote: > On Sat, 12 Nov 2005, Doug Rabson wrote: > > For quite a while now (far too long in fact), I've been slowly > > working on an extension framework for GSS-API. This was partly > > prompted by an interest in NFSv4 which requires both LIPKEY > > [RFC2847] as well as Kerberosv5 as security providers. The existing > > FreeBSD GSS-API library comes from Heimdal and only provides > > Kerberosv5. It is also a necessary pre-requisite for an > > implementation of RPCSEC_GSS which I'm not quite ready to commit. > > This is great news! Have you taken a look at the Solaris inclusion > of gssapi parts in their kernel: > > http://fxr.watson.org/fxr/source/common/gssapi/?v=OPENSOLARIS > > I assume this is associated with NFSv4 support, but haven't dug > around at all yet other than noticing it there the other day. Most > other discussion of GSSAPI I've seen assumes that the crypto takes > place in user space, but having it in kernel has some significant > advantages (especially if you have a fully preemptive kernel, which > we now have). I have looked at the Solaris kernel GSS-API code. As far as I can see on a first reading, they defer the context establishment out to userland and once the context is up, they do the actual crypto for signing etc. in the kernel, via a plugin model. Doing all the crypto in userland isn't really a good idea because even when you aren't using message privacy and integrity, parts of the RPC header are still signed for basic replay detection. Flipping all that out to userland would be devastating for performance. Rick Macklem's NFSv4 server code does its crypto in the kernel in a similar way to Solaris but it is hard-wired to kerberosv5. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 11:25:53 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5E1716A41F for ; Sat, 12 Nov 2005 11:25:53 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C93A43D46 for ; Sat, 12 Nov 2005 11:25:53 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0B4B746BAB; Sat, 12 Nov 2005 06:25:53 -0500 (EST) Date: Sat, 12 Nov 2005 11:25:52 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Rabson In-Reply-To: <200511121115.38732.dfr@nlsystems.com> Message-ID: <20051112112234.H33260@fledge.watson.org> References: <200511121042.42425.dfr@nlsystems.com> <20051112110504.X33260@fledge.watson.org> <200511121115.38732.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 11:25:53 -0000 On Sat, 12 Nov 2005, Doug Rabson wrote: > I have looked at the Solaris kernel GSS-API code. As far as I can see on > a first reading, they defer the context establishment out to userland > and once the context is up, they do the actual crypto for signing etc. > in the kernel, via a plugin model. > > Doing all the crypto in userland isn't really a good idea because even > when you aren't using message privacy and integrity, parts of the RPC > header are still signed for basic replay detection. Flipping all that > out to userland would be devastating for performance. Rick Macklem's > NFSv4 server code does its crypto in the kernel in a similar way to > Solaris but it is hard-wired to kerberosv5. I agree entirely with the above sentiments. Are you sure you can't make it to EuroBSDCon to talk about NFSv4 there? :-) Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 11:43:45 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DA1616A41F; Sat, 12 Nov 2005 11:43:45 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC84143D5A; Sat, 12 Nov 2005 11:43:39 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jACBhSDL046742; Sat, 12 Nov 2005 11:43:28 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Robert Watson Date: Sat, 12 Nov 2005 11:43:26 +0000 User-Agent: KMail/1.8.2 References: <200511121042.42425.dfr@nlsystems.com> <200511121115.38732.dfr@nlsystems.com> <20051112112234.H33260@fledge.watson.org> In-Reply-To: <20051112112234.H33260@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511121143.26697.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Sat, 12 Nov 2005 11:43:28 +0000 (GMT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1169/Fri Nov 11 21:28:05 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: arch@freebsd.org Subject: Re: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 11:43:45 -0000 On Saturday 12 November 2005 11:25, Robert Watson wrote: > On Sat, 12 Nov 2005, Doug Rabson wrote: > > I have looked at the Solaris kernel GSS-API code. As far as I can > > see on a first reading, they defer the context establishment out to > > userland and once the context is up, they do the actual crypto for > > signing etc. in the kernel, via a plugin model. > > > > Doing all the crypto in userland isn't really a good idea because > > even when you aren't using message privacy and integrity, parts of > > the RPC header are still signed for basic replay detection. > > Flipping all that out to userland would be devastating for > > performance. Rick Macklem's NFSv4 server code does its crypto in > > the kernel in a similar way to Solaris but it is hard-wired to > > kerberosv5. > > I agree entirely with the above sentiments. Are you sure you can't > make it to EuroBSDCon to talk about NFSv4 there? :-) Sorry, I really just can't make it this year :-( From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 15:58:13 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E47DB16A41F; Sat, 12 Nov 2005 15:58:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE1D743D45; Sat, 12 Nov 2005 15:58:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9380B46C0B; Sat, 12 Nov 2005 10:58:11 -0500 (EST) Date: Sat, 12 Nov 2005 15:58:11 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Edwards In-Reply-To: <20050701132104.GA95135@freefall.freebsd.org> Message-ID: <20051112154618.E66912@fledge.watson.org> References: <20050701132104.GA95135@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marc Olzheim , arch@freebsd.org Subject: Re: ktrace and KTR_DROP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 15:58:14 -0000 On Fri, 1 Jul 2005, Peter Edwards wrote: > Ever since the introduction of a separate ktrace worker thread for > writing output, there's the distinct possibility that ktrace output will > drop requests. For some proceses, it's actually inevitable: as long as > the traced processes can sustain a rate of generating ktrace events > faster than the ktrace thread can write them, you'll eventually run out > of ktrace requests. I sent you this patch earlier today, but figured a larger audience might make sense. The attached patch tries to find a happy medium between the approach taken in 4.x (commit immediately) and the 5.x approach (commit asynchronously in a worker). The reason we can't just use the 4.x model is that it assumes it is safe to perform sleepable VFS operations at pretty arbitrary points in the scheduler, etc. Since this is not the case under SMPng (and possibly not under 4.x), we most log certain trace records asynchronously. The prime candidate is the context switch tracing, which generates a record when switching away from and back to a user thread. There's also a case where a mutex is held in the signal code, but John believes that the code can be changes so the trace record isn't generated with the lock held. The attached patch is a first hack at the following: - Eliminate the ktrace worker thread and global record queue, as they are no longer used. Keep the global free record list, as records are still used. - Add a per-process record queue, which will hold any asynchronously generated records, such as from context switches. This replaces the global queue. - When a record is committed synchronously, first drain any pending per-process records in order to maintain ordering as best we can. Currently ordering between competing threads is provided via a global ktrace_sx, but a per-process flag or lock probably makes more sense. - When a record is committed asynchronously, simply queue it to the process. - When a process returns to user space, flush any pending records. - When a process exits, flush any pending records. - Assert on process tear-down that there are no pending records. - Slightly abstract the notion of being "in ktrace", which is used to prevent the recursive generation of records, as well as generating traces for ktrace events. Known issues: - When a record is drained asynchronously, it is committed using the current tracing credential and vnode. Potentially, in rare situations, this might be the wrong thing to do, as those might have changed since the record was generated. - When a thread sleeps, its context switch record won't be committed until it wakes up and returns to user space, or until another thread hits a draining point (such as submitting a synchronous record). If you're tracing a single-threaded process live, you won't be provided with the sleep record until it wakes up, which might be inconvenient. - It would be nice to do an atomic drain-and-disable on process exit. - ktrace_mtx and ktrace_sx are global, and so potentially contended. Unclear how much of a problem this is. - The sysret case may not be in the right place -- the drain point should probably be in userret, not in the system call return, as we also want to drain when returning from a VM trap, signal delivery, or whatever. Robert N M Watson --- //depot/vendor/freebsd/src/sys/kern/kern_exit.c 2005/11/08 17:15:28 +++ //depot/user/rwatson/ktrace/src/sys/kern/kern_exit.c 2005/11/12 13:53:30 @@ -366,8 +366,13 @@ (void)acct_process(td); #ifdef KTRACE /* - * release trace file + * Drain any pending records on the thread and release the trace + * file. + * + * XXXRW: These should be done atomically, so that there isn't a + * race. Probably via ktrexit(). */ + ktrsysretdrain(); PROC_LOCK(p); mtx_lock(&ktrace_mtx); p->p_traceflag = 0; /* don't trace the vrele() */ --- //depot/vendor/freebsd/src/sys/kern/kern_fork.c 2005/07/01 16:35:11 +++ //depot/user/rwatson/ktrace/src/sys/kern/kern_fork.c 2005/11/03 14:04:09 @@ -272,6 +272,7 @@ mac_init_proc(newproc); #endif knlist_init(&newproc->p_klist, &newproc->p_mtx, NULL, NULL, NULL); + STAILQ_INIT(&newproc->p_ktr); /* We have to lock the process tree while we look for a pid. */ sx_slock(&proctree_lock); --- //depot/vendor/freebsd/src/sys/kern/kern_ktrace.c 2005/11/01 14:50:28 +++ //depot/user/rwatson/ktrace/src/sys/kern/kern_ktrace.c 2005/11/12 13:53:10 @@ -1,6 +1,8 @@ /*- * Copyright (c) 1989, 1993 - * The Regents of the University of California. All rights reserved. + * The Regents of the University of California. + * Copyright (c) 2005 Robert N. M. Watson + * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -54,6 +56,25 @@ #include #include +/* + * The ktrace facility allows the tracing of certain key events in user space + * processes, such as system calls, signal delivery, context switches, and + * user generated events using utrace(2). It works by streaming event + * records and data to a vnode associated with the process using the + * ktrace(2) system call. In general, records can be written directly from + * the context that generates the event. One important exception to this is + * during a context switch, where sleeping is not permitted. To handle this + * case, trace events are generated using in-kernel ktr_request records, and + * then delivered to disk at a convenient moment -- either immediately, the + * next traceable event, at system call return, or at process exit. + * + * When dealing with multiple threads or processes writing to the same event + * log, ordering guarantees are weak: specifically, if an event has multiple + * records (i.e., system call enter and return), they may be interlaced with + * records from another event. Process and thread ID information is provided + * in the record, and user applications can de-interlace events if required. + */ + static MALLOC_DEFINE(M_KTRACE, "KTRACE", "KTRACE"); #ifdef KTRACE @@ -65,8 +86,6 @@ struct ktr_request { struct ktr_header ktr_header; void *ktr_buffer; - struct ucred *ktr_cred; - struct vnode *ktr_vp; union { struct ktr_syscall ktr_syscall; struct ktr_sysret ktr_sysret; @@ -88,7 +107,6 @@ 0 /* KTR_USER */ }; -static STAILQ_HEAD(, ktr_request) ktr_todo; static STAILQ_HEAD(, ktr_request) ktr_free; static SYSCTL_NODE(_kern, OID_AUTO, ktrace, CTLFLAG_RD, 0, "KTRACE options"); @@ -104,34 +122,62 @@ static int print_message = 1; struct mtx ktrace_mtx; static struct cv ktrace_cv; +static struct sx ktrace_sx; static void ktrace_init(void *dummy); static int sysctl_kern_ktrace_request_pool(SYSCTL_HANDLER_ARGS); static u_int ktrace_resize_pool(u_int newsize); static struct ktr_request *ktr_getrequest(int type); -static void ktr_submitrequest(struct ktr_request *req); +static void ktr_submitrequest(struct thread *td, struct ktr_request *req); static void ktr_freerequest(struct ktr_request *req); -static void ktr_loop(void *dummy); -static void ktr_writerequest(struct ktr_request *req); +static void ktr_writerequest(struct thread *td, struct ktr_request *req); static int ktrcanset(struct thread *,struct proc *); static int ktrsetchildren(struct thread *,struct proc *,int,int,struct vnode *); static int ktrops(struct thread *,struct proc *,int,int,struct vnode *); +/* + * ktrace itself generates events, such as context switches, which we do not + * wish to trace. Maintain a flag, TDP_INKTRACE, on each thread to determine + * whether or not it is in a region where tracing of events should be + * suppressed. + */ +static void +ktrace_enter(struct thread *td) +{ + + KASSERT(!(td->td_pflags & TDP_INKTRACE), ("ktrace_enter: flag set")); + td->td_pflags |= TDP_INKTRACE; +} + +static void +ktrace_exit(struct thread *td) +{ + + KASSERT(td->td_pflags & TDP_INKTRACE, ("ktrace_exit: flag not set")); + td->td_pflags &= ~TDP_INKTRACE; +} + static void +ktrace_assert(struct thread *td) +{ + + KASSERT(td->td_pflags & TDP_INKTRACE, ("ktrace_assert: flag not set")); +} + +static void ktrace_init(void *dummy) { struct ktr_request *req; int i; mtx_init(&ktrace_mtx, "ktrace", NULL, MTX_DEF | MTX_QUIET); + sx_init(&ktrace_sx, "ktrace_sx"); cv_init(&ktrace_cv, "ktrace"); - STAILQ_INIT(&ktr_todo); STAILQ_INIT(&ktr_free); for (i = 0; i < ktr_requestpool; i++) { req = malloc(sizeof(struct ktr_request), M_KTRACE, M_WAITOK); STAILQ_INSERT_HEAD(&ktr_free, req, ktr_list); } - kthread_create(ktr_loop, NULL, NULL, RFHIGHPID, 0, "ktrace"); } SYSINIT(ktrace_init, SI_SUB_KTRACE, SI_ORDER_ANY, ktrace_init, NULL); @@ -154,12 +200,12 @@ if (error) return (error); td = curthread; - td->td_pflags |= TDP_INKTRACE; + ktrace_enter(td); mtx_lock(&ktrace_mtx); oldsize = ktr_requestpool; newsize = ktrace_resize_pool(wantsize); mtx_unlock(&ktrace_mtx); - td->td_pflags &= ~TDP_INKTRACE; + ktrace_exit(td); error = SYSCTL_OUT(req, &oldsize, sizeof(u_int)); if (error) return (error); @@ -214,27 +260,21 @@ struct proc *p = td->td_proc; int pm; - td->td_pflags |= TDP_INKTRACE; - mtx_lock(&ktrace_mtx); + ktrace_enter(td); /* XXX: In caller instead? */ if (!KTRCHECK(td, type)) { - mtx_unlock(&ktrace_mtx); - td->td_pflags &= ~TDP_INKTRACE; + ktrace_exit(td); return (NULL); } + mtx_lock(&ktrace_mtx); req = STAILQ_FIRST(&ktr_free); if (req != NULL) { STAILQ_REMOVE_HEAD(&ktr_free, ktr_list); + mtx_unlock(&ktrace_mtx); req->ktr_header.ktr_type = type; if (p->p_traceflag & KTRFAC_DROP) { req->ktr_header.ktr_type |= KTR_DROP; p->p_traceflag &= ~KTRFAC_DROP; } - KASSERT(p->p_tracevp != NULL, ("ktrace: no trace vnode")); - KASSERT(p->p_tracecred != NULL, ("ktrace: no trace cred")); - req->ktr_vp = p->p_tracevp; - VREF(p->p_tracevp); - req->ktr_cred = crhold(p->p_tracecred); - mtx_unlock(&ktrace_mtx); microtime(&req->ktr_header.ktr_time); req->ktr_header.ktr_pid = p->p_pid; req->ktr_header.ktr_tid = td->td_tid; @@ -248,32 +288,82 @@ mtx_unlock(&ktrace_mtx); if (pm) printf("Out of ktrace request objects.\n"); - td->td_pflags &= ~TDP_INKTRACE; + ktrace_exit(td); } return (req); } +/* + * Some trace generation environments don't permit direct access to VFS, + * such as during a context switch where sleeping is not allowed. Under these + * circumstances, queue a request to the thread to be written asynchronously + * later. + */ static void -ktr_submitrequest(struct ktr_request *req) +ktr_enqueuerequest(struct thread *td, struct ktr_request *req) { mtx_lock(&ktrace_mtx); - STAILQ_INSERT_TAIL(&ktr_todo, req, ktr_list); - cv_signal(&ktrace_cv); + STAILQ_INSERT_TAIL(&td->td_proc->p_ktr, req, ktr_list); mtx_unlock(&ktrace_mtx); - curthread->td_pflags &= ~TDP_INKTRACE; + ktrace_exit(td); +} + +/* + * Drain any pending ktrace records from the per-thread queue to disk. This + * is used both internally before committing other records, and also on + * system call return. We drain all the ones we can find at the time when + * drain is requested, but don't keep draining after that as those events + * may me approximately "after" the current event. + */ +static void +ktr_drain(struct thread *td) +{ + struct ktr_request *queued_req; + STAILQ_HEAD(, ktr_request) local_queue; + + ktrace_assert(td); + sx_assert(&ktrace_sx, SX_XLOCKED); + + STAILQ_INIT(&local_queue); /* XXXRW: needed? */ + + if (!STAILQ_EMPTY(&td->td_proc->p_ktr)) { + mtx_lock(&ktrace_mtx); + STAILQ_CONCAT(&local_queue, &td->td_proc->p_ktr); + mtx_unlock(&ktrace_mtx); + + while ((queued_req = STAILQ_FIRST(&local_queue))) { + STAILQ_REMOVE_HEAD(&local_queue, ktr_list); + ktr_writerequest(td, queued_req); + ktr_freerequest(queued_req); + } + } +} + +/* + * Submit a trace record for immediate commit to disk -- to be used only + * where entering VFS is OK. First drain any pending records that may have + * been cached in the thread. + */ +static void +ktr_submitrequest(struct thread *td, struct ktr_request *req) +{ + + ktrace_assert(td); + + sx_xlock(&ktrace_sx); + ktr_drain(td); + ktr_writerequest(td, req); + ktr_freerequest(req); + sx_xunlock(&ktrace_sx); + + ktrace_exit(td); } static void ktr_freerequest(struct ktr_request *req) { - crfree(req->ktr_cred); - if (req->ktr_vp != NULL) { - mtx_lock(&Giant); - vrele(req->ktr_vp); - mtx_unlock(&Giant); - } if (req->ktr_buffer != NULL) free(req->ktr_buffer, M_KTRACE); mtx_lock(&ktrace_mtx); @@ -281,38 +371,6 @@ mtx_unlock(&ktrace_mtx); } -static void -ktr_loop(void *dummy) -{ - struct ktr_request *req; - struct thread *td; - struct ucred *cred; - - /* Only cache these values once. */ - td = curthread; - cred = td->td_ucred; - for (;;) { - mtx_lock(&ktrace_mtx); - while (STAILQ_EMPTY(&ktr_todo)) - cv_wait(&ktrace_cv, &ktrace_mtx); - req = STAILQ_FIRST(&ktr_todo); - STAILQ_REMOVE_HEAD(&ktr_todo, ktr_list); - KASSERT(req != NULL, ("got a NULL request")); - mtx_unlock(&ktrace_mtx); - /* - * It is not enough just to pass the cached cred - * to the VOP's in ktr_writerequest(). Some VFS - * operations use curthread->td_ucred, so we need - * to modify our thread's credentials as well. - * Evil. - */ - td->td_ucred = req->ktr_cred; - ktr_writerequest(req); - td->td_ucred = cred; - ktr_freerequest(req); - } -} - /* * MPSAFE */ @@ -344,7 +402,7 @@ req->ktr_header.ktr_len = buflen; req->ktr_buffer = buf; } - ktr_submitrequest(req); + ktr_submitrequest(curthread, req); } /* @@ -365,7 +423,24 @@ ktp->ktr_code = code; ktp->ktr_error = error; ktp->ktr_retval = retval; /* what about val2 ? */ - ktr_submitrequest(req); + ktr_submitrequest(curthread, req); +} + +/* + * When a system call returns, it may be necessary to drain ktrace records + * hung off the thread from an earlier context switch. Also necessary when + * a thread exits. + */ +void +ktrsysretdrain(void) +{ + struct thread *td = curthread; + + ktrace_enter(td); + sx_xlock(&ktrace_sx); + ktr_drain(td); + sx_xunlock(&ktrace_sx); + ktrace_exit(td); } void @@ -391,7 +466,7 @@ req->ktr_header.ktr_len = namelen; req->ktr_buffer = buf; } - ktr_submitrequest(req); + ktr_submitrequest(curthread, req); } /* @@ -439,7 +514,7 @@ ktg->ktr_rw = rw; req->ktr_header.ktr_len = datalen; req->ktr_buffer = buf; - ktr_submitrequest(req); + ktr_submitrequest(curthread, req); } void @@ -460,7 +535,7 @@ kp->action = action; kp->mask = *mask; kp->code = code; - ktr_submitrequest(req); + ktr_enqueuerequest(curthread, req); } void @@ -476,7 +551,7 @@ kc = &req->ktr_data.ktr_csw; kc->out = out; kc->user = user; - ktr_submitrequest(req); + ktr_enqueuerequest(curthread, req); } #endif /* KTRACE */ @@ -519,7 +594,7 @@ if (ops != KTROP_CLEARFILE && facs == 0) return (EINVAL); - td->td_pflags |= TDP_INKTRACE; + ktrace_enter(td); if (ops != KTROP_CLEAR) { /* * an operation which requires a file argument. @@ -530,7 +605,7 @@ error = vn_open(&nd, &flags, 0, -1); if (error) { mtx_unlock(&Giant); - td->td_pflags &= ~TDP_INKTRACE; + ktrace_exit(td); return (error); } NDFREE(&nd, NDF_ONLY_PNBUF); @@ -539,7 +614,7 @@ if (vp->v_type != VREG) { (void) vn_close(vp, FREAD|FWRITE, td->td_ucred, td); mtx_unlock(&Giant); - td->td_pflags &= ~TDP_INKTRACE; + ktrace_exit(td); return (EACCES); } mtx_unlock(&Giant); @@ -647,7 +722,7 @@ (void) vn_close(vp, FWRITE, td->td_ucred, td); mtx_unlock(&Giant); } - td->td_pflags &= ~TDP_INKTRACE; + ktrace_exit(td); return (error); #else /* !KTRACE */ return (ENOSYS); @@ -688,7 +763,7 @@ } req->ktr_buffer = cp; req->ktr_header.ktr_len = uap->len; - ktr_submitrequest(req); + ktr_submitrequest(td, req); return (0); #else /* !KTRACE */ return (ENOSYS); @@ -787,12 +862,11 @@ } static void -ktr_writerequest(struct ktr_request *req) +ktr_writerequest(struct thread *td, struct ktr_request *req) { struct ktr_header *kth; struct vnode *vp; struct proc *p; - struct thread *td; struct ucred *cred; struct uio auio; struct iovec aiov[3]; @@ -800,18 +874,36 @@ int datalen, buflen, vrele_count; int error; - vp = req->ktr_vp; + /* + * We hold the vnode and credential for use in I/O in case ktrace is + * disabled on the process as we write out the request. + * + * XXXRW: This is not ideal: we could end up performing a write after + * the vnode has been closed. + */ + mtx_lock(&ktrace_mtx); + vp = td->td_proc->p_tracevp; + if (vp != NULL) + VREF(vp); + cred = td->td_proc->p_tracecred; + if (cred != NULL) + crhold(cred); + mtx_unlock(&ktrace_mtx); + /* * If vp is NULL, the vp has been cleared out from under this - * request, so just drop it. + * request, so just drop it. Make sure the credential and vnode are + * in sync: we should have both or neither. */ - if (vp == NULL) + if (vp == NULL) { + KASSERT(cred == NULL, ("ktr_writerequest: cred != NULL")); return; + } + KASSERT(cred != NULL, ("ktr_writerequest: cred == NULL")); + kth = &req->ktr_header; datalen = data_lengths[(u_short)kth->ktr_type & ~KTR_DROP]; buflen = kth->ktr_len; - cred = req->ktr_cred; - td = curthread; auio.uio_iov = &aiov[0]; auio.uio_offset = 0; auio.uio_segflg = UIO_SYSSPACE; @@ -835,6 +927,7 @@ auio.uio_resid += buflen; auio.uio_iovcnt++; } + mtx_lock(&Giant); vn_start_write(vp, &mp, V_WAIT); vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); @@ -884,17 +977,12 @@ } } sx_sunlock(&allproc_lock); + /* - * Second, clear this vnode from any pending requests. + * We can't clear any pending requests in threads that have cached + * them but not yet committed them, as those are per-thread. The + * thread will have to clear it itself on system call return. */ - mtx_lock(&ktrace_mtx); - STAILQ_FOREACH(req, &ktr_todo, ktr_list) { - if (req->ktr_vp == vp) { - req->ktr_vp = NULL; - vrele_count++; - } - } - mtx_unlock(&ktrace_mtx); mtx_lock(&Giant); while (vrele_count-- > 0) vrele(vp); --- //depot/vendor/freebsd/src/sys/kern/kern_proc.c 2005/11/08 09:13:20 +++ //depot/user/rwatson/ktrace/src/sys/kern/kern_proc.c 2005/11/12 13:53:30 @@ -156,6 +156,7 @@ KASSERT((td != NULL), ("proc_dtor: bad thread pointer")); kg = FIRST_KSEGRP_IN_PROC(p); KASSERT((kg != NULL), ("proc_dtor: bad kg pointer")); + KASSERT(STAILQ_EMPTY(&p->p_ktr), ("proc_dtor: non-empty p_ktr")); #endif /* Dispose of an alternate kstack, if it exists. --- //depot/vendor/freebsd/src/sys/sys/ktrace.h 2005/11/01 14:50:28 +++ //depot/user/rwatson/ktrace/src/sys/sys/ktrace.h 2005/11/02 14:14:37 @@ -68,6 +68,7 @@ #define KTRCHECK(td, type) ((td)->td_proc->p_traceflag & (1 << type)) #define KTRPOINT(td, type) \ (KTRCHECK((td), (type)) && !((td)->td_pflags & TDP_INKTRACE)) +#define KTRCHECKDRAIN(td) (!(STAILQ_EMPTY(&(td)->td_ktr))) /* * ktrace record types @@ -174,6 +175,7 @@ void ktrgenio(int, enum uio_rw, struct uio *, int); void ktrsyscall(int, int narg, register_t args[]); void ktrsysret(int, int, register_t); +void ktrsysretdrain(void); #else --- //depot/vendor/freebsd/src/sys/sys/proc.h 2005/11/08 09:13:20 +++ //depot/user/rwatson/ktrace/src/sys/sys/proc.h 2005/11/12 13:53:30 @@ -608,6 +608,7 @@ void *p_emuldata; /* (c) Emulator state data. */ struct label *p_label; /* (*) Proc (not subject) MAC label. */ struct p_sched *p_sched; /* (*) Scheduler-specific data. */ + STAILQ_HEAD(, ktr_request) p_ktr; /* (o) KTR event queue. */ }; #define p_session p_pgrp->pg_session From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 17:40:25 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C36D016A41F for ; Sat, 12 Nov 2005 17:40:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58BB643D45 for ; Sat, 12 Nov 2005 17:40:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jACHeIpP047093; Sat, 12 Nov 2005 10:40:21 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43762910.3080305@samsco.org> Date: Sat, 12 Nov 2005 10:40:32 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <15738.1131786948@critter.freebsd.dk> In-Reply-To: <15738.1131786948@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Juergen.Dankoweit@T-Online.de, freebsd-arch@freebsd.org Subject: Re: FreeBSD on embedded systems X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 17:40:25 -0000 Poul-Henning Kamp wrote: > In message <1131786743.2050.7.camel@primergy470.juergendankoweit.net>, Juergen > Dankoweit writes: > > >>My question is now: is there an overview on which embedded systems >>FreeBSD runs? > > > Typically in this space, people select hardware based on I/O > requirements and there is plenty to pick at. > > FreeBSD runs on pretty much anything with an i386 compatible CPU, > and the soekris is merely the hackers favourite. > > Maintaining a comprehensive list would be a bit of work, but not > a lot of work, so if somebody volunteers for it, I'm sure we can > find a spot for it on our web-pages. > FreeBSD is also being made to run on a variety of smaller ARM platforms right now like the ARM920T. It might also be possible to get a PPC platform like the 405G/440G working without a whole lot of work. Scott From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 18:29:06 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B08E816A41F; Sat, 12 Nov 2005 18:29:06 +0000 (GMT) (envelope-from rodrigc@c-24-147-19-135.hsd1.ma.comcast.net) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id F336D43D45; Sat, 12 Nov 2005 18:29:05 +0000 (GMT) (envelope-from rodrigc@c-24-147-19-135.hsd1.ma.comcast.net) Received: from dibbler.crodrigues.org (c-24-147-19-135.hsd1.ma.comcast.net[24.147.19.135]) by comcast.net (rwcrmhc12) with ESMTP id <200511121829040140012ojke>; Sat, 12 Nov 2005 18:29:04 +0000 Received: from c-24-147-19-135.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.4/8.13.1) with ESMTP id jACITAlP012418; Sat, 12 Nov 2005 13:29:10 -0500 (EST) (envelope-from rodrigc@c-24-147-19-135.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-135.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id jACIT9oY012417; Sat, 12 Nov 2005 13:29:09 -0500 (EST) (envelope-from rodrigc) Date: Sat, 12 Nov 2005 13:29:09 -0500 From: Craig Rodrigues To: freebsd-arch@freebsd.org Message-ID: <20051112182909.GA4301@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: kan@freebsd.org, jeff@freebsd.org Subject: [RFC] vfs_bio additions, motivated by XFS for FreeBSD project X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 18:29:06 -0000 Hi, Now that FreeBSD 6.0 is released, I would like to work on integrating code from the XFS for FreeBSD project into FreeBSD-CURRENT. Alexander Kabaev made some changes to vfs_bio.c which are needed by the XFS for FreeBSD code. In addition to some new functions, this patch adds three new fields to struct buf (b_fsprivate1, b_fsprivate2, b_fsprivate3). You don't see their use here, but in the XFS for FreeBSD code (which you can get from http://people.freebsd.org/~rodrigc/xfs/ ), they are used to cache certain information. Comments? --- //depot/vendor/freebsd/src/sys/kern/vfs_bio.c 2005/10/08 15:01:11 +++ //depot/projects/src/sys/kern/vfs_bio.c 2005/10/08 16:09:54 @@ -216,7 +216,7 @@ */ static struct mtx rbreqlock; -/* +/* * Synchronization (sleep/wakeup) variable for buffer requests. * Can contain the VFS_BIO_NEED flags defined below; setting/clearing is done * by and/or. @@ -233,8 +233,12 @@ /* * Lock that protects against bwait()/bdone()/B_DONE races. */ +static struct mtx bdonelock; -static struct mtx bdonelock; +/* + * Lock that protects against bwait()/bdone()/B_DONE races. + */ +static struct mtx bpinlock; /* * Definitions for the buffer free lists. @@ -523,6 +527,7 @@ mtx_init(&nblock, "needsbuffer lock", NULL, MTX_DEF); mtx_init(&bdlock, "buffer daemon lock", NULL, MTX_DEF); mtx_init(&bdonelock, "bdone lock", NULL, MTX_DEF); + mtx_init(&bpinlock, "bpin lock", NULL, MTX_DEF); /* next, make a null set of free lists */ for (i = 0; i < BUFFER_QUEUES; i++) @@ -636,7 +641,7 @@ * bremfree: * * Mark the buffer for removal from the appropriate free list in brelse. - * + * */ void bremfree(struct buf *bp) @@ -720,18 +725,51 @@ } /* + * Attempt to initiate asynchronous I/O on read-ahead blocks. We must + * clear BIO_ERROR and B_INVAL prior to initiating I/O . If B_CACHE is set, + * the buffer is valid and we do not have to do anything. + */ +void +breada(struct vnode * vp, daddr_t * rablkno, int * rabsize, + int cnt, struct ucred * cred) +{ + struct buf *rabp; + int i; + + for (i = 0; i < cnt; i++, rablkno++, rabsize++) { + if (inmem(vp, *rablkno)) + continue; + rabp = getblk(vp, *rablkno, *rabsize, 0, 0, 0); + + if ((rabp->b_flags & B_CACHE) == 0) { + if (curthread != PCPU_GET(idlethread)) + curthread->td_proc->p_stats->p_ru.ru_inblock++; + rabp->b_flags |= B_ASYNC; + rabp->b_flags &= ~B_INVAL; + rabp->b_ioflags &= ~BIO_ERROR; + rabp->b_iocmd = BIO_READ; + if (rabp->b_rcred == NOCRED && cred != NOCRED) + rabp->b_rcred = crhold(cred); + vfs_busy_pages(rabp, 0); + BUF_KERNPROC(rabp); + rabp->b_iooffset = dbtob(rabp->b_blkno); + bstrategy(rabp); + } else { + brelse(rabp); + } + } +} + +/* * Operates like bread, but also starts asynchronous I/O on - * read-ahead blocks. We must clear BIO_ERROR and B_INVAL prior - * to initiating I/O . If B_CACHE is set, the buffer is valid - * and we do not have to do anything. + * read-ahead blocks. */ int breadn(struct vnode * vp, daddr_t blkno, int size, daddr_t * rablkno, int *rabsize, int cnt, struct ucred * cred, struct buf **bpp) { - struct buf *bp, *rabp; - int i; + struct buf *bp; int rv = 0, readwait = 0; CTR3(KTR_BUF, "breadn(%p, %jd, %d)", vp, blkno, size); @@ -752,29 +790,8 @@ ++readwait; } - for (i = 0; i < cnt; i++, rablkno++, rabsize++) { - if (inmem(vp, *rablkno)) - continue; - rabp = getblk(vp, *rablkno, *rabsize, 0, 0, 0); + breada(vp, rablkno, rabsize, cnt, cred); - if ((rabp->b_flags & B_CACHE) == 0) { - if (curthread != PCPU_GET(idlethread)) - curthread->td_proc->p_stats->p_ru.ru_inblock++; - rabp->b_flags |= B_ASYNC; - rabp->b_flags &= ~B_INVAL; - rabp->b_ioflags &= ~BIO_ERROR; - rabp->b_iocmd = BIO_READ; - if (rabp->b_rcred == NOCRED && cred != NOCRED) - rabp->b_rcred = crhold(cred); - vfs_busy_pages(rabp, 0); - BUF_KERNPROC(rabp); - rabp->b_iooffset = dbtob(rabp->b_blkno); - bstrategy(rabp); - } else { - brelse(rabp); - } - } - if (readwait) { rv = bufwait(bp); } @@ -807,6 +824,10 @@ if (BUF_REFCNT(bp) == 0) panic("bufwrite: buffer is not busy???"); + + if (bp->b_pin_count > 0) + bunpin_wait(bp); + KASSERT(!(bp->b_vflags & BV_BKGRDINPROG), ("FFS background buffer should not get here %p", bp)); @@ -1117,6 +1138,11 @@ KASSERT(!(bp->b_flags & (B_CLUSTER|B_PAGING)), ("brelse: inappropriate B_PAGING or B_CLUSTER bp %p", bp)); + if (bp->b_flags & B_MANAGED) { + bqrelse(bp); + return; + } + if (bp->b_iocmd == BIO_WRITE && (bp->b_ioflags & BIO_ERROR) && !(bp->b_flags & B_INVAL)) { @@ -1286,7 +1312,7 @@ } } - + if (BUF_REFCNT(bp) > 1) { /* do not release to free list */ BUF_UNLOCK(bp); @@ -1394,6 +1420,18 @@ BUF_UNLOCK(bp); return; } + + if (bp->b_flags & B_MANAGED) { + if (bp->b_flags & B_REMFREE) { + mtx_lock(&bqlock); + bremfreel(bp); + mtx_unlock(&bqlock); + } + bp->b_flags &= ~(B_ASYNC | B_NOCACHE | B_AGE | B_RELBUF); + BUF_UNLOCK(bp); + return; + } + mtx_lock(&bqlock); /* Handle delayed bremfree() processing. */ if (bp->b_flags & B_REMFREE) @@ -1821,6 +1859,10 @@ bp->b_npages = 0; bp->b_dirtyoff = bp->b_dirtyend = 0; bp->b_bufobj = NULL; + bp->b_pin_count = 0; + bp->b_fsprivate1 = NULL; + bp->b_fsprivate2 = NULL; + bp->b_fsprivate3 = NULL; LIST_INIT(&bp->b_dep); @@ -2059,6 +2101,10 @@ if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT, NULL) != 0) continue; + if (bp->b_pin_count > 0) { + BUF_UNLOCK(bp); + continue; + } BO_LOCK(bp->b_bufobj); if ((bp->b_vflags & BV_BKGRDINPROG) != 0 || (bp->b_flags & B_DELWRI) == 0) { @@ -2393,6 +2439,19 @@ if ((bp->b_flags & B_VMIO) == 0 || (size > bp->b_kvasize)) { if (bp->b_flags & B_DELWRI) { + /* + * If buffer is pinned and caller does + * not want sleep waiting for it to be + * unpinned, bail out + * */ + if (bp->b_pin_count > 0) { + if (flags & GB_LOCK_NOWAIT) { + bqrelse(bp); + return (NULL); + } else { + bunpin_wait(bp); + } + } bp->b_flags |= B_NOCACHE; bwrite(bp); } else { @@ -3034,11 +3093,11 @@ struct bufobj *dropobj; void (*biodone)(struct buf *); - CTR3(KTR_BUF, "bufdone(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); dropobj = NULL; - KASSERT(BUF_REFCNT(bp) > 0, ("biodone: bp %p not busy %d", bp, BUF_REFCNT(bp))); + KASSERT(BUF_REFCNT(bp) > 0, ("biodone: bp %p not busy %d", bp, + BUF_REFCNT(bp))); KASSERT(!(bp->b_flags & B_DONE), ("biodone: bp %p already done", bp)); runningbufwakeup(bp); @@ -3053,6 +3112,19 @@ bufobj_wdrop(dropobj); return; } + + bufdone_finish(bp); + + if (dropobj) + bufobj_wdrop(dropobj); +} + +void +bufdone_finish(struct buf *bp) +{ + KASSERT(BUF_REFCNT(bp) > 0, ("biodone: bp %p not busy %d", bp, + BUF_REFCNT(bp))); + if (LIST_FIRST(&bp->b_dep) != NULL) buf_complete(bp); @@ -3118,7 +3190,8 @@ if (m == NULL) panic("biodone: page disappeared!"); bp->b_pages[i] = m; - pmap_qenter(trunc_page((vm_offset_t)bp->b_data), bp->b_pages, bp->b_npages); + pmap_qenter(trunc_page((vm_offset_t)bp->b_data), + bp->b_pages, bp->b_npages); } #if defined(VFS_BIO_DEBUG) if (OFF_TO_IDX(foff) != m->pindex) { @@ -3130,7 +3203,7 @@ /* * In the write case, the valid and clean bits are - * already changed correctly ( see bdwrite() ), so we + * already changed correctly ( see bdwrite() ), so we * only need to do this here in the read case. */ if ((bp->b_iocmd == BIO_READ) && !bogusflag && resid > 0) { @@ -3185,8 +3258,6 @@ bqrelse(bp); } else bdone(bp); - if (dropobj) - bufobj_wdrop(dropobj); } /* @@ -3742,6 +3813,32 @@ return (error); } +void +bpin(struct buf *bp) +{ + mtx_lock(&bpinlock); + bp->b_pin_count ++; + mtx_unlock(&bpinlock); +} + +void +bunpin(struct buf *bp) +{ + mtx_lock(&bpinlock); + if ( --bp->b_pin_count == 0) + wakeup(bp); + mtx_unlock(&bpinlock); +} + +void +bunpin_wait(struct buf *bp) +{ + mtx_lock(&bpinlock); + while (bp->b_pin_count > 0) + msleep(bp, &bpinlock, PRIBIO, "bwunpin", 0); + mtx_unlock(&bpinlock); +} + #include "opt_ddb.h" #ifdef DDB #include @@ -3794,3 +3891,4 @@ } } #endif /* DDB */ + --- //depot/vendor/freebsd/src/sys/kern/vfs_cluster.c 2005/08/14 09:53:08 +++ //depot/projects/src/sys/kern/vfs_cluster.c 2005/08/14 10:01:58 @@ -765,6 +765,12 @@ --len; continue; } + if (tbp->b_pin_count > 0) { + BUF_UNLOCK(tbp); + ++start_lbn; + --len; + continue; + } bremfree(tbp); tbp->b_flags &= ~B_DONE; @@ -868,6 +874,15 @@ BUF_UNLOCK(tbp); break; } + + /* + * Do not pull in pinned buffers. + */ + if (tbp->b_pin_count > 0) { + BUF_UNLOCK(tbp); + break; + } + /* * Ok, it's passed all the tests, * so remove it from the free list @@ -979,3 +994,4 @@ buflist->bs_nchildren = i + 1; return (buflist); } + --- //depot/vendor/freebsd/src/sys/sys/buf.h 2005/10/08 15:01:11 +++ //depot/projects/src/sys/sys/buf.h 2005/10/08 16:09:54 @@ -135,6 +135,10 @@ struct vm_page *b_pages[btoc(MAXPHYS)]; int b_npages; struct workhead b_dep; /* (D) List of filesystem dependencies. */ + void *b_fsprivate1; + void *b_fsprivate2; + void *b_fsprivate3; + int b_pin_count; }; #define b_object b_bufobj->bo_object @@ -214,7 +218,7 @@ #define B_01000000 0x01000000 /* Available flag. */ #define B_02000000 0x02000000 /* Available flag. */ #define B_PAGING 0x04000000 /* volatile paging I/O -- bypass VMIO */ -#define B_08000000 0x08000000 /* Available flag. */ +#define B_MANAGED 0x08000000 /* Managed by FS. */ #define B_RAM 0x10000000 /* Read ahead mark (flag) */ #define B_VMIO 0x20000000 /* VMIO flag */ #define B_CLUSTER 0x40000000 /* pagein op, so swap() can count it */ @@ -486,6 +490,7 @@ void bremfree(struct buf *); void bremfreef(struct buf *); /* XXX Force bremfree, only for nfs. */ int bread(struct vnode *, daddr_t, int, struct ucred *, struct buf **); +void breada(struct vnode *, daddr_t *, int *, int, struct ucred *); int breadn(struct vnode *, daddr_t, int, daddr_t *, int *, int, struct ucred *, struct buf **); void bdwrite(struct buf *); @@ -504,6 +509,7 @@ int bufwait(struct buf *); int bufwrite(struct buf *); void bufdone(struct buf *); +void bufdone_finish(struct buf *); int cluster_read(struct vnode *, u_quad_t, daddr_t, long, struct ucred *, long, int, struct buf **); @@ -527,7 +533,11 @@ struct buf *trypbuf(int *); void bwait(struct buf *, u_char, const char *); void bdone(struct buf *); +void bpin(struct buf *); +void bunpin(struct buf *); +void bunpin_wait(struct buf *); #endif /* _KERNEL */ #endif /* !_SYS_BUF_H_ */ + -- Craig Rodrigues rodrigc@crodrigues.org