From owner-freebsd-arm@freebsd.org Sun Nov 19 07:16:36 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9DCBDEDF5B for ; Sun, 19 Nov 2017 07:16:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-164.reflexion.net [208.70.210.164]) (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 751276E6BD for ; Sun, 19 Nov 2017 07:16:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27814 invoked from network); 19 Nov 2017 07:16:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Nov 2017 07:16:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 19 Nov 2017 02:16:28 -0500 (EST) Received: (qmail 18943 invoked from network); 19 Nov 2017 07:16:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Nov 2017 07:16:28 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 17E5CEC7925; Sat, 18 Nov 2017 23:16:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh sessions close spontaneously on rpi2 From: Mark Millard In-Reply-To: <1A09ACF9-1A85-480D-90BD-9886FC54D116@dsl-only.net> Date: Sat, 18 Nov 2017 23:16:27 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: <20171118165638.GA47956@www.zefox.net> <1A09ACF9-1A85-480D-90BD-9886FC54D116@dsl-only.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 07:16:36 -0000 [The problem that I reported does not happen on a rpi2b V1.1.] On 2017-Nov-18, at 12:45 PM, Mark Millard wrote: > On 2017-Nov-18, at 8:56 AM, bob prohaska wrote: > >> It appears that something(s) are profoundly amiss on r325916 when running >> on rpi2. >> >> With make -j4 clean running in /usr/ports, new ssh connections fail >> promptly after login. For example >> >> ===========begin copy/paste=========== >> bob@raspberrypi:~ $ ssh com >> Password for bob@www.zefox.com: >> Last login: Sat Nov 18 08:38:45 2017 from 192.168.1.20 >> FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017 >> To change an environment variable in /bin/sh use: >> >> $ VARIABLE="value" >> $ export VARIABLE >> bob@www:~ % Connection to com closed. >> bob@raspberrypi:~ $ >> bob@raspberrypi:~ $ ssh com >> Password for bob@www.zefox.com: >> Last login: Sat Nov 18 08:41:33 2017 from 192.168.1.20 >> FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017 >> You can use aliases to decrease the amount of typing you need to do to get >> commands you commonly use. Examples of fairly popular aliases include (in >> Bourne shell style, as in /bin/sh, bash, ksh, and zsh): >> >> alias lf="ls -FA" >> alias ll="ls -lA" >> alias su="su -m" >> >> In csh or tcsh, these would be >> >> alias lf ls -FA >> alias ll ls -lA >> alias su su -m >> >> To remove an alias, you can usually use 'unalias aliasname'. To list all >> aliases, you can usually type just 'alias'. >> bob@www:~ % Connection to com closed. >> =============end copy/paste============ >> >> Stopping the make clean session restores normal behavior. Long-established >> ssh connections seem to keep functioning normally, three have stayed up >> overnight, though two restarts of the make clean session. >> >> At the same time, the reports of attempted umounts of /dev seem to have >> stopped, although the make clean sessions still stop, with only a cryptic >> "2 errors" on the controlling ssh session. There's nothing on the console >> or in the message log. >> >> Altogether this is rather disturbing and I'd be grateful for any insights. > > [Be warned that the BPI-M3 context here is experimental > currently: official build support has been disabled > for now, pending the switch to Linux based DTB content. > (There is a committer waiting for that *.dt* source > to be in FreeBSD.) I've temporarily patched a few > things to keep my BPI-M3 builds going during the "not > supported" time.] > > It may not be rpi2 specific but an example of a more > general armv7(/6?) issue: > > Using -r325700 (on both the BPI-M3 and amd64) and a debug > kernel (but with DIAGNOSTICs disabled) I've discovered > that when I nfs mount the BPI-M3 from the amd64 and try a > recursive diff: > > # mount -o noatime,hard,intr :/ /mnt > # diff -r /usr/src/sys/ /mnt/src/sys/ > > the Ethernet connection on the BPI-M3 stops working: > existing connections time out and ping in and out both > fail. (The serial console still works fine.) > > Via the serial console I can sometimes restart the > networking via: > > # ifconfig awg0 down > # ifconfig awg0 up > > but if the "diff -r" is still going when I do that the > BPI-M3 networking will quickly fail again. > > No console messages, no core files. > > So far this type of test sequence always fails in > a fairly short time. > > [DIAGNOSTICS was disabled because with it enabled > the USB did not find USB devices and I normally > use a USB SSD for the root file system.] I finally got an rpi2 "modernized" to -r325700 (with the new sysutils/rpi-firmware and updated sysutils/u-boot-rpi2 materials). ( -r325700 matches the BPI-M3 and other contexts that I currently have access to.) # mount -o noatime,hard,intr :/ /mnt # diff -r /usr/src/sys/ /mnt/src/sys/ is working just fine so far. So more likely this problem is ALLWINNER, A83T, or BPI-M3 specific. Sorry for the noise. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Nov 19 08:15: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 A316FDEF2A5 for ; Sun, 19 Nov 2017 08:15:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-158.reflexion.net [208.70.210.158]) (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 6A0E56FCF0 for ; Sun, 19 Nov 2017 08:15:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28471 invoked from network); 19 Nov 2017 08:15:48 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Nov 2017 08:15:48 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 19 Nov 2017 03:15:48 -0500 (EST) Received: (qmail 21982 invoked from network); 19 Nov 2017 08:15:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Nov 2017 08:15:48 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9265AEC88F5; Sun, 19 Nov 2017 00:15:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh sessions close spontaneously on rpi2 [Also: I got a rpi2 'Translation Fault (L1)' crash that I also report here, -r325700 based context] From: Mark Millard In-Reply-To: Date: Sun, 19 Nov 2017 00:15:47 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171118165638.GA47956@www.zefox.net> <1A09ACF9-1A85-480D-90BD-9886FC54D116@dsl-only.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 08:15:55 -0000 Do you get any messages like: smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy . . . smsc0: warning: Failed to write register 0x114 . . . smsc0: warning: Failed to read register 0x118 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy . . . smsc0: warning: Failed to read register 0x114 smsc0: warning: MII read timeout I am seeing these while a svnlite update is going against the mmcsd0 and a portmaster build of pkg is going against a USB SSD. (The active root file system is on the USB SSD.) [Later. . .] The ssh session that was running the svnlite update eventually got: packet_write_wait: Connection to 192.168.1.112 port 22: Broken pipe [Process completed] Another ssh session (idle sitting at a prompt) was still working after that. The portmaster build of pkg was via the serial console instead of via ethernet and ssh. For reference: smsc0 on uhub1 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 smscphy0: PHY 1 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto . . . smsc0: chip 0xec00, rev. 0002 [Even later:] Eventually the rpi2 crashed with: slot0: Controller timeout sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x36003200 | Version: 0x00009902 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x0000003f sdhci_bcm0-slot0: Argument: 0x01163b00 | Trn mode: 0x0000193a sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000307 sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 sdhci_bcm0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff0089 sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps: 0x00000000 | Caps2: 0x00000000 sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xe4cd1cf8 FSR=3D00000005, FAR=3D00000024, spsr=3D60000013 r0 =3Dc3885c00, r1 =3Dc3880780, r2 =3D00000000, r3 =3D00000000 r4 =3Dc3a5c600, r5 =3Dc388e648, r6 =3D00000001, r7 =3Dc3a5c630 r8 =3Dc0869490, r9 =3Dc086a828, r10=3Dc388e600, r11=3De4cd1db0 r12=3D00000029, ssp=3De4cd1d88, slr=3Dc027895c, pc =3Dc062eaf4 [ thread pid 11 tid 100035 ] Stopped at bcm_sdhci_dma_intr+0xb8: ldr r2, [r2, #0x024] db> bt Tracing pid 11 tid 100035 td 0xc39a6740 db_trace_self() at db_trace_self pc =3D 0xc05c6d24 lr =3D 0xc005eab4 (db_stack_trace+0x108) sp =3D 0xe4cd1a08 fp =3D 0xe4cd1a20 db_stack_trace() at db_stack_trace+0x108 pc =3D 0xc005eab4 lr =3D 0xc005e714 (db_command+0x268) sp =3D 0xe4cd1a28 fp =3D 0xe4cd1ac8 r4 =3D 0x00000001 r5 =3D 0x00000000 r6 =3D 0xc0734fef r10 =3D 0x00000000 db_command() at db_command+0x268 pc =3D 0xc005e714 lr =3D 0xc005e49c (db_command_loop+0x74) sp =3D 0xe4cd1ad0 fp =3D 0xe4cd1ae0 r4 =3D 0xc06e9458 r5 =3D 0xc071184e r6 =3D 0xc099cfa4 r7 =3D 0xe4cd1cf8 r8 =3D 0xc07fcb38 r9 =3D 0xc086a860 r10 =3D 0xc098bcd0 db_command_loop() at db_command_loop+0x74 pc =3D 0xc005e49c lr =3D 0xc0061f24 (db_trap+0x12c) sp =3D 0xe4cd1ae8 fp =3D 0xe4cd1c00 r4 =3D 0x00000000 r5 =3D 0xc099cfb0 r6 =3D 0xc098bcf0 r10 =3D 0xc098bcd0 db_trap() at db_trap+0x12c pc =3D 0xc0061f24 lr =3D 0xc02e27a8 (kdb_trap+0x16c) sp =3D 0xe4cd1c08 fp =3D 0xe4cd1c30 r4 =3D 0x00000000 r5 =3D 0x00000005 r6 =3D 0xc098bcf0 r7 =3D 0xe4cd1cf8 kdb_trap() at kdb_trap+0x16c pc =3D 0xc02e27a8 lr =3D 0xc05ea50c (abort_fatal+0x20c) sp =3D 0xe4cd1c38 fp =3D 0xe4cd1c58 r4 =3D 0xe4cd1cf8 r5 =3D 0x00000013 r6 =3D 0x00000024 r7 =3D 0x00000005 r8 =3D 0x00000005 r9 =3D 0xc39a6740 r10 =3D 0xe4cd1cf8 abort_fatal() at abort_fatal+0x20c pc =3D 0xc05ea50c lr =3D 0xc05ea170 (abort_handler+0x318) sp =3D 0xe4cd1c60 fp =3D 0xe4cd1cf0 r4 =3D 0x00000005 r5 =3D 0x00000005 r6 =3D 0x00000000 r7 =3D 0x00000005 r8 =3D 0x00000013 r10 =3D 0xe4cd1cf8 abort_handler() at abort_handler+0x318 pc =3D 0xc05ea170 lr =3D 0xc05c9720 (exception_exit) sp =3D 0xe4cd1cf8 fp =3D 0xe4cd1db0 r4 =3D 0xc3a5c600 r5 =3D 0xc388e648 r6 =3D 0x00000001 r7 =3D 0xc3a5c630 r8 =3D 0xc0869490 r9 =3D 0xc086a828 r10 =3D 0xc388e600 exception_exit() at exception_exit pc =3D 0xc05c9720 lr =3D 0xc027895c (__mtx_lock_sleep+0x1ec) sp =3D 0xe4cd1d88 fp =3D 0xe4cd1db0 r0 =3D 0xc3885c00 r1 =3D 0xc3880780 r2 =3D 0x00000000 r3 =3D 0x00000000 r4 =3D 0xc3a5c600 r5 =3D 0xc388e648 r6 =3D 0x00000001 r7 =3D 0xc3a5c630 r8 =3D 0xc0869490 r9 =3D 0xc086a828 r10 =3D 0xc388e600 r12 =3D 0x00000029 bcm_sdhci_dma_intr() at bcm_sdhci_dma_intr+0xb8 pc =3D 0xc062eaf4 lr =3D 0xc02594c4 = (intr_event_execute_handlers+0x118) sp =3D 0xe4cd1db8 fp =3D 0xe4cd1dd8 r4 =3D 0xc38faee0 r5 =3D 0xc388e648 r6 =3D 0x00000000 r7 =3D 0xc389b840 r8 =3D 0xc0869490 r9 =3D 0xc086a828 r10 =3D 0xc388e600 intr_event_execute_handlers() at intr_event_execute_handlers+0x118 pc =3D 0xc02594c4 lr =3D 0xc0259c20 (ithread_loop+0x15c) sp =3D 0xe4cd1de0 fp =3D 0xe4cd1e18 r4 =3D 0xc38faee0 r5 =3D 0xc388e670 r6 =3D 0xc388e600 r7 =3D 0xc388e610 r8 =3D 0xc38faeec r9 =3D 0xc0828ba0 r10 =3D 0x00000000 ithread_loop() at ithread_loop+0x15c pc =3D 0xc0259c20 lr =3D 0xc0255e20 (fork_exit+0xc0) sp =3D 0xe4cd1e20 fp =3D 0xe4cd1e40 r4 =3D 0xc39a6740 r5 =3D 0xc38b3730 r6 =3D 0xc0259ac4 r7 =3D 0xc38faee0 r8 =3D 0xe4cd1e48 r9 =3D 0x00000000 r10 =3D 0x00000000 fork_exit() at fork_exit+0xc0 pc =3D 0xc0255e20 lr =3D 0xc05c96b0 (swi_exit) sp =3D 0xe4cd1e48 fp =3D 0x00000000 r4 =3D 0xc0259ac4 r5 =3D 0xc38faee0 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 r10 =3D 0x00000000 swi_exit() at swi_exit pc =3D 0xc05c96b0 lr =3D 0xc05c96b0 (swi_exit) sp =3D 0xe4cd1e48 fp =3D 0x00000000 db>=20 I notice during boot I get: Booting [/boot/kernel/kernel]... =20 /boot/dtb/bcm2836-rpi-2-b.dtb size=3D0x346b Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. That last seems to indicate that the DTB is from FreeBSD instead of from the rpi-firmware or u-boot-rpi2 in my context. For reference: U-Boot 2017.09 (Nov 18 2017 - 07:51:46 +0000) DRAM: 960 MiB RPI 2 Model B (0xa21041) MMC: sdhci@7e300000: 0 . . . Compatible U-Boot API signature found @0x3bb5d988 FreeBSD/armv7 U-Boot loader, Revision 1.2 DRAM: 960MB Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0p1: /boot/kernel/kernel data=3D0x87035c+0x183ca4 = syms=3D[0x4+0x93890+0x4+0xd7368] /boot/kernel/geom_label.ko text=3D0x47b8 data=3D0x868+0x4 = syms=3D[0x4+0xd90+0x4+0xfb6] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Nov 19 16:19: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 30418DB8E9F for ; Sun, 19 Nov 2017 16:19:09 +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 F413B7DE99 for ; Sun, 19 Nov 2017 16:19:08 +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 vAJGJHPA051622 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Nov 2017 08:19:18 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAJGJHsd051619; Sun, 19 Nov 2017 08:19:17 -0800 (PST) (envelope-from fbsd) Date: Sun, 19 Nov 2017 08:19:17 -0800 From: bob prohaska To: Mark Millard Cc: Freebsd-arm , bob prohaska Subject: Re: ssh sessions close spontaneously on rpi2 [Also: I got a rpi2 'Translation Fault (L1)' crash that I also report here, -r325700 based context] Message-ID: <20171119161917.GA49502@www.zefox.net> References: <20171118165638.GA47956@www.zefox.net> <1A09ACF9-1A85-480D-90BD-9886FC54D116@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 16:19:09 -0000 On Sun, Nov 19, 2017 at 12:15:47AM -0800, Mark Millard wrote: > Do you get any messages like: > > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > . . . > smsc0: warning: Failed to write register 0x114 > . . . Nothing of that sort. The closest thing to a system-level error I saw was the appearance of what looked like a console message which appeared instead on an ssh session su-ed to root. There was no corresponding message on the serial console. Alas, the scrollback buffer on the root ssh session doesn't go back far enough to retrieve it. In some ways it looked almost as if the kernel was talking to wrong device files. However, the mischief was confined exclusively to make sessions run in /usr/ports. Make run in /usr/src has (so far) worked without any oddities. I don't think a make session run in /usr/ports has finished on anything, even make clean, without some sort of error event. Thanks for reading, and any insights... bob prohaska From owner-freebsd-arm@freebsd.org Sun Nov 19 16:57: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 25115DB957F for ; Sun, 19 Nov 2017 16:57:04 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from fallback.mail.ru (fallback4.mail.ru [94.100.181.169]) (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 904E77EC53 for ; Sun, 19 Nov 2017 16:57:02 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from [10.161.22.25] (port=47504 helo=smtp55.i.mail.ru) by fallback4.mail.ru with esmtp (envelope-from ) id 1eGSto-0003gs-H0 for freebsd-arm@freebsd.org; Sun, 19 Nov 2017 19:56:52 +0300 Received: by smtp55.i.mail.ru with esmtpa (envelope-from ) id 1eGSte-0006dx-MK for freebsd-arm@freebsd.org; Sun, 19 Nov 2017 19:56:44 +0300 Date: Sun, 19 Nov 2017 16:56:33 +0000 From: qroxana To: freebsd-arm@freebsd.org Subject: orangepi-plus-2e.dtb not working any more MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-7FA49CB5: 0D63561A33F958A5F1332C9D03D9A5908418485989E116BD0E7F839AE9AE0281725E5C173C3A84C33ABC0F576A1641EC356E7185B4FA520728A6D463EDFD0DBBC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0FBD8D53030842A14A574AF45C6390F7469DAA53EE0834AAEE X-Mailru-Sender: 7D0D47836E5066826FAE144A65460DF1111A5EAF4D31BCA97D922687D1B83B9E1E812D0E9FCFB9579BBFFF7D229A147FFDD1F2F6C9B53D730D187FEF3E0D57C1D08349341B303650BDF7E317B72FD726EC982BF62A43B37A04568DD965327F405FEEDEB644C299C0ED14614B50AE0675 X-Mras: OK X-Mras: OK X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 16:57:04 -0000 Hi, I also tried to boot my OrangePi Plus2E board with nanopi-neo.dtb and it worked, except the awg0 status stays "no carrier" anyway. Here's the log of booting with orangepi-plus-2e.dtb: U-Boot 2017.09 (Nov 10 2017 - 19:38:12 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus 2E DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 237996 bytes read in 40 ms (5.7 MiB/s) ## Starting application at 0x42000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0xb9f477e0 FreeBSD/armv7 U-Boot loader, Revision 1.2 (Tue Oct 24 23:34:02 UTC 2017 root@orangepi) DRAM: 2048MB MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel text=0x7bfe98 data=0x76e10+0x17c330 syms=[0x4+0x8e560+0x4+0xcf437] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 2 seconds... Type '?' for a list of commands, 'help' for more detailed help. loader> load -t dtb /boot/dtb/orangepi-plus-2e.dtb /boot/dtb/orangepi-plus-2e.dtb size=0x53cd loader> boot Booting... Using DTB from loaded file '/boot/dtb/orangepi-plus-2e.dtb'. Kernel entry at 0x42200180... Kernel args: (null) 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 r324846: Wed Oct 27 05:20:15 UTC 2017 root@orangepi:/usr/obj/usr/src/sys/GENERIC-NODEBUG arm FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) VT: init without driver. CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, PXN, LPAE, Coherent Walk Optional instructions: SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory = 2147483648 (2048 MB) avail memory = 2089316352 (1992 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 clk_fixed2: on aw_ccu0 simplebus0: on ofwbus0 aw_ccung0: mem 0x1c20000-0x1c203ff on simplebus0 iichb0: mem 0x1c2ac00-0x1c2afff irq 30 on simplebus0 iicbus0: on iichb0 aw_ccung1: mem 0x1f01400-0x1f014ff on simplebus0 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 regfix4: on ofwbus0 regfix5: on ofwbus0 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 aw_sid0: mem 0x1c14000-0x1c143ff on simplebus0 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 awusbphy0: mem 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803,0x1c1c800-0x1c1c803,0x1c1d800-0x1c1d803 on simplebus0 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 33 on simplebus0 gic0: pn 0x1, arch 0x2, rev 0x1, implementer 0x43b irqs 160 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 gpio0: mem 0x1c20800-0x1c20bff irq 17,18 on simplebus0 gpiobus0: on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 37 on simplebus0 gpiobus1: on gpio1 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 rtc0: mem 0x1f00000-0x1f00053 irq 34,35 on simplebus0 rtc0: registered as a time-of-day clock, resolution 1.000000s iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff irq 39 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 a31dmac0: mem 0x1c02000-0x1c02fff irq 4 on simplebus0 a10_mmc0: mem 0x1c0f000-0x1c0ffff irq 5 on simplebus0 mmc0: on a10_mmc0 a10_mmc1: mem 0x1c10000-0x1c10fff irq 6 on simplebus0 a10_mmc1: cannot reset the controller device_attach: a10_mmc1 attach returned 6 a10_mmc1: mem 0x1c11000-0x1c11fff irq 7 on simplebus0 mmc1: on a10_mmc1 ehci0: mem 0x1c1b000-0x1c1b0ff irq 11 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci1: mem 0x1c1c000-0x1c1c0ff irq 13 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci2: mem 0x1c1d000-0x1c1d0ff irq 15 on simplebus0 usbus2: EHCI version 1.0 usbus2 on ehci2 gpioc0: on gpio0 aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 23 on simplebus0 pcm0: mem 0x1c22c00-0x1c22fff irq 25 on simplebus0 Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc0c13bc8 FSR=00000005, FAR=00000004, spsr=600000d3 r0 =c53ed000, r1 =00000000, r2 =00000080, r3 =00000000 r4 =c53ed000, r5 =c528b500, r6 =c53ed000, r7 =00000000 r8 =00000007, r9 =00000000, r10=ffffffff, r11=c0c13c78 r12=00000080, ssp=c0c13c58, slr=c05ec914, pc =c05eca24 [ thread pid 0 tid 100000 ] Stopped at h3_pr_set_clear+0x20: ldmib r1, {r0-r1} db> bt Tracing pid 0 tid 100000 td 0xc0960b80 db_trace_self() at db_trace_self pc = 0xc05bae00 lr = 0xc005eb90 (db_stack_trace+0x108) sp = 0xc0c138d8 fp = 0xc0c138f0 db_stack_trace() at db_stack_trace+0x108 pc = 0xc005eb90 lr = 0xc005e7ec (db_command+0x268) sp = 0xc0c138f8 fp = 0xc0c13998 r4 = 0x00000001 r5 = 0x00000000 r6 = 0xc0705ed2 r10 = 0x00000000 db_command() at db_command+0x268 pc = 0xc005e7ec lr = 0xc005e574 (db_command_loop+0x74) sp = 0xc0c139a0 fp = 0xc0c139b0 r4 = 0xc06bb568 r5 = 0xc06e2a7b r6 = 0xc095df9c r7 = 0xc0c13bc8 r8 = 0xc08321dc r9 = 0xc07c7a38 r10 = 0xc094f620 db_command_loop() at db_command_loop+0x74 pc = 0xc005e574 lr = 0xc0062010 (db_trap+0x12c) sp = 0xc0c139b8 fp = 0xc0c13ad0 r4 = 0x00000000 r5 = 0xc095dfa8 r6 = 0xc094f640 r10 = 0xc094f620 db_trap() at db_trap+0x12c pc = 0xc0062010 lr = 0xc02d9a6c (kdb_trap+0x168) sp = 0xc0c13ad8 fp = 0xc0c13b00 r4 = 0x00000000 r5 = 0x00000005 r6 = 0xc094f640 r7 = 0xc0c13bc8 kdb_trap() at kdb_trap+0x168 pc = 0xc02d9a6c lr = 0xc05de28c (abort_fatal+0x20c) sp = 0xc0c13b08 fp = 0xc0c13b28 r4 = 0xc0c13bc8 r5 = 0x00000013 r6 = 0x00000004 r7 = 0x00000005 r8 = 0x00000005 r9 = 0xc0960b80 r10 = 0xc0c13bc8 abort_fatal() at abort_fatal+0x20c pc = 0xc05de28c lr = 0xc05ddef0 (abort_handler+0x318) sp = 0xc0c13b30 fp = 0xc0c13bc0 r4 = 0x00000005 r5 = 0x00000005 r6 = 0x00000000 r7 = 0x00000005 r8 = 0x00000013 r10 = 0xc0c13bc8 abort_handler() at abort_handler+0x318 pc = 0xc05ddef0 lr = 0xc05bd7f8 (exception_exit) sp = 0xc0c13bc8 fp = 0xc0c13c78 r4 = 0xc53ed000 r5 = 0xc528b500 r6 = 0xc53ed000 r7 = 0x00000000 r8 = 0x00000007 r9 = 0x00000000 r10 = 0xffffffff exception_exit() at exception_exit pc = 0xc05bd7f8 lr = 0xc05ec914 (h3_mixer_init+0x58) sp = 0xc0c13c58 fp = 0xc0c13c78 r0 = 0xc53ed000 r1 = 0x00000000 r2 = 0x00000080 r3 = 0x00000000 r4 = 0xc53ed000 r5 = 0xc528b500 r6 = 0xc53ed000 r7 = 0x00000000 r8 = 0x00000007 r9 = 0x00000000 r10 = 0xffffffff r12 = 0x00000080 h3_pr_set_clear() at h3_pr_set_clear+0x20 pc = 0xc05eca24 lr = 0xc05ec914 (h3_mixer_init+0x58) sp = 0xc0c13c80 fp = 0xc0c13c88 r4 = 0xc53ed000 r5 = 0xc528b500 r6 = 0xc528b500 r7 = 0x00000000 r8 = 0xc53ed000 r9 = 0x00000000 r10 = 0xffffffff h3_mixer_init() at h3_mixer_init+0x58 pc = 0xc05ec914 lr = 0xc01008e0 (mixer_obj_create+0x124) sp = 0xc0c13c90 fp = 0xc0c13ca8 r4 = 0xc53ee000 r5 = 0x00000000 mixer_obj_create() at mixer_obj_create+0x124 pc = 0xc01008e0 lr = 0xc0100a0c (mixer_init+0xac) sp = 0xc0c13cb0 fp = 0xc0c13ce0 r4 = 0xc518fa00 r5 = 0x00000000 r6 = 0xc53ed000 r7 = 0xc081ae7c r8 = 0x00000000 r9 = 0xc528b500 mixer_init() at mixer_init+0xac pc = 0xc0100a0c lr = 0xc05ec378 (a10codec_attach+0x2fc) sp = 0xc0c13ce8 fp = 0xc0c13d78 r4 = 0xc528b500 r5 = 0xc53ed000 r6 = 0xc53ed004 r7 = 0xffffffff r8 = 0x00000000 r9 = 0x00002084 r10 = 0xc528b550 a10codec_attach() at a10codec_attach+0x2fc pc = 0xc05ec378 lr = 0xc02cbb18 (device_attach+0x4ec) sp = 0xc0c13d80 fp = 0xc0c13dc8 r4 = 0xc528b500 r5 = 0xc528cb80 r6 = 0xc528cb80 r7 = 0x00000000 r8 = 0xc095d80c r9 = 0xc02cfd58 device_attach() at device_attach+0x4ec pc = 0xc02cbb18 lr = 0xc02cd69c (bus_generic_new_pass+0x118) sp = 0xc0c13dd0 fp = 0xc0c13de8 r4 = 0xc528b500 r5 = 0xc07ecc5c r6 = 0xc0961cfc r7 = 0xc5167000 r8 = 0xc094f4b0 r9 = 0xc0720bd4 r10 = 0xc0960f48 bus_generic_new_pass() at bus_generic_new_pass+0x118 pc = 0xc02cd69c lr = 0xc02cd664 (bus_generic_new_pass+0xe0) sp = 0xc0c13df0 fp = 0xc0c13e08 r4 = 0xc528cb80 r5 = 0xc07ecc5c r6 = 0xc0961cfc r7 = 0x00000000 r8 = 0xc094f4b0 r10 = 0xc0960f48 bus_generic_new_pass() at bus_generic_new_pass+0xe0 pc = 0xc02cd664 lr = 0xc02cd664 (bus_generic_new_pass+0xe0) sp = 0xc0c13e10 fp = 0xc0c13e28 r4 = 0xc528cd00 r5 = 0xc07ecc5c r6 = 0xc0961cfc r7 = 0x00000000 r8 = 0xc094f4b0 r10 = 0xc0960f48 bus_generic_new_pass() at bus_generic_new_pass+0xe0 pc = 0xc02cd664 lr = 0xc02cd664 (bus_generic_new_pass+0xe0) sp = 0xc0c13e30 fp = 0xc0c13e48 r4 = 0xc528cd80 r5 = 0xc07ecc5c r6 = 0xc0961cfc r7 = 0x00000000 r8 = 0xc094f4b0 r10 = 0xc0960f48 bus_generic_new_pass() at bus_generic_new_pass+0xe0 pc = 0xc02cd664 lr = 0xc02cf0f8 (root_bus_configure+0x80) sp = 0xc0c13e50 fp = 0xc0c13e68 r4 = 0xc07ecc5c r5 = 0xc528d000 r6 = 0xc094f4b0 r7 = 0xc5292000 r8 = 0xc096190c r10 = 0xc0960f48 root_bus_configure() at root_bus_configure+0x80 pc = 0xc02cf0f8 lr = 0xc0223cb4 (mi_startup+0xfc) sp = 0xc0c13e70 fp = 0xc0c13e90 r4 = 0xc0961044 r5 = 0x00000001 r6 = 0xc071fc6c r7 = 0x00000000 r8 = 0xc0961040 r10 = 0xc0960f48 mi_startup() at mi_startup+0xfc pc = 0xc0223cb4 lr = 0xc00002c4 (btext+0x144) sp = 0xc0c13e98 fp = 0x00000000 r4 = 0xc00003f8 r5 = 0xc09b0000 r6 = 0x4205a400 r7 = 0x00c52078 r8 = 0xc0b1f000 r9 = 0x00000014 r10 = 0x0000000a btext() at btext+0x144 pc = 0xc00002c4 lr = 0xc00002c4 (btext+0x144) sp = 0xc0c13e98 fp = 0x00000000 db> From owner-freebsd-arm@freebsd.org Sun Nov 19 22:12: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 69A7ADBFB1D for ; Sun, 19 Nov 2017 22:12:56 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 06AAF65D3E for ; Sun, 19 Nov 2017 22:12:55 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x55b3cd0c.dyn.telefonica.de [85.179.205.12]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vAJMCgnC017271 for ; Sun, 19 Nov 2017 23:12:42 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Sun, 19 Nov 2017 23:12:41 +0100 (CET) Message-ID: <4b05d0c082a.5171d271@mail.schwarzes.net> In-Reply-To: <0706441c-eee7-9f6e-3e3b-44a362bc7317@restart.be> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <3e6a8ce3-1b12-1557-ad0c-7b2259ced263@restart.be> <4b021ad4813.3aa2749e@mail.schwarzes.net> <32fb3c08-9fc8-a8b2-000b-b9932a69cebf@restart.be> <0706441c-eee7-9f6e-3e3b-44a362bc7317@restart.be> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Sun, 19 Nov 2017 23:12:42 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 22:12:56 -0000 On 17.11.17, Henri Hennebert wrote: > On 11/17/2017 11:57, Henri Hennebert wrote: >> FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 = >> r320599M: Mon Oct=A0 2 10:06:00 CEST 2017 = >> root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY=A0 arm64 >> = >> without ntpd, keeps time correctly after 3 hours and with make = >> buildworld running. > > But after 2 more hours, it was 3 minutes too fast :-( A sudden step of 3 minutes, maybe some bits are mixed up. Could be the = hardware, no one can confirm this problem. Do you have checked the power = supply? -asc From owner-freebsd-arm@freebsd.org Mon Nov 20 12:44:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3478ADEAAD0 for ; Mon, 20 Nov 2017 12:44:13 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B70897C2AB; Mon, 20 Nov 2017 12:44:12 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=ian@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ygT1P6Yc2zv0c Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ygT1P6Yc2zv0c; Mon, 20 Nov 2017 13:44:09 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAKCi7Mb048524 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Nov 2017 13:44:08 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: Ian Lepore , Andreas Schwarz , freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <1510851514.99235.378.camel@freebsd.org> From: Henri Hennebert Message-ID: <55dd038f-4d82-4fca-bd57-8315bb99c38b@restart.be> Date: Mon, 20 Nov 2017 13:44:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1510851514.99235.378.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 12:44:13 -0000 On 11/16/2017 17:58, Ian Lepore wrote: > On Tue, 2017-11-14 at 23:03 +0100, Andreas Schwarz wrote: >> On 14.11.17, Henri Hennebert wrote: >>> >>> On 11/13/2017 21:03, Mark Millard wrote: >>>> >>>> >>>> So it looks like you are getting bad times from at >>>> least 2 servers. Note that the other servers seem >>>> fine as far as your e-mailed material goes. >>> I believe that the clock of the Pine64+ is going too fast and that the 2 >>> servers where polled and so show this offset/jitter. In an other >>> occurrence of this problem, if I wait long enough, all servers display >>> huge offset. >> But they step not simultaneous to this offset (which is ~300s), why should some >> servers have such offset and others not?. >> > > Because not all peers are being polled at the same time, and the offset > and jitter are updated only after a polling cycle.  In the last ntpq: > >>>       remote           refid      st t when poll reach   delay   offset jitter >>> ============================================================================== >>> 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000    0.000  0.000 >>> -webhost2.mitht. 193.67.79.202    2 u  948 1024  177   58.815    1.451 0.932 >>> +ns2.telecom.lt  212.59.3.3       2 u   13 1024  177   43.400  -357912 357913. >>> +ntp.bserved.nl  193.67.79.202    2 u 1111 1024   37   17.664    0.980 0.379 >>> -178.32.44.208 ( 193.190.230.65   2 u   81 1024  177   14.930    1.087 135278. >>> *stratum2-1.NTP. 129.70.130.71    2 u 1077 1024   77   28.135    1.998 0.570 >>> -linode.ibendit. 199.102.46.77    2 u 2048 1024   76  129.945    0.307 0.584 >>> #193.104.37.238  193.190.230.66   2 u  799 1024   77   14.977    1.321 0.821 > > Notice that the two anomalous servers are the ones with a small "when" > value, indicating they were polled within the last couple minutes. > > Also, the fact that some of the "when" values are larger than the > polling interval is unusual... that would tend to indicate network > trouble... some of the servers are only beeing reached intermitantly > (which can be seen by the incomplete "reach" masks). > > The idea that two public stratum-2 servers are providing consistant bad > time is not a viable theory. > > Also, the time is good and stable for several of the ten-minute > intervals, and it was good for long enough that the polling interval > ramped up from 64 to 1024 seconds (assuming there is no "minpoll" > override forcing it to 1024 in ntp.conf).  That argues against any kind > of constant clock-drift problem.  Either the clock is stepping due to a > problem in the driver such as not handling rollover of a 32-bit > register, or the clock goes wildly off-frequency, but only > intermittantly.  The latter might happen if the cpu clock is being used > as a timecounter and the cpu falls back to a low-power mode that cuts > the clock frequency in half or something. Thank you for those illuminating informations I will try another Pine64+ and a new power supply Henri > -- Ian > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Nov 20 16:58:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D61ABDF0F45 for ; Mon, 20 Nov 2017 16:58:24 +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 B59B564CD9 for ; Mon, 20 Nov 2017 16:58:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vAKGwWJv055870 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Nov 2017 08:58:33 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAKGwWaI055869; Mon, 20 Nov 2017 08:58:32 -0800 (PST) (envelope-from fbsd) Date: Mon, 20 Nov 2017 08:58:32 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: ssh sessions close spontaneously on rpi2 Message-ID: <20171120165832.GA55836@www.zefox.net> References: <20171118165638.GA47956@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171118165638.GA47956@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 16:58:24 -0000 Can anybody reproduce the following behavior on RPI2 ? Boot the machine multi-user and start two ssh login sessions. On one, start a top session, as a placeholder. On the second, su to root, cd to /usr/ports and run make -j8 clean > clean.log & Next, try to open another (this makes three) ssh connection. Log in, and just watch. On my test box at FreeBSD 12.0-CURRENT (RPI2) #10 r325987 the connection fails within a couple of minutes; the login session terminates without explanation and the connection closes. No errors are on the serial console, /var/log/messages records nothing related. Ssh sessions started prior to starting make clean seem unaffected. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Nov 21 15:33:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D48A1DF18EF for ; Tue, 21 Nov 2017 15:33:40 +0000 (UTC) (envelope-from jselwitz@verizon.net) Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (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 AF8C572A56 for ; Tue, 21 Nov 2017 15:33:40 +0000 (UTC) (envelope-from jselwitz@verizon.net) Received: from mtaout-mbe02.mx.aol.com (mtaout-mbe02.mx.aol.com [172.26.254.174]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id 9EB96380031D for ; Tue, 21 Nov 2017 10:33:38 -0500 (EST) Received: from [172.28.1.169] (rrcs-208-105-143-82.nys.biz.rr.com [208.105.143.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mtaout-mbe02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 87E1F38000086 for ; Tue, 21 Nov 2017 10:33:37 -0500 (EST) Date: Tue, 21 Nov 2017 10:33:24 -0500 Subject: RPI2 Hanging on boot. Message-ID: X-Android-Message-ID: From: Jason To: freebsd-arm@freebsd.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal x-aol-global-disposition: G x-aol-sid: 3039ac1afeae5a1447512b33 X-AOL-IP: 208.105.143.82 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:33:40 -0000 From owner-freebsd-arm@freebsd.org Tue Nov 21 20:28: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 ECE2ED937A2 for ; Tue, 21 Nov 2017 20:28:10 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 787B97E8FA for ; Tue, 21 Nov 2017 20:28:09 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4e33346f.dyn.telefonica.de [78.51.52.111]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vALKS5nn030916 for ; Tue, 21 Nov 2017 21:28:06 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 21 Nov 2017 21:28:05 +0100 (CET) Message-ID: <4b085b60112.4d5474c1@mail.schwarzes.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: RPI2-B FreeBSD:12:armv7 repository not existing MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Tue, 21 Nov 2017 21:28:06 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 20:28:11 -0000 I run into problem with the latest update of pkg (to pkg-1.10.2), pkg is now using the correct ABI for requesting the package repository. Unfortunately there is no "FreeBSD:12:armv7" at the moment at pkg.freebsd.org, so pkg will not work anymore per default at armv7 installations. A workaround is to add "ABI: FreeBSD:12:armv6" to /usr/local/etc/pkg.conf, will force pkg to use armv6. -asc From owner-freebsd-arm@freebsd.org Tue Nov 21 21:15: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 7855DD94E70 for ; Tue, 21 Nov 2017 21:15:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-143.reflexion.net [208.70.210.143]) (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 2D509804A0 for ; Tue, 21 Nov 2017 21:15:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13916 invoked from network); 21 Nov 2017 21:15:07 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Nov 2017 21:15:07 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 21 Nov 2017 16:15:07 -0500 (EST) Received: (qmail 13800 invoked from network); 21 Nov 2017 21:15:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Nov 2017 21:15:07 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A591EEC7E18; Tue, 21 Nov 2017 13:15:06 -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.3 \(3273\)) Subject: Re: ssh sessions close spontaneously on rpi2 Date: Tue, 21 Nov 2017 13:15:05 -0800 References: <20171118165638.GA47956@www.zefox.net> <20171120165832.GA55836@www.zefox.net> To: bob prohaska , Freebsd-arm In-Reply-To: <20171120165832.GA55836@www.zefox.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 21:15:09 -0000 On 2017-Nov-20, at 8:58 AM, bob prohaska wrote: > Can anybody reproduce the following behavior on RPI2 ? >=20 > Boot the machine multi-user and start two ssh login sessions. >=20 > On one, start a top session, as a placeholder. On the second, > su to root, cd to /usr/ports and run > make -j8 clean > clean.log & >=20 > Next, try to open another (this makes three) ssh connection. Log in, > and just watch.=20 >=20 > On my test box at FreeBSD 12.0-CURRENT (RPI2) #10 r325987 the = connection > fails within a couple of minutes; the login session terminates without > explanation and the connection closes.=20 >=20 > No errors are on the serial console, /var/log/messages records nothing > related. Ssh sessions started prior to starting make clean seem = unaffected. Given the messages that I've been getting but you have not, I figure my attempting this under my current conditions would not be effective. But I've another oddity that you might try: A) I booted and ran top on the serial console ( top -CaePosize ) B) I logged in 4 ssh sessions and had each do "openssl speed" top gets an unexpected result: CPU 2 shows as 100% idle and the others 0.0% idle. The process CPU column agrees, in that that the total is around 300% instead of around 400%. A couple of the tend to show closer to 50% as long as 4 are running. At 3 running it goes back to each being near 100%. # uname -apKU FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r325700M arm armv7 = 1200053 1200053 (I normally run a non-debug kernel that has debug symbols.) I may try jumping to -r325997 . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Nov 21 21:36: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 2D9CDDB893B for ; Tue, 21 Nov 2017 21:36:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-103.reflexion.net [208.70.210.103]) (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 CDC3881245 for ; Tue, 21 Nov 2017 21:36:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15346 invoked from network); 21 Nov 2017 21:36:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Nov 2017 21:36:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 21 Nov 2017 16:36:45 -0500 (EST) Received: (qmail 15866 invoked from network); 21 Nov 2017 21:36:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Nov 2017 21:36:45 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 131B2EC7E18; Tue, 21 Nov 2017 13:36:45 -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.3 \(3273\)) Subject: Re: ssh sessions close spontaneously on rpi2 Date: Tue, 21 Nov 2017 13:36:44 -0800 References: <20171118165638.GA47956@www.zefox.net> <20171120165832.GA55836@www.zefox.net> To: bob prohaska , Freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 21:36:48 -0000 On 2017-Nov-21, at 1:15 PM, Mark Millard wrote: > On 2017-Nov-20, at 8:58 AM, bob prohaska = wrote: >=20 >> Can anybody reproduce the following behavior on RPI2 ? >>=20 >> Boot the machine multi-user and start two ssh login sessions. >>=20 >> On one, start a top session, as a placeholder. On the second, >> su to root, cd to /usr/ports and run >> make -j8 clean > clean.log & >>=20 >> Next, try to open another (this makes three) ssh connection. Log in, >> and just watch.=20 >>=20 >> On my test box at FreeBSD 12.0-CURRENT (RPI2) #10 r325987 the = connection >> fails within a couple of minutes; the login session terminates = without >> explanation and the connection closes.=20 >>=20 >> No errors are on the serial console, /var/log/messages records = nothing >> related. Ssh sessions started prior to starting make clean seem = unaffected. >=20 > Given the messages that I've been getting but you have not, > I figure my attempting this under my current conditions > would not be effective. >=20 > But I've another oddity that you might try: >=20 > A) I booted and ran top on the serial console ( top -CaePosize ) > B) I logged in 4 ssh sessions and had each do "openssl speed" >=20 > top gets an unexpected result: CPU 2 shows as 100% idle and the > others 0.0% idle. >=20 > The process CPU column agrees, in that that the total is > around 300% instead of around 400%. A couple of the > tend to show closer to 50% as long as 4 are running. > At 3 running it goes back to each being near 100%. >=20 > # uname -apKU > FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r325700M arm armv7 = 1200053 1200053 >=20 > (I normally run a non-debug kernel that has debug symbols.) >=20 > I may try jumping to -r325997 . >=20 I rebooted and ended up stuck at Releasing APs. I cut and restored power and booted. And now all the cores seem to be in use. Still -r325700 . Not easily repeatable from what I can tell. A question for your test: what if you substitute computation-bound processes for your -j8 make? Do you get different results? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Nov 22 17:36:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17C5ADF0BFB; Wed, 22 Nov 2017 17:36:08 +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 C4CD72D42; Wed, 22 Nov 2017 17:36:07 +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 vAMHaEh3063267 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Nov 2017 09:36:15 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAMHaECH063266; Wed, 22 Nov 2017 09:36:14 -0800 (PST) (envelope-from fbsd) Date: Wed, 22 Nov 2017 09:36:13 -0800 From: bob prohaska To: Mark Millard Cc: Freebsd-arm , ports@freebsd.org Subject: Re: ssh sessions close spontaneously on rpi2 Message-ID: <20171122173613.GA63035@www.zefox.net> References: <20171118165638.GA47956@www.zefox.net> <20171120165832.GA55836@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 17:36:08 -0000 On Tue, Nov 21, 2017 at 01:15:05PM -0800, Mark Millard wrote: > > But I've another oddity that you might try: > > A) I booted and ran top on the serial console ( top -CaePosize ) > B) I logged in 4 ssh sessions and had each do "openssl speed" > > top gets an unexpected result: CPU 2 shows as 100% idle and the > others 0.0% idle. > On FreeBSD 12.0-CURRENT (RPI2) #11 r326038: Wed Nov 22 01:04:56 PST 2017 the behavior seems reasonable: last pid: 743; load averages: 3.88, 2.12, 0.97 up 0+00:35:32 08:51:39 28 processes: 5 running, 23 sleeping CPU: 97.3% user, 0.0% nice, 0.6% system, 2.2% interrupt, 0.0% idle Mem: 22M Active, 4380K Inact, 65M Wired, 33M Buf, 824M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 739 bob 1 102 0 7404K 4496K CPU3 3 3:56 103.68% openssl 737 bob 1 103 0 7404K 4496K RUN 2 4:16 99.53% openssl 741 bob 1 103 0 7404K 4496K CPU1 1 2:25 98.15% openssl 740 bob 1 102 0 7404K 4496K CPU0 0 3:47 92.67% openssl 694 bob 1 20 0 6508K 3060K CPU2 2 0:02 0.42% top 714 bob 1 20 0 11188K 6756K select 2 0:00 0.05% sshd 706 bob 1 20 0 11188K 6756K select 2 0:00 0.04% sshd 603 root 1 20 0 8156K 5096K select 1 0:00 0.02% sendmail Far as I can tell the problems with ssh disconnection are tied to running make -jN processes in /usr/ports. Make -j4 buildworld in /usr/src does not obviously interfere with subsequent ssh connections. Running make -j4 -DBATCH in /usr/ports/www/firefox also breaks ssh connections, but not quite so fast, it takes a few minutes for new ssh sessions to fail. Incidentally, the -DBATCH flag is ignored. That make stopped on a stale readline installation. After manually upgrading readline, the make was restarted without -j4 in /usr/ports/www/firefox and, some ten minutes later, the ssh connections are still working. Looks like the trouble is related to make -jN, but only in /usr/ports. It's understood the -j option is not a sure thing in ports, but having it interfere with ssh connections seems most strange. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Nov 22 21:26: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 C41E7DF63B0 for ; Wed, 22 Nov 2017 21:26:27 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [103.78.157.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BD906AF70 for ; Wed, 22 Nov 2017 21:26:26 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id vAMLFxvX014888 for ; Thu, 23 Nov 2017 08:16:00 +1100 (AEDT) (envelope-from freebsd-arm@sentry.org) Subject: Re: ssh sessions close spontaneously on rpi2 References: <20171118165638.GA47956@www.zefox.net> <20171120165832.GA55836@www.zefox.net> <20171122173613.GA63035@www.zefox.net> Cc: freebsd-arm From: Trev Message-ID: <5756fea2-750a-6827-fcc4-163e6f21d264@sentry.org> Date: Thu, 23 Nov 2017 08:15:59 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 MIME-Version: 1.0 In-Reply-To: <20171122173613.GA63035@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Thu, 23 Nov 2017 08:16:00 +1100 (AEDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 21:26:27 -0000 bob prohaska wrote on 23/11/2017 04:36: [chomp] > Far as I can tell the problems with ssh disconnection are tied to > running make -jN processes in /usr/ports. Make -j4 buildworld in /usr/src > does not obviously interfere with subsequent ssh connections. > > Running make -j4 -DBATCH in /usr/ports/www/firefox also breaks ssh connections, > but not quite so fast, it takes a few minutes for new ssh sessions to fail. > Incidentally, the -DBATCH flag is ignored. > > That make stopped on a stale readline installation. After manually upgrading > readline, the make was restarted without -j4 in /usr/ports/www/firefox and, > some ten minutes later, the ssh connections are still working. > > Looks like the trouble is related to make -jN, but only in /usr/ports. It's > understood the -j option is not a sure thing in ports, but having it > interfere with ssh connections seems most strange. I've had similar issues (wireless USB dongle failing and settings being corrupted) with FreeBSD 11 Stable - I tracked it down to power usage when using make -j (I have two 32GB USB memory dongles also plugged in, one of which contains /usr). May be related? From owner-freebsd-arm@freebsd.org Wed Nov 22 22:11: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 5E794DF70B2; Wed, 22 Nov 2017 22:11:25 +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 35CBE6C766; Wed, 22 Nov 2017 22:11:25 +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 vAMMBc2T063930 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Nov 2017 14:11:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAMMBcG8063929; Wed, 22 Nov 2017 14:11:38 -0800 (PST) (envelope-from fbsd) Date: Wed, 22 Nov 2017 14:11:38 -0800 From: bob prohaska To: Trev Cc: freebsd-arm , ports@freebsd.org Subject: Re: ssh sessions close spontaneously on rpi2 Message-ID: <20171122221138.GA63801@www.zefox.net> References: <20171118165638.GA47956@www.zefox.net> <20171120165832.GA55836@www.zefox.net> <20171122173613.GA63035@www.zefox.net> <5756fea2-750a-6827-fcc4-163e6f21d264@sentry.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5756fea2-750a-6827-fcc4-163e6f21d264@sentry.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 22:11:25 -0000 On Thu, Nov 23, 2017 at 08:15:59AM +1100, Trev wrote: > bob prohaska wrote on 23/11/2017 04:36: > > [snip] > > > > some ten minutes later, the ssh connections are still working. > > After some three hours, the ssh connections all failed, merely saying "connection closed". The host remained up and responsive. > > I've had similar issues (wireless USB dongle failing and settings being > corrupted) with FreeBSD 11 Stable - I tracked it down to power usage > when using make -j (I have two 32GB USB memory dongles also plugged in, > one of which contains /usr). May be related? Strikes me as unlikely, since j4 in buildworld causes no such problems. The RPI2 in question uses wired Ethernet and has one 64 GB USB flash drive holding /var, /tmp, /usr and swap. Last time I looked (long ago) the power supply voltage wasn't an issue. I'll try to find my cables and check voltages again, just to be sure. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Nov 23 04:18:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DDF8DC1AE6; Thu, 23 Nov 2017 04:18:24 +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 5B03E7A78E; Thu, 23 Nov 2017 04:18:23 +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 vAN4IaFW064727 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Nov 2017 20:18:37 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAN4IaqH064726; Wed, 22 Nov 2017 20:18:36 -0800 (PST) (envelope-from fbsd) Date: Wed, 22 Nov 2017 20:18:36 -0800 From: bob prohaska To: Kevin Oberman Cc: ports@FreeBSD.org, freebsd-arm@freebsd.org Subject: Re: Dependencies satisfied, build stops anyway. Message-ID: <20171123041836.GA64420@www.zefox.net> References: <20171122232836.GB63801@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 04:18:24 -0000 On Wed, Nov 22, 2017 at 05:12:16PM -0800, Kevin Oberman wrote: > On Wed, Nov 22, 2017 at 3:28 PM, bob prohaska wrote: > > > > > Attempts to compile a number of ports on RPI2, in this case dns/bind910, > > often > > stop with an error along the lines of: > > > > /bin/mkdir -p '/tmp/mountpoint.f1jbPw/devel/gettext-tools/work/stage/usr/ > > local/share/gettext' > > install -m 555 ../build-aux/config.rpath '/tmp/mountpoint.f1jbPw/devel/ > > gettext-tools/work/stage/usr/local/share/gettext' > > ====> Compressing man pages (compress-man) > > ===> Installing for gettext-tools-0.19.8.1 > > ===> Checking if gettext-tools already installed > > ===> gettext-tools-0.19.8.1 is already installed > > You may wish to ``make deinstall'' and install this port again > > by ``make reinstall'' to upgrade it properly. > > If you really wish to overwrite the old port of gettext-tools > > without deleting it first, set the variable "FORCE_PKG_REGISTER" > > in your environment or the "make install" command line. > > *** Error code 1 > > > > In case it isn't obvious, I'm confused. The version sought is found, > > so what's the error? > > > > Thanks for reading, > > > > bob prohaska > > > > The problem is that you have two tools with different means of determining > if a port is present. When the ports system installs a port, it olls at the > pkgdb an makes sure the port is not installed. Unfortunately, pkgdb thinks > it is. > > the easiest fix is to "pkg delete -f gettext-tools" followed be a > re-install. Go to /usr/ports/devel/gettext-tools and make install. If you > are using portmaster, "portmaster -C devel/gettext-tools" will do the job, > as well, but you always need to delete the port. > -- Is there a simple way to force deletion and reinstallation? The number of stale dependencies seems to be vast, and this is on a relatively simple port, dns/bind910. Being on an ARM platform there are no precompiled binaries. Thanks very much! bob prohaska From owner-freebsd-arm@freebsd.org Thu Nov 23 04:32: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 B3216DDB252; Thu, 23 Nov 2017 04:32:55 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 692687AF3B; Thu, 23 Nov 2017 04:32:55 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ua0-x22e.google.com with SMTP id e10so12021876uah.10; Wed, 22 Nov 2017 20:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sUtP/u5jeuLMPn0iyax5n7tZu0ASMqsaBPIlPeqKD7g=; b=GPAkxl7vsnvUCqgjo+BKqyEkUNTTUXmP0MjLPY31buik91ogNG9GiHGYvZp2oURrCr /WYQOVw0J+94om28xkc2O9qnz1KgI4Nr/+6OdhPLEfx0ttRWLzG3imMwA1wrQf84ONHJ YIOlVjbnbz+MrmM94XXotu2Pypw/tGD9aksKZTrRQg75uAUxTY/hmZ3jEXtZ20Hl/VLB 5VPtp/m3SddYZ/jab07fmMsdxldKQt1bn04/V0ZM/FXnubfapWzdtIBHsKvBDgkb6Gcv AyqQPShDzn9lMNmkF7m/ZwIdN9AXcQnt04688Mrt3+/bu+JN8JKKZ5iaK1rlKYgg/LRR ms8g== 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=sUtP/u5jeuLMPn0iyax5n7tZu0ASMqsaBPIlPeqKD7g=; b=CLhpRLQ0MTxwPBVpw0GJkNAkNPNNtEoK47HTVaSbhjgaNelgEpIhML7K0nRe9vkz2s tB6yEYpb/3ATDzzrOv19gz05IoaCj3tSHPM26GndEW18DhD/YPiqLiZKIh8qsOyI50CM yWWzv57R3L/Sxas09mZsXlgAjyUDMibx3OiWHXnXpp7bYQX8dIJ90/GR7XAUO1NST8l/ UA5UhDsdjAa4SGy+LnuK/U76JLStKUh8UoH2o+QfI5rU+6Cs6qkFTLnRsx0DU5I1lO48 yAyFnR9pbP5CQa0QBIEKKLPoFK8zNP/9ugu4uNPWQyaoCU5zTIrSKHUtGhQW9ffLG6/H oAwg== X-Gm-Message-State: AJaThX4qoWXdtViiyD7h217ySgLxMGB2/yIX7OH3k52W9Lx75ez3oeB0 hryG3j4pNggPjWqNRRe6GmK8yrVj1FOb+mx9IqpESHrf X-Google-Smtp-Source: AGs4zMa14X1bxSzQXwOMiTTGEvhHe1592awhsJ1+urm+mKAiRoovHMfQQy+GnPF3TDjREDSnOm1oa7kEjDeht38xhNM= X-Received: by 10.176.8.71 with SMTP id b7mr14336579uaf.168.1511411574182; Wed, 22 Nov 2017 20:32:54 -0800 (PST) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.147.156 with HTTP; Wed, 22 Nov 2017 20:32:53 -0800 (PST) In-Reply-To: <20171123041836.GA64420@www.zefox.net> References: <20171122232836.GB63801@www.zefox.net> <20171123041836.GA64420@www.zefox.net> From: Kevin Oberman Date: Wed, 22 Nov 2017 20:32:53 -0800 X-Google-Sender-Auth: 0RGNkzpMpeNx02YHaKPGtuVNOUA Message-ID: Subject: Re: Dependencies satisfied, build stops anyway. To: bob prohaska Cc: "ports@FreeBSD.org" , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 04:32:55 -0000 On Wed, Nov 22, 2017 at 8:18 PM, bob prohaska wrote: > On Wed, Nov 22, 2017 at 05:12:16PM -0800, Kevin Oberman wrote: > > On Wed, Nov 22, 2017 at 3:28 PM, bob prohaska > wrote: > > > > > > > > Attempts to compile a number of ports on RPI2, in this case > dns/bind910, > > > often > > > stop with an error along the lines of: > > > > > > /bin/mkdir -p '/tmp/mountpoint.f1jbPw/devel/ > gettext-tools/work/stage/usr/ > > > local/share/gettext' > > > install -m 555 ../build-aux/config.rpath > '/tmp/mountpoint.f1jbPw/devel/ > > > gettext-tools/work/stage/usr/local/share/gettext' > > > ====> Compressing man pages (compress-man) > > > ===> Installing for gettext-tools-0.19.8.1 > > > ===> Checking if gettext-tools already installed > > > ===> gettext-tools-0.19.8.1 is already installed > > > You may wish to ``make deinstall'' and install this port again > > > by ``make reinstall'' to upgrade it properly. > > > If you really wish to overwrite the old port of gettext-tools > > > without deleting it first, set the variable "FORCE_PKG_REGISTER" > > > in your environment or the "make install" command line. > > > *** Error code 1 > > > > > > In case it isn't obvious, I'm confused. The version sought is found, > > > so what's the error? > > > > > > Thanks for reading, > > > > > > bob prohaska > > > > > > > The problem is that you have two tools with different means of > determining > > if a port is present. When the ports system installs a port, it olls at > the > > pkgdb an makes sure the port is not installed. Unfortunately, pkgdb > thinks > > it is. > > > > the easiest fix is to "pkg delete -f gettext-tools" followed be a > > re-install. Go to /usr/ports/devel/gettext-tools and make install. If you > > are using portmaster, "portmaster -C devel/gettext-tools" will do the > job, > > as well, but you always need to delete the port. > > -- > > Is there a simple way to force deletion and reinstallation? The number > of stale dependencies seems to be vast, and this is on a relatively > simple port, dns/bind910. Being on an ARM platform there are no > precompiled binaries. > > Thanks very much! > > bob prohaska > Stale ports SHOULD not be an issue. Normally old ports are updated automatically. It is important that your ports tree is consistent and, usually that it is current. Assuming yours is, the only issue is the oddball case like this one. You won't hit them often. Usually it is when a file that is tested for is missing. Usually a library. pkgdb says that the port is installed, but the make looks for the actual library and triggers an install, as opposed to a reinstall, when it is not found. Unled this systm has been massively mangled, it is a very unusual development, at least in my experience. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-arm@freebsd.org Thu Nov 23 05: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 CDE44DDC534; Thu, 23 Nov 2017 05:12:16 +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 0F4FA7BF7A; Thu, 23 Nov 2017 05:12:15 +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 vAN5CTrn064870 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Nov 2017 21:12:29 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAN5CSWa064869; Wed, 22 Nov 2017 21:12:28 -0800 (PST) (envelope-from fbsd) Date: Wed, 22 Nov 2017 21:12:28 -0800 From: bob prohaska To: Kevin Oberman Cc: "ports@FreeBSD.org" , freebsd-arm@freebsd.org Subject: Re: Dependencies satisfied, build stops anyway. Message-ID: <20171123051228.GA64807@www.zefox.net> References: <20171122232836.GB63801@www.zefox.net> <20171123041836.GA64420@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 05:12:16 -0000 On Wed, Nov 22, 2017 at 08:32:53PM -0800, Kevin Oberman wrote: > > Stale ports SHOULD not be an issue. Normally old ports are updated > automatically. It is important that your ports tree is consistent and, > usually that it is current. Assuming yours is, the only issue is the > oddball case like this one. You won't hit them often. Usually it is when a > file that is tested for is missing. Usually a library. pkgdb says that the > port is installed, but the make looks for the actual library and triggers > an install, as opposed to a reinstall, when it is not found. Unled this > systm has been massively mangled, it is a very unusual development, at > least in my experience. > -- Aye, there's the rub 8-) Some time ago I accidentally destroyed most of /usr and ended up reconstructing it from a recent snapshot. Since buildworld and buildkernel seemed to work in /usr/src, I thought /usr/ports would be likewise recovered after a fresh checkout. For now I've set FORCE_PKG_REGISTER=yes in /etc/src.conf and that seems to allow make to proceed without interruptions for dns/bind910, but I gather that's not a long-term fix. Thanks very much! bob prohaska From owner-freebsd-arm@freebsd.org Thu Nov 23 05:23: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 67FA6DDCAEF; Thu, 23 Nov 2017 05:23:49 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 46A927C4C9; Thu, 23 Nov 2017 05:23:48 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vAN5Nokw030267; Wed, 22 Nov 2017 21:23:57 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "ports@freebsd.org>" , , "Kevin Oberman" In-Reply-To: <20171123051228.GA64807@www.zefox.net> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "bob prohaska" Subject: Re: Dependencies satisfied, build stops anyway. Date: Wed, 22 Nov 2017 21:23:56 -0800 Message-Id: <2ab2735988a2d2dee23f00834dee872b@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 05:23:49 -0000 On Wed, 22 Nov 2017 21:12:28 -0800 "bob prohaska" said > On Wed, Nov 22, 2017 at 08:32:53PM -0800, Kevin Oberman wrote: > >=20 > > Stale ports SHOULD not be an issue=2E Normally old ports are updated > > automatically=2E It is important that your ports tree is consistent and, > > usually that it is current=2E Assuming yours is, the only issue is the > > oddball case like this one=2E You won't hit them often=2E Usually it is whe= n a > > file that is tested for is missing=2E Usually a library=2E pkgdb says that = the > > port is installed, but the make looks for the actual library and trigge= rs > > an install, as opposed to a reinstall, when it is not found=2E Unled this > > systm has been massively mangled, it is a very unusual development, at > > least in my experience=2E > > -- >=20 > Aye, there's the rub 8-) >=20 > Some time ago I accidentally destroyed most of /usr and ended up > reconstructing it from a recent snapshot=2E Since buildworld and > buildkernel seemed to work in /usr/src, I thought /usr/ports would > be likewise recovered after a fresh checkout=2E >=20 > For now I've set > FORCE_PKG_REGISTER=3Dyes=20 > in /etc/src=2Econf and that seems to allow make to proceed without > interruptions for dns/bind910, but I gather that's not a long-term > fix=2E I think you might have been better off going with the suggested cd /offending/port make deinstall make reinstall The choice to pollute your environment with FORCE_PKG_REGISTER will simply compound the problem you're already experiencing=2E :( Just saying=2E In the end, you're probably going need to decide on a revision, and check it out for both src && ports=2E Then perform a fresh build(world/kernel) && install world/kernel=2E Else you'll be fighting this and other woes for eternity=2E I'm only saying all this in an effort to help=2E :) All the best, and best of luck=2E :) --Chris >=20 > Thanks very much! >=20 > bob prohaska > From owner-freebsd-arm@freebsd.org Thu Nov 23 07:01:47 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA75ADE1364; Thu, 23 Nov 2017 07:01:47 +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 852AB7F80F; Thu, 23 Nov 2017 07:01:47 +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 vAN71rSV065132 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Nov 2017 23:01:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAN71qg0065130; Wed, 22 Nov 2017 23:01:53 -0800 (PST) (envelope-from fbsd) Date: Wed, 22 Nov 2017 23:01:52 -0800 From: bob prohaska To: Chris H Cc: "ports@freebsd.org>" , freebsd-arm@freebsd.org, Kevin Oberman Subject: Re: Dependencies satisfied, build stops anyway. Message-ID: <20171123070152.GB64807@www.zefox.net> References: <20171123051228.GA64807@www.zefox.net> <2ab2735988a2d2dee23f00834dee872b@udns.ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ab2735988a2d2dee23f00834dee872b@udns.ultimatedns.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 07:01:47 -0000 On Wed, Nov 22, 2017 at 09:23:56PM -0800, Chris H wrote: > I think you might have been better off going with the suggested > cd /offending/port > make deinstall > make reinstall > > The choice to pollute your environment with FORCE_PKG_REGISTER > will simply compound the problem you're already experiencing. :( > Just saying. > > In the end, you're probably going need to decide on a revision, > and check it out for both src && ports. Then perform a fresh > build(world/kernel) && install world/kernel. Else you'll be > fighting this and other woes for eternity. > This is slightly surprising; I know world and kernel need to match fairly closely, but I thought ports could be at least somewhat (days, weeks, possibly months) out of sync, depending on their complexity and what they depend on. > I'm only saying all this in an effort to help. :) > > All the best, and best of luck. :) > I very much appreciate your counsel. This host is essentially expendable, used only to rehearse procedures to be employed on machines whose functions are of some (small) value. bob prohaska From owner-freebsd-arm@freebsd.org Fri Nov 24 06:07: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 CBE57DBAA24; Fri, 24 Nov 2017 06:07:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 736C56727F; Fri, 24 Nov 2017 06:07:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id k82so12947244vkd.5; Thu, 23 Nov 2017 22:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=K19izwOPFGLHSN/ltPBJ68BeeEivti+ab8ZzXFuOLLc=; b=fPmrIAmezeiEw9PJs9j9aSjeKUEPJwFhfk5f4xWfJWW04313v5U2jR+eFpZdSCThX+ I0d9teCL22c0YPo+q+xoUxIIbrhEBgW7lCGmvts8O2XgK5qYHrBFdWpYetN+JHLrjreu 3RtSXwG7gta97PeGPlfG1AbpKuVmudifoCJla5FooTBz86xNabjUqNPCNfUgleuJ+GnK 68VLIUJhpJ4e+ZWT2hjq2kt3vZV2uS/xxMua0EBUNjTtfwtTSDE/Sff60ftMpjplBvgC aF27/EoPN3zw72bu8g4pxP3Ox+SIOkV8CHyH7a7EbtP5f7pqAGOrzOY7FVEg3MJ1f5Kq pPYQ== 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=K19izwOPFGLHSN/ltPBJ68BeeEivti+ab8ZzXFuOLLc=; b=Mz/L2ufFeTijj6Hf/uuDOfv7qN+29FHsBYoy/G7QAVcesH/SXdcThxnpsG3b+JyuS/ xBrx/V2b5+BwR7BOBtAAs5y3TYhBC6NIPM7LW4v+0Cfvs65e7vcA0H/zGhaoKaPXHTxz kNLDygsqVYNCXifADAatNR0ZY4o/CQI1U+KyWfrKCU4DT9KpnTQUknm7wjZ76VEBIfxS 5sRLOXOlCtTrqYOjSVLyucfmn8utvqDlxEygC27Mq0AhaKmO0Vv5cVXVhKtGKNIlVJLt 9qCr4/itJpbABmYyFdm/oxhY5YAedg0SfBv1kw5DLNiBoVwXMAxbtTbakq9N59BjqDkW Chuw== X-Gm-Message-State: AJaThX5n2ik4RUAj+2UkVuQzi6O9enk/ztVvV0HLRQZ/CfGA2roHh1Kh P3fM8S544cVldkNThTvNr5fSfpmNK/TrGIns0sfBdQ== X-Google-Smtp-Source: AGs4zMaRbUt1BCYG0WYHWWdO/5BayF8X/H/X/Mt4LtVbkkhxos+sTGgFU7tLwbWfPoiCGvRatu/dJoeZnjbv3+WBMFw= X-Received: by 10.31.32.70 with SMTP id g67mr19810704vkg.9.1511503657255; Thu, 23 Nov 2017 22:07:37 -0800 (PST) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.147.156 with HTTP; Thu, 23 Nov 2017 22:07:36 -0800 (PST) In-Reply-To: <2ab2735988a2d2dee23f00834dee872b@udns.ultimatedns.net> References: <20171123051228.GA64807@www.zefox.net> <2ab2735988a2d2dee23f00834dee872b@udns.ultimatedns.net> From: Kevin Oberman Date: Thu, 23 Nov 2017 22:07:36 -0800 X-Google-Sender-Auth: ZfO_hi-uv89vqzs4Wuqlct2rmjE Message-ID: Subject: Re: Dependencies satisfied, build stops anyway. To: Chris H Cc: bob prohaska , "ports@freebsd.org>" , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 06:07:38 -0000 On Wed, Nov 22, 2017 at 9:23 PM, Chris H wrote: > On Wed, 22 Nov 2017 21:12:28 -0800 "bob prohaska" > said > > On Wed, Nov 22, 2017 at 08:32:53PM -0800, Kevin Oberman wrote: >> > > Stale ports SHOULD not be an issue. Normally old ports are updated >> > automatically. It is important that your ports tree is consistent and, >> > usually that it is current. Assuming yours is, the only issue is the >> > oddball case like this one. You won't hit them often. Usually it is >> when a >> > file that is tested for is missing. Usually a library. pkgdb says that >> the >> > port is installed, but the make looks for the actual library and >> triggers >> > an install, as opposed to a reinstall, when it is not found. Unled this >> > systm has been massively mangled, it is a very unusual development, at >> > least in my experience. >> > -- >> >> Aye, there's the rub 8-) >> >> Some time ago I accidentally destroyed most of /usr and ended up >> reconstructing it from a recent snapshot. Since buildworld and >> buildkernel seemed to work in /usr/src, I thought /usr/ports would >> be likewise recovered after a fresh checkout. >> >> For now I've set >> FORCE_PKG_REGISTER=yes in /etc/src.conf and that seems to allow make to >> proceed without >> interruptions for dns/bind910, but I gather that's not a long-term >> fix. >> > I think you might have been better off going with the suggested > cd /offending/port > make deinstall > make reinstall > > The choice to pollute your environment with FORCE_PKG_REGISTER > will simply compound the problem you're already experiencing. :( > Just saying. > > In the end, you're probably going need to decide on a revision, > and check it out for both src && ports. Then perform a fresh > build(world/kernel) && install world/kernel. Else you'll be > fighting this and other woes for eternity. > > I'm only saying all this in an effort to help. :) > > All the best, and best of luck. :) > > --Chris > > > >> Thanks very much! >> >> bob prohask > > Ouch! Yes, you have a mess. There is no requirement that ports and src be in sync. If you are running any supported version of FreeBSD (10.4, 11.1, 10-STABLE, or 11-STABLE) or CURRENT, you should be fine with updating your ports tree. Then you can create a list of installed ports, delete all ports, and then re-install from the list. If you use portmaster, the man page has a fairly simple list of steps that can let you do that job. If you rebuild everything from ports, it will take a while. I've done this for well over 1000 ports and it had taken a couple of days. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-arm@freebsd.org Sat Nov 25 22:33: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 9715EDF2454 for ; Sat, 25 Nov 2017 22:33:11 +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 800E172302 for ; Sat, 25 Nov 2017 22:33:11 +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 vAPMXBLS092358 for ; Sat, 25 Nov 2017 22:33:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223874] arm64: kernel does not build with DIAGNOSTIC enabled Date: Sat, 25 Nov 2017 22:33:11 +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: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 22:33:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223874 Bug ID: 223874 Summary: arm64: kernel does not build with DIAGNOSTIC enabled Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org Attempting to build arm64 with options DIAGNOSTIC enabled in kernel config results in: --- pmap.o --- /root/freebsd/sys/arm64/arm64/pmap.c:900:1: error: no previous prototype for function 'pmap_invalidate_page' [-Werror,-Wmissing-prototypes] pmap_invalidate_page(pmap_t pmap, vm_offset_t va) ^ /root/freebsd/sys/arm64/arm64/pmap.c:914:1: error: no previous prototype for function 'pmap_invalidate_range' [-Werror,-Wmissing-prototypes] pmap_invalidate_range(pmap_t pmap, vm_offset_t sva, vm_offset_t eva) ^ /root/freebsd/sys/arm64/arm64/pmap.c:931:1: error: no previous prototype for function 'pmap_invalidate_all' [-Werror,-Wmissing-prototypes] pmap_invalidate_all(pmap_t pmap) ^ --=20 You are receiving this mail because: You are the assignee for the bug.=