From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 01:19:37 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AC2F106566B for ; Sun, 17 Jul 2011 01:19:37 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id EF7B28FC19 for ; Sun, 17 Jul 2011 01:19:36 +0000 (UTC) Received: from park.js.berklix.net (p5DCBD997.dip.t-dialin.net [93.203.217.151]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6H1JX65069610; Sun, 17 Jul 2011 01:19:34 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6H1Jn10006053; Sun, 17 Jul 2011 03:19:49 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6H1JdII020844; Sun, 17 Jul 2011 01:19:44 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107170119.p6H1JdII020844@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Sun, 17 Jul 2011 03:19:39 +0200 Sender: jhs@berklix.com Cc: "Julian H. Stacey" Subject: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 01:19:37 -0000 Hi all, ENVIRONMENT: Standard gcc version 4.2.1 20070719 [FreeBSD] that comes with FreeBSD 7.4-RELEASE on my 686 host with CFLAGS += -march=i586 in /etc/make.conf used with cd /usr/src/bin/who ; make clean ; make cleandir ; make clean ; make reports Warning: Object directory not changed from original /usr/src/usr.bin/who cc -O2 -fno-strict-aliasing -march=i586 -c /usr/src/usr.bin/who/who.c cc -O2 -fno-strict-aliasing -march=i586 -o who who.o looking with file who reports who: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.4, dynamically linked (uses shared libs), FreeBSD-style, not stripped Problem: Use it from a 586 7.4-RELEASE host (AMD+NFS) file /host/sony/usr/src/usr.bin/who/who /host/sony/usr/src/usr.bin/who/who: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.4, dynamically linked (uses shared libs), FreeBSD-style, not stripped /host/sony/usr/src/usr.bin/who/who fails with Illegal instruction It's nothing special about /who. Nothing to do with AMD+NFS, As I've used cp too before executing, I first found this while cross compiling from a fast 686 to install on a slow 586 for 7.3 to 7.4 upgrade, All these binaries were not excutable on the 586: /boot/loader /sbin/init /bin/sh /bin/csh getty Can someone else please confirm this observation ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 02:02:25 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8EC61065670 for ; Sun, 17 Jul 2011 02:02:25 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 54BA28FC17 for ; Sun, 17 Jul 2011 02:02:25 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p6H22NmZ052195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Jul 2011 21:02:23 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id p6H22MCe088370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Jul 2011 21:02:22 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p6H22LOT088177; Sat, 16 Jul 2011 21:02:21 -0500 (CDT) (envelope-from dan) Date: Sat, 16 Jul 2011 21:02:21 -0500 From: Dan Nelson To: "Julian H. Stacey" Message-ID: <20110717020220.GM6611@dan.emsphone.com> References: <201107170119.p6H1JdII020844@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107170119.p6H1JdII020844@fire.js.berklix.net> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Sat, 16 Jul 2011 21:02:23 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: hackers@freebsd.org Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 02:02:25 -0000 In the last episode (Jul 17), Julian H. Stacey said: > Hi all, > ENVIRONMENT: > Standard > gcc version 4.2.1 20070719 [FreeBSD] > that comes with > FreeBSD 7.4-RELEASE > on my 686 host with > CFLAGS += -march=i586 > in > /etc/make.conf > used with > cd /usr/src/bin/who ; make clean ; make cleandir ; make clean ; make > reports > Warning: Object directory not changed from original /usr/src/usr.bin/who > cc -O2 -fno-strict-aliasing -march=i586 -c /usr/src/usr.bin/who/who.c > cc -O2 -fno-strict-aliasing -march=i586 -o who who.o > looking with > file who > reports > who: ELF 32-bit LSB executable, Intel 80386, version 1 > (FreeBSD), for FreeBSD 7.4, dynamically linked (uses shared > libs), FreeBSD-style, not stripped > > Problem: > Use it from a 586 7.4-RELEASE host (AMD+NFS) > file /host/sony/usr/src/usr.bin/who/who > /host/sony/usr/src/usr.bin/who/who: ELF 32-bit LSB executable, > Intel 80386, version 1 (FreeBSD), for FreeBSD 7.4, dynamically > linked (uses shared libs), FreeBSD-style, not stripped > /host/sony/usr/src/usr.bin/who/who > fails with > Illegal instruction Were the crt*.o files on your fast machine also compiled with -march=i586 ? If you run gdb on the core file, can you determine what function the bad instruction is in? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 07:55:31 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDCCC106566C for ; Sun, 17 Jul 2011 07:55:31 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A04CC8FC0A for ; Sun, 17 Jul 2011 07:55:31 +0000 (UTC) Received: by vxg33 with SMTP id 33so2280421vxg.13 for ; Sun, 17 Jul 2011 00:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=7BexHjMrutOxEvhaB3lyRXHlEoPtmvWa4Q/e37re4GU=; b=YBON3WZ+r7wgqLNhAevlRekBhf9od4gh+M/jeujYKzld6U4LWPbMk9RFIkUllB2O9c QFugKSk3yJyDVAsZzd0rSVjSv0QA7JSPxV/UgkteO1+qIEiV/UXQYmsPha6Q0XLPS5F8 2lUt/eXqoMtkoYMifh42OiS5wool+NNTSZZi4= MIME-Version: 1.0 Received: by 10.220.214.208 with SMTP id hb16mr1425779vcb.61.1310887968264; Sun, 17 Jul 2011 00:32:48 -0700 (PDT) Received: by 10.220.177.140 with HTTP; Sun, 17 Jul 2011 00:32:48 -0700 (PDT) Date: Sun, 17 Jul 2011 11:32:48 +0400 Message-ID: From: Andrey Fesenko To: freebsd-hackers@freebsd.org, dteske@vicor.com Content-Type: text/plain; charset=UTF-8 Cc: Subject: [RELEASE] New Boot-Loader Menu bugs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 07:55:31 -0000 Last Changed Rev: 224125 Not update share/examples/bootforth/* any files old version loader. file sys/boot/forth/loader.conf ############################################################## ### Loader settings ######################################## ############################################################## not actual logo list #loader_logo="fbsdbw" # Desired logo: fbsdbw, beastiebw, beastie, none need #loader_logo="orbbw" # Desired logo: orb, orbbw, fbsdbw, beastiebw, beastie, none maybe over loader option. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 23:51:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 344F9106566C; Sun, 17 Jul 2011 23:51:21 +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 F0DF18FC14; Sun, 17 Jul 2011 23:51:20 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p6HNpJnC013524; Sun, 17 Jul 2011 18:51:19 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 17 Jul 2011 18:51:18 -0500 Received: from CMBFISLTC13.FNFIS.COM ([10.132.211.41]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Jul 2011 18:51:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 17 Jul 2011 18:51:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RELEASE] New Boot-Loader Menu bugs? thread-index: AQGgQ0NRiDi/xFWlAfqaGZIcThR++QHvTSVblTm32uA= References: From: "Teske, Devin" To: X-OriginalArrivalTime: 17 Jul 2011 23:51:19.0979 (UTC) FILETIME=[6D0A57B0:01CC44DC] Cc: freebsd-hackers@freebsd.org, Devin.Teske@fisglobal.com Subject: FW: [RELEASE] New Boot-Loader Menu bugs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 23:51:21 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERldmluIFRlc2tlIFttYWlsdG86ZHRl c2tlQHZpY29yLmNvbV0gDQpTZW50OiBTdW5kYXksIEp1bHkgMTcsIDIwMTEgNDo0NSBQTQ0KVG86 ICdBbmRyZXkgRmVzZW5rbyc7ICdmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmcnDQpDYzogSnVs aWFuIEVsaXNjaGVyOyBUZXNrZSwgRGV2aW4gKERldmluLlRlc2tlQGZpc2dsb2JhbC5jb20pDQpT dWJqZWN0OiBSRTogW1JFTEVBU0VdIE5ldyBCb290LUxvYWRlciBNZW51IGJ1Z3M/DQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5kcmV5IEZlc2Vua28gW21haWx0bzpm MGFuZHJleUBnbWFpbC5jb21dDQo+IFNlbnQ6IFN1bmRheSwgSnVseSAxNywgMjAxMSAxMjozMyBB TQ0KPiBUbzogZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnOyBkdGVza2VAdmljb3IuY29tDQo+ IFN1YmplY3Q6IFtSRUxFQVNFXSBOZXcgQm9vdC1Mb2FkZXIgTWVudSBidWdzPw0KPiANCj4gTGFz dCBDaGFuZ2VkIFJldjogMjI0MTI1DQoNCkFyZSB5b3Ugc3VyZSB0aGF0J3MgdGhlIHJpZ2h0IHJl dj8gVGhhdCByZXYgKGJ5IGRvdWdiKSBhcHBlYXJzIHRvIGJlIHJlbGF0ZWQgdG8gZGVmYXVsdCBl bXB0eSB6b25lcyBpbiBgL2V0Yy9uYW1lZGIvbmFtZWQuY29uZicsIGFuZCBjb21wbGV0ZWx5IHVu cmVsYXRlZCB0byBteSByZXYgMjIyNDE3ICh3aGljaCB5b3UgYXBwZWFyIHRvIGJlIHJlZmVyZW5j aW5nIGJlbG93KS4NCg0KDQo+IE5vdCB1cGRhdGUgc2hhcmUvZXhhbXBsZXMvYm9vdGZvcnRoLyog YW55IGZpbGVzIG9sZCB2ZXJzaW9uIGxvYWRlci4NCj4gDQo+IGZpbGUgc3lzL2Jvb3QvZm9ydGgv bG9hZGVyLmNvbmYNCj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMNCj4gIyMjICBMb2FkZXIgc2V0dGluZ3MgICMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCj4gIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCj4gDQo+IG5vdCBhY3R1YWwg bG9nbyBsaXN0DQo+ICNsb2FkZXJfbG9nbz0iZmJzZGJ3IgkJIyBEZXNpcmVkIGxvZ286IGZic2Ri dywgYmVhc3RpZWJ3LA0KPiBiZWFzdGllLCBub25lDQo+IG5lZWQNCj4gI2xvYWRlcl9sb2dvPSJv cmJidyIJCSMgRGVzaXJlZCBsb2dvOiBvcmIsIG9yYmJ3LCBmYnNkYncsIGJlYXN0aWVidywNCj4g YmVhc3RpZSwgbm9uZQ0KPiANCj4gbWF5YmUgb3ZlciBsb2FkZXIgb3B0aW9uLg0KDQpJdCB0b29r IG1lIGF3aGlsZSwgYnV0IEkgdGhpbmsgSSBzZWUgd2hhdCB5b3UncmUgc2F5aW5nLg0KDQpUaGF0 IHRoZSBmb2xsb3dpbmcgcGF0Y2ggbmVlZHMgdG8gYmUgYXBwbGllZCB0byBoZWFkL3N5cy9ib290 L2ZvcnRoL2xvYWRlci5jb25mIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgY2hhbmdlcyB0aGF0 IHdlcmUgbWFkZSBhZ2FpbnN0IGhlYWQvc3lzL2Jvb3QvZm9ydGgvbG9hZGVyLmNvbmYuNSAoaW4g cmV2IDIyMjQxNyk6DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KLS0tIGxvYWRlci5jb25mLm9yaWcJU3VuIEp1bCAxNyAxNjoz NzozNSAyMDExDQorKysgbG9hZGVyLmNvbmYJU3VuIEp1bCAxNyAxNjozODowOSAyMDExDQpAQCAt NDcsNyArNDcsOCBAQA0KIAkJCQkjIGVzY2FwZSB0byB0aGUgbG9hZGVyIHByb21wdCwgc2V0IHRv DQogCQkJCSMgIk5PIiB0byBkaXNhYmxlIGF1dG9ib290aW5nDQogI2JlYXN0aWVfZGlzYWJsZT0i Tk8iCQkjIFR1cm4gdGhlIGJlYXN0aWUgYm9vdCBtZW51IG9uIGFuZCBvZmYNCi0jbG9hZGVyX2xv Z289ImZic2RidyIJCSMgRGVzaXJlZCBsb2dvOiBmYnNkYncsIGJlYXN0aWVidywgYmVhc3RpZSwg bm9uZQ0KKyNsb2FkZXJfbG9nbz0ib3JiYnciCQkjIERlc2lyZWQgbG9nbzogb3JiLCBvcmJidywg ZmJzZGJ3LCBiZWFzdGllYncsDQorCQkJCSMgYmVhc3RpZSwgbm9uZQ0KICNjb21jb25zb2xlX3Nw ZWVkPSI5NjAwIgkjIFNldCB0aGUgY3VycmVudCBzZXJpYWwgY29uc29sZSBzcGVlZA0KICNjb25z b2xlPSJ2aWRjb25zb2xlIgkJIyBBIGNvbW1hIHNlcGFyYXRlZCBsaXN0IG9mIGNvbnNvbGUocykN CiAjY3VycmRldj0iZGlzazFzMWEiCQkjIFNldCB0aGUgY3VycmVudCBkZXZpY2UNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpE b2VzIGFueWJvZHkgb2JqZWN0IHRvIHRoZSBhYm92ZSBwYXRjaD8NCi0tIA0KRGV2aW4NCgpfX19f X19fX19fX19fCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBpcyBw cm9wcmlldGFyeSBhbmQvb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2U6IChpKSBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFsbCBjb3Bp ZXM7IChpaSkgZG8gbm90IGRpc2Nsb3NlLCBkaXN0cmlidXRlIG9yIHVzZSB0aGUgbWVzc2FnZSBp biBhbnkgbWFubmVyOyBhbmQgKGlpaSkgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuIElu IGFkZGl0aW9uLCBwbGVhc2UgYmUgYXdhcmUgdGhhdCBhbnkgbWVzc2FnZSBhZGRyZXNzZWQgdG8g b3VyIGRvbWFpbiBpcyBzdWJqZWN0IHRvIGFyY2hpdmluZyBhbmQgcmV2aWV3IGJ5IHBlcnNvbnMg b3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBUaGFuayB5b3UuCl9fX19fX19fX19f X18K From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 00:08:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2F4A4106564A for ; Mon, 18 Jul 2011 00:08:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DBDF314D907; Mon, 18 Jul 2011 00:08:26 +0000 (UTC) Message-ID: <4E23797A.8060209@FreeBSD.org> Date: Sun, 17 Jul 2011 17:08:26 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: "Teske, Devin" References: In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, f0andrey@gmail.com Subject: Re: FW: [RELEASE] New Boot-Loader Menu bugs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 00:08:27 -0000 There also seems to be a bug with the new boot loader that if you bounce out to the prompt and do 'boot kernel.other' the kern.module_path sysctl is not updated. It still lists /boot/kernel first; but that should be replaced by /boot/kernel.other. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 03:05:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D8AA106566C; Mon, 18 Jul 2011 03:05:30 +0000 (UTC) (envelope-from prvs=41809205dd=devin.teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 02EE68FC1C; Mon, 18 Jul 2011 03:05:29 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa02 [127.0.0.1]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with SMTP id p6I2m7hQ023963; Sun, 17 Jul 2011 21:49:45 -0500 Received: from sbhfisltcgw01.fnfis.com ([10.132.248.121]) by ltcfislmsgpa02.fnfis.com with ESMTP id xjs5e03f3-10; Sun, 17 Jul 2011 21:49:45 -0500 Received: from sbhfisltcgw01.FNFIS.COM ([10.132.248.121]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Jul 2011 21:44:21 -0500 Received: from [10.0.0.104] ([10.132.254.136]) by sbhfisltcgw01.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Jul 2011 21:41:10 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: <4E23797A.8060209@FreeBSD.org> Date: Sun, 17 Jul 2011 19:41:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4966ACA5-DA61-445D-8C22-C337D032E756@vicor.com> References: <4E23797A.8060209@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 18 Jul 2011 02:41:10.0274 (UTC) FILETIME=[26EDF620:01CC44F4] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-17_05:2011-07-16, 2011-07-17, 1970-01-01 signatures=0 Content-Type: text/plain; charset="ISO-8859-1" Cc: freebsd-hackers@freebsd.org, f0andrey@gmail.com, "Teske, Devin" Subject: Re: [RELEASE] New Boot-Loader Menu bugs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 03:05:30 -0000 On Jul 17, 2011, at 5:08 PM, Doug Barton wrote: > There also seems to be a bug with the new boot loader that if you bounce > out to the prompt and do 'boot kernel.other' Hmmm... The last change to the FICL word "boot" was 10 years, 9 months ago, by dcs = in version 1.19 of sys/boot/forth/loader.4th. I know that I haven't touched that word, but I'll have to double-check to s= ee if I'm overriding it in any way. I can see by the code in loader.4th that "boot" will automatically call "un= load" for you if/when an argument is present (e.g., "boot kernel.other"). I personally have never used that syntax (I've always said "unload" before-= hand), but I will take it from the code that this is supposed to work. > the kern.module_path sysctl > is not updated. If you want to change module_path for loader(8), you should set it in loade= r.conf(5). The FICL word "start" (as seen in /boot/loader.rc) will: (a) read loader.conf(5) and then (b) take your customized module_path and (c) search for a suitable kernel in those directories NOTE: that is, if "kernel" was not already set -- which it is, by default, = to "/boot/kernel" sysctl(8) is not (and, IIRC, cannot be) influenced by loader environment va= riables. However, you can retrieve the loader(8) variables via kenv(1). If you wanted to, you could create an rc.d or RCNG script to use kenv(1) to= do things with the loader(8) variables (such as drop them into loader.conf= (5) or sysctl.conf(5)). Be careful though. > It still lists /boot/kernel first; but that should be > replaced by /boot/kernel.other. I'm not familiar with the latter behavior. -- 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 Mon Jul 18 03:40:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DCC41065673; Mon, 18 Jul 2011 03:40:14 +0000 (UTC) (envelope-from prvs=41809205dd=devin.teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id D759E8FC14; Mon, 18 Jul 2011 03:40:13 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa03 [127.0.0.1]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with SMTP id p6I3WIkG032202; Sun, 17 Jul 2011 22:40:13 -0500 Received: from sbhfisltcgw07.fnfis.com ([10.132.248.135]) by ltcfislmsgpa03.fnfis.com with ESMTP id xjs5f03nc-1; Sun, 17 Jul 2011 22:40:13 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by SBHFISLTCGW07.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Jul 2011 22:40:12 -0500 Received: from [10.0.0.104] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Jul 2011 22:40:04 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: <4E23797A.8060209@FreeBSD.org> Date: Sun, 17 Jul 2011 20:40:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E23797A.8060209@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 18 Jul 2011 03:40:04.0838 (UTC) FILETIME=[61B1A060:01CC44FC] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-18_01:2011-07-16, 2011-07-18, 1970-01-01 signatures=0 Content-Type: text/plain; charset="ISO-8859-1" Cc: freebsd-hackers@freebsd.org, f0andrey@gmail.com, "Teske, Devin" Subject: Re: [RELEASE] New Boot-Loader Menu bugs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 03:40:14 -0000 Hi Doug, On Jul 17, 2011, at 5:08 PM, Doug Barton wrote: > There also seems to be a bug with the new boot loader that if you bounce > out to the prompt and do 'boot kernel.other' the kern.module_path sysctl > is not updated. It still lists /boot/kernel first; but that should be > replaced by /boot/kernel.other. I had a chance to try this out in a VM. I just tested this in FreeBSD 8.1-RELEASE with my loader_menu applied (exac= tly what's available from rev 222417). The results I get are actually what you describe should happen. Here's the steps I took: 1. Made sure all "kernel=3D" and "module_path=3D" lines were commented out = in loader.conf(5) 2. Moved my kernel to /boot/kernel/kernel 3. Made a copy of my kernel to /boot/kernel2/kernel 4. Rebooted. Didn't touch anything. Verified that when I came up, `sysctl -= n kern.bootfile' was /boot/kernel/kernel. Good. We have a baseline operatio= n that things are working as-expected without interrupting the boot-process= (that is to say, that loader(8) loaded the kernel in it's default location= ). 5. Reboot again. This time, I press Escape to the drop to the loader(8) pro= mpt. 6. I took "boot /boot/kernel2" 7. I see the new kernel being loaded. 8. The kernel executes. 9. My system boots as-expected. 10. The value of sysctl kern.module_path produces (drum roll): /boot/kernel= 2;/boot/kernel;/boot/modules What release are you running? I can't replicate the bug in 8.1-RELEASE with= the new loader menu applied. It's possible that the bug was introduced som= e other way. --=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 Mon Jul 18 07:40:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 62E51106566B for ; Mon, 18 Jul 2011 07:40:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9F7F4152EA4; Mon, 18 Jul 2011 07:40:20 +0000 (UTC) Message-ID: <4E23E363.2010303@FreeBSD.org> Date: Mon, 18 Jul 2011 00:40:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Devin Teske References: <4E23797A.8060209@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, f0andrey@gmail.com, "Teske, Devin" Subject: Re: [RELEASE] New Boot-Loader Menu bugs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 07:40:22 -0000 On 07/17/2011 20:40, Devin Teske wrote: > What release are you running? Recent HEAD -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 12:34:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 750CF106566B for ; Mon, 18 Jul 2011 12:34:13 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id BAA0A8FC13 for ; Mon, 18 Jul 2011 12:34:12 +0000 (UTC) Received: (qmail 94648 invoked by uid 1004); 18 Jul 2011 12:34:14 -0000 Message-ID: <4E2427E4.5080201@uffe.org> Date: Mon, 18 Jul 2011 14:32:36 +0200 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Mnenhy/0.8.3 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------050702030708090303000702" Subject: [PATCH] sysctl cleanup - unifying sysctls: vm.kvm_size and vm.kvm_free X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 12:34:13 -0000 This is a multi-part message in MIME format. --------------050702030708090303000702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please consider this patch - it unifies sysctls: vm.kvm_size and vm.kvm_free. Currently these sysctls are only found under i386 and amd64: sys/i386/i386/pmap.c sys/i386/xen/pmap.c sys/amd64/amd64/pmap.c It seems logical (to me) to move them into a generic location suce as sys/vm/vm_kern.c Patch against HEAD (revision 224180) attached. Kind regards Uffe Jakobsen --------------050702030708090303000702 Content-Type: text/plain; name="sysctl_vm_kvm.patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysctl_vm_kvm.patch.txt" Index: sys/vm/vm_kern.c =================================================================== --- sys/vm/vm_kern.c (revision 224180) +++ sys/vm/vm_kern.c (working copy) @@ -588,6 +588,26 @@ kmem_init_zero_region(); } +static int +kvm_size(SYSCTL_HANDLER_ARGS) +{ + unsigned long ksize = VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS; + + return sysctl_handle_long(oidp, &ksize, 0, req); +} +SYSCTL_PROC(_vm, OID_AUTO, kvm_size, CTLTYPE_LONG|CTLFLAG_RD, + 0, 0, kvm_size, "LU", "Size of KVM"); + +static int +kvm_free(SYSCTL_HANDLER_ARGS) +{ + unsigned long kfree = VM_MAX_KERNEL_ADDRESS - kernel_vm_end; + + return sysctl_handle_long(oidp, &kfree, 0, req); +} +SYSCTL_PROC(_vm, OID_AUTO, kvm_free, CTLTYPE_LONG|CTLFLAG_RD, + 0, 0, kvm_free, "LU", "Amount of KVM free"); + #ifdef DIAGNOSTIC /* * Allow userspace to directly trigger the VM drain routine for testing Index: sys/i386/i386/pmap.c =================================================================== --- sys/i386/i386/pmap.c (revision 224180) +++ sys/i386/i386/pmap.c (working copy) @@ -2042,27 +2042,7 @@ } PMAP_LOCK_DESTROY(pmap); } - -static int -kvm_size(SYSCTL_HANDLER_ARGS) -{ - unsigned long ksize = VM_MAX_KERNEL_ADDRESS - KERNBASE; - return (sysctl_handle_long(oidp, &ksize, 0, req)); -} -SYSCTL_PROC(_vm, OID_AUTO, kvm_size, CTLTYPE_LONG|CTLFLAG_RD, - 0, 0, kvm_size, "IU", "Size of KVM"); - -static int -kvm_free(SYSCTL_HANDLER_ARGS) -{ - unsigned long kfree = VM_MAX_KERNEL_ADDRESS - kernel_vm_end; - - return (sysctl_handle_long(oidp, &kfree, 0, req)); -} -SYSCTL_PROC(_vm, OID_AUTO, kvm_free, CTLTYPE_LONG|CTLFLAG_RD, - 0, 0, kvm_free, "IU", "Amount of KVM free"); - /* * grow the number of kernel page table entries, if needed */ Index: sys/i386/xen/pmap.c =================================================================== --- sys/i386/xen/pmap.c (revision 224180) +++ sys/i386/xen/pmap.c (working copy) @@ -1856,27 +1856,7 @@ mtx_unlock(&createdelete_lock); #endif } - -static int -kvm_size(SYSCTL_HANDLER_ARGS) -{ - unsigned long ksize = VM_MAX_KERNEL_ADDRESS - KERNBASE; - return sysctl_handle_long(oidp, &ksize, 0, req); -} -SYSCTL_PROC(_vm, OID_AUTO, kvm_size, CTLTYPE_LONG|CTLFLAG_RD, - 0, 0, kvm_size, "IU", "Size of KVM"); - -static int -kvm_free(SYSCTL_HANDLER_ARGS) -{ - unsigned long kfree = VM_MAX_KERNEL_ADDRESS - kernel_vm_end; - - return sysctl_handle_long(oidp, &kfree, 0, req); -} -SYSCTL_PROC(_vm, OID_AUTO, kvm_free, CTLTYPE_LONG|CTLFLAG_RD, - 0, 0, kvm_free, "IU", "Amount of KVM free"); - /* * grow the number of kernel page table entries, if needed */ Index: sys/amd64/amd64/pmap.c =================================================================== --- sys/amd64/amd64/pmap.c (revision 224180) +++ sys/amd64/amd64/pmap.c (working copy) @@ -1926,27 +1926,7 @@ vm_page_free_zero(m); PMAP_LOCK_DESTROY(pmap); } - -static int -kvm_size(SYSCTL_HANDLER_ARGS) -{ - unsigned long ksize = VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS; - return sysctl_handle_long(oidp, &ksize, 0, req); -} -SYSCTL_PROC(_vm, OID_AUTO, kvm_size, CTLTYPE_LONG|CTLFLAG_RD, - 0, 0, kvm_size, "LU", "Size of KVM"); - -static int -kvm_free(SYSCTL_HANDLER_ARGS) -{ - unsigned long kfree = VM_MAX_KERNEL_ADDRESS - kernel_vm_end; - - return sysctl_handle_long(oidp, &kfree, 0, req); -} -SYSCTL_PROC(_vm, OID_AUTO, kvm_free, CTLTYPE_LONG|CTLFLAG_RD, - 0, 0, kvm_free, "LU", "Amount of KVM free"); - /* * grow the number of kernel page table entries, if needed */ --------------050702030708090303000702-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 13:54:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4670C106564A for ; Mon, 18 Jul 2011 13:54:33 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 035268FC1C for ; Mon, 18 Jul 2011 13:54:32 +0000 (UTC) Received: by qwc9 with SMTP id 9so2089946qwc.13 for ; Mon, 18 Jul 2011 06:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P7mDoYXDfth/SVhKDjlCfcVJqvcyd987l6ga1Ms4Bog=; b=e64FJtXCMk4D1+K6ZqHFPxpZJLhFAfNYfUXcXa2IhUuoUIzaZpaw4mh+gFFj0+sx41 NuFLkXIkPpFHwPD9OfiUE9kdEGTdZHoaEiW0fmB83F55MCdkgaxwY/xr1V3zW0eIwVId U1U3Rn/si998FRnY6giA49RMXK6xNb8hlKyhs= MIME-Version: 1.0 Received: by 10.229.7.137 with SMTP id d9mr4742042qcd.251.1310997272286; Mon, 18 Jul 2011 06:54:32 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.11.40 with HTTP; Mon, 18 Jul 2011 06:54:32 -0700 (PDT) In-Reply-To: <4E2427E4.5080201@uffe.org> References: <4E2427E4.5080201@uffe.org> Date: Mon, 18 Jul 2011 06:54:32 -0700 X-Google-Sender-Auth: DthI1KzXSciKBxdftAi4KoYuO70 Message-ID: From: mdf@FreeBSD.org To: Uffe Jakobsen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] sysctl cleanup - unifying sysctls: vm.kvm_size and vm.kvm_free X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:54:33 -0000 On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen wrote: > Please consider this patch - it unifies sysctls: vm.kvm_size and > vm.kvm_free. > > Currently these sysctls are only found under i386 and amd64: > > sys/i386/i386/pmap.c > sys/i386/xen/pmap.c > sys/amd64/amd64/pmap.c > > It seems logical (to me) to move them into a generic location suce as > sys/vm/vm_kern.c > > Patch against HEAD (revision 224180) attached. I don't believe that VM_MAX_KERNEL_ADDRESS is relevant to all architectures, which is why these sysctls are in i386/amd64 specific files. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 14:41:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226E9106566B; Mon, 18 Jul 2011 14:41:13 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id D441E8FC16; Mon, 18 Jul 2011 14:41:12 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QioQt-000MJQ-T9; Mon, 18 Jul 2011 17:04:28 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jul 2011 17:04:27 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org Subject: broadcast oddity X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:41:13 -0000 this code behaves correctly when run from a diskless host which booted via PXE, but fails on a host that was booted from disk. hint: the non working sends a packet with a non ethernet broadcast address and an ip address of 255.255.255.255, the working version sets the ethernet address to 0xffffffff and the ip to the network broadcast address. what am I doing wrong? danny PS: what is the correct way to obtain the network broadcast address? #include #include #include #include #include #include void bcast() { int so, on; char msg[BUFSIZ]; struct timespec t2; struct sockaddr_in soin; if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) { perror("socket"); exit(-1); } on = 1; if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) { perror("setsockopt"); exit(-1); } bzero(&soin, sizeof(struct sockaddr_in)); soin.sin_len = sizeof(struct sockaddr_in); soin.sin_family = AF_INET; soin.sin_addr.s_addr = INADDR_BROADCAST; soin.sin_port = htons(12345); while(1) { clock_gettime(CLOCK_REALTIME, &t2); sprintf(msg, "0x%016x", t2.tv_sec); if(sendto(so, msg, strlen(msg)+1, 0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) < 0) { perror("sendto"); break; } sleep(10); } } main(int cc, char **vv) { bcast(); } From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 14:48:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E218106566C for ; Mon, 18 Jul 2011 14:48:53 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 68FD08FC16 for ; Mon, 18 Jul 2011 14:48:51 +0000 (UTC) Received: (qmail 97158 invoked by uid 1004); 18 Jul 2011 14:48:54 -0000 Message-ID: <4E244797.80109@uffe.org> Date: Mon, 18 Jul 2011 16:47:51 +0200 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Mnenhy/0.8.3 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4E2427E4.5080201@uffe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mdf@FreeBSD.org Subject: Re: [PATCH] sysctl cleanup - unifying sysctls: vm.kvm_size and vm.kvm_free X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:48:53 -0000 On 2011-07-18 15:54, mdf@FreeBSD.org wrote: > On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen wrote: >> Please consider this patch - it unifies sysctls: vm.kvm_size and >> vm.kvm_free. >> >> Currently these sysctls are only found under i386 and amd64: >> >> sys/i386/i386/pmap.c >> sys/i386/xen/pmap.c >> sys/amd64/amd64/pmap.c >> >> It seems logical (to me) to move them into a generic location suce as >> sys/vm/vm_kern.c >> >> Patch against HEAD (revision 224180) attached. > > I don't believe that VM_MAX_KERNEL_ADDRESS is relevant to all > architectures, which is why these sysctls are in i386/amd64 specific > files. > Well I'm not an expert - but I did some checking before submitting this patch. As far as I can see VM_MAX_KERNEL_ADDRESS is addressed in several generic kernel files: sys/kern/subr_param.c sys/vm/vm_map.c sys/vm/vm_object.c and as far as I can see these locations are not ifdef'ed with any platform specific condition. Further more the following platform-specific files defines VM_MAX_KERNEL_ADDRESS: sys/amd64/include/vmparam.h sys/arm/include/vmparam.h sys/i386/include/vmparam.h sys/ia64/include/vmparam.h sys/mips/include/vmparam.h sys/powerpc/include/vmparam.h sys/sparc64/include/vmparam.h That leaves us only with "pc98" and "x86" platform-specifics subdirs that does not directly define VM_MAX_KERNEL_ADDRESS sys/pc98/include/vmparam.h includes "i386/vmparam.h" which defines VM_MAX_KERNEL_ADDRESS While "x86" subdir is a little more questionable - though it has several includes for machine/vmparam.h which defines VM_MAX_KERNEL_ADDRESS Could soneone please give me an indication of what would be the correct way for me to verify this in a more "scientific" way. I've only got access to i386 and amd64 hardware but would cross-platform compiling for all platforms be a sufficient way of verifying this ? Thanks in advance. Kind regards Uffe From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 14:52:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1DD51065677 for ; Mon, 18 Jul 2011 14:52:57 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta31.charter.net (mta31.charter.net [216.33.127.82]) by mx1.freebsd.org (Postfix) with ESMTP id 690418FC1A for ; Mon, 18 Jul 2011 14:52:57 +0000 (UTC) Received: from imp09 ([10.20.200.9]) by mta31.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110718145256.OTMH3994.mta31.charter.net@imp09> for ; Mon, 18 Jul 2011 10:52:56 -0400 Received: from [192.168.1.125] ([75.135.75.204]) by imp09 with smtp.charter.net id 9Ssv1h00a4QU3rf05Sswua; Mon, 18 Jul 2011 10:52:56 -0400 X-Authority-Analysis: v=1.1 cv=1b2X7W/SifksZeClH/haT1SUt4udqxFGF00pZw2/jJk= c=1 sm=1 a=qGV6uSQ7kSsA:10 a=OMXgzpAV4rQA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=0rWYpq1FyvbmNm91JE0A:9 a=wPNLvfGTeEIA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E2448D1.6020504@gamozo.org> Date: Mon, 18 Jul 2011 09:53:05 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:52:57 -0000 Hello, In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi' > test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi' >> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. Any tips? Otherwise I'll be looking into this today myself. -Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 15:35:16 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 043CB106564A for ; Mon, 18 Jul 2011 15:35:16 +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 304E08FC0A for ; Mon, 18 Jul 2011 15:35:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA24443; Mon, 18 Jul 2011 18:18:58 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E244EE1.40604@FreeBSD.org> Date: Mon, 18 Jul 2011 18:18:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Brandon Falk References: <4E2448D1.6020504@gamozo.org> In-Reply-To: <4E2448D1.6020504@gamozo.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:35:16 -0000 on 18/07/2011 17:53 Brandon Falk said the following: > Hello, > > In recent branches (confirmed with 224119) builds compiled with clang happen to > throw 'Unknown error: -512' in a lot of places, making the system unusable. > (Untested on gcc compiled systems). Originally I thought the problem was with > specific programs, then I narrowed it down to file I/O, and now I've narrowed it > down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues > whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every > other time you run the program. Common issues, portsnap is affected, making it > impossible to fetch/extract ports. As well as redirecting output in shells eg > `echo 'hi' > test` fails every other try. You have the same issue with text > editors like `edit` where it fails every other save. There are no issues with > `echo 'hi' >> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. > > Any tips? Otherwise I'll be looking into this today myself. Just a hint that you could try using DTrace syscall and fbt providers to see where in kernel (if in kernel) that -512 return value originates. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 16:33:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CCFD1065670 for ; Mon, 18 Jul 2011 16:33:56 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC3208FC14 for ; Mon, 18 Jul 2011 16:33:55 +0000 (UTC) Received: by qyk38 with SMTP id 38so2218896qyk.13 for ; Mon, 18 Jul 2011 09:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nV7vOR7eeFO6zmsvV8/2GbxA9cR0S2dYvkxOJTPl9rk=; b=lTnmrm6AR+kwFTRyTBalKwPVa0v8vlj+nfRKZnYm4LDqe169gN2U+s28eGuHIEgQBX 7x+sV9hg81PEZD9vuB2nVWV3GqLOYC4aHH6WoBgE7heGF2VAtYcQh1GYzF8QFGkmB8jO Pn2KvDqgm/C/qQshiw0kLtdpGzOLW/sw0aEk0= MIME-Version: 1.0 Received: by 10.229.190.83 with SMTP id dh19mr5030439qcb.175.1311006835001; Mon, 18 Jul 2011 09:33:55 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.11.40 with HTTP; Mon, 18 Jul 2011 09:33:54 -0700 (PDT) In-Reply-To: <4E244797.80109@uffe.org> References: <4E2427E4.5080201@uffe.org> <4E244797.80109@uffe.org> Date: Mon, 18 Jul 2011 09:33:54 -0700 X-Google-Sender-Auth: 2JkrrZZvcj8BQ-_odBXDvSSD8N4 Message-ID: From: mdf@FreeBSD.org To: Uffe Jakobsen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] sysctl cleanup - unifying sysctls: vm.kvm_size and vm.kvm_free X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:33:56 -0000 On Mon, Jul 18, 2011 at 7:47 AM, Uffe Jakobsen wrote: > On 2011-07-18 15:54, mdf@FreeBSD.org wrote: >> On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen =A0wrote: >>> >>> Please consider this patch - it unifies sysctls: vm.kvm_size and >>> vm.kvm_free. >>> >>> Currently these sysctls are only found under i386 and amd64: >>> >>> sys/i386/i386/pmap.c >>> sys/i386/xen/pmap.c >>> sys/amd64/amd64/pmap.c >>> >>> It seems logical (to me) to move them into a generic location suce as >>> sys/vm/vm_kern.c >>> >>> Patch against HEAD (revision 224180) attached. >> >> I don't believe that VM_MAX_KERNEL_ADDRESS is relevant to all >> architectures, which is why these sysctls are in i386/amd64 specific >> files. >> > > Well I'm not an expert - but I did some checking before submitting this > patch. > > As far as I can see VM_MAX_KERNEL_ADDRESS is addressed in several generic > kernel files: > > sys/kern/subr_param.c > sys/vm/vm_map.c > sys/vm/vm_object.c > > and as far as I can see these locations are not ifdef'ed with any platfor= m > specific condition. > > > > Further more the following platform-specific files defines > VM_MAX_KERNEL_ADDRESS: > > sys/amd64/include/vmparam.h > sys/arm/include/vmparam.h > sys/i386/include/vmparam.h > sys/ia64/include/vmparam.h > sys/mips/include/vmparam.h > sys/powerpc/include/vmparam.h > sys/sparc64/include/vmparam.h > > That leaves us only with "pc98" and "x86" platform-specifics subdirs that > does not directly define VM_MAX_KERNEL_ADDRESS > > sys/pc98/include/vmparam.h includes "i386/vmparam.h" which defines > VM_MAX_KERNEL_ADDRESS > > While "x86" subdir is a little more questionable - though it has several > includes for machine/vmparam.h which defines VM_MAX_KERNEL_ADDRESS > > > > Could soneone please give me an indication of what would be the correct w= ay > for me to verify this in a more "scientific" way. Alan Cox is usually a definitive answer for FreeBSD vm questions. My recollection was in the context of a bug with memguard(9) on sparc64, however now that I refresh my memory the issue there was VM_KMEM_SIZE_MAX, not VM_MAX_KERNEL_ADDRESS. So, my apologies as my memory has led me astray. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 20:47:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF3C8106566C; Mon, 18 Jul 2011 20:47:42 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5838FC08; Mon, 18 Jul 2011 20:47:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=sWXTlsCYLdFETDrReVLOeKJ90E8G+oDcJxLauJJ8d/I=; b=C1GTLWoNxgJcVMGnftbXINVDbcPUQId3lSvxNfu4ULnOwAhwsIYb0ASolz1yNQzLfrdqV0Pe+8W8XE5ynVjBhJanHASXMKY/tmCj0CHgieW6/WX2OY2e1pIsrtEKswEpNKl/dRuE4663Oc5ocFFiVXxcMUkyRMBNyzWOS/9w9MvWR/h60P57e7LzomZySYm3WNXgJRnbYYMX6FEqXFypCazZI7u6M7+wjyJFOPQmQYTeTUAZPLromtFysDIsbEBHIF+PKMeMnJtdx8Ah9fs3OFr3/PiAUnpJkXrs/cXZ1b2OcsIfR9lT/bceEdYzG1CnGbOxpY1Tv0OsW9n6jVA6VA==; Received: from MacBook-Eygene-Ryabinkin.local (ppp91-77-162-104.pppoe.mtu-net.ru [91.77.162.104]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1QiuUE-000DnR-2u; Tue, 19 Jul 2011 00:32:18 +0400 Date: Tue, 19 Jul 2011 00:32:15 +0400 From: Eygene Ryabinkin To: Daniel Braniss Message-ID: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="McpcKDxJRrEJVmOH" Content-Disposition: inline In-Reply-To: Sender: rea@codelabs.ru Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:47:43 -0000 --McpcKDxJRrEJVmOH Content-Type: multipart/mixed; boundary="UeXZ3FjlYZvuln/G" Content-Disposition: inline --UeXZ3FjlYZvuln/G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Daniel, good day. Mon, Jul 18, 2011 at 05:04:27PM +0300, Daniel Braniss wrote: > this code behaves correctly when run from a diskless host which > booted via PXE, but fails on a host that was booted from disk. > hint: the non working sends a packet with a non ethernet broadcast > address and an ip address of 255.255.255.255, And that non-broadcast ethernet address is the MAC of your default router? > the working version sets the ethernet address to 0xffffffff and the > ip to the network broadcast address. What's your routing table (netstat -rn) for the PXE-booted host? > what am I doing wrong? >=20 > danny > PS: what is the correct way to obtain the network broadcast address? You nailed it: you should send packets to the network's broadcast, not to the 0xffffffff. And in order to find the broadcast address for the interface (or network at that interface), you should use getifaddrs(), like in the attached example. It is very quick and dirty one and it has some limitations (e.g., it takes the first broadcast address from the interface), but it should be a good starting point. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --UeXZ3FjlYZvuln/G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bcast.c" #include #include #include #include #include #include #include #include #include void bcast(in_addr_t addr) { int so, on; char msg[BUFSIZ]; struct timespec t2; struct sockaddr_in soin; if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) { perror("socket"); exit(-1); } on = 1; if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) { perror("setsockopt"); exit(-1); } bzero(&soin, sizeof(struct sockaddr_in)); soin.sin_len = sizeof(struct sockaddr_in); soin.sin_family = AF_INET; soin.sin_addr.s_addr = addr; soin.sin_port = htons(12345); while(1) { clock_gettime(CLOCK_REALTIME, &t2); sprintf(msg, "0x%016x", t2.tv_sec); if(sendto(so, msg, strlen(msg)+1, 0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) < 0) { perror("sendto"); break; } sleep(10); } } main(int argc, char *argv[]) { struct ifaddrs *ifap, *ifa, *our_if; struct sockaddr_in *sin; if (argc < 2) errx(1, "No arguments"); if (getifaddrs(&ifap) != 0) perror("getifaddrs"); our_if = NULL; for (ifa = ifap; ifa != NULL; ifa = ifa->ifa_next) { if (strcmp(argv[1], ifa->ifa_name) == 0) { sin = (struct sockaddr_in *)ifa->ifa_broadaddr; if (!(ifa->ifa_flags & IFF_BROADCAST) || sin == NULL || sin->sin_addr.s_addr == 0) continue; our_if = ifa; break; } } if (!our_if) errx(1, "Can't find broadcast-able interface '%s'", argv[1]); bcast(sin->sin_addr.s_addr); freeifaddrs(ifap); } --UeXZ3FjlYZvuln/G-- --McpcKDxJRrEJVmOH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iF0EAREIAAYFAk4kmE8ACgkQFq+eroFS7PvE+QD/ZL0cpFaKvLA+ZWWFH/QlA5Xb hqKEG+XY90zdya2/twEA9R3xcK8wwRtOiLf7Tb9SHviukeMsrxwufSWhdapJfj0= =Iujs -----END PGP SIGNATURE----- --McpcKDxJRrEJVmOH-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 21:35:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFC54106566C for ; Mon, 18 Jul 2011 21:35:20 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B756B8FC0A for ; Mon, 18 Jul 2011 21:35:20 +0000 (UTC) Received: by qyk38 with SMTP id 38so2401064qyk.13 for ; Mon, 18 Jul 2011 14:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=6S33UgyfLmXGH9DnlHJCwhKMntFnHGs15v54HgAcq/k=; b=mrvfaIAaTAZSnADJLL0ZKsOxQ+z3yoRBpyPggCUoE4Fwl1nRruHw1vdNpmrOG7tjpQ Zs+g13VAhOmQ8dBNF6NB2PwAg/Pwb7Vxo0dkTSOs2zdNDm9nuAbgIgvp3vGmx7XLBwnq EfjQ4cXQXsLW6qLX4eL3DCa/6IlMEzPr744NA= MIME-Version: 1.0 Received: by 10.229.114.194 with SMTP id f2mr5281839qcq.112.1311023353409; Mon, 18 Jul 2011 14:09:13 -0700 (PDT) Received: by 10.229.37.12 with HTTP; Mon, 18 Jul 2011 14:09:13 -0700 (PDT) Date: Mon, 18 Jul 2011 14:09:13 -0700 Message-ID: From: Ali Mashtizadeh To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Subject: xlocale X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:35:21 -0000 Hi Folks, I was wondering if there is any plan to support the xlocale POSIX api? The stdcxx library that is part of the LLVM project requires it to function, otherwise it may take a large porting effort. Given that this is part of the posix standard it seems prudent to add. The only mention I found of this was in the wiki below, describing that they were planning on skipping support for xlocale. http://wiki.freebsd.org/KonradJankowski/Collation Thanks, -- Ali Mashtizadeh From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 00:19:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5A811065670 for ; Tue, 19 Jul 2011 00:19:11 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta11.charter.net (mta11.charter.net [216.33.127.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2038FC0C for ; Tue, 19 Jul 2011 00:19:11 +0000 (UTC) Received: from imp10 ([10.20.200.15]) by mta11.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110719001910.SSFJ4091.mta11.charter.net@imp10>; Mon, 18 Jul 2011 20:19:10 -0400 Received: from [192.168.1.125] ([75.135.75.204]) by imp10 with smtp.charter.net id 9cK91h00E4QU3rf05cK9Cu; Mon, 18 Jul 2011 20:19:10 -0400 X-Authority-Analysis: v=1.1 cv=G6Q69DB3AUoJKS2BpLRaz8MQ2NORN7h5HRzrJMPOhRw= c=1 sm=1 a=qGV6uSQ7kSsA:10 a=YzQM1Zd3q-sA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=Twq80G31HvXCSWYLlK4A:9 a=I1MSExzIpqJtw2PBf2cA:7 a=wPNLvfGTeEIA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E24CD87.4010906@gamozo.org> Date: Mon, 18 Jul 2011 19:19:19 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Andriy Gapon References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> In-Reply-To: <4E244EE1.40604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 00:19:12 -0000 On 7/18/2011 10:18 AM, Andriy Gapon wrote: > on 18/07/2011 17:53 Brandon Falk said the following: >> Hello, >> >> In recent branches (confirmed with 224119) builds compiled with clang happen to >> throw 'Unknown error: -512' in a lot of places, making the system unusable. >> (Untested on gcc compiled systems). Originally I thought the problem was with >> specific programs, then I narrowed it down to file I/O, and now I've narrowed it >> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues >> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every >> other time you run the program. Common issues, portsnap is affected, making it >> impossible to fetch/extract ports. As well as redirecting output in shells eg >> `echo 'hi'> test` fails every other try. You have the same issue with text >> editors like `edit` where it fails every other save. There are no issues with >> `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. >> >> Any tips? Otherwise I'll be looking into this today myself. > > Just a hint that you could try using DTrace syscall and fbt providers to see where > in kernel (if in kernel) that -512 return value originates. > Update: I've traced more and more into the kernel, and currently I have found the following trace: >>> ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) >>> vn_truncate() (in sys/kern/vfs_vnops.c:636) >>> kern_openat() (in sys/kern/vfs_syscalls.c:1043) >>> kern_open() (in sys/kern/vfs_syscalls.c:1035) >>> open() (in sys/kern/vfs_syscalls.c:1006) ufs_setattr() returns with -1 (EPERM) I'll continue to try to find the exact problem. A quick workaround currently would probably be to use a different filesystem other than ufs, but then again, I have no clue if other filesystems have the same issue. Hopefully that trace will help anyone who wants to help out. -Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 07:40:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70581065670; Tue, 19 Jul 2011 07:40:13 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCD48FC14; Tue, 19 Jul 2011 07:40:13 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Qj4uZ-0005nH-SR; Tue, 19 Jul 2011 10:40:11 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Eygene Ryabinkin In-reply-to: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> Comments: In-reply-to Eygene Ryabinkin message dated "Tue, 19 Jul 2011 00:32:15 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jul 2011 10:40:11 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 07:40:14 -0000 Hi Eygene, > Daniel, good day. > > Mon, Jul 18, 2011 at 05:04:27PM +0300, Daniel Braniss wrote: > > this code behaves correctly when run from a diskless host which > > booted via PXE, but fails on a host that was booted from disk. > > hint: the non working sends a packet with a non ethernet broadcast > > address and an ip address of 255.255.255.255, > > And that non-broadcast ethernet address is the MAC of your > default router? yes. > > > the working version sets the ethernet address to 0xffffffff and the > > ip to the network broadcast address. > > What's your routing table (netstat -rn) for the PXE-booted host? it's ok, same in both cases. it's picked up via DHCP, in the diskless case by the boot/loader in the second via dhcpclient. > > > what am I doing wrong? > >=20 > > danny > > PS: what is the correct way to obtain the network broadcast address? > > You nailed it: you should send packets to the network's broadcast, > not to the 0xffffffff. > but I'm at the user/ip level!, have no way to set mac/ethernet address. still, the question is why it works in one case, and failes in the other. > And in order to find the broadcast address for the interface (or > network at that interface), you should use getifaddrs(), like in the > attached example. It is very quick and dirty one and it has some > limitations (e.g., it takes the first broadcast address from the > interface), but it should be a good starting point. thanks, danny > Eygene Ryabinkin ,,,^..^,,, > [ Life's unfair - but root password helps! | codelabs.ru ] > [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] > > --UeXZ3FjlYZvuln/G > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="bcast.c" > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > void > bcast(in_addr_t addr) > { > int so, on; > char msg[BUFSIZ]; > struct timespec t2; > struct sockaddr_in soin; > > if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) { > perror("socket"); > exit(-1); > } > on = 1; > if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) { > perror("setsockopt"); > exit(-1); > } > > bzero(&soin, sizeof(struct sockaddr_in)); > soin.sin_len = sizeof(struct sockaddr_in); > soin.sin_family = AF_INET; > soin.sin_addr.s_addr = addr; > soin.sin_port = htons(12345); > while(1) { > clock_gettime(CLOCK_REALTIME, &t2); > sprintf(msg, "0x%016x", t2.tv_sec); > if(sendto(so, msg, strlen(msg)+1, > 0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) < 0) { > perror("sendto"); > break; > } > sleep(10); > } > } > > main(int argc, char *argv[]) > { > struct ifaddrs *ifap, *ifa, *our_if; > struct sockaddr_in *sin; > > if (argc < 2) > errx(1, "No arguments"); > if (getifaddrs(&ifap) != 0) > perror("getifaddrs"); > our_if = NULL; > for (ifa = ifap; ifa != NULL; ifa = ifa->ifa_next) { > if (strcmp(argv[1], ifa->ifa_name) == 0) { > sin = (struct sockaddr_in *)ifa->ifa_broadaddr; > if (!(ifa->ifa_flags & IFF_BROADCAST) || > sin == NULL || > sin->sin_addr.s_addr == 0) > continue; > our_if = ifa; > break; > } > } > if (!our_if) > errx(1, "Can't find broadcast-able interface '%s'", argv[1]); > bcast(sin->sin_addr.s_addr); > freeifaddrs(ifap); > } > > --UeXZ3FjlYZvuln/G-- > > --McpcKDxJRrEJVmOH > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (Darwin) > > iF0EAREIAAYFAk4kmE8ACgkQFq+eroFS7PvE+QD/ZL0cpFaKvLA+ZWWFH/QlA5Xb > hqKEG+XY90zdya2/twEA9R3xcK8wwRtOiLf7Tb9SHviukeMsrxwufSWhdapJfj0= > =Iujs > -----END PGP SIGNATURE----- > > --McpcKDxJRrEJVmOH-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 09:07:35 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8485106566B for ; Tue, 19 Jul 2011 09:07:35 +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 112B68FC15 for ; Tue, 19 Jul 2011 09:07:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA07980; Tue, 19 Jul 2011 12:07:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E254953.9090909@FreeBSD.org> Date: Tue, 19 Jul 2011 12:07:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Brandon Falk References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> <4E24CD87.4010906@gamozo.org> In-Reply-To: <4E24CD87.4010906@gamozo.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 09:07:35 -0000 on 19/07/2011 03:19 Brandon Falk said the following: > On 7/18/2011 10:18 AM, Andriy Gapon wrote: >> on 18/07/2011 17:53 Brandon Falk said the following: >>> Hello, >>> >>> In recent branches (confirmed with 224119) builds compiled with clang happen to >>> throw 'Unknown error: -512' in a lot of places, making the system unusable. >>> (Untested on gcc compiled systems). Originally I thought the problem was with >>> specific programs, then I narrowed it down to file I/O, and now I've narrowed it >>> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues >>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every >>> other time you run the program. Common issues, portsnap is affected, making it >>> impossible to fetch/extract ports. As well as redirecting output in shells eg >>> `echo 'hi'> test` fails every other try. You have the same issue with text >>> editors like `edit` where it fails every other save. There are no issues with >>> `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. >>> >>> Any tips? Otherwise I'll be looking into this today myself. >> >> Just a hint that you could try using DTrace syscall and fbt providers to see where >> in kernel (if in kernel) that -512 return value originates. >> > > Update: > > I've traced more and more into the kernel, and currently I have found the > following trace: > >>>> ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) > (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) >>>> vn_truncate() (in sys/kern/vfs_vnops.c:636) >>>> kern_openat() (in sys/kern/vfs_syscalls.c:1043) >>>> kern_open() (in sys/kern/vfs_syscalls.c:1035) >>>> open() (in sys/kern/vfs_syscalls.c:1006) > > ufs_setattr() returns with -1 (EPERM) But not -512, though. > I'll continue to try to find the exact problem. A quick workaround currently would > probably be to use a different filesystem other than ufs, but then again, I have > no clue if other filesystems have the same issue. > > Hopefully that trace will help anyone who wants to help out. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 10:14:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03129106564A for ; Tue, 19 Jul 2011 10:14:18 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id BBE6A8FC19 for ; Tue, 19 Jul 2011 10:14:17 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:9ccb:15f7:ff4a:ca60] (unknown [IPv6:2001:7b8:3a7:0:9ccb:15f7:ff4a:ca60]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A12445C37; Tue, 19 Jul 2011 12:14:16 +0200 (CEST) Message-ID: <4E2558F7.6040202@FreeBSD.org> Date: Tue, 19 Jul 2011 12:14:15 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brandon Falk References: <4E2448D1.6020504@gamozo.org> In-Reply-To: <4E2448D1.6020504@gamozo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 10:14:18 -0000 On 2011-07-18 16:53, Brandon Falk wrote: > In recent branches (confirmed with 224119) builds compiled with clang > happen to throw 'Unknown error: -512' in a lot of places, making the > system unusable. (Untested on gcc compiled systems). I have never seen this, neither with clang-compiled nor gcc-compiled systems. Can you please verify if it still occurs if you build your system with gcc? If you don't want (or can) rebuild the whole system, you can try to rebuild just your kernel with gcc, and see if the problems disappear. > Originally I > thought the problem was with specific programs, then I narrowed it down > to file I/O, and now I've narrowed it down to open() with O_TRUNC. > Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on > open() it fails with that 'Unknown error: -512' every other time you run > the program. Common issues, portsnap is affected, making it impossible > to fetch/extract ports. As well as redirecting output in shells eg `echo > 'hi'> test` fails every other try. You have the same issue with text > editors like `edit` where it fails every other save. There are no issues > with `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an > O_TRUNC error. I have been running clang-compiled systems for a long time now, and have never seen this. It works fine here, I cannot reproduce any of your examples. Do you build with any special settings in make.conf or src.conf, particularly modified CFLAGS or COPTFLAGS? What is your architecture, i386 or amd64? Any other non-standard configuration or environment settings? From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 11:58:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F67106564A for ; Tue, 19 Jul 2011 11:58:48 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 548668FC0C for ; Tue, 19 Jul 2011 11:58:47 +0000 (UTC) Received: by vws18 with SMTP id 18so3951007vws.13 for ; Tue, 19 Jul 2011 04:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UQSjZu7mJVUvt1glp3gNYXcfOz4zi2WzVnKEYlGe8SI=; b=UNPARXCmeCFlq+DI2RhP2BBcEOluHe3+xzQBFDxNOj5cIvmwEUbqARnYEe2C/a0TA7 ubYOOgHJs74ij5FbV7TAb5agwLrta2Yt3+dtpgl+unQ5VEzIfuENCtYMPveEbG1bqfTC 6oU3NIDsrM/NqsERu2GhwFmXWwuzy29rA6NLk= MIME-Version: 1.0 Received: by 10.220.57.11 with SMTP id a11mr1510764vch.4.1311076727211; Tue, 19 Jul 2011 04:58:47 -0700 (PDT) Received: by 10.220.203.202 with HTTP; Tue, 19 Jul 2011 04:58:47 -0700 (PDT) In-Reply-To: <4E24CD87.4010906@gamozo.org> References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> <4E24CD87.4010906@gamozo.org> Date: Tue, 19 Jul 2011 04:58:47 -0700 Message-ID: From: Garrett Cooper To: Brandon Falk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 11:58:48 -0000 On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk wrote: > On 7/18/2011 10:18 AM, Andriy Gapon wrote: >> >> on 18/07/2011 17:53 Brandon Falk said the following: >>> >>> Hello, >>> >>> In recent branches (confirmed with 224119) builds compiled with clang >>> happen to >>> throw 'Unknown error: -512' in a lot of places, making the system >>> unusable. >>> (Untested on gcc compiled systems). Originally I thought the problem wa= s >>> with >>> specific programs, then I narrowed it down to file I/O, and now I've >>> narrowed it >>> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issue= s >>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: >>> -512' every >>> other time you run the program. Common issues, portsnap is affected, >>> making it >>> impossible to fetch/extract ports. As well as redirecting output in >>> shells eg >>> `echo 'hi'> =A0test` fails every other try. You have the same issue wit= h >>> text >>> editors like `edit` where it fails every other save. There are no issue= s >>> with >>> `echo 'hi'>> =A0test` as there is no O_TRUNC, it only seems to be an >>> O_TRUNC error. >>> >>> Any tips? Otherwise I'll be looking into this today myself. >> >> Just a hint that you could try using DTrace syscall and fbt providers to >> see where >> in kernel (if in kernel) that -512 return value originates. >> > > Update: > > I've traced more and more into the kernel, and currently I have found the > following trace: > >>>> ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) > (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) >>>> vn_truncate() (in sys/kern/vfs_vnops.c:636) >>>> kern_openat() (in sys/kern/vfs_syscalls.c:1043) >>>> kern_open() =A0 (in sys/kern/vfs_syscalls.c:1035) >>>> open() (in sys/kern/vfs_syscalls.c:1006) > > ufs_setattr() returns with -1 (EPERM) > > I'll continue to try to find the exact problem. A quick workaround curren= tly > would probably be to use a different filesystem other than ufs, but then > again, I have no clue if other filesystems have the same issue. > > Hopefully that trace will help anyone who wants to help out. What UFS options do you have defined in your kernel? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 12:31:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAC931065672; Tue, 19 Jul 2011 12:31:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F81C8FC1A; Tue, 19 Jul 2011 12:31:39 +0000 (UTC) Received: by vxg33 with SMTP id 33so3988205vxg.13 for ; Tue, 19 Jul 2011 05:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+TiYhcEmytP0ZAGwY1v5tY/1zhELjXRWzqXBWxUtmiI=; b=Ro8QbuPb/sMcLjdgfRyuF8fhVbFcnjIa9OOEOZRJ0nj5oAoIgNiDqXAijAMiPaFtc0 +7Bs/VV26W+G4qewKl7ScdMx48be8lHDDvZiZCDt7RT1yIUxO0aY42oKBRinHb2lt1lN RiMUak7GLXHTerSXLrQALH08D6QL7Yxphkjjk= MIME-Version: 1.0 Received: by 10.52.97.201 with SMTP id ec9mr8117643vdb.10.1311078698524; Tue, 19 Jul 2011 05:31:38 -0700 (PDT) Received: by 10.220.203.202 with HTTP; Tue, 19 Jul 2011 05:31:38 -0700 (PDT) In-Reply-To: References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> <4E24CD87.4010906@gamozo.org> Date: Tue, 19 Jul 2011 05:31:38 -0700 Message-ID: From: Garrett Cooper To: Brandon Falk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 12:31:39 -0000 On Tue, Jul 19, 2011 at 4:58 AM, Garrett Cooper wrote: > On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk wrote: >> On 7/18/2011 10:18 AM, Andriy Gapon wrote: >>> >>> on 18/07/2011 17:53 Brandon Falk said the following: >>>> >>>> Hello, >>>> >>>> In recent branches (confirmed with 224119) builds compiled with clang >>>> happen to >>>> throw 'Unknown error: -512' in a lot of places, making the system >>>> unusable. >>>> (Untested on gcc compiled systems). Originally I thought the problem w= as >>>> with >>>> specific programs, then I narrowed it down to file I/O, and now I've >>>> narrowed it >>>> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issu= es >>>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: >>>> -512' every >>>> other time you run the program. Common issues, portsnap is affected, >>>> making it >>>> impossible to fetch/extract ports. As well as redirecting output in >>>> shells eg >>>> `echo 'hi'> =A0test` fails every other try. You have the same issue wi= th >>>> text >>>> editors like `edit` where it fails every other save. There are no issu= es >>>> with >>>> `echo 'hi'>> =A0test` as there is no O_TRUNC, it only seems to be an >>>> O_TRUNC error. >>>> >>>> Any tips? Otherwise I'll be looking into this today myself. >>> >>> Just a hint that you could try using DTrace syscall and fbt providers t= o >>> see where >>> in kernel (if in kernel) that -512 return value originates. >>> >> >> Update: >> >> I've traced more and more into the kernel, and currently I have found th= e >> following trace: >> >>>>> ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) >> (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR= ) >>>>> vn_truncate() (in sys/kern/vfs_vnops.c:636) >>>>> kern_openat() (in sys/kern/vfs_syscalls.c:1043) >>>>> kern_open() =A0 (in sys/kern/vfs_syscalls.c:1035) >>>>> open() (in sys/kern/vfs_syscalls.c:1006) >> >> ufs_setattr() returns with -1 (EPERM) >> >> I'll continue to try to find the exact problem. A quick workaround curre= ntly >> would probably be to use a different filesystem other than ufs, but then >> again, I have no clue if other filesystems have the same issue. >> >> Hopefully that trace will help anyone who wants to help out. > > What UFS options do you have defined in your kernel? Also, what does mount say and have you tried running as root? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 13:16:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF6E3106566C for ; Tue, 19 Jul 2011 13:16:09 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 982D88FC1A for ; Tue, 19 Jul 2011 13:16:09 +0000 (UTC) Received: by iwr19 with SMTP id 19so4942622iwr.13 for ; Tue, 19 Jul 2011 06:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HKBPmifs5I3Gm/8x+imWywjrGUlv0Uaz1ELIrHB5bMA=; b=UGC7m77aJ3yGRzqTIpLEUx95kkdvQxwpTFNXZ/cMXe74NH1RJYCiV3o5lX3+yWEPLJ VPk4aKRMnLQj3dlt0uqwsVgFk98Am3ppA/A9WENqZg25WOy8q+Rb6G6Gyd44ZLiNDSFl pQmb3h1bdOaZBaAXhZZgQowd2CLu1/SmhefWk= MIME-Version: 1.0 Received: by 10.42.100.72 with SMTP id z8mr8631894icn.448.1311081368782; Tue, 19 Jul 2011 06:16:08 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.224.70 with HTTP; Tue, 19 Jul 2011 06:16:08 -0700 (PDT) In-Reply-To: <20110705134447.493e0bf1@kan.dnsalias.net> References: <20110702193724.5c55a6c9@kan.dnsalias.net> <20110703103925.0bdf255a@kan.dnsalias.net> <20110705134447.493e0bf1@kan.dnsalias.net> Date: Tue, 19 Jul 2011 15:16:08 +0200 X-Google-Sender-Auth: QsGrsSgxjo9nRtJAt1_uDdCrtXs Message-ID: From: Robert Millan To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] __FreeBSD_kernel__ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:16:09 -0000 2011/7/5 Alexander Kabaev : > The slow way would be the right way if you were inclined to really take > it. Once old releases of tools that can be broken by the new macro > use are long and forgotten we can start on relying on said macro, but > not before. Given that your main concern is backward compatibility, is it an inconvenient to you if 3rd party compilers such as GCC or Clang begin adding this macro? If you're still not comfortable with this macro by the time you want to import one of those, it just takes a minute to remove it. The purpose of this, of course, is to start the clock count (as you've put it: "Once old releases of tools that can be broken by the new macro use are long and forgotten we can start on relying on said macro"). -- Robert Millan From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 15:16:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6908106566C; Tue, 19 Jul 2011 15:16:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AC3E88FC13; Tue, 19 Jul 2011 15:16:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 43AEF46B3C; Tue, 19 Jul 2011 11:16:08 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D4AD28A02E; Tue, 19 Jul 2011 11:16:07 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 19 Jul 2011 10:04:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E23E363.2010303@FreeBSD.org> In-Reply-To: <4E23E363.2010303@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107191004.25281.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Jul 2011 11:16:07 -0400 (EDT) Cc: f0andrey@gmail.com, Doug Barton , Devin Teske , "Teske, Devin" Subject: Re: [RELEASE] New Boot-Loader Menu bugs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:16:08 -0000 On Monday, July 18, 2011 3:40:19 am Doug Barton wrote: > On 07/17/2011 20:40, Devin Teske wrote: > > What release are you running? > > Recent HEAD I upgraded my desktop at home to HEAD yesterday and tested this via a 'boot kernel.GENERIC' at the loader prompt and it did the same as the previous loader (module_path was /boot/kernel.GENERIC;/boot/kernel;/boot/modules), so I think the new boot loader menus work fine in this regard. How exactly are you reproducing your broken case Doug? Do you have any settings in /boot/loader.conf or /boot/loader.conf.local? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 15:29:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3602106566C; Tue, 19 Jul 2011 15:29:47 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta31.charter.net (mta31.charter.net [216.33.127.82]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0928FC08; Tue, 19 Jul 2011 15:29:47 +0000 (UTC) Received: from imp09 ([10.20.200.9]) by mta31.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110719152946.OWPH3994.mta31.charter.net@imp09>; Tue, 19 Jul 2011 11:29:46 -0400 Received: from [192.168.1.125] ([75.135.75.204]) by imp09 with smtp.charter.net id 9rVl1h00K4QU3rf05rVlyG; Tue, 19 Jul 2011 11:29:46 -0400 X-Authority-Analysis: v=1.1 cv=1b2X7W/SifksZeClH/haT1SUt4udqxFGF00pZw2/jJk= c=1 sm=1 a=qGV6uSQ7kSsA:10 a=YzQM1Zd3q-sA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=pGLkceISAAAA:8 a=5Qp8lWOuAAAA:8 a=Rtm9G2dbfmXd8Fkf3IEA:9 a=t9f34lXaIuT1MRZ0JjoA:7 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=gzg3p7Doww8A:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E25A2F4.2030707@gamozo.org> Date: Tue, 19 Jul 2011 10:29:56 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Garrett Cooper References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> <4E24CD87.4010906@gamozo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:29:47 -0000 On 7/19/2011 7:31 AM, Garrett Cooper wrote: > On Tue, Jul 19, 2011 at 4:58 AM, Garrett Cooper wrote: >> On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk wrote: >>> On 7/18/2011 10:18 AM, Andriy Gapon wrote: >>>> on 18/07/2011 17:53 Brandon Falk said the following: >>>>> Hello, >>>>> >>>>> In recent branches (confirmed with 224119) builds compiled with clang >>>>> happen to >>>>> throw 'Unknown error: -512' in a lot of places, making the system >>>>> unusable. >>>>> (Untested on gcc compiled systems). Originally I thought the problem was >>>>> with >>>>> specific programs, then I narrowed it down to file I/O, and now I've >>>>> narrowed it >>>>> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues >>>>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: >>>>> -512' every >>>>> other time you run the program. Common issues, portsnap is affected, >>>>> making it >>>>> impossible to fetch/extract ports. As well as redirecting output in >>>>> shells eg >>>>> `echo 'hi'> test` fails every other try. You have the same issue with >>>>> text >>>>> editors like `edit` where it fails every other save. There are no issues >>>>> with >>>>> `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an >>>>> O_TRUNC error. >>>>> >>>>> Any tips? Otherwise I'll be looking into this today myself. >>>> Just a hint that you could try using DTrace syscall and fbt providers to >>>> see where >>>> in kernel (if in kernel) that -512 return value originates. >>>> >>> Update: >>> >>> I've traced more and more into the kernel, and currently I have found the >>> following trace: >>> >>>>>> ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) >>> (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) >>>>>> vn_truncate() (in sys/kern/vfs_vnops.c:636) >>>>>> kern_openat() (in sys/kern/vfs_syscalls.c:1043) >>>>>> kern_open() (in sys/kern/vfs_syscalls.c:1035) >>>>>> open() (in sys/kern/vfs_syscalls.c:1006) >>> ufs_setattr() returns with -1 (EPERM) >>> >>> I'll continue to try to find the exact problem. A quick workaround currently >>> would probably be to use a different filesystem other than ufs, but then >>> again, I have no clue if other filesystems have the same issue. >>> >>> Hopefully that trace will help anyone who wants to help out. >> What UFS options do you have defined in your kernel? > Also, what does mount say and have you tried running as root? > Thanks, > -Garrett > Garrett, I am running as root. No issues with the mounting. As for options, which do you want? -Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 15:31:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D693F1065670 for ; Tue, 19 Jul 2011 15:31:32 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta11.charter.net (mta11.charter.net [216.33.127.80]) by mx1.freebsd.org (Postfix) with ESMTP id 6189A8FC21 for ; Tue, 19 Jul 2011 15:31:32 +0000 (UTC) Received: from imp10 ([10.20.200.15]) by mta11.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110719153131.EJTM4091.mta11.charter.net@imp10>; Tue, 19 Jul 2011 11:31:31 -0400 Received: from [192.168.1.125] ([75.135.75.204]) by imp10 with smtp.charter.net id 9rXX1h0034QU3rf05rXXBd; Tue, 19 Jul 2011 11:31:31 -0400 X-Authority-Analysis: v=1.1 cv=G6Q69DB3AUoJKS2BpLRaz8MQ2NORN7h5HRzrJMPOhRw= c=1 sm=1 a=qGV6uSQ7kSsA:10 a=YzQM1Zd3q-sA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=HGqSmLHvpetimDycJuIA:9 a=oPcGth1CRej8k5BJBsgA:7 a=wPNLvfGTeEIA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E25A35E.6060308@gamozo.org> Date: Tue, 19 Jul 2011 10:31:42 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Dimitry Andric References: <4E2448D1.6020504@gamozo.org> <4E2558F7.6040202@FreeBSD.org> In-Reply-To: <4E2558F7.6040202@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:31:32 -0000 On 7/19/2011 5:14 AM, Dimitry Andric wrote: > On 2011-07-18 16:53, Brandon Falk wrote: >> In recent branches (confirmed with 224119) builds compiled with clang >> happen to throw 'Unknown error: -512' in a lot of places, making the >> system unusable. (Untested on gcc compiled systems). > > I have never seen this, neither with clang-compiled nor gcc-compiled > systems. Can you please verify if it still occurs if you build your > system with gcc? If you don't want (or can) rebuild the whole system, > you can try to rebuild just your kernel with gcc, and see if the > problems disappear. > > >> Originally I >> thought the problem was with specific programs, then I narrowed it down >> to file I/O, and now I've narrowed it down to open() with O_TRUNC. >> Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on >> open() it fails with that 'Unknown error: -512' every other time you run >> the program. Common issues, portsnap is affected, making it impossible >> to fetch/extract ports. As well as redirecting output in shells eg `echo >> 'hi'> test` fails every other try. You have the same issue with text >> editors like `edit` where it fails every other save. There are no issues >> with `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an >> O_TRUNC error. > > I have been running clang-compiled systems for a long time now, and have > never seen this. It works fine here, I cannot reproduce any of your > examples. > > Do you build with any special settings in make.conf or src.conf, > particularly modified CFLAGS or COPTFLAGS? What is your architecture, > i386 or amd64? Any other non-standard configuration or environment > settings? > Dimitry, I will try to build with gcc sometime today. I might as well try out a different filesystem too. I have no special settings besides CPUTYPE?=native, but there was someone with a similar error who did not specify a cpu type when building, so I know that isn't a problem. Arch is amd64, no other nonstandard configuration. -Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 17:25:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 927571065675; Tue, 19 Jul 2011 17:25:00 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4A48FC0A; Tue, 19 Jul 2011 17:24:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=r4BBFeN+uFRA8/dKCD4KHhhRNaIYiRCRqNA7BEYVp4c=; b=p5ScyJreiVXk5U7jZuoQAi1MgcEfoqAmOGvnDtBg2Jn7y+EktWbFcckbLe2pXUJ4fnBXqyIXaQvVfMNMEBB15tleqnQg6n5wbQ523Tb63No2BZ8/2hALr9+6/KEYAh2Q1x4/bqiUX9PtDZB1v5WnVy/Q1+zlnrIsb95wU9x5f4/ZXlQwWXi0Thi/P9smmaBYLXMnhRRvWkpvfjjdSEJU/MIz/NeBR4pLnVzI98ELowRiXRacsIrTxqH1LvxkmKU7EGNT/3VXjOUFjdH01UJYlOkacCLcXff5C1QnrSno0ZPpJ9DzkGBvfNhrJIQye8EGLeVCnPLOvVt7QaLP2K7oWg==; Received: from MacBook-Eygene-Ryabinkin.local (ppp91-77-162-156.pppoe.mtu-net.ru [91.77.162.156]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1QjE2U-000OfO-PD; Tue, 19 Jul 2011 21:24:58 +0400 Date: Tue, 19 Jul 2011 21:24:55 +0400 From: Eygene Ryabinkin To: Daniel Braniss Message-ID: <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NEaRsfQExFH3jWtg" Content-Disposition: inline In-Reply-To: Sender: rea@codelabs.ru Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 17:25:00 -0000 --NEaRsfQExFH3jWtg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Jul 19, 2011 at 10:40:11AM +0300, Daniel Braniss wrote: > > And that non-broadcast ethernet address is the MAC of your > > default router? > yes. Fine, that is more-or-less expected, since the network subsystem just routes 255.255.255.255 to the default gateway. The issue you're seeing were already seen before, http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html http://www.freebsd.org/cgi/query-pr.cgi?pr=3D72468 http://lists.freebsd.org/pipermail/freebsd-net/2007-January/012874.html [= 1] and bms@ told me that in this case the default gateway routing is the correct historical behaviour of FreeBSD. [1] I finally remembered that I had seen this issue too ;)) > > What's your routing table (netstat -rn) for the PXE-booted host? > > it's ok, same in both cases. it's picked up via DHCP, in the diskless > case by the boot/loader in the second via dhcpclient. Still, can you show both of them? > > You nailed it: you should send packets to the network's broadcast, > > not to the 0xffffffff. > >=20 > but I'm at the user/ip level!, have no way to set mac/ethernet address. I meant the IP's network broadcast and by 0xffffffff I meant 255.255.255.255. Please, look at the posted code. > still, the question is why it works in one case, and failes in the other. Yes, it is. But ip_output.c has the following code, {{{ if (rte->rt_flags & RTF_GATEWAY) dst =3D (struct sockaddr_in *)rte->rt_gateway; if (rte->rt_flags & RTF_HOST) isbroadcast =3D (rte->rt_flags & RTF_BROADCAST); else isbroadcast =3D in_broadcast(dst->sin_addr, ifp); }}} So, if the route that is selected is the gateway, then there will be no broadcast on the L2. At least in my understanding of the code. Thus, I am interested in the routing tables and route flags. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --NEaRsfQExFH3jWtg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iF4EAREIAAYFAk4lvecACgkQFq+eroFS7PtqOwEAkdzoSVbsOv1x01hTfYMQHmN5 sooNn8einiX32BR/PSEA/iJAOVvMn38joKNp8hCxLFUuzm34zc1XLGMSrlnh0B8U =zEhc -----END PGP SIGNATURE----- --NEaRsfQExFH3jWtg-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 18:56:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03AA1065673 for ; Tue, 19 Jul 2011 18:56:12 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B35C98FC26 for ; Tue, 19 Jul 2011 18:56:12 +0000 (UTC) Received: by iyb11 with SMTP id 11so5326632iyb.13 for ; Tue, 19 Jul 2011 11:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=VawMN0QVZw4qsq7C74Cl3xRkf3X5xcPb+QG9dBOm1b8=; b=eJZlP98mAXvZRkkhOJXjNdAmKUFpDCgmDn8uRXDi1Q0iQ4R66QrvPnLB574UEom77H UmmHLZ0zkj9Me+3XEGSrgnvKKRCVvaxo4p/0s90xXoJN1Qk+l4UuMp/MDiC3x8Yx8igF eHjNZ01GsrRbJ93i2qgm23Vbyohd+ScxaXXKk= MIME-Version: 1.0 Received: by 10.42.146.65 with SMTP id i1mr9670212icv.201.1311099939032; Tue, 19 Jul 2011 11:25:39 -0700 (PDT) Received: by 10.42.213.130 with HTTP; Tue, 19 Jul 2011 11:25:39 -0700 (PDT) Date: Tue, 19 Jul 2011 14:25:39 -0400 Message-ID: From: Zaphod Beeblebrox To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: setkey and -ctx X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:56:13 -0000 I have a Cisco ASA which expects a different tunnel for each IP that I'm sending traffic to (ie: it expects a different tunnel per firewall rule over there). It looks like I should have each SA in a different domain on my side to do this --- so it looks like I should be using the "-ctx" flag to setkey (or in /etc/ipsec.conf). But setkey appears to reject this... Is this unimplemented? Am I missing something? From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 02:09:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31DB1106566C; Wed, 20 Jul 2011 02:09:25 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pz0-f49.google.com (mail-pz0-f49.google.com [209.85.210.49]) by mx1.freebsd.org (Postfix) with ESMTP id 0662A8FC12; Wed, 20 Jul 2011 02:09:24 +0000 (UTC) Received: by pzk33 with SMTP id 33so7340544pzk.8 for ; Tue, 19 Jul 2011 19:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JCJQzPeto3MvLVj/X/mTMTk2hls4fFeaE69gfSjI75g=; b=rAEAYPTxZ7+ExxG2RqOrv33ibD5yY5vsntUo8FSoNquv8JOKtka6q6z2wnsylpw/nf ZgA3dq5mDoMYBwG8Haz4Iz0yqOpSOue4dkM6LAkeCj6Jw6o/9MSh7mcstSNJO4K5ryI2 t37o43T/pESiEkuHIEVBJs0IJ9RrWXfm11Bys= MIME-Version: 1.0 Received: by 10.143.97.26 with SMTP id z26mr3707178wfl.81.1311127764402; Tue, 19 Jul 2011 19:09:24 -0700 (PDT) Received: by 10.142.172.16 with HTTP; Tue, 19 Jul 2011 19:09:24 -0700 (PDT) In-Reply-To: <55627D64-E412-4D04-AA17-3D912EEE6589@bsdimp.com> References: <4E11ECE2.9050402@freebsd.org> <55627D64-E412-4D04-AA17-3D912EEE6589@bsdimp.com> Date: Tue, 19 Jul 2011 22:09:24 -0400 Message-ID: From: grarpamp To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 20 Jul 2011 02:37:29 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Jails: Setting different times in jails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 02:09:25 -0000 > Why on earth would you want this? Hi. Since your quote of my note was not to the original, I'll repost it here. Kurt Lidl also posted useful situations on these lists. Also, being able to have time tick backwards in jails could be interesting fuzzing too :-) Enjoy. Would be nice to be able to set different times in different jails. All jails would tick in step with the system. But each jail could have it's birthtime set specifically via jail(8), jail(2), etc. Either by specification of a specific time, or an offset from the current true system time. ie: jail(8): -t [-|+] Child jails would offset from their parent, not the system. Internally, gettimeofday, filesystem timestamps, and any other userland interfaces would be hooked and adjusted by referencing a table of jail ID's and their offsets. Similar to how setting TZ or /etc/localtime effects a timezone offset. But transparent and undetectable to the jail unless set as visible by the invoker. Useful for creating alternate histories, testing time dependant protocols and applications, forensics, pen testing, etc. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 06:16:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9869C106564A for ; Wed, 20 Jul 2011 06:16:07 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from mta11.charter.net (mta11.charter.net [216.33.127.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0E38FC0A for ; Wed, 20 Jul 2011 06:16:06 +0000 (UTC) Received: from imp09 ([10.20.200.9]) by mta11.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20110720061606.VYLI4091.mta11.charter.net@imp09> for ; Wed, 20 Jul 2011 02:16:06 -0400 Received: from [192.168.1.12] ([75.135.75.204]) by imp09 with smtp.charter.net id A6G51h0034QU3rf056G5Bj; Wed, 20 Jul 2011 02:16:06 -0400 X-Authority-Analysis: v=1.1 cv=1b2X7W/SifksZeClH/haT1SUt4udqxFGF00pZw2/jJk= c=1 sm=1 a=7Da5kHvgTEoA:10 a=YzQM1Zd3q-sA:10 a=EZ1XIdwCItEA:10 a=8nJEP1OIZ-IA:10 a=HEs2YkztZRVyeANDsLw8Eg==:17 a=6I5d2MoRAAAA:8 a=OmwH20eVnGfbHJhRDBcA:9 a=sbY4zcnBeYubQurredgA:7 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=HEs2YkztZRVyeANDsLw8Eg==:117 Message-ID: <4E2672A5.4000401@gamozo.org> Date: Wed, 20 Jul 2011 01:16:05 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4E2448D1.6020504@gamozo.org> <4E2558F7.6040202@FreeBSD.org> <4E25A35E.6060308@gamozo.org> In-Reply-To: <4E25A35E.6060308@gamozo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Issue with 'Unknown Error: -512' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 06:16:07 -0000 On 7/19/2011 10:31 AM, Brandon Falk wrote: > On 7/19/2011 5:14 AM, Dimitry Andric wrote: >> On 2011-07-18 16:53, Brandon Falk wrote: >>> In recent branches (confirmed with 224119) builds compiled with clang >>> happen to throw 'Unknown error: -512' in a lot of places, making the >>> system unusable. (Untested on gcc compiled systems). >> >> I have never seen this, neither with clang-compiled nor gcc-compiled >> systems. Can you please verify if it still occurs if you build your >> system with gcc? If you don't want (or can) rebuild the whole system, >> you can try to rebuild just your kernel with gcc, and see if the >> problems disappear. >> >> >>> Originally I >>> thought the problem was with specific programs, then I narrowed it down >>> to file I/O, and now I've narrowed it down to open() with O_TRUNC. >>> Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on >>> open() it fails with that 'Unknown error: -512' every other time you >>> run >>> the program. Common issues, portsnap is affected, making it impossible >>> to fetch/extract ports. As well as redirecting output in shells eg >>> `echo >>> 'hi'> test` fails every other try. You have the same issue with text >>> editors like `edit` where it fails every other save. There are no >>> issues >>> with `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an >>> O_TRUNC error. >> >> I have been running clang-compiled systems for a long time now, and have >> never seen this. It works fine here, I cannot reproduce any of your >> examples. >> >> Do you build with any special settings in make.conf or src.conf, >> particularly modified CFLAGS or COPTFLAGS? What is your architecture, >> i386 or amd64? Any other non-standard configuration or environment >> settings? >> > > Dimitry, > > I will try to build with gcc sometime today. I might as well try out a > different filesystem too. > > I have no special settings besides CPUTYPE?=native, but there was > someone with a similar error who did not specify a cpu type when > building, so I know that isn't a problem. Arch is amd64, no other > nonstandard configuration. > > -Brandon Falk > _______________________________________________ > 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 just did a clang build with CPUTYPE?=native and the unknown error issue has seemed to calm down a large amount. I still occasionally get it, but given multiple attempts at say compiling software, it will move on and all will be well. It is for sure not happening every other O_TRUNC, but it is still happening. Depending on system configuration, this still could cause some major issues for people. I'll keep my eye out and see what changes and try to figure out how to duplicate the issue on the new rev. Rev: 224221 Built with clang and CPUTYPE?=native -Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 09:34:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837C2106566C; Wed, 20 Jul 2011 09:34:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id DB6F18FC13; Wed, 20 Jul 2011 09:34:40 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QjTAs-000IjW-Ba; Wed, 20 Jul 2011 12:34:38 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Eygene Ryabinkin In-reply-to: <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> Comments: In-reply-to Eygene Ryabinkin message dated "Tue, 19 Jul 2011 21:24:55 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jul 2011 12:34:38 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 09:34:41 -0000 > Tue, Jul 19, 2011 at 10:40:11AM +0300, Daniel Braniss wrote: > > > And that non-broadcast ethernet address is the MAC of your > > > default router? > > yes. with dest_addr = INADDR_BROADCAST on the non diskless: 09:44:29.850576 00:0d:b9:00:72:a8 (oui Unknown) > 00:04:38:a0:c6:07 (oui Unknown), ethertype IPv4 (0x0800), length 61: wrap-1.cs.huji.ac.il.53016 > 255.255.255.255.12345: UDP, length 19 and 00:04:38:a0:c6:07 belongs to the router: wrap-1# arp -a | grep 00:04:38:a0:c6:07 router-80.cs.huji.ac.il (132.65.80.1) at 00:04:38:a0:c6:07 on sis0 expires in 1200 seconds [ethernet] > > Fine, that is more-or-less expected, since the network subsystem > just routes 255.255.255.255 to the default gateway. The issue > you're seeing were already seen before, > http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D72468 > http://lists.freebsd.org/pipermail/freebsd-net/2007-January/012874.html [= > 1] the more I read the more confused i get :-) > and bms@ told me that in this case the default gateway routing is the > correct historical behaviour of FreeBSD. > > [1] I finally remembered that I had seen this issue too ;)) > > > > What's your routing table (netstat -rn) for the PXE-booted host? > > > > it's ok, same in both cases. it's picked up via DHCP, in the diskless > > case by the boot/loader in the second via dhcpclient. > > Still, can you show both of them? from the diskless: els-01# ifconfig vr0: flags=8843 metric 0 mtu 1500 options=8280b ether 00:0d:b9:22:57:18 inet 132.65.91.1 netmask 0xfffff000 broadcast 132.65.95.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 els-01# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 132.65.80.1 UG 0 16606 vr0 127.0.0.1 link#4 UH 0 36 lo0 132.65.80.0/20 link#1 U 0 86612 vr0 132.65.91.1 link#1 UHS 0 12 lo0 from the non-diskless: wrap-1# ifconfig sis0: flags=8943 metric 0 mtu 1500 options=83808 ether 00:0d:b9:00:72:a8 inet 132.65.80.181 netmask 0xfffff000 broadcast 132.65.95.255 media: Ethernet autoselect (100baseTX ) status: active sis1: flags=8802 metric 0 mtu 1500 options=83808 ether 00:0d:b9:00:72:a9 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 wrap-1# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 132.65.80.1 UGS 0 16936 sis0 127.0.0.1 link#4 UH 0 76 lo0 132.65.80.0/20 link#1 U 0 67433 sis0 132.65.80.181 link#1 UHS 0 0 lo0 > > > > You nailed it: you should send packets to the network's broadcast, > > > not to the 0xffffffff. > > >=20 > > but I'm at the user/ip level!, have no way to set mac/ethernet address. > > I meant the IP's network broadcast and by 0xffffffff I meant > 255.255.255.255. Please, look at the posted code. > > > still, the question is why it works in one case, and failes in the other. > > Yes, it is. But ip_output.c has the following code, > {{{ > if (rte->rt_flags & RTF_GATEWAY) > dst =3D (struct sockaddr_in *)rte->rt_gateway; > if (rte->rt_flags & RTF_HOST) > isbroadcast =3D (rte->rt_flags & RTF_BROADCAST); > else > isbroadcast =3D in_broadcast(dst->sin_addr, ifp); > }}} > > So, if the route that is selected is the gateway, then there will be > no broadcast on the L2. At least in my understanding of the code. > Thus, I am interested in the routing tables and route flags. so it boils down to a problem in selecting the route? cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 11:33:53 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83C6F1065670 for ; Wed, 20 Jul 2011 11:33:53 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E22588FC08 for ; Wed, 20 Jul 2011 11:33:52 +0000 (UTC) Received: from park.js.berklix.net (p5DCBEA02.dip.t-dialin.net [93.203.234.2]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6KBXeMh076085; Wed, 20 Jul 2011 11:33:41 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6KBXgA4027653; Wed, 20 Jul 2011 13:33:42 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6KBXQTr006861; Wed, 20 Jul 2011 11:33:31 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107201133.p6KBXQTr006861@fire.js.berklix.net> To: Dan Nelson From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sat, 16 Jul 2011 21:02:21 CDT." <20110717020220.GM6611@dan.emsphone.com> Date: Wed, 20 Jul 2011 13:33:26 +0200 Sender: jhs@berklix.com Cc: "Julian H. Stacey" , hackers@freebsd.org Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 11:33:53 -0000 Hi Dan cc list Dan Nelson wrote: > In the last episode (Jul 17), Julian H. Stacey said: > > Hi all, > > ENVIRONMENT: > > Standard > > gcc version 4.2.1 20070719 [FreeBSD] > > that comes with > > FreeBSD 7.4-RELEASE > > on my 686 host with > > CFLAGS += -march=i586 > > in > > /etc/make.conf > > used with > > cd /usr/src/bin/who ; make clean ; make cleandir ; make clean ; make > > reports > > Warning: Object directory not changed from original /usr/src/usr.bin/who > > cc -O2 -fno-strict-aliasing -march=i586 -c /usr/src/usr.bin/who/who.c > > cc -O2 -fno-strict-aliasing -march=i586 -o who who.o > > looking with > > file who > > reports > > who: ELF 32-bit LSB executable, Intel 80386, version 1 > > (FreeBSD), for FreeBSD 7.4, dynamically linked (uses shared > > libs), FreeBSD-style, not stripped > > > > Problem: > > Use it from a 586 7.4-RELEASE host (AMD+NFS) > > file /host/sony/usr/src/usr.bin/who/who > > /host/sony/usr/src/usr.bin/who/who: ELF 32-bit LSB executable, > > Intel 80386, version 1 (FreeBSD), for FreeBSD 7.4, dynamically > > linked (uses shared libs), FreeBSD-style, not stripped > > /host/sony/usr/src/usr.bin/who/who > > fails with > > Illegal instruction > > Were the crt*.o files on your fast machine also compiled with -march=i586 ? No. I hadn't thought of that, Thanks. Trying below. > If you run gdb on the core file, can you determine what function the bad > instruction is in? host=686: cc -O2 -fno-strict-aliasing -march=i586 -g -c who.c cc -O2 -fno-strict-aliasing -march=i586 -g -o who who.o mv who /host/lapn/tmp/who 586: /tmp/who Illegal instruction gdb /tmp/who run Starting program: /tmp/who Program received signal SIGILL, Illegal instruction. 0x08048a5a in _start1 () (gdb) backtrace #0 0x08048a5a in _start1 () #1 0x08048a18 in _start () #2 0x2804f960 in dlclose () from /libexec/ld-elf.so.1 #3 0x00000001 in ?? () 686: change make.conf to CFLAGS += -march=i586 -g Search for crt in Makefile: contrib/gccMakefile.in make clean not supported gnu/lib/csu/Makefile lib/csu/i386-elf/Makefile cd /usr/src ; make clean cd lib/csu/i386-elf ; make install install -o root -g wheel -m 444 crti.o crtn.o gcrt1.o \ crt1.o Scrt1.o /usr/lib cd /usr/lib ; ls -l crti.o crtn.o gcrt1.o crt1.o Scrt1.o -r--r--r-- 1 root wheel 5032 Jul 20 11:42 Scrt1.o -r--r--r-- 1 root wheel 4900 Jul 20 11:42 crt1.o -r--r--r-- 1 root wheel 1680 Jul 20 11:42 crti.o -r--r--r-- 1 root wheel 1636 Jul 20 11:42 crtn.o -r--r--r-- 1 root wheel 5117 Jul 20 11:42 gcrt1.o cd /usr/src/usr.bin/who ; make mv who /host/lapn/tmp/who2 586 /tmp/who2 # Runs OK 686 make.conf CFLAGS += -march=i686 -g cd /usr/src/lib/csu/i386-elf make clean ; make ; make install make.conf CFLAGS += -march=i586 -g cd /usr/src/usr.bin/who ; make clean ; make ; mv who /host/lapn/tmp/who3 586 /tmp/who3 gdb /tmp/who3 (gdb) run Starting program: /tmp/who3 Program received signal SIGILL, Illegal instruction. 0x08048a5a in _start1 (cleanup=0x2804f960 , argc=1, argv=0xbfbfe37c) at /usr/src/lib/csu/i386-elf/crt1_c.c:75 75 __progname = s + 1; (gdb) bt #0 0x08048a5a in _start1 (cleanup=0x2804f960 , argc=1, argv=0xbfbfe37c) at /usr/src/lib/csu/i386-elf/crt1_c.c:75 #1 0x08048a18 in _start () at /usr/src/lib/csu/i386-elf/crt1_s.S:42 #2 0x2804f960 in dlclose () from /libexec/ld-elf.so.1 #3 0x00000001 in ?? () 686 make.conf CFLAGS += -march=i686 -g cd /usr/src/gnu/lib/csu ; make clean ; make ; make install cd /usr/src/usr.bin/who ; make clean ; make mv who /host/lapn/tmp/who4 586 /tmp/who4 Illegal instruction gdb /tmp/who4 run Starting program: /tmp/who4 Program received signal SIGILL, Illegal instruction. 0x08048a5a in _start1 (cleanup=0x2804f960 , argc=1, argv=0xbfbfe37c) at /usr/src/lib/csu/i386-elf/crt1_c.c:75 75 __progname = s + 1; 686 cc -O2 -fno-strict-aliasing -march=i686 -g -v -o who who.o Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] /usr/bin/ld --eh-frame-hdr -V -dynamic-linker \ /libexec/ld-elf.so.1 -o who /usr/lib/crt1.o /usr/lib/crti.o \ /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib who.o -lgcc \ --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed \ -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o GNU ld version 2.15 [FreeBSD] 2004-05-23 Supported emulations: elf_i386_fbsd What should FreeBSD do ? Add a comment to man gcc ... that -march=i586 is not enough, & feed the comment back to gcc project & see how they want to handle it ? Have seperate FreeBSD subdirs for 3,4,5,6 /usr/lib/crt1.o ? Question: with more complex programs than who, might there be sensitivity to other libs too ? PS I recall there's a FreeBSD tool chain group ? I can't see a list name in http://lists.freebsd.org/mailman/listinfo There is freebsd-i386@ Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 11:51:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFE621065670; Wed, 20 Jul 2011 11:51:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B6E558FC1F; Wed, 20 Jul 2011 11:51:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 21EFA46B1A; Wed, 20 Jul 2011 07:51:29 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B17828A02E; Wed, 20 Jul 2011 07:51:28 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 20 Jul 2011 07:48:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107201133.p6KBXQTr006861@fire.js.berklix.net> In-Reply-To: <201107201133.p6KBXQTr006861@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107200748.05786.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 20 Jul 2011 07:51:28 -0400 (EDT) Cc: "Julian H. Stacey" , hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 11:51:31 -0000 On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > What should FreeBSD do ? > Add a comment to man gcc ... that -march=i586 is not > enough, & feed the comment back to gcc project & see how > they want to handle it ? No, this is not a GCC bug. If you want to use a single build machine that will compile programs for other machines on a network to use, it must use the lowest common denominator for its CPUTYPE in /etc/make.conf. The out-of-the-box crt files from a FreeBSD install will work fine on a 486 and above, so can only get yourself into this quandry by building a new world with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates this rule. You can fix your machine by fixing the CPUTYPE in your build machine and building and installing a new world (do use NO_CLEAN=yes for your build, do a full build). You will also want to rebuild any other binaries on this machine that you share with other machines. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 11:51:30 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFE621065670; Wed, 20 Jul 2011 11:51:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B6E558FC1F; Wed, 20 Jul 2011 11:51:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 21EFA46B1A; Wed, 20 Jul 2011 07:51:29 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B17828A02E; Wed, 20 Jul 2011 07:51:28 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 20 Jul 2011 07:48:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107201133.p6KBXQTr006861@fire.js.berklix.net> In-Reply-To: <201107201133.p6KBXQTr006861@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107200748.05786.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 20 Jul 2011 07:51:28 -0400 (EDT) Cc: "Julian H. Stacey" , hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 11:51:31 -0000 On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > What should FreeBSD do ? > Add a comment to man gcc ... that -march=i586 is not > enough, & feed the comment back to gcc project & see how > they want to handle it ? No, this is not a GCC bug. If you want to use a single build machine that will compile programs for other machines on a network to use, it must use the lowest common denominator for its CPUTYPE in /etc/make.conf. The out-of-the-box crt files from a FreeBSD install will work fine on a 486 and above, so can only get yourself into this quandry by building a new world with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates this rule. You can fix your machine by fixing the CPUTYPE in your build machine and building and installing a new world (do use NO_CLEAN=yes for your build, do a full build). You will also want to rebuild any other binaries on this machine that you share with other machines. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 12:35:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDED6106564A; Wed, 20 Jul 2011 12:35:20 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 49A878FC16; Wed, 20 Jul 2011 12:35:19 +0000 (UTC) Received: from park.js.berklix.net (p5DCBEA02.dip.t-dialin.net [93.203.234.2]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6KCZABQ076567; Wed, 20 Jul 2011 12:35:10 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6KCZ76A028246; Wed, 20 Jul 2011 14:35:07 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6KCYvmT007475; Wed, 20 Jul 2011 12:35:02 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107201235.p6KCYvmT007475@fire.js.berklix.net> To: John Baldwin From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 20 Jul 2011 07:48:05 EDT." <201107200748.05786.jhb@freebsd.org> Date: Wed, 20 Jul 2011 14:34:57 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:35:21 -0000 Hi, Reference: > From: John Baldwin > Date: Wed, 20 Jul 2011 07:48:05 -0400 > Message-id: <201107200748.05786.jhb@freebsd.org> John Baldwin wrote: > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > What should FreeBSD do ? > > Add a comment to man gcc ... that -march=i586 is not > > enough, & feed the comment back to gcc project & see how > > they want to handle it ? > > No, this is not a GCC bug. If you want to use a single build machine that > will compile programs for other machines on a network to use, it must use the > lowest common denominator for its CPUTYPE in /etc/make.conf. > > The out-of-the-box crt files from a FreeBSD install will work fine on a 486 > and above, so can only get yourself into this quandry by building a new world > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates > this rule. > > You can fix your machine by fixing the CPUTYPE in your build machine and > building and installing a new world (do use NO_CLEAN=yes for your build, do a > full build). You will also want to rebuild any other binaries on this machine > that you share with other machines. > > -- > John Baldwin Hi John, Yes I realise all that now thanks. The point now is man gcc is misleading/ incomplete: "-march=cpu-type Generate instructions for the machine type cpu-type." Those instructions will not make a program that runs on a lesser CPU type without alternate crt for lesse CPU. CFLAGS in make.conf is fine for single developer/ host debugging, but is not appropriate for multi user multi make builds os src/ ports/ other Its seems just that gcc -march fails to select alternate crt. One gross ugly solution needing root would be to create chroots, but Too ugly. I suggest gcc via -march should also be used as a selection for sub dirs for crt ? & we should co-operate with gcc project on that, *BSD & *linux must all face same phenomena so lets not develop a non standard solution. Even if we're too lazy to do anything more, we should at least document it as a patch to man gcc. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 12:35:20 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDED6106564A; Wed, 20 Jul 2011 12:35:20 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 49A878FC16; Wed, 20 Jul 2011 12:35:19 +0000 (UTC) Received: from park.js.berklix.net (p5DCBEA02.dip.t-dialin.net [93.203.234.2]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6KCZABQ076567; Wed, 20 Jul 2011 12:35:10 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6KCZ76A028246; Wed, 20 Jul 2011 14:35:07 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6KCYvmT007475; Wed, 20 Jul 2011 12:35:02 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107201235.p6KCYvmT007475@fire.js.berklix.net> To: John Baldwin From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 20 Jul 2011 07:48:05 EDT." <201107200748.05786.jhb@freebsd.org> Date: Wed, 20 Jul 2011 14:34:57 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:35:21 -0000 Hi, Reference: > From: John Baldwin > Date: Wed, 20 Jul 2011 07:48:05 -0400 > Message-id: <201107200748.05786.jhb@freebsd.org> John Baldwin wrote: > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > What should FreeBSD do ? > > Add a comment to man gcc ... that -march=i586 is not > > enough, & feed the comment back to gcc project & see how > > they want to handle it ? > > No, this is not a GCC bug. If you want to use a single build machine that > will compile programs for other machines on a network to use, it must use the > lowest common denominator for its CPUTYPE in /etc/make.conf. > > The out-of-the-box crt files from a FreeBSD install will work fine on a 486 > and above, so can only get yourself into this quandry by building a new world > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates > this rule. > > You can fix your machine by fixing the CPUTYPE in your build machine and > building and installing a new world (do use NO_CLEAN=yes for your build, do a > full build). You will also want to rebuild any other binaries on this machine > that you share with other machines. > > -- > John Baldwin Hi John, Yes I realise all that now thanks. The point now is man gcc is misleading/ incomplete: "-march=cpu-type Generate instructions for the machine type cpu-type." Those instructions will not make a program that runs on a lesser CPU type without alternate crt for lesse CPU. CFLAGS in make.conf is fine for single developer/ host debugging, but is not appropriate for multi user multi make builds os src/ ports/ other Its seems just that gcc -march fails to select alternate crt. One gross ugly solution needing root would be to create chroots, but Too ugly. I suggest gcc via -march should also be used as a selection for sub dirs for crt ? & we should co-operate with gcc project on that, *BSD & *linux must all face same phenomena so lets not develop a non standard solution. Even if we're too lazy to do anything more, we should at least document it as a patch to man gcc. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 12:39:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C2D8106564A; Wed, 20 Jul 2011 12:39:07 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 2187F8FC0C; Wed, 20 Jul 2011 12:39:06 +0000 (UTC) Received: from park.js.berklix.net (p5DCBEA02.dip.t-dialin.net [93.203.234.2]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6KCd19C076595; Wed, 20 Jul 2011 12:39:02 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6KCcwAk028271; Wed, 20 Jul 2011 14:38:58 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6KCcmWh007548; Wed, 20 Jul 2011 12:38:53 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107201238.p6KCcmWh007548@fire.js.berklix.net> From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 20 Jul 2011 14:34:57 +0200." Date: Wed, 20 Jul 2011 14:38:48 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:39:07 -0000 > Even if we're too lazy to do anything more, we should at least > document it as a patch to man gcc. PS Please no one take offense at word "Lazy" I'm as lazy as the next man. A good engineer can be a lazy engineer, - if he works to max efficiency :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 12:39:07 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C2D8106564A; Wed, 20 Jul 2011 12:39:07 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 2187F8FC0C; Wed, 20 Jul 2011 12:39:06 +0000 (UTC) Received: from park.js.berklix.net (p5DCBEA02.dip.t-dialin.net [93.203.234.2]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6KCd19C076595; Wed, 20 Jul 2011 12:39:02 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6KCcwAk028271; Wed, 20 Jul 2011 14:38:58 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6KCcmWh007548; Wed, 20 Jul 2011 12:38:53 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107201238.p6KCcmWh007548@fire.js.berklix.net> From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 20 Jul 2011 14:34:57 +0200." Date: Wed, 20 Jul 2011 14:38:48 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:39:07 -0000 > Even if we're too lazy to do anything more, we should at least > document it as a patch to man gcc. PS Please no one take offense at word "Lazy" I'm as lazy as the next man. A good engineer can be a lazy engineer, - if he works to max efficiency :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 12:45:06 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86EF11065670; Wed, 20 Jul 2011 12:45:06 +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 81D1F8FC0A; Wed, 20 Jul 2011 12:45:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA00412; Wed, 20 Jul 2011 15:44:59 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E26CDCB.2070802@FreeBSD.org> Date: Wed, 20 Jul 2011 15:44:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201107200748.05786.jhb@freebsd.org> <201107201235.p6KCYvmT007475@fire.js.berklix.net> In-Reply-To: <201107201235.p6KCYvmT007475@fire.js.berklix.net> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Dan Nelson , John Baldwin Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:45:06 -0000 on 20/07/2011 15:34 Julian H. Stacey said the following: > Even if we're too lazy to do anything more, we should at least > document it as a patch to man gcc. Talk to GCC people now? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 15:15:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 221331065719; Wed, 20 Jul 2011 15:15:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E62AF8FC14; Wed, 20 Jul 2011 15:15:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 868EA46B45; Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2562C8A02E; Wed, 20 Jul 2011 11:15:00 -0400 (EDT) From: John Baldwin To: "Julian H. Stacey" Date: Wed, 20 Jul 2011 11:13:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107201235.p6KCYvmT007475@fire.js.berklix.net> In-Reply-To: <201107201235.p6KCYvmT007475@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107201113.52085.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:15:01 -0000 On Wednesday, July 20, 2011 8:34:57 am Julian H. Stacey wrote: > Hi, > Reference: > > From: John Baldwin > > Date: Wed, 20 Jul 2011 07:48:05 -0400 > > Message-id: <201107200748.05786.jhb@freebsd.org> > > John Baldwin wrote: > > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > > What should FreeBSD do ? > > > Add a comment to man gcc ... that -march=i586 is not > > > enough, & feed the comment back to gcc project & see how > > > they want to handle it ? > > > > No, this is not a GCC bug. If you want to use a single build machine that > > will compile programs for other machines on a network to use, it must use the > > lowest common denominator for its CPUTYPE in /etc/make.conf. > > > > The out-of-the-box crt files from a FreeBSD install will work fine on a 486 > > and above, so can only get yourself into this quandry by building a new world > > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates > > this rule. > > > > You can fix your machine by fixing the CPUTYPE in your build machine and > > building and installing a new world (do use NO_CLEAN=yes for your build, do a > > full build). You will also want to rebuild any other binaries on this machine > > that you share with other machines. > > > > -- > > John Baldwin > > > Hi John, > Yes I realise all that now thanks. > The point now is man gcc is misleading/ incomplete: > "-march=cpu-type > Generate instructions for the machine type cpu-type." > Those instructions will not make a program that runs on a lesser CPU type > without alternate crt for lesse CPU. > > CFLAGS in make.conf is fine for single developer/ host debugging, > but is not appropriate for multi user multi make builds os src/ ports/ other > > Its seems just that gcc -march fails to select alternate crt. > > One gross ugly solution needing root would be to create chroots, > but Too ugly. > > I suggest gcc via -march should also be used as a selection for sub > dirs for crt ? & we should co-operate with gcc project on that, > *BSD & *linux must all face same phenomena so lets not develop > a non standard solution. I think this is a harder problem than you expect. It is not just the crt files that matter, but every library. You would need CPU-specific versions of every static library on the build system, and possibly you would want to do this for all shared libraries too. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 15:15:01 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 221331065719; Wed, 20 Jul 2011 15:15:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E62AF8FC14; Wed, 20 Jul 2011 15:15:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 868EA46B45; Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2562C8A02E; Wed, 20 Jul 2011 11:15:00 -0400 (EDT) From: John Baldwin To: "Julian H. Stacey" Date: Wed, 20 Jul 2011 11:13:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107201235.p6KCYvmT007475@fire.js.berklix.net> In-Reply-To: <201107201235.p6KCYvmT007475@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107201113.52085.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:15:01 -0000 On Wednesday, July 20, 2011 8:34:57 am Julian H. Stacey wrote: > Hi, > Reference: > > From: John Baldwin > > Date: Wed, 20 Jul 2011 07:48:05 -0400 > > Message-id: <201107200748.05786.jhb@freebsd.org> > > John Baldwin wrote: > > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > > What should FreeBSD do ? > > > Add a comment to man gcc ... that -march=i586 is not > > > enough, & feed the comment back to gcc project & see how > > > they want to handle it ? > > > > No, this is not a GCC bug. If you want to use a single build machine that > > will compile programs for other machines on a network to use, it must use the > > lowest common denominator for its CPUTYPE in /etc/make.conf. > > > > The out-of-the-box crt files from a FreeBSD install will work fine on a 486 > > and above, so can only get yourself into this quandry by building a new world > > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates > > this rule. > > > > You can fix your machine by fixing the CPUTYPE in your build machine and > > building and installing a new world (do use NO_CLEAN=yes for your build, do a > > full build). You will also want to rebuild any other binaries on this machine > > that you share with other machines. > > > > -- > > John Baldwin > > > Hi John, > Yes I realise all that now thanks. > The point now is man gcc is misleading/ incomplete: > "-march=cpu-type > Generate instructions for the machine type cpu-type." > Those instructions will not make a program that runs on a lesser CPU type > without alternate crt for lesse CPU. > > CFLAGS in make.conf is fine for single developer/ host debugging, > but is not appropriate for multi user multi make builds os src/ ports/ other > > Its seems just that gcc -march fails to select alternate crt. > > One gross ugly solution needing root would be to create chroots, > but Too ugly. > > I suggest gcc via -march should also be used as a selection for sub > dirs for crt ? & we should co-operate with gcc project on that, > *BSD & *linux must all face same phenomena so lets not develop > a non standard solution. I think this is a harder problem than you expect. It is not just the crt files that matter, but every library. You would need CPU-specific versions of every static library on the build system, and possibly you would want to do this for all shared libraries too. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 18:05:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8193A1065672; Wed, 20 Jul 2011 18:05:15 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 014BF8FC0A; Wed, 20 Jul 2011 18:05:14 +0000 (UTC) Received: from park.js.berklix.net (p5DCBEA02.dip.t-dialin.net [93.203.234.2]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6KI52Jn078739; Wed, 20 Jul 2011 18:05:03 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6KI52Qu030411; Wed, 20 Jul 2011 20:05:03 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6KI4qss011543; Wed, 20 Jul 2011 18:04:57 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107201804.p6KI4qss011543@fire.js.berklix.net> To: John Baldwin From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 20 Jul 2011 11:13:51 EDT." <201107201113.52085.jhb@freebsd.org> Date: Wed, 20 Jul 2011 20:04:52 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, Dan Nelson , Andriy Gapon Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 18:05:15 -0000 Hi John & all, > On Wednesday, July 20, 2011 8:34:57 am Julian H. Stacey wrote: > > Hi, > > Reference: > > > From: John Baldwin > > > Date: Wed, 20 Jul 2011 07:48:05 -0400 > > > Message-id: <201107200748.05786.jhb@freebsd.org> > > > > John Baldwin wrote: > > > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > > > What should FreeBSD do ? > > > > Add a comment to man gcc ... that -march=i586 is not > > > > enough, & feed the comment back to gcc project & see how > > > > they want to handle it ? > > > > > > No, this is not a GCC bug. If you want to use a single build machine that > > > will compile programs for other machines on a network to use, it must use the > > > lowest common denominator for its CPUTYPE in /etc/make.conf. > > > > > > The out-of-the-box crt files from a FreeBSD install will work fine on a 486 > > > and above, so can only get yourself into this quandry by building a new world > > > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates > > > this rule. > > > > > > You can fix your machine by fixing the CPUTYPE in your build machine and > > > building and installing a new world (do use NO_CLEAN=yes for your build, do a > > > full build). You will also want to rebuild any other binaries on this machine > > > that you share with other machines. > > > > > > -- > > > John Baldwin > > > > > > Hi John, > > Yes I realise all that now thanks. > > The point now is man gcc is misleading/ incomplete: > > "-march=cpu-type > > Generate instructions for the machine type cpu-type." > > Those instructions will not make a program that runs on a lesser CPU type > > without alternate crt for lesse CPU. > > > > CFLAGS in make.conf is fine for single developer/ host debugging, > > but is not appropriate for multi user multi make builds os src/ ports/ other > > > > Its seems just that gcc -march fails to select alternate crt. > > > > One gross ugly solution needing root would be to create chroots, > > but Too ugly. > > > > I suggest gcc via -march should also be used as a selection for sub > > dirs for crt ? & we should co-operate with gcc project on that, > > *BSD & *linux must all face same phenomena so lets not develop > > a non standard solution. > > I think this is a harder problem than you expect. Yes, Needs to be thought through, that's why I posted 13:33:26 +0200 : > > Question: with more complex programs than who, might there > > be sensitivity to other libs too ? Per Andriy's : > Talk to GCC people now? I'm not clear what's best, but yes, when its clear, then talk to gcc people. > It is not just the crt files > that matter, but every library. You would need CPU-specific versions of every > static library on the build system, Would be preferable. Though as we default to link dynamic, not as essential as crt.o . We could also have some ifdef to avoid by default generating for all of [3-6]86 that would save space & time, If the directory was not filled, a user of gcc --march=i586 would then fail to link from /usr/lib/i586/ & could receive a good error, instead of a 686 crt.o with no error. > and possibly you would want to do this for > all shared libraries too. I guess we could skip those, Presuming a target system should have a matched set for the right CPU & release etc. I'm not sure about the recent plethora of lib stuff /lib Seems to be all .so so I guess not affected. /libexec ld-elf.so.1 ld-elf32.so.1 # no man ld-elf /usr/lib This is where I'd suggest sub dirs of [3-6]86 with default machine native either in top dir or perhaps a native/ sub dir, or sym linked whatever gcc & out & other projects find best ? /usr/lib32 ... Sigh ! same as above ? .. /usr/libdata /ldscripts & /lint ? /usr/libexec Presumably can ignore this as real programs. & ignore inderminent localy variant dirs shown by cd /usr/local ; find . -type d -name \*lib\* -print Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 11:46:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FD101065675 for ; Thu, 21 Jul 2011 11:46:30 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id D10E68FC19 for ; Thu, 21 Jul 2011 11:46:29 +0000 (UTC) Received: from park.js.berklix.net (p5DCBE76B.dip.t-dialin.net [93.203.231.107]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6LBkRae093360; Thu, 21 Jul 2011 11:46:28 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6LBkRTH043258; Thu, 21 Jul 2011 13:46:28 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6LBkHpd025018; Thu, 21 Jul 2011 11:46:22 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107211146.p6LBkHpd025018@fire.js.berklix.net> To: Alexander Kabaev From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 20 Jul 2011 20:01:43 EDT." Date: Thu, 21 Jul 2011 13:46:17 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 11:46:30 -0000 Hi, Alexander Kabaev wrote: > On Wed, Jul 20, 2011 at 2:04 PM, Julian H. Stacey wrote: > > Hi John & all, > > > > > > >> It is not just the crt files > >> that matter, but every library.  You would need CPU-specific versions of every > >> static library on the build system, > > > > Would be preferable. > > Though as we default to link dynamic, not as essential as crt.o . > > We could also have some ifdef to avoid by default generating for > > all of [3-6]86 that would save space & time, > > If the directory was not filled, a user of gcc --march=i586 would > > then fail to link from /usr/lib/i586/ & could receive a good error, > > instead of a 686 crt.o with no error. > > > > > >> and possibly you would want to do this for > >> all shared libraries too. > > > > I guess we could skip those, Presuming a target system should have a > > matched set for the right CPU & release etc. > > > > > > I'm not sure about the recent plethora of lib stuff > >        /lib > >                Seems to be all .so so I guess not affected. > >        /libexec > >                ld-elf.so.1 ld-elf32.so.1       # no man ld-elf > >        /usr/lib > >                This is where I'd suggest sub dirs of [3-6]86 > >                with default machine native either > >                         in top dir > >                        or perhaps a native/ sub dir, > >                        or sym linked > >                whatever gcc & out & other projects find best ? > >        /usr/lib32 > >                ... Sigh ! same as above ? .. > >        /usr/libdata /ldscripts & /lint > >                ? > >        /usr/libexec > >                Presumably can ignore this as real programs. > > > >        & ignore inderminent localy variant dirs shown by > >                cd /usr/local ; find . -type d -name \*lib\* -print > > Hi Alexander, Your mailer has gone wrong. It lost cc freebsd-hackers@freebsd.org (restored) & below the word 'plethora' in my posting was a plain tab indented section. Your mailer mangled each tab to a string of 5 chars: " \xa0" > Where does that end? We have tons of -march options, would you create > the subdir for each combination of ABI and CPU users can potentially > think > of? Insanity lies that way. Don't panic, I agree, Only a few rare cross generator hosts might want the severe bloat of all arch libs installed. But no reason we coudn't have an infrastructure of lib dir name structure expectancy for where to look for stuff _If_ it's installed. Maybe NetBSD & Linux people may have also had ideas on that ? It would prevent gcc -march=586 silently failing, producing unusable binaries, as wrong crt.o is linked in. Would this be best: Extend gcc -march=cpu , so in addition to telling compiler to generate cpu specific code rather than default native, it also automatically passes paths to linker to use eg Not /usr/lib/ but /usr/lib/cpu/ thus forcing a link failure if directory non existant or empty. No default auto populating with every other arch. Certainly not for sparc, amd, etc. Not even for *86 by default (Unless, maybe just for crt.o as sample ? they're not big ...) Later we could add to Makefile structure, to populate lib sub dir[s] on request, if optional extra env. var[s] trigger an ifdef build of extra libs. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 12:17:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB9F8106564A for ; Thu, 21 Jul 2011 12:17:38 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 203338FC19 for ; Thu, 21 Jul 2011 12:17:37 +0000 (UTC) Received: from park.js.berklix.net (p5DCBE76B.dip.t-dialin.net [93.203.231.107]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p6LCHZQP093565; Thu, 21 Jul 2011 12:17:36 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p6LCHaYl043364; Thu, 21 Jul 2011 14:17:36 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p6LCHV9p025307; Thu, 21 Jul 2011 12:17:36 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201107211217.p6LCHV9p025307@fire.js.berklix.net> To: freebsd-toolchain@freebsd.org, freebsd-i386@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Thu, 21 Jul 2011 14:17:31 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 12:17:38 -0000 Hi freebsd-toolchain@freebsd.org, freebsd-i386@freebsd.org cc: freebsd-hackers@freebsd.org Sun Jul 17 01:19:37 UTC 2011 I wrote to freebsd-hackers@ with Subject: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 Summary: I found a problem with CFLAGS += -march=i586 on an i686 linking a crt.o for an i686, then not running on an i586, I suggested maybe -march could be extended to also select seperate lib sub directories to at least trigger a link failure, rather than a silent apparent good compile of a bad binary. Others on freebsd-hackers@ made various follow up. People on freebsd-toolchain@ & freebsd-i386@ might have valuable input ? Not wanting to split the thread between lists, or cross post, More than this one) or lose people on freebsd-hackers@, Could you please look at http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035889.html & reply-to: freebsd-hackers@freebsd.org Thanks ! (PS I'm not on freebsd-toolchain@ & freebsd-i386@, but am on freebsd-hackers@ ) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 13:08:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A86EE106564A for ; Thu, 21 Jul 2011 13:08:08 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 547C38FC1C for ; Thu, 21 Jul 2011 13:08:07 +0000 (UTC) Received: by qwc9 with SMTP id 9so847524qwc.13 for ; Thu, 21 Jul 2011 06:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=El1R4VkRyE9jAuF1zP5JwSiVemnO7nwIPpHFISFHZ7U=; b=tFLwb4JmAPbwWqsmEuSxLeniwI3FLWlzvGgiS7kCUf5LBmgw3SSMy+e/4SyAz86/tx eRZhGfYYtohxMewRXK3gE2A8i7rWdxDSGxHJyCCJztbwh8pBSe1wBWKmp4R1UzYIr7Dj bEk69ALxXxJ3IISaAQxzb3k5eddmjrmuz7t04= MIME-Version: 1.0 Received: by 10.229.51.138 with SMTP id d10mr191901qcg.17.1311251823217; Thu, 21 Jul 2011 05:37:03 -0700 (PDT) Received: by 10.229.219.19 with HTTP; Thu, 21 Jul 2011 05:37:03 -0700 (PDT) Date: Thu, 21 Jul 2011 16:37:03 +0400 Message-ID: From: Subbsd To: freebsd-jail , freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: userland dtrace tools not working in jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 13:08:08 -0000 Hi I try to use dtrace in jail on FreeBSD-9-64. Kernel have options: --- include GENERIC ident GENERIC-DTRACE options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # all architectures - kernel ELF linker loads CTF data options KDTRACE_FRAME # amd64 - ensure frames are compiled in makeoptions WITH_CTF=1 --- All world compiling with WITH_CTF=1 KNOBS. And dtraccing works fine in 'master' hosts When i try use it in chrooted environment (getting by installworld DESTDIR="diffrence path" from WITH_CTF=1 objects) it doesn't work. After make -C /usr/src installworld distribution DESTDIR="/usr/a": bsd# mount - t devfs devfs /usr/a/dev (dtrace used /dev/dtrace/* special files) bsd# dtrace -l |wc -l 42300 bsd# chroot /usr/a dtrace -l |wc -l 42300 bsd# dtrace -n 'syscall:::entry { @sc[execname, probefunc] = count(); }' ^C (...) bsd# chroot /usr/a dtrace -n 'syscall:::entry { @sc[execname, probefunc] = count(); }' dtrace: invalid probe specifier syscall:::entry { @sc[execname, probefunc] = count(); }: "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t" getpid() = 2786 (0xae2) __sysctl(0x7fffffffd2d0,0x2,0x800a72a80,0x7fffffffd2d8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd1e0,0x2,0x7fffffffd220,0x7fffffffd288,0x800863e10,0xd) = 0 (0x0) __sysctl(0x7fffffffd220,0x3,0x800a71968,0x7fffffffd2d8,0x0,0x0) = 0 (0x0) readlink("/etc/malloc.conf",0x7fffffffcdc0,1024) ERR#2 'No such file or directory' issetugid(0x801a58801,0x7fffffffcdc0,0x0,0x2,0x7fffffffcdc0,0x0) = 0 (0x0) break(0x800000) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34389770240 (0x801ca4000) mmap(0x8020a4000,3522560,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34393964544 (0x8020a4000) munmap(0x801ca4000,3522560) = 0 (0x0) thr_self(0x802007400,0x0,0x0,0x0,0x40,0x7fffffffc8c0) = 0 (0x0) mmap(0x7fffffbfe000,4096,PROT_NONE,MAP_ANON,-1,0x0) = 140737484152832 (0x7fffffbfe000) rtprio_thread(0x0,0x18735,0x7fffffffd290,0x1000,0xffffffff,0x0) = 0 (0x0) sysarch(0x81,0x7fffffffd2b8,0x800a71540,0x800a718e0,0xffffffff,0x0) = 0 (0x0) sigaction(32,{ 0x80085d290 SA_SIGINFO ss_t },0x0) = 0 (0x0) sigprocmask(SIG_UNBLOCK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) getrlimit(RLIMIT_NOFILE,{ cur=11095,max=11095 }) = 0 (0x0) setrlimit(RLIMIT_NOFILE,{ cur=11095,max=11095 }) = 0 (0x0) __sysctl(0x7fffffffd190,0x2,0x7fffffffd1d0,0x7fffffffd238,0x800ad6158,0x16) = 0 (0x0) __sysctl(0x7fffffffd1d0,0x3,0x0,0x7fffffffd358,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd190,0x2,0x7fffffffd1d0,0x7fffffffd238,0x800ad6158,0x16) = 0 (0x0) __sysctl(0x7fffffffd1d0,0x3,0x80203b080,0x7fffffffd358,0x0,0x0) = 0 (0x0) open("/dev/dtrace/dtrace",O_RDONLY,00) = 3 (0x3) open("/dev/dtrace/profile",O_RDONLY,00) = 4 (0x4) open("/dev/dtrace/syscall",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/syscall",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/vfs",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/sctp",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/callout_execute",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/proc",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/mac",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/mac_framework",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/priv",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/lockstat",O_RDONLY,00) = 5 (0x5) open("/dev/dtrace/dtmalloc",O_RDONLY,00) = 6 (0x6) open("/dev/dtrace/fbt",O_RDONLY,00) = 7 (0x7) open("/dev/dtrace/nfsclient",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/nfscl",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/dtrace/dtrace",O_RDWR,00) = 8 (0x8) open("/dev/dtrace/fasttrap",O_RDWR,00) = 9 (0x9) close(7) = 0 (0x0) close(6) = 0 (0x0) close(5) = 0 (0x0) close(4) = 0 (0x0) close(3) = 0 (0x0) fcntl(8,F_SETFD,FD_CLOEXEC) = 0 (0x0) fcntl(9,F_SETFD,FD_CLOEXEC) = 0 (0x0) __sysctl(0x7fffffffd230,0x2,0x802041b70,0x7fffffffd228,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd230,0x2,0x802041c70,0x7fffffffd228,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd230,0x2,0x802041d70,0x7fffffffd228,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd230,0x2,0x802041e70,0x7fffffffd228,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd230,0x2,0x802041f70,0x7fffffffd228,0x0,0x0) = 0 (0x0) ioctl(8,0x4030780a { IOR 0x78('x'), 10, 48 },0x2041010) = 0 (0x0) __sysctl(0x7fffffffd190,0x2,0x7fffffffd1d0,0x7fffffffd238,0x800ad61c4,0xd) = 0 (0x0) __sysctl(0x7fffffffd1d0,0x2,0x7fffffffd370,0x7fffffffd358,0x0,0x0) = 0 (0x0) kldnext(0) = 1 (0x1) kldstat(1,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/kernel",O_RDONLY,00) ERR#2 'No such file or directory' stat("/usr/share/nls/C/libc.cat",0x7fffffffbb30) ERR#2 'No such file or directory' stat("/usr/share/nls/libc/C",0x7fffffffbb30) ERR#2 'No such file or directory' stat("/usr/local/share/nls/C/libc.cat",0x7fffffffbb30) ERR#2 'No such file or directory' stat("/usr/local/share/nls/libc/C",0x7fffffffbb30) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(1) = 2 (0x2) kldstat(2,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/geom_mirror.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(2) = 3 (0x3) kldstat(3,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/accf_data.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(3) = 4 (0x4) kldstat(4,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/accf_dns.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(4) = 5 (0x5) kldstat(5,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/accf_http.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(5) = 6 (0x6) kldstat(6,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/dtrace.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(6) = 7 (0x7) kldstat(7,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/cyclic.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(7) = 8 (0x8) kldstat(8,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/opensolaris.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(8) = 9 (0x9) kldstat(9,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/dtrace_test.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(9) = 10 (0xa) kldstat(10,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/dtraceall.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(10) = 11 (0xb) kldstat(11,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/dtmalloc.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(11) = 12 (0xc) kldstat(12,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/dtnfscl.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(12) = 13 (0xd) kldstat(13,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/dtnfsclient.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(13) = 14 (0xe) kldstat(14,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/nfsclient.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(14) = 15 (0xf) kldstat(15,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/nfs_common.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(15) = 16 (0x10) kldstat(16,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/fbt.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(16) = 17 (0x11) kldstat(17,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/fasttrap.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(17) = 18 (0x12) kldstat(18,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/lockstat.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(18) = 19 (0x13) kldstat(19,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/sdt.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(19) = 20 (0x14) kldstat(20,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/systrace.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(20) = 21 (0x15) kldstat(21,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/systrace_freebsd32.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(21) = 22 (0x16) kldstat(22,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/profile.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(22) = 23 (0x17) kldstat(23,0x7fffffffc1d0) = 0 (0x0) open("/boot/kernel/nullfs.ko",O_RDONLY,00) ERR#2 'No such file or directory' close(-1) ERR#9 'Bad file descriptor' kldnext(23) = 0 (0x0) getegid() = 0 (0x0) geteuid() = 0 (0x0) getgid() = 0 (0x0) getpid() = 2786 (0xae2) getpgid(0) = 2785 (0xae1) getppid() = 2785 (0xae1) getsid(0) = 52367 (0xcc8f) getuid() = 0 (0x0) mmap(0x0,706,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366447616 (0x800666000) mprotect(0x800666000,706,PROT_READ) = 0 (0x0) mmap(0x0,730,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366451712 (0x800667000) mprotect(0x800667000,730,PROT_READ) = 0 (0x0) munmap(0x800666000,706) = 0 (0x0) mmap(0x0,480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366447616 (0x800666000) mprotect(0x800666000,480,PROT_READ) = 0 (0x0) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc950) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc930) = 0 (0x0) stat("/usr/lib/dtrace",{ mode=drwxr-xr-x ,inode=3457372,size=512,blksize=32768 }) = 0 (0x0) open("/usr/lib/dtrace",O_NONBLOCK|0x20000,0201020200) = 3 (0x3) fstat(3,{ mode=drwxr-xr-x ,inode=3457372,size=512,blksize=32768 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstatfs(0x3,0x7fffffffcd40,0x802001a20,0x607d90,0x607fb0,0xfffff800) = 0 (0x0) getdirentries(0x3,0x802116000,0x1000,0x802114488,0x607fb0,0xfffffffd) = 512 (0x200) open("/usr/lib/dtrace/errno.d",O_RDONLY,0666) = 4 (0x4) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(4,{ mode=-r--r--r-- ,inode=3458159,size=6900,blksize=32768 }) = 0 (0x0) read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) = 6900 (0x1af4) read(4,0x802160000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6e0) = 0 (0x0) madvise(0x8021b8000,0xe000,0x5,0x1b7,0x7,0x7fffffffbef0) = 0 (0x0) close(4) = 0 (0x0) open("/usr/lib/dtrace/psinfo.d",O_RDONLY,0666) = 4 (0x4) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(4,{ mode=-r--r--r-- ,inode=3458160,size=3186,blksize=32768 }) = 0 (0x0) read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) = 3186 (0xc72) read(4,0x802160000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6e0) = 0 (0x0) close(4) = 0 (0x0) madvise(0x8021b8000,0x1000,0x5,0x2940,0x7,0x7fffffffc690) = 0 (0x0) madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x7fffffffc690) = 0 (0x0) open("/usr/lib/dtrace/signal.d",O_RDONLY,0666) = 4 (0x4) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(4,{ mode=-r--r--r-- ,inode=3458161,size=3111,blksize=32768 }) = 0 (0x0) read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) = 3111 (0xc27) read(4,0x802160000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6e0) = 0 (0x0) close(4) = 0 (0x0) madvise(0x8021b8000,0x5000,0x5,0x1b7,0x7,0x0) = 0 (0x0) madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x0) = 0 (0x0) open("/usr/lib/dtrace/unistd.d",O_RDONLY,0666) = 4 (0x4) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(4,{ mode=-r--r--r-- ,inode=3458162,size=2009,blksize=32768 }) = 0 (0x0) read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) = 2009 (0x7d9) read(4,0x802160000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6e0) = 0 (0x0) close(4) = 0 (0x0) madvise(0x8021b8000,0x1000,0x5,0x2940,0x7,0x7fffffffc690) = 0 (0x0) madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x7fffffffc690) = 0 (0x0) open("/usr/lib/dtrace/regs_x86.d",O_RDONLY,0666) = 4 (0x4) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(4,{ mode=-r--r--r-- ,inode=3458163,size=3593,blksize=32768 }) = 0 (0x0) read(4,"/* "...,32768) = 3593 (0xe09) read(4,0x802160000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6e0) = 0 (0x0) close(4) = 0 (0x0) madvise(0x8021b8000,0x6000,0x5,0x1b7,0x7,0x0) = 0 (0x0) madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x0) = 0 (0x0) getdirentries(0x3,0x802116000,0x1000,0x802114488,0x7fffffffc690,0x7fffffffc690) = 0 (0x0) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) open("/usr/lib/dtrace/regs_x86.d",O_RDONLY,0666) = 3 (0x3) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(3,{ mode=-r--r--r-- ,inode=3458163,size=3593,blksize=32768 }) = 0 (0x0) read(3,"/* "...,32768) = 3593 (0xe09) read(3,0x80211d000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6b0) = 0 (0x0) close(3) = 0 (0x0) madvise(0x80217e000,0x1000,0x5,0x23d0,0x7,0xffffffff) = 0 (0x0) madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) = 0 (0x0) open("/usr/lib/dtrace/unistd.d",O_RDONLY,0666) = 3 (0x3) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(3,{ mode=-r--r--r-- ,inode=3458162,size=2009,blksize=32768 }) = 0 (0x0) read(3,"/*\n * CDDL HEADER START\n *\n *"...,32768) = 2009 (0x7d9) read(3,0x80211d000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6b0) = 0 (0x0) close(3) = 0 (0x0) madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) = 0 (0x0) open("/usr/lib/dtrace/signal.d",O_RDONLY,0666) = 3 (0x3) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(3,{ mode=-r--r--r-- ,inode=3458161,size=3111,blksize=32768 }) = 0 (0x0) read(3,"/*\n * CDDL HEADER START\n *\n *"...,32768) = 3111 (0xc27) read(3,0x80211d000,32768) = 0 (0x0) ioctl(0,TIOCGETA,0xffffc6b0) = 0 (0x0) close(3) = 0 (0x0) madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) = 0 (0x0) open("/usr/lib/dtrace/psinfo.d",O_RDONLY,0666) = 3 (0x3) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) fstat(3,{ mode=-r--r--r-- ,inode=3458160,size=3186,blksize=32768 }) = 0 (0x0) read(3,"/*\n * CDDL HEADER START\n *\n *"...,32768) = 3186 (0xc72) read(3,0x80211d000,32768) = 0 (0x0) mmap(0x0,495,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366455808 (0x800668000) mprotect(0x800668000,495,PROT_READ) = 0 (0x0) munmap(0x800666000,480) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) mmap(0x0,573,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366447616 (0x800666000) mprotect(0x800666000,573,PROT_READ) = 0 (0x0) munmap(0x800668000,495) = 0 (0x0) close(3) = 0 (0x0) madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) = 0 (0x0) dtrace: write(2,"dtrace: ",8) = 8 (0x8) invalid probe specifier syscall:::entry { @sc[execname, probefunc] = count(); }write(2,"invalid probe specifier syscall:"...,79) = 79 (0x4f) : "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t" write(2,": "/usr/lib/dtrace/psinfo.d", li"...,65) = 65 (0x41) madvise(0x802181000,0x1000,0x5,0x2418,0x7,0x8020019c0) = 0 (0x0) madvise(0x80217d000,0x1000,0x5,0x23b8,0x7,0x8020019c0) = 0 (0x0) madvise(0x80217a000,0x1000,0x5,0x2370,0x7,0x8020019c0) = 0 (0x0) madvise(0x802175000,0x2000,0x5,0x174,0x7,0x8020019c0) = 0 (0x0) madvise(0x80217e000,0x2000,0x5,0x17d,0x7,0x1) = 0 (0x0) madvise(0x80217b000,0x1000,0x5,0x2388,0x7,0x1) = 0 (0x0) madvise(0x802177000,0x1000,0x5,0x2328,0x7,0x1) = 0 (0x0) madvise(0x802115000,0x1000,0x5,0x19f8,0x7,0x1) = 0 (0x0) madvise(0x80217c000,0x1000,0x5,0x23a0,0x7,0x1) = 0 (0x0) madvise(0x802178000,0x2000,0x5,0x177,0x7,0x1) = 0 (0x0) madvise(0x802113000,0x2000,0x5,0x112,0x7,0x1) = 0 (0x0) munmap(0x800667000,730) = 0 (0x0) munmap(0x800666000,573) = 0 (0x0) madvise(0x802180000,0x1000,0x5,0x2400,0x7,0xffffffff) = 0 (0x0) madvise(0x802111000,0x2000,0x5,0x110,0x7,0xffffffff) = 0 (0x0) madvise(0x8020c1000,0x1000,0x5,0x1218,0x7,0xffffffff) = 0 (0x0) madvise(0x802088000,0x1000,0x5,0xcc0,0x7,0xffffffff) = 0 (0x0) close(8) = 0 (0x0) close(9) = 0 (0x0) madvise(0x8020c4000,0x1000,0x5,0x1260,0x7,0xffffffff) = 0 (0x0) madvise(0x8020bd000,0x1000,0x5,0x11b8,0x7,0xffffffff) = 0 (0x0) madvise(0x8020a6000,0x1000,0x5,0xf90,0x7,0xffffffff) = 0 (0x0) madvise(0x802094000,0x1000,0x5,0xde0,0x7,0xffffffff) = 0 (0x0) madvise(0x802085000,0x1000,0x5,0xc78,0x7,0xffffffff) = 0 (0x0) madvise(0x8020c3000,0x1000,0x5,0x1248,0x7,0xffffffff) = 0 (0x0) madvise(0x80209d000,0x2000,0x5,0x9c,0x7,0xffffffff) = 0 (0x0) madvise(0x802086000,0x1000,0x5,0xc90,0x7,0xffffffff) = 0 (0x0) madvise(0x80203f000,0x1000,0x5,0x5e8,0x7,0xffffffff) = 0 (0x0) madvise(0x802084000,0x1000,0x5,0xc60,0x7,0x8020011e0) = 0 (0x0) madvise(0x802040000,0x3000,0x5,0x3f,0x7,0x8020011e0) = 0 (0x0) madvise(0x80203c000,0x1000,0x5,0x5a0,0x7,0x8020011e0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) process exit, rval = 1 - i can see anything that hinders dtrace to be happy. Any ideas? Thanks. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 13:51:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6B82106566B; Thu, 21 Jul 2011 13:51:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A96288FC17; Thu, 21 Jul 2011 13:51:33 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a] (unknown [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F0E225C37; Thu, 21 Jul 2011 15:51:31 +0200 (CEST) Message-ID: <4E282EE4.50500@FreeBSD.org> Date: Thu, 21 Jul 2011 15:51:32 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <201107211217.p6LCHV9p025307@fire.js.berklix.net> In-Reply-To: <201107211217.p6LCHV9p025307@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Julian H. Stacey" , freebsd-toolchain@freebsd.org, freebsd-i386@freebsd.org Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 13:51:34 -0000 On 2011-07-21 14:17, Julian H. Stacey wrote: > Summary: > I found a problem with CFLAGS += -march=i586 on an i686 linking > a crt.o for an i686, then not running on an i586, IMHO this is a bit of a PEBKAC issue. If you change CPUFLAGS to target a specific CPU, you should really rebuild all of world with it, not just a single program. In fact, you should rebuild all your ports too. > I suggested > maybe -march could be extended to also select seperate lib sub > directories to at least trigger a link failure, rather than a silent > apparent good compile of a bad binary. I think this would add a whole lot of complexity for very little gain, and still not save you from potential problems. You would really have to use the same approach for all system libraries, otherwise you might link in something from e.g. libc or libcrypto that was optimized for the wrong CPU. And I'm not even mentioning objects and/or libraries from ports... :) The compiler cannot automagically determine whether any object or library file you link into your program is fit to run on the CPU you are targeting, unless you would add information specifying the CPU type (and other particulars) to the object files themselves. In the end, it is up to you to make sure you do not mix "incompatible" object code. Having said all this, if you are worried particularly about the crt*.o files, then we could simply always build those with 'lowest common denominator' flags, like we do with e.g. the dynamic linker. I doubt very much that the startup code gains any performance by optimizing for higher CPU types. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 15:42:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7674B1065676 for ; Thu, 21 Jul 2011 15:42:50 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3E95C8FC18 for ; Thu, 21 Jul 2011 15:42:50 +0000 (UTC) Received: by yic13 with SMTP id 13so838271yic.13 for ; Thu, 21 Jul 2011 08:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=OJDiAExb7EWgwzQZVLvUxeo5pVoHQQ2/5NsXxcV7UxQ=; b=HHF4Px6cci+MkAOHEZmOaWk/ijA8zBYZwLdupycBTHMXG9eXogOK7rDT5kH+y7lsyp NtBfRF4uUdMRduFMBQsuPQg5zl5aM4Hd2E2oFR7l92yejZT1rOH99cSVJXnBO+Vou8gd ZnMoIh6A2I6TeZ+TqOZqBK6TAGRt5k5YyoLto= MIME-Version: 1.0 Received: by 10.236.187.68 with SMTP id x44mr590360yhm.306.1311262969721; Thu, 21 Jul 2011 08:42:49 -0700 (PDT) Received: by 10.236.110.40 with HTTP; Thu, 21 Jul 2011 08:42:49 -0700 (PDT) Date: Thu, 21 Jul 2011 11:42:49 -0400 Message-ID: From: Aryeh Friedman To: FreeBSD Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 21 Jul 2011 16:21:42 +0000 Subject: make release question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:42:50 -0000 Where does "make release" place the disk images (iso's) by default From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 16:31:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F99C106566B for ; Thu, 21 Jul 2011 16:31:51 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id E71C88FC08 for ; Thu, 21 Jul 2011 16:31:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LOO0080OZ92GH00@smtpauth1.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Thu, 21 Jul 2011 11:31:50 -0500 (CDT) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LOO003ZJZ8X7O10@smtpauth1.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Thu, 21 Jul 2011 11:31:45 -0500 (CDT) Date: Thu, 21 Jul 2011 11:31:44 -0500 From: Nathan Whitehorn In-reply-to: To: Aryeh Friedman Message-id: <4E285470.6080706@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-9, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.21.162414, SenderIP=128.104.160.176 References: User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.18) Gecko/20110706 Thunderbird/3.1.11 Cc: FreeBSD Mailing List Subject: Re: make release question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 16:31:51 -0000 On 07/21/11 10:42, Aryeh Friedman wrote: > Where does "make release" place the disk images (iso's) by default > _______________________________________________ > 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" On -CURRENT, it places them in /usr/obj/usr/src/release. You can use make install DESTDIR=blah to put them somewhere else. On 8.x and earlier it places them in CHROOT/R. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 16:36:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E96511065675 for ; Thu, 21 Jul 2011 16:36:54 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 07F028FC15 for ; Thu, 21 Jul 2011 16:36:53 +0000 (UTC) Received: by wwe6 with SMTP id 6so1399599wwe.31 for ; Thu, 21 Jul 2011 09:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uhREBZlu6BNKFz9FKPJ36VpgfZ8GgG1NYcUh6OIWhG4=; b=EYoHbTaqAUC6CCuzzRs6h98rbaxFm7SqA4AWiYodNT2phAYCrOLtSfKNJQfRN8MUaB ZlXEaTAlino8Cu6q67Szj4hCMJYiubnjzkQ+sYWBgswP1eB7hVcqZ+wXoHJzcnBqumpZ mlU6JVj4lS4IYBokn9c/VY6ToFjbEK77BJjXk= MIME-Version: 1.0 Received: by 10.217.4.66 with SMTP id t44mr408948wes.25.1311266212697; Thu, 21 Jul 2011 09:36:52 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.216.46.18 with HTTP; Thu, 21 Jul 2011 09:36:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Jul 2011 09:36:52 -0700 X-Google-Sender-Auth: M1w88AlEcPUpM8vOtWbR1tStPYc Message-ID: From: Artem Belevich To: Subbsd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , freebsd-jail Subject: Re: userland dtrace tools not working in jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 16:36:55 -0000 On Thu, Jul 21, 2011 at 5:37 AM, Subbsd wrote: > Hi > > I try to use dtrace in jail on FreeBSD-9-64. > Kernel have options: > --- > include GENERIC > ident =A0 =A0 =A0 =A0 =A0 GENERIC-DTRACE > options KDTRACE_FRAME =A0 =A0 =A0 =A0 =A0 # Ensure frames are compiled in > options KDTRACE_HOOKS =A0 =A0 =A0 =A0 =A0 # Kernel DTrace hooks > options DDB_CTF =A0 =A0 =A0 =A0 =A0 =A0 =A0# all architectures - kernel E= LF linker > loads CTF data > options KDTRACE_FRAME =A0 =A0 =A0 =A0# amd64 - ensure frames are compiled= in > makeoptions WITH_CTF=3D1 > --- > > All world compiling with WITH_CTF=3D1 KNOBS. And dtraccing works fine in > 'master' hosts > When i try use it in chrooted environment (getting by installworld > DESTDIR=3D"diffrence path" from WITH_CTF=3D1 objects) it doesn't work. > > After > make -C /usr/src installworld distribution DESTDIR=3D"/usr/a": > > bsd# mount - t devfs devfs /usr/a/dev =A0 =A0(dtrace used /dev/dtrace/* > special files) > bsd# dtrace -l |wc -l > =A0 42300 > bsd# chroot /usr/a dtrace -l |wc -l > =A0 42300 > > bsd# dtrace -n 'syscall:::entry { @sc[execname, probefunc] =3D count(); }= ' > ^C > (...) > > bsd# chroot /usr/a dtrace -n 'syscall:::entry { @sc[execname, > probefunc] =3D count(); }' > dtrace: invalid probe specifier syscall:::entry { @sc[execname, > probefunc] =3D count(); }: "/usr/lib/dtrace/psinfo.d", line 37: syntax > error near "uid_t" > > > getpid() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 2786 (0xae2) > __sysctl(0x7fffffffd2d0,0x2,0x800a72a80,0x7fffffffd2d8,0x0,0x0) =3D 0 (0x= 0) > __sysctl(0x7fffffffd1e0,0x2,0x7fffffffd220,0x7fffffffd288,0x800863e10,0xd= ) > =3D 0 (0x0) > __sysctl(0x7fffffffd220,0x3,0x800a71968,0x7fffffffd2d8,0x0,0x0) =3D 0 (0x= 0) > readlink("/etc/malloc.conf",0x7fffffffcdc0,1024) ERR#2 'No such file > or directory' > issetugid(0x801a58801,0x7fffffffcdc0,0x0,0x2,0x7fffffffcdc0,0x0) =3D 0 (0= x0) > break(0x800000) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=3D 0 (0x0) > mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D > 34389770240 (0x801ca4000) > mmap(0x8020a4000,3522560,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0= ) > =3D 34393964544 (0x8020a4000) > munmap(0x801ca4000,3522560) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > thr_self(0x802007400,0x0,0x0,0x0,0x40,0x7fffffffc8c0) =3D 0 (0x0) > mmap(0x7fffffbfe000,4096,PROT_NONE,MAP_ANON,-1,0x0) =3D 140737484152832 > (0x7fffffbfe000) > rtprio_thread(0x0,0x18735,0x7fffffffd290,0x1000,0xffffffff,0x0) =3D 0 (0x= 0) > sysarch(0x81,0x7fffffffd2b8,0x800a71540,0x800a718e0,0xffffffff,0x0) =3D 0= (0x0) > sigaction(32,{ 0x80085d290 SA_SIGINFO ss_t },0x0) =3D 0 (0x0) > sigprocmask(SIG_UNBLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > getrlimit(RLIMIT_NOFILE,{ cur=3D11095,max=3D11095 }) =3D 0 (0x0) > setrlimit(RLIMIT_NOFILE,{ cur=3D11095,max=3D11095 }) =3D 0 (0x0) > __sysctl(0x7fffffffd190,0x2,0x7fffffffd1d0,0x7fffffffd238,0x800ad6158,0x1= 6) > =3D 0 (0x0) > __sysctl(0x7fffffffd1d0,0x3,0x0,0x7fffffffd358,0x0,0x0) =3D 0 (0x0) > __sysctl(0x7fffffffd190,0x2,0x7fffffffd1d0,0x7fffffffd238,0x800ad6158,0x1= 6) > =3D 0 (0x0) > __sysctl(0x7fffffffd1d0,0x3,0x80203b080,0x7fffffffd358,0x0,0x0) =3D 0 (0x= 0) > open("/dev/dtrace/dtrace",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =3D 3 (0x3) > open("/dev/dtrace/profile",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0=3D 4 (0x4) > open("/dev/dtrace/syscall",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0ERR#2 'No such= file > or directory' > open("/dev/dtrace/syscall",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0ERR#2 'No such= file > or directory' > open("/dev/dtrace/vfs",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =A0 =A0ERR#2 'No = such file > or directory' > open("/dev/dtrace/sctp",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =A0 ERR#2 'No su= ch file > or directory' > open("/dev/dtrace/callout_execute",O_RDONLY,00) =A0ERR#2 'No such file > or directory' > open("/dev/dtrace/proc",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =A0 ERR#2 'No su= ch file > or directory' > open("/dev/dtrace/mac",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =A0 =A0ERR#2 'No = such file > or directory' > open("/dev/dtrace/mac_framework",O_RDONLY,00) =A0 =A0ERR#2 'No such file > or directory' > open("/dev/dtrace/priv",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =A0 ERR#2 'No su= ch file > or directory' > open("/dev/dtrace/lockstat",O_RDONLY,00) =A0 =A0 =A0 =A0 =3D 5 (0x5) > open("/dev/dtrace/dtmalloc",O_RDONLY,00) =A0 =A0 =A0 =A0 =3D 6 (0x6) > open("/dev/dtrace/fbt",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 7 (0x7= ) > open("/dev/dtrace/nfsclient",O_RDONLY,00) =A0 =A0 =A0 =A0ERR#2 'No such f= ile > or directory' > open("/dev/dtrace/nfscl",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0 =A0ERR#2 'No su= ch file > or directory' > open("/dev/dtrace/dtrace",O_RDWR,00) =A0 =A0 =A0 =A0 =A0 =A0 =3D 8 (0x8) > open("/dev/dtrace/fasttrap",O_RDWR,00) =A0 =A0 =A0 =A0 =A0 =3D 9 (0x9) > close(7) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > close(6) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > close(5) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > close(4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > close(3) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > fcntl(8,F_SETFD,FD_CLOEXEC) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > fcntl(9,F_SETFD,FD_CLOEXEC) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > __sysctl(0x7fffffffd230,0x2,0x802041b70,0x7fffffffd228,0x0,0x0) =3D 0 (0x= 0) > __sysctl(0x7fffffffd230,0x2,0x802041c70,0x7fffffffd228,0x0,0x0) =3D 0 (0x= 0) > __sysctl(0x7fffffffd230,0x2,0x802041d70,0x7fffffffd228,0x0,0x0) =3D 0 (0x= 0) > __sysctl(0x7fffffffd230,0x2,0x802041e70,0x7fffffffd228,0x0,0x0) =3D 0 (0x= 0) > __sysctl(0x7fffffffd230,0x2,0x802041f70,0x7fffffffd228,0x0,0x0) =3D 0 (0x= 0) > ioctl(8,0x4030780a { IOR 0x78('x'), 10, 48 },0x2041010) =3D 0 (0x0) > __sysctl(0x7fffffffd190,0x2,0x7fffffffd1d0,0x7fffffffd238,0x800ad61c4,0xd= ) > =3D 0 (0x0) > __sysctl(0x7fffffffd1d0,0x2,0x7fffffffd370,0x7fffffffd358,0x0,0x0) =3D 0 = (0x0) > kldnext(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 1 (0x1) > kldstat(1,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/kernel",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0ERR#2 'No such= file > or directory' Here's your problem ^^^. dtrace extracts CTF information from the binaries. In case of kernel probes, that would be the kernel itself and loadable modules. All that stuff lives in /boot and is not accessible from your jail. --Artem > stat("/usr/share/nls/C/libc.cat",0x7fffffffbb30) ERR#2 'No such file > or directory' > stat("/usr/share/nls/libc/C",0x7fffffffbb30) =A0 =A0 ERR#2 'No such file > or directory' > stat("/usr/local/share/nls/C/libc.cat",0x7fffffffbb30) ERR#2 'No such > file or directory' > stat("/usr/local/share/nls/libc/C",0x7fffffffbb30) ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 2 (0x2) > kldstat(2,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/geom_mirror.ko",O_RDONLY,00) =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(2) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 3 (0x3) > kldstat(3,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/accf_data.ko",O_RDONLY,00) =A0 =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(3) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 4 (0x4) > kldstat(4,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/accf_dns.ko",O_RDONLY,00) =A0 =A0 ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 5 (0x5) > kldstat(5,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/accf_http.ko",O_RDONLY,00) =A0 =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(5) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 6 (0x6) > kldstat(6,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/dtrace.ko",O_RDONLY,00) =A0 =A0 =A0 ERR#2 'No such fil= e > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(6) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 7 (0x7) > kldstat(7,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/cyclic.ko",O_RDONLY,00) =A0 =A0 =A0 ERR#2 'No such fil= e > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(7) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 8 (0x8) > kldstat(8,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/opensolaris.ko",O_RDONLY,00) =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(8) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 9 (0x9) > kldstat(9,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > open("/boot/kernel/dtrace_test.ko",O_RDONLY,00) =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(9) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 10 (0xa) > kldstat(10,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/dtraceall.ko",O_RDONLY,00) =A0 =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(10) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 11 (0xb) > kldstat(11,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/dtmalloc.ko",O_RDONLY,00) =A0 =A0 ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(11) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 12 (0xc) > kldstat(12,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/dtnfscl.ko",O_RDONLY,00) =A0 =A0 =A0ERR#2 'No such fil= e > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(12) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 13 (0xd) > kldstat(13,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/dtnfsclient.ko",O_RDONLY,00) =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(13) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 14 (0xe) > kldstat(14,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/nfsclient.ko",O_RDONLY,00) =A0 =A0ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(14) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 15 (0xf) > kldstat(15,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/nfs_common.ko",O_RDONLY,00) =A0 ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(15) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 16 (0x10) > kldstat(16,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/fbt.ko",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0ERR#2 'No such= file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(16) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 17 (0x11) > kldstat(17,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/fasttrap.ko",O_RDONLY,00) =A0 =A0 ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(17) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 18 (0x12) > kldstat(18,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/lockstat.ko",O_RDONLY,00) =A0 =A0 ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(18) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 19 (0x13) > kldstat(19,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/sdt.ko",O_RDONLY,00) =A0 =A0 =A0 =A0 =A0ERR#2 'No such= file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(19) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 20 (0x14) > kldstat(20,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/systrace.ko",O_RDONLY,00) =A0 =A0 ERR#2 'No such file > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(20) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 21 (0x15) > kldstat(21,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/systrace_freebsd32.ko",O_RDONLY,00) ERR#2 'No such > file or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(21) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 22 (0x16) > kldstat(22,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/profile.ko",O_RDONLY,00) =A0 =A0 =A0ERR#2 'No such fil= e > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(22) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 23 (0x17) > kldstat(23,0x7fffffffc1d0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D 0 (0x0) > open("/boot/kernel/nullfs.ko",O_RDONLY,00) =A0 =A0 =A0 ERR#2 'No such fil= e > or directory' > close(-1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0ERR#9 'Bad file descriptor' > kldnext(23) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=3D 0 (0x0) > getegid() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0=3D 0 (0x0) > geteuid() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0=3D 0 (0x0) > getgid() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > getpid() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 2786 (0xae2) > getpgid(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 2785 (0xae1) > getppid() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0=3D 2785 (0xae1) > getsid(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0=3D 52367 (0xcc8f) > getuid() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > mmap(0x0,706,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D > 34366447616 (0x800666000) > mprotect(0x800666000,706,PROT_READ) =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0 (0x0= ) > mmap(0x0,730,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D > 34366451712 (0x800667000) > mprotect(0x800667000,730,PROT_READ) =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0 (0x0= ) > munmap(0x800666000,706) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=3D 0 (0x0) > mmap(0x0,480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D > 34366447616 (0x800666000) > mprotect(0x800666000,480,PROT_READ) =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0 (0x0= ) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > ioctl(0,TIOCGETA,0xffffc950) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > ioctl(0,TIOCGETA,0xffffc930) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > stat("/usr/lib/dtrace",{ mode=3Ddrwxr-xr-x > ,inode=3D3457372,size=3D512,blksize=3D32768 }) =3D 0 (0x0) > open("/usr/lib/dtrace",O_NONBLOCK|0x20000,0201020200) =3D 3 (0x3) > fstat(3,{ mode=3Ddrwxr-xr-x ,inode=3D3457372,size=3D512,blksize=3D32768 }= ) =3D 0 (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > fstatfs(0x3,0x7fffffffcd40,0x802001a20,0x607d90,0x607fb0,0xfffff800) =3D = 0 (0x0) > getdirentries(0x3,0x802116000,0x1000,0x802114488,0x607fb0,0xfffffffd) > =3D 512 (0x200) > open("/usr/lib/dtrace/errno.d",O_RDONLY,0666) =A0 =A0=3D 4 (0x4) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(4,{ mode=3D-r--r--r-- ,inode=3D3458159,size=3D6900,blksize=3D32768 = }) =3D 0 (0x0) > read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) =3D 6900 (0x1af4) > read(4,0x802160000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6e0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > madvise(0x8021b8000,0xe000,0x5,0x1b7,0x7,0x7fffffffbef0) =3D 0 (0x0) > close(4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > open("/usr/lib/dtrace/psinfo.d",O_RDONLY,0666) =A0 =3D 4 (0x4) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(4,{ mode=3D-r--r--r-- ,inode=3D3458160,size=3D3186,blksize=3D32768 = }) =3D 0 (0x0) > read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) =3D 3186 (0xc72) > read(4,0x802160000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6e0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > close(4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x8021b8000,0x1000,0x5,0x2940,0x7,0x7fffffffc690) =3D 0 (0x0) > madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x7fffffffc690) =3D 0 (0x0) > open("/usr/lib/dtrace/signal.d",O_RDONLY,0666) =A0 =3D 4 (0x4) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(4,{ mode=3D-r--r--r-- ,inode=3D3458161,size=3D3111,blksize=3D32768 = }) =3D 0 (0x0) > read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) =3D 3111 (0xc27) > read(4,0x802160000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6e0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > close(4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x8021b8000,0x5000,0x5,0x1b7,0x7,0x0) =A0 =A0=3D 0 (0x0) > madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x0) =A0 =A0=3D 0 (0x0) > open("/usr/lib/dtrace/unistd.d",O_RDONLY,0666) =A0 =3D 4 (0x4) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(4,{ mode=3D-r--r--r-- ,inode=3D3458162,size=3D2009,blksize=3D32768 = }) =3D 0 (0x0) > read(4,"/*\n * CDDL HEADER START\n *\n *"...,32768) =3D 2009 (0x7d9) > read(4,0x802160000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6e0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > close(4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x8021b8000,0x1000,0x5,0x2940,0x7,0x7fffffffc690) =3D 0 (0x0) > madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x7fffffffc690) =3D 0 (0x0) > open("/usr/lib/dtrace/regs_x86.d",O_RDONLY,0666) =3D 4 (0x4) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(4,{ mode=3D-r--r--r-- ,inode=3D3458163,size=3D3593,blksize=3D32768 = }) =3D 0 (0x0) > read(4,"/* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"..= .,32768) =3D 3593 (0xe09) > read(4,0x802160000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6e0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > close(4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x8021b8000,0x6000,0x5,0x1b7,0x7,0x0) =A0 =A0=3D 0 (0x0) > madvise(0x802160000,0x8000,0x5,0x15f,0x7,0x0) =A0 =A0=3D 0 (0x0) > getdirentries(0x3,0x802116000,0x1000,0x802114488,0x7fffffffc690,0x7ffffff= fc690) > =3D 0 (0x0) > lseek(3,0x0,SEEK_SET) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=3D 0 (0x0) > close(3) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > open("/usr/lib/dtrace/regs_x86.d",O_RDONLY,0666) =3D 3 (0x3) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(3,{ mode=3D-r--r--r-- ,inode=3D3458163,size=3D3593,blksize=3D32768 = }) =3D 0 (0x0) > read(3,"/* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"..= .,32768) =3D 3593 (0xe09) > read(3,0x80211d000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6b0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > close(3) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x80217e000,0x1000,0x5,0x23d0,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) =3D 0 (0x0) > open("/usr/lib/dtrace/unistd.d",O_RDONLY,0666) =A0 =3D 3 (0x3) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(3,{ mode=3D-r--r--r-- ,inode=3D3458162,size=3D2009,blksize=3D32768 = }) =3D 0 (0x0) > read(3,"/*\n * CDDL HEADER START\n *\n *"...,32768) =3D 2009 (0x7d9) > read(3,0x80211d000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6b0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > close(3) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) =3D 0 (0x0) > open("/usr/lib/dtrace/signal.d",O_RDONLY,0666) =A0 =3D 3 (0x3) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(3,{ mode=3D-r--r--r-- ,inode=3D3458161,size=3D3111,blksize=3D32768 = }) =3D 0 (0x0) > read(3,"/*\n * CDDL HEADER START\n *\n *"...,32768) =3D 3111 (0xc27) > read(3,0x80211d000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > ioctl(0,TIOCGETA,0xffffc6b0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0 (0x0) > close(3) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) =3D 0 (0x0) > open("/usr/lib/dtrace/psinfo.d",O_RDONLY,0666) =A0 =3D 3 (0x3) > sigprocmask(SIG_BLOCK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 = (0x0) > fstat(3,{ mode=3D-r--r--r-- ,inode=3D3458160,size=3D3186,blksize=3D32768 = }) =3D 0 (0x0) > read(3,"/*\n * CDDL HEADER START\n *\n *"...,32768) =3D 3186 (0xc72) > read(3,0x80211d000,32768) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D 0 (0x0) > mmap(0x0,495,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D > 34366455808 (0x800668000) > mprotect(0x800668000,495,PROT_READ) =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0 (0x0= ) > munmap(0x800666000,480) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > mmap(0x0,573,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D > 34366447616 (0x800666000) > mprotect(0x800666000,573,PROT_READ) =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0 (0x0= ) > munmap(0x800668000,495) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=3D 0 (0x0) > close(3) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x80211d000,0x8000,0x5,0x11c,0x7,0xffffffff) =3D 0 (0x0) > dtrace: write(2,"dtrace: ",8) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0=3D 8 (0x8) > invalid probe specifier syscall:::entry { @sc[execname, probefunc] =3D > count(); }write(2,"invalid probe specifier syscall:"...,79) =3D 79 > (0x4f) > : "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t" > write(2,": "/usr/lib/dtrace/psinfo.d", li"...,65) =3D 65 (0x41) > madvise(0x802181000,0x1000,0x5,0x2418,0x7,0x8020019c0) =3D 0 (0x0) > madvise(0x80217d000,0x1000,0x5,0x23b8,0x7,0x8020019c0) =3D 0 (0x0) > madvise(0x80217a000,0x1000,0x5,0x2370,0x7,0x8020019c0) =3D 0 (0x0) > madvise(0x802175000,0x2000,0x5,0x174,0x7,0x8020019c0) =3D 0 (0x0) > madvise(0x80217e000,0x2000,0x5,0x17d,0x7,0x1) =A0 =A0=3D 0 (0x0) > madvise(0x80217b000,0x1000,0x5,0x2388,0x7,0x1) =A0 =3D 0 (0x0) > madvise(0x802177000,0x1000,0x5,0x2328,0x7,0x1) =A0 =3D 0 (0x0) > madvise(0x802115000,0x1000,0x5,0x19f8,0x7,0x1) =A0 =3D 0 (0x0) > madvise(0x80217c000,0x1000,0x5,0x23a0,0x7,0x1) =A0 =3D 0 (0x0) > madvise(0x802178000,0x2000,0x5,0x177,0x7,0x1) =A0 =A0=3D 0 (0x0) > madvise(0x802113000,0x2000,0x5,0x112,0x7,0x1) =A0 =A0=3D 0 (0x0) > munmap(0x800667000,730) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=3D 0 (0x0) > munmap(0x800666000,573) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=3D 0 (0x0) > madvise(0x802180000,0x1000,0x5,0x2400,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x802111000,0x2000,0x5,0x110,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x8020c1000,0x1000,0x5,0x1218,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x802088000,0x1000,0x5,0xcc0,0x7,0xffffffff) =3D 0 (0x0) > close(8) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > close(9) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =3D 0 (0x0) > madvise(0x8020c4000,0x1000,0x5,0x1260,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x8020bd000,0x1000,0x5,0x11b8,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x8020a6000,0x1000,0x5,0xf90,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x802094000,0x1000,0x5,0xde0,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x802085000,0x1000,0x5,0xc78,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x8020c3000,0x1000,0x5,0x1248,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x80209d000,0x2000,0x5,0x9c,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x802086000,0x1000,0x5,0xc90,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x80203f000,0x1000,0x5,0x5e8,0x7,0xffffffff) =3D 0 (0x0) > madvise(0x802084000,0x1000,0x5,0xc60,0x7,0x8020011e0) =3D 0 (0x0) > madvise(0x802040000,0x3000,0x5,0x3f,0x7,0x8020011e0) =3D 0 (0x0) > madvise(0x80203c000,0x1000,0x5,0x5a0,0x7,0x8020011e0) =3D 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > =3D 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 (0= x0) > process exit, rval =3D 1 > > - i can see anything that hinders dtrace to be happy. Any ideas? Thanks. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 17:38:15 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC2A1065670; Thu, 21 Jul 2011 17:38:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9CB8FC13; Thu, 21 Jul 2011 17:38:15 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6LHS5NA029782 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 21 Jul 2011 11:28:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201107201113.52085.jhb@freebsd.org> Date: Thu, 21 Jul 2011 11:27:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4304C061-51AF-4601-9412-86A24D133A99@bsdimp.com> References: <201107201235.p6KCYvmT007475@fire.js.berklix.net> <201107201113.52085.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 21 Jul 2011 11:28:09 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.ORG, "Julian H. Stacey" , hackers@FreeBSD.ORG, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:38:15 -0000 On Jul 20, 2011, at 9:13 AM, John Baldwin wrote: > I think this is a harder problem than you expect. It is not just the = crt files > that matter, but every library. You would need CPU-specific versions = of every > static library on the build system, and possibly you would want to do = this for > all shared libraries too. gcc has support for what it calls multilib. It was originally for MIPS = where there were 3 ABIs that needed to be supported simultaneously (o32, = n32 and n64). However, it is general enough to adapt to your needs, I = think. The harder part is fixing things like the ports and such to that as = well... The medium hard part is fixing buildworld to generate all this = stuff in the right places. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 17:38:15 2011 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC2A1065670; Thu, 21 Jul 2011 17:38:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9CB8FC13; Thu, 21 Jul 2011 17:38:15 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6LHS5NA029782 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 21 Jul 2011 11:28:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201107201113.52085.jhb@freebsd.org> Date: Thu, 21 Jul 2011 11:27:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4304C061-51AF-4601-9412-86A24D133A99@bsdimp.com> References: <201107201235.p6KCYvmT007475@fire.js.berklix.net> <201107201113.52085.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 21 Jul 2011 11:28:09 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.ORG, "Julian H. Stacey" , hackers@FreeBSD.ORG, Dan Nelson Subject: Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:38:15 -0000 On Jul 20, 2011, at 9:13 AM, John Baldwin wrote: > I think this is a harder problem than you expect. It is not just the = crt files > that matter, but every library. You would need CPU-specific versions = of every > static library on the build system, and possibly you would want to do = this for > all shared libraries too. gcc has support for what it calls multilib. It was originally for MIPS = where there were 3 ABIs that needed to be supported simultaneously (o32, = n32 and n64). However, it is general enough to adapt to your needs, I = think. The harder part is fixing things like the ports and such to that as = well... The medium hard part is fixing buildworld to generate all this = stuff in the right places. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 18:11:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A93D106566B; Thu, 21 Jul 2011 18:11:56 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id CCA948FC18; Thu, 21 Jul 2011 18:11:55 +0000 (UTC) Received: by qyk30 with SMTP id 30so3998422qyk.13 for ; Thu, 21 Jul 2011 11:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=73hoMSCnRzI4RLfnzbtF9GdQd93hyev+wRZoQGGoSqk=; b=BP27TX+mDAERZNaXOwmDQXZ8dpFfSwbB0GdX9ubfROjdqEkH09qxIWellJ/oaTGt7I pBZ2T7zg8Z+KArO6iliNYECehROAGxV9bZfQ9koJ5czRgtD0D1a6ovakEaNmCVHERReR kric2/PcDROt/NDnI3xR5k/QGCvVJ+tvhU6Sw= MIME-Version: 1.0 Received: by 10.229.61.151 with SMTP id t23mr495069qch.245.1311271915099; Thu, 21 Jul 2011 11:11:55 -0700 (PDT) Received: by 10.229.219.19 with HTTP; Thu, 21 Jul 2011 11:11:54 -0700 (PDT) In-Reply-To: <20110721174725.GG1202@home.opsec.eu> References: <20110721174725.GG1202@home.opsec.eu> Date: Thu, 21 Jul 2011 22:11:54 +0400 Message-ID: From: Subbsd To: Kurt Jaeger Content-Type: text/plain; charset=ISO-8859-1 Cc: Artem Belevich , freebsd-jail , freebsd-hackers Subject: Re: userland dtrace tools not working in jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 18:11:56 -0000 Hi On 7/21/11, Kurt Jaeger wrote: > Hi! > >> > I try to use dtrace in jail on FreeBSD-9-64. > [...] >> > open("/boot/kernel/kernel",O_RDONLY,00) ERR#2 'No such file >> > or directory' >> >> Here's your problem ^^^. >> >> dtrace extracts CTF information from the binaries. In case of kernel >> probes, that would be the kernel itself and loadable modules. All that >> stuff lives in /boot and is not accessible from your jail. > > If he copied /boot to the jail, would it work ? Yes! Artem Belevich was right! Copy of my /boot to jail solve my problem. Thanks you, all! May be necessary to document this moment? > > -- > pi@opsec.eu +49 171 3101372 9 years to go > ! > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 17:47:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BCCC106566C; Thu, 21 Jul 2011 17:47:25 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id F307A8FC15; Thu, 21 Jul 2011 17:47:24 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QjxLJ-000Krh-9W; Thu, 21 Jul 2011 19:47:25 +0200 Date: Thu, 21 Jul 2011 19:47:25 +0200 From: Kurt Jaeger To: Artem Belevich Message-ID: <20110721174725.GG1202@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailman-Approved-At: Thu, 21 Jul 2011 18:23:33 +0000 Cc: freebsd-hackers , freebsd-jail , Subbsd Subject: Re: userland dtrace tools not working in jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:47:25 -0000 Hi! > > I try to use dtrace in jail on FreeBSD-9-64. [...] > > open("/boot/kernel/kernel",O_RDONLY,00)          ERR#2 'No such file > > or directory' > > Here's your problem ^^^. > > dtrace extracts CTF information from the binaries. In case of kernel > probes, that would be the kernel itself and loadable modules. All that > stuff lives in /boot and is not accessible from your jail. If he copied /boot to the jail, would it work ? -- pi@opsec.eu +49 171 3101372 9 years to go ! From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 06:28:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A197106564A; Fri, 22 Jul 2011 06:28:54 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1431B8FC13; Fri, 22 Jul 2011 06:28:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=0JzVxuJQaoa/jSAWGlvjyr3BxaAxrzKqb8kFCLe+lsc=; b=fk5IFiFSbs6pANztcWC5Et0wulinLgbGnnKC95F5QgJLq0ScpkG9R1/AR9a9qeXNXnslVml2Fs4w3ye/RbwGmWr0++XpOAsGJbfGUa+jwQvpJIltcZOjudN0Ccw2i8ZGlvtzTEKQr2CkB+jEXxO6HRWUu76Na7vfF7y3jAof4bEMjnAKMZaQw5hhldUQ6cbNXE4ikRLVU6IovGJLoWbOch2YOTeYdZOlq8PeIea+triGhArled/Q8FbJIjlzs/f2sfsO+3fO3BWj+0v0VM55fwO2UB2wOwyzsoEDB1PFttfFKfRU6LHoTV0zZtV/CYQOts+vs4ss5Tvwe+Qt9QFxIw==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Qk9EC-000AqV-A2; Fri, 22 Jul 2011 10:28:52 +0400 Date: Fri, 22 Jul 2011 10:28:50 +0400 From: Eygene Ryabinkin To: Daniel Braniss Message-ID: References: <20110718203215.GM54929@MacBook-Eygene-Ryabinkin.local> <20110719172455.GP54929@MacBook-Eygene-Ryabinkin.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: Sender: rea@codelabs.ru Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: broadcast oddity X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 06:28:54 -0000 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Wed, Jul 20, 2011 at 12:34:38PM +0300, Daniel Braniss wrote: > from the diskless: > els-01# ifconfig > vr0: flags=3D8843 metric 0 mtu 15= 00 > options=3D8280b > ether 00:0d:b9:22:57:18 > inet 132.65.91.1 netmask 0xfffff000 broadcast 132.65.95.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D3 > inet 127.0.0.1 netmask 0xff000000=20 > els-01# netstat -rn > Routing tables >=20 > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 132.65.80.1 UG 0 16606 vr0 > 127.0.0.1 link#4 UH 0 36 lo0 > 132.65.80.0/20 link#1 U 0 86612 vr0 > 132.65.91.1 link#1 UHS 0 12 lo0 >=20 > from the non-diskless: > wrap-1# ifconfig > sis0: flags=3D8943 metric= 0 mtu=20 > 1500 > options=3D83808 > ether 00:0d:b9:00:72:a8 > inet 132.65.80.181 netmask 0xfffff000 broadcast 132.65.95.255 > media: Ethernet autoselect (100baseTX ) > status: active > sis1: flags=3D8802 metric 0 mtu 1500 > options=3D83808 > ether 00:0d:b9:00:72:a9 > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D3 > inet 127.0.0.1 netmask 0xff000000=20 >=20 > wrap-1# netstat -rn > Routing tables >=20 > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 132.65.80.1 UGS 0 16936 sis0 > 127.0.0.1 link#4 UH 0 76 lo0 > 132.65.80.0/20 link#1 U 0 67433 sis0 > 132.65.80.181 link#1 UHS 0 0 lo0 The only difference I see is the absence of the 'S' flag on the default route for the diskless case. Will try to create the testbed. > > Yes, it is. But ip_output.c has the following code, > > {{{ > > if (rte->rt_flags & RTF_GATEWAY) > > dst =3D3D (struct sockaddr_in *)rte->rt_gateway; > > if (rte->rt_flags & RTF_HOST) > > isbroadcast =3D3D (rte->rt_flags & RTF_BROADCAS= T); > > else > > isbroadcast =3D3D in_broadcast(dst->sin_addr, i= fp); > > }}} > >=20 > > So, if the route that is selected is the gateway, then there will be > > no broadcast on the L2. At least in my understanding of the code. > > Thus, I am interested in the routing tables and route flags. >=20 > so it boils down to a problem in selecting the route? More-or-less so: for default gateways there will never be any L2-broadcasts, for host routes the L2-broadcasts are governed by the 'B' route flag and for other routes the destination address governs the behaviour (INADDR_ANY & INADDR_BROADCAST as the destination will enable L2-broadcast unconditionally /but most likely we will hit the default route earlier for this case/, interface broadcast address /132.65.95.255 in your case/ will enable L2-brodcast via the corresponding interface). --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk4pGKIACgkQFq+eroFS7Pu6QAD+JAIkX+Rv5wNg4mFn3+nh9ost FXzLZwEAjbdAiLqWAn0A/iyXAYHFpLK5DE5RfQCrSxcFojKaOkotKazyrncZpvU+ =b8c0 -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 16:13:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC9DE1065675 for ; Fri, 22 Jul 2011 16:13:39 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5206F8FC15 for ; Fri, 22 Jul 2011 16:13:39 +0000 (UTC) Received: by wwe6 with SMTP id 6so2309240wwe.31 for ; Fri, 22 Jul 2011 09:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:from:content-type:subject:date:message-id:to:mime-version :x-mailer; bh=WpwY6MGr9D0AzysOevzk55fkBa20q2Df48HpPy1m/X4=; b=VyHUrl79AXUGcdTj6ft/qvZHfIkMDZZRzKhIs2d5eVV7ToSMBwnMuXMMp60epoGLAF GErHmnHg2EOvvVKEhaGrYdf3Eke6db6DgjwaPwUAi5T4UWrVlA9hzzZ9X4+UOKO5t9Fc RFN95rDuIBMPtFKNgvjj0J4upPQvAbYSNRQls= Received: by 10.216.235.133 with SMTP id u5mr1883299weq.101.1311349893254; Fri, 22 Jul 2011 08:51:33 -0700 (PDT) Received: from [192.168.1.102] (45.81.datacomsa.pl [195.34.81.45]) by mx.google.com with ESMTPS id a63sm1632683wed.8.2011.07.22.08.51.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 08:51:32 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Date: Fri, 22 Jul 2011 17:51:28 +0200 Message-Id: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:13:39 -0000 Patch below changes ps(1) to automatically size column widths according = to their contents. =46rom the user point of view, it prevents breaking layout = with too wide values and in most cases makes output narrower. =46rom the developer point of = view, it removes the need to specify widths. Testing is welcome - the patch shouldn't = change ps(1) behaviour except slightly changing the widths, but the code changes are = pretty large and it's quite possible I've missed something. http://people.freebsd.org/~trasz/ps-8.diff -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 17:49:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7862F1065672 for ; Fri, 22 Jul 2011 17:49:32 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 02BC38FC17 for ; Fri, 22 Jul 2011 17:49:31 +0000 (UTC) Received: by wyg24 with SMTP id 24so2191994wyg.13 for ; Fri, 22 Jul 2011 10:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=G4E+EfJRXbOJcF6qtJetpyBCaLkIe1NtYZHVlg8LTkE=; b=b3ddvDX7z5khABzVhGRhXR/QFOmQXHqdpiED03IJqcn3wig+TJHYfQGEKlBm4jVr0D 9FsXZbu6f4UTSKBjM1YgiTEYkUGLw1L17+eWyvLSMl7RSUtlkIlPJAQoL5OenHoL2Y4T A/65z7q83MYQL7p5vGsbQE+rIWwreMgD95wK0= Received: by 10.227.197.194 with SMTP id el2mr1492085wbb.55.1311355281836; Fri, 22 Jul 2011 10:21:21 -0700 (PDT) Received: from localhost ([72.46.129.46]) by mx.google.com with ESMTPS id b13sm2071095wbh.41.2011.07.22.10.21.20 (version=SSLv3 cipher=OTHER); Fri, 22 Jul 2011 10:21:21 -0700 (PDT) From: Test Rat To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> Date: Fri, 22 Jul 2011 21:21:13 +0400 In-Reply-To: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> ("Edward Tomasz =?utf-8?Q?Napiera=C5=82a=22's?= message of "Fri, 22 Jul 2011 17:51:28 +0200") Message-ID: <86hb6e1bau.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 22 Jul 2011 18:02:09 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:49:32 -0000 Edward Tomasz Napiera=C5=82a writes: > Patch below changes ps(1) to automatically size column widths according t= o their > contents. From the user point of view, it prevents breaking layout with = too wide values > and in most cases makes output narrower. From the developer point of vie= w, it removes > the need to specify widths. Testing is welcome - the patch shouldn't cha= nge ps(1) > behaviour except slightly changing the widths, but the code changes are p= retty large > and it's quite possible I've missed something. STAT column seems to be right-aligned when it was previously left-aligned. This makes sorting it harder, e.g. $ ps ax | (IFS=3D; read h; echo $h; sort -k3) | less From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 21:22:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D02521065673 for ; Fri, 22 Jul 2011 21:22:43 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 975A98FC15 for ; Fri, 22 Jul 2011 21:22:43 +0000 (UTC) Received: by gwb15 with SMTP id 15so2270035gwb.13 for ; Fri, 22 Jul 2011 14:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=B2R+azWvDZegosolU8HC16eZtc9Q9NUGADWhEuYpbH0=; b=jHm6oQVHehDc45YKxGJhQ3Bx4bhrrRcYCfoFdkDtaP4HrTm9TJGlxAWJss1hgX7Xeq C4/q2XGhv0P/AN2L6Mpr74q2F6BtRLFT8MMoWvcCrgksx+aGnEGaEVHhfXYkjjd49a9e c1h/DRhFMREznbSaHjZFHt3GiQTBK4Eg4jD10= MIME-Version: 1.0 Received: by 10.142.120.1 with SMTP id s1mr1078816wfc.252.1311369762553; Fri, 22 Jul 2011 14:22:42 -0700 (PDT) Received: by 10.142.201.1 with HTTP; Fri, 22 Jul 2011 14:22:42 -0700 (PDT) Date: Fri, 22 Jul 2011 17:22:42 -0400 Message-ID: From: grarpamp To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 22 Jul 2011 22:39:24 +0000 Cc: Subject: Silicon Image programming docs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:22:43 -0000 Found some datasheets (programming docs) and board schematics for Silicon Image storage controllers. Since they don't seem to be publicly available, perhaps some of these docs will be useful. Bcc'd relevant fs and hackers lists. Reply to hardware I guess. # Overview http://www.siliconimage.com/products/family.aspx?id=3 http://www.siliconimage.com/docs/Site_PDFs/Product_Guide_3Q_2011.pdf # SiI0680 http://www.siliconimage.com/docs/SiI-DS-0069-C.pdf http://www.siliconimage.com/docs/SiI-SC-0094-A.PDF # SiI3114 http://www.siliconimage.com/docs/SiI-DS-0103-D.pdf http://www.siliconimage.com/docs/SiI-SC-0057-B.PDF # SiI3124 http://www.siliconimage.com/docs/SiI-DS-0160-C.pdf http://www.siliconimage.com/docs/312404_B00_092704.PDF # SiI3132 http://www.siliconimage.com/docs/SiI-DS-0136-B.pdf http://www.siliconimage.com/docs/SiI-DS-0138-E.pdf http://www.siliconimage.com/docs/SiI-SC-0097_doc.pdf # SiI3512 http://www.siliconimage.com/docs/SiI-DS-0102-D.pdf http://www.siliconimage.com/docs/SiI-DS-0107-C.pdf http://www.siliconimage.com/docs/SiI-SC-0056-B.PDF # SiI3531 http://www.siliconimage.com/docs/SiI-DS-0208-C.pdf http://www.siliconimage.com/docs/SiI-SC-215.PDF # SiI3726 http://www.siliconimage.com/docs/FINAL%20SiI3726%20Product%20Brief_02-16-2011.pdf http://www.siliconimage.com/docs/SiI-DS-0121-C1.pdf # SiI3811 http://www.siliconimage.com/docs/SiI3811_PB58_FINAL_8-17-06.pdf http://www.siliconimage.com/docs/SiI-SC-0231-A.PDF From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 02:31:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1E96106564A for ; Sat, 23 Jul 2011 02:31:19 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A34088FC08 for ; Sat, 23 Jul 2011 02:31:19 +0000 (UTC) Received: by iyb11 with SMTP id 11so3262839iyb.13 for ; Fri, 22 Jul 2011 19:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=WHypVBGubqP0b/jedWTg+FLOrQGIAWEYdtkBagGBbm4=; b=O1Od69rDIa/eNI4Yb/WCFM37go6Rxp1JqfPWx+GUR9W95hnIjE2+2TiGcW1y5L6CbO D79N9dfO7rw6NLiyvSKUAnBNWAbKaC5Lel6nweuYLVrIWg6nSmFC9kjeuh902bR4I6cS cQ4Ni5oBq/kKdVSl2lDBM+x/dD9th7QfkveJo= MIME-Version: 1.0 Received: by 10.142.223.3 with SMTP id v3mr1219466wfg.289.1311386839612; Fri, 22 Jul 2011 19:07:19 -0700 (PDT) Received: by 10.142.199.13 with HTTP; Fri, 22 Jul 2011 19:07:19 -0700 (PDT) Date: Sat, 23 Jul 2011 04:07:19 +0200 Message-ID: From: Davide Italiano To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: UMA large allocations issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 02:31:19 -0000 Hi. I'm a student and some time ago I started investigating a bit about the performance/fragmentation issue of large allocations within the UMA allocator. Benckmarks showed up that this problems of performances are mainly related to the fact that every call to uma_large_malloc() results in a call to kmem_malloc(), and this behaviour is really inefficient. I started doing some work. Here's somethin: First of all, I tried to define larger zones and let uma do it all as a first step. UMA can allocate slabs of more than one page. So I tried to define zones of 1,2,4,8 pages, moving ZMEM_KMAX up. I tested the solution w/ raidtest. Here there are some numbers. Here's the workload characterization: set mediasize=`diskinfo /dev/zvol/tank/vol | awk '{print $3}'` set sectorsize=`diskinfo /dev/zvol/tank/vol | awk '{print $2}'` raidtest genfile -s $mediasize -S $sectorsize -n 50000 # $mediasize = 10737418240 # $sectorsize = 512 Number of READ requests: 24924 Number of WRITE requests: 25076 Numbers of bytes to transmit: 3305292800 raidtest test -d /dev/zvol/tank/vol -n 4 ## tested using 4 cores, 1.5 GB Ram Results: Number of processes: 4 Bytes per second: 10146896 Requests per second: 153 Results: (4* PAGE_SIZE) Number of processes: 4 Bytes per second: 14793969 Requests per second: 223 Results: (8* PAGE_SIZE) Number of processes: 4 Bytes per second: 6855779 Requests per second: 103 The result of this tests is that defining larger zones is useful until the size of these zones is not too big. After some size, performances decreases significantly. As second step, alc@ proposed to create a new layer that sits between UMA and the VM subsystem. This layer can manage a pool of chunk that can be used to satisfy requests from uma_large_malloc so avoiding the overhead due to kmem_malloc() calls. I've recently started developing a patch (not yet full working) that implements this layer. First of all I'd like to concentrate my attention to the performance problem rather than the fragmentation one. So the patch that actually started to write doesn't care about fragmentation aspects. http://davit.altervista.org/uma_large_allocations.patch There are some questions to which I wasn't able to answer (for example, when it's safe to call kmem_malloc() to request memory). So, at the end of the day I'm asking for your opinion about this issue and I'm looking for a "mentor" (some kind of guidance) to continue this project. If someone is interested to help, it would be very appreciated. Best Davide Italiano From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 03:28:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C115B1065670 for ; Sat, 23 Jul 2011 03:28:11 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id ACEB68FC0A for ; Sat, 23 Jul 2011 03:28:11 +0000 (UTC) Received: from mail1.rawbw.com (mail1.rawbw.com [198.144.192.43]) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p6N3SBPK029892; Fri, 22 Jul 2011 20:28:11 -0700 (PDT) (envelope-from yuri@rawbw.com) Received: from 74-95-207-98-SFBA.hfc.comcastbusiness.net (74-95-207-98-SFBA.hfc.comcastbusiness.net [74.95.207.98]) by newwebmail.rawbw.com (Horde Framework) with HTTP; Fri, 22 Jul 2011 20:28:11 -0700 Message-ID: <20110722202811.17302hol2s3ar084@newwebmail.rawbw.com> Date: Fri, 22 Jul 2011 20:28:11 -0700 From: Yuri To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2.1-RC1) Subject: DTrace script asserts and kills the other process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 03:28:11 -0000 I am trying to run this dtrace script: #!/usr/sbin/dtrace -s pid123:libc::entry { self->timestmp[probefunc] = timestmp; } pid123:libc::return /self->timestmp[probefunc] != 0/ { @function_duration[probefunc] = sum(timestmp - self->timestmp[probefunc]); timestmp[probefunc] = 0; } which I got from here: http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html replacing 123 with the pid of some running process. Result: dtrace utility asserts: Assertion failed: (dpr != NULL), file /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, line 751. Abort trap: 6 Also the target process is killed too: Killed: 9 8.2-STABLE amd64 Yuri From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 12:08:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24C17106564A for ; Sat, 23 Jul 2011 12:08:47 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by mx1.freebsd.org (Postfix) with ESMTP id D815D8FC1B for ; Sat, 23 Jul 2011 12:08:46 +0000 (UTC) Received: from [78.34.168.76] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1QkaqV-0003Qo-H8; Sat, 23 Jul 2011 13:58:15 +0200 Date: Sat, 23 Jul 2011 13:56:55 +0200 From: Fabian Keil To: Yuri Message-ID: <20110723135655.4479d190@fabiankeil.de> In-Reply-To: <20110722202811.17302hol2s3ar084@newwebmail.rawbw.com> References: <20110722202811.17302hol2s3ar084@newwebmail.rawbw.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/La3w/NOhAik5nd.B9i5=6FC"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace script asserts and kills the other process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 12:08:47 -0000 --Sig_/La3w/NOhAik5nd.B9i5=6FC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yuri wrote: > I am trying to run this dtrace script: >=20 > #!/usr/sbin/dtrace -s > pid123:libc::entry > { > self->timestmp[probefunc] =3D timestmp; > } > pid123:libc::return > /self->timestmp[probefunc] !=3D 0/ > { > @function_duration[probefunc] =3D sum(timestmp - > self->timestmp[probefunc]); timestmp[probefunc] =3D 0; > } >=20 > which I got from here: =20 > http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html > replacing 123 with the pid of some running process. >=20 > Result: dtrace utility asserts: > Assertion failed: (dpr !=3D NULL), file =20 > /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtra= ce/common/dt_proc.c, > line 751. > Abort trap: 6 >=20 > Also the target process is killed too: > Killed: 9 >=20 > 8.2-STABLE amd64 This is a known issue. You may be able to work around it by letting dtrace start the traced process. There's already a PR about it: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/158431 but the limitation isn't mentioned in the wiki: http://wiki.freebsd.org/DTrace/userland It's not clear to me if this has worked in the past or if it works for other architectures (the reporter and I are both using amd64, too). Fabian --Sig_/La3w/NOhAik5nd.B9i5=6FC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4qtwkACgkQBYqIVf93VJ2jDQCgn7hufjUgcKelrwWUxPujOswH nagAoMwD1X9mpR14L9TG72YO7ox9hFtS =ljLh -----END PGP SIGNATURE----- --Sig_/La3w/NOhAik5nd.B9i5=6FC-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 17:50:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A6D21065670 for ; Sat, 23 Jul 2011 17:50:53 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 167698FC14 for ; Sat, 23 Jul 2011 17:50:52 +0000 (UTC) Received: by iyb11 with SMTP id 11so4127859iyb.13 for ; Sat, 23 Jul 2011 10:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TJ7pWGtWsN+I641o5kkE6LgucZ8en46uNETtcx7cqqE=; b=QwxGBbO73xoYXL95r3i8Vdh4mS1npDJyPpTM8R01lYCEPPhyYkLW+MVTDxpO7N2IEa KPRnbVgl/UNjdGQQVvDcCPkuZ2HKZQfO0/q1BIC2R4lBF2IZvQy3rcEjl+U7x9Fo/qGX NcJi93YZxvimNykdY6PBzCPeqC/j3ZMGHUu/I= MIME-Version: 1.0 Received: by 10.231.26.87 with SMTP id d23mr2767141ibc.18.1311441971035; Sat, 23 Jul 2011 10:26:11 -0700 (PDT) Received: by 10.231.191.77 with HTTP; Sat, 23 Jul 2011 10:26:10 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Jul 2011 12:26:11 -0500 Message-ID: From: Alan Cox To: Davide Italiano Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: UMA large allocations issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 17:50:53 -0000 On Fri, Jul 22, 2011 at 9:07 PM, Davide Italiano wrote: > Hi. > I'm a student and some time ago I started investigating a bit about > the performance/fragmentation issue of large allocations within the > UMA allocator. > Benckmarks showed up that this problems of performances are mainly > related to the fact that every call to uma_large_malloc() results in a > call to kmem_malloc(), and this behaviour is really inefficient. > > I started doing some work. Here's somethin: > First of all, I tried to define larger zones and let uma do it all as > a first step. > UMA can allocate slabs of more than one page. So I tried to define > zones of 1,2,4,8 pages, moving ZMEM_KMAX up. > I tested the solution w/ raidtest. Here there are some numbers. > > Here's the workload characterization: > > > set mediasize=`diskinfo /dev/zvol/tank/vol | awk '{print $3}'` > set sectorsize=`diskinfo /dev/zvol/tank/vol | awk '{print $2}'` > raidtest genfile -s $mediasize -S $sectorsize -n 50000 > > # $mediasize = 10737418240 > # $sectorsize = 512 > > Number of READ requests: 24924 > Number of WRITE requests: 25076 > Numbers of bytes to transmit: 3305292800 > > > raidtest test -d /dev/zvol/tank/vol -n 4 > ## tested using 4 cores, 1.5 GB Ram > > Results: > Number of processes: 4 > Bytes per second: 10146896 > Requests per second: 153 > > Results: (4* PAGE_SIZE) > Number of processes: 4 > Bytes per second: 14793969 > Requests per second: 223 > > Results: (8* PAGE_SIZE) > Number of processes: 4 > Bytes per second: 6855779 > Requests per second: 103 > > > The result of this tests is that defining larger zones is useful until > the size of these zones is not too big. After some size, performances > decreases significantly. > > As second step, alc@ proposed to create a new layer that sits between > UMA and the VM subsystem. This layer can manage a pool of chunk that > can be used to satisfy requests from uma_large_malloc so avoiding the > overhead due to kmem_malloc() calls. > > I've recently started developing a patch (not yet full working) that > implements this layer. First of all I'd like to concentrate my > attention to the performance problem rather than the fragmentation > one. So the patch that actually started to write doesn't care about > fragmentation aspects. > > http://davit.altervista.org/uma_large_allocations.patch > > There are some questions to which I wasn't able to answer (for > example, when it's safe to call kmem_malloc() to request memory). > > In this context, there is really only one restriction. Your page_alloc_new() should never call kmem_malloc() with M_WAITOK if your bitmap_mtx lock is held. It may only call kmem_malloc() with M_NOWAIT if your bitmap_mtx lock is held. That said, I would try to structure the code so that you're not doing any kmem_malloc() calls with the bitmap_mtx lock held. So, at the end of the day I'm asking for your opinion about this issue > and I'm looking for a "mentor" (some kind of guidance) to continue > this project. If someone is interested to help, it would be very > appreciated. > > I will take a closer look at your patch later today, and send you comments. Alan