From owner-freebsd-arch@FreeBSD.ORG Sun Dec 10 19:33:49 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABEC016A416 for ; Sun, 10 Dec 2006 19:33:49 +0000 (UTC) (envelope-from sivasile@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 384EA43CA8 for ; Sun, 10 Dec 2006 19:32:31 +0000 (GMT) (envelope-from sivasile@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1249011wxc for ; Sun, 10 Dec 2006 11:33:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WZ9Bw5gUhOzwH3/dsXwPFxA+c6H30wC8bC45WEw1NQY2WVzQr11xe2O9mRztd4yy3QCQ/hgIIBL3o9z76tDmmRCnaShUG7EsfHY56EDOc2O3c+N0k7wBllLe/nt67ASA4/UafE3rcwPvFdMXpJrrtaN163/Erkp0RH+Y4Vh5Rms= Received: by 10.90.78.9 with SMTP id a9mr6170038agb.1165779223165; Sun, 10 Dec 2006 11:33:43 -0800 (PST) Received: by 10.90.95.12 with HTTP; Sun, 10 Dec 2006 11:33:43 -0800 (PST) Message-ID: <69565f410612101133u32c0818bm8840164692901c88@mail.gmail.com> Date: Sun, 10 Dec 2006 14:33:43 -0500 From: "Stan Ivasilevich" To: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: 64-bit x86 support 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, 10 Dec 2006 19:33:49 -0000 Hello. Does FreeBSD support 64-bit x86 processors from Intel and AMD? I currently own a 32-bit machine (x86 Intel). I am running both Windows XP and FreeBSD 5.3. When I buy me a new computer that's 64-bit (dual core or quad core), I would like to run FreeBSD on it. I want to know if you support 64-bit x85 machines? Thank you. Stanislav Ivasilevich. From owner-freebsd-arch@FreeBSD.ORG Sun Dec 10 19:56:21 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7EE216A403 for ; Sun, 10 Dec 2006 19:56:21 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6528043CA2 for ; Sun, 10 Dec 2006 19:55:09 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id BEC9F604D; Sun, 10 Dec 2006 22:56:19 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 9DD22602D; Sun, 10 Dec 2006 22:56:19 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kBAJu6l2081501; Sun, 10 Dec 2006 22:56:06 +0300 (MSK) (envelope-from ru) Date: Sun, 10 Dec 2006 22:55:59 +0300 From: Ruslan Ermilov To: Stan Ivasilevich Message-ID: <20061210195559.GA81270@rambler-co.ru> References: <69565f410612101133u32c0818bm8840164692901c88@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <69565f410612101133u32c0818bm8840164692901c88@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-arch@freebsd.org Subject: Re: 64-bit x86 support 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, 10 Dec 2006 19:56:21 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 10, 2006 at 02:33:43PM -0500, Stan Ivasilevich wrote: > Hello. >=20 > Does FreeBSD support 64-bit x86 processors from Intel and AMD? I current= ly > own a 32-bit machine (x86 Intel). I am running both Windows XP and FreeB= SD > 5.3. When I buy me a new computer that's 64-bit (dual core or quad core)= , I > would like to run FreeBSD on it. I want to know if you support 64-bit x85 > machines? Thank you. >=20 Of couse we do; please see here for more details: http://www.freebsd.org/platforms/amd64.html Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFfGZPqRfpzJluFF4RArLzAKCOYDawi/mIXH/E+o4fJ41Nya+lbgCeOm3w M6wtKDgAZWnQUO+/wri0SmE= =3gK5 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 00:29:16 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD2DC16A40F; Mon, 11 Dec 2006 00:29:16 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AE4B43C9D; Mon, 11 Dec 2006 00:27:57 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from [127.0.0.1] (adsl-sj-9-245.rockisland.net [64.119.9.245]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id kBB0T6KC094486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Dec 2006 16:29:07 -0800 (PST) (envelope-from jdp@polstra.com) In-Reply-To: <200611201242.58088.jhb@freebsd.org> References: <200611201242.58088.jhb@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <095D8C4E-5C80-451A-8DF9-C3B307A0F603@polstra.com> Content-Transfer-Encoding: 7bit From: John Polstra Date: Sun, 10 Dec 2006 16:29:00 -0800 To: John Baldwin X-Mailer: Apple Mail (2.752.3) Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 11 Dec 2006 00:29:17 -0000 On Nov 20, 2006, at 9:42 AM, John Baldwin wrote: > It's going to be a function of the chipset, as something in the > chipset > (presumably a Host -> PCI bridge) has to listen for writes to > 0xfeeXXXXXX and > convert them into APIC messages. There are two ways I planned on > doing this: > > 1) Allow PCI-PCI bridges to be blacklisted, and the pcib_alloc_msi > [x]() > methods would compare the bridge's device id against a blacklist. > This can > matter if you have virtual PCI-PCI bridges that really a HT -> PCI > bridge or > the like. > > 2) Blacklist chipsets in the x86 MD code based on the device ID of > the first > Host -> PCI bridge at device 0.0.0. I have implemented both of these checks, except that I put #2 into the MI code since I couldn't find any reason to make it x86- specific. Here's the patch. Does it look OK to you? It works fine here. John Index: pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.324 diff -u -p -u -r1.324 pci.c --- pci.c 21 Nov 2006 05:46:09 -0000 1.324 +++ pci.c 11 Dec 2006 00:16:59 -0000 @@ -175,6 +175,24 @@ struct pci_quirk pci_quirks[] = { { 0 } }; +/* MSI device quirks. */ +struct msi_device_quirk { + uint32_t devid; /* Vendor/device ID */ + int flags; /* MSI quirk flags */ +}; + +#define MSI_QUIRK_NO_MSI 0x01 +#define MSI_QUIRK_NO_MSIX 0x02 + +struct msi_device_quirk msi_device_quirks[] = { + /* + * MSI doesn't work with the Intel E7501 chipset, at least on + * the Tyan 2721 motherboard. + */ + { 0x254c8086, MSI_QUIRK_NO_MSI | MSI_QUIRK_NO_MSIX }, + { 0 } +}; + /* map register information */ #define PCI_MAPMEM 0x01 /* memory map */ #define PCI_MAPMEMP 0x02 /* prefetchable memory map */ @@ -1116,6 +1134,43 @@ pci_resume_msi(device_t dev) } /* + * Return the MSI quirks associated with a specific device, typically + * a host-PCI or PCI-PCI bridge. + */ +static int +pci_get_msi_device_quirks(device_t dev) +{ + uint32_t devid; + int i; + + devid = pci_get_device(dev) << 16 | pci_get_vendor(dev); + for (i = 0; msi_device_quirks[i].devid != 0; i++) + if (msi_device_quirks[i].devid == devid) + return (msi_device_quirks[i].flags); + return (0); +} + +/* + * Return the systemwide MSI quirks. Currently, we just check for + * blacklisted chipsets as represented by the host-PCI bridge at + * device 0:0:0. In the future, it may become necessary to check other + * system attributes, such as the kenv values that give the motherboard + * manufacturer and model number. + */ +static int +pci_get_msi_global_quirks(void) +{ + device_t dev; + int quirks; + + quirks = 0; + dev = pci_find_bsf(0, 0, 0); + if (dev != NULL) + quirks |= pci_get_msi_device_quirks(dev); + return (quirks); +} + +/* * Attempt to allocate *count MSI messages. The actual number allocated is * returned in *count. After this function returns, each message will be * available to the driver as SYS_RES_IRQ resources starting at a rid 1. @@ -1126,7 +1181,7 @@ pci_alloc_msi_method(device_t dev, devic struct pci_devinfo *dinfo = device_get_ivars(child); pcicfgregs *cfg = &dinfo->cfg; struct resource_list_entry *rle; - int actual, error, i, irqs[32]; + int actual, error, i, irqs[32], quirks; uint16_t ctrl; /* Don't let count == 0 get us into trouble. */ @@ -1138,13 +1193,23 @@ pci_alloc_msi_method(device_t dev, devic if (rle != NULL && rle->res != NULL) return (ENXIO); + /* + * Check for MSI quirks that affect the whole system, and those + * that are specific to the device's parent bridge. + */ + quirks = pci_get_msi_global_quirks() | + pci_get_msi_device_quirks(device_get_parent(dev)); + /* Try MSI-X first. */ - error = pci_alloc_msix(dev, child, count); - if (error != ENODEV) - return (error); + if (!(quirks & MSI_QUIRK_NO_MSIX)) { + error = pci_alloc_msix(dev, child, count); + if (error != ENODEV) + return (error); + } /* MSI capability present? */ - if (cfg->msi.msi_location == 0 || !pci_do_msi) + if (cfg->msi.msi_location == 0 || !pci_do_msi || + (quirks & MSI_QUIRK_NO_MSI)) return (ENODEV); /* Already have allocated messages? */ From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 10:30:38 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F1E016A506 for ; Mon, 11 Dec 2006 10:30:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FF8F43D8C for ; Mon, 11 Dec 2006 10:25:33 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 43006 invoked from network); 11 Dec 2006 10:14:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Dec 2006 10:14:29 -0000 Message-ID: <457D3265.7070004@freebsd.org> Date: Mon, 11 Dec 2006 11:26:45 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: John Polstra References: <200611201242.58088.jhb@freebsd.org> <095D8C4E-5C80-451A-8DF9-C3B307A0F603@polstra.com> In-Reply-To: <095D8C4E-5C80-451A-8DF9-C3B307A0F603@polstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 11 Dec 2006 10:30:38 -0000 John Polstra wrote: > > On Nov 20, 2006, at 9:42 AM, John Baldwin wrote: > >> It's going to be a function of the chipset, as something in the chipset >> (presumably a Host -> PCI bridge) has to listen for writes to >> 0xfeeXXXXXX and >> convert them into APIC messages. There are two ways I planned on >> doing this: >> >> 1) Allow PCI-PCI bridges to be blacklisted, and the pcib_alloc_msi[x]() >> methods would compare the bridge's device id against a blacklist. >> This can >> matter if you have virtual PCI-PCI bridges that really a HT -> PCI >> bridge or >> the like. >> >> 2) Blacklist chipsets in the x86 MD code based on the device ID of the >> first >> Host -> PCI bridge at device 0.0.0. > > I have implemented both of these checks, except that I put #2 into the > MI code since I couldn't find any reason to make it x86-specific. > Here's the patch. Does it look OK to you? It works fine here. IIRC it is not only a chipset problem but also sometimes how a MSI capable chipset is wired on the mainboard. So some probing would have to be done as well. -- Andre From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 14:55:49 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA28316A407 for ; Mon, 11 Dec 2006 14:55:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CEF143C9D for ; Mon, 11 Dec 2006 14:54:32 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBBEtkH8008568; Mon, 11 Dec 2006 09:55:46 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: John Polstra Date: Mon, 11 Dec 2006 09:42:43 -0500 User-Agent: KMail/1.9.4 References: <200611201242.58088.jhb@freebsd.org> <095D8C4E-5C80-451A-8DF9-C3B307A0F603@polstra.com> In-Reply-To: <095D8C4E-5C80-451A-8DF9-C3B307A0F603@polstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612110942.44308.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Mon, 11 Dec 2006 09:55:46 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2315/Mon Dec 11 04:55:24 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 11 Dec 2006 14:55:49 -0000 On Sunday 10 December 2006 19:29, John Polstra wrote: > > On Nov 20, 2006, at 9:42 AM, John Baldwin wrote: > > > It's going to be a function of the chipset, as something in the > > chipset > > (presumably a Host -> PCI bridge) has to listen for writes to > > 0xfeeXXXXXX and > > convert them into APIC messages. There are two ways I planned on > > doing this: > > > > 1) Allow PCI-PCI bridges to be blacklisted, and the pcib_alloc_msi > > [x]() > > methods would compare the bridge's device id against a blacklist. > > This can > > matter if you have virtual PCI-PCI bridges that really a HT -> PCI > > bridge or > > the like. > > > > 2) Blacklist chipsets in the x86 MD code based on the device ID of > > the first > > Host -> PCI bridge at device 0.0.0. > > I have implemented both of these checks, except that I put #2 into > the MI code since I couldn't find any reason to make it x86- > specific. Here's the patch. Does it look OK to you? It works fine > here. Hmm. I did blacklist stuff several weeks ago but haven't had time to test it or post it yet. :( I do think I like your approach a bit better though. What I had so far is here: http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch I'm not sure if it's worth blacklisting MSI separate from MSI-X as that only makes a difference at the device level (chipsets just get a single memory write per interrupt either way, they can't tell MSI from MSI-X). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 17:11:25 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C578A16A415; Mon, 11 Dec 2006 17:11:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BAE743C9E; Mon, 11 Dec 2006 17:10:06 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBBHBGA1063307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Dec 2006 19:11:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kBBHBGqu020278; Mon, 11 Dec 2006 19:11:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBBHBFH3020277; Mon, 11 Dec 2006 19:11:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Dec 2006 19:11:15 +0200 From: Kostik Belousov To: "Arne H. Juul" Message-ID: <20061211171115.GD311@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7qSK/uQB79J36Y4o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: freebsd-arch@freebsd.org, freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 11 Dec 2006 17:11:26 -0000 --7qSK/uQB79J36Y4o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 11, 2006 at 04:07:09PM +0100, Arne H. Juul wrote: > On Mon, 11 Dec 2006, Arne H. Juul wrote: > Looking at the Java VM source code it does some tricks with dup2() to=20 > reopen the close()'d filedescriptor, making it point to a filedescriptor= =20 > that's pre-connected to a closed socket. >=20 > A small C program that duplicates this (using pipes to make it a bit > simpler) follows. I'm not sure if any standards demand that this > works like it used to on FreeBSD 4 / libc_r, but since Java uses it it > would be really nice if this could be made to work in FreeBSD 6 (libthr > and libpthread). Or maybe somebody has another suggestions on how to > implement the Java close() semantics? >=20 > Anyway, the following C program works as intended on FreeBSD 4, > hangs on FreeBSD 6 (amd64), compiled with: > cc -Wall -pthread read_dup2.c -o read_dup2 >=20 >=20 > #include > #include > #include > #include > #include >=20 > int p[2]; >=20 > void *run(void *arg) { > ssize_t res; > char tmp[128]; > fprintf(stderr, "reading...\n"); > res =3D read(p[0], tmp, sizeof(tmp)); > fprintf(stderr, "read result: %d\n", (int)res); > if (res < 0) { > perror("read"); > } > return arg; > } >=20 > int main(int argc, char **argv) { > pthread_t t; > int d =3D open("/dev/null", O_RDONLY); > if (pipe(p) !=3D 0) { > perror("pipe"); > return 1; > } > if (pthread_create(&t, NULL, run, NULL) !=3D 0) { > perror("thread create"); > return 1; > } > sleep(1); > d =3D open("/dev/null", O_RDONLY); > if (d < 0) { > perror("open dev null"); > exit(1); > } > if (dup2(d, p[0]) < 0) { > perror("dup2"); > exit(1); > } > if (pthread_join(t, NULL) !=3D 0) { > perror("thread join"); > exit(1); > } > return 0; > } I think that -arch@ is proper ML to discuss the issue. Your test example hangs becase read() takes one more hold count on the file descriptor operated upon. As result, when calling close, f_count of the rpipe (aka p[0]) is 2, close() decrements it, f_count becomes 1. Since f_count > 0, fdrop_locked simply returns instead of calling fo_close (see kern_descrip.c). I cannot find the statement in SUSv3 that would require interruption of the read() upon close() from another thread; this looks like undefined behaviour from the standard point of view. I think that JVM is more appropriate place for fix, but others may have different view point. --7qSK/uQB79J36Y4o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFfZEzC3+MBN1Mb4gRAqKBAJ0e2xoeobSLeRZjJQbFUs5/uXX3ywCgqkJM ZoWAOIyyznh7U1KYx8vpB8s= =CgYu -----END PGP SIGNATURE----- --7qSK/uQB79J36Y4o-- From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 22:40:41 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E163A16A4A0; Mon, 11 Dec 2006 22:40:41 +0000 (UTC) (envelope-from arnej@pvv.ntnu.no) Received: from decibel.pvv.ntnu.no (decibel.pvv.ntnu.no [129.241.210.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73FF144040; Mon, 11 Dec 2006 22:33:22 +0000 (GMT) (envelope-from arnej@pvv.ntnu.no) Received: from arnej by decibel.pvv.ntnu.no with local (Exim 4.60) (envelope-from ) id 1GttjM-0003Kw-2u; Mon, 11 Dec 2006 23:34:40 +0100 Date: Mon, 11 Dec 2006 23:34:40 +0100 (CET) From: "Arne H. Juul" To: Kostik Belousov In-Reply-To: <20061211171115.GD311@deviant.kiev.zoral.com.ua> Message-ID: References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org, freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 11 Dec 2006 22:40:42 -0000 On Mon, 11 Dec 2006, Kostik Belousov wrote: > On Mon, Dec 11, 2006 at 04:07:09PM +0100, Arne H. Juul wrote: >> Looking at the Java VM source code it does some tricks with dup2() to >> reopen the close()'d filedescriptor, making it point to a filedescriptor >> that's pre-connected to a closed socket. >> >> A small C program that duplicates this (using pipes to make it a bit >> simpler) follows. I'm not sure if any standards demand that this >> works like it used to on FreeBSD 4 / libc_r, but since Java uses it it >> would be really nice if this could be made to work in FreeBSD 6 (libthr >> and libpthread). Or maybe somebody has another suggestions on how to >> implement the Java close() semantics? > > I think that -arch@ is proper ML to discuss the issue. > > Your test example hangs becase read() takes one more hold count on the > file descriptor operated upon. As result, when calling close, f_count > of the rpipe (aka p[0]) is 2, close() decrements it, f_count becomes > 1. Since f_count > 0, fdrop_locked simply returns instead of calling > fo_close (see kern_descrip.c). > > I cannot find the statement in SUSv3 that would require interruption of > the read() upon close() from another thread; this looks like undefined > behaviour from the standard point of view. The best authority I've found says that the standards are silent (so the current FreeBSD 6 behaviour is allowed), I'm asking whether it is best practice and why it's changed since FreeBSD 4. > I think that JVM is more appropriate place for fix, but others may have > different view point. If it was just the JVM I would agree, but any threaded program that uses blocking I/O in some threads will probably need the same kind of handling at some point. And if you think about what that handling looks like, it's not exactly pretty: * when calling any potentially blocking system call (read/readv, write/writev, recv/recvfrom/recvmsg, send/sendto/sendmsg, accept, connect, poll, select, maybe others that I didn't think of) the application must: ** take a mutex ** remember in some structure (linked list or similar) keyed off the file descriptor that "this thread will now do blocking I/O" ** release the mutex ** perform the actual operation ** take the mutex again ** check if the operation was interrupted in a special way, if so return with EBADF ** release the mutex * instead of calling close() and dup2() the application must: ** take the mutex ** for each thread in the FD-associated structure, interrupt it in some special way (I'm guessing that setting a special flag and then sending SIGIO should work). ** actually do the close() / dup2() ** release the mutex This is exactly the sort of issue that should be solved by the thread library / kernel threads implementation and not in every threaded application that needs it, in my view. - Arne H. J. From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 23:24:20 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7356716A4A0; Mon, 11 Dec 2006 23:24:20 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FFD843CC3; Mon, 11 Dec 2006 23:22:48 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id kBBNNKNj029559; Mon, 11 Dec 2006 15:23:20 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200612110942.44308.jhb@freebsd.org> Date: Mon, 11 Dec 2006 15:23:20 -0800 (PST) From: John Polstra To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 11 Dec 2006 23:24:20 -0000 On 11-Dec-2006 John Baldwin wrote: > Hmm. I did blacklist stuff several weeks ago but haven't had time to > test it or post it yet. :( Oops. :-} > I do think I like your approach a bit better though. What I had so > far is here: > > http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch > > I'm not sure if it's worth blacklisting MSI separate from MSI-X as that > only makes a difference at the device level (chipsets just get a single > memory write per interrupt either way, they can't tell MSI from MSI-X). Since the MSI support is really your turf, I'll happily defer to you on it. If you decide my patch should go in, I could add the additional blacklisted bridges from your patch, add the tunable to ignore the blacklist, and eliminate the distinction between blacklisting MSI and MSI-X. Let me know whether I should go ahead and commit that. John From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 23:32:21 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D074116A5F5; Mon, 11 Dec 2006 23:32:21 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCB6F43CEA; Mon, 11 Dec 2006 23:27:23 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id kBBNSNxP029680; Mon, 11 Dec 2006 15:28:24 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <457D3265.7070004@freebsd.org> Date: Mon, 11 Dec 2006 15:28:23 -0800 (PST) From: John Polstra To: Andre Oppermann Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 11 Dec 2006 23:32:21 -0000 On 11-Dec-2006 Andre Oppermann wrote: > IIRC it is not only a chipset problem but also sometimes how a MSI capable > chipset is wired on the mainboard. I agree, that is probably the case. The pci_get_msi_global_quirks function is intended to be open-ended in the sense that it should do whatever it needs to do to figure out whether the system as a whole can support MSI or not. The function comment mentions checking kenv strings as an example. At this point I don't know all of the other checks that need to be done, but they should all fit into that function. > So some probing would have to be done as well. Actual probing might be risky. On my Tyan 2721 motherboard, enabling MSI wedges the system solid, requiring a HW reset to recover. John From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 00:16:10 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 910F216A407; Tue, 12 Dec 2006 00:16:09 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-arch@freebsd.org Date: Tue, 12 Dec 2006 08:16:07 +0800 User-Agent: KMail/1.8.2 References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612120816.07608.davidxu@freebsd.org> Cc: Kostik Belousov , "Arne H. Juul" , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 00:16:10 -0000 On Tuesday 12 December 2006 06:34, Arne H. Juul wrote: > This is exactly the sort of issue that should be solved by the > thread library / kernel threads implementation and not in every > threaded application that needs it, in my view. > It should not be done in new thread library, do you want a bloat and error-prone thread library ? Instead if this semantic is really necessary, it should be done in kernel. > - Arne H. J. David Xu From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 00:50:24 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F4B916A4C8; Tue, 12 Dec 2006 00:50:24 +0000 (UTC) (envelope-from arnej@pvv.ntnu.no) Received: from decibel.pvv.ntnu.no (decibel.pvv.ntnu.no [129.241.210.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DDC043CD0; Tue, 12 Dec 2006 00:48:40 +0000 (GMT) (envelope-from arnej@pvv.ntnu.no) Received: from arnej by decibel.pvv.ntnu.no with local (Exim 4.60) (envelope-from ) id 1GtvqI-0001FY-Pe; Tue, 12 Dec 2006 01:49:58 +0100 Date: Tue, 12 Dec 2006 01:49:58 +0100 (CET) From: "Arne H. Juul" To: David Xu In-Reply-To: <200612120816.07608.davidxu@freebsd.org> Message-ID: References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-java@freebsd.org, freebsd-arch@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 00:50:24 -0000 On Tue, 12 Dec 2006, David Xu wrote: > On Tuesday 12 December 2006 06:34, Arne H. Juul wrote: > >> This is exactly the sort of issue that should be solved by the >> thread library / kernel threads implementation and not in every >> threaded application that needs it, in my view. >> > It should not be done in new thread library, do you want a bloat > and error-prone thread library ? Instead if this semantic is really > necessary, it should be done in kernel. Well, it depends on the alternatives. If a clean kernel implementation is possible - yes please, of course. If only a complex, error-prone kernel implementation is possible, I would prefer to have the complexity in the thread library. That's better than having it in the kernel and (IMHO) better than having N implementation in various applications, especially since the applications don't necessarily know enough about the internals of the thread library and kernel interactions to get it right, much less efficient. That said, copying the linux_close.c workaround in the Java VM seems to solve my immediate problem, even if I think it's a bit ugly. But I have confidence that you can do a better and cleaner solution :-) - Arne H. J. From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 01:04:52 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 720F616A675; Tue, 12 Dec 2006 01:04:52 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-arch@freebsd.org Date: Tue, 12 Dec 2006 09:04:49 +0800 User-Agent: KMail/1.8.2 References: <200612120816.07608.davidxu@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612120904.49744.davidxu@freebsd.org> Cc: Kostik Belousov , "Arne H. Juul" , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 01:04:52 -0000 On Tuesday 12 December 2006 08:49, Arne H. Juul wrote: > On Tue, 12 Dec 2006, David Xu wrote: > > On Tuesday 12 December 2006 06:34, Arne H. Juul wrote: > > > > > >> This is exactly the sort of issue that should be solved by the > >> thread library / kernel threads implementation and not in every > >> threaded application that needs it, in my view. > > > > It should not be done in new thread library, do you want a bloat > > and error-prone thread library ? Instead if this semantic is really > > necessary, it should be done in kernel. > > Well, it depends on the alternatives. > If a clean kernel implementation is possible - yes please, of course. > If only a complex, error-prone kernel implementation is possible, > I would prefer to have the complexity in the thread library. > > That's better than having it in the kernel and (IMHO) better than having N > implementation in various applications, especially since the applications > don't necessarily know enough about the internals of the thread library > and kernel interactions to get it right, much less efficient. > > That said, copying the linux_close.c workaround in the Java VM seems to > solve my immediate problem, even if I think it's a bit ugly. But I have > confidence that you can do a better and cleaner solution :-) > > - Arne H. J. Thread library only manages POSIX threads, it is nothing to do with how user will use file. Sorry, I will not mess the thread library. David Xu From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 01:09:03 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C99F16A40F; Tue, 12 Dec 2006 01:09:03 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CA3943E27; Tue, 12 Dec 2006 01:04:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBC15whr006985; Mon, 11 Dec 2006 20:05:58 -0500 (EST) Date: Mon, 11 Dec 2006 20:05:58 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Arne H. Juul" In-Reply-To: Message-ID: References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Mon, 11 Dec 2006 20:05:58 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Kostik Belousov , freebsd-arch@freebsd.org, David Xu , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 01:09:03 -0000 On Tue, 12 Dec 2006, Arne H. Juul wrote: > On Tue, 12 Dec 2006, David Xu wrote: >> On Tuesday 12 December 2006 06:34, Arne H. Juul wrote: >> >>> This is exactly the sort of issue that should be solved by the >>> thread library / kernel threads implementation and not in every >>> threaded application that needs it, in my view. >>> >> It should not be done in new thread library, do you want a bloat >> and error-prone thread library ? Instead if this semantic is really >> necessary, it should be done in kernel. > > Well, it depends on the alternatives. > If a clean kernel implementation is possible - yes please, of course. > If only a complex, error-prone kernel implementation is possible, > I would prefer to have the complexity in the thread library. Hacking libthr or libpthread to do this for you is not an option. They would then look like libc_r since all fd's accesses would need to be wrapped. If this needs to be done, it must be in the kernel. Common sense leads me to think that a close() should release threads in IO operations (reads/writes/selects/polls) and return EBADF or something appropriate. At least when behavior is not dictated by POSIX or other historical/defactor behavior. -- DE From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 05:54:25 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DFEC16A403; Tue, 12 Dec 2006 05:54:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13CA443CAC; Tue, 12 Dec 2006 05:53:04 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 589B21291E2; Tue, 12 Dec 2006 16:54:20 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 11AB527432; Tue, 12 Dec 2006 16:54:19 +1100 (EST) Date: Tue, 12 Dec 2006 16:54:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Daniel Eischen In-Reply-To: Message-ID: <20061212160016.W56465@delplex.bde.org> References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , "Arne H. Juul" , freebsd-java@FreeBSD.org, David Xu , freebsd-arch@FreeBSD.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 05:54:25 -0000 On Mon, 11 Dec 2006, Daniel Eischen wrote: > Hacking libthr or libpthread to do this for you is not > an option. They would then look like libc_r since all > fd's accesses would need to be wrapped. If this needs > to be done, it must be in the kernel. > > Common sense leads me to think that a close() should release > threads in IO operations (reads/writes/selects/polls) and > return EBADF or something appropriate. At least when behavior > is not dictated by POSIX or other historical/defactor behavior. It's probably a nightmare in the kernel too. close() starts looking like revoke(), and revoke() has large problems and bugs in this area. At higher levels, revoke() has no support for either waking up or synchronizing with threads in I/O operations on the revoked file; it only tries to force a close on revoked files that are open, but due to reference counting problems it sometimes gets even this wrong. At lower levels, I think only the tty driver even partly understands that a device close() can occur while an (other) thread is in another operation on the device. Of course, most revokes are of ttys so the tty driver needs to understand this more than most. It uses a generation count to detect changes of the open instance. It doesn't wake up the other threads and depends on them checking the generation count. The check occurs mainly in ttysleep() where it is fundamentally incomplete on SMP systems -- there is no synchronization, so after a revoke(), threads running on other CPUs just blunder on like they do in other drivers. Giant locking of the tty driver reduces the problem. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 06:44:11 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3130D16A412; Tue, 12 Dec 2006 06:44:11 +0000 (UTC) (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 C8F7643CA4; Tue, 12 Dec 2006 06:42:49 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id CE2611747B; Tue, 12 Dec 2006 06:44:08 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 12 Dec 2006 16:54:19 +1100." <20061212160016.W56465@delplex.bde.org> Date: Tue, 12 Dec 2006 06:44:03 +0000 Message-ID: <32874.1165905843@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Arne H. Juul" , Daniel Eischen , David Xu , freebsd-arch@FreeBSD.org, Kostik Belousov , freebsd-java@FreeBSD.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 06:44:11 -0000 In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes: >On Mon, 11 Dec 2006, Daniel Eischen wrote: >It's probably a nightmare in the kernel too. close() starts looking >like revoke(), and revoke() has large problems and bugs in this area. There is the distinctive difference that revoke() operates on a name and close() on a filedescriptor, but otherwise I agree. -- 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 Tue Dec 12 13:21:20 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B479916A417; Tue, 12 Dec 2006 13:21:20 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E3443DBA; Tue, 12 Dec 2006 13:17:24 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBCDIWqu003219; Tue, 12 Dec 2006 08:18:33 -0500 (EST) Date: Tue, 12 Dec 2006 08:18:32 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Arne H. Juul" In-Reply-To: Message-ID: References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Tue, 12 Dec 2006 08:18:33 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Kostik Belousov , freebsd-arch@freebsd.org, David Xu , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 13:21:20 -0000 On Mon, 11 Dec 2006, Daniel Eischen wrote: > On Tue, 12 Dec 2006, Arne H. Juul wrote: > >> On Tue, 12 Dec 2006, David Xu wrote: >>> On Tuesday 12 December 2006 06:34, Arne H. Juul wrote: >>> >>>> This is exactly the sort of issue that should be solved by the >>>> thread library / kernel threads implementation and not in every >>>> threaded application that needs it, in my view. >>>> >>> It should not be done in new thread library, do you want a bloat >>> and error-prone thread library ? Instead if this semantic is really >>> necessary, it should be done in kernel. >> >> Well, it depends on the alternatives. >> If a clean kernel implementation is possible - yes please, of course. >> If only a complex, error-prone kernel implementation is possible, >> I would prefer to have the complexity in the thread library. > > Hacking libthr or libpthread to do this for you is not > an option. They would then look like libc_r since all > fd's accesses would need to be wrapped. If this needs > to be done, it must be in the kernel. It's also couldn't be entirely solved by fixing it in the threads library. You could still have a non-threaded application that waits on a read operation, but receives a signal and closes the socket in the signal handler. -- DE From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 13:59:23 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B42D916A492; Tue, 12 Dec 2006 13:59:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 993A343D36; Tue, 12 Dec 2006 13:56:03 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBCDumHp001088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2006 15:56:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kBCDumka019314; Tue, 12 Dec 2006 15:56:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBCDulHY019313; Tue, 12 Dec 2006 15:56:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Dec 2006 15:56:47 +0200 From: Kostik Belousov To: Daniel Eischen Message-ID: <20061212135647.GK311@deviant.kiev.zoral.com.ua> References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5uO961YFyoDlzFnP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: freebsd-arch@freebsd.org, "Arne H. Juul" , David Xu , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 13:59:24 -0000 --5uO961YFyoDlzFnP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 12, 2006 at 08:18:32AM -0500, Daniel Eischen wrote: > On Mon, 11 Dec 2006, Daniel Eischen wrote: >=20 > >On Tue, 12 Dec 2006, Arne H. Juul wrote: > > > >>On Tue, 12 Dec 2006, David Xu wrote: > >>>On Tuesday 12 December 2006 06:34, Arne H. Juul wrote: > >>> > >>>>This is exactly the sort of issue that should be solved by the > >>>>thread library / kernel threads implementation and not in every > >>>>threaded application that needs it, in my view. > >>>> > >>>It should not be done in new thread library, do you want a bloat > >>>and error-prone thread library ? Instead if this semantic is really > >>>necessary, it should be done in kernel. > >> > >>Well, it depends on the alternatives. > >>If a clean kernel implementation is possible - yes please, of course. > >>If only a complex, error-prone kernel implementation is possible, > >>I would prefer to have the complexity in the thread library. > > > >Hacking libthr or libpthread to do this for you is not > >an option. They would then look like libc_r since all > >fd's accesses would need to be wrapped. If this needs > >to be done, it must be in the kernel. >=20 > It's also couldn't be entirely solved by fixing it in the > threads library. You could still have a non-threaded > application that waits on a read operation, but receives > a signal and closes the socket in the signal handler. This is not the problem. The read (as syscall being executed) is aborted when signal is delivered. Original poster considered situation where read() is active (in particular, f_count of struct file is incremented by fget, that caused the reported behaviour). --5uO961YFyoDlzFnP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFfrUeC3+MBN1Mb4gRAhCXAKCJxzJsY0KFk3GYwKTqTSC2ZLWybQCgjA8M Lfnc6O8F144t8wd826jDuX0= =6wvE -----END PGP SIGNATURE----- --5uO961YFyoDlzFnP-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 14:24:39 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3568F16A4C8; Tue, 12 Dec 2006 14:24:39 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21B7B4403A; Tue, 12 Dec 2006 14:07:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBCE8UAQ020207; Tue, 12 Dec 2006 09:08:30 -0500 (EST) Date: Tue, 12 Dec 2006 09:08:30 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kostik Belousov In-Reply-To: <20061212135647.GK311@deviant.kiev.zoral.com.ua> Message-ID: References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> <20061212135647.GK311@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Tue, 12 Dec 2006 09:08:31 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-arch@freebsd.org, "Arne H. Juul" , David Xu , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 14:24:39 -0000 On Tue, 12 Dec 2006, Kostik Belousov wrote: > On Tue, Dec 12, 2006 at 08:18:32AM -0500, Daniel Eischen wrote: >> It's also couldn't be entirely solved by fixing it in the >> threads library. You could still have a non-threaded >> application that waits on a read operation, but receives >> a signal and closes the socket in the signal handler. > > This is not the problem. The read (as syscall being executed) is aborted > when signal is delivered. Original poster considered situation where > read() is active (in particular, f_count of struct file is incremented > by fget, that caused the reported behaviour). Even when SA_RESTART is set? -- DE From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 14:34:39 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0367216A51C; Tue, 12 Dec 2006 14:34:39 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FB3044407; Tue, 12 Dec 2006 14:17:59 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBCEJ94W000917; Tue, 12 Dec 2006 09:19:09 -0500 (EST) Date: Tue, 12 Dec 2006 09:19:09 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Arne H. Juul" In-Reply-To: Message-ID: References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Tue, 12 Dec 2006 09:19:10 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Kostik Belousov , freebsd-arch@freebsd.org, David Xu , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 14:34:39 -0000 On Mon, 11 Dec 2006, Daniel Eischen wrote: > > Common sense leads me to think that a close() should release > threads in IO operations (reads/writes/selects/polls) and > return EBADF or something appropriate. At least when behavior > is not dictated by POSIX or other historical/defactor behavior. BTW, I tested the behavior on Solaris. Solaris returns EBADF with the posted sample C program. -- DE From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 14:38:19 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5BF316A416; Tue, 12 Dec 2006 14:38:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF0C343DA8; Tue, 12 Dec 2006 14:24:05 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Gu8ZE-000GNm-Uw; Tue, 12 Dec 2006 16:25:21 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBCEOuFg003721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Dec 2006 16:24:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kBCEOutV020035; Tue, 12 Dec 2006 16:24:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBCEOsKu020034; Tue, 12 Dec 2006 16:24:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Dec 2006 16:24:54 +0200 From: Kostik Belousov To: Daniel Eischen Message-ID: <20061212142454.GL311@deviant.kiev.zoral.com.ua> References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> <20061212135647.GK311@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0FRtVia6Q6lt+M0P" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua X-Scanner-Signature: b22dd54e5e410b0526d530b08df0ebb5 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 594 [Dec 12 2006] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-arch@freebsd.org, "Arne H. Juul" , David Xu , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 14:38:19 -0000 --0FRtVia6Q6lt+M0P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 12, 2006 at 09:08:30AM -0500, Daniel Eischen wrote: > On Tue, 12 Dec 2006, Kostik Belousov wrote: >=20 > >On Tue, Dec 12, 2006 at 08:18:32AM -0500, Daniel Eischen wrote: > >>It's also couldn't be entirely solved by fixing it in the > >>threads library. You could still have a non-threaded > >>application that waits on a read operation, but receives > >>a signal and closes the socket in the signal handler. > > > >This is not the problem. The read (as syscall being executed) is aborted > >when signal is delivered. Original poster considered situation where > >read() is active (in particular, f_count of struct file is incremented > >by fget, that caused the reported behaviour). >=20 > Even when SA_RESTART is set? Yes. Since SA_RESTART causes syscall to be reissued, read() would fail with EBADFD on its own. --0FRtVia6Q6lt+M0P Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFfru1C3+MBN1Mb4gRAmT9AJ0bq2u672FpTLNZylM4pQ21mGT4uACg6x5N e6Kn5izt2nTwOeKXkeC4iwQ= =h6zM -----END PGP SIGNATURE----- --0FRtVia6Q6lt+M0P-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 14:48:03 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60E1E16A4D1 for ; Tue, 12 Dec 2006 14:48:03 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5E7344325 for ; Tue, 12 Dec 2006 14:41:40 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id kBCEgkiT062153; Tue, 12 Dec 2006 06:42:46 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id kBCEgknB062152; Tue, 12 Dec 2006 06:42:46 -0800 (PST) (envelope-from rizzo) Date: Tue, 12 Dec 2006 06:42:46 -0800 From: Luigi Rizzo To: arch@freebsd.org Message-ID: <20061212064246.A62035@xorpc.icir.org> References: <200612081036.kB8AakMD029277@repoman.freebsd.org> <20061212131333.GU54209@cicely12.cicely.de> <20061212055756.A61182@xorpc.icir.org> <20061212141759.GZ54209@cicely12.cicely.de> <20061212062445.A61903@xorpc.icir.org> <20061212143113.GA54209@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20061212143113.GA54209@cicely12.cicely.de>; from ticso@cicely12.cicely.de on Tue, Dec 12, 2006 at 03:31:13PM +0100 Cc: Subject: Re: cvs commit: src/sys/net if_ethersubr.c 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, 12 Dec 2006 14:48:03 -0000 [moving to arch] sorry if it has been debated already, but looking in the network code it seems that checks for architectures that need strong alignment are done through a sequence of #if defined(__ia64__) || defined(__blah__) || ... one such sequence is in net/if_loop::if_simloop(), and was related to a problem we are having with some recent commits to net/if_ethersubr.c While the easy fix (for this one) is to add || defined(__arm__) to the sequence, we were wondering if there is some identifier that we can use to the purpose. Bernd Walter was suggesting this: > I would have said ALIGNBYTES != 1, but this also matches with i386. > Guess it's time to introduce somehing like ALIGN_STRONG, or whatever > colour fits best. ideas ? cheers luigi From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 15:00:49 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C31516A4FE for ; Tue, 12 Dec 2006 15:00:49 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep20-int.chello.at (viefep16-int.chello.at [213.46.255.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 396A643CA5 for ; Tue, 12 Dec 2006 14:56:40 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from lizard.fafoe.narf.at ([213.47.85.26]) by viefep20-int.chello.at (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20061212145739.FHOI21913.viefep20-int.chello.at@lizard.fafoe.narf.at>; Tue, 12 Dec 2006 15:57:39 +0100 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id 0FEACBB80; Tue, 12 Dec 2006 15:57:39 +0100 (CET) Date: Tue, 12 Dec 2006 15:57:39 +0100 From: Stefan Farfeleder To: Luigi Rizzo Message-ID: <20061212145738.GC915@lizard.fafoe.narf.at> References: <200612081036.kB8AakMD029277@repoman.freebsd.org> <20061212131333.GU54209@cicely12.cicely.de> <20061212055756.A61182@xorpc.icir.org> <20061212141759.GZ54209@cicely12.cicely.de> <20061212062445.A61903@xorpc.icir.org> <20061212143113.GA54209@cicely12.cicely.de> <20061212064246.A62035@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061212064246.A62035@xorpc.icir.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: arch@freebsd.org Subject: Re: cvs commit: src/sys/net if_ethersubr.c 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, 12 Dec 2006 15:00:49 -0000 On Tue, Dec 12, 2006 at 06:42:46AM -0800, Luigi Rizzo wrote: > [moving to arch] > > sorry if it has been debated already, but looking in the > network code it seems that checks for architectures that > need strong alignment are done through a sequence of > > #if defined(__ia64__) || defined(__blah__) || ... > > one such sequence is in net/if_loop::if_simloop(), and was > related to a problem we are having with some recent > commits to net/if_ethersubr.c > > While the easy fix (for this one) is to add > || defined(__arm__) > to the sequence, we were wondering if there is some identifier > that we can use to the purpose. > > Bernd Walter was suggesting this: > > > I would have said ALIGNBYTES != 1, but this also matches with i386. > > Guess it's time to introduce somehing like ALIGN_STRONG, or whatever > > colour fits best. > > ideas ? Architectures without strong alignment define __NO_STRICT_ALIGNMENT in . Stefan From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 20:22:01 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC89716A64E for ; Tue, 12 Dec 2006 20:22:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 326B344383 for ; Tue, 12 Dec 2006 20:07:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBCK8rBA021195; Tue, 12 Dec 2006 15:08:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: John Polstra Date: Tue, 12 Dec 2006 15:09:03 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612121509.03785.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 12 Dec 2006 15:08:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2318/Tue Dec 12 11:58:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 12 Dec 2006 20:22:02 -0000 On Monday 11 December 2006 18:23, John Polstra wrote: > On 11-Dec-2006 John Baldwin wrote: > > Hmm. I did blacklist stuff several weeks ago but haven't had time to > > test it or post it yet. :( > > Oops. :-} Hardly your fault though. :) > > I do think I like your approach a bit better though. What I had so > > far is here: > > > > http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch > > > > I'm not sure if it's worth blacklisting MSI separate from MSI-X as that > > only makes a difference at the device level (chipsets just get a single > > memory write per interrupt either way, they can't tell MSI from MSI-X). > > Since the MSI support is really your turf, I'll happily defer to > you on it. If you decide my patch should go in, I could add the > additional blacklisted bridges from your patch, add the tunable > to ignore the blacklist, and eliminate the distinction between > blacklisting MSI and MSI-X. Let me know whether I should go ahead > and commit that. Well, I've tried to update my tree to be similar to your patch. One thing I did keep is that I want the blacklisting of PCI-PCI bridges to be something that happens while the request is bubbling up rather than just do a check on the immediate parent as in your patch. I want to make sure the entire heirarchy beneath a known busted bridge is blacklisted, not just the immediate children. I've gone ahead and committed some of the framework (such as giving the host drivers their own alloc methods) but I've changed the global blacklist to be MI as in your patch. Rather than creating a separate quirk table for MSI, I just added a new quirk type to the pci_quirks[] table and added the quirks there. Updated patch (relative to the stuff I just committed) is at the same location: http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch Can you review and possibly test it? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 20:49:56 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13F9716A407; Tue, 12 Dec 2006 20:49:56 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E45443CF9; Tue, 12 Dec 2006 20:48:26 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBCKnmnT006945; Tue, 12 Dec 2006 15:49:48 -0500 (EST) Date: Tue, 12 Dec 2006 15:49:48 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Poul-Henning Kamp In-Reply-To: <32874.1165905843@critter.freebsd.dk> Message-ID: References: <32874.1165905843@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Tue, 12 Dec 2006 15:49:50 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: "Arne H. Juul" , David Xu , freebsd-arch@freebsd.org, Kostik Belousov , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 20:49:56 -0000 On Tue, 12 Dec 2006, Poul-Henning Kamp wrote: > In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes: >> On Mon, 11 Dec 2006, Daniel Eischen wrote: > >> It's probably a nightmare in the kernel too. close() starts looking >> like revoke(), and revoke() has large problems and bugs in this area. > > There is the distinctive difference that revoke() operates on a name > and close() on a filedescriptor, but otherwise I agree. Well, if threads waiting on IO are interruptable by signals, can't we make a new signal that's only used by the kernel and send it to all threads waiting on IO for that descriptor? When it gets out to actually setup the signal handler, it just resumes like it is returning from an SA_RESTART signal handler (which according to another posting would reissue the IO command and get EBADF). -- Dan From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 23:30:13 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 73A0D16A51E; Tue, 12 Dec 2006 23:30:13 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: Daniel Eischen Date: Wed, 13 Dec 2006 07:30:10 +0800 User-Agent: KMail/1.8.2 References: <32874.1165905843@critter.freebsd.dk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612130730.10973.davidxu@freebsd.org> Cc: "Arne H. Juul" , Poul-Henning Kamp , freebsd-arch@freebsd.org, Kostik Belousov , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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, 12 Dec 2006 23:30:13 -0000 On Wednesday 13 December 2006 04:49, Daniel Eischen wrote: > On Tue, 12 Dec 2006, Poul-Henning Kamp wrote: > > In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes: > >> On Mon, 11 Dec 2006, Daniel Eischen wrote: > >> > >> It's probably a nightmare in the kernel too. close() starts looking > >> like revoke(), and revoke() has large problems and bugs in this area. > > > > There is the distinctive difference that revoke() operates on a name > > and close() on a filedescriptor, but otherwise I agree. > > Well, if threads waiting on IO are interruptable by signals, > can't we make a new signal that's only used by the kernel > and send it to all threads waiting on IO for that descriptor? > When it gets out to actually setup the signal handler, it > just resumes like it is returning from an SA_RESTART signal > handler (which according to another posting would reissue > the IO command and get EBADF). Stop using signal, it is slow for threaded process, first you don't know which threads are using the descriptor, second, you have to run long code path in kernel signal code to find and deliver the signals to all interested threads, that is too expensive for benchmark like apache benchmark. David Xu From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 03:28:52 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9197C16A403; Wed, 13 Dec 2006 03:28:52 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67BE443CA7; Wed, 13 Dec 2006 03:27:25 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 11ABE5A3F5C; Wed, 13 Dec 2006 14:28:17 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 817638C0C; Wed, 13 Dec 2006 14:28:15 +1100 (EST) Date: Wed, 13 Dec 2006 14:28:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Xu In-Reply-To: <200612130730.10973.davidxu@freebsd.org> Message-ID: <20061213141257.J2006@besplex.bde.org> References: <32874.1165905843@critter.freebsd.dk> <200612130730.10973.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Arne H. Juul" , Daniel Eischen , Poul-Henning Kamp , freebsd-arch@freebsd.org, Kostik Belousov , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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: Wed, 13 Dec 2006 03:28:52 -0000 On Wed, 13 Dec 2006, David Xu wrote: > On Wednesday 13 December 2006 04:49, Daniel Eischen wrote: >> On Tue, 12 Dec 2006, Poul-Henning Kamp wrote: >>> In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes: >>>> On Mon, 11 Dec 2006, Daniel Eischen wrote: >>>> >>>> It's probably a nightmare in the kernel too. close() starts looking >>>> like revoke(), and revoke() has large problems and bugs in this area. >>> >>> There is the distinctive difference that revoke() operates on a name >>> and close() on a filedescriptor, but otherwise I agree. >> >> Well, if threads waiting on IO are interruptable by signals, >> can't we make a new signal that's only used by the kernel >> and send it to all threads waiting on IO for that descriptor? >> When it gets out to actually setup the signal handler, it >> just resumes like it is returning from an SA_RESTART signal >> handler (which according to another posting would reissue >> the IO command and get EBADF). > > Stop using signal, it is slow for threaded process, first you don't > know which threads are using the descriptor, second, you have > to run long code path in kernel signal code to find and deliver > the signals to all interested threads, that is too expensive for > benchmark like apache benchmark. A signal would be fast enough for revoke() since revoke() is not used much, and would work well if the signal could be sent, and is unmaskable, and all device drivers catch signals (oops, all of them act like applications whose signal catching function just sets a flag, except while they sleep, so they have the usual problems with just setting a flag -- they may run for too long before actually using the setting). However, I think there is no way to determine which threads are using an fd short of doing the equivalent of fstat(1) searching throuhj kmem. Kernel data structures just aren't set up to do this search efficiently, and shouldn't be bloated to do it. For close() on non-devices, there is the additional problem of infinite disk waits due to things like nfs servers down and bugs. Then signals don't work and you wouldn't like close() by a thread trying to clean up the problem to hang too. Otherwise close()/revoke() would be a good way to cancel an infinite disk wait. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 07:12:26 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A787516A415 for ; Wed, 13 Dec 2006 07:12:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 320EA43CCD for ; Wed, 13 Dec 2006 07:10:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 12 Dec 2006 22:57:09 -0800 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBD7C23r098829; Tue, 12 Dec 2006 23:12:03 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <457FA7C0.408@elischer.org> Date: Tue, 12 Dec 2006 23:12:00 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Bruce Evans References: <32874.1165905843@critter.freebsd.dk> <200612130730.10973.davidxu@freebsd.org> <20061213141257.J2006@besplex.bde.org> In-Reply-To: <20061213141257.J2006@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Arne H. Juul" , Daniel Eischen , Poul-Henning Kamp , David Xu , freebsd-arch@freebsd.org, Kostik Belousov , freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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: Wed, 13 Dec 2006 07:12:26 -0000 Bruce Evans wrote: > On Wed, 13 Dec 2006, David Xu wrote: > >> On Wednesday 13 December 2006 04:49, Daniel Eischen wrote: >>> On Tue, 12 Dec 2006, Poul-Henning Kamp wrote: >>>> In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes: >>>>> On Mon, 11 Dec 2006, Daniel Eischen wrote: >>>>> >>>>> It's probably a nightmare in the kernel too. close() starts looking >>>>> like revoke(), and revoke() has large problems and bugs in this area. >>>> >>>> There is the distinctive difference that revoke() operates on a name >>>> and close() on a filedescriptor, but otherwise I agree. >>> >>> Well, if threads waiting on IO are interruptable by signals, >>> can't we make a new signal that's only used by the kernel >>> and send it to all threads waiting on IO for that descriptor? >>> When it gets out to actually setup the signal handler, it >>> just resumes like it is returning from an SA_RESTART signal >>> handler (which according to another posting would reissue >>> the IO command and get EBADF). >> >> Stop using signal, it is slow for threaded process, first you don't >> know which threads are using the descriptor, second, you have >> to run long code path in kernel signal code to find and deliver >> the signals to all interested threads, that is too expensive for >> benchmark like apache benchmark. > > A signal would be fast enough for revoke() since revoke() is not used > much, and would work well if the signal could be sent, and is unmaskable, > and all device drivers catch signals (oops, all of them act like > applications whose signal catching function just sets a flag, except > while they sleep, so they have the usual problems with just setting a > flag -- they may run for too long before actually using the setting). > However, I think there is no way to determine which threads are using > an fd short of doing the equivalent of fstat(1) searching throuhj kmem. > Kernel data structures just aren't set up to do this search efficiently, > and shouldn't be bloated to do it. that's processes.. which thread in the process is the one that is currently waiting on the socket? > > For close() on non-devices, there is the additional problem of infinite > disk waits due to things like nfs servers down and bugs. Then signals > don't work and you wouldn't like close() by a thread trying to clean > up the problem to hang too. Otherwise close()/revoke() would be a good > way to cancel an infinite disk wait. > > Bruce > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 08:06:12 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8C8C16A403 for ; Wed, 13 Dec 2006 08:06:12 +0000 (UTC) (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 C6AC443CEC for ; Wed, 13 Dec 2006 08:04:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kBD83a9w024370; Wed, 13 Dec 2006 01:03:37 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 13 Dec 2006 01:04:34 -0700 (MST) Message-Id: <20061213.010434.1791047804.imp@bsdimp.com> To: stefan@fafoe.narf.at From: "M. Warner Losh" In-Reply-To: <20061212145738.GC915@lizard.fafoe.narf.at> References: <20061212143113.GA54209@cicely12.cicely.de> <20061212064246.A62035@xorpc.icir.org> <20061212145738.GC915@lizard.fafoe.narf.at> X-Mailer: Mew version 4.2 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]); Wed, 13 Dec 2006 01:03:37 -0700 (MST) Cc: arch@freebsd.org Subject: Re: cvs commit: src/sys/net if_ethersubr.c 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: Wed, 13 Dec 2006 08:06:13 -0000 In message: <20061212145738.GC915@lizard.fafoe.narf.at> Stefan Farfeleder writes: : On Tue, Dec 12, 2006 at 06:42:46AM -0800, Luigi Rizzo wrote: : > [moving to arch] : > : > sorry if it has been debated already, but looking in the : > network code it seems that checks for architectures that : > need strong alignment are done through a sequence of : > : > #if defined(__ia64__) || defined(__blah__) || ... : > : > one such sequence is in net/if_loop::if_simloop(), and was : > related to a problem we are having with some recent : > commits to net/if_ethersubr.c : > : > While the easy fix (for this one) is to add : > || defined(__arm__) : > to the sequence, we were wondering if there is some identifier : > that we can use to the purpose. : > : > Bernd Walter was suggesting this: : > : > > I would have said ALIGNBYTES != 1, but this also matches with i386. : > > Guess it's time to introduce somehing like ALIGN_STRONG, or whatever : > > colour fits best. : > : > ideas ? : : Architectures without strong alignment define __NO_STRICT_ALIGNMENT in : . This has been talked about at length in the past. Nobody has followed through on the implementation. param.h was the preferred location for these things. This patch fixes the problem at hand and moves things to their proper location. http://perforce.freebsd.org/chv.cgi?CH=111579 Change 111579 by imp@imp_lighthouse on 2006/12/12 22:08:26 Move __NO_STRICT_ALIGNMENT and use it. Affected files ... .. //depot/projects/arm/src/sys/amd64/include/_types.h#7 edit .. //depot/projects/arm/src/sys/amd64/include/param.h#5 edit .. //depot/projects/arm/src/sys/i386/include/_types.h#7 edit .. //depot/projects/arm/src/sys/i386/include/param.h#4 edit .. //depot/projects/arm/src/sys/net/bpf_filter.c#5 edit .. //depot/projects/arm/src/sys/net/if_loop.c#8 edit Differences ... ==== //depot/projects/arm/src/sys/amd64/include/_types.h#7 (text+ko) ==== @@ -43,8 +43,6 @@ #error this file needs sys/cdefs.h as a prerequisite #endif -#define __NO_STRICT_ALIGNMENT - /* * Basic types upon which most other types are built. */ ==== //depot/projects/arm/src/sys/amd64/include/param.h#5 (text+ko) ==== @@ -66,6 +66,7 @@ #ifndef _NO_NAMESPACE_POLLUTION +#define __NO_STRICT_ALIGNMENT #define __HAVE_ACPI #define __PCI_REROUTE_INTERRUPT ==== //depot/projects/arm/src/sys/i386/include/_types.h#7 (text+ko) ==== @@ -43,8 +43,6 @@ #error this file needs sys/cdefs.h as a prerequisite #endif -#define __NO_STRICT_ALIGNMENT - /* * Basic types upon which most other types are built. */ ==== //depot/projects/arm/src/sys/i386/include/param.h#4 (text+ko) ==== @@ -51,6 +51,7 @@ #ifndef _NO_NAMESPACE_POLLUTION +#define __NO_STRICT_ALIGNMENT #define __HAVE_ACPI #define __PCI_REROUTE_INTERRUPT ==== //depot/projects/arm/src/sys/net/bpf_filter.c#5 (text+ko) ==== @@ -38,11 +38,7 @@ #include -#ifdef sun -#include -#endif - -#ifndef __i386__ +#ifndef __NO_STRICT_ALIGNMENT #define BPF_ALIGN #endif ==== //depot/projects/arm/src/sys/net/if_loop.c#8 (text+ko) ==== @@ -290,7 +290,7 @@ /* Strip away media header */ if (hlen > 0) { m_adj(m, hlen); -#if defined(__ia64__) || defined(__sparc64__) +#ifndef __NO_STRICT_ALIGNMENT /* * Some archs do not like unaligned data, so * we move data down in the first mbuf. From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 11:28:29 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0047E16A508; Wed, 13 Dec 2006 11:28:28 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A552743CF7; Wed, 13 Dec 2006 11:26:38 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 3B070111229; Wed, 13 Dec 2006 22:28:04 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id C9A3E8C0B; Wed, 13 Dec 2006 22:28:03 +1100 (EST) Date: Wed, 13 Dec 2006 22:28:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Julian Elischer In-Reply-To: <457FA7C0.408@elischer.org> Message-ID: <20061213220952.H792@besplex.bde.org> References: <32874.1165905843@critter.freebsd.dk> <200612130730.10973.davidxu@freebsd.org> <20061213141257.J2006@besplex.bde.org> <457FA7C0.408@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Arne H. Juul" , Daniel Eischen , Poul-Henning Kamp , David Xu , freebsd-arch@FreeBSD.org, Kostik Belousov , freebsd-java@FreeBSD.org Subject: Re: close() of active socket does not work on FreeBSD 6 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: Wed, 13 Dec 2006 11:28:29 -0000 On Tue, 12 Dec 2006, Julian Elischer wrote: > Bruce Evans wrote: >> A signal would be fast enough for revoke() since revoke() is not used >> much, and would work well if the signal could be sent, and is unmaskable, >> and all device drivers catch signals (oops, all of them act like >> ... >> However, I think there is no way to determine which threads are using >> an fd short of doing the equivalent of fstat(1) searching throuhj kmem. >> Kernel data structures just aren't set up to do this search efficiently, >> and shouldn't be bloated to do it. > > that's processes.. which thread in the process is the one that is currently > waiting on the socket? Do you mean that this wouldn't work the signal would need to be per-thread but signals are per-process? Aren't there per-thread signals now? It's not just one thread, at least for general files. There can be any number. I just remembered that SIGIO delivery has problems near here. There is some i/o on a device, and the kernel has to figure out all open fd's on the device with O_ASYNC set on the open file of the fd. It has difficulty doing this, even with some data structures pointing from the device back to the processes. In theory there can be any number of fd's with the same open file and the signal should be broadcast to the processes owning these fd's). This is still simpler than signaling threads in i/o functions since the signal is broadcast. I said that something like fstat(1) groping in kmem is needed to find all the relevant threads. That is nowhere near enough -- fstat cannot tell which threads are currently in i/o functions. Something closer to what debuggers do is needed -- stop all threads and stack trace them all to see where they are :-). Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 12:10:54 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B4BE516A416; Wed, 13 Dec 2006 12:10:53 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-java@freebsd.org, Daniel Eischen Date: Wed, 13 Dec 2006 20:10:49 +0800 User-Agent: KMail/1.8.2 References: <32874.1165905843@critter.freebsd.dk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612132010.49601.davidxu@freebsd.org> Cc: Kostik Belousov , Poul-Henning Kamp , "Arne H. Juul" , freebsd-arch@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 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: Wed, 13 Dec 2006 12:10:54 -0000 On Wednesday 13 December 2006 04:49, Daniel Eischen wrote: > On Tue, 12 Dec 2006, Poul-Henning Kamp wrote: > > In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes: > >> On Mon, 11 Dec 2006, Daniel Eischen wrote: > >> > >> It's probably a nightmare in the kernel too. close() starts looking > >> like revoke(), and revoke() has large problems and bugs in this area. > > > > There is the distinctive difference that revoke() operates on a name > > and close() on a filedescriptor, but otherwise I agree. > > Well, if threads waiting on IO are interruptable by signals, > can't we make a new signal that's only used by the kernel > and send it to all threads waiting on IO for that descriptor? > When it gets out to actually setup the signal handler, it > just resumes like it is returning from an SA_RESTART signal > handler (which according to another posting would reissue > the IO command and get EBADF). Even if you have implemented the close() with the interruption, another thread openning a file still can reuse the file handle immediately, according to specifications, the lowest free file handle will be returned, if SA_RESTART is used, the interrupted thread restart the syscall, it will be using a wrong file, I think even if we have implemented the feature in kernel, useland threads still has serious race to fix. David Xu From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 14:23:25 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C44716A403; Wed, 13 Dec 2006 14:23:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6336843CA4; Wed, 13 Dec 2006 14:21:55 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBDENNe8029216; Wed, 13 Dec 2006 09:23:23 -0500 (EST) Date: Wed, 13 Dec 2006 09:23:23 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200612132010.49601.davidxu@freebsd.org> Message-ID: References: <32874.1165905843@critter.freebsd.dk> <200612132010.49601.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Wed, 13 Dec 2006 09:23:23 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-arch@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 14:23:25 -0000 [CC trimmed] On Wed, 13 Dec 2006, David Xu wrote: > On Wednesday 13 December 2006 04:49, Daniel Eischen wrote: >> >> Well, if threads waiting on IO are interruptable by signals, >> can't we make a new signal that's only used by the kernel >> and send it to all threads waiting on IO for that descriptor? >> When it gets out to actually setup the signal handler, it >> just resumes like it is returning from an SA_RESTART signal >> handler (which according to another posting would reissue >> the IO command and get EBADF). > > Even if you have implemented the close() with the interruption, another > thread openning a file still can reuse the file handle immediately, > according to specifications, the lowest free file handle will be returned, > if SA_RESTART is used, the interrupted thread restart the syscall, > it will be using a wrong file, I think even if we have implemented the > feature in kernel, useland threads still has serious race to fix. If you use a special signal that is only used for this purpose, there is no reason you have to try the IO operation again. You can just return EBADF. Anyway, this was just a thought/idea. I don't mean to argue against any of the other reasons why this isn't a good idea. -- DE From owner-freebsd-arch@FreeBSD.ORG Wed Dec 13 23:31:36 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B800A16A49E; Wed, 13 Dec 2006 23:31:36 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB3043DA2; Wed, 13 Dec 2006 23:29:21 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id kBDNUpLK005011; Wed, 13 Dec 2006 15:30:52 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200612121509.03785.jhb@freebsd.org> Date: Wed, 13 Dec 2006 15:30:51 -0800 (PST) From: John Polstra To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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: Wed, 13 Dec 2006 23:31:36 -0000 On 12-Dec-2006 John Baldwin wrote: > Updated patch (relative to the stuff I just committed) is at the > same location: > > http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch > > Can you review and possibly test it? I reviewed the patch, and it looks fine except for two minor style mismatches. The definitions of PCI_QUIRK_DISABLE_MSI and PCIB_DISABLE_MSI both have a tab after the #define, but in each case the preceding line used a space after the #define. Hang your head in shame! ;-) I'm updating a system to the latest -current so I can test the patch. I'll report back soon. John From owner-freebsd-arch@FreeBSD.ORG Thu Dec 14 01:04:54 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60A8C16A417 for ; Thu, 14 Dec 2006 01:04:54 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AB4043DAF for ; Thu, 14 Dec 2006 01:01:15 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so118527ana for ; Wed, 13 Dec 2006 17:02:41 -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=GLx6vLJQjDbVmORLzef7KdJ880uT9PFwlMOX/n7t28t+jHVC6nnxr6E9s7YoAEw6OX0OD2NjI4CnZJS5Q03WMI0fOgErrzXmtwN0ZdV9SksMyngT0ykGpkoRBePntFbL30aAMTZCC/Caa85fQ4hB0TWhy/isNtJ1nvwdHEEdC84= Received: by 10.100.173.19 with SMTP id v19mr327643ane.1166058160848; Wed, 13 Dec 2006 17:02:40 -0800 (PST) Received: by 10.100.136.16 with HTTP; Wed, 13 Dec 2006 17:02:40 -0800 (PST) Message-ID: <6eb82e0612131702o178bc054qdebf0b3e69a74534@mail.gmail.com> Date: Thu, 14 Dec 2006 09:02:40 +0800 From: "Rong-en Fan" To: "Pawel Jakub Dawidek" In-Reply-To: <20061101202252.GX15861@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061101190606.GQ15861@garage.freebsd.pl> <20061101192457.GA56970@lor.one-eyed-alien.net> <20061101194618.GT15861@garage.freebsd.pl> <20061101195952.GB56970@lor.one-eyed-alien.net> <20061101202252.GX15861@garage.freebsd.pl> Cc: freebsd-arch@freebsd.org Subject: Re: sysconf(3) extensions. 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, 14 Dec 2006 01:04:54 -0000 On 11/2/06, Pawel Jakub Dawidek wrote: > On Wed, Nov 01, 2006 at 01:59:52PM -0600, Brooks Davis wrote: > > On Wed, Nov 01, 2006 at 08:46:18PM +0100, Pawel Jakub Dawidek wrote: > > > On Wed, Nov 01, 2006 at 01:24:57PM -0600, Brooks Davis wrote: > > > > On Wed, Nov 01, 2006 at 08:06:06PM +0100, Pawel Jakub Dawidek wrote: > > > > > Hi. > > > > > > > > > > I'd like to add two non-standard value to the sysconf(3) functions, > > > > > which can be found in both Solaris and Linux: _SC_PHYS_PAGES and > > > > > _SC_AVPHYS_PAGES. > > > > > > > > > > The patch is here: > > > > > > > > > > http://people.freebsd.org/~pjd/patches/sysconf.patch > > > > > > > > > > Can someone review it? Thanks. > > > > > > > > What are they for? My concern is that _SC_AVPHYS_PAGES isn't going to > > > > semantically match other platforms since in a steady state the free count > > > > is small on FreeBSD, but on other systems it swings quite a bit based on > > > > load. > > > > > > _SC_PHYS_PAGES is used by libzpool (a part of the ZFS file system). > > > _SC_AVPHYS_PAGES I used more for completness. > > > > OK. I'd be somewhat inclined to leave _SC_AVPHYS_PAGES out in that > > case, but I don't feel strongly about it. > > I've no opinion, I can remove it. What's the status of _SC_PHYS_PAGES? I'm porting mbuffer [1], which uses _SC_PHYS_PAGES. Regards, Rong-En Fan [1] http://www.maier-komor.de/mbuffer.html From owner-freebsd-arch@FreeBSD.ORG Thu Dec 14 01:56:24 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF54316A515; Thu, 14 Dec 2006 01:56:24 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74C2143EE8; Thu, 14 Dec 2006 01:47:56 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id kBE1nQSq007493; Wed, 13 Dec 2006 17:49:26 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 13 Dec 2006 17:49:26 -0800 (PST) From: John Polstra To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 14 Dec 2006 01:56:25 -0000 On 13-Dec-2006 John Polstra wrote: > On 12-Dec-2006 John Baldwin wrote: > >> Updated patch (relative to the stuff I just committed) is at the >> same location: >> >> http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch >> >> Can you review and possibly test it? > > I'm updating a system to the latest -current so I can test the > patch. I'll report back soon. Your patch works fine on my Tyan 2721 board with today's -current. I also tried manually setting hw.pci.honor_msi_blacklist=0 in the loader, and it did the right thing. John From owner-freebsd-arch@FreeBSD.ORG Thu Dec 14 11:37:41 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B38A916A415; Thu, 14 Dec 2006 11:37:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02CC043C9D; Thu, 14 Dec 2006 11:36:02 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA17946; Thu, 14 Dec 2006 13:37:35 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4581377E.2090407@icyb.net.ua> Date: Thu, 14 Dec 2006 13:37:34 +0200 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Peter Wemm , freebsd-arch@FreeBSD.org Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: HZ of 1024 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, 14 Dec 2006 11:37:41 -0000 Peter and all, I am playing with an idea of using RTC/IRQ8 instead of 8254 timer/IRQ0 to drive system hard clock. Due to the nature of RTC, if I got it correctly, I think I will have to use HZ of 1024 (or some reasonable divisor of it). I've accidentally noticed that 1024 was used as a default value of hz on amd64 systems for a while, but then it was changed to use 1000. I've read the cvs commit logs about some interference with stat clock and/or prof clock, but I couldn't dig up any detailed information about this. Could you please share your experience about hz=1024 and advise what I should look for ? Maybe you even have some ideas on how to eliminate or reduce the interference ? Thank you. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Dec 14 14:34:16 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6072816A500 for ; Thu, 14 Dec 2006 14:34:16 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD70F43CAF for ; Thu, 14 Dec 2006 14:32:37 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8F55B4880F; Thu, 14 Dec 2006 15:34:10 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5EA534880D; Thu, 14 Dec 2006 15:34:06 +0100 (CET) Date: Thu, 14 Dec 2006 15:33:58 +0100 From: Pawel Jakub Dawidek To: Rong-en Fan Message-ID: <20061214143358.GB1729@garage.freebsd.pl> References: <20061101190606.GQ15861@garage.freebsd.pl> <20061101192457.GA56970@lor.one-eyed-alien.net> <20061101194618.GT15861@garage.freebsd.pl> <20061101195952.GB56970@lor.one-eyed-alien.net> <20061101202252.GX15861@garage.freebsd.pl> <6eb82e0612131702o178bc054qdebf0b3e69a74534@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s/l3CgOIzMHHjg/5" Content-Disposition: inline In-Reply-To: <6eb82e0612131702o178bc054qdebf0b3e69a74534@mail.gmail.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-arch@freebsd.org Subject: Re: sysconf(3) extensions. 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, 14 Dec 2006 14:34:16 -0000 --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2006 at 09:02:40AM +0800, Rong-en Fan wrote: > On 11/2/06, Pawel Jakub Dawidek wrote: > >On Wed, Nov 01, 2006 at 01:59:52PM -0600, Brooks Davis wrote: > >> On Wed, Nov 01, 2006 at 08:46:18PM +0100, Pawel Jakub Dawidek wrote: > >> > On Wed, Nov 01, 2006 at 01:24:57PM -0600, Brooks Davis wrote: > >> > > On Wed, Nov 01, 2006 at 08:06:06PM +0100, Pawel Jakub Dawidek wrot= e: > >> > > > Hi. > >> > > > > >> > > > I'd like to add two non-standard value to the sysconf(3) functio= ns, > >> > > > which can be found in both Solaris and Linux: _SC_PHYS_PAGES and > >> > > > _SC_AVPHYS_PAGES. > >> > > > > >> > > > The patch is here: > >> > > > > >> > > > http://people.freebsd.org/~pjd/patches/sysconf.patch > >> > > > > >> > > > Can someone review it? Thanks. > >> > > > >> > > What are they for? My concern is that _SC_AVPHYS_PAGES isn't goin= g to > >> > > semantically match other platforms since in a steady state the fre= e count > >> > > is small on FreeBSD, but on other systems it swings quite a bit ba= sed on > >> > > load. > >> > > >> > _SC_PHYS_PAGES is used by libzpool (a part of the ZFS file system). > >> > _SC_AVPHYS_PAGES I used more for completness. > >> > >> OK. I'd be somewhat inclined to leave _SC_AVPHYS_PAGES out in that > >> case, but I don't feel strongly about it. > > > >I've no opinion, I can remove it. >=20 > What's the status of _SC_PHYS_PAGES? I'm porting mbuffer [1], which > uses _SC_PHYS_PAGES. I just committed it to HEAD. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --s/l3CgOIzMHHjg/5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgWDWForvXbEpPzQRAolSAJ93dPki0X9Ood/ZKIPRV+QensLXHACg488v 5eMnSkzeKDPSGb5qMMpQcoI= =SAHI -----END PGP SIGNATURE----- --s/l3CgOIzMHHjg/5-- From owner-freebsd-arch@FreeBSD.ORG Thu Dec 14 17:41:29 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6349716A492 for ; Thu, 14 Dec 2006 17:41:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F79743EC5 for ; Thu, 14 Dec 2006 17:27:38 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBEHSsuF039753; Thu, 14 Dec 2006 12:28:55 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: John Polstra Date: Thu, 14 Dec 2006 11:50:23 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612141150.23597.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 14 Dec 2006 12:28:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2332/Thu Dec 14 09:54:27 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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, 14 Dec 2006 17:41:29 -0000 On Wednesday 13 December 2006 18:30, John Polstra wrote: > On 12-Dec-2006 John Baldwin wrote: > > > Updated patch (relative to the stuff I just committed) is at the > > same location: > > > > http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch > > > > Can you review and possibly test it? > > I reviewed the patch, and it looks fine except for two minor > style mismatches. The definitions of PCI_QUIRK_DISABLE_MSI and > PCIB_DISABLE_MSI both have a tab after the #define, but in each case > the preceding line used a space after the #define. Hang your head > in shame! ;-) I can just fix the style bug in the old code then. :) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 04:38:03 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33F7716A49E for ; Fri, 15 Dec 2006 04:38:03 +0000 (UTC) (envelope-from www-data@h823864.serverkompetenz.net) Received: from h823864.serverkompetenz.net (megahost.de [85.214.24.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id A158A43CAA for ; Fri, 15 Dec 2006 04:36:23 +0000 (GMT) (envelope-from www-data@h823864.serverkompetenz.net) Received: by h823864.serverkompetenz.net (Postfix, from userid 33) id 71F0B7BA294; Fri, 15 Dec 2006 05:20:30 +0100 (CET) To: freebsd-arch@freebsd.org From: N.L LOTTERY PROMOTION. MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20061215042030.71F0B7BA294@h823864.serverkompetenz.net> Date: Fri, 15 Dec 2006 05:20:30 +0100 (CET) Subject: OUR CHRISTMAS BONANZA JUST FOR YOU.... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remittancedept@aol.co.uk List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2006 04:38:03 -0000 CONTACT DUE PROCESS UNIT (DPU) YOUR ID WON MICROSOFT / LOTTO NL INTERNATIONAL PROMOTION PROGRAM Date: 15th December, 2006 Ref Nr: ESZ/231-ILGI0431/06 Batch Nr: EOS/15/096/TVFS Serial Nr 472-9768-79 Lucky Nr:8-66-97-22-65-55 Ticket Nr: 20511465463-7655 Dear Email Bearer, CONSOLATION PRIZE WINNING NOTICE!!! Europe/America private international e-games organizers and Co-sponsors, MICROSOFT / LOTTO NL, officially bring to your notice of the final draw result of December -2006 MICROSOFT / LOTTO NL wheel E-game which was conducted at our international corporate office complex in The Netherlands . Most recently this foundation set up the NEW LOTTERY SCHEME to give out prizes based on COMPUTER BALLOT SYSTEM. By doing this the foundation seek to encourage the use of Internet for academic and business pursuits. Itsmajor aim is to promote music, theatre, art and literature projects in the social and political arena with a focus on health, as well as science, research, and higher education. We wish to congratulate and inform you on the selection of your email ticket number which was selected among the 10 lucky consolation prize winners. Your email ID identified with ticket No. 8-66-97-22-65-55 and was selected by our E-games Random Selection System (ERSS) with entries from the 50,000 different email addresses enrolled for the E-game. Your email ID was included among the 50,000 different email addresses submitted by our partner international email provider companies. You have won a consolation cash prize of $1,000 000.00 (One million Dollars Only). The MICROSOFT / LOTTO NL Group have approved a payout of your consolation cash prize which will be remunerated directly to you by the official Payment Agency Board. Our DUE PROCESS UNIT (DPU) will render to you complete assistance and provide additional information and processes for the claims of your consolation prize. For due processing of your winning claim, please contact the International Remittance Department Information Officer Mr. J Dobrowolski who has been assigned to assist you. Contact Person: NAME: Mr. J Dobrowolski E-mail: remittancedept@aol.co.uk Tel:+31-626-164-175 Fax:+31-847-581-688 You are advised to provide him with the following information: Names: Phone/Fax number: Nationality: Ref Number: Batch Number: Ticket Number: All claims are nullified after 14 working days from todayOnce again congratulations from all our staffs on your consolation prize winning, we hope you will partake in our forth coming MICROSOFT / LOTTO NL Email-games. Regards, Mrs.Susane Jones Online Coordinator NB: In accordance with the MICROSOFT / LOTTO NL E-games policy and regulations, this notification is dispatched directly to only the lucky consolation prize Winners. This notification also contains information that is proprietary,privileged or confidential or otherwise legally exempt from disclosure. If you are not the right recipient whose email address attached to the lucky numbers along with the winning informations you are not authorized to read, print, retain, copy or disseminate this notice or any part of it. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 10:15:23 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03F8316A407; Fri, 15 Dec 2006 10:15:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0371143CA0; Fri, 15 Dec 2006 10:13:41 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GvA65-0001oy-5M; Fri, 15 Dec 2006 12:15:21 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 2006 12:15:21 +0200 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Kernel Virtual Machine 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, 15 Dec 2006 10:15:23 -0000 sorry for the cross-posting, but not realy sure where this belongs. Linux just incorporated this, so I was wondering if anything along this lines is being done/concidered for FreeBSD? see: http://aplawrence.com/Linux/kvm_virtualization.html http://osdir.com/Article9554.phtml Cheers, danny PS: I think that the K in kvm is for 'Avi Kivity' From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 12:05:10 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 213FD16A407 for ; Fri, 15 Dec 2006 12:05:10 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a15.dreamhost.com (sd-green-bigip-207.dreamhost.com [208.97.132.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6041B43C9F for ; Fri, 15 Dec 2006 12:03:19 +0000 (GMT) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.203.29.76]) by spunkymail-a15.dreamhost.com (Postfix) with ESMTP id B91537F078; Fri, 15 Dec 2006 04:04:50 -0800 (PST) Date: Fri, 15 Dec 2006 10:04:46 -0200 From: Ricardo Nabinger Sanchez To: Danny Braniss Message-Id: <20061215100446.f606e1a8.rnsanchez@wait4.org> In-Reply-To: References: Organization: SYS_WAIT4 X-Mailer: Sylpheed version 2.3.0beta6 (GTK+ 2.10.6; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Kernel Virtual Machine 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, 15 Dec 2006 12:05:10 -0000 On Fri, 15 Dec 2006 12:15:21 +0200 Danny Braniss wrote: > PS: I think that the K in kvm is for 'Avi Kivity' Isn't it just [K]ernel [V]irtual [M]achine? -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 12:18:49 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8000E16A508 for ; Fri, 15 Dec 2006 12:18:49 +0000 (UTC) (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 8C71E43E5D for ; Fri, 15 Dec 2006 12:13:04 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id D1DE21747B; Fri, 15 Dec 2006 12:14:29 +0000 (UTC) To: Ricardo Nabinger Sanchez From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 15 Dec 2006 10:04:46 -0200." <20061215100446.f606e1a8.rnsanchez@wait4.org> Date: Fri, 15 Dec 2006 12:14:24 +0000 Message-ID: <23064.1166184864@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Danny Braniss , freebsd-arch@freebsd.org Subject: Re: Kernel Virtual Machine 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, 15 Dec 2006 12:18:49 -0000 In message <20061215100446.f606e1a8.rnsanchez@wait4.org>, Ricardo Nabinger Sanc hez writes: >On Fri, 15 Dec 2006 12:15:21 +0200 >Danny Braniss wrote: > >> PS: I think that the K in kvm is for 'Avi Kivity' > >Isn't it just [K]ernel [V]irtual [M]achine? KVM is usually Kernel Virturl Memory -- 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 Fri Dec 15 14:35:29 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C51E16A47C for ; Fri, 15 Dec 2006 14:35:29 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C8B143CB0 for ; Fri, 15 Dec 2006 14:33:42 +0000 (GMT) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GvE9c-0007Ez-GM for freebsd-arch@freebsd.org; Fri, 15 Dec 2006 15:35:16 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Dec 2006 15:35:16 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Dec 2006 15:35:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Fri, 15 Dec 2006 15:35:07 +0100 Lines: 16 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: Sender: news Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Kernel Virtual Machine 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, 15 Dec 2006 14:35:29 -0000 Danny Braniss wrote: > sorry for the cross-posting, but not realy sure where this > belongs. > > Linux just incorporated this, so I was wondering if anything > along this lines is being done/concidered for FreeBSD? > see: > http://aplawrence.com/Linux/kvm_virtualization.html > http://osdir.com/Article9554.phtml Direct port is not possible because of licensing reasons (LGPL). But it would be extremely nice to have at least SOME full virtualization capability in FreeBSD (qemu is too slow) :( All new (from almost two years ago) server class CPUs support hardware virtualization, and it's also present in most new desktop CPUs. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 18:58:41 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26AD716A40F; Fri, 15 Dec 2006 18:58:41 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail9.mail.yandex.net (webmail9.mail.yandex.net [213.180.223.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id E93AB43C9D; Fri, 15 Dec 2006 18:56:04 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail9.yandex.ru) by mail.yandex.ru id ; Fri, 15 Dec 2006 21:57:38 +0300 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Fri, 15 Dec 2006 21:57:37 +0300 (MSK) Date: Fri, 15 Dec 2006 21:57:37 +0300 (MSK) From: "Andrey V. Elsukov" Sender: bu7cher@yandex.ru Message-Id: <4582F021.000015.13046@webmail9.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: bu7cher@yandex.ru To: freebsd-net@freebsd.org X-Source-Ip: 82.211.152.12 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Runtime control for the IPFIREWALL_FORWARD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2006 18:58:41 -0000 Hi, All! I want get the IPFIREWALL_FORWARD feature without a kernel rebuild. And use forwarding with the ipfw kld. It's possible to have this functional in the base system? If yes, then which is preferred way: sysctl or kld? -- WBR, Andrey V. Elsukov From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 20:20:36 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9596516A407 for ; Fri, 15 Dec 2006 20:20:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6901443C9D for ; Fri, 15 Dec 2006 20:18:52 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GvJXl-0003tO-AA; Fri, 15 Dec 2006 22:20:33 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Poul-Henning Kamp" In-reply-to: <23064.1166184864@critter.freebsd.dk> References: <23064.1166184864@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Fri, 15 Dec 2006 12:14:24 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Dec 2006 22:20:33 +0200 From: Danny Braniss Message-ID: Cc: Ricardo Nabinger Sanchez , freebsd-arch@freebsd.org Subject: Re: Kernel Virtual Machine 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, 15 Dec 2006 20:20:36 -0000 > In message <20061215100446.f606e1a8.rnsanchez@wait4.org>, Ricardo Nabinger Sanc > hez writes: > >On Fri, 15 Dec 2006 12:15:21 +0200 > >Danny Braniss wrote: > > > >> PS: I think that the K in kvm is for 'Avi Kivity' > > > >Isn't it just [K]ernel [V]irtual [M]achine? > > KVM is usually Kernel Virturl Memory it can also be Keyboard,VGA,Mouse switch, but I did spell it out in the Subject. My intend was mainly a pun on Linux, where names are sometimes more important that technologies :-). (both developer's surname start with K) but all this is OT, now realy, is something happenig/talked about doing something in this area, or is it still uncharted waters here? danny From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 20:27:23 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84EF416A403 for ; Fri, 15 Dec 2006 20:27:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC74343CB7 for ; Fri, 15 Dec 2006 20:25:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 15 Dec 2006 12:11:59 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBFKNldg098400; Fri, 15 Dec 2006 12:23:48 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <4583044B.4000006@elischer.org> Date: Fri, 15 Dec 2006 12:23:39 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: bu7cher@yandex.ru References: <4582F021.000015.13046@webmail9.yandex.ru> In-Reply-To: <4582F021.000015.13046@webmail9.yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Runtime control for the IPFIREWALL_FORWARD 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, 15 Dec 2006 20:27:23 -0000 Andrey V. Elsukov wrote: > Hi, All! > > I want get the IPFIREWALL_FORWARD feature without a kernel rebuild. > And use forwarding with the ipfw kld. It's possible to have this > functional in the base system? If yes, then which is preferred way: > sysctl or kld? > This introduces quite a bit of extra code into the path of IP packets. Some people are very sensitive about anything that slows down that path. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 15 21:18:12 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86BF416A403 for ; Fri, 15 Dec 2006 21:18:12 +0000 (UTC) (envelope-from lsc@prgmr.com) Received: from luke.xen.prgmr.com (luke.xen.prgmr.com [38.99.2.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9325343CCE for ; Fri, 15 Dec 2006 21:16:28 +0000 (GMT) (envelope-from lsc@prgmr.com) Received: from luke.xen.prgmr.com (localhost [IPv6:::1]) by luke.xen.prgmr.com (8.13.3/8.13.3) with ESMTP id kBFLHn3Z016651; Fri, 15 Dec 2006 13:17:49 -0800 (PST) Received: from localhost (lsc@localhost) by luke.xen.prgmr.com (8.13.3/8.13.3) with ESMTP id kBFLHmQd020399; Fri, 15 Dec 2006 13:17:49 -0800 (PST) X-Authentication-Warning: luke.xen.prgmr.com: lsc owned process doing -bs Date: Fri, 15 Dec 2006 13:17:48 -0800 (PST) From: Luke Crawford X-X-Sender: lsc@luke.xen.prgmr.com To: Danny Braniss In-Reply-To: Message-ID: References: <23064.1166184864@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Poul-Henning Kamp , Ricardo Nabinger Sanchez , freebsd-arch@freebsd.org Subject: Re: Kernel Virtual Machine 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, 15 Dec 2006 21:18:12 -0000 On Fri, 15 Dec 2006, Danny Braniss wrote: > but all this is OT, now realy, is something happenig/talked about doing > something in this area, or is it still uncharted waters here? Kip Macy has done good work on the Xen port for FreeBSD, and Xen does mostly the same things as this 'kvm'. (I am not saavy to the licensing issues, but NetBSD has Xen support, and the XenSource people seem both reasonable and accessible, so it seems like any licensing issues could be resolved.) http://perforce.freebsd.org/changeList.cgi?CMD=changes&FSPC=//depot/projects/xen3/... I've got it compiling unprivlidged (XenU) kernels with a -current from a couple months back, and it works with a Xen 3.0.2 Xen host running linux just fine. (from what I understand, the Xen0 stuff doesn't work yet) I have XenUs running right now from this; I don't think I would call them 'production' yet, but they mostly work. there were some changes between 3.0.2 and 3.0.3 that broke it, though. I'm going to bang on it this weekend, but it's likely that I'm not good enough to figure out that problem by myself. I do have good test systems and access to all the relevant code, and I'm happy to do the 'bang on it until it compiles' type work, if someone smarter wants to help with the 3.0.2-3.0.3 issues. From owner-freebsd-arch@FreeBSD.ORG Sat Dec 16 09:41:04 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 073BF16A412; Sat, 16 Dec 2006 09:41:04 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from pantene.mail.yandex.net (pantene.mail.yandex.net [213.180.223.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92DE643CA0; Sat, 16 Dec 2006 09:41:03 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (pantene.yandex.ru) by mail.yandex.ru id ; Sat, 16 Dec 2006 12:40:44 +0300 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Sat, 16 Dec 2006 12:40:44 +0300 (MSK) Date: Sat, 16 Dec 2006 12:40:44 +0300 (MSK) From: "Andrey V. Elsukov" Sender: bu7cher@yandex.ru Message-Id: <4583BF1C.000006.25221@pantene.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: bu7cher@yandex.ru To: julian@elischer.org In-Reply-To: <4583044B.4000006@elischer.org> References: <4582F021.000015.13046@webmail9.yandex.ru> <4583044B.4000006@elischer.org> X-Source-Ip: 82.211.152.12 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, bu7cher@yandex.ru, freebsd-arch@freebsd.org Subject: Re: Runtime control for the IPFIREWALL_FORWARD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 09:41:04 -0000 >Andrey V. Elsukov wrote: >This introduces quite a bit of extra code into the path of IP packets. Yes, it will add a few extra checks like a "if (pfil_forward_enabled) {...}" >Some people are very sensitive about anything that slows down that path. I can introduce a new kernel option - NO_PFIL_FORWARD, which will remove an extra code from the CUSTOM kernel. But the GENERIC kernel will be more universal with a new feature. -- WBR, Andrey V. Elsukov