From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 22 00:41:00 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6185B106566B; Sun, 22 Nov 2009 00:41:00 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id BC4068FC13; Sun, 22 Nov 2009 00:40:59 +0000 (UTC) Received: by bwz5 with SMTP id 5so4539717bwz.3 for ; Sat, 21 Nov 2009 16:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=fXE3U0k+n3jUaCtdEY3giENaspkeXiFGok+wSigKY1w=; b=sfi+qx/XwLTS51Ag2aO0vkZ7qDmS/pvzRaH1DbDt9e2fCF2Gs3AL9mSXU61SOusdZ8 6IpQnPNRizR77ySbYvQyLjVu8Bm/k4f6z1GgcVPC/liuHqLlxgIAXHqKlm1J/V8A7+XL 9VBhFHNbUeyH3ZHpojhNWwxHOzlMvwWKUse+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YUaOaNG+nXh7htRw9kh46xwHXcan3JguQVyT7v+bRWriaiLoovCyx3Zmvpz1A58z0H y1gJWiu2QxjfV8HbZgRMqOl0WLG7sztPe6FDBSyEpTaZoZSXfFql5vCdRIhKjRAlg5QK CSA3dhRaaZate3sJSfih3zt8mYhV3Om1KK8N4= Received: by 10.204.10.6 with SMTP id n6mr2939641bkn.27.1258848868351; Sat, 21 Nov 2009 16:14:28 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id d13sm3550212fka.17.2009.11.21.16.14.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Nov 2009 16:14:27 -0800 (PST) Date: Sun, 22 Nov 2009 02:14:22 +0200 From: Gleb Kurtsou To: Ivan Voras Message-ID: <20091122001422.GA17971@tops.skynet.lt> References: <9bbcef730911211240n342d412dg21af8c76b4e1b429@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9bbcef730911211240n342d412dg21af8c76b4e1b429@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org Subject: Re: PUFFS SoC project? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 00:41:00 -0000 On (21/11/2009 21:40), Ivan Voras wrote: > What is the status of this year's SoC projects? Specifically, does > anyone know what happened to PUFFS? > (http://wiki.freebsd.org/SOC2009TatsianaSeveryna) ? As far as I know it is in a pretty good shape. Tatsiana is busy with real job, and has "passed" maintainership to me. ntfs-3g, puffs-ssh and some other filesystems work, but are largely untested, some fuse filesystems are broken as their support of inode numbers is to weak (take a look at fuse-sshfs). There are some issues regarding cache. Original NetBSD puffs code tends to mmap data to cache it in vm, puffs port doesn't. Besides mmaped pages can go out of sync. If you are interested in working on it, do not hesitate contacting me, I'm interested in finishing the port. Thanks, Gleb. From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 22 22:11:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45FAA1065670 for ; Sun, 22 Nov 2009 22:11:37 +0000 (UTC) (envelope-from obrien654j@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id F21968FC13 for ; Sun, 22 Nov 2009 22:11:35 +0000 (UTC) Received: by qyk6 with SMTP id 6so2404105qyk.3 for ; Sun, 22 Nov 2009 14:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=LgBjpp8D/5P/Tv5hyBOLdPtbSA9Ihk52xaYt/Le03Bo=; b=SVd54YpX3D9ojQ/yw91MWjQVSFrhhl/dGI1/OxD50HMDvzpoUWFNegjyP/Cfsp6dnW mmqkEHdVWBi0nk0tPEUCLJsjsS2BKhfSNQKfjWY4Ugmfwm6rD1Nqrv2nRqisdXV1kx0s AhtSsRmPH/YrRNA0GYfWFMim1COwpdp3NSAYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=UQ7T0cy6Z8P3tbUP46HhRdtafSTnlkG3awP/RHi5BnHkDo4MAJwDlmLGbA7utZ5wYy 7EeRjyt/H5tGDWPuF9BnQIVAN+UqR5hkD+uYZizLRXaMhcE+2QYBc8xTliS7P4iqGKF8 2CS+l83tFjWPxBsnoZ+azM5cEvp3nqdZObBqo= Received: by 10.224.57.72 with SMTP id b8mr2070147qah.222.1258926496959; Sun, 22 Nov 2009 13:48:16 -0800 (PST) Received: from minifree.wright.edu ([130.108.237.5]) by mx.google.com with ESMTPS id 7sm10264660qwf.24.2009.11.22.13.48.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Nov 2009 13:48:16 -0800 (PST) Date: Sun, 22 Nov 2009 16:48:46 -0500 From: Jeremy O'Brien To: freebsd-hackers@freebsd.org Message-ID: <20091122214846.GA24357@minifree.wright.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Cisco Aironet MPI350 Fix X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 22:11:37 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31, and on a fresh install of FreeBSD 8.0-RC3, the card did not work. Also, it caused my system to freeze up for a few seconds about once a minute as the driver spit out "an0: device timeout" messages so long as the interface was up. I researched the issue, and found the following fix already in dragonflybsd's tree: http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db883ae3eb5e4ebf2ece9 I modified the patch and applied it to FreeBSD's kernel (trivial), and am happy to report that my card is now working flawlessly. Could someone possibly review this patch and integrate it into the source tree so that others may benefit from it as well? The patch is based off of 8.0-RC3's code, but applies to the latest code as well without modification. Thank you, Jeremy O'Brien --IS0zKkzwUGydFO0o Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mpi350_fix.diff" diff --git a/sys/dev/an/if_an.c b/sys/dev/an/if_an.c index 5b4f13b..f08138d 100644 --- a/sys/dev/an/if_an.c +++ b/sys/dev/an/if_an.c @@ -2747,7 +2747,7 @@ an_start(struct ifnet *ifp) struct mbuf *m0 = NULL; struct an_txframe_802_3 tx_frame_802_3; struct ether_header *eh; - int id, idx, i; + int id, idx, i, ready; unsigned char txcontrol; struct an_card_tx_desc an_tx_desc; u_int8_t *buf; @@ -2774,6 +2774,7 @@ an_start(struct ifnet *ifp) return; } + ready = 0; idx = sc->an_rdata.an_tx_prod; AN_LOCK(sc); @@ -2781,6 +2782,7 @@ an_start(struct ifnet *ifp) bzero((char *)&tx_frame_802_3, sizeof(tx_frame_802_3)); while (sc->an_rdata.an_tx_ring[idx] == 0) { + ready = 1; IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); if (m0 == NULL) break; @@ -2803,7 +2805,7 @@ an_start(struct ifnet *ifp) tx_frame_802_3.an_tx_802_3_payload_len, (caddr_t)&sc->an_txbuf); - txcontrol = AN_TXCTL_8023; + txcontrol = AN_TXCTL_8023 | AN_TXCTL_HW(sc->mpi350); /* write the txcontrol only */ an_write_data(sc, id, 0x08, (caddr_t)&txcontrol, sizeof(txcontrol)); @@ -2842,6 +2844,7 @@ an_start(struct ifnet *ifp) while (sc->an_rdata.an_tx_empty || idx != sc->an_rdata.an_tx_cons) { + ready = 1; IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); if (m0 == NULL) { break; @@ -2866,7 +2869,7 @@ an_start(struct ifnet *ifp) tx_frame_802_3.an_tx_802_3_payload_len, (caddr_t)&sc->an_txbuf); - txcontrol = AN_TXCTL_8023; + txcontrol = AN_TXCTL_8023 | AN_TXCTL_HW(sc->mpi350); /* write the txcontrol only */ bcopy((caddr_t)&txcontrol, &buf[0x08], sizeof(txcontrol)); @@ -2888,7 +2891,7 @@ an_start(struct ifnet *ifp) tx_frame_802_3.an_tx_802_3_payload_len; an_tx_desc.an_phys = sc->an_tx_buffer[idx].an_dma_paddr; - for (i = 0; i < sizeof(an_tx_desc) / 4 ; i++) { + for (i = sizeof(an_tx_desc) / 4 - 1; i >= 0; --i) { CSR_MEM_AUX_WRITE_4(sc, AN_TX_DESC_OFFSET /* zero for now */ + (0 * sizeof(an_tx_desc)) @@ -2919,7 +2922,7 @@ an_start(struct ifnet *ifp) } AN_UNLOCK(sc); - if (m0 != NULL) + if (!ready) ifp->if_drv_flags |= IFF_DRV_OACTIVE; sc->an_rdata.an_tx_prod = idx; diff --git a/sys/dev/an/if_anreg.h b/sys/dev/an/if_anreg.h index 103572a..8f3d30a 100644 --- a/sys/dev/an/if_anreg.h +++ b/sys/dev/an/if_anreg.h @@ -394,13 +394,16 @@ struct an_txframe_802_3 { #define AN_PAYLOADTYPE_ETHER 0x0000 #define AN_PAYLOADTYPE_LLC 0x0010 -#define AN_TXCTL_80211 \ - (AN_TXCTL_TXOK_INTR|AN_TXCTL_TXERR_INTR|AN_HEADERTYPE_80211| \ - AN_PAYLOADTYPE_LLC|AN_TXCTL_NORELEASE) +#define AN_TXCTL_80211 (AN_HEADERTYPE_80211|AN_PAYLOADTYPE_LLC) -#define AN_TXCTL_8023 \ - (AN_TXCTL_TXOK_INTR|AN_TXCTL_TXERR_INTR|AN_HEADERTYPE_8023| \ - AN_PAYLOADTYPE_ETHER|AN_TXCTL_NORELEASE) +#define AN_TXCTL_8023 (AN_HEADERTYPE_8023|AN_PAYLOADTYPE_ETHER) + +/* + * Additions to transmit control bits for MPI350 + */ + +#define AN_TXCTL_HW(x) ( x ? (AN_TXCTL_NORELEASE) : \ + (AN_TXCTL_TXOK_INTR|AN_TXCTL_TXERR_INTR|AN_TXCTL_NORELEASE)) #define AN_TXGAP_80211 0 #define AN_TXGAP_8023 0 --IS0zKkzwUGydFO0o-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 23 04:17:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F33881065694 for ; Mon, 23 Nov 2009 04:17:30 +0000 (UTC) (envelope-from gatinhodosseussonhos@hotmail.com) Received: from snt0-omc1-s32.snt0.hotmail.com (snt0-omc1-s32.snt0.hotmail.com [65.55.90.43]) by mx1.freebsd.org (Postfix) with ESMTP id C7DE88FC22 for ; Mon, 23 Nov 2009 04:17:30 +0000 (UTC) Received: from SNT102-W32 ([65.55.90.9]) by snt0-omc1-s32.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 20:17:30 -0800 Message-ID: X-Originating-IP: [189.72.31.212] From: Fulano Tal To: , Date: Mon, 23 Nov 2009 05:17:30 +0100 Importance: Normal In-Reply-To: <20091122214846.GA24357@minifree.wright.edu> References: <20091122214846.GA24357@minifree.wright.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 04:17:30.0287 (UTC) FILETIME=[DF6873F0:01CA6BF3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: Cisco Aironet MPI350 Fix X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 04:17:31 -0000 Mr O'Brien=2C =20 I gave up of 8.0-RC3 a few days ago because I was unable of fix a missing /= dev/agp=2C but I got better after reading "freeze up a few seconds about once a minute= "=2C just after restart a frozen pc. =20 I start to storm again but the only thing I know is: a) slackware agp nod makes no sense b) obscure halts during lilo are happening c) frost login prompts broke with my freebsd zippy cowsay fortune fun =20 I need some clues or better=2C a breakpoint hint. =20 =20 > Date: Sun=2C 22 Nov 2009 16:48:46 -0500 > From: obrien654j@gmail.com > To: freebsd-hackers@freebsd.org > Subject: Cisco Aironet MPI350 Fix >=20 > Hello=2C >=20 > I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31=2C and on a > fresh install of FreeBSD 8.0-RC3=2C the card did not work. Also=2C it cau= sed > my system to freeze up for a few seconds about once a minute as the > driver spit out "an0: device timeout" messages so long as the interface > was up. I researched the issue=2C and found the following fix already in > dragonflybsd's tree: >=20 > http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db= 883ae3eb5e4ebf2ece9 >=20 > I modified the patch and applied it to FreeBSD's kernel (trivial)=2C and > am happy to report that my card is now working flawlessly. Could someone > possibly review this patch and integrate it into the source tree so that > others may benefit from it as well? >=20 > The patch is based off of 8.0-RC3's code=2C but applies to the latest cod= e > as well without modification. >=20 > Thank you=2C > Jeremy O'Brien =20 _________________________________________________________________ Agora a pressa =E9 amiga da perfei=E7=E3o. Chegou o Windows 7. Conhe=E7a! http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=3D1539= From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 23 05:37:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C485A1065672 for ; Mon, 23 Nov 2009 05:37:19 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFC28FC19 for ; Mon, 23 Nov 2009 05:37:19 +0000 (UTC) Received: by gxk10 with SMTP id 10so2466152gxk.3 for ; Sun, 22 Nov 2009 21:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=SsMPYrTlYrgxI/+cSMuVuxXoAgRcXvZpovIOCSmRQQo=; b=k6Nrf2TYQGmgQOV/vp4mMz+/edScCfQUkpmkAxdE7v0Ig2cOeyJa+tgxp4kU3tr6su kJrH5jHWghVJhyYCC0RtdZxd2SajkhLket6R39J6mtcNEnioWP7CM0LEeB2EXOP5l2u7 Xb46NJXczi78xYX+CTxDhSAVN6D0MbuVGFljE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=o49sxZqNvNdNUNBPaBHtpXCqJYBo4fZ7+ftmGmiwQqDEK8mH3fRrCI82I2Pz6WdjuH Kr3kuOm8Xx/UomA3OHwUbaIWNWEZ3NI96XHkz0U2DzB5IfoXBbhl82NFdkfPMjE5xG8g ZZ7ax93xFM0daK3xDlbYJAu+TmYP9R2mya1GQ= MIME-Version: 1.0 Sender: heliocentric@gmail.com Received: by 10.150.174.8 with SMTP id w8mr7674739ybe.204.1258953062815; Sun, 22 Nov 2009 21:11:02 -0800 (PST) In-Reply-To: <20091121105244.GA35595@server.vk2pj.dyndns.org> References: <20091119065742.GA28159@logik.internal.network> <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> <20091121105244.GA35595@server.vk2pj.dyndns.org> Date: Mon, 23 Nov 2009 00:11:02 -0500 X-Google-Sender-Auth: 362b78a516240ee5 Message-ID: From: Dylan Cochran To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Wine on amd64 in 32 bit jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:37:19 -0000 On Sat, Nov 21, 2009 at 5:52 AM, Peter Jeremy wrote: > I did run into problems initially because my i386 userland wasn't > aligned with my amd64 kernel but rebuilding both fixed that (I'm > running 8.0-RC1 and a bit). > > Note that some tools that poke around in kernel innards won't work - > ps and lsof are the most obvious. =A0ktrace works but the resultant > ktrace.out files need to read with an amd64 kdump. A word of caution: not all the ioctl's and setsockopt's have the proper glue code under COMBAT_FREEBSD32. For example, running ifconfig on 7.2 i386-on-amd64 is unable to set an ip address, and syscons ioctls are completely broken. The program will build properly, but will be unreliable at runtime (seemingly out of the blue segfaults, a few cases of sigbus). Especially if they do a blind cast without sanity checking and confinue forward on error. While this may not seem that relevant on a build machine, remember that autoconf generates tiny stub binaries and runs them to determine 'compatibility' for the binary it intends to build. It may feed information that will lead it to making incorrect guesses about the target environment. It's not very common, but it has happened, and can fly under the radar. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 23 07:45:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C316106568B for ; Mon, 23 Nov 2009 07:45:48 +0000 (UTC) (envelope-from gatinhodosseussonhos@hotmail.com) Received: from snt0-omc1-s21.snt0.hotmail.com (snt0-omc1-s21.snt0.hotmail.com [65.55.90.32]) by mx1.freebsd.org (Postfix) with ESMTP id E43028FC17 for ; Mon, 23 Nov 2009 07:45:47 +0000 (UTC) Received: from SNT102-W42 ([65.55.90.7]) by snt0-omc1-s21.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 23:45:47 -0800 Message-ID: X-Originating-IP: [189.72.31.212] From: Fulano Tal To: , Date: Mon, 23 Nov 2009 08:45:47 +0100 Importance: Normal In-Reply-To: <20091122214846.GA24357@minifree.wright.edu> References: <20091122214846.GA24357@minifree.wright.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 07:45:47.0263 (UTC) FILETIME=[F82FA8F0:01CA6C10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: Cisco Aironet MPI350 Fix X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:45:48 -0000 ignore that=2C I just discovered watson.org..=2C sorry. =20 computers are not for me=2C really :/ =20 Felipe. =20 From: gatinhodosseussonhos@hotmail.com To: obrien654j@gmail.com=3B freebsd-hackers@freebsd.org Subject: RE: Cisco Aironet MPI350 Fix Date: Mon=2C 23 Nov 2009 05:17:30 +0100 Mr O'Brien=2C =20 I gave up of 8.0-RC3 a few days ago because I was unable of fix a missing /= dev/agp=2C but I got better after reading "freeze up a few seconds about once a minute= "=2C just after restart a frozen pc. =20 I start to storm again but the only thing I know is: a) slackware agp nod makes no sense b) obscure halts during lilo are happening c) frost login prompts broke with my freebsd zippy cowsay fortune fun =20 I need some clues or better=2C a breakpoint hint. =20 =20 > Date: Sun=2C 22 Nov 2009 16:48:46 -0500 > From: obrien654j@gmail.com > To: freebsd-hackers@freebsd.org > Subject: Cisco Aironet MPI350 Fix >=20 > Hello=2C >=20 > I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31=2C and on a > fresh install of FreeBSD 8.0-RC3=2C the card did not work. Also=2C it cau= sed > my system to freeze up for a few seconds about once a minute as the > driver spit out "an0: device timeout" messages so long as the interface > was up. I researched the issue=2C and found the following fix already in > dragonflybsd's tree: >=20 > http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db= 883ae3eb5e4ebf2ece9 >=20 > I modified the patch and applied it to FreeBSD's kernel (trivial)=2C and > am happy to report that my card is now working flawlessly. Could someone > possibly review this patch and integrate it into the source tree so that > others may benefit from it as well? >=20 > The patch is based off of 8.0-RC3's code=2C but applies to the latest cod= e > as well without modification. >=20 > Thank you=2C > Jeremy O'Brien A vida na frente do computador ficou mais simples: Chegou Windows 7! Clique= e Conhe=E7a=20 =20 _________________________________________________________________ Agora a pressa =E9 amiga da perfei=E7=E3o. Chegou o Windows 7. Conhe=E7a! http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=3D1539= From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 24 18:03:56 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7D77106566B for ; Tue, 24 Nov 2009 18:03:56 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id A80B78FC12 for ; Tue, 24 Nov 2009 18:03:56 +0000 (UTC) Received: from vesper.usenix.org (vesper.usenix.org [131.106.3.142]) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id nAOI3tpv013202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Nov 2009 10:03:56 -0800 (PST) Message-Id: <66C615B4-3A6C-4D6F-A294-F3B026780853@usenix.org> From: Lionel Garth Jones To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Nov 2009 10:03:55 -0800 X-Mailer: Apple Mail (2.930.3) X-DCC-Usenix-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.9 required=6.0 tests=ALL_TRUSTED,SUBJ_ALL_CAPS autolearn=no version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on lonestar X-Mailman-Approved-At: Tue, 24 Nov 2009 18:19:28 +0000 Subject: IPTPS '10 CFP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:03:56 -0000 On behalf of the 9th International Workshop on Peer-to-Peer Systems (IPTPS '10) program committee, we are inviting you to submit engaging position papers on the current and future trends in peer-to-peer systems. Co-located with NSDI '10 in San Jose, CA, this one-day workshop provides a venue in which to present and discuss peer-to-peer technologies, applications, and systems and to identify key research issues and challenges that lie ahead. This year, the workshop's charter will be expanded to include topics relating to self-organizing and self-managing distributed systems. This is in response to recent trends where self-organizing techniques proposed in early peer-to-peer systems have found their way into more managed settings such as datacenters, enterprises, and ISPs to help deal with growing scale, complexity, and heterogeneity. In the context of this year's workshop, peer-to-peer systems are defined to be large-scale distributed systems that are mostly decentralized, are self-organizing, and might or might not include resources from multiple administrative domains. Papers will be selected based on originality, likelihood of spawning insightful discussion, and technical merit. The program will include presentations of position papers along with plenty of time for lively discussion among the participants, as well as a demo session for working systems. Topics of interest include but are not limited to: * Network and system support for peer-to-peer systems * Self-organizing and self-managing distributed systems * Adaptive algorithms and architectures for large-scale distributed systems * New applications and protocols for peer-to-peer systems * Availability, robustness, performance, and scaling * Security, privacy, anonymity, anti-censorship, and incentives * Lessons drawn from experience with deployed peer-to-peer systems * Measurement, modeling, and workload characterization Complete paper submissions are due Friday, December 18, 2009, 11:59 p.m. EST. For more details on the submission process, please see the complete Call for Papers at: http://www.usenix.org/iptps10/cfpa/ We look forward to receiving your submissions! Michael J. Freedman, Princeton University Arvind Krishnamurthy, University of Washington IPTPS '10 Program Co-Chairs iptps10chairs@usenix.org --------------------------------- Call for Papers 9th International Workshop on Peer-to-Peer Systems (IPTPS '10) April 27, 2010 San Jose, CA http://www.usenix.org/iptps10/cfpa/ Submissions Deadline: December 18, 2009, 11:59 p.m. EST --------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 24 18:53:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5DEF1065692 for ; Tue, 24 Nov 2009 18:53:10 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id C1B598FC27 for ; Tue, 24 Nov 2009 18:53:10 +0000 (UTC) Received: by pwj15 with SMTP id 15so4725583pwj.3 for ; Tue, 24 Nov 2009 10:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=NrQlWj9TBZin9+vL0xDySQ+EqQYuxOWnGhInmzygcy0=; b=CY/9WLBk6O1rdca3yGIQ7LA3rrySYHeGaIkTV5GcrEARSpgGRbVlUXLT2dOVGFKO3Q Peui1/OB1/8B5S2d7HhHYoX4ddfMfQ+zMLr2im0v6pLWz/JTcboHwg9jWJDlKyFbwNVD Je5uoiXc1EVprhV8Hfkt7ztQAFmtLqC0BX8/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=I2912ZUjIWDsmLahvqqA01WqcDS/8M0PLFlqz2oVH4PzrFC+E2f1NxP/dWi3sTd2V3 1wnsJfi/AcKM3a2gOmJiBnkl5iBJ+r4Oy1tuZLc9zxNU/JQkZJVjk1QXh3pB6jbZmdC1 vby5QwePRkYBF92mbHpeYskEdYP0ppkpfYDik= MIME-Version: 1.0 Received: by 10.142.117.6 with SMTP id p6mr708727wfc.343.1259087379015; Tue, 24 Nov 2009 10:29:39 -0800 (PST) Date: Tue, 24 Nov 2009 10:29:38 -0800 Message-ID: From: Navdeep Parhar To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: zero size set_pcpu linker sets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:53:11 -0000 objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu" section of size 0. Why? What is the difference between having a 0 sized set_pcpu vs. not having it at all? The kernel linker considers the alignment requirements of these empty sections and advances mapsize/mapbase. This bothers my kgdb (which is slightly modified to deal with amd64 KLDs). I'm using the patch shown here as a stopgap measure. I think the correct fix is to not have these empty sections in the KLD to begin with. Regards, Navdeep diff -r 09b877bb00f2 sys/kern/link_elf_obj.c --- a/sys/kern/link_elf_obj.c Mon Nov 23 12:42:09 2009 -0800 +++ b/sys/kern/link_elf_obj.c Tue Nov 24 10:13:02 2009 -0800 @@ -680,10 +680,12 @@ switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: - alignmask = shdr[i].sh_addralign - 1; - mapsize += alignmask; - mapsize &= ~alignmask; - mapsize += shdr[i].sh_size; + if (shdr[i].sh_size) { + alignmask = shdr[i].sh_addralign - 1; + mapsize += alignmask; + mapsize &= ~alignmask; + mapsize += shdr[i].sh_size; + } break; } } @@ -740,9 +742,15 @@ switch (shdr[i].sh_type) { case SHT_PROGBITS: case SHT_NOBITS: - alignmask = shdr[i].sh_addralign - 1; - mapbase += alignmask; - mapbase &= ~alignmask; + if (shdr[i].sh_size) { + alignmask = shdr[i].sh_addralign - 1; + mapbase += alignmask; + mapbase &= ~alignmask; + } if (ef->shstrtab && shdr[i].sh_name != 0) ef->progtab[pb].name = ef->shstrtab + shdr[i].sh_name; From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 15:14:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A4581065672 for ; Thu, 26 Nov 2009 15:14:22 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id EC0E58FC3D for ; Thu, 26 Nov 2009 15:14:21 +0000 (UTC) Received: by ewy26 with SMTP id 26so886851ewy.3 for ; Thu, 26 Nov 2009 07:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ngdYyBe5c3TZXzUb0au/Oc1dwGTxfi1hkSHkvFuBgO0=; b=JxNe+VAgUdlQywAMeZWNQQ+G+M+OCXEnDKxooEJ9+7jNAulvraUTPMZoE+RwZFNL3z 98+HhpD/XDq7kAvniNelGHaA+ytC3MDvtFEX6l2U9+5IsbAOjBCh/R2XIBhLn08d7Ztf NibopLMBaWHEZY3OIebjs2pObqnN83ytBJwKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kpAV/p8OkUBqwfmlaeq8RxA8s1at3pqUCzH75YOve7OuuEhdECbDrjb45eweXfa4ZM NzB4Z9fIaD/b702BPgfezvreQVdb0iO1D/M0qPCFZjoDX+XPvz+I0ge55jG6uNXP9zL5 /7fhq27PV8zGa6oG62S/7ouq/gA/v5MpvpovM= MIME-Version: 1.0 Received: by 10.216.90.77 with SMTP id d55mr2808509wef.146.1259248460852; Thu, 26 Nov 2009 07:14:20 -0800 (PST) Date: Thu, 26 Nov 2009 10:14:20 -0500 Message-ID: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> From: Linda Messerschmidt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 15:14:22 -0000 We have a squid proxy process with very large memory requirements (10 - 20 GB) on a machine with 24GB of RAM. Unfortunately, we have to rotate the logs of this process once per day. When we do, it fork()s and exec()s about 16-20 child processes as helpers. Since it's got this multi-million-entry page table, that's a disaster, because it has to copy all those page table entries for each child, then throw them out. This takes a couple of minutes of 100% CPU usage, during which time the machine is pretty much unresponsive. Someone on the squid list suggested we try the new superpages feature (vm.pmap.pg_ps_enabled) in 7.2. We did, and after some tuning, we got it to work. Here's some "sysctl vm.pmap" for a similar machine with 16GB of RAM that does NOT have this setting enabled: vm.pmap.pv_entry_count: 2307899 vm.pmap.pde.promotions: 0 vm.pmap.pde.p_failures: 0 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 0 vm.pmap.pv_entry_max: 4276871 vm.pmap.pg_ps_enabled: 0 Now, here is the machine that does have it, just prior to the daily rotation mentioned above: vm.pmap.pv_entry_count: 61361 vm.pmap.pde.promotions: 23123 vm.pmap.pde.p_failures: 327946 vm.pmap.pde.mappings: 1641 vm.pmap.pde.demotions: 17848 vm.pmap.pv_entry_max: 7330186 vm.pmap.pg_ps_enabled: 1 So it obviously this feature makes a huge difference and is a brilliant idea. :-) My (limited) understanding is that one of the primary benefits of this feature is to help situations like ours... a page table that's 512x smaller can be copied 512x faster. However, in practice this doesn't happen. It's like fork() breaks up the squid process into 4kb pages again. Here's the same machine's entries just after rotation: vm.pmap.pv_entry_count: 1908056 vm.pmap.pde.promotions: 23212 vm.pmap.pde.p_failures: 413171 vm.pmap.pde.mappings: 1641 vm.pmap.pde.demotions: 21470 vm.pmap.pv_entry_max: 7330186 vm.pmap.pg_ps_enabled: 1 So some 3,600 superpages spontaneously turned into 1,850,000 4k pages. Once this happens, squid seems reluctant to use more superpages until its restarted. We get a lot of p_failures and a slow-but-steady stream of demotions. Here's the same machine just now: vm.pmap.pv_entry_count: 2022786 vm.pmap.pde.promotions: 25281 vm.pmap.pde.p_failures: 996027 vm.pmap.pde.mappings: 1641 vm.pmap.pde.demotions: 21683 vm.pmap.pv_entry_max: 7330186 vm.pmap.pg_ps_enabled: 1 And a few minutes later: vm.pmap.pv_entry_count: 2021556 vm.pmap.pde.promotions: 25331 vm.pmap.pde.p_failures: 1001773 vm.pmap.pde.mappings: 1641 vm.pmap.pde.demotions: 21684 vm.pmap.pv_entry_max: 7330186 vm.pmap.pg_ps_enabled: 1 (There were *no* p_failures or demotions in the several hours prior to rotation.) This trend continues... the pv_entry_count bounces up and down even though memory usage is increasing, so it's like it's trying to recover and convert things back (promotions), but it's having a lot of trouble (p_failures). It's not clear to me if this might be a problem with the superpages implementation, or if squid does something particularly horrible to its memory when it forks to cause this, but I wanted to ask about it on the list in case somebody who understands it better might know whats going on. :-) This is on FreeBSD-STABLE 7.2 amd64 r198976M. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 15:25:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from straylight.ringlet.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with SMTP id 4EA8E106568F for ; Thu, 26 Nov 2009 15:25:04 +0000 (UTC) (envelope-from roam@ringlet.net) Received: (qmail 15387 invoked by uid 1000); 26 Nov 2009 15:25:03 -0000 Date: Thu, 26 Nov 2009 17:25:03 +0200 From: Peter Pentchev To: freebsd-hackers@freebsd.org Message-ID: <20091126152503.GA14662@straylight.m.ringlet.net> References: <20091119065742.GA28159@logik.internal.network> <11167f520911191512q5fa951dbu6ab7cf35de31825@mail.gmail.com> <20091121105244.GA35595@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Wine on amd64 in 32 bit jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 15:25:05 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2009 at 12:11:02AM -0500, Dylan Cochran wrote: > On Sat, Nov 21, 2009 at 5:52 AM, Peter Jeremy wrote: > > I did run into problems initially because my i386 userland wasn't > > aligned with my amd64 kernel but rebuilding both fixed that (I'm > > running 8.0-RC1 and a bit). > > > > Note that some tools that poke around in kernel innards won't work - > > ps and lsof are the most obvious. =A0ktrace works but the resultant > > ktrace.out files need to read with an amd64 kdump. >=20 > A word of caution: not all the ioctl's and setsockopt's have the > proper glue code under COMBAT_FREEBSD32... That was actually a nice typo :P G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 This sentence would be seven words long if it were six words shorter. --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iQIcBAEBCgAGBQJLDp3NAAoJEGUe77AlJ98THHsP/Rvi/wVGVgNAeOCEEnYE8CQ1 /1HgooLs1ARoosByqGygkTuxcFudzrxY09cZ8s0bgpBkRngs/Mn0dMJAcL5DBzWT ztCF7kN0DlJE4Dq+/pG1Q8ysI3pSNl7XK1v4IEM3cnByKChJjmKPBIhLgEIyW7hU iar3P5M77rxRvWGEgWmr7QhEGlXgHAWfw8wFZVJfLOtsXqhJbaoz1fiAPW8XvVLa leMv7UjkhIffGWgfcvE+/JDukAVxhC4lVuCm9xmgP4PhEKVQXovHWK9BiMSNm236 RccbS2EkRG1j73m/GcjZcVaNbMlsqgwkjniHu0Pk2k+YNUHDqsBBTW6GvKMgO689 1OwJyCUSvky0E+j+bTUIRU7dZfoeZe0Y30Wzu1qen7+kHP1Ocy09ajU/zURNNCyy e9eL0jFN/+AiGhYhbz5wkfJc0E3hc61qySn2jnbtgnMcOy7aNWLZx4GTHTTl+nKR xdjUwFuj4HZ/DnnPeHJz5PzTNOR2rD5oHBRGJg+t55MU3Kqf2zVx06JDIPO9Lwql HOiPHZ6Bp2mA9hKbnUfd3kkiJoblnuM3lcis9/8inysdIEISl0/a7vCgRot8pmcR SDqUfpZvxDMwps/xaNRfLdfMEj8HES8yCYczlX+y8dS5lJDCaIhRu/0/VKUoawfi Wv8H685Ms2Vk3k4blh3G =O2Oa -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 15:34:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C000E106568D for ; Thu, 26 Nov 2009 15:34:42 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 559E58FC08 for ; Thu, 26 Nov 2009 15:34:41 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so243265eye.9 for ; Thu, 26 Nov 2009 07:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PDdpojboYvqivuUh8DsByrd610sRW/OEqtRdxzI8gJE=; b=axnqY6fq5SJmhyzGwyBCh/nKLtDrCyU0yuynvPO6SBwkJbaC+TnYQfEKwv2DrzP9Hb CGvuLbiYFXPcDRHcXZ6px7KahKDHKpaNsmHSG3fURclXgaEzRC7SgXmNhd91DqSZAF3o iBLkSjfRv128nhdsiCTVmp7g3OvnSFBKKwbEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AXhfnKwt/bmTPo3A/SgW7dzR+hNpPMDajJgaZ2mhl0FLTMfJn41jLnQ7LndK5KUHjv wg1omHqh+aXVS/bSILrpyB9fCyAJ1XoOnSsEUC/A14zJ4jvVw8Gb+IrLXpWHIBOSk1ue UrFxZnms4H7Ldgi5Pu5kRp15uQ9xwdJDZjHtg= MIME-Version: 1.0 Received: by 10.216.87.144 with SMTP id y16mr359605wee.95.1259249681180; Thu, 26 Nov 2009 07:34:41 -0800 (PST) In-Reply-To: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> Date: Thu, 26 Nov 2009 10:34:41 -0500 Message-ID: From: Ryan Stone To: Linda Messerschmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 15:34:42 -0000 Is squid multithreaded? My first guess would be that you have one thread forking off all of these processes while other threads are still doing work and writing to different parts of the address space. I don't know the details of the superpages implementation but I could definitely see that this could be a problem. When the process is forked off the vm layer has to mark all of the pages in the parent process as copy-on-write. If there are other threads in squid writing to memory in this time, the vm layer will have to allocate a new page of memory for every page that squid writes to. This breaks up the superpage(superpages must be physically contiguous in memory). I don't know if the superpage implementation tries to alleviate this situation at all. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 15:47:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CD51106566B for ; Thu, 26 Nov 2009 15:47:17 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2274C8FC18 for ; Thu, 26 Nov 2009 15:47:16 +0000 (UTC) Received: by ewy26 with SMTP id 26so919205ewy.3 for ; Thu, 26 Nov 2009 07:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HDhX8X9+Sejc37/ox1AJa4W57LpNyKAFXBpHMMKTh2E=; b=skAUq4+XFryjyihh4acSOX+RhEcPnWWDQ93y5Xfys98taxMu/VOxkJikOzRZV4AHuK jjmVFX5kGkm3MGUk5MzZAtDO8N1rY00/COTGlaDFG9gxmI9PKkSmVgIpk3x0gDWQIc8h E12kP1jsba0sLWy9EvwNhFU42lHrZxHL3TM/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vG2BjvTCM2VHP9PvqMXXhm9wcRe8EZqwdUBJlgENdITF+UCT586p3Pju4qJLUNwES1 nikXyne4KXK5gfailqFkh0VQkgqYYhAw2PS4i1hP2e4vm0yHEBctE4oigSBXQ2gAKfc9 +ASTzqPoKJ8P+NKYEfw74736+E0bblWh9+Xvo= MIME-Version: 1.0 Received: by 10.216.87.71 with SMTP id x49mr233018wee.11.1259250436033; Thu, 26 Nov 2009 07:47:16 -0800 (PST) In-Reply-To: References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> Date: Thu, 26 Nov 2009 10:47:15 -0500 Message-ID: <237c27100911260747v3089d14aj7c9c86526df3f234@mail.gmail.com> From: Linda Messerschmidt To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 15:47:17 -0000 On Thu, Nov 26, 2009 at 10:34 AM, Ryan Stone wrote: > Is squid multithreaded? No, it isn't: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 75086 squid 1 4 0 12571M 12584M kqread 6 31:31 0.68% squid Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 15:50:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4604106568F for ; Thu, 26 Nov 2009 15:50:08 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 950F18FC08 for ; Thu, 26 Nov 2009 15:50:08 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 817646D41B; Thu, 26 Nov 2009 15:50:07 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 450B0844F2; Thu, 26 Nov 2009 16:50:07 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Linda Messerschmidt References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> Date: Thu, 26 Nov 2009 16:50:07 +0100 In-Reply-To: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> (Linda Messerschmidt's message of "Thu, 26 Nov 2009 10:14:20 -0500") Message-ID: <86bpipuvyo.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 15:50:08 -0000 Linda Messerschmidt writes: > Unfortunately, we have to rotate the logs of this process once per > day. When we do, it fork()s and exec()s about 16-20 child processes > as helpers. s/fork/vfork/ and you should be fine. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 15:51:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47624106568D for ; Thu, 26 Nov 2009 15:51:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 078BE8FC1A for ; Thu, 26 Nov 2009 15:51:27 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 38C7C6D44E; Thu, 26 Nov 2009 15:51:27 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0444B844F2; Thu, 26 Nov 2009 16:51:27 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Linda Messerschmidt References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <86bpipuvyo.fsf@ds4.des.no> Date: Thu, 26 Nov 2009 16:51:26 +0100 In-Reply-To: <86bpipuvyo.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Thu, 26 Nov 2009 16:50:07 +0100") Message-ID: <867htduvwh.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 15:51:28 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Linda Messerschmidt writes: > > Unfortunately, we have to rotate the logs of this process once per > > day. When we do, it fork()s and exec()s about 16-20 child processes > > as helpers. > s/fork/vfork/ and you should be fine. ...and you should look into replacing Squid with Varnish, of course. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 16:15:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D8371065672 for ; Thu, 26 Nov 2009 16:15:44 +0000 (UTC) (envelope-from nil@opensesame.st) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0333A8FC17 for ; Thu, 26 Nov 2009 16:15:43 +0000 (UTC) Received: by gxk10 with SMTP id 10so694732gxk.3 for ; Thu, 26 Nov 2009 08:15:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.235.1 with SMTP id i1mr6281627anh.97.1259250799165; Thu, 26 Nov 2009 07:53:19 -0800 (PST) X-Originating-IP: [72.191.33.69] In-Reply-To: <237c27100911260747v3089d14aj7c9c86526df3f234@mail.gmail.com> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <237c27100911260747v3089d14aj7c9c86526df3f234@mail.gmail.com> From: james toy Date: Thu, 26 Nov 2009 10:52:59 -0500 Message-ID: <11dbd75e0911260752o46b2c82ch3b33ac7fb27f6b44@mail.gmail.com> To: Linda Messerschmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ryan Stone Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:15:44 -0000 Hi Linda, vfork() should mitigate this -- i suggest replacing. respectfully, =3Djt On Thu, Nov 26, 2009 at 10:47, Linda Messerschmidt wrote: > On Thu, Nov 26, 2009 at 10:34 AM, Ryan Stone wrote: >> Is squid multithreaded? > > No, it isn't: > > =A0PID USERNAME =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0 TIME = =A0 WCPU COMMAND > 75086 squid =A0 =A0 =A0 1 =A0 4 =A0 =A00 12571M 12584M kqread =A06 =A031:= 31 =A00.68% squid > > Thanks! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 17:11:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18AF1106566B for ; Thu, 26 Nov 2009 17:11:12 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id A44078FC19 for ; Thu, 26 Nov 2009 17:11:11 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so265949eye.9 for ; Thu, 26 Nov 2009 09:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=x2241r9jKCFDucac5S6kKWqKp9X3IAJGqstV8c2aOt0=; b=G0Db5xTYzKUO4Fqb4ifQGpkxDKuCL5Zq2akVowvhGxDIdlQB9qCCPk3BEHkf6Gp1VU hTkd3A+W5ov3OwPLopCvTDVYH7h2xgI3aaRGMMbKLnPKnr1nZPjaV4vGH9Hh3O0kSj/V n9hlqEM/6gyvRyil0AEsoi/T9siJ9pZZRvoNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZeYHEQzxoGLihpggPDzJqdSTt8FYvNSyp7OmSxdDxUCTlljBwD5Jhb2TPbO+ZqKkQO vOBTDYE/oi/SOthdEt1xx4n8yKMg5GgZg4QW5WzAH+qbl9M2lf6N7qwF1FAZ/m1ftnhG IHCWLXo9H38fhArNNKYxJTGdLcYAou+ryIBQ8= MIME-Version: 1.0 Received: by 10.216.90.77 with SMTP id d55mr2847473wef.146.1259255470661; Thu, 26 Nov 2009 09:11:10 -0800 (PST) In-Reply-To: <867htduvwh.fsf@ds4.des.no> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <86bpipuvyo.fsf@ds4.des.no> <867htduvwh.fsf@ds4.des.no> Date: Thu, 26 Nov 2009 12:11:10 -0500 Message-ID: <237c27100911260911w2674b79ds8ac447e900324dce@mail.gmail.com> From: Linda Messerschmidt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:11:12 -0000 I think I was not clear with my message, I apologize. I did not mean to suggest that we were asking for help solving a problem with squid rotation. I provided that information as background to discuss what we observed as a potential misbehavior in the new VM superpages feature, in the hope that if there is a problem with the new feature, we can help find/resolve it or, if this is working as intended, hopefully gain some insight as to what's going on. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 26 17:04:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A9141065694 for ; Thu, 26 Nov 2009 17:04:37 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 765888FC13 for ; Thu, 26 Nov 2009 17:04:36 +0000 (UTC) Received: by fxm10 with SMTP id 10so793833fxm.14 for ; Thu, 26 Nov 2009 09:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=K3NF4oxqXtoEX7+fBDNeVXqhfiLXZpDeajvDWUrc7bc=; b=YyjOONa73SSADVgK5n7rkRMEjydDlfmN6w/guzjXXHfTUb0U1L0Mj0q+L/9lkfyuyz X2C84BxbGqOdu92QWw6qR5no2vDnDOYZdVzlSjRBGiGvmFcUMARx18C1qe47Z/JeZClR O3uAE9RU1oFELei5Zy0J92OG+8kzACAyrbQEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uHEKuwjIX5F0gyM1heVecV/V2j7qGz1yLCj4ill/vQVGqFSZoQLKK0+fNMwQskfaOj IUZapOkmxpC1juLnVWQCoLFp0zRm248ZYegP2CcFQdn5WfYq/jEGHOU3dk0gnIIIAtvS Zy/ad31rFQjlBSBxcjLoBzKTdLdhGEKgUaJxg= MIME-Version: 1.0 Received: by 10.239.179.99 with SMTP id c35mr932939hbg.197.1259255075205; Thu, 26 Nov 2009 09:04:35 -0800 (PST) In-Reply-To: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> Date: Thu, 26 Nov 2009 17:04:34 +0000 Message-ID: From: krad To: Linda Messerschmidt X-Mailman-Approved-At: Thu, 26 Nov 2009 17:38:37 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:04:37 -0000 2009/11/26 Linda Messerschmidt > We have a squid proxy process with very large memory requirements (10 > - 20 GB) on a machine with 24GB of RAM. > > Unfortunately, we have to rotate the logs of this process once per > day. When we do, it fork()s and exec()s about 16-20 child processes > as helpers. Since it's got this multi-million-entry page table, > that's a disaster, because it has to copy all those page table entries > for each child, then throw them out. This takes a couple of minutes > of 100% CPU usage, during which time the machine is pretty much > unresponsive. > > Someone on the squid list suggested we try the new superpages feature > (vm.pmap.pg_ps_enabled) in 7.2. We did, and after some tuning, we got > it to work. > > Here's some "sysctl vm.pmap" for a similar machine with 16GB of RAM > that does NOT have this setting enabled: > > vm.pmap.pv_entry_count: 2307899 > vm.pmap.pde.promotions: 0 > vm.pmap.pde.p_failures: 0 > vm.pmap.pde.mappings: 0 > vm.pmap.pde.demotions: 0 > vm.pmap.pv_entry_max: 4276871 > vm.pmap.pg_ps_enabled: 0 > > Now, here is the machine that does have it, just prior to the daily > rotation mentioned above: > > vm.pmap.pv_entry_count: 61361 > vm.pmap.pde.promotions: 23123 > vm.pmap.pde.p_failures: 327946 > vm.pmap.pde.mappings: 1641 > vm.pmap.pde.demotions: 17848 > vm.pmap.pv_entry_max: 7330186 > vm.pmap.pg_ps_enabled: 1 > > So it obviously this feature makes a huge difference and is a > brilliant idea. :-) > > My (limited) understanding is that one of the primary benefits of this > feature is to help situations like ours... a page table that's 512x > smaller can be copied 512x faster. However, in practice this doesn't > happen. It's like fork() breaks up the squid process into 4kb pages > again. Here's the same machine's entries just after rotation: > > vm.pmap.pv_entry_count: 1908056 > vm.pmap.pde.promotions: 23212 > vm.pmap.pde.p_failures: 413171 > vm.pmap.pde.mappings: 1641 > vm.pmap.pde.demotions: 21470 > vm.pmap.pv_entry_max: 7330186 > vm.pmap.pg_ps_enabled: 1 > > So some 3,600 superpages spontaneously turned into 1,850,000 4k pages. > > Once this happens, squid seems reluctant to use more superpages until > its restarted. We get a lot of p_failures and a slow-but-steady > stream of demotions. Here's the same machine just now: > > vm.pmap.pv_entry_count: 2022786 > vm.pmap.pde.promotions: 25281 > vm.pmap.pde.p_failures: 996027 > vm.pmap.pde.mappings: 1641 > vm.pmap.pde.demotions: 21683 > vm.pmap.pv_entry_max: 7330186 > vm.pmap.pg_ps_enabled: 1 > > And a few minutes later: > > vm.pmap.pv_entry_count: 2021556 > vm.pmap.pde.promotions: 25331 > vm.pmap.pde.p_failures: 1001773 > vm.pmap.pde.mappings: 1641 > vm.pmap.pde.demotions: 21684 > vm.pmap.pv_entry_max: 7330186 > vm.pmap.pg_ps_enabled: 1 > > (There were *no* p_failures or demotions in the several hours prior to > rotation.) > > This trend continues... the pv_entry_count bounces up and down even > though memory usage is increasing, so it's like it's trying to recover > and convert things back (promotions), but it's having a lot of trouble > (p_failures). > > It's not clear to me if this might be a problem with the superpages > implementation, or if squid does something particularly horrible to > its memory when it forks to cause this, but I wanted to ask about it > on the list in case somebody who understands it better might know > whats going on. :-) > > This is on FreeBSD-STABLE 7.2 amd64 r198976M. > > Thanks! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Im sure you will get a lot of lovely answers to this but best keep things simple. WHy not just syslog it of to another server and offload all the compression to that box. You could even back it with zfs nad do on the fly gzip compression at the file system level, or use syslog-ng to do it. If you are worried about zfs and bsd use (open)*solaris or another filesystem with with inline compression From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 05:42:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B6961065670 for ; Fri, 27 Nov 2009 05:42:19 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id EE2E08FC08 for ; Fri, 27 Nov 2009 05:42:18 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id nAR5gGY8003287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 Nov 2009 16:12:16 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Fri, 27 Nov 2009 16:12:05 +1030 User-Agent: KMail/1.9.10 References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1345579.13HRzccGxm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911271612.14394.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Linda Messerschmidt , krad Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 05:42:19 -0000 --nextPart1345579.13HRzccGxm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 27 Nov 2009, krad wrote: > Im sure you will get a lot of lovely answers to this but best keep > things simple. WHy not just syslog it of to another server and > offload all the compression to that box. You could even back it with > zfs nad do on the fly gzip compression at the file system level, or > use syslog-ng to do it. If you are worried about zfs and bsd use > (open)*solaris =A0or another filesystem with with inline compression Or send squids logs to a small buffer process which you then HUP when=20 rotating logs. Also, I don't really understand why squid would fork when you tell it to=20 rotate, seems like a design defect. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1345579.13HRzccGxm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLD2a25ZPcIHs/zowRAjXuAJ9+QwnQbp57E2fFT2kf+lTnLUd5egCcDFlu Cg1nwa4zmvTFPGVcSzpn97M= =WhYk -----END PGP SIGNATURE----- --nextPart1345579.13HRzccGxm-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 08:13:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5FB11065672 for ; Fri, 27 Nov 2009 08:13:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 781AC8FC1A for ; Fri, 27 Nov 2009 08:13:23 +0000 (UTC) Received: by iwn36 with SMTP id 36so783618iwn.3 for ; Fri, 27 Nov 2009 00:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=dbwzoGsZ22s/7UoiYRij9c7ZBkCefq6iqukwaPK6Wh8=; b=HE3Guuwpb14gShY4QkjyJ9XGyOVg1PLTrbFc0ELOyfK0cQ8VQ37sBXaKP35r1dIpkO 3V8GUhhn0/da04VpEKfVqRgH1ksFBn8Np77fEsbQThD+wtyOENA5ZDd2t0sW7KirI0c6 tbNUDdYvD2zTsjUnRDSn0yz44mJ6ZwYGgVKfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WCwUzYHkNI1GaLB3fpisGdnuRof8K3i08QiydybMYyZV4JOhMAcxo301II6qmcN4hb Bz/c/2XTqKlT0/8gVprT4F6LW15Fx38ishQj65oI+q0GH0iyoNgjCZBZiMqgcCr8OIeK qsx7SK8SgVwJ2dcn0xPOF4SRW4ZQWpRnVtV0g= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.231.4.75 with SMTP id 11mr1721867ibq.25.1259307938751; Thu, 26 Nov 2009 23:45:38 -0800 (PST) In-Reply-To: <200911271612.14394.doconnor@gsoft.com.au> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200911271612.14394.doconnor@gsoft.com.au> Date: Fri, 27 Nov 2009 02:45:38 -0500 X-Google-Sender-Auth: 61f8d68f868e9711 Message-ID: From: Adrian Chadd To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt , krad Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:13:23 -0000 There's a bunch of other random crap that may be going on relating to the helper processes (eg rewriters, auth, etc) which may also be restarted. Anyway. The thread is about superpage demotion and copying, not what Squid is or isn't doing in her configuration. :) Adrian 2009/11/27 Daniel O'Connor : > On Fri, 27 Nov 2009, krad wrote: >> Im sure you will get a lot of lovely answers to this but best keep >> things simple. WHy not just syslog it of to another server and >> offload all the compression to that box. You could even back it with >> zfs nad do on the fly gzip compression at the file system level, or >> use syslog-ng to do it. If you are worried about zfs and bsd use >> (open)*solaris =A0or another filesystem with with inline compression > > Or send squids logs to a small buffer process which you then HUP when > rotating logs. > > Also, I don't really understand why squid would fork when you tell it to > rotate, seems like a design defect. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > =A0-- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 08:39:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FB71106566B for ; Fri, 27 Nov 2009 08:39:50 +0000 (UTC) (envelope-from hmk@tf.uni-kiel.de) Received: from tfmail.tf.uni-kiel.de (tfmail.tf.uni-kiel.de [134.245.244.101]) by mx1.freebsd.org (Postfix) with ESMTP id C3D868FC12 for ; Fri, 27 Nov 2009 08:39:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by tfmail.tf.uni-kiel.de (Postfix) with ESMTP id 68FCA1000CD24 for ; Fri, 27 Nov 2009 09:19:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at tf.uni-kiel.de Received: from tfmail.tf.uni-kiel.de ([127.0.0.1]) by localhost (tfmail.tf.uni-kiel.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a05jD-OVsVJ0 for ; Fri, 27 Nov 2009 09:19:11 +0100 (CET) Received: by tfmail.tf.uni-kiel.de (Postfix, from userid 505) id DD50C1000CD12; Fri, 27 Nov 2009 09:19:11 +0100 (CET) Date: Fri, 27 Nov 2009 09:19:11 +0100 From: Henner Morten Kruse To: freebsd-hackers@freebsd.org Message-ID: <20091127081911.GA4254@tf.uni-kiel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Workaround for ntop as daemon, is it ok? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:39:50 -0000 Hi, I have just set up an ntop server based on 8.0-RELEASE. FreeBSD ntop 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 After installing ntop 1.3.10 and all dependencies from the ports ntop did work, but when running ntop as a daemon I got permanent and repeating warning messages: [warn] kevent: Bad file descriptor ktrace reported the following: 47944 100098 initial thread CALL kevent(0x5,0x29ed8700,0x1,0x29ed8c00, 0x40,0) 47944 100098 initial thread RET kevent 1 47945 100139 ntop CALL kevent(0x5,0x29ed8700,0x3,0x29ed8c00,0x40, 0xbfbfd8a4) 47945 100139 ntop RET kevent -1 errno 9 Bad file descriptor "[warn] kevent: Bad file descriptor I found out that ntop forks another thread for the daemon and kills the initial one. The problem with this behaviour is that the kqueue is started by the initial thread and the daemon thread doesn't use the same file descriptors. So the kqueue is lost. This is ntop running in foreground (note fd 5, this is the kqueue): PID COMM FD T V FLAGS REF OFFSET PRO NAME 48884 ntop cwd v d -------- - - - /usr/ports/net/ntop/work/ntop-3.3.10 48884 ntop root v d -------- - - - / 48884 ntop 0 v c rw------ 12 421416 - /dev/pts/1 48884 ntop 1 v c rw------ 12 421416 - /dev/pts/1 48884 ntop 2 v c rw------ 12 421416 - /dev/pts/1 48884 ntop 3 v r rw-----l 1 12646 - /var/db/ntop/prefsCache.db 48884 ntop 4 v r rw-----l 1 12557 - /var/db/ntop/ntop_pw.db 48884 ntop 5 k - rw------ 1 0 - - 48884 ntop 6 v c rw------ 2 35673 - /dev/bpf 48884 ntop 7 s - rw---n-- 2 0 UDP 0.0.0.0:30903 0.0.0.0:0 48884 ntop 8 s - rw---n-- 2 0 UDP 0.0.0.0:56316 0.0.0.0:0 48884 ntop 9 s - rw---n-- 2 0 UDP 0.0.0.0:56311 0.0.0.0:0 48884 ntop 10 v r rw-----l 1 13782 - /var/db/ntop/dnsCache.db 48884 ntop 11 v r rw-----l 1 652448 - /var/db/ntop/macPrefix.db 48884 ntop 12 v r rw-----l 1 167936 - /var/db/ntop/fingerprint.db 48884 ntop 13 v r r------- 1 24903680 - /usr/local/etc/ntop/GeoLiteCity.dat 48884 ntop 14 v r r------- 1 1601536 - /usr/local/etc/ntop/GeoIPASNum.dat 48884 ntop 15 s - rw------ 1 0 TCP 0.0.0.0:3000 0.0.0.0:0 48884 ntop 17 v r rw-----l 1 8192 - /var/db/ntop/LsWatch.db And this is ntop running in background: PID COMM FD T V FLAGS REF OFFSET PRO NAME 48842 ntop cwd v d -------- - - - / 48842 ntop root v d -------- - - - / 48842 ntop 0 v r r------- 1 24903680 - /usr/local/etc/ntop/GeoLiteCity.dat 48842 ntop 1 v r r------- 1 1601536 - /usr/local/etc/ntop/GeoIPASNum.dat 48842 ntop 2 v c rw------ 11 413845 - /dev/pts/1 48842 ntop 3 v r rw-----l 1 12646 - /var/db/ntop/prefsCache.db 48842 ntop 4 v r rw-----l 1 12557 - /var/db/ntop/ntop_pw.db 48842 ntop 5 s - rw------ 1 0 TCP 0.0.0.0:3000 0.0.0.0:0 48842 ntop 6 v c rw------ 2 32705 - /dev/bpf 48842 ntop 7 s - rw---n-- 1 0 UDP 0.0.0.0:48169 0.0.0.0:0 48842 ntop 8 s - rw---n-- 1 0 UDP 0.0.0.0:36849 0.0.0.0:0 48842 ntop 9 s - rw---n-- 1 0 UDP 0.0.0.0:64119 0.0.0.0:0 48842 ntop 10 v r rw-----l 1 13284 - /var/db/ntop/dnsCache.db 48842 ntop 11 v r rw-----l 1 499464 - /var/db/ntop/macPrefix.db 48842 ntop 12 v r rw-----l 1 167936 - /var/db/ntop/fingerprint.db 48842 ntop 14 v r rw-----l 1 8192 - /var/db/ntop/LsWatch.db After further investiagations I found the function which is responsible for the fork at line 172 of ntop.c. /* **************************************** */ void daemonizeUnderUnix(void) { #ifndef WIN32 int childpid; signal(SIGHUP, SIG_IGN); #ifdef HANDLE_DIED_CHILD signal(SIGCHLD, handleDiedChild); #else signal(SIGCHLD, SIG_IGN); #endif signal(SIGQUIT, SIG_IGN); if((childpid=fork()) < 0) traceEvent(CONST_TRACE_ERROR, "INIT: Occurred while daemonizing (errno=%d)", errno); else { #ifdef DEBUG traceEvent(CONST_TRACE_INFO, "DEBUG: after fork() in %s (%d)", childpid ? "parent" : "child", childpid); #endif if(!childpid) { /* child */ traceEvent(CONST_TRACE_INFO, "INIT: Bye bye: I'm becoming a daemon..."); detachFromTerminalUnderUnix(1); } else { /* father */ traceEvent(CONST_TRACE_INFO, "INIT: Parent process is exiting (this is normal)"); exit(0); } } myGlobals.mainThreadId = pthread_self(); traceEvent(CONST_TRACE_ALWAYSDISPLAY, "THREADMGMT[t%lu]: Now running as a daemon", myGlobals.mainThreadId); #endif } /* **************************************** */ When I change the fork() in line 186 to rfork(RFPROC) everything works and I get no more warning messages and procstat reports an existing kqueue for the daemonized ntop: PID COMM FD T V FLAGS REF OFFSET PRO NAME 54712 ntop cwd v d -------- - - - / 54712 ntop root v d -------- - - - / 54712 ntop 0 v r r------- 1 24903680 - /usr/local/etc/ntop/GeoLiteCity.dat 54712 ntop 1 v r r------- 1 1601536 - /usr/local/etc/ntop/GeoIPASNum.dat 54712 ntop 2 v c rw------ 11 884896 - /dev/pts/2 54712 ntop 3 v r rw-----l 1 12646 - /var/db/ntop/prefsCache.db 54712 ntop 4 v r rw-----l 1 12557 - /var/db/ntop/ntop_pw.db 54712 ntop 5 k - rw------ 1 0 - - 54712 ntop 6 v c rw------ 2 56988 - /dev/bpf 54712 ntop 7 s - rw---n-- 2 0 UDP 0.0.0.0:21649 0.0.0.0:0 54712 ntop 8 s - rw---n-- 2 0 UDP 0.0.0.0:15926 0.0.0.0:0 54712 ntop 9 s - rw---n-- 2 0 UDP 0.0.0.0:43003 0.0.0.0:0 54712 ntop 10 v r rw-----l 1 14612 - /var/db/ntop/dnsCache.db 54712 ntop 11 v r rw-----l 1 322078 - /var/db/ntop/macPrefix.db 54712 ntop 12 v r rw-----l 1 167936 - /var/db/ntop/fingerprint.db 54712 ntop 13 s - rw------ 1 0 TCP 0.0.0.0:3000 0.0.0.0:0 54712 ntop 15 v r rw-----l 1 8192 - /var/db/ntop/LsWatch.db So my question to this is: Is my workaround ok or could this cause any problems? And what is the cause of these warnings? Is it a bug or incapability in the kqueue implementation or is it caused by bad code in ntop? Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 08:55:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42A0E1065679 for ; Fri, 27 Nov 2009 08:55:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id CCE668FC15 for ; Fri, 27 Nov 2009 08:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 04AB941C796; Fri, 27 Nov 2009 09:55:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Bi2LEcLw412U; Fri, 27 Nov 2009 09:55:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 2D0BB41C795; Fri, 27 Nov 2009 09:55:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4CB754448EC; Fri, 27 Nov 2009 08:51:41 +0000 (UTC) Date: Fri, 27 Nov 2009 08:51:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Navdeep Parhar In-Reply-To: Message-ID: <20091127084843.V37440@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: zero size set_pcpu linker sets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:55:09 -0000 On Tue, 24 Nov 2009, Navdeep Parhar wrote: Hi, > objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu" > section of size 0. Why? What is the difference between having a 0 > sized set_pcpu vs. not having it at all? > > The kernel linker considers the alignment requirements of these empty > sections and advances mapsize/mapbase. This bothers my kgdb (which is > slightly modified to deal with amd64 KLDs). So what's your real problem? > I'm using the patch shown here as a stopgap measure. I think the correct > fix is to not have these empty sections in the KLD to begin with. Right. The problem here is a bug with ld and linker sets and size and aligment calculations the the elf section is started when not all of this is known correctly and it's not fixed later. This came up with that "netisr" bug where we had seen the misalignment of the dpcpu set. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 11:27:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D951065672 for ; Fri, 27 Nov 2009 11:27:06 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCC98FC0A for ; Fri, 27 Nov 2009 11:27:05 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-157-187.lns6.adl6.internode.on.net [121.45.157.187]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id nARBR2dj012025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 Nov 2009 21:57:03 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Adrian Chadd Date: Fri, 27 Nov 2009 21:56:36 +1030 User-Agent: KMail/1.9.10 References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200911271612.14394.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6700669.yVJjEBM4GY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911272156.58108.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt , krad Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 11:27:07 -0000 --nextPart6700669.yVJjEBM4GY Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 27 Nov 2009, Adrian Chadd wrote: > There's a bunch of other random crap that may be going on relating to > the helper processes (eg rewriters, auth, etc) which may also be > restarted. OK. > Anyway. The thread is about superpage demotion and copying, not what > Squid is or isn't doing in her configuration. :) Yeah I understand that but if you can avoid the huge problem with a deft=20 rearrangement that may help your production environment and give you=20 more time for a real solution :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6700669.yVJjEBM4GY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLD7eC5ZPcIHs/zowRAl+sAKCMXPi9PdBxQMcAh1/i4CfulLOvRQCgpUyf njAWYns7mEA28escQgK/Jn4= =OciS -----END PGP SIGNATURE----- --nextPart6700669.yVJjEBM4GY-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 16:52:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D5821065670 for ; Fri, 27 Nov 2009 16:52:45 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from mx27.mail.ru (mx27.mail.ru [94.100.176.41]) by mx1.freebsd.org (Postfix) with ESMTP id F0DA88FC14 for ; Fri, 27 Nov 2009 16:52:44 +0000 (UTC) Received: from [91.190.115.253] (port=49089 helo=pstation) by mx27.mail.ru with asmtp id 1NE43n-0000tp-00 for freebsd-hackers@freebsd.org; Fri, 27 Nov 2009 19:52:43 +0300 Date: Fri, 27 Nov 2009 19:56:59 +0300 From: Anthony Pankov X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) Message-ID: <15434604890.20091127195659@mail.ru> To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: ucred when euid/egid X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anthony Pankov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:52:45 -0000 Hello, I face some misunderstood situation related to the access permissions. There is a program(script) with the suid/sgid (mode 6555): r-sr-sr-x fuser:proggroup theprog There is a file: rw-rw---- someone:filegroup thefile User 'fuser' (==program euid) have primary group 'filegroup'(==group, who can read/write thefile). Program try to read(write) thefile and fail with permissions. I don't fully understand why. According VOP_ACCESS(9) there is a check /* Otherwise, check the groups. */ for (i = 0, gp = cred->cr_groups; i < cred->cr_ngroups; i++, gp++) ... So, i have only one assumption: when seteuided program executed ucred struct and cred->cr_groups doesn't change accordingly to euid/egid and stay the same as for executor. Is this a bug (how can i fix it) or feature (how can i bypass it)? -- Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 17:08:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3B41065672 for ; Fri, 27 Nov 2009 17:08:28 +0000 (UTC) (envelope-from jilles@crab.stack.nl) Received: from crab.stack.nl (crab.stack.nl [131.155.140.134]) by mx1.freebsd.org (Postfix) with ESMTP id 972E08FC13 for ; Fri, 27 Nov 2009 17:08:27 +0000 (UTC) Received: by crab.stack.nl (Postfix, from userid 1677) id 16E995C43; Fri, 27 Nov 2009 17:49:39 +0100 (CET) Date: Fri, 27 Nov 2009 17:49:39 +0100 From: Jilles Tjoelker To: Henner Morten Kruse Message-ID: <20091127164938.GB17211@stack.nl> References: <20091127081911.GA4254@tf.uni-kiel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091127081911.GA4254@tf.uni-kiel.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Workaround for ntop as daemon, is it ok? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 17:08:28 -0000 On Fri, Nov 27, 2009 at 09:19:11AM +0100, Henner Morten Kruse wrote: > I have just set up an ntop server based on 8.0-RELEASE. > FreeBSD ntop 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > After installing ntop 1.3.10 and all dependencies from the ports ntop > did work, but when running ntop as a daemon I got permanent and repeating > warning messages: > [warn] kevent: Bad file descriptor > [...] > I found out that ntop forks another thread for the daemon and kills the > initial one. The problem with this behaviour is that the kqueue is > started by the initial thread and the daemon thread doesn't use the > same file descriptors. So the kqueue is lost. That's a process, not a thread. > [...] > When I change the fork() in line 186 to rfork(RFPROC) everything works > and I get no more warning messages and procstat reports an existing > kqueue for the daemonized ntop: > So my question to this is: > Is my workaround ok or could this cause any problems? And what is the cause > of these warnings? Is it a bug or incapability in the kqueue implementation > or is it caused by bad code in ntop? Because it refers to other file descriptors, a kqueue is only really meaningful in the file descriptor table it was created in (this could be avoided for events that do not refer to file descriptors, and I think Solaris's "ports" system does that). As described in the kqueue(2) man page, calling rfork(2) without RFFDG will allow sharing the kqueue between the two processes. As long as the parent process exits quickly, or no "tricks" with file descriptor numbers are done, this is pretty safe. Another fix is to create the kqueue in the child process. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 19:08:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF86F1065670 for ; Fri, 27 Nov 2009 19:08:22 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mx1.freebsd.org (Postfix) with ESMTP id 6281D8FC1F for ; Fri, 27 Nov 2009 19:08:22 +0000 (UTC) Received: by ywh42 with SMTP id 42so1610516ywh.28 for ; Fri, 27 Nov 2009 11:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=8LdnOKB/Qibq9mnHSCMsVHnIFg+kmWTq312MKXIlUvU=; b=ago/ds/oDEJJByW1iwvVHd5zdabeeyYlu+KGAKQJZ56e3itU2MEf9+f0Z8je93hq3G RgY1c6NwSmJElMQNrDEH0OYhsYWCDcNPOyWabwKKIGE0VC0nDz0U3zlTgVO3vHXb/QKi V0AtTtLOq+21tYcpWUIOizOjqmRVJvSnBirpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=uomaWDcGj5LA01xoTBaQgqNldFLgwGE85vJXYsDoaGqw5q1bO1+mjBS4DWsl8m4ka8 0lt1vjNWWTo7gHYWnANs63vBE8EoXH5DRDT9XddqhCztNCuO7SDUMvwnynglNw3maHuQ lDwKb2BNUF/se56WhcKCQQhygU3NfTEtPDk6o= Received: by 10.150.7.6 with SMTP id 6mr2293182ybg.261.1259348900823; Fri, 27 Nov 2009 11:08:20 -0800 (PST) Received: from doormat.home (c-98-207-40-172.hsd1.ca.comcast.net [98.207.40.172]) by mx.google.com with ESMTPS id 6sm692950ywd.37.2009.11.27.11.08.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 11:08:19 -0800 (PST) Date: Fri, 27 Nov 2009 11:08:16 -0800 From: Navdeep Parhar To: "Bjoern A. Zeeb" Message-ID: <20091127190815.GA15536@doormat.home> Mail-Followup-To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <20091127084843.V37440@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091127084843.V37440@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: zero size set_pcpu linker sets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 19:08:22 -0000 On Fri, Nov 27, 2009 at 08:51:41AM +0000, Bjoern A. Zeeb wrote: > On Tue, 24 Nov 2009, Navdeep Parhar wrote: > > Hi, > > >objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu" > >section of size 0. Why? What is the difference between having a 0 > >sized set_pcpu vs. not having it at all? > > > >The kernel linker considers the alignment requirements of these empty > >sections and advances mapsize/mapbase. This bothers my kgdb (which is > >slightly modified to deal with amd64 KLDs). > > So what's your real problem? > I'm trying to read a KLD's globals etc. from its .bss and .data from within kgdb. It has a problem on amd64 that was discussed a long time back: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/026014.html The workaround I was using failed after the appearance of set_pcpu, and that made me look at the object file and the kernel linker code. I think there are two minor problems: a) There is an empty set_pcpu in the KLD when it shouldn't be there. b) The kernel linker doesn't ignore this section even though it's empty. It ends up advancing its location calculations because of the way it considers alignment requirements, even for empty sections. > > >I'm using the patch shown here as a stopgap measure. I think the correct > >fix is to not have these empty sections in the KLD to begin with. > > Right. The problem here is a bug with ld and linker sets and size and > aligment calculations the the elf section is started when not all of > this is known correctly and it's not fixed later. This came up with > that "netisr" bug where we had seen the misalignment of the dpcpu set. Yes, I remember that bug, and some of the changes that went in to fix it. Do you know why this empty set_pcpu shows up in most, but not all KLDs? I was hoping we could remove it from all the ones that don't really have any PCPU data. Regards, Navdeep From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 21:32:58 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854FB106568D; Fri, 27 Nov 2009 21:32:58 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFB88FC12; Fri, 27 Nov 2009 21:32:58 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.167.197]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id nARLHVST062941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 13:17:32 -0800 (PST) (envelope-from sobomax@sippysoft.com) Message-ID: <4B1041EB.9020109@sippysoft.com> Date: Fri, 27 Nov 2009 13:17:31 -0800 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Nov 2009 22:49:32 +0000 Cc: FreeBSD Hackers , stable@FreeBSD.ORG Subject: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 21:32:58 -0000 Hi, I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Here is my limits: Resource limits (current): cputime infinity secs filesize infinity kB datasize 2097152 kB stacksize 65536 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 5547 openfiles 20000 sbsize infinity bytes vmemoryuse infinity kB Running ktrace I see: 9154 java CALL mmap(0,0x44000000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0xffffffff,0,0) 9154 java RET mmap -1 errno 12 Cannot allocate memory 9154 java CALL write(0x1,0xbf9fe378,0x2b) 9154 java GIO fd 1 wrote 43 bytes "Error occurred during initialization of VM I made a small program that uses malloc(3) to allocate the same amount of memory, and that works nicely, ktrace reveals why: 10108 a.out CALL mmap(0,0x44000000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0) 10108 a.out RET mmap -1 errno 12 Cannot allocate memory 10108 a.out CALL break(0x4c100000) 10108 a.out RET break 0 So the question is: why does mmap() fails while essentially the same sbrk() request succeeds? This is really bad since, while native FreeBSD programs can work around this by using malloc(3), Linux programs and software that knows nothing about intricate details of the FreeBSD VM (i.e. Java) will fail miserably. I tried increasing vm.max_proc_mmap to 2147483647 from default 49344, but it did not do any good. mmap() still fails with the request of this size. I have seen several threads on the issue over the years, but still no resolution. It seems that only plausible solution is to limit heap size in java, which may not work for all cases. Funny thing is that the first sentence of the sbrk(2) manual page says: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. Yet, "legacy interfaces" seems to do much better job than "modern virtual memory management interfaces"! -Maxim From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 27 23:19:20 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 388E4106566B for ; Fri, 27 Nov 2009 23:19:20 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF948FC17 for ; Fri, 27 Nov 2009 23:19:20 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 3CD8828432; Fri, 27 Nov 2009 14:59:23 -0800 (PST) Message-ID: <4B1059CA.6040605@FreeBSD.org> Date: Fri, 27 Nov 2009 14:59:22 -0800 From: Jason Evans User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Maxim Sobolev References: <4B1041EB.9020109@sippysoft.com> In-Reply-To: <4B1041EB.9020109@sippysoft.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 23:19:20 -0000 Maxim Sobolev wrote: > I am trying to figure out why java fails to start with 1024MB of heap on > i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set > to 2GB. Some memory (1GiB?) is reserved for kernel address space, and you reserved 2GiB for DSS. That leaves less than 1GiB available after shared libraries and whatnot are mapped. If there is more than 1GiB available, mmap can still fail due to the memory being non-contiguous. Jason From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 00:02:18 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F6021065670 for ; Sat, 28 Nov 2009 00:02:18 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 21A9C8FC0A for ; Sat, 28 Nov 2009 00:02:17 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.167.197]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id nAS025Q4063941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 16:02:11 -0800 (PST) (envelope-from sobomax@sippysoft.com) Message-ID: <4B10687D.3050209@sippysoft.com> Date: Fri, 27 Nov 2009 16:02:05 -0800 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jason Evans References: <4B1041EB.9020109@sippysoft.com> <4B1059CA.6040605@FreeBSD.org> In-Reply-To: <4B1059CA.6040605@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 Nov 2009 01:11:08 +0000 Cc: FreeBSD Hackers Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 00:02:18 -0000 Jason Evans wrote: > Maxim Sobolev wrote: >> I am trying to figure out why java fails to start with 1024MB of heap >> on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are >> set to 2GB. > > Some memory (1GiB?) is reserved for kernel address space, and you > reserved 2GiB for DSS. That leaves less than 1GiB available after > shared libraries and whatnot are mapped. If there is more than 1GiB > available, mmap can still fail due to the memory being non-contiguous. Jason, So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself less than 1GB left to be allocated via mmap()? Perhaps the cause of the problem is my interpretation of MAXDSIZ as an overall limit of VM that the process will be able to allocate regardless of the memory management interface is wrong, and in fact the process can allocate up to MAXDSIZ using sbrk(2) and then some extra using mmap(2) up to 3GB? I tried lowering DFLDSIZ to 1.5GB, and it helped with Java. What is the best strategy if I want to maximize amount of memory available to applications? Most of modern applications use mmap(), isn't it? Then where MAXDSIZ can bite me if I set it to say 512MB? -Maxim From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 01:30:20 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E0E01065695 for ; Sat, 28 Nov 2009 01:30:20 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 006468FC19 for ; Sat, 28 Nov 2009 01:30:19 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 32FC22844E; Fri, 27 Nov 2009 17:30:18 -0800 (PST) Message-ID: <4B107D29.5030307@FreeBSD.org> Date: Fri, 27 Nov 2009 17:30:17 -0800 From: Jason Evans User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Maxim Sobolev References: <4B1041EB.9020109@sippysoft.com> <4B1059CA.6040605@FreeBSD.org> <4B10687D.3050209@sippysoft.com> In-Reply-To: <4B10687D.3050209@sippysoft.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 01:30:20 -0000 Maxim Sobolev wrote: > Jason Evans wrote: >> Maxim Sobolev wrote: >>> I am trying to figure out why java fails to start with 1024MB of heap >>> on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are >>> set to 2GB. >> >> Some memory (1GiB?) is reserved for kernel address space, and you >> reserved 2GiB for DSS. That leaves less than 1GiB available after >> shared libraries and whatnot are mapped. If there is more than 1GiB >> available, mmap can still fail due to the memory being non-contiguous. > > So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself > less than 1GB left to be allocated via mmap()? Yes, my recollection is that MAXDSIZ controls the amount of virtual address space dedicated to DSS, and this address space will not be mapped via anonymous mmap. I wanted to move completely away from using sbrk in malloc, but we can't completely remove DSS for backward compatibility reasons, which means less heap address space than would be ideal. > What is the > best strategy if I want to maximize amount of memory available to > applications? Most of modern applications use mmap(), isn't it? Then > where MAXDSIZ can bite me if I set it to say 512MB? I would set MAXDSIZ to 0, so that the maximum amount of memory is available for mapping shared libraries and files, and allocating via malloc. This may cause problems with a couple of ports that implement their own memory allocators based on sbrk, but otherwise it should be all good. You might also set /etc/malloc.conf to 'd' in order to disable the sbrk calls. Jason From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 02:22:41 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13D1E106566C; Sat, 28 Nov 2009 02:22:41 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id AFD538FC15; Sat, 28 Nov 2009 02:22:40 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.167.197]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id nAS2McaV064649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 18:22:39 -0800 (PST) (envelope-from sobomax@sippysoft.com) Message-ID: <4B10896E.3080201@sippysoft.com> Date: Fri, 27 Nov 2009 18:22:38 -0800 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jason Evans References: <4B1041EB.9020109@sippysoft.com> <4B1059CA.6040605@FreeBSD.org> <4B10687D.3050209@sippysoft.com> <4B107D29.5030307@FreeBSD.org> In-Reply-To: <4B107D29.5030307@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 Nov 2009 02:28:11 +0000 Cc: FreeBSD Hackers Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 02:22:41 -0000 Jason Evans wrote: > Maxim Sobolev wrote: >> Jason Evans wrote: >>> Maxim Sobolev wrote: >>>> I am trying to figure out why java fails to start with 1024MB of >>>> heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and >>>> DFLDSIZ are set to 2GB. >>> >>> Some memory (1GiB?) is reserved for kernel address space, and you >>> reserved 2GiB for DSS. That leaves less than 1GiB available after >>> shared libraries and whatnot are mapped. If there is more than 1GiB >>> available, mmap can still fail due to the memory being non-contiguous. >> >> So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself >> less than 1GB left to be allocated via mmap()? > > Yes, my recollection is that MAXDSIZ controls the amount of virtual > address space dedicated to DSS, and this address space will not be > mapped via anonymous mmap. I wanted to move completely away from using > sbrk in malloc, but we can't completely remove DSS for backward > compatibility reasons, which means less heap address space than would be > ideal. > >> What is the best strategy if I want to maximize amount of memory >> available to applications? Most of modern applications use mmap(), >> isn't it? Then where MAXDSIZ can bite me if I set it to say 512MB? > > I would set MAXDSIZ to 0, so that the maximum amount of memory is > available for mapping shared libraries and files, and allocating via > malloc. This may cause problems with a couple of ports that implement > their own memory allocators based on sbrk, but otherwise it should be > all good. You might also set /etc/malloc.conf to 'd' in order to > disable the sbrk calls. I see, thank you for the explanation. One of the problem that we are having is that we use a lot of interpreted languages in our environment (python, php etc), and most of those implement their own memory allocators, some of which rely on sbrk(2) unfortunately. I believe that's where that 2GB limit of ours comes from - one of our Python applications is very memory hungry and we had to bump that limit to allow it sufficient room. Crazy idea, perhaps, but has anyone considered wrapping up sbrk(2) into mmap(2), so that there is only one memory pool to draw from? Switch to 64-bit certainly helps, however there are lot of 32-bit machines hanging around and we will see them for a while in the embedded space. Certainly current situation with two separate sources of heap memory is not normal. -Maxim From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 10:39:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B2C51065670 for ; Sat, 28 Nov 2009 10:39:43 +0000 (UTC) (envelope-from andymac@bullseye.apana.org.au) Received: from ipmail02.adl6.internode.on.net (ipmail02.adl6.internode.on.net [203.16.214.140]) by mx1.freebsd.org (Postfix) with ESMTP id CE10F8FC23 for ; Sat, 28 Nov 2009 10:39:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoGAN+IEEt5LcZN/2dsb2JhbACBTZdiuT+EMQQ Received: from ppp121-45-198-77.lns20.cbr1.internode.on.net (HELO bullseye.apana.org.au) ([121.45.198.77]) by ipmail02.adl6.internode.on.net with ESMTP; 28 Nov 2009 20:54:22 +1030 Received: from [192.168.63.10] (tenring.andymac.org [192.168.63.10]) by bullseye.apana.org.au (8.14.2/8.14.2) with ESMTP id nASAPeQ4007378 for ; Sat, 28 Nov 2009 21:25:45 +1100 (EST) (envelope-from andymac@bullseye.andymac.org) Message-ID: <4B10F7DC.1080408@bullseye.andymac.org> Date: Sat, 28 Nov 2009 21:13:48 +1100 From: Andrew MacIntyre User-Agent: Thunderbird 2.0.0.23 (OS/2/20090822) MIME-Version: 1.0 To: FreeBSD Hackers References: <4B1041EB.9020109@sippysoft.com> <4B1059CA.6040605@FreeBSD.org> <4B10687D.3050209@sippysoft.com> <4B107D29.5030307@FreeBSD.org> <4B10896E.3080201@sippysoft.com> In-Reply-To: <4B10896E.3080201@sippysoft.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 10:39:43 -0000 Maxim Sobolev wrote: > Jason Evans wrote: >> I would set MAXDSIZ to 0, so that the maximum amount of memory is >> available for mapping shared libraries and files, and allocating via >> malloc. This may cause problems with a couple of ports that implement >> their own memory allocators based on sbrk, but otherwise it should be >> all good. You might also set /etc/malloc.conf to 'd' in order to >> disable the sbrk calls. > > I see, thank you for the explanation. One of the problem that we are > having is that we use a lot of interpreted languages in our environment > (python, php etc), and most of those implement their own memory > allocators, some of which rely on sbrk(2) unfortunately. I believe > that's where that 2GB limit of ours comes from - one of our Python > applications is very memory hungry and we had to bump that limit to > allow it sufficient room. While Python has its own allocator, it relies on the platform malloc() rather than sbrk(), and therefore Jason's suggestion to use '-d' in /etc/malloc.conf should be effective for it. -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 13:09:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3904D106566B; Sat, 28 Nov 2009 13:09:09 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by mx1.freebsd.org (Postfix) with ESMTP id 803B78FC13; Sat, 28 Nov 2009 13:09:08 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAGapEEtR8EdJ/2dsb2JhbACBTdB8hDEE Received: from 73.71-240-81.adsl-dyn.isp.belgacom.be (HELO kalimero.atlascopco.be) ([81.240.71.73]) by relay.skynet.be with ESMTP; 28 Nov 2009 13:39:39 +0100 Received: from kalimero.atlascopco.be (kalimero.atlascopco.be [127.0.0.1]) by kalimero.atlascopco.be (8.14.3/8.14.3) with ESMTP id nASCcruV002359; Sat, 28 Nov 2009 13:39:08 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: Maxim Sobolev Date: Sat, 28 Nov 2009 13:38:50 +0100 User-Agent: KMail/1.9.10 References: <4B1041EB.9020109@sippysoft.com> In-Reply-To: <4B1041EB.9020109@sippysoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911281338.53430.tijl@coosemans.org> Cc: FreeBSD Hackers , stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 13:09:09 -0000 On Friday 27 November 2009 22:17:31 Maxim Sobolev wrote: > I am trying to figure out why java fails to start with 1024MB of heap > on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are > set to 2GB. Here is my limits: > > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 2097152 kB > stacksize 65536 kB > coredumpsize infinity kB > memoryuse infinity kB > memorylocked infinity kB > maxprocesses 5547 > openfiles 20000 > sbsize infinity bytes > vmemoryuse infinity kB > > Running ktrace I see: > > 9154 java CALL mmap(0,0x44000000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0xffffffff,0,0) > 9154 java RET mmap -1 errno 12 Cannot allocate memory > 9154 java CALL write(0x1,0xbf9fe378,0x2b) > 9154 java GIO fd 1 wrote 43 bytes > "Error occurred during initialization of VM On i386 a process has only 3GiB of address space. If you reserve 2GiB for datasize (sbrk), there's less than 1GiB available for mmap. Unless you have a program that still uses sbrk and needs 2GiB you should make maxdsiz much smaller. Since FreeBSD 7 malloc can use mmap besides sbrk so you can set maxdsiz to a really small value if you want to. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 18:28:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DD3B106566B for ; Sat, 28 Nov 2009 18:28:05 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing03.lava.net (outgoing03.lava.net [IPv6:2001:1888:0:1:202:b3ff:fe1d:6b98]) by mx1.freebsd.org (Postfix) with ESMTP id 08B058FC12 for ; Sat, 28 Nov 2009 18:28:05 +0000 (UTC) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTP id 68436101C1; Sat, 28 Nov 2009 08:28:04 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id CBB69153882; Sat, 28 Nov 2009 08:28:03 -1000 (HST) Date: Sat, 28 Nov 2009 08:28:03 -1000 From: Clifton Royston To: freebsd-hackers@freebsd.org Message-ID: <20091128182803.GA13793@lava.net> Mail-Followup-To: freebsd-hackers@freebsd.org, Anthony Pankov References: <20091128120018.16D2C10656C7@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091128120018.16D2C10656C7@hub.freebsd.org> User-Agent: Mutt/1.4.2.2i Cc: Anthony Pankov Subject: Re: ucred when euid/egid X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 18:28:05 -0000 > Date: Fri, 27 Nov 2009 19:56:59 +0300 > From: Anthony Pankov > Subject: ucred when euid/egid > To: freebsd-hackers@freebsd.org > Message-ID: <15434604890.20091127195659@mail.ru> > Content-Type: text/plain; charset=us-ascii > > Hello, > > I face some misunderstood situation related to the access permissions. > > > There is a program(script) with the suid/sgid (mode 6555): > > r-sr-sr-x fuser:proggroup theprog > > There is a file: > rw-rw---- someone:filegroup thefile > > > User 'fuser' (==program euid) have primary group 'filegroup'(==group, > who can read/write thefile). > > Program try to read(write) thefile and fail with permissions. > > I don't fully understand why. There is no bug; when you use the suid/sgid facility, the program gains the effective user ID and/or the effective GID of the executable. It does *not* gain any gids which the effective user is added to at login. man seteuid for more info. In what you have shown, theprog has neither the same user (fuser vs. someone) nor the same group (proggroup vs. filegroup) as the file you want it to modify. For what you want to do to work correctly, you would need to either make theprog's ownership be: anyuser:filegroup or fuser:proggroup -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services