From owner-freebsd-arm@FreeBSD.ORG Sun Apr 5 01:52:46 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC854466 for ; Sun, 5 Apr 2015 01:52:46 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BA430337 for ; Sun, 5 Apr 2015 01:52:46 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t351qjVl082485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 4 Apr 2015 18:52:45 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t351qjoK082484 for freebsd-arm@FreeBSD.org; Sat, 4 Apr 2015 18:52:45 -0700 (PDT) (envelope-from jmg) Date: Sat, 4 Apr 2015 18:52:45 -0700 From: John-Mark Gurney To: freebsd-arm@FreeBSD.org Subject: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150405015245.GO51048@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 04 Apr 2015 18:52:45 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 01:52:46 -0000 I would like to remove this file as it does not implement our defined memcpy. Per POSIX, overlapping regions passed to memcpy is undefined behavior. We have defined it to have the same symatics as memmove. Sample test program: #include #include char bufa[512] = "this is a test buffer that should be copied fine."; int main() { memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); printf("%s\n", bufa); return 0; } Output on amd64 HEAD: this is a this is a test buffer that should be co Output on old armv4 from 9.x: this is a this is a thst buffethst bufhould beufh If you just look at the file, it is clear that the implementation does not adjust the copy direction based upon pointers. We imported the code from NetBSD, and NetBSD does apparently require memcpy's arguments to be non-overlapping. I'll remove the file shortly unless someone can prove to me that all uses of memcpy in our tree do not depend upon our defined behavior per memcpy(3)'s man page. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 15:58:59 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78F34771 for ; Mon, 6 Apr 2015 15:58:59 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D11FB65 for ; Mon, 6 Apr 2015 15:58:58 +0000 (UTC) Received: by igblo3 with SMTP id lo3so24437173igb.1 for ; Mon, 06 Apr 2015 08:58:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=dRCvRIGLfzS2BQEZk/QAtfj1OulmdYLclPpXtwERAC0=; b=SUj8AxUtrEZ+YQjee6Z5t23v2sBF1U6XnsshmldNyBkRDX0nc4/EKf03FFbWT6enFq wQO9EobUZPqmFJjB1RHwQfK9uFa+9tRmCkLMktvGaHIv4b11iT7sMFxtUyY708G/UuFF Jv5xd3FKx0phpbhhVoUX0LNiqIn8rKStAMmG1PlQ5420nvm/AhUaAQmuEG3oX5CMgrpN oTsEBX6Ce+qIelMz2tJ/K9Pzo5KC5iC/0AFLJpsD5cXq9m0486W8USMXg21B4+hA6U25 bNUd70vnI6o6JfW9QFu02QXS1p/Gg452DpW2WxK+E7z7GfS3R8+Gy5FK1PgByp8WaghS L2QQ== X-Gm-Message-State: ALoCoQkD7gWGAKpKQuWgfgSYSn4RGxt6b89BNTXYqUzdLOXF0ZHCNqx4q6eFyaVqwBfaeAukUbq/ X-Received: by 10.107.160.212 with SMTP id j203mr23916389ioe.43.1428335931985; Mon, 06 Apr 2015 08:58:51 -0700 (PDT) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id ig15sm2967838igb.10.2015.04.06.08.58.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 08:58:51 -0700 (PDT) Sender: Warner Losh Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1D3B8A86-5E90-43C0-A0C4-B0FC86FC3A39"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: <20150405015245.GO51048@funkthat.com> Date: Mon, 6 Apr 2015 09:58:49 -0600 Message-Id: References: <20150405015245.GO51048@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 15:58:59 -0000 --Apple-Mail=_1D3B8A86-5E90-43C0-A0C4-B0FC86FC3A39 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > I would like to remove this file as it does not implement our defined > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > behavior. We have defined it to have the same symatics as memmove. > > Sample test program: > #include > #include > > char bufa[512] = "this is a test buffer that should be copied fine."; > int > main() > { > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > printf("%s\n", bufa); > > return 0; > } > > Output on amd64 HEAD: > this is a this is a test buffer that should be co > > Output on old armv4 from 9.x: > this is a this is a thst buffethst bufhould beufh > > If you just look at the file, it is clear that the implementation does > not adjust the copy direction based upon pointers. We imported the > code from NetBSD, and NetBSD does apparently require memcpy's arguments > to be non-overlapping. > > I'll remove the file shortly unless someone can prove to me that all > uses of memcpy in our tree do not depend upon our defined behavior > per memcpy(3)'s man page. Any chance you can fix this implementation instead? Warner --Apple-Mail=_1D3B8A86-5E90-43C0-A0C4-B0FC86FC3A39 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVIq05AAoJEGwc0Sh9sBEAU54P/AlgpT9pDJxoZ5vK9JcB3Z45 1vfz0Vyr2OpfnXCU4A8W48sECy9OphGRoz0afGcEsZjAiRZk1JyBLgTjktAEoqAL VfOMffmzmMRl2tJCkWDkveXiXp26k8PYY0y0hAd1TXuG8eHX21kXlPvGOtx7NxSn 9hBfMewIGGNlRUu/SK49AsyW9+wdNKR6hjCZWqnbGrAElXOJxsZ884gEG676Q33I 12A8rRvDPYznCsUePIS3TXFvTeQUcARZ+m6KOV3DOyvaU5qoL/ovpMufMEF8IF25 zDRBFsfCJyujDfNhLdB9x95LlEIVrw1F8rRVmncHjeM1vCP+FBh+molhgCmy9Nyw k9b1NV17yYEQKOMmfXOEqieBA3fh2d96nCqnBNhzfozkHluss0DwwCzOKPeWqweY 6YAqrvWKo1X6vSZ5haESbiSkd+u+6axW0Q+sEhuElLdxBBTY1C6wwSd5zXnvtm2B qExEF1gLhiTRKMGRVam95APGMIaqO3kuU6A8YByH/bC1u62wt8fRuNuX2F+XT9lN LTyNyXCekCC631mA885trPtUVtzMmO3NcchgRDecwUi6VRyG0WoLn2nGnBXETQ7q +ZSBPwC7LjgWtDl2ejG+zOSf+v9+X/KBWcilnvWuLIkEx5V0YD7FFgKSoyjQVKQs w+CDqsANvfrZJ+GPLUI4 =GKgz -----END PGP SIGNATURE----- --Apple-Mail=_1D3B8A86-5E90-43C0-A0C4-B0FC86FC3A39-- From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 17:12:51 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E04AB1E8 for ; Mon, 6 Apr 2015 17:12:51 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A289C67F for ; Mon, 6 Apr 2015 17:12:51 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t36HCmg9007452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 10:12:48 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t36HCmB9007451; Mon, 6 Apr 2015 10:12:48 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Apr 2015 10:12:48 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406171248.GV51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 06 Apr 2015 10:12:49 -0700 (PDT) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 17:12:52 -0000 Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > I would like to remove this file as it does not implement our defined > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > behavior. We have defined it to have the same symatics as memmove. > > > > Sample test program: > > #include > > #include > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > int > > main() > > { > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > printf("%s\n", bufa); > > > > return 0; > > } > > > > Output on amd64 HEAD: > > this is a this is a test buffer that should be co > > > > Output on old armv4 from 9.x: > > this is a this is a thst buffethst bufhould beufh > > > > If you just look at the file, it is clear that the implementation does > > not adjust the copy direction based upon pointers. We imported the > > code from NetBSD, and NetBSD does apparently require memcpy's arguments > > to be non-overlapping. > > > > I'll remove the file shortly unless someone can prove to me that all > > uses of memcpy in our tree do not depend upon our defined behavior > > per memcpy(3)'s man page. > > Any chance you can fix this implementation instead? I don't know arm assembly well enough, nor do I have the time to fix it.. I am willing to test any implementations as I have access to hardware... I guess I should add a test to verify that memcpy behavese like memmove to our test suite... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 17:41:48 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53F08C8E for ; Mon, 6 Apr 2015 17:41:48 +0000 (UTC) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE4A69FC for ; Mon, 6 Apr 2015 17:41:47 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.8/8.14.8) with ESMTP id t36HfUD1063541; Mon, 6 Apr 2015 19:41:30 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.8/8.14.8/Submit) id t36HfUgJ063540; Mon, 6 Apr 2015 19:41:30 +0200 (CEST) (envelope-from mlfbsd) Date: Mon, 6 Apr 2015 19:41:30 +0200 From: Olivier Houchard To: John-Mark Gurney Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406174130.GA63423@ci0.org> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150406171248.GV51048@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 17:41:48 -0000 On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > > > I would like to remove this file as it does not implement our defined > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > > behavior. We have defined it to have the same symatics as memmove. > > > > > > Sample test program: > > > #include > > > #include > > > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > > int > > > main() > > > { > > > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > > printf("%s\n", bufa); > > > > > > return 0; > > > } > > > > > > Output on amd64 HEAD: > > > this is a this is a test buffer that should be co > > > > > > Output on old armv4 from 9.x: > > > this is a this is a thst buffethst bufhould beufh > > > > > > If you just look at the file, it is clear that the implementation does > > > not adjust the copy direction based upon pointers. We imported the > > > code from NetBSD, and NetBSD does apparently require memcpy's arguments > > > to be non-overlapping. > > > > > > I'll remove the file shortly unless someone can prove to me that all > > > uses of memcpy in our tree do not depend upon our defined behavior > > > per memcpy(3)'s man page. > > > > Any chance you can fix this implementation instead? > > I don't know arm assembly well enough, nor do I have the time to fix > it.. I am willing to test any implementations as I have access to > hardware... > > I guess I should add a test to verify that memcpy behavese like memmove > to our test suite... > I think the bug is in the manpage, not the code, and we should fix it the way NetBSD did. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 19:09:16 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F29F6936 for ; Mon, 6 Apr 2015 19:09:15 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C33C868F for ; Mon, 6 Apr 2015 19:09:15 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t36J91RY008691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 12:09:01 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t36J918t008690; Mon, 6 Apr 2015 12:09:01 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Apr 2015 12:09:01 -0700 From: John-Mark Gurney To: Olivier Houchard Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406190901.GW51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150406174130.GA63423@ci0.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 06 Apr 2015 12:09:01 -0700 (PDT) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 19:09:16 -0000 Olivier Houchard wrote this message on Mon, Apr 06, 2015 at 19:41 +0200: > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > > > > > I would like to remove this file as it does not implement our defined > > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > > > behavior. We have defined it to have the same symatics as memmove. > > > > > > > > Sample test program: > > > > #include > > > > #include > > > > > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > > > int > > > > main() > > > > { > > > > > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > > > printf("%s\n", bufa); > > > > > > > > return 0; > > > > } > > > > > > > > Output on amd64 HEAD: > > > > this is a this is a test buffer that should be co > > > > > > > > Output on old armv4 from 9.x: > > > > this is a this is a thst buffethst bufhould beufh > > > > > > > > If you just look at the file, it is clear that the implementation does > > > > not adjust the copy direction based upon pointers. We imported the > > > > code from NetBSD, and NetBSD does apparently require memcpy's arguments > > > > to be non-overlapping. > > > > > > > > I'll remove the file shortly unless someone can prove to me that all > > > > uses of memcpy in our tree do not depend upon our defined behavior > > > > per memcpy(3)'s man page. > > > > > > Any chance you can fix this implementation instead? > > > > I don't know arm assembly well enough, nor do I have the time to fix > > it.. I am willing to test any implementations as I have access to > > hardware... > > > > I guess I should add a test to verify that memcpy behavese like memmove > > to our test suite... > > > > I think the bug is in the manpage, not the code, and we should fix it the way > NetBSD did. Have you audited all of our code base to confirm that such a change will not break anything? The man page has been like this since r1573, so it's very possible that code has been written to depend upon this behavior... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 19:18:17 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B635A78 for ; Mon, 6 Apr 2015 19:18:17 +0000 (UTC) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 359B47D8 for ; Mon, 6 Apr 2015 19:18:16 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.8/8.14.8) with ESMTP id t36JHxlV064171; Mon, 6 Apr 2015 21:17:59 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.8/8.14.8/Submit) id t36JHxEI064170; Mon, 6 Apr 2015 21:17:59 +0200 (CEST) (envelope-from mlfbsd) Date: Mon, 6 Apr 2015 21:17:59 +0200 From: Olivier Houchard To: John-Mark Gurney Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406191759.GA64102@ci0.org> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <20150406190901.GW51048@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150406190901.GW51048@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 19:18:17 -0000 On Mon, Apr 06, 2015 at 12:09:01PM -0700, John-Mark Gurney wrote: > Olivier Houchard wrote this message on Mon, Apr 06, 2015 at 19:41 +0200: > > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > > > > > > > I would like to remove this file as it does not implement our defined > > > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > > > > behavior. We have defined it to have the same symatics as memmove. > > > > > > > > > > Sample test program: > > > > > #include > > > > > #include > > > > > > > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > > > > int > > > > > main() > > > > > { > > > > > > > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > > > > printf("%s\n", bufa); > > > > > > > > > > return 0; > > > > > } > > > > > > > > > > Output on amd64 HEAD: > > > > > this is a this is a test buffer that should be co > > > > > > > > > > Output on old armv4 from 9.x: > > > > > this is a this is a thst buffethst bufhould beufh > > > > > > > > > > If you just look at the file, it is clear that the implementation does > > > > > not adjust the copy direction based upon pointers. We imported the > > > > > code from NetBSD, and NetBSD does apparently require memcpy's arguments > > > > > to be non-overlapping. > > > > > > > > > > I'll remove the file shortly unless someone can prove to me that all > > > > > uses of memcpy in our tree do not depend upon our defined behavior > > > > > per memcpy(3)'s man page. > > > > > > > > Any chance you can fix this implementation instead? > > > > > > I don't know arm assembly well enough, nor do I have the time to fix > > > it.. I am willing to test any implementations as I have access to > > > hardware... > > > > > > I guess I should add a test to verify that memcpy behavese like memmove > > > to our test suite... > > > > > > > I think the bug is in the manpage, not the code, and we should fix it the way > > NetBSD did. > > Have you audited all of our code base to confirm that such a change > will not break anything? The man page has been like this since r1573, > so it's very possible that code has been written to depend upon this > behavior... > No. But I doubt anybody decided to rely on an implementation detail described in the "BUGS" section, written 25 years ago, to warn people NOT to do this. If we do, well it's a bug, and it doesn't matter if it's in the manpage or not. Both NetBSD and OpenBSD got ride of those bits, and so should we. Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 19:32:34 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CA5FC3 for ; Mon, 6 Apr 2015 19:32:34 +0000 (UTC) Received: from st11p00mm-asmtp002.mac.com (st11p00mm-asmtpout002.mac.com [17.172.81.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FC7F993 for ; Mon, 6 Apr 2015 19:32:33 +0000 (UTC) Received: from akita.localnet (209-23-203-214-Illinois.hfc.comcastbusiness.net [209.23.203.214]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NME00BN7E618530@st11p00mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Mon, 06 Apr 2015 18:32:27 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-06_04:2015-04-06,2015-04-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504060172 From: Rui Paulo To: freebsd-arm@freebsd.org Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Date: Mon, 06 Apr 2015 11:32:25 -0700 Message-id: <3427080.JV46itjP9L@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-reply-to: <20150406174130.GA63423@ci0.org> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 19:32:34 -0000 On Monday 06 April 2015 19:41:30 Olivier Houchard wrote: > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > > > > > I would like to remove this file as it does not implement our defined > > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > > > behavior. We have defined it to have the same symatics as memmove. > > > > > > > > Sample test program: > > > > #include > > > > #include > > > > > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > > > int > > > > main() > > > > { > > > > > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > > > printf("%s\n", bufa); > > > > > > > > return 0; > > > > > > > > } > > > > > > > > Output on amd64 HEAD: > > > > this is a this is a test buffer that should be co > > > > > > > > Output on old armv4 from 9.x: > > > > this is a this is a thst buffethst bufhould beufh > > > > > > > > If you just look at the file, it is clear that the implementation does > > > > not adjust the copy direction based upon pointers. We imported the > > > > code from NetBSD, and NetBSD does apparently require memcpy's > > > > arguments > > > > to be non-overlapping. > > > > > > > > I'll remove the file shortly unless someone can prove to me that all > > > > uses of memcpy in our tree do not depend upon our defined behavior > > > > per memcpy(3)'s man page. > > > > > > Any chance you can fix this implementation instead? > > > > I don't know arm assembly well enough, nor do I have the time to fix > > it.. I am willing to test any implementations as I have access to > > hardware... > > > > I guess I should add a test to verify that memcpy behavese like memmove > > to our test suite... > > I think the bug is in the manpage, not the code, and we should fix it the > way NetBSD did. Our implementation of memcpy() allows strings to overlap, so we really shouldn't be special-casing armv4. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 19:40:22 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E95271B0 for ; Mon, 6 Apr 2015 19:40:22 +0000 (UTC) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7150A9D6 for ; Mon, 6 Apr 2015 19:40:22 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.8/8.14.8) with ESMTP id t36Je7D7064500; Mon, 6 Apr 2015 21:40:07 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.8/8.14.8/Submit) id t36Je7fo064499; Mon, 6 Apr 2015 21:40:07 +0200 (CEST) (envelope-from mlfbsd) Date: Mon, 6 Apr 2015 21:40:07 +0200 From: Olivier Houchard To: Rui Paulo Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406194007.GA64433@ci0.org> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3427080.JV46itjP9L@akita> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 19:40:23 -0000 On Mon, Apr 06, 2015 at 11:32:25AM -0700, Rui Paulo wrote: > On Monday 06 April 2015 19:41:30 Olivier Houchard wrote: > > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > > > > > > > I would like to remove this file as it does not implement our defined > > > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > > > > behavior. We have defined it to have the same symatics as memmove. > > > > > > > > > > Sample test program: > > > > > #include > > > > > #include > > > > > > > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > > > > int > > > > > main() > > > > > { > > > > > > > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > > > > printf("%s\n", bufa); > > > > > > > > > > return 0; > > > > > > > > > > } > > > > > > > > > > Output on amd64 HEAD: > > > > > this is a this is a test buffer that should be co > > > > > > > > > > Output on old armv4 from 9.x: > > > > > this is a this is a thst buffethst bufhould beufh > > > > > > > > > > If you just look at the file, it is clear that the implementation does > > > > > not adjust the copy direction based upon pointers. We imported the > > > > > code from NetBSD, and NetBSD does apparently require memcpy's > > > > > arguments > > > > > to be non-overlapping. > > > > > > > > > > I'll remove the file shortly unless someone can prove to me that all > > > > > uses of memcpy in our tree do not depend upon our defined behavior > > > > > per memcpy(3)'s man page. > > > > > > > > Any chance you can fix this implementation instead? > > > > > > I don't know arm assembly well enough, nor do I have the time to fix > > > it.. I am willing to test any implementations as I have access to > > > hardware... > > > > > > I guess I should add a test to verify that memcpy behavese like memmove > > > to our test suite... > > > > I think the bug is in the manpage, not the code, and we should fix it the > > way NetBSD did. > > Our implementation of memcpy() allows strings to overlap, so we really > shouldn't be special-casing armv4. > Any use of memcpy() with overlapping strings is a bug, I fail to see why we should make any effort to make it work. Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 19:53:46 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3B602B8 for ; Mon, 6 Apr 2015 19:53:46 +0000 (UTC) Received: from orange.myspectrum.nl (unknown [IPv6:2a01:7c8:aab2:19e:5054:ff:fe1e:7dad]) by mx1.freebsd.org (Postfix) with ESMTP id 846BDBA7 for ; Mon, 6 Apr 2015 19:53:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by orange.myspectrum.nl (Postfix) with ESMTP id 27E638CC4B; Mon, 6 Apr 2015 21:53:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at myspectrum.nl Received: from orange.myspectrum.nl ([127.0.0.1]) by localhost (orange.myspectrum.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdYS3egVOOas; Mon, 6 Apr 2015 21:53:37 +0200 (CEST) Received: from [192.168.178.11] (5ED6B7F1.cm-7-7c.dynamic.ziggo.nl [94.214.183.241]) (Authenticated sender: freebsd_arm@myspectrum.nl) by orange.myspectrum.nl (Postfix) with ESMTPSA id 934BF8CC4A; Mon, 6 Apr 2015 21:53:37 +0200 (CEST) Message-ID: <5522E440.3010306@myspectrum.nl> Date: Mon, 06 Apr 2015 21:53:36 +0200 From: Jeroen Hofstee User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Olivier Houchard , Rui Paulo Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> <20150406194007.GA64433@ci0.org> In-Reply-To: <20150406194007.GA64433@ci0.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 19:53:47 -0000 Hi, On 06-04-15 21:40, Olivier Houchard wrote: > On Mon, Apr 06, 2015 at 11:32:25AM -0700, Rui Paulo wrote: >> On Monday 06 April 2015 19:41:30 Olivier Houchard wrote: >>> On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: >>>> Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: >>>>>> On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: >>>>>> >>>>>> I would like to remove this file as it does not implement our defined >>>>>> memcpy. Per POSIX, overlapping regions passed to memcpy is undefined >>>>>> behavior. We have defined it to have the same symatics as memmove. >>>>>> >>>>>> Sample test program: >>>>>> #include >>>>>> #include >>>>>> >>>>>> char bufa[512] = "this is a test buffer that should be copied fine."; >>>>>> int >>>>>> main() >>>>>> { >>>>>> >>>>>> memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); >>>>>> printf("%s\n", bufa); >>>>>> >>>>>> return 0; >>>>>> >>>>>> } >>>>>> >>>>>> Output on amd64 HEAD: >>>>>> this is a this is a test buffer that should be co >>>>>> >>>>>> Output on old armv4 from 9.x: >>>>>> this is a this is a thst buffethst bufhould beufh >>>>>> >>>>>> If you just look at the file, it is clear that the implementation does >>>>>> not adjust the copy direction based upon pointers. We imported the >>>>>> code from NetBSD, and NetBSD does apparently require memcpy's >>>>>> arguments >>>>>> to be non-overlapping. >>>>>> >>>>>> I'll remove the file shortly unless someone can prove to me that all >>>>>> uses of memcpy in our tree do not depend upon our defined behavior >>>>>> per memcpy(3)'s man page. >>>>> Any chance you can fix this implementation instead? >>>> I don't know arm assembly well enough, nor do I have the time to fix >>>> it.. I am willing to test any implementations as I have access to >>>> hardware... >>>> >>>> I guess I should add a test to verify that memcpy behavese like memmove >>>> to our test suite... >>> I think the bug is in the manpage, not the code, and we should fix it the >>> way NetBSD did. >> Our implementation of memcpy() allows strings to overlap, so we really >> shouldn't be special-casing armv4. >> > Any use of memcpy() with overlapping strings is a bug, I fail to see why we > should make any effort to make it work. For what it is worth, a similar issue is discussed at https://sourceware.org/bugzilla/show_bug.cgi?id=12518 Regards, Jeroen From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 20:55:02 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FAE4EC1 for ; Mon, 6 Apr 2015 20:55:02 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0A9346 for ; Mon, 6 Apr 2015 20:55:00 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 8A3A160F68; Mon, 6 Apr 2015 20:54:52 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (smtp7.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 06 Apr 2015 20:54:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428353692640:2752545603 X-MC-Ingress-Time: 1428353692640 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp7.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YfAtB-0003bj-Ng; Mon, 06 Apr 2015 17:32:45 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t36HWffA073047; Mon, 6 Apr 2015 11:32:41 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+g8oduF14rWM9FglNwQDfj Message-ID: <1428341561.82583.154.camel@freebsd.org> Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S From: Ian Lepore To: Warner Losh Date: Mon, 06 Apr 2015 11:32:41 -0600 In-Reply-To: References: <20150405015245.GO51048@funkthat.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 20:55:02 -0000 On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote: > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > I would like to remove this file as it does not implement our defined > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > behavior. We have defined it to have the same symatics as memmove. > > > > Sample test program: > > #include > > #include > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > int > > main() > > { > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > printf("%s\n", bufa); > > > > return 0; > > } > > > > Output on amd64 HEAD: > > this is a this is a test buffer that should be co > > > > Output on old armv4 from 9.x: > > this is a this is a thst buffethst bufhould beufh > > > > If you just look at the file, it is clear that the implementation does > > not adjust the copy direction based upon pointers. We imported the > > code from NetBSD, and NetBSD does apparently require memcpy's arguments > > to be non-overlapping. > > > > I'll remove the file shortly unless someone can prove to me that all > > uses of memcpy in our tree do not depend upon our defined behavior > > per memcpy(3)'s man page. > > Any chance you can fix this implementation instead? > > Warner I don't think we should be wasting our scarce developer resources trying to redevelop high-performance string functions for long-obsolete arm hardware. Just revert to the generic implementations, and perhaps someone who actually uses that old hardware will contribute high performance implementations that follow the rules. Hmmm, does netbsd have xscale performance implementations of memmove()? Maybe we can just drop that in as memcpy(). Any more work than that is probably wasted effort at this late date. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 21:52:07 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C8D132B for ; Mon, 6 Apr 2015 21:52:07 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 373A6BFF for ; Mon, 6 Apr 2015 21:52:06 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t36LpvLJ010274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 14:51:57 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t36LpuIm010273; Mon, 6 Apr 2015 14:51:56 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Apr 2015 14:51:56 -0700 From: John-Mark Gurney To: Olivier Houchard Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406215156.GZ51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> <20150406194007.GA64433@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150406194007.GA64433@ci0.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 06 Apr 2015 14:51:57 -0700 (PDT) Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 21:52:07 -0000 Olivier Houchard wrote this message on Mon, Apr 06, 2015 at 21:40 +0200: > On Mon, Apr 06, 2015 at 11:32:25AM -0700, Rui Paulo wrote: > > On Monday 06 April 2015 19:41:30 Olivier Houchard wrote: > > > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > > > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > > > > > > > > > I would like to remove this file as it does not implement our defined > > > > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > > > > > behavior. We have defined it to have the same symatics as memmove. > > > > > > > > > > > > Sample test program: > > > > > > #include > > > > > > #include > > > > > > > > > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > > > > > int > > > > > > main() > > > > > > { > > > > > > > > > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > > > > > printf("%s\n", bufa); > > > > > > > > > > > > return 0; > > > > > > > > > > > > } > > > > > > > > > > > > Output on amd64 HEAD: > > > > > > this is a this is a test buffer that should be co > > > > > > > > > > > > Output on old armv4 from 9.x: > > > > > > this is a this is a thst buffethst bufhould beufh > > > > > > > > > > > > If you just look at the file, it is clear that the implementation does > > > > > > not adjust the copy direction based upon pointers. We imported the > > > > > > code from NetBSD, and NetBSD does apparently require memcpy's > > > > > > arguments > > > > > > to be non-overlapping. > > > > > > > > > > > > I'll remove the file shortly unless someone can prove to me that all > > > > > > uses of memcpy in our tree do not depend upon our defined behavior > > > > > > per memcpy(3)'s man page. > > > > > > > > > > Any chance you can fix this implementation instead? > > > > > > > > I don't know arm assembly well enough, nor do I have the time to fix > > > > it.. I am willing to test any implementations as I have access to > > > > hardware... > > > > > > > > I guess I should add a test to verify that memcpy behavese like memmove > > > > to our test suite... > > > > > > I think the bug is in the manpage, not the code, and we should fix it the > > > way NetBSD did. > > > > Our implementation of memcpy() allows strings to overlap, so we really > > shouldn't be special-casing armv4. > > Any use of memcpy() with overlapping strings is a bug, I fail to see why we > should make any effort to make it work. Are you willing to do the work to make amd64/i386 and other platforms behave incorrectly (one way or the other) when they overlap? If you aren't willing to do that (and fix the resulting bugs), how do you expect me to deal w/ unfound bugs in armv4 that depend upon this "buggy" behavior? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:06:35 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B3D24F6 for ; Mon, 6 Apr 2015 22:06:35 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1F27D32 for ; Mon, 6 Apr 2015 22:06:34 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so351133igb.1 for ; Mon, 06 Apr 2015 15:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZDYnHDse4t589I1250TKWjfzH2ZNHl/4QwIKILr6aWY=; b=oUqLauUfmT44ww+AOeSd6/iXMeqGcmE2+SEVD6bfkIZLQsBjfAU6ed6OFCGcnDISyI ix1swFczTGhBbkbp6kcn2UwO/RR0fpMV3VL6l7xbI3x1z28N6YuqY2oOwv13fXym5asg o8rWf2lCrabuxfmhTRb9ed8wpyq2VjYwzENoLVKGUO/IXBGfhkl/fmDUqDv5FhKocJt1 lWQ0lrQK55LdDVaiji6rNvZ6r3KA9sx7URfBZmvk07YFE+TgaI4jNYxf4YwkIvuYPr6y yYVhD0g3oXp/daXBwji3/s65T3aNkN/pPwjIw78ilznrPDU25YNj7iRzUB8L3V868qli MDSQ== MIME-Version: 1.0 X-Received: by 10.42.137.202 with SMTP id z10mr12587724ict.37.1428357994376; Mon, 06 Apr 2015 15:06:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Mon, 6 Apr 2015 15:06:34 -0700 (PDT) In-Reply-To: <20150406215156.GZ51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> <20150406194007.GA64433@ci0.org> <20150406215156.GZ51048@funkthat.com> Date: Mon, 6 Apr 2015 15:06:34 -0700 X-Google-Sender-Auth: RztxTcI4BnGxMDTyzvpmxE8acLw Message-ID: Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S From: Adrian Chadd To: John-Mark Gurney Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:06:35 -0000 Can we make -current builds of userland include a run-time assertion that the buffer pointers don't overlap? -adrian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:15:43 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD9CD820 for ; Mon, 6 Apr 2015 22:15:43 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A09EAE1C for ; Mon, 6 Apr 2015 22:15:43 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so493949igb.1 for ; Mon, 06 Apr 2015 15:15:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=w3pwr59V5H/xpFzpsbb6BG0Ljxkt2xVVDs4WF00aIHY=; b=Eprzbfl1nAZE3LyvfIB5J2qm54nqzobgzIjmWflHW9ebbGLys6HPEnE5D5zAKlTIP0 VSsZbgn28ASFAksoSXxJT5YtfVLkQJmVdYJJbQkxVzmRhejPD8uSB5juT2W0uly+g+TA xMfN7wyT3Q7/o7g16vXtRKhKeaIJ2izfPZRMzCfsOfeaEKqw+ZXqlMtRbbYKhMKWCUre 81ek9kz3zRsPt3GvsaSQ6ISlh+ooyishckwvBnRCWGpZd0S9PrP/5M5wz5xdR9XKR+/m 9hm5ob7ISLpkn+RT9DJPdiWqPJU9tl8+eFL8M2HFsd08UezzUOmK/ux9/nAQPmD+NWUt Kwbg== X-Gm-Message-State: ALoCoQmapV0NMkcJStDFHBQdzIyu0lyaU+v5T+5hqZlB+FLbRKAM55IB9TAps0Idil4lR67vMPFC X-Received: by 10.107.131.135 with SMTP id n7mr8696910ioi.37.1428358542535; Mon, 06 Apr 2015 15:15:42 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id b6sm3562463igb.15.2015.04.06.15.15.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 15:15:41 -0700 (PDT) Sender: Warner Losh Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: <1428341561.82583.154.camel@freebsd.org> Date: Mon, 6 Apr 2015 16:15:40 -0600 Message-Id: References: <20150405015245.GO51048@funkthat.com> <1428341561.82583.154.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:15:44 -0000 --Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 6, 2015, at 11:32 AM, Ian Lepore wrote: >=20 > On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote: >>> On Apr 4, 2015, at 7:52 PM, John-Mark Gurney = wrote: >>>=20 >>> I would like to remove this file as it does not implement our = defined >>> memcpy. Per POSIX, overlapping regions passed to memcpy is = undefined >>> behavior. We have defined it to have the same symatics as memmove. >>>=20 >>> Sample test program: >>> #include >>> #include >>>=20 >>> char bufa[512] =3D "this is a test buffer that should be copied = fine."; >>> int >>> main() >>> { >>>=20 >>> memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); >>> printf("%s\n", bufa); >>>=20 >>> return 0; >>> } >>>=20 >>> Output on amd64 HEAD: >>> this is a this is a test buffer that should be co >>>=20 >>> Output on old armv4 from 9.x: >>> this is a this is a thst buffethst bufhould beufh >>>=20 >>> If you just look at the file, it is clear that the implementation = does >>> not adjust the copy direction based upon pointers. We imported the >>> code from NetBSD, and NetBSD does apparently require memcpy's = arguments >>> to be non-overlapping. >>>=20 >>> I'll remove the file shortly unless someone can prove to me that all >>> uses of memcpy in our tree do not depend upon our defined behavior >>> per memcpy(3)'s man page. >>=20 >> Any chance you can fix this implementation instead? >>=20 >> Warner >=20 > I don't think we should be wasting our scarce developer resources = trying > to redevelop high-performance string functions for long-obsolete arm > hardware. Just revert to the generic implementations, and perhaps > someone who actually uses that old hardware will contribute high > performance implementations that follow the rules. >=20 > Hmmm, does netbsd have xscale performance implementations of = memmove()? > Maybe we can just drop that in as memcpy(). Any more work than that = is > probably wasted effort at this late date. I just looked at what NetBSD has. I=E2=80=99ve looked at the assembly = here. I think that we should just use the generic implementation now. These = routines are optimized for xscale, and don=E2=80=99t seem to be that much better = than the generic routines. So as long as you don=E2=80=99t break arm, armeb, armv6, etc it should = be OK. Warner --Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVIwWMAAoJEGwc0Sh9sBEAzBIP/2ZStS0buY9asslWCGyJsa4P PCWM/8W1wXxR6KZDWu9qjzhMPOTY+kNtxN7EZ9SST7gzQJTBJ7d8aAuDaNlo7/k8 Vyf9PiYcH5yU6F+aDsxIzEa0a/d36dB1xToXwyCIPrOnz1qnXrvfROitnlXadbcs eLk4hRjcD0/9YcosZ/vfXET8WKlxPufBvtqD/KnHo5q47IgNFnZRruXg6NN4N2gh rrAu16iPYzpyEsun8UoM7kHE+ZSxs0PTRHfV/gJ2Kr0JG7R2HO+pR0IBc0brS+pA /oJxD4TIacEznBsp8ZqtZsfOQ5DI5wiSV30CPiGqasO7R1XUrejw/WAlMovWy7/V 1F22IYCDCBBGXxJGG7x4Qb+xkA0fiMWTC79Tpi8e8g+rLEQ8rZxgD9/gWos84Mb6 UfpaE0qaUYUFvZCZkw0UCm6iGD9+xCtMnGsQQBuuNbAN9MWgVlmJ0hk+Q86BtwBO +uZXz81OFCghmjd0Fb8JzPRpGX3NX3mW/DaSKRr9Jxvrp8+fcqa/kG/5gNraqcsF x636gR4Z+eknsAloWVsrxQtGceElwrqvv84XCpXVDvdqtZ2qBm6vt/5Hvteb3o7O BWJMKfxRxPKSLTWlLp63X1rn9Eas8wMYfB268OWQzNMBgeC4KvMrX+dwGnuaEOr1 66hws9oN1CjcpFfXB3/Z =rnAd -----END PGP SIGNATURE----- --Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A-- From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:24:09 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7312AA8E; Mon, 6 Apr 2015 22:24:09 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1C8F03; Mon, 6 Apr 2015 22:24:09 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t36MO7nE010684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 15:24:07 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t36MO7Ln010683; Mon, 6 Apr 2015 15:24:07 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Apr 2015 15:24:07 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406222407.GB51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <1428341561.82583.154.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 06 Apr 2015 15:24:07 -0700 (PDT) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:24:09 -0000 Warner Losh wrote this message on Mon, Apr 06, 2015 at 16:15 -0600: > > > On Apr 6, 2015, at 11:32 AM, Ian Lepore wrote: > > > > On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote: > >>> On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > >>> > >>> I would like to remove this file as it does not implement our defined > >>> memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > >>> behavior. We have defined it to have the same symatics as memmove. > >>> > >>> Sample test program: > >>> #include > >>> #include > >>> > >>> char bufa[512] = "this is a test buffer that should be copied fine."; > >>> int > >>> main() > >>> { > >>> > >>> memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > >>> printf("%s\n", bufa); > >>> > >>> return 0; > >>> } > >>> > >>> Output on amd64 HEAD: > >>> this is a this is a test buffer that should be co > >>> > >>> Output on old armv4 from 9.x: > >>> this is a this is a thst buffethst bufhould beufh > >>> > >>> If you just look at the file, it is clear that the implementation does > >>> not adjust the copy direction based upon pointers. We imported the > >>> code from NetBSD, and NetBSD does apparently require memcpy's arguments > >>> to be non-overlapping. > >>> > >>> I'll remove the file shortly unless someone can prove to me that all > >>> uses of memcpy in our tree do not depend upon our defined behavior > >>> per memcpy(3)'s man page. > >> > >> Any chance you can fix this implementation instead? > >> > >> Warner > > > > I don't think we should be wasting our scarce developer resources trying > > to redevelop high-performance string functions for long-obsolete arm > > hardware. Just revert to the generic implementations, and perhaps > > someone who actually uses that old hardware will contribute high > > performance implementations that follow the rules. > > > > Hmmm, does netbsd have xscale performance implementations of memmove()? > > Maybe we can just drop that in as memcpy(). Any more work than that is > > probably wasted effort at this late date. > > I just looked at what NetBSD has. I???ve looked at the assembly here. > I think that we should just use the generic implementation now. These routines > are optimized for xscale, and don???t seem to be that much better than the > generic routines. I've looked and I don't see a version of memmove.S in NetBSD... There is lib/libc/arch/arm/string/bcopy.S which includes memmove.S, but I can't find memmove.S in their tree... It could be a generated file as I don't know their build infrastructure... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:25:30 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB795AE5 for ; Mon, 6 Apr 2015 22:25:30 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id EF045F0C for ; Mon, 6 Apr 2015 22:25:29 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 14034120FAF; Mon, 6 Apr 2015 22:00:33 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (smtp1.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 06 Apr 2015 22:00:33 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428357633282:526239237 X-MC-Ingress-Time: 1428357633281 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp1.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YfF4K-0001JR-R1; Mon, 06 Apr 2015 22:00:32 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t36M0Upg073483; Mon, 6 Apr 2015 16:00:31 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/SoCjAHFE5OrP4EDT4RsFG Message-ID: <1428357630.82583.157.camel@freebsd.org> Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S From: Ian Lepore To: John-Mark Gurney Date: Mon, 06 Apr 2015 16:00:30 -0600 In-Reply-To: <20150406215156.GZ51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> <20150406194007.GA64433@ci0.org> <20150406215156.GZ51048@funkthat.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:25:30 -0000 On Mon, 2015-04-06 at 14:51 -0700, John-Mark Gurney wrote: > Olivier Houchard wrote this message on Mon, Apr 06, 2015 at 21:40 +0200: > > On Mon, Apr 06, 2015 at 11:32:25AM -0700, Rui Paulo wrote: > > > On Monday 06 April 2015 19:41:30 Olivier Houchard wrote: > > > > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > > > > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > > > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney wrote: > > > > > > > > > > > > > > I would like to remove this file as it does not implement our defined > > > > > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined > > > > > > > behavior. We have defined it to have the same symatics as memmove. > > > > > > > > > > > > > > Sample test program: > > > > > > > #include > > > > > > > #include > > > > > > > > > > > > > > char bufa[512] = "this is a test buffer that should be copied fine."; > > > > > > > int > > > > > > > main() > > > > > > > { > > > > > > > > > > > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); > > > > > > > printf("%s\n", bufa); > > > > > > > > > > > > > > return 0; > > > > > > > > > > > > > > } > > > > > > > > > > > > > > Output on amd64 HEAD: > > > > > > > this is a this is a test buffer that should be co > > > > > > > > > > > > > > Output on old armv4 from 9.x: > > > > > > > this is a this is a thst buffethst bufhould beufh > > > > > > > > > > > > > > If you just look at the file, it is clear that the implementation does > > > > > > > not adjust the copy direction based upon pointers. We imported the > > > > > > > code from NetBSD, and NetBSD does apparently require memcpy's > > > > > > > arguments > > > > > > > to be non-overlapping. > > > > > > > > > > > > > > I'll remove the file shortly unless someone can prove to me that all > > > > > > > uses of memcpy in our tree do not depend upon our defined behavior > > > > > > > per memcpy(3)'s man page. > > > > > > > > > > > > Any chance you can fix this implementation instead? > > > > > > > > > > I don't know arm assembly well enough, nor do I have the time to fix > > > > > it.. I am willing to test any implementations as I have access to > > > > > hardware... > > > > > > > > > > I guess I should add a test to verify that memcpy behavese like memmove > > > > > to our test suite... > > > > > > > > I think the bug is in the manpage, not the code, and we should fix it the > > > > way NetBSD did. > > > > > > Our implementation of memcpy() allows strings to overlap, so we really > > > shouldn't be special-casing armv4. > > > > Any use of memcpy() with overlapping strings is a bug, I fail to see why we > > should make any effort to make it work. > > Are you willing to do the work to make amd64/i386 and other platforms > behave incorrectly (one way or the other) when they overlap? If you > aren't willing to do that (and fix the resulting bugs), how do you > expect me to deal w/ unfound bugs in armv4 that depend upon this > "buggy" behavior? > As Olivier pointed out on irc, this isn't actually xscale code, it's used for all armv5+ systems. To me that says that there isn't a whole lot of existing code relying on the non-standard behavior because arm systems actually work. For non-arm systems, the potential breakage exists primarily in drivers and MD code that aren't used on arm, and that's a much smaller universe of potential breakage. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:35:42 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0659CD70 for ; Mon, 6 Apr 2015 22:35:42 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD4288 for ; Mon, 6 Apr 2015 22:35:41 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so37191428ied.1 for ; Mon, 06 Apr 2015 15:35:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=FnukCbJOtTnsXZLyJBpM/hyBmaQmU0+je4wZiGFHXq4=; b=KbagvW2gpfS/e8aw8kZKd3wovWHH/rP+T7Txpra95BzWJ8Y8l/OH7t/jw63Lpr8M3u Vb/A2xgEBlr9NPrUUqzNo3IhOnCZaRMC7Ll0PDjx+b5x2dl7c5Z1lmGaVopoGK7Dm1YQ M1gbP4aZl1oIHE1VkQbY4z7xKZx4P64W0t/Gvxms57oI7Ci0fFvTjo++I4ZFuTTqZcXO mVsvX6Raf+tqn8Zk4Bda0ghwjZDW11shWU5V/z2nDFmhEJqdYaZBEGi4eIUtxvR6nQxC IMqQeXZq9gpjDCsCwrk1sYL3InYPF4fYiPwlU4LlOZjTD/eiTY4NMHeuPN7Bejq0xHSi sGrg== X-Gm-Message-State: ALoCoQlwChSz5NCTd9Va7oIbFynGOfV6KF5aSK7Yfq2ktJZ90F165udl7Q6o2i2/MV0mNBlBzQQL X-Received: by 10.50.43.136 with SMTP id w8mr864977igl.26.1428359403394; Mon, 06 Apr 2015 15:30:03 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id p76sm3548018iop.14.2015.04.06.15.30.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 15:30:02 -0700 (PDT) Sender: Warner Losh Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_91BBA9EB-A0B9-4A15-90D0-0D76930AE3A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: <20150406222407.GB51048@funkthat.com> Date: Mon, 6 Apr 2015 16:30:01 -0600 Message-Id: <20DF0E2C-3552-4E55-8656-301EA8CD41C6@bsdimp.com> References: <20150405015245.GO51048@funkthat.com> <1428341561.82583.154.camel@freebsd.org> <20150406222407.GB51048@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:35:42 -0000 --Apple-Mail=_91BBA9EB-A0B9-4A15-90D0-0D76930AE3A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 6, 2015, at 4:24 PM, John-Mark Gurney wrote: >=20 > Warner Losh wrote this message on Mon, Apr 06, 2015 at 16:15 -0600: >>=20 >>> On Apr 6, 2015, at 11:32 AM, Ian Lepore wrote: >>>=20 >>> On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote: >>>>> On Apr 4, 2015, at 7:52 PM, John-Mark Gurney = wrote: >>>>>=20 >>>>> I would like to remove this file as it does not implement our = defined >>>>> memcpy. Per POSIX, overlapping regions passed to memcpy is = undefined >>>>> behavior. We have defined it to have the same symatics as = memmove. >>>>>=20 >>>>> Sample test program: >>>>> #include >>>>> #include >>>>>=20 >>>>> char bufa[512] =3D "this is a test buffer that should be copied = fine."; >>>>> int >>>>> main() >>>>> { >>>>>=20 >>>>> memcpy(&bufa[10], &bufa[0], strlen(&bufa[10])); >>>>> printf("%s\n", bufa); >>>>>=20 >>>>> return 0; >>>>> } >>>>>=20 >>>>> Output on amd64 HEAD: >>>>> this is a this is a test buffer that should be co >>>>>=20 >>>>> Output on old armv4 from 9.x: >>>>> this is a this is a thst buffethst bufhould beufh >>>>>=20 >>>>> If you just look at the file, it is clear that the implementation = does >>>>> not adjust the copy direction based upon pointers. We imported = the >>>>> code from NetBSD, and NetBSD does apparently require memcpy's = arguments >>>>> to be non-overlapping. >>>>>=20 >>>>> I'll remove the file shortly unless someone can prove to me that = all >>>>> uses of memcpy in our tree do not depend upon our defined behavior >>>>> per memcpy(3)'s man page. >>>>=20 >>>> Any chance you can fix this implementation instead? >>>>=20 >>>> Warner >>>=20 >>> I don't think we should be wasting our scarce developer resources = trying >>> to redevelop high-performance string functions for long-obsolete arm >>> hardware. Just revert to the generic implementations, and perhaps >>> someone who actually uses that old hardware will contribute high >>> performance implementations that follow the rules. >>>=20 >>> Hmmm, does netbsd have xscale performance implementations of = memmove()? >>> Maybe we can just drop that in as memcpy(). Any more work than that = is >>> probably wasted effort at this late date. >>=20 >> I just looked at what NetBSD has. I???ve looked at the assembly here. >> I think that we should just use the generic implementation now. These = routines >> are optimized for xscale, and don???t seem to be that much better = than the >> generic routines. >=20 > I've looked and I don't see a version of memmove.S in NetBSD... There = is > lib/libc/arch/arm/string/bcopy.S which includes memmove.S, but I can't > find memmove.S in their tree... It could be a generated file as I = don't > know their build infrastructure... bcopy is memmove with a different arg order, so they do assembler tricks = to provide both interfaces. Warner --Apple-Mail=_91BBA9EB-A0B9-4A15-90D0-0D76930AE3A3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVIwjpAAoJEGwc0Sh9sBEA/B0QANNlzI3/B7vV8A+9G5xIB8/u wk9Wtq11VItmwHit+wNUYRQpP36EtZEd/3jK3vy7o0DfCekH4+TIh1499GyEZaVD NoQn/7GEoGsKhNDVdi5uxQxwrKXDHFdFxRHwumJvUnk5DHMQRo+VL45lX+bEwfak EkGWIs9Q5GZC5v9KDkvfQMt02xIq7IMHdIxjcDs6zfALenGg3I1yH9/FCGctu26O xICQ9SUnAewLWT1GhvJcF+nAPhmGXlSILjPXJJp+W7WZTmz/G6s+A5zv4fHZElwt TLYWftQj7WWpnlcWWiILT+hg948rgDCgpzJuRfPw0ZjcXSJNBnJKZNGmozHmih5y d2DXkHgh28iONt+GmSx+Xh70HCVc0tWgq/KQsyi9AhP8NjKNfcs63JqUSTfvSJVT XHG9+l8++fk3paAO+ZXE1+OOJPekylcxQRZ54fhHdxutywz5ssZo/zJ9EC4O7RMr C05hAI7m6xeltv+M76NLTEFdwPJ79te+xISzTcFM/ScZUJWfqYmk/OS5BAfR0boS XEgryW5ujDAcYtmjvX7Aizj8Kyxo7gCrL3wr+i5GeyTiOz12ko6U6fcv+K6jp7gA 215xzmuBWC1fBJyvz7ehK6YeqkWKHFZnAvXNaFrv2UUjJ00ZWPgm3jgMXOYGrVfJ VDzpzXnKBKluXFJsWBqe =FSWq -----END PGP SIGNATURE----- --Apple-Mail=_91BBA9EB-A0B9-4A15-90D0-0D76930AE3A3-- From owner-freebsd-arm@FreeBSD.ORG Tue Apr 7 00:32:29 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E6376DD for ; Tue, 7 Apr 2015 00:32:29 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27A59E25 for ; Tue, 7 Apr 2015 00:32:29 +0000 (UTC) Received: by wizk4 with SMTP id k4so2829838wiz.1 for ; Mon, 06 Apr 2015 17:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/VyW5QhtdnAWBjnixdt4SUUoS6PLK3gq0jREaeAqU3E=; b=LZITK6d8lB8aKS2jAAa5YRbR890TETpKsZ8i//poLag2UNuHG7tHwQjutMK6/kV7cC xycIvfHq1Gq0XYb//sqSO9Wo9ivRJgORDCItB1QP0/CAEjPxYiiPlaIll5h9WM5K0/0d nkIB8V7Z8TLZ7qpTgKo6QuaiMPk2B76nEY9ytI0EgxPFflFL2FpdzdQfX93SefAwPEmk iaeMTVU6vti7LmVYinQ5VKrvCSf/w1RXAlyKNtzNva5v8GgqWgkz6YoS1oeaqSHuy6j0 qFCyjStWnuA8R1GuyFQV5NUgaofo3VuWMFoPU6o7hzfVs5HnLe0KwTFjk/PIdPsatzXs s36w== MIME-Version: 1.0 X-Received: by 10.180.84.97 with SMTP id x1mr1366973wiy.1.1428366747759; Mon, 06 Apr 2015 17:32:27 -0700 (PDT) Received: by 10.27.91.75 with HTTP; Mon, 6 Apr 2015 17:32:27 -0700 (PDT) Date: Mon, 6 Apr 2015 17:32:27 -0700 Message-ID: Subject: kvm_nlist failing on arm? From: Waitman Gobble To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 00:32:29 -0000 Hi, I'm having an issue with kvm_nlist failing on armv6 machine, but works on amd64 machines. Anyone have an idea about this? simple example static struct nlist nl[] = { #define N_HCI_RAW 0 { "_ng_btsocket_hci_raw_sockets" }, }; kvm_t *kvmd = NULL; kvmd = kvm_openfiles(NULL, memf, NULL, O_RDONLY, errbuf); kvm_nlist(kvmd, nl); if (nl[0].n_type == 0) { /* bomb - problem */ } # uname -a FreeBSD ARTiming150301 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279488: Sun Mar 1 10:27:33 PST 2015 waitman@rpidev.waitman.net:/usr/home/waitman/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/TMRDEV arm Thanks, -- Waitman Gobble Los Altos California USA 510-830-7975 From owner-freebsd-arm@FreeBSD.ORG Tue Apr 7 02:02:02 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06E00D9F for ; Tue, 7 Apr 2015 02:02:02 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2EF0905 for ; Tue, 7 Apr 2015 02:02:01 +0000 (UTC) Received: from gromit.chumby.lan (c-71-63-94-21.hsd1.va.comcast.net [71.63.94.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 1EA06D5C for ; Mon, 6 Apr 2015 21:54:31 -0400 (EDT) From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Huge pause during BBB boot Message-Id: <6086F4B8-AFD3-43D6-895A-C9AD0982FCFE@gromit.dlib.vt.edu> Date: Mon, 6 Apr 2015 21:54:30 -0400 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 02:02:02 -0000 I updated my FreeBSD/arm 11-CURRENT BeagleBone Black today and now there = is a huge pause when booting up. The boot sequence runs normally to the = "gpioc0: on gpio0" message and then seems to hang. A = long time later, it continues and finishes the boot. The lines after the paused one are these: uart0: mem 0x44e09000-0x44e09fff irq 72 on = simplebus0 uart0: console (-1,n,8,1) The console speed of -1 looks definitely wrong. Is a bad initialisation of the uart causing the long boot delay? I've included the boot log at the end of this message. Cheers, Paul. =3D=3D=3D=3D=3D U-Boot SPL 2014.04 (Mar 09 2015 - 19:17:54) reading args spl_load_image_fat_os: error reading image args, err - -1 reading bb-uboot.img reading bb-uboot.img U-Boot 2014.04 (Mar 09 2015 - 19:17:54) I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading bb-uEnv.txt reading bbubldr 260193 bytes read in 18 ms (13.8 MiB/s) reading bboneblk.dtb 16372 bytes read in 5 ms (3.1 MiB/s) ## Starting application at 0x88000074 ... Consoles: U-Boot console Compatible U-Boot API signature found @9f635510 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@releng2.nyi.freebsd.org, Mon Mar 9 19:17:49 UTC 2015) DRAM: 512MB Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. /boot/kernel/kernel data=3D0x528898+0x3b768 = syms=3D[0x4+0x61970+0x4+0x6571e] /boot/kernel/geom_label.ko text=3D0x4e08 data=3D0x760+0x4 = syms=3D[0x4+0x1260+0x4+0xf23 ] Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. loader> boot -s Booting... Using DTB provided by U-Boot at address 0x80000100. Kernel entry at 0x80200100... Kernel args: -s KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r281149: Mon Apr 6 11:41:32 EDT 2015 = paul@chumby.chumby.lan:/build/obj/bbb/arm.armv6/build/src/head/sys/BEAGLEB= ONE-NO_WITNESS arm FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:3 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory =3D 536870912 (512 MB) avail memory =3D 516415488 (492 MB) Texas Instruments AM3358 Processor, Revision ES1.1 random: entropy device infrastructure driver random: selecting highest priority adaptor random: SOFT: yarrow init() random: selecting highest priority adaptor ofwbus0: simplebus0: on ofwbus0 aintc0: mem 0x48200000-0x48200fff on = simplebus0 aintc0: Revision 5.0 ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 am335x_prcm0: mem = 0x44e00000-0x44e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz am335x_dmtimer0: mem = 0x44e05000-0x44e05fff,0x44e31000-0x44e31fff,0x48040000-0x48040fff,0x480420= 00-0x48042fff,0x48044000-0x48044fff,0x48046000-0x48046fff,0x48048000-0x480= 48fff,0x4804a000-0x4804afff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer" frequency 24000000 Hz quality 1000 am335x_rtc0: mem = 0x44e3e000-0x44e3efff irq 75,76 on simplebus0 am335x_rtc0: AM335X RTC v1.0.6 ti_adc0: mem 0x44e0d000-0x44e0efff irq 16 on = simplebus0 ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 ti_wdt0: mem 0x44e35000-0x44e35fff irq 91 on = simplebus0 gpio0: mem = 0x44e07000-0x44e07fff,0x4804c000-0x4804cfff,0x481ac000-0x481acfff,0x481ae0= 00-0x481aefff irq 96,97,98,99,32,33,62,63 on simplebus0 gpiobus0: on gpio0 gpioled0: at pin(s) 53 on gpiobus0 gpioled1: at pin(s) 54 on gpiobus0 gpioled2: at pin(s) 55 on gpiobus0 gpioled3: at pin(s) 56 on gpiobus0 gpioc0: on gpio0 uart0: mem 0x44e09000-0x44e09fff irq 72 on = simplebus0 uart0: console (-1,n,8,1) ti_edma30: mem = 0x49000000-0x490fffff,0x49800000-0x498fffff,0x49900000-0x499fffff,0x49a000= 00-0x49afffff irq 12,13,14 on simplebus0 ti_edma30: EDMA revision 40014c00 sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on = simplebus0 mmc0: on sdhci_ti0 sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on = simplebus0 mmc1: on sdhci_ti1 cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq = 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=3D128 RX=3D384 miibus0: on cpsw0 smscphy0: PHY 0 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cpsw0: Ethernet address: 90:59:af:55:26:eb iichb0: mem 0x44e0b000-0x44e0bfff irq 70 on = simplebus0 iichb0: I2C revision 4.0 FIFO size: 32 bytes iicbus0: on iichb0 iic0: on iicbus0 am335x_pmic0: at addr 0x48 on iicbus0 iichb1: mem 0x4802a000-0x4802afff irq 71 on = simplebus0 iichb1: I2C revision 4.0 FIFO size: 32 bytes iicbus1: on iichb1 iic1: on iicbus1 iichb2: mem 0x4819c000-0x4819cfff irq 30 on = simplebus0 iichb2: I2C revision 4.0 FIFO size: 32 bytes iicbus2: on iichb2 iic2: on iicbus2 am335x_pwm0: mem = 0x48300000-0x483000ff,0x48300100-0x4830017f,0x48300180-0x483001ff,0x483002= 00-0x4830025f irq 86,58 on simplebus0 am335x_pwm1: mem = 0x48302000-0x483020ff,0x48302100-0x4830217f,0x48302180-0x483021ff,0x483022= 00-0x4830225f irq 87,59 on simplebus0 am335x_pwm2: mem = 0x48304000-0x483040ff,0x48304100-0x4830417f,0x48304180-0x483041ff,0x483042= 00-0x4830425f irq 88,60 on simplebus0 musbotg0: mem = 0x47400000-0x47400fff,0x47401000-0x474012ff,0x47401300-0x474013ff,0x474014= 00-0x474017ff,0x47401800-0x47401aff,0x47401b00-0x47401bff,0x47401c00-0x474= 01fff irq 17,18,19 on simplebus0 musbotg0: TI AM335X USBSS v0.0.13 usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus0 on musbotg0 usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus1 on musbotg0 ti_pruss0: mem = 0x4a300000-0x4a37ffff irq 20,21,22,23,24,25,26,27 on simplebus0 ti_pruss0: AM33xx PRU-ICSS Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: = on usbus1 ugen0.1: at usbus0 uhub1: = on usbus0 mmcsd0: 16GB at mmc0 = 48.0MHz/4bit/65535-block uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered mmcsd1: 2GB at = mmc1 48.0MHz/8bit/65535-block am335x_pmic0: TPS65217C ver 1.2 powered by AC random: unblocking device. Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... warning: no time-of-day clock registered, system time will not be set = accurately Enter full pathname of shell or RETURN for /bin/sh: ugen1.2: at = usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks =3D 0x4100 umass0:0:0: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI device da0: Serial Number GW0 da0: 40.000MB/s transfers da0: 24404MB (49980416 512 byte sectors: 255H 63S/T 3111C) da0: quirks=3D0x2 =09= From owner-freebsd-arm@FreeBSD.ORG Tue Apr 7 02:10:00 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23D3DF2F for ; Tue, 7 Apr 2015 02:10:00 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEC2B92B for ; Tue, 7 Apr 2015 02:09:59 +0000 (UTC) Received: by widjs5 with SMTP id js5so641793wid.1 for ; Mon, 06 Apr 2015 19:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QUgrVqIF8/L1pcOoiHQ60NAjmZ3yc0YI1YPY64bP+TE=; b=DBYj6JqxNE4dBHUWeK8c2KvwW+bG1bKAY0DVASToVR5XgQR71H4f2WZ6PPVZyxGLK9 cx2rLltbTJOMfkBJBaXaq3WlT/uJt855Egda/45wZpBhjrqpoH04qAUwxE/cyuWFAsFd jRsqoWobRwrsz1dRA2oDZko9vtWjB5Y+8ZiQeB1HuZNpUrB8yFfSCbkkkqmRdNEsj5lK 8r5ea4F1U2L22bOXqWCWDusI60LNSB1yWHzFD3iKBf6qlcNeoG2x5Pn2pvijQfzKQNDt VwsL9Efc0MtdRP3RItnVcko087KJjPxVTyOOlmojeKfYrcSHjGHnn23X0rEk4V5MP654 62vw== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr250305wib.60.1428372597323; Mon, 06 Apr 2015 19:09:57 -0700 (PDT) Received: by 10.27.91.75 with HTTP; Mon, 6 Apr 2015 19:09:57 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Apr 2015 19:09:57 -0700 Message-ID: Subject: Re: kvm_nlist failing on arm? From: Waitman Gobble To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 02:10:00 -0000 On Mon, Apr 6, 2015 at 5:32 PM, Waitman Gobble wrote: > Hi, > > I'm having an issue with kvm_nlist failing on armv6 machine, but works > on amd64 machines. Anyone have an idea about this? > > > simple example > > static struct nlist nl[] = { > #define N_HCI_RAW 0 > { "_ng_btsocket_hci_raw_sockets" }, > }; > > kvm_t *kvmd = NULL; > kvmd = kvm_openfiles(NULL, memf, NULL, O_RDONLY, errbuf); > kvm_nlist(kvmd, nl); > if (nl[0].n_type == 0) { > /* bomb - problem */ > } > > > > # uname -a > FreeBSD ARTiming150301 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279488: > Sun Mar 1 10:27:33 PST 2015 > waitman@rpidev.waitman.net:/usr/home/waitman/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/TMRDEV > arm > > > Thanks, > > -- > Waitman Gobble > Los Altos California USA > 510-830-7975 OOPs, the error: kvm_nlist: no namelist -- Waitman Gobble Los Altos California USA 510-830-7975 From owner-freebsd-arm@FreeBSD.ORG Tue Apr 7 15:26:04 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2B3357F for ; Tue, 7 Apr 2015 15:26:04 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 182FE3CD for ; Tue, 7 Apr 2015 15:26:03 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id AE603100E1E; Tue, 7 Apr 2015 14:42:51 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (smtp5.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 07 Apr 2015 14:42:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428417771883:2838097223 X-MC-Ingress-Time: 1428417771883 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp5.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YfU1w-00011n-So; Tue, 07 Apr 2015 13:59:05 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t37DwvSH001138; Tue, 7 Apr 2015 07:58:58 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+/wK5K6+A4cPmHWr6mhps0 Message-ID: <1428415137.82583.159.camel@freebsd.org> Subject: Re: Huge pause during BBB boot From: Ian Lepore To: Paul Mather Date: Tue, 07 Apr 2015 07:58:57 -0600 In-Reply-To: <6086F4B8-AFD3-43D6-895A-C9AD0982FCFE@gromit.dlib.vt.edu> References: <6086F4B8-AFD3-43D6-895A-C9AD0982FCFE@gromit.dlib.vt.edu> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 15:26:05 -0000 On Mon, 2015-04-06 at 21:54 -0400, Paul Mather wrote: > I updated my FreeBSD/arm 11-CURRENT BeagleBone Black today and now there is a huge pause when booting up. The boot sequence runs normally to the "gpioc0: on gpio0" message and then seems to hang. A long time later, it continues and finishes the boot. > > The lines after the paused one are these: > > uart0: mem 0x44e09000-0x44e09fff irq 72 on simplebus0 > uart0: console (-1,n,8,1) > > > The console speed of -1 looks definitely wrong. > > Is a bad initialisation of the uart causing the long boot delay? > > I've included the boot log at the end of this message. > > Cheers, > > Paul. > I'm not sure the uart speed glitch is the cause of the long delay, but it was fixed in r281200. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Apr 10 02:09:15 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49866F7D for ; Fri, 10 Apr 2015 02:09:15 +0000 (UTC) Received: from biz112.inmotionhosting.com (biz112.inmotionhosting.com [66.117.4.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D0DBF1F for ; Fri, 10 Apr 2015 02:09:14 +0000 (UTC) Received: from 75-37-201-71.lightspeed.snmtca.sbcglobal.net ([75.37.201.71]:57344 helo=SB2) by biz112.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YfLhM-0005sa-QM for freebsd-arm@freebsd.org; Mon, 06 Apr 2015 22:05:18 -0700 From: "Sven Brehmer" To: Subject: Bluetooth on the Wandboard Quad Date: Mon, 6 Apr 2015 22:05:15 -0700 Message-ID: <04cf01d070f0$6f993d40$4ecbb7c0$@polycoresoftware.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBw7LvbVhnxBzQ9RtqxSKOi2TJ5VQ== Content-Language: en-us X-OutGoing-Spam-Status: No, score=-102.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz112.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - polycoresoftware.com X-Get-Message-Sender-Via: biz112.inmotionhosting.com: authenticated_id: sven.brehmer@polycoresoftware.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:09:15 -0000 Hello, We are running FreeBSD on the Wandboard and are trying get Bluetooth working using a Bluetooth USB adapter. The Adapter is an IOGEAR GBU521W6 Bluetooth 4.0 Micro Adapter USB, based on the Broadcom BCM20702A chip. We can't get the Bluetooth network stack started. We have searched the internet and found advice and settings which we have tested, to no avail. Some information below. Loaded drivers: # kldstat Id Refs Address Size Name 1 16 0xc2000000 6996a4 kernel 2 1 0xc269a000 e6e4 ng_ubt.ko 3 2 0xc26a9000 132e4 ng_hci.ko 4 4 0xc26bd000 9f78 ng_bluetooth.ko 5 6 0xc26c7000 1696c netgraph.ko 6 1 0xc79b2000 22000 ng_btsocket.ko 7 1 0xc7a48000 15000 ng_l2cap.ko 8 1 0xc7881000 b000 ng_socket.ko loader.conf related entries (probably not required): ng_ubt_load="YES" ng_l2cap_load="YES" rc.conf related entries: #bluetooth hcsecd_enable="YES" hcsecd_config="/etc/bluetooth/hcsecd.conf" sdpd_enable="YES" bthidd_enable="YES" bthidd_config="/etc/bluetooth/bthidd.conf" /etc/bluetooth files: ubt0.conf entries: authentication_enable="NO" connectable="YES" discoverable="YES" hci_debug_level="4" l2cap_debug_level="4" local_name="wandboard-quad" role_switch="YES" hcsecd.conf sample entries: device { bdaddr 00:11:22:33:44:55; name "Dummy"; key "0x00112233445566778899aabbccddeeff"; pin nopin; } device { bdaddr e4:32:ab:34:4e:ae; name "SvenB"; key nokey; pin nopin; } bthidd.conf has a blank line. hosts have entries. a snippet from the output of # sh -x /etc/rc.d/bluetooth start ubt0, below. + read _line + return 0 + bluetooth_setup_stack ubt0 hook + dev=ubt0 + shift + hook=hook + shift + ngctl mkpeer ubt0: hci hook drv + ngctl name ubt0:hook ubt0hci + ngctl msg ubt0hci: set_debug 3 + ngctl mkpeer ubt0hci: l2cap acl hci + ngctl name ubt0hci:acl ubt0l2cap + ngctl msg ubt0l2cap: set_debug 3 + ngctl connect ubt0hci: btsock_hci_raw: raw ubt0raw + ngctl connect ubt0l2cap: btsock_l2c_raw: ctl ubt0ctl + ngctl connect ubt0l2cap: btsock_l2c: l2c ubt0l2c + /usr/sbin/hccontrol -n ubt0hci reset + return 1 + bluetooth_shutdown_stack ubt0 + dev=ubt0 + ngctl shutdown ubt0hci: + ngctl shutdown ubt0l2cap: + return 0 + err 1 'Unable to setup Bluetooth stack for device ubt0' + exitval=1 + shift + [ -x /usr/bin/logger ] + logger '/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0' + echo '/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0' /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 + exit 1 Any advice would be appreciated. Regards, Sven Brehmer From owner-freebsd-arm@FreeBSD.ORG Fri Apr 10 06:44:11 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB527956 for ; Fri, 10 Apr 2015 06:44:11 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5D69FC7 for ; Fri, 10 Apr 2015 06:44:11 +0000 (UTC) Received: by wiun10 with SMTP id n10so14813776wiu.1 for ; Thu, 09 Apr 2015 23:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KnJIoClDZWRMb7sEamjVnRaVlM/YanOtFNujCLSFlGE=; b=clBWBJMpe2X24Vmh4miRl8mvA2534s4J9DUBObHRG25bBP5q+JPl6xi3VHtOwawbNh Nr3tfWNIFP8GbqSOP9KsySNAEeX8V/gdKJHpetoYD3FUN6Vgh7P6MG/J58plNiLm6lw2 wG3cQl9hOZWpHt/YSwZ6x3xMt9aFHqg6zuc6G88/MK5TiVg/whrBB2fQMljs+08sXTym ZuXw7Yuc/37RiG4YEIWVPgpN1f7hpW+pT8M2gKKeJqqIu8ovm2U7VGdfZDSpGfa7tPoV DdYTOPINLLOUrih5YLLuiYxEl7zmdvf5d0la2Pwe67PJr5FO2it4FmMb6ONqeLRqehVT klMQ== MIME-Version: 1.0 X-Received: by 10.180.80.65 with SMTP id p1mr12577819wix.70.1428648250081; Thu, 09 Apr 2015 23:44:10 -0700 (PDT) Received: by 10.27.91.75 with HTTP; Thu, 9 Apr 2015 23:44:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Apr 2015 23:44:10 -0700 Message-ID: Subject: Re: kvm_nlist failing on arm? From: Waitman Gobble To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 06:44:12 -0000 On Mon, Apr 6, 2015 at 7:09 PM, Waitman Gobble wrote: > On Mon, Apr 6, 2015 at 5:32 PM, Waitman Gobble wrote: >> Hi, >> >> I'm having an issue with kvm_nlist failing on armv6 machine, but works >> on amd64 machines. Anyone have an idea about this? >> >> >> simple example >> >> static struct nlist nl[] = { >> #define N_HCI_RAW 0 >> { "_ng_btsocket_hci_raw_sockets" }, >> }; >> >> kvm_t *kvmd = NULL; >> kvmd = kvm_openfiles(NULL, memf, NULL, O_RDONLY, errbuf); >> kvm_nlist(kvmd, nl); >> if (nl[0].n_type == 0) { >> /* bomb - problem */ >> } >> >> >> >> # uname -a >> FreeBSD ARTiming150301 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279488: >> Sun Mar 1 10:27:33 PST 2015 >> waitman@rpidev.waitman.net:/usr/home/waitman/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/TMRDEV >> arm >> >> >> Thanks, >> >> -- >> Waitman Gobble >> Los Altos California USA >> 510-830-7975 > > > OOPs, the error: > > kvm_nlist: no namelist > > > -- > Waitman Gobble > Los Altos California USA > 510-830-7975 I'm not yet sure if this is a netgraph or bluetooth kernel module issue, or something else. kvm_nlist does not seem to resolve netgraph/bluetooth names on RPI/armv6 which causes btsockstat in base to fail with error. # btsockstat btsockstat: kvm_nlist: no namelist uname -a FreeBSD ARTiming150301 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279488: Sun Mar 1 10:27:33 PST 2015 waitman@rpidev.waitman.net:/usr/home/waitman/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/TMRDEV arm # kldstat | grep ng_ 5 1 0xc2ba0000 e000 ng_ubt.ko 7 1 0xc2bcb000 12000 ng_hci.ko 8 3 0xc2bde000 a000 ng_bluetooth.ko 13 1 0xc2cc0000 16000 ng_l2cap.ko 14 1 0xc2cd8000 24000 ng_btsocket.ko 15 1 0xc2d05000 c000 ng_socket.ko test, some things we know should not resolve and some things should. #include #include #include #include #include #include #include static struct nlist nl[] = { { "kernel_l1pa" }, { "KPML4phys" }, { "_rtstat" }, { "booha" }, { "_ng_btsocket_hci_raw_debug_level" }, { "_ng_btsocket_hci_raw_sockets" }, { "_ng_btsocket_l2cap_raw_sockets" }, { "_ng_btsocket_l2cap_sockets" }, { "_ng_btsocket_l2cap_raw_rt" }, { "_ng_btsocket_l2cap_rt" }, { "_ng_btsocket_rfcomm_sockets" }, { "_ng_btsocket_rfcomm_sessions" }, { "_rttrash" }, { "_rt_tables" }, { "" }, }; int main(int argc, char *argv[]) { int i; kvm_t *kvmd = NULL; char errbuf[_POSIX2_LINE_MAX]; kvmd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf); kvm_nlist(kvmd, nl); for (i=0;i<14;i++) { if (nl[i].n_type == 0) { printf("error: no match %i (%s)\n",i,nl[i].n_name); } else { printf("OK: %i %s\n",i,nl[i].n_name); } } return(0); } # clang -lkvm -o test test.c # ./test OK: 0 kernel_l1pa error: no match 1 (KPML4phys) OK: 2 _rtstat error: no match 3 (booha) error: no match 4 (_ng_btsocket_hci_raw_debug_level) error: no match 5 (_ng_btsocket_hci_raw_sockets) error: no match 6 (_ng_btsocket_l2cap_raw_sockets) error: no match 7 (_ng_btsocket_l2cap_sockets) error: no match 8 (_ng_btsocket_l2cap_raw_rt) error: no match 9 (_ng_btsocket_l2cap_rt) error: no match 10 (_ng_btsocket_rfcomm_sockets) error: no match 11 (_ng_btsocket_rfcomm_sessions) OK: 12 _rttrash OK: 13 _rt_tables Hopefully someone can shed some light on this problem. Thank you, -- Waitman Gobble Los Altos California USA 510-830-7975 From owner-freebsd-arm@FreeBSD.ORG Fri Apr 10 09:09:26 2015 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B74C5728; Fri, 10 Apr 2015 09:09:26 +0000 (UTC) Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com [IPv6:2607:f8b0:400c:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68B0E2BA; Fri, 10 Apr 2015 09:09:26 +0000 (UTC) Received: by vnbg190 with SMTP id g190so4038157vnb.8; Fri, 10 Apr 2015 02:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dbNIlBOr6rjtIflUZAW/zX2R0h3N7+Iq6nlFpl5IM4A=; b=RacRm4oGyqYZ4spMh+xJWZ7qcrLW+JX9+h9l/pNKLiHDwV5TwhBZi56+qXN0IF4+VH jujQmWkj9LRJ8E6Csyk9L+Ch/uPKBNJJdhmRnnVvU5KorMandW1iiAxBFxMaEPo178x6 OZqF601vYo+mCuMjJKyjgogF1hxDfCb/+ORfMrEFWjLP2HXZ9SBUY0meI/K9q2KCuFZ3 5eHEwcq8oxDO2lB5Y2Lvvcigyw3Xva7HPAo4R1kdMOKvsoCQMhE6WneDKxPvv8LrJ30f rF1YTqqPXnHHhLUqTFzhGokO0XHdCvqOv/mWqVFzQJhcJeEeYaKxUQ/97RwZvSLQKJ8c 9+hw== X-Received: by 10.52.170.52 with SMTP id aj20mr486971vdc.94.1428656965513; Fri, 10 Apr 2015 02:09:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.61.100 with HTTP; Fri, 10 Apr 2015 02:09:05 -0700 (PDT) In-Reply-To: References: <1EFF2C41-456C-476E-9BA8-712E62DF0D4E@gromit.dlib.vt.edu> From: Pratik Singhal Date: Fri, 10 Apr 2015 14:39:05 +0530 Message-ID: Subject: Re: panic: pmap_demote_section: No l2_bucket for wired mapping To: Zbigniew Bodek Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 09:09:26 -0000 I am also able to reproduce the same bug on my Cubieboard 1 with freeBSD 11-current :- I am pasting the stack trace and the boot log. boot log :- http://pastie.org/10084212 stack trace :- http://pastie.org/10084214 On Mon, Mar 23, 2015 at 6:11 AM, Zbigniew Bodek wrote: > 2015-03-22 20:45 GMT+01:00 Paul Mather : > > On Mar 22, 2015, at 7:54 AM, Michael Tuexen wrote: > > > >> Dear all, > >> > >> running head on a Raspberry Pi became unstable. When running > >> r280329 for a while (the machine is exposed to the Internet, so > >> ssh logins are continuously tried), the machine panics: > >> > >> panic: pmap_demote_section: No l2_bucket for wired mapping > >> KDB: enter: panic > > > > > > I get this panic when booting to multi-user on my newly-updated BBB > (FreeBSD 11.0-CURRENT #0 r280350). As pointed out later in this thread, > setting vm.pmap.sp_enabled=0 prevents the panic (so far) and allows booting. > > > > Cheers, > > > > Paul. > > > > I was able to reproduce this on my R-Pi too. > The bug may be related to shared libraries mapping since excluding > pmap_enter_section() (the one in the pmap_enter_object() that is > responsible for doing the work for shared libraries mappings) results > in normal operation even with page promotion/demotion enabled. > I will try to find some time to look into that to ensure that this is > not just covering the problem. If it doesn't then we may consider > disabling pmap_enter_section() (by adding "return FALSE;") to have WA > (without disabling superpages) until we find the real solution. > pmap_enter_section() was being used very rarely before shared > libraries superpage mappings were enabled so it is reasonable to think > that the bug is somewhere around. Please let me know in case you find > something. > > Best regards > zbb > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Regards, Pratik Singhal From owner-freebsd-arm@FreeBSD.ORG Fri Apr 10 09:16:56 2015 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D35CEBAC; Fri, 10 Apr 2015 09:16:56 +0000 (UTC) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 656C83E8; Fri, 10 Apr 2015 09:16:55 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 10 Apr 2015 11:16:46 +0200 id 0010E404.552794FE.00010F97 Date: Fri, 10 Apr 2015 11:16:45 +0200 From: Milan Obuch To: Pratik Singhal Subject: Re: panic: pmap_demote_section: No l2_bucket for wired mapping Message-ID: <20150410111645.55c1efb0@zeta.dino.sk> In-Reply-To: References: <1EFF2C41-456C-476E-9BA8-712E62DF0D4E@gromit.dlib.vt.edu> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; i386-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 09:16:56 -0000 On Fri, 10 Apr 2015 14:39:05 +0530 Pratik Singhal wrote: > I am also able to reproduce the same bug on my Cubieboard 1 with > freeBSD 11-current :- > > I am pasting the stack trace and the boot log. > > boot log :- http://pastie.org/10084212 > > stack trace :- http://pastie.org/10084214 > Hi, could you try adding 'options ARM_NEW_PMAP' to your kernel configs? It looks like it fixes this issue for me. If yoo can verify it, then I suggest to add this into RPI-B kernel config in our source tree for everybody, and some other kernel configs as well. Regards, Milan > On Mon, Mar 23, 2015 at 6:11 AM, Zbigniew Bodek > wrote: > > > 2015-03-22 20:45 GMT+01:00 Paul Mather : > > > On Mar 22, 2015, at 7:54 AM, Michael Tuexen > > > wrote: > > > > > >> Dear all, > > >> > > >> running head on a Raspberry Pi became unstable. When running > > >> r280329 for a while (the machine is exposed to the Internet, so > > >> ssh logins are continuously tried), the machine panics: > > >> > > >> panic: pmap_demote_section: No l2_bucket for wired mapping > > >> KDB: enter: panic > > > > > > > > > I get this panic when booting to multi-user on my newly-updated > > > BBB > > (FreeBSD 11.0-CURRENT #0 r280350). As pointed out later in this > > thread, setting vm.pmap.sp_enabled=0 prevents the panic (so far) > > and allows booting. > > > > > > Cheers, > > > > > > Paul. > > > > > > > I was able to reproduce this on my R-Pi too. > > The bug may be related to shared libraries mapping since excluding > > pmap_enter_section() (the one in the pmap_enter_object() that is > > responsible for doing the work for shared libraries mappings) > > results in normal operation even with page promotion/demotion > > enabled. I will try to find some time to look into that to ensure > > that this is not just covering the problem. If it doesn't then we > > may consider disabling pmap_enter_section() (by adding "return > > FALSE;") to have WA (without disabling superpages) until we find > > the real solution. pmap_enter_section() was being used very rarely > > before shared libraries superpage mappings were enabled so it is > > reasonable to think that the bug is somewhere around. Please let me > > know in case you find something. > > > > Best regards > > zbb > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > > "freebsd-arm-unsubscribe@freebsd.org" > > > > > From owner-freebsd-arm@FreeBSD.ORG Fri Apr 10 12:37:14 2015 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0E743B6 for ; Fri, 10 Apr 2015 12:37:14 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 922CAF2E for ; Fri, 10 Apr 2015 12:37:14 +0000 (UTC) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 0E24A25E; Fri, 10 Apr 2015 08:37:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic: pmap_demote_section: No l2_bucket for wired mapping From: Paul Mather In-Reply-To: <20150410111645.55c1efb0@zeta.dino.sk> Date: Fri, 10 Apr 2015 08:37:01 -0400 Content-Transfer-Encoding: 7bit Message-Id: <39BE85EE-FCF1-4061-9145-F0EA469AA8F1@gromit.dlib.vt.edu> References: <1EFF2C41-456C-476E-9BA8-712E62DF0D4E@gromit.dlib.vt.edu> <20150410111645.55c1efb0@zeta.dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.1878.6) Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 12:37:14 -0000 On Apr 10, 2015, at 5:16 AM, Milan Obuch wrote: > On Fri, 10 Apr 2015 14:39:05 +0530 > Pratik Singhal wrote: > >> I am also able to reproduce the same bug on my Cubieboard 1 with >> freeBSD 11-current :- >> >> I am pasting the stack trace and the boot log. >> >> boot log :- http://pastie.org/10084212 >> >> stack trace :- http://pastie.org/10084214 >> > > Hi, > > could you try adding 'options ARM_NEW_PMAP' to your kernel configs? It > looks like it fixes this issue for me. If yoo can verify it, then I > suggest to add this into RPI-B kernel config in our source tree for > everybody, and some other kernel configs as well. Just as an update, the ARM_NEW_PMAP code fixes the "No l2_bucket for wired mapping" panic I was getting on BeagleBone Black. Cheers, Paul. From owner-freebsd-arm@FreeBSD.ORG Fri Apr 10 19:19:29 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDA9389D; Fri, 10 Apr 2015 19:19:29 +0000 (UTC) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A46EC8C6; Fri, 10 Apr 2015 19:19:29 +0000 (UTC) Received: by vnbg7 with SMTP id g7so7864484vnb.11; Fri, 10 Apr 2015 12:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=vzTm65/h1i4DdtmHAQHzQEivAfNoXWQ7BVpl006+Dr0=; b=wVAaGqV8LTEtQ+pqZvIIxul7XPS/7J5R0DpjqTBHFx7OcPUfSNN8ZSGpYrWYw5HEKQ t4wNq7D0eKn9ObCUrCW57Qpbp5D5SoAGyzckX88+Uh4zCvQL+PFBPItLgF/zki14eB0R ZBxDWn87fSdIDPeGfPkFoNQynQPrHMOTGNJqH+fzB5nMLJ6J1kut4t7XyWlxgWqhqIea 7XEJK+sAoPg8utdCaRdudyPnN9gzFpUjrH755hoj4dNeDBUiqRRIrvlgVRZOm2WMKohK dr+x0qBz7hlx4MhUfUDg/OO8qum+Rebi+zk87+2clkHojOEhEHvi/XeszcWtvtW7+aX8 DBMQ== X-Received: by 10.52.78.35 with SMTP id y3mr3090046vdw.5.1428693568804; Fri, 10 Apr 2015 12:19:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.61.100 with HTTP; Fri, 10 Apr 2015 12:19:08 -0700 (PDT) From: Pratik Singhal Date: Sat, 11 Apr 2015 00:49:08 +0530 Message-ID: Subject: pmap_demote_section: No l2_bucket for wired mapping panic To: freebsd-hackers , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 19:19:30 -0000 Hello all, I am trying to boot into FreeBSD 11.0 current on my CubieBoard 1 . I have compiled the kernel in two ways along with "options ARM_NEW_PMAP" as well as without it. Whenever , I try to boot into the system the kernel panics . I am pasting the stack trace and the boot log for the compilation with ARM_NEW_PMAP enabled. People have reported previously that on R-pi if we compile with the "options ARM_NEW_PMAP" the panic issue is resolved, but it seems to have no effect on Cubieboard 1. Any ideas what could be the problem ? boot log and stack trace :- http://pastie.org/10085231 -- Regards, Pratik Singhal From owner-freebsd-arm@FreeBSD.ORG Fri Apr 10 23:01:05 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8EAC2B1; Fri, 10 Apr 2015 23:01:05 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F2C730E; Fri, 10 Apr 2015 23:01:05 +0000 (UTC) Received: by ignm3 with SMTP id m3so22807441ign.0; Fri, 10 Apr 2015 16:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T/q4zjo/GeL+7vg7RM+xP4sA2cVb+q8//52CXUs0YzQ=; b=wMoinXlQRkSdXMydtuX3S8X3JLyMQyFZNxTgQ+wbxmxxiL63+G+kXnGNsN33Kfp+r4 YlDyfuGQxoVNJE5DuEDEXqNjvFgnkqxytm/oRiljCdh1wAJuiCRkJn4nEL+Oxd0nS63O vo8iaEifFB8K2CzfjHIRyKxxLO/a+ysBRIjU0l/A353HRA9VMmqCAZJ7RtCrMOmAqLWH h9dCYVuI75Y+YRQpgk5uN1jbf3hrLXvTqvcdgj4MqQIOgf5K3E2fEKmVuCe7cmtwDFMm STSvi7wUWnTHYIXaIpXTDuVyP584RbYQnMXHQTDWv0eFf2p6XianZr6OEx1fxeXP6/aN cGBQ== MIME-Version: 1.0 X-Received: by 10.42.27.14 with SMTP id h14mr6497227icc.19.1428706865058; Fri, 10 Apr 2015 16:01:05 -0700 (PDT) Received: by 10.64.28.43 with HTTP; Fri, 10 Apr 2015 16:01:04 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Apr 2015 01:01:04 +0200 Message-ID: Subject: Re: pmap_demote_section: No l2_bucket for wired mapping panic From: Svatopluk Kraus To: Pratik Singhal Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:01:05 -0000 The point of ARM_NEW_PMAP option is that there are no l2_buckets in new armv6 pmap. So, as long as you get same panic, you are not running kernel compiled with ARM_NEW_PMAP option. Svatopluk Kraus On Fri, Apr 10, 2015 at 9:19 PM, Pratik Singhal wrote: > Hello all, I am trying to boot into FreeBSD 11.0 current on my CubieBoard 1 > . I have compiled the kernel in two ways along with "options ARM_NEW_PMAP" > as well as without it. > > Whenever , I try to boot into the system the kernel panics . I am pasting > the stack trace and the boot log for the compilation with ARM_NEW_PMAP > enabled. > > People have reported previously that on R-pi if we compile with the > "options ARM_NEW_PMAP" the panic issue is resolved, but it seems to have no > effect on Cubieboard 1. > > Any ideas what could be the problem ? > > boot log and stack trace :- http://pastie.org/10085231 > > -- > Regards, > Pratik Singhal > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Apr 11 01:28:51 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE4F69CA; Sat, 11 Apr 2015 01:28:51 +0000 (UTC) Received: from mail-vn0-x22d.google.com (mail-vn0-x22d.google.com [IPv6:2607:f8b0:400c:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C01C283; Sat, 11 Apr 2015 01:28:51 +0000 (UTC) Received: by vnbf1 with SMTP id f1so9933184vnb.5; Fri, 10 Apr 2015 18:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Fl+jlTwfEXOzLHRWtl93+7T8JgNdV79t79p/d/GGj1Q=; b=wlXIc5X6IgkkYl2u4d9BoPdiZIdKZ88vaCeXdmqtw/vd6tb94MFl1nWxpEgPjusY6t MoVM+r4NJZ7Hp1NszszZOAIcuvekhEUOyT6ItVxIw/4y0TQNFoAbeFeLvgSt1e+d+LQ2 RSdoEkc7S8ouYJ7Aqwz32ctoQ/L4yswsoKTuh9WGm6WMeLpZODnd0LaySoKxrQayjxTF Kjo+lbqqJOF43eSVP3l/qsiObNjea6f6GMxxkYDeMrovvwYVJ9WBged1ZugCHrEhHGzM mDbnYsYZ220UEReBGh2sn9AF3RaGwQL82naOmzx9x2BZdck4mgOFMViMMmZQn31DZUqT 2yNw== X-Received: by 10.52.14.200 with SMTP id r8mr4514714vdc.79.1428715729766; Fri, 10 Apr 2015 18:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.61.100 with HTTP; Fri, 10 Apr 2015 18:28:29 -0700 (PDT) In-Reply-To: References: From: Pratik Singhal Date: Sat, 11 Apr 2015 06:58:29 +0530 Message-ID: Subject: Re: pmap_demote_section: No l2_bucket for wired mapping panic To: Svatopluk Kraus Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 01:28:51 -0000 I have double checked everything, recompiled kernel from scratch imade sure that I ncluded the line "options ARM_NEW_PMAP" in the kernel configuration file and I am still getting the same panic. Is there something at runtime that I can do to make sure that the kernel I am running is compiled with ARM_NEW_PMAP ? On Sat, Apr 11, 2015 at 4:31 AM, Svatopluk Kraus wrote: > The point of ARM_NEW_PMAP option is that there are no l2_buckets in > new armv6 pmap. So, as long as you get same panic, you are not running > kernel compiled with ARM_NEW_PMAP option. > > Svatopluk Kraus > > > On Fri, Apr 10, 2015 at 9:19 PM, Pratik Singhal wrote: > > Hello all, I am trying to boot into FreeBSD 11.0 current on my > CubieBoard 1 > > . I have compiled the kernel in two ways along with "options > ARM_NEW_PMAP" > > as well as without it. > > > > Whenever , I try to boot into the system the kernel panics . I am pasting > > the stack trace and the boot log for the compilation with ARM_NEW_PMAP > > enabled. > > > > People have reported previously that on R-pi if we compile with the > > "options ARM_NEW_PMAP" the panic issue is resolved, but it seems to have > no > > effect on Cubieboard 1. > > > > Any ideas what could be the problem ? > > > > boot log and stack trace :- http://pastie.org/10085231 > > > > -- > > Regards, > > Pratik Singhal > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Regards, Pratik Singhal From owner-freebsd-arm@FreeBSD.ORG Sat Apr 11 02:36:02 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0F123B5; Sat, 11 Apr 2015 02:36:02 +0000 (UTC) Received: from relay.mailchannels.net (si-002-i39.relay.mailchannels.net [184.154.112.204]) by mx1.freebsd.org (Postfix) with ESMTP id D401FADC; Sat, 11 Apr 2015 02:36:00 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp6.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 05D5E1D0AA3; Sat, 11 Apr 2015 02:20:13 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp6.ore.mailhop.org (smtp6.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Sat, 11 Apr 2015 02:20:13 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428718813428:1587006772 X-MC-Ingress-Time: 1428718813427 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp6.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Ygl1n-0007jV-Tb; Sat, 11 Apr 2015 02:20:12 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t3B2K9Hp009055; Fri, 10 Apr 2015 20:20:09 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/Z7zGJvfgk12j4JfBDyl1g Message-ID: <1428718809.1182.31.camel@freebsd.org> Subject: Re: pmap_demote_section: No l2_bucket for wired mapping panic From: Ian Lepore To: Pratik Singhal Date: Fri, 10 Apr 2015 20:20:09 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: freebsd-hackers , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 02:36:02 -0000 Reply at the bottom, where it belongs. On Sat, 2015-04-11 at 06:58 +0530, Pratik Singhal wrote: > I have double checked everything, recompiled kernel from scratch imade sure > that I ncluded the line "options ARM_NEW_PMAP" in the kernel configuration > file and I am still getting the same panic. > > Is there something at runtime that I can do to make sure that the kernel I > am running is compiled with ARM_NEW_PMAP ? > > > > On Sat, Apr 11, 2015 at 4:31 AM, Svatopluk Kraus wrote: > > > The point of ARM_NEW_PMAP option is that there are no l2_buckets in > > new armv6 pmap. So, as long as you get same panic, you are not running > > kernel compiled with ARM_NEW_PMAP option. > > > > Svatopluk Kraus > > > > [...] > > > >From the announcement of the ARM_NEW_PMAP option... If you need to check whether the new or old code is running on a system, use "sysctl vm.pmap.pte1.promotions", if that gives an "unknown oid" error you're running the old code. Other evidence: revolution > grep l2_bucket pmap-v6-new.c revolution > You can't be getting a panic about l2_bucket stuff from code that doesn't have anything in it about l2 buckets. Something must have gone wrong with the way you built and installed the new kernel. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Apr 11 08:15:13 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 014E198E; Sat, 11 Apr 2015 08:15:12 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38301FFA; Sat, 11 Apr 2015 08:15:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428740082; l=2306; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=bV9NmMBMEQC18pJp5DEZGmFDQuSpd6Y8YNX1v4ctknw=; b=RI9A1E3nwoKhoI6JxSRlwKfJ/XPJYmRb141dwVpZgRVjgDn/sVibcXdY3Yp9Q7VJUBP F6LpBQk0C44ScYHS+MWjZLwpmFSfKzQ7h5FSrnNkNrSdsxhFB3jSvlqQvkBmZ+AcXXCGU HhWQDrXcXbX7HP2KaUnPTbpq8cq7LvbgSlo= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg46scv/pkmS X-RZG-CLASS-ID: mo00 Received: from quad (p5486816B.dip0.t-ipconnect.de [84.134.129.107]) by smtp.strato.de (RZmta 37.5 DYNA|AUTH) with ESMTPSA id I010cfr3B8ESBEw (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve sect571r1 with 571 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 11 Apr 2015 10:14:28 +0200 (CEST) Date: Sat, 11 Apr 2015 08:14:27 +0000 From: Ulrich Grey To: Ian Lepore Subject: Re: pmap_demote_section: No l2_bucket for wired mapping panic Message-Id: <20150411081427.2f4fc14feb08cee948734d66@ulrich-grey.de> In-Reply-To: <1428718809.1182.31.camel@freebsd.org> References: <1428718809.1182.31.camel@freebsd.org> Organization: - X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 08:15:13 -0000 This kernel is running ARM_NEW_PMAP: root@wqtest:/usr/home/gwgpi # sysctl vm.pmap. vm.pmap.pv_entry_spare: 10379 vm.pmap.pv_entry_allocs: 1486593921 vm.pmap.pv_entry_frees: 1486577084 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 5598313 vm.pmap.pc_chunk_allocs: 5598394 vm.pmap.pc_chunk_count: 81 vm.pmap.pv_entry_count: 16837 vm.pmap.pte1.promotions: 3530 vm.pmap.pte1.p_failures: 20352 vm.pmap.pte1.mappings: 721715 vm.pmap.pte1.demotions: 508 vm.pmap.sp_enabled: 1 vm.pmap.nkpt2pg: 32 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 1745184 root@wqtest:/usr/home/gwgpi # ---------------------------------- On Fri, 10 Apr 2015 20:20:09 -0600 Ian Lepore wrote: > Reply at the bottom, where it belongs. > > On Sat, 2015-04-11 at 06:58 +0530, Pratik Singhal wrote: > > I have double checked everything, recompiled kernel from scratch imade sure > > that I ncluded the line "options ARM_NEW_PMAP" in the kernel configuration > > file and I am still getting the same panic. > > > > Is there something at runtime that I can do to make sure that the kernel I > > am running is compiled with ARM_NEW_PMAP ? > > > > > > > > On Sat, Apr 11, 2015 at 4:31 AM, Svatopluk Kraus wrote: > > > > > The point of ARM_NEW_PMAP option is that there are no l2_buckets in > > > new armv6 pmap. So, as long as you get same panic, you are not running > > > kernel compiled with ARM_NEW_PMAP option. > > > > > > Svatopluk Kraus > > > > > > > [...] > > > > > > From the announcement of the ARM_NEW_PMAP option... > > If you need to check whether the new or old code is running on a > system, use "sysctl vm.pmap.pte1.promotions", if that gives an > "unknown oid" error you're running the old code. > > Other evidence: > > revolution > grep l2_bucket pmap-v6-new.c > revolution > > > You can't be getting a panic about l2_bucket stuff from code that > doesn't have anything in it about l2 buckets. Something must have gone > wrong with the way you built and installed the new kernel. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Apr 11 08:47:17 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90D33C61; Sat, 11 Apr 2015 08:47:17 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C616535E; Sat, 11 Apr 2015 08:47:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428742007; l=2869; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=x0W0hwx2w7DDUUoj29heI+WvHD7FhhJGBdmaxK1p9Dc=; b=tqw4aqwsKOubnxak9vdJzXABPapwPL27r02Syo8c3FcPF5adYeMnaf3PLjzEiCdhRHD AjAldnWU00j40b4PbSa257nDwA82N+otm7rKOaS15/t2chjkwGegWnn5GVRSMcESlfd/9 cosyRPIoGpaN1KH/8XEUoEkXEKtp8PfD9NA= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg46scv/pkmS X-RZG-CLASS-ID: mo00 Received: from quad (p5486816B.dip0.t-ipconnect.de [84.134.129.107]) by smtp.strato.de (RZmta 37.5 DYNA|AUTH) with ESMTPSA id c06599r3B8kVAWa (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve sect571r1 with 571 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 11 Apr 2015 10:46:31 +0200 (CEST) Date: Sat, 11 Apr 2015 08:46:30 +0000 From: Ulrich Grey To: Ulrich Grey Subject: Re: pmap_demote_section: No l2_bucket for wired mapping panic Message-Id: <20150411084630.e424b59c1c327add498721e2@ulrich-grey.de> In-Reply-To: <20150411081427.2f4fc14feb08cee948734d66@ulrich-grey.de> References: <1428718809.1182.31.camel@freebsd.org> <20150411081427.2f4fc14feb08cee948734d66@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 08:47:17 -0000 sysctl vm.pmap.pte1.promotions It's the figure "1" not the letter "l"! ------------------------------------------ On Sat, 11 Apr 2015 08:14:27 +0000 Ulrich Grey wrote: > This kernel is running ARM_NEW_PMAP: > > root@wqtest:/usr/home/gwgpi # sysctl vm.pmap. > vm.pmap.pv_entry_spare: 10379 > vm.pmap.pv_entry_allocs: 1486593921 > vm.pmap.pv_entry_frees: 1486577084 > vm.pmap.pc_chunk_tryfail: 0 > vm.pmap.pc_chunk_frees: 5598313 > vm.pmap.pc_chunk_allocs: 5598394 > vm.pmap.pc_chunk_count: 81 > vm.pmap.pv_entry_count: 16837 > vm.pmap.pte1.promotions: 3530 > vm.pmap.pte1.p_failures: 20352 > vm.pmap.pte1.mappings: 721715 > vm.pmap.pte1.demotions: 508 > vm.pmap.sp_enabled: 1 > vm.pmap.nkpt2pg: 32 > vm.pmap.shpgperproc: 200 > vm.pmap.pv_entry_max: 1745184 > root@wqtest:/usr/home/gwgpi # > ---------------------------------- > On Fri, 10 Apr 2015 20:20:09 -0600 > Ian Lepore wrote: > > > Reply at the bottom, where it belongs. > > > > On Sat, 2015-04-11 at 06:58 +0530, Pratik Singhal wrote: > > > I have double checked everything, recompiled kernel from scratch imade sure > > > that I ncluded the line "options ARM_NEW_PMAP" in the kernel configuration > > > file and I am still getting the same panic. > > > > > > Is there something at runtime that I can do to make sure that the kernel I > > > am running is compiled with ARM_NEW_PMAP ? > > > > > > > > > > > > On Sat, Apr 11, 2015 at 4:31 AM, Svatopluk Kraus wrote: > > > > > > > The point of ARM_NEW_PMAP option is that there are no l2_buckets in > > > > new armv6 pmap. So, as long as you get same panic, you are not running > > > > kernel compiled with ARM_NEW_PMAP option. > > > > > > > > Svatopluk Kraus > > > > > > > > > > [...] > > > > > > > > > From the announcement of the ARM_NEW_PMAP option... > > > > If you need to check whether the new or old code is running on a > > system, use "sysctl vm.pmap.pte1.promotions", if that gives an > > "unknown oid" error you're running the old code. > > > > Other evidence: > > > > revolution > grep l2_bucket pmap-v6-new.c > > revolution > > > > > You can't be getting a panic about l2_bucket stuff from code that > > doesn't have anything in it about l2 buckets. Something must have gone > > wrong with the way you built and installed the new kernel. > > > > -- Ian > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Apr 11 09:14:26 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BB0C69E; Sat, 11 Apr 2015 09:14:26 +0000 (UTC) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39496832; Sat, 11 Apr 2015 09:14:26 +0000 (UTC) Received: by vnbf1 with SMTP id f1so10636891vnb.5; Sat, 11 Apr 2015 02:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0tgh5m+Y5ayJDVTtHp2ORpmfKq7Duu67Bc1EmSGCRss=; b=a+qNB/zTvlXkj6jHne7QtPAGLxS3qwEfUNQ9dyoggcdJINCVsFEza8JGXeO8zVv2np XxqLoE2MzkyGtrxaUiwPifUhHSmaM+YyaZnygoMIXHxQ3Fd/6XIgoxdo2O6gWPxUxQ8c D9GorrZVdzMVhOYPSoofAASuGhq9iTwibB2t/Mj35gi8+XAPECnP2y0IyLxO3A2HLyhv 87Sw8BhwoZToczPOA+gGeguRFuIiNLp3K87iWlpqCNzJvkDr0BwbSO//3+njKQdJDOxz AmCemAOp6LN1RyZAC6O0uO2jxiEDWi6vIW1Ca7DE0OBm8Hj8BksRTa6qPmYF3h8Kudh6 XpHQ== X-Received: by 10.52.78.35 with SMTP id y3mr6060073vdw.5.1428743665277; Sat, 11 Apr 2015 02:14:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.61.100 with HTTP; Sat, 11 Apr 2015 02:14:05 -0700 (PDT) In-Reply-To: <20150411084630.e424b59c1c327add498721e2@ulrich-grey.de> References: <1428718809.1182.31.camel@freebsd.org> <20150411081427.2f4fc14feb08cee948734d66@ulrich-grey.de> <20150411084630.e424b59c1c327add498721e2@ulrich-grey.de> From: Pratik Singhal Date: Sat, 11 Apr 2015 14:44:05 +0530 Message-ID: Subject: Re: pmap_demote_section: No l2_bucket for wired mapping panic To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 09:14:26 -0000 It seems that the issue is resolved for now, as many people suspected I was using the wrong kernel. I was making the changes in the different config file than the one from which the kernel was being compiled. I again recompiled the kenrel, this time correctly and the issue is resolved now. Regards, Pratik Singhal On Sat, Apr 11, 2015 at 2:16 PM, Ulrich Grey wrote: > > sysctl vm.pmap.pte1.promotions > > It's the figure "1" not the letter "l"! > ------------------------------------------ > On Sat, 11 Apr 2015 08:14:27 +0000 > Ulrich Grey wrote: > > > This kernel is running ARM_NEW_PMAP: > > > > root@wqtest:/usr/home/gwgpi # sysctl vm.pmap. > > vm.pmap.pv_entry_spare: 10379 > > vm.pmap.pv_entry_allocs: 1486593921 > > vm.pmap.pv_entry_frees: 1486577084 > > vm.pmap.pc_chunk_tryfail: 0 > > vm.pmap.pc_chunk_frees: 5598313 > > vm.pmap.pc_chunk_allocs: 5598394 > > vm.pmap.pc_chunk_count: 81 > > vm.pmap.pv_entry_count: 16837 > > vm.pmap.pte1.promotions: 3530 > > vm.pmap.pte1.p_failures: 20352 > > vm.pmap.pte1.mappings: 721715 > > vm.pmap.pte1.demotions: 508 > > vm.pmap.sp_enabled: 1 > > vm.pmap.nkpt2pg: 32 > > vm.pmap.shpgperproc: 200 > > vm.pmap.pv_entry_max: 1745184 > > root@wqtest:/usr/home/gwgpi # > > ---------------------------------- > > On Fri, 10 Apr 2015 20:20:09 -0600 > > Ian Lepore wrote: > > > > > Reply at the bottom, where it belongs. > > > > > > On Sat, 2015-04-11 at 06:58 +0530, Pratik Singhal wrote: > > > > I have double checked everything, recompiled kernel from scratch > imade sure > > > > that I ncluded the line "options ARM_NEW_PMAP" in the kernel > configuration > > > > file and I am still getting the same panic. > > > > > > > > Is there something at runtime that I can do to make sure that the > kernel I > > > > am running is compiled with ARM_NEW_PMAP ? > > > > > > > > > > > > > > > > On Sat, Apr 11, 2015 at 4:31 AM, Svatopluk Kraus > wrote: > > > > > > > > > The point of ARM_NEW_PMAP option is that there are no l2_buckets in > > > > > new armv6 pmap. So, as long as you get same panic, you are not > running > > > > > kernel compiled with ARM_NEW_PMAP option. > > > > > > > > > > Svatopluk Kraus > > > > > > > > > > > > > [...] > > > > > > > > > > > > From the announcement of the ARM_NEW_PMAP option... > > > > > > If you need to check whether the new or old code is running on > a > > > system, use "sysctl vm.pmap.pte1.promotions", if that gives an > > > "unknown oid" error you're running the old code. > > > > > > Other evidence: > > > > > > revolution > grep l2_bucket pmap-v6-new.c > > > revolution > > > > > > > You can't be getting a panic about l2_bucket stuff from code that > > > doesn't have anything in it about l2 buckets. Something must have gone > > > wrong with the way you built and installed the new kernel. > > > > > > -- Ian > > > > > > > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Regards, Pratik Singhal