From owner-freebsd-arm@freebsd.org Sun Dec 30 15:34:12 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA304142BA7B for ; Sun, 30 Dec 2018 15:34:11 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mogw1022.ocn.ad.jp (mogw1022.ocn.ad.jp [153.149.231.28]) by mx1.freebsd.org (Postfix) with ESMTP id 25B0989AD0 for ; Sun, 30 Dec 2018 15:34:07 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mf-smf-unw007c2 (mf-smf-unw007c2.ocn.ad.jp [153.138.219.100]) by mogw1022.ocn.ad.jp (Postfix) with ESMTP id 58166A8023F; Mon, 31 Dec 2018 00:33:57 +0900 (JST) Received: from ocn-vc-mts-104c1.ocn.ad.jp ([153.138.237.81]) by mf-smf-unw007c2 with ESMTP id dcyogdv3UQXHCdd6DgZg7A; Mon, 31 Dec 2018 00:33:57 +0900 Received: from smtp.ocn.ne.jp ([153.149.227.134]) by ocn-vc-mts-104c1.ocn.ad.jp with ESMTP id dd6Dgk3pUq2v1dd6DgR5xS; Mon, 31 Dec 2018 00:33:57 +0900 Received: from localhost (p571097-ipngn200409sizuokaden.shizuoka.ocn.ne.jp [180.33.36.97]) by smtp.ocn.ne.jp (Postfix) with ESMTPA; Mon, 31 Dec 2018 00:33:57 +0900 (JST) Date: Mon, 31 Dec 2018 00:33:56 +0900 (JST) Message-Id: <20181231.003356.1147810385398844555.toshi@ruby.ocn.ne.jp> To: freebsd-arm@freebsd.org Subject: SPI start bit (9 bit) for BBB From: SAITOU Toshihide X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 25B0989AD0 X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of toshi@ruby.ocn.ne.jp designates 153.149.231.28 as permitted sender) smtp.mailfrom=toshi@ruby.ocn.ne.jp X-Spamd-Result: default: False [6.38 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.149.231.0/26]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[ocn.ne.jp]; NEURAL_SPAM_MEDIUM(0.98)[0.979,0]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; RBL_VIRUSFREE_BOTNET(2.00)[28.231.149.153.bip.virusfree.cz : 127.0.0.2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[mfgw1.ocn.ad.jp,mfgw1.ocn.ad.jp,mfgw1.ocn.ad.jp,mfgw1.ocn.ad.jp,mfgw1.ocn.ad.jp,mfgw1.ocn.ad.jp,mfgw1.ocn.ad.jp,mfgw1.ocn.ad.jp]; NEURAL_SPAM_LONG(0.98)[0.982,0]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_SHORT(0.54)[0.541,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4713, ipnet:153.128.0.0/11, country:JP]; IP_SCORE(0.29)[ipnet: 153.128.0.0/11(2.09), asn: 4713(-0.55), country: JP(-0.09)] X-Spam: Yes 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, 30 Dec 2018 15:34:12 -0000 In 3-line serial protcol, there is a type using additional 1-bit to specify command or data. The BBB can handle this, so I can use with the following patch (unskillful and maybe side effects exist). I hope this will attract someones interest to implement this and also SPI frequency and mode. --- arm/ti/ti_spi.c.orig 2018-12-22 00:47:12.096034000 +0900 +++ arm/ti/ti_spi.c 2018-12-30 23:58:00.000000000 +0900 @@ -493,6 +493,7 @@ ti_spi_transfer(device_t dev, device_t child, struct s /* Disable the FIFO. */ TI_SPI_WRITE(sc, MCSPI_XFERLEVEL, 0); +#if 0 /* 8 bits word, d0 miso, d1 mosi, mode 0 and CS active low. */ reg = TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); reg &= ~(MCSPI_CONF_FFER | MCSPI_CONF_FFEW | MCSPI_CONF_SBPOL | @@ -501,6 +502,7 @@ ti_spi_transfer(device_t dev, device_t child, struct s MCSPI_CONF_DMAW | MCSPI_CONF_EPOL); reg |= MCSPI_CONF_DPE0 | MCSPI_CONF_EPOL | MCSPI_CONF_WL8BITS; TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); +#endif #if 0 /* Enable channel interrupts. */ @@ -558,6 +560,70 @@ ti_spi_get_node(device_t bus, device_t dev) return (ofw_bus_get_node(bus)); } +static int +ti_spi_sbe(device_t dev, device_t child, uint32_t *request) +{ + struct ti_spi_softc *sc; + uint32_t reg; + + sc = device_get_softc(dev); + + TI_SPI_LOCK(sc); + + /* If the controller is in use wait until it is available. */ + while (sc->sc_flags & TI_SPI_BUSY) + mtx_sleep(dev, &sc->sc_mtx, 0, "ti_spi", 0); + + /* Now we have control over SPI controller. */ + sc->sc_flags = TI_SPI_BUSY; + + reg = TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); + if (*request) + reg |= MCSPI_CONF_SBE; + else + reg &= ~MCSPI_CONF_SBE; + TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); + + /* Release the controller and wakeup the next thread waiting for it. */ + sc->sc_flags = 0; + wakeup_one(dev); + TI_SPI_UNLOCK(sc); + + return (0); +} + +static int +ti_spi_sbpol(device_t dev, device_t child, uint32_t *request) +{ + struct ti_spi_softc *sc; + uint32_t reg; + + sc = device_get_softc(dev); + + TI_SPI_LOCK(sc); + + /* If the controller is in use wait until it is available. */ + while (sc->sc_flags & TI_SPI_BUSY) + mtx_sleep(dev, &sc->sc_mtx, 0, "ti_spi", 0); + + /* Now we have control over SPI controller. */ + sc->sc_flags = TI_SPI_BUSY; + + reg = TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); + if (*request) + reg |= MCSPI_CONF_SBPOL; + else + reg &= ~MCSPI_CONF_SBPOL; + TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); + + /* Release the controller and wakeup the next thread waiting for it. */ + sc->sc_flags = 0; + wakeup_one(dev); + TI_SPI_UNLOCK(sc); + + return (0); +} + static device_method_t ti_spi_methods[] = { /* Device interface */ DEVMETHOD(device_probe, ti_spi_probe), @@ -569,6 +635,10 @@ static device_method_t ti_spi_methods[] = { /* ofw_bus interface */ DEVMETHOD(ofw_bus_get_node, ti_spi_get_node), + + /* provisional chip register interface for SBE and SBPOL */ + DEVMETHOD(spibus_sbe, ti_spi_sbe), + DEVMETHOD(spibus_sbpol, ti_spi_sbpol), DEVMETHOD_END }; --- dev/spibus/spibus.c.orig 2018-12-29 23:50:40.262296000 +0900 +++ dev/spibus/spibus.c 2018-12-30 23:58:00.000000000 +0900 @@ -226,6 +226,18 @@ spibus_transfer_impl(device_t dev, device_t child, str return (SPIBUS_TRANSFER(device_get_parent(dev), child, cmd)); } +static int +spibus_sbe_impl(device_t dev, device_t child, uint32_t *request) +{ + return (SPIBUS_SBE(device_get_parent(dev), child, request)); +} + +static int +spibus_sbpol_impl(device_t dev, device_t child, uint32_t *request) +{ + return (SPIBUS_SBPOL(device_get_parent(dev), child, request)); +} + static device_method_t spibus_methods[] = { /* Device interface */ DEVMETHOD(device_probe, spibus_probe), @@ -247,6 +259,9 @@ static device_method_t spibus_methods[] = { /* spibus interface */ DEVMETHOD(spibus_transfer, spibus_transfer_impl), + + DEVMETHOD(spibus_sbe, spibus_sbe_impl), + DEVMETHOD(spibus_sbpol, spibus_sbpol_impl), DEVMETHOD_END }; --- dev/spibus/spibus_if.m.orig 2018-12-22 00:49:22.440211000 +0900 +++ dev/spibus/spibus_if.m 2018-12-30 23:58:00.000000000 +0900 @@ -39,3 +39,15 @@ METHOD int transfer { device_t child; struct spi_command *cmd; }; + +METHOD int sbe { + device_t dev; + device_t child; + uint32_t *request; +}; + +METHOD int sbpol { + device_t dev; + device_t child; + uint32_t *request; +}; --- dev/spibus/spigen.c.orig 2018-12-29 20:19:20.584696000 +0900 +++ dev/spibus/spigen.c 2018-12-30 23:58:00.000000000 +0900 @@ -248,6 +248,28 @@ spigen_transfer_mmapped(struct cdev *cdev, struct spig } static int +spigen_sbe(struct cdev *cdev, uint32_t *request) +{ + device_t dev = cdev->si_drv1; + int error = 0; + + error = SPIBUS_SBE(device_get_parent(dev), dev, (uint32_t *)request); + + return (error); +} + +static int +spigen_sbpol(struct cdev *cdev, uint32_t *request) +{ + device_t dev = cdev->si_drv1; + int error = 0; + + error = SPIBUS_SBPOL(device_get_parent(dev), dev, (uint32_t *)request); + + return (error); +} + +static int spigen_ioctl(struct cdev *cdev, u_long cmd, caddr_t data, int fflag, struct thread *td) { @@ -272,6 +294,12 @@ spigen_ioctl(struct cdev *cdev, u_long cmd, caddr_t da break; case SPIGENIOC_SET_SPI_MODE: error = spibus_set_mode(dev, *(uint32_t *)data); + break; + case SPIGENIOC_SBE: + error = spigen_sbe(cdev, (uint32_t *)data); + break; + case SPIGENIOC_SBPOL: + error = spigen_sbpol(cdev, (uint32_t *)data); break; default: error = ENOTTY; --- sys/spigenio.h.orig 2018-12-22 00:48:50.752200000 +0900 +++ sys/spigenio.h 2018-12-30 23:58:00.000000000 +0900 @@ -52,5 +52,7 @@ struct spigen_transfer_mmapped { #define SPIGENIOC_SET_CLOCK_SPEED _IOW(SPIGENIOC_BASE, 3, uint32_t) #define SPIGENIOC_GET_SPI_MODE _IOR(SPIGENIOC_BASE, 4, uint32_t) #define SPIGENIOC_SET_SPI_MODE _IOW(SPIGENIOC_BASE, 5, uint32_t) +#define SPIGENIOC_SBE _IOW(SPIGENIOC_BASE, 6, uint32_t) +#define SPIGENIOC_SBPOL _IOW(SPIGENIOC_BASE, 7, uint32_t) #endif /* !_SYS_SPIGENIO_H_ */ -- SAITOU Toshihide From owner-freebsd-arm@freebsd.org Sun Dec 30 17:58:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89382142FCEB for ; Sun, 30 Dec 2018 17:58:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (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 98AB08EA02 for ; Sun, 30 Dec 2018 17:58:53 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1546191728; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=BnnkzFOnK1f2s4qrnBSytJfcyH5RvWo76wFeya/1B4PMPzHeICGk/mDTWUVkcK84eQfXFEUyC11gD VdIMPA8Zv2WiCfb/0HHNt0rEfGQg42FmQr9rIf8m2HHQxP6uoI2sFo161puIpMdjfUZzlOBlkfxaqF iOu/0A1M3wK7lyUdVKNRzpJ8T7HvtrraUnpxFyrD9oKfV7OPtWvBFZHLt77R9jwgACtJ7rr/ZByOWG XHV5Xm/bqyJhnkWAzwQjm0gM6EB31GfCjGPsy2IJ2YI8FUphlP4JZK9hXhEiw0R0ZaclkBTEOacm08 X68a+3TJPrArhOq42Ae8IiFbxFA6f1w== 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:to:from:subject:message-id:dkim-signature:from; bh=8L2y8opAe0zkyLZxIIBYC5ChyqQUSVcRKBXdRMGmf24=; b=jb4YxYzAyVmGkOs9a9yvEpnnyUjv0z22Qx1WSmjjajUjgfYFM0qJs/JGk64oQEc3GXIhxiI6hFcEi +B+gqU9B0LmFzujVanupVgEADnCUtm5KrFJFoXpE38PFbc8iGGsu2+PtLHr02nTVpq5mJqURKKXLn+ 1biCEUhl5Lx9qdmtsptmdmL87kqbjQTgmmQ3jPfetYZwqRmKkCVkeo4JlZfXu5CY4yxIcYqVxTUOkZ LnB4jNKr8/WvOlPJc/hQyhX/QmLwZHzocrEpViWtze1NWGsnizYYmoVRyJ/dK280WkbskDH50Fanje 3pQgWMRU1t9ElI/joDlMJdyQo8xHBfA== 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:to:from:subject:message-id:from; bh=8L2y8opAe0zkyLZxIIBYC5ChyqQUSVcRKBXdRMGmf24=; b=IkZTcIg5uqQR6VvUhNjlaQlVtmY/Mro5/vh2ekMGsE5DB8F0qpjH+AhbkFa9gGZb10BUE8SALk+eH YyD7O4WItZdaSWSwxqmr7/Ic9wStTY/bKKpKps97eyHwcWFcXYas4o7ebdLPXvPvJFBy8yWzrZgQ5x KUj5ZJmSzY+cOV8btinqBCNSfW3xlQDf7dfqe27pEFanbggQajSAhjNlye4fWCWtZV69J5ot0Y3ycu UPlV2rgpQC7udqt7uz7cUY0hpgQntmqdI/NyijMbFyC3Sxje8pJsPTRHBFVkc+VpTZZCpnrCcqIq+4 dPQk5RSzQBcP2MI9hCYmAC3Pq7LWaqg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 396267ac-0c5a-11e9-befd-af03bedce89f 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 396267ac-0c5a-11e9-befd-af03bedce89f; Sun, 30 Dec 2018 17:42:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBUHgd5B028987; Sun, 30 Dec 2018 10:42:39 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1546191759.78877.91.camel@freebsd.org> Subject: Re: SPI start bit (9 bit) for BBB From: Ian Lepore To: SAITOU Toshihide , freebsd-arm@freebsd.org Date: Sun, 30 Dec 2018 10:42:39 -0700 In-Reply-To: <20181231.003356.1147810385398844555.toshi@ruby.ocn.ne.jp> References: <20181231.003356.1147810385398844555.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 98AB08EA02 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,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: Sun, 30 Dec 2018 17:58:54 -0000 On Mon, 2018-12-31 at 00:33 +0900, SAITOU Toshihide wrote: > In 3-line serial protcol, there is a type using additional 1-bit to > specify command or data.  The BBB can handle this, so I can use with > the following patch (unskillful and maybe side effects exist).  I > hope this will attract someones interest to implement this and also > SPI frequency and mode. > > > --- arm/ti/ti_spi.c.orig 2018-12-22 00:47:12.096034000 +0900 > +++ arm/ti/ti_spi.c 2018-12-30 23:58:00.000000000 +0900 > @@ -493,6 +493,7 @@ ti_spi_transfer(device_t dev, device_t child, > struct s >   /* Disable the FIFO. */ >   TI_SPI_WRITE(sc, MCSPI_XFERLEVEL, 0); >   > +#if 0 >   /* 8 bits word, d0 miso, d1 mosi, mode 0 and CS active low. > */ >   reg = TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); >   reg &= ~(MCSPI_CONF_FFER | MCSPI_CONF_FFEW | > MCSPI_CONF_SBPOL | > @@ -501,6 +502,7 @@ ti_spi_transfer(device_t dev, device_t child, > struct s >       MCSPI_CONF_DMAW | MCSPI_CONF_EPOL); >   reg |= MCSPI_CONF_DPE0 | MCSPI_CONF_EPOL | > MCSPI_CONF_WL8BITS; >   TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); > +#endif >   >  #if 0 >   /* Enable channel interrupts. */ > @@ -558,6 +560,70 @@ ti_spi_get_node(device_t bus, device_t dev) >   return (ofw_bus_get_node(bus)); >  } >   > +static int > +ti_spi_sbe(device_t dev, device_t child, uint32_t *request) > +{ > + struct ti_spi_softc *sc; > + uint32_t reg; > + > + sc = device_get_softc(dev); > + > + TI_SPI_LOCK(sc); > + > + /* If the controller is in use wait until it is available. > */ > + while (sc->sc_flags & TI_SPI_BUSY) > + mtx_sleep(dev, &sc->sc_mtx, 0, "ti_spi", 0); > + > + /* Now we have control over SPI controller. */ > + sc->sc_flags = TI_SPI_BUSY; > + > + reg = TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); > + if (*request) > + reg |= MCSPI_CONF_SBE; > + else > + reg &= ~MCSPI_CONF_SBE; > + TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); > + > + /* Release the controller and wakeup the next thread waiting > for it. */ > + sc->sc_flags = 0; > + wakeup_one(dev); > + TI_SPI_UNLOCK(sc); > + > + return (0); > +} > + > +static int > +ti_spi_sbpol(device_t dev, device_t child, uint32_t *request) > +{ > + struct ti_spi_softc *sc; > + uint32_t reg; > + > + sc = device_get_softc(dev); > + > + TI_SPI_LOCK(sc); > + > + /* If the controller is in use wait until it is available. > */ > + while (sc->sc_flags & TI_SPI_BUSY) > + mtx_sleep(dev, &sc->sc_mtx, 0, "ti_spi", 0); > + > + /* Now we have control over SPI controller. */ > + sc->sc_flags = TI_SPI_BUSY; > + > + reg = TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); > + if (*request) > + reg |= MCSPI_CONF_SBPOL; > + else > + reg &= ~MCSPI_CONF_SBPOL; > + TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); > + > + /* Release the controller and wakeup the next thread waiting > for it. */ > + sc->sc_flags = 0; > + wakeup_one(dev); > + TI_SPI_UNLOCK(sc); > + > + return (0); > +} > + >  static device_method_t ti_spi_methods[] = { >   /* Device interface */ >   DEVMETHOD(device_probe, ti_spi_probe), > @@ -569,6 +635,10 @@ static device_method_t ti_spi_methods[] = { >   >   /* ofw_bus interface */ >   DEVMETHOD(ofw_bus_get_node, ti_spi_get_node), > + > + /* provisional chip register interface for SBE and SBPOL */ > + DEVMETHOD(spibus_sbe, ti_spi_sbe), > + DEVMETHOD(spibus_sbpol, ti_spi_sbpol), >   >   DEVMETHOD_END >  }; > --- dev/spibus/spibus.c.orig 2018-12-29 23:50:40.262296000 > +0900 > +++ dev/spibus/spibus.c 2018-12-30 23:58:00.000000000 +0900 > @@ -226,6 +226,18 @@ spibus_transfer_impl(device_t dev, device_t > child, str >   return (SPIBUS_TRANSFER(device_get_parent(dev), child, > cmd)); >  } >   > +static int > +spibus_sbe_impl(device_t dev, device_t child, uint32_t *request) > +{ > + return (SPIBUS_SBE(device_get_parent(dev), child, request)); > +} > + > +static int > +spibus_sbpol_impl(device_t dev, device_t child, uint32_t *request) > +{ > + return (SPIBUS_SBPOL(device_get_parent(dev), child, > request)); > +} > + >  static device_method_t spibus_methods[] = { >   /* Device interface */ >   DEVMETHOD(device_probe, spibus_probe), > @@ -247,6 +259,9 @@ static device_method_t spibus_methods[] = { >   >   /* spibus interface */ >   DEVMETHOD(spibus_transfer, spibus_transfer_impl), > + > + DEVMETHOD(spibus_sbe, spibus_sbe_impl), > + DEVMETHOD(spibus_sbpol, spibus_sbpol_impl), >   >   DEVMETHOD_END >  }; > --- dev/spibus/spibus_if.m.orig 2018-12-22 00:49:22.440211000 > +0900 > +++ dev/spibus/spibus_if.m 2018-12-30 23:58:00.000000000 +0900 > @@ -39,3 +39,15 @@ METHOD int transfer { >   device_t child; >   struct spi_command *cmd; >  }; > + > +METHOD int sbe { > + device_t dev; > + device_t child; > + uint32_t *request; > +}; > + > +METHOD int sbpol { > + device_t dev; > + device_t child; > + uint32_t *request; > +}; > --- dev/spibus/spigen.c.orig 2018-12-29 20:19:20.584696000 > +0900 > +++ dev/spibus/spigen.c 2018-12-30 23:58:00.000000000 +0900 > @@ -248,6 +248,28 @@ spigen_transfer_mmapped(struct cdev *cdev, > struct spig >  } >   >  static int > +spigen_sbe(struct cdev *cdev, uint32_t *request) > +{ > + device_t dev = cdev->si_drv1; > + int error = 0; > + > + error = SPIBUS_SBE(device_get_parent(dev), dev, (uint32_t > *)request); > + > + return (error); > +} > + > +static int > +spigen_sbpol(struct cdev *cdev, uint32_t *request) > +{ > + device_t dev = cdev->si_drv1; > + int error = 0; > + > + error = SPIBUS_SBPOL(device_get_parent(dev), dev, (uint32_t > *)request); > + > + return (error); > +} > + > +static int >  spigen_ioctl(struct cdev *cdev, u_long cmd, caddr_t data, int fflag, >      struct thread *td) >  { > @@ -272,6 +294,12 @@ spigen_ioctl(struct cdev *cdev, u_long cmd, > caddr_t da >   break; >   case SPIGENIOC_SET_SPI_MODE: >   error = spibus_set_mode(dev, *(uint32_t *)data); > + break; > + case SPIGENIOC_SBE: > + error = spigen_sbe(cdev, (uint32_t *)data); > + break; > + case SPIGENIOC_SBPOL: > + error = spigen_sbpol(cdev, (uint32_t *)data); >   break; >   default: >   error = ENOTTY; > --- sys/spigenio.h.orig 2018-12-22 00:48:50.752200000 +0900 > +++ sys/spigenio.h 2018-12-30 23:58:00.000000000 +0900 > @@ -52,5 +52,7 @@ struct spigen_transfer_mmapped { >  #define SPIGENIOC_SET_CLOCK_SPEED  _IOW(SPIGENIOC_BASE, 3, uint32_t) >  #define SPIGENIOC_GET_SPI_MODE     _IOR(SPIGENIOC_BASE, 4, uint32_t) >  #define SPIGENIOC_SET_SPI_MODE     _IOW(SPIGENIOC_BASE, 5, uint32_t) > +#define SPIGENIOC_SBE              _IOW(SPIGENIOC_BASE, 6, uint32_t) > +#define SPIGENIOC_SBPOL            _IOW(SPIGENIOC_BASE, 7, uint32_t) >   >  #endif /* !_SYS_SPIGENIO_H_ */ > > -- I've been working with SPI devices for years, and I don't think I've ever heard of this SBE and SBPOL stuff. Can you point me to a standards document or something else that describes it? -- Ian From owner-freebsd-arm@freebsd.org Sun Dec 30 23:10:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB0181438AE1 for ; Sun, 30 Dec 2018 23:10:18 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mfdf018.ocn.ad.jp (mfdf018.ocn.ad.jp [153.128.50.74]) by mx1.freebsd.org (Postfix) with ESMTP id 88C2A71D6D for ; Sun, 30 Dec 2018 23:10:17 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mogw1929.ocn.ad.jp (mogw1929.ocn.ad.jp [153.138.215.95]) by mfdf018.ocn.ad.jp (Postfix) with ESMTP id B3441B8B37A for ; Mon, 31 Dec 2018 08:10:09 +0900 (JST) Received: from mf-smf-ucb026c3 (mf-smf-ucb026c3.ocn.ad.jp [153.153.66.168]) by mogw1929.ocn.ad.jp (Postfix) with ESMTP id B1E26203B5; Mon, 31 Dec 2018 08:09:56 +0900 (JST) Received: from ocn-vc-mts-101c1.ocn.ad.jp ([153.153.66.78]) by mf-smf-ucb026c3 with ESMTP id dk4PgHkbKqJizdkDUgJPDK; Mon, 31 Dec 2018 08:09:56 +0900 Received: from smtp.ocn.ne.jp ([153.149.227.165]) by ocn-vc-mts-101c1.ocn.ad.jp with ESMTP id dkDUggJCEEH5BdkDUgjXc1; Mon, 31 Dec 2018 08:09:56 +0900 Received: from localhost (p571097-ipngn200409sizuokaden.shizuoka.ocn.ne.jp [180.33.36.97]) by smtp.ocn.ne.jp (Postfix) with ESMTPA; Mon, 31 Dec 2018 08:09:56 +0900 (JST) Date: Mon, 31 Dec 2018 08:09:53 +0900 (JST) Message-Id: <20181231.080953.1864031625387192599.toshi@ruby.ocn.ne.jp> To: freebsd-arm@freebsd.org Subject: Re: SPI start bit (9 bit) for BBB From: SAITOU Toshihide Received-SPF: pass (mf-ofc-ucb058: domain designate client-ip as permitted sender) client-ip=153.138.215.89; envelope-from=; helo=mogw1923.ocn.ad.jp; Received-SPF: pass (mf-ofc-ucb057: domain designate client-ip as permitted sender) client-ip=153.138.214.88; envelope-from=; helo=mogw1822.ocn.ad.jp; In-Reply-To: <1546191759.78877.91.camel@freebsd.org> References: <20181231.003356.1147810385398844555.toshi@ruby.ocn.ne.jp> <1546191759.78877.91.camel@freebsd.org> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 88C2A71D6D X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of toshi@ruby.ocn.ne.jp designates 153.128.50.74 as permitted sender) smtp.mailfrom=toshi@ruby.ocn.ne.jp X-Spamd-Result: default: False [4.26 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:153.128.50.0/24]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.86)[0.862,0]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[ocn.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mfgw1.ocn.ad.jp]; NEURAL_SPAM_LONG(0.95)[0.945,0]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_SHORT(0.43)[0.432,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4713, ipnet:153.128.0.0/11, country:JP]; IP_SCORE(0.73)[ip: (2.19), ipnet: 153.128.0.0/11(2.08), asn: 4713(-0.54), country: JP(-0.09)] 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, 30 Dec 2018 23:10:19 -0000 On Sun, 30 Dec 2018 10:42:39 -0700, Ian Lepore wrote:= > On Mon, 2018-12-31 at 00:33 +0900, SAITOU Toshihide wrote: >> In 3-line serial protcol, there is a type using additional 1-bit to >> specify command or data.=A0=A0The BBB can handle this, so I can use = with >> the following patch (unskillful and maybe side effects exist).=A0=A0= I >> hope this will attract someones interest to implement this and also >> SPI frequency and mode. >> = >> = >> --- arm/ti/ti_spi.c.orig 2018-12-22 00:47:12.096034000 +0900 >> +++ arm/ti/ti_spi.c 2018-12-30 23:58:00.000000000 +0900 >> @@ -493,6 +493,7 @@ ti_spi_transfer(device_t dev, device_t child, >> struct s >> =A0 /* Disable the FIFO. */ >> =A0 TI_SPI_WRITE(sc, MCSPI_XFERLEVEL, 0); >> =A0 >> +#if 0 >> =A0 /* 8 bits word, d0 miso, d1 mosi, mode 0 and CS active low. >> */ >> =A0 reg =3D TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); >> =A0 reg &=3D ~(MCSPI_CONF_FFER | MCSPI_CONF_FFEW | >> MCSPI_CONF_SBPOL | >> @@ -501,6 +502,7 @@ ti_spi_transfer(device_t dev, device_t child, >> struct s >> =A0 =A0=A0=A0=A0MCSPI_CONF_DMAW | MCSPI_CONF_EPOL); >> =A0 reg |=3D MCSPI_CONF_DPE0 | MCSPI_CONF_EPOL | >> MCSPI_CONF_WL8BITS; >> =A0 TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); >> +#endif >> =A0 >> =A0#if 0 >> =A0 /* Enable channel interrupts. */ >> @@ -558,6 +560,70 @@ ti_spi_get_node(device_t bus, device_t dev) >> =A0 return (ofw_bus_get_node(bus)); >> =A0} >> =A0 >> +static int >> +ti_spi_sbe(device_t dev, device_t child, uint32_t *request) >> +{ >> + struct ti_spi_softc *sc; >> + uint32_t reg; >> + >> + sc =3D device_get_softc(dev); >> + >> + TI_SPI_LOCK(sc); >> + >> + /* If the controller is in use wait until it is available. >> */ >> + while (sc->sc_flags & TI_SPI_BUSY) >> + mtx_sleep(dev, &sc->sc_mtx, 0, "ti_spi", 0); >> + >> + /* Now we have control over SPI controller. */ >> + sc->sc_flags =3D TI_SPI_BUSY; >> + >> + reg =3D TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); >> + if (*request) >> + reg |=3D MCSPI_CONF_SBE; >> + else >> + reg &=3D ~MCSPI_CONF_SBE; >> + TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); >> + >> + /* Release the controller and wakeup the next thread waiting >> for it. */ >> + sc->sc_flags =3D 0; >> + wakeup_one(dev); >> + TI_SPI_UNLOCK(sc); >> + >> + return (0); >> +} >> + >> +static int >> +ti_spi_sbpol(device_t dev, device_t child, uint32_t *request) >> +{ >> + struct ti_spi_softc *sc; >> + uint32_t reg; >> + >> + sc =3D device_get_softc(dev); >> + >> + TI_SPI_LOCK(sc); >> + >> + /* If the controller is in use wait until it is available. >> */ >> + while (sc->sc_flags & TI_SPI_BUSY) >> + mtx_sleep(dev, &sc->sc_mtx, 0, "ti_spi", 0); >> + >> + /* Now we have control over SPI controller. */ >> + sc->sc_flags =3D TI_SPI_BUSY; >> + >> + reg =3D TI_SPI_READ(sc, MCSPI_CONF_CH(sc->sc_cs)); >> + if (*request) >> + reg |=3D MCSPI_CONF_SBPOL; >> + else >> + reg &=3D ~MCSPI_CONF_SBPOL; >> + TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); >> + >> + /* Release the controller and wakeup the next thread waiting >> for it. */ >> + sc->sc_flags =3D 0; >> + wakeup_one(dev); >> + TI_SPI_UNLOCK(sc); >> + >> + return (0); >> +} >> + >> =A0static device_method_t ti_spi_methods[] =3D { >> =A0 /* Device interface */ >> =A0 DEVMETHOD(device_probe, ti_spi_probe), >> @@ -569,6 +635,10 @@ static device_method_t ti_spi_methods[] =3D { >> =A0 >> =A0 /* ofw_bus interface */ >> =A0 DEVMETHOD(ofw_bus_get_node, ti_spi_get_node), >> + >> + /* provisional chip register interface for SBE and SBPOL */ >> + DEVMETHOD(spibus_sbe, ti_spi_sbe), >> + DEVMETHOD(spibus_sbpol, ti_spi_sbpol), >> =A0 >> =A0 DEVMETHOD_END >> =A0}; >> --- dev/spibus/spibus.c.orig 2018-12-29 23:50:40.262296000 >> +0900 >> +++ dev/spibus/spibus.c 2018-12-30 23:58:00.000000000 +0900 >> @@ -226,6 +226,18 @@ spibus_transfer_impl(device_t dev, device_t >> child, str >> =A0 return (SPIBUS_TRANSFER(device_get_parent(dev), child, >> cmd)); >> =A0} >> =A0 >> +static int >> +spibus_sbe_impl(device_t dev, device_t child, uint32_t *request) >> +{ >> + return (SPIBUS_SBE(device_get_parent(dev), child, request)); >> +} >> + >> +static int >> +spibus_sbpol_impl(device_t dev, device_t child, uint32_t *request) >> +{ >> + return (SPIBUS_SBPOL(device_get_parent(dev), child, >> request)); >> +} >> + >> =A0static device_method_t spibus_methods[] =3D { >> =A0 /* Device interface */ >> =A0 DEVMETHOD(device_probe, spibus_probe), >> @@ -247,6 +259,9 @@ static device_method_t spibus_methods[] =3D { >> =A0 >> =A0 /* spibus interface */ >> =A0 DEVMETHOD(spibus_transfer, spibus_transfer_impl), >> + >> + DEVMETHOD(spibus_sbe, spibus_sbe_impl), >> + DEVMETHOD(spibus_sbpol, spibus_sbpol_impl), >> =A0 >> =A0 DEVMETHOD_END >> =A0}; >> --- dev/spibus/spibus_if.m.orig 2018-12-22 00:49:22.440211000 >> +0900 >> +++ dev/spibus/spibus_if.m 2018-12-30 23:58:00.000000000 +0900 >> @@ -39,3 +39,15 @@ METHOD int transfer { >> =A0 device_t child; >> =A0 struct spi_command *cmd; >> =A0}; >> + >> +METHOD int sbe { >> + device_t dev; >> + device_t child; >> + uint32_t *request; >> +}; >> + >> +METHOD int sbpol { >> + device_t dev; >> + device_t child; >> + uint32_t *request; >> +}; >> --- dev/spibus/spigen.c.orig 2018-12-29 20:19:20.584696000 >> +0900 >> +++ dev/spibus/spigen.c 2018-12-30 23:58:00.000000000 +0900 >> @@ -248,6 +248,28 @@ spigen_transfer_mmapped(struct cdev *cdev, >> struct spig >> =A0} >> =A0 >> =A0static int >> +spigen_sbe(struct cdev *cdev, uint32_t *request) >> +{ >> + device_t dev =3D cdev->si_drv1; >> + int error =3D 0; >> + >> + error =3D SPIBUS_SBE(device_get_parent(dev), dev, (uint32_t >> *)request); >> + >> + return (error); >> +} >> + >> +static int >> +spigen_sbpol(struct cdev *cdev, uint32_t *request) >> +{ >> + device_t dev =3D cdev->si_drv1; >> + int error =3D 0; >> + >> + error =3D SPIBUS_SBPOL(device_get_parent(dev), dev, (uint32_t >> *)request); >> + >> + return (error); >> +} >> + >> +static int >> =A0spigen_ioctl(struct cdev *cdev, u_long cmd, caddr_t data, int ffl= ag, >> =A0=A0=A0=A0=A0struct thread *td) >> =A0{ >> @@ -272,6 +294,12 @@ spigen_ioctl(struct cdev *cdev, u_long cmd, >> caddr_t da >> =A0 break; >> =A0 case SPIGENIOC_SET_SPI_MODE: >> =A0 error =3D spibus_set_mode(dev, *(uint32_t *)data); >> + break; >> + case SPIGENIOC_SBE: >> + error =3D spigen_sbe(cdev, (uint32_t *)data); >> + break; >> + case SPIGENIOC_SBPOL: >> + error =3D spigen_sbpol(cdev, (uint32_t *)data); >> =A0 break; >> =A0 default: >> =A0 error =3D ENOTTY; >> --- sys/spigenio.h.orig 2018-12-22 00:48:50.752200000 +0900 >> +++ sys/spigenio.h 2018-12-30 23:58:00.000000000 +0900 >> @@ -52,5 +52,7 @@ struct spigen_transfer_mmapped { >> =A0#define SPIGENIOC_SET_CLOCK_SPEED=A0=A0_IOW(SPIGENIOC_BASE, 3, ui= nt32_t) >> =A0#define SPIGENIOC_GET_SPI_MODE=A0=A0=A0=A0=A0_IOR(SPIGENIOC_BASE,= 4, uint32_t) >> =A0#define SPIGENIOC_SET_SPI_MODE=A0=A0=A0=A0=A0_IOW(SPIGENIOC_BASE,= 5, uint32_t) >> +#define SPIGENIOC_SBE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0_IOW= (SPIGENIOC_BASE, 6, uint32_t) >> +#define SPIGENIOC_SBPOL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0_IOW(SPI= GENIOC_BASE, 7, uint32_t) >> =A0 >> =A0#endif /* !_SYS_SPIGENIO_H_ */ >> = >> -- > = > I've been working with SPI devices for years, and I don't think I've > ever heard of this SBE and SBPOL stuff. Can you point me to a standar= ds > document or something else that describes it? > = > -- Ian Sure, here it is. Fig. 9.3.1, p. 30, https://www.crystalfontz.com/controllers/Sitroni= x/ST7735/ When the start bit is enabled, one extra clock is added, request =3D 1; ioctl(lcd->spi_fd, SPIGENIOC_SBE, &request); and the data porarity is controled by the start bit porarity. ioctl(h->spi_fd, SPIGENIOC_SBPOL, &request); By this patch, BeagleBone Mini Display Cape is usable. https://www.logicsupply.com/999-0004100/ -- SAITOU Toshihide From owner-freebsd-arm@freebsd.org Mon Dec 31 00:38:57 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01B09143B88A for ; Mon, 31 Dec 2018 00:38:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 EA35275563 for ; Mon, 31 Dec 2018 00:38:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5ER293AVM1nYvxUVQp1SOJ2JY9oTqoEra0yamggZlr6CsuilPTlX3gomiy4MtUd Ai16CS9aKKe0y63Eu0yMAi4HgptjfXkUHxkx2xwotBJ81PkM35hsMX9WRbffkFH4wHX1XxgEkUVy qphqY1NniQt2sG0lE4VBG3wIFVVX._j9tv0B8bIQ7HX33PEnpqIi8kSSB8FCP6Duvw06QfkcPX90 j64kjbA60H1vx1oC2lPTu2XHILSDr6s0a9n1W8K_scpf7BNmSdgFPM4SZJ4Yl2X6iKguTX6i0qWX V6A0Mh8wfahwP7DA3eC1wXPmfPSmiEKfOdkk5ckpPaZJ30Qfgim9N9LHJt3IvmBx3cBiRara_7Ba LlxTiMTN.rrDZyXRzz.UgRMsG53XDvoGRKN1CITGni.GPFoKzPz25zK4zO_NUGDRIjcHgIlDyRXX GXK0e4HAKVM_.uHb50YfbZKmDp.I_vE.445lN16zMku9FkQ35gnzDUzJ5NemPhKjIxWtPSBCWwce ZKrErVCcrwLRwkoIcCnI.NG2eroXWJtwa9hsr_MgEhU2E7ue.wC5kg.pAddj5lA47_.DWtsaH0gk 6RGrWwsPmPvn_7_k7wSXy8P.8hJJkdhSHL9AjhNPjxd2iSWSN8H1tvTAGxGnpcNVxlgA6A8dwRW7 PWaVhGv6lAaNXGU_xxC68g2rvDZASL1M7mePK4xVOTtmycZflzCTJbWGQAaNvC2KqZCZ61rr2fdv U4w6kMiNrSMIf_6npPOMwv85gLKWY9yQelxlBs8lAq_9whoYozrqceWpsvzxW8crmcC_IyhQpPB6 XC_WL0uznyX9_8tEP_Y8WK7TGykFbWPbwoC0Pk8gI2gOCXFCn9Y7G2obXG1zw9J.sljgCfdmQH_u 4pf6A7HIm_gMJPM4TojLBoWqcYhGN4BOtK6wERh2944zfcQerFxrp5HZEAcF2z8m25LgZ4vqtlb9 3NIV9Ki8UcyKekwfOkzNGdVbnzHmC1_RROrbOrsTsPsLnwhQI_060DFpqseYJaYNkOlH50Dezy1x Q1HKf093xalJFKBw45_dU_i3.dOKz.iUlJ4HDvgTtUHA0PkZWyKz0TulI.U9OtjLxiQ0op.A- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Mon, 31 Dec 2018 00:38:49 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 57b6b0495726289929d5de26bdecfcdf; Mon, 31 Dec 2018 00:38:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem] From: Mark Millard In-Reply-To: <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> Date: Sun, 30 Dec 2018 16:38:42 -0800 Cc: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: EA35275563 X-Spamd-Bar: / X-Spamd-Result: default: False [0.94 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.31)[-0.307,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.46)[0.457,0]; NEURAL_HAM_LONG(-0.11)[-0.108,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.41)[ip: (4.36), ipnet: 74.6.128.0/21(1.54), asn: 26101(1.23), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[35.128.6.74.list.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: Mon, 31 Dec 2018 00:38:57 -0000 On 2018-Dec-28, at 12:12, Mark Millard wrote: > On 2018-Dec-28, at 05:13, Michal Meloun = wrote: >=20 >> Mark, >> this is known problem with qemu-user-static. >> Emulation of every single interruptible syscall is broken by design = (it >> have signal related races). Theses races cannot be solved without = major >> rewrite of syscall emulation code. >> Unfortunately, nobody actively works on this, I think. >>=20 >=20 > Thanks for the note setting some expectations. > . . . It turns out that I've been through (part of?) this before and mikael.urankar@gmail.com had back then provided a qemu-user-static patch (that might have been arm specific or 32-bit target specific when running on a 64-bit host). (The qemu-user-static code structure seems to have changed some afterwards and the patch is no longer where he had pointed me to back then.) To show size and offsets on armv7 vs. armd64 for struct kevent I use: # more kevent_size_offsets.c=20 #include "/usr/include/sys/event.h" // kevent #include // offsetof #include // printf int main() { printf("%lu\n", (unsigned long) sizeof(struct kevent)); printf("ident %lu\n", (unsigned long) offsetof(struct kevent, = ident)); printf("filter %lu\n", (unsigned long) offsetof(struct kevent, = filter)); printf("flags %lu\n", (unsigned long) offsetof(struct kevent, = flags)); printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, = fflags)); printf("data %lu\n", (unsigned long) offsetof(struct kevent, = data)); printf("udata %lu\n", (unsigned long) offsetof(struct kevent, = udata)); printf("ext %lu\n", (unsigned long) offsetof(struct kevent, = ext)); return 0; } It ends up showing on armv7 (under qemu-arm-static insteead of native, = not that it matters here): # ./a.out 64 ident 0 filter 4 flags 6 fflags 8 data 16 udata 24 ext 32 On amd64 (native) it ends up as: # ./a.out 64 ident 0 filter 8 flags 10 fflags 12 data 16 udata 24 ext 32 Thus a translation of layout is required when hosted. This is for: struct kevent { __uintptr_t ident; /* identifier for this event */ short filter; /* filter for event */ unsigned short flags; /* action flags for kqueue */ unsigned int fflags; /* filter flag value */ __int64_t data; /* filter data value */ void *udata; /* opaque user data identifier = */ __uint64_t ext[4]; /* extensions */ }; But qemu-user-static has for translation purposes: struct target_freebsd_kevent { abi_ulong ident; int16_t filter; uint16_t flags; uint32_t fflags; int64_t data; abi_ulong udata; uint64_t ext[4]; } __packed; (note the __packed) for which in amd64's qemu_arm_static has the size and offsets: # gdb qemu-arm-static . . . (gdb) p/d sizeof(struct target_freebsd_kevent) $1 =3D 56 (gdb) p/d &((struct target_freebsd_kevent *)0)->ident $2 =3D 0 (gdb) p/d &((struct target_freebsd_kevent *)0)->filter $3 =3D 4 (gdb) p/d &((struct target_freebsd_kevent *)0)->flags $4 =3D 6 (gdb) p/d &((struct target_freebsd_kevent *)0)->fflags $5 =3D 8 (gdb) p/d &((struct target_freebsd_kevent *)0)->data $6 =3D 12 (gdb) p/d &((struct target_freebsd_kevent *)0)->udata $7 =3D 20 (gdb) p/d &((struct target_freebsd_kevent *)0)->ext $8 =3D 24 which which does not match the armv7 offsets for data, udata, or ext and does not have the right size for struct target_freebsd_kevent[] indexing to match armv7's struct target_freebsd_kevent[] indexing. This in turn makes the do_freebsd_kevent code do the wrong thing in its: struct target_freebsd_kevent *target_changelist, *target_eventlist; . . . for (i =3D 0; i < arg3; i++) { __get_user(changelist[i].ident, = &target_changelist[i].ident); __get_user(changelist[i].filter, = &target_changelist[i].filter); __get_user(changelist[i].flags, = &target_changelist[i].flags); __get_user(changelist[i].fflags, = &target_changelist[i].fflags); __get_user(changelist[i].data, &target_changelist[i].data); /* __get_user(changelist[i].udata, = &target_changelist[i].udata); */ #if TARGET_ABI_BITS =3D=3D 32 changelist[i].udata =3D (void = *)(uintptr_t)target_changelist[i].udata; tswap32s((uint32_t *)&changelist[i].udata); #else changelist[i].udata =3D (void = *)(uintptr_t)target_changelist[i].udata; tswap64s((uint64_t *)&changelist[i].udata); #endif __get_user(changelist[i].ext[0], = &target_changelist[i].ext[0]); __get_user(changelist[i].ext[1], = &target_changelist[i].ext[1]); __get_user(changelist[i].ext[2], = &target_changelist[i].ext[2]); __get_user(changelist[i].ext[3], = &target_changelist[i].ext[3]); } . . . for (i =3D 0; i < arg5; i++) { __put_user(eventlist[i].ident, &target_eventlist[i].ident); __put_user(eventlist[i].filter, = &target_eventlist[i].filter); __put_user(eventlist[i].flags, &target_eventlist[i].flags); __put_user(eventlist[i].fflags, = &target_eventlist[i].fflags); __put_user(eventlist[i].data, &target_eventlist[i].data); /* __put_user(eventlist[i].udata, = &target_eventlist[i].udata);*/ #if TARGET_ABI_BITS =3D=3D 32 tswap32s((uint32_t *)&eventlist[i].data); target_eventlist[i].data =3D (uintptr_t)eventlist[i].data; #else tswap64s((uint64_t *)&eventlist[i].data); target_eventlist[i].data =3D (uintptr_t)eventlist[i].data; #endif __put_user(eventlist[i].ext[0], = &target_eventlist[i].ext[0]); __put_user(eventlist[i].ext[1], = &target_eventlist[i].ext[1]); __put_user(eventlist[i].ext[2], = &target_eventlist[i].ext[2]); __put_user(eventlist[i].ext[3], = &target_eventlist[i].ext[3]); } I'll eventually do something to have struct target_freebsd_kevent for amd64-native targeting armv7 and see if that is sufficient to avoid the problem in my context. Previously removing the __packed was enough to make the structure the same size with the same offsets as for armv7. (Such might not have been appropriate to all targets.) armv6 would have the same problem as I understand things. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Dec 31 01:26:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A7C1143D20D for ; Mon, 31 Dec 2018 01:26:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 8862D77033 for ; Mon, 31 Dec 2018 01:26:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GCCA8DAVM1kUKxhiZC8K8BRc3IuZ3yLJKqIXG.4_x_.P8EH8M7AagoQvnyA5vTG 5AvuN8stcgjNaxL9Z1HIvS79Yf0mnvF8yWwGNK9H6I22rLXQr2cvQYUyBzb2NHeyKzEhNkF.I7gf AT1gqwO8UQnMy.f1xseIx2lRfJkWnUWBs_paoelClh02aNIc3k9EY0r_VbabEIO7CzEcCfYCRP2l Ixws9HIw2mjF6Se.Hx2WqSXUaVb8E6RvQ6e3q6dhZ1C_C4hXbjVCu6pTCPL0X1EaVq39iWMvt5Ax fGIfgOZjZoGrc._pWtdtDh2v5bncKvsKRtrb1Zvy3tIq22USMlsBVWA_e_PuStLvnJ.sqae.XQ7V zh9MCPnhpvnoyqnQYpnfaBk4kx9zMU5VYMu.gvvJdGrrH6R0D4EmwDuSe_uW3dT4ol0q1qXdSlA0 vPO0WFE_pPYCyvY8K6Zi7G.L2Be3AwqPdu.1a2dQgCLmUrl79701SNNnSXakEW6ZGknARz9bIpos .9Y0n6yjA5L8Rbc7MyTr2bH8ZlaUS64_Ruwxr6gSZMEaKI1lCnDt5Foc0uckzQ3nFNU9ZyZ.JShv pPjfq1vTyBQgQOX9VT_fivUoIzeKMEnE_ssLiLtNCaaYkaaHePGd_qB.JH2.cNhlaYTDFsTkJICT gYph1la6EJ3H3Vw_9_rzr3HlZ42tPP_nx9F1TY0cjjsCAchArofoNlvGR20iSDJmqw8W2NnxWySG SLqtcoRlD0r3zTxeysQF1Bg5Es0fgnHdnK7oBJ7IXrIWGIaDxqIPAIBE1MEaPqhKG9sFwUkCBQS3 OZ7FyYGxbEcgBTBjTawK2zxNK6povtllziHMruDNUD1dMfjSV.Iq5KerMx5N8_XQUkDW1EOdWS2t RzOFeJTi8LzkH8K7ZkzZTrWjnlcBicPFnD2P0StLY_u9yUzHwyEDWTiKqYGc1BtGUVicKersZZCP Zz2TZD3eMQmwUktY5oQf9gnEPj37V6KQZEbhPWjXdMik47gtXxU5JGLD._BtPwN_I0UR8uHwgWn8 LjRqP9RCh_FovgCix9YUfMf6RTes7Jg0TnRGkTO_tc7YFQeWCt4mSY1UNWd_g9Lj2BiImZLE0VMg - Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Mon, 31 Dec 2018 01:26:08 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp403.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 04ffb892c2e4a018446db2706dc31fd2; Mon, 31 Dec 2018 01:26:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem] From: Mark Millard In-Reply-To: Date: Sun, 30 Dec 2018 17:26:01 -0800 Cc: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 8862D77033 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.10)[-0.098,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.90)[0.904,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.58)[ip: (5.23), ipnet: 74.6.128.0/21(1.54), asn: 26101(1.23), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.13)[0.125,0]; RCVD_IN_DNSWL_NONE(0.00)[124.132.6.74.list.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: Mon, 31 Dec 2018 01:26:16 -0000 [Removing __packed did make the size and offsets match armv7 and the build worked based on the reconstructed qemu-arm-static.] On 2018-Dec-30, at 16:38, Mark Millard wrote: > On 2018-Dec-28, at 12:12, Mark Millard wrote: >=20 >> On 2018-Dec-28, at 05:13, Michal Meloun = wrote: >>=20 >>> Mark, >>> this is known problem with qemu-user-static. >>> Emulation of every single interruptible syscall is broken by design = (it >>> have signal related races). Theses races cannot be solved without = major >>> rewrite of syscall emulation code. >>> Unfortunately, nobody actively works on this, I think. >>>=20 >>=20 >> Thanks for the note setting some expectations. >> . . . >=20 >=20 > It turns out that I've been through (part of?) this before and > mikael.urankar@gmail.com had back then provided a qemu-user-static > patch (that might have been arm specific or 32-bit target specific > when running on a 64-bit host). (The qemu-user-static code structure > seems to have changed some afterwards and the patch is no longer > where he had pointed me to back then.) >=20 > To show size and offsets on armv7 vs. armd64 for struct kevent > I use: >=20 > # more kevent_size_offsets.c=20 > #include "/usr/include/sys/event.h" // kevent > #include // offsetof > #include // printf >=20 > int > main() > { > printf("%lu\n", (unsigned long) sizeof(struct kevent)); > printf("ident %lu\n", (unsigned long) offsetof(struct kevent, = ident)); > printf("filter %lu\n", (unsigned long) offsetof(struct kevent, = filter)); > printf("flags %lu\n", (unsigned long) offsetof(struct kevent, = flags)); > printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, = fflags)); > printf("data %lu\n", (unsigned long) offsetof(struct kevent, = data)); > printf("udata %lu\n", (unsigned long) offsetof(struct kevent, = udata)); > printf("ext %lu\n", (unsigned long) offsetof(struct kevent, = ext)); > return 0; > } >=20 > It ends up showing on armv7 (under qemu-arm-static insteead of native, = not > that it matters here): >=20 > # ./a.out > 64 > ident 0 > filter 4 > flags 6 > fflags 8 > data 16 > udata 24 > ext 32 >=20 > On amd64 (native) it ends up as: >=20 > # ./a.out > 64 > ident 0 > filter 8 > flags 10 > fflags 12 > data 16 > udata 24 > ext 32 >=20 > Thus a translation of layout is required when hosted. This is for: >=20 > struct kevent { > __uintptr_t ident; /* identifier for this event */ > short filter; /* filter for event */ > unsigned short flags; /* action flags for kqueue */ > unsigned int fflags; /* filter flag value */ > __int64_t data; /* filter data value */ > void *udata; /* opaque user data identifier = */ > __uint64_t ext[4]; /* extensions */ > }; >=20 > But qemu-user-static has for translation purposes: >=20 > struct target_freebsd_kevent { > abi_ulong ident; > int16_t filter; > uint16_t flags; > uint32_t fflags; > int64_t data; > abi_ulong udata; > uint64_t ext[4]; > } __packed; >=20 > (note the __packed) for which in amd64's qemu_arm_static has > the size and offsets: >=20 > # gdb qemu-arm-static > . . . > (gdb) p/d sizeof(struct target_freebsd_kevent) > $1 =3D 56 > (gdb) p/d &((struct target_freebsd_kevent *)0)->ident > $2 =3D 0 > (gdb) p/d &((struct target_freebsd_kevent *)0)->filter > $3 =3D 4 > (gdb) p/d &((struct target_freebsd_kevent *)0)->flags > $4 =3D 6 > (gdb) p/d &((struct target_freebsd_kevent *)0)->fflags > $5 =3D 8 > (gdb) p/d &((struct target_freebsd_kevent *)0)->data > $6 =3D 12 > (gdb) p/d &((struct target_freebsd_kevent *)0)->udata > $7 =3D 20 > (gdb) p/d &((struct target_freebsd_kevent *)0)->ext > $8 =3D 24 >=20 > which which does not match the armv7 offsets for > data, udata, or ext and does not have the right size > for struct target_freebsd_kevent[] indexing to > match armv7's struct target_freebsd_kevent[] indexing. >=20 > This in turn makes the do_freebsd_kevent code do the wrong > thing in its: >=20 > struct target_freebsd_kevent *target_changelist, *target_eventlist; > . . . > for (i =3D 0; i < arg3; i++) { > __get_user(changelist[i].ident, = &target_changelist[i].ident); > __get_user(changelist[i].filter, = &target_changelist[i].filter); > __get_user(changelist[i].flags, = &target_changelist[i].flags); > __get_user(changelist[i].fflags, = &target_changelist[i].fflags); > __get_user(changelist[i].data, &target_changelist[i].data); > /* __get_user(changelist[i].udata, = &target_changelist[i].udata); */ > #if TARGET_ABI_BITS =3D=3D 32 > changelist[i].udata =3D (void = *)(uintptr_t)target_changelist[i].udata; > tswap32s((uint32_t *)&changelist[i].udata); > #else > changelist[i].udata =3D (void = *)(uintptr_t)target_changelist[i].udata; > tswap64s((uint64_t *)&changelist[i].udata); > #endif > __get_user(changelist[i].ext[0], = &target_changelist[i].ext[0]); > __get_user(changelist[i].ext[1], = &target_changelist[i].ext[1]); > __get_user(changelist[i].ext[2], = &target_changelist[i].ext[2]); > __get_user(changelist[i].ext[3], = &target_changelist[i].ext[3]); > } > . . . > for (i =3D 0; i < arg5; i++) { > __put_user(eventlist[i].ident, &target_eventlist[i].ident); > __put_user(eventlist[i].filter, = &target_eventlist[i].filter); > __put_user(eventlist[i].flags, &target_eventlist[i].flags); > __put_user(eventlist[i].fflags, = &target_eventlist[i].fflags); > __put_user(eventlist[i].data, &target_eventlist[i].data); > /* __put_user(eventlist[i].udata, = &target_eventlist[i].udata);*/ > #if TARGET_ABI_BITS =3D=3D 32 > tswap32s((uint32_t *)&eventlist[i].data); > target_eventlist[i].data =3D (uintptr_t)eventlist[i].data; > #else > tswap64s((uint64_t *)&eventlist[i].data); > target_eventlist[i].data =3D (uintptr_t)eventlist[i].data; > #endif > __put_user(eventlist[i].ext[0], = &target_eventlist[i].ext[0]); > __put_user(eventlist[i].ext[1], = &target_eventlist[i].ext[1]); > __put_user(eventlist[i].ext[2], = &target_eventlist[i].ext[2]); > __put_user(eventlist[i].ext[3], = &target_eventlist[i].ext[3]); > } >=20 >=20 >=20 > I'll eventually do something to have struct target_freebsd_kevent for > amd64-native targeting armv7 and see if that is sufficient to avoid = the > problem in my context. Previously removing the __packed was enough to > make the structure the same size with the same offsets as for armv7. > (Such might not have been appropriate to all targets.) >=20 > armv6 would have the same problem as I understand things. Using commented out __packed in: struct target_freebsd11_kevent { abi_ulong ident; int16_t filter; uint16_t flags; uint32_t fflags; abi_long data; abi_ulong udata; } ; // __packed; struct target_freebsd_kevent { abi_ulong ident; int16_t filter; uint16_t flags; uint32_t fflags; int64_t data; abi_ulong udata; uint64_t ext[4]; } ; // __packed; in = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall_defs.h was sufficient to allow the multimedia/gstreamer1-qt@qt5 build to = complete: no more hang-up. So this is likely what is wrong for the packages-builders as well. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Dec 31 03:16:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBE22141E91B for ; Mon, 31 Dec 2018 03:16:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 394AD83B95 for ; Mon, 31 Dec 2018 03:16:38 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1546226192; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=rCaQmpnBE6QkhWfd1RNM9hHLQZdPLdvfPBtIvSnoorA+VROYNFBdKWTvdYupq4QEz3H3AVxw/9Ums GAfqHON5tMAd0NdBqmj9KuREp4xboMxmzqzWpRhLFlMp6bTXnP8YVyoW7ddSZARzijgmwYSg5FWS5p t75Al6zAcPfrMp2UfwWSMQ17X70cShRCZZ3R0uBfZU9fy5IV6dHXnc3adJXvbo5fZ1B5t+hvLmHyMg wv3vF/V7YSRBM+7FLDpDKLBIUqZIcy/Z9GSLZSL3eVlAUSKRMVNIAGjubzg2dnmnWP1U55+hCeM8Ga B4jgXvVhueX+HhR58J+jyCP8jKWJ/NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=mime-version:content-type:references:in-reply-to:date:to:from:subject: message-id:dkim-signature:from; bh=9ksv/gO/3MlNiULA2z8nd9MuALu4r8ER3V3orvXyucI=; b=cPFm4Qg20mSoZpvPDih/RU0mxlDq3xuTpIn5pX6RxVRVq6fpWSU9u84SL90w9StQ/EudxVY1CsIKE WenUacN9El7e1CPZNlmNZnXLSWwcLuwQliLtTjy8Qi4P3YtSTYy1AU6roHEt63LGRZO4Xlr4gQQKwi kcfilEcnfpS7yl+IJ/vdaT4BgntusE87ak+rRIYylt+W+FHvfvzd+56edNIJ4tgG3UGxdtADWeaObX ncSmBdPZlXL5fNcmXk06q7BbLRsUQDzL83jnba3SExtffIUSPAli4zyVq5cofYFencgtZoOHUepX8U pCfGMmkruPtf/Ob7QXJMtMrxwhOhI2A== ARC-Authentication-Results: i=1; outbound2.eu.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=mime-version:content-type:references:in-reply-to:date:to:from:subject: message-id:from; bh=9ksv/gO/3MlNiULA2z8nd9MuALu4r8ER3V3orvXyucI=; b=Pk7u3geyqKSpyu3GJQG2SOW2MJp5gngznHozgCuRbIBYK4z0/7X/oWsYCrSSB2DuTFCFiB1mpAzdm p9qklWCLstmy4UAR0SJIdu6fMo8DzCb0alJtFBOcRo08decACBi20E81R583aHxsp/hjmdor+Hv53b OP4KdS7U0Zjt5PnWx/d+zX62iCQgcuvkaaZL7GwQWOdHfhPKH5hZiQoSK9fMpTrFqKrR4ngZzdk5aK Oov0YsM89dGyJTBkxLVyipEEeoLQBHMRBUSio4NxnAFe0lFS3HCPRLj7E/0381FNfAblFTFBmsUkQZ FthM8JgqPKWz696oAxh8FMtrkIecAUA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 759bf020-0caa-11e9-a887-bd2f23b465e5 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 outbound2.eu.mailhop.org (Halon) with ESMTPSA id 759bf020-0caa-11e9-a887-bd2f23b465e5; Mon, 31 Dec 2018 03:16:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBV3GQDx030107; Sun, 30 Dec 2018 20:16:26 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1546226186.78877.97.camel@freebsd.org> Subject: Re: SPI start bit (9 bit) for BBB From: Ian Lepore To: SAITOU Toshihide , freebsd-arm@freebsd.org Date: Sun, 30 Dec 2018 20:16:26 -0700 In-Reply-To: <20181231.003356.1147810385398844555.toshi@ruby.ocn.ne.jp> References: <20181231.003356.1147810385398844555.toshi@ruby.ocn.ne.jp> Content-Type: multipart/mixed; boundary="=-Gjgpods0HzOcfsYoXlP1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-Rspamd-Queue-Id: 394AD83B95 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:52.58.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: Mon, 31 Dec 2018 03:16:40 -0000 --=-Gjgpods0HzOcfsYoXlP1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Mon, 2018-12-31 at 00:33 +0900, SAITOU Toshihide wrote: > In 3-line serial protcol, there is a type using additional 1-bit to > specify command or data.  The BBB can handle this, so I can use with > the following patch (unskillful and maybe side effects exist).  I > hope this will attract someones interest to implement this and also > SPI frequency and mode. > Since you are already set up for testing spi on BBB, could you please try the attached patch for handling bus speed and mode? If it works I'll get it committed. -- Ian --=-Gjgpods0HzOcfsYoXlP1 Content-Disposition: inline; filename="ti_spi_mode_freq.diff" Content-Type: text/x-patch; name="ti_spi_mode_freq.diff"; charset="ASCII" Content-Transfer-Encoding: 7bit Index: sys/arm/ti/ti_spi.c =================================================================== --- sys/arm/ti/ti_spi.c (revision 341650) +++ sys/arm/ti/ti_spi.c (working copy) @@ -446,7 +446,7 @@ ti_spi_transfer(device_t dev, device_t child, stru { int err; struct ti_spi_softc *sc; - uint32_t reg, cs; + uint32_t clockhz, cs, mode, reg; sc = device_get_softc(dev); @@ -457,6 +457,8 @@ ti_spi_transfer(device_t dev, device_t child, stru /* Get the proper chip select for this child. */ spibus_get_cs(child, &cs); + spibus_get_clock(child, &clockhz); + spibus_get_mode(child, &mode); cs &= ~SPIBUS_CS_HIGH; @@ -466,6 +468,13 @@ ti_spi_transfer(device_t dev, device_t child, stru return (EINVAL); } + if (mode > 3) + { + device_printf(dev, "Invalid mode %d requested by %s\n", mode, + device_get_nameunit(child)); + return (EINVAL); + } + TI_SPI_LOCK(sc); /* If the controller is in use wait until it is available. */ @@ -487,8 +496,8 @@ ti_spi_transfer(device_t dev, device_t child, stru /* Disable FIFO for now. */ sc->sc_fifolvl = 1; - /* Use a safe clock - 500kHz. */ - ti_spi_set_clock(sc, sc->sc_cs, 500000); + /* Set the bus frequency. */ + ti_spi_set_clock(sc, sc->sc_cs, clockhz); /* Disable the FIFO. */ TI_SPI_WRITE(sc, MCSPI_XFERLEVEL, 0); @@ -500,6 +509,7 @@ ti_spi_transfer(device_t dev, device_t child, stru MCSPI_CONF_DPE1 | MCSPI_CONF_DPE0 | MCSPI_CONF_DMAR | MCSPI_CONF_DMAW | MCSPI_CONF_EPOL); reg |= MCSPI_CONF_DPE0 | MCSPI_CONF_EPOL | MCSPI_CONF_WL8BITS; + reg |= mode; /* POL and PHA are the low bits, we can just OR-in mode */ TI_SPI_WRITE(sc, MCSPI_CONF_CH(sc->sc_cs), reg); #if 0 --=-Gjgpods0HzOcfsYoXlP1-- From owner-freebsd-arm@freebsd.org Mon Dec 31 05:01:27 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95F4E1421CAD for ; Mon, 31 Dec 2018 05:01:27 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6403E870B5 for ; Mon, 31 Dec 2018 05:01:25 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-ua1-x943.google.com with SMTP id e16so8388202uam.12 for ; Sun, 30 Dec 2018 21:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QFPFb9gWPIEkXrgIwZErCATYwfa5hjOLLmWTWs7MFh8=; b=XwfRu4l07HKkDgYJMTBNHWd4xdPiktOFg5uaO/uaFQDDAz97yjgsxnZdV6g12Pe3Sj EdiFSZo20vxTScii9v9WjxKnDYAIdztrB+eW/nwLfyauJhOr9/BRT9Pp7iB25mplFb5R glFehgS5T3yyTmxXqAnJATIor3hCOTsqd8haEby93UGsGYxYML7Fs/9uNy9zXoxKReoe f/UqmEeUmv4+iv5WYFEHocb49UthVmbdBhjU/UFD0b/0S7cbWLGZZ5RpCdEDEiUfsexP pztzvElMfFI+iI9NywXtzz0xjRHy+xDb3drdyBeBFkjju5ePndbM7cMeScDse6fLjsTF xwmw== 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=QFPFb9gWPIEkXrgIwZErCATYwfa5hjOLLmWTWs7MFh8=; b=YkTps/fN8aFI60q4+9XHwG12HmYWe9KHBvcSKoI8CixqUI7SRF8MHW9X2VusygH/fY pFhrv7Oke6x+9y4zz8uMBaFbb0xI1ZWYEBVdra5kYsaBiPwmeGOZxlhxHngkidWNwPSc DPTyJhegLIOQ+uZNNRWPNNkJ1qlSGbvD9cHKxW2nvceGuowU7LBytmndwxYaTRFpZPiR 7vKKTX3sWD8LIHqMA5ewuCsSwgtwJHHtJT0Ku3Qh9FVl5T2HoAQdq2XR68d5zjf4+UCf gIrnUsk1SCKg1SDS2qO79G8gHJORCNjIyUJ1ajcyhsiDuv+4uywcTtgy5me3KzIpGeEq PV8A== X-Gm-Message-State: AJcUukdg/wIH+ifdSd5Yz/k2nvdvohGYvt1iYLN9hE7S7uDvG7mzeAiS 63VcVX6vBj+jbx+ThLv40SlOLlXDS7BLgZuqK1SYCg== X-Google-Smtp-Source: ALg8bN4J8U9fsaGZYK/bh16OjkRonekxzqt8NmRA+IHsb83EmbS/YLQ83Dp+gRCgqwKwaNqAFpnblxe3aGzb65QIQAc= X-Received: by 2002:ab0:73c4:: with SMTP id m4mr13774871uaq.101.1546232484418; Sun, 30 Dec 2018 21:01:24 -0800 (PST) MIME-Version: 1.0 References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> In-Reply-To: From: Jonathan Chen Date: Mon, 31 Dec 2018 18:01:13 +1300 Message-ID: Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem] To: Mark Millard Cc: mmel@freebsd.org, freebsd-emulation@freebsd.org, FreeBSD Current , freebsd-arm , ports-list freebsd , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 6403E870B5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=XwfRu4l0 X-Spamd-Result: default: False [0.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.916,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.959,0]; IP_SCORE(0.05)[ip: (3.78), ipnet: 2607:f8b0::/32(-1.91), asn: 15169(-1.55), country: US(-0.08)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[chen.org.nz]; NEURAL_HAM_LONG(-0.81)[-0.811,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[3.4.9.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)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUSPICIOUS_RECIPS(1.50)[] 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, 31 Dec 2018 05:01:27 -0000 On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports wrote: > > [Removing __packed did make the size and offsets match armv7 > and the build worked based on the reconstructed qemu-arm-static.] Thanks for the analysis Mark! I've been suffering quite a few hangups with my ports crossbuilds on amd64->armv7 on 12-STABLE, and I'll be trying your suggestions to see whether it resolves the issue. Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Mon Dec 31 08:05:47 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08BBE142AD5B for ; Mon, 31 Dec 2018 08:05:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.ne1.yahoo.com (sonic309-20.consmr.mail.ne1.yahoo.com [66.163.184.146]) (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 3486C8F004 for ; Mon, 31 Dec 2018 08:05:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oyA5EscVM1mqNZkxzVcgwUqOKvV_U3MMD3PfEZxE_7AieulH4igtebPJaoW6pk8 hK1ONZrFGv8Fx0ncA0cuBJWacJMWD1G7hV0Y0AqB1C2fAD4ztXhFj7ocFQsK9Ne6WEpIFgyExWdW KmCzFjIoUcrt0bGjBCftAzAyOXlkNlseptznyyiodskp2aVZDpVIR2bCswSmxCK_yMEvhYqMkIJP D9jQs4KXG2W756WJvaDhMAPwb.ekLf2XxUEPYUq2TTJL0TzgVULeXcPPwpPu8Piiofi5FcdV90vS 0P2hDfePQJJPjAV0FsSZSKpFGozNPw0GjZggko7PRs8Y3wM7IOdZAu_Vt6Bh0B0pv6moKi9f4Nfq eDdq8QE6iNl1kyhqjZOylUhTXpqjXvzqcUZ63KiZs1ruVFKNDtFcRFyPGjIVl.eK3vpdGQYiP5_q rLf4hq0k6zDPDSOdkXAhZIv53AJpWWcgKWwQiDgrPDvRp7EcSRCL3GWE5a..dGHkXxk0bCXxhbMr aV3Bjj0XOAw4dOxyjYMZ31FU6euUTAblvg8Vhd2ToLDzlQpR3zF3HGnqh9TVW0Jb4nyR7INTSO1g plKKY7L66YOEVkHXPE1ekAe0S0.eahjFXC7Z2va20w_glHUvfDYq6HzqOidIhdK87VVVd3Sdacw_ bnq0vVK46MXBETwCHXHTmCNv.4IqOxtTYRA0ZoPgidpAN0Z1slNo4OHSXAkLKo0IdfxvkQZnXvB_ VGL8c4VFYm.GxUTocR9EiNSNm53GtP9W7p270Nf67NvbjV4iQhU6.QOhmPWtSyvb5iKK8AuZY8k. ZoIm0q3v0iEwLxjR8fxPb.Ebd6UCstE5ZZRk.PVpyLR3CHwjN9eGaU7E2mpJdd.dctz9xHiBwgky E0YLlmYJF0H8jiv63SpL0vg00vTT0I233ZtpMjTvl8yP4NtafXdo0OQK_oOhqPBRfAPAY4WYDnLI SsAJgLEjCP5DTCocGB_VEOx7EL5GmNC4pFbD2zxyiuOSZTnHEPRS37Kqvt0JZAJ6qxnuIXhB1cMP sUEcdez.ZPgMgsrTYQxXkm06kjleBPqrGKoWksaTpySWvZpThuUwLy6H5APtAf3gm4.UoSmAjsoc - Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Mon, 31 Dec 2018 08:05:37 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp417.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9a7d61f623df156aa1a0a58f98273bbf; Mon, 31 Dec 2018 08:05:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem] From: Mark Millard In-Reply-To: Date: Mon, 31 Dec 2018 00:05:31 -0800 Cc: mmel@freebsd.org, freebsd-emulation@freebsd.org, FreeBSD Current , freebsd-arm , ports-list freebsd , FreeBSD Toolchain Content-Transfer-Encoding: 7bit Message-Id: <82478A45-7D15-4995-B333-FC42B39E5345@yahoo.com> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> To: Jonathan Chen X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 3486C8F004 X-Spamd-Bar: + X-Spamd-Result: default: False [1.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_SEVEN(0.00)[7]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.54)[-0.544,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.64)[0.642,0]; NEURAL_HAM_LONG(-0.42)[-0.425,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.08)[ip: (3.39), ipnet: 66.163.184.0/21(1.15), asn: 36646(0.92), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.184.163.66.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[146.184.163.66.rep.mailspike.net : 127.0.0.17]; SUSPICIOUS_RECIPS(1.50)[] 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, 31 Dec 2018 08:05:47 -0000 On 2018-Dec-30, at 21:01, Jonathan Chen wrote: > On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports > wrote: >> >> [Removing __packed did make the size and offsets match armv7 >> and the build worked based on the reconstructed qemu-arm-static.] > > Thanks for the analysis Mark! I've been suffering quite a few hangups > with my ports crossbuilds on amd64->armv7 on 12-STABLE, and I'll be > trying your suggestions to see whether it resolves the issue. If you have something like a kqread state for a hang-up consistently in the same place, then Mikael Urankar 's fix (or any other way of getting the right sizes and field offsets for kevent) has a chance of fixing what you have observed. But if you have a form of hang-up that shows no sign of being tied to kevent or hangs-up only sometimes, I'd be surprised if the __packed change(s) would fix the issue. I've seen such racy hang-ups from lld's creation of (#cpu)+2 threads, as FreeBSD counts cpus. I've selectively forced -Wl,--no-threads at times in specific contexts to avoid that. binutils ld does not tolerate the option. ports does not appear to have an equivalent of: LDFLAGS.lld+= -Wl,--no-threads that would be lld specific. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Dec 31 11:52:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 674241430ADA for ; Mon, 31 Dec 2018 11:52:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::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.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0073D960B8 for ; Mon, 31 Dec 2018 11:52:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2C80917F9D for ; Mon, 31 Dec 2018 11:52:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id wBVBqNlM010934 for ; Mon, 31 Dec 2018 11:52:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id wBVBqNv9010933 for freebsd-arm@FreeBSD.org; Mon, 31 Dec 2018 11:52:23 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 234525] buildworld clang fails on Raspberry Pi 3b+ Date: Mon, 31 Dec 2018 11:52:23 +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: taxman637@gmail.com 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 attachments.created 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, 31 Dec 2018 11:52:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234525 Bug ID: 234525 Summary: buildworld clang fails on Raspberry Pi 3b+ Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: taxman637@gmail.com Created attachment 200648 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D200648&action= =3Dedit backtrace Sorry, I'm not a programmer, but I hope this might be helpful FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r342541 GENERIC arm64 I enabled a large swap on a usb hard drive, used subversion to get the late= st -current, and attempted to buildworld. I got a segfault in cc. Here's the backtrace and I'll attach the two reques= ted files: #0 LookupBucketFor () at /usr/src/contrib/llvm/lib/Support/StringMap.cpp:79 #1 0x0000000003aeaa30 in try_emplace () at /usr/src/contrib/llvm/include/llvm/ADT/StringMap.h:396 #2 0x0000000003aeabac in insert () at /usr/src/contrib/llvm/include/llvm/ADT/StringMap.h:387 #3 addOption () at /usr/src/contrib/llvm/lib/Support/CommandLine.cpp:151 #4 0x0000000003ae1c00 in addOption () at /usr/src/contrib/llvm/lib/Support/CommandLine.cpp:194 #5 addArgument () at /usr/src/contrib/llvm/lib/Support/CommandLine.cpp:357 #6 0x000000000305207c in _GLOBAL__sub_I_CorrelatedValuePropagation.cpp () at /usr/src/contrib/llvm/include/llvm/Support/CommandLine.h:1342 #7 0x00000000011d01a0 in handle_static_init (argc=3D139, argv=3D0xffffffff= cab8, env=3D0xffffffffcf18) at /usr/src/lib/csu/common/ignore_init.c:124 #8 0x00000000011d00a8 in __start (argc=3D139, argv=3D0xffffffffcab8, env=3D0xffffffffcf18, cleanup=3D) at /usr/src/lib/csu/aarch64/crt1.c:83 #9 0x00000000011d0000 in ?? () Backtrace stopped: not enough registers or memory available to unwind furth= er (gdb) quit --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Dec 31 12:47:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBECB1432769 for ; Mon, 31 Dec 2018 12:47:53 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mfdf022.ocn.ad.jp (mfdf022.ocn.ad.jp [153.128.50.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7406268173; Mon, 31 Dec 2018 12:47:52 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mogw2025.ocn.ad.jp (mogw2025.ocn.ad.jp [61.118.33.27]) by mfdf022.ocn.ad.jp (Postfix) with ESMTP id DA24A203666; Mon, 31 Dec 2018 21:47:43 +0900 (JST) Received: from mf-smf-unw004c3 (mf-smf-unw004c3.ocn.ad.jp [153.138.219.77]) by mogw2025.ocn.ad.jp (Postfix) with ESMTP id 63AEB440413; Mon, 31 Dec 2018 21:47:30 +0900 (JST) Received: from ocn-vc-mts-102c1.ocn.ad.jp ([153.153.66.81]) by mf-smf-unw004c3 with ESMTP id dwuKgug5EvEVfdwyggHSTm; Mon, 31 Dec 2018 21:47:30 +0900 Received: from smtp.ocn.ne.jp ([153.149.227.167]) by ocn-vc-mts-102c1.ocn.ad.jp with ESMTP id dwyggUTSM8o4xdwyggZrCG; Mon, 31 Dec 2018 21:47:30 +0900 Received: from localhost (p571097-ipngn200409sizuokaden.shizuoka.ocn.ne.jp [180.33.36.97]) by smtp.ocn.ne.jp (Postfix) with ESMTPA; Mon, 31 Dec 2018 21:47:30 +0900 (JST) Date: Mon, 31 Dec 2018 21:47:25 +0900 (JST) Message-Id: <20181231.214725.1482321641373486643.toshi@ruby.ocn.ne.jp> To: ian@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: SPI start bit (9 bit) for BBB From: SAITOU Toshihide In-Reply-To: <1546226186.78877.97.camel@freebsd.org> References: <20181231.003356.1147810385398844555.toshi@ruby.ocn.ne.jp> <1546226186.78877.97.camel@freebsd.org> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7406268173 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of toshi@ruby.ocn.ne.jp designates 153.128.50.80 as permitted sender) smtp.mailfrom=toshi@ruby.ocn.ne.jp X-Spamd-Result: default: False [4.89 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:153.128.50.0/24]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[ocn.ne.jp]; NEURAL_SPAM_MEDIUM(0.96)[0.955,0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.78)[0.784,0]; MX_GOOD(-0.01)[cached: mfgw1.ocn.ad.jp]; RCPT_COUNT_TWO(0.00)[2]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_LONG(0.99)[0.985,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4713, ipnet:153.128.0.0/11, country:JP]; IP_SCORE(0.87)[ip: (2.92), ipnet: 153.128.0.0/11(2.08), asn: 4713(-0.55), country: JP(-0.09)] 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, 31 Dec 2018 12:47:54 -0000 On Sun, 30 Dec 2018 20:16:26 -0700, Ian Lepore = wrote: > On Mon, 2018-12-31 at 00:33 +0900, SAITOU Toshihide wrote: >> In 3-line serial protcol, there is a type using additional 1-bit to >> specify command or data.=A0=A0The BBB can handle this, so I can use = >> with >> the following patch (unskillful and maybe side effects exist).=A0=A0= I >> hope this will attract someones interest to implement this and also >> SPI frequency and mode. >> > > Since you are already set up for testing spi on BBB, could you = > please > try the attached patch for handling bus speed and mode? If it works > I'll get it committed. > > -- Ian I confirm that the spi(8) command is functional on BBB now. spi -f spigen0.0 -s 1000000 -m 0 I wish that the start bit enable and polarity will be implemented in = the same way. -- SAITOU Toshihide From owner-freebsd-arm@freebsd.org Mon Dec 31 18:17:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59571143BD24 for ; Mon, 31 Dec 2018 18:17:05 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B60A676933 for ; Mon, 31 Dec 2018 18:17:02 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-vs1-xe42.google.com with SMTP id h78so16809599vsi.6 for ; Mon, 31 Dec 2018 10:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oA8R8OTMVP5nqZ/84IF8NfoX9sHi/7YO4Ow7mg9WvCc=; b=jnCS1RJP+l9efv1+10mxdhoEMORIUXqbYExoOXbHJu+Wk6K2A7E619csAmTbGAUWiX hPDNQgsBfnTIoeJg2W/0xmiH9Bzl7dPdCgtYvd6DDWqLMT8yDLo5sMVplJB2+RmkvnH5 1pcKhfJrQb0houBCQiRwU1hEM8TeMkJI0DWPvNCLIMcxLAmkaSB/Rxijma1ZUicyWC+p /CycYBu4AzK7sc2oXpyAk4oxQiVYvqrM/r70AtCZJA1qYYNHQBCsOIdmBPzesCnatE+F WM0IiWeGSHackIKhVtgMy3FrODMevsZrxSVml+3tMcgr1cjDSufevcaT8mG6ghJrL81t qXng== 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=oA8R8OTMVP5nqZ/84IF8NfoX9sHi/7YO4Ow7mg9WvCc=; b=jQUNBvMBU5R7T3/DK2Qgupr0iR2/3D0BRocZd7QZUy9aFJF8LDO2SOv5AcmGXoB3R7 +XKwKbbMPJ4Fa7OujaJE3jjTVCFwvG0+jz1u3v6VWfrXieyij7O7H1y0WOhjLd3kfA64 h+V+9ZurixGtG2zoGUvcl+20UtU/A8nhPA7keKL4rI4HPg051YrP4Qy2iS3dk3PEC9U1 3TZoI4RBIieV6rkSGDYRcwHrczHoSmHYlck00hAOzSawsHYHUupiKsqts+2G3/Lyo1G/ EpjkuxpIYSAAFQerTSq7WjRSnS7FJCbAHKDLf1b4n3murVnk6fGhK2DAx/9TMDCZldq9 yUrA== X-Gm-Message-State: AA+aEWaZMHEyuZODNjyKGJqpcYNoyk132VYi5LwZmrdNeHMaoxb0v+G1 I60v3Opd2dROAgbC9TGH7Kft+1gxQhKH90B5lQQUgPV681Q= X-Google-Smtp-Source: AFSGD/WamyiZqPddZL65QVX3WFI7IxrVHjb44abOfNyRGwpfDS/3I8ZAXuthlo+BCwyrKz/KzHrqfqNF5k9lgT+qJpA= X-Received: by 2002:a67:5bdc:: with SMTP id w89mr15553112vsg.109.1546280221720; Mon, 31 Dec 2018 10:17:01 -0800 (PST) MIME-Version: 1.0 References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> <82478A45-7D15-4995-B333-FC42B39E5345@yahoo.com> In-Reply-To: <82478A45-7D15-4995-B333-FC42B39E5345@yahoo.com> From: Jonathan Chen Date: Tue, 1 Jan 2019 07:16:40 +1300 Message-ID: Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem] To: Mark Millard Cc: mmel@freebsd.org, freebsd-emulation@freebsd.org, FreeBSD Current , freebsd-arm , ports-list freebsd , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B60A676933 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=jnCS1RJP X-Spamd-Result: default: False [0.42 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.80)[-0.796,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.56)[0.561,0]; IP_SCORE(0.12)[ip: (4.22), ipnet: 2607:f8b0::/32(-1.95), asn: 15169(-1.56), country: US(-0.08)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[chen.org.nz]; NEURAL_HAM_LONG(-0.66)[-0.661,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[2.4.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]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUSPICIOUS_RECIPS(1.50)[] 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, 31 Dec 2018 18:17:05 -0000 On Mon, 31 Dec 2018 at 21:05, Mark Millard wrote: [...] > But if you have a form of hang-up that shows no sign of being tied > to kevent or hangs-up only sometimes, I'd be surprised if the __packed > change(s) would fix the issue. With the __packed-modified qemu-user-static, the amd64->armv7 crossbuilds does not hang anymore, but I get build failures instead. Interestingly enough, an unmodified qemu-user-static gets further along in a amd64->armv6 crossbuild, with only one reproducible hang. Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Mon Dec 31 20:05:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6ECB143E89A for ; Mon, 31 Dec 2018 20:05:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.ne1.yahoo.com (sonic310-22.consmr.mail.ne1.yahoo.com [66.163.186.203]) (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 2F84B82F50 for ; Mon, 31 Dec 2018 20:05:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: UQN7FI0VM1n5nZk3WR3voHWoQkVFc6BC1vW._8LcwBAopbwO7AHVzxG7qmOPrlx u50CR1tA3.WxwmDlKbwNj8g8eYbLA4i8GBr2XryOSXBXnkHqCyf7wR..dwylwJosA8HBa8z9xNDk l5a7x3z.bV17_Ej_JvXYfE0Mo7jL_cOhTJzIlzNHi6xRUffUJdSAZCRLmBEWGWwIlvI7G22Ud.Ta D7HveKucFNnU7jtBYndMvV6b5BAh9aRJ.RlMm18pzIxflRK0pBA1a9olyHtbtRGJv7lXtnRTr60q 0FdzRc6Em3k_Qgoy3q.WEa1pxqav4MpLlaiTi0Tjbjg_6Bie.3qvw46S7Uv2.baDUmJgXYEhcnuK CUYHQpVZSzZkovyYweOeM47ig8Hj1qK8_HPkcufNw_.ADmUqk0E6_v.BtPX_GWrMPJqfNoVG8rID G9e4gh6SCTaZiQRxOwSOZs3Jow5lMbx1w4F0MS3R1zexC0O.FnurA7ey2GL4MxJnVLRUimGkWUJc AzNip8NuCDI4X8EOq6rfHsX9qDta_ZpiElLGPMROOrtM8SybWX6k9mzFaPX5.0.VxFITauYev82o 25wWdSe0iaIwl.eYGb0Ik7GH4qTefPVzuYmsWDsiSTdS4movVJz2XaTAbjVtuYN2pZvhg_MGGevb EcjeejGw.VhCRi69NPw3ADGA33XGbsoHeDyZXo.eiTcM1WPMBSOHtkne8kqijQbadAKhOOJVbqK0 kmVzK9fPFTKDH4pkMRQUleVMk_mVSDQlVLY4qc1efmZTPDTquHdJiC_tQMtsDqpuhEs46acJR5T4 txwRCOVOntd13W42m.2PwnHMq_nBea.440oPOkGeapy1tPXkUJje0hHqesXDCd3PSmQhLVe5oypm uCGoXH82YZnQD1_QWmEpHiGkf3Ayx_yfaBN9kN_DFaumSZOkDKilGebtSBVUzbOMwZP_1cIcg9jJ bA.df6KbWuB8F1p0.bP.FAzSarQjsYPBZMkYyGoKNAk2POecB5ZvKqYqGPqbLhuOGJYt1qh0xSbS mCKsJ0AujfgArFk5N6KAnPv2Z69tLoKudQpOmBUJgxASb77WfuQ6RsbXhYe.4t2WUCs8w Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Mon, 31 Dec 2018 20:05:43 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0742405770bc6c0a367a982b1de2352c; Mon, 31 Dec 2018 20:05:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem] From: Mark Millard In-Reply-To: Date: Mon, 31 Dec 2018 12:05:37 -0800 Cc: freebsd-emulation@freebsd.org, FreeBSD Current , freebsd-arm , ports-list freebsd , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <984303F3-ADCD-442A-B1E9-412B8365B399@yahoo.com> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> <82478A45-7D15-4995-B333-FC42B39E5345@yahoo.com> To: Jonathan Chen X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 2F84B82F50 X-Spamd-Bar: / X-Spamd-Result: default: False [0.55 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.50)[-0.495,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.84)[0.844,0]; NEURAL_HAM_LONG(-0.40)[-0.397,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.11)[ip: (3.58), ipnet: 66.163.184.0/21(1.13), asn: 36646(0.91), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[203.186.163.66.list.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: Mon, 31 Dec 2018 20:05:53 -0000 On 2018-Dec-31, at 10:16, Jonathan Chen wrote: > On Mon, 31 Dec 2018 at 21:05, Mark Millard = wrote: > [...] >> But if you have a form of hang-up that shows no sign of being tied >> to kevent or hangs-up only sometimes, I'd be surprised if the = __packed >> change(s) would fix the issue. >=20 > With the __packed-modified qemu-user-static, the amd64->armv7 > crossbuilds does not hang anymore, but I get build failures instead. > Interestingly enough, an unmodified qemu-user-static gets further > along in a amd64->armv6 crossbuild, with only one reproducible hang. I tend to compare cross-build failures to native-build attempts. The multimedia-gstreamer1-qt@qt5 hang-up was qemu-arm-static specific, not occurring native. That and being reliable about hanging-up is what prompted the investigation. The lld thread fanout hangup also has only happened under qemu-arm-static but I do not have a context with more than 4 cores for armv7: far less than 28 (FreeBSD under Hyper-V) or 32 cpus (FreeBSD native) that I use for cross-builds. I do not know if you care to but it is possible to see if the FreeBSD package builders get failures or hangs for the same ports. I use head port build examples below: http://beefy16.nyi.freebsd.org/jail.html?mastername=3Dhead-armv7-default http://beefy8.nyi.freebsd.org/jail.html?mastername=3Dhead-armv6-default The pages displayed show a list of port version (p??????) and freebsd version (s??????) looking like p??????_s?????? . Those links take you to pages for exploring the built, failed, skipped, and ignored ports. Of course, for race-condition problems in builds, checking is messier because of needing to look at possibly many port/system combinations. My attempts to build x11/lumina fail for: [00:01:02] [01] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2 [00:02:23] [01] [00:01:21] Saved multimedia/libvpx | libvpx-1.7.0_2 = wrkdir to: = /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/libvpx= -1.7.0_2.tar [00:02:23] [01] [00:01:21] Finished multimedia/libvpx | libvpx-1.7.0_2: = Failed: build [00:02:24] [01] [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: = Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-libav | = gstreamer1-libav-1.14.4_2: Dependent port multimedia/libvpx | = libvpx-1.7.0_2 failed [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-plugins-core | = gstreamer1-plugins-core-1.14: Dependent port multimedia/libvpx | = libvpx-1.7.0_2 failed [00:02:24] [01] [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: = Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed [00:02:24] [01] [00:01:22] Skipping x11/lumina-core | lumina-core-1.4.1: = Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed . . . [00:06:19] Failed ports: multimedia/libvpx:build [00:06:19] Skipped ports: multimedia/ffmpeg multimedia/gstreamer1-libav = multimedia/gstreamer1-plugins-core x11/lumina x11/lumina-core [FBSDFSSDjailArmV7-default] [2018-12-30_17h04m02s] [committing:] Queued: = 7 Built: 1 Failed: 1 Skipped: 5 Ignored: 0 Tobuild: 0 Time: = 00:06:16 Native build attempts on an armv7 get the same. But I'm still at: # svnlite info | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 341836 Last Changed Rev: 341836 because I froze at that while investigating the reliable hang and have not started progressing again yet. Last I looked the head-armv7-default package builds were also failing for libvpx if I remember right. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jan 1 03:00:40 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEC1E14245B4 for ; Tue, 1 Jan 2019 03:00:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 2926068546 for ; Tue, 1 Jan 2019 03:00:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Wz_.scgVM1khe5KePqMyFXlkE6GTgublMfEO44SQCg.lgOj5KMs4VaCw7ajcmPi k_BdqefUXyaEiRGRe6GlzEHe6_IluIhSfsBiLsGgx1kSjbRjnUyaNFgV6qnHlf54d9vwGDLemX0G g7eGRlQadi2HOBwKHDivodc8Bb3G_hqa92WVpfuOHjL.DyVmH9PqGT6tSpdwhzhOk03G6pZVm8fs 535tE7AEviK.nB8wA5oGsgxEhrfmAiLXhSwbtJQkXRmvYY_f5Vikc__ecd5vmLlLJaLLyUJWx5go TlhvcFZrZDi89jMgpDX.3n.6rbT7M8pW1ICXlIYVd8VqyaOArzaoWpiAxkzMEF0p2WCLH_YL3rlg Kl4CkQkM9.dnCjvRNW5y8xEDRHDiiAkPbqOo1kBJ5K.HA8u0r4Ah1xMr9DRLSSXKOIXl7obqSXlV DlhDb.KnHnn_pSAtN0HO1FdU18rE3jPivtF51VPq9hSdLyzIkwZtpUOyfW.RDR69l3QHewiWuTcW oB.4Av.0BCGvLlI.k9OWyEKA7KwO5blugxNqzT1zj5OT3Qf0xM1fT88Z1lOEvKw8XAY8BsiWD0sB PUU9_c2b.Zy0jS4_GSJYhP8riDn488Xh9EdGp4.5bdJP1XZRUJ.Y6jslg23wYSB5ecgq1qCbw107 ks3_G5DeU3IyGroq5XnZQWoq3zb2HAEPNDtUb2oBIqCKWY61RwDzjvN.NYVxhG.JbMIEnQZekzAU EhF0d5lq7cagsXNxnpYOK2gLpqAD.uSj_eHzh_kcMqph_e3zsg3hW6Ld8QVFkrE7an_zp.HvNptf XyMS6MgzJ5RQ5MG4FZ1X1qMTmIs2Rw1GJd5cQabQQlFERRlC1Ix8kzNBeeow2EFzBayE4lZ6uktl KVic4.m8t4_vWYSCPSXAo3ftBDHiHd8VRc3MHnHiyVLLSwvb8_k9p0yHt6KR3.DGxp3w7wmjZhRj LEZTclDGa1fwp0G1T1shZuKidWjhKC6sDEsTRdjLoH2VDSHDDozOiU28Xm012.iWg.mfKgU_iF7t msW7W6o67K88YhjIWmiRIulHWzYUbVaOBj4dYEDfLDnasL0JR1jOL1_MECXGoGZqqSg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Jan 2019 03:00:38 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dbd0bb2a6a724229abedbad683618265; Tue, 01 Jan 2019 02:50:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem] From: Mark Millard In-Reply-To: <984303F3-ADCD-442A-B1E9-412B8365B399@yahoo.com> Date: Mon, 31 Dec 2018 18:50:23 -0800 Cc: freebsd-emulation@freebsd.org, FreeBSD Current , freebsd-arm , ports-list freebsd , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <642A3C38-5229-4BA3-9BA7-CD78F52D0335@yahoo.com> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> <82478A45-7D15-4995-B333-FC42B39E5345@yahoo.com> <984303F3-ADCD-442A-B1E9-412B8365B399@yahoo.com> To: Jonathan Chen X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 2926068546 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.71 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.23)[ip: (-7.15), ipnet: 98.137.64.0/21(0.61), asn: 36647(0.49), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.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: Tue, 01 Jan 2019 03:00:40 -0000 [I listed my /usr/src svn veriosn information instead of /usr/ports . Correcting. . .] On 2018-Dec-31, at 12:05, Mark Millard wrote: > On 2018-Dec-31, at 10:16, Jonathan Chen wrote: >=20 >> On Mon, 31 Dec 2018 at 21:05, Mark Millard = wrote: >> [...] >>> But if you have a form of hang-up that shows no sign of being tied >>> to kevent or hangs-up only sometimes, I'd be surprised if the = __packed >>> change(s) would fix the issue. >>=20 >> With the __packed-modified qemu-user-static, the amd64->armv7 >> crossbuilds does not hang anymore, but I get build failures instead. >> Interestingly enough, an unmodified qemu-user-static gets further >> along in a amd64->armv6 crossbuild, with only one reproducible hang. >=20 > I tend to compare cross-build failures to native-build attempts. The > multimedia-gstreamer1-qt@qt5 hang-up was qemu-arm-static specific, > not occurring native. That and being reliable about hanging-up is > what prompted the investigation. >=20 > The lld thread fanout hangup also has only happened under > qemu-arm-static but I do not have a context with more than 4 cores for > armv7: far less than 28 (FreeBSD under Hyper-V) or 32 cpus (FreeBSD > native) that I use for cross-builds. >=20 > I do not know if you care to but it is possible to see if the FreeBSD > package builders get failures or hangs for the same ports. I use > head port build examples below: >=20 > http://beefy16.nyi.freebsd.org/jail.html?mastername=3Dhead-armv7-default= >=20 > http://beefy8.nyi.freebsd.org/jail.html?mastername=3Dhead-armv6-default >=20 > The pages displayed show a list of port version (p??????) and freebsd > version (s??????) looking like p??????_s?????? . Those links take you > to pages for exploring the built, failed, skipped, and ignored > ports. >=20 > Of course, for race-condition problems in builds, checking is messier > because of needing to look at possibly many port/system combinations. >=20 > My attempts to build x11/lumina fail for: >=20 > [00:01:02] [01] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2 > [00:02:23] [01] [00:01:21] Saved multimedia/libvpx | libvpx-1.7.0_2 = wrkdir to: = /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/libvpx= -1.7.0_2.tar > [00:02:23] [01] [00:01:21] Finished multimedia/libvpx | = libvpx-1.7.0_2: Failed: build > [00:02:24] [01] [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: = Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed > [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-libav | = gstreamer1-libav-1.14.4_2: Dependent port multimedia/libvpx | = libvpx-1.7.0_2 failed > [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-plugins-core = | gstreamer1-plugins-core-1.14: Dependent port multimedia/libvpx | = libvpx-1.7.0_2 failed > [00:02:24] [01] [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: = Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed > [00:02:24] [01] [00:01:22] Skipping x11/lumina-core | = lumina-core-1.4.1: Dependent port multimedia/libvpx | libvpx-1.7.0_2 = failed > . . . > [00:06:19] Failed ports: multimedia/libvpx:build > [00:06:19] Skipped ports: multimedia/ffmpeg = multimedia/gstreamer1-libav multimedia/gstreamer1-plugins-core = x11/lumina x11/lumina-core > [FBSDFSSDjailArmV7-default] [2018-12-30_17h04m02s] [committing:] = Queued: 7 Built: 1 Failed: 1 Skipped: 5 Ignored: 0 Tobuild: 0 = Time: 00:06:16 >=20 > Native build attempts on an armv7 get the same. >=20 > But I'm still at: >=20 > . . . Correcting to have the /usr/ports information: # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 484783 Last Changed Rev: 484783 >=20 > because I froze at that while investigating the reliable hang and > have not started progressing again yet. Last I looked the > head-armv7-default package builds were also failing for libvpx if > I remember right. Looks like more recently libvpx builds on the package builders. So next = time that I update the ports tree I'll get to see the next problem (if any). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jan 1 09:21:20 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43ECA142DE13 for ; Tue, 1 Jan 2019 09:21:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.146]) (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 1E85C8C2EC for ; Tue, 1 Jan 2019 09:21:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: us7g6xIVM1luKTt3mtoFARttRFd3W1ISbsmHUvfYlXwy25lx_M_gA_UxEb3.GPp lfClwywTtJSTZWvazwKzqYhl8Z7..VinIx66tSXtxC3ZQiyJn9RazAQyLwg95x2N6KiiNa.XGJzm GsznPNqK.ecAvQLmNYHPa_GsyiK4l.icgPCv6WlPbnCajG1X873AagFMTkYtVO6ioKALRtNNGeis 8rWdub4lwakqoLb4odG2YK8dPgW_VOJG3uWwKktEsORCKQev9o5PHNilg8uGCAkLvfCfJN.wybfV lAX2qRqwvCmmh8CDP5ULPnNYAYTLST_IJyBUq1v4tFELwpsT.ngpoU10rHy0vU3WVbkWVMlgmGCV gTHCmUyczRTP0Q1aq3yHQIvdQT12A7IYRlx9rSQm7akR2gqSiEeAFVhVZ8yNBvwJ2YjqrboCoymQ 9Xx9c3NsmrYxa32g7Go9075JcKZTHZ8SKSn1u.3x_6jILQas04_c6jdnPcrdeIDlgsizOZ7o3RoW JUOyXeQo.15LGLbh6lHZ51ZAdw79yeX.RM_n5MnKIJ4Es3ylgKPt5np7910pMy_vX9EmmtCRvClw tnSqKobkAjoGnYj6QaLQxgUQc8g2gyawtIO_2UD54auNl11YXEu1UrCZe2q4cqL0JbtHW7CryM30 yUluOxWAVfFSc2nw_9DYY.BT9oU.LT.rQQdICd22OQF_.S97ejVkyxiyM.BGfaBgzXUeyncpeo9A de72wKu1xJD5A53P10tdZyQXPOQUYGynkUDSXnq2Y_qzWYbp9ABUNHMadRf9C_ulo5LE_z0O57A5 ry3ua8qEydMLB6kH2qK3CAV8IpgwhpngzxrZ8LRnd_lwKIi0p0Sit6UuO.GdRVbQW2vOIHHMsxSV KWwUl2Pd7b0_O6J90orob6eh2Wb2NGP8LEv_l3VmRIWpxP0InaeULz9n1ts6KEfYNy1JGUqAjlLu 2B7lYw.ClhBg1gTIeIuM1SdaUU6XbPCKH79H49VIeenME3lSeCbiDzasdjcrm2A5nxEEiGcz6d1v zAlC4FmIu1GHCLYkezrKKWKc2FlFItpwICrNAGyQ7kRQjgXgcfmAHLpoW7pvWvWClyHO8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Jan 2019 09:21:17 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 884e215aa3804c4159859f2baa479017; Tue, 01 Jan 2019 09:21:14 +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 12.2 \(3445.102.3\)) Subject: How to get multimedia/libvpx to build on a world that was built using WITHOUT_BINUTILS (armv7 example) Message-Id: Date: Tue, 1 Jan 2019 01:21:14 -0800 Cc: freebsd-arm To: ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 1E85C8C2EC X-Spamd-Bar: / X-Spamd-Result: default: False [0.64 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.38)[-0.377,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.90)[0.901,0]; NEURAL_HAM_LONG(-0.36)[-0.365,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.99)[ip: (3.94), ipnet: 98.137.64.0/21(0.60), asn: 36647(0.48), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.65.137.98.list.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: Tue, 01 Jan 2019 09:21:20 -0000 [Note: My armv7 context builds ports with -mcpu=3Dcortex-a7 via a = make.conf like file. The in-use world also was built with -mcpu=3Dcortex-a7 .] In order to avoid the likes of: . . . as -meabi=3D5 --defsym ARCHITECTURE=3D7 -march=3Darmv7-a = -mfloat-abi=3Dhard -mfpu=3Dneon -I./ = -I"/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0"/ -o = vpx_dsp/arm/intrapred_neon_asm.asm.S.o = vpx_dsp/arm/intrapred_neon_asm.asm.S /bin/sh: as: not found gmake[2]: *** [Makefile:199: vpx_dsp/arm/intrapred_neon_asm.asm.S.o] = Error 127 gmake[1]: *** [Makefile:17: .DEFAULT] Error 2 gmake[1]: Leaving directory = '/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0' *** Error code 1 Stop. make: stopped in /usr/ports/multimedia/libvpx . . . in a context where FreeBSD world was built using WITHOUT_BINUTILS=3D and then installed as the context for building ports, I made a change to multimedia/libvpx/Makefile . I used: # svnlite diff /usr/ports/multimedia/libvpx/Makefile=20 Index: /usr/ports/multimedia/libvpx/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/multimedia/libvpx/Makefile (revision 488859) +++ /usr/ports/multimedia/libvpx/Makefile (working copy) @@ -14,7 +14,9 @@ LICENSE_FILE=3D ${WRKSRC}/LICENSE =20 BUILD_DEPENDS=3D nasm:devel/nasm +BUILD_DEPENDS+=3D as:devel/binutils =20 + USE_GITHUB=3D yes GH_ACCOUNT=3D webmproject =20 After which the reattempted build via poudriere-devel got: [00:02:35] [02] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_3 . . . [00:05:49] [02] [00:03:14] Finished multimedia/libvpx | libvpx-1.7.0_3: = Success (That text was actually taken from a amd64->armv7 cross-build = environment output.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jan 1 10:46:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 128831437AA2 for ; Tue, 1 Jan 2019 10:46:06 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F0B88F228 for ; Tue, 1 Jan 2019 10:46:05 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.164] (helo=mjail1.freenet.de) by mout1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1geHYg-00073h-QH for freebsd-arm@freebsd.org; Tue, 01 Jan 2019 11:46:02 +0100 Received: from [::1] (port=36048 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1geHYg-0005O9-P8 for freebsd-arm@freebsd.org; Tue, 01 Jan 2019 11:46:02 +0100 Received: from sub6.freenet.de ([195.4.92.125]:43304) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1geHW5-0003gk-Np for freebsd-arm@freebsd.org; Tue, 01 Jan 2019 11:43:21 +0100 Received: from p4ffc6a69.dip0.t-ipconnect.de ([79.252.106.105]:63855 helo=freebsd-t450.fritz.box) by sub6.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 587) (Exim 4.90_1 #2) id 1geHW5-0007gb-Ku for freebsd-arm@freebsd.org; Tue, 01 Jan 2019 11:43:21 +0100 Date: Tue, 1 Jan 2019 11:43:19 +0100 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-arm@freebsd.org Subject: [BBB] nanobsd boot stuck Message-ID: <20190101104319.GA89465@freebsd-t450.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.11.1 (2018-12-01) X-Originated-At: 79.252.106.105!63855 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, 01 Jan 2019 10:46:06 -0000 Hi, a freshly built nanobsd RELEASE-12.0-p1 for Beaglebone Black does not boot further than the line "Trying to mount root from ufs:/dev/mmcsd0s2a [ro]" I've tried to track this further down and the findings are 1. booting into single user mode works. When I boot into single user mode and exit from there, the BBB continues its boot into multiuser without any further problems. I'm able to login and have all my programs working. 2. setting "set -x" in /etc/rc to extend verbosity. After setting, i can see that the boot stops at line 62 of rc which says: dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` I altered this line to dlv=`/bin/echo "0"` but it still stops at that line. Using the builtin sh-echo instead of the binary one ( dlv=`echo "0"` ) the boot continues until: sh /etc/rc.initdiskless After commenting this whole "diskless" section out, the boot continues by sourcing rc.subr and stops in the function load_rc_config() executing this line: [ -r /etc/defaults/rc.conf ] 3. using different SD-Cards containing the nanobsd image makes no difference. All cards show same behavior described above. 4. regular FreeBSD Image (non-nanobsd) does boot correctly. I do not have a clue how to further debug this. Since the single-user-mode works, it seems to me that the installation as such is not entirely broken, but there is some hickup in the init procedure. Any ideas? Thanks -- Manuel From owner-freebsd-arm@freebsd.org Tue Jan 1 17:36:47 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BA5E1422EC6 for ; Tue, 1 Jan 2019 17:36:47 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4925377471 for ; Tue, 1 Jan 2019 17:36:44 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-vk1-xa34.google.com with SMTP id v70so6185565vkv.7 for ; Tue, 01 Jan 2019 09:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=BYKyafAkV0D9Do1DOtbn/Ihb9/9eox9zqIwwitgFmys=; b=uBzr7yypNJP4v4Feijb/3JU9uIG5TCrsas8UE6wEuHZIbvdZ336i1gcBmKJjBnmHjf D6lbOlmV3fBVaGfBwH0VC2QZ8NaXyE8zYvAO7oxIJBpD7rEhmfz3wQecE1je340qYRXG GO/YM8tO7yvwSYHGel06O49AzslLwype7veChmn74J6EKmtCqlhV3EDeeOuq1n6CjmpN HuSRwp/0UiOhOlISceW0ODaYfLB1w0TCXLzCimKUu792JO4Aag0TkDER5o7LPyYCeL4s +oNDzsYxh1jkKPjy9ImfblaFZjH07Hy5bjmWBVcG2/R3VSnttXpsmU/N+8EAPPNAifCR z4nA== 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=BYKyafAkV0D9Do1DOtbn/Ihb9/9eox9zqIwwitgFmys=; b=HEK804rYXDiOdwhSL4tyi4O61/PPP1hes6pVTOsi9rFROeA7bPxeZWRRsmsWKtra0X 2/zAvCJ+f7nVOnSrhhH3E74nCavTW6KZod4WZGJhg76VTFJJtLUBjRSZJtHxWqRrQCfU ZC/LvP0zdEZiWjIkU9jL1R0jqfDZDKTuo8lLnBNkZMenWbc0PTlAi41RVhgc797BaF9H SUSHQh1JY46X5CHXrMtyiUFBQ8/IxKlNPTjIoysZZZgNNQ+OiGrbkTI8fPjt5Wr/awRw V/JeEF1AAWM8RSFwU+R/O78nlyEPNaWhUg6+vDQpgg8Y+YHPdiRQfZL30uJQLgqyn/vw 2ScQ== X-Gm-Message-State: AJcUukfVeled2hHZxSfo2S2GgJZsSW4EVCyFjpSRq8gXlxRq0iCAAfm1 DTFZcNnBtaMiXZoKryPJC9ozBhvEtZa3IMj5p5mCUl5BbdE= X-Google-Smtp-Source: ALg8bN5FoCvzJ3bXyrd9Ue1IOfCmO9zIDanLYuCOdcBH5SSMeR2nBy0BuqKRfJtMXDAS9tAySy+ZRnmfpC8EC9DlExA= X-Received: by 2002:a1f:95d1:: with SMTP id x200mr14541375vkd.78.1546364203773; Tue, 01 Jan 2019 09:36:43 -0800 (PST) MIME-Version: 1.0 From: Jonathan Chen Date: Wed, 2 Jan 2019 06:36:30 +1300 Message-ID: Subject: What's the difference between armv6 and armv7? To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4925377471 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=uBzr7yyp X-Spamd-Result: default: False [-2.54 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com]; DMARC_NA(0.00)[chen.org.nz]; RCVD_IN_DNSWL_NONE(0.00)[4.3.a.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)[]; NEURAL_HAM_SHORT(-0.50)[-0.503,0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.73)[ipnet: 2607:f8b0::/32(-2.00), asn: 15169(-1.58), country: US(-0.08)] 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, 01 Jan 2019 17:36:47 -0000 Hi, Sorry if this sounds like a simple question, but what is the difference between armv6 and armv7 TARGET_ARCH? I had opportunity to try out both for STABLE-12 the past few days, and the resultant kernel and binaries both work for the RPI2. The file(1) output doesn't appear to offer any distinguishing features either: rpi2:~,6:35am> file /usr/bin/true /usr/bin/true: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200500), FreeBSD-style, stripped Thanks -- Jonathan Chen From owner-freebsd-arm@freebsd.org Tue Jan 1 18:23:52 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4846B1424329; Tue, 1 Jan 2019 18:23:52 +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 7F391808DC; Tue, 1 Jan 2019 18:23:51 +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 x01ILrYA014117 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Jan 2019 10:21:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x01ILrtm014116; Tue, 1 Jan 2019 10:21:53 -0800 (PST) (envelope-from fbsd) Date: Tue, 1 Jan 2019 10:21:53 -0800 From: bob prohaska To: bob prohaska Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: How much memory to compile www/chromium? Message-ID: <20190101182153.GA13944@www.zefox.net> References: <20181212165313.GA84881@www.zefox.net> <20181212184149.ol44fon2unowu35q@squirrel.exwg.net> <20181212192115.GA85583@www.zefox.net> <20181212202504.4n3mhtx7grbeh6j7@squirrel.exwg.net> <20181214012733.GA92808@www.zefox.net> <20181218174903.GA41072@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181218174903.GA41072@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 7F391808DC X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.82 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.91)[0.913,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.97)[0.973,0]; MX_GOOD(-0.01)[cached: www.zefox.net]; NEURAL_SPAM_LONG(0.82)[0.817,0]; IP_SCORE(0.23)[ip: (0.81), ipnet: 50.1.16.0/20(0.40), asn: 7065(0.02), country: US(-0.08)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[] 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, 01 Jan 2019 18:23:52 -0000 On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: > > Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile successfully over > several days. The -DBATCH option was used, in hopes it'd fetch the right options. > Just for fun I added a mechanical hard disk with a 4 GB swap partition and re-ran the www/chromium compilation with MAKE_JOBS_NUMBER_LIMIT unset, to see what happens. OOMA was turned off with vm.pageout_oom_seq="2048" in /boot/loader.conf. After ~11 days the process finished. Log files of gstat output and make output are at http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/mech_sd/ in case anyone's curious. The log files are around 100MB, it seems quickest to download them to look around. Swap use peaked at 3522008 kB. If gstat is to be believed the bottleneck appears to be the mechanical hard disk, which showed near 100% busy when the microSD swap partition was around 15% busy. Apart from a few "indefinite wait..." warnings on the console there was no indication of errors. As a further test, I'ved added two additional USB flash swap devices and am re-running the compilation of www/chromium. The swap layout is quite lopsided, with the USB flash devices having only 2 GB swap partitions on each, contrasting to the 4 GB swap partitions on the microSD card and mechanical disk. The first oddity is that top doesn't seem to see the extra swap space, reporting only 7192M total. Swapinfo does seem to plausibly report swap status as Device 1K-blocks Used Avail Capacity /dev/mmcsd0s2b 4404252 52228 4352024 1% /dev/da0p1 4194304 50848 4143456 1% /dev/da2p5 2097152 28232 2068920 1% /dev/da1f 2097152 28060 2069092 1% Total 12792860 159368 12633492 1% after running overnight. "indefinite wait..." warnings on the console have returned in abundance with the use of USB flash swap, even though swap usage is still less than 200MB. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Jan 1 18:34:19 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 069A51424C00 for ; Tue, 1 Jan 2019 18:34:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 4E6E280FE9 for ; Tue, 1 Jan 2019 18:34:18 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1546367651; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=kCUpOOQoUApXN4hHG2V2l0Q0kBBpuIBnum7M7X9cCyfUWQ+oVAQ8fHMhQdGcznYGh78HgfWlxcbTb 9xTPU99L7KGjQQVZSpVD74pFXQBLK7alTacT/GcWKRwBmofhuLNYp6nTwJ26ufqrpu+3VsxOwABwJv DK1mNgmSjspaUK8aUZLGyapROzL4GLu2xjPb5tpfBlAM680//Jmqd75ySu/Hv6OS9gNVtab4MkJ2aU IDj3/rEp281fTYPF/itaV+C+GiZtS63qUt31P18/se8D7rnf6c+dIZupb2YH2tl2bip729Pa+MVX3K ZRbZ1qsW46wvSiPnUlHmC0H8aZ1Q8NQ== 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:to:from:subject:message-id:dkim-signature:from; bh=v86tWrIOOkoZcZ4wnCYUQsrj4WANhUPf6KhybhvJrYk=; b=ugDVoCOLNW0dgPSc5Q3kmGSydCHuXR5bdFu0cpiapIl8kqSZ9ZByDEnG8rZPvpz03yhI47rH1tHxJ THhHt0iXohP92Cj8Gg9McaqV4wVAYjGPvE/b04UEYFjSU0s3JAjBfe43F+qhMCsPLxE3T+aCtjg30z likxDXedyktHjk0veTL1Ka1HlvNfI7cbexf1PT6ds0hSN7WeLxNyTg43id9QQke0uMPflJhGr0NktA EXbx1T3RbeoPbEEs4Xvs00ijulV0qivqBKQ9RhUXJpjYQdeBfNwyGX1FyubO9Y9jTXeN+JgIOoZCBj Y5nYU9SeyEbn4FWl/0KCSTePI8vB14Q== ARC-Authentication-Results: i=1; outbound2.eu.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:to:from:subject:message-id:from; bh=v86tWrIOOkoZcZ4wnCYUQsrj4WANhUPf6KhybhvJrYk=; b=bnETfi5JopdCPxKbSi9ZDG+I5RGnhy8/IeuM3ClWadvq9d51XFp56GQ/z91bOy902LjcazfR7mhGW /uwzDb7Jo/zxyM50WKgZ8vkUzXE68JjDMIDlCgYMHnlHegNNZle6w/qCH7vfZik8kNljjipFqDQFKk sD93o8yKukeIVHk79bzgO3bGHQc6Gd7uMbFf7P+xorrobXK2yro6pRAltwEW8rD6Ip/IWExBet5hAP w9ZwQU/dzI+XGRVOF03q679dsLO1dtUjRWf/pXpJPWeo11ERh9MtPOlZlBCrWrTV16mvEs+jvvTwaH O3bWZXNdXMEgHCo1JcstHlkhUjTgHdw== X-MHO-RoutePath: aGlwcGll X-MHO-User: d2cd56cb-0df3-11e9-a887-bd2f23b465e5 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 outbound2.eu.mailhop.org (Halon) with ESMTPSA id d2cd56cb-0df3-11e9-a887-bd2f23b465e5; Tue, 01 Jan 2019 18:34:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x01IY7bu034238; Tue, 1 Jan 2019 11:34:07 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1546367647.78877.105.camel@freebsd.org> Subject: Re: What's the difference between armv6 and armv7? From: Ian Lepore To: Jonathan Chen , freebsd-arm@freebsd.org Date: Tue, 01 Jan 2019 11:34:07 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4E6E280FE9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; ASN(0.00)[asn:16509, ipnet:52.58.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: Tue, 01 Jan 2019 18:34:19 -0000 On Wed, 2019-01-02 at 06:36 +1300, Jonathan Chen wrote: > Hi, > > Sorry if this sounds like a simple question, but what is the > difference between armv6 and armv7 TARGET_ARCH? I had opportunity to > try out both for STABLE-12 the past few days, and the resultant > kernel > and binaries both work for the RPI2. The file(1) output doesn't > appear > to offer any distinguishing features either: > > rpi2:~,6:35am> file /usr/bin/true > /usr/bin/true: ELF 32-bit LSB executable, ARM, EABI5 version 1 > (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for > FreeBSD 12.0 (1200500), FreeBSD-style, stripped > > Thanks For a long time, freebsd made no distinction between armv6 and v7 and everything worked pretty well. The few places where the minor differences between v6 and v7 mattered were in the kernel, and it detected the hardware type at runtime and coped. Pretending that v6 and v7 were the same caused problems mainly for ports, which  sometimes compile differently for v6 and v7 (they use #ifdef). Running a v6 kernel and world on v7 hardware may mostly work, depending on which ports/pkgs you use, but that's really an accident. The only real armv6 systems that freebsd supports are the original rpi and rpi-b (the ones with the single-core processor). Everything else is v7 for 32-bit or v8 for 64-bit. Your rpi-2, being multi-core, definitely needs to be running v7. To see the difference in a binary, use "readelf -A" and look for Tag_CPU_arch in the output. (I guess file(1) should be taught to find those tags and report the file type with more detail.) -- Ian From owner-freebsd-arm@freebsd.org Tue Jan 1 20:49:55 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91E1D142A5C3 for ; Tue, 1 Jan 2019 20:49:54 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18FF48AEDB for ; Tue, 1 Jan 2019 20:47:39 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x01KlRH5070559; Tue, 1 Jan 2019 12:47:27 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x01KlQVj070558; Tue, 1 Jan 2019 12:47:26 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201901012047.x01KlQVj070558@pdx.rh.CN85.dnsmgr.net> Subject: Re: [BBB] nanobsd boot stuck In-Reply-To: <20190101104319.GA89465@freebsd-t450.fritz.box> To: =?iso-8859-15?Q?Manuel_St=FChn?= Date: Tue, 1 Jan 2019 12:47:26 -0800 (PST) CC: freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 18FF48AEDB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; REPLY(-4.00)[]; 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: Tue, 01 Jan 2019 20:49:56 -0000 > Hi, > a freshly built nanobsd RELEASE-12.0-p1 for Beaglebone Black does not > boot further than the line > "Trying to mount root from ufs:/dev/mmcsd0s2a [ro]" > > I've tried to track this further down and the findings are > > > 1. booting into single user mode works. When I boot into single user > mode and exit from there, the BBB continues its boot into multiuser > without any further problems. I'm able to login and have all my programs > working. > > 2. setting "set -x" in /etc/rc to extend verbosity. After setting, i can > see that the boot stops at line 62 of rc which says: > > dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` Hum, is /dev not getting mounted for some reason causing an issue here. Right before this line try adding: #Lets see what file systems are here now /bin/df #Lets see if we have a /dev/null to use /bin/ls -lag /dev/null #Lets see what this command returns /sbin/sysctl -n vfs.nfs.diskless_valid > > I altered this line to > > dlv=`/bin/echo "0"` Uh, ah, I see it, this is NOT what happens when you run: dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` set | grep dlv dlv='' To get past try: dlv='' > > but it still stops at that line. Using the builtin sh-echo instead of > the binary one ( dlv=`echo "0"` ) the boot continues until: This is starting to sound like it is having issues accessing the root device, like your sd card is toast. > > sh /etc/rc.initdiskless > Why did it wonder down the diskless path, you specifically set dlv.. oh gone back and editied.. I see it, dlv=0, not same as dlv='';. dlv gets null of vfs.nfs.dikless_valid does not exist as an oid: # /sbin/sysctl -n vfs.nfs.diskless_valid sysctl: unknown oid 'vfs.nfs.diskless_valid' not 0 as you forced. > After commenting this whole "diskless" section out, the boot continues > by sourcing rc.subr and stops in the function load_rc_config() executing > this line: > > [ -r /etc/defaults/rc.conf ] > > 3. using different SD-Cards containing the nanobsd image makes no > difference. All cards show same behavior described above. sd card socket, bad sd code in the kernel image your using? > 4. regular FreeBSD Image (non-nanobsd) does boot correctly. > > I do not have a clue how to further debug this. Since the > single-user-mode works, it seems to me that the installation as such is > not entirely broken, but there is some hickup in the init procedure. > > Any ideas? Well a few corrections above might get you closer, since you forced it down the diskless path, which is incorrect. > Thanks > > -- > Manuel > _______________________________________________ > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Tue Jan 1 23:14:40 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5465D142D6BA for ; Tue, 1 Jan 2019 23:14:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 35E0B8F5CF for ; Tue, 1 Jan 2019 23:14:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zclRtcgVM1lLNs0gGL95j0BqYtyHpQtF39oSiYumdn5b5hWaRBmfwS4WVNOl6qf NWBzi0BbF5vWO9Qiiw_WiXWlihb.t71.3itJqUFoKwNlcovT2CJlBPQeaRY7nnrvODtRO4WGpQcC Qo7tvr.sPGl9WGcF6eFw85W4zE2sTXOYm8jGRL5rfr6xk9cbTgSRvGZMYt2DGo_D0NaU37YJlsEi Ez58lojQzz9ZiDHtUeCSClgtTCHlewt2xvrQObdZaM1QXYaNPe9UjcTzKWltLgGNo9TYKZWxL5y4 l9x3LpZAkswc_5OaIRgLgQBlXl5YRT8kwUvmG3ra2EzmAQe1.dLAv0zWD2pvqL_mXP2UNajAXDPi 7KOQQRqPWplEGiznDI5RUwcCB.aPS9XD6usOEolSDU4SQkOMXBHdPOd_Jl4G2seGTjl_chC2pM0i cjEcQjd5TcD2UEinAgnJTBI8X4SlqdNWMu_m7bhwrYSXbicYruPMuI2QasjCaZpHLrebCKXxs6F5 jH1GR.CcmgLqcD7drdBXE1GMIzmrwjAZDyS79JTNhYcDrQqbKWEl7PZSzI1YPBheNibEJylCMzMo alRokhPmKdT6lII0XGg3uWED4TiLZVOQIF6cxq1cVVZvkAjAyWcC2z1cgg7RcRUJ0BgLalFUsPxI aB.V5Bw1RrDr61hlz9R3yzWGcwPp5402O2Cpz5aK5ApxbIYzpmOeka5a_uEoxoCsfGZKIvnYMewl m_lMUuBr5Ztnx17t3zb0hGG.DfDIA79srFWlwGzngYC_.WQq6OqNC8xzq4C_PPrjVBcef3Yexl22 XAmD6pm5NJAvNpAdIDLJM0vXj2LEpKK30lqgNNkcRp_kHTBwzf5bMKoes_2iuj6UcCGg2SE6qzp4 RfsQOR_MtaEyHDcQxKQI98PSsTyeR83deKUao9AeVx105SCe2XlWiDvkaCQE_7VWYY4LYusXn5jh orFh38NNipbb2zsSKzXZqxWV7KADonDj1efmZoMNKWJFOpmCHuLRa_6zkwCe4sGagTbzBDInUpau 4PCoOyxCsPtlMsE_Q_eTd24uK9CHrQ5tMTLkGPmoWdEV2vV5pWuKQrXpUw96tf01WsvjynwLY Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Jan 2019 23:14:30 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp419.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8c90122d314b20f31201564d03556535; Tue, 01 Jan 2019 23:14:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: How much memory to compile www/chromium? From: Mark Millard In-Reply-To: <20190101182153.GA13944@www.zefox.net> Date: Tue, 1 Jan 2019 15:14:26 -0800 Cc: freebsd-arm , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <66584297-22E7-4D94-963A-5FD4D9130686@yahoo.com> References: <20181212165313.GA84881@www.zefox.net> <20181212184149.ol44fon2unowu35q@squirrel.exwg.net> <20181212192115.GA85583@www.zefox.net> <20181212202504.4n3mhtx7grbeh6j7@squirrel.exwg.net> <20181214012733.GA92808@www.zefox.net> <20181218174903.GA41072@www.zefox.net> <20190101182153.GA13944@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 35E0B8F5CF X-Spamd-Bar: / X-Spamd-Result: default: False [-0.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.851,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.16)[0.163,0]; NEURAL_HAM_LONG(-0.80)[-0.795,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.69)[ip: (2.44), ipnet: 98.137.64.0/21(0.60), asn: 36647(0.48), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.64.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.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: Tue, 01 Jan 2019 23:14:40 -0000 On 2019-Jan-1, at 10:21, bob prohaska wrote: > On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: >>=20 >> Setting MAKE_JOBS_NUMBER_LIMIT=3D2 allowed www/chromium to compile = successfully over >> several days. The -DBATCH option was used, in hopes it'd fetch the = right options.=20 >>=20 >=20 > Just for fun I added a mechanical hard disk with a 4 GB swap partition = and re-ran > the www/chromium compilation with MAKE_JOBS_NUMBER_LIMIT unset, to see = what happens. > OOMA was turned off with vm.pageout_oom_seq=3D"2048" in = /boot/loader.conf. >=20 > After ~11 days the process finished. Log files of gstat output and = make output are at=20 > http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/mech_sd/ > in case anyone's curious. The log files are around 100MB, it seems = quickest to download=20 > them to look around. Swap use peaked at 3522008 kB. If gstat is to be = believed > the bottleneck appears to be the mechanical hard disk, which showed = near > 100% busy when the microSD swap partition was around 15% busy. Apart = from a few > "indefinite wait..." warnings on the console there was no indication = of errors. >=20 > As a further test, I'ved added two additional USB flash swap devices = and am re-running > the compilation of www/chromium. The swap layout is quite lopsided, = with the USB flash > devices having only 2 GB swap partitions on each, contrasting to the 4 = GB swap partitions > on the microSD card and mechanical disk.=20 >=20 > The first oddity is that top doesn't seem to see the extra swap space, = reporting only=20 > 7192M total. If you start top before changing the swap space (swapon or swapoff), top does not change to match: it does not monitor the swap space total size over time. But I've no other clue to the ordering that actually occurred. > Swapinfo does seem to plausibly report swap status as > Device 1K-blocks Used Avail Capacity > /dev/mmcsd0s2b 4404252 52228 4352024 1% > /dev/da0p1 4194304 50848 4143456 1% > /dev/da2p5 2097152 28232 2068920 1% > /dev/da1f 2097152 28060 2069092 1% > Total 12792860 159368 12633492 1% >=20 > after running overnight. >=20 > "indefinite wait..." warnings on the console have returned in = abundance with the use > of USB flash swap, even though swap usage is still less than 200MB.=20 You might want to report the types/models of the USB flash devices that were in used. Also relevant is the past usage pattern and amount of prior use on the USB flash devices. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 2 00:03:58 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61CAE142E729; Wed, 2 Jan 2019 00:03:58 +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 C80256A22D; Wed, 2 Jan 2019 00:03:56 +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 x0204BPJ015092 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Jan 2019 16:04:12 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x0204Bo4015091; Tue, 1 Jan 2019 16:04:11 -0800 (PST) (envelope-from fbsd) Date: Tue, 1 Jan 2019 16:04:11 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm , freebsd-ports@freebsd.org Subject: Re: How much memory to compile www/chromium? Message-ID: <20190102000411.GA14861@www.zefox.net> References: <20181212165313.GA84881@www.zefox.net> <20181212184149.ol44fon2unowu35q@squirrel.exwg.net> <20181212192115.GA85583@www.zefox.net> <20181212202504.4n3mhtx7grbeh6j7@squirrel.exwg.net> <20181214012733.GA92808@www.zefox.net> <20181218174903.GA41072@www.zefox.net> <20190101182153.GA13944@www.zefox.net> <66584297-22E7-4D94-963A-5FD4D9130686@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66584297-22E7-4D94-963A-5FD4D9130686@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: C80256A22D X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.77 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.71)[0.709,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.26)[0.257,0]; MX_GOOD(-0.01)[cached: www.zefox.net]; NEURAL_SPAM_LONG(0.69)[0.686,0]; IP_SCORE(0.22)[ip: (0.79), ipnet: 50.1.16.0/20(0.39), asn: 7065(0.02), country: US(-0.08)]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[] 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, 02 Jan 2019 00:03:58 -0000 On Tue, Jan 01, 2019 at 03:14:26PM -0800, Mark Millard wrote: > > > On 2019-Jan-1, at 10:21, bob prohaska wrote: > > > On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: > > > > > > As a further test, I'ved added two additional USB flash swap devices and am re-running > > the compilation of www/chromium. The swap layout is quite lopsided, with the USB flash > > devices having only 2 GB swap partitions on each, contrasting to the 4 GB swap partitions > > on the microSD card and mechanical disk. > > > > The first oddity is that top doesn't seem to see the extra swap space, reporting only > > 7192M total. > > If you start top before changing the swap space (swapon or > swapoff), top does not change to match: it does not monitor > the swap space total size over time. But I've no other clue > to the ordering that actually occurred. > In fact I made that mistake so I quit and restarted top. The incorrect swap total number persisted. After a fashion the number makes some sense: The small swap partitions are 2 GB, if the swap is used uniformly the total would be 8 GB. 7192 MB is less wrong than the ~13GB reported by swapinfo. > > You might want to report the types/models of the USB flash devices that > were in used. Also relevant is the past usage pattern and amount of > prior use on the USB flash devices. > > The flash devices are the same Sandisk Extreme "thumb drives" used in earlier swap experiments with buildworld. One is model SDCZ80-064, the other SDCZ800-064. The former is rated USB3.0, the latter USB3.1. They're certainly not new, but neither are they obviously broken (yet). Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Jan 2 02:43:58 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F46114321DB for ; Wed, 2 Jan 2019 02:43:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 B5F206E5E3 for ; Wed, 2 Jan 2019 02:43:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: LAWn62YVM1kZnptCb7wVUs.rq0nxsLjkM4HCu3G4jTSBGz7rsFnfSGv57pzpJ_w kVxMvKFZm_3yMflld52DjxeWI1BoxzvqlnFRuaOkytQG2_nAR1suHpjNwIcjZfebHr_gOtoqCGwn xLxiyuuqWeQLnGxTOIk1G53VeLxsxUnPiQpHZo4CDfSjiODM37h1DfBo08KvYsZFDqjej3ZvH2du uUYvGg.C6dyXPm2UtJ3p8RvXvYVizbttPQPz1RhUGEqO3fh.fUszP9iAg32bfZeq_wss0khmgbML .XU0UJnlBkzTmFafjLhtNMTdMVZFIormxff0XbWnDOIXVI4rnMqZqxuk4YNJc0HD__3iso7xNn6q .5WRjHfxStmwevYewkHPfgGZ1alOTLHnkn2nEbikb1_QTd3Fbp4fi.3qCoCCN53OlILnGz2Vb3EI NoffKEAvcB9MCXYT3qER2oNnkXJUrtE3fxMFNzxlN5TYlWFONAvHxKLa4BvTC1sbMQ7IR5_6VNdz vLTBkxi7LGewlmJWqiCi2VKzlXbYyY7i.NO.0ygRXTQQnvewVSAXr.IL1vNYb21AkqRl.tRCd8cS FgQItfUnhKL9XLk4hvQCUwb6CsBvY5HEjA10gKqbVnq9vIuiANTkVEFUBn3Nn6jFfqHLkKuZprBP vmSx3eHjPHFK78Alr4G_cBFcoGOGKkcUKuQOvLTEDyMk_uNvnl53jX5VslOqd2JurI0zJzaBiVjT 0CS4QvFzPRmM.J9M724_jg4arQ0YaiEPsZrj5SYxL0LZFLDf6R37RNELrRHdbWx.aP.fdqW0O1Dp PBADUX24sJKpMOxtuFYTJGJkxXaxcp88.FZRT902Td82fbYKCzN_i1foz0w7AVzr0YzT99APnCKr medeX0u4bZzq_Tj3yh4wdCoRKU95ZjCMPMYPSFUtkwP_jATzdVrWLaueZZfk7evtWte_FNljOg1N 2iS77ayzeNxrXVX8K0Nm8nn1kMzDNTqDgPAVdBgWMjghMH7jQw8Ehjd7_.crJQ00bigwuskcM9X6 M4N7crxyNGCO5WLfzzNRQNb1E0zWrOXK0UxTa2_npXCv3yXgCXNsagmQayt4WJe5Q1ll_WIzt Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Jan 2019 02:43:54 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2ea84824158dc5b5004ef3d5e7a20719; Wed, 02 Jan 2019 02:43:50 +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 12.2 \(3445.102.3\)) Subject: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 (with backtrace, code, and value details) Message-Id: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> Date: Tue, 1 Jan 2019 18:43:49 -0800 Cc: freebsd-arm To: freebsd-emulation@freebsd.org, ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: B5F206E5E3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.84 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.34)[ip: (-7.71), ipnet: 98.137.64.0/21(0.60), asn: 36647(0.48), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.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: Wed, 02 Jan 2019 02:43:58 -0000 The below showed up for poudiere-devel bulk getting stuck using one = FreeBSD cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, = unlike the last hang-up that I analyzed. I do not yet know how repeatable this = is but the original hang-up and the one experiment the below is from. =46rom top: PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 12789 root 4 52 0 166M 33M 0 uwait 6 36:06 = 97.22% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0 Note: The vast margority of the 36:06 has been stuck in the uwait loop = involved. =46rom ps -auxd: root 94075 0.0 0.0 12932 3552 1 S+ 10:42 0:01.21 = | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 root 1944 0.0 0.0 12932 3540 1 I+ 10:42 0:00.00 = | |-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 root 1957 0.0 0.0 12932 3556 1 I 10:42 0:00.04 = | |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: = build_pkg (poppler-qt5-0.72.0) (sh) root 12328 0.0 0.0 12932 3548 1 I 10:49 0:00.00 = | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: = build_pkg (poppler-qt5-0.72.0) (sh) root 12329 0.0 0.0 10328 1756 1 IJ 10:49 0:00.01 = | | `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 = stage root 12350 0.0 0.0 9860 1248 1 IJ 10:49 0:00.00 = | | `-- /usr/bin/make -f Makefile = DESTDIR=3D/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install root 12353 0.0 0.0 10236 1664 1 IJ 10:49 0:00.05 = | | `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 = qt5/all root 12787 0.0 0.0 9856 1236 1 IJ 10:50 0:00.00 = | | `-- /nxb-bin/usr/bin/make -f = qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make = qt5/test root 12789 100.0 0.0 169868 33528 1 IJ 10:50 36:35.26 = | | `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/ root 94423 0.0 0.0 12932 3484 1 S+ 10:42 0:12.91 = | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 (gdb) attach 12789 Attaching to process 12789 Reading symbols from = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qe= mu-arm-static...done. [New LWP 101168 of process 12789] [New LWP 101178 of process 12789] [New LWP 101499 of process 12789] [Switching to LWP 100304 of process 12789] _umtx_op () at _umtx_op.S:3 3 RSYSCALL(_umtx_op) (gdb) info threads Id Target Id Frame=20 * 1 LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3 2 LWP 101168 of process 12789 _umtx_op_err () at = /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 3 LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3 4 LWP 101499 of process 12789 0x0000000060051c26 in = atomic_cmpset_int (dst=3D, expect=3D, = src=3D536870912) at /usr/include/machine/atomic.h:220 (gdb) thread 4 [Switching to thread 4 (LWP 101499 of process 12789)] #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 220 ATOMIC_CMPSET(int); (gdb) bt #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 #5 0x00000000600392f0 in target_cpu_loop (env=3D0x86159b118) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/arm/target_arch_cpu.h:207 #6 0x0000000060038c99 in cpu_loop (env=3D0xf4dede80) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/main.c:121 #7 0x0000000060050c1a in new_freebsd_thread_start (arg=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:152 #8 0x00000000601ad5f6 in thread_start (curthread=3D0x861571300) at = /usr/src/lib/libthr/thread/thr_create.c:291 #9 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfbb3000 181 #define ATOMIC_CMPSET(TYPE) \ 182 static __inline int \ 183 atomic_cmpset_##TYPE(volatile u_##TYPE *dst, u_##TYPE expect, = u_##TYPE src) \ 184 { \ (gdb)=20 185 u_char res; \ 186 \ 187 __asm __volatile( \ 188 " " MPLOCKED " " \ 189 " cmpxchg %3,%1 ; " \ 190 " sete %0 ; " \ 191 "# atomic_cmpset_" #TYPE " " \ 192 : "=3Dq" (res), /* 0 */ \ 193 "+m" (*dst), /* 1 */ \ 194 "+a" (expect) /* 2 */ \ (gdb)=20 195 : "r" (src) /* 3 */ \ 196 : "memory", "cc"); \ 197 return (res); \ 198 } \ . . . 218 ATOMIC_CMPSET(char); 219 ATOMIC_CMPSET(short); 220 ATOMIC_CMPSET(int); 221 ATOMIC_CMPSET(long); (gdb) up #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 178 return atomic_cmpset_acq_32(addr, current, new); (gdb) list 173 static int tcmpset_32(uint32_t *addr, uint32_t a, uint32_t b) 174 { 175 uint32_t current =3D tswap32(a); 176 uint32_t new =3D tswap32(b); 177=09 178 return atomic_cmpset_acq_32(addr, current, new); 179 } (gdb) up #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { (gdb) list 1259 } 1260 } 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { 1262 /* decrement reader count */ 1263 for (;;) { 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { 1266 unlock_user_struct(target_urwlock, 1267 target_addr, 1); 1268 return -TARGET_EPERM; (gdb)=20 1269 } 1270 } else { 1271 break; 1272 } 1273 } 1274 } else { 1275 unlock_user_struct(target_urwlock, target_addr, 1); 1276 return -TARGET_EPERM; 1277 } 1278=09 The above loop is where the code is stuck looping, using most of the = capacity of one cpu (as FreeBSD classifies cpus). The value of state is stuck at: (gdb) print state $2 =3D 536870913 I'll note that the loop is inside qemu-arm-atatic, not in the cmake that = it is running. To show a little more context before the assembler for the routine that = ends up containing that loop: (gdb) up #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 474 ret =3D freebsd_rw_unlock(obj); (gdb) list 469 ret =3D freebsd_rw_wrlock(obj, val, 0, NULL); 470 } 471 break; 472=09 473 case TARGET_UMTX_OP_RW_UNLOCK: 474 ret =3D freebsd_rw_unlock(obj); 475 break; 476=09 477 #if defined(__FreeBSD_version) && __FreeBSD_version > 900000 478 #ifdef UMTX_OP_MUTEX_WAKE2 (gdb) up #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); (gdb) list 1359 ret =3D do_freebsd__umtx_unlock(arg1); 1360 break; 1361 #endif 1362=09 1363 case TARGET_FREEBSD_NR__umtx_op: /* undocumented */ 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); 1365 break; 1366=09 1367 /* 1368 * ioctl(2) As for the assembler level view for the routine containing the loop (via inlining and such): Dump of assembler code for function freebsd_rw_unlock: 0x0000000060051bd0 <+0>: push %rbp 0x0000000060051bd1 <+1>: mov %rsp,%rbp 0x0000000060051bd4 <+4>: push %rbx 0x0000000060051bd5 <+5>: push %rax 0x0000000060051bd6 <+6>: mov %edi,%ebx 0x0000000060051bd8 <+8>: mov $0x20,%esi 0x0000000060051bdd <+13>: mov $0x3,%edx 0x0000000060051be2 <+18>: callq 0x60036b70 0x0000000060051be7 <+23>: mov %eax,%ecx 0x0000000060051be9 <+25>: mov $0xfffffff2,%eax 0x0000000060051bee <+30>: test %ecx,%ecx 0x0000000060051bf0 <+32>: jne 0x60051c50 = 0x0000000060051bf2 <+34>: mov %ebx,%edi 0x0000000060051bf4 <+36>: add 0x26a6355(%rip),%rdi # = 0x626f7f50 0x0000000060051bfb <+43>: je 0x60051c50 = 0x0000000060051bfd <+45>: mov (%rdi),%ecx 0x0000000060051bff <+47>: mov 0x4(%rdi),%edx 0x0000000060051c02 <+50>: test %ecx,%ecx 0x0000000060051c04 <+52>: js 0x60051c30 0x0000000060051c06 <+54>: test $0x1fffffff,%ecx 0x0000000060051c0c <+60>: je 0x60051c4b = 0x0000000060051c0e <+62>: lea -0x1(%rcx),%esi 0x0000000060051c11 <+65>: nopw %cs:0x0(%rax,%rax,1) 0x0000000060051c1b <+75>: nopl 0x0(%rax,%rax,1) NOTE: loop is below: 0x0000000060051c20 <+80>: mov %ecx,%eax =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) 0x0000000060051c26 <+86>: sete %bl 0x0000000060051c29 <+89>: test %bl,%bl 0x0000000060051c2b <+91>: je 0x60051c20 Note: loop is above 0x0000000060051c2d <+93>: jmp 0x60051c57 = 0x0000000060051c2f <+95>: nop 0x0000000060051c30 <+96>: mov %ecx,%esi 0x0000000060051c32 <+98>: and $0x7fffffff,%esi 0x0000000060051c38 <+104>: mov %ecx,%eax 0x0000000060051c3a <+106>: lock cmpxchg %esi,(%rdi) 0x0000000060051c3e <+110>: sete %bl 0x0000000060051c41 <+113>: test %bl,%bl 0x0000000060051c43 <+115>: jne 0x60051c57 = 0x0000000060051c45 <+117>: mov (%rdi),%ecx 0x0000000060051c47 <+119>: test %ecx,%ecx 0x0000000060051c49 <+121>: js 0x60051c30 0x0000000060051c4b <+123>: mov $0xffffffff,%eax 0x0000000060051c50 <+128>: add $0x8,%rsp 0x0000000060051c54 <+132>: pop %rbx 0x0000000060051c55 <+133>: pop %rbp 0x0000000060051c56 <+134>: retq =20 0x0000000060051c57 <+135>: test $0x2,%dl 0x0000000060051c5a <+138>: jne 0x60051c70 = 0x0000000060051c5c <+140>: test $0x40000000,%ecx 0x0000000060051c62 <+146>: jne 0x60051c82 = 0x0000000060051c64 <+148>: xor %eax,%eax 0x0000000060051c66 <+150>: test $0x20000000,%ecx 0x0000000060051c6c <+156>: je 0x60051c50 = 0x0000000060051c6e <+158>: jmp 0x60051c89 = 0x0000000060051c70 <+160>: test $0x20000000,%ecx 0x0000000060051c76 <+166>: jne 0x60051c89 = 0x0000000060051c78 <+168>: xor %eax,%eax 0x0000000060051c7a <+170>: test $0x40000000,%ecx 0x0000000060051c80 <+176>: je 0x60051c50 = 0x0000000060051c82 <+178>: mov $0x1,%edx 0x0000000060051c87 <+183>: jmp 0x60051c8e = 0x0000000060051c89 <+185>: mov $0x7fffffff,%edx 0x0000000060051c8e <+190>: mov $0x3,%esi 0x0000000060051c93 <+195>: xor %ecx,%ecx 0x0000000060051c95 <+197>: xor %r8d,%r8d 0x0000000060051c98 <+200>: callq 0x601b5970 <_umtx_op> 0x0000000060051c9d <+205>: mov %eax,%edi 0x0000000060051c9f <+207>: add $0x8,%rsp 0x0000000060051ca3 <+211>: pop %rbx 0x0000000060051ca4 <+212>: pop %rbp --Type for more, q to quit, c to continue without paging-- 0x0000000060051ca5 <+213>: jmpq 0x60040a40 End of assembler dump. For just before the "lock cmpxchg %esi,(%rdi)" in the loop: rax 0x20000001 536870913 rbx 0xf4dede00 4108246528 rcx 0x20000001 536870913 rdx 0x2 2 rsi 0x20000000 536870912 rdi 0xf4dede80 4108246656 (gdb) x 0xf4dede80 0xf4dede80: 0x40000001 0x0000000060051c20 <+80>: mov %ecx,%eax =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) 0x0000000060051c26 <+86>: sete %bl 0x0000000060051c29 <+89>: test %bl,%bl 0x0000000060051c2b <+91>: je 0x60051c20 At this point I do not have interpretation of the details, not even a comparison to the source code. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 2 03:37:48 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2ADEB14331BE for ; Wed, 2 Jan 2019 03:37:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 457AA6FC23 for ; Wed, 2 Jan 2019 03:37:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 9S7KqawVM1nsPJ2rmLRCkK81xnAOujtjrZAZ_VPMhtSSUzzUIabeCq4RsuRMhQE pmbhZirJMlPYD9DOH_2mfs301u0JsmMg3ruIsweqns5DaSVqJoX.QzIXlHgBDil3_pXQYqiUWPZE gbR5ntoy20xslcRa8x8FqaY643NSi5YyPSzonVMey4Uy2hMh014S5ogvvlrnfsbBe1GhpEmAYHTE QVeeHv5lQ54kf7MA7Le6FjNK97VBAjw4mD7Phv7Bjc24cTzaFNpVdLYI1y0FicNB0_5e.Yf__kwj ezyCZrzLaxXj0s3HXQ1CJRwv45tXaC69nAbbRNgHfoMn93XDn9vE3v6hHUCdrxZ0O.bs1RRAT3zo 9JR8_0S2pK6vaSpnKUAj5fHq.s5XyOp.W2onQ8z7mz1hYpS1Cr0jooBSeRtJDqWa1snDGIHF9IQu A.pEuv5SAxHPaoUvWsqHFQ8R5M7YqFbW63oMUY0Bd9eXZGKl.8qhtTxHs5YBEX0W7VJtAzXzqDxD 7pdycplmYIWCFLz5X5zbyXAr6.aWgSqLQ2zJKwxj03gyB.72bvk8ySGS7lPY88xB4fXLjEpPvdck IUMxbPEFZmivZRgf9wmsdkVyVYzi8BboISYBmOo00qUmoyUjfWgM3WTClOnsY7B00kbe7zfAiStE RS_t2iYJOm6MMiCYnla0hzdh9XA3O4q5SIBk039ne8aCJbIR_amwPKWmYv2dymHmAYPk7W.0AyZS QTANPJel6YXXzXVBMN5P8u5Lysy1_7AmnR8xOybOmdq9IAYnfPWdm3HqWCPm0369U6w6ZYa0cYjZ D_TFfloxr58X.cPG5YifiOnN7QfSn2_cy6P11wPIaGh_xip__THEcKBZxJ6ajKmzlvv7lYbuySA2 ulUFOQPdzktZTe7Drb3WWyhVK6T_v.tvPtRa2m97D2v.JnLFfCqSrzIWzhED1j2.kDJ1qpS8pasq Z.mVmkcC9Ca8RTQTl3ryvLR.OvxVLZf4PoB_c4MM3qfmYgpSH.8gslhehxtMbR4o5SZxuqhZo.w3 fKRqvvuHphcbWoIGqbvXTQVvGF7CkGFp4fMP41joq8YpYW6XX89LdljVOSJ2rmBr6niyIfSA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Jan 2019 03:37:38 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp421.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1fc6b5ff2c0640e8f6371145fc776cba; Wed, 02 Jan 2019 03:37:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [problem possibly found] From: Mark Millard In-Reply-To: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> Date: Tue, 1 Jan 2019 19:37:35 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> To: freebsd-emulation@freebsd.org, ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 457AA6FC23 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.77 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.92)[-0.923,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.34)[ip: (-2.69), ipnet: 98.137.64.0/21(0.60), asn: 36647(0.48), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.64.137.98.list.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: Wed, 02 Jan 2019 03:37:48 -0000 [It looks to me like the assembler code has some code moved out of the loop that it should not be (by intent). It appears that calling tcmpset_32 does not prevent code motion to before the call and the variable involved was not declared volatile.] On 2019-Jan-1, at 18:43, Mark Millard wrote: > The below showed up for poudiere-devel bulk getting stuck using one = FreeBSD > cpu while building graphics/poppler-qt5 . This is not a kevent = hang-up, unlike > the last hang-up that I analyzed. I do not yet know how repeatable = this is > but the original hang-up and the one experiment the below is from. >=20 > =46rom top: >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 12789 root 4 52 0 166M 33M 0 uwait 6 36:06 = 97.22% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0 >=20 > Note: The vast margority of the 36:06 has been stuck in the uwait loop = involved. >=20 > =46rom ps -auxd: >=20 > root 94075 0.0 0.0 12932 3552 1 S+ 10:42 = 0:01.21 | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 > root 1944 0.0 0.0 12932 3540 1 I+ 10:42 = 0:00.00 | |-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 > root 1957 0.0 0.0 12932 3556 1 I 10:42 = 0:00.04 | |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: = build_pkg (poppler-qt5-0.72.0) (sh) > root 12328 0.0 0.0 12932 3548 1 I 10:49 = 0:00.00 | | `-- sh: = poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (poppler-qt5-0.72.0) = (sh) > root 12329 0.0 0.0 10328 1756 1 IJ 10:49 = 0:00.01 | | `-- /usr/bin/make -C = /usr/ports/graphics/poppler-qt5 stage > root 12350 0.0 0.0 9860 1248 1 IJ 10:49 = 0:00.00 | | `-- /usr/bin/make -f Makefile = DESTDIR=3D/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install > root 12353 0.0 0.0 10236 1664 1 IJ 10:49 = 0:00.05 | | `-- /nxb-bin/usr/bin/make -f = CMakeFiles/Makefile2 qt5/all > root 12787 0.0 0.0 9856 1236 1 IJ 10:50 = 0:00.00 | | `-- /nxb-bin/usr/bin/make -f = qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make = qt5/test > root 12789 100.0 0.0 169868 33528 1 IJ 10:50 = 36:35.26 | | `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/ > root 94423 0.0 0.0 12932 3484 1 S+ 10:42 = 0:12.91 | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 >=20 >=20 > (gdb) attach 12789 > Attaching to process 12789 > Reading symbols from = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qe= mu-arm-static...done. > [New LWP 101168 of process 12789] > [New LWP 101178 of process 12789] > [New LWP 101499 of process 12789] > [Switching to LWP 100304 of process 12789] > _umtx_op () at _umtx_op.S:3 > 3 RSYSCALL(_umtx_op) > (gdb) info threads > Id Target Id Frame=20 > * 1 LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3 > 2 LWP 101168 of process 12789 _umtx_op_err () at = /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 3 LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3 > 4 LWP 101499 of process 12789 0x0000000060051c26 in = atomic_cmpset_int (dst=3D, expect=3D, = src=3D536870912) at /usr/include/machine/atomic.h:220 > (gdb) thread 4 > [Switching to thread 4 (LWP 101499 of process 12789)] > #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 > 220 ATOMIC_CMPSET(int); >=20 > (gdb) bt > #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 > #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 > #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 > #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 > #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 > arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 > #5 0x00000000600392f0 in target_cpu_loop (env=3D0x86159b118) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/arm/target_arch_cpu.h:207 > #6 0x0000000060038c99 in cpu_loop (env=3D0xf4dede80) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/main.c:121 > #7 0x0000000060050c1a in new_freebsd_thread_start (arg=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:152 > #8 0x00000000601ad5f6 in thread_start (curthread=3D0x861571300) at = /usr/src/lib/libthr/thread/thr_create.c:291 > #9 0x0000000000000000 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffdfbb3000 >=20 > 181 #define ATOMIC_CMPSET(TYPE) \ > 182 static __inline int \ > 183 atomic_cmpset_##TYPE(volatile u_##TYPE *dst, u_##TYPE expect, = u_##TYPE src) \ > 184 { \ > (gdb)=20 > 185 u_char res; \ > 186 \ > 187 __asm __volatile( \ > 188 " " MPLOCKED " " \ > 189 " cmpxchg %3,%1 ; " \ > 190 " sete %0 ; " \ > 191 "# atomic_cmpset_" #TYPE " " \ > 192 : "=3Dq" (res), /* 0 */ \ > 193 "+m" (*dst), /* 1 */ \ > 194 "+a" (expect) /* 2 */ \ > (gdb)=20 > 195 : "r" (src) /* 3 */ \ > 196 : "memory", "cc"); \ > 197 return (res); \ > 198 } \ > . . . > 218 ATOMIC_CMPSET(char); > 219 ATOMIC_CMPSET(short); > 220 ATOMIC_CMPSET(int); > 221 ATOMIC_CMPSET(long); >=20 > (gdb) up > #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 > 178 return atomic_cmpset_acq_32(addr, current, new); > (gdb) list > 173 static int tcmpset_32(uint32_t *addr, uint32_t a, uint32_t b) > 174 { > 175 uint32_t current =3D tswap32(a); > 176 uint32_t new =3D tswap32(b); > 177=09 > 178 return atomic_cmpset_acq_32(addr, current, new); > 179 } >=20 > (gdb) up > #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { > (gdb) list > 1259 } > 1260 } > 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { > 1262 /* decrement reader count */ > 1263 for (;;) { > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { > 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { > 1266 unlock_user_struct(target_urwlock, > 1267 target_addr, 1); > 1268 return -TARGET_EPERM; > (gdb)=20 > 1269 } > 1270 } else { > 1271 break; > 1272 } > 1273 } > 1274 } else { > 1275 unlock_user_struct(target_urwlock, target_addr, 1); > 1276 return -TARGET_EPERM; > 1277 } > 1278=09 >=20 > The above loop is where the code is stuck looping, using most of the = capacity of > one cpu (as FreeBSD classifies cpus). The value of state is stuck at: >=20 > (gdb) print state > $2 =3D 536870913 >=20 > I'll note that the loop is inside qemu-arm-atatic, not in the cmake = that it > is running. >=20 >=20 >=20 > To show a little more context before the assembler for the routine = that ends up > containing that loop: >=20 > (gdb) up > #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 > 474 ret =3D freebsd_rw_unlock(obj); > (gdb) list > 469 ret =3D freebsd_rw_wrlock(obj, val, 0, NULL); > 470 } > 471 break; > 472=09 > 473 case TARGET_UMTX_OP_RW_UNLOCK: > 474 ret =3D freebsd_rw_unlock(obj); > 475 break; > 476=09 > 477 #if defined(__FreeBSD_version) && __FreeBSD_version > 900000 > 478 #ifdef UMTX_OP_MUTEX_WAKE2 >=20 > (gdb) up > #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 > arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 > 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); > (gdb) list > 1359 ret =3D do_freebsd__umtx_unlock(arg1); > 1360 break; > 1361 #endif > 1362=09 > 1363 case TARGET_FREEBSD_NR__umtx_op: /* undocumented */ > 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); > 1365 break; > 1366=09 > 1367 /* > 1368 * ioctl(2) >=20 > As for the assembler level view for the routine containing the > loop (via inlining and such): >=20 > Dump of assembler code for function freebsd_rw_unlock: > 0x0000000060051bd0 <+0>: push %rbp > 0x0000000060051bd1 <+1>: mov %rsp,%rbp > 0x0000000060051bd4 <+4>: push %rbx > 0x0000000060051bd5 <+5>: push %rax > 0x0000000060051bd6 <+6>: mov %edi,%ebx > 0x0000000060051bd8 <+8>: mov $0x20,%esi > 0x0000000060051bdd <+13>: mov $0x3,%edx > 0x0000000060051be2 <+18>: callq 0x60036b70 > 0x0000000060051be7 <+23>: mov %eax,%ecx > 0x0000000060051be9 <+25>: mov $0xfffffff2,%eax > 0x0000000060051bee <+30>: test %ecx,%ecx > 0x0000000060051bf0 <+32>: jne 0x60051c50 = > 0x0000000060051bf2 <+34>: mov %ebx,%edi > 0x0000000060051bf4 <+36>: add 0x26a6355(%rip),%rdi # = 0x626f7f50 > 0x0000000060051bfb <+43>: je 0x60051c50 = > 0x0000000060051bfd <+45>: mov (%rdi),%ecx > 0x0000000060051bff <+47>: mov 0x4(%rdi),%edx > 0x0000000060051c02 <+50>: test %ecx,%ecx > 0x0000000060051c04 <+52>: js 0x60051c30 > 0x0000000060051c06 <+54>: test $0x1fffffff,%ecx > 0x0000000060051c0c <+60>: je 0x60051c4b = > 0x0000000060051c0e <+62>: lea -0x1(%rcx),%esi > 0x0000000060051c11 <+65>: nopw %cs:0x0(%rax,%rax,1) > 0x0000000060051c1b <+75>: nopl 0x0(%rax,%rax,1) > NOTE: loop is below: > 0x0000000060051c20 <+80>: mov %ecx,%eax > =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) > 0x0000000060051c26 <+86>: sete %bl > 0x0000000060051c29 <+89>: test %bl,%bl > 0x0000000060051c2b <+91>: je 0x60051c20 > Note: loop is above > 0x0000000060051c2d <+93>: jmp 0x60051c57 = > 0x0000000060051c2f <+95>: nop > 0x0000000060051c30 <+96>: mov %ecx,%esi > 0x0000000060051c32 <+98>: and $0x7fffffff,%esi > 0x0000000060051c38 <+104>: mov %ecx,%eax > 0x0000000060051c3a <+106>: lock cmpxchg %esi,(%rdi) > 0x0000000060051c3e <+110>: sete %bl > 0x0000000060051c41 <+113>: test %bl,%bl > 0x0000000060051c43 <+115>: jne 0x60051c57 = > 0x0000000060051c45 <+117>: mov (%rdi),%ecx > 0x0000000060051c47 <+119>: test %ecx,%ecx > 0x0000000060051c49 <+121>: js 0x60051c30 > 0x0000000060051c4b <+123>: mov $0xffffffff,%eax > 0x0000000060051c50 <+128>: add $0x8,%rsp > 0x0000000060051c54 <+132>: pop %rbx > 0x0000000060051c55 <+133>: pop %rbp > 0x0000000060051c56 <+134>: retq =20 > 0x0000000060051c57 <+135>: test $0x2,%dl > 0x0000000060051c5a <+138>: jne 0x60051c70 = > 0x0000000060051c5c <+140>: test $0x40000000,%ecx > 0x0000000060051c62 <+146>: jne 0x60051c82 = > 0x0000000060051c64 <+148>: xor %eax,%eax > 0x0000000060051c66 <+150>: test $0x20000000,%ecx > 0x0000000060051c6c <+156>: je 0x60051c50 = > 0x0000000060051c6e <+158>: jmp 0x60051c89 = > 0x0000000060051c70 <+160>: test $0x20000000,%ecx > 0x0000000060051c76 <+166>: jne 0x60051c89 = > 0x0000000060051c78 <+168>: xor %eax,%eax > 0x0000000060051c7a <+170>: test $0x40000000,%ecx > 0x0000000060051c80 <+176>: je 0x60051c50 = > 0x0000000060051c82 <+178>: mov $0x1,%edx > 0x0000000060051c87 <+183>: jmp 0x60051c8e = > 0x0000000060051c89 <+185>: mov $0x7fffffff,%edx > 0x0000000060051c8e <+190>: mov $0x3,%esi > 0x0000000060051c93 <+195>: xor %ecx,%ecx > 0x0000000060051c95 <+197>: xor %r8d,%r8d > 0x0000000060051c98 <+200>: callq 0x601b5970 <_umtx_op> > 0x0000000060051c9d <+205>: mov %eax,%edi > 0x0000000060051c9f <+207>: add $0x8,%rsp > 0x0000000060051ca3 <+211>: pop %rbx > 0x0000000060051ca4 <+212>: pop %rbp > --Type for more, q to quit, c to continue without paging-- > 0x0000000060051ca5 <+213>: jmpq 0x60040a40 > End of assembler dump. >=20 > For just before the "lock cmpxchg %esi,(%rdi)" in the loop: >=20 > rax 0x20000001 536870913 > rbx 0xf4dede00 4108246528 > rcx 0x20000001 536870913 > rdx 0x2 2 > rsi 0x20000000 536870912 > rdi 0xf4dede80 4108246656 >=20 > (gdb) x 0xf4dede80 > 0xf4dede80: 0x40000001 >=20 > 0x0000000060051c20 <+80>: mov %ecx,%eax > =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) > 0x0000000060051c26 <+86>: sete %bl > 0x0000000060051c29 <+89>: test %bl,%bl > 0x0000000060051c2b <+91>: je 0x60051c20 >=20 >=20 > At this point I do not have interpretation of the details, not even > a comparison to the source code. In the source code there is: 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { 1262 /* decrement reader count */ 1263 for (;;) { 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { 1266 unlock_user_struct(target_urwlock, 1267 target_addr, 1); 1268 return -TARGET_EPERM; (gdb)=20 1269 } 1270 } else { 1271 break; 1272 } 1273 } But in the assembler code it appears to me that the code: 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { 1266 unlock_user_struct(target_urwlock, 1267 target_addr, 1); 1268 return -TARGET_EPERM; (gdb)=20 1269 } was factored out of the loop, with the test moved to before the loop. The TARGET_URWLOCK_READER_COUNT use masks off based on 0x1fffffff . But the code for the conditional test is before the loop: 0x0000000060051c06 <+54>: test $0x1fffffff,%ecx 0x0000000060051c0c <+60>: je 0x60051c4b = . . . NOTE: loop is below: 0x0000000060051c20 <+80>: mov %ecx,%eax =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) 0x0000000060051c26 <+86>: sete %bl 0x0000000060051c29 <+89>: test %bl,%bl 0x0000000060051c2b <+91>: je 0x60051c20 Note: loop is above I may try declaring state volatile in an attempt to prevent the code motion. (But what of other uses of tcmpset_32 controlling subordinate code in other places?) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 2 04:53:03 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E50871434C64 for ; Wed, 2 Jan 2019 04:53:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (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 DDBEC7207E for ; Wed, 2 Jan 2019 04:53:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: rivfqgUVM1k4_w1bRsr93rAsOEKgFiWiCmOQ8Drt.kdoIuNnQH_dzk_7gj4ysi1 R2tL2PLwoRSNaZYJa3AD3_lD14PRHAqWHy7nbaKlXKOhuBBTai2y6y4pwyLmh0Cvb0TztkLwg0iY ZiX.JkpbwzeFDtri9ORRJqql8pKxuaa0Not9jbRoYxC1Mk79HnotbQgPIs4uUY2PlmyJ1JhEoSl7 YbmoJmPokeJrDd7zuOtcUEH0xcIk77t0HmX1sqaAMBdNBG.bxMG1PzH_uojq.bHI_fZApq.s05mA yjxx5WcoPrAhdRvPZf3KEwWEve5GFQG42_xcyWZ4l6pSdYqFdkAJWNcUYC20.KbicCUex7vAhc_i V49GSMf67Dlhj31zs3di_Vs5heUYfUKoAcuwh8a2tGyfRXUpCHgKcD_GScFyNJxe.C5jWZxPbiTP Jx1UZy91caSSl5bU_5r8pJgBGsvUJ9loqAJKPOLxw0FcSNAWl5IOoR0A9J3CQ6EMJlyfEXr5gJQd tJ99VHtUVfHZ3Cgwauxw7h2Y0EmgkZfuz4B8aQswe0DS0oWDK3zjS8yvx8DwmjtAFY_ReV6RNFDS 13Xv0vSNMZOeM9PmVfYq8rhsCo3asWeU2I8HAwEo.UiAD5QQL0seJ_hRx45E2BQrBp.WZbEqwAJt Z1IYTtESe6AlY56I6jIP2DAEhgcc_.dt08rBwfgZZ6CYL_NmZ85Ww2GQTFmb.2m1Sy.p9kR1BRXO 4fl0H4tgv1gg0rFQ32d9Km9.nMpFbIICIoyuoM05_pP4bVTd0m3WTNHNF_oTw.Ejcv6Ir8kpTEu_ ZrhMo9myjLKfmInu982NqUoaJY3PyymaVabJnnn_sjLK3ynHqLq6qwI8OjlqzYoA9TpJB3b4KI2U go1BaOfw4_0zT7shUK7RNhxvP2iKuTVInYzVkWCQWWNGK61BDxFhlTLB.9gftPBvf7J7jIkWkgK5 y0oiv8d8RqldK_nZkMDNx75PV8tB.oOHR6TlqGMMJ3ibzDHKH934IPJrJ9ZQMSkX1T7LY6CpB2ko p.Hdw.W4Zthd4GZdq9HDFEf0vT31mF7NERO3X7Ys_CVtSp1DyMUGY91fpGIYIEtoD756dYek- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Jan 2019 04:52:53 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a77ac9e2e0bfe980ae387608a47651aa; Wed, 02 Jan 2019 04:42:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [problem not found] From: Mark Millard In-Reply-To: Date: Tue, 1 Jan 2019 20:42:42 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> To: freebsd-emulation@freebsd.org, ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: DDBEC7207E X-Spamd-Bar: / X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.65)[-0.650,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.31)[0.305,0]; NEURAL_HAM_LONG(-0.61)[-0.608,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.77)[ip: (2.85), ipnet: 98.137.64.0/21(0.59), asn: 36647(0.47), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.68.137.98.list.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: Wed, 02 Jan 2019 04:53:03 -0000 [I was wrong: it is code elimination, not motion. volatile is not a fix.] On 2019-Jan-1, at 19:37, Mark Millard wrote: > [It looks to me like the assembler code has some code moved out of the > loop that it should not be (by intent). It appears that calling > tcmpset_32 does not prevent code motion to before the call and > the variable involved was not declared volatile.] >=20 > On 2019-Jan-1, at 18:43, Mark Millard wrote: >=20 >> The below showed up for poudiere-devel bulk getting stuck using one = FreeBSD >> cpu while building graphics/poppler-qt5 . This is not a kevent = hang-up, unlike >> the last hang-up that I analyzed. I do not yet know how repeatable = this is >> but the original hang-up and the one experiment the below is from. >>=20 >> =46rom top: >>=20 >> PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND >> 12789 root 4 52 0 166M 33M 0 uwait 6 36:06 = 97.22% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0 >>=20 >> Note: The vast margority of the 36:06 has been stuck in the uwait = loop involved. >>=20 >> =46rom ps -auxd: >>=20 >> root 94075 0.0 0.0 12932 3552 1 S+ 10:42 = 0:01.21 | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 >> root 1944 0.0 0.0 12932 3540 1 I+ 10:42 = 0:00.00 | |-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 >> root 1957 0.0 0.0 12932 3556 1 I 10:42 = 0:00.04 | |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: = build_pkg (poppler-qt5-0.72.0) (sh) >> root 12328 0.0 0.0 12932 3548 1 I 10:49 = 0:00.00 | | `-- sh: = poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (poppler-qt5-0.72.0) = (sh) >> root 12329 0.0 0.0 10328 1756 1 IJ 10:49 = 0:00.01 | | `-- /usr/bin/make -C = /usr/ports/graphics/poppler-qt5 stage >> root 12350 0.0 0.0 9860 1248 1 IJ 10:49 = 0:00.00 | | `-- /usr/bin/make -f Makefile = DESTDIR=3D/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install >> root 12353 0.0 0.0 10236 1664 1 IJ 10:49 = 0:00.05 | | `-- /nxb-bin/usr/bin/make -f = CMakeFiles/Makefile2 qt5/all >> root 12787 0.0 0.0 9856 1236 1 IJ 10:50 = 0:00.00 | | `-- /nxb-bin/usr/bin/make -f = qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make = qt5/test >> root 12789 100.0 0.0 169868 33528 1 IJ 10:50 = 36:35.26 | | `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/ >> root 94423 0.0 0.0 12932 3484 1 S+ 10:42 = 0:12.91 | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 >>=20 >>=20 >> (gdb) attach 12789 >> Attaching to process 12789 >> Reading symbols from = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qe= mu-arm-static...done. >> [New LWP 101168 of process 12789] >> [New LWP 101178 of process 12789] >> [New LWP 101499 of process 12789] >> [Switching to LWP 100304 of process 12789] >> _umtx_op () at _umtx_op.S:3 >> 3 RSYSCALL(_umtx_op) >> (gdb) info threads >> Id Target Id Frame=20 >> * 1 LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3 >> 2 LWP 101168 of process 12789 _umtx_op_err () at = /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 >> 3 LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3 >> 4 LWP 101499 of process 12789 0x0000000060051c26 in = atomic_cmpset_int (dst=3D, expect=3D, = src=3D536870912) at /usr/include/machine/atomic.h:220 >> (gdb) thread 4 >> [Switching to thread 4 (LWP 101499 of process 12789)] >> #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 >> 220 ATOMIC_CMPSET(int); >>=20 >> (gdb) bt >> #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 >> #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 >> #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 >> #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) >> at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 >> #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 >> arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 >> #5 0x00000000600392f0 in target_cpu_loop (env=3D0x86159b118) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/arm/target_arch_cpu.h:207 >> #6 0x0000000060038c99 in cpu_loop (env=3D0xf4dede80) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/main.c:121 >> #7 0x0000000060050c1a in new_freebsd_thread_start (arg=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:152 >> #8 0x00000000601ad5f6 in thread_start (curthread=3D0x861571300) at = /usr/src/lib/libthr/thread/thr_create.c:291 >> #9 0x0000000000000000 in ?? () >> Backtrace stopped: Cannot access memory at address 0x7fffdfbb3000 >>=20 >> 181 #define ATOMIC_CMPSET(TYPE) \ >> 182 static __inline int \ >> 183 atomic_cmpset_##TYPE(volatile u_##TYPE *dst, u_##TYPE expect, = u_##TYPE src) \ >> 184 { \ >> (gdb)=20 >> 185 u_char res; \ >> 186 \ >> 187 __asm __volatile( \ >> 188 " " MPLOCKED " " \ >> 189 " cmpxchg %3,%1 ; " \ >> 190 " sete %0 ; " \ >> 191 "# atomic_cmpset_" #TYPE " " \ >> 192 : "=3Dq" (res), /* 0 */ \ >> 193 "+m" (*dst), /* 1 */ \ >> 194 "+a" (expect) /* 2 */ \ >> (gdb)=20 >> 195 : "r" (src) /* 3 */ \ >> 196 : "memory", "cc"); \ >> 197 return (res); \ >> 198 } \ >> . . . >> 218 ATOMIC_CMPSET(char); >> 219 ATOMIC_CMPSET(short); >> 220 ATOMIC_CMPSET(int); >> 221 ATOMIC_CMPSET(long); >>=20 >> (gdb) up >> #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 >> 178 return atomic_cmpset_acq_32(addr, current, new); >> (gdb) list >> 173 static int tcmpset_32(uint32_t *addr, uint32_t a, uint32_t b) >> 174 { >> 175 uint32_t current =3D tswap32(a); >> 176 uint32_t new =3D tswap32(b); >> 177=09 >> 178 return atomic_cmpset_acq_32(addr, current, new); >> 179 } >>=20 >> (gdb) up >> #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 >> 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { >> (gdb) list >> 1259 } >> 1260 } >> 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { >> 1262 /* decrement reader count */ >> 1263 for (;;) { >> 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { >> 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { >> 1266 unlock_user_struct(target_urwlock, >> 1267 target_addr, 1); >> 1268 return -TARGET_EPERM; >> (gdb)=20 >> 1269 } >> 1270 } else { >> 1271 break; >> 1272 } >> 1273 } >> 1274 } else { >> 1275 unlock_user_struct(target_urwlock, target_addr, 1); >> 1276 return -TARGET_EPERM; >> 1277 } >> 1278=09 >>=20 >> The above loop is where the code is stuck looping, using most of the = capacity of >> one cpu (as FreeBSD classifies cpus). The value of state is stuck at: >>=20 >> (gdb) print state >> $2 =3D 536870913 >>=20 >> I'll note that the loop is inside qemu-arm-atatic, not in the cmake = that it >> is running. >>=20 >>=20 >>=20 >> To show a little more context before the assembler for the routine = that ends up >> containing that loop: >>=20 >> (gdb) up >> #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) >> at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 >> 474 ret =3D freebsd_rw_unlock(obj); >> (gdb) list >> 469 ret =3D freebsd_rw_wrlock(obj, val, 0, NULL); >> 470 } >> 471 break; >> 472=09 >> 473 case TARGET_UMTX_OP_RW_UNLOCK: >> 474 ret =3D freebsd_rw_unlock(obj); >> 475 break; >> 476=09 >> 477 #if defined(__FreeBSD_version) && __FreeBSD_version > 900000 >> 478 #ifdef UMTX_OP_MUTEX_WAKE2 >>=20 >> (gdb) up >> #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 >> arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 >> 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); >> (gdb) list >> 1359 ret =3D do_freebsd__umtx_unlock(arg1); >> 1360 break; >> 1361 #endif >> 1362=09 >> 1363 case TARGET_FREEBSD_NR__umtx_op: /* undocumented */ >> 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); >> 1365 break; >> 1366=09 >> 1367 /* >> 1368 * ioctl(2) >>=20 >> As for the assembler level view for the routine containing the >> loop (via inlining and such): >>=20 >> Dump of assembler code for function freebsd_rw_unlock: >> 0x0000000060051bd0 <+0>: push %rbp >> 0x0000000060051bd1 <+1>: mov %rsp,%rbp >> 0x0000000060051bd4 <+4>: push %rbx >> 0x0000000060051bd5 <+5>: push %rax >> 0x0000000060051bd6 <+6>: mov %edi,%ebx >> 0x0000000060051bd8 <+8>: mov $0x20,%esi >> 0x0000000060051bdd <+13>: mov $0x3,%edx >> 0x0000000060051be2 <+18>: callq 0x60036b70 >> 0x0000000060051be7 <+23>: mov %eax,%ecx >> 0x0000000060051be9 <+25>: mov $0xfffffff2,%eax >> 0x0000000060051bee <+30>: test %ecx,%ecx >> 0x0000000060051bf0 <+32>: jne 0x60051c50 = >> 0x0000000060051bf2 <+34>: mov %ebx,%edi >> 0x0000000060051bf4 <+36>: add 0x26a6355(%rip),%rdi # = 0x626f7f50 >> 0x0000000060051bfb <+43>: je 0x60051c50 = >> 0x0000000060051bfd <+45>: mov (%rdi),%ecx >> 0x0000000060051bff <+47>: mov 0x4(%rdi),%edx >> 0x0000000060051c02 <+50>: test %ecx,%ecx >> 0x0000000060051c04 <+52>: js 0x60051c30 >> 0x0000000060051c06 <+54>: test $0x1fffffff,%ecx >> 0x0000000060051c0c <+60>: je 0x60051c4b = >> 0x0000000060051c0e <+62>: lea -0x1(%rcx),%esi >> 0x0000000060051c11 <+65>: nopw %cs:0x0(%rax,%rax,1) >> 0x0000000060051c1b <+75>: nopl 0x0(%rax,%rax,1) >> NOTE: loop is below: >> 0x0000000060051c20 <+80>: mov %ecx,%eax >> =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) >> 0x0000000060051c26 <+86>: sete %bl >> 0x0000000060051c29 <+89>: test %bl,%bl >> 0x0000000060051c2b <+91>: je 0x60051c20 >> Note: loop is above >> 0x0000000060051c2d <+93>: jmp 0x60051c57 = >> 0x0000000060051c2f <+95>: nop >> 0x0000000060051c30 <+96>: mov %ecx,%esi >> 0x0000000060051c32 <+98>: and $0x7fffffff,%esi >> 0x0000000060051c38 <+104>: mov %ecx,%eax >> 0x0000000060051c3a <+106>: lock cmpxchg %esi,(%rdi) >> 0x0000000060051c3e <+110>: sete %bl >> 0x0000000060051c41 <+113>: test %bl,%bl >> 0x0000000060051c43 <+115>: jne 0x60051c57 = >> 0x0000000060051c45 <+117>: mov (%rdi),%ecx >> 0x0000000060051c47 <+119>: test %ecx,%ecx >> 0x0000000060051c49 <+121>: js 0x60051c30 >> 0x0000000060051c4b <+123>: mov $0xffffffff,%eax >> 0x0000000060051c50 <+128>: add $0x8,%rsp >> 0x0000000060051c54 <+132>: pop %rbx >> 0x0000000060051c55 <+133>: pop %rbp >> 0x0000000060051c56 <+134>: retq =20 >> 0x0000000060051c57 <+135>: test $0x2,%dl >> 0x0000000060051c5a <+138>: jne 0x60051c70 = >> 0x0000000060051c5c <+140>: test $0x40000000,%ecx >> 0x0000000060051c62 <+146>: jne 0x60051c82 = >> 0x0000000060051c64 <+148>: xor %eax,%eax >> 0x0000000060051c66 <+150>: test $0x20000000,%ecx >> 0x0000000060051c6c <+156>: je 0x60051c50 = >> 0x0000000060051c6e <+158>: jmp 0x60051c89 = >> 0x0000000060051c70 <+160>: test $0x20000000,%ecx >> 0x0000000060051c76 <+166>: jne 0x60051c89 = >> 0x0000000060051c78 <+168>: xor %eax,%eax >> 0x0000000060051c7a <+170>: test $0x40000000,%ecx >> 0x0000000060051c80 <+176>: je 0x60051c50 = >> 0x0000000060051c82 <+178>: mov $0x1,%edx >> 0x0000000060051c87 <+183>: jmp 0x60051c8e = >> 0x0000000060051c89 <+185>: mov $0x7fffffff,%edx >> 0x0000000060051c8e <+190>: mov $0x3,%esi >> 0x0000000060051c93 <+195>: xor %ecx,%ecx >> 0x0000000060051c95 <+197>: xor %r8d,%r8d >> 0x0000000060051c98 <+200>: callq 0x601b5970 <_umtx_op> >> 0x0000000060051c9d <+205>: mov %eax,%edi >> 0x0000000060051c9f <+207>: add $0x8,%rsp >> 0x0000000060051ca3 <+211>: pop %rbx >> 0x0000000060051ca4 <+212>: pop %rbp >> --Type for more, q to quit, c to continue without paging-- >> 0x0000000060051ca5 <+213>: jmpq 0x60040a40 >> End of assembler dump. >>=20 >> For just before the "lock cmpxchg %esi,(%rdi)" in the loop: >>=20 >> rax 0x20000001 536870913 >> rbx 0xf4dede00 4108246528 >> rcx 0x20000001 536870913 >> rdx 0x2 2 >> rsi 0x20000000 536870912 >> rdi 0xf4dede80 4108246656 >>=20 >> (gdb) x 0xf4dede80 >> 0xf4dede80: 0x40000001 >>=20 >> 0x0000000060051c20 <+80>: mov %ecx,%eax >> =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) >> 0x0000000060051c26 <+86>: sete %bl >> 0x0000000060051c29 <+89>: test %bl,%bl >> 0x0000000060051c2b <+91>: je 0x60051c20 >>=20 >>=20 >> At this point I do not have interpretation of the details, not even >> a comparison to the source code. >=20 >=20 > . . . (misleading notes deleted) . . . I was wrong about the code motion: in . . . } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { /* decrement reader count */ for (;;) { if (!tcmpset_32(&target_urwlock->rw_state, state, (state - = 1))) { if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) { unlock_user_struct(target_urwlock, target_addr, 1); return -TARGET_EPERM; } } else { break; } } the outer test was leading to the inner-if being eliminated. While "volatile state" stopped that from happening it did not fix the hang-up in the loop. (There are likely other consequences to the use of memory involved instead of just a register as well.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 2 09:38:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11F3B143C5EF for ; Wed, 2 Jan 2019 09:38:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 D3EDF83B14 for ; Wed, 2 Jan 2019 09:38:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MbZRxqYVM1l0RTrWfY6B92ehXKJR0C1h1dBiyFQS.v2aTdKrGhofAhr7awVzRnc 5fbpIqxQKZRQ2jM72yV_zjdBR8RCQc0sEAFdkXmM.6ua2btuW97BqkLiExhy7D2ntO80xlkkSr0M oFllVLUy2zJlOWuFzZMnV1bLm0XaISM0pEGF2yBwKQY.dFS00CgN3tK0hu55XAc2DRuaQzqIsQmZ eLUCoqUpdEcJe5RlMCtJPY3RAa4z0onXbYk2aq_C.eOq3bfMQ9CZFtzpbZScAEc5rdZzdxSYtnsC 3m9UzQUD_5aV0naei5y60Vst8.eFISJSviU5hVkTGYt8xo7tEvNBTmtrmHHkFDqcqeKZ0dFFjE66 m3q2Td8SYNNidAKlp.QNjJfvjFSO5EVVgaJbsZt2x_lwqrXWK3qu4AgY3m13Z3ivcvBQ_QH3em7l JCeieNunB5ihHTyrENUibvA2E3esVeyKuhd3.z6QZgLMVot6gIZCRQj_fu_uBH_ONcugGucdiYDf EHDf2ERPtWlgQTO32Dp.icDgYfnA4CcwIf3AKmhfocrlt434BmKAqHbpDHI8sRuErOrIlgAM3XNZ K7UvlevwscAzf3.08kM98qDXoIrAmVrm4Y94C4R2JTDHy82vHRAPzZTfofNTrtwKWarFxxr6WuiC 59Hn0NMIysOrUP032GTTZO1ezzY.XHV8y.OKFxktYutNsfEN7Vg..PKEo9xFuTy0alBYy.qSeuLK cuPzBrFk3cIyLUzQEgl4jc6xrjC.Uh2Z9N6SgyxXBFm9Emg2FueJJvRCz6Ejz3Umvwd67TUMghAc tjR9ELh77Mt1.nSVgd5xy6u7xmaJxsNQf5jvA7OLzMojx_ZG3y9Jt1WQxyvBfb2oBkDELlyVr1CJ 9AbTtCHCNVv6cfEbaLxHnRpX5iQT39UEFdTJHAetnKrLwVJQDtKgc2_Bd60sCOyKtGUeFCmnTJqG FmPWFXWzVjEDmdvU_iyK7V0RiZwvcEO1GtJyigpN6IDeBf7S8wgLOTX_h9A3hsRWovQwTVIvyGZN sYbXfZ36K0ECCoNlIBbiEHZDFWzhnnETHJxGrp0oXQ4uJwRwalXpeloPpVQ2IrnLwSMBud2buYE8 7V30- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Wed, 2 Jan 2019 09:37:57 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c13c494d5caefe516d52fee49a1e7ccf; Wed, 02 Jan 2019 09:37:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included] From: Mark Millard In-Reply-To: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> Date: Wed, 2 Jan 2019 01:37:53 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> To: Sean Bruno , freebsd-emulation@freebsd.org, ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: D3EDF83B14 X-Spamd-Bar: + X-Spamd-Result: default: False [1.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.40)[-0.400,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.83)[0.830,0]; NEURAL_HAM_LONG(-0.02)[-0.020,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.37)[ip: (4.24), ipnet: 74.6.128.0/21(1.50), asn: 26101(1.20), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[41.130.6.74.list.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: Wed, 02 Jan 2019 09:38:06 -0000 On 2019-Jan-1, at 18:43, Mark Millard wrote: > The below showed up for poudiere-devel bulk getting stuck using one = FreeBSD > cpu while building graphics/poppler-qt5 . This is not a kevent = hang-up, unlike > the last hang-up that I analyzed. I do not yet know how repeatable = this is > but the original hang-up and the one experiment the below is from. >=20 > =46rom top: >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 12789 root 4 52 0 166M 33M 0 uwait 6 36:06 = 97.22% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0 >=20 > Note: The vast margority of the 36:06 has been stuck in the uwait loop = involved. >=20 > =46rom ps -auxd: >=20 > root 94075 0.0 0.0 12932 3552 1 S+ 10:42 = 0:01.21 | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 > root 1944 0.0 0.0 12932 3540 1 I+ 10:42 = 0:00.00 | |-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 > root 1957 0.0 0.0 12932 3556 1 I 10:42 = 0:00.04 | |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: = build_pkg (poppler-qt5-0.72.0) (sh) > root 12328 0.0 0.0 12932 3548 1 I 10:49 = 0:00.00 | | `-- sh: = poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (poppler-qt5-0.72.0) = (sh) > root 12329 0.0 0.0 10328 1756 1 IJ 10:49 = 0:00.01 | | `-- /usr/bin/make -C = /usr/ports/graphics/poppler-qt5 stage > root 12350 0.0 0.0 9860 1248 1 IJ 10:49 = 0:00.00 | | `-- /usr/bin/make -f Makefile = DESTDIR=3D/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install > root 12353 0.0 0.0 10236 1664 1 IJ 10:49 = 0:00.05 | | `-- /nxb-bin/usr/bin/make -f = CMakeFiles/Makefile2 qt5/all > root 12787 0.0 0.0 9856 1236 1 IJ 10:50 = 0:00.00 | | `-- /nxb-bin/usr/bin/make -f = qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make = qt5/test > root 12789 100.0 0.0 169868 33528 1 IJ 10:50 = 36:35.26 | | `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/ > root 94423 0.0 0.0 12932 3484 1 S+ 10:42 = 0:12.91 | `-- sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 >=20 >=20 > (gdb) attach 12789 > Attaching to process 12789 > Reading symbols from = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qe= mu-arm-static...done. > [New LWP 101168 of process 12789] > [New LWP 101178 of process 12789] > [New LWP 101499 of process 12789] > [Switching to LWP 100304 of process 12789] > _umtx_op () at _umtx_op.S:3 > 3 RSYSCALL(_umtx_op) > (gdb) info threads > Id Target Id Frame=20 > * 1 LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3 > 2 LWP 101168 of process 12789 _umtx_op_err () at = /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 3 LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3 > 4 LWP 101499 of process 12789 0x0000000060051c26 in = atomic_cmpset_int (dst=3D, expect=3D, = src=3D536870912) at /usr/include/machine/atomic.h:220 > (gdb) thread 4 > [Switching to thread 4 (LWP 101499 of process 12789)] > #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 > 220 ATOMIC_CMPSET(int); >=20 > (gdb) bt > #0 0x0000000060051c26 in atomic_cmpset_int (dst=3D, = expect=3D, src=3D536870912) at = /usr/include/machine/atomic.h:220 > #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 > #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 > #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 > #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 > arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 > #5 0x00000000600392f0 in target_cpu_loop (env=3D0x86159b118) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/arm/target_arch_cpu.h:207 > #6 0x0000000060038c99 in cpu_loop (env=3D0xf4dede80) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/main.c:121 > #7 0x0000000060050c1a in new_freebsd_thread_start (arg=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:152 > #8 0x00000000601ad5f6 in thread_start (curthread=3D0x861571300) at = /usr/src/lib/libthr/thread/thr_create.c:291 > #9 0x0000000000000000 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffdfbb3000 >=20 > 181 #define ATOMIC_CMPSET(TYPE) \ > 182 static __inline int \ > 183 atomic_cmpset_##TYPE(volatile u_##TYPE *dst, u_##TYPE expect, = u_##TYPE src) \ > 184 { \ > (gdb)=20 > 185 u_char res; \ > 186 \ > 187 __asm __volatile( \ > 188 " " MPLOCKED " " \ > 189 " cmpxchg %3,%1 ; " \ > 190 " sete %0 ; " \ > 191 "# atomic_cmpset_" #TYPE " " \ > 192 : "=3Dq" (res), /* 0 */ \ > 193 "+m" (*dst), /* 1 */ \ > 194 "+a" (expect) /* 2 */ \ > (gdb)=20 > 195 : "r" (src) /* 3 */ \ > 196 : "memory", "cc"); \ > 197 return (res); \ > 198 } \ > . . . > 218 ATOMIC_CMPSET(char); > 219 ATOMIC_CMPSET(short); > 220 ATOMIC_CMPSET(int); > 221 ATOMIC_CMPSET(long); >=20 > (gdb) up > #1 tcmpset_32 (addr=3D, a=3D, = b=3D536870912) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:178 > 178 return atomic_cmpset_acq_32(addr, current, new); > (gdb) list > 173 static int tcmpset_32(uint32_t *addr, uint32_t a, uint32_t b) > 174 { > 175 uint32_t current =3D tswap32(a); > 176 uint32_t new =3D tswap32(b); > 177=09 > 178 return atomic_cmpset_acq_32(addr, current, new); > 179 } >=20 > (gdb) up > #2 freebsd_rw_unlock (target_addr=3D4108246528) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.c:1264 > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { > (gdb) list > 1259 } > 1260 } > 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { > 1262 /* decrement reader count */ > 1263 for (;;) { > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { > 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { > 1266 unlock_user_struct(target_urwlock, > 1267 target_addr, 1); > 1268 return -TARGET_EPERM; > (gdb)=20 > 1269 } > 1270 } else { > 1271 break; > 1272 } > 1273 } > 1274 } else { > 1275 unlock_user_struct(target_urwlock, target_addr, 1); > 1276 return -TARGET_EPERM; > 1277 } > 1278=09 >=20 > The above loop is where the code is stuck looping, using most of the = capacity of > one cpu (as FreeBSD classifies cpus). The value of state is stuck at: >=20 > (gdb) print state > $2 =3D 536870913 >=20 > I'll note that the loop is inside qemu-arm-atatic, not in the cmake = that it > is running. >=20 >=20 >=20 > To show a little more context before the assembler for the routine = that ends up > containing that loop: >=20 > (gdb) up > #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=3D, = op=3D536870912, val=3D, uaddr=3D, = target_time=3D) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/freebsd/os-thread.h:474 > 474 ret =3D freebsd_rw_unlock(obj); > (gdb) list > 469 ret =3D freebsd_rw_wrlock(obj, val, 0, NULL); > 470 } > 471 break; > 472=09 > 473 case TARGET_UMTX_OP_RW_UNLOCK: > 474 ret =3D freebsd_rw_unlock(obj); > 475 break; > 476=09 > 477 #if defined(__FreeBSD_version) && __FreeBSD_version > 900000 > 478 #ifdef UMTX_OP_MUTEX_WAKE2 >=20 > (gdb) up > #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=3D0x86159b118, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-184411592, = arg7=3D-199471616,=20 > arg8=3D-1622188640) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/syscall.c:1364 > 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); > (gdb) list > 1359 ret =3D do_freebsd__umtx_unlock(arg1); > 1360 break; > 1361 #endif > 1362=09 > 1363 case TARGET_FREEBSD_NR__umtx_op: /* undocumented */ > 1364 ret =3D do_freebsd__umtx_op(arg1, arg2, arg3, arg4, = arg5); > 1365 break; > 1366=09 > 1367 /* > 1368 * ioctl(2) >=20 > As for the assembler level view for the routine containing the > loop (via inlining and such): >=20 > Dump of assembler code for function freebsd_rw_unlock: > 0x0000000060051bd0 <+0>: push %rbp > 0x0000000060051bd1 <+1>: mov %rsp,%rbp > 0x0000000060051bd4 <+4>: push %rbx > 0x0000000060051bd5 <+5>: push %rax > 0x0000000060051bd6 <+6>: mov %edi,%ebx > 0x0000000060051bd8 <+8>: mov $0x20,%esi > 0x0000000060051bdd <+13>: mov $0x3,%edx > 0x0000000060051be2 <+18>: callq 0x60036b70 > 0x0000000060051be7 <+23>: mov %eax,%ecx > 0x0000000060051be9 <+25>: mov $0xfffffff2,%eax > 0x0000000060051bee <+30>: test %ecx,%ecx > 0x0000000060051bf0 <+32>: jne 0x60051c50 = > 0x0000000060051bf2 <+34>: mov %ebx,%edi > 0x0000000060051bf4 <+36>: add 0x26a6355(%rip),%rdi # = 0x626f7f50 > 0x0000000060051bfb <+43>: je 0x60051c50 = > 0x0000000060051bfd <+45>: mov (%rdi),%ecx > 0x0000000060051bff <+47>: mov 0x4(%rdi),%edx > 0x0000000060051c02 <+50>: test %ecx,%ecx > 0x0000000060051c04 <+52>: js 0x60051c30 > 0x0000000060051c06 <+54>: test $0x1fffffff,%ecx > 0x0000000060051c0c <+60>: je 0x60051c4b = > 0x0000000060051c0e <+62>: lea -0x1(%rcx),%esi > 0x0000000060051c11 <+65>: nopw %cs:0x0(%rax,%rax,1) > 0x0000000060051c1b <+75>: nopl 0x0(%rax,%rax,1) > NOTE: loop is below: > 0x0000000060051c20 <+80>: mov %ecx,%eax > =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) > 0x0000000060051c26 <+86>: sete %bl > 0x0000000060051c29 <+89>: test %bl,%bl > 0x0000000060051c2b <+91>: je 0x60051c20 > Note: loop is above > 0x0000000060051c2d <+93>: jmp 0x60051c57 = > 0x0000000060051c2f <+95>: nop > 0x0000000060051c30 <+96>: mov %ecx,%esi > 0x0000000060051c32 <+98>: and $0x7fffffff,%esi > 0x0000000060051c38 <+104>: mov %ecx,%eax > 0x0000000060051c3a <+106>: lock cmpxchg %esi,(%rdi) > 0x0000000060051c3e <+110>: sete %bl > 0x0000000060051c41 <+113>: test %bl,%bl > 0x0000000060051c43 <+115>: jne 0x60051c57 = > 0x0000000060051c45 <+117>: mov (%rdi),%ecx > 0x0000000060051c47 <+119>: test %ecx,%ecx > 0x0000000060051c49 <+121>: js 0x60051c30 > 0x0000000060051c4b <+123>: mov $0xffffffff,%eax > 0x0000000060051c50 <+128>: add $0x8,%rsp > 0x0000000060051c54 <+132>: pop %rbx > 0x0000000060051c55 <+133>: pop %rbp > 0x0000000060051c56 <+134>: retq =20 > 0x0000000060051c57 <+135>: test $0x2,%dl > 0x0000000060051c5a <+138>: jne 0x60051c70 = > 0x0000000060051c5c <+140>: test $0x40000000,%ecx > 0x0000000060051c62 <+146>: jne 0x60051c82 = > 0x0000000060051c64 <+148>: xor %eax,%eax > 0x0000000060051c66 <+150>: test $0x20000000,%ecx > 0x0000000060051c6c <+156>: je 0x60051c50 = > 0x0000000060051c6e <+158>: jmp 0x60051c89 = > 0x0000000060051c70 <+160>: test $0x20000000,%ecx > 0x0000000060051c76 <+166>: jne 0x60051c89 = > 0x0000000060051c78 <+168>: xor %eax,%eax > 0x0000000060051c7a <+170>: test $0x40000000,%ecx > 0x0000000060051c80 <+176>: je 0x60051c50 = > 0x0000000060051c82 <+178>: mov $0x1,%edx > 0x0000000060051c87 <+183>: jmp 0x60051c8e = > 0x0000000060051c89 <+185>: mov $0x7fffffff,%edx > 0x0000000060051c8e <+190>: mov $0x3,%esi > 0x0000000060051c93 <+195>: xor %ecx,%ecx > 0x0000000060051c95 <+197>: xor %r8d,%r8d > 0x0000000060051c98 <+200>: callq 0x601b5970 <_umtx_op> > 0x0000000060051c9d <+205>: mov %eax,%edi > 0x0000000060051c9f <+207>: add $0x8,%rsp > 0x0000000060051ca3 <+211>: pop %rbx > 0x0000000060051ca4 <+212>: pop %rbp > --Type for more, q to quit, c to continue without paging-- > 0x0000000060051ca5 <+213>: jmpq 0x60040a40 > End of assembler dump. >=20 > For just before the "lock cmpxchg %esi,(%rdi)" in the loop: >=20 > rax 0x20000001 536870913 > rbx 0xf4dede00 4108246528 > rcx 0x20000001 536870913 > rdx 0x2 2 > rsi 0x20000000 536870912 > rdi 0xf4dede80 4108246656 >=20 > (gdb) x 0xf4dede80 > 0xf4dede80: 0x40000001 >=20 > 0x0000000060051c20 <+80>: mov %ecx,%eax > =3D> 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) > 0x0000000060051c26 <+86>: sete %bl > 0x0000000060051c29 <+89>: test %bl,%bl > 0x0000000060051c2b <+91>: je 0x60051c20 >=20 >=20 > At this point I do not have interpretation of the details, not even > a comparison to the source code. Note: The problem was observed in building ports head -r488859 's = graphics/poppler-qt5 . In the below code I've added a missing statement: > 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { > 1262 /* decrement reader count */ > 1263 for (;;) { > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, = (state - 1))) { __get_user(state, &target_urwlock->rw_state); > 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { > 1266 unlock_user_struct(target_urwlock, > 1267 target_addr, 1); > 1268 return -TARGET_EPERM; > (gdb)=20 > 1269 } > 1270 } else { > 1271 break; > 1272 } > 1273 } The lack of the update to 'state' is why it was valid for the compiler to eliminate the code for: > 1265 if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) = { > 1266 unlock_user_struct(target_urwlock, > 1267 target_addr, 1); > 1268 return -TARGET_EPERM; > (gdb)=20 > 1269 } So (without old line numbers): } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { /* decrement reader count */ for (;;) { if (!tcmpset_32(&target_urwlock->rw_state, state, (state - = 1))) { __get_user(state, &target_urwlock->rw_state); if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) { unlock_user_struct(target_urwlock, target_addr, 1); return -TARGET_EPERM; } } else { break; } } This follows the structure of other tcmpset_32 use in the source file. With this change poudriere-devel's bulk worked for graphics/poppler-qt5 as a amd64->armv7 cross-build (FreeBSD head -r341836 based, under = Hyper-V, with 28 logical-processors assigned): [00:00:13] [01] [00:00:00] Building graphics/poppler-qt5 | = poppler-qt5-0.72.0 [00:08:03] [01] [00:07:50] Finished graphics/poppler-qt5 | = poppler-qt5-0.72.0: Success =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jan 2 14:03:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31D1014211B3 for ; Wed, 2 Jan 2019 14:03:06 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D7778D75B for ; Wed, 2 Jan 2019 14:03:05 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.164] (helo=mjail1.freenet.de) by mout1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1geh6s-0001Lp-1o; Wed, 02 Jan 2019 15:03:02 +0100 Received: from [::1] (port=41614 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1geh6s-00061Y-1A; Wed, 02 Jan 2019 15:03:02 +0100 Received: from sub1.freenet.de ([195.4.92.120]:45472) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1geh4h-0005E2-M9; Wed, 02 Jan 2019 15:00:47 +0100 Received: from p4ffc6cfc.dip0.t-ipconnect.de ([79.252.108.252]:36653 helo=freebsd-t450.fritz.box) by sub1.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 587) (Exim 4.90_1 #2) id 1geh4h-0005It-IM; Wed, 02 Jan 2019 15:00:47 +0100 Date: Wed, 2 Jan 2019 15:00:45 +0100 From: Manuel =?iso-8859-15?Q?St=FChn?= To: "Rodney W. Grimes" Cc: freebsd-arm@freebsd.org Subject: Re: [BBB] nanobsd boot stuck Message-ID: <20190102140045.GA57656@freebsd-t450.fritz.box> References: <20190101104319.GA89465@freebsd-t450.fritz.box> <201901012047.x01KlQVj070558@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <201901012047.x01KlQVj070558@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.11.1 (2018-12-01) X-Originated-At: 79.252.108.252!36653 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, 02 Jan 2019 14:03:06 -0000 On Tue, Jan 01, 2019 at 12:47:26PM -0800, Rodney W. Grimes wrote: >> Hi, >> a freshly built nanobsd RELEASE-12.0-p1 for Beaglebone Black does not >> boot further than the line >> "Trying to mount root from ufs:/dev/mmcsd0s2a [ro]" >> >> I've tried to track this further down and the findings are >> >> >> 1. booting into single user mode works. When I boot into single user >> mode and exit from there, the BBB continues its boot into multiuser >> without any further problems. I'm able to login and have all my programs >> working. >> >> 2. setting "set -x" in /etc/rc to extend verbosity. After setting, i can >> see that the boot stops at line 62 of rc which says: >> >> dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` > >Hum, is /dev not getting mounted for some reason >causing an issue here. >Right before this line try adding: >#Lets see what file systems are here now >/bin/df >#Lets see if we have a /dev/null to use >/bin/ls -lag /dev/null >#Lets see what this command returns >/sbin/sysctl -n vfs.nfs.diskless_valid >> >> I altered this line to >> >> dlv=`/bin/echo "0"` >Uh, ah, I see it, this is NOT what happens when you run: >dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` >set | grep dlv >dlv='' >To get past try: >dlv='' >> >> but it still stops at that line. Using the builtin sh-echo instead of >> the binary one ( dlv=`echo "0"` ) the boot continues until: > >This is starting to sound like it is having issues accessing >the root device, like your sd card is toast. >> >> sh /etc/rc.initdiskless >> >Why did it wonder down the diskless path, you specifically >set dlv.. oh gone back and editied.. I see it, dlv=0, not same as dlv='';. >dlv gets null of vfs.nfs.dikless_valid does not exist as an oid: ># /sbin/sysctl -n vfs.nfs.diskless_valid >sysctl: unknown oid 'vfs.nfs.diskless_valid' >not 0 as you forced. hmm, on all my machines (amd64 and armv7, 12.0-p1 and 11.2-STABLE) there exists an oid named vfs.nfs.diskless_valid: # sysctl -n vfs.nfs.diskless_valid 0 That was the reason why i've set dlv to 0 in the first place. >> After commenting this whole "diskless" section out, the boot continues >> by sourcing rc.subr and stops in the function load_rc_config() executing >> this line: > >> >> [ -r /etc/defaults/rc.conf ] >> >> 3. using different SD-Cards containing the nanobsd image makes no >> difference. All cards show same behavior described above. > >sd card socket, bad sd code in the kernel image your using? I've managed to organize another Beaglebone Black board, and on this one the image does boot without issues. It seems that the beaglebone i was developing on the whole time is defect somehow! >> 4. regular FreeBSD Image (non-nanobsd) does boot correctly. >> >> I do not have a clue how to further debug this. Since the >> single-user-mode works, it seems to me that the installation as such is >> not entirely broken, but there is some hickup in the init procedure. >> >> Any ideas? > >Well a few corrections above might get you closer, since >you forced it down the diskless path, which is incorrect. Thank you for your tips! >> Thanks >> >> -- >> Manuel >> _______________________________________________ >> 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" >> > >-- >Rod Grimes rgrimes@freebsd.org -- Manuel From owner-freebsd-arm@freebsd.org Wed Jan 2 18:39:30 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E00B2142C4A3 for ; Wed, 2 Jan 2019 18:39:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1866AEBA for ; Wed, 2 Jan 2019 18:39:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x02IdObU075061; Wed, 2 Jan 2019 10:39:24 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x02IdOSH075060; Wed, 2 Jan 2019 10:39:24 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201901021839.x02IdOSH075060@pdx.rh.CN85.dnsmgr.net> Subject: Re: [BBB] nanobsd boot stuck In-Reply-To: <20190102140045.GA57656@freebsd-t450.fritz.box> To: =?iso-8859-15?Q?Manuel_St=FChn?= Date: Wed, 2 Jan 2019 10:39:24 -0800 (PST) CC: freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 6D1866AEBA X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; REPLY(-4.00)[]; 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: Wed, 02 Jan 2019 18:39:30 -0000 > On Tue, Jan 01, 2019 at 12:47:26PM -0800, Rodney W. Grimes wrote: > >> Hi, > >> a freshly built nanobsd RELEASE-12.0-p1 for Beaglebone Black does not > >> boot further than the line > >> "Trying to mount root from ufs:/dev/mmcsd0s2a [ro]" > >> > >> I've tried to track this further down and the findings are > >> > >> > >> 1. booting into single user mode works. When I boot into single user > >> mode and exit from there, the BBB continues its boot into multiuser > >> without any further problems. I'm able to login and have all my programs > >> working. > >> > >> 2. setting "set -x" in /etc/rc to extend verbosity. After setting, i can > >> see that the boot stops at line 62 of rc which says: > >> > >> dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` > > > >Hum, is /dev not getting mounted for some reason > >causing an issue here. > >Right before this line try adding: > >#Lets see what file systems are here now > >/bin/df > >#Lets see if we have a /dev/null to use > >/bin/ls -lag /dev/null > >#Lets see what this command returns > >/sbin/sysctl -n vfs.nfs.diskless_valid > >> > >> I altered this line to > >> > >> dlv=`/bin/echo "0"` > >Uh, ah, I see it, this is NOT what happens when you run: > >dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` > >set | grep dlv > >dlv='' > >To get past try: > >dlv='' > >> > >> but it still stops at that line. Using the builtin sh-echo instead of > >> the binary one ( dlv=`echo "0"` ) the boot continues until: > > > >This is starting to sound like it is having issues accessing > >the root device, like your sd card is toast. > >> > >> sh /etc/rc.initdiskless > >> > >Why did it wonder down the diskless path, you specifically > >set dlv.. oh gone back and editied.. I see it, dlv=0, not same as dlv='';. > >dlv gets null of vfs.nfs.dikless_valid does not exist as an oid: > ># /sbin/sysctl -n vfs.nfs.diskless_valid > >sysctl: unknown oid 'vfs.nfs.diskless_valid' > >not 0 as you forced. > > hmm, on all my machines (amd64 and armv7, 12.0-p1 and 11.2-STABLE) there > exists an oid named vfs.nfs.diskless_valid: > > # sysctl -n vfs.nfs.diskless_valid > 0 > > That was the reason why i've set dlv to 0 in the first place. Argh, ok, I went down the wrong rabbit hole, teach me for not doing a uname before I run stuff in an xterm to see what the values are. 11.1 does not have this oid. > > >> After commenting this whole "diskless" section out, the boot continues > >> by sourcing rc.subr and stops in the function load_rc_config() executing > >> this line: > > > >> > >> [ -r /etc/defaults/rc.conf ] > >> > >> 3. using different SD-Cards containing the nanobsd image makes no > >> difference. All cards show same behavior described above. > > > >sd card socket, bad sd code in the kernel image your using? > > I've managed to organize another Beaglebone Black board, and on this one > the image does boot without issues. > It seems that the beaglebone i was developing on the whole time is > defect somehow! I wonder if it is the sd card socket wore out from usage? These are not really high duty cycle things, and why I prefer to actually netboot these types of devices over fooling with sd cards. Though many have crappy network performance, so that leads to other issues :-(. > >> 4. regular FreeBSD Image (non-nanobsd) does boot correctly. > >> > >> I do not have a clue how to further debug this. Since the > >> single-user-mode works, it seems to me that the installation as such is > >> not entirely broken, but there is some hickup in the init procedure. > >> > >> Any ideas? > > > >Well a few corrections above might get you closer, since > >you forced it down the diskless path, which is incorrect. > > Thank you for your tips! Just glad its been found! -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Thu Jan 3 01:41:21 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2528C14388BE; Thu, 3 Jan 2019 01:41:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCB5382FBB; Thu, 3 Jan 2019 01:41:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 51D5311457; Thu, 3 Jan 2019 01:41:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f177.google.com with SMTP id v1-v6so28542784ljd.0; Wed, 02 Jan 2019 17:41:20 -0800 (PST) X-Gm-Message-State: AJcUukfWT9N8dMCGmqn38AmC6tRmV8i4GIuafRdMmA4d/YLGFM85+EG4 WSFa/2SHFx7sWEM6U0Pdg8lknY92v9e4FqF99bQ= X-Google-Smtp-Source: AFSGD/VJMe+L+fDMV1QOWtVKFImtMj9oK/7YxzR6l2A9eNAQEZzYbL+cfIIFZCkJvNdmsv3pbmPNnzFZBOYtZg4EhjM= X-Received: by 2002:a2e:b04f:: with SMTP id d15-v6mr28618253ljl.3.1546479678673; Wed, 02 Jan 2019 17:41:18 -0800 (PST) MIME-Version: 1.0 References: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> In-Reply-To: From: Kyle Evans Date: Wed, 2 Jan 2019 19:41:07 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included] To: Mark Millard Cc: Sean Bruno , freebsd-emulation@freebsd.org, ports-list freebsd , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BCB5382FBB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.969,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-0.998,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: Thu, 03 Jan 2019 01:41:21 -0000 On Wed, Jan 2, 2019 at 3:38 AM Mark Millard via freebsd-ports wrote: > > On 2019-Jan-1, at 18:43, Mark Millard wrote: > > > The below showed up for poudiere-devel bulk getting stuck using one FreeBSD > > cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, unlike > > the last hang-up that I analyzed. I do not yet know how repeatable this is > > but the original hang-up and the one experiment the below is from. > > > > From top: > > > > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME CPU COMMAND > > 12789 root 4 52 0 166M 33M 0 uwait 6 36:06 97.22% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0 > > > > Note: The vast margority of the 36:06 has been stuck in the uwait loop involved. > > > > From ps -auxd: > > > > root 94075 0.0 0.0 12932 3552 1 S+ 10:42 0:01.21 | `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 > > root 1944 0.0 0.0 12932 3540 1 I+ 10:42 0:00.00 | |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 > > root 1957 0.0 0.0 12932 3556 1 I 10:42 0:00.04 | |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (poppler-qt5-0.72.0) (sh) > > root 12328 0.0 0.0 12932 3548 1 I 10:49 0:00.00 | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (poppler-qt5-0.72.0) (sh) > > root 12329 0.0 0.0 10328 1756 1 IJ 10:49 0:00.01 | | `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage > > root 12350 0.0 0.0 9860 1248 1 IJ 10:49 0:00.00 | | `-- /usr/bin/make -f Makefile DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install > > root 12353 0.0 0.0 10236 1664 1 IJ 10:49 0:00.05 | | `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all > > root 12787 0.0 0.0 9856 1236 1 IJ 10:50 0:00.00 | | `-- /nxb-bin/usr/bin/make -f qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test > > root 12789 100.0 0.0 169868 33528 1 IJ 10:50 36:35.26 | | `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/ > > root 94423 0.0 0.0 12932 3484 1 S+ 10:42 0:12.91 | `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w graphics/poppler-qt5 > > > > > > (gdb) attach 12789 > > Attaching to process 12789 > > Reading symbols from /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done. > > [New LWP 101168 of process 12789] > > [New LWP 101178 of process 12789] > > [New LWP 101499 of process 12789] > > [Switching to LWP 100304 of process 12789] > > _umtx_op () at _umtx_op.S:3 > > 3 RSYSCALL(_umtx_op) > > (gdb) info threads > > Id Target Id Frame > > * 1 LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3 > > 2 LWP 101168 of process 12789 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > > 3 LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3 > > 4 LWP 101499 of process 12789 0x0000000060051c26 in atomic_cmpset_int (dst=, expect=, src=536870912) at /usr/include/machine/atomic.h:220 > > (gdb) thread 4 > > [Switching to thread 4 (LWP 101499 of process 12789)] > > #0 0x0000000060051c26 in atomic_cmpset_int (dst=, expect=, src=536870912) at /usr/include/machine/atomic.h:220 > > 220 ATOMIC_CMPSET(int); > > > > (gdb) bt > > #0 0x0000000060051c26 in atomic_cmpset_int (dst=, expect=, src=536870912) at /usr/include/machine/atomic.h:220 > > #1 tcmpset_32 (addr=, a=, b=536870912) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178 > > #2 freebsd_rw_unlock (target_addr=4108246528) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264 > > #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=, op=536870912, val=, uaddr=, target_time=) > > at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474 > > #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, arg1=, arg2=, arg3=, arg4=0, arg5=0, arg6=-184411592, arg7=-199471616, > > arg8=-1622188640) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364 > > #5 0x00000000600392f0 in target_cpu_loop (env=0x86159b118) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/arm/target_arch_cpu.h:207 > > #6 0x0000000060038c99 in cpu_loop (env=0xf4dede80) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/main.c:121 > > #7 0x0000000060050c1a in new_freebsd_thread_start (arg=) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:152 > > #8 0x00000000601ad5f6 in thread_start (curthread=0x861571300) at /usr/src/lib/libthr/thread/thr_create.c:291 > > #9 0x0000000000000000 in ?? () > > Backtrace stopped: Cannot access memory at address 0x7fffdfbb3000 > > > > 181 #define ATOMIC_CMPSET(TYPE) \ > > 182 static __inline int \ > > 183 atomic_cmpset_##TYPE(volatile u_##TYPE *dst, u_##TYPE expect, u_##TYPE src) \ > > 184 { \ > > (gdb) > > 185 u_char res; \ > > 186 \ > > 187 __asm __volatile( \ > > 188 " " MPLOCKED " " \ > > 189 " cmpxchg %3,%1 ; " \ > > 190 " sete %0 ; " \ > > 191 "# atomic_cmpset_" #TYPE " " \ > > 192 : "=q" (res), /* 0 */ \ > > 193 "+m" (*dst), /* 1 */ \ > > 194 "+a" (expect) /* 2 */ \ > > (gdb) > > 195 : "r" (src) /* 3 */ \ > > 196 : "memory", "cc"); \ > > 197 return (res); \ > > 198 } \ > > . . . > > 218 ATOMIC_CMPSET(char); > > 219 ATOMIC_CMPSET(short); > > 220 ATOMIC_CMPSET(int); > > 221 ATOMIC_CMPSET(long); > > > > (gdb) up > > #1 tcmpset_32 (addr=, a=, b=536870912) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178 > > 178 return atomic_cmpset_acq_32(addr, current, new); > > (gdb) list > > 173 static int tcmpset_32(uint32_t *addr, uint32_t a, uint32_t b) > > 174 { > > 175 uint32_t current = tswap32(a); > > 176 uint32_t new = tswap32(b); > > 177 > > 178 return atomic_cmpset_acq_32(addr, current, new); > > 179 } > > > > (gdb) up > > #2 freebsd_rw_unlock (target_addr=4108246528) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264 > > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, (state - 1))) { > > (gdb) list > > 1259 } > > 1260 } > > 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) != 0) { > > 1262 /* decrement reader count */ > > 1263 for (;;) { > > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, (state - 1))) { > > 1265 if (TARGET_URWLOCK_READER_COUNT(state) == 0) { > > 1266 unlock_user_struct(target_urwlock, > > 1267 target_addr, 1); > > 1268 return -TARGET_EPERM; > > (gdb) > > 1269 } > > 1270 } else { > > 1271 break; > > 1272 } > > 1273 } > > 1274 } else { > > 1275 unlock_user_struct(target_urwlock, target_addr, 1); > > 1276 return -TARGET_EPERM; > > 1277 } > > 1278 > > > > The above loop is where the code is stuck looping, using most of the capacity of > > one cpu (as FreeBSD classifies cpus). The value of state is stuck at: > > > > (gdb) print state > > $2 = 536870913 > > > > I'll note that the loop is inside qemu-arm-atatic, not in the cmake that it > > is running. > > > > > > > > To show a little more context before the assembler for the routine that ends up > > containing that loop: > > > > (gdb) up > > #3 0x000000006004ab33 in do_freebsd__umtx_op (obj=, op=536870912, val=, uaddr=, target_time=) > > at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474 > > 474 ret = freebsd_rw_unlock(obj); > > (gdb) list > > 469 ret = freebsd_rw_wrlock(obj, val, 0, NULL); > > 470 } > > 471 break; > > 472 > > 473 case TARGET_UMTX_OP_RW_UNLOCK: > > 474 ret = freebsd_rw_unlock(obj); > > 475 break; > > 476 > > 477 #if defined(__FreeBSD_version) && __FreeBSD_version > 900000 > > 478 #ifdef UMTX_OP_MUTEX_WAKE2 > > > > (gdb) up > > #4 0x0000000060041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, arg1=, arg2=, arg3=, arg4=0, arg5=0, arg6=-184411592, arg7=-199471616, > > arg8=-1622188640) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364 > > 1364 ret = do_freebsd__umtx_op(arg1, arg2, arg3, arg4, arg5); > > (gdb) list > > 1359 ret = do_freebsd__umtx_unlock(arg1); > > 1360 break; > > 1361 #endif > > 1362 > > 1363 case TARGET_FREEBSD_NR__umtx_op: /* undocumented */ > > 1364 ret = do_freebsd__umtx_op(arg1, arg2, arg3, arg4, arg5); > > 1365 break; > > 1366 > > 1367 /* > > 1368 * ioctl(2) > > > > As for the assembler level view for the routine containing the > > loop (via inlining and such): > > > > Dump of assembler code for function freebsd_rw_unlock: > > 0x0000000060051bd0 <+0>: push %rbp > > 0x0000000060051bd1 <+1>: mov %rsp,%rbp > > 0x0000000060051bd4 <+4>: push %rbx > > 0x0000000060051bd5 <+5>: push %rax > > 0x0000000060051bd6 <+6>: mov %edi,%ebx > > 0x0000000060051bd8 <+8>: mov $0x20,%esi > > 0x0000000060051bdd <+13>: mov $0x3,%edx > > 0x0000000060051be2 <+18>: callq 0x60036b70 > > 0x0000000060051be7 <+23>: mov %eax,%ecx > > 0x0000000060051be9 <+25>: mov $0xfffffff2,%eax > > 0x0000000060051bee <+30>: test %ecx,%ecx > > 0x0000000060051bf0 <+32>: jne 0x60051c50 > > 0x0000000060051bf2 <+34>: mov %ebx,%edi > > 0x0000000060051bf4 <+36>: add 0x26a6355(%rip),%rdi # 0x626f7f50 > > 0x0000000060051bfb <+43>: je 0x60051c50 > > 0x0000000060051bfd <+45>: mov (%rdi),%ecx > > 0x0000000060051bff <+47>: mov 0x4(%rdi),%edx > > 0x0000000060051c02 <+50>: test %ecx,%ecx > > 0x0000000060051c04 <+52>: js 0x60051c30 > > 0x0000000060051c06 <+54>: test $0x1fffffff,%ecx > > 0x0000000060051c0c <+60>: je 0x60051c4b > > 0x0000000060051c0e <+62>: lea -0x1(%rcx),%esi > > 0x0000000060051c11 <+65>: nopw %cs:0x0(%rax,%rax,1) > > 0x0000000060051c1b <+75>: nopl 0x0(%rax,%rax,1) > > NOTE: loop is below: > > 0x0000000060051c20 <+80>: mov %ecx,%eax > > => 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) > > 0x0000000060051c26 <+86>: sete %bl > > 0x0000000060051c29 <+89>: test %bl,%bl > > 0x0000000060051c2b <+91>: je 0x60051c20 > > Note: loop is above > > 0x0000000060051c2d <+93>: jmp 0x60051c57 > > 0x0000000060051c2f <+95>: nop > > 0x0000000060051c30 <+96>: mov %ecx,%esi > > 0x0000000060051c32 <+98>: and $0x7fffffff,%esi > > 0x0000000060051c38 <+104>: mov %ecx,%eax > > 0x0000000060051c3a <+106>: lock cmpxchg %esi,(%rdi) > > 0x0000000060051c3e <+110>: sete %bl > > 0x0000000060051c41 <+113>: test %bl,%bl > > 0x0000000060051c43 <+115>: jne 0x60051c57 > > 0x0000000060051c45 <+117>: mov (%rdi),%ecx > > 0x0000000060051c47 <+119>: test %ecx,%ecx > > 0x0000000060051c49 <+121>: js 0x60051c30 > > 0x0000000060051c4b <+123>: mov $0xffffffff,%eax > > 0x0000000060051c50 <+128>: add $0x8,%rsp > > 0x0000000060051c54 <+132>: pop %rbx > > 0x0000000060051c55 <+133>: pop %rbp > > 0x0000000060051c56 <+134>: retq > > 0x0000000060051c57 <+135>: test $0x2,%dl > > 0x0000000060051c5a <+138>: jne 0x60051c70 > > 0x0000000060051c5c <+140>: test $0x40000000,%ecx > > 0x0000000060051c62 <+146>: jne 0x60051c82 > > 0x0000000060051c64 <+148>: xor %eax,%eax > > 0x0000000060051c66 <+150>: test $0x20000000,%ecx > > 0x0000000060051c6c <+156>: je 0x60051c50 > > 0x0000000060051c6e <+158>: jmp 0x60051c89 > > 0x0000000060051c70 <+160>: test $0x20000000,%ecx > > 0x0000000060051c76 <+166>: jne 0x60051c89 > > 0x0000000060051c78 <+168>: xor %eax,%eax > > 0x0000000060051c7a <+170>: test $0x40000000,%ecx > > 0x0000000060051c80 <+176>: je 0x60051c50 > > 0x0000000060051c82 <+178>: mov $0x1,%edx > > 0x0000000060051c87 <+183>: jmp 0x60051c8e > > 0x0000000060051c89 <+185>: mov $0x7fffffff,%edx > > 0x0000000060051c8e <+190>: mov $0x3,%esi > > 0x0000000060051c93 <+195>: xor %ecx,%ecx > > 0x0000000060051c95 <+197>: xor %r8d,%r8d > > 0x0000000060051c98 <+200>: callq 0x601b5970 <_umtx_op> > > 0x0000000060051c9d <+205>: mov %eax,%edi > > 0x0000000060051c9f <+207>: add $0x8,%rsp > > 0x0000000060051ca3 <+211>: pop %rbx > > 0x0000000060051ca4 <+212>: pop %rbp > > --Type for more, q to quit, c to continue without paging-- > > 0x0000000060051ca5 <+213>: jmpq 0x60040a40 > > End of assembler dump. > > > > For just before the "lock cmpxchg %esi,(%rdi)" in the loop: > > > > rax 0x20000001 536870913 > > rbx 0xf4dede00 4108246528 > > rcx 0x20000001 536870913 > > rdx 0x2 2 > > rsi 0x20000000 536870912 > > rdi 0xf4dede80 4108246656 > > > > (gdb) x 0xf4dede80 > > 0xf4dede80: 0x40000001 > > > > 0x0000000060051c20 <+80>: mov %ecx,%eax > > => 0x0000000060051c22 <+82>: lock cmpxchg %esi,(%rdi) > > 0x0000000060051c26 <+86>: sete %bl > > 0x0000000060051c29 <+89>: test %bl,%bl > > 0x0000000060051c2b <+91>: je 0x60051c20 > > > > > > At this point I do not have interpretation of the details, not even > > a comparison to the source code. > > > Note: The problem was observed in building ports head -r488859 's graphics/poppler-qt5 . > > In the below code I've added a missing statement: > > > 1261 } else if (TARGET_URWLOCK_READER_COUNT(state) != 0) { > > 1262 /* decrement reader count */ > > 1263 for (;;) { > > 1264 if (!tcmpset_32(&target_urwlock->rw_state, state, (state - 1))) { > __get_user(state, &target_urwlock->rw_state); > > 1265 if (TARGET_URWLOCK_READER_COUNT(state) == 0) { > > 1266 unlock_user_struct(target_urwlock, > > 1267 target_addr, 1); > > 1268 return -TARGET_EPERM; > > (gdb) > > 1269 } > > 1270 } else { > > 1271 break; > > 1272 } > > 1273 } > > The lack of the update to 'state' is why it was valid for the > compiler to eliminate the code for: > > > 1265 if (TARGET_URWLOCK_READER_COUNT(state) == 0) { > > 1266 unlock_user_struct(target_urwlock, > > 1267 target_addr, 1); > > 1268 return -TARGET_EPERM; > > (gdb) > > 1269 } > > So (without old line numbers): > > } else if (TARGET_URWLOCK_READER_COUNT(state) != 0) { > /* decrement reader count */ > for (;;) { > if (!tcmpset_32(&target_urwlock->rw_state, state, (state - 1))) { > __get_user(state, &target_urwlock->rw_state); > if (TARGET_URWLOCK_READER_COUNT(state) == 0) { > unlock_user_struct(target_urwlock, > target_addr, 1); > return -TARGET_EPERM; > } > } else { > break; > } > } > > This follows the structure of other tcmpset_32 use in the source file. > > With this change poudriere-devel's bulk worked for graphics/poppler-qt5 > as a amd64->armv7 cross-build (FreeBSD head -r341836 based, under Hyper-V, > with 28 logical-processors assigned): > Ah, thanks for that! I think your analysis is correct, and I've created a pull request [1] for Sean. This should fix the apparent hangs reported by many across armv7/aarch64. [1] https://github.com/seanbruno/qemu-bsd-user/pull/72 From owner-freebsd-arm@freebsd.org Thu Jan 3 05:30:04 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA4BF143F478 for ; Thu, 3 Jan 2019 05:30:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-15.consmr.mail.bf2.yahoo.com (sonic315-15.consmr.mail.bf2.yahoo.com [74.6.134.125]) (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 8D5F78A0E6 for ; Thu, 3 Jan 2019 05:30:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5da9pNEVM1nXydlrnwMRYrMLkrSpI3886i6txx1jcS59GvMpCkE6rJmWi7oC6FK wnjMslm.uwAMmjrFI3u1VS44qG1_WKKOLSEx8KGCnnUOivxWL1W8wlZ.U.aKaDk4eg1BPNhlr.AD UZMPbD3RJKkNzvbUdPdosQkOjWhA6Pm6NpCeUIo_pNex58yP5.YQqZwSLAvXN40rfcYZNBh.x5J6 U853A1kseLBL7eVVHjvnBvvkGMhKqSir55LEanC1HdXCLPA5vabxMyW0CmSyTXPjAhLqChaoZjAu idGoNcVLJ7tvqZv8neqBu2F0uQ6oLX40zcZNqDgeHPBxQeyyKix4QTKzihJqEYkYkGbavcKUI0Tt YEDCWYzFKwioTBq1AGGax50UZmq_qACx9au9T7bRo7lMCtUB.qWPYi7Eq1mFVaTWKcOXZpGkWYAs _6hXOzHNwtH56Zd2gGS5MNaxfqynLwXC6niq3GMjI_nmDUJLHWpfT92o4X.lYYsmM98niSntI7aw FqnOVOAh1ZgM7A8lcsMjch4P1dB5g8_56NxMtvCmmFY2n5nhS08VYx.vZcl7U5USi2vth4.wbsip CSE1JkJcjxBxDatOZtiaS_0sxgDZdDZTJPGOcrzsC34sNFcap89wLbePrxSqsPOIRVMVtApqu7kX ntvhuuDtCcwApIgwIGczdufKgyEFto83ZNObhjFpY.XgyuygfjQvkF9_osN3Q5v7EJ3wG94ueT0B 0z.T3cnhP_W_ZqfUrw1nVO5T5Rm1ntX_ePiHtO7xokI.IacckmLPeN2nuuvhLVS5d.sXD3T3Ji_d DD5VeUYTFCqq9G9rRtCi3Q3gO2cb_ws0wQ86OsbZXcfo0LSf3nlL2vhHS4jGINN5Esa_SqFc1Imj TUONF.E9jIVTjHTt471mIUScIa_usW11E4l4mFCR6nbRoQYc1jafKrHxAbsZf6lF_nc1XlVUHC6P KzV6lIkjSvBuGAyQRanbfHeuhJzZ4SgDRv5dbDDD3zAcjLJFv4tomYquZU3v_YEmksFTf_OT9PU1 g6V56RSdgrtYlZL75NCvksJFbxDxPqj3vfVaYHlABzHmTBMt3vGyqMXZqQ_dz4Mxe2z4cjbVzLw- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 3 Jan 2019 05:29:56 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8dd332dbfed0ed5f8c56d879ed05fddf; Thu, 03 Jan 2019 05:29:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included] From: Mark Millard In-Reply-To: Date: Wed, 2 Jan 2019 21:29:53 -0800 Cc: Sean Bruno , freebsd-emulation@freebsd.org, ports-list freebsd , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8EFD9D72-AABD-4AB1-8592-8B78E779F67F@yahoo.com> References: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> To: Kyle Evans X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 8D5F78A0E6 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.07 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.78)[0.781,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.49)[ip: (4.88), ipnet: 74.6.128.0/21(1.49), asn: 26101(1.19), country: US(-0.08)]; NEURAL_SPAM_MEDIUM(0.72)[0.720,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.58)[0.582,0]; RCVD_IN_DNSWL_NONE(0.00)[125.134.6.74.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[125.134.6.74.rep.mailspike.net : 127.0.0.17] 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, 03 Jan 2019 05:30:04 -0000 On 2019-Jan-2, at 17:41, Kyle Evans wrote: > On Wed, Jan 2, 2019 at 3:38 AM Mark Millard via freebsd-ports > wrote: >>=20 >>> . . . >>=20 >> So (without old line numbers): >>=20 >> } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) { >> /* decrement reader count */ >> for (;;) { >> if (!tcmpset_32(&target_urwlock->rw_state, state, (state = - 1))) { >> __get_user(state, &target_urwlock->rw_state); >> if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) { >> unlock_user_struct(target_urwlock, >> target_addr, 1); >> return -TARGET_EPERM; >> } >> } else { >> break; >> } >> } >>=20 >> This follows the structure of other tcmpset_32 use in the source = file. >>=20 >> With this change poudriere-devel's bulk worked for = graphics/poppler-qt5 >> as a amd64->armv7 cross-build (FreeBSD head -r341836 based, under = Hyper-V, >> with 28 logical-processors assigned): >>=20 >=20 > Ah, thanks for that! I think your analysis is correct, and I've > created a pull request [1] for Sean. This should fix the apparent > hangs reported by many across armv7/aarch64. >=20 > [1] https://github.com/seanbruno/qemu-bsd-user/pull/72 There is also the issue that the __packed use for target_freebsd_kevent and target_freebsd11_kevent cause the wrong size and field offsets for armv7 (and armv6) when translating to or from the host (amd64) struct kevent vs. the target struct kevent. These hangs show up as in the kqread state or other such implying kevent is hung-up, unlike for the above. I'm using the following for now: > struct target_freebsd11_kevent { > abi_ulong ident; > int16_t filter; > uint16_t flags; > uint32_t fflags; > abi_long data; > abi_ulong udata; > } ; // __packed; >=20 > struct target_freebsd_kevent { > abi_ulong ident; > int16_t filter; > uint16_t flags; > uint32_t fflags; > int64_t data; > abi_ulong udata; > uint64_t ext[4]; > } ; // __packed; With these I was finally able to build lumina for armv7 via a cross-build (amd64->armv7). Sean is aware of this. However, I still get other hang-ups for targeting aarch64. I've started trying to gather evidence for the one I currently get. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jan 3 09:25:34 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFBAA1422040 for ; Thu, 3 Jan 2019 09:25:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-10.consmr.mail.ne1.yahoo.com (sonic308-10.consmr.mail.ne1.yahoo.com [66.163.187.33]) (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 CD39B6BAF1 for ; Thu, 3 Jan 2019 09:25:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: A3.moPAVM1kRZpCBbKh8mEmWkGJygBBJGnS5Y6_9lxYMa5tsRMD9lLTEYaS5G9g QMmOIerjKI8cxpll4aQEOpzqRbFVy4hoZPDYlXhtfeOY4tQgxrhiF4Lrr3U8NoFQLQwxG6pd5pp3 FEDCgiLrd_itW47NZsxDm6p8lqM1IH.cwqE3TT64peQMN6FSEeJNtvRK1CJZf7bO2vc_g8yXbhFz crgOqmYpfV6lAQr3jO7HM2TJBpbY550cS9ex8ZDaxD7Rhs5AOJmXNnyg7Xl7q4vqa0NEJB9guF8Q f8GQQqsu1KmQrybYhezfPrK1jlFmUfE4rN_aT.t90Wd9yLaF1x5sPoUvHWCqZVbsGPQEyH1L.V6A .yUcRK8T6Ko9hEpV6Hgibupe4br26A0IsgiesR.Za.jhkOUnrCfUP0.tT6EwQNmlH8vALt0szP.p 1C4vTGqFYkmzCfbGxLe9f1S8ZcYk.jUO1QDYxpf8wG_wbXITBqaWYddYzy1FtPMDVivTEfvPRW8p JdPn9LS3_Vtg7MEIrsQjx4mBGp5x7gzNAHp1A2veo3PXJWbWOlQu3zETHzNGBmV5WRuSwqIyMf3j adjDzOmdMeZIZ8cPWN_2yF0PRpbDfXket3k20Yd45l0pyJ1D3OzvKMf_OmMOB00HjHeemyPV6jpa MvjokmO4hrfOP6VMllk0jvhy8YBpH6H70D7yW61eF0Cin_SdEJ88g7zXpVeFGSiATpbOrTgSYLMC GxNaXSb9fWgnwQm72cX0Gw.mCVIcMfshVJe4Tms3YN50QMUL.nSxlQuwY7.GcUN3V7Tn9W0HUjUE gjfU3jNowTCg51gJIMnqD0gFlE4KHFaWAHjuFysksJcjTm_lWYuFjq5WEUQeUWgnTftYtIr1KL_v 4SHM1EvZ0AxZcpKVHhK8XDbmEuwEOV2pOCBEe98S_J9Gl6Fa278epFevje2ufJlc0wPAdaWzmC_z I.tcjYm3XbUtSZi.tGt1SiYLXijBSJbDo.Yoh3ccueZwbbFbjD6Jip7aDhWkq9wObvpM8QqZ89Lb dVZH_rVuts_neNipjSmR9hXE2qsTH7A7PXNNP.J5waLqfLgRVc0otlUh_LociA9Ke5TvsIo4vmDe hnsd0Fg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Thu, 3 Jan 2019 09:25:27 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp402.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b8f2f43454d6314b563298e05f0013d4; Thu, 03 Jan 2019 09:25:25 +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 12.2 \(3445.102.3\)) Subject: Under qemu-aarch64-static "wc /dev/null" gets "Unsupported ancillary data: 1/0" from a sendmsg attempt: because of wrong cmsg_len type in target_cmsghdr Message-Id: <22184643-4320-4B7C-86DA-A71DF62D4543@yahoo.com> Date: Thu, 3 Jan 2019 01:25:23 -0800 Cc: freebsd-arm To: Kyle Evans , freebsd-emulation@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: CD39B6BAF1 X-Spamd-Bar: + X-Spamd-Result: default: False [2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.80)[0.801,0]; NEURAL_HAM_LONG(-0.01)[-0.012,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.22)[ip: (4.20), ipnet: 66.163.184.0/21(1.11), asn: 36646(0.88), country: US(-0.08)]; NEURAL_SPAM_MEDIUM(0.50)[0.497,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[33.187.163.66.list.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: Thu, 03 Jan 2019 09:25:35 -0000 [This note follows the investigation sequence, ending with the important conclusions.] My test context here is a poudriere-devel bulk -i for a amd64->aarch64 context. wc /dev/null or wc //dev/null does: # wc /dev/null Unsupported ancillary data: 1/0 that then hangs-up until I ^C to get back to a prompt. Here is what ktrace/kdump shows the process before the hang through when I hit ^C to stop the hang-up: . . . 98475 101033 qemu-aarch64-static 0.000340 CALL = sigprocmask[340](SIG_BLOCK,0x7ffffffe3c80,0x7ffffffe3d80) 98475 101033 qemu-aarch64-static 0.000003 RET sigprocmask[340] 0 98475 101033 qemu-aarch64-static 0.000001 CALL = pselect[522](0x6,0,0x7ffffffe3fb0,0,0,0x7ffffffe3d80) 98475 101033 qemu-aarch64-static 0.000001 RET pselect[522] 1 98475 101033 qemu-aarch64-static 0.000001 CALL = sigprocmask[340](SIG_SETMASK,0x7ffffffe3c80,0) 98475 101033 qemu-aarch64-static 0.000001 RET sigprocmask[340] 0 98475 101033 qemu-aarch64-static 0.000042 CALL = write[4](0x2,0x7ffffffe3480,0x20) 98475 101033 qemu-aarch64-static 0.000036 GIO fd 2 wrote 32 bytes "Unsupported ancillary data: 1/0 " 98475 101033 qemu-aarch64-static 0.000003 RET write[4] 32/0x20 98475 101033 qemu-aarch64-static 0.000001 CALL = sendmsg[28](0x5,0x7ffffffe3c28,0) 98475 101033 qemu-aarch64-static 0.000003 RET sendmsg[28] -1 errno 22 = Invalid argument 98475 101033 qemu-aarch64-static 0.000184 CALL close[6](0x3) 98475 101033 qemu-aarch64-static 0.000040 RET close[6] 0 98475 101033 qemu-aarch64-static 0.000017 CALL close[6](0x7) 98475 101033 qemu-aarch64-static 0.000005 RET close[6] 0 98475 101033 qemu-aarch64-static 0.000002 CALL = sigprocmask[340](SIG_BLOCK,0x7ffffffe3c80,0x7ffffffe3d80) 98475 101033 qemu-aarch64-static 0.000001 RET sigprocmask[340] 0 98475 101033 qemu-aarch64-static 0.000001 CALL = pselect[522](0x6,0x7ffffffe3dd0,0,0,0,0x7ffffffe3d80) 98475 101539 qemu-aarch64-static 0.000089 RET nanosleep[240] 0 98475 101539 qemu-aarch64-static 0.000042 CALL = _umtx_op[454](0x86101f008,UMTX_OP_WAIT_UINT_PRIVATE,0,0,0) 98475 101033 qemu-aarch64-static 15.845396 RET pselect[522] -1 errno = 4 Interrupted system call Note the qemu-aarch64 genrated message and the later: sendmsg[28] -1 errno 22 Invalid argument The qemu-*-static code that wrote the message is from t2h_freebsd_cmsg and is: if ((cmsg->cmsg_level =3D=3D TARGET_SOL_SOCKET) && (cmsg->cmsg_type =3D=3D SCM_RIGHTS)) { int *fd =3D (int *)data; int *target_fd =3D (int *)target_data; int i, numfds =3D len / sizeof(int); for (i =3D 0; i < numfds; i++) { fd[i] =3D tswap32(target_fd[i]); } } else if ((cmsg->cmsg_level =3D=3D TARGET_SOL_SOCKET) && (cmsg->cmsg_type =3D=3D SCM_TIMESTAMP) && (len =3D=3D sizeof(struct timeval))) { /* copy struct timeval to host */ struct timeval *tv =3D (struct timeval *)data; struct target_freebsd_timeval *target_tv =3D (struct target_freebsd_timeval *)target_data; __get_user(tv->tv_sec, &target_tv->tv_sec); __get_user(tv->tv_usec, &target_tv->tv_usec); } else { gemu_log("Unsupported ancillary data: %d/%d\n", cmsg->cmsg_level, cmsg->cmsg_type); memcpy(data, target_data, len); } =20 Well it turns out that qemu_*-static 's code has: struct target_cmsghdr { abi_long cmsg_len; int32_t cmsg_level; int32_t cmsg_type; }; where for amd64 target_cmsghdr has: (gdb) p/d sizeof(struct target_cmsghdr) $2 =3D 16 (gdb) p/d sizeof(((struct target_cmsghdr *)0)->cmsg_len)=20 $5 =3D 8 (gdb) p/d &((struct target_cmsghdr *)0)->cmsg_level $4 =3D 8 (gdb) p/d &((struct target_cmsghdr *)0)->cmsg_type=20 $1 =3D 12 which does not match the amd64 or aarch64 native: struct cmsghdr { socklen_t cmsg_len; /* data byte count, = including hdr */ int cmsg_level; /* originating protocol = */ int cmsg_type; /* protocol-specific = type */ /* followed by u_char cmsg_data[]; */ }; =20 because the cmsghdr's cmsg_len is smaller, even on a 64-bit = architecture: (gdb) p/d sizeof(((struct cmsghdr *)0)->cmsg_len) $6 =3D 4 /usr/include/arpa/inet.h:typedef __socklen_t socklen_t; /usr/include/netinet/in.h:typedef __socklen_t socklen_t; /usr/include/netinet6/in6.h:typedef __socklen_t socklen_t; /usr/include/sys/_types.h:typedef __uint32_t __socklen_t; /usr/include/sys/socket.h:typedef __socklen_t socklen_t; . . . /usr/include/netdb.h:typedef __socklen_t socklen_t; so abi_long does not match socklen_t for 64-bit architectures. So code such as in t2h_freebsd_cmsg: cmsg->cmsg_level =3D tswap32(target_cmsg->cmsg_level); cmsg->cmsg_type =3D tswap32(target_cmsg->cmsg_type); is not using the correct target offsets when aarch64 is the target that it is extracting from (for example). For comparison on a 64-bit architecture: (gdb) p/d sizeof(struct cmsghdr) $1 =3D 12 (gdb) p/d &((struct cmsghdr *)0)->cmsg_level $2 =3D 4 (gdb) p/d &((struct cmsghdr *)0)->cmsg_type=20 $3 =3D 8 I do not yet have a tested change. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jan 3 10:06:58 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13AE414234EC for ; Thu, 3 Jan 2019 10:06:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-3.consmr.mail.bf2.yahoo.com (sonic301-3.consmr.mail.bf2.yahoo.com [74.6.129.42]) (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 E69C06DCF2 for ; Thu, 3 Jan 2019 10:06:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 7ood0GYVM1lSeOFmgC1s1hlM8tzFFMRcYIDJ7P3KPG0CMGHRpi32PWOcUt18enQ dClTYGeNWjl5NxLd.w6sK61tZVKenkajbbhvYmCKhcJw0LKxjdou_QQ6llHg5OpV1z1e8chmkV3A aal1TSp_QzvP6lfpklrk28Wn_Dxzwp6A_QYnq69O2xkNB2bJ3M5p8GMR3hQ1.oPfh3tHr8n8XLbW m6JcjEz9Uhp8IWaFJwcm7Hkv8wz8hyOcXFiMFbcQXKcY.m0QRNnnn.4W2DPKpa6UhzlS6gqV34oS XNQCwJ3yVzpxeHLDrP4XuoolJlIqzNRqIdORGk.0cNMTbNLCNKCNEkf7f7KHWdSv3NW0buz26c56 gxs_oLpdMf6Ons1OS_.O9joaAARO87nwYlx3wH5S05ew40FASH1rMvBuhf9d7fEnWCprTDmLh91y eYgdAZI7Ps9_6pk9zZi5SY5UhbnwrSE5qNxj1NEPranFw1KnSjY8WW6C3ZVOGw.9wAEt0tK7UxVx mWDhhLqGWm5WOetuu2pW62T0e7jK5PA1MFEQTMU0XWfWs3t8lY6rh.HQoIlxlx9ME4FOZoO6LW.q jqIGoREaXin4BlHgbBYEAvQ3vn9qKgAZqhRhdErM4t8tBU4nwi.ZJDdPtq9mPwLrm7b4IlarLzZO Voma1jUuTnHzvwKJIs0pxHNOoL699Qq1fKNUnF8nqH_RabkBOeqgUYY0LzQ8bZWj2Xa6CkGHhH0u joAiN.yj__HBqJN0gZERV4HI3ReBnFsd8TVueNKZcELjfm3GxkCr9Rn73huzBZw4RclHn9mAXzU3 Th0GY3hiK3mv6msSpCTHc0LiOIauwRDDI58eupm5vjiQQVBFA1O7XD_EApfr1AUblFdDcsJSACwG NaLh0hyeUs6KIaDmOW98oOxQV90woD3DBbplOCkYSPUTk7f7r000smD4.0R8G9rNwDBf_9pX9M12 UCja4DyJxNqS4tEbCsLJl2SYbsJB_NzoztV9_MkvcOUSCmMPEOzzIrRhzt203sl4ttt6L8hDqXq0 qu_oGR9qrPohzX77A8evXxTP6CsypwrfQcCgXyrpcYMLoe8wLMKr8LM1pcKQdSjMKfZ7uNzQ_Bu_ sU1dRcQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Thu, 3 Jan 2019 10:06:55 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e2e1ad36aec9e258eee1043557fc3499; Thu, 03 Jan 2019 10:06:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Under qemu-aarch64-static "wc /dev/null" gets "Unsupported ancillary data: 1/0" from a sendmsg attempt: because of wrong cmsg_len type in target_cmsghdr From: Mark Millard In-Reply-To: <22184643-4320-4B7C-86DA-A71DF62D4543@yahoo.com> Date: Thu, 3 Jan 2019 02:06:51 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <22184643-4320-4B7C-86DA-A71DF62D4543@yahoo.com> To: Kyle Evans , freebsd-emulation@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: E69C06DCF2 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.84 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.96)[0.957,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.43)[ip: (4.52), ipnet: 74.6.128.0/21(1.49), asn: 26101(1.19), country: US(-0.08)]; NEURAL_SPAM_MEDIUM(0.64)[0.643,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.32)[0.322,0]; RCVD_IN_DNSWL_NONE(0.00)[42.129.6.74.list.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: Thu, 03 Jan 2019 10:06:58 -0000 [Adding a for-reference note.] On 2019-Jan-3, at 01:25, Mark Millard wrote: > [This note follows the investigation sequence, > ending with the important conclusions.] >=20 > My test context here is a poudriere-devel bulk -i for a > amd64->aarch64 context. >=20 > wc /dev/null or wc //dev/null does: >=20 > # wc /dev/null > Unsupported ancillary data: 1/0 >=20 > that then hangs-up until I ^C to get back to a prompt. >=20 >=20 > Here is what ktrace/kdump shows the process before the hang through > when I hit ^C to stop the hang-up: >=20 > . . . > 98475 101033 qemu-aarch64-static 0.000340 CALL = sigprocmask[340](SIG_BLOCK,0x7ffffffe3c80,0x7ffffffe3d80) > 98475 101033 qemu-aarch64-static 0.000003 RET sigprocmask[340] 0 > 98475 101033 qemu-aarch64-static 0.000001 CALL = pselect[522](0x6,0,0x7ffffffe3fb0,0,0,0x7ffffffe3d80) > 98475 101033 qemu-aarch64-static 0.000001 RET pselect[522] 1 > 98475 101033 qemu-aarch64-static 0.000001 CALL = sigprocmask[340](SIG_SETMASK,0x7ffffffe3c80,0) > 98475 101033 qemu-aarch64-static 0.000001 RET sigprocmask[340] 0 > 98475 101033 qemu-aarch64-static 0.000042 CALL = write[4](0x2,0x7ffffffe3480,0x20) > 98475 101033 qemu-aarch64-static 0.000036 GIO fd 2 wrote 32 bytes > "Unsupported ancillary data: 1/0 > " > 98475 101033 qemu-aarch64-static 0.000003 RET write[4] 32/0x20 > 98475 101033 qemu-aarch64-static 0.000001 CALL = sendmsg[28](0x5,0x7ffffffe3c28,0) > 98475 101033 qemu-aarch64-static 0.000003 RET sendmsg[28] -1 errno = 22 Invalid argument > 98475 101033 qemu-aarch64-static 0.000184 CALL close[6](0x3) > 98475 101033 qemu-aarch64-static 0.000040 RET close[6] 0 > 98475 101033 qemu-aarch64-static 0.000017 CALL close[6](0x7) > 98475 101033 qemu-aarch64-static 0.000005 RET close[6] 0 > 98475 101033 qemu-aarch64-static 0.000002 CALL = sigprocmask[340](SIG_BLOCK,0x7ffffffe3c80,0x7ffffffe3d80) > 98475 101033 qemu-aarch64-static 0.000001 RET sigprocmask[340] 0 > 98475 101033 qemu-aarch64-static 0.000001 CALL = pselect[522](0x6,0x7ffffffe3dd0,0,0,0,0x7ffffffe3d80) > 98475 101539 qemu-aarch64-static 0.000089 RET nanosleep[240] 0 > 98475 101539 qemu-aarch64-static 0.000042 CALL = _umtx_op[454](0x86101f008,UMTX_OP_WAIT_UINT_PRIVATE,0,0,0) > 98475 101033 qemu-aarch64-static 15.845396 RET pselect[522] -1 errno = 4 Interrupted system call >=20 > Note the qemu-aarch64 genrated message and the later: > sendmsg[28] -1 errno 22 Invalid argument >=20 > The qemu-*-static code that wrote the message is from > t2h_freebsd_cmsg and is: >=20 > if ((cmsg->cmsg_level =3D=3D TARGET_SOL_SOCKET) && > (cmsg->cmsg_type =3D=3D SCM_RIGHTS)) { > int *fd =3D (int *)data; > int *target_fd =3D (int *)target_data; > int i, numfds =3D len / sizeof(int); >=20 > for (i =3D 0; i < numfds; i++) { > fd[i] =3D tswap32(target_fd[i]); > } > } else if ((cmsg->cmsg_level =3D=3D TARGET_SOL_SOCKET) && > (cmsg->cmsg_type =3D=3D SCM_TIMESTAMP) && > (len =3D=3D sizeof(struct timeval))) { > /* copy struct timeval to host */ > struct timeval *tv =3D (struct timeval *)data; > struct target_freebsd_timeval *target_tv =3D > (struct target_freebsd_timeval *)target_data; > __get_user(tv->tv_sec, &target_tv->tv_sec); > __get_user(tv->tv_usec, &target_tv->tv_usec); > } else { > gemu_log("Unsupported ancillary data: %d/%d\n", > cmsg->cmsg_level, cmsg->cmsg_type); > memcpy(data, target_data, len); > } >=20 > Well it turns out that qemu_*-static 's code has: >=20 > struct target_cmsghdr { > abi_long cmsg_len; > int32_t cmsg_level; > int32_t cmsg_type; > }; >=20 > where for amd64 target_cmsghdr has: >=20 > (gdb) p/d sizeof(struct target_cmsghdr) > $2 =3D 16 > (gdb) p/d sizeof(((struct target_cmsghdr *)0)->cmsg_len)=20 > $5 =3D 8 > (gdb) p/d &((struct target_cmsghdr *)0)->cmsg_level > $4 =3D 8 > (gdb) p/d &((struct target_cmsghdr *)0)->cmsg_type=20 > $1 =3D 12 >=20 > which does not match the amd64 or aarch64 native: >=20 > struct cmsghdr { > socklen_t cmsg_len; /* data byte count, = including hdr */ > int cmsg_level; /* originating protocol = */ > int cmsg_type; /* protocol-specific = type */ > /* followed by u_char cmsg_data[]; */ > }; =20 >=20 > because the cmsghdr's cmsg_len is smaller, even on a 64-bit = architecture: >=20 > (gdb) p/d sizeof(((struct cmsghdr *)0)->cmsg_len) > $6 =3D 4 >=20 > /usr/include/arpa/inet.h:typedef __socklen_t socklen_t; > /usr/include/netinet/in.h:typedef __socklen_t socklen_t; > /usr/include/netinet6/in6.h:typedef __socklen_t socklen_t; > /usr/include/sys/_types.h:typedef __uint32_t __socklen_t; > /usr/include/sys/socket.h:typedef __socklen_t socklen_t; > . . . > /usr/include/netdb.h:typedef __socklen_t socklen_t; >=20 > so abi_long does not match socklen_t for 64-bit architectures. >=20 > So code such as in t2h_freebsd_cmsg: >=20 > cmsg->cmsg_level =3D tswap32(target_cmsg->cmsg_level); > cmsg->cmsg_type =3D tswap32(target_cmsg->cmsg_type); >=20 > is not using the correct target offsets when aarch64 is the target > that it is extracting from (for example). >=20 > For comparison on a 64-bit architecture: >=20 > (gdb) p/d sizeof(struct cmsghdr) > $1 =3D 12 > (gdb) p/d &((struct cmsghdr *)0)->cmsg_level > $2 =3D 4 > (gdb) p/d &((struct cmsghdr *)0)->cmsg_type=20 > $3 =3D 8 >=20 >=20 > I do not yet have a tested change. >=20 On aarch64 (like on amd64): # more cmsghdr_size_offsets.c=20 #include "/usr/include/sys/socket.h" // cmsghdr #include // offsetof #include // printf int main() { printf("%lu\n", (unsigned long) sizeof(struct cmsghdr)); printf("cmsg_len %lu\n", (unsigned long) offsetof(struct = cmsghdr, cmsg_len)); printf("cmsg_level %lu\n", (unsigned long) offsetof(struct = cmsghdr, cmsg_level)); printf("cmsg_type %lu\n", (unsigned long) offsetof(struct = cmsghdr, cmsg_type)); return 0; } produces: # ./a.out 12 cmsg_len 0 cmsg_level 4 cmsg_type 8 which qemu-aarch64-static 's target_cmsghdr definitely does not match. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jan 3 11:26:34 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 329F41425617; Thu, 3 Jan 2019 11:26:34 +0000 (UTC) (envelope-from audioone.official@gmail.com) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27CB6708FD; Thu, 3 Jan 2019 11:26:33 +0000 (UTC) (envelope-from audioone.official@gmail.com) Received: by mail-it1-x12e.google.com with SMTP id c9so42283780itj.1; Thu, 03 Jan 2019 03:26:33 -0800 (PST) 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=0O5Rnfmy9jSGRcXPXOjA0I7PpHDTinonI93RvV9xRa4=; b=TDYNlpvsaV3ngwgjw1+LQfMGRo8r15MTsFUsnZYMXMWTzPw1Umy+bAw9JUEkmDVtHS gYBosUhgxpeG0XQmfnMYZPAq40yhENnFj9LU0i6lZYBVYIIGuWMNiEAtca2a22InGwly 85SmEwSaZa9pLuZTwbpUbtBiIPY9tNmiHPG581ielAny0dYG51J9+HS43nvODEnQ2Fjh HgQtu211WHh94Er0y/KxGywKavMivtyYqdpYXR1oRXEzgdbNqG3RfsMfrP+3I4WdFHED i2MOGi/L7j3pncwitpiugtjbIkPqgtNq+PEqgRUm5D0iXnBKyJ3HSoRglpaMTiJU9P/K Vafg== 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=0O5Rnfmy9jSGRcXPXOjA0I7PpHDTinonI93RvV9xRa4=; b=KSmLlmIQIhYAhNp42rTw4TyWQ7ECPkUTscwXgJOLr/Oqv9k5EBU/gB7UCtECZpkbOZ b70P/uqBJhT5qUpnMIlx0CndXyLCQRQ+Xs733HDJynuA8jj+4opAvn6aUZCW+uF6M0hp +DwyfOXENLYUdMFx/R8YG5q6vshdyNxXJ3aXC6aNbg5FiLnIdwGWE66+IXJos8Bcix5M QtrjD++nAP4ePoUbJzbZRVLinXdj8q5TVZvFiKj/a5M3OaFW5D6an/1utaai125OCAKr OnM6JwqqUUghKZo/12pUDEH3kYaJ+YVddtzkwmaLnlzDyBVBTxAPJ1La0ZSoIS4dD/h3 d++w== X-Gm-Message-State: AA+aEWbh3oK/TYNGcJNAxiZYsA3rtb1s5Pty8kd7cKqUjNzci2z7+U4W riOtq7XrqDLPpNsb88sOEV+Amtk0mmLkGOsLvDeaDsuv X-Google-Smtp-Source: AFSGD/VVo9y+mFwQUxQAQkNAV8ddYecGSywZ3rLLLFh+YzZzAXq6QALQXx1SKS8IQGjNHz3DwoDYUNAcZV9/1sAOHtU= X-Received: by 2002:a02:1bc5:: with SMTP id 66mr33167547jas.105.1546514792002; Thu, 03 Jan 2019 03:26:32 -0800 (PST) MIME-Version: 1.0 From: AudioONE Date: Thu, 3 Jan 2019 19:27:04 +0800 Message-ID: Subject: i.MX6 DualLite stuck at early boot To: freebsd-ports@freebsd.org, freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 27CB6708FD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=TDYNlpvs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of audiooneofficial@gmail.com designates 2607:f8b0:4864:20::12e as permitted sender) smtp.mailfrom=audiooneofficial@gmail.com X-Spamd-Result: default: False [-6.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,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]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[e.2.1.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]; NEURAL_HAM_SHORT(-0.94)[-0.942,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; IP_SCORE(-2.52)[ip: (-8.77), ipnet: 2607:f8b0::/32(-2.13), asn: 15169(-1.64), country: US(-0.08)]; 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: Thu, 03 Jan 2019 11:26:35 -0000 okay....... after days and days mind storm(mind fuck), finally, I can enter DDB, here is what I did in [reinit_mmu], maybe can help someone. ============================== ASENTRY_NP(reinit_mmu) push {r4-r11, lr} mov r4, r0 mov r5, r1 mov r6, r2 + /* Only for Cortex-A9 Errdata Fix */ + mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register + orr r0, r0, #1 << 4 @ set bit #4 + orr r0, r0, #1 << 6 @ set bit #6 + orr r0, r0, #1 << 11 @ set bit #11 + orr r0, r0, #1 << 21 @ set bit #21 + mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register + DSB + ISB . . . . #else bl dcache_inv_pou_all #endif mcr CP15_ICIALLU + mcr CP15_TLBIALL /* Flush TLB */ + mcr CP15_BPIALL /* Flush Branch predictor */ DSB ISB /* Set auxiliary register */ mrc CP15_ACTLR(r7) . . . END(reinit_mmu) ============================== my new problem is OS panic at same address "FAR=0000ec10"(after reset the eval-board many times), what does it mean? something wrong with FDT? I use wandboard-dual dts file(1 GB memory) U-Boot 2016.05 (Dec 31 2018 - 22:57:28 +0800) CPU: Freescale i.MX6DL rev1.2 at 792 MHz Reset cause: POR Board: MX6DL-Armadillo2 DRAM: 1 GiB WARNING: Caches not enabled MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FEC Error: FEC address not set. Hit any key to stop autoboot: 0 reading tarker ** Unable to read file tarker ** reading tmpker ** Unable to read file tmpker ** Booting BSD loader reading ubldr.bin 185536 bytes read in 40 ms (4.4 MiB/s) ## Starting application at 0x12000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x4fd703e0 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@freebsd-x250, Sat Dec 15 17:17:42 HKT 2018) DRAM: 1024MB Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Booting from disk0s2: / /boot/kernel/kernel data=0x580b24+0xb74dc - Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Kernel entry at 0x0x12200100... Kernel args: (null) initarm: console initialized arg1 kmdp = 0xc2639000 boothowto = 0x00000000 dtbp = 0xc254af08 lastaddr1: 0x1283a000 loader passed (static) kenv: loader_envp = 0xc2638000 c2638000 LINES=24 c2638009 console=uboot c2638017 currdev=disk0s2: c2638028 kerflag= c2638031 kernelname=/boot/kernel/kernel c2638050 loaddev=disk0s2: c2638061 prompt=loader> c2638070 twiddle_divisor=1 imx_wdog_init_last_reset ARM Debug Architecture v7 4 watchpoints and 6 breakpoints supported KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-RELEASE-p1 #180 r309528M: Thu Jan 3 10:42:45 HKT 2019 root@4160059805-freebsd-xeon:/mnt/dev/bsdbuild/arm.armv6/mnt/dev/11/sys/IMX6 arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. subsystem 1000000 0xc23e0b88(0)... Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc2713d18 FSR=00000005, FAR=0000ec10, spsr=600000d3 r0 =12998000, r1 =c2ffc010, r2 =00000001, r3 =c261c07c r4 =00000006, r5 =c261c074, r6 =00000000, r7 =2a600000 r8 =c2ffc059, r9 =00000000, r10=c260ba28, r11=c2713dd8 r12=c2ffc014, ssp=c2713da8, slr=0000ec10, pc =c23fa450 [ thread pid 0 tid 0 ] Stopped at 0xc23fa450 db> bt Tracing pid 0 tid 0 td 0xc2617190 KDB: reentering KDB: stack backtrace: KDB: reentering KDB: stack backtrace: blahblahblah..... blahblahblah..... blahblahblah..... blahblahblah..... KDB: reentering KDB: stack backtrace: KDB: reentering KDB: stack backtrace: panic: pmap_fault: pm_pt1 abort cpuid = 0 Uptime: 1s > hi guys > > I've got a small brand eval-board which built with MCIMX6U6AVM08AC and running FreeBSD 11.0.1(I have tried HEAD version, 12.0-BETA3, it didn't work too), ubldr stage is fine but it stucked at "reinit_mmu" function(FreeBSD might be have assembly printf for debug environment, because aseeembly code just like a blackbox when you without JTAG debugger in hand ) > > ====================================== > Booting from disk0s2: > / > /boot/kernel/kernel data=0x57b564+0x58a9c syms=[0x4+0x6e9d0+0x4+0x77ada] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Kernel entry at 0x0x12200100... > Kernel args: (null) > EARL_DEBUG: pmap_kern_ttb 0x1290004a, actlr_mask 0xc1, actlr_set 0x41 > (nothing) > ====================================== > > > > when I trace the code to "reinit_mmu" function, commented code like this, kernel panic and reported "Asynchronous External Abort". Am I the only one who meet this WEIRD case? I got AM3352/AM3354/Zynq7 platforms, they works fine with kernel 11.0.1. Is it something different between i.MX6 Dual(Wandboard) and i.MX6 DualLite? > > /* Enable caches. */ > mrc CP15_SCTLR(r7) > // it will be stucked if don't commented this code > /* orr r7, #CPU_CONTROL_DC_ENABLE //DEBUG > orr r7, #CPU_CONTROL_IC_ENABLE //DEBUG > orr r7, #CPU_CONTROL_BPRD_ENABLE //DEBUG */ > mcr CP15_SCTLR(r7) > DSB > > mcr CP15_TTBR0(r4) /* Set new TTB */ > DSB > ISB > > // it will be stucked if don't commented this code > /* mcr CP15_TLBIALL /// Flush TLB //DEBUG */ > mcr CP15_BPIALL /* Flush Branch predictor */ > DSB > ISB > > > > > U-Boot 2016.05 (Dec 16 2018 - 13:09:25 +0800) > > CPU: Freescale i.MX6DL rev1.2 at 792 MHz > Reset cause: POR > Board: MX6DL-Armadillo2 > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: FSL_SDHC: 0 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: FEC > Error: FEC address not set. > > Hit any key to stop autoboot: 0 > reading ubldr.bin > 185536 bytes read in 40 ms (4.4 MiB/s) > ## Starting application at 0x12000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x4fd703e0 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@freebsd-x250, Sat Dec 15 17:17:42 HKT 2018) > > DRAM: 1024MB > Number of U-Boot devices: 2 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=... good. > Booting from disk0s2: > / > /boot/kernel/kernel data=0x57b564+0x58a9c syms=[0x4+0x6e9d0+0x4+0x77ada] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Kernel entry at 0x0x12200100... > Kernel args: (null) > EARL_DEBUG: pmap_kern_ttb 0x1290004a, actlr_mask 0xc1, actlr_set 0x41 > EARL_DEBUG: cpu_setup pass > EARL_DEBUG: init_param1 pass > initarm: console initialized > arg1 kmdp = 0xc26bc000 > boothowto = 0x00000000 > dtbp = 0xc2547eb8 > lastaddr1: 0x128bd000 > loader passed (static) kenv: > loader_envp = 0xc26bb000 > c26bb000 LINES=24 > c26bb009 console=uboot > c26bb017 currdev=disk0s2: > c26bb028 kerflag= > c26bb031 kernelname=/boot/kernel/kernel > c26bb050 loaddev=disk0s2: > c26bb061 prompt=loader> > c26bb070 twiddle_divisor=1 > EARL_DEBUG: platform_late_init pass > Fatal kernel mode data abort: 'Asynchronous External Abort' on write > trapframe: 0xc257c688 > FSR=00001c06, FAR=Invalid, spsr=600000d3 > r0 =00000100, r1 =600001d3, r2 =600000d3, r3 =30c52079 > r4 =00000000, r5 =c257c7e4, r6 =c25b3280, r7 =c25b3280 > r8 =c2578058, r9 =00000000, r10=c25ce154, r11=c257c7d8 > r12=c2577c24, ssp=c257c718, slr=c244b3c0, pc =c244b3d4 > > panic: Fatal abort > cpuid = 0 > Uptime: 1s From owner-freebsd-arm@freebsd.org Thu Jan 3 13:07:14 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CF70142A19A for ; Thu, 3 Jan 2019 13:07:13 +0000 (UTC) (envelope-from audioone.official@gmail.com) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8620274450 for ; Thu, 3 Jan 2019 13:07:12 +0000 (UTC) (envelope-from audioone.official@gmail.com) Received: by mail-it1-x134.google.com with SMTP id w18so45150955ite.1 for ; Thu, 03 Jan 2019 05:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OoUrY4EjZkRsD0LOjY9NsI9i/Y8GHRX1Tjblbt4t5uw=; b=SNis+Ag5BXJ3jGC7RpjHfh/1VuwTjVX7DUJLl3tBdFl5su3OXiG1Knc6cBMWDnvrqI i2iosLK/uiaPBD0hGZp15cQB+XxFQAaQWyxo2CGfXX1KG2U/4iwuVk3l+hxBREXOOerv IU25xSGqZR/12Ae3XRQLx5fulTOwx4EhlFrS22LTCzRIjqRsN4NqNOBuhCf9PlOjeB8Y vKTzWT9aigC6xT4i3bxaMc6Ee/3Ezyonzzj5Orp6Y/Prv5CgDkxNoEIdlxAZUj6dqrlJ q8gpjjdqOlM3aX4Z14zpv84c3QHvz/Bu+oBY2lgsCzJSI6WjvW2+xDtd4Ghlt23Pzzmg 0G5w== 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; bh=OoUrY4EjZkRsD0LOjY9NsI9i/Y8GHRX1Tjblbt4t5uw=; b=H/d4JJk4s/25/qY/uOdKbs9RPnF7+vpUzYUo/s5fisSyABuOZUJKx1W1K1UVO513Z2 1PhZCPBCxPlkiGnncORWb/6deh7vuu43jCymJ5sk1IaGb/0v+Tll13tU9mn+LYX+zRN9 UI6WubOSbKf/ADue/DSQRj8RODfncLTJt3CXfoNFW1oIrG89l0zWbUJSnSGug8eVS9Ve UIEzS9KvBj6Ua7ikN4tk+2ZQThnWa7Jlgyl00V9297/IiC00TGLlQg4LuSspauhrQy1+ HEItv3oNrZ3ks58X5WQBJ+nxFSoKXII34ZLVLg4jRo9I13rHkA52u2ZIxTd1t+L/zxAV oJnw== X-Gm-Message-State: AA+aEWYIM6+AJ+UXZZTGhsVGO8uVtv5hA5e/i9K5B8L+7WAx6DOvzc0v 5OWaoI2Fni6I17tJ/ic1PX1SMMPXOvjvLvbQk5McvZI6 X-Google-Smtp-Source: AFSGD/Vxp/9VdLWuwdz+qJG4PX101etFTK84ba4VFljQrl6wa+mgwWFPXVTNsC2WbuaeZNb9JchdcZBykNNLNTm+Bco= X-Received: by 2002:a02:9d0:: with SMTP id 77mr31053603jam.14.1546520831349; Thu, 03 Jan 2019 05:07:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: AudioONE Date: Thu, 3 Jan 2019 21:07:48 +0800 Message-ID: Subject: Re: i.MX6 DualLite stuck at early boot To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 8620274450 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=SNis+Ag5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of audiooneofficial@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) smtp.mailfrom=audiooneofficial@gmail.com X-Spamd-Result: default: False [-6.44 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.93)[-0.935,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; 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)[]; TO_MATCH_ENVRCPT_ALL(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]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.50)[ip: (-8.65), ipnet: 2607:f8b0::/32(-2.13), asn: 15169(-1.64), country: US(-0.08)]; RCVD_IN_DNSWL_NONE(0.00)[4.3.1.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]; 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: Thu, 03 Jan 2019 13:07:14 -0000 no luck to set sp_enabled = 0, any ideas? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208381 > okay....... after days and days mind storm(mind fuck), finally, I can > enter DDB, here is what I did in [reinit_mmu], maybe can help someone. > > > ============================== > > ASENTRY_NP(reinit_mmu) > push {r4-r11, lr} > mov r4, r0 > mov r5, r1 > mov r6, r2 > > + /* Only for Cortex-A9 Errdata Fix */ > + mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register > + orr r0, r0, #1 << 4 @ set bit #4 > + orr r0, r0, #1 << 6 @ set bit #6 > + orr r0, r0, #1 << 11 @ set bit #11 > + orr r0, r0, #1 << 21 @ set bit #21 > + mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register > + DSB > + ISB > > . > . > . > . > #else > bl dcache_inv_pou_all > #endif > mcr CP15_ICIALLU > + mcr CP15_TLBIALL /* Flush TLB */ > + mcr CP15_BPIALL /* Flush Branch predictor */ > DSB > ISB > > > /* Set auxiliary register */ > mrc CP15_ACTLR(r7) > . > . > . > > END(reinit_mmu) > ============================== > > my new problem is OS panic at same address "FAR=0000ec10"(after reset the > eval-board many times), what does it mean? something wrong with FDT? I use > wandboard-dual dts file(1 GB memory) > > > U-Boot 2016.05 (Dec 31 2018 - 22:57:28 +0800) > > CPU: Freescale i.MX6DL rev1.2 at 792 MHz > Reset cause: POR > Board: MX6DL-Armadillo2 > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: FSL_SDHC: 0 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: FEC > Error: FEC address not set. > > Hit any key to stop autoboot: 0 > reading tarker > ** Unable to read file tarker ** > reading tmpker > ** Unable to read file tmpker ** > Booting BSD loader > reading ubldr.bin > 185536 bytes read in 40 ms (4.4 MiB/s) > ## Starting application at 0x12000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x4fd703e0 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@freebsd-x250, Sat Dec 15 17:17:42 HKT 2018) > > DRAM: 1024MB > Number of U-Boot devices: 2 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=... good. > Booting from disk0s2: > / > /boot/kernel/kernel data=0x580b24+0xb74dc - > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Kernel entry at 0x0x12200100... > Kernel args: (null) > initarm: console initialized > arg1 kmdp = 0xc2639000 > boothowto = 0x00000000 > dtbp = 0xc254af08 > lastaddr1: 0x1283a000 > loader passed (static) kenv: > loader_envp = 0xc2638000 > c2638000 LINES=24 > c2638009 console=uboot > c2638017 currdev=disk0s2: > c2638028 kerflag= > c2638031 kernelname=/boot/kernel/kernel > c2638050 loaddev=disk0s2: > c2638061 prompt=loader> > c2638070 twiddle_divisor=1 > imx_wdog_init_last_reset > ARM Debug Architecture v7 > 4 watchpoints and 6 breakpoints supported > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-RELEASE-p1 #180 r309528M: Thu Jan 3 10:42:45 HKT 2019 > root@4160059805-freebsd-xeon:/mnt/dev/bsdbuild/arm.armv6/mnt/dev/11/sys/IMX6 > arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM > 3.8.0) > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > subsystem 1000000 > 0xc23e0b88(0)... Fatal kernel mode data abort: 'Translation Fault (L1)' > on read > trapframe: 0xc2713d18 > FSR=00000005, FAR=0000ec10, spsr=600000d3 > r0 =12998000, r1 =c2ffc010, r2 =00000001, r3 =c261c07c > r4 =00000006, r5 =c261c074, r6 =00000000, r7 =2a600000 > r8 =c2ffc059, r9 =00000000, r10=c260ba28, r11=c2713dd8 > r12=c2ffc014, ssp=c2713da8, slr=0000ec10, pc =c23fa450 > > [ thread pid 0 tid 0 ] > Stopped at 0xc23fa450 > db> bt > Tracing pid 0 tid 0 td 0xc2617190 > KDB: reentering > KDB: stack backtrace: > KDB: reentering > KDB: stack backtrace: > blahblahblah..... > blahblahblah..... > blahblahblah..... > blahblahblah..... > KDB: reentering > KDB: stack backtrace: > KDB: reentering > KDB: stack backtrace: > panic: pmap_fault: pm_pt1 abort > cpuid = 0 > Uptime: 1s > > > > > hi guys > > > > > I've got a small brand eval-board which built with MCIMX6U6AVM08AC and > running FreeBSD 11.0.1(I have tried HEAD version, 12.0-BETA3, it didn't > work too), ubldr stage is fine but it stucked at "reinit_mmu" > function(FreeBSD might be have assembly printf for debug environment, > because aseeembly code just like a blackbox when you without JTAG debugger > in hand ) > > > > ====================================== > > Booting from disk0s2: > > / > > /boot/kernel/kernel data=0x57b564+0x58a9c > syms=[0x4+0x6e9d0+0x4+0x77ada] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Kernel entry at 0x0x12200100... > > Kernel args: (null) > > EARL_DEBUG: pmap_kern_ttb 0x1290004a, actlr_mask 0xc1, actlr_set 0x41 > > (nothing) > > ====================================== > > > > > > > > when I trace the code to "reinit_mmu" function, commented code like > this, kernel panic and reported "Asynchronous External Abort". Am I the > only one who meet this WEIRD case? I got AM3352/AM3354/Zynq7 platforms, > they works fine with kernel 11.0.1. Is it something different between i.MX6 > Dual(Wandboard) and i.MX6 DualLite? > > > > /* Enable caches. */ > > mrc CP15_SCTLR(r7) > > // it will be stucked if don't commented this code > > /* orr r7, #CPU_CONTROL_DC_ENABLE //DEBUG > > orr r7, #CPU_CONTROL_IC_ENABLE //DEBUG > > orr r7, #CPU_CONTROL_BPRD_ENABLE //DEBUG */ > > mcr CP15_SCTLR(r7) > > DSB > > > > mcr CP15_TTBR0(r4) /* Set new TTB */ > > DSB > > ISB > > > > // it will be stucked if don't commented this code > > /* mcr CP15_TLBIALL /// Flush TLB //DEBUG */ > > mcr CP15_BPIALL /* Flush Branch predictor */ > > DSB > > ISB > > > > > > > > > > U-Boot 2016.05 (Dec 16 2018 - 13:09:25 +0800) > > > > CPU: Freescale i.MX6DL rev1.2 at 792 MHz > > Reset cause: POR > > Board: MX6DL-Armadillo2 > > DRAM: 1 GiB > > WARNING: Caches not enabled > > MMC: FSL_SDHC: 0 > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: serial > > Err: serial > > Net: FEC > > Error: FEC address not set. > > > > Hit any key to stop autoboot: 0 > > reading ubldr.bin > > 185536 bytes read in 40 ms (4.4 MiB/s) > > ## Starting application at 0x12000000 ... > > Consoles: U-Boot console > > Compatible U-Boot API signature found @0x4fd703e0 > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > (root@freebsd-x250, Sat Dec 15 17:17:42 HKT 2018) > > > > DRAM: 1024MB > > Number of U-Boot devices: 2 > > U-Boot env: loaderdev not set, will probe all devices. > > Found U-Boot device: disk > > Probing all disk devices... > > Checking unit=0 slice= partition=... good. > > Booting from disk0s2: > > / > > /boot/kernel/kernel data=0x57b564+0x58a9c > syms=[0x4+0x6e9d0+0x4+0x77ada] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Kernel entry at 0x0x12200100... > > Kernel args: (null) > > EARL_DEBUG: pmap_kern_ttb 0x1290004a, actlr_mask 0xc1, actlr_set 0x41 > > EARL_DEBUG: cpu_setup pass > > EARL_DEBUG: init_param1 pass > > initarm: console initialized > > arg1 kmdp = 0xc26bc000 > > boothowto = 0x00000000 > > dtbp = 0xc2547eb8 > > lastaddr1: 0x128bd000 > > loader passed (static) kenv: > > loader_envp = 0xc26bb000 > > c26bb000 LINES=24 > > c26bb009 console=uboot > > c26bb017 currdev=disk0s2: > > c26bb028 kerflag= > > c26bb031 kernelname=/boot/kernel/kernel > > c26bb050 loaddev=disk0s2: > > c26bb061 prompt=loader> > > c26bb070 twiddle_divisor=1 > > EARL_DEBUG: platform_late_init pass > > Fatal kernel mode data abort: 'Asynchronous External Abort' on write > > trapframe: 0xc257c688 > > FSR=00001c06, FAR=Invalid, spsr=600000d3 > > r0 =00000100, r1 =600001d3, r2 =600000d3, r3 =30c52079 > > r4 =00000000, r5 =c257c7e4, r6 =c25b3280, r7 =c25b3280 > > r8 =c2578058, r9 =00000000, r10=c25ce154, r11=c257c7d8 > > r12=c2577c24, ssp=c257c718, slr=c244b3c0, pc =c244b3d4 > > > > panic: Fatal abort > > cpuid = 0 > > Uptime: 1s > From owner-freebsd-arm@freebsd.org Thu Jan 3 20:52:00 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 591291436DB3 for ; Thu, 3 Jan 2019 20:52:00 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82DCC8F309; Thu, 3 Jan 2019 20:51:59 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: by mail-io1-f51.google.com with SMTP id m19so28040736ioh.3; Thu, 03 Jan 2019 12:51:59 -0800 (PST) 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=S3VvELCBRUappLOUrT1rBSfant6PXzJfSFbQFbKTrg0=; b=MuqcKFaYY/hPEnMpDgTbhUK/mKSPV+7gA5WeMt3nMmZgSX2HJrYeZyTi+Fduw3X9Uu jQnpZb16f4uYy6/r19OgV68XO332Aq0gndDAM9U3sisBXpRZmPLXkg1xZ4YXPyRLhzPo NMM0G4wOncsiyD3Mr+61igmEBt153duoENKOirXr0pvh79k31F8l8VTQ4YvsFzYUi2Wa S1M36k5izTGT2gg/p1hORXc2LAush+HBV62fyfFGbENq7u4oKzEkGcchqOkhnr2s2njv +Up+cQ7dKqLlmsvMfEPk754NJ6g34wbZgGKSrTXAjp3idtdOoRBAwQs1lSqtb/M1ZJix 645A== X-Gm-Message-State: AJcUukc02bZ47tiumip8KLP547yeBR18YwGIRsGG4mesudH/+NlohznK aLTS5z//hogndymJJvIjUnSunm6WVDOsOw2gXF3FnRwD X-Google-Smtp-Source: ALg8bN4qGOfdnfZe/TNgZabfd/DqNk+ldgDU/9WDAhdNwpJzzSRinX7ZiQ09U6V9Vq/206rF275Uj7zvYN3oqWGBM4c= X-Received: by 2002:a5e:d808:: with SMTP id l8mr32836658iok.299.1546548713336; Thu, 03 Jan 2019 12:51:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Jayachandran C." Date: Thu, 3 Jan 2019 12:51:26 -0800 Message-ID: Subject: Re: ThunderX2 support in FreeBSD/arm64 To: Ed Maste Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 82DCC8F309 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of cjayachandran@gmail.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=cjayachandran@gmail.com X-Spamd-Result: default: False [-5.92 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; IP_SCORE(-3.02)[ip: (-9.59), ipnet: 209.85.128.0/17(-3.78), asn: 15169(-1.64), country: US(-0.08)]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[51.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.90)[-0.896,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FORGED_SENDER(0.30)[jchandra@freebsd.org,cjayachandran@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[jchandra@freebsd.org,cjayachandran@gmail.com]; 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, 03 Jan 2019 20:52:00 -0000 (Was AFK for a while, sorry for the late reply) Hi Ed, On Fri, Dec 21, 2018 at 11:15 AM Ed Maste wrote: > > On Mon, 17 Dec 2018 at 21:51, Jayachandran C. wrote: > > > > Over the last few weeks I have committed changes for a few outstanding > > items needed for ThunderX2 support in FreeBSD/arm64. > > I see that D10082, D10083, D10084 are still open, awaiting review. > Should I apply them to my test tree? > > My current status - loader claims to start the kernel, but I see no > further output. Can you share the kernel config file you used (or > perhaps a git tree you built from)? There seems to be 2 issues here - both of them happen when the AMI firmware is used. The first issue is that the efi framebuffer does not work, and I am not able to select the serial console with AMI firmware. The second issue is that the on-chip SATA controller is not setup correctly by the AMI firmware and can cause a 'NBU BAR error' failure. I have uploaded a test firmware and instructions to https://people.freebsd.org/~jchandra/testfw/ which should boot FreeBSD fine. This is an internal build which does not have both the problems above. Let me know if this works, and I will try to push the fixes to AMI. Thanks, JC. From owner-freebsd-arm@freebsd.org Thu Jan 3 21:23:47 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FDE01437E0A for ; Thu, 3 Jan 2019 21:23:47 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B6B469F87; Thu, 3 Jan 2019 21:23:46 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: by mail-io1-f52.google.com with SMTP id g8so16748816iok.4; Thu, 03 Jan 2019 13:23:46 -0800 (PST) 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=l2rX5gDsdmIgJlKt87wUu6+1C1WTaN/r26+ZKS8qDq8=; b=kQSME81RWLul6urxb9n32UzM7Z6S3frSJFEoTc6iMl5DdWQz31wj1TR+IjX5fzIrmp jCz4BS3UKaZABKOlF4Vyb9yTzhaYEwgzD8baGIyIgaU8vhr5S/3uJ/twFoPtIbuatBV6 ggbJb6rUWTPEaujXt47rHebZcnVBM7Ou4mtC+w4O6jCZrLu1dG/rMyu87Ga+/RbB0fP1 pkALJ09R9mL5y/OdnBco5rHNPNnI9nb5efTaxm5lzM1yB8XKOmxCzqVwwsc0F4OE20k1 G1vKvEejCCwpHEiLjoNG/0PCg9pstaQwA0phONlUqXU3mV1+1U0N70qUOonT1gsN0A4w XHyQ== X-Gm-Message-State: AJcUukfdlaO0Bq+0xVGT0T1ydvlchnrK1UZbc5rJ+xsNz37fWrR1piJx IWFSz+EhzZvuE/4S1C6p9rs4ZMtiDV7DOslSyI0+ig== X-Google-Smtp-Source: ALg8bN462T1sUSUrLXR7tsVMqfX7bUfI5JzOYNwRFJZ2YRwX2E308qrYRKrnQOdD31mqVMOdbORBF3yG1sVGRno0R0U= X-Received: by 2002:a5d:8199:: with SMTP id u25mr6672994ion.113.1546550619437; Thu, 03 Jan 2019 13:23:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Jayachandran C." Date: Thu, 3 Jan 2019 13:23:12 -0800 Message-ID: Subject: Re: ThunderX2 support in FreeBSD/arm64 To: Ed Maste Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7B6B469F87 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of cjayachandran@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=cjayachandran@gmail.com X-Spamd-Result: default: False [-5.54 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.76)[-0.759,0]; FORGED_SENDER(0.30)[jchandra@freebsd.org,cjayachandran@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jchandra@freebsd.org,cjayachandran@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.78)[ip: (-8.38), ipnet: 209.85.128.0/17(-3.77), asn: 15169(-1.64), country: US(-0.08)]; 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, 03 Jan 2019 21:23:47 -0000 On Fri, Dec 21, 2018 at 12:02 PM Ed Maste wrote: > > On Fri, 21 Dec 2018 at 14:08, Ed Maste wrote: > > > > I see that D10082, D10083, D10084 are still open, awaiting review. > > Oops, that should be D18002, D18003, D18004. ThunderX2 should should boot even without these changes, the default association between PCI RC and GIC ITS based on NUMA settings should work fine. It would be good to get these reviewed since it adds support for the ARM specific IORT table, which is standard way of passing the associations between RC and ITS - and is required for full ACPI support. Thanks, JC From owner-freebsd-arm@freebsd.org Fri Jan 4 06:56:44 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BA1F141E0A9; Fri, 4 Jan 2019 06:56:44 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3729383EC0; Fri, 4 Jan 2019 06:56:43 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm1-x344.google.com with SMTP id n190so286203wmd.0; Thu, 03 Jan 2019 22:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=usatyWAmXZ35xb0cj4vJ5X+otTvMD3Y8WK5vM9ibfqk=; b=EqaVeZ+MtgcqEbDjTM1zZUsQuOEuMpVgH7psTso6ORP1sUDbJyxIGSmosBtKD5ckla r+1BFsB2m7gCBGwYwLe6Ivfi4PwAbq1i8fJufedle7dt7U031SZXyTgyDy8HBLrOnzSi vIM5+MVBUeGyszmhLL5X0rhZkUFF1vsunUzQb2P5XZlZ/MZLUyv9hsgxQAojlm+VKDed 0oNEVfjmKgR7MANTgBEN4RFkkM3LJDgeoGkRu/iWCLR0q/rqWQT2JykWy4Z6ggc0lCHM i50cOhEu3d5bXFdFECRjMMA2on/REPRtgmDN3RjQZGoHtcBbe+NbNvW2vCnof1jGlQIM tuIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=usatyWAmXZ35xb0cj4vJ5X+otTvMD3Y8WK5vM9ibfqk=; b=hpeLOypp4kRvveV+EZ+NIgYvGbeYChDUFDvmBQnVght7PKyUnHZtuAfj+EmiMGmiaB NtnG2NNSttpViL9gRUK2DMwOPLpPkOQdF9GKBX/ciRMX2g4RAhEPSo3gTkrWhTvCO2s/ 4hsJMOQUbY7lg8gXl0of7GmZ/SsimdeMua02kBIX0rExta7VlH22PZ5CUQT38vSkxtLb r6wlXXVkr/oqvamEpa5sw3ELXiBpSB5yKIUPQ1GPsxljNxagUn//tH68BDQjcRytajRa ZmnjB6dUbNNMiKVSj0InMlJ0TEHonQW+i/0tyjoTnK559YrSdGV+pKwrAAU1ntW1/7AG 7ZVQ== X-Gm-Message-State: AJcUukfa92AS+JRzB9F5IlYSJ6a0fmOE5zNYcZzt6JevDYqJz6kEPyNd ZfIAIoxbrsu692RGedXRaV0= X-Google-Smtp-Source: ALg8bN5Zpor5Ok+IQ7zPygWdFm+N3SmLBhhVdGnHAX9TWo018dTNm6YcA4RAJOIQWcVUAWDSIFrUYA== X-Received: by 2002:a1c:8d12:: with SMTP id p18mr451319wmd.31.1546585001981; Thu, 03 Jan 2019 22:56:41 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id t76sm339763wme.33.2019.01.03.22.56.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jan 2019 22:56:41 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) To: Dennis Clarke , freebsd-arm@freebsd.org, FreeBSD Current , Mark Millard References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> Openpgp: preference=signencrypt Autocrypt: addr=mmel@freebsd.org; prefer-encrypt=mutual; keydata= mQENBFYuVRkBCADZiwLCCne3wG9b9k+R2Neo5zVo2bLaZRfNNY/v9kg283i0sb1Da4EdEiNT 15El5UyozhphUIbIR/zrVpxF1TvvFdoCyzx6a68bNY2d9dBrDcNDZC+XnyDdHQoobN87DWT1 mRVkmbg9LHZ/SVUOkGYuWyE+8UYeDAcUizuXwSK5zFWmeTyIoWNa68ifrWLfQe0p4x5jC/AI VURCi17p360vU4fhgwoMvEEhrRBWCr4DYHToFjIt2WdBy3GR1qoO0+Xkd6G+OoBULo+XDfgu L2WdPvh0K69F9/LgHkMmG5Il7SCe62QGpG2vaCgRV7BQhLX+kxlvM+WrdRatWRml4Y/3ABEB AAG0IE1pY2hhbCBNZWxvdW4gPG1tZWxAZnJlZWJzZC5vcmc+iQFABBMBCgAqAhsDBQsJCAcD BRUKCQgLBRYDAgEAAh4BAheAAhkBBQJZjBHDBQkHICOqAAoJEGkesmtexaqqIKMIAJ9xTp1w ge86ns2ZYOac5++mAgpFatohSlxYUR3gwud3Y3Ej0eumavpv/C26N6dsLnspwRenKdLbIPKe 0N8lI7CcDBIJGiFyY3c4H79QjIkYpRgbWFyCM85zEyVJpB+U7BhsgXE2uwVjE9RNhEP0KBoj sp357uqq1B1+VUO4GJ+RjdmYSOcNrjR8tTfy02456qovGjJ4JcJBlhyK6GzBKvnZSoA0s+QP OMn3gd8gdomMLEJdS3kTsfhLh2rQPZa9EmzafIyjXrirWq4+4fVFgd8SiMZyyTM+Kz30ZSUe 6SmfaQTQ/WLRIl5jku2uYQWlrRIKT9xaQzRWtZO9UgtXFRG5AQ0EVi5VGQEIALqgRkfS21D/ OqWE9mXfh2bIjrp9uC8T0MCuimbsrAdLKNNorGu2nE+rebgX8n5nYM377HOnalPGyOuXvCbQ 8MFVRdWOHxenJjXJialNdBsOf2wLva3vSSVsdoPzibWDIcJqhBOQ3EuhsILyWSPvYYKEiy95 mfhrDtuTTOAYVR9aNQBOENztB2TDJyMx/qZmtGroGV3N0Hqde/znHPtQO8RG5/FQGMfHMI5G FMuycr1ceHnLo/ovrqAl4TYV+UHSHJ+FDE9dt9wXHclWbWbC0yNugchZq6rho5Jjfv4a2v7P pyn3HoDinh1lWP7hYA0ZNExGHekLnXWVqO/lzGS6bMEAEQEAAYkBJQQYAQoADwIbDAUCWYwR wwUJByAjqgAKCRBpHrJrXsWqqrsrB/4g4ESK5TLxUxi8pLWcLPyvwtN4Fmf7VsCVefkhakaG rDPmfvfnG+OFwN60Xqoni7GBeakl01xwT4RINfvVfShDy6cHpLS7QL/M8pzfulVX38MkVkOD yGZhwjE+jyT/kZNA1Olaw3N3IefHq3brskQ7G4d9oPep2DDbw7C4Q76uOBjxy34JVB0WOsB6 NyMQB9h6LGljQtdEddyUqwnRZzzHiGvp0hPtdYQHQZlqbj4FV9lTRK7a8Ega+y7MgmeMiztG zeXyjNP02r3PRHCPagwa57bPxH2aAh4Q7UzBBZ0GTMm7DLKNtCP58WDxblrrhZ+7kHqGK8Fs bdeUpDdEYLVd Message-ID: Date: Fri, 4 Jan 2019 07:56:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 3729383EC0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=EqaVeZ+M; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of melounmichal@gmail.com designates 2a00:1450:4864:20::344 as permitted sender) smtp.mailfrom=melounmichal@gmail.com X-Spamd-Result: default: False [-4.18 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.69)[-0.692,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.48)[ip: (1.21), ipnet: 2a00:1450::/32(-1.87), asn: 15169(-1.65), country: US(-0.08)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.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, 04 Jan 2019 06:56:44 -0000 On 29.12.2018 18:47, Dennis Clarke wrote: > On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote: >> >> On 2018-Dec-28, at 12:12, Mark Millard wrote: >> >>> On 2018-Dec-28, at 05:13, Michal Meloun >>> wrote: >>> >>>> Mark, >>>> this is known problem with qemu-user-static. >>>> Emulation of every single interruptible syscall is broken by design (it >>>> have signal related races). Theses races cannot be solved without major >>>> rewrite of syscall emulation code. >>>> Unfortunately, nobody actively works on this, I think. >>>> > > Following along here quietly and I had to blink at this a few times. > Is there a bug report somewhere within the qemu world related to this >  'broken by design' qemu feature? Firstly, I apologize for late answer. Writing a technically accurate but still comprehensible report is extremely difficult for me. Major design issue with qemu-user is the fact that guest (blocking / interruptible) syscalls must be emulated atomically, including delivering of asynchronous signals (including signals originated by other thread). This is something that cannot be emulated precisely by user mode program, without specific kernel support. Let me explain this in a little more details. Assume that we have following trivial code: void sig_alarm_handler(…) { if (!done) { do some work; alarm(10); } } void foo(void) { install_signal_handler(SIGALARM, sig_alarm_handler); alarm(10); do some work; while (true) { rv = select(…, NULL); if (rv == 0) do some work; else if (rv != EINTR) Report error end exit; } } In native environment, this code works well. It calls alarm signal handler every 10s, irrespective if signal is fired in the program code or in libc implementation of select() or if program is waiting in kernel part of select() syscall. In qemu-user environment, things get significantly harder. Qemu can deliver signals to guest only on instruction boundary, the guest signal handler should see emulated CPU context in consistent state. But kernel can deliver signal to qemu in any time. Due to this, qemu must store delivered signals into queue and emit these later, when emulator steps over next instruction boundary. Assume that qemu just emulates 'syscall' instruction from guest select() call. Also assume that no other signals (but SIGALARM) are generated, and socket used in select() never received or transmits any data. The first version of qemu-user code emulating select() was: abi_long do_freebsd_select(..) { convert input guest arguments to host; rv = select(…); convert output host arguments to guest; return(rv); } But this is very racy. If alarm signal is fired before select(…) enters kernel, qemu queues it (but does not deliver it to guest because it isn't on instruction boundary) and continues in emulation. And because (in our case) select() waits indefinitely, alarm signal is never delivered to guest and whole program hangs. Actual qemu code emulating select() looks like: abi_long do_freebsd_select(..) { convert input guest arguments to host; sigfillset(&mask); sigprocmask(SIG_BLOCK, &mask, &omask); if (ts->signal_pending) { sigprocmask(SIG_SETMASK, &omask, NULL); /* We have a signal pending so just poll select() and return. */ tv2.tv_sec = tv2.tv_usec = 0; ret = select(…, , &tv2)); if (ret == 0) ret = TARGET_EINTR; } else { ret = pselect(…, &omask)); sigprocmask(SIG_SETMASK, &omask, NULL); } convert output host arguments to guest; return(rv); } This look a much better. The code blocks all signals first, then checks if any signal is pending. If yes, then does not-blocking select() (because timeout is zero) and correctly returns EINTR immediately. Otherwise, it uses other variant of select(), pselect() which adjusts right signal mask itself. That's mean that syscall is called with blocked signal delivery, but kernel adjusts right sigmask before it waits for event. While this looks like perfect solution and this code closes all races from first version, then it doesn't. pselect() uses different semantic that select(), it doesn't update timeout argument. So this solution is also inappropriate. Moreover, I think, we don't have p equivalents for all blocking syscalls. Mark, I hope that this is also the answer to your question posted to hackers@ and also the exploitation why you see hang. Linux uses different approach to overcome this issue, safe_syscall -> https://gitlab.collabora.com/tomeu/qemu/commit/4d330cee37a21aabfc619a1948953559e66951a4 It looks like workable workaround, but I'm not sure about ERESTART versus EINTR return values. Imho, this can be problem. I have list of other qemu-user problems (I mean mainly a bsd-user part of qemu code here), not counting normal coding bugs: - code is not thread safety but is used in threaded environment (rw locks for example), - emulate some sysctl's and resource limits / usage behavior is very hard (mainly if we emulate 32-bits guest on 64-bits host) - if host syscall returns ERESTART, we should do full unroll and pass it to guest. - the syscalls emulation should not use the libc functions, but syscall instruction directly. Libc shims can have side effects so we should not to execute it twice. Once in guest, second time in host. - and last major one. At this time, all guest structures are maintained by hand. Due to huge amount of these structures, this is the extreme error prone approach. We should convert this to script generated code, including guest syscalls definition. Again, my apology for slightly (or much) chaotic report, but this is the best what's I capable. Michal From owner-freebsd-arm@freebsd.org Fri Jan 4 09:18:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A53D142262F for ; Fri, 4 Jan 2019 09:18:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-29.consmr.mail.bf2.yahoo.com (sonic317-29.consmr.mail.bf2.yahoo.com [74.6.129.84]) (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 7E95687DA8 for ; Fri, 4 Jan 2019 09:18:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: _omNhBkVM1nZlTPAtL0PP1wCtfNJzm.2ufgw0cCLxwF8784wVfEjWFNhkuXFUbA eNjtNjZbC8eIadw6j50TFf_MSrs2dEKSOUBbBCkcvP.5cYzsxF3EWEvjvB3yn1xmBDkbTxebZ7Fx gRab.4LLSC_G8WV1jP9Zt_3zEQ56VjDeF6H1Zs2ZsEl7QwFCAKpX1psS8Y1eZZuAA1x.MiAmCybu oLKlhouxv8ctmMW8bQ_2tluYjOWJF2SOyvGgBQdfG1ciuxWKoOYIRuu9MbYJw.5xrB3DhjiBydIu pYpqvqvso1jakGrwMzpu1Q8gBwR71YE6FvLdsoM32tz8rxtUXRoHcQxhQM2FNc5LNj8iMLn40MIn pA0g11N6FNZZO8Rg45CgrJXZkJLRP_6lmcwXIDFLT7zRQdUJv4w65FZw.bkGLskfFY14LCPNOwyw Vn_sAcjAmmFk9tGkQ5.nTLWSG3TdaW1I3ymKsPjvYAMOsuPoSAGHnMGPTiVJnc4sS0ehGQEhU1mI DAqCQ94Q_c6B.5ap3aEMfgs0J.bWCEEdOcl8FsMr.TRkFrlQfKs5qlkdxj2d73HJq5nZhn5z.GT8 LEB2uklKvTbpjIlaviS_Up0STQYzDI._OYUQTOD3qfZpPXrnhwCwTdrdbpeyfHq8JrKbYdQziYv5 XqvezLfIVtEGmIMcSj.UenBONSd5E0K45wgh9h1CREoQRE_U9nWQrvpe2tUmNnP6okK_daprZDhh JDccCAnYIoFd0qpJ1oMUgmxoSd2nQuQKTRXO47pDWYBe3JQPgWOCMJlbUFRe7djpWsDx2i.ntlHL .CBlgvoUmvuZCFG8ppPyRfzs7Jv41b7tnzG.qewGhClzy0_0XYgzGRxcJWn9lDT_BYA.k9Osgve5 uEVOtBTlEGolpwmOd3EW0f17G9sGg_qWLDGvCRfifPAt8rFbCuU.MY1xtDobMO.bolvEGFHwRWg9 huxeaSwseG.6z_ekwZsFI9E4CN4mfocAkDFNwCPVAO1_5Wz3O8ogVYFJFVj4_6IHrmzWFnsZLxqI Ddi4ImIjZ3Ojt9P6WAHazjc8VboV9iH5zwL9IwpoSedlA5MORMuqs65txxjjI57p1reVtzr4n Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 4 Jan 2019 09:17:59 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c4e54658c1a98d8dd65b4cbbaccdfeaa; Fri, 04 Jan 2019 09:17:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) From: Mark Millard In-Reply-To: Date: Fri, 4 Jan 2019 01:17:52 -0800 Cc: Dennis Clarke , freebsd-arm@freebsd.org, FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 7E95687DA8 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.94)[0.940,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.38)[ip: (4.30), ipnet: 74.6.128.0/21(1.48), asn: 26101(1.18), country: US(-0.08)]; NEURAL_SPAM_MEDIUM(0.37)[0.373,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.22)[0.221,0]; RCVD_IN_DNSWL_NONE(0.00)[84.129.6.74.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.129.6.74.rep.mailspike.net : 127.0.0.17] 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, 04 Jan 2019 09:18:06 -0000 On 2019-Jan-3, at 22:56, Michal Meloun wrote: > On 29.12.2018 18:47, Dennis Clarke wrote: >> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote: >>> >>> On 2018-Dec-28, at 12:12, Mark Millard wrote: >>> >>>> On 2018-Dec-28, at 05:13, Michal Meloun >>>> wrote: >>>> >>>>> Mark, >>>>> this is known problem with qemu-user-static. >>>>> Emulation of every single interruptible syscall is broken by design (it >>>>> have signal related races). Theses races cannot be solved without major >>>>> rewrite of syscall emulation code. >>>>> Unfortunately, nobody actively works on this, I think. >>>>> >> >> Following along here quietly and I had to blink at this a few times. >> Is there a bug report somewhere within the qemu world related to this >> 'broken by design' qemu feature? > > Firstly, I apologize for late answer. Writing a technically accurate but > still comprehensible report is extremely difficult for me. Thanks for doing so. > . . . > Mark, I hope that this is also the answer to your question posted to > hackers@ and also the exploitation why you see hang. Again thanks: it was helpful for my gaining some understanding of the code structure. But it turns out that another of your list of problems is involved in the hang-up: > . . . > - and last major one. At this time, all guest structures are maintained > by hand. Due to huge amount of these structures, this is the extreme > error prone approach. We should convert this to script generated code, > including guest syscalls definition. It turns out that "struct target_cmsghdr" has the wrong overall size, the wrong first field size, and the wrong offsets for later fields for amd64->aarch64 use (or likely any 64-bit->64-bit host-target pair, even amd64->x86_64). In fact the code reports via: gemu_log("Unsupported ancillary data: %d/%d\n", cmsg->cmsg_level, cmsg->cmsg_type); because of msg->cmsg_level and cmsg->cmsg_type ending up with messed up values. It hangs after that message shows up. The more complete code containing that qemu_log call is: if ((cmsg->cmsg_level == TARGET_SOL_SOCKET) && (cmsg->cmsg_type == SCM_RIGHTS)) { int *fd = (int *)data; int *target_fd = (int *)target_data; int i, numfds = len / sizeof(int); for (i = 0; i < numfds; i++) { fd[i] = tswap32(target_fd[i]); } } else if ((cmsg->cmsg_level == TARGET_SOL_SOCKET) && (cmsg->cmsg_type == SCM_TIMESTAMP) && (len == sizeof(struct timeval))) { /* copy struct timeval to host */ struct timeval *tv = (struct timeval *)data; struct target_freebsd_timeval *target_tv = (struct target_freebsd_timeval *)target_data; __get_user(tv->tv_sec, &target_tv->tv_sec); __get_user(tv->tv_usec, &target_tv->tv_usec); } else { gemu_log("Unsupported ancillary data: %d/%d\n", cmsg->cmsg_level, cmsg->cmsg_type); memcpy(data, target_data, len); } Of 3 types of hangups that I've run into recently, one was from a missing statement, one was from struct target_kevent having the wrong overall size and wrong field offsets after the first field (amd64->armv7 was an example), and the one involving struct target_cmsghdr above. (There may be more to the target_cmsghdr one.) > Again, my apology for slightly (or much) chaotic report, but this is the > best what's I capable. Not chaotic in my view. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jan 4 18:34:49 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3990F1434E83 for ; Fri, 4 Jan 2019 18:34:49 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F6DA7589E; Fri, 4 Jan 2019 18:34:48 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-it1-x131.google.com with SMTP id i145so2779952ita.4; Fri, 04 Jan 2019 10:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VW1wbOGSBEa6O8+J1giOux9UwziDmD4CCaNR9YBO2U8=; b=N3487/anDoNvf0+OltwwjEM+2hX9Kr/9VS/Nt8teGMo489u5I83UrkW5cMoyWPOmz3 tVvEVYhHpRD8iRkvb62NU31AWuLW8AZut1BIduHnElSk4OeM3MPDMhkr8mWgvoGmeuVw f/IboAW/FjwvLO9Sq0QjSFkggsB8SNcvLoSLvXTdgG7QJIYoU9YZc4kK5/9X6sFFb/TP Q0fQjFBI+wjfkxKA/NFLtsr7JSbPtoJJhZh4zeLrvRGMyis+RryMLhEfEwZ/RwVh18uj dRsBMu47uuXc0/Q7/d8yVM+OIIaISLYH9Vpe64R2Go8SpRPhmeoFVp2stmJMC+WwmFeP 7p0g== 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=VW1wbOGSBEa6O8+J1giOux9UwziDmD4CCaNR9YBO2U8=; b=lA3/MeoSqyLMvCHJUEAd5vAmz0gUBRLHWhDBcK/DQoXJ3UaJZjCRaGtCdfqnjo0yxi mRgZc7YdIHERzRTPUPGeMGakGV0sHkjX9QMYmdSV3cSXFL+nBuUc40hshrUAuDvE2cCN OfNG2Rfjq/zcHG4MHanWJ6aUIHmRWd9kRPoiJNqAFNshvv/2rGv6CKhsUyjcix2YJJ7q 9yOYusqtBvfFHG6donexrQGeD2gOYmOhbIv1+FbTElKSz+X6YjGiGd2KfA9fuUQwGgHz 4UqSSfWNu1RlVRrXbhO6XpxDQvdiv7eif5iCbWBTh5eJgAaO8mTauKdTUrssbR9MJqQt oGYw== X-Gm-Message-State: AJcUuke3zcK8WjZEG5m1AwwmcL377IQVLl7A5IU38OVNMtq86gg0qvQN yYOh50vm4Qzsh01fBo89eyaWi8DIkFDkP2+BF/kzwW// X-Google-Smtp-Source: ALg8bN7nNJJCQoDpwXuL/QhX0wn7VC13jJpZlFUO7OPiCpkefeVhEGHUDyWMQ+ZqrKTaCnWdIvHWOKQNlJujyr7TIic= X-Received: by 2002:a24:4110:: with SMTP id x16mr1807779ita.30.1546626887543; Fri, 04 Jan 2019 10:34:47 -0800 (PST) MIME-Version: 1.0 References: <20181221195054.GA84895@home.opsec.eu> <20181221200257.eth3xbnxhpsilbji@mutt-hbsd> In-Reply-To: <20181221200257.eth3xbnxhpsilbji@mutt-hbsd> From: Russell Haley Date: Fri, 4 Jan 2019 10:34:35 -0800 Message-ID: Subject: Re: ThunderX2 support in FreeBSD/arm64 To: Shawn Webb Cc: Kurt Jaeger , freebsd-arm X-Rspamd-Queue-Id: 3F6DA7589E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=N3487/an; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of russhaley@gmail.com designates 2607:f8b0:4864:20::131 as permitted sender) smtp.mailfrom=russhaley@gmail.com X-Spamd-Result: default: False [-6.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.3.1.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]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; IP_SCORE(-2.38)[ip: (-7.98), ipnet: 2607:f8b0::/32(-2.18), asn: 15169(-1.66), country: US(-0.08)]; NEURAL_HAM_SHORT(-0.88)[-0.882,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(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: Fri, 04 Jan 2019 18:34:49 -0000 On Fri, Dec 21, 2018 at 12:07 PM Shawn Webb wrote: > On Fri, Dec 21, 2018 at 08:50:54PM +0100, Kurt Jaeger wrote: > > Hi! > > > > > Over the last few weeks I have committed changes for a few outstanding > > > items needed for ThunderX2 support in FreeBSD/arm64. Most of the > > > changes were to fix-up support for ACPI based PCI controllers and to > > > enable ACPI based NUMA (thanks to andrew, markj and jhb for reviews). > > > > > > With these, 13-CURRENT works well enough for testing - so if you have > > > access to a ThunderX2, I would like to hear how well it works for you. > > > > Can you tell suggest possible systems/supplier to choose for a port > > builder box ? > > > > I'm mulling over buying such a system to testbuild freebsd ports on arm64 > > and look around for possible suppliers. > > HardenedBSD bought theirs from Phoenics Electronics. > > Status of HardenedBSD's ThunderX2: > I emailed Phoenics Electronics and received an email from Steve Wilson. He pointed me to these little beauties: https://www.asacomputers.com/Cavium-ThunderX.html Now I just have to convince my boss or my other boss (wife) to let me buy one... I did notice that these ASA Computer units only use the ThunderX and the ThunderX_CP processors. Some of the other ThunderX processors have PCIe and other goodies such as this one: https://www.marvell.com/server-processors/thunderx-arm-processors/thunderx-nt/ Contact Info For Steve: Steve Wilson Director, Phoenics Tech Center 31 Nagog Pk, Acton MA 01720 978 856 0111 617 594 9603 c skype: stevenjwilson9603 > > Almost booting stock FreeBSD. I'm working with Jayachandran to resolve > the issues. It may be that my system has buggy firmware, but > Jayachandran is verifying whether that's the case. > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal: +1 443-546-8752 > Tor+XMPP+OTR: lattera@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > From owner-freebsd-arm@freebsd.org Fri Jan 4 18:55:05 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 755A114357B2 for ; Fri, 4 Jan 2019 18:55:05 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::4]) (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 0438C76770; Fri, 4 Jan 2019 18:55:05 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by fc.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1gfUcW-000Ajp-7m; Fri, 04 Jan 2019 19:55:00 +0100 Date: Fri, 4 Jan 2019 19:55:00 +0100 From: Kurt Jaeger To: Russell Haley Cc: Shawn Webb , Kurt Jaeger , freebsd-arm Subject: Re: ThunderX2 support in FreeBSD/arm64 Message-ID: <20190104185500.GA96232@fc.opsec.eu> References: <20181221195054.GA84895@home.opsec.eu> <20181221200257.eth3xbnxhpsilbji@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, 04 Jan 2019 18:55:05 -0000 Hi! > > > > With these, 13-CURRENT works well enough for testing - so if you have > > > > access to a ThunderX2, I would like to hear how well it works for you. [...] > > HardenedBSD bought theirs from Phoenics Electronics. > > > > Status of HardenedBSD's ThunderX2: > > > I emailed Phoenics Electronics and received an email from Steve Wilson. He > pointed me to these little beauties: > > https://www.asacomputers.com/Cavium-ThunderX.html Well, to say the truth, I'm a bit confused by all this choice 8-} This page: https://b2b.gigabyte.com/ARM-Server/R181-T90-rev-100#ov says that there's a difference between ThunderX and ThunderX2. The asa-systems are much cheaper, but are not ThunderX2, right ? > https://www.marvell.com/server-processors/thunderx-arm-processors/thunderx-nt/ Yes, what's x-nt now ? Something between X and X2 ? Something beyond ? -- pi@FreeBSD.org +49 171 3101372 One year to go ! From owner-freebsd-arm@freebsd.org Fri Jan 4 19:09:46 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20F051435F48 for ; Fri, 4 Jan 2019 19:09:46 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 965F077295 for ; Fri, 4 Jan 2019 19:09:45 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Fri, 04 Jan 2019 19:08:39 +0000 Received: from [192.168.1.141] ([62.122.208.146]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 3C54EE7C-E2EA-4840-98EF-3FEADBF5217B.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Fri, 04 Jan 2019 19:08:39 +0000 Date: Fri, 04 Jan 2019 22:08:32 +0300 From: Greg V Subject: Re: ThunderX2 support in FreeBSD/arm64 To: Kurt Jaeger Cc: Russell Haley , freebsd-arm Message-Id: <1546628912.2475.0@smtp.migadu.com> In-Reply-To: <20190104185500.GA96232@fc.opsec.eu> References: <20181221195054.GA84895@home.opsec.eu> <20181221200257.eth3xbnxhpsilbji@mutt-hbsd> <20190104185500.GA96232@fc.opsec.eu> X-Mailer: geary/0.12.4 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; bh=2RPPrSdNRmA8RRAR5OLHLMF9xjEZdXCSqE7eDY501OE=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=kA2NZTXgWKz1tWWwou2Ja/P1tA2HaL3XEtjxl5StyXACGiaiCHpf7Z7ms7+bmPbg0phngC2PjL7a5J3VfokFeagfepVJDjx/HlBHmxA2KMoamMfUlIyfK4TLjn8ZCPjRP6aWaV89idZWjdhT29J5gLkDvmnEL21xFh8BN69smgo= X-Rspamd-Queue-Id: 965F077295 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.980,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, 04 Jan 2019 19:09:46 -0000 On Fri, Jan 4, 2019 at 9:55 PM, Kurt Jaeger wrote: > Hi! >=20 >> > > > With these, 13-CURRENT works well enough for testing - so if=20 >> you have >> > > > access to a ThunderX2, I would like to hear how well it works=20 >> for you. > [...] >> > HardenedBSD bought theirs from Phoenics Electronics. >> > >> > Status of HardenedBSD's ThunderX2: >> > >> I emailed Phoenics Electronics and received an email from Steve=20 >> Wilson. He >> pointed me to these little beauties: >>=20 >> https://www.asacomputers.com/Cavium-ThunderX.html >=20 > Well, to say the truth, I'm a bit confused by all this choice 8-} >=20 > This page: >=20 > https://b2b.gigabyte.com/ARM-Server/R181-T90-rev-100#ov >=20 > says that there's a difference between ThunderX and ThunderX2.( Of course there is. ThunderX2 is a *massive* upgrade over the first=20 ThunderX, especially in single-core performance. TX2 uses a completely=20 new core (ex-Broadcom Vulcan). You can play with the original ThunderX in the "cloud" right now: - Scaleway VPS =97 I wrote the depenguination instructions:=20 https://community.scaleway.com/t/freebsd-on-arm64/6678 - Packet bare metal https://www.packet.com/cloud/servers/c1-large-arm/=20 =97 when not sold out :D (seems like they have some available in New=20 York right now) =97 they offer (an older version of) FreeBSD as a one=20 click install Packet also plans to have Ampere eMAG servers generally available in Q1=20 2019=85 = From owner-freebsd-arm@freebsd.org Fri Jan 4 20:31:56 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 121FA1438F59 for ; Fri, 4 Jan 2019 20:31:56 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2E5282E51 for ; Fri, 4 Jan 2019 20:31:54 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-ed1-x541.google.com with SMTP id a20so26037792edc.8 for ; Fri, 04 Jan 2019 12:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zBt6Rm+Qw2MeW6DsPKXRJwzmXsL/VZEV2Wk4is51NWI=; b=bL7V8+c3hcLD0I4hHYRk2cEFSWPGCa3Rj/OuoA0g/rJXF5Ue5f2cFoY2CD8qrIYdyR L/oy+2Pfo52oQK1nJleC2liknybvnPpouGH0rv/rYBo2D5ENkbzpZShC1WWpJYdpIEiI N/pmwNsUB2uWW2i3cTVpQ4qsyxCcHk9xrfGSmYYmM2HcE21SRNCwmBtaiAy7ZvdVsUE0 /cZ8ujNiS9UOy/VL6G5cjuCyHRnOQS1ZAcZbkQyN8zmyIU1IeZUfoiYcudGAiQe5b9Jf lpt31eWxfRJLERuzEyAkhxGFGCC7lewIZshFh9m9lafOtPbxakdo6l0FRa8o+DOu1ZyT V9rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zBt6Rm+Qw2MeW6DsPKXRJwzmXsL/VZEV2Wk4is51NWI=; b=Kb0YUNb+6VO9cS+yU+4rZqZGNcOXrr0FOXBhtdJjI9FbSbqxbmHLvwDmMxuZbobpBx mQRpE5U/aEqD44y3zqaIbXCE//oNIaj0HE1o6dwJMDY0Sn4es3lgFMtAbwYjfT0tVDKo utpqsXMWGYmJ/sriIxkpTWRieiU4bUeuSP/na2X0ljA4Oft0wrZxU7w0RhuM0BFqYnD4 cwbBmuOYXn6I7Cbcm7rgVZvOFmlp9r/12cfnPjGL7ctJQPgUJXUD8zytHqqKIoq2prRD rbqOiNaJX7lZ+4ma46mM8DYdSCFtqrCD2L4Td/xVleljWbZAJ0gtJIlqwR+0mU51oUTc juqQ== X-Gm-Message-State: AA+aEWa7OW7b4YRpIa0dxStFYb6wyT+ZW5qVNtETQhF+yOgTe3N8QmeC /mTGusdbyYYeINZcLZiunXckJBQZnDe33w== X-Google-Smtp-Source: AFSGD/VT0cqgyw6gP+bKizmUzy8+PB2CodigCsNQNlsx6oafkOHMpBfFj3r+/EMvYSzzAWKgve0/Hg== X-Received: by 2002:a17:906:6442:: with SMTP id l2-v6mr39133694ejn.73.1546633913503; Fri, 04 Jan 2019 12:31:53 -0800 (PST) Received: from mutt-hbsd (232.ip-54-39-148.net. [54.39.148.232]) by smtp.gmail.com with ESMTPSA id cd6-v6sm13626098ejb.14.2019.01.04.12.31.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 04 Jan 2019 12:31:52 -0800 (PST) Date: Fri, 4 Jan 2019 15:31:33 -0500 From: Shawn Webb To: "Jayachandran C." Cc: Ed Maste , "freebsd-arm@freebsd.org" Subject: Re: ThunderX2 support in FreeBSD/arm64 Message-ID: <20190104203133.euftenspsfxp7vyq@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yp2u43dytvahevui" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT FreeBSD 13.0-CURRENT HARDENEDBSD-13-CURRENT amd64 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: D2E5282E51 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=bL7V8+c3; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2a00:1450:4864:20::541 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-5.80 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; IP_SCORE(-0.71)[ip: (0.06), ipnet: 2a00:1450::/32(-1.89), asn: 15169(-1.66), country: US(-0.08)]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[] 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, 04 Jan 2019 20:31:56 -0000 --yp2u43dytvahevui Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 03, 2019 at 12:51:26PM -0800, Jayachandran C. wrote: > (Was AFK for a while, sorry for the late reply) > Hi Ed, >=20 > On Fri, Dec 21, 2018 at 11:15 AM Ed Maste wrote: > > > > On Mon, 17 Dec 2018 at 21:51, Jayachandran C. wr= ote: > > > > > > Over the last few weeks I have committed changes for a few outstanding > > > items needed for ThunderX2 support in FreeBSD/arm64. > > > > I see that D10082, D10083, D10084 are still open, awaiting review. > > Should I apply them to my test tree? > > > > My current status - loader claims to start the kernel, but I see no > > further output. Can you share the kernel config file you used (or > > perhaps a git tree you built from)? >=20 > There seems to be 2 issues here - both of them happen when the AMI > firmware is used. > The first issue is that the efi framebuffer does not work, and I am > not able to select the serial console with AMI firmware. The second > issue is that the on-chip SATA controller is not setup correctly by > the AMI firmware and can cause a 'NBU BAR error' failure. >=20 > I have uploaded a test firmware and instructions to > https://people.freebsd.org/~jchandra/testfw/ which should boot FreeBSD > fine. This is an internal build which does not have both the problems > above. Let me know if this works, and I will try to push the fixes to > AMI. Hey Jayachandran, I'll apply the test firmware on my end either this weekend or Monday. I'll report back afterwards. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --yp2u43dytvahevui Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlwvwqAACgkQaoRlj1JF bu5xLQ//S2pa3f2h6im7BA0bkLtrlQAW551KVP/n488pp0V+ZVLQyo6PdpHr8ECe wi/lLU672FK/KsLptJFum8trPOtZWbhyPBV0v32fAvLNDUw0WTrRMgzTMtOZJcBC xKvUpwZ2GzniNdc4Yv1mqYa/ipjnW+g4kWBYzIIOLZxP3y9YgaB+LvYrPpkKhuPg BOn1eVRX/l2Bt4fuPzhYFbfIFmeQ/BpECSWGcGZMxgQdA0KNxdUXNuZynxtMCMka bnUAgg1l0zyyIKzfI838yxi0dYYKe/UJ0P0iSKklRTTfeiQPRWqs3B+js4r2h1le nWJEbRoA1pawbyjlm1QJZ07oXjU0dc4e7S4lMTOhcI1pZscNGDjXr7EpS/6XO5p3 xK/ITudD270YXdQfdsfsnfJz121T+P8gym+wKtZXlZ40LOSZCU99Iqo0VH5nXIz2 i/lvn6A7Ejm50MQmHGYXX0SPPUy3eXDE2S+5AyO4OSSCQsyNoq0GzDxSZ9nAgA1K 9zn8OgTqTlze8Mj+C/p0EX3sWkdWmkW9Pr4WDNe4cbgz3lIXQ+tWNleBx1PAGK+E Lj0MFCH4GqwQHBnvdoX/NFDVZeMyllrfg5vP4kpDmHIcSWXwA4Hq4nzzsYufYB+C xGIy07amLgvt7pjNQGBtskbith2wAStdjJRKKpRK4v7bSC78udg= =io+Y -----END PGP SIGNATURE----- --yp2u43dytvahevui-- From owner-freebsd-arm@freebsd.org Sat Jan 5 00:53:03 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D1471440769; Sat, 5 Jan 2019 00:53:03 +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 59B8A8C949; Sat, 5 Jan 2019 00:53:02 +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 x050r7UP031650 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Jan 2019 16:53:08 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x050r70x031649; Fri, 4 Jan 2019 16:53:07 -0800 (PST) (envelope-from fbsd) Date: Fri, 4 Jan 2019 16:53:06 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska , freebsd-ports@freebsd.org Subject: Re: How much memory to compile www/chromium? Message-ID: <20190105005306.GA31380@www.zefox.net> References: <20181212165313.GA84881@www.zefox.net> <20181212184149.ol44fon2unowu35q@squirrel.exwg.net> <20181212192115.GA85583@www.zefox.net> <20181212202504.4n3mhtx7grbeh6j7@squirrel.exwg.net> <20181214012733.GA92808@www.zefox.net> <20181218174903.GA41072@www.zefox.net> <20190101182153.GA13944@www.zefox.net> <66584297-22E7-4D94-963A-5FD4D9130686@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66584297-22E7-4D94-963A-5FD4D9130686@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 59B8A8C949 X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.74 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.71)[0.711,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.960,0]; MX_GOOD(-0.01)[cached: www.zefox.net]; NEURAL_SPAM_LONG(0.92)[0.919,0]; IP_SCORE(0.26)[ip: (0.90), ipnet: 50.1.16.0/20(0.45), asn: 7065(0.04), country: US(-0.08)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[] 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, 05 Jan 2019 00:53:03 -0000 > > On 2019-Jan-1, at 10:21, bob prohaska wrote: > > > On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: > >> > >> Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile successfully over > >> several days. The -DBATCH option was used, in hopes it'd fetch the right options. > >> > > > > Just for fun I added a mechanical hard disk with a 4 GB swap partition and re-ran > > the www/chromium compilation with MAKE_JOBS_NUMBER_LIMIT unset, to see what happens. > > OOMA was turned off with vm.pageout_oom_seq="2048" in /boot/loader.conf. > > > > After ~11 days the process finished. Log files of gstat output and make output are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/mech_sd/ > > > > As a further test, I'ved added two additional USB flash swap devices and am re-running > > the compilation of www/chromium. The swap layout is quite lopsided, with the USB flash > > devices having only 2 GB swap partitions on each, contrasting to the 4 GB swap partitions > > on the microSD card and mechanical disk. > > The attempt to compile chromium using four USB swap partitions didn't complete, but it might have gotten far enough to be surprising. Swap use peaked around 2.4 GB, while the dual swap partition setup used around 3.5 GB of swap at maximum. The make failure happened near the 17000 counter point, when the controlling ssh connection was dropped. I _think_ that's past the point of maximum swap use, but I'll have to re-try to make sure. The log files are at http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/flash_mech_sd/ in case anybody is curious. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Jan 5 12:12:52 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E750D14995DB for ; Sat, 5 Jan 2019 12:12:51 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 9562D802F0 for ; Sat, 5 Jan 2019 12:12:50 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1546689365; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=iiDZWwxKgkIW/s6Z5x10UpRf/NWeN00bdFL8CaIYefPsPEOizDhUfMxU8qBHzaAg8WOqfA5Ej9DSP PqaQlc+tg4ENj0E3XgIRfCMx/0gi+oa1LwJWTQC724DJrDU0Mr2r0w+zGnigSHuyXYL/6R8Pm1hEb0 XRCwxel3Bvtna1sTDKdho3LIvncWtO10qjRYkNiXaO5RSiV/cMmA5bISePUG8lvQg7vLave7HB/3gU WrFxQu2Mqt5H0Rnlf7aqmHqjOjBwFz4PENDrRarS/Mt2JBUe1WH7IlkaydX34V/eXprxJl9GnWMRPM 4TBx6j5Py10QMKNbpmb+MjOTgU4LiPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:mime-version:date:message-id:subject: from:to:dkim-signature:from; bh=h+L14S7jXLqcDf9sS7+M6CXd2Glj1o0ia160xYgCt3Q=; b=P3EM/8eTZYiffNGjSR8Xh6S8Epdd5sbn70QLirB8fJExhTACA4R4GFZAbkSsGpyVB+bEV/L9Dks47 VLJaQCS/O3q9PuZZuxLVdICr8DyoSJ29n8050chBQRQ2sw4peHwJHagj1iIKGvHhUqr6GBzUFHdJ42 3fYkgZOvwli8jclOT2Pc+1X7oyTPr0st2jMhsFE44zz/irBX3mp7zoPLwEF3dV4sK7hespMEzibbTf DetSji0c0+gjRxLVuhqLd4CsC1lsXTaisbkQXVtf3oL14cHcuwmAuhWtxtwBTlQ9tftH5utAJJrtwb KOzzptrmGfgY9w6qRVIz/S1Mg3u2IGQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.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:content-type:mime-version:date:message-id:subject: from:to:from; bh=h+L14S7jXLqcDf9sS7+M6CXd2Glj1o0ia160xYgCt3Q=; b=MXnavdEnMhWCfM3y+8Rm2oSdqLbCLO2WWY6Ajm4SEOLwNm5Xth7iHhUXpXWyaoKjptyPPzxZbOs32 IpHpjv4DqOMzRVB7J+1gfJpU45ZT6u5mWKNx8WAU2RuLLY1T8ksCHWg6n1w+3DMEcsdFksiYpn/gYM w4do3AmDB1dvKxN0sQ9H15oLnBRnYOGthFsd62+9i2kCjVRZYf2WOkW4aO2zF09W4XB300ollyUe/r bOvUXX/itLeE84DTmgqabCB/b1UEjnsG2MvKeADU9Oqdl4kzGe6MwJH+0uG+cEqOtxzziVn/xPW5ds NkzN1ZG4Xz2c2ORiCXY8V9ktVU898aA== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: deac06d4-10e0-11e9-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.152.101 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.152.101]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id deac06d4-10e0-11e9-befd-af03bedce89f; Sat, 05 Jan 2019 11:56:03 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x05BuYI2070075 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 5 Jan 2019 12:56:35 +0100 (CET) (envelope-from per@hedeland.org) To: freebsd-arm@freebsd.org From: Per Hedeland Subject: i2c on RPi Zero? Message-ID: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> Date: Sat, 5 Jan 2019 12:56:34 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9562D802F0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=MXnavdEn X-Spamd-Result: default: False [-4.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; MX_GOOD(-0.01)[hedeland.org,mx2.mailhop.org]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-1.24)[ipnet: 54.148.0.0/15(-4.87), asn: 16509(-1.25), country: US(-0.08)]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[i=1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; RECEIVED_SPAMHAUS_PBL(0.00)[101.152.228.81.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[hedeland.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[64.219.148.54.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.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: Sat, 05 Jan 2019 12:12:52 -0000 Hi, Is i2c expected to work on Raspberry Pi Zero? I have FreeBSD running just fine on it from FreeBSD-12.0-RELEASE-arm-armv6-RPI-B.img, but there is no mention of iic at boot (dmesg), and no /dev/iic* - while on a Pi B with FreeBSD-11.0-STABLE-arm-armv6-RPI-B-20170105-r311441.img (sorry about the different versions) I see: iichb0: mem 0x205000-0x20501f on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x804000-0x80401f on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 Also "What works" on https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi has just an ominous question mark for i2c on Zero...:-) Any hints for debugging/testing would be appreciated. Thanks --Per Hedeland From owner-freebsd-arm@freebsd.org Sat Jan 5 14:48:22 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD06B149D379 for ; Sat, 5 Jan 2019 14:48:22 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound1p.ore.mailhop.org (outbound1p.ore.mailhop.org [54.149.210.130]) (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 6CD67854DF for ; Sat, 5 Jan 2019 14:48:20 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1546698697; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=C1RNSRpFxY1ijWnGnXuC6KxQb6TRKPgG5ukCPdTIynXdk7qj+4ynvvHXCSu5bW0iJLgZtQU4Wgn0X nHfMY3n/NMVVNLL9u8jkpImcW56knwIUlsRnHSuA58cBEvnTvJYuBUSXlD6uyG/vIfA87ZlW406Dqp QbtdSWBwgFBmCFYTXuSfekTcibseFpIAQueD/haG8jNmeQ6m5Hz83gK62mmqiNRoWsuUJLJ8yCKRee U4W8SDIFiPmpEYjpHq4yM3ShS46XbP6lzIk2HXXF5GUc2vtJlvr+uItlSCYHOVxmV8SSu3hTLiQLRB PtC1HoKD7gDn36xS3ddxGgOgxA3yiZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:dkim-signature:from; bh=mmpIJU2n6ihKHG0cpGpffjZZNROVAsCoJOGVuO9D39Q=; b=pV1r3/y/pdF1inIaCJpacGHYN7K1qFvPu/lu6nVZoN25YnLcCF53NGEdtV0qYoVnalyKuPTkWdOZf 4Vopi3vM9FvQAsUqh6+iMvmhFw8+Te2FljzD+/XZEIdfPGtrhy6DREahp3/F7mq1jov1h3CjbBM3XD y/IFvR02pMgwPHyFFPcdyNZEFt5ddZf9fLqd1oXXnPnJUykj9EvuIxZbppy/ljq18Wi9b00bis2NOL yz45R9AomhaafjOFSZkudeblPOgbVZX5E3Tb8U6g/oHoUM9kOLSs5045BQEgkvlnH4bxdMOCfe8cL3 WZZXH5AlJIejy/XKGM623KTDifAzSQQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.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:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:from; bh=mmpIJU2n6ihKHG0cpGpffjZZNROVAsCoJOGVuO9D39Q=; b=arXY5/8al42HFgXJzaibprR+eNeyj/uCGc+xJSAapFfeTxmFIclAgvK83GRhv8yBk1rLBpqLf8vFE ecujrI47LHSlAAg+Ih9ALMo81TPb3jLD/loDCIqiriAoCg+0sdVaviGr9fCDVNKFg7LxsUxHS129SB H00clPDoSOgGZCRfgr1ocvrNGpQlsz6ZKqeJlasY0OtV7jJjse9KxHC9hr0IV98tF6DKyBg9KKVC3c XEfp0i2oLxUA4WDbFZAM6ebDA+GHkjsx7Qa/8Iup7Q0bHiD/+c3niXzY96j47WBzmxYlPcl1bBS2Ba wVFyxmz+hbl+kBm5qEqBWNNY3/AmIcQ== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 99f3d959-10f6-11e9-a59a-7b143e15dabc X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.152.101 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.152.101]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 99f3d959-10f6-11e9-a59a-7b143e15dabc; Sat, 05 Jan 2019 14:31:36 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x05EW7Ij070954 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 5 Jan 2019 15:32:07 +0100 (CET) (envelope-from per@hedeland.org) Subject: Re: i2c on RPi Zero? To: freebsd-arm@freebsd.org References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> From: Per Hedeland Message-ID: Date: Sat, 5 Jan 2019 15:32:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6CD67854DF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=arXY5/8a X-Spamd-Result: default: False [-4.52 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; MX_GOOD(-0.01)[cached: hedeland.org]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-1.24)[ipnet: 54.148.0.0/15(-4.86), asn: 16509(-1.25), country: US(-0.08)]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[i=1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; RECEIVED_SPAMHAUS_PBL(0.00)[101.152.228.81.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[hedeland.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[130.210.149.54.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.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: Sat, 05 Jan 2019 14:48:22 -0000 I did a bit more testing on the Zero to see if the FreeBSD version mattered: FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no luck. FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! (I.e. dmesg reports as below and /dev/iic{0,1} get created - I haven't tested actual usage beyond having 'i2c -s' report "no devices found".) I guess that the i2c support hasn't been removed intentionally, i.e. this seems to be a regression - or is there some additional config etc required to enable it with FreeBSD-12? The iic and iicbus drivers appear to be built into the kernel in both 11 and 12. (I haven't tested FreeBSD-12 on the Pi B, but I would guess that the result will be the same as on the Zero, since it seems the hardware is the same.) --Per Hedeland On 2019-01-05 12:56, Per Hedeland wrote: > Hi, > > Is i2c expected to work on Raspberry Pi Zero? I have FreeBSD running > just fine on it from FreeBSD-12.0-RELEASE-arm-armv6-RPI-B.img, but > there is no mention of iic at boot (dmesg), and no /dev/iic* - while > on a Pi B with > FreeBSD-11.0-STABLE-arm-armv6-RPI-B-20170105-r311441.img (sorry about > the different versions) I see: > > iichb0: mem 0x205000-0x20501f on simplebus0 > iicbus0: on iichb0 > iic0: on iicbus0 > iichb1: mem 0x804000-0x80401f on simplebus0 > iicbus1: on iichb1 > iic1: on iicbus1 > > Also "What works" on > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi has just an > ominous question mark for i2c on Zero...:-) > > Any hints for debugging/testing would be appreciated. > > Thanks > > --Per Hedeland > _______________________________________________ > 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 Sat Jan 5 19:58:21 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D410C141F8F4 for ; Sat, 5 Jan 2019 19:58:20 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 C68E26A648 for ; Sat, 5 Jan 2019 19:58:19 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1gfs5B-000E2S-OU; Sat, 05 Jan 2019 11:58:10 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id x05Jw92T053967; Sat, 5 Jan 2019 11:58:09 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sat, 5 Jan 2019 11:58:08 -0800 From: Oleksandr Tymoshenko To: Per Hedeland Cc: freebsd-arm@freebsd.org Subject: Re: i2c on RPi Zero? Message-ID: <20190105195808.GA53872@bluezbox.com> References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Per Hedeland (per@hedeland.org) wrote: > I did a bit more testing on the Zero to see if the FreeBSD version > mattered: > > FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no > luck. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: C68E26A648 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [2.77 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_SPAM_SHORT(0.55)[0.548,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; NEURAL_SPAM_MEDIUM(0.51)[0.507,0]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mx.bluezbox.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.42)[0.422,0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.61)[asn: 14061(3.12), country: US(-0.08)] 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, 05 Jan 2019 19:58:21 -0000 Per Hedeland (per@hedeland.org) wrote: > I did a bit more testing on the Zero to see if the FreeBSD version > mattered: > > FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no > luck. > > FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! > (I.e. dmesg reports as below and /dev/iic{0,1} get created - I haven't > tested actual usage beyond having 'i2c -s' report "no devices found".) > > I guess that the i2c support hasn't been removed intentionally, > i.e. this seems to be a regression - or is there some additional > config etc required to enable it with FreeBSD-12? The iic and iicbus > drivers appear to be built into the kernel in both 11 and 12. > > (I haven't tested FreeBSD-12 on the Pi B, but I would guess that the > result will be the same as on the Zero, since it seems the hardware is > the same.) There was a transition in device tree files between 11 and 12. bcm2708-rpi-0-w.dtb has i2c nodes but they're disabled by default. Try editing config.txt on FAT partition and adding following line: dtparam=i2c This should make boot firmware to enable device nodes in the device tree blob during the boot. -- gonzo From owner-freebsd-arm@freebsd.org Sat Jan 5 21:41:06 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D89E1423FF8 for ; Sat, 5 Jan 2019 21:41:06 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound1g.eu.mailhop.org (outbound1g.eu.mailhop.org [52.28.6.212]) (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 7F9526E489 for ; Sat, 5 Jan 2019 21:41:05 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1546723494; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=fi0RTum42igWTzA03yauNZKyTbYKgLIzOoXhG/9HTwMRio66XNZbr+lbC1RTiP50eJP9rBist0pIw kKEG7hPqD7xH8g9HGgjSxPQ0HCDkpL3J70ve0l/9DmrLzT1eFZAZ3sRdW556kIY1TQ3WxcWF2elyq/ XO3HhK8mYlcZ5MDsDmOzj6Acnp0IGTc8YqU79HlyUXkabwtz+cnKEaIyAqI4GKJoDi8X3n/Jy5KcOt GIKNpdJYxxmiTHeIGeB/ePQFM+U0qTaZYkup0s7ygoAQkpygowCTez04zmsCvopXa3VCg8o7r70dEC bbJaD/ukvdcWlrjAT3revhxL/8iVoig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=Hi/KB7KFyGZgB393XQv+7nWSd+lnNhBXXLIpjj6Ezgw=; b=JTeh9cu8LZKS+wpvZ2qPoAZfHdrcp/wR2eUrbigIUWWywXZJ5xtH4/FjrU9+rgDE2ymqt1dLpXL9R UmWN6WyZWROHSSfKLcG1jMJ+8/Ep/d1je8megZMxlqAs2ozpYpMv8T3Vrup0pUTyh8mZ7l5R7rUy9g ctIB3YHxV3U/GRJDxMzsmWYzVBxPC8aXVusPOpWvLUO90e/zoif4P7C69Z/7Ty30FtI9vEzZdi52qw Um9c1S0D4lNJb///KiAygWu6PZ12WGAct5zE0mxLSZ1wyr5bMhRSuDCcem0P3l8b7NqZ77Ri/mKLr3 oOptihibnFDtBdeNI3dY69g+3fh9MSg== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.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:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=Hi/KB7KFyGZgB393XQv+7nWSd+lnNhBXXLIpjj6Ezgw=; b=OHgLZYX1xmdKMW/pgvUrf4rQ9wkTzqPhj6Snn0GDNMLAM7Vxy76ETeUEy61cGnoix9CPBqhHK49yQ qkev7rIbimXVXEq3P9osHZXABwpIRh9ZVThJQ2TcWgx5IEMyCGYHzBExLQze5MD+Bbi8Kz8tY/QmmO 9ra3Zc//BnLMF00vqxniAUrMn1LyH9D/APuew0Uc9YxQfA5bGNqOaFEhqn5Lc26BIFTpU+yYOG/6bP xx54yHXyD2rRyIfQzdVD8hrB3px93sQe75JXMi3fkwwIcopqnTlgQtnjFKO4RtUoruyqhfNgutJ0Ek E3g6aNQR1g717jQ2KGQP4VYuZz7AKxg== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 55c59a8e-1130-11e9-8a28-a1efd8da9a94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.152.101 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.152.101]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 55c59a8e-1130-11e9-8a28-a1efd8da9a94; Sat, 05 Jan 2019 21:24:51 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x05LOojj072293 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 5 Jan 2019 22:24:50 +0100 (CET) (envelope-from per@hedeland.org) Subject: Re: i2c on RPi Zero? To: Oleksandr Tymoshenko Cc: freebsd-arm@freebsd.org References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> <20190105195808.GA53872@bluezbox.com> From: Per Hedeland Message-ID: Date: Sat, 5 Jan 2019 22:24:49 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190105195808.GA53872@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7F9526E489 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=OHgLZYX1 X-Spamd-Result: default: False [-3.47 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; MX_GOOD(-0.01)[cached: hedeland.org]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.89)[-0.893,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.27)[asn: 16509(-1.25), country: US(-0.08)]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[i=1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; RECEIVED_SPAMHAUS_PBL(0.00)[101.152.228.81.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.6.28.52.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.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: Sat, 05 Jan 2019 21:41:06 -0000 On 2019-01-05 20:58, Oleksandr Tymoshenko wrote: > Per Hedeland (per@hedeland.org) wrote: >> I did a bit more testing on the Zero to see if the FreeBSD version >> mattered: >> >> FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no >> luck. >> >> FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! >> (I.e. dmesg reports as below and /dev/iic{0,1} get created - I haven't >> tested actual usage beyond having 'i2c -s' report "no devices found".) >> >> I guess that the i2c support hasn't been removed intentionally, >> i.e. this seems to be a regression - or is there some additional >> config etc required to enable it with FreeBSD-12? The iic and iicbus >> drivers appear to be built into the kernel in both 11 and 12. >> >> (I haven't tested FreeBSD-12 on the Pi B, but I would guess that the >> result will be the same as on the Zero, since it seems the hardware is >> the same.) > > There was a transition in device tree files between 11 and 12. > bcm2708-rpi-0-w.dtb has i2c nodes but they're disabled by default. > Try editing config.txt on FAT partition and adding following line: > > dtparam=i2c > > This should make boot firmware to enable device nodes in the device > tree blob during the boot. Thanks a lot! I can confirm that this makes i2c "work" on Zero with 12-RELEASE (almost) to the extent described above for 11.2-STABLE (it detects/creates only iic0, not iic1, but as far as I understand from other sources, iic0 is all that is needed for "plain B" and thus also for Zero). Should I file a PR for this? I assume that the i2c nodes being disabled is not intentional... --Per Hedeland From owner-freebsd-arm@freebsd.org Sat Jan 5 21:56:14 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 510A314247B4 for ; Sat, 5 Jan 2019 21:56:14 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 5BD4F6ED9F for ; Sat, 5 Jan 2019 21:56:13 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1gftvN-000EOa-5w; Sat, 05 Jan 2019 13:56:09 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id x05Lu8sn055339; Sat, 5 Jan 2019 13:56:08 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sat, 5 Jan 2019 13:56:08 -0800 From: Oleksandr Tymoshenko To: Per Hedeland Cc: freebsd-arm@freebsd.org Subject: Re: i2c on RPi Zero? Message-ID: <20190105215608.GA55315@bluezbox.com> References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> <20190105195808.GA53872@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Per Hedeland (per@hedeland.org) wrote: > On 2019-01-05 20:58, Oleksandr Tymoshenko wrote: > > Per Hedeland (per@hedeland.org) wrote: > >> I did a bit more testing on the Zero to see if the FreeBSD ver [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 5BD4F6ED9F X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [3.05 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_SPAM_SHORT(0.61)[0.610,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; NEURAL_SPAM_MEDIUM(0.72)[0.715,0]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mx.bluezbox.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.43)[0.427,0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.61)[asn: 14061(3.12), country: US(-0.08)] 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, 05 Jan 2019 21:56:14 -0000 Per Hedeland (per@hedeland.org) wrote: > On 2019-01-05 20:58, Oleksandr Tymoshenko wrote: > > Per Hedeland (per@hedeland.org) wrote: > >> I did a bit more testing on the Zero to see if the FreeBSD version > >> mattered: > >> > >> FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no > >> luck. > >> > >> FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! > >> (I.e. dmesg reports as below and /dev/iic{0,1} get created - I haven't > >> tested actual usage beyond having 'i2c -s' report "no devices found".) > >> > >> I guess that the i2c support hasn't been removed intentionally, > >> i.e. this seems to be a regression - or is there some additional > >> config etc required to enable it with FreeBSD-12? The iic and iicbus > >> drivers appear to be built into the kernel in both 11 and 12. > >> > >> (I haven't tested FreeBSD-12 on the Pi B, but I would guess that the > >> result will be the same as on the Zero, since it seems the hardware is > >> the same.) > > > > There was a transition in device tree files between 11 and 12. > > bcm2708-rpi-0-w.dtb has i2c nodes but they're disabled by default. > > Try editing config.txt on FAT partition and adding following line: > > > > dtparam=i2c > > > > This should make boot firmware to enable device nodes in the device > > tree blob during the boot. > > Thanks a lot! I can confirm that this makes i2c "work" on Zero with > 12-RELEASE (almost) to the extent described above for 11.2-STABLE (it > detects/creates only iic0, not iic1, but as far as I understand from > other sources, iic0 is all that is needed for "plain B" and thus also > for Zero). > > Should I file a PR for this? I assume that the i2c nodes being > disabled is not intentional... Yes, please do. There are also other devices, that should be enabled by default, like SPI. Thanks -- gonzo From owner-freebsd-arm@freebsd.org Sat Jan 5 22:09:52 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E68361424C33 for ; Sat, 5 Jan 2019 22:09:51 +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 9B3856F509 for ; Sat, 5 Jan 2019 22:09:50 +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 d2b00498; Sat, 5 Jan 2019 23:03:07 +0100 (CET) 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=65kSoiangd8/mEuhHPYAxYYxb+8=; b=FiOX8yep0AnIQ8oCQmqev/0tEZ5+ v6oin1KgHlD2U7FZ/PaKq91y4aTGBUF6o+twbMm2RiGWW+us71T5kt3A03zPTu7B uAlP3oapJf1jpfOCDQ4RlWUt2fheT07TbIoUWq93mUHBt+/m8coy5C7SCldrBao/ Ni7sXa1rnCf3Krc= 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=RK+JTvifbqNTNg1KCgzy5fzYq+jjEjMJc9pYqLO3/BiXLQfRHNo6MErf aKMVzsia9XhgAOyfUluOWzo7aMQ4g+Jh18yepf/fu4ChbNNB+ELKYZrvJIZP7VhP C/Cq7UgE/fHby1YUw8wX+U8NCdUl6qDmtUQCnvghRvXFuZYiLKU= Received: from knuckles.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id ec54e20d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 5 Jan 2019 23:03:07 +0100 (CET) Date: Sat, 5 Jan 2019 23:03:06 +0100 From: Emmanuel Vadot To: Oleksandr Tymoshenko Cc: Per Hedeland , freebsd-arm@freebsd.org Subject: Re: i2c on RPi Zero? Message-Id: <20190105230306.2ad9d0ba2c2df0e8fac5f053@bidouilliste.com> In-Reply-To: <20190105215608.GA55315@bluezbox.com> References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> <20190105195808.GA53872@bluezbox.com> <20190105215608.GA55315@bluezbox.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: 9B3856F509 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mail header.b=FiOX8yep; 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 [-0.12 / 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.78)[-0.777,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.91)[-0.912,0]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.35)[0.351,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MX_GOOD(-0.01)[mx-backup.blih.net,mail.blih.net]; IP_SCORE(0.13)[ipnet: 212.83.160.0/19(0.80), asn: 12876(-0.13), country: FR(-0.02)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.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: Sat, 05 Jan 2019 22:09:52 -0000 On Sat, 5 Jan 2019 13:56:08 -0800 Oleksandr Tymoshenko wrote: > Per Hedeland (per@hedeland.org) wrote: > > On 2019-01-05 20:58, Oleksandr Tymoshenko wrote: > > > Per Hedeland (per@hedeland.org) wrote: > > >> I did a bit more testing on the Zero to see if the FreeBSD version > > >> mattered: > > >> > > >> FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no > > >> luck. > > >> > > >> FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! > > >> (I.e. dmesg reports as below and /dev/iic{0,1} get created - I haven't > > >> tested actual usage beyond having 'i2c -s' report "no devices found".) > > >> > > >> I guess that the i2c support hasn't been removed intentionally, > > >> i.e. this seems to be a regression - or is there some additional > > >> config etc required to enable it with FreeBSD-12? The iic and iicbus > > >> drivers appear to be built into the kernel in both 11 and 12. > > >> > > >> (I haven't tested FreeBSD-12 on the Pi B, but I would guess that the > > >> result will be the same as on the Zero, since it seems the hardware is > > >> the same.) > > > > > > There was a transition in device tree files between 11 and 12. > > > bcm2708-rpi-0-w.dtb has i2c nodes but they're disabled by default. > > > Try editing config.txt on FAT partition and adding following line: > > > > > > dtparam=i2c > > > > > > This should make boot firmware to enable device nodes in the device > > > tree blob during the boot. > > > > Thanks a lot! I can confirm that this makes i2c "work" on Zero with > > 12-RELEASE (almost) to the extent described above for 11.2-STABLE (it > > detects/creates only iic0, not iic1, but as far as I understand from > > other sources, iic0 is all that is needed for "plain B" and thus also > > for Zero). > > > > Should I file a PR for this? I assume that the i2c nodes being > > disabled is not intentional... > > Yes, please do. There are also other devices, that should be enabled by > default, like SPI. Why should we enabled them by default ? We have no correct way for switching a pin to gpio mode (you can do that with gpioctl on some system but I consider it as a bug) so if I want to use the i2c/spi/whatever pins as gpio and the default image set it to another function I'm stuck. Using the rpi fundation dtb means that every settings that they set for Linux will also be set for us, so every tutorial on the web where people saying that you should set something in config.txt will apply to FreeBSD too. The current settings aren't a bug, it's a feature (c). > Thanks > > -- > gonzo > _______________________________________________ > 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 From owner-freebsd-arm@freebsd.org Sat Jan 5 23:27:44 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C80B14270D9; Sat, 5 Jan 2019 23:27:44 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from ecc03.stack.nl (unknown [IPv6:2001:610:1108:5010::210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 370D772CC9; Sat, 5 Jan 2019 23:27:40 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mail01.stack.nl (blade.stack.nl [51.15.111.152]) by ecc03.stack.nl (Postfix) with ESMTPS id 5993D2188A; Sat, 5 Jan 2019 23:27:23 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.stack.nl (Postfix) with ESMTP id 253B160989; Sat, 5 Jan 2019 23:27:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail01 Received: from mail01.stack.nl ([127.0.0.1]) by localhost (mail01.stack.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs-VNT8GTDpz; Sat, 5 Jan 2019 23:27:20 +0000 (UTC) Received: from blade.stack.nl (blade.stack.nl [192.168.122.130]) by mail01.stack.nl (Postfix) with ESMTP id E116060962; Sat, 5 Jan 2019 23:27:20 +0000 (UTC) Received: by blade.stack.nl (Postfix, from userid 1677) id C41962091A; Sun, 6 Jan 2019 00:27:20 +0100 (CET) Date: Sun, 6 Jan 2019 00:27:20 +0100 From: Jilles Tjoelker To: mmel@freebsd.org Cc: Dennis Clarke , freebsd-arm@freebsd.org, FreeBSD Current , Mark Millard Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) Message-ID: <20190105232720.GA13476@stack.nl> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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, 05 Jan 2019 23:27:44 -0000 On Fri, Jan 04, 2019 at 07:56:42AM +0100, Michal Meloun wrote: > On 29.12.2018 18:47, Dennis Clarke wrote: > > On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote: > >> > >> On 2018-Dec-28, at 12:12, Mark Millard wrote: > >> > >>> On 2018-Dec-28, at 05:13, Michal Meloun > >>> wrote: > >>> > >>>> Mark, > >>>> this is known problem with qemu-user-static. > >>>> Emulation of every single interruptible syscall is broken by design (it > >>>> have signal related races). Theses races cannot be solved without major > >>>> rewrite of syscall emulation code. > >>>> Unfortunately, nobody actively works on this, I think. > >>>> > > Following along here quietly and I had to blink at this a few times. > > Is there a bug report somewhere within the qemu world related to this > >  'broken by design' qemu feature? > Firstly, I apologize for late answer. Writing a technically accurate but > still comprehensible report is extremely difficult for me. > Major design issue with qemu-user is the fact that guest (blocking / > interruptible) syscalls must be emulated atomically, including > delivering of asynchronous signals (including signals originated by > other thread). > This is something that cannot be emulated precisely by user mode > program, without specific kernel support. Let me explain this in a > little more details. > [snip] > This look a much better. The code blocks all signals first, then checks > if any signal is pending. If yes, then does not-blocking select() > (because timeout is zero) and correctly returns EINTR immediately. > Otherwise, it uses other variant of select(), pselect() which adjusts > right signal mask itself. > That's mean that syscall is called with blocked signal delivery, but > kernel adjusts right sigmask before it waits for event. While this looks > like perfect solution and this code closes all races from first version, > then it doesn't. pselect() uses different semantic that select(), it > doesn't update timeout argument. So this solution is also inappropriate. FreeBSD select() never updates the passed timeout. When emulating Linux syscalls, this will have to be done manually. > Moreover, I think, we don't have p equivalents for all blocking > syscalls. We definitely do not. For example, open() has no equivalent with a signal mask. > Mark, I hope that this is also the answer to your question posted to > hackers@ and also the exploitation why you see hang. > Linux uses different approach to overcome this issue, safe_syscall -> > https://gitlab.collabora.com/tomeu/qemu/commit/4d330cee37a21aabfc619a1948953559e66951a4 > It looks like workable workaround, but I'm not sure about ERESTART > versus EINTR return values. Imho, this can be problem. This looks like a reasonable solution. Musl libc uses the same approach to implement pthread cancellation (where with the default "deferred" cancellation type, cancellation takes effect at cancellation points only, which include most blocking system calls; if a cancellation request comes in at the same time as a blocking cancellation point system call starts, the same race condition needs to be avoided). As for ERESTART vs EINTR, EINTR can be treated like any other error. On the other hand, ERESTART (or variants like ERESTARTSYS) is never returned by the kernel, but instead causes the kernel to rewind the program counter (so the system call instruction will be executed again) just before invoking the signal handler. Therefore, when the host kernel does this to qemu, qemu must do the same to the guest. If a signal is delivered just before qemu makes a system call on behalf of the guest, this may look like ERESTART. This is fine since it looks the same as if the signal was delivered just before the guest's system call instruction. The approach as used by FreeBSD libc to implement pthread cancellation (thr_wake(2) on self in the signal handler) will not let you distinguish between ERESTART and EINTR, so you would have to replicate that determination (which typically but not always depends on the signal's SA_RESTART flag and which system call it is). Therefore, I would not recommend that approach. > I have list of other qemu-user problems (I mean mainly a bsd-user part > of qemu code here), not counting normal coding bugs: > - code is not thread safety but is used in threaded environment (rw > locks for example), > - emulate some sysctl's and resource limits / usage behavior is very > hard (mainly if we emulate 32-bits guest on 64-bits host) In many such cases, the proper behaviour can be found in the kernel code (when a 64-bit kernel needs to handle a system call from a 32-bit process). I expect problems with getdirentries() and struct dirent.d_off with filesystems that return hashed filenames as positions. > - if host syscall returns ERESTART, we should do full unroll and pass it > to guest. Yes (with the above mentioned caveats about how ERESTART is returned). > - the syscalls emulation should not use the libc functions, but syscall > instruction directly. Libc shims can have side effects so we should not > to execute it twice. Once in guest, second time in host. If you accept that your code is going to be more tightly coupled to libc and the kernel than most applications, calling system calls directly should be fine. This will also allow you to install your own handler for SIGTHR if you do not want to remap it. Do not expect pthread cancellation and suspension to work properly in such a configuration, though. > - and last major one. At this time, all guest structures are maintained > by hand. Due to huge amount of these structures, this is the extreme > error prone approach. We should convert this to script generated code, > including guest syscalls definition. Definitions of system calls are in syscalls.master and should be automatically processable; definitions of types are in header files and cannot really be processed other than by a C compiler. > Again, my apology for slightly (or much) chaotic report, but this is the > best what's I capable. It was clear enough to me. -- Jilles Tjoelker From owner-freebsd-arm@freebsd.org Sat Jan 5 23:40:00 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FE8C14275E1 for ; Sat, 5 Jan 2019 23:40:00 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 10941732D3 for ; Sat, 5 Jan 2019 23:39:58 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1546731553; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FRxtQDp7N97H1qhMRVvMPs8eN6wvab4Uoc1TBChnoQgzxJTV4oF4JKgLuVaNLMDMrek+RgYNnOF8R 1PG+U5P5jQt8V1kNmflPn7C8slWE9j1BvJOH1GsKalKQKFRwGaQdNtQJcwMG5OgK7aoIcTt8U9HTGy k8XWfvAX874Vo7Z2oQBrPFboqMfrouUmXIFYxmn14FTE7bMmnMboOcUXrwsBr/H3vTquvIBFozG5Nq +SR74wtGzUv4h/SCJJTOAsGDZKb3nwju3iT5qokN1ND3v5wCXuAbUWO6/YQEi2sX0ITgLtL0/rYBRx K+2YUWYU0N4ln4UyXPxwOn/gvCP3F0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=3ShzYAo0ZYzsU8dCrGObS9QrsFSfoXcKYF1JbI1Otz0=; b=spj3fHsZDHAkoBMflM5Zaee3UYkPCNIWXVPcipr+mN3ijN43/ol+NlcRVoMz7nPlh7X8O3w94dpa6 a4+ShKL5ND5MR7Ss6ECLZ5/cnWWrFpU78S7PmSAkjaaTd+VjQ7e52TJe1LhEwoBmhMcmTNELgLNs7U sUh+w0D+yq+o3yE6UZ84xN1vRlSBsgNPWU7jKFnI6+S4cUyPU99XFxJ2cMmZys3OeekSvg0BY/0x8y pi5TGqLXWKMM+Ag5kNqZ14yyh6e9NxG5OpdRZYvWMt8edcHevcZOR+5PQ8oUlNBT6URV37iJqx/w6H +CF5TeEpk8//aclLm4UV+FpVsXqcQGA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.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:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=3ShzYAo0ZYzsU8dCrGObS9QrsFSfoXcKYF1JbI1Otz0=; b=Ec2b98WexPAeKUWN3X9WItyPoq8MxyA8jdm7QC04JBmp1ebai1nf55FyYp5mw4QZL19YGaKK1578q t3QxD69GZ6wh83Zikm8hAeE3KSMNRhUFtfL2rfikbN13XEcX5+g37qzfEie4998g/vOvpHcaOwXS4O VLNBhMsKdAib2C7zpUYB3pH5VmCZH9o88Va6ha6BWdtGED0ME36gNHqBURl/dp0KfbH62Id2lXJOV5 RI2ydwg6wiIEqXr8kNBUA8f81jK/8Z4IYxxt/rMu9O9g442RuhtzPZMciVKJlaRfhnk2QF/iQ9UNeZ noHqfAX18gbrPLiuEakykSNu5LkoARQ== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 17483545-1143-11e9-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.152.101 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.152.101]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 17483545-1143-11e9-befd-af03bedce89f; Sat, 05 Jan 2019 23:39:11 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x05Ndmbm072661 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 6 Jan 2019 00:39:48 +0100 (CET) (envelope-from per@hedeland.org) Subject: Re: i2c on RPi Zero? To: Emmanuel Vadot Cc: Oleksandr Tymoshenko , freebsd-arm@freebsd.org References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> <20190105195808.GA53872@bluezbox.com> <20190105215608.GA55315@bluezbox.com> <20190105230306.2ad9d0ba2c2df0e8fac5f053@bidouilliste.com> From: Per Hedeland Message-ID: Date: Sun, 6 Jan 2019 00:39:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190105230306.2ad9d0ba2c2df0e8fac5f053@bidouilliste.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 10941732D3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=Ec2b98We X-Spamd-Result: default: False [-4.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; MX_GOOD(-0.01)[cached: hedeland.org]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-1.24)[ipnet: 54.148.0.0/15(-4.86), asn: 16509(-1.25), country: US(-0.08)]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[i=1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; RECEIVED_SPAMHAUS_PBL(0.00)[101.152.228.81.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[64.219.148.54.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.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: Sat, 05 Jan 2019 23:40:00 -0000 On 2019-01-05 23:03, Emmanuel Vadot wrote: > On Sat, 5 Jan 2019 13:56:08 -0800 > Oleksandr Tymoshenko wrote: > >> Per Hedeland (per@hedeland.org) wrote: >>> On 2019-01-05 20:58, Oleksandr Tymoshenko wrote: >>>> Per Hedeland (per@hedeland.org) wrote: >>>>> I did a bit more testing on the Zero to see if the FreeBSD version >>>>> mattered: >>>>> >>>>> FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no >>>>> luck. >>>>> >>>>> FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! >>>>> (I.e. dmesg reports as below and /dev/iic{0,1} get created - I haven't >>>>> tested actual usage beyond having 'i2c -s' report "no devices found".) >>>>> >>>>> I guess that the i2c support hasn't been removed intentionally, >>>>> i.e. this seems to be a regression - or is there some additional >>>>> config etc required to enable it with FreeBSD-12? The iic and iicbus >>>>> drivers appear to be built into the kernel in both 11 and 12. >>>>> >>>>> (I haven't tested FreeBSD-12 on the Pi B, but I would guess that the >>>>> result will be the same as on the Zero, since it seems the hardware is >>>>> the same.) >>>> >>>> There was a transition in device tree files between 11 and 12. >>>> bcm2708-rpi-0-w.dtb has i2c nodes but they're disabled by default. >>>> Try editing config.txt on FAT partition and adding following line: >>>> >>>> dtparam=i2c >>>> >>>> This should make boot firmware to enable device nodes in the device >>>> tree blob during the boot. >>> >>> Thanks a lot! I can confirm that this makes i2c "work" on Zero with >>> 12-RELEASE (almost) to the extent described above for 11.2-STABLE (it >>> detects/creates only iic0, not iic1, but as far as I understand from >>> other sources, iic0 is all that is needed for "plain B" and thus also >>> for Zero). >>> >>> Should I file a PR for this? I assume that the i2c nodes being >>> disabled is not intentional... >> >> Yes, please do. There are also other devices, that should be enabled by >> default, like SPI. > > Why should we enabled them by default ? > We have no correct way for switching a pin to gpio mode (you can do > that with gpioctl on some system but I consider it as a bug) so if I > want to use the i2c/spi/whatever pins as gpio and the default image set > it to another function I'm stuck. > Using the rpi fundation dtb means that every settings that they set > for Linux will also be set for us, so every tutorial on the web where > people saying that you should set something in config.txt will apply to > FreeBSD too. > The current settings aren't a bug, it's a feature (c). OK... - so your take seems to be that FreeBSD users should google for the "Linux way" to (e.g.) enable i2c on RPi. I googled "enable i2c on raspberry pi" now, and indeed it brought up lots of Linux stuff, but unfortunately it mostly says to run 'raspi-config', which I can't find on my FreeBSD installation (and didn't actually expect to, of course). If I explicitly add "config.txt" to the search string, I do indeed find some info about what to put in that file - but of course I wouldn't have done that if I didn't already know that this was the file that needed to be edited... I'm all for using "standard" components (even when "standard" means "Linux"), and reducing the amount of FreeBSD-specific work that you and others need to put in to support FreeBSD on these "odd" systems - and as a long time (Free)BSD user, I actually prefer to edit a file over running some GUI tool without knowing what it does. But I really think there needs to be a bit more help directed specifically at the FreeBSD user here (if there is and I just haven't found it, please enlighten me). A few words (besides "configuration for start.elf":-) about what config.txt is good for, and perhaps a pointer to e.g. https://www.raspberrypi.org/documentation/configuration/device-tree.md (found it from your hints, thanks!), on the https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi page may be enough. And despite the whining above, I really do appreciate all your efforts to make it possible to run FreeBSD on these systems - many thanks! --Per Hedeland From owner-freebsd-arm@freebsd.org Sat Jan 5 23:47:55 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B926B1427C13 for ; Sat, 5 Jan 2019 23:47:55 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 503B873A80 for ; Sat, 5 Jan 2019 23:47:54 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by mail-pg1-x542.google.com with SMTP id d72so19044383pga.9 for ; Sat, 05 Jan 2019 15:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lQrgUmR9cIdWJLO3y6w7qfXa0cZYaErYpeVLOuOly64=; b=ZzBLUd7EO3ekbEQEG6Hu4g/0WcNoE1uwtx699R8uL9MLh7IPpkAraShCpCsGO+unhZ mnsKlxueOzQLAt0sDge+iW+8/peEOFuwzzI9/rdC3XKwzhW4asVNIpmvN85xPfALa6W8 hGdIaEBkKfrNzrXx8Vu0FZpNzIK8drvpsEn7c9md+tldoq4ft2ab5zY2IAI/bJGO42bt GJeViPHyHl2O/8xAQZrF6Sj/0MT46u4CZ1Ad6mcZTzkkP79UPtJpWYET6Tgoq/SafeMP rq+BFgzTq57/DhhpKe0ZBut5qOdEqQZX7w3dIRH8YqyKNyJTxrmdb2UTGxNGlwLX02oj eqPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lQrgUmR9cIdWJLO3y6w7qfXa0cZYaErYpeVLOuOly64=; b=JZUbWji3qXP7EWm6Mw1nnQCkbcvg5PyKvAugJE2Jw0rfHIf9HKcIFoWy74ZSlKQs4y /s94HIBKLPIRnIzkFbi7fPycrtuJEbJmO4kogkVN6WTFDjlzXxxqCjD1yp9hbi99E7j9 QIv0EKTq/rZ0M7ch4eLLjXZKWFF0KD7FSJQAaV+8N+noAmz+0yg32jj+ghZ0orUb0rwg LhrUvfa5hYN+oElhGeZiAY49LWQYu805XhsyGG9ePy8NXOUdQnCsWyiAAKu0Rb8OX2XN iVTa737eplLd6IQXVUuOMocT38agJYyr6r/yN713OQ2n49fbQA2t09DNrGHwlKoNmeVh nl7g== X-Gm-Message-State: AJcUukeDOlBFbjWHWrg4AHJCUfszZewDfTn0NsOiofORYjjgvskz0D1H YLWFyIij0YSAJy7q+caSYGHdIZIxuXWo X-Google-Smtp-Source: ALg8bN7nGW3H8V1Ahe7tGdEqKUOf92HKKBpM5DeoIpLQQ9AhVrvEivcAEURQ0vVz6vZgYSQJ6NKqew== X-Received: by 2002:a63:a84a:: with SMTP id i10mr6320184pgp.263.1546732072717; Sat, 05 Jan 2019 15:47:52 -0800 (PST) Received: from ?IPv6:2600:8801:9900:167:692c:a35f:a173:be4f? ([2600:8801:9900:167:692c:a35f:a173:be4f]) by smtp.gmail.com with ESMTPSA id t87sm199383958pfk.122.2019.01.05.15.47.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Jan 2019 15:47:52 -0800 (PST) From: "Michael Mitchell (megabyte)" Message-Id: <4C1DFE20-8124-47EB-995C-F1029C1FA4DA@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: i2c on RPi Zero? Date: Sat, 5 Jan 2019 15:47:50 -0800 In-Reply-To: Cc: Emmanuel Vadot , freebsd-arm@freebsd.org To: Per Hedeland References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> <20190105195808.GA53872@bluezbox.com> <20190105215608.GA55315@bluezbox.com> <20190105230306.2ad9d0ba2c2df0e8fac5f053@bidouilliste.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 503B873A80 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ZzBLUd7E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mmitchel@gmail.com designates 2607:f8b0:4864:20::542 as permitted sender) smtp.mailfrom=mmitchel@gmail.com X-Spamd-Result: default: False [0.91 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; URI_COUNT_ODD(1.00)[7]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.35)[-0.346,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.55)[0.552,0]; NEURAL_HAM_LONG(-0.89)[-0.889,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.5.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]; SUBJECT_ENDS_QUESTION(1.00)[]; IP_SCORE(0.10)[ip: (4.44), ipnet: 2607:f8b0::/32(-2.20), asn: 15169(-1.67), country: US(-0.08)] Content-Type: text/plain; charset=us-ascii 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: Sat, 05 Jan 2019 23:47:56 -0000 simplified: why would freebsd demand a different device tree than what you get when you download it from raspberrypi.org = ? all the internet documentation describes how to manipulate the device tree. we are at their mercy for the boot up folder as it is... mdm > On Jan 5, 2019, at 3:39 PM, Per Hedeland wrote: >=20 > On 2019-01-05 23:03, Emmanuel Vadot wrote: >> On Sat, 5 Jan 2019 13:56:08 -0800 >> Oleksandr Tymoshenko wrote: >>> Per Hedeland (per@hedeland.org) wrote: >>>> On 2019-01-05 20:58, Oleksandr Tymoshenko wrote: >>>>> Per Hedeland (per@hedeland.org) wrote: >>>>>> I did a bit more testing on the Zero to see if the FreeBSD = version >>>>>> mattered: >>>>>>=20 >>>>>> FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still = no >>>>>> luck. >>>>>>=20 >>>>>> FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! >>>>>> (I.e. dmesg reports as below and /dev/iic{0,1} get created - I = haven't >>>>>> tested actual usage beyond having 'i2c -s' report "no devices = found".) >>>>>>=20 >>>>>> I guess that the i2c support hasn't been removed intentionally, >>>>>> i.e. this seems to be a regression - or is there some additional >>>>>> config etc required to enable it with FreeBSD-12? The iic and = iicbus >>>>>> drivers appear to be built into the kernel in both 11 and 12. >>>>>>=20 >>>>>> (I haven't tested FreeBSD-12 on the Pi B, but I would guess that = the >>>>>> result will be the same as on the Zero, since it seems the = hardware is >>>>>> the same.) >>>>>=20 >>>>> There was a transition in device tree files between 11 and 12. >>>>> bcm2708-rpi-0-w.dtb has i2c nodes but they're disabled by default. >>>>> Try editing config.txt on FAT partition and adding following line: >>>>>=20 >>>>> dtparam=3Di2c >>>>>=20 >>>>> This should make boot firmware to enable device nodes in the = device >>>>> tree blob during the boot. >>>>=20 >>>> Thanks a lot! I can confirm that this makes i2c "work" on Zero with >>>> 12-RELEASE (almost) to the extent described above for 11.2-STABLE = (it >>>> detects/creates only iic0, not iic1, but as far as I understand = from >>>> other sources, iic0 is all that is needed for "plain B" and thus = also >>>> for Zero). >>>>=20 >>>> Should I file a PR for this? I assume that the i2c nodes being >>>> disabled is not intentional... >>>=20 >>> Yes, please do. There are also other devices, that should be enabled = by >>> default, like SPI. >> Why should we enabled them by default ? >> We have no correct way for switching a pin to gpio mode (you can do >> that with gpioctl on some system but I consider it as a bug) so if I >> want to use the i2c/spi/whatever pins as gpio and the default image = set >> it to another function I'm stuck. >> Using the rpi fundation dtb means that every settings that they set >> for Linux will also be set for us, so every tutorial on the web where >> people saying that you should set something in config.txt will apply = to >> FreeBSD too. >> The current settings aren't a bug, it's a feature (c). >=20 > OK... - so your take seems to be that FreeBSD users should google for > the "Linux way" to (e.g.) enable i2c on RPi. I googled "enable i2c on > raspberry pi" now, and indeed it brought up lots of Linux stuff, but > unfortunately it mostly says to run 'raspi-config', which I can't find > on my FreeBSD installation (and didn't actually expect to, of course). >=20 > If I explicitly add "config.txt" to the search string, I do indeed > find some info about what to put in that file - but of course I > wouldn't have done that if I didn't already know that this was the > file that needed to be edited... >=20 > I'm all for using "standard" components (even when "standard" means > "Linux"), and reducing the amount of FreeBSD-specific work that you > and others need to put in to support FreeBSD on these "odd" systems - > and as a long time (Free)BSD user, I actually prefer to edit a file > over running some GUI tool without knowing what it does. >=20 > But I really think there needs to be a bit more help directed > specifically at the FreeBSD user here (if there is and I just haven't > found it, please enlighten me). A few words (besides "configuration > for start.elf":-) about what config.txt is good for, and perhaps a > pointer to e.g. > https://www.raspberrypi.org/documentation/configuration/device-tree.md > (found it from your hints, thanks!), on the > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi page may be > enough. >=20 > And despite the whining above, I really do appreciate all your efforts > to make it possible to run FreeBSD on these systems - many thanks! >=20 > --Per Hedeland > _______________________________________________ > 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 Sat Jan 5 23:48:55 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A1B01427CC2 for ; Sat, 5 Jan 2019 23:48:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 4104573B11 for ; Sat, 5 Jan 2019 23:48:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 440pLakVM1mwTNukkh8Z3zTk4n8ZbzYHbRWBi53CvaYoNBiPLvrdRyWxfygZvFW zDQ4CSAsjGdujTnrkS9QxF5qMDTXgc9sLWo_M6z4XwYBuVD3oiFTYfVaOSW0YLY3LaB27_jt2fGp qPDtJ9mE2KpSVXWSYg_seEq0j1snwTk5ddMYNvOn75DwFNT_f5d7zT_8NxA1ngYoNI3riwGQXDt4 WzhQ16SZGXHpsj.XlhGmJeH52j6bQr1SI8iiV357YzwFI7XQQwk_MFJ1EF0yHZAoRDwYbrQpt0Iu eZPAb.deK5cmJfAn2_gj74.ZOb1MAGlFdkSqH3LFjlyYTIoAjbokbJqqx_pPpUnxGG85.CLE_RGm VuuqaluYblFO.p80yiTWwfDT439V.t_e869IHoahlaVhqRmbm_8Nwh2ZWKLn3VonVWvHGfT3AZ6s KWodahIsu3h7WvRlydD1ANgrklJ3NPjV0bfLNCBLUcuyJvvVRtkNt5NIXj6FmBB2SqlxreEDmyRb lN6FSHF1l5GP889IDaImmtGqtCAlqI3N3_tX4RzVe.uRpWeHt0qIurJFJhGJ8cIGSJqQKGMoh8jO bp8zYQoHzey32.Dt69PK_.t8ER9Mf_UeDcQ95HimwkDDeVlNrydhVCWamhsEYxn5tCr.yK99Y8Ap zjjQg60Ywm0e0LwUTmbTCHc1s.c_DjhXyY8be4k5REFW3loowpY16fkUVbZ22PCeUuhikkp3N6sz R1Je6j2B1XAS46yFKgLR1AwhmX.HJvA3bIMbXaXpMRfu54LQcY7dsaQ8joazU1lxbyWfS1poPfwo yQNFoALydphA6k7Gf6pd1ChU9G3gnJotV7rcXVrukE_jNLmAgu.OKlvq.ulkJQnHiciAO9Lc3pZg S2T9Uq2WkWP7eFEhjCzefJxJxLpXnd_Uikyi63efnz7gFK3QNgWFfH3ZEd1fUwi1fA9FP0qS2FJc SN32RCqXekFitAdgeAmIa3rEO9hE_9viQUaCw8DbRT33.LEvYWyx9jNsg903k8XlyYHO6WGGMRtE RygYLm5tBMUptmVT0FQiPJRC0ITGIRKjRJjMnYmEjwC4G7sx_X2eny7d8e5qKIIpP2MFXVpUx7sv FBQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Jan 2019 23:48:47 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp402.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 00b4e2a428433f4617b80ddce139b2f3; Sat, 05 Jan 2019 23:48:47 +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 12.2 \(3445.102.3\)) Subject: qemu-arm-static has target_prpsinfo missing pr_pid field so target_prpsinfo is too small Message-Id: <5C2E8937-23A5-4899-B3CE-8468697D8923@yahoo.com> Date: Sat, 5 Jan 2019 15:48:46 -0800 Cc: Sean Bruno , freebsd-arm To: Kyle Evans , freebsd-emulation@freebsd.org, ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 4104573B11 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.42)[ip: (-8.10), ipnet: 98.137.64.0/21(0.60), asn: 36647(0.48), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.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, 05 Jan 2019 23:48:55 -0000 [The context here is FreeBSD head -r341836 based and ports head -r488859 = based.] Note: I assume that "struct target_prpsinfo" is meant to match the = memory layout of the target's native "struct prpsinfo". Otherwise the reported = differences below could be irrelevant. Note: struct target_prpsinfo is in (for my context): = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/elfload.c For armv7 (and likely armv6) the following code: printf("sizeof(struct prpsinfo) =3D %lu\n", (unsigned long) = sizeof(struct prpsinfo)); printf("pr_version %lu\n", (unsigned long) offsetof(struct = prpsinfo, pr_version)); printf("pr_psinfosz %lu\n", (unsigned long) offsetof(struct = prpsinfo, pr_psinfosz)); printf("pr_fname %lu\n", (unsigned long) offsetof(struct = prpsinfo, pr_fname)); printf("pr_psargs %lu\n", (unsigned long) offsetof(struct = prpsinfo, pr_psargs)); printf("pr_pid %lu\n", (unsigned long) offsetof(struct prpsinfo, = pr_pid)); produces: sizeof(struct prpsinfo) =3D 112 pr_version 0 pr_psinfosz 4 pr_fname 8 pr_psargs 25 pr_pid 108 However gdb reports for qemu-arm-static (on amd64): (gdb) p/d sizeof(struct target_prpsinfo) $7 =3D 108 (gdb) p/d &((struct target_prpsinfo *)0)->pr_version $8 =3D 0 (gdb) p/d &((struct target_prpsinfo *)0)->pr_psinfosz $9 =3D 4 (gdb) p/d &((struct target_prpsinfo *)0)->pr_fname =20 $10 =3D 8 (gdb) p/d &((struct target_prpsinfo *)0)->pr_psargs $11 =3D 25 (gdb) p/d &((struct target_prpsinfo *)0)->pr_pid =20 There is no member named pr_pid. So the fields prior to pr_pid have matching offsets and there is no extra padding added before pr_pid for native armv7. /usr/include/sys/procinfo.h has: typedef struct prpsinfo { int pr_version; /* Version number of struct (1) */ size_t pr_psinfosz; /* sizeof(prpsinfo_t) (1) */ char pr_fname[PRFNAMESZ+1]; /* Command name, null terminated = (1) */ char pr_psargs[PRARGSZ+1]; /* Arguments, null terminated = (1) */ pid_t pr_pid; /* Process ID (1a) */ } prpsinfo_t; pr_pid was added in -r308009 (2016-oct-28) and is in 11.2 . = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b= sd-user/elfload.c has: typedef struct target_prpsinfo { int32_t pr_version; /* Version number of struct (1) */ abi_ulong pr_psinfosz; /* sizeof(prpsinfo_t) (1) */ char pr_fname[TARGET_PRFNAMESZ+1]; /* Command name + NULL (1) = */ char pr_psargs[TARGET_PRARGSZ+1]; /* Arguments + NULL (1) */ } target_prpsinfo_t; =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 Jan 5 23:59:07 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6C5014297B0 for ; Sat, 5 Jan 2019 23:59:06 +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 B7C6C74906 for ; Sat, 5 Jan 2019 23:59:05 +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 e15a7f4c; Sun, 6 Jan 2019 00:59:03 +0100 (CET) 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=6qWxIj+07yR2NLIf7fqvowWiOQM=; b=PsD9pQh2DeZ4En8hajByubYF/7yU ZI04/I/u9wl23TiZaHUcSOG9gonFLMN1Wt5Ec6ilzglWFGs8/ZAiUIkgYLwPiphz 3p9ObeF1d16lJwbLPuxYd1OxzqxIvo+ykB8erHthoI08fUlChZLpoiYHK5brtWCN psNjjRIsxCJZa78= 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=ObPFKmbVIOAWKa0nQCJxUy7jyjR/VccBqhxz0K9tTNEqi9ZW3RP78IXQ In2tQQITolpMGyMfqrpupsRJFZxgErGjRJcNaHJNDRaeiZoqKeqHBQ/gRpbo+l9t NOLtU1GRt/abd1QwIkTt2MTJEaq38Ii0cbyzB9DweHW3BHBDnJc= Received: from knuckles.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 60863494 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 6 Jan 2019 00:59:03 +0100 (CET) Date: Sun, 6 Jan 2019 00:58:57 +0100 From: Emmanuel Vadot To: Per Hedeland Cc: Oleksandr Tymoshenko , freebsd-arm@freebsd.org Subject: Re: i2c on RPi Zero? Message-Id: <20190106005857.baa1313ba0f70de5a2913e6d@bidouilliste.com> In-Reply-To: References: <229e0d36-a07b-8551-9613-0bf5748352e7@hedeland.org> <20190105195808.GA53872@bluezbox.com> <20190105215608.GA55315@bluezbox.com> <20190105230306.2ad9d0ba2c2df0e8fac5f053@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: B7C6C74906 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mail header.b=PsD9pQh2; 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 [0.36 / 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.70)[-0.698,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.87)[-0.874,0]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.72)[0.716,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MX_GOOD(-0.01)[cached: mx-backup.blih.net]; IP_SCORE(0.13)[ipnet: 212.83.160.0/19(0.79), asn: 12876(-0.13), country: FR(-0.02)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.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: Sat, 05 Jan 2019 23:59:07 -0000 On Sun, 6 Jan 2019 00:39:48 +0100 Per Hedeland wrote: > On 2019-01-05 23:03, Emmanuel Vadot wrote: > > On Sat, 5 Jan 2019 13:56:08 -0800 > > Oleksandr Tymoshenko wrote: > > > >> Per Hedeland (per@hedeland.org) wrote: > >>> On 2019-01-05 20:58, Oleksandr Tymoshenko wrote: > >>>> Per Hedeland (per@hedeland.org) wrote: > >>>>> I did a bit more testing on the Zero to see if the FreeBSD version > >>>>> mattered: > >>>>> > >>>>> FreeBSD-12.0-STABLE-arm-armv6-RPI-B-20190103-r342709.img - still no > >>>>> luck. > >>>>> > >>>>> FreeBSD-11.2-STABLE-arm-armv6-RPI-B-20190103-r342709.img - works! > >>>>> (I.e. dmesg reports as below and /dev/iic{0,1} get created - I haven't > >>>>> tested actual usage beyond having 'i2c -s' report "no devices found".) > >>>>> > >>>>> I guess that the i2c support hasn't been removed intentionally, > >>>>> i.e. this seems to be a regression - or is there some additional > >>>>> config etc required to enable it with FreeBSD-12? The iic and iicbus > >>>>> drivers appear to be built into the kernel in both 11 and 12. > >>>>> > >>>>> (I haven't tested FreeBSD-12 on the Pi B, but I would guess that the > >>>>> result will be the same as on the Zero, since it seems the hardware is > >>>>> the same.) > >>>> > >>>> There was a transition in device tree files between 11 and 12. > >>>> bcm2708-rpi-0-w.dtb has i2c nodes but they're disabled by default. > >>>> Try editing config.txt on FAT partition and adding following line: > >>>> > >>>> dtparam=i2c > >>>> > >>>> This should make boot firmware to enable device nodes in the device > >>>> tree blob during the boot. > >>> > >>> Thanks a lot! I can confirm that this makes i2c "work" on Zero with > >>> 12-RELEASE (almost) to the extent described above for 11.2-STABLE (it > >>> detects/creates only iic0, not iic1, but as far as I understand from > >>> other sources, iic0 is all that is needed for "plain B" and thus also > >>> for Zero). > >>> > >>> Should I file a PR for this? I assume that the i2c nodes being > >>> disabled is not intentional... > >> > >> Yes, please do. There are also other devices, that should be enabled by > >> default, like SPI. > > > > Why should we enabled them by default ? > > We have no correct way for switching a pin to gpio mode (you can do > > that with gpioctl on some system but I consider it as a bug) so if I > > want to use the i2c/spi/whatever pins as gpio and the default image set > > it to another function I'm stuck. > > Using the rpi fundation dtb means that every settings that they set > > for Linux will also be set for us, so every tutorial on the web where > > people saying that you should set something in config.txt will apply to > > FreeBSD too. > > The current settings aren't a bug, it's a feature (c). > > OK... - so your take seems to be that FreeBSD users should google for > the "Linux way" to (e.g.) enable i2c on RPi. I googled "enable i2c on > raspberry pi" now, and indeed it brought up lots of Linux stuff, but > unfortunately it mostly says to run 'raspi-config', which I can't find > on my FreeBSD installation (and didn't actually expect to, of course). No, my take is that FreeBSD users should be able to tweak rpi the same way (more of less) than the Linux users. Unfortunatly, as you pointed out, sometimes it's hidden via a script/binary that do it for you. But more important is that I don't want to enable i2c (or any other function on pins) if the board doesn't requires it. DTS/DTB is supposed to represent the hardware and if the hardware doesn't have i2c (or, again, any other stuff on some pins) there is no reason for us to switch by default to those functions. > If I explicitly add "config.txt" to the search string, I do indeed > find some info about what to put in that file - but of course I > wouldn't have done that if I didn't already know that this was the > file that needed to be edited... > > I'm all for using "standard" components (even when "standard" means > "Linux"), and reducing the amount of FreeBSD-specific work that you > and others need to put in to support FreeBSD on these "odd" systems - > and as a long time (Free)BSD user, I actually prefer to edit a file > over running some GUI tool without knowing what it does. > > But I really think there needs to be a bit more help directed > specifically at the FreeBSD user here (if there is and I just haven't > found it, please enlighten me). A few words (besides "configuration > for start.elf":-) about what config.txt is good for, and perhaps a > pointer to e.g. > https://www.raspberrypi.org/documentation/configuration/device-tree.md > (found it from your hints, thanks!), on the > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi page may be > enough. The wiki probably need a lot of updates on how to use i2c/spi or whatever on rpi* (with dtb overlays examples etc ...). > And despite the whining above, I really do appreciate all your efforts > to make it possible to run FreeBSD on these systems - many thanks! > > --Per Hedeland Cheers, -- Emmanuel Vadot