Date: Mon, 30 Nov 2020 16:41:02 +0100 (CET) From: Ronald Klop <ronald-lists@klop.ws> To: Philip Paeps <philip@freebsd.org> Cc: Kurt Jaeger <pi@opsec.eu>, Cluster Administrators <clusteradm@freebsd.org>, Steve Wills <swills@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: aarch64 pkg build seems broken/hanging Message-ID: <1846211902.1.1606750862152@localhost> In-Reply-To: <4F2C84A9-72EF-4041-B28B-CFDF5A10DF80@freebsd.org> References: <735767609.10.1597159067683@localhost> <op.0pf4q6ofkndu52@sjakie> <504493339.1.1597829845980@localhost> <1268679721.21.1598955250524@localhost> <2128344036.116.1599572445531@localhost> <93ab93ce-8887-315e-c775-0929c716032a@FreeBSD.org> <20200909142039.GK53210@home.opsec.eu> <op.0teh5mejkndu52@sjakie> <4F2C84A9-72EF-4041-B28B-CFDF5A10DF80@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Van: Philip Paeps <philip@freebsd.org> Datum: maandag, 30 november 2020 06:30 Aan: Ronald Klop <ronald-lists@klop.ws> CC: Steve Wills <swills@freebsd.org>, Kurt Jaeger <pi@opsec.eu>, freebsd-arm@freebsd.org, Cluster Administrators <clusteradm@freebsd.org> Onderwerp: Re: aarch64 pkg build seems broken/hanging > > On 2020-11-01 19:28:24 (+0800), Ronald Klop wrote: > > On Wed, 09 Sep 2020 16:20:39 +0200, Kurt Jaeger <pi@opsec.eu> wrote: > >>> Sorry, but this is not a portmgr@ issue, this is a clusteradm@ >>> issue. > >> > >> philip@ (with clusteradm@ hat) checked the issue and explained the > >> cause of the problem: > >> > >> The thunderx hardware currently in use in the cluster is a very early > >> version and has stability issues. A replacement is @work. > > > > I don't want to be pushing the issue, but do you have some information > about the progress of the aarch64 hardware issues? > > The new aarch64 systems arrived at the data centre on Friday (local time) and were installed and configured in the cluster yesterday (my time). They'll start running builds soon. Packages will start appearing on the mirrors shortly after. > > Steady progress... > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > > > Great news! Thanks for the update. Do you have some nice details about the new systems? Just for my curiosity. Probably a bit better than the RPI4 I installed to build my packages in the meantime. :-) Regards, Ronald. From owner-freebsd-arm@freebsd.org Mon Nov 30 21:52:23 2020 Return-Path: <owner-freebsd-arm@freebsd.org> 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 D33AD4A95D3 for <freebsd-arm@mailman.nyi.freebsd.org>; Mon, 30 Nov 2020 21:52:23 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ClJqW2fDTz4m20 for <freebsd-arm@freebsd.org>; Mon, 30 Nov 2020 21:52:23 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1606773142; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=PcAt5zLs1Xjd7oMkPlyvZAGGKj/9v08Fq8tDEsN2NYlOAY4C72vBshZudvcklj0EOfWCX4dKXTWAJ b4e4RVYJtoK6xBY4c21h6QTP4f/XhjhySuUGVxONJKowETkSXGVeP601yNy7oUYj3yn231Crwx1aM9 D9F/3h0d3h2ALwog0qh0aN2t2rgXQLKDVjndAWOeyl+VJPbysGEyrDqSOLd4oS+A4G6A+vBcF8j88X DvIARNpy5RoEfE2gfRktnPntqekathv8wZYftXVlt/X5FDhdDux/yiP9VqFn8f4qPxxqm5/aV+sPQK cNRjqUSyv2+esaanf7rwKL4B7qlDB2A== 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=BlqKb8oQ8YrPoiv/kE5ClHZeflc9aSOKPEVyTg4YU+U=; b=tVAxyMp4bW3II0SOOXDcUROWf/1mH67YkqoXEJ0NYKbc0UAnTv74C+norF+V9b068hxd6rj2mp6U+ 7xiCHw0MMUlxTb6Lz7/Bcu4e7rv2rQDmrvGqm93tT3oxzftKq5icYCNeMCAPY+oCOo5qa53t5GUuME dSgBgzELtj9kK9T/5QQ/kyfzE8JkL3VIwjCkM63oQaS8rRZMu1zFcAT+X47NAGfcvtMTvUgFqkGrGJ n7htC3e3OUluq2SeBjTI3myfwABbsEqW7RDBcoaCyeiORqMwWwRhwq3LlWdTsmGFezyI4CrvuhBeW3 F3IeXszmVr1HOJUascYVDyB9Z2QL9ZA== ARC-Authentication-Results: i=1; outbound3.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=BlqKb8oQ8YrPoiv/kE5ClHZeflc9aSOKPEVyTg4YU+U=; b=KVctnk/fOOBWL4V85ykPC15d/LiF3HnRRrfTg0eMNUzUn/8wMH5u23Pev625CmlN1oxwr0Gl6Ui14 72fzOE806MVZJdmgK2ry86Q8cq3FVUF/dcQDx0huBoTFPcj26bPHBJ5XVPv1bumECB3HgLNb808OLv bD1osASSzg6p8IEOEhKhA5rtEH4IwhhzqKjWuLEk3oVXdpbVImMwfnPxBvJV5Q5Nr+Y1eWY+2RFgra VmKoUtCNPlHvu9xBiofxe7ppTgrGMMeaja4VzsFoyAcBovFzm2WTZVnELR6QVgebT6+kqXtoTNweyJ E/9e8XkBWQcfIPNGcI0L/kt5WU3kojg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 51549ff0-3356-11eb-8b39-614106969e8d 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 (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 51549ff0-3356-11eb-8b39-614106969e8d; Mon, 30 Nov 2020 21:52:20 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0AULqIwj091917; Mon, 30 Nov 2020 14:52:18 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <af7527d32fcfbf5a7e09bdf6eda9467ce1342639.camel@freebsd.org> Subject: Re: User Space GPIO Interrupt programming - GSoC-2018 From: Ian Lepore <ian@freebsd.org> To: "Dr. Rolf Jansen" <freebsd-rj@obsigna.com> Cc: freebsd-arm@freebsd.org Date: Mon, 30 Nov 2020 14:52:18 -0700 In-Reply-To: <BD08359D-C61D-454F-95A1-92B248707B9C@obsigna.com> References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> <c55d7f332631b69c3241a60538a6a7b5475d93b9.camel@freebsd.org> <FBEF19B1-0504-4CDF-976C-C50707E06584@obsigna.com> <8d806302-479c-ca34-3fdb-96d27f40e212@viruzzz.org> <8655AF30-273B-48E7-98CD-007AA1D265F5@obsigna.com> <54ffe2d2-01a2-8b43-94fa-aee4a3f89861@viruzzz.org> <08649892ca2ab434c261d36e0e13ba051086de6f.camel@freebsd.org> <1e6993d43d22d6ce1aa2860a61745356688d1e53.camel@freebsd.org> <BD08359D-C61D-454F-95A1-92B248707B9C@obsigna.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4ClJqW2fDTz4m20 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 30 Nov 2020 21:52:23 -0000 On Fri, 2020-11-27 at 19:45 -0300, Dr. Rolf Jansen wrote: > Am 27.11.2020 um 15:04 schrieb Ian Lepore <ian@freebsd.org>: > > On Fri, 2020-11-27 at 10:16 -0700, Ian Lepore wrote: > > > On Fri, 2020-11-27 at 14:28 +0300, Vladimir Goncharov wrote: > > > > Here it is. > > > > There is struct gpioc_event with pin number and bintime which > > > > is send > > > > to userspace. > > > > > > > > Also I'm thinking about to implementation notofication without > > > > extra > > > > reading from socket via struct kevent's extra fields > > > > (fflags/ext[4]), > > > > looks like it is possible. > > > > > > > > > > Please don't top-post on freebsd mailing lists. > > > > > > I think we need a way for the app to choose whether it wants > > > simple > > > reporting of pin number (like the original code) perhaps along > > > with a > > > count, versus requesting detailed per-event data. I'm going to > > > propose > > > something more detailed about this as soon as I get my thoughts > > > all > > > organized. I also want to get the original code and the locking > > > fixes > > > I've done to it into a phab review for people to start looking at > > > before starting to do new major changes to it. > > > > > > Allocating memory in the interrupt handler isn't a good idea, it > > > will > > > just increase latency on processing other pin interrupts and lead > > > to > > > inaccurate timestamps. IMO, it would be better to allocate a > > > fixed > > > array of events; when the app requests detailed event reporting > > > it can > > > request the number of stored events it wants handled and we could > > > allocate all at once based on that. > > > > > > > The gsoc2018 code, with locking and style(9) fixes, is now at: > > > > https://reviews.freebsd.org/D27398 > > I got it working, and as expected, by your comments the level > interrupt mode has been disabled. I am OK with this. Later, I will > add more comments on this in my response to you other e-mail. > > Best regards > > Rolf I've just updated the phabricator review with new code. This adds the detailed versus summary reporting. I decided the detailed reporting should still be the default like it was before, but now it can handle many events between calls to read(), unlike the old code that only stored one pin change event between calls. Now it uses a circular buffer, and there's a new ioctl function for increasing the size of the buffer (or switching to summary reporting mode). I incorporated Christian's test program into the phab review, and added some enhancements to it. It shows how to read and interpret the new detailed and summary structures, how to convert the monotonic clock event timestaps to UTC if needed (*), and how to handle getting multiple event notifications with each read() call (by passing a big buffer and parsing the structs from it after the call). https://reviews.freebsd.org/D27398 (*) The conversion of monotonic to utc time doesn't attempt to deal with the system clock being stepped between the time an event was recorded and when it is printed. In the real world, system time gets stepped when the system boots, not at random while apps are running. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1846211902.1.1606750862152>