From owner-freebsd-arm@freebsd.org Sun Aug 30 02:52:50 2015 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 63ABC9C5D4F for ; Sun, 30 Aug 2015 02:52:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD2C7C0F for ; Sun, 30 Aug 2015 02:52:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id t7U2qh2G030046; Sat, 29 Aug 2015 19:52:43 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id t7U2qhBl030045; Sat, 29 Aug 2015 19:52:43 -0700 (PDT) (envelope-from fbsd) Date: Sat, 29 Aug 2015 19:52:43 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Another RPI2 installworld crash with backtrace and logfile Message-ID: <20150830025243.GL53136@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 02:52:50 -0000 Here's another RPI2 crash during installworld. Uname -a reports FreeBSD www.zefox.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287241M: Fri Aug 28 12:30:06 PDT 2015 bob@www.zefox.org:/usr/obj/usr/src/sys/RPI2 arm This time world and kernel were in sync. Still no output visible from sysctl hw.mmc.debug=1 sysctl hw.sdhci.debug=1 The smsc0 warnings started yesterday while playing with /usr/ports/sysutils/stress. The machine sent a couple of emails complaining about unlink: saved-entropy.8: No such file or directory mv: saved-entropy.5: No such file or directory mv: saved-entropy.4: No such file or directory mv: saved-entropy.2: No such file or directory while stress was running, but nothing else happened. Since it wouldn't crash, svnlite update /usr/src was run and the build commenced. It very slowly worked through buildworld, buildkernel and crashed during installworldworld, installworld's last words were: install -o root -g wheel -m 444 verify_krb5_conf.8.gz /usr/share/man/man8 ===> kerberos5/usr.sbin (install) --- _sub.realinstall --- ===> kerberos5/usr.sbin/iprop-log (install) --- _proginstall --- --- _maninstall --- --- _proginstall --- install -s -o root -g wheel -m 555 iprop-log /usr/sbin/iprop-log --- _maninstall --- install -o root -g wheel -m 444 iprop-log.8.gz /usr/share/man/man8 The console output and backtrace follow. smsc0: warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: ============== REGISTER DUMP ============== sdhci_bcm0-slot0: Sys addr: 0x02012c00 | Version: 0x00009902 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000099 sdhci_bcm0-slot0: Argument: 0x00173000 | 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: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_bcm0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000001 sdhci_bcm0-slot0: Caps: 0x00000000 | Max curr: 0x00000001 sdhci_bcm0-slot0: =========================================== mmc0: CMD25 RESULT: 1 mmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[WRITE(offset=725549056, length=131072)]error = 5 mmc0: CMD25 RESULT: 1 mmcsd0: Error indicated: 1 Timeout mmc0: CMD25 RESULT: 1 mmcsd0: Error indicated: 1 Timeout mmc0: CMD25 RESULT: 1 mmcsd0: Error indicated: 1 Timeout mmc0: CMD25 RESULT: 1 mmcsd0: Error indicated: 1 Timeout mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD25 RESULT: 1 mmc0: CMD24 RESULT: 1 mmc0: CMD24 RESULT: 1 mmc0: CMD25 RESULT: 1 g_vfs_done():mmcsd0s2a[WRITE(offset=725680128, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=725811200, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=725942272, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726073344, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726204416, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726335488, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726466560, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726597632, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726728704, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726859776, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=726990848, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=727121920, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=727252992, length=131072)]error = 5 g_vfs_done():mmcsd0s2a[WRITE(offset=20925952, length=2048)]error = 5 panic: brelse: inappropriate B_PAGING or B_CLUSTER bp 0xd75cdb88 cpuid = 0 KDB: enter: panic [ thread pid 12 tid 100014 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 12 tid 100014 td 0xc39fd360 db_trace_self() at db_trace_self pc = 0xc05439ac lr = 0xc0141038 (db_stack_trace+0x108) sp = 0xd69e19d8 fp = 0xd69e19f0 r10 = 0xc07885f8 db_stack_trace() at db_stack_trace+0x108 pc = 0xc0141038 lr = 0xc0140a84 (db_command+0x388) sp = 0xd69e19f8 fp = 0xd69e1a98 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r10 = 0xc07885f8 db_command() at db_command+0x388 pc = 0xc0140a84 lr = 0xc01406ec (db_command_loop+0x74) sp = 0xd69e1aa0 fp = 0xd69e1ab0 r4 = 0xc05aa958 r5 = 0xc05cba03 r6 = 0xc07885e4 r7 = 0xd69e1c80 r8 = 0xc077d620 r9 = 0xc0693ea4 r10 = 0xc077d624 db_command_loop() at db_command_loop+0x74 pc = 0xc01406ec lr = 0xc014321c (db_trap+0x108) sp = 0xd69e1ab8 fp = 0xd69e1bd0 r4 = 0x00000000 r5 = 0xc07885f0 r6 = 0xc077d648 r10 = 0xc077d624 db_trap() at db_trap+0x108 pc = 0xc014321c lr = 0xc02eb6ec (kdb_trap+0x184) sp = 0xd69e1bd8 fp = 0xd69e1c00 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc077d648 r7 = 0xd69e1c80 kdb_trap() at kdb_trap+0x184 pc = 0xc02eb6ec lr = 0xc055ba9c (undefinedinstruction+0x344) sp = 0xd69e1c08 fp = 0xd69e1c78 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc055b6a8 r7 = 0xe7ffffff r8 = 0xc39fd360 r9 = 0xc02eae44 r10 = 0xd69e1c80 undefinedinstruction() at undefinedinstruction+0x344 pc = 0xc055ba9c lr = 0xc0545034 (exception_exit) sp = 0xd69e1c80 fp = 0xd69e1d18 r4 = 0xc05cba58 r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xd69e1d6c r9 = 0xc078a3a0 r10 = 0xc39fd360 exception_exit() at exception_exit pc = 0xc0545034 lr = 0xc02eae34 (kdb_enter+0x48) sp = 0xd69e1d10 fp = 0xd69e1d18 r0 = 0xc077d634 r1 = 0x00000000 r2 = 0xd69e1c44 r3 = 0xc05cfb1d r4 = 0xc05cba58 r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xd69e1d6c r9 = 0xc078a3a0 r10 = 0xc39fd360 r12 = 0xc06aec58 $a.8() at $a.8 pc = 0xc02eae48 lr = 0xc02adfb0 (vpanic+0x164) sp = 0xd69e1d20 fp = 0xd69e1d40 r4 = 0x00000100 r10 = 0xc39fd360 vpanic() at vpanic+0x164 pc = 0xc02adfb0 lr = 0xc02ade4c (vpanic) sp = 0xd69e1d48 fp = 0xd69e1d60 r4 = 0xc076e178 r5 = 0xc05d8170 r6 = 0xd69e1d6c r7 = 0xc076e0e0 r8 = 0xc078979c r9 = 0xc05bd467 r10 = 0x00000000 vpanic() at vpanic pc = 0xc02ade4c lr = 0xc033bd5c (brelse+0x6f0) sp = 0xd69e1d68 fp = 0xd69e1dd8 r4 = 0xc02ade4c r5 = 0xc541a1f8 r6 = 0xd69e1d6c r7 = 0xd75cdb88 r8 = 0xc42c73d4 r9 = 0xd75cdb88 r10 = 0xc076c184 brelse() at brelse+0x6f0 pc = 0xc033bd5c lr = 0xc033f5c0 (bufdone+0x58) sp = 0xd69e1de0 fp = 0xd69e1de8 r4 = 0xd75cdb88 r5 = 0xc42c73d4 r6 = 0xc076c140 r7 = 0xc076c184 r8 = 0xc078979c r9 = 0xc05bd467 r10 = 0x00000000 bufdone() at bufdone+0x58 pc = 0xc033f5c0 lr = 0xc023cc34 (g_io_schedule_up+0xe4) sp = 0xd69e1df0 fp = 0xd69e1e20 r4 = 0xc05bf7ad r5 = 0xc541a1f8 g_io_schedule_up() at g_io_schedule_up+0xe4 pc = 0xc023cc34 lr = 0xc023d35c (g_up_procbody+0x78) sp = 0xd69e1e28 fp = 0xd69e1e30 r4 = 0xc05bfbcf r5 = 0xc076c1ac r6 = 0xc023d2e4 r7 = 0x00000000 r8 = 0xd69e1e58 r9 = 0x00000000 r10 = 0x00000000 g_up_procbody() at g_up_procbody+0x78 pc = 0xc023d35c lr = 0xc027b144 (fork_exit+0xa0) sp = 0xd69e1e38 fp = 0xd69e1e50 r4 = 0xc39fd360 r5 = 0xc3958000 fork_exit() at fork_exit+0xa0 pc = 0xc027b144 lr = 0xc0544fc4 (swi_exit) sp = 0xd69e1e58 fp = 0x00000000 r4 = 0xc023d2e4 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r10 = 0x00000000 swi_exit() at swi_exit pc = 0xc0544fc4 lr = 0xc0544fc4 (swi_exit) sp = 0xd69e1e58 fp = 0x00000000 db> In case it's useful, here is the transcript of the recovery. It's a little odd that fsck needs to be re-run individually for da0p1 and da0p4 on the hard disk. They appear in /etc/fstab thus: /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 /dev/mmcsd0s2a / ufs rw,noatime 1 1 #md /tmp mfs rw,noatime,-s50m 0 0 #md /var/log mfs rw,noatime,-s15m 0 0 #md /var/tmp mfs rw,noatime,-s5m 0 0 /dev/da0p4 /tmp ufs rw,noatime 0 0 /dev/da0p3 /usr ufs rw,noatime,late,failok 1 2 /dev/da0p2 none swap sw 0 0 /dev/da0p1 /var ufs rw,noatime 0 0 Enter full pathname of shell or RETURN for /bin/sh: # fsck -y ** /dev/mmcsd0s2a USE JOURNAL? yes ** SU+J Recovering /dev/mmcsd0s2a ** Reading 4194304 byte journal from inode 4. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. WRITE CHANGES? yes ** 115 journal records in 5632 bytes for 65.34% utilization ** Freed 16 inodes (0 dirs) 203 blocks, and 46 frags. ***** FILE SYSTEM MARKED CLEAN ***** ** /dev/da0p3 ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=2332336 (8 should be 0) CORRECT? yes INCORRECT BLOCK COUNT I=3049740 (48 should be 0) CORRECT? yes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=2086739 OWNER=root MODE=100555 SIZE=3629 MTIME=Aug 29 18:35 2015 RECONNECT? yes UNREF FILE I=2086744 OWNER=root MODE=100555 SIZE=9508 MTIME=Aug 29 18:35 2015 RECONNECT? yes UNREF FILE I=2086858 OWNER=root MODE=100555 SIZE=12652 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=2086968 OWNER=root MODE=100555 SIZE=8148 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=2086969 OWNER=root MODE=100555 SIZE=16168 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=2175928 OWNER=root MODE=100555 SIZE=24104 MTIME=Aug 28 12:36 2015 CLEAR? yes UNREF FILE I=2254598 OWNER=root MODE=100444 SIZE=34080 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2254639 OWNER=root MODE=100444 SIZE=5256 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2254655 OWNER=root MODE=100444 SIZE=6884 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2254658 OWNER=root MODE=100444 SIZE=5520 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2254737 OWNER=root MODE=100444 SIZE=32472 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2254799 OWNER=root MODE=100444 SIZE=268356 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2254811 OWNER=root MODE=100444 SIZE=16988 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2254855 OWNER=root MODE=100444 SIZE=558440 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2254856 OWNER=root MODE=100444 SIZE=107312 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2254872 OWNER=root MODE=100444 SIZE=49404 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2254880 OWNER=root MODE=100444 SIZE=425320 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2254931 OWNER=root MODE=100444 SIZE=64756 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2255025 OWNER=root MODE=100444 SIZE=159880 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2255033 OWNER=root MODE=100444 SIZE=11340 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2255042 OWNER=root MODE=100444 SIZE=7464 MTIME=Aug 28 12:38 2015 CLEAR? yes UNREF FILE I=2255174 OWNER=root MODE=100444 SIZE=319376 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2255480 OWNER=root MODE=100444 SIZE=106344 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2255501 OWNER=root MODE=100444 SIZE=5600 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2255562 OWNER=root MODE=100444 SIZE=33624 MTIME=Aug 28 12:34 2015 CLEAR? yes UNREF FILE I=2255573 OWNER=root MODE=100444 SIZE=4568 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255581 OWNER=root MODE=100444 SIZE=6156 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255583 OWNER=root MODE=100444 SIZE=7892 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255585 OWNER=root MODE=100444 SIZE=4860 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255587 OWNER=root MODE=100444 SIZE=4816 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255589 OWNER=root MODE=100444 SIZE=4212 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255593 OWNER=root MODE=100444 SIZE=3620 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255599 OWNER=root MODE=100444 SIZE=3716 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255601 OWNER=root MODE=100444 SIZE=4200 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255603 OWNER=root MODE=100444 SIZE=3912 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255609 OWNER=root MODE=100444 SIZE=11108 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2255612 OWNER=root MODE=100444 SIZE=47424 MTIME=Aug 28 12:35 2015 CLEAR? yes UNREF FILE I=2328435 OWNER=root MODE=100444 SIZE=0 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=2328436 OWNER=root MODE=100444 SIZE=0 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=2328445 OWNER=root MODE=100444 SIZE=0 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=3049744 OWNER=root MODE=100555 SIZE=0 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=3049758 OWNER=root MODE=100555 SIZE=0 MTIME=Aug 29 18:36 2015 RECONNECT? yes UNREF FILE I=3049759 OWNER=root MODE=100555 SIZE=0 MTIME=Aug 29 18:36 2015 RECONNECT? yes ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 871400 files, 3358352 used, 4002263 free (37559 frags, 495588 blocks, 0.5% fragmentation) ***** FILE SYSTEM STILL DIRTY ***** ***** FILE SYSTEM WAS MODIFIED ***** ***** PLEASE RERUN FSCK ***** # random: unblocking device. # fsck -y ** /dev/mmcsd0s2a USE JOURNAL? yes ** SU+J Recovering /dev/mmcsd0s2a Journal timestamp does not match fs mount time ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 116380 files, 596620 used, 1161195 free (33275 frags, 140990 blocks, 1.9% fragmentation) ***** FILE SYSTEM IS CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** ** /dev/da0p3 ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 871400 files, 3358352 used, 4002263 free (37559 frags, 495588 blocks, 0.5% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** # boot -sh: boot: not found # exit Setting hostuuid: d8fda880-104e-11e5-b1cd-b827eb18f842. Setting hostid: 0x908fd2cc. Fast boot: skipping disk checks. Mounting local file systems:mount: /dev/da0p4: R/W mount of /tmp denied. Filesystem is not clean - run fsck. Forced mount will invalidate journal contents: Operation not permitted mount: /dev/da0p1: R/W mount of /var denied. Filesystem is not clean - run fsck. Forced mount will invalidate journal contents: Operation not permitted . Mounting /etc/fstab filesystems failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Aug 29 18:24:33 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: # fsck -y da0p1 ** /dev/da0p1 USE JOURNAL? yes ** SU+J Recovering /dev/da0p1 ** Reading 33554432 byte journal from inode 4. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. WRITE CHANGES? yes ** 11 journal records in 1024 bytes for 34.38% utilization ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. ***** FILE SYSTEM MARKED CLEAN ***** # fsck -y da0p4 ** /dev/da0p4 USE JOURNAL? yes ** SU+J Recovering /dev/da0p4 ** Reading 10584064 byte journal from inode 4. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. WRITE CHANGES? yes ** 4 journal records in 1536 bytes for 8.33% utilization ** Freed 4 inodes (0 dirs) 0 blocks, and 5 frags. ***** FILE SYSTEM MARKED CLEAN ***** # exit Setting hostuuid: d8fda880-104e-11e5-b1cd-b827eb18f842. Setting hostid: 0x908fd2cc. Fast boot: skipping disk checks. Mounting local file systems:. Setting hostname: www.zefox.org. Feeding entropy:. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 ue0: flags=8843 metric 0 mtu 1500 options=80001 ether b8:27:eb:18:f8:42 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 ELF ldconfig path: /lib /usr/lib /usr/lib/compat Starting devd. ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 Starting ums0 moused. add net default: gateway 192.168.1.254 add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. Setting date via ntp. 29 Aug 19:07:25 ntpdate[452]: step time server 131.107.13.100 offset 2418.723369 sec No core dumps found. Starting casperd. Clearing /tmp (X related). Updating motd:. Mounting late file systems:. Starting powerd. Configuring vt: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting sendmail. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Sat Aug 29 19:07:31 PDT 2015 FreeBSD/arm (www.zefox.org) (ttyu0) login: I'll try to complete the build and proceed as before. If there's a way to get more/better debugging output please give me a hint. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sun Aug 30 03:56:35 2015 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 7339A9C4DDE for ; Sun, 30 Aug 2015 03:56:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (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 28823DCE for ; Sun, 30 Aug 2015 03:56:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgeb6 with SMTP id b6so50195560qge.3 for ; Sat, 29 Aug 2015 20:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Lh0szs45NMHWpktO3uVChKKcUrmX3rfVDCWtU25lU7s=; b=Gu/WP2cmhrZDtzYjYaj4XkoIpPBZ6sgjA7fWqn3O6jhhBqH7K/AJiX/FKMNukobqdO 5G5901ptIz6WMMDPL6fMs+GWlllKaI1RUVCdbmJyhPvC+lM6InjnZlMIzHsLCXIYbdF4 VoczJQOeHUzvcYlSmocqk3Ruyjuy4WqMRxdUqM2aw+Z+FLSNjANFeCf/YINKzWkApPgY AYpeCQz5k49zW6t/YM/MkXRV6RnSWyvrme3/JcvDMPwixNqwFprACP7r9qgzUmIG0DBU bU52jLP3whUGf5RsZeXy1Y5U+NdFLbmARXIyh9uVM/urN6F4xtqXd2p/zLb0Lge931Q8 iimA== X-Gm-Message-State: ALoCoQmiuO//sfl2e54/ap4RJSbhSekL33qIX65yAbjkT4nMEyycBX62i9mISMwxSNFS/YPXR6Nm MIME-Version: 1.0 X-Received: by 10.140.233.14 with SMTP id e14mr30715809qhc.20.1440906987521; Sat, 29 Aug 2015 20:56:27 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.164 with HTTP; Sat, 29 Aug 2015 20:56:27 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20150830025243.GL53136@www.zefox.net> References: <20150830025243.GL53136@www.zefox.net> Date: Sat, 29 Aug 2015 21:56:27 -0600 X-Google-Sender-Auth: 8AiY71u6DEf2HJ4HMrvMwJ6v86E Message-ID: Subject: Re: Another RPI2 installworld crash with backtrace and logfile From: Warner Losh To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 03:56:35 -0000 Conversations on IRC suggest that the interrupt controller make things on RPI2 might not be completely MP safe. Perhaps this is causing issue. Too many (or few) interrupts may mess up the state machine sdhci relies upon. Or perhaps the WRITE_MULTI is to blame. CMD25 is WRITE_MULTI. This has caused issues sometimes in the past. Perhaps turning it off may be more stable. diff -r d8e9f4eb0b5b sys/dev/sdhci/sdhci.c --- a/sys/dev/sdhci/sdhci.c +++ b/sys/dev/sdhci/sdhci.c @@ -1396,7 +1396,8 @@ sdhci_generic_read_ivar(device_t bus, de *result = slot->host.ios.timing; break; case MMCBR_IVAR_MAX_DATA: - *result = 65535; +// *result = 65535; + *result = 1; break; } return (0); would do the trick if you want to test it out. This is, at best, an ugly hack. It may slow things down enough so that it doesn't matter, or it may avoid some of the problems with streaming that happens with MULTI_WRITE. Warner On Sat, Aug 29, 2015 at 8:52 PM, bob prohaska wrote: > > Here's another RPI2 crash during installworld. Uname -a reports > FreeBSD www.zefox.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287241M: Fri > Aug 28 12:30:06 PDT 2015 bob@www.zefox.org:/usr/obj/usr/src/sys/RPI2 > arm > This time world and kernel were in sync. Still no output visible from > > sysctl hw.mmc.debug=1 > sysctl hw.sdhci.debug=1 > > The smsc0 warnings started yesterday while > playing with /usr/ports/sysutils/stress. The machine sent a couple of > emails complaining about > > unlink: saved-entropy.8: No such file or directory > mv: saved-entropy.5: No such file or directory > mv: saved-entropy.4: No such file or directory > mv: saved-entropy.2: No such file or directory > > while stress was running, but nothing else happened. > > > Since it wouldn't crash, svnlite update /usr/src was run > and the build commenced. It very slowly worked through buildworld, > buildkernel and crashed > during installworldworld, installworld's last words were: > > > install -o root -g wheel -m 444 verify_krb5_conf.8.gz /usr/share/man/man8 > ===> kerberos5/usr.sbin (install) > --- _sub.realinstall --- > ===> kerberos5/usr.sbin/iprop-log (install) > --- _proginstall --- > --- _maninstall --- > --- _proginstall --- > install -s -o root -g wheel -m 555 iprop-log /usr/sbin/iprop-log > --- _maninstall --- > install -o root -g wheel -m 444 iprop-log.8.gz /usr/share/man/man8 > > The console output and backtrace follow. > smsc0: warning: MII is busy > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > sdhci_bcm0-slot0: Controller timeout > sdhci_bcm0-slot0: ============== REGISTER DUMP ============== > sdhci_bcm0-slot0: Sys addr: 0x02012c00 | Version: 0x00009902 > sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000099 > sdhci_bcm0-slot0: Argument: 0x00173000 | 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: 0x01ff00fb | Sig enab: 0x01ff00fb > sdhci_bcm0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000001 > sdhci_bcm0-slot0: Caps: 0x00000000 | Max curr: 0x00000001 > sdhci_bcm0-slot0: =========================================== > mmc0: CMD25 RESULT: 1 > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():mmcsd0s2a[WRITE(offset=725549056, length=131072)]error = 5 > mmc0: CMD25 RESULT: 1 > mmcsd0: Error indicated: 1 Timeout > mmc0: CMD25 RESULT: 1 > mmcsd0: Error indicated: 1 Timeout > mmc0: CMD25 RESULT: 1 > mmcsd0: Error indicated: 1 Timeout > mmc0: CMD25 RESULT: 1 > mmcsd0: Error indicated: 1 Timeout > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD25 RESULT: 1 > mmc0: CMD24 RESULT: 1 > mmc0: CMD24 RESULT: 1 > mmc0: CMD25 RESULT: 1 > g_vfs_done():mmcsd0s2a[WRITE(offset=725680128, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=725811200, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=725942272, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726073344, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726204416, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726335488, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726466560, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726597632, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726728704, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726859776, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=726990848, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=727121920, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=727252992, length=131072)]error = 5 > g_vfs_done():mmcsd0s2a[WRITE(offset=20925952, length=2048)]error = 5 > panic: brelse: inappropriate B_PAGING or B_CLUSTER bp 0xd75cdb88 > cpuid = 0 > KDB: enter: panic > [ thread pid 12 tid 100014 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 12 tid 100014 td 0xc39fd360 > db_trace_self() at db_trace_self > pc = 0xc05439ac lr = 0xc0141038 (db_stack_trace+0x108) > sp = 0xd69e19d8 fp = 0xd69e19f0 > r10 = 0xc07885f8 > db_stack_trace() at db_stack_trace+0x108 > pc = 0xc0141038 lr = 0xc0140a84 (db_command+0x388) > sp = 0xd69e19f8 fp = 0xd69e1a98 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r10 = 0xc07885f8 > db_command() at db_command+0x388 > pc = 0xc0140a84 lr = 0xc01406ec (db_command_loop+0x74) > sp = 0xd69e1aa0 fp = 0xd69e1ab0 > r4 = 0xc05aa958 r5 = 0xc05cba03 > r6 = 0xc07885e4 r7 = 0xd69e1c80 > r8 = 0xc077d620 r9 = 0xc0693ea4 > r10 = 0xc077d624 > db_command_loop() at db_command_loop+0x74 > pc = 0xc01406ec lr = 0xc014321c (db_trap+0x108) > sp = 0xd69e1ab8 fp = 0xd69e1bd0 > r4 = 0x00000000 r5 = 0xc07885f0 > r6 = 0xc077d648 r10 = 0xc077d624 > db_trap() at db_trap+0x108 > pc = 0xc014321c lr = 0xc02eb6ec (kdb_trap+0x184) > sp = 0xd69e1bd8 fp = 0xd69e1c00 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc077d648 r7 = 0xd69e1c80 > kdb_trap() at kdb_trap+0x184 > pc = 0xc02eb6ec lr = 0xc055ba9c (undefinedinstruction+0x344) > sp = 0xd69e1c08 fp = 0xd69e1c78 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc055b6a8 r7 = 0xe7ffffff > r8 = 0xc39fd360 r9 = 0xc02eae44 > r10 = 0xd69e1c80 > undefinedinstruction() at undefinedinstruction+0x344 > pc = 0xc055ba9c lr = 0xc0545034 (exception_exit) > sp = 0xd69e1c80 fp = 0xd69e1d18 > r4 = 0xc05cba58 r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xd69e1d6c r9 = 0xc078a3a0 > r10 = 0xc39fd360 > exception_exit() at exception_exit > pc = 0xc0545034 lr = 0xc02eae34 (kdb_enter+0x48) > sp = 0xd69e1d10 fp = 0xd69e1d18 > r0 = 0xc077d634 r1 = 0x00000000 > r2 = 0xd69e1c44 r3 = 0xc05cfb1d > r4 = 0xc05cba58 r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xd69e1d6c r9 = 0xc078a3a0 > r10 = 0xc39fd360 r12 = 0xc06aec58 > $a.8() at $a.8 > pc = 0xc02eae48 lr = 0xc02adfb0 (vpanic+0x164) > sp = 0xd69e1d20 fp = 0xd69e1d40 > r4 = 0x00000100 r10 = 0xc39fd360 > vpanic() at vpanic+0x164 > pc = 0xc02adfb0 lr = 0xc02ade4c (vpanic) > sp = 0xd69e1d48 fp = 0xd69e1d60 > r4 = 0xc076e178 r5 = 0xc05d8170 > r6 = 0xd69e1d6c r7 = 0xc076e0e0 > r8 = 0xc078979c r9 = 0xc05bd467 > r10 = 0x00000000 > vpanic() at vpanic > pc = 0xc02ade4c lr = 0xc033bd5c (brelse+0x6f0) > sp = 0xd69e1d68 fp = 0xd69e1dd8 > r4 = 0xc02ade4c r5 = 0xc541a1f8 > r6 = 0xd69e1d6c r7 = 0xd75cdb88 > r8 = 0xc42c73d4 r9 = 0xd75cdb88 > r10 = 0xc076c184 > brelse() at brelse+0x6f0 > pc = 0xc033bd5c lr = 0xc033f5c0 (bufdone+0x58) > sp = 0xd69e1de0 fp = 0xd69e1de8 > r4 = 0xd75cdb88 r5 = 0xc42c73d4 > r6 = 0xc076c140 r7 = 0xc076c184 > r8 = 0xc078979c r9 = 0xc05bd467 > r10 = 0x00000000 > bufdone() at bufdone+0x58 > pc = 0xc033f5c0 lr = 0xc023cc34 (g_io_schedule_up+0xe4) > sp = 0xd69e1df0 fp = 0xd69e1e20 > r4 = 0xc05bf7ad r5 = 0xc541a1f8 > g_io_schedule_up() at g_io_schedule_up+0xe4 > pc = 0xc023cc34 lr = 0xc023d35c (g_up_procbody+0x78) > sp = 0xd69e1e28 fp = 0xd69e1e30 > r4 = 0xc05bfbcf r5 = 0xc076c1ac > r6 = 0xc023d2e4 r7 = 0x00000000 > r8 = 0xd69e1e58 r9 = 0x00000000 > r10 = 0x00000000 > g_up_procbody() at g_up_procbody+0x78 > pc = 0xc023d35c lr = 0xc027b144 (fork_exit+0xa0) > sp = 0xd69e1e38 fp = 0xd69e1e50 > r4 = 0xc39fd360 r5 = 0xc3958000 > fork_exit() at fork_exit+0xa0 > pc = 0xc027b144 lr = 0xc0544fc4 (swi_exit) > sp = 0xd69e1e58 fp = 0x00000000 > r4 = 0xc023d2e4 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0x00000000 r10 = 0x00000000 > swi_exit() at swi_exit > pc = 0xc0544fc4 lr = 0xc0544fc4 (swi_exit) > sp = 0xd69e1e58 fp = 0x00000000 > db> > > > In case it's useful, here is the transcript of the recovery. It's a little > odd that fsck > needs to be re-run individually for da0p1 and da0p4 on the hard disk. They > appear in > /etc/fstab thus: > > /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 0 > /dev/mmcsd0s2a / ufs rw,noatime 1 1 > #md /tmp mfs rw,noatime,-s50m 0 0 > #md /var/log mfs rw,noatime,-s15m 0 0 > #md /var/tmp mfs rw,noatime,-s5m 0 0 > /dev/da0p4 /tmp ufs rw,noatime 0 0 > /dev/da0p3 /usr ufs rw,noatime,late,failok 1 2 > /dev/da0p2 none swap sw 0 0 > /dev/da0p1 /var ufs rw,noatime 0 0 > > > Enter full pathname of shell or RETURN for /bin/sh: > # fsck -y > ** /dev/mmcsd0s2a > > USE JOURNAL? yes > > ** SU+J Recovering /dev/mmcsd0s2a > ** Reading 4194304 byte journal from inode 4. > > RECOVER? yes > > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > > WRITE CHANGES? yes > > ** 115 journal records in 5632 bytes for 65.34% utilization > ** Freed 16 inodes (0 dirs) 203 blocks, and 46 frags. > > ***** FILE SYSTEM MARKED CLEAN ***** > ** /dev/da0p3 > ** Last Mounted on /usr > ** Phase 1 - Check Blocks and Sizes > INCORRECT BLOCK COUNT I=2332336 (8 should be 0) > CORRECT? yes > > INCORRECT BLOCK COUNT I=3049740 (48 should be 0) > CORRECT? yes > > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > UNREF FILE I=2086739 OWNER=root MODE=100555 > SIZE=3629 MTIME=Aug 29 18:35 2015 > RECONNECT? yes > > UNREF FILE I=2086744 OWNER=root MODE=100555 > SIZE=9508 MTIME=Aug 29 18:35 2015 > RECONNECT? yes > > UNREF FILE I=2086858 OWNER=root MODE=100555 > SIZE=12652 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=2086968 OWNER=root MODE=100555 > SIZE=8148 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=2086969 OWNER=root MODE=100555 > SIZE=16168 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=2175928 OWNER=root MODE=100555 > SIZE=24104 MTIME=Aug 28 12:36 2015 > CLEAR? yes > > UNREF FILE I=2254598 OWNER=root MODE=100444 > SIZE=34080 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2254639 OWNER=root MODE=100444 > SIZE=5256 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2254655 OWNER=root MODE=100444 > SIZE=6884 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2254658 OWNER=root MODE=100444 > SIZE=5520 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2254737 OWNER=root MODE=100444 > SIZE=32472 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2254799 OWNER=root MODE=100444 > SIZE=268356 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2254811 OWNER=root MODE=100444 > SIZE=16988 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2254855 OWNER=root MODE=100444 > SIZE=558440 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2254856 OWNER=root MODE=100444 > SIZE=107312 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2254872 OWNER=root MODE=100444 > SIZE=49404 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2254880 OWNER=root MODE=100444 > SIZE=425320 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2254931 OWNER=root MODE=100444 > SIZE=64756 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2255025 OWNER=root MODE=100444 > SIZE=159880 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2255033 OWNER=root MODE=100444 > SIZE=11340 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2255042 OWNER=root MODE=100444 > SIZE=7464 MTIME=Aug 28 12:38 2015 > CLEAR? yes > > UNREF FILE I=2255174 OWNER=root MODE=100444 > SIZE=319376 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2255480 OWNER=root MODE=100444 > SIZE=106344 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2255501 OWNER=root MODE=100444 > SIZE=5600 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2255562 OWNER=root MODE=100444 > SIZE=33624 MTIME=Aug 28 12:34 2015 > CLEAR? yes > > UNREF FILE I=2255573 OWNER=root MODE=100444 > SIZE=4568 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255581 OWNER=root MODE=100444 > SIZE=6156 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255583 OWNER=root MODE=100444 > SIZE=7892 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255585 OWNER=root MODE=100444 > SIZE=4860 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255587 OWNER=root MODE=100444 > SIZE=4816 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255589 OWNER=root MODE=100444 > SIZE=4212 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255593 OWNER=root MODE=100444 > SIZE=3620 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255599 OWNER=root MODE=100444 > SIZE=3716 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255601 OWNER=root MODE=100444 > SIZE=4200 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255603 OWNER=root MODE=100444 > SIZE=3912 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255609 OWNER=root MODE=100444 > SIZE=11108 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2255612 OWNER=root MODE=100444 > SIZE=47424 MTIME=Aug 28 12:35 2015 > CLEAR? yes > > UNREF FILE I=2328435 OWNER=root MODE=100444 > SIZE=0 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=2328436 OWNER=root MODE=100444 > SIZE=0 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=2328445 OWNER=root MODE=100444 > SIZE=0 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=3049744 OWNER=root MODE=100555 > SIZE=0 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=3049758 OWNER=root MODE=100555 > SIZE=0 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > UNREF FILE I=3049759 OWNER=root MODE=100555 > SIZE=0 MTIME=Aug 29 18:36 2015 > RECONNECT? yes > > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? yes > > SUMMARY INFORMATION BAD > SALVAGE? yes > > BLK(S) MISSING IN BIT MAPS > SALVAGE? yes > > 871400 files, 3358352 used, 4002263 free (37559 frags, 495588 blocks, 0.5% > fragmentation) > > ***** FILE SYSTEM STILL DIRTY ***** > > ***** FILE SYSTEM WAS MODIFIED ***** > > ***** PLEASE RERUN FSCK ***** > # random: unblocking device. > > # fsck -y > ** /dev/mmcsd0s2a > > USE JOURNAL? yes > > ** SU+J Recovering /dev/mmcsd0s2a > Journal timestamp does not match fs mount time > ** Skipping journal, falling through to full fsck > > ** Last Mounted on / > ** Root file system > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? yes > > SUMMARY INFORMATION BAD > SALVAGE? yes > > BLK(S) MISSING IN BIT MAPS > SALVAGE? yes > > 116380 files, 596620 used, 1161195 free (33275 frags, 140990 blocks, 1.9% > fragmentation) > > ***** FILE SYSTEM IS CLEAN ***** > > ***** FILE SYSTEM WAS MODIFIED ***** > ** /dev/da0p3 > ** Last Mounted on /usr > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 871400 files, 3358352 used, 4002263 free (37559 frags, 495588 blocks, 0.5% > fragmentation) > > ***** FILE SYSTEM MARKED CLEAN ***** > # boot > -sh: boot: not found > # exit > Setting hostuuid: d8fda880-104e-11e5-b1cd-b827eb18f842. > Setting hostid: 0x908fd2cc. > Fast boot: skipping disk checks. > Mounting local file systems:mount: /dev/da0p4: R/W mount of /tmp denied. > Filesystem is not clean - run fsck. Forced mount will invalidate journal > contents: Operation not permitted > mount: /dev/da0p1: R/W mount of /var denied. Filesystem is not clean - run > fsck. Forced mount will invalidate journal contents: Operation not permitted > . > Mounting /etc/fstab filesystems failed, startup aborted > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > Aug 29 18:24:33 init: /bin/sh on /etc/rc terminated abnormally, going to > single user mode > Enter full pathname of shell or RETURN for /bin/sh: > # fsck -y da0p1 > ** /dev/da0p1 > > USE JOURNAL? yes > > ** SU+J Recovering /dev/da0p1 > ** Reading 33554432 byte journal from inode 4. > > RECOVER? yes > > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > > WRITE CHANGES? yes > > ** 11 journal records in 1024 bytes for 34.38% utilization > ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. > > ***** FILE SYSTEM MARKED CLEAN ***** > > > # fsck -y da0p4 > ** /dev/da0p4 > > USE JOURNAL? yes > > ** SU+J Recovering /dev/da0p4 > ** Reading 10584064 byte journal from inode 4. > > RECOVER? yes > > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > > WRITE CHANGES? yes > > ** 4 journal records in 1536 bytes for 8.33% utilization > ** Freed 4 inodes (0 dirs) 0 blocks, and 5 frags. > > ***** FILE SYSTEM MARKED CLEAN ***** > # exit > Setting hostuuid: d8fda880-104e-11e5-b1cd-b827eb18f842. > Setting hostid: 0x908fd2cc. > Fast boot: skipping disk checks. > Mounting local file systems:. > Setting hostname: www.zefox.org. > Feeding entropy:. > smsc0: chip 0xec00, rev. 0002 > ue0: link state changed to DOWN > ue0: link state changed to UP > Starting Network: lo0 ue0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=21 > ue0: flags=8843 metric 0 mtu 1500 > options=80001 > ether b8:27:eb:18:f8:42 > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > Starting devd. > ums0: on > usbus0 > ums0: 3 buttons and [XYZ] coordinates ID=0 > Starting ums0 moused. > add net default: gateway 192.168.1.254 > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Creating and/or trimming log files. > Starting syslogd. > Setting date via ntp. > 29 Aug 19:07:25 ntpdate[452]: step time server 131.107.13.100 offset > 2418.723369 sec > No core dumps found. > Starting casperd. > Clearing /tmp (X related). > Updating motd:. > Mounting late file systems:. > Starting powerd. > Configuring vt: blanktime. > Performing sanity check on sshd configuration. > Starting sshd. > Starting sendmail. > Starting sendmail_msp_queue. > Starting cron. > Starting background file system checks in 60 seconds. > > Sat Aug 29 19:07:31 PDT 2015 > > FreeBSD/arm (www.zefox.org) (ttyu0) > > login: > > > I'll try to complete the build and proceed as before. If there's a way to > get > more/better debugging output please give me a hint. > > Thanks for reading, > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sun Aug 30 06:21:03 2015 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 B443F9C09C5 for ; Sun, 30 Aug 2015 06:21:03 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (canonware.com [204.109.63.53]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A3C71B4E; Sun, 30 Aug 2015 06:21:03 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from [127.0.0.1] (lyk.canonware.com [204.109.63.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 762912878D; Sat, 29 Aug 2015 23:14:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: arm64: userspace broken with jemalloc 4.0.0 From: Jason Evans In-Reply-To: <55E22CC0.9000306@citrix.com> Date: Sat, 29 Aug 2015 23:14:23 -0700 Cc: jasone@freebsd.org, andrew@fubar.geek.nz, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> References: <55E22CC0.9000306@citrix.com> To: Julien Grall X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 06:21:03 -0000 On Aug 29, 2015, at 3:05 PM, Julien Grall = wrote: > I've built the latest freebsd master (r287263) for arm64 today. While > trying to use the userspace I hit some ASSERT in jemalloc: >=20 > # ls > : = /usr/src/freebsd/lib/libc/../../contrib/jemalloc/include/jemalloc/internal= /arena.h:571: Failed assertion: "pageind >=3D map_bias" > pid 21 (ls), uid 0: exited on signal 6 > Abort trap >=20 > It's happening every time with the command "ls". >=20 > I tried to use the previous version of jemalloc (i.e reverting > all the patches up to "Update jemalloc to version 4.0.0" included) > and everything is working. >=20 > Note that I'm using Freebsd as a Xen ARM guest although the only > difference is the version of jemalloc (4.0.0 vs 3.6.0). >=20 > Does anyone using arm64 have seen a similar ASSERT? >=20 > BTW, is there any way to rebuild only the libc rather than doing > make buildworld everytime I modified the jemalloc code? What is the page size on arm64? If it's greater than 8 KiB, I know what = the problem is and have a patch that I've already tested and can = integrate tomorrow when I'm awake enough not fat-finger it. = https://github.com/jemalloc/jemalloc/commit/5ef33a9f2b9f4fb56553529f7b31f4= f5f57ce014 Thanks, Jason From owner-freebsd-arm@freebsd.org Sun Aug 30 12:51:29 2015 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 3C5F09C66FE for ; Sun, 30 Aug 2015 12:51:29 +0000 (UTC) (envelope-from prvs=67726ce1b=julien.grall@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF0E0381; Sun, 30 Aug 2015 12:51:28 +0000 (UTC) (envelope-from prvs=67726ce1b=julien.grall@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,434,1437436800"; d="scan'208";a="295908933" Message-ID: <55E2FC47.5070801@citrix.com> Date: Sun, 30 Aug 2015 13:51:19 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jason Evans CC: freebsd-arm , Subject: Re: arm64: userspace broken with jemalloc 4.0.0 References: <55E22CC0.9000306@citrix.com> <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> In-Reply-To: <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 12:51:29 -0000 Hi Jason, On 30/08/2015 07:14, Jason Evans wrote: > On Aug 29, 2015, at 3:05 PM, Julien Grall wrote: >> I've built the latest freebsd master (r287263) for arm64 today. While >> trying to use the userspace I hit some ASSERT in jemalloc: >> >> # ls >> : /usr/src/freebsd/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:571: Failed assertion: "pageind >= map_bias" >> pid 21 (ls), uid 0: exited on signal 6 >> Abort trap >> >> It's happening every time with the command "ls". >> >> I tried to use the previous version of jemalloc (i.e reverting >> all the patches up to "Update jemalloc to version 4.0.0" included) >> and everything is working. >> >> Note that I'm using Freebsd as a Xen ARM guest although the only >> difference is the version of jemalloc (4.0.0 vs 3.6.0). >> >> Does anyone using arm64 have seen a similar ASSERT? >> >> BTW, is there any way to rebuild only the libc rather than doing >> make buildworld everytime I modified the jemalloc code? > > What is the page size on arm64? The page size is 4KB. I could give a try just in case when you have integrated the patch. Regards, -- Julien Grall From owner-freebsd-arm@freebsd.org Sun Aug 30 22:21:51 2015 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 2080D9C67DC for ; Sun, 30 Aug 2015 22:21:51 +0000 (UTC) (envelope-from prvs=67726ce1b=julien.grall@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86B28F7C; Sun, 30 Aug 2015 22:21:50 +0000 (UTC) (envelope-from prvs=67726ce1b=julien.grall@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,436,1437436800"; d="scan'208";a="299385018" Subject: Re: arm64: userspace broken with jemalloc 4.0.0 To: Jason Evans References: <55E22CC0.9000306@citrix.com> <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> <55E2FC47.5070801@citrix.com> CC: freebsd-arm , , From: Julien Grall Message-ID: <55E381F5.1030107@citrix.com> Date: Sun, 30 Aug 2015 23:21:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E2FC47.5070801@citrix.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 22:21:51 -0000 On 30/08/2015 13:51, Julien Grall wrote: > Hi Jason, > > On 30/08/2015 07:14, Jason Evans wrote: >> On Aug 29, 2015, at 3:05 PM, Julien Grall >> wrote: >>> I've built the latest freebsd master (r287263) for arm64 today. While >>> trying to use the userspace I hit some ASSERT in jemalloc: >>> >>> # ls >>> : >>> /usr/src/freebsd/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:571: >>> Failed assertion: "pageind >= map_bias" >>> pid 21 (ls), uid 0: exited on signal 6 >>> Abort trap >>> >>> It's happening every time with the command "ls". >>> >>> I tried to use the previous version of jemalloc (i.e reverting >>> all the patches up to "Update jemalloc to version 4.0.0" included) >>> and everything is working. >>> >>> Note that I'm using Freebsd as a Xen ARM guest although the only >>> difference is the version of jemalloc (4.0.0 vs 3.6.0). >>> >>> Does anyone using arm64 have seen a similar ASSERT? >>> >>> BTW, is there any way to rebuild only the libc rather than doing >>> make buildworld everytime I modified the jemalloc code? >> >> What is the page size on arm64? > > The page size is 4KB. I could give a try just in case when you have > integrated the patch. So I figured out the problem today. ls is linked to 2 libraries using local thread storage: libxo and libc. Somehow the 2 libraries are using the same base pointer for the storage. When libxo will try to realloc a pointer living in the thread storage, jemalloc will throw an exception (the ASSERT mentioned earlier) because the pointer is invalid. The pointer was expected to be NULL but it has been overwritten by jemalloc earlier. So I don't think this is because of jemalloc and going back to an older version appears to hide the problem. I still need to figure out why jemalloc and libxo are sharing the same base pointer for the thread local storage. I'm not sure where I should look. Regards, -- Julien Grall From owner-freebsd-arm@freebsd.org Mon Aug 31 20:29:57 2015 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 500839C7340 for ; Mon, 31 Aug 2015 20:29:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB2A123B; Mon, 31 Aug 2015 20:29:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by ioeu67 with SMTP id u67so29928432ioe.1; Mon, 31 Aug 2015 13:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=9s/n6uqOXmYbBMW/FdWr9kOIyzvqDEcCksufwhVla50=; b=Ua+b3naG4U6cGmrY8LguNkskOu2RFuO6tb6vLUIuGZF3FLtx04wpbDJqOubAoxTDcP DKej0M21oFjRd2A6/kiavz/bsHxivMM2F0Os8FM4+HJVoQ8Fe0gTi7UT3LfO8MEsGN1C 2Sl2yDp4U/iunkAP2UtQCZOYODOeG4Q8pmK1If7QXEc2oQK6/w/JHaUAl/8i+PM9f5Bi vlAOnVZGkR6g2/XRfBcNfLtes38ZZQyeyXIZkn7FRcavAlvJAr2+1qNCebW2rPXloe3r RP0YhcFYvFVOnkP6XB3IXIzcaOhFfodjURrCzTJmn1up3j1PuzWG6R9kt3YtSwcSTp9y kp6g== X-Received: by 10.107.165.138 with SMTP id o132mr5438543ioe.29.1441052996448; Mon, 31 Aug 2015 13:29:56 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.166.17 with HTTP; Mon, 31 Aug 2015 13:29:36 -0700 (PDT) In-Reply-To: <55E381F5.1030107@citrix.com> References: <55E22CC0.9000306@citrix.com> <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> <55E2FC47.5070801@citrix.com> <55E381F5.1030107@citrix.com> From: Ed Maste Date: Mon, 31 Aug 2015 16:29:36 -0400 X-Google-Sender-Auth: EJ59hXf2u8-RqDe58PFBjlOQ4sE Message-ID: Subject: Re: arm64: userspace broken with jemalloc 4.0.0 To: Julien Grall Cc: freebsd-arm , Andrew Turner Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 20:29:57 -0000 On 30 August 2015 at 18:21, Julien Grall wrote: > > > So I figured out the problem today. ls is linked to 2 libraries using local > thread storage: libxo and libc. Somehow the 2 libraries are using the same > base pointer for the storage. > > When libxo will try to realloc a pointer living in the thread storage, > jemalloc will throw an exception (the ASSERT mentioned earlier) because the > pointer is invalid. The pointer was expected to be NULL but it has been > overwritten by jemalloc earlier. Would you submit a PR for this to keep track of it while the investigation is ongoing? From owner-freebsd-arm@freebsd.org Mon Aug 31 21:06:51 2015 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 2E79A9C6231 for ; Mon, 31 Aug 2015 21:06:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id EC0BE991; Mon, 31 Aug 2015 21:06:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from bender.Home (bcdc6507.skybroadband.com [188.220.101.7]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 2F3D4D7907; Mon, 31 Aug 2015 21:06:49 +0000 (UTC) Date: Mon, 31 Aug 2015 22:06:47 +0100 From: Andrew Turner To: Julien Grall Cc: , freebsd-arm Subject: Re: arm64: userspace broken with jemalloc 4.0.0 Message-ID: <20150831220647.67a4646d@bender.Home> In-Reply-To: <55E22CC0.9000306@citrix.com> References: <55E22CC0.9000306@citrix.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/pkK1f/3q6zRGlsC+dYMyV/F" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 21:06:51 -0000 --MP_/pkK1f/3q6zRGlsC+dYMyV/F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 29 Aug 2015 23:05:52 +0100 Julien Grall wrote: > Hi, > > I've built the latest freebsd master (r287263) for arm64 today. While > trying to use the userspace I hit some ASSERT in jemalloc: > > # ls > : /usr/src/freebsd/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:571: > Failed assertion: "pageind >= map_bias" pid 21 (ls), uid 0: exited on > signal 6 Abort trap > > It's happening every time with the command "ls". > > I tried to use the previous version of jemalloc (i.e reverting > all the patches up to "Update jemalloc to version 4.0.0" included) > and everything is working. > > Note that I'm using Freebsd as a Xen ARM guest although the only > difference is the version of jemalloc (4.0.0 vs 3.6.0). > > Does anyone using arm64 have seen a similar ASSERT? > > BTW, is there any way to rebuild only the libc rather than doing > make buildworld everytime I modified the jemalloc code? > > Regards, > This is a bug in the runtime linkers handling of tls. The attached patch allows me to get to multiuser mode without anything hitting the above assert. Andrew -- ABT Systems Ltd Unit 11, Hove Business Centre, Fonthill Road, Hove, BN3 6HA Registered in England and Wales, No. 9285513 --MP_/pkK1f/3q6zRGlsC+dYMyV/F Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0001-WIP-fix-for-AArch64-TLS.patch >From 81e6769f103e0e40347469ae6940ca461295d607 Mon Sep 17 00:00:00 2001 From: Andrew Turner Date: Mon, 31 Aug 2015 21:59:32 +0100 Subject: [PATCH] WIP fix for AArch64 TLS --- libexec/rtld-elf/aarch64/rtld_machdep.h | 4 ++-- libexec/rtld-elf/rtld.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/libexec/rtld-elf/aarch64/rtld_machdep.h b/libexec/rtld-elf/aarch64/rtld_machdep.h index 1cb2029..a7b1900 100644 --- a/libexec/rtld-elf/aarch64/rtld_machdep.h +++ b/libexec/rtld-elf/aarch64/rtld_machdep.h @@ -64,9 +64,9 @@ Elf_Addr reloc_jmpslot(Elf_Addr *where, Elf_Addr target, #define round(size, align) \ (((size) + (align) - 1) & ~((align) - 1)) #define calculate_first_tls_offset(size, align) \ - round(size, align) + round(16, align) #define calculate_tls_offset(prev_offset, prev_size, size, align) \ - round((prev_offset) + (size), align) + round((prev_offset) + prev_size, align) #define calculate_tls_end(off, size) ((off) + (size)) #define TLS_TCB_SIZE 8 diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 1d91460..eecfb0f 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -4611,7 +4611,7 @@ allocate_tls_offset(Obj_Entry *obj) return true; } - if (obj->tlsindex == 1) + if (tls_last_offset == 0) off = calculate_first_tls_offset(obj->tlssize, obj->tlsalign); else off = calculate_tls_offset(tls_last_offset, tls_last_size, -- 2.4.6 --MP_/pkK1f/3q6zRGlsC+dYMyV/F-- From owner-freebsd-arm@freebsd.org Mon Aug 31 22:42:20 2015 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 D26049C722A for ; Mon, 31 Aug 2015 22:42:20 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63B571D80 for ; Mon, 31 Aug 2015 22:42:19 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id t7VMgGbF074906; Tue, 1 Sep 2015 00:42:16 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Svatopluk Kraus CC: Hans Petter Selasky , "freebsd-arm@freebsd.org" Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 01 Sep 2015 00:42:15 +0200 (CEST) Message-ID: <46d8b55830c.48a059ec@mail.schwarzes.net> In-Reply-To: References: <55A7D8CE.4020809@selasky.org> <55B23276.8090703@selasky.org> <55B73113.2020308@selasky.org> <55B8AB76.7030603@selasky.org> <55B8B297.1010008@selasky.org> <20150729154516.GH78154@funkthat.com> <55B8F5EC.2050908@selasky.org> <46ad096c958.1a82a175@mail.schwarzes.net> <55B9C3E2.5040501@selasky.org> <46ae815c7c3.447237c8@mail.schwarzes.net> <46aece00b53.3c1cdc1f@mail.schwarzes.net> <55BB2A5F.9000502@selasky.org> <46baa16c4ce.6efd29ef@mail.schwarzes.net> <55CF31A1.5080205@selasky.org> <46ce372c895.20050775@mail.schwarzes.net> <46d0a4441bb.41f6f91d@mail.schwarzes.net> <55DD5C0A.2050401@selasky.org> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: DWC OTG TX path optimisation for 11-current MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Tue, 01 Sep 2015 00:42:16 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 22:42:20 -0000 On 28.08.15, Svatopluk Kraus wrote: > My subjective observation is that the slow system response can be > caused by slow wake up from idle state. I have tried to change > scheduler from ULE to BSD one with no MII warning and everything is > okay result. And buildword was about one hour faster. Note that the > trigger is very sensitive, so it can be just because system timing and > many other things are different with different scheduler. I've tried the 4BSD scheduler too, amazing, faster and surely prevents to run into the known problem. I've just started a buildworld loop, will try to reach 10 rounds. -asc From owner-freebsd-arm@freebsd.org Tue Sep 1 04:53:50 2015 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 53F8F9C07A4 for ; Tue, 1 Sep 2015 04:53:50 +0000 (UTC) (envelope-from me@rvijay.me) Received: from mail11.rvijay.me (mail11.rvijay.me [107.6.164.87]) by mx1.freebsd.org (Postfix) with ESMTP id 17387F93 for ; Tue, 1 Sep 2015 04:53:49 +0000 (UTC) (envelope-from me@rvijay.me) Received: from mail10.rvijay.me (mail10.rvijay.me [89.233.108.53]) by mail11.rvijay.me (Postfix) with ESMTP id AF77E1E611EC for ; Tue, 1 Sep 2015 10:23:42 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by mail10.rvijay.me (Postfix) with ESMTP id 5116D2480E for ; Tue, 1 Sep 2015 04:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rvijay.me; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from:to; s=20130919; t=1441083218; x=1441947219; bh=Cwf+S5AutGu7q+RiwtB0 Bi1bBowp5wIgokLXHklRVxs=; b=DcSKAz0xYQZm69fITPa2a1Y8rJr+anTkjM7m 6PDFPrJ3L/s2Ma43BEHK1pBRh3XP80/eInlmlOtbt0hmkyEzTRxKhJXpVs6+Y1gg HncRnmh7dmipcEHeUKUMwk+j2dsC5si5vd/v62cdr3RaCRxo3fb6LwTLTjPw8gwK Y955GjA= Received: from mail10.rvijay.me ([127.0.0.1]) by localhost (mail10.rvijay.me [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 9MBLyuvd0Gym for ; Tue, 1 Sep 2015 04:53:38 +0000 (UTC) Received: from Vijays-MacBook-Pro.local (unknown [183.83.50.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail10.rvijay.me (Postfix) with ESMTPSA id 79155247FA for ; Tue, 1 Sep 2015 04:53:38 +0000 (UTC) To: freebsd-arm@freebsd.org From: Vijay Rajah Subject: Support for Odroid-Xu4 Message-ID: <55E52F50.20909@rvijay.me> Date: Tue, 1 Sep 2015 10:23:36 +0530 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 04:53:50 -0000 Hello List, I have a Odroid Xu4. I intend to use this as my router (with a USB to Ethernet adapter & WiFi - usb adapter).. I have ubuntu running on this (for testing) I would really like to have FreeBSD on this platform. Is this platform supported? any tips/tricks so that I can try a few things. -Thanks Vijay From owner-freebsd-arm@freebsd.org Tue Sep 1 07:25:20 2015 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 65C169C816D for ; Tue, 1 Sep 2015 07:25:20 +0000 (UTC) (envelope-from prvs=679187919=julien.grall@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3945B4F; Tue, 1 Sep 2015 07:25:19 +0000 (UTC) (envelope-from prvs=679187919=julien.grall@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,447,1437436800"; d="scan'208";a="296390289" Subject: Re: arm64: userspace broken with jemalloc 4.0.0 To: Andrew Turner References: <55E22CC0.9000306@citrix.com> <20150831220647.67a4646d@bender.Home> CC: , freebsd-arm From: Julien Grall Message-ID: <55E552CC.9080206@citrix.com> Date: Tue, 1 Sep 2015 08:25:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150831220647.67a4646d@bender.Home> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 07:25:20 -0000 Hi Andrew, On 31/08/2015 22:06, Andrew Turner wrote: > On Sat, 29 Aug 2015 23:05:52 +0100 > Julien Grall wrote: >> I've built the latest freebsd master (r287263) for arm64 today. While >> trying to use the userspace I hit some ASSERT in jemalloc: >> >> # ls >> : /usr/src/freebsd/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:571: >> Failed assertion: "pageind >= map_bias" pid 21 (ls), uid 0: exited on >> signal 6 Abort trap >> >> It's happening every time with the command "ls". >> >> I tried to use the previous version of jemalloc (i.e reverting >> all the patches up to "Update jemalloc to version 4.0.0" included) >> and everything is working. >> >> Note that I'm using Freebsd as a Xen ARM guest although the only >> difference is the version of jemalloc (4.0.0 vs 3.6.0). >> >> Does anyone using arm64 have seen a similar ASSERT? >> >> BTW, is there any way to rebuild only the libc rather than doing >> make buildworld everytime I modified the jemalloc code? >> >> Regards, >> > > This is a bug in the runtime linkers handling of tls. The attached > patch allows me to get to multiuser mode without anything hitting the > above assert. I ended up to a similar patch during the week-end (see below). Although I was looking to the amd64/i386 definition of calculate_tls_offset which is the same as ARM64. I didn't understand why it's working for this architecture but not for ours. Is there any possible bug in the amd64/i386 runtime too? Regards, commit 3ee52ef6864c2180979d3de92cdf56f18a408beb Author: Julien Grall Date: Mon Aug 31 01:28:53 2015 +0100 rtld: fix diff --git a/libexec/rtld-elf/aarch64/rtld_machdep.h b/libexec/rtld-elf/aarch64/rtld_machdep.h index 1cb2029..ff4d60a 100644 --- a/libexec/rtld-elf/aarch64/rtld_machdep.h +++ b/libexec/rtld-elf/aarch64/rtld_machdep.h @@ -66,7 +66,7 @@ Elf_Addr reloc_jmpslot(Elf_Addr *where, Elf_Addr target, #define calculate_first_tls_offset(size, align) \ round(size, align) #define calculate_tls_offset(prev_offset, prev_size, size, align) \ - round((prev_offset) + (size), align) + round((prev_offset) + (prev_size), align) #define calculate_tls_end(off, size) ((off) + (size)) #define TLS_TCB_SIZE 8 diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 1d91460..1a776da 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -4427,7 +4427,7 @@ allocate_tls(Obj_Entry *objs, void *oldtcb, size_t tcbsize, size_t tcbalign) dtv[1] = tls_max_index; for (obj = objs; obj; obj = obj->next) { - if (obj->tlsoffset > 0) { + if (obj->tlssize > 0) { addr = (Elf_Addr)tls + obj->tlsoffset; if (obj->tlsinitsize > 0) memcpy((void*) addr, obj->tlsinit, obj->tlsinitsize); -- Julien Grall From owner-freebsd-arm@freebsd.org Tue Sep 1 10:38:48 2015 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 F368D9C8153 for ; Tue, 1 Sep 2015 10:38:48 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id C241911EB for ; Tue, 1 Sep 2015 10:38:48 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from bender (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 567C0D7FAC; Tue, 1 Sep 2015 10:38:41 +0000 (UTC) Date: Tue, 1 Sep 2015 11:38:38 +0100 From: Andrew Turner To: Julien Grall Cc: freebsd-arm Subject: Re: arm64: userspace broken with jemalloc 4.0.0 Message-ID: <20150901113838.02347efd@bender> In-Reply-To: <55E552CC.9080206@citrix.com> References: <55E22CC0.9000306@citrix.com> <20150831220647.67a4646d@bender.Home> <55E552CC.9080206@citrix.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 10:38:49 -0000 On Tue, 1 Sep 2015 08:25:00 +0100 Julien Grall wrote: > Hi Andrew, > > On 31/08/2015 22:06, Andrew Turner wrote: > > On Sat, 29 Aug 2015 23:05:52 +0100 > > Julien Grall wrote: > >> I've built the latest freebsd master (r287263) for arm64 today. > >> While trying to use the userspace I hit some ASSERT in jemalloc: > >> > >> # ls > >> : /usr/src/freebsd/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:571: > >> Failed assertion: "pageind >= map_bias" pid 21 (ls), uid 0: exited > >> on signal 6 Abort trap > >> > >> It's happening every time with the command "ls". > >> > >> I tried to use the previous version of jemalloc (i.e reverting > >> all the patches up to "Update jemalloc to version 4.0.0" included) > >> and everything is working. > >> > >> Note that I'm using Freebsd as a Xen ARM guest although the only > >> difference is the version of jemalloc (4.0.0 vs 3.6.0). > >> > >> Does anyone using arm64 have seen a similar ASSERT? > >> > >> BTW, is there any way to rebuild only the libc rather than doing > >> make buildworld everytime I modified the jemalloc code? > >> > >> Regards, > >> > > > > This is a bug in the runtime linkers handling of tls. The attached > > patch allows me to get to multiuser mode without anything hitting > > the above assert. > > I ended up to a similar patch during the week-end (see below). > Although I was looking to the amd64/i386 definition of > calculate_tls_offset which is the same as ARM64. I didn't understand > why it's working for this architecture but not for ours. > > Is there any possible bug in the amd64/i386 runtime too? amd64 and i386 use a different tls variant. They place the thread pointer at end of the buffer and allocate data before it, where arm64 places it at the start and allocates space after this. I suspect it was previously working by chance. There is a bug with all Variant I tls architectures (arm, arm64, mips, and powerpc) where the thread pointer may be trashed. I expect to fix this soon, and have a more complete fix committed soon after this. (For those interested in the layout of the tls data there is a paper on it at [1], with useful figures on pages 5 and 6). Andrew [1] http://www.akkadia.org/drepper/tls.pdf From owner-freebsd-arm@freebsd.org Tue Sep 1 10:54:12 2015 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 3BBA19C88D7 for ; Tue, 1 Sep 2015 10:54:12 +0000 (UTC) (envelope-from prvs=679187919=julien.grall@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9BF51C1A; Tue, 1 Sep 2015 10:54:11 +0000 (UTC) (envelope-from prvs=679187919=julien.grall@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,448,1437436800"; d="scan'208";a="299841048" Message-ID: <55E58389.5040606@citrix.com> Date: Tue, 1 Sep 2015 11:52:57 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Ed Maste CC: Andrew Turner , freebsd-arm Subject: Re: arm64: userspace broken with jemalloc 4.0.0 References: <55E22CC0.9000306@citrix.com> <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> <55E2FC47.5070801@citrix.com> <55E381F5.1030107@citrix.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 10:54:12 -0000 Hi Ed, On 31/08/15 21:29, Ed Maste wrote: > On 30 August 2015 at 18:21, Julien Grall wrote: >> >> >> So I figured out the problem today. ls is linked to 2 libraries using local >> thread storage: libxo and libc. Somehow the 2 libraries are using the same >> base pointer for the storage. >> >> When libxo will try to realloc a pointer living in the thread storage, >> jemalloc will throw an exception (the ASSERT mentioned earlier) because the >> pointer is invalid. The pointer was expected to be NULL but it has been >> overwritten by jemalloc earlier. > > Would you submit a PR for this to keep track of it while the > investigation is ongoing? Andrew provides a patch to fix the problem on the thread. Let me know if it's still worth to submit a PR. Regards, -- Julien Grall From owner-freebsd-arm@freebsd.org Tue Sep 1 13:01:34 2015 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 616579C78B0 for ; Tue, 1 Sep 2015 13:01:34 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from vps.amdmi3.ru (vps.amdmi3.ru [109.234.38.216]) by mx1.freebsd.org (Postfix) with ESMTP id 20ADF1E55; Tue, 1 Sep 2015 13:01:31 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from hive.panopticon (unknown [78.153.152.119]) by vps.amdmi3.ru (Postfix) with ESMTPS id 4779FB059C; Tue, 1 Sep 2015 16:01:23 +0300 (MSK) Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id A2BF8785; Tue, 1 Sep 2015 15:58:33 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id D5BC6BDE42; Tue, 1 Sep 2015 16:01:17 +0300 (MSK) Date: Tue, 1 Sep 2015 16:01:17 +0300 From: Dmitry Marakasov To: Svatopluk Kraus Cc: Adrian Chadd , "freebsd-arm@FreeBSD.org" , Ian Lepore Subject: Re: Instability likely related to new pmap on Cubieboard A10 Message-ID: <20150901130117.GK1245@hades.panopticon> References: <20150819120753.GH79354@hades.panopticon> <20150819134708.GJ79354@hades.panopticon> <20150819232836.GA1245@hades.panopticon> <20150820185417.GB1245@hades.panopticon> <20150820201020.GC1245@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 13:01:34 -0000 * Svatopluk Kraus (onwahe@gmail.com) wrote: > >> Thanks. Meantime, I tried most recent HEAD on pandaboard and > >> beaglebone black and no problem there. Do you have enabled INVARIANTS > >> and INVARIANT_SUPPORT in your config? > > > > I've enabled them at some point - at least last two runs had these > > enabled. Any other way I could help? Maybe I should check if it was > > new pmap commit which caused this, and if not, bisect it? > > > > Can you try attached semi-debug patch, please? I want to be sure that > problem is not on patched place. Sorry for delay, I was short on time last week, and then I was busy with setting up tftp/nfs netboot for my cubieboard. Now it finally works and I'd say it's pretty cool when I can test another build without plugging sd card around. Unfortunately, with this setup panic doesn't reproduce: there are just around 10 sh(1) segfaults during init, and then it boots into somehow usable state. Only once I've had panic with your latest patch applied: https://people.freebsd.org/~amdmi3/pmap4.log With my new netboot, I plan to try to bisect it; for panic debugging I guess I'll have to get back to plugging SD around. If you want me to do more panic tests, could we please revisit which patches should be applied cause I'm kinda lost in them. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://amdmi3.ru From owner-freebsd-arm@freebsd.org Tue Sep 1 16:11:57 2015 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 481039C7622 for ; Tue, 1 Sep 2015 16:11:57 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 0ECAFA8B for ; Tue, 1 Sep 2015 16:11:56 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZWnpI-000Cfc-J0 for freebsd-arm@freebsd.org; Tue, 01 Sep 2015 16:50:24 +0100 Date: Tue, 1 Sep 2015 16:50:24 +0100 From: John To: freebsd-arm@freebsd.org Subject: some general questions regarding freebsd on rasp pi Message-ID: <20150901155024.GA46253@potato.growveg.org> Reply-To: freesbd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:11:57 -0000 Hello list, I'm in a bit of a chicken-and-egg situation with regard to installing freebsd on a raspberry pi 2 b+. This pi as I understand it is 64-bit, has 1GB RAM. I want to use it to run exim, sshd, mutt, slrn and a few other bits. I've been looking for a repository of info for all things freebsd-arm but haven't come up with much useful and *recent*. Would be grateful if some kind soul could answer the following: 1. is it just a question of grabbing the iso, burning it to sd card and rebooting the pi? 2. if [1] is true, for this 64-bit pi, do I use FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150826-r287169.img.xz OR FreeBSD-11.0-CURRENT-arm64-aarch64-20150818-r286893-memstick.img.xz given that I want to run 64-bit? Is there a how-to or walk-through for arm/arm64 that is recent? If there is, I can't find it. many thanks, -- John From owner-freebsd-arm@freebsd.org Tue Sep 1 16:35:00 2015 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 987D69C8484 for ; Tue, 1 Sep 2015 16:35:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 707407B8 for ; Tue, 1 Sep 2015 16:34:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbkq10 with SMTP id kq10so5282382igb.0; Tue, 01 Sep 2015 09:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NUEd8L6NW/zC60ZhkGf86uNMbq1h9ODpITF6txowOkE=; b=OO/ftMEdib4ZBMl+Yzm1rB+hH/n8+tQ0tW0CjRxmUlf9wSwPfvBzpZUShkWxRZWb5w NAcmX6I3dZ7Lo9EFJsOpaBBZDDm2KwUiM7gMp4h4PU6Hm9u0ZiEOzB1KWJUdPRok5gAI brPpA72q2XDmgUMMe0K+hdwBA11zF6sqGx714ndYhDPwLytD4nitIzWTTsd+eU6wDRzp RM9u4f6gcQ2KAdi2TEj4nYDkHvdPeNyqVNvgM7SpUReLf29HALTzH+Plx3Kql9cq9Tub HP9jTo8GPE2suvUGjkGzWC0tWcO7HRb/DDlIS8cva55p/QRkTXf4J0bVZFSGvS9WyYb6 wH8g== MIME-Version: 1.0 X-Received: by 10.50.73.97 with SMTP id k1mr3100028igv.61.1441125296902; Tue, 01 Sep 2015 09:34:56 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Tue, 1 Sep 2015 09:34:56 -0700 (PDT) In-Reply-To: <20150901155024.GA46253@potato.growveg.org> References: <20150901155024.GA46253@potato.growveg.org> Date: Tue, 1 Sep 2015 09:34:56 -0700 Message-ID: Subject: Re: some general questions regarding freebsd on rasp pi From: Adrian Chadd To: freesbd-arm@freebsd.org, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:35:00 -0000 I didn't think it was a 64 bit ARM - use the RPI2 image. :) -a On 1 September 2015 at 08:50, John wrote: > Hello list, > > I'm in a bit of a chicken-and-egg situation with regard to installing freebsd > on a raspberry pi 2 b+. This pi as I understand it is 64-bit, has 1GB RAM. > I want to use it to run exim, sshd, mutt, slrn and a few other bits. I've been > looking for a repository of info for all things freebsd-arm but haven't come up > with much useful and *recent*. Would be grateful if some kind soul could answer > the following: > > 1. is it just a question of grabbing the iso, burning it to sd card and > rebooting the pi? > > 2. if [1] is true, for this 64-bit pi, do I use > FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150826-r287169.img.xz > > OR > > FreeBSD-11.0-CURRENT-arm64-aarch64-20150818-r286893-memstick.img.xz > > given that I want to run 64-bit? > > Is there a how-to or walk-through for arm/arm64 that is recent? If there > is, I can't find it. > > many thanks, > -- > John > _______________________________________________ > 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 Tue Sep 1 17:17:05 2015 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 3D0849C7A7F for ; Tue, 1 Sep 2015 17:17:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) (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 01310182 for ; Tue, 1 Sep 2015 17:17:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkcj187 with SMTP id j187so50821216qkc.2 for ; Tue, 01 Sep 2015 10:16:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1Ve6E+m9QaHtHcAQdHWgAApMWbHA5abc45ReyH+bxG8=; b=SX6f1j4tcH5yIViv301OOa0bqnLPSYsYAWEFpYIdemAUSPyDVt3z3tULKIP41lFVAJ jB6d+wm6YQzw7WkfahY4mtb4hHRUms4NzOADMrzV4fQQv3rwWe/gkzdcP140FGzXqIEb jZBLVjonVZWwwJm7ciBiPvAOT/z7dsTpLnbF5xRwsdnLISmvEzAWRdsvrTAa4RuAbwCD wVSvjexIby8GoshtTx4BsLn6N+sKgokeoy6ycZjaS2cmhtMdG1qc9UM1duVk4CzwCf7n +NsOVIsYQSGXNq6IGVFkbsRLQ5D3CKsxo9VQQ6EmpNSe14VI8nkXLypLxvpvynxEehSn pE0Q== X-Gm-Message-State: ALoCoQmj0SrIslO3rtBEsMOJiGgphrhLUL1R+80/646OtJRTKC0O2ouG+p64SyRfOo/Gg6zAigHY MIME-Version: 1.0 X-Received: by 10.55.197.139 with SMTP id k11mr21343082qkl.11.1441127817477; Tue, 01 Sep 2015 10:16:57 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.164 with HTTP; Tue, 1 Sep 2015 10:16:57 -0700 (PDT) X-Originating-IP: [69.53.245.26] In-Reply-To: <20150901155024.GA46253@potato.growveg.org> References: <20150901155024.GA46253@potato.growveg.org> Date: Tue, 1 Sep 2015 11:16:57 -0600 X-Google-Sender-Auth: fQm-bPgX0yxF4Hf7h9ygUddd-0Q Message-ID: Subject: Re: some general questions regarding freebsd on rasp pi From: Warner Losh To: freesbd-arm@freebsd.org, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:17:05 -0000 On Tue, Sep 1, 2015 at 9:50 AM, John wrote: > Hello list, > > I'm in a bit of a chicken-and-egg situation with regard to installing > freebsd > on a raspberry pi 2 b+. This pi as I understand it is 64-bit, has 1GB RAM. > Its still a 32-bit arm processor, best supported by the armv6 FreeBSD port. You cannot run arm64 on it because it isn't a 64-bit processor. > I want to use it to run exim, sshd, mutt, slrn and a few other bits. I've > been > looking for a repository of info for all things freebsd-arm but haven't > come up > with much useful and *recent*. Would be grateful if some kind soul could > answer > the following: > > 1. is it just a question of grabbing the iso, burning it to sd card and > rebooting the pi? > Yes. > 2. if [1] is true, for this 64-bit pi, do I use > FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150826-r287169.img.xz > > OR > > FreeBSD-11.0-CURRENT-arm64-aarch64-20150818-r286893-memstick.img.xz > > given that I want to run 64-bit? > You can use either. But there's no way to run 64-bit on the core that's in the RPi2. You simply can't do that, no matter how much you might want to :) > Is there a how-to or walk-through for arm/arm64 that is recent? If there > is, I can't find it. The handbook information on creating SD images from the images the release engineer makes is good. Warner From owner-freebsd-arm@freebsd.org Tue Sep 1 17:18:32 2015 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 3ED589C7B09 for ; Tue, 1 Sep 2015 17:18:32 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 12AC0220 for ; Tue, 1 Sep 2015 17:18:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 0A8573B4; Tue, 1 Sep 2015 13:12:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: some general questions regarding freebsd on rasp pi From: Paul Mather In-Reply-To: Date: Tue, 1 Sep 2015 13:12:37 -0400 Cc: freesbd-arm@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <22E09F55-EF8A-424C-9E74-8D1ADB67BCB7@gromit.dlib.vt.edu> References: <20150901155024.GA46253@potato.growveg.org> To: Adrian Chadd X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:18:32 -0000 > On Sep 1, 2015, at 12:34 PM, Adrian Chadd = wrote: >=20 > I didn't think it was a 64 bit ARM - use the RPI2 image. :) +1 The Raspberry Pi 2 isn't a 64-bit ARM device. I can confirm for the = original poster, though, that the RPI2 image works nicely as a way of = doing the initial install. Cheers, Paul. >=20 >=20 >=20 > -a >=20 >=20 > On 1 September 2015 at 08:50, John = wrote: >> Hello list, >>=20 >> I'm in a bit of a chicken-and-egg situation with regard to installing = freebsd >> on a raspberry pi 2 b+. This pi as I understand it is 64-bit, has 1GB = RAM. >> I want to use it to run exim, sshd, mutt, slrn and a few other bits. = I've been >> looking for a repository of info for all things freebsd-arm but = haven't come up >> with much useful and *recent*. Would be grateful if some kind soul = could answer >> the following: >>=20 >> 1. is it just a question of grabbing the iso, burning it to sd card = and >> rebooting the pi? >>=20 >> 2. if [1] is true, for this 64-bit pi, do I use >> FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150826-r287169.img.xz >>=20 >> OR >>=20 >> FreeBSD-11.0-CURRENT-arm64-aarch64-20150818-r286893-memstick.img.xz >>=20 >> given that I want to run 64-bit? >>=20 >> Is there a how-to or walk-through for arm/arm64 that is recent? If = there >> is, I can't find it. >>=20 >> many thanks, >> -- >> John >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@freebsd.org Wed Sep 2 02:53:44 2015 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 3838B9C8846 for ; Wed, 2 Sep 2015 02:53:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 04414A35; Wed, 2 Sep 2015 02:53:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by igcrk20 with SMTP id rk20so15649395igc.1; Tue, 01 Sep 2015 19:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=D2gtNJoCQ+cDD9S4AOcFwzDFq08l9noLtK8RrTZbKEs=; b=VoJaGl01Ep9i+Sa1ynDkrR3c3VwvHanweBJ9L+HffwxMIPiEUgjV3GlL7DjGODf2uZ VQ8YfSnlilvIsOoduEu93S4UPYDrLZmEhFaqhwguzW3ovwRHdHDDzoMHSsJgh9J/CiiM eD7oEC4U9hUvhLSDAtATRee3Iv6XyR6K7/Idd9OhoZid6h92pV9iCi2QqkF8X/846HzL IHHoXk3AAFp2xH9rAu4YhsaLhaS/Uw54JzfA6J52nsgevh9f8yeeK1Bhq7Bye5J03svx 7Q1OlkE+UJ/tBO8BieF2xCXoRh2VdOQ6Gt/UmNUThHWcaqLXYtyOZq53IUjTsJSOzanI SoWA== X-Received: by 10.50.20.135 with SMTP id n7mr1299892ige.58.1441162423307; Tue, 01 Sep 2015 19:53:43 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.166.17 with HTTP; Tue, 1 Sep 2015 19:53:23 -0700 (PDT) In-Reply-To: <55E58389.5040606@citrix.com> References: <55E22CC0.9000306@citrix.com> <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> <55E2FC47.5070801@citrix.com> <55E381F5.1030107@citrix.com> <55E58389.5040606@citrix.com> From: Ed Maste Date: Tue, 1 Sep 2015 22:53:23 -0400 X-Google-Sender-Auth: 2sSYsz0kT4MHE6v04cyzcLMV5Vs Message-ID: Subject: Re: arm64: userspace broken with jemalloc 4.0.0 To: Julien Grall Cc: Andrew Turner , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 02:53:44 -0000 >> Would you submit a PR for this to keep track of it while the >> investigation is ongoing? > > Andrew provides a patch to fix the problem on the thread. Let me know if > it's still worth to submit a PR. No - I wasn't aware that Andrew had all of the details and just wanted to make sure we had a single place to collect data during the investigation. Once it turned out that the issue was well-understood with a patch in progress there was no need. Thanks, Ed From owner-freebsd-arm@freebsd.org Wed Sep 2 03:53:10 2015 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 C70D59C8687 for ; Wed, 2 Sep 2015 03:53:10 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 9D13E9EE for ; Wed, 2 Sep 2015 03:53:10 +0000 (UTC) (envelope-from tim@kientzle.com) Received: by pacfv12 with SMTP id fv12so17846552pac.2 for ; Tue, 01 Sep 2015 20:53:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xY6omQXTC8g938uGs+cQh52epsmPqU4JPiumut6mLP0=; b=IZzjh5z5LiQRwUtb+iVFW6VvQqB7Rvd29a0JVmVgqT5SjWVtJFwPQl7PjsZ76lCa/N 6cOmS0JGI5RaBvEbxw7SzWbUaG4xiQj8FI5Cns4FxcAq+3Xg3XKXJN1CB7WDSLZ5yLai uWD91i3u/bWF9i1hUMGtmeUFA5H/XEsl4MRohnCiOwIyTS8UXALzQytjX0xHNJHSvdWH RW/yXjXIsFW8UrW/5rfWhUGCasLpirOwnHymqbY1zVHCE5SlUb58vKoQQF9WrCG4glzJ mxOzz2Llp35GlGbCFzJeBzmZe+lP38NN/hmIr47UuzNKwFEdoQ2vYHE+KO5MeDuxwZlv 28mg== X-Gm-Message-State: ALoCoQkerSjbxQh65vcRg36dTv3vGBrrk4PxvyVzUz0WiAQze+wkDqboMP2i0Ly1kPmJ8rfe4k8d X-Received: by 10.68.202.72 with SMTP id kg8mr52107570pbc.42.1441165984401; Tue, 01 Sep 2015 20:53:04 -0700 (PDT) Received: from [192.168.1.102] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by smtp.gmail.com with ESMTPSA id pj3sm19835910pdb.6.2015.09.01.20.53.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Sep 2015 20:53:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: some general questions regarding freebsd on rasp pi From: Tim Kientzle In-Reply-To: <20150901155024.GA46253@potato.growveg.org> Date: Tue, 1 Sep 2015 20:53:01 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150901155024.GA46253@potato.growveg.org> To: freesbd-arm@freebsd.org X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 03:53:10 -0000 > On Sep 1, 2015, at 8:50 AM, John = wrote: >=20 > Hello list, >=20 > I'm in a bit of a chicken-and-egg situation with regard to installing = freebsd > on a raspberry pi 2 b+. This pi as I understand it is 64-bit, has 1GB = RAM. > I want to use it to run exim, sshd, mutt, slrn and a few other bits. = I've been > looking for a repository of info for all things freebsd-arm but = haven't come up > with much useful and *recent*. Would be grateful if some kind soul = could answer=20 > the following: >=20 > 1. is it just a question of grabbing the iso, burning it to sd card = and=20 > rebooting the pi? Yes. >=20 > 2. if [1] is true, for this 64-bit pi, do I use=20 > FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150826-r287169.img.xz >=20 > OR >=20 > FreeBSD-11.0-CURRENT-arm64-aarch64-20150818-r286893-memstick.img.xz >=20 > given that I want to run 64-bit? Use the RPI2 image. (arm64 is for 64-bit arm; RPI2 is a 32-bit = processor). >=20 > Is there a how-to or walk-through for arm/arm64 that is recent? If = there > is, I can't find it. There is some information on the FreeBSD Wiki for particular boards: https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi And, of course, this mailing list is a good place to ask other related = questions. Tim >=20 > many thanks, > --=20 > John > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Sep 2 13:49:35 2015 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 E197F9C82D2 for ; Wed, 2 Sep 2015 13:49:35 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 A57D3813 for ; Wed, 2 Sep 2015 13:49:35 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZX8Pr-0009SU-Hq for freebsd-arm@freebsd.org; Wed, 02 Sep 2015 14:49:31 +0100 Date: Wed, 2 Sep 2015 14:49:31 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: some general questions regarding freebsd on rasp pi Message-ID: <20150902134931.GA2221@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150901155024.GA46253@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 13:49:36 -0000 On Tue, Sep 01, 2015 at 11:16:57AM -0600, Warner Losh wrote: > Its still a 32-bit arm processor, best supported by the armv6 FreeBSD port. > You cannot run arm64 on it because it isn't a 64-bit processor. Thanks everyone. (see, told you I was an idiot). Seems to be running nicely now. Just need to update ports and start building what I need. One answer i've not been able to find - is it easy to clock the pi under freebsd? Looking for 1GHz (think the ram is half this) -- John From owner-freebsd-arm@freebsd.org Wed Sep 2 14:47:39 2015 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 8BEB49C831F for ; Wed, 2 Sep 2015 14:47:39 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 511BDA81; Wed, 2 Sep 2015 14:47:39 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by igcpb10 with SMTP id pb10so27123972igc.1; Wed, 02 Sep 2015 07:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ewR214g+abQzzLKihrolUBe77iTXTJyP9s/xSK6cHIQ=; b=rJpcqy92V86cu7hsXY5oO7LmqX/nwgX8RtC6wcTmy9FvrvqmlBeYBvxui7RcjKhaLw d95GNlmowGY//I/o6vx4bNGfFhteBpcGAGmLKOworMs82fbD1OQ/oNU/R9dxJNUPZUP1 Ue6FPWdz8O9lhSwyw9w5/n/8KEKwVKhex7iLhXRjqmhEwheXEseCnK5/IkkXDN9LKc5v 4AEcTCs4MYlH75vjCwTxDopfjmrxTGzMGcXDuzjWowiWPeLX2HY2N4zX3XJiTcFd/a2O tA8HccabDXPKByqieoODqLOCoKrPdOlOYDznHM8pMtpEzC3Fxn1EYlhTx90i0gy3DJI8 GL9w== MIME-Version: 1.0 X-Received: by 10.50.26.66 with SMTP id j2mr3412528igg.42.1441205258541; Wed, 02 Sep 2015 07:47:38 -0700 (PDT) Received: by 10.64.239.196 with HTTP; Wed, 2 Sep 2015 07:47:38 -0700 (PDT) In-Reply-To: <20150901130117.GK1245@hades.panopticon> References: <20150819120753.GH79354@hades.panopticon> <20150819134708.GJ79354@hades.panopticon> <20150819232836.GA1245@hades.panopticon> <20150820185417.GB1245@hades.panopticon> <20150820201020.GC1245@hades.panopticon> <20150901130117.GK1245@hades.panopticon> Date: Wed, 2 Sep 2015 16:47:38 +0200 Message-ID: Subject: Re: Instability likely related to new pmap on Cubieboard A10 From: Svatopluk Kraus To: Dmitry Marakasov Cc: Adrian Chadd , "freebsd-arm@FreeBSD.org" , Ian Lepore Content-Type: multipart/mixed; boundary=047d7bd75bb27c36d0051ec4bf6f X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:47:39 -0000 --047d7bd75bb27c36d0051ec4bf6f Content-Type: text/plain; charset=UTF-8 On Tue, Sep 1, 2015 at 3:01 PM, Dmitry Marakasov wrote: > * Svatopluk Kraus (onwahe@gmail.com) wrote: > >> >> Thanks. Meantime, I tried most recent HEAD on pandaboard and >> >> beaglebone black and no problem there. Do you have enabled INVARIANTS >> >> and INVARIANT_SUPPORT in your config? >> > >> > I've enabled them at some point - at least last two runs had these >> > enabled. Any other way I could help? Maybe I should check if it was >> > new pmap commit which caused this, and if not, bisect it? >> > >> >> Can you try attached semi-debug patch, please? I want to be sure that >> problem is not on patched place. > > Sorry for delay, I was short on time last week, and then I was busy with > setting up tftp/nfs netboot for my cubieboard. Now it finally works > and I'd say it's pretty cool when I can test another build without > plugging sd card around. Unfortunately, with this setup panic doesn't > reproduce: there are just around 10 sh(1) segfaults during init, and > then it boots into somehow usable state. Only once I've had panic with > your latest patch applied: > > https://people.freebsd.org/~amdmi3/pmap4.log > > With my new netboot, I plan to try to bisect it; for panic debugging I > guess I'll have to get back to plugging SD around. If you want me to do > more panic tests, could we please revisit which patches should be > applied cause I'm kinda lost in them. > Okay then, here is my summary: I thought that segmentation faults and panic(s) are caused by two different things. Now, it looks that they are not. The logs of old configuration with sd card, you provided, shows that something is corrupting kernel memory. Three logs and three quite different corruptions. So now, I would like to focus to segmentation faults which points to some corruption too. As you are only one who reports this kind of problem, it's probably related to your hardware or the way how your system is booted. Thus, if you would be so kind: (A1) Use only one hardware configuration now. I like to investigate the segmentation faults, so you may use netboot. (A2) Start with clean, up to date kernel without any patches to learn how the system behaves. (A3) You can try to use old pmap, however, the result has no relevance. Note that with old pmap, the system memory layout is different, the system timing is different (for example, when a process is forking), and pointless cache and TLB operation are done in addition. (A4) Apply attached patch, enable KTR, set KTR_MASK to KTR_TRAP, and when system breaks to debugger, send me output from the following commands: "show ktr" ... at least 10 lines but more is better ;) "show pmap /u" (A5) If you type "continue", you can repeat step A4 and send me info from more segmentation faults at once. (A6) If you got panic, send me kernel file together with panic backtrace. (B) Another thing you could try is to omit in you configuration as many devices as possible. Mainly the ones which use DMA. For example, boot from sd card without network driver compiled in and vice versa. (C) If you think that there was kernel revision including new pmap which worked without problems, confirm that please and tell me which one it was. Svata --047d7bd75bb27c36d0051ec4bf6f Content-Type: text/plain; charset=US-ASCII; name="pmap_debug3.diff" Content-Disposition: attachment; filename="pmap_debug3.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie2w51dx0 SW5kZXg6IHN5cy9hcm0vYXJtL3RyYXAtdjYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL2FybS90 cmFwLXY2LmMJKHJldmlzaW9uIDI4NzM5NCkKKysrIHN5cy9hcm0vYXJtL3RyYXAtdjYuYwkod29y a2luZyBjb3B5KQpAQCAtMTY3LDcgKzE2NywyNyBAQAogCXthYm9ydF9mYXRhbCwJIlVuZGVmaW5l ZCBDb2RlICgweDQwRikifQogfTsKIAorc3RhdGljIHZvaWQKK2NwdV90cmFjZXNpZ2V4aXQoc3Ry dWN0IHRocmVhZCAqdGQpCit7CisJc3RydWN0IHRyYXBmcmFtZSAqdGY7CiAKKwl0ZiA9IHRkLT50 ZF9mcmFtZTsKKwlpZiAodGYgPT0gTlVMTCkKKwkJcmV0dXJuOworCisJQ1RSMyhLVFJfVFJBUCwg InBjIDB4JTA4eCB1c3JfbHIgMHglMDh4IHVzcl9zcCAweCUwOHgiLAorCSAgICB0Zi0+dGZfcGMs IHRmLT50Zl91c3JfbHIsIHRmLT50Zl91c3Jfc3ApOworCUNUUjMoS1RSX1RSQVAsICJzcHNyIDB4 JTA4eCBzdmNfbHIgMHglMDh4IHN2Y19zcCAweCUwOHgiLAorCSAgICB0Zi0+dGZfc3BzciwgdGYt PnRmX3N2Y19sciwgdGYtPnRmX3N2Y19zcCk7CisJQ1RSNShLVFJfVFJBUCwgInIwIDB4JTA4eCBy MSAweCUwOHggcjIgMHglMDh4IHIzIDB4JTA4eCByNCAweCUwOHgiLAorCSAgICB0Zi0+dGZfcjAs IHRmLT50Zl9yMSwgdGYtPnRmX3IyLCB0Zi0+dGZfcjMsIHRmLT50Zl9yNCk7CisJQ1RSNShLVFJf VFJBUCwgInI1IDB4JTA4eCByNiAweCUwOHggcjcgMHglMDh4IHI4IDB4JTA4eCByOSAweCUwOHgi LAorCSAgICB0Zi0+dGZfcjUsIHRmLT50Zl9yNiwgdGYtPnRmX3I3LCB0Zi0+dGZfcjgsIHRmLT50 Zl9yOSk7CisJQ1RSMyhLVFJfVFJBUCwgInIxMCAweCUwOHggcjExIDB4JTA4eCByMTIgMHglMDh4 IiwKKwkgICAgdGYtPnRmX3IxMCwgdGYtPnRmX3IxMSwgdGYtPnRmX3IxMik7Cit9CisKIHN0YXRp YyBfX2lubGluZSB2b2lkCiBjYWxsX3RyYXBzaWduYWwoc3RydWN0IHRocmVhZCAqdGQsIGludCBz aWcsIGludCBjb2RlLCB2bV9vZmZzZXRfdCBhZGRyKQogewpAQCAtMTc2LDYgKzE5Niw5IEBACiAJ Q1RSNChLVFJfVFJBUCwgIiVzOiBhZGRyOiAlI3gsIHNpZzogJWQsIGNvZGU6ICVkIiwKIAkgICBf X2Z1bmNfXywgYWRkciwgc2lnLCBjb2RlKTsKIAorCWNwdV90cmFjZXNpZ2V4aXQodGQpOworCWJy ZWFrcG9pbnQoKTsKKwogCS8qCiAJICogVE9ETzogc29tZSBpbmZvIHdvdWxkIGJlIG5pY2UgdG8g a25vdwogCSAqIGlmIHdlIGFyZSBzZXJ2aW5nIGRhdGEgb3IgcHJlZmV0Y2ggYWJvcnQuCg== --047d7bd75bb27c36d0051ec4bf6f-- From owner-freebsd-arm@freebsd.org Thu Sep 3 00:10:45 2015 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 7BA1A9C7517 for ; Thu, 3 Sep 2015 00:10:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6C64D36 for ; Thu, 3 Sep 2015 00:10:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id t830Ac3s070928; Wed, 2 Sep 2015 17:10:38 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id t830AcDc070927; Wed, 2 Sep 2015 17:10:38 -0700 (PDT) (envelope-from fbsd) Date: Wed, 2 Sep 2015 17:10:37 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Reproducible crashes on RPI2 under 11-CURRENT using stress2 Message-ID: <20150903001037.GC33831@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 00:10:45 -0000 It seems possible to cause relatively reproducible crashes on RPI2 under 11-CURRENT using Peter Holm's stress2 suite. Below are console output and backtrace of four crashes produced in the space of one day. To my surprise, all four seem related to virtual memory. How, or if, that's related to the crashes seen during build of the OS is unclear, since those seemed related to writing to the microSD card. FreeBSD 11.0-CURRENT (RPI2) #48 r287318M: Mon Aug 31 20:02:27 PDT 2015 Crash #1 Triggered by stress2, invocation sh ./run.sh -a stress2 started at 11:57:20, last output lines were 14:51:14 Loop #1 swap: run time 0+00:00:15, incarnations 30, load 80, verbose 1 syscall: run time 0+00:00:15, incarnations 18, load 100, verbose 1 The smsc0 warnings began a few minutes after stress2 was started. Console output and backtrace: smsc0: warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy panic: vm_fault: fault on nofault entry, addr: d1a2f000 cpuid = 0 KDB: enter: panic [ thread pid 5372 tid 100149 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 5372 tid 100149 td 0xc4a8b360 db_trace_self() at db_trace_self pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) sp = 0xed605730 fp = 0xed605748 r10 = 0xc07885f8 db_stack_trace() at db_stack_trace+0x108 pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) sp = 0xed605750 fp = 0xed6057f0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r10 = 0xc07885f8 db_command() at db_command+0x388 pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) sp = 0xed6057f8 fp = 0xed605808 r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 r6 = 0xc07885e4 r7 = 0xed6059d8 r8 = 0xc077d620 r9 = 0xc0693fa4 r10 = 0xc077d624 db_command_loop() at db_command_loop+0x74 pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) sp = 0xed605810 fp = 0xed605928 r4 = 0x00000000 r5 = 0xc07885f0 r6 = 0xc077d648 r10 = 0xc077d624 db_trap() at db_trap+0x108 pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) sp = 0xed605930 fp = 0xed605958 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc077d648 r7 = 0xed6059d8 kdb_trap() at kdb_trap+0x184 pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) sp = 0xed605960 fp = 0xed6059d0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc055b728 r7 = 0xe7ffffff r8 = 0xc4a8b360 r9 = 0xc02eadf8 r10 = 0xed6059d8 undefinedinstruction() at undefinedinstruction+0x344 pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) sp = 0xed6059d8 fp = 0xed605a70 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xed605ab4 r9 = 0xc078a3a0 r10 = 0xc4a8b360 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) sp = 0xed605a68 fp = 0xed605a70 r0 = 0xc077d634 r1 = 0x00000000 r2 = 0xed60599c r3 = 0xc05cfbc0 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xed605ab4 r9 = 0xc078a3a0 r10 = 0xc4a8b360 r12 = 0xc06aed58 $a.8() at $a.8 pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) sp = 0xed605a78 fp = 0xed605a98 r4 = 0x00000100 r10 = 0xc4a8b360 vpanic() at vpanic+0x164 pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) sp = 0xed605aa0 fp = 0xed605aa8 r4 = 0xc097e000 r5 = 0xed605bd4 r6 = 0xed605bc8 r7 = 0xc05f7991 r8 = 0xd1a2f000 r9 = 0x00000000 r10 = 0x000007c0 kproc_shutdown() at kproc_shutdown pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) sp = 0xed605ab0 fp = 0xed605c28 r4 = 0xed605bd4 r5 = 0xed605ab4 vm_fault_dirty() at vm_fault_dirty pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) sp = 0xed605c30 fp = 0xed605c50 r4 = 0x00000002 r5 = 0xc4a8b360 r6 = 0xd1a2f000 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xc078e1f8 vm_fault() at vm_fault+0x88 pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) sp = 0xed605c58 fp = 0xed605cf8 r4 = 0xed605d00 r5 = 0x00000000 r6 = 0x00000007 r7 = 0x00000007 r8 = 0xd1a2fb00 r9 = 0xc4a8b360 r10 = 0x00000013 abort_handler() at abort_handler+0x400 pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) sp = 0xed605d00 fp = 0x00000000 r4 = 0xc4a8b360 r5 = 0xed605e08 r6 = 0xed605dc8 r7 = 0x00000000 r8 = 0xed605e00 r9 = 0xc078a010 r10 = 0xed605ea8 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc053e3e0 (copyin+0x80) sp = 0xed605d94 fp = 0x00000000 r0 = 0xd1a2fb00 r1 = 0xed605dc8 r2 = 0x00000010 r3 = 0x00000001 r4 = 0xc4a8b360 r5 = 0xed605e08 r6 = 0xed605dc8 r7 = 0x00000000 r8 = 0xed605e00 r9 = 0xc078a010 r10 = 0xed605ea8 r12 = 0x00000001 copyin() at copyin+0x2e4 pc = 0xc053e644 lr = 0xc053e3e0 (copyin+0x80) sp = 0xed605d94 fp = 0x00000000 copyin() at copyin+0x80 pc = 0xc053e3e0 lr = 0xc053e3e0 (copyin+0x80) sp = 0xed605d94 fp = 0x00000000 Unwind failure (no registers changed) db> Crash #2 Stress2 started as above. 20150901 15:14:56 all.cfg, elapsed 00:00:01 Last words from stress2 17:18:09 Loop #1 swap: run time 0+00:00:15, incarnations 23, load 80, verbose 1 syscall: run time 0+00:00:15, incarnations 17, load 100, verbose 1 Console and backtrace follow: smsc0: warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to write register 0x114 panic: vm_fault: fault on nofault entry, addr: c48ee000 cpuid = 3 KDB: enter: panic [ thread pid 4860 tid 100234 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 4860 tid 100234 td 0xc4c11a20 db_trace_self() at db_trace_self pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) sp = 0xed7bef40 fp = 0xed7bef58 r10 = 0xc07885f8 db_stack_trace() at db_stack_trace+0x108 pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) sp = 0xed7bef60 fp = 0xed7bf000 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r10 = 0xc07885f8 db_command() at db_command+0x388 pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) sp = 0xed7bf008 fp = 0xed7bf018 r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 r6 = 0xc07885e4 r7 = 0xed7bf1e8 r8 = 0xc077d620 r9 = 0xc0693fa4 r10 = 0xc077d624 db_command_loop() at db_command_loop+0x74 pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) sp = 0xed7bf020 fp = 0xed7bf138 r4 = 0x00000000 r5 = 0xc07885f0 r6 = 0xc077d648 r10 = 0xc077d624 db_trap() at db_trap+0x108 pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) sp = 0xed7bf140 fp = 0xed7bf168 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc077d648 r7 = 0xed7bf1e8 kdb_trap() at kdb_trap+0x184 pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) sp = 0xed7bf170 fp = 0xed7bf1e0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc055b728 r7 = 0xe7ffffff r8 = 0xc4c11a20 r9 = 0xc02eadf8 r10 = 0xed7bf1e8 undefinedinstruction() at undefinedinstruction+0x344 pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) sp = 0xed7bf1e8 fp = 0xed7bf280 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xed7bf2c4 r9 = 0xc078a3a0 r10 = 0xc4c11a20 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) sp = 0xed7bf278 fp = 0xed7bf280 r0 = 0xc077d634 r1 = 0x00000000 r2 = 0xed7bf1ac r3 = 0xc05cfbc0 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xed7bf2c4 r9 = 0xc078a3a0 r10 = 0xc4c11a20 r12 = 0xc06aed58 $a.8() at $a.8 pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) sp = 0xed7bf288 fp = 0xed7bf2a8 r4 = 0x00000100 r10 = 0xc4c11a20 vpanic() at vpanic+0x164 pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) sp = 0xed7bf2b0 fp = 0xed7bf2b8 r4 = 0xc097e000 r5 = 0xed7bf3e4 r6 = 0xed7bf3d8 r7 = 0xc05f7991 r8 = 0xc48ee000 r9 = 0x00000000 r10 = 0x000007c0 kproc_shutdown() at kproc_shutdown pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) sp = 0xed7bf2c0 fp = 0xed7bf438 r4 = 0xed7bf3e4 r5 = 0xed7bf2c4 vm_fault_dirty() at vm_fault_dirty pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) sp = 0xed7bf440 fp = 0xed7bf460 r4 = 0x00000002 r5 = 0xc4c11a20 r6 = 0xc48ee000 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xc078e1f8 vm_fault() at vm_fault+0x88 pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) sp = 0xed7bf468 fp = 0xed7bf508 r4 = 0xed7bf510 r5 = 0x00000000 r6 = 0x0000000f r7 = 0x0000000f r8 = 0xc48ee4fc r9 = 0xc4c11a20 r10 = 0x00000013 abort_handler() at abort_handler+0x400 pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) sp = 0xed7bf510 fp = 0x00000000 r4 = 0xed7bfe08 r5 = 0xc4c11a20 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xed7bfe00 r9 = 0xc078a010 r10 = 0xed7bfea8 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc053e3e0 (copyin+0x80) sp = 0xed7bf5a4 fp = 0x00000000 r0 = 0xc48ee4fc r1 = 0xed7bf5c0 r2 = 0x00000004 r3 = 0x00000001 r4 = 0xed7bfe08 r5 = 0xc4c11a20 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xed7bfe00 r9 = 0xc078a010 r10 = 0xed7bfea8 r12 = 0x00000001 copyin() at copyin+0x2e4 pc = 0xc053e644 lr = 0xc053e3e0 (copyin+0x80) sp = 0xed7bf5a4 fp = 0x00000000 copyin() at copyin+0x80 pc = 0xc053e3e0 lr = 0xc053e3e0 (copyin+0x80) sp = 0xed7bf5a4 fp = 0x00000000 Unwind failure (no registers changed) db> Crash #3 Setup as before: Reboot, fsck-fy until filesystem was clean, reboot to multi-user Stress2 invoked with sh ./run.shl-a, initial terminal output was 20150901 17:37:06 all.cfg, elapsed 00:00:00 run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 17:37:06 Loop #1 udp: run time 0+00:02:00, incarnations 16, load 20, verbose 1 mkdir: run time 0+00:02:00, incarnations 1, load 80, verbose 1 mkfifo: run time 0+00:02:00, incarnations 8, load 20, verbose 1 symlink: run time 0+00:02:00, incarnations 7, load 20, verbose 1 swap: run time 0+00:02:00, incarnations 38, load 80, verbose 1 mmap: run time 0+00:02:00, incarnations 2, load 20, verbose 1 thr1: run time 0+00:02:00, incarnations 12, load 20, verbose 1 An intermediate output which looks odd: 19:08:25 Loop #1 mkdir: run time 0+00:02:00, incarnations 5, load 80, verbose 1 tcp: run time 0+00:02:00, incarnations 12, load 20, verbose 1 thr1: run time 0+00:02:00, incarnations 16, load 20, verbose 1 rw: run time 0+00:02:00, incarnations 6, load 70, verbose 1 creat: run time 0+00:02:00, incarnations 12, load 80, verbose 1 tcp: write(3), tcp.c:146: Connection reset by peer 20150901 19:14:45 pty.cfg, elapsed 01:37:39 run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 Last words were: 20150901 19:30:31 syscall.cfg, elapsed 01:53:24 run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 19:30:36 Loop #1 Console output and backtrace: smsc0: warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to write register 0x114 panic: vm_fault: fault on nofault entry, addr: c8ace000 cpuid = 2 KDB: enter: panic [ thread pid 3146 tid 100747 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 3146 tid 100747 td 0xc4fe3360 db_trace_self() at db_trace_self pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) sp = 0xeda676b0 fp = 0xeda676c8 r10 = 0xc07885f8 db_stack_trace() at db_stack_trace+0x108 pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) sp = 0xeda676d0 fp = 0xeda67770 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r10 = 0xc07885f8 db_command() at db_command+0x388 pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) sp = 0xeda67778 fp = 0xeda67788 r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 r6 = 0xc07885e4 r7 = 0xeda67958 r8 = 0xc077d620 r9 = 0xc0693fa4 r10 = 0xc077d624 db_command_loop() at db_command_loop+0x74 pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) sp = 0xeda67790 fp = 0xeda678a8 r4 = 0x00000000 r5 = 0xc07885f0 r6 = 0xc077d648 r10 = 0xc077d624 db_trap() at db_trap+0x108 pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) sp = 0xeda678b0 fp = 0xeda678d8 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc077d648 r7 = 0xeda67958 kdb_trap() at kdb_trap+0x184 pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) sp = 0xeda678e0 fp = 0xeda67950 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc055b728 r7 = 0xe7ffffff r8 = 0xc4fe3360 r9 = 0xc02eadf8 r10 = 0xeda67958 undefinedinstruction() at undefinedinstruction+0x344 pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) sp = 0xeda67958 fp = 0xeda679f0 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xeda67a34 r9 = 0xc078a3a0 r10 = 0xc4fe3360 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) sp = 0xeda679e8 fp = 0xeda679f0 r0 = 0xc077d634 r1 = 0x00000000 r2 = 0xeda6791c r3 = 0xc05cfbc0 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xeda67a34 r9 = 0xc078a3a0 r10 = 0xc4fe3360 r12 = 0xc06aed58 $a.8() at $a.8 pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) sp = 0xeda679f8 fp = 0xeda67a18 r4 = 0x00000100 r10 = 0xc4fe3360 vpanic() at vpanic+0x164 pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) sp = 0xeda67a20 fp = 0xeda67a28 r4 = 0xc097e000 r5 = 0xeda67b54 r6 = 0xeda67b48 r7 = 0xc05f7991 r8 = 0xc8ace000 r9 = 0x00000000 r10 = 0x000007c0 kproc_shutdown() at kproc_shutdown pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) sp = 0xeda67a30 fp = 0xeda67ba8 r4 = 0xeda67b54 r5 = 0xeda67a34 vm_fault_dirty() at vm_fault_dirty pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) sp = 0xeda67bb0 fp = 0xeda67bd0 r4 = 0x00000002 r5 = 0xc4fe3360 r6 = 0xc8ace000 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xc078e1f8 vm_fault() at vm_fault+0x88 pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) sp = 0xeda67bd8 fp = 0xeda67c78 r4 = 0xeda67c80 r5 = 0x00000000 r6 = 0x00000007 r7 = 0x00000007 r8 = 0xc8ace554 r9 = 0xc4fe3360 r10 = 0x00000013 abort_handler() at abort_handler+0x400 pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) sp = 0xeda67c80 fp = 0x00000000 r4 = 0xeda67e08 r5 = 0xc4fe3360 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xeda67e00 r9 = 0xc078a010 r10 = 0xeda67ea8 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc053e3e0 (copyin+0x80) sp = 0xeda67d14 fp = 0x00000000 r0 = 0xc8ace554 r1 = 0xeda67d44 r2 = 0x0000001c r3 = 0x00000001 r4 = 0xeda67e08 r5 = 0xc4fe3360 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xeda67e00 r9 = 0xc078a010 r10 = 0xeda67ea8 r12 = 0x00000001 copyin() at copyin+0x2e4 pc = 0xc053e644 lr = 0xc053e3e0 (copyin+0x80) sp = 0xeda67d14 fp = 0x00000000 copyin() at copyin+0x80 pc = 0xc053e3e0 lr = 0xc053e3e0 (copyin+0x80) sp = 0xeda67d14 fp = 0x00000000 Unwind failure (no registers change) db> Crash #4 Setup as before, start was bob@www:~/stress2 % sh ./run.sh -a 20150901 20:14:22 all.cfg, elapsed 00:00:00 run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 20:14:23 Loop #1 udp: run time 0+00:02:00, incarnations 20, load 20, verbose 1 badcode: run time 0+00:02:00, incarnations 18, load 20, verbose 1 creat: run time 0+00:02:00, incarnations 16, load 80, verbose 1 mmap: run time 0+00:02:00, incarnations 8, load 20, verbose 1 swap: run time 0+00:02:00, incarnations 10, load 80, verbose 1 mkdir: run time 0+00:02:00, incarnations 5, load 80, verbose 1 rename: run time 0+00:02:00, incarnations 10, load 20, verbose 1 Curious development at: 20:36:22 Loop #2 rw: run time 0+00:02:00, incarnations 4, load 100, verbose 1 mkdir: run time 0+00:02:00, incarnations 3, load 80, verbose 1 /tmp: write failed, filesystem is full rw: write(p01317), rw.c:152: No space left on device Last words were: 23:16:39 Loop #1 swap: run time 0+00:00:15, incarnations 16, load 80, verbose 1 syscall: run time 0+00:00:15, incarnations 14, load 100, verbose 1 Console and backtrace follow. warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII read timeout panic: vm_fault: fault on nofault entry, addr: c42c6000 cpuid = 0 KDB: enter: panic [ thread pid 3456 tid 100172 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 3456 tid 100172 td 0xc4a64360 db_trace_self() at db_trace_self pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) sp = 0xed5da638 fp = 0xed5da650 r10 = 0xc07885f8 db_stack_trace() at db_stack_trace+0x108 pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) sp = 0xed5da658 fp = 0xed5da6f8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r10 = 0xc07885f8 db_command() at db_command+0x388 pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) sp = 0xed5da700 fp = 0xed5da710 r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 r6 = 0xc07885e4 r7 = 0xed5da8e0 r8 = 0xc077d620 r9 = 0xc0693fa4 r10 = 0xc077d624 db_command_loop() at db_command_loop+0x74 pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) sp = 0xed5da718 fp = 0xed5da830 r4 = 0x00000000 r5 = 0xc07885f0 r6 = 0xc077d648 r10 = 0xc077d624 db_trap() at db_trap+0x108 pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) sp = 0xed5da838 fp = 0xed5da860 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc077d648 r7 = 0xed5da8e0 kdb_trap() at kdb_trap+0x184 pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) sp = 0xed5da868 fp = 0xed5da8d8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc055b728 r7 = 0xe7ffffff r8 = 0xc4a64360 r9 = 0xc02eadf8 r10 = 0xed5da8e0 undefinedinstruction() at undefinedinstruction+0x344 pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) sp = 0xed5da8e0 fp = 0xed5da978 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xed5da9bc r9 = 0xc078a3a0 r10 = 0xc4a64360 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) sp = 0xed5da970 fp = 0xed5da978 r0 = 0xc077d634 r1 = 0x00000000 r2 = 0xed5da8a4 r3 = 0xc05cfbc0 r4 = 0xc05cbafb r5 = 0x00000001 r6 = 0xc076e0e0 r7 = 0xc076e278 r8 = 0xed5da9bc r9 = 0xc078a3a0 r10 = 0xc4a64360 r12 = 0xc06aed58 $a.8() at $a.8 pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) sp = 0xed5da980 fp = 0xed5da9a0 r4 = 0x00000100 r10 = 0xc4a64360 vpanic() at vpanic+0x164 pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) sp = 0xed5da9a8 fp = 0xed5da9b0 r4 = 0xc097e000 r5 = 0xed5daadc r6 = 0xed5daad0 r7 = 0xc05f7991 r8 = 0xc42c6000 r9 = 0x00000000 r10 = 0x000007c0 kproc_shutdown() at kproc_shutdown pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) sp = 0xed5da9b8 fp = 0xed5dab30 r4 = 0xed5daadc r5 = 0xed5da9bc vm_fault_dirty() at vm_fault_dirty pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) sp = 0xed5dab38 fp = 0xed5dab58 r4 = 0x00000002 r5 = 0xc4a64360 r6 = 0xc42c6000 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xc078e1f8 vm_fault() at vm_fault+0x88 pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) sp = 0xed5dab60 fp = 0xed5dac00 r4 = 0xed5dac08 r5 = 0x00000000 r6 = 0x0000000f r7 = 0x0000000f r8 = 0xc42c6065 r9 = 0xc4a64360 r10 = 0x00000013 abort_handler() at abort_handler+0x400 pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) sp = 0xed5dac08 fp = 0xed5dad20 r4 = 0xed5daea8 r5 = 0xc0541b90 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc4a64360 r9 = 0xc078a010 r10 = 0xed5dad98 exception_exit() at exception_exit pc = 0xc05450f4 lr = 0xc034a7d4 (namei+0x108) sp = 0xed5dac9c fp = 0xed5dad20 r0 = 0xc42c6065 r1 = 0xc5372400 r2 = 0x00000400 r3 = 0xed5dad98 r4 = 0xed5daea8 r5 = 0xc0541b90 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc4a64360 r9 = 0xc078a010 r10 = 0xed5dad98 r12 = 0x00000001 copyinstr() at copyinstr+0x28 pc = 0xc0541af0 lr = 0xc034a7d4 (namei+0x108) sp = 0xed5dac9c fp = 0xed5dad20 namei() at namei+0x108 pc = 0xc034a7d4 lr = 0xc0338d84 (sys___acl_aclcheck_file+0x50) sp = 0xed5dad28 fp = 0xed5dade8 r4 = 0xc4a64360 r5 = 0xed5dae08 r6 = 0xed5dad40 r7 = 0x00000000 r8 = 0xed5dae00 r9 = 0xc078a010 r10 = 0xbfbffac0 sys___acl_aclcheck_file() at sys___acl_aclcheck_file+0x50 pc = 0xc0338d84 lr = 0xc055a760 (swi_handler+0x2c8) sp = 0xed5dadf0 fp = 0xed5dae50 r4 = 0xc4a64360 r5 = 0xc4a74700 r6 = 0x00000000 r10 = 0xbfbffac0 swi_handler() at swi_handler+0x2c8 pc = 0xc055a760 lr = 0xc0545084 (swi_exit) sp = 0xed5dae58 fp = 0xbfbff940 r4 = 0x4faeba54 r5 = 0x46ba5d64 r6 = 0xbfbff8f0 r7 = 0x00000000 r8 = 0xbfbffac8 r9 = 0x00000000 r10 = 0xbfbffac0 swi_exit() at swi_exit pc = 0xc0545084 lr = 0xc0545084 (swi_exit) sp = 0xed5dae58 fp = 0xbfbff940 db> One possible experiment is to separate the stress tests, to see if the swap exercises alone can generate the crash. Are there more fruitful things to try? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Thu Sep 3 00:33:35 2015 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 92E419C80BF for ; Thu, 3 Sep 2015 00:33:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 48F3215DD for ; Thu, 3 Sep 2015 00:33:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgx61 with SMTP id 61so17549226qgx.3 for ; Wed, 02 Sep 2015 17:33:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xHhrckcpUsDsOPATQELGjTnz5CLMRA03noaczZgC0PM=; b=ZxMIVGoETEIgr2cO+vCijgfySg+ocCzkPFdVt4sny5fAUUyyO5M/jD8ltEZJPgEHE0 TixZLF+l8TSndC1m+dmNRB26HheEAjD5RZoTglt0bJAnoFVFz6dCAoTdYtBnnq/4S9rk 7hA/tydZ2S5qZhSCk6lk4ogd1Tt/weFYtd+HOskQhB4vPH4FjbUl3kyy4E+V16Wrjvxc RXmqYyAfoQfqjsmJGGnP3uJBjr2S+DGhXl6cdnLS7J0jnNGktunD0waLITi0jWTcxE1V mKYgY/oKayD4THjI+WIDr7P5V70qmjcFR1WWQYeLIubx2BgeoERcFMgiBVblhO/q9JfA +veg== X-Gm-Message-State: ALoCoQl80Xy4eWlrWhizhagYL5z5R36foALsO7zyzGphM5MAygs43GQPGSqWfBpysMsRSwahApEv MIME-Version: 1.0 X-Received: by 10.140.238.76 with SMTP id j73mr66497602qhc.43.1441240005610; Wed, 02 Sep 2015 17:26:45 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.164 with HTTP; Wed, 2 Sep 2015 17:26:45 -0700 (PDT) X-Originating-IP: [2607:fb90:12c:a455:0:11:f52d:e501] Received: by 10.140.80.164 with HTTP; Wed, 2 Sep 2015 17:26:45 -0700 (PDT) In-Reply-To: <20150903001037.GC33831@www.zefox.net> References: <20150903001037.GC33831@www.zefox.net> Date: Wed, 2 Sep 2015 18:26:45 -0600 X-Google-Sender-Auth: Rs0kRzDJ7_Pzsalb8DuivTNYYEE Message-ID: Subject: Re: Reproducible crashes on RPI2 under 11-CURRENT using stress2 From: Warner Losh To: bob prohaska Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 00:33:35 -0000 The interrupt controller code is not SMP safe. It needs to be fixed or you'll see instability under load. Stuff like these crashes. Run a UP kernel if you need to do high loads. Warner On Sep 2, 2015 6:10 PM, "bob prohaska" wrote: > > > It seems possible to cause relatively reproducible crashes on RPI2 under > 11-CURRENT using Peter Holm's stress2 suite. Below are console output > and backtrace of four crashes produced in the space of one day. > > To my surprise, all four seem related to virtual memory. How, or if, > that's related to the crashes seen during build of the OS is unclear, > since those seemed related to writing to the microSD card. > > FreeBSD 11.0-CURRENT (RPI2) #48 r287318M: Mon Aug 31 20:02:27 PDT 2015 > > Crash #1 > > Triggered by stress2, invocation > sh ./run.sh -a > stress2 started at 11:57:20, last output lines were > > 14:51:14 Loop #1 > swap: run time 0+00:00:15, incarnations 30, load 80, verbose 1 > syscall: run time 0+00:00:15, incarnations 18, load 100, verbose 1 > > The smsc0 warnings began a few minutes after stress2 was started. > > Console output and backtrace: > smsc0: warning: MII is busy > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > panic: vm_fault: fault on nofault entry, addr: d1a2f000 > cpuid = 0 > KDB: enter: panic > [ thread pid 5372 tid 100149 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 5372 tid 100149 td 0xc4a8b360 > db_trace_self() at db_trace_self > pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) > sp = 0xed605730 fp = 0xed605748 > r10 = 0xc07885f8 > db_stack_trace() at db_stack_trace+0x108 > pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) > sp = 0xed605750 fp = 0xed6057f0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r10 = 0xc07885f8 > db_command() at db_command+0x388 > pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) > sp = 0xed6057f8 fp = 0xed605808 > r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 > r6 = 0xc07885e4 r7 = 0xed6059d8 > r8 = 0xc077d620 r9 = 0xc0693fa4 > r10 = 0xc077d624 > db_command_loop() at db_command_loop+0x74 > pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) > sp = 0xed605810 fp = 0xed605928 > r4 = 0x00000000 r5 = 0xc07885f0 > r6 = 0xc077d648 r10 = 0xc077d624 > db_trap() at db_trap+0x108 > pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) > sp = 0xed605930 fp = 0xed605958 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc077d648 r7 = 0xed6059d8 > kdb_trap() at kdb_trap+0x184 > pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) > sp = 0xed605960 fp = 0xed6059d0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc055b728 r7 = 0xe7ffffff > r8 = 0xc4a8b360 r9 = 0xc02eadf8 > r10 = 0xed6059d8 > undefinedinstruction() at undefinedinstruction+0x344 > pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) > sp = 0xed6059d8 fp = 0xed605a70 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xed605ab4 r9 = 0xc078a3a0 > r10 = 0xc4a8b360 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) > sp = 0xed605a68 fp = 0xed605a70 > r0 = 0xc077d634 r1 = 0x00000000 > r2 = 0xed60599c r3 = 0xc05cfbc0 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xed605ab4 r9 = 0xc078a3a0 > r10 = 0xc4a8b360 r12 = 0xc06aed58 > $a.8() at $a.8 > pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) > sp = 0xed605a78 fp = 0xed605a98 > r4 = 0x00000100 r10 = 0xc4a8b360 > vpanic() at vpanic+0x164 > pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) > sp = 0xed605aa0 fp = 0xed605aa8 > r4 = 0xc097e000 r5 = 0xed605bd4 > r6 = 0xed605bc8 r7 = 0xc05f7991 > r8 = 0xd1a2f000 r9 = 0x00000000 > r10 = 0x000007c0 > kproc_shutdown() at kproc_shutdown > pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) > sp = 0xed605ab0 fp = 0xed605c28 > r4 = 0xed605bd4 r5 = 0xed605ab4 > vm_fault_dirty() at vm_fault_dirty > pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) > sp = 0xed605c30 fp = 0xed605c50 > r4 = 0x00000002 r5 = 0xc4a8b360 > r6 = 0xd1a2f000 r7 = 0x00000000 > r8 = 0x00000001 r9 = 0xc078e1f8 > vm_fault() at vm_fault+0x88 > pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) > sp = 0xed605c58 fp = 0xed605cf8 > r4 = 0xed605d00 r5 = 0x00000000 > r6 = 0x00000007 r7 = 0x00000007 > r8 = 0xd1a2fb00 r9 = 0xc4a8b360 > r10 = 0x00000013 > abort_handler() at abort_handler+0x400 > pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) > sp = 0xed605d00 fp = 0x00000000 > r4 = 0xc4a8b360 r5 = 0xed605e08 > r6 = 0xed605dc8 r7 = 0x00000000 > r8 = 0xed605e00 r9 = 0xc078a010 > r10 = 0xed605ea8 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xed605d94 fp = 0x00000000 > r0 = 0xd1a2fb00 r1 = 0xed605dc8 > r2 = 0x00000010 r3 = 0x00000001 > r4 = 0xc4a8b360 r5 = 0xed605e08 > r6 = 0xed605dc8 r7 = 0x00000000 > r8 = 0xed605e00 r9 = 0xc078a010 > r10 = 0xed605ea8 r12 = 0x00000001 > copyin() at copyin+0x2e4 > pc = 0xc053e644 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xed605d94 fp = 0x00000000 > copyin() at copyin+0x80 > pc = 0xc053e3e0 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xed605d94 fp = 0x00000000 > Unwind failure (no registers changed) > db> > > Crash #2 > > Stress2 started as above. > 20150901 15:14:56 all.cfg, elapsed 00:00:01 > Last words from stress2 > 17:18:09 Loop #1 > swap: run time 0+00:00:15, incarnations 23, load 80, verbose 1 > syscall: run time 0+00:00:15, incarnations 17, load 100, verbose 1 > > Console and backtrace follow: > > smsc0: warning: MII is busy > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to write register 0x114 > panic: vm_fault: fault on nofault entry, addr: c48ee000 > cpuid = 3 > KDB: enter: panic > [ thread pid 4860 tid 100234 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 4860 tid 100234 td 0xc4c11a20 > db_trace_self() at db_trace_self > pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) > sp = 0xed7bef40 fp = 0xed7bef58 > r10 = 0xc07885f8 > db_stack_trace() at db_stack_trace+0x108 > pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) > sp = 0xed7bef60 fp = 0xed7bf000 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r10 = 0xc07885f8 > db_command() at db_command+0x388 > pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) > sp = 0xed7bf008 fp = 0xed7bf018 > r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 > r6 = 0xc07885e4 r7 = 0xed7bf1e8 > r8 = 0xc077d620 r9 = 0xc0693fa4 > r10 = 0xc077d624 > db_command_loop() at db_command_loop+0x74 > pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) > sp = 0xed7bf020 fp = 0xed7bf138 > r4 = 0x00000000 r5 = 0xc07885f0 > r6 = 0xc077d648 r10 = 0xc077d624 > db_trap() at db_trap+0x108 > pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) > sp = 0xed7bf140 fp = 0xed7bf168 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc077d648 r7 = 0xed7bf1e8 > kdb_trap() at kdb_trap+0x184 > pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) > sp = 0xed7bf170 fp = 0xed7bf1e0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc055b728 r7 = 0xe7ffffff > r8 = 0xc4c11a20 r9 = 0xc02eadf8 > r10 = 0xed7bf1e8 > undefinedinstruction() at undefinedinstruction+0x344 > pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) > sp = 0xed7bf1e8 fp = 0xed7bf280 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xed7bf2c4 r9 = 0xc078a3a0 > r10 = 0xc4c11a20 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) > sp = 0xed7bf278 fp = 0xed7bf280 > r0 = 0xc077d634 r1 = 0x00000000 > r2 = 0xed7bf1ac r3 = 0xc05cfbc0 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xed7bf2c4 r9 = 0xc078a3a0 > r10 = 0xc4c11a20 r12 = 0xc06aed58 > $a.8() at $a.8 > pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) > sp = 0xed7bf288 fp = 0xed7bf2a8 > r4 = 0x00000100 r10 = 0xc4c11a20 > vpanic() at vpanic+0x164 > pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) > sp = 0xed7bf2b0 fp = 0xed7bf2b8 > r4 = 0xc097e000 r5 = 0xed7bf3e4 > r6 = 0xed7bf3d8 r7 = 0xc05f7991 > r8 = 0xc48ee000 r9 = 0x00000000 > r10 = 0x000007c0 > kproc_shutdown() at kproc_shutdown > pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) > sp = 0xed7bf2c0 fp = 0xed7bf438 > r4 = 0xed7bf3e4 r5 = 0xed7bf2c4 > vm_fault_dirty() at vm_fault_dirty > pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) > sp = 0xed7bf440 fp = 0xed7bf460 > r4 = 0x00000002 r5 = 0xc4c11a20 > r6 = 0xc48ee000 r7 = 0x00000000 > r8 = 0x00000001 r9 = 0xc078e1f8 > vm_fault() at vm_fault+0x88 > pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) > sp = 0xed7bf468 fp = 0xed7bf508 > r4 = 0xed7bf510 r5 = 0x00000000 > r6 = 0x0000000f r7 = 0x0000000f > r8 = 0xc48ee4fc r9 = 0xc4c11a20 > r10 = 0x00000013 > abort_handler() at abort_handler+0x400 > pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) > sp = 0xed7bf510 fp = 0x00000000 > r4 = 0xed7bfe08 r5 = 0xc4c11a20 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xed7bfe00 r9 = 0xc078a010 > r10 = 0xed7bfea8 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xed7bf5a4 fp = 0x00000000 > r0 = 0xc48ee4fc r1 = 0xed7bf5c0 > r2 = 0x00000004 r3 = 0x00000001 > r4 = 0xed7bfe08 r5 = 0xc4c11a20 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xed7bfe00 r9 = 0xc078a010 > r10 = 0xed7bfea8 r12 = 0x00000001 > copyin() at copyin+0x2e4 > pc = 0xc053e644 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xed7bf5a4 fp = 0x00000000 > copyin() at copyin+0x80 > pc = 0xc053e3e0 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xed7bf5a4 fp = 0x00000000 > Unwind failure (no registers changed) > db> > > Crash #3 > Setup as before: Reboot, fsck-fy until filesystem was clean, reboot to > multi-user > Stress2 invoked with sh ./run.shl-a, initial terminal output was > 20150901 17:37:06 all.cfg, elapsed 00:00:00 > run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 > 17:37:06 Loop #1 > udp: run time 0+00:02:00, incarnations 16, load 20, verbose 1 > mkdir: run time 0+00:02:00, incarnations 1, load 80, verbose 1 > mkfifo: run time 0+00:02:00, incarnations 8, load 20, verbose 1 > symlink: run time 0+00:02:00, incarnations 7, load 20, verbose 1 > swap: run time 0+00:02:00, incarnations 38, load 80, verbose 1 > mmap: run time 0+00:02:00, incarnations 2, load 20, verbose 1 > thr1: run time 0+00:02:00, incarnations 12, load 20, verbose 1 > > An intermediate output which looks odd: > > 19:08:25 Loop #1 > mkdir: run time 0+00:02:00, incarnations 5, load 80, verbose 1 > tcp: run time 0+00:02:00, incarnations 12, load 20, verbose 1 > thr1: run time 0+00:02:00, incarnations 16, load 20, verbose 1 > rw: run time 0+00:02:00, incarnations 6, load 70, verbose 1 > creat: run time 0+00:02:00, incarnations 12, load 80, verbose 1 > tcp: write(3), tcp.c:146: Connection reset by peer > > > > 20150901 19:14:45 pty.cfg, elapsed 01:37:39 > run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 > > Last words were: > > 20150901 19:30:31 syscall.cfg, elapsed 01:53:24 > run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 > 19:30:36 Loop #1 > > Console output and backtrace: > smsc0: warning: MII is busy > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to write register 0x114 > panic: vm_fault: fault on nofault entry, addr: c8ace000 > cpuid = 2 > KDB: enter: panic > [ thread pid 3146 tid 100747 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 3146 tid 100747 td 0xc4fe3360 > db_trace_self() at db_trace_self > pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) > sp = 0xeda676b0 fp = 0xeda676c8 > r10 = 0xc07885f8 > db_stack_trace() at db_stack_trace+0x108 > pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) > sp = 0xeda676d0 fp = 0xeda67770 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r10 = 0xc07885f8 > db_command() at db_command+0x388 > pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) > sp = 0xeda67778 fp = 0xeda67788 > r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 > r6 = 0xc07885e4 r7 = 0xeda67958 > r8 = 0xc077d620 r9 = 0xc0693fa4 > r10 = 0xc077d624 > db_command_loop() at db_command_loop+0x74 > pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) > sp = 0xeda67790 fp = 0xeda678a8 > r4 = 0x00000000 r5 = 0xc07885f0 > r6 = 0xc077d648 r10 = 0xc077d624 > db_trap() at db_trap+0x108 > pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) > sp = 0xeda678b0 fp = 0xeda678d8 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc077d648 r7 = 0xeda67958 > kdb_trap() at kdb_trap+0x184 > pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) > sp = 0xeda678e0 fp = 0xeda67950 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc055b728 r7 = 0xe7ffffff > r8 = 0xc4fe3360 r9 = 0xc02eadf8 > r10 = 0xeda67958 > undefinedinstruction() at undefinedinstruction+0x344 > pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) > sp = 0xeda67958 fp = 0xeda679f0 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xeda67a34 r9 = 0xc078a3a0 > r10 = 0xc4fe3360 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) > sp = 0xeda679e8 fp = 0xeda679f0 > r0 = 0xc077d634 r1 = 0x00000000 > r2 = 0xeda6791c r3 = 0xc05cfbc0 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xeda67a34 r9 = 0xc078a3a0 > r10 = 0xc4fe3360 r12 = 0xc06aed58 > $a.8() at $a.8 > pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) > sp = 0xeda679f8 fp = 0xeda67a18 > r4 = 0x00000100 r10 = 0xc4fe3360 > vpanic() at vpanic+0x164 > pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) > sp = 0xeda67a20 fp = 0xeda67a28 > r4 = 0xc097e000 r5 = 0xeda67b54 > r6 = 0xeda67b48 r7 = 0xc05f7991 > r8 = 0xc8ace000 r9 = 0x00000000 > r10 = 0x000007c0 > kproc_shutdown() at kproc_shutdown > pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) > sp = 0xeda67a30 fp = 0xeda67ba8 > r4 = 0xeda67b54 r5 = 0xeda67a34 > vm_fault_dirty() at vm_fault_dirty > pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) > sp = 0xeda67bb0 fp = 0xeda67bd0 > r4 = 0x00000002 r5 = 0xc4fe3360 > r6 = 0xc8ace000 r7 = 0x00000000 > r8 = 0x00000001 r9 = 0xc078e1f8 > vm_fault() at vm_fault+0x88 > pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) > sp = 0xeda67bd8 fp = 0xeda67c78 > r4 = 0xeda67c80 r5 = 0x00000000 > r6 = 0x00000007 r7 = 0x00000007 > r8 = 0xc8ace554 r9 = 0xc4fe3360 > r10 = 0x00000013 > abort_handler() at abort_handler+0x400 > pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) > sp = 0xeda67c80 fp = 0x00000000 > r4 = 0xeda67e08 r5 = 0xc4fe3360 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xeda67e00 r9 = 0xc078a010 > r10 = 0xeda67ea8 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xeda67d14 fp = 0x00000000 > r0 = 0xc8ace554 r1 = 0xeda67d44 > r2 = 0x0000001c r3 = 0x00000001 > r4 = 0xeda67e08 r5 = 0xc4fe3360 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xeda67e00 r9 = 0xc078a010 > r10 = 0xeda67ea8 r12 = 0x00000001 > copyin() at copyin+0x2e4 > pc = 0xc053e644 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xeda67d14 fp = 0x00000000 > copyin() at copyin+0x80 > pc = 0xc053e3e0 lr = 0xc053e3e0 (copyin+0x80) > sp = 0xeda67d14 fp = 0x00000000 > Unwind failure (no registers change) > db> > Crash #4 > > Setup as before, start was > bob@www:~/stress2 % sh ./run.sh -a > 20150901 20:14:22 all.cfg, elapsed 00:00:00 > run: run time 0+00:05:00, incarnations 1, load 100, verbose 1 > 20:14:23 Loop #1 > udp: run time 0+00:02:00, incarnations 20, load 20, verbose 1 > badcode: run time 0+00:02:00, incarnations 18, load 20, verbose 1 > creat: run time 0+00:02:00, incarnations 16, load 80, verbose 1 > mmap: run time 0+00:02:00, incarnations 8, load 20, verbose 1 > swap: run time 0+00:02:00, incarnations 10, load 80, verbose 1 > mkdir: run time 0+00:02:00, incarnations 5, load 80, verbose 1 > rename: run time 0+00:02:00, incarnations 10, load 20, verbose 1 > > Curious development at: > 20:36:22 Loop #2 > rw: run time 0+00:02:00, incarnations 4, load 100, verbose 1 > mkdir: run time 0+00:02:00, incarnations 3, load 80, verbose 1 > > /tmp: write failed, filesystem is full > rw: write(p01317), rw.c:152: No space left on device > > Last words were: > 23:16:39 Loop #1 > swap: run time 0+00:00:15, incarnations 16, load 80, verbose 1 > syscall: run time 0+00:00:15, incarnations 14, load 100, verbose 1 > > Console and backtrace follow. > warning: MII is busy > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII read timeout > panic: vm_fault: fault on nofault entry, addr: c42c6000 > cpuid = 0 > KDB: enter: panic > [ thread pid 3456 tid 100172 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 3456 tid 100172 td 0xc4a64360 > db_trace_self() at db_trace_self > pc = 0xc0543a6c lr = 0xc014103c (db_stack_trace+0x108) > sp = 0xed5da638 fp = 0xed5da650 > r10 = 0xc07885f8 > db_stack_trace() at db_stack_trace+0x108 > pc = 0xc014103c lr = 0xc0140a88 (db_command+0x388) > sp = 0xed5da658 fp = 0xed5da6f8 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r10 = 0xc07885f8 > db_command() at db_command+0x388 > pc = 0xc0140a88 lr = 0xc01406f0 (db_command_loop+0x74) > sp = 0xed5da700 fp = 0xed5da710 > r4 = 0xc05aa9d8 r5 = 0xc05cbaa6 > r6 = 0xc07885e4 r7 = 0xed5da8e0 > r8 = 0xc077d620 r9 = 0xc0693fa4 > r10 = 0xc077d624 > db_command_loop() at db_command_loop+0x74 > pc = 0xc01406f0 lr = 0xc0143220 (db_trap+0x108) > sp = 0xed5da718 fp = 0xed5da830 > r4 = 0x00000000 r5 = 0xc07885f0 > r6 = 0xc077d648 r10 = 0xc077d624 > db_trap() at db_trap+0x108 > pc = 0xc0143220 lr = 0xc02eb6a0 (kdb_trap+0x184) > sp = 0xed5da838 fp = 0xed5da860 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc077d648 r7 = 0xed5da8e0 > kdb_trap() at kdb_trap+0x184 > pc = 0xc02eb6a0 lr = 0xc055bb1c (undefinedinstruction+0x344) > sp = 0xed5da868 fp = 0xed5da8d8 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc055b728 r7 = 0xe7ffffff > r8 = 0xc4a64360 r9 = 0xc02eadf8 > r10 = 0xed5da8e0 > undefinedinstruction() at undefinedinstruction+0x344 > pc = 0xc055bb1c lr = 0xc05450f4 (exception_exit) > sp = 0xed5da8e0 fp = 0xed5da978 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xed5da9bc r9 = 0xc078a3a0 > r10 = 0xc4a64360 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc02eade8 (kdb_enter+0x48) > sp = 0xed5da970 fp = 0xed5da978 > r0 = 0xc077d634 r1 = 0x00000000 > r2 = 0xed5da8a4 r3 = 0xc05cfbc0 > r4 = 0xc05cbafb r5 = 0x00000001 > r6 = 0xc076e0e0 r7 = 0xc076e278 > r8 = 0xed5da9bc r9 = 0xc078a3a0 > r10 = 0xc4a64360 r12 = 0xc06aed58 > $a.8() at $a.8 > pc = 0xc02eadfc lr = 0xc02adf98 (vpanic+0x164) > sp = 0xed5da980 fp = 0xed5da9a0 > r4 = 0x00000100 r10 = 0xc4a64360 > vpanic() at vpanic+0x164 > pc = 0xc02adf98 lr = 0xc02adfe4 (kproc_shutdown) > sp = 0xed5da9a8 fp = 0xed5da9b0 > r4 = 0xc097e000 r5 = 0xed5daadc > r6 = 0xed5daad0 r7 = 0xc05f7991 > r8 = 0xc42c6000 r9 = 0x00000000 > r10 = 0x000007c0 > kproc_shutdown() at kproc_shutdown > pc = 0xc02adfe4 lr = 0xc0516afc (vm_fault_dirty) > sp = 0xed5da9b8 fp = 0xed5dab30 > r4 = 0xed5daadc r5 = 0xed5da9bc > vm_fault_dirty() at vm_fault_dirty > pc = 0xc0516afc lr = 0xc0514dec (vm_fault+0x88) > sp = 0xed5dab38 fp = 0xed5dab58 > r4 = 0x00000002 r5 = 0xc4a64360 > r6 = 0xc42c6000 r7 = 0x00000000 > r8 = 0x00000001 r9 = 0xc078e1f8 > vm_fault() at vm_fault+0x88 > pc = 0xc0514dec lr = 0xc055af04 (abort_handler+0x400) > sp = 0xed5dab60 fp = 0xed5dac00 > r4 = 0xed5dac08 r5 = 0x00000000 > r6 = 0x0000000f r7 = 0x0000000f > r8 = 0xc42c6065 r9 = 0xc4a64360 > r10 = 0x00000013 > abort_handler() at abort_handler+0x400 > pc = 0xc055af04 lr = 0xc05450f4 (exception_exit) > sp = 0xed5dac08 fp = 0xed5dad20 > r4 = 0xed5daea8 r5 = 0xc0541b90 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc4a64360 r9 = 0xc078a010 > r10 = 0xed5dad98 > exception_exit() at exception_exit > pc = 0xc05450f4 lr = 0xc034a7d4 (namei+0x108) > sp = 0xed5dac9c fp = 0xed5dad20 > r0 = 0xc42c6065 r1 = 0xc5372400 > r2 = 0x00000400 r3 = 0xed5dad98 > r4 = 0xed5daea8 r5 = 0xc0541b90 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc4a64360 r9 = 0xc078a010 > r10 = 0xed5dad98 r12 = 0x00000001 > copyinstr() at copyinstr+0x28 > pc = 0xc0541af0 lr = 0xc034a7d4 (namei+0x108) > sp = 0xed5dac9c fp = 0xed5dad20 > namei() at namei+0x108 > pc = 0xc034a7d4 lr = 0xc0338d84 (sys___acl_aclcheck_file+0x50) > sp = 0xed5dad28 fp = 0xed5dade8 > r4 = 0xc4a64360 r5 = 0xed5dae08 > r6 = 0xed5dad40 r7 = 0x00000000 > r8 = 0xed5dae00 r9 = 0xc078a010 > r10 = 0xbfbffac0 > sys___acl_aclcheck_file() at sys___acl_aclcheck_file+0x50 > pc = 0xc0338d84 lr = 0xc055a760 (swi_handler+0x2c8) > sp = 0xed5dadf0 fp = 0xed5dae50 > r4 = 0xc4a64360 r5 = 0xc4a74700 > r6 = 0x00000000 r10 = 0xbfbffac0 > swi_handler() at swi_handler+0x2c8 > pc = 0xc055a760 lr = 0xc0545084 (swi_exit) > sp = 0xed5dae58 fp = 0xbfbff940 > r4 = 0x4faeba54 r5 = 0x46ba5d64 > r6 = 0xbfbff8f0 r7 = 0x00000000 > r8 = 0xbfbffac8 r9 = 0x00000000 > r10 = 0xbfbffac0 > swi_exit() at swi_exit > pc = 0xc0545084 lr = 0xc0545084 (swi_exit) > sp = 0xed5dae58 fp = 0xbfbff940 > db> > > One possible experiment is to separate the stress tests, to see if the swap > exercises alone can generate the crash. Are there more fruitful things to > try? > > Thanks for reading, > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Sep 3 14:16:19 2015 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 745239C9E8A for ; Thu, 3 Sep 2015 14:16:19 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38E161E87 for ; Thu, 3 Sep 2015 14:16:19 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by igbkq10 with SMTP id kq10so49958603igb.0 for ; Thu, 03 Sep 2015 07:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SCM9YXrtl5Q/lFKW7dNrmWPgjdFQzcOD9pbrExZ1Sr0=; b=cbhwNuScH7132IXDHD5Opb/TtwdiuEN6+oz7aGn5z5C3djVIaQ6i0k6qhRrk0TZoxH QSvN1EisChS0eUFCvHT6Khg5/9nP5C/jTW0JYDwuZSG8OUv2Q7pGxq7g/8jYb96QThAY 49BqpIKowd+bUTOA+GcybgMOoVp26WmVZR6wVrU/KFmYhOnaNIEk0pXqzO2WXb1JFJ6o fpVyBu6h2wRCUDLlGFQjmZ1cBsqKK/piUlesjRRpAg+jzQyFPak/kSkE0ujUGCVUmCP2 EIV/XMKY87W0cTRg8iMsMP6BnfP2xdUCPnesSKgRKVyL+kkgrDB4z1wUVsDCxsuerEYC 4bOw== MIME-Version: 1.0 X-Received: by 10.50.72.19 with SMTP id z19mr12917861igu.19.1441289778485; Thu, 03 Sep 2015 07:16:18 -0700 (PDT) Received: by 10.64.239.196 with HTTP; Thu, 3 Sep 2015 07:16:18 -0700 (PDT) In-Reply-To: <55E152C4.7010209@selasky.org> References: <55A7D8CE.4020809@selasky.org> <55B23276.8090703@selasky.org> <55B73113.2020308@selasky.org> <55B8AB76.7030603@selasky.org> <55B8B297.1010008@selasky.org> <20150729154516.GH78154@funkthat.com> <55B8F5EC.2050908@selasky.org> <46ad096c958.1a82a175@mail.schwarzes.net> <55B9C3E2.5040501@selasky.org> <46ae815c7c3.447237c8@mail.schwarzes.net> <46aece00b53.3c1cdc1f@mail.schwarzes.net> <55BB2A5F.9000502@selasky.org> <46baa16c4ce.6efd29ef@mail.schwarzes.net> <55CF31A1.5080205@selasky.org> <46ce372c895.20050775@mail.schwarzes.net> <46d0a4441bb.41f6f91d@mail.schwarzes.net> <55DD5C0A.2050401@selasky.org> <55E152C4.7010209@selasky.org> Date: Thu, 3 Sep 2015 16:16:18 +0200 Message-ID: Subject: Re: DWC OTG TX path optimisation for 11-current From: Svatopluk Kraus To: Hans Petter Selasky Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:16:19 -0000 On Sat, Aug 29, 2015 at 8:35 AM, Hans Petter Selasky wrote: > On 08/28/15 14:27, Svatopluk Kraus wrote: >> >> On Wed, Aug 26, 2015 at 8:26 AM, Hans Petter Selasky >> wrote: >>> >>> On 08/25/15 21:51, Andreas Schwarz wrote: >>>> >>>> >>>> On 24.08.15, Andreas Schwarz wrote: >>>> >>>>> With both kernels I was not able to reproduce the initial problem. >>>> >>>> >>>> >>>> By accident, today I run again into the problem (with r287086). 8( >>>> >>>> Aug 25 20:27:59 pizelot kernel: smsc0: warning: Failed to write register >>>> 0x114 >>>> Aug 25 20:45:32 pizelot kernel: smsc0: warning: Failed to read register >>>> 0x114 >>>> Aug 25 20:45:32 pizelot kernel: smsc0: warning: MII is busy >>>> Aug 25 20:46:08 pizelot kernel: smsc0: warning: Failed to write register >>>> 0x114 >>>> Aug 25 20:46:14 pizelot kernel: smsc0: warning: Failed to read register >>>> 0x114 >>>> Aug 25 20:46:14 pizelot kernel: smsc0: warning: MII is busy >>>> Aug 25 20:46:16 pizelot kernel: smsc0: warning: Failed to write register >>>> 0x114 >>>> Aug 25 20:46:46 pizelot kernel: smsc0: warning: Failed to read register >>>> 0x114 >>>> Aug 25 20:46:46 pizelot kernel: smsc0: warning: MII is busy >>>> [...] >>>> >>> >>> It might seem like some process is using all CPU on core 0, so that USB >>> doesn't get a chance to run. I would suggest maybe moving the DWC OTG >>> fast >>> IRQ handling to core #1. Is it possible you could enter kgdb, and poke >>> around which fast IRQ is doing work there? >>> >> >> Well, I finally found a courage ;) to hack dwc_otg driver to be able >> to inactivate it totally after trigger is pulled. And even then, if >> there was no interrupt and no timer on it, the problem survived. Thus, >> I thing that the driver is out of game. However, some small chance >> remains that the driver might corrupt something in kernel. But this >> indirect influence is, IMO, not likely. >> >> My subjective observation is that the slow system response can be >> caused by slow wake up from idle state. I have tried to change >> scheduler from ULE to BSD one with no MII warning and everything is >> okay result. And buildword was about one hour faster. Note that the >> trigger is very sensitive, so it can be just because system timing and >> many other things are different with different scheduler. >> >> Another obeservation is that in the bad system state, ipi rate is 10 >> times less (2 - 3 per a second) than in normal state (about 20 per a >> second) measured when system is 99% idle. >> >> Svata >> > > Hi, > > Maybe you could try to build an RPI kernel from projects/hps_head : > > https://svnweb.freebsd.org/base/projects/hps_head/ > > And test? > I disabled INVARIANTS and INVARIANT_SUPPORT options and tested it. It was not better. MII warnings were there and slow system response after buildworld finished too. The buildworld time was longer. FYI, my console is on uart. On first ssh session, "make -j6 buildworld" is run. On second ssh session, "systat -v" is run. On third ssh session, "top -P -S" is run. Usually, I do some subjective observation during first hour of buildworld. It seemed that disk was more often quite busy and consequently, cores were more often in idle state. Svata From owner-freebsd-arm@freebsd.org Thu Sep 3 14:16:32 2015 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 D86F09C9EB5 for ; Thu, 3 Sep 2015 14:16:32 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 99D5B1ED7 for ; Thu, 3 Sep 2015 14:16:32 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZXVJO-000LVD-GJ for freebsd-arm@freebsd.org; Thu, 03 Sep 2015 15:16:22 +0100 Date: Thu, 3 Sep 2015 15:16:22 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: some general questions regarding freebsd on rasp pi Message-ID: <20150903141622.GA42047@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150901155024.GA46253@potato.growveg.org> <20150902134931.GA2221@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150902134931.GA2221@potato.growveg.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:16:32 -0000 On Wed, Sep 02, 2015 at 02:49:31PM +0100, John wrote: > Just need to update ports and start building what I need. One answer i've not been able > to find - is it easy to clock the pi under freebsd? Looking for 1GHz > (think the ram is half this) in the grand tradition of answering myself, the way to do this with the rasp 2 hw.cpufreq.turbo=1 dev.cpu.0.freq=900 in /etc/sysctl.conf and reboot, or modify them directly. Now i have: # sysctl hw.cpufreq hw.cpufreq.temperature: 43312 hw.cpufreq.voltage_sdram_p: 1200000 hw.cpufreq.voltage_sdram_i: 1200000 hw.cpufreq.voltage_sdram_c: 1200000 hw.cpufreq.voltage_core: 1312500 hw.cpufreq.turbo: 1 hw.cpufreq.sdram_freq: 450000000 hw.cpufreq.core_freq: 250000000 hw.cpufreq.arm_freq: 900000000 and # sysctl dev.cpu dev.cpu.3.%parent: cpulist0 dev.cpu.3.%pnpinfo: name=cpu@3 compat=arm,cortex-a7 dev.cpu.3.%location: dev.cpu.3.%driver: cpu dev.cpu.3.%desc: Open Firmware CPU dev.cpu.2.%parent: cpulist0 dev.cpu.2.%pnpinfo: name=cpu@2 compat=arm,cortex-a7 dev.cpu.2.%location: dev.cpu.2.%driver: cpu dev.cpu.2.%desc: Open Firmware CPU dev.cpu.1.%parent: cpulist0 dev.cpu.1.%pnpinfo: name=cpu@1 compat=arm,cortex-a7 dev.cpu.1.%location: dev.cpu.1.%driver: cpu dev.cpu.1.%desc: Open Firmware CPU dev.cpu.0.temperature: 42.2C dev.cpu.0.freq_levels: 900/-1 600/-1 dev.cpu.0.freq: 900 dev.cpu.0.%parent: cpulist0 dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a7 dev.cpu.0.%location: dev.cpu.0.%driver: cpu dev.cpu.0.%desc: Open Firmware CPU dev.cpu.%parent: not sure if it can be cranked any more. Any ideas? -- John From owner-freebsd-arm@freebsd.org Thu Sep 3 14:27:55 2015 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 61AFD9CA2F1 for ; Thu, 3 Sep 2015 14:27:55 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A5F86D0 for ; Thu, 3 Sep 2015 14:27:55 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 7C3DC5B9; Thu, 3 Sep 2015 10:27:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: some general questions regarding freebsd on rasp pi From: Paul Mather In-Reply-To: <20150903141622.GA42047@potato.growveg.org> Date: Thu, 3 Sep 2015 10:27:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C8F46FD-ED2A-4B30-A10F-6A666A3E0816@gromit.dlib.vt.edu> References: <20150901155024.GA46253@potato.growveg.org> <20150902134931.GA2221@potato.growveg.org> <20150903141622.GA42047@potato.growveg.org> To: freebsd-arm , John X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:27:55 -0000 On Sep 3, 2015, at 10:16 AM, John = wrote: > On Wed, Sep 02, 2015 at 02:49:31PM +0100, John wrote: >=20 >> Just need to update ports and start building what I need. One answer = i've not been able >> to find - is it easy to clock the pi under freebsd? Looking for 1GHz=20= >> (think the ram is half this) >=20 > in the grand tradition of answering myself, the way to do this with = the rasp 2 >=20 > hw.cpufreq.turbo=3D1 > dev.cpu.0.freq=3D900 >=20 > in /etc/sysctl.conf and reboot, or modify them directly. Now i have: >=20 > # sysctl hw.cpufreq > hw.cpufreq.temperature: 43312 > hw.cpufreq.voltage_sdram_p: 1200000 > hw.cpufreq.voltage_sdram_i: 1200000 > hw.cpufreq.voltage_sdram_c: 1200000 > hw.cpufreq.voltage_core: 1312500 > hw.cpufreq.turbo: 1 > hw.cpufreq.sdram_freq: 450000000 > hw.cpufreq.core_freq: 250000000 > hw.cpufreq.arm_freq: 900000000 >=20 > and >=20 > # sysctl dev.cpu > dev.cpu.3.%parent: cpulist0 > dev.cpu.3.%pnpinfo: name=3Dcpu@3 compat=3Darm,cortex-a7 > dev.cpu.3.%location:=20 > dev.cpu.3.%driver: cpu > dev.cpu.3.%desc: Open Firmware CPU > dev.cpu.2.%parent: cpulist0 > dev.cpu.2.%pnpinfo: name=3Dcpu@2 compat=3Darm,cortex-a7 > dev.cpu.2.%location:=20 > dev.cpu.2.%driver: cpu > dev.cpu.2.%desc: Open Firmware CPU > dev.cpu.1.%parent: cpulist0 > dev.cpu.1.%pnpinfo: name=3Dcpu@1 compat=3Darm,cortex-a7 > dev.cpu.1.%location:=20 > dev.cpu.1.%driver: cpu > dev.cpu.1.%desc: Open Firmware CPU > dev.cpu.0.temperature: 42.2C > dev.cpu.0.freq_levels: 900/-1 600/-1 > dev.cpu.0.freq: 900 > dev.cpu.0.%parent: cpulist0 > dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a7 > dev.cpu.0.%location:=20 > dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: Open Firmware CPU > dev.cpu.%parent: FWIW, I believe that powerd is supported on the Raspberry Pi 2, so if = you add powerd_enable=3D"YES" to your /etc/rc.conf it will switch = between the two CPU frequencies depending upon CPU load. Cheers, Paul. From owner-freebsd-arm@freebsd.org Fri Sep 4 10:41:55 2015 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 53D5E9CA179 for ; Fri, 4 Sep 2015 10:41:55 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 45B2D1FB; Fri, 4 Sep 2015 10:41:55 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B8932335; Fri, 4 Sep 2015 10:41:55 +0000 (UTC) Date: Fri, 4 Sep 2015 10:41:54 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: tuexen@FreeBSD.org, mav@FreeBSD.org, delphij@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <277552279.26.1441363315714.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1046 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 10:41:55 -0000 FreeBSD_HEAD_arm64 - Build #1046 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1046/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1046/ch= anges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1046/con= sole Change summaries: 287457 by tuexen: Don't leak memory in an error case. MFC after:=091 week 287456 by tuexen: Add a NULL pointer check to silence the clang code analyzer. MFC after:=091 week 287455 by mav: Remove some dead code. 287454 by delphij: Fix build. The end of the build log: [...truncated 76015 lines...] rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I. -I/= usr/src/usr.sbin/config -std=3Dgnu99 config.c /usr/src/usr.sbin/config/ma= in.c lang.c /usr/src/usr.sbin/config/mkmakefile.c /usr/src/usr.sbin/config/= mkheaders.c /usr/src/usr.sbin/config/mkoptions.c kernconf.c --- depend_subdir_bsnmpd --- --- hast_tree.c --- --- usr.bin.depend__D --- echo elf2aout: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a >> .depen= d --- usr.sbin.depend__D --- cat /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.def | gensnmptree = -p hast_ --- depend_subdir_crashinfo --- =3D=3D=3D> usr.sbin/crashinfo (depend) --- depend_subdir_bsnmpd --- --- parse.c --- yacc -d -v /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hast= d/parse.y cp y.tab.c parse.c --- token.c --- lex -otoken.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/= hastd/token.l --- hast_oid.h --- cat /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.def | gensnmptree = -e begemotHast > hast_oid.h --- depend_subdir_cron --- --- depend_subdir_bsnmpd --- --- .depend --- --- depend_subdir_cron --- =3D=3D=3D> usr.sbin/cron (depend) --- depend_subdir_bsnmpd --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I/usr/= src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd -DHAVE_CAPSICU= M -DINET -DINET6 -DYY_NO_UNPUT -DYY_NO_INPUT -DSNMPTREE_TYPES -I. -std=3Dgn= u99 /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/ebu= f.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/hast_= compression.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/h= astd/hast_proto.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/hast_snmp.c /u= sr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/lzf.c /usr/= src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/nv.c parse.c /= usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/pjdlog.c /= usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/proto.c /u= sr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/proto_commo= n.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hast/../../../../sbin/hastd/proto= _uds.c token.c hast_tree.c --- depend_subdir_cron --- --- _sub.depend --- =3D=3D=3D> usr.sbin/cron/lib (depend) --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I/usr/= src/usr.sbin/cron/lib/../cron -DLOGIN_CAP -DPAM -std=3Dgnu99 /usr/src/usr= .sbin/cron/lib/entry.c /usr/src/usr.sbin/cron/lib/env.c /usr/src/usr.sbin/c= ron/lib/misc.c --- depend_subdir_config --- echo config: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a /usr/obj/arm= 64.aarch64/usr/src/tmp/usr/lib/libl.a /usr/obj/arm64.aarch64/usr/src/tmp/us= r/lib/libsbuf.a >> .depend --- depend_subdir_crunch --- =3D=3D=3D> usr.sbin/crunch (depend) --- _sub.depend --- =3D=3D=3D> usr.sbin/crunch/crunchgen (depend) --- depend_subdir_cron --- =3D=3D=3D> usr.sbin/cron/cron (depend) --- depend_subdir_crunch --- --- crunched_skel.c --- sh -e /usr/src/usr.sbin/crunch/crunchgen/mkskel.sh /usr/src/usr.sbin/crunch= /crunchgen/crunched_main.c >crunched_skel.c --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -std= =3Dgnu99 /usr/src/usr.sbin/crunch/crunchgen/crunchgen.c crunched_skel.c --- depend_subdir_cron --- --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -DLOGIN= _CAP -DPAM -std=3Dgnu99 /usr/src/usr.sbin/cron/cron/cron.c /usr/src/usr.s= bin/cron/cron/database.c /usr/src/usr.sbin/cron/cron/do_command.c /usr/src/= usr.sbin/cron/cron/job.c /usr/src/usr.sbin/cron/cron/user.c /usr/src/usr.sb= in/cron/cron/popen.c --- depend_subdir_crunch --- echo crunchgen: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a >> .depe= nd =3D=3D=3D> usr.sbin/crunch/crunchide (depend) --- depend_subdir_bsnmpd --- echo snmp_hast.so.6: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libutil.a >= > .depend --- depend_subdir_crunch --- --- .depend --- --- depend_subdir_bsnmpd --- =3D=3D=3D> usr.sbin/bsnmpd/modules/snmp_hostres (depend) --- depend_subdir_crunch --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -DNLIST= _ELF32 -DNLIST_ELF64 -std=3Dgnu99 /usr/src/usr.sbin/crunch/crunchide/crun= chide.c /usr/src/usr.sbin/crunch/crunchide/exec_elf32.c /usr/src/usr.sbin/c= runch/crunchide/exec_elf64.c --- depend_subdir_bsnmpd --- --- hostres_tree.c --- cat /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def | gensnm= ptree -p hostres_ --- hostres_oid.h --- cat /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def | gensnm= ptree -e host hrStorageOther hrStorageRam hrStorageVirtualMemory hrStorage= FixedDisk hrStorageRemovableDisk hrStorageFloppyDisk hrStorageCompactDisc = hrStorageRamDisk hrStorageFlashMemory hrStorageNetworkDisk hrDeviceOther h= rDeviceUnknown hrDeviceProcessor hrDeviceNetwork hrDevicePrinter hrDevice= DiskStorage hrDeviceVideo hrDeviceAudio hrDeviceCoprocessor hrDeviceKeyboa= rd hrDeviceModem hrDeviceParallelPort hrDevicePointing hrDeviceSerialPort= hrDeviceTape hrDeviceClock hrDeviceVolatileMemory hrDeviceNonVolatileMemo= ry hrFSOther hrFSUnknown hrFSBerkeleyFFS hrFSSys5FS hrFSFat hrFSHPFS hrFSH= FS hrFSMFS hrFSNTFS hrFSVNode hrFSJournaled hrFSiso9660 hrFSRockRidge hrFS= NFS hrFSNetware hrFSAFS hrFSDFS hrFSAppleshare hrFSRFS hrFSDGCFS hrFSBFS h= rFSFAT32 hrFSLinuxExt2 > hostres_oid.h --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -DNDEBU= G -I/usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_sourc= e -I. -std=3Dgnu99 /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_= begemot.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_device_tbl.= c /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c /= usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_fs_tbl.c /usr/src/usr.= sbin/bsnmpd/modules/snmp_hostres/hostres_network_tbl.c /usr/src/usr.sbin/bs= nmpd/modules/snmp_hostres/hostres_partition_tbl.c /usr/src/usr.sbin/bsnmpd/= modules/snmp_hostres/hostres_printer_tbl.c /usr/src/usr.sbin/bsnmpd/modules= /snmp_hostres/hostres_processor_tbl.c /usr/src/usr.sbin/bsnmpd/modules/snmp= _hostres/hostres_scalars.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/ho= stres_snmp.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_storage_= tbl.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_swinstalled_tbl= .c /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/host--- depend_subdir_cron= --- echo cron: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a /usr/obj/arm64= .aarch64/usr/src/usr.sbin/cron/lib/libcron.a /usr/obj/arm64.aarch64/usr/src= /tmp/usr/lib/libpam.a /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libutil.a = >> .depend --- depend_subdir_bsnmpd --- res_swrun_tbl.c /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/= common_source/printcap.c hostres_tree.c --- depend_subdir_cron --- =3D=3D=3D> usr.sbin/cron/crontab (depend) --- depend_subdir_crunch --- echo crunchide: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a >> .depe= nd --- depend_subdir_ctladm --- =3D=3D=3D> usr.sbin/ctladm (depend) --- depend_subdir_cron --- --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I/usr/= src/usr.sbin/cron/crontab/../cron -std=3Dgnu99 /usr/src/usr.sbin/cron/cro= ntab/crontab.c --- depend_subdir_ctladm --- --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I/usr/= src/usr.sbin/ctladm/../../sys -std=3Dgnu99 /usr/src/usr.sbin/ctladm/ctlad= m.c /usr/src/usr.sbin/ctladm/util.c /usr/src/usr.sbin/ctladm/../../sys/cam/= ctl/ctl_util.c /usr/src/usr.sbin/ctladm/../../sys/cam/ctl/ctl_scsi_all.c --- depend_subdir_cron --- echo crontab: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a /usr/obj/ar= m64.aarch64/usr/src/usr.sbin/cron/lib/libcron.a /usr/obj/arm64.aarch64/usr/= src/tmp/usr/lib/libmd.a /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libutil.= a >> .depend --- usr.bin.depend__D --- --- depend_subdir_elfcopy --- =3D=3D=3D> usr.bin/elfcopy (depend) --- depend_subdir_drill --- echo drill: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a /usr/obj/arm6= 4.aarch64/usr/src/tmp/usr/lib/libprivateldns.a /usr/obj/arm64.aarch64/usr/s= rc/tmp/usr/lib/libcrypto.a >> .depend --- usr.sbin.depend__D --- --- depend_subdir_ctld --- =3D=3D=3D> usr.sbin/ctld (depend) --- depend_subdir_ctladm --- /usr/src/usr.sbin/ctladm/ctladm.c:71:10: fatal error: 'cam/ctl/ctl_backend_= block.h' file not found #include ^ 1 error generated. --- usr.bin.depend__D --- --- depend_subdir_elfcopy --- --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I/usr/= src/usr.bin/elfcopy/../../contrib/elftoolchain/libelftc -I/usr/src/usr.bin/= elfcopy/../../contrib/elftoolchain/common -std=3Dgnu99 /usr/src/usr.bin/e= lfcopy/../../contrib/elftoolchain/elfcopy/archive.c /usr/src/usr.bin/elfcop= y/../../contrib/elftoolchain/elfcopy/ascii.c /usr/src/usr.bin/elfcopy/../..= /contrib/elftoolchain/elfcopy/binary.c /usr/src/usr.bin/elfcopy/../../contr= ib/elftoolchain/elfcopy/main.c /usr/src/usr.bin/elfcopy/../../contrib/elfto= olchain/elfcopy/sections.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolch= ain/elfcopy/segments.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/= elfcopy/symbols.c --- usr.sbin.depend__D --- --- depend_subdir_ctld --- --- parse.c --- yacc -d -v /usr/src/usr.sbin/ctld/parse.y cp y.tab.c parse.c --- token.c --- lex -otoken.c /usr/src/usr.sbin/ctld/token.l --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I/usr/= src/usr.sbin/ctld -I/usr/src/usr.sbin/ctld/../../sys -I/usr/src/usr.sbin/ct= ld/../../sys/cam/ctl -I/usr/src/usr.sbin/ctld/../../sys/dev/iscsi -std=3Dgn= u99 /usr/src/usr.sbin/ctld/chap.c /usr/src/usr.sbin/ctld/ctld.c /usr/src/= usr.sbin/ctld/discovery.c /usr/src/usr.sbin/ctld/isns.c /usr/src/usr.sbin/c= tld/kernel.c /usr/src/usr.sbin/ctld/keys.c /usr/src/usr.sbin/ctld/log.c /us= r/src/usr.sbin/ctld/login.c parse.c /usr/src/usr.sbin/ctld/pdu.c token.c --- depend_subdir_ctladm --- mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/usr.sbin/ctladm 1 error make[4]: stopped in /usr/src/usr.sbin/ctladm *** [depend_subdir_ctladm] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- usr.bin.depend__D --- echo objcopy: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a /usr/obj/ar= m64.aarch64/usr/src/tmp/usr/lib/libarchive.a /usr/obj/arm64.aarch64/usr/src= /lib/libelftc/libelftc.a /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libelf.= a >> .depend A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/usr.bin/elfcopy *** [depend_subdir_elfcopy] Error code 2 make[3]: stopped in /usr/src/usr.bin 1 error make[3]: stopped in /usr/src/usr.bin *** [usr.bin.depend__D] Error code 2 make[2]: stopped in /usr/src --- usr.sbin.depend__D --- --- depend_subdir_ctld --- /usr/src/usr.sbin/ctld/kernel.c:65:10: fatal error: 'cam/ctl/ctl_backend_bl= ock.h' file not found #include ^ 1 error generated. --- depend_subdir_bsnmpd --- echo snmp_hostres.so.6: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libkvm.a= /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libdevinfo.a /usr/obj/arm64.aar= ch64/usr/src/tmp/usr/lib/libm.a /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/= libgeom.a /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libmemstat.a >> .depen= d A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres *** [_sub.depend] Error code 2 make[5]: stopped in /usr/src/usr.sbin/bsnmpd/modules 1 error make[5]: stopped in /usr/src/usr.sbin/bsnmpd/modules *** [_sub.depend] Error code 2 make[4]: stopped in /usr/src/usr.sbin/bsnmpd 1 error make[4]: stopped in /usr/src/usr.sbin/bsnmpd *** [depend_subdir_bsnmpd] Error code 2 make[3]: stopped in /usr/src/usr.sbin --- depend_subdir_ctld --- mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in /usr/src/usr.sbin/ctld 1 error make[4]: stopped in /usr/src/usr.sbin/ctld *** [depend_subdir_ctld] Error code 2 make[3]: stopped in /usr/src/usr.sbin 3 errors make[3]: stopped in /usr/src/usr.sbin *** [usr.sbin.depend__D] Error code 2 make[2]: stopped in /usr/src 2 errors make[2]: stopped in /usr/src *** [_depend] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson1264433483474065423.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 rm: FreeBSD_HEAD_arm64/libexec/ld-elf32.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/libexec/ld-elf.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/libexec: Directory not empty rm: FreeBSD_HEAD_arm64/sbin/init: Operation not permitted rm: FreeBSD_HEAD_arm64/sbin: Directory not empty rm: FreeBSD_HEAD_arm64/lib/libcrypt.so.5: Operation not permitted rm: FreeBSD_HEAD_arm64/lib/libc.so.7: Operation not permitted rm: FreeBSD_HEAD_arm64/lib/libthr.so.3: Operation not permitted rm: FreeBSD_HEAD_arm64/lib: Directory not empty rm: FreeBSD_HEAD_arm64/usr/bin/yppasswd: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/crontab: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/opieinfo: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/opiepasswd: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/chpass: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/su: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/passwd: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/ypchfn: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/login: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/chfn: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/chsh: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/ypchsh: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin/ypchpass: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/bin: Directory not empty rm: FreeBSD_HEAD_arm64/usr/lib/librt.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib: Directory not empty rm: FreeBSD_HEAD_arm64/usr/lib32/librt.so.1: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32/libc.so.7: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32/libthr.so.3: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32/libcrypt.so.5: Operation not permitted rm: FreeBSD_HEAD_arm64/usr/lib32: Directory not empty rm: FreeBSD_HEAD_arm64/usr: Directory not empty rm: FreeBSD_HEAD_arm64: Directory not empty + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Fri Sep 4 12:53:46 2015 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 33E859CA8B6 for ; Fri, 4 Sep 2015 12:53:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 21DBC7B9; Fri, 4 Sep 2015 12:53:46 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 22FA8388; Fri, 4 Sep 2015 12:53:46 +0000 (UTC) Date: Fri, 4 Sep 2015 12:53:44 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: mav@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1653022564.28.1441371226011.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <277552279.26.1441363315714.JavaMail.jenkins@jenkins-9.freebsd.org> References: <277552279.26.1441363315714.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1047 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 12:53:46 -0000 FreeBSD_HEAD_arm64 - Build #1047 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1047/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1047/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1047/console Change summaries: 287459 by mav: Another addition to r287455. 287458 by mav: Addition to r287455. From owner-freebsd-arm@freebsd.org Fri Sep 4 17:38:16 2015 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 231819CB6AF for ; Fri, 4 Sep 2015 17:38:16 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 DD5561939 for ; Fri, 4 Sep 2015 17:38:15 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZXuw8-000KJp-BC for freebsd-arm@freebsd.org; Fri, 04 Sep 2015 18:38:04 +0100 Date: Fri, 4 Sep 2015 18:38:04 +0100 From: John To: freebsd-arm@freebsd.org Subject: very odd behaviour from svnlite on RPi2 Message-ID: <20150904173804.GA82922@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 17:38:16 -0000 Hello list, On my newly installed RPi2, I'm trying to install the ports tree. I'm running -CURRENT. I usually install and update ports tree on my freebsd boxen with the following incantation: svnlite co https://svn0.eu.FreeBSD.org/ports/head /usr/ports The problem I'm seeing is variously svnlite bails with the following: svn: E120108: Error retrieving REPORT: The server unexpectedly closed the connection. or... svn: E000054: Error retrieving REPORT: Connection reset by peer or... svn: E120106: ra_serf: The server sent a truncated HTTP response body. I'm having to continually restart this and usually have to cd into /usr/ports and run svnlite cleanup before continueing. I'm on a 20Mbit connection and can get 2MB/s from the upstream server. Is the problem happening because of some issue with svnlite or is it because of some bottleneck on the pi? Is thered anything I can do about it? thanks, -- John From owner-freebsd-arm@freebsd.org Fri Sep 4 21:33:58 2015 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 BBD809CB809 for ; Fri, 4 Sep 2015 21:33:58 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 443001C0F for ; Fri, 4 Sep 2015 21:33:57 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id t84LXt3i088876 for ; Fri, 4 Sep 2015 23:33:55 +0200 (CEST) (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: Fri, 04 Sep 2015 23:33:54 +0200 (CEST) Message-ID: <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> In-Reply-To: <20150904173804.GA82922@potato.growveg.org> References: <20150904173804.GA82922@potato.growveg.org> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: very odd behaviour from svnlite on RPi2 MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Fri, 04 Sep 2015 23:33:55 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 21:33:58 -0000 On 04.09.15, John wrote: > On my newly installed RPi2, I'm trying to install the ports tree. I'm > running -CURRENT. I usually install and update ports tree on my > freebsd boxen with the following incantation: > > svnlite co https://svn0.eu.FreeBSD.org/ports/head /usr/ports > > The problem I'm seeing is variously svnlite bails with the following: I got this svn errors from time to time, independently from the rpi. For getting and updating the ports tree, you can also use the "portsnap" tool (it's part of the base system). -asc From owner-freebsd-arm@freebsd.org Fri Sep 4 21:54:09 2015 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 838059CA061 for ; Fri, 4 Sep 2015 21:54:09 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (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 4E2E21452 for ; Fri, 4 Sep 2015 21:54:08 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from 127.0.0.1 (25.ip-149-202-63.eu [149.202.63.25]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id t84M8iAj065861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 4 Sep 2015 18:08:53 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Subject: Re: very odd behaviour from svnlite on RPi2 To: freebsd-arm@freebsd.org References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> From: George Rosamond Message-ID: <55EA0FC6.2030607@ceetonetechnology.com> Date: Fri, 4 Sep 2015 17:40:22 -0400 MIME-Version: 1.0 In-Reply-To: <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 21:54:09 -0000 Andreas Schwarz: > On 04.09.15, John wrote: > >> On my newly installed RPi2, I'm trying to install the ports tree. I'm >> running -CURRENT. I usually install and update ports tree on my >> freebsd boxen with the following incantation: >> >> svnlite co https://svn0.eu.FreeBSD.org/ports/head /usr/ports >> >> The problem I'm seeing is variously svnlite bails with the following: > > I got this svn errors from time to time, independently from the rpi. For > getting and updating the ports tree, you can also use the "portsnap" tool > (it's part of the base system). I have had these errors many times before. My assumption is that it's tied to the network driver, although it's been a while since I tested. Have you also tried using svn? Portsnap is definitely the capable workaround, but it doesn't explain the original problem. g From owner-freebsd-arm@freebsd.org Fri Sep 4 22:32:21 2015 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 483EF9CB15F for ; Fri, 4 Sep 2015 22:32:21 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 0C5F2A06 for ; Fri, 4 Sep 2015 22:32:20 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZXzWo-000LTe-5z for freebsd-arm@freebsd.org; Fri, 04 Sep 2015 23:32:14 +0100 Date: Fri, 4 Sep 2015 23:32:14 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: very odd behaviour from svnlite on RPi2 Message-ID: <20150904223214.GA80713@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 22:32:21 -0000 On Fri, Sep 04, 2015 at 11:33:54PM +0200, Andreas Schwarz wrote: > I got this svn errors from time to time, independently from the rpi. For > getting and updating the ports tree, you can also use the "portsnap" tool > (it's part of the base system). Yeah I thought about doing this instead of svnlite (after I'd started svnlite). After 10 restarts I got so annoyed I made a while loop. I've never used portsnap because I thought it lagged behind svn, but I might use it in future, maybe it's suited more to low-power systems. I've not seen these errors on the other freebsd boxes in the logs (same connection) which is why I thought it might be a bottleneck with the pi. -- John From owner-freebsd-arm@freebsd.org Sat Sep 5 04:09:32 2015 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 974859CAEEE for ; Sat, 5 Sep 2015 04:09:32 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (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 504EE1319 for ; Sat, 5 Sep 2015 04:09:31 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t853eNeb024181 for freebsd-arm@freebsd.org; Sat, 5 Sep 2015 03:40:23 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.108] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id g88pd5re9t7fk4c74rd4v423n2; for freebsd-arm@freebsd.org; Sat, 05 Sep 2015 03:40:23 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: very odd behaviour from svnlite on RPi2 From: Tim Kientzle In-Reply-To: <20150904223214.GA80713@potato.growveg.org> Date: Fri, 4 Sep 2015 20:40:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com> References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> <20150904223214.GA80713@potato.growveg.org> To: freebsd-arm X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 04:09:32 -0000 > On Sep 4, 2015, at 3:32 PM, John = wrote: >=20 > On Fri, Sep 04, 2015 at 11:33:54PM +0200, Andreas Schwarz wrote: >=20 >> I got this svn errors from time to time, independently from the rpi. = For=20 >> getting and updating the ports tree, you can also use the "portsnap" = tool >> (it's part of the base system). >=20 > Yeah I thought about doing this instead of svnlite (after I'd started = svnlite). > After 10 restarts I got so annoyed I made a while loop. I've never = used=20 > portsnap because I thought it lagged behind svn, but I might use it in = future,=20 > maybe it's suited more to low-power systems. Svn should work just fine on "low power systems," but has had problems = on FreeBSD-based RPi and BeagleBone for a long time. I suspect the root cause is a bug in SVN when dealing with extremely = slow disk: I think the TCP connection times out while the svn client is = doing a long series of disk operations. It certainly should not be happening. > I've not seen these errors on the other freebsd boxes in the logs = (same=20 > connection) which is why I thought it might be a bottleneck with the = pi. In some cases, I've repeated the 'svn cleanup' + 'svn up' cycle for 2-3 = days before it finally completed only to see missing files that svn = doesn't seem to be aware of at all. I've found that partial tree = checkouts are more likely to succeed; you can sometimes work around this = by asking SVN to checkout/update individual subdirectories. For FreeBSD source checkouts, I recommend using git which doesn't seem = to suffer from this problem. Similarly, portsnap is more resilient than = svn for ports checkouts. Tim From owner-freebsd-arm@freebsd.org Sat Sep 5 12:53:24 2015 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 EB0559CA937 for ; Sat, 5 Sep 2015 12:53:24 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 AEAEC1E65 for ; Sat, 5 Sep 2015 12:53:24 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZYCy4-000Ih9-UC for freebsd-arm@freebsd.org; Sat, 05 Sep 2015 13:53:16 +0100 Date: Sat, 5 Sep 2015 13:53:16 +0100 From: John To: freebsd-arm@freebsd.org Subject: keeping up-to-date on RPi2/FreeBSD11 Message-ID: <20150905125316.GB80713@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 12:53:25 -0000 Hello list, I'd like to keep my system up-to-date. Also, might be able to speed up the system a bit by removing options witness/invariants. Although I can find plenty of informative websites detailing how to initially build (using crotchet) and install FreeBSD on RPi2, I can't find where (for RPi2) to configure the kernel and build/installworld in-place on the RPi2. I can see the crossbuild targets in /usr/src/Makefile on another -CURRENT machine but thought I'd ask here first as freebsd-arm evolves very rapidly. Basically, I need to know: 1. where the kernel config file is 2. how to build/install a new world on this platform for an in-place upgrade like you'd do on i386/amd64 thanks, -- John From owner-freebsd-arm@freebsd.org Sat Sep 5 13:36:31 2015 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 68B0D9CBD4E for ; Sat, 5 Sep 2015 13:36:31 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 041FE13C7 for ; Sat, 5 Sep 2015 13:36:30 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1441460185; l=1237; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=/w1WA/B5+P1ph0Bv8V5STe2mBqVAlJeb0M/HtW/ruKA=; b=Ww43N/zDnHoQU4tkzkJMcWrvp5Yy6XKp5dKB3iSLSMSBfjjwSPvKFBGyVy0DvRAp6Ix MXjZOSNSeysiMM9HqJMXvBrP6zHPFYXB6nf9QqMIDTxQQlWbuosdTM2WVdbvVcPrROnX9 zuSBODOz41sjCjdJwUQHBcApW+HPxH+b4tc= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg46sMv/GQHH X-RZG-CLASS-ID: mo00 Received: from quad (p548680C3.dip0.t-ipconnect.de [84.134.128.195]) by smtp.strato.de (RZmta 37.11 DYNA|AUTH) with ESMTPSA id Q01c9cr85DZKilG (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 5 Sep 2015 15:35:20 +0200 (CEST) Date: Sat, 5 Sep 2015 13:35:19 +0000 From: Ulrich Grey To: freebsd-arm@freebsd.org Subject: Re: keeping up-to-date on RPi2/FreeBSD11 Message-Id: <20150905133519.c60e316b90b3205a5d482c01@ulrich-grey.de> In-Reply-To: <20150905125316.GB80713@potato.growveg.org> References: <20150905125316.GB80713@potato.growveg.org> Organization: - X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 13:36:31 -0000 On Sat, 5 Sep 2015 13:53:16 +0100 John wrote: > Hello list, > > I'd like to keep my system up-to-date. Also, might be able to speed up > the system a bit by removing options witness/invariants. Although I can find > plenty of informative websites detailing how to initially build (using crotchet) > and install FreeBSD on RPi2, I can't find where (for RPi2) to configure the > kernel and build/installworld in-place on the RPi2. I can see the crossbuild > targets in /usr/src/Makefile on another -CURRENT machine but thought I'd ask > here first as freebsd-arm evolves very rapidly. Basically, I need to know: > > 1. where the kernel config file is /usr/src/sys/arm/conf > 2. how to build/install a new world on this platform See: https://www.freebsd.org/doc/handbook/makeworld.html Add swapspace. To change to single user mode I think you need a serial console. > > for an in-place upgrade like you'd do on i386/amd64 > > thanks, > -- > John > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 5 20:03:41 2015 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 C6D949CAF0C for ; Sat, 5 Sep 2015 20:03:41 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (smtp61.avvanta.com [206.124.128.61]) (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 ABFE91C59 for ; Sat, 5 Sep 2015 20:03:41 +0000 (UTC) (envelope-from kah42pub@blarg.com) Received: from mail.avvanta.com (localhost.drteeth.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id 9F4CFF3937 for ; Sat, 5 Sep 2015 12:46:27 -0700 (PDT) Received: from MBP16GB.local (c-50-135-203-40.hsd1.wa.comcast.net [50.135.203.40]) by mail.avvanta.com (Postfix) with ESMTP id 83E74F3935 for ; Sat, 5 Sep 2015 12:46:27 -0700 (PDT) Subject: Re: keeping up-to-date on RPi2/FreeBSD11 To: freebsd-arm@freebsd.org References: <20150905125316.GB80713@potato.growveg.org> <20150905133519.c60e316b90b3205a5d482c01@ulrich-grey.de> From: kah42pub Message-ID: <55EB46D2.1040003@blarg.com> Date: Sat, 5 Sep 2015 12:47:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150905133519.c60e316b90b3205a5d482c01@ulrich-grey.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.drteeth.p.blarg.net X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 20:03:42 -0000 On 9/5/15 06:35, Ulrich Grey wrote: > On Sat, 5 Sep 2015 13:53:16 +0100 > John wrote: > >> Hello list, >> >> I'd like to keep my system up-to-date. Also, might be able to speed up >> the system a bit by removing options witness/invariants. Although I can find >> plenty of informative websites detailing how to initially build (using crotchet) >> and install FreeBSD on RPi2, I can't find where (for RPi2) to configure the >> kernel and build/installworld in-place on the RPi2. I can see the crossbuild >> targets in /usr/src/Makefile on another -CURRENT machine but thought I'd ask >> here first as freebsd-arm evolves very rapidly. Basically, I need to know: >> >> 1. where the kernel config file is > > /usr/src/sys/arm/conf > >> 2. how to build/install a new world on this platform > > See: https://www.freebsd.org/doc/handbook/makeworld.html > > Add swapspace. > To change to single user mode I think you need a serial console. > >> >> for an in-place upgrade like you'd do on i386/amd64 >> >> thanks, >> -- >> John >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > For what it is worth, these steps work for me to update an RPI2 in place. A serial cable is definitely required. Most of this was taken from the FreeBSD documentation. I've omitted steps that are specific to my configuration. chflags -R noschg /usr/obj/* rm -rf /usr/obj cd /usr/src make -j8 cleandir make -j4 buildworld # This takes 8+ hours for me on RPI2 make -j4 buildkernel KERNCONF=RPI2 # This takes an hour or less on RPI2 # Plug in serial cable and connect/login for following steps shutdown now cd /usr/src make installkernel mount -u / swapon -a mergemaster -p make installworld mergemaster -iF make delete-old shutdown -r now # Serial cable not needed after this step unless there is a problem portsnap fetch update portmaster -Raf cd /usr/src make delete-old-libs This process recently took me up to 11.0-CURRENT r287441 without a hiccup on the RPI2. Hope it helps. If anyone sees anything obvious that I didn't do that I should have for the upgrade process, feel free to speak up. Also, powerd definitely works on RPI2. Having it enabled (allowing stepped up CPU speeds under load) decreases the build world time by hours - at least for me. Your mileage may vary. Kris From owner-freebsd-arm@freebsd.org Sat Sep 5 23:48:42 2015 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 AF6B99CBDD4 for ; Sat, 5 Sep 2015 23:48:42 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 7152728C for ; Sat, 5 Sep 2015 23:48:42 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ZYNCA-00036N-0G for freebsd-arm@freebsd.org; Sun, 06 Sep 2015 00:48:30 +0100 Date: Sun, 6 Sep 2015 00:48:29 +0100 From: John To: freebsd-arm@freebsd.org Subject: Re: keeping up-to-date on RPi2/FreeBSD11 Message-ID: <20150905234829.GA6572@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20150905125316.GB80713@potato.growveg.org> <20150905133519.c60e316b90b3205a5d482c01@ulrich-grey.de> <55EB46D2.1040003@blarg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55EB46D2.1040003@blarg.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 23:48:42 -0000 On Sat, Sep 05, 2015 at 12:47:30PM -0700, kah42pub wrote: > For what it is worth, these steps work for me to update an RPI2 in > place. A serial cable is definitely required. Most of this was taken > from the FreeBSD documentation. I've omitted steps that are specific to > my configuration. [snip - thanks for the info btw] > This process recently took me up to 11.0-CURRENT r287441 without a > hiccup on the RPI2. Hope it helps. If anyone sees anything obvious that > I didn't do that I should have for the upgrade process, feel free to > speak up. Will your method work for an image made by crotchet - ie will it boot the right kernel, does it update what crotchet installed? The original install was http://download.raspbsd.org/FreeBSD-armv6-11.0-RPI2-286947.img.gz > Also, powerd definitely works on RPI2. Having it enabled (allowing > stepped up CPU speeds under load) decreases the build world time by > hours - at least for me. Your mileage may vary. yep, I have powerd enabled now rather than setting turbo in /etc/sysctl.conf. I also have powerd_flags="-a hiadaptive" though am unsure if these flags have any effect on this arch. thanks, -- John