From owner-freebsd-arm@freebsd.org Sun Oct 20 21:00:04 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D27A2169E7B for ; Sun, 20 Oct 2019 21:00:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46xBx05Dcyz4LZ3 for ; Sun, 20 Oct 2019 21:00:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9620F1985A for ; Sun, 20 Oct 2019 21:00:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9KL04ik015940 for ; Sun, 20 Oct 2019 21:00:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9KL04ln015937 for freebsd-arm@FreeBSD.org; Sun, 20 Oct 2019 21:00:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201910202100.x9KL04ln015937@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 20 Oct 2019 21:00:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2019 21:00:04 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 2 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Mon Oct 21 00:04:41 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 13CBC16E798 for ; Mon, 21 Oct 2019 00:04:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46xH1y70BQz4WBb for ; Mon, 21 Oct 2019 00:04:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id x9L04Xm0014471 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Oct 2019 17:04:34 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x9L04XxX014470; Sun, 20 Oct 2019 17:04:33 -0700 (PDT) (envelope-from fbsd) Date: Sun, 20 Oct 2019 17:04:33 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Swap_pager messages when no swap is in use Message-ID: <20191021000433.GA14127@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 46xH1y70BQz4WBb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.13 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.867,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.08)[ip: (0.33), ipnet: 50.1.16.0/20(0.17), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.98)[-0.981,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 00:04:41 -0000 While running svnlite to update sources on a Pi3 running -currrent I was surprised to notice a flurry of swap_pager: indefinite wait buffer: bufobj: 0, blkno: 133095, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 136056, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 140560, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 134290, size: 8192 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 124869, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 125113, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 142799, size: 4096 messages when no swap seemed to be in use. Gstat reported much congestion of the microSD card, holding / and half the swap, but there was no obvious activity reading or writing swap, just the root partition. Should this be considered normal? It strikes me as very odd. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Mon Oct 21 00:14:53 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E878216EB5D for ; Mon, 21 Oct 2019 00:14:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46xHFm2zssz4Wct for ; Mon, 21 Oct 2019 00:14:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82f.google.com with SMTP id g50so4068532qtb.4 for ; Sun, 20 Oct 2019 17:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ul0tdSDF58yLIcpCLwtkGuyR2jpyIXsVaVHjr5xPk+E=; b=q0NBqtqZGeOfighUEd/DCG/cvpw0oRLuCmXfkUm5bX+agCqexwHDGmzKEnIJpCQLEy me6Aw6PcmpmuzMkonU4yBj4ck3bgvvxFkjPy5Ym6IjgFjgZERDwctQK8R5K9j0VcAkqR sdw9HLzK7yufR4VIe8rkOMVU3Y4qGSB5kvFJupsI9XyoFV33epYlVCml/SxA1X6hGj7B M0rAWlWO5pIFUswlOOhv7oM3ixEsgWeJURWa/imlLn2F5WovP46Jr52LMgbFKfQwhoHN gpP99EfUCCf2c7Wdu/vqX5V/53Hd6HuE9sDMxrGtvpBB2sh9h9/uuBhAOc3Lx0yhTKMJ aK3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ul0tdSDF58yLIcpCLwtkGuyR2jpyIXsVaVHjr5xPk+E=; b=dAhKR5Ih0mSkffl1UH+d6j7Elr9UsvMglABYkaHI0tOKXSfif0G+wyYVTWgtXPKz4x Up/wVlIW5dTWjsUIJH23B8smEuoYJqxSQIu1kkRVlJ/k5PalLuIfV9vg3v8Pwkdr9jA8 S+aQr8dnpVXENQDzNEOo74NUCQc9ld8o5d7w/q44WV2+JPmVw0ppa2lqhVzEV57Zn+F+ eJjL2580RwntmA1RfP8KtnTqRVy/Ii/sKPSpJBM7UPffd5rduPs51SJeJIN1GwgAMoHO 1oxnpOIBKTZg/Je0K4NNtiCenycXHtWUs1XNDtwcoW17kZGd1Ix3HOONH8f4lEVb6gF4 dixw== X-Gm-Message-State: APjAAAVB1V1LGewf9a2Gb96V9X651dA7D7EWkzhDQ/nMB2IDcQI4B4Xl Z/N8eRJv5iPAv4gfLdECQ59sZkaT34biDayaomGjw7fXW6o= X-Google-Smtp-Source: APXvYqwnA6qjTpxpv/9/UpDqB5MUS+M+gxsqKvcqMArCjxQrk8kdS3XsBQojv4uO2YhRDR0Ip2vtaKjupUCejyixG9w= X-Received: by 2002:ad4:5004:: with SMTP id s4mr659893qvo.87.1571616890093; Sun, 20 Oct 2019 17:14:50 -0700 (PDT) MIME-Version: 1.0 References: <20191021000433.GA14127@www.zefox.net> In-Reply-To: <20191021000433.GA14127@www.zefox.net> From: Warner Losh Date: Sun, 20 Oct 2019 18:14:37 -0600 Message-ID: Subject: Re: Swap_pager messages when no swap is in use To: bob prohaska Cc: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 46xHFm2zssz4Wct X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=q0NBqtqZ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::82f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[f.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.79)[ip: (-9.35), ipnet: 2607:f8b0::/32(-2.45), asn: 15169(-2.08), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 00:14:54 -0000 On Sun, Oct 20, 2019, 6:04 PM bob prohaska wrote: > While running svnlite to update sources on a Pi3 running -currrent > I was surprised to notice a flurry of > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 133095, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 136056, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 140560, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 134290, size: 8192 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 124869, size: 16384 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 125113, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 142799, size: 4096 > messages when no swap seemed to be in use. Gstat reported much congestion > of the microSD card, holding / and half the swap, but there was no obvious > activity reading or writing swap, just the root partition. > > Should this be considered normal? It strikes me as very odd. > It took more than 30s for the IO to complete. Sadly, this is normal for cheap SD cards. Warner Thanks for reading, > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Oct 21 00:43:19 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3519316F2A0 for ; Mon, 21 Oct 2019 00:43:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46xHtZ2Wz2z4XhS for ; Mon, 21 Oct 2019 00:43:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id x9L0hHD4014693 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Oct 2019 17:43:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x9L0hHCD014692; Sun, 20 Oct 2019 17:43:17 -0700 (PDT) (envelope-from fbsd) Date: Sun, 20 Oct 2019 17:43:17 -0700 From: bob prohaska To: Warner Losh Cc: freebsd-arm@freebsd.org Subject: Re: Swap_pager messages when no swap is in use Message-ID: <20191021004317.GB14127@www.zefox.net> References: <20191021000433.GA14127@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 46xHtZ2Wz2z4XhS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.850,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.08)[ip: (0.33), ipnet: 50.1.16.0/20(0.16), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.98)[-0.977,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 00:43:19 -0000 On Sun, Oct 20, 2019 at 06:14:37PM -0600, Warner Losh wrote: > On Sun, Oct 20, 2019, 6:04 PM bob prohaska wrote: > > > While running svnlite to update sources on a Pi3 running -currrent > > I was surprised to notice a flurry of > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 133095, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 136056, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 140560, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 134290, size: 8192 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 124869, size: 16384 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 125113, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 142799, size: 4096 > > messages when no swap seemed to be in use. Gstat reported much congestion > > of the microSD card, holding / and half the swap, but there was no obvious > > activity reading or writing swap, just the root partition. > > > > Should this be considered normal? It strikes me as very odd. > > > > It took more than 30s for the IO to complete. Sadly, this is normal for > cheap SD cards. > Ok, but why is the swapping system complaining when there's no swapping going on? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Mon Oct 21 00:46:00 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 60E0A16F34F for ; Mon, 21 Oct 2019 00:46:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46xHxf4pcWz4XlW for ; Mon, 21 Oct 2019 00:45:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x832.google.com with SMTP id m15so18402379qtq.2 for ; Sun, 20 Oct 2019 17:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qoq8KFFLs/mADfS9KehvNLfNxjW/7q5cVrFmrp0sGC0=; b=G5zK+/lT/u8q6AdBVUFmRwpvdkqxADKu6+wxjfAZzoSnMvWwRqWPaa4wDunfMArLsv YTyRlWmKzJs/4gtWKDvqaXjg1cdh1en3A2KFBN/6Qn3On3/FfycOXPWd6/f0aVQxv8VO o8hHEuvZ1JEGKeK39wRXxINOBDSYFrISPBw4RmhzNjhgJvU4HV3sKarJA5JkRZJaSMKD Mss52y10472QGwc8Zh5IUtCLgZ7gZVI/OVMWTk7/5oK46KM0ANvK6hsyHQH1ICiTWgxM zdkxa2IXsMgb8AlV4jIuZ8DW1jTqDykSOy18ERWcifBL6ZkEQCz7SKbk3TTO0f7rbQ3W DF4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qoq8KFFLs/mADfS9KehvNLfNxjW/7q5cVrFmrp0sGC0=; b=s9CwB43ocMdEhCStFeF+Tej0mX08JIq5DRLmdjqyJJ9oK9Z6aap9QX3xvmKg7jct2K bdh8JWilEqVh6avggz164EWFjtKFsLHqUF+ZyRGhpjoyXxwTX1WtbAjqau0Th81TrsFM JD3rZspqALE5IiynIesUNGZmdSYekvDVlfhQ31rKLoFulYZQvB9SssREux2r/kTxy0Rh QJYk6gsCDmMDF8sWIJTAx0mZrSmxlAmgL4ZcYiYeTa8RIuuBTkEG4ducs8T9I9zN0UAC MaB635eWFnK5dNdWKpj9xebYpX3/lXDlU8rq9pABq91SqaNL4JFoBl0gx5PpVzudoiQv fVvQ== X-Gm-Message-State: APjAAAVEgjYYUaXimkDEr8/VKDBFfcyVA9562mau4EWZ5VTT+BN0M/uU oW5yQlxsNKC6dkmS+5iwDEe9xkZUifGMT15EmSTUNNQJ X-Google-Smtp-Source: APXvYqwtSNyaq/I1o7BMtexqlsTOwRV7Ij/K1iGnU23ix8z1Lup5aUehIQDqjfMqzVv2i/xWrPjNnqRj7sD2Wb78wYk= X-Received: by 2002:aed:3be9:: with SMTP id s38mr16615770qte.175.1571618757100; Sun, 20 Oct 2019 17:45:57 -0700 (PDT) MIME-Version: 1.0 References: <20191021000433.GA14127@www.zefox.net> <20191021004317.GB14127@www.zefox.net> In-Reply-To: <20191021004317.GB14127@www.zefox.net> From: Warner Losh Date: Sun, 20 Oct 2019 18:45:45 -0600 Message-ID: Subject: Re: Swap_pager messages when no swap is in use To: bob prohaska Cc: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 46xHxf4pcWz4XlW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=G5zK+/lT; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::832) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.79)[ip: (-9.38), ipnet: 2607:f8b0::/32(-2.45), asn: 15169(-2.08), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 00:46:00 -0000 On Sun, Oct 20, 2019, 6:43 PM bob prohaska wrote: > On Sun, Oct 20, 2019 at 06:14:37PM -0600, Warner Losh wrote: > > On Sun, Oct 20, 2019, 6:04 PM bob prohaska wrote: > > > > > While running svnlite to update sources on a Pi3 running -currrent > > > I was surprised to notice a flurry of > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 133095, size: > 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 136056, size: > 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 140560, size: > 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 134290, size: > 8192 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 124869, size: > 16384 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 125113, size: > 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 142799, size: > 4096 > > > messages when no swap seemed to be in use. Gstat reported much > congestion > > > of the microSD card, holding / and half the swap, but there was no > obvious > > > activity reading or writing swap, just the root partition. > > > > > > Should this be considered normal? It strikes me as very odd. > > > > > > > It took more than 30s for the IO to complete. Sadly, this is normal for > > cheap SD cards. > > > > Ok, but why is the swapping system complaining when there's no swapping > going on? > The swap pager is complaining. It is used for things other than pure swapping to a swap partition... Warner Thanks for reading, > > bob prohaska > > From owner-freebsd-arm@freebsd.org Mon Oct 21 07:52:56 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 47C02177299 for ; Mon, 21 Oct 2019 07:52:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46xTQJ0X1Xz3PnZ for ; Mon, 21 Oct 2019 07:52:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D078B20E59 for ; Mon, 21 Oct 2019 07:52:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9L7qt4g088510 for ; Mon, 21 Oct 2019 07:52:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9L7qtri088509 for freebsd-arm@FreeBSD.org; Mon, 21 Oct 2019 07:52:55 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 241388] The snapshot images of CURRENT for RPi-B do not boot till login-prompt any more Date: Mon, 21 Oct 2019 07:52:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: iz-rpi03@hs-karlsruhe.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 07:52:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241388 Bug ID: 241388 Summary: The snapshot images of CURRENT for RPi-B do not boot till login-prompt any more Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: iz-rpi03@hs-karlsruhe.de Due to an unfortunate update of an RPi-B (processes are terminated with signal 4 during boot) I noticed, that the newer images provided at https://download.freebsd.org/ftp/snapshots/arm/armv6/ISO-IMAGES/13.0/ shows the same problem. The last image which is booting fine is FreeBSD-13.0-CURRENT-arm-armv6-RPI-B-20191004-r353072.img.xz. Booting the newer images looks always like this: uhub1: 3 ports with 2 removable, self powered Growing root partition to fill device pid 37 (awk), jid 0, uid 0: exited on signal 4 Illegal instruction pid 40 (awk), jid 0, uid 0: exited on signal 4 Illegal instruction Don't know how to grow root filesystem type:=20 ugen0.3: at usbus0 smsc0 on uhub1 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 smscphy0: PHY 1 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: xxxxxxx pid 46 (logger), jid 0, uid 0: exited on signal 4 Illegal instruction /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, genera= ting a new one pid 47 (sleep), jid 0, uid 0: exited on signal 4 Illegal instruction Setting hostuuid: a-b-c-d. Setting hostid: 0xabcd. No suitable dump device was found. ugen0.4: at usbus0 ukbd0 on uhub1 ukbd0: on usbu= s0 kbd1 at ukbd0 Starting file system checks: /dev/ufs/roopid 68 (fsck_ufs), jid 0, uid 0: exited on signal 4 tfs: FILE SYSTEM CLEAN; SKIPPING CHECKS fsck: /dev/ufs/rootfs: Illegal instruction Unknown error 1; help! ERROR: ABORTING BOOT (sending SIGTER=20 With a disabled fsck in /etc/fstab, my unfortunate update shows a login-pro= mpt. But a successful login is not possible due to signal 4. Ralf --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Oct 22 13:57:20 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 99DE615B796 for ; Tue, 22 Oct 2019 13:57:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46yFSH5LLQz3Jdg; Tue, 22 Oct 2019 13:57:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 473dd183; Tue, 22 Oct 2019 15:57:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Rtgxj4o6kQGXCbaxkXRM+Om3t9k=; b=tckObeH9qhS3QfX/K+aN1iicG4S4 ZHlwHuSBDeA2lcj5ewhPh/M3Zpn/1l1bB6SXHNJ/BE4J0VlbsuqX+/6aKWucdYsf J6hiz5bVL2mIDNvdF8XdNCBM/ZMv1rsM+57K/y9KuM8/HPDSLAXNTSfTe7Ms+WwF MEJTAvnwNN31XvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=aZpl2HFoxSHd2fG6VUOrsrQRGZK+KbZUmkCSoErj4NTHOsNpvXDoqi0r 7ovDMeJXZCoqv9mt4sjzci4CtE3kwKGmSre26YYK541rTWjxSIOwvktHMF7tua51 k3WciOklayqT7cVKCZjW8LCLD4zogLUbJzx+GG1yyFlB4PKJK48= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id b3c0a094 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 22 Oct 2019 15:57:16 +0200 (CEST) Date: Tue, 22 Oct 2019 15:57:16 +0200 From: Emmanuel Vadot To: Gary Otten Cc: freebsd-arm@freebsd.org, mmel@freebsd.org Subject: Re: GPIO on Olimex A64 board. Bank E not working. Message-Id: <20191022155716.3ebf30f63e02409aee2a6679@bidouilliste.com> In-Reply-To: <20191018134326.dce3f37b8418ea9a2c0095a1@bidouilliste.com> References: <20191015131842.370e113b9f494ead760b9b6f@bidouilliste.com> <20191015175901.1d0173f27798f15c25c037de@bidouilliste.com> <20191018133131.3063a80860e4906e0fd67f2c@bidouilliste.com> <20191018134326.dce3f37b8418ea9a2c0095a1@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46yFSH5LLQz3Jdg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mail header.b=tckObeH9; dmarc=none; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.177.182 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.23 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mail]; NEURAL_HAM_MEDIUM(-0.75)[-0.748,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.83.177.182/32]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bidouilliste.com]; NEURAL_HAM_LONG(-0.97)[-0.965,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.38)[ip: (-0.63), ipnet: 212.83.160.0/19(2.43), asn: 12876(0.11), country: FR(-0.00)]; ASN(0.00)[asn:12876, ipnet:212.83.160.0/19, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 13:57:20 -0000 On Fri, 18 Oct 2019 13:43:26 +0200 Emmanuel Vadot wrote: > On Fri, 18 Oct 2019 13:31:31 +0200 > Emmanuel Vadot wrote: > > > On Tue, 15 Oct 2019 13:26:46 -0400 > > Gary Otten wrote: > > > > > Ok, I placed hw.regulator.disable_unused=0 in /boot/loader.conf. Here is > > > the results, also still no output on the E bank. > > > > > > root@:/dev # sysctl hw.regulator > > > hw.regulator.dc1sw.uvolt: 0 > > > hw.regulator.dc1sw.always_on: 0 > > > hw.regulator.dc1sw.boot_on: 0 > > > hw.regulator.dc1sw.enable_cnt: 0 > > > hw.regulator.dc1sw.enable_delay: 0 > > > hw.regulator.dc1sw.ramp_delay: 0 > > > hw.regulator.dc1sw.max_uamp: 0 > > > hw.regulator.dc1sw.min_uamp: 0 > > > hw.regulator.dc1sw.max_uvolt: 0 > > > hw.regulator.dc1sw.min_uvolt: 0 > > > hw.regulator.ldo-io1.always_on: 0 > > > hw.regulator.ldo-io1.boot_on: 0 > > > hw.regulator.ldo-io1.enable_cnt: 0 > > > hw.regulator.ldo-io1.enable_delay: 0 > > > hw.regulator.ldo-io1.ramp_delay: 0 > > > hw.regulator.ldo-io1.max_uamp: 0 > > > hw.regulator.ldo-io1.min_uamp: 0 > > > hw.regulator.ldo-io1.max_uvolt: 3300000 > > > hw.regulator.ldo-io1.min_uvolt: 700000 > > > hw.regulator.ldo-io0.always_on: 0 > > > hw.regulator.ldo-io0.boot_on: 0 > > > hw.regulator.ldo-io0.enable_cnt: 0 > > > hw.regulator.ldo-io0.enable_delay: 0 > > > hw.regulator.ldo-io0.ramp_delay: 0 > > > hw.regulator.ldo-io0.max_uamp: 0 > > > hw.regulator.ldo-io0.min_uamp: 0 > > > hw.regulator.ldo-io0.max_uvolt: 3300000 > > > hw.regulator.ldo-io0.min_uvolt: 700000 > > > hw.regulator.vdd-cpus.uvolt: 1100000 > > > hw.regulator.vdd-cpus.always_on: 1 > > > hw.regulator.vdd-cpus.boot_on: 0 > > > hw.regulator.vdd-cpus.enable_cnt: 0 > > > hw.regulator.vdd-cpus.enable_delay: 0 > > > hw.regulator.vdd-cpus.ramp_delay: 0 > > > hw.regulator.vdd-cpus.max_uamp: 0 > > > hw.regulator.vdd-cpus.min_uamp: 0 > > > hw.regulator.vdd-cpus.max_uvolt: 1100000 > > > hw.regulator.vdd-cpus.min_uvolt: 1100000 > > > hw.regulator.vcc-1v2-hsic.uvolt: 1200000 > > > hw.regulator.vcc-1v2-hsic.always_on: 0 > > > hw.regulator.vcc-1v2-hsic.boot_on: 0 > > > hw.regulator.vcc-1v2-hsic.enable_cnt: 0 > > > hw.regulator.vcc-1v2-hsic.enable_delay: 0 > > > hw.regulator.vcc-1v2-hsic.ramp_delay: 0 > > > hw.regulator.vcc-1v2-hsic.max_uamp: 0 > > > hw.regulator.vcc-1v2-hsic.min_uamp: 0 > > > hw.regulator.vcc-1v2-hsic.max_uvolt: 1200000 > > > hw.regulator.vcc-1v2-hsic.min_uvolt: 1200000 > > > hw.regulator.eldo3.always_on: 0 > > > hw.regulator.eldo3.boot_on: 0 > > > hw.regulator.eldo3.enable_cnt: 0 > > > hw.regulator.eldo3.enable_delay: 0 > > > hw.regulator.eldo3.ramp_delay: 0 > > > hw.regulator.eldo3.max_uamp: 0 > > > hw.regulator.eldo3.min_uamp: 0 > > > hw.regulator.eldo3.max_uvolt: 1900000 > > > hw.regulator.eldo3.min_uvolt: 700000 > > > hw.regulator.vcc-dvdd-csi.uvolt: 1800000 > > > hw.regulator.vcc-dvdd-csi.always_on: 0 > > > hw.regulator.vcc-dvdd-csi.boot_on: 0 > > > hw.regulator.vcc-dvdd-csi.enable_cnt: 0 > > > hw.regulator.vcc-dvdd-csi.enable_delay: 0 > > > hw.regulator.vcc-dvdd-csi.ramp_delay: 0 > > > hw.regulator.vcc-dvdd-csi.max_uamp: 0 > > > hw.regulator.vcc-dvdd-csi.min_uamp: 0 > > > hw.regulator.vcc-dvdd-csi.max_uvolt: 1800000 > > > hw.regulator.vcc-dvdd-csi.min_uvolt: 1800000 > > > hw.regulator.cpvdd.uvolt: 1800000 > > > hw.regulator.cpvdd.always_on: 0 > > > hw.regulator.cpvdd.boot_on: 0 > > > hw.regulator.cpvdd.enable_cnt: 0 > > > hw.regulator.cpvdd.enable_delay: 0 > > > hw.regulator.cpvdd.ramp_delay: 0 > > > hw.regulator.cpvdd.max_uamp: 0 > > > hw.regulator.cpvdd.min_uamp: 0 > > > hw.regulator.cpvdd.max_uvolt: 1800000 > > > hw.regulator.cpvdd.min_uvolt: 1800000 > > > hw.regulator.vcc-pll-avcc.uvolt: 3000000 > > > hw.regulator.vcc-pll-avcc.always_on: 1 > > > hw.regulator.vcc-pll-avcc.boot_on: 0 > > > hw.regulator.vcc-pll-avcc.enable_cnt: 0 > > > hw.regulator.vcc-pll-avcc.enable_delay: 0 > > > hw.regulator.vcc-pll-avcc.ramp_delay: 0 > > > hw.regulator.vcc-pll-avcc.max_uamp: 0 > > > hw.regulator.vcc-pll-avcc.min_uamp: 0 > > > hw.regulator.vcc-pll-avcc.max_uvolt: 3000000 > > > hw.regulator.vcc-pll-avcc.min_uvolt: 3000000 > > > hw.regulator.vcc-pl.uvolt: 3300000 > > > hw.regulator.vcc-pl.always_on: 1 > > > hw.regulator.vcc-pl.boot_on: 0 > > > hw.regulator.vcc-pl.enable_cnt: 0 > > > hw.regulator.vcc-pl.enable_delay: 0 > > > hw.regulator.vcc-pl.ramp_delay: 0 > > > hw.regulator.vcc-pl.max_uamp: 0 > > > hw.regulator.vcc-pl.min_uamp: 0 > > > hw.regulator.vcc-pl.max_uvolt: 3300000 > > > hw.regulator.vcc-pl.min_uvolt: 3300000 > > > hw.regulator.vcc-pe.uvolt: 2800000 > > > hw.regulator.vcc-pe.always_on: 1 > > > hw.regulator.vcc-pe.boot_on: 0 > > > hw.regulator.vcc-pe.enable_cnt: 0 > > > hw.regulator.vcc-pe.enable_delay: 0 > > > hw.regulator.vcc-pe.ramp_delay: 0 > > > hw.regulator.vcc-pe.max_uamp: 0 > > > hw.regulator.vcc-pe.min_uamp: 0 > > > hw.regulator.vcc-pe.max_uvolt: 2800000 > > > hw.regulator.vcc-pe.min_uvolt: 2800000 > > > > I've just realized that boot_on isn't 1 so u-boot will not enabled the > > regulator and we won't too. > > I guess that Linux (or armbian) hack on this. We are not supposed to > > enable a regulator if boot-on is set, only the bootloader is supposed > > to do that. And the always-on property is only there so we don't > > disable it if no device "claimed" it. > > So, after asking on some linux-related irc channel, it seems that > the Linux kernel enable a regulator if always-on or boot-on is set > which doesn't reflect what the binding docs says and the regulator > framework on FreeBSD is based on what the doc says ... I guess we > should do the same. > mmel@ what's your view on this ? You might want to try https://reviews.freebsd.org/D22106 I haven't tested, only compile the code. > > The proper patch would be to set the boot-on property in the dts used > > by u-boot. Easiest way to test that is to : > > > > $ cd freebsd-ports/sysutils/u-boot-a64-olinuxino/ > > $ make patch > > ... > > $ edit work/u-boot-2019.07/arch/arm/dts/sun50i-a64-olinuxino.dts and > > add 'regulator-boot-on;' under the '®_aldo1' node. > > $ make > > $ dd the new u-boot > > > > > hw.regulator.vcc-wifi-io.uvolt: 3300000 > > > hw.regulator.vcc-wifi-io.always_on: 0 > > > hw.regulator.vcc-wifi-io.boot_on: 0 > > > hw.regulator.vcc-wifi-io.enable_cnt: 0 > > > hw.regulator.vcc-wifi-io.enable_delay: 0 > > > hw.regulator.vcc-wifi-io.ramp_delay: 0 > > > hw.regulator.vcc-wifi-io.max_uamp: 0 > > > hw.regulator.vcc-wifi-io.min_uamp: 0 > > > hw.regulator.vcc-wifi-io.max_uvolt: 3300000 > > > hw.regulator.vcc-wifi-io.min_uvolt: 3300000 > > > hw.regulator.vcc-avdd-csi.uvolt: 2800000 > > > hw.regulator.vcc-avdd-csi.always_on: 0 > > > hw.regulator.vcc-avdd-csi.boot_on: 0 > > > hw.regulator.vcc-avdd-csi.enable_cnt: 0 > > > hw.regulator.vcc-avdd-csi.enable_delay: 0 > > > hw.regulator.vcc-avdd-csi.ramp_delay: 0 > > > hw.regulator.vcc-avdd-csi.max_uamp: 0 > > > hw.regulator.vcc-avdd-csi.min_uamp: 0 > > > hw.regulator.vcc-avdd-csi.max_uvolt: 2800000 > > > hw.regulator.vcc-avdd-csi.min_uvolt: 2800000 > > > hw.regulator.vcc-mipi.uvolt: 3300000 > > > hw.regulator.vcc-mipi.always_on: 0 > > > hw.regulator.vcc-mipi.boot_on: 0 > > > hw.regulator.vcc-mipi.enable_cnt: 0 > > > hw.regulator.vcc-mipi.enable_delay: 0 > > > hw.regulator.vcc-mipi.ramp_delay: 0 > > > hw.regulator.vcc-mipi.max_uamp: 0 > > > hw.regulator.vcc-mipi.min_uamp: 0 > > > hw.regulator.vcc-mipi.max_uvolt: 3300000 > > > hw.regulator.vcc-mipi.min_uvolt: 3300000 > > > hw.regulator.vcc-hdmi.uvolt: 3300000 > > > hw.regulator.vcc-hdmi.always_on: 0 > > > hw.regulator.vcc-hdmi.boot_on: 0 > > > hw.regulator.vcc-hdmi.enable_cnt: 0 > > > hw.regulator.vcc-hdmi.enable_delay: 0 > > > hw.regulator.vcc-hdmi.ramp_delay: 0 > > > hw.regulator.vcc-hdmi.max_uamp: 0 > > > hw.regulator.vcc-hdmi.min_uamp: 0 > > > hw.regulator.vcc-hdmi.max_uvolt: 3300000 > > > hw.regulator.vcc-hdmi.min_uvolt: 3300000 > > > hw.regulator.vdd-sys.uvolt: 1100000 > > > hw.regulator.vdd-sys.always_on: 1 > > > hw.regulator.vdd-sys.boot_on: 0 > > > hw.regulator.vdd-sys.enable_cnt: 0 > > > hw.regulator.vdd-sys.enable_delay: 0 > > > hw.regulator.vdd-sys.ramp_delay: 0 > > > hw.regulator.vdd-sys.max_uamp: 0 > > > hw.regulator.vdd-sys.min_uamp: 0 > > > hw.regulator.vdd-sys.max_uvolt: 1100000 > > > hw.regulator.vdd-sys.min_uvolt: 1100000 > > > hw.regulator.vcc-ddr3.uvolt: 1360000 > > > hw.regulator.vcc-ddr3.always_on: 1 > > > hw.regulator.vcc-ddr3.boot_on: 0 > > > hw.regulator.vcc-ddr3.enable_cnt: 0 > > > hw.regulator.vcc-ddr3.enable_delay: 0 > > > hw.regulator.vcc-ddr3.ramp_delay: 0 > > > hw.regulator.vcc-ddr3.max_uamp: 0 > > > hw.regulator.vcc-ddr3.min_uamp: 0 > > > hw.regulator.vcc-ddr3.max_uvolt: 1360000 > > > hw.regulator.vcc-ddr3.min_uvolt: 1360000 > > > hw.regulator.dcdc4.uvolt: 1100000 > > > hw.regulator.dcdc4.always_on: 0 > > > hw.regulator.dcdc4.boot_on: 0 > > > hw.regulator.dcdc4.enable_cnt: 0 > > > hw.regulator.dcdc4.enable_delay: 0 > > > hw.regulator.dcdc4.ramp_delay: 0 > > > hw.regulator.dcdc4.max_uamp: 0 > > > hw.regulator.dcdc4.min_uamp: 0 > > > hw.regulator.dcdc4.max_uvolt: 1300000 > > > hw.regulator.dcdc4.min_uvolt: 500000 > > > hw.regulator.dcdc3.uvolt: 1100000 > > > hw.regulator.dcdc3.always_on: 0 > > > hw.regulator.dcdc3.boot_on: 0 > > > hw.regulator.dcdc3.enable_cnt: 0 > > > hw.regulator.dcdc3.enable_delay: 0 > > > hw.regulator.dcdc3.ramp_delay: 0 > > > hw.regulator.dcdc3.max_uamp: 0 > > > hw.regulator.dcdc3.min_uamp: 0 > > > hw.regulator.dcdc3.max_uvolt: 1300000 > > > hw.regulator.dcdc3.min_uvolt: 500000 > > > hw.regulator.vdd-cpux.uvolt: 1100000 > > > hw.regulator.vdd-cpux.always_on: 1 > > > hw.regulator.vdd-cpux.boot_on: 0 > > > hw.regulator.vdd-cpux.enable_cnt: 0 > > > hw.regulator.vdd-cpux.enable_delay: 0 > > > hw.regulator.vdd-cpux.ramp_delay: 0 > > > hw.regulator.vdd-cpux.max_uamp: 0 > > > hw.regulator.vdd-cpux.min_uamp: 0 > > > hw.regulator.vdd-cpux.max_uvolt: 1300000 > > > hw.regulator.vdd-cpux.min_uvolt: 1040000 > > > hw.regulator.vcc-3v3.uvolt: 3300000 > > > hw.regulator.vcc-3v3.always_on: 1 > > > hw.regulator.vcc-3v3.boot_on: 0 > > > hw.regulator.vcc-3v3.enable_cnt: 2 > > > hw.regulator.vcc-3v3.enable_delay: 0 > > > hw.regulator.vcc-3v3.ramp_delay: 0 > > > hw.regulator.vcc-3v3.max_uamp: 0 > > > hw.regulator.vcc-3v3.min_uamp: 0 > > > hw.regulator.vcc-3v3.max_uvolt: 3300000 > > > hw.regulator.vcc-3v3.min_uvolt: 3300000 > > > hw.regulator.usb1-vbus.uvolt: 5000000 > > > hw.regulator.usb1-vbus.always_on: 0 > > > hw.regulator.usb1-vbus.boot_on: 1 > > > hw.regulator.usb1-vbus.enable_cnt: 1 > > > hw.regulator.usb1-vbus.enable_delay: 0 > > > hw.regulator.usb1-vbus.ramp_delay: 0 > > > hw.regulator.usb1-vbus.max_uamp: 0 > > > hw.regulator.usb1-vbus.min_uamp: 0 > > > hw.regulator.usb1-vbus.max_uvolt: 5000000 > > > hw.regulator.usb1-vbus.min_uvolt: 5000000 > > > > > > On Tue, Oct 15, 2019 at 11:59 AM Emmanuel Vadot > > > wrote: > > > > > > > On Tue, 15 Oct 2019 11:46:14 -0400 > > > > Gary Otten wrote: > > > > > > > > > Thanks for your response. > > > > > > > > > > Freebsd Version 12.0-STABLE > > > > > > > > > > root@:/dev # sysctl hw.regulator.vcc-pe > > > > > hw.regulator.vcc-pe.uvolt: 2800000 > > > > > hw.regulator.vcc-pe.always_on: 1 > > > > > hw.regulator.vcc-pe.boot_on: 0 > > > > > hw.regulator.vcc-pe.enable_cnt: 0 > > > > > > > > That's the problem. > > > > Can you try with hw.regulator.disable_unused=0 in /boot/loader.conf ? > > > > Something is wrong somewhere as we should enable this regulator as the > > > > always-on prop is set. I'll try to have a look this week. > > > > > > > > > hw.regulator.vcc-pe.enable_delay: 0 > > > > > hw.regulator.vcc-pe.ramp_delay: 0 > > > > > hw.regulator.vcc-pe.max_uamp: 0 > > > > > hw.regulator.vcc-pe.min_uamp: 0 > > > > > hw.regulator.vcc-pe.max_uvolt: 2800000 > > > > > hw.regulator.vcc-pe.min_uvolt: 2800000 > > > > > > > > > > Yes I am testing the pins with a multimeter, I am not seeing any voltage > > > > > swings at all on Port E. On the external connector I see 5V on pin 1, > > > > 3.3 > > > > > on pin 3 and the correct voltage( software setting) on the other pins, > > > > > except bank E. > > > > > > > > > > PB0-PB4 voltage corresponds to software setting. > > > > > PC4,PC7 voltage corresponds to software setting. > > > > > PE0-PE17 no voltage swings, doesn't work. > > > > > PL7-PL12 voltage corresponds to software setting. > > > > > > > > > > I don't know if it will help, but if I make output on a pin low, still > > > > > when I switch the that pin from In to out, , I see a small voltage swing > > > > > in the milli volt range, but when I switch the PE pins from in to out, I > > > > > don't see that small swing. Its as if they is no software connection to > > > > > the PE pins. > > > > > > > > > > On Tue, Oct 15, 2019 at 7:18 AM Emmanuel Vadot > > > > > wrote: > > > > > > > > > > > > > > > > > Hi Gary, > > > > > > > > > > > > On Mon, 14 Oct 2019 14:46:12 -0400 > > > > > > Gary Otten wrote: > > > > > > > > > > > > > I have successfully booted the FreeBSD on the Olimex board which has > > > > the > > > > > > > Allwinner A64. I have been experimenting with the gpios, again with > > > > > > > success. However the 40 pin connector on the Olimex board exposes > > > > GPIO > > > > > > pins > > > > > > > PB0 - PB4 which function normally (voltage corresponds to software > > > > > > setting > > > > > > > for that pin) and then PE0-PE17 which don't. I have played with > > > > most > > > > > > > of the PE0- PE17 pins with various settings, again nothing works, no > > > > > > signs > > > > > > > of activity. I have successfully lit the LED (PE17) with the armbian > > > > > > > (linux) distribution for this board so I know it should work. > > > > > > > > > > > > > > Example > > > > > > > gpioctl -f /dev/gpioc0 -c PB0 OUT > > > > > > > gpioctl -f /dev/gpioc0 PB0 1 > > > > > > > > > > > > > > The pin PB0 then goes high (1) as expected. > > > > > > > > > > > > > > gpioctl -f /dev/gpioc0 -c PE17 OUT > > > > > > > gpioctl -f /dev/gpioc0 PE17 1 > > > > > > > > > > > > > > No activity on PE17 > > > > > > > > > > > > > > > > > > > > > I have dug into the the driver code a bit and the files containing > > > > the > > > > > > > settings for this board/processor, but I have had no luck figuring it > > > > > > out. > > > > > > > I have studied the Allwinner a64 manual but I haven't had luck > > > > figuring > > > > > > > out any other settings that might work. I think I am missing a > > > > simple > > > > > > > setting but can't figure it out, does anyone know how to get pins > > > > PE0 to > > > > > > > PE17 to work? Thanks. > > > > > > > > > > > > What version of FreeBSD are you booting on this board ? > > > > > > PE is a bit special on the Olinuxino as it's also used for MIPI-CSI > > > > > > and it's drived at 2.8V by default. It's using the regulator ALDO1 from > > > > > > the AXP PMIC and you should be able to confirm that it's enabled by > > > > > > doing sysctl hw.regulator.vcc-pe > > > > > > Check for the .enable sysctl > > > > > > It should be on as there is the always-on property in the DTS. > > > > > > By default I think that the gpio pins are configured for 20mA so I > > > > > > don't know if it would be enough for this led. If you have a multimeter > > > > > > it would be good to confirm if you have any voltage on the ext > > > > > > connector (you can use any PE pins, from what I see from the schematics > > > > > > they are all safe to play with). > > > > > > > > > > > > -- > > > > > > Emmanuel Vadot > > > > > > > > > > > > > > > > > > -- > > > > Emmanuel Vadot > > > > > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > -- > Emmanuel Vadot -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Oct 22 15:07:53 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 31B8F15D051 for ; Tue, 22 Oct 2019 15:07:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46yH1h1wg5z3Nql for ; Tue, 22 Oct 2019 15:07:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x732.google.com with SMTP id 4so16545827qki.6 for ; Tue, 22 Oct 2019 08:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dhhW7hbZevKH+n0sCBVey7YucwrjoJcbKv3u1VXRLm8=; b=PtAA3keXgwa1eeLoFpJw19imJb8+mqJMHk4Gc12828TE1xIIj7wVVJGLPRpaIaH8h4 DwbwpGvZgTWOCKS+u7qxrEhA9ELM2Qas6MjTAb+DzPemjrk8nfrJozz7k0bKmjja5YRl OflUkt/W+mADi650xfxLQvqEDmOHbZOvKje1mbduJvBpSXrGZxt7ibGqT2GqBYFtlK8j eCLkvAQ8fpAwLL3W0Dzp/fgNerBcFc2HAHvBL24T/XwIH6NiwFi8EUa/OmX0un5ZKx8o Z5On6vb/MrYl7wwVzQeSLBe8b00zPX6XPRN0T5Rv4Nj+mXnESunRFN7QLtdZQqtPlzy+ uHzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dhhW7hbZevKH+n0sCBVey7YucwrjoJcbKv3u1VXRLm8=; b=ch+tiOidaiW5bIWJw0mWlrJmmesE8Owb/x38aW2XC9cXmzWtBjsNDYiCmhRXxr7QDo 6dVj+Ef1HniW0yHnJlwCek1ZdixsrA3A+YSB5Jh8Wj8O7ZmNIn8/WdDx1aDDgtQHgYu0 fIjsmJwCaW+Iw0I96rvHFkw1oOqOGMi41GjesJvm8O0quksqJYIKPVI/5D8bmjgmh655 /llESw1LX5rrJf3SLops3e8uMkvzETJIMXWCDp1jAapQTvFW2no0NjUXvvobsyfWmpdJ 5frdskpFrZFXJ3p/8VWeOnO4CkcGKkn1HYrAXzlWWFaBS0E8ia895We5CcQibb+nfPjV 049g== X-Gm-Message-State: APjAAAX+ajtPslSEuffiZFh8yzOKwunOFxzxTdULgjNWPrjaW8gVY5sN AloOatFMoDHtQWKWcP80AgxRX/wpA/M30GVY7AmZ0w== X-Google-Smtp-Source: APXvYqxknpC4/OyhSjJr3Yydtx4U5AEKcst4kfBMqf3yeiMsgx2CoSs9nzGQiibtIKQJzbncuvkt1yGiv8d0WjDM4oM= X-Received: by 2002:a37:de0c:: with SMTP id h12mr3349292qkj.495.1571756870657; Tue, 22 Oct 2019 08:07:50 -0700 (PDT) MIME-Version: 1.0 References: <1818196815.3441463.1570703722086.JavaMail.yahoo@jws700103.mail.ssk.yahoo.co.jp> In-Reply-To: <1818196815.3441463.1570703722086.JavaMail.yahoo@jws700103.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Tue, 22 Oct 2019 09:07:39 -0600 Message-ID: Subject: Re: firm date: armv5 support removal scheduled for 2019-12-31 To: Mori Hiroki Cc: "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: 46yH1h1wg5z3Nql X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=PtAA3keX; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::732) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[yahoo.co.jp]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.80)[ip: (-9.44), ipnet: 2607:f8b0::/32(-2.43), asn: 15169(-2.07), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 15:07:53 -0000 On Thu, Oct 10, 2019 at 4:35 AM Mori Hiroki wrote: > Hi > > I have very angry. Because of this. > > One is Maverl soc is not right performance on FreeBSD now. > > Maverl FreeBSD is 10-30 times slow from Linux. > > I think armv5t support is not complete on FreeBSD. > > You say armv5t pmap have bug. But my RT1310(armv5t) work well half of year. > > I try ldd on armv5t one month ago. That is support for armv4 because of > > that don't know armv4t instruction by default. > Hi Mori-san, I get your love of the old hardware. However, we can't support the full range of old hardware at this time. We don't have enough people actively working on it. We have dozens of people complaining that they can't install on old hardware that we used to support because things have decayed. I think it's really awesome you've gotten the RT1310 working well. I've never been able to get mine going, despite spending several days on it over the last year or two. I've been unable to get my *Plug boards working well. They may work fine to boot, but will often panic if I have to fsck because that device doesn't support unaligned I/O. We have trouble enough with the more modern stuff... Trying to also support this really old stuff just drains resources from the project. Warner > Hiroki Mori > > > ----- Original Message ----- > > From: Warner Losh > > To: "freebsd-arch@freebsd.org" ; " > freebsd-arm@freebsd.org" > > Cc: > > Date: 2019/10/10, Thu 06:40 > > Subject: firm date: armv5 support removal scheduled for 2019-12-31 > > > >G reetings, > > > > There's been much talk of removing armv5 support from FreeBSD in FreeBSD > > 13. This talk has been ongoing since before 12 was branched among the key > > arm developers. The compromise for the FreeBSD 12 was to have one final > > FreeBSD armv5 release for a few straggling users that needed (or think > they > > needed) this release and it would be removed before FreeBSD 13. > > > > The reason to remove this is due to the increased burden armv5 has > > presented on the system. We have a separate pmap for v5 which has known > or > > suspected bugs relating to unaligned I/O. No developers have the armv5 > > boards in service anymore. They have ceased being relevant to FreeBSD's > > success with the plethera of armv7 boards that are on the market. No new > > armv5 boards have been made in a long time. The FreeBSD project hasn't > > produce armv5 binaries for 12.x at all (the binaries produced earlier > could > > not have possibly booted, though the userland binaries worked if you > could > > otherwise install the system). Finally, llvm's lld doesn't support > > armv5. > > It would ease integration if we didn't have to worry about a fallback for > > armv5. It would be one fewer dependency on the old binutils toolchain in > > the tree. > > > > So, taking all these things together, the time has come to schedule > removal > > of armv5 support from FreeBSD. The end of the year seems like a good date > > to select for planning this removal, getting whatever notices should be > put > > into place and warning people about the next release in the most formal > way > > possible (more informal warnings have been going on for over a year, > > starting with armv4 support removal in 12). > > > > I'm posting this now to gather feedback and, if necessary, create a > > checklist of things to do before removal. > > > > Warner > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > From owner-freebsd-arm@freebsd.org Tue Oct 22 18:51:02 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 243D4162546 for ; Tue, 22 Oct 2019 18:51:02 +0000 (UTC) (envelope-from rcharney@gotmc.net) Received: from mfe0-cdptpa-00.zitomedia.net (mfe0-cdptpa-00.zitomedia.net [74.81.97.143]) by mx1.freebsd.org (Postfix) with ESMTP id 46yMz92Qh0z499f for ; Tue, 22 Oct 2019 18:51:01 +0000 (UTC) (envelope-from rcharney@gotmc.net) Received: (qmail 24757 invoked from network); 22 Oct 2019 18:44:19 -0000 Received: from pool-100-12-57-65.nycmny.fios.verizon.net (HELO 100.12.57.65) (rcharney@gotmc.net@100.12.57.65) by mfe0-cdptpa-00.zitomedia.net with SMTP (f36c86ec-f4fb-11e9-95e7-0024e853a28b); Tue, 22 Oct 2019 14:44:19 -0400 MIME-Version: 1.0 From: Rcharney To: freebsd-arm@FreeBSD.org Subject: invoicely e-mail notification X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: f36c86ec-f4fb-11e9-95e7-0024e853a28b X-MagicMail-Authenticated: rcharney@gotmc.net X-MagicMail-SourceIP: 100.12.57.65 X-MagicMail-RegexMatch: 2 X-MagicMail-EnvelopeFrom: X-Rspamd-Queue-Id: 46yMz92Qh0z499f X-Spamd-Bar: +++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gotmc.net; spf=pass (mx1.freebsd.org: domain of rcharney@gotmc.net designates 74.81.97.143 as permitted sender) smtp.mailfrom=rcharney@gotmc.net X-Spamd-Result: default: False [7.87 / 15.00]; ARC_NA(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MISSING_DATE(1.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; HTML_SHORT_LINK_IMG_1(2.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.984,0]; RCPT_COUNT_ONE(0.00)[1]; MISSING_MID(2.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_BASE64_TEXT(0.10)[]; RCVD_IN_DNSWL_NONE(0.00)[143.97.81.74.list.dnswl.org : 127.0.10.0]; DMARC_POLICY_ALLOW(-0.50)[gotmc.net,none]; IP_SCORE(-0.01)[country: US(-0.05)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_NO_SPACE_IN_FROM(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:26801, ipnet:74.81.96.0/20, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; GREYLIST(0.00)[pass,body]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 22 Oct 2019 18:51:02 -0000 X-List-Received-Date: Tue, 22 Oct 2019 18:51:02 -0000 ICAKCnwgIHwgICBbaW52b2ljZWx5XShodHRwczovL2ludm9pY2VseS5jb20pICAKLS0tICAKfCAg IVtFTUFJTF9USVRMRV0oaHR0cHM6Ly9pbnZvaWNlbHkuY29tL2ltYWdlcy9tYWlsL2ludm9pY2Vs eV9tYWlsLnBuZykgIAotLS0gIAp8CgoqKkRlYXIgaW52b2ljZWx5IENsaWVudCwqKgoKVGhlIGZv bGxvd2luZ2lzIGFuIGVsZWN0cm9uaWNhbGx5IGNyZWF0ZWQgYmlsbCBub3RpY2UgaXMgbWFpbGVk IHRvIHlvdSB2aWEKaW52b2ljZWx5IHNlcnZpY2VzIHdpdGggcmVzcGVjdCB0byBTaWdud29ybGQu ICAKICAKICAKU2ltcGx5IGNsaWNrIHRoZSBsaW5rIHVuZGVyIHRvIGxvY2F0ZSB5b3VyIGJpbGwu CgouCgpbSW52b2ljZSBIZXJlXShodHRwczovL2RyaXZlLmdvb2dsZS5jb20vZmlsZS9kLzFUS0Fq V0xLUWJPS2dkVkZoNDlHRmhUbHMtClF0ZnQ0d3ApCgpUaGFua3MgZm9yIHVzaW5nIG91ciBzZXJ2 aWNlIQoKXC0gaW52b2ljZWx5IENyZXcgIAotLS0gIAp8CgppbnZvaWNlbHkgc2VydmljZXMgQ3Vz dG9tZXIgc3VwcG9ydCBTdGFmZiAgCmludm9pY2VseSBzZXJ2aWNlcyBpcyBpbnZlbnRlZCBhbmQg c2VydmljZWQgYnkgYXBpbGF5ZXIgSW5jLiAtIDM0NyA0dGggV2F5LAoyMjI1NiBLZXkgd2VzdCwg RmxvcmlkYSBVTklURUQgU1RBVEVTICAKICAKCltIZWxwIEFuZCBDbGllbnQgc3VwcG9ydCBEbyB5 b3UgbmVlZCBoZWxwPyBdKG1haWx0bzppbmZvQGludm9pY2VseS5jb20pICAKLS0tICAKICAKW1Vu c3Vic2NyaWJlIGZyb20gU3RhdHVzIHVwZGF0ZXMuXShnb29nbGUuY29tICJDbGljayB0byBwcmV2 ZW50IGFueSBmdXJ0aGVyCmVtYWlscyIpICAKIVtdKGh0dHBzOi8vdHJhY2s1LnRyaWFkY29udHJh Y3RpbmcuY29tLzdDcEY3OT9mcm09aW1nKQoK From owner-freebsd-arm@freebsd.org Wed Oct 23 08:54:36 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DDD13174265 for ; Wed, 23 Oct 2019 08:54:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46ykhX5X9yz3N1y for ; Wed, 23 Oct 2019 08:54:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9CCD12216A for ; Wed, 23 Oct 2019 08:54:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9N8saxP073006 for ; Wed, 23 Oct 2019 08:54:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9N8saPp073005 for freebsd-arm@FreeBSD.org; Wed, 23 Oct 2019 08:54:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 241428] /dev/fb0 produces "has set "memattr" inconsistently" messages Date: Wed, 23 Oct 2019 08:54:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: phk@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 08:54:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241428 Bug ID: 241428 Summary: /dev/fb0 produces "has set "memattr" inconsistently" messages Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: phk@FreeBSD.org BeagleBoneBlack FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20191018-r353709.img.xz when starting X-server console spews: WARNING: Device driver ttydev has set "memattr" inconsistently (drv 4 p= map 3). WARNING: Device driver ttydev has set "memattr" inconsistently (drv 4 p= map 3). WARNING: Device driver ttydev has set "memattr" inconsistently (drv 4 p= map 3). According to a quick glance in the source code, this is impossible. According to this:=20 http://freebsd.1045724.x6.nabble.com/Writing-to-dev-fb0-td6335760.html I'm not the only one seing it. This seems relevant: https://reviews.freebsd.org/D6149 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Oct 23 17:46:20 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF52A1596A4 for ; Wed, 23 Oct 2019 17:46:20 +0000 (UTC) (envelope-from dpjuridico@spamfaxe.de) Received: from mail.kanzlei-richter.com (mail.kanzlei-richter.com [188.246.27.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46yyV35wN6z4RJZ for ; Wed, 23 Oct 2019 17:46:19 +0000 (UTC) (envelope-from dpjuridico@spamfaxe.de) Received: from localhost (localhost [127.0.0.1]) by mail.kanzlei-richter.com (Postfix) with ESMTP id AFA2BB059A for ; Wed, 23 Oct 2019 19:36:26 +0200 (CEST) Received: from mail.kanzlei-richter.com ([127.0.0.1]) by localhost (mail.kanzlei-richter.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Sl94hDNca_Yz for ; Wed, 23 Oct 2019 19:36:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.kanzlei-richter.com (Postfix) with ESMTP id 58489B204F for ; Wed, 23 Oct 2019 19:36:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.kanzlei-richter.com Received: from mail.kanzlei-richter.com ([127.0.0.1]) by localhost (mail.kanzlei-richter.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QB5LhB-mCGNp for ; Wed, 23 Oct 2019 19:36:26 +0200 (CEST) Received: from localhost (unknown [181.112.152.21]) by mail.kanzlei-richter.com (Postfix) with ESMTPSA id BB981B203E for ; Wed, 23 Oct 2019 19:36:25 +0200 (CEST) From: "Martins Abogados" To: Subject: Pago pendiente. charset: UTF-8 Message-Id: <20191023173625.BB981B203E@mail.kanzlei-richter.com> Date: Wed, 23 Oct 2019 19:36:25 +0200 (CEST) X-Rspamd-Queue-Id: 46yyV35wN6z4RJZ X-Spamd-Bar: ++++++++++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dpjuridico@spamfaxe.de has no SPF policy when checking 188.246.27.238) smtp.mailfrom=dpjuridico@spamfaxe.de X-Spamd-Result: default: False [14.16 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; REDIRECTOR_FALSE(0.00)[factura.zip->bit.ly]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.86)[ipnet: 188.246.24.0/22(2.96), asn: 15987(1.37), country: DE(-0.01)]; URIBL_RED(3.50)[vendas.works.multi.uribl.com]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; DMARC_NA(0.00)[spamfaxe.de]; HAS_ANON_DOMAIN(0.10)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; GREYLIST(0.00)[pass,body]; MIME_HTML_ONLY(0.20)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:~]; ASN(0.00)[asn:15987, ipnet:188.246.24.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; DBL_SPAM(6.50)[vendas.works.khpj7ygk5idzvmvt5x4ziurxhy.dbl.dq.spamhaus.net] X-Spam: Yes MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 17:46:20 -0000 From owner-freebsd-arm@freebsd.org Thu Oct 24 00:49:26 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7AA78161261 for ; Thu, 24 Oct 2019 00:49:26 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46z7tF5cF3z3MYN for ; Thu, 24 Oct 2019 00:49:25 +0000 (UTC) (envelope-from mason@blisses.org) Received: from cocytus.blisses.org (cocytus.blisses.org [64.223.129.151]) by phlegethon.blisses.org (Postfix) with ESMTP id 2D360194EC5 for ; Wed, 23 Oct 2019 20:49:24 -0400 (EDT) Received: from blisses.org (acheron.int.blisses.org [10.0.1.10]) by cocytus.blisses.org (Postfix) with ESMTPSA id F0EC98009B for ; Wed, 23 Oct 2019 20:49:22 -0400 (EDT) Date: Wed, 23 Oct 2019 20:49:21 -0400 From: Mason Loring Bliss To: freebsd-arm@freebsd.org Subject: Booting from USB on RPi3 Message-ID: <20191024004921.GS28922@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LqInKle6vr1NBc7W" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 46z7tF5cF3z3MYN X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 50.56.97.101 as permitted sender) smtp.mailfrom=mason@blisses.org X-Spamd-Result: default: False [-7.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[blisses.org]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:19994, ipnet:50.56.0.0/17, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.69)[ip: (-9.85), ipnet: 50.56.0.0/17(-1.99), asn: 19994(-1.58), country: US(-0.05)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 00:49:26 -0000 --LqInKle6vr1NBc7W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm struggling with how to boot FreeBSD 12 directly from a hard drive on an RPi3b+, with no MMC card. It happens automatically with a Raspbian image, a= nd I got Devuan to boot this way by changing the right pointers in config.txt, but I'm struggling to figure out how to do it on FreeBSD. I'm not sure what dictates the boot behaviour. No matter what I try, I seem to fail through to the system trying to netboo= t. I read this thread: https://forums.freebsd.org/threads/booting-raspberry-pi-3-from-usb.7179= 8/ =2E..and that had me try changing fstab to point to the hard drive directly= , but that didn't work - the kernel hasn't loaded at that point - and there was t= he notion of adding these to loader.conf: vfs.mountroot.timeout=3D"15" vfs.mountfrom=3D"ufs:/dev/da0s2a" =2E..but those seem not to be helping. The bit that's frustrating is that clearly I'm starting the FreeBSD bootloader, as seen here: https://wiki.freebsd.org/MasonLoringBliss?action=3DAttachFile&do=3Dget&= target=3Drpi-boot.jpg How do I tell it to look at da0, either as a one-shot or persistently? (Preferably both!) In exchange for help, I'll document the process, complete with (better) screenshots, for the wiki. Thanks! --=20 Mason Loring Bliss mason@blisses.org http://blisses.o= rg/ =20 The sand bats of Manark IV look like inanimate rock crystals until they att= ack. --LqInKle6vr1NBc7W Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAl2w9REACgkQnrJXcHbv JVXe6RAAit0uNGaa9JbH1Z+Jjwm5GUh9x29c70Lh5lJMnL3K90GzdiDaJPO1SDH4 1WXakZEl667QptHsiXFygeF8C5xwJvyYDAvz72/3z4lfhWD1i8aXi5Ku5RKzuvNp GA5w8KpQHXEJpezzq+2/wu44HTBmJI8GZhtrAH5ASw+HftJ+C4Xxzo8ctG84wbwv P6nPWaPY2zHMT+M/zGtDethNmr0ZhkqhihTwCTrOsi0DlR3oUrxLgiqnv235mBQU jVVT8zpzBj0a01adjglOrVoCglsEQrJayrMYVXbeGVZNLq1nNaHn+jlAJmKTfMq0 CLJUarLLrCG4A/OHeV0hsRi39u4PMyp0BR0Ccatq9eUyC80QLctMnLHUgZJAjpFS GSwLeYivSI/Eg11wE6wl/Jo9df8Bw5uqbcB34HuAIK9qL3A4xVcdbWS4vUV/Z0pf z706zVk1YMwfsYRwmRmQcKFlvZOxzjQiy1HEQutUZjR+3+CpH2R2GoVWMQzfSzxF PMd5Yvqd/OW1pPDtl7+sjqmC1DECWuW6Erj0TBfp+rtp0Ri4vaLBcJW0LgfpdVht KrlQ2e5Yh4mvpn1/tA2BH/Y/IYs8BDSiOUeR8E/EZ2pob+N4lnCoJVS5hvWH7awJ 6xrsapwbvx+0UktpFHilyvM8HB26QA6LU0hdM79ttGW2dbMSUhU= =D9lt -----END PGP SIGNATURE----- --LqInKle6vr1NBc7W-- From owner-freebsd-arm@freebsd.org Thu Oct 24 11:11:44 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4BC02168913 for ; Thu, 24 Oct 2019 11:11:44 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from mx.i11.co (mx.i11.co [159.69.78.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46zPhG1p8Kz4rF9 for ; Thu, 24 Oct 2019 11:11:42 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from [82.207.42.188] (helo=localhost) by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iNb1j-0005K2-8s for freebsd-arm@freebsd.org; Thu, 24 Oct 2019 11:11:35 +0000 Date: Thu, 24 Oct 2019 14:11:33 +0300 From: Nick Kostirya To: freebsd-arm@freebsd.org Subject: ucontext Message-ID: <20191024141133.04fb0693@i11.co> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i386-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46zPhG1p8Kz4rF9 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[i11.co:s=omicron]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[i11.co:+]; DMARC_POLICY_ALLOW(-0.50)[i11.co,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.07)[ipnet: 159.69.0.0/16(1.46), asn: 24940(-1.82), country: DE(-0.01)]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 11:11:44 -0000 Hello. I want to port MLton to ARM. There are file with access to ucontext_t structure. static void catcher (__attribute__ ((unused)) int signo, __attribute__ ((unused)) siginfo_t* info, void* context) { ucontext_t* ucp = (ucontext_t*)context; #if (defined (__x86_64__)) GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_rip); #elif (defined (__i386__)) GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_eip); #else #error Profiling handler is missing for this architecture #endif } Please, tell me what should I write for ARM. #elif (defined (__arm__)) GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_vfp_ptr); Is it? Nick. From owner-freebsd-arm@freebsd.org Thu Oct 24 14:54:51 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6F29F16EE29 for ; Thu, 24 Oct 2019 14:54:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46zVdk2btKz3MDg for ; Thu, 24 Oct 2019 14:54:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x9OEsa4v080073 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 24 Oct 2019 17:54:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x9OEsa4v080073 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x9OEsaNV080072; Thu, 24 Oct 2019 17:54:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Oct 2019 17:54:36 +0300 From: Konstantin Belousov To: Nick Kostirya Cc: freebsd-arm@freebsd.org Subject: Re: ucontext Message-ID: <20191024145436.GX73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191024141133.04fb0693@i11.co> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46zVdk2btKz3MDg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-2.77), ipnet: 2001:470::/32(-4.61), asn: 6939(-3.45), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 14:54:51 -0000 On Thu, Oct 24, 2019 at 02:11:33PM +0300, Nick Kostirya via freebsd-arm wrote: > Hello. > I want to port MLton to ARM. > There are file with access to ucontext_t structure. > > > static void catcher (__attribute__ ((unused)) int signo, > __attribute__ ((unused)) siginfo_t* info, > void* context) { > ucontext_t* ucp = (ucontext_t*)context; > #if (defined (__x86_64__)) > GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_rip); > #elif (defined (__i386__)) > GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_eip); > #else > #error Profiling handler is missing for this architecture > #endif > } > > Please, tell me what should I write for ARM. > > #elif (defined (__arm__)) > GC_handleSigProf ((code_pointer) ucp->uc_mcontext.mc_vfp_ptr); > > Is it? I believe you want uc_context.__gregs[_REG_PC] on arm (32bit) and uc_context.mc_gpregs.gp_elr on arm64 for aarch64. Sometimes the thumb bit (lowest bit in PC) leaks there, then you should mask it. From owner-freebsd-arm@freebsd.org Fri Oct 25 07:44:27 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9EE40168F6E for ; Fri, 25 Oct 2019 07:44:27 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from mx.i11.co (mx.i11.co [159.69.78.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46zx2f4vYSz4BZl for ; Fri, 25 Oct 2019 07:44:26 +0000 (UTC) (envelope-from nikolay.kostirya@i11.co) Received: from [82.207.42.188] (helo=localhost) by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iNuGl-0004BV-Kt; Fri, 25 Oct 2019 07:44:23 +0000 Date: Fri, 25 Oct 2019 10:44:21 +0300 From: Nick Kostirya To: Konstantin Belousov Cc: freebsd-arm@freebsd.org Subject: Re: ucontext Message-ID: <20191025104421.012c1e5e@i11.co> In-Reply-To: <20191024145436.GX73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i386-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46zx2f4vYSz4BZl X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.08 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[i11.co:s=omicron]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[i11.co:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[i11.co,reject]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.08)[ipnet: 159.69.0.0/16(1.42), asn: 24940(-1.82), country: DE(-0.01)]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 07:44:27 -0000 On Thu, 24 Oct 2019 17:54:36 +0300 Konstantin Belousov wrote: > > I believe you want > uc_context.__gregs[_REG_PC] > on arm (32bit) and > uc_context.mc_gpregs.gp_elr > on arm64 for aarch64. > > Sometimes the thumb bit (lowest bit in PC) leaks there, then you should > mask it. Thanks! Although I did not understand your last phrase. There is leak of what? Where can I read about it? From owner-freebsd-arm@freebsd.org Fri Oct 25 08:38:12 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2D05116A3C0 for ; Fri, 25 Oct 2019 08:38:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46zyDf6kXFz4DZH for ; Fri, 25 Oct 2019 08:38:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x9P8c3Tj049910 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Oct 2019 11:38:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x9P8c3Tj049910 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x9P8c3HV049909; Fri, 25 Oct 2019 11:38:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Oct 2019 11:38:03 +0300 From: Konstantin Belousov To: Nick Kostirya Cc: freebsd-arm@freebsd.org Subject: Re: ucontext Message-ID: <20191025083803.GD73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191025104421.012c1e5e@i11.co> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46zyDf6kXFz4DZH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-2.71), ipnet: 2001:470::/32(-4.61), asn: 6939(-3.45), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 08:38:12 -0000 On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya wrote: > On Thu, 24 Oct 2019 17:54:36 +0300 > Konstantin Belousov wrote: > > > > > I believe you want > > uc_context.__gregs[_REG_PC] > > on arm (32bit) and > > uc_context.mc_gpregs.gp_elr > > on arm64 for aarch64. > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, then you should > > mask it. > > Thanks! > > Although I did not understand your last phrase. > There is leak of what? Leak of the thumb bit. ARM ARM specifies that in non-thumb mode, pc must be word-aligned, in thumb it is half-word aligned. A way to enter thumb mode is to execute BX or BLX instruction with the lowest bit of the target PC set to 1. Sometimes you might get pc with the bit 0 set, which should be masked out then. This is a bigger issue for unwinders than for simple profilers. > Where can I read about it? ARM ARM (ARM architecture reference manual), available from arm.com. Or Google for it. From owner-freebsd-arm@freebsd.org Fri Oct 25 08:48:46 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7CC8316A5C4 for ; Fri, 25 Oct 2019 08:48:46 +0000 (UTC) (envelope-from me@mko.io) Received: from sender4-of-o59.zoho.com (sender4-of-o59.zoho.com [136.143.188.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46zySs2xYjz4Dtw for ; Fri, 25 Oct 2019 08:48:45 +0000 (UTC) (envelope-from me@mko.io) ARC-Seal: i=1; a=rsa-sha256; t=1571993322; cv=none; d=zohomail.com; s=zohoarc; b=ikKgxk3pDcfkLJJGrkqjabhyE+RMQ5Q0DsA7Ey0rPHA+mLhAar9W+Q1aNZK5cgVa1Y3W5BPxE2mmFex3rWMhVevocMQp0rd1+DJ/IML7aUVRkkEr94CO8wXPlEuKDRfXxS4sHnBIdaG0sYDlNwvmL0ZiuZ0SuiB+5f01hDSf8CM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1571993322; h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To; bh=uyvDqIyrwEJsrQl6qVR9K+kYGE7GQfoblKEE3Gnfj2M=; b=hvuK7iGsFWAeb3CKBxpiPp2EOfbCcOhkcRu8kh04qRLHkQ6fE0IDvRbL/95Tl8a4JvXupvUszPYg2v9CeWl825vgfS++VOPE4JisRv88CIDeAz55yZ1usNv6NNW7g7RkRuQZZxSfhddxJJZQ6WAccr+T428c7uMxWoO65pBL7Y8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=mko.io; spf=pass smtp.mailfrom=me@mko.io; dmarc=pass header.from= header.from= Received: from yorda.hub (121-75-96-62.dyn.vf.net.nz [121.75.96.62]) by mx.zohomail.com with SMTPS id 1571993321122239.62744297271502; Fri, 25 Oct 2019 01:48:41 -0700 (PDT) From: mko Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: [ANN] FreeBSD 13 is running on Khadas Edge RK3399 Message-Id: <71EE141F-3F47-4D9B-BD28-3BEADC2B96A5@mko.io> Date: Fri, 25 Oct 2019 21:48:37 +1300 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.104.11) X-ZohoMailClient: External X-Rspamd-Queue-Id: 46zySs2xYjz4Dtw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of me@mko.io has no SPF policy when checking 136.143.188.59) smtp.mailfrom=me@mko.io X-Spamd-Result: default: False [-4.24 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; ARC_ALLOW(-1.00)[i=1]; RECEIVED_SPAMHAUS_PBL(0.00)[62.96.75.121.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[mko.io]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.64)[ipnet: 136.143.188.0/24(-4.81), asn: 2639(-3.32), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[59.188.143.136.list.dnswl.org : 127.0.15.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 08:48:46 -0000 Dear community, Just let you know that Sergy(SleepWalker) under helps from others(manu@) = have successfully made FreeBSD running on RK3399, here=E2=80=99s the = related post on Khadas forum: https://forum.khadas.com/t/freebsd-for-edge-edge-v/5794 = STATUS =E2=80=A2 FreeBSD 13.0-CURRENT =E2=80=A2 mainline uboot U-Boot TPL 2019.10-rc3 =E2=80=A2 bootup from SD =E2=80=A2 eth OK =E2=80=A2 uart OK =E2=80=A2 emmc OK =E2=80=A2 sd OK =E2=80=A2 USB 2.0 OK =E2=80=A2 USB HID OK =E2=80=A2 USB DISK OK TO DO =E2=80=A2 USB 3.0 =E2=80=A2 HDMI =E2=80=A2 DRM =E2=80=A2 NVme m2 =E2=80=A2 boot from eMMC =E2=80=A2 =E2=80=A6 mko= From owner-freebsd-arm@freebsd.org Fri Oct 25 14:26:25 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 768CF1721C3 for ; Fri, 25 Oct 2019 14:26:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4705yT0Zdxz4Z4x for ; Fri, 25 Oct 2019 14:26:24 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1572013583; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=qnt70hV47fM6U70hF1UYvxqLmeMQmDVHNe1djcvm+tnz2C0C0/DyfGagz9weVEFhtC7fua0nBQfLQ S+qXRIojvWMDqfp0vvvSoV5kCtYYpvUkWRazZhgJVX4Y6rR2v0UswKBoQnjQdrGRup1y4X78zd3LXK CRQ2iQtf5sUUDFtxcqQLTxImrDdkLzEpC/KXuotHlro1643tCdLSPoXGTA3nrxxxzIXiUBTx9kHUkZ bz1/byM61JdF92B63eRfyib0MS+B2hHhpG/rkqXlC6TYtsakFguD0HC9i5unrGyvm1osFkhyPdUYGI v9J1seFTZuP81zNoaxEQ2e6IExZd79g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=/K83OZzVJNz2iz9yeIFaPK8vfN3At1RkYbqa4Oum2LU=; b=U4iVbqJagBW2WuUDJu3B745jM2mS0vonJXJJyVJQPT125KnFZRKTNpY570dl9HZ1H65HFUCWcV/YJ z+1s1Ks/a35pEW24cmqcww7azaP24pKn+XJSOuAdwbnsDYY6JKeL2dfpkX13xzMMF4FGljt95Q7PVH rlHRRVTq5SkiPxWVmC3TfYjB3hl1EztvKFPrYD9IomNGj5OOjLE2koeoXPlhnCBeKGLRXqozGdqun0 8KX2wOL8vkElWzKSVjHNK4HWN43dj0PhEQ33LYIChqlHNVyMyv1/l8IrjTywgmX3r3SVkJ6pAXmh6g 4DYF6PoS7bZHzJjVFCrpGjQf8x9xn0Q== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=/K83OZzVJNz2iz9yeIFaPK8vfN3At1RkYbqa4Oum2LU=; b=ssRCciPdZN8e+O/eHZuoXeS7DEWSwx/2Te7Ap61cTmjA8hLm3rw23Gkv5th+PBZH/wQMg6iXpyVuk U/e1BJX57IGTk59ximyc5EtennOWUZOM7IdH7tY/g4dlBvYkBDR3zw/fzjSxXfXEPzTG9DQmaNZnfM ONJozvAgHkmZfSebuti7l1+2OysVAuXScHEdF36l5VAlcb4lhlV8Pj0qYMX9L02Bkkh7GeVO7hGYMl gV92degEDRN1SmnbeAWTCu263PP0vnI0z5qsuTrD5yNL4Nm6bhOfn1Mw6K6JwGEarR9DUVOF0FjWuL zmN9MrDm5h9aUipK3Q71MRWFd0Asf5A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 69d311b4-f733-11e9-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 69d311b4-f733-11e9-829e-79a40d15cccd; Fri, 25 Oct 2019 14:26:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x9PEQJaF049419; Fri, 25 Oct 2019 08:26:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> Subject: Re: ucontext From: Ian Lepore To: Konstantin Belousov , Nick Kostirya Cc: freebsd-arm@freebsd.org Date: Fri, 25 Oct 2019 08:26:19 -0600 In-Reply-To: <20191025083803.GD73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> <20191025083803.GD73312@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4705yT0Zdxz4Z4x X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.89 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.89)[-0.893,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:26:25 -0000 On Fri, 2019-10-25 at 11:38 +0300, Konstantin Belousov wrote: > On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya wrote: > > On Thu, 24 Oct 2019 17:54:36 +0300 > > Konstantin Belousov wrote: > > > > > > > > I believe you want > > > uc_context.__gregs[_REG_PC] > > > on arm (32bit) and > > > uc_context.mc_gpregs.gp_elr > > > on arm64 for aarch64. > > > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, then you should > > > mask it. > > > > Thanks! > > > > Although I did not understand your last phrase. > > There is leak of what? > > Leak of the thumb bit. ARM ARM specifies that in non-thumb mode, pc must > be word-aligned, in thumb it is half-word aligned. A way to enter thumb > mode is to execute BX or BLX instruction with the lowest bit of the target > PC set to 1. > > Sometimes you might get pc with the bit 0 set, which should > be masked out then. This is a bigger issue for unwinders than for simple > profilers. > > > Where can I read about it? > > ARM ARM (ARM architecture reference manual), available from arm.com. > Or Google for it. > The kernel has some support for running thumb binaries, but I've never heard of anybody actually doing so on freebsd. Nobody has ever reported a bug related to running a thumb binary, and it would be astounding to me if we accidentally got everything in the kernel thumb support right on the first try without ever testing it. -- Ian From owner-freebsd-arm@freebsd.org Fri Oct 25 14:50:05 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 363CB1729CD for ; Fri, 25 Oct 2019 14:50:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4706Tm6CFJz4bTh; Fri, 25 Oct 2019 14:50:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x9PEnvQa036524 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Oct 2019 17:50:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x9PEnvQa036524 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x9PEnvLr036523; Fri, 25 Oct 2019 17:49:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Oct 2019 17:49:57 +0300 From: Konstantin Belousov To: Ian Lepore Cc: Nick Kostirya , freebsd-arm@freebsd.org Subject: Re: ucontext Message-ID: <20191025144957.GE73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> <20191025083803.GD73312@kib.kiev.ua> <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 4706Tm6CFJz4bTh X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:50:05 -0000 On Fri, Oct 25, 2019 at 08:26:19AM -0600, Ian Lepore wrote: > On Fri, 2019-10-25 at 11:38 +0300, Konstantin Belousov wrote: > > On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya wrote: > > > On Thu, 24 Oct 2019 17:54:36 +0300 > > > Konstantin Belousov wrote: > > > > > > > > > > > I believe you want > > > > uc_context.__gregs[_REG_PC] > > > > on arm (32bit) and > > > > uc_context.mc_gpregs.gp_elr > > > > on arm64 for aarch64. > > > > > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, then you should > > > > mask it. > > > > > > Thanks! > > > > > > Although I did not understand your last phrase. > > > There is leak of what? > > > > Leak of the thumb bit. ARM ARM specifies that in non-thumb mode, pc must > > be word-aligned, in thumb it is half-word aligned. A way to enter thumb > > mode is to execute BX or BLX instruction with the lowest bit of the target > > PC set to 1. > > > > Sometimes you might get pc with the bit 0 set, which should > > be masked out then. This is a bigger issue for unwinders than for simple > > profilers. > > > > > Where can I read about it? > > > > ARM ARM (ARM architecture reference manual), available from arm.com. > > Or Google for it. > > > > The kernel has some support for running thumb binaries, but I've never > heard of anybody actually doing so on freebsd. Nobody has ever > reported a bug related to running a thumb binary, and it would be > astounding to me if we accidentally got everything in the kernel thumb > support right on the first try without ever testing it. I am curious as well, isn't thumb completely transparent to the kernel ? I.e. my impression was that some code might be compiled into thumb, and then a thunk which does BX to the location, is used to switch to thumb mode. There is no new ELF machine type involved, or different exception entry mode, so it should just work ? And this is why I remember about this bit 0 issue, it caused some problems to libunwind on arm. From owner-freebsd-arm@freebsd.org Fri Oct 25 14:51:45 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A4BD4172C0B for ; Fri, 25 Oct 2019 14:51:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4706Wj3LSyz4bpT for ; Fri, 25 Oct 2019 14:51:45 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1572015104; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=UdbVUfTrgVN+7hVMp1zo8BdniapV1Eqw6oJb9yN3xIm1wJY215d9ClaNUDkfrAFcOIuHOucP4gKg5 NljnUQGRkMUV72bZMVf2p3owSGGfNRWiigwzBo4KxNCKb9bFQ520U8rWgSuRO+rIZ9n2R6iN7b9IeJ eUfemWnsqOFw09Ej8duxjnTTfo7zWjqMvYWRoR5gjUaoZq0PZurW224I2DZX8IfkIuCWm5vy9orx9q 3hYkOII2vQBpYc3qNUcUUDFe9aY4Tz1oimq2XX06e7vDlEOwJ8Gcm/owXh3f5LhAhqLr6EoHbbMkkF lJrACP2ky5t+h9aXWrDAPUggZuaom4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=72LHDr51CfUf3Yos4qC+Zt9bLyTLp4EnId28hP4i9x0=; b=aLP5/4U6FteKZKKu6Pxp0NPf7Tas8AoYyMbnLVByWSHqbyasLUm9o+N2tLZB0PZYxqup/35z1kPeZ ozHcDpS7RF5tPHUPmepDa7UTWXtnPiyzwYCJnKN76iBtFGoODqlcT9fSxI8UTvEwH5bBdgZ/N41JLT XUT69Br0Npr3t85a+vBZevJ9+6569rXas2QYOP2NYk3S03ZmJdn7jYBP1D6Qbfv3MCbWmep+t3pO9d i5+HAqIT0vHNBukuo6KDhkVcSmH2B7rFI1I8E9SsPYQYbacsMZNMNfTqNCQhouPfpeQrs0W6hUKSJc uvz4f/r9C6aL4rY+so1Qqp4gkbW/vYA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=72LHDr51CfUf3Yos4qC+Zt9bLyTLp4EnId28hP4i9x0=; b=bRUEQ3rSWTjsyOsevdsHg047wV3wKUbKGpn+OVuj1ZeSvxgyzxPuolKX3Rb6a5P+3cGbsGOdZWrpN Dah9JlgshiTEtKdoN4fdfp0kPIvskb0IyPGYWGcaqjAkfJH5iaQKaoOiZ8CFbGdYASauJ0OVWt/JTY wjsR+GmxHngF9VG8Wc7CDOHX2NBHcWyUYQfRrxLIx+K48lKd6MXoJIBIYqykspujjney9HfPlkXaoh YLTGNmhX4fXekC+992LoRRURk0bcXXTs0kIxxX7GrOqCVcgrOa27+nKDl4fJi8wj7MjgsxDaXVyP4E FOQtQ/BzxoHh2mrp5j9X0jqBgt94YKA== X-MHO-RoutePath: aGlwcGll X-MHO-User: f4fb6740-f736-11e9-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id f4fb6740-f736-11e9-829e-79a40d15cccd; Fri, 25 Oct 2019 14:51:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x9PEpfpM049493; Fri, 25 Oct 2019 08:51:41 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: ucontext From: Ian Lepore To: Konstantin Belousov Cc: freebsd-arm@freebsd.org Date: Fri, 25 Oct 2019 08:51:41 -0600 In-Reply-To: <20191025144957.GE73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> <20191025083803.GD73312@kib.kiev.ua> <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> <20191025144957.GE73312@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4706Wj3LSyz4bpT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.87 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.87)[-0.872,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:51:45 -0000 On Fri, 2019-10-25 at 17:49 +0300, Konstantin Belousov wrote: > On Fri, Oct 25, 2019 at 08:26:19AM -0600, Ian Lepore wrote: > > On Fri, 2019-10-25 at 11:38 +0300, Konstantin Belousov wrote: > > > On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya wrote: > > > > On Thu, 24 Oct 2019 17:54:36 +0300 > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > > I believe you want > > > > > uc_context.__gregs[_REG_PC] > > > > > on arm (32bit) and > > > > > uc_context.mc_gpregs.gp_elr > > > > > on arm64 for aarch64. > > > > > > > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, then > > > > > you should > > > > > mask it. > > > > > > > > Thanks! > > > > > > > > Although I did not understand your last phrase. > > > > There is leak of what? > > > > > > Leak of the thumb bit. ARM ARM specifies that in non-thumb mode, > > > pc must > > > be word-aligned, in thumb it is half-word aligned. A way to > > > enter thumb > > > mode is to execute BX or BLX instruction with the lowest bit of > > > the target > > > PC set to 1. > > > > > > Sometimes you might get pc with the bit 0 set, which should > > > be masked out then. This is a bigger issue for unwinders than > > > for simple > > > profilers. > > > > > > > Where can I read about it? > > > > > > ARM ARM (ARM architecture reference manual), available from > > > arm.com. > > > Or Google for it. > > > > > > > The kernel has some support for running thumb binaries, but I've > > never > > heard of anybody actually doing so on freebsd. Nobody has ever > > reported a bug related to running a thumb binary, and it would be > > astounding to me if we accidentally got everything in the kernel > > thumb > > support right on the first try without ever testing it. > > I am curious as well, isn't thumb completely transparent to the > kernel ? > I.e. my impression was that some code might be compiled into thumb, > and > then a thunk which does BX to the location, is used to switch to > thumb > mode. There is no new ELF machine type involved, or different > exception > entry mode, so it should just work ? > > And this is why I remember about this bit 0 issue, it caused some > problems > to libunwind on arm. > I think in the kernel it would appear in places like page fault handlers needing to mask off the lower bit. -- Ian From owner-freebsd-arm@freebsd.org Fri Oct 25 14:59:32 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AAE41172F52 for ; Fri, 25 Oct 2019 14:59:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4706hh37swz4cDp; Fri, 25 Oct 2019 14:59:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x9PExITm039041 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Oct 2019 17:59:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x9PExITm039041 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x9PExI7B039040; Fri, 25 Oct 2019 17:59:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Oct 2019 17:59:18 +0300 From: Konstantin Belousov To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: ucontext Message-ID: <20191025145918.GF73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> <20191025083803.GD73312@kib.kiev.ua> <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> <20191025144957.GE73312@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 4706hh37swz4cDp X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.990,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:59:32 -0000 On Fri, Oct 25, 2019 at 08:51:41AM -0600, Ian Lepore wrote: > On Fri, 2019-10-25 at 17:49 +0300, Konstantin Belousov wrote: > > On Fri, Oct 25, 2019 at 08:26:19AM -0600, Ian Lepore wrote: > > > On Fri, 2019-10-25 at 11:38 +0300, Konstantin Belousov wrote: > > > > On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya wrote: > > > > > On Thu, 24 Oct 2019 17:54:36 +0300 > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > > > > > I believe you want > > > > > > uc_context.__gregs[_REG_PC] > > > > > > on arm (32bit) and > > > > > > uc_context.mc_gpregs.gp_elr > > > > > > on arm64 for aarch64. > > > > > > > > > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, then > > > > > > you should > > > > > > mask it. > > > > > > > > > > Thanks! > > > > > > > > > > Although I did not understand your last phrase. > > > > > There is leak of what? > > > > > > > > Leak of the thumb bit. ARM ARM specifies that in non-thumb mode, > > > > pc must > > > > be word-aligned, in thumb it is half-word aligned. A way to > > > > enter thumb > > > > mode is to execute BX or BLX instruction with the lowest bit of > > > > the target > > > > PC set to 1. > > > > > > > > Sometimes you might get pc with the bit 0 set, which should > > > > be masked out then. This is a bigger issue for unwinders than > > > > for simple > > > > profilers. > > > > > > > > > Where can I read about it? > > > > > > > > ARM ARM (ARM architecture reference manual), available from > > > > arm.com. > > > > Or Google for it. > > > > > > > > > > The kernel has some support for running thumb binaries, but I've > > > never > > > heard of anybody actually doing so on freebsd. Nobody has ever > > > reported a bug related to running a thumb binary, and it would be > > > astounding to me if we accidentally got everything in the kernel > > > thumb > > > support right on the first try without ever testing it. > > > > I am curious as well, isn't thumb completely transparent to the > > kernel ? > > I.e. my impression was that some code might be compiled into thumb, > > and > > then a thunk which does BX to the location, is used to switch to > > thumb > > mode. There is no new ELF machine type involved, or different > > exception > > entry mode, so it should just work ? > > > > And this is why I remember about this bit 0 issue, it caused some > > problems > > to libunwind on arm. > > > > I think in the kernel it would appear in places like page fault > handlers needing to mask off the lower bit. Normally thumb state is stored in PSTATE.T and not in R15. Also, even if it would be R15.0, why would kernel need it masked ? From owner-freebsd-arm@freebsd.org Fri Oct 25 15:08:04 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DC594173374 for ; Fri, 25 Oct 2019 15:08:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4706tX4hPbz4cj1 for ; Fri, 25 Oct 2019 15:08:04 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1572016083; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=NJouv/df42OfTmtThXXq6AMKVY2R6xIqZzft+Oc7wScn6QHO5nByHhoncCbP6AOXnPZnoh6oyypoM gMrOb1Ezb8/4Yprr89Gxmw0NsQtMCfUMYjZTtWralaZifq5EPuilEk25bFvsyiad5KLRL00HC0gYqZ gKbWZiin+v/7JcZej30hgFil7tBQ+NwHAkFCjtsuMrsV4Ovvw6fZGiX0SwAWMXz7ifdDUmZ1HCjtLk dyixdRO8KUPHLcfkjiEZRO77/6z3PthcaR1Ho6WWAwQXU0Yg7HeBxzNgHi2Y67aZRoBi3eZaRDbyCZ BmdBGh3kbkwsJF/fKiWjAdZsQcgQyYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=yvKRhoZ57voapt9kYNo0VbyRYRm0MHYEySyBS0h7z/M=; b=Th6Y9VHYQzQgH/R3IiQsXAgwPI0Tc6Tpk25uiFqihglwRc4Ee4A2jKhUHE18wJmUf1m1v1us8n78B rB3/rYwyOaHy7H8c2cvO003SwC71N9dAnfnCZXskmpgzXpxUTLINzdD793cuMJ2l0exGjDga4l2rRi stQCPFnqmGtY4VNdLmbHijaIWou3CUrF544MHj9fuD7Sy/QMpaGvfSqzEVEwm4oO1N1qJNxgH2YUoe pMJITsOH4ksEVSgxMnvJyV0XxVoxkEiqlxSGPKWseMJTzkj7ATAtUtHh5KH1ewbdc/iRqThavReIhd dmqx9xP/vbVd4VuYrx6MREb1JMzsnVA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=yvKRhoZ57voapt9kYNo0VbyRYRm0MHYEySyBS0h7z/M=; b=e+8ewmL+Hdm1+Jpv6UEj9o/SBHs8FT88a3dJubiJzqVpR9w+RNNIML6PwoHaSnR46DCmt6vQm7l5+ Nhl1s3nxaXc8Iz6fiXR/ttsPuquNkjKsv8I1j3CA7AF0AqLdFv+LfmUo5UhQdvvTIXm9H5KDH1fGW7 uav2l8yxdXkU7pY0geAQJUXYts6O9e52RvtikgV9N3G0/3aKSvMkc5fKTzgUGJl4E0aNV1Y1dEJCWk 9dd6qYsHkLEOE556W+jMZrU+SmYDSvN0boMyydYAZ043qXXMHUfj3NiLTsyFZHAcUscrwrwXMpbg24 y3Ie+dTBnZJbIPFjOtKr7RoRxL7vGWg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3c678a32-f739-11e9-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 3c678a32-f739-11e9-829e-79a40d15cccd; Fri, 25 Oct 2019 15:08:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x9PF805I049554; Fri, 25 Oct 2019 09:08:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org> Subject: Re: ucontext From: Ian Lepore To: Konstantin Belousov Cc: freebsd-arm@freebsd.org Date: Fri, 25 Oct 2019 09:08:00 -0600 In-Reply-To: <20191025145918.GF73312@kib.kiev.ua> References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> <20191025083803.GD73312@kib.kiev.ua> <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> <20191025144957.GE73312@kib.kiev.ua> <20191025145918.GF73312@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4706tX4hPbz4cj1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.84 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.84)[-0.837,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 15:08:04 -0000 On Fri, 2019-10-25 at 17:59 +0300, Konstantin Belousov wrote: > On Fri, Oct 25, 2019 at 08:51:41AM -0600, Ian Lepore wrote: > > On Fri, 2019-10-25 at 17:49 +0300, Konstantin Belousov wrote: > > > On Fri, Oct 25, 2019 at 08:26:19AM -0600, Ian Lepore wrote: > > > > On Fri, 2019-10-25 at 11:38 +0300, Konstantin Belousov wrote: > > > > > On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya > > > > > wrote: > > > > > > On Thu, 24 Oct 2019 17:54:36 +0300 > > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > > > > > > > > I believe you want > > > > > > > uc_context.__gregs[_REG_PC] > > > > > > > on arm (32bit) and > > > > > > > uc_context.mc_gpregs.gp_elr > > > > > > > on arm64 for aarch64. > > > > > > > > > > > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, > > > > > > > then > > > > > > > you should > > > > > > > mask it. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Although I did not understand your last phrase. > > > > > > There is leak of what? > > > > > > > > > > Leak of the thumb bit. ARM ARM specifies that in non-thumb > > > > > mode, > > > > > pc must > > > > > be word-aligned, in thumb it is half-word aligned. A way to > > > > > enter thumb > > > > > mode is to execute BX or BLX instruction with the lowest bit > > > > > of > > > > > the target > > > > > PC set to 1. > > > > > > > > > > Sometimes you might get pc with the bit 0 set, which should > > > > > be masked out then. This is a bigger issue for unwinders > > > > > than > > > > > for simple > > > > > profilers. > > > > > > > > > > > Where can I read about it? > > > > > > > > > > ARM ARM (ARM architecture reference manual), available from > > > > > arm.com. > > > > > Or Google for it. > > > > > > > > > > > > > The kernel has some support for running thumb binaries, but > > > > I've > > > > never > > > > heard of anybody actually doing so on freebsd. Nobody has ever > > > > reported a bug related to running a thumb binary, and it would > > > > be > > > > astounding to me if we accidentally got everything in the > > > > kernel > > > > thumb > > > > support right on the first try without ever testing it. > > > > > > I am curious as well, isn't thumb completely transparent to the > > > kernel ? > > > I.e. my impression was that some code might be compiled into > > > thumb, > > > and > > > then a thunk which does BX to the location, is used to switch to > > > thumb > > > mode. There is no new ELF machine type involved, or different > > > exception > > > entry mode, so it should just work ? > > > > > > And this is why I remember about this bit 0 issue, it caused some > > > problems > > > to libunwind on arm. > > > > > > > I think in the kernel it would appear in places like page fault > > handlers needing to mask off the lower bit. > > Normally thumb state is stored in PSTATE.T and not in R15. Also, > even > if it would be R15.0, why would kernel need it masked ? > I assume that a page fault on an instruction fetch would have the low bit set in the FAR in thumb mode, and the fault handler would have to cope with that. Maybe not, it wasn't me that wrote that part of the arm kernel support. But it seems like you yourself just gave an example of why the kernel would be involved in thumb-or-not stuff... to resume execution after a fault you'd have to adjust the PC to the faulting instruction, and how much to adjust it would be based on whether the faulting code was in thumb mode or not, so the fault handler would have to examine the status register for the mode. I imagine there's a handful of places where that sort of thing comes up in the kernel, and if nobody has ever tested it, I imagine there's a bug or two lurking there. -- Ian From owner-freebsd-arm@freebsd.org Sat Oct 26 07:44:39 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B93191634F9 for ; Sat, 26 Oct 2019 07:44:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-34.consmr.mail.ne1.yahoo.com (sonic317-34.consmr.mail.ne1.yahoo.com [66.163.184.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 470Y0Q4zKpz3NJ0 for ; Sat, 26 Oct 2019 07:44:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: QX9qqFAVM1m3hF2_5LD2BZJ6vbkeYwKHjMtvzD0.OyE8AeOnmpIYEH6xQ74iOtq bLDoyyX40blrbdruLnN6R9F0oABqssoDdg7JHMjTai8PDtQERWLPQRGSsNjIfFCwew71S_3EmHFy a44JzZpmQobbR4Knh.q3P2.3_jdX4f89mEFkN2Ntb4UHCtmUKaVMuZOiiWJ72EFXobrd5LKgUnEz SfXuw8FCpKnVHeYcH_e2A_EV9OnOLkqeMnd_cUQVvxxx_CpH8tzwCpKf6UzfGMANwlc6WZyEuxWJ Ofy1AwytM6oTWgJprRZk7eZzKA33G1ogQ3nNnHGJkbafGyLinD22vhMCMcH.MpRRS2yX3hMFkM6f WPTUTleN3GbS9fLRdOVODc_XITvFILCiR_0THOKKzYx7Ii27eTgrzfE9EMTueI_ECLbQGzeBXoxV .50c_4Uz_swTWvk_nUM4eZYqcli4EI4EYUZHYnK5DWe995Mskh8c2ur5T0rAQdFr.9fIoZdVK9cG Qr.AEtKQ6g4Tjb3C4A6d_3s5mdVKwi_n5UUDzS74C.sm.NRdjNnt.T9KxLQicR8VGX4xpSZE_Ahz s7NnRv9GTZo7WSGC6hTyGkESBQlC0KPr_6PI5Ju9KJ8T0AZgSq9E1SbEUUhhg6BIH5Jxra1lnHiC DVoiKd58eyqIP.3h3Q5t3Oe237MydmNdzdk2GAqE1OlXYTejegdVdYx.XQJsxkhPbqxoo.YU2jgR d26fLcl.7dVIcv1bw8iRHJXhuX9TbSzY.XTo5MGkiIdK5iAyvv1YYYhTEBfY0a2jxhOJo8mp4uLL n6ZHhlPUzHxxPaiB2oLr3DrqLR7.dYSEHiUoq6qLqbQo64kTEegtYusO3G48WsMiawVW0_5Y2dae 0NHOUSL2r5qmV8B_g98X_QfmQ6TosjZLi8v29_Yjn6iVCZX0zhKgKcWJpfDGDgK4KokZsB_kWs._ ST2pEQKRCZaSn2U2bqskeYsNPYH.ebA22wocg8RpZOIqe72tcAo1WvbHFI3kB8OB1a27fXJs.9RI xhXtAmpDvjAn0Acawzsn_1BVG8Az8dSjS_TQzHKtHzrVE0OyMrp34nsMONNNPcHQUwXNV0eFea58 g5UJOdvN_Iy9BqNPMU5u0PqdVKaCr5pjXfxn9fKWbcIiC_RbohGncupjq7b_IVbAE3dQgtRZd380 _lk66qigD7a4KTmfex9VU1TsSTPfIBPlGpnX8Hfao2Mzz5Dss1lrzMe.DyDWTCw1VeXCRSFLk8Ow iV6OHVlrZ86ag6Ufuzp.rbzv9sPXSboQi9Z4uEqSNFIpVBkzx3OUmSE2jvXIDSqefvNO9LEnrYF0 TpLqRlZ_nFQ0L8TDt2cGInlGsKkyfIHU1SIn7s2QoGC795T_SHSXb.Bra2g4f9WlsKEw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Sat, 26 Oct 2019 07:44:36 +0000 Received: by smtp411.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 94a007704224a756ebb03d4c52b7849d; Sat, 26 Oct 2019 07:44:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: A comparison of ARMv8 Cortex-A57 OverDrive 1000 vs. powerpc64 PowerMac11,2 (2 socket/2 cores each): fairly modern vs. older, higher power Message-Id: <88DAC6B2-35F0-4F61-AEE1-51FC32F09776@yahoo.com> Date: Sat, 26 Oct 2019 00:44:34 -0700 To: freebsd-ppc@freebsd.org, freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3594.4.19) X-Rspamd-Queue-Id: 470Y0Q4zKpz3NJ0 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.04 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.69)[-0.692,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.84)[-0.843,0]; RCVD_COUNT_TWO(0.00)[2]; MV_CASE(0.50)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[45.184.163.66.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (3.75), ipnet: 66.163.184.0/21(1.32), asn: 36646(1.06), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 07:44:39 -0000 Just a comparison I thought was interesting. The comparison is in the .png's of the plots. I reference where to get the .png's. I reference two plots from a variation on the old HINT (Hierarchical INTegeration) serial and pthread benchmarks. (The variation's code uses C++17 facilities.) HINT and acpphint are CPU/memory use benchmarks (unless operated up into sizes that page to disk). Trials for kernel vector sizes that are large tend to make caches less effective. So acpphint's exploration of kernel vector sizes shows the related consequences. In the plots "higher is faster". The dark curves are the OverDrive 1000. The light curves are the PowerMac11,2. The blue curves are single threaded, not measuring any thread creation overhead. The green curves are multi-threaded, with 4 threads, matching the core counts, thread creation overhead included in the times measured. Four data types are covered: 32 bit unsigned (abbreviated ui), 2 examples of 64 bit unsigned (ull and ul), double (d). On the OverDrive, double is slower than the 64-bit unsigned types; on the PowerMac11,2, double is faster than the 64-bit unsigned types. For 32-bit (ui) the maximum kernel vectors size is limited in the plots, compared to the other data types. .png of the plot for X axis being the total kernel vector bytes for the median-timed trial for that size: = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-OverDrive_1000_PowerMac11%2C2-threads_4-LP64-g%2B%2B_9_O3-libc%2B%2B-D= SIZE_large_fast_types-RAM.png .png of the plot for X axis being the time (sec) for the total kernel vector bytes for that median-timed trial: = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/acpph= int-OverDrive_1000_PowerMac11%2C2-threads_4-LP64-g%2B%2B_9_O3-libc%2B%2B-D= SIZE_large_fast_types-time.png The OverDrive 1000 is generally faster for what the benchmark measures, other than data type double for single threaded. (The PowerMac11,2 was running a FreeBSD that was not built via gcc 4.2.1 but via system-clang used with devel/powerpc64-binutils. But the FreeBSD was [and is] still ELFv1 based. For the OverDrive, Cortex-A57 was directly targeted in the system build and the benchmark build.) For both targets: devel/gcc9's g++9 was used to build the benchmark, but in such a way to be using just FreeBSD system libraries, such as libc++ instead of libstdc++. The plots are from gnuplot. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Oct 26 10:58:51 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D025116B758 for ; Sat, 26 Oct 2019 10:58:51 +0000 (UTC) (envelope-from testcb00@gmail.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 470dJV358kz424r for ; Sat, 26 Oct 2019 10:58:50 +0000 (UTC) (envelope-from testcb00@gmail.com) Received: by mail-vs1-xe2a.google.com with SMTP id b123so3237675vsb.5 for ; Sat, 26 Oct 2019 03:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4B+p6Elz4FlnUxKdsazG9YAkitJ4re8F8DVquTMqMl4=; b=FTqRisqhMgd1sIKKQjDw5+5/Pt/eHc1bo3wXz8ov5i61XLC6BvxaAlV7l7LQN82BCV ipIiQIR+kdVygUWyudjaETlEl9tmzO/xodL9qWk8sVuVyePXKfCtFEPZwonPlzHs6uB6 xJayPndZeapysxu8+MgFVCD6zTYTIdKhdxZBZu2UeM+H3w+1hDqJ1JusMBsrzjYS+aQk dC9RpkFhzcMz5YsKrD7xo+JMAsfCmXoyBUYOmmnW3AN6d1wDe7gPrZxkK4UFbwOkajM7 hQfuLZxN7rqVc0e368n9q9AT3fmjxpxzCADLgoDZPt3vbuQS9hmnCpzJS5aN4H0PefG5 NStg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4B+p6Elz4FlnUxKdsazG9YAkitJ4re8F8DVquTMqMl4=; b=OliIrQl++0o0e2aVrFX5Xd3f2bLpkJh+CvDlZqSXxz5JtZx4BOTBZvvlbxp2JBFtn4 sdCcN4/byChrW14ccynyBPPdqjFuXChYrIKDeY2F9kW8Htg5dEk0f6f/HTegp7uk/yiQ 8/El+tuv4gs7Np10/90njiJvmMg0RfbF69kwFekKNAWToiP22078xorMZz6VkJMT8wDz 6DkkjmGVSVdL1yuEzYiLj/hPyoGbqii3OBPkOzWjzztu+cH8PI/AXZStMmsw/zPzWVYg igbXVhM7ki4IoCnlqJjpduAkv4XZzEeGozkwwJvq77wOzSu9vwqXKSiTkQYE+D2oKeGT Kcgw== X-Gm-Message-State: APjAAAXNas2KRc0yVbXNHvicUPL4xZZ6TTZFOmnVgEhKHgyQ4m898Icl hnhqR/MaUjHt4EHClMZQkoTUloWUsshs2pTxwQ4pFBZOV3t4sg== X-Google-Smtp-Source: APXvYqwEVzmc+4+7BFWUrudel75bFFqR11bG7yxg/Ld0B8RE2R5RZ9mEQyovKsJASL5DqT+hAtb+Cdc5go4FGOPIJk4= X-Received: by 2002:a67:db8a:: with SMTP id f10mr4542198vsk.7.1572087529021; Sat, 26 Oct 2019 03:58:49 -0700 (PDT) MIME-Version: 1.0 From: ro Ze Date: Sat, 26 Oct 2019 19:58:37 +0900 Message-ID: Subject: Is it possible to build a ZFS Raspberry Pi 3B/3B+/4 image? with other questions. To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 470dJV358kz424r X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=FTqRisqh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of testcb00@gmail.com designates 2607:f8b0:4864:20::e2a as permitted sender) smtp.mailfrom=testcb00@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-9.72), ipnet: 2607:f8b0::/32(-2.40), asn: 15169(-2.05), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[a.2.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 10:58:51 -0000 Hi everyone, it is my first FreeBSD post. I am using FreeBSD 12.1-RC2 RPI3 image in my Raspberry Pi 3B+. I have a few experience on FreeNAS and I know the two system are not the same. On FreeNAS, there is a tool named iocage which is a FreeBSD Jail manager. Using the iocage, I am allowed to pass a dedicated network interface to the Jail via the vnet feature which is default supported in FreeBSD 12.0. With that feature, I have a idea of using FreeBSD Jail in my Raspberry Pi and I start to do this. Before flashing the image to SD card, I had downloaded x86 DVD and installed as a VM to learn the basic command in FreeBSD. Since the installation process allowed me to use ZFS as the root file system, I only had few trouble in installing the iocage and using the Jail with vnet. However, I found that the root file system of FreeBSD RPI3 image is UFS, which is not supported by iocage. This means that I will have to use another storage device to create a new zpool for iocage. Since Raspberry Pi doesn't have native SATA port and all it's USB ports are come from USB Hub, I believe that using iocage inside the USB will have a huge performance drop. However, to try the feature, I adopt this situation, create a USB zpool for iocage. I have build a zpool for Jail storage in another USB stick in my FreeNAS and I am now import the pool to my Raspberry Pi, and mount to the Jail. Question part. So, is there a way to build a ZFS image (zroot) so that I could use iocage natively in my SD card? I also learned that I could mount a ZFS file system (zpool) as nullfs to Jail but I don't know the difference between ZFS, zpool, dataset, zvol, nullfs. I think that ZFS is like NTFS in Windows or EXT4 in Linux. While zpool is like RAID but zpool itself is already ZFS formatted, normal RAID should be formatted after creating the RAID volume. And zvol is block storage while dataset is file storage like a folder. But I cannot understand the difference between zvol and dataset, and why I could mount a zpool as nullfs inside the Jail? ZFS and nullfs should be two different file system. Thank you to read this thread and sorry for my English as I am not a native user. Zero From owner-freebsd-arm@freebsd.org Sat Oct 26 16:39:25 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C266917901E for ; Sat, 26 Oct 2019 16:39:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 470msS5PRpz4Mkb for ; Sat, 26 Oct 2019 16:39:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id x9QGdKDm039070 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Oct 2019 09:39:21 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x9QGdK0o039069; Sat, 26 Oct 2019 09:39:20 -0700 (PDT) (envelope-from fbsd) Date: Sat, 26 Oct 2019 09:39:20 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Permissions when moving storage devices between hosts Message-ID: <20191026163920.GA38958@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 470msS5PRpz4Mkb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.882,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.08)[ip: (0.33), ipnet: 50.1.16.0/20(0.16), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.98)[-0.976,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 16:39:25 -0000 Not sure if this is an issue with FreeBSD, freebsd-arm or *nix in general. I'm having what look like throughput problems with a microSD card on a Raspberry Pi3b running -current. Things like svnlite update, tar and make install seem to take forever, if one watches gstat the queue length hops wildly from zero to hundreds sometimes. At other times the queue stays short and throughput looks reasonable. As a test, I used benchmarks/bonnie to run a test on the card, writing a log file to the card. Next, I moved the microSD card to a usb/microSD adapter and plugged it into an Rpi2b host running stable/12, mounting it on /mnt The plan was to re-run the bonnie test on the second host to see if the choice of host made much difference. Alas, after mounting the card, all owners/groups are freebsd/freebsd and I can't get permission to write any files, at least as a regular user. The usernames are the same on both hosts and I'm hesitant to try mucking about with ownerships. It does not seem possible to simply add world-write permissions to the test directory using chmod +w as root. It seems there must be a way to do the experiment, but perhaps there's a better way. The goal is merely to determine if the card's gone bad or something else is wrong. It's a Samsung Evo + 128GB, a few months old and worth enough that I don't want to blindly replace it. Thanks for reading, and any ideas! bob prohaska From owner-freebsd-arm@freebsd.org Sat Oct 26 16:42:34 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EB87C1792CF for ; Sat, 26 Oct 2019 16:42:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 470mx55nGhz4N3C for ; Sat, 26 Oct 2019 16:42:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id m15so8212786qtq.2 for ; Sat, 26 Oct 2019 09:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V4hxd/sZQhExkTCdUxHM95UjWtC7mV0fufQXx6K8JTQ=; b=eNx23NcCsNW+14o+fDb5NPYKUCD3J1Yd+aSG4WhOtonRjL0OMN0V5ByHE29uoo3AL3 4q5jngQOgXc3K3NB5cMjDh3x308ZKqnmiBF1wNx4140xvbKPW3XiaK8IWKn5QEyzrmkh LpXoN9xBeF1UBf4+CmuDQBYEKXnEfcdpkaH0GQDjqJllBRIhDRf6q/Oyk/GaSDS1/08l ae0pJDYXRBlQ7pvvCuz7M2gWbMPS3CwnYNGEUXcu4i+dSyYXT5EdLcrMuBY/nGp1Jsyf L/kWxOHzvtT3+9YINlOmzOz4jyjTGjZFDVjr14hzBmtUa1oNHrD0mYFFVyXwprVq7l/E I03w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V4hxd/sZQhExkTCdUxHM95UjWtC7mV0fufQXx6K8JTQ=; b=cHgE1BH6esQLfSdeebVNLwkGt4m/oaeF5PI+/9d20r0ZEwPzTln+InTAjHwTGv69NT r+8APWeVmtmOIgzlPlJEpP8Bq/TB9GczDPHw+FnSeHa7914iXd4zM+mXcSrFVB8pV8I7 gttTESTBa3AOh5TzGSZZB9kobObM3VRvWQ4DehcXztdfpR2Xow4BOUO4onqibwneEbjR H9aa3wYRQNvHUGnPSEc9fag5ZLYD7ScFbHsAg17EaLFLNNGwwwocKbGmfV19FhN5i10T 8+g7QSPmTn0f1ZOzK04vsVUnIGJerK5N4J0Qs0A0eo0veNwtBxhsV5lUSuSxDTDXe8Hf 4/Hg== X-Gm-Message-State: APjAAAVzxLaQl2HhR+W0XEIcCm08icraf5h+UlQzcGn8/cH2pXI84iIS fuMnHpe0nhconoHG+KMl6EQfcBdIn/rKvYs65i9o6Q== X-Google-Smtp-Source: APXvYqymwczMXaJeKyjhkFntjWDb0/KIU0LzKJi6t3Vm+L1JvvYBFiG4P/9lOPUd8or0sZdO26Pz3DcS/lcuttzcb2k= X-Received: by 2002:ad4:442d:: with SMTP id e13mr1290016qvt.202.1572108152332; Sat, 26 Oct 2019 09:42:32 -0700 (PDT) MIME-Version: 1.0 References: <20191024141133.04fb0693@i11.co> <20191024145436.GX73312@kib.kiev.ua> <20191025104421.012c1e5e@i11.co> <20191025083803.GD73312@kib.kiev.ua> <78c9868cf23643dfa2f88694542e86251bde13e7.camel@freebsd.org> <20191025144957.GE73312@kib.kiev.ua> <20191025145918.GF73312@kib.kiev.ua> <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org> In-Reply-To: <7fddb657a8a1724c5ae75442e21d4a7f448a0c99.camel@freebsd.org> From: Warner Losh Date: Sat, 26 Oct 2019 10:42:20 -0600 Message-ID: Subject: Re: ucontext To: Ian Lepore Cc: Konstantin Belousov , freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 470mx55nGhz4N3C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=eNx23NcC; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::841) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.41)[ip: (2.48), ipnet: 2607:f8b0::/32(-2.40), asn: 15169(-2.05), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 16:42:35 -0000 On Fri, Oct 25, 2019, 9:08 AM Ian Lepore wrote: > On Fri, 2019-10-25 at 17:59 +0300, Konstantin Belousov wrote: > > On Fri, Oct 25, 2019 at 08:51:41AM -0600, Ian Lepore wrote: > > > On Fri, 2019-10-25 at 17:49 +0300, Konstantin Belousov wrote: > > > > On Fri, Oct 25, 2019 at 08:26:19AM -0600, Ian Lepore wrote: > > > > > On Fri, 2019-10-25 at 11:38 +0300, Konstantin Belousov wrote: > > > > > > On Fri, Oct 25, 2019 at 10:44:21AM +0300, Nick Kostirya > > > > > > wrote: > > > > > > > On Thu, 24 Oct 2019 17:54:36 +0300 > > > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > > > > > > > > > > > I believe you want > > > > > > > > uc_context.__gregs[_REG_PC] > > > > > > > > on arm (32bit) and > > > > > > > > uc_context.mc_gpregs.gp_elr > > > > > > > > on arm64 for aarch64. > > > > > > > > > > > > > > > > Sometimes the thumb bit (lowest bit in PC) leaks there, > > > > > > > > then > > > > > > > > you should > > > > > > > > mask it. > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > Although I did not understand your last phrase. > > > > > > > There is leak of what? > > > > > > > > > > > > Leak of the thumb bit. ARM ARM specifies that in non-thumb > > > > > > mode, > > > > > > pc must > > > > > > be word-aligned, in thumb it is half-word aligned. A way to > > > > > > enter thumb > > > > > > mode is to execute BX or BLX instruction with the lowest bit > > > > > > of > > > > > > the target > > > > > > PC set to 1. > > > > > > > > > > > > Sometimes you might get pc with the bit 0 set, which should > > > > > > be masked out then. This is a bigger issue for unwinders > > > > > > than > > > > > > for simple > > > > > > profilers. > > > > > > > > > > > > > Where can I read about it? > > > > > > > > > > > > ARM ARM (ARM architecture reference manual), available from > > > > > > arm.com. > > > > > > Or Google for it. > > > > > > > > > > > > > > > > The kernel has some support for running thumb binaries, but > > > > > I've > > > > > never > > > > > heard of anybody actually doing so on freebsd. Nobody has ever > > > > > reported a bug related to running a thumb binary, and it would > > > > > be > > > > > astounding to me if we accidentally got everything in the > > > > > kernel > > > > > thumb > > > > > support right on the first try without ever testing it. > > > > > > > > I am curious as well, isn't thumb completely transparent to the > > > > kernel ? > > > > I.e. my impression was that some code might be compiled into > > > > thumb, > > > > and > > > > then a thunk which does BX to the location, is used to switch to > > > > thumb > > > > mode. There is no new ELF machine type involved, or different > > > > exception > > > > entry mode, so it should just work ? > > > > > > > > And this is why I remember about this bit 0 issue, it caused some > > > > problems > > > > to libunwind on arm. > > > > > > > > > > I think in the kernel it would appear in places like page fault > > > handlers needing to mask off the lower bit. > > > > Normally thumb state is stored in PSTATE.T and not in R15. Also, > > even > > if it would be R15.0, why would kernel need it masked ? > > > > I assume that a page fault on an instruction fetch would have the low > bit set in the FAR in thumb mode, and the fault handler would have to > cope with that. Maybe not, it wasn't me that wrote that part of the > arm kernel support. > > But it seems like you yourself just gave an example of why the kernel > would be involved in thumb-or-not stuff... to resume execution after a > fault you'd have to adjust the PC to the faulting instruction, and how > much to adjust it would be based on whether the faulting code was in > thumb mode or not, so the fault handler would have to examine the > status register for the mode. I imagine there's a handful of places > where that sort of thing comes up in the kernel, and if nobody has ever > tested it, I imagine there's a bug or two lurking there. > For mips, there are places we decode instructions. If we need to do that on arm, then I'm surprised with 0 bug reports from that angle as well... Warner -- Ian > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >