From owner-freebsd-arm@freebsd.org Sun Feb 25 14:42:52 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CE23F31139; Sun, 25 Feb 2018 14:42:52 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 333247F4A5; Sun, 25 Feb 2018 14:42:51 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.133] (helo=smtp9.tb.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1epxAj-0002l5-Uj; Sun, 25 Feb 2018 15:21:01 +0100 Received: from 5ed231fb.cm-7-3a.dynamic.ziggo.nl ([94.210.49.251] helo=wan0.bsd4all.org) by smtp9.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1epxAj-000203-TF; Sun, 25 Feb 2018 15:21:01 +0100 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id E164D2174; Sun, 25 Feb 2018 15:20:59 +0100 (CET) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTlXV4v4ILMO; Sun, 25 Feb 2018 15:20:50 +0100 (CET) Received: from [192.168.1.65] (unknown [192.168.1.65]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 2376A2166; Sun, 25 Feb 2018 15:20:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: INTRNG From: peter.blok@bsd4all.org In-Reply-To: <401A33BD-F3AE-4139-9D47-6F85C8333022@brawn.org> Date: Sun, 25 Feb 2018 15:20:49 +0100 Cc: freebsd-arm@freebsd.org, FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: <694A18B8-60FB-48C8-AE63-C63250F6D940@bsd4all.org> References: <401A33BD-F3AE-4139-9D47-6F85C8333022@brawn.org> To: Jon Brawn X-Mailer: Apple Mail (2.3445.5.20) X-SourceIP: 94.210.49.251 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.3 cv=XYenMrx5 c=1 sm=1 tr=0 a=7fK1ynn72W3Z/oi6DA4Tww==:17 a=IkcTkHD0fZMA:10 a=Op4juWPpsa0A:10 a=79WsMlhMAAAA:8 a=qZHiuq15OrB9ri-jzK0A:9 a=XQNlMLMPhtl59P3B:21 a=RBS4klvuPhtMt2ah:21 a=QEXdDO2ut3YA:10 a=0SLe_2h_PVcu0AVkMdds:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 14:42:52 -0000 While on the subject INTRNG - does anybody know the status of handling = GPIO interrupts with queue/kevent? There were some patches before INTRNG, but they require some work. Peter > On 23 Feb 2018, at 07:25, Jon Brawn wrote: >=20 > Wotcha Gang! >=20 > In my travels through the arm64 GENERIC config file I came across the = option =E2=80=98INTRNG=E2=80=99, and wondered what it was: >=20 > INTeRrupt Next Generation? > INTeger Random Number Generator? > IN TRaiNinG? > INTerrupt Random Number Generator? > INdependent TRaiNinG? >=20 > So, please put me out of my misery, what does INTRNG stand for, and = what are its implications when selected vs not selected? >=20 > Cheers! >=20 > Jon. From owner-freebsd-arm@freebsd.org Sun Feb 25 21:00:29 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEF04F28599 for ; Sun, 25 Feb 2018 21:00:28 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 890C670491 for ; Sun, 25 Feb 2018 21:00:28 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id BBFCB233D3 for ; Sun, 25 Feb 2018 21:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1PL0RCF076777 for ; Sun, 25 Feb 2018 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1PL0RQq076773 for freebsd-arm@FreeBSD.org; Sun, 25 Feb 2018 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201802252100.w1PL0RQq076773@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 25 Feb 2018 21:00:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 21:00:29 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 220297 | arch(7) rename arm64 to aarch64 respecting `uname 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Mon Feb 26 06:15:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C2AEF2E240 for ; Mon, 26 Feb 2018 06:15:10 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96964851A5 for ; Mon, 26 Feb 2018 06:15:09 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.28] (helo=mx18.freenet.de) by mout1.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (port 25) (Exim 4.90_1 #2) id 1eqC42-0000AS-8D for freebsd-arm@freebsd.org; Mon, 26 Feb 2018 07:15:06 +0100 Received: from web3.emo.freenet-rz.de ([194.97.107.236]:63312) by mx18.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 587) (Exim 4.90_1 #2) id 1eqC41-0002NS-VI for freebsd-arm@freebsd.org; Mon, 26 Feb 2018 07:15:06 +0100 Received: from localhost ([127.0.0.1] helo=emo.freenet.de) by web3.emo.freenet-rz.de with esmtpa (Exim 4.84_2 2 (Panther_1)) id 1eqC41-0004J7-It for ; Mon, 26 Feb 2018 07:15:05 +0100 Date: Mon, 26 Feb 2018 07:15:04 +0100 From: freebsdnewbie@freenet.de Subject: [bbb] kernel panic during boot To: freebsd-arm@freebsd.org X-Priority: 3 MIME-Version: 1.0 X-Abuse: 306382964 / 165.225.72.165 Message-Id: <6efca938e9fcefb04b528cdb4d8f0080@email.freenet.de> User-Agent: freenetMail Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originated-At: 165.225.72.165!32809 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 06:15:10 -0000 Booting CURRENT r329950 (GENERIC-NODEBUG Kernel) on a Beaglebone Black resu= lts in a kernel panic: U-Boot 2017.09 (Oct 19 2017 - 22:27:23 +0000) CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - bad CRC, using default environment not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 232876 bytes read in 22 ms (10.1 MiB/s) ## Starting application at 0x82000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x9df2dc60 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Thu Jan 4 03:32:38 UTC 2018 root@releng3.nyi.freebsd.org) DRAM: 512MB Number of U-Boot devices: 3 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: /boot/kernel/kernel data=3D0x8ad194+0x186e6c syms=3D[0x4+0x97930+0x4+0xdbe9= 9] Hit [Enter] to boot immediately, or any other key for command . Booting [/boot/kernel/kernel]... /boot/dtb/am335x-boneblack.dtb size=3D0xc8b3 Loaded DTB from file 'am335x-boneblack.dtb'. Kernel entry at 0x82200100... Kernel args: (null) ARM Debug Architecture not supported KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #2 r329982: Sun Feb 25 15:52:01 CET 2018 root@valinor:/usr/obj/usr/src/arm.armv7/sys/GENERIC-NODEBUG arm FreeBSD clang version 6.0.0 (branches/release_60 325330) (based on LLVM=20 6.0.0) VT: init without driver. module_register: cannot register simplebus/ahci from kernel; already=20 loaded from kernel Module simplebus/ahci failed to register: 17 module_register: cannot register simplebus/ehci from kernel; already=20 loaded from kernel Module simplebus/ehci failed to register: 17 module_register: cannot register simplebus/pcib from kernel; already=20 loaded from kernel Module simplebus/pcib failed to register: 17 module_register: cannot register simplebus/ehci from kernel; already=20 loaded from kernel Module simplebus/ehci failed to register: 17 CPU: ARM Cortex-A8 r3p2 (ECO: 0x00000000) CPU Features: Thumb2, Security, VMSAv7 Optional instructions: UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory =3D 536870912 (512 MB) avail memory =3D 511311872 (487 MB) Texas Instruments AM335x Processor, Revision ES2.1 arc4random: no preloaded entropy cache random: entropy device external interface panic: kobj_class_compile: out of memory cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc05f4c10 lr =3D 0xc00a25d8 (db_trace_self_wrapper+0x30) sp =3D 0xc0c13cb0 fp =3D 0xc0c13dc8 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc00a25d8 lr =3D 0xc02d2210 (vpanic+0x154) sp =3D 0xc0c13dd0 fp =3D 0xc0c13df0 r4 =3D 0x00000100 r5 =3D 0x00000001 r6 =3D 0xc0746bb4 r7 =3D 0xc09baa58 vpanic() at vpanic+0x154 pc =3D 0xc02d2210 lr =3D 0xc02d20bc (vpanic) sp =3D 0xc0c13df8 fp =3D 0xc0c13dfc r4 =3D 0x00000000 r5 =3D 0xc088c10c r6 =3D 0xc30dc4c0 r7 =3D 0x0000000f r8 =3D 0xc1e81780 r9 =3D 0xc08a766c r10 =3D 0xc09ba7c8 vpanic() at vpanic pc =3D 0xc02d20bc lr =3D 0xc0321394 (kobj_class_compile_static) sp =3D 0xc0c13e04 fp =3D 0xc0c13e20 r4 =3D 0x0000000f r5 =3D 0xc1e81780 r6 =3D 0xc08a766c r7 =3D 0xc09ba7c8 r8 =3D 0xc0c13dfc r9 =3D 0xc02d20bc r10 =3D 0xc0c13e04 kobj_class_compile_static() at kobj_class_compile_static pc =3D 0xc0321394 lr =3D 0xc030ed94 (devclass_add_driver+0x48) sp =3D 0xc0c13e28 fp =3D 0xc0c13e40 r4 =3D 0xc30dc4c0 r10 =3D 0x0000000f devclass_add_driver() at devclass_add_driver+0x48 pc =3D 0xc030ed94 lr =3D 0xc02b57e0 (module_register_init+0xd4) sp =3D 0xc0c13e48 fp =3D 0xc0c13e68 r4 =3D 0xc088c0e8 r5 =3D 0xc1e99900 r6 =3D 0xc076e386 r7 =3D 0x00000001 r8 =3D 0xc09df118 r9 =3D 0xc08a766c module_register_init() at module_register_init+0xd4 pc =3D 0xc02b57e0 lr =3D 0xc0268f20 (mi_startup+0x18c) sp =3D 0xc0c13e70 fp =3D 0xc0c13e90 r4 =3D 0xc09def24 r5 =3D 0x00000001 r6 =3D 0xc07846cc r7 =3D 0x00000000 r8 =3D 0xc09def20 r9 =3D 0xc07854e4 r10 =3D 0xc09dee28 mi_startup() at mi_startup+0x18c pc =3D 0xc0268f20 lr =3D 0xc0000244 (btext+0x144) sp =3D 0xc0c13e98 fp =3D 0x00000000 r4 =3D 0xc0000378 r5 =3D 0xc0a30000 r6 =3D 0x82059480 r7 =3D 0x00c52078 r8 =3D 0xc0bc3000 r9 =3D 0x00000014 r10 =3D 0x44e35000 btext() at btext+0x144 pc =3D 0xc0000244 lr =3D 0xc0000244 (btext+0x144) sp =3D 0xc0c13e98 fp =3D 0x00000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at $d.3: ldrb r15, [r15, r15, ror r15]! db> Any Ideas? Sichern Sie sich mit freenet Mail start 20 GB CLOUD-SPEICHER=0Azus=C3=A4tzl= ich zu Ihrem werbefreien Postfach sowie h=C3=B6chste=0ASicherheitsstandards= =0Ahttps://email.freenet.de/start/index.html=0A[https://email.freenet.de/s= tart/index.html?utm_medium=3DMail%20Start&utm_source=3DMailfooter&utm_campa= ign=3DFooter%20B&epid=3De9900000928&utm_content=3DLink]=0A From owner-freebsd-arm@freebsd.org Mon Feb 26 14:54:48 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78D80F2A7C2 for ; Mon, 26 Feb 2018 14:54:48 +0000 (UTC) (envelope-from dev.madaari@gmail.com) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 E941278A47 for ; Mon, 26 Feb 2018 14:54:47 +0000 (UTC) (envelope-from dev.madaari@gmail.com) Received: by mail-wr0-x22f.google.com with SMTP id n7so21528945wrn.5 for ; Mon, 26 Feb 2018 06:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=v6b3ugCkcJjNtZL79i3i+uQIGD2zO7oUl4SFiPRIdgI=; b=dGGtG6eWKfBL8uZQR9tG/zXz7tCMSKDWvVCalliFOPvADIYscY62x8YFlGZFa3e+CW 7m0s4Ww5IODG9W50hIwrjCOcsihOhnOjzvM4oRfBqIoFTMQiGCGCycPg3kHeR7uCJ02o 6a3EVTOJYzyGnXRL48b3grMaWHkDpgPyGq53Xmyt4+APLROd0VSgk8iM1ABasJbZsrre mN8YFOIC9oC6S9ZgS6KAQItAme8wnEN2xybVQo9MfZAUStMjikfJGMOCrdJaE0/bO9h6 xCXuOeCVvkp8Vt1iBz3pvDxuE7yiU1JLEDQ1/RqUF+HejLigIjvQTs6N3eDcueu1Vycr 1hjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v6b3ugCkcJjNtZL79i3i+uQIGD2zO7oUl4SFiPRIdgI=; b=hQQoNwz5dI8PCPW/IGc1/jmR6coZvdklkEjjj+f5RJDxsQwc8jFH/1bkWGhAHbSs6T AaKR/ztuGNrdu0diWsXMxRihPMIcfwnhlVBv/tWpCcxXyljxukNMY9EmzqQEqYSQG/Wk pIWAdeXDZ5q32cQWVbgIye/FILE6fz9TewTDaxfyAjTEeAARWB7sHk+a3/B/39Sb29zY qALXxBE4zCWnvY0lhPA9HF+7PRCksNMlQFGo4i/Y8RfOBd2BCuETR9SbCHXs9wPA0fV6 kIy5KQ1FJ6hqxU1gro3MBfHATZh0BdKA7+DIbJFkEmkxaHX7y+Fmc+15F2xyTjNv9g7W WI4w== X-Gm-Message-State: APf1xPAyFQj5rhXjKGyWzzZJDo3XQl3Sf6dE/cp2qi7Id1zvuZoG4959 F9+1oOjttuJF91DRajFAq+u8SON9PXyNv9NoURyWCw== X-Google-Smtp-Source: AG47ELuG9Zq31b199MxpQkc0sGriTeFb78dW+1nBT//Hr37oaiGKqV+Hxx3E6aBO9f1xXzxnc9LecmMRM9X8N6B+++4= X-Received: by 10.223.144.131 with SMTP id i3mr4083444wri.218.1519656885800; Mon, 26 Feb 2018 06:54:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.70 with HTTP; Mon, 26 Feb 2018 06:54:45 -0800 (PST) From: Udit agarwal Date: Mon, 26 Feb 2018 20:24:45 +0530 Message-ID: Subject: Support for Atheros AR9271 in FreeBSD kernel To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 14:54:48 -0000 Hello community, I actually need to use my wireless card Atheros AR9271(Firmware name: ath9k_htc/htc_9271-1.4.0.fw) with FreeBSD on BeagleBoneBlack. Although its mentioned here , that FreeBSD currently lacks driver for this, but still i would like to ask about any sort of driver(or partial support) for my wireless card. Thanks, Udit Agarwal From owner-freebsd-arm@freebsd.org Mon Feb 26 15:10:36 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 019ECF2BC16 for ; Mon, 26 Feb 2018 15:10:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 8B0D6796BC; Mon, 26 Feb 2018 15:10:35 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x234.google.com with SMTP id l187so11316646ith.4; Mon, 26 Feb 2018 07:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VVyzv+5bt0uvneyU8LaGHSZ+AA0/WkZG8ENdbgfSCzQ=; b=Ffx+HSp5BddPceusyOleGwkAeYrU6KJ1VfKnF0y63LjynulyWsNMUPlAHhgLUxdRKW uqQgsV+sCNKILVIOCL3ZrqlYLIUIFU9IyO9PFGQSCdwi6iYWgP7MPgzF6hp3nNM1b4fO Ayn4Z6uD5EuFWvF6axapP0hKLPCCpxg887aj7DR2lWUjXUOiwHI7giZoydtpIiqZm24y biVVTABkb5ZU30H1ThILDix5m6JwEJlS4+9o5+hJNWnpAS8a3GQ4cc44cZR8118oOdRS hyXWu7Zi1sE606LnJk1Z3pqvX5J/8iIAwiWAeD7qBxXU7LXheXtS6f4OV4b9VqGgNqpZ uQ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VVyzv+5bt0uvneyU8LaGHSZ+AA0/WkZG8ENdbgfSCzQ=; b=k+qb76WVHs4ruVKbGsphf6aGkcca0xKccI/5gRTseiCt96ORL8RFnGpapaCG7if2S0 6zNKMvTM3PHQyf+riNwTgkJWJNzqtRr28hGmrRYWLyGJ2odPy3ChKE2WO3PUvwTIgZ0T +qFwRKgoPQKRnCd+oEJH8GaZFP41nKAQ7LBTYc/IOWIUFKnbSCDvlbDnDNz/n0L2+L4u u+Aaxwsk8XkT9hU/6Zfko6YZ3KKztL/tu1ynf/ppYsgmpNhrCNkqJKxkGZRfTTeMNomv STowyDR/6JNWRoVAPviXMxZB3/L+jXTd2cM2NUS5WH+7EsQihtM9WcnCMV6xBJMqhF2t yxTg== X-Gm-Message-State: APf1xPBNfwXjfolAuPYxGSjq8dMr405vXSdCxVMfUoXLuMbEkuyTqW6x 8KaYwujEkOb5PBGzfxXu5F8z6G78Xf/OqEBvTdi++Q== X-Google-Smtp-Source: AH8x227NGPmMZYfn2kzfyIrJjdLf/dgflzKhN4gk31kQMJBkvZ/4WYTEg6/vvJrMA27DgakCyVkufwe3mc1UDDTEX2U= X-Received: by 10.36.145.1 with SMTP id i1mr12600324ite.54.1519657834632; Mon, 26 Feb 2018 07:10:34 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.163.13 with HTTP; Mon, 26 Feb 2018 07:10:14 -0800 (PST) In-Reply-To: References: <31CD451B-DD39-4F20-91CD-FD60A857A8A3@freebsd.org> From: Ed Maste Date: Mon, 26 Feb 2018 10:10:14 -0500 X-Google-Sender-Auth: MqKIHu2Xd59hhSIN7ENBqtmEq1A Message-ID: Subject: Re: ThunderX2 support To: Michael Tuexen Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 15:10:36 -0000 On 20 February 2018 at 07:55, Michael Tuexen wrote: > > Hi Ed, > > thanks for the feedback. I guess it is planned that ThunderX2 is supported sometimes > in the future? Yes - thanks to Cavium we have access to a ThunderX2 system for development, and Andrew Turner has made some good progress addressing issues we've found (e.g. r329906, r329990, r329991, r330016). We don't have a timeline on full support yet though. From owner-freebsd-arm@freebsd.org Mon Feb 26 15:23:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6BC0F2CB4F; Mon, 26 Feb 2018 15:23:53 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 23A9B7A060; Mon, 26 Feb 2018 15:23:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1QFNjqW021033 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Feb 2018 07:23:46 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1QFNjLF021032; Mon, 26 Feb 2018 07:23:45 -0800 (PST) (envelope-from fbsd) Date: Mon, 26 Feb 2018 07:23:45 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: freebsd-current@freebsd.org, bob prohaska Subject: Errors compiling LLVM on RPi3 at 330019 Message-ID: <20180226152345.GA21006@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 15:23:53 -0000 At revision 330019 -DNO_CLEAN buildworld stops with --- Target/X86/X86ISelDAGToDAG.o --- /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2463:7: error: use of undeclared identifier 'SelectCode' SelectCode(ZextTarget.getNode()); ^ /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2464:7: error: use of undeclared identifier 'SelectCode' SelectCode(Brind.getNode()); ^ /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2480:5: error: use of undeclared identifier 'SelectCode' SelectCode(VSelect.getNode()); ^ /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:3072:3: error: use of undeclared identifier 'SelectCode' SelectCode(Node); Should I wait for an update, or run cleandir? This is on a Pi3. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Mon Feb 26 17:03:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 907FAF33599 for ; Mon, 26 Feb 2018 17:03:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 14E7E7E517 for ; Mon, 26 Feb 2018 17:03:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1QH3KYR021253 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Feb 2018 09:03:21 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1QH3KF6021252; Mon, 26 Feb 2018 09:03:20 -0800 (PST) (envelope-from fbsd) Date: Mon, 26 Feb 2018 09:03:20 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Strange behavior from cu on armv7 Message-ID: <20180226170320.GA21104@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 17:03:23 -0000 Lately cu sessions (or something closely-related) have taken to misbehaving on a Pi2 running -current. The situation is: ssh into armv7 host which has a pl2303 plugged into it su to root run cu -l cuaU0 -s 115200 to connect to the serial port of a Pi3 Most of the time the connection behaves normally. The pl2303 is prone to locking up over time, seemingly faster (an hour) when the armv7 host is loaded. In that case, unplugging and replugging the pl2303 aborts the cu connection, which can then be restarted and again behaves normally. Lately, the unplug-replug cycle produces the normal recognition and allows the cu session to be restarted, but no data is tranferred. A "connected" prompt comes back, but there's no echo and no data. Further unplug-replug attempts don't change anything. A reboot of the armv7 host restores normal behavior. In a couple of cases unprintable characters displayed: root@www:/home/bob # cu -l cuaU0 -s 11520oo}root@www:/home/bob # cu -l cuaU0 -s 115200 Connected [hex characters didn't copy/paste] FreeBSD/arm64 (www.zefox.org) (ttyu0) login: � FreeBSD/arm64 (www.zefox.org) (ttyu0) login: And all is well, for now. Thanks for reading, and any ideas. bob prohaska From owner-freebsd-arm@freebsd.org Mon Feb 26 18:16:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCB1BF37F35; Mon, 26 Feb 2018 18:16:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 757B481530; Mon, 26 Feb 2018 18:16:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B0BBF8329; Mon, 26 Feb 2018 19:16:14 +0100 (CET) From: Dimitry Andric Message-Id: <6AAA36E2-CDE3-42C3-B070-3C75044656C6@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3ABC99C8-E8AC-4180-A3F4-099890C3F398"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Errors compiling LLVM on RPi3 at 330019 Date: Mon, 26 Feb 2018 19:16:18 +0100 In-Reply-To: <20180226152345.GA21006@www.zefox.net> Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org To: bob prohaska References: <20180226152345.GA21006@www.zefox.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 18:16:22 -0000 --Apple-Mail=_3ABC99C8-E8AC-4180-A3F4-099890C3F398 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Feb 2018, at 16:23, bob prohaska wrote: >=20 > At revision 330019 -DNO_CLEAN buildworld stops with >=20 > --- Target/X86/X86ISelDAGToDAG.o --- > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2463:7: = error: use of undeclared identifier 'SelectCode' > SelectCode(ZextTarget.getNode()); > ^ > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2464:7: = error: use of undeclared identifier 'SelectCode' > SelectCode(Brind.getNode()); > ^ > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2480:5: = error: use of undeclared identifier 'SelectCode' > SelectCode(VSelect.getNode()); > ^ > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:3072:3: = error: use of undeclared identifier 'SelectCode' > SelectCode(Node); >=20 > Should I wait for an update, or run cleandir? This is on a Pi3. =46rom which revision were you upgrading? It looks like your .inc files were not regenerated properly by llvm-tblgen, maybe timestamps out of whack? I would indeed try a clean build. -Dimitry --Apple-Mail=_3ABC99C8-E8AC-4180-A3F4-099890C3F398 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWpRO8gAKCRCwXqMKLiCW oxKAAKC4GHhn3d0pm3LQRoKLHI6meBgW4ACgwcS+ku+a/fNe6Pbn5vFgF3zUdQA= =Hhgl -----END PGP SIGNATURE----- --Apple-Mail=_3ABC99C8-E8AC-4180-A3F4-099890C3F398-- From owner-freebsd-arm@freebsd.org Mon Feb 26 18:31:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D2E0F3905D for ; Mon, 26 Feb 2018 18:31:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2CC88216B for ; Mon, 26 Feb 2018 18:31:32 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 401baffb-1b23-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 401baffb-1b23-11e8-91c6-33ffc249f3e8; Mon, 26 Feb 2018 18:31:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1QIVLnP075625; Mon, 26 Feb 2018 11:31:21 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1519669881.91697.295.camel@freebsd.org> Subject: Re: Strange behavior from cu on armv7 From: Ian Lepore To: bob prohaska , freebsd-arm@freebsd.org Date: Mon, 26 Feb 2018 11:31:21 -0700 In-Reply-To: <20180226170320.GA21104@www.zefox.net> References: <20180226170320.GA21104@www.zefox.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 18:31:33 -0000 On Mon, 2018-02-26 at 09:03 -0800, bob prohaska wrote: > Lately cu sessions (or something closely-related) have taken to > misbehaving on a Pi2 running -current. > > The situation is: > > ssh into armv7 host which has a pl2303 plugged into it > su to root > run cu -l cuaU0 -s 115200 to connect to the serial port of a Pi3  > > Most of the time the connection behaves normally. The pl2303 is prone > to locking up over time, seemingly faster (an hour) when the armv7 host > is loaded. In that case, unplugging and replugging the pl2303 aborts > the cu connection, which can then be restarted and again behaves normally. > > Lately, the unplug-replug cycle produces the normal recognition and  > allows the cu session to be restarted, but no data is tranferred. > A "connected" prompt comes back, but there's no echo and no data.  > Further unplug-replug attempts don't change anything. A reboot of > the armv7 host restores normal behavior.  > > In a couple of cases unprintable characters displayed: > > root@www:/home/bob # cu -l cuaU0 -s 11520oo}root@www:/home/bob # cu -l cuaU0 -s 115200 > Connected > [hex characters didn't copy/paste] > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > login: � > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > login:  > > And all is well, for now. > > Thanks for reading, and any ideas. > > bob prohaska Hmm.  I've noticed for the past week or two (maybe longer) that if I connect to a wandboard serial console via an ftdi usb-serial and cu, and then I do "stty size 24 140" I get exactly the symptom you describe... no response to ^C or ^T, and neither un/replugging the ftdi nor closing and reopening the cu connection makes data flow in either direction until the arm board is rebooted.  Ssh connections to the board continue to work fine and the system appears to be running fine, it's only the serial console that's dead.  Killing the getty on the console doesn't help either, a new non-responsive getty starts up immediately. So, I guess all in all I have nothing much to offer here except a too- wordy "me too". -- Ian From owner-freebsd-arm@freebsd.org Mon Feb 26 18:47:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4511BF3A185 for ; Mon, 26 Feb 2018 18:47:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B646B82B71; Mon, 26 Feb 2018 18:47:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1QIl1I5021498 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Feb 2018 10:47:02 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1QIl1pc021497; Mon, 26 Feb 2018 10:47:01 -0800 (PST) (envelope-from fbsd) Date: Mon, 26 Feb 2018 10:47:01 -0800 From: bob prohaska To: Dimitry Andric Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Errors compiling LLVM on RPi3 at 330019 Message-ID: <20180226184701.GB21104@www.zefox.net> References: <20180226152345.GA21006@www.zefox.net> <6AAA36E2-CDE3-42C3-B070-3C75044656C6@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6AAA36E2-CDE3-42C3-B070-3C75044656C6@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 18:47:04 -0000 On Mon, Feb 26, 2018 at 07:16:18PM +0100, Dimitry Andric wrote: > On 26 Feb 2018, at 16:23, bob prohaska wrote: > > > > At revision 330019 -DNO_CLEAN buildworld stops with > > > > --- Target/X86/X86ISelDAGToDAG.o --- > > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2463:7: error: use of undeclared identifier 'SelectCode' > > SelectCode(ZextTarget.getNode()); > > ^ > > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2464:7: error: use of undeclared identifier 'SelectCode' > > SelectCode(Brind.getNode()); > > ^ > > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2480:5: error: use of undeclared identifier 'SelectCode' > > SelectCode(VSelect.getNode()); > > ^ > > /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:3072:3: error: use of undeclared identifier 'SelectCode' > > SelectCode(Node); > > > > Should I wait for an update, or run cleandir? This is on a Pi3. > > From which revision were you upgrading? Probably revision 329997 > It looks like your .inc files > were not regenerated properly by llvm-tblgen, The system has been plagued by stoppages during clang build. Sometimes in llvm-tblgen, but not always. A frequent error is 137, from clang, but "out of swap" happens too. Been using the -DNO_CLEAN option to pick up where it left off. > maybe timestamps out of > whack? I would indeed try a clean build. > Ok, will try starting over. FWIW, recently behavior re swapping has been much better (gstat delays look smaller using swap on microSD) but the system is still reporting "out of swap" when top shows less than complete swap use. Thanks very much! bob prohaska From owner-freebsd-arm@freebsd.org Mon Feb 26 18:54:37 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C9E4F3AA47 for ; Mon, 26 Feb 2018 18:54:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FAB683441; Mon, 26 Feb 2018 18:54:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1QIsYf3021511 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Feb 2018 10:54:35 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1QIsYfF021510; Mon, 26 Feb 2018 10:54:34 -0800 (PST) (envelope-from fbsd) Date: Mon, 26 Feb 2018 10:54:34 -0800 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Strange behavior from cu on armv7 Message-ID: <20180226185434.GC21104@www.zefox.net> References: <20180226170320.GA21104@www.zefox.net> <1519669881.91697.295.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1519669881.91697.295.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 18:54:37 -0000 On Mon, Feb 26, 2018 at 11:31:21AM -0700, Ian Lepore wrote: > On Mon, 2018-02-26 at 09:03 -0800, bob prohaska wrote: > > Lately cu sessions (or something closely-related) have taken to > > misbehaving on a Pi2 running -current. > > > > The situation is: > > > > ssh into armv7 host which has a pl2303 plugged into it > > su to root > > run cu -l cuaU0 -s 115200 to connect to the serial port of a Pi3?? > > > > Most of the time the connection behaves normally. The pl2303 is prone > > to locking up over time, seemingly faster (an hour) when the armv7 host > > is loaded. In that case, unplugging and replugging the pl2303 aborts > > the cu connection, which can then be restarted and again behaves normally. > > > > Lately, the unplug-replug cycle produces the normal recognition and?? > > allows the cu session to be restarted, but no data is tranferred. > > A "connected" prompt comes back, but there's no echo and no data.?? > > Further unplug-replug attempts don't change anything. A reboot of > > the armv7 host restores normal behavior.?? > > > > In a couple of cases unprintable characters displayed: > > > > root@www:/home/bob # cu -l cuaU0 -s 11520oo}root@www:/home/bob # cu -l cuaU0 -s 115200 > > Connected > > [hex characters didn't copy/paste] > > > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > > > login: ??? > > > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > > > login:?? > > > > And all is well, for now. > > > > Thanks for reading, and any ideas. > > > > bob prohaska > > Hmm. ??I've noticed for the past week or two (maybe longer) that if I > connect to a wandboard serial console via an ftdi usb-serial and cu, > and then I do "stty size 24 140" I get exactly the symptom you > describe... no response to ^C or ^T, and neither un/replugging the ftdi > nor closing and reopening the cu connection makes data flow in either > direction until the arm board is rebooted. ??Ssh connections to the > board continue to work fine and the system appears to be running fine, > it's only the serial console that's dead. ??Killing the getty on the > console doesn't help either, a new non-responsive getty starts up > immediately. > > So, I guess all in all I have nothing much to offer here except a too- > wordy "me too". > Well, at least I'm in good company.....8-) Thanks for writing, bob prohaska From owner-freebsd-arm@freebsd.org Mon Feb 26 18:56:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1E7BF3AC28 for ; Mon, 26 Feb 2018 18:56:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88DF4835E4 for ; Mon, 26 Feb 2018 18:56:51 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D11EB832E; Mon, 26 Feb 2018 19:56:50 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_205FB500-0588-41BB-A0D1-EBB9A8877F6A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Errors compiling LLVM on RPi3 at 330019 Date: Mon, 26 Feb 2018 19:56:49 +0100 In-Reply-To: <20180226184701.GB21104@www.zefox.net> Cc: freebsd-arm@freebsd.org To: bob prohaska References: <20180226152345.GA21006@www.zefox.net> <6AAA36E2-CDE3-42C3-B070-3C75044656C6@FreeBSD.org> <20180226184701.GB21104@www.zefox.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 18:56:53 -0000 --Apple-Mail=_205FB500-0588-41BB-A0D1-EBB9A8877F6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Feb 2018, at 19:47, bob prohaska wrote: >=20 > On Mon, Feb 26, 2018 at 07:16:18PM +0100, Dimitry Andric wrote: >> On 26 Feb 2018, at 16:23, bob prohaska wrote: >>>=20 >>> At revision 330019 -DNO_CLEAN buildworld stops with >>>=20 >>> --- Target/X86/X86ISelDAGToDAG.o --- >>> /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2463:7: = error: use of undeclared identifier 'SelectCode' >>> SelectCode(ZextTarget.getNode()); >>> ^ >>> /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2464:7: = error: use of undeclared identifier 'SelectCode' >>> SelectCode(Brind.getNode()); >>> ^ >>> /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:2480:5: = error: use of undeclared identifier 'SelectCode' >>> SelectCode(VSelect.getNode()); >>> ^ >>> /usr/src/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:3072:3: = error: use of undeclared identifier 'SelectCode' >>> SelectCode(Node); >>>=20 >>> Should I wait for an update, or run cleandir? This is on a Pi3. >>=20 >> =46rom which revision were you upgrading? > Probably revision 329997 >=20 >> It looks like your .inc files >> were not regenerated properly by llvm-tblgen, >=20 > The system has been plagued by stoppages during clang build. > Sometimes in llvm-tblgen, but not always. A frequent error > is 137, from clang, but "out of swap" happens too. Been using > the -DNO_CLEAN option to pick up where it left off. Right, I suspect that is the root cause here. When llvm-tblgen or clang-tblgen are writing a .inc file, and they are killed by OOM in the middle of it, the file will have been partially written, and most likely be incomplete. However, on the next NO_CLEAN run, make thinks the file is up-to-date, so starts the build of the dependencies of those .inc files, leading to errors like you report. Ideally the table-generated files should be atomically replaced, but we currently don't do that. Upstream also compares the output with any previous file, if it exists, and does not update it if it has not changed. I think I still have a diff laying around to do just that, but I never finished it up... In any case, my advice here would be to either add some swap space, or lower your -j level, to minimize the chance of files corrupted by OOM killing. -Dimitry --Apple-Mail=_205FB500-0588-41BB-A0D1-EBB9A8877F6A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWpRYcQAKCRCwXqMKLiCW o7tRAJ96D75xivNyiIYaYX+uE4H8INhPfgCgzZT9GdT8pYrc/l/xJKi/AdpasPA= =+OPK -----END PGP SIGNATURE----- --Apple-Mail=_205FB500-0588-41BB-A0D1-EBB9A8877F6A-- From owner-freebsd-arm@freebsd.org Mon Feb 26 21:42:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35C11F24DB5 for ; Mon, 26 Feb 2018 21:42:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B33D16AFD3 for ; Mon, 26 Feb 2018 21:42:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id c0bbad91 for ; Mon, 26 Feb 2018 22:42:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; s=mail; bh=t232RWfxfoOsAn/q2vzt2GF/2 xg=; b=t8FZAqCk8dFSB9+Hei1Hxgvnu3HsdHStliGvRM5CkZkgp+k9NKB2OpXQ7 6vCDUG8nnNGKPBWFDopCypObVU9U7gc65YB3yAMLf+UEDqJBE23s0JP86VWGPZhC zdyJuy0/Gjhao+1n62dj78s76q4N9lw7/sssmaoHOYvnu5Pej4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=p/BYmrrkL8KsHck1WJM pC1NSgewVln4aq3lGRwfENVlRkYhZaCxl+sBqfpMf0HNmrpxe7hIvUcsGhO2VtAG ed6ZO7a2Mqhl6U4VM6oG+cv6Q9ECBi178rwpoeOEWRKkCNsXVpY/tsJzMODzHISV EM8ImS4k/cgyWyWsXmnqXqsk= Received: from arcadia.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id aad2895c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Mon, 26 Feb 2018 22:42:14 +0100 (CET) Date: Mon, 26 Feb 2018 22:42:14 +0100 From: Emmanuel Vadot To: freebsd-arm@freebsd.org Subject: Rock64 status Message-Id: <20180226224214.64b14ec9f016f713cd8dec6f@bidouilliste.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 21:42:23 -0000 Hi arm@ I've just pushed the start of the Rock64 bits in the tree. Here is the current status : - Full boot to multiuser - Some clocks are supported - SD is supported (perf is around ~5MB/s for read and write) - eMMC isn't supported, we need regulators first - OTG seems to be probed but I haven't tested - OHCI work but we don't support the usb phy so it only works because the bootloader setup that for us Bootloader status : I don't plan to provide a port for this board, this board have an SPI flash which can hold u-boot for us. Hopefully this spi will be written in factory at some point, for now it isn't. >From https://github.com/ayufan-rock64/linux-build/releases download the image "u-boot-flash-spi-rock64.img.xz", dd that on an sdcard and boot your Rock64, this will flash u-boot on the spi and you won't need u-boot on the sdcard after that. This u-boot is based on 2017.09 which have some problems with EFI block devices, this means that using boot1.efi or loader.efi from the sdcard will fail. However netbooting works like a charm and for now this is perfect for me as I don't want to swap sdcard when doing kernel dev. I hope that the u-boot status will change soon. Current work : - Working on phase clock for the SD/MMC, this will probably give better performance. Futur work (mostly in order): - I2C driver - PMIC driver - Do a proper usbphy driver - Split generic-ehci in two parts : ACPI and FDT - ??? - Profit If you have any question or wanna help don't hesitate to answer this email. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Feb 27 11:27:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40442F3C397 for ; Tue, 27 Feb 2018 11:27:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1D1070410 for ; Tue, 27 Feb 2018 11:27:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0FD927BD8 for ; Tue, 27 Feb 2018 11:27:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1RBRsuL003618 for ; Tue, 27 Feb 2018 11:27:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1RBRs0c003616 for freebsd-arm@FreeBSD.org; Tue, 27 Feb 2018 11:27:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 226238] arm / arm64 kernel compilation broken by r330041 Date: Tue, 27 Feb 2018 11:27:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sylvain@sylvaingarrigues.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 11:27:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226238 Bug ID: 226238 Summary: arm / arm64 kernel compilation broken by r330041 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: sylvain@sylvaingarrigues.com The #include is in an #ifdef block not include= d on platforms other than i386 / amd64. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Feb 27 16:40:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F2B3F35A82 for ; Tue, 27 Feb 2018 16:40:55 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE3C781F6E for ; Tue, 27 Feb 2018 16:40:54 +0000 (UTC) (envelope-from amshafer64@gmail.com) Received: by mail-qk0-x229.google.com with SMTP id l206so24333775qke.1 for ; Tue, 27 Feb 2018 08:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=yYwxPODo5kdVn7/ik30/GzRlsZR37ahdiBptxrqZGHY=; b=q+DzEZOQbg0OPxo8hw29brV/HVKX1qshlTnJPKxFqPYCwekpfQTtYYICkfh/rZVTt4 v/yZCzBPjkb6U6nn7iVi46BAvhZ/VP/HoIZKJAVebpgu+NorSis3rKsSA7BPDbjGeRlM NGtlLpokPvprp7sLRhIvEuW0p0wZAdaMfkf8oyzBkySZKvrCGf7mqyX5dd2mqWQNMIqj K3Narpvo4Vrd5UEmcULWBscxx0FWbP3X0ZTotmj7QB8FB11danf6MNqTKl3Mv9V9eJbI SOwV8pQhWnPP5u7mMCoECrvFnlbZ/koZFvmMZ3992oIT8yC+ynylk7u19Y6Z6nMI4Imf Yzkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=yYwxPODo5kdVn7/ik30/GzRlsZR37ahdiBptxrqZGHY=; b=ayJmLs6agQYpu4gfCP5/ar80C6LUQK+0yAdkkVAZzCm5ICRwjfzyhl1QxcP71nvOwr zKJyRTtlCgtU3D/yXYQZo2iWaYqooG7havjQn2ArYRDOFT68oWNDTBfMqJ82kgvwHXAB 70MiApvCTZ1Kkk5oPvbNqw6/R1jazMF+JQBOTwksOw7nle/jkdrJzH1DuBPandddCPME SJrXuwL7oEFCPgurf836hqfCvVel0sFdrImVY77/Dwgc5qCWn2leki9faD5GVzL+Sa/7 s0lVTirlpbnXfnv+NI+O+rbqSDn8OHLTczy5He2YjCon4DnCUU+eXI2KeLk9bSp92ZT+ TRiA== X-Gm-Message-State: APf1xPCKmEEx/mVPH3GFxkeBpBIrX5O81xRb+1KaigmkAk/K+OaiAFJE UHnPEO5w7MQlVOnaG+1kUZcoQI/J X-Google-Smtp-Source: AG47ELs8QqCvDtBq5EpSRT6Pht79sL5osKmfZXfkeTE/F1+SgBzDmIc+nhf3uOxKWCeDp1hyDqPfFQ== X-Received: by 10.233.239.82 with SMTP id d79mr23023876qkg.190.1519749653877; Tue, 27 Feb 2018 08:40:53 -0800 (PST) Received: from [10.139.65.31] (ncsu-nat1-7.ncstate.net. [152.7.224.7]) by smtp.gmail.com with ESMTPSA id h200sm6449141qke.66.2018.02.27.08.40.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 08:40:53 -0800 (PST) From: Austin Shafer Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: [GSoc] Looking for a mentor for a summer of code project Message-Id: <35FBD594-BBCF-4FED-9975-F516E12B6AD5@gmail.com> Date: Tue, 27 Feb 2018 11:27:03 -0500 To: freebsd-arm@FreeBSD.org X-Mailer: Apple Mail (2.3445.5.20) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:40:55 -0000 Hi freebsd-arm, My name is Austin Shafer and I am looking for a Google Summer of = Code mentor. I loved reading Joseph Kong=E2=80=99s =E2=80=9CFreeBSD = Device Drivers: A Guide For The Intrepid=E2=80=9D and want to pursue a = project that could apply and build on what I had learned. The project = that caught my eye is =E2=80=9CImproving support for an embedded = CPU/Board=E2=80=9D.=20 = https://wiki.freebsd.org/SummerOfCodeIdeas#Improve_support_for_an_embedded= _CPU.2Fboard = A little about me, I am an undergraduate student in computer = science who has used a FreeBSD desktop for school development throughout = most of college. I interned at Juniper Networks last summer and got to = meet some great members of the FreeBSD community. Although I have done = plenty of C and assembly code programming, I am still new to OS = development and want to learn as much as I can. The project involves bringing support for hardware devices such = as SATA controllers, SD/MMC interfaces, I2C and SPI interfaces, sound, = graphics hardware (2D only), and USB/USB2/USB3. I was interested in = working on the BeagleBone (TI AM335x CPU) but I am interested to hear = your recommendations on what CPU/board I should pursue.=20 If you are interested in mentoring me or have suggestions for = what I should do please let me know! Thanks for your time, Austin Shafer= From owner-freebsd-arm@freebsd.org Tue Feb 27 23:41:37 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9087F34B5D for ; Tue, 27 Feb 2018 23:41:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0ACA777487 for ; Tue, 27 Feb 2018 23:41:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1RNfTLQ026049 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Feb 2018 15:41:30 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1RNfTgS026048; Tue, 27 Feb 2018 15:41:29 -0800 (PST) (envelope-from fbsd) Date: Tue, 27 Feb 2018 15:41:29 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: Custom kernel for RPi2 and 3 Message-ID: <20180227234129.GA25710@www.zefox.net> References: <20180220161900.GA2345@www.zefox.net> <20180221051801.GA73510@www.zefox.net> <1519229812.91697.61.camel@freebsd.org> <20180221181518.GA696@www.zefox.net> <1519242042.91697.116.camel@freebsd.org> <20180222012501.GA1313@www.zefox.net> <20180224165945.GA12197@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180224165945.GA12197@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:41:37 -0000 Recent tries at a custom kernel for Pi2 and Pi3 are mixed. Pi2 seems to work fairly well, but the size reduction isn't impressive. The latest try with a Pi3 kernel stopped with --- all_subdir_armv8crypto --- In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:228:25: error: typedef redefinition with d ifferent types ('int16_t' (aka 'short') vs '__int_fast16_t' (aka 'int')) typedef __int_least16_t int_fast16_t; ^ /usr/src/sys/sys/stdint.h:51:25: note: previous definition is here typedef __int_fast16_t int_fast16_t; ^ In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:229:26: error: typedef redefinition with different types ('uint16_t' (aka 'unsigned short') vs '__uint_fast16_t' (aka 'unsigned int')) typedef __uint_least16_t uint_fast16_t; ^ /usr/src/sys/sys/stdint.h:56:26: note: previous definition is here typedef __uint_fast16_t uint_fast16_t; ^ In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:245:24: error: typedef redefinition with different types ('int8_t' (aka 'signed char') vs '__int_fast8_t' (aka 'int')) typedef __int_least8_t int_fast8_t; ^ /usr/src/sys/sys/stdint.h:50:24: note: previous definition is here typedef __int_fast8_t int_fast8_t; ^ In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:246:25: error: typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs '__uint_fast8_t' (aka 'unsigned int')) typedef __uint_least8_t uint_fast8_t; ^ /usr/src/sys/sys/stdint.h:55:25: note: previous definition is here typedef __uint_fast8_t uint_fast8_t; ^ --- cam_queue.o --- Compilation was from a clean start, beginning with make -j1 kernel-toolchain. I re-ran svnlite update but didn't see any relevant changes and a retry failed as before. I also tried, on a whim cp /usr/lib/include/stdint.h /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/ just in case it might help, no difference (not surprising, the file, which used to be missing after make kernl-toolchain, apparently wasn't). The kernel config is at http://www.zefox.net/~fbsd/rpi3/kernel_config/ZEFOX if anybody would take a look for errors. It was ok as of r329893 Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Feb 28 17:03:14 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 572BBF35593 for ; Wed, 28 Feb 2018 17:03:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC0E682FFB for ; Wed, 28 Feb 2018 17:03:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1SH3Bs5028782 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Feb 2018 09:03:12 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1SH3BNo028781; Wed, 28 Feb 2018 09:03:11 -0800 (PST) (envelope-from fbsd) Date: Wed, 28 Feb 2018 09:03:11 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Is maximum swap usage tunable? Message-ID: <20180228170311.GA26187@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 17:03:14 -0000 In watching system compilations on an RPi3 it looks as if the system starts killing processes with "out of swap" warnings well below 50% of full utilization (in this case, 2 GB). One recent instance of make -j4 kernel-toolchain killed llvm-tblgen with only 34% of the swap in use. Is the maximum swap usage limit adjustable in any way? I didn't recognize anything useful in the page at https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports It's possible the problem is really swap speed, rather than size, so I'd like to try changing size limits if possible. The swap media claims 2-3 MB/sec random write speed and observations with gstat seem to support the claim, but transient stalls are hard to observe. An RPi2 with similar hardware seems to have no problems. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Feb 28 17:21:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 055E9F36A3A for ; Wed, 28 Feb 2018 17:21:13 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from oneyou.mgm51.net (oneyou.mgm51.net [IPv6:2607:f2f8:af30::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oneyou.mgm51.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98BC483BC3 for ; Wed, 28 Feb 2018 17:21:12 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (sentry.24cl.com [IPv6:2001:558:6017:94:c582:1d99:a986:7609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mgm51.net (Postfix) with ESMTPS id 3zs2Ql5GfdzWCYy for ; Wed, 28 Feb 2018 12:21:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mgm51.com; s=mgm51-02; t=1519838463; bh=TzLJ9ZsO6xh9OqOvpP6wkI034u3mkgtvU6m3Xkbe3sM=; h=Subject:To:From:Message-ID:Date; b=UQMzW8db9dh6tAimvg92jMEqIVbY0tJ8xgSVYtAaDqswESuibWawUvNXHWK1DA+vf jO16pPfJrup81ac6ayTcwbrZ73y09q1n8gwdQKwj/DczzkM2lZC9qT8+Kv9bOHf5/P C1tofZokWvV66lO00AOf7OYv+NOFzLIiKzZnYizaZTKR8nft9K4PZsEJNpPW4VLr0V xWMSCkhyP1EqwWznFX5C4twIULDLesRbgqXcZGy6XAEtKDq28KeP5JJPQhGuWnVFM0 O2pGhNUMVQ0YHEcvDYQg9xpsQzz3gJJowoduEhwCmrH8DBvF5iY6DjifVx+dcddgQi YpcakxAg6XDNQ== Received: from [IPv6:fdcf:b715:2f4d:1:a968:662f:4999:7781] (unknown [IPv6:fdcf:b715:2f4d:1:a968:662f:4999:7781]) by sentry.24cl.com (Postfix) with ESMTP id 3zs2Qk5GvHzkB4D for ; Wed, 28 Feb 2018 12:21:02 -0500 (EST) Subject: Re: Is maximum swap usage tunable? To: freebsd-arm@freebsd.org References: <20180228170311.GA26187@www.zefox.net> From: Mike Message-ID: Date: Wed, 28 Feb 2018 12:20:56 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180228170311.GA26187@www.zefox.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 17:21:13 -0000 On 2/28/2018 12:03 PM, bob prohaska wrote: > In watching system compilations on an RPi3 it looks as if the > system starts killing processes with "out of swap" warnings > well below 50% of full utilization (in this case, 2 GB). One > recent instance of make -j4 kernel-toolchain killed llvm-tblgen > with only 34% of the swap in use. > > Is the maximum swap usage limit adjustable in any way? I didn't > recognize anything useful in the page at > https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports > > It's possible the problem is really swap speed, rather than size, so I'd > like to try changing size limits if possible. The swap media claims 2-3 > MB/sec random write speed and observations with gstat seem to support the > claim, but transient stalls are hard to observe. An RPi2 with similar > hardware seems to have no problems. > > It's possible the problem is really swap speed I was running into swap speed / timeout issues. There were messages on the console to that effect. Once I put the swap space on rotating rust, that part of the compile problem disappeared. I use 1GB swap space. YMMV. From owner-freebsd-arm@freebsd.org Wed Feb 28 18:23:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01CFAF3ADA5 for ; Wed, 28 Feb 2018 18:23:51 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 A29A9863A8 for ; Wed, 28 Feb 2018 18:23:49 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ABB5520B97 for ; Wed, 28 Feb 2018 13:23:43 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 28 Feb 2018 13:23:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= caffeinated.codes; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ecHrPnRf2xtn+n3wVEJOu0nIcjKsbDgk2vcC5QVS7 ek=; b=vwUqXET4YY8zx73IQ3vfCduHdkegHloZpN8fPOPKjWy7kP/ZiG3bPvdvj apJe30twvD2x5LpL2B4EBTnLjTxYg+1Isc8oB0T7KvccigzgvgnLl7iQaaQaQiob PVynYmjWN0cNo3s7ejIqPlTEIle2EuEjqt0f1F1/g0GP57JYDo2a8ZwguxWsc2cY C7ip1f+twMFrH0a56I/3FWBRBrwJa0+iSlb+smjGmjhF35/Dh0dP6MmCNf6tF41K eO2Mie91Hn8hVIdUsrgaA487K0gMLZlQJHSzviXsJ5QcP/V7fIpB4HkH+hYe8JHZ q8O0eun03uFiBZoDilOnAT1W26fkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ecHrPnRf2xtn+n3wVEJOu0nIcjKsb Dgk2vcC5QVS7ek=; b=cFRggPt1FxxgGHrllS6fc6xqwBL6HkSSXyzkm2ah5z4Pm qzN4qf1K7OZUxCsyY4c9nCEqC8lr2b/tinhbpg510loK5rh+J479y0I0k+iqEIzu AY/E1oJXUGi/+rQHvA4E1y4tJ7esRlceZGK8MoteIY8wXCxvaoAYtk/UMai+MNgi r6eGqOnFPQF2esWnrnhrrsIxINsSdy49JtLOipu7iWejZeSshrzwtkYFbVZTx2F4 CBF2ArXDt+LaoyLjYlbbWXttTcd+DK3NKCd/+Cg1OIpbZkay+50++Jg1TxqruDOP QKmk1Nvw8W3FhF8q+IOwI9SW/XsR/1r4uCn13i07w== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 893939E111; Wed, 28 Feb 2018 13:23:43 -0500 (EST) Message-Id: <1519842223.2614418.1286772128.15A6E6C5@webmail.messagingengine.com> From: Hyun Hwang To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 Date: Wed, 28 Feb 2018 13:23:43 -0500 Subject: Stock image of armv7 RPI2 (r330034) hangs on loader after first boot, with red LED on. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 18:23:51 -0000 Hi, I re-imaged my RPi 2 with [the stock image](https://download.FreeBSD.org/ftp/snapshots/arm/armv7/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20180226-r330034.img.xz), but it hangs on second boot on the loader. First boot shows no problem at all. Loader finds the kernel, loads the dtb, and hands over to the kernel. Then kernel clears the screen and starts normal boot procedure. The problem occurs on the second boot. I first shut the pi down using `shutdown -h now`, unplugged it, and then immediately re-plugged to the power. This is what the screen reads: ``` Hit [Enter] to boot immediately, or any key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/bcm2836-rpi-2-b.dtb size=0x34cd Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. Kernel entry at 0x1200100... Kernel args: (null) ``` At this point, it does nothing. I have found that the very problem occurred [a month ago to bob](https://lists.freebsd.org/pipermail/freebsd-arm/2018-January/017310.html), but unlike their situation (self-built), this occurs on stock image. Can anyone look into this problem? In the meantime, I will try few other previous images that is still in download.FreeBSD.org. Thank you. -- Hyun Hwang From owner-freebsd-arm@freebsd.org Wed Feb 28 18:55:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02AD2F3D024 for ; Wed, 28 Feb 2018 18:55:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 735EE87C32 for ; Wed, 28 Feb 2018 18:55:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1SItIuZ029061 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Feb 2018 10:55:19 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1SItINn029060; Wed, 28 Feb 2018 10:55:18 -0800 (PST) (envelope-from fbsd) Date: Wed, 28 Feb 2018 10:55:17 -0800 From: bob prohaska To: Mike Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180228185517.GB26187@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 18:55:21 -0000 On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: > On 2/28/2018 12:03 PM, bob prohaska wrote: > > In watching system compilations on an RPi3 it looks as if the > > system starts killing processes with "out of swap" warnings > > well below 50% of full utilization (in this case, 2 GB). One > > recent instance of make -j4 kernel-toolchain killed llvm-tblgen > > with only 34% of the swap in use. > > > > Is the maximum swap usage limit adjustable in any way? I didn't > > recognize anything useful in the page at > > https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports > > > > It's possible the problem is really swap speed, rather than size, so I'd > > like to try changing size limits if possible. The swap media claims 2-3 > > MB/sec random write speed and observations with gstat seem to support the > > claim, but transient stalls are hard to observe. An RPi2 with similar > > hardware seems to have no problems. > > > > > > It's possible the problem is really swap speed > > I was running into swap speed / timeout issues. There were messages on > the console to that effect. > > Once I put the swap space on rotating rust, that part of the compile > problem disappeared. I use 1GB swap space. > The latest kernel versions seem to have largely done away with the "indefinite wait buffobj" warnings. They're few and far between, the compile proceeds unless they're abundant. The fact that armv7 has no problem, and the system is reporting "out of swap" with 34% in use strikes me as suspicious. Kernel and userland are in sync, so the figure of 34% swap usage is probably accurate. Perhaps my question is better phrased thus: How does FreeBSD-arm determine when it's out of swap? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Feb 28 19:37:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 918B2F3FDE9 for ; Wed, 28 Feb 2018 19:37:46 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from oneyou.mgm51.net (oneyou.mgm51.net [174.136.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oneyou.mgm51.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EC3D89A6C for ; Wed, 28 Feb 2018 19:37:45 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (sentry.24cl.com [IPv6:2001:558:6017:94:c582:1d99:a986:7609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mgm51.net (Postfix) with ESMTPS id 3zs5SR6MT7zWCVy; Wed, 28 Feb 2018 14:37:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mgm51.com; s=mgm51-02; t=1519846664; bh=ofko/flzEMSjeM9EqyfdZ+CQIBk1FKi/6MbA/wELxzE=; h=Subject:To:Cc:From:Message-ID:Date; b=lWO2+I70/rycwrf/NxEPR6XUv0ByIlyUXdmTS6z8XDrhpYi4Ex3voje5VcXZr57WE TnX4QQVMKvrCUGwxO8ToWZnRAC1vAHBrO7bpd/3NL0MZ5rYU2FWDfHDBX6zk41unug v79GYQgWVoK4hBub9xLWpdmZEsId8k/wOHizoqYXIEsIjGrkV5gMLTFZgkM17k4pZ1 ShfVndpnDFQlB1cBIsxRE24y5i0KMEV3k3CKT6C5K0tmKK+knUDaBcEBbIGh0FIB7k RBle4dWNSR2SBZAxSTNAwWcsFAB+O0EXID3DTNC1dkuJuyQ3LCtiayrLOEGuoZ2dru YljJ5WpUm0ocw== Received: from [IPv6:fdcf:b715:2f4d:1:a968:662f:4999:7781] (unknown [IPv6:fdcf:b715:2f4d:1:a968:662f:4999:7781]) by sentry.24cl.com (Postfix) with ESMTP id 3zs5SQ6KydzkB4D; Wed, 28 Feb 2018 14:37:42 -0500 (EST) Subject: Re: Is maximum swap usage tunable? To: bob prohaska Cc: freebsd-arm@freebsd.org References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> From: Mike Message-ID: <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> Date: Wed, 28 Feb 2018 14:37:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180228185517.GB26187@www.zefox.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 19:37:46 -0000 On 2/28/2018 1:55 PM, bob prohaska wrote: > On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: >> On 2/28/2018 12:03 PM, bob prohaska wrote: >>> In watching system compilations on an RPi3 it looks as if the >>> system starts killing processes with "out of swap" warnings >>> well below 50% of full utilization (in this case, 2 GB). One >>> recent instance of make -j4 kernel-toolchain killed llvm-tblgen >>> with only 34% of the swap in use. >>> >>> Is the maximum swap usage limit adjustable in any way? I didn't >>> recognize anything useful in the page at >>> https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports >>> >>> It's possible the problem is really swap speed, rather than size, so I'd >>> like to try changing size limits if possible. The swap media claims 2-3 >>> MB/sec random write speed and observations with gstat seem to support the >>> claim, but transient stalls are hard to observe. An RPi2 with similar >>> hardware seems to have no problems. >>> >> >> >>> It's possible the problem is really swap speed >> >> I was running into swap speed / timeout issues. There were messages on >> the console to that effect. >> >> Once I put the swap space on rotating rust, that part of the compile >> problem disappeared. I use 1GB swap space. >> > > The latest kernel versions seem to have largely done away with the > "indefinite wait buffobj" warnings. They're few and far between, > the compile proceeds unless they're abundant. The fact that armv7 > has no problem, and the system is reporting "out of swap" with 34% > in use strikes me as suspicious. Kernel and userland are in sync, > so the figure of 34% swap usage is probably accurate. > > Perhaps my question is better phrased thus: How does FreeBSD-arm > determine when it's out of swap? > Thanks for the follow-up. I was planning to download and try the RPI3-20180226-r330034 image file this evening. Per your comment, I'll not use the rusty swap space, and see what happens. I'll report back, probably on the morrow... thx. From owner-freebsd-arm@freebsd.org Wed Feb 28 19:46:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FEA1F4073F for ; Wed, 28 Feb 2018 19:46:25 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 2A4B48A079 for ; Wed, 28 Feb 2018 19:46:24 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 39AE820F26 for ; Wed, 28 Feb 2018 14:46:24 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 28 Feb 2018 14:46:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= caffeinated.codes; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+W8IbielDTI680ha/ uMkgHqPLZ1ZmT8Dh/FhsVJI4wc=; b=u9s6pS96zw9mKmLsR/zNZJr2RoqFdbsBS 9x5LxE96GMF6Zi0xedNA+iLypblMzIP/kGjURV2l1jj62P6itigQTKZ65Vwrn+VK g4KdSWkIKaUIuYXWQxXezfVgyZnE8AT2xTH4q+idbCI5lX9dqoYXWTMZFPAatvGD UqAf1oNopKOPZBufJQE7ddqemDWA6N2f4XvpmRBQ31HK9HeebdY1axYNqWPV/d/h TTuWN0uX9bHeSSdlHDW7+EWJegdbI9z+KJ38FA38umTSSb5ye3dxZYBfYQrNsLUc bzC/ZFo1TBfcBn0nmN3oo08+iSpUSlJxnTh4h4ZNYrTANQi8FsDYQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+W8Ibi elDTI680ha/uMkgHqPLZ1ZmT8Dh/FhsVJI4wc=; b=S9GrRiH5wOpJU3sYsjxko/ viKCh9XYMofsSisZ58uQ4Kdmf5seg4pQaFsMz+798HW4vmAGEw0HGt5gokANHDgz a4RMzPTD14Za2/m3U226M4hly7wMah/Oqu3mxN3pA2hBiHIkLRaaDCqOcoS/zc54 smleECeUHE9KHiAm09KFZQ0cyONnogPasPQ2S8jCoISD52zTyxkf171iiZgUGv15 n2g167pRGmtsLJZGb3xU5tUa9hpk6Ip+tTGwFvfBzwqRKT93AgXkqZ/P4MgtRZgo CqSKI+Wx67fTMGOextT0QjxOWsmOOcBHCeL35iolrQPgzbibAvMLof3C9PTq8DSw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1D2589E217; Wed, 28 Feb 2018 14:46:24 -0500 (EST) Message-Id: <1519847184.3588780.1286870920.4B6980E3@webmail.messagingengine.com> From: Hyun Hwang To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 Date: Wed, 28 Feb 2018 14:46:24 -0500 References: <1519842223.2614418.1286772128.15A6E6C5@webmail.messagingengine.com> Subject: Re: Stock image of armv7 RPI2 (r330034) hangs on loader after first boot, with red LED on. In-Reply-To: <1519842223.2614418.1286772128.15A6E6C5@webmail.messagingengine.com> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 19:46:25 -0000 On Wednesday, February 28, 2018, 1:23 PM (UTC-0500), Hyun Hwang wrote: > Hi, > > I re-imaged my RPi 2 with [the stock image] > (https://download.FreeBSD.org/ftp/snapshots/arm/armv7/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20180226-r330034.img.xz), > but it hangs on second boot on the loader. > > First boot shows no problem at all. Loader finds the kernel, loads the > dtb, and hands over to the kernel. Then kernel clears the screen and > starts normal boot procedure. > The problem occurs on the second boot. I first shut the pi down using > `shutdown -h now`, unplugged it, and then immediately re-plugged to the > power. > > This is what the screen reads: > ``` > Hit [Enter] to boot immediately, or any key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/dtb/bcm2836-rpi-2-b.dtb size=0x34cd > Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. > Kernel entry at 0x1200100... > Kernel args: (null) > ``` > At this point, it does nothing. > > I have found that the very problem occurred [a month ago to bob] > (https://lists.freebsd.org/pipermail/freebsd-arm/2018-January/017310.html), > but unlike their situation (self-built), this occurs on stock image. > > Can anyone look into this problem? In the meantime, I will try few other > previous images that is still in download.FreeBSD.org. > > Thank you. > -- > Hyun Hwang I just checked stock image at r329009, and it boots fines even after the first boot. So some commit after r329009 is causing behavior, but frankly, I have no idea where to start looking, since this weird hang does not print any detailed message out even if I set `verbose_loading="YES"` and `boot_verbose="YES"` in `/boot/loader.conf.local`. It just sits there and do nothing after that `Kernel args: (null)` line. Any lead is appreciated. -- Hyun Hwang From owner-freebsd-arm@freebsd.org Wed Feb 28 20:15:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 710BFF42604 for ; Wed, 28 Feb 2018 20:15:21 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0F138B693 for ; Wed, 28 Feb 2018 20:15:20 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 179786d4-1cc4-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 179786d4-1cc4-11e8-91c6-33ffc249f3e8; Wed, 28 Feb 2018 20:15:18 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1SKFDV2081962; Wed, 28 Feb 2018 13:15:13 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1519848913.91697.387.camel@freebsd.org> Subject: Re: Is maximum swap usage tunable? From: Ian Lepore To: bob prohaska , Mike Cc: freebsd-arm@freebsd.org Date: Wed, 28 Feb 2018 13:15:13 -0700 In-Reply-To: <20180228185517.GB26187@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 20:15:21 -0000 On Wed, 2018-02-28 at 10:55 -0800, bob prohaska wrote: > On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: > > > > On 2/28/2018 12:03 PM, bob prohaska wrote: > > > > > > In watching system compilations on an RPi3 it looks as if the > > > system starts killing processes with "out of swap" warnings  > > > well below 50% of full utilization (in this case, 2 GB). One > > > recent instance of make -j4 kernel-toolchain killed llvm-tblgen > > > with only 34% of the swap in use. > > > > > > Is the maximum swap usage limit adjustable in any way? I didn't > > > recognize anything useful in the page at > > > https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports  > > > > > > It's possible the problem is really swap speed, rather than size, so I'd > > > like to try changing size limits if possible. The swap media claims 2-3  > > > MB/sec random write speed and observations with gstat seem to support the > > > claim, but transient stalls are hard to observe. An RPi2 with similar  > > > hardware seems to have no problems. > > > > > > > > > > > It's possible the problem is really swap speed > > I was running into swap speed / timeout issues.  There were messages on > > the console to that effect. > > > > Once I put the swap space on rotating rust, that part of the compile > > problem disappeared.  I use 1GB swap space. > > > The latest kernel versions seem to have largely done away with the > "indefinite wait buffobj" warnings. They're few and far between, > the compile proceeds unless they're abundant. The fact that armv7 > has no problem, and the system is reporting "out of swap" with 34% > in use strikes me as suspicious. Kernel and userland are in sync,  > so the figure of 34% swap usage is probably accurate.  > > Perhaps my question is better phrased thus: How does FreeBSD-arm  > determine when it's out of swap? > > Thanks for reading, > > bob prohaska You are reading too much into the phrase "out of swap". It doesn't mean literally "all sectors of all swapfiles are occupied with live data".  It just means "out of memory".  It can happen because it's unable to move more data to swap fast enough due to some short peak demand.  It can happen for other reasons too, like all disk buffers in use, or running out of resources to track the data in swap, or the system can't find any more pages eligible to be moved out to swap. It looks like the message that indicates swap space is truly full is   swap_pager: out of swap space Is that what you're seeing?  Or are you seeing processes killed with an out of swap space message? -- Ian From owner-freebsd-arm@freebsd.org Wed Feb 28 20:39:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56904F43F2B for ; Wed, 28 Feb 2018 20:39:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E10CB8C617 for ; Wed, 28 Feb 2018 20:39:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id w63so5031493ita.3 for ; Wed, 28 Feb 2018 12:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=s39S65+InW6HqqagibWtMNdVgv4BEhnTX64JWwVtpqU=; b=uYUBH7dObtQm0ikjvmuQsW1k3vpKaM3XBREybsMiJyYcjRbswigFwuwNKUzRS/rc5z n5oyWJ03acnMPgVmiNHCY5jVjeRSS4pJatu2u8CYGuRddSwNq9ieEnccikZ0O0xs/Qzp DANkurB/AH3wjx1biIBH12GXPLYxv4v8xOorSIAa14JCfoRhFNjEMpIRZaRmyy9d5Tbt wISjdrwZ+SNSiqEJj2KdT9i6vlR9eM5oX+uuBJhMeJ9ENCCrU1eDEmpvAdKKfHGIyMX6 w5IOhYMLKzp/SGubAHzd3BPh6WlRVpyNb8wSDHsuGlCy8fpcHCLbp/3RPG9O+TPvrlMS dh+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=s39S65+InW6HqqagibWtMNdVgv4BEhnTX64JWwVtpqU=; b=k3eiCi7sqE/QmRFuC6G0AsUcZhuxSP5HznEXvfsXkhbxpaoCeK7aHwyjsyifDztlqs IWoODSi4tNh4rW1fOMUIAen2NVEF2N6w+mVz6zrhQfSV2HHOde1fL39beMa1sbjVD0Os S0+ur8whtEYqlsWEbBU3EjjjA0LWNCM9nJnNlindnad4yJwSpY7LzswTvJI5rTAT6Ay0 1odn26qB6RmFr+K62Vcq78xfOcQ0JhGGTPVriSYHeA22/Az4P4IuDIy+z6S9bIwsfZOB ScUfifbcNJvp7oMsF2iCNy1287QLg54+lL1vAdZYhHFZMCmOjqW/C9eMrjPh0uO8NW5C Q4qg== X-Gm-Message-State: APf1xPC748oDeJyMKbIqYB1EZWN8lBpazVhkGLCph/lHeLA+sO7TwzIL DpAUPBM9O0xmAvY8yWF/RKNpkIM6RS4/s4qE5ZDVTQp9 X-Google-Smtp-Source: AG47ELsNOiYhISBH9B3SOkGb+w1kulCzOZ+3moRGEJKme5P7u7bkvoASUwXIeXCMKkXtycRAa+iDjaAIKAAYEQYa7Y8= X-Received: by 10.36.4.65 with SMTP id 62mr7584791itb.57.1519850349090; Wed, 28 Feb 2018 12:39:09 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 28 Feb 2018 12:39:08 -0800 (PST) X-Originating-IP: [50.227.106.226] In-Reply-To: <1519847184.3588780.1286870920.4B6980E3@webmail.messagingengine.com> References: <1519842223.2614418.1286772128.15A6E6C5@webmail.messagingengine.com> <1519847184.3588780.1286870920.4B6980E3@webmail.messagingengine.com> From: Warner Losh Date: Wed, 28 Feb 2018 13:39:08 -0700 X-Google-Sender-Auth: scGooxaDyKLVS2AbkQ5nWIiqZ54 Message-ID: Subject: Re: Stock image of armv7 RPI2 (r330034) hangs on loader after first boot, with red LED on. To: Hyun Hwang Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 20:39:10 -0000 On Wed, Feb 28, 2018 at 12:46 PM, Hyun Hwang wrote: > On Wednesday, February 28, 2018, 1:23 PM (UTC-0500), Hyun Hwang > wrote: > > Hi, > > > > I re-imaged my RPi 2 with [the stock image] > > (https://download.FreeBSD.org/ftp/snapshots/arm/armv7/ISO- > IMAGES/12.0/FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20180226-r330034.img.xz), > > but it hangs on second boot on the loader. > > > > First boot shows no problem at all. Loader finds the kernel, loads the > > dtb, and hands over to the kernel. Then kernel clears the screen and > > starts normal boot procedure. > > The problem occurs on the second boot. I first shut the pi down using > > `shutdown -h now`, unplugged it, and then immediately re-plugged to the > > power. > > > > This is what the screen reads: > > ``` > > Hit [Enter] to boot immediately, or any key for command prompt. > > Booting [/boot/kernel/kernel]... > > /boot/dtb/bcm2836-rpi-2-b.dtb size=0x34cd > > Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. > > Kernel entry at 0x1200100... > > Kernel args: (null) > > ``` > > At this point, it does nothing. > > > > I have found that the very problem occurred [a month ago to bob] > > (https://lists.freebsd.org/pipermail/freebsd-arm/2018- > January/017310.html), > > but unlike their situation (self-built), this occurs on stock image. > > > > Can anyone look into this problem? In the meantime, I will try few other > > previous images that is still in download.FreeBSD.org. > > > > Thank you. > > -- > > Hyun Hwang > > I just checked stock image at r329009, and it boots fines even after the > first boot. > So some commit after r329009 is causing behavior, but frankly, I have no > idea where to start looking, since this weird hang does not print any > detailed message out even if I set `verbose_loading="YES"` and > `boot_verbose="YES"` in `/boot/loader.conf.local`. It just sits there and > do nothing after that `Kernel args: (null)` line. > > Any lead is appreciated. > You might try entropy_cache_load="NO" in your loader.conf.loader and see if that helps. From owner-freebsd-arm@freebsd.org Wed Feb 28 21:05:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65F5DF22AB8 for ; Wed, 28 Feb 2018 21:05:42 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 1202A8D638 for ; Wed, 28 Feb 2018 21:05:41 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3DF1620CA5; Wed, 28 Feb 2018 16:05:41 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 28 Feb 2018 16:05:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= caffeinated.codes; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=R0zqZ/ EJuIFKTGwet2zz3+zsNTFjGuvh979s6SNL0sE=; b=GyQFmYfPM2jV4eXOtITLAq rVrbSWMPAxEm0iCQOvddcEX8pp8Ph0tidNJor2QIKcHDSACYFYMomIW9GQV/xnqY FYMCxCcX61pBf4QdNyaWQANKEVae2AInLgFoRQX/gZD+BqIo6XtQG4LWF7wOf0yo DryDP99s5VjDciyO29mp4cru/zDoBHIPQ2aarbMljkqbEZjJp0PefF0mB662I9Jy uvfve0/lsyKLhqE+lL7eXcJ6QQStau9tWVCLf4eEp2oVs6XqQzKqrrOllCX9V1AY yMzqQwY8JSBry1WyNF6UXfCIRI687X9URBjv4mv7bNlASTep3iZ/PIizVZOzwn8A == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=R0zqZ/ EJuIFKTGwet2zz3+zsNTFjGuvh979s6SNL0sE=; b=Nwze8KGOgQbG9MZ2Ns+M1W ZflR9iXudZcCvPctZfU0i1NIw25v1XskBoMFyA25XXDYqguFkGyWm/IzQ8aDkf57 dWdIN5BW2esPiurmIioOFpwEhXwmSHZtARmL6zTd5IlBoD6Fzn+oTXIPv7LjLdCH r85AldCzFZe8eUzgq/v5OnhvbZ8Iwu0l0JMyv3DXGKevyXU+Px9Z9O4iIbvxGMId h1rpu0//bAS8v7hcPA5a/EuGDlKuAWJvDMwXMT0/Am+eyga69ciZQKbURFXJe2yS ++2Q/Fq2f1A9sWIp8xZImvSV/LLEljTQA16SfxcCe9CDYHxuofjd9hvLsthbOj4Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0FF409E111; Wed, 28 Feb 2018 16:05:40 -0500 (EST) Message-Id: <1519851940.3648574.1286973904.4C0CF889@webmail.messagingengine.com> From: Hyun Hwang To: Warner Losh Cc: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 Subject: Re: Stock image of armv7 RPI2 (r330034) hangs on loader after first boot, with red LED on. Date: Wed, 28 Feb 2018 16:05:40 -0500 References: <1519842223.2614418.1286772128.15A6E6C5@webmail.messagingengine.com> <1519847184.3588780.1286870920.4B6980E3@webmail.messagingengine.com> In-Reply-To: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 21:05:42 -0000 On Wednesday, February 28, 2018, 1:39 PM (UTC-0700), Warner Losh wrote: > You might try entropy_cache_load="NO" in your loader.conf.loader and see if > that helps. > That did resolve the issue! Now on r330034 the Pi boots normally. Thank you! -- Hyun Hwang From owner-freebsd-arm@freebsd.org Wed Feb 28 21:43:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D099F258A8 for ; Wed, 28 Feb 2018 21:43:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B8538F111 for ; Wed, 28 Feb 2018 21:43:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1SLh1hm029500 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Feb 2018 13:43:02 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1SLh14m029499; Wed, 28 Feb 2018 13:43:01 -0800 (PST) (envelope-from fbsd) Date: Wed, 28 Feb 2018 13:43:01 -0800 From: bob prohaska To: Mike Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180228214301.GA29481@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 21:43:04 -0000 On Wed, Feb 28, 2018 at 02:37:36PM -0500, Mike wrote: > On 2/28/2018 1:55 PM, bob prohaska wrote: > > On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: > >> On 2/28/2018 12:03 PM, bob prohaska wrote: > >>> In watching system compilations on an RPi3 it looks as if the > >>> system starts killing processes with "out of swap" warnings > >>> well below 50% of full utilization (in this case, 2 GB). One > >>> recent instance of make -j4 kernel-toolchain killed llvm-tblgen > >>> with only 34% of the swap in use. > >>> > >>> Is the maximum swap usage limit adjustable in any way? I didn't > >>> recognize anything useful in the page at > >>> https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports > >>> > >>> It's possible the problem is really swap speed, rather than size, so I'd > >>> like to try changing size limits if possible. The swap media claims 2-3 > >>> MB/sec random write speed and observations with gstat seem to support the > >>> claim, but transient stalls are hard to observe. An RPi2 with similar > >>> hardware seems to have no problems. > >>> > >> > >> > >>> It's possible the problem is really swap speed > >> > >> I was running into swap speed / timeout issues. There were messages on > >> the console to that effect. > >> > >> Once I put the swap space on rotating rust, that part of the compile > >> problem disappeared. I use 1GB swap space. > >> > > > > The latest kernel versions seem to have largely done away with the > > "indefinite wait buffobj" warnings. They're few and far between, > > the compile proceeds unless they're abundant. The fact that armv7 > > has no problem, and the system is reporting "out of swap" with 34% > > in use strikes me as suspicious. Kernel and userland are in sync, > > so the figure of 34% swap usage is probably accurate. > > > > Perhaps my question is better phrased thus: How does FreeBSD-arm > > determine when it's out of swap? > > > > > Thanks for the follow-up. > > I was planning to download and try the > > RPI3-20180226-r330034 > > image file this evening. Per your comment, I'll not use the rusty swap > space, and see what happens. > > I'll report back, probably on the morrow... > FWIW, I've been using Sandisk Extreme USB 3 flash drives for /usr /var/ and swap on the Pi3. It seems that flash write speed is a tighter bottleneck than USB 2.0 ports on the Pi. Attempts to use older, slower USB 2 flash drives on a Pi2 didn't work, though the symptoms were never "out of swap". Good luck! bob prohaska From owner-freebsd-arm@freebsd.org Wed Feb 28 21:51:39 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 608BAF264A4 for ; Wed, 28 Feb 2018 21:51:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D3D6A8F8A2; Wed, 28 Feb 2018 21:51:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1SLpbaG029534 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Feb 2018 13:51:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1SLpaM1029533; Wed, 28 Feb 2018 13:51:36 -0800 (PST) (envelope-from fbsd) Date: Wed, 28 Feb 2018 13:51:36 -0800 From: bob prohaska To: Ian Lepore Cc: Mike , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180228215136.GB29481@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <1519848913.91697.387.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1519848913.91697.387.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 21:51:39 -0000 On Wed, Feb 28, 2018 at 01:15:13PM -0700, Ian Lepore wrote: > On Wed, 2018-02-28 at 10:55 -0800, bob prohaska wrote: > > On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: > > > > > > On 2/28/2018 12:03 PM, bob prohaska wrote: > > > > > > > > In watching system compilations on an RPi3 it looks as if the > > > > system starts killing processes with "out of swap" warnings? > > > > well below 50% of full utilization (in this case, 2 GB). One > > > > recent instance of make -j4 kernel-toolchain killed llvm-tblgen > > > > with only 34% of the swap in use. > > > > > > > > Is the maximum swap usage limit adjustable in any way? I didn't > > > > recognize anything useful in the page at > > > > https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports? > > > > > > > > It's possible the problem is really swap speed, rather than size, so I'd > > > > like to try changing size limits if possible. The swap media claims 2-3? > > > > MB/sec random write speed and observations with gstat seem to support the > > > > claim, but transient stalls are hard to observe. An RPi2 with similar? > > > > hardware seems to have no problems. > > > > > > > > > > > > > > > It's possible the problem is really swap speed > > > I was running into swap speed / timeout issues.??There were messages on > > > the console to that effect. > > > > > > Once I put the swap space on rotating rust, that part of the compile > > > problem disappeared.??I use 1GB swap space. > > > > > The latest kernel versions seem to have largely done away with the > > "indefinite wait buffobj" warnings. They're few and far between, > > the compile proceeds unless they're abundant. The fact that armv7 > > has no problem, and the system is reporting "out of swap" with 34% > > in use strikes me as suspicious. Kernel and userland are in sync,? > > so the figure of 34% swap usage is probably accurate.? > > > > Perhaps my question is better phrased thus: How does FreeBSD-arm? > > determine when it's out of swap? > > > > Thanks for reading, > > > > bob prohaska > > You are reading too much into the phrase "out of swap". It doesn't > mean literally "all sectors of all swapfiles are occupied with live > data". ?It just means "out of memory". ?It can happen because it's > unable to move more data to swap fast enough due to some short peak > demand. ?It can happen for other reasons too, like all disk buffers in > use, or running out of resources to track the data in swap, or the > system can't find any more pages eligible to be moved out to swap. > > It looks like the message that indicates swap space is truly full is > > ? swap_pager: out of swap space > > Is that what you're seeing? ?Or are you seeing processes killed with an > out of swap space message? > I'm seeing Feb 27 18:41:50 www kernel: pid 46399 (llvm-tblgen), uid 0, was killed: out of swap space but never anything referencing swap_pager. As it happens, the machine is still using two swap partitions, one on USB flash and one on the microSD card. Another correspondent reported that swap on microSD was troublesome, I thought that problem was fixed. Maybe I was mistaken and should repeat the experiment. Thanks for clarifying the terminology! bob prohaska From owner-freebsd-arm@freebsd.org Wed Feb 28 22:48:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A776F2A2DA for ; Wed, 28 Feb 2018 22:48:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25ED06A23D for ; Wed, 28 Feb 2018 22:48:57 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8acd73d2-1cd9-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 8acd73d2-1cd9-11e8-91c6-33ffc249f3e8; Wed, 28 Feb 2018 22:48:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1SMmkhb082263; Wed, 28 Feb 2018 15:48:46 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1519858126.91697.391.camel@freebsd.org> Subject: Re: Stock image of armv7 RPI2 (r330034) hangs on loader after first boot, with red LED on. From: Ian Lepore To: Hyun Hwang , Warner Losh Cc: freebsd-arm@freebsd.org Date: Wed, 28 Feb 2018 15:48:46 -0700 In-Reply-To: <1519851940.3648574.1286973904.4C0CF889@webmail.messagingengine.com> References: <1519842223.2614418.1286772128.15A6E6C5@webmail.messagingengine.com> <1519847184.3588780.1286870920.4B6980E3@webmail.messagingengine.com> <1519851940.3648574.1286973904.4C0CF889@webmail.messagingengine.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 22:48:58 -0000 On Wed, 2018-02-28 at 16:05 -0500, Hyun Hwang wrote: > On Wednesday, February 28, 2018, 1:39 PM (UTC-0700), Warner Losh @bsdimp.com> wrote: > > > > You might try entropy_cache_load="NO" in your loader.conf.loader > > and see if > > that helps. > > > That did resolve the issue! Now on r330034 the Pi boots normally. > > Thank you! I just committed the real fix in r330131.  Basically any copies of ubldr built between rr329190 and rr330131 won't load modules properly, with the symptom being a lockup or kernel panic early in boot.  If you load no modules in loader, everything should be fine; loading modules after the kernel has started works in all versions. -- Ian From owner-freebsd-arm@freebsd.org Thu Mar 1 11:23:22 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CFD3F3BAE6 for ; Thu, 1 Mar 2018 11:23:22 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 C0C917D46E for ; Thu, 1 Mar 2018 11:23:21 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-it0-x230.google.com with SMTP id w19so17639831ite.0 for ; Thu, 01 Mar 2018 03:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lTfemm55SM13papQPb/RwoDNC6NNULSOlLgIBxWGvdk=; b=mLw3RQLgbef6Nrx4C07iy3kC9ERNrzV4ZFiYaHH4Hr/LCoh6GcYuIKD1ycZbw9uzwP R5fKjvKxQkK2t/J4ZmS7mlSs7pIY5YZ0g4bTWNR9AciVthztw2ijhhrV9+/C5Ct/pi8K x7WFJ2SjQzUH2RLb7x8gB4bXHk9RWyi7urXUCCgHfpJVjOyj7Au0QJVkRZTx4DwyZ0FN HrMbRjUB29hE/8AEji7uP2vOvmy0vxz6ClAT7NtRfvtl6QESemyQz4omMMSbZxHEzEEM jpBiK+2cHB09NrFZvZZ3gKVJCmz3Zq0g4X3M8n2QPHU/hjQUGc8cL1er72zOrlCzClRR Fl/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lTfemm55SM13papQPb/RwoDNC6NNULSOlLgIBxWGvdk=; b=LOjTBnTPlx8OY0tYuaSCIkzyXq+6n0Ct8AEGfCFZTy3VYbmQU+CAXgwW+xeg1MBAd3 4Tll4OOIPxyIMCmhVKCcER+yjvk8ANe9aM7pAJdIyiWCPQlQIb1BdklSfKtywFLoYdV/ LUbam8l38mTz24ESIpJaQRylZKrRp36mghpMjmUEf5mb2mIzXTT4esom4Ck92cpgL79+ zkh1Sp6RXmZWXh4fzJcRt17EuoOrJYolycrD7Y1aMrJhKhkpVRwO/umAdQOvAqPQ3UDh ZLGsnDRo1Xg838+hX72FZ1rdpu8eMkRWfizkdF6fLAA8TpOqsrtWnP205FDG/zcKDQbd nL6g== X-Gm-Message-State: APf1xPDUr33lbt6gkXwt38oGgvT++WsI1JJPqwBPg2raplrb6bmSe+Fv zWlytLHtperupPa7TO5q7g1Oy05cGjSUUwJbdtBgdK58 X-Google-Smtp-Source: AG47ELt5BLC6ujw/sCUw64zb0mCpEW20isk7ZjLyZ1hQrXo0enXzgdSRjQAlhMIOMUDufqpl/n5LV+UWb+SeH+//kXM= X-Received: by 10.36.142.2 with SMTP id h2mr2211459ite.5.1519903401154; Thu, 01 Mar 2018 03:23:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.3.79 with HTTP; Thu, 1 Mar 2018 03:23:20 -0800 (PST) In-Reply-To: References: <31CD451B-DD39-4F20-91CD-FD60A857A8A3@freebsd.org> From: Marcin Wojtas Date: Thu, 1 Mar 2018 12:23:20 +0100 Message-ID: Subject: Re: ThunderX2 support To: Ed Maste Cc: Michael Tuexen , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 11:23:22 -0000 Hi Ed, 2018-02-26 16:10 GMT+01:00 Ed Maste : > On 20 February 2018 at 07:55, Michael Tuexen wrote: >> >> Hi Ed, >> >> thanks for the feedback. I guess it is planned that ThunderX2 is supported sometimes >> in the future? > > Yes - thanks to Cavium we have access to a ThunderX2 system for > development, and Andrew Turner has made some good progress addressing > issues we've found (e.g. r329906, r329990, r329991, r330016). We don't > have a timeline on full support yet though. What exactly SoC revision (T99?) and board you have access to? Best regards, Marcin From owner-freebsd-arm@freebsd.org Thu Mar 1 23:17:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78F03F330EC for ; Thu, 1 Mar 2018 23:17:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D36B77F995 for ; Thu, 1 Mar 2018 23:17:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w21NHpvr033431 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Mar 2018 15:17:52 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w21NHpea033430; Thu, 1 Mar 2018 15:17:51 -0800 (PST) (envelope-from fbsd) Date: Thu, 1 Mar 2018 15:17:51 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Strange svnlite error, database disk image is malformed on Pi3 Message-ID: <20180301231751.GA33421@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 23:17:59 -0000 Just ran svnlite up /usr/src on a Pi3 and got svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for det ails) svn: E155004: Working copy '/usr/src' locked. svn: E155004: '/usr/src' is already locked. root@www:/usr/src # svnlite cleanup . svn: E200030: sqlite[S11]: database disk image is malformed svn: E200042: Additional errors: svn: E200030: sqlite[S11]: database disk image is malformed Any hint as to what's wrong or how to recover would be much apprediated. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Fri Mar 2 02:39:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66F7AF3FEC2 for ; Fri, 2 Mar 2018 02:39:16 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh504-vm5.bullet.mail.kks.yahoo.co.jp (nh504-vm5.bullet.mail.kks.yahoo.co.jp [183.79.57.91]) by mx1.freebsd.org (Postfix) with SMTP id 70643865D1 for ; Fri, 2 Mar 2018 02:39:14 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.141] by nh504.bullet.mail.kks.yahoo.co.jp with NNFMP; 02 Mar 2018 02:36:53 -0000 Received: from [183.79.100.135] by t504.bullet.mail.kks.yahoo.co.jp with NNFMP; 02 Mar 2018 02:36:53 -0000 Received: from [127.0.0.1] by omp504.mail.kks.yahoo.co.jp with NNFMP; 02 Mar 2018 02:36:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 44523.19646.bm@omp504.mail.kks.yahoo.co.jp Received: (qmail 32369 invoked by uid 60001); 2 Mar 2018 02:36:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1519958212; bh=OwhMGQl1sdWCR25lJI8XG7N8Cae8AQf8z4IlEu/+U3c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W33xHf6pZmxzX5LkzptnlBz7pTNf5M5VW1faoiVZOdpVLzzYNfHmg3+tzD5hVIMWZLyLk9XvmdEU5Y9PxoBB2ar0eGE/ARXAWcY3p/Sw8AoLHbQ9+ZTUlcaYiu8of/y/QGCoBrLQyMCtR9b0w2DgBGDGZvk9VMWh6UmDLPrZ9t4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IXdIv/Sjjyqt5Z7tnNF1yFB9jBAHi9zUGK5X+BOLIhr9S8TEy76mTS+eJwsprJ9Qvj8Bf6bKp1+3wF0qDJgjCzvd/DveV14A6kvsiqziJSgL8wpJUaCEPxEBR9FCKo/E1ueXlDGUiIv/TzU2otTY3PqpdcaYnIOrM5o7GEIWgEk=; Message-ID: <719458.13334.qm@web101701.mail.ssk.yahoo.co.jp> X-YMail-OSG: KLB_SJ4VM1m08FXFTWf7hZEQ4sBGj2f2DT3sQl3JqH.J53ZxLAIfinN_nwZMW4rKF7f2S8yJbChaMqlKzjbayaI.UDGmfBL6NBZ0yjfDHat9TTpnH4DYRtxMOZqcZBpUQPYyKa2f6dSIR4mspFC.r5rOOjFhbkM8LoxcBvh8OtTuyHfxwC.lruVk8SHkTsWFk2zpvggqnvgpSD8at3982cos3aSuQW_H.qu8v4RFNtBEuMen26nSx.w98A3flzbZRGy4xkC_Qfbuwa4nMhfKRgt12oIRyFTKJGiazIqf7jpuAbtGfWnTZCHXaV6QE.QHnvQDTsT6VD4djKDXg1.nsKbgJNUiTd0DAoHkJ0_GYa_QWDvDGu9TxouVKLocHPItY3PVIfVjX5N_q8G1bFAncmo4mX26xL7ESJspc.BEf2hyuZ.wXZlW9_oC8nCDsRJaIN_t8N3p.wO4hDshBXs4Sgoi9Ry0WOnafjJFvX8LNGAi.QscxDIvKzUqkj_wLvJPGyRKKAtcQ3BmPtUfrwsTzRpxHZKx1rBLzxnjj6ZZ46CKNfbGe.CgdED1BD6VUd32xcugwYK._eGZoSdlA1xRxpjOzcHRmEJGwkCEIz7Nwi0yAR7OG.Wm.cm6h4wI8KqY Received: from [203.165.91.75] by web101701.mail.ssk.yahoo.co.jp via HTTP; Fri, 02 Mar 2018 11:36:51 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: T9b6.fUVM1kgMCv88.SFFsXCzOjKcGFnk7RgwhZF_LlZSl7DWgqavBgWxX8zkyFhfM4C5r6ki0Tj_dQh9NidpH4hJDB8OsVWzrlTeQoyg8wOnth1WasUdZqsV.ARl21baNoG Date: Fri, 2 Mar 2018 11:36:51 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: CFI write fix review To: "freebsd-arm@freebsd.org" , "freebsd-mips@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 02:39:16 -0000 Hi=0A=0ASorry double post.=0A=0AI make mx(amd type) cfi flash write fix.=0A= =0ACurrent code is broke boot if not protected boot sector=0Aby write opera= tion.=A0=0A=0AIf you use mx flash. Please check this.=0A=0Ahttps://reviews.= freebsd.org/D14279=0A=0A=0ABe carefull this is very=A0dangerous.=0A=0AIf yo= u broke boot, It's only brick.=A0=0A=0AIf you do brick then you must use jt= ag and restore boot.=0A=0AThanks=0A=0AHiroki Mori From owner-freebsd-arm@freebsd.org Fri Mar 2 06:40:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E39CF28C4E for ; Fri, 2 Mar 2018 06:40:49 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AB396FD0D; Fri, 2 Mar 2018 06:40:48 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id n7so8949692wrn.5; Thu, 01 Mar 2018 22:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=azQ/hYecD5LdwT5b7lHlb3aYYgAE0jlaPR/whhIx0o8=; b=YmtbqgKkdc1keF/3Hs7uI3Un5nJsNU3546N+Le+ul9DuL06vCp83pSg7tVzJisRXyh YERVLghaASc5rHfnUZylw3EwRqfO64dL2G11NbKvjbjOYezG1U9rsddX0XWQQXWrboRz 8osL0BQbJzq9LMaYLYXFWJb4/XiBEPW3JwnHS82gZ1GS5uGLrOHjXkbdkB/wmsaGk9JO 6enacNp9VTqNJ4E8E00/WHriw2TDSWGJItaLcg7ehL9l0bYjORLfpR0GQwDDQkzc1JYL /uQjHAHLGOiqQBGrVkGz66+S4hgHydX1sJfnhB5pNbJehDoxYcDXKGn60X+2yDvfiMNM kXwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=azQ/hYecD5LdwT5b7lHlb3aYYgAE0jlaPR/whhIx0o8=; b=eTwDp0JWNk9F9w++swEDI8yQtTb/UclqlxHvy7xw37AjuUeZTZxJCTYtP8UXQd6KTm qMqN/ZExlZwNshxvdf3LC2e2np/Sp0Dxg+2wgi4kGAKzfExmbkRYSCxwsFzUTDvh70RJ /KshDagena3iYgg26/PrH9WGALjsar+HBcb99HJTunIda+wk0KUZHWqMz8krWOcN5WFp cheef3y0L7HWzl4Mi9BamXphAi/D3Fe527NGBxEMq2p+bEMf8pr5DLH2mLsUl2zbwz2C tqeGi1kKaDoZLjUmWXBznuTHALlWHYrkXWpFJ/wf3+6E90b/tWQrbN3Ombk7zUtM1d3s 2Dgw== X-Gm-Message-State: APf1xPAVtMO/u2qnZQzvqTTWlDimXKZ3FXoC2F7BLSd4M0uAVl96nJ/y tMrdpDAPPkpypuG/303ukfSDPzxd8LULkvqeEnKbLg== X-Google-Smtp-Source: AG47ELsVrk0OX9sJrQI+ub9DV0NaKV3iaPjTZHZpWkGfPoryGNZQHuEHMNAnT+eRmjVFn908BaY1sWMw68p1EKAs6dg= X-Received: by 10.223.195.204 with SMTP id d12mr4079352wrg.116.1519972846361; Thu, 01 Mar 2018 22:40:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.169.206 with HTTP; Thu, 1 Mar 2018 22:40:45 -0800 (PST) Received: by 10.223.169.206 with HTTP; Thu, 1 Mar 2018 22:40:45 -0800 (PST) In-Reply-To: <1518137096.32585.128.camel@freebsd.org> References: <1518137096.32585.128.camel@freebsd.org> From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Fri, 2 Mar 2018 08:40:45 +0200 Message-ID: Subject: Re: Confused about ARM64 cross-compilation To: Ian Lepore Cc: Timur Tabi , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 06:40:49 -0000 Pe 9 feb. 2018 2:45 AM, "Ian Lepore" a scris: On Thu, 2018-02-08 at 18:21 -0600, Timur Tabi wrote: > I've installed FreeBSD 11 on an x86 system, and I followed the > instructions on https://wiki.freebsd.org/FreeBSD/arm/crossbuild to > download the source code. Then I download arm64_build.sh from > https://wiki.freebsd.org/arm64 and run that. Now it's building > something, but I don't know what it's doing. Shouldn't I need to > install a cross-compiler first? > Nope, the freebsd build process is completely self-contained. It starts by building whatever cross-compiler it needs if crossbuilding is involved. Was the cross compiling ever tested from a host that only has gcc? How far back should I go with the host to lack clang/llvm on the host to make sure the entire cross build of the toolchain is done from 0? I'm trying to add cross compilation from linux and I'm running into many issues related to missing apparently assumed object files on the host, but the build process doesn't make it clear which is the target for those object files. Having llvm as a cross compiler by default on the host doesn't make this distinction easy to figure out. From owner-freebsd-arm@freebsd.org Fri Mar 2 16:19:36 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D18BBF31423 for ; Fri, 2 Mar 2018 16:19:35 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from oneyou.mgm51.net (oneyou.mgm51.net [174.136.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oneyou.mgm51.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6760A69666 for ; Fri, 2 Mar 2018 16:19:34 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (sentry.24cl.com [IPv6:2001:558:6017:94:c582:1d99:a986:7609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mgm51.net (Postfix) with ESMTPS id 3ztDyl3ljBzWCYx for ; Fri, 2 Mar 2018 11:19:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mgm51.com; s=mgm51-02; t=1520007567; bh=WqHM3um5dIfrhIix8V5YZtM63OdrKEP9aMvUHJ/oDPc=; h=Subject:Cc:From:Message-ID:Date; b=YLU7lg0TPzUfyI48+aMXEbnd2lymfX7DEtVVI2a+q/RwU+RmrsukX8VDet01OAFBi hpjDi77YLxlD1+rTCiMkqCu+UJeV0btohAOzFDrqECZcvlmoCNikk/4IrQb3UfeZwA V1KzeoQ51mw7ZB0FihwOSKfnarA1ZbcMi8CTQJ18eDAIFUuFG2xKd9+do1lbNV/ul8 gswuIqnygwf4Ea2hkj+WZB4CsAH/9UZQj1FkXsYVNm4o7spf3dqkGqOFaxDHI2EX4D uyiPralvEehtAZK0Xjh4q66KJ/SZQ5dUhkFHsJ86oaHqwpc2JJR90dZlVeTJiAs4+Q EQiBALKvkBCHg== Received: from [IPv6:fdcf:b715:2f4d:1:7935:c9cc:21c2:33cc] (unknown [IPv6:fdcf:b715:2f4d:1:7935:c9cc:21c2:33cc]) by sentry.24cl.com (Postfix) with ESMTP id 3ztDyk43LJzkB4D for ; Fri, 2 Mar 2018 11:19:26 -0500 (EST) Subject: Re: Is maximum swap usage tunable? Cc: freebsd-arm@freebsd.org References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> From: Mike Message-ID: Date: Fri, 2 Mar 2018 11:19:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180228214301.GA29481@www.zefox.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 16:19:36 -0000 On 2/28/2018 4:43 PM, bob prohaska wrote: > On Wed, Feb 28, 2018 at 02:37:36PM -0500, Mike wrote: >> On 2/28/2018 1:55 PM, bob prohaska wrote: >>> On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: >>>> On 2/28/2018 12:03 PM, bob prohaska wrote: >>>>> In watching system compilations on an RPi3 it looks as if the >>>>> system starts killing processes with "out of swap" warnings >>>>> well below 50% of full utilization (in this case, 2 GB). One >>>>> recent instance of make -j4 kernel-toolchain killed llvm-tblgen >>>>> with only 34% of the swap in use. >>>>> >>>>> Is the maximum swap usage limit adjustable in any way? I didn't >>>>> recognize anything useful in the page at >>>>> https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&sektion=&manpath=freebsd-release-ports >>>>> >>>>> It's possible the problem is really swap speed, rather than size, so I'd >>>>> like to try changing size limits if possible. The swap media claims 2-3 >>>>> MB/sec random write speed and observations with gstat seem to support the >>>>> claim, but transient stalls are hard to observe. An RPi2 with similar >>>>> hardware seems to have no problems. >>>>> >>>> >>>> >>>>> It's possible the problem is really swap speed >>>> >>>> I was running into swap speed / timeout issues. There were messages on >>>> the console to that effect. >>>> >>>> Once I put the swap space on rotating rust, that part of the compile >>>> problem disappeared. I use 1GB swap space. >>>> >>> >>> The latest kernel versions seem to have largely done away with the >>> "indefinite wait buffobj" warnings. They're few and far between, >>> the compile proceeds unless they're abundant. The fact that armv7 >>> has no problem, and the system is reporting "out of swap" with 34% >>> in use strikes me as suspicious. Kernel and userland are in sync, >>> so the figure of 34% swap usage is probably accurate. >>> >>> Perhaps my question is better phrased thus: How does FreeBSD-arm >>> determine when it's out of swap? >>> >> >> >> Thanks for the follow-up. >> >> I was planning to download and try the >> >> RPI3-20180226-r330034 >> >> image file this evening. Per your comment, I'll not use the rusty swap >> space, and see what happens. >> >> I'll report back, probably on the morrow... >> > FWIW, I've been using Sandisk Extreme USB 3 flash drives for > /usr /var/ and swap on the Pi3. It seems that flash write > speed is a tighter bottleneck than USB 2.0 ports on the Pi. > Attempts to use older, slower USB 2 flash drives on a Pi2 > didn't work, though the symptoms were never "out of swap". > buildworld is still running. I started it around 3PM (EST) on March 1. I'm seeing a lot of swap messages on the console. The text is: swap_pager: indefinite wait buffer: bufobj: 0, blkno: [varies], size: [varies] From owner-freebsd-arm@freebsd.org Fri Mar 2 17:04:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96CE7F34E6B for ; Fri, 2 Mar 2018 17:04:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 198FF6C02E for ; Fri, 2 Mar 2018 17:04:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id q24so11277260ioh.8 for ; Fri, 02 Mar 2018 09:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AJzVSU6SwnUG1b4Tp7f+n2krdNybQXCFERjBseFAa5Q=; b=IfXdmq9YRigWva1/pkyVta8biSnABNAxDlZa29yIeWhZGAoJNTM9PdsVh7C+gdLn8K j/UYQS/zbDWi3n3rQ3hstQnoXo3jE7mF5AE8NzY8Rnfe5b5ICYwKH/Jsp19cj6mOgApw sbxSXEaJFimxHM1cadjyV6gXpaTeYOwTQmcb5bsrancc+eUgfpA7qDyH428tRgPpx6Rj BJiw7ML3WA8yBSDpTkND6iMTYC9/Gf3FPuWGkjYUC/+IgQeHT5/xtmfQDTk8ZwySqZp9 TWFdBEoDBUezrsYBizchXqGu+ha4Gxo+oQdqCPbDgg5TvQ0tRI8OB6yOJ+5V7vTaEA5+ C9TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AJzVSU6SwnUG1b4Tp7f+n2krdNybQXCFERjBseFAa5Q=; b=mUVC6n7kA/ytYHofZD5J+gEhCSvVEEQiJeWQPA5ysIIYWLjjmXOsMm1JDEdI3dPeDt 0QGvixwUFT1dmAR9FMwWt3fbnHEUcMJBBAXivHEdZKMXu6QB+blfluQfd9Cxs+7ww6KD aMsBeFsLUPluh3zKykeV+Uzs8ZM7Yx3pQ93ztlWhvQZKs0TU4+rXKeIdDOq4jK3kCg2N o+8gzhIFM1bjBGKDINfyCJ1JPUXYP46qOUCjAQ8nH4QvuZb5IXU5Vku1fyBZ2YIvQgrF I9VCwPe0e9fZQs0j7pTghMRcOyKJqMfpidLMYCF0eG18CYTvb9iElSi2UoPOADkMUY5l HsTQ== X-Gm-Message-State: AElRT7FQCej2I49RXG59lwzHf6feHD8Izq4E6b4UXzbhG/TQjaeNgYj7 mOuH7gczlN9QUJZMF3cJAtXzDZgLqzHe38QIbanHbA== X-Google-Smtp-Source: AG47ELvn63ZsOPBlLstN4BYBEP8foYUdFN3lA5h468zRr6ipYoR/SUnvDBMQPzXIelaCMQwQd83C6bvGIuWgl5fVziQ= X-Received: by 10.107.142.79 with SMTP id q76mr7297817iod.299.1520010297310; Fri, 02 Mar 2018 09:04:57 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Fri, 2 Mar 2018 09:04:56 -0800 (PST) X-Originating-IP: [50.227.106.226] In-Reply-To: References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> From: Warner Losh Date: Fri, 2 Mar 2018 10:04:56 -0700 X-Google-Sender-Auth: x2SorJgQEtw4G54r-SmrXIr6-ps Message-ID: Subject: Re: Is maximum swap usage tunable? To: Mike Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 17:04:58 -0000 On Fri, Mar 2, 2018 at 9:19 AM, Mike wrote: > On 2/28/2018 4:43 PM, bob prohaska wrote: > > On Wed, Feb 28, 2018 at 02:37:36PM -0500, Mike wrote: > >> On 2/28/2018 1:55 PM, bob prohaska wrote: > >>> On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: > >>>> On 2/28/2018 12:03 PM, bob prohaska wrote: > >>>>> In watching system compilations on an RPi3 it looks as if the > >>>>> system starts killing processes with "out of swap" warnings > >>>>> well below 50% of full utilization (in this case, 2 GB). One > >>>>> recent instance of make -j4 kernel-toolchain killed llvm-tblgen > >>>>> with only 34% of the swap in use. > >>>>> > >>>>> Is the maximum swap usage limit adjustable in any way? I didn't > >>>>> recognize anything useful in the page at > >>>>> https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)& > sektion=&manpath=freebsd-release-ports > >>>>> > >>>>> It's possible the problem is really swap speed, rather than size, so > I'd > >>>>> like to try changing size limits if possible. The swap media claims > 2-3 > >>>>> MB/sec random write speed and observations with gstat seem to > support the > >>>>> claim, but transient stalls are hard to observe. An RPi2 with similar > >>>>> hardware seems to have no problems. > >>>>> > >>>> > >>>> > >>>>> It's possible the problem is really swap speed > >>>> > >>>> I was running into swap speed / timeout issues. There were messages > on > >>>> the console to that effect. > >>>> > >>>> Once I put the swap space on rotating rust, that part of the compile > >>>> problem disappeared. I use 1GB swap space. > >>>> > >>> > >>> The latest kernel versions seem to have largely done away with the > >>> "indefinite wait buffobj" warnings. They're few and far between, > >>> the compile proceeds unless they're abundant. The fact that armv7 > >>> has no problem, and the system is reporting "out of swap" with 34% > >>> in use strikes me as suspicious. Kernel and userland are in sync, > >>> so the figure of 34% swap usage is probably accurate. > >>> > >>> Perhaps my question is better phrased thus: How does FreeBSD-arm > >>> determine when it's out of swap? > >>> > >> > >> > >> Thanks for the follow-up. > >> > >> I was planning to download and try the > >> > >> RPI3-20180226-r330034 > >> > >> image file this evening. Per your comment, I'll not use the rusty swap > >> space, and see what happens. > >> > >> I'll report back, probably on the morrow... > >> > > FWIW, I've been using Sandisk Extreme USB 3 flash drives for > > /usr /var/ and swap on the Pi3. It seems that flash write > > speed is a tighter bottleneck than USB 2.0 ports on the Pi. > > Attempts to use older, slower USB 2 flash drives on a Pi2 > > didn't work, though the symptoms were never "out of swap". > > > > buildworld is still running. I started it around 3PM (EST) on March 1. > > I'm seeing a lot of swap messages on the console. The text is: > > swap_pager: indefinite wait buffer: bufobj: 0, > blkno: [varies], size: [varies] This message comes from the swap pager when the I/O doesn't complete quickly enough. It has nothing to do with sizes of the swap space. I've seen three causes for this: (1) The driver going crazy and not completing I/Os it gets notified as being done; (2) The driver not having a backstop timer on I/Os to fail them with timeout; (3) timeouts not firing for the driver to fail the I/O up the stack. (4) when a drive suddenly slow way way down (~100x or more slower), the I/O queues balloons and you can get these. Warner From owner-freebsd-arm@freebsd.org Fri Mar 2 17:16:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8684F35BD6 for ; Fri, 2 Mar 2018 17:16:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39DBB6C945 for ; Fri, 2 Mar 2018 17:16:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 46f8439e-1e3d-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 46f8439e-1e3d-11e8-b951-f99fef315fd9; Fri, 02 Mar 2018 17:15:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w22HFv7v087582; Fri, 2 Mar 2018 10:15:57 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1520010957.23690.10.camel@freebsd.org> Subject: Re: Is maximum swap usage tunable? From: Ian Lepore To: Warner Losh , Mike Cc: "freebsd-arm@freebsd.org" Date: Fri, 02 Mar 2018 10:15:57 -0700 In-Reply-To: References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 17:16:07 -0000 On Fri, 2018-03-02 at 10:04 -0700, Warner Losh wrote: > On Fri, Mar 2, 2018 at 9:19 AM, Mike wrote: > > > > > On 2/28/2018 4:43 PM, bob prohaska wrote: > > > > > > On Wed, Feb 28, 2018 at 02:37:36PM -0500, Mike wrote: > > > > > > > > On 2/28/2018 1:55 PM, bob prohaska wrote: > > > > > > > > > > On Wed, Feb 28, 2018 at 12:20:56PM -0500, Mike wrote: > > > > > > > > > > > > On 2/28/2018 12:03 PM, bob prohaska wrote: > > > > > > > > > > > > > > In watching system compilations on an RPi3 it looks as if the > > > > > > > system starts killing processes with "out of swap" warnings > > > > > > > well below 50% of full utilization (in this case, 2 GB). One > > > > > > > recent instance of make -j4 kernel-toolchain killed llvm-tblgen > > > > > > > with only 34% of the swap in use. > > > > > > > > > > > > > > Is the maximum swap usage limit adjustable in any way? I didn't > > > > > > > recognize anything useful in the page at > > > > > > > https://www.freebsd.org/cgi/man.cgi?query=sysctl(8)&; > > sektion=&manpath=freebsd-release-ports > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's possible the problem is really swap speed, rather than size, so > > I'd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > like to try changing size limits if possible. The swap media claims > > 2-3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > MB/sec random write speed and observations with gstat seem to > > support the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > claim, but transient stalls are hard to observe. An RPi2 with similar > > > > > > > hardware seems to have no problems. > > > > > > > > > > > > > > > > > > > > > > > > > > > It's possible the problem is really swap speed > > > > > > I was running into swap speed / timeout issues.  There were messages > > on > > > > > > > > > > > > > > > > > > > > > > > > the console to that effect. > > > > > > > > > > > > Once I put the swap space on rotating rust, that part of the compile > > > > > > problem disappeared.  I use 1GB swap space. > > > > > > > > > > > The latest kernel versions seem to have largely done away with the > > > > > "indefinite wait buffobj" warnings. They're few and far between, > > > > > the compile proceeds unless they're abundant. The fact that armv7 > > > > > has no problem, and the system is reporting "out of swap" with 34% > > > > > in use strikes me as suspicious. Kernel and userland are in sync, > > > > > so the figure of 34% swap usage is probably accurate. > > > > > > > > > > Perhaps my question is better phrased thus: How does FreeBSD-arm > > > > > determine when it's out of swap? > > > > > > > > > > > > > Thanks for the follow-up. > > > > > > > > I was planning to download and try the > > > > > > > >   RPI3-20180226-r330034 > > > > > > > > image file this evening.  Per your comment, I'll not use the rusty swap > > > > space, and see what happens. > > > > > > > > I'll report back, probably on the morrow... > > > > > > > FWIW, I've been using Sandisk Extreme USB 3 flash drives for > > > /usr /var/ and swap on the Pi3. It seems that flash write > > > speed is a tighter bottleneck than USB 2.0 ports on the Pi. > > > Attempts to use older, slower USB 2 flash drives on a Pi2 > > > didn't work, though the symptoms were never "out of swap". > > > > > buildworld is still running.  I started it around 3PM (EST) on March 1. > > > > I'm seeing a lot of swap messages on the console.  The text is: > > > >   swap_pager: indefinite wait buffer: bufobj: 0, > >      blkno: [varies], size: [varies] > > This message comes from the swap pager when the I/O doesn't complete > quickly enough. It has nothing to do with sizes of the swap space. > > I've seen three causes for this: (1) The driver going crazy and not > completing I/Os it gets notified as being done; (2) The driver not having a > backstop timer on I/Os to fail them with timeout; (3) timeouts not firing > for the driver to fail the I/O up the stack. (4) when a drive suddenly slow > way way down (~100x or more slower), the I/O queues balloons and you can > get these. > > Warner You forgot a cause: (5) swap is on an sdcard where taking 30-90 seconds to complete an IO is "normal". Making it even more fun, there's a sort of (5.5) bullet: an sdcard can "lend" its horrible performance to every other storage device in the system.  If there is a ton of IO queued up to the sd device (such as when .o files from a a make -j are ending up there) then all the buffers in the system get stacked up in the sd device's bio queue and IO to other devices suffers. I've always thought the new(ish) IO scheduler stuff should be able to help with that in some way, but I never get around to looking at it. -- Ian From owner-freebsd-arm@freebsd.org Fri Mar 2 17:23:14 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A228DF364F8 for ; Fri, 2 Mar 2018 17:23:14 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 3DCE56CE8B for ; Fri, 2 Mar 2018 17:23:13 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 98E9320AB8 for ; Fri, 2 Mar 2018 12:23:13 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 02 Mar 2018 12:23:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=7krMAiVV/UNkTaxpC2VGGJ2GTCOmKG3dykO24UViAOs=; b=L3TYL+QR xB59jqk+jFIjPJqHNLvgrLuK6pgyYI/EM1L3p2spmcKpJHxxBu5owHxlilmJAnCT jgW30vD9fYNughvq/eqW/owaANkVc9JvsG7IWRVf5zzPFehNg+ZykC8zjwEY0oY8 IWyEKFTbryc/nuQ2cpzNSVDamj3CknvzxkMeGi8+PjMon7kADuMBBFbhGrexvlre Mr4fOwjXevrbTu5zaBwRSEnIy5afMKouq6gES4VcaSIITi7Gmr/c6KG7Fyump6Vm DE6vJVCbhs4h3EtiLWJaXGFRSECRiTKRp69vO+9PoUYmpRQZOGSd5UyLM//IM3Zu Xduf8h15tPdmtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=7krMAiVV/UNkTaxpC2VGGJ2GTCOmK G3dykO24UViAOs=; b=jr0rLZCKGahjFfUmiNuMVm9YyseJwfGKw2X7iOfLT8/IF mfF5nMKhgyUc7gTH4jOlmNaiqUunh4QpVTP4XZcgkE7ZtICVDLD2WxwjngSXQmbq 9j/lXbJerp0BC8iiTPr18INP1HhB/ZMp8NM3Rl1J9QGOMb3Hes5DpymjxfadqZ9l CB/USLxGMHcZPn+1q6HVr03N9JAav4MSsp3vvGDva1zlOJzim2MywYpA0yzfdSw2 pAzFilKAEqtJaJ3ZjLlbuTIewjglaaqYnYwr+NFjwdct7rUFt/BefrklADjhbDnW AT5K0O2/UYhqiSQOfM2kdNshDMN3ujcCF1Jq+fnbQ== X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 221707E622 for ; Fri, 2 Mar 2018 12:23:13 -0500 (EST) To: freebsd-arm@freebsd.org From: tech-lists Subject: rpi2/zfs Message-ID: <2427949f-c76d-3d04-e379-3f398110fff1@zyxst.net> Date: Fri, 2 Mar 2018 17:23:12 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 17:23:14 -0000 Hi, Has anyone tried running the rpi2 with zfs (an attached hard drive the thing having zfs filesystem)? I'd imagine it'd be slow but is it usable? Within expectations? If so, please could you share any zfs sysctls you needed to make it work. thanks, -- J. From owner-freebsd-arm@freebsd.org Fri Mar 2 17:48:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BA45F38059 for ; Fri, 2 Mar 2018 17:48:07 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from oneyou.mgm51.net (oneyou.mgm51.net [174.136.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oneyou.mgm51.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1947D6E107 for ; Fri, 2 Mar 2018 17:48:06 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (sentry.24cl.com [IPv6:2001:558:6017:94:c582:1d99:a986:7609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mgm51.net (Postfix) with ESMTPS id 3ztGx122dnzWCYy for ; Fri, 2 Mar 2018 12:48:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mgm51.com; s=mgm51-02; t=1520012885; bh=xR2TD8k8exRPu4v4HKbExaHk6UovMT8cs+1JrhS9Zmc=; h=Subject:To:From:Message-ID:Date; b=es6Ljv3Z5d5Tk9qAbhVL1KQrvOvh/2depNiLjZlZWsNLXiyYJ+uStk7kWAIH15evk PSpu+XMk+UxyGfTjx4TRcrZ9dRX2u2cDK5sEWFRvOdLJcac6BbphxOwKVebX7+6nsQ +sRhwQDhXf1aB/1qhJVhytNN06y0CcFPTNSUxPs/U90MSFYbAFG3DhyuYgPrU0hYAK ysqXXrm16nqDt5CqI0LAXhy+MZncOm/zU4Ff+hk0x9QmfilWU5BJIQfAq9DgJw6hty 2sgRanMGHLkBQE3gHoHoSYrICN4kO9MsTRhRsnrtHhX8h4BBy1+46HRbkD2zze45Zm f074+jR5/AAUQ== Received: from [IPv6:fdcf:b715:2f4d:1:7935:c9cc:21c2:33cc] (unknown [IPv6:fdcf:b715:2f4d:1:7935:c9cc:21c2:33cc]) by sentry.24cl.com (Postfix) with ESMTP id 3ztGx01pV1zkB4D for ; Fri, 2 Mar 2018 12:48:04 -0500 (EST) Subject: Re: Is maximum swap usage tunable? To: "freebsd-arm@freebsd.org" References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> From: Mike Message-ID: Date: Fri, 2 Mar 2018 12:47:53 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 17:48:07 -0000 On 3/2/2018 12:04 PM, Warner Losh wrote: > >[snip] > > buildworld is still running.  I started it around 3PM (EST) on March 1. > > I'm seeing a lot of swap messages on the console.  The text is: > >   swap_pager: indefinite wait buffer: bufobj: 0, >      blkno: [varies], size: [varies] > > > This message comes from the swap pager when the I/O doesn't complete > quickly enough. It has nothing to do with sizes of the swap space. > > I've seen three causes for this: (1) The driver going crazy and not > completing I/Os it gets notified as being done; (2) The driver not > having a backstop timer on I/Os to fail them with timeout; (3) timeouts > not firing for the driver to fail the I/O up the stack. (4) when a drive > suddenly slow way way down (~100x or more slower), the I/O queues > balloons and you can get these. Thanks for the explanation. So far, buildworld is continuing to run. That is something that has not happened before, buildworld would usually abort by now. swap is on an older Adata (U1) microSD card. I have a Sandisk Extreme Pro (V30) microSD card arriving over the weekend (hopefully), so I'd be interested in seeing if that makes any difference, either to the number of messages or the speed of the build. From owner-freebsd-arm@freebsd.org Fri Mar 2 20:19:14 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E0EAF42BF7 for ; Fri, 2 Mar 2018 20:19:14 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 E3082766E9 for ; Fri, 2 Mar 2018 20:19:13 +0000 (UTC) (envelope-from hyun@caffeinated.codes) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 18B3B20083 for ; Fri, 2 Mar 2018 15:19:13 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 02 Mar 2018 15:19:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= caffeinated.codes; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=AgZjLg/JAIDiB5phy0tj5WGOEhmdla/gVVHSuoZtU 8o=; b=Nladg8mGSfiSoqk88FqRbuSq3pLE2ejHCOaVAznanPhaakRVGJxk1bZzF xOwnVVdPvKE28fHlYJbRBkDE7Pl7AsUD7JniI1qpY7ESdT0AMySUS9/yoaS8fXqq 2hRiWDKt/5p6Emcaszqt6HkQVZNc98aQWz5UBRXrtItJqA7ZxqJfaY4izW8w8TlB l8zCcngl6MWyDplkStRZKZa52HkIXw+V6cDHanBQnQDF6cLp+bOtESgO+EEtHW3W EwKbv+eM/+P1C2/IFX46EHx/qlszItEjN46tRPCplyMwB3GsBuxRulRKWLcXD8h+ DJ0oBRh5E7Ebma5OcgW3VqCjmC85w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=AgZjLg/JAIDiB5phy0tj5WGOEhmdl a/gVVHSuoZtU8o=; b=B6bvZ9BlBEucSWnh3lJfOuVqApvxv2SoOv0oDuUpndr3y WkpuHMxFPqV3bJJwZJ/+nZ8NNcWLvVtCoOfMaSWf5OC1hb+9OhNPw8b1MgPJEI7Y 8JBXPUWZSCZlW3xVOvLftDY3ksMDi4MWwmN23cssy2vwiyfVUfiNkdNHKJ8WhD56 w6E7x3KvXOcquIJvtk5e9ZTdF+bDggWOPET9Nk8ET2teZZRcmdpl1qGH8E9cUfrf 5ULQCEFsIM5IzaM9/W9q+viCJpN2HHLKDlbxyeQn5J34U1FV3fdCf1NfHUhgjVAe OWxhehstNW3eMtCQsvg2C8kHierbUHJnsIvTKMcxA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id ECEF89E21F; Fri, 2 Mar 2018 15:19:12 -0500 (EST) Message-Id: <1520021952.1789846.1289530984.1590B651@webmail.messagingengine.com> From: Hyun Hwang To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 Subject: RPI3 boot failure after self-built update to r330131 (Subtopic: How to properly update CURRENT on RPi3?) Date: Fri, 02 Mar 2018 15:19:12 -0500 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 20:19:14 -0000 Hi, Recently after replacing my Transcend microSD card, I haven't had any chance to fiddle with my RPi3 until now. Yesterday I wrote the stock image of r330034 to my RPi3 and immediately tried a system update using the source. Now it cannot find the kernel and cannot boot. Of course, the whole build on RPi3 itself is extremely slow, so I used another faster amd64 machine to cross-build it. I used this command on the builder: `make -j8 TARGET=arm64 TARGET_ARCH=aarch64 KERNCONF=GENERIC buildworld buildkernel`. (I do not have `/etc/make.conf` and `/etc/src.conf`, so it is a vanilla build without any customization.) Then after I mounted my SD card (`mount /dev/da0s2 /mnt/ && mount -tmsdosfs /dev/da0s1 /mnt/boot/msdos/`), I issued install: `make TARGET=arm64 TARGET_ARCH=aarch64 KERNCONF=GENERIC DESTDIR=/mnt/ installkernel installworld`. After running mergemaster (`mergemaster -Ui -Aaarch64 -D/mnt/`; I'm deferring use of `etcupdate` for now), I copied everything from `/usr/local/share/u-boot/u-boot-rpi3/` to `/mnt/boot/msdos/`, and `/mnt/boot/boot1.efi` to `/mnt/boot/msdos/EFI/BOOT/bootaarch64.efi`. I referenced crochet's RaspberryPi3/setup.sh to know which files I need to copy. Now, the boot fails with `can't find 'kernel'` message. I have doubled-checked that `/mnt/boot/kernel/kernel` exists before unmounting, and it is still there. My `/mnt/boot/loader.conf` has this line only: `autoboot_delay="1"`. Did I do something wrong during above steps (I use this method on my RPi2) or is there any other specific update options I should have followed? -- Hyun Hwang From owner-freebsd-arm@freebsd.org Fri Mar 2 20:30:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 350BDF43761 for ; Fri, 2 Mar 2018 20:30:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC12B76DEA for ; Fri, 2 Mar 2018 20:30:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w22KUFNa036766 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Mar 2018 12:30:16 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w22KUEqI036765; Fri, 2 Mar 2018 12:30:14 -0800 (PST) (envelope-from fbsd) Date: Fri, 2 Mar 2018 12:30:14 -0800 From: bob prohaska To: Mike Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180302203014.GB33421@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 20:30:18 -0000 On Fri, Mar 02, 2018 at 11:19:16AM -0500, Mike wrote: > > buildworld is still running. I started it around 3PM (EST) on March 1. > > I'm seeing a lot of swap messages on the console. The text is: > > swap_pager: indefinite wait buffer: bufobj: 0, > blkno: [varies], size: [varies] > > > That's been my experience too. How is your storage and swap set up? Any idea what peak swap usage is? Thanks for posting! bob prohaska From owner-freebsd-arm@freebsd.org Fri Mar 2 20:39:35 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66B00F4428D for ; Fri, 2 Mar 2018 20:39:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC6A377426 for ; Fri, 2 Mar 2018 20:39:34 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w22KdXQJ036798 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Mar 2018 12:39:34 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w22KdWBN036797; Fri, 2 Mar 2018 12:39:32 -0800 (PST) (envelope-from fbsd) Date: Fri, 2 Mar 2018 12:39:32 -0800 From: bob prohaska To: Mike Cc: "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180302203932.GC33421@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 20:39:35 -0000 On Fri, Mar 02, 2018 at 12:47:53PM -0500, Mike wrote: > > So far, buildworld is continuing to run. That is something that has not > happened before, buildworld would usually abort by now. > > swap is on an older Adata (U1) microSD card. Do you mean the boot microSD, or separate? bob prohaska From owner-freebsd-arm@freebsd.org Fri Mar 2 23:13:19 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DB37F2B530 for ; Fri, 2 Mar 2018 23:13:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B0CF7E9BD for ; Fri, 2 Mar 2018 23:13:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w22NDHAx037196 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Mar 2018 15:13:18 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w22NDHa9037195; Fri, 2 Mar 2018 15:13:17 -0800 (PST) (envelope-from fbsd) Date: Fri, 2 Mar 2018 15:13:17 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Can two USB flash drives conflict with each other? Message-ID: <20180302231317.GA37148@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 23:13:19 -0000 I just tried connecting a second SanDisk USB 3.0 flash drive to a Pi3 running -current. It's not precisely identical to the first, having a different activity indicator and being slightly older. Upon connection, the RPi3 console began emitting a continuous loop of error messages: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0a[WRITE(offset=268632064, length=32768)]error = 5 g_vfs_done():da0a[WRITE(offset=825819136, length=32768)]error = 5 swap_pager: I/O error - pagein failed; blkno 2228,size 4096, error 5 gv_vfsm_done_f()aul:dt:a0 pa[aWger RIreTE(ofadfs eetr=ror,65 p536id, 1leng t(iniht) =4096)]error = 5 g_vfs_done():da0a[WRITE(offset=8585216, length=4096)]error = 5 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 08 01 80 00 00 40 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain This output seems to go on indefinitely, even after the offending flash drive was removed. Note the garbling in the 5th line of console output; it's been seen on rare occasions before, but never "on demand". A shutdown -r command stopped at Shutdown NOW! shutdown: [pid 3469] root@www:/usr/src # sh: /usr/bin/wall: Input/output error and the shell is now unresponsive. The console still has a login prompt, but never asks for a password. Looks like plug-pulling time. The obvious solution is "don't do that!", but if somebody can offer a more insightful explanation I'd be grateful. Using two USB flash drives simultaneously would be very useful. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Mar 3 00:32:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30067F3159F for ; Sat, 3 Mar 2018 00:32:30 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 D4DA08246D for ; Sat, 3 Mar 2018 00:32:29 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1742120C05; Fri, 2 Mar 2018 19:32:29 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 02 Mar 2018 19:32:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=APHf8cBbkOO0FZ5U+IthLzpFjKcdD SPOZsnEQdkTLlA=; b=pLUHF7O15CFBKjrTbpDO/Vlghz06QM3H0P+CkiQqphTTa vO+qiKGVVQnzp6MOehr6vLZ8hjnoKpXCcfjPx0dXVrjD8hqQKkfBYa7rWN+XnXfl lwHqvjTBbdSb1DtdYvwcePZ6jqdXk+4xH6p54mbvz5sPWMomoUZryHlLYMs05NiQ miaN+0K3nkVBB8okuUm91OIrJYg6tUF2qiVUz/SfOYYLeb/C/Kaoae8Ayqh9btJ9 nD5d7I3i70ci4siZjd+2CjrwDt1cVGCpeo0KJgpIN9aCXo+ECKwbmlIxuP8W2CgB nb0JqMlsCimSpScO/SUdexMDR4JEh0UUS0E2twsbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=APHf8c BbkOO0FZ5U+IthLzpFjKcdDSPOZsnEQdkTLlA=; b=eoj8H7FTuxGYHIQ6gEHMy0 7EyO9RQc3E9+WnP0boEmcvj6jR1Shjm86pZEQRq4wuaTDiNJi7c8RO4r1uriJJry GI2lCcQTnxjvcCZ7yJWnupDVf0OEQ4p0sfeD+CHSHiCtcekWUkNESpxyc/ZSuoYX AIc89onMj2jxxUoXxNebTeiLgWo0LpGZwGLjM6/WcBkls6HpYHwOzLKlVfNK8bLC 4iZ8CjpYzkJ61Cj1jBeLtFnMRZKJGcMWMQ0NA8EsUAauwQlOtFJJh6N8A273q50z t7dK0xXWX/q73IDPYpDkvKIA1DWSp03uR8qoouCw7Ts7Vl+6dmrvIwshw0oAlucw == X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 93081246C8; Fri, 2 Mar 2018 19:32:28 -0500 (EST) Subject: Re: Can two USB flash drives conflict with each other? To: bob prohaska References: <20180302231317.GA37148@www.zefox.net> From: tech-lists Cc: freebsd-arm@freebsd.org Message-ID: <0fd4b991-a7d8-0e04-7d73-26d351873390@zyxst.net> Date: Sat, 3 Mar 2018 00:32:27 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180302231317.GA37148@www.zefox.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 00:32:30 -0000 On 02/03/2018 23:13, bob prohaska wrote: > The obvious solution is "don't do that!", but if somebody can offer > a more insightful explanation I'd be grateful. Using two USB flash > drives simultaneously would be very useful. I've found [this was a year ago, maybe two] that if I had two usb sticks plugged in that sometimes they'd be detected in reverse order to what I expected. What I mean is that sometimes the device called /dev/da0 and the one called /dev/da1 would swap on reboot. I suppose it would depend on which one woke up first. So if I had made /dev/da0p1, allocated it as swap, /dev/da0p1 as data, perhaps put the ports tree there, /dev/da1p1 as data, perhaps used the entire device for data, sometimes it'd boot, look at /dev/da0 which was /dev/da1 previously, not seen swap, and complained loudly. I think there is a way to wire device identities to names but it might need GPT rather than MBR as a partitioning scheme. I worked around it by labelling one of the usb sticks with sticky tape and ensuring it wasn't plugged in before the other one when rebooting. -- J. From owner-freebsd-arm@freebsd.org Sat Mar 3 00:43:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45BE2F31FC8 for ; Sat, 3 Mar 2018 00:43:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D54882A34; Sat, 3 Mar 2018 00:43:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w230hGF0037371 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Mar 2018 16:43:17 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w230hG8B037370; Fri, 2 Mar 2018 16:43:16 -0800 (PST) (envelope-from fbsd) Date: Fri, 2 Mar 2018 16:43:15 -0800 From: bob prohaska To: Ian Lepore Cc: Warner Losh , Mike , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180303004315.GB37148@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> <1520010957.23690.10.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1520010957.23690.10.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 00:43:26 -0000 On Fri, Mar 02, 2018 at 10:15:57AM -0700, Ian Lepore wrote: > You forgot a cause: (5) swap is on an sdcard where taking 30-90 seconds > to complete an IO is "normal". > FWIW, the Sandisk Extreme USB flash drive is claimed to be considerably faster than that, ~2MB/sec random write, at least per http://usb.userbenchmark.com/SanDisk-Extreme-USB-30-16GB/Rating/1301 One hopes(!) that the microSD cards of the same name are simlar. > Making it even more fun, there's a sort of (5.5) bullet: an sdcard can > "lend" its horrible performance to every other storage device in the > system. ?If there is a ton of IO queued up to the sd device (such as > when .o files from a a make -j are ending up there) then all the > buffers in the system get stacked up in the sd device's bio queue and > IO to other devices suffers. > A j4 buildworld on an RPI2 running -current seems to work much better than j2 on an RPI3, both using the same Sandisk flash devices. The Pi2 has /usr, /var /tmp and swap on USB flash, the Pi3 has /tmp and half the swap on microSD, with /usr, /var and the other half of swap on USB flash. Thus, /tmp and all of swap are on the same device for the Pi2, while /tmp and only half the swap are on the same device on the Pi3. It was expected the Pi3 should work better than the Pi2, but the opposite seems to be observed. > I've always thought the new(ish) IO scheduler stuff should be able to > help with that in some way, but I never get around to looking at it. > > I'd be pleased to do any testing I can, if it helps. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Mar 3 00:57:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6891F32EE4 for ; Sat, 3 Mar 2018 00:57:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47ACD839DB for ; Sat, 3 Mar 2018 00:57:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w230v1Qd037417 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Mar 2018 16:57:02 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w230v03o037416; Fri, 2 Mar 2018 16:57:01 -0800 (PST) (envelope-from fbsd) Date: Fri, 2 Mar 2018 16:57:00 -0800 From: bob prohaska To: tech-lists Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Can two USB flash drives conflict with each other? Message-ID: <20180303005700.GC37148@www.zefox.net> References: <20180302231317.GA37148@www.zefox.net> <0fd4b991-a7d8-0e04-7d73-26d351873390@zyxst.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0fd4b991-a7d8-0e04-7d73-26d351873390@zyxst.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 00:57:03 -0000 On Sat, Mar 03, 2018 at 12:32:27AM +0000, tech-lists wrote: > On 02/03/2018 23:13, bob prohaska wrote: > > The obvious solution is "don't do that!", but if somebody can offer > > a more insightful explanation I'd be grateful. Using two USB flash > > drives simultaneously would be very useful. > > I've found [this was a year ago, maybe two] that if I had two usb sticks > plugged in that sometimes they'd be detected in reverse order to what I > expected. > > What I mean is that sometimes the device called /dev/da0 and the one > called /dev/da1 would swap on reboot. I suppose it would depend on which > one woke up first. So if I had made /dev/da0p1, allocated it as swap, > /dev/da0p1 as data, perhaps put the ports tree there, /dev/da1p1 as > data, perhaps used the entire device for data, sometimes it'd boot, look > at /dev/da0 which was /dev/da1 previously, not seen swap, and complained > loudly. > > I think there is a way to wire device identities to names but it might > need GPT rather than MBR as a partitioning scheme. I worked around it by > labelling one of the usb sticks with sticky tape and ensuring it wasn't > plugged in before the other one when rebooting. > On the first try I plugged the second USB drive into a running machine, producing the errors reported. It's not obvious how a _second_ device can "unseat" one that is already represented in /dev/.... On a later try I plugged the second USB flash device in and powered the Pi3 up, whence the kernel got confused over which was which. That makes slightly more sense. I think that might be fixable with labels in /etc/fstab. In my case the second drive was labeled much like the first, so it couldn't help. Somewhere I got the idea USB flash devices had a unique serial number, or equivalent, so that more than one could co-exist on a host. Is this notion mistaken? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Mar 3 01:02:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D2F5F334DD for ; Sat, 3 Mar 2018 01:02:18 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA87A83E0F; Sat, 3 Mar 2018 01:02:17 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w23129S1032484; Fri, 2 Mar 2018 17:02:09 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w231298R032483; Fri, 2 Mar 2018 17:02:09 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803030102.w231298R032483@pdx.rh.CN85.dnsmgr.net> Subject: Re: Is maximum swap usage tunable? In-Reply-To: <20180303004315.GB37148@www.zefox.net> To: bob prohaska Date: Fri, 2 Mar 2018 17:02:09 -0800 (PST) CC: Ian Lepore , "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 01:02:18 -0000 > On Fri, Mar 02, 2018 at 10:15:57AM -0700, Ian Lepore wrote: > > > You forgot a cause: (5) swap is on an sdcard where taking 30-90 seconds > > to complete an IO is "normal". > > > FWIW, the Sandisk Extreme USB flash drive is claimed to be considerably > faster than that, ~2MB/sec random write, at least per > http://usb.userbenchmark.com/SanDisk-Extreme-USB-30-16GB/Rating/1301 > One hopes(!) that the microSD cards of the same name are simlar. > > > Making it even more fun, there's a sort of (5.5) bullet: an sdcard can > > "lend" its horrible performance to every other storage device in the > > system. ?If there is a ton of IO queued up to the sd device (such as > > when .o files from a a make -j are ending up there) then all the > > buffers in the system get stacked up in the sd device's bio queue and > > IO to other devices suffers. > > > A j4 buildworld on an RPI2 running -current seems to work much better > than j2 on an RPI3, both using the same Sandisk flash devices. The Pi2 > has /usr, /var /tmp and swap on USB flash, the Pi3 has /tmp and half > the swap on microSD, with /usr, /var and the other half of swap on > USB flash. Thus, /tmp and all of swap are on the same device for the > Pi2, while /tmp and only half the swap are on the same device on the Pi3. > It was expected the Pi3 should work better than the Pi2, but the opposite > seems to be observed. I would actually expect the opposite, but not for an obvious reason, the RPI2 is running a 32 bit version of FreeBSD, and the RPI3 is running a 64 bit version. These are memory constrained devices, and my theory is that the wasted memory used for pointers that can never address more than the 2G of physcial space on the RPI3 are killing your memory foot print, and killing your build. Getting that 32 bit version of FreeBSD running on the RPI3 would prove out my theory. In my mind it makes 0 sense to run a 64 bit OS on a device that physically has less than 4G of memory, other than as an exercise in yes, we can make the 64 bit code run on that cpu, but for real work usage it makes no practical sense. I also suspect that the cortex CPU in that thing can run 32 bit code a wee bit faster than 64 bit code other than large data moves... > > I've always thought the new(ish) IO scheduler stuff should be able to > > help with that in some way, but I never get around to looking at it. > > > > > I'd be pleased to do any testing I can, if it helps. > > Thanks for reading, > > bob prohaska -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sat Mar 3 01:05:57 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6102FF33907 for ; Sat, 3 Mar 2018 01:05:57 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C95DC840E3 for ; Sat, 3 Mar 2018 01:05:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2315s89032501; Fri, 2 Mar 2018 17:05:54 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2315sH7032500; Fri, 2 Mar 2018 17:05:54 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803030105.w2315sH7032500@pdx.rh.CN85.dnsmgr.net> Subject: Re: Can two USB flash drives conflict with each other? In-Reply-To: <20180303005700.GC37148@www.zefox.net> To: bob prohaska Date: Fri, 2 Mar 2018 17:05:54 -0800 (PST) CC: tech-lists , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 01:05:57 -0000 > On Sat, Mar 03, 2018 at 12:32:27AM +0000, tech-lists wrote: > > On 02/03/2018 23:13, bob prohaska wrote: > > > The obvious solution is "don't do that!", but if somebody can offer > > > a more insightful explanation I'd be grateful. Using two USB flash > > > drives simultaneously would be very useful. > > > > I've found [this was a year ago, maybe two] that if I had two usb sticks > > plugged in that sometimes they'd be detected in reverse order to what I > > expected. > > > > What I mean is that sometimes the device called /dev/da0 and the one > > called /dev/da1 would swap on reboot. I suppose it would depend on which > > one woke up first. So if I had made /dev/da0p1, allocated it as swap, > > /dev/da0p1 as data, perhaps put the ports tree there, /dev/da1p1 as > > data, perhaps used the entire device for data, sometimes it'd boot, look > > at /dev/da0 which was /dev/da1 previously, not seen swap, and complained > > loudly. > > > > I think there is a way to wire device identities to names but it might > > need GPT rather than MBR as a partitioning scheme. I worked around it by > > labelling one of the usb sticks with sticky tape and ensuring it wasn't > > plugged in before the other one when rebooting. > > > > On the first try I plugged the second USB drive into a running machine, > producing the errors reported. It's not obvious how a _second_ device > can "unseat" one that is already represented in /dev/.... I can not think of anything that should unseat a device either, unless somehow in the physical act of plugging it in the other one became disconnected and a bus probe happened. > On a later try I plugged the second USB flash device in and powered > the Pi3 up, whence the kernel got confused over which was which. That > makes slightly more sense. I think that might be fixable with labels > in /etc/fstab. In my case the second drive was labeled much like the > first, so it couldn't help. Right, labels are good :-) > Somewhere I got the idea USB flash devices had a unique serial number, > or equivalent, so that more than one could co-exist on a host. > Is this notion mistaken? You should be able to have as many USB flash devices as you want connected to a system, there are guys that have done silly things like "raid 5 on USB" using a stack of flash drives. I have been on service calls that I shake my head at how many external USB attached hard drives are attached to a windows box. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sat Mar 3 01:18:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 448A9F34648 for ; Sat, 3 Mar 2018 01:18:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA44C847F5 for ; Sat, 3 Mar 2018 01:18:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id l187so3970759ith.4 for ; Fri, 02 Mar 2018 17:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rC9r1xENAhPGeQcXeaJFnowK8l4Tho5k5wZdeFvAXSU=; b=VhXnsvPz2/rnL3WI8dxgjwH1w0qLqGhitr35T1yhn46uyTqeyfABZPwTx5L8njQnfJ /hr3qMSgvamnBTP8p1A1MgS37ZHpbfhYmCIB0FnEXvUOl005csPWb0NwVqliehQeEarn aRgnPGf5pix0LDMsV5M3bFmGezAVCMFA/DpkJPD/oX4gG3A+L7ZK9DFDhjoQJcLse9Wa 2PIQiRIg0hoiLjEyAH5asnBxqM/Dqs2mLE5Sn/tg3apsMzodBl491XC0Pd7cDuQyVmot JzGZ8wBY+HrQjWmKhZMJhiAQwAIPGk7RhmbesV0mIpiMm16qLJ8mbPpKXfuJL5vDIJhP zBhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rC9r1xENAhPGeQcXeaJFnowK8l4Tho5k5wZdeFvAXSU=; b=cVhMbwEiPyS3MoA/yvmtjoYuAYkijuzzcQSneS5wsmW3lThIDHlu9j4P83Lxz/Yl6X MvPCXbehsn9a/kSn81abQwqCDpskH16lnpqhd2mTalw322CVCN/E+1yAYepFnajidKtY XpgPRD+y2GfthAqSb7iS9DU0PSeFT+/4+KQh2puYtihkc5eGSyd4QyWV7OtmvPsnBzl1 RWsnq4i5887+jVnpYAudzm487UstqdbUR40BMITnxL7+WVZF7HEDfOBF73H0s37vMyiR QwfRhtk0AB2YOVKAe3RdOwmySEQN3QknwzEe08MUKQUrFTJyvLhBtpnvAxq9gz5f2oJV ++ww== X-Gm-Message-State: AElRT7ESIvhTsUpz/b1XQdnYrB1oAUWGcNej0uWDfkjCEmu4CGjSs8kj 3+8yaKKyjcEj6ci8T87wFJ76ahyQDdf69FsltMJAag== X-Google-Smtp-Source: AG47ELuhWC/4+o8cQmvbtKv/fO1R01y3vYK6qbKfQZYFa1X6PexBcNm9dZ0YPeUQLQsqe9Mpu8k9cLAfXoUx7u2EAxI= X-Received: by 10.36.16.147 with SMTP id 141mr5056080ity.73.1520039897133; Fri, 02 Mar 2018 17:18:17 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Fri, 2 Mar 2018 17:18:16 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180303004315.GB37148@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> <1520010957.23690.10.camel@freebsd.org> <20180303004315.GB37148@www.zefox.net> From: Warner Losh Date: Fri, 2 Mar 2018 18:18:16 -0700 X-Google-Sender-Auth: 6OcKS5QZ0I2L9bh2JaeEOC_67DU Message-ID: Subject: Re: Is maximum swap usage tunable? To: bob prohaska Cc: Ian Lepore , Mike , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 01:18:18 -0000 On Fri, Mar 2, 2018 at 5:43 PM, bob prohaska wrote: > On Fri, Mar 02, 2018 at 10:15:57AM -0700, Ian Lepore wrote: > > > You forgot a cause: (5) swap is on an sdcard where taking 30-90 seconds > > to complete an IO is "normal". > > > FWIW, the Sandisk Extreme USB flash drive is claimed to be considerably > faster than that, ~2MB/sec random write, at least per > http://usb.userbenchmark.com/SanDisk-Extreme-USB-30-16GB/Rating/1301 > One hopes(!) that the microSD cards of the same name are simlar. Hope in one hand and spit in the other and see which one gets wet first :) The problem isn't the steady-state happy-state streaming pictures/video to the card. The problem is that sometimes the "long tail" times for the I/O for pathological cases can be seconds, or tends of seconds. It doesn't take too many of those high-latency I/Os to really screw up the system.... SD card FTLs are 'go fast for streaming video / pictures, suck slow for everything else'. Consumer grade SSDs, though they also have kinda crappy FTLs, aren't anywhere near that bad. Warner From owner-freebsd-arm@freebsd.org Sat Mar 3 01:46:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A95EF35F8C for ; Sat, 3 Mar 2018 01:46:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 01B8F859B0; Sat, 3 Mar 2018 01:46:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w231kigj037530 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Mar 2018 17:46:45 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w231khfc037529; Fri, 2 Mar 2018 17:46:43 -0800 (PST) (envelope-from fbsd) Date: Fri, 2 Mar 2018 17:46:43 -0800 From: bob prohaska To: "Rodney W. Grimes" Cc: Ian Lepore , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180303014643.GD37148@www.zefox.net> References: <20180303004315.GB37148@www.zefox.net> <201803030102.w231298R032483@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201803030102.w231298R032483@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 01:46:46 -0000 On Fri, Mar 02, 2018 at 05:02:09PM -0800, Rodney W. Grimes wrote: > > On Fri, Mar 02, 2018 at 10:15:57AM -0700, Ian Lepore wrote: > > > > > You forgot a cause: (5) swap is on an sdcard where taking 30-90 seconds > > > to complete an IO is "normal". > > > > > FWIW, the Sandisk Extreme USB flash drive is claimed to be considerably > > faster than that, ~2MB/sec random write, at least per > > http://usb.userbenchmark.com/SanDisk-Extreme-USB-30-16GB/Rating/1301 > > One hopes(!) that the microSD cards of the same name are simlar. > > > > > Making it even more fun, there's a sort of (5.5) bullet: an sdcard can > > > "lend" its horrible performance to every other storage device in the > > > system. ?If there is a ton of IO queued up to the sd device (such as > > > when .o files from a a make -j are ending up there) then all the > > > buffers in the system get stacked up in the sd device's bio queue and > > > IO to other devices suffers. > > > > > A j4 buildworld on an RPI2 running -current seems to work much better > > than j2 on an RPI3, both using the same Sandisk flash devices. The Pi2 > > has /usr, /var /tmp and swap on USB flash, the Pi3 has /tmp and half > > the swap on microSD, with /usr, /var and the other half of swap on > > USB flash. Thus, /tmp and all of swap are on the same device for the > > Pi2, while /tmp and only half the swap are on the same device on the Pi3. > > It was expected the Pi3 should work better than the Pi2, but the opposite > > seems to be observed. > > I would actually expect the opposite, but not for an obvious reason, > the RPI2 is running a 32 bit version of FreeBSD, and the RPI3 is > running a 64 bit version. These are memory constrained devices, > and my theory is that the wasted memory used for pointers that can > never address more than the 2G of physcial space on the RPI3 are > killing your memory foot print, and killing your build. > Any idea how much memory gets wasted? Right now the Pi3 kernel is smaller than that of the Pi2, -r-xr-xr-x 1 root wheel 7142608 Feb 25 17:11 /boot/kernel/kernel versus -r-xr-xr-x 1 root wheel 9426388 Feb 26 22:31 /boot/kernel/kernel on the Pi2. Seems like that ought to at least help... > Getting that 32 bit version of FreeBSD running on the RPI3 would > prove out my theory. > How much and what kind of work is required? > In my mind it makes 0 sense to run a 64 bit OS on a device that > physically has less than 4G of memory, other than as an exercise > in yes, we can make the 64 bit code run on that cpu, but for > real work usage it makes no practical sense. I also suspect > that the cortex CPU in that thing can run 32 bit code a wee > bit faster than 64 bit code other than large data moves... > I agree, and remember your observations along those lines some time ago. The only reason I'm fooling with arm64 is that the older Pi2 seems NLA and the Pi3 is, or soon will be, the only option. A Pi3 running Raspbian, on which I'm typing this, is a quite decent little workstation. It's using USB flash (old and slow, by the way) for swap, but has a Sandisk Extreme microSD card. > > > I've always thought the new(ish) IO scheduler stuff should be able to > > > help with that in some way, but I never get around to looking at it. > > > > > > > > I'd be pleased to do any testing I can, if it helps. > > Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Mar 3 01:52:37 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF185F365CB for ; Sat, 3 Mar 2018 01:52:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3216A85DCD; Sat, 3 Mar 2018 01:52:35 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w231qXRD032677; Fri, 2 Mar 2018 17:52:33 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w231qXFA032676; Fri, 2 Mar 2018 17:52:33 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803030152.w231qXFA032676@pdx.rh.CN85.dnsmgr.net> Subject: Re: Is maximum swap usage tunable? In-Reply-To: <20180303014643.GD37148@www.zefox.net> To: bob prohaska Date: Fri, 2 Mar 2018 17:52:32 -0800 (PST) CC: Ian Lepore , "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 01:52:37 -0000 > On Fri, Mar 02, 2018 at 05:02:09PM -0800, Rodney W. Grimes wrote: > > > On Fri, Mar 02, 2018 at 10:15:57AM -0700, Ian Lepore wrote: > > > > > > > You forgot a cause: (5) swap is on an sdcard where taking 30-90 seconds > > > > to complete an IO is "normal". > > > > > > > FWIW, the Sandisk Extreme USB flash drive is claimed to be considerably > > > faster than that, ~2MB/sec random write, at least per > > > http://usb.userbenchmark.com/SanDisk-Extreme-USB-30-16GB/Rating/1301 > > > One hopes(!) that the microSD cards of the same name are simlar. > > > > > > > Making it even more fun, there's a sort of (5.5) bullet: an sdcard can > > > > "lend" its horrible performance to every other storage device in the > > > > system. ?If there is a ton of IO queued up to the sd device (such as > > > > when .o files from a a make -j are ending up there) then all the > > > > buffers in the system get stacked up in the sd device's bio queue and > > > > IO to other devices suffers. > > > > > > > A j4 buildworld on an RPI2 running -current seems to work much better > > > than j2 on an RPI3, both using the same Sandisk flash devices. The Pi2 > > > has /usr, /var /tmp and swap on USB flash, the Pi3 has /tmp and half > > > the swap on microSD, with /usr, /var and the other half of swap on > > > USB flash. Thus, /tmp and all of swap are on the same device for the > > > Pi2, while /tmp and only half the swap are on the same device on the Pi3. > > > It was expected the Pi3 should work better than the Pi2, but the opposite > > > seems to be observed. > > > > I would actually expect the opposite, but not for an obvious reason, > > the RPI2 is running a 32 bit version of FreeBSD, and the RPI3 is > > running a 64 bit version. These are memory constrained devices, > > and my theory is that the wasted memory used for pointers that can > > never address more than the 2G of physcial space on the RPI3 are > > killing your memory foot print, and killing your build. > > > Any idea how much memory gets wasted? Right now the Pi3 kernel is > smaller than that of the Pi2, > -r-xr-xr-x 1 root wheel 7142608 Feb 25 17:11 /boot/kernel/kernel > versus > -r-xr-xr-x 1 root wheel 9426388 Feb 26 22:31 /boot/kernel/kernel > on the Pi2. Seems like that ought to at least help... This is an artifact of the number of devices supported being short on the RPi3. > > Getting that 32 bit version of FreeBSD running on the RPI3 would > > prove out my theory. > > > How much and what kind of work is required? >From what jhb said the other day it is minor clean up details, and I believe someone else has wip in progress to clean up some of those details. > > > In my mind it makes 0 sense to run a 64 bit OS on a device that > > physically has less than 4G of memory, other than as an exercise > > in yes, we can make the 64 bit code run on that cpu, but for > > real work usage it makes no practical sense. I also suspect > > that the cortex CPU in that thing can run 32 bit code a wee > > bit faster than 64 bit code other than large data moves... > > > I agree, and remember your observations along those lines some > time ago. The only reason I'm fooling with arm64 is that the older > Pi2 seems NLA and the Pi3 is, or soon will be, the only option. > A Pi3 running Raspbian, on which I'm typing this, is a quite decent > little workstation. It's using USB flash (old and slow, by the way) > for swap, but has a Sandisk Extreme microSD card. And that Raspbian is 32 bit :-D > > > > I've always thought the new(ish) IO scheduler stuff should be able to > > > > help with that in some way, but I never get around to looking at it. > > > > > > > > > > > I'd be pleased to do any testing I can, if it helps. > > > > > Thanks for reading, > > bob prohaska -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sat Mar 3 16:26:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0A4AF2569F for ; Sat, 3 Mar 2018 16:26:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D09268A33 for ; Sat, 3 Mar 2018 16:26:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w23GQ6VI042019 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 3 Mar 2018 08:26:07 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w23GQ5UT042018; Sat, 3 Mar 2018 08:26:05 -0800 (PST) (envelope-from fbsd) Date: Sat, 3 Mar 2018 08:26:05 -0800 From: bob prohaska To: Warner Losh Cc: Mike , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: Is maximum swap usage tunable? Message-ID: <20180303162605.GA41874@www.zefox.net> References: <20180228170311.GA26187@www.zefox.net> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 16:26:11 -0000 On Fri, Mar 02, 2018 at 10:04:56AM -0700, Warner Losh wrote: > On Fri, Mar 2, 2018 at 9:19 AM, Mike wrote: > > > > > buildworld is still running. I started it around 3PM (EST) on March 1. > > > > I'm seeing a lot of swap messages on the console. The text is: > > > > swap_pager: indefinite wait buffer: bufobj: 0, > > blkno: [varies], size: [varies] > > > This message comes from the swap pager when the I/O doesn't complete > quickly enough. It has nothing to do with sizes of the swap space. > > I've seen three causes for this: (1) The driver going crazy and not > completing I/Os it gets notified as being done; (2) The driver not having a > backstop timer on I/Os to fail them with timeout; (3) timeouts not firing > for the driver to fail the I/O up the stack. (4) when a drive suddenly slow > way way down (~100x or more slower), the I/O queues balloons and you can > get these. > Is there some sort of experiment which can distinguish hardware delays from software delays? For example, would logging gstat output shed any light? Thanks for reading, bob prohaska