From owner-freebsd-stable@FreeBSD.ORG Sun Apr 26 07:08:25 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6F06CB0 for ; Sun, 26 Apr 2015 07:08:25 +0000 (UTC) Received: from asmtp01.netarrest.com (asmtp01.netarrest.com [67.228.24.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B283D1FAA for ; Sun, 26 Apr 2015 07:08:25 +0000 (UTC) Received: from Dell-Admin (p5B077667.dip0.t-ipconnect.de [91.7.118.103]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp01.netarrest.com (Postfix) with ESMTPSA id B959F990052 for ; Sun, 26 Apr 2015 02:08:21 -0500 (CDT) Reply-To: nights@sunrise.ch Message-ID: <88c762362ccd87400522164d001350b7@sunrise.ch> From: "Midsommar Festival 2015" To: Subject: Are you a DJ ? Date: Sun, 26 Apr 2015 09:05:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 07:08:25 -0000 If you have trouble reading this email, turn on the images, or [1]click here to read it online. [2][CDc4LAiWEAIEcWc.jpg] [3]Midsommar Festival returns to Switzerland for the 5th year and we are searching the planet for the best talented DJ to join the festival for a spotlight performance on this edition in Lucerne. If you think you have what it takes, then upload your best 30 minutes DJ set via Mixcloud or SoundCloud. One talented and lucky winner will get the chance to perform at the Midsommar Festival, with some of the most relevant and talented acts coming from many different countries. The Midsommar Team will cover roundtrip flights and accommodation in Lucerne, Switzerland. The final line-up will be announced soon and maybe with your name on the roster?! This is a unique chance to be part of an incredible festival with artists coming from all around the world. [4][CDc7yZfWAAAmKQ7.jpg] How to Enter: The competition is open to European residents only. * Open a SoundCloud or MixCloud account in case you don't have one. * Upload a mix of no more than 30 minutes. * Title the mix Midsommar Recruits [Your DJ Name] * Tag your mix Midsommar Recruits if you fail to tag it correctly, your mix may be missed * Include the competition cover-art, provided [5]here. * Spread it around and share it to your friends and fans to collect likes. Judging: * The top 20 most 'liked' mixes that are uploaded on Mixcloud or SoundCloud and tagged with 'Midsommar Recruits' will get shortlisted. * Only the mixes with at least 50 plays by the deadline date can qualify in the top 20. * The artists of the Festival and the Midsommar Crew will review each of these 20 mixes and select the 10 finalists. * The finalists will publish the mix or cover of the festival in their own facebook accounts and will collect as much likes, shares and comments they can. The mix or cover with more activity will perform at the Midsommar Festival 2015, with some of the most important artists of the industry. If you dont want to receive our newsletters anymore, please [6]click here This e-mail including any attachments is confidential and may be legally privileged. If you have received it in error please advise the sender immediately. The unauthorised use, distribution, copying or alteration of this email is strictly forbidden. Su dirección de email ha sido recopilada de fuentes de público acceso en Internet. Conforme a la Directiva Europea 2002/58/EC y la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones, vd. tiene el derecho a oponerse a que sus datos personales se utilicen para fines publicitarios y de marketing. Si este es su deseo, le rogamos pulse [7]darse de baja y automaticamente dejará de recibir comunicaciones publicitarias por nuestra parte. CONFIDENCIALIDAD: La información contenida en este mensaje y/o archivo(s) adjunto(s) es confidencial/privilegiada y está destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el destinatario señalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicación por error, le informamos que está totalmente prohibida, y puede ser ilegal, cualquier divulgación, distribución o reproducción de esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la dirección arriba mencionada. Gracias. VIRUS: Aunque hemos tomado las medidas para asegurarnos que este correo electrónico y sus ficheros adjuntos están libres de virus, le recomendamos que a efectos de mantener buenas prácticas de seguridad, el receptor debe asegurarse que este correo y sus ficheros adjuntos están libres de virus. References 1. http://t.co/wgiYtRQ00V 2. http://t.co/wgiYtRQ00V 3. http://t.co/wgiYtRQ00V 4. http://t.co/wgiYtRQ00V 5. http://pbs.twimg.com/media/CDc4LAiWEAIEcWc.jpg:large 6. http://iTiny.net/852727 7. http://iTiny.net/852727 From owner-freebsd-stable@FreeBSD.ORG Sun Apr 26 15:29:31 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99D67E81 for ; Sun, 26 Apr 2015 15:29:31 +0000 (UTC) Received: from mail.sundivenetworks.net (mail.sundivenetworks.net [212.13.212.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61B3611C7 for ; Sun, 26 Apr 2015 15:29:31 +0000 (UTC) Received: from static45-91.adsl.bogons.net ([85.158.45.91] helo=[192.168.1.121]) by mail.sundivenetworks.net with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YmOUk-000C57-DF; Sun, 26 Apr 2015 16:29:22 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061) From: Will Green In-Reply-To: <55367EA2.4090800@multiplay.co.uk> Date: Sun, 26 Apr 2015 16:29:22 +0100 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <155EC358-9733-476E-8240-CC53D6EAB910@sundivenetworks.com> References: <2F473FFD-108D-428B-B2E1-511AA3F754B0@sundivenetworks.com> <55367EA2.4090800@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.2098) X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam: No X-bounce-key: sundivenetworks.net-1; will@sundivenetworks.com; 1430062171; 644f90cf; X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 15:29:31 -0000 Thanks Steven. I=E2=80=99ll hold off releasing the updated tutorials for = now. > On 21 Apr 2015, at 17:45, Steven Hartland = wrote: >=20 > I did actually request this back in November, but I don't seem to have = had a reply so I'll chase. >=20 > On 21/04/2015 16:23, Will Green wrote: >> Hello, >>=20 >> I have been updating my ZFS tutorials for use on FreeBSD 10.1. To = allow users to experiment with ZFS I use file-backed ZFS pools. On = FreeBSD 10.1 they cause a kernel panic. >>=20 >> For example a simple command like the following causes a panic: zpool = create /tmp/zfstut/disk1 >>=20 >> This issue was identified in PR 195061: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195061 >> And fixed in r274619 (2014-11-17): = https://svnweb.freebsd.org/base?view=3Drevision&revision=3D274619 >>=20 >> However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but = doesn=E2=80=99t on 11-CURRENT). >>=20 >> Are there any plans to patch this in 10.1? I note it=E2=80=99s not in = the errata. >>=20 >> My tutorials are not the only ones that use file-backed ZFS: new = users experimenting with ZFS on FreeBSD are likely to encounter this = issue. >>=20 >> Thanks, >> Will >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Apr 26 16:46:34 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69F9DFAC for ; Sun, 26 Apr 2015 16:46:34 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06718196D for ; Sun, 26 Apr 2015 16:46:33 +0000 (UTC) Received: by widdi4 with SMTP id di4so66615145wid.0 for ; Sun, 26 Apr 2015 09:46:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZsVBrqY9Kgn55WtI3S8AbH/88UoDSLJA9WN548GKEx4=; b=AfcbszisvChzMr2EKkgJF2TmSJA/T+r/a2qJHAkaN41YeVgavfRTHSh1Wn7fzqNipZ bUetdZYNEXoWPTo2WMI0mZe8DSRk8MZbJBe6HCo2V8J5pcdvXwEwGjRoFw2S4NRE5Ixt DxXKbavzshX6Ss9Iw9bQg569WVjbp/UCTA0wwEFLSbBZnFq4wAlLxF/FodGSNAO1Ffd1 jEzT0cSNqawz/bJU9+ZoScffErFZRBZNzAMFOXF1Nj7xZEl6srwxvDc+k20bEkMYvei9 OUwqWZyBLEzUpmZICdz7PJRt3Is3coYTJvr+onTWz2aiw0vMSJLbQpqtWQkv3z812lBB 9CNQ== X-Gm-Message-State: ALoCoQmkfaPt5Yo75VeEAAcnwsbBrcuoIdv3NhdKx3S+vQV8N9ZnaHDiLz/CAA5aojAs3mF1wesL X-Received: by 10.180.102.228 with SMTP id fr4mr13507948wib.4.1430066786023; Sun, 26 Apr 2015 09:46:26 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id y7sm11708428wjw.16.2015.04.26.09.46.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 09:46:25 -0700 (PDT) Message-ID: <553D165F.4030809@multiplay.co.uk> Date: Sun, 26 Apr 2015 17:46:23 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Will Green CC: freebsd-stable@freebsd.org Subject: Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061) References: <2F473FFD-108D-428B-B2E1-511AA3F754B0@sundivenetworks.com> <55367EA2.4090800@multiplay.co.uk> <155EC358-9733-476E-8240-CC53D6EAB910@sundivenetworks.com> In-Reply-To: <155EC358-9733-476E-8240-CC53D6EAB910@sundivenetworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 16:46:34 -0000 Looks like it got lost in the tubes, sitting with me to get info across to re@ On 26/04/2015 16:29, Will Green wrote: > Thanks Steven. I’ll hold off releasing the updated tutorials for now. > >> On 21 Apr 2015, at 17:45, Steven Hartland wrote: >> >> I did actually request this back in November, but I don't seem to have had a reply so I'll chase. >> >> On 21/04/2015 16:23, Will Green wrote: >>> Hello, >>> >>> I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause a kernel panic. >>> >>> For example a simple command like the following causes a panic: zpool create /tmp/zfstut/disk1 >>> >>> This issue was identified in PR 195061: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 >>> And fixed in r274619 (2014-11-17): https://svnweb.freebsd.org/base?view=revision&revision=274619 >>> >>> However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but doesn’t on 11-CURRENT). >>> >>> Are there any plans to patch this in 10.1? I note it’s not in the errata. >>> >>> My tutorials are not the only ones that use file-backed ZFS: new users experimenting with ZFS on FreeBSD are likely to encounter this issue. >>> >>> Thanks, >>> Will >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Apr 27 18:42:42 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A866F4 for ; Mon, 27 Apr 2015 18:42:42 +0000 (UTC) Received: from b192.virtualtarget.com.br (b192.virtualtarget.com.br [187.61.28.192]) by mx1.freebsd.org (Postfix) with ESMTP id 023201B3A for ; Mon, 27 Apr 2015 18:42:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=dkim.vttrack.com.br; h=From:To:Subject:MIME-Version:Content-Type:Reply-To:List-Unsubscribe:Message-ID:Date; bh=XzyknKNCxirTwc0NLdoaWMQwL7Q=; b=coqB895HEZRkvL/IzQgMYSz2w3RO1i5z9EyP7xzP/ciwFHC/LJ9BVuLhA5D6N+C4/X6zpblSkgsC uhbVTP/R7lr+bnlKiRo68ixs1aiu8DJdxMnmPRO3HhIxqGtxGplgX0QpZjqUM8Jls8PAGvNNX5CD NPkTHFKDZKrRvvy5hQo= Received: by b192.virtualtarget.com.br id h7q17q0sh4s5 for ; Mon, 27 Apr 2015 15:36:45 -0300 (envelope-from ) From: "Abese" To: "" Subject: =?UTF-8?B?VEVDU0hPVyAyMDE1IOKAkyBEaXZ1bGd1ZSBzZXVzIHByb2R1dG9zIGNvbSBjdXM=?= =?UTF-8?B?dG8gemVybyE=?= MIME-Version: 1.0 Reply-To: "Abese" X-Hash: 21805-66-1841768-c5cb3f682f42aee1e17006fe852fe8c6 X-DMA: 24798129 Message-ID: <0.1.DA.D24.1D081191CBF21AA.60CF@b192.virtualtarget.com.br> Date: Mon, 27 Apr 2015 15:39:57 -0300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 18:42:42 -0000 exposec-tecshow Um produto Fiera Milano, a feira re=FAne os melhores profissionais do setor. Venha conhecer o que o mercado tem de melhor para oferecer. [ vers=E3o online [http://trk.envio.cafec.com.br/index.dma/DmaPreview?21805.66.1841768= .c5cb3f682f42aee1e17006fe852fe8c6.1] ] [ descadastrar [http://trk.envio.caf= ec.com.br/index.dma/DmaOptOut?21805,66,1841768,c5cb3f682f42aee1e17006fe852f= e8c6,1] ]=20 [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,953,c5cb= 3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.exposec.tmp.br/?ut= m_source=3DVirtual_Target&utm_medium=3DEmail&utm_content=3D&utm_campaign=3D= exposec-tecshow"> 12 a 14 de Maio de 2015=20 S=E3o Paulo Expo Exhibition " width=3D"319" /> Atendimento: +55 11 5585 4355 | info@fieramilano.com.br [mailto:info@fieramilano.com.br]=20 Ir para o site[http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,953,= c5cb3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.exposec.tmp.br= /?utm_source=3DVirtual_Target&utm_medium=3DEmail&utm_content=3D&utm_campaig= n=3Dexposec-tecshow" width=3D"13" /> Sobre a feira[http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,954= ,c5cb3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.exposec.tmp.b= r/sobre-a-feira/?utm_source=3DVirtual_Target&utm_medium=3DEmail&utm_content= =3D&utm_campaign=3Dexposec-tecshow" width=3D"13" /> Perfil do visitante[http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768= ,955,c5cb3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.exposec.t= mp.br/perfil-do-visitante/?utm_source=3DVirtual_Target&utm_medium=3DEmail&u= tm_content=3D&utm_campaign=3Dexposec-tecshow" width=3D"13" /> Quero expor[http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,956= ,c5cb3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.exposec.tmp.b= r/quero-expor/?utm_source=3DVirtual_Target&utm_medium=3DEmail&utm_content= =3D&utm_campaign=3Dexposec-tecshow" width=3D"13" /> Credenciamento[http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,18= 41768,957,c5cb3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.mbxe= ventos.com/AOLExposec/content/Bienvenida.aspx?utm_source=3DVirtual_Target&u= tm_medium=3DEmail&utm_content=3D&utm_campaign=3Dexposec-tecshow" width=3D"13" /> [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,962,c5cb= 3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]https://www.facebook.com/Expo= secBrasil?utm_source=3DVirtual_Target&utm_medium=3DEmail&utm_content=3D&utm= _campaign=3Dexposec-tecshow font-size:20px; color:#334d81; text-decoration:none;">=20 [mailto:dalva@abese.org.br]=20 M=CDDIAS SOCIAIS=20 [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,962,c5cb= 3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]https://www.facebook.com/Expo= secBrasil?utm_source=3DVirtual_Target&utm_medium=3DEmail&utm_content=3D&utm= _campaign=3Dexposec-tecshow" width=3D"20" />[http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,963,c5= cb3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]https://www.youtube.com/pla= ylist?list=3DPLyM3_ohTBBzlAMaFJXT_weAcxv0WHfU_F&utm_source=3DVirtual_Target= &utm_medium=3DEmail&utm_content=3D&utm_campaign=3Dexposec-tecshow" width=3D"20" />[mailto:info@fieramilano.com.br] RECEBA NOSSA NEWSLETTER[mailto:info@fieramilano.com.br]=20 MAIS INFORMA=C7=D5ES=20 +55 11 5585 4355=20 info@fieramilano.com.br [mailto:info@fieramilano.com.br]=20 www.fieramilano.com.br [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,958,c5cb= 3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.fieramilano.com.br= ?utm_source=3DVirtual_Target&utm_medium=3DEmail&utm_content=3D&utm_campaign= =3Dexposec-tecshow" valign=3D"middle"> REALIZA=C7=C3O=20 [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,959,c5cb= 3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.abese.org.br/?utm_= source=3DVirtual_Target&utm_medium=3DEmail&utm_content=3D&utm_campaign=3Dex= posec-tecshow" valign=3D"middle"> PROMO=C7=C3O E ORGANIZA=C7=C3O=20 [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,958,c5cb= 3f682f42aee1e17006fe852fe8c6,[DMA6_ENCODE_URL]http://www.fieramilano.com.br= ?utm_source=3DVirtual_Target&utm_medium=3DEmail&utm_content=3D&utm_campaign= =3Dexposec-tecshow font-size:10px; color:#777777;">Uma feira f=EDliada a Ubrafe [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,960,c5cb= 3f682f42aee1e17006fe852fe8c6,aHR0cDovL3d3dy51YnJhZmUub3JnLmJyLz91dG1fc291cm= NlPVZpcnR1YWxfVGFyZ2V0JnV0bV9tZWRpdW09RW1haWwmdXRtX2NvbnRlbnQ9JnV0bV9jYW1wY= Wlnbj1leHBvc2VjLXRlY3Nob3cmdXRtX3Rlcm09,1,ZnJlZWJzZC5vcmc=3D] e UFI [http://trk.envio.cafec.com.br/index.dma/DmaClick?21805,66,1841768,961,c5cb= 3f682f42aee1e17006fe852fe8c6,aHR0cDovL3d3dy51Zmkub3JnLz91dG1fc291cmNlPVZpcn= R1YWxfVGFyZ2V0JnV0bV9tZWRpdW09RW1haWwmdXRtX2NvbnRlbnQ9JnV0bV9jYW1wYWlnbj1le= HBvc2VjLXRlY3Nob3cmdXRtX3Rlcm09,1,ZnJlZWJzZC5vcmc=3D]. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 28 09:51:20 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E6EB254 for ; Tue, 28 Apr 2015 09:51:20 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31AD5129F for ; Tue, 28 Apr 2015 09:51:19 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Yn2AT-00063F-Jl for freebsd-stable@freebsd.org; Tue, 28 Apr 2015 11:51:10 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: protecting some processes from out-of-swap killer References: <20150425104336.GD13141@ivaldir.etoilebsd.net> Date: Tue, 28 Apr 2015 11:51:03 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40, URIBL_BLOCKED autolearn=disabled version=3.3.2 X-Scan-Signature: 2ecd0b53b7de9511489f92806276a3d7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 09:51:20 -0000 On Sat, 25 Apr 2015 13:15:32 +0200, Dmitry Morozovsky wrote: > On Sat, 25 Apr 2015, Baptiste Daroussin wrote: > >> > However, sometimes postgres processes got killed by 'out of swap >> space'. >> > I suppose the source of problem could be that VSZ size of postgres >> processes >> > (8-9 G) is bigger than swap congigured (4G). >> > >> > Is there any way to prevent this, besides reallocating space for swap? >> >> protect(1) ? > > Of course. I really do not understand how google hides the man page > from me. > > Thanks, and sorry fot the noise. > The OS trying to kill a process is probably not what you want. So when you protect(1) postgres the OS will kill another process, which I hope is not running without reason. My advice would be to - or increase your swap space - or tune postgresql to use less memory - or limit tmpfs (tmpfs uses swap if RAM is short) - or tune zfs to use less memory Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 28 10:11:36 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 466A98D4 for ; Tue, 28 Apr 2015 10:11:36 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD4DD162F for ; Tue, 28 Apr 2015 10:11:34 +0000 (UTC) Received: from localhost ([83.205.11.192]) by mwinf5d34 with ME id MNBX1q00E48cfiB03NBX36; Tue, 28 Apr 2015 12:11:32 +0200 X-ME-Helo: localhost X-ME-Date: Tue, 28 Apr 2015 12:11:32 +0200 X-ME-IP: 83.205.11.192 Message-ID: <553F5CD2.5020604@orange.fr> Date: Tue, 28 Apr 2015 12:11:30 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: stable@freebsd.org, current@freebsd.org Subject: VT+KVM: is there a way to disable video output on a given connector ? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 10:11:36 -0000 Hello, I have an old Dell Inspirao 9300 with a Radeon video card, which I use to do some tests. This computer has a screen (1920x1200) in very bad state, so I use it with an external display (1920x1080), switching to the external by a special key combination (Fn+F8). This works OK when the video is in alphanumeric mode, that is with syscons. But with the video in graphics mode, both screens are used. Under X, the output to the internal screen may be suppressed with xrandr. But with vt I have not found any documented tunable/sysctl to achieve the same effect (I already use the kern.vt.fb.default_mode tunable to force the resolution). Thanks for your attention, CBu From owner-freebsd-stable@FreeBSD.ORG Tue Apr 28 12:38:12 2015 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AD044AD for ; Tue, 28 Apr 2015 12:38:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 249C9170E for ; Tue, 28 Apr 2015 12:38:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3SCcC3Y007282 for ; Tue, 28 Apr 2015 12:38:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Tue, 28 Apr 2015 12:38:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: rea@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 12:38:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 --- Comment #18 from commit-hook@freebsd.org --- A commit references this bug: Author: dumbbell Date: Tue Apr 28 12:37:10 UTC 2015 New revision: 282141 URL: https://svnweb.freebsd.org/changeset/base/282141 Log: DRM2: fix off-by-one overflow in ioctl processing Call to the driver-specific ioctl used to process ioctl number that will lead to the out-of-bounds access to the ioctl handler array. PR: 193367 Approved by: kib MFC of: r275209 (original commit by rea) Changes: _U stable/10/ stable/10/sys/dev/drm2/drm_drv.c -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 28 13:19:52 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF79D372 for ; Tue, 28 Apr 2015 13:19:52 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A4F541C2E for ; Tue, 28 Apr 2015 13:19:52 +0000 (UTC) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 279215B0; Tue, 28 Apr 2015 09:11:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: protecting some processes from out-of-swap killer From: Paul Mather In-Reply-To: Date: Tue, 28 Apr 2015 09:11:51 -0400 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <95EED247-A571-43A4-9FAA-822118B5B8F1@gromit.dlib.vt.edu> References: <20150425104336.GD13141@ivaldir.etoilebsd.net> To: Ronald Klop X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:19:52 -0000 On Apr 28, 2015, at 5:51 AM, Ronald Klop wrote: > On Sat, 25 Apr 2015 13:15:32 +0200, Dmitry Morozovsky = wrote: >=20 >> On Sat, 25 Apr 2015, Baptiste Daroussin wrote: >>=20 >>> > However, sometimes postgres processes got killed by 'out of swap = space'. >>> > I suppose the source of problem could be that VSZ size of postgres = processes >>> > (8-9 G) is bigger than swap congigured (4G). >>> > >>> > Is there any way to prevent this, besides reallocating space for = swap? >>>=20 >>> protect(1) ? >>=20 >> Of course. I really do not understand how google hides the man page = from me. >>=20 >> Thanks, and sorry fot the noise. >>=20 >=20 >=20 > The OS trying to kill a process is probably not what you want. So when = you protect(1) postgres the OS will kill another process, which I hope = is not running without reason. > My advice would be to > - or increase your swap space > - or tune postgresql to use less memory > - or limit tmpfs (tmpfs uses swap if RAM is short) > - or tune zfs to use less memory That is good advice, although I do think "protect" has its place for = preventing unforeseen accidents as mentioned above. I believe it's good = to be able to designate certain processes as more valuable than others = if you know that to be the case. A case in point: We have an Omeka instance on a fairly low-resource = system. Omeka uses ImageMagick to generate thumbnails for items added = to collections. In one case, we had a very large TIFF file added, who, = when having a thumbnail generated, caused its thumbnail-generating = process to consume large amounts of memory and swap. When swap was = exhausted, the OS decided it needed to kill off something and settled = upon Apache (under which Omeka runs), causing Omeka to stop running. In = other times, the out-of-swap killer has chosen to kill the SSH daemon, = making it harder subsequently to access the box and fix problems. Being able to protect httpd---or even just sshd---served as a handy = safety belt after that happened. :-) I guess the proper way to address this would be to set limits on Apache = or the thumbnail generation so it doesn't go hog wild in the future... Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 29 17:27:02 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F2AAA15 for ; Wed, 29 Apr 2015 17:27:02 +0000 (UTC) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB4421D9A for ; Wed, 29 Apr 2015 17:27:01 +0000 (UTC) Received: from webmail.ee.ryerson.ca (eccles [172.16.1.2]) by eccles.ee.ryerson.ca (8.14.9/8.14.9) with ESMTP id t3TH94PG063726; Wed, 29 Apr 2015 13:09:04 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Received: from 206.108.127.2 (SquirrelMail authenticated user dmagda) by webmail.ee.ryerson.ca with HTTP; Wed, 29 Apr 2015 13:09:05 -0400 Message-ID: <61abe503a5bc8550e1413fd1933bea62.squirrel@webmail.ee.ryerson.ca> In-Reply-To: References: <20150425104336.GD13141@ivaldir.etoilebsd.net> Date: Wed, 29 Apr 2015 13:09:05 -0400 Subject: Re: protecting some processes from out-of-swap killer From: "David Magda" To: "Ronald Klop" Cc: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (eccles.ee.ryerson.ca [172.16.1.2]); Wed, 29 Apr 2015 13:09:05 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:27:02 -0000 On Tue, April 28, 2015 05:51, Ronald Klop wrote: > The OS trying to kill a process is probably not what you want. So when you > protect(1) postgres the OS will kill another process, which I hope is not > running without reason. > My advice would be to > - or increase your swap space > - or tune postgresql to use less memory > - or limit tmpfs (tmpfs uses swap if RAM is short) > - or tune zfs to use less memory Personally I didn't even know FreeBSD had an OOM killer. I regularly run into Linux's though, but that's because by default Linux allows over-committing of memory. I was under the impression that FreeBSD did not over-subscribe memory, and so would not allow a process to do a malloc() unless there was enough RAM+swap to satisfy it. Is this a mistaken assumption? (I probably have to buy the McKusick, Neville-Neil, Watson book.) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 30 08:59:49 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A22427C7 for ; Thu, 30 Apr 2015 08:59:49 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6360F1614 for ; Thu, 30 Apr 2015 08:59:48 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YnkJi-0006tz-2y; Thu, 30 Apr 2015 10:59:39 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "David Magda" Cc: freebsd-stable@freebsd.org Subject: Re: protecting some processes from out-of-swap killer References: <20150425104336.GD13141@ivaldir.etoilebsd.net> <61abe503a5bc8550e1413fd1933bea62.squirrel@webmail.ee.ryerson.ca> Date: Thu, 30 Apr 2015 10:59:32 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <61abe503a5bc8550e1413fd1933bea62.squirrel@webmail.ee.ryerson.ca> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40, URIBL_BLOCKED autolearn=disabled version=3.3.1 X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 08:59:49 -0000 On Wed, 29 Apr 2015 19:09:05 +0200, David Magda wrote: > On Tue, April 28, 2015 05:51, Ronald Klop wrote: > >> The OS trying to kill a process is probably not what you want. So when >> you >> protect(1) postgres the OS will kill another process, which I hope is >> not >> running without reason. >> My advice would be to >> - or increase your swap space >> - or tune postgresql to use less memory >> - or limit tmpfs (tmpfs uses swap if RAM is short) >> - or tune zfs to use less memory > > Personally I didn't even know FreeBSD had an OOM killer. I regularly run > into Linux's though, but that's because by default Linux allows > over-committing of memory. > > I was under the impression that FreeBSD did not over-subscribe memory, > and > so would not allow a process to do a malloc() unless there was enough > RAM+swap to satisfy it. > > Is this a mistaken assumption? (I probably have to buy the McKusick, > Neville-Neil, Watson book.) > > See sysctl vm.overcommit, which is also documented here: https://wiki.freebsd.org/SystemTuning and in man tuning(7). Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 30 13:51:05 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7AE8D56 for ; Thu, 30 Apr 2015 13:51:05 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 915831BFB for ; Thu, 30 Apr 2015 13:51:05 +0000 (UTC) Received: by be-well.ilk.org (Postfix, from userid 1147) id 4EFBC33C24; Thu, 30 Apr 2015 09:51:04 -0400 (EDT) From: Lowell Gilbert To: "David Magda" Cc: freebsd-stable@freebsd.org Subject: Re: protecting some processes from out-of-swap killer References: <20150425104336.GD13141@ivaldir.etoilebsd.net> <61abe503a5bc8550e1413fd1933bea62.squirrel@webmail.ee.ryerson.ca> Reply-To: freebsd-stable@freebsd.org Date: Thu, 30 Apr 2015 09:51:04 -0400 In-Reply-To: <61abe503a5bc8550e1413fd1933bea62.squirrel@webmail.ee.ryerson.ca> (David Magda's message of "Wed, 29 Apr 2015 13:09:05 -0400") Message-ID: <44iocdpvw7.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:51:05 -0000 "David Magda" writes: > On Tue, April 28, 2015 05:51, Ronald Klop wrote: > >> The OS trying to kill a process is probably not what you want. So when you >> protect(1) postgres the OS will kill another process, which I hope is not >> running without reason. >> My advice would be to >> - or increase your swap space >> - or tune postgresql to use less memory >> - or limit tmpfs (tmpfs uses swap if RAM is short) >> - or tune zfs to use less memory > > Personally I didn't even know FreeBSD had an OOM killer. I regularly run > into Linux's though, but that's because by default Linux allows > over-committing of memory. > > I was under the impression that FreeBSD did not over-subscribe memory, and > so would not allow a process to do a malloc() unless there was enough > RAM+swap to satisfy it. > > Is this a mistaken assumption? (I probably have to buy the McKusick, > Neville-Neil, Watson book.) Yes, that is a mistaken assumption; any system that supports fork(2) pretty much has to do memory overcommit or make terribly inefficient use of its memory. Overcommit is irrelevant to your problem, though. You have processes that are using more virtual memory than the system has. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 30 18:37:59 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1267E294 for ; Thu, 30 Apr 2015 18:37:59 +0000 (UTC) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBD0B1D0F for ; Thu, 30 Apr 2015 18:37:57 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 5773715D4 for ; Thu, 30 Apr 2015 14:28:17 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Thu, 30 Apr 2015 14:28:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/X9GyG98fPh7/w1 T7L3SpfXl15A=; b=LvcHKocv/KsiZf+pv0WTZWYq23DhsEGGUwvTF4reAuCc7R1 KvkBvXDnLJDmcClKFYKfYkSI+UvvRElqXyLnpv915k22/FUpjot311WqJhmU7k8k Z3nN/EoLC/g5zG6G1MiT/oSMoMmfUde86ElygQK3/f/hhDatcCQ+JZJPR+zU= Received: by web3.nyi.internal (Postfix, from userid 99) id 12FAC1079D9; Thu, 30 Apr 2015 14:28:17 -0400 (EDT) Message-Id: <1430418497.3253201.261134645.7FB30850@webmail.messagingengine.com> X-Sasl-Enc: alQlvRvgU0ndsjJwq0nCXyT2yB6Gqgj7EjeEyCKE27q4 1430418497 From: Mark Felder To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-f5f4dd6c Subject: Re: protecting some processes from out-of-swap killer Date: Thu, 30 Apr 2015 13:28:17 -0500 In-Reply-To: <20150425104336.GD13141@ivaldir.etoilebsd.net> References: <20150425104336.GD13141@ivaldir.etoilebsd.net> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 18:37:59 -0000 On Sat, Apr 25, 2015, at 05:43, Baptiste Daroussin wrote: > On Sat, Apr 25, 2015 at 01:31:14PM +0300, Dmitry Morozovsky wrote: > > Hi there colleagues, > > > > I have stable/10 on a rather big machine (2*8*2 e5 Xeon, 64G RAM, SAS+SSD ZFS > > raid10+ZIL+L2ARC) acting as a PostgreSQL server. > > > > To use such a big resource pool that is mostly idle, I'd deployed poudriere > > there (using tmpfs) too. > > > > Most times this combination works like a charm: LA could be 60+ and no visual > > latency increase on SQL queries. > > > > However, sometimes postgres processes got killed by 'out of swap space'. > > I suppose the source of problem could be that VSZ size of postgres processes > > (8-9 G) is bigger than swap congigured (4G). > > > > Is there any way to prevent this, besides reallocating space for swap? > > > > Quick googling does not help, at least I could not find answers relevant > > enough. > > > > Thanks! > > protect(1) ? > Thanks for asking, Dmitry, as I've now learned of a new useful command. It appears it has only been around a short time: > Added Thu Sep 19 18:53:42 2013 UTC (19 months, 1 week ago) by jhb Very cool. :-) From owner-freebsd-stable@FreeBSD.ORG Sat May 2 17:15:52 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B29ADB1 for ; Sat, 2 May 2015 17:15:52 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F1ED1E40 for ; Sat, 2 May 2015 17:15:51 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so43841325igb.0 for ; Sat, 02 May 2015 10:15:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9PhS7laptL7NPWyfL36rkzxRAg45K6gkzq5UEWmcx7g=; b=Yu3Nn/ITrcNjkEGbhMJxb+pu6MItlb2Rtk32iVgVdsczHx98EEDtsX8zyo64zr5X0X WgZVnhZJz5ur56Sis2wyEL8IG7usLLrijb6Y3zASf+wURlJSLjsuWqOPXqMZCFZvTUlp Ok1jtAX2yiHIfY0IS3YRhj4fufhAvlsq/6qWqFVAWC0HoFbT8K5L7Lxh4JNejQEwex6r dvDJBgYrtnGZE2TuWJ+/wjkOJPxCYQvrI2Ovbcwj+v65e8e5G1lnmhSHeFF+HLMgEDAK XSbAeTg4crLkhl6VR/TnI3U1g2WxmzZ50L1Uh9BUTPQ9XVTvLc2xNjhXNilRcIkwIdyb xGeg== X-Gm-Message-State: ALoCoQlW5aAkB212b7j+Kj+Tx+jzipS5DDQK4E1a1YVJaUyiOqCL4+ydDIEt5AJdEu0eu+0+Molx MIME-Version: 1.0 X-Received: by 10.43.60.76 with SMTP id wr12mr20510579icb.83.1430586944778; Sat, 02 May 2015 10:15:44 -0700 (PDT) Received: by 10.79.11.6 with HTTP; Sat, 2 May 2015 10:15:44 -0700 (PDT) Date: Sat, 2 May 2015 19:15:44 +0200 Message-ID: Subject: include/rpcsvc - mkdir: /usr/obj/lib32: Permission denied From: Oliver Pinter To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 17:15:52 -0000 Hi all! I try to build a modified 10-STABLE with jenkins, but I got the error in the subject. You can find the full build log under this link: http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-10-experimental-amd64/1/console If you need more info, please ping me, or write to core@hardenedbsd.org . Thanks you, Oliver From owner-freebsd-stable@FreeBSD.ORG Sat May 2 18:20:12 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12708CB1 for ; Sat, 2 May 2015 18:20:12 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9FA113CF for ; Sat, 2 May 2015 18:20:11 +0000 (UTC) Received: by iecrt8 with SMTP id rt8so107396443iec.0 for ; Sat, 02 May 2015 11:20:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9J9gRHEh/9xUSJ66J7+5c2dTCIIE6PngKKqCXeTLSN4=; b=NgaS3l4OM8ML74kLXH5ag9MHKpHuMXkcEzm09q/G23QmKBNCG4NdxDDqh9GmqX1/yY xpegov77yJ4Ni2bBQ0DQEbkESuwljvx+bgB8R0+E8Cm1bfgBrLon+wJtvPnhmyUyUYaL i/OLlfRAiJRVP9a17qf/Dcw92TSR7q1Z0Xveoocc+57yNmJtpmJFXQsxa0VQILb9PI1y wguwKnV39vY/b7+2H48lAzDIKZZgmgOrECdlBxb2FkIP1idqf3cHEQ2WwNNf8UgX8TEl N+Ut/cl2ya71LSJ/R+f5VnzbWBlj3ptTOxDgo/XI2pTVREkPqJED2bOhnKyj4n8CJkdr 7/CQ== X-Gm-Message-State: ALoCoQlavAR4jNlMQdTx5z53vOUMfy+gYzMIXgQFUr8X0CH5KNRIRuCF4kaeGredOhAVojiedMM0 MIME-Version: 1.0 X-Received: by 10.43.173.70 with SMTP id ob6mr20784677icc.45.1430590805153; Sat, 02 May 2015 11:20:05 -0700 (PDT) Received: by 10.79.11.6 with HTTP; Sat, 2 May 2015 11:20:05 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 May 2015 20:20:05 +0200 Message-ID: Subject: Re: include/rpcsvc - mkdir: /usr/obj/lib32: Permission denied From: Oliver Pinter To: stable@freebsd.org Cc: will@FreeBSD.org, gjb@freebsd.org, bdrewery@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 18:20:12 -0000 On 5/2/15, Oliver Pinter wrote: > On 5/2/15, Oliver Pinter wrote: >> Hi all! >> >> I try to build a modified 10-STABLE with jenkins, but I got the error >> in the subject. >> You can find the full build log under this link: >> http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-10-experimental-amd64/1/console >> >> If you need more info, please ping me, or write to core@hardenedbsd.org . >> >> Thanks you, >> Oliver >> > > Seems like something LIB32_OBJTREE related changes are missing from > 10-STABLE's Makefile.inc1... > Especially this commit: commit ad4df7fd320711af1c0e3bf59b9c7274c0cf95ae Author: will Date: Thu Sep 18 01:57:36 2014 +0000 Root the lib32 object tree under the overall object tree. This enables a common root directory for all object files for a given tree, which eases sharing a common MAKEOBJDIRPREFIX, and cleaning up of object trees. In particular, one can simply (from the source directory) rm -rf /usr/obj$(pwd) to destroy all object files for it. Or to copy/sync files, etc. Reviewed by: bdrewery CR: https://reviews.freebsd.org/D796 MFC after: 1 month Sponsored by: Spectra Logic From owner-freebsd-stable@FreeBSD.ORG Sat May 2 18:22:09 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11589DA4 for ; Sat, 2 May 2015 18:22:09 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA20414DA for ; Sat, 2 May 2015 18:22:08 +0000 (UTC) Received: by iejt8 with SMTP id t8so107577722iej.2 for ; Sat, 02 May 2015 11:22:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qqztLgjQppH70wOlGE20Y87HQCO6OnhAjqPuPgMiEgM=; b=R4w9qMycpPuZAIVLJ2ePRQkoBAVwnkP0ZBgRloYed1NLPO2PMuFkINlqgk7s0xiEy4 IZhzIm+TLpiAMTcaZF8c1tijX48k/2lQ2lmDbRybh5LiD/Ij1+FPtn72P/is6JKNbiLG YtYoS4T+gQs7rDsafS+uDKq9BHF7NTSPvrsKH7Tmz6ZdB6mLBhfUfHKUFKENwxuqtaGu i2810mohDI+m6MBNphE19iZZCfJ1v3OfclkvVc7CYJ3csYKkHXhhFdWr8wj54xJiMGE0 IXqb2uQlW5+CkNaw+/4IoktR2UiA5kLT1fwbcdaWlf2N1BsUeCNNJaFSuOqvgSTUcoZw NZAg== X-Gm-Message-State: ALoCoQnmQ4eioAyYHL/SXN6ItdGS8MF7YV5N13lpxzFVKyW4j9TGI66H1z+z01/sT2vgQRAYVhnI MIME-Version: 1.0 X-Received: by 10.50.114.9 with SMTP id jc9mr4366997igb.49.1430590522241; Sat, 02 May 2015 11:15:22 -0700 (PDT) Received: by 10.79.11.6 with HTTP; Sat, 2 May 2015 11:15:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 May 2015 20:15:22 +0200 Message-ID: Subject: Re: include/rpcsvc - mkdir: /usr/obj/lib32: Permission denied From: Oliver Pinter To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 18:22:09 -0000 On 5/2/15, Oliver Pinter wrote: > Hi all! > > I try to build a modified 10-STABLE with jenkins, but I got the error > in the subject. > You can find the full build log under this link: > http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-10-experimental-amd64/1/console > > If you need more info, please ping me, or write to core@hardenedbsd.org . > > Thanks you, > Oliver > Seems like something LIB32_OBJTREE related changes are missing from 10-STABLE's Makefile.inc1... From owner-freebsd-stable@FreeBSD.ORG Sat May 2 18:46:33 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28901247 for ; Sat, 2 May 2015 18:46:33 +0000 (UTC) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id E4E4616AE for ; Sat, 2 May 2015 18:46:32 +0000 (UTC) Received: from [192.168.5.21] (5418287B.cm-5-1a.dynamic.ziggo.nl [84.24.40.123]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id 46A221E8C4C for ; Sat, 2 May 2015 18:37:22 +0000 (UTC) Message-ID: <55451961.5070708@searchy.net> Date: Sat, 02 May 2015 20:37:21 +0200 From: "Frank de Bot (lists)" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: kernel process [nfscl] high cpu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 18:46:33 -0000 Hi, On a 10.1-RELEASE-p9 server I have several NFS mounts used for a jail. Because it's a server only to test, there is a low load. But the [nfscl] process is hogging a CPU after a while. This happens pretty fast, within 1 or 2 days. I'm noticing the high CPU of the process when I want to do some test after a little while (those 1 or 2 days). My jail.conf look like: exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; exec.clean; mount.devfs; exec.consolelog = "/var/log/jail.$name.log"; #mount.fstab = "/usr/local/etc/jail.fstab.$name"; test01 { host.hostname = "test01_hosting"; ip4.addr = somepublicaddress; ip4.addr += someprivateaddress; mount = "10.13.37.2:/tank/hostingbase /opt/jails/test01 nfs nfsv4,minorversion=1,pnfs,ro,noatime 0 0"; mount += "10.13.37.2:/tank/hosting/test /opt/jails/test01/opt nfs nfsv4,minorversion=1,pnfs,noatime 0 0"; path = "/opt/jails/test01"; } Last test was with NFS 4.1, I also worked with NFS 4.(0) with the same result. In the readonly nfs share there are symbolic links point to the read-write share for logging, storing .run files, etc. When I monitor my network interface with tcpdump, there is little nfs traffic, only when I do try to access the shares there is activity. What is causing nfscl to run around in circles, hogging the CPU (it makes the system slow to respond too) or how can I found out what's the cause? Regards, Frank de Bot From owner-freebsd-stable@FreeBSD.ORG Sat May 2 19:28:36 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DA50145 for ; Sat, 2 May 2015 19:28:36 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 474871B65 for ; Sat, 2 May 2015 19:28:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBABlJEVV/95baINcg19cBYMYwkiBTAqFNk4CggsTAQEBAQEBAYEKhCABAQEDAQEBASAEJyALGxgCAg0ZAikBCSYGCAcEARwEiAIIDbJdkmUBAQEBBgEBAQEBAQEbgSGKGIQzAQEFFzQHgmiBRQWLGYsFhBCDVT2GB442I4IHHIFtIjEHgQQ5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,356,1427774400"; d="scan'208";a="207745642" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 02 May 2015 15:28:34 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7FB21B4221; Sat, 2 May 2015 15:28:34 -0400 (EDT) Date: Sat, 2 May 2015 15:28:34 -0400 (EDT) From: Rick Macklem To: "Frank de Bot (lists)" Cc: freebsd-stable@FreeBSD.org Message-ID: <1031959302.30289198.1430594914473.JavaMail.root@uoguelph.ca> In-Reply-To: <55451961.5070708@searchy.net> Subject: Re: kernel process [nfscl] high cpu MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 19:28:36 -0000 Frank de Bot wrote: > Hi, > > On a 10.1-RELEASE-p9 server I have several NFS mounts used for a > jail. > Because it's a server only to test, there is a low load. But the > [nfscl] > process is hogging a CPU after a while. This happens pretty fast, > within > 1 or 2 days. I'm noticing the high CPU of the process when I want to > do > some test after a little while (those 1 or 2 days). > > My jail.conf look like: > > exec.start = "/bin/sh /etc/rc"; > exec.stop = "/bin/sh /etc/rc.shutdown"; > exec.clean; > mount.devfs; > exec.consolelog = "/var/log/jail.$name.log"; > #mount.fstab = "/usr/local/etc/jail.fstab.$name"; > > test01 { > host.hostname = "test01_hosting"; > ip4.addr = somepublicaddress; > ip4.addr += someprivateaddress; > > mount = "10.13.37.2:/tank/hostingbase /opt/jails/test01 > nfs nfsv4,minorversion=1,pnfs,ro,noatime 0 0"; > mount += "10.13.37.2:/tank/hosting/test > /opt/jails/test01/opt nfs nfsv4,minorversion=1,pnfs,noatime > 0 0"; > > path = "/opt/jails/test01"; > } > > Last test was with NFS 4.1, I also worked with NFS 4.(0) with the > same > result. In the readonly nfs share there are symbolic links point to > the > read-write share for logging, storing .run files, etc. When I monitor > my > network interface with tcpdump, there is little nfs traffic, only > when I > do try to access the shares there is activity. > > What is causing nfscl to run around in circles, hogging the CPU (it > makes the system slow to respond too) or how can I found out what's > the > cause? > Well, the nfscl does server->client RPCs referred to as callbacks. I have no idea what the implications of running it in a jail is, but I'd guess that these server->client RPCs get blocked somehow, etc... (The NFSv4.0 mechanism requires a separate IP address that the server can connect to on the client. For NFSv4.1, it should use the same TCP connection as is used for the client->server RPCs. The latter seems like it should work, but there is probably some glitch.) ** Just run without the nfscl daemon (it is only needed for delegations or pNFS). Since a big Netapp filer (the cluster ones) are about the only servers that currently support pNFS (no FreeBSD server support yet), you can probably forget about pNFS (I'd get rid of the "pnfs" mount option). It also won't work unless this callback path is working. As for delegations, they aren't required for NFSv4.[0-1] to work correctly and aren't enabled by default on the FreeBSD server. --> Running without the nfscl daemon will just ensure no delegations are issued, even if enabled on the server. rick > > Regards, > > Frank de Bot > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" >