From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 00:10:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ABDCADB7 for ; Sun, 10 Feb 2013 00:10:20 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA10EF2 for ; Sun, 10 Feb 2013 00:10:20 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb1so2585588pad.11 for ; Sat, 09 Feb 2013 16:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:content-type:date:message-id :mime-version:x-mailer; bh=YS64osJNc9VPmXT+2c4p55rBXhioaBoc06ZuTBoJD7g=; b=UCLgZsqcEsRcOGdVQxNlBEjTYBZ5UKJpGtqAjGoUqiJkpLUd9/NzKHNIstUz25JQon obV7KbBQerECKwvrL3rU9MoR3BEQ2Uah3zwTO/8RzfqWfOS/bwYsVCNG+wDXFFoBBNYy 7Q9sfKbVL82zZB+QhpErC05IaJYt9eYJH5pNbJsFzN0o0jkeUbjtA/y6UzOdgepQ86/1 MgUe9U7Ye4sdv0xVbVWBhBCYtvbhk7zsomVYkP7zfh8vzBgOosKedlwDj5M2USdxcuKq WQ4GWwrdw1wpJiJn2Qj1S0Z87AOvTITt8797U/xOG95DstfMrHkbUf5C3zvpWP7saMjz KD0A== X-Received: by 10.68.196.130 with SMTP id im2mr6865272pbc.101.1360455014651; Sat, 09 Feb 2013 16:10:14 -0800 (PST) Received: from [192.168.1.210] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id r2sm289938pbd.1.2013.02.09.16.10.12 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 09 Feb 2013 16:10:13 -0800 (PST) Subject: Eliminating a warning in sys/boot From: Sean Bruno To: "freebsd-hackers@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UyKDMXI/DbPNvVHgzLL0" Date: Sat, 09 Feb 2013 16:10:11 -0800 Message-ID: <1360455011.4618.8.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 00:10:20 -0000 --=-UyKDMXI/DbPNvVHgzLL0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, this is not a valid warning in our universe and I'd like to silence it when compiling sys/boot as printf(9) and sprintf(9) supports this format. How can we silence this warning for the FreeBSD universe? =3D=3D=3D> efi/libefi (all) In file included from efinet.c:39: /home/sbruno/fbsd_head/sys/boot/efi/libefi/../../common/dev_net.c:328:19: w= arning: invalid conversion specifier 'D' [-Wformat-invalid-specifier] sprintf(temp, "%6D", d->myea, ":"); SEan --=-UyKDMXI/DbPNvVHgzLL0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJRFuVjAAoJEBkJRdwI6BaHACoH/2kvk9MJFdLl3/sixJ5ogmWI luDzQHHCvxrf+k8rEq4qwKJ+XhB30DkMbsiGhRgCLp6j6AdCZBy4BmkwgfpTv7ni ep8Qa8rkDZe1EIdmnf02cguK5/0uorayWWhGkj8IpFIuuil/0Y/Hwq59jdiWLQje VrJoxmS7e6RWBI8bvo5T7V8TvQZvYGXDRiZmH3Awe9Q+GlvXo7qkP1jxBG2ECUJS 4N0n5m7W8I9FOiJLX3jCqGWoMkgAKvAudBrsx3GLXkSYAyrQU0tZ5AYZeHL6Ow6Z /0J38aiR1tU1AubSUFGTaAYaFPVvlZOaJbJzcHq1+zax0HMxTY00SGZyWE2zOgQ= =aTGI -----END PGP SIGNATURE----- --=-UyKDMXI/DbPNvVHgzLL0-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 09:28:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 51C95306; Sun, 10 Feb 2013 09:28:06 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by mx1.freebsd.org (Postfix) with ESMTP id B976512A; Sun, 10 Feb 2013 09:28:05 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id e53so2650930eek.26 for ; Sun, 10 Feb 2013 01:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TRTe57wobQ4GdoOR5F5CLck/NPDkBorh3GkqtdBF688=; b=PtrpGc90pzINcvALBGTL1tpJKBodjNml/lVituAgimPCg4Emy+BAJzLgSoavt7R5id Dp6SgVuOvgFaA2H3N9p5XFT2CwGVKnRlcvCuvfKeXASL1JRU0l+1fp/O1Jx0CzNGoMII 6kii0m4yi7tmYzWOttks5tNMV9poOfUtFuWZo8H3tj4Q51eSBQkLvWqa9ARfYINc5aFQ CYI/AHn7GmN2zfgm+Bx1qJ5BKuC54WN4kWxjwZB/2UaIdKVlylJgIlWHMeU60MJV3HRl x1AekEg8EfFb6Ue9R9McQl0gIpTzxl/ruSnSgyaI4Bdf4y8uKIylaDt1kXxaRt9Lcm82 g3Bg== MIME-Version: 1.0 X-Received: by 10.14.2.5 with SMTP id 5mr36345886eee.30.1360488479038; Sun, 10 Feb 2013 01:27:59 -0800 (PST) Received: by 10.14.133.204 with HTTP; Sun, 10 Feb 2013 01:27:58 -0800 (PST) In-Reply-To: <1360455011.4618.8.camel@powernoodle> References: <1360455011.4618.8.camel@powernoodle> Date: Sun, 10 Feb 2013 01:27:58 -0800 Message-ID: Subject: Re: Eliminating a warning in sys/boot From: hiren panchasara To: sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 09:28:06 -0000 On Sat, Feb 9, 2013 at 4:10 PM, Sean Bruno wrote: > So, this is not a valid warning in our universe and I'd like to silence > it when compiling sys/boot as printf(9) and sprintf(9) supports this > format. How can we silence this warning for the FreeBSD universe? > > ===> efi/libefi (all) > In file included from efinet.c:39: > /home/sbruno/fbsd_head/sys/boot/efi/libefi/../../common/dev_net.c:328:19: warning: invalid conversion specifier 'D' > [-Wformat-invalid-specifier] > sprintf(temp, "%6D", d->myea, ":"); Here "d->myea" being char pointer, can we not do following instead? : sprintf(temp, "%6s", d->myea, ":"); Hiren From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 10:37:54 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7838328E; Sun, 10 Feb 2013 10:37:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6B8B343; Sun, 10 Feb 2013 10:37:53 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1AAbjlb071423; Sun, 10 Feb 2013 12:37:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1AAbjlb071423 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1AAbjRY071422; Sun, 10 Feb 2013 12:37:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Feb 2013 12:37:45 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Request for review, time_pps_fetch() enhancement Message-ID: <20130210103745.GI2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <20130209134706.GB19909@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TMGYF+XY7wpHOFd9" Content-Disposition: inline In-Reply-To: <20130209134706.GB19909@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 10:37:54 -0000 --TMGYF+XY7wpHOFd9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote: > On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote: > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > I'd like feedback on the attached patch, which adds support to our > > > time_pps_fetch() implementation for the blocking behaviors described = in > > > section 3.4.3 of RFC 2783. The existing implementation can only retu= rn > > > the most recently captured data without blocking. These changes add = the > > > ability to block (forever or with timeout) until a new event occurs. >=20 > > > Index: sys/kern/kern_tc.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sys/kern/kern_tc.c (revision 246337) > > > +++ sys/kern/kern_tc.c (working copy) > > > @@ -1446,6 +1446,50 @@ > > > * RFC 2783 PPS-API implementation. > > > */ > > > =20 > > > +static int > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > +{ > > > [snip] > > > + aseq =3D pps->ppsinfo.assert_sequence; > > > + cseq =3D pps->ppsinfo.clear_sequence; > > > + while (aseq =3D=3D pps->ppsinfo.assert_sequence && > > > + cseq =3D=3D pps->ppsinfo.clear_sequence) { > > Note that compilers are allowed to optimize these accesses even over > > the sequential point, which is the tsleep() call. Only accesses to > > volatile objects are forbidden to be rearranged. >=20 > > I suggest to add volatile casts to pps in the loop condition. >=20 > The memory pointed to by pps is global (other code may have a pointer to > it); therefore, the compiler must assume that the tsleep() call (which > invokes code in a different compilation unit) may modify it. >=20 > Because volatile does not make concurrent access by multiple threads > defined either, adding it here only seems to slow down the code > (potentially). The volatile guarantees that the compiler indeed reloads the value on read access. Conceptually, the tsleep() does not modify or even access the checked fields, and compiler is allowed to note this by whatever methods (LTO ?). More, the standard says that an implementation is allowed to not evaluate part of the expression if no side effects are produced, even by calling a function. I agree that for practical means, the _currently_ used compilers should consider the tsleep() call as the sequential point. But then the volatile qualifier cast applied for the given access would not change the code as well. >=20 > > > + err =3D tsleep(pps, PCATCH, "ppsfch", timo); > > > + if (err =3D=3D EWOULDBLOCK && fapi->timeout.tv_sec =3D=3D -1) { > > > + continue; > > > + } else if (err !=3D 0) { > > > + return (err); > > > + } > > > + } > > > + } > --=20 > Jilles Tjoelker --TMGYF+XY7wpHOFd9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRF3h4AAoJEJDCuSvBvK1B+dYP/3Qqs9HWVNiMeSg96SZpBKb6 FPWX1+ORMEg8OCpJwseTgaYivVLIitDs/eoUnfyZnBDtydm1cJq76jT1iMPL58PC xFfqst1viOmq5aj0yBuK5XZGOleLgXQusx7mR6S7FK2S6fL+NdoPTz5fhRY380Jy LdWXkZX+CPnEuC8f3KToASxajbEcVBns2LEsiJ9k4mm28jNhwv9AkUwDLFuvrHlY UJCpBzDwxeET7EZL6GTU8krWpCwTUKzwC+zUQL4D7Fl5CVb7hrzdAklCNKDKHUEE vBadYROFNOeYAVWnqqk//BquXPmkuy6UZhs7/w/QBod7UiYA3GesjHW2+/JmL0pi Zc6ZgWE/WfIAREaTUkUwK5+QZxRkev7fNNX46kJXMkvzr82ko5U28O4EGLyqvDjZ Z6VRZC9NeS2Js24Tl8kbJP2fKTkLMdYzTrW5RqcVSPmiEYLjma4NJ3vrsflqnfmr ZKBnR986q6pcAQK+04Uo2wQ94kFM2Jy09S1LVx2Bcjk+qjpjQ6H68pHYlUa5SHPI u4kzy4sl8nIyb1EvDiryZ2Ds8mC9YbVCBwBJcLBonGx62+jA3YjgnZQDSBfX6oi/ 9qqn7O5EEY0renI+vvpXNR5/dXg2Jmp4E7La9Gr+R/CEZUdr5qZ+NACnPgDc1ExI a1SyRlbJyshZvdpcLwuA =+kNV -----END PGP SIGNATURE----- --TMGYF+XY7wpHOFd9-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 10:41:50 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 978763A2; Sun, 10 Feb 2013 10:41:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E98E0369; Sun, 10 Feb 2013 10:41:49 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1AAfjuT071977; Sun, 10 Feb 2013 12:41:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1AAfjuT071977 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1AAfjXo071976; Sun, 10 Feb 2013 12:41:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Feb 2013 12:41:45 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Request for review, time_pps_fetch() enhancement Message-ID: <20130210104145.GJ2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <1360365220.4545.42.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+gGPykIdtTMJQYdC" Content-Disposition: inline In-Reply-To: <1360365220.4545.42.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 10:41:50 -0000 --+gGPykIdtTMJQYdC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2013 at 04:13:40PM -0700, Ian Lepore wrote: > On Wed, 2013-02-06 at 17:58 +0200, Konstantin Belousov wrote: > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > I'd like feedback on the attached patch, which adds support to our > > > time_pps_fetch() implementation for the blocking behaviors described = in > > > section 3.4.3 of RFC 2783. The existing implementation can only retu= rn > > > the most recently captured data without blocking. These changes add = the > > > ability to block (forever or with timeout) until a new event occurs. > > >=20 > > > -- Ian > > >=20 > >=20 > > > Index: sys/kern/kern_tc.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sys/kern/kern_tc.c (revision 246337) > > > +++ sys/kern/kern_tc.c (working copy) > > > @@ -1446,6 +1446,50 @@ > > > * RFC 2783 PPS-API implementation. > > > */ > > > =20 > > > +static int > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > +{ > > > + int err, timo; > > > + pps_seq_t aseq, cseq; > > > + struct timeval tv; > > > + > > > + if (fapi->tsformat && fapi->tsformat !=3D PPS_TSFMT_TSPEC) > > > + return (EINVAL); > > > + > > > + /* > > > + * If no timeout is requested, immediately return whatever values w= ere > > > + * most recently captured. If timeout seconds is -1, that's a requ= est > > > + * to block without a timeout. WITNESS won't let us sleep forever > > > + * without a lock (we really don't need a lock), so just repeatedly > > > + * sleep a long time. > > > + */ > > Regarding no need for the lock, it would just move the implementation i= nto > > the low quality one, for the case when one timestamp capture is lost > > and caller of time_pps_fetch() sleeps until next pps event is generated. > >=20 > > I understand the desire to avoid lock, esp. in the pps_event() called > > from the arbitrary driver context. But the race is also real. > >=20 >=20 > What race? A user of the pps interface understands that there is one > event per second, and understands that if you ask to block until the > next event at approximately the time that event is expected to occur, > then it is ambiguous whether the call completes almost-immediately or in > about 1 second. >=20 > Looking at it another way, if a blocking call is made right around the > time of the PPS, the thread could get preempted before getting to > pps_fetch() function and not get control again until after the PPS has > occurred. In that case it's going to block for about a full second, > even though the call was made before top-of-second. That situation is > exactly the same with or without locking, so what extra functionality is > gained with locking? What guarantee does locking let us make to the > caller that the lockless code doesn't? No guarantees, but I noted in the original reply that this is about the quality of the implementation and not about correctness. As I said there as well, I am not sure that any locking can be useful for the situation at all. --+gGPykIdtTMJQYdC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRF3loAAoJEJDCuSvBvK1BdfkQAJ23vyNMtY8Hsue3Vvf1uHd8 pJFQr/6NBIeaCIH057H6G8aWzmEUStoY7Gve8mzFr0oBo0zkb6ttTjINkbvaNI0T 48htcdEUx+elnFs8bIzlPstEsluJGg4TcJG3NbVBJzu1Hmjyt6MqsgbI9kOyJpmB X1JjwMDNT0TiPL8gSKJcNMFT2FYc2186Ol4vVyeBS3oQCnzFHSfUpvF350felDo5 8sS0A50E1owRdcNje8FWtShwFmVHIVgwSbuSMaf5Ga4ks2eupc4HUtCYQAxumOzY P+NLlOfEWSmzQfDbkXk1527CGn6lKai+SZVXOp9OY081XcwEbuLZjja84JK9WyQ3 hb+RMOPY6tEMxYg4VrkeuskMV3S0H95EHP09/3neHOjxRDqFPgk+plLe3r4zkQLw up72SO7VEMqvsN8R8vXtN89uetUaC50LbcV15iLdplZRtcQcIgkq6oAV/9131IUK EkZeRGBJMGeM78wRdSnPilB7zpxLcBe0U7WXkvmbB3n0nAfsQRj3QVi6YGzDZ6Cq 0SZm1oQUUFyPjja+afdjOmIy69G6WbrA1AY2YqSHV7/65sYqg7bQEXwvEDfbGgik xfsYqBe/DQHnluSpjgRyRK2pXIQmu5T6NP7PFJBcl2e6ASWQhJZA3rCSSWiH8Gjf T8VOLEKByW58VUFEZc1+ =uLon -----END PGP SIGNATURE----- --+gGPykIdtTMJQYdC-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 11:30:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 124F7823; Sun, 10 Feb 2013 11:30:02 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id CC8DE7D6; Sun, 10 Feb 2013 11:30:01 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A22B05C43; Sun, 10 Feb 2013 12:29:53 +0100 (CET) Message-ID: <511784B0.4060806@FreeBSD.org> Date: Sun, 10 Feb 2013 12:29:52 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: sbruno@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: Eliminating a warning in sys/boot References: <1360455011.4618.8.camel@powernoodle> In-Reply-To: <1360455011.4618.8.camel@powernoodle> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 11:30:02 -0000 On 2013-02-10 01:10, Sean Bruno wrote:> So, this is not a valid warning in our universe and I'd like to silence > it when compiling sys/boot as printf(9) and sprintf(9) supports this > format. How can we silence this warning for the FreeBSD universe? > > ===> efi/libefi (all) > In file included from efinet.c:39: > /home/sbruno/fbsd_head/sys/boot/efi/libefi/../../common/dev_net.c:328:19: warning: invalid conversion specifier 'D' > [-Wformat-invalid-specifier] > sprintf(temp, "%6D", d->myea, ":"); Either eliminate the non-standard printf format specifier, or use the -fformat-extensions flag while compiling. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 14:42:05 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23354EF7; Sun, 10 Feb 2013 14:42:05 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by mx1.freebsd.org (Postfix) with ESMTP id CE48B117; Sun, 10 Feb 2013 14:42:04 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id dn14so5405056obc.32 for ; Sun, 10 Feb 2013 06:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=EoeVcwbPnyFoKlZJur6SQdT7UYmGyfyHjDTbt2LIEOY=; b=PV6C1TVZ7J/89r8VyAezuntOsfFz+hVHVV5Ado87XoRR4Q1hZRBtoAXS46wdShWmIF YK0qt7M7JczTPCSJQyyjRdzE+kSt7tRZHXEKAFip5pgx+UqcHpn1HTbn4suOhVfn76rV Fk6WezL7Fna2sXkd8BpbNZLB+AFsKOFrI0/fgoW0r//oOnf7bIBfjh9FJcUAevCwaPjG vmCYkH9serV9E6YqfyLPz2YR4MGxR3K0zWTfGhFrHQyU52gq7cS3tzI3YBcDcJWbJ7o9 2nbA7+hSgE40wUWFn0rD4h0AURlfAWo031ny/xxEl5PP9cmceGluoT82Nc3XitgtV0Oe eI+A== MIME-Version: 1.0 X-Received: by 10.60.171.170 with SMTP id av10mr8833796oec.78.1360507324020; Sun, 10 Feb 2013 06:42:04 -0800 (PST) Sender: pali.gabor@gmail.com Received: by 10.182.87.195 with HTTP; Sun, 10 Feb 2013 06:42:03 -0800 (PST) Date: Sun, 10 Feb 2013 15:42:03 +0100 X-Google-Sender-Auth: grE6A8Aps3Urt7Qvc1AOKYve_Tk Message-ID: Subject: Reminder: FreeBSD Quarterly Status Reports, July--December, 2012 From: Gabor Pali To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 14:42:05 -0000 Hello there, Let me call your attention to the approaching deadline of the next set(s) of FreeBSD Quarterly Status Reports. Please consider submitting a few lines on your FreeBSD-related project, we are counting on all of you! :-) On Sun, Jan 13, 2013 at 10:57 PM, Gabor Pali wrote: > Please note that the deadline for submissions covering the period > between July and December 2012 is February 17th, 2013. You can find more details on submission at the Project's web site [1] but you are free to ask me directly (in private) if you need help with this. [1] http://www.freebsd.org/news/status/ From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 21:48:23 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45B2ED5F; Sun, 10 Feb 2013 21:48:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9753363D; Sun, 10 Feb 2013 21:48:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1ALmIRI046444; Sun, 10 Feb 2013 23:48:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1ALmIRI046444 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1ALmIJ2046443; Sun, 10 Feb 2013 23:48:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Feb 2013 23:48:18 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: fcntl(2) F_READAHEAD set to zero doesn't work [patch] Message-ID: <20130210214818.GU2522@kib.kiev.ua> References: <1360367889.4545.58.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yUaAwXDrp3vRFP8y" Content-Disposition: inline In-Reply-To: <1360367889.4545.58.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 21:48:23 -0000 --yUaAwXDrp3vRFP8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2013 at 04:58:09PM -0700, Ian Lepore wrote: > I discovered today that fcntl(fd, F_READAHEAD, 0) doesn't work as > advertised. It's supposed to disable readahead, but instead it restores > the default readahead behavior (if it had previously been changed), and > there is no way to disable readahead.[1] I think the attached patch > fixes it, but it's not immediately clear from the patch why; here's the > deal... >=20 > The amount of readahead is calculated by sequential_heuristic() in > vfs_vnops.c. If the FRDAHEAD flag is set on the file it uses the value > stored in the file's f_seqcount, otherwise it calculates a value (and > updates f_seqcount, which doesn't ever happen when FRDAHEAD is set). >=20 > So the patch causes the FRDAHEAD flag to be set even in the case of the > readahead amount being zero. Because it seems like a useful concept, it > still allows the readahead to be restored to default behavior, now by > passing a negative value. >=20 > Does this look right to those of you who understand this part of the > system better than I do? It looks correct. I do wonder if it better to keep the actual behaviour as is and set the readahead amount to default on the arg =3D=3D 0, disabling readahead for arg < 0. It is too exteme, most likely, please proceed. >=20 > -- Ian >=20 > [1] No way using F_READAHEAD; I know about POSIX_FADV_RANDOM. > Index: sys/kern/kern_descrip.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_descrip.c (revision 246337) > +++ sys/kern/kern_descrip.c (working copy) > @@ -776,7 +776,7 @@ > } > fhold(fp); > FILEDESC_SUNLOCK(fdp); > - if (arg !=3D 0) { > + if (arg >=3D 0) { > vp =3D fp->f_vnode; > error =3D vn_lock(vp, LK_SHARED); > if (error !=3D 0) { > Index: lib/libc/sys/fcntl.2 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/libc/sys/fcntl.2 (revision 246337) > +++ lib/libc/sys/fcntl.2 (working copy) > @@ -28,7 +28,7 @@ > .\" @(#)fcntl.2 8.2 (Berkeley) 1/12/94 > .\" $FreeBSD$ > .\" > -.Dd July 27, 2012 > +.Dd February 8, 2013 > .Dt FCNTL 2 > .Os > .Sh NAME > @@ -171,7 +171,7 @@ > which is rounded up to the nearest block size. > A zero value in > .Fa arg > -turns off read ahead. > +turns off read ahead, a negative value restores the system default. > .It Dv F_RDAHEAD > Equivalent to Darwin counterpart which sets read ahead amount of 128KB > when the third argument, > _______________________________________________ > 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" --yUaAwXDrp3vRFP8y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRGBWhAAoJEJDCuSvBvK1BXpYP/jcWsgG68n10KB2W8aL+SZrc 6Pi4DQSMBTuqUfZ2b1UD2TlB7LHikbeqM6e1LjCbwcDqx9yc1k2PaQnVRGiWxsQl 2x6juHIYraXGaPz8tyAuWorYn/LRc7tyFUph2I+QTIg6mlzzxA3k6BtEZTAWnKbD sDrtRCwG0jAwlSk3JIQ3l1guwBvyXCilNonRLwrlbP1HqTP10rZ/P4rYQTLpnViz dMPHmoLgE+/ezHJPVFadD5Lc/wpw7JuiHwMhFCt+F7wOD6BseJPCGV3HZKgaOmFt bVuF4t8wltOca21mvza1FRJlMxTYVX/aiup2FOnTCkwAGV+QsQLTU1IXlr3/qpJT J7A4xIiwJ+/zI8GYvWuOZLo2ucgMOK7OnloFoRc4GeVEd1xbctrERmKNxV+mufxj ag4p5gFWbO62vIFzj1qAdUe53eYgo3/pLYtHzvwzrGch52NRxmVyIE9QqQ6nNk/u G4NlVQav49LN1z+as7lCEEy46zcNWUSy2PGxEKtuKLl2x5m9PI1QI5NhySKsJxyi 1TxizHWWsiSBi3Q0aC/X0w4dsoTZuDG/t3++YDLwLUAk5sYJptOj2Sn+BVSkYD8w UxU/22OYtyqulHc4zWCY5bEFWo5UOxWe7JTNfaPrv+cvjJsirjfrnLDczBLzPrn3 zoCPvZPwoTiHdZvHexLC =8bc/ -----END PGP SIGNATURE----- --yUaAwXDrp3vRFP8y-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 11 15:18:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A09E9B31 for ; Mon, 11 Feb 2013 15:18:14 +0000 (UTC) (envelope-from papowell@astart.com) Received: from astart2.astart.com (99-111-96-109.uvs.sndgca.sbcglobal.net [99.111.96.109]) by mx1.freebsd.org (Postfix) with ESMTP id 6080C86C for ; Mon, 11 Feb 2013 15:18:14 +0000 (UTC) Received: from laptop_83.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.4/8.14.4) with ESMTP id r1BF7KY3044702 for ; Mon, 11 Feb 2013 07:07:21 -0800 (PST) (envelope-from papowell@astart.com) Message-ID: <51190923.7090907@astart.com> Date: Mon, 11 Feb 2013 07:07:15 -0800 From: Patrick Powell Organization: Astart Technologies User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120807 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Eliminating a warning in sys/boot References: <1360455011.4618.8.camel@powernoodle> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: papowell@astart.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:18:14 -0000 On 02/10/13 01:27, hiren panchasara wrote: > On Sat, Feb 9, 2013 at 4:10 PM, Sean Bruno wrote: >> So, this is not a valid warning in our universe and I'd like to silence >> it when compiling sys/boot as printf(9) and sprintf(9) supports this >> format. How can we silence this warning for the FreeBSD universe? >> >> ===> efi/libefi (all) >> In file included from efinet.c:39: >> /home/sbruno/fbsd_head/sys/boot/efi/libefi/../../common/dev_net.c:328:19: warning: invalid conversion specifier 'D' >> [-Wformat-invalid-specifier] >> sprintf(temp, "%6D", d->myea, ":"); > Here "d->myea" being char pointer, can we not do following instead? : > sprintf(temp, "%6s", d->myea, ":"); NO NO NO NO! I really suggest that sprintf be removed from the C library. Try: char fixed_buffer[32]; snprintf(fixed_buffer, sizeof(fixed_buffer), "%6whateverformat",whatever); -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Road, Suite X, Network and System El Cajon, CA 92019 Consulting 858-874-6543 Web Site: www.astart.com From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 11 19:24:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 372B78D5 for ; Mon, 11 Feb 2013 19:24:34 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id EDC328DC for ; Mon, 11 Feb 2013 19:24:33 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r1BJOWjH054455 for ; Mon, 11 Feb 2013 14:24:32 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id r1BJOWAD054454 for freebsd-hackers@freebsd.org; Mon, 11 Feb 2013 14:24:32 -0500 (EST) (envelope-from lidl) Date: Mon, 11 Feb 2013 14:24:32 -0500 From: Kurt Lidl To: freebsd-hackers@freebsd.org Subject: building select ports for packaging on install media Message-ID: <20130211192432.GA54378@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 19:24:34 -0000 Greetings. I'm looking for a little guidance in building a small (one to two dozen) packages for inclusion on a locally generated install CDROM. (I'm doing this on for sparc64 machines, but I don't think that matters tremendously.) I have successfully generated bootable cd-rom media by doing: cd /usr/src/release make release After grinding around alot, I get a viable sparc64 bootable cdrom. What I'd like to do is augement that CD-ROM image with several binary packages, so I can just install them via 'sysinstall', rather than having to maintain a /usr/ports tree on every host and compile the same software again and again... I've found: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/article.html and http://www.freebsd.org/doc/en/articles/portbuild/article.html But those seem to revolve around building *all* the ports. I just want to do a couple of dozen of them, but I'd like to end up with something that will generate binary packages that 'pkg install' can deal with. Thanks for any tips. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 11 19:31:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A303AD2 for ; Mon, 11 Feb 2013 19:31:18 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id F2943943 for ; Mon, 11 Feb 2013 19:31:17 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id hq4so3572485wib.6 for ; Mon, 11 Feb 2013 11:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VoV7bRpzZDjPKIynf666BhnCj1iTEVBBmyZAV8bkqas=; b=v5kG8OH/kJ27jN9XN+AfM0qlop+AWBWOBh3q/s1X26wa7IkvHi8kxcnNSN8mZkNOSj GnlBUERVuxFyZToP/xLErvVu1OcJ7ADhfaCujDeoFMRZ3cgTpEkbbSB/5P+EpmXJ2Yoh ssBiD7tYxP3CD4DWn0WA+GSZLY6a5cnXyNc/uxdfBB5B6PFFMgy/INmFCjn0Vx2fTnpg 2mSfz8SOkWxXnjv3TZPKsrA4AYIyHgHjDeV0Yu8tBUNEAwBbCy2RiLeMN2GYIaWNoplP qVLOt5RSdEHiHgnX9xceGBTYjli78Kn9OLNIza7I9+uDEXPr4/x0tNloeaGDTp86eyJA GUGQ== MIME-Version: 1.0 X-Received: by 10.180.105.195 with SMTP id go3mr18065815wib.13.1360611076966; Mon, 11 Feb 2013 11:31:16 -0800 (PST) Received: by 10.194.85.116 with HTTP; Mon, 11 Feb 2013 11:31:16 -0800 (PST) Received: by 10.194.85.116 with HTTP; Mon, 11 Feb 2013 11:31:16 -0800 (PST) In-Reply-To: <20130211192432.GA54378@pix.net> References: <20130211192432.GA54378@pix.net> Date: Mon, 11 Feb 2013 21:31:16 +0200 Message-ID: Subject: Re: building select ports for packaging on install media From: Alexander Yerenkow To: Kurt Lidl Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 19:31:18 -0000 Best way is to have poudriere :) Regards, Alexander Yerenkow 11.02.2013 21:24 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Kurt Lidl" =CE=C1=D0=C9=D3=C1=CC: > Greetings. > > I'm looking for a little guidance in building a small > (one to two dozen) packages for inclusion on a locally > generated install CDROM. > > (I'm doing this on for sparc64 machines, but I don't think > that matters tremendously.) > > I have successfully generated bootable cd-rom media > by doing: > > cd /usr/src/release > make release > > After grinding around alot, I get a viable sparc64 bootable > cdrom. > > What I'd like to do is augement that CD-ROM image with several > binary packages, so I can just install them via 'sysinstall', > rather than having to maintain a /usr/ports tree on every host > and compile the same software again and again... > > I've found: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/artic= le.html > and > http://www.freebsd.org/doc/en/articles/portbuild/article.html > > But those seem to revolve around building *all* the ports. > I just want to do a couple of dozen of them, but I'd like to > end up with something that will generate binary packages that > 'pkg install' can deal with. > > Thanks for any tips. > > -Kurt > _______________________________________________ > 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 Mon Feb 11 19:33:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B4158BD0 for ; Mon, 11 Feb 2013 19:33:39 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id 2B31395F for ; Mon, 11 Feb 2013 19:33:38 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so3382480eek.19 for ; Mon, 11 Feb 2013 11:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=McXDrVIS3+PgoRvX/DEQmf/QO0DXDn+3zyn+dhEY5OY=; b=dc4kxPZ9RvCKklDIcFIKAOV1+JMwg+Bl/vpi40O5/CL4omCx80j+QrbB/LQhWNS+Wv pn8Zp/imPWuhvHPb31Rt9WSn3X2HCH/NOp/NvXRSAdBK3oA5/WXieisTAXh6UrcOgyh4 0la8Z0lEBADMgWhqZoJKnUoz5d4o+gUJzb3bWw8NAAO9ZVOzVNTDrLGGpvAHE21YIRMx LiB3TXLCcXrbj3uLB+Tyr03unFYC7+JQ6RqIFZKpmFETjaIXTXA88VmJEqTClZQuDoRj f78lSkCs6731B/+SEUj7nEXr+eCZSIHQpvkWexAcARMJmcc2Utzho/tTuhXdJf631pOE gVVA== MIME-Version: 1.0 X-Received: by 10.14.0.135 with SMTP id 7mr29637696eeb.5.1360611217358; Mon, 11 Feb 2013 11:33:37 -0800 (PST) Received: by 10.14.124.7 with HTTP; Mon, 11 Feb 2013 11:33:36 -0800 (PST) Received: by 10.14.124.7 with HTTP; Mon, 11 Feb 2013 11:33:36 -0800 (PST) In-Reply-To: References: <20130211192432.GA54378@pix.net> Date: Mon, 11 Feb 2013 19:33:36 +0000 Message-ID: Subject: Re: building select ports for packaging on install media From: Chris Rees To: Alexander Yerenkow Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, Kurt Lidl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 19:33:39 -0000 Tinderbox will also work fine. (Also, this belongs on ports@) Chris On 11 Feb 2013 19:31, "Alexander Yerenkow" wrote: > Best way is to have poudriere :) > > Regards, Alexander Yerenkow > 11.02.2013 21:24 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Kurt Lidl" =CE=C1=D0=C9=D3=C1=CC: > > > Greetings. > > > > I'm looking for a little guidance in building a small > > (one to two dozen) packages for inclusion on a locally > > generated install CDROM. > > > > (I'm doing this on for sparc64 machines, but I don't think > > that matters tremendously.) > > > > I have successfully generated bootable cd-rom media > > by doing: > > > > cd /usr/src/release > > make release > > > > After grinding around alot, I get a viable sparc64 bootable > > cdrom. > > > > What I'd like to do is augement that CD-ROM image with several > > binary packages, so I can just install them via 'sysinstall', > > rather than having to maintain a /usr/ports tree on every host > > and compile the same software again and again... > > > > I've found: > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/artic= le.html > > and > > http://www.freebsd.org/doc/en/articles/portbuild/article.html > > > > But those seem to revolve around building *all* the ports. > > I just want to do a couple of dozen of them, but I'd like to > > end up with something that will generate binary packages that > > 'pkg install' can deal with. > > > > Thanks for any tips. > > > > -Kurt > > _______________________________________________ > > 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" > > > _______________________________________________ > 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 Mon Feb 11 19:38:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A8CDDAF for ; Mon, 11 Feb 2013 19:38:52 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 12F1B9A4 for ; Mon, 11 Feb 2013 19:38:51 +0000 (UTC) Received: from [89.204.154.216] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U4zDA-0005at-QL; Mon, 11 Feb 2013 20:38:45 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id r1BJcgP2002181; Mon, 11 Feb 2013 20:38:42 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id r1BJcfOu002180; Mon, 11 Feb 2013 20:38:41 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Mon, 11 Feb 2013 20:38:41 +0100 From: Matthias Apitz To: Kurt Lidl Subject: Re: building select ports for packaging on install media Message-ID: <20130211193840.GA1577@tiny.Sisis.de> References: <20130211192432.GA54378@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130211192432.GA54378@pix.net> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.154.216 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 19:38:52 -0000 El día Monday, February 11, 2013 a las 02:24:32PM -0500, Kurt Lidl escribió: > What I'd like to do is augement that CD-ROM image with several > binary packages, so I can just install them via 'sysinstall', > rather than having to maintain a /usr/ports tree on every host > and compile the same software again and again... > > I've found: > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/article.html > and > http://www.freebsd.org/doc/en/articles/portbuild/article.html > > But those seem to revolve around building *all* the ports. > I just want to do a couple of dozen of them, but I'd like to > end up with something that will generate binary packages that > 'pkg install' can deal with. Just compile and install the required ports from /usr/ports on your main host and create binary packages of them in some central directory with: for i in /var/db/pkg/*; do pkg=`basename $i` pkg_create -Rnb $pkg done Move the result to the CD/DVD and that's it matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: guru@unixarea.de | - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | - No proprietary attachments phone: +49-170-4527211 | - Respect for open standards From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 15:55:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2CD6929F for ; Tue, 12 Feb 2013 15:55:47 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 97522D87 for ; Tue, 12 Feb 2013 15:55:46 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1CFTkix025377; Tue, 12 Feb 2013 16:29:46 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1CFTjF1025374; Tue, 12 Feb 2013 16:29:46 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 12 Feb 2013 16:29:45 +0100 (CET) From: Wojciech Puchar To: Kurt Lidl Subject: Re: building select ports for packaging on install media In-Reply-To: <20130211192432.GA54378@pix.net> Message-ID: References: <20130211192432.GA54378@pix.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 12 Feb 2013 16:29:46 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:55:47 -0000 > cdrom. > > What I'd like to do is augement that CD-ROM image with several > binary packages, so I can just install them via 'sysinstall', > rather than having to maintain a /usr/ports tree on every host > and compile the same software again and again... why not just use pkg_add? From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 15:59:56 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D877C3AF for ; Tue, 12 Feb 2013 15:59:56 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 87EB2DB6 for ; Tue, 12 Feb 2013 15:59:56 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1CFxjnB083115 for ; Tue, 12 Feb 2013 08:59:52 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1CFxNDa041137; Tue, 12 Feb 2013 08:59:23 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Request for review, time_pps_fetch() enhancement From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130210104145.GJ2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <1360365220.4545.42.camel@revolution.hippie.lan> <20130210104145.GJ2522@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2013 08:59:23 -0700 Message-ID: <1360684763.4545.167.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:59:56 -0000 On Sun, 2013-02-10 at 12:41 +0200, Konstantin Belousov wrote: > On Fri, Feb 08, 2013 at 04:13:40PM -0700, Ian Lepore wrote: > > On Wed, 2013-02-06 at 17:58 +0200, Konstantin Belousov wrote: > > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > > I'd like feedback on the attached patch, which adds support to our > > > > time_pps_fetch() implementation for the blocking behaviors described in > > > > section 3.4.3 of RFC 2783. The existing implementation can only return > > > > the most recently captured data without blocking. These changes add the > > > > ability to block (forever or with timeout) until a new event occurs. > > > > > > > > -- Ian > > > > > > > > > > > Index: sys/kern/kern_tc.c > > > > =================================================================== > > > > --- sys/kern/kern_tc.c (revision 246337) > > > > +++ sys/kern/kern_tc.c (working copy) > > > > @@ -1446,6 +1446,50 @@ > > > > * RFC 2783 PPS-API implementation. > > > > */ > > > > > > > > +static int > > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > > +{ > > > > + int err, timo; > > > > + pps_seq_t aseq, cseq; > > > > + struct timeval tv; > > > > + > > > > + if (fapi->tsformat && fapi->tsformat != PPS_TSFMT_TSPEC) > > > > + return (EINVAL); > > > > + > > > > + /* > > > > + * If no timeout is requested, immediately return whatever values were > > > > + * most recently captured. If timeout seconds is -1, that's a request > > > > + * to block without a timeout. WITNESS won't let us sleep forever > > > > + * without a lock (we really don't need a lock), so just repeatedly > > > > + * sleep a long time. > > > > + */ > > > Regarding no need for the lock, it would just move the implementation into > > > the low quality one, for the case when one timestamp capture is lost > > > and caller of time_pps_fetch() sleeps until next pps event is generated. > > > > > > I understand the desire to avoid lock, esp. in the pps_event() called > > > from the arbitrary driver context. But the race is also real. > > > > > > > What race? A user of the pps interface understands that there is one > > event per second, and understands that if you ask to block until the > > next event at approximately the time that event is expected to occur, > > then it is ambiguous whether the call completes almost-immediately or in > > about 1 second. > > > > Looking at it another way, if a blocking call is made right around the > > time of the PPS, the thread could get preempted before getting to > > pps_fetch() function and not get control again until after the PPS has > > occurred. In that case it's going to block for about a full second, > > even though the call was made before top-of-second. That situation is > > exactly the same with or without locking, so what extra functionality is > > gained with locking? What guarantee does locking let us make to the > > caller that the lockless code doesn't? > > No guarantees, but I noted in the original reply that this is about the > quality of the implementation and not about correctness. > > As I said there as well, I am not sure that any locking can be useful > for the situation at all. Well then I guess I don't understand what you mean by the term "quality". Apparently you use it as some form of jargon rather than its usual accepted meaning in everyday English? Or, more directly: are you implying something should be changed to make the code better? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 16:04:03 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 854B37C9 for ; Tue, 12 Feb 2013 16:04:03 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D24F8E78 for ; Tue, 12 Feb 2013 16:04:02 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1CG42X6083261 for ; Tue, 12 Feb 2013 09:04:02 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1CG3dvn041147; Tue, 12 Feb 2013 09:03:39 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Request for review, time_pps_fetch() enhancement From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130210103745.GI2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <20130209134706.GB19909@stack.nl> <20130210103745.GI2522@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2013 09:03:39 -0700 Message-ID: <1360685019.4545.170.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:04:03 -0000 On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote: > On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote: > > On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote: > > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > > I'd like feedback on the attached patch, which adds support to our > > > > time_pps_fetch() implementation for the blocking behaviors described in > > > > section 3.4.3 of RFC 2783. The existing implementation can only return > > > > the most recently captured data without blocking. These changes add the > > > > ability to block (forever or with timeout) until a new event occurs. > > > > > > Index: sys/kern/kern_tc.c > > > > =================================================================== > > > > --- sys/kern/kern_tc.c (revision 246337) > > > > +++ sys/kern/kern_tc.c (working copy) > > > > @@ -1446,6 +1446,50 @@ > > > > * RFC 2783 PPS-API implementation. > > > > */ > > > > > > > > +static int > > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > > +{ > > > > [snip] > > > > + aseq = pps->ppsinfo.assert_sequence; > > > > + cseq = pps->ppsinfo.clear_sequence; > > > > + while (aseq == pps->ppsinfo.assert_sequence && > > > > + cseq == pps->ppsinfo.clear_sequence) { > > > Note that compilers are allowed to optimize these accesses even over > > > the sequential point, which is the tsleep() call. Only accesses to > > > volatile objects are forbidden to be rearranged. > > > > > I suggest to add volatile casts to pps in the loop condition. > > > > The memory pointed to by pps is global (other code may have a pointer to > > it); therefore, the compiler must assume that the tsleep() call (which > > invokes code in a different compilation unit) may modify it. > > > > Because volatile does not make concurrent access by multiple threads > > defined either, adding it here only seems to slow down the code > > (potentially). > The volatile guarantees that the compiler indeed reloads the value on > read access. Conceptually, the tsleep() does not modify or even access > the checked fields, and compiler is allowed to note this by whatever > methods (LTO ?). > > More, the standard says that an implementation is allowed to not evaluate > part of the expression if no side effects are produced, even by calling > a function. > > I agree that for practical means, the _currently_ used compilers should > consider the tsleep() call as the sequential point. But then the volatile > qualifier cast applied for the given access would not change the code as > well. > Doesn't this then imply that essentially every driver has this problem, and for that matter, every sequence of code anywhere in the base involving "loop while repeatedly sleeping, then waking and checking the state of some data for changes"? I sure haven't seen that many volatile qualifiers scattered around the code. -- Ian > > > > > > + err = tsleep(pps, PCATCH, "ppsfch", timo); > > > > + if (err == EWOULDBLOCK && fapi->timeout.tv_sec == -1) { > > > > + continue; > > > > + } else if (err != 0) { > > > > + return (err); > > > > + } > > > > + } > > > > + } > > -- > > Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 16:20:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C4BCD0A for ; Tue, 12 Feb 2013 16:20:28 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 2F745F79 for ; Tue, 12 Feb 2013 16:20:28 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c13so343233ieb.9 for ; Tue, 12 Feb 2013 08:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=RehjMpU7uJPj8kgkT5WNzSDQPqcivL/P2ThT470Aoa0=; b=SQjXjmB7WUKhQCCaUpM4q1NI+cG8zRwfrMuJueJsMiS6Zn17Y0BdDyRNNumCX9edSV fxcMNr1RRRzHAEBz8A98Sd6c9+G6VySjD3fMjTcau6eIoecCqnz8c1gxUPj48UTbnbGz RdxC0LUcBwct/vt0td17SiW4SKlqQx1uqiu3Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer:x-gm-message-state; bh=RehjMpU7uJPj8kgkT5WNzSDQPqcivL/P2ThT470Aoa0=; b=bnkOes7b12ILgS4GFkTRkNI9B5Hyzs3+k0vnnwrtbzxT+BvJl+QbltAdQGilGzp5Cc 5AN3nUaqnoHTcml09E3ghya4aCDMB9o/4kpaqAGc8kGDWpR4FYEL8a0/+RNZZNcBPy9+ MlaYICX7dTdvUbmRSI2MczOjjmNhwpVsZQEuVs2YShWBNCQBr5l4N6epXEqvFr6ou9vN F5/c/wTJJAC47zCAKSV2Jlp4a4G7DWexrKuY9jUk/7ZT9GZr1INy9N86SyQJAPOEk1LS Z2Ri4uEwMjjJkCeUa/6fpmoXBVmOtKZCJyBOXBjLCSuyEEP7OmRSLFRonIjS2sn2ysgH EQFA== X-Received: by 10.50.159.162 with SMTP id xd2mr4495480igb.11.1360686027662; Tue, 12 Feb 2013 08:20:27 -0800 (PST) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPS id fb10sm34755990igb.1.2013.02.12.08.20.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:20:26 -0800 (PST) From: Kevin Day Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Obscure platform testbed Message-Id: Date: Tue, 12 Feb 2013 10:20:23 -0600 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmi2z3ouZTaM1U2HC/vUT9zNsjuL+MgSfrBXGtq/Gw0JiVIuXOStL8mbOSl5vhB+5WWLWn7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:20:28 -0000 I'm not sure if this is the right place to post this, so if you know of = anyone who may be interested in this please forward to them. Right now = my company (your.org) does the free amd64/i386 VMs for FreeBSD = developers. For an unrelated project, we're trying to build a testbed of many of the = more obscure *nix boxes, both running their native OS and a modern OS. = As an example, we've now got two SGI O2 R10K boxes, one running IRIX and = one running NetBSD. We're planning on doing the same for Sparc64(Solaris = and FreeBSD), VAX, ARM, etc. Where possible we'll have NFS mounted home = directories and NIS to have shared logins across the "cluster". First, would any of you find this useful? If this is really only useful = for us, I won't bother trying to make this scale beyond our own need for = this. If this is popular enough to warrant the extra time, it wouldn't = be much more work to make this available to any developer who could use = it.=20 Second, do any of you have older non-intel boxes that are just gathering = dust, that are complete enough to install an OS and plug into ethernet? = If it's otherwise heading to a dumpster one day, we'd happily pay for = shipping to put it to good/public use. -- Kevin From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 17:16:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D478CE1 for ; Tue, 12 Feb 2013 17:16:09 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 283792E3 for ; Tue, 12 Feb 2013 17:16:09 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r1CHG8IV065613; Tue, 12 Feb 2013 12:16:08 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id r1CHG8qs065612; Tue, 12 Feb 2013 12:16:08 -0500 (EST) (envelope-from lidl) Date: Tue, 12 Feb 2013 12:16:08 -0500 From: Kurt Lidl To: Wojciech Puchar Subject: Re: building select ports for packaging on install media Message-ID: <20130212171608.GA65437@pix.net> References: <20130211192432.GA54378@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:16:09 -0000 On Tue, Feb 12, 2013 at 04:29:45PM +0100, Wojciech Puchar wrote: > > cdrom. > > > > What I'd like to do is augement that CD-ROM image with several > > binary packages, so I can just install them via 'sysinstall', > > rather than having to maintain a /usr/ports tree on every host > > and compile the same software again and again... > > why not just use pkg_add? Because there do not seem to be any packages available for 9.1-sparc64: root@host-75: uname -a FreeBSD host.pix.net 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Tue Feb 5 00:35:59 EST 2013 lidl@host.pix.net:/usr/obj/usr/src/sys/V120 sparc64 root@host-76: pkg install nettop Updating repository catalogue pkg: http://pkg.freebsd.org/freebsd:9:sparc64:64/latest/repo.txz: Not Found -Kurt From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 20:14:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16FCE505; Tue, 12 Feb 2013 20:14:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (we-in-x0231.1e100.net [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD01E87; Tue, 12 Feb 2013 20:14:22 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id d7so407546wer.22 for ; Tue, 12 Feb 2013 12:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HzlO/boktjRK1MP4rSb0ybjAuOMjOFOqDVRt/Rw1L+A=; b=YBnQx0kQKeVbaKngl9A4u+g+I3sLCotQ+lhqyt0+6aD3heF6hZu8/0vVE2d2R2+4aD +XS8aMYCpklIFGX7ZQYopjJ410xY4pJAgbv/Po9ptMQ0xCkcXPZczIkaXiovf/LC667l G+krBHuEiMA2qWq9zyZqmNV4y2Prcb9x1D3lH1hHgVrQXWVUKfHR9UN40vyjnWEUnorX QuQFGk8jRhclRQFWnzKXLO8RcUlDo9Dvo0Ww2abbePh7J0aRefTwU+u41hiNOl5BVHGS UjtSqGKirD3M9XMZk0C38RrlnvCrbvOORb5iKYIj2ZVVwDMu35F8HvJKDwoVGddSGY1p TOFg== MIME-Version: 1.0 X-Received: by 10.180.93.234 with SMTP id cx10mr5669204wib.34.1360700061637; Tue, 12 Feb 2013 12:14:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Tue, 12 Feb 2013 12:14:21 -0800 (PST) In-Reply-To: <1360685019.4545.170.camel@revolution.hippie.lan> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <20130209134706.GB19909@stack.nl> <20130210103745.GI2522@kib.kiev.ua> <1360685019.4545.170.camel@revolution.hippie.lan> Date: Tue, 12 Feb 2013 12:14:21 -0800 X-Google-Sender-Auth: g8lUSZPZEP3c6j130s-jaS_Dkl4 Message-ID: Subject: Re: Request for review, time_pps_fetch() enhancement From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:14:23 -0000 On 12 February 2013 08:03, Ian Lepore wrote: >> I agree that for practical means, the _currently_ used compilers should >> consider the tsleep() call as the sequential point. But then the volatile >> qualifier cast applied for the given access would not change the code as >> well. >> > > Doesn't this then imply that essentially every driver has this problem, > and for that matter, every sequence of code anywhere in the base > involving "loop while repeatedly sleeping, then waking and checking the > state of some data for changes"? I sure haven't seen that many volatile > qualifiers scattered around the code. Well, not even that - any cached access (eg to a softc member) after a mutex operation would be invalid. Hence why there's supposed to be some specific fairy dust sprinkled over those functions/inlines to tell the compiler to invalidate local copies of memory structures. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 20:34:14 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1AEA8A71; Tue, 12 Feb 2013 20:34:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7E31DF54; Tue, 12 Feb 2013 20:34:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1CKY8Vm067806; Tue, 12 Feb 2013 22:34:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1CKY8Vm067806 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1CKY8kT067805; Tue, 12 Feb 2013 22:34:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Feb 2013 22:34:08 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Request for review, time_pps_fetch() enhancement Message-ID: <20130212203408.GM2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <20130209134706.GB19909@stack.nl> <20130210103745.GI2522@kib.kiev.ua> <1360685019.4545.170.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bnxx4g3oiWbQYxPJ" Content-Disposition: inline In-Reply-To: <1360685019.4545.170.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:34:14 -0000 --Bnxx4g3oiWbQYxPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2013 at 09:03:39AM -0700, Ian Lepore wrote: > On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote: > > On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote: > > > On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote: > > > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > > > I'd like feedback on the attached patch, which adds support to our > > > > > time_pps_fetch() implementation for the blocking behaviors descri= bed in > > > > > section 3.4.3 of RFC 2783. The existing implementation can only = return > > > > > the most recently captured data without blocking. These changes = add the > > > > > ability to block (forever or with timeout) until a new event occu= rs. > > >=20 > > > > > Index: sys/kern/kern_tc.c > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > --- sys/kern/kern_tc.c (revision 246337) > > > > > +++ sys/kern/kern_tc.c (working copy) > > > > > @@ -1446,6 +1446,50 @@ > > > > > * RFC 2783 PPS-API implementation. > > > > > */ > > > > > =20 > > > > > +static int > > > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > > > +{ > > > > > [snip] > > > > > + aseq =3D pps->ppsinfo.assert_sequence; > > > > > + cseq =3D pps->ppsinfo.clear_sequence; > > > > > + while (aseq =3D=3D pps->ppsinfo.assert_sequence && > > > > > + cseq =3D=3D pps->ppsinfo.clear_sequence) { > > > > Note that compilers are allowed to optimize these accesses even over > > > > the sequential point, which is the tsleep() call. Only accesses to > > > > volatile objects are forbidden to be rearranged. > > >=20 > > > > I suggest to add volatile casts to pps in the loop condition. > > >=20 > > > The memory pointed to by pps is global (other code may have a pointer= to > > > it); therefore, the compiler must assume that the tsleep() call (which > > > invokes code in a different compilation unit) may modify it. > > >=20 > > > Because volatile does not make concurrent access by multiple threads > > > defined either, adding it here only seems to slow down the code > > > (potentially). > > The volatile guarantees that the compiler indeed reloads the value on > > read access. Conceptually, the tsleep() does not modify or even access > > the checked fields, and compiler is allowed to note this by whatever > > methods (LTO ?). > >=20 > > More, the standard says that an implementation is allowed to not evalua= te > > part of the expression if no side effects are produced, even by calling > > a function. > >=20 > > I agree that for practical means, the _currently_ used compilers should > > consider the tsleep() call as the sequential point. But then the volati= le > > qualifier cast applied for the given access would not change the code as > > well. > >=20 >=20 > Doesn't this then imply that essentially every driver has this problem, > and for that matter, every sequence of code anywhere in the base > involving "loop while repeatedly sleeping, then waking and checking the > state of some data for changes"? I sure haven't seen that many volatile > qualifiers scattered around the code. No, it does not imply that every driver has this problem. A typical driver provides the mutual exclusion for access of the shared data, which means using locks. Locks include neccessary barries to ensure the visibility of the changes, in particular the compiler barriers. --Bnxx4g3oiWbQYxPJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRGqdAAAoJEJDCuSvBvK1BBRUP/2znbzWCkfxBUxHS/1zj4Nba sEIzYHvyzkMGRCXbEh65NoUb2wpNdTTOuqKoCWAVs+Zi81ZJOX8DbC9tol+5gvzj nprF2FOxHLDDykd3E8wo3i9U8CTgZ4VkES/keycRa5ZU7bTj70evNCcv2cZiN45L I07QHbyc85rNwooctagW8c0K6P+r0YPg0Ap0GPHFa3Is00zgSeVtCXUQh1wgLull wi+ClB2ipi+W57jeSu0oD/2toQTq59TKaur1mFHY629BV9rm8c4cEtGSQbZADQgB FFIFgvJmY6PT2xlpSKCxeVcF7hzdjcuWrJGoqDWECrVh6roTKTBGCrQReLF5k+8I Gn627aAzY8A8tm3Na9SrH34mQcSAJWgpMaH43HmH0E70BQdBNGS/KARv1jts9pFQ hoi5AIJiaEaFTz+fKd4m6z6DvzenBMo0cdGrDi+BFIs/5DiXQa0Re/dcK3bbcZWa zWpd1RukjJBbUgaa+A6Z+A5QLZMwoqFCQSf7CbtjW10wbxNiFiAQT+LYSNoCxyQ7 0kLUYARF6OxKJTeiys2lilXD9QTC0G7W+MC5i6qMb76fDvkl/wf/zqd65ZJq/JTJ Ayc9tmuyiUXRguUtcR35zZZTA0og6pHVvGXsw/qc9hToHAP6HSVDidGAHC1e6ErV a40gnMmmeOEKiL4zH5d3 =q+K1 -----END PGP SIGNATURE----- --Bnxx4g3oiWbQYxPJ-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 21:51:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 166C0B53; Tue, 12 Feb 2013 21:51:00 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA983A7; Tue, 12 Feb 2013 21:50:58 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id dq12so467008wgb.12 for ; Tue, 12 Feb 2013 13:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=0pyKx6O5IfMTqBWxeerN64IwsXPidHIkU+7fg6D5/R0=; b=KQJhnrtt2Y7vZPtL6KNb529LHDootzbKV8mp4nY3iNiVuu5ZMAVwCKnl7v1WLqSWch Hp7UBUQPd8SoeDLhwBXYbXd+/VTiK1zIVbuK+r9Z2SNuS/WXeINX642X7Noligs+onkv 5n/zBi4cYxUF3tb+iDSuJKHxed6mP4mdp1CxCGnqS2YQpTO86oTcsQCBE4gffkkuz0ck mwaCffc2wRFENVUaAjBR4aimz8XP/+OeJ+8sP7JjAWAtHBw4I1c8lKFsKpqc1UMl1FJ1 LuVTsKcigbsgzBazg9iRmyooMIhZoVHYBTAkIsJ55WzuxvS7Ep4jW2b6mTs1F6Xl4XKz Gwkg== X-Received: by 10.194.92.65 with SMTP id ck1mr34075821wjb.54.1360705857920; Tue, 12 Feb 2013 13:50:57 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id hb9sm39149205wib.3.2013.02.12.13.50.56 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 12 Feb 2013 13:50:57 -0800 (PST) Sender: Mikolaj Golub Date: Tue, 12 Feb 2013 23:50:54 +0200 From: Mikolaj Golub To: John Baldwin Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130212215054.GA9839@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301241120.52054.jhb@freebsd.org> <201301251531.43540.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301251531.43540.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Kostik Belousov , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 21:51:00 -0000 On Fri, Jan 25, 2013 at 03:31:43PM -0500, John Baldwin wrote: > BTW, one off-ball thought I have is that I would like to have a mode where > libprocstat operates on a core file (of a process, not a kernel crash dump), > so it could list the threads from a core dump, and possibly file descriptor > info (if PR kern/173723 is implemented). > > We certainly could have a 'raw' mode where it spat out name: value or XML > of the entire kinfo_proc perhaps. > It looks very interesting! Do you mean something like this? root@lisa:/root # sh -c 'kill -5 $$' Trace/BPT trap (core dumped) root@lisa:/root # ls -l sh.core -rw------- 1 root wheel 8790016 Feb 12 21:17 sh.core root@lisa:/root # procstat sh.core PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM 674 657 674 657 657 1 root - FreeBSD ELF32 sh root@lisa:/root # procstat -f sh.core PID COMM FD T V FLAGS REF OFFSET PRO NAME 674 sh text v r r-------- - - - /bin/sh 674 sh ctty v c rw------- - - - /dev/pts/0 674 sh cwd v d r-------- - - - /root 674 sh root v d r-------- - - - / 674 sh 0 v c rw------- 8 2537 - /dev/pts/0 674 sh 1 v c rw------- 8 2537 - /dev/pts/0 674 sh 2 v c rw------- 8 2537 - /dev/pts/0 root@lisa:/root # procstat -v sh.core PID START END PRT RES PRES REF SHD FL TP PATH 674 0x8048000 0x8064000 r-x 28 0 1 0 CN-- vn /bin/sh 674 0x8064000 0x8066000 rw- 2 0 1 0 ---- df 674 0x28064000 0x2807a000 r-x 22 0 17 0 CN-- vn /libexec/ld-elf.so.1 674 0x2807a000 0x28083000 rw- 9 0 1 0 ---- df 674 0x28084000 0x280a3000 r-x 31 32 2 1 CN-- vn /lib/libedit.so.7 674 0x280a3000 0x280a5000 rw- 2 0 1 0 C--- vn /lib/libedit.so.7 674 0x280a5000 0x280a7000 rw- 0 0 0 0 ---- -- 674 0x280a7000 0x280e0000 r-x 57 0 4 2 CN-- vn /lib/libncurses.so.8 674 0x280e0000 0x280e3000 rw- 3 0 1 0 C--- vn /lib/libncurses.so.8 674 0x280e3000 0x28213000 r-x 304 0 34 17 CN-- vn /lib/libc.so.7 674 0x28213000 0x2821a000 rw- 7 0 1 0 C--- vn /lib/libc.so.7 674 0x2821a000 0x28243000 rw- 16 0 2 0 ---- df 674 0x28400000 0x28c00000 rw- 24 0 2 0 ---- df 674 0xbfbdf000 0xbfbff000 rwx 3 0 1 0 ---D df 674 0xbfbff000 0xbfc00000 r-x 0 0 20 0 CN-- ph Here is my attempt to implement it: http://people.freebsd.org/~trociny/procstat_core.1.patch The patch needs much work yet, especially the userland part, but looks like it is good enough for demonstration purposes to discuss how this should be done properly. So, procstat data is stored in a core as note sections with name "FreeBSD" and types NT_PROCSTAT_PROC, NT_PROCSTAT_FILES, ... The current format of notes is a header of sizeof(int) and data in the format as it is returned by a related sysctl call. I think the header should provide some versioning and for the cases I implemented (kinfo_proc, kinfo_file, kinfo_vmentry) it contains a value of the corresponding kinfo struct size (e.g. KINFO_VMENTRY_SIZE). It might be not the best solution and I would be glad for suggestions. (BTW, why don't we have constants like KINFO_VMENTRY_SIZE defined for all archs?) To avoid code duplication I changed the code of kinfo sysctl handlers to output kinfo data to sbuf instead of calling SYSCTL_OUT directly so these functions could be used by both sysctl handlers and the coredump routine. Another thing I am not sure about is writing procstat data in the coredump routine. The coredump routine on the first pass calculates core sizes and on the second pass does actual writing. I added procstat in that way that procstat data is collected on the first run to internal buffers and on the second pass is copied from the buffers to the core. I could do this another way, e.g running kern_proc_*out() twice, on the fist pass with tiny buffer and a drain routine that would calculate data length, but this looks less efficient, complicates things and currently I am not sure that procstat sizes are not changeable between the passes. The issue with my approach I see is that after the first pass, before actually doing allocations we check corefile limits. I do allocations before checking the limit, so potentially using some kernel space when it might not be allowed by limits. Is this a problem I should worry and try another approach? I do nothing yet for freebsd32 compat case. I suppose I should check if the dumping process is running 32 binary and store procstat data in freebsd32 format? As I said there is much to do in userland, and I would like to concentrate on the kernel part and the format first, but I would be glad if somebody helps me with the problem I faced linking libelf to libprocstat. With the modifications to the libprocstat makefile: -DPADD= ${LIBKVM} ${LIBUTIL} -LDADD= -lkvm -lutil +DPADD= ${LIBELF} ${LIBKVM} ${LIBUTIL} +LDADD= -lelf -lkvm -lutil buildworld fails with the error: make: don't know how to make /scratch2/tmp/trociny/obj/i386.i386/home/trociny/svn/base/head/tmp/usr/lib/libelf.a. Stop -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 11:49:03 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 272188D8 for ; Wed, 13 Feb 2013 11:49:03 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D1028CD3 for ; Wed, 13 Feb 2013 11:49:02 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id B67976A97 for ; Wed, 13 Feb 2013 11:48:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7D544A36A; Wed, 13 Feb 2013 12:48:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: hackers@freebsd.org Subject: Turn on CLANG_IS_CC when not building gcc Date: Wed, 13 Feb 2013 12:48:55 +0100 Message-ID: <86wquc3048.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 11:49:03 -0000 The following patches (for head and stable/9) automatically enable CLANG_IS_CC if GCC is disabled but CLANG is not. Any objections? Index: head/share/mk/bsd.own.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/share/mk/bsd.own.mk (revision 246325) +++ head/share/mk/bsd.own.mk (working copy) @@ -526,6 +526,8 @@ MK_CLANG_EXTRAS:=3D no MK_CLANG_FULL:=3D no MK_CLANG_IS_CC:=3D no +.elif ${MK_GCC} =3D=3D "no" +MK_CLANG_IS_CC:=3D yes .endif =20 # Index: stable/9/share/mk/bsd.own.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- stable/9/share/mk/bsd.own.mk (revision 244989) +++ stable/9/share/mk/bsd.own.mk (working copy) @@ -581,6 +581,8 @@ =20 .if ${MK_CLANG} =3D=3D "no" MK_CLANG_IS_CC:=3D no +.elif ${MK_GCC} =3D=3D "no" +MK_CLANG_IS_CC:=3D yes .endif =20 MK_LIBCPLUSPLUS?=3D no DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 11:55:37 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B2EDA76 for ; Wed, 13 Feb 2013 11:55:37 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 29ADBD10 for ; Wed, 13 Feb 2013 11:55:37 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 48C535C43; Wed, 13 Feb 2013 12:55:33 +0100 (CET) Message-ID: <511B7F37.4010409@FreeBSD.org> Date: Wed, 13 Feb 2013 12:55:35 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , hackers@freebsd.org Subject: Re: Turn on CLANG_IS_CC when not building gcc References: <86wquc3048.fsf@ds4.des.no> In-Reply-To: <86wquc3048.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 11:55:37 -0000 On 2013-02-13 12:48, Dag-Erling Sm=C3=B8rgrav wrote:> The following patch= es (for head and stable/9) automatically enable > CLANG_IS_CC if GCC is disabled but CLANG is not. Any objections? This looks fine to me. Otherwise, if ${CC} isn't set to clang, buildworld might fail in mysterious ways... :) From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 12:32:04 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B5A2F420; Wed, 13 Feb 2013 12:32:04 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 79E82EE7; Wed, 13 Feb 2013 12:32:04 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 8ABB46AF5; Wed, 13 Feb 2013 12:32:03 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 545E0A373; Wed, 13 Feb 2013 13:32:03 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Dimitry Andric Subject: Re: Turn on CLANG_IS_CC when not building gcc References: <86wquc3048.fsf@ds4.des.no> <511B7F37.4010409@FreeBSD.org> Date: Wed, 13 Feb 2013 13:32:03 +0100 In-Reply-To: <511B7F37.4010409@FreeBSD.org> (Dimitry Andric's message of "Wed, 13 Feb 2013 12:55:35 +0100") Message-ID: <86obfo2y4c.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 12:32:04 -0000 Dimitry Andric writes: > Dag-Erling Sm=C3=B8rgrav writes: > > The following patches (for head and stable/9) automatically enables > > CLANG_IS_CC if GCC is disabled but CLANG is not. Any objections? > This looks fine to me. Otherwise, if ${CC} isn't set to clang, > buildworld might fail in mysterious ways... :) Not mysterious at all - it fails while building xlint in the cross-tools phase because, while bsd.{lib,prog}.mk invoke the compiler as "clang" and not "cc", lint itself tries invokes "cc" to generate the lint libraries (/usr/libdata/lint/llib-l{posix,stdc}.ln). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 15:16:44 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AA687F4 for ; Wed, 13 Feb 2013 15:16:44 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8B05091F for ; Wed, 13 Feb 2013 15:16:43 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1DFGZBd000509 for ; Wed, 13 Feb 2013 08:16:35 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1DFGW2Y042368; Wed, 13 Feb 2013 08:16:32 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Request for review, time_pps_fetch() enhancement From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130212203408.GM2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <20130209134706.GB19909@stack.nl> <20130210103745.GI2522@kib.kiev.ua> <1360685019.4545.170.camel@revolution.hippie.lan> <20130212203408.GM2522@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Feb 2013 08:16:32 -0700 Message-ID: <1360768592.4545.209.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:16:44 -0000 On Tue, 2013-02-12 at 22:34 +0200, Konstantin Belousov wrote: > On Tue, Feb 12, 2013 at 09:03:39AM -0700, Ian Lepore wrote: > > On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote: > > > On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote: > > > > On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote: > > > > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > > > > I'd like feedback on the attached patch, which adds support to our > > > > > > time_pps_fetch() implementation for the blocking behaviors described in > > > > > > section 3.4.3 of RFC 2783. The existing implementation can only return > > > > > > the most recently captured data without blocking. These changes add the > > > > > > ability to block (forever or with timeout) until a new event occurs. > > > > > > > > > > Index: sys/kern/kern_tc.c > > > > > > =================================================================== > > > > > > --- sys/kern/kern_tc.c (revision 246337) > > > > > > +++ sys/kern/kern_tc.c (working copy) > > > > > > @@ -1446,6 +1446,50 @@ > > > > > > * RFC 2783 PPS-API implementation. > > > > > > */ > > > > > > > > > > > > +static int > > > > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > > > > +{ > > > > > > [snip] > > > > > > + aseq = pps->ppsinfo.assert_sequence; > > > > > > + cseq = pps->ppsinfo.clear_sequence; > > > > > > + while (aseq == pps->ppsinfo.assert_sequence && > > > > > > + cseq == pps->ppsinfo.clear_sequence) { > > > > > Note that compilers are allowed to optimize these accesses even over > > > > > the sequential point, which is the tsleep() call. Only accesses to > > > > > volatile objects are forbidden to be rearranged. > > > > > > > > > I suggest to add volatile casts to pps in the loop condition. > > > > > > > > The memory pointed to by pps is global (other code may have a pointer to > > > > it); therefore, the compiler must assume that the tsleep() call (which > > > > invokes code in a different compilation unit) may modify it. > > > > > > > > Because volatile does not make concurrent access by multiple threads > > > > defined either, adding it here only seems to slow down the code > > > > (potentially). > > > The volatile guarantees that the compiler indeed reloads the value on > > > read access. Conceptually, the tsleep() does not modify or even access > > > the checked fields, and compiler is allowed to note this by whatever > > > methods (LTO ?). > > > > > > More, the standard says that an implementation is allowed to not evaluate > > > part of the expression if no side effects are produced, even by calling > > > a function. > > > > > > I agree that for practical means, the _currently_ used compilers should > > > consider the tsleep() call as the sequential point. But then the volatile > > > qualifier cast applied for the given access would not change the code as > > > well. > > > > > > > Doesn't this then imply that essentially every driver has this problem, > > and for that matter, every sequence of code anywhere in the base > > involving "loop while repeatedly sleeping, then waking and checking the > > state of some data for changes"? I sure haven't seen that many volatile > > qualifiers scattered around the code. > > No, it does not imply that every driver has this problem. > A typical driver provides the mutual exclusion for access of > the shared data, which means using locks. Locks include neccessary > barries to ensure the visibility of the changes, in particular the > compiler barriers. Ohhhh. I had never considered that using mutexes had other side effects. So is there a correct MI way to invoke the right barrier magic in a situation like this? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 16:18:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F01CAAC6 for ; Wed, 13 Feb 2013 16:18:27 +0000 (UTC) (envelope-from natris@centrum.cz) Received: from gmmr4.centrum.cz (gmmr4.centrum.cz [IPv6:2a00:da80:1:502::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA36DEA for ; Wed, 13 Feb 2013 16:18:27 +0000 (UTC) Received: from mail1008.cent (unknown [10.32.3.100]) by gmmr4.centrum.cz (Postfix) with ESMTP id A749C11D for ; Wed, 13 Feb 2013 17:18:25 +0100 (CET) Received: by mail1008.cent (Postfix, from userid 33) id A1A7C40570F46; Wed, 13 Feb 2013 17:18:25 +0100 (CET) To: Subject: =?utf-8?q?SIGSEGV=2FSIGBUS_when_accessing_after_end_of_mmapped_file=3B_why_it_differs_with_GCC=3F?= Received: from 212.4.138.50 (X-Forwarded-For: 212.4.138.50) by mail1008.centrum.cz (centrum.cz multimail) with HTTP Date: Wed, 13 Feb 2013 17:18:25 +0100 From: X-Mailer: Centrum Email 5.3 X-Priority: 3 X-Original-From: natris@centrum.cz MIME-Version: 1.0 Message-Id: <20130213171825.76D3A9DC@centrum.cz> X-Maser: Georgo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 13 Feb 2013 16:56:03 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:18:28 -0000 Hello, I am porting an application which maps files into the memory and works directly with the memory. When doing this, it can happen that when someone resizes the file so that part of the previously mapped region is no longer backed by the file, synchronous signal is sent to the process which needs to be handled.   On all other platforms than FreeBSD I have tested (Solaris, Linux, Darwin, HP-UX) the signal in question is SIGBUS. However on FreeBSD, depending on the >>compiler<< used, it is either SIGBUS or SIGSEGV. When I compile the binary with "gcc version 4.2.1 20070831 patched [FreeBSD], amd64", the signal is SIGBUS, when i use "gcc version 4.7.3 20121103 (prerelease) (FreeBSD Ports Collection)", the signal is SIGSEGV. Please note that one of the versions of gcc between 4.2 and 4.7 also caused SIGSEFV to be sent but this did not matter for me as I did not need to use that version; I however need gcc 4.7 to work because of c++11 stuff that my project has recently started to use.   Unfortunately registering signal handler on SIGSEGV is very inconvenient for me; I would prefer to somehow switch the behavior to be sane.   Please anyone has an idea whether or how this could be achieved? I have tried to find out why, on single machine, just because of different gcc version, kernel sends different signal but I have never worked with fbsd kernel before and so my search did not succeed so far.   Machine in question runs amd64 FreeBSD 9.1-RC2, but this has also happened to me with older version of FreeBSD.     gcc 4.2 (same happens also with libstdc++ and co. from gcc 4.2): Program received signal SIGBUS, Bus error. (gdb) i shared From                To                  Syms Read   Shared Object Library 0x0000000800f2ef70  0x0000000800f3ee68  Yes (*)     /libexec/ld-elf.so.1 0x000000080114d710  0x0000000801159748  Yes (*)     /lib/libthr.so.3 0x00000008013c2d30  0x000000080142c656  Yes         /usr/local/lib/gcc47/libstdc++.so.6 0x00000008016737c0  0x00000008016891b8  Yes (*)     /lib/libm.so.5 0x0000000801893930  0x00000008018a3088  Yes         /usr/local/lib/gcc47/libgcc_s.so.1 0x0000000801ad71d0  0x0000000801ba9358  Yes (*)     /lib/libc.so.7   gcc 4.7: Program received signal SIGSEGV, Segmentation fault. (gdb) i shared From                To                  Syms Read   Shared Object Library 0x0000000800f5ef70  0x0000000800f6ee68  Yes (*)     /libexec/ld-elf.so.1 0x000000080117d710  0x0000000801189748  Yes (*)     /lib/libthr.so.3 0x00000008013f2d30  0x000000080145c656  Yes         /usr/local/lib/gcc47/libstdc++.so.6 0x00000008016a37c0  0x00000008016b91b8  Yes (*)     /lib/libm.so.5 0x00000008018c3930  0x00000008018d3088  Yes         /usr/local/lib/gcc47/libgcc_s.so.1 0x0000000801b071d0  0x0000000801bd9358  Yes (*)     /lib/libc.so.7 I would be glad for any hint or information. Kind Regards, Ondrej Kolacek From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 17:14:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2A6DAF18 for ; Wed, 13 Feb 2013 17:14:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mx1.freebsd.org (Postfix) with ESMTP id EE29E20C for ; Wed, 13 Feb 2013 17:14:04 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id tb18so1486198obb.17 for ; Wed, 13 Feb 2013 09:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gBR3aMciBtCDFd9WLHJT5gMAw8Bg/qrhzUuWFXukMc4=; b=H2fSNd7mGCbRZq/SBDk202Flvqputdt/V52yjalqf6wnHdGiwO0XPEpE0Mzgypx4cK ttuVvOLZCeY5mPHOWVPhDfZlyuaKupXaP6iEEJIWHP6+N01BJsW4xwkP6FwhrXtvHnVb HWPn6Pb4NejSLv8NDfaKjwEVaCpD503p3/jYQL5VxzUJhK4LlED1NK4LS2UPaMwPofLk afcHOV+2nw46T5XRxWc/ucfcCK571L8aJDIIBDus+mLnuj4jcw7LBa6SMALitM5ahQeN YoMAqdVMFt83NlmC7DMUA2FIUwlOzEMvjaUEnME1d3fYUCLF9yyNpxJotY0MO99HRkLq O2rw== MIME-Version: 1.0 X-Received: by 10.182.112.34 with SMTP id in2mr17236097obb.80.1360775638255; Wed, 13 Feb 2013 09:13:58 -0800 (PST) Received: by 10.76.109.236 with HTTP; Wed, 13 Feb 2013 09:13:58 -0800 (PST) In-Reply-To: <20130213171825.76D3A9DC@centrum.cz> References: <20130213171825.76D3A9DC@centrum.cz> Date: Wed, 13 Feb 2013 12:13:58 -0500 Message-ID: Subject: Re: SIGSEGV/SIGBUS when accessing after end of mmapped file; why it differs with GCC? From: Ryan Stone To: natris@centrum.cz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:14:05 -0000 On Wed, Feb 13, 2013 at 11:18 AM, wrote: > Hello, > I am porting an application which maps files into the memory and works > directly with the memory. When doing this, it can happen that when someone > resizes the file so that part of the previously mapped region is no longer > backed by the file, synchronous signal is sent to the process which needs > to be handled. > > On all other platforms than FreeBSD I have tested (Solaris, Linux, Darwin, > HP-UX) the signal in question is SIGBUS. However on FreeBSD, depending on > the >>compiler<< used, it is either SIGBUS or SIGSEGV. When I compile the > binary with "gcc version 4.2.1 20070831 patched [FreeBSD], amd64", the > signal is SIGBUS, when i use "gcc version 4.7.3 20121103 (prerelease) > (FreeBSD Ports Collection)", the signal is SIGSEGV. Please note that one of > the versions of gcc between 4.2 and 4.7 also caused SIGSEFV to be sent but > this did not matter for me as I did not need to use that version; I however > need gcc 4.7 to work because of c++11 stuff that my project has recently > started to use. > > Unfortunately registering signal handler on SIGSEGV is very inconvenient > for me; I would prefer to somehow switch the behavior to be sane. > > Please anyone has an idea whether or how this could be achieved? I have > tried to find out why, on single machine, just because of different gcc > version, kernel sends different signal but I have never worked with fbsd > kernel before and so my search did not succeed so far. > > Machine in question runs amd64 FreeBSD 9.1-RC2, but this has also happened > to me with older version of FreeBSD. > > > gcc 4.2 (same happens also with libstdc++ and co. from gcc 4.2): > Program received signal SIGBUS, Bus error. > (gdb) i shared > From To Syms Read Shared Object Library > 0x0000000800f2ef70 0x0000000800f3ee68 Yes (*) /libexec/ld-elf.so.1 > 0x000000080114d710 0x0000000801159748 Yes (*) /lib/libthr.so.3 > 0x00000008013c2d30 0x000000080142c656 Yes > /usr/local/lib/gcc47/libstdc++.so.6 > 0x00000008016737c0 0x00000008016891b8 Yes (*) /lib/libm.so.5 > 0x0000000801893930 0x00000008018a3088 Yes > /usr/local/lib/gcc47/libgcc_s.so.1 > 0x0000000801ad71d0 0x0000000801ba9358 Yes (*) /lib/libc.so.7 > > gcc 4.7: > Program received signal SIGSEGV, Segmentation fault. > (gdb) i shared > From To Syms Read Shared Object Library > 0x0000000800f5ef70 0x0000000800f6ee68 Yes (*) /libexec/ld-elf.so.1 > 0x000000080117d710 0x0000000801189748 Yes (*) /lib/libthr.so.3 > 0x00000008013f2d30 0x000000080145c656 Yes > /usr/local/lib/gcc47/libstdc++.so.6 > 0x00000008016a37c0 0x00000008016b91b8 Yes (*) /lib/libm.so.5 > 0x00000008018c3930 0x00000008018d3088 Yes > /usr/local/lib/gcc47/libgcc_s.so.1 > 0x0000000801b071d0 0x0000000801bd9358 Yes (*) /lib/libc.so.7 > > > I would be glad for any hint or information. > Kind Regards, > Ondrej Kolacek > _______________________________________________ > 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" I think that setting sysctl machdep.prot_fault_translation=1 would do what you want. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 17:41:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D41573CF for ; Wed, 13 Feb 2013 17:41:12 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 27CB52E7 for ; Wed, 13 Feb 2013 17:41:11 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1DHf10b001570 for ; Wed, 13 Feb 2013 18:41:01 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1DHf1BJ001567 for ; Wed, 13 Feb 2013 18:41:01 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 13 Feb 2013 18:41:01 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: disk errors on heavy write I/O Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 13 Feb 2013 18:41:01 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:41:12 -0000 when doing lots of writes (large file) after few tens of gigabytes i've got as below. smartctl -t long (full surface test) reports no errors my disk is ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) i have the same drive model at other place, and got into the same situation once. any ideas what it is. i cannot find any firmware update. Feb 13 18:29:20 wojtek kernel: ahcich0: Timeout on slot 25 port 0 Feb 13 18:29:20 wojtek kernel: ahcich0: is 00000000 cs fdffffff ss ffffffff rs ffffffff tfd c0 serr 00000000 cmd 0000da17 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 b0 9c bf 40 02 00 00 08 00 00 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Retrying command Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 10 74 0a 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 d0 31 10 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=17530617856, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 90 ef 15 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=17723260928, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 50 ad 1b 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=17915904000, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 10 6b 21 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=18108547072, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 d0 28 27 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=18301190144, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 90 e6 2c 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=18493833216, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 50 a4 32 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=18686476288, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 10 62 38 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=18879119360, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 d0 1f 3e 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=19071762432, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 20 90 dd 43 40 02 00 00 00 00 00 Feb 13 18:29:20 wojtek kernel: g_vfs_done():(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid Feb 13 18:29:20 wojtek kernel: ada0a[WRITE(offset=19264405504, length=16384)]error = 22 Feb 13 18:29:20 wojtek kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 19:12:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05CA4CFD for ; Wed, 13 Feb 2013 19:12:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB8FA0D for ; Wed, 13 Feb 2013 19:12:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1DJC83r042962; Wed, 13 Feb 2013 21:12:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1DJC83r042962 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1DJC8I0042961; Wed, 13 Feb 2013 21:12:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Feb 2013 21:12:08 +0200 From: Konstantin Belousov To: natris@centrum.cz Subject: Re: SIGSEGV/SIGBUS when accessing after end of mmapped file; why it differs with GCC? Message-ID: <20130213191208.GR2522@kib.kiev.ua> References: <20130213171825.76D3A9DC@centrum.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ms/uB3aZsWYC/mdj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:12:18 -0000 --ms/uB3aZsWYC/mdj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 12:13:58PM -0500, Ryan Stone wrote: > On Wed, Feb 13, 2013 at 11:18 AM, wrote: >=20 > > Hello, > > I am porting an application which maps files into the memory and works > > directly with the memory. When doing this, it can happen that when some= one > > resizes the file so that part of the previously mapped region is no lon= ger > > backed by the file, synchronous signal is sent to the process which nee= ds > > to be handled. > > > > On all other platforms than FreeBSD I have tested (Solaris, Linux, Darw= in, > > HP-UX) the signal in question is SIGBUS. However on FreeBSD, depending = on > > the >>compiler<< used, it is either SIGBUS or SIGSEGV. When I compile t= he > > binary with "gcc version 4.2.1 20070831 patched [FreeBSD], amd64", the > > signal is SIGBUS, when i use "gcc version 4.7.3 20121103 (prerelease) > > (FreeBSD Ports Collection)", the signal is SIGSEGV. Please note that on= e of > > the versions of gcc between 4.2 and 4.7 also caused SIGSEFV to be sent = but > > this did not matter for me as I did not need to use that version; I how= ever > > need gcc 4.7 to work because of c++11 stuff that my project has recently > > started to use. > > > > Unfortunately registering signal handler on SIGSEGV is very inconvenient > > for me; I would prefer to somehow switch the behavior to be sane. > > > > Please anyone has an idea whether or how this could be achieved? I have > > tried to find out why, on single machine, just because of different gcc > > version, kernel sends different signal but I have never worked with fbsd > > kernel before and so my search did not succeed so far. > > > > Machine in question runs amd64 FreeBSD 9.1-RC2, but this has also happe= ned > > to me with older version of FreeBSD. > > > > > > gcc 4.2 (same happens also with libstdc++ and co. from gcc 4.2): > > Program received signal SIGBUS, Bus error. > > (gdb) i shared > > From To Syms Read Shared Object Libra= ry > > 0x0000000800f2ef70 0x0000000800f3ee68 Yes (*) /libexec/ld-elf.so.1 > > 0x000000080114d710 0x0000000801159748 Yes (*) /lib/libthr.so.3 > > 0x00000008013c2d30 0x000000080142c656 Yes > > /usr/local/lib/gcc47/libstdc++.so.6 > > 0x00000008016737c0 0x00000008016891b8 Yes (*) /lib/libm.so.5 > > 0x0000000801893930 0x00000008018a3088 Yes > > /usr/local/lib/gcc47/libgcc_s.so.1 > > 0x0000000801ad71d0 0x0000000801ba9358 Yes (*) /lib/libc.so.7 > > > > gcc 4.7: > > Program received signal SIGSEGV, Segmentation fault. > > (gdb) i shared > > From To Syms Read Shared Object Libra= ry > > 0x0000000800f5ef70 0x0000000800f6ee68 Yes (*) /libexec/ld-elf.so.1 > > 0x000000080117d710 0x0000000801189748 Yes (*) /lib/libthr.so.3 > > 0x00000008013f2d30 0x000000080145c656 Yes > > /usr/local/lib/gcc47/libstdc++.so.6 > > 0x00000008016a37c0 0x00000008016b91b8 Yes (*) /lib/libm.so.5 > > 0x00000008018c3930 0x00000008018d3088 Yes > > /usr/local/lib/gcc47/libgcc_s.so.1 > > 0x0000000801b071d0 0x0000000801bd9358 Yes (*) /lib/libc.so.7 > > > > > > I would be glad for any hint or information. > > Kind Regards, > > Ondrej Kolacek > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 >=20 >=20 > I think that setting sysctl machdep.prot_fault_translation=3D1 would do w= hat > you want. This might be an indication of the issue with the toolchains you use, in particular, with the linker or csu. The default selection for the signal is based on the note osver, linked into the binary from crt1.o. Either linker omits the note, or wrong crt1 is used. You did not specified anything about version of the FreeBSD used, nor the exact compiler invocations. Using the crystal ball, I see the r244600 for HEAD and r244904 for stable/9, if you use --gc-sections flags. This is more or less consistent with what you reported, since gcc from ports uses binutils from ports, which have newer ld with bugfix already applied. --ms/uB3aZsWYC/mdj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRG+WHAAoJEJDCuSvBvK1BFtQQAJzAiDsyd4NDdJx01fzJmnn2 xcIx3FICcKLPX1guF5D/mp1uDUy/1XcN0rFk16GoAm3lVL9flK4Bqk9R8mjZsVpO UUHoMloFEwvZAtVlkNxWBJmEgcRFe3Ij4pluqC58p55ICR+axE/IL4R77W+bndKk iDRtNePm7t+t9gKX1iS8UV/LhvsLIQTckBltwNDgTgef0c2f3o6BH4DaB8harujz HYaTojOwtDlsHlsIRH307VJDTjUAzuKKBI6sQfnyW1qUcjJQ9pub56aiDRS2kQ6t SqvU82qX5Vk7Y4Ee0mlQl+Ut+sQBDSyEFHsHdU1KKb35RYfGr9czmlp8aerP4+xg +eRp8JbW6QV2SsJst9tzEP3hBGUjpfNUps5DWOvg+jioLMEN95LDczGaWJJZpIVb gBCfRgq7jso3KVvL+kXdWKYnj0ptVOyqTeOHif/+2GL8G8onSYnEwXn69Hc2ddB2 sND5IJkaA0xl9lmO0vHxlwGCQsbFGrpGEhXJ+V07D28Huu3Nx89Ju/HowtkJAq4V d57TxMXOrp43oip9K8uhVEQhZSqnfv2X2yQcCr3xQTMTauvL6eMVPPtez0bdRedU 11w1OxJAlsEcFCx0B9jJzS+b423GCpQrwvFvZh7Q1jOWgcpYVi6Q5DYmyZUuSnzf LcFLF0mHNmNyjhN9XzQT =izrt -----END PGP SIGNATURE----- --ms/uB3aZsWYC/mdj-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 19:38:31 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAAD661F; Wed, 13 Feb 2013 19:38:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 11B28B04; Wed, 13 Feb 2013 19:38:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1DJcQR2045824; Wed, 13 Feb 2013 21:38:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1DJcQR2045824 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1DJcQRT045823; Wed, 13 Feb 2013 21:38:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Feb 2013 21:38:26 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Request for review, time_pps_fetch() enhancement Message-ID: <20130213193826.GU2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <20130209134706.GB19909@stack.nl> <20130210103745.GI2522@kib.kiev.ua> <1360685019.4545.170.camel@revolution.hippie.lan> <20130212203408.GM2522@kib.kiev.ua> <1360768592.4545.209.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WRMGsLmc1wQc8NPq" Content-Disposition: inline In-Reply-To: <1360768592.4545.209.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:38:31 -0000 --WRMGsLmc1wQc8NPq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 08:16:32AM -0700, Ian Lepore wrote: > On Tue, 2013-02-12 at 22:34 +0200, Konstantin Belousov wrote: > > On Tue, Feb 12, 2013 at 09:03:39AM -0700, Ian Lepore wrote: > > > On Sun, 2013-02-10 at 12:37 +0200, Konstantin Belousov wrote: > > > > On Sat, Feb 09, 2013 at 02:47:06PM +0100, Jilles Tjoelker wrote: > > > > > On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wro= te: > > > > > > On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote: > > > > > > > I'd like feedback on the attached patch, which adds support t= o our > > > > > > > time_pps_fetch() implementation for the blocking behaviors de= scribed in > > > > > > > section 3.4.3 of RFC 2783. The existing implementation can o= nly return > > > > > > > the most recently captured data without blocking. These chan= ges add the > > > > > > > ability to block (forever or with timeout) until a new event = occurs. > > > > >=20 > > > > > > > Index: sys/kern/kern_tc.c > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > --- sys/kern/kern_tc.c (revision 246337) > > > > > > > +++ sys/kern/kern_tc.c (working copy) > > > > > > > @@ -1446,6 +1446,50 @@ > > > > > > > * RFC 2783 PPS-API implementation. > > > > > > > */ > > > > > > > =20 > > > > > > > +static int > > > > > > > +pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps) > > > > > > > +{ > > > > > > > [snip] > > > > > > > + aseq =3D pps->ppsinfo.assert_sequence; > > > > > > > + cseq =3D pps->ppsinfo.clear_sequence; > > > > > > > + while (aseq =3D=3D pps->ppsinfo.assert_sequence && > > > > > > > + cseq =3D=3D pps->ppsinfo.clear_sequence) { > > > > > > Note that compilers are allowed to optimize these accesses even= over > > > > > > the sequential point, which is the tsleep() call. Only accesses= to > > > > > > volatile objects are forbidden to be rearranged. > > > > >=20 > > > > > > I suggest to add volatile casts to pps in the loop condition. > > > > >=20 > > > > > The memory pointed to by pps is global (other code may have a poi= nter to > > > > > it); therefore, the compiler must assume that the tsleep() call (= which > > > > > invokes code in a different compilation unit) may modify it. > > > > >=20 > > > > > Because volatile does not make concurrent access by multiple thre= ads > > > > > defined either, adding it here only seems to slow down the code > > > > > (potentially). > > > > The volatile guarantees that the compiler indeed reloads the value = on > > > > read access. Conceptually, the tsleep() does not modify or even acc= ess > > > > the checked fields, and compiler is allowed to note this by whatever > > > > methods (LTO ?). > > > >=20 > > > > More, the standard says that an implementation is allowed to not ev= aluate > > > > part of the expression if no side effects are produced, even by cal= ling > > > > a function. > > > >=20 > > > > I agree that for practical means, the _currently_ used compilers sh= ould > > > > consider the tsleep() call as the sequential point. But then the vo= latile > > > > qualifier cast applied for the given access would not change the co= de as > > > > well. > > > >=20 > > >=20 > > > Doesn't this then imply that essentially every driver has this proble= m, > > > and for that matter, every sequence of code anywhere in the base > > > involving "loop while repeatedly sleeping, then waking and checking t= he > > > state of some data for changes"? I sure haven't seen that many volat= ile > > > qualifiers scattered around the code. > >=20 > > No, it does not imply that every driver has this problem. > > A typical driver provides the mutual exclusion for access of > > the shared data, which means using locks. Locks include neccessary > > barries to ensure the visibility of the changes, in particular the > > compiler barriers. >=20 > Ohhhh. I had never considered that using mutexes had other side > effects. So is there a correct MI way to invoke the right barrier magic > in a situation like this? My belief is that you do not need a barrier there. The only (slightly) problematic issue there is a purely theoretical possibility that a very smart compiler would omit the reload step. The volatile qualifier for the dererefence in the loop condition should close this, as I described in the very first reply. --WRMGsLmc1wQc8NPq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRG+uyAAoJEJDCuSvBvK1BWS0P/i8X5JG/rjIF57jyizv98ZYv MO5sDgLZ1WBffstFqZ6o1ZfUihFuXnRjY20AXgtu13wdPms3PF7WwYH/pnnfn0Nm V6f0FkHpuut3fJLZmHrHNfCDnm3BZf1wdxTeDBL7JQk9FLpFjtLVe0TGqhxthKOr HURDQ8edTSNu8FxDdrcUpnrB8dOvcNxbUXJCFcEs+xbb421GvH82yTWwvUUCQmVG SaAaq/NkdkrhwYej0a+XXSIHMkQxU7/fZ25jerGY4FBK5xcqV52Yh6HzXtr2V40K +1r2QxjT00xrqISBzI+ZUPd5YMicX7JgnCKnhopmRPpjs3lZsDcA7jnElqDowtrW +8DlzOzovnULpIW3kch3xkab3QLyaAq28UBsiDhrS6t/JjiowEo6FsYS7LFoYg9h m1Osp2hSUdU7WAcVVWovIHR2NIz1uF35ncf0Za8jQKUZIryVCXr58ocek8fO6JD2 oZ9WujWp57y69SOEwE3CK4GmZ/hp+3R35+knyvVYB8WsBsd62lIdBzfTYmkLNjFy 0x1msi9HTuU8AAQ4KLVcG8GYRp33BgEmvi0F1/5C36xKsVLcmBHhzmsur1tYQjVN PUZYv2i5jKLEG73+Y1cCZ2V0WhsEDRa1VeTv9rDji0aiNAxXktHA2EO4f0M54QSf vElk+h9s8CY5O/5yy3U7 =c0im -----END PGP SIGNATURE----- --WRMGsLmc1wQc8NPq-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 21:01:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 251B576D; Wed, 13 Feb 2013 21:01:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 92BE9F11; Wed, 13 Feb 2013 21:01:02 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so4583781wgb.4 for ; Wed, 13 Feb 2013 13:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XnJGPPOr4Q1Tpqlr7j5cn+ibOFo9WrfWVDVlUqiyljI=; b=to1EBFaWsyNMYgzhqM3HAnZLONB+S2XCBQmfo8fkO+9YBWDckzrgZMk7DrmGxiXI97 CaisCaFsx2sJIcCdLFzdsKV4eRwdqR7ytuFewWYW2bhH56xKJLtWGg3mMDS+QtnfIxs4 ZmvcjzshpR1gjrvDPSiHRdstPJArJsPZGtxtLr7oUgiGgOO0j8KLdEoBU8pSUt3Wpy1S SJJKB4poFuzCl/BTsPOmFTPic3qNpc/jkDwVgBDtromJLtW0Et9XAl7yOqFtuPgJ56RJ QKzobwvvA1rdXOEMXRq0kSbvwOFiEMdkZRYzKsP/r5563kDo0hwErV77/rqzHagesZ1b JIYg== MIME-Version: 1.0 X-Received: by 10.181.12.103 with SMTP id ep7mr12683928wid.12.1360789261748; Wed, 13 Feb 2013 13:01:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Wed, 13 Feb 2013 13:01:01 -0800 (PST) In-Reply-To: <20130213193826.GU2522@kib.kiev.ua> References: <1360125698.93359.566.camel@revolution.hippie.lan> <20130206155830.GX2522@kib.kiev.ua> <20130209134706.GB19909@stack.nl> <20130210103745.GI2522@kib.kiev.ua> <1360685019.4545.170.camel@revolution.hippie.lan> <20130212203408.GM2522@kib.kiev.ua> <1360768592.4545.209.camel@revolution.hippie.lan> <20130213193826.GU2522@kib.kiev.ua> Date: Wed, 13 Feb 2013 13:01:01 -0800 X-Google-Sender-Auth: F8v6dvCqeDPzgmqEUHJShZqa1xI Message-ID: Subject: Re: Request for review, time_pps_fetch() enhancement From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Jilles Tjoelker , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:01:03 -0000 ... why don't we just mark tsleep() as a barrier point and be done with it? Same as the wakeup call? Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 21:26:33 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4BE132D; Wed, 13 Feb 2013 21:26:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 08205A4; Wed, 13 Feb 2013 21:26:32 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA12215; Wed, 13 Feb 2013 23:26:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U5jqY-0000g2-QE; Wed, 13 Feb 2013 23:26:30 +0200 Message-ID: <511C0505.6060204@FreeBSD.org> Date: Wed, 13 Feb 2013 23:26:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: kgdb modules References: <510F8F33.3030504@icritical.com> <510F9EEF.8080402@FreeBSD.org> <201302041458.16404.jhb@freebsd.org> In-Reply-To: <201302041458.16404.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Matt Burke X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:26:34 -0000 on 04/02/2013 21:58 John Baldwin said the following: > You can also load modules manually by > using the add-kld command (give it a full path to an individual module). You > may need to use 'nosharedlibrary' to unload symbols from the "wrong" module > before add-kld will be useful however. I think that this approach is superior to what I suggested. BTW, thank you for 'nosharedlibrary' - I learned a new thing about gdb :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 21:54:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B236B7C for ; Wed, 13 Feb 2013 21:54:07 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x22b.google.com (ia-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 67A771C1 for ; Wed, 13 Feb 2013 21:54:07 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so1678257iaz.16 for ; Wed, 13 Feb 2013 13:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tBWwlFAHQZqBdjLMNcAodD2tA24+2fqmhayX+LnToHU=; b=JXKnO5d6fzVyYvMoecM+hILASAXpKxsKickHfBPwT/INqLP93oDtbMq3nxr1MArhTx u9+6lbMYar7h2rGr0TCBjkvpsKOM/CoEyQKh3H6AFcz9uLd3ymOzDRd2Rbn010HW79JV FSgkyrgmLzE3KaovY4gJm4jUcglXgVLklY5cyeOl+NDxZs1Y7hYSgGJvWNHRG2UKZRPQ 0ljMC/wOj6SXS+tvAxurHY/bLlmbQlo/uOw46PLXM/QsKfDYXkfVtm6HJzeT71RE/bQQ ktQdbNNCYatzip794RbxdjknwbVsyTci4/YvgEVgVGodjPL6A6beTY1EIrJFOCes21fo KfMA== X-Received: by 10.50.236.65 with SMTP id us1mr14019895igc.100.1360792446938; Wed, 13 Feb 2013 13:54:06 -0800 (PST) Received: from [192.168.1.14] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id mj6sm38822301igc.9.2013.02.13.13.54.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 13:54:05 -0800 (PST) Message-ID: <511C0B75.2050401@gmail.com> Date: Wed, 13 Feb 2013 15:53:57 -0600 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Obscure platform testbed References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:54:07 -0000 On 2/12/2013 10:20 AM, Kevin Day wrote: > > I'm not sure if this is the right place to post this, so if you know of anyone who may be interested in this please forward to them. Right now my company (your.org) does the free amd64/i386 VMs for FreeBSD developers. > > For an unrelated project, we're trying to build a testbed of many of the more obscure *nix boxes, both running their native OS and a modern OS. As an example, we've now got two SGI O2 R10K boxes, one running IRIX and one running NetBSD. We're planning on doing the same for Sparc64(Solaris and FreeBSD), VAX, ARM, etc. Where possible we'll have NFS mounted home directories and NIS to have shared logins across the "cluster". > > First, would any of you find this useful? If this is really only useful for us, I won't bother trying to make this scale beyond our own need for this. If this is popular enough to warrant the extra time, it wouldn't be much more work to make this available to any developer who could use it. > > Second, do any of you have older non-intel boxes that are just gathering dust, that are complete enough to install an OS and plug into ethernet? If it's otherwise heading to a dumpster one day, we'd happily pay for shipping to put it to good/public use. > > -- Kevin > I imagine your request would be more geared towards porters than hackers. What you're creating would be of more use to someone developing portable software. I wouldn't personally use it, but people trying to develop for *nix but not just linux would need something. As for non-intel boxes, you're probably better off with emulators that support networking. Older processors are horribly power efficient by todays standards, and a lot of the interesting systems have emulators available. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 02:20:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29D174DB for ; Thu, 14 Feb 2013 02:20:18 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-ie0-x235.google.com (ie-in-x0235.1e100.net [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id C8CB0E57 for ; Thu, 14 Feb 2013 02:20:17 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id 17so2584240iea.26 for ; Wed, 13 Feb 2013 18:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=K0OCNCooWpIlcllA9QK2czSU6xJBHVlAbK+bk54L+BU=; b=DIIWZy4Z6jGiGWs5XQkmh6llpc+hloWeUnykgY/FMNj0y2Ra7NuBYdqAITwTj7j1To 6EtFYfY85ietL7Wh0GZCMw6XGO4hf3oS0X0nPMbGMQ3wqkBG6iWNtRE/aEHLnc/8eDg+ K3Qyt+6deanO4YAUe3MGAONYh4IvzWaBXwK0A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=K0OCNCooWpIlcllA9QK2czSU6xJBHVlAbK+bk54L+BU=; b=Id1ZwO2ioI3Ryje3wmfIKEDnfht3dL7HV+a6Oozi05Ylt5m7pFV8Z+AF5YMPRsg+9n IjfmP7S0cfsSmUb/Y5Byc7AZK3q4uO2fLiQ4T4lwJIpd/XksJ++o0llm3sRfOIrmvmtS W3F/gvlXeHHt3gBVGesi5Ud5YWw58grKdRZ1y0VPCR3Vvk7wERzC0m/SG+iX4SoM7CVo spHA/4dfzbafrSdjg3iaxNZ4TTPySZ1WLm3c8oQudmuuLiHKZBmZJ8z7V3shQz7xs9b3 TNBmXIp9RameDXbZTsCV67GLMX+/hV2bbXmp7OgGgXM5dhddP0xnM2im17WnOkXkM9NW 9pFw== X-Received: by 10.50.219.234 with SMTP id pr10mr15716716igc.26.1360808417187; Wed, 13 Feb 2013 18:20:17 -0800 (PST) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPS id bp7sm18003433igb.4.2013.02.13.18.20.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 18:20:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Obscure platform testbed From: Kevin Day In-Reply-To: <511C0B75.2050401@gmail.com> Date: Wed, 13 Feb 2013 20:20:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <108E0BBD-5550-40C3-8117-1C9A4895E9CD@dragondata.com> References: <511C0B75.2050401@gmail.com> To: Joshua Isom X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlugNxowpG0ckgwDre4WBZXVYDXWHxAIarb5ZDHgpZt9W4l2MrSzjb9FJjMVzH9Go5nSO+k Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 02:20:18 -0000 On Feb 13, 2013, at 3:53 PM, Joshua Isom wrote: > On 2/12/2013 10:20 AM, Kevin Day wrote: >>=20 >> I'm not sure if this is the right place to post this, so if you know = of anyone who may be interested in this please forward to them. Right = now my company (your.org) does the free amd64/i386 VMs for FreeBSD = developers. >>=20 >> For an unrelated project, we're trying to build a testbed of many of = the more obscure *nix boxes, both running their native OS and a modern = OS. As an example, we've now got two SGI O2 R10K boxes, one running IRIX = and one running NetBSD. We're planning on doing the same for = Sparc64(Solaris and FreeBSD), VAX, ARM, etc. Where possible we'll have = NFS mounted home directories and NIS to have shared logins across the = "cluster". >=20 > I imagine your request would be more geared towards porters than = hackers. What you're creating would be of more use to someone = developing portable software. I wouldn't personally use it, but people = trying to develop for *nix but not just linux would need something. >=20 > As for non-intel boxes, you're probably better off with emulators that = support networking. Older processors are horribly power efficient by = todays standards, and a lot of the interesting systems have emulators = available. For this project, we really do need the real hardware. Long story, but = we need to demonstrate certain operations on legacy hardware itself. So, = while we're going through this hassle I thought I'd make it public if = there are any takers. I've had a few people interested in using it, and a couple people = offering up hardware. If anyone has interest, please contact me for more = off-list info! :) -- Kevin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 08:28:42 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A41A8F88 for ; Thu, 14 Feb 2013 08:28:42 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 17976DBE for ; Thu, 14 Feb 2013 08:28:41 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t44so1695863wey.26 for ; Thu, 14 Feb 2013 00:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OIt5WHNwQeOpeQIAHlf64uMo2TY49A2QYNuk8TKvPkU=; b=hq7epexro5+fykCU0C1xSahnuBLmS/NiAbnjvIg89msptO1rj21PX9gGjFkWn51BS0 Um6czQ0mqV0AWECQfM5XBWimYlia8dxqciGL2nVXISMTpIiky41ifI+Tmryz5psBKSxy SLQaegoo7m5p+m6Z0Rgua1YCdqpXv1UnOw4amN/J9HAriaQqkMbSadmwkJqWXZBOragb 8bUMOZRuuQ6EC7Eot/r5bkABH/iEG0OZ3AJBGsgAOZfC8o2vcfWaxrLRHrNWVvmh4AM2 5TaCcEV/OOb5DHUg2sX5p4Rh6wpA3u60KAkkPoXVh8q//igLJknczHdyIvlQKNJAX4hJ 0F7Q== MIME-Version: 1.0 X-Received: by 10.180.8.4 with SMTP id n4mr15022383wia.13.1360830521304; Thu, 14 Feb 2013 00:28:41 -0800 (PST) Received: by 10.194.85.116 with HTTP; Thu, 14 Feb 2013 00:28:41 -0800 (PST) In-Reply-To: <108E0BBD-5550-40C3-8117-1C9A4895E9CD@dragondata.com> References: <511C0B75.2050401@gmail.com> <108E0BBD-5550-40C3-8117-1C9A4895E9CD@dragondata.com> Date: Thu, 14 Feb 2013 10:28:41 +0200 Message-ID: Subject: Re: Obscure platform testbed From: Alexander Yerenkow To: Kevin Day Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, Joshua Isom X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:28:42 -0000 I'd like to share some experience. I helped guys in LWJGL to have a port to FreeBSD. Their main problem was lack of experience of setting dev FreeBSD (without spending solid amount of time), and total lacking of some "template VMs for building/developing/porting" at all. While I did that port, I tried to set up also other BSD and see what's there (Dragonfly, Open, Net) with different level of success. My point is, if there will be some way to developers to gain access to pre-set and test-ready environment, peoples could benefit from it. >From start this could be set-up in semi manual mode, and became some good service. Thanks. -- Regards, Alexander Yerenkow From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 10:10:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BA2237C4; Thu, 14 Feb 2013 10:10:22 +0000 (UTC) (envelope-from lsanfil@marvell.com) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECAC20E; Thu, 14 Feb 2013 10:10:21 +0000 (UTC) Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKURy4B7es01S+P+//MTYCo+HzsDTHYe7Y@postini.com; Thu, 14 Feb 2013 02:10:22 PST Received: from SC-VEXCH4.marvell.com ([0000:0000:0000:0000:0000:0000:0.0.0.1]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 14 Feb 2013 02:06:56 -0800 From: Lino Sanfilippo To: John Baldwin Date: Thu, 14 Feb 2013 02:06:55 -0800 Subject: RE: Mbuf memory handling Thread-Topic: Mbuf memory handling Thread-Index: Ac4EraXPcYPlCn64TSe+AJIoHaz8HAF7NvsQ Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE1C7403C42E@SC-VEXCH4.marvell.com> References: <175CCF5F49938B4D99B2E3EF7F558EBE1C73F401F3@SC-VEXCH4.marvell.com> <175CCF5F49938B4D99B2E3EF7F558EBE1C73F4038E@SC-VEXCH4.marvell.com> <201302061605.00583.jhb@freebsd.org> In-Reply-To: <201302061605.00583.jhb@freebsd.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hackers freeBSD , Axel Fischer , Jacques Fourie , Ralf Assmann , Markus Althoff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:10:22 -0000 > -----Original Message----- > From: John Baldwin [mailto:jhb@freebsd.org] > Sent: Mittwoch, 6. Februar 2013 22:05 > To: Lino Sanfilippo > Cc: Jacques Fourie; Hackers freeBSD; Axel Fischer; Markus Althoff; Ralf > Assmann > Subject: Re: Mbuf memory handling >=20 > On Wednesday, February 06, 2013 2:41:32 pm Lino Sanfilippo wrote: > > John, Jacques, > > > > thank you very much for your help. An mbuf cluster seems to be the > right > direction. > > So I would have to do something like > > > > mbuf =3D m_getjcl(how, MT_DATA, M_PKTHDR, MJUMPAGESIZE); > > left_for_next_rcv =3D m_split(mbuf, chunksize); > > if_input(ifp, mbuf); > > > > right? > > > > >I agree that read-only buffers may be ok in this case but would like > to > point out that the M_WRITABLE() macro will evaluate to 0 if the > refcount on > the cluster is >1 > > > > The fact that the resulting mbufs returned by m_split() are not > writeable > any more is indeed a problem: > > What I would like to do is keep the 'left_for_next_rcv' mbuf until > the next > packet arrives and > > then fill it with the next packets data only up to 'chunksize', split > it > again to pass the new mbuf to > > the protocol stack and so on until 'left_for_next_rcv' becomes too > small to > be splitted further. > > Only then I would want to allocate a new "fresh" jumbo sized mbuf. Is > it > possible to > > realize this with cluster mbufs? >=20 > They are only read-only in the sense that you can't call routines like > m_pullup() or m_prepend(), etc. Your device should still be able to > DMA > into the buffer, but once the buffer is passed up to the stack the > stack > can't mess with it. This is probably what you want anyway as you > wouldn't > want the stack appending to a buffer and spilling over into the cluster > where your device is going to DMA the next packet. >=20 I implemented the solution yesterday and everything seems to work. Thank yo= u! Lino=20 From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 10:38:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2861FC8 for ; Thu, 14 Feb 2013 10:38:24 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 796963F8 for ; Thu, 14 Feb 2013 10:38:24 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1EAcJIN001913 for ; Thu, 14 Feb 2013 11:38:19 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1EAcJb6001910 for ; Thu, 14 Feb 2013 11:38:19 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 14 Feb 2013 11:38:19 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: rsh/rlogin strange behavior In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 14 Feb 2013 11:38:19 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:38:25 -0000 i use rsh/rlogin regularly within LAN and over encrypted tunnels it works generally fine but have strange behavior when i output long amount of text in console (eg. cat bigfile), where long is like 20kB it a) display part of it and hangs (i have to kill rlogin) - rarely b) display part of it and rest is skipped. then i can work normally. ssh doesn't have such a problem. what is wrong? From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 11:09:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7685C9F4 for ; Thu, 14 Feb 2013 11:09:34 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 47E7E959 for ; Thu, 14 Feb 2013 11:09:34 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r1EB9W6Y012478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Feb 2013 05:09:32 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Thu, 14 Feb 2013 05:09:31 -0600 From: "Teske, Devin" To: Wojciech Puchar , "freebsd-hackers@freebsd.org" Subject: RE: rsh/rlogin strange behavior Thread-Topic: rsh/rlogin strange behavior Thread-Index: AQHOCp9xD1iNtGIRjUuq20A96tJlfZh5L3kp Date: Thu, 14 Feb 2013 11:09:31 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201EA93B6@ltcfiswmsgmb21> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-14_04:2013-02-14,2013-02-14,1970-01-01 signatures=0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 11:09:34 -0000 On Thu, 14 Feb 2013, Wojciech Puchar wrote: > i use rsh/rlogin regularly within LAN and over encrypted tunnels > it works generally fine but have strange behavior >=20 > when i output long amount of text in console (eg. cat bigfile), where long > is like 20kB it >=20 > a) display part of it and hangs (i have to kill rlogin) - rarely > b) display part of it and rest is skipped. then i can work normally. >=20 >=20 > ssh doesn't have such a problem. >=20 > what is wrong? >=20 This sounds oddly like a bug we discovered back in the 4 days with rsh. We discovered a bug years ago when moving from FreeBSD-4.8 to 4.11 (with ma= ny back-ported drivers) that a combination of the em(4) driver (back-ported= from RELENG_6) and changes to libc ended up in the traces. We could easily replicate the issue in csh with: repeat 100 rsh date HINT: Set yourself up in /etc/hosts.equiv on for password-less entry Repeat about 5 or 6 times and then eventually the connection will hang and = you won't be able to make more connections for some time. Next step? Execute "netstat -an | less" and look for oddities (like a mass = pile of FIN_WAIT_2 connections). In our case (ymmv) the final ACK was not being sent leaving the client side= stacking up a bunch of connections that take msl.timeout time to expire (i= irc). If I do remember correctly the problem happened when the server was u= sing an em(4) driver. Our ultimate solution was to either switch critical servers to fxp(4) based= hardware or roll entire sites over to using key-based SSH (which may work = for you -- have you thought about giving ssh-keygen a try? that is, if you'= re using rsh for the convenience of password-less entry via hosts.equiv for= example). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 11:29:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2325F27D for ; Thu, 14 Feb 2013 11:29:41 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6ACA58 for ; Thu, 14 Feb 2013 11:29:40 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1EBTTPi002240; Thu, 14 Feb 2013 12:29:29 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1EBTTet002237; Thu, 14 Feb 2013 12:29:29 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 14 Feb 2013 12:29:29 +0100 (CET) From: Wojciech Puchar To: "Teske, Devin" Subject: RE: rsh/rlogin strange behavior In-Reply-To: <13CA24D6AB415D428143D44749F57D7201EA93B6@ltcfiswmsgmb21> Message-ID: References: , <13CA24D6AB415D428143D44749F57D7201EA93B6@ltcfiswmsgmb21> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 14 Feb 2013 12:29:30 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 11:29:41 -0000 > > repeat 100 rsh date > > HINT: Set yourself up in /etc/hosts.equiv on for password-less entry > > Repeat about 5 or 6 times and then eventually the connection will hang and you won't be able to make more connections for some time. > > Next step? Execute "netstat -an | less" and look for oddities (like a mass pile of FIN_WAIT_2 connections). > > In our case (ymmv) the final ACK was not being sent leaving the client side stacking up a bunch of connections that take msl.timeout time to expire (iirc). If I do remember correctly the problem happened when the server was using an em(4) driver. > > Our ultimate solution was to either switch critical servers to fxp(4) based hardware or roll entire sites over to using key-based SSH (which may work for you -- have you thought about giving ssh-keygen a try? that is, if you're using rsh for the convenience of password-less entry via hosts.equiv for example). > -- it is FreeBSD 9, em or re or bge hardware but rlogin goes over tun(4) interface. in the same time rcp works fine even for gigabyte file. any more ideas? From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 11:35:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 35F7C621 for ; Thu, 14 Feb 2013 11:35:13 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id D9381AAB for ; Thu, 14 Feb 2013 11:35:12 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id r1EBZ76p022418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Feb 2013 05:35:12 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Thu, 14 Feb 2013 05:34:26 -0600 From: "Teske, Devin" To: Wojciech Puchar Subject: RE: rsh/rlogin strange behavior Thread-Topic: rsh/rlogin strange behavior Thread-Index: AQHOCp9xD1iNtGIRjUuq20A96tJlfZh5L3kpgABs94D//5u9bw== Date: Thu, 14 Feb 2013 11:34:25 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201EA941E@ltcfiswmsgmb21> References: , <13CA24D6AB415D428143D44749F57D7201EA93B6@ltcfiswmsgmb21>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-14_04:2013-02-14,2013-02-14,1970-01-01 signatures=0 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 11:35:13 -0000 On Thu, 14 Feb 2013, Wojciech Puchar wrote: > it is FreeBSD 9, em or re or bge hardware but rlogin goes over tun(4) > interface. >=20 > in the same time rcp works fine even for gigabyte file. >=20 > any more ideas? Try to isolate the problem as network or disk or other... systat -iostat 1 netstat 1 systat -vmstat 1 NOTE: Don't forget systat takes ":ignore " which can be handy at ti= mes if you have a lot of devices Those are a good start. Others can offer others to see where your data is c= hoking. HINT: Look for errors in the "netstat 1" output? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 11:39:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3E2A753 for ; Thu, 14 Feb 2013 11:39:35 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0F2DAAE3 for ; Thu, 14 Feb 2013 11:39:34 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r1EBdSdr002342; Thu, 14 Feb 2013 12:39:28 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r1EBdSra002339; Thu, 14 Feb 2013 12:39:28 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 14 Feb 2013 12:39:28 +0100 (CET) From: Wojciech Puchar To: "Teske, Devin" Subject: RE: rsh/rlogin strange behavior In-Reply-To: <13CA24D6AB415D428143D44749F57D7201EA941E@ltcfiswmsgmb21> Message-ID: References: , <13CA24D6AB415D428143D44749F57D7201EA93B6@ltcfiswmsgmb21>, <13CA24D6AB415D428143D44749F57D7201EA941E@ltcfiswmsgmb21> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 14 Feb 2013 12:39:28 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 11:39:35 -0000 > > systat -iostat 1 not a disk for sure. not even use everything needed already cached > netstat 1 # netstat -I tun3 1 input (tun3) output packets errs idrops bytes packets errs bytes colls 1 0 0 52 1 0 173 0 1 0 0 52 1 0 121 0 2 0 0 104 2 0 201 0 1 0 0 52 2 0 201 0 5 0 0 263 3 0 254 0 1 0 0 52 1 0 121 0 1 0 0 52 1 0 121 0 12 0 0 628 17 0 16452 0 4 0 0 208 4 0 473 0 5 0 0 263 4 0 950 0 23 0 0 1202 30 0 32656 0 50 0 0 2619 76 0 81661 0 41 0 0 2148 60 0 65301 0 43 0 0 2252 61 0 65353 0 45 0 0 2356 62 0 65433 0 45 0 0 2356 62 0 65433 0 43 0 0 2252 61 0 65353 0 44 0 0 2305 61 0 65353 0 11 0 0 575 16 0 16429 0 5 0 0 260 5 0 553 0 and that's it. seems fine. strange observation - usually first time it trims part of output. second or third is good. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 14:04:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F214F2E for ; Thu, 14 Feb 2013 14:04:05 +0000 (UTC) (envelope-from natris@centrum.cz) Received: from gmmr1.centrum.cz (gmmr1.centrum.cz [IPv6:2a00:da80:0:502::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A830696 for ; Thu, 14 Feb 2013 14:04:05 +0000 (UTC) Received: from mail1006.cent (unknown [10.32.3.101]) by gmmr1.centrum.cz (Postfix) with ESMTP id 00CC38080BF5; Thu, 14 Feb 2013 15:04:03 +0100 (CET) Received: by mail1006.cent (Postfix, from userid 33) id EB6F460000223; Thu, 14 Feb 2013 15:04:02 +0100 (CET) To: =?utf-8?q?Konstantin_Belousov?= Subject: =?utf-8?q?Re=3A_SIGSEGV=2FSIGBUS_when_accessing_after_end_of_mmapped_file=3B_why_it_differs_with_GCC=3F?= Received: from 212.4.138.50 (X-Forwarded-For: 212.4.138.50) by mail1006.centrum.cz (centrum.cz multimail) with HTTP Date: Thu, 14 Feb 2013 15:04:02 +0100 From: References: <20130213171825.76D3A9DC@centrum.cz>, <20130213191208.GR2522@kib.kiev.ua> In-Reply-To: <20130213191208.GR2522@kib.kiev.ua> X-Mailer: Centrum Email 5.3 X-Priority: 3 X-Original-From: natris@centrum.cz MIME-Version: 1.0 Message-Id: <20130214150402.49631109@centrum.cz> X-Maser: oho Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 14 Feb 2013 14:12:41 +0000 Cc: =?utf-8?q?freebsd=2Dhackers=40freebsd=2Eorg?= , =?utf-8?q?Ryan_Stone?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:04:05 -0000     Od: "Konstantin Belousov" > On Wed, Feb 13, 2013 at 12:13:58PM -0500, Ryan Stone wrote: >> On Wed, Feb 13, 2013 at 11:18 AM, wrote: >> >> > Hello, >> > I am porting an application which maps files into the memory and works >> > directly with the memory. When doing this, it can happen that when >> > someone >> > resizes the file so that part of the previously mapped region is no >> > longer >> > backed by the file, synchronous signal is sent to the process which >> > needs >> > to be handled. >> > >> > On all other platforms than FreeBSD I have tested (Solaris, Linux, >> > Darwin, >> > HP-UX) the signal in question is SIGBUS. However on FreeBSD, depending >> > on >> > the >>compiler<< used, it is either SIGBUS or SIGSEGV. When I compile >> > the >> > binary with "gcc version 4.2.1 20070831 patched [FreeBSD], amd64", the >> > signal is SIGBUS, when i use "gcc version 4.7.3 20121103 (prerelease) >> > (FreeBSD Ports Collection)", the signal is SIGSEGV. Please note that one >> > of >> > the versions of gcc between 4.2 and 4.7 also caused SIGSEFV to be sent >> > but >> > this did not matter for me as I did not need to use that version; I >> > however >> > need gcc 4.7 to work because of c++11 stuff that my project has recently >> > started to use. >> > >> > Unfortunately registering signal handler on SIGSEGV is very inconvenient >> > for me; I would prefer to somehow switch the behavior to be sane. >> > >> > Please anyone has an idea whether or how this could be achieved? I have >> > tried to find out why, on single machine, just because of different gcc >> > version, kernel sends different signal but I have never worked with fbsd >> > kernel before and so my search did not succeed so far. >> > >> > Machine in question runs amd64 FreeBSD 9.1-RC2, but this has also >> > happened >> > to me with older version of FreeBSD. >> > >> > >> > gcc 4.2 (same happens also with libstdc++ and co. from gcc 4.2): >> > Program received signal SIGBUS, Bus error. >> > (gdb) i shared >> > From                To                  Syms Read   Shared Object >> > Library >> > 0x0000000800f2ef70  0x0000000800f3ee68  Yes (*)     /libexec/ld-elf.so.1 >> > 0x000000080114d710  0x0000000801159748  Yes (*)     /lib/libthr.so.3 >> > 0x00000008013c2d30  0x000000080142c656  Yes >> > /usr/local/lib/gcc47/libstdc++.so.6 >> > 0x00000008016737c0  0x00000008016891b8  Yes (*)     /lib/libm.so.5 >> > 0x0000000801893930  0x00000008018a3088  Yes >> > /usr/local/lib/gcc47/libgcc_s.so.1 >> > 0x0000000801ad71d0  0x0000000801ba9358  Yes (*)     /lib/libc.so.7 >> > >> > gcc 4.7: >> > Program received signal SIGSEGV, Segmentation fault. >> > (gdb) i shared >> > From                To                  Syms Read   Shared Object >> > Library >> > 0x0000000800f5ef70  0x0000000800f6ee68  Yes (*)     /libexec/ld-elf.so.1 >> > 0x000000080117d710  0x0000000801189748  Yes (*)     /lib/libthr.so.3 >> > 0x00000008013f2d30  0x000000080145c656  Yes >> > /usr/local/lib/gcc47/libstdc++.so.6 >> > 0x00000008016a37c0  0x00000008016b91b8  Yes (*)     /lib/libm.so.5 >> > 0x00000008018c3930  0x00000008018d3088  Yes >> > /usr/local/lib/gcc47/libgcc_s.so.1 >> > 0x0000000801b071d0  0x0000000801bd9358  Yes (*)     /lib/libc.so.7 >> > >> > >> > I would be glad for any hint or information. >> > Kind Regards, >> > Ondrej Kolacek >> > _______________________________________________ >> > 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" >> >> >> >> I think that setting sysctl machdep.prot_fault_translation=1 would do what >> you want. > > This might be an indication of the issue with the toolchains you use, > in particular, with the linker or csu.  The default selection for the signal > is based on the note osver, linked into the binary from crt1.o. Either > linker omits the note, or wrong crt1 is used. > > You did not specified anything about version of the FreeBSD used, nor > the exact compiler invocations. Using the crystal ball, I see the > r244600 for HEAD and r244904 for stable/9, if you use --gc-sections > flags. This is more or less consistent with what you reported, since > gcc from ports uses binutils from ports, which have newer ld with > bugfix already applied. Thanks a lot for the pointers. So, to sum it up for potential others who could stumble into this problem: In FBSD6 and older, there was a POSIX nonconformity in FreeBSD when in some cases SIGBUS was raisedinstead of SIGSEGV. Within FBSD7, change of behavior was implemented in kernel - in case of page fault, SIGSEGV is raised instead of SIGBUS. However it was quickly determined that this was breaking stuff, as the old binaries expected SIGBUS instead. Also it was determined that this change is not really POSIX conformant either as some page faults are supposed to signal SIGBUS (like the mmap issue I was asking about). Because of this, within PR 118304, hack has been made to the kernel. Based on ELF OSABI note within the executable (eg. note (.note.ABI-tag): FreeBSD 901000), for ELF files with OS version older than 700004 or for those who do not contain such a note, SIGBUS is used, for those who contain newer flag SIGSEGV is used. There is also an option to tune the translation globally for all processes on the given machine via sysctl machdep.prot_fault_translation.   In my case it is indeed so that while the gcc42 generated binary does not contain the note, gcc47 binary does contain it. I am indeed using --gc-sections linker option, however whether this, potentially with some bug in linker, caused the note to be missing, I am not sure, as I did not investigate into this. The solution of the original problem is thus to ensure that the note presence is consistent and that the correct signal is handled.   Thanks again for the assistance Ondrej Kolacek From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 20:17:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D1F1D45 for ; Thu, 14 Feb 2013 20:17:34 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 171B1AE1 for ; Thu, 14 Feb 2013 20:17:32 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 05835D481B2; Thu, 14 Feb 2013 21:17:25 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id D825471A; Thu, 14 Feb 2013 21:17:24 +0100 (CET) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id A609D13162; Thu, 14 Feb 2013 20:17:24 +0000 (UTC) Date: Thu, 14 Feb 2013 21:17:24 +0100 From: Jeremie Le Hen To: Wojciech Puchar Subject: Re: rsh/rlogin strange behavior Message-ID: <20130214201724.GC5900@felucia.tataz.chchile.org> Mail-Followup-To: Wojciech Puchar , freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 20:17:34 -0000 On Thu, Feb 14, 2013 at 11:38:19AM +0100, Wojciech Puchar wrote: > > what is wrong? Please do not reply a random thread to create a new one. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 10:57:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 08777496 for ; Fri, 15 Feb 2013 10:57:57 +0000 (UTC) (envelope-from loic.blot@unix-experience.fr) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by mx1.freebsd.org (Postfix) with ESMTP id 7B14514E for ; Fri, 15 Feb 2013 10:57:55 +0000 (UTC) Received: from [10.42.69.152] ([82.124.32.74]) by mwinf5d25 with ME id 0axo1l00H1bxcNi03axonE; Fri, 15 Feb 2013 11:57:48 +0100 Message-ID: <1360926085.23144.18.camel@Nerz-PC.home> Subject: dot.core ?? From: =?ISO-8859-1?Q?Lo=EFc?= BLOT To: "freebsd-hackers@freebsd.org" Date: Fri, 15 Feb 2013 12:01:25 +0100 Organization: UNIX Experience Fr X-Mailer: Evolution 3.6.3 Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: loic.blot@unix-experience.fr List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 10:57:57 -0000 Hello, i have strange problem on one of my FreeBSD 9.1 install. The server randomly hard reboots. When i look at dmesg i don't find anything, but there is a strange entry: pid 24931 (dot), uid 0: exited on signal 11 (core dumped) pid 24932 (dot), uid 0: exited on signal 11 (core dumped) pid 24935 (dot), uid 0: exited on signal 11 (core dumped) pid 24936 (dot), uid 0: exited on signal 11 (core dumped) pid 27343 (dot), uid 0: exited on signal 11 (core dumped) pid 27344 (dot), uid 0: exited on signal 11 (core dumped) pid 27347 (dot), uid 0: exited on signal 11 (core dumped) pid 27348 (dot), uid 0: exited on signal 11 (core dumped) pid 29714 (dot), uid 0: exited on signal 11 (core dumped) pid 29715 (dot), uid 0: exited on signal 11 (core dumped) pid 29727 (dot), uid 0: exited on signal 11 (core dumped) pid 29728 (dot), uid 0: exited on signal 11 (core dumped) There is also a dot.core in /root do you now what's the problem ? -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 11:22:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 296679B0 for ; Fri, 15 Feb 2013 11:22:56 +0000 (UTC) (envelope-from mike@urgle.com) Received: from cheddar.urgle.com (cheddar.urgle.com [IPv6:2001:470:967d:b:21c:c4ff:fed7:6d44]) by mx1.freebsd.org (Postfix) with ESMTP id E47FF23B for ; Fri, 15 Feb 2013 11:22:55 +0000 (UTC) Received: from mike by cheddar.urgle.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U6JNW-000G72-GQ for freebsd-hackers@freebsd.org; Fri, 15 Feb 2013 11:22:54 +0000 Date: Fri, 15 Feb 2013 11:22:54 +0000 From: Mike Bristow To: "freebsd-hackers@freebsd.org" Subject: Re: dot.core ?? Message-ID: <20130215112254.GA23913@cheddar.urgle.com> References: <1360926085.23144.18.camel@Nerz-PC.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1360926085.23144.18.camel@Nerz-PC.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 11:22:56 -0000 On Fri, Feb 15, 2013 at 12:01:25PM +0100, Loïc BLOT wrote: > Hello, > i have strange problem on one of my FreeBSD 9.1 install. > The server randomly hard reboots. > When i look at dmesg i don't find anything, but there is a strange > entry: > > pid 24931 (dot), uid 0: exited on signal 11 (core dumped) [snip similar] > There is also a dot.core in /root "dot" is a program in the graphviz suit, probably. Someone or something is running it as root, and it attempts to access memory which it has no permission to access, so it is killed and a core dump generated. This memory access is likly to be caused by one of two things: 1) a bug in dot; 2) hardware memory corruption I suggest you boot memtest86 or similar to see if you can prove the hardware fault - especially if you can track down who or what is running dot and show that it fails randomly (e.g., if you run it with the same input it does not fail all the time). Cheers, Mike -- Mike Bristow mike@urgle.com http://www.urgle.com/~mike/CV/ From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 13:34:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D64D0E65 for ; Fri, 15 Feb 2013 13:34:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9D9BD6 for ; Fri, 15 Feb 2013 13:34:56 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 06E915C43; Fri, 15 Feb 2013 14:34:49 +0100 (CET) Message-ID: <511E397D.1000005@FreeBSD.org> Date: Fri, 15 Feb 2013 14:34:53 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: natris@centrum.cz, Konstantin Belousov Subject: Re: SIGSEGV/SIGBUS when accessing after end of mmapped file; why it differs with GCC? References: <20130213171825.76D3A9DC@centrum.cz>, <20130213191208.GR2522@kib.kiev.ua> <20130214150402.49631109@centrum.cz> In-Reply-To: <20130214150402.49631109@centrum.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:34:56 -0000 On 2013-02-14 15:04, natris@centrum.cz wrote: > Od: "Konstantin Belousov" >> On Wed, Feb 13, 2013 at 12:13:58PM -0500, Ryan Stone wrote: >>> On Wed, Feb 13, 2013 at 11:18 AM, wrote: ... >>>> Machine in question runs amd64 FreeBSD 9.1-RC2, but this has also ... >> You did not specified anything about version of the FreeBSD used, nor >> the exact compiler invocations. Using the crystal ball, I see the >> r244600 for HEAD and r244904 for stable/9, if you use --gc-sections >> flags. This is more or less consistent with what you reported, since >> gcc from ports uses binutils from ports, which have newer ld with >> bugfix already applied. ... > In my case it is indeed so that while the gcc42 generated binary does not contain the note, gcc47 binary does contain it. I am indeed using --gc-sections linker option, however whether this, potentially with some bug in linker, caused the note to be missing, I am not sure, as I did not investigate into this. The solution of the original problem is thus to ensure that the note presence is consistent and that the correct signal is handled. As Kostik already pointed out, FreeBSD's ld contains a bug which erroneously strips out the note sections, if you use --gc-sections. I fixed that for head in r244600, and merged it to stable/9 in r244904. Since you said you are running FreeBSD 9.1-RC2, you will not have this particular fix, so it is the most likely cause for your problems. The reason you do not see it with gcc 4.7 is that it will use a much newer ld from the binutils port, where this issue with --gc-sections was fixed a long time ago. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 13:52:14 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59E8AA96; Fri, 15 Feb 2013 13:52:14 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mx1.freebsd.org (Postfix) with ESMTP id 14514D6C; Fri, 15 Feb 2013 13:52:13 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h2so3695126oag.24 for ; Fri, 15 Feb 2013 05:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=UaI7Jzc+2KFBVM/j4Qqr+vA9RqAhfLV2tkuScg1YcF8=; b=c3zqNqkvicDDVSdRFC7/GTdKNrLv0++Gh+75ZoioZiRqRkSkulv6U1pXM+DgMv51rR JLAodDDg34tcZbABaE/PKeqB8VYJivHkhxqe+JT9OGtwXsrzeymeHCi9UCMd/2D0AtkJ MU33J5TFC7H0CllwKEvtNoBbQt/ltx6kOgGa91kEZKT1Z+JWJddG4U+pKwYZ65Ut+R3R vuiuyuHBUIebNn5SN0vkFhtjKGM7qJzVQsi0xOBz/dxoHOJ8AB2bdxBMJZtvefi4GWD8 bAf7bDFNM4jtcScin1VQNyROCzH0ph3wvYCEj3buK7Fj6YwS9vRmPl22oweBWZzZ1/vZ q84Q== MIME-Version: 1.0 X-Received: by 10.60.172.163 with SMTP id bd3mr1511014oec.78.1360936333313; Fri, 15 Feb 2013 05:52:13 -0800 (PST) Sender: pali.gabor@gmail.com Received: by 10.182.87.195 with HTTP; Fri, 15 Feb 2013 05:52:13 -0800 (PST) Date: Fri, 15 Feb 2013 14:52:13 +0100 X-Google-Sender-Auth: 89HnZh7YfTvDtvGbu5SG508aZ0U Message-ID: Subject: Final Reminder: FreeBSD Quarterly Status Reports, July--December, 2012 From: Gabor Pali To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:52:14 -0000 Hello there, Just a final reminder: the deadline for the reports is this Sunday. On Sun, Feb 10, 2013 at 3:42 PM, Gabor Pali wrote: > Let me call your attention to the approaching deadline of the next > set(s) of FreeBSD Quarterly Status Reports. Please consider > submitting a few lines on your FreeBSD-related project, we are > counting on all of you! :-) > > On Sun, Jan 13, 2013 at 10:57 PM, Gabor Pali wrote: >> Please note that the deadline for submissions covering the period >> between July and December 2012 is February 17th, 2013. > > You can find more details on submission at the Project's web site [1] > but you are free to ask me directly (in private) if you need help with > this. > > [1] http://www.freebsd.org/news/status/ From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 16 12:20:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 894C7F24 for ; Sat, 16 Feb 2013 12:20:36 +0000 (UTC) (envelope-from phileas-fogg@mail.ru) Received: from fallback3.mail.ru (fallback3.mail.ru [94.100.176.58]) by mx1.freebsd.org (Postfix) with ESMTP id 12918835 for ; Sat, 16 Feb 2013 12:20:35 +0000 (UTC) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) by fallback3.mail.ru (mPOP.Fallback_MX) with ESMTP id CBE70D502F03 for ; Sat, 16 Feb 2013 16:20:33 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=VI9vx54z/G5DCnemRsGPhT8kc2tZEL8WhvyRdNPvsmY=; b=fXYJuR2Yqj/f/6Oof/IF8FHsQFjN7D9yWf2lrsDk5V3DmbjSPMjMDaFi1aDek4urpZ6oHvcIgKxSm67x9hBMQPBwFp9EqaeTBW/qhIAi95UBYfiHooXAgMLHCHux9y9U; Received: from [149.172.191.230] (port=34589 helo=[192.168.1.76]) by smtp43.i.mail.ru with esmtpa (envelope-from ) id 1U6gkl-0001zx-5f for freebsd-hackers@freebsd.org; Sat, 16 Feb 2013 16:20:27 +0400 Message-ID: <511F879C.3030801@mail.ru> Date: Sat, 16 Feb 2013 14:20:28 +0100 From: Phileas Fogg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Scrolling in framebuffer syscons Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:20:36 -0000 Hi, i have a question about how the scrolling in a framebuffer syscons works. I'm trying to speed up the syscons on the PS3 console which is a simple framebuffer syscons. It uses the renderer _gfbrndrsw_ (see dev/syscons/scgfbrndr.c) to draw into the framebuffer of the PS3 console. The _gfb_draw_ function implements a simple scrolling that moves data from bottom to top with _vidd_copy_. And that's where i have a problem because _vidd_copy_ calls the function _ps3fb_copy_ (see powerpc/ps3/ps3_syscons.c). But the function _ps3fb_copy_ is NOT implemented yet. So, the question is how does the scrolling work then ? I took a look at other syscons implementation based on a framebuffer, and almost all of them do NOT implement _vidd_copy_ function, e.g. XBOX syscons. Thanks regards