From owner-freebsd-arm@freebsd.org Sun Feb 5 08:11:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 812C9CD160F; Sun, 5 Feb 2017 08:11:55 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF46DBF6; Sun, 5 Feb 2017 08:11:54 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v158BcOY056878 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 5 Feb 2017 19:11:44 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id v158BXRE011122 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Feb 2017 19:11:33 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v158BXdF011121; Sun, 5 Feb 2017 19:11:33 +1100 (AEDT) (envelope-from peter) Date: Sun, 5 Feb 2017 19:11:33 +1100 From: Peter Jeremy To: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: lang/go 1.7.5 fails to install on Arm Message-ID: <20170205081133.GA11031@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 08:11:55 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm trying to install lang/go on a RPi and it's failing because cgo.a is missing (see below). Looking through the sources it looks like it should exist but it's not built and there's no build error. Can anyone clarify whether the problem is the port or my build environment? (And, if the latter, does anyone have any suggestions what is wrong?) =3D=3D=3D> Installing for go-1.7.5,1 =3D=3D=3D> Checking if go already installed =3D=3D=3D> Registering installation for go-1.7.5,1 pkg-static: Unable to access file /usr/obj/usr/ports/lang/go/work/stage/usr= /local/go/pkg/freebsd_arm/runtime/cgo.a: No such file or directory *** Error code 74 Stop. make: stopped in /usr/ports/lang/go --=20 Peter Jeremy --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYlt41XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs07bEQAJMmXn+62LsxC0ybjaTDkouy oaOhc/hoymENcjUqYdIYqmrB4jzYfyZoq4bPc7GZFlKMzX5mfAceZYX7aNkugsZn UgzBtPZqMpqimXwuTlKwD2/ZQ+xHFZ/x7A8F3gzSGQkozA7zUT0gMZeghM/vn7e8 FcscNBeBhHr1DiBAjyZTNjPvHSSmsuwKDzdiU+9ZM6La+hKLWZOm0Y7T5RaHZoRL 8RegSehG6xVyzF5rWKvGsHfsYOKQ2xMr6Hge3CcR7E6f4m7c8VCtnaQSbi5qoUUz z05uGNE6haBP6Sscf2AE9JGfI13UAgMe7FyfIFx4nTyp7PSTqottaMDpJ0Di+VXi okxxso0gqzByeslWlIAjnLpGkbgG3nwzqeMJm/vQYue/BaK6enLr1EsKeoFeLLHg ieOQ14nVxa4KH/GTnRAeM6mw7WCzBT7e7UudwmFwGrb7FxyuUZhbT9IiZ15ilo+T RRDP2VtAbjOeUr6k3DgpBxe5fLMlw+Pxge7zn+MSmszfbOeq2++YTeAE8HbSIcyS NIL0DUMeKSorQdhrDS3IVaLbf3igql8MzKlLnU/j/TNtsYZ+Gtb5eW4cVp6te7Wp Y6KIsZdJkk8og7X5qjoFEzo85glzXRmdv9p5XYHhjBdno5DB+pHxqtQiLeRw6Yio SSsFaga5Bmbkt2TAaEBc =QflP -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-arm@freebsd.org Sun Feb 5 09:12:32 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E08FCCD1D36 for ; Sun, 5 Feb 2017 09:12:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-70.reflexion.net [208.70.210.70]) (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 9FBEFEBD for ; Sun, 5 Feb 2017 09:12:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10252 invoked from network); 5 Feb 2017 09:12:25 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Feb 2017 09:12:25 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Sun, 05 Feb 2017 04:12:25 -0500 (EST) Received: (qmail 18561 invoked from network); 5 Feb 2017 09:12:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Feb 2017 09:12:25 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 8FB40EC77A4; Sun, 5 Feb 2017 01:12:24 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Sun, 5 Feb 2017 01:12:23 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: Message-Id: <7B5DF446-6740-43DE-823D-B6ECBECF0C32@dsl-only.net> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 09:12:33 -0000 [Top post of a new result.] Using lldb to look at the memory for the stack around sh failure points has some apparently fixed structure. Example: . . . junk values . . . 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 0xffffffffe520: 0x0000000000000000 0x0000000000000000 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 0xffffffffe550: 0x0000000000434000 0x000000000000000f 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e 0xffffffffe580: 0x0000000000000001 0x0000000000000005 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 . . . junk values . . . where "register read" showed: sp =3D 0x0000ffffffffe600 (The distance and direction to the last non-junk line from the reported sp in each example is the same.) Looking around that 0x000000000040f490: 0x40f48c: 0x97fffc74 bl 0x40e65c ; freejob at = jobs.c:463 0x40f490: 0x9100c294 add x20, x20, #0x30 ; =3D0x30=20 It is the same address and code in each case. Sometimes the junk values are all zeros over sizable distances. Sometimes the sizable areas seem to have random data. /usr/src/bin/sh/jobs.c 's freejobs is: static void freejob(struct job *jp) { struct procstat *ps; int i; INTOFF; if (bgjob =3D=3D jp) bgjob =3D NULL; for (i =3D jp->nprocs, ps =3D jp->ps ; --i >=3D 0 ; ps++) { if (ps->cmd !=3D nullstr) ckfree(ps->cmd); } if (jp->ps !=3D &jp->ps0) ckfree(jp->ps); jp->used =3D 0; #if JOBS deljob(jp); #endif INTON; } /usr/src/bin/sh/error.h defines INTOFF and INTON: #define EXINT 0 /* SIGINT received */ #define EXERROR 1 /* a generic error */ #define EXEXEC 2 /* command execution failed */ #define EXEXIT 3 /* call exitshell(exitstatus) */ . . . extern struct jmploc *handler; extern volatile sig_atomic_t exception; . . . extern volatile sig_atomic_t suppressint; extern volatile sig_atomic_t intpending; #define INTOFF suppressint++ #define INTON { if (--suppressint =3D=3D 0 && intpending) onint(); } #define is_int_on() suppressint #define SETINTON(s) suppressint =3D (s) #define FORCEINTON {suppressint =3D 0; if (intpending) onint();} #define SET_PENDING_INT intpending =3D 1 #define CLEAR_PENDING_INT intpending =3D 0 #define int_pending() intpending void exraise(int) __dead2; void onint(void) __dead2; /usr/src/bin/sh/error.c hAS: void exraise(int e) { INTOFF; if (handler =3D=3D NULL) abort(); exception =3D e; longjmp(handler->loc, 1); } . . . void onint(void) { sigset_t sigs; intpending =3D 0; sigemptyset(&sigs); sigprocmask(SIG_SETMASK, &sigs, NULL); /* * This doesn't seem to be needed, since main() emits a newline. */ #if 0 if (tcgetpgrp(0) =3D=3D getpid()) write(STDERR_FILENO, "\n", 1); #endif if (rootshell && iflag) exraise(EXINT); else { signal(SIGINT, SIG_DFL); kill(getpid(), SIGINT); _exit(128 + SIGINT); } } # grep setjmp /usr/src/bin/sh/* /usr/src/bin/sh/TOUR:so I implement it using setjmp and longjmp. The = global variable /usr/src/bin/sh/error.h:#include /usr/src/bin/sh/error.h: * BSD setjmp saves the signal mask, which = violates ANSI C and takes time, /usr/src/bin/sh/error.h: * so we use _setjmp instead. /usr/src/bin/sh/error.h:#define setjmp(jmploc) _setjmp(jmploc) /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { /usr/src/bin/sh/histedit.c: if (setjmp(jmploc.loc)) { /usr/src/bin/sh/jobs.c: if (setjmp(jmploc.loc)) /usr/src/bin/sh/main.c: * commands. The setjmp call sets up the = location to jump to when an /usr/src/bin/sh/main.c: if (setjmp(main_handler.loc)) { /usr/src/bin/sh/parser.c: if (setjmp(jmploc.loc)) { /usr/src/bin/sh/parser.c: if (!setjmp(jmploc.loc)) { /usr/src/bin/sh/trap.c: if (!setjmp(loc1.loc)) { /usr/src/bin/sh/trap.c: if (!setjmp(loc2.loc)) { /usr/src/bin/sh/var.c: if (setjmp(jmploc.loc)) Other notes: As a personal investigation I've temporarily changed to using something not fully generic but based on gic-400 specifics: # svnlite diff /usr/src/sys/arm/arm/gic.c Index: /usr/src/sys/arm/arm/gic.c =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/src/sys/arm/arm/gic.c (revision 312982) +++ /usr/src/sys/arm/arm/gic.c (working copy) @@ -672,9 +672,13 @@ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS +#define EXPECTED_SPURIOUS_IRQ 1023 + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { device_printf(sc->gic_dev, - "Spurious interrupt detected: last irq: %d on = CPU%d\n", + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n", + irq, sc->nirqs, sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); + } #endif return (FILTER_HANDLED); } @@ -720,6 +724,16 @@ if (irq < sc->nirqs) goto dispatch_irq; =20 + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { +#undef EXPECTED_SPURIOUS_IRQ +#ifdef GIC_DEBUG_SPURIOUS + device_printf(sc->gic_dev, + "Spurious end interrupt %d detected of %d: last irq: = %d on CPU%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); +#endif + } + return (FILTER_HANDLED); } =20 The result was no notices of Spurious interrupts have been generated: All of the odd interrupts were the special 1023 value. [As far as I could tell from the code the configuration is such that 1022 should not be generated --and were not. 1020 and 1021 are reserved and should not be generated.] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Feb-2, at 12:37 AM, Mark Millard wrote: I'm out of my element here but I will note one difference between what I read in the likes of: = http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/DEN0024A_v8_arch= itecture_PG.pdf and what I see in /usr/src/sys/arm/arm/gic.c 's arm_gic_intr . The written description says (quoting 10.6 The Generic Interrupt Controller and 10.6.3 Interrupt Handling): > Interrupts can either be edge-triggered (considered to be asserted = when the GIC detects a rising edge on the relevant input, and to remain = asserted until cleared) or level-sensitive (considered to be asserted = only when the relevant input to the GIC is HIGH). >=20 > . . . >=20 > The priority and list of cores to which an interrupt can be delivered = to are all configured in the Distributor. An interrupt asserted to the = Distributor by a peripheral is in the Pending state (or Active and = Pending if it was already Active). The Distributor determines the = highest priority pending interrupt that can be delivered to a core and = forwards that to the CPU interface of the core. At the CPU interface, = the interrupt is in turn signaled to the core, at which point the core = takes the FIQ or IRQ exception. >=20 > The core executes the exception handler in response. The handler must = query the interrupt ID from a CPU interface register and begin servicing = the interrupt source. When finished, the handler must write to a CPU = interface register to report the end of processing. >=20 > =E2=80=A2 For a given interrupt the typical sequence is: >=20 > =E2=80=A2 Inactive -> Pending > When the interrupt is asserted by the peripheral. >=20 > =E2=80=A2 Pending -> Active > When the handler acknowledges the interrupt. >=20 > =E2=80=A2 Active -> Inactive > When the handle[r] has finished dealing with the interrupt. >=20 > . . . >=20 > The top-level interrupt handler reads the Interrupt Acknowledge = Register from the CPU Interface block to obtain the interrupt ID. >=20 > As well as returning the interrupt ID, the read causes the interrupt = to be marked as active in the Distributor. Once the interrupt ID is = known (identifying the interrupt source), the top-level handler can now = dispatch a device-specific handler to service the interrupt. >=20 > When the device-specific handler finishes execution, the top-level = handler writes the same interrupt ID to the End of Interrupt (EoI) = register in the CPU Interface block, indicating the end of interrupt = processing. So that wording indicates that the write to GICC_EOIR should be after the dispatched activity (after "servicing"), not before. I did not find anything indicating that edge-triggered vs. level triggered would be different for this, for example. (But being unfamiliar I could have missed something.) In two cases below the code has the write to the GICC_EOIR before the dispatch (so before the servicing activity), possibly allowing another interrupt during or even before the dispatched activity (say if the state for the irq is active-and-pending at the time of the GICC_EOIR write or if there is a lower priority interrupt pending at that time): > if (irq <=3D GIC_LAST_SGI) { > #ifdef SMP > /* Call EOI for all IPI before dispatch. */ > gic_c_write_4(sc, GICC_EOIR, irq_active_reg); > intr_ipi_dispatch(sgi_to_ipi[gi->gi_irq], tf); > goto next_irq; > #else > . . . > #endif > } >=20 > . . . > if ((gi->gi_flags & GI_FLAG_EARLY_EOI) =3D=3D = GI_FLAG_EARLY_EOI) > gic_c_write_4(sc, GICC_EOIR, irq_active_reg); >=20 > if (intr_isrc_dispatch(&gi->gi_isrc, tf) !=3D 0) { > gic_irq_mask(sc, irq); > if ((gi->gi_flags & GI_FLAG_EARLY_EOI) !=3D = GI_FLAG_EARLY_EOI) > gic_c_write_4(sc, GICC_EOIR, irq_active_reg); > device_printf(sc->gic_dev, "Stray irq %u disabled\n", = irq); > } >=20 > next_irq: . . . Note: GI_FLAG_EARLY_EOI was set for edge triggered: > /* For MSI/MSI-X we should have already configured these */ > if ((gi->gi_flags & GI_FLAG_MSI) =3D=3D 0) { > if (pol =3D=3D INTR_POLARITY_CONFORM) > pol =3D INTR_POLARITY_LOW; /* just pick = some */ > if (trig =3D=3D INTR_TRIGGER_CONFORM) > trig =3D INTR_TRIGGER_EDGE; /* just pick = some */ >=20 > gi->gi_pol =3D pol; > gi->gi_trig =3D trig; >=20 > /* Edge triggered interrupts need an early EOI sent */ > if (gi->gi_pol =3D=3D INTR_TRIGGER_EDGE) > gi->gi_flags |=3D GI_FLAG_EARLY_EOI; > } =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Feb-1, at 7:07 PM, Mark Millard wrote: > I temporarily modified the Spurious-interrupt-detected notice to also = report > irq and sc->nirqs : >=20 >=20 > . . . > #define gic_c_read_4(_sc, _reg) \ > bus_space_read_4((_sc)->gic_c_bst, (_sc)->gic_c_bsh, (_reg)) >=20 > . . . > int > arm_gic_intr(void *arg) > { > struct arm_gic_softc *sc =3D arg; > struct gic_irqsrc *gi; > uint32_t irq_active_reg, irq; > struct trapframe *tf; >=20 > irq_active_reg =3D gic_c_read_4(sc, GICC_IAR); > irq =3D irq_active_reg & 0x3FF; >=20 > /* > . . . > */ >=20 > if (irq >=3D sc->nirqs) { > #ifdef GIC_DEBUG_SPURIOUS > device_printf(sc->gic_dev, > "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n", > irq, sc->nirqs, > sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); > #endif > return (FILTER_HANDLED); > } > . . . >=20 >=20 > The result was irq=3D=3D1023 and sc->nirqs=3D=3D224 in every message > that I've seen so far. 1023=3D=3D0x3FF . >=20 > Looking around I found in: >=20 > = http://www.cl.cam.ac.uk/research/srg/han/ACS-P35/zynq/arm_gic_architecture= _specification.pdf >=20 > the following on various reasons why 1023 would show up (quoting): >=20 >=20 >=20 > =E2=80=A2 A processor reads the GICC_IAR and obtains the = interrupt ID 1023, indicating a spurious interrupt. The processor can = return from its interrupt service routine without writing to its = GICC_EOIR. >=20 > The spurious interrupt ID indicates that the original interrupt is no = longer pending, typically because another target processor is handling = it. >=20 > . . . >=20 > The GIC architecture reserves interrupt ID numbers 1020-1023 for = special purposes. In a GICv1 implementation that does not implement the = GIC Security Extensions, the only one of these used is ID 1023. This = value is returned to a processor, in response to an interrupt = acknowledge, if there is no pending interrupt with sufficient priority = for it to be signaled to the processor. It is described as a response to = a spurious interrupt. >=20 > Note >=20 > A race condition can cause a spurious interrupt. For example, a = spurious interrupt can occur if a processor writes a 1 to a field in an = GICD_ICENABLERn that corresponds to a pending interrupt after the CPU = interface has signaled the interrupt to the processor and the processor = has recognized the interrupt, but before the processor has read from the = GICC_IAR. >=20 > . . . >=20 > =E2=80=A2 If a read of the GICC_IAR does not match the security = of the interrupt, the GICC_IAR read does not acknowledge any interrupt = and returns the value: >=20 > =E2=80=A2 1022 for a Secure read when the highest = priority interrupt is Non-secure >=20 > =E2=80=A2 1023 for a Non-secure read when the highest = priority interrupt is Secure. > . . . >=20 > A read of the GICC_IAR returns the interrupt ID of the highest = priority pending interrupt for the CPU interface. The read returns a = spurious interrupt ID of 1023 if any of the following apply: >=20 > =E2=80=A2 forwarding of interrupts by the Distributor to the CPU = interface is disabled >=20 > =E2=80=A2 signaling of interrupts by the CPU interface to the = connected processor is disabled >=20 > =E2=80=A2 no pending interrupt on the CPU interface has = sufficient priority for the interface to signal it to the processor. >=20 >=20 > =E2=80=A2 The following sequence of events is an example of when = the GIC returns an interrupt ID of 1023, and shows how reads of the = GICC_IAR can be timing critical: >=20 > 1. A peripheral asserts a level-sensitive interrupt. >=20 > 2. The interrupt has sufficient priority and therefore the GIC signals = it to a targeted processor. >=20 > 3. The peripheral deasserts the interrupt. Because there is no other = pending interrupt of sufficient priority, the GIC deasserts the = interrupt request to the processor. >=20 > 4. Before it has recognized the deassertion of the interrupt request = from stage 3, the targeted processor reads the GICC_IAR. Because there = is no interrupt with sufficient priority to signal to the processor, the = GIC returns the spurious ID value of 1023. >=20 >=20 > The determination of the returned interrupt ID is more complex if the = GIC supports interrupt grouping >=20 > . . . >=20 >=20 > Interrupt signaling of the required interrupt group by CPU interface = disabled >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ 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" _______________________________________________ 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 Sun Feb 5 16:53:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E0B6CD2366 for ; Sun, 5 Feb 2017 16:53:59 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1C538150E for ; Sun, 5 Feb 2017 16:53:58 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id D6DC46257B for ; Sun, 5 Feb 2017 10:53:57 -0600 (CST) Subject: Re: NanoBSD config script for RPI2 References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> Date: Sun, 5 Feb 2017 10:53:35 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090805080505080701050708" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 16:53:59 -0000 This is a cryptographically signed message in MIME format. --------------ms090805080505080701050708 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/4/2017 15:02, Mark Millard wrote: > On 2017-Feb-4, at 10:56 AM, Karl Denninger > wrote: > >> On 2/4/2017 10:38, Warner Losh wrote: >>> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger >> denninger.net > wrote: >>>> It fails here during image create.... >>>> >>>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>>> + [ -n s1 ] >>>> + eval 's1=3Dfat16b' >>>> + s1=3Dfat16b >>>> + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>> + mkimg -a 3 -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.s= 1' -p >>>> 'freebsd >>>> :=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p >>>> 'freebsd:=3D/pics/CrossBuild/embedded/rp >>>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>> mkimg: invalid option -- a >>>> mkimg: error: unknown option >>>> >>>> usage: mkimg >>>> options: >>>> --formats - list image formats >>>> --schemes - list partition schemes >>>> --version - show version information >>>> >>>> -b - file containing boot code >>>> -c - capacity (in bytes) of the disk >>>> -f >>>> -o - file to write image into >>>> -p >>>> -s >>>> -v - increase verbosity >>>> -y - [developers] enable unit test >>>> -H - number of heads to simulate >>>> -P - physical sector size >>>> -S - logical sector size >>>> -T - number of tracks to simulate >>>> >>>> formats: >>>> qcow - QEMU Copy-On-Write, version 1 >>>> qcow2 - QEMU Copy-On-Write, version 2 >>>> raw - Raw Disk >>>> vhd - Virtual Hard Disk >>>> vhdf - Fixed Virtual Hard Disk >>>> vmdk - Virtual Machine Disk >>>> >>>> schemes: >>>> apm - Apple Partition Map >>>> bsd - BSD disk label >>>> ebr - Extended Boot Record >>>> gpt - GUID Partition Table >>>> mbr - Master Boot Record >>>> pc98 - PC-9800 disk partitions >>>> vtoc8 - SMI VTOC8 disk labels >>>> >>>> Is the "-a" flag attempting to set the active partition? It appears= >>>> there's no option to do that in mkimg... >>> Install a newer mkimg: >>> >>> Revision 307550 - (view) (download) (annotate) - [select for diffs] > > https://svnweb.freebsd.org/base/?pathrev=3D312669 shows that > -r3125699 is from head. > > Looking around: stable/11 has not been updated for its mkimg. only > head has -a added at this point. > >>> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp >>> File length: 3730 byte(s) >>> Diff to previous 307544 >>> >>> Add a new flag to mkimg (-a num) to specify the active partition for >>> those partitioning schemes that have this concept. Implement it as an= >>> override for mbr's setting 0x80 in the flags for the first partition >>> when we have boot code. >>> >>> Differential Revision: https://reviews.freebsd.org/D4403 >>> >>> Though maybe I should try to add it to the bootstrap tools so I can >>> use a new one after the build. >>> >>> Warner >>> >> root@NewFS:/disk/karl # uname -v >> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 > > https://svnweb.freebsd.org/base/?pathrev=3D312669 shows that > -r3125699 is from head, not from stable/11 . > > If you have a mix of head and stable/11 materials with mkimg from > stable/11 then -a will not be present for mkimg. > >> karl@NewFS.denninger.net >> :/usr/obj/usr/src/sys/KSD-SMP >> root@NewFS:/disk/karl # which mkimg >> /usr/bin/mkimg >> root@NewFS:/disk/karl # pkg install mkimg >> Updating FreeBSD repository catalogue... >> FreeBSD repository is up-to-date. >> All repositories are up-to-date. >> pkg: No packages available to install matching 'mkimg' have been found= >> in the repositories >> root@NewFS:/disk/karl # >> >> So.... it's part of base and there is no obvious package (a check for >> ports in */*mkimg* fails too); my system is current as of Jan 23.... >> >> (As an aside I think if I remove the -a it may work on the Pi, since t= he >> Pi will try to boot the first partition which happens to be DOS -- I >> think. I'll try it.) >> >> --=20 >> Karl Denninger >> karl@denninger.net > denninger.net > >> /The Market Ticker/ >> /[S/MIME encrypted email preferred]/ > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > Manually setting the third partition to active does work to boot, but the default partition settings for root and cfg are also wrong; you need these overrides or the mount of root fails on startup: # # Partition layout for the Pi2 is: # 1 =3D FAT16 boot (MSDOS) containing bootcode, ubldr, etc. # 2 =3D CFG # 3 =3D Root (must be separately marked active so ubldr can find it) # 4 =3D Altroot # NANO_SLICE_CFG=3Ds2 NANO_SLICE_ROOT=3Ds3 NANO_SLICE_ALTROOT=3Ds4 NANO_ROOT=3Ds3a NANO_ALTROOT=3Ds4a I'm working on some other issues but this allows the unit to boot up and start. You do need to mark the partition active manually but there's a workaround for the need to do that manually -- mount the image after it's built in "common" and set the active flag using gpart: mdi=3D`mdconfig -f _.disk.image......` gpart set -a active -i 3 $mdi mdconfig -d -u $mdi Which works if used in place of the "-a...." argument to the mkimg command. Perhaps this should be changed in the "common" script and made the general case, at least for 11-STABLE and before, since it should work with pretty-much any version of FreeBSD and obviates the need for the updated mkimg. As things stand right now a checkout of 11-STABLE has a common script that relies on an updated mkimg that isn't present in the system and thus will//not work. This is what I changed in common: case ${NANO_LAYOUT} in std-embedded) # mkimg -a 3 ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p ${s1}:=3D${NANO_LOG}/_.s1 \ mkimg ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p ${s1}:=3D${NANO_LOG}/_.s1 \ -p ${s2}:=3D${NANO_LOG}/_.s2 \ -p ${s3}:=3D${NANO_LOG}/_.s3 \ -o ${out} mdi=3D`mdconfig -f ${out}` gpart show $mdi gpart set -a active -i 3 $mdi gpart show $mdi mdconfig -d -u $mdi ;; The two "shows" are (obviously) not necessary but result in log output that shows the active flag successfully set. Partial output from _.di incorporating this change: Populating `/pics/CrossBuild/embedded/rpi2/_.s2' Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete + [ -n s1 ] + eval 's1=3Dfat16b' + s1=3Dfat16b + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP + mkimg -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.s1' -p 'freebsd:=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p 'freebsd:=3D/pics/CrossBuild/embedded/rpi2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP + mdconfig -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP + mdi=3Dmd0 + gpart show md0 =3D> 1 429840 md0 MBR (210M) 1 65536 1 fat16 (32M) 65537 65536 2 freebsd (32M) 131073 298768 3 freebsd (146M) + gpart set -a active -i 3 md0 active set on md0s3 + gpart show md0 =3D> 1 429840 md0 MBR (210M) 1 65536 1 fat16 (32M) 65537 65536 2 freebsd (32M) 131073 298768 3 freebsd [active] (146M) + mdconfig -d -u md0 + rm -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz + echo 'NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.x= z' NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz + uname -r + command rm -x -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.x= z + xz -9 --keep /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP Onward I go... now I need to figure out how to get packages to work in a cross-compiled world, which might be a bit of a bigger problem since the existing way it's done chroot's into the installed world, which of course means that the "pkg" command is for the wrong architecture..... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090805080505080701050708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDUxNjUzMzVaME8GCSqGSIb3DQEJBDFCBEC4f5Qr T395Ny9281BRQgybxdDJEaqnSjQaJXGa6aOHVzgFYZcZl3J1iSCXpZYO8JvF3Qb0eJLA8Scz /OAtmel9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAgmLKZUnDazxO yjUawQ5yuXSnt0U+OmeGqLjHsBSQkSm9O4cHxWSRx60mwWEikNx1DOIdRX1MAyMnLk2b/leh sxh6oHlafYToqB7QPmuEDaUPO4APEhEZKc9MPLJd5u1rTqhEFXrITGenZ/HydvQBWKma2BkK zYhbvo0gXErcIavnaxV58QK+5ArOg0nz3Y+wIc1fgSnPWdmN6h0DKcitgZ4G9XDCNkQ+/93Z IC3ht2VR0jLLiNZcCwdvtQyqbRxC4frdwvFyKC1VjFFHIcY/yNyzjAGeAb1eLSqjbbvzVowO mNFV80w7esyNbqr3w0VLvqTYiP8DYFqeYXoPYi9YwEnVvx+07P5Qkotsyjr+UdFAptk1v1YA PBsQuO4C96CG7tT4Yrs9Qhve7PTUKW64nO+u/1HPUwfuLvFc7G2eLZF+XwOYCOkiwvXu2b2m BLUjgFhGEJmfYShQIojy9gAp7i+AzgcgLp9uuLU/9/DwAuie+Yx1t3z36+z3X85XcUn48DBT 5W+A5Psd6rZM2dkZKMFXPSw+DR0hvd/V75tFRej6KThpDpP0zjkqg+XYUPs+8d9Z8AMamFvm SzIySulNvBElbXLb+7htjsh3l1x+2YFb/+Xoz3VD+5gH/W1ZmICV6ykSx5eiGN+gZ2f/L7Wz 3gjQMaqtGC1jdKn+zIwWgdkAAAAAAAA= --------------ms090805080505080701050708-- From owner-freebsd-arm@freebsd.org Sun Feb 5 19:43:14 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12261CD26FC; Sun, 5 Feb 2017 19:43:14 +0000 (UTC) (envelope-from jlaffaye.freebsd@gmail.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFEE7A3E; Sun, 5 Feb 2017 19:43:13 +0000 (UTC) (envelope-from jlaffaye.freebsd@gmail.com) Received: by mail-io0-x243.google.com with SMTP id m98so7298873iod.2; Sun, 05 Feb 2017 11:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aN2l1LVpP/AIyHZB8iyKDQ8eyvAH5PFVWuH22mvzBh8=; b=AiJtuzhdmg0WzxAVsHBO2eBxnmeUvstcBZzjw5xRSTZDWroE7dUyZ8SCXSmtYWRtIN yR4P8YXSlp6+ICuzOHuUWDxhHpzcxunGQVIMEpGkSxqDav74mLpAJfbIIMbNHE1riJO4 uLoSL/+iay2Up4X41sr1nYd1qQg0cZXaG0VAhTf/XJlVmMCx1+B/qKhZ4T1eh6pZhu7F dWPHXXrzgi66LYe/TcnhlUIdAHx6S8FQy38odl/UEdAh5nirykdeZFhogJn9IR3MjjhN LXcIfP8R+qcEqvF2FiXQSLA9V3Nw09RJB74sAUyHVK0nbfD7kU8DxV5pPXcBEngCkRKK vnzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aN2l1LVpP/AIyHZB8iyKDQ8eyvAH5PFVWuH22mvzBh8=; b=XqqAf2Wyb+FlJDmUElw91W9Qaz/jmwt2uFw/yhXV1btuwYrlVi/XfYrRE5hO4CMDSa st8lmrTiH4dawizmvQed75z/uGyg2WzZwtzrco3PiNtAkOLwOy/C9WpMcqzZ1jO4fohi +APFGIR9HvwJnH3kJJ2e7PJSO9dt1vRVNeNHZ2170C0KJuXwu7IATiesNOjazv1XhHnu jMipHN83S1YoPUjtc3K/9aodNktGpI8amS7TdHwcHH0y/r0h+KAWeh4iXLMXbHYf2i9v 0qb37ImqeGtYfb/dSZ+72LvMyAXbwelzciGAkAbQVpOm2/uECDYYXLkomgFZTAe2SjYl 9CwA== X-Gm-Message-State: AMke39mJGRug0Qnc3OeyDIAoTMCnHXcpx3y1mzpf6MfwZCKZDi+FqO7jvo9G2Bm8DBuiPjSGvuah+JNwS2KyLg== X-Received: by 10.107.9.149 with SMTP id 21mr4314784ioj.106.1486323793307; Sun, 05 Feb 2017 11:43:13 -0800 (PST) MIME-Version: 1.0 Sender: jlaffaye.freebsd@gmail.com Received: by 10.79.85.212 with HTTP; Sun, 5 Feb 2017 11:43:12 -0800 (PST) In-Reply-To: <20170205081133.GA11031@server.rulingia.com> References: <20170205081133.GA11031@server.rulingia.com> From: Julien Laffaye Date: Sun, 5 Feb 2017 20:43:12 +0100 X-Google-Sender-Auth: 0ay-Aculz7Npfps_MWPyf5G-bRA Message-ID: Subject: Re: lang/go 1.7.5 fails to install on Arm To: Peter Jeremy Cc: freebsd-arm@freebsd.org, FreeBSD Ports ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 19:43:14 -0000 go/pkg/%%opsys_ARCH%%/runtime/cgo.a is in the plist, but for some reason it is not compiled on arm. is it the only error ? On Sun, Feb 5, 2017 at 9:11 AM, Peter Jeremy wrote: > I'm trying to install lang/go on a RPi and it's failing because cgo.a is > missing (see below). Looking through the sources it looks like it should > exist but it's not built and there's no build error. Can anyone clarify > whether the problem is the port or my build environment? (And, if the > latter, does anyone have any suggestions what is wrong?) > > ===> Installing for go-1.7.5,1 > ===> Checking if go already installed > ===> Registering installation for go-1.7.5,1 > pkg-static: Unable to access file /usr/obj/usr/ports/lang/go/ > work/stage/usr/local/go/pkg/freebsd_arm/runtime/cgo.a: No such file or > directory > *** Error code 74 > > Stop. > make: stopped in /usr/ports/lang/go > > -- > Peter Jeremy > From owner-freebsd-arm@freebsd.org Sun Feb 5 20:16:48 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85CA0CD2E49 for ; Sun, 5 Feb 2017 20:16:48 +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 661791ACD for ; Sun, 5 Feb 2017 20:16:47 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1caTEs-000PX2-Pq; Sun, 05 Feb 2017 12:16:47 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v15KGjnf098147; Sun, 5 Feb 2017 12:16:45 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 5 Feb 2017 12:16:45 -0800 From: Oleksandr Tymoshenko To: =?iso-8859-1?Q?Otac=EDlio?= Cc: "freebsd-arm@freebsd.org" Subject: Re: SMP support on Raspberry PI 3 Message-ID: <20170205201645.GA98103@bluezbox.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) 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: Otacílio (otacilio.neto@bsd.com.br) wrote: > Dears > > > I did a build of 12 r312852 to my Raspberry PI 3 with SMP enabled. But, > when the board is booting I get this message intermittent > > cpufreq0: rejecting change, SMP not started yet > > SMP is supposed to work? [...] 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] 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bsd.com.br] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 20:16:48 -0000 Otacílio (otacilio.neto@bsd.com.br) wrote: > Dears > > > I did a build of 12 r312852 to my Raspberry PI 3 with SMP enabled. But, > when the board is booting I get this message intermittent > > cpufreq0: rejecting change, SMP not started yet > > SMP is supposed to work? It's supposed to work to some extent but reported to be unstable under real life load. You need PSCI monitor on FAT partition to make it work. I beleive latest sysutils/u-boot-rpi3 combined with latest crochet should produce SMP-enabled image. -- gonzo From owner-freebsd-arm@freebsd.org Sun Feb 5 20:21:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12CD0CD2F5F for ; Sun, 5 Feb 2017 20:21:56 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB5B21D48 for ; Sun, 5 Feb 2017 20:21:55 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x230.google.com with SMTP id x49so89388309qtc.2 for ; Sun, 05 Feb 2017 12:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=C3/J79ueMPPchZblojrMIkLUkPzvO4b+wDWHIK4r7rc=; b=HA5gWt/iARYS4EJXIOphzzftCT8G8pMmetzOO5cjKnkZa5Fr3VycrSdkAuC7jFiM3k 46Z6NGPRBlum1t4JrkgJg4utLRp8FdnyzxzKa2EX+u1WmyWrbwuPbR2hUD+VdcPNDLlw 5DrzWxr+Ijg3edWdF7PMofoh83Jm15hnZ17X0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=C3/J79ueMPPchZblojrMIkLUkPzvO4b+wDWHIK4r7rc=; b=gqlKTtI/GbWLl4KVW2fi9c2AeO8r7TA3vnnc32+Vz9qzjqXXO4U8mfIXVrlUwEdrto 9qdszUM7/Pu+Qg4X84k3OKYl2u893KAH0yGyGKxyzCC8pD7iIF1Y+7cVLAj+OnT0au1a 8lgxX+KeysIrc9hvtCDhb8DfYiMSLV2jOR63POFvy64vmzn0z2ADJKXwfgVKFJNUb+2F 1Pt929ETYFXsGSTeD+NKETn1V5yvQxlMAQs/3JMk4+8R2ZKTX3MZANPtmyKc/G+jVZel tl/LQuYIi1XIzMDwIP1qYmhKo57Ciybt/FckI+wC+U+tYmkjarIrUV/yFdx6wO3mi5me 53kQ== X-Gm-Message-State: AMke39mh4nAhxYnixnTXyZlbNa1LAcdmj025nC10y/gxWacrMJQIEC2m22PFQ2yv4RL8oA== X-Received: by 10.200.42.227 with SMTP id c32mr6390931qta.70.1486326114538; Sun, 05 Feb 2017 12:21:54 -0800 (PST) Received: from [192.168.0.11] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id a54sm31066332qta.48.2017.02.05.12.21.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Feb 2017 12:21:54 -0800 (PST) Subject: Re: SMP support on Raspberry PI 3 To: Oleksandr Tymoshenko References: <20170205201645.GA98103@bluezbox.com> Cc: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <276e65b8-4f90-5820-efdd-0114fefc8dfe@bsd.com.br> Date: Sun, 5 Feb 2017 17:21:48 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170205201645.GA98103@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 20:21:56 -0000 Em 05/02/2017 17:16, Oleksandr Tymoshenko escreveu: > Otacílio (otacilio.neto@bsd.com.br) wrote: >> Dears >> >> >> I did a build of 12 r312852 to my Raspberry PI 3 with SMP enabled. But, >> when the board is booting I get this message intermittent >> >> cpufreq0: rejecting change, SMP not started yet >> >> SMP is supposed to work? > It's supposed to work to some extent but reported to be unstable > under real life load. You need PSCI monitor on FAT partition to > make it work. I beleive latest sysutils/u-boot-rpi3 combined with > latest crochet should produce SMP-enabled image. > I did a update of u-boot-rpi3, crouchet and rebuild a image. It's working but I do not have tested under heavy load. []'s -Otacilio From owner-freebsd-arm@freebsd.org Sun Feb 5 21:22:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43111CD2B4E for ; Sun, 5 Feb 2017 21:22:58 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id DC703D97 for ; Sun, 5 Feb 2017 21:22:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 143B0627B6 for ; Sun, 5 Feb 2017 15:22:50 -0600 (CST) Subject: Re: NanoBSD config script for RPI2 To: "freebsd-arm@freebsd.org" References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> From: Karl Denninger Message-ID: Date: Sun, 5 Feb 2017 15:22:28 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080504040601000007000701" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 21:22:58 -0000 This is a cryptographically signed message in MIME format. --------------ms080504040601000007000701 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/5/2017 10:53, Karl Denninger wrote: > On 2/4/2017 15:02, Mark Millard wrote: >> On 2017-Feb-4, at 10:56 AM, Karl Denninger > > wrote: >> >>> On 2/4/2017 10:38, Warner Losh wrote: >>>> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger >>> denninger.net > wrote: >>>>> It fails here during image create.... >>>>> >>>>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>>>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>>>> + [ -n s1 ] >>>>> + eval 's1=3Dfat16b' >>>>> + s1=3Dfat16b >>>>> + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>> + mkimg -a 3 -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.= s1' -p >>>>> 'freebsd >>>>> :=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p >>>>> 'freebsd:=3D/pics/CrossBuild/embedded/rp >>>>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>> mkimg: invalid option -- a >>>>> mkimg: error: unknown option >>>>> >>>>> usage: mkimg >>>>> options: >>>>> --formats - list image formats >>>>> --schemes - list partition schemes >>>>> --version - show version information >>>>> >>>>> -b - file containing boot code >>>>> -c - capacity (in bytes) of the disk >>>>> -f >>>>> -o - file to write image into >>>>> -p >>>>> -s >>>>> -v - increase verbosity >>>>> -y - [developers] enable unit test >>>>> -H - number of heads to simulate >>>>> -P - physical sector size >>>>> -S - logical sector size >>>>> -T - number of tracks to simulate >>>>> >>>>> formats: >>>>> qcow - QEMU Copy-On-Write, version 1 >>>>> qcow2 - QEMU Copy-On-Write, version 2 >>>>> raw - Raw Disk >>>>> vhd - Virtual Hard Disk >>>>> vhdf - Fixed Virtual Hard Disk >>>>> vmdk - Virtual Machine Disk >>>>> >>>>> schemes: >>>>> apm - Apple Partition Map >>>>> bsd - BSD disk label >>>>> ebr - Extended Boot Record >>>>> gpt - GUID Partition Table >>>>> mbr - Master Boot Record >>>>> pc98 - PC-9800 disk partitions >>>>> vtoc8 - SMI VTOC8 disk labels >>>>> >>>>> Is the "-a" flag attempting to set the active partition? It appear= s >>>>> there's no option to do that in mkimg... >>>> Install a newer mkimg: >>>> >>>> Revision 307550 - (view) (download) (annotate) - [select for diffs] >> https://svnweb.freebsd.org/base/?pathrev=3D312669 shows that >> -r3125699 is from head. >> >> Looking around: stable/11 has not been updated for its mkimg. only >> head has -a added at this point. >> >>>> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp= >>>> File length: 3730 byte(s) >>>> Diff to previous 307544 >>>> >>>> Add a new flag to mkimg (-a num) to specify the active partition for= >>>> those partitioning schemes that have this concept. Implement it as a= n >>>> override for mbr's setting 0x80 in the flags for the first partition= >>>> when we have boot code. >>>> >>>> Differential Revision: https://reviews.freebsd.org/D4403 >>>> >>>> Though maybe I should try to add it to the bootstrap tools so I can >>>> use a new one after the build. >>>> >>>> Warner >>>> >>> root@NewFS:/disk/karl # uname -v >>> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 >> https://svnweb.freebsd.org/base/?pathrev=3D312669 shows that >> -r3125699 is from head, not from stable/11 . >> >> If you have a mix of head and stable/11 materials with mkimg from >> stable/11 then -a will not be present for mkimg. >> >>> karl@NewFS.denninger.net >>> :/usr/obj/usr/src/sys/KSD-SMP >>> root@NewFS:/disk/karl # which mkimg >>> /usr/bin/mkimg >>> root@NewFS:/disk/karl # pkg install mkimg >>> Updating FreeBSD repository catalogue... >>> FreeBSD repository is up-to-date. >>> All repositories are up-to-date. >>> pkg: No packages available to install matching 'mkimg' have been foun= d >>> in the repositories >>> root@NewFS:/disk/karl # >>> >>> So.... it's part of base and there is no obvious package (a check for= >>> ports in */*mkimg* fails too); my system is current as of Jan 23.... >>> >>> (As an aside I think if I remove the -a it may work on the Pi, since = the >>> Pi will try to boot the first partition which happens to be DOS -- I >>> think. I'll try it.) >>> >>> --=20 >>> Karl Denninger >>> karl@denninger.net >> denninger.net > >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ >> >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >> > Manually setting the third partition to active does work to boot, but > the default partition settings for root and cfg are also wrong; you nee= d > these overrides or the mount of root fails on startup: > > # > # Partition layout for the Pi2 is: > # 1 =3D FAT16 boot (MSDOS) containing bootcode, ubldr, etc. > # 2 =3D CFG > # 3 =3D Root (must be separately marked active so ubldr can find it) > # 4 =3D Altroot > # > NANO_SLICE_CFG=3Ds2 > NANO_SLICE_ROOT=3Ds3 > NANO_SLICE_ALTROOT=3Ds4 > NANO_ROOT=3Ds3a > NANO_ALTROOT=3Ds4a > > I'm working on some other issues but this allows the unit to boot up an= d > start. You do need to mark the partition active manually but there's a= > workaround for the need to do that manually -- mount the image after > it's built in "common" and set the active flag using gpart: > > mdi=3D`mdconfig -f _.disk.image......` > gpart set -a active -i 3 $mdi > mdconfig -d -u $mdi > > Which works if used in place of the "-a...." argument to the mkimg > command. Perhaps this should be changed in the "common" script and mad= e > the general case, at least for 11-STABLE and before, since it should > work with pretty-much any version of FreeBSD and obviates the need for > the updated mkimg. As things stand right now a checkout of 11-STABLE > has a common script that relies on an updated mkimg that isn't present > in the system and thus will//not work. > > This is what I changed in common: > > case ${NANO_LAYOUT} in > std-embedded) > # mkimg -a 3 ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p > ${s1}:=3D${NANO_LOG}/_.s1 \ > mkimg ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p > ${s1}:=3D${NANO_LOG}/_.s1 \ > -p ${s2}:=3D${NANO_LOG}/_.s2 \ > -p ${s3}:=3D${NANO_LOG}/_.s3 \ > -o ${out} > mdi=3D`mdconfig -f ${out}` > gpart show $mdi > gpart set -a active -i 3 $mdi > gpart show $mdi > mdconfig -d -u $mdi > ;; > > The two "shows" are (obviously) not necessary but result in log output > that shows the active flag successfully set. > > Partial output from _.di incorporating this change: > > Populating `/pics/CrossBuild/embedded/rpi2/_.s2' > Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete > + [ -n s1 ] > + eval 's1=3Dfat16b' > + s1=3Dfat16b > + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > + mkimg -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.s1' -p > 'freebsd:=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p > 'freebsd:=3D/pics/CrossBuild/embedded/rpi2/_.s3' -o > /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > + mdconfig -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > + mdi=3Dmd0 > + gpart show md0 > =3D> 1 429840 md0 MBR (210M) > 1 65536 1 fat16 (32M) > 65537 65536 2 freebsd (32M) > 131073 298768 3 freebsd (146M) > > + gpart set -a active -i 3 md0 > active set on md0s3 > + gpart show md0 > =3D> 1 429840 md0 MBR (210M) > 1 65536 1 fat16 (32M) > 65537 65536 2 freebsd (32M) > 131073 298768 3 freebsd [active] (146M) > > + mdconfig -d -u md0 > + rm -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz > + echo 'NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP= =2Exz' > NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz > + uname -r > + command rm -x -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP= =2Exz > + xz -9 --keep /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > > > Onward I go... now I need to figure out how to get packages to work in = a > cross-compiled world, which might be a bit of a bigger problem since th= e > existing way it's done chroot's into the installed world, which of > course means that the "pkg" command is for the wrong architecture..... The above works -- almost. The system boots on first start, gets an IP address, sets time and such and then hangs here: =2E.... Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat Soft Float compatibility ldconfig path: Setting hostname: nanobsd-HD-MCP. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,AT= TACH,CACHED Feeding entropy: eval: cannot create /boot/entropy: Read-only file system= smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 ue0: flags=3D8843 metric 0 mtu 15= 00 options=3D80009 ether b8:27:eb:be:e6:f8 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 Starting devd. Starting dhclient. DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.1.200 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.200 bound to 192.168.1.216 -- renewal in 21600 seconds. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Creating and/or trimming log files. Starting syslogd. Setting date via ntp. 5 Feb 21:03:24 ntpdate[464]: step time server 74.104.167.114 offset 301.729232 sec Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Configuring vt: blanktime. Starting cron. It does have the console requested on the serial interface, but I never get a login prompt. It doesn't appear to be hanging on the actual cron startup (I can't ^C out of it which would otherwise be the case.)=20 Networking is (obviously) running as it does get the time and I can ping it. This implies that I have no getty running, but "onifconsole" IS specified in the /etc/ttys file. This could get to be a bit fun trying to figure out why it's freezing during the startup and before an actual login prompt is produced -- or whether the "onifconsole" is being ignored in /etc/ttys (looks likely, but how to check?) Even more-interesting is that a (or other characters) typed at it while it's hung *does* echo..... Do I need "console=3Dcomconsole" in /boot/loader.conf? I would think setting the option in the nanobsd config file would generate that, but it does not appear to -- and it also doesn't appear to be necessary, because I do get all the boot messages on the serial console side. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080504040601000007000701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDUyMTIyMjhaME8GCSqGSIb3DQEJBDFCBEBEwtIZ TUIrCFXFYNLHSlK/iB+hi2JY9QDe5GFYUeiMkIIhKgE/6mX7re28TPWjJlrTjR00cibH+G+w JPFjOu7XMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAfMNF0xpA7BVf io0vP35HXTEYfDZ/pza/9dVguIuOxwYC707QSssKk6n8Xa2/B2ettspqy7pyYFsEOe8KK9is oZU5DN0Po1PoGQTwDP1/Bz9N0/awTyZuLWtBcSKEYCjqGlagQr+9xxe8qfoVzwD3X2FMaQHp ixeTufgSZpNIai/9wwwtT3E49YK0dH/q2E//rhRaA+/ewA+fkhDsRVE6O8H2tSRTBWsm+mvv pFNVQLRK3F+EH8dRzuHtNEL6EcfOfFFeK3isJPqqcK+W6uUI+HIZPGMXQzYS0Xu0Dx8reeNn L5YVsOvW/UOlcAh4dxP28iliFkGX1l0CvwmLFlZX0OrpM50SwEsDSETbdN4OXsoRB5J5VE/k 6oaSG0Qb91sepGzSNWlyuujhq5lz9/AUDBWACuyUvjPDcN273q4X2aRv5BTKEltIFdnzHBoF ZxaTwc3X6pvR3pSg+1DYVJS90r8AA3ON0/row2pu3PyrOBs7ETFxengTI2QWm3IxNAcvCsIq MksjkOCZbVaNKCkoLWptP2BhQvBuO/fvcfrWdPhhD09M4yPRrb5NGheQzMcrKICGGOnSWS+o WRid7Hh13w2OFgPWQr0JoER8SPZL9A3HmLo8ViEbGog9eea8B5HLv5c/D7wN6uPJqfUucGQG G+avAHbJAcLZispzEqsSXkUAAAAAAAA= --------------ms080504040601000007000701-- From owner-freebsd-arm@freebsd.org Sun Feb 5 22:55:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7734ECD2AA2 for ; Sun, 5 Feb 2017 22:55:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4738F87A for ; Sun, 5 Feb 2017 22:55:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id c7so46545471itd.1 for ; Sun, 05 Feb 2017 14:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+VlAiHrY1+6VTBjKxCvAodsk/S4xllFOi3rkRZiboyI=; b=UAg32NDRCbTB653NIMNcgUxLsV4pg9fSvgH4qRw6bE+VOAGWl2/Afc37FNQ/pUldIP QOV3aIAERxjUwQCFmR4DRWrLUy6v4Dsx1UXSUrCFJc2aZkgYVrq2qc+73cF8hU4SkYSg ctf5UYdvOY2w3vGyTU2+b0exBNjezRafcK1I8rnTws7+NkTEEUg9EFX+n4zCzkhnjWZb vxlX+64iiIdTlpneybJKXryYLET94QaQMu/eBCk/iHoCG6eENauYIZZVgyfk4m1GLp3g Puy7RDHeSE7UYfhxrDiLI8hOCLATomq5JEL8bpIPzljMof8/eUTUihQOv+NkCKZSd2ct Sq2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+VlAiHrY1+6VTBjKxCvAodsk/S4xllFOi3rkRZiboyI=; b=qfsJPeTupP7vUFkmKF2hKa/J1PL3bXIwAzl+bVjtrvpXsH2Z3X13jPK9ff7aPfEE5/ 2Hsq3INDPZlOs7PhK+KcWzdl6hfH3l2g70wJ6A0m/KgvjsTW+mI0LmhcZJgUuHwPVjDr RElVONb+wyXbDE42bHqqAeNTAl0nSRCRX5JzEoEaLdPKzxJ3Y5Q+fkPHfc0IXs7G5PC+ WM8TOMd00oQ/eo/PybUlsEOpxGyN3/Br5islm6HRvVEfyyesKAzgPzT+YtpjSXydHCEU 2NWQfT9nvYsV5rfYhKmEqtLB8igt8JB2YHF7aJQtuePKBsuWCPR6CWe/IXOa6HR5OtPG 8Nwg== X-Gm-Message-State: AIkVDXIHj3vs+M0RmNIR5Rapka9NUhpJTYzsT/x0gPTMtiYCCJLcqsdZ2q7PEOCmQAkGX2qVa24qd1De0xcSxQ== X-Received: by 10.36.116.71 with SMTP id o68mr5674040itc.60.1486335332382; Sun, 05 Feb 2017 14:55:32 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sun, 5 Feb 2017 14:55:31 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> From: Warner Losh Date: Sun, 5 Feb 2017 15:55:31 -0700 X-Google-Sender-Auth: Ddnsj3iFRR1v_nS_JQOEekup_P4 Message-ID: Subject: Re: NanoBSD config script for RPI2 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 22:55:33 -0000 On Sun, Feb 5, 2017 at 9:53 AM, Karl Denninger wrote: > On 2/4/2017 15:02, Mark Millard wrote: >> On 2017-Feb-4, at 10:56 AM, Karl Denninger > > wrote: >> >>> On 2/4/2017 10:38, Warner Losh wrote: >>>> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger >>> denninger.net > wrote: >>>>> It fails here during image create.... >>>>> >>>>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>>>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>>>> + [ -n s1 ] >>>>> + eval 's1=fat16b' >>>>> + s1=fat16b >>>>> + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>> + mkimg -a 3 -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p >>>>> 'freebsd >>>>> :=/pics/CrossBuild/embedded/rpi2/_.s2' -p >>>>> 'freebsd:=/pics/CrossBuild/embedded/rp >>>>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>> mkimg: invalid option -- a >>>>> mkimg: error: unknown option >>>>> >>>>> usage: mkimg >>>>> options: >>>>> --formats - list image formats >>>>> --schemes - list partition schemes >>>>> --version - show version information >>>>> >>>>> -b - file containing boot code >>>>> -c - capacity (in bytes) of the disk >>>>> -f >>>>> -o - file to write image into >>>>> -p >>>>> -s >>>>> -v - increase verbosity >>>>> -y - [developers] enable unit test >>>>> -H - number of heads to simulate >>>>> -P - physical sector size >>>>> -S - logical sector size >>>>> -T - number of tracks to simulate >>>>> >>>>> formats: >>>>> qcow - QEMU Copy-On-Write, version 1 >>>>> qcow2 - QEMU Copy-On-Write, version 2 >>>>> raw - Raw Disk >>>>> vhd - Virtual Hard Disk >>>>> vhdf - Fixed Virtual Hard Disk >>>>> vmdk - Virtual Machine Disk >>>>> >>>>> schemes: >>>>> apm - Apple Partition Map >>>>> bsd - BSD disk label >>>>> ebr - Extended Boot Record >>>>> gpt - GUID Partition Table >>>>> mbr - Master Boot Record >>>>> pc98 - PC-9800 disk partitions >>>>> vtoc8 - SMI VTOC8 disk labels >>>>> >>>>> Is the "-a" flag attempting to set the active partition? It appears >>>>> there's no option to do that in mkimg... >>>> Install a newer mkimg: >>>> >>>> Revision 307550 - (view) (download) (annotate) - [select for diffs] >> >> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >> -r3125699 is from head. >> >> Looking around: stable/11 has not been updated for its mkimg. only >> head has -a added at this point. >> >>>> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp >>>> File length: 3730 byte(s) >>>> Diff to previous 307544 >>>> >>>> Add a new flag to mkimg (-a num) to specify the active partition for >>>> those partitioning schemes that have this concept. Implement it as an >>>> override for mbr's setting 0x80 in the flags for the first partition >>>> when we have boot code. >>>> >>>> Differential Revision: https://reviews.freebsd.org/D4403 >>>> >>>> Though maybe I should try to add it to the bootstrap tools so I can >>>> use a new one after the build. >>>> >>>> Warner >>>> >>> root@NewFS:/disk/karl # uname -v >>> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 >> >> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >> -r3125699 is from head, not from stable/11 . >> >> If you have a mix of head and stable/11 materials with mkimg from >> stable/11 then -a will not be present for mkimg. >> >>> karl@NewFS.denninger.net >>> :/usr/obj/usr/src/sys/KSD-SMP >>> root@NewFS:/disk/karl # which mkimg >>> /usr/bin/mkimg >>> root@NewFS:/disk/karl # pkg install mkimg >>> Updating FreeBSD repository catalogue... >>> FreeBSD repository is up-to-date. >>> All repositories are up-to-date. >>> pkg: No packages available to install matching 'mkimg' have been found >>> in the repositories >>> root@NewFS:/disk/karl # >>> >>> So.... it's part of base and there is no obvious package (a check for >>> ports in */*mkimg* fails too); my system is current as of Jan 23.... >>> >>> (As an aside I think if I remove the -a it may work on the Pi, since the >>> Pi will try to boot the first partition which happens to be DOS -- I >>> think. I'll try it.) >>> >>> -- >>> Karl Denninger >>> karl@denninger.net >> denninger.net > >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ >> >> >> === >> Mark Millard >> markmi at dsl-only.net >> > > Manually setting the third partition to active does work to boot, but > the default partition settings for root and cfg are also wrong; you need > these overrides or the mount of root fails on startup: > > # > # Partition layout for the Pi2 is: > # 1 = FAT16 boot (MSDOS) containing bootcode, ubldr, etc. > # 2 = CFG > # 3 = Root (must be separately marked active so ubldr can find it) > # 4 = Altroot > # > NANO_SLICE_CFG=s2 > NANO_SLICE_ROOT=s3 > NANO_SLICE_ALTROOT=s4 > NANO_ROOT=s3a > NANO_ALTROOT=s4a > > I'm working on some other issues but this allows the unit to boot up and > start. You do need to mark the partition active manually but there's a > workaround for the need to do that manually -- mount the image after > it's built in "common" and set the active flag using gpart: > > mdi=`mdconfig -f _.disk.image......` > gpart set -a active -i 3 $mdi > mdconfig -d -u $mdi > > Which works if used in place of the "-a...." argument to the mkimg > command. Perhaps this should be changed in the "common" script and made > the general case, at least for 11-STABLE and before, since it should > work with pretty-much any version of FreeBSD and obviates the need for > the updated mkimg. As things stand right now a checkout of 11-STABLE > has a common script that relies on an updated mkimg that isn't present > in the system and thus will//not work. > > This is what I changed in common: > > case ${NANO_LAYOUT} in > std-embedded) > # mkimg -a 3 ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p > ${s1}:=${NANO_LOG}/_.s1 \ > mkimg ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p > ${s1}:=${NANO_LOG}/_.s1 \ > -p ${s2}:=${NANO_LOG}/_.s2 \ > -p ${s3}:=${NANO_LOG}/_.s3 \ > -o ${out} > mdi=`mdconfig -f ${out}` > gpart show $mdi > gpart set -a active -i 3 $mdi > gpart show $mdi > mdconfig -d -u $mdi > ;; Yea, I'm not going to make that change. mkimg can run as the user, all the other stuff requires root. I'll see about changing it to use a mkimg build as an extra build tool in buildworld though. > The two "shows" are (obviously) not necessary but result in log output > that shows the active flag successfully set. > > Partial output from _.di incorporating this change: > > Populating `/pics/CrossBuild/embedded/rpi2/_.s2' > Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete > + [ -n s1 ] > + eval 's1=fat16b' > + s1=fat16b > + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > + mkimg -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p > 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s2' -p > 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s3' -o > /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > + mdconfig -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > + mdi=md0 > + gpart show md0 > => 1 429840 md0 MBR (210M) > 1 65536 1 fat16 (32M) > 65537 65536 2 freebsd (32M) > 131073 298768 3 freebsd (146M) > > + gpart set -a active -i 3 md0 > active set on md0s3 > + gpart show md0 > => 1 429840 md0 MBR (210M) > 1 65536 1 fat16 (32M) > 65537 65536 2 freebsd (32M) > 131073 298768 3 freebsd [active] (146M) > > + mdconfig -d -u md0 > + rm -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz > + echo 'NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz' > NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz > + uname -r > + command rm -x -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz > + xz -9 --keep /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > > > Onward I go... now I need to figure out how to get packages to work in a > cross-compiled world, which might be a bit of a bigger problem since the > existing way it's done chroot's into the installed world, which of > course means that the "pkg" command is for the wrong architecture..... Yes. I need to add that to the base NanoBSD as well. There's two approaches: one is to try to add them directly with the recent support for that from pkg. The other is to include packages on the media and install them on first boot. I'm leaning towards the former. Warner From owner-freebsd-arm@freebsd.org Sun Feb 5 22:57:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BB2ACD2B50 for ; Sun, 5 Feb 2017 22:57:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32141967 for ; Sun, 5 Feb 2017 22:57:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id r185so46693457ita.0 for ; Sun, 05 Feb 2017 14:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XmwEhBJaV0LY0d7Ab3oAj7uorY7jxKGW7hGo6mvjHRo=; b=t1a828u+R10d3NbI1s5hpTbw3oZvoAuk0KpqBzGQiCF63r6+de3ihktC0td0Mz3EAJ MFXOni/Y78I2uMVopgysOAygPL4iDaYKUGqRJt5FfQkB/80M/z2N6T5eRJYu3WLPYJ14 OyoHHR1bVF1ZrhWGTHzjxN1OO3a24qg54FmeE0rN4k10onWQ0BZe7vyrkLrEQTmbaI5E 9VTVqRBUEXj39zNIXqzcInkZHcyW/SMq19M96EzR4XgwY6wsAcCTW+FmhmqA3nMglASq eXCQuuwKS0AeGdOybIsxi4WhZKD5yEOZlfuZMpzZyXW4olbHuyDx2wtdoXgp4q3l61dk O7GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XmwEhBJaV0LY0d7Ab3oAj7uorY7jxKGW7hGo6mvjHRo=; b=Ul/24BTRXS1lEgFE3ssGkTDfr73NjEgp3ZC8c6c2BYw4kYFKKQPQtOZLuLpTPUbjLw G0Xp75UJB4opSFuDCacQIQbBZ8xlHFzjyoeuWikgMNY+UJG6PxiUAzNUDdt14cqE3RSk +08N1i7P4fli2dXu7dGTjy7xgc23WGBdZvOA+TMcGqWZd3rBcERDou7GbYsLJiW56s1g MO6YS5WCP26InKWAh2ntjh2jFGSE0vUZFC9uer7ssbUEJSibu3ljwDjoXmLRH0r96sED YjKfaQPNLrQ2zQPRW8K25sNi5qRK/RxCmJeY0xXNizvfjBqTfAbBW55fAH5kvlPuMla9 cYNQ== X-Gm-Message-State: AIkVDXKHY5PKF4faYTAiBq7XfQwgT4u9ZirNMeNLk35t+nFS7UXFvJBRf1Jp71ldAMh4r8t6NUBcuGW1mpGMDQ== X-Received: by 10.36.79.13 with SMTP id c13mr4983667itb.103.1486335427424; Sun, 05 Feb 2017 14:57:07 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sun, 5 Feb 2017 14:57:06 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> From: Warner Losh Date: Sun, 5 Feb 2017 15:57:06 -0700 X-Google-Sender-Auth: 2gKwx7ys9btKrymDJuYB19qe7uI Message-ID: Subject: Re: NanoBSD config script for RPI2 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 22:57:08 -0000 On Sun, Feb 5, 2017 at 2:22 PM, Karl Denninger wrote: > On 2/5/2017 10:53, Karl Denninger wrote: >> On 2/4/2017 15:02, Mark Millard wrote: >>> On 2017-Feb-4, at 10:56 AM, Karl Denninger >> > wrote: >>> >>>> On 2/4/2017 10:38, Warner Losh wrote: >>>>> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger >>>> denninger.net > wrote: >>>>>> It fails here during image create.... >>>>>> >>>>>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>>>>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>>>>> + [ -n s1 ] >>>>>> + eval 's1=fat16b' >>>>>> + s1=fat16b >>>>>> + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>>> + mkimg -a 3 -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p >>>>>> 'freebsd >>>>>> :=/pics/CrossBuild/embedded/rpi2/_.s2' -p >>>>>> 'freebsd:=/pics/CrossBuild/embedded/rp >>>>>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>>> mkimg: invalid option -- a >>>>>> mkimg: error: unknown option >>>>>> >>>>>> usage: mkimg >>>>>> options: >>>>>> --formats - list image formats >>>>>> --schemes - list partition schemes >>>>>> --version - show version information >>>>>> >>>>>> -b - file containing boot code >>>>>> -c - capacity (in bytes) of the disk >>>>>> -f >>>>>> -o - file to write image into >>>>>> -p >>>>>> -s >>>>>> -v - increase verbosity >>>>>> -y - [developers] enable unit test >>>>>> -H - number of heads to simulate >>>>>> -P - physical sector size >>>>>> -S - logical sector size >>>>>> -T - number of tracks to simulate >>>>>> >>>>>> formats: >>>>>> qcow - QEMU Copy-On-Write, version 1 >>>>>> qcow2 - QEMU Copy-On-Write, version 2 >>>>>> raw - Raw Disk >>>>>> vhd - Virtual Hard Disk >>>>>> vhdf - Fixed Virtual Hard Disk >>>>>> vmdk - Virtual Machine Disk >>>>>> >>>>>> schemes: >>>>>> apm - Apple Partition Map >>>>>> bsd - BSD disk label >>>>>> ebr - Extended Boot Record >>>>>> gpt - GUID Partition Table >>>>>> mbr - Master Boot Record >>>>>> pc98 - PC-9800 disk partitions >>>>>> vtoc8 - SMI VTOC8 disk labels >>>>>> >>>>>> Is the "-a" flag attempting to set the active partition? It appears >>>>>> there's no option to do that in mkimg... >>>>> Install a newer mkimg: >>>>> >>>>> Revision 307550 - (view) (download) (annotate) - [select for diffs] >>> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >>> -r3125699 is from head. >>> >>> Looking around: stable/11 has not been updated for its mkimg. only >>> head has -a added at this point. >>> >>>>> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp >>>>> File length: 3730 byte(s) >>>>> Diff to previous 307544 >>>>> >>>>> Add a new flag to mkimg (-a num) to specify the active partition for >>>>> those partitioning schemes that have this concept. Implement it as an >>>>> override for mbr's setting 0x80 in the flags for the first partition >>>>> when we have boot code. >>>>> >>>>> Differential Revision: https://reviews.freebsd.org/D4403 >>>>> >>>>> Though maybe I should try to add it to the bootstrap tools so I can >>>>> use a new one after the build. >>>>> >>>>> Warner >>>>> >>>> root@NewFS:/disk/karl # uname -v >>>> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 >>> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >>> -r3125699 is from head, not from stable/11 . >>> >>> If you have a mix of head and stable/11 materials with mkimg from >>> stable/11 then -a will not be present for mkimg. >>> >>>> karl@NewFS.denninger.net >>>> :/usr/obj/usr/src/sys/KSD-SMP >>>> root@NewFS:/disk/karl # which mkimg >>>> /usr/bin/mkimg >>>> root@NewFS:/disk/karl # pkg install mkimg >>>> Updating FreeBSD repository catalogue... >>>> FreeBSD repository is up-to-date. >>>> All repositories are up-to-date. >>>> pkg: No packages available to install matching 'mkimg' have been found >>>> in the repositories >>>> root@NewFS:/disk/karl # >>>> >>>> So.... it's part of base and there is no obvious package (a check for >>>> ports in */*mkimg* fails too); my system is current as of Jan 23.... >>>> >>>> (As an aside I think if I remove the -a it may work on the Pi, since the >>>> Pi will try to boot the first partition which happens to be DOS -- I >>>> think. I'll try it.) >>>> >>>> -- >>>> Karl Denninger >>>> karl@denninger.net >>> denninger.net > >>>> /The Market Ticker/ >>>> /[S/MIME encrypted email preferred]/ >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >> Manually setting the third partition to active does work to boot, but >> the default partition settings for root and cfg are also wrong; you need >> these overrides or the mount of root fails on startup: >> >> # >> # Partition layout for the Pi2 is: >> # 1 = FAT16 boot (MSDOS) containing bootcode, ubldr, etc. >> # 2 = CFG >> # 3 = Root (must be separately marked active so ubldr can find it) >> # 4 = Altroot >> # >> NANO_SLICE_CFG=s2 >> NANO_SLICE_ROOT=s3 >> NANO_SLICE_ALTROOT=s4 >> NANO_ROOT=s3a >> NANO_ALTROOT=s4a >> >> I'm working on some other issues but this allows the unit to boot up and >> start. You do need to mark the partition active manually but there's a >> workaround for the need to do that manually -- mount the image after >> it's built in "common" and set the active flag using gpart: >> >> mdi=`mdconfig -f _.disk.image......` >> gpart set -a active -i 3 $mdi >> mdconfig -d -u $mdi >> >> Which works if used in place of the "-a...." argument to the mkimg >> command. Perhaps this should be changed in the "common" script and made >> the general case, at least for 11-STABLE and before, since it should >> work with pretty-much any version of FreeBSD and obviates the need for >> the updated mkimg. As things stand right now a checkout of 11-STABLE >> has a common script that relies on an updated mkimg that isn't present >> in the system and thus will//not work. >> >> This is what I changed in common: >> >> case ${NANO_LAYOUT} in >> std-embedded) >> # mkimg -a 3 ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p >> ${s1}:=${NANO_LOG}/_.s1 \ >> mkimg ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p >> ${s1}:=${NANO_LOG}/_.s1 \ >> -p ${s2}:=${NANO_LOG}/_.s2 \ >> -p ${s3}:=${NANO_LOG}/_.s3 \ >> -o ${out} >> mdi=`mdconfig -f ${out}` >> gpart show $mdi >> gpart set -a active -i 3 $mdi >> gpart show $mdi >> mdconfig -d -u $mdi >> ;; >> >> The two "shows" are (obviously) not necessary but result in log output >> that shows the active flag successfully set. >> >> Partial output from _.di incorporating this change: >> >> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >> + [ -n s1 ] >> + eval 's1=fat16b' >> + s1=fat16b >> + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >> + mkimg -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p >> 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s2' -p >> 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s3' -o >> /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >> + mdconfig -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >> + mdi=md0 >> + gpart show md0 >> => 1 429840 md0 MBR (210M) >> 1 65536 1 fat16 (32M) >> 65537 65536 2 freebsd (32M) >> 131073 298768 3 freebsd (146M) >> >> + gpart set -a active -i 3 md0 >> active set on md0s3 >> + gpart show md0 >> => 1 429840 md0 MBR (210M) >> 1 65536 1 fat16 (32M) >> 65537 65536 2 freebsd (32M) >> 131073 298768 3 freebsd [active] (146M) >> >> + mdconfig -d -u md0 >> + rm -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >> + echo 'NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz' >> NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >> + uname -r >> + command rm -x -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >> + xz -9 --keep /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >> >> >> Onward I go... now I need to figure out how to get packages to work in a >> cross-compiled world, which might be a bit of a bigger problem since the >> existing way it's done chroot's into the installed world, which of >> course means that the "pkg" command is for the wrong architecture..... > > The above works -- almost. > > The system boots on first start, gets an IP address, sets time and such > and then hangs here: ... > Do I need "console=comconsole" in /boot/loader.conf? I would think > setting the option in the nanobsd config file would generate that, but > it does not appear to -- and it also doesn't appear to be necessary, > because I do get all the boot messages on the serial console side. If nanobsd did its thing right, you should have a getty running on both the serial port and the video "console" regardless of which one is /dev/console. onifconsole isn't that useful in this situation. Warner From owner-freebsd-arm@freebsd.org Mon Feb 6 06:17:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B910CD37A4 for ; Mon, 6 Feb 2017 06:17:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB059128F for ; Mon, 6 Feb 2017 06:17:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id j13so58657029iod.3 for ; Sun, 05 Feb 2017 22:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GclDmnw5ftqxSkz4Im/uu+hHCpN/XKv/KxSNBhwZ/nY=; b=YQPc8fH1/G+1Fm/TszWvtob4wOZfr7NKEeGMBaKP+XJvdsDDKI6j6JG6qYgEDgr8h8 1RqnLTsDUhSGVb7wVp0uc8XEbiZHU34tpsoyQ3P8KmiOs8GUheCuL1UeW4UJlA1oPKOu s6qQhjYSXMSvQlZib8zfINgEHYAvkKGewY7HahQIfzwfwkc52q2MVVP/OYOpa7NWOU6E oV9ReDVPkrTFNjTj2rZrWfGCHSv7Svi4AlKYe25lbZ8ZO/c/LdF2BUiqroKHdekegZ3I D5Sp0HZMQd0KENblpXt0ybeDHSDQTL2WyT1+T8lFVSUS/6Qp/4GwWjyuFWMkUc9Y27OW 34JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GclDmnw5ftqxSkz4Im/uu+hHCpN/XKv/KxSNBhwZ/nY=; b=bc9war/DYJrocCfVdK1nKCYxoLvj/KboMwFhfCYpPhxQlD4ZfiOTLN7xk60d3Rywzy MCfyXqrtQmxPoDWLsOxuyx3+aiESzdTh4N8G9GoKtTRlTFAzNbBB5bsaixogSjeenXQo c46B0Johbg5BdpNMJEGYHHbjkEvudaKcWx4g2Tf82Y6CMIillGCX6+dAJ4ml13kSKCk6 06Pn4toPmYRvuIM6JxjBRtbBvxyriAMsdFNFSfM+l8xUv0AE0WSN0IbMqgXUvF1Gr6NL H3AUHSKGccW/ZkB31nHWEsjTcBWOhNokz8L4PwfOUEb7dUqQcu1dSJGGph+fURpBwpPR 4pBw== X-Gm-Message-State: AMke39nisNi9pL6cjeLM815p2KTnTVnKDd5qSecckAZ27V24QAIK8mDQ4WCHFUFPfTNGtf3tQ90YZuCoP6W21w== X-Received: by 10.107.20.13 with SMTP id 13mr5693982iou.0.1486361827891; Sun, 05 Feb 2017 22:17:07 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sun, 5 Feb 2017 22:17:07 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> From: Warner Losh Date: Sun, 5 Feb 2017 23:17:07 -0700 X-Google-Sender-Auth: 0FZ7xnJwxVuksD3G3BY6gDua_d4 Message-ID: Subject: Re: NanoBSD config script for RPI2 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 06:17:10 -0000 BTW, try r313326. It will fix the mkimg issues as well as the NANO_ROOT issue. It seems to work for me here locally, and corrects a few other issues that were lurking. Warner On Sun, Feb 5, 2017 at 3:57 PM, Warner Losh wrote: > On Sun, Feb 5, 2017 at 2:22 PM, Karl Denninger wrote: >> On 2/5/2017 10:53, Karl Denninger wrote: >>> On 2/4/2017 15:02, Mark Millard wrote: >>>> On 2017-Feb-4, at 10:56 AM, Karl Denninger >>> > wrote: >>>> >>>>> On 2/4/2017 10:38, Warner Losh wrote: >>>>>> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger >>>>> denninger.net > wrote: >>>>>>> It fails here during image create.... >>>>>>> >>>>>>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>>>>>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>>>>>> + [ -n s1 ] >>>>>>> + eval 's1=fat16b' >>>>>>> + s1=fat16b >>>>>>> + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>>>> + mkimg -a 3 -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p >>>>>>> 'freebsd >>>>>>> :=/pics/CrossBuild/embedded/rpi2/_.s2' -p >>>>>>> 'freebsd:=/pics/CrossBuild/embedded/rp >>>>>>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>>>>>> mkimg: invalid option -- a >>>>>>> mkimg: error: unknown option >>>>>>> >>>>>>> usage: mkimg >>>>>>> options: >>>>>>> --formats - list image formats >>>>>>> --schemes - list partition schemes >>>>>>> --version - show version information >>>>>>> >>>>>>> -b - file containing boot code >>>>>>> -c - capacity (in bytes) of the disk >>>>>>> -f >>>>>>> -o - file to write image into >>>>>>> -p >>>>>>> -s >>>>>>> -v - increase verbosity >>>>>>> -y - [developers] enable unit test >>>>>>> -H - number of heads to simulate >>>>>>> -P - physical sector size >>>>>>> -S - logical sector size >>>>>>> -T - number of tracks to simulate >>>>>>> >>>>>>> formats: >>>>>>> qcow - QEMU Copy-On-Write, version 1 >>>>>>> qcow2 - QEMU Copy-On-Write, version 2 >>>>>>> raw - Raw Disk >>>>>>> vhd - Virtual Hard Disk >>>>>>> vhdf - Fixed Virtual Hard Disk >>>>>>> vmdk - Virtual Machine Disk >>>>>>> >>>>>>> schemes: >>>>>>> apm - Apple Partition Map >>>>>>> bsd - BSD disk label >>>>>>> ebr - Extended Boot Record >>>>>>> gpt - GUID Partition Table >>>>>>> mbr - Master Boot Record >>>>>>> pc98 - PC-9800 disk partitions >>>>>>> vtoc8 - SMI VTOC8 disk labels >>>>>>> >>>>>>> Is the "-a" flag attempting to set the active partition? It appears >>>>>>> there's no option to do that in mkimg... >>>>>> Install a newer mkimg: >>>>>> >>>>>> Revision 307550 - (view) (download) (annotate) - [select for diffs] >>>> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >>>> -r3125699 is from head. >>>> >>>> Looking around: stable/11 has not been updated for its mkimg. only >>>> head has -a added at this point. >>>> >>>>>> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp >>>>>> File length: 3730 byte(s) >>>>>> Diff to previous 307544 >>>>>> >>>>>> Add a new flag to mkimg (-a num) to specify the active partition for >>>>>> those partitioning schemes that have this concept. Implement it as an >>>>>> override for mbr's setting 0x80 in the flags for the first partition >>>>>> when we have boot code. >>>>>> >>>>>> Differential Revision: https://reviews.freebsd.org/D4403 >>>>>> >>>>>> Though maybe I should try to add it to the bootstrap tools so I can >>>>>> use a new one after the build. >>>>>> >>>>>> Warner >>>>>> >>>>> root@NewFS:/disk/karl # uname -v >>>>> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 >>>> https://svnweb.freebsd.org/base/?pathrev=312669 shows that >>>> -r3125699 is from head, not from stable/11 . >>>> >>>> If you have a mix of head and stable/11 materials with mkimg from >>>> stable/11 then -a will not be present for mkimg. >>>> >>>>> karl@NewFS.denninger.net >>>>> :/usr/obj/usr/src/sys/KSD-SMP >>>>> root@NewFS:/disk/karl # which mkimg >>>>> /usr/bin/mkimg >>>>> root@NewFS:/disk/karl # pkg install mkimg >>>>> Updating FreeBSD repository catalogue... >>>>> FreeBSD repository is up-to-date. >>>>> All repositories are up-to-date. >>>>> pkg: No packages available to install matching 'mkimg' have been found >>>>> in the repositories >>>>> root@NewFS:/disk/karl # >>>>> >>>>> So.... it's part of base and there is no obvious package (a check for >>>>> ports in */*mkimg* fails too); my system is current as of Jan 23.... >>>>> >>>>> (As an aside I think if I remove the -a it may work on the Pi, since the >>>>> Pi will try to boot the first partition which happens to be DOS -- I >>>>> think. I'll try it.) >>>>> >>>>> -- >>>>> Karl Denninger >>>>> karl@denninger.net >>>> denninger.net > >>>>> /The Market Ticker/ >>>>> /[S/MIME encrypted email preferred]/ >>>> >>>> === >>>> Mark Millard >>>> markmi at dsl-only.net >>>> >>> Manually setting the third partition to active does work to boot, but >>> the default partition settings for root and cfg are also wrong; you need >>> these overrides or the mount of root fails on startup: >>> >>> # >>> # Partition layout for the Pi2 is: >>> # 1 = FAT16 boot (MSDOS) containing bootcode, ubldr, etc. >>> # 2 = CFG >>> # 3 = Root (must be separately marked active so ubldr can find it) >>> # 4 = Altroot >>> # >>> NANO_SLICE_CFG=s2 >>> NANO_SLICE_ROOT=s3 >>> NANO_SLICE_ALTROOT=s4 >>> NANO_ROOT=s3a >>> NANO_ALTROOT=s4a >>> >>> I'm working on some other issues but this allows the unit to boot up and >>> start. You do need to mark the partition active manually but there's a >>> workaround for the need to do that manually -- mount the image after >>> it's built in "common" and set the active flag using gpart: >>> >>> mdi=`mdconfig -f _.disk.image......` >>> gpart set -a active -i 3 $mdi >>> mdconfig -d -u $mdi >>> >>> Which works if used in place of the "-a...." argument to the mkimg >>> command. Perhaps this should be changed in the "common" script and made >>> the general case, at least for 11-STABLE and before, since it should >>> work with pretty-much any version of FreeBSD and obviates the need for >>> the updated mkimg. As things stand right now a checkout of 11-STABLE >>> has a common script that relies on an updated mkimg that isn't present >>> in the system and thus will//not work. >>> >>> This is what I changed in common: >>> >>> case ${NANO_LAYOUT} in >>> std-embedded) >>> # mkimg -a 3 ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p >>> ${s1}:=${NANO_LOG}/_.s1 \ >>> mkimg ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p >>> ${s1}:=${NANO_LOG}/_.s1 \ >>> -p ${s2}:=${NANO_LOG}/_.s2 \ >>> -p ${s3}:=${NANO_LOG}/_.s3 \ >>> -o ${out} >>> mdi=`mdconfig -f ${out}` >>> gpart show $mdi >>> gpart set -a active -i 3 $mdi >>> gpart show $mdi >>> mdconfig -d -u $mdi >>> ;; >>> >>> The two "shows" are (obviously) not necessary but result in log output >>> that shows the active flag successfully set. >>> >>> Partial output from _.di incorporating this change: >>> >>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>> + [ -n s1 ] >>> + eval 's1=fat16b' >>> + s1=fat16b >>> + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mkimg -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p >>> 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s2' -p >>> 'freebsd:=/pics/CrossBuild/embedded/rpi2/_.s3' -o >>> /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mdconfig -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mdi=md0 >>> + gpart show md0 >>> => 1 429840 md0 MBR (210M) >>> 1 65536 1 fat16 (32M) >>> 65537 65536 2 freebsd (32M) >>> 131073 298768 3 freebsd (146M) >>> >>> + gpart set -a active -i 3 md0 >>> active set on md0s3 >>> + gpart show md0 >>> => 1 429840 md0 MBR (210M) >>> 1 65536 1 fat16 (32M) >>> 65537 65536 2 freebsd (32M) >>> 131073 298768 3 freebsd [active] (146M) >>> >>> + mdconfig -d -u md0 >>> + rm -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >>> + echo 'NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz' >>> NANO RM -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >>> + uname -r >>> + command rm -x -f /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP.xz >>> + xz -9 --keep /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> >>> >>> Onward I go... now I need to figure out how to get packages to work in a >>> cross-compiled world, which might be a bit of a bigger problem since the >>> existing way it's done chroot's into the installed world, which of >>> course means that the "pkg" command is for the wrong architecture..... >> >> The above works -- almost. >> >> The system boots on first start, gets an IP address, sets time and such >> and then hangs here: > ... >> Do I need "console=comconsole" in /boot/loader.conf? I would think >> setting the option in the nanobsd config file would generate that, but >> it does not appear to -- and it also doesn't appear to be necessary, >> because I do get all the boot messages on the serial console side. > > If nanobsd did its thing right, you should have a getty running on > both the serial port and the video "console" regardless of which one > is /dev/console. onifconsole isn't that useful in this situation. > > Warner From owner-freebsd-arm@freebsd.org Mon Feb 6 07:37:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 234BDCD3CE1; Mon, 6 Feb 2017 07:37:45 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 979A71E42; Mon, 6 Feb 2017 07:37:44 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v167bYQt064586 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 6 Feb 2017 18:37:40 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id v167bTmg059317 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Feb 2017 18:37:29 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v167bTnD059316; Mon, 6 Feb 2017 18:37:29 +1100 (AEDT) (envelope-from peter) Date: Mon, 6 Feb 2017 18:37:29 +1100 From: Peter Jeremy To: Julien Laffaye Cc: freebsd-arm@freebsd.org, FreeBSD Ports ML Subject: Re: lang/go 1.7.5 fails to install on Arm Message-ID: <20170206073729.GF90481@server.rulingia.com> References: <20170205081133.GA11031@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 07:37:45 -0000 --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Feb-05 20:43:12 +0100, Julien Laffaye wrote: >go/pkg/%%opsys_ARCH%%/runtime/cgo.a > > >is in the plist, but for some reason it is not compiled on arm. >is it the only error ? If I comment that out of .PLIST.mktmp then Go installs without problem and there are no problems running a couple of relatively trivial Go programs. --=20 Peter Jeremy --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYmCe5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0tgIP/3Kj4CRZJ1eqwtAPNGPZjbCV 1OBgC3cjowusEQSzA9DnAirdS1YsZvEQ09PkKVL4WoM93UmZfg77XXq9XQHJqAko xI2Atp7eajinua67e6BKs4IW+sMaNYT274oiI43GLYCt363p6PVdzz2f00Ue1TBK uB+7yDob0anrLIzlbg/myJW0I0MV4xHaPAiQqWx9tnDMzmG8ZZzUUum/EpTakHPI omPVsCqWybvLtQpsCqae1GR+84JI+SyH80/AlFWoxMAZzW9CcMNBjWQISJaXkMDW KWRnd8vHQkuJAEvtA43uwFFJz4L6I9rMlc1UKGYpK6GVZMMKBKHvlYxlUKb+L01c XMJ8aihPr4XTmKe5EIBjSsdeWfTEqEzvicZOnyE9hPX3GGw2mcjIWX7tr/6qS65q y1Z9+DHBBs6mmI55cRZmwjZYMfdIUtF7BiAfpkNUvPNwmDd4wc7n0Ph63AM2EuLV n2a4FMcuDmpU59gh4vlSnCIGrJdm/I8+XoeV+S4456t3CakFHFJZkwfvx7gh0L5T oya2e4IPqQnbW4UdkI0O7zuR/4BG/kithwz7SjkpiFRKz7VP1jzoCot2/Ee/2Eb0 HmlCeF8vBiU9UbotlcOpTXhnje/0GSIu8echnnZzR6aUz/aIMVTE3EBs+bQsVO4m drw+08iSxrEeJMj75YQ9 =5PVl -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From owner-freebsd-arm@freebsd.org Mon Feb 6 14:28:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB53DCD2E28 for ; Mon, 6 Feb 2017 14:28:42 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id AE8DB62C for ; Mon, 6 Feb 2017 14:28:42 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 37B2562D11 for ; Mon, 6 Feb 2017 08:28:41 -0600 (CST) Subject: Re: NanoBSD config script for RPI2 References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> <41e02f9b-7884-1eec-b4e0-a32c962642b9@denninger.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <03b3c4e7-c915-ebd5-d560-bf23673f5215@denninger.net> Date: Mon, 6 Feb 2017 08:28:18 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040008020603040007090500" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 14:28:43 -0000 This is a cryptographically signed message in MIME format. --------------ms040008020603040007090500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/5/2017 16:57, Warner Losh wrote: > On Sun, Feb 5, 2017 at 2:22 PM, Karl Denninger wro= te: >> >> The above works -- almost. >> >> The system boots on first start, gets an IP address, sets time and suc= h >> and then hangs here: > ... >> Do I need "console=3Dcomconsole" in /boot/loader.conf? I would think >> setting the option in the nanobsd config file would generate that, but= >> it does not appear to -- and it also doesn't appear to be necessary, >> because I do get all the boot messages on the serial console side. > If nanobsd did its thing right, you should have a getty running on > both the serial port and the video "console" regardless of which one > is /dev/console. onifconsole isn't that useful in this situation. > > Warner Interesting observation -- I've been chasing problems with the sound subsystem (one of the PRs involved is here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213687) and part of the chase involved updating the bootcode.bin and related files. /The most-recent version of those files from Github results in FreeBSD failing to reliably start/; it will sometimes hang after the ethernet interface identifies and it /also /hangs somewhere in the last few /etc/rc files (and I'm not sure exactly where) -- because those files never all complete init never starts the gettys. I've tried to locate the offending rc file (the shell that init kicks off to run the jobs appears to be spinning in an "R" state, but it's not accumulating time!) but thus far have failed to do so. On a "normally running" system as long as sshd comes up everything looks ok. But if you need to log in via a console, whether serial or otherwise, it looks like it hung because the chain of things that have to run before that gets started *did* hang. Reverting to the u-boot port versions of said files fixes that. Not sure how badly doing so will hose my sound, however.... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040008020603040007090500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDYxNDI4MThaME8GCSqGSIb3DQEJBDFCBEA+yeBx 0AufbVjsW6Djx4ES8/8cTyAGdZAS5/iUZGbqDv1dbYDain1BKf0Ps34TteNA+gyp5yjd0B7K INVXRfreMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAkH0qUdCDofi0 4KrF4RLGYBdLrUy1tkrVnLX18lVUo09fAKu/vCBEElkum+sA9Ep12uDGhNGrJXSWGdRJgAQv nGU1DAefFBchTMbp/5jGgcwHhdfsMOeDLLpcbqLPQlwxIUXaPnOiBHMR1yTTCCq+sWrMGkzN zobq8/euPm9mlMpJdbjfBp+/EOGMknCZmIusckzdgbSwpPX2wMoGzyk8ifC3/14cGiLb+cDU qMjJfKHK/YUfTf+coABmtOB6a8GysIPqeh1JYbgVJqT7hYFmcUJUabkLq3GpO6GmFzp0ftc/ hPq+g2ZI1nwKNySRvPN9Nyzg/yUyaXvvrXQ7+QV8uHfHX7lI7B5feLmGj5dQ2d1dCD/mmdx8 wYZePagAjbXQ7ojnQyfkFeTLZsQINKp6jdTwBtcgPNAF4ZRAbvQGgTkXfgEyXXKvCyJ6x4GM t+todYezw7dW1BvutfCAXTYItk2ktfIbRLvuWo6WMCl6JrzyOlFwC1GHQNATh1xa/zyw2uYw GRp0rRNdFLkB6qn5dGJki/wL/JOSNQRIpHQfiwaPILhpFYgo0FdvEMMP20j6HLO4QZluDYzg Ok7nNU83fNGlsPxwboYS6mxzm6qUCpuZpP6Mj8L9RIPBaANZ1ND1hca4bKnKsuKDBdCOfJoI YJnYtrADDM3/eE/4Z+L2yaoAAAAAAAA= --------------ms040008020603040007090500-- From owner-freebsd-arm@freebsd.org Mon Feb 6 14:58:47 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A13ACD3596 for ; Mon, 6 Feb 2017 14:58:47 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 2E70B19A7 for ; Mon, 6 Feb 2017 14:58:46 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3E4D12AE165 for ; Mon, 6 Feb 2017 08:58:46 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Will 11-STABLE boot and run on RPI3? Message-ID: <4aee29bc-7c1f-4b34-93c6-b3047d69ef46@denninger.net> Date: Mon, 6 Feb 2017 08:58:23 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040700020800030207090302" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 14:58:47 -0000 This is a cryptographically signed message in MIME format. --------------ms040700020800030207090302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just trying to figure out if I need to step up to -HEAD if I want to play with the "3"... I assume we still do not have SDIO support and thus no onboard LAN, correct? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040700020800030207090302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDYxNDU4MjNaME8GCSqGSIb3DQEJBDFCBEClW6+z 9NeC/73C/0XrKS3HAOTVBaprTLjy+qaH+DRbvSGTLIZauTuBgu/ZMgJnMNIiLvrQ5shlv7lL 4b9YtjHTMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAKA2qz0jpB5vP nHYX8ywssGJpw9BHT3S6cKyMWXPHQZYOorkOHH1elHRPk+ZsGlgKp+XClXBTp3KI/Az3i/Wi EtbO3+VtiaDAJuHtk10Hb8EZ+JoDRC/maDVcs016eH6BcJOc0OiTBcfA7I0FnHTFpjwjVfvd hzVTEMf1AM9xr/7XYG3Oqf6MmPS33aRo+AilOcShLNZFGX2SAAaH3PWD11zt08y9PWoMJVBh Byns7t6XcDjQLFIghdw0X18ZkwYFVrR09NkY0e4Q5GnuWZXLNoWgoeYs9UOs5Zl9L4MO7ipY jvuk2DxBUjv3XzCfBLIHNUtwaXhiUsvsMHv++aOHjIhzd20AV9QkuR42qM7D8F87Z8v5C4I+ sdTx87DFOIRBJVX/P7oU+DDMC6f/l51CHZONoTzp10D+MnLmwvQqfv8cyH9Z2CrSdniSOc9D mCRZTXKtKAYfLt6nwDAt4LQqLs5JzsHfL0NiuuO230Yrm6nhshqX5bzqvEVyZnn1vjDuQGZj CBwkeeOroVtW4OHqOlpplUBBIPaEQXTIkGL9V+mzTztJI8Z5M4r9rBbFgaQYezfB+LatIHd5 pk/yWhnIu4OqoyEGK/xb/M9Ni57fuai3l1J6Q+TUmuqGWGrWRhRWHFfKr2+eYdC8Wl3AMZpW Tuhkr3XJKAVZctrlcUGC72wAAAAAAAA= --------------ms040700020800030207090302-- From owner-freebsd-arm@freebsd.org Mon Feb 6 21:29:18 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F50ECD3128 for ; Mon, 6 Feb 2017 21:29:18 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5057E9 for ; Mon, 6 Feb 2017 21:29:17 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 2D34031A2B; Mon, 6 Feb 2017 14:29:16 -0700 (MST) Date: Mon, 6 Feb 2017 14:29:16 -0700 From: Brad Davis To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: Will 11-STABLE boot and run on RPI3? Message-ID: <20170206212916.GX70816@corpmail.liquidneon.com> References: <4aee29bc-7c1f-4b34-93c6-b3047d69ef46@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4aee29bc-7c1f-4b34-93c6-b3047d69ef46@denninger.net> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:29:18 -0000 On Mon, Feb 06, 2017 at 08:58:23AM -0600, Karl Denninger wrote: > Just trying to figure out if I need to step up to -HEAD if I want to > play with the "3"... I assume we still do not have SDIO support and thus > no onboard LAN, correct? s/LAN/WLAN/, but yeah. I just put a new image on http://raspbsd.org/raspberrypi.html if you want to give it a spin. Regards, Brad Davis From owner-freebsd-arm@freebsd.org Tue Feb 7 04:05:36 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FFDBCD406F for ; Tue, 7 Feb 2017 04:05:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-70.reflexion.net [208.70.210.70]) (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 1EA9B1714 for ; Tue, 7 Feb 2017 04:05:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32197 invoked from network); 7 Feb 2017 04:06:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Feb 2017 04:06:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Mon, 06 Feb 2017 23:05:28 -0500 (EST) Received: (qmail 30049 invoked from network); 7 Feb 2017 04:05:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Feb 2017 04:05:28 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 8894DEC8081; Mon, 6 Feb 2017 20:05:27 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Mon, 6 Feb 2017 20:05:26 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> <7B5DF446-6740-43DE-823D-B6ECBECF0C32@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: <7B5DF446-6740-43DE-823D-B6ECBECF0C32@dsl-only.net> Message-Id: <1B1EEC5E-9875-417F-9901-A66CB5885634@dsl-only.net> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 04:05:36 -0000 [I got a lucky sh core dump with more stack context/content available to look at for an example sh crash. This helps narrow things down.] On 2017-Feb-5, at 1:12 AM, Mark Millard wrote: > [Top post of a new result.] >=20 > Using lldb to look at the memory for the stack around > sh failure points has some apparently fixed structure. > Example: >=20 > . . . junk values . . . > 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 > 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 > 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 > 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 > 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 > 0xffffffffe520: 0x0000000000000000 0x0000000000000000 > 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 > 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 > 0xffffffffe550: 0x0000000000434000 0x000000000000000f > 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 > 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e > 0xffffffffe580: 0x0000000000000001 0x0000000000000005 > 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 > . . . junk values . . . I got lucky and got a core dump that did not have the junk areas and could trace the stack's frame pointer chain between main and libc.so.7`__free (through freejob along the way). See later. > where "register read" showed: >=20 > sp =3D 0x0000ffffffffe600 >=20 > (The distance and direction to the last non-junk line > from the reported sp in each example is the same.) > Looking around that 0x000000000040f490: >=20 > 0x40f48c: 0x97fffc74 bl 0x40e65c ; freejob = at jobs.c:463 > 0x40f490: 0x9100c294 add x20, x20, #0x30 ; =3D0x30=20= >=20 > It is the same address and code in each case. I should have originally noted that 0x40f48c is in forkshell, along the child process code-path: pid_t forkshell(struct job *jp, union node *n, int mode) { . . . (see /usr/src/bin/sh/jobs.c for this) . . . INTOFF; if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) checkzombies(); flushall(); pid =3D fork(); if (pid =3D=3D -1) { TRACE(("Fork failed, errno=3D%d\n", errno)); INTON; error("Cannot fork: %s", strerror(errno)); } if (pid =3D=3D 0) { struct job *p; int wasroot; int i; =20 TRACE(("Child shell %d\n", (int)getpid())); wasroot =3D rootshell; rootshell =3D 0; handler =3D &main_handler; closescript(); INTON; forcelocal =3D 0; clear_traps(); #if JOBS . . . (see /usr/src/bin/sh/jobs.c for this) . . . #else . . . (see /usr/src/bin/sh/jobs.c for this) . . . #endif INTOFF; for (i =3D njobs, p =3D jobtab ; --i >=3D 0 ; p++) if (p->used) freejob(p); INTON; if (wasroot && iflag) { setsignal(SIGINT); setsignal(SIGQUIT); setsignal(SIGTERM); } return pid; } . . . (see /usr/src/bin/sh/jobs.c for this) . . . > Sometimes the junk values are all zeros over sizable > distances. Sometimes the sizable areas seem to have > random data. >=20 > /usr/src/bin/sh/jobs.c 's freejobs is: >=20 > static void > freejob(struct job *jp) > { > struct procstat *ps; > int i; >=20 > INTOFF; > if (bgjob =3D=3D jp) > bgjob =3D NULL; > for (i =3D jp->nprocs, ps =3D jp->ps ; --i >=3D 0 ; ps++) { > if (ps->cmd !=3D nullstr) > ckfree(ps->cmd); > } > if (jp->ps !=3D &jp->ps0) > ckfree(jp->ps); > jp->used =3D 0; > #if JOBS > deljob(jp); > #endif > INTON; > } >=20 > /usr/src/bin/sh/error.h defines INTOFF and INTON: >=20 > #define EXINT 0 /* SIGINT received */ > #define EXERROR 1 /* a generic error */ > #define EXEXEC 2 /* command execution failed */ > #define EXEXIT 3 /* call exitshell(exitstatus) */ >=20 > . . . >=20 > extern struct jmploc *handler; > extern volatile sig_atomic_t exception; >=20 > . . . >=20 > extern volatile sig_atomic_t suppressint; > extern volatile sig_atomic_t intpending; >=20 > #define INTOFF suppressint++ > #define INTON { if (--suppressint =3D=3D 0 && intpending) onint(); } > #define is_int_on() suppressint > #define SETINTON(s) suppressint =3D (s) > #define FORCEINTON {suppressint =3D 0; if (intpending) onint();} > #define SET_PENDING_INT intpending =3D 1 > #define CLEAR_PENDING_INT intpending =3D 0 > #define int_pending() intpending >=20 > void exraise(int) __dead2; > void onint(void) __dead2; >=20 > /usr/src/bin/sh/error.c hAS: >=20 > void > exraise(int e) > { > INTOFF; > if (handler =3D=3D NULL) > abort(); > exception =3D e; > longjmp(handler->loc, 1); > } > . . . > void > onint(void) > { > sigset_t sigs; >=20 > intpending =3D 0; > sigemptyset(&sigs); > sigprocmask(SIG_SETMASK, &sigs, NULL); >=20 > /* > * This doesn't seem to be needed, since main() emits a = newline. > */ > #if 0 > if (tcgetpgrp(0) =3D=3D getpid()) > write(STDERR_FILENO, "\n", 1); > #endif > if (rootshell && iflag) > exraise(EXINT); > else { > signal(SIGINT, SIG_DFL); > kill(getpid(), SIGINT); > _exit(128 + SIGINT); > } > } >=20 > # grep setjmp /usr/src/bin/sh/* > /usr/src/bin/sh/TOUR:so I implement it using setjmp and longjmp. The = global variable > /usr/src/bin/sh/error.h:#include > /usr/src/bin/sh/error.h: * BSD setjmp saves the signal mask, which = violates ANSI C and takes time, > /usr/src/bin/sh/error.h: * so we use _setjmp instead. > /usr/src/bin/sh/error.h:#define setjmp(jmploc) _setjmp(jmploc) > /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { > /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) > /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { > /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { > /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { > /usr/src/bin/sh/histedit.c: if (setjmp(jmploc.loc)) { > /usr/src/bin/sh/jobs.c: if (setjmp(jmploc.loc)) > /usr/src/bin/sh/main.c: * commands. The setjmp call sets up the = location to jump to when an > /usr/src/bin/sh/main.c: if (setjmp(main_handler.loc)) { > /usr/src/bin/sh/parser.c: if (setjmp(jmploc.loc)) { > /usr/src/bin/sh/parser.c: if (!setjmp(jmploc.loc)) { > /usr/src/bin/sh/trap.c: if (!setjmp(loc1.loc)) { > /usr/src/bin/sh/trap.c: if (!setjmp(loc2.loc)) { > /usr/src/bin/sh/var.c: if (setjmp(jmploc.loc)) Here is the call chain that I was able to trace in the newer core dump: (most nested first to least nested last; showing frame pointer and lr value pairs and calls/return-places) (ifree is not in the core file) 0xffffffffcc60: 0x0000ffffffffcca0 0x000000004054cd94 libc.so.7`__free: 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 0x4054cd94 <+148>: adrp x9, 185 0xffffffffcca0: 0x0000ffffffffccc0 0x0000000000411300 sh`ckfree: 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free 0x411300 <+32>: ldr x8, [x19, #0x970] 0xffffffffccc0: 0x0000ffffffffcd00 0x000000000040e6e8 sh`freejob: 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 0x40e6e8 <+140>: adrp x8, 38 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 sh`forkshell: 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 sh`evaltree: 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 0xffffffffced0: 0x0000ffffffffd160 0x0000000000406e28 sh`evalbackcmd: 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 0x406e28 <+340>: ldur w0, [x29, #-0x5c] 0xffffffffd160: 0x0000ffffffffd310 0x0000000000409324 sh`argstr: 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 0x409324 <+432>: mov x0, x26 0xffffffffd310: 0x0000ffffffffd370 0x0000000000408fa8 sh`expandarg: 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 0xffffffffd370: 0x0000ffffffffd5f0 0x0000000000407530 sh`exphere: 0x40752c <+212>: bl 0x408f38 ; expandarg at = expand.c:225 0x407530 <+216>: ldr x8, [x20] 0xffffffffd5f0: 0x0000ffffffffd630 0x00000000004073f0 sh`expredir: 0x4073ec <+112>: bl 0x407458 ; exphere at = eval.c:494 0x4073f0 <+116>: b 0x407428 ; <+172> at = eval.c:535 0xffffffffd630: 0x0000ffffffffd960 0x0000000000406154 sh`evalcommand: 0x406150 <+744>: bl 0x40737c ; expredir at = eval.c:532 0x406154 <+748>: ldur w27, [x29, #-0x68] 0xffffffffd960: 0x0000ffffffffda10 0x0000000000405570 sh`evaltree: 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 0x405574 <+216>: ldr x8, [x24, #0x8] 0xffffffffda10: 0x0000ffffffffdac0 0x00000000004056b4 sh`evaltree: 0x4056b0 <+532>: bl 0x40549c ; <+0> at = eval.c:193 0x4056b4 <+536>: ldr w8, [x19, #0x990] 0xffffffffdac0: 0x0000ffffffffdb70 0x0000000000405550 sh`evaltree: 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 0x405550 <+180>: ldr w8, [x22, #0x994] 0xffffffffdb70: 0x0000ffffffffdbf0 0x0000000000411034 sh`cmdloop: 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 0x411034 <+252>: mov w27, wzr 0xffffffffdbf0: 0x0000ffffffffdc50 0x0000000000410ea8 sh`main: 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 0x410ea8 <+660>: adrp x8, 36 0xffffffffdc50: 0x0000ffffffffdc90 0x0000000000402f30 sh`__start: 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit (_rtld is not in the core file) 0xffffffffdc90: 0x0000000000000000 0x0000000040434658 ld-elf.so.1`.rtld_start: 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 0x40434658 <+24>: mov x8, x0 Some of the most nested possibly had returned. But the forkshell / freejob general time frame seem to match everything that I've seen. [The details of the middle "eval*" related layers vary from what I can tell.] "register read" shows fp, lr, and pc majorly messed up. General Purpose Registers: x0 =3D 0x0000000000000000 x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc x2 =3D 0x0000000040a00000 x3 =3D 0x0000000000000002 x4 =3D 0x0000000000000096 x5 =3D 0x0000000040a5fd10 x6 =3D 0x0000000000434c28 sh..bss + 9448 x7 =3D 0x0000000000434c28 sh..bss + 9448 x8 =3D 0x0000000000000001 x9 =3D 0x0000000000000000 x10 =3D 0x0000000000000000 x11 =3D 0x0000000040a350c0 x12 =3D 0x0000000040a0e770 x13 =3D 0x0000000000000072 x14 =3D 0x000000000000006f x15 =3D 0x0000000000000010 x16 =3D 0x0000000000432340 =20 x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 x18 =3D 0x0000000000000000 x19 =3D 0x0000000000000000 x20 =3D 0x0000000000000000 x21 =3D 0x0000000000000001 x22 =3D 0x0000000040a5ff10 x23 =3D 0x0000ffffffffd190 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x0000000000434000 sh..bss + 6336 x26 =3D 0x0000ffffffffcd00 x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a6f5e0 fp =3D 0x0000000040a5fed8 lr =3D 0x0000000000000000 sp =3D 0x0000ffffffffcd60 pc =3D 0x0000000000000000 cpsr =3D 0x60000000 sp is also odd by being in the middle of the stack range for: 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 sh`forkshell: 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 sh`evaltree: 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 NOTE: The fork happened earlier in sh`forkshell and this is the child process that has the odd value. [It leaves me wondering if 0x0000ffffffffcd60 is a stack pointer value associated with a call to something earlier than the sh`forkshell call that is called by sh`forkshell .] Also: in the ones with only a small section of the junk areas the equivalent of: 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 is the largest addressed non-junk content in the area and the equivalent of: 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 would instead show zeros or "random" garbage values. In this case, however that range of the stack looks like: . . . 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 0xffffffffcd10: 0x0000ffffffffcd00 0x0000000000434000 0xffffffffcd20: 0x0000000000434000 0x0000ffffffffd190 0xffffffffcd30: 0x0000000040a5ff10 0x0000000000000001 0xffffffffcd40: 0x0000000000000000 0x0000000000000000 0xffffffffcd50: 0x0000000040a5fed8 0x0000000000000000 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 0xffffffffcd70: 0x0000000000000000 0x827a80ccb3228215 0xffffffffcd80: 0x0000000040a6f5c0 0x0000000000434000 0xffffffffcd90: 0x0000000000434000 0x0000000000434000 0xffffffffcda0: 0x0000000000434000 0x0000000000434000 0xffffffffcdb0: 0x0000000040a6f638 0x0000000000000000 0xffffffffcdc0: 0x0000000040a350c0 0x0000000000434000 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 0xffffffffcde0: 0x0000000000000003 0x0000000040a350c0 0xffffffffcdf0: 0x0000000040a6f5c0 0x0000000000434000 0xffffffffce00: 0x0000000000434000 0x0000000040a6f638 0xffffffffce10: 0x0000000000000000 0x0000000000434000 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 . . . Interestingly 0xffffffffcd60 reported for the sp looks like it has a frame-pointer/lr-value pair that does not fit with the overall call chain that ties together but is some fragment of a prior(?) call chain: 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 sh`evalcommand: 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub = for: _setjmp 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 It looks like it is a record from calling _setjmp in sh`evalcommand . (sh uses _setjmp/_longjmp via macros that turn into them for setjmp/longjmp references in sh's source code.) Interestingly (likely junk relative to the above): 0xffffffffcf90: 0x0000000000000000 0x0000000000432000 where: (lldb) dis -s 0x0000000000432000 sh`__frame_dummy_init_array_entry: 0x432000 <+0>: .long 0x00402fac ; unknown opcode 0x432004 <+4>: .long 0x00000000 ; unknown opcode (lldb) dis -s __frame_dummy_init_array_entry -c32 sh`frame_dummy: 0x402fac <+0>: adrp x8, 48 0x402fb0 <+4>: adrp x1, 48 0x402fb4 <+8>: ldr x8, [x8, #0x30] 0x402fb8 <+12>: ldr x1, [x1, #0x228] 0x402fbc <+16>: cmp x8, #0x0 ; =3D0x0=20 0x402fc0 <+20>: ccmp x1, #0x0, #0x4, ne 0x402fc4 <+24>: b.ne 0x402fcc ; <+32> 0x402fc8 <+28>: ret =20 0x402fcc <+32>: adrp x0, 48 0x402fd0 <+36>: add x0, x0, #0x30 ; =3D0x30=20 0x402fd4 <+40>: br x1 sh`lookupalias: . . . Ohter notes: Some examples of funcnest=3D=3D0 others have (e.g.) funcnest=3D=3D2. This one had funcnest=3D=3D0. commandname varies. In this case it was: (lldb) print commandname (char *) $74 =3D 0x0000ffffffffe210 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/configure" Other examples include: (lldb) print commandname (char *) $0 =3D 0x0000ffffffffdc40 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/fi= xincludes/configure" (lldb) print commandname (char *) $0 =3D 0x0000ffffffffe498 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/../config.sub" (lldb) print commandname (char *) $0 =3D 0x0000ffffffffe398 "../libtool" So far the forkshell/fork/freejob and associated materials always = seeming to be involved is all that I've found that is common (at least that is suggested by what I see so far) within the sh context. > Other notes: >=20 > As a personal investigation I've temporarily changed to using > something not fully generic but based on gic-400 specifics: >=20 > # svnlite diff /usr/src/sys/arm/arm/gic.c > Index: /usr/src/sys/arm/arm/gic.c > =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/src/sys/arm/arm/gic.c (revision 312982) > +++ /usr/src/sys/arm/arm/gic.c (working copy) > @@ -672,9 +672,13 @@ >=20 > if (irq >=3D sc->nirqs) { > #ifdef GIC_DEBUG_SPURIOUS > +#define EXPECTED_SPURIOUS_IRQ 1023 > + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { > device_printf(sc->gic_dev, > - "Spurious interrupt detected: last irq: %d on = CPU%d\n", > + "Spurious interrupt %d detected of %d: last irq: = %d on CPU%d\n", > + irq, sc->nirqs, > sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); > + } > #endif > return (FILTER_HANDLED); > } > @@ -720,6 +724,16 @@ > if (irq < sc->nirqs) > goto dispatch_irq; >=20 > + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { > +#undef EXPECTED_SPURIOUS_IRQ > +#ifdef GIC_DEBUG_SPURIOUS > + device_printf(sc->gic_dev, > + "Spurious end interrupt %d detected of %d: last = irq: %d on CPU%d\n", > + irq, sc->nirqs, > + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); > +#endif > + } > + > return (FILTER_HANDLED); > } >=20 >=20 > The result was no notices of Spurious interrupts have been generated: > All of the odd interrupts were the special 1023 value. >=20 > [As far as I could tell from the code the configuration is such that > 1022 should not be generated --and were not. 1020 and 1021 are > reserved and should not be generated.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Feb 7 10:44:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD6FBCD4072 for ; Tue, 7 Feb 2017 10:44:34 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96D531EB for ; Tue, 7 Feb 2017 10:44:34 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: by mail-pg0-x243.google.com with SMTP id 204so11830980pge.2 for ; Tue, 07 Feb 2017 02:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=yRAVZ9jYaZQ6TjP+7atlpFbyq5It69wgyGQUZtV64f8=; b=QnXc74gNhkrIzDETIXzn0N3CW3u8nKpyyGQl1jBFYwmEHa8IRty8uHG8O8cC0IyTCO SjWqOvl0x5ETVl0JYtVRISOenRXUQXiAN32xUg3VatqRoirzAXX1Lg3fitK7wisd5/NQ e5O6GNwV3RuFWxL2MnGkBAEqCm5VoE0bjUydMRtScUhok9uIZMADjCvVfcx6NgBunL/G hSP/BcscKUVBVcsPMGrBwFJ5pemW6uTy6CUK4xd4tV4mSKKJIO8TOSqRfhdQDb30GMHP F1YWaOOMwtSwNFV52r8is0qZjoDeyYx2AkidPJRrzxZxXbFU7/ZpjmR8qVmcle+fed3Z SqHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=yRAVZ9jYaZQ6TjP+7atlpFbyq5It69wgyGQUZtV64f8=; b=q+GW+yu27skBSopIpsexwI3HznZXbIHV3GyyiEQ/l8kVJAn13CgdldHYRccq6BuQSM VvHIu171fpFnVJdvOJ5lSyhicR1Nokpu4iWPEQFA168k1Sv0umhSRPPFq8J2NyG3IZGI +5BDIm+17EXLOlN++NvWRK01CaxvHwd3quNi4MjydNFkmR3MjhEUftfrLrsexYyDde6V 4P+cuPjqSqKRgu1vY47KGEN3vtfs4Gr4fZpbD/0WYB1kp50eyoekGx+MisbCdZtkpK25 TdBQhCYl5/Fpmqu/8Cbfd+ywvKpoLScdEeOmK2NdPnFmXiQSlxrP0QpB74PcgzV0Q8R5 MM+A== X-Gm-Message-State: AIkVDXLQGHiXeVY2d/kpBb/VdUG4uM72yzyy/oW/mxMbZU6h4XWTfiZbfzx5LWU+0Q01aw== X-Received: by 10.84.215.149 with SMTP id l21mr25220104pli.16.1486464273831; Tue, 07 Feb 2017 02:44:33 -0800 (PST) Received: from ?IPv6:2601:1c0:ce01:a5b7:f863:b02:c411:934f? ([2601:1c0:ce01:a5b7:f863:b02:c411:934f]) by smtp.gmail.com with ESMTPSA id c2sm10085866pfl.61.2017.02.07.02.44.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 02:44:33 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Tue, 7 Feb 2017 02:44:32 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> <7B5DF446-6740-43DE-823D-B6ECBECF0C32@dsl-only.net> <1B1EEC5E-9875-417F-9901-A66CB5885634@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: <1B1EEC5E-9875-417F-9901-A66CB5885634@dsl-only.net> Message-Id: <25B9EBC8-147F-47C2-BC40-C449EF3AC3FE@gmail.com> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 10:44:34 -0000 Another core. The register read reported: fp =3D 0x0000000000000000 lr =3D 0x0000000000000000 sp =3D 0x0000fffffffee630 pc =3D 0x0000000000000000 And looking around (most nested to outer most): 0xfffffffee530: 0x0000fffffffee570 0x000000004054cd94 libc.so.7`__free: 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 0x4054cd94 <+148>: adrp x9, 185 0xfffffffee570: 0x0000fffffffee590 0x0000000000411300 sh`ckfree: 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free 0x411300 <+32>: ldr x8, [x19, #0x970] 0xfffffffee590: 0x0000fffffffee5d0 0x000000000040e6e8 sh`freejob: 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 0x40e6e8 <+140>: adrp x8, 38 0xfffffffee5d0: 0x0000ffffffffcaa0 0x000000000040f490 sh`forkshell: 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30 (Note that sp=3D=3D0x0000fffffffee630 is fairly close to = 0xfffffffee5d0.) (sizable frame jump from 0xfffffffee5d0 to 0x0000ffffffffcaa0, size = 0xE4D0=3D=3D58576 bytes) (0xfffffffee5e0 up to 0xffffffffa890 (not inclusive) are all = 0x0000000000000000) (The prior trace example did not have such a large area.) 0xffffffffca50: 0x0000ffffffffcaa0 0x000000000040f1c8 sh`forkshell: 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork 0x40f1cc <+152>: mov w19, w0 (flushall a voids returning to 0x40f1c8 directly, instead making the last routine it calls return there instead of to flushall.) 0xffffffffcaa0: 0x0000ffffffffcb50 0x0000000000405954 sh`evaltree: 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 0xffffffffcb50: 0x0000ffffffffcde0 0x0000000000406e28 sh`evalbackcmd: 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 0x406e28 <+340>: ldur w0, [x29, #-0x5c] 0xffffffffcde0: 0x0000ffffffffcf90 0x0000000000409324 sh`argstr: 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 0x409324 <+432>: mov x0, x26 0xffffffffcf90: 0x0000ffffffffcff0 0x0000000000408fa8 sh`expandarg: 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 0xffffffffcff0: 0x0000ffffffffd320 0x0000000000405f48 sh`evalcommand: 0x405f44 <+220>: bl 0x408f38 ; expandarg at = expand.c:225 0x405f48 <+224>: ldr x24, [x24, #0x8] 0xffffffffd0f0: 0x0000ffffffffd320 0x00000000004068e4 sh`evalcommand: 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub = for: _setjmp 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 0xffffffffd320: 0x0000ffffffffd3d0 0x0000000000405570 sh`evaltree: 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 0x405574 <+216>: ldr x8, [x24, #0x8] 0xffffffffd3d0: 0x0000ffffffffd480 0x0000000000405550 sh`cmdloop: 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 0x411034 <+252>: mov w27, wzr 0xffffffffd480: 0x0000ffffffffd7b0 0x00000000004067d0 sh`evalcommand: 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 0x4067d0 <+2408>: ldr x8, [x24, #0x970] 0xffffffffd7b0: 0x0000ffffffffd860 0x0000000000405570 sh`evaltree: 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 0x405574 <+216>: ldr x8, [x24, #0x8] 0xffffffffd860: 0x0000ffffffffd910 0x0000000000405550 sh`evaltree: 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 0x405550 <+180>: ldr w8, [x22, #0x994] 0xffffffffd910: 0x0000ffffffffdc40 0x00000000004067d0 sh`evalcommand: 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 0x4067d0 <+2408>: ldr x8, [x24, #0x970] 0xffffffffda10: 0x0000ffffffffdc40 0x000000000040673c sh`evalcommand: 0x406738 <+2256>: bl 0x402be0 ; symbol stub = for: _setjmp 0x40673c <+2260>: cbnz w0, 0x406c60 ; <+3576> at = eval.c:1042 0xffffffffdc40: 0x0000ffffffffdcf0 0x0000000000405570 sh`evaltree: 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 0x405574 <+216>: ldr x8, [x24, #0x8] 0xffffffffdcf0: 0x0000ffffffffdd70 0x0000000000411034 sh`cmdloop: 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 0x411034 <+252>: mov w27, wzr 0xffffffffdd70: 0x0000ffffffffddd0 0x0000000000410ea8 sh`main: 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 0x410ea8 <+660>: adrp x8, 36 0xffffffffddd0: 0x0000ffffffffde10 0x0000000000402f30 sh`__start: 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit (_rtld is not in the core file) 0xffffffffde10: 0x0000000000000000 0x0000000040434658 ld-elf.so.1`.rtld_start: 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 0x40434658 <+24>: mov x8, x0 So again the problem is associated with the forkshell/fork/freejob related materials. (I mistakenly left out the evalcommand/_setjmp material when I made the trace in the below. The same for flushall. I've inserted some of that below, at least for the flushall context.) On 2017-Feb-6, at 8:05 PM, Mark Millard wrote: > [I got a lucky sh core dump with more stack context/content > available to look at for an example sh crash. This helps > narrow things down.] >=20 > On 2017-Feb-5, at 1:12 AM, Mark Millard = wrote: >=20 >> [Top post of a new result.] >>=20 >> Using lldb to look at the memory for the stack around >> sh failure points has some apparently fixed structure. >> Example: >>=20 >> . . . junk values . . . >> 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 >> 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 >> 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 >> 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 >> 0xffffffffe520: 0x0000000000000000 0x0000000000000000 >> 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 >> 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe550: 0x0000000000434000 0x000000000000000f >> 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 >> 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e >> 0xffffffffe580: 0x0000000000000001 0x0000000000000005 >> 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >> . . . junk values . . . >=20 > I got lucky and got a core dump that did not have the junk > areas and could trace the stack's frame pointer chain > between main and libc.so.7`__free (through freejob along > the way). See later. >=20 >> where "register read" showed: >>=20 >> sp =3D 0x0000ffffffffe600 >>=20 >> (The distance and direction to the last non-junk line >> from the reported sp in each example is the same.) >> Looking around that 0x000000000040f490: >>=20 >> 0x40f48c: 0x97fffc74 bl 0x40e65c ; freejob = at jobs.c:463 >> 0x40f490: 0x9100c294 add x20, x20, #0x30 ; =3D0x30=20= >>=20 >> It is the same address and code in each case. >=20 > I should have originally noted that 0x40f48c is in > forkshell, along the child process code-path: >=20 > pid_t > forkshell(struct job *jp, union node *n, int mode) > { > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > INTOFF; > if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) > checkzombies(); > flushall(); > pid =3D fork(); > if (pid =3D=3D -1) { > TRACE(("Fork failed, errno=3D%d\n", errno)); > INTON; > error("Cannot fork: %s", strerror(errno)); > } > if (pid =3D=3D 0) { > struct job *p; > int wasroot; > int i; >=20 > TRACE(("Child shell %d\n", (int)getpid())); > wasroot =3D rootshell; > rootshell =3D 0; > handler =3D &main_handler; > closescript(); > INTON; > forcelocal =3D 0; > clear_traps(); > #if JOBS > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > #else > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > #endif > INTOFF; > for (i =3D njobs, p =3D jobtab ; --i >=3D 0 ; p++) > if (p->used) > freejob(p); > INTON; > if (wasroot && iflag) { > setsignal(SIGINT); > setsignal(SIGQUIT); > setsignal(SIGTERM); > } > return pid; > } > . . . (see /usr/src/bin/sh/jobs.c for this) . . . >=20 >> Sometimes the junk values are all zeros over sizable >> distances. Sometimes the sizable areas seem to have >> random data. >>=20 >> /usr/src/bin/sh/jobs.c 's freejobs is: >>=20 >> static void >> freejob(struct job *jp) >> { >> struct procstat *ps; >> int i; >>=20 >> INTOFF; >> if (bgjob =3D=3D jp) >> bgjob =3D NULL; >> for (i =3D jp->nprocs, ps =3D jp->ps ; --i >=3D 0 ; ps++) { >> if (ps->cmd !=3D nullstr) >> ckfree(ps->cmd); >> } >> if (jp->ps !=3D &jp->ps0) >> ckfree(jp->ps); >> jp->used =3D 0; >> #if JOBS >> deljob(jp); >> #endif >> INTON; >> } >>=20 >> /usr/src/bin/sh/error.h defines INTOFF and INTON: >>=20 >> #define EXINT 0 /* SIGINT received */ >> #define EXERROR 1 /* a generic error */ >> #define EXEXEC 2 /* command execution failed */ >> #define EXEXIT 3 /* call exitshell(exitstatus) */ >>=20 >> . . . >>=20 >> extern struct jmploc *handler; >> extern volatile sig_atomic_t exception; >>=20 >> . . . >>=20 >> extern volatile sig_atomic_t suppressint; >> extern volatile sig_atomic_t intpending; >>=20 >> #define INTOFF suppressint++ >> #define INTON { if (--suppressint =3D=3D 0 && intpending) onint(); } >> #define is_int_on() suppressint >> #define SETINTON(s) suppressint =3D (s) >> #define FORCEINTON {suppressint =3D 0; if (intpending) onint();} >> #define SET_PENDING_INT intpending =3D 1 >> #define CLEAR_PENDING_INT intpending =3D 0 >> #define int_pending() intpending >>=20 >> void exraise(int) __dead2; >> void onint(void) __dead2; >>=20 >> /usr/src/bin/sh/error.c hAS: >>=20 >> void >> exraise(int e) >> { >> INTOFF; >> if (handler =3D=3D NULL) >> abort(); >> exception =3D e; >> longjmp(handler->loc, 1); >> } >> . . . >> void >> onint(void) >> { >> sigset_t sigs; >>=20 >> intpending =3D 0; >> sigemptyset(&sigs); >> sigprocmask(SIG_SETMASK, &sigs, NULL); >>=20 >> /* >> * This doesn't seem to be needed, since main() emits a = newline. >> */ >> #if 0 >> if (tcgetpgrp(0) =3D=3D getpid()) >> write(STDERR_FILENO, "\n", 1); >> #endif >> if (rootshell && iflag) >> exraise(EXINT); >> else { >> signal(SIGINT, SIG_DFL); >> kill(getpid(), SIGINT); >> _exit(128 + SIGINT); >> } >> } >>=20 >> # grep setjmp /usr/src/bin/sh/* >> /usr/src/bin/sh/TOUR:so I implement it using setjmp and longjmp. The = global variable >> /usr/src/bin/sh/error.h:#include >> /usr/src/bin/sh/error.h: * BSD setjmp saves the signal mask, which = violates ANSI C and takes time, >> /usr/src/bin/sh/error.h: * so we use _setjmp instead. >> /usr/src/bin/sh/error.h:#define setjmp(jmploc) _setjmp(jmploc) >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/histedit.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/jobs.c: if (setjmp(jmploc.loc)) >> /usr/src/bin/sh/main.c: * commands. The setjmp call sets up the = location to jump to when an >> /usr/src/bin/sh/main.c: if (setjmp(main_handler.loc)) { >> /usr/src/bin/sh/parser.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/parser.c: if (!setjmp(jmploc.loc)) { >> /usr/src/bin/sh/trap.c: if (!setjmp(loc1.loc)) { >> /usr/src/bin/sh/trap.c: if (!setjmp(loc2.loc)) { >> /usr/src/bin/sh/var.c: if (setjmp(jmploc.loc)) >=20 > Here is the call chain that I was able to trace > in the newer core dump: > (most nested first to least nested last; > showing frame pointer and lr value pairs > and calls/return-places) >=20 > (ifree is not in the core file) > 0xffffffffcc60: 0x0000ffffffffcca0 0x000000004054cd94 > libc.so.7`__free: > 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 > 0x4054cd94 <+148>: adrp x9, 185 > 0xffffffffcca0: 0x0000ffffffffccc0 0x0000000000411300 > sh`ckfree: > 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free > 0x411300 <+32>: ldr x8, [x19, #0x970] > 0xffffffffccc0: 0x0000ffffffffcd00 0x000000000040e6e8 > sh`freejob: > 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 > 0x40e6e8 <+140>: adrp x8, 38 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 sh`forkshell: 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork 0x40f1cc <+152>: mov w19, w0 (flushall a voids returning to 0x40f1c8 directly, instead making the last routine it calls return there instead of to flushall.) > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 > 0xffffffffced0: 0x0000ffffffffd160 0x0000000000406e28 > sh`evalbackcmd: > 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 > 0x406e28 <+340>: ldur w0, [x29, #-0x5c]0xffffffffcd60: = 0x0000ffffffffcf90 0x00000000004068e4 > 0xffffffffd160: 0x0000ffffffffd310 0x0000000000409324 > sh`argstr: > 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 > 0x409324 <+432>: mov x0, x26 > 0xffffffffd310: 0x0000ffffffffd370 0x0000000000408fa8 > sh`expandarg: > 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 > 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 > 0xffffffffd370: 0x0000ffffffffd5f0 0x0000000000407530 > sh`exphere: > 0x40752c <+212>: bl 0x408f38 ; expandarg at = expand.c:225 > 0x407530 <+216>: ldr x8, [x20] > 0xffffffffd5f0: 0x0000ffffffffd630 0x00000000004073f0 > sh`expredir: > 0x4073ec <+112>: bl 0x407458 ; exphere at = eval.c:494 > 0x4073f0 <+116>: b 0x407428 ; <+172> at = eval.c:535 > 0xffffffffd630: 0x0000ffffffffd960 0x0000000000406154 > sh`evalcommand: > 0x406150 <+744>: bl 0x40737c ; expredir at = eval.c:532 > 0x406154 <+748>: ldur w27, [x29, #-0x68] > 0xffffffffd960: 0x0000ffffffffda10 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffda10: 0x0000ffffffffdac0 0x00000000004056b4 > sh`evaltree: > 0x4056b0 <+532>: bl 0x40549c ; <+0> at = eval.c:193 > 0x4056b4 <+536>: ldr w8, [x19, #0x990] > 0xffffffffdac0: 0x0000ffffffffdb70 0x0000000000405550 > sh`evaltree: > 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 > 0x405550 <+180>: ldr w8, [x22, #0x994] > 0xffffffffdb70: 0x0000ffffffffdbf0 0x0000000000411034 > sh`cmdloop: > 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 > 0x411034 <+252>: mov w27, wzr > 0xffffffffdbf0: 0x0000ffffffffdc50 0x0000000000410ea8 > sh`main: > 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 > 0x410ea8 <+660>: adrp x8, 36 > 0xffffffffdc50: 0x0000ffffffffdc90 0x0000000000402f30 > sh`__start: > 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 > 0x402f30 <+360>: bl 0x402ae0 ; symbol stub = for: exit >=20 > (_rtld is not in the core file) > 0xffffffffdc90: 0x0000000000000000 0x0000000040434658 > ld-elf.so.1`.rtld_start: > 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 > 0x40434658 <+24>: mov x8, x0 >=20 > Some of the most nested possibly had returned. But the > forkshell / freejob general time frame seem to match > everything that I've seen. >=20 > [The details of the middle "eval*" related layers vary > from what I can tell.] >=20 > "register read" shows fp, lr, and pc majorly > messed up. >=20 > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc > x2 =3D 0x0000000040a00000 > x3 =3D 0x0000000000000002 > x4 =3D 0x0000000000000096 > x5 =3D 0x0000000040a5fd10 > x6 =3D 0x0000000000434c28 sh..bss + 9448 > x7 =3D 0x0000000000434c28 sh..bss + 9448 > x8 =3D 0x0000000000000001 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000000000 > x11 =3D 0x0000000040a350c0 > x12 =3D 0x0000000040a0e770 > x13 =3D 0x0000000000000072 > x14 =3D 0x000000000000006f > x15 =3D 0x0000000000000010 > x16 =3D 0x0000000000432340 =20 > x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 > x18 =3D 0x0000000000000000 > x19 =3D 0x0000000000000000 > x20 =3D 0x0000000000000000 > x21 =3D 0x0000000000000001 > x22 =3D 0x0000000040a5ff10 > x23 =3D 0x0000ffffffffd190 > x24 =3D 0x0000000000434000 sh..bss + 6336 > x25 =3D 0x0000000000434000 sh..bss + 6336 > x26 =3D 0x0000ffffffffcd00 > x27 =3D 0x0000000000434000 sh..bss + 6336 > x28 =3D 0x0000000040a6f5e0 > fp =3D 0x0000000040a5fed8 > lr =3D 0x0000000000000000 > sp =3D 0x0000ffffffffcd60 > pc =3D 0x0000000000000000 > cpsr =3D 0x60000000 >=20 > sp is also odd by being in the middle of the stack range > for: >=20 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 >=20 > NOTE: The fork happened earlier in sh`forkshell and this > is the child process that has the odd value. >=20 > [It leaves me wondering if 0x0000ffffffffcd60 is a stack > pointer value associated with a call to something > earlier than the sh`forkshell call that is called by > sh`forkshell .] >=20 > Also: in the ones with only a small section of the junk > areas the equivalent of: >=20 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 >=20 > is the largest addressed non-junk content in the area > and the equivalent of: >=20 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 >=20 > would instead show zeros or "random" garbage values. >=20 > In this case, however that range of the stack looks like: >=20 > . . . > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > 0xffffffffcd10: 0x0000ffffffffcd00 0x0000000000434000 > 0xffffffffcd20: 0x0000000000434000 0x0000ffffffffd190 > 0xffffffffcd30: 0x0000000040a5ff10 0x0000000000000001 > 0xffffffffcd40: 0x0000000000000000 0x0000000000000000 > 0xffffffffcd50: 0x0000000040a5fed8 0x0000000000000000 > 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 > 0xffffffffcd70: 0x0000000000000000 0x827a80ccb3228215 > 0xffffffffcd80: 0x0000000040a6f5c0 0x0000000000434000 > 0xffffffffcd90: 0x0000000000434000 0x0000000000434000 > 0xffffffffcda0: 0x0000000000434000 0x0000000000434000 > 0xffffffffcdb0: 0x0000000040a6f638 0x0000000000000000 > 0xffffffffcdc0: 0x0000000040a350c0 0x0000000000434000 > 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 > 0xffffffffcde0: 0x0000000000000003 0x0000000040a350c0 > 0xffffffffcdf0: 0x0000000040a6f5c0 0x0000000000434000 > 0xffffffffce00: 0x0000000000434000 0x0000000040a6f638 > 0xffffffffce10: 0x0000000000000000 0x0000000000434000 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > . . . >=20 > Interestingly 0xffffffffcd60 reported for the sp looks > like it has a frame-pointer/lr-value pair that does not > fit with the overall call chain that ties together but > is some fragment of a prior(?) call chain: >=20 > 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 > sh`evalcommand: > 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub = for: _setjmp > 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 >=20 > It looks like it is a record from calling _setjmp in > sh`evalcommand . >=20 > (sh uses _setjmp/_longjmp via macros that turn > into them for setjmp/longjmp references in > sh's source code.) >=20 > Interestingly (likely junk relative to the above): >=20 > 0xffffffffcf90: 0x0000000000000000 0x0000000000432000 >=20 > where: >=20 > (lldb) dis -s 0x0000000000432000 > sh`__frame_dummy_init_array_entry: > 0x432000 <+0>: .long 0x00402fac ; unknown opcode > 0x432004 <+4>: .long 0x00000000 ; unknown opcode > (lldb) dis -s __frame_dummy_init_array_entry -c32 > sh`frame_dummy: > 0x402fac <+0>: adrp x8, 48 > 0x402fb0 <+4>: adrp x1, 48 > 0x402fb4 <+8>: ldr x8, [x8, #0x30] > 0x402fb8 <+12>: ldr x1, [x1, #0x228] > 0x402fbc <+16>: cmp x8, #0x0 ; =3D0x0=20 > 0x402fc0 <+20>: ccmp x1, #0x0, #0x4, ne > 0x402fc4 <+24>: b.ne 0x402fcc ; <+32> > 0x402fc8 <+28>: ret =20 > 0x402fcc <+32>: adrp x0, 48 > 0x402fd0 <+36>: add x0, x0, #0x30 ; =3D0x30=20 > 0x402fd4 <+40>: br x1 >=20 > sh`lookupalias: > . . . >=20 >=20 > Ohter notes: >=20 > Some examples of funcnest=3D=3D0 others have (e.g.) funcnest=3D=3D2. > This one had funcnest=3D=3D0. >=20 > commandname varies. In this case it was: >=20 > (lldb) print commandname > (char *) $74 =3D 0x0000ffffffffe210 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/configure" >=20 > Other examples include: >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffdc40 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/fi= xincludes/configure" >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffe498 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/../config.sub" >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffe398 "../libtool" >=20 >=20 > So far the forkshell/fork/freejob and associated materials always = seeming > to be involved is all that I've found that is common (at least that is > suggested by what I see so far) within the sh context. >=20 >> Other notes: >>=20 >> As a personal investigation I've temporarily changed to using >> something not fully generic but based on gic-400 specifics: >>=20 >> # svnlite diff /usr/src/sys/arm/arm/gic.c >> Index: /usr/src/sys/arm/arm/gic.c >> =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/src/sys/arm/arm/gic.c (revision 312982) >> +++ /usr/src/sys/arm/arm/gic.c (working copy) >> @@ -672,9 +672,13 @@ >>=20 >> if (irq >=3D sc->nirqs) { >> #ifdef GIC_DEBUG_SPURIOUS >> +#define EXPECTED_SPURIOUS_IRQ 1023 >> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >> device_printf(sc->gic_dev, >> - "Spurious interrupt detected: last irq: %d on = CPU%d\n", >> + "Spurious interrupt %d detected of %d: last irq: = %d on CPU%d\n", >> + irq, sc->nirqs, >> sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >> + } >> #endif >> return (FILTER_HANDLED); >> } >> @@ -720,6 +724,16 @@ >> if (irq < sc->nirqs) >> goto dispatch_irq; >>=20 >> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >> +#undef EXPECTED_SPURIOUS_IRQ >> +#ifdef GIC_DEBUG_SPURIOUS >> + device_printf(sc->gic_dev, >> + "Spurious end interrupt %d detected of %d: last = irq: %d on CPU%d\n", >> + irq, sc->nirqs, >> + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >> +#endif >> + } >> + >> return (FILTER_HANDLED); >> } >>=20 >>=20 >> The result was no notices of Spurious interrupts have been generated: >> All of the odd interrupts were the special 1023 value. >>=20 >> [As far as I could tell from the code the configuration is such that >> 1022 should not be generated --and were not. 1020 and 1021 are >> reserved and should not be generated.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Feb 7 14:46:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A3DCCD4405 for ; Tue, 7 Feb 2017 14:46:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1F43C19C1 for ; Tue, 7 Feb 2017 14:46:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id C2BC3186689 for ; Tue, 7 Feb 2017 08:46:31 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Crochet produces boom-boom build Message-ID: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> Date: Tue, 7 Feb 2017 08:46:08 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080000020705060709080500" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:46:33 -0000 This is a cryptographically signed message in MIME format. --------------ms080000020705060709080500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Crochet, checked out -HEAD from yesterday, attempting to boot the Pi3 with what it produces I get this: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console Command line arguments: loader.efi Image base: 0x379b8008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Tue Feb 7 07:03:47 CST 2017 freebsd@NewFS.denninger.net) Failed to start image provided by UFS (14) "Synchronous Abort" handler, esr 0x96000004 ELR: 3af62cec LR: 3af61d60 x0 : 0000000000000001 x1 : 0000000000000001 x2 : 000000003afeb000 x3 : 000000000000003f x4 : 0000000000000020 x5 : 0000000000000010 x6 : 0000000000000000 x7 : 0000000039b260a4 x8 : 000000003af61d48 x9 : 000000000000000d x10: 0000000000000030 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000002 x14: 0000000000000000 x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 x18: 000000003ab30df8 x19: 0000000037a16008 x20: 0000000000000000 x21: 0000000000000000 x22: 0000000039b28000 x23: 0000000039b1d49c x24: 0000000039b28850 x25: 000000003ab3d740 x26: 000000003af839a0 x27: 0000000039b2e3e8 x28: 0000000000000000 x29: 000000003ab2ef60 Resetting CPU ... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080000020705060709080500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDcxNDQ2MDhaME8GCSqGSIb3DQEJBDFCBEA2ynBo ikPAakgVhkGlkl0QqwioSKzsJxc/CwQ5nsSxcgmNYjWi4mldMLv7YcO2c2LNI+dtfZ8dr8rL 7ASVpZUHMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAzGx0ISqTIVix QY9mfF0NuRng5JT4xc4UmmiU2gZ+9r3J5sRACJV81X7PsKNYHKyKobUPA5OvEDyMBlkmABXD XXnwm8hMF4sZwU6DaBSAI9eEg+PYWgo79FN/E+AcPSqc6NJ+pxU59qkMoEXc/TuPlBBgYBYp GB9y4al40e0hjKev4uR0432DOJQtz3Qs9fra0msegQucKn6agjFnuLZqjfs8seklvtHY+lTz rkmlCxrpQGWNKOoFIfxY8BZ2ojSP23Rq5deP1LF0SnOL4BW7xQvquO9beh1edph5iDGJw+k+ BVMqhOjPEoI/QuevrvqIlQ3rzgGwYOGkW+c52rffP4q8MH+CN6wd/Cn99Zgf/Xblihxhikql YWWd61kJE09D84hs40eC/7/a1cbwJZy2wMgYfddtYPrt8bFRPjZPYKLfmn+jCtLlaqhvwCvw 7MWr2g98MS7aBPvOWdKcsnu8omd2tveACzlOn7dbjHG0vwbAYxZmx3EpRGKKDbTmJCewYi1e 9bU131zJnHQVFSpYUk7UmIMQQAvf+Pas/aeig2PsPmh4UE38GDPXBWI0xZdal8WsvV9IRJxR Rspwi8gUHildbHW4ZOY5KBKR4/BYkhWw2bNrDehh9RYDpVm489uL0Fa6TBX8b9Mznj9a7vRG 8f+ywNZQMSNjJmFfwyabelIAAAAAAAA= --------------ms080000020705060709080500-- From owner-freebsd-arm@freebsd.org Tue Feb 7 14:58:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12856CD4956 for ; Tue, 7 Feb 2017 14:58:19 +0000 (UTC) (envelope-from utecolshorn@kabelmail.de) Received: from smtp-out01.xworks.net (smtp-out01.xworks.net [31.25.48.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtpa1.mediabeam.com", Issuer "smtpa1.mediabeam.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC6F41AE for ; Tue, 7 Feb 2017 14:58:17 +0000 (UTC) (envelope-from utecolshorn@kabelmail.de) Received: from mailbackend1 (cluster06.xworks.net [10.100.1.80]) by smtp-out01.xworks.net (Postfix) with ESMTP id 73C1C612DD; Tue, 7 Feb 2017 15:50:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kabelmail.de; s=mail; t=1486479055; bh=TCjRxEQZMbBVLBOsop+8c6VqGAn7xrCXFcv/ehcNzN8=; h=From:To:Subject:Date:MIME-Version:Content-Type; b=srNuhFfS1tOj4xz1C7vxv7k80tBlMkCGeAyFsbBwNAW2JsBYpIzMarIgsPr+UbtPh DrI16XIWSLMgi9BTVaxgLjEZj21PBz+oyUkpedFaBFGG6rufUoisN/IbMw4VSkMp0g 604xMq+oIFEmqAAFBI8I0xQb5RQybRqj/MK6K3gE= Received: from MonsterPC (ip25055156.dynamic.kabel-deutschland.de [37.5.81.86]) (authenticated bits=0) by smtpa.mediabeam.com with ESMTP id v17Eol94011816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2017 15:50:51 +0100 X-mediaBEAM-Originating-IP: [37.5.81.86] X-mediaBEAM-AUTHID: [utecolshorn@kabelmail.de] From: "Ute Colshorn" To: , Subject: =?utf-8?Q?WG:_Tuesdays_Probe_f=C3=A4llt_aus?= Date: Tue, 7 Feb 2017 15:50:43 +0100 Message-ID: <000f01d28151$92f54f90$b8dfeeb0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdKBOccQdj4QLuY9Qh+1EgEXhEZ/VwAFy5ZA Content-Language: de X-mediaBEAM-AuthCheck: route13 X-mediaBEAM-AuthScore: 0.0/5.0, scanned in 0.905sec X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:58:19 -0000 Hi Matthias,=20 erreiche dich leider nicht telefonisch - kannst d u heute die Probe = =C3=BCbernehmen oder sagen wir ab?? Liebe Gr=C3=BC=C3=9Fe + auf bald Ute 05064 85791 -----Urspr=C3=BCngliche Nachricht----- Von: Julia Sch=C3=B6nleiter [mailto:juliaschoenleiter@me.com]=20 Gesendet: Dienstag, 7. Februar 2017 13:00 An: Reyelt Matthias; Kaune Claudia; Mirja Kaune; Ute Colshorn; Remmers = Melanie Betreff: Tuesdays Probe f=C3=A4llt aus Lieber Vorstand, ich muss die Probe heute absagen. Und schreibe auch gerne an den ganzen = Chor. Mich hat leider jetzt die n=C3=A4chste Krankheitswelle (Grippe) = erreicht und ich habe leider keinen Ersatz f=C3=BCr heute Abend = gefunden. Im Moment ist es mir zuviel, aber ich schaue, wenn ich wieder gesund = bin, gerne nach einem Ersatztermin. Wollt ihr dem Chor absagen? Lieben Gruss, Julia ----- E-Mail ist virenfrei. Von AVG =C3=BCberpr=C3=BCft - www.avg.com Version: 2016.0.7998 / Virendatenbank: 4756/13903 - Ausgabedatum: = 06.02.2017=20 From owner-freebsd-arm@freebsd.org Tue Feb 7 17:10:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D0C9CD5291 for ; Tue, 7 Feb 2017 17:10:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id BB8A1891 for ; Tue, 7 Feb 2017 17:10:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 7F2C0186C67 for ; Tue, 7 Feb 2017 11:10:32 -0600 (CST) Subject: Re: Crochet produces boom-boom build To: freebsd-arm@freebsd.org References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> From: Karl Denninger Message-ID: Date: Tue, 7 Feb 2017 11:10:32 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050805010001050806050400" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:10:34 -0000 This is a cryptographically signed message in MIME format. --------------ms050805010001050806050400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/7/2017 08:46, Karl Denninger wrote: > Crochet, checked out -HEAD from yesterday, attempting to boot the Pi3 > with what it produces I get this: > >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: ZFS UFS > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console > Command line arguments: loader.efi > Image base: 0x379b8008 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Tue Feb 7 07:03:47 CST 2017 freebsd@NewFS.denninger.net) > Failed to start image provided by UFS (14) > "Synchronous Abort" handler, esr 0x96000004 > ELR: 3af62cec > LR: 3af61d60 > x0 : 0000000000000001 x1 : 0000000000000001 > x2 : 000000003afeb000 x3 : 000000000000003f > x4 : 0000000000000020 x5 : 0000000000000010 > x6 : 0000000000000000 x7 : 0000000039b260a4 > x8 : 000000003af61d48 x9 : 000000000000000d > x10: 0000000000000030 x11: 0000000000000000 > x12: 0000000000000000 x13: 0000000000000002 > x14: 0000000000000000 x15: 0000000000000000 > x16: 0000000000000000 x17: 0000000000000000 > x18: 000000003ab30df8 x19: 0000000037a16008 > x20: 0000000000000000 x21: 0000000000000000 > x22: 0000000039b28000 x23: 0000000039b1d49c > x24: 0000000039b28850 x25: 000000003ab3d740 > x26: 000000003af839a0 x27: 0000000039b2e3e8 > x28: 0000000000000000 x29: 000000003ab2ef60 > > Resetting CPU ... > Update..... I took Brad's image, grabbed /boot/loader.efi from that, replaced the copy that Crochet built with it, and what I get it boots but SMP is screwed up and it winds up with an I/O problem and panics. Here's the full boot sequence (with /boot/loader.efi replaced): RPi3 PSCI monitor installed U-Boot 2017.01 (Feb 06 2017 - 15:53:30 -0600) DRAM: 944 MiB RPI 3 Model B (0xa22082) MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 81472 bytes read in 28 ms (2.8 MiB/s) ## Starting EFI application at 01000000 ... Scanning disks on usb... Scanning disks on mmc... Adding logical partition Adding logical partition MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 7 disks >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console Command line arguments: loader.efi Image base: 0x379b9008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Feb 2 16:16:49 MST 2017 raspberry@hive.raspbsd.org) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel data=3D0x81ca88+0x43afc0 syms=3D[0x8+0x104970+0x8+0xb= e160] /boot/kernel/geom_label.ko text=3D0x5d40 data=3D0xe90+0x8 syms=3D[0x8+0x1638+0x8+0xbe8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x8004000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 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 12.0-CURRENT #0 r313389: Tue Feb 7 10:13:16 CST 2017 =20 freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm64.aarch64/pics/Cro= ssBuild-12/src/sys/GENERIC arm64 =46reeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. can't re-use a leaf (geom_label)! module_register: cannot register g_label from kernel; already loaded from geom_label.ko Module g_label failed to register: 17 Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 ofw_clkbus0: on ofwbus0 clk_fixed0: on ofw_clkbus0 clk_fixed1: on ofw_clkbus0 clk_fixed2: on ofw_clkbus0 clk_fixed3: on ofw_clkbus0 clk_fixed4: on ofw_clkbus0 clk_fixed5: on ofw_clkbus0 clk_fixed6: on ofw_clkbus0 psci0: on ofwbus0 local_intc0: mem 0x40000000-0x400000ff on simplebus0 intc0: mem 0x7e00b200-0x7e00b3ff irq 16 on simplebus0 generic_timer0: irq 37,38,39,40 on simplebus0 Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 bcm_dma0: mem 0x7e007000-0x7e007eff irq 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 on simplebus0 mbox0: mem 0x7e00b880-0x7e00b8bf irq 17 on simplebus0 bcmwd0: mem 0x7e100000-0x7e100027 on simplebus0 gpio0: mem 0x7e200000-0x7e2000b3 irq 18,19 on simplebus0 gpiobus0: on gpio0 gpioc0: on gpio0 uart0: mem 0x7e201000-0x7e201fff irq 20 on simplebus0 uart0: console (115200,n,8,1) spi0: mem 0x7e204000-0x7e204fff irq 22 on simplebus0 spibus0: on spi0 spibus0: at cs 0 mode 0 spibus0: at cs 1 mode 0 sdhci_bcm0: mem 0x7e300000-0x7e3000ff irq 27 on simplebus0 mmc0: on sdhci_bcm0 iichb0: mem 0x7e804000-0x7e804fff irq 31 on simplebus0 iicbus0: on iichb0 bcm283x_dwcotg0: mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 33,34 on simplebus0 usbus0 on bcm283x_dwcotg0 gpioled0: on simplebus0 gpioled0: failed to map pin fb0: on simplebus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x3db33000, screen_size 818688 pmu0: irq 36 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cryptosoft0: Timecounters tick every 1.000 msec The GEOM class LABEL is already loaded. usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 32GB at mmc0 41.6MHz/4bit/65535-block bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF Release APs APs not started CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k Granule,MixedEndian,S/N= S Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... uhub0: 1 port with 1 removable, self powered warning: no time-of-day clock registered, system time will not be set accurately Growing root partition to fill device ugen0.2: at usbus0 uhub1 on uhub0 uhub1: on usbus0 uhub1: MTT enabled GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them. mmcsd0s2 resized mmcsd0s2a resized super-block backups (for fsck_ffs -b #) at: 3802304, 4752832, 5703360, 6653888, 7604416, 8554944, 9505472, 10456000,= 11406528, 12357056, 13307584, 14258112, 15208640, 16159168, 17109696, 18060224, 19010752, 19961280, 20911808, 21862336, 22812864, 23763392, 24713920, 25664448, 26614976,uhub1: 5 ports with 4 removable, self power= ed 27565504, 28516032, 29466560, 30417088, 31367616, 32318144, 33268672, 34219200, 35169728, 36120256, 37070784, 38021312, 38971840, 39922368, 40872896, 41823424, 42773952, 43724480, 44675008, 45625536, 46576064, 47526592, 48477120, 49427648, 50378176, 51328704, 52279232, 53229760, 54180288, 55130816, 56081344, 57031872, 57982400, 58932928, 59883456, 60833984, 61784512 ugen0.3: at usbus0 smsc0 on uhub1 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 smscphy0: PHY 1 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:4e:88:64 Setting hostuuid: 30303030-3030-3030-3331-346538383634. Setting hostid: 0x968824d5. No suitable dump device was found. Starting file system checks: /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s2a: clean, 7272066 free (274 frags, 908974 blocks, 0.0% fragmentation) lock order reversal: 1st 0xffff000053248208 bufwait (bufwait) @ /pics/CrossBuild-12/src/sys/kern/vfs_bio.c:3500 2nd 0xfffffd0001559600 dirhash (dirhash) @ /pics/CrossBuild-12/src/sys/ufs/ufs/ufs_dirhash.c:281 stack backtrace: #0 0xffff00000034eb94 at witness_debugger+0x64 #1 0xffff0000002fb808 at _sx_xlock+0x6c #2 0xffff0000005576a4 at ufsdirhash_move+0x40 #3 0xffff00000055987c at ufs_direnter+0x2ac #4 0xffff000000561c98 at ufs_makeinode+0x464 #5 0xffff00000055e464 at ufs_create+0x3c #6 0xffff0000005eacac at VOP_CREATE_APV+0xc4 #7 0xffff0000003b9970 at vn_open_cred+0x284 #8 0xffff0000003b3524 at kern_openat+0x1d4 #9 0xffff0000005cf434 at do_el0_sync+0x4c8 #10 0xffff0000005b91d0 at handle_el0_sync+0x64 lock order reversal: 1st 0xfffffd00017c19a0 ufs (ufs) @ /pics/CrossBuild-12/src/sys/kern/vfs_subr.c:2600 2nd 0xffff000053248208 bufwait (bufwait) @ /pics/CrossBuild-12/src/sys/ufs/ffs/ffs_vnops.c:280 3rd 0xfffffd0001976068 ufs (ufs) @ /pics/CrossBuild-12/src/sys/kern/vfs_subr.c:2600 stack backtrace: #0 0xffff00000034eb94 at witness_debugger+0x64 #1 0xffff0000002ce980 at __lockmgr_args+0x57c #2 0xffff0000005527c8 at ffs_lock+0x88 #3 0xffff0000005ed764 at VOP_LOCK1_APV+0xc4 #4 0xffff0000003ba024 at _vn_lock+0x8c #5 0xffff0000003aba04 at vget+0x58 #6 0xffff00000039ea70 at vfs_hash_get+0xf0 #7 0xffff00000054ebac at ffs_vgetf+0x44 #8 0xffff000000545e1c at softdep_sync_buf+0x910 #9 0xffff000000553328 at ffs_syncvnode+0x274 #10 0xffff00000052e768 at ffs_truncate+0x624 #11 0xffff000000559d20 at ufs_direnter+0x750 #12 0xffff000000561c98 at ufs_makeinode+0x464 #13 0xffff00000055e464 at ufs_create+0x3c #14 0xffff0000005eacac at VOP_CREATE_APV+0xc4 #15 0xffff0000003b9970 at vn_open_cred+0x284 #16 0xffff0000003b3524 at kern_openat+0x1d4 #17 0xffff0000005cf434 at do_el0_sync+0x4c8 Mounting local filesystems:random: unblocking device. =2E ELF ldconfig path: /lib /usr/lib /usr/lib/compat Setting hostname: rpi3. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,AT= TACH,CACHED Feeding entropy: . smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 ue0: flags=3D8843 metric 0 mtu 15= 00 options=3D80009 ether b8:27:eb:4e:88:64 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 Starting devd. Starting dhclient. DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 192.168.1.200 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.200 bound to 192.168.1.17 -- renewal in 21600 seconds. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Creating and/or trimming log files. Starting syslogd. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting powerd. cpufreq0: rejecting change, SMP not started yet Configuring vt: blanktime. Generating RSA host key. cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet 2048 SHA256:UFglYtdXWLG/Va5zmZ0OoGMhnvYiNyGDqEUkas7PZVs root@rpi3 (RSA) Generating ECDSA host key. cpufreq0: rejecting change, SMP not started yet 256 SHA256:XPQnIwHtB3Aau3jSQDitlqDZxF8hPLji5VpjOkJ3xqI root@rpi3 (ECDSA) Generating ED25519 host key. cpufreq0: rejecting change, SMP not started yet 256 SHA256:cVSnpBc4G0NX7+I3yUWiTa4YyYroJdbS0aKqdFky3a0 root@rpi3 (ED25519= ) Performing sanity check on sshd configuration. cpufreq0: rejecting change, SMP not started yet sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x006d8000 | Version: 0x00009902 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000015 sdhci_bcm0-slot0: Argument: 0x000af240 | Trn mode: 0x0000193a sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000307 sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 sdhci_bcm0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff0089 sdhci_bcm0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: Caps: 0x00000000 | Max curr: 0x00000001 sdhci_bcm0-slot0: =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 mmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[WRITE(offset=3D314343424, length=3D16384)]error =3D= 5 mmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[READ(offset=3D1695514624, length=3D32768)]error =3D= 5 vm_fault: pager read error, pid 626 (sshd) mmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[WRITE(offset=3D314343424, length=3D16384)]error =3D= 5 Smmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[WRITE(offset=3D15509504, length=3D512)]error =3D 5= panic: brelse: inappropriate B_PAGING or B_CLUSTER bp 0xffff000053280d60 cpuid =3D 3 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005b76ac lr =3D 0xffff000000086048 sp =3D 0xffff000040328990 fp =3D 0xffff000040328ba0 db_trace_self_wrapper() at vpanic+0x170 pc =3D 0xffff000000086048 lr =3D 0xffff0000002f41b4 sp =3D 0xffff000040328bb0 fp =3D 0xffff000040328c30 vpanic() at kassert_panic+0x164 pc =3D 0xffff0000002f41b4 lr =3D 0xffff0000002f4040 sp =3D 0xffff000040328c40 fp =3D 0xffff000040328d00 kassert_panic() at brelse+0x7c4 pc =3D 0xffff0000002f4040 lr =3D 0xffff00000038e804 sp =3D 0xffff000040328d10 fp =3D 0xffff000040328d70 brelse() at bufwrite+0x338 pc =3D 0xffff00000038e804 lr =3D 0xffff00000038bb7c sp =3D 0xffff000040328d80 fp =3D 0xffff000040328dc0 bufwrite() at softdep_process_journal+0x714 pc =3D 0xffff00000038bb7c lr =3D 0xffff000000547e7c sp =3D 0xffff000040328dd0 fp =3D 0xffff000040328e70 softdep_process_journal() at flush_deplist+0xb4 pc =3D 0xffff000000547e7c lr =3D 0xffff00000054d34c sp =3D 0xffff000040328e80 fp =3D 0xffff000040328eb0 =2E.... (I wind up in the the debugger, as expected at this point) It appears I've either got something wrong in the cross-compiling environment or -HEAD is currently broken for this architecture..... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050805010001050806050400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDcxNzEwMzJaME8GCSqGSIb3DQEJBDFCBECOHXCt UCLglIHb0B0WHK0GPTOQlgmNW3GVLcdmhwB5ohu/bHN9ttreu/JUSqVotpdGICTer90u9Xb9 BVLEkjPZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAue4A7b6nEfug hDKKZrfEc7N9cVz5IxoyEBDzcoW29ru/PFEwHCxHYCfNIaNc2lwYQBCwnSPk6Tv5ErY9v4oC 8ITWyc3mnwjFo2Tp51prw9ttrrofqEAvjeMoXa3TY8kR6WDZjIlTe5tToM88Te+Piscc+9Ld JnxHJubJj9N4FPZMs5jlGyYNae6q3sXApqZXtBpm+tJ0dLyWFDr6Dh18ConvrHLCNoJBygIw gscO9J2R5VRV0RvIhv5CzmY1Fiw6zkUtuebmNZ4I1jvez8tMc/1Oh/x/IxVDgvd8PUnIwXtY l/piTY3pFfyUy9gal7cd2kM1S40e1bRYc74ZVi89P0ISkD48SqXugJv359dmFwwzuutO4TG+ Eb9b2TNPB47Hv+3THNy6NPXQKfrKXGjAS4ypzQp1sCvSrczshKob5Fj7wX06gzRJTX3yXp/v vVn4d/jY0XUcw2YBqWQFbH9PC54oAkrnw5AwWyXsjzPD/HGuV4cQ/ghM/hDhTPPEwE32QaRN 7o3v3z+aZbwDHEW5+Mh6PQ6yTPpBV2Lrva7qjeFMi2zosuPEDLmTbSOTZ8NHqYXtTJzqfrfi Mg6Bt6lFTsWkypGNHKum2+lvGcgsFPFXFdR2wKN57Wh6bJ5Wy2ozGJdohcthqLJGheinn/Xv er3MD1WwidwluU7q1ButrwMAAAAAAAA= --------------ms050805010001050806050400-- From owner-freebsd-arm@freebsd.org Tue Feb 7 17:28:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D84ECCD57AB for ; Tue, 7 Feb 2017 17:28:37 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 935721444 for ; Tue, 7 Feb 2017 17:28:37 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 949A2186D1B for ; Tue, 7 Feb 2017 11:28:36 -0600 (CST) Subject: Re: Crochet produces boom-boom build References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> To: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> Date: Tue, 7 Feb 2017 11:28:36 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170207172617.GA64935@night.db.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000907010300040705040301" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:28:37 -0000 This is a cryptographically signed message in MIME format. --------------ms000907010300040705040301 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/7/2017 11:26, Diane Bruce wrote: > On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote: >> On 2/7/2017 08:46, Karl Denninger wrote: >>> Crochet, checked out -HEAD from yesterday, attempting to boot the Pi3= >>> with what it produces I get this: >>> > ... >> I took Brad's image, grabbed /boot/loader.efi from that, replaced the >> copy that Crochet built with it, and what I get it boots but SMP is >> screwed up and it winds up with an I/O problem and panics. >> >> Here's the full boot sequence (with /boot/loader.efi replaced): >> >> RPi3 PSCI monitor installed >> ue0: Ethernet address: b8:27:eb:4e:88:64 >> Setting hostuuid: 30303030-3030-3030-3331-346538383634. >> Setting hostid: 0x968824d5. >> No suitable dump device was found. >> Starting file system checks: >> /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/mmcsd0s2a: clean, 7272066 free (274 frags, 908974 blocks, 0.0% > ... >> Generating RSA host key. >> cpufreq0: rejecting change, SMP not started yet >> cpufreq0: rejecting change, SMP not started yet >> cpufreq0: rejecting change, SMP not started yet >> cpufreq0: rejecting change, SMP not started yet >> cpufreq0: rejecting change, SMP not started yet >> cpufreq0: rejecting change, SMP not started yet > Have you tried cold booting this SD card since?=20 > >> It appears I've either got something wrong in the cross-compiling >> environment or -HEAD is currently broken for this architecture..... > Diane Uh, that is a cold boot. Brad's image, which appears (at first blush) to be built with defaults (which I used as well here) comes up and runs normally, other than a few complaints about spurious interrupts while the kernel is starting up (all CPUs start and run, etc.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000907010300040705040301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDcxNzI4MzZaME8GCSqGSIb3DQEJBDFCBEB077SI 2RWNuGjxoMknk8DikCQzuXGbnamgPC3SRLxdefV061XwQHOg8Ud1ApuivTJWZSSUnDqpqEd6 U2tlLBvaMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAQQBxPH+SwBPW c8CDX6OjAvOuVCdxBQAf3Hob3+wbxfc0BeQYcVASPMZGf7T0W0FbmtGSubYzfiraeP6xDX9e 28sBf2UBgPw4utLQ0nfTydICnCb9vGa4ZfOxD8wj50Fdi6FvYzjr++xGXTfQXFifHiFdo57G 1vPf0KR+yiKtu+BdkwCMur4CD0g7baeuYvNbdsRLYGEqlueuP9r279nc9kh8kCYtDYDO0bXb eH1r4ZJTGIsihJKTNYNrvIdnAOCLERRn6BqyGwFPWFLuuHYxaKr5hOhZWg0Zdt62AhUk26eb f8ddEi/lj2E5AaBss/3F319EKvDQ3nE8t0RadVBGklQDIKP9vazv4O/eAIlv+Z5VsXM1nUEH rOquGDWIrFD00/SQRmwNEsogBi+3kMUrIzCcQCtKWi/nVszGurOIC6tpWo4fmnMLGcE/ACtT q66ILXy/zjYGoAKpNz8YjxwczDHasTnwZI2aZnP4G6pWcLkOANzZpzzBqQ2wXYpvtCUWPwfU 7UFnoCgOEjnOx505tPBkskDyp8hJKf9w+IJPvtquN+uIQfbrHcucrliXqeANLmlpMu4CwHEP Nolki94RS7J4Ft+4bE6PrM6RpeUnH1lmHe0M/d2BXHboD0t5QkPYnEkEPSTPWipOcMbT7qX3 F7m4LiWXfwh8cQ87OuexaTsAAAAAAAA= --------------ms000907010300040705040301-- From owner-freebsd-arm@freebsd.org Tue Feb 7 17:35:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D42BBCD5A1D for ; Tue, 7 Feb 2017 17:35:50 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id C481C1AC5 for ; Tue, 7 Feb 2017 17:35:50 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 58E382AA368; Tue, 7 Feb 2017 10:25:15 -0700 (MST) Received: by night.db.net (Postfix, from userid 1000) id E230B3981A; Tue, 7 Feb 2017 12:26:17 -0500 (EST) Date: Tue, 7 Feb 2017 12:26:17 -0500 From: Diane Bruce To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: Crochet produces boom-boom build Message-ID: <20170207172617.GA64935@night.db.net> References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:35:50 -0000 On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote: > On 2/7/2017 08:46, Karl Denninger wrote: > > Crochet, checked out -HEAD from yesterday, attempting to boot the Pi3 > > with what it produces I get this: > > ... > I took Brad's image, grabbed /boot/loader.efi from that, replaced the > copy that Crochet built with it, and what I get it boots but SMP is > screwed up and it winds up with an I/O problem and panics. > > Here's the full boot sequence (with /boot/loader.efi replaced): > > RPi3 PSCI monitor installed > ue0: Ethernet address: b8:27:eb:4e:88:64 > Setting hostuuid: 30303030-3030-3030-3331-346538383634. > Setting hostid: 0x968824d5. > No suitable dump device was found. > Starting file system checks: > /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mmcsd0s2a: clean, 7272066 free (274 frags, 908974 blocks, 0.0% ... > Generating RSA host key. > cpufreq0: rejecting change, SMP not started yet > cpufreq0: rejecting change, SMP not started yet > cpufreq0: rejecting change, SMP not started yet > cpufreq0: rejecting change, SMP not started yet > cpufreq0: rejecting change, SMP not started yet > cpufreq0: rejecting change, SMP not started yet Have you tried cold booting this SD card since? > It appears I've either got something wrong in the cross-compiling > environment or -HEAD is currently broken for this architecture..... Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arm@freebsd.org Tue Feb 7 18:31:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF983CD5B62 for ; Tue, 7 Feb 2017 18:31:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 78D023D3 for ; Tue, 7 Feb 2017 18:31:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3D4971889E3 for ; Tue, 7 Feb 2017 12:31:30 -0600 (CST) Subject: Re: Crochet produces boom-boom build To: freebsd-arm@freebsd.org References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> From: Karl Denninger Message-ID: <7fcf12c8-6c2d-ba01-aef1-75c734865e2d@denninger.net> Date: Tue, 7 Feb 2017 12:31:30 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090800010407070303030801" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:31:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090800010407070303030801 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/7/2017 11:28, Karl Denninger wrote: > On 2/7/2017 11:26, Diane Bruce wrote: >> Have you tried cold booting this SD card since?=20 >> >>> It appears I've either got something wrong in the cross-compiling >>> environment or -HEAD is currently broken for this architecture..... >> Diane > Uh, that is a cold boot. Brad's image, which appears (at first blush) > to be built with defaults (which I used as well here) comes up and runs= > normally, other than a few complaints about spurious interrupts while > the kernel is starting up (all CPUs start and run, etc.) > BTW the cross-compiler components (that pkg says are current) used are: root@NewFS:/disk/karl # pkg info|grep aar aarch64-binutils-2.27_5,1 GNU binutils for AArch64 cross-development= aarch64-none-elf-binutils-2.27_5,1 GNU binutils for bare metal AArch64 cross-development aarch64-none-elf-gcc-6.3.0 Cross GNU Compiler Collection for aarch64noneelf An "svn update ." in ports leaves me with the same versions in the ports tree, so it does appear I have the current cross-compiler bits. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090800010407070303030801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDcxODMxMzBaME8GCSqGSIb3DQEJBDFCBEBAoima rsNFpot8bCSzdrd/putgCZXhABmQmogx3iLFYjrM7ZGjn3gRgtHuT79TzRg1klS2isedEN3l pkg1g0HaMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAdRfOciG4CpZa FPulgkPiJ4282izRZh3TPBufyiAWgUeEFFmI0x0ieRtbwZlAB0WkCLbhgZevp3Is270K02FT wQgU091RW627Yl1eKh4HGhU4btDw1oe/7p0VtbMUxeiQniAGx1zCpIwkJw3d6iGmZreGBQWz XRtSxI0/WvR9WsQjtQzF873XgLCbx7nbc4S0jZ17WJDwBLMuJm8ekpptMQJnMFZ8EfNk0MD2 k0Gb+X2TFrgkK9qoX8meu1gAK9BHbDTj/vWBZ6J5zfibV3dtD63upGw7GNjwO0bJwVN0qiLG kAtYRi8XtjlsSinokD36avsEqFQCf6rftsHA60/mSwJJWHs9QwCFPZp0kj+V9pXRo2KO7ufR llD7w5E3sBV4HFYSwG7IK2Y/0CZvrEyP9BfN6YI/TxtGCr0zTHF794/RUFZA0lfCXc12iM+A MHHHVfMWNfa2fjuuGokYm0KCiNP5FjVO97VPRVwMeAXMK3SmtkZz48G+O4QtR3B39D759j/T QeNKliVisQAeBAWoqnVsNM8VC8HKhAWQxKO63v4QhhtJTFYdeslRH6QtcmWVLcyXEByj7o4D iR3qExmfLkCN206vo2acDnu6y4/KMHvXtY4MrXpgd9LJnNLJS/hXZfHa5y2RNkMF/CXRkSyZ 4Q4EngfPHeMNRY1kGME+7zMAAAAAAAA= --------------ms090800010407070303030801-- From owner-freebsd-arm@freebsd.org Tue Feb 7 18:33:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98CCCCD5BF4 for ; Tue, 7 Feb 2017 18:33:37 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8849A8CF for ; Tue, 7 Feb 2017 18:33:37 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 18BB52AA38D; Tue, 7 Feb 2017 11:32:31 -0700 (MST) Received: by night.db.net (Postfix, from userid 1000) id F05BD3981A; Tue, 7 Feb 2017 13:33:33 -0500 (EST) Date: Tue, 7 Feb 2017 13:33:33 -0500 From: Diane Bruce To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: Crochet produces boom-boom build Message-ID: <20170207183333.GA65714@night.db.net> References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:33:37 -0000 On Tue, Feb 07, 2017 at 11:28:36AM -0600, Karl Denninger wrote: > On 2/7/2017 11:26, Diane Bruce wrote: > > On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote: > Uh, that is a cold boot. Brad's image, which appears (at first blush) > to be built with defaults (which I used as well here) comes up and runs > the kernel is starting up (all CPUs start and run, etc.) Then you are missing armstub8.bin in the dos portion of the sd card. The latest crotchet and u-boot-rpi3.bin port will install these. > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arm@freebsd.org Tue Feb 7 18:36:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2F69CD5C99 for ; Tue, 7 Feb 2017 18:36:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD6EA75 for ; Tue, 7 Feb 2017 18:36:55 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 1712719DEFF for ; Tue, 7 Feb 2017 12:36:55 -0600 (CST) Subject: Re: Crochet produces boom-boom build References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> <20170207183333.GA65714@night.db.net> To: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: <92d8e397-e050-3d54-be0c-d6774b98f990@denninger.net> Date: Tue, 7 Feb 2017 12:36:54 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170207183333.GA65714@night.db.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060507080601070909030205" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:36:56 -0000 This is a cryptographically signed message in MIME format. --------------ms060507080601070909030205 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/7/2017 12:33, Diane Bruce wrote: > On Tue, Feb 07, 2017 at 11:28:36AM -0600, Karl Denninger wrote: >> On 2/7/2017 11:26, Diane Bruce wrote: >>> On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote: >> Uh, that is a cold boot. Brad's image, which appears (at first blush)= >> to be built with defaults (which I used as well here) comes up and run= s >> the kernel is starting up (all CPUs start and run, etc.) > Then you are missing armstub8.bin in the dos portion of the sd card. > The latest crotchet and u-boot-rpi3.bin port will install these. > No I'm not -- it was put there by crochet in the build and is present. root@NewFS:~karl/temp # mdconfig -a Pi3-KSD.img md0 root@NewFS:~karl/temp # mount -t msdosfs /dev/md0s1 /mnt root@NewFS:~karl/temp # cd /mnt root@NewFS:/mnt # ls EFI config.txt start_cd.elf LICENCE.broadcom fixup.dat start_x.elf README fixup_cd.dat startup.nsh armstub8.bin fixup_x.dat u-boot.bin bcm2710-rpi-3-b.dtb overlays bootcode.bin start.elf root@NewFS:/mnt # ls -al total 7561 drwxr-xr-x 1 root wheel 16384 Jan 1 1980 . drwxr-xr-x 45 root wheel 55 Jan 24 13:22 .. drwxr-xr-x 1 root wheel 4096 Feb 7 10:13 EFI -rwxr-xr-x 1 root wheel 1494 Feb 7 10:13 LICENCE.broadcom -rwxr-xr-x 1 root wheel 123 Feb 7 10:13 README -rwxr-xr-x 1 root wheel 6144 Feb 7 10:13 armstub8.bin -rwxr-xr-x 1 root wheel 15992 Feb 7 10:13 bcm2710-rpi-3-b.dtb -rwxr-xr-x 1 root wheel 17932 Feb 7 10:13 bootcode.bin -rwxr-xr-x 1 root wheel 137 Feb 7 10:13 config.txt -rwxr-xr-x 1 root wheel 6482 Feb 7 10:13 fixup.dat -rwxr-xr-x 1 root wheel 2504 Feb 7 10:13 fixup_cd.dat -rwxr-xr-x 1 root wheel 9716 Feb 7 10:13 fixup_x.dat drwxr-xr-x 1 root wheel 4096 Feb 7 10:13 overlays -rwxr-xr-x 1 root wheel 2747896 Feb 7 10:13 start.elf -rwxr-xr-x 1 root wheel 618296 Feb 7 10:13 start_cd.elf -rwxr-xr-x 1 root wheel 3879416 Feb 7 10:13 start_x.elf -rwxr-xr-x 1 root wheel 9 Feb 7 10:13 startup.nsh -rwxr-xr-x 1 root wheel 369456 Feb 7 10:13 u-boot.bin --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060507080601070909030205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDcxODM2NTRaME8GCSqGSIb3DQEJBDFCBECC4STb Ic6HpmUADqMB6ZikhRFcS6u49H6mKCFpusWrJwU51lY4ze1Z40eURZS269iWX9ZKJPs5Tqo1 C4MqkTcdMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAvh0YKfyY5SIy oPNJRkf+F0lcu32WNc32UkshUVBx6uLOZCSESuK/avedKyNi3QFZ2hCnQNEQdzWrdgw2IZ9Q Bd8q5Ud/wmVJGJzalVzoCY0J3/TleumKMv/0tVnjYxPff9Pnjrcb+acnXFm4X6GFVO3KpYAg 6Ccuelyo4ZdpUrCiPE1agEonQRQxdl19mmoHbo2hRGacTS1PCRS5G4oKQcOGoUgxK+41dqMB 7abEPp1teJ4nJwQKy/uTNMPU3aDXWVHnbcTqKVljQ7D5M0FFKlrgaB9CJSANxmychf+G1iGt ygT/X4GRodrba3nPz1qMXCyBaqOEwIjdy/xJuKxmF7MCeOOiyWS3w+FNUBl+8ctjXq1plcsp h1lj/A6kwJF+PvDJUKLYTaBgXLpxXCt3b8qYZiv0TOQopI0ScIXyweEcbmapNmafjwi1AAaA yXVo0/VMstXqxbiP0Qp0ffGF6w6EaJoW5S/hqh/rhCZ+aqGzuDIIyT5KWwNDyzrEv/Dif1wn S+qpIaBubILHcVze0Hp+c7+I/3xR0AQdZxkiyEzAJPHeYBea/D/pw1lc/nSvOWvuOGNbyobQ tFVocAgV+fZt3wp7YbuADee3AyYVHDI4LHAck9zvGD+GkGAx2l6qM6BSP40JZ0ONtQWlqxnI t327p17bcTtMe9GRLC2eawAAAAAAAAA= --------------ms060507080601070909030205-- From owner-freebsd-arm@freebsd.org Tue Feb 7 18:47:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9409CD41D9 for ; Tue, 7 Feb 2017 18:47:06 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.com (mail.synsport.com [208.69.230.148]) (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 B4C6D1627 for ; Tue, 7 Feb 2017 18:47:06 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [127.0.0.1] (ip72-204-83-236.fv.ks.cox.net [72.204.83.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.com (Postfix) with ESMTP id 1EC1143CC8; Tue, 7 Feb 2017 12:45:22 -0600 (CST) To: freebsd-arm@freebsd.org Reply-To: marino@freebsd.org From: John Marino Subject: ARM64: PC/IP not saved in signal frame Cc: Andreas Tobler Message-ID: <530c18cd-d50d-4709-a0ca-22324a0cb592@marino.st> Date: Tue, 7 Feb 2017 12:47:01 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 X-Antivirus: avast! (VPS 170206-3, 02/06/2017), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:47:06 -0000 Hi guys, I've been struggling to provide unwind support on the aarch64-*-freebsd* target of FreeBSD. The only working example on this arch is aarch64-linux (attached). I think I'm 99% done with the freebsd version (attached) but the last value that needs to be pass to the _Unwind_FrameState is the program counter offset. I know the PC is not register-based on aarch64. Linux still saves the value in the signal context, but AFAICT FreeBSD does not. Can somebody A) confirm that the program counter is missing from the saved signal context B) confirm that it needs to be added for proper signal frame unwinding? Alternatively, maybe somebody can figure out a solution given the current freebsd structures, but I'm losing hope on that one. (line 99) Regards, John From owner-freebsd-arm@freebsd.org Tue Feb 7 18:55:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCB2FCD443C for ; Tue, 7 Feb 2017 18:55:56 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.com (mail.synsport.com [208.69.230.148]) (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 BA2D91BFE for ; Tue, 7 Feb 2017 18:55:56 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from [127.0.0.1] (ip72-204-83-236.fv.ks.cox.net [72.204.83.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.com (Postfix) with ESMTP id 78ED743CC8; Tue, 7 Feb 2017 12:54:12 -0600 (CST) Subject: Re: ARM64: PC/IP not saved in signal frame Reply-To: marino@freebsd.org References: <530c18cd-d50d-4709-a0ca-22324a0cb592@marino.st> To: freebsd-arm@freebsd.org Cc: Andreas Tobler From: John Marino Message-ID: <86279411-3979-edab-7ba2-4a1e3fa6429e@marino.st> Date: Tue, 7 Feb 2017 12:55:51 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <530c18cd-d50d-4709-a0ca-22324a0cb592@marino.st> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170206-3, 02/06/2017), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:55:57 -0000 On 2/7/2017 12:47, John Marino wrote: > Hi guys, > I've been struggling to provide unwind support on the aarch64-*-freebsd* > target of FreeBSD. The only working example on this arch is > aarch64-linux (attached). I think I'm 99% done with the freebsd version > (attached) but the last value that needs to be pass to the > _Unwind_FrameState is the program counter offset. > > I know the PC is not register-based on aarch64. Linux still saves the > value in the signal context, but AFAICT FreeBSD does not. > > Can somebody > A) confirm that the program counter is missing from the saved signal > context > B) confirm that it needs to be added for proper signal frame unwinding? > > Alternatively, maybe somebody can figure out a solution given the > current freebsd structures, but I'm losing hope on that one. (line 99) Apparently attachments are stripped out on this mail list. You can see the headers here: https://leaf.dragonflybsd.org/~marino/linux-unwind.h https://leaf.dragonflybsd.org/~marino/freebsd-unwind.h John From owner-freebsd-arm@freebsd.org Tue Feb 7 19:00:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B6A2CD4730 for ; Tue, 7 Feb 2017 19:00:39 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBD8F1F31 for ; Tue, 7 Feb 2017 19:00:38 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id x49so143608163qtc.2 for ; Tue, 07 Feb 2017 11:00:38 -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=nzjXrV022zp31y9rSMGmBzQpmC9wjBPcT0AdF1U1aI4=; b=fNMppUI1PJr6pJtddjxcY+1SkWXWUha11Ztnb2d2uPf/Gm+Xehd2KvJ9Qd4DnYa4wg JfaiyZkEuKu03Q0+GrrI7ulWM6zUj6KELG/2rzp+6bEAb42jECJ5mfhR+2xCyBS/gDhl PmMNArmA8imLQIrYUzrSHknYMnoiYk01ZC4ZXsoTs+/eQrT5sT+g4CJ8BQNnrBRrt4Hx 7PMeEaCzdYtwwDN5UeThiJb7G1WRpEfscc+liUs9La8D8XGjIEhGNClVuuGQdXBNGYSy mGlZQKv/QlBg08BewhOnAU7yURXzpFsrAzTb4DpGwejdWLLeIl1lETkabUPks5rjlmYA ga9g== 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=nzjXrV022zp31y9rSMGmBzQpmC9wjBPcT0AdF1U1aI4=; b=Bh4vVr6SJT+sjOh2rxpr5sYQvdmzbI76Fmxia0MmeMIRugguSBk/qAPdlj8vM8HTfq CRr1inGWEI4Lc8wGFNLXOFyEL4jlvHqRzBwjS28j9DR4gLSfipZFi2aiBkrBIGTjXjAp ka4YetcL4Yqfu9YbXjMXrfpdoi1NAn2XwDwwkuBXXeM5ana4JlU6uN3nQKauulovOB1R aOJ6xXWIBhQMDilEPuiNx/1pPRDKuSIwv/Y+v32mp+gauZl9Ilo8YPud8TI0716rWq1g NOn4QKUGwMtIW8c+Vl9CNGLkkUG5nrYU6oAxVD4YsPXBtj0W69M8Wd9ewbrT6gyyaoaC +wvg== X-Gm-Message-State: AMke39mMwXOw+zcBAVgdfp2Apejn+mDYVWurhxhjiKR8lsNPcWz4pWTArqOSaXvtzFze7sUxp+zSbCDPrVIvHA== X-Received: by 10.200.40.113 with SMTP id 46mr15076515qtr.167.1486494037705; Tue, 07 Feb 2017 11:00:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.104.8 with HTTP; Tue, 7 Feb 2017 11:00:07 -0800 (PST) From: Jia-Shiun Li Date: Wed, 8 Feb 2017 03:00:07 +0800 Message-ID: Subject: patching cpufreq for rpi3 To: "freebsd-arm@freebsd.org" Content-Type: multipart/mixed; boundary=001a114062641470300547f55d2c X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:00:39 -0000 --001a114062641470300547f55d2c Content-Type: text/plain; charset=UTF-8 I was figuring out why frequency scaling does not work on rpi3, and found that bcm2837 was not caught in some cases. Thus the attached patch. The patch corrects voltage reporting for rpi3. Frequency scaling still does not work though. Any ideas? --- dmesg.orig.txt 2017-02-07 20:00:46.587450000 +0800 +++ dmesg.new3.txt 2017-02-08 00:44:23.609649000 +0800 @@ -5,13 +5,13 @@ 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 12.0-CURRENT #1 r313043: Sun Feb 5 01:01:06 CST 2017 +FreeBSD 12.0-CURRENT #3 r313043M: Wed Feb 8 00:24:00 CST 2017 jsli@4cbsd:/personal/freebsd/obj/x64/arm64.aarch64/ personal/freebsd/fbsdsrc/sys/GENERIC arm64 FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. -Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000000e27000. -Preloaded /boot/entropy "/boot/entropy" at 0xffff000000e27de0. +Preloaded elf kernel "/boot/kernel.cpufreq/kernel" at 0xffff000000e27000. +Preloaded /boot/entropy "/boot/entropy" at 0xffff000000e27de8. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) @@ -236,8 +236,8 @@ bcm2835_cpufreq0: Boot settings: bcm2835_cpufreq0: current ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF bcm2835_cpufreq0: max/min ARM 1200/600MHz, Core 400/250MHz, SDRAM 450/400MHz -bcm2835_cpufreq0: current Core 30001200mV, SDRAM_C 30001200mV, SDRAM_I 30001200mV, SDRAM_P 30001200mV -bcm2835_cpufreq0: max/min Core 32344950/30001200mV, SDRAM_C 30001200/30001200mV, SDRAM_I 30001200/30001200mV, SDRAM_P 30001200/30001200mV +bcm2835_cpufreq0: current Core 1200mV, SDRAM_C 1200mV, SDRAM_I 1200mV, SDRAM_P 1200mV +bcm2835_cpufreq0: max/min Core 1293/1200mV, SDRAM_C 1200/1200mV, SDRAM_I 1200/1200mV, SDRAM_P 1200/1200mV bcm2835_cpufreq0: Temperature 51.5C Release APs mmc0: setting bus width to 4 bits -Jia-Shiun. --001a114062641470300547f55d2c Content-Type: text/x-patch; charset=US-ASCII; name="rpi3cpufreq.patch" Content-Disposition: attachment; filename="rpi3cpufreq.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iyvw4hnj0 SW5kZXg6IHN5cy9hcm0vYnJvYWRjb20vYmNtMjgzNS9iY20yODM1X2NwdWZyZXEuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzeXMvYXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9jcHVmcmVxLmMJKHJldmlz aW9uIDMxMzA0MykKKysrIHN5cy9hcm0vYnJvYWRjb20vYmNtMjgzNS9iY20yODM1X2NwdWZyZXEu Ywkod29ya2luZyBjb3B5KQpAQCAtNjYsMTYgKzY2LDE2IEBACiAjZGVmaW5lCUhaMk1IWihmcmVx KSAoKGZyZXEpIC8gKDEwMDAgKiAxMDAwKSkKICNkZWZpbmUJTUhaMkhaKGZyZXEpICgoZnJlcSkg KiAoMTAwMCAqIDEwMDApKQogCi0jaWZkZWYgU09DX0JDTTI4MzYKKyNpZmRlZiBTT0NfQkNNMjgz NQorI2RlZmluZQlPRkZTRVQyTVZPTFQodmFsKSAoMTIwMCArICgodmFsKSAqIDI1KSkKKyNkZWZp bmUJTVZPTFQyT0ZGU0VUKHZhbCkgKCgodmFsKSAtIDEyMDApIC8gMjUpCisjZGVmaW5lCURFRkFV TFRfQVJNX0ZSRVFVRU5DWQkgNzAwCisjZGVmaW5lCURFRkFVTFRfTE9XRVNUX0ZSRVEJIDMwMAor I2Vsc2UKICNkZWZpbmUJT0ZGU0VUMk1WT0xUKHZhbCkgKCgodmFsKSAvIDEwMDApKQogI2RlZmlu ZQlNVk9MVDJPRkZTRVQodmFsKSAoKCh2YWwpICogMTAwMCkpCiAjZGVmaW5lCURFRkFVTFRfQVJN X0ZSRVFVRU5DWQkgNjAwCiAjZGVmaW5lCURFRkFVTFRfTE9XRVNUX0ZSRVEJIDYwMAotI2Vsc2UK LSNkZWZpbmUJT0ZGU0VUMk1WT0xUKHZhbCkgKDEyMDAgKyAoKHZhbCkgKiAyNSkpCi0jZGVmaW5l CU1WT0xUMk9GRlNFVCh2YWwpICgoKHZhbCkgLSAxMjAwKSAvIDI1KQotI2RlZmluZQlERUZBVUxU X0FSTV9GUkVRVUVOQ1kJIDcwMAotI2RlZmluZQlERUZBVUxUX0xPV0VTVF9GUkVRCSAzMDAKICNl bmRpZgogI2RlZmluZQlERUZBVUxUX0NPUkVfRlJFUVVFTkNZCSAyNTAKICNkZWZpbmUJREVGQVVM VF9TRFJBTV9GUkVRVUVOQ1kJIDQwMApAQCAtMTU0NCw3ICsxNTQ0LDIwIEBACiAJCWlmIChtaW5f ZnJlcSA+IGNwdWZyZXFfbG93ZXN0X2ZyZXEpCiAJCQltaW5fZnJlcSA9IGNwdWZyZXFfbG93ZXN0 X2ZyZXE7CiAKLSNpZmRlZiBTT0NfQkNNMjgzNgorI2lmZGVmIFNPQ19CQ00yODM1CisJLyogZnJv bSBmcmVxIHRvIG1pbl9mcmVxICovCisJZm9yIChpZHggPSAwOyBpZHggPCAqY291bnQgJiYgZnJl cSA+PSBtaW5fZnJlcTsgaWR4KyspIHsKKwkJaWYgKGZyZXEgPiBzYy0+YXJtX21pbl9mcmVxKQor CQkJdm9sdHMgPSBzYy0+bWF4X3ZvbHRhZ2VfY29yZTsKKwkJZWxzZQorCQkJdm9sdHMgPSBzYy0+ bWluX3ZvbHRhZ2VfY29yZTsKKwkJc2V0c1tpZHhdLmZyZXEgPSBmcmVxOworCQlzZXRzW2lkeF0u dm9sdHMgPSB2b2x0czsKKwkJc2V0c1tpZHhdLmxhdCA9IFRSQU5TSVRJT05fTEFURU5DWTsKKwkJ c2V0c1tpZHhdLmRldiA9IGRldjsKKwkJZnJlcSAtPSBNSFpTVEVQOworCX0KKyNlbHNlCiAJLyog WFhYIFJQaTIgaGF2ZSBvbmx5IDkwMC82MDBNSHogKi8KIAlpZHggPSAwOwogCXZvbHRzID0gc2Mt Pm1pbl92b2x0YWdlX2NvcmU7CkBAIC0xNTYwLDE5ICsxNTczLDYgQEAKIAkJc2V0c1tpZHhdLmRl diA9IGRldjsKIAkJaWR4Kys7CiAJfQotI2Vsc2UKLQkvKiBmcm9tIGZyZXEgdG8gbWluX2ZyZXEg Ki8KLQlmb3IgKGlkeCA9IDA7IGlkeCA8ICpjb3VudCAmJiBmcmVxID49IG1pbl9mcmVxOyBpZHgr KykgewotCQlpZiAoZnJlcSA+IHNjLT5hcm1fbWluX2ZyZXEpCi0JCQl2b2x0cyA9IHNjLT5tYXhf dm9sdGFnZV9jb3JlOwotCQllbHNlCi0JCQl2b2x0cyA9IHNjLT5taW5fdm9sdGFnZV9jb3JlOwot CQlzZXRzW2lkeF0uZnJlcSA9IGZyZXE7Ci0JCXNldHNbaWR4XS52b2x0cyA9IHZvbHRzOwotCQlz ZXRzW2lkeF0ubGF0ID0gVFJBTlNJVElPTl9MQVRFTkNZOwotCQlzZXRzW2lkeF0uZGV2ID0gZGV2 OwotCQlmcmVxIC09IE1IWlNURVA7Ci0JfQogI2VuZGlmCiAJKmNvdW50ID0gaWR4OwogCg== --001a114062641470300547f55d2c-- From owner-freebsd-arm@freebsd.org Tue Feb 7 19:06:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CA50CD4857 for ; Tue, 7 Feb 2017 19:06:25 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id DD85374D; Tue, 7 Feb 2017 19:06:24 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-144.nat-2.net.cam.ac.uk [131.111.5.144]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 121C6D8561; Tue, 7 Feb 2017 19:00:51 +0000 (UTC) Date: Tue, 7 Feb 2017 19:06:22 +0000 From: Andrew Turner To: John Marino Cc: marino@freebsd.org, freebsd-arm@freebsd.org, Andreas Tobler Subject: Re: ARM64: PC/IP not saved in signal frame Message-ID: <20170207190622.1a7a3673@zapp> In-Reply-To: <86279411-3979-edab-7ba2-4a1e3fa6429e@marino.st> References: <530c18cd-d50d-4709-a0ca-22324a0cb592@marino.st> <86279411-3979-edab-7ba2-4a1e3fa6429e@marino.st> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:06:25 -0000 On Tue, 7 Feb 2017 12:55:51 -0600 John Marino wrote: > On 2/7/2017 12:47, John Marino wrote: > > Hi guys, > > I've been struggling to provide unwind support on the > > aarch64-*-freebsd* target of FreeBSD. The only working example on > > this arch is aarch64-linux (attached). I think I'm 99% done with > > the freebsd version (attached) but the last value that needs to be > > pass to the _Unwind_FrameState is the program counter offset. > > > > I know the PC is not register-based on aarch64. Linux still saves > > the value in the signal context, but AFAICT FreeBSD does not. > > > > Can somebody > > A) confirm that the program counter is missing from the saved signal > > context > > B) confirm that it needs to be added for proper signal frame > > unwinding? > > > > Alternatively, maybe somebody can figure out a solution given the > > current freebsd structures, but I'm losing hope on that one. (line > > 99) > > Apparently attachments are stripped out on this mail list. > You can see the headers here: > https://leaf.dragonflybsd.org/~marino/linux-unwind.h > https://leaf.dragonflybsd.org/~marino/freebsd-unwind.h You want sc->REG_NAME(elr). Andrew From owner-freebsd-arm@freebsd.org Tue Feb 7 21:36:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FC5ECD5578 for ; Tue, 7 Feb 2017 21:36:26 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0064BF06 for ; Tue, 7 Feb 2017 21:36:25 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id D207D122111; Tue, 7 Feb 2017 15:36:18 -0600 (CST) Subject: Re: Crochet produces boom-boom build To: Diane Bruce , "freebsd-arm@freebsd.org" References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> <20170207183333.GA65714@night.db.net> From: Karl Denninger Message-ID: <3587bf6c-ba2e-dab6-cc66-0ac1cdf4b27c@denninger.net> Date: Tue, 7 Feb 2017 15:36:18 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170207183333.GA65714@night.db.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050006040807090703020609" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:36:26 -0000 This is a cryptographically signed message in MIME format. --------------ms050006040807090703020609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/7/2017 12:33, Diane Bruce wrote: > On Tue, Feb 07, 2017 at 11:28:36AM -0600, Karl Denninger wrote: >> On 2/7/2017 11:26, Diane Bruce wrote: >>> On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote: >> Uh, that is a cold boot. Brad's image, which appears (at first blush)= >> to be built with defaults (which I used as well here) comes up and run= s >> the kernel is starting up (all CPUs start and run, etc.) > Then you are missing armstub8.bin in the dos portion of the sd card. > The latest crotchet and u-boot-rpi3.bin port will install these. I think the path is to figure out is why /boot/loader.efi blows up, given that armstub8.bin IS present and is being installed -- and my Crochet git grab was yesterday (last change visible appears to be 5 days old.) RPi3 PSCI monitor installed U-Boot 2017.01 (Feb 07 2017 - 14:26:16 -0600) DRAM: 944 MiB RPI 3 Model B (0xa22082) MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 81472 bytes read in 28 ms (2.8 MiB/s) ## Starting EFI application at 01000000 ... Scanning disks on usb... Scanning disks on mmc... Adding logical partition Adding logical partition MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 7 disks >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console Command line arguments: loader.efi Image base: 0x379b8008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Tue Feb 7 15:15:52 CST 2017 freebsd@NewFS.denninger.net) Failed to start image provided by UFS (14) "Synchronous Abort" handler, esr 0x96000004 ELR: 3af62cec LR: 3af61d60 x0 : 0000000000000001 x1 : 0000000000000001 x2 : 000000003afeb000 x3 : 000000000000003f x4 : 0000000000000020 x5 : 0000000000000010 x6 : 0000000000000000 x7 : 0000000039b260a4 x8 : 000000003af61d48 x9 : 000000000000000d x10: 0000000000000030 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000002 x14: 0000000000000000 x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 x18: 000000003ab30df8 x19: 0000000037a16008 x20: 0000000000000000 x21: 0000000000000000 x22: 0000000039b28000 x23: 0000000039b1d49c x24: 0000000039b28850 x25: 000000003ab3d740 x26: 000000003af839a0 x27: 0000000039b2e3e8 x28: 0000000000000000 x29: 000000003ab2ef60 Resetting CPU ... resetting ... That's what I get off a clean build (just re-built/reinstalled the u-boot-rpi3 port, just to be sure, then re-ran Crochet.) I can replace /boot/loader.efi with the "working" one from Brad's build -- which is NOT of the same size (say much less checksum) -- but I suspect whatever is producing the bad code in /boot/loader.efi is also producing the bad code in the rest of the build.... so fixing the first one should fix the second. What are you building Crochet'd builds for the Pi3 on and what versions of aarch64-* do you have on your system? The clue may lie there. I am building on: FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050006040807090703020609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDcyMTM2MThaME8GCSqGSIb3DQEJBDFCBEDiDwHq SgpWyhbPvimp74Ph1h5UAUEAhV3yusZjQ3Xqwq7hMfBCo56eiHc8ekEpDkRJ9o+jS8b7K6/8 NAuySh19MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAhHjOP7+4ZBsw rho3sdeGb8HFKxcoLEtFs8rVdnkcRo2UFX3bb5wgfAGcAWMnDNoyblmKG28X483AtZFt25yl XKFNZtxdVVD7a36fHeSs4eJw+V3hr9wwDbV2ZARrXdr5Uzvvjh7OXaG8cKnVZflOBFZI+iGr 64s2EgMmmLCh3AzT4sN7QyxTs3HUYq0T5p+fMQr2VO6wz1G9QtrzKnxs8xb/+1EZWk240dNM snh3ANGRcPwKHyFtIQUkq0dgxXoqsCdRFsh97yg8Ux9BQyX/zDaLabXfgmfa0x02f3hMVj9X eSe0o+ifDSgyYQ6FocUD57pgXbyQh1sERNJtAtsRPOd5/bstLA5w8Wla0R5tOrH0OU9pYbMl 1QMftGe7xeI6pAsFxseJZ8cp5KFrtK+3Rew8wpcxa+e8AG2kF8g4/lV4yUZ27Vt3Lj9eUxiL CtzK/y2NW0DXMXYUeBaVwwRgqWe1jBjc86GUVW3Jz+zJ7zUQj5HPl9nkJl4sUNy9iXLT056b SjOhh5wGHXcKctbI+WdFCKlXtG20WajYXHynxjQzNMsQq5Wmmkl7ZnFCexTDcfCVdHlxbziJ B0GogAMGZyClkIAsSBc8AC9a57x8YiNjREoB2xkg8fB9pPWJ/wASFIvZfHMfXQvW+0SxdJMc Jrb1GCfxYMd4GqB+jmnIkN0AAAAAAAA= --------------ms050006040807090703020609-- From owner-freebsd-arm@freebsd.org Wed Feb 8 01:42:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16211CD4AFA for ; Wed, 8 Feb 2017 01:42:40 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.com (mail.synsport.com [208.69.230.148]) (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 E76BF14A6 for ; Wed, 8 Feb 2017 01:42:39 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from [127.0.0.1] (ip72-204-83-236.fv.ks.cox.net [72.204.83.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.com (Postfix) with ESMTP id 53F6243BBC; Tue, 7 Feb 2017 19:40:54 -0600 (CST) Subject: Re: ARM64: PC/IP not saved in signal frame To: Andrew Turner References: <530c18cd-d50d-4709-a0ca-22324a0cb592@marino.st> <86279411-3979-edab-7ba2-4a1e3fa6429e@marino.st> <20170207190622.1a7a3673@zapp> Cc: freebsd-arm@freebsd.org, Andreas Tobler From: John Marino Message-ID: Date: Tue, 7 Feb 2017 19:42:33 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20170207190622.1a7a3673@zapp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170206-3, 02/06/2017), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 01:42:40 -0000 On 2/7/2017 13:06, Andrew Turner wrote: > On Tue, 7 Feb 2017 12:55:51 -0600 > John Marino wrote: > >> On 2/7/2017 12:47, John Marino wrote: >>> Hi guys, >>> I've been struggling to provide unwind support on the >>> aarch64-*-freebsd* target of FreeBSD. The only working example on >>> this arch is aarch64-linux (attached). I think I'm 99% done with >>> the freebsd version (attached) but the last value that needs to be >>> pass to the _Unwind_FrameState is the program counter offset. >>> >>> I know the PC is not register-based on aarch64. Linux still saves >>> the value in the signal context, but AFAICT FreeBSD does not. >>> >>> Can somebody >>> A) confirm that the program counter is missing from the saved signal >>> context >>> B) confirm that it needs to be added for proper signal frame >>> unwinding? >>> >>> Alternatively, maybe somebody can figure out a solution given the >>> current freebsd structures, but I'm losing hope on that one. (line >>> 99) >> >> Apparently attachments are stripped out on this mail list. >> You can see the headers here: >> https://leaf.dragonflybsd.org/~marino/linux-unwind.h >> https://leaf.dragonflybsd.org/~marino/freebsd-unwind.h > > You want sc->REG_NAME(elr). > Hi Andrew, After changing the .how field to REG_SAVED_OFFSET (from the original REG_SAVED_VAL_OFFSET) on the retaddr column, it worked! I didn't expect that though. Is linux just using a misnomer? That is, is it referring to the Exception Link Register as the PC? I'm just trying to understand what happened and how you knew the correct answer. :) John From owner-freebsd-arm@freebsd.org Wed Feb 8 09:12:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BBE6CD5360 for ; Wed, 8 Feb 2017 09:12:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2911835 for ; Wed, 8 Feb 2017 09:12:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 8B7E2CD535F; Wed, 8 Feb 2017 09:12:35 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B28ECD535E for ; Wed, 8 Feb 2017 09:12:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4BF841834 for ; Wed, 8 Feb 2017 09:12:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from sgi-2.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cbO3L-000MFL-Og for arm@freebsd.org; Wed, 08 Feb 2017 10:56:39 +0200 From: Daniel Braniss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: nanopi and usb not working Message-Id: <53687A6E-9B54-4EF7-B19E-09541DDD109C@cs.huji.ac.il> Date: Wed, 8 Feb 2017 10:56:39 +0200 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 09:12:35 -0000 Hi, I am beginning to wonder if my board has a broken usb, since no matter = what I plug in it gives error: usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR ugen1.2: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device BTW, this is with current, and nanopi-neo.dts but orange-pi u-boot. anyone has a working usb? cheers, danny From owner-freebsd-arm@freebsd.org Wed Feb 8 09:18:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D926CD53E0 for ; Wed, 8 Feb 2017 09:18:25 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4D132192A for ; Wed, 8 Feb 2017 09:18:25 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 49939CD53DF; Wed, 8 Feb 2017 09:18:25 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4937ECD53DE for ; Wed, 8 Feb 2017 09:18:25 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E1C51929 for ; Wed, 8 Feb 2017 09:18:25 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ot0-x232.google.com with SMTP id 32so108295650oth.3 for ; Wed, 08 Feb 2017 01:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C2veUY6wppnkfKmAEM4ZFgAOgWd0XkAoZh7bdvG+KPU=; b=l3d89rP3l8904TjJDwfTcmy1ZxNx6ZqpmYeb5PPoDlMk3mGzKF5bh7/r782MUYFDiy skxcQMhKETo+VGQzBQ6+MZvRR0UzTDd17i3up9lOjC6vw8JV/+dzxtiaKv1FxUD3L99F hefjHJz+ZOwrd7o9ShjjPXLOzwojxHYdUjRGuO1u3ESQURQcioE7srm0PANhOCUO07FT QoSv6VRtPOGIyggtApz/q3+DMxF2eyRsAJvjLpdTvNyJr98YPAQh8rnknTg1Xg3dglpf Ok7oh/4lr34N3QNP6DFJ8QKwMELny4YcVjWS3//ntx6l2ETkjEKvWHc+YFGj0HPlhVzY AThQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C2veUY6wppnkfKmAEM4ZFgAOgWd0XkAoZh7bdvG+KPU=; b=GJrHL7HBbq05ZI1dOMCtVgCMPWvPuRCo5OVjkPU22hK1Orh1tySmDBKsizfOkQF41V PvDM/A6Ine1aoypSGMbCwInyBCNO14mDcsAPj48wd6LheGEQB2RXoQa9NMxGWCPQ4oln U/5j/ilkNBm8pRwrJR3+ArYtbWXFWvQk9e9Roc2KxVLd4jzP8k3BFYVbSUD28mvmHNDE 1Nu4xJPo9BMn1WLkkahEZMXo+P6ktttD9lLyVeFoR7GBZG36+dL5+CUtR2qbq8oKkwSB 6CaNH86IgKg8TE3GjnyOCqaY8TyuP0cyqG1eKAMKH45AVXSdiTe7uBeuIYtU3cF0dtB9 fqog== X-Gm-Message-State: AMke39ka5NZTRqVkslt3okz0TW9Oeamd5MAzUTHOWCV4wPoB3S7yOZqbcxnmpnN9KqjgDUvLM3++ZcE8ad1mmw== X-Received: by 10.157.47.234 with SMTP id b39mr10097460otd.0.1486545504350; Wed, 08 Feb 2017 01:18:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.221.71 with HTTP; Wed, 8 Feb 2017 01:18:24 -0800 (PST) In-Reply-To: <53687A6E-9B54-4EF7-B19E-09541DDD109C@cs.huji.ac.il> References: <53687A6E-9B54-4EF7-B19E-09541DDD109C@cs.huji.ac.il> From: Ganbold Tsagaankhuu Date: Wed, 8 Feb 2017 17:18:24 +0800 Message-ID: Subject: Re: nanopi and usb not working To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 09:18:25 -0000 On Wed, Feb 8, 2017 at 4:56 PM, Daniel Braniss wrote: > Hi, > I am beginning to wonder if my board has a broken usb, since no matter what > I plug in it gives error: > > usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_IOERROR > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_IOERROR > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_IOERROR > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_IOERROR > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_IOERROR > ugen1.2: at usbus1 (disconnected) > uhub_reattach_port: could not allocate new device > > BTW, this is with current, and nanopi-neo.dts but orange-pi u-boot. > Better use u-boot for nanopi neo: https://github.com/jaredmcneill/freebsd-ports/tree/u-boot-nanopi-neo/sysutils/u-boot-nanopi-neo Or you can try my image: https://people.freebsd.org/~ganbold/FreeBSD-armv6-12.0-nanopi-neo.img.xz Ganbold > anyone has a working usb? > > cheers, > danny > > _______________________________________________ > 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 Wed Feb 8 09:42:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EAF9CD5B9F for ; Wed, 8 Feb 2017 09:42:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6B8D7C for ; Wed, 8 Feb 2017 09:42:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 26E45CD5B9E; Wed, 8 Feb 2017 09:42:01 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26904CD5B9D for ; Wed, 8 Feb 2017 09:42:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 D74B8D79 for ; Wed, 8 Feb 2017 09:42:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from sgi-2.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cbOlB-000N7b-9A; Wed, 08 Feb 2017 11:41:57 +0200 From: Daniel Braniss Message-Id: <6D43ACDB-FAEA-4DAE-B02F-4E80C45D8111@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: nanopi and usb not working Date: Wed, 8 Feb 2017 11:41:57 +0200 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: Ganbold Tsagaankhuu References: <53687A6E-9B54-4EF7-B19E-09541DDD109C@cs.huji.ac.il> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 09:42:01 -0000 > On 8 Feb 2017, at 11:18, Ganbold Tsagaankhuu = wrote: >=20 >=20 >=20 > On Wed, Feb 8, 2017 at 4:56 PM, Daniel Braniss > wrote: > Hi, > I am beginning to wonder if my board has a broken usb, since no matter = what > I plug in it gives error: >=20 > usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_IOERROR, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_IOERROR > ugen1.2: at usbus1 (disconnected) > uhub_reattach_port: could not allocate new device >=20 > BTW, this is with current, and nanopi-neo.dts but orange-pi u-boot. >=20 > Better use u-boot for nanopi neo: >=20 > = https://github.com/jaredmcneill/freebsd-ports/tree/u-boot-nanopi-neo/sysut= ils/u-boot-nanopi-neo = >=20 the patches no longer apply :-( > Or you can try my image: >=20 > = https://people.freebsd.org/~ganbold/FreeBSD-armv6-12.0-nanopi-neo.img.xz = = that one worked! I will =E2=80=98borrow' the u-boot & dtb from it. BTW, I used your spigen to drive an ssd1331 oled 96rgbx64 display! >=20 > Ganbold >=20 >=20 > anyone has a working usb? >=20 > cheers, > danny >=20 > _______________________________________________ > 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 Wed Feb 8 13:12:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18D07CD62AE for ; Wed, 8 Feb 2017 13:12:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (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 D56E0F2B for ; Wed, 8 Feb 2017 13:12:00 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cbS2P-00017m-6N for freebsd-arm@freebsd.org; Wed, 08 Feb 2017 14:11:57 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Subject: Fwd: Re: svn commit: r313343 - head/sys/arm/arm References: <201702061458.v16EwOjU015633@repo.freebsd.org> <27DC1078-9C59-4B6C-A9CF-9E6D246F7366@FreeBSD.org> Date: Wed, 08 Feb 2017 14:11:56 +0100 To: "FreeBSD ARM" MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <27DC1078-9C59-4B6C-A9CF-9E6D246F7366@FreeBSD.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 27b922e39ba943ef41a3b4c3f0284049 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:12:01 -0000 Hello, I'm not a commiter. so what do other think about this on 11-CURRENT? --- sys/arm/arm/identcpu.c (revision 313193) +++ sys/arm/arm/identcpu.c (working copy) @@ -386,8 +386,8 @@ void identify_arm_cpu(void) { - u_int cpuid, reg, size, sets, ways; - u_int8_t type, linesize, ctrl; + u_int cpuid, reg, size, sets, ways, ctrl; + u_int8_t type, linesize; int i; ctrl =3D cpu_get_control(); I'm currently compiling this and will try to install in a couple of hour= s = (or days :-) ) Regards, Ronald. ------- Forwarded message ------- From: "Stanislav Galabov" To: "Ronald Klop" Cc: "Stanislav Galabov" , = src-committers@freebsd.org, svn-src-all@freebsd.org, = svn-src-head@freebsd.org Subject: Re: svn commit: r313343 - head/sys/arm/arm Date: Wed, 08 Feb 2017 14:01:46 +0100 Hi, I hadn=E2=80=99t looked at 11-CURRENT to be honest, but looking at it - = yes, it seems is applicable there too. Unfortunately I am not certain I=E2=80=99ll have time to MFC this, so if= anyone wants to/has the time - please be my guest. Best wishes, Stanislav > On Feb 8, 2017, at 14:58, Ronald Klop wrote: > > Hello, > > Is this applicable to 11-CURRENT also? > > That version (sys/arm/arm/identcpu.c) has: > void > identify_arm_cpu(void) > { > u_int cpuid, reg, size, sets, ways; > u_int8_t type, linesize, ctrl; > int i; > > Regards, > Ronald. > > > On Mon, 06 Feb 2017 15:58:24 +0100, Stanislav Galabov = > wrote: > >> Author: sgalabov >> Date: Mon Feb 6 14:58:24 2017 >> New Revision: 313343 >> URL: https://svnweb.freebsd.org/changeset/base/313343 >> >> Log: >> sys/arm/arm/identcpu-v4.c: fix identify_arm_cpu() >> identify_arm_cpu() in sys/arm/arm/identcpu-v4.c incorrectly uses a >> u_int8_t variable to store the result of cpu_get_control(). >> It should really use a u_int variable, the same way as done for = >> cpu_ident() >> in the same function, as both cpuid and control registers are 32-bit= .. >> This issue causes users of identcpu-v4 to incorrectly report things = = >> such as >> icache status (bit 12 in cpu control register) and basically anythin= g >> defined in bits above bit 7 :-) >> Reviewed by: manu >> Sponsored by: Smartcom - Bulgaria AD >> Differential Revision: https://reviews.freebsd.org/D9460 >> >> Modified: >> head/sys/arm/arm/identcpu-v4.c >> >> Modified: head/sys/arm/arm/identcpu-v4.c >> =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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> --- head/sys/arm/arm/identcpu-v4.c Mon Feb 6 14:41:34 2017 (r313342)= >> +++ head/sys/arm/arm/identcpu-v4.c Mon Feb 6 14:58:24 2017 (r313343)= >> @@ -294,8 +294,7 @@ u_int cpu_pfr(int num) >> void >> identify_arm_cpu(void) >> { >> - u_int cpuid; >> - u_int8_t ctrl; >> + u_int cpuid, ctrl; >> int i; >> ctrl =3D cpu_get_control(); >> _______________________________________________ >> svn-src-all@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/svn-src-all >> To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org= " From owner-freebsd-arm@freebsd.org Wed Feb 8 14:41:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F341CD6DA4 for ; Wed, 8 Feb 2017 14:41:26 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 16AE9768 for ; Wed, 8 Feb 2017 14:41:25 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 867B111F509 for ; Wed, 8 Feb 2017 08:41:24 -0600 (CST) Subject: Re: Crochet produces boom-boom build To: freebsd-arm@freebsd.org References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> <20170207183333.GA65714@night.db.net> <3587bf6c-ba2e-dab6-cc66-0ac1cdf4b27c@denninger.net> From: Karl Denninger Message-ID: <3d9adfff-3005-4c63-bc40-00745cbef01b@denninger.net> Date: Wed, 8 Feb 2017 08:41:22 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3587bf6c-ba2e-dab6-cc66-0ac1cdf4b27c@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020906010002090900020509" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:41:26 -0000 This is a cryptographically signed message in MIME format. --------------ms020906010002090900020509 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/7/2017 15:36, Karl Denninger wrote: > On 2/7/2017 12:33, Diane Bruce wrote: >> On Tue, Feb 07, 2017 at 11:28:36AM -0600, Karl Denninger wrote: >>> On 2/7/2017 11:26, Diane Bruce wrote: >>>> On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote: >>> Uh, that is a cold boot. Brad's image, which appears (at first blush= ) >>> to be built with defaults (which I used as well here) comes up and ru= ns >>> the kernel is starting up (all CPUs start and run, etc.) >> Then you are missing armstub8.bin in the dos portion of the sd card. >> The latest crotchet and u-boot-rpi3.bin port will install these. > I think the path is to figure out is why /boot/loader.efi blows up, > given that armstub8.bin IS present and is being installed -- and my > Crochet git grab was yesterday (last change visible appears to be 5 day= s > old.) > > RPi3 PSCI monitor installed > > > U-Boot 2017.01 (Feb 07 2017 - 14:26:16 -0600) > > DRAM: 944 MiB > RPI 3 Model B (0xa22082) > MMC: bcm2835_sdhci: 0 > reading uboot.env > > ** Unable to read "uboot.env" from mmc0:1 ** > Using default environment > > In: serial > Out: lcd > Err: lcd > Net: Net Initialization Skipped > No ethernet found. > starting USB... > USB0: Core Release: 2.80a > scanning bus 0 for devices... 3 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > scanning usb for ethernet devices... 1 Ethernet Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > reading efi/boot/bootaa64.efi > 81472 bytes read in 28 ms (2.8 MiB/s) > ## Starting EFI application at 01000000 ... > Scanning disks on usb... > Scanning disks on mmc... > Adding logical partition > Adding logical partition > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 7 disks > > >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: ZFS UFS > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console > Command line arguments: loader.efi > Image base: 0x379b8008 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Tue Feb 7 15:15:52 CST 2017 freebsd@NewFS.denninger.net) > Failed to start image provided by UFS (14) > "Synchronous Abort" handler, esr 0x96000004 > ELR: 3af62cec > LR: 3af61d60 > x0 : 0000000000000001 x1 : 0000000000000001 > x2 : 000000003afeb000 x3 : 000000000000003f > x4 : 0000000000000020 x5 : 0000000000000010 > x6 : 0000000000000000 x7 : 0000000039b260a4 > x8 : 000000003af61d48 x9 : 000000000000000d > x10: 0000000000000030 x11: 0000000000000000 > x12: 0000000000000000 x13: 0000000000000002 > x14: 0000000000000000 x15: 0000000000000000 > x16: 0000000000000000 x17: 0000000000000000 > x18: 000000003ab30df8 x19: 0000000037a16008 > x20: 0000000000000000 x21: 0000000000000000 > x22: 0000000039b28000 x23: 0000000039b1d49c > x24: 0000000039b28850 x25: 000000003ab3d740 > x26: 000000003af839a0 x27: 0000000039b2e3e8 > x28: 0000000000000000 x29: 000000003ab2ef60 > > Resetting CPU ... > > resetting ... > > That's what I get off a clean build (just re-built/reinstalled the > u-boot-rpi3 port, just to be sure, then re-ran Crochet.) I can replace > /boot/loader.efi with the "working" one from Brad's build -- which is > NOT of the same size (say much less checksum) -- but I suspect whatever= > is producing the bad code in /boot/loader.efi is also producing the bad= > code in the rest of the build.... so fixing the first one should fix th= e > second. > > What are you building Crochet'd builds for the Pi3 on and what versions= > of aarch64-* do you have on your system? The clue may lie there. I am= > building on: > > FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 > karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP > The build that runs (and which was uploaded to rasperian by Brad) is: FreeBSD 12.0-CURRENT #0 r313109M: Thu Feb 2 16:16:39 MST 2017 =20 raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarc= h64/usr/src/sys/GENERIC Note the "M", so local mods (not in the public repo) appear to be in the kernel source tree. r313441 (updated a short while ago, but none of the changes since yesterday appear to touch files that are specific to the ARM architectures) does not produce a working build here and I've re-installed both the u-boot port and the crossbuild components just to make sure I've got the current versions. My cross-build tools are also at what appear to be current revisions from what I'm able to discern. root@NewFS:/usr/ports/devel/aarch64-binutils # pkg info|grep aarch aarch64-binutils-2.27_5,1 GNU binutils for AArch64 cross-development= aarch64-none-elf-binutils-2.27_5,1 GNU binutils for bare metal AArch64 cross-development aarch64-none-elf-gcc-6.3.0 Cross GNU Compiler Collection for aarch64noneelf Since there are local revisions I assume that reverting to 313109 is unlikely to produce joy without either knowing at what rev those were committed or having them here, or if there's an issue with the crossbuild versions that are "latest available publicly." --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020906010002090900020509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDgxNDQxMjJaME8GCSqGSIb3DQEJBDFCBEB5wJ1A IaJW0iR+jCb2W4RCY60zw1aqvE8MOCvq2ZRCUhilUXDAQwvf7q2/Fc+Epz/Ql/C6khN1ZFpO TOPX8uniMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAkqdWCo48lklE 5AhPHqdXcPkcnqI9dfCoA9OOdjcFxE9nx7LE72BDHL2wslqw+ca6KRfenMbfhdSuM9jrvH8n 6ei9ydsRFx06oXJP+Jz5zBvQE8FeojF13ekh29i74o4fNnjZ8hXKVzutou9Tc4U8Ufn6yCkN gUvxluDrglsQknWYgvKgV29etnDO91CE+2FyxjWfqrX0nu94/nTJepZkVQOjyXCZKmMPpsrk Jb7j5nD3gChpZemmRP+lsVGC70TPEGFTkSD02agAF4vtKSCd5kqI9BgPnl8YIADvFn5al2xF 7Gtv9FgI70U3PoDRgFtXFUlwd8U9hPGPbPQnRL7CAPN76nH/+Yjw+Z7/WG3NHTS7JsI+TPqD CZkU9Nq3N33q0Ag6sh5UpwcOcE4m9kb3GfvJyTBR0VyqQFys1uc2U26KiHeGp9jg+F4ZX4ZQ 4PuiZHP9IGC+ELEgkV/De/gPDJWiNSJgOPTq2lhiKAbUdTkUUcll+UoxldURh1FHp+o6zcmY ThUmNU2Yio0Ur2vyx4ez2hZ3732rbj0sbzwowCaqVWRHp54qm2zFL7FOA5O7XXV58w8mQGJL Vqm9x7bctmMkYsy65jCENW/OF3ZkXiRYhEWrfwpfrbSJhL2Ai1ApH3g9fr0CvzFAtXCIFa8F r+TVFHs6GpF1eOaMcPe6u+sAAAAAAAA= --------------ms020906010002090900020509-- From owner-freebsd-arm@freebsd.org Wed Feb 8 18:38:12 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4031ECD6B14 for ; Wed, 8 Feb 2017 18:38:12 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id C497D1447 for ; Wed, 8 Feb 2017 18:38:11 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id EAE9C122EE3 for ; Wed, 8 Feb 2017 12:38:10 -0600 (CST) Subject: Re: Crochet produces boom-boom build To: freebsd-arm@freebsd.org References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> <20170207183333.GA65714@night.db.net> <3587bf6c-ba2e-dab6-cc66-0ac1cdf4b27c@denninger.net> <3d9adfff-3005-4c63-bc40-00745cbef01b@denninger.net> From: Karl Denninger Message-ID: <47cbca0e-69f7-f2d8-391f-436eb124a561@denninger.net> Date: Wed, 8 Feb 2017 12:38:08 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3d9adfff-3005-4c63-bc40-00745cbef01b@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070109040805090403000000" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 18:38:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070109040805090403000000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/8/2017 08:41, Karl Denninger wrote: > On 2/7/2017 15:36, Karl Denninger wrote: >> On 2/7/2017 12:33, Diane Bruce wrote: >>> On Tue, Feb 07, 2017 at 11:28:36AM -0600, Karl Denninger wrote: >>>> On 2/7/2017 11:26, Diane Bruce wrote: >>>>> On Tue, Feb 07, 2017 at 11:10:32AM -0600, Karl Denninger wrote: >>>> Uh, that is a cold boot. Brad's image, which appears (at first blus= h) >>>> to be built with defaults (which I used as well here) comes up and r= uns >>>> the kernel is starting up (all CPUs start and run, etc.) >>> Then you are missing armstub8.bin in the dos portion of the sd card. >>> The latest crotchet and u-boot-rpi3.bin port will install these. >> I think the path is to figure out is why /boot/loader.efi blows up, >> given that armstub8.bin IS present and is being installed -- and my >> Crochet git grab was yesterday (last change visible appears to be 5 da= ys >> old.) >> >> RPi3 PSCI monitor installed >> >> >> U-Boot 2017.01 (Feb 07 2017 - 14:26:16 -0600) >> >> DRAM: 944 MiB >> RPI 3 Model B (0xa22082) >> MMC: bcm2835_sdhci: 0 >> reading uboot.env >> >> ** Unable to read "uboot.env" from mmc0:1 ** >> Using default environment >> >> In: serial >> Out: lcd >> Err: lcd >> Net: Net Initialization Skipped >> No ethernet found. >> starting USB... >> USB0: Core Release: 2.80a >> scanning bus 0 for devices... 3 USB Device(s) found >> scanning usb for storage devices... 0 Storage Device(s) found >> scanning usb for ethernet devices... 1 Ethernet Device(s) found= >> Hit any key to stop autoboot: 0 >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >> Found EFI removable media binary efi/boot/bootaa64.efi >> reading efi/boot/bootaa64.efi >> 81472 bytes read in 28 ms (2.8 MiB/s) >> ## Starting EFI application at 01000000 ... >> Scanning disks on usb... >> Scanning disks on mmc... >> Adding logical partition >> Adding logical partition >> MMC Device 1 not found >> MMC Device 2 not found >> MMC Device 3 not found >> Found 7 disks >> >> >>>> FreeBSD EFI boot block >> Loader path: /boot/loader.efi >> >> Initializing modules: ZFS UFS >> Probing 3 block devices.....* done >> ZFS found no pools >> UFS found 1 partition >> Consoles: EFI console >> Command line arguments: loader.efi >> Image base: 0x379b8008 >> EFI version: 2.05 >> EFI Firmware: Das U-boot (rev 0.00) >> >> FreeBSD/arm64 EFI loader, Revision 1.1 >> (Tue Feb 7 15:15:52 CST 2017 freebsd@NewFS.denninger.net) >> Failed to start image provided by UFS (14) >> "Synchronous Abort" handler, esr 0x96000004 >> ELR: 3af62cec >> LR: 3af61d60 >> x0 : 0000000000000001 x1 : 0000000000000001 >> x2 : 000000003afeb000 x3 : 000000000000003f >> x4 : 0000000000000020 x5 : 0000000000000010 >> x6 : 0000000000000000 x7 : 0000000039b260a4 >> x8 : 000000003af61d48 x9 : 000000000000000d >> x10: 0000000000000030 x11: 0000000000000000 >> x12: 0000000000000000 x13: 0000000000000002 >> x14: 0000000000000000 x15: 0000000000000000 >> x16: 0000000000000000 x17: 0000000000000000 >> x18: 000000003ab30df8 x19: 0000000037a16008 >> x20: 0000000000000000 x21: 0000000000000000 >> x22: 0000000039b28000 x23: 0000000039b1d49c >> x24: 0000000039b28850 x25: 000000003ab3d740 >> x26: 000000003af839a0 x27: 0000000039b2e3e8 >> x28: 0000000000000000 x29: 000000003ab2ef60 >> >> Resetting CPU ... >> >> resetting ... >> >> That's what I get off a clean build (just re-built/reinstalled the >> u-boot-rpi3 port, just to be sure, then re-ran Crochet.) I can replace= >> /boot/loader.efi with the "working" one from Brad's build -- which is >> NOT of the same size (say much less checksum) -- but I suspect whateve= r >> is producing the bad code in /boot/loader.efi is also producing the ba= d >> code in the rest of the build.... so fixing the first one should fix t= he >> second. >> >> What are you building Crochet'd builds for the Pi3 on and what version= s >> of aarch64-* do you have on your system? The clue may lie there. I a= m >> building on: >> >> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 >> karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP >> > The build that runs (and which was uploaded to rasperian by Brad) is: > > FreeBSD 12.0-CURRENT #0 r313109M: Thu Feb 2 16:16:39 MST 2017 =20 > raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aa= rch64/usr/src/sys/GENERIC > > Note the "M", so local mods (not in the public repo) appear to be in th= e > kernel source tree. > > r313441 (updated a short while ago, but none of the changes since > yesterday appear to touch files that are specific to the ARM > architectures) does not produce a working build here and I've > re-installed both the u-boot port and the crossbuild components just to= > make sure I've got the current versions. My cross-build tools are also > at what appear to be current revisions from what I'm able to discern. > > root@NewFS:/usr/ports/devel/aarch64-binutils # pkg info|grep aarch > aarch64-binutils-2.27_5,1 GNU binutils for AArch64 cross-developme= nt > aarch64-none-elf-binutils-2.27_5,1 GNU binutils for bare metal AArch64 > cross-development > aarch64-none-elf-gcc-6.3.0 Cross GNU Compiler Collection for > aarch64noneelf > > Since there are local revisions I assume that reverting to 313109 is > unlikely to produce joy without either knowing at what rev those were > committed or having them here, or if there's an issue with the > crossbuild versions that are "latest available publicly." > More data..... Reverting my HEAD tree to r313109 produces a build that boots..... RPi3 PSCI monitor installed U-Boot 2017.01 (Feb 07 2017 - 14:26:16 -0600) DRAM: 944 MiB RPI 3 Model B (0xa22082) MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 81472 bytes read in 28 ms (2.8 MiB/s) ## Starting EFI application at 01000000 ... Scanning disks on usb... Scanning disks on mmc... Adding logical partition Adding logical partition MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 7 disks >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console Command line arguments: loader.efi Image base: 0x379b9008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Wed Feb 8 11:56:55 CST 2017 freebsd@NewFS.denninger.net) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x77fd38 data=3D0x9fc68+0x43b328 syms=3D[0x8+0x104e80+0x8+0xbe4a6] /boot/kernel/geom_label.ko text=3D0x5d40 data=3D0xe90+0x8 syms=3D[0x8+0x1638+0x8+0xbe8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 4 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot Booting... Using DTB provided by EFI at 0x8004000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 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 12.0-CURRENT #0 r313109: Wed Feb 8 11:56:46 CST 2017 =20 freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm64.aarch64/pics/Cro= ssBuild-12/src/sys/GENERIC arm64 FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. can't re-use a leaf (geom_label)! module_register: cannot register g_label from kernel; already loaded from geom_label.ko Module g_label failed to register: 17 Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 ofw_clkbus0: on ofwbus0 clk_fixed0: on ofw_clkbus0 clk_fixed1: on ofw_clkbus0 clk_fixed2: on ofw_clkbus0 clk_fixed3: on ofw_clkbus0 clk_fixed4: on ofw_clkbus0 clk_fixed5: on ofw_clkbus0 clk_fixed6: on ofw_clkbus0 psci0: on ofwbus0 local_intc0: mem 0x40000000-0x400000ff on simplebus0 intc0: mem 0x7e00b200-0x7e00b3ff irq 16 on simplebus0 generic_timer0: irq 37,38,39,40 on simplebus0 Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 bcm_dma0: mem 0x7e007000-0x7e007eff irq 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 on simplebus0 mbox0: mem 0x7e00b880-0x7e00b8bf irq 17 on simplebus0 bcmwd0: mem 0x7e100000-0x7e100027 on simplebus0 gpio0: mem 0x7e200000-0x7e2000b3 irq 18,19 on simplebus0 gpiobus0: on gpio0 gpioc0: on gpio0 uart0: mem 0x7e201000-0x7e201fff irq 20 on simplebus0 uart0: console (115200,n,8,1) spi0: mem 0x7e204000-0x7e204fff irq 22 on simplebus0 spibus0: on spi0 spibus0: at cs 0 mode 0 spibus0: at cs 1 mode 0 sdhci_bcm0: mem 0x7e300000-0x7e3000ff irq 27 on simplebus0 mmc0: on sdhci_bcm0 iichb0: mem 0x7e804000-0x7e804fff irq 31 on simplebus0 iicbus0: on iichb0 bcm283x_dwcotg0: mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 33,34 on simplebus0 usbus0 on bcm283x_dwcotg0 gpioled0: on simplebus0 gpioled0: failed to map pin fb0: on simplebus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x3db33000, screen_size 818688 pmu0: irq 36 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cryptosoft0: Timecounters tick every 1.000 msec The GEOM class LABEL is already loaded. usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 32GB at mmc0 41.6MHz/4bit/65535-block bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF Release APs CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k Granule,MixedEndian,S/N= S Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... warning: no time-of-day clock registered, system time will not be set accurately uhub0: 1 port with 1 removable, self powered Growing root partition to fill device GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them. ugen0.2: at usbus0 uhub1 on uhub0 uhub1: on usbus0 mcsuhub1: MTT enabled d0s2 resized mmcsd0s2a resized super-block backups (for fsck_ffs -b #) at: 3802304, 4752832, 5703360, 6653888, 7604416, 8554944, 9505472, 10456000,= 11406528, 12357056, 13307584, 14258112, 15208640, 16159168, 17109696, 18060224, 19010752, 19961280, 20911808, 21862336, 22812864, 23763392, 24713920, 25664448, 26614976, 27565504, 28516032, 29466560, 30417088, 31367616, 32318144, 33268672, 34219200, 35169728, 36120256, 37070784, 38021312, 38971840, 39922368, 40872896, 41823424, 42773952, 43724480,uhub1: 5 ports with 4 removable, self powered 44675008, 45625536, 46576064, 47526592, 48477120, 49427648, 50378176, 51328704, 52279232, 53229760, 54180288, 55130816, 56081344, 57031872, 57982400, 58932928, 59883456, 60833984, 61784512 ugen0.3: at usbus0 smsc0 on uhub1 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 smscphy0: PHY 1 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:4e:88:64 Setting hostuuid: 30303030-3030-3030-3331-346538383634. Setting hostid: 0x968824d5. No suitable dump device was found. Starting file system checks: /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s2a: clean, 7269925 free (269 frags, 908707 blocks, 0.0% fragmentation) lock order reversal: 1st 0xffff000053234db0 bufwait (bufwait) @ /pics/CrossBuild-12/src/sys/kern/vfs_bio.c:3500 2nd 0xfffffd0001a23000 dirhash (dirhash) @ /pics/CrossBuild-12/src/sys/ufs/ufs/ufs_dirhash.c:281 stack backtrace: #0 0xffff000000352bb8 at witness_debugger+0x64 #1 0xffff0000002ff734 at _sx_xlock+0x6c #2 0xffff00000055a480 at ufsdirhash_move+0x40 #3 0xffff00000055c658 at ufs_direnter+0x2ac #4 0xffff000000564a74 at ufs_makeinode+0x464 #5 0xffff000000561240 at ufs_create+0x3c #6 0xffff0000005edc94 at VOP_CREATE_APV+0xc4 #7 0xffff0000003bda8c at vn_open_cred+0x284 #8 0xffff0000003b7640 at kern_openat+0x1d4 #9 0xffff0000005d2434 at do_el0_sync+0x4c8 #10 0xffff0000005bc1d0 at handle_el0_sync+0x64 lock order reversal: 1st 0xfffffd00019b15f0 ufs (ufs) @ /pics/CrossBuild-12/src/sys/kern/vfs_subr.c:2600 2nd 0xffff000053234db0 bufwait (bufwait) @ /pics/CrossBuild-12/src/sys/ufs/ffs/ffs_vnops.c:280 3rd 0xfffffd0001a439a0 ufs (ufs) @ /pics/CrossBuild-12/src/sys/kern/vfs_subr.c:2600 stack backtrace: #0 0xffff000000352bb8 at witness_debugger+0x64 #1 0xffff0000002d25a8 at __lockmgr_args+0x57c #2 0xffff0000005555a4 at ffs_lock+0x88 #3 0xffff0000005f074c at VOP_LOCK1_APV+0xc4 #4 0xffff0000003be140 at _vn_lock+0x8c #5 0xffff0000003afb18 at vget+0x58 #6 0xffff0000003a2b28 at vfs_hash_get+0xf0 #7 0xffff000000551988 at ffs_vgetf+0x44 #8 0xffff000000548bf8 at softdep_sync_buf+0x910 #9 0xffff000000556104 at ffs_syncvnode+0x274 #10 0xffff000000531544 at ffs_truncate+0x624 #11 0xffff00000055cafc at ufs_direnter+0x750 #12 0xffff000000564a74 at ufs_makeinode+0x464 #13 0xffff000000561240 at ufs_create+0x3c #14 0xffff0000005edc94 at VOP_CREATE_APV+0xc4 #15 0xffff0000003bda8c at vn_open_cred+0x284 #16 0xffff0000003b7640 at kern_openat+0x1d4 #17 0xffff0000005d2434 at do_el0_sync+0x4c8 Mounting local filesystems:random: unblocking device. =2E ELF ldconfig path: /lib /usr/lib /usr/lib/compat Setting hostname: rpi3. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,AT= TACH,CACHED Feeding entropy: . smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 ue0: flags=3D8843 metric 0 mtu 15= 00 options=3D80009 ether b8:27:eb:4e:88:64 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 Starting devd. Starting dhclient. DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.1.200 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.200 bound to 192.168.1.17 -- renewal in 21600 seconds. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Creating and/or trimming log files. Starting syslogd. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting powerd. Configuring vt: blanktime. Generating RSA host key. 2048 SHA256:4OPSazKNHZ6zC6S0C8RebMUlcZn6flcUxmv/m2XaVEA root@rpi3 (RSA) Generating ECDSA host key. 256 SHA256:HNYLFTCAaR3s1pS2fUAFbhBR3tkDfHzCx0IoLPjqNsk root@rpi3 (ECDSA) Generating ED25519 host key. 256 SHA256:CV90hBgQwZcL3smwgJ8KsXQ4KPtYLmHcIIAlpclbJpI root@rpi3 (ED25519= ) Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. mount: /dev/mmcsd0s2a: Device busy Wed Feb 8 18:06:16 UTC 2017 FreeBSD/arm64 (rpi3) (ttyu0) login: So now I have more questions: 1. What got broken between 313109 and 313441? There has to be more than one problem for the Pi3 because -HEAD not only blows up in /boot/loader.efi but *also* the running system that is produced (since if I replace /boot/loader.efi with a working copy I wind up with a panic before the system finishes starting up, so the damage isn't limited to sys/boot/efi). 2. I assume the patch on the previous is responsible for silencing the lock-order-reversal complaint in the uploaded image. Maybe. Probably, actually, since I get a complaint after signing in even after the first boot (where growfs runs) but don't on the pre-built image. There isn't much that's been changed in the loader that looks like it could bear on this -- the interesting change might be in r313442 although I don't see why a test for NULL (which is the only change in there) would result in the problem. I'm going to start stepping forward in the loader until I get the crash, and take it from there unless one of the committers knows what went wrong. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070109040805090403000000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDgxODM4MDhaME8GCSqGSIb3DQEJBDFCBEC5UbYx LaT78U2BbQ5truLrRGhSggcILiLGdBE7vPmO+nQ90dAxFcP8UR3KXhCp7vz491/K3Tu+YIFv A6QD5fJiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAVvcwQRoC4i+n geh1RlQxIXv+H1mo1pWLvpL3/4GsuWrwnHVuPFiRhdr5adSOjYULFpylAdjy7sTkbraU/Go+ wX4rF/PAJ74dx4LE4FZC1bjbULwhELygKuUmq2P4OqMdcdBP7kej3XD6HPthiQe+bJ6aRgbk c/bFERJUsHJO6x4DLLJWIlFKt9YATf4BO+qLcmc2hEBzyd8E7YYLDDS0y65dK0HJpZKmNCuI q7HXOpheW9wF8BJJ6QAhqE/JLjJwyC9HpWCYbKosbBgWWh+LY4sHAzzoxHtRHQcgaGhE19EK zG7+fvsKd/aIdOjObY81hG6lUFgFWT1LmILomkOg99xUc6p7Gzk7/w6LXfqOLJn2KL4c9E0Y bCYriO7hAh3bCaZNmf6Tw/TRvzE9VTyj84RkGOXddaVdjRvaVl5rChDnuQhkLQ9jbzGq+K7R yg6CsPOWUkrOnsAdnaftlQr6stAPccj6lUGmq0N8gfjrPpL6ScF1dUnkqAjCJk3CMmN971J1 Tr3qCDsyJ4cPLWyKWCccoi/U2RiYwWlpxK/HRB5UoddWcbK1vjkcOhibvV+M1cxNob0OD2Mk CyZ394n0hFaSG2gKtb+CSPLb4qYrhOxlfQ3IJkPekgchVDbvAoQvcG+GdKQjFEEZ/8BT0oSm 4yqQ6UTAXvstiBFIY7GfZx4AAAAAAAA= --------------ms070109040805090403000000-- From owner-freebsd-arm@freebsd.org Wed Feb 8 21:36:18 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E5EBCD6813 for ; Wed, 8 Feb 2017 21:36:18 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 08DBE11B8 for ; Wed, 8 Feb 2017 21:36:17 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id DED94123B0D for ; Wed, 8 Feb 2017 15:36:16 -0600 (CST) Subject: Re: Crochet produces boom-boom build To: freebsd-arm@freebsd.org References: <3ba56367-aa16-4af9-2479-44ccfee4d11e@denninger.net> <20170207172617.GA64935@night.db.net> <77b08492-e9fa-329f-abcb-205ba75b4119@denninger.net> <20170207183333.GA65714@night.db.net> <3587bf6c-ba2e-dab6-cc66-0ac1cdf4b27c@denninger.net> <3d9adfff-3005-4c63-bc40-00745cbef01b@denninger.net> <47cbca0e-69f7-f2d8-391f-436eb124a561@denninger.net> From: Karl Denninger Message-ID: Date: Wed, 8 Feb 2017 15:36:14 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <47cbca0e-69f7-f2d8-391f-436eb124a561@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010707060506000105090902" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:36:18 -0000 This is a cryptographically signed message in MIME format. --------------ms010707060506000105090902 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/8/2017 12:38, Karl Denninger wrote: > So now I have more questions: > > 1. What got broken between 313109 and 313441? There has to be more tha= n > one problem for the Pi3 because -HEAD not only blows up in > /boot/loader.efi but *also* the running system that is produced (since > if I replace /boot/loader.efi with a working copy I wind up with a pani= c > before the system finishes starting up, so the damage isn't limited to > sys/boot/efi). > > 2. I assume the patch on the previous is responsible for silencing the > lock-order-reversal complaint in the uploaded image. Maybe. Probably,= > actually, since I get a complaint after signing in even after the first= > boot (where growfs runs) but don't on the pre-built image. > > There isn't much that's been changed in the loader that looks like it > could bear on this -- the interesting change might be in r313442 > although I don't see why a test for NULL (which is the only change in > there) would result in the problem. I'm going to start stepping forwar= d > in the loader until I get the crash, and take it from there unless one > of the committers knows what went wrong. > BTW whatever it is that is causing this is local to the RPI3 (or at least machines of the same architecture); I just completed a Crochet build for the Pi2 from -HEAD and it boots and runs fine, other than emitting "lock order reversal" warnings. I'm going to revert JUST the loader directory to 313109, rebuild for the Pi3, and see what happens. There are not many revs to the arm64 CPU-dependent code between 313109 and 313441; if I get panics out of the kernel with the loader reverted, but not the rest of the tree, then I'll revert the arm64 code back to 313109 and see if it stops them. This may take a while since I've yet to figure out the magic to get just the kernel to rebuild on changes (without wiping the entire work directory) so it's ~1 hour or so a crack per test. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010707060506000105090902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDgyMTM2MTRaME8GCSqGSIb3DQEJBDFCBEA9BUcH piPXZZqwu6kXKRD4OWUct64kQspUXq4IdvYnJp4kUPwZvSr6qurVYIMYym+MvsCphyKEoDt3 mNTmMt+SMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAa/lTglW5nnAi PY8YrAtdIxZ/+qBbaB+e9eRnGUur2D3RRg66Pu+eg2U18wW7RADryVxkM69GtFz2AZeU3Sf7 NFTQMpbP1l5ZTzmNMs3JWX4O1VpRzuPr0r9VYRUx/CPFCBiDCfsqmXocLnNq6IYZkdZ21JhF wOWA0v0jKT4jn9f0LJnNUsHLOn4a27oGdyoO/1nqC2nIa+S4EZ/7zK16kUES6TKORFY7+MLC +2xrajTfI2uWK5lJN2G+FwoWUHJvSoYfB1xPrTDElUJchDLs2nlp4S03qSenGCAfqgJrfTuG 5MuwA1W4qaNGoHmh4cNfO4nJEjELIuj0yKxjuiQB8/js7GJWoWWe8zN6EUro9+nINpmbY+NN NwdamoRDQ6bN6HxfJ0hwKd5qS9JUzXS15AwEkna5EeYzocbM+a7JuyuZHBlAoN5AA0/8Rf74 ZvBTg6gGxq4zyu4v/UD84PO0z7We/39kRYp3JkWkeCrI59OakP205YaOO48gu/ke+tfOsikX 4Q5Q9TuBrSNSu5DFP2c0vdLAHbaZ8acSPipp1KOvRh9wmqC05TfKH/6pVcMKy2mTvV7/d74n Ng8WZR7jzAMIgs9dJ81jDAFJvrqLb4AW8gHhFRtMB1t+jFRvefLDfaszRzmuZfpNETKfFJME bcj5eVKkqoz5ZSPTW9zf76cAAAAAAAA= --------------ms010707060506000105090902-- From owner-freebsd-arm@freebsd.org Thu Feb 9 03:22:54 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C0DDCD7048 for ; Thu, 9 Feb 2017 03:22:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CDAABE7 for ; Thu, 9 Feb 2017 03:22:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id o16so73889022wra.1 for ; Wed, 08 Feb 2017 19:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/jime3F92ULKOnwSXXzwJj2/Yk+7ZM6ygbDdqg0WzG8=; b=MEURP+gOVj+udmwI4wvmTe6i7auq4ZdRkwfCEII3elq82nPPZbgVUgaGOkkfOaX40m zZ0xQu7AmD0OQnqitnIXHwk8jt7gEfSfBuTn41qwK6UAgiHnvJROpZuU4ToUBGAcFGNA nhee7qMdxCTKg4tWK8Kk56vkGrK7KnqmS3GpNsEN7Hyvgiv9YioULk8qdp1x+LuBD72x Bg2PWHsH5GX702s4S1QsLxzqf2NNDozV26owTc85EjFz90LXkcCJV6rRrGIYHK1A+03I NjMx8csMwvqx6owft0kOuK6ZDeYDAqpWc2DTGmFOKGrbwVFalrN9LdFnZxGDWkvijSTA Ha7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/jime3F92ULKOnwSXXzwJj2/Yk+7ZM6ygbDdqg0WzG8=; b=lb41czD0HfsAGuhni7YCdIDBz0YbopTS1uJO33khfbIAr0t5TBUdkiuQzb35hCx1qT HFaY5Lcgms0C2kvd/M2/uZgt1VhTpPIB7N34TPDt+9IhAMlIHGYNiEHFy9sPKwJDw7NA sm9N0TCYCtSt5kVm9EP+ex3dJ/vp6iMiqFe5DQRPBdSZdWuDCGyts6sKVOFnB6OugzMm peg89dkX1cLavc0skE5jisulUovN8+oMmzVknFFiO3sK3pbAt534LLDrMtyY9uFshljb tbHl0/84oGnh/px5kK6xTsCV7Gfb688G1MGp5JMZn0vmrnJxERuvFsigy4+FDhkLop4v dlMA== X-Gm-Message-State: AMke39kV2QqJqFNvcvkrYO1kMOvhSHE7JP305401O3TEMZY0+VCMeNUCfXDUl4yrd/gSE/AHB5gLex7CvUQrDA== X-Received: by 10.223.169.112 with SMTP id u103mr620282wrc.166.1486610571348; Wed, 08 Feb 2017 19:22:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.82.162 with HTTP; Wed, 8 Feb 2017 19:22:50 -0800 (PST) In-Reply-To: <59508065.2X8Qo0R8aR@pc-alex> References: <2478341.4YUvIvO0Dr@pc-alex> <20170202160159.GN2092@kib.kiev.ua> <59508065.2X8Qo0R8aR@pc-alex> From: Adrian Chadd Date: Wed, 8 Feb 2017 19:22:50 -0800 Message-ID: Subject: Re: Counter API To: Alexandre Martins Cc: Konstantin Belousov , Freebsd arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 03:22:54 -0000 On 3 February 2017 at 05:03, Alexandre Martins wrote: > Hi Kontantin. > > Your patch compille and run great in a 32 bit environment. I don't have a= 64 > bit one to check. > > Thank you for your support. hm! Should this be committed to -head? -adrian > > Best regards > > Alexandre > > Le jeudi 2 f=C3=A9vrier 2017, 18:01:59 Konstantin Belousov a =C3=A9crit : >> On Thu, Feb 02, 2017 at 04:38:08PM +0100, Alexandre Martins wrote: >> > Hi all, >> > >> > Our companie is curently tracking performance issue with our ARM produ= ct. >> > >> > We have seen that counter API was migrated from intrinsic to atomic. >> > >> > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D269406 >> > >> > But there is still the calls to critical_enter/leave in the macro >> > counter_enter/leave. >> > >> > Is that needed ? Can we remove that ? >> >> Try this. I did not even compiled the patch. >> >> diff --git a/sys/arm/include/counter.h b/sys/arm/include/counter.h >> index c4da91f7a14..950516e1616 100644 >> --- a/sys/arm/include/counter.h >> +++ b/sys/arm/include/counter.h >> @@ -31,12 +31,9 @@ >> >> #include >> #include >> -#ifdef INVARIANTS >> -#include >> -#endif >> >> -#define counter_enter() critical_enter() >> -#define counter_exit() critical_exit() >> +#define counter_enter() do {} while (0) >> +#define counter_exit() do {} while (0) >> >> #ifdef IN_SUBR_COUNTER_C >> >> @@ -55,7 +52,7 @@ counter_u64_fetch_inline(uint64_t *p) >> int i; >> >> r =3D 0; >> - for (i =3D 0; i < mp_ncpus; i++) >> + CPU_FOREACH(i) >> r +=3D counter_u64_read_one((uint64_t *)p, i); >> >> return (r); >> @@ -78,18 +75,13 @@ counter_u64_zero_inline(counter_u64_t c) >> } >> #endif >> >> -#define counter_u64_add_protected(c, inc) do { \ >> - CRITICAL_ASSERT(curthread); \ >> - atomic_add_64((uint64_t *)zpcpu_get(c), (inc)); \ >> -} while (0) >> +#define counter_u64_add_protected(c, inc) counter_u64_add(c,= inc) >> >> static inline void >> counter_u64_add(counter_u64_t c, int64_t inc) >> { >> >> - counter_enter(); >> - counter_u64_add_protected(c, inc); >> - counter_exit(); >> + atomic_add_64((uint64_t *)zpcpu_get(c), inc); >> } >> >> #endif /* ! __MACHINE_COUNTER_H__ */ >> diff --git a/sys/arm64/include/counter.h b/sys/arm64/include/counter.h >> index 9d56cce3d3d..cfa521f9b73 100644 >> --- a/sys/arm64/include/counter.h >> +++ b/sys/arm64/include/counter.h >> @@ -30,12 +30,10 @@ >> #define _MACHINE_COUNTER_H_ >> >> #include >> -#ifdef INVARIANTS >> -#include >> -#endif >> +#include >> >> -#define counter_enter() critical_enter() >> -#define counter_exit() critical_exit() >> +#define counter_enter() do {} while (0) >> +#define counter_exit() do {} while (0) >> >> #ifdef IN_SUBR_COUNTER_C >> static inline uint64_t >> @@ -52,13 +50,12 @@ counter_u64_fetch_inline(uint64_t *p) >> int i; >> >> r =3D 0; >> - for (i =3D 0; i < mp_ncpus; i++) >> + CPU_FOREACH(i) >> r +=3D counter_u64_read_one((uint64_t *)p, i); >> >> return (r); >> } >> >> -/* XXXKIB might interrupt increment */ >> static void >> counter_u64_zero_one_cpu(void *arg) >> { >> @@ -76,18 +73,13 @@ counter_u64_zero_inline(counter_u64_t c) >> } >> #endif >> >> -#define counter_u64_add_protected(c, inc) do { \ >> - CRITICAL_ASSERT(curthread); \ >> - *(uint64_t *)zpcpu_get(c) +=3D (inc); \ >> -} while (0) >> +#define counter_u64_add_protected(c, inc) counter_u64_add(c,= inc) >> >> static inline void >> counter_u64_add(counter_u64_t c, int64_t inc) >> { >> >> - counter_enter(); >> - counter_u64_add_protected(c, inc); >> - counter_exit(); >> + atomic_add_64((uint64_t *)zpcpu_get(c), inc); >> } >> >> #endif /* ! _MACHINE_COUNTER_H_ */ > > -- > Alexandre Martins > STORMSHIELD > From owner-freebsd-arm@freebsd.org Thu Feb 9 05:20:32 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1FEACD7682 for ; Thu, 9 Feb 2017 05:20:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-70.reflexion.net [208.70.210.70]) (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 5E4D9298 for ; Thu, 9 Feb 2017 05:20:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20829 invoked from network); 9 Feb 2017 04:53:45 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Feb 2017 04:53:45 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Wed, 08 Feb 2017 23:53:45 -0500 (EST) Received: (qmail 9891 invoked from network); 9 Feb 2017 04:53:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Feb 2017 04:53:45 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B3FB9EC7652; Wed, 8 Feb 2017 20:53:44 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Wed, 8 Feb 2017 20:53:44 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> <7B5DF446-6740-43DE-823D-B6ECBECF0C32@dsl-only.net> <1B1EEC5E-9875-417F-9901-A66CB5885634@dsl-only.net> <25B9EBC8-147F-47C2-BC40-C449EF3AC3FE@gmail.com> To: Tom Vijlbrief , freebsd-arm In-Reply-To: <25B9EBC8-147F-47C2-BC40-C449EF3AC3FE@gmail.com> Message-Id: <71B83856-654D-4F38-894F-1DF41681F0FC@dsl-only.net> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 05:20:32 -0000 Another sh core, this one with non-zero "junk" around the sp at the core-dump gives new information. The "junk" is because the SP actually ends up in higher addressed memory than the base frame (when .rtld_start does "bl _rtld"). [Some sh core dumps have different sp relationships than this but this can and does happen.] With the below additional evidence I conclude that either the stack pointer was messed up when fork returned for the child path or shortly there after (while sh's forkshell routine was still active). Supporting details: General Purpose Registers: . . . sp =3D 0x0000ffffffffe600 The sp =3D 0x0000ffffffffe600 is rather high in memory, in fact outside the stack for what ld-elf.so.1`.rtld_start calls. . . 0xffffffffd5b0: 0x0000ffffffffd5f0 0x0000000000402f30 0xffffffffd5c0: 0x0000000000000000 0x0000000000000000 0xffffffffd5d0: 0x0000000000000000 0x0000000000000000 0xffffffffd5e0: 0x0000ffffffffd600 0x0000ffffffffd600 0xffffffffd5f0: 0x0000000000000000 0x0000000040434658 (Note: 0x0000ffffffffe600-0x1000=3D=3D0xffffffffd5f0+0x10 but other core files have widely varying distances.) For that last line: 0xffffffffd5f0: 0x0000000000000000 0x0000000040434658 (lldb) dis -s -4*4+0x0000000040434658 ld-elf.so.1`.rtld_start: 0x40434648 <+8>: sub sp, sp, #0x10 ; =3D0x10=20 0x4043464c <+12>: mov x1, sp 0x40434650 <+16>: add x2, x1, #0x8 ; =3D0x8=20 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 0x40434658 <+24>: mov x8, x0 (0x2e4c is not in the core file.) and for the other frame-pointer/lr-value pair: 0xffffffffd5b0: 0x0000ffffffffd5f0 0x0000000000402f30 (lldb) dis -s -4*4+0x0000000000402f30 sh`__start: 0x402f20 <+344>: mov w0, w21 0x402f24 <+348>: mov x1, x20 0x402f28 <+352>: mov x2, x19 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit Note: Anything higher addressed in memory than that=20 0xffffffffd5ff I'll say is "higher than the stack region" or some such phrase. Yet despite being higher than the stack region there are some stack frames also near by (also higher than the stack region). . . An area around the sp =3D 0x0000ffffffffe600 that lldb reported for this core (with some notes used later): . . . 0xffffffffe400: 0x6572662d6e776f6e 0x302e323164736265 0xffffffffe410: 0x56454c454b414d00 0x42494c00323d4c45 0xffffffffe420: 0x403d434e49464c45 0x6e69666c6562696c 0xffffffffe430: 0x4f465f444c004063 0x5445475241545f52 0xffffffffe440: 0x6f6c2f7273752f3d 0x637261612f6c6163 0xffffffffe450: 0x656e6f6e2d343668 0x6e69622f666c652d 0xffffffffe460: 0x3d62647000646c2f 0x2f62642f7261762f 0xffffffffe470: 0x74726f7000676b70 0x2f3d72696462645f 0xffffffffe480: 0x702f62642f726176 0x5f4d50007374726f 0xffffffffe490: 0x505f544e45524150 0x657665643d54524f 0xffffffffe4a0: 0x3668637261612f6c 0x652d656e6f6e2d34 0xffffffffe4b0: 0x43006363672d666c 0x5243530063633d43 0xffffffffe4c0: 0x6f6f722f3d545049 0x5f7374726f702f74 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 (beginning of what = looks like stack frames) 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 0xffffffffe520: 0x0000000000000000 0x0000000000000000 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 0xffffffffe550: 0x0000000000434000 0x000000000000000f 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e 0xffffffffe580: 0x0000000000000001 0x0000000000000005 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) 0xffffffffe5b0: 0x54494445003d4854 0x41500069763d524f x26, x25 values = (see below) 0xffffffffe5c0: 0x2f3d534547414b43 0x74726f702f727375 x24, x23 values = (see below) 0xffffffffe5d0: 0x67616b6361702f73 0x414c46444c007365 x22, x21 values = (see below) 0xffffffffe5e0: 0x58584300203d5347 0x662d3d5347414c46 x20, x19 values = (see below) 0xffffffffe5f0: 0x2d74656b63617262 0x31353d6874706564 fp, lr values = (see below); pc=3D=3Dlr eventually. 0xffffffffe600: 0x346d673d344d0032 0x73752f3d564e4500 0xffffffffe610: 0x6d2f656d6f682f72 0x732e2f696d6b7261 0xffffffffe620: 0x2f3d647000637268 0x74726f702f727375 0xffffffffe630: 0x4441524750550073 0x703d4c4f4f545f45 0xffffffffe640: 0x657473616d74726f 0x5254524f46470072 0xffffffffe650: 0x4552534f003d4e41 0x4f00302e32313d4c 0xffffffffe660: 0x752f3d445750444c 0x702f6a626f2f7273 . . . So at this point we have that the stack pointer was messed up somewhat prior to the core-dump. x19-x26 in the below are from the locations indicated to the side above: General Purpose Registers: x0 =3D 0x0000000000000000 x1 =3D 0x0000000000000000 x2 =3D 0x0000000000000000 x3 =3D 0x00000000405735c8 libc.so.7`__sys_sigaction x4 =3D 0x0000000000000090 x5 =3D 0x2080002000200000 x6 =3D 0x0000000000434c28 sh..bss + 9448 x7 =3D 0x00000000000c590d x8 =3D 0x0000000000000000 x9 =3D 0x0000000000000000 x10 =3D 0x0000000000434000 sh..bss + 6336 x11 =3D 0x0000000000000000 x12 =3D 0x0000000000434c38 sh..bss + 9464 x13 =3D 0x0000000000000001 x14 =3D 0x0000000000000063 x15 =3D 0x0000000000000010 x16 =3D 0x0000000000432280 =20 x17 =3D 0x0000000040573554 libc.so.7`sigaction at sigaction.c:49 x18 =3D 0x0000000000000000 x19 =3D 0x662d3d5347414c46 x20 =3D 0x58584300203d5347 x21 =3D 0x414c46444c007365 x22 =3D 0x67616b6361702f73 x23 =3D 0x74726f702f727375 x24 =3D 0x2f3d534547414b43 x25 =3D 0x41500069763d524f x26 =3D 0x54494445003d4854 x27 =3D 0x0000ffffffffc658 x28 =3D 0x0000000000000000 fp =3D 0x2d74656b63617262 lr =3D 0x31353d6874706564 sp =3D 0x0000ffffffffe600 pc =3D 0x31353d6874706564 cpsr =3D 0x20000000 Note the: 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 is somewhat before 0x0000ffffffffe600. It looks to be a frame-pointer/lr-value pair. (And the 0x0000ffffffffc5c0 does point to a frame-pointer/lr-value pair that is part of a coherent chain of them inside the stack region.) It seems likely that despite the long distance framepointer reference in the fp/lr value pair: 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 that sp =3D 0x0000ffffffffe600 was the result of an increment by a small fixed amount from an sp near 0xffffffffe5a0, such as by code like the following when forkshell tries to return: sh`forkshell: 0x40f520 <+1004>: ldp x29, x30, [sp, #0x40] 0x40f524 <+1008>: ldp x20, x19, [sp, #0x30] 0x40f528 <+1012>: ldp x22, x21, [sp, #0x20] 0x40f52c <+1016>: ldp x24, x23, [sp, #0x10] 0x40f530 <+1020>: ldp x26, x25, [sp], #0x50 0x40f534 <+1024>: ret =20 So the prior is sp=3D0xffffffffe5b0 for the above code. Also note that for SP=3D0xffffffffe5b0 initially that code would fill in x19-x26 as they were actually filled in: solid evidence of the sp that exit code started with. Note that forkshell had started with: sh`forkshell: 0x40f134 <+0>: stp x26, x25, [sp, #-0x50]! 0x40f138 <+4>: stp x24, x23, [sp, #0x10] 0x40f13c <+8>: stp x22, x21, [sp, #0x20] 0x40f140 <+12>: stp x20, x19, [sp, #0x30] 0x40f144 <+16>: stp x29, x30, [sp, #0x40] 0x40f148 <+20>: add x29, sp, #0x40 ; =3D0x40=20 And that indicates that sp had a big change after: 0x40f148 <+20>: add x29, sp, #0x40 ; =3D0x40=20 in order for x29=3D0x0000ffffffffc5c0 to have later been written out as it was at 0xffffffffe5a0. But by the freejob call (that is in forkshell's child process path) that is indicated by the below the sp had changed to be higher than the stack region: 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 (lldb) dis -s -4*4+0x000000000040f490 sh`forkshell: 0x40f480 <+844>: ldrb w8, [x20, #0x21] 0x40f484 <+848>: cbz w8, 0x40f490 ; <+860> at = jobs.c:907 0x40f488 <+852>: mov x0, x20 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 . . . where freejob started with: (lldb) dis -s freejob sh`freejob: 0x40e65c <+0>: str x23, [sp, #-0x40]! 0x40e660 <+4>: stp x22, x21, [sp, #0x10] 0x40e664 <+8>: stp x20, x19, [sp, #0x20] 0x40e668 <+12>: stp x29, x30, [sp, #0x30] 0x40e66c <+16>: add x29, sp, #0x30 ; =3D0x30=20 . . . and the contained: 0x40e668 <+12>: stp x29, x30, [sp, #0x30] wrote the frame-pointer/lr-value pair: 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 after freejob was called. freejob returns with: (lldb) dis -s freejob -c 128 sh`freejob: . . . 0x40e748 <+236>: ldp x29, x30, [sp, #0x30] 0x40e74c <+240>: ldp x20, x19, [sp, #0x20] 0x40e750 <+244>: ldp x22, x21, [sp, #0x10] 0x40e754 <+248>: ldr x23, [sp], #0x40 0x40e758 <+252>: ret =20 . . . The lr-value from: 0xffffffffc5c0: 0x0000ffffffffc8f0 0x0000000000406648 refers to: sh`evalcommand: 0x406644 <+2012>: bl 0x40f134 ; forkshell at = jobs.c:838 0x406648 <+2016>: cbz w0, 0x40666c ; <+2052> at = eval.c:1175 as expected. This is in the stack region. There is evidence of the following frame-pointer/lr-value pair still in the stack-region from just before the fork but while forkshell was active and before the big change in sp value: 0xffffffffc570: 0x0000ffffffffc5c0 0x000000000040f1c8 sh`forkshell: 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork The parent process did not crash and so there is no evdence that its sp value was ever wrong. So going into fork things seem to have been okay. So far it does not appear to me that there is information left for inside or after the fork but before the freejob call on the child process path. So the fork itself might have returned with the wrong sp value or the problem might have occurred a little later. As far as the bad sp values in this example core file. . . The content of what I've historically called "junk" areas that are actually outside the stack region are interesting: . . . 0xffffffffe400: 0x6572662d6e776f6e 0x302e323164736265 0xffffffffe410: 0x56454c454b414d00 0x42494c00323d4c45 0xffffffffe420: 0x403d434e49464c45 0x6e69666c6562696c 0xffffffffe430: 0x4f465f444c004063 0x5445475241545f52 0xffffffffe440: 0x6f6c2f7273752f3d 0x637261612f6c6163 0xffffffffe450: 0x656e6f6e2d343668 0x6e69622f666c652d 0xffffffffe460: 0x3d62647000646c2f 0x2f62642f7261762f 0xffffffffe470: 0x74726f7000676b70 0x2f3d72696462645f 0xffffffffe480: 0x702f62642f726176 0x5f4d50007374726f 0xffffffffe490: 0x505f544e45524150 0x657665643d54524f 0xffffffffe4a0: 0x3668637261612f6c 0x652d656e6f6e2d34 0xffffffffe4b0: 0x43006363672d666c 0x5243530063633d43 0xffffffffe4c0: 0x6f6f722f3d545049 0x5f7374726f702f74 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) In other words ('\0' terminated strings): . . . (lldb) print (char*)0xffffffffe400 (char *) $67 =3D 0x0000ffffffffe400 "nown-freebsd12.0" (lldb) print (char*)0xffffffffe411 (char *) $66 =3D 0x0000ffffffffe411 "MAKELEVEL=3D2" (lldb) print (char*)0xffffffffe433 (char *) $68 =3D 0x0000ffffffffe433 = "LD_FOR_TARGET=3D/usr/local/aarch64-none-elf/bin/ld" (lldb) print (char*)0xffffffffe464 (char *) $69 =3D 0x0000ffffffffe464 "pdb=3D/var/db/pkg" (lldb) print (char*)0xffffffffe474 (char *) $71 =3D 0x0000ffffffffe474 "port_dbdir=3D/var/db/ports" (lldb) print (char*)0xffffffffe48d (char *) $60 =3D 0x0000ffffffffe48d = "PM_PARENT_PORT=3Ddevel/aarch64-none-elf-gcc" (lldb) print (char*)0xffffffffe4b7 (char *) $29 =3D 0x0000ffffffffe4b7 "CC=3Dcc" (lldb) print (char*)0xffffffffe4bd (char *) $30 =3D 0x0000ffffffffe4bd "SCRIPT=3D/root/ports_x" As for: 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) 0xffffffffe5b0: 0x54494445003d4854 0x41500069763d524f x26, x25 values = (see below) 0xffffffffe5c0: 0x2f3d534547414b43 0x74726f702f727375 x24, x23 values = (see below) 0xffffffffe5d0: 0x67616b6361702f73 0x414c46444c007365 x22, x21 values = (see below) 0xffffffffe5e0: 0x58584300203d5347 0x662d3d5347414c46 x20, x19 values = (see below) 0xffffffffe5f0: 0x2d74656b63617262 0x31353d6874706564 fp, lr values = (see below); pc=3D=3Dlr as well. 0xffffffffe600: 0x346d673d344d0032 0x73752f3d564e4500 0xffffffffe610: 0x6d2f656d6f682f72 0x732e2f696d6b7261 0xffffffffe620: 0x2f3d647000637268 0x74726f702f727375 0xffffffffe630: 0x4441524750550073 0x703d4c4f4f545f45 0xffffffffe640: 0x657473616d74726f 0x5254524f46470072 0xffffffffe650: 0x4552534f003d4e41 0x4f00302e32313d4c 0xffffffffe660: 0x752f3d445750444c 0x702f6a626f2f7273 . . . In other words: (lldb) print (char*)0xffffffffe5b0 (char *) $72 =3D 0x0000ffffffffe5b0 "TH=3D" (The above is likely missing its beginning, having been replaced by the frame-popinter/lr-value pair.) (lldb) print (char*)0xffffffffe5be (char *) $73 =3D 0x0000ffffffffe5be "PACKAGES=3D/usr/ports/packages" (lldb) print (char*)0xffffffffe5db (char *) $74 =3D 0x0000ffffffffe5db "LDFLAGS=3D " (lldb) print (char*)0xffffffffe5e5 (char *) $75 =3D 0x0000ffffffffe5e5 "CXXFLAGS=3D-fbracket-depth=3D512" (lldb) print (char*)0xffffffffe602 (char *) $76 =3D 0x0000ffffffffe602 "M4=3Dgm4" (lldb) print (char*)0xffffffffe624 (char *) $77 =3D 0x0000ffffffffe624 "pd=3D/usr/ports" (lldb) print (char*)0xffffffffe632 (char *) $79 =3D 0x0000ffffffffe632 "UPGRADE_TOOL=3Dportmaster" (lldb) print (char*)0xffffffffe64a (char *) $81 =3D 0x0000ffffffffe64a "GFORTRAN=3D" (lldb) print (char*)0xffffffffe654 (char *) $82 =3D 0x0000ffffffffe654 "OSREL=3D12.0" (lldb) print (char*)0xffffffffe65f (char *) $83 =3D 0x0000ffffffffe65f = "OLDPWD=3D/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/.bu= ild" . . . So the middle range with the stack frames: 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 0xffffffffe520: 0x0000000000000000 0x0000000000000000 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 0xffffffffe550: 0x0000000000434000 0x000000000000000f 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e 0xffffffffe580: 0x0000000000000001 0x0000000000000005 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) has stomped on strings that are outside the stack region. (The stack frames are the actual junk.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Feb-7, at 2:44 AM, Mark Millard wrote: > Another core. The register read reported: >=20 > fp =3D 0x0000000000000000 > lr =3D 0x0000000000000000 > sp =3D 0x0000fffffffee630 > pc =3D 0x0000000000000000 >=20 > And looking around (most nested to outer most): >=20 > 0xfffffffee530: 0x0000fffffffee570 0x000000004054cd94 > libc.so.7`__free: > 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 > 0x4054cd94 <+148>: adrp x9, 185 > 0xfffffffee570: 0x0000fffffffee590 0x0000000000411300 > sh`ckfree: > 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free > 0x411300 <+32>: ldr x8, [x19, #0x970] > 0xfffffffee590: 0x0000fffffffee5d0 0x000000000040e6e8 > sh`freejob: > 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 > 0x40e6e8 <+140>: adrp x8, 38 > 0xfffffffee5d0: 0x0000ffffffffcaa0 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30 > (Note that sp=3D=3D0x0000fffffffee630 is fairly close to = 0xfffffffee5d0.) >=20 > (sizable frame jump from 0xfffffffee5d0 to 0x0000ffffffffcaa0, size = 0xE4D0=3D=3D58576 bytes) > (0xfffffffee5e0 up to 0xffffffffa890 (not inclusive) are all = 0x0000000000000000) > (The prior trace example did not have such a large area.) >=20 > 0xffffffffca50: 0x0000ffffffffcaa0 0x000000000040f1c8 > sh`forkshell: > 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 > 0x40f1c8 <+148>: bl 0x402920 ; symbol stub = for: fork > 0x40f1cc <+152>: mov w19, w0 > (flushall a voids returning to 0x40f1c8 directly, instead making > the last routine it calls return there instead of to flushall.) >=20 > 0xffffffffcaa0: 0x0000ffffffffcb50 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 > 0xffffffffcb50: 0x0000ffffffffcde0 0x0000000000406e28 > sh`evalbackcmd: > 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 > 0x406e28 <+340>: ldur w0, [x29, #-0x5c] > 0xffffffffcde0: 0x0000ffffffffcf90 0x0000000000409324 > sh`argstr: > 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 > 0x409324 <+432>: mov x0, x26 > 0xffffffffcf90: 0x0000ffffffffcff0 0x0000000000408fa8 > sh`expandarg: > 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 > 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 > 0xffffffffcff0: 0x0000ffffffffd320 0x0000000000405f48 > sh`evalcommand: > 0x405f44 <+220>: bl 0x408f38 ; expandarg at = expand.c:225 > 0x405f48 <+224>: ldr x24, [x24, #0x8] >=20 > 0xffffffffd0f0: 0x0000ffffffffd320 0x00000000004068e4 > sh`evalcommand: > 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub = for: _setjmp > 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 >=20 > 0xffffffffd320: 0x0000ffffffffd3d0 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffd3d0: 0x0000ffffffffd480 0x0000000000405550 > sh`cmdloop: > 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 > 0x411034 <+252>: mov w27, wzr > 0xffffffffd480: 0x0000ffffffffd7b0 0x00000000004067d0 > sh`evalcommand: > 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 > 0x4067d0 <+2408>: ldr x8, [x24, #0x970] > 0xffffffffd7b0: 0x0000ffffffffd860 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffd860: 0x0000ffffffffd910 0x0000000000405550 > sh`evaltree: > 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 > 0x405550 <+180>: ldr w8, [x22, #0x994] > 0xffffffffd910: 0x0000ffffffffdc40 0x00000000004067d0 > sh`evalcommand: > 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 > 0x4067d0 <+2408>: ldr x8, [x24, #0x970] >=20 > 0xffffffffda10: 0x0000ffffffffdc40 0x000000000040673c > sh`evalcommand: > 0x406738 <+2256>: bl 0x402be0 ; symbol stub = for: _setjmp > 0x40673c <+2260>: cbnz w0, 0x406c60 ; <+3576> at = eval.c:1042 >=20 > 0xffffffffdc40: 0x0000ffffffffdcf0 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffdcf0: 0x0000ffffffffdd70 0x0000000000411034 > sh`cmdloop: > 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 > 0x411034 <+252>: mov w27, wzr > 0xffffffffdd70: 0x0000ffffffffddd0 0x0000000000410ea8 > sh`main: > 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 > 0x410ea8 <+660>: adrp x8, 36 > 0xffffffffddd0: 0x0000ffffffffde10 0x0000000000402f30 > sh`__start: > 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 > 0x402f30 <+360>: bl 0x402ae0 ; symbol stub = for: exit >=20 > (_rtld is not in the core file) > 0xffffffffde10: 0x0000000000000000 0x0000000040434658 > ld-elf.so.1`.rtld_start: > 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 > 0x40434658 <+24>: mov x8, x0 >=20 > So again the problem is associated with the forkshell/fork/freejob > related materials. >=20 > (I mistakenly left out the evalcommand/_setjmp material > when I made the trace in the below. The same for flushall. > I've inserted some of that below, at least for > the flushall context.) On 2017-Feb-6, at 8:05 PM, Mark Millard wrote: > [I got a lucky sh core dump with more stack context/content > available to look at for an example sh crash. This helps > narrow things down.] >=20 > On 2017-Feb-5, at 1:12 AM, Mark Millard = wrote: >=20 >> [Top post of a new result.] >>=20 >> Using lldb to look at the memory for the stack around >> sh failure points has some apparently fixed structure. >> Example: >>=20 >> . . . junk values . . . >> 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 >> 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 >> 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 >> 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 >> 0xffffffffe520: 0x0000000000000000 0x0000000000000000 >> 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 >> 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe550: 0x0000000000434000 0x000000000000000f >> 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 >> 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e >> 0xffffffffe580: 0x0000000000000001 0x0000000000000005 >> 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >> . . . junk values . . . >=20 > I got lucky and got a core dump that did not have the junk > areas and could trace the stack's frame pointer chain > between main and libc.so.7`__free (through freejob along > the way). See later. >=20 >> where "register read" showed: >>=20 >> sp =3D 0x0000ffffffffe600 >>=20 >> (The distance and direction to the last non-junk line >> from the reported sp in each example is the same.) >> Looking around that 0x000000000040f490: >>=20 >> 0x40f48c: 0x97fffc74 bl 0x40e65c ; freejob at = jobs.c:463 >> 0x40f490: 0x9100c294 add x20, x20, #0x30 ; =3D0x30=20 >>=20 >> It is the same address and code in each case. >=20 > I should have originally noted that 0x40f48c is in > forkshell, along the child process code-path: >=20 > pid_t > forkshell(struct job *jp, union node *n, int mode) > { > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > INTOFF; > if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) > checkzombies(); > flushall(); > pid =3D fork(); > if (pid =3D=3D -1) { > TRACE(("Fork failed, errno=3D%d\n", errno)); > INTON; > error("Cannot fork: %s", strerror(errno)); > } > if (pid =3D=3D 0) { > struct job *p; > int wasroot; > int i; >=20 > TRACE(("Child shell %d\n", (int)getpid())); > wasroot =3D rootshell; > rootshell =3D 0; > handler =3D &main_handler; > closescript(); > INTON; > forcelocal =3D 0; > clear_traps(); > #if JOBS > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > #else > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > #endif > INTOFF; > for (i =3D njobs, p =3D jobtab ; --i >=3D 0 ; p++) > if (p->used) > freejob(p); > INTON; > if (wasroot && iflag) { > setsignal(SIGINT); > setsignal(SIGQUIT); > setsignal(SIGTERM); > } > return pid; > } > . . . (see /usr/src/bin/sh/jobs.c for this) . . . >=20 >> Sometimes the junk values are all zeros over sizable >> distances. Sometimes the sizable areas seem to have >> random data. >>=20 >> /usr/src/bin/sh/jobs.c 's freejobs is: >>=20 >> static void >> freejob(struct job *jp) >> { >> struct procstat *ps; >> int i; >>=20 >> INTOFF; >> if (bgjob =3D=3D jp) >> bgjob =3D NULL; >> for (i =3D jp->nprocs, ps =3D jp->ps ; --i >=3D 0 ; ps++) { >> if (ps->cmd !=3D nullstr) >> ckfree(ps->cmd); >> } >> if (jp->ps !=3D &jp->ps0) >> ckfree(jp->ps); >> jp->used =3D 0; >> #if JOBS >> deljob(jp); >> #endif >> INTON; >> } >>=20 >> /usr/src/bin/sh/error.h defines INTOFF and INTON: >>=20 >> #define EXINT 0 /* SIGINT received */ >> #define EXERROR 1 /* a generic error */ >> #define EXEXEC 2 /* command execution failed */ >> #define EXEXIT 3 /* call exitshell(exitstatus) */ >>=20 >> . . . >>=20 >> extern struct jmploc *handler; >> extern volatile sig_atomic_t exception; >>=20 >> . . . >>=20 >> extern volatile sig_atomic_t suppressint; >> extern volatile sig_atomic_t intpending; >>=20 >> #define INTOFF suppressint++ >> #define INTON { if (--suppressint =3D=3D 0 && intpending) onint(); } >> #define is_int_on() suppressint >> #define SETINTON(s) suppressint =3D (s) >> #define FORCEINTON {suppressint =3D 0; if (intpending) onint();} >> #define SET_PENDING_INT intpending =3D 1 >> #define CLEAR_PENDING_INT intpending =3D 0 >> #define int_pending() intpending >>=20 >> void exraise(int) __dead2; >> void onint(void) __dead2; >>=20 >> /usr/src/bin/sh/error.c hAS: >>=20 >> void >> exraise(int e) >> { >> INTOFF; >> if (handler =3D=3D NULL) >> abort(); >> exception =3D e; >> longjmp(handler->loc, 1); >> } >> . . . >> void >> onint(void) >> { >> sigset_t sigs; >>=20 >> intpending =3D 0; >> sigemptyset(&sigs); >> sigprocmask(SIG_SETMASK, &sigs, NULL); >>=20 >> /* >> * This doesn't seem to be needed, since main() emits a newline. >> */ >> #if 0 >> if (tcgetpgrp(0) =3D=3D getpid()) >> write(STDERR_FILENO, "\n", 1); >> #endif >> if (rootshell && iflag) >> exraise(EXINT); >> else { >> signal(SIGINT, SIG_DFL); >> kill(getpid(), SIGINT); >> _exit(128 + SIGINT); >> } >> } >>=20 >> # grep setjmp /usr/src/bin/sh/* >> /usr/src/bin/sh/TOUR:so I implement it using setjmp and longjmp. The = global variable >> /usr/src/bin/sh/error.h:#include >> /usr/src/bin/sh/error.h: * BSD setjmp saves the signal mask, which = violates ANSI C and takes time, >> /usr/src/bin/sh/error.h: * so we use _setjmp instead. >> /usr/src/bin/sh/error.h:#define setjmp(jmploc) _setjmp(jmploc) >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/histedit.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/jobs.c: if (setjmp(jmploc.loc)) >> /usr/src/bin/sh/main.c: * commands. The setjmp call sets up the = location to jump to when an >> /usr/src/bin/sh/main.c: if (setjmp(main_handler.loc)) { >> /usr/src/bin/sh/parser.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/parser.c: if (!setjmp(jmploc.loc)) { >> /usr/src/bin/sh/trap.c: if (!setjmp(loc1.loc)) { >> /usr/src/bin/sh/trap.c: if (!setjmp(loc2.loc)) { >> /usr/src/bin/sh/var.c: if (setjmp(jmploc.loc)) >=20 > Here is the call chain that I was able to trace > in the newer core dump: > (most nested first to least nested last; > showing frame pointer and lr value pairs > and calls/return-places) >=20 > (ifree is not in the core file) > 0xffffffffcc60: 0x0000ffffffffcca0 0x000000004054cd94 > libc.so.7`__free: > 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 > 0x4054cd94 <+148>: adrp x9, 185 > 0xffffffffcca0: 0x0000ffffffffccc0 0x0000000000411300 > sh`ckfree: > 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free > 0x411300 <+32>: ldr x8, [x19, #0x970] > 0xffffffffccc0: 0x0000ffffffffcd00 0x000000000040e6e8 > sh`freejob: > 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 > 0x40e6e8 <+140>: adrp x8, 38 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 sh`forkshell: 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork 0x40f1cc <+152>: mov w19, w0 (flushall a voids returning to 0x40f1c8 directly, instead making the last routine it calls return there instead of to flushall.) > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 > 0xffffffffced0: 0x0000ffffffffd160 0x0000000000406e28 > sh`evalbackcmd: > 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 > 0x406e28 <+340>: ldur w0, [x29, #-0x5c]0xffffffffcd60: = 0x0000ffffffffcf90 0x00000000004068e4 > 0xffffffffd160: 0x0000ffffffffd310 0x0000000000409324 > sh`argstr: > 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 > 0x409324 <+432>: mov x0, x26 > 0xffffffffd310: 0x0000ffffffffd370 0x0000000000408fa8 > sh`expandarg: > 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 > 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 > 0xffffffffd370: 0x0000ffffffffd5f0 0x0000000000407530 > sh`exphere: > 0x40752c <+212>: bl 0x408f38 ; expandarg at = expand.c:225 > 0x407530 <+216>: ldr x8, [x20] > 0xffffffffd5f0: 0x0000ffffffffd630 0x00000000004073f0 > sh`expredir: > 0x4073ec <+112>: bl 0x407458 ; exphere at = eval.c:494 > 0x4073f0 <+116>: b 0x407428 ; <+172> at = eval.c:535 > 0xffffffffd630: 0x0000ffffffffd960 0x0000000000406154 > sh`evalcommand: > 0x406150 <+744>: bl 0x40737c ; expredir at = eval.c:532 > 0x406154 <+748>: ldur w27, [x29, #-0x68] > 0xffffffffd960: 0x0000ffffffffda10 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffda10: 0x0000ffffffffdac0 0x00000000004056b4 > sh`evaltree: > 0x4056b0 <+532>: bl 0x40549c ; <+0> at = eval.c:193 > 0x4056b4 <+536>: ldr w8, [x19, #0x990] > 0xffffffffdac0: 0x0000ffffffffdb70 0x0000000000405550 > sh`evaltree: > 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 > 0x405550 <+180>: ldr w8, [x22, #0x994] > 0xffffffffdb70: 0x0000ffffffffdbf0 0x0000000000411034 > sh`cmdloop: > 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 > 0x411034 <+252>: mov w27, wzr > 0xffffffffdbf0: 0x0000ffffffffdc50 0x0000000000410ea8 > sh`main: > 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 > 0x410ea8 <+660>: adrp x8, 36 > 0xffffffffdc50: 0x0000ffffffffdc90 0x0000000000402f30 > sh`__start: > 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 > 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit >=20 > (_rtld is not in the core file) > 0xffffffffdc90: 0x0000000000000000 0x0000000040434658 > ld-elf.so.1`.rtld_start: > 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 > 0x40434658 <+24>: mov x8, x0 >=20 > Some of the most nested possibly had returned. But the > forkshell / freejob general time frame seem to match > everything that I've seen. >=20 > [The details of the middle "eval*" related layers vary > from what I can tell.] >=20 > "register read" shows fp, lr, and pc majorly > messed up. >=20 > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc > x2 =3D 0x0000000040a00000 > x3 =3D 0x0000000000000002 > x4 =3D 0x0000000000000096 > x5 =3D 0x0000000040a5fd10 > x6 =3D 0x0000000000434c28 sh..bss + 9448 > x7 =3D 0x0000000000434c28 sh..bss + 9448 > x8 =3D 0x0000000000000001 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000000000 > x11 =3D 0x0000000040a350c0 > x12 =3D 0x0000000040a0e770 > x13 =3D 0x0000000000000072 > x14 =3D 0x000000000000006f > x15 =3D 0x0000000000000010 > x16 =3D 0x0000000000432340 =20 > x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 > x18 =3D 0x0000000000000000 > x19 =3D 0x0000000000000000 > x20 =3D 0x0000000000000000 > x21 =3D 0x0000000000000001 > x22 =3D 0x0000000040a5ff10 > x23 =3D 0x0000ffffffffd190 > x24 =3D 0x0000000000434000 sh..bss + 6336 > x25 =3D 0x0000000000434000 sh..bss + 6336 > x26 =3D 0x0000ffffffffcd00 > x27 =3D 0x0000000000434000 sh..bss + 6336 > x28 =3D 0x0000000040a6f5e0 > fp =3D 0x0000000040a5fed8 > lr =3D 0x0000000000000000 > sp =3D 0x0000ffffffffcd60 > pc =3D 0x0000000000000000 > cpsr =3D 0x60000000 >=20 > sp is also odd by being in the middle of the stack range > for: >=20 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 >=20 > NOTE: The fork happened earlier in sh`forkshell and this > is the child process that has the odd value. >=20 > [It leaves me wondering if 0x0000ffffffffcd60 is a stack > pointer value associated with a call to something > earlier than the sh`forkshell call that is called by > sh`forkshell .] >=20 > Also: in the ones with only a small section of the junk > areas the equivalent of: >=20 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 >=20 > is the largest addressed non-junk content in the area > and the equivalent of: >=20 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 >=20 > would instead show zeros or "random" garbage values. >=20 > In this case, however that range of the stack looks like: >=20 > . . . > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > 0xffffffffcd10: 0x0000ffffffffcd00 0x0000000000434000 > 0xffffffffcd20: 0x0000000000434000 0x0000ffffffffd190 > 0xffffffffcd30: 0x0000000040a5ff10 0x0000000000000001 > 0xffffffffcd40: 0x0000000000000000 0x0000000000000000 > 0xffffffffcd50: 0x0000000040a5fed8 0x0000000000000000 > 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 > 0xffffffffcd70: 0x0000000000000000 0x827a80ccb3228215 > 0xffffffffcd80: 0x0000000040a6f5c0 0x0000000000434000 > 0xffffffffcd90: 0x0000000000434000 0x0000000000434000 > 0xffffffffcda0: 0x0000000000434000 0x0000000000434000 > 0xffffffffcdb0: 0x0000000040a6f638 0x0000000000000000 > 0xffffffffcdc0: 0x0000000040a350c0 0x0000000000434000 > 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 > 0xffffffffcde0: 0x0000000000000003 0x0000000040a350c0 > 0xffffffffcdf0: 0x0000000040a6f5c0 0x0000000000434000 > 0xffffffffce00: 0x0000000000434000 0x0000000040a6f638 > 0xffffffffce10: 0x0000000000000000 0x0000000000434000 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > . . . >=20 > Interestingly 0xffffffffcd60 reported for the sp looks > like it has a frame-pointer/lr-value pair that does not > fit with the overall call chain that ties together but > is some fragment of a prior(?) call chain: >=20 > 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 > sh`evalcommand: > 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub = for: _setjmp > 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 >=20 > It looks like it is a record from calling _setjmp in > sh`evalcommand . >=20 > (sh uses _setjmp/_longjmp via macros that turn > into them for setjmp/longjmp references in > sh's source code.) >=20 > Interestingly (likely junk relative to the above): >=20 > 0xffffffffcf90: 0x0000000000000000 0x0000000000432000 >=20 > where: >=20 > (lldb) dis -s 0x0000000000432000 > sh`__frame_dummy_init_array_entry: > 0x432000 <+0>: .long 0x00402fac ; unknown opcode > 0x432004 <+4>: .long 0x00000000 ; unknown opcode > (lldb) dis -s __frame_dummy_init_array_entry -c32 > sh`frame_dummy: > 0x402fac <+0>: adrp x8, 48 > 0x402fb0 <+4>: adrp x1, 48 > 0x402fb4 <+8>: ldr x8, [x8, #0x30] > 0x402fb8 <+12>: ldr x1, [x1, #0x228] > 0x402fbc <+16>: cmp x8, #0x0 ; =3D0x0=20 > 0x402fc0 <+20>: ccmp x1, #0x0, #0x4, ne > 0x402fc4 <+24>: b.ne 0x402fcc ; <+32> > 0x402fc8 <+28>: ret =20 > 0x402fcc <+32>: adrp x0, 48 > 0x402fd0 <+36>: add x0, x0, #0x30 ; =3D0x30=20 > 0x402fd4 <+40>: br x1 >=20 > sh`lookupalias: > . . . >=20 >=20 > Ohter notes: >=20 > Some examples of funcnest=3D=3D0 others have (e.g.) funcnest=3D=3D2. > This one had funcnest=3D=3D0. >=20 > commandname varies. In this case it was: >=20 > (lldb) print commandname > (char *) $74 =3D 0x0000ffffffffe210 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/configure" >=20 > Other examples include: >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffdc40 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/fi= xincludes/configure" >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffe498 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/../config.sub" >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffe398 "../libtool" >=20 >=20 > So far the forkshell/fork/freejob and associated materials always = seeming > to be involved is all that I've found that is common (at least that is > suggested by what I see so far) within the sh context. >=20 >> Other notes: >>=20 >> As a personal investigation I've temporarily changed to using >> something not fully generic but based on gic-400 specifics: >>=20 >> # svnlite diff /usr/src/sys/arm/arm/gic.c >> Index: /usr/src/sys/arm/arm/gic.c >> =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/src/sys/arm/arm/gic.c (revision 312982) >> +++ /usr/src/sys/arm/arm/gic.c (working copy) >> @@ -672,9 +672,13 @@ >>=20 >> if (irq >=3D sc->nirqs) { >> #ifdef GIC_DEBUG_SPURIOUS >> +#define EXPECTED_SPURIOUS_IRQ 1023 >> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >> device_printf(sc->gic_dev, >> - "Spurious interrupt detected: last irq: %d on = CPU%d\n", >> + "Spurious interrupt %d detected of %d: last irq: = %d on CPU%d\n", >> + irq, sc->nirqs, >> sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >> + } >> #endif >> return (FILTER_HANDLED); >> } >> @@ -720,6 +724,16 @@ >> if (irq < sc->nirqs) >> goto dispatch_irq; >>=20 >> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >> +#undef EXPECTED_SPURIOUS_IRQ >> +#ifdef GIC_DEBUG_SPURIOUS >> + device_printf(sc->gic_dev, >> + "Spurious end interrupt %d detected of %d: last = irq: %d on CPU%d\n", >> + irq, sc->nirqs, >> + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >> +#endif >> + } >> + >> return (FILTER_HANDLED); >> } >>=20 >>=20 >> The result was no notices of Spurious interrupts have been generated: >> All of the odd interrupts were the special 1023 value. >>=20 >> [As far as I could tell from the code the configuration is such that >> 1022 should not be generated --and were not. 1020 and 1021 are >> reserved and should not be generated.] =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ 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 Thu Feb 9 12:41:20 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B01B3CD69B0 for ; Thu, 9 Feb 2017 12:41:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-75.reflexion.net [208.70.210.75]) (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 718581AE9 for ; Thu, 9 Feb 2017 12:41:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27544 invoked from network); 9 Feb 2017 12:41:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Feb 2017 12:41:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Thu, 09 Feb 2017 07:41:18 -0500 (EST) Received: (qmail 1663 invoked from network); 9 Feb 2017 12:41:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Feb 2017 12:41:18 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 7885AEC7652 for ; Thu, 9 Feb 2017 04:41:17 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: head -r312982 on pine64 (an A64): 4 "openssl speed"s (e.g.) in parallel lead to thermal poweroff despite powerd use Message-Id: Date: Thu, 9 Feb 2017 04:41:16 -0800 To: freebsd-arm X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 12:41:20 -0000 Attempting (back to back): # openssl speed > /dev/null 2>&1 & # openssl speed > /dev/null 2>&1 & # openssl speed > /dev/null 2>&1 & # openssl speed > /dev/null 2>&1 & leads to eventual sudden thermal powerpff on the pine64 (that has a heat sink and fan) for head -r312982 . (By no means is the command set likely to be unique for causing such.) Context details: # ps -aux | grep powerd root 608 0.0 0.0 6192 440 - Ss 03:40 0:00.10 = /usr/sbin/powerd root 720 0.0 0.1 6544 2136 1 S+ 03:51 0:00.01 grep powerd # more /usr/src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 (I've been holding at 312982 while investigating sh getting core files on occasion. See: = https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015620.html = .) # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/arm/arm/gic.c M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/dev/mlx5/diagnostics.h M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/ofw/ofw_machdep.c # svnlite diff /usr/src/sys/arm/arm/gic.c Index: /usr/src/sys/arm/arm/gic.c =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/src/sys/arm/arm/gic.c (revision 312982) +++ /usr/src/sys/arm/arm/gic.c (working copy) @@ -672,9 +672,13 @@ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS +#define EXPECTED_SPURIOUS_IRQ 1023 + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { device_printf(sc->gic_dev, - "Spurious interrupt detected: last irq: %d on = CPU%d\n", + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n", + irq, sc->nirqs, sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); + } #endif return (FILTER_HANDLED); } @@ -720,6 +724,16 @@ if (irq < sc->nirqs) goto dispatch_irq; =20 + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { +#undef EXPECTED_SPURIOUS_IRQ +#ifdef GIC_DEBUG_SPURIOUS + device_printf(sc->gic_dev, + "Spurious end interrupt %d detected of %d: last irq: = %d on CPU%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); +#endif + } + return (FILTER_HANDLED); } =20 Effectively that just disables the spurious interrupt notices that were being generated: all the examples happen to have irq=3D=3D1023. /usr/src/sys/dev/mlx5/diagnostics.h has the removal of an inappropriate const (as was later done by someone's check-in). (It turns out clang allows updates to const members in structs when the whole struct is assigned. gcc correctly rejects such code.) Other than KERNCONF files most of the rest of the changes are tied to my powerpc64 and powerpc investigations of clang use as the system compiler (there are problems --and I occasionally find additional ones). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Feb 9 14:34:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3FC2CD609D for ; Thu, 9 Feb 2017 14:34:15 +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 mx1.freebsd.org (Postfix) with ESMTPS id 8A3C7A1 for ; Thu, 9 Feb 2017 14:34:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v19EYFf9032289 for ; Thu, 9 Feb 2017 14:34:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 216940] r313333 blows up RPI3 booting in /boot/loader.efi Date: Thu, 09 Feb 2017 14:34:15 +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 Many People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:34:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940 Bug ID: 216940 Summary: r313333 blows up RPI3 booting in /boot/loader.efi Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: karl@denninger.net The Pi3 boots through a chain that includes /boot/loader.efi. The changes made in r313333, committed 2017-02-06, causes the RPI3 to fail during the boot sequence in /boot/loader.efi with the following crash: EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Feb 9 08:09:37 CST 2017 freebsd@NewFS.denninger.net) Failed to start image provided by UFS (14) "Synchronous Abort" handler, esr 0x96000004 ELR: 3af62cec LR: 3af61d60 x0 : 0000000000000001 x1 : 0000000000000001 x2 : 000000003afeb000 x3 : 000000000000003f x4 : 0000000000000020 x5 : 0000000000000010 x6 : 0000000000000000 x7 : 0000000039b260a4 x8 : 000000003af61d48 x9 : 000000000000000d x10: 0000000000000030 x11: 0000000000000000 x12: 0000000000000000 x13: 0000000000000002 x14: 0000000000000000 x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 x18: 000000003ab30df8 x19: 0000000037a16008 x20: 0000000000000000 x21: 0000000000000000 x22: 0000000039b28000 x23: 0000000039b1d49c x24: 0000000039b28850 x25: 000000003ab3d740 x26: 000000003af839a0 x27: 0000000039b2e3e8 x28: 0000000000000000 x29: 000000003ab2ef60 Resetting CPU ... resetting ... Reverting sys/boot/efi to a revision prior to 313333 resolves the issue. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Feb 9 19:17:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5297CCD4F37 for ; Thu, 9 Feb 2017 19:17:40 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from wa3yre.wynn.com (wa3yre.wynn.com [199.89.147.3]) (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 C24D61B24 for ; Thu, 9 Feb 2017 19:17:38 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from pearl (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by wa3yre.wynn.com (8.14.3/8.12.6) with ESMTP id v19JEv1o035964 for ; Thu, 9 Feb 2017 14:14:57 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Received: from pearl ([199.89.147.252] helo=pearl) by ASSP-nospam with ESMTPS(AES256-SHA) (ASSP 1.10.1); 9 Feb 2017 14:14:57 -0500 Date: Thu, 9 Feb 2017 14:14:37 -0500 From: freebsd-arm@wynn.com To: freebsd-arm@freebsd.org Subject: mounting USB drive at boot Message-ID: Reply-To: wynkoop@wynn.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-apple-darwin10.8.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:17:40 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkdyZWV0 aW5nLQ0KDQpUaGlzIGlzIHByb2JhYmx5IG5vdCBBUk0gc3BlY2lmaWMsIGJ1dCBJIGp1c3QgYnJv dWdodCBteSBvcmlnaW5hbA0KQmVhZ2xlQm9uZSB1cCBvbiB0aGUgZnJlZWJzZCBjdXJyZW50IGlt YWdlIGZyb20gZnRwLmZyZWVic2Qub3JnLg0KDQpXaGlsZSBJIHdhcyBwbGVhc2VkIHRvIGRpc2Nv dmVyIHRoYXQgVVNCIHdhcyB3b3JraW5nIG11Y2ggYmV0dGVyIHRoYW4NCml0IGhhZCBvbiAxMC54 IGZvciBkaXNrIGRldmljZXMgKHVzYiBmbGFzaCBkcml2ZSBpbiB0aGlzIGNhc2UpLiAgSSB3YXMN CmRpc2FwcG9pbnRlZCB0byBkaXNjb3ZlciB0aGF0IGF0dGVtcHRzIHRvIG1vdW50IHRoZSBkcml2 ZSBhdCBib290IHdvdWxkDQpmYWlsIHdpdGggdGhlIGRyaXZlIG5vdCBiZWluZyBwcmVzZW50IHdo ZW4gZnNjayBzdGFydGVkLiAgDQoNCkkgdHJpZWQgdGFnZ2luZyBpdCBhcyBhIGxhdGUgZmlsZSBz eXN0ZW0gaW4gZnN0YWIgYW5kIG9mIGNvdXJzZSBtYXJrZWQNCml0IGFzIHNlY29uZCB0byAgY2hl Y2sgYWZ0ZXIgLywgYnV0IG5vIGpveS4gIFRoZSBtZXNzYWdlIGFib3V0IGRhMA0KYmVpbmcgZGlz Y292ZXJlZCBhbHdheXMgY2FtZSBhZnRlciB0aGUgZnNjayBmYWlsZWQgYW5kIEkgd2FzIGRyb3Bw ZWQgdG8NCnNpbmdsZSB1c2VyIG1vZGUuDQoNCkFzIGEgd29yayBhcm91bmQgSSBzZXQgL2Rldi91 ZnMvYmI2NCB0byBub2F1dG8gYW5kIEkgYW0gcnVubmluZyBmc2NrIG9uDQppdCBhbmQgbW91bnRp bmcgaXQgZnJvbSByYy5sb2NhbC4NCg0KSXMgdGhlcmUgc29tZXRoaW5nIG9idmlvdXMgSSBoYXZl IG1pc3NlZCB0aGF0IHdpbGwgcGVybWl0IHRoZSBmc2NrIHRvDQpoYXBwZW4gYWZ0ZXIgdGhlIHVz YiBidXMgaGFzIGJlZW4gcHJvYmVkPw0KDQotIC1CcmV0dA0KDQotIC0tIA0KDQp3eW5rb29wQHd5 bm4uY29tDQo5MTctNjQyLTY5MjUNCjkyOS0yNzItMDAwMA0KDQpBbWVuZG1lbnQgSQ0KDQpDb25n cmVzcyBzaGFsbCBtYWtlIG5vIGxhdyByZXNwZWN0aW5nIGFuIGVzdGFibGlzaG1lbnQgb2YgcmVs aWdpb24sIG9yDQpwcm9oaWJpdGluZyB0aGUgZnJlZSBleGVyY2lzZSB0aGVyZW9mOyBvciBhYnJp ZGdpbmcgdGhlIGZyZWVkb20gb2YNCnNwZWVjaCwgb3Igb2YgdGhlIHByZXNzOyBvciB0aGUgcmln aHQgb2YgdGhlIHBlb3BsZSBwZWFjZWFibHkgdG8NCmFzc2VtYmxlLCBhbmQgdG8gcGV0aXRpb24g dGhlIGdvdmVybm1lbnQgZm9yIGEgcmVkcmVzcyBvZiBncmlldmFuY2VzLg0KDQotLS0tLUJFR0lO IFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQppUUVjQkFFQkNBQUdCUUpZbkwrb0FBb0pFSzZLM3lyYytS dURWYUFJQUpNbVBWaDBCVFExbmUyR0RKSTNZbzlsDQo5bllicGU2NGFObktmOVdUbCt6Rkc2NmRP bEgyYzhqRmNscXN2REV3OFMzcGtoa0pXeTRON2ZDMUZUdURBaW1yDQpjZ2UrMngrc3Q3QjE4VEQz U2NwV1h5VWd0OE5BNXN1U0kzN08wOHU5djR6WXV1YUQ3Q1ZhaTNsVDRWeURDeVNyDQoxVmxGd2pB My9DSGxsd2lyYjJLUW01Ync1NGEvdmZCVnhUbDN2RzZPV3p6ZEZoaU5BSTllcEkySkd3RnVyTGkw DQpQVllhMWNnb25nS3lvazZMMEhxcXpyTytuRnhnY3Y0ZDlTQllyeUpLdHIxd1M0dnVXUjF1S2d6 ZzZsdUlHd21ZDQp2NmlSWmFqN0NuZmk5enZVK2dLbWcrZFJNdGlOK1RtQU5YOVJEVFBrWFZaTWFW eEc1a1lFeG9aYWlnUFQwNUU9DQo9V1BuRw0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-arm@freebsd.org Thu Feb 9 19:38:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98180CD82E5 for ; Thu, 9 Feb 2017 19:38:50 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 7EAC36E7 for ; Thu, 9 Feb 2017 19:38:50 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 40e11735-eeff-11e6-ba57-8bc134ee460a X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 40e11735-eeff-11e6-ba57-8bc134ee460a; Thu, 09 Feb 2017 19:37:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v19Jbdcu014698; Thu, 9 Feb 2017 12:37:40 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1486669059.10020.220.camel@freebsd.org> Subject: Re: mounting USB drive at boot From: Ian Lepore To: wynkoop@wynn.com, freebsd-arm@freebsd.org Date: Thu, 09 Feb 2017 12:37:39 -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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:38:50 -0000 On Thu, 2017-02-09 at 14:14 -0500, freebsd-arm@wynn.com wrote: > Greeting- > > This is probably not ARM specific, but I just brought my original > BeagleBone up on the freebsd current image from ftp.freebsd.org. > > While I was pleased to discover that USB was working much better than > it had on 10.x for disk devices (usb flash drive in this case).  I > was > disappointed to discover that attempts to mount the drive at boot > would > fail with the drive not being present when fsck started.   > > I tried tagging it as a late file system in fstab and of course > marked > it as second to  check after /, but no joy.  The message about da0 > being discovered always came after the fsck failed and I was dropped > to > single user mode. > > As a work around I set /dev/ufs/bb64 to noauto and I am running fsck > on > it and mounting it from rc.local. > > Is there something obvious I have missed that will permit the fsck to > happen after the usb bus has been probed? > > -Brett > > _______________________________________________ > 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 > " Set kern.cam.boot_delay="10000" in /boot/loader.conf.  Tune the 10000 as needed, it's delay in milliseconds. -- Ian From owner-freebsd-arm@freebsd.org Thu Feb 9 19:41:00 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07A19CD8369 for ; Thu, 9 Feb 2017 19:41:00 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D9752834 for ; Thu, 9 Feb 2017 19:40:59 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id DEC17324; Thu, 9 Feb 2017 14:31:24 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_C000A3A4-90D5-4A39-974F-BC4F3185CD3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: mounting USB drive at boot From: Paul Mather In-Reply-To: Date: Thu, 9 Feb 2017 14:31:23 -0500 Cc: freebsd-arm@freebsd.org Message-Id: <2793027D-E0AE-45F9-981A-0DCFB0723B06@gromit.dlib.vt.edu> References: To: wynkoop@wynn.com X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:41:00 -0000 --Apple-Mail=_C000A3A4-90D5-4A39-974F-BC4F3185CD3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 2:14 PM, freebsd-arm@wynn.com wrote: > Greeting- >=20 > This is probably not ARM specific, but I just brought my original > BeagleBone up on the freebsd current image from ftp.freebsd.org. >=20 > While I was pleased to discover that USB was working much better than > it had on 10.x for disk devices (usb flash drive in this case). I was > disappointed to discover that attempts to mount the drive at boot = would > fail with the drive not being present when fsck started. >=20 > I tried tagging it as a late file system in fstab and of course marked > it as second to check after /, but no joy. The message about da0 > being discovered always came after the fsck failed and I was dropped = to > single user mode. >=20 > As a work around I set /dev/ufs/bb64 to noauto and I am running fsck = on > it and mounting it from rc.local. >=20 > Is there something obvious I have missed that will permit the fsck to > happen after the usb bus has been probed? I was having the same problem and found that adding this line to = /boot/loader.conf solved the problem for me: kern.cam.boot_delay=3D"10000" That instructs the system to wait 10 seconds during boot to give time = for the CAM subsystem probes to complete. Cheers, Paul. --Apple-Mail=_C000A3A4-90D5-4A39-974F-BC4F3185CD3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYnMOLAAoJEGsW1DqNux/ZQNAP/0CoFs9425mfski+SGH02FPV nfzJNZvCwlVm2AdMt+e8bwmgv96/BD5ALxmOeCPsBXIhSh6Cj+DgbiPUc/NEmCv3 SlvMRAqiqz2hpeBm8e4LGl+21RhTCbmIMp2kuqTboxt2/IBmH8zsiWbA7NQmJ1KW cuOrfN8PGO5bLXiX3HDJSsDneQmudZ/zlbgMteYHKtThw5etRZcodtFbfeZrdNtb DFOTvluo3TlIaCt+AFfST3kdTFp5eZDLy9T1/fkcoHXvXAgDYeiZxQj6naQtUUq2 lCUpx8MfQg9XfCDBFkYltu6irBs0/Br6szCz5jx1iWAeOVmGqmCGmbt6u+AaF1fg v36itumnBGxAOjO5kHkMQ+VOhxiVrTnbJLQ7iZ7aIaWII1mI8jJqaNCLdk6vb9C6 mnXm478QiOpxvwQu2xD9yaioqO+xULG2Qnmgmn8mSQERrWogS1w2KjUyzh6i5ym/ PgGLQn0oslh9H0oM0cZ3J/XLX4weu3eKNSvRF20AOnZL6juhCnhrem81WvQiBkbF iSiMB71bL2g/rVkVtOqcgIKgZf1ko1lVOmdIafFfLIgVo7vEW7HeXQe4dga3UfqE whhmTde8NWnsJkkMPsnVUwGfL2a8Rq30IAP+ShcgLqF2ZnxT4SPW6ONjoizjHfgz 4y4ESXyGEI+UiDW/K6aa =Dhm2 -----END PGP SIGNATURE----- --Apple-Mail=_C000A3A4-90D5-4A39-974F-BC4F3185CD3F-- From owner-freebsd-arm@freebsd.org Thu Feb 9 19:59:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07029CD8936 for ; Thu, 9 Feb 2017 19:59:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 7A7CD14C6; Thu, 9 Feb 2017 19:59:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v19Jwv90078472 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Feb 2017 21:58:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v19Jwv90078472 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v19JwvjM078471; Thu, 9 Feb 2017 21:58:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Feb 2017 21:58:57 +0200 From: Konstantin Belousov To: Ian Lepore Cc: wynkoop@wynn.com, freebsd-arm@freebsd.org Subject: Re: mounting USB drive at boot Message-ID: <20170209195857.GQ2092@kib.kiev.ua> References: <1486669059.10020.220.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1486669059.10020.220.camel@freebsd.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:59:04 -0000 On Thu, Feb 09, 2017 at 12:37:39PM -0700, Ian Lepore wrote: > On Thu, 2017-02-09 at 14:14 -0500, freebsd-arm@wynn.com wrote: > > Greeting- > > > > This is probably not ARM specific, but I just brought my original > > BeagleBone up on the freebsd current image from ftp.freebsd.org. > > > > While I was pleased to discover that USB was working much better than > > it had on 10.x for disk devices (usb flash drive in this case).ššI > > was > > disappointed to discover that attempts to mount the drive at boot > > would > > fail with the drive not being present when fsck started.šš > > > > I tried tagging it as a late file system in fstab and of course > > marked > > it as second toššcheck after /, but no joy.ššThe message about da0 > > being discovered always came after the fsck failed and I was dropped > > to > > single user mode. > > > > As a work around I set /dev/ufs/bb64 to noauto and I am running fsck > > on > > it and mounting it from rc.local. > > > > Is there something obvious I have missed that will permit the fsck to > > happen after the usb bus has been probed? > > > > -Brett > > > > _______________________________________________ > > 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 > > " > > Set kern.cam.boot_delay="10000" in /boot/loader.conf. šTune the 10000 > as needed, it's delay in milliseconds. Right solution after r313350 is to set vfs.root_mount_always_wait=1 loader tunable. The knob should be merged to 11 in two weeks. From owner-freebsd-arm@freebsd.org Thu Feb 9 20:21:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECAA7CD810C for ; Thu, 9 Feb 2017 20:21:49 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from wa3yre.wynn.com (wa3yre.wynn.com [199.89.147.3]) (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 A544668D; Thu, 9 Feb 2017 20:21:49 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from pearl (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by wa3yre.wynn.com (8.14.3/8.12.6) with ESMTP id v19KLNBc041118; Thu, 9 Feb 2017 15:21:47 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Received: from pearl ([199.89.147.252] helo=pearl) by ASSP-nospam with ESMTPS(AES256-SHA) (ASSP 1.10.1); 9 Feb 2017 15:21:23 -0500 Date: Thu, 9 Feb 2017 15:21:18 -0500 From: freebsd-arm@wynn.com To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: mounting USB drive at boot Message-ID: In-Reply-To: <1486669059.10020.220.camel@freebsd.org> References: <20170209141437.5c808ca9@pearl> <1486669059.10020.220.camel@freebsd.org> Reply-To: wynkoop@wynn.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-apple-darwin10.8.0) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:21:50 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCg0KPiBT ZXQga2Vybi5jYW0uYm9vdF9kZWxheT0iMTAwMDAiIGluIC9ib290L2xvYWRlci5jb25mLiCgVHVu ZSB0aGUgMTAwMDANCj4gYXMgbmVlZGVkLCBpdCdzIGRlbGF5IGluIG1pbGxpc2Vjb25kcy4NCj4g DQo+IC0tIElhbg0KPiANCj4gDQoNClRoYW5rcyB0byBldmVyeW9uZSB3aG8gcG9pbnRlZCB0aGlz IG91dCEgIE5vdCBvYnZpb3VzIGZyb20gYW55IGRvY3MuDQpQZXJoYXBzIHRoZSBoYW5kYm9vayBu ZWVkcyBhIHNwb3QgZm9yIHRoaXMuDQoNCi0gLUJyZXR0DQoNCi0gLS0gDQoNCnd5bmtvb3BAd3lu bi5jb20NCjkxNy02NDItNjkyNQ0KOTI5LTI3Mi0wMDAwDQoNCkFtZW5kbWVudCBJDQoNCkNvbmdy ZXNzIHNoYWxsIG1ha2Ugbm8gbGF3IHJlc3BlY3RpbmcgYW4gZXN0YWJsaXNobWVudCBvZiByZWxp Z2lvbiwgb3INCnByb2hpYml0aW5nIHRoZSBmcmVlIGV4ZXJjaXNlIHRoZXJlb2Y7IG9yIGFicmlk Z2luZyB0aGUgZnJlZWRvbSBvZg0Kc3BlZWNoLCBvciBvZiB0aGUgcHJlc3M7IG9yIHRoZSByaWdo dCBvZiB0aGUgcGVvcGxlIHBlYWNlYWJseSB0bw0KYXNzZW1ibGUsIGFuZCB0byBwZXRpdGlvbiB0 aGUgZ292ZXJubWVudCBmb3IgYSByZWRyZXNzIG9mIGdyaWV2YW5jZXMuDQoNCi0tLS0tQkVHSU4g UEdQIFNJR05BVFVSRS0tLS0tDQoNCmlRRWNCQUVCQ0FBR0JRSlluTTlDQUFvSkVLNkszeXJjK1J1 RDJTMEgvUnd2K0xDTFBrMkQxYzlxWEt1dXY2dlMNClcwRURhV3JZam5RcW1mVXlnNElpMU5WOEVJ WTJrOExxQUlIcC9aeEhGeU5Zek56a25uTlpNcDRvcFFxMG12SWkNCkZkZnhqQkpaWGF2enBVQzVR dXlOS2szSUt6cUZYME00eDZXVVc1andkR1JhaVM3b0FNd3p1cVh3ZXlhR05pT1YNCmhkV1BuTFk2 WWJvYlI2M2xhN3NrN2V0L3doeGFFSlJxeWhZUUtvSkQ1S2hGalg1VC96OUNuSitRT2Q3MXliSEMN Ck1yOUNHOWdMWWVLbzdTZzFSVE1nRGZrOTdBbFNIbVcyYkZPQ2pSUktIWmY0MTdlVnpoSTFabWpk a21jUDhyZUoNCjZ0ODFsVGJZenRuMkorNlBRalFST0hYV2hlRnRNYTl5MFBnMVBscEVqamdXTk14 aXZ6R2pRWFRiWnM3dFQ2Yz0NCj0vSzNLDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From owner-freebsd-arm@freebsd.org Fri Feb 10 01:28:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFA31CD8DFD for ; Fri, 10 Feb 2017 01:28:37 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from wa3yre.wynn.com (wa3yre.wynn.com [199.89.147.3]) (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 94E0116A2 for ; Fri, 10 Feb 2017 01:28:36 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from pearl (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by wa3yre.wynn.com (8.14.3/8.12.6) with ESMTP id v1A1SXVH066061; Thu, 9 Feb 2017 20:28:34 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Received: from pearl ([199.89.147.198] helo=pearl) by ASSP-nospam with ESMTPS(AES256-SHA) (ASSP 1.10.1); 9 Feb 2017 20:28:33 -0500 Date: Thu, 9 Feb 2017 20:28:26 -0500 From: freebsd-arm@wynn.com To: Paul Mather Cc: freebsd-arm@freebsd.org Subject: Re: mounting USB drive at boot Message-ID: In-Reply-To: <2793027D-E0AE-45F9-981A-0DCFB0723B06@gromit.dlib.vt.edu> References: <20170209141437.5c808ca9@pearl> <2793027D-E0AE-45F9-981A-0DCFB0723B06@gromit.dlib.vt.edu> Reply-To: wynkoop@wynn.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-apple-darwin10.8.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 01:28:38 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNClBhdWwg TWF0aGVyIHNhaWQ7DQo+IA0KPiBJIHdhcyBoYXZpbmcgdGhlIHNhbWUgcHJvYmxlbSBhbmQgZm91 bmQgdGhhdCBhZGRpbmcgdGhpcyBsaW5lDQo+IHRvIC9ib290L2xvYWRlci5jb25mIHNvbHZlZCB0 aGUgcHJvYmxlbSBmb3IgbWU6DQo+IA0KPiAJa2Vybi5jYW0uYm9vdF9kZWxheT0iMTAwMDAiDQo+ IA0KPiANCj4gVGhhdCBpbnN0cnVjdHMgdGhlIHN5c3RlbSB0byB3YWl0IDEwIHNlY29uZHMgZHVy aW5nIGJvb3QgdG8gZ2l2ZSB0aW1lDQo+IGZvciB0aGUgQ0FNIHN1YnN5c3RlbSBwcm9iZXMgdG8g Y29tcGxldGUuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBQYXVsLg0KPiANCg0KVGhhbmtzIHNvIG11 Y2ggZXZlcnlvbmUgZm9yIHRoYXQgcG9pbnRlciEgIE5vIGlkZWEgd2h5IEkgZGlkIG5vdCBmaW5k DQppdCBpbiB0aGUgaGFuZGJvb2suDQoNCkJ1aWxkaW5nIGEga2VybmVsIG9uIHRoZSB1c2Igc3Rp Y2sgbm93IGp1c3QgdG8gc3RyZXNzIHRlc3QgdGhpbmdzLg0KV2lsbCBmaXggbG9hZGVyLmNvbmYg YW5kIHJlYm9vdCB3aGVuIGRvbmUuICBJdCBzaG91bGQgYmUgaW50ZXJlc3RpbmcgdG8NCnNlZSBo b3cgbG9uZyBhIGtlcm5lbCBidWlsZCB0YWtlcy4gIFdoaWxlIHRoZSBCZWFnbGVCb25lIGlzIG11 Y2gNCmZhc3RlciB0aGFuIHRoZSBTdW4gMyBJIGJ1aWx0IG15IGZpcnN0IGtlcm5lbCBvbiBpdCBp cyB0YWtpbmcgbXVjaA0KbW9yZSB0aW1lLiAgTWF5YmUgdXNiZmxhc2ggZHJpdmUgd3JpdGUgc3Bl ZWRzIGFyZSBob2xkaW5nIG1lIGJhY2suDQoNCi0gLUJyZXR0IA0KDQoNCi0gLS0gDQoNCnd5bmtv b3BAd3lubi5jb20NCjkxNy02NDItNjkyNQ0KOTI5LTI3Mi0wMDAwDQoNCkFtZW5kbWVudCBJDQoN CkNvbmdyZXNzIHNoYWxsIG1ha2Ugbm8gbGF3IHJlc3BlY3RpbmcgYW4gZXN0YWJsaXNobWVudCBv ZiByZWxpZ2lvbiwgb3INCnByb2hpYml0aW5nIHRoZSBmcmVlIGV4ZXJjaXNlIHRoZXJlb2Y7IG9y IGFicmlkZ2luZyB0aGUgZnJlZWRvbSBvZg0Kc3BlZWNoLCBvciBvZiB0aGUgcHJlc3M7IG9yIHRo ZSByaWdodCBvZiB0aGUgcGVvcGxlIHBlYWNlYWJseSB0bw0KYXNzZW1ibGUsIGFuZCB0byBwZXRp dGlvbiB0aGUgZ292ZXJubWVudCBmb3IgYSByZWRyZXNzIG9mIGdyaWV2YW5jZXMuDQoNCi0tLS0t QkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQoNCmlRRWNCQUVCQ0FBR0JRSlluUmMvQUFvSkVLNksz eXJjK1J1RGZPVUlBSTkzVmMyMjEzajVMTlk4dGMxVFdjN0kNCmZTZ2tpUkNHajR5czFPNWRTM05j OWszMG5WSkN6L2NOU2hHUlNtSUFuRllHQU1sTnhEc094ZHhiUHNsNUJVdkENCnFLaTh1MU1iSkV0 Y2ord3M2K1o5THdySHdSbUZmQkw0Tjc3SG10UjFSdG93cjdBS0s5bEYrZVd4RFlrL2JKcE8NClVV dDhuV3IzRVNBaTNiVy9hTEdacEdTODZCT0NHWHNuMzZzQUpUNUNEWFVVK3hnRTI2UHJoMU9FS0lW azRuZTMNClBFRW15OWRNUDh2TTUwTGZXN25yRm9BRU5BQmdWc29teUF3YnIxbE8xZFJUWEdXN0V1 WE4xQzVPYVZKdnZZWWQNCmsvUmdFeTlFdFdrMXZFMFNYMFRva2ZES1p3TUdNUlpQbG45UWt1WU5y dDFmRFdkczcvaEdtOUtCcGluWjhLOD0NCj1GS2pBDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0NCg== From owner-freebsd-arm@freebsd.org Fri Feb 10 15:03:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E443ACD896E; Fri, 10 Feb 2017 15:03:05 +0000 (UTC) (envelope-from wolfgang.meyer@hob.de) Received: from hobex29.hob.de (hobex19.hob.de [212.185.199.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52C24141A; Fri, 10 Feb 2017 15:03:01 +0000 (UTC) (envelope-from wolfgang.meyer@hob.de) Received: from HOBEX12.hob.de (172.22.1.12) by hobex19.hob.de (172.25.1.31) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 10 Feb 2017 16:01:22 +0100 Received: from HOBEX11.hob.de ([fe80::b99f:1c54:7122:49b4]) by HOBEX12.hob.de ([::1]) with mapi id 14.02.0387.000; Fri, 10 Feb 2017 16:01:43 +0100 From: "Meyer, Wolfgang" To: "'freebsd-arm@FreeBSD.org'" , "'freebsd-toolchain@FreeBSD.org'" Subject: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] Thread-Topic: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] Thread-Index: AdKDrhWkwDVgm5wmQJOmHv89OT16WQ== Date: Fri, 10 Feb 2017 15:01:42 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.71.140] old-x-esetresult: clean, is OK old-x-esetid: 4EB48F3AB80C29501FF7D7 x-esetresult: clean, is OK x-esetid: 4EB48F3AB80C29501FF7D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:03:06 -0000 Hello, I am gaining experience in building packages for aarch64 on an amd64 host u= sing poudriere and it works (most of the time) quite well but it is really = slow. In order to accelerate the build I wanted to crosscompile within poudriere = using the instructions provided in http://phaq.phunsites.net/2015/10/11/freebsd-on-armv6-cross-compile-perform= ance-optimization-for-poudriere/comment-page-1/ and getting it to work with aarch64. The first problems arose when trying to build the xdev target: > make XDEV=3Darm64 XDEV_ARCH=3Daarch64 xdev The build fails and after doing some not very educated hacks to workaround = the problems I get to the point where I do not have a clue on how to fix th= is. The error message looks like: =3D=3D=3D> lib/libc++ (obj,all,install) c++ -isystem //usr/aarch64-freebsd/usr/include -L//usr/aarch64-freebsd/usr/= lib --sysroot=3D//usr/aarch64-freebsd/ -B//usr/aarch64-freebsd/usr/libexec= -B//usr/aarch64-freebsd/usr/bin -B//usr/aarch64-freebsd/usr/lib -O2 -pip= e -isystem /usr/FBSD_src/src_head/contrib/libc++/include -isystem /usr/FBSD= _src/src_head/contrib/libcxxrt -nostdinc++ -nostdlib -DLIBCXXRT -MD -MF.dep= end.algorithm.o -MTalgorithm.o -fstack-protector-strong -Qunused-arguments = -std=3Dc++11 -Wno-c++11-extensions -c /usr/FBSD_src/src_head/contrib/libc= ++/src/algorithm.cpp -o algorithm.o In file included from /usr/FBSD_src/src_head/contrib/libc++/src/algorithm.c= pp:11: In file included from /usr/FBSD_src/src_head/contrib/libc++/include/random:= 1638: /usr/FBSD_src/src_head/contrib/libc++/include/cmath:313:12: error: no membe= r named 'signbit' in namespace 'std' using std::signbit; ~~~~~^ ... + some more errors of the same kind. Hence I tried another way to get a crosscompile toolchain for use in poudri= ere. When crosscompiling on the host we use at the moment the stuff generat= ed by the kernel-toolchain target of the src tree (+ the sysroot and + the = aarch64-binutils from the ports as the kernel-toolchain does not build a cr= osscompile lld for aarch64). So I looked whether I would be able to import = this setup in a poudriere jail. Therefore I made the kernel-toolchain build= with the MAKEOBJDIRPREFIX set to the /usr/obj dir within the jail as shown= in the above mentioned link. The contents of the $MAKEOBJDIRPREFIX/usr/src= /tmp/ directory were copied to the /usr/aarch64-freebsd dir in the jail to = have a seperated toolchain directory. In the first try I did not add a cross-linker hoping the native lld in the = jail would be able to do the work. Well it won't. After learning how to ent= er the poudriere jail and looking at the verbose output from the compilatio= n I concluded that the compiler seemed to work but the linker failed. Next = step was installing the aarch64-binutils from ports in the jail (in my /usr= /aarch-freebsd cross-toolchain directory). Still no success as the linker c= omplained about some ELF interpreter /libexec/ld-elf.so.1 not found error. Which I ascribed to the fact that the executables from the aarch64-b= inutls port are dynamically linked. Adding a LDFLAGS+=3D -all-static line to the binutils ports Makefile I was able to create a statically linke= d linker and installed it in my poudriere jail. Still no success though, as= again similar errors occured like for the usage of the native linker (comp= laining about missing crt1.o files and missing lgcc_somethings). To make the long story short, after comparing the verbose output of my comp= iling in the jails with that of a direct crosscompile I found out that it w= as able to correctly link some object files when providing absolute paths t= o the crt*.o files and correct library search path for the libgcc_something= libraries. Which of course doesn't help when the linker is implicitly call= ed by the compiler. Further research showed that I could crosscompile/link = when providing the --sysroot=3D/ flag to overwrite the sysroot configuratio= n from the build of the crosscompiler. Amending the lines CFLAGS+=3D--sysroot=3D/ CPPFLAGS+=3D--sysroot=3D/ (Don't know if needed) CXXFLAGS+=3D--sysroot=3D/ LDFLAGS+=3D--sysroot=3D/ to my poudriere make.conf file I finally was able to produce a working cros= s-compiled package for aarch64 in poudriere. And the gains are quite signif= icant (around 21 minutes for building pkg package with qemu-user emulation = vs 5 minutes using cross-compilation, native amd64 build in poudriere finis= hes in less than a minute). Still the creation of the cross-compiling toolchain seems to be quite cumbe= rsome. Hence advice on getting such a toolchain in a cleaner way (ideally p= robably a working build for the xdev target) are greatly appreciated. ________________________________ Follow HOB: - HOB: http://www.hob.de/redirect/hob.html - Xing: http://www.hob.de/redirect/xing.html - LinkedIn: http://www.hob.de/redirect/linkedin.html - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html - Facebook: http://www.hob.de/redirect/facebook.html - Twitter: http://www.hob.de/redirect/twitter.html - YouTube: http://www.hob.de/redirect/youtube.html - E-Mail: http://www.hob.de/redirect/mail.html HOB GmbH & Co. KG Schwadermuehlstr. 3 D-90556 Cadolzburg Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic AG Fuerth, HRA 5180 Steuer-Nr. 218/163/00107 USt-ID-Nr. DE 132747002 Komplementaerin HOB electronic Beteiligungs GmbH AG Fuerth, HRB 3416 From owner-freebsd-arm@freebsd.org Fri Feb 10 15:59:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1927CD9102 for ; Fri, 10 Feb 2017 15:59:11 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (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 6E0A217EE for ; Fri, 10 Feb 2017 15:59:10 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id ECE063761C31 for ; Fri, 10 Feb 2017 16:49:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id DFAD93761D7F for ; Fri, 10 Feb 2017 16:49:29 +0100 (CET) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U_zId0Yt6fXC for ; Fri, 10 Feb 2017 16:49:29 +0100 (CET) Received: from pc-alex.localnet (fwlabo.stormshield.eu [10.2.0.1]) by work.stormshield.eu (Postfix) with ESMTP id BE10C3761C31 for ; Fri, 10 Feb 2017 16:49:29 +0100 (CET) From: Alexandre Martins To: freebsd-arm@freebsd.org Subject: bcopy/memmove optimization broken ? Date: Fri, 10 Feb 2017 16:51:19 +0100 Message-ID: <5335118.oK1KXXDaG5@pc-alex> Organization: STORMSHIELD User-Agent: KMail/4.14.10 (FreeBSD/10.3-RELEASE-p7; KDE/4.14.10; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5297990.tDBggcDrPZ"; micalg="sha256"; protocol="application/pkcs7-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 15:59:11 -0000 --nextPart5297990.tDBggcDrPZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi all I see in the kernel code of bcopy/memmove an optimization if the copied= region=20 don't overlap: https://svnweb.freebsd.org/base/head/sys/arm/arm/support.S?view=3Dannot= ate#l403 I'm a newbie in ARM assembly, so, sorry if i'm wrong, but - R0 is the dst (1st parameter) - R1 is the src (2nd parameter) So : subcc r3, r0, r1 /* if (dst > src) r3 =3D dst - src */ subcs r3, r1, r0 /* if (src > dsr) r3 =3D src - dst */ cmp r3, r2 /* if (r3 < len) we have an overlap */ bcc PIC_SYM(_C_LABEL(memcpy), PLT) Seems to be inverted. Should it be that ? : subcs r3, r0, r1 /* if (dst > src) r3 =3D dst - src */ subcc r3, r1, r0 /* if (src > dsr) r3 =3D src - dst */ cmp r3, r2 /* if (r3 < len) we have an overlap */ bcs PIC_SYM(_C_LABEL(memcpy), PLT) Best regards =2D-=20 Alexandre Martins STORMSHIELD --nextPart5297990.tDBggcDrPZ Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCOUw ggSGMIICbqADAgECAgUA28zw7TANBgkqhkiG9w0BAQsFADBIMQswCQYDVQQGEwJGUjEUMBIGA1UE CgwLU1RPUk1TSElFTEQxIzAhBgNVBAMMGlN0b3Jtc2hpZWxkIFJvb3QgQXV0aG9yaXR5MB4XDTE0 MDkwNDE1MDcxMFoXDTI0MDkwMTE1MDcxMFowSTELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JN U0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVsZCBVc2VycyBBdXRob3JpdHkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDChwWgC/6VWKL7jgWI3eA2sVvRdOwuHcXsRAAXVWdlMC0ygg7u 45E78GhAnpdl8QbIu7x/Q2zOq6KttspwDEIjkoMLTZngLLlGjYJZPfuSoC6hl9R7vRd5f8Fhu3v0 xQ/7vzKYz4C836IGCrk31gmrPO0H0fxkyxCMfhoTTzue3oXW1IsmQwCrOPOu2Y82QANDhbifWLjI WJetnj58YRKR82KBs3Flbqxtp0mi9+IswMvCCRSoT+ORB73Cl6URt7Qm7BcD+qnkJ9uwlUC94dIl T2hX4ybY/w/ssA17Ew418fgyRCWQXzgjZgZ/XUcw2WP9dIggA7Pg+c/xeROJH1zvAgMBAAGjdjB0 MB0GA1UdDgQWBBShbYRsooCFBXx8dXWANMETW5fXgTAfBgNVHSMEGDAWgBS4Qqn6Z0Twf9NhjOyl x1CutL3sozAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjARBglghkgBhvhCAQEEBAMC AQYwDQYJKoZIhvcNAQELBQADggIBAE6C9zkt2J6dPm2KLbzRS6rBIYZNFi0X59g3ekQ2Sc4UWsq+ B3L86j5xnQSRnIM/DKV1+Q2UHbU/qsh4cto2fwTV6V+aJ07Vu/bJE1rAN4AI4V26ytf7VoBcBjVZ Jq8pHOMp/G2eQH7F1xqzml68DpKku66aUalkcC9IM82m7AW3YAyvDoYEAchv4qyL8qhVLLp6LNru 8ZOhMELhZLWl4ulw/SFDMhcBS6I4wC6icj71MLGSrr61vMktMdwQ+CGFQ5z5JbaxM61VgzKay8+g lw+xTbpnitrDfhkzHs2fdwOOur3vtNnNsrdBWiYPseJ2k4VGD7ov5kITQZckmZyF/V+Ir//agJQG VuwhDZCXgXOvrje+FLYp7tQ9pgSvLbluh1A+ywfyHnFI4n6tZy9SD3MIDgWR4KwFLM1Qmt3NQb32 tkq9Vm0jUcQXFfbnWKLA9krw3m8NmCqhL5PzpfOegYOc0QJWfMQamxeWxXMLk6uKisS//+VqfpCa 5Jx53t+9DmoN1+ob4jOprPaX6tfBBr5djah2yzPGjHEB52VgWXxIF9lCM2z7Qw+zFb2PIdNeSjIk NEFg/1orKAAa5gQXAQynN2J7E+aLf2XLhHcS0v+9yoisPEw9+Tb5F1uQh+gzYD5JUUYcYWncnX8g P8k6X+F5mQ/81IoNL/IejxJgy/LoMIIEVzCCAz+gAwIBAgIFAIUoy7swDQYJKoZIhvcNAQELBQAw STELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JNU0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVs ZCBVc2VycyBBdXRob3JpdHkwHhcNMTYwOTAxMTUxMTA4WhcNMTcwOTAxMTUxMTA4WjBwMQswCQYD VQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElFTEQxGjAYBgNVBAMMEUFsZXhhbmRyZSBNQVJUSU5T MS8wLQYJKoZIhvcNAQkBFiBhbGV4YW5kcmUubWFydGluc0BzdG9ybXNoaWVsZC5ldTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMN+CnvE13jKEwJ+OyMzwBpC02dY+LpD5luJwnJTVnV2 9aUjEMI+xGFMMHd9kSIVInbk4WDe1ELOKerg0dzgnkRiOHECSGum1UhcZABxQgY2cmSffNQ6JVro 52UaBlt3aTOk3imYJCHUIGgOWMvOtRc8BxyBHdi15FZPj/F9I+AKufRFsBXUakplFIAPEwy3m2eR a/eCMLqGJUyK7YmsAlEnYn2mA38zIoqtKvL6KPHtrV8fw1SRLQ13+j9nu1LlCaqhmLtILFxhV0/9 uDTvx5cKtZ8Xj1nPM6NUUrso9qlXwm4On6Y34pVTtnYGMQRuljil3Hiz84RJjPDJYRGwbgkCAwEA AaOCAR0wggEZMB0GA1UdDgQWBBTmRLIwSfhNwbdfV13xt0G0JHYjPDAfBgNVHSMEGDAWgBShbYRs ooCFBXx8dXWANMETW5fXgTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwID6DARBglghkgBhvhCAQEE BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHBzOi8vcGtpLm5ldGFzcS5jb20vYXV0aC9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0LmNybDAR BgNVHSAECjAIMAYGBFUdIAAwKwYDVR0RBCQwIoEgYWxleGFuZHJlLm1hcnRpbnNAc3Rvcm1zaGll bGQuZXUwDQYJKoZIhvcNAQELBQADggEBALT9NWiAaE6nDev34vShhsyb9lWBOQfCnAMyKwtFy/cU uIoHsxyOanIIQHz0ZtB76GCHDo7RStMyp6RYIefIsxABLhSr4hHapJka9g/X/nxexyr0xyT3IpYQ dmyMSHRT18Z/ZaBlQdyfnS2PYkPHJAHl4iqB4SnQlh3rwFdKTJMgCz413cDxQHytgRPGTiXOhyV7 aS3ANJFha6ZHA8HU9sTslY8ZXSUu94iD3t2kcF3gBb432UKALwryKqnrwzFX68pFpqO5QAjEHaF6 6p1agMb2b3HlQGZrME5wSO6rsZJPYvJEyvrwHxCxjSTkOdPw6GriWGTMrVMU0fVrfptMS1gxggIT MIICDwIBATBSMEkxCzAJBgNVBAYTAkZSMRQwEgYDVQQKDAtTVE9STVNISUVMRDEkMCIGA1UEAwwb U3Rvcm1zaGllbGQgVXNlcnMgQXV0aG9yaXR5AgUAhSjLuzANBglghkgBZQMEAgEFAKCBkzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTAxNTUxMTlaMCgGCSqG SIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCCxGLwW 2Vm7yBv+GC53rePsv3IPBgxmcXTlOHCkId0VojANBgkqhkiG9w0BAQEFAASCAQBRWpUF06Wa6/C4 pOH4tEjpGzaXgdSh9M1yuYIFnq7ZtqdfuYxDvq4zy8roBzX+gUbBQt/fswAPA7B3687s/jcaewYq cJ4/oiPihSfDfhqfopuOnqMP2w4TF8SKYBiXvXM9L2j+qTvTIJJYAADhUGPmtXUCSBpdiBmSI7XT 1+oE53S/Z+FtxoW/SJ4IDlBUe0tjRaqc4/LiRA5Tzhc+cegTjPNo1KzDbvnPmH8uAx+0Zx2rzgrU 3XgOCj83BewKkoNLzU2OpjK9jm+RuUyAbTiOiAvhntiDzBhqMYQB+xKsMwz7zvafPI4sgg8UFe1I 0csvamR4tKRnNFXUYoqX66fcAAAAAAAA --nextPart5297990.tDBggcDrPZ-- From owner-freebsd-arm@freebsd.org Fri Feb 10 16:04:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28750CD93F9; Fri, 10 Feb 2017 16:04:37 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.com (mail.synsport.com [208.69.230.148]) (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 021891EBB; Fri, 10 Feb 2017 16:04:36 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from [127.0.0.1] (ip72-204-83-236.fv.ks.cox.net [72.204.83.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.com (Postfix) with ESMTP id 4E3F943D23; Fri, 10 Feb 2017 10:02:50 -0600 (CST) Subject: Re: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] To: "Meyer, Wolfgang" , "'freebsd-arm@FreeBSD.org'" , "'freebsd-toolchain@FreeBSD.org'" References: From: John Marino Message-ID: Date: Fri, 10 Feb 2017 10:04:34 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170210-1, 02/10/2017), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:04:37 -0000 On 2/10/2017 09:01, Meyer, Wolfgang wrote: > Hello, > > I am gaining experience in building packages for aarch64 on an amd64 host using poudriere and it works (most of the time) quite well but it is really slow. > > In order to accelerate the build I wanted to crosscompile within poudriere using the instructions provided in > http://phaq.phunsites.net/2015/10/11/freebsd-on-armv6-cross-compile-performance-optimization-for-poudriere/comment-page-1/ > and getting it to work with aarch64. I don't know if this will help, but I created a proper [1] cross-compiler for aarch64 last week: http://www.freshports.org/lang/gnatcross-aarch64/ John [1] By proper, I mean based on FreeBSD/ARM64 sysroot (currently only Release 11.0 available) From owner-freebsd-arm@freebsd.org Fri Feb 10 16:20:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C1A9CD9A8B; Fri, 10 Feb 2017 16:20:29 +0000 (UTC) (envelope-from wolfgang.meyer@hob.de) Received: from hobex29.hob.de (hobex29.hob.de [212.185.199.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "HOBEX29", Issuer "HOBEX29" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C58DFFCC; Fri, 10 Feb 2017 16:20:27 +0000 (UTC) (envelope-from wolfgang.meyer@hob.de) Received: from HOBEX22.hob.de (172.22.1.22) by hobex29.hob.de (172.25.1.32) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 10 Feb 2017 17:18:53 +0100 Received: from HOBEX11.hob.de ([fe80::b99f:1c54:7122:49b4]) by HOBEX22.hob.de ([::1]) with mapi id 14.02.0387.000; Fri, 10 Feb 2017 17:19:13 +0100 From: "Meyer, Wolfgang" To: "Meyer, Wolfgang" , "'freebsd-arm@FreeBSD.org'" , "'freebsd-toolchain@FreeBSD.org'" Subject: RE: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] Thread-Topic: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] Thread-Index: AdKDrhWkwDVgm5wmQJOmHv89OT16WQACrmdQ Date: Fri, 10 Feb 2017 16:19:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.71.140] old-x-esetresult: clean, is OK old-x-esetid: 46BD7B394506373217FE23 x-esetresult: clean, is OK x-esetid: 46BD7B394506373217FE23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:20:29 -0000 > Hello, > > > To make the long story short, after comparing the verbose output of my > compiling in the jails with that of a direct crosscompile I found out tha= t it was > able to correctly link some object files when providing absolute paths to= the > crt*.o files and correct library search path for the libgcc_something lib= raries. > Which of course doesn't help when the linker is implicitly called by the > compiler. Further research showed that I could crosscompile/link when > providing the --sysroot=3D/ flag to overwrite the sysroot configuration f= rom the > build of the crosscompiler. Amending the lines > > CFLAGS+=3D--sysroot=3D/ > CPPFLAGS+=3D--sysroot=3D/ (Don't know if needed) > CXXFLAGS+=3D--sysroot=3D/ > LDFLAGS+=3D--sysroot=3D/ > > to my poudriere make.conf file I finally was able to produce a working cr= oss- > compiled package for aarch64 in poudriere. And the gains are quite signif= icant > (around 21 minutes for building pkg package with qemu-user emulation vs 5 > minutes using cross-compilation, native amd64 build in poudriere finishes= in > less than a minute). > > Still the creation of the cross-compiling toolchain seems to be quite > cumbersome. Hence advice on getting such a toolchain in a cleaner way > (ideally probably a working build for the xdev target) are greatly apprec= iated. > After building some more packages besides of pkg it seems, I am still not t= here yet. There is quite some fallout mainly during configure due to not ge= tting the right searchpath for the libraries. Maybe creating a symlink on t= he root directory at the path of the expected sysroot directory might heal = this. ________________________________ Follow HOB: - HOB: http://www.hob.de/redirect/hob.html - Xing: http://www.hob.de/redirect/xing.html - LinkedIn: http://www.hob.de/redirect/linkedin.html - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html - Facebook: http://www.hob.de/redirect/facebook.html - Twitter: http://www.hob.de/redirect/twitter.html - YouTube: http://www.hob.de/redirect/youtube.html - E-Mail: http://www.hob.de/redirect/mail.html HOB GmbH & Co. KG Schwadermuehlstr. 3 D-90556 Cadolzburg Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic AG Fuerth, HRA 5180 Steuer-Nr. 218/163/00107 USt-ID-Nr. DE 132747002 Komplementaerin HOB electronic Beteiligungs GmbH AG Fuerth, HRB 3416 From owner-freebsd-arm@freebsd.org Fri Feb 10 16:24:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDDBECD9C8A; Fri, 10 Feb 2017 16:24:55 +0000 (UTC) (envelope-from wolfgang.meyer@hob.de) Received: from hobex29.hob.de (hobex19.hob.de [212.185.199.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 869CF139A; Fri, 10 Feb 2017 16:24:54 +0000 (UTC) (envelope-from wolfgang.meyer@hob.de) Received: from HOBEX22.hob.de (172.22.1.22) by hobex19.hob.de (172.25.1.31) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 10 Feb 2017 17:24:29 +0100 Received: from HOBEX11.hob.de ([fe80::b99f:1c54:7122:49b4]) by HOBEX22.hob.de ([::1]) with mapi id 14.02.0387.000; Fri, 10 Feb 2017 17:24:47 +0100 From: "Meyer, Wolfgang" To: 'John Marino' , "'freebsd-arm@FreeBSD.org'" , "'freebsd-toolchain@FreeBSD.org'" Subject: RE: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] Thread-Topic: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] Thread-Index: AdKDrhWkwDVgm5wmQJOmHv89OT16WQAAOdkAAAKb3uA= Date: Fri, 10 Feb 2017 16:24:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.71.140] old-x-esetresult: clean, is OK old-x-esetid: 46BD7B394506373217FE21 x-esetresult: clean, is OK x-esetid: 46BD7B394506373217FE21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:24:56 -0000 > > Hello, > > > > I am gaining experience in building packages for aarch64 on an amd64 ho= st > using poudriere and it works (most of the time) quite well but it is real= ly slow. > > > > In order to accelerate the build I wanted to crosscompile within > > poudriere using the instructions provided in > > http://phaq.phunsites.net/2015/10/11/freebsd-on-armv6-cross-compile- > pe > > rformance-optimization-for-poudriere/comment-page-1/ > > and getting it to work with aarch64. > > I don't know if this will help, but I created a proper [1] cross-compiler= for > aarch64 last week: > http://www.freshports.org/lang/gnatcross-aarch64/ > > John > > [1] By proper, I mean based on FreeBSD/ARM64 sysroot (currently only > Release 11.0 available) > Thanks, I will look at it next week. Is there a documentation on how the to= olchain was created, or is it basically along the lines of normal gcc-based= toolchain creation? Although I somehow would prefer if I can manage to bas= e my cross-compile toolchain on the base system toolchain. Regards, Wolfgang ________________________________ Follow HOB: - HOB: http://www.hob.de/redirect/hob.html - Xing: http://www.hob.de/redirect/xing.html - LinkedIn: http://www.hob.de/redirect/linkedin.html - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html - Facebook: http://www.hob.de/redirect/facebook.html - Twitter: http://www.hob.de/redirect/twitter.html - YouTube: http://www.hob.de/redirect/youtube.html - E-Mail: http://www.hob.de/redirect/mail.html HOB GmbH & Co. KG Schwadermuehlstr. 3 D-90556 Cadolzburg Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic AG Fuerth, HRA 5180 Steuer-Nr. 218/163/00107 USt-ID-Nr. DE 132747002 Komplementaerin HOB electronic Beteiligungs GmbH AG Fuerth, HRB 3416 From owner-freebsd-arm@freebsd.org Fri Feb 10 16:30:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EC63CD9E46; Fri, 10 Feb 2017 16:30:19 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.com (mail.synsport.com [208.69.230.148]) (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 2A26B1699; Fri, 10 Feb 2017 16:30:18 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from [127.0.0.1] (ip72-204-83-236.fv.ks.cox.net [72.204.83.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.com (Postfix) with ESMTP id 89DB243C07; Fri, 10 Feb 2017 10:28:31 -0600 (CST) Subject: Re: How to get a crosscompile toolchain for aarch64 for use in poudriere[?] To: "Meyer, Wolfgang" , "'freebsd-arm@FreeBSD.org'" , "'freebsd-toolchain@FreeBSD.org'" References: From: John Marino Message-ID: Date: Fri, 10 Feb 2017 10:30:15 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170210-1, 02/10/2017), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:30:19 -0000 On 2/10/2017 10:24, Meyer, Wolfgang wrote: >> >> I don't know if this will help, but I created a proper [1] >> cross-compiler for aarch64 last week: >> http://www.freshports.org/lang/gnatcross-aarch64/ >> >> John >> >> [1] By proper, I mean based on FreeBSD/ARM64 sysroot (currently >> only Release 11.0 available) >> > > Thanks, I will look at it next week. Is there a documentation on how > the toolchain was created, or is it basically along the lines of > normal gcc-based toolchain creation? The ports makefiles are recipes. If you want to know how something is built, you look at those. There are many cross-compiler ports in the tree. The only thing special about this one is that a bootstrap compiler is used in order to build the Ada front-end. But that's just a case of specifying it over a base compiler. > Although I somehow would prefer > if I can manage to base my cross-compile toolchain on the base system > toolchain. Good luck, since that's impossible. Cross-compilers need their own set of binutils for the target system. You're not going to be able to do better than what I did. John From owner-freebsd-arm@freebsd.org Fri Feb 10 16:59:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80895CD9824 for ; Fri, 10 Feb 2017 16:59:42 +0000 (UTC) (envelope-from jletutour@deltadore.com) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0109.outbound.protection.outlook.com [104.47.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0992CB8 for ; Fri, 10 Feb 2017 16:59:41 +0000 (UTC) (envelope-from jletutour@deltadore.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deltadoregroup.onmicrosoft.com; s=selector1-deltadore-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qSoYgfllNC/fXsrj0KQOBKtLAwtsIF+GV34TPIO18O0=; b=iODa5oZAW3dSHJXrXbYB4n83CekdYcKM2WT1BN/+IMNVaLxcDeE3yxMYcF02WT5UlaxZeY3REH4zsZ3J1Wpz+OVL/cC3TJEAopSm1vIBZ/R8Lhj7einPyxgjV/KK8Nr3llaQksqrckc/xJHy1z2WsjlTAtEAef6HLhZcdwIhHG0= Received: from VI1PR07MB1406.eurprd07.prod.outlook.com (10.165.238.12) by VI1PR07MB1405.eurprd07.prod.outlook.com (10.165.238.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 10 Feb 2017 16:59:36 +0000 Received: from VI1PR07MB1406.eurprd07.prod.outlook.com ([10.165.238.12]) by VI1PR07MB1406.eurprd07.prod.outlook.com ([10.165.238.12]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 16:59:36 +0000 From: LE TUTOUR Jean To: Warner Losh CC: "freebsd-arm@freebsd.org" Subject: usb trouble cubox bsd 11 - FreeBSD 11.0-STABLE #0 r310359: Wed Dec 21 18:19:11 UTC 2016 Thread-Topic: usb trouble cubox bsd 11 - FreeBSD 11.0-STABLE #0 r310359: Wed Dec 21 18:19:11 UTC 2016 Thread-Index: AdKDtLXFgl0MyTd2SryRagdt+hVM8A== Date: Fri, 10 Feb 2017 16:59:36 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jletutour@deltadore.com; x-originating-ip: [57.197.54.10] x-ms-office365-filtering-correlation-id: 0fbfcd4c-b9ef-4f65-d5e1-08d451d631c5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB1405; x-microsoft-exchange-diagnostics: 1; VI1PR07MB1405; 7:/CVRlB3SXVn1p3jW93Svkegr8pT9pRM2YBy+Trr1evuPt7KAeuRFefBuws0gZz+ou63cOyKf7oXy6Z1fcxxGpwN8rvHTHg1TRxk0rNRMCORMeTDzDFML8WQW9mtQTPQ0c8AHZp7I8B3/TPEYYLJ0ukO6DQU2OFGogGp7aCpVgaVxoF/m4UkAHLEuqwaTsjFBy/2Hgv42WfBX4D3xLD40XnOZiStn7OpAeXhQ/wcK4EUq7jorv4LnrmuXV/56acdOA5TIsf1BH3VJJkWo9wB9MEXDvha5xQ+015d8Zqp30MDicSZz8Gk614kDJ3oZiIJYA15hkHIiq5tY5zljnua2J6qYR/NAbb5nbLRcXnUPPKMXHRFECz2pSj1b/HNUz2ESR5HXvBhglwIMPBYyJQR7pBuRifA33QlMmgdrhSicN14CN20rQMeRNWOdAdzjx0Xyu+ohZyqDGRSn+oE9mKDZURRtNSM/NE44OA+Bqj0DU12vSmYZ/WKjLs46mP9q0QovxFbRH//gye0THvK3c+Tauw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:VI1PR07MB1405; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1405; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39830400002)(377454003)(24454002)(55784002)(38334002)(189002)(13734003)(199003)(101416001)(106356001)(105586002)(6506006)(6436002)(33656002)(9686003)(77096006)(54356999)(3660700001)(55016002)(99286003)(8936002)(74316002)(81166006)(8676002)(6306002)(50986999)(81156014)(7736002)(25786008)(53386004)(6916009)(110136004)(305945005)(68736007)(966004)(38730400002)(122556002)(92566002)(4326007)(3280700002)(53946003)(66066001)(6116002)(2906002)(53936002)(3846002)(102836003)(2900100001)(5890100001)(86362001)(5660300001)(97736004)(7696004)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1405; H:VI1PR07MB1406.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: deltadore.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: deltadore.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 16:59:36.4471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 23f7ef23-d797-403b-9679-644130ba65cf X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1405 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:59:42 -0000 SGVsbG8sIGZyZWVic2QgdGVhbToNCg0KUGxlYXNlIHNlZSBsaXN0aW5nIGJlbG93DQpJIGhhdmUg dHdvIHByb2JsZW1zOg0KDQo+IHVzYiBzZWVtcyBub3Qgd29yayA6IG5vdGhpbmcgaW4gZG1lc2cg LCB3aGVuIEkgcGx1ZyBzb21ldGhpbmcgaW4gdXNiDQo+L3NiaW4vc2h1dGRvd246IFBlcm1pc3Np b24gZGVuaWVkLiAgOiAgSSBhbSAgZnJlZWJzZC9mcmVlYnNkDQoNCkRvbid0IHlvdSBoYXZlIGFu eSBpZGVhID8gSXQgd29ya3Mgb24gbGludXggLCBnZW5lcmFsbHksIHNvcnJ5DQpXaGl0aCBhIGRl YmlhbiAgb24gdGhlIHNhbWUgcGxhdGVmb3JtLCBubyBwcm9ibGVtcw0KDQpSZWdhcmRzDQoNCktp bmQgUmVnYXJkcw0KDQoNCg0KDQoNCg0KZnJlZWJzZEBpbXg2On4gJSBkbWVzZw0KQ29weXJpZ2h0 IChjKSAxOTkyLTIwMTYgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAoYykgMTk3OSwg MTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAg ICAgICBUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLg0KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBG cmVlQlNEIEZvdW5kYXRpb24uDQpGcmVlQlNEIDExLjAtU1RBQkxFICMwIHIzMTAzNTk6IFdlZCBE ZWMgMjEgMTg6MTk6MTEgVVRDIDIwMTYNCiAgICByb290QHJlbGVuZzIubnlpLmZyZWVic2Qub3Jn Oi91c3Ivb2JqL2FybS5hcm12Ni91c3Ivc3JjL3N5cy9JTVg2IGFybQ0KRnJlZUJTRCBjbGFuZyB2 ZXJzaW9uIDMuOC4wICh0YWdzL1JFTEVBU0VfMzgwL2ZpbmFsIDI2MjU2NCkgKGJhc2VkIG9uIExM Vk0gMy44LjApDQpWVDogaW5pdCB3aXRob3V0IGRyaXZlci4NCkNQVTogQ29ydGV4IEE5LXIyIHJl diAxMCAoQ29ydGV4LUEgY29yZSkNCiBTdXBwb3J0ZWQgZmVhdHVyZXM6IEFSTV9JU0EgVEhVTUIy IEpBWkVMTEUgVEhVTUJFRSBBUk12NCBTZWN1cml0eV9FeHQNCiBXQiBlbmFibGVkIExBQlQgYnJh bmNoIHByZWRpY3Rpb24gZGlzYWJsZWQNCkxvVVU6MiBMb0M6MiBMb1VJUzoyDQpDYWNoZSBsZXZl bCAxOg0KIDMyS0IvMzJCIDQtd2F5IGRhdGEgY2FjaGUgV0IgUmVhZC1BbGxvYyBXcml0ZS1BbGxv Yw0KIDMyS0IvMzJCIDQtd2F5IGluc3RydWN0aW9uIGNhY2hlIFJlYWQtQWxsb2MNCnJlYWwgbWVt b3J5ICA9IDIxNDc0ODM2NDggKDIwNDggTUIpDQphdmFpbCBtZW1vcnkgPSAyMDkwOTA5Njk2ICgx OTk0IE1CKQ0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBD UFVzDQpyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVyZmFjZQ0Ka2JkMCBhdCBr YmRtdXgwDQpvZndidXMwOiA8T3BlbiBGaXJtd2FyZSBEZXZpY2UgVHJlZT4NCnNpbXBsZWJ1czA6 IDxGbGF0dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24gb2Z3YnVzMA0Kc2ltcGxlYnVz MTogPEZsYXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBtZW0gMHgyMDAwMDAwLTB4MjBm ZmZmZiBvbiBzaW1wbGVidXMwDQpzaW1wbGVidXMyOiA8RmxhdHRlbmVkIGRldmljZSB0cmVlIHNp bXBsZSBidXM+IG1lbSAweDIwMDAwMDAtMHgyMDNmZmZmIG9uIHNpbXBsZWJ1czENCmlteDZfYW5h dG9wMDogPEZyZWVzY2FsZSBpLk1YNiBBbmFsb2cgUExMcyBhbmQgUG93ZXI+IG1lbSAweDIwYzgw MDAtMHgyMGM4ZmZmIGlycSA0Niw0Nyw0OCBvbiBzaW1wbGVidXMxDQpzaW1wbGVidXMzOiA8Rmxh dHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG1lbSAweDIxMDAwMDAtMHgyMWZmZmZmIG9u IHNpbXBsZWJ1czANCm9jb3RwMDogPEZyZWVzY2FsZSBPbi1DaGlwIE9uZS1UaW1lLVByb2dyYW1t YWJsZSBNZW1vcnk+IG1lbSAweDIxYmMwMDAtMHgyMWJmZmZmIG9uIHNpbXBsZWJ1czMNCmNjbTA6 IDxGcmVlc2NhbGUgaS5NWDYgQ2xvY2sgQ29udHJvbCBNb2R1bGU+IG1lbSAweDIwYzQwMDAtMHgy MGM3ZmZmIGlycSA0NCw0NSBvbiBzaW1wbGVidXMxDQpsMmNhY2hlMDogPFBMMzEwIEwyIGNhY2hl IGNvbnRyb2xsZXI+IG1lbSAweGEwMjAwMC0weGEwMmZmZiBpcnEgOSBvbiBzaW1wbGVidXMwDQps MmNhY2hlMDogY2Fubm90IGFsbG9jYXRlIElSUSwgbm90IHVzaW5nIGludGVycnVwdA0KbDJjYWNo ZTA6IFBhcnQgbnVtYmVyOiAweDMsIHJlbGVhc2U6IDB4Nw0KbDJjYWNoZTA6IEwyIENhY2hlIGVu YWJsZWQ6IDEwMjRLQi8zMkIgMTYgd2F5cw0KaW14X2lvbXV4MDogPEZyZWVzY2FsZSBpLk1YIHBp biBjb25maWd1cmF0aW9uPiBtZW0gMHgyMGUwMDAwLTB4MjBlM2ZmZiBvbiBzaW1wbGVidXMxDQpn aWMwOiA8QVJNIEdlbmVyaWMgSW50ZXJydXB0IENvbnRyb2xsZXI+IG1lbSAweGEwMTAwMC0weGEw MWZmZiwweGEwMDEwMC0weGEwMDFmZiBvbiBzaW1wbGVidXMwDQpnaWMwOiBwbiAweDM5MCwgYXJj aCAweDEsIHJldiAweDIsIGltcGxlbWVudGVyIDB4NDNiIGlycXMgMTYwDQppbXhfZ3B0MDogPEZy ZWVzY2FsZSBpLk1YIEdQVCB0aW1lcj4gbWVtIDB4MjA5ODAwMC0weDIwOWJmZmYgaXJxIDI2IG9u IHNpbXBsZWJ1czENCkV2ZW50IHRpbWVyICJpTVhHUFQiIGZyZXF1ZW5jeSA2NjAwMDAwMCBIeiBx dWFsaXR5IDgwMA0KVGltZWNvdW50ZXIgImlNWEdQVCIgZnJlcXVlbmN5IDY2MDAwMDAwIEh6IHF1 YWxpdHkgMTAwMA0KbXBfdG1yMDogPEFSTSBNUENvcmUgVGltZXJzPiBtZW0gMHhhMDA2MDAtMHhh MDA2MWYgaXJxIDggb24gc2ltcGxlYnVzMA0KRXZlbnQgdGltZXIgIk1QQ29yZSIgZnJlcXVlbmN5 IDQ5MjAwMDAwMCBIeiBxdWFsaXR5IDEwMDANCmhkbWkwOiA8RnJlZXNjYWxlIGkuTVg2IEhETUkg Y29yZT4gbWVtIDB4MTIwMDAwLTB4MTI4ZmZmIGlycSA1IG9uIHNpbXBsZWJ1czANCmhkbWkwOiBI RE1JIGNvbnRyb2xsZXIgMTM6MGE6YTA6YzENCnVhcnQwOiA8RnJlZXNjYWxlIGkuTVggVUFSVD4g bWVtIDB4MjAyMDAwMC0weDIwMjNmZmYgaXJxIDY2IG9uIHNpbXBsZWJ1czINCnVhcnQwOiBjb25z b2xlICgxMTUyMDAsbiw4LDEpDQpncGlvMDogPEZyZWVzY2FsZSBpLk1YIEdQSU8gQ29udHJvbGxl cj4gbWVtIDB4MjA5YzAwMC0weDIwOWZmZmYgaXJxIDI3LDI4IG9uIHNpbXBsZWJ1czENCmdwaW9i dXMwOiA8R1BJTyBidXM+IG9uIGdwaW8wDQpncGlvYzA6IDxHUElPIGNvbnRyb2xsZXI+IG9uIGdw aW8wDQpncGlvMTogPEZyZWVzY2FsZSBpLk1YIEdQSU8gQ29udHJvbGxlcj4gbWVtIDB4MjBhMDAw MC0weDIwYTNmZmYgaXJxIDI5LDMwIG9uIHNpbXBsZWJ1czENCmdwaW9idXMxOiA8R1BJTyBidXM+ IG9uIGdwaW8xDQpncGlvYzE6IDxHUElPIGNvbnRyb2xsZXI+IG9uIGdwaW8xDQpncGlvMjogPEZy ZWVzY2FsZSBpLk1YIEdQSU8gQ29udHJvbGxlcj4gbWVtIDB4MjBhNDAwMC0weDIwYTdmZmYgaXJx IDMxLDMyIG9uIHNpbXBsZWJ1czENCmdwaW9idXMyOiA8R1BJTyBidXM+IG9uIGdwaW8yDQpncGlv YzI6IDxHUElPIGNvbnRyb2xsZXI+IG9uIGdwaW8yDQpncGlvMzogPEZyZWVzY2FsZSBpLk1YIEdQ SU8gQ29udHJvbGxlcj4gbWVtIDB4MjBhODAwMC0weDIwYWJmZmYgaXJxIDMzLDM0IG9uIHNpbXBs ZWJ1czENCmdwaW9idXMzOiA8R1BJTyBidXM+IG9uIGdwaW8zDQpncGlvYzM6IDxHUElPIGNvbnRy b2xsZXI+IG9uIGdwaW8zDQpncGlvNDogPEZyZWVzY2FsZSBpLk1YIEdQSU8gQ29udHJvbGxlcj4g bWVtIDB4MjBhYzAwMC0weDIwYWZmZmYgaXJxIDM1LDM2IG9uIHNpbXBsZWJ1czENCmdwaW9idXM0 OiA8R1BJTyBidXM+IG9uIGdwaW80DQpncGlvYzQ6IDxHUElPIGNvbnRyb2xsZXI+IG9uIGdwaW80 DQpncGlvNTogPEZyZWVzY2FsZSBpLk1YIEdQSU8gQ29udHJvbGxlcj4gbWVtIDB4MjBiMDAwMC0w eDIwYjNmZmYgaXJxIDM3LDM4IG9uIHNpbXBsZWJ1czENCmdwaW9idXM1OiA8R1BJTyBidXM+IG9u IGdwaW81DQpncGlvYzU6IDxHUElPIGNvbnRyb2xsZXI+IG9uIGdwaW81DQpncGlvNjogPEZyZWVz Y2FsZSBpLk1YIEdQSU8gQ29udHJvbGxlcj4gbWVtIDB4MjBiNDAwMC0weDIwYjdmZmYgaXJxIDM5 LDQwIG9uIHNpbXBsZWJ1czENCmdwaW9idXM2OiA8R1BJTyBidXM+IG9uIGdwaW82DQpncGlvYzY6 IDxHUElPIGNvbnRyb2xsZXI+IG9uIGdwaW82DQppbXhfd2RvZzA6IDxGcmVlc2NhbGUgaS5NWCBX YXRjaGRvZz4gbWVtIDB4MjBiYzAwMC0weDIwYmZmZmYgaXJxIDQyIG9uIHNpbXBsZWJ1czENCnVz YnBoeTA6IDxGcmVlc2NhbGUgaS5NWDYgVVNCIFBIWT4gbWVtIDB4MjBjOTAwMC0weDIwYzlmZmYg aXJxIDUwIG9uIHNpbXBsZWJ1czENCnVzYnBoeTE6IDxGcmVlc2NhbGUgaS5NWDYgVVNCIFBIWT4g bWVtIDB4MjBjYTAwMC0weDIwY2FmZmYgaXJxIDUxIG9uIHNpbXBsZWJ1czENCnNyYzA6IDxGcmVl c2NhbGUgaS5NWDYgU3lzdGVtIFJlc2V0IENvbnRyb2xsZXI+IG1lbSAweDIwZDgwMDAtMHgyMGRi ZmZmIGlycSA1NCw1NSBvbiBzaW1wbGVidXMxDQplaGNpMDogPEZyZWVzY2FsZSBpLk1YIGludGVn cmF0ZWQgVVNCIGNvbnRyb2xsZXI+IG1lbSAweDIxODQwMDAtMHgyMTg0MWZmIGlycSA3MyBvbiBz aW1wbGVidXMzDQp1c2J1czA6IEVIQ0kgdmVyc2lvbiAxLjANCnVzYnVzMCBvbiBlaGNpMA0KZWhj aTE6IDxGcmVlc2NhbGUgaS5NWCBpbnRlZ3JhdGVkIFVTQiBjb250cm9sbGVyPiBtZW0gMHgyMTg0 MjAwLTB4MjE4NDNmZiBpcnEgNzQgb24gc2ltcGxlYnVzMw0KdXNidXMxOiBFSENJIHZlcnNpb24g MS4wDQp1c2J1czEgb24gZWhjaTENCmZmZWMwOiA8RnJlZXNjYWxlIEdpZ2FiaXQgRXRoZXJuZXQg Q29udHJvbGxlcj4gbWVtIDB4MjE4ODAwMC0weDIxOGJmZmYgaXJxIDc3LDc4IG9uIHNpbXBsZWJ1 czMNCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBmZmVjMA0KYXRwaHkwOiA8QXRoZXJvcyBGMSAxMC8x MDAvMTAwMCBQSFk+IFBIWSA0IG9uIG1paWJ1czANCmF0cGh5MDogIG5vbmUsIDEwYmFzZVQsIDEw YmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlU1gtRkRYLCAxMDAw YmFzZVQtRkRYLCAxMDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bw0KZmZlYzA6IEV0aGVybmV0IGFk ZHJlc3M6IGQwOjYzOmI0OjAwOjk5OjY5DQpzZGhjaV9pbXgwOiA8RnJlZXNjYWxlIHVTREhDIGNv bnRyb2xsZXI+IG1lbSAweDIxOTAwMDAtMHgyMTkzZmZmIGlycSA4MiBvbiBzaW1wbGVidXMzDQpt bWMwOiA8TU1DL1NEIGJ1cz4gb24gc2RoY2lfaW14MA0Kc2RoY2lfaW14MTogPEZyZWVzY2FsZSB1 U0RIQyBjb250cm9sbGVyPiBtZW0gMHgyMTk0MDAwLTB4MjE5N2ZmZiBpcnEgODMgb24gc2ltcGxl YnVzMw0KbW1jMTogPE1NQy9TRCBidXM+IG9uIHNkaGNpX2lteDENCmlpY2hiMDogPEZyZWVzY2Fs ZSBpLk1YIEkyQz4gbWVtIDB4MjFhNDAwMC0weDIxYTdmZmYgaXJxIDg3IG9uIHNpbXBsZWJ1czMN CmlpY2J1czA6IDxPRlcgSTJDIGJ1cz4gb24gaWljaGIwDQppaWMwOiA8STJDIGdlbmVyaWMgSS9P PiBvbiBpaWNidXMwDQppaWNoYjE6IDxGcmVlc2NhbGUgaS5NWCBJMkM+IG1lbSAweDIxYTgwMDAt MHgyMWFiZmZmIGlycSA4OCBvbiBzaW1wbGVidXMzDQppaWNidXMxOiA8T0ZXIEkyQyBidXM+IG9u IGlpY2hiMQ0KaWljMTogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzMQ0KaWljYnVzMTogPHVu a25vd24gY2FyZD4gYXQgYWRkciAweGQwDQp1YXJ0MTogPEZyZWVzY2FsZSBpLk1YIFVBUlQ+IG1l bSAweDIxZjAwMDAtMHgyMWYzZmZmIGlycSA5NSBvbiBzaW1wbGVidXMzDQpmYjA6IDxGcmVlc2Nh bGUgSVBVPiBtZW0gMHgyNDAwMDAwLTB4MjdmZmZmZiBpcnEgMTIsMTMgb24gc2ltcGxlYnVzMA0K Y3B1bGlzdDA6IDxPcGVuIEZpcm13YXJlIENQVSBHcm91cD4gb24gb2Z3YnVzMA0KY3B1MDogPE9w ZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KY3B1MTogPE9wZW4gRmlybXdhcmUgQ1BVPiBv biBjcHVsaXN0MA0KY3B1MjogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KY3B1Mzog PE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KY3J5cHRvc29mdDA6IDxzb2Z0d2FyZSBj cnlwdG8+DQpUaW1lY291bnRlcnMgdGljayBldmVyeSAyLjAwMCBtc2VjDQpoZG1pMDogcmVhZGlu ZyBFRElEIGZyb20gaWljYnVzMCwgYWRkciA1MA0KdXNidXMwOiA0ODBNYnBzIEhpZ2ggU3BlZWQg VVNCIHYyLjANCnVzYnVzMTogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQp1Z2VuMC4xOiA8 RnJlZXNjYWxlIEVIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMA0KdWh1YjA6IDxGcmVlc2NhbGUgRUhD SSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMA0K dWdlbjEuMTogPEZyZWVzY2FsZSBFSENJIHJvb3QgSFVCPiBhdCB1c2J1czENCnVodWIxOiA8RnJl ZXNjYWxlIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBv biB1c2J1czENCmZiZDAgb24gZmIwDQpWVDogaW5pdGlhbGl6ZSB3aXRoIG5ldyBWVCBkcml2ZXIg ImZiIi4NCm1tYzA6IE5vIGNvbXBhdGlibGUgY2FyZHMgZm91bmQgb24gYnVzDQptbWNzZDA6IDRH QiA8U0RIQyBTUzA0RyA4LjAgU04gNTMyQzQ4RUUgTUZHIDEyLzIwMTUgYnkgMyBTRD4gYXQgbW1j MSA1MC4wTUh6LzRiaXQvNjU1MzUtYmxvY2sNClJlbGVhc2UgQVBzDQpUcnlpbmcgdG8gbW91bnQg cm9vdCBmcm9tIHVmczovZGV2L3Vmcy9yb290ZnMgW3J3XS4uLg0KdWh1YjA6IDEgcG9ydCB3aXRo IDEgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVodWIxOiAxIHBvcnQgd2l0aCAxIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkDQpXQVJOSU5HOiAvcmVsZW5nLzExLWFybXY2LUNVQk9YLUhVTU1JTkdC T0FSRC1zbmFwL3Vzci9vYmovdXNyL3NyYy9yZWxlYXNlL3VmcyB3YXMgbm90IHByb3Blcmx5IGRp c21vdW50ZWQNCndhcm5pbmc6IG5vIHRpbWUtb2YtZGF5IGNsb2NrIHJlZ2lzdGVyZWQsIHN5c3Rl bSB0aW1lIHdpbGwgbm90IGJlIHNldCBhY2N1cmF0ZWx5DQpyYW5kb206IHVuYmxvY2tpbmcgZGV2 aWNlLg0KZmZlYzA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpmZmVjMDogbGluayBzdGF0 ZSBjaGFuZ2VkIHRvIFVQDQpmcmVlYnNkQGlteDY6fiAlIGRtZXNnDQpDb3B5cmlnaHQgKGMpIDE5 OTItMjAxNiBUaGUgRnJlZUJTRCBQcm9qZWN0Lg0KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAx OTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0DQogICAgICAgIFRo ZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0Qg Rm91bmRhdGlvbi4NCkZyZWVCU0QgMTEuMC1TVEFCTEUgIzAgcjMxMDM1OTogV2VkIERlYyAyMSAx ODoxOToxMSBVVEMgMjAxNg0KICAgIHJvb3RAcmVsZW5nMi5ueWkuZnJlZWJzZC5vcmc6L3Vzci9v YmovYXJtLmFybXY2L3Vzci9zcmMvc3lzL0lNWDYgYXJtDQpGcmVlQlNEIGNsYW5nIHZlcnNpb24g My44LjAgKHRhZ3MvUkVMRUFTRV8zODAvZmluYWwgMjYyNTY0KSAoYmFzZWQgb24gTExWTSAzLjgu MCkNClZUOiBpbml0IHdpdGhvdXQgZHJpdmVyLg0KQ1BVOiBDb3J0ZXggQTktcjIgcmV2IDEwIChD b3J0ZXgtQSBjb3JlKQ0KIFN1cHBvcnRlZCBmZWF0dXJlczogQVJNX0lTQSBUSFVNQjIgSkFaRUxM RSBUSFVNQkVFIEFSTXY0IFNlY3VyaXR5X0V4dA0KIFdCIGVuYWJsZWQgTEFCVCBicmFuY2ggcHJl ZGljdGlvbiBkaXNhYmxlZA0KTG9VVToyIExvQzoyIExvVUlTOjINCkNhY2hlIGxldmVsIDE6DQog MzJLQi8zMkIgNC13YXkgZGF0YSBjYWNoZSBXQiBSZWFkLUFsbG9jIFdyaXRlLUFsbG9jDQogMzJL Qi8zMkIgNC13YXkgaW5zdHJ1Y3Rpb24gY2FjaGUgUmVhZC1BbGxvYw0KcmVhbCBtZW1vcnkgID0g MjE0NzQ4MzY0OCAoMjA0OCBNQikNCmF2YWlsIG1lbW9yeSA9IDIwOTA5MDk2OTYgKDE5OTQgTUIp DQpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA0IENQVXMNCnJh bmRvbTogZW50cm9weSBkZXZpY2UgZXh0ZXJuYWwgaW50ZXJmYWNlDQprYmQwIGF0IGtiZG11eDAN Cm9md2J1czA6IDxPcGVuIEZpcm13YXJlIERldmljZSBUcmVlPg0Kc2ltcGxlYnVzMDogPEZsYXR0 ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMwDQpzaW1wbGVidXMxOiA8Rmxh dHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG1lbSAweDIwMDAwMDAtMHgyMGZmZmZmIG9u IHNpbXBsZWJ1czANCnNpbXBsZWJ1czI6IDxGbGF0dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1 cz4gbWVtIDB4MjAwMDAwMC0weDIwM2ZmZmYgb24gc2ltcGxlYnVzMQ0KaW14Nl9hbmF0b3AwOiA8 RnJlZXNjYWxlIGkuTVg2IEFuYWxvZyBQTExzIGFuZCBQb3dlcj4gbWVtIDB4MjBjODAwMC0weDIw YzhmZmYgaXJxIDQ2LDQ3LDQ4IG9uIHNpbXBsZWJ1czENCnNpbXBsZWJ1czM6IDxGbGF0dGVuZWQg ZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gbWVtIDB4MjEwMDAwMC0weDIxZmZmZmYgb24gc2ltcGxl YnVzMA0Kb2NvdHAwOiA8RnJlZXNjYWxlIE9uLUNoaXAgT25lLVRpbWUtUHJvZ3JhbW1hYmxlIE1l bW9yeT4gbWVtIDB4MjFiYzAwMC0weDIxYmZmZmYgb24gc2ltcGxlYnVzMw0KY2NtMDogPEZyZWVz Y2FsZSBpLk1YNiBDbG9jayBDb250cm9sIE1vZHVsZT4gbWVtIDB4MjBjNDAwMC0weDIwYzdmZmYg aXJxIDQ0LDQ1IG9uIHNpbXBsZWJ1czENCmwyY2FjaGUwOiA8UEwzMTAgTDIgY2FjaGUgY29udHJv bGxlcj4gbWVtIDB4YTAyMDAwLTB4YTAyZmZmIGlycSA5IG9uIHNpbXBsZWJ1czANCmwyY2FjaGUw OiBjYW5ub3QgYWxsb2NhdGUgSVJRLCBub3QgdXNpbmcgaW50ZXJydXB0DQpsMmNhY2hlMDogUGFy dCBudW1iZXI6IDB4MywgcmVsZWFzZTogMHg3DQpsMmNhY2hlMDogTDIgQ2FjaGUgZW5hYmxlZDog MTAyNEtCLzMyQiAxNiB3YXlzDQppbXhfaW9tdXgwOiA8RnJlZXNjYWxlIGkuTVggcGluIGNvbmZp Z3VyYXRpb24+IG1lbSAweDIwZTAwMDAtMHgyMGUzZmZmIG9uIHNpbXBsZWJ1czENCmdpYzA6IDxB Uk0gR2VuZXJpYyBJbnRlcnJ1cHQgQ29udHJvbGxlcj4gbWVtIDB4YTAxMDAwLTB4YTAxZmZmLDB4 YTAwMTAwLTB4YTAwMWZmIG9uIHNpbXBsZWJ1czANCmdpYzA6IHBuIDB4MzkwLCBhcmNoIDB4MSwg cmV2IDB4MiwgaW1wbGVtZW50ZXIgMHg0M2IgaXJxcyAxNjANCmlteF9ncHQwOiA8RnJlZXNjYWxl IGkuTVggR1BUIHRpbWVyPiBtZW0gMHgyMDk4MDAwLTB4MjA5YmZmZiBpcnEgMjYgb24gc2ltcGxl YnVzMQ0KRXZlbnQgdGltZXIgImlNWEdQVCIgZnJlcXVlbmN5IDY2MDAwMDAwIEh6IHF1YWxpdHkg ODAwDQpUaW1lY291bnRlciAiaU1YR1BUIiBmcmVxdWVuY3kgNjYwMDAwMDAgSHogcXVhbGl0eSAx MDAwDQptcF90bXIwOiA8QVJNIE1QQ29yZSBUaW1lcnM+IG1lbSAweGEwMDYwMC0weGEwMDYxZiBp cnEgOCBvbiBzaW1wbGVidXMwDQpFdmVudCB0aW1lciAiTVBDb3JlIiBmcmVxdWVuY3kgNDkyMDAw MDAwIEh6IHF1YWxpdHkgMTAwMA0KaGRtaTA6IDxGcmVlc2NhbGUgaS5NWDYgSERNSSBjb3JlPiBt ZW0gMHgxMjAwMDAtMHgxMjhmZmYgaXJxIDUgb24gc2ltcGxlYnVzMA0KaGRtaTA6IEhETUkgY29u dHJvbGxlciAxMzowYTphMDpjMQ0KdWFydDA6IDxGcmVlc2NhbGUgaS5NWCBVQVJUPiBtZW0gMHgy MDIwMDAwLTB4MjAyM2ZmZiBpcnEgNjYgb24gc2ltcGxlYnVzMg0KdWFydDA6IGNvbnNvbGUgKDEx NTIwMCxuLDgsMSkNCmdwaW8wOiA8RnJlZXNjYWxlIGkuTVggR1BJTyBDb250cm9sbGVyPiBtZW0g MHgyMDljMDAwLTB4MjA5ZmZmZiBpcnEgMjcsMjggb24gc2ltcGxlYnVzMQ0KZ3Bpb2J1czA6IDxH UElPIGJ1cz4gb24gZ3BpbzANCmdwaW9jMDogPEdQSU8gY29udHJvbGxlcj4gb24gZ3BpbzANCmdw aW8xOiA8RnJlZXNjYWxlIGkuTVggR1BJTyBDb250cm9sbGVyPiBtZW0gMHgyMGEwMDAwLTB4MjBh M2ZmZiBpcnEgMjksMzAgb24gc2ltcGxlYnVzMQ0KZ3Bpb2J1czE6IDxHUElPIGJ1cz4gb24gZ3Bp bzENCmdwaW9jMTogPEdQSU8gY29udHJvbGxlcj4gb24gZ3BpbzENCmdwaW8yOiA8RnJlZXNjYWxl IGkuTVggR1BJTyBDb250cm9sbGVyPiBtZW0gMHgyMGE0MDAwLTB4MjBhN2ZmZiBpcnEgMzEsMzIg b24gc2ltcGxlYnVzMQ0KZ3Bpb2J1czI6IDxHUElPIGJ1cz4gb24gZ3BpbzINCmdwaW9jMjogPEdQ SU8gY29udHJvbGxlcj4gb24gZ3BpbzINCmdwaW8zOiA8RnJlZXNjYWxlIGkuTVggR1BJTyBDb250 cm9sbGVyPiBtZW0gMHgyMGE4MDAwLTB4MjBhYmZmZiBpcnEgMzMsMzQgb24gc2ltcGxlYnVzMQ0K Z3Bpb2J1czM6IDxHUElPIGJ1cz4gb24gZ3BpbzMNCmdwaW9jMzogPEdQSU8gY29udHJvbGxlcj4g b24gZ3BpbzMNCmdwaW80OiA8RnJlZXNjYWxlIGkuTVggR1BJTyBDb250cm9sbGVyPiBtZW0gMHgy MGFjMDAwLTB4MjBhZmZmZiBpcnEgMzUsMzYgb24gc2ltcGxlYnVzMQ0KZ3Bpb2J1czQ6IDxHUElP IGJ1cz4gb24gZ3BpbzQNCmdwaW9jNDogPEdQSU8gY29udHJvbGxlcj4gb24gZ3BpbzQNCmdwaW81 OiA8RnJlZXNjYWxlIGkuTVggR1BJTyBDb250cm9sbGVyPiBtZW0gMHgyMGIwMDAwLTB4MjBiM2Zm ZiBpcnEgMzcsMzggb24gc2ltcGxlYnVzMQ0KZ3Bpb2J1czU6IDxHUElPIGJ1cz4gb24gZ3BpbzUN CmdwaW9jNTogPEdQSU8gY29udHJvbGxlcj4gb24gZ3BpbzUNCmdwaW82OiA8RnJlZXNjYWxlIGku TVggR1BJTyBDb250cm9sbGVyPiBtZW0gMHgyMGI0MDAwLTB4MjBiN2ZmZiBpcnEgMzksNDAgb24g c2ltcGxlYnVzMQ0KZ3Bpb2J1czY6IDxHUElPIGJ1cz4gb24gZ3BpbzYNCmdwaW9jNjogPEdQSU8g Y29udHJvbGxlcj4gb24gZ3BpbzYNCmlteF93ZG9nMDogPEZyZWVzY2FsZSBpLk1YIFdhdGNoZG9n PiBtZW0gMHgyMGJjMDAwLTB4MjBiZmZmZiBpcnEgNDIgb24gc2ltcGxlYnVzMQ0KdXNicGh5MDog PEZyZWVzY2FsZSBpLk1YNiBVU0IgUEhZPiBtZW0gMHgyMGM5MDAwLTB4MjBjOWZmZiBpcnEgNTAg b24gc2ltcGxlYnVzMQ0KdXNicGh5MTogPEZyZWVzY2FsZSBpLk1YNiBVU0IgUEhZPiBtZW0gMHgy MGNhMDAwLTB4MjBjYWZmZiBpcnEgNTEgb24gc2ltcGxlYnVzMQ0Kc3JjMDogPEZyZWVzY2FsZSBp Lk1YNiBTeXN0ZW0gUmVzZXQgQ29udHJvbGxlcj4gbWVtIDB4MjBkODAwMC0weDIwZGJmZmYgaXJx IDU0LDU1IG9uIHNpbXBsZWJ1czENCmVoY2kwOiA8RnJlZXNjYWxlIGkuTVggaW50ZWdyYXRlZCBV U0IgY29udHJvbGxlcj4gbWVtIDB4MjE4NDAwMC0weDIxODQxZmYgaXJxIDczIG9uIHNpbXBsZWJ1 czMNCnVzYnVzMDogRUhDSSB2ZXJzaW9uIDEuMA0KdXNidXMwIG9uIGVoY2kwDQplaGNpMTogPEZy ZWVzY2FsZSBpLk1YIGludGVncmF0ZWQgVVNCIGNvbnRyb2xsZXI+IG1lbSAweDIxODQyMDAtMHgy MTg0M2ZmIGlycSA3NCBvbiBzaW1wbGVidXMzDQp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjANCnVz YnVzMSBvbiBlaGNpMQ0KZmZlYzA6IDxGcmVlc2NhbGUgR2lnYWJpdCBFdGhlcm5ldCBDb250cm9s bGVyPiBtZW0gMHgyMTg4MDAwLTB4MjE4YmZmZiBpcnEgNzcsNzggb24gc2ltcGxlYnVzMw0KbWlp YnVzMDogPE1JSSBidXM+IG9uIGZmZWMwDQphdHBoeTA6IDxBdGhlcm9zIEYxIDEwLzEwMC8xMDAw IFBIWT4gUEhZIDQgb24gbWlpYnVzMA0KYXRwaHkwOiAgbm9uZSwgMTBiYXNlVCwgMTBiYXNlVC1G RFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VTWC1GRFgsIDEwMDBiYXNlVC1G RFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvDQpmZmVjMDogRXRoZXJuZXQgYWRkcmVzczog ZDA6NjM6YjQ6MDA6OTk6NjkNCnNkaGNpX2lteDA6IDxGcmVlc2NhbGUgdVNESEMgY29udHJvbGxl cj4gbWVtIDB4MjE5MDAwMC0weDIxOTNmZmYgaXJxIDgyIG9uIHNpbXBsZWJ1czMNCm1tYzA6IDxN TUMvU0QgYnVzPiBvbiBzZGhjaV9pbXgwDQpzZGhjaV9pbXgxOiA8RnJlZXNjYWxlIHVTREhDIGNv bnRyb2xsZXI+IG1lbSAweDIxOTQwMDAtMHgyMTk3ZmZmIGlycSA4MyBvbiBzaW1wbGVidXMzDQpt bWMxOiA8TU1DL1NEIGJ1cz4gb24gc2RoY2lfaW14MQ0KaWljaGIwOiA8RnJlZXNjYWxlIGkuTVgg STJDPiBtZW0gMHgyMWE0MDAwLTB4MjFhN2ZmZiBpcnEgODcgb24gc2ltcGxlYnVzMw0KaWljYnVz MDogPE9GVyBJMkMgYnVzPiBvbiBpaWNoYjANCmlpYzA6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlp Y2J1czANCmlpY2hiMTogPEZyZWVzY2FsZSBpLk1YIEkyQz4gbWVtIDB4MjFhODAwMC0weDIxYWJm ZmYgaXJxIDg4IG9uIHNpbXBsZWJ1czMNCmlpY2J1czE6IDxPRlcgSTJDIGJ1cz4gb24gaWljaGIx DQppaWMxOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMxDQppaWNidXMxOiA8dW5rbm93biBj YXJkPiBhdCBhZGRyIDB4ZDANCnVhcnQxOiA8RnJlZXNjYWxlIGkuTVggVUFSVD4gbWVtIDB4MjFm MDAwMC0weDIxZjNmZmYgaXJxIDk1IG9uIHNpbXBsZWJ1czMNCmZiMDogPEZyZWVzY2FsZSBJUFU+ IG1lbSAweDI0MDAwMDAtMHgyN2ZmZmZmIGlycSAxMiwxMyBvbiBzaW1wbGVidXMwDQpjcHVsaXN0 MDogPE9wZW4gRmlybXdhcmUgQ1BVIEdyb3VwPiBvbiBvZndidXMwDQpjcHUwOiA8T3BlbiBGaXJt d2FyZSBDUFU+IG9uIGNwdWxpc3QwDQpjcHUxOiA8T3BlbiBGaXJtd2FyZSBDUFU+IG9uIGNwdWxp c3QwDQpjcHUyOiA8T3BlbiBGaXJtd2FyZSBDUFU+IG9uIGNwdWxpc3QwDQpjcHUzOiA8T3BlbiBG aXJtd2FyZSBDUFU+IG9uIGNwdWxpc3QwDQpjcnlwdG9zb2Z0MDogPHNvZnR3YXJlIGNyeXB0bz4N ClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDIuMDAwIG1zZWMNCmhkbWkwOiByZWFkaW5nIEVESUQg ZnJvbSBpaWNidXMwLCBhZGRyIDUwDQp1c2J1czA6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIu MA0KdXNidXMxOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjANCnVnZW4wLjE6IDxGcmVlc2Nh bGUgRUhDSSByb290IEhVQj4gYXQgdXNidXMwDQp1aHViMDogPEZyZWVzY2FsZSBFSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwDQp1Z2VuMS4x OiA8RnJlZXNjYWxlIEVIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMQ0KdWh1YjE6IDxGcmVlc2NhbGUg RUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz MQ0KZmJkMCBvbiBmYjANClZUOiBpbml0aWFsaXplIHdpdGggbmV3IFZUIGRyaXZlciAiZmIiLg0K bW1jMDogTm8gY29tcGF0aWJsZSBjYXJkcyBmb3VuZCBvbiBidXMNCm1tY3NkMDogNEdCIDxTREhD IFNTMDRHIDguMCBTTiA1MzJDNDhFRSBNRkcgMTIvMjAxNSBieSAzIFNEPiBhdCBtbWMxIDUwLjBN SHovNGJpdC82NTUzNS1ibG9jaw0KUmVsZWFzZSBBUHMNClRyeWluZyB0byBtb3VudCByb290IGZy b20gdWZzOi9kZXYvdWZzL3Jvb3RmcyBbcnddLi4uDQp1aHViMDogMSBwb3J0IHdpdGggMSByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjE6IDEgcG9ydCB3aXRoIDEgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQNCldBUk5JTkc6IC9yZWxlbmcvMTEtYXJtdjYtQ1VCT1gtSFVNTUlOR0JPQVJELXNu YXAvdXNyL29iai91c3Ivc3JjL3JlbGVhc2UvdWZzIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRl ZA0Kd2FybmluZzogbm8gdGltZS1vZi1kYXkgY2xvY2sgcmVnaXN0ZXJlZCwgc3lzdGVtIHRpbWUg d2lsbCBub3QgYmUgc2V0IGFjY3VyYXRlbHkNCnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuDQpm ZmVjMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04NCmZmZWMwOiBsaW5rIHN0YXRlIGNoYW5n ZWQgdG8gVVANCmZyZWVic2RAaW14Njp+ICUNCmZyZWVic2RAaW14Njp+ICUNCmZyZWVic2RAaW14 Njp+ICUgc2h1dGRvd24gLS1oZWxwDQovc2Jpbi9zaHV0ZG93bjogUGVybWlzc2lvbiBkZW5pZWQu DQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IHdsb3NoQGJzZGltcC5jb20g W21haWx0bzp3bG9zaEBic2RpbXAuY29tXSBEZSBsYSBwYXJ0IGRlIFdhcm5lciBMb3NoDQpFbnZv ecOpIDogamV1ZGkgMSBzZXB0ZW1icmUgMjAxNiAxNzoyMw0Kw4AgOiBMRSBUVVRPVVIgSmVhbg0K Q2MgOiBmcmVlYnNkLWFybUBmcmVlYnNkLm9yZw0KT2JqZXQgOiBSZTogZnJlZUJzZCBjdWJveCBJ TVg2LVEgLSBTRCBDYXJkIGltYWdlDQoNCkRvZXMgZnRwOi8vZnRwLmZyZWVic2Qub3JnL3B1Yi9G cmVlQlNEL3JlbGVhc2VzL2FybS9hcm12Ni9JU08tSU1BR0VTLzExLjAvRnJlZUJTRC0xMS4wLVJD Mi1hcm0tYXJtdjYtQ1VCT1gtSFVNTUlOR0JPQVJELmltZy54eg0Kd29yayBmb3IgeW91Pw0KDQpX YXJuZXINCg0KDQpPbiBUaHUsIFNlcCAxLCAyMDE2IGF0IDY6NDYgQU0sIExFIFRVVE9VUiBKZWFu IDxqbGV0dXRvdXJAZGVsdGFkb3JlLmNvbT4gd3JvdGU6DQo+IEhlbGxvLA0KPg0KPiBDb3VsZCBp IGhhdmUgdGhpcyA/DQo+IFRoYW5rcyBhIGxvdA0KPg0KPiBCZXN0IHJlZ2FyZHMNCj4NCj4NCj4N Cj4NCj4gSmVhbiBMRSBUVVRPVVINCj4gU2VydmljZSBSJkkNCj4gREVMVEEgRE9SRQ0KPiBMZSBW aWV1eCBDaGVuZQ0KPiAzNTI3MCBCb25uZW1haW4NCj4NCj4gKzMzNjMyMjk2OTIyDQo+ICszMzI5 OTczNDgyOA0KPg0KPiBbaHR0cDovL21haWwuZGVsdGFkb3JlLmNvbS9pbWFnZXMvbG9nb19kZWx0 YWRvcmVfY291bC5HSUZdDQo+IGh0dHA6Ly93d3cuZGVsdGFkb3JlLmZyDQo+DQo+ICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gQ2UgbWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpP2Nl cyBqb2ludGVzIHNvbnQgP3RhYmxpcyA/IGwnIGF0dGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRl c3RpbmF0YWlyZXMgZXQgc29udCBjb25maWRlbnRpZWxzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBkZSBsZSBkP3RydWlyZSBldCBkJ2VuIGF2ZXJ0aXIgaW1t P2RpYXRlbWVudCBsJ2V4cD9kaXRldXIuDQo+DQo+IFRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWVzIGFuZCBpcyBjb25m aWRlbnRpYWwuIElmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGRl bGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuDQo+ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+ IGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFybQ0K PiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1hcm0tdW5zdWJzY3Jp YmVAZnJlZWJzZC5vcmciDQpbaHR0cDovL21haWwuZGVsdGFkb3JlLmNvbS9pbWFnZXMvbG9nb19k ZWx0YWRvcmVfY291bC5HSUZdDQpodHRwOi8vd3d3LmRlbHRhZG9yZS5mcg0KDQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQpDZSBtZXNzYWdlIGV0IHRvdXRlcyBsZXMgcGnDqGNlcyBq b2ludGVzIHNvbnQgw6l0YWJsaXMgw6AgbCcgYXR0ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVz dGluYXRhaXJlcyBldCBzb250IGNvbmZpZGVudGllbHMuIFNpIHZvdXMgcmVjZXZleiBjZSBtZXNz YWdlIHBhciBlcnJldXIsIG1lcmNpIGRlIGxlIGTDqXRydWlyZSBldCBkJ2VuIGF2ZXJ0aXIgaW1t w6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1ci4NCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMgYW5kIGlzIGNvbmZp ZGVudGlhbC4gSWYgeW91IHJlY2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0IGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci4NCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCg== From owner-freebsd-arm@freebsd.org Fri Feb 10 17:34:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14047CD83B1 for ; Fri, 10 Feb 2017 17:34:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 EA72D327 for ; Fri, 10 Feb 2017 17:34:41 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 2905e3bc-efb7-11e6-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 2905e3bc-efb7-11e6-b3c2-c9f38144898e; Fri, 10 Feb 2017 17:34:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1AHYW6I017074; Fri, 10 Feb 2017 10:34:33 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1486748072.10020.253.camel@freebsd.org> Subject: Re: usb trouble cubox bsd 11 - FreeBSD 11.0-STABLE #0 r310359: Wed Dec 21 18:19:11 UTC 2016 From: Ian Lepore To: LE TUTOUR Jean , Warner Losh Cc: "freebsd-arm@freebsd.org" Date: Fri, 10 Feb 2017 10:34:32 -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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:34:42 -0000 On Fri, 2017-02-10 at 16:59 +0000, LE TUTOUR Jean wrote: > Hello, freebsd team: > > Please see listing below > I have two problems: > > > > > usb seems not work : nothing in dmesg , when I plug something in > > usb > > /sbin/shutdown: Permission denied.  :  I am  freebsd/freebsd > Don't you have any idea ? It works on linux , generally, sorry > Whith a debian  on the same plateform, no problems > > [...] For shutdown, you must be root, or a member of the group 'operator' to use the command. I don't have time right now to dig into this too deeply, but I can add a few comments about usb on imx6 systems... Usb is known to work on cubox (we use the same uSOM module in products at $work). The usb root ports on imx6 do not recognize device-removed events for some reason.  You can plug any device into the host port and it should be recognized, but when you remove it the system doesn't notice.  That means if you plug something else in, that also doesn't get noticed, and it's stuck that way until the next reboot.  You can work around that by plugging in a hub -- it does notice when you remove devices from hub ports. On the stable-11 branch, the usb host port should work, but the OTG port is not properly configured as a second host port.  On a cubox that would appear as only one of the slots working (I can't remember if it's the upper or lower connector that works). I fixed the OTG-as-host in 12-current recently (r311850), but haven't MFC'd the fix to the stable-11 or 10 branches yet.  Maybe I can find time to do that this weekend. -- Ian From owner-freebsd-arm@freebsd.org Fri Feb 10 22:02:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EC43CD9506 for ; Fri, 10 Feb 2017 22:02:52 +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 mx1.freebsd.org (Postfix) with ESMTPS id 6EB0166B for ; Fri, 10 Feb 2017 22:02:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v1AM2qN6096541 for ; Fri, 10 Feb 2017 22:02:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 216981] Missing include in sys/arm64/include/atomic.h Date: Fri, 10 Feb 2017 22:02:52 +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 Many People X-Bugzilla-Who: karl@denninger.net 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:02:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216981 Bug ID: 216981 Summary: Missing include in sys/arm64/include/atomic.h Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: karl@denninger.net Created attachment 179856 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D179856&action= =3Dedit Add the missing include.... #include is missing, and thus inclusion of this header file results in compile failures due to lack of declaration of the various types specified inside. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Feb 10 22:06:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD9C9CD968F for ; Fri, 10 Feb 2017 22:06:24 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id A17BC9BD for ; Fri, 10 Feb 2017 22:06:24 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 782351ABF49 for ; Fri, 10 Feb 2017 16:06:18 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Pi3 vchiq driver? Message-ID: Date: Fri, 10 Feb 2017 16:06:12 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030402080504090705020209" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:06:24 -0000 This is a cryptographically signed message in MIME format. --------------ms030402080504090705020209 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I assume this will provide the audio service (which is currently not available) on the Pi3. Attempting to include it results in a handful of compilation errors.=20 They'd be easy to fix for the instant case but generalizing them so they ALSO compile on the Pi2 would likely be a good idea, and I'm less-certain on the "right" way to do that. The errors are generally of the form (once I fixed a missing include in atomic.h): /pics/CrossBuild-12/src/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.= c:1852: 6: error: cast to 'void *' from smaller integer type 'int' [-Werror,-Wint-to-voi d-pointer-cast] (void *)((int *)header->data)[0];= ^ --- pci_host_generic.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=3D/pics/Crochet-work/obj/arm64.aa rch64/pics/CrossBuild-12/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/pics/CrossBuild-12/src/sys -I/pics/CrossBuild-12/src/sys/co ntrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno- omit-frame-pointer -mno-omit-leaf-frame-pointer -MD=20 -MF.depend.pci_host_generic =2Eo -MTpci_host_generic.o -mgeneral-regs-only -ffixed-x18 -ffreestanding= -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-pr ototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno- pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnosti cs-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-e mpty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error- pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -Werror /pics /CrossBuild-12/src/sys/dev/pci/pci_host_generic.c --- vchiq_kmod.o --- /pics/CrossBuild-12/src/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.= c:50:10 : fatal error: 'machine/fdt.h' file not found #include ^ --- thunder_pcie_pem_fdt.o --- ctfconvert -L VERSION -g thunder_pcie_pem_fdt.o --- pci_host_generic_fdt.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=3D/pics/Crochet-work/obj/arm64.aa rch64/pics/CrossBuild-12/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/pics/CrossBuild-12/src/sys -I/pics/CrossBuild-12/src/sys/co ntrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno- omit-frame-pointer -mno-omit-leaf-frame-pointer -MD=20 -MF.depend.pci_host_generic _fdt.o -MTpci_host_generic_fdt.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Ws trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wund ef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fd iagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno -error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wn o-error-pointer-sign -Wno-error-shift-negative-value =20 -std=3Diso9899:1999 -Werro r /pics/CrossBuild-12/src/sys/dev/pci/pci_host_generic_fdt.c --- vchiq_core.o --- /pics/CrossBuild-12/src/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.= c:3823: 5: error: format specifies type 'unsigned long long' but the argument has type ' uint64_t' (aka 'unsigned long') [-Werror,-Wformat] Guidance? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030402080504090705020209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTAyMjA2MTJaME8GCSqGSIb3DQEJBDFCBEBnvuxu JT8CC3Xun8jjbvosYHK7cLSKiyfglbf8fmvndltHZJZKMqxwvDSVaZ6xsFSkvG6ijm88JDw1 gShppjbCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAmSsg5gD/nGD3 3Wf2h9bOWAh5PPkSp6cwlL9BoI3zfnMYDcO5d5q9a9QEX1AF/RLXzwgiRrAlKWYTfWm67KQ2 +MztlsBarxMfzwqLvYRSDfhhupudQr+dayOUYsQXNSdWTgxtZSO5Xw+un1ehG9rBMTonzE4z SiUHpQasWs2nH7LzaFG3mSNFPBsqrTHJR9PTIiAI8E1dlD1grtGM9GTyy4ctza0zVdarOqLy pUXvZuW5BV1uO4MkVLGNoivxVA8ZvtpgDVIuer+aiqOu0rrGeVxEByu8n+04oqbvOb1CNUec HkMp444x33mZk3RAW0hmk/ZiCwXdkLmNLwxoE4EfHoA3QuPz6MnulqMnUI84fJrKcA0Tr2n9 rxNBFH0OLJm3qkIFq1MryScgIQo72EeeHG6I7Wo3SkwlHip7f/zIKqlOTEAdkUOJA34ZS+9S W1Pcz2plZp/I5nweLEzzCnmRQTFUShlG+L4oG3ZMJAVtURfrbTtnBf58q6oSjBSOZpVY6vcS HH/X2q6UgRYdMHKiCM4ps5I/n+bp8hlsRMQo4F7qS/+p0FDCh+j4Tdu1lRPj1ksjzLlLL5zU JmlHYw1UgBAXyGB7mspJLse5VTwtJzeBQc8CW64BhjjHmzJcyrZXmBSoFMHycSs32Ws5uha/ 3UWmjbUIiGynj9IalzCY218AAAAAAAA= --------------ms030402080504090705020209-- From owner-freebsd-arm@freebsd.org Fri Feb 10 22:12:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 206C6CD98AA for ; Fri, 10 Feb 2017 22:12:45 +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 mx1.freebsd.org (Postfix) with ESMTPS id 10091CEC for ; Fri, 10 Feb 2017 22:12:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v1AMCiCc021251 for ; Fri, 10 Feb 2017 22:12:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 216981] Missing include in sys/arm64/include/atomic.h Date: Fri, 10 Feb 2017 22:12:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed 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 Many People X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution bug_status Message-ID: In-Reply-To: References: 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:12:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216981 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian@FreeBSD.org Resolution|--- |Not A Bug Status|New |Closed --- Comment #1 from Ian Lepore --- This is not a bug. Per atomic(9), users of atomic.h are required to include sys/types.h before machine/atomic.h. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Feb 10 22:20:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF77CCD9980 for ; Fri, 10 Feb 2017 22:20:01 +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 B25ECDF5 for ; Fri, 10 Feb 2017 22:20:01 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1ccJXm-000E6W-T9; Fri, 10 Feb 2017 14:19:55 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v1AMJrQY054219; Fri, 10 Feb 2017 14:19:53 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 10 Feb 2017 14:19:53 -0800 From: Oleksandr Tymoshenko To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: Pi3 vchiq driver? Message-ID: <20170210221953.GA54179@bluezbox.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) 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: Karl Denninger (karl@denninger.net) wrote: > I assume this will provide the audio service (which is currently not > available) on the Pi3. > > Attempting to include it results in a handful of compilation errors. > They'd be easy to fix for the instant case but generalizing them so they > ALSO compile on the Pi2 would likely be a good idea, and I'm > less-certain on the "right" way to do that. ... skipped ... > Guidance? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: denninger.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:20:01 -0000 Karl Denninger (karl@denninger.net) wrote: > I assume this will provide the audio service (which is currently not > available) on the Pi3. > > Attempting to include it results in a handful of compilation errors. > They'd be easy to fix for the instant case but generalizing them so they > ALSO compile on the Pi2 would likely be a good idea, and I'm > less-certain on the "right" way to do that. ... skipped ... > Guidance? VCHI driver is designed for 32-bit system. It passes pointers as opaque values to VideoCore and expectes them mirrored back and reused as pointers. This is not going to work on 64-bit system. It can be fixed but it's not a matter of adding more #ifdefs some additional logic required. There is also a matter of userland-facing API which is not relevant for audio driver but relevant for OpenGL and other parts of raspberrypi-userland port. I have some work in progress but it's far from proper state. -- gonzo From owner-freebsd-arm@freebsd.org Fri Feb 10 22:22:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB321CD9B77 for ; Fri, 10 Feb 2017 22:22:07 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 7F91EF94 for ; Fri, 10 Feb 2017 22:22:07 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 4E4691AB257; Fri, 10 Feb 2017 16:22:06 -0600 (CST) Subject: Re: Pi3 vchiq driver? To: Oleksandr Tymoshenko References: <20170210221953.GA54179@bluezbox.com> Cc: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <4ce65a43-8216-acbc-2a6c-c7da6e070727@denninger.net> Date: Fri, 10 Feb 2017 16:22:01 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170210221953.GA54179@bluezbox.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020209030703090500090104" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:22:07 -0000 This is a cryptographically signed message in MIME format. --------------ms020209030703090500090104 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/10/2017 16:19, Oleksandr Tymoshenko wrote: > Karl Denninger (karl@denninger.net) wrote: >> I assume this will provide the audio service (which is currently not >> available) on the Pi3. >> >> Attempting to include it results in a handful of compilation errors.=20 >> They'd be easy to fix for the instant case but generalizing them so th= ey >> ALSO compile on the Pi2 would likely be a good idea, and I'm >> less-certain on the "right" way to do that. > ... skipped ... >> Guidance? > VCHI driver is designed for 32-bit system. It passes pointers as opaque= > values to VideoCore and expectes them mirrored back and reused as > pointers. This is not going to work on 64-bit system. It can be fixed > but it's not a matter of adding more #ifdefs some additional logic > required. There is also a matter of userland-facing API which is not > relevant for audio driver but relevant for OpenGL and other parts of > raspberrypi-userland port. > > I have some work in progress but it's far from proper state. > Gotcha.... The i2c driver compiles on the Pi3 but I don't know if it works yet. I also have yet to check the GPIO outputs (the "led" driver does *not* work and that might portend bad things, but we'll see.) I'll get the breadboard out with one of my spare i2c modules and see if I can talk to = it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020209030703090500090104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTAyMjIyMDFaME8GCSqGSIb3DQEJBDFCBEDkdO/H NAMPG9/bADYQNaCvCVK81NAQRMiNUm+H8AMKMlVYCB6grkQj5AjqG7gbb06FVgSouvgJEzN4 +WCcmkMzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAOzHkaRcY2v/u UOPJ55SeFkOB/I5grab3DPpn74n2pK1tslkAsySbjQBWXEjAY+dQmaxrFVHQNbJppiQehrBF 9OvlAXsSZ3fFvX531tR/w45dxCBboqdvFjvGpMJCdroThkUDjwkzvGFm/qr9tPVqE13wf4Ae pQo4xAHoFb9M7A9TZmU0NjtnNp97yGYuawDStiN1oHtlA4yLlAVZ5X99KiqEF5tFF4alGSDt vpBPCpewfX8jjOmVDuvEsBD64NUlySECuXTIDCrNjiPlGonDbZdLzKWS5JqZ29Zz+Efr7DMW +El7425pZ15V1tJnaQHyGwqTTcTtxkXgGNBRlnr5/RTX1AYGFw7IGzRQxgo1jYEiv/jSRTX8 phiVJScKbINmVewBiqo5JeKJc+UpmlIrhcZUF4bkjg5jv5gZuI/GybvqLDY0bI91TOaz6sTc SzGfezxSc5n5XYYaFQirO5JpkcDsr4gfRK37lUXlCHbxHKPHe0AlZSFxHylHV0IpfFoqec+3 6IXei82twn7t8rq5vCeCrwJP7QCdderKJEEdzQArKllzay/4vz2meSi6TXpOSDi4KCVmwuaJ BZeM/di4tTBiiNwGv5Y8CdUXu19xKLEOljrwxuIgMnjJQqJS16m5y8vcf3ghxvugEFRLaO2u 7wepbcmWDYA2HqsG5ZkF/0MAAAAAAAA= --------------ms020209030703090500090104-- From owner-freebsd-arm@freebsd.org Sat Feb 11 00:58:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA01DCD831D for ; Sat, 11 Feb 2017 00:58:13 +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 71A3B236 for ; Sat, 11 Feb 2017 00:58:12 +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 v1B0e3s9095892; Fri, 10 Feb 2017 16:40:03 -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 v1B0e314095891; Fri, 10 Feb 2017 16:40:03 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201702110040.v1B0e314095891@pdx.rh.CN85.dnsmgr.net> Subject: Re: Pi3 vchiq driver? In-Reply-To: <20170210221953.GA54179@bluezbox.com> To: Oleksandr Tymoshenko Date: Fri, 10 Feb 2017 16:40:03 -0800 (PST) CC: Karl Denninger , "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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 00:58:14 -0000 Yet one more reason that we should be building a 32bit os for the RPI3 too. The board only has 1GByte of memory, so wasting 32bits for all those 64bit points.. is.. well a waste! Not only in the limited resource of memory, but cache, and memory bandwidth. I know, its neat to play with 64 bit SMP code on a tiny little board, but its wastefull! > Karl Denninger (karl@denninger.net) wrote: > > I assume this will provide the audio service (which is currently not > > available) on the Pi3. > > > > Attempting to include it results in a handful of compilation errors. > > They'd be easy to fix for the instant case but generalizing them so they > > ALSO compile on the Pi2 would likely be a good idea, and I'm > > less-certain on the "right" way to do that. > ... skipped ... > > Guidance? > > VCHI driver is designed for 32-bit system. It passes pointers as opaque > values to VideoCore and expectes them mirrored back and reused as > pointers. This is not going to work on 64-bit system. It can be fixed > but it's not a matter of adding more #ifdefs some additional logic > required. There is also a matter of userland-facing API which is not > relevant for audio driver but relevant for OpenGL and other parts of > raspberrypi-userland port. > > I have some work in progress but it's far from proper state. > > -- > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sat Feb 11 01:27:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50813CD97CC for ; Sat, 11 Feb 2017 01:27:38 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (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 2F17A17D6 for ; Sat, 11 Feb 2017 01:27:38 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:To:From; bh=UDjQCvV935igFJxslZrf43yz0sxhTrY5QG6j4dqaWPE=; b=ACBU7t6m+B3VIMjHXFFn7SPGTf9V24ThjebFfcLOnHk2ky6u6pgNZvQ6GmJgf0nH8cnKPA7GNk1PwvwI/Wb4Jq+UUVvTUaxmKjp5Cbp6YR3PeY3Az75QxZtk99VJyRRmT9K7cr1A2UlGjJHc8LukUDVIRaa7N3nu607CkZBj72821OWg; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ccMTL-000DP5-Ma for freebsd-arm@freebsd.org; Fri, 10 Feb 2017 17:27:37 -0800 From: "Tony Hain" To: Date: Fri, 10 Feb 2017 17:27:33 -0800 Message-ID: <0ee901d28406$052ed070$0f8c7150$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKEBROeHEopH8F7SN+P5DiBVRw/rw== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: Questions about BBB/BBG dtb names vs. content X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.net) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 01:27:38 -0000 When I built 12 current the other day, I found some confusing dtb file names. First there were identical files : am335x-bone.dtb beaglebone.dtb am335x-boneblack.dtb beaglebone-black.dtb But there was not a matching one for green. Is that intentional? am335x-bonegreen.dtb Then the content didn't match the names: am335x-boneblack.dtb -- compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; am335x-bonegreen.dtb -- compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; Aren't the strings in the compatible line supposed to match the file names? Is there a reason there are identical files in the dtb path rather than a link? Is the fdt_file="" line required in loader.conf if the am335x file name exists? I have the BBB running with fdt_file="beaglebone-black.dtb", and the changes to it for turning on uart1. Should I have made the changes to the am335x file instead, or should I create the beaglebone-green.dtb file for the BBG? Tony From owner-freebsd-arm@freebsd.org Sat Feb 11 01:52:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4FC5CD9A05 for ; Sat, 11 Feb 2017 01:52:34 +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 91900A66 for ; Sat, 11 Feb 2017 01:52:34 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1ccMrY-000EcM-Op; Fri, 10 Feb 2017 17:52:33 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v1B1qW4l056193; Fri, 10 Feb 2017 17:52:32 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 10 Feb 2017 17:52:31 -0800 From: Oleksandr Tymoshenko To: Tony Hain Cc: freebsd-arm@freebsd.org Subject: Re: Questions about BBB/BBG dtb names vs. content Message-ID: <20170211015231.GA56071@bluezbox.com> References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ee901d28406$052ed070$0f8c7150$@tndh.net> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) 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: Tony Hain (tony@tndh.net) wrote: > When I built 12 current the other day, I found some confusing dtb file > names. > First there were identical files : > am335x-bone.dtb beaglebone.dtb > am335x-boneblack.dtb beaglebone-black.dtb > > But there was not a matching one for green. Is that intentional? > am335x-bonegreen.dtb > > Then the content didn't match the names: > am335x-boneblack.dtb -- > compatible = "ti, am335x-bone-black", "ti, am335x-bone", "ti,am33xx"; > > am335x-bonegreen.dtb -- > compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", > "ti,am335x-bone", "ti,am33xx"; > > Aren't the strings in the compatible line supposed to match the file names? > Is there a reason there are identical files in the dtb path rather than a > link? > Is the fdt_file="" line required in loader.conf if the am335x file name > exists? > > I have the BBB running with fdt_file="beaglebone-black.dtb", and the changes > to it for turning on uart1. Should I have made the changes to the am335x > file instead, or should I create the beaglebone-green.dtb file for the BBG? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: tndh.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 01:52:34 -0000 Tony Hain (tony@tndh.net) wrote: > When I built 12 current the other day, I found some confusing dtb file > names. > First there were identical files : > am335x-bone.dtb beaglebone.dtb > am335x-boneblack.dtb beaglebone-black.dtb > > But there was not a matching one for green. Is that intentional? > am335x-bonegreen.dtb > > Then the content didn't match the names: > am335x-boneblack.dtb -- > compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; > > am335x-bonegreen.dtb -- > compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", > "ti,am335x-bone", "ti,am33xx"; > > Aren't the strings in the compatible line supposed to match the file names? > Is there a reason there are identical files in the dtb path rather than a > link? > Is the fdt_file="" line required in loader.conf if the am335x file name > exists? > > I have the BBB running with fdt_file="beaglebone-black.dtb", and the changes > to it for turning on uart1. Should I have made the changes to the am335x > file instead, or should I create the beaglebone-green.dtb file for the BBG? beaglebone*dtb is FreeBSD-specific DTB names, dts files for them were created in early days of FDT support. am335x-*dtb are upstream names, Linux and U-Boot use them as standard names. U-Boot can detect type of board in run-time and set fdt_file env variable based on that type. Until recently we had sysutils/u-boot-beaglebone port with custom FreeBSD-specific patch where this autodetect logic used beaglebone*dtb names. Recently it was converted to being slave port to sysutils/u-boot-master as a part of U-Boot ports unification effort. During this conversion aforementioned patch was deleted so now u-boot operates with am335x-*.dtb names. To be backward-compatible with previously built systems, that still refer to old-style names, we now create links, beaglebone.dtb is a link to am335x-bone.dtb and beaglebone-black.dtb is a link to am335x-boneblack.dtb. There was no FreeBSD-specific DTS for beaglebone green previously, so am335x-bonegreen.dtb does not have beaglebone* counterpart. At the moment any changes toboot/fdt/dts/arm/beagebone-*.dts are not going affect beagebone-*.dtb because these dtbs created as links, not generated. I have patch in review that fixes it and brings back old-style DTBs along with some fixes that are in upstream but haven't been merged to FreeBSD tree yet: https://reviews.freebsd.org/D9432 With current tree you need to move your uart1-related change to sys/gnu/dts/arm/am335x-boneblack.dts, regenerate dtbs and that should do the trick. -- gonzo From owner-freebsd-arm@freebsd.org Sat Feb 11 02:11:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B31CCDA4AC for ; Sat, 11 Feb 2017 02:11:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-76.reflexion.net [208.70.210.76]) (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 C087D163D for ; Sat, 11 Feb 2017 02:11:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20037 invoked from network); 11 Feb 2017 02:11:24 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Feb 2017 02:11:24 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Fri, 10 Feb 2017 21:11:24 -0500 (EST) Received: (qmail 13294 invoked from network); 11 Feb 2017 02:11:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Feb 2017 02:11:24 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 09FC5EC7AC6; Fri, 10 Feb 2017 18:11:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: bcopy/memmove optimization broken ? [looks like you are correct to me, I give supporting detail] From: Mark Millard In-Reply-To: <5335118.oK1KXXDaG5@pc-alex> Date: Fri, 10 Feb 2017 18:11:23 -0800 Cc: freebsd-arm , Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> References: <5335118.oK1KXXDaG5@pc-alex> To: Alexandre Martins X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 02:11:33 -0000 On 2017-Feb-10, at 7:51 AM, Alexandre Martins wrote: > Hi all >=20 > I see in the kernel code of bcopy/memmove an optimization if the = copied region=20 > don't overlap: >=20 > = https://svnweb.freebsd.org/base/head/sys/arm/arm/support.S?view=3Dannotate= #l403 >=20 > I'm a newbie in ARM assembly, so, sorry if i'm wrong, but > - R0 is the dst (1st parameter) > - R1 is the src (2nd parameter) >=20 > So : > subcc r3, r0, r1 /* if (dst > src) r3 =3D dst - src */ > subcs r3, r1, r0 /* if (src > dsr) r3 =3D src - dst */ > cmp r3, r2 /* if (r3 < len) we have an overlap */ > bcc PIC_SYM(_C_LABEL(memcpy), PLT) >=20 > Seems to be inverted. Should it be that ? : > subcs r3, r0, r1 /* if (dst > src) r3 =3D dst - src */ > subcc r3, r1, r0 /* if (src > dsr) r3 =3D src - dst */ > cmp r3, r2 /* if (r3 < len) we have an overlap */ > bcs PIC_SYM(_C_LABEL(memcpy), PLT) >=20 >=20 > Best regards >=20 > --=20 > Alexandre Martins > STORMSHIELD I did not expect something so central that has been around so long to look wrong but. . . Going through the supporting details of the original code based on my looking around here is what I found: #include void *memmove(void *dest, const void *src, size_t n); So I'd expect (c'ish notation): r0=3D=3Ddest r1=3D=3Dsrc r2=3D=3Dn Then for (the comments vs. code is being challenged): (The comments do seem to give the intent correctly.) cmp r0, r1 RETeq /* Bail now if src/dst are the same */ subcc r3, r0, r1 /* if (dst > src) r3 =3D dst - src */ subcs r3, r1, r0 /* if (src > dsr) r3 =3D src - dst */ cmp r3, r2 /* if (r3 < len) we have an overlap */ bcc PIC_SYM(_C_LABEL(memcpy), PLT) . . . cmp r0,r1 should result in condition code (c'ish notation): eq=3D(r0=3D=3Dr1) cc=3D(r0=3Dr1) (Only the r0 position has no immediate-value alternative.) subcc r3,r0,r1 is: if (cc) r3=3Dr0-r1 // no condition code change In other words: if (dst=3Dsrc) r3=3Dsrc-dst So it does not match the test listed in the comment as far as I can see. And in (mathematical) integer arithmetic the r3 result would be nonpositive for src-dst. But the earlier RETeq prevents the zero case, so: negative. For non-negative arithmetic (natural or whole): undefined. If it was only a normal mathemetical context r3=3D-abs(dst-src) would be a summary of the two sub instruction sequence as it is from what I can tell. For the purpose the summary should be: r3=3Dabs(dst-src), given dst!=3Dsrc . There is no need to wonder outside normal mathematical non-negative arithmetic in the process either. Your code change would have the right summary and use only normal mathematical rules from what I can tell: cmp r0, r1 RETeq /* Bail now if src/dst are the same */ subcs r3, r0, r1 /* if (dst > src) r3 =3D dst - src */ subcc r3, r1, r0 /* if (src > dsr) r3 =3D src - dst */ cmp r3, r2 /* if (r3 < len) we have an overlap */ bcs PIC_SYM(_C_LABEL(memcpy), PLT) . . . subcs r3,r0,r1 is: if (cs) r3=3Dr0-r1 // no condition code change In other words: if (dst>=3Dsrc) r3=3Ddst-src. Given the prior RETeq, that is effectively: if (dst>src) r3=3Ddst-src. And that matches the comments and would produce a positive result for r3, matching the normal mathematical result. subcc r3,r1,r0 is: if (cc) r3=3Dr1-r0 // no condition code change In other words: if (dst Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEA12CDA455 for ; Sat, 11 Feb 2017 05:59:58 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C0449EB for ; Sat, 11 Feb 2017 05:59:58 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: by mail-pf0-x22e.google.com with SMTP id 202so11428276pfx.2 for ; Fri, 10 Feb 2017 21:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=/foZaCnt1BBHgkd4Xi0j7SyimhSyLpPvkf4ylJ7qnNc=; b=g1uiGlC3jfmmh0kXpsUzlAmHX4aHucU+IJ0IMMn8j4z0w9/coxuE3z+KvduEN6qMxo H12kwkPSqd63PCam9pdONiLCxdQK7fVL8F+RCsM3Hyyt3AxR46aNglz9l7d4T2YXsBSz dY6k4psEsRyRzXHst/ADjASXuUymz/gCGwmTXhd51cdaQB3FVTnSdD1RCcZPuNwyCFoG lsj9566JuzfIQR5amRa9xhqhQKE82XKpZNfkSy72KlOffoX0B9JbmsgPsxoYE52rJdHz mJ8alnEJGq2+O8OP1K2se01IFbSGiFtEFRnWWITZt76APnjKA56LMEBwnupC8kAkvk7F SCEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=/foZaCnt1BBHgkd4Xi0j7SyimhSyLpPvkf4ylJ7qnNc=; b=rCdpOFHqEUiazrxLC8EEyAE/JJnhkDeMTDb9ZjYEjztZA5kfYGf0yvwPwlGdf4zzgG U+WcK8zAqYw3y8HPF5+pneXIE8fVBMp8wVl000d3Xb4T3lruGPYjflIMHdZzK4nAxty/ 4WzaELBcfCGJhuGlrtkjyrhag4eAnMwBAhsH/NCDsCYYo3JEQVzXvfq/dBHwXgRMOkvq sfDm/BFHtTtAi1nHBlh1cr0+5PnBjDY/lnyg/1qAs3ZgLF0cTYDHOX8/MaM0IOAZg1a6 m2AsTGpW5ZTM7sM52fskIF0LTcW8Uv8+yYge/8Zy/RdSOgY92M9Wa8DXHTc+G59F1f0o EZ1g== X-Gm-Message-State: AMke39nC1Yw+uX5ObaB8KAsUNluvXQH8+sI9ae6HNL1W1bXjKG2sC2gXGxvnKzTYXJGoJw== X-Received: by 10.98.81.6 with SMTP id f6mr14547917pfb.180.1486792797335; Fri, 10 Feb 2017 21:59:57 -0800 (PST) Received: from ?IPv6:2601:1c0:ce01:a5b7:d8d:f09f:c17f:5ba1? ([2601:1c0:ce01:a5b7:d8d:f09f:c17f:5ba1]) by smtp.gmail.com with ESMTPSA id u75sm8742560pgc.31.2017.02.10.21.59.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 21:59:56 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Fri, 10 Feb 2017 21:59:55 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> <7B5DF446-6740-43DE-823D-B6ECBECF0C32@dsl-only.net> <1B1EEC5E-9875-417F-9901-A66CB5885634@dsl-only.net> <25B9EBC8-147F-47C2-BC40-C449EF3AC3FE@gmail.com> <71B83856-654D-4F38-894F-1DF41681F0FC@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: <71B83856-654D-4F38-894F-1DF41681F0FC@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 05:59:58 -0000 The stack pointer is messed up when fork returns, at least when it happens to be too large to be in the stack region. So I conclude that fork sometimes returns a corrupted state in the child-process, at least for the stack pointer. Supporting details: I've added stack checks for the stack pointer being in too large for the proper stack region after the fork in the child-process path ( /usr/src/bin/sh/jobs.c modification): extern void stack_check(void); pid_t forkshell(struct job *jp, union node *n, int mode) { pid_t pid; pid_t pgrp; =20 TRACE(("forkshell(%%%td, %p, %d) called\n", jp - jobtab, (void = *)n, mode)); INTOFF; if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) checkzombies(); flushall(); pid =3D fork(); if (pid =3D=3D -1) { TRACE(("Fork failed, errno=3D%d\n", errno)); INTON; error("Cannot fork: %s", strerror(errno)); } if (pid =3D=3D 0) { struct job *p; int wasroot; int i; =20 TRACE(("Child shell %d\n", (int)getpid())); wasroot =3D rootshell; rootshell =3D 0; handler =3D &main_handler; stack_check(); <<<<<<<=3D=3D=3D=3D=3D=3D this = one catches the "too large" case closescript(); stack_check(); INTON; stack_check(); forcelocal =3D 0; clear_traps(); stack_check(); . . . (Note: TRACE is disabled.) In a separate .c file: void stack_check(void) { volatile uintptr_t test =3D 0; extern struct jmploc main_handler; if (*(uintptr_t*)&main_handler.loc[0]._jb[6] < = (uintptr_t)(void*)&test) abort(); } (I happened to use /usr/src/bin/sh/miscbltin.c with a couple of includes added.) Sometimes the bad sp value is not too large for the stack region so this does not catch all the failures. (lldb) bt * thread #1: tid =3D 100144, 0x0000000040554e54 libc.so.7`_thr_kill + 8, = name =3D 'sh', stop reason =3D signal SIGABRT * frame #0: 0x0000000040554e54 libc.so.7`_thr_kill + 8 frame #1: 0x0000000040554e18 libc.so.7`__raise(s=3D6) + 64 at = raise.c:52 frame #2: 0x0000000040554d8c libc.so.7`abort + 84 at abort.c:65 frame #3: 0x0000000000411984 sh`stack_check + 88 at miscbltin.c:73 frame #4: 0x000000000040f33c sh`forkshell(jp=3D, = n=3D, mode=3D) + 520 at jobs.c:865 frame #5: 0x0000000000405954 sh`evaltree [inlined] evalpipe + 164 at = eval.c:596 frame #6: 0x00000000004058b0 sh`evaltree(n=3D, = flags=3D) + 1044 at eval.c:286 frame #7: 0x0000000000406e28 sh`evalbackcmd(n=3D0x0000000040a50af8, = result=3D0x0000ffffffffd2f0) + 340 at eval.c:702 frame #8: 0x0000000000409324 sh`argstr [inlined] = expbackq(cmd=3D0x0000000040a50af8, flag=3D, = dst=3D) + 40 at expand.c:461 frame #9: 0x00000000004092fc sh`argstr(p=3D"", flag=3D, = dst=3D) + 392 at expand.c:315 frame #10: 0x0000000000408fa8 sh`expandarg(arg=3D, = arglist=3D0x0000ffffffffd688, flag=3D) + 112 at = expand.c:234 frame #11: 0x0000000000405f48 sh`evalcommand(cmd=3D, = flags=3D, backcmd=3D) + 224 at eval.c:863 frame #12: 0x0000000000405570 sh`evaltree(n=3D0x0000000040a50bd0, = flags=3D) + 212 at eval.c:290 frame #13: 0x0000000000405550 sh`evaltree(n=3D0x0000000040a50ee0, = flags=3D) + 180 at eval.c:213 frame #14: 0x0000000000411050 sh`cmdloop(top=3D) + 252 = at main.c:231 frame #15: 0x0000000000410ec4 sh`main(argc=3D, = argv=3D) + 660 at main.c:178 frame #16: 0x0000000000402f30 sh`__start + 360 frame #17: 0x0000000040434658 ld-elf.so.1`.rtld_start + 24 at = rtld_start.S:41 (lldb) register read General Purpose Registers: x0 =3D 0x0000000000000000 x1 =3D 0x0000000000000000 x2 =3D 0x0000000000000000 x3 =3D 0x0000000040573638 libc.so.7`_sigprocmask x4 =3D 0x0000000040a50b2c x5 =3D 0x0000000040a4f4f9 x6 =3D 0x0000000000646573 x7 =3D 0x0000000000646573 x8 =3D 0x00000000000001b1 x9 =3D 0x0000000000000000 x10 =3D 0x0000000000000000 x11 =3D 0x0000000000000018 x12 =3D 0x0000000000000004 x13 =3D 0x0000000000000427 x14 =3D 0x0000000000000001 x15 =3D 0x0000000000000000 x16 =3D 0x0000000040554e4c libc.so.7`_thr_kill x17 =3D 0x0000ffffffffe8e0 x18 =3D 0x0000000000000000 x19 =3D 0x0000000000000006 x20 =3D 0x0000000040a36180 x21 =3D 0x0000000000000000 x22 =3D 0x0000000000000000 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x0000000040a36180 x26 =3D 0x0000000000000003 x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a50b18 fp =3D 0x0000ffffffffe910 lr =3D 0x0000000040554e18 libc.so.7`__raise + 64 at raise.c:52 sp =3D 0x0000ffffffffe8f0 pc =3D 0x0000000040554e54 libc.so.7`_thr_kill + 8 cpsr =3D 0x80000000 On 2017-Feb-8, at 8:53 PM, Mark Millard wrote: > Another sh core, this one with non-zero "junk" around > the sp at the core-dump gives new information. The "junk" > is because the SP actually ends up in higher addressed > memory than the base frame (when .rtld_start does > "bl _rtld"). [Some sh core dumps have different sp > relationships than this but this can and does > happen.] >=20 > With the below additional evidence I conclude that > either the stack pointer was messed up when fork > returned for the child path or shortly there after > (while sh's forkshell routine was still active). >=20 >=20 >=20 >=20 >=20 > Supporting details: >=20 > General Purpose Registers: > . . . > sp =3D 0x0000ffffffffe600 >=20 > The sp =3D 0x0000ffffffffe600 is rather high in memory, > in fact outside the stack for what ld-elf.so.1`.rtld_start > calls. . . >=20 > 0xffffffffd5b0: 0x0000ffffffffd5f0 0x0000000000402f30 > 0xffffffffd5c0: 0x0000000000000000 0x0000000000000000 > 0xffffffffd5d0: 0x0000000000000000 0x0000000000000000 > 0xffffffffd5e0: 0x0000ffffffffd600 0x0000ffffffffd600 > 0xffffffffd5f0: 0x0000000000000000 0x0000000040434658 >=20 > (Note: 0x0000ffffffffe600-0x1000=3D=3D0xffffffffd5f0+0x10 > but other core files have widely varying distances.) >=20 > For that last line: >=20 > 0xffffffffd5f0: 0x0000000000000000 0x0000000040434658 > (lldb) dis -s -4*4+0x0000000040434658 > ld-elf.so.1`.rtld_start: > 0x40434648 <+8>: sub sp, sp, #0x10 ; =3D0x10=20 > 0x4043464c <+12>: mov x1, sp > 0x40434650 <+16>: add x2, x1, #0x8 ; =3D0x8=20 > 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 > 0x40434658 <+24>: mov x8, x0 >=20 > (0x2e4c is not in the core file.) >=20 > and for the other frame-pointer/lr-value pair: >=20 > 0xffffffffd5b0: 0x0000ffffffffd5f0 0x0000000000402f30 > (lldb) dis -s -4*4+0x0000000000402f30 > sh`__start: > 0x402f20 <+344>: mov w0, w21 > 0x402f24 <+348>: mov x1, x20 > 0x402f28 <+352>: mov x2, x19 > 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 > 0x402f30 <+360>: bl 0x402ae0 ; symbol stub = for: exit >=20 > Note: Anything higher addressed in memory than that=20 > 0xffffffffd5ff I'll say is "higher than the stack > region" or some such phrase. >=20 > Yet despite being higher than the stack region > there are some stack frames also near by (also > higher than the stack region). . . >=20 > An area around the sp =3D 0x0000ffffffffe600 that lldb > reported for this core (with some notes used later): >=20 > . . . > 0xffffffffe400: 0x6572662d6e776f6e 0x302e323164736265 > 0xffffffffe410: 0x56454c454b414d00 0x42494c00323d4c45 > 0xffffffffe420: 0x403d434e49464c45 0x6e69666c6562696c > 0xffffffffe430: 0x4f465f444c004063 0x5445475241545f52 > 0xffffffffe440: 0x6f6c2f7273752f3d 0x637261612f6c6163 > 0xffffffffe450: 0x656e6f6e2d343668 0x6e69622f666c652d > 0xffffffffe460: 0x3d62647000646c2f 0x2f62642f7261762f > 0xffffffffe470: 0x74726f7000676b70 0x2f3d72696462645f > 0xffffffffe480: 0x702f62642f726176 0x5f4d50007374726f > 0xffffffffe490: 0x505f544e45524150 0x657665643d54524f > 0xffffffffe4a0: 0x3668637261612f6c 0x652d656e6f6e2d34 > 0xffffffffe4b0: 0x43006363672d666c 0x5243530063633d43 > 0xffffffffe4c0: 0x6f6f722f3d545049 0x5f7374726f702f74 > 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) > 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 (beginning of = what looks like stack frames) > 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 > 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 > 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 > 0xffffffffe520: 0x0000000000000000 0x0000000000000000 > 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 > 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 > 0xffffffffe550: 0x0000000000434000 0x000000000000000f > 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 > 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e > 0xffffffffe580: 0x0000000000000001 0x0000000000000005 > 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) > 0xffffffffe5b0: 0x54494445003d4854 0x41500069763d524f x26, x25 values = (see below) > 0xffffffffe5c0: 0x2f3d534547414b43 0x74726f702f727375 x24, x23 values = (see below) > 0xffffffffe5d0: 0x67616b6361702f73 0x414c46444c007365 x22, x21 values = (see below) > 0xffffffffe5e0: 0x58584300203d5347 0x662d3d5347414c46 x20, x19 values = (see below) > 0xffffffffe5f0: 0x2d74656b63617262 0x31353d6874706564 fp, lr values = (see below); pc=3D=3Dlr eventually. > 0xffffffffe600: 0x346d673d344d0032 0x73752f3d564e4500 > 0xffffffffe610: 0x6d2f656d6f682f72 0x732e2f696d6b7261 > 0xffffffffe620: 0x2f3d647000637268 0x74726f702f727375 > 0xffffffffe630: 0x4441524750550073 0x703d4c4f4f545f45 > 0xffffffffe640: 0x657473616d74726f 0x5254524f46470072 > 0xffffffffe650: 0x4552534f003d4e41 0x4f00302e32313d4c > 0xffffffffe660: 0x752f3d445750444c 0x702f6a626f2f7273 > . . . >=20 > So at this point we have that the stack pointer was > messed up somewhat prior to the core-dump. >=20 > x19-x26 in the below are from the locations indicated > to the side above: >=20 > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x0000000000000000 > x2 =3D 0x0000000000000000 > x3 =3D 0x00000000405735c8 libc.so.7`__sys_sigaction > x4 =3D 0x0000000000000090 > x5 =3D 0x2080002000200000 > x6 =3D 0x0000000000434c28 sh..bss + 9448 > x7 =3D 0x00000000000c590d > x8 =3D 0x0000000000000000 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000434000 sh..bss + 6336 > x11 =3D 0x0000000000000000 > x12 =3D 0x0000000000434c38 sh..bss + 9464 > x13 =3D 0x0000000000000001 > x14 =3D 0x0000000000000063 > x15 =3D 0x0000000000000010 > x16 =3D 0x0000000000432280 =20 > x17 =3D 0x0000000040573554 libc.so.7`sigaction at = sigaction.c:49 > x18 =3D 0x0000000000000000 > x19 =3D 0x662d3d5347414c46 > x20 =3D 0x58584300203d5347 > x21 =3D 0x414c46444c007365 > x22 =3D 0x67616b6361702f73 > x23 =3D 0x74726f702f727375 > x24 =3D 0x2f3d534547414b43 > x25 =3D 0x41500069763d524f > x26 =3D 0x54494445003d4854 > x27 =3D 0x0000ffffffffc658 > x28 =3D 0x0000000000000000 > fp =3D 0x2d74656b63617262 > lr =3D 0x31353d6874706564 > sp =3D 0x0000ffffffffe600 > pc =3D 0x31353d6874706564 > cpsr =3D 0x20000000 >=20 > Note the: >=20 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >=20 > is somewhat before 0x0000ffffffffe600. It looks to be > a frame-pointer/lr-value pair. (And the 0x0000ffffffffc5c0 > does point to a frame-pointer/lr-value pair that is > part of a coherent chain of them inside the stack region.) >=20 > It seems likely that despite the long distance > framepointer reference in the fp/lr value pair: >=20 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >=20 > that sp =3D 0x0000ffffffffe600 was the result of an > increment by a small fixed amount from an sp near > 0xffffffffe5a0, such as by code like the following > when forkshell tries to return: >=20 > sh`forkshell: > 0x40f520 <+1004>: ldp x29, x30, [sp, #0x40] > 0x40f524 <+1008>: ldp x20, x19, [sp, #0x30] > 0x40f528 <+1012>: ldp x22, x21, [sp, #0x20] > 0x40f52c <+1016>: ldp x24, x23, [sp, #0x10] > 0x40f530 <+1020>: ldp x26, x25, [sp], #0x50 > 0x40f534 <+1024>: ret =20 >=20 > So the prior is sp=3D0xffffffffe5b0 for the above code. > Also note that for SP=3D0xffffffffe5b0 initially that > code would fill in x19-x26 as they were actually > filled in: solid evidence of the sp that exit code > started with. >=20 > Note that forkshell had started with: >=20 > sh`forkshell: > 0x40f134 <+0>: stp x26, x25, [sp, #-0x50]! > 0x40f138 <+4>: stp x24, x23, [sp, #0x10] > 0x40f13c <+8>: stp x22, x21, [sp, #0x20] > 0x40f140 <+12>: stp x20, x19, [sp, #0x30] > 0x40f144 <+16>: stp x29, x30, [sp, #0x40] > 0x40f148 <+20>: add x29, sp, #0x40 ; =3D0x40=20 >=20 > And that indicates that sp had a big change after: >=20 > 0x40f148 <+20>: add x29, sp, #0x40 ; =3D0x40=20 >=20 > in order for x29=3D0x0000ffffffffc5c0 to have later > been written out as it was at 0xffffffffe5a0. >=20 > But by the freejob call (that is in forkshell's child > process path) that is indicated by the below the > sp had changed to be higher than the stack region: >=20 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 > (lldb) dis -s -4*4+0x000000000040f490 > sh`forkshell: > 0x40f480 <+844>: ldrb w8, [x20, #0x21] > 0x40f484 <+848>: cbz w8, 0x40f490 ; <+860> at = jobs.c:907 > 0x40f488 <+852>: mov x0, x20 > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 > . . . >=20 > where freejob started with: >=20 > (lldb) dis -s freejob > sh`freejob: > 0x40e65c <+0>: str x23, [sp, #-0x40]! > 0x40e660 <+4>: stp x22, x21, [sp, #0x10] > 0x40e664 <+8>: stp x20, x19, [sp, #0x20] > 0x40e668 <+12>: stp x29, x30, [sp, #0x30] > 0x40e66c <+16>: add x29, sp, #0x30 ; =3D0x30=20 > . . . >=20 > and the contained: >=20 > 0x40e668 <+12>: stp x29, x30, [sp, #0x30] >=20 > wrote the frame-pointer/lr-value pair: >=20 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >=20 > after freejob was called. freejob returns with: >=20 > (lldb) dis -s freejob -c 128 > sh`freejob: > . . . > 0x40e748 <+236>: ldp x29, x30, [sp, #0x30] > 0x40e74c <+240>: ldp x20, x19, [sp, #0x20] > 0x40e750 <+244>: ldp x22, x21, [sp, #0x10] > 0x40e754 <+248>: ldr x23, [sp], #0x40 > 0x40e758 <+252>: ret =20 > . . . >=20 > The lr-value from: >=20 > 0xffffffffc5c0: 0x0000ffffffffc8f0 0x0000000000406648 >=20 > refers to: >=20 > sh`evalcommand: > 0x406644 <+2012>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x406648 <+2016>: cbz w0, 0x40666c ; <+2052> at = eval.c:1175 >=20 > as expected. This is in the stack region. >=20 > There is evidence of the following frame-pointer/lr-value > pair still in the stack-region from just before the fork but > while forkshell was active and before the big change in > sp value: >=20 > 0xffffffffc570: 0x0000ffffffffc5c0 0x000000000040f1c8 > sh`forkshell: > 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 > 0x40f1c8 <+148>: bl 0x402920 ; symbol stub = for: fork >=20 > The parent process did not crash and so there is no evdence > that its sp value was ever wrong. So going into fork > things seem to have been okay. >=20 > So far it does not appear to me that there is information > left for inside or after the fork but before the freejob call > on the child process path. So the fork itself might have > returned with the wrong sp value or the problem might have > occurred a little later. >=20 > As far as the bad sp values in this example core file. . . >=20 > The content of what I've historically called "junk" > areas that are actually outside the stack region are > interesting: >=20 > . . . > 0xffffffffe400: 0x6572662d6e776f6e 0x302e323164736265 > 0xffffffffe410: 0x56454c454b414d00 0x42494c00323d4c45 > 0xffffffffe420: 0x403d434e49464c45 0x6e69666c6562696c > 0xffffffffe430: 0x4f465f444c004063 0x5445475241545f52 > 0xffffffffe440: 0x6f6c2f7273752f3d 0x637261612f6c6163 > 0xffffffffe450: 0x656e6f6e2d343668 0x6e69622f666c652d > 0xffffffffe460: 0x3d62647000646c2f 0x2f62642f7261762f > 0xffffffffe470: 0x74726f7000676b70 0x2f3d72696462645f > 0xffffffffe480: 0x702f62642f726176 0x5f4d50007374726f > 0xffffffffe490: 0x505f544e45524150 0x657665643d54524f > 0xffffffffe4a0: 0x3668637261612f6c 0x652d656e6f6e2d34 > 0xffffffffe4b0: 0x43006363672d666c 0x5243530063633d43 > 0xffffffffe4c0: 0x6f6f722f3d545049 0x5f7374726f702f74 > 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) >=20 > In other words ('\0' terminated strings): >=20 > . . . > (lldb) print (char*)0xffffffffe400 > (char *) $67 =3D 0x0000ffffffffe400 "nown-freebsd12.0" > (lldb) print (char*)0xffffffffe411 > (char *) $66 =3D 0x0000ffffffffe411 "MAKELEVEL=3D2" > (lldb) print (char*)0xffffffffe433 > (char *) $68 =3D 0x0000ffffffffe433 = "LD_FOR_TARGET=3D/usr/local/aarch64-none-elf/bin/ld" > (lldb) print (char*)0xffffffffe464 > (char *) $69 =3D 0x0000ffffffffe464 "pdb=3D/var/db/pkg" > (lldb) print (char*)0xffffffffe474 > (char *) $71 =3D 0x0000ffffffffe474 "port_dbdir=3D/var/db/ports" > (lldb) print (char*)0xffffffffe48d > (char *) $60 =3D 0x0000ffffffffe48d = "PM_PARENT_PORT=3Ddevel/aarch64-none-elf-gcc" > (lldb) print (char*)0xffffffffe4b7 > (char *) $29 =3D 0x0000ffffffffe4b7 "CC=3Dcc" > (lldb) print (char*)0xffffffffe4bd > (char *) $30 =3D 0x0000ffffffffe4bd "SCRIPT=3D/root/ports_x" >=20 > As for: >=20 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) > 0xffffffffe5b0: 0x54494445003d4854 0x41500069763d524f x26, x25 values = (see below) > 0xffffffffe5c0: 0x2f3d534547414b43 0x74726f702f727375 x24, x23 values = (see below) > 0xffffffffe5d0: 0x67616b6361702f73 0x414c46444c007365 x22, x21 values = (see below) > 0xffffffffe5e0: 0x58584300203d5347 0x662d3d5347414c46 x20, x19 values = (see below) > 0xffffffffe5f0: 0x2d74656b63617262 0x31353d6874706564 fp, lr values = (see below); pc=3D=3Dlr as well. > 0xffffffffe600: 0x346d673d344d0032 0x73752f3d564e4500 > 0xffffffffe610: 0x6d2f656d6f682f72 0x732e2f696d6b7261 > 0xffffffffe620: 0x2f3d647000637268 0x74726f702f727375 > 0xffffffffe630: 0x4441524750550073 0x703d4c4f4f545f45 > 0xffffffffe640: 0x657473616d74726f 0x5254524f46470072 > 0xffffffffe650: 0x4552534f003d4e41 0x4f00302e32313d4c > 0xffffffffe660: 0x752f3d445750444c 0x702f6a626f2f7273 > . . . >=20 > In other words: >=20 > (lldb) print (char*)0xffffffffe5b0 > (char *) $72 =3D 0x0000ffffffffe5b0 "TH=3D" > (The above is likely missing its beginning, having been replaced > by the frame-popinter/lr-value pair.) > (lldb) print (char*)0xffffffffe5be > (char *) $73 =3D 0x0000ffffffffe5be "PACKAGES=3D/usr/ports/packages" > (lldb) print (char*)0xffffffffe5db > (char *) $74 =3D 0x0000ffffffffe5db "LDFLAGS=3D " > (lldb) print (char*)0xffffffffe5e5 > (char *) $75 =3D 0x0000ffffffffe5e5 "CXXFLAGS=3D-fbracket-depth=3D512" > (lldb) print (char*)0xffffffffe602 > (char *) $76 =3D 0x0000ffffffffe602 "M4=3Dgm4" > (lldb) print (char*)0xffffffffe624 > (char *) $77 =3D 0x0000ffffffffe624 "pd=3D/usr/ports" > (lldb) print (char*)0xffffffffe632 > (char *) $79 =3D 0x0000ffffffffe632 "UPGRADE_TOOL=3Dportmaster" > (lldb) print (char*)0xffffffffe64a > (char *) $81 =3D 0x0000ffffffffe64a "GFORTRAN=3D" > (lldb) print (char*)0xffffffffe654 > (char *) $82 =3D 0x0000ffffffffe654 "OSREL=3D12.0" > (lldb) print (char*)0xffffffffe65f > (char *) $83 =3D 0x0000ffffffffe65f = "OLDPWD=3D/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/.bu= ild" > . . . >=20 > So the middle range with the stack frames: >=20 > 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) > 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 > 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 > 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 > 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 > 0xffffffffe520: 0x0000000000000000 0x0000000000000000 > 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 > 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 > 0xffffffffe550: 0x0000000000434000 0x000000000000000f > 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 > 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e > 0xffffffffe580: 0x0000000000000001 0x0000000000000005 > 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 > 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) >=20 > has stomped on strings that are outside the stack > region. (The stack frames are the actual junk.) >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net On 2017-Feb-7, at 2:44 AM, Mark Millard wrote: > Another core. The register read reported: >=20 > fp =3D 0x0000000000000000 > lr =3D 0x0000000000000000 > sp =3D 0x0000fffffffee630 > pc =3D 0x0000000000000000 >=20 > And looking around (most nested to outer most): >=20 > 0xfffffffee530: 0x0000fffffffee570 0x000000004054cd94 > libc.so.7`__free: > 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 > 0x4054cd94 <+148>: adrp x9, 185 > 0xfffffffee570: 0x0000fffffffee590 0x0000000000411300 > sh`ckfree: > 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free > 0x411300 <+32>: ldr x8, [x19, #0x970] > 0xfffffffee590: 0x0000fffffffee5d0 0x000000000040e6e8 > sh`freejob: > 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 > 0x40e6e8 <+140>: adrp x8, 38 > 0xfffffffee5d0: 0x0000ffffffffcaa0 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30 > (Note that sp=3D=3D0x0000fffffffee630 is fairly close to = 0xfffffffee5d0.) >=20 > (sizable frame jump from 0xfffffffee5d0 to 0x0000ffffffffcaa0, size = 0xE4D0=3D=3D58576 bytes) > (0xfffffffee5e0 up to 0xffffffffa890 (not inclusive) are all = 0x0000000000000000) > (The prior trace example did not have such a large area.) >=20 > 0xffffffffca50: 0x0000ffffffffcaa0 0x000000000040f1c8 > sh`forkshell: > 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 > 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork > 0x40f1cc <+152>: mov w19, w0 > (flushall a voids returning to 0x40f1c8 directly, instead making > the last routine it calls return there instead of to flushall.) >=20 > 0xffffffffcaa0: 0x0000ffffffffcb50 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 > 0xffffffffcb50: 0x0000ffffffffcde0 0x0000000000406e28 > sh`evalbackcmd: > 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 > 0x406e28 <+340>: ldur w0, [x29, #-0x5c] > 0xffffffffcde0: 0x0000ffffffffcf90 0x0000000000409324 > sh`argstr: > 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 > 0x409324 <+432>: mov x0, x26 > 0xffffffffcf90: 0x0000ffffffffcff0 0x0000000000408fa8 > sh`expandarg: > 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 > 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 > 0xffffffffcff0: 0x0000ffffffffd320 0x0000000000405f48 > sh`evalcommand: > 0x405f44 <+220>: bl 0x408f38 ; expandarg at = expand.c:225 > 0x405f48 <+224>: ldr x24, [x24, #0x8] >=20 > 0xffffffffd0f0: 0x0000ffffffffd320 0x00000000004068e4 > sh`evalcommand: > 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub = for: _setjmp > 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 >=20 > 0xffffffffd320: 0x0000ffffffffd3d0 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffd3d0: 0x0000ffffffffd480 0x0000000000405550 > sh`cmdloop: > 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 > 0x411034 <+252>: mov w27, wzr > 0xffffffffd480: 0x0000ffffffffd7b0 0x00000000004067d0 > sh`evalcommand: > 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 > 0x4067d0 <+2408>: ldr x8, [x24, #0x970] > 0xffffffffd7b0: 0x0000ffffffffd860 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffd860: 0x0000ffffffffd910 0x0000000000405550 > sh`evaltree: > 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 > 0x405550 <+180>: ldr w8, [x22, #0x994] > 0xffffffffd910: 0x0000ffffffffdc40 0x00000000004067d0 > sh`evalcommand: > 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 > 0x4067d0 <+2408>: ldr x8, [x24, #0x970] >=20 > 0xffffffffda10: 0x0000ffffffffdc40 0x000000000040673c > sh`evalcommand: > 0x406738 <+2256>: bl 0x402be0 ; symbol stub = for: _setjmp > 0x40673c <+2260>: cbnz w0, 0x406c60 ; <+3576> at = eval.c:1042 >=20 > 0xffffffffdc40: 0x0000ffffffffdcf0 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffdcf0: 0x0000ffffffffdd70 0x0000000000411034 > sh`cmdloop: > 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 > 0x411034 <+252>: mov w27, wzr > 0xffffffffdd70: 0x0000ffffffffddd0 0x0000000000410ea8 > sh`main: > 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 > 0x410ea8 <+660>: adrp x8, 36 > 0xffffffffddd0: 0x0000ffffffffde10 0x0000000000402f30 > sh`__start: > 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 > 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit >=20 > (_rtld is not in the core file) > 0xffffffffde10: 0x0000000000000000 0x0000000040434658 > ld-elf.so.1`.rtld_start: > 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 > 0x40434658 <+24>: mov x8, x0 >=20 > So again the problem is associated with the forkshell/fork/freejob > related materials. >=20 > (I mistakenly left out the evalcommand/_setjmp material > when I made the trace in the below. The same for flushall. > I've inserted some of that below, at least for > the flushall context.) On 2017-Feb-6, at 8:05 PM, Mark Millard wrote: > [I got a lucky sh core dump with more stack context/content > available to look at for an example sh crash. This helps > narrow things down.] >=20 > On 2017-Feb-5, at 1:12 AM, Mark Millard = wrote: >=20 >> [Top post of a new result.] >>=20 >> Using lldb to look at the memory for the stack around >> sh failure points has some apparently fixed structure. >> Example: >>=20 >> . . . junk values . . . >> 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 >> 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 >> 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 >> 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 >> 0xffffffffe520: 0x0000000000000000 0x0000000000000000 >> 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 >> 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe550: 0x0000000000434000 0x000000000000000f >> 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 >> 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e >> 0xffffffffe580: 0x0000000000000001 0x0000000000000005 >> 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >> . . . junk values . . . >=20 > I got lucky and got a core dump that did not have the junk > areas and could trace the stack's frame pointer chain > between main and libc.so.7`__free (through freejob along > the way). See later. >=20 >> where "register read" showed: >>=20 >> sp =3D 0x0000ffffffffe600 >>=20 >> (The distance and direction to the last non-junk line >> from the reported sp in each example is the same.) >> Looking around that 0x000000000040f490: >>=20 >> 0x40f48c: 0x97fffc74 bl 0x40e65c ; freejob at = jobs.c:463 >> 0x40f490: 0x9100c294 add x20, x20, #0x30 ; =3D0x30=20 >>=20 >> It is the same address and code in each case. >=20 > I should have originally noted that 0x40f48c is in > forkshell, along the child process code-path: >=20 > pid_t > forkshell(struct job *jp, union node *n, int mode) > { > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > INTOFF; > if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) > checkzombies(); > flushall(); > pid =3D fork(); > if (pid =3D=3D -1) { > TRACE(("Fork failed, errno=3D%d\n", errno)); > INTON; > error("Cannot fork: %s", strerror(errno)); > } > if (pid =3D=3D 0) { > struct job *p; > int wasroot; > int i; >=20 > TRACE(("Child shell %d\n", (int)getpid())); > wasroot =3D rootshell; > rootshell =3D 0; > handler =3D &main_handler; > closescript(); > INTON; > forcelocal =3D 0; > clear_traps(); > #if JOBS > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > #else > . . . (see /usr/src/bin/sh/jobs.c for this) . . . > #endif > INTOFF; > for (i =3D njobs, p =3D jobtab ; --i >=3D 0 ; p++) > if (p->used) > freejob(p); > INTON; > if (wasroot && iflag) { > setsignal(SIGINT); > setsignal(SIGQUIT); > setsignal(SIGTERM); > } > return pid; > } > . . . (see /usr/src/bin/sh/jobs.c for this) . . . >=20 >> Sometimes the junk values are all zeros over sizable >> distances. Sometimes the sizable areas seem to have >> random data. >>=20 >> /usr/src/bin/sh/jobs.c 's freejobs is: >>=20 >> static void >> freejob(struct job *jp) >> { >> struct procstat *ps; >> int i; >>=20 >> INTOFF; >> if (bgjob =3D=3D jp) >> bgjob =3D NULL; >> for (i =3D jp->nprocs, ps =3D jp->ps ; --i >=3D 0 ; ps++) { >> if (ps->cmd !=3D nullstr) >> ckfree(ps->cmd); >> } >> if (jp->ps !=3D &jp->ps0) >> ckfree(jp->ps); >> jp->used =3D 0; >> #if JOBS >> deljob(jp); >> #endif >> INTON; >> } >>=20 >> /usr/src/bin/sh/error.h defines INTOFF and INTON: >>=20 >> #define EXINT 0 /* SIGINT received */ >> #define EXERROR 1 /* a generic error */ >> #define EXEXEC 2 /* command execution failed */ >> #define EXEXIT 3 /* call exitshell(exitstatus) */ >>=20 >> . . . >>=20 >> extern struct jmploc *handler; >> extern volatile sig_atomic_t exception; >>=20 >> . . . >>=20 >> extern volatile sig_atomic_t suppressint; >> extern volatile sig_atomic_t intpending; >>=20 >> #define INTOFF suppressint++ >> #define INTON { if (--suppressint =3D=3D 0 && intpending) onint(); } >> #define is_int_on() suppressint >> #define SETINTON(s) suppressint =3D (s) >> #define FORCEINTON {suppressint =3D 0; if (intpending) onint();} >> #define SET_PENDING_INT intpending =3D 1 >> #define CLEAR_PENDING_INT intpending =3D 0 >> #define int_pending() intpending >>=20 >> void exraise(int) __dead2; >> void onint(void) __dead2; >>=20 >> /usr/src/bin/sh/error.c hAS: >>=20 >> void >> exraise(int e) >> { >> INTOFF; >> if (handler =3D=3D NULL) >> abort(); >> exception =3D e; >> longjmp(handler->loc, 1); >> } >> . . . >> void >> onint(void) >> { >> sigset_t sigs; >>=20 >> intpending =3D 0; >> sigemptyset(&sigs); >> sigprocmask(SIG_SETMASK, &sigs, NULL); >>=20 >> /* >> * This doesn't seem to be needed, since main() emits a newline. >> */ >> #if 0 >> if (tcgetpgrp(0) =3D=3D getpid()) >> write(STDERR_FILENO, "\n", 1); >> #endif >> if (rootshell && iflag) >> exraise(EXINT); >> else { >> signal(SIGINT, SIG_DFL); >> kill(getpid(), SIGINT); >> _exit(128 + SIGINT); >> } >> } >>=20 >> # grep setjmp /usr/src/bin/sh/* >> /usr/src/bin/sh/TOUR:so I implement it using setjmp and longjmp. The = global variable >> /usr/src/bin/sh/error.h:#include >> /usr/src/bin/sh/error.h: * BSD setjmp saves the signal mask, which = violates ANSI C and takes time, >> /usr/src/bin/sh/error.h: * so we use _setjmp instead. >> /usr/src/bin/sh/error.h:#define setjmp(jmploc) _setjmp(jmploc) >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/histedit.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/jobs.c: if (setjmp(jmploc.loc)) >> /usr/src/bin/sh/main.c: * commands. The setjmp call sets up the = location to jump to when an >> /usr/src/bin/sh/main.c: if (setjmp(main_handler.loc)) { >> /usr/src/bin/sh/parser.c: if (setjmp(jmploc.loc)) { >> /usr/src/bin/sh/parser.c: if (!setjmp(jmploc.loc)) { >> /usr/src/bin/sh/trap.c: if (!setjmp(loc1.loc)) { >> /usr/src/bin/sh/trap.c: if (!setjmp(loc2.loc)) { >> /usr/src/bin/sh/var.c: if (setjmp(jmploc.loc)) >=20 > Here is the call chain that I was able to trace > in the newer core dump: > (most nested first to least nested last; > showing frame pointer and lr value pairs > and calls/return-places) >=20 > (ifree is not in the core file) > 0xffffffffcc60: 0x0000ffffffffcca0 0x000000004054cd94 > libc.so.7`__free: > 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 > 0x4054cd94 <+148>: adrp x9, 185 > 0xffffffffcca0: 0x0000ffffffffccc0 0x0000000000411300 > sh`ckfree: > 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free > 0x411300 <+32>: ldr x8, [x19, #0x970] > 0xffffffffccc0: 0x0000ffffffffcd00 0x000000000040e6e8 > sh`freejob: > 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 > 0x40e6e8 <+140>: adrp x8, 38 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 sh`forkshell: 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork 0x40f1cc <+152>: mov w19, w0 (flushall a voids returning to 0x40f1c8 directly, instead making the last routine it calls return there instead of to flushall.) > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 > 0xffffffffced0: 0x0000ffffffffd160 0x0000000000406e28 > sh`evalbackcmd: > 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 > 0x406e28 <+340>: ldur w0, [x29, #-0x5c]0xffffffffcd60: = 0x0000ffffffffcf90 0x00000000004068e4 > 0xffffffffd160: 0x0000ffffffffd310 0x0000000000409324 > sh`argstr: > 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 > 0x409324 <+432>: mov x0, x26 > 0xffffffffd310: 0x0000ffffffffd370 0x0000000000408fa8 > sh`expandarg: > 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 > 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 > 0xffffffffd370: 0x0000ffffffffd5f0 0x0000000000407530 > sh`exphere: > 0x40752c <+212>: bl 0x408f38 ; expandarg at = expand.c:225 > 0x407530 <+216>: ldr x8, [x20] > 0xffffffffd5f0: 0x0000ffffffffd630 0x00000000004073f0 > sh`expredir: > 0x4073ec <+112>: bl 0x407458 ; exphere at = eval.c:494 > 0x4073f0 <+116>: b 0x407428 ; <+172> at = eval.c:535 > 0xffffffffd630: 0x0000ffffffffd960 0x0000000000406154 > sh`evalcommand: > 0x406150 <+744>: bl 0x40737c ; expredir at = eval.c:532 > 0x406154 <+748>: ldur w27, [x29, #-0x68] > 0xffffffffd960: 0x0000ffffffffda10 0x0000000000405570 > sh`evaltree: > 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 > 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 > 0x405574 <+216>: ldr x8, [x24, #0x8] > 0xffffffffda10: 0x0000ffffffffdac0 0x00000000004056b4 > sh`evaltree: > 0x4056b0 <+532>: bl 0x40549c ; <+0> at = eval.c:193 > 0x4056b4 <+536>: ldr w8, [x19, #0x990] > 0xffffffffdac0: 0x0000ffffffffdb70 0x0000000000405550 > sh`evaltree: > 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 > 0x405550 <+180>: ldr w8, [x22, #0x994] > 0xffffffffdb70: 0x0000ffffffffdbf0 0x0000000000411034 > sh`cmdloop: > 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 > 0x411034 <+252>: mov w27, wzr > 0xffffffffdbf0: 0x0000ffffffffdc50 0x0000000000410ea8 > sh`main: > 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 > 0x410ea8 <+660>: adrp x8, 36 > 0xffffffffdc50: 0x0000ffffffffdc90 0x0000000000402f30 > sh`__start: > 0x402f2c <+356>: bl 0x410c14 ; main at main.c:97 > 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit >=20 > (_rtld is not in the core file) > 0xffffffffdc90: 0x0000000000000000 0x0000000040434658 > ld-elf.so.1`.rtld_start: > 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 > 0x40434658 <+24>: mov x8, x0 >=20 > Some of the most nested possibly had returned. But the > forkshell / freejob general time frame seem to match > everything that I've seen. >=20 > [The details of the middle "eval*" related layers vary > from what I can tell.] >=20 > "register read" shows fp, lr, and pc majorly > messed up. >=20 > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc > x2 =3D 0x0000000040a00000 > x3 =3D 0x0000000000000002 > x4 =3D 0x0000000000000096 > x5 =3D 0x0000000040a5fd10 > x6 =3D 0x0000000000434c28 sh..bss + 9448 > x7 =3D 0x0000000000434c28 sh..bss + 9448 > x8 =3D 0x0000000000000001 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000000000 > x11 =3D 0x0000000040a350c0 > x12 =3D 0x0000000040a0e770 > x13 =3D 0x0000000000000072 > x14 =3D 0x000000000000006f > x15 =3D 0x0000000000000010 > x16 =3D 0x0000000000432340 =20 > x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 > x18 =3D 0x0000000000000000 > x19 =3D 0x0000000000000000 > x20 =3D 0x0000000000000000 > x21 =3D 0x0000000000000001 > x22 =3D 0x0000000040a5ff10 > x23 =3D 0x0000ffffffffd190 > x24 =3D 0x0000000000434000 sh..bss + 6336 > x25 =3D 0x0000000000434000 sh..bss + 6336 > x26 =3D 0x0000ffffffffcd00 > x27 =3D 0x0000000000434000 sh..bss + 6336 > x28 =3D 0x0000000040a6f5e0 > fp =3D 0x0000000040a5fed8 > lr =3D 0x0000000000000000 > sp =3D 0x0000ffffffffcd60 > pc =3D 0x0000000000000000 > cpsr =3D 0x60000000 >=20 > sp is also odd by being in the middle of the stack range > for: >=20 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > sh`forkshell: > 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 > 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > sh`evaltree: > 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 > 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 >=20 > NOTE: The fork happened earlier in sh`forkshell and this > is the child process that has the odd value. >=20 > [It leaves me wondering if 0x0000ffffffffcd60 is a stack > pointer value associated with a call to something > earlier than the sh`forkshell call that is called by > sh`forkshell .] >=20 > Also: in the ones with only a small section of the junk > areas the equivalent of: >=20 > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 >=20 > is the largest addressed non-junk content in the area > and the equivalent of: >=20 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 >=20 > would instead show zeros or "random" garbage values. >=20 > In this case, however that range of the stack looks like: >=20 > . . . > 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 > 0xffffffffcd10: 0x0000ffffffffcd00 0x0000000000434000 > 0xffffffffcd20: 0x0000000000434000 0x0000ffffffffd190 > 0xffffffffcd30: 0x0000000040a5ff10 0x0000000000000001 > 0xffffffffcd40: 0x0000000000000000 0x0000000000000000 > 0xffffffffcd50: 0x0000000040a5fed8 0x0000000000000000 > 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 > 0xffffffffcd70: 0x0000000000000000 0x827a80ccb3228215 > 0xffffffffcd80: 0x0000000040a6f5c0 0x0000000000434000 > 0xffffffffcd90: 0x0000000000434000 0x0000000000434000 > 0xffffffffcda0: 0x0000000000434000 0x0000000000434000 > 0xffffffffcdb0: 0x0000000040a6f638 0x0000000000000000 > 0xffffffffcdc0: 0x0000000040a350c0 0x0000000000434000 > 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 > 0xffffffffcde0: 0x0000000000000003 0x0000000040a350c0 > 0xffffffffcdf0: 0x0000000040a6f5c0 0x0000000000434000 > 0xffffffffce00: 0x0000000000434000 0x0000000040a6f638 > 0xffffffffce10: 0x0000000000000000 0x0000000000434000 > 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 > . . . >=20 > Interestingly 0xffffffffcd60 reported for the sp looks > like it has a frame-pointer/lr-value pair that does not > fit with the overall call chain that ties together but > is some fragment of a prior(?) call chain: >=20 > 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 > sh`evalcommand: > 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub for: = _setjmp > 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 >=20 > It looks like it is a record from calling _setjmp in > sh`evalcommand . >=20 > (sh uses _setjmp/_longjmp via macros that turn > into them for setjmp/longjmp references in > sh's source code.) >=20 > Interestingly (likely junk relative to the above): >=20 > 0xffffffffcf90: 0x0000000000000000 0x0000000000432000 >=20 > where: >=20 > (lldb) dis -s 0x0000000000432000 > sh`__frame_dummy_init_array_entry: > 0x432000 <+0>: .long 0x00402fac ; unknown opcode > 0x432004 <+4>: .long 0x00000000 ; unknown opcode > (lldb) dis -s __frame_dummy_init_array_entry -c32 > sh`frame_dummy: > 0x402fac <+0>: adrp x8, 48 > 0x402fb0 <+4>: adrp x1, 48 > 0x402fb4 <+8>: ldr x8, [x8, #0x30] > 0x402fb8 <+12>: ldr x1, [x1, #0x228] > 0x402fbc <+16>: cmp x8, #0x0 ; =3D0x0=20 > 0x402fc0 <+20>: ccmp x1, #0x0, #0x4, ne > 0x402fc4 <+24>: b.ne 0x402fcc ; <+32> > 0x402fc8 <+28>: ret =20 > 0x402fcc <+32>: adrp x0, 48 > 0x402fd0 <+36>: add x0, x0, #0x30 ; =3D0x30=20 > 0x402fd4 <+40>: br x1 >=20 > sh`lookupalias: > . . . >=20 >=20 > Ohter notes: >=20 > Some examples of funcnest=3D=3D0 others have (e.g.) funcnest=3D=3D2. > This one had funcnest=3D=3D0. >=20 > commandname varies. In this case it was: >=20 > (lldb) print commandname > (char *) $74 =3D 0x0000ffffffffe210 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/configure" >=20 > Other examples include: >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffdc40 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/fi= xincludes/configure" >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffe498 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/../config.sub" >=20 > (lldb) print commandname > (char *) $0 =3D 0x0000ffffffffe398 "../libtool" >=20 >=20 > So far the forkshell/fork/freejob and associated materials always = seeming > to be involved is all that I've found that is common (at least that is > suggested by what I see so far) within the sh context. >=20 >> Other notes: >>=20 >> As a personal investigation I've temporarily changed to using >> something not fully generic but based on gic-400 specifics: >>=20 >> # svnlite diff /usr/src/sys/arm/arm/gic.c >> Index: /usr/src/sys/arm/arm/gic.c >> =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/src/sys/arm/arm/gic.c (revision 312982) >> +++ /usr/src/sys/arm/arm/gic.c (working copy) >> @@ -672,9 +672,13 @@ >>=20 >> if (irq >=3D sc->nirqs) { >> #ifdef GIC_DEBUG_SPURIOUS >> +#define EXPECTED_SPURIOUS_IRQ 1023 >> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >> device_printf(sc->gic_dev, >> - "Spurious interrupt detected: last irq: %d on = CPU%d\n", >> + "Spurious interrupt %d detected of %d: last irq: = %d on CPU%d\n", >> + irq, sc->nirqs, >> sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >> + } >> #endif >> return (FILTER_HANDLED); >> } >> @@ -720,6 +724,16 @@ >> if (irq < sc->nirqs) >> goto dispatch_irq; >>=20 >> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >> +#undef EXPECTED_SPURIOUS_IRQ >> +#ifdef GIC_DEBUG_SPURIOUS >> + device_printf(sc->gic_dev, >> + "Spurious end interrupt %d detected of %d: last = irq: %d on CPU%d\n", >> + irq, sc->nirqs, >> + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >> +#endif >> + } >> + >> return (FILTER_HANDLED); >> } >>=20 >>=20 >> The result was no notices of Spurious interrupts have been generated: >> All of the odd interrupts were the special 1023 value. >>=20 >> [As far as I could tell from the code the configuration is such that >> 1022 should not be generated --and were not. 1020 and 1021 are >> reserved and should not be generated.] =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ 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" _______________________________________________ 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 Feb 11 07:28:20 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C869CDB1FF for ; Sat, 11 Feb 2017 07:28:20 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from wa3yre.wynn.com (wa3yre.wynn.com [199.89.147.3]) (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 4FC9A18D9 for ; Sat, 11 Feb 2017 07:28:19 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from pearl (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by wa3yre.wynn.com (8.14.3/8.12.6) with ESMTP id v1B7SA2Z017898 for ; Sat, 11 Feb 2017 02:28:11 -0500 (EST) (envelope-from wynkoop@wynn.com) Received: from pearl ([199.89.147.252] helo=pearl) by ASSP-nospam with ESMTPS(AES256-SHA) (ASSP 1.10.1); 11 Feb 2017 02:28:10 -0500 Date: Sat, 11 Feb 2017 02:28:00 -0500 From: Brett Wynkoop To: Subject: Out of swap - NOT Message-ID: Reply-To: wynkoop@wynn.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-apple-darwin10.8.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 07:28:20 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkdyZWV0 aW5nLQ0KDQpTbyBJIGhhdmUgc2VlbiB0aGlzIHNldmVyYWwgdGltZXMgb24gRnJlZUJTRC0xMiAt IHVuYW1lIGluZm8gdG8gZm9sbG93DQoNCkZyZWVCU0QgYmIyLnd5bm4uY29tIDEyLjAtQ1VSUkVO VCBGcmVlQlNEIDEyLjAtQ1VSUkVOVCAjMCByMzExNDYxOiBGcmkNCkphbiAgNiAwMzoxMzowMSBV VEMgMjAxNw0Kcm9vdEByZWxlbmczLm55aS5mcmVlYnNkLm9yZzovdXNyL29iai9hcm0uYXJtdjYv dXNyL3NyYy9zeXMvQkVBR0xFQk9ORQ0KYXJtDQoNCk1BS0U9bWFrZSBzaCAuLi8uLi8uLi9jb25m L25ld3ZlcnMuc2ggIEJFQUdMRUJPTkUNCmNjIC1jIC1PIC1waXBlICAtZyAtbm9zdGRpbmMgIC1J LiAtSS4uLy4uLy4uIC1JLi4vLi4vLi4vY29udHJpYi9saWJmZHQNCi0gLUkuLi8uLi8uLi9nbnUv ZHRzL2luY2x1ZGUgLURfS0VSTkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMNCi0gLWlu Y2x1ZGUgb3B0X2dsb2JhbC5oIC1tYXJjaD1hcm12N2EgLWZ1bndpbmQtdGFibGVzICAtZmZyZWVz dGFuZGluZw0KLSAtZndyYXB2IC1nZHdhcmYtMiAtV2FsbCAtV3JlZHVuZGFudC1kZWNscyAtV25l c3RlZC1leHRlcm5zDQotIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMg LVdwb2ludGVyLWFyaXRoIC1XaW5saW5lDQotIC1XY2FzdC1xdWFsIC1XdW5kZWYgLVduby1wb2lu dGVyLXNpZ24gLURfX3ByaW50Zl9fPV9fZnJlZWJzZF9rcHJpbnRmX18NCi0gLVdtaXNzaW5nLWlu Y2x1ZGUtZGlycyAtZmRpYWdub3N0aWNzLXNob3ctb3B0aW9uIC1Xbm8tdW5rbm93bi1wcmFnbWFz DQotIC1Xbm8tZXJyb3ItdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby1lcnJvci1lbXB0eS1ib2R5 DQotIC1Xbm8tZXJyb3ItcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby1lcnJvci11bnVzZWQtZnVu Y3Rpb24NCi0gLVduby1lcnJvci1wb2ludGVyLXNpZ24gLVduby1lcnJvci1zaGlmdC1uZWdhdGl2 ZS12YWx1ZSAgLW1mcHU9bm9uZQ0KLSAtc3RkPWlzbzk4OTk6MTk5OSAtV2Vycm9yICB2ZXJzLmMg Y3RmY29udmVydCAtTCBWRVJTSU9OIC1nIHZlcnMubw0KbGlua2luZyBrZXJuZWwuZnVsbCBjdGZt ZXJnZSAtTCBWRVJTSU9OIC1nIC1vIGtlcm5lbC5mdWxsIC4uLiAqKioNClNpZ25hbCA5DQoNClN0 b3AuDQptYWtlOiBzdG9wcGVkIGluIC9leHBvcnQvc3JjL3N5cy9hcm0vY29tcGlsZS9CRUFHTEVC T05FDQpyb290QGJiMjovc3lzL2FybS9jb21waWxlL0JFQUdMRUJPTkUgIyANCg0KcGlkIDI0NTIz IChjdGZtZXJnZSksIHVpZCAwLCB3YXMga2lsbGVkOiBvdXQgb2Ygc3dhcCBzcGFjZQ0KcGlkIDIx MzY1IChtYWtlKSwgdWlkIDAsIHdhcyBraWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNlDQpwaWQgMzg1 MjcgKGN0Zm1lcmdlKSwgdWlkIDAsIHdhcyBraWxsZWQ6IG91dCBvZiBzd2FwIHNwYWNlDQpbd3lu a29vcEBiYjIgfl0kDQoNCg0KSSBoYXZlIHJ1biB0aGUga2VybmVsIGJ1aWxkIHNldmVyYWwgdGlt ZXMgYW5kIHRoaXMgaXMgYWx3YXlzIHRoZQ0KcmVzdWx0LiAgSSBhbHNvIGhhZCBhbiByc3luYyBr aWxsZWQgZm9yIG91dCBvZiBzd2FwLiAgVGhlIGludGVyZXN0aW5nDQpwYXJ0IGlzIHRoYXQgYXQg bm8gdGltZSBkaWQgSSByZWFsbHkgcnVuIG91dCBvZiBzd2FwLiAgVGhpcyBpcyBvbiBhbg0Kb3Jp Z2luYWwgQmVhZ2xlQm9uZSB3aXRoIDI1Nk0gb2YgcmFtIGFuZCA3NjhNIG9mIHN3YXAuICBBdCBu byB0aW1lIGRpZA0KcHN0YXQgb3IgdG9wIGluIGFub3RoZXIgd2luZG93IHJlcG9ydCB0aGF0IGFs bCB0aGUgc3dhcCB3YXMgdXNlZC4gIEluDQpmYWN0IHN3YXAgdXNlIG5ldmVyIGdvdCBhYm92ZSAx MCUuDQoNCkkgaGF2ZSBiZWVuIHVzaW5nIEJTRCBzaW5jZSB0aGUgZWFybHkgMTk4MCdzIGFuZCBo YXZlIG5ldmVyIHNlZW4gYQ0Kc3lzdGVtIHJlcG9ydCBhIHByb2Nlc3MgYmVpbmcga2lsbGVkIGZv ciBvdXQgb2Ygc3dhcCB3aGVuIHRoZXJlIGlzDQpzdGlsbCBwbGVudHkgb2Ygc3dhcCBiZWZvcmUg bm93Lg0KDQpJZGVhcz8gIA0KDQotIC1CcmV0dA0KLSAtLSANCg0Kd3lua29vcEB3eW5uLmNvbQ0K OTE3LTY0Mi02OTI1DQo5MjktMjcyLTAwMDANCg0KQW1lbmRtZW50IEkNCg0KQ29uZ3Jlc3Mgc2hh bGwgbWFrZSBubyBsYXcgcmVzcGVjdGluZyBhbiBlc3RhYmxpc2htZW50IG9mIHJlbGlnaW9uLCBv cg0KcHJvaGliaXRpbmcgdGhlIGZyZWUgZXhlcmNpc2UgdGhlcmVvZjsgb3IgYWJyaWRnaW5nIHRo ZSBmcmVlZG9tIG9mDQpzcGVlY2gsIG9yIG9mIHRoZSBwcmVzczsgb3IgdGhlIHJpZ2h0IG9mIHRo ZSBwZW9wbGUgcGVhY2VhYmx5IHRvDQphc3NlbWJsZSwgYW5kIHRvIHBldGl0aW9uIHRoZSBnb3Zl cm5tZW50IGZvciBhIHJlZHJlc3Mgb2YgZ3JpZXZhbmNlcy4NCg0KLS0tLS1CRUdJTiBQR1AgU0lH TkFUVVJFLS0tLS0NCg0KaVFFY0JBRUJDQUFHQlFKWW5yMEpBQW9KRUs2SzN5cmMrUnVELzhNSC9S WGRxaVNmUXFMZHduOWg3UzErUkRvcw0KL1Roak8vQnhjNGNEaDc1bm9BQ3RGaElxQXhnYzFKTWNu OXFFV0tlbEhnYUpybW9qcXVtQmtSWllEMk1OWjBpRw0KQUVuMWUrY1pwdTZyWmZMcmZ6ODFLcFl4 MW4xbWhtUndFRFd2emlTMWcrVm5iYXFmYWE1em5RcjJ6RFozL1N6VA0KdURUTTNHQjJSMmVsM003 elhrTU5HbWV5ZER1UTk3MVZ0Y3RYUUd5T05reGVnN2tNQ3VaT0lXemc1RWprUFllQg0KVGpoOFhW YmZuQ243N2JwRm5WSzVsRE9qRXQrY1JMUDFpQzNyN01IbjlrZE9vWGxRT2UvSHcyZXNKRzlienFs aw0KNTFBbGVJVlg2dzFqRDdYMVBTcWpLZzJNU09FZXFUdU8vSmlWUEJTMVlRNlk3WGdUZGF5Qzl6 NXptS2lBaVQ4PQ0KPTRXNzYNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-arm@freebsd.org Sat Feb 11 07:30:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03C9DCDB265 for ; Sat, 11 Feb 2017 07:30:53 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from wa3yre.wynn.com (wa3yre.wynn.com [199.89.147.3]) (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 B41C81988 for ; Sat, 11 Feb 2017 07:30:52 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from pearl (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by wa3yre.wynn.com (8.14.3/8.12.6) with ESMTP id v1B7Uo2W018047 for ; Sat, 11 Feb 2017 02:30:50 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Received: from pearl ([199.89.147.252] helo=pearl) by ASSP-nospam with ESMTPS(AES256-SHA) (ASSP 1.10.1); 11 Feb 2017 02:30:50 -0500 Date: Sat, 11 Feb 2017 02:30:50 -0500 From: freebsd-arm@wynn.com To: Subject: Out of swap - NOT Message-ID: Reply-To: wynkoop@wynn.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-apple-darwin10.8.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 07:30:53 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCg0KR3Jl ZXRpbmctDQoNClNvIEkgaGF2ZSBzZWVuIHRoaXMgc2V2ZXJhbCB0aW1lcyBvbiBGcmVlQlNELTEy IC0gdW5hbWUgaW5mbyB0byBmb2xsb3cNCg0KRnJlZUJTRCBiYjIud3lubi5jb20gMTIuMC1DVVJS RU5UIEZyZWVCU0QgMTIuMC1DVVJSRU5UICMwIHIzMTE0NjE6IEZyaQ0KSmFuICA2IDAzOjEzOjAx IFVUQyAyMDE3DQpyb290QHJlbGVuZzMubnlpLmZyZWVic2Qub3JnOi91c3Ivb2JqL2FybS5hcm12 Ni91c3Ivc3JjL3N5cy9CRUFHTEVCT05FDQphcm0NCg0KTUFLRT1tYWtlIHNoIC4uLy4uLy4uL2Nv bmYvbmV3dmVycy5zaCAgQkVBR0xFQk9ORQ0KY2MgLWMgLU8gLXBpcGUgIC1nIC1ub3N0ZGluYyAg LUkuIC1JLi4vLi4vLi4gLUkuLi8uLi8uLi9jb250cmliL2xpYmZkdA0KLSAtIC1JLi4vLi4vLi4v Z251L2R0cy9pbmNsdWRlIC1EX0tFUk5FTCAtREhBVkVfS0VSTkVMX09QVElPTl9IRUFERVJTDQot IC0gLWluY2x1ZGUgb3B0X2dsb2JhbC5oIC1tYXJjaD1hcm12N2EgLWZ1bndpbmQtdGFibGVzICAt ZmZyZWVzdGFuZGluZw0KLSAtIC1md3JhcHYgLWdkd2FyZi0yIC1XYWxsIC1XcmVkdW5kYW50LWRl Y2xzIC1XbmVzdGVkLWV4dGVybnMNCi0gLSAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1w cm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV2lubGluZQ0KLSAtIC1XY2FzdC1xdWFsIC1XdW5k ZWYgLVduby1wb2ludGVyLXNpZ24gLURfX3ByaW50Zl9fPV9fZnJlZWJzZF9rcHJpbnRmX18NCi0g LSAtV21pc3NpbmctaW5jbHVkZS1kaXJzIC1mZGlhZ25vc3RpY3Mtc2hvdy1vcHRpb24gLVduby11 bmtub3duLXByYWdtYXMNCi0gLSAtV25vLWVycm9yLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8t ZXJyb3ItZW1wdHktYm9keQ0KLSAtIC1Xbm8tZXJyb3ItcGFyZW50aGVzZXMtZXF1YWxpdHkgLVdu by1lcnJvci11bnVzZWQtZnVuY3Rpb24NCi0gLSAtV25vLWVycm9yLXBvaW50ZXItc2lnbiAtV25v LWVycm9yLXNoaWZ0LW5lZ2F0aXZlLXZhbHVlICAtbWZwdT1ub25lDQotIC0gLXN0ZD1pc285ODk5 OjE5OTkgLVdlcnJvciAgdmVycy5jIGN0ZmNvbnZlcnQgLUwgVkVSU0lPTiAtZyB2ZXJzLm8NCmxp bmtpbmcga2VybmVsLmZ1bGwgY3RmbWVyZ2UgLUwgVkVSU0lPTiAtZyAtbyBrZXJuZWwuZnVsbCAu Li4gKioqDQpTaWduYWwgOQ0KDQpTdG9wLg0KbWFrZTogc3RvcHBlZCBpbiAvZXhwb3J0L3NyYy9z eXMvYXJtL2NvbXBpbGUvQkVBR0xFQk9ORQ0Kcm9vdEBiYjI6L3N5cy9hcm0vY29tcGlsZS9CRUFH TEVCT05FICMgDQoNCnBpZCAyNDUyMyAoY3RmbWVyZ2UpLCB1aWQgMCwgd2FzIGtpbGxlZDogb3V0 IG9mIHN3YXAgc3BhY2UNCnBpZCAyMTM2NSAobWFrZSksIHVpZCAwLCB3YXMga2lsbGVkOiBvdXQg b2Ygc3dhcCBzcGFjZQ0KcGlkIDM4NTI3IChjdGZtZXJnZSksIHVpZCAwLCB3YXMga2lsbGVkOiBv dXQgb2Ygc3dhcCBzcGFjZQ0KW3d5bmtvb3BAYmIyIH5dJA0KDQoNCkkgaGF2ZSBydW4gdGhlIGtl cm5lbCBidWlsZCBzZXZlcmFsIHRpbWVzIGFuZCB0aGlzIGlzIGFsd2F5cyB0aGUNCnJlc3VsdC4g IEkgYWxzbyBoYWQgYW4gcnN5bmMga2lsbGVkIGZvciBvdXQgb2Ygc3dhcC4gIFRoZSBpbnRlcmVz dGluZw0KcGFydCBpcyB0aGF0IGF0IG5vIHRpbWUgZGlkIEkgcmVhbGx5IHJ1biBvdXQgb2Ygc3dh cC4gIFRoaXMgaXMgb24gYW4NCm9yaWdpbmFsIEJlYWdsZUJvbmUgd2l0aCAyNTZNIG9mIHJhbSBh bmQgNzY4TSBvZiBzd2FwLiAgQXQgbm8gdGltZSBkaWQNCnBzdGF0IG9yIHRvcCBpbiBhbm90aGVy IHdpbmRvdyByZXBvcnQgdGhhdCBhbGwgdGhlIHN3YXAgd2FzIHVzZWQuICBJbg0KZmFjdCBzd2Fw IHVzZSBuZXZlciBnb3QgYWJvdmUgMTAlLg0KDQpJIGhhdmUgYmVlbiB1c2luZyBCU0Qgc2luY2Ug dGhlIGVhcmx5IDE5ODAncyBhbmQgaGF2ZSBuZXZlciBzZWVuIGENCnN5c3RlbSByZXBvcnQgYSBw cm9jZXNzIGJlaW5nIGtpbGxlZCBmb3Igb3V0IG9mIHN3YXAgd2hlbiB0aGVyZSBpcw0Kc3RpbGwg cGxlbnR5IG9mIHN3YXAgYmVmb3JlIG5vdy4NCg0KSWRlYXM/ICANCg0KLSAtIC1CcmV0dA0KLSAt IC0tIA0KDQp3eW5rb29wQHd5bm4uY29tDQo5MTctNjQyLTY5MjUNCjkyOS0yNzItMDAwMA0KDQpB bWVuZG1lbnQgSQ0KDQpDb25ncmVzcyBzaGFsbCBtYWtlIG5vIGxhdyByZXNwZWN0aW5nIGFuIGVz dGFibGlzaG1lbnQgb2YgcmVsaWdpb24sIG9yDQpwcm9oaWJpdGluZyB0aGUgZnJlZSBleGVyY2lz ZSB0aGVyZW9mOyBvciBhYnJpZGdpbmcgdGhlIGZyZWVkb20gb2YNCnNwZWVjaCwgb3Igb2YgdGhl IHByZXNzOyBvciB0aGUgcmlnaHQgb2YgdGhlIHBlb3BsZSBwZWFjZWFibHkgdG8NCmFzc2VtYmxl LCBhbmQgdG8gcGV0aXRpb24gdGhlIGdvdmVybm1lbnQgZm9yIGEgcmVkcmVzcyBvZiBncmlldmFu Y2VzLg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KaVFFY0JBRUJDQUFHQlFKWW5y MnFBQW9KRUs2SzN5cmMrUnVEblI0SC9pZzdaVFdVSysra1lhcXFoR2hGVm1lZw0KcVZZSFR6QTVm VnV5QTc0YVVIUTYrS1FrNVlSK3k5aUJoZ2VxdWNiZSthQ2VIM1hLN3hwaUdvVzBOMUllMmh5SA0K NnhmWVZMY21iOHk2Rjg5MlFRMksvSStRN0F1aEpjZWs0aktVSS83V09LY2ZJSkZZUk9GSTlLNTcv Yjk3aW5EWA0KRnNHZUlLNlJnaXJ0Uy9teWpFdDZEbU5ZTUJxZytPNkZPWVNSQlVrUkU5VWJZbFlr NEtpU3Q5bGlSUVZlYjEycQ0KdHdBT3dFS2R4VFFkUDA1VGlERTUwVEtKdE4xVi9EeEtrZ3NTdmw0 YTdYamc2WkZCU1ROU3BDRFBTWnhuQ2dHUg0KYkM5WWVuaGw1MXFWTkNtVnRtQkhwRWh5TW5IZ0FF RGlOd0kwNXJsajhjWFpzL3RWSXlFb21lTW9aUk5KeGNJPQ0KPVJlMTgNCi0tLS0tRU5EIFBHUCBT SUdOQVRVUkUtLS0tLQ0K From owner-freebsd-arm@freebsd.org Sat Feb 11 11:19:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 833A7CD94D4 for ; Sat, 11 Feb 2017 11:19:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-74.reflexion.net [208.70.210.74]) (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 21B4416E1 for ; Sat, 11 Feb 2017 11:19:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26404 invoked from network); 11 Feb 2017 11:19:26 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Feb 2017 11:19:26 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Sat, 11 Feb 2017 06:19:26 -0500 (EST) Received: (qmail 22328 invoked from network); 11 Feb 2017 11:19:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Feb 2017 11:19:26 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B5E5BEC8257; Sat, 11 Feb 2017 03:19:25 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Sat, 11 Feb 2017 03:19:25 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> <7B5DF446-6740-43DE-823D-B6ECBECF0C32@dsl-only.net> <1B1EEC5E-9875-417F-9901-A66CB5885634@dsl-only.net> <25B9EBC8-147F-47C2-BC40-C449EF3AC3FE@gmail.com> <71B83856-654D-4F38-894F-1DF41681F0FC@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: Message-Id: <2A1F1091-4115-46A1-8DB5-032099A49290@dsl-only.net> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 11:19:29 -0000 On 2017-Feb-10, at 9:59 PM, Mark Millard wrote: > The stack pointer is messed up when fork returns, > at least when it happens to be too large to be in > the stack region. >=20 > So I conclude that fork sometimes returns a > corrupted state in the child-process, at least > for the stack pointer. >=20 >=20 >=20 > Supporting details: >=20 > I've added stack checks for the stack pointer being > in too large for the proper stack region after the > fork in the child-process path > ( /usr/src/bin/sh/jobs.c modification): >=20 > extern void stack_check(void); >=20 > pid_t > forkshell(struct job *jp, union node *n, int mode) > { > pid_t pid; > pid_t pgrp; >=20 > TRACE(("forkshell(%%%td, %p, %d) called\n", jp - jobtab, (void = *)n, > mode)); > INTOFF; > if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) > checkzombies(); > flushall(); > pid =3D fork(); > if (pid =3D=3D -1) { > TRACE(("Fork failed, errno=3D%d\n", errno)); > INTON; > error("Cannot fork: %s", strerror(errno)); > } > if (pid =3D=3D 0) { > struct job *p; > int wasroot; > int i; >=20 > TRACE(("Child shell %d\n", (int)getpid())); > wasroot =3D rootshell; > rootshell =3D 0; > handler =3D &main_handler; > stack_check(); <<<<<<<=3D=3D=3D=3D=3D=3D this = one catches the "too large" case > closescript(); > stack_check(); > INTON; > stack_check(); > forcelocal =3D 0; > clear_traps(); > stack_check(); > . . . >=20 > (Note: TRACE is disabled.) >=20 > In a separate .c file: >=20 > void stack_check(void) > { > volatile uintptr_t test =3D 0; > extern struct jmploc main_handler; > if (*(uintptr_t*)&main_handler.loc[0]._jb[6] < = (uintptr_t)(void*)&test) abort(); > } >=20 > (I happened to use /usr/src/bin/sh/miscbltin.c with > a couple of includes added.) >=20 > Sometimes the bad sp value is not too large for the > stack region so this does not catch all the failures. >=20 >=20 >=20 > (lldb) bt > * thread #1: tid =3D 100144, 0x0000000040554e54 libc.so.7`_thr_kill + = 8, name =3D 'sh', stop reason =3D signal SIGABRT > * frame #0: 0x0000000040554e54 libc.so.7`_thr_kill + 8 > frame #1: 0x0000000040554e18 libc.so.7`__raise(s=3D6) + 64 at = raise.c:52 > frame #2: 0x0000000040554d8c libc.so.7`abort + 84 at abort.c:65 > frame #3: 0x0000000000411984 sh`stack_check + 88 at miscbltin.c:73 > frame #4: 0x000000000040f33c sh`forkshell(jp=3D, = n=3D, mode=3D) + 520 at jobs.c:865 > frame #5: 0x0000000000405954 sh`evaltree [inlined] evalpipe + 164 = at eval.c:596 > frame #6: 0x00000000004058b0 sh`evaltree(n=3D, = flags=3D) + 1044 at eval.c:286 > frame #7: 0x0000000000406e28 sh`evalbackcmd(n=3D0x0000000040a50af8, = result=3D0x0000ffffffffd2f0) + 340 at eval.c:702 > frame #8: 0x0000000000409324 sh`argstr [inlined] = expbackq(cmd=3D0x0000000040a50af8, flag=3D, = dst=3D) + 40 at expand.c:461 > frame #9: 0x00000000004092fc sh`argstr(p=3D"", flag=3D, = dst=3D) + 392 at expand.c:315 > frame #10: 0x0000000000408fa8 sh`expandarg(arg=3D, = arglist=3D0x0000ffffffffd688, flag=3D) + 112 at = expand.c:234 > frame #11: 0x0000000000405f48 sh`evalcommand(cmd=3D, = flags=3D, backcmd=3D) + 224 at eval.c:863 > frame #12: 0x0000000000405570 sh`evaltree(n=3D0x0000000040a50bd0, = flags=3D) + 212 at eval.c:290 > frame #13: 0x0000000000405550 sh`evaltree(n=3D0x0000000040a50ee0, = flags=3D) + 180 at eval.c:213 > frame #14: 0x0000000000411050 sh`cmdloop(top=3D) + 252 = at main.c:231 > frame #15: 0x0000000000410ec4 sh`main(argc=3D, = argv=3D) + 660 at main.c:178 > frame #16: 0x0000000000402f30 sh`__start + 360 > frame #17: 0x0000000040434658 ld-elf.so.1`.rtld_start + 24 at = rtld_start.S:41 >=20 > (lldb) register read > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x0000000000000000 > x2 =3D 0x0000000000000000 > x3 =3D 0x0000000040573638 libc.so.7`_sigprocmask > x4 =3D 0x0000000040a50b2c > x5 =3D 0x0000000040a4f4f9 > x6 =3D 0x0000000000646573 > x7 =3D 0x0000000000646573 > x8 =3D 0x00000000000001b1 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000000000 > x11 =3D 0x0000000000000018 > x12 =3D 0x0000000000000004 > x13 =3D 0x0000000000000427 > x14 =3D 0x0000000000000001 > x15 =3D 0x0000000000000000 > x16 =3D 0x0000000040554e4c libc.so.7`_thr_kill > x17 =3D 0x0000ffffffffe8e0 > x18 =3D 0x0000000000000000 > x19 =3D 0x0000000000000006 > x20 =3D 0x0000000040a36180 > x21 =3D 0x0000000000000000 > x22 =3D 0x0000000000000000 > x23 =3D 0x0000000000434000 sh..bss + 6336 > x24 =3D 0x0000000000434000 sh..bss + 6336 > x25 =3D 0x0000000040a36180 > x26 =3D 0x0000000000000003 > x27 =3D 0x0000000000434000 sh..bss + 6336 > x28 =3D 0x0000000040a50b18 > fp =3D 0x0000ffffffffe910 > lr =3D 0x0000000040554e18 libc.so.7`__raise + 64 at raise.c:52 > sp =3D 0x0000ffffffffe8f0 > pc =3D 0x0000000040554e54 libc.so.7`_thr_kill + 8 > cpsr =3D 0x80000000 The assembler code path between the fork call and the stack_check recall is shown as part of the below: 0x40f1c4 <+144>: bl 0x414040 ; flushall at = output.c:236 0x40f1c8 <+148>: bl 0x402920 ; symbol stub = for: fork 0x40f1cc <+152>: mov w19, w0 0x40f1d0 <+156>: cbz w19, 0x40f31c ; <+488> at = jobs.c:862 . . . 0x40f31c <+488>: adrp x8, 37 0x40f320 <+492>: adrp x9, 37 0x40f324 <+496>: ldr w22, [x8, #0xc08] 0x40f328 <+500>: str wzr, [x8, #0xc08] 0x40f32c <+504>: adrp x8, 37 0x40f330 <+508>: add x8, x8, #0xa00 ; =3D0xa00=20 0x40f334 <+512>: str x8, [x9, #0x978] 0x40f338 <+516>: bl 0x41192c ; stack_check at = miscbltin.c:70 0x40f33c <+520>: bl 0x40d684 ; closescript at = input.c:512 0x40f340 <+524>: bl 0x41192c ; stack_check at = miscbltin.c:70 (not much and not stack pointer manipulation). Based on: (lldb) print/x main_handler (jmploc) $42 =3D { loc =3D { [0] =3D { _jb =3D { [0] =3D 0x0000ffffffffd900fb5d25837d7ff700 [1] =3D 0x00000000000000030000ffffffffd9b0 [2] =3D 0x00000000004320380000000000434a00 [3] =3D 0x00000000000000000000000000000000 [4] =3D 0x00000000000000000000000000000000 [5] =3D 0x00000000000000000000000000000000 [6] =3D 0x0000000000410c740000ffffffffd950 . . . so that main's back-pointer to the prior frame is: 0x0000ffffffffd950 the high-address part of the (active) stack region looks in part like: 0xffffffffd990: 0x0000000000000000 0x0000000040434658 ld-elf.so.1`.rtld_start: 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 0x40434658 <+24>: mov x8, x0 0xffffffffd950: 0x0000ffffffffd990 0x0000000000402f30 sh`__start: 0x402f2c <+356>: bl 0x410c30 ; main at = main.c:97 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit 0xffffffffd8f0: 0x0000ffffffffd950 0x0000000000410ec4 sh`main: 0x410ec0 <+656>: bl 0x410f54 ; cmdloop at = main.c:199 0x410ec4 <+660>: adrp x8, 36 . . . 0xffffffffce90: 0x0000ffffffffcf40 0x0000000000405954 sh`evaltree: 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:840 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 (The 0x0000ffffffffcf40 was recorded by forkshell at 0xffffffffce90. The next frame-pointer/lr-value pair is shown later.) But looking around I found another area of the strings that had been replaced by stack contents in higher-addressed memory than just the obviously forkshell related frames that I've referenced in earlier notes. Showing both: . . . (strings) . . . 0xffffffffe1e0: 0x4c454b414d00792d 0x5400323d4c455645 0xffffffffe1f0: 0x5f4c4556454c504f 0x52554749464e4f43 0xffffffffe200: 0x454d554752415f45 0x7273752f3d53544e 0xffffffffe210: 0x726f702f6a626f2f 0x752f6b726f777374 0xffffffffe220: 0x7374726f702f7273 0x612f6c657665642f 0xffffffffe230: 0x6e2d343668637261 0x2d666c652d656e6f 0xffffffffe240: 0x6b726f772f636367 0x332e362d6363672f 0xffffffffe250: 0x69666e6f632f302e 0x742d2d2065727567 0xffffffffe260: 0x61613d7465677261 0x6f6e2d3436686372 0xffffffffe270: 0x2d20666c652d656e 0x656c62617369642d (frames below) 0xffffffffe280: 0x00000000404aed84 0x0000000000000001 0xffffffffe290: 0x0000ffffffffe590 0x0000000000000000 0xffffffffe2a0: 0x0000000000000000 0x0000000000000723 0xffffffffe2b0: 0x000000004044f800 0x0000ffffffffe370 0xffffffffe2c0: 0x0000ffffffffe360 0x0000000040438f70 0xffffffffe2d0: 0x000000004044f800 0x00000000000001c0 0xffffffffe2e0: 0x00000000404aed80 0x0000000000000000 0xffffffffe2f0: 0x0000ffff00000000 0x0000000040438f70 0xffffffffe300: 0x0000ffffffffe600 0x0000000000000000 0xffffffffe310: 0x0000000000000000 0x0000000000000000 0xffffffffe320: 0x0000000000000001 0x0000ffffffffe3e0 0xffffffffe330: 0x0000ffffffffe590 0x0000000000000000 0xffffffffe340: 0x0000000000000000 0x000000004044d180 0xffffffffe350: 0x0000ffffffffe4c0 0x0000ffffffffe3f0 0xffffffffe360: 0x0000ffffffffe3e0 0x000000004043c66c 0xffffffffe370: 0x00000000404bab29 0x0000000009d690dc 0xffffffffe380: 0x0000fffff2ee705a 0x000000004044e3c0 0xffffffffe390: 0x0000ffff00000001 0x000000004044f800 0xffffffffe3a0: 0x00000000404aed80 0x0000ffffffffe590 0xffffffffe3b0: 0x00000000404bab29 0x00000000404bab23 0xffffffffe3c0: 0x000000004044f800 0x0000ffffffffe7a8 0xffffffffe3d0: 0x0000ffffffffe4c0 0x0000ffffffffe4f0 0xffffffffe3e0: 0x0000ffffffffe450 0x000000004043c4b0 0xffffffffe3f0: 0x00000000404bab29 0x0000000009d690dc 0xffffffffe400: 0x00000000f2ee705a 0x000000004044e3c0 0xffffffffe410: 0x0000ffff00000001 0x000000004044f800 0xffffffffe420: 0x00000000404aed80 0x0000ffffffffe590 0xffffffffe430: 0x000000004044f800 0x0000ffffffffe7a8 0xffffffffe440: 0x000000004044f800 0x0000ffffffffe4f0 0xffffffffe450: 0x0000ffffffffe4e0 0x0000000040437440 0xffffffffe460: 0x0000000000000000 0x0000000000000000 0xffffffffe470: 0x0000000040a50b88 0x0000000000646573 0xffffffffe480: 0x0000000000000010 0x0000000040a50b68 0xffffffffe490: 0x8020080200000000 0x8020080280000000 0xffffffffe4a0: 0x8020080280200800 0x8020080200000000 0xffffffffe4b0: 0x0000000000000000 0x0000000000000000 0xffffffffe4c0: 0x0000000000000000 0x0000000000000000 0xffffffffe4d0: 0x8020080280200802 0x8020080280200802 0xffffffffe4e0: 0x0000ffffffffe570 0x00000000404bab29 0xffffffffe4f0: 0x000000004044d0e5 0x0000000040554e4c 0xffffffffe500: 0x000000004044d0e5 0x0000000000000000 0xffffffffe510: 0x0000008080808080 0xfefefefeff2f2d30 0xffffffffe520: 0x00000000404aed80 0x0000ffffffffe590 0xffffffffe530: 0x0000000000000003 0x0000000040a36180 0xffffffffe540: 0x0000000000434000 0x00000000001675e8 0xffffffffe550: 0x000000004049f000 0x0000ffffffffe590 0xffffffffe560: 0x00000000404ce9d0 0x0000000040554e4c 0xffffffffe570: 0x0000ffffffffe800 0x0000000040436edc 0xffffffffe580: 0x000000004049f000 0x0000ffffffffe5c0 0xffffffffe590: 0x0000000000000001 0x0000000040554dd8 0xffffffffe5a0: 0xfb5d25837d7ff700 0x0000ffffffffe580 0xffffffffe5b0: 0x000000004044f800 0x0000000000002a78 0xffffffffe5c0: 0x0000ffffffffe590 0x0000000000000000 0xffffffffe5d0: 0x0000000000434000 0x0000000000434000 0xffffffffe5e0: 0x0000000040a36180 0x0000000000000003 0xffffffffe5f0: 0x0000000000434000 0x000000004045b8c8 0xffffffffe600: 0x0000ffffffffe800 0x0000000040436de0 . . . (zeros) . . . 0xffffffffe6c0: 0x4b4d00646c697562 0x5f4c454e52454b5f 0xffffffffe6d0: 0x3d534c4f424d5953 0x52504e414d006f6e 0xffffffffe6e0: 0x73752f3d58494645 0x006c61636f6c2f72 . . . (strings) . . . 0xffffffffe730: 0x6f702f7273752f6b 0x657665642f737472 0xffffffffe740: 0x3668637261612f6c 0x652d656e6f6e2d34 0xffffffffe750: 0x772f6363672d666c 0x6975622e2f6b726f 0xffffffffe760: 0x006c746e692f646c 0x5550435f504d535f 0xffffffffe770: 0x425f4d5000343d53 0x3d474e49444c4955 0xffffffffe780: 0x69646c6975626d70 0x42006e69616d676e 0xffffffffe790: 0x4154534e495f4453 0x50495243535f4c4c 0xffffffffe7a0: 0x6c6174736e693d54 0x000000004044f800 (frames below again) 0xffffffffe7b0: 0x0000000040a50b18 0x0000000000434000 0xffffffffe7c0: 0x0000000000000003 0x0000000040a36180 0xffffffffe7d0: 0x0000000000434000 0x0000000000434000 0xffffffffe7e0: 0x0000000000000000 0x0000000000000000 0xffffffffe7f0: 0x0000000040a36180 0x0000000000000006 0xffffffffe800: 0x0000ffffffffe910 0x00000000404346b4 0xffffffffe810: 0x0000000000000000 0x0000000000000000 0xffffffffe820: 0x8020080280200802 0x8020080280200802 0xffffffffe830: 0x8020080280200800 0x8020080200000000 0xffffffffe840: 0x0000000000000000 0x0000000000000000 0xffffffffe850: 0x0000000000000010 0x0000000040a50b68 0xffffffffe860: 0x8020080200000000 0x8020080280000000 0xffffffffe870: 0x2f2f2f2f2f2f2f2f 0x2f2f2f2f2f2f2f2f 0xffffffffe880: 0x0000000040a50b88 0x0000000000646573 0xffffffffe890: 0x00000000000001b0 0x0000000000000000 0xffffffffe8a0: 0x0000000000646573 0x0000000000646573 0xffffffffe8b0: 0x0000000040a50b2c 0x0000000040a4f4f9 0xffffffffe8c0: 0x0000000000000000 0x0000000040573638 0xffffffffe8d0: 0x0000000000018730 0x0000000000000006 0xffffffffe8e0: 0x00000000406065e8 0x0000000040554e18 0xffffffffe8f0: 0x0000000000018730 0xeb61b0294df66bbd 0xffffffffe900: 0x0000ffffffffe92c 0x0000000000000000 0xffffffffe910: 0x0000ffffffffe950 0x0000000040554d8c 0xffffffffe920: 0x0000000040a50b2c 0xffffffdf40a4f4f9 0xffffffffe930: 0xffffffffffffffff 0x00000000ffffffff 0xffffffffe940: 0x0000000000000000 0x0000000000000000 0xffffffffe950: 0x0000ffffffffe970 0x0000000000411984 0xffffffffe960: 0x0000000000000000 0xeb61b0294df66bbd 0xffffffffe970: 0x0000ffffffffce90 0x000000000040f33c (back to strings below) 0xffffffffe980: 0x4c45444145520078 0x41545f524f465f46 0xffffffffe990: 0x73752f3d54454752 0x2f6c61636f6c2f72 0xffffffffe9a0: 0x2d34366863726161 0x666c652d656e6f6e 0xffffffffe9b0: 0x6165722f6e69622f 0x534f4800666c6564 0xffffffffe9c0: 0x003d5342494c5f54 0x455341434c415544 0xffffffffe9d0: 0x49505f4f4e00313d 0x5250007365793d45 0xffffffffe9e0: 0x73752f3d58494645 0x006c61636f6c2f72 The frames from this higher-address area are: (strings at higher addresses near by) 0xffffffffe970: 0x0000ffffffffce90 0x000000000040f33c sh`forkshell: 0x40f338 <+516>: bl 0x41192c ; stack_check at = miscbltin.c:70 0x40f33c <+520>: bl 0x40d684 ; closescript at = input.c:512 0x40f340 <+524>: bl 0x41192c ; stack_check at = miscbltin.c:70 (The 0x0000ffffffffce90 was recorded by stack_check but at 0xffffffffe970: sp is out of the active stack region here [bad value].) 0xffffffffe950: 0x0000ffffffffe970 0x0000000000411984 sh`stack_check: 0x411980 <+84>: bl 0x402770 ; symbol stub for: = abort 0x411984 <+88>: bl 0x402bc0 ; symbol stub for: = __stack_chk_fail 0xffffffffe910: 0x0000ffffffffe950 0x0000000040554d8c libc.so.7`abort: 0x40554d88 <+80>: bl 0x332c0 ; symbol stub = for: acl_init 0x40554d8c <+84>: mov x0, x19 0xffffffffe800: 0x0000ffffffffe910 0x00000000404346b4 ld-elf.so.1`_rtld_bind_start: 0x404346b0 <+64>: bl 0x4d90 ; _rtld_bind at = rtld.c:710 0x404346b4 <+68>: ldp xzr, x30, [sp, #0xd0] (There were strings between above and below.) 0xffffffffe600: 0x0000ffffffffe800 0x0000000040436de0 (lldb) dis -s -4*4+0x0000000040436de0 ld-elf.so.1`_rtld_bind: 0x40436ddc <+76>: bl 0x106d8 ; sigsetjmp 0x40436de0 <+80>: cbz w0, 0x4df0 ; <+96> at = rtld.c:721 (Nothing links back to 0xffffffffe600, as expected for sigsetjmp without a matching siglongjmp.) 0xffffffffe570: 0x0000ffffffffe800 0x0000000040436edc ld-elf.so.1`_rtld_bind: 0x40436ed8 <+328>: bl 0xaf68 ; lock_release = at rtld_lock.c:228 0x40436edc <+332>: mov x0, x19 0xffffffffe4e0: 0x0000ffffffffe570 0x00000000404bab29 (0x00000000404bab29 is an odd value; address range around it seems to not be code based on lldb dis output. Aslo the core file does not contain 0xaf68 from the above.) 0xffffffffe450: 0x0000ffffffffe4e0 0x0000000040437440 ld-elf.so.1`symlook_default: 0x4043743c <+172>: bl 0xa434 ; symlook_global = at rtld.c:3906 0x40437440 <+176>: ldr x20, [x20, #0x258] 0xffffffffe3e0: 0x0000ffffffffe450 0x000000004043c4b0 ld-elf.so.1`symlook_global: 0x4043c4ac <+120>: bl 0xa5bc ; symlook_list = at rtld.c:4005 0x4043c4b0 <+124>: cbnz w0, 0xa4e4 ; <+176> at = rtld.c:3926 0xffffffffe360: 0x0000ffffffffe3e0 0x000000004043c66c ld-elf.so.1`symlook_list: 0x4043c668 <+172>: bl 0x6e44 ; symlook_obj at = rtld.c:4083 0x4043c66c <+176>: cbnz w0, 0xa698 ; <+220> at = rtld.c:4014 0xffffffffe2c0: 0x0000ffffffffe360 0x0000000040438f70 ld-elf.so.1`symlook_obj: 0x40438f6c <+296>: bl 0xa6cc ; matched_symbol = at rtld.c:4132 0x40438f70 <+300>: and w8, w0, #0xff (More strings at nearby smaller addresses.) Example strings (increasing addresses) in the area with out-of-place stack frames: . . . (more strings) . . . (lldb) print (char*)0xffffffffe1e3 (char *) $20 =3D 0x0000ffffffffe1e3 "MAKELEVEL=3D2" (lldb) print (char*)0xffffffffe1ef (char *) $22 =3D 0x0000ffffffffe1ef = "TOPLEVEL_CONFIGURE_ARGUMENTS=3D/usr/obj/portswork/usr/ports/devel/aarch64= -none-elf-gcc/work/gcc-6.3.0/configure --target=3Daarch64-none-elf = --disable\x84\xedJ@" . . . (stack frames then some zeros) . . . (lldb) print (char*)0xffffffffe6c0 (char *) $13 =3D 0x0000ffffffffe6c0 "build" (lldb) print (char*)0xffffffffe6c6 (char *) $19 =3D 0x0000ffffffffe6c6 "MK_KERNEL_SYMBOLS=3Dno" . . . (more strings) . . . (lldb) print (char*)0xffffffffe774 (char *) $39 =3D 0x0000ffffffffe774 "PM_BUILDING=3Dpmbuildingmain" (lldb) print (char*)0xffffffffe78f (char *) $40 =3D 0x0000ffffffffe78f "BSD_INSTALL_SCRIPT=3Dinstal" . . . (stack frames) . . . (lldb) print (char*)0xffffffffe982 (char *) $57 =3D 0x0000ffffffffe982 = "READELF_FOR_TARGET=3D/usr/local/aarch64-none-elf/bin/readelf" (lldb) print (char*)0xffffffffe9bd (char *) $58 =3D 0x0000ffffffffe9bd "HOST_LIBS=3D" . . . (more strings) . . . The big sp jump in: 0xffffffffe970: 0x0000ffffffffce90 0x000000000040f33c leaves some history showing. . . 0xffffffffce40: 0x0000ffffffffce90 0x000000000040f1c8 sh`forkshell: 0x40f1c4 <+144>: bl 0x414040 ; flushall at = output.c:236 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork 0x40f1cc <+152>: mov w19, w0 shows that flushall's recording is before the odd sp value shows up. =3D=3D=3D Mark Millard markmi at dsl-only.net > On 2017-Feb-8, at 8:53 PM, Mark Millard = wrote: >=20 >> Another sh core, this one with non-zero "junk" around >> the sp at the core-dump gives new information. The "junk" >> is because the SP actually ends up in higher addressed >> memory than the base frame (when .rtld_start does >> "bl _rtld"). [Some sh core dumps have different sp >> relationships than this but this can and does >> happen.] >>=20 >> With the below additional evidence I conclude that >> either the stack pointer was messed up when fork >> returned for the child path or shortly there after >> (while sh's forkshell routine was still active). >>=20 >>=20 >>=20 >>=20 >>=20 >> Supporting details: >>=20 >> General Purpose Registers: >> . . . >> sp =3D 0x0000ffffffffe600 >>=20 >> The sp =3D 0x0000ffffffffe600 is rather high in memory, >> in fact outside the stack for what ld-elf.so.1`.rtld_start >> calls. . . >>=20 >> 0xffffffffd5b0: 0x0000ffffffffd5f0 0x0000000000402f30 >> 0xffffffffd5c0: 0x0000000000000000 0x0000000000000000 >> 0xffffffffd5d0: 0x0000000000000000 0x0000000000000000 >> 0xffffffffd5e0: 0x0000ffffffffd600 0x0000ffffffffd600 >> 0xffffffffd5f0: 0x0000000000000000 0x0000000040434658 >>=20 >> (Note: 0x0000ffffffffe600-0x1000=3D=3D0xffffffffd5f0+0x10 >> but other core files have widely varying distances.) >>=20 >> For that last line: >>=20 >> 0xffffffffd5f0: 0x0000000000000000 0x0000000040434658 >> (lldb) dis -s -4*4+0x0000000040434658 >> ld-elf.so.1`.rtld_start: >> 0x40434648 <+8>: sub sp, sp, #0x10 ; =3D0x10=20 >> 0x4043464c <+12>: mov x1, sp >> 0x40434650 <+16>: add x2, x1, #0x8 ; =3D0x8=20 >> 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 >> 0x40434658 <+24>: mov x8, x0 >>=20 >> (0x2e4c is not in the core file.) >>=20 >> and for the other frame-pointer/lr-value pair: >>=20 >> 0xffffffffd5b0: 0x0000ffffffffd5f0 0x0000000000402f30 >> (lldb) dis -s -4*4+0x0000000000402f30 >> sh`__start: >> 0x402f20 <+344>: mov w0, w21 >> 0x402f24 <+348>: mov x1, x20 >> 0x402f28 <+352>: mov x2, x19 >> 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 >> 0x402f30 <+360>: bl 0x402ae0 ; symbol stub = for: exit >>=20 >> Note: Anything higher addressed in memory than that=20 >> 0xffffffffd5ff I'll say is "higher than the stack >> region" or some such phrase. >>=20 >> Yet despite being higher than the stack region >> there are some stack frames also near by (also >> higher than the stack region). . . >>=20 >> An area around the sp =3D 0x0000ffffffffe600 that lldb >> reported for this core (with some notes used later): >>=20 >> . . . >> 0xffffffffe400: 0x6572662d6e776f6e 0x302e323164736265 >> 0xffffffffe410: 0x56454c454b414d00 0x42494c00323d4c45 >> 0xffffffffe420: 0x403d434e49464c45 0x6e69666c6562696c >> 0xffffffffe430: 0x4f465f444c004063 0x5445475241545f52 >> 0xffffffffe440: 0x6f6c2f7273752f3d 0x637261612f6c6163 >> 0xffffffffe450: 0x656e6f6e2d343668 0x6e69622f666c652d >> 0xffffffffe460: 0x3d62647000646c2f 0x2f62642f7261762f >> 0xffffffffe470: 0x74726f7000676b70 0x2f3d72696462645f >> 0xffffffffe480: 0x702f62642f726176 0x5f4d50007374726f >> 0xffffffffe490: 0x505f544e45524150 0x657665643d54524f >> 0xffffffffe4a0: 0x3668637261612f6c 0x652d656e6f6e2d34 >> 0xffffffffe4b0: 0x43006363672d666c 0x5243530063633d43 >> 0xffffffffe4c0: 0x6f6f722f3d545049 0x5f7374726f702f74 >> 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) >> 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 (beginning of = what looks like stack frames) >> 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 >> 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 >> 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 >> 0xffffffffe520: 0x0000000000000000 0x0000000000000000 >> 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 >> 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe550: 0x0000000000434000 0x000000000000000f >> 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 >> 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e >> 0xffffffffe580: 0x0000000000000001 0x0000000000000005 >> 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) >> 0xffffffffe5b0: 0x54494445003d4854 0x41500069763d524f x26, x25 values = (see below) >> 0xffffffffe5c0: 0x2f3d534547414b43 0x74726f702f727375 x24, x23 values = (see below) >> 0xffffffffe5d0: 0x67616b6361702f73 0x414c46444c007365 x22, x21 values = (see below) >> 0xffffffffe5e0: 0x58584300203d5347 0x662d3d5347414c46 x20, x19 values = (see below) >> 0xffffffffe5f0: 0x2d74656b63617262 0x31353d6874706564 fp, lr values = (see below); pc=3D=3Dlr eventually. >> 0xffffffffe600: 0x346d673d344d0032 0x73752f3d564e4500 >> 0xffffffffe610: 0x6d2f656d6f682f72 0x732e2f696d6b7261 >> 0xffffffffe620: 0x2f3d647000637268 0x74726f702f727375 >> 0xffffffffe630: 0x4441524750550073 0x703d4c4f4f545f45 >> 0xffffffffe640: 0x657473616d74726f 0x5254524f46470072 >> 0xffffffffe650: 0x4552534f003d4e41 0x4f00302e32313d4c >> 0xffffffffe660: 0x752f3d445750444c 0x702f6a626f2f7273 >> . . . >>=20 >> So at this point we have that the stack pointer was >> messed up somewhat prior to the core-dump. >>=20 >> x19-x26 in the below are from the locations indicated >> to the side above: >>=20 >> General Purpose Registers: >> x0 =3D 0x0000000000000000 >> x1 =3D 0x0000000000000000 >> x2 =3D 0x0000000000000000 >> x3 =3D 0x00000000405735c8 libc.so.7`__sys_sigaction >> x4 =3D 0x0000000000000090 >> x5 =3D 0x2080002000200000 >> x6 =3D 0x0000000000434c28 sh..bss + 9448 >> x7 =3D 0x00000000000c590d >> x8 =3D 0x0000000000000000 >> x9 =3D 0x0000000000000000 >> x10 =3D 0x0000000000434000 sh..bss + 6336 >> x11 =3D 0x0000000000000000 >> x12 =3D 0x0000000000434c38 sh..bss + 9464 >> x13 =3D 0x0000000000000001 >> x14 =3D 0x0000000000000063 >> x15 =3D 0x0000000000000010 >> x16 =3D 0x0000000000432280 =20 >> x17 =3D 0x0000000040573554 libc.so.7`sigaction at = sigaction.c:49 >> x18 =3D 0x0000000000000000 >> x19 =3D 0x662d3d5347414c46 >> x20 =3D 0x58584300203d5347 >> x21 =3D 0x414c46444c007365 >> x22 =3D 0x67616b6361702f73 >> x23 =3D 0x74726f702f727375 >> x24 =3D 0x2f3d534547414b43 >> x25 =3D 0x41500069763d524f >> x26 =3D 0x54494445003d4854 >> x27 =3D 0x0000ffffffffc658 >> x28 =3D 0x0000000000000000 >> fp =3D 0x2d74656b63617262 >> lr =3D 0x31353d6874706564 >> sp =3D 0x0000ffffffffe600 >> pc =3D 0x31353d6874706564 >> cpsr =3D 0x20000000 >>=20 >> Note the: >>=20 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >>=20 >> is somewhat before 0x0000ffffffffe600. It looks to be >> a frame-pointer/lr-value pair. (And the 0x0000ffffffffc5c0 >> does point to a frame-pointer/lr-value pair that is >> part of a coherent chain of them inside the stack region.) >>=20 >> It seems likely that despite the long distance >> framepointer reference in the fp/lr value pair: >>=20 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >>=20 >> that sp =3D 0x0000ffffffffe600 was the result of an >> increment by a small fixed amount from an sp near >> 0xffffffffe5a0, such as by code like the following >> when forkshell tries to return: >>=20 >> sh`forkshell: >> 0x40f520 <+1004>: ldp x29, x30, [sp, #0x40] >> 0x40f524 <+1008>: ldp x20, x19, [sp, #0x30] >> 0x40f528 <+1012>: ldp x22, x21, [sp, #0x20] >> 0x40f52c <+1016>: ldp x24, x23, [sp, #0x10] >> 0x40f530 <+1020>: ldp x26, x25, [sp], #0x50 >> 0x40f534 <+1024>: ret =20 >>=20 >> So the prior is sp=3D0xffffffffe5b0 for the above code. >> Also note that for SP=3D0xffffffffe5b0 initially that >> code would fill in x19-x26 as they were actually >> filled in: solid evidence of the sp that exit code >> started with. >>=20 >> Note that forkshell had started with: >>=20 >> sh`forkshell: >> 0x40f134 <+0>: stp x26, x25, [sp, #-0x50]! >> 0x40f138 <+4>: stp x24, x23, [sp, #0x10] >> 0x40f13c <+8>: stp x22, x21, [sp, #0x20] >> 0x40f140 <+12>: stp x20, x19, [sp, #0x30] >> 0x40f144 <+16>: stp x29, x30, [sp, #0x40] >> 0x40f148 <+20>: add x29, sp, #0x40 ; =3D0x40=20 >>=20 >> And that indicates that sp had a big change after: >>=20 >> 0x40f148 <+20>: add x29, sp, #0x40 ; =3D0x40=20 >>=20 >> in order for x29=3D0x0000ffffffffc5c0 to have later >> been written out as it was at 0xffffffffe5a0. >>=20 >> But by the freejob call (that is in forkshell's child >> process path) that is indicated by the below the >> sp had changed to be higher than the stack region: >>=20 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >> (lldb) dis -s -4*4+0x000000000040f490 >> sh`forkshell: >> 0x40f480 <+844>: ldrb w8, [x20, #0x21] >> 0x40f484 <+848>: cbz w8, 0x40f490 ; <+860> at = jobs.c:907 >> 0x40f488 <+852>: mov x0, x20 >> 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 >> 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 >> . . . >>=20 >> where freejob started with: >>=20 >> (lldb) dis -s freejob >> sh`freejob: >> 0x40e65c <+0>: str x23, [sp, #-0x40]! >> 0x40e660 <+4>: stp x22, x21, [sp, #0x10] >> 0x40e664 <+8>: stp x20, x19, [sp, #0x20] >> 0x40e668 <+12>: stp x29, x30, [sp, #0x30] >> 0x40e66c <+16>: add x29, sp, #0x30 ; =3D0x30=20 >> . . . >>=20 >> and the contained: >>=20 >> 0x40e668 <+12>: stp x29, x30, [sp, #0x30] >>=20 >> wrote the frame-pointer/lr-value pair: >>=20 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >>=20 >> after freejob was called. freejob returns with: >>=20 >> (lldb) dis -s freejob -c 128 >> sh`freejob: >> . . . >> 0x40e748 <+236>: ldp x29, x30, [sp, #0x30] >> 0x40e74c <+240>: ldp x20, x19, [sp, #0x20] >> 0x40e750 <+244>: ldp x22, x21, [sp, #0x10] >> 0x40e754 <+248>: ldr x23, [sp], #0x40 >> 0x40e758 <+252>: ret =20 >> . . . >>=20 >> The lr-value from: >>=20 >> 0xffffffffc5c0: 0x0000ffffffffc8f0 0x0000000000406648 >>=20 >> refers to: >>=20 >> sh`evalcommand: >> 0x406644 <+2012>: bl 0x40f134 ; forkshell at = jobs.c:838 >> 0x406648 <+2016>: cbz w0, 0x40666c ; <+2052> at = eval.c:1175 >>=20 >> as expected. This is in the stack region. >>=20 >> There is evidence of the following frame-pointer/lr-value >> pair still in the stack-region from just before the fork but >> while forkshell was active and before the big change in >> sp value: >>=20 >> 0xffffffffc570: 0x0000ffffffffc5c0 0x000000000040f1c8 >> sh`forkshell: >> 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 >> 0x40f1c8 <+148>: bl 0x402920 ; symbol stub = for: fork >>=20 >> The parent process did not crash and so there is no evdence >> that its sp value was ever wrong. So going into fork >> things seem to have been okay. >>=20 >> So far it does not appear to me that there is information >> left for inside or after the fork but before the freejob call >> on the child process path. So the fork itself might have >> returned with the wrong sp value or the problem might have >> occurred a little later. >>=20 >> As far as the bad sp values in this example core file. . . >>=20 >> The content of what I've historically called "junk" >> areas that are actually outside the stack region are >> interesting: >>=20 >> . . . >> 0xffffffffe400: 0x6572662d6e776f6e 0x302e323164736265 >> 0xffffffffe410: 0x56454c454b414d00 0x42494c00323d4c45 >> 0xffffffffe420: 0x403d434e49464c45 0x6e69666c6562696c >> 0xffffffffe430: 0x4f465f444c004063 0x5445475241545f52 >> 0xffffffffe440: 0x6f6c2f7273752f3d 0x637261612f6c6163 >> 0xffffffffe450: 0x656e6f6e2d343668 0x6e69622f666c652d >> 0xffffffffe460: 0x3d62647000646c2f 0x2f62642f7261762f >> 0xffffffffe470: 0x74726f7000676b70 0x2f3d72696462645f >> 0xffffffffe480: 0x702f62642f726176 0x5f4d50007374726f >> 0xffffffffe490: 0x505f544e45524150 0x657665643d54524f >> 0xffffffffe4a0: 0x3668637261612f6c 0x652d656e6f6e2d34 >> 0xffffffffe4b0: 0x43006363672d666c 0x5243530063633d43 >> 0xffffffffe4c0: 0x6f6f722f3d545049 0x5f7374726f702f74 >> 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) >>=20 >> In other words ('\0' terminated strings): >>=20 >> . . . >> (lldb) print (char*)0xffffffffe400 >> (char *) $67 =3D 0x0000ffffffffe400 "nown-freebsd12.0" >> (lldb) print (char*)0xffffffffe411 >> (char *) $66 =3D 0x0000ffffffffe411 "MAKELEVEL=3D2" >> (lldb) print (char*)0xffffffffe433 >> (char *) $68 =3D 0x0000ffffffffe433 = "LD_FOR_TARGET=3D/usr/local/aarch64-none-elf/bin/ld" >> (lldb) print (char*)0xffffffffe464 >> (char *) $69 =3D 0x0000ffffffffe464 "pdb=3D/var/db/pkg" >> (lldb) print (char*)0xffffffffe474 >> (char *) $71 =3D 0x0000ffffffffe474 "port_dbdir=3D/var/db/ports" >> (lldb) print (char*)0xffffffffe48d >> (char *) $60 =3D 0x0000ffffffffe48d = "PM_PARENT_PORT=3Ddevel/aarch64-none-elf-gcc" >> (lldb) print (char*)0xffffffffe4b7 >> (char *) $29 =3D 0x0000ffffffffe4b7 "CC=3Dcc" >> (lldb) print (char*)0xffffffffe4bd >> (char *) $30 =3D 0x0000ffffffffe4bd "SCRIPT=3D/root/ports_x" >>=20 >> As for: >>=20 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) >> 0xffffffffe5b0: 0x54494445003d4854 0x41500069763d524f x26, x25 values = (see below) >> 0xffffffffe5c0: 0x2f3d534547414b43 0x74726f702f727375 x24, x23 values = (see below) >> 0xffffffffe5d0: 0x67616b6361702f73 0x414c46444c007365 x22, x21 values = (see below) >> 0xffffffffe5e0: 0x58584300203d5347 0x662d3d5347414c46 x20, x19 values = (see below) >> 0xffffffffe5f0: 0x2d74656b63617262 0x31353d6874706564 fp, lr values = (see below); pc=3D=3Dlr as well. >> 0xffffffffe600: 0x346d673d344d0032 0x73752f3d564e4500 >> 0xffffffffe610: 0x6d2f656d6f682f72 0x732e2f696d6b7261 >> 0xffffffffe620: 0x2f3d647000637268 0x74726f702f727375 >> 0xffffffffe630: 0x4441524750550073 0x703d4c4f4f545f45 >> 0xffffffffe640: 0x657473616d74726f 0x5254524f46470072 >> 0xffffffffe650: 0x4552534f003d4e41 0x4f00302e32313d4c >> 0xffffffffe660: 0x752f3d445750444c 0x702f6a626f2f7273 >> . . . >>=20 >> In other words: >>=20 >> (lldb) print (char*)0xffffffffe5b0 >> (char *) $72 =3D 0x0000ffffffffe5b0 "TH=3D" >> (The above is likely missing its beginning, having been replaced >> by the frame-popinter/lr-value pair.) >> (lldb) print (char*)0xffffffffe5be >> (char *) $73 =3D 0x0000ffffffffe5be "PACKAGES=3D/usr/ports/packages" >> (lldb) print (char*)0xffffffffe5db >> (char *) $74 =3D 0x0000ffffffffe5db "LDFLAGS=3D " >> (lldb) print (char*)0xffffffffe5e5 >> (char *) $75 =3D 0x0000ffffffffe5e5 "CXXFLAGS=3D-fbracket-depth=3D512" >> (lldb) print (char*)0xffffffffe602 >> (char *) $76 =3D 0x0000ffffffffe602 "M4=3Dgm4" >> (lldb) print (char*)0xffffffffe624 >> (char *) $77 =3D 0x0000ffffffffe624 "pd=3D/usr/ports" >> (lldb) print (char*)0xffffffffe632 >> (char *) $79 =3D 0x0000ffffffffe632 "UPGRADE_TOOL=3Dportmaster" >> (lldb) print (char*)0xffffffffe64a >> (char *) $81 =3D 0x0000ffffffffe64a "GFORTRAN=3D" >> (lldb) print (char*)0xffffffffe654 >> (char *) $82 =3D 0x0000ffffffffe654 "OSREL=3D12.0" >> (lldb) print (char*)0xffffffffe65f >> (char *) $83 =3D 0x0000ffffffffe65f = "OLDPWD=3D/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/.bu= ild" >> . . . >>=20 >> So the middle range with the stack frames: >>=20 >> 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 ("junk" (text) = temporarily stops here) >> 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 >> 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 >> 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 >> 0xffffffffe520: 0x0000000000000000 0x0000000000000000 >> 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 >> 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 >> 0xffffffffe550: 0x0000000000434000 0x000000000000000f >> 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 >> 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e >> 0xffffffffe580: 0x0000000000000001 0x0000000000000005 >> 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 >> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 ("junk" (text) = starts again after this line) >>=20 >> has stomped on strings that are outside the stack >> region. (The stack frames are the actual junk.) >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > On 2017-Feb-7, at 2:44 AM, Mark Millard = wrote: >=20 >> Another core. The register read reported: >>=20 >> fp =3D 0x0000000000000000 >> lr =3D 0x0000000000000000 >> sp =3D 0x0000fffffffee630 >> pc =3D 0x0000000000000000 >>=20 >> And looking around (most nested to outer most): >>=20 >> 0xfffffffee530: 0x0000fffffffee570 0x000000004054cd94 >> libc.so.7`__free: >> 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 >> 0x4054cd94 <+148>: adrp x9, 185 >> 0xfffffffee570: 0x0000fffffffee590 0x0000000000411300 >> sh`ckfree: >> 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free >> 0x411300 <+32>: ldr x8, [x19, #0x970] >> 0xfffffffee590: 0x0000fffffffee5d0 0x000000000040e6e8 >> sh`freejob: >> 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 >> 0x40e6e8 <+140>: adrp x8, 38 >> 0xfffffffee5d0: 0x0000ffffffffcaa0 0x000000000040f490 >> sh`forkshell: >> 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 >> 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30 >> (Note that sp=3D=3D0x0000fffffffee630 is fairly close to = 0xfffffffee5d0.) >>=20 >> (sizable frame jump from 0xfffffffee5d0 to 0x0000ffffffffcaa0, size = 0xE4D0=3D=3D58576 bytes) >> (0xfffffffee5e0 up to 0xffffffffa890 (not inclusive) are all = 0x0000000000000000) >> (The prior trace example did not have such a large area.) >>=20 >> 0xffffffffca50: 0x0000ffffffffcaa0 0x000000000040f1c8 >> sh`forkshell: >> 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 >> 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork >> 0x40f1cc <+152>: mov w19, w0 >> (flushall a voids returning to 0x40f1c8 directly, instead making >> the last routine it calls return there instead of to flushall.) >>=20 >> 0xffffffffcaa0: 0x0000ffffffffcb50 0x0000000000405954 >> sh`evaltree: >> 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 >> 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 >> 0xffffffffcb50: 0x0000ffffffffcde0 0x0000000000406e28 >> sh`evalbackcmd: >> 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 >> 0x406e28 <+340>: ldur w0, [x29, #-0x5c] >> 0xffffffffcde0: 0x0000ffffffffcf90 0x0000000000409324 >> sh`argstr: >> 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 >> 0x409324 <+432>: mov x0, x26 >> 0xffffffffcf90: 0x0000ffffffffcff0 0x0000000000408fa8 >> sh`expandarg: >> 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 >> 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 >> 0xffffffffcff0: 0x0000ffffffffd320 0x0000000000405f48 >> sh`evalcommand: >> 0x405f44 <+220>: bl 0x408f38 ; expandarg at = expand.c:225 >> 0x405f48 <+224>: ldr x24, [x24, #0x8] >>=20 >> 0xffffffffd0f0: 0x0000ffffffffd320 0x00000000004068e4 >> sh`evalcommand: >> 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub = for: _setjmp >> 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 >>=20 >> 0xffffffffd320: 0x0000ffffffffd3d0 0x0000000000405570 >> sh`evaltree: >> 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 >> 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 >> 0x405574 <+216>: ldr x8, [x24, #0x8] >> 0xffffffffd3d0: 0x0000ffffffffd480 0x0000000000405550 >> sh`cmdloop: >> 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 >> 0x411034 <+252>: mov w27, wzr >> 0xffffffffd480: 0x0000ffffffffd7b0 0x00000000004067d0 >> sh`evalcommand: >> 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 >> 0x4067d0 <+2408>: ldr x8, [x24, #0x970] >> 0xffffffffd7b0: 0x0000ffffffffd860 0x0000000000405570 >> sh`evaltree: >> 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 >> 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 >> 0x405574 <+216>: ldr x8, [x24, #0x8] >> 0xffffffffd860: 0x0000ffffffffd910 0x0000000000405550 >> sh`evaltree: >> 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 >> 0x405550 <+180>: ldr w8, [x22, #0x994] >> 0xffffffffd910: 0x0000ffffffffdc40 0x00000000004067d0 >> sh`evalcommand: >> 0x4067cc <+2404>: bl 0x40549c ; evaltree at = eval.c:193 >> 0x4067d0 <+2408>: ldr x8, [x24, #0x970] >>=20 >> 0xffffffffda10: 0x0000ffffffffdc40 0x000000000040673c >> sh`evalcommand: >> 0x406738 <+2256>: bl 0x402be0 ; symbol stub = for: _setjmp >> 0x40673c <+2260>: cbnz w0, 0x406c60 ; <+3576> at = eval.c:1042 >>=20 >> 0xffffffffdc40: 0x0000ffffffffdcf0 0x0000000000405570 >> sh`evaltree: >> 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 >> 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 >> 0x405574 <+216>: ldr x8, [x24, #0x8] >> 0xffffffffdcf0: 0x0000ffffffffdd70 0x0000000000411034 >> sh`cmdloop: >> 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 >> 0x411034 <+252>: mov w27, wzr >> 0xffffffffdd70: 0x0000ffffffffddd0 0x0000000000410ea8 >> sh`main: >> 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 >> 0x410ea8 <+660>: adrp x8, 36 >> 0xffffffffddd0: 0x0000ffffffffde10 0x0000000000402f30 >> sh`__start: >> 0x402f2c <+356>: bl 0x410c14 ; main at = main.c:97 >> 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit >>=20 >> (_rtld is not in the core file) >> 0xffffffffde10: 0x0000000000000000 0x0000000040434658 >> ld-elf.so.1`.rtld_start: >> 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 >> 0x40434658 <+24>: mov x8, x0 >>=20 >> So again the problem is associated with the forkshell/fork/freejob >> related materials. >>=20 >> (I mistakenly left out the evalcommand/_setjmp material >> when I made the trace in the below. The same for flushall. >> I've inserted some of that below, at least for >> the flushall context.) >=20 > On 2017-Feb-6, at 8:05 PM, Mark Millard wrote: >=20 >> [I got a lucky sh core dump with more stack context/content >> available to look at for an example sh crash. This helps >> narrow things down.] >>=20 >> On 2017-Feb-5, at 1:12 AM, Mark Millard = wrote: >>=20 >>> [Top post of a new result.] >>>=20 >>> Using lldb to look at the memory for the stack around >>> sh failure points has some apparently fixed structure. >>> Example: >>>=20 >>> . . . junk values . . . >>> 0xffffffffe4d0: 0x0000000000000078 0x637261612f737470 >>> 0xffffffffe4e0: 0x00000000004345c8 0x0000000000434000 >>> 0xffffffffe4f0: 0x0000000000434000 0x0000000040a903e0 >>> 0xffffffffe500: 0x0000ffffffffe540 0x000000004054cd94 >>> 0xffffffffe510: 0x696d6b72616d2f6c 0x0000000000000000 >>> 0xffffffffe520: 0x0000000000000000 0x0000000000000000 >>> 0xffffffffe530: 0x0000000000000000 0xe8021690dc1f70b8 >>> 0xffffffffe540: 0x00000000004345c8 0x0000000000434000 >>> 0xffffffffe550: 0x0000000000434000 0x000000000000000f >>> 0xffffffffe560: 0x0000ffffffffe5a0 0x000000000041aef0 >>> 0xffffffffe570: 0x0000000000434c38 0x732f7273752f3a6e >>> 0xffffffffe580: 0x0000000000000001 0x0000000000000005 >>> 0xffffffffe590: 0x0000000040a33180 0x0000000000000000 >>> 0xffffffffe5a0: 0x0000ffffffffc5c0 0x000000000040f490 >>> . . . junk values . . . >>=20 >> I got lucky and got a core dump that did not have the junk >> areas and could trace the stack's frame pointer chain >> between main and libc.so.7`__free (through freejob along >> the way). See later. >>=20 >>> where "register read" showed: >>>=20 >>> sp =3D 0x0000ffffffffe600 >>>=20 >>> (The distance and direction to the last non-junk line >>> from the reported sp in each example is the same.) >>> Looking around that 0x000000000040f490: >>>=20 >>> 0x40f48c: 0x97fffc74 bl 0x40e65c ; freejob at = jobs.c:463 >>> 0x40f490: 0x9100c294 add x20, x20, #0x30 ; =3D0x30=20 >>>=20 >>> It is the same address and code in each case. >>=20 >> I should have originally noted that 0x40f48c is in >> forkshell, along the child process code-path: >>=20 >> pid_t >> forkshell(struct job *jp, union node *n, int mode) >> { >> . . . (see /usr/src/bin/sh/jobs.c for this) . . . >> INTOFF; >> if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) >> checkzombies(); >> flushall(); >> pid =3D fork(); >> if (pid =3D=3D -1) { >> TRACE(("Fork failed, errno=3D%d\n", errno)); >> INTON; >> error("Cannot fork: %s", strerror(errno)); >> } >> if (pid =3D=3D 0) { >> struct job *p; >> int wasroot; >> int i; >>=20 >> TRACE(("Child shell %d\n", (int)getpid())); >> wasroot =3D rootshell; >> rootshell =3D 0; >> handler =3D &main_handler; >> closescript(); >> INTON; >> forcelocal =3D 0; >> clear_traps(); >> #if JOBS >> . . . (see /usr/src/bin/sh/jobs.c for this) . . . >> #else >> . . . (see /usr/src/bin/sh/jobs.c for this) . . . >> #endif >> INTOFF; >> for (i =3D njobs, p =3D jobtab ; --i >=3D 0 ; p++) >> if (p->used) >> freejob(p); >> INTON; >> if (wasroot && iflag) { >> setsignal(SIGINT); >> setsignal(SIGQUIT); >> setsignal(SIGTERM); >> } >> return pid; >> } >> . . . (see /usr/src/bin/sh/jobs.c for this) . . . >>=20 >>> Sometimes the junk values are all zeros over sizable >>> distances. Sometimes the sizable areas seem to have >>> random data. >>>=20 >>> /usr/src/bin/sh/jobs.c 's freejobs is: >>>=20 >>> static void >>> freejob(struct job *jp) >>> { >>> struct procstat *ps; >>> int i; >>>=20 >>> INTOFF; >>> if (bgjob =3D=3D jp) >>> bgjob =3D NULL; >>> for (i =3D jp->nprocs, ps =3D jp->ps ; --i >=3D 0 ; ps++) { >>> if (ps->cmd !=3D nullstr) >>> ckfree(ps->cmd); >>> } >>> if (jp->ps !=3D &jp->ps0) >>> ckfree(jp->ps); >>> jp->used =3D 0; >>> #if JOBS >>> deljob(jp); >>> #endif >>> INTON; >>> } >>>=20 >>> /usr/src/bin/sh/error.h defines INTOFF and INTON: >>>=20 >>> #define EXINT 0 /* SIGINT received */ >>> #define EXERROR 1 /* a generic error */ >>> #define EXEXEC 2 /* command execution failed */ >>> #define EXEXIT 3 /* call exitshell(exitstatus) */ >>>=20 >>> . . . >>>=20 >>> extern struct jmploc *handler; >>> extern volatile sig_atomic_t exception; >>>=20 >>> . . . >>>=20 >>> extern volatile sig_atomic_t suppressint; >>> extern volatile sig_atomic_t intpending; >>>=20 >>> #define INTOFF suppressint++ >>> #define INTON { if (--suppressint =3D=3D 0 && intpending) onint(); } >>> #define is_int_on() suppressint >>> #define SETINTON(s) suppressint =3D (s) >>> #define FORCEINTON {suppressint =3D 0; if (intpending) onint();} >>> #define SET_PENDING_INT intpending =3D 1 >>> #define CLEAR_PENDING_INT intpending =3D 0 >>> #define int_pending() intpending >>>=20 >>> void exraise(int) __dead2; >>> void onint(void) __dead2; >>>=20 >>> /usr/src/bin/sh/error.c hAS: >>>=20 >>> void >>> exraise(int e) >>> { >>> INTOFF; >>> if (handler =3D=3D NULL) >>> abort(); >>> exception =3D e; >>> longjmp(handler->loc, 1); >>> } >>> . . . >>> void >>> onint(void) >>> { >>> sigset_t sigs; >>>=20 >>> intpending =3D 0; >>> sigemptyset(&sigs); >>> sigprocmask(SIG_SETMASK, &sigs, NULL); >>>=20 >>> /* >>> * This doesn't seem to be needed, since main() emits a newline. >>> */ >>> #if 0 >>> if (tcgetpgrp(0) =3D=3D getpid()) >>> write(STDERR_FILENO, "\n", 1); >>> #endif >>> if (rootshell && iflag) >>> exraise(EXINT); >>> else { >>> signal(SIGINT, SIG_DFL); >>> kill(getpid(), SIGINT); >>> _exit(128 + SIGINT); >>> } >>> } >>>=20 >>> # grep setjmp /usr/src/bin/sh/* >>> /usr/src/bin/sh/TOUR:so I implement it using setjmp and longjmp. = The global variable >>> /usr/src/bin/sh/error.h:#include >>> /usr/src/bin/sh/error.h: * BSD setjmp saves the signal mask, which = violates ANSI C and takes time, >>> /usr/src/bin/sh/error.h: * so we use _setjmp instead. >>> /usr/src/bin/sh/error.h:#define setjmp(jmploc) _setjmp(jmploc) >>> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >>> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) >>> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >>> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >>> /usr/src/bin/sh/eval.c: if (setjmp(jmploc.loc)) { >>> /usr/src/bin/sh/histedit.c: if (setjmp(jmploc.loc)) { >>> /usr/src/bin/sh/jobs.c: if (setjmp(jmploc.loc)) >>> /usr/src/bin/sh/main.c: * commands. The setjmp call sets up the = location to jump to when an >>> /usr/src/bin/sh/main.c: if (setjmp(main_handler.loc)) { >>> /usr/src/bin/sh/parser.c: if (setjmp(jmploc.loc)) { >>> /usr/src/bin/sh/parser.c: if (!setjmp(jmploc.loc)) { >>> /usr/src/bin/sh/trap.c: if (!setjmp(loc1.loc)) { >>> /usr/src/bin/sh/trap.c: if (!setjmp(loc2.loc)) { >>> /usr/src/bin/sh/var.c: if (setjmp(jmploc.loc)) >>=20 >> Here is the call chain that I was able to trace >> in the newer core dump: >> (most nested first to least nested last; >> showing frame pointer and lr value pairs >> and calls/return-places) >>=20 >> (ifree is not in the core file) >> 0xffffffffcc60: 0x0000ffffffffcca0 0x000000004054cd94 >> libc.so.7`__free: >> 0x4054cd90 <+144>: bl 0xad6fc ; ifree at = jemalloc_jemalloc.c:1876 >> 0x4054cd94 <+148>: adrp x9, 185 >> 0xffffffffcca0: 0x0000ffffffffccc0 0x0000000000411300 >> sh`ckfree: >> 0x4112fc <+28>: bl 0x4027e0 ; symbol stub for: = free >> 0x411300 <+32>: ldr x8, [x19, #0x970] >> 0xffffffffccc0: 0x0000ffffffffcd00 0x000000000040e6e8 >> sh`freejob: >> 0x40e6e4 <+136>: bl 0x4112e0 ; ckfree at = memalloc.c:86 >> 0x40e6e8 <+140>: adrp x8, 38 >> 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 >> sh`forkshell: >> 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 >> 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 >=20 > 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 > sh`forkshell: > 0x40f1c4 <+144>: bl 0x413fc8 ; flushall at = output.c:236 > 0x40f1c8 <+148>: bl 0x402920 ; symbol stub for: = fork > 0x40f1cc <+152>: mov w19, w0 > (flushall a voids returning to 0x40f1c8 directly, instead making > the last routine it calls return there instead of to flushall.) >=20 >> 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 >> sh`evaltree: >> 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 >> 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 >> 0xffffffffced0: 0x0000ffffffffd160 0x0000000000406e28 >> sh`evalbackcmd: >> 0x406e24 <+336>: bl 0x40549c ; evaltree at = eval.c:193 >> 0x406e28 <+340>: ldur w0, [x29, #-0x5c]0xffffffffcd60: = 0x0000ffffffffcf90 0x00000000004068e4 >=20 >> 0xffffffffd160: 0x0000ffffffffd310 0x0000000000409324 >> sh`argstr: >> 0x409320 <+428>: bl 0x406cd4 ; evalbackcmd at = eval.c:646 >> 0x409324 <+432>: mov x0, x26 >> 0xffffffffd310: 0x0000ffffffffd370 0x0000000000408fa8 >> sh`expandarg: >> 0x408fa4 <+108>: bl 0x409174 ; argstr at = expand.c:267 >> 0x408fa8 <+112>: cbz x19, 0x409020 ; <+232> at = expand.c:236 >> 0xffffffffd370: 0x0000ffffffffd5f0 0x0000000000407530 >> sh`exphere: >> 0x40752c <+212>: bl 0x408f38 ; expandarg at = expand.c:225 >> 0x407530 <+216>: ldr x8, [x20] >> 0xffffffffd5f0: 0x0000ffffffffd630 0x00000000004073f0 >> sh`expredir: >> 0x4073ec <+112>: bl 0x407458 ; exphere at = eval.c:494 >> 0x4073f0 <+116>: b 0x407428 ; <+172> at = eval.c:535 >> 0xffffffffd630: 0x0000ffffffffd960 0x0000000000406154 >> sh`evalcommand: >> 0x406150 <+744>: bl 0x40737c ; expredir at = eval.c:532 >> 0x406154 <+748>: ldur w27, [x29, #-0x68] >> 0xffffffffd960: 0x0000ffffffffda10 0x0000000000405570 >> sh`evaltree: >> 0x40556c <+208>: bl 0x405e68 ; evalcommand at = eval.c:825 >> 0x405570 <+212>: b 0x405a9c ; <+1536> at = eval.c:623 >> 0x405574 <+216>: ldr x8, [x24, #0x8] >> 0xffffffffda10: 0x0000ffffffffdac0 0x00000000004056b4 >> sh`evaltree: >> 0x4056b0 <+532>: bl 0x40549c ; <+0> at = eval.c:193 >> 0x4056b4 <+536>: ldr w8, [x19, #0x990] >> 0xffffffffdac0: 0x0000ffffffffdb70 0x0000000000405550 >> sh`evaltree: >> 0x40554c <+176>: bl 0x40549c ; <+0> at = eval.c:193 >> 0x405550 <+180>: ldr w8, [x22, #0x994] >> 0xffffffffdb70: 0x0000ffffffffdbf0 0x0000000000411034 >> sh`cmdloop: >> 0x411030 <+248>: bl 0x40549c ; evaltree at = eval.c:193 >> 0x411034 <+252>: mov w27, wzr >> 0xffffffffdbf0: 0x0000ffffffffdc50 0x0000000000410ea8 >> sh`main: >> 0x410ea4 <+656>: bl 0x410f38 ; cmdloop at = main.c:199 >> 0x410ea8 <+660>: adrp x8, 36 >> 0xffffffffdc50: 0x0000ffffffffdc90 0x0000000000402f30 >> sh`__start: >> 0x402f2c <+356>: bl 0x410c14 ; main at main.c:97 >> 0x402f30 <+360>: bl 0x402ae0 ; symbol stub for: = exit >>=20 >> (_rtld is not in the core file) >> 0xffffffffdc90: 0x0000000000000000 0x0000000040434658 >> ld-elf.so.1`.rtld_start: >> 0x40434654 <+20>: bl 0x2e4c ; _rtld at = rtld.c:339 >> 0x40434658 <+24>: mov x8, x0 >>=20 >> Some of the most nested possibly had returned. But the >> forkshell / freejob general time frame seem to match >> everything that I've seen. >>=20 >> [The details of the middle "eval*" related layers vary >> from what I can tell.] >>=20 >> "register read" shows fp, lr, and pc majorly >> messed up. >>=20 >> General Purpose Registers: >> x0 =3D 0x0000000000000000 >> x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc >> x2 =3D 0x0000000040a00000 >> x3 =3D 0x0000000000000002 >> x4 =3D 0x0000000000000096 >> x5 =3D 0x0000000040a5fd10 >> x6 =3D 0x0000000000434c28 sh..bss + 9448 >> x7 =3D 0x0000000000434c28 sh..bss + 9448 >> x8 =3D 0x0000000000000001 >> x9 =3D 0x0000000000000000 >> x10 =3D 0x0000000000000000 >> x11 =3D 0x0000000040a350c0 >> x12 =3D 0x0000000040a0e770 >> x13 =3D 0x0000000000000072 >> x14 =3D 0x000000000000006f >> x15 =3D 0x0000000000000010 >> x16 =3D 0x0000000000432340 =20 >> x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 >> x18 =3D 0x0000000000000000 >> x19 =3D 0x0000000000000000 >> x20 =3D 0x0000000000000000 >> x21 =3D 0x0000000000000001 >> x22 =3D 0x0000000040a5ff10 >> x23 =3D 0x0000ffffffffd190 >> x24 =3D 0x0000000000434000 sh..bss + 6336 >> x25 =3D 0x0000000000434000 sh..bss + 6336 >> x26 =3D 0x0000ffffffffcd00 >> x27 =3D 0x0000000000434000 sh..bss + 6336 >> x28 =3D 0x0000000040a6f5e0 >> fp =3D 0x0000000040a5fed8 >> lr =3D 0x0000000000000000 >> sp =3D 0x0000ffffffffcd60 >> pc =3D 0x0000000000000000 >> cpsr =3D 0x60000000 >>=20 >> sp is also odd by being in the middle of the stack range >> for: >>=20 >> 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 >> sh`forkshell: >> 0x40f48c <+856>: bl 0x40e65c ; freejob at = jobs.c:463 >> 0x40f490 <+860>: add x20, x20, #0x30 ; =3D0x30=20 >> 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 >> sh`evaltree: >> 0x405950 <+1204>: bl 0x40f134 ; forkshell at = jobs.c:838 >> 0x405954 <+1208>: cbnz w0, 0x4059dc ; <+1344> = [inlined] evalpipe + 300 at eval.c:286 >>=20 >> NOTE: The fork happened earlier in sh`forkshell and this >> is the child process that has the odd value. >>=20 >> [It leaves me wondering if 0x0000ffffffffcd60 is a stack >> pointer value associated with a call to something >> earlier than the sh`forkshell call that is called by >> sh`forkshell .] >>=20 >> Also: in the ones with only a small section of the junk >> areas the equivalent of: >>=20 >> 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 >>=20 >> is the largest addressed non-junk content in the area >> and the equivalent of: >>=20 >> 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 >>=20 >> would instead show zeros or "random" garbage values. >>=20 >> In this case, however that range of the stack looks like: >>=20 >> . . . >> 0xffffffffcd00: 0x0000ffffffffce20 0x000000000040f490 >> 0xffffffffcd10: 0x0000ffffffffcd00 0x0000000000434000 >> 0xffffffffcd20: 0x0000000000434000 0x0000ffffffffd190 >> 0xffffffffcd30: 0x0000000040a5ff10 0x0000000000000001 >> 0xffffffffcd40: 0x0000000000000000 0x0000000000000000 >> 0xffffffffcd50: 0x0000000040a5fed8 0x0000000000000000 >> 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 >> 0xffffffffcd70: 0x0000000000000000 0x827a80ccb3228215 >> 0xffffffffcd80: 0x0000000040a6f5c0 0x0000000000434000 >> 0xffffffffcd90: 0x0000000000434000 0x0000000000434000 >> 0xffffffffcda0: 0x0000000000434000 0x0000000000434000 >> 0xffffffffcdb0: 0x0000000040a6f638 0x0000000000000000 >> 0xffffffffcdc0: 0x0000000040a350c0 0x0000000000434000 >> 0xffffffffcdd0: 0x0000ffffffffce20 0x000000000040f1c8 >> 0xffffffffcde0: 0x0000000000000003 0x0000000040a350c0 >> 0xffffffffcdf0: 0x0000000040a6f5c0 0x0000000000434000 >> 0xffffffffce00: 0x0000000000434000 0x0000000040a6f638 >> 0xffffffffce10: 0x0000000000000000 0x0000000000434000 >> 0xffffffffce20: 0x0000ffffffffced0 0x0000000000405954 >> . . . >>=20 >> Interestingly 0xffffffffcd60 reported for the sp looks >> like it has a frame-pointer/lr-value pair that does not >> fit with the overall call chain that ties together but >> is some fragment of a prior(?) call chain: >>=20 >> 0xffffffffcd60: 0x0000ffffffffcf90 0x00000000004068e4 >> sh`evalcommand: >> 0x4068e0 <+2680>: bl 0x402be0 ; symbol stub for: = _setjmp >> 0x4068e4 <+2684>: cbz w0, 0x406a04 ; <+2972> at = eval.c:1101 >>=20 >> It looks like it is a record from calling _setjmp in >> sh`evalcommand . >>=20 >> (sh uses _setjmp/_longjmp via macros that turn >> into them for setjmp/longjmp references in >> sh's source code.) >>=20 >> Interestingly (likely junk relative to the above): >>=20 >> 0xffffffffcf90: 0x0000000000000000 0x0000000000432000 >>=20 >> where: >>=20 >> (lldb) dis -s 0x0000000000432000 >> sh`__frame_dummy_init_array_entry: >> 0x432000 <+0>: .long 0x00402fac ; unknown opcode >> 0x432004 <+4>: .long 0x00000000 ; unknown opcode >> (lldb) dis -s __frame_dummy_init_array_entry -c32 >> sh`frame_dummy: >> 0x402fac <+0>: adrp x8, 48 >> 0x402fb0 <+4>: adrp x1, 48 >> 0x402fb4 <+8>: ldr x8, [x8, #0x30] >> 0x402fb8 <+12>: ldr x1, [x1, #0x228] >> 0x402fbc <+16>: cmp x8, #0x0 ; =3D0x0=20 >> 0x402fc0 <+20>: ccmp x1, #0x0, #0x4, ne >> 0x402fc4 <+24>: b.ne 0x402fcc ; <+32> >> 0x402fc8 <+28>: ret =20 >> 0x402fcc <+32>: adrp x0, 48 >> 0x402fd0 <+36>: add x0, x0, #0x30 ; =3D0x30=20 >> 0x402fd4 <+40>: br x1 >>=20 >> sh`lookupalias: >> . . . >>=20 >>=20 >> Ohter notes: >>=20 >> Some examples of funcnest=3D=3D0 others have (e.g.) funcnest=3D=3D2. >> This one had funcnest=3D=3D0. >>=20 >> commandname varies. In this case it was: >>=20 >> (lldb) print commandname >> (char *) $74 =3D 0x0000ffffffffe210 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/configure" >>=20 >> Other examples include: >>=20 >> (lldb) print commandname >> (char *) $0 =3D 0x0000ffffffffdc40 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/fi= xincludes/configure" >>=20 >> (lldb) print commandname >> (char *) $0 =3D 0x0000ffffffffe498 = "/usr/obj/portswork/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.3.0/li= biberty/../config.sub" >>=20 >> (lldb) print commandname >> (char *) $0 =3D 0x0000ffffffffe398 "../libtool" >>=20 >>=20 >> So far the forkshell/fork/freejob and associated materials always = seeming >> to be involved is all that I've found that is common (at least that = is >> suggested by what I see so far) within the sh context. >>=20 >>> Other notes: >>>=20 >>> As a personal investigation I've temporarily changed to using >>> something not fully generic but based on gic-400 specifics: >>>=20 >>> # svnlite diff /usr/src/sys/arm/arm/gic.c >>> Index: /usr/src/sys/arm/arm/gic.c >>> =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/src/sys/arm/arm/gic.c (revision 312982) >>> +++ /usr/src/sys/arm/arm/gic.c (working copy) >>> @@ -672,9 +672,13 @@ >>>=20 >>> if (irq >=3D sc->nirqs) { >>> #ifdef GIC_DEBUG_SPURIOUS >>> +#define EXPECTED_SPURIOUS_IRQ 1023 >>> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >>> device_printf(sc->gic_dev, >>> - "Spurious interrupt detected: last irq: %d on = CPU%d\n", >>> + "Spurious interrupt %d detected of %d: last irq: = %d on CPU%d\n", >>> + irq, sc->nirqs, >>> sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >>> + } >>> #endif >>> return (FILTER_HANDLED); >>> } >>> @@ -720,6 +724,16 @@ >>> if (irq < sc->nirqs) >>> goto dispatch_irq; >>>=20 >>> + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { >>> +#undef EXPECTED_SPURIOUS_IRQ >>> +#ifdef GIC_DEBUG_SPURIOUS >>> + device_printf(sc->gic_dev, >>> + "Spurious end interrupt %d detected of %d: last = irq: %d on CPU%d\n", >>> + irq, sc->nirqs, >>> + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); >>> +#endif >>> + } >>> + >>> return (FILTER_HANDLED); >>> } >>>=20 >>>=20 >>> The result was no notices of Spurious interrupts have been = generated: >>> All of the odd interrupts were the special 1023 value. >>>=20 >>> [As far as I could tell from the code the configuration is such that >>> 1022 should not be generated --and were not. 1020 and 1021 are >>> reserved and should not be generated.] From owner-freebsd-arm@freebsd.org Sat Feb 11 13:54:18 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A6BECDBCA6 for ; Sat, 11 Feb 2017 13:54:18 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF64613 for ; Sat, 11 Feb 2017 13:54:17 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 9AB6A1AB4CB for ; Sat, 11 Feb 2017 07:54:16 -0600 (CST) Subject: Re: Out of swap - NOT To: freebsd-arm@freebsd.org References: From: Karl Denninger Message-ID: Date: Sat, 11 Feb 2017 07:54:10 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010905060403040304000401" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 13:54:18 -0000 This is a cryptographically signed message in MIME format. --------------ms010905060403040304000401 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/11/2017 01:30, freebsd-arm@wynn.com wrote: > > Greeting- > > So I have seen this several times on FreeBSD-12 - uname info to follow > > FreeBSD bb2.wynn.com 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311461: Fri > Jan 6 03:13:01 UTC 2017 > root@releng3.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm > > MAKE=3Dmake sh ../../../conf/newvers.sh BEAGLEBONE > cc -c -O -pipe -g -nostdinc -I. -I../../.. -I../../../contrib/libfdt > - -I../../../gnu/dts/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > - -include opt_global.h -march=3Darmv7a -funwind-tables -ffreestanding= > - -fwrapv -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs > - -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > - -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprint= f__ > - -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas= > - -Wno-error-tautological-compare -Wno-error-empty-body > - -Wno-error-parentheses-equality -Wno-error-unused-function > - -Wno-error-pointer-sign -Wno-error-shift-negative-value -mfpu=3Dnone= > - -std=3Diso9899:1999 -Werror vers.c ctfconvert -L VERSION -g vers.o > linking kernel.full ctfmerge -L VERSION -g -o kernel.full ... *** > Signal 9 > > Stop. > make: stopped in /export/src/sys/arm/compile/BEAGLEBONE > root@bb2:/sys/arm/compile/BEAGLEBONE # > > pid 24523 (ctfmerge), uid 0, was killed: out of swap space > pid 21365 (make), uid 0, was killed: out of swap space > pid 38527 (ctfmerge), uid 0, was killed: out of swap space > [wynkoop@bb2 ~]$ > > > I have run the kernel build several times and this is always the > result. I also had an rsync killed for out of swap. The interesting > part is that at no time did I really run out of swap. This is on an > original BeagleBone with 256M of ram and 768M of swap. At no time did > pstat or top in another window report that all the swap was used. In > fact swap use never got above 10%. > > I have been using BSD since the early 1980's and have never seen a > system report a process being killed for out of swap when there is > still plenty of swap before now. > > Ideas? =20 > > - -Brett > - --=20 > > wynkoop@wynn.com > 917-642-6925 > 929-272-0000 In all probability it's really out. Remember that RAM allocation has to either come from physical RAM or swap. If the requested allocation cannot be made then you get this exact situation, and it happens quickly enough that you won't see it most of the time with monitoring tools. What's probably biting you is temporary file space, which comes from RAM since it's mounted on a ramdisk, and exhausts it. I've run into this same situation trying to build on a Pi2. My recommendation? Connect a USB disk drive to the system and put a swap partition on there. Or cross-compile (which is what I do) on a nice big AMD64 box since that is MUCH faster. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010905060403040304000401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTExMzU0MTBaME8GCSqGSIb3DQEJBDFCBEB6cj0Z eJakPsyBHoS/IVmp2UAbUIPx8I4dprzWWS25nxRLlVwfUsjQmLozkR38QHg0XBbbhnPJG7GW nkA6NHX1MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAGClgzelbJBRT dBGERMagj8JpaKsjRvFw3kgKneVOYokTabeVd3sL7K6EBpx9nCyeMDGroJXLmxnUKwvLLbgO n5Xi9uBR46rmCfFrphVG/57N/NT5oATtH0DGScy9vkl7dweh36fXd+4idzQudZWRnwQds41i 64G5zaX52Oe4BWRAvHknn8n1M68e3JVccCDPtfz0+C6bJ3Lw9KoaFi/fEapFD3D1979Ixn1U lvKqrS9XjcHN/RaZbV9LUpg+KUtTbq5tNk1w7t7TG5bjqcEGKhqCJRZN2VtTRnJTMUa3hwI2 AIO0jY1tVMiSxygT1MroKorkGh56a+HGfI93q4KJ+U4LX3C0t36EW2dz85po8rDAGqPu7JN8 MUzMFlu2Gqr5oyKhzx5RUCiLdwwANpAB4SWBOT3oHVZpD7kQH0ewt+nxl4NH7RHHlpsNGvPx kT6uq75GZRDRw9ZP1dM1mxahmaOKcvidmJoKYgD8xTUXydGf6aHmCe1Q++93IXNDth5koFOv 62/wfqPmNEI3qMH3ID6ugwqvn1EryewfMEXmXAPMwOGZ7Lolis2zaqNlusJiopZtY38i5GSV hKLTXIuxJjUosnVx/OaDXAcN27VVWoRt8XUv5qvhn/M/EDAyx3LSWFyuewClPtZdeqNplJK5 y+t1lDl5ajTP4YY6FbGvYecAAAAAAAA= --------------ms010905060403040304000401-- From owner-freebsd-arm@freebsd.org Sat Feb 11 19:08:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2048CDB610 for ; Sat, 11 Feb 2017 19:08:37 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (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 8EC341FA6 for ; Sat, 11 Feb 2017 19:08:37 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:Cc:To:From; bh=KatCD3sihZJhPsa4xisJl1wpvXUzEdozbuQLG2cUaLI=; b=AdZ7haY3J9XhmTskUsRjXLA9hxuJavSke/E1wuia77X65z9tOb+dYH0LlEixCkrKqnB/BfzrVy5fyMqN18T8aZ/8YgugQRW0chFVQOA+Ty90FwvzHx39C6fTgRGeNiVgmg00UVmAZcnVrlzFDqy0SAYKM2K43AK9hnSKZYPyd1uFHM5H; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ccd25-0005VX-74; Sat, 11 Feb 2017 11:08:35 -0800 From: "Tony Hain" To: "'Oleksandr Tymoshenko'" Cc: References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> In-Reply-To: <20170211015231.GA56071@bluezbox.com> Date: Sat, 11 Feb 2017 11:08:28 -0800 Message-ID: <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCzikkuUoxhpHAkDcVcrtsdCslcNQH9hJ4To5IviqA= Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: Questions about BBB/BBG dtb names vs. content X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.net) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 19:08:37 -0000 > -----Original Message----- > From: Oleksandr Tymoshenko [mailto:gonzo@bluezbox.com] > Sent: Friday, February 10, 2017 5:53 PM > To: Tony Hain > Cc: freebsd-arm@freebsd.org > Subject: Re: Questions about BBB/BBG dtb names vs. content > > Tony Hain (tony@tndh.net) wrote: > > When I built 12 current the other day, I found some confusing dtb file > > names. > > First there were identical files : > > am335x-bone.dtb beaglebone.dtb > > am335x-boneblack.dtb beaglebone-black.dtb > > > > But there was not a matching one for green. Is that intentional? > > am335x-bonegreen.dtb > > > > Then the content didn't match the names: > > am335x-boneblack.dtb -- > > compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; > > > > am335x-bonegreen.dtb -- > > compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", > > "ti,am335x-bone", "ti,am33xx"; > > > > Aren't the strings in the compatible line supposed to match the file names? > > Is there a reason there are identical files in the dtb path rather > > than a link? > > Is the fdt_file="" line required in loader.conf if the am335x file > > name exists? > > > > I have the BBB running with fdt_file="beaglebone-black.dtb", and the > > changes to it for turning on uart1. Should I have made the changes to > > the am335x file instead, or should I create the beaglebone-green.dtb file > for the BBG? > > beaglebone*dtb is FreeBSD-specific DTB names, dts files for them were > created in early days of FDT support. am335x-*dtb are upstream names, > Linux and U-Boot use them as standard names. > > U-Boot can detect type of board in run-time and set fdt_file env variable > based on that type. Until recently we had sysutils/u-boot-beaglebone port > with custom FreeBSD-specific patch where this autodetect logic used > beaglebone*dtb names. Recently it was converted to being slave port to > sysutils/u-boot-master as a part of U-Boot ports unification effort. During this > conversion aforementioned patch was deleted so now u-boot operates with > am335x-*.dtb names. To be backward-compatible with previously built > systems, that still refer to old-style names, we now create links, > beaglebone.dtb is a link to am335x-bone.dtb and beaglebone-black.dtb is a > link to am335x-boneblack.dtb. There was no FreeBSD-specific DTS for > beaglebone green previously, so am335x-bonegreen.dtb does not have > beaglebone* counterpart. Thanks for the background. I had seen comments about a transition, but not enough detail to figure out old vs. new. > > At the moment any changes toboot/fdt/dts/arm/beagebone-*.dts are not > going affect beagebone-*.dtb because these dtbs created as links, not > generated. I have patch in review that fixes it and brings back old-style DTBs > along with some fixes that are in upstream but haven't been merged to > FreeBSD tree yet: https://reviews.freebsd.org/D9432 That may be the intent, but as of FreeBSD 12.0-CURRENT #0 r313411: Wed Feb 8 00:04:14 PST 2017 they were separate files, not links: root@tic:~ # ls -l /boot/dtb total 248 -r--r--r-- 2 root wheel 33017 Feb 8 00:07 am335x-bone.dtb -r--r--r-- 2 root wheel 33801 Feb 8 00:07 am335x-boneblack.dtb -r--r--r-- 1 root wheel 33305 Feb 8 00:07 am335x-bonegreen.dtb -r--r--r-- 2 root wheel 33801 Feb 8 00:07 beaglebone-black.dtb -r--r--r-- 2 root wheel 33017 Feb 8 00:07 beaglebone.dtb -r--r--r-- 1 root wheel 31483 Feb 8 00:07 ufw.dtb Links are what I expected, and is why I asked for clarification. > > With current tree you need to move your uart1-related change to > sys/gnu/dts/arm/am335x-boneblack.dts, regenerate dtbs and that should do > the trick. Thanks for the pointer. I have been running dtc after the build to manually patch the file. There is still the open question about the "compatible" strings containing "-" while the file names do not. If that is what is coming from upstream and expected, fine. I just wanted to check to make sure something didn't get crossed up during the name changes. Hopefully I will get a green build done this weekend. Tony > > -- > gonzo From owner-freebsd-arm@freebsd.org Sat Feb 11 19:36:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E325CDB1E7 for ; Sat, 11 Feb 2017 19:36:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 7336D13A4 for ; Sat, 11 Feb 2017 19:36:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 50a572d0-f091-11e6-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 50a572d0-f091-11e6-b3c2-c9f38144898e; Sat, 11 Feb 2017 19:36:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1BJaBux001717; Sat, 11 Feb 2017 12:36:11 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1486841770.10020.287.camel@freebsd.org> Subject: Re: Questions about BBB/BBG dtb names vs. content From: Ian Lepore To: Tony Hain , "'Oleksandr Tymoshenko'" Cc: freebsd-arm@freebsd.org Date: Sat, 11 Feb 2017 12:36:10 -0700 In-Reply-To: <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> 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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 19:36:19 -0000 On Sat, 2017-02-11 at 11:08 -0800, Tony Hain wrote: > > > > [...] > > There is still the open question about the "compatible" strings > containing > "-" while the file names do not. If that is what is coming from > upstream and > expected, fine. I just wanted to check to make sure something didn't > get > crossed up during the name changes. Hopefully I will get a green > build done > this weekend. > > Tony There is not necessarily any relationship between dts/dtb filenames and  any compat strings within the dtb.  The compat strings are defined by the bindings documentation, and are essentially a contract between the dts source and the device driver source.  The filenames are a separate contract, mostly between vendors and the u-boot source, but even those don't have to agree. Anybody can set the u-boot fdt_file env var to anything they want. IMO, that is the right way to handle all this freebsd and local user customization... if you want a uart device enabled, then create your own tony-bb.dts that includes the standard beaglebone source, then adds the few lines of code needed to enable the uart, and in u-boot just do setenv fdt_file tony-bb.dtb; saveenv.  (At least until overlay support settles down and finds its way into freebsd.) -- Ian From owner-freebsd-arm@freebsd.org Sat Feb 11 20:11:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D29F0CDBB76 for ; Sat, 11 Feb 2017 20:11:43 +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 B8CD2C6A for ; Sat, 11 Feb 2017 20:11:43 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cce1F-000HBh-GX; Sat, 11 Feb 2017 12:11:42 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v1BKBfqd066072; Sat, 11 Feb 2017 12:11:41 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sat, 11 Feb 2017 12:11:40 -0800 From: Oleksandr Tymoshenko To: Tony Hain Cc: freebsd-arm@freebsd.org Subject: Re: Questions about BBB/BBG dtb names vs. content Message-ID: <20170211201140.GA66049@bluezbox.com> References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) 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: Tony Hain (tony@tndh.net) wrote: > > Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: tndh.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 20:11:43 -0000 Tony Hain (tony@tndh.net) wrote: > > -----Original Message----- > > From: Oleksandr Tymoshenko [mailto:gonzo@bluezbox.com] > > Sent: Friday, February 10, 2017 5:53 PM > > To: Tony Hain > > Cc: freebsd-arm@freebsd.org > > Subject: Re: Questions about BBB/BBG dtb names vs. content > > > > Tony Hain (tony@tndh.net) wrote: > > > When I built 12 current the other day, I found some confusing dtb file > > > names. > > > First there were identical files : > > > am335x-bone.dtb beaglebone.dtb > > > am335x-boneblack.dtb beaglebone-black.dtb > > > > > > But there was not a matching one for green. Is that intentional? > > > am335x-bonegreen.dtb > > > > > > Then the content didn't match the names: > > > am335x-boneblack.dtb -- > > > compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; > > > > > > am335x-bonegreen.dtb -- > > > compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", > > > "ti,am335x-bone", "ti,am33xx"; > > > > > > Aren't the strings in the compatible line supposed to match the file > names? > > > Is there a reason there are identical files in the dtb path rather > > > than a link? > > > Is the fdt_file="" line required in loader.conf if the am335x file > > > name exists? > > > > > > I have the BBB running with fdt_file="beaglebone-black.dtb", and the > > > changes to it for turning on uart1. Should I have made the changes to > > > the am335x file instead, or should I create the beaglebone-green.dtb > file > > for the BBG? > > > > beaglebone*dtb is FreeBSD-specific DTB names, dts files for them were > > created in early days of FDT support. am335x-*dtb are upstream names, > > Linux and U-Boot use them as standard names. > > > > U-Boot can detect type of board in run-time and set fdt_file env variable > > based on that type. Until recently we had sysutils/u-boot-beaglebone port > > with custom FreeBSD-specific patch where this autodetect logic used > > beaglebone*dtb names. Recently it was converted to being slave port to > > sysutils/u-boot-master as a part of U-Boot ports unification effort. > During this > > conversion aforementioned patch was deleted so now u-boot operates with > > am335x-*.dtb names. To be backward-compatible with previously built > > systems, that still refer to old-style names, we now create links, > > beaglebone.dtb is a link to am335x-bone.dtb and beaglebone-black.dtb is a > > link to am335x-boneblack.dtb. There was no FreeBSD-specific DTS for > > beaglebone green previously, so am335x-bonegreen.dtb does not have > > beaglebone* counterpart. > > Thanks for the background. I had seen comments about a transition, but not > enough detail to figure out old vs. new. > > > > > At the moment any changes toboot/fdt/dts/arm/beagebone-*.dts are not > > going affect beagebone-*.dtb because these dtbs created as links, not > > generated. I have patch in review that fixes it and brings back old-style > DTBs > > along with some fixes that are in upstream but haven't been merged to > > FreeBSD tree yet: https://reviews.freebsd.org/D9432 > > That may be the intent, but as of FreeBSD 12.0-CURRENT #0 r313411: Wed Feb > 8 00:04:14 PST 2017 they were separate files, not links: > root@tic:~ # ls -l /boot/dtb > total 248 > -r--r--r-- 2 root wheel 33017 Feb 8 00:07 am335x-bone.dtb > -r--r--r-- 2 root wheel 33801 Feb 8 00:07 am335x-boneblack.dtb > -r--r--r-- 1 root wheel 33305 Feb 8 00:07 am335x-bonegreen.dtb > -r--r--r-- 2 root wheel 33801 Feb 8 00:07 beaglebone-black.dtb > -r--r--r-- 2 root wheel 33017 Feb 8 00:07 beaglebone.dtb > -r--r--r-- 1 root wheel 31483 Feb 8 00:07 ufw.dtb > > Links are what I expected, and is why I asked for clarification. They are hardlinks, not symlinks % ls -ali am335x-bone.dtb beaglebone.dtb am335x-boneblack.dtb beaglebone-black.d tb 4251661 -r--r--r-- 2 root wheel 33017 Feb 11 11:48 am335x-bone.dtb 4251662 -r--r--r-- 2 root wheel 33801 Feb 11 11:48 am335x-boneblack.dtb 4251662 -r--r--r-- 2 root wheel 33801 Feb 11 11:48 beaglebone-black.dtb 4251661 -r--r--r-- 2 root wheel 33017 Feb 11 11:48 beaglebone.dtb inode number (first column) is the same respective dtbs. -- gonzo From owner-freebsd-arm@freebsd.org Sat Feb 11 21:46:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60A59CDB050 for ; Sat, 11 Feb 2017 21:46:08 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from wa3yre.wynn.com (wa3yre.wynn.com [199.89.147.3]) (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 B3B3E1B7 for ; Sat, 11 Feb 2017 21:46:07 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from pearl (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by wa3yre.wynn.com (8.14.3/8.12.6) with ESMTP id v1BLj4KP086620; Sat, 11 Feb 2017 16:45:04 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Received: from pearl ([199.89.147.252] helo=pearl) by ASSP-nospam with ESMTPS(AES256-SHA) (ASSP 1.10.1); 11 Feb 2017 16:45:04 -0500 Date: Sat, 11 Feb 2017 16:44:59 -0500 From: freebsd-arm@wynn.com To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: Out of swap - NOT Message-ID: In-Reply-To: References: <20170211023050.387b9cc7@pearl> Reply-To: wynkoop@wynn.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-apple-darwin10.8.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 21:46:08 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCk9uIFNh dCwgMTEgRmViIDIwMTcgMDc6NTQ6MTAgLTA2MDANCkthcmwgRGVubmluZ2VyIDxrYXJsQGRlbm5p bmdlci5uZXQ+IHdyb3RlOg0KDQo+IA0KPiBJbiBhbGwgcHJvYmFiaWxpdHkgaXQncyByZWFsbHkg b3V0LiAgUmVtZW1iZXIgdGhhdCBSQU0gYWxsb2NhdGlvbiBoYXMNCj4gdG8gZWl0aGVyIGNvbWUg ZnJvbSBwaHlzaWNhbCBSQU0gb3Igc3dhcC4gIElmIHRoZSByZXF1ZXN0ZWQgYWxsb2NhdGlvbg0K PiBjYW5ub3QgYmUgbWFkZSB0aGVuIHlvdSBnZXQgdGhpcyBleGFjdCBzaXR1YXRpb24sIGFuZCBp dCBoYXBwZW5zDQo+IHF1aWNrbHkgZW5vdWdoIHRoYXQgeW91IHdvbid0IHNlZSBpdCBtb3N0IG9m IHRoZSB0aW1lIHdpdGggbW9uaXRvcmluZw0KPiB0b29scy4NCj4gDQo+IFdoYXQncyBwcm9iYWJs eSBiaXRpbmcgeW91IGlzIHRlbXBvcmFyeSBmaWxlIHNwYWNlLCB3aGljaCBjb21lcyBmcm9tDQo+ IFJBTSBzaW5jZSBpdCdzIG1vdW50ZWQgb24gYSByYW1kaXNrLCBhbmQgZXhoYXVzdHMgaXQuICBJ J3ZlIHJ1biBpbnRvDQo+IHRoaXMgc2FtZSBzaXR1YXRpb24gdHJ5aW5nIHRvIGJ1aWxkIG9uIGEg UGkyLg0KPiANCj4gTXkgcmVjb21tZW5kYXRpb24/IENvbm5lY3QgYSBVU0IgZGlzayBkcml2ZSB0 byB0aGUgc3lzdGVtIGFuZCBwdXQgYQ0KPiBzd2FwIHBhcnRpdGlvbiBvbiB0aGVyZS4gT3IgY3Jv c3MtY29tcGlsZSAod2hpY2ggaXMgd2hhdCBJIGRvKSBvbiBhDQo+IG5pY2UgYmlnIEFNRDY0IGJv eCBzaW5jZSB0aGF0IGlzIE1VQ0ggZmFzdGVyLg0KPiANCkdyZWV0aW5nLQ0KDQpJIGZpbmQgaXQg cmVhbGx5IGhhcmQgdG8gYmVsaWV2ZSB0aGF0IEkgY291bGQgYmUgcnVubmluZyBvdXQgb2Ygc3dh cCwNCmJ1dCBJIHN1cHBvc2UgYXMgYSB0ZXN0IEkgY2FuIHN0aWNrIGFkZGl0aW9uYWwgc3dhcCBv biBteSBVU0IgZHJpdmUuDQpUaGVyZSBpcyBhbHJlYWR5IGFzIEkgc2FpZCAzeFJhbSBzd2FwIG9u IHRoZSBzZCBjYXJkLiAgWWVzIHBlcmhhcHMgbXkNCnBzdGF0IGRpZCBub3QgcnVuIGF0IHRoZSBl eGFjdCByaWdodCBpbnN0YW50IHRvIHNlZSB0aGUgT09NIGhhcHBlbiwgYnV0DQpoYXZpbmcgc3Rh cnRlZCBvbiBQRFAgMTEvNzBzIHJ1bm5pbmcgQlNEIDQuMSBJIGhhdmUgbmV2ZXIgc2VlbiBhIGtl cm5lbA0KYnVpbGQgYWN0dWFsbHkgdGFrZSB0aGF0IG11Y2ggbWVtb3J5Lg0KDQpUaGlzIGV4ZXJj aXNlIGlzIG5vdCByZWFsbHkgYWJvdXQgZ2V0dGluZyBhIG5ldyBrZXJuZWwgYnVpbHQuICBZZXMg SQ0KY291bGQgY3Jvc3Mgb24gbXkgTWFjIG9yIG9uZSBvZiBteSBGcmVlQlNEIHNlcnZlcnMuICBJ dCBpcyBhYm91dA0KYmVhdGluZyBvbiB0aGUgc3lzdGVtIHRvIHNlZSB3aGF0IGl0IGNhbiBkbyBh bmQgaG93IHN0YWJsZSBpdCBpcy4gIFdoZW4NCmxhc3QgSSBiZWF0IG9uIFVTQiBkaXNrcyB1bmRl ciBGcmVlQlNEIEFSTSB0aGUgZGlza3Mgd291bGQganVzdA0KZGlzYXBwZWFyIGFzIGZhciBhcyB0 aGUga2VybmVsIHdhcyBjb25jZXJuZWQuICBTbyBJIHNlZSB0aGVyZSBpcyBtdWNoDQppbXByb3Zl bWVudCBiZXR3ZWVuIDEwIGFuZCAxMi4gIA0KDQpUaGlzIHJlYWxseSBiZWdzIHRoZSBxdWVzdGlv biBob3cgY2FuIG15IDU4NiBhdCAxMzNNaHogd2l0aCA0OE0gb2YgcmFtDQphbmQgOTZNICBvZiBz d2FwIGJ1aWxkIGl0J3Mga2VybmVsIChmcmVlYnNkKSBhbmQgYW4gYXJtIGJveCB3aXRoIG1vcmUN CnJlYWwgcmFtIGFuZCAzeCBzd2FwIGdldHMgT09NIGlzc3Vlcz8NCg0KLSAtQnJldHQNCg0KDQot IC0tIA0KDQp3eW5rb29wQHd5bm4uY29tDQo5MTctNjQyLTY5MjUNCjkyOS0yNzItMDAwMA0KDQpB bWVuZG1lbnQgSQ0KDQpDb25ncmVzcyBzaGFsbCBtYWtlIG5vIGxhdyByZXNwZWN0aW5nIGFuIGVz dGFibGlzaG1lbnQgb2YgcmVsaWdpb24sIG9yDQpwcm9oaWJpdGluZyB0aGUgZnJlZSBleGVyY2lz ZSB0aGVyZW9mOyBvciBhYnJpZGdpbmcgdGhlIGZyZWVkb20gb2YNCnNwZWVjaCwgb3Igb2YgdGhl IHByZXNzOyBvciB0aGUgcmlnaHQgb2YgdGhlIHBlb3BsZSBwZWFjZWFibHkgdG8NCmFzc2VtYmxl LCBhbmQgdG8gcGV0aXRpb24gdGhlIGdvdmVybm1lbnQgZm9yIGEgcmVkcmVzcyBvZiBncmlldmFu Y2VzLg0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQppUUVjQkFFQkNBQUdCUUpZ bjRYZkFBb0pFSzZLM3lyYytSdURyMGNILzJ2aEhhN3lLalVadFhLbFdYZzlocmRoDQpCTE9WUXlL NGZMMlJRc0xLTlowQTZDQWFxQU1kcW90UFUrTDlnTUdUeEV4V2FBcjlSM1orOWdMUjlqMVpGRUJR DQovbERSUXhvN1FsTitJcXo1QkJCOHlMczBid2g2REJkanhVM21RWWVhVnl5WVlEWVVidVZWNkVX WkhIVVdmZ2lVDQpxTVlkaTlRMzVNS0FzTStzU2R3QUJqTE9FdVlKc3dSVWYzTnlnV3ozdXREWXBD UHBnZ204NG9mc2ZJaFZmc1pQDQoydUk4bEhjWmdzRnhQOERCS3NLMnJjRWpNa2IvU256cXNUQlMz ZE1WSEVPM0xjSFMvQ2tBamhZMFBUVEN6ZHUxDQpNcUJvd3R6SEhmNmd5NWk5dHM2WXVMRHhialRM WmkyK254YU5qWjdxanNVUzlpd0t0cXRNVjdTVEVxQUNyM009DQo9dUh0Zw0KLS0tLS1FTkQgUEdQ IFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-arm@freebsd.org Sat Feb 11 21:56:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E742CCDB381 for ; Sat, 11 Feb 2017 21:56:53 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id A0BCC977 for ; Sat, 11 Feb 2017 21:56:53 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3E46D1ABE85; Sat, 11 Feb 2017 15:56:52 -0600 (CST) Subject: Re: Out of swap - NOT To: wynkoop@wynn.com References: <20170211023050.387b9cc7@pearl> Cc: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: <6cf27c78-dc32-6282-d244-9158d89d3694@denninger.net> Date: Sat, 11 Feb 2017 15:56:46 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090001080300090901010205" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 21:56:54 -0000 This is a cryptographically signed message in MIME format. --------------ms090001080300090901010205 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/11/2017 15:44, freebsd-arm@wynn.com wrote: > On Sat, 11 Feb 2017 07:54:10 -0600 > Karl Denninger wrote: > > > > In all probability it's really out. Remember that RAM allocation has= > > to either come from physical RAM or swap. If the requested allocatio= n > > cannot be made then you get this exact situation, and it happens > > quickly enough that you won't see it most of the time with monitoring= > > tools. > > > What's probably biting you is temporary file space, which comes from > > RAM since it's mounted on a ramdisk, and exhausts it. I've run into > > this same situation trying to build on a Pi2. > > > My recommendation? Connect a USB disk drive to the system and put a > > swap partition on there. Or cross-compile (which is what I do) on a > > nice big AMD64 box since that is MUCH faster. > > Greeting- > > I find it really hard to believe that I could be running out of swap, > but I suppose as a test I can stick additional swap on my USB drive. > There is already as I said 3xRam swap on the sd card. Yes perhaps my > pstat did not run at the exact right instant to see the OOM happen, but= > having started on PDP 11/70s running BSD 4.1 I have never seen a kernel= > build actually take that much memory. > > This exercise is not really about getting a new kernel built. Yes I > could cross on my Mac or one of my FreeBSD servers. It is about > beating on the system to see what it can do and how stable it is. When= > last I beat on USB disks under FreeBSD ARM the disks would just > disappear as far as the kernel was concerned. So I see there is much > improvement between 10 and 12. =20 > > This really begs the question how can my 586 at 133Mhz with 48M of ram > and 96M of swap build it's kernel (freebsd) and an arm box with more > real ram and 3x swap gets OOM issues? > > -Brett > Where's your temp directory mounted? By default that's usually on a ramdisk (md) on these builds, and that will bite you in exactly this fashion. That's why I said to connect a USB disk drive; stick your temp (and swap if you wish) on there and the problem should go away. tmp on md is a wise selection for any device that has main storage on an sd card as those things are both (very) slow and relatively fragile in terms of writes. However trying to buildworld/buildkernel there requires a LOT of transient space and if you don't have it... boom-boom. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090001080300090901010205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTEyMTU2NDZaME8GCSqGSIb3DQEJBDFCBEBlaoDn mXMuo41D1zDZkZ0VxaJqrmOKcayeoDDwcoMz7v6fpEM6GRrjeM+Tj1bpIC8S2MhTt8EsnFix 0cmI7KMlMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAw4yz13QnyPU5 G0+i2LiCI/+Yas2zPXbK5NbvSjJd0/2nde8fmZQCPovppD/KCK8FCJZ2HioX74ONgNplaQ9+ LEkwh76wirE7xuMQjNzvGZUohxYiMu2IaQpBc7YdYEhgrMhD4uE3d08uHSRQpySOw7O8Pmkt aW2ZYbg7Snj5Jlmn4C1VwEHOBCuw/2Z3BKL/XUcroSQzwcQ1Wmn9UFbhV13NI7rskSsv6V8+ QPVW8OJuk/foHmmiaryglo1tTJgsVWB+CGCLOl11GkfBICd1ty94G7Nyh7IkAQIeWsJhhBvz bsM6RVNJdrgaMgK3SJ6mzuEpEjR/LnWfaml19PlZlfHZjyg776ej7kayc4jTq24XfHBxXZsK GgFCGIm8ZOwmRnIqGUeeN6g47UgQCIY2L2DtKdIM3DM+hf58SRRR/ydhTxNqw1B/TYLgc0Ht c7oerXJtp9zQqE42HHCZ7s6nfJUwh9SO1t3I1dmxRuDbj+6u5lFfiDj8RVgyglalTfjwf+LK wW0He+KfW2ZkvKmPIShZ6vm2CU/jEeKgSu9ETSvjNchpWs+UqVfCXmVdcMfGYO+TdtkyrP/5 kL6ZHFq3SXVUTnRQuqP0RbBo0C/6aSTeXih1FRhliT300eTXJkWtEBnM5dl3IqJMzTsDpktF 747SWnNg0pKrhnpN3EhjyBgAAAAAAAA= --------------ms090001080300090901010205--