From owner-freebsd-arm@freebsd.org Sun Feb 12 11:09: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 03F4BCD9DF2 for ; Sun, 12 Feb 2017 11:09:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (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 AFFCE1304 for ; Sun, 12 Feb 2017 11:09:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24724 invoked from network); 12 Feb 2017 11:02:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Feb 2017 11:02:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Sun, 12 Feb 2017 06:02:27 -0500 (EST) Received: (qmail 31870 invoked from network); 12 Feb 2017 10:52:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Feb 2017 10:52:47 -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 F169DEC885D; Sun, 12 Feb 2017 02:52:46 -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: pine64 (an A64 Contex-A53 context, e.g. -r312982): sh`forkshell child-process path after fork sometimes has a bad stack pointer value Message-Id: Date: Sun, 12 Feb 2017 02:52:46 -0800 Cc: freebsd-arm To: Andrew Turner , Shawn Webb , Tom Vijlbrief 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, 12 Feb 2017 11:09:10 -0000 On pine64 (an A64 Cortex-A53 context) multiple people on the lists including me have reported sh getting occasional core dumps. I've analyzed a bunch of the sh core dumps and all failed in the child-process path of forkshell when forkshell tried to return.=20 I've since done experiments with code to detect some forms of odd stack pointer values so that the adjusted code calls abort for such a detection before such a return would happen. [This gives a nicer context to look at in core dumps (before things are very messed up if the sp is bad).] In sh`forkshell, just after the fork returns, on the child-process path there is sometimes a messed up sp value by what direction it is from the prior frame-pointers on the stack --and on occasion the value difference is very large, such as: (from: lldb register read on the frame with the pc in sh`forkshell ) fp =3D 0x0000ffffffffce90 sp =3D 0x0000ffffffffe980 This has the sp with a larger address than what sh`__start stored as the frame-pointer back-link when it is put to use via ld-elf.so.1`.rtld_start (more like 0x0000ffffffffde10 as I remember): outside the active stack region. [Note: my experiments so far would not establish if the sp might sometimes have an unexpectedly large distance toward lower memory addresses, specially if it was still in the potential stack-region. It may be that both directions happen.] The distance when it fails is vary variable across examples. I just picked an example were stack frames would be written over the top of other material when sh`forkshell makes other calls on the child-process path, material that would be outside what should be the active stack region. # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 (I've frozen at that version for this exploration. It has taken me a while.) Looking around I see what might be a few possibilities. . . (I'm no expert so some might be trivially eliminated.) Possibility #0 (possibilities in no particular order): sys/arm64/arm64/vm_machdep.c : In cpu_fork what if the bcopy of td1-td_frame might not always have access to the latest updated values, needing some form of memory "fence" to be sure that such values are accessible? : tf =3D (struct trapframe *)STACKALIGN((struct trapframe *)pcb2 - = 1); bcopy(td1->td_frame, tf, sizeof(*tf)); tf->tf_x[0] =3D 0; tf->tf_x[1] =3D 0; tf->tf_spsr =3D 0; td2->td_frame =3D tf; /* Set the return value registers for fork() */ td2->td_pcb->pcb_x[8] =3D (uintptr_t)fork_return; td2->td_pcb->pcb_x[9] =3D (uintptr_t)td2; td2->td_pcb->pcb_x[PCB_LR] =3D (uintptr_t)fork_trampoline; td2->td_pcb->pcb_sp =3D (uintptr_t)td2->td_frame; td2->td_pcb->pcb_fpusaved =3D &td2->td_pcb->pcb_fpustate; td2->td_pcb->pcb_vfpcpu =3D UINT_MAX; /* Setup to release spin count in fork_exit(). */ td2->td_md.md_spinlock_count =3D 1; td2->td_md.md_saved_daif =3D 0; Possibility #1: sys/arm64/arm64/swtch.S : ENTRY(fork_trampoline) . . . /* Restore sp and lr */ ldp x0, x1, [sp] msr sp_el0, x0 mov lr, x1 Similar point to #0 but for the ldp memory accesses shown. Possibility #3: sys/arm64/arm64/exception.S : Both of: handle_el0_sync handle_el0_irq also update sp_el0 and so if any such can happen during any part of fork_trampoline after its "msr sp_el0, x0" but before its "msr daifset, #2" (disabling interrupts), then the wrong sp_el0 value would be in place at fork_tramploine's eret . It will be interesting to see what the problem actually was once it has been fixed. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Feb 12 15:02: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 A25E0CDCACC for ; Sun, 12 Feb 2017 15:02:55 +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 919041778 for ; Sun, 12 Feb 2017 15:02:55 +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 v1CF2tkg097589 for ; Sun, 12 Feb 2017 15:02:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217009] [CI] arm64 is failing to link in libpam/modules/pam_krb5: relocation against symbol `__stack_chk_guard@@FBSD_1.0 Date: Sun, 12 Feb 2017 15:02:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lwhsu@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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: Sun, 12 Feb 2017 15:02:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217009 Li-Wen Hsu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --- Comment #1 from Li-Wen Hsu --- This seems fixed, newer builds back to normal. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Feb 13 02:46: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 7EEE1CDC25C for ; Mon, 13 Feb 2017 02:46:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (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 3341C1AD for ; Mon, 13 Feb 2017 02:46:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22311 invoked from network); 13 Feb 2017 02:48:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Feb 2017 02:48:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Sun, 12 Feb 2017 21:46:52 -0500 (EST) Received: (qmail 30665 invoked from network); 13 Feb 2017 02:46:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Feb 2017 02:46:51 -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 F269EEC7EC3; Sun, 12 Feb 2017 18:46:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: pine64 (an A64 Cortex-A53 context, e.g. -r312982): sh`forkshell child-process path after fork sometimes has a bad stack pointer value From: Mark Millard In-Reply-To: Date: Sun, 12 Feb 2017 18:46:50 -0800 Cc: Tom Vijlbrief , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> References: To: andrew@freebsd.org, Shawn Webb 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: Mon, 13 Feb 2017 02:46:55 -0000 On 2017-Feb-12, at 2:52 AM, Mark Millard wrote: > On pine64 (an A64 Cortex-A53 context) multiple people on the lists > including me have reported sh getting occasional core dumps. >=20 > I've analyzed a bunch of the sh core dumps and all failed in the > child-process path of forkshell when forkshell tried to return.=20 > I've since done experiments with code to detect some forms of > odd stack pointer values so that the adjusted code calls abort > for such a detection before such a return would happen. [This > gives a nicer context to look at in core dumps (before things > are very messed up if the sp is bad).] >=20 > In sh`forkshell, just after the fork returns, on the child-process > path there is sometimes a messed up sp value by what direction > it is from the prior frame-pointers on the stack --and on occasion > the value difference is very large, such as: > (from: lldb register read on the frame with the pc in sh`forkshell ) >=20 > fp =3D 0x0000ffffffffce90 > sp =3D 0x0000ffffffffe980 >=20 > This has the sp with a larger address than what sh`__start > stored as the frame-pointer back-link when it is put to use via > ld-elf.so.1`.rtld_start (more like 0x0000ffffffffde10 as I > remember): outside the active stack region. >=20 > [Note: my experiments so far would not establish if the sp > might sometimes have an unexpectedly large distance toward > lower memory addresses, specially if it was still in the > potential stack-region. It may be that both directions > happen.] >=20 > The distance when it fails is vary variable across examples. > I just picked an example were stack frames would be written > over the top of other material when sh`forkshell makes other > calls on the child-process path, material that would be > outside what should be the active stack region. >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 >=20 > (I've frozen at that version for this exploration. > It has taken me a while.) >=20 > Looking around I see what might be a few possibilities. . . > (I'm no expert so some might be trivially eliminated.) >=20 >=20 > Possibility #0 (possibilities in no particular order): >=20 > sys/arm64/arm64/vm_machdep.c : >=20 > In cpu_fork what if the bcopy of td1-td_frame might not > always have access to the latest updated values, needing > some form of memory "fence" to be sure that such values are > accessible? : >=20 > tf =3D (struct trapframe *)STACKALIGN((struct trapframe *)pcb2 = - 1); > bcopy(td1->td_frame, tf, sizeof(*tf)); > tf->tf_x[0] =3D 0; > tf->tf_x[1] =3D 0; > tf->tf_spsr =3D 0; >=20 > td2->td_frame =3D tf; >=20 > /* Set the return value registers for fork() */ > td2->td_pcb->pcb_x[8] =3D (uintptr_t)fork_return; > td2->td_pcb->pcb_x[9] =3D (uintptr_t)td2; > td2->td_pcb->pcb_x[PCB_LR] =3D (uintptr_t)fork_trampoline; > td2->td_pcb->pcb_sp =3D (uintptr_t)td2->td_frame; > td2->td_pcb->pcb_fpusaved =3D &td2->td_pcb->pcb_fpustate; > td2->td_pcb->pcb_vfpcpu =3D UINT_MAX; >=20 > /* Setup to release spin count in fork_exit(). */ > td2->td_md.md_spinlock_count =3D 1; > td2->td_md.md_saved_daif =3D 0; >=20 >=20 > Possibility #1: >=20 > sys/arm64/arm64/swtch.S : >=20 > ENTRY(fork_trampoline) > . . . > /* Restore sp and lr */ > ldp x0, x1, [sp] > msr sp_el0, x0 > mov lr, x1 >=20 > Similar point to #0 but for the ldp memory accesses > shown. >=20 >=20 > Possibility #3: >=20 > sys/arm64/arm64/exception.S : >=20 > Both of: >=20 > handle_el0_sync > handle_el0_irq >=20 > also update sp_el0 and so if any such can happen > during any part of fork_trampoline after its > "msr sp_el0, x0" but before its "msr daifset, #2" > (disabling interrupts), then the wrong sp_el0 value > would be in place at fork_tramploine's eret . >=20 >=20 > It will be interesting to see what the problem actually > was once it has been fixed. I have updated to a test that should report any time fork changes the stack pointer from what it was before the fork, parent or child process: # svnlite diff /usr/src/bin/sh/miscbltin.c /usr/src/bin/sh/jobs.c Index: /usr/src/bin/sh/miscbltin.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/bin/sh/miscbltin.c (revision 312982) +++ /usr/src/bin/sh/miscbltin.c (working copy) @@ -64,6 +64,15 @@ =20 #undef eflag =20 + +/* JUST FOR TESTING */ +uintptr_t example_stack_address(void) +{ + volatile uintptr_t test =3D 0; + return (uintptr_t)(void*)&test; +} + + int readcmd(int, char **); int umaskcmd(int, char **); int ulimitcmd(int, char **); Index: /usr/src/bin/sh/jobs.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/bin/sh/jobs.c (revision 312982) +++ /usr/src/bin/sh/jobs.c (working copy) @@ -51,6 +51,9 @@ #include #include =20 +/* JUST FOR TESTING */ +#include + #include "shell.h" #if JOBS #include @@ -833,6 +836,11 @@ * in a pipeline). */ =20 +extern uintptr_t example_stack_address(void); + +uintptr_t stack_address_before_fork =3D 0; +uintptr_t stack_address_after_fork =3D 0; + pid_t forkshell(struct job *jp, union node *n, int mode) { @@ -845,7 +853,10 @@ if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) checkzombies(); flushall(); + stack_address_before_fork =3D example_stack_address(); pid =3D fork(); + stack_address_after_fork =3D example_stack_address(); + if (stack_address_after_fork !=3D stack_address_before_fork) = abort(); if (pid =3D=3D -1) { TRACE(("Fork failed, errno=3D%d\n", errno)); INTON; @@ -946,7 +957,6 @@ return pid; } =20 - pid_t vforkexecshell(struct job *jp, char **argv, char **envp, const char = *path, int idx, int pip[2]) { I've been using repeated attempts to build devel/aarch64-none-elf-gcc for testing because the configure activity does lots of shell work that forks. (I first noticed the problem in such a context.) The first example core file from repeated attempts to build devel/aarch64-none-elf-gcc with this new test shows: (lldb) bt * thread #1: tid =3D 100188, 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: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a350c0 x21 =3D 0x0000000000000002 x22 =3D 0x0000000040a49898 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x00000000000000fb x26 =3D 0x0000000040a49b90 x27 =3D 0x0000000040a49918 x28 =3D 0x0000000000434000 sh..bss + 6336 fp =3D 0x0000ffffffffcee0 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffd180 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $0 =3D 0x0000ffffffffce80 (lldb) print/x stack_address_after_fork (uintptr_t) $1 =3D 0x0000ffffffffd160 (lldb) print/x main_handler (jmploc) $2 =3D { loc =3D { [0] =3D { _jb =3D { [0] =3D 0x0000ffffffffdb60fb5d25837d7ff700 [1] =3D 0x00000000000000170000ffffffffdc08 [2] =3D 0x00000000004320380000000000434a10 [3] =3D 0x00000000000000000000000000000000 [4] =3D 0x00000000000000000000000000000000 [5] =3D 0x00000000000000000000000000000000 [6] =3D 0x0000000000410c800000ffffffffdbb0 . . . (main_handler is from setjmp in main.) In this example of the context for sh`forkshell after the fork: fp =3D 0x0000ffffffffcee0 < sp =3D 0x0000ffffffffd180 < = 0x0000ffffffffdbb0 That explains why the bt stopped with frame #3: part of the stack had been trashed by the calls to example_stack_address and to abort (and what its internal call chain involves), unlike the prior example that trashed memory outside the active stack region. Compared to the prior example's sp =3D 0x0000ffffffffe980 the distance from the frame pointer in sh`forkshell is much smaller this time --but it is still in the same (wrong) direction. This illustrates the variability in the bad sp value from bad-case to bad-case. I plan to leave the repeated builds running for a time to accumulate some more core files based on this new test. If any examples happen of sp decreasing instead of increasing, the code should core dump for those as well, unlike my prior testing. Context details: # 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 The -r312982 variant is a cross build with -mcpu=3Dcortex-a53 specified: # more ~/src.configs/src.conf.pine64-clang-bootstrap.amd64-host=20 TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ XCFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} XCXXFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. In order to cut down on the Spurious interrupt notices on the console I eventually did the below personal adjustment specific to my context (and it is in use above): # 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); } The added message block was to report unexpected values for the exit path. None have been reported from there. The gic.c changes eliminated all the Spurious interrupt notices --which made the console more reasonable to use. But so far I've not come up with a way to discover what leads to the irq=3D=3D1023 reports for the original message context. [Interrupts handled by one core but sent to multiple cores?] Other notes: I switched to Andrew Turner's freebsd Email address. It might be more appropriate. I also fixed the mistyped "Contex-a53" in the Subject to say "Cortex-a53". =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Feb 13 05:42:27 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 A7B6FCDCC4B for ; Mon, 13 Feb 2017 05:42:27 +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 7CF531067 for ; Mon, 13 Feb 2017 05:42:27 +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=0/pf4ZfrTGYxUednJ4/TjO9snei/5IDjpISSMO/fFXs=; b=ARJsemSdpq9VMWYXNBXjuRl8ZQV1INQxYw45sq33p8bUK8RDJ83WaiDMisHQLRE2izQJsf0bEEZS8NMmcCZo5T5avdDemyiZGAyPWsn//JHgv74O5MJ1czI3/TSZeK0EKh2+69MLQYVZN/TRxMzY19fBwXTTodB6Eo6gRFQdQVyvNIv9; 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 1cd9Or-000E2e-7K; Sun, 12 Feb 2017 21:42:25 -0800 From: "Tony Hain" To: "'Oleksandr Tymoshenko'" Cc: References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> <20170211201140.GA66049@bluezbox.com> In-Reply-To: <20170211201140.GA66049@bluezbox.com> Date: Sun, 12 Feb 2017 21:42:09 -0800 Message-ID: <0fdf01d285bb$eb15f8f0$c141ead0$@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: AQCzikkuUoxhpHAkDcVcrtsdCslcNQH9hJ4TAXN5MpwC2JJLtaNyFmVA 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: Mon, 13 Feb 2017 05:42:27 -0000 > -----Original Message----- > From: Oleksandr Tymoshenko [mailto:gonzo@bluezbox.com] > Sent: Saturday, February 11, 2017 12:12 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: > > > -----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. Please forgive the oversight. I haven't seen anyone use hard links for 30 years, so that didn't even occur to me. Tony > > -- > gonzo From owner-freebsd-arm@freebsd.org Mon Feb 13 07:01: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 4CAAFCDCD3E for ; Mon, 13 Feb 2017 07:01:42 +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 280A2E50; Mon, 13 Feb 2017 07:01:42 +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=XnMYR/mqA8I1OW0RUsjru0NJRepy9WV+PkcCDj4VRr4=; b=AsI8Ef8RpZDqhvc+U36tDUG3qgC+j9EgRLYfuC3rWhOXKkYQyGaIPKTpUAsiCVaK7XXzTnhLjyOOg9Ct1xSMjS9YYEvxqhsqEsxJTVCZTYgBeuEw9FC0bNl3xmYaOuDNS/DRNLxjCXqiClr43eqCL6oofyUVzWdDWDZhUjfTUI+SmB8i; 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 1cdAdi-000FIM-04; Sun, 12 Feb 2017 23:01:40 -0800 From: "Tony Hain" To: "'Ian Lepore'" , "'Oleksandr Tymoshenko'" Cc: References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> <1486841770.10020.287.camel@freebsd.org> In-Reply-To: <1486841770.10020.287.camel@freebsd.org> Date: Sun, 12 Feb 2017 23:01:34 -0800 Message-ID: <0fe001d285c7$032c32a0$098497e0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCzikkuUoxhpHAkDcVcrtsdCslcNQH9hJ4TAXN5MpwBwWtU/aN60AuA 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: Mon, 13 Feb 2017 07:01:42 -0000 > -----Original Message----- > From: Ian Lepore [mailto:ian@freebsd.org] > Sent: Saturday, February 11, 2017 11:36 AM > To: Tony Hain; 'Oleksandr Tymoshenko' > Cc: freebsd-arm@freebsd.org > Subject: Re: Questions about BBB/BBG dtb names vs. content >=20 > 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 >=20 > There is not necessarily any relationship between dts/dtb filenames = and > =A0any compat strings within the dtb. =A0The compat strings are = defined by the > bindings documentation, and are essentially a contract between the dts > source and the device driver source. =A0The filenames are a separate contract, > mostly between vendors and the u-boot source, but even those don't = have > to agree. >=20 > 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. =A0(At least until overlay support settles down and finds its = way into > freebsd.) So how would I get crochet to build that dtb? As far as I can tell I = need to add an include line in the black file, including the compatible for = green, because I can't follow the sequence that actually builds the dts = initially. I did put together a dts for all 6 uarts, because it was a pita to find = and correlate the references which are not collected as a complete set = anywhere as far as I can tell. I offer it here for contrib if it is useful for = the short term, or for the dtbo effort. I am running crochet now, so I am = not positive this works yet, but it should be close. /* am335x-bone-uarts.dts * * BeagleBone Green / Black - All 6 uarts defined : * this was difficult to find as the SRM doesn't include the address offset, * and example dts files found by search were incomplete, many = with incorrect offsets * eventually tripped over address offset P8/9 maps at: * http://www.siue.edu/~gengel/bbbWebStuff/BeagleboneBlackP8HeaderTable.pdf * http://www.siue.edu/~gengel/bbbWebStuff/BeagleboneBlackP9HeaderTable.pdf * coorelated with 335x pin map at * http://www.ti.com/lit/ds/symlink/am3359.pdf zcz ball number matches above tables * * compiled by Tony Hain - 2/12/17 * * modify comment markers below to enable/disable required uarts * * add #include "am335x-bone-uarts.dts" to board dts */ /dts-v1/; / { model =3D "TI AM335x BeagleBone Green"; compatible =3D "ti,am335x-bone-green", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; }; &am33xx_pinmux { uart0_pins: uart0_pins { pinctrl-single,pins =3D < /* Addr offset | Direction | MuxMode | Connector | Proc = pin | SignalName | Conflict */ AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0) /* J1_4 E15 uart0_rxd */ AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* J1_5 E16 uart0_txd */ // AM33XX_IOPAD(0x978, PIN_OUTPUT | MUX_MODE5) /* P9_20 = D18 uart0_ctsn ! uart1_cts*/ // AM33XX_IOPAD(0x97c, PIN_INPUT | MUX_MODE5) /* P9_19 = D17 uart0_rtsn ! uart1_rts*/ >; }; uart1_pins: uart1_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x980, PIN_INPUT | MUX_MODE0) /* P9_26 = D16 uart1_rxd */ AM33XX_IOPAD(0x984, PIN_INPUT | MUX_MODE0) /* P9_24 = D15 uart1_txd */ // AM33XX_IOPAD(0x978, PIN_INPUT_PULLDOWN | MUX_MODE0) /* P9_20 = D18 uart1_ctsn ! uart0_cts*/ // AM33XX_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* P9_19 = D17 uart1_rtsn ! uart0_rts*/ // AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5) /* No_pin = G16 uart1_ri */ // AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5) /* No_pin = K18 uart1_dcd */ // AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5) /* No_pin = L18 uart1_dsr */ // AM33XX_IOPAD(0xXxx, PIN_OUTPUT_PULLDOWN | MUX_MODE5) /* No_pin = L17 uart1_dtr */ >; }; uart2_pins: uart2_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE1) /* P9_22 = A17 uart2_rxd */ AM33XX_IOPAD(0x954, PIN_OUTPUT | MUX_MODE1) /* P9_21 = B17 uart2_txd */ // AM33XX_IOPAD(0x8c0, PIN_INPUT_PULLDOWN | MUX_MODE6) /* P8_37 U1 uart2_ctsn ! uart5_txd*/ // AM33XX_IOPAD(0x8b8, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* P8_38 U2 uart2_rtsn ! uart5_rxd*/ >; }; uart3_pins: uart3_pins { pinctrl-single,pins =3D < // AM33XX_IOPAD(0xXxx, PIN_INPUT | MUX_MODE1) /* No_pin = C15 uart3_rxd ! hdmi */ AM33XX_IOPAD(0x964, PIN_OUTPUT_PULLUP | MUX_MODE1) /* P9_42 = C18 uart3_txd */ // AM33XX_IOPAD(0x8c8, PIN_INPUT_PULLUP | MUX_MODE6) /* P8_36 U3 uart3_ctsn */ // AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE6) /* P8_34 U4 uart3_rtsn */ >; }; uart4_pins: uart4_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x870, PIN_INPUT_PULLUP | MUX_MODE6) /* P9_11 = T17 uart4_rxd */ AM33XX_IOPAD(0x874, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* P9_13 = U17 uart4_txd */ // AM33XX_IOPAD(0x8d0, PIN_INPUT_PULLUP | MUX_MODE6) /* P8_35 V2 uart4_ctsn */ // AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE6) /* P8_33 V3 uart4_rtsn */ >; }; uart5_pins: uart5_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x8c4, PIN_INPUT | MUX_MODE4) /* P8_38 U2 uart5_rxd ! uart2_rts*/ AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE4) /* P8_37 U1 uart5_txd ! uart2_cts*/ // AM33XX_IOPAD(0x8d8, PIN_INPUT_PULLUP | MUX_MODE6) /* P8_31 V4 uart5_ctsn */ // AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE6) /* P8_32 T5 uart5_rtsn */ >; }; }; &uart0 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart0_pins>; status =3D "okay"; // status =3D "disabled"; }; &uart1 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart1_pins>; status =3D "okay"; // status =3D "disabled"; }; &uart2 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart2_pins>; // status =3D "okay"; status =3D "disabled"; }; &uart3 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart3_pins>; // status =3D "okay"; status =3D "disabled"; }; &uart4 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart4_pins>; // status =3D "okay"; status =3D "disabled"; }; &uart5 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart5_pins>; // status =3D "okay"; status =3D "disabled"; }; From owner-freebsd-arm@freebsd.org Mon Feb 13 08:27:41 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 283D9CDC815 for ; Mon, 13 Feb 2017 08:27:41 +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 CDFC51B7A; Mon, 13 Feb 2017 08:27:39 +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 87A0B3760C51; Mon, 13 Feb 2017 09:26:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 789903760C58; Mon, 13 Feb 2017 09:26:40 +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 gNa5HxvGZ8gM; Mon, 13 Feb 2017 09:26:40 +0100 (CET) Received: from pc-alex.localnet (fwlabo.stormshield.eu [10.2.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 4E3BC3760C51; Mon, 13 Feb 2017 09:26:40 +0100 (CET) From: Alexandre Martins To: Mark Millard Cc: freebsd-arm , Ian Lepore Subject: Re: bcopy/memmove optimization broken ? [looks like you are correct to me, I give supporting detail] Date: Mon, 13 Feb 2017 09:28:31 +0100 Message-ID: <7424243.zp5tqGREgJ@pc-alex> Organization: STORMSHIELD User-Agent: KMail/4.14.10 (FreeBSD/10.3-RELEASE-p7; KDE/4.14.10; amd64; ; ) In-Reply-To: <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> References: <5335118.oK1KXXDaG5@pc-alex> <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2442143.bXjVvZE6mh"; 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: Mon, 13 Feb 2017 08:27:41 -0000 --nextPart2442143.bXjVvZE6mh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Le vendredi 10 f=E9vrier 2017, 18:11:23 Mark Millard a =E9crit : > 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 co= pied > > region don't overlap: > >=20 > > https://svnweb.freebsd.org/base/head/sys/arm/arm/support.S?view=3Da= nnotate#l > > 403 > >=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 > I did not expect something so central that has been > around so long to look wrong but. . . >=20 > Going through the supporting details of the original > code based on my looking around here is what I found: >=20 > #include=09 > void *memmove(void *dest, const void *src, size_t n); >=20 > So I'd expect (c'ish notation): > r0=3D=3Ddest > r1=3D=3Dsrc > r2=3D=3Dn >=20 > Then for (the comments vs. code is being challenged): > (The comments do seem to give the intent correctly.) >=20 > 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) > . . . >=20 > cmp r0,r1 should result in condition code (c'ish notation): >=20 > eq=3D(r0=3D=3Dr1) > cc=3D(r0 cs=3D(r0>=3Dr1) >=20 > (Only the r0 position has no immediate-value alternative.) >=20 >=20 > subcc r3,r0,r1 is: if (cc) r3=3Dr0-r1 // no condition code change > In other words: if (dst=20 > 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 negative for dst-src. For > non-negative arithmetic (natural or whole): undefined. >=20 >=20 > subcs r3,r1,r0 is: if (cs) r3=3Dr1-r0 // no condition code change > In other words: if (dst>=3Dsrc) r3=3Dsrc-dst >=20 > 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. >=20 >=20 > 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. >=20 > 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. >=20 > Your code change would have the right summary and use only > normal mathematical rules from what I can tell: >=20 > 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) > . . . >=20 > 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. >=20 > subcc r3,r1,r0 is: if (cc) r3=3Dr1-r0 // no condition code change > In other words: if (dst And that matches the comments and would produce a positive result > for r3, matching the normal mathematical result. >=20 > Overall summary of the two updated sub?? instructions: > r3=3Dabs(dst-src), given dst!=3Dsrc. >=20 > And that would make for an appropriate comparison to n (i.e., to r2).= >=20 > It appears to have been as it is now since -r143175 when memmove was > added to sys/arm/arm/support.S (2005-Apr-12). >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net Thank you for this deep anaysis ! I also made some benchmark. It seems that the "Xscale" version of=20 memcpy/memmove is slower that the standard "ARM" on my platform (armada= 388). I do the change by undefine the _ARM_ARCH_5E. #define _ARM_ARCH_5E =3D> Xscale version #undef _ARM_ARCH_5E =3D> "ARM" version There is my results: Block size: 2048 memcpy (Kernel ARM) : 1028.7 MB/s memmove (Kernel ARM) : 616.5 MB/s memcpy (Kernel xscale) : 920.1 MB/s memmove (Kernel xscale) : 618.8 MB/s Block size: 128 memcpy (Kernel ARM) : 1018.5 MB/s memmove (Kernel ARM) : 668.4 MB/s memcpy (Kernel xscale) : 825.9 MB/s memmove (Kernel xscale) : 668.6 MB/s Block size: 64 memcpy (Kernel ARM) : 892.9 MB/s memmove (Kernel ARM) : 667.2 MB/s memcpy (Kernel xscale) : 721.2 MB/s memmove (Kernel xscale) : 668.2 MB/s Block size: 32 memcpy (Kernel ARM) : 620.6 MB/s memmove (Kernel ARM) : 634.6 MB/s memcpy (Kernel xscale) : 504.9 MB/s memmove (Kernel xscale) : 634.5 MB/s Block size; 16 memcpy (Kernel ARM) : 471.8 MB/s memmove (Kernel ARM) : 464.5 MB/s memcpy (Kernel xscale) : 254.5 MB/s memmove (Kernel xscale) : 464.7 MB/s As you can see, more the size of the memcpy is small, more the standard= (ARM)=20 version of memcpy is faster. In addition, the libc version suffer the same problem, but is 15% more = efficiant. What can I do to help you on this point ? Best regards =2D-=20 Alexandre Martins STORMSHIELD --nextPart2442143.bXjVvZE6mh 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTMwODI4MzFaMCgGCSqG SIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCBPtmZr zlzEZ1n86lp3L69T+qUFzB/lFpNI6DhE+cRMDjANBgkqhkiG9w0BAQEFAASCAQCEf5zQhj1rSPh0 ORcAe9GoYYGyXP0538OLfHfiWGFX2AuUTtka3zxkperwctKhl6pUwrDGPs3XqQWwwYRywk0RZL+s 1haTlNsJSsLLOqZVVKPdsd3jC0Me/As5pfOvQ6TReVvVfGbk3KxWyevWO7ClGEfpt+9PstxI9ggi iZ1kyB3FlrcrcVCIpY4QGrrIk42S93Hi49+t7QKjaRq+1rKALsQombtsJsWPfxiOAxKLVdQTdiJ0 rfDRvhD87ljsfwLuMCNih1rnvTNDTZwZwu5feGMDJFPGfvTtqAJC6H0hM8ohM/dznnMFc6stlIq6 m8/Oy805sXn9uEtVSGR1+rdrAAAAAAAA --nextPart2442143.bXjVvZE6mh-- From owner-freebsd-arm@freebsd.org Mon Feb 13 09:27: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 CE5CECDD88A for ; Mon, 13 Feb 2017 09:27:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (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 8F60C17A8 for ; Mon, 13 Feb 2017 09:27:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20911 invoked from network); 13 Feb 2017 09:27:18 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Feb 2017 09:27:18 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Mon, 13 Feb 2017 04:27:18 -0500 (EST) Received: (qmail 22101 invoked from network); 13 Feb 2017 09:27:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Feb 2017 09:27: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 65E98EC7B39; Mon, 13 Feb 2017 01:27:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 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: <7424243.zp5tqGREgJ@pc-alex> Date: Mon, 13 Feb 2017 01:27:16 -0800 Cc: freebsd-arm , Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <8E5F8A15-2F79-4015-B93B-975D27308782@dsl-only.net> References: <5335118.oK1KXXDaG5@pc-alex> <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> <7424243.zp5tqGREgJ@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: Mon, 13 Feb 2017 09:27:20 -0000 On 2017-Feb-13, at 12:28 AM, Alexandre Martins wrote: > Le vendredi 10 f=C3=A9vrier 2017, 18:11:23 Mark Millard a =C3=A9crit : >> On 2017-Feb-10, at 7:51 AM, Alexandre Martins stormshield.eu> wrote: >>> Hi all >>>=20 >>> I see in the kernel code of bcopy/memmove an optimization if the = copied >>> region don't overlap: >>>=20 >>> = https://svnweb.freebsd.org/base/head/sys/arm/arm/support.S?view=3Dannotate= #l >>> 403 >>>=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 >> I did not expect something so central that has been >> around so long to look wrong but. . . >>=20 >> Going through the supporting details of the original >> code based on my looking around here is what I found: >>=20 >> #include >> void *memmove(void *dest, const void *src, size_t n); >>=20 >> So I'd expect (c'ish notation): >> r0=3D=3Ddest >> r1=3D=3Dsrc >> r2=3D=3Dn >>=20 >> Then for (the comments vs. code is being challenged): >> (The comments do seem to give the intent correctly.) >>=20 >> 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) >> . . . >>=20 >> cmp r0,r1 should result in condition code (c'ish notation): >>=20 >> eq=3D(r0=3D=3Dr1) >> cc=3D(r0> cs=3D(r0>=3Dr1) >>=20 >> (Only the r0 position has no immediate-value alternative.) >>=20 >>=20 >> subcc r3,r0,r1 is: if (cc) r3=3Dr0-r1 // no condition code change >> In other words: if (dst>=20 >> 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 negative for dst-src. For >> non-negative arithmetic (natural or whole): undefined. >>=20 >>=20 >> subcs r3,r1,r0 is: if (cs) r3=3Dr1-r0 // no condition code change >> In other words: if (dst>=3Dsrc) r3=3Dsrc-dst >>=20 >> 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. >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> Your code change would have the right summary and use only >> normal mathematical rules from what I can tell: >>=20 >> 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) >> . . . >>=20 >> 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. >>=20 >> subcc r3,r1,r0 is: if (cc) r3=3Dr1-r0 // no condition code change >> In other words: if (dst> And that matches the comments and would produce a positive result >> for r3, matching the normal mathematical result. >>=20 >> Overall summary of the two updated sub?? instructions: >> r3=3Dabs(dst-src), given dst!=3Dsrc. >>=20 >> And that would make for an appropriate comparison to n (i.e., to r2). >>=20 >> It appears to have been as it is now since -r143175 when memmove was >> added to sys/arm/arm/support.S (2005-Apr-12). >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 >=20 >=20 > Thank you for this deep anaysis ! >=20 > I also made some benchmark. It seems that the "Xscale" version of=20 > memcpy/memmove is slower that the standard "ARM" on my platform = (armada388). >=20 > I do the change by undefine the _ARM_ARCH_5E. > #define _ARM_ARCH_5E =3D> Xscale version > #undef _ARM_ARCH_5E =3D> "ARM" version >=20 > There is my results: >=20 > Block size: 2048 > memcpy (Kernel ARM) : 1028.7 MB/s > memmove (Kernel ARM) : 616.5 MB/s > memcpy (Kernel xscale) : 920.1 MB/s > memmove (Kernel xscale) : 618.8 MB/s >=20 > Block size: 128 > memcpy (Kernel ARM) : 1018.5 MB/s > memmove (Kernel ARM) : 668.4 MB/s > memcpy (Kernel xscale) : 825.9 MB/s > memmove (Kernel xscale) : 668.6 MB/s >=20 > Block size: 64 > memcpy (Kernel ARM) : 892.9 MB/s > memmove (Kernel ARM) : 667.2 MB/s > memcpy (Kernel xscale) : 721.2 MB/s > memmove (Kernel xscale) : 668.2 MB/s >=20 > Block size: 32 > memcpy (Kernel ARM) : 620.6 MB/s > memmove (Kernel ARM) : 634.6 MB/s > memcpy (Kernel xscale) : 504.9 MB/s > memmove (Kernel xscale) : 634.5 MB/s >=20 > Block size; 16 > memcpy (Kernel ARM) : 471.8 MB/s > memmove (Kernel ARM) : 464.5 MB/s > memcpy (Kernel xscale) : 254.5 MB/s > memmove (Kernel xscale) : 464.7 MB/s >=20 > As you can see, more the size of the memcpy is small, more the = standard (ARM)=20 > version of memcpy is faster. >=20 > In addition, the libc version suffer the same problem, but is 15% more = efficiant. >=20 > What can I do to help you on this point ? >=20 > Best regards > --=20 > Alexandre Martins > STORMSHIELD I recommend submitting your original discovery to bugzilla: https://bugs.freebsd.org/bugzilla/enter_bug.cgi I can submit the original find if you are not going to. (I would likely not submit a benchmark report since I have not done such benchmarking or analysis producing expected-performance estimates.) I'm not a FreeBSD committer, nor an arm expert. I'm not working on such issues as such. I just decided to look-up/study enough material to confirm or deny what you had written, in part because the notation looked like it could be easy to get the condition code suffixes and argument order mismatched for sub??. (An alternate fix is to reverse the operands in the two sub?? commands but leave the cc and cs as they are --but then the comments would also need to be updated track.) I had added Ian L. as a CC: because he is knowledgable, active, and a committer. If I messed up in my studying the material he would likely catch my mistakes. If you (and my confirmation) are right then he likely could fix the code in svn as well. As the decision about when to call the code that can deal with overlapping memory regions is wrong, the code that should only be used for non-overlaping regions likely would handle some overlapping regions and so would operate incorrectly in at least some cases. In other words, I think the bug is worse than just an example of being sub-optimal: the code is wrong from what I can tell. (I've no clue if the code is ever put to use for any bad cases.) It is true that for the non-overlapping cases that are sent to the more general, slower overlap-handling-capable code the results would likely be worse than for the code designed for non-overlapping-only. As your your benchmarks: I'm not sure if you benchmarked the original code vs. your corrected code. The corrected code would be the most intersting (presuming you [and my confirmation] are correct). If you submit to bugzilla, I'd suggest any benchmark reports be submitted separately from the original issue with the sub?? instructions. The 32-bit arm's that I have access to are both Cortex-A7 based: a BPI-M3 and an RPI2, so armv7. I've not tried such benchmarking on them. And I'm not likely to, at least not any time soon. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Feb 13 10:51: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 7203ACDCD15 for ; Mon, 13 Feb 2017 10:51:06 +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 6225B27C for ; Mon, 13 Feb 2017 10:51:06 +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 v1DAp6Df097013 for ; Mon, 13 Feb 2017 10:51:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217065] Memmove / bcopy optimization bug Date: Mon, 13 Feb 2017 10:51:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: alexandre.martins@stormshield.eu 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: Mon, 13 Feb 2017 10:51:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217065 Bug ID: 217065 Summary: Memmove / bcopy optimization bug Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: alexandre.martins@stormshield.eu Hello, During the optimization phase of our project on an Armada 380, I have see t= hat an optimization on bcopy/memmove is broken. https://svnweb.freebsd.org/base/head/sys/arm/arm/support.S?view=3Dannotate#= l403 The condition on the following line are reserved: > 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) Should be: > 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) This code may produce bugs if an unlikely copy of more that 2Gb is done (I don't see how). I have already reported that on the mailling list: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D462567+0+archive/2017/freeb= sd-arm/20170212.freebsd-arm Best regards, Alexandre Martins --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Feb 13 13:23:27 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 8F15BCDBCA4 for ; Mon, 13 Feb 2017 13:23:27 +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 638DA1D56 for ; Mon, 13 Feb 2017 13:23:27 +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 v1DDNRmx034530 for ; Mon, 13 Feb 2017 13:23:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217069] Performance: memcpy slower in Xscale vs ARM Date: Mon, 13 Feb 2017 13:23:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: alexandre.martins@stormshield.eu 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: Mon, 13 Feb 2017 13:23:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217069 Bug ID: 217069 Summary: Performance: memcpy slower in Xscale vs ARM Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: alexandre.martins@stormshield.eu Hello, During the development for our new platform, armada380 based, I see that the "standard" version of memmove/memcpy is faster than the "xscale" one. For that, I just remove the _ARM_ARCH_5E define into the file sys/arm/arm/support.S. There is the results: Block size: 2048 memcpy (Kernel ARM) : 1028.7 MB/s memmove (Kernel ARM) : 616.5 MB/s memcpy (Kernel xscale) : 920.1 MB/s memmove (Kernel xscale) : 618.8 MB/s Block size: 128 memcpy (Kernel ARM) : 1018.5 MB/s memmove (Kernel ARM) : 668.4 MB/s memcpy (Kernel xscale) : 825.9 MB/s memmove (Kernel xscale) : 668.6 MB/s Block size: 64 memcpy (Kernel ARM) : 892.9 MB/s memmove (Kernel ARM) : 667.2 MB/s memcpy (Kernel xscale) : 721.2 MB/s memmove (Kernel xscale) : 668.2 MB/s Block size: 32 memcpy (Kernel ARM) : 620.6 MB/s memmove (Kernel ARM) : 634.6 MB/s memcpy (Kernel xscale) : 504.9 MB/s memmove (Kernel xscale) : 634.5 MB/s Block size: 16 memcpy (Kernel ARM) : 471.8 MB/s memmove (Kernel ARM) : 464.5 MB/s memcpy (Kernel xscale) : 254.5 MB/s memmove (Kernel xscale) : 464.7 MB/s Please note that the userland suffer the same problem, and the standard "AR= M" is a little bit more efficient. I'm available to test any point you want. Best regards Alexandre Martins --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Feb 13 14:04: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 F1587CDD9E9 for ; Mon, 13 Feb 2017 14:04:05 +0000 (UTC) (envelope-from freebook@partyman.se) Received: from mail05.trekia.se (mail05.trekia.se [79.99.4.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glesys.se", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9DD717D9 for ; Mon, 13 Feb 2017 14:04:05 +0000 (UTC) (envelope-from freebook@partyman.se) Received: by mail05.trekia.se (Postfix, from userid 666) id 6316D6E80FEB; Mon, 13 Feb 2017 14:56:34 +0100 (CET) From: freebook@partyman.se Precedence: junk Auto-Submitted: auto-replied To: References: <148699410807.5136.16834074155968718950@hinet.net> In-Reply-To: <148699410807.5136.16834074155968718950@hinet.net> Subject: Re: 31360 freebook Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset="US-ASCII" Content-Transfer-Encoding: 8bit Message-Id: <20170213135634.6316D6E80FEB@mail05.trekia.se> Date: Mon, 13 Feb 2017 14:56:34 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:04:06 -0000 freebsd-arm@freebsd.org writes: Free book about activated carbon For a free book about activated carbon please go to http://books24-7.com/ There are also some more great eBooks completely free as well as printed books that are for sale. Kindest regards books24-7.com From owner-freebsd-arm@freebsd.org Mon Feb 13 16:17: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 30B36CDD284 for ; Mon, 13 Feb 2017 16:17:56 +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 D9DB71142 for ; Mon, 13 Feb 2017 16:17:54 +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 8A5863761957 for ; Mon, 13 Feb 2017 17:16:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 7E1113761DDD for ; Mon, 13 Feb 2017 17:16:58 +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 06f1qWL9b1VX for ; Mon, 13 Feb 2017 17:16:58 +0100 (CET) Received: from pc-alex.localnet (fwlabo.stormshield.eu [10.2.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 601D73761961 for ; Mon, 13 Feb 2017 17:16:58 +0100 (CET) From: Alexandre Martins To: freebsd-arm@freebsd.org Subject: Dead (funny) code Date: Mon, 13 Feb 2017 17:18:49 +0100 Message-ID: <8144520.k7BAz0bq1H@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="nextPart2961624.pOHle5vaoQ"; 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: Mon, 13 Feb 2017 16:17:56 -0000 --nextPart2961624.pOHle5vaoQ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hello, I continue my review and I see some strange piece of code. I suspect it= to be=20 a debug piece that was forget: https://svnweb.freebsd.org/base/head/sys/arm/arm/cpufunc_asm.S?view=3Da= nnotate#l127 .Lglou: =09=09.asciz "plop %p\n" =09=09.align 2 It's pretty funny, and I wanted to share that with you :) =2D-=20 Alexandre Martins STORMSHIELD --nextPart2961624.pOHle5vaoQ 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTMxNjE4NDlaMCgGCSqG SIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCBDsJT2 bCTGOZ0uBqdeQE8QAlJdIX0X7JAA/nQyqjviUDANBgkqhkiG9w0BAQEFAASCAQCm6UdiXqH03KmV wMH4pcQQcYKMYw1bSVPnZSiTrYTKavCfwQoXwDyBQPZJ7R67MfZxNf6LnVPnbgJsUyIHIxGC1zM9 L9LNytoD9PfX5JocjntDGi7oKyHCNhN5ny3n7BaLNqg/HH8hmi/C2CZucPpzpp6NcDVtJAauHopu s5EfYZRFe2nCDxLT0HGYZY9jiN5kn6fk4HDAhKgiAMg1jYPclWVcbzZREdSr1NhQayFxerPRUgSq +pDVREwJCfDKzbCfExa/wFbF6bmTSz0QvOsNrRMYZ/Rb3HnpLQ6Qm4pbVULeXKFhn/inzev/k2ie RbOBQ01h+GlQiIkGDWitFf7OAAAAAAAA --nextPart2961624.pOHle5vaoQ-- From owner-freebsd-arm@freebsd.org Mon Feb 13 16:39:09 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 935E5CDD78C for ; Mon, 13 Feb 2017 16:39:09 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4145F1E4A for ; Mon, 13 Feb 2017 16:39:09 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.9/8.14.8) with ESMTP id v1DGd3M7046912; Mon, 13 Feb 2017 17:39:03 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.9/8.14.8/Submit) id v1DGd3LX046911; Mon, 13 Feb 2017 17:39:03 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 13 Feb 2017 17:39:03 +0100 From: Olivier Houchard To: Alexandre Martins Cc: freebsd-arm@freebsd.org Subject: Re: Dead (funny) code Message-ID: <20170213163903.GA46877@ci0.org> References: <8144520.k7BAz0bq1H@pc-alex> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8144520.k7BAz0bq1H@pc-alex> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 13 Feb 2017 16:39:09 -0000 On Mon, Feb 13, 2017 at 05:18:49PM +0100, Alexandre Martins wrote: > Hello, > > I continue my review and I see some strange piece of code. I suspect it to be > a debug piece that was forget: > > https://svnweb.freebsd.org/base/head/sys/arm/arm/cpufunc_asm.S?view=annotate#l127 > > > .Lglou: > .asciz "plop %p\n" > .align 2 > > > It's pretty funny, and I wanted to share that with you :) > Oh man, I'm responsible for this, it's probably been there since very early in the arm part. I guess it's time to let it go, thanks for reporting :) Olivier From owner-freebsd-arm@freebsd.org Mon Feb 13 16:56:51 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 13E1BCDDD65 for ; Mon, 13 Feb 2017 16:56:51 +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 E97F8E2F for ; Mon, 13 Feb 2017 16:56:50 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6e55dd3e-f20d-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 6e55dd3e-f20d-11e6-ba57-8bc134ee460a; Mon, 13 Feb 2017 16:56:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1DGuetj005747; Mon, 13 Feb 2017 09:56:40 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1487005000.10020.292.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: Mon, 13 Feb 2017 09:56:40 -0700 In-Reply-To: <0fe001d285c7$032c32a0$098497e0$@tndh.net> References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> <1486841770.10020.287.camel@freebsd.org> <0fe001d285c7$032c32a0$098497e0$@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: Mon, 13 Feb 2017 16:56:51 -0000 On Sun, 2017-02-12 at 23:01 -0800, Tony Hain wrote: > > > > > -----Original Message----- > > From: Ian Lepore [mailto:ian@freebsd.org] > > Sent: Saturday, February 11, 2017 11:36 AM > > To: Tony Hain; 'Oleksandr Tymoshenko' > > Cc: freebsd-arm@freebsd.org > > Subject: Re: Questions about BBB/BBG dtb names vs. content > > > > 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.) > So how would I get crochet to build that dtb? As far as I can tell I > need to > add an include line in the black file, including the compatible for > green, > because I can't follow the sequence that actually builds the dts > initially. > I did put together a dts for all 6 uarts, because it was a pita to > find and > correlate the references which are not collected as a complete set > anywhere > as far as I can tell. I offer it here for contrib if it is useful for > the > short term, or for the dtbo effort. I am running crochet now, so I am > not > positive this works yet, but it should be close. > > /* am335x-bone-uarts.dts >  * >  * BeagleBone Green / Black - All 6 uarts defined : >  *   this was difficult to find as the SRM doesn't include the > address > offset, >  *       and example dts files found by search were incomplete, many > with > incorrect offsets >  *   eventually tripped over address offset P8/9 maps at: >  * > http://www.siue.edu/~gengel/bbbWebStuff/BeagleboneBlackP8HeaderTable. > pdf >  * > http://www.siue.edu/~gengel/bbbWebStuff/BeagleboneBlackP9HeaderTable. > pdf >  *   coorelated with 335x pin map at >  *       http://www.ti.com/lit/ds/symlink/am3359.pdf     zcz ball > number > matches above tables >  * >  *   compiled by Tony Hain - 2/12/17 >  * >  *  modify comment markers below to enable/disable required uarts >  * >  *  add  #include "am335x-bone-uarts.dts"   to board dts >  */ > > /dts-v1/; > > / { >         model = "TI AM335x BeagleBone Green"; >         compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", > "ti,am335x-bone", "ti,am33xx"; > }; > > &am33xx_pinmux { >         uart0_pins: uart0_pins { >                 pinctrl-single,pins = < > /*              Addr offset | Direction  | MuxMode  |  Connector | > Proc pin > > > > SignalName | Conflict >  */ >         AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)    /* J1_4 > E15 > uart0_rxd */ >         AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* J1_5 > E16 > uart0_txd */ > //      AM33XX_IOPAD(0x978, PIN_OUTPUT | MUX_MODE5)          /* P9_20 > D18 > uart0_ctsn ! uart1_cts*/ > //      AM33XX_IOPAD(0x97c, PIN_INPUT | MUX_MODE5)           /* P9_19 > D17 > uart0_rtsn ! uart1_rts*/ >                 >; >         }; > >         uart1_pins: uart1_pins { >                 pinctrl-single,pins = < >         AM33XX_IOPAD(0x980, PIN_INPUT | MUX_MODE0)           /* P9_26 > D16 > uart1_rxd */ >         AM33XX_IOPAD(0x984, PIN_INPUT | MUX_MODE0)           /* P9_24 > D15 > uart1_txd */ > }; > uart1_ctsn ! uart0_cts*/ > //      AM33XX_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* P9_19 > D17 > uart1_rtsn ! uart0_rts*/ > //      AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5)  /* > No_pin G16 > uart1_ri */ > //      AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5)  /* > No_pin K18 > uart1_dcd */ > //      AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5)  /* > No_pin L18 > uart1_dsr */ > //      AM33XX_IOPAD(0xXxx, PIN_OUTPUT_PULLDOWN | MUX_MODE5) /* > No_pin L17 > uart1_dtr */ >                 >; >         }; > >         uart2_pins: uart2_pins { >                 pinctrl-single,pins = < >         AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE1)           /* P9_22 > A17 > uart2_rxd */ >         AM33XX_IOPAD(0x954, PIN_OUTPUT | MUX_MODE1)          /* P9_21 > B17 > uart2_txd */ > //      AM33XX_IOPAD(0x8c0, PIN_INPUT_PULLDOWN | MUX_MODE6)  /* P8_37 > U1 > uart2_ctsn ! uart5_txd*/ > //      AM33XX_IOPAD(0x8b8, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* P8_38 > U2 > uart2_rtsn ! uart5_rxd*/ >                 >; >         }; > >         uart3_pins: uart3_pins { >                 pinctrl-single,pins = < > //      AM33XX_IOPAD(0xXxx, PIN_INPUT | MUX_MODE1)           /* > No_pin C15 > uart3_rxd ! hdmi */ >         AM33XX_IOPAD(0x964, PIN_OUTPUT_PULLUP | MUX_MODE1)   /* P9_42 > C18 > uart3_txd */ > //      AM33XX_IOPAD(0x8c8, PIN_INPUT_PULLUP | MUX_MODE6)    /* P8_36 > U3 > uart3_ctsn */ > //      AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE6)          /* P8_34 > U4 > uart3_rtsn */ >                 >; >         }; > >         uart4_pins: uart4_pins { >                 pinctrl-single,pins = < >         AM33XX_IOPAD(0x870, PIN_INPUT_PULLUP | MUX_MODE6)    /* P9_11 > T17 > uart4_rxd */ >         AM33XX_IOPAD(0x874, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* P9_13 > U17 > uart4_txd */ > //      AM33XX_IOPAD(0x8d0, PIN_INPUT_PULLUP | MUX_MODE6)    /* P8_35 > V2 > uart4_ctsn */ > //      AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE6)    > };       /* P8_33 V3 > uart4_rtsn */ >                 >; >         }; > >         uart5_pins: uart5_pins { >                 pinctrl-single,pins = < >         AM33XX_IOPAD(0x8c4, PIN_INPUT | MUX_MODE4)           /* P8_38 > U2 > uart5_rxd ! uart2_rts*/ >         AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE4)          /* P8_37 > U1 > uart5_txd ! uart2_cts*/ > //      AM33XX_IOPAD(0x8d8, PIN_INPUT_PULLUP | MUX_MODE6)    /* P8_31 > V4 > uart5_ctsn */ > //      AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE6)          /* P8_32 > T5 > uart5_rtsn */ >                 >; >         }; > }; > > &uart0 { >         pinctrl-names = "default"; >         pinctrl-0 = <&uart0_pins>; >         status = "okay"; > //      status = "disabled"; > }; > > &uart1 { >         pinctrl-names = "default"; >         pinctrl-0 = <&uart1_pins>; >         status = "okay"; > //      status = "disabled"; > }; > > &uart2 { >         pinctrl-names = "default"; >         pinctrl-0 = <&uart2_pins>; > //      status = "okay"; >         status = "disabled"; > }; > > &uart3 { >         pinctrl-names = "default"; >         pinctrl-0 = <&uart3_pins>; > //      status = "okay"; >         status = "disabled"; > }; > > &uart4 { >         pinctrl-names = "default"; >         pinctrl-0 = <&uart4_pins>; > //      status = "okay"; >         status = "disabled"; > }; > > &uart5 { >         pinctrl-names = "default"; >         pinctrl-0 = <&uart5_pins>; > //      status = "okay"; >         status = "disabled"; > }; > It looks like you've designed it so that you have to modify the stock source to include that file above.  Instead, reverse that.  Remove the block that has the model= and all, and in its place do   #include "am335x-bonegreen.dts" and then follow that with the &am33xx_pinmux {...} and #uartN {...} blocks you already have. Then you just need to tell crochet to build that dts file instead of (or in addition to) the standard ones.  I don't use crochet, so I'm not sure how to make it do that, but someone here can probably give us the right incantation. -- Ian   From owner-freebsd-arm@freebsd.org Mon Feb 13 21:46:16 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 D19DECDE494 for ; Mon, 13 Feb 2017 21:46:16 +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 944F81CBD for ; Mon, 13 Feb 2017 21:46:16 +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 v1DLk6oq044786; Mon, 13 Feb 2017 16:46:07 -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); 13 Feb 2017 16:46:06 -0500 Date: Mon, 13 Feb 2017 16:46:04 -0500 From: Brett Wynkoop To: Joe Nosay Cc: freebsd-arm@freebsd.org Subject: Re: Out of swap - NOT Message-ID: In-Reply-To: References: <20170211022800.14138f68@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: 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: Mon, 13 Feb 2017 21:46:16 -0000 On Mon, 13 Feb 2017 15:55:11 -0500 Joe Nosay wrote: > Is it possible to place the swap on a separate disk such as a usb? Yes, but I am not sure what difference that will make. I would think a swapfile is a swapfile. Yes I am swapping on a file because the image autogrew the filesystem on first boot, so no chance to set up a partition. It should be noted that by getting rid of the tmpfs /tmp I was able to complete a kernel build. At no time did my monitored use of swap exceed 10%. -Brett -- wynkoop@wynn.com 917-642-6925 929-272-0000 Amendment I Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the government for a redress of grievances. From owner-freebsd-arm@freebsd.org Mon Feb 13 21:48: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 668BECDE564 for ; Mon, 13 Feb 2017 21:48:48 +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 3AC0A1E7D for ; Mon, 13 Feb 2017 21:48:47 +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 AE1341A4F00 for ; Mon, 13 Feb 2017 15:48:41 -0600 (CST) Subject: Re: Out of swap - NOT To: freebsd-arm@freebsd.org References: <20170211022800.14138f68@pearl> From: Karl Denninger Message-ID: <7248bf14-4f27-73a3-4f71-909a490a9011@denninger.net> Date: Mon, 13 Feb 2017 15:48:32 -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="------------ms060905040400030808060206" 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, 13 Feb 2017 21:48:48 -0000 This is a cryptographically signed message in MIME format. --------------ms060905040400030808060206 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/13/2017 15:46, Brett Wynkoop wrote: > On Mon, 13 Feb 2017 15:55:11 -0500 > Joe Nosay wrote: > >> Is it possible to place the swap on a separate disk such as a usb? > Yes, but I am not sure what difference that will make. I would think a= > swapfile is a swapfile. Yes I am swapping on a file because the image > autogrew the filesystem on first boot, so no chance to set up a > partition. > > It should be noted that by getting rid of the tmpfs /tmp I was able to > complete a kernel build. At no time did my monitored use of swap exceed= > 10%. > > -Brett Well, you didn't really run out of "swap" -- you ran out of tmpfs, but the symptomology is that you get that result. As I noted I've seen that before; you do not want to run /tmp on the SD card though as the wear pattern is very bad for it and in addition it's also very slow. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060905040400030808060206 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTMyMTQ4MzJaME8GCSqGSIb3DQEJBDFCBEBKJegk dXPE7H0YUme1yIsQsXS5PrsbHA349Hy54Z4/sQsQlb9vyPO2vEmsvi9mVKsQlFSQ2aWwLMD4 I5HavP+6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAhhFNiTlremrg HTiTqWsrD43Ue/wbGqUL63KhZW1LPHVD1lBuX4bjAKSOsu2fTOrDn5vX1uOjc2/Pq0pQnsa+ V+Ha3ZQicZYuqtpHD8VivCJranvo2PYuRkVSJdajWSzAGp2pJXD4SGUu8GCd/Fn9lMZVubNC H8MekaCn4xXarVams/w0wRF0K3PoL85mrQklun2VrivfoWscKPtkchJSk57/9UoCt1kYhjtA yUduxKm4c7fSOqsSmU1O1/cjkHX4Gf2c/5PMkMQ0mFg3a0Hb48Ubtb6nSNyDPly9poJV60cm 1yzVfe2W5Own4iT0j9f3IoHmbaDYoCC77wSnQVxCVrbzOlgwXIOfmNJEgkv6EsvpbfDnjQCa tqzFqTYflMFHpjRCz73qxkaRUCsytvZ/GpB0qJ1r4zSyrrfWxWg3D0r7HND//9IGOHoiFJpf U18YLkHle5so35XFU7bv6U00wzfH5PAxnFpD3uLivUxIDzb/j2rY4trKi+c41qW3PqRzInAT +oXRoPcwI1eoAx+UrXACOB4eMmKvHV7SRoqWulRrHZtO26Ot4UIEblLFuLIIH2yp+SLVzTEi hXTaJM15AJOsLkOuWx6m0MPzZSq15E0BrbazMNRmWrJvdcTKeXcanqkPM38yWsl8YvINIFqF 8qyLYb1cT1PljJpw/VeD6vsAAAAAAAA= --------------ms060905040400030808060206-- From owner-freebsd-arm@freebsd.org Mon Feb 13 22:20: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 18ECCCDEE1C for ; Mon, 13 Feb 2017 22:20:05 +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 C804A12BE for ; Mon, 13 Feb 2017 22:20:04 +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 0EF2E1BF2A3 for ; Mon, 13 Feb 2017 16:20:03 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: ABI compatibility between 11-STABLE (RPI2) and 12-HEAD (RPI3) Message-ID: <8979e483-7836-609f-9a95-db81abac09e3@denninger.net> Date: Mon, 13 Feb 2017 16:19:55 -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="------------ms030102080501080109020604" 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, 13 Feb 2017 22:20:05 -0000 This is a cryptographically signed message in MIME format. --------------ms030102080501080109020604 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hmmmm....//I thought you could run things compiled on the Pi2 under 11-STABLE (don't you have to do this to run packages on the RPI3 under -HEAD right now?) on a Pi3 running on 12-CURRENT (-HEAD)...... Apparently not.... root@rpi3:/usr/local/bin # hd-mcp /usr/local/bin/hd-mcp: Exec format error. Binary file not executable. root@rpi3:/usr/local/bin # file hd-mcp hd-mcp: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.0 (1100507), FreeBSD-style, stripped --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030102080501080109020604 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMTMyMjE5NTVaME8GCSqGSIb3DQEJBDFCBEBQIOqE 4Ns9p9ivtivyaqtm3cx4fwg53QdPvguhPR6yvEr/uqB3HIkQquhqFAPcUyn36Z9CVw4qcHw+ 9AXtHtddMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAtcXaCfFZLQW6 3KzPnYCzVY7VmpmK6pftQDlw4vM0Ed0EEkFSphhF3mvHlAU2VKY6LdC/8S+Wi/zgSnRJ8jBw PSAqZvEbLdWqJ6aC0js3two3QLepM43BE1L0O+zxM8A7sbzeQKWNAbRwyugJgMyiltotkvw5 jPojy1Vf2NYGcBmNH0x/wkmlgR+Ya5pnvzhbLzhJRRMfjmIlb2AcyqRvHtR/WmYExQzpR3VJ tShSRGRI14hiyrYCtdlR/Mr9wXzBSzaYFU97Br12qmqMFlbTJEx+ZGU3VTPUq/t3ruK0CEbi vWQSpbneo9jT5jYDjTISXIg8Qx4RzTeMstQZxgjc99BSbJ6g5IvVz1laM9lSAoLHYG1/l8iu nhbtYfhpNw4XONlaWNBYIgwSKZya43l6G1lh7U6TUA8UTh3CKymtmOuxB0anTX+bfRFH5vrd 7tPoDmVEnexBI+eFSN0iEG/OjHxvi+GqYEEo10faI0o9HpHJja3tjdP4tKv0bTiJ29ax/g7y EgC9YFuRd8fsbn1khDd3ulJmBAjnbzxTWSpgOor0AdBEB8YEJxMOebCgbec4kO4VXxJlx8S1 RKbBsAEFynWbq1U95C5eY40cO7bWqRn8LgcMeXgKV4VxNQXm6K+wDHK5dr8dL9fbwSgxhShA p0P8RxTn5+C83XkHoxvOHW4AAAAAAAA= --------------ms030102080501080109020604-- From owner-freebsd-arm@freebsd.org Mon Feb 13 22:29: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 8F87BCDD156 for ; Mon, 13 Feb 2017 22:29:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C912193A for ; Mon, 13 Feb 2017 22:29:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id x75so6600224itb.0 for ; Mon, 13 Feb 2017 14:29:55 -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=dY1j7oGdmG6HU23BMBJNd0Kp+cZTurkeVjsSsO5YVC0=; b=ocK4i5ReqozI/05/lThWUN6CMeD4R77e0+nAl+a3ui8o/c/PDkysWQk0BbaWYE7LaI ZvuRiOvNpXSNnnkXwjEKyBfSBeT2SdaCnHv6PrTO4DXnza4XqzKoByBBpHOhpnbRiJep eSAUCJf3Lavou9E0eDGFq7tZ7zXfznHeAB/EMeowPBTg6iETZL1HZGH2ejlM/ctMzeJw OunSp4fYkkddTnVctWs6WSZVrpL8/XeSbjD1xwVxxRYibqKkvb9bxT4a8rY87VEGvziW xrLCkNYiYbQkYzIr+ka0PhOriygyPXto6xYeJmPWY8V7RleQfze1rii4dHzd76N5iROB o3gg== 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=dY1j7oGdmG6HU23BMBJNd0Kp+cZTurkeVjsSsO5YVC0=; b=C08JojAcNl2dA+45f/96cuQsoRM9A/Fd2SoCuI4Kdvjvm9AslE1R9fB8NO1QDD829j 62IBPwTq9MzsCP6TIW1TJdiUzqYDxpb7RcgyjtZNeECxTdpoUhtpmGEjXOWidRN1ft4Z XndIjmaQLAvErX/ay1F++ApyMOY6k4/Ns++DydMGEMgEngJYxOPDtPd/FDie2BaFy2ce mZ7gZmNqukDQKsZ7UYkKmEKF0dxZp6BdA8v0nGVuiDVDdxtn0OjBKJ/d4e/3F6PNeGCm kqTJKmsHl/r4Ax7uR4LxNpgY20MCE3InngIXvKA2HA9EHUllm65Pw5QFw3wNm1u8YwUP cMEQ== X-Gm-Message-State: AMke39mI6vYoMAwuL60w5DsoxQUothyu2lphlBmHzEcIjTZLsfFcrY5IfG5tjrhVdFBPPBfDUmF+3vaYgr0XNA== X-Received: by 10.107.139.131 with SMTP id n125mr25280999iod.166.1487024994585; Mon, 13 Feb 2017 14:29:54 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Mon, 13 Feb 2017 14:29:54 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <8979e483-7836-609f-9a95-db81abac09e3@denninger.net> References: <8979e483-7836-609f-9a95-db81abac09e3@denninger.net> From: Warner Losh Date: Mon, 13 Feb 2017 15:29:54 -0700 X-Google-Sender-Auth: dqdgr1Cba0TC-o3Gvz6wyZtjkgo Message-ID: Subject: Re: ABI compatibility between 11-STABLE (RPI2) and 12-HEAD (RPI3) 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, 13 Feb 2017 22:29:55 -0000 On Mon, Feb 13, 2017 at 3:19 PM, Karl Denninger wrote: > Hmmmm....//I thought you could run things compiled on the Pi2 under > 11-STABLE (don't you have to do this to run packages on the RPI3 under > -HEAD right now?) on a Pi3 running on 12-CURRENT (-HEAD)...... > > Apparently not.... > > root@rpi3:/usr/local/bin # hd-mcp > /usr/local/bin/hd-mcp: Exec format error. Binary file not executable. > > root@rpi3:/usr/local/bin # file hd-mcp > hd-mcp: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), > dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.0 > (1100507), FreeBSD-style, stripped We don't support running 32-bit binaries on 64-bit arm machines. Not all 64-bit arm CPUs can even do that if we did. Warner From owner-freebsd-arm@freebsd.org Tue Feb 14 03:20: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 22791CDC294 for ; Tue, 14 Feb 2017 03:20:45 +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 968BF1316 for ; Tue, 14 Feb 2017 03:20:44 +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 v1E3Kdn1010480 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2017 05:20:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v1E3Kdn1010480 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v1E3KaRr010457; Tue, 14 Feb 2017 05:20:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 Feb 2017 05:20:36 +0200 From: Konstantin Belousov To: wynkoop@wynn.com Cc: Joe Nosay , freebsd-arm@freebsd.org Subject: Re: Out of swap - NOT Message-ID: <20170214032036.GR2092@kib.kiev.ua> References: <20170211022800.14138f68@pearl> 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-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: Tue, 14 Feb 2017 03:20:45 -0000 On Mon, Feb 13, 2017 at 04:46:04PM -0500, Brett Wynkoop wrote: > On Mon, 13 Feb 2017 15:55:11 -0500 > Joe Nosay wrote: > > > Is it possible to place the swap on a separate disk such as a usb? > > Yes, but I am not sure what difference that will make. I would think a > swapfile is a swapfile. Yes I am swapping on a file because the image > autogrew the filesystem on first boot, so no chance to set up a > partition. swapfile write requires the write request to come through the filesystem write path, which might require the filesystem to allocate more memory and read some data. E.g. it is known that any ZFS write request allocates memory, and that write request on large UFS file might require allocating and reading an indirect block buffer to find the block number of the written block, if the indirect block was not yet read. As result, swapfile swapping is more prone to the trivial and unavoidable deadlocks where the pagedaemon thread, which produces free memory, needs more free memory to make a progress. Swap write on the raw partition over simple partitioning scheme directly over HBA are usually safe, while e.g. zfs over geli over umass is the worst construction. From owner-freebsd-arm@freebsd.org Tue Feb 14 03:35:03 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 9BCBCCDCC8D for ; Tue, 14 Feb 2017 03:35:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (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 4FDFF1FB1 for ; Tue, 14 Feb 2017 03:35:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11358 invoked from network); 14 Feb 2017 03:34:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2017 03:34:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Mon, 13 Feb 2017 22:34:55 -0500 (EST) Received: (qmail 21990 invoked from network); 14 Feb 2017 03:34:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Feb 2017 03:34:55 -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 9A6CFEC7822; Mon, 13 Feb 2017 19:34:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Out of swap - NOT From: Mark Millard In-Reply-To: <20170214032036.GR2092@kib.kiev.ua> Date: Mon, 13 Feb 2017 19:34:53 -0800 Cc: wynkoop@wynn.com, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <75FA953B-4F23-4FF9-92D9-B78BA890EEA6@dsl-only.net> References: <20170211022800.14138f68@pearl> <20170214032036.GR2092@kib.kiev.ua> To: Konstantin Belousov 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, 14 Feb 2017 03:35:03 -0000 On 2017-Feb-13, at 7:20 PM, Konstantin Belousov = wrote: > On Mon, Feb 13, 2017 at 04:46:04PM -0500, Brett Wynkoop wrote: >> On Mon, 13 Feb 2017 15:55:11 -0500 >> Joe Nosay wrote: >>=20 >>> Is it possible to place the swap on a separate disk such as a usb? >>=20 >> Yes, but I am not sure what difference that will make. I would think = a >> swapfile is a swapfile. Yes I am swapping on a file because the = image >> autogrew the filesystem on first boot, so no chance to set up a >> partition. > swapfile write requires the write request to come through the = filesystem > write path, which might require the filesystem to allocate more memory > and read some data. E.g. it is known that any ZFS write request > allocates memory, and that write request on large UFS file might = require > allocating and reading an indirect block buffer to find the block = number > of the written block, if the indirect block was not yet read. >=20 > As result, swapfile swapping is more prone to the trivial and = unavoidable > deadlocks where the pagedaemon thread, which produces free memory, = needs > more free memory to make a progress. Swap write on the raw partition = over > simple partitioning scheme directly over HBA are usually safe, while = e.g. > zfs over geli over umass is the worst construction. Thanks for the explanation of bugzilla 206038: 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black) amd64 etc: swapfile usage hangs; swap partition works I'll copy your text into the comments for that submittal. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Feb 14 04:04:51 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 2C2F4CDE6E9 for ; Tue, 14 Feb 2017 04:04:51 +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 CD9FE1EFF for ; Tue, 14 Feb 2017 04:04:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11587 invoked from network); 14 Feb 2017 04:04:43 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2017 04:04:43 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Mon, 13 Feb 2017 23:04:43 -0500 (EST) Received: (qmail 12433 invoked from network); 14 Feb 2017 04:04:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Feb 2017 04:04:43 -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 CFB28EC7B31; Mon, 13 Feb 2017 20:04:42 -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: <8E5F8A15-2F79-4015-B93B-975D27308782@dsl-only.net> Date: Mon, 13 Feb 2017 20:04:42 -0800 Cc: freebsd-arm , Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <674C2DA0-808D-4968-B86D-7CADEC3A7EEE@dsl-only.net> References: <5335118.oK1KXXDaG5@pc-alex> <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> <7424243.zp5tqGREgJ@pc-alex> <8E5F8A15-2F79-4015-B93B-975D27308782@dsl-only.net> 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: Tue, 14 Feb 2017 04:04:51 -0000 On 2017-Feb-13, at 1:27 AM, Mark Millard wrote: > As the decision about when to call the code that can > deal with overlapping memory regions is wrong, the code > that should only be used for non-overlaping regions likely > would handle some overlapping regions and so would operate > incorrectly in at least some cases. >=20 > In other words, I think the bug is worse than just an > example of being sub-optimal: the code is wrong from what > I can tell. (I've no clue if the code is ever put to use > for any bad cases.) I was wrong about the error status, possibly for multiple reasons, but the following is sufficient: https://www.freebsd.org/cgi/man.cgi?query=3Dmemcpy&sektion=3D3 says: In this implementation memcpy() is implemented using bcopy(3), and = there- fore the strings may overlap. On other systems, copying = overlapping strings may produce surprises. Programs intended to be portable = should use memmove(3) when src and dst may overlap. so the branch taken case for: bcc PIC_SYM(_C_LABEL(memcpy), PLT) also deals with overlaps since FreeBSD criteria is that memcpy does so. (I had been thinking that it did not deal with such.) Side note: Notably the arm implementation of FreeBSD memcpy does not call bcopy (that would be recursive in the arm implementation). memcpy just needs to have some properties that bcopy also has. This suggests that memcpy vs. bcopy may have a performance Principle of Least Astonishment violation since memcpy may well perform differently than bcopy for some types of contexts but memcpy is supposed to use bcopy. [A varient of these notes are in the comments for bugzilla 217065.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Feb 14 05:31: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 90C22CDE169 for ; Tue, 14 Feb 2017 05:31:38 +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 55F071B4E for ; Tue, 14 Feb 2017 05:31:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11392 invoked from network); 14 Feb 2017 05:26:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Feb 2017 05:26:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Tue, 14 Feb 2017 00:24:50 -0500 (EST) Received: (qmail 27974 invoked from network); 14 Feb 2017 05:24:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Feb 2017 05:24:50 -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 CA48BEC8FB9; Mon, 13 Feb 2017 21:24:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: pine64 (an A64 Cortex-A53 context, e.g. -r312982): sh`forkshell child-process path after fork sometimes has a bad stack pointer value From: Mark Millard In-Reply-To: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> Date: Mon, 13 Feb 2017 21:24:49 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> References: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> To: andrew@freebsd.org, Shawn Webb , Tom Vijlbrief 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, 14 Feb 2017 05:31:38 -0000 [A top post of 7 summaries of more stack pointer changes for before fork vs. after fork.] Unless I figure out a way to well-track what is happening internal to fork's activity this is likely my last post of evidence for the issue. Based on the new test that detects both directions and checks the parent and child cases for fork's return value. . . All the examples of core dumps report: (lldb) print pid (pid_t) $0 =3D 0 and so go down the child-process code path in sh`forkshell. There are no examples of the parent code path cases having any such issue. I do not show the "print commandname" output but it varies greatly. I have 3 examples of the stack pointer getting smaller instead of staying at the same value, each landed in the potential active stack area and so did not trash other memory areas: (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a33180 x21 =3D 0x0000000000000000 x22 =3D 0x0000000040abce68 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x0000000000000003 x26 =3D 0x0000000040a33180 x27 =3D 0x0000ffffffffcb08 x28 =3D 0x0000000000000000 fp =3D 0x0000ffffffffca70 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffc960 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $0 =3D 0x0000ffffffffca10 (lldb) print/x stack_address_after_fork (uintptr_t) $1 =3D 0x0000ffffffffc940 0x0000ffffffffca10-0x0000ffffffffc940 =3D 0xD0 (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a23300 x21 =3D 0x0000000000000000 x22 =3D 0x0000000040a50510 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x0000000040a23300 x26 =3D 0x00000000ffffffff x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a50538 fp =3D 0x0000ffffffffbdc0 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffbcb0 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $0 =3D 0x0000ffffffffbd60 (lldb) print/x stack_address_after_fork (uintptr_t) $1 =3D 0x0000ffffffffbc90 0x0000ffffffffbd60-0x0000ffffffffbc90 =3D 0xD0 (No more examples of 0xD0 though.) (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a36180 x21 =3D 0x0000000000000002 x22 =3D 0x0000000040a53150 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x00000000000000fa x26 =3D 0x0000000040a53e40 x27 =3D 0x0000000040a53226 x28 =3D 0x0000000000434000 sh..bss + 6336 fp =3D 0x0000ffffffffcf90 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffb540 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $0 =3D 0x0000ffffffffcf30 (lldb) print/x stack_address_after_fork (uintptr_t) $1 =3D 0x0000ffffffffb520 0x0000ffffffffcf30-0x0000ffffffffb520 =3D 0x1A10 For the rest of the examples the stack pointer gets larger, but by widely variable amounts: (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a350c0 x21 =3D 0x0000000000000002 x22 =3D 0x0000000040a49898 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x00000000000000fb x26 =3D 0x0000000040a49b90 x27 =3D 0x0000000040a49918 x28 =3D 0x0000000000434000 sh..bss + 6336 fp =3D 0x0000ffffffffcee0 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffd180 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $0 =3D 0x0000ffffffffce80 (lldb) print/x stack_address_after_fork (uintptr_t) $1 =3D 0x0000ffffffffd160 0x0000ffffffffd160-0x0000ffffffffce80 =3D 0x2E0 (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a33180 x21 =3D 0x0000000000000000 x22 =3D 0x0000000040a53748 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x0000000040a33180 x26 =3D 0x00000000ffffffff x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a53770 fp =3D 0x0000ffffffffcae0 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffd5a0 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $0 =3D 0x0000ffffffffca80 (lldb) print/x stack_address_after_fork (uintptr_t) $1 =3D 0x0000ffffffffd580 0x0000ffffffffd580-0x0000ffffffffca80 =3D 0xB00 (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a33180 x21 =3D 0x0000000000000000 x22 =3D 0x0000000040a9f6b8 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x0000000040a33180 x26 =3D 0x0000000000000003 x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a9f6a8 fp =3D 0x0000ffffffffc710 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffce40 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $0 =3D 0x0000ffffffffc6b0 (lldb) print/x stack_address_after_fork (uintptr_t) $1 =3D 0x0000ffffffffce20 0x0000ffffffffce20-0x0000ffffffffc6b0 =3D 0x770 (lldb) up 3 frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 856 stack_address_before_fork =3D example_stack_address(); 857 pid =3D fork(); 858 stack_address_after_fork =3D example_stack_address(); -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); 860 if (pid =3D=3D -1) { 861 TRACE(("Fork failed, errno=3D%d\n", errno)); 862 INTON; (lldb) register read General Purpose Registers: x19 =3D 0x0000000000000000 x20 =3D 0x0000000040a33180 x21 =3D 0x0000000000000000 x22 =3D 0x0000000040a9be28 x23 =3D 0x0000000000434000 sh..bss + 6336 x24 =3D 0x0000000000434000 sh..bss + 6336 x25 =3D 0x0000000040a33180 x26 =3D 0x0000000000000003 x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a9bdb0 fp =3D 0x0000ffffffffca50 lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 sp =3D 0x0000ffffffffd8a0 pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 20 registers were unavailable. (lldb) print/x stack_address_before_fork (uintptr_t) $2 =3D 0x0000ffffffffc9f0 (lldb) print/x stack_address_after_fork (uintptr_t) $3 =3D 0x0000ffffffffd880 0x0000ffffffffd880-0x0000ffffffffc9f0 =3D 0xE90 That is it for evidence, at least for now. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Feb-12, at 6:46 PM, Mark Millard wrote: > On 2017-Feb-12, at 2:52 AM, Mark Millard = wrote: >=20 >> On pine64 (an A64 Cortex-A53 context) multiple people on the lists >> including me have reported sh getting occasional core dumps. >>=20 >> I've analyzed a bunch of the sh core dumps and all failed in the >> child-process path of forkshell when forkshell tried to return.=20 >> I've since done experiments with code to detect some forms of >> odd stack pointer values so that the adjusted code calls abort >> for such a detection before such a return would happen. [This >> gives a nicer context to look at in core dumps (before things >> are very messed up if the sp is bad).] >>=20 >> In sh`forkshell, just after the fork returns, on the child-process >> path there is sometimes a messed up sp value by what direction >> it is from the prior frame-pointers on the stack --and on occasion >> the value difference is very large, such as: >> (from: lldb register read on the frame with the pc in sh`forkshell ) >>=20 >> fp =3D 0x0000ffffffffce90 >> sp =3D 0x0000ffffffffe980 >>=20 >> This has the sp with a larger address than what sh`__start >> stored as the frame-pointer back-link when it is put to use via >> ld-elf.so.1`.rtld_start (more like 0x0000ffffffffde10 as I >> remember): outside the active stack region. >>=20 >> [Note: my experiments so far would not establish if the sp >> might sometimes have an unexpectedly large distance toward >> lower memory addresses, specially if it was still in the >> potential stack-region. It may be that both directions >> happen.] >>=20 >> The distance when it fails is vary variable across examples. >> I just picked an example were stack frames would be written >> over the top of other material when sh`forkshell makes other >> calls on the child-process path, material that would be >> outside what should be the active stack region. >>=20 >> # uname -apKU >> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 >>=20 >> (I've frozen at that version for this exploration. >> It has taken me a while.) >>=20 >> Looking around I see what might be a few possibilities. . . >> (I'm no expert so some might be trivially eliminated.) >>=20 >>=20 >> Possibility #0 (possibilities in no particular order): >>=20 >> sys/arm64/arm64/vm_machdep.c : >>=20 >> In cpu_fork what if the bcopy of td1-td_frame might not >> always have access to the latest updated values, needing >> some form of memory "fence" to be sure that such values are >> accessible? : >>=20 >> tf =3D (struct trapframe *)STACKALIGN((struct trapframe *)pcb2 = - 1); >> bcopy(td1->td_frame, tf, sizeof(*tf)); >> tf->tf_x[0] =3D 0; >> tf->tf_x[1] =3D 0; >> tf->tf_spsr =3D 0; >>=20 >> td2->td_frame =3D tf; >>=20 >> /* Set the return value registers for fork() */ >> td2->td_pcb->pcb_x[8] =3D (uintptr_t)fork_return; >> td2->td_pcb->pcb_x[9] =3D (uintptr_t)td2; >> td2->td_pcb->pcb_x[PCB_LR] =3D (uintptr_t)fork_trampoline; >> td2->td_pcb->pcb_sp =3D (uintptr_t)td2->td_frame; >> td2->td_pcb->pcb_fpusaved =3D &td2->td_pcb->pcb_fpustate; >> td2->td_pcb->pcb_vfpcpu =3D UINT_MAX; >>=20 >> /* Setup to release spin count in fork_exit(). */ >> td2->td_md.md_spinlock_count =3D 1; >> td2->td_md.md_saved_daif =3D 0; >>=20 >>=20 >> Possibility #1: >>=20 >> sys/arm64/arm64/swtch.S : >>=20 >> ENTRY(fork_trampoline) >> . . . >> /* Restore sp and lr */ >> ldp x0, x1, [sp] >> msr sp_el0, x0 >> mov lr, x1 >>=20 >> Similar point to #0 but for the ldp memory accesses >> shown. >>=20 >>=20 >> Possibility #3: >>=20 >> sys/arm64/arm64/exception.S : >>=20 >> Both of: >>=20 >> handle_el0_sync >> handle_el0_irq >>=20 >> also update sp_el0 and so if any such can happen >> during any part of fork_trampoline after its >> "msr sp_el0, x0" but before its "msr daifset, #2" >> (disabling interrupts), then the wrong sp_el0 value >> would be in place at fork_tramploine's eret . >>=20 >>=20 >> It will be interesting to see what the problem actually >> was once it has been fixed. >=20 > I have updated to a test that should report any time > fork changes the stack pointer from what it was before > the fork, parent or child process: >=20 > # svnlite diff /usr/src/bin/sh/miscbltin.c /usr/src/bin/sh/jobs.c > Index: /usr/src/bin/sh/miscbltin.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/bin/sh/miscbltin.c (revision 312982) > +++ /usr/src/bin/sh/miscbltin.c (working copy) > @@ -64,6 +64,15 @@ >=20 > #undef eflag >=20 > + > +/* JUST FOR TESTING */ > +uintptr_t example_stack_address(void) > +{ > + volatile uintptr_t test =3D 0; > + return (uintptr_t)(void*)&test; > +} > + > + > int readcmd(int, char **); > int umaskcmd(int, char **); > int ulimitcmd(int, char **); > Index: /usr/src/bin/sh/jobs.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/bin/sh/jobs.c (revision 312982) > +++ /usr/src/bin/sh/jobs.c (working copy) > @@ -51,6 +51,9 @@ > #include > #include >=20 > +/* JUST FOR TESTING */ > +#include > + > #include "shell.h" > #if JOBS > #include > @@ -833,6 +836,11 @@ > * in a pipeline). > */ >=20 > +extern uintptr_t example_stack_address(void); > + > +uintptr_t stack_address_before_fork =3D 0; > +uintptr_t stack_address_after_fork =3D 0; > + > pid_t > forkshell(struct job *jp, union node *n, int mode) > { > @@ -845,7 +853,10 @@ > if (mode =3D=3D FORK_BG && (jp =3D=3D NULL || jp->nprocs =3D=3D = 0)) > checkzombies(); > flushall(); > + stack_address_before_fork =3D example_stack_address(); > pid =3D fork(); > + stack_address_after_fork =3D example_stack_address(); > + if (stack_address_after_fork !=3D stack_address_before_fork) = abort(); > if (pid =3D=3D -1) { > TRACE(("Fork failed, errno=3D%d\n", errno)); > INTON; > @@ -946,7 +957,6 @@ > return pid; > } >=20 > - > pid_t > vforkexecshell(struct job *jp, char **argv, char **envp, const char = *path, int idx, int pip[2]) > { >=20 >=20 > I've been using repeated attempts to build devel/aarch64-none-elf-gcc > for testing because the configure activity does lots of shell work > that forks. (I first noticed the problem in such a context.) >=20 > The first example core file from repeated attempts to build > devel/aarch64-none-elf-gcc with this new test shows: >=20 > (lldb) bt > * thread #1: tid =3D 100188, 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: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 > (lldb) up 3 > frame #3: 0x000000000040f56c sh`forkshell(jp=3D, = n=3D, mode=3D) + 1080 at jobs.c:859 > 856 stack_address_before_fork =3D = example_stack_address(); > 857 pid =3D fork(); > 858 stack_address_after_fork =3D = example_stack_address(); > -> 859 if (stack_address_after_fork !=3D = stack_address_before_fork) abort(); > 860 if (pid =3D=3D -1) { > 861 TRACE(("Fork failed, errno=3D%d\n", = errno)); > 862 INTON; >=20 > (lldb) register read > General Purpose Registers: > x19 =3D 0x0000000000000000 > x20 =3D 0x0000000040a350c0 > x21 =3D 0x0000000000000002 > x22 =3D 0x0000000040a49898 > x23 =3D 0x0000000000434000 sh..bss + 6336 > x24 =3D 0x0000000000434000 sh..bss + 6336 > x25 =3D 0x00000000000000fb > x26 =3D 0x0000000040a49b90 > x27 =3D 0x0000000040a49918 > x28 =3D 0x0000000000434000 sh..bss + 6336 > fp =3D 0x0000ffffffffcee0 > lr =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 > sp =3D 0x0000ffffffffd180 > pc =3D 0x000000000040f56c sh`forkshell + 1080 at jobs.c:862 > 20 registers were unavailable. >=20 > (lldb) print/x stack_address_before_fork > (uintptr_t) $0 =3D 0x0000ffffffffce80 >=20 > (lldb) print/x stack_address_after_fork > (uintptr_t) $1 =3D 0x0000ffffffffd160 >=20 > (lldb) print/x main_handler > (jmploc) $2 =3D { > loc =3D { > [0] =3D { > _jb =3D { > [0] =3D 0x0000ffffffffdb60fb5d25837d7ff700 > [1] =3D 0x00000000000000170000ffffffffdc08 > [2] =3D 0x00000000004320380000000000434a10 > [3] =3D 0x00000000000000000000000000000000 > [4] =3D 0x00000000000000000000000000000000 > [5] =3D 0x00000000000000000000000000000000 > [6] =3D 0x0000000000410c800000ffffffffdbb0 > . . . >=20 > (main_handler is from setjmp in main.) >=20 > In this example of the context for sh`forkshell after the fork: >=20 > fp =3D 0x0000ffffffffcee0 < sp =3D 0x0000ffffffffd180 < = 0x0000ffffffffdbb0 >=20 > That explains why the bt stopped with frame #3: part of the stack > had been trashed by the calls to example_stack_address and to abort > (and what its internal call chain involves), unlike the prior example > that trashed memory outside the active stack region. >=20 > Compared to the prior example's sp =3D 0x0000ffffffffe980 the > distance from the frame pointer in sh`forkshell is much smaller this > time --but it is still in the same (wrong) direction. >=20 > This illustrates the variability in the bad sp value from bad-case > to bad-case. >=20 > I plan to leave the repeated builds running for a time to accumulate > some more core files based on this new test. If any examples happen > of sp decreasing instead of increasing, the code should core dump for > those as well, unlike my prior testing. >=20 >=20 >=20 > Context details: >=20 > # more /usr/src/sys/arm64/conf/GENERIC-NODBG > # > # GENERIC -- Custom configuration for the arm64/aarch64 > # >=20 > include "GENERIC" >=20 > ident GENERIC-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # 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 >=20 > # 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 >=20 >=20 > The -r312982 variant is a cross build with -mcpu=3Dcortex-a53 > specified: >=20 > # more ~/src.configs/src.conf.pine64-clang-bootstrap.amd64-host=20 > TO_TYPE=3Daarch64 > TOOLS_TO_TYPE=3D${TO_TYPE} > # > KERNCONF=3DGENERIC-NODBG > TARGET=3Darm64 > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > WITHOUT_LIBSOFT=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D > # > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > XCFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} > XCXXFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. > # > XCFLAGS+=3D -mcpu=3Dcortex-a53 > XCXXFLAGS+=3D -mcpu=3Dcortex-a53 > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. >=20 >=20 > In order to cut down on the Spurious interrupt notices on the > console I eventually did the below personal adjustment specific > to my context (and it is in use above): >=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 > The added message block was to report unexpected values for the > exit path. None have been reported from there. >=20 > The gic.c changes eliminated all the Spurious interrupt notices = --which > made the console more reasonable to use. >=20 > But so far I've not come up with a way to discover what leads > to the irq=3D=3D1023 reports for the original message context. > [Interrupts handled by one core but sent to multiple cores?] >=20 >=20 > Other notes: >=20 > I switched to Andrew Turner's freebsd Email address. It might be more > appropriate. I also fixed the mistyped "Contex-a53" in the Subject to > say "Cortex-a53". From owner-freebsd-arm@freebsd.org Tue Feb 14 15:57: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 789A0CDF67E; Tue, 14 Feb 2017 15:57:14 +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 D5B0916D1; Tue, 14 Feb 2017 15:57:13 +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; Tue, 14 Feb 2017 16:56:54 +0100 Received: from HOBEX11.hob.de ([fe80::b99f:1c54:7122:49b4]) by HOBEX12.hob.de ([::1]) with mapi id 14.02.0387.000; Tue, 14 Feb 2017 16:57:01 +0100 From: "Meyer, Wolfgang" To: "'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: AdKDrhWkwDVgm5wmQJOmHv89OT16WQACrmdQAMgAHTA= Date: Tue, 14 Feb 2017 15:57:01 +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: 4EB48F3AB80C295018F1D5 x-esetresult: clean, is OK x-esetid: 4EB48F3AB80C295018F1D5 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: Tue, 14 Feb 2017 15:57:14 -0000 > -----Original Message----- > From: Meyer, Wolfgang > Sent: Freitag, 10. Februar 2017 17:19 > 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[?] > > > 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 > > that 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 libraries. > > 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 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 > > cross- compiled package for aarch64 in poudriere. And the gains are > > quite significant (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 > appreciated. > > > > > After building some more packages besides of pkg it seems, I am still not > there yet. There is quite some fallout mainly during configure due to not > getting the right searchpath for the libraries. Maybe creating a symlink = on the > root directory at the path of the expected sysroot directory might heal t= his. In the meantime I figured out how to tweak the jail to get it to cross-buil= d the desired subset of ports without fallout. Some of the changes are mere= ly cosmetic but lead to a cleaner overall configuration in my point of view= . Changes to the previously described configuration include: - before starting the kernel-toolchain build make two nullfs-mounts: > mount -t nullfs //usr/src /usr/src > mount -t nullfs //usr/obj /usr/obj - after kernel-toolchain build and copying //usr/ob= j/usr/src/tmp/* to //usr/aarch64-freebsd delete //usr/obj/usr/src/tmp and create a symlink to / at //usr/obj/usr/src/tmp Now all tested ports cross-build fine with varying speed gains compared to = the qemu-user emulated (in the ballpark of two- to eightfold, but not analy= sed in detail). ________________________________ 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 Tue Feb 14 16:35: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 24CA6CDF61A for ; Tue, 14 Feb 2017 16:35:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-71.reflexion.net [208.70.210.71]) (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 CB97412C8 for ; Tue, 14 Feb 2017 16:35:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21759 invoked from network); 14 Feb 2017 16:35:55 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Feb 2017 16:35:55 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Tue, 14 Feb 2017 11:35:55 -0500 (EST) Received: (qmail 31960 invoked from network); 14 Feb 2017 16:35:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Feb 2017 16:35:55 -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 009B4EC788F; Tue, 14 Feb 2017 08:35:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: A potential fix for arm64's: sh`forkshell child-process path after fork sometimes has a bad stack pointer value From: Mark Millard In-Reply-To: <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> Date: Tue, 14 Feb 2017 08:35:54 -0800 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> References: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> To: andrew@freebsd.org, Shawn Webb , Tom Vijlbrief 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, 14 Feb 2017 16:35:58 -0000 The following change has let my test run for 8.5 hours so far without a fork-failure in sh`forkshell : # svnlite diff /usr/src/sys/arm64/arm64/swtch.S Index: /usr/src/sys/arm64/arm64/swtch.S =================================================================== --- /usr/src/sys/arm64/arm64/swtch.S (revision 312982) +++ /usr/src/sys/arm64/arm64/swtch.S (working copy) @@ -241,6 +241,12 @@ mov fp, #0 /* Stack traceback stops here. */ bl _C_LABEL(fork_exit) + /* + * Disable interrupts to avoid + * overwriting sp_el0 and spsr_el1 by an IRQ exception. + */ + msr daifset, #2 + /* Restore sp and lr */ ldp x0, x1, [sp] msr sp_el0, x0 @@ -263,12 +269,6 @@ ldp x28, x29, [sp, #TF_X + 28 * 8] /* Skip x30 as it was restored above as lr */ - /* - * Disable interrupts to avoid - * overwriting spsr_el1 by an IRQ exception. - */ - msr daifset, #2 - /* Restore elr and spsr */ ldp x0, x1, [sp, #16] msr elr_el1, x0 I'm going to switch to attempting a self-hosted buildworld buildkernel again. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Feb 14 16:57:23 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 CF9F3CDFA48 for ; Tue, 14 Feb 2017 16:57:23 +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 9C6031D78 for ; Tue, 14 Feb 2017 16:57:23 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-142.nat-2.net.cam.ac.uk [131.111.5.142]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 8E7ABD8561; Tue, 14 Feb 2017 16:50:53 +0000 (UTC) Date: Tue, 14 Feb 2017 16:56:44 +0000 From: Andrew Turner To: Mark Millard Cc: Shawn Webb , Tom Vijlbrief , freebsd-arm Subject: Re: A potential fix for arm64's: sh`forkshell child-process path after fork sometimes has a bad stack pointer value Message-ID: <20170214165644.15dedf6e@zapp> In-Reply-To: <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> References: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> 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, 14 Feb 2017 16:57:23 -0000 On Tue, 14 Feb 2017 08:35:54 -0800 Mark Millard wrote: > The following change has let my test run for 8.5 hours so far without > a fork-failure in sh`forkshell : > > # svnlite diff /usr/src/sys/arm64/arm64/swtch.S > Index: /usr/src/sys/arm64/arm64/swtch.S > =================================================================== > --- /usr/src/sys/arm64/arm64/swtch.S (revision 312982) > +++ /usr/src/sys/arm64/arm64/swtch.S (working copy) > @@ -241,6 +241,12 @@ > mov fp, #0 /* Stack traceback stops here. */ > bl _C_LABEL(fork_exit) > > + /* > + * Disable interrupts to avoid > + * overwriting sp_el0 and spsr_el1 by an IRQ exception. > + */ > + msr daifset, #2 > + > /* Restore sp and lr */ > ldp x0, x1, [sp] > msr sp_el0, x0 > @@ -263,12 +269,6 @@ > ldp x28, x29, [sp, #TF_X + 28 * 8] > /* Skip x30 as it was restored above as lr */ > > - /* > - * Disable interrupts to avoid > - * overwriting spsr_el1 by an IRQ exception. > - */ > - msr daifset, #2 > - > /* Restore elr and spsr */ > ldp x0, x1, [sp, #16] > msr elr_el1, x0 > > I'm going to switch to attempting a self-hosted buildworld > buildkernel again. Can you try the patch in https://reviews.freebsd.org/D9593. It moves loading of sp_el0 until after interrupts have been disabled. Andrew From owner-freebsd-arm@freebsd.org Tue Feb 14 17:18: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 24269CDF089 for ; Tue, 14 Feb 2017 17:18:01 +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 CA2EE1C9A for ; Tue, 14 Feb 2017 17:18:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15483 invoked from network); 14 Feb 2017 17:17:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2017 17:17:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Tue, 14 Feb 2017 12:17:58 -0500 (EST) Received: (qmail 11758 invoked from network); 14 Feb 2017 17:17:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Feb 2017 17:17:58 -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 EFA15EC86D9; Tue, 14 Feb 2017 09:17:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A potential fix for arm64's: sh`forkshell child-process path after fork sometimes has a bad stack pointer value From: Mark Millard In-Reply-To: <20170214165644.15dedf6e@zapp> Date: Tue, 14 Feb 2017 09:17:57 -0800 Cc: Shawn Webb , Tom Vijlbrief , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <6EED2BFF-CAFB-4F58-8D0D-8E060319278C@dsl-only.net> References: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> <20170214165644.15dedf6e@zapp> To: Andrew Turner 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, 14 Feb 2017 17:18:01 -0000 On 2017-Feb-14, at 8:56 AM, Andrew Turner wrote: On Tue, 14 Feb 2017 08:35:54 -0800 > Mark Millard wrote: > >> The following change has let my test run for 8.5 hours so far without >> a fork-failure in sh`forkshell : >> >> # svnlite diff /usr/src/sys/arm64/arm64/swtch.S >> Index: /usr/src/sys/arm64/arm64/swtch.S >> =================================================================== >> --- /usr/src/sys/arm64/arm64/swtch.S (revision 312982) >> +++ /usr/src/sys/arm64/arm64/swtch.S (working copy) >> @@ -241,6 +241,12 @@ >> mov fp, #0 /* Stack traceback stops here. */ >> bl _C_LABEL(fork_exit) >> >> + /* >> + * Disable interrupts to avoid >> + * overwriting sp_el0 and spsr_el1 by an IRQ exception. >> + */ >> + msr daifset, #2 >> + >> /* Restore sp and lr */ >> ldp x0, x1, [sp] >> msr sp_el0, x0 >> @@ -263,12 +269,6 @@ >> ldp x28, x29, [sp, #TF_X + 28 * 8] >> /* Skip x30 as it was restored above as lr */ >> >> - /* >> - * Disable interrupts to avoid >> - * overwriting spsr_el1 by an IRQ exception. >> - */ >> - msr daifset, #2 >> - >> /* Restore elr and spsr */ >> ldp x0, x1, [sp, #16] >> msr elr_el1, x0 >> >> I'm going to switch to attempting a self-hosted buildworld >> buildkernel again. > > Can you try the patch in https://reviews.freebsd.org/D9593. It moves > loading of sp_el0 until after interrupts have been disabled. > > Andrew Sure. I'll stop the self-hosted buildworld buildkernel and switch over to your source. One minor point: /* Skip x30 as it was restored above as lr */ now should say something like: /* Skip x30 as it is restored below as lr */ === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Feb 15 01:08: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 8A625CDF223 for ; Wed, 15 Feb 2017 01:08:31 +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 4F2801697 for ; Wed, 15 Feb 2017 01:08:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7340 invoked from network); 15 Feb 2017 01:10:29 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Feb 2017 01:10:29 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Tue, 14 Feb 2017 20:08:28 -0500 (EST) Received: (qmail 27247 invoked from network); 15 Feb 2017 01:08:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Feb 2017 01:08: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 B7D77EC88F3; Tue, 14 Feb 2017 17:08:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A potential fix for arm64's: sh`forkshell child-process path after fork sometimes has a bad stack pointer value From: Mark Millard In-Reply-To: <6EED2BFF-CAFB-4F58-8D0D-8E060319278C@dsl-only.net> Date: Tue, 14 Feb 2017 17:08:27 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <142FC38B-48F6-4456-8CD1-D180EDB6A73C@dsl-only.net> References: <2D04FF37-DEC8-42CE-961D-AE8CD58A0EAA@dsl-only.net> <93064627-5F72-4167-90B1-0A98ABF4C99C@dsl-only.net> <3BC697B9-4A3E-49FF-AB11-1106E2EF8399@dsl-only.net> <20170214165644.15dedf6e@zapp> <6EED2BFF-CAFB-4F58-8D0D-8E060319278C@dsl-only.net> To: Andrew Turner 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, 15 Feb 2017 01:08:31 -0000 On 2017-Feb-14, at 9:17 AM, Mark Millard wrote: > On 2017-Feb-14, at 8:56 AM, Andrew Turner = wrote: >=20 > On Tue, 14 Feb 2017 08:35:54 -0800 >> Mark Millard wrote: >>=20 >>> The following change has let my test run for 8.5 hours so far = without >>> a fork-failure in sh`forkshell : >>>=20 >>> # svnlite diff /usr/src/sys/arm64/arm64/swtch.S >>> Index: /usr/src/sys/arm64/arm64/swtch.S >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/arm64/arm64/swtch.S (revision 312982) >>> +++ /usr/src/sys/arm64/arm64/swtch.S (working copy) >>> @@ -241,6 +241,12 @@ >>> mov fp, #0 /* Stack traceback stops here. */ >>> bl _C_LABEL(fork_exit) >>>=20 >>> + /* >>> + * Disable interrupts to avoid >>> + * overwriting sp_el0 and spsr_el1 by an IRQ exception. >>> + */ >>> + msr daifset, #2 >>> + >>> /* Restore sp and lr */ >>> ldp x0, x1, [sp] >>> msr sp_el0, x0 >>> @@ -263,12 +269,6 @@ >>> ldp x28, x29, [sp, #TF_X + 28 * 8] >>> /* Skip x30 as it was restored above as lr */ >>>=20 >>> - /* >>> - * Disable interrupts to avoid >>> - * overwriting spsr_el1 by an IRQ exception. >>> - */ >>> - msr daifset, #2 >>> - >>> /* Restore elr and spsr */ >>> ldp x0, x1, [sp, #16] >>> msr elr_el1, x0 >>>=20 >>> I'm going to switch to attempting a self-hosted buildworld >>> buildkernel again. >>=20 >> Can you try the patch in https://reviews.freebsd.org/D9593. It moves >> loading of sp_el0 until after interrupts have been disabled. >>=20 >> Andrew >=20 > Sure. I'll stop the self-hosted buildworld buildkernel and > switch over to your source. >=20 > One minor point: >=20 > /* Skip x30 as it was restored above as lr */ >=20 > now should say something like: >=20 > /* Skip x30 as it is restored below as lr */ As reported on https://reviews.freebsd.org/D9593 the buildworld buildkernel test stopped in buildworld with two sh processed failing. But the core files do not suggest a stack corruption to me, nor was fork active. My test code recorded its before and after fork stack address examples and they were equal as they should be. It appeared that simply starting the buildworld buildkernel would continue on so I restarted it. It has in fact continued on and is still building. I see no reason to take the stoppage as something to count against the change. And I'll say so in new comments in https://reviews.freebsd.org/D9593 once the build completes or fails and I report on that. Failure details (both cores are basically the same for these details): (lldb) up frame #9: 0x000000004054c82c libc.so.7`ifree(tsd=3D, = ptr=3D, tcache=3D, slow_path=3D) = + 304 at jemalloc_jemalloc.c:1889 1886 usize =3D isalloc(tsd_tsdn(tsd), ptr, = config_prof); 1887 prof_free(tsd, ptr, usize); 1888 } else if (config_stats || config_valgrind) -> 1889 usize =3D isalloc(tsd_tsdn(tsd), ptr, = config_prof); 1890 if (config_stats) 1891 *tsd_thread_deallocatedp_get(tsd) +=3D usize; 1892=09 (lldb) print config_stats (const bool) $0 =3D true (lldb) print config_valgrind (const bool) $1 =3D false So the new failure was actually during config_stats activity, which is apparently enabled by default for how I built -r312982 . The actual abort initiation was from: (lldb) up frame #3: 0x00000000405340fc libc.so.7`huge_node_get [inlined] = __je_rtree_get(dependent=3Dtrue) + 308 at rtree.h:328 325 RTREE_GET_LEAF(RTREE_HEIGHT_MAX-1) 326 #undef RTREE_GET_SUBTREE 327 #undef RTREE_GET_LEAF -> 328 default: not_reached(); 329 } 330 #undef RTREE_GET_BIAS 331 not_reached(); The back traces look similar to this one of the pair: (lldb) bt * thread #1: tid =3D 100137, 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: 0x00000000405340fc libc.so.7`huge_node_get [inlined] = __je_rtree_get(dependent=3Dtrue) + 308 at rtree.h:328 frame #4: 0x00000000405340dc libc.so.7`huge_node_get [inlined] = __je_chunk_lookup(dependent=3Dtrue) at chunk.h:89 frame #5: 0x00000000405340dc = libc.so.7`huge_node_get(ptr=3D) + 276 at jemalloc_huge.c:11 frame #6: 0x0000000040534114 = libc.so.7`__je_huge_salloc(tsdn=3D, ptr=3D) + = 24 at jemalloc_huge.c:434 frame #7: 0x000000004054c84c libc.so.7`ifree [inlined] = __je_arena_salloc(demote=3Dfalse) + 32 at arena.h:1426 frame #8: 0x000000004054c82c libc.so.7`ifree [inlined] = __je_isalloc(demote=3Dfalse) at jemalloc_internal.h:1045 frame #9: 0x000000004054c82c libc.so.7`ifree(tsd=3D, = ptr=3D, tcache=3D, slow_path=3D) = + 304 at jemalloc_jemalloc.c:1889 frame #10: 0x000000004054cd94 = libc.so.7`__free(ptr=3D0x0000000040a17520) + 148 at = jemalloc_jemalloc.c:2016 frame #11: 0x0000000000411328 sh`ckfree(p=3D) + 32 at = memalloc.c:88 frame #12: 0x0000000000407cd8 sh`clearcmdentry + 76 at exec.c:505 frame #13: 0x0000000000406bfc sh`evalcommand(cmd=3D, = flags=3D, backcmd=3D) + 3476 at eval.c:1182 frame #14: 0x0000000000405570 sh`evaltree(n=3D0x0000000040a1c270, = flags=3D) + 212 at eval.c:290 frame #15: 0x000000000041105c sh`cmdloop(top=3D) + 252 = at main.c:231 frame #16: 0x0000000000410ed0 sh`main(argc=3D, = argv=3D) + 660 at main.c:178 frame #17: 0x0000000000402f30 sh`__start + 360 frame #18: 0x0000000040434658 ld-elf.so.1`.rtld_start + 24 at = rtld_start.S:41 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Feb 15 16:14: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 D7DB5CE03F1 for ; Wed, 15 Feb 2017 16:14:05 +0000 (UTC) (envelope-from jletutour@deltadore.com) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40108.outbound.protection.outlook.com [40.107.4.108]) (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 31E9CEC; Wed, 15 Feb 2017 16:14:04 +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=vtVohynTu/nR+aE26Sy8J/Sn4xX+e/rbMIEeLKlKPUQ=; b=qUo9VWbSEoH48L6DpYIKh8kUiwT239XGx3FKXCOXBUbQRuMaZ0zzKxty6mRVhdMcJr04VKpFTY5dspv9bojb+XD4PwTg3XJujvDzATtNLxoAydnPosHa86RGEv3kl4JtmZmsA41n83IeZY8AW5Un3pdi0cL7+aF8IIDHnhjWFZw= Received: from VI1PR07MB1406.eurprd07.prod.outlook.com (10.165.238.12) by VI1PR07MB1408.eurprd07.prod.outlook.com (10.165.238.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Wed, 15 Feb 2017 16:14:01 +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.0919.013; Wed, 15 Feb 2017 16:14:01 +0000 From: LE TUTOUR Jean To: Ian Lepore , Warner Losh CC: "freebsd-arm@freebsd.org" Subject: RE: 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: AQHSg8P1CgJqoHKo4U6vWv4RHMkUXKFmi7+A Date: Wed, 15 Feb 2017 16:14:01 +0000 Message-ID: References: <1486748072.10020.253.camel@freebsd.org> In-Reply-To: <1486748072.10020.253.camel@freebsd.org> 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: ded598f8-12a1-404a-3a1b-08d455bda778 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB1408; x-microsoft-exchange-diagnostics: 1; VI1PR07MB1408; 7:OrLxE9ckMyHURszxu0CrD6tOzebpZbhMinZrVRQ4rIp6QzwDktg90vb1KfdsdAdBG+XVnAuVItXiYRnxLcOi1xZC1fAUJKmra4PdTH1Pqtx98FHLrbQZFM7owajpseWIl/GSKxmSiEkvTG6G8p0fm0EYkbNQ0aLjEYHohmGuF1V3gQCXqCVjKsj5HkyCGug6DjKMN/O50si68DaRSP53hJaYcCOmvXtLfShXPecov6OC35j+fEjRM9Mssfcn39iSyRVigbffw0EFEcvEySSE13scWKjm87xsaeVD60OIBOhQaAtZPLA/NB61444inXWZxDPOUzxN7nkfMPPv9Ioop268RTMr2nyKMAoSKkDkF/I/jVYifEXJ7XKmze/3Czi4SVPzie3l/lOFU0erQIhnXjVKf81C+cc7hHmDlkkIYQ6FKprRbfxiAvruR2cE4mtMzvsjIDpGdRnfHfVvrcWYTHa75qtzz9gp6yPpeh9/4ddkBotenGC/5sCM9RA2FSPMBYQ+irDVyu35g4ftKyptcw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:VI1PR07MB1408; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1408; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(39450400003)(189002)(24454002)(377424004)(46034005)(40224003)(199003)(55784002)(76176999)(33656002)(8676002)(3660700001)(305945005)(101416001)(7736002)(50986999)(3280700002)(86362001)(54356999)(74316002)(575784001)(97736004)(7696004)(38730400002)(2906002)(122556002)(53386004)(189998001)(92566002)(2900100001)(66066001)(53936002)(106356001)(106116001)(5660300001)(105586002)(966004)(4326007)(81166006)(6246003)(77096006)(6506006)(229853002)(5890100001)(102836003)(3846002)(389900002)(2950100002)(6116002)(8936002)(6436002)(55016002)(9686003)(81156014)(99286003)(25786008)(68736007)(6306002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1408; 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: 15 Feb 2017 16:14:01.1095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 23f7ef23-d797-403b-9679-644130ba65cf X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1408 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, 15 Feb 2017 16:14:05 -0000 SGVsbG8gSWFuDQpUaGFua3MNCiAoIEkndmUgIHRyaWVkIG9ubHkgdGhlIG90ZyByb290ICkNClRo ZSBwcm9ibGVtIGlzIHRoYXQgICBJIGRvbuKAmXQgIGtub3cgd2VsbCBmcmVlYnNkICwgICggYnV0 IGJldHRlciBsaW51eCkNCg0KSGVyZSBpcyB3aGF0IEkgaGF2ZSBub3cgb24gdXNiMQ0KDQpWVDog aW5pdGlhbGl6ZSB3aXRoIG5ldyBWVCBkcml2ZXIgImZiIi4NCm1tYzA6IE5vIGNvbXBhdGlibGUg Y2FyZHMgZm91bmQgb24gYnVzDQptbWNzZDA6IDRHQiA8U0RIQyBTUzA0RyA4LjAgU04gNTMyQzQ4 RUUgTUZHIDEyLzIwMTUgYnkgMyBTRD4gYXQgbW1jMSA1MC4wTUh6LzRiaXQvNjU1MzUtYmxvY2sN ClJlbGVhc2UgQVBzDQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L3Vmcy9yb290 ZnMgW3J3XS4uLg0KdWh1YjA6IDEgcG9ydCB3aXRoIDEgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQN CnVodWIxOiAxIHBvcnQgd2l0aCAxIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpXQVJOSU5HOiAv IHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZA0Kd2FybmluZzogbm8gdGltZS1vZi1kYXkgY2xv Y2sgcmVnaXN0ZXJlZCwgc3lzdGVtIHRpbWUgd2lsbCBub3QgYmUgc2V0IGFjY3VyYXRlbHkNCnJh bmRvbTogdW5ibG9ja2luZyBkZXZpY2UuDQpmZmVjMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERP V04NCmZmZWMwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCnVnZW4xLjI6IDxVU0IgRGlzayAy LjA+IGF0IHVzYnVzMQ0KdW1hc3MwIG9uIHVodWIxDQp1bWFzczA6IDxVU0IgRGlzayAyLjAsIGNs YXNzIDAvMCwgcmV2IDIuMDAvMi4wMCwgYWRkciAyPiBvbiB1c2J1czENCmRhMCBhdCB1bWFzcy1z aW0wIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMA0KZGEwOiA8VmVuZG9yQ28gUHJvZHVjdENv ZGUgMi4wMD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU1BDLTIgU0NTSSBkZXZpY2UNCmRhMDog U2VyaWFsIE51bWJlciA5MjA3MTMwRDhDMjA4MzAzNTU1DQpkYTA6IDQwLjAwME1CL3MgdHJhbnNm ZXJzDQpkYTA6IDc3OTlNQiAoMTU5NzI4ODIgNTEyIGJ5dGUgc2VjdG9ycykNCmRhMDogcXVpcmtz PTB4MjxOT182X0JZVEU+DQpyb290QGlteDY6L2hvbWUvZnJlZWJzZCAjIGxzIC9kZXYvZGEqDQov ZGV2L2RhMCAgICAgICAgL2Rldi9kYTBzMQ0KDQpyb290QGlteDY6L2hvbWUvZnJlZWJzZCAjIGNk IC9tZWRpYQ0Kcm9vdEBpbXg2Oi9tZWRpYSAjIGxzDQpyb290QGlteDY6L21lZGlhICMgbW91bnQg L2Rldi9kYTBzMSAvbWVkaWENCm1vdW50OiAvZGV2L2RhMHMxOiBJbnZhbGlkIGFyZ3VtZW50DQpy b290QGlteDY6L21lZGlhICMgbW91bnQgL2Rldi9kYTAgL21lZGlhDQptb3VudDogL2Rldi9kYTA6 IEludmFsaWQgYXJndW1lbnQNCnJvb3RAaW14NjovbWVkaWEgIyBjZCAuLg0Kcm9vdEBpbXg2Oi8g IyBtb3VudCAvZGV2L2RhMCAvbWVkaWENCm1vdW50OiAvZGV2L2RhMDogSW52YWxpZCBhcmd1bWVu dA0KDQoNCmRvIHlvdSBoYXZlIGFuIGlkZWEgYWJvdXQgdGhhdDoNCiAgd2h5IEkgZG9u4oCZdCBt YW5hZ2UgdG8gbW91bnQgIG15IFVTQiBLZXkgLCAvIGluIEZBVA0KDQpraW5kICByZWdhcmRzDQpK ZWFuDQoNCg0KDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogSWFuIExl cG9yZSBbbWFpbHRvOmlhbkBmcmVlYnNkLm9yZ10NCkVudm95w6kgOiB2ZW5kcmVkaSAxMCBmw6l2 cmllciAyMDE3IDE4OjM1DQrDgCA6IExFIFRVVE9VUiBKZWFuOyBXYXJuZXIgTG9zaA0KQ2MgOiBm cmVlYnNkLWFybUBmcmVlYnNkLm9yZw0KT2JqZXQgOiBSZTogdXNiIHRyb3VibGUgY3Vib3ggYnNk IDExIC0gRnJlZUJTRCAxMS4wLVNUQUJMRSAjMCByMzEwMzU5OiBXZWQgRGVjIDIxIDE4OjE5OjEx IFVUQyAyMDE2DQoNCk9uIEZyaSwgMjAxNy0wMi0xMCBhdCAxNjo1OSArMDAwMCwgTEUgVFVUT1VS IEplYW4gd3JvdGU6DQo+IEhlbGxvLCBmcmVlYnNkIHRlYW06DQo+DQo+IFBsZWFzZSBzZWUgbGlz dGluZyBiZWxvdw0KPiBJIGhhdmUgdHdvIHByb2JsZW1zOg0KPg0KPiA+DQo+ID4gdXNiIHNlZW1z IG5vdCB3b3JrIDogbm90aGluZyBpbiBkbWVzZyAsIHdoZW4gSSBwbHVnIHNvbWV0aGluZyBpbiB1 c2INCj4gPiAvc2Jpbi9zaHV0ZG93bjogUGVybWlzc2lvbiBkZW5pZWQuICA6ICBJIGFtICBmcmVl YnNkL2ZyZWVic2QNCj4gRG9uJ3QgeW91IGhhdmUgYW55IGlkZWEgPyBJdCB3b3JrcyBvbiBsaW51 eCAsIGdlbmVyYWxseSwgc29ycnkgV2hpdGggYQ0KPiBkZWJpYW4gIG9uIHRoZSBzYW1lIHBsYXRl Zm9ybSwgbm8gcHJvYmxlbXMNCj4NCj4gWy4uLl0NCg0KRm9yIHNodXRkb3duLCB5b3UgbXVzdCBi ZSByb290LCBvciBhIG1lbWJlciBvZiB0aGUgZ3JvdXAgJ29wZXJhdG9yJyB0byB1c2UgdGhlIGNv bW1hbmQuDQoNCkkgZG9uJ3QgaGF2ZSB0aW1lIHJpZ2h0IG5vdyB0byBkaWcgaW50byB0aGlzIHRv byBkZWVwbHksIGJ1dCBJIGNhbiBhZGQgYSBmZXcgY29tbWVudHMgYWJvdXQgdXNiIG9uIGlteDYg c3lzdGVtcy4uLg0KDQpVc2IgaXMga25vd24gdG8gd29yayBvbiBjdWJveCAod2UgdXNlIHRoZSBz YW1lIHVTT00gbW9kdWxlIGluIHByb2R1Y3RzIGF0ICR3b3JrKS4NCg0KVGhlIHVzYiByb290IHBv cnRzIG9uIGlteDYgZG8gbm90IHJlY29nbml6ZSBkZXZpY2UtcmVtb3ZlZCBldmVudHMgZm9yIHNv bWUgcmVhc29uLiAgWW91IGNhbiBwbHVnIGFueSBkZXZpY2UgaW50byB0aGUgaG9zdCBwb3J0IGFu ZCBpdCBzaG91bGQgYmUgcmVjb2duaXplZCwgYnV0IHdoZW4geW91IHJlbW92ZSBpdCB0aGUgc3lz dGVtIGRvZXNuJ3Qgbm90aWNlLiAgVGhhdCBtZWFucyBpZiB5b3UgcGx1ZyBzb21ldGhpbmcgZWxz ZSBpbiwgdGhhdCBhbHNvIGRvZXNuJ3QgZ2V0IG5vdGljZWQsIGFuZCBpdCdzIHN0dWNrIHRoYXQg d2F5IHVudGlsIHRoZSBuZXh0IHJlYm9vdC4gIFlvdSBjYW4gd29yayBhcm91bmQgdGhhdCBieSBw bHVnZ2luZyBpbiBhIGh1YiAtLSBpdCBkb2VzIG5vdGljZSB3aGVuIHlvdSByZW1vdmUgZGV2aWNl cyBmcm9tIGh1YiBwb3J0cy4NCg0KT24gdGhlIHN0YWJsZS0xMSBicmFuY2gsIHRoZSB1c2IgaG9z dCBwb3J0IHNob3VsZCB3b3JrLCBidXQgdGhlIE9URyBwb3J0IGlzIG5vdCBwcm9wZXJseSBjb25m aWd1cmVkIGFzIGEgc2Vjb25kIGhvc3QgcG9ydC4gIE9uIGEgY3Vib3ggdGhhdCB3b3VsZCBhcHBl YXIgYXMgb25seSBvbmUgb2YgdGhlIHNsb3RzIHdvcmtpbmcgKEkgY2FuJ3QgcmVtZW1iZXIgaWYg aXQncyB0aGUgdXBwZXIgb3IgbG93ZXIgY29ubmVjdG9yIHRoYXQgd29ya3MpLg0KDQpJIGZpeGVk IHRoZSBPVEctYXMtaG9zdCBpbiAxMi1jdXJyZW50IHJlY2VudGx5IChyMzExODUwKSwgYnV0IGhh dmVuJ3QgTUZDJ2QgdGhlIGZpeCB0byB0aGUgc3RhYmxlLTExIG9yIDEwIGJyYW5jaGVzIHlldC4g IE1heWJlIEkgY2FuIGZpbmQgdGltZSB0byBkbyB0aGF0IHRoaXMgd2Vla2VuZC4NCg0KLS0gSWFu DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCkzigJl1c2FnZSBkZSBsYSBtZXNzYWdlcmllIHByb2Zlc3Npb25uZWxsZSBvdSBkdSB0w6ls w6lwaG9uZSBlbiBzb2lyw6llIG91IGVuIGRlaG9ycyBkZSBqb3VycyB0cmF2YWlsbMOpcyBkb2l0 IMOqdHJlIGp1c3RpZmnDqSBwYXIgbGEgZ3Jhdml0w6kgZXQgbOKAmXVyZ2VuY2UgZXQvb3UgbOKA mWltcG9ydGFuY2UgZXhjZXB0aW9ubmVsbGUgZHUgc3VqZXQgdHJhaXTDqS4gSWwgZXN0IHJhcHBl bMOpIHF1ZSBudWwgbuKAmWVzdCwgcXVvaSBxdeKAmWlsIGVuIHNvaXQsIHRlbnUgZGUgcsOpcG9u ZHJlIGF1eCBtYWlscyBvdSBtZXNzYWdlcywgU01TLCBhZHJlc3PDqXMgZHVyYW50IGNlcyBww6ly aW9kZXMNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KW2h0dHA6Ly9tYWlsLmRlbHRhZG9yZS5jb20vaW1hZ2VzL2xvZ29fZGVsdGFkb3Jl X2NvdWwuR0lGXQ0KaHR0cDovL3d3dy5kZWx0YWRvcmUuZnINCg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KQ2UgbWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBz b250IMOpdGFibGlzIMOgIGwnIGF0dGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWly ZXMgZXQgc29udCBjb25maWRlbnRpZWxzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCBtZXJjaSBkZSBsZSBkw6l0cnVpcmUgZXQgZCdlbiBhdmVydGlyIGltbcOpZGlhdGVt ZW50IGwnZXhww6lkaXRldXIuDQoNClRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWVzIGFuZCBpcyBjb25maWRlbnRpYWwu IElmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBh bmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQo= From owner-freebsd-arm@freebsd.org Wed Feb 15 16:21: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 637C0CE054A for ; Wed, 15 Feb 2017 16:21:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 2E0327DF; Wed, 15 Feb 2017 16:21:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BCFF41FE025; Wed, 15 Feb 2017 17:20:45 +0100 (CET) Subject: Re: usb trouble cubox bsd 11 - FreeBSD 11.0-STABLE #0 r310359: Wed Dec 21 18:19:11 UTC 2016 To: LE TUTOUR Jean , Ian Lepore , Warner Losh References: <1486748072.10020.253.camel@freebsd.org> Cc: "freebsd-arm@freebsd.org" From: Hans Petter Selasky Message-ID: <9a04c038-8f2a-66e9-5c9e-e74bcc2b74b8@selasky.org> Date: Wed, 15 Feb 2017 17:20:16 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; 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: Wed, 15 Feb 2017 16:21:10 -0000 On 02/15/17 17:14, LE TUTOUR Jean wrote: > root@imx6:/home/freebsd # cd /media > root@imx6:/media # ls > root@imx6:/media # mount /dev/da0s1 /media > mount: /dev/da0s1: Invalid argument > root@imx6:/media # mount /dev/da0 /media > mount: /dev/da0: Invalid argument > root@imx6:/media # cd .. > root@imx6:/ # mount /dev/da0 /media > mount: /dev/da0: Invalid argument > > > do you have an idea about that: > why I don’t manage to mount my USB Key , / in FAT With FreeBSD mount you need to specify msdosfs: mount -t msdosfs /dev/da0s1 /media --HPS From owner-freebsd-arm@freebsd.org Wed Feb 15 16:21: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 C048CCE058C for ; Wed, 15 Feb 2017 16:21:29 +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 A40FD87B for ; Wed, 15 Feb 2017 16:21:29 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: d519167d-f39a-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 d519167d-f39a-11e6-ba57-8bc134ee460a; Wed, 15 Feb 2017 16:21:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1FGLMGi001335; Wed, 15 Feb 2017 09:21:22 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1487175682.36530.2.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: Wed, 15 Feb 2017 09:21:22 -0700 In-Reply-To: References: <1486748072.10020.253.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-7" 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: Wed, 15 Feb 2017 16:21:29 -0000 On Wed, 2017-02-15 at 16:14 +0000, LE TUTOUR Jean wrote: > Hello Ian > Thanks >  ( I've  tried only the otg root ) > The problem is that   I don¢t  know well freebsd ,  ( but better > linux) > > Here is what I have now on usb1 > > VT: initialize with new VT driver "fb". > mmc0: No compatible cards found on bus > mmcsd0: 4GB at mmc1 > 50.0MHz/4bit/65535-block > Release APs > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > uhub0: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > WARNING: / was not properly dismounted > warning: no time-of-day clock registered, system time will not be set > accurately > random: unblocking device. > ffec0: link state changed to DOWN > ffec0: link state changed to UP > ugen1.2: at usbus1 > umass0 on uhub1 > umass0: on usbus1 > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SPC-2 SCSI > device > da0: Serial Number 9207130D8C208303555 > da0: 40.000MB/s transfers > da0: 7799MB (15972882 512 byte sectors) > da0: quirks=0x2 > root@imx6:/home/freebsd # ls /dev/da* > /dev/da0        /dev/da0s1 > > root@imx6:/home/freebsd # cd /media > root@imx6:/media # ls > root@imx6:/media # mount /dev/da0s1 /media > mount: /dev/da0s1: Invalid argument > root@imx6:/media # mount /dev/da0 /media > mount: /dev/da0: Invalid argument > root@imx6:/media # cd .. > root@imx6:/ # mount /dev/da0 /media > mount: /dev/da0: Invalid argument > > > do you have an idea about that: >   why I don¢t manage to mount  my USB Key , / in FAT > > kind  regards > Jean > I'm going to guess here that da0s1 is a dos/fat filesystem?  If so, this is a freebsd quirk (that IMO is kinda crazy for 2017): if the filesystem type is not ufs, you have to tell the mount command what it is.  Try   mount -t msdosfs /dev/da0s1 /media -- Ian From owner-freebsd-arm@freebsd.org Wed Feb 15 16:25: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 6591ACE06E1 for ; Wed, 15 Feb 2017 16:25:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 313E79F5 for ; Wed, 15 Feb 2017 16:25:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id 203so67788383ith.0 for ; Wed, 15 Feb 2017 08:25:11 -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=1p2V26ixNf+f0+MgBWNnKwvhd27eAm6DGmt0phNxaJU=; b=EjgFn5LHSD6kEtUouAIf1xVR0PBa/hdrJxbYIXbxrTgRNrO3xcEC/WxfGLI6naXQ02 fB+QwYE2I0OXuFgvXJBZI27HNSpaVwr/MYqWBTdAwky3auLvkci6+NVBztSYf95FAIjj SNirYWwuJs+5+TTMtPuPE6hbFADGZB0B5Lr7sN69JPTXHICYEVXr5CCz6UJpYTD4vGm7 dj1zuUu9gVPbw1QQEduWNgduZFIaHM5TmWJwWGIqf8TjJv1/AVZX6s0/Q3GxRTyyQspC zNcktd2ApV7wooUsTdEz5F6Q8LhSH96kpnpog6l586fGVu4JLtBt1watVFNGYteBzda+ 7n/w== 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=1p2V26ixNf+f0+MgBWNnKwvhd27eAm6DGmt0phNxaJU=; b=Xr5/nBi3jPV4NglrLpY9SIE4H8CdToAcXTUu6HtTG0D8QiJgX73IU9MnL20mU3ize1 ZzhdHurWP9tjflEhezp96vjA+BMJPC98JxQtCYq0AA61E6ieRJTr2Yc/ZeZS9JaQet3z UR56ts0mZxq5SpmkwVa/DDBi0N3N4W1NPcgaMBSKt0fN1Sp0jPSkZdkhHjz8KN9zrzIa tNiQs9Pq1qwYbRYZ3x0NXC+5L1Uc4pPEdWA8Jss8ALF1bJM+mSMxzy4j3zw1AtzgNBQg kjPtcawmz2PnaBGJ8QUjXb8xehkEfhGYB8w0uvK6nVkuBpKssLM8TqqZbs51O0jm7h4h 4kMA== X-Gm-Message-State: AMke39lZg4ztKFdz5O5TxD0m8E/BEsXayqf39r7VOsBcNVAyKpgjKaIu6r/lIml3CnQh3YJLZqZc90EaFTCrYQ== X-Received: by 10.107.198.195 with SMTP id w186mr32799609iof.19.1487175910319; Wed, 15 Feb 2017 08:25:10 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Wed, 15 Feb 2017 08:25:09 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <674C2DA0-808D-4968-B86D-7CADEC3A7EEE@dsl-only.net> References: <5335118.oK1KXXDaG5@pc-alex> <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> <7424243.zp5tqGREgJ@pc-alex> <8E5F8A15-2F79-4015-B93B-975D27308782@dsl-only.net> <674C2DA0-808D-4968-B86D-7CADEC3A7EEE@dsl-only.net> From: Warner Losh Date: Wed, 15 Feb 2017 09:25:09 -0700 X-Google-Sender-Auth: 2TEGSgpMRVp4eI8WOyM9KQRfEoA Message-ID: Subject: Re: bcopy/memmove optimization broken ? [looks like you are correct to me, I give supporting detail] To: Mark Millard Cc: Alexandre Martins , freebsd-arm , Ian Lepore 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: Wed, 15 Feb 2017 16:25:11 -0000 On Mon, Feb 13, 2017 at 9:04 PM, Mark Millard wrote: > On 2017-Feb-13, at 1:27 AM, Mark Millard wrote: > >> As the decision about when to call the code that can >> deal with overlapping memory regions is wrong, the code >> that should only be used for non-overlaping regions likely >> would handle some overlapping regions and so would operate >> incorrectly in at least some cases. >> >> In other words, I think the bug is worse than just an >> example of being sub-optimal: the code is wrong from what >> I can tell. (I've no clue if the code is ever put to use >> for any bad cases.) > > I was wrong about the error status, possibly for multiple reasons, > but the following is sufficient: > > https://www.freebsd.org/cgi/man.cgi?query=memcpy&sektion=3 > > says: > > In this implementation memcpy() is implemented using bcopy(3), and there- > fore the strings may overlap. On other systems, copying overlapping > strings may produce surprises. Programs intended to be portable should > use memmove(3) when src and dst may overlap. > > so the branch taken case for: > > bcc PIC_SYM(_C_LABEL(memcpy), PLT) > > also deals with overlaps since FreeBSD criteria is > that memcpy does so. (I had been thinking that it > did not deal with such.) > > > Side note: > > Notably the arm implementation of FreeBSD memcpy does not call > bcopy (that would be recursive in the arm implementation). > memcpy just needs to have some properties that bcopy also has. > > This suggests that memcpy vs. bcopy may have a performance > Principle of Least Astonishment violation since memcpy may well > perform differently than bcopy for some types of contexts but > memcpy is supposed to use bcopy. > > > [A varient of these notes are in the comments for bugzilla > 217065.] Seems like the memcpy man page should be softened to reflect the !x86 reality. If we provide different semantics between different arches, we should consider carefully why and document in the code or change. Warner From owner-freebsd-arm@freebsd.org Wed Feb 15 16: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 2E8B9CE0937 for ; Wed, 15 Feb 2017 16:34:15 +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 D4B43E0D; Wed, 15 Feb 2017 16:34:14 +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 v1FGY4so018912; Wed, 15 Feb 2017 08:34:04 -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 v1FGY0Mx018911; Wed, 15 Feb 2017 08:34:00 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201702151634.v1FGY0Mx018911@pdx.rh.CN85.dnsmgr.net> Subject: Re: bcopy/memmove optimization broken ? [looks like you are correct to me, I give supporting detail] In-Reply-To: To: Warner Losh Date: Wed, 15 Feb 2017 08:34:00 -0800 (PST) CC: Mark Millard , freebsd-arm , Ian Lepore 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: Wed, 15 Feb 2017 16:34:15 -0000 > On Mon, Feb 13, 2017 at 9:04 PM, Mark Millard wrote: > > On 2017-Feb-13, at 1:27 AM, Mark Millard wrote: > > > >> As the decision about when to call the code that can > >> deal with overlapping memory regions is wrong, the code > >> that should only be used for non-overlaping regions likely > >> would handle some overlapping regions and so would operate > >> incorrectly in at least some cases. > >> > >> In other words, I think the bug is worse than just an > >> example of being sub-optimal: the code is wrong from what > >> I can tell. (I've no clue if the code is ever put to use > >> for any bad cases.) > > > > I was wrong about the error status, possibly for multiple reasons, > > but the following is sufficient: > > > > https://www.freebsd.org/cgi/man.cgi?query=memcpy&sektion=3 > > > > says: > > > > In this implementation memcpy() is implemented using bcopy(3), and there- > > fore the strings may overlap. On other systems, copying overlapping > > strings may produce surprises. Programs intended to be portable should > > use memmove(3) when src and dst may overlap. > > > > so the branch taken case for: > > > > bcc PIC_SYM(_C_LABEL(memcpy), PLT) > > > > also deals with overlaps since FreeBSD criteria is > > that memcpy does so. (I had been thinking that it > > did not deal with such.) > > > > > > Side note: > > > > Notably the arm implementation of FreeBSD memcpy does not call > > bcopy (that would be recursive in the arm implementation). > > memcpy just needs to have some properties that bcopy also has. > > > > This suggests that memcpy vs. bcopy may have a performance > > Principle of Least Astonishment violation since memcpy may well > > perform differently than bcopy for some types of contexts but > > memcpy is supposed to use bcopy. > > > > > > [A varient of these notes are in the comments for bugzilla > > 217065.] > > Seems like the memcpy man page should be softened to reflect the !x86 > reality. If we provide different semantics between different arches, > we should consider carefully why and document in the code or change. We should consider that we never do that, please, that is just asking for a lot of foot shooting! Especially with something as fundemental as memcpy/bcopy! -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Wed Feb 15 16:39:46 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 E63A3CE099C for ; Wed, 15 Feb 2017 16:39:46 +0000 (UTC) (envelope-from kelly.collins@infodigitalzone.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B5419EE3 for ; Wed, 15 Feb 2017 16:39:46 +0000 (UTC) (envelope-from kelly.collins@infodigitalzone.com) Received: by mailman.ysv.freebsd.org (Postfix) id B1E94CE099B; Wed, 15 Feb 2017 16:39:46 +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 AFDBACE099A for ; Wed, 15 Feb 2017 16:39:46 +0000 (UTC) (envelope-from kelly.collins@infodigitalzone.com) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-bo1ind01on0089.outbound.protection.outlook.com [104.47.101.89]) (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 13D19EE2 for ; Wed, 15 Feb 2017 16:39:44 +0000 (UTC) (envelope-from kelly.collins@infodigitalzone.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2188731.onmicrosoft.com; s=selector1-infodigitalzone-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/wTwMy/KEDkuCfaRRE/tjPDTXAlIL6scyFBxVnWkEkw=; b=NhgCCrNgisx7IQKkM89OLuCyDdj7p4/J+XFC1nfIm5XuaM0av5VLeXzQCwjC8mPcvEic+2znO50nQzbKTEmZ/0Xy14Uv5Fw4r+zwwM6GyN4K66xWr6nkV4RAtvIhVSDFTvNj0DfC6tkSecoD1PkgccTxo4oAig1xbhI8B140Xbc= Received: from BMXPR01MB0821.INDPRD01.PROD.OUTLOOK.COM (10.174.216.137) by BMXPR01MB0821.INDPRD01.PROD.OUTLOOK.COM (10.174.216.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 16:39:41 +0000 Received: from BMXPR01MB0821.INDPRD01.PROD.OUTLOOK.COM ([10.174.216.137]) by BMXPR01MB0821.INDPRD01.PROD.OUTLOOK.COM ([10.174.216.137]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 16:39:41 +0000 From: Kelly Collins To: "arm@freebsd.org" Subject: Avaya Products and Services Clients DB Thread-Topic: Avaya Products and Services Clients DB Thread-Index: AdKHqZ2C4QMUXDraT/+xOZu2qDJ/iw== Date: Wed, 15 Feb 2017 16:35:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kelly.collins@infodigitalzone.com; x-originating-ip: [106.51.28.183] x-ms-office365-filtering-correlation-id: 08107d05-d5cd-4327-d356-08d455c13d6e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702085551020)(201702085552020); SRVR:BMXPR01MB0821; x-microsoft-exchange-diagnostics: 1; BMXPR01MB0821; 7:QLani90S8CcjvJAR1tYkRl+9NczPJQaXWmuYxYvLSFX8VS89M1/X/jCekLkmXKigtN4+WfXJD/g5QrY1QLNAI+901HzIiu7ZcOJ/vsqOBS2amrJ8J9fbPFdtBYRxS8hVqqFLgcGc6AQWJIWYTvLOyRC8hDEj+XJ+GZRjpqN12Kik6sCWvwAeJazA+GQqZK7HUocO2kAphUa1830Cb8ksy9WWfJNf/lg5w80ellry5pcsQGXd8iHEs0vduPy5Zyl0sZ0ALhGCHzsw24dsGUn9bCu+99bKJJnqa4V6MCPfRl/DkDPw/G7UABXV/LrG3aAUOdlF0czzE4Vf1XAF1pZvmu/b4F7jrYXAGnIyM2rwmT1QMx/X6eYjLOEwG4ADgWI90U+bqucsP6m+jx0BG2QaSL+GtBfNLCsUKt8Tu01AZa5wBTZf8n+a3i35QjeiMb+Mue8SSXvM//MV9574TE7fiuiUNNxSUhzkZQBYQeVQLWL99bwDAG/YY2tTAoWcz44fKxUJHBdXj6pq2I7ziMhsQg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(2016111802025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(6043046); SRVR:BMXPR01MB0821; BCL:0; PCL:0; RULEID:; SRVR:BMXPR01MB0821; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39410400002)(39840400002)(199003)(189002)(3846002)(102836003)(6116002)(38730400002)(790700001)(6666003)(101416001)(2900100001)(6916009)(122556002)(6506006)(6436002)(3280700002)(92566002)(2906002)(50986999)(54356999)(389900002)(77096006)(2351001)(450100001)(7696004)(106356001)(66066001)(105586002)(9456002)(5630700001)(8676002)(8936002)(2501003)(1730700003)(74316002)(189998001)(81166006)(81156014)(5660300001)(97736004)(110136004)(3660700001)(7736002)(53936002)(9686003)(54896002)(33656002)(6306002)(68736007)(86362001)(55016002)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:BMXPR01MB0821; H:BMXPR01MB0821.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: infodigitalzone.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: infodigitalzone.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 16:35:59.8132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0ed40d93-50a2-4bae-a38e-107c80b2c3c5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BMXPR01MB0821 Content-Type: text/plain; charset="us-ascii" 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, 15 Feb 2017 16:39:47 -0000 Good Day, Would you be interested in acquiring a list of Companies or Clients using A= vaya products and services? We also have other technology: Cisco, Shoretel, Mitel, SAP, Salesforce, Ora= cle, SAS, Verizon, Sprint, Qwest, and many more.. We provide contacts from all over globe: North America, EMEA, Asia Pacific = and LATAM. Please review and let me know which industry you would need the contact lis= t and I will get back to you with counts, pricing and more information in m= y next email. Await your response. Best Regards, Kelly Collins Demand Generation- Technology Database From owner-freebsd-arm@freebsd.org Wed Feb 15 16:40:22 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 CF6CACE09EE for ; Wed, 15 Feb 2017 16:40:22 +0000 (UTC) (envelope-from jletutour@deltadore.com) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0124.outbound.protection.outlook.com [104.47.2.124]) (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 4A832F47; Wed, 15 Feb 2017 16:40:21 +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=Ui+pwu6t8kRF/1kSMU60Unvu30+wpaGE/gwBY9vjWOk=; b=IpBbzA/NEA7+Nn8QPAfWNOUApwIYbBqid0tKtXjnTPpHAYlsDcz/r9q7hpv9KYeQ/D/3DT/8pWvW7Hk1Z8ixjghZ7bRwrgWc3p2KI9Fb46fIB2HFmioCtzc2mtBsA+kI/2kCzEJv5rPMA4eoqt7yjsmpWIsxkzIjgJoTczHi5Ys= 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.919.10; Wed, 15 Feb 2017 16:40:17 +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.0919.013; Wed, 15 Feb 2017 16:40:17 +0000 From: LE TUTOUR Jean To: Hans Petter Selasky , Ian Lepore , Warner Losh CC: "freebsd-arm@freebsd.org" Subject: RE: 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: AQHSh6eAbjjG13yPpE6qKIrLRSim0qFqQmfA Date: Wed, 15 Feb 2017 16:40:17 +0000 Message-ID: References: <1486748072.10020.253.camel@freebsd.org> <9a04c038-8f2a-66e9-5c9e-e74bcc2b74b8@selasky.org> In-Reply-To: <9a04c038-8f2a-66e9-5c9e-e74bcc2b74b8@selasky.org> 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: 0a04fb4e-8156-46a9-5dc1-08d455c152ff x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB1405; x-microsoft-exchange-diagnostics: 1; VI1PR07MB1405; 7:tn8rK+04Zi+/497PeeDz7Q7mwSXlel3qRpHXO72/7iJP/BUwUmpvMad0kYfES0KbrhrEYS/sBnx6FbCYX414Fc9wgXLfBtyubC5QLhcVGUS7C4c2Bz6U2H4YCDxz1knkcrqdKKTa69VndLu65P/4Ei+BXObGhhr79p1MHKJlpIXKYYz61SELljc9FeuerLkXKCN1BuUHGwGfiX8tIvf3j3lBNXcQeKeP9U1TDh3vRVGKHovfncfO3CnQPmsR3c4urWALZZagiVT/6M9m9XUsZEyQoN2C+GB0Ek0tRDHfbmqsHFWgEnQ17hD/0KJW7nG8ukB39g2GAi669I3Ew8hK6dm89IIQBebWPt9n6vPZ8LTMM6Jh3X8lTl+b200DfobabNDTejFh4WeKaZTauM0fx62+c8B0Vbzbh0Mk73lJ/fEjZiya8KK/CtxQ4PNcJKDIDKciX5pMClJEvVDytv+mHPxGcHQIj1flv08NA/N4yCrxgNnOPNM/9x33r1+daOAt7YWZErE8ytTBphoIMWk3vA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:VI1PR07MB1405; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1405; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(55784002)(199003)(24454002)(92566002)(5890100001)(77096006)(25786008)(101416001)(6306002)(33656002)(9686003)(2906002)(86362001)(93886004)(50986999)(81156014)(6436002)(8676002)(53546003)(8936002)(575784001)(99286003)(6506006)(5660300001)(76176999)(54356999)(81166006)(4326007)(55016002)(3846002)(7736002)(305945005)(966004)(2900100001)(102836003)(122556002)(6116002)(6246003)(105586002)(53936002)(53386004)(3280700002)(74316002)(106356001)(97736004)(66066001)(38730400002)(229853002)(2950100002)(3660700001)(106116001)(68736007)(189998001)(7696004)(389900002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1405; H:VI1PR07MB1406.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:fr; 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: 15 Feb 2017 16:40:17.4768 (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: Wed, 15 Feb 2017 16:40:22 -0000 VGhhbmsgIHlvdSwNCkkgc2hvdWxkIGtub3cgIGJldHRlciBCU0QuDQpJIGFtIHNvcnJ5DQoNClJl Z2FyZHMNCg0KDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogSGFucyBQ ZXR0ZXIgU2VsYXNreSBbbWFpbHRvOmhwc0BzZWxhc2t5Lm9yZ10NCkVudm95w6kgOiBtZXJjcmVk aSAxNSBmw6l2cmllciAyMDE3IDE3OjIwDQrDgCA6IExFIFRVVE9VUiBKZWFuOyBJYW4gTGVwb3Jl OyBXYXJuZXIgTG9zaA0KQ2MgOiBmcmVlYnNkLWFybUBmcmVlYnNkLm9yZw0KT2JqZXQgOiBSZTog dXNiIHRyb3VibGUgY3Vib3ggYnNkIDExIC0gRnJlZUJTRCAxMS4wLVNUQUJMRSAjMCByMzEwMzU5 OiBXZWQgRGVjIDIxIDE4OjE5OjExIFVUQyAyMDE2DQoNCk9uIDAyLzE1LzE3IDE3OjE0LCBMRSBU VVRPVVIgSmVhbiB3cm90ZToNCj4gcm9vdEBpbXg2Oi9ob21lL2ZyZWVic2QgIyBjZCAvbWVkaWEN Cj4gcm9vdEBpbXg2Oi9tZWRpYSAjIGxzDQo+IHJvb3RAaW14NjovbWVkaWEgIyBtb3VudCAvZGV2 L2RhMHMxIC9tZWRpYQ0KPiBtb3VudDogL2Rldi9kYTBzMTogSW52YWxpZCBhcmd1bWVudA0KPiBy b290QGlteDY6L21lZGlhICMgbW91bnQgL2Rldi9kYTAgL21lZGlhDQo+IG1vdW50OiAvZGV2L2Rh MDogSW52YWxpZCBhcmd1bWVudA0KPiByb290QGlteDY6L21lZGlhICMgY2QgLi4NCj4gcm9vdEBp bXg2Oi8gIyBtb3VudCAvZGV2L2RhMCAvbWVkaWENCj4gbW91bnQ6IC9kZXYvZGEwOiBJbnZhbGlk IGFyZ3VtZW50DQo+DQo+DQo+IGRvIHlvdSBoYXZlIGFuIGlkZWEgYWJvdXQgdGhhdDoNCj4gICB3 aHkgSSBkb27igJl0IG1hbmFnZSB0byBtb3VudCAgbXkgVVNCIEtleSAsIC8gaW4gRkFUDQoNCldp dGggRnJlZUJTRCBtb3VudCB5b3UgbmVlZCB0byBzcGVjaWZ5IG1zZG9zZnM6DQoNCm1vdW50IC10 IG1zZG9zZnMgL2Rldi9kYTBzMSAvbWVkaWENCg0KLS1IUFMNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCkzigJl1c2FnZSBkZSBsYSBtZXNz YWdlcmllIHByb2Zlc3Npb25uZWxsZSBvdSBkdSB0w6lsw6lwaG9uZSBlbiBzb2lyw6llIG91IGVu IGRlaG9ycyBkZSBqb3VycyB0cmF2YWlsbMOpcyBkb2l0IMOqdHJlIGp1c3RpZmnDqSBwYXIgbGEg Z3Jhdml0w6kgZXQgbOKAmXVyZ2VuY2UgZXQvb3UgbOKAmWltcG9ydGFuY2UgZXhjZXB0aW9ubmVs bGUgZHUgc3VqZXQgdHJhaXTDqS4gSWwgZXN0IHJhcHBlbMOpIHF1ZSBudWwgbuKAmWVzdCwgcXVv aSBxdeKAmWlsIGVuIHNvaXQsIHRlbnUgZGUgcsOpcG9uZHJlIGF1eCBtYWlscyBvdSBtZXNzYWdl cywgU01TLCBhZHJlc3PDqXMgZHVyYW50IGNlcyBww6lyaW9kZXMNCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KW2h0dHA6Ly9tYWlsLmRl bHRhZG9yZS5jb20vaW1hZ2VzL2xvZ29fZGVsdGFkb3JlX2NvdWwuR0lGXQ0KaHR0cDovL3d3dy5k ZWx0YWRvcmUuZnINCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KQ2UgbWVzc2Fn ZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgam9pbnRlcyBzb250IMOpdGFibGlzIMOgIGwnIGF0dGVu dGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMgZXQgc29udCBjb25maWRlbnRpZWxz LiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBkZSBsZSBkw6l0 cnVpcmUgZXQgZCdlbiBhdmVydGlyIGltbcOpZGlhdGVtZW50IGwnZXhww6lkaXRldXIuDQoNClRo aXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSBhZGRyZXNzZWVzIGFuZCBpcyBjb25maWRlbnRpYWwuIElmIHlvdSByZWNlaXZlIHRoaXMgbWVz c2FnZSBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRo ZSBzZW5kZXIuDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= From owner-freebsd-arm@freebsd.org Wed Feb 15 16:53:17 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 2AC91CE0EAB for ; Wed, 15 Feb 2017 16:53:17 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 E4DD31CCB for ; Wed, 15 Feb 2017 16:53:16 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by mail-it0-x232.google.com with SMTP id x75so67202527itb.0 for ; Wed, 15 Feb 2017 08:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambient-md-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oGeiLcsjmZ2OcB09VyKiejH7/P/8ZRzgb/qbv3wWBnU=; b=zYxGYJd71xZrKV4JRqMPmncAPDYkOwQpOsrVM/cHg9EHBwIDFP3ZDDDQJJDHy5o6ww gQefS7O17jiPzAT0ZWnCugMgSfDG8ooPIxUn333zc1pfQz3qvAcL4BJrn0VKPp3q1d5r /xxIhX1FoP3YJECwG2z4k2UWoJgzQ5r37+HuMbJdRBX9v/YHi4oB3cKhGwFdvhYz96W/ IAwT8nUtyUNbsOQZAUmpWY93TEcbj6KdDN/o/F2sU6PSUIkhEtD4sc586I0XztVT5G6E HApRWzxodAtcXirWGT4rzda+FM4cfL2HboKOoKBX/9oFuc3Uv7qmAZl41booqORXWPDi 9KoQ== 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=oGeiLcsjmZ2OcB09VyKiejH7/P/8ZRzgb/qbv3wWBnU=; b=B7HGP2rCBC5IPEzJOZycxO9AQJbImFQ9ZyGqjp8sa/GbndwkqoHmOr7l1gGqJ5OrJG yYEmd5xd8c14PbIGYCRR8E+DtWo9/yrVWtTps1Bx4KVcfxSZ6BBANpUForMdu7j10QoD FHL5DAV/HcrzCxewFZWNzwOSS5CeLppClMUP+lZg591hWoMVosCurbCTFsEV9k42MgKQ M1fg8v0YNdVEAz1uKurJTEDVW0Bv9ItDLVfudkmwp9EEBg/ZtqTvFXDAzKhT4opw1XJF 61vOvQ7ez+9Zif5wUAYOOdYPUPJ4kmpl2kGYZEzJjFQgn0q1d9thrdK/pHXCaJJls9kL TscA== X-Gm-Message-State: AMke39mgVkCBMxTqez+MCZsHL0sA/SqClAesNF+S7/+mtcLy2ouxkukpG7SFBpMWdnYjM5I+PJpKd0ABzj4ZCA== X-Received: by 10.107.47.132 with SMTP id v4mr37731943iov.172.1487177594807; Wed, 15 Feb 2017 08:53:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.95.2 with HTTP; Wed, 15 Feb 2017 08:53:14 -0800 (PST) X-Originating-IP: [66.158.136.226] From: peter garshtja Date: Wed, 15 Feb 2017 11:53:14 -0500 Message-ID: Subject: RPI2: wifi 802.11ac usb dongle To: 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, 15 Feb 2017 16:53:17 -0000 Greetings, Can anyone recommend wifi 802.11ac usb dongle ? Im thinking to use it on my RPI2 with freebsd R.11, i checked https://www.freebsd.org/relnotes/CURRENT/hardware/support.html but i dont see any of ac usb dongles on arm arch. Thanks, Peter From owner-freebsd-arm@freebsd.org Wed Feb 15 17:34: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 D8D3BCE0B96 for ; Wed, 15 Feb 2017 17:34:19 +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 B36441778; Wed, 15 Feb 2017 17:34:19 +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=tC9hS+U8exMjaF3u6tfEQ5QTyE2XImYY7FJrHmlMIpg=; b=AMjVWhvAkqqPLo+gRPzxoyhK17Fg8Bog2x8WujG1Hmj+VetV+yazRDUNOpyLMvBcMjsBfTtYDUjB+4+Qty5/M3+jbG9kSp22P3KAG5h+p1Lfvu3JhVumJQJeTapi+sF8tkaM29kNA5kJ9rvQxkkBzO152/KPM7MeZAL1eZ3pYJcJ0adO; 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 1ce3T1-000OEo-8a; Wed, 15 Feb 2017 09:34:17 -0800 From: "Tony Hain" To: "'Ian Lepore'" , "'Oleksandr Tymoshenko'" Cc: References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> <1486841770.10020.287.camel@freebsd.org> <0fe001d285c7$032c32a0$098497e0$@tndh.net> <1487005000.10020.292.camel@freebsd.org> In-Reply-To: <1487005000.10020.292.camel@freebsd.org> Date: Wed, 15 Feb 2017 09:34:12 -0800 Message-ID: <123601d287b1$b8f1c820$2ad55860$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCzikkuUoxhpHAkDcVcrtsdCslcNQH9hJ4TAXN5MpwBwWtU/QLGedD0ArIe9bCjUaPBEA== 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: Wed, 15 Feb 2017 17:34:19 -0000 Ian Lepore wrote: > > --------------- snip ---------------------- >=20 > It looks like you've designed it so that you have to modify the stock source to > include that file above. =A0Instead, reverse that. =A0Remove the block = that has the > model=3D and all, and in its place do >=20 > =A0#include "am335x-bonegreen.dts" >=20 > and then follow that with the=A0&am33xx_pinmux {...} and #uartN {...} = blocks > you already have. >=20 > Then you just need to tell crochet to build that dts file instead of = (or in > addition to) the standard ones. =A0I don't use crochet, so I'm not = sure how to > make it do that, but someone here can probably give us the right incantation. Well crochet appears to be an obscure collection of scripts that do not provide an option for specific dts files. With the only configuration = option being at the board level, Beaglebone, it builds dtb's for both White and Black, and I can't figure out how to modify that. My approach was to = move the black.dts out of the way and park a modified green.dts in its place, with the include for the uarts. Yes I could have put the uart = definitions in the dts, but it seems more broadly applicable to keep that as a full set = to be included when needed, rather than cluttering up the base dts for = every board type. The list I sent the other day had syntax errors, as well as duplicating the uart0_pins label, so dtc kept failing, and the error = message was not descriptive enough to make debugging easy. In any case, with the steps below a crochet build completed, but I keep getting "read-only = file system - growfs: /dev/mmcsd0s2: Operation not permitted " and " cannot = open /etc/fstab: No such file or directory " after the resize so I don't know = if it runs on the BBG yet. mv am335x-boneblack.dts am335x-boneblack.dts.dist cp am335x-bonegreen.dts am335x-boneblack.dts (fav editor) --- am335x-boneblack.dts diff am335x-bonegreen.dts am335x-boneblack.dts(modified) > #include "am335x-bone-uarts.dtsi" < &am33xx_pinmux { < uart2_pins: uart2_pins { < pinctrl-single,pins =3D < < AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE1) = /* spi0_sclk.uart2_rxd */ < AM33XX_IOPAD(0x954, PIN_OUTPUT | MUX_MODE1) = /* spi0_d0.uart2_txd */ < >; < }; < }; < < &uart2 { < pinctrl-names =3D "default"; < pinctrl-0 =3D <&uart2_pins>; < status =3D "okay"; < }; < cat am335x-bone-uarts.dtsi /* am335x-bone-uarts.dtsi * * BeagleBone Green / Black - All 6 uarts defined : * this was difficult to find as the SRM doesn't include the address offset, * and example dts files found by search were incomplete, * many with incorrect offsets * eventually tripped over address offset P8/9 maps at: * http://www.siue.edu/~gengel/bbbWebStuff/BeagleboneBlackP8HeaderTable.pdf * http://www.siue.edu/~gengel/bbbWebStuff/BeagleboneBlackP9HeaderTable.pdf * coorelated with 335x pin map at * http://www.ti.com/lit/ds/symlink/am3359.pdf * zcz ball number matches above tables * * compiled by Tony Hain - 2/12/17 * * modify comment markers below to enable/disable required uarts * * add #include "am335x-bone-uarts.dtsi" to board dts */ // IOPAD Addr offset | Direction | MuxMode | Connector | Proc = pin | SignalName | Conflict &am33xx_pinmux { // uart0_pins: uart0_pins { // pinctrl-single,pins =3D < // AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0) /* J1_4 E15 uart0_rxd */ // AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* J1_5 E16 uart0_txd */ // AM33XX_IOPAD(0x978, PIN_OUTPUT | MUX_MODE5) /* P9_20 = D18 uart0_ctsn ! uart1_cts*/ // AM33XX_IOPAD(0x97c, PIN_INPUT | MUX_MODE5) /* P9_19 = D17 uart0_rtsn ! uart1_rts*/ // >; // }; uart1_pins: uart1_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x980, PIN_INPUT | MUX_MODE0) /* P9_26 = D16 uart1_rxd */ AM33XX_IOPAD(0x984, PIN_INPUT | MUX_MODE0) /* P9_24 = D15 uart1_txd */ // AM33XX_IOPAD(0x978, PIN_INPUT_PULLDOWN | MUX_MODE0) /* P9_20 = D18 uart1_ctsn ! uart0_cts*/ // AM33XX_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* P9_19 = D17 uart1_rtsn ! uart0_rts*/ // AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5) /* No_pin = G16 uart1_ri */ // AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5) /* No_pin = K18 uart1_dcd */ // AM33XX_IOPAD(0xXxx, PIN_INPUT_PULLDOWN | MUX_MODE5) /* No_pin = L18 uart1_dsr */ // AM33XX_IOPAD(0xXxx, PIN_OUTPUT_PULLDOWN | MUX_MODE5) /* No_pin = L17 uart1_dtr */ >; }; uart2_pins: uart2_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE1) /* P9_22 = A17 uart2_rxd */ AM33XX_IOPAD(0x954, PIN_OUTPUT | MUX_MODE1) /* P9_21 = B17 uart2_txd */ // AM33XX_IOPAD(0x8c0, PIN_INPUT_PULLDOWN | MUX_MODE6) /* P8_37 U1 uart2_ctsn ! uart5_txd*/ // AM33XX_IOPAD(0x8b8, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* P8_38 U2 uart2_rtsn ! uart5_rxd*/ >; }; uart3_pins: uart3_pins { pinctrl-single,pins =3D < // AM33XX_IOPAD(0xXxx, PIN_INPUT | MUX_MODE1) /* No_pin = C15 uart3_rxd ! hdmi */ AM33XX_IOPAD(0x964, PIN_OUTPUT_PULLUP | MUX_MODE1) /* P9_42 = C18 uart3_txd */ // AM33XX_IOPAD(0x8c8, PIN_INPUT_PULLUP | MUX_MODE6) /* P8_36 U3 uart3_ctsn */ // AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE6) /* P8_34 U4 uart3_rtsn */ >; }; uart4_pins: uart4_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x870, PIN_INPUT_PULLUP | MUX_MODE6) /* P9_11 = T17 uart4_rxd */ AM33XX_IOPAD(0x874, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* P9_13 = U17 uart4_txd */ // AM33XX_IOPAD(0x8d0, PIN_INPUT_PULLUP | MUX_MODE6) /* P8_35 V2 uart4_ctsn */ // AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE6) /* P8_33 V3 uart4_rtsn */ >; }; uart5_pins: uart5_pins { pinctrl-single,pins =3D < AM33XX_IOPAD(0x8c4, PIN_INPUT | MUX_MODE4) /* P8_38 U2 uart5_rxd ! uart2_rts*/ AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE4) /* P8_37 U1 uart5_txd ! uart2_cts*/ // AM33XX_IOPAD(0x8d8, PIN_INPUT_PULLUP | MUX_MODE6) /* P8_31 V4 uart5_ctsn */ // AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE6) /* P8_32 T5 uart5_rtsn */ >; }; }; &uart0 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart0_pins>; status =3D "okay"; // status =3D "disabled"; }; &uart1 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart1_pins>; status =3D "okay"; // status =3D "disabled"; }; &uart2 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart2_pins>; // status =3D "okay"; status =3D "disabled"; }; &uart3 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart3_pins>; // status =3D "okay"; status =3D "disabled"; }; &uart4 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart4_pins>; // status =3D "okay"; status =3D "disabled"; }; &uart5 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart5_pins>; // status =3D "okay"; status =3D "disabled"; }; From owner-freebsd-arm@freebsd.org Wed Feb 15 18:12:16 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 1DA23CE0779 for ; Wed, 15 Feb 2017 18:12:16 +0000 (UTC) (envelope-from murty.ind@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 CDA01EB6 for ; Wed, 15 Feb 2017 18:12:15 +0000 (UTC) (envelope-from murty.ind@gmail.com) Received: by mail-qk0-x22d.google.com with SMTP id u25so159417505qki.2 for ; Wed, 15 Feb 2017 10:12:15 -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=rY634LX88xToWD6L++4BlBS7+ZUxmilv981iXeYztPM=; b=e+ZTr0g7SFhXA8b6+LzZNvsbdeXCpmvN8UxmOAeeDUQ7SQfhuKbh1vn/9PMNnd4ZRE QkslLiyZuSfwC196CKftg3Nm78DBiHRy2KCKJswVVZUmn2FxZLOCLYHzAvqXcn0A1AAI UV3RGyne7f58/GQDiP4p3cnmuGvFmi66A0oZKSU8CRg0pxjBZ9YvM6IDnfDga3Z/DniD OQC8hClvmWPTPOwDJ2RxCI/5swjKXRShwBBKwUPAXd4Zzuy1SUlQPL4OLMNSrVGhMEDx HnuOGoBjPu4sIfqvb5qwleyBLYadQ0WT5UQm86cRFNpD6/7gER63xcSREb7vVUxceudD 86nQ== 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=rY634LX88xToWD6L++4BlBS7+ZUxmilv981iXeYztPM=; b=L8bJnqCxDLqwz91OFNoTLi1U4g6r/C96+qmSKTVwUGfOrK/azi1w5LoXibsEEaw3Kh n2rrGLQALOUQVRPozIYQQ7aldC3TV7t470SVgUPaLq0kPqZlQq0Y8sC/G24UaR7LFnYP qvyoSDyU1byrMWiZOILjpiX3Psqy5DDXKurDUCotFDxfJskDhM7VSXpWQEaj2JlTpyyJ f5nO3/BYnoWSzrc4X6K+S0cgcS50re6v0vqlrEmO91tq6AxGMglO3pBu7dy6VBDk6+Ig ncrImqdRERQay9J9DAVawfusmKvwzNvxX7690PDItqF05vKB+FXQR1q+9IbDG3REIEBh jOfg== X-Gm-Message-State: AMke39k1vEhKF1UI0e2UC9nzTURtDOrIJn7pBdT6g6AzeAp3eQd9XBAPOPCqOjA9ytX+wnPMG9E2D2KwD7Rplw== X-Received: by 10.55.5.11 with SMTP id 11mr33649453qkf.262.1487182334960; Wed, 15 Feb 2017 10:12:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.38.2 with HTTP; Wed, 15 Feb 2017 10:12:14 -0800 (PST) From: murty mvr Date: Wed, 15 Feb 2017 23:42:14 +0530 Message-ID: Subject: pkg bootstrap failing To: 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, 15 Feb 2017 18:12:16 -0000 Hi Team, am new to both FreeBSD,and RPI3. am trying to install softwares through package manger, but pkg is failing. Could you pls help me out. root@rpi3:/usr/home/raspberry # env ABI=freebsd:11:aarch64:64 pkg bootstrap The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+ http://pkg.FreeBSD.org/freebsd:11:aarch64:64/latest, please wait... Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done Installing pkg-1.9.4_1... pkg-static: wrong architecture: FreeBSD:11:aarch64 instead of freebsd:11:aarch64:64 Failed to install the following 1 package(s): /tmp//pkg.txz.1NPoad root@rpi3:/usr/home/raspberry # Thanks a ton murty. From owner-freebsd-arm@freebsd.org Wed Feb 15 20:06: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 10B13CE0871 for ; Wed, 15 Feb 2017 20:06: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 B61D414F1 for ; Wed, 15 Feb 2017 20:06:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1282 invoked from network); 15 Feb 2017 20:06:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Feb 2017 20:06:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Wed, 15 Feb 2017 15:06:11 -0500 (EST) Received: (qmail 13852 invoked from network); 15 Feb 2017 20:06:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Feb 2017 20:06:11 -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 AC2A9EC90A2; Wed, 15 Feb 2017 12:06:10 -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: Date: Wed, 15 Feb 2017 12:06:09 -0800 Cc: Alexandre Martins , freebsd-arm , Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: References: <5335118.oK1KXXDaG5@pc-alex> <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> <7424243.zp5tqGREgJ@pc-alex> <8E5F8A15-2F79-4015-B93B-975D27308782@dsl-only.net> <674C2DA0-808D-4968-B86D-7CADEC3A7EEE@dsl-only.net> To: Warner Losh 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, 15 Feb 2017 20:06:20 -0000 On 2017-Feb-15, at 8:25 AM, Warner Losh wrote: > On Mon, Feb 13, 2017 at 9:04 PM, Mark Millard = wrote: >> On 2017-Feb-13, at 1:27 AM, Mark Millard = wrote: >>=20 >>> As the decision about when to call the code that can >>> deal with overlapping memory regions is wrong, the code >>> that should only be used for non-overlaping regions likely >>> would handle some overlapping regions and so would operate >>> incorrectly in at least some cases. >>>=20 >>> In other words, I think the bug is worse than just an >>> example of being sub-optimal: the code is wrong from what >>> I can tell. (I've no clue if the code is ever put to use >>> for any bad cases.) >>=20 >> I was wrong about the error status, possibly for multiple reasons, >> but the following is sufficient: >>=20 >> https://www.freebsd.org/cgi/man.cgi?query=3Dmemcpy&sektion=3D3 >>=20 >> says: >>=20 >> In this implementation memcpy() is implemented using bcopy(3), = and there- >> fore the strings may overlap. On other systems, copying = overlapping >> strings may produce surprises. Programs intended to be portable = should >> use memmove(3) when src and dst may overlap. >>=20 >> so the branch taken case for: >>=20 >> bcc PIC_SYM(_C_LABEL(memcpy), PLT) >>=20 >> also deals with overlaps since FreeBSD criteria is >> that memcpy does so. (I had been thinking that it >> did not deal with such.) >>=20 >>=20 >> Side note: >>=20 >> Notably the arm implementation of FreeBSD memcpy does not call >> bcopy (that would be recursive in the arm implementation). >> memcpy just needs to have some properties that bcopy also has. >>=20 >> This suggests that memcpy vs. bcopy may have a performance >> Principle of Least Astonishment violation since memcpy may well >> perform differently than bcopy for some types of contexts but >> memcpy is supposed to use bcopy. >>=20 >>=20 >> [A varient of these notes are in the comments for bugzilla >> 217065.] >=20 > Seems like the memcpy man page should be softened to reflect the !x86 > reality. If we provide different semantics between different arches, > we should consider carefully why and document in the code or change. >=20 > Warner If FreeBSD's memcpy ever does not handle overlapped memory regions in the copy how much FreeBSD specific source code that is not intended to be TARGET_ARCH specific would be invalidated and need to be updated to work on all TARGET_ARCH's? I would not expect any "softended" criteria for memcpy to go this far. There is a lot of history tied to the existing definition that would have to be reviewed and likely various updates made. If the "softended" aspect were only the removal of the direct claim that bcopy is used, then I'd hope for some documented guidance about tradeoffs for choosing bcopy vs. memcpy. It would be nice if the guidance was not TARGET_ARCH specific in any usually-important way, otherwise there would be be a systematic need for conditional selection to pick the better one in source code. If an an architecture needs an unusual distinction I'd expect an architecture-specific name for an architecture-specific routine would be better: it makes clear the need for selection. If a few architectures share an unusual need then a name based on the need could be used instead. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Feb 15 22:37: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 96331CE01AD for ; Wed, 15 Feb 2017 22:37:39 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound2e.ore.mailhop.org (outbound2e.ore.mailhop.org [54.149.88.251]) (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 7A94F669 for ; Wed, 15 Feb 2017 22:37:38 +0000 (UTC) (envelope-from per@hedeland.org) X-MHO-User: 26f1a7af-f3cf-11e6-b3c2-c9f38144898e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.155.109 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.155.109]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 26f1a7af-f3cf-11e6-b3c2-c9f38144898e; Wed, 15 Feb 2017 22:36:13 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id v1FMaQms091792 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Feb 2017 23:36:27 +0100 (CET) (envelope-from per@hedeland.org) Subject: Re: pkg bootstrap failing To: murty mvr References: From: Per Hedeland Cc: freebsd-arm@freebsd.org Message-ID: Date: Wed, 15 Feb 2017 23:36:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 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: Wed, 15 Feb 2017 22:37:39 -0000 On 2017-02-15 19:12, murty mvr wrote: > Hi Team, am new to both FreeBSD,and RPI3. am trying to install softwares > through package manger, but pkg is failing. > > Could you pls help me out. > > root@rpi3:/usr/home/raspberry # env ABI=freebsd:11:aarch64:64 pkg bootstrap Per both https://wiki.freebsd.org/arm64/rpi3 and http://www.raspbsd.org/raspberrypi.html, the correct invocation is: env ABI=FreeBSD:11:aarch64 pkg bootstrap I've succesfully done that (and, with the corresponding entry in /usr/local/etc/pkg.conf, used pkg to install a few packages) on an RPi3 running the image Brad Davis announced here a week ago. Btw, I would like to send a heartfelt THANK YOU! to Brad and all the other people putting in a lot of hard work to make FreeBSD a viable OS for the RPi (and other arm systems, although I currently don't have a personal interest in those). I tried putting FreeBSD on an RPi1 a couple of years ago when I got it - I did succeed, but the effort of getting there and using it was more than I was prepared to spend, and I reluctantly had to resort to the L-OS. When I recently started to play around a bit more actively with that and an RPi3 aquired later, I got increasingly annoyed with L, and decided to have another look at the FreeBSD support - and it just works! Pre-built images - and packages, I certainly didn't expect that! The RPi1 is running 11.0-RELEASE absolutely perfectly, and the RPi3 support seems to be coming along nicely. I got both up and running with USB wifi with minimal effort, without ever connecting console and keyboard. Thanks again! --Per Hedeland From owner-freebsd-arm@freebsd.org Wed Feb 15 23:32: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 C32F2CE0F51 for ; Wed, 15 Feb 2017 23:32:18 +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 9D7901E0 for ; Wed, 15 Feb 2017 23:32:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 06a6e5b6-f3d7-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 06a6e5b6-f3d7-11e6-ba57-8bc134ee460a; Wed, 15 Feb 2017 23:32:34 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1FNWFkv002243; Wed, 15 Feb 2017 16:32:15 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1487201535.73144.15.camel@freebsd.org> Subject: Re: svn commit: r312679 - head/sys/arm/freescale/imx From: Ian Lepore To: Yoshiro MIHIRA , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, "freebsd-arm@FreeBSD.org" Date: Wed, 15 Feb 2017 16:32:15 -0700 In-Reply-To: References: <201701240209.v0O29UDD047838@repo.freebsd.org> Content-Type: multipart/mixed; boundary="=-7+SAO7B1lPddo/yKeoRL" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port 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: Wed, 15 Feb 2017 23:32:18 -0000 --=-7+SAO7B1lPddo/yKeoRL Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit > > Author: ian > > Date: Tue Jan 24 02:09:30 2017 > > New Revision: 312679 > > URL: https://svnweb.freebsd.org/changeset/base/312679 [...] On Wed, 2017-02-15 at 10:31 +0000, Yoshiro MIHIRA wrote: > Hi. > Ian > > Thank you for your strong effort to support imx6 board. > > I have SolidRun HummingBoard-i2(imx6dl-hummingboard). > > I have reboot issue(never reset after reboot) and if I use Linux, I > reproduce this issue So I reported this issue to SolidRun Forum. > http://forum.solid-run.com/linux-on-cubox-i-and-hummingboard-f8/need- > to-push-reset-button-to-reboot-linux-system-t3122.html > But I could not get any information. > > I tested latest kernel(r313280) unfortunately it was not solved. > > Do you know other information about reset issue, please let me know. > > Currently I need to push reset button when I restart system... > > Yours > Yoshiro MIHIRA > [adding arm@ list] Are you set up to build and test a custom kernel?  If so, try applying the patch I'm attaching to this mail and let me know if it helps.  This turns on a bit in the control register that is described in the manual as "use a new more robust method to generate a software reset" (if it's better, I wonder why they didn't make it the hardware default?). -- Ian --=-7+SAO7B1lPddo/yKeoRL Content-Disposition: inline; filename="temp.diff" Content-Type: text/x-patch; name="temp.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: imx_machdep.c =================================================================== --- imx_machdep.c (revision 313569) +++ imx_machdep.c (working copy) @@ -78,6 +78,7 @@ imx_wdog_cpu_reset(vm_offset_t wdcr_physaddr) if ((pcr = devmap_ptov(wdcr_physaddr, sizeof(*pcr))) == NULL) { printf("cpu_reset() can't find its control register... locking up now."); } else { + *pcr |= 1 << 6; *pcr &= ~WDOG_CR_SRS; *pcr &= ~WDOG_CR_SRS; *pcr &= ~WDOG_CR_SRS; --=-7+SAO7B1lPddo/yKeoRL-- From owner-freebsd-arm@freebsd.org Thu Feb 16 09:48: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 1505ECE127E for ; Thu, 16 Feb 2017 09:48:20 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7F11169 for ; Thu, 16 Feb 2017 09:48:19 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1487238496; l=9727; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=H5Az4iIF4RGpJVUG6r5TXUal2N4v1ieLJ962BY+aCPw=; b=pUNdENdYZ6EQbgT9966G1hW3qlfrowycIXm8dWZ0ZjtRhZ3WqAdCLaPsucB+iT8qH0 rTPULoGR7rPJUwMoeI8q0bvyOVYTGKlNCcUtQN2yNTjsNHCnrrH+c4pFdJ+oxGUkyGlQ dVERa01NsYf7KsehARbHHcnJhmL0xV24XILZU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 39.12 DYNA|AUTH) with ESMTPSA id 30b190t1G9mFfTq (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 16 Feb 2017 10:48:15 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id C04867506DA1 for ; Thu, 16 Feb 2017 07:48:12 -0200 (BRST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: BeagleBone Black MMC ordering clashes From: "Dr. Rolf Jansen" In-Reply-To: Date: Thu, 16 Feb 2017 07:48:11 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A97EEB3-6B24-48E7-959F-67F4275AFEC8@obsigna.com> References: <7D750433-59FC-4999-AC24-041683E17310@obsigna.com> <1483718084.96230.5.camel@freebsd.org> <0D800E14-799A-4926-AEF8-CD698D647E40@obsigna.com> <1483722560.96230.10.camel@freebsd.org> <1483928120.96230.61.camel@freebsd.org> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) 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, 16 Feb 2017 09:48:20 -0000 Am 09.01.2017 um 00:32 schrieb Dr. Rolf Jansen : >> Am 09.01.2017 um 00:15 schrieb Ian Lepore : >> On Fri, 2017-01-06 at 16:40 -0200, Dr. Rolf Jansen wrote: >>>> Am 06.01.2017 um 15:09 schrieb Ian Lepore : >>>> On Fri, 2017-01-06 at 14:33 -0200, Dr. Rolf Jansen wrote: >>>>>> Am 06.01.2017 um 13:54 schrieb Ian Lepore : >>>>>> On Fri, 2017-01-06 at 12:37 -0200, Dr. Rolf Jansen wrote: >>>>>>>=20 >>>>>>> The BeagleBone Black comes with 2 MMC facilities, one built- >>>>>>> in >>>>>>> (internal 4 GB) and one provided by a removable SD card. For >>>>>>> unknown >>>>>>> reasons the BBB defined on the removable SD card to be MMC0 >>>>>>> and >>>>>>> the >>>>>>> internal flash memory is MMC0. >>>>>>>=20 >>>>>>> 1) In the first go, I dd'd the FreeBSD-12 BBB snapshot >>>>>>> (20161221) >>>>>>> onto a SD card and I was able to start the device from that >>>>>>> card. >>>>>>> gpart showed me that the device identifier of the SD card is >>>>>>> mmcsd0 >>>>>>> and that of the internal flash memory is mmcsd1. OK, that >>>>>>> matches >>>>>>> the >>>>>>> already mentioned definitions. >>>>>>>=20 >>>>>>> 2) Now, I destroyed the partition of the internal mmcsd1 >>>>>>> and >>>>>>> created a new one: >>>>>>>=20 >>>>>>> =3D> 63 7552961 mmcsd1 MBR (3.6G) >>>>>>> 63 8129 - free - (4.0M) >>>>>>> 8192 8192 1 fat32 [active] (4.0M) >>>>>>> 16384 7536640 2 freebsd (3.6G) >>>>>>>=20 >>>>>>> =3D> 0 7536640 mmcsd1s2 BSD (3.6G) >>>>>>> 0 7536640 1 freebsd-ufs (3.6G) >>>>>>>=20 >>>>>>> 3) I copied over the contents of /boot/msdos from the >>>>>>> external >>>>>>> SD >>>>>>> card to the msdosfs on mmcsd1s1 and I installed the FreeBSD >>>>>>> 12 >>>>>>> snapshot on mmcsd1s1a. Restarting the device from the >>>>>>> internal >>>>>>> flash >>>>>>> and no external SD inserted with FreeBSD 12-CURRENT works >>>>>>> well at >>>>>>> the >>>>>>> first glance. >>>>>>>=20 >>>>>>> 4) However, the internal flash got now the device >>>>>>> identifier >>>>>>> mmcsd0: >>>>>>>=20 >>>>>>> ... >>>>>>> mmc0: No compatible cards found on bus >>>>>>> ... >>>>>>> mmcsd0: 4GB >>>>>> 112 >>>>>>> 0x0000> at mmc1 48.0MHz/8bit/65535-block >>>>>>> ... >>>>>>>=20 >>>>>>> I know, this is how FreeBSD deals with the device numbering, >>>>>>> i.e. >>>>>>> serial numbers starting at zero without particular meaning, >>>>>>> and I >>>>>>> know that we should not rely on the number ordering. >>>>>>>=20 >>>>>>> But it seems that the MMC device driver does cont on the >>>>>>> external >>>>>>> SD >>>>>>> card is at MMC0 when I insert it into the BBB once it has >>>>>>> been >>>>>>> started from the internal flash. It seems to insist to assign >>>>>>> the >>>>>>> device ID mmcsd0, which results in the device ordering clash >>>>>>> because >>>>>>> mmcsd0 has been assigned to the internal flash at MMC1 (s. >>>>>>> above). >>>>>>>=20 >>>>>>> In the moment, I can have both flash device active at the >>>>>>> same >>>>>>> time >>>>>>> only when I start the BBB from the external SD. >>>>>>>=20 >>>>>>> I would be glad to hear suggestions on how to deal with the >>>>>>> issue. At >>>>>>> the end of the day, I want to start the device from the >>>>>>> mostly >>>>>>> static >>>>>>> OS file system on the internal flash and keep the volatile >>>>>>> data >>>>>>> on >>>>>>> the external SD. >>>>>>>=20 >>>>>>> Best regards >>>>>>>=20 >>>>>>> Rolf >>>>>> The mmcsd0 identifier will be assigned to the first mmc device >>>>>> found >>>>>> that has a valid mmc or sd card. If the external slot has a >>>>>> card >>>>>> in >>>>>> it, it will become mmcsd0 because it gets probed first. If it >>>>>> has >>>>>> no >>>>>> card in it, the onboard eMMC becomes mmcsd0 because the sd slot >>>>>> didn't >>>>>> claim that device id. There is no way to change the order of >>>>>> probing; >>>>>> probing happens in order of the devices in the chip. The BBB >>>>>> makers >>>>>> decided to connect the external sd to the first device and the >>>>>> onboard >>>>>> eMMC to the second one. >>>>> Thank you for rephrasing of what I wanted to say in my initial >>>>> post: >>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I know, this is how FreeBSD deals with the device numbering, >>>>>>> i.e. >>>>>>> serial numbers starting at zero without particular meaning, >>>>>>> and I >>>>>>> know that we should not rely on the number ordering. >>>>> So, yes, this part is absolutely clear and understood. >>>>>>=20 >>>>>> If you want the eMMC to be the root filesystem whether there is >>>>>> an >>>>>> external sd card installed or not, the only solution is to use >>>>>> UFS >>>>>> or >>>>>> GPT labels instead of device names to refer to partitions in >>>>>> fstab. >>>>> I do not rely on device identifiers in fstab on non of my >>>>> numerous >>>>> FreeBSD boxes, instead, I use the various sorts of labels ever >>>>> since, >>>>> and I continue to do it also with the BBB installation(s). >>>>>=20 >>>>> # df -h >>>>> Filesystem Size Used Avail Capacity Mounted on >>>>> /dev/ufs/SYSTEM 13G 875M 11G 7% / >>>>> devfs 1.0K 1.0K 0B 100% /dev >>>>> /dev/label/BOOT 4.0M 924K 3.1M 23% /boot/msdos >>>>> tmpfs 50M 4.0K 50M 0% /tmp >>>>>=20 >>>>> However, this does not help in the given case, because the MMC >>>>> device >>>>> driver refuses to enumerate the SD card when inserted into a BBB >>>>> that >>>>> has been already started-up from the internal flash. So the >>>>> question >>>>> is, how can I get the SD card activated once inserted into a >>>>> running >>>>> system, and I would happily live with any device identifier for >>>>> it, >>>>> even let it mmcsd77 if only the device would be accessible by >>>>> this. >>>>>=20 >>>>> Best regards >>>>>=20 >>>>> Rolf >>>> Oh, you mean you boot from eMMC without an sd card, then later when >>>> you >>>> insert an sd card it's not detected? I've never tried that (I've >>>> never >>>> used the onboard eMMC at all), but it wouldn't surprise me that >>>> it's >>>> broken. >>> Yes, that is the problem. >>>=20 >>>>=20 >>>> It would imply we're not handling the card-detect properly, >>>> probably because it's a gpio pin, and we didn't have good gpio >>>> support >>>> back when I was working on the TI sdcard driver. >>> Well, this might be related to an issues with the U-Boot/MLO >>> facility. Remember that I replaced the factory one on the eMMC by = the >>> one from the FreeBSD 12.0-CURRENT(Beaglebone) image. Actually this >>> allows me to boot FreeBSD from the internal eMMC without an SD card, >>> however with a remarkable notice at the very beginning of the boot >>> sequence: >>>=20 >>> U-Boot SPL 2016.05 (Dec 21 2016 - 18:05:07) >>> Trying to boot from MMC2 >>> Card did not respond to voltage select! >>> *** Warning - MMC init failed, using default environment >>>=20 >>> The "Card did not respond" notice and the consecutive warning does >>> not appear when I boot from the SD card, instead I see another one >>> about a not supported property by the SD card:=20 >>>=20 >>> U-Boot SPL 2016.05 (Dec 21 2016 - 18:05:07) >>> Trying to boot from MMC1 >>> Card doesn't support part_switch >>> MMC partition switch failed >>> *** Warning - MMC partition switch failed, using default >>> environment >>>=20 >>> Perhaps U-Boot disables/deactivates/turns-off something on the board >>> already in the very early stage. Perhaps I need to adapt the U-Boot >>> image for internal eMMC booting. >>>=20 >>>>=20 >>>> Yep, I just looked at the source, and there's no handling for gpio- >>>> based sd card detect in the TI driver. Maybe I can find some time >>>> this >>>> weekend to add it, now that we have a better gpio infrastructure >>>> for >>>> drivers to use. >>> Many thanks in advance for spending your time. >>>=20 >>> Best regards >>>=20 >>> Rolf >>=20 >> Okay, I got this all done and tested this weekend, and just committed >> all the changes for am335x (beaglebone) and imx6 (wandboard, cubox, >> etc). It's pretty easy to convert an existing driver, so I expect >> other boards with sdhci-compatible hardware to get updated soon too. >>=20 >> If you are set up to build custom kernels, you just need to update = your >> sources to r311736 or later and rebuild. Otherwise you can wait = until >> the next 12-current snapshot is available (I think those still come = out >> weekly). >=20 > Ian, >=20 > thank you very much for all you efforts. >=20 > My x86-machines are running custom kernels and personally I am set = building it, however, I am in the course of porting my own software to = the BeagleBone, and I learned already that compiling huge code bases on = it is not fun at all. >=20 > At some point in time in the near future, I need to setup ARM cross = building on one of my faster x86 machines. For the time being, I will = wait for the next snapshot, and of course I will report my findings. I tried the FreeBSD 12 snapshot for the BeagleBone from 2017-02-10, and = it does not work at all. The new u-boot is complaining that it cannot find a configured device = and drops into the console, and I needed to revert to the previous = u-boot, i.e. the one that was on the snapshot from 2017-01-05. With that the new kernel loaded, however, when trying to mount root, = kernel's vfs complained that the indicated device /dev/mmcsd0s2a is = read-only, and booting was not finished. I gave up with = FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170210-r313561, and I will = try again with the next snapshot. Best regards Rolf= From owner-freebsd-arm@freebsd.org Thu Feb 16 14:52:02 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 51E7CCE1E42 for ; Thu, 16 Feb 2017 14:52:02 +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 3F4AC10F2 for ; Thu, 16 Feb 2017 14:52:02 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id ED12F31633; Thu, 16 Feb 2017 07:51:54 -0700 (MST) Date: Thu, 16 Feb 2017 07:51:54 -0700 From: Brad Davis To: Per Hedeland Cc: murty mvr , freebsd-arm@freebsd.org Subject: Re: pkg bootstrap failing Message-ID: <20170216145154.GN70816@corpmail.liquidneon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 16 Feb 2017 14:52:02 -0000 On Wed, Feb 15, 2017 at 11:36:26PM +0100, Per Hedeland wrote: > On 2017-02-15 19:12, murty mvr wrote: > > Hi Team, am new to both FreeBSD,and RPI3. am trying to install softwares > > through package manger, but pkg is failing. > > > > Could you pls help me out. > > > > root@rpi3:/usr/home/raspberry # env ABI=freebsd:11:aarch64:64 pkg bootstrap > > Per both https://wiki.freebsd.org/arm64/rpi3 and > http://www.raspbsd.org/raspberrypi.html, the correct invocation is: > > env ABI=FreeBSD:11:aarch64 pkg bootstrap > > I've succesfully done that (and, with the corresponding entry in > /usr/local/etc/pkg.conf, used pkg to install a few packages) on an RPi3 > running the image Brad Davis announced here a week ago. > > Btw, I would like to send a heartfelt THANK YOU! to Brad and all the > other people putting in a lot of hard work to make FreeBSD a viable OS > for the RPi (and other arm systems, although I currently don't have a > personal interest in those). I tried putting FreeBSD on an RPi1 a couple > of years ago when I got it - I did succeed, but the effort of getting > there and using it was more than I was prepared to spend, and I > reluctantly had to resort to the L-OS. > > When I recently started to play around a bit more actively with that and > an RPi3 aquired later, I got increasingly annoyed with L, and decided to > have another look at the FreeBSD support - and it just works! Pre-built > images - and packages, I certainly didn't expect that! The RPi1 is > running 11.0-RELEASE absolutely perfectly, and the RPi3 support seems to > be coming along nicely. I got both up and running with USB wifi with > minimal effort, without ever connecting console and keyboard. Thank you very much for your kind words and we are glad to hear it is working for you! Regards, Brad Davis From owner-freebsd-arm@freebsd.org Thu Feb 16 16:28: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 26E88CDC141 for ; Thu, 16 Feb 2017 16:28:43 +0000 (UTC) (envelope-from digit9@digit9.co.in) Received: from digit9.co.in (unknown [IPv6:2a01:4f8:201:82ac::2]) (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 EB62E168D for ; Thu, 16 Feb 2017 16:28:42 +0000 (UTC) (envelope-from digit9@digit9.co.in) Received: by digit9.co.in (Postfix, from userid 10000) id 8E7F7118B43B; Thu, 16 Feb 2017 21:58:27 +0530 (IST) To: freebsd-arm@freebsd.org Subject: [iTunes-Connect]=?UTF-8?Q?=E2=9C=89_?=Someone has been logged into your account from another country X-PHP-Originating-Script: 10000:12.php From: AppleID Message-Id: <20170216162827.8E7F7118B43B@digit9.co.in> Date: Thu, 16 Feb 2017 21:58:27 +0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: Thu, 16 Feb 2017 16:28:43 -0000 From owner-freebsd-arm@freebsd.org Thu Feb 16 17:05: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 1E8EACE1486 for ; Thu, 16 Feb 2017 17:05:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE80B1E94 for ; Thu, 16 Feb 2017 17:05:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v1GH1Bf0040894 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 09:01:12 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v1GH1Af4040893; Thu, 16 Feb 2017 09:01:10 -0800 (PST) (envelope-from fbsd) Date: Thu, 16 Feb 2017 09:01:10 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: fatal error: 'invtrig.h' file not found on RPI2 Message-ID: <20170216170110.GA40795@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-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, 16 Feb 2017 17:05:20 -0000 For the last day I've been seeing --- lib/msun__L --- /usr/src/lib/msun/src/catrigl.c:48:10: fatal error: 'invtrig.h' file not found #include "invtrig.h" This is on FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r313709: Mon Feb 13 15:11:04 PST 2017 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm Am I doing something wrong? Attempts to update simply report root@www:/usr/src # svnlite up . Updating '.': At revision 313810. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Feb 16 17:42: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 E6236CE2081 for ; Thu, 16 Feb 2017 17:42:14 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::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 BA9C412F2 for ; Thu, 16 Feb 2017 17:42:14 +0000 (UTC) (envelope-from fuz@fuz.su) Received: by fuz.su (Postfix, from userid 1000) id 79DD120156; Thu, 16 Feb 2017 18:42:13 +0100 (CET) Date: Thu, 16 Feb 2017 18:42:13 +0100 From: fuz@fuz.su To: freebsd-arm@freebsd.org Subject: lib32 support for ARM64 Message-ID: <20170216174213.GA26791@fuz.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 16 Feb 2017 17:42:15 -0000 Hello! I have recently started to use FreeBSD on my Raspberry Pi 3, when I noticed that there is no lib32 support, i.e. you cannot run 32 bit ARM binaries. As I am currently a student with a lot of time to kill during the summer, I am thinking about implementing this. I would like to know: * what needs to be ported/adapted to get lib32 support working? * has there been any existing work in this direction? * is there interest in implementing this feature? * if yes, would this feature be suitable for a gsoc project? I have no experience in working on the FreeBSD kernel except for a one-line patch I wrote to get an LPT port card running. I have (for a student) very good knowledge of programming in C. I know how to read and write assembly code. I have a reasonable idea of how the FreeBSD kernel is structured. Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From owner-freebsd-arm@freebsd.org Thu Feb 16 21:09:30 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 63F7DCE20A3 for ; Thu, 16 Feb 2017 21:09:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 2D9751AF4 for ; Thu, 16 Feb 2017 21:09:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id x75so40239477itb.0 for ; Thu, 16 Feb 2017 13:09:30 -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=j3LhGMQc1XsPRU8BYNQOOdspkFTmbJ0h6o0Z+rNYpgA=; b=E+ihDDtgMRt12SLB9b3vs8rHkBJ08PeASZREcb0zncpx0ee0fPL4wJWK7/s3F16ZWZ 8rc/f/KcB0T1SH2PHxgVqs1MS3In+uEJnbH79zLsnVdK7coovw15nECMavyc5LN8sqvC hopFoJxoL1xn9ob39UDZ/QdTaltmi8RNBVDoDbSg5Wz5r1xzCsK06l8F8Gwl4B2Js8p/ CBPxj5uTERVTo6bmwW4O18OA2sgTutAQX4qYU2JmjtKXyEi6nFkWkRv7hACfry7hDdGS QbKtNfQ9gI1NJX2fDf4aJQVlog+66pdGHwXENe/H1+vDLG9+fKZeg9R3fdM9foKBHH6t LlBQ== 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=j3LhGMQc1XsPRU8BYNQOOdspkFTmbJ0h6o0Z+rNYpgA=; b=eyG2vFw+2YRvVVPeGO1oIqcgadl1qPw3iOcrI48KTtLp30vlP+dh/08ZJYorQCaY6f X5/T/zRmwO7/Aydt4USUFjGqH+7zqIxkkazmDDmh4T2axwByax7bfAry1zR/SvLgt5m1 CbXWi7xBkdKNrUhJtyvRMYoWgK8HsmdmbuWWeBmKvcgdC8sqG1ljf3mSE276o7r+lVNG ero8m7PsXVDnWvQLNwwn0LDXM76ApWJl/MM8pw3IhZzFvshXVAgX4bRWisew5/4WBVWa yyDGsv6X3QvnoayQkohAul7vsxtsVymwdildjnXnno62wf6D9Iq54OJCSZuRVbpBKqiT 8yaA== X-Gm-Message-State: AMke39kEOe5wp0S3YjG4QZv6tjCe/XWq2H2veo+YfCWZ+uTFg4+W8QUapg6NuKS8N2rP7NkHtM5pxz1sdPsUDQ== X-Received: by 10.107.11.216 with SMTP id 85mr2974526iol.0.1487279369274; Thu, 16 Feb 2017 13:09:29 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Thu, 16 Feb 2017 13:09:28 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <20170216174213.GA26791@fuz.su> References: <20170216174213.GA26791@fuz.su> From: Warner Losh Date: Thu, 16 Feb 2017 14:09:28 -0700 X-Google-Sender-Auth: 541KtIsLr2pqGkDmjTy-iu38zCw Message-ID: Subject: Re: lib32 support for ARM64 To: fuz@fuz.su 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: Thu, 16 Feb 2017 21:09:30 -0000 On Thu, Feb 16, 2017 at 10:42 AM, wrote: > Hello! > > I have recently started to use FreeBSD on my Raspberry Pi 3, when I > noticed that there is no lib32 support, i.e. you cannot run 32 bit ARM > binaries. As I am currently a student with a lot of time to kill during > the summer, I am thinking about implementing this. I would like to know: > > * what needs to be ported/adapted to get lib32 support working? > * has there been any existing work in this direction? > * is there interest in implementing this feature? > * if yes, would this feature be suitable for a gsoc project? > > I have no experience in working on the FreeBSD kernel except for a > one-line patch I wrote to get an LPT port card running. I have (for a > student) very good knowledge of programming in C. I know how to read and > write assembly code. I have a reasonable idea of how the FreeBSD kernel > is structured. There's two issues here: (1) building lib32 stuff. It isn't hard, but lots of grunt work given the differences between the tool chains for armv6 and arm64. (2) Running the 32-bit binaries (which we don't support). Past experience suggests it's on the order of a few days to a couple of weeks worth of work. But arm wasn't setup for 32/64 bit sharing so it is likely going to be on the longer end of that, if not a bit longer. Especially for a more junior person, so it would be a little small on the GSoC scale, but no worse than some other GSoCs that have been completed successfully. Warner From owner-freebsd-arm@freebsd.org Thu Feb 16 21:10: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 17C97CE20F2 for ; Thu, 16 Feb 2017 21:10:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 D2C2F1B6F for ; Thu, 16 Feb 2017 21:10:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5DBFE1FE025; Thu, 16 Feb 2017 22:10:06 +0100 (CET) Subject: Re: fatal error: 'invtrig.h' file not found on RPI2 To: bob prohaska , freebsd-arm@freebsd.org References: <20170216170110.GA40795@www.zefox.net> From: Hans Petter Selasky Message-ID: <5d95b6b7-8cab-cdb2-76d8-502359f2df91@selasky.org> Date: Thu, 16 Feb 2017 22:09:40 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170216170110.GA40795@www.zefox.net> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Thu, 16 Feb 2017 21:10:25 -0000 On 02/16/17 18:01, bob prohaska wrote: > For the last day I've been seeing > > --- lib/msun__L --- > /usr/src/lib/msun/src/catrigl.c:48:10: fatal error: 'invtrig.h' file not found > #include "invtrig.h" > Hi, There is a fix in progress for this issue. --HPS From owner-freebsd-arm@freebsd.org Thu Feb 16 21:34: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 CE7E7CE2975 for ; Thu, 16 Feb 2017 21:34:31 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (smtp.fgznet.ch [IPv6:2001:4060:1:1001::14:52]) (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 97BD81C98 for ; Thu, 16 Feb 2017 21:34:31 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPSA id BBCA3C6CCE; Thu, 16 Feb 2017 22:34:27 +0100 (CET) Subject: Re: fatal error: 'invtrig.h' file not found on RPI2 To: bob prohaska , freebsd-arm@freebsd.org References: <20170216170110.GA40795@www.zefox.net> From: Andreas Tobler Message-ID: <418eca38-683c-4c13-f24b-f05aa49196d7@fgznet.ch> Date: Thu, 16 Feb 2017 22:34:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170216170110.GA40795@www.zefox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: Obelix Submit on 127.0.1.1 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, 16 Feb 2017 21:34:31 -0000 On 16.02.17 18:01, bob prohaska wrote: > For the last day I've been seeing > > --- lib/msun__L --- > /usr/src/lib/msun/src/catrigl.c:48:10: fatal error: 'invtrig.h' file not found > #include "invtrig.h" > > This is on > > FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r313709: Mon Feb 13 15:11:04 PST 2017 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm > > Am I doing something wrong? Attempts to update simply report > root@www:/usr/src # svnlite up . > Updating '.': > At revision 313810. Just revert r313761 in head/lib/msun, it affects also mips and powerpc. Andreas From owner-freebsd-arm@freebsd.org Fri Feb 17 01:55: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 DD066CE1D32 for ; Fri, 17 Feb 2017 01:55:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ACFDC181D for ; Fri, 17 Feb 2017 01:55:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v1H1tGmh042214 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 17:55:17 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v1H1tFei042213; Thu, 16 Feb 2017 17:55:15 -0800 (PST) (envelope-from fbsd) Date: Thu, 16 Feb 2017 17:55:15 -0800 From: bob prohaska To: Andreas Tobler Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: fatal error: 'invtrig.h' file not found on RPI2 Message-ID: <20170217015515.GA42188@www.zefox.net> References: <20170216170110.GA40795@www.zefox.net> <418eca38-683c-4c13-f24b-f05aa49196d7@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <418eca38-683c-4c13-f24b-f05aa49196d7@fgznet.ch> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 17 Feb 2017 01:55:40 -0000 On Thu, Feb 16, 2017 at 10:34:27PM +0100, Andreas Tobler wrote: > On 16.02.17 18:01, bob prohaska wrote: > > For the last day I've been seeing > > > > --- lib/msun__L --- > > /usr/src/lib/msun/src/catrigl.c:48:10: fatal error: 'invtrig.h' file not found > > #include "invtrig.h" > > > > This is on > > > > FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r313709: Mon Feb 13 15:11:04 PST 2017 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm > > > > Am I doing something wrong? Attempts to update simply report > > root@www:/usr/src # svnlite up . > > Updating '.': > > At revision 313810. > > Just revert r313761 in head/lib/msun, it affects also mips and powerpc. > Hmm, didn't seem to help, same error. Actually, it doesn't matter, this is just a test machine. How can I tell when it's useful to try again? Thanks! bob From owner-freebsd-arm@freebsd.org Fri Feb 17 08:00: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 B7FF1CE280A for ; Fri, 17 Feb 2017 08:00:33 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A1FC1E7F for ; Fri, 17 Feb 2017 08:00:33 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id 189so12099157pfu.3 for ; Fri, 17 Feb 2017 00:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=JaiSy85CGMM4ypwZBAVa0JKPRhbQ3qtl4XI1vycvXeQ=; b=NM2j+t0crmtRAPmXcH1Ax2CXBF33UHPEOe+lTqqWf+kZ3zFa2SxrDWD7d7GAa5+jqt 7V41wf4jw+pTo5BAL1DsXCx2Ri8AwXUA8B11ly+ChV81DDWGWIL0hujpOlGpnMynJfbY YeFRFYXCWDnhG/qwh1nzpqnibTGepU5/Xgq82sK34Af0UY2ek5Sd5J8SJzDKMkuaDJvE zAbnkFac/LcN78u800FZQAqOjqL1qGWKBCqqmPUnWpdmTcHqU310693Riqgo4aoOKY/Q dQJ2r3Pg+rQZBqOXKRiJ/4RdMrpkAn7CbOmx2I7y/VCm5K6Dv8R3TV1LGo2X+eGnMAC0 6ksw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=JaiSy85CGMM4ypwZBAVa0JKPRhbQ3qtl4XI1vycvXeQ=; b=czDWFp698rQb3OeYavUrkZ+XZth5aT5SP92hWNnFCNkwCtwqYG6ftlwOUrU5vWqWo5 LTV4OWM7oejptpE6t9lNYZ4RXVPNoB8b+cirwd1dB09oTHTSpOTEjeTu1Obw0oYivpGI yHjzMgiuOrCmIwvdh1vUWlbOM+HuVWFiZzD+GZON8eYaB9Th4NAD8faNQRFC42jk14qU q3YMjA0/mMRqhm2ok0pvqAkvI1Hlpdz2BATGorlonS6ykZCZx2Ik593RzpOtz2shJwKk 0ptXDaGllYWGLq9/sWlK397mtQjEAAYCRWpkIpzXZL71BA0T32zV+ZYxvqxTzs9jK5Jv m4oQ== X-Gm-Message-State: AMke39kSwMTacbXctQhrPkoD6WNDi5MHeNzBSy5nLhyXXqXje0KTMn1KBlmbEIwW6ToPYQ== X-Received: by 10.84.194.165 with SMTP id h34mr9265010pld.70.1487318433012; Fri, 17 Feb 2017 00:00:33 -0800 (PST) Received: from [192.168.88.254] (ip70-173-249-54.lv.lv.cox.net. [70.173.249.54]) by smtp.gmail.com with ESMTPSA id n81sm17644835pfb.111.2017.02.17.00.00.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 00:00:32 -0800 (PST) To: freebsd-arm@freebsd.org From: jungle boogie Subject: raspbsd rpi3 password? Message-ID: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> Date: Fri, 17 Feb 2017 00:00:30 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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: Fri, 17 Feb 2017 08:00:33 -0000 Hi All, Anyone know what the password is for the raspberry pi 3 image from http://www.raspbsd.org/raspberrypi.html I can't seem to login with freebsd/freebsd. Is ssh disabled by default? Would it be too much to ask to have it listed on the website? Also, anyone know the GPIO pins for serial connection? I thought it was 3,4,5 for black,white,green. Perhaps this can be listed on the website as well for each image available. Thanks! From owner-freebsd-arm@freebsd.org Fri Feb 17 08:14:51 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 DD70ACE2C96 for ; Fri, 17 Feb 2017 08:14:51 +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 8BBCF161B for ; Fri, 17 Feb 2017 08:14:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23078 invoked from network); 17 Feb 2017 08:14:44 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Feb 2017 08:14:44 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Fri, 17 Feb 2017 03:14:44 -0500 (EST) Received: (qmail 24471 invoked from network); 17 Feb 2017 08:14:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Feb 2017 08:14:43 -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 316EDEC7B43; Fri, 17 Feb 2017 00:14:43 -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: arm64 libc.so.7.full link: Are the 8 "R_AARCH64_ABS64 used with TLS symbol . . ." notices a problem? Message-Id: Date: Fri, 17 Feb 2017 00:14:42 -0800 To: freebsd-arm , FreeBSD Toolchain 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: Fri, 17 Feb 2017 08:14:52 -0000 [This happens to be a amd64 -> arm64 cross build context.] Context: # uname -paKU FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT r313783M amd64 = amd64 1200020 1200020 In exploring how to investigate tsd_booted assert failures I noticed the following in: /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full.meta # Meta data file = /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full.meta CMD @echo building shared library libc.so.7 CMD @rm -f libc.so.7 libc.so CMD cc -B/usr/local/aarch64-freebsd/bin/ -mcpu=3Dcortex-a53 -target = aarch64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/pine64_clang/arm64.aarch64/usr/src/tmp = -B/usr/local/aarch64-freebsd/bin/ -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'/usr/local/aarch64-freebsd/bin/nm' NMFLAGS=3D'' lorder = bt_close.pico . . . (long list of .pico files) . . . wmemset.pico | tsort -q` -lcompiler_rt -lssp_nonshared CWD /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc TARGET libc.so.7.full -- command output -- building shared library libc.so.7 /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): = R_AARCH64_ABS64 used with TLS symbol udb /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): = R_AARCH64_ABS64 used with TLS symbol uf /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): = R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_initialized /usr/local/aarch64-freebsd/bin/ld: = cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with = TLS symbol dtors /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): = R_AARCH64_ABS64 used with TLS symbol __thread_locale /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale Are these R_AARCH64_ABS64 notices expected? Are they a problem? I also notice that the "filemon acquired metadata" does not list an entry to match up with: /usr/src/lib/libc/stdlib/jemalloc/Symbol.map So it would appear that changes to the Symbol.map file would not of themselves cause things to rebuild or relink. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Feb 17 08:24: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 E39C8CE0316 for ; Fri, 17 Feb 2017 08:24:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 AAE441DB4 for ; Fri, 17 Feb 2017 08:24:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B2D4B1FE025; Fri, 17 Feb 2017 09:24:19 +0100 (CET) Subject: Re: fatal error: 'invtrig.h' file not found on RPI2 To: bob prohaska , Andreas Tobler References: <20170216170110.GA40795@www.zefox.net> <418eca38-683c-4c13-f24b-f05aa49196d7@fgznet.ch> <20170217015515.GA42188@www.zefox.net> Cc: freebsd-arm@freebsd.org From: Hans Petter Selasky Message-ID: <31cfa5ab-7bfc-1309-20bf-76279560dd95@selasky.org> Date: Fri, 17 Feb 2017 09:23:54 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170217015515.GA42188@www.zefox.net> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Fri, 17 Feb 2017 08:24:40 -0000 On 02/17/17 02:55, bob prohaska wrote: > On Thu, Feb 16, 2017 at 10:34:27PM +0100, Andreas Tobler wrote: >> On 16.02.17 18:01, bob prohaska wrote: >>> For the last day I've been seeing >>> >>> --- lib/msun__L --- >>> /usr/src/lib/msun/src/catrigl.c:48:10: fatal error: 'invtrig.h' file not found >>> #include "invtrig.h" >>> >>> This is on >>> >>> FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r313709: Mon Feb 13 15:11:04 PST 2017 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm >>> >>> Am I doing something wrong? Attempts to update simply report >>> root@www:/usr/src # svnlite up . >>> Updating '.': >>> At revision 313810. >> >> Just revert r313761 in head/lib/msun, it affects also mips and powerpc. >> > > Hmm, didn't seem to help, same error. Actually, it doesn't matter, this is > just a test machine. > > How can I tell when it's useful to try again? > After this patch: https://svnweb.freebsd.org/changeset/base/313863 --HPS From owner-freebsd-arm@freebsd.org Fri Feb 17 08:34: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 1A207CE0940 for ; Fri, 17 Feb 2017 08:34:58 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mailbox.org", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC8851613 for ; Fri, 17 Feb 2017 08:34:57 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 6F15244F95 for ; Fri, 17 Feb 2017 09:34:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:references:in-reply-to :subject:subject:from:from:message-id:date:date:received; s= mail20150812; t=1487320488; bh=rIQp2tgF59c0TtOU76XPx10xizsjCBoaX CZm7DU2SDs=; b=kVKvUOJ2EBGabojIL8k8WoZD0nsxLRY6ZYy4jd+p4GHE8FOHZ 6mrlwwrKAjFsfO9LhRxaAbXa7/GgUKRl95NRpPGp7s9S6rvKzIlm9SE8MR+IXKmZ hLNAhKIJaHJ38ES+TbEhqLFspyKOyoacxg10SycFM7nXEbkYfGCJ2MGbkP6ILJXc LaSotEaaZRYAAmF68+WhT35BFQOKgd6wQ98QvxtItNLTBfRSDpPlq9nc8BwIrl0v 4POjSEmFgf4TXZMQivfHt1oz6MVZaVq9DNblZSvg+gAElApu9jnUVSK7D4jnHh4+ 9XBp/m8PMse6HiTOL3xxHXRSYO6gc7FeBBlHQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id F5ktt3KgQk7w for ; Fri, 17 Feb 2017 09:34:48 +0100 (CET) Date: Fri, 17 Feb 2017 09:34:45 +0100 Message-ID: <861sux8bbu.wl-herbert@mailbox.org> From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: raspbsd rpi3 password? In-Reply-To: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> References: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") 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: Fri, 17 Feb 2017 08:34:58 -0000 jungle boogie skrev: > > Hi All, > Anyone know what the password is for the raspberry pi 3 image from > http://www.raspbsd.org/raspberrypi.html Seriously? http://www.raspbsd.org/#image-info 2nd question: What is the login credentials for the images? > I can't seem to login with freebsd/freebsd. Is ssh disabled by default? > Would it be too much to ask to have it listed on the website? See About: RaspBSD is a volunteer project headed by FreeBSD Committer Brad Davis (brd@). -- Herbert From owner-freebsd-arm@freebsd.org Fri Feb 17 14:07: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 BC739CE3511; Fri, 17 Feb 2017 14:07:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FBC7120F; Fri, 17 Feb 2017 14:07:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id A0B7C27F; Fri, 17 Feb 2017 08:07:32 -0600 (CST) Date: Fri, 17 Feb 2017 08:07:31 -0600 From: Mark Linimon To: Mark Millard Cc: freebsd-arm , FreeBSD Toolchain Subject: Re: arm64 libc.so.7.full link: Are the 8 "R_AARCH64_ABS64 used with TLS symbol . . ." notices a problem? Message-ID: <20170217140731.GA7285@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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, 17 Feb 2017 14:07:34 -0000 On Fri, Feb 17, 2017 at 12:14:42AM -0800, Mark Millard wrote: > Are these R_AARCH64_ABS64 notices expected? Are they a problem? Is the following post relevant? https://lists.freebsd.org/pipermail/svn-ports-all/2017-February/144857.html mcl From owner-freebsd-arm@freebsd.org Fri Feb 17 15:30:44 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 E3255CE35DA for ; Fri, 17 Feb 2017 15:30:44 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 B372A177F for ; Fri, 17 Feb 2017 15:30:44 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-pg0-x235.google.com with SMTP id z67so16456828pgb.1 for ; Fri, 17 Feb 2017 07:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=lSlUvDC84KDLjvJNWVjxyV0DV7aieQPdRityemamiNM=; b=fqyo88HEHQ4Z2oC93z2ms22Ie1fjfukvb809qQBf4HPb4CYNIfhs28lUiY5o9dVzt8 eFTl4ytDURflEkgItrPQtzuib3KOXmPu689j0uSAKzAy+zNbzoz5cUaYghYQZXwBRAt3 nn55gV6R5V5mPLO68Kweru+giJGHPw1/7xDj/Sw6wDqAv63tGnNeNPpP9p5CILC5rFK5 pT3ZvlItMAfxEpVh98pdNZpuVCWr2Tn1ut4XQ3J0FaHMBJ8k6eZIh+zaO31y7jNWjdeQ nbf6e7wWRIcSgSNpXjR1wllSyW2/oftWrjk7NhXWiP0evNZKH7m/7rojJOgRS3WQgmaT G5SQ== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lSlUvDC84KDLjvJNWVjxyV0DV7aieQPdRityemamiNM=; b=XPpN3Li1Vl4Cp2joIP0IDLaBVna2ozEKBVUDUhCuc5axkpgsgHWV4wCiDN3nQRvHdM nOkQTThqvene3rZ6ykz07/jfGpm9DAoDvlS567psZcLAauH8ziiZQBAslH1AsSYXapLy f801bGiCKj0HHCrmb5/Fj0VA3DuSnkwTfZ9gfFAQiwJ9B/TG7OnPI0v9336FTDzRbf1X XJKYtl1ZqlO0SWR1ogH77UuYHgZva18oPGRhgTXjdeAs2w5BqteXfaDOkJCoLye0wLkZ Ymb68mQLsX86tRS8stFJQVjXWtdA3933njl1dF+9RajVQB0Tzl6cXzFByydrnbsDZhnC 9nRQ== X-Gm-Message-State: AMke39nDyB1Y2UcDw7iw6xHxWFN4mB6oNZR2GqQHdC3mcIbRNDy9G7t9qE+3HT2BYUhPaQ== X-Received: by 10.99.108.74 with SMTP id h71mr10677273pgc.99.1487345444129; Fri, 17 Feb 2017 07:30:44 -0800 (PST) Received: from [192.168.88.254] (ip70-173-249-54.lv.lv.cox.net. [70.173.249.54]) by smtp.gmail.com with ESMTPSA id z77sm20378738pfk.47.2017.02.17.07.30.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 07:30:43 -0800 (PST) Subject: Re: raspbsd rpi3 password? To: freebsd-arm@freebsd.org References: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> <861sux8bbu.wl-herbert@mailbox.org> From: jungle boogie Message-ID: Date: Fri, 17 Feb 2017 07:30:42 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <861sux8bbu.wl-herbert@mailbox.org> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Fri, 17 Feb 2017 15:30:45 -0000 On 02/17/2017 12:34 AM, Herbert J. Skuhra wrote: > jungle boogie skrev: >> >> Hi All, >> Anyone know what the password is for the raspberry pi 3 image from >> http://www.raspbsd.org/raspberrypi.html > > Seriously? > > http://www.raspbsd.org/#image-info AH! Thanks for pointing that out. I was looking under the specific image info. From owner-freebsd-arm@freebsd.org Fri Feb 17 15:33: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 873DACE37BD for ; Fri, 17 Feb 2017 15:33:48 +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 729261B35 for ; Fri, 17 Feb 2017 15:33:48 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 5E6133135D; Fri, 17 Feb 2017 08:33:41 -0700 (MST) Date: Fri, 17 Feb 2017 08:33:41 -0700 From: Brad Davis To: jungle boogie Cc: freebsd-arm@freebsd.org Subject: Re: raspbsd rpi3 password? Message-ID: <20170217153341.GR70816@corpmail.liquidneon.com> References: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> 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: Fri, 17 Feb 2017 15:33:48 -0000 On Fri, Feb 17, 2017 at 12:00:30AM -0800, jungle boogie wrote: > Hi All, > > Anyone know what the password is for the raspberry pi 3 image from > http://www.raspbsd.org/raspberrypi.html > > I can't seem to login with freebsd/freebsd. Is ssh disabled by default? > > Would it be too much to ask to have it listed on the website? > > Also, anyone know the GPIO pins for serial connection? I thought it was > 3,4,5 for black,white,green. Perhaps this can be listed on the website > as well for each image available. I haven't added that because sometimes they are reversed.. Trip flipping your RX/TX pins. Thanks to gonzo@ for helping me figure that out one day.. Regards, Brad Davis From owner-freebsd-arm@freebsd.org Fri Feb 17 17:01: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 31B86CE39FF for ; Fri, 17 Feb 2017 17:01:04 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05E1F1D7A; Fri, 17 Feb 2017 17:01:04 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-it0-x233.google.com with SMTP id x75so21456327itb.0; Fri, 17 Feb 2017 09:01:04 -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=0n+LyH/m02xTVMsXaiXsVtEK8Eqh7zBY7Z5rz9xnv8c=; b=EMiGL8lDVDrxeB4kE+QU+9b65DIMYvjguzkVVhLgxHz+zjeIv/1dZpWSF8qCyTErCw G24wLb6FwWWiqb42HqIUpFCHG/9ltWTp+KZZHEIZkKiSiOqm5qGHYnKoJjK+mxvKLO7G 5wLH3KvY+5sg9npm4bxqUctzi/8XP33zb499IAtB/kdUwbJX5x1AjTry+rM2t/N2ycb3 /AB93oprl+Xyoie7rIQpiNphkCf+At61G2GWAn+iM5U0fjlzV3lFq/HpHmTryodBmQaI ysR5P32eyVFz26QKjeRBqmjSfjBFs4NCjyrpRYVB2jZMo6pFfMZUKvxKOrwdG+hCfk3l okgg== 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=0n+LyH/m02xTVMsXaiXsVtEK8Eqh7zBY7Z5rz9xnv8c=; b=StPCfYCD4g6VRWZMzyJRhQLcY4qYtqPv+iZfFsh8zzmMEfbKkQRcF2LwmyEDiSBlY2 6Oe2XSr+5ped7pc3W5QKvbtX3P5n9dhSTrxnKMBrhIWjd6qDr3n9G758HbtUo8JCWikO 3QfwC9RKZNXrxjzMpE4OxJFmTZjSF0X8hJ7AGhgXB2PT4fJ+Qa/7DU0wvw+S8NZ92X2W mhWgT6w8ajezkzbWdyRFxy3b3GT+un6bkezXy5/tqKZllQ/pFb6ryGf5DwkGz9HcmcbL 7kGafk9/46dPb/b6RAX1JgC8h309T7r8nUwJYF/GBEH0SMzu3EBpDEgeTa9yxsTYEpiL CN/w== X-Gm-Message-State: AMke39lYGYJhn/mTKFFtOHMpTj6q1cIcqofwcxPplhypuWxpXynfy2YVqjHSI/D+tXV5sNNbaMUW6za3kH/KFA== X-Received: by 10.107.186.134 with SMTP id k128mr7554173iof.71.1487350863298; Fri, 17 Feb 2017 09:01:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.142.199 with HTTP; Fri, 17 Feb 2017 09:01:02 -0800 (PST) In-Reply-To: <20170217153341.GR70816@corpmail.liquidneon.com> References: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> <20170217153341.GR70816@corpmail.liquidneon.com> From: jungle Boogie Date: Fri, 17 Feb 2017 09:01:02 -0800 Message-ID: Subject: Re: raspbsd rpi3 password? To: Brad Davis 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: Fri, 17 Feb 2017 17:01:04 -0000 Hi Brad, On 17 February 2017 at 07:33, Brad Davis wrote: > On Fri, Feb 17, 2017 at 12:00:30AM -0800, jungle boogie wrote: >> Hi All, >> >> Anyone know what the password is for the raspberry pi 3 image from >> http://www.raspbsd.org/raspberrypi.html >> >> I can't seem to login with freebsd/freebsd. Is ssh disabled by default? >> >> Would it be too much to ask to have it listed on the website? >> >> Also, anyone know the GPIO pins for serial connection? I thought it was >> 3,4,5 for black,white,green. Perhaps this can be listed on the website >> as well for each image available. > > I haven't added that because sometimes they are reversed.. Trip flipping > your RX/TX pins. Thanks to gonzo@ for helping me figure that out one > day.. > > So raspberry pi 2 and 3 have different serial connections? I could not find this information out on ANY website I searched last night. > Regards, > Brad Davis > -- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info From owner-freebsd-arm@freebsd.org Fri Feb 17 17:08: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 7EF2ECE3A94 for ; Fri, 17 Feb 2017 17:08:49 +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 687371122 for ; Fri, 17 Feb 2017 17:08:48 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 88C35314EE; Fri, 17 Feb 2017 10:08:47 -0700 (MST) Date: Fri, 17 Feb 2017 10:08:47 -0700 From: Brad Davis To: jungle Boogie Cc: "freebsd-arm@freebsd.org" Subject: Re: raspbsd rpi3 password? Message-ID: <20170217170847.GS70816@corpmail.liquidneon.com> References: <3fe603a1-7335-b09a-33fd-ba8c14fcec26@gmail.com> <20170217153341.GR70816@corpmail.liquidneon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Fri, 17 Feb 2017 17:08:49 -0000 On Fri, Feb 17, 2017 at 09:01:02AM -0800, jungle Boogie wrote: > Hi Brad, > On 17 February 2017 at 07:33, Brad Davis wrote: > > On Fri, Feb 17, 2017 at 12:00:30AM -0800, jungle boogie wrote: > >> Hi All, > >> > >> Anyone know what the password is for the raspberry pi 3 image from > >> http://www.raspbsd.org/raspberrypi.html > >> > >> I can't seem to login with freebsd/freebsd. Is ssh disabled by default? > >> > >> Would it be too much to ask to have it listed on the website? > >> > >> Also, anyone know the GPIO pins for serial connection? I thought it was > >> 3,4,5 for black,white,green. Perhaps this can be listed on the website > >> as well for each image available. > > > > I haven't added that because sometimes they are reversed.. Trip flipping > > your RX/TX pins. Thanks to gonzo@ for helping me figure that out one > > day.. > > > > > > So raspberry pi 2 and 3 have different serial connections? I could not > find this information out on ANY website I searched last night. No, they have the same pinout. Check this website for a good visual: https://pinout.xyz/pinout/uart and of course Adafruits guide: https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/overview?view=all#connect-the-lead Regards, Brad Davis From owner-freebsd-arm@freebsd.org Fri Feb 17 21:03: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 966DACE3E97 for ; Fri, 17 Feb 2017 21:03:33 +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 6F7971650 for ; Fri, 17 Feb 2017 21:03:33 +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=K26AD06fJ/BjY5ihwhSkPruLpdlpNdnMw/TEcW+D4KU=; b=AYyDPb2h8DI0jfEKL0hDbiOcPSn0ATF7USe5A4OpQl3Eg04lsN/5Jc19dzaGGWh/4F8DwHvahO7wPsf9nVRHQQZuRwoKY8pzlx212u9C26hCu2VwxbVahiPr1UBhXe88O2b94R+PLa7cD2dhtZ8Nye577r8vm9SxmwIHZwom0mvA5lgI; 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 1cepgc-00006n-5d for freebsd-arm@freebsd.org; Fri, 17 Feb 2017 13:03:32 -0800 From: "Tony Hain" To: Date: Fri, 17 Feb 2017 13:03:27 -0800 Message-ID: <149b01d28961$49418770$dbc49650$@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: AdKJYUidZDB1UV3wT3GfspA7GRWwFQ== 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: r313878M builds mmcsd0s2 as read-only & /etc/fstab is missing 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: Fri, 17 Feb 2017 21:03:33 -0000 FreeBSD 12.0-CURRENT #0 r313878M: Fri Feb 17 11:26:27 PST 2017 U-Boot SPL 2017.01-rc3 (Jan 31 2017 - 08:26:19) Trying to boot from MMC1MMC partition switch failed *** Warning - MMC partition switch failed, using default environment reading u-boot.img reading u-boot.img U-Boot 2017.01-rc3 (Jan 31 2017 - 08:26:19 +0000) CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - bad CRC, using default environment not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt 0 bytes read in 3 ms (0 Bytes/s) Loaded env from uEnv.txt Importing environment from mmc0 ... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 231544 bytes read in 20 ms (11 MiB/s) ## Starting application at 0x82000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x9df30c58 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Fri Feb 17 11:26:35 PST 2017 tony@) DRAM: 512MB Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x6097e8+0x1a2818 syms=[0x4+0x89ba0+0x4+0x9e2fb] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/am335x-bonegreen.dtb size=0x8219 Loaded DTB from file 'am335x-bonegreen.dtb'. Kernel entry at 0x82200100... Kernel args: (null) ARM Debug Architecture not supported 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 r313878M: Fri Feb 17 11:26:27 PST 2017 ... Trying to mount root from ufs:mmcsd0s2 []... warning: no time-of-day clock registered, system time will not be set accurately 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. gpart: Read-only file system growfs: /dev/mmcsd0s2: Operation not permitted /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating a new one Setting hostuuid: 696c1f73-f547-11e6-91d8-884aeaf5a20e. Setting hostid: 0xfd5e4d57. eval: cannot open /etc/fstab: No such file or directory No suitable dump device was found. eval: cannot open /etc/fstab: No such file or directory fstab: /etc/fstab:0: No such file or directory Warning! No /etc/fstab: skipping disk checks. fstab: /etc/fstab:0: No such file or directory mount: mmcsd0s2: Operation not permitted Mounting root filesystem rw failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Feb 17 19:29:34 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: # random: unblocking device. # mount mmcsd0s2 on / (ufs, local, read-only, nfsv4acls) devfs on /dev (devfs, local) # # df Filesystem 512-blocks Used Avail Capacity Mounted on mmcsd0s2 1826232 1726488 -46352 103% / devfs 2 2 0 100% /dev # gpart list mmcsd0 Geom name: mmcsd0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 62333951 first: 63 entries: 4 scheme: MBR Providers: 1. Name: mmcsd0s1 Mediasize: 33546240 (32M) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 32256 Mode: r0w0e0 attrib: active rawtype: 12 length: 33546240 offset: 32256 type: !12 index: 1 end: 65582 start: 63 2. Name: mmcsd0s2 Mediasize: 31880380416 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 524288 Mode: r2w1e1 rawtype: 165 length: 31880380416 offset: 34078720 type: freebsd index: 2 end: 62332927 start: 66560 Consumers: 1. Name: mmcsd0 Mediasize: 31914983424 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 0 Mode: r2w1e2 #